Ruby on Rails stack on Mac OSX keeps crashing while RVM looks ok (both 10.68 and 10.7). A fix.

My Rails App, set up to run on RVM with all the right gems, kept crashing. To fix it I had to rearrange my environment, and reinstall the entire stack.

I recently spent some time struggling with an annoying problem with a Ruby on Rails app that just kept crashing. My environment is(was) Mac OSX Snow 10.6.8.

How I fixed it

  • uninstall the entire stack: rails, bundler and all dependencies, gem and rvm itself,
  • change my system path settings (sudo vi “/etc/paths”, put “/usr/local/bin” on top)
  • restart the machine, verify that in my path “/usr/local/bin” comes before “/usr/bin”
  • re-install rvm, ruby 1.9.2, gem, bundler
  • verify “which ruby”, “which gem”, “which bundle”, they should all show the rubies path “~/.rvm/…rubies/…”
  • install rails, redo “bundle install” in the project folder

The problem

I was having troubles getting a ruby in rails application running. This same app had been running perfectly fine before, I didn’t touch the code and others didn’t seem to have any problems running it. So it had to be something with my environment. The main change that I did was to have migrated from Ruby 1.8.7 to Ruby 1.9.2. But everyone had done that too, the app had been nicely running on 1.8.7 for me too, but not on Ruby 1.9.2. Why was this happening? Why was I the only one experiencing this problem?

Clues that led to my approach

After some googling and reading up a few blog posts, I came across this post by Yehuda Katz. I followed Yehuda’s recommendations, but that didn’t fix my issue. He’d touched upon one thing that I was sure was going to be a good lead: some gems could have been compiled with the wrong version of Ruby or native libraries. That had to be it, but where, which gems? I thought if a quick reinstall didn’t do it, something must be seriously broken. As I started removing and reinstalling the gems one by one, I kept checking the search paths, that’s how I found out that it was consistently not what I was expecting, some gems were found on /usr/bin while others were found under /usr/local/bin or in the rubies (rvm).

The only way to stop this, for me, was to remove it all, force my system to search /usr/local/bin. So I cleaned my env, adjusted the file /etc/paths to search “/usr/local/bin” before other paths.

What I’ve learned here is, as Yehuda puts it, “check your assumptions first” is probably even stronger for the DRY Ruby on Rails like environments than say Java or .NET environments. Indeed it is too tempting to think that once you’ve installed rvm, the ruby on rails stack and some nifty little gems, all following some quickly assembled and even quicker read blog postings, that everything would be fine from there. And that’s the wrong assumption that one needs to challenge.

Installing rvm, instructing it to default to another ruby version is not all there is to it. One needs to ensure that the entire stack has a consistent chain of dependencies, it’s better to do it at install time when installing anything new, and running things (to check that no assumption was quietly falsified unbeknownst to you).

Cappuccino is for Objective-C developers what GWT is for Java developers

Cappuccino looks to be a promising framework for those with years of Objective-C experience looking to leverage that skill to build attractive web sites without learning all the intricacies of CSS and JavaScript

Every once in a while I come across a framework and wonder who on earth would want to learn this? Then time passes by and I would cross it again while exploring something else, then my curiosity is aroused a tad more. That’s how I’ve bumped into Cappuccino for the third time in perhaps an 18 months timespan. So this time I thought I’d look under the bonnet to see what it’s got to offer that I may learn something from.

My time budget was about 1 hr, which was enough to get the code, set it up and take it for a spin. Several times I thought I was reading Objective-C and nearly stopped, then I would carry on a little further.

This was a nice surprise, a topic for another blog posting in the coming weeks.

The traditional IDEs should go on a “diet” program

Traditionally IDEs should go on a diet program, they are unnecessarily too heavy and fail to accomodate the rapid turnaround time they are intended to provide. The emergence of web browser based IDEs is probably going to help a lot.

These days I do a lot of rapid prototyping, turning around small but fully working apps fast is my equivalent of PowerPoint slides. As you do this, you realise just how much of a resource hog the integrated development environments (IDEs) have become (always have been?). And there is really no good excuse for this. Sure, computers are getting faster and cheaper, and the traditional IDEs seem intent to make sure you never realise the benefits of that.

