Easy peasy websockets with node.js and socket.io

With our Web Sockets incubator we had a rough start on Atmosphere grinding through the samples. There is no intention to bash Atmosphere, it looks like an interesting approach. However, it should be a lesson to all aspiring framework builders out there: getting your samples in top shape matters a lot. This week we tried out socket.io and I wasn't too hopeful as I had planned all kinds of things throughout the evening. The result of a 40 minute pairing session with Sonny Gill was pretty good and I'll share the basic highlights here in a very short post.

First we installed node.js and used npm to install socket.io. Next we moved on to create a simple app that exposes a socket on the server. Finally we created a client that opens a socket and sends some test string over the wire.

The code you can find on github as usual: https://github.com/xebia/app-incubator-web-sockets/blob/master/socketio-sample. All in all it is less than 50 lines of javascript and html and it simply works as expected. Not bad for less than an hour of fiddling! In our next session we'll look into the possibilities of streaming video over Web Sockets, or maybe we will look at another framework to see if it performs any more interesting magic tricks. That's all for now, stay tuned!

Posted via email from Xebia App Incubator

Force breakthrough by forcing mistakes

A week or so ago I started to play Math Workout to rekindle my degenerated calculation skills. After a while I got stuck at a certain speed, making no mistakes anymore. I tried to push myself to go faster, but without making mistakes but that just didn't work. Then I tried a different approach: I forced myself to go fast, mistakes or no. After a couple of sessions, I went back to making no mistakes and to my surprise I was around 8% faster. I have a theory about why this is and I'm applying it to life without hesitation from now on, so read on if you want to share the fun.

<!-- more -->

What's Math Workout

I'll give you some background on Math Workout first, so you can understand the example. Math Workout is a game that let's you solve simple calculations and times you while you do so. The main goal is to be as fast as you can. For example, on easy level the hardest addition is 8+7 and the hardest multiplication is 4*6 (I'm considering 5*6 easier). Dead easy as you can see. The trick though is that you need to solve 20 of these problems in less than 23 seconds, and I can tell you that's tricky enough because you need to read the problem, come up with the answer and type it correctly in about a second.

What goes wrong if you don't make mistakes

Somehow I got into a rhythm. See the numbers, see the operator, answer pops up, type it. There are probably a few more steps that I was doing unconsciously, but the point is that I was taking a fixed amount of time for each step. Sometimes I found myself breaking the rhythm just before I punched the wrong number and then taking some fixed amount of time again to correct myself. Whenever that didn't happen my time would be between 26 and 27 seconds consistently. Basically I had put a few safety checks in (which I probably didn't need most of the time) that were slowing me down. Whenever I pushed myself, I would occasionally parse the wrong operator, type the wrong number, pop up the wrong answer and quickly revert to the strategy that worked. Once I noticed this, I knew I needed to break the pattern.

Forcing errors

I decided to change the pattern, and ignore the mistakes at first. I decided to ignore the operator check and assume that my brain would be able to pick up the numbers and the operator in one go. I made 5 errors out of 20 questions and decided that I was bad at picking the operator, but it must be working somehow, otherwise I would have seen more in the range of 10 mistakes. I gave myself positive feedback by thinking I was a smart cookie for figuring that out.  I repeated it a few times and saw the errors go down and the times with it, more positive feedback. After a mere 5 runs I focussed on making no mistakes again, and I was below 25 seconds. Mind you, before that, trying for over 50 runs there was no way in hell that I was going to go under 26, my top times were averaging around 27.5 seconds. By forcing the errors I had broken the pattern and found a more optimum way of behaving. Much faster than waiting for some luck would have done.

What's going on here

When you make a mistake you tend to give yourself negative feedback "aww shoot!" and this tells you to avoid the behavior that led to this the next time. When you don't make mistakes and you have a better time than before you give your self positive feedback and reinforce the behavior that led to the result. When you try something new and it doesn't pay off immediately, you will give yourself negative feedback. We crave positive feedback, so we keep on aiming to get that result improving, even if our method is flawed and we're in the wrong rhythm. It's hard to break a pattern that reasonable results but is suboptimal. The main reason here is that when left to it's own self learning devices, the variation in methods goes down rapidly. It takes a conscious effort or a lucky coincidence to break out of the suboptimum. The lucky coincidence becomes less and less likely the more you reinforce the suboptimal behavior. This is caused by a thing called Extinction Burst which is intended to pulls you back into the behavior that worked in the past.

