asher's comments

Well, we do have that law for patents. They expire in 20 years. And the patent itself "open-sources" the process being patented.

Regarding Depeche, people on Youtube have broken down exactly what each band member was playing during the 80s shows; you might find it interesting. The parts are simple. I don't say that to knock them at all, on the contrary it shows that pianistic excellence has little to do with great synthpop. Alan Wilder is a trained pianist and found little scope for his talents in those shows.

Of course the fast, repetitive bits were either on tape or sampled into the Emulator keyboards.

Good question. Definitely learn the rudiments of piano playing, up to playing block chords (triads) with either hand.

Beyond that, I think they diverge too much. A lot of piano technique is getting both hands working together to play rhythm and melody - but generally synths are doing one thing at a time, and cooperating with other instruments.

A lot of classic synth lines are monophonic, aka "one-finger" lines, although to play them fluidly with one finger would be pretty hard. So pianistic skills would be wasted in this context.

When polysynths got common in the mid 80s, pianistic fingering of chords (but not necessarily rhythms) was used. I mean, to play the melancholy chords of "Drive" by the Cars, you need some of the skills of a pianist, but not rhythmic ones. You do need two hands.

(Of course the DX7 was played very much as a piano at times)

I do think you need the music theory though, such as awareness of chords and functional harmony.

Consider learning some of the classic synth basslines - they tend to have tutorials on youtube - like Material Girl or Tarzan Boy.

Cool, thanks for making this.

This is basically the Roman Simplex font used in CAD packages, and included in the Hershey fonts.

https://en.wikipedia.org/wiki/Hershey_fonts

Hershey and CAD fonts are stroke-based, so line weight and endcap style influence the appearance.

Here's a JSONized version as part of the textlines tool: https://github.com/wildsparx/textlines/blob/master/fonts.jso...

Of course CAD fonts can be used at different aspect ratios - Roman Simplex is often used at 0.85 and that may be what National Park captures.

One path is to use sequential ints internally and encrypt them externally with something like idgen:

https://pypi.org/project/idgen/

That provides IDs that are both opaque and, if you want, user-friendly.

(disclaimer: I wrote it.)

The Bell System (America's telecom monopoly until it's breakup in the 80s) pretty much avoided Phillips, etc. screws. Everything was slot (or pin-hex tamperproof). I do see mention of a Phillips driver in this 1961 BSP: http://www.telephonecollectors.info/index.php/browse/bsp-bel...

The slotted terminal screws worked well because they were cheese head, or cylindrical, allowing the driver to apply torque at the very edge of the slot. Outside the Bell System, terminal screws are usually binding head, which has a fillet around the top edge, removing material where it's most needed.

Thanks for the report; don't know why that happened; no iframes involved.

Good catch. Will fix the accidentals.

In the Parsons Code section, if I'm reading correctly, the chords are conceived along an up-down axis. However chords do not really have that relation. Going from 1maj to 5maj can be up a fifth or down a fourth.

To illustrate this, first listen to the default 1645 progression on rhythatom. Then change the octave of row 2 (4maj chord) from +0 to +1. Can you hear its similar role in the progression, even though it's now stressed by being up an octave?

If you want to try these chord progressions in your browser, check out:

http://wildsparx.com/rhythatom/

Coincidentally I just finished it. Source is here:

https://github.com/wildsparx/rhythatom

In theory it should run in any Chrome/Chromium browser, but I've received several reports of rhythatom failing to play. Would appreciate any help or ideas.

If you look at: https://peterburk.github.io/chordProgressions/ChordProgressi...

There doesn't seem to be any indication of major/minor. One way to interpret that is "always use the diatonic." Which means only use notes in the key, which means chords (1,4,5) are major while (2,3,6) are minor. However songs can have non-diatonic chords.

If you look at Rhyathatom, it defaults to the well-worn 1645 progression - the 6 is explicitly minor, which makes it diatonic. Try making the 6 major and you get a different animal - kind of sinister! That's a non-diatonic chord.

Maybe the author accounted for this elsewhere.

Related: https://pypi.python.org/pypi/idgen/0.0.1

That's one way to ensure safety of domain names, at the cost of mnemonics ;)

I used to think like that. But consider two things. The capabilities of the state actors are high. They cooperate with chipmakers and OS makers (or subvert or hack them). They compromise routers and hard drive firmware. Second, Kaplan's book documents multiple waves of cyber-fear in the US government; multiple US presidents starting with Reagan have tried and failed to secure our vulnerable systems. Simply put, corporations are not going to let NSA dictate security practices to them, because they need to make money and can't spend all day on security. Similar problems occur in military/government.

Remember how cannons made castles obsolete? We're in a similar era, where offense is outstripping defense.

Consider stuxnet. You have to assume Iran, which is smart enough to make nuclear weapons, took its best shot at securing that air-gapped network.

I think you have to accept that hoarding vulns is the international reality and difficult to change. Maybe a cyber-SALT treaty could change it.

Yes, Kaplan's book touches on the silliness of the term (it was consciously borrowed from William Gibson) but policy makers and advocates seem to use it in discussion. Of course there are more impressive terms when needed, like "Information Warfare".

Seems like it's trendy to hate the NSA. It gets conflated with an anti-authoritarian mindset. I wish smart people would gain some perspective - I got some by reading Bamford's books and a new one by Fred Kaplan - Dark Territories, about NSAs painful move to cyber. Some key points:

* All the great powers have NSA equivalents. Meaning they play offence and defense in crypto, RF, and cyber. We (USA) can impose restrictions on our NSA but not on anyone else's. Our exploit-riddled networks are a playground for American, Russian and Chinese cyber warriors - and probably many others.

