Ruby VS Smalltalk
A little better on my reading queue for this week’s highlights. I think the most interesting post (of course from my absolutely opinionated view) was the Uncle Bob’s keynote talk at this RailsConf 2009. I always enjoy to hear interesting pieces of computing history and Uncle Bob is clearly a skilled storyteller. It must be fun (and also sad when you realize how old you are :) to write talks adding pieces of your personal history. What killed Smalltalk? It was too easy to make a mess. But also: image without source files, not free, competing implementations. Also a wrong attitude: Smalltalkers thought their language and tools were so good that they don’t need to be compliant with the typical corporate IT infrastructure. The presentation is a concentrate of great thoughts. What is clean code? Is code that reveals what it does by reading it. If the WTF/min is != 0 is not clean. Ruby risks the same because it’s powerful. What can we do? Craftsmanship. Leave the campfire cleaner than you found it. A collective effort to maintain the code clean should save also the most powerful and risky language. Good start tdd: has infiltrated the ruby culture much more than it did with smalltalk.
Kent Beck - To Test or Not to Test? That’s a Good Question.… I also don’t test for specific cases. When I don’t it’s because I’m missing the skills to test effectively, that is, in an easy and consolidated way. Let’s take Rails view specs with rspec. I know how to spec them out very quickly, mocks, render directives and so on. Almost a no brainer. But there are other cases where it takes me a long time to figure out how to mock certain APIs, what methods should I call and how to organize the spec suite. So my rule became: if it’s taking too long or it’s too complicated fork a new task to spike and learn about it. But now ship it! It’s brutal I know but usually that’s the correct thing to do. Of course the meaning of “too long” is strictly project dependent. Then I put shame on me because I was missing a “tool” in my tool set so that next time I can’t be taken by surprise. I know I need practice.
Introduction to Wolfram|Alpha by Stephen Wolfram… This is the screencast that introduced me to the work of Stephen Wolfram. Wolfram Alpha is an incredible piece of software, capable of correlations and interpretation beyond what I’ve seen so far. I’m wondering what kind of semantic engine is behind the web interface. This engine is capable of attaching meaning to the human knowledge and serve it at the speed of light. Google killer app? Nah, I don’t think so. What you see on Wolfram Alpha is opinionated, a mash-up of related information that the engine thinks you may like. Wonderful if you want to infer knowledge from data you don’t know about, less useful if you know what you’re searching for. That’s what Google is about when you input some words in the search box. Will it change the way we use the web? Again, I’m skeptic.
Cellular automaton - Wikipedia, the free encyclopedia… Looking at the WolframAlpha phenomenon I ended up wandering wikipedia reading about cellular automaton. I’m amazed by how complicated a model with simple rules can be. Very simple CAs like the monodimensional rule-110 are even turing complete. I also realized that the Langton’s ant and Conway’s Game of Life are to popular implementation of CAs. Some of these models are often seen in nature (predators, chaotic systems, population models etc.) and therefore is tempting to think that a basic combination of simple rules is responsible for biological life. What are those rules is the subject of Wolfram’s book “A New Kind Of Science” which is already in my Amazon basket.
Episode 134: Release It with Michael Nygard… Sad: the book is standing on my bookshelf and I never managed to read it. Good: this episode remembers me what I’m missing. First: my knowledge of production systems just scratch the surface. For some reason in my career I always move when the system starts its life and that’s not good. The podcast follows the book structure which is a nice to read patterns collection. Here’s some interesting bite of the conversation. A system that self-adjusts or shuts down a specific feature when a functionality doesn’t behave as from the SLA is better than timeout. Timeout usually creates more dangers. Ajax completion on key strokes is of low value and high server impact. I don’t agree with this one, it depends on the application if this is low value. Caching can be good, but too much caching or caching done wrong can be dangerous. SLA inversion anti-patter: forgetting that SLA of dependent systems are correlated to the SLA of the main system. And much more. Recommended listening.
5 months ago