Reblog

RSpec, minitest, cukes & friends

I followed the discussion on Twitter after David Heinemeier Hansson declared his dislike for rspec and similar testing frameworks. This is nothing new but this time he was pissed off by some code snippet he was working on. I’ve read several interesting answers and the general consensus seems to be that there is not an absolute “right” way to spec-out features. Agree.

I always used RSpec (except for an RR parenthesis I wasn’t happy about) but these days I’m more inclined to go the simplest route, that is for Rails the included Test::Unit and integration test capabilities. Also outside Rails I’m more inclined to use Test::Unit/minitest which comes for free with Ruby 1.9. What is pushing me away from RSpec is the lack of consistency in the DSL release after release.

New keywords are introduced constantly which most of the time are equivalent ways to express the same construct. I think this is David Chelimsky tying to integrate all the good suggestions coming from the community. Although I appreciate his effort, the final result for me is that I struggle to read specs written by someone else unless I learn the new syntax. The other problem is that working on different projects with different RSpec versions I often can’t remember what style I can use. Embellishments to RSpec aren’t for sure a bad thing except when the DSL becomes a moving target and the changes introduced can’t be considered definitive “improvements” but different ways to name the same thing. I’d rather prefer David to be much more opinionated about RSpec, for the good and for the bad.

I have the impression that with Cucumber, Capybara, RSpec and the incredible number of other frameworks we are pushing the need for testing way too far. It’s like we “rubysts” are trying to demonstrate where we can push a DSL for testing thanks to the language expressiveness, which is an useful not business-related exercise. There are of course use cases for all of the above frameworks, but the community effort in the direction of testing frameworks seems disproportionate.

Quick Getting Started with Clojure

Here is a quick list of opinionated links on how to get started with Clojure I prepared for a friend recently. I think it adds some value on top of a standard Google search, especially for beginners, by excluding a few (but very good indeed) advanced resources you can discover later.

• The crash video introduction. If you have a Java background, have a look at the standard Rich Hickey intro part 1 and part 2 intro from blipTV. If you have a Ruby background you could enjoy also the Stuart Halloway’s introduction for rubyists. Having seen both and having both Java and Ruby experience, I suggest you to cope with the Java syntax if you can and watch Rich Hickey first. Stuart tends to compress concepts (both here and in his book, Programming Clojure by the pragmatic).
• If you don’t like watching videos (I like them a lot, but I can’t easily find the right time window to do it) you can start right away writing code with the Clojure Koans. Of all the possible assisted tutorials, the koans format has the best “zero to keyboard” acceleration. In all cases, try not mess around with the Java classpath at this point if you can. In case you feel disoriented about how to install and run the github koans on your computer, read this good koans preparation article, but skip Leiningen and just place the jar suggested from the Github page into the lib directory.
• If you want an offline option, I suggest Practical Clojure by Luke Vanderhart and Stuart Sierra over the older and more practical Programming Clojure by Stuart Halloway. The introductory material in Practical Clojure is very well crafted, including a gentle introduction to the functional programming paradigm shift and a mind-opening explanation of the meaning of state in object orientation. Stuart’s book is for sure another option but also a more advanced step in my opinion, being essential and practical.
• Fully equipped with your introductory material I suggest you to attend a programming dojo. A dojo is a form of collective pair programming with very simple rules to rotate people at the keyboard. The dojo forces you to put the new knowledge into practice and at the same time you’ll get in contact with more experienced Clojure programmers full of expertise to share and make you faster and better. London Clojurians for example are building a simple game with Clojure as a learning tool and meetup once a month. Hopefully you’ll find a dojo close to you, or maybe you can create your own!

How to find ideas for a talk

Here is a quick list of actions to consider the next time you run out of ideas while thinking at the next conference to speak at. I consistently run through the list and usually come out with a fair list of topics. Next step is of course to select the best ones and create the abstract. Each bullet in the list can take a little while to execute properly. Half a day is necessary if you didn’t use the list for a while, but following times should be much faster:

• What you did during the past year? What did you learn that is worth mentioning in a talk?
• If you keep a daily log (I do) look at notes about problems you fixed or things you’ve learned. Anything interesting in there?
• Have a look at other “trendy” conferences in the close future and see what the buzz is all about. Have you worked with the same technology/process stack? Do you think you know enough about it to present yourself?
• Have a look at the past conferences you attended to see if there are topics worth presenting somewhere else and spreading the word
• Have a look at the last past talks you gave (if any) to see if some of them are improvable and still actual
• Have a look at the last article/podcasts/books you bookmarked to see if those topics are worth speaking about
• Have a look at past talks held at the same conference (the one you’d like to submit to) to understand their preferences and skim the topic list