* In cyber, offense and defense become the same. Kaplan's book covers this. So a smart country seeks cyber-superiority. The more we hamper NSA, the more we empower foreign cyber-warriors.

* The focus has moved from RF to cyber. Giant antennas are far less important and giant datacenters are the new stars. Vacuuming up packets is less alarming when you understand we've been vacuuming up radio and telephone signals for decades. When comsats were important, NSA was vacuuming up their downlinks. When international telegrams were punched on paper tape, NSA's predecessors picked up the tape each day.

* The US has tried going "NSA-less". It happened in 1929 under the slogan "Gentlemen do not read each other's mail". That noble slogan led to the US operating at a disadvantage in the lead up to WWII. It doesn't pay to fly blind.

* Fear of an overreaching state is always justified; however we should focus that fear more on how NSA shares data than how it acquires it. For instance fusion centers: https://www.eff.org/deeplinks/2014/04/why-fusion-centers-mat...

This story reminded me to clean up a very different synth and put it on github:

https://github.com/wildsparx/synthem80

Unlike NSynth, synthem80 is directed to a specific and humble goal - make early 80s-style arcade sounds. It uses a mini-language to control an engine similar to that in Pacman.

For instance, the sound when Pacman eats a ghost:

    ./synthem80 -o eat-monster.sw 'timer(t=0.5) wav(wf=1 f=2 a=45) add(a=< b=48) nmc(wf=5 f=<)'

I guess I phrased that wrong - I think server candidates should know vi or emacs. No need for both.

I'm at shopkick. We're a mobile app. We hire server, Android and iPhone engineers, but many will move across these platforms. We look for smart generalists. So, although we use Python on our servers, we don't expect server candidates to know Python.

Advice for senior engineers: brush up your practical programming. If you've been in an architect/leadership role, you may be rusty. Make sure you're comfortable on both whiteboard and keyboard.

If you spent the last 5 years writing iPhone apps, we expect you to know iPhone development pretty well. Memory management is the obvious area here.

Be ready to explain the most recent projects on your resume. Think outside the box - if you wrote code to process messages from a black box, how do you think the black box worked? If you consumed JSON messages, how much can you explain of JSON and JSON parsers? Many projects are so narrow in scope that we can't have a meaningful conversation about them, so be prepared to broaden into adjacent areas.

Advice for new grads and early-career engineers: have some solid, non-trivial code on github (or equivalent) and make sure we know about it. Be prepared to discuss it and explain design decisions. Few do this.

This post is my take on the question - what follows is especially subjective and not representative of shopkick:

Don't put stuff on your resume that you don't know. Or, brush up the skills featured on your resume.

Learn a scripting language, especially if you're a server engineer. People who only know Java/C++ are at a big disadvantage if they have to write code in an interview. How big? Turning a 5 minute question into 35 minutes is typical - and it gets worse. One very smart, very experienced man took 45 minutes on such a question. Of course, don't just port Java idioms to Python; learn Python idioms. Good languages are Python/Ruby/Perl. I think a HN reader probably doesn't need to be told this, but just in case. Properly used, scripting languages teach techniques which carry over to compiled languages.

Server engineers should be comfortable with either vi or emacs. And with basic Linux. Personally I find it astounding that a server candidate would be unfamiliar with ls and cat, but it happens.

I hope this is helpful and doesn't sound arrogant.

One aspect we shouldn't overlook is stratification by intelligence. People of very different IQs have trouble communicating. So, "hateful repetition of populist punchlines" is a natural form of communication for average-intelligence people - to say nothing of below-average.

Now, the loudest, most visible fraction of any political group tends to be the stupid.

So your conversational Utopia needs some kind of poll-test at the entrance.

I think that an educated gentleman of 150 years ago wouldn't be annoyed at the ignorant opinions of a servant, because they were of two different worlds. Today with the spread of literacy and erosion of class distinction, these different levels of discourse are forced together.

Shopkick | Redwood City CA, Seattle, Toronto | iOS, Android and Server Engineers | On-Site Full-Time | INTERN VISA

We're a well-funded post-acquisition startup providing a mobile app to millions of brick and mortar shoppers. Our app helps shoppers save money and discover products, and helps brands and retailers reach shoppers.

Our main office is in Redwood City, between Palo Alto and San Francisco, right next to the train station. We're in a downtown area with lots of coffee and restaurants.

We're looking for iOS, Android, Server and Data engineers.

Our interview process is a phone screen with an engineer and a day of on-site interviews. I think we generally prioritize intelligence, culture fit, and communication ability over domain specific knowledge; however we obviously expect a senior Android dev to know a lot about Android. If you're experienced, expect a deep discussion about something on your resume.

Server Technologies: Python, Pylons, Thrift, SQLAlchemy, MySQL, Redis. For Data: Hadoop, Scala, Spark, Vertica

Ping us at [email protected] if you're interested.

My Dad had a Vector in the 80s - learned a lot from it. It had a big reset button on the front, which instantly booted into the "monitor" - a program which let you inspect and disassemble RAM. (RAM was not erased in the reboot.)

You could, of course use the monitor to disassemble the monitor, which was a good way to learn assembly language.

Later I wired an Atari joystick to the machine - it had some kind of GPIO pins. It was a very hackable platform, with S100 slots, tons of space inside, and lots of DSUB cutouts on the rear panel.

Wrote several video games in Z80 for that machine, although graphics were limited to TRS-80 style 6-pixels-per-character.

Later I found out that Disney Imagineering built a loudspeaker monitoring multiplexer around a similar S100 computer. It allowed a sound technician to remotely choose an amp output to monitor. I wonder how many other cool applications these machines enabled.