“[...] plans are useful, in the sense that they are proof that planning has taken place. The planning process forces people to think through the right issues. But as for the plans themselves, [they just don't work in practice]” – from Made To Stick by Chip and Dan Heath

This provides a nice answer to the odd notion that being agile is an excuse to do away with all planning. It explains the intuition that planning itself is useful, even if plans aren’t.

I’ve only just started reading that book, but odds are good that there’s plenty more gems in it like this one. Thanks to Glen Lipka for the recommendation.

PS: I had to cripple the quote a bit, especially at the end, for it to make sense outside of the book’s context.

As a recent example, I just clicked on this particular link: http://yuilibrary.com/theater/nicholas-zakas/zakas-architecture/

I found that link in a post elsewhere. When I click on it, I’m getting redirected to this page: http://yuilibrary.com/theater/

That’s not what I was looking for. To add insult to injury, when I search for “architecture” in the search field on that page, the first result is exactly the same, that I started with, again redirecting me to the latter useless one. And no, I’m not going to page through 10 pages looking for that one video, f*** you very much. (PS: YouTube channel search worked)

Speaking of redirects: If you own some smartphone, you may be aware that certain websites redirect you to their mobile site once they detect that you’re using a mobile browser. For example, when you open this link on an iPhone or Android phone: http://soundcloud.com/bassistance

You end up here: http://m.soundcloud.com/bassistance

But when you open that mobile specific page in a desktop browser, there’s no redirect happening, that would bring you back to the non-mobile page. There’s only an opt-in, as with many mobile specific pages.

At least the Mobile SoundCloud page also works on desktop browsers, but there’s a lot worse examples. Amazon for example gives you only a very crippled site, so if I share an Amazon page from my smartphone with someone, they end up on that same mobile page, lacking 80% of what Amazon normally has.

Mobile YouTube just screws it up completely. Whenever sharing a link, you end up on the mobile front page, loosing all context you had.

I’ve got one more. Mozilla, not exactly on the evil side of the web, can of course screw up redirects just like anyone else. In this case, I attempted to open this page: https://developer.mozilla.org/en/aria/widgets/spinbutton

What I end up on is this instead: https://developer.mozilla.org/de/

What’s going on? Even though my system and browser is set to English, I’m getting redirected to a german site. I didn’t ask for that, and worse, it looses the deep link, as it redirects to the start page, not the one I actually wanted to open. So is it my fault for having added “German” to my list of preferred languages in my browser, as I need that for a specific project? Even though its set with a lower preference then English? I don’t think so.

So please, the next time you implement a redirect, think! Thanks for reading.

Alhazen, Rasputin, North Korea, Meta Humor, HR Exploitation++, Security Trolls, Introduction to JavaScript unit testing, Advanced JavaScript Basics, Things we don’t know, Node.js and cooperative multitasking, Chevelle, Silversun Pickups, Favorites: Opeth, Favorites: Tool, Favorites: King Crimson, Scala on Google App Engine, Automated Testing

17 in total, with anything from music recommendations to tech stuff to articles about certain figures. Oldest from 2009, newest from just now.

Based on that, anything you’d like to see published? Something you’re interested in? Pick any three!

To start, a Funk Jam Mix with Gerrit and Uwe.

Up next, a never finished song, for some reason filed as “radioedit”, there’s just drum and bass, Uwe and me:

This is an odd one. As far as I can remember, some VST drum computer, where I just changed patterns here and there, plus VST-based piano with some custom bass. Whatever.

Last but not least, a version of Pour Me A Glass, with an oldschool Remaining cast.

That’s it. Whatever comes next is going to be some new recordings. Hopefully sometime this year…

To bring those back to life, I’ve replaced them with the new html5-based SoundCloud widget. While I’ve got some more to upload, I’d like to share something for the time being.

There’s the Roaring Hamster session, which resulted in a set of four tracks, with one longplayer. If you’re reading this on the site, the set widget should show up below:

A very different beast was “Die Gesellschaft des Elefanten”, consisting of multiple sessions. The jammix higlight is below, the rest inside the original post.

Put away your high expectations and give it a shot!

Female crickets locate male crickets by the sounds they make. However, the head of a cricket is too small to locate the sound by measuring the time difference between the incoming signals.

So how does the cricket locate sound?

It does it by “hardwiring” movement and sound recognition. Basically that is: If a sound reaches the right ear, a movement to the right is triggered. After that the system sleeps for sometime. Same for the left ear.

This makes the cricket move to the target in a zick-zack kind of way.

This exact behaviour has been implemented in a robot already: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.1665&rep=rep1&type=pdf

The robot cricket is pretty cool:

A bit larger then the average cricket though.

Another update from Gerd (via G+):

 I found it in the book “Die Entdeckung der Intelligenz – Können Ameisen denken?” by Holk Cruse, Jeffrey Dean and Helge Ritter. Unfortunately there is no English edition, as far as I know. The book contains quite a lot of examples of robots simulating animal behavior (they are called Animaten in German). The special cricket robot itself was mentioned in another book, though, but it seems I gave it away. And unfortunately I can’t remember it’s title.

Rereading the according chapter I unfortunately have to correct myself: Crickets have a special organ that physically measures the difference of sound pressures directly. Basically by allowing the sound to reach both the eardrums from both outside and inside, which makes the ear one organ with two eardrums and four entrances. One entrance leads to the front of the right, another to the front of the left eardrum, like for us. But an additional entrance leads from the right between the two eardrums, and yet another does the same from the left . The principle is called “coupled eardrums”

However, for crickets this is limited to a very narrow range of frequencies (that of male crickets, of course). It’s a very special solution. But frogs apply the same mechanisms to a broader range of frequencies. There’s a small paragraph on this in the Wikipedia article on sound locating: “Ho showed that the coupled-eardrum system in frogs can produce increased interaural vibration disparities when only small arrival time and sound level differences were available to the animal’s head. Efforts to build directional microphones based on the coupled-eardrum structure are underway.” The article mentions flies as using this system, too, so it seems to scale very well

Now you know!

To start, sound travels 1235km/h or 343m/s. The latter is more useful for the upcoming calculations, so keep that in mind. Let’s say the distance between your ears is about 20cm, or 0.2m. Depending on the size of your head, its likely a bit less, or even a bit more. If sound travels 343m/s, it would take 0.2m/343m/s to travel from one ear to the other, so 0.58ms. In other words, half a millisecond is all we need to figure out from what direction a sound is coming, as that’s the maximum delay for a sound coming from one side to reach the other ear. But we can also locate sounds coming from front-left or front-right and inbetween, so we need even less then half a millisecond to locate a sound.

With that in mind, let’s take another look at sound under water. According to Wikipedia, sound in fresh water travels with 1497m/s, in sea water even 1560m/s (at certain temperatures etc.). That’s 4.3 and 4.5 times faster then compared to sound in air. So our location hearing precision would have to be four times better to locate a sound under water, or need need some workaround that delays sound from reaching the other ear, depending on the direction.

Based on my experience with audio recording on specialized audio hardware and drivers, we usually have to deal with latencies of about one millisecond. Which is great for audio recording, compared to 100ms to 300ms that regular audio hardware and drivers get you, but way too much for the underwarter locating device. So we’d probably need a hardwired solution that could work with much lower latencies. If 0.58ms is the maximum we can deal with, half of that might be the lower bound, so 0.29ms. To adapt that to the 4.5 speed increase in salt water, we’d need a precision of 0.0725 milliseconds, or 72.5 microseconds. Considering that computers can measure in nanoseconds, that should be plenty for some optimized hardware.

On a somewhat related note: Consider a coordinate system with a single axis, x. You can position points anywhere on x. That’s what stereo sound is. Add another axis, y, and you can position a point on both x and y. You’ve got two dimensions. That’s what’s sold as “3D” sound. To get actual 3D, you’d have to add another axis. I haven’t ever seen any setup that has actual three dimensions. Why is that? Maybe because we’re not that good at actually hearing in three dimensions, as we’ve got only two ears?

So much for my two cents of anecdotal evidence on the topic, the Sound Localization article has a lot more actual detail (but also no fancy images). For some fun images, take a look at this (archived) page.

As far as I can tell, there’s not much of a drawback for adding that plugin. It just adds a few meta elements, based on content that’s in the html anyway.

The model I wanted to is an ATST, originally created for my Domino Star Wars project.

I had the model exported as a 3DS file, which I then imported into Blender, scaled down a bit, then exported to Three.js’ ASCII JSON format. Figuring out how to use the Blender plugin took a bit of digging (documented into a new readme). From there I took one of the existing examples and replaced the loaded model with my own. And tada, a rotating 3D ATST, in your browser, if it supports WebGL

3D ATST demo

If that doesn’t render for you, here’s a screenshot:

This isn’t all too interesting yet, but an important first step.

For more WebGL resources, see my WebGL Links post.

• There’s a WebGL specification, and as usual, its intended for implementors of the spec, not for users of the API. Though at least this spec as actual usage examples, so if you’re looking for a specific detail, this could be a good last resort.
• An okay Getting Started tutorial let’s you render, BEHOLD, a square. It makes use of vertex and fragment shaders, making the whole thing fairly complicated, but hey, its hardware accelerated and you’ll learn a lot of the low level basics.
• A lot more resources can be found on Planet WebGL, there I just found this cool X-Wing demo.
• Another site decicated to learning WebGL, The WebGL Cookbook.