Hope this helps

Ivy Lee and the evolution of modern time management

Just recently I learned about Ivy Lee (not the actress) who is considered one of the first public relations specialist in history. Ivy Lee is considered also the “inventor” of a simple yet powerful focus management technique branded “top 5” in our modern times by Cameron Herold.

The technique can be summarized as follow:

• At the end of the current working day write down the six most important things you should do next day
• Start from the top of the list first thing next working day and stick with it until done
• Start executing the next task only after you finish with the current one
• At the end of the day reconsider priorities and create a new task list

The short sized list forces you to consider what really matters and leave everything else out. It turns out that your main priorities follow the Pareto Principle and you should end up doing 80% of what really matters with those top priorities. What I just told you is the short explanation but please read the more “romantic” full story about how Bethlehem Steel Corporation was able to become one of the largest steel producer in the US thanks to Ivy Lee advices.

Top5 includes a lot of what is used in modern time management techniques like the Pomodoro Technique or GTD. The Pomodoro Technique focuses on sequential execution of tasks extracted from a prioritized todo-today list which only contains tasks worth the capacity planned for that day. GTD contains (amongst the rest) the notion of current/tomorrow (and then monthly. quarterly and life-time) most important achievements. Both GTD and the PT then expands the concept in different ways and directions making it a complete (and complicated) framework.

The simplicity of Top5 is only apparent: it requires a fair amount of self-discipline to list the top priorities and execute them, leaving a lot of room for misinterpretation and mistakes. Teamly.com, a website I discovered recently, gives its Top5 interpretation adding a few features to help you out.

For example a today’s priority can’t be edited after 20 minutes from creation to force you really consider if this is a top priority or not. Of course you can’t create more than 5 but you can create other priorities for the next day, next week or month. In general an user of the technique is delegated the following decisions:

• How big a priority should be
• How to prioritize them
• How to maintain focus on the current task (despite internal or external interruptions)
• How to measure effectiveness in tasks execution

and possibly more. My impression is that Top5 is too easy to execute incorrectly “as is” bringing to early failure. Top5 has very few prescriptions and hence is more an expert tool and a good candidate for integration with other time management techniques.

SC2010 Report

I attended the Software Craftmanship 2010 conference in Bletchley Park and had a great time. A craftsmanship based conference is a collective exercise in clean programming using a lot of different techniques: katas, koans and maybe less esoteric exercises in refactoring and test driven development. This was exactly what I expected and the reason for me to attend. I coded the whole time and concentrated on my craft, tooling and techniques. Here are the sessions I attended.

Refuctoring with Jason Gorman

I briefly looked at the screencast of the presentation the day before and thought refuctoring must be fun and it was. The technique is simple: grab a very simple line of code, like “Hello World” which is fully covered with tests and try to make it a mess! Not easy at all! There are so many ways you can be a bad programmer and we are so used to try hard for maintainability that writing crappy code is excruciatingly difficult :)

But refuctoring is not just fun. It is a real exercise with good overall effects. Since you’re not concerned with maintainability of the code or how to better structure business rules, the focus is just purely on refactoring with all the benefits of recognizing quickly how to clean up the mess you just created. Kudos to Jason Gorman for the whole conference and for his very entertaining session. I know now how to recognize code “smiles” and replacing them with code “smells”.

Designer Code by Chris Parsons

This was the natural continuations of the previous session. After a brief introduction to code smells and related refactoring moves, Chris Parsons of Eden Development fame showed us a completely cryptic piece of code to refactor, probably the work of a Master Refuctor. Code coverage was already in place for the exercise, we just had to solve the puzzle of defining meaningful name and clean up the code. Another very good exercise I couldn’t complete but hopefully is all available here.

Make Mine A Mocker by Neill Pearman

Another interesting way of exercising. This time, Neill created for us a koan based on a cucumber feature set on the path of building a mocking library for Ruby. Following the steps and the tips given, we were required to write enough code to make the scenario pass and move to the next failing ones. I couldn’t get through the end (as almost all the other exercise) but it’s easy to “doggy bag” the content of the conference thanks to GitHub and bring back the koan with you for later enlightenment.