I’ve worked with many popular IDEs over the years, the ones I’ve used most are Eclipse and IntelliJ IDEA, and Microsoft Visual Studio (memories of Powerbuilder and Borland IDE are still there). The one constant thing I’ve noticed with IDEs is that user waiting time is steady, it is getting longer in some cases, not shorter. Aside from code refactoring features there’s nothing fundamentally new to these tools. Somehow you always need the top of the range computer to run traditional IDEs, and if you’re running anything else at the same time such as a word processor, or a database then you might end up spending a lot of time waiting for your computer to give you control.

Why are traditional IDEs lagging behind (actually hindering) the performance gains afforded by the hardware evolution? I think one possible cause is that these IDEs are still failing to become truly modular. Various efforts to tune the IDE into understanding the user role remain too timid, you get a little less clutter on the toolbars and windows here and there, but the start/stop time and various frequent activities remain painfully slow, because the stuff is just too heavy for no particularly useful reason. This topic actually ties in to my rant about virtualisation still failing the desktop power user, more on that on another blog posting.

On the other hand, text editor centric IDEs are quite nippy. Take TextMate, Emacs, VI, you get to work much quicker and spend most of your time doing work rather than waiting for the tool to complete some task. These tools do offer code completion and search, what you really miss is perhaps the refactoring and interactive debugging capabilities. And I think those aspects are becoming less relevant, test-driven development in a good agile process makes debugging unnecessary for the best part of the development lifecycle. If these practices are combined with something like behaviour driven development increases the odds of producing good quality code. The programming language really helps if it’s less verbose, in that sense I’m starting to think of Java as the new Cobol really. Languages that are based on functional programming are such a tremendous help in thinking clearly, writing less code and spending less time with infrastructure stuff.

The emergence of web browser based IDEs such as Mozilla ACE might provide a serious challenge to the traditional IDEs, and that would be a good thing.

Programming language review whirlwind

Selecting a programming language in this day and age is actually fun. I had a lot of fun comparing the following languages and their eco-systems: Ruby, Erlang, Scala, Groovy, Haskell. I’ve come away with lots of new insights that I’d forgotten or overlooked. I think a practising hands-on software engineer or architect would gain a lot in endeavouring in this type of journey.

Every once in a while you get a chance to evaluate various technologies for their suitability to a job. I’ve reached one such time, and the task is about taking a fresh look at the programming language and platform for this particular project, pick the most adequate. I’d forgotten how much fun such a journey can actually be.

In this initiative, I got inevitably drawn on the popular functional languages that many in the open source community thrive on. I’m glad I got to do this, it made me realise that I was drifting away from some of my earlier and most consistent mantra: reducing waste, fighting off verbosity in the way we build solutions.

The languages that I’ve evaluated and compared in this initiative were: Ruby (and its ecosystem), Scala, Groovy, Python, Haskell, Erlang. Why didn’t I do this earlier? It’s simply crazy not to have done so earlier and often. I’ve now learned my lesson, I’ll be doing this regularly from now on.

When architecting solutions, writing ‘no code’ is the nirvana. This being the real-world, fighting off verbosity and tedious repetitive stuff is the most efficient way to solve problems. Functional languages provide the best platforms for addressing modern computing needs.

Information Systems Architect should write solid code, Part 2, how?

Code is the most efficient way to convey ideas to programmers. Architecture code should be embryonic, a starting point for a solution. Architecture principles help when they define some ground rules for composing solutions out of components, the boundaries and contexts of these compositions and the special conditions that should be guarded. All this can be expressed much faster in wireframe code, than in complicated text. If you can express architecture principles in diagrams and text, be sure to also express them in solid code. I call this say it in code.

In an earlier post, I stated that an Architect should write solid code. I’ve also tweeted about this, pointing out that an IT architect who doesn’t code cannot be trusted. To illustrate my point, I chose a fictitious test case organisation, Trotters, where Kermit works as an Architect. I described some of the consequences when someone like Kermit is far removed from code. If you are interested in this discussion but haven’t read my earlier post, I invite you to do so here.

In this post I will discuss some of the ways that Kermit could write code to make the architecture practice more effective in his organisation.

