I'm currently awaiting delivery of components to assemble an ErgoDox. The later variations show here display an encouraging similarity to a lot of the ErgoDox's features, although perhaps most interestingly a move away from independent positioning of the two halves.
The ErgoDox is really the two halves of a Kinesis flattened.
Keyboard.IO is a little bit different. There's a splay of a few degrees between the columns that map to each finger. A bunch of the work you do with your pinkies on the ErgoDox or just about any other keyboard moves to your thumbs. And yes, it ended up as a single keyboard. I really, really wanted to do something that was two separate pieces. Between the risks it would add to the mechanical design and the fact that I found myself intensely frustrating that the two halves of the ErgoDox were never in quite the places I expected them to be, we've decided to run with a single-piece unit, at least for the Model 01.
It's been years since I've seen it, but I remember a hilarious scene where Jack Bristow is talking to someone in an IM-like window; his choice of text is giant red Comic Sans and his messages are devoid of grammar and punctuation.
You could argue that this is typical of the average IM user in the early 2000s, but it seemed incongruous for the character.
Create commits using `add -p` up to the point that the current state of the work tree is fully committed. (You can `reset HEAD^` if you need to add some stuff that you do not want to become part of your branch's history, at least not in its current form.) Then test using run-command-on-git-revisions[1] on the new commits.
This lets you create multiple commits at the same time and run tests on all of them. You could argue that committing and resetting is effectively the same thing as stashing and popping, but I think the benefits of being able to iterate over a list of commits and test each one is worth creating additional commits that you will probably reset shortly after testing.
This is also what you should do after a rebase to test all affected commits as they have not neccesarily existed in a testable state in the work tree.
I think there is selection bias, but in the other way. Web programmers, as your typical HN goer sees them, probably tend to underestimate just how many other programmers there are out there, particularly doing Java work.
Beneath the bleeding edge of "what is cool" and "what cool companies use" there is a very large iceberg of people and companies doing/using things that stopped being cool a decade ago.
Well, it looks like the overwhelming majority of web programming is done in PHP/ASP, so I guess it's not the case so much for web developers.
Although I'd be amazed if Go won over a significant portion of the PHP/ASP crowd, given that they have already self-selected out of using Ruby, Python, etc. for web development instead.
I suppose you could argue that Go is a good fit for PHP/ASP programmers who have really tuned their applications for performance, but I strongly suspect they're a small minority.
If you are using a DSLR in burst mode it probably won't choose a variety of apertures and shutter speeds. It will determine what it believes to be a correct exposure for the scene and set an aperture and shutter speed it considers appropriate, if the shutter speed and aperture change they will probably only vary relative to each other; the exposure will be the same. You can do something similar to what you've described by putting the camera into auto exposure bracketing mode where the camera varies shutter speed to give a predetermined degree of over or under exposure per shot in sets of three (or more) shots. In the somewhat unlikely event that your camera was unable to sufficiently capture the dynamic range of a scene you can merge multiple photographs of the same scene with differing exposure values to produce an image with greater dynamic range that can then be compressed through tone mapping.
If you don't think "playing with fstop and shutter speed by hand" is only worthwhile for "art shots or action shots" then why bother framing a shot the way you want it? Decisions about aperture and shutter speed affect more than just exposure.