Code Breaker History

After lunch we got the tour of Bletchley Park and of course learn about the important piece of cryptography history that tool place here during world war 2. Alan Touring was head of the first team who architected the Bomb, an electromechanical calculator to exploit the settings of the Enigma machine. What a nice way to spend some time outside and relax before the afternoon sessions!

Robot Tournament by Matt Wynne

I really enjoyed the development challenge organized for us by Matt Wynne. Very simple: create a small program able to play tic tac toe in a tournament with 6 “battle” and hopefully win. I preferred Ruby for my robot but I wasn’t that good :( I managed to win 50% of the battles until the 4th round, then trying to add the new feature I ran out of time. Another useful exercise: adding the time constraint to the mix forces you to think about the best possible solution in the least amount of time. Of course the solution cannot be the best and the focus is exactly this. Release quickly release often is the key to survive in such an environment and developing this kind of challenge you’re forced to think about compromise. Kudos to Matt for his tournament platform available here. I will certainly suggest the game at the next craftsmen meetup.

This week’s highlights

Show #80 Josh Clark, Tapworthy: Designing Great iPhone Apps - The Startup Success Podcast… Josh Clark is not telling us the usual commonplace stuff we use to hear when speaking about what makes a mobile application great. The big picture consists of three mindsets: micro-tasking (repetition), locality (urgency), boredom. I’m on the go when I use my iPhone so I’m micro-tasking to get something done quickly. The application should allow me to get to the final results in just a few quick moves. I’m local, so I expect from the application to localize information and to mix “local” with sensors: visualize what is local, speak to me what is local or tell me what’s in front of me thanks to the compass. We can give new context to the “personal computer” definition of decades ago. Speaking of porting legacy app to mobile, Josh suggests not to just replicate the experience on the phone, but to find what part can be really be mobile. Mobile platforms aren’t just for work, they are cultural platforms, something with a personality.

Show #74 Kent Beck on Lean Startups, TDD and startups The Startup Success Podcast… The “Learn, Measure, Build Cycle” is at the base of continuous deployment. You can think of it as an A/B Testing which takes place ahead of feature completion. The principle is to build just enough software just to get the answer to the business question. Then deploy and measure the results. Capital requirements and risk will go down as a consequence. Capital efficiency for startups has increased to the point that a single person can work to more startup projects at once. VCs of course enjoy this because they can increase the number of startups to fund at a lower cost and increase the probability of success of at least one. Sometimes it’s necessary to take a shortcut and avoid testing. TDD is especially effective for the not well known areas of the application and for parts subject to heavy optimization. The decision to skip testing is not a practice you can take in isolation, it’s an option when it considerably slows down the dev cycle.

The Clean Coder: The Hacker, The Novice, The Artist, and The Craftsman.… Never thought of that in this terms, but the ROI-based model Uncle Bob describes covers a lot of cases. The craftsman is the only category described here that cares about ROI. Wonder where researchers would fit in here. There is definitely some sort of ROI in research, but the time to achieve ROI is different that that of the industry.

Dan North - Deliberate Discovery… Dan North speaks on his blog about what we are missing when we just concentrate on user stories during the inception of a project with the effect of having stakeholders looking at the story backlog, turning it 90 degrees and think of it as a gaant chart. Deliberate discovery means to allocate part of the inception effort to something which is not story description. Learning is the constraint. Ignorance decreases as the project moves forward in a non linear fashion. The skill to improve is how to find which factors in a project (or ignorance axis) are the most effective to reduce ignorance the quickest and take whatever action is needed in that direction along with user story planning. Dan is convinced that this skill is subject to the Dreyfuss model and as such it requires practice and this is why we have the impression we can’t predict what’s going to happen to the project. Of course we don’t have the crystal ball, but we can get better at it.

Herding Code 82: Cory Foy and Will Green Compare .NET and Ruby Development | Herding Code… Comparisons between languages are usually useless or even stupid. I heard a very discussion instead in this PodCast by Herding Code thanks to Cory Foy. First of all ActiveRecord and its SRP violation: in Ruby with mixins and dynamic types it’s much easier to add persistency into model objects. This is probably the main reason why Rails developers usually don’t care. With typed languages instead the amount of code and interfaces required to achieve the same thing is evident and scarier. “Your application tends to model the company organizational structure” so people think that Java apps are more complicated because they model complex businesses. False: Ruby is just so expressive that you don’t need a lot of layers just to make it works. DDD is uncommon because Rails came out from a presentation first approach that somehow permeates into the framework.

Episode 165: NoSQL and MongoDB with Dwight Merriman | Software Engineering Radio… Another nice episode on the nosql db space. I think I’m getting closer and closer to understand what kind of problem nosql dbs are solving. One of the reasons is that the relational model is very easy to understand and intuitive: the transactional ACID properties is exactly what we want to see. I write something and I can read my changes. I move data from one place to another and I expect to see the new data in the right place. And so on. NoSql is just opening to all the shade of grey in between. Data will be eventually consistent is the key: concurrency and availability is embraced. Programmers now have one more task each user story developed: what is the consistency model? Based on the answer, different part of the application can be tuned for different consistency. For example if I am the user making the change I want to see my changes, but I don’t care if others will see in a few minutes. There are many other nuances like this one which are not easy with MySql.

Twitter / Francesco Cirillo: …right now 5 minute… This tweet from Francesco, the inventor of the Pomodoro Technique, remembers me that the 25 mins pomodoro “time” is customizable. The fact that the timer can be adjusted during the day is probably one of the most important aspect of the technique. The pomodoro time should contract or expand to fit the current focus ability. If you can’t focus for more than 5 minutes, then that should be your pomodoro time. The Pomodoro time can be be reverted slowly up to 25 minutes or more when internal distractions aren’t an issue anymore. Pomodoro shrinking accomplishes a specific goal: keep frustration away when we are not able to concentrate and keep on working with satisfaction even when bad mood kicks in.

Gojko Adzic - Thought-provoking TDD exercise at the Software Craftsmanship conference… This article describe a constrained mode TDD where the implementation that makes the test passes is first written directly inside the test, hence without structural plumbing like methods or classes. The implementation moves to classes only with a set of restricted steps. I consider this a good exercise to test everyday assumptions while applying TDD, like right jump to create a class to make the test pass. The need for structural containment is discovered through testing exactly like the implementation details. As someone noticed in the comments, this style leads to a functional style of programming since the first encapsulation of code admitted are methods.

Why: A Tale Of A Post-Modern Genius - Smashing Magazine… A nice write-up about the _Why persona, who he was and what he did in computer programming and arts. If ever had the need to send someone who doesn’t know _why reading something about him, this is for sure a well written biography. _Why is another example (the other being Alan Kay) of person who was inspired by young people for their programming activities, treating them like “customers”. There is definitely something to learn looking at kids while they try to force a system to do what they want. Their naivety is almost impossible to replicate in our adult world but it is fundamental in interaction design. So if you have a kid, don’t miss the opportunity to watch him/her closely while they learn because it’s an invaluable source of inspiration.

iPad Usability: First Findings From User Testing (Jakob Nielsen’s Alertbox)… Hard to believe, but the iPad’s bigger screen poses serious challenges to interaction designers. I’d be tempted to say it’s just a bigger iPhone, no big deal but that’s not the case. On the iPad the text that is big enough to read is not big enough to tap, for example. Another problem that the bigger screen seems to aggravate is the lack of a strong touch interface standard and users get confused on what to expect when tapping. About swiping: should you swipe bottom to top or right to left to scroll? The screen format doesn’t help to discover what on the iphone is evident. Personally I found the same issues on the iPhone as well. For example, a great application like Stanza always confuses me when I try to reach the homepage with the book index. I always end up on the topic list for the current book.

Better Software Conference 2010 Part 1

I just attended the 2010 edition of Better Software conference in Florence. Overall it was a good conference with probably the best italian speakers around. The only problem for “Better Software” was that there was not enough software. Sure, many interesting talks and a lot of great informal chat during breaks. But there was very little code on the giant screens and way too many pictures. Many attendees in the room were indeed coding while watching the talk (there was also a good 50% twitter users typing though). Others were programming outside at the lobby. I hope to see more code the next year, perhaps with a specific track dedicated to languages, programming, tools and techniques. Code examples and live sessions are the most important learning tools for programmers in my opinion and managers should know how to code too! :)