To begin with, here are some more (bold) statements – I could always prove the points at a later stage.

  • If you can draw diagrams, you could also provide framing code base that realise the diagram
  • If you cannot create code representative of the diagrams that you are drawing, then either:
    • you are unsure how to do this (no further comment on that), or
    • your ideas are not fully fleshed out yet (so you are not done), or
    • you are reluctant to get into the details, for some reason
    • In any case, this is a problem.

Writing wireframe code goes much faster than writing long documents, and it harmonises interpretation much more efficiently. Text and diagrams leave a lot of room for interpretation, every programmer is likely to interpret things his/her own singular way.

Code is the most efficient way to convey ideas to programmers. Architecture code should be embryonic, a starting point for a solution. Architecture principles help when they define some ground rules for composing solutions out of components, the boundaries and contexts of these compositions and the special conditions that should be guarded. All this can be expressed much faster in wireframe code, than in complicated text.

How should Kermit go about this?

To simplify I will focus on web application as the solution domain for Trotters. Kermit and the team are working with object-oriented (OO) design and development concepts, they standardise on UML notation. They could be programming on Java or .NET platform, that doesn’t matter here.

Here is a simple guidance for Kermit:

  • UML supports drawing component diagrams. Kermit has probably designed a layered architecture diagram. Therefore, Kermit can create equivalent UML artefacts in code by designing classes for relevant components using the most appropriate realisation path.
  • Components in a layered architecture will typically interact via interfaces. Kermit can create (mostly one-to-one) interface classes between each connection points in the architecture. OO design skills are necessary to do this right. This is a first test of Kermit’s ability to say it in code. This can be further refined when for example using a concept such as design by contract, of which ample free resources can be found on the Internet
  • Boundary conditions and constraints: modern programming languages like C# or Java offer an array of features to deal with constraints. (similar concepts are fairly trivial in other languages) In addition, boundary conditions and constraints can be expressed in test harnesses, in turn included in the codebase as part of a continuous integration setup. Such productivity measures are invaluable and they often teach teams aspects of the solutions that might not be trivial, let alone described in text documents.
  • Enforcing architecture: this aspect is made trivial when considering the development environments (IDEs) available to programmers these days. These IDEs ship (or can be complemented) with code analysis and validation tools. The most recurrent patterns and errors can typically be verified with little or no effort, thanks to the richness of the validation rules that are available for these tools. An organisation like Trotters, as discussed in part 1, is typically weak in this area, and that is a shame.

Once expressed in code, the following become enabled:

  • Efficient two-way feedback on the architecture: programmers can immediately spot any issues and raise them for resolution with the architect. Kermit’s ability to communicate in code will come in handy, as he is able to grasp implementation issues quickly and can improve his design in the process
  • Enforcing architecture principles: nearly every modern programming environment offer tools for validating code and testing boundary conditions.
  • Platform constraints are immediately brought to light: with architecture code, architects and programmers are immediately confronted with infrastructure constraints. This makes it possible to analyse the situation, convey feedback quickly to all stakeholders before anything is really built. This helps in reducing gaps in expectations across all groups.
  • Guarding against basic mistakes or repetitions: there are elements that are typically common to every solution in a given business domain. There is no value in painstakingly recreating such elements, as that would only expose Trotters to unnecessary mistakes (typing, errors or omissions due to human factors, learning the hard way).

An easy argument could be to claim that Kermit, as an architect, does not have enough time to delve into programming details. Another easy argument would be to claim that should Kermit delve in code, he would be overstepping his role (micro-managing?), or that the programmers’ creativity could be hampered. Such arguments are easy to bring up, it is very tempting when one knows nothing better to do. But such approach is misguided, in most cases. First of all, I argue that an architect can write solid code much faster than he/she can create useful documents with legible text and diagrams. A second reason why I think this is misguided, is that the tools and techniques available today are amazingly powerful and simple to use, not using them to their true potential equates to disservice to the organisation. As a way to illustrate this last point, I’ll take a totally unrelated example: as I look over the shoulder of some people using Microsoft Word, I’m often amazed to see how they go through the pain of manually formatting documents by inserting spaces and page breaks. These people don’t seem to be aware of features that were in the product since version 2.0! (the first I’ve used). That is the point. And this example is actually nothing compared to the inefficiencies caused by programmers and architects enforcing early 90’s work processes with 2010 generation of tools and techniques.

