I’ll add that I’d never work for a military contractor, which google, at the latest since the Acquisition of Boston Dynamics, most certainly is.
(I’ve been poked once by a google recruiter some years ago. I’m not sure I am google material, though.)
When I’m out of options on what to cook for lunch (which usually is on the quick side of things anyway), I usually have some Pasta left somewhere in my drawers. Pasta sauces can be a lengthy affair (If you have never done that, you should try a real homemade bolognese sugo, which ideally cooks for a pretty long time), but this one is really quick, and I usually do them freestyle. I tried to remember what I did this time, because it was extremely tasty:
- Put a generous amount of olive oil into a small pan on medium heat. The ingredients are supposed to swim in oil. Remember: Olive oil = good fat.
- Add Finely chopped garlic to taste (A good rule of thumb is one clove per person). I messed this up and only chopped it into slices, which works, but small pieces is better.
- Add dried chilies finely chopped or broken, also to taste. As this is largely dependent on your taste AND the potential of your chili, I can’t seriously give you any recommendations here
- Let it simmer for some time, so that the garlic is cooked, but not brown
- Add a tea spoon or two of tomato paste. It won’t easily dissolve, but that will be fixed later
- Add some dried herbs. I used home grown oregano, I assume basil would work as well
- When the pasta is done, add 2-3 table spoons of the pasta water before straining the pasta, this will dissolve the paste and bind the whole thing together. Add a bit of salt.
- If possible, pour the strained pasta directly into the pan and give it a good stir so that the sauce is well distributed.
- serve, add hard cheese to taste if you must
- Have some yoghurt ready for eventual dosage errors on the chili side.
Simple, yet effective. That’s why I love pasta.
A trip to IKEA ended with me getting a new version of their DIODER color LED contraption. It’s basically a strip (or, in the new version a puck like structure) with a load of RGB LEDs that are driven by a small and simple PIC based controller unit that lets you either set a color by using a dial or choose between two different ways of cycling through ALL THE COLORS!!!
It’s a fun toy, but since the circuit is so simple (it’s basically power supply, microcontroler plus controls and the LED drivers), it’s also very easy to hack. The end game, of course, is to address each light source (Both DIODER sets contain four of them) individually, but for that you would need a dedicated driver chip. But what’s easy is to remove the PIC microcontroller and the pot, attach an Arduino to the three channels and the PIC power supply and Bam! you can drive the DIODER set with the PWM channels of the Arduino.
The next step was to add the Ethernet shield and to drive the LEDs via UDP. My version of the Ethernet shield unfortunately doesn’t play nice with the DIODER power suppy, so currently I need to have the USB connected, but hey.
I devised the simplest UDP protocol I could come up with and wrote a little ruby script to send some packets.
Next, I used the rosc gem to let the ruby script open up an OSC server. A little test with TouchOSC and a small, three slider control surface was already pretty cool, but as I saw that latency was pretty much non existent with this setup, I wanted to go further.
So I built a little drum pattern with Ableton Live, added an additional MIDI track and painted some rhythmic controller envelopes on CTRLCHG 1, 2 and 3. I then (first iteration) used OSCulator, a pretty cool tool to basically convert every control signal to every control signal to send OSC to my script. In the second iteration, I’ve at least eliminated OSCulator by finally learning me some Max 4 Live.
The effect of RGB strips and pucks flashing synchronously to the music is pretty mesmerizing, I have to say.
The used code can be found in this gist.
I was really happy with the result and also with the fact that I finally started looking at hardware hacking again, even if it was just a small project.
I’ve not been able to research this in depth so far, but it seems as if mobile Safari on iOS7, under unclear circumstances, caches responses even if they are non OK responses.
This is clearly wrong and broke our nginx-auth_request based login system: It renders a 403 error with a (mozilla persona) login button after authentication failed - After login, the user is redirected to the original address and this should trigger a full reload (which would then pass authentication and render the real web page). In our case, it just loaded the login page from cache, which, due to persona’s behaviour, would trigger the login dance, which would redirect to the original address which…you get the idea.
Fixable by setting no-cache headers when rendering out the 403 page, but still pretty annoying.
In Preperation of my Talk at the Railswaycon 2012, I hacked together something I was thinking of for a long time. What if you could let your server render out complete pages (for sake of searchability, for example) and then initialize a backbone collection from that HTML? Your backbone app could then augment the statically rendered page with it’s own magic.
Here’s a gist. I’m going to publish it including examples and tests later on.
I say: F*CK YOU APPLE!!!. The Web Audio API has been available as a webkit patch for something that feels like at least 3 years and is (correct me if I’m wrong) available in stable Chrome for at least a year, or even one and a half (it has been present in beta versions for at least two). Firefox and Google (and even Opera) are innovating the hell out of the web platform and all that Apple does is fixing the most blatant security issues.
So, Googles “Install a modern browser” may be a bit rude, or maybe even cheeky, but it’s not completely unfounded. This all wouldn’t be much of a problem as long as we only talk about desktop browsers because nobody uses Safari there anyway (Market share is really small), but then there’s the whole mobile space with the iPad clearly dominating the space and Apple not allowing other browser engines onto the platform.
This situation actively hurts the web - As much as I love my iPad and and as much as Apple did in the first place to make mobile browsing bearable and popular - But this needs to change.
You’ll have to use conservative spawning mode in passenger to be able to use soap4r.