End of the (mild) rant, now the good part. There are tons of smart programmers and entrepreneurs in Italy. I had the opportunity to meet many at the conference and I was inspired in several ways. I met also a lot of young programmers eager to learn and improve their skills. Sometimes you just need to stay away from institutionalized environment (where I used to work) to discover enthusiasm and energy and Better Software succeeded attracting exactly this kind of people. Good job.

Here’s a summary of the talk I attended and some thoughts they provoked. Don’t miss the conference next year, I won’t.

Stefano Sanna - Application store, potenzialità e trappole

Although Symbian sold 80M+ devices, apps created for Symbian OS are not selling that well. With just 2.5M of devices Apple is instead the best seller with 4 billion downloads and 185k published apps. Of course developers won’t invest in a platform that doesn’t sell applications. The conclusion is that the device spread is not enough to succeed if there isn’t a store capable of selling applications. Other interesting fact is that the best sellers are those (like Apple) who sell devices with a mandatory data contract. Without a data plan you can’t install apps directly from the device which is easier than synchronizing from a desktop. Speaking of the two main contenders, AppStore and Android, a surprise comes from the number of downloads per device which is roughly similar for the two platforms. But this is a potentially misleading metric because Android applications can be purchased anywhere, not just from the official store. Many applications sold outside the official channel are thus un-trackeable.