To summarise, if you can express architecture principles in diagrams and text, be sure to also express them in solid code to reduce communication gaps. I call this: say it in code. Users typically don’t relate to design documents (architecture is part of design in this context). Often case, design documents would pass approval gates without users noticing faults or shortcomings in them. And this should be expected, precisely because users hire architects for their solution skills and experience. Architects shouldn’t expect that users could validate solution architecture, which is what normally happens a lot – again I’m using the term users in a broad context here. On the other hand, once solutions are shown to users, they can more effectively provide meaningful feedback. So, Architects should express technical solutions in solution, and code is the closest form that can be less immune to human interpretation induce deviations.

So far, I’ve focused on the application architecture aspect of the Architect role, in my simplified view. Looking at the broader architect role, including business analysis and infrastructure design, saying it in code will involve other aspects that I won’t analyse too much here for a number of reasons. This posting is already quite long, I’m still trying to keep it short enough yet complete in its illustration. In future postings, I will tackle these other architect roles.

In the next instalment I will explore the limits of this concept. If I get more time, I will develop the concept further for Trotters by showing specific examples of the type of code that Kermit would be writing to help his organisation (eat your own dog food idea).

Information Systems Architects should write solid code. Part 1, Why?

I believe that an architect, in the Information Systems world, should be first and foremost a very good programmer. The architect should write code on occasions, it would be better if writing code is actually a habit. When this is the case, the Architect is able to bring a positive influence to the organisation. When this is not the case, the Architect would most probably be less efficient and will find himself/herself regularly in unproductive discussions.

I believe that, in Information Systems environments, an architect should be first and foremost a very good programmer. The architect should write code on occasions, it would be better if writing code is actually a habit. When this is the case, the Architect is able to bring a positive influence to the organisation. When this is not the case, the Architect would most probably be less efficient and will find himself/herself regularly stuck in unproductive discussions. Unfortunately, a non-negligible amount of inefficiencies stem from the Architect’s lack of awareness of the application platforms and code and the engineering activities surrounding them.

This can be proven ab absurdo, but I will provide a simple case to illustrate the point.

In this and subsequent postings, I plan a multi-part posting, I will be using the term Architect to refer to anyone who has responsibility in capturing user requirements and translating them into instructions for programmers. This broad definition includes business analysts and application designers. Though infrastructure architects and designers play a key role in shaping up the IT environment, I will classify them as programmers in this discussion because they are often at the receiving end of something specified by someone else.

Those who have needs and ask for something to be done with the IS/IT systems are users.
Those who translate user needs into work instructions are architects.
Those who actually execute the tasks of creating or modifying IS/IT systems are programmers.
The expression write solid code designate the act of creating an artefact that can be unambiguously understood as machine code, when used in a modelling context these are formal model artefacts, when used in a programming context these are program source code.

I know there might be a million other definitions out there. I think, at this point, someone could take offence and quit reading. That would be too bad. I am not interested in definitions and titles, I want to make a point and I need these specific working definitions. They work fine in this context, take my word for it.

Let’s give a simple persona to our IS/IT Architect,  Kermit. Kermit is a man in his mid-thirties, he works for a company called Trotters Fresh Dairy Products  Ltd (known as Trotters).

Say that Kermit does not write code, whatever the reason. This means that Kermit is not familiar with coding issues because he doesn’t deal with them regularly (so Kermit actually knows a programming language? good for him, but he is not involved in coding at Trotters and that that’s the point here). Kermit only talks in concepts, not related to code.

Kermit communicates his concepts to the programmers Robert and Marie-Louise using diagrams and explanatory notes. Kermit also communicates with business stakeholders using diagrams and explanatory notes.

