daragh

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.

This is gorgeous.

If he liked Hitchhiker's Guide and Kurt Vonnegut, you should give him The Sirens of Titan.

https://github.com/harukizaemon/hamster is apparently quite good.

Ah yes, the day we sold our bus.

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.

[1] https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...

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.

I think many (if not the majority of) programmers are still using strongly typed programming languages.

That FIFO temporary file is the file descriptor of the subprocess' stdout. You're accessing it through a pipe.

It's most useful when you want to diff the result of multiple commands, e.g.: diffing the contents of two directories:

  $ diff <(find /first/path | sort) <(find /second/path | sort)

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.

I'm not too sure how useful the DoF preview feature is, in what common circumstance do you recommend I use it?

Also, you shouldn't restrict yourself to the centre AF point; focus-and-recompose will produce blurry images if your depth-of-field is shallow. You should learn to quickly select an appropriate AF point when composing your shot.

That's a pretty solid butchering of the design of daringfireball.net

The other point I made was that even if they were offering "green" VPSs it doesn't mean they're going to have a "green" and "non-green" power cables running in to the building and they put your VPS in the rack hooked up to the "green" one. They`d probably just do exactly what you can do yourself, pay someone to offset the environmental cost.

One of the main things about purposefully choosing "green" companies, often at increased cost, is that you are influencing the market based on your preference. Choosing environmentally friendly products encourages companies to offer them (I also appreciate that this is why many abuse the term).

Furthermore, if you wish to brand your site or company as "green" you should probably do a little more than choose a "green" VPS provider lest you further obviate the term.

In all seriousness, that's retarded.

If you honestly want to be "green" you can make changes to your personal behaviour (such as using CFLs, recycled packaging etc.) and not rely on some company to hold your hand and make you feel like you're making a difference for a little extra cash.

I personally tend to lose respect for companies that try to upsell their "green" options, much in the same way I am dubious of extended warranties.

I also hope you realise that even if they were to offer a "green" option it probably wouldn't mean they're going to stick a windmill on top of their colo, they'd just use your extra cash to offset the environmental cost of the electricity you used, much in the same way you can.

Don't get me wrong, I a happy Slichost customer and have made efforts to recycle and use public transport for the environment's sake since I was a child, but this recent rash of "green" buzzwording really ires me as it seems to be used in a most insincere and vapid manner, instead of people actually taking a rational, pragmatic approach to environmental efficiency.

Pen & paper for rapid prototyping, then start mocking up with actual code.

This isn't 1999, you'll save yourself a lot of trouble than messing around with Photoshop layers.

If you actually begin coding well from the ground up the application of design will be far more natural and agile than if you were trying to slice up a psd.