Omar Cafini - Sviluppare e vendere applicazioni per iPhone

Omar is an interesting mix between technical capabilities and entrepreneurship. He runs a couple of events: MarcheIN and 24hrsCamp that remembers me similar initiatives I found in the States. He’s also a programmer and with a few friends he’s running an iPhone development firm, mitapp, that contains already a well rounded application portfolio. Here’s a few points from his presentation about the experience of developing iPhone applications.

• Games software houses have big set of titles on the store, which is difficult to compete against as an indie developer. Unfortunately this means that quantity is sometimes more important than quality in the Apple Store.
• Prefer the team to the single developer more or less for the same reasons as above.
• Think twice before sending the app to the appstore. The visibility effect during the first moments of life is almost non-repetible. In other words the top of visibility is reached at the very beginning.
• The market is saturated with apps at the 0.99$ price target. Again another warning that is difficult to make a living when you’re forced to sell at such a low price.
• Some interesting marketing techniques help to achieve some results if carefully tailored before launching: in app purchase, redeem codes or contest based on redeem codes. Do not forget to reserve a domain and a supporting web site for the app.

Something I also experienced first person that Omar was talking about is the kind of users using iPhone apps. Don’t forget that the iPhone is now more a fashion object than a real instrument for mobile workers. Sad but true, be “stupid” designing applications and contents, because this is the kind of public you’re aiming at. Please be merciful if you ever see me creating a fart app! :)

Leandro Agrò - Una storia di SW dai protocolli alla startup

Unfortunately I wasn’t able to understand what the talk was about. I had reminiscences of Jini (the Java technology) at some point, but I’m not sure. I saw images, videos and heard craploads of buzzwords. I know they are creating (or created) an usb crocodile called iCrocco who remembers “feelings” that can be uploaded to the desktop when connected. Or maybe not. Who knows? Please enlighten me.

Andrea Santagata - Start-up web in Italia. Si può fare

This is the man behind several italian popular websites and services like Splinder. The talk was an objective take on the italian internet market as seen from the startups he is responsible for. Some of them succeeded some of them failed. I really appreciated he was so open about both, a rare example of honesty and sustainable business (he was concerned about employees families). The last “creature” is called Liquida and as far as I can tell it resembles WolphramAlpha for the italian market. Andrea is still waiting to call Liquida a success. At the end of the presentation he just nailed the biggest problem for the success of an internet startup: all citizens should be able to access a DSL connection. In other words Internet should be a government priority and be part of our rights. Needless to say, we are not driving the effort in Italy, quite the opposite.

It is taking longer than expected to re-organize my notes about the conference. I decided to split my report into multiple parts. I’m working on part 2, stay connected. Cheers.

This week’s highlights

REWORK: The new business book from 37signals.… The book by 37signals is not saying a lot of new stuff. But it’s not a surprise. I’m an avid reader of their blog and followers of podcasts and presentations by DHH, Jason Fried and friends and they talk constantly about what was condensed in this book. Nevertheless this is a good reading. First of all is not easy to express what creates a profitable company in a succinct way like they did. Second, I like the format: small illustrated chapters that you can read easily. Of course there was also something to learn. Reading the history and motivation behind the success of whatever human endeavor gives a lot of insight for current projects and the book is full of great examples. Favorites: focus on what won’t change, underdo your competition, four letter words.