As software is written, there will inevitably be mismatches between the application release(s) and user expectations – malfunctions are particular kinds of mismatches, changes in user expectation are also forms of mismatches. Resolving any such issues involves representatives of users, programmers and architects. At the very least, Trotters IS/IT will be facing a number of challenges due to the combined effect of the following factors:

  • Kermit made his architecture decisions based on his extensive knowledge of widely used architecture frameworks and standards, papers from industry analysts and discussions in architecture communities, his own perception of what the business is about and what matters most to Trotters business and organisation
  • Kermit’s architecture was interpreted by the business according to their knowledge, their perception of IT and software (often shaped by external influences and people background), and their evolving needs
  • Kermit’s architecture was interpreted by the programmers according to their knowledge, the platform and programming tools they are using and the resources that were available to do the work.
  • Coding was constrained by a number of factors including technology platform, programming tools, resource availability, Robert and Marie-Louise are not aware of everything that might be possible with the tools in their possession. Some of Kermit’s suggested principles were not feasible due to these constraints, choices had to be made on-the-fly.
  • Changes constantly occur in Trotters’ business environment, with them people adjust their perceptions and their expectations, it is very hard to convey all those changes in a usable and timely manner to all stakeholders. So people make assumptions that they feel comfortable with and won’t necessarily validate such assumptions.
  • Business is always pressed for time, competition is fierce in Trotters’ industry, financial constraints are ever present, decision makers are dealing with compromises all the time

Arguably there is more to say about the factors that influence complexity in the organisation, the above seem sufficient to make the point here. Let’s analyse the impact of Kermit’s lack of awareness of the code:

  • Industry architecture best practices, analyst white papers, none of this make sense until they are cast into the reality of a specific organisation. This cannot be done efficiently without intimate knowledge of the platform and the way the application is being (or supposed to be) coded. With Kermit, Trotters organisation will be learning this reality casting process the hard way
  • Even if perfectly drafted, the architecture can quickly become stale because the business reality would have moved after Kermit issued his blueprints but before the applications could be fully built and released.
  • Kermit couldn’t coach Robert and Marie-Louise efficiently, because he wasn’t involved in the coding. Even if Kermit would work closely with the programmers, since Kermit can’t write solid code, then a significant amount of the programmers’ time would go into educating Kermit on coding issues and practices
  • The numerous micro-decisions made during the software construction contribute to a non-negligible change in the initial promises of the architecture, such changes will not surface until an application release is available to the users.
  • Kermit misses the chance of bringing any lessons learned back into his architecture vision, because the feedback loop is not present or is poorly executed. Conversely, Kermit has little or no way to ensure, thus guarantee, that his vision is actually been executed upon. If the vision wasn’t correct, that fact is not properly reflected everywhere. If the vision was correct but was poorly executed, there was nothing to prevent that from happening
  • Vendor platforms evolve, so any knowledge built on a particular set of vendor solutions is likely to become obsolete and require refreshing before it is put to use after a certain amount of time. This constant knowledge renewal typically doesn’t happen, sometimes because it cannot be afforded, but also partly because people tend to get stuck in their routines and fail to notice that their knowledge is becoming obsolete. There is nothing in place to validate that knowledge at Trotters’ is adequate and aligned between the architecture practice and the programming practice
  • Kermit probably know some technology platforms very well, but there is no telling that he knows the particular platform that is part of the solution at Trotters, or perhaps the platform has evolved since the last time that Kermit did any hands-on work on it.
  • Kermit cannot assess the experience of Robert and Marie-Louise on the platform either. Conversely, Robert and Marie-Louise have no effective way to find out about each other’s strengths and ensure they are complementary. Trotters’ organisation has to trust that things would work out somehow
  • Sometimes people do notice that their knowledge might no longer be sufficient, some could then become defensive and would fight to keep any blind-spots from the open. This is human, it can be fought but it should mostly be managed. Users, architects and programmers at Trotters are facing the same dilemmas, they might not even be aware that this could be motivating some of their actions.

We can go on and on about the factors that could be causing mismatches between user expectation and application releases, but the above is sufficient to derive a pattern and draw some preliminary conclusions.

When there is any significant distance between the architects and the actual solution building and delivery, inefficiency tends to creep in very quickly and organisations don’t get the most of their assets. It does not help when those who specify what needs to be done and outline how it should be done, are removed from the actual construction of the solution. When the architect has no idea what code was (or is being) written, he could be talking about concepts that only exist on his slides and documents but actually never materialised. What would be the point of that? The above is the rationale behind my statement that An IT Architect should write solid code.