Download now or preview on posterous

PastedGraphic-3.pdf (21 KB)

What's to learn?

It pays off to try things, even if the first results are not impressive follow through for a bit and see if you might just be crossing a chasm and things are better on the other side. I've seen this pattern not only in my own behavior, but also in the behavior of groups of students and teams of software developers. As long as we didn't plot the graph of all possibilities the only way to find out that behavior is suboptimal is to explore and find a better type of behavior. With Math Workout this is easy, because if I can't make the required time my behavior must be the problem. If there is no required time and nobody knows which goals to set (like in Software development, or any kind of creative work really) you can never be sure of what works best until you've literally tried everything. The trick is to find a way to reward yourself for trying the new thing that doesn't relate too much to the old reward of squeezing every last drop out of a poor method.

I'm not saying you should be trying everything right now, but how about trying one thing each week? That would already be a huge improvement for most of us I'm sure.

Posted via email from Iwein's braindumps

Olijfolie

Het is in Nederland niet makkelijk om goede olijfolie te vinden. Als je de spullen van de supermarkt gewend bent, weet dan dat er de gelegenheid is om een ster te winnen simpelweg door het gebruik van betere olie. In deze blog ben ik op zoek naar een goede, betaalbare olie en waarom de beste olie die ik kon vinden niet in de winkel te koop is.

Bij het produceren van olijfolie worden verschillende extractie methoden gebruikt. De belangrijkste factoren zijn de lage temperatuur (eerste koude persing) en de manier van malen waarbij zo min mogelijk de pit en schil van de olijf meegeperst moeten worden.

Deze beide criteria zijn in directe tegenspraak met de kwantitatieve grenzen die het winstgevend produceren van olie in hun greep houden. Immers: hoe meer olie per olijf, hoe goedkoper de productie. Hierom worden latere persingen uitgevoerd waarbij de gemalen olijven fijner worden gemalen en worden gekookt.

Op zoek naar goede olie zijn veel speciaalzaken te vinden die wel prima olie hebben, maar deze olie is duur. 20 euro per liter is de prijs die de olijfoliespecialist in Culemborg bedingt. Ik betaal graag voor goed kwaliteit, maar als het wat minder kan (qua prijs dan) ben ik ook te vinden.

Vriend Tiziano nam mij een halve liter olie van zijn ouderlijk bedrijf in Italie mee. Vriend Guido bracht mij een kruikje olie van het vat dat hij in Kroatie had gekocht. De olie uit Kroatie kan zich gemakkelijk meten aan de producten van Kastelli, en de olie van Tiziano is beduidend beter (smaken verschillen, maar het zegt toch iets).

Even rekenen hoor… Er is olie die in het land van herkomst voor 5 euro per liter (of minder) verkocht kan worden, en beter is dan de olie die je voor drie keer dat bedrag in Nederland koopt. Deze olie komt niet op de markt (in het Italiaanse geval), en al helemaal niet op de internationale markt (in beide gevallen). Voor olie van de kwaliteit waar we het over hebben betaal je in de VS rustig 50 dollar per liter, en in het noorden van Europa is 40 euro per liter ook niet vreemd.

Het aanbod in het land van herkomst (Italie) is groot, maar de prijzen zijn daar zo laag dat de boeren de moeite niet nemen hun olie ter verkoop aan te bieden. De vraag in het noord-westen is groter dan het aanbod aldaar (anders zouden de prijzen niet zo hoog liggen). Het grote gat tussen de prijzen die de boeren in Italië krijgen en de prijs die in de winkels in Nederland betaald word is moeilijk te verklaren.

In elk geval, ik laat de conspiracy theories aan de lezer over, maar als je op vakantie gaat naar een warm land, vergeet dan niet een beetje olie bij een boer te kopen. Wel eerst even proeven hè?

Posted via email from Koken en Eten

Reaction to "Why ORCL was right to sue ..."

Posted via email from iweinfuld's posterous

Forging intelligent Teams instead of staffing Projects with intelligent people

In my experience with consulting and development, project teams (both Agile and traditional) invariably face issues with availability of team members. In one (rather long and messy) talk on craftsmanship Robert Martin came up with an interesting idea that I'd like to explore a bit more. It might actually solve this problem if used in the right way in a large organization. The idea is simple: organize into long term teams of upto 12 people and accept work from different projects as a team.