markupslicer | Slice your HTML/CSS markup into Ruby on Rails templates… Just a great idea. This service allows you to automate that repetitive action of splitting a web page into functional areas that are then worked separately. This includes also css tags, a time waster every time I need to think a name for a section. I can see it especially useful to extract partials for a Rails application but other frameworks will be supported soon.

Three Rivers Institute  » Blog Archive  » Continuous Deployment Immersion… Nice. This should be called Extreme Deployment and be part of the Extreme Programming practices set. What Kent describes here gives you a method to move the build process to continuous deployment step by step the hard way. Why? Search my other links, there are a few talking about lean startup thinking and when continuous deployment makes a lot of sense: essentially to move the product more close to what the customer wants instead of what you think they need.

What will happen when a software company downs tools for a week? - Business of Software Blog… Here’s an expanded version of what Relevance is doing every Friday. With a week available to create something which doesn’t need to be related with your company current stream of revenue, what will you do? I have plenty of ideas and the fact that your company supports you is nice. But as someone said in the comments, it should probably be expanded to whatever you have in mind, company related or not, open or closed source. In my opinion it is a win-win even if the whole company contributes to open source projects for a week. It’s an huge return of image, free advertisement and word of mouth and not only. What was contributed outside the company will return in as side thinking, new knowledge and ideas. Well done anyway, although it should sounds more like a practice for the long term instead of something to try once a year. Hope they’ll consider this for the time being.

Chariot Tech Cast - Battle of the Frameworks II… An interesting debate. I don’t usually like panels because they are too broad and unfocused. This is an exception but the panel is not interesting for the web framework discussion itself (which is just a little more than a marketing pitch) but for the several unrelated topics in between. JSF is a hostile abstraction web framework because it brings too far away from HTML in a unnatural way. “Successful languages like Objective-C or JavaScript are really abominations”, while framework like JQuery are there to fix ten years old problems of browsers and make it a modern language. CSS flexible boxes, dom local storage and other HTML 5 tricks are not yet organically explained in tutorials to build up complete applications. The TIOBE index is bullshit because it reflects the inability of search engine to return coherent results when the language name is not enough (like Go for example or Prototype that requires an additional “programming” term). And much more, enjoy.

Hacker News | HN Contractors: Add Yourself… A resource of valuable information, like rates and what people are up to for their contracting activity, with emails and web sites. This list helped me understand how to adjust my actual rate and also gave me an opportunity to look at web sites of people I value like the HN community.

This week’s highlights

Here is the summary of my lurking around the past weeks. Probably the Calacanis VS Dhh episode of Twist is my favorite on this set. But also Eric Ries’s interview about Lean Startup Thinking was very interesting. As usual, the link is followed by opinionated summaries. Enjoy.

[FoRK] Programming languages, operating systems, despair and anger… Ah ah, enjoyed this one. There is definitely truth in the rant. Especially the fact that many if not all main stream languages are more written for computers than humans, with some noticeable exception in languages like Ruby or Python. The point to take away from the post in my opinion is that language design should take into account the list of all the common programming tasks listed here. It looks that we need again another layer of abstraction on top of programming languages, something similar to a DSL where the domain is day to day programming for an average application. Good stuff.

I’m quitting the Internet. Will I be liberated or left behind? - By James Sturm - Slate Magazine… An interesting reading with thoughtful comments. I went information diet myself and from that short 15 days experience I understood a lot about my mistakes. I also realized that the all-or-nothing is not a solution. I need and I enjoy to keep up with the Internet buzz. But I understand who needs to quit completely, at least temporary, to understand where the limit is, as in this blog post.

Episode 159: C++0X with Scott Meyers | Software Engineering Radio… So even C++ gets lambdas, type inference and power support for concurrency (along with the other features added in this last re-incaranation). As I heard already a few times, Java is apparently dead. When lambdas will be included in Java most of the developers will be already using Scala or Groovy. The JSR is a remarkable high ceremony process that forces people to create their own flavor of Java with the features they miss the most.