In next settlements I will elaborate on how an architect could be writing solid code, increase his effectiveness in the organisation and ensure that his vision of the solution is as close as possible to the actual solution. I will call this Say it in Code.

PS:

I am an IS/IT Architect, I could be subject to the same shortcomings described above. This is one of the lessons that I have learned over time. I’ve always felt this to be an issue in my job, I try to minimise any gaps between the vision and the realisation that was made of it by staying close to the code.

Code frameworks and ghettos, where creativity gets a lock-in

An acute issue in programmer productivity lies in framework learning curve. More often than not, no framework can be more productive than having to learn a new one. A code framework can be a force for good when it solves infrastructural issues and allow developers to concentrate on the specific job at hand. When the job is about addressing a user need, then it is well worth investigating the benefits of any framework before diving in head first. But when the job itself is about infrastructure, then the story could get more complicated.

I once read a rant by an open source developer called Zed Shaw, where he was saying that Rails is a ghetto. Zed was venting frustration about some members of the Rails (of Ruby on Rails) community, apparently he couldn’t monetise his skills properly due to politics in the community. Hence it felt like a ghetto to him. An interesting point I took from his rant was that you could get stuck in a framework and not achieve your goals, easy to guess but also easily overlooked. As I write this post, I checked the rant again for reference and I found that Zed withdrew it and replaced it with a much more toned down text, you can read that here.

A code framework can be a force for good when it solves infrastructural issues and allow developers to concentrate on the specific job at hand. When the job is about addressing a user need, then it is well worth investigating the benefits of any framework before diving in head first. But when the job itself is about infrastructure, then the story could get more complicated. In this post, I am only addressing situations when the job is about addressing user needs.

Many code frameworks are useful for beginners, useful for creating an initial solution framework. That’s the first phase of bringing ideas to life, this is where you’ve realised your Hello World and you’re all pumped up about how easy that was.

A second phase kicks in as you start learning more about the problem domain and potential solutions, you usually iterate through your design and code to reflect changes. This is a good test of the chosen framework’s flexibility, can you improve your design easily? can you improve your code easily? The further in the development, the more acute the questions become. If you’re lucky to think like the framework designers do, then progress should be swift. If not then a tough reality would start to dawn on you. Either way, your creativity start to be shaped by the frameworks that you’re using. This is where the potential pains with frameworks start to surface, it is a good learning stage. I liken this phase to betting on horse race: it always seems that the next bet will be a hit, people keep on betting. Invariably, there will come a time when the developer could feel that he was cheated somehow, he wasn’t told something or that he didn’t realise something.

The third phase in this framework journey is when the coding is done, and the application need to be put into production use. In this phase, performance and reliability issues usually start to pop up. The inevitable questions arise: is there anything wrong in my code? was the infrastructure correctly setup? If you don’t think the way your framework designers want you to think, then you could make missteps and issues would compound quickly. And maybe you do, but you just can’t help much since the framework ties you down. In this stage, only an elite few is able to efficiently address such issues. In the unfortunate case where the troubles call for an audit or project rescue by another party, the business owners tend to feel a bigger pain as their purse is severely tapped because an entirely different way of thinking and seeing the world is brought in.

Code frameworks are like giant bags of assumptions about technology, people, problem and solution domains. They help if the assumptions largely apply in the most significant aspects. When choosing frameworks, do people realise the extent of the assumptions they are about to make? How often do people bother to (or are equipped to) check such assumptions? These are interesting questions for a survey.

Creativity lock-in is not a bad thing if it helps people focus on specific and relevant problem and solution domains. When that is not the case, creativity lock-in can have devastating consequences. Ghetto can be a bit of a hyperbole, but it is a powerful paradigm for reminding people to consider a broader picture when selecting frameworks. A code framework should help with project technical hygiene, open up more opportunities. When the selection is mostly based on product marketing, then the assumptions are not being checked, who’s at fault then? – I wouldn’t blame the product vendors.

iPhone 3G battery drain and potential code smell