This is actually the way small development companies have worked for ages, and they have done quite well on it. The problem is that when projects and clients get bigger they tend to turn things upside down and instead of pushing work to teams that can handle it, they start pulling resources (eww I hate that word when applied to human beings) into the project. This process is called staffing.

There is a problem with staffing. People are not resources. The difference between people and resources (think coal, plated steel, money) is that they change based on changes in their environment. This ability is defined by Stephen Hawking as intelligence, and I like that definition. The big upside of intelligence is that it can actually solve problems for you and that is something that typical resources cannot do. If intelligence is the stuff that allows you to come up with solutions, resources are the stuff that you consume to implement them. A profound difference here is that coming up with a solution actually increases the amount of intelligence, whereas implementing a solution always decreases the amount of resources.

If managers pretend that people are resources and projects are black boxes that turn resources into implemented solutions they will get two things: shortage of intelligence and shortcomings in implemented solutions. The shortage of intelligence is caused by the fact that a project starts being about finding a solution and invariably more and more becomes about implementing it. The former makes you smarter (increasing intelligence) the latter dumbs you down (decreasing intelligence). If you only implement solutions you lose your ability to adapt to change, but if all you ever do is adapt to change you might go crazy. There is an optimum between the amount of change a person has to handle and the amount of time he needs to regain his footing, and this is different per person.

This is all well and fine, but how will we get those essential team members available then? I'm getting to it, don't worry.

First we put a team together thinking about a certain context, not a project. Then we let them establish a healthy environment for them to adapt to and increase their intelligence. This causes team members to be available to each other by default. The we let the project managers sell the work to a team, possibly multiple teams. Each team takes on what they are comfortable with but they stick together. Now this chunk of work might be too little or they might get bored with it. Then they take on some more work, possibly from another project, but they keep together as a team.

If a team member wants to leave this is a career move, not a ephemeral thing you can do for a couple of hours on friday if you feel like it. You can't be part time on one team and part time on another. If you want to take on some work you have to convince your team, or make your career move and be gone totally. Now the question of when person X is available to person Y is extremely simple. When they're in the same team they can count on each other. If they are not on the same team they might have a meeting some time. 

This should up a lot of things, I'm looking forward to try it. If anyone already has experience with this approach on a large scale or moving a large development organization into this mode I would love to hear some war stories.

Posted via email from iweinfuld's posterous

The Copy, then Rename pattern for file based integration

This is a blog for those unlucky many of you that, like me, had to solve the file integration problem. Two processes are integrating over a directory, one writes (W), one reads (R). Now the reader picks up a file while the writer is still writing to it. BOOM, R caughs and dies. Sounds familiar? Then read on.

I know I promised a blog on a deadline free utopia, but while I'm chewing over that one I need to jot down this thought. That's what blogs are for right to capture the excess of an overflowing mind?

So back to R and W that can't seem to get their processes synced. How do you prevent R reading that file that W is still writing? Locking will work, but it's clunky and tricky. Looking at the timestamp might work in most of the cases, but it is not guaranteed to work under high load. Can you say heisenbug? So, what can we do.

Well in fact the solution is too simple to spend more than a few sentences on. It is old, battered and scarred, and it will be around for a while in the future. Just Copy the file to a temporary name and then Rename it to its final destination. Maybe I'll include an image later, but you should get the point, right?

Posted via email from iweinfuld's posterous

BBQ experiment: Grilled pineapple

I'm having a barbecue with some Xebia colleagues next Tuesday. When I have a couple of guests over for the first time, I always like to play it safe a little bit, but the following two experiments just seem too easy, so I'll take the risk:

Grilled Pineapple (adapted from Ananas al Forno):

For the original recipe look at this old blog. I don't see a reason why it wouldn't work on the barbecue, and potentially improve the flavor given the right type of smoke. I'm thinking sage should work. 

Marinaded sweet potato

I have no clue yet how I'm going to pull it off, but I've made marinaded carrot shaslic's before and that worked out pretty well, so I'm guessing that it's "just" a matter of getting them done just right and finding the proper marinade for them.

I'll update this post with the story of success or as it may happen disaster after Thursday, if you have any tips, warnings or other first hand accounts please help me out before I make a fool of myself.

Posted via email from Koken en Eten