Daring Fireball: New iPhone Developer Agreement Bans the Use of Adobe’s Flash-to-iPhone Compiler… Maybe not only Flash. What about MacRuby? This is an high risk move from Apple. True, they can protect the quality of the product and avoid third parties to create tools that can compile down iPhone, Android and other platforms at the same time like Titanium. On the other hand, other languages are more expressive and maintainable than Objective-C giving iPhone app a quality boost. Although I’m developing iPhone in Objective-C it sounds to me like nonsense. I’d like the option to use the right tool for the job and maybe Objective-C is not always the right tool. I’m worried that Apple will stop the MacRuby team on working on an explicit garbage collector, thus preventing MacRuby to run on the iPhone.

TWiST #46 with David Heinemeier Hansson… Here we go. Every once in while there is something you can’t miss. Two interpretations of capitalism (or maybe just one is and the other is not): the one that Calacanis defines old school and maybe European is in my opinion the new school or the anti-american school. David explains perfectly well what the differences are, but I think it all comes down to the presence of an upper limit. With no limit, the model is to raise money and move to something else to raise possibly more money, often by creating a bubble of expectation and excitement made of meaningless metrics. The other way (David) gives less prominence to money accumulation and more importance to searching the best idea to implement, an healthy life style and real profit. Overall it means doing business with the idea that when your income is enough to afford everything, there is no need to raise more money just because you can. With a nice side effect: better wealth distribution overall.

danieltenner.com ‚Äî How to¬†nap… Glad to see I’m not the only exercising how to nap. It also took me some time to get to the point where I’m now. My experience is very similar to the one described in this post. I still use sometimes white noise tracks from 20 to 30 minutes based on the mood of the moment. And yes, never ever go over 30 minutes, or you risk drowsiness as described here. Something I’m doing lately after the muscles relaxing focus part, is to focus my thinking to someone walking and just visualizing the legs and almost nothing about the surrounding of the scene. Sometimes it takes some effort, but apparently it puts the brain on some useless thinking that removes other thoughts and prepare for napping. At least, this works for me!

Show #49 Eric Ries, Lean Startup and product/market fit ¬´ The Startup Success Podcast… You should really listen to this one. Eric is great explaining what this is all about and I very enjoyed his clarity. The relation to acceptance tests idea is mine though. So: continuous deployment + production cluster + revenue metrics and an automatic halt and revert system for production is the recipe to drastically reduce the importance of acceptance testing. The scary part is that we are accepting and embracing the fact that bugs will make it to production even if we fight them hard (it will happen anyway). By gradually deploying to a cluster if there are bugs only a small portion of our customer will find out. The presence of a “revenue” metric will trigger the revert button automatically, reducing the loss to the bare minimum. By accepting the risk of some bugs passing to production we can leverage a very tight customer feedback loop and learn very early how to change direction to achieve market fit. This works well for startups, where the kernel idea need to be validated ASAP.

QR Code - Wikipedia, the free encyclopedia… Thinking seriously to place this on my business card. Slick and if you have a modern phone, readable!

Emphasized Insanity - Using Sinatra to test remote services in Rails… In my last project I had a lot of stubbed request response to stub out web services like S3 or MTurk. I did everything by hand and it was not difficult, what is difficult is to reproduce the call and dump the raw response when you realize you need just another slightly different test case. For the next time I’d like to user something like FakeWeb or this Sinatra server built on top of it. Recording and storing should be much easier and repeatable improving the maintenance of integration tests with stubbed web services.

Billable Pomodoros

So you are ready to start the next project and you are a freelancer and a good Pomodoro Technique practitioner. Of course all those tracked pomodoros are a good source of information for billing. But how the pomodoro should be converted into time and then into money on the bill? My rule of thumb is the following:

1P ~= 35’

The math behind the equation assumes that breaks related to the technique are part of the job (a very important part indeed). If you take more or less 5 minutes short break and a long break of 20 minutes you have 140 minutes every 4 pomodoros which are exactly the 35 minutes shown above.

There are great days and there are bad days, but let’s say you’re a 12P/day kind of guy. Twelve pomodoros is 7 hours (I know the very last long break is not included but as an average I don’t think it’s important). If you have an hourly wage of 40$ and 12p is your daily average for a month, you’ll charge ~5600$ to your customer. Just an example. If you prefer to bill days of work, then is up to you to decide how many pomodoros make up a day.

The interesting part of making pomodoros a billable unit is the high quality of the work sold to the customer. If you bill pomodoros and the customer is able to understand the technique, they can be sure that what they receive is high quality, focused work that can be tracked down to the single 35 minutes unit (if you keep the history). With tools like Pomodori this is plain easy.

Would you agree with my conclusions? What you would do differently instead?