When your iPhone is setup to use Push email update, it can drain your battery dramatically whenever the server becomes unavailable. This is clearly a design problem that should have been prevented. Applications should degrade gracefully, and similarly, they should enhance gracefully.

Recently I’ve been annoyed by an issue with my iPhone 3G, a phone I’ve had since August 2008: it’s battery was draining super fast and I didn’t see why this was happening. The battery life has never been stellar, but it also has never been this bad.

As I tweeted about this problem here, a friend of mine pointed out that this could be due to Push update when the server is not available, tweet here. He was right, as soon as I disabled the faulty email account, the battery issue stopped.

My problem is solved, but I’m not happy about what I think might be the root cause of this issue. I think I’ve bumped into a code smell, the like that architects ought to prevent for a pleasurable user experience.

When you think about it, the main reason that Push would drain battery life is that the phone would be continuously probing a non-responsive server, trying to reconnect. This would be mindlessly going on for as long as the problem persists, and that is precisely what I find troublesome.

A mobile service that is likely to experience connection problems, as a matter of fact any connected application, should have intelligence to space out the retries and give up after a reasonable amount of failed attempts.

When a server becomes unreachable, the device should stop trying and provide a feedback, visual or not. This enables the user to decide on an appropriate action or none. But I don’t see why the application would persist and keep trying again and again, until your device runs out of battery.

Looking at it from a coding perspective, there are two possible scenario: (1) someone decided to approve this functionality, or (2) it was overlooked.

In the second case, (2), this would qualify as a “code smell”. Such code smell could easily be remedied by simply introducing a variable and increasing retry interval, aiming to both reduce the number of attempts and giving it sufficient time to fail gracefully. An example such algorithm could be based on Fibonacci numbers, see Wikipedia, reducing the chances of mindless retries.

Naturally, for a company as large and reputable as Apple, this can hardly ever be a case of technical competence issue. They probably won’t even heard of this posting, or if they did, they probably wouldn’t care.

A big take away is that, it’s the tiny deficiencies of this kind that can accrue and potentially result in an overall poor user experience. At the end of the day, even if you have a nice architecture, you would be failing your users if you didn’t pay attention to tiny code smells with huge potential impact.

For a good user experience with connected applications, an architecture principle could be: degrade gracefully; after a reasonable amount of failed retries, stop and notify user when a server becomes unreachable. As richer features become available, gracefully enrich the user experience.

GO, a case for a new programming language

With the advent of Google Go, there’s a renewed debate on whether we needed a new programming language. Actually a case can be made, for a niche player or an organisation with the right momentum to develop and maintain a new programming language.

No programming language will ever be fit for all purposes. Microsoft, among others, understood this and catered for it as they created C# and many variants of CLR compliant languages. As the technology platforms evolve, it should be natural to factor in the lessons learned and try a new approach.

In fact many already maintain Domain Specific Languages (DSL) without necessarily thinking of it as a programming language. Martin Fowler, @martinfowler, talked eloquently about the subject on his blog. In the Java world for example, template engines provide a really powerful method for organisations to become even more productive. With the right architecture, a lot of development and testing time can be cut if developers and architects can set up a good infrastructure to leverage the power of these tools.

If anyone can come up with a new programming language and be successful with it, Google can. When Chrome came out we were wondering the same thing, whether we really needed a new web browser. Now then? Another really interesting thing about Google GO is that the architects made a very clever choice by making it easy to learn for C or C++ programmers. This lowers the learning curve significantly, even good Java developers will be able to pick up GO quickly. Some of the concepts of Google GO seem to be inspired from Objective C, another big win there because Objective C has some really elegant constructs.

So there you GO, building on proven concepts, just like C# did when it came out, Google is bound to deliver the goods. I expect this language to grow fast because it can potentially leverage existing libraries. The adoption will be easier when appropriate tooling start to emerge. I foresee an approach like Google Web Toolkit, as a path to building bridges towards existing language platforms or runtime engines. If the compiler is as efficient as advertised, GO might just give Google a kind of unifying language that helps reduce software engineering effort by taking away deployment platform concerns. Microsoft is busy with a similar approach, their Oslo project and LINQ efforts are indications of the sort of goal that can be sought. I can’t way to start playing with it a bit.