czwartek, 17 października 2013

The return of native applications - but what for?

Before the web applications era we had the following (and not an easy one) situation with software:
  • some applications had only one target in terms of hardware or operating system
  • some applications had different versions so that they could be used on more than one software / hardware combination
Around the time when I started my first job (2000) it was apparent that the ultimate interface for everyone and everything would be the browser. Since then we have had web based applications serving as the primary user interface in all possible domains, from email, through project management to modeling and simulation.

But recently, we see more and more applications that are marketed as native. Although often a web version of an application exists, its platform-tied version (iOS, Android or Windows) is marketed as if the nativity alone were such a big advantage.

What can we make out of this? I don't know. But it just seems strange.

środa, 9 października 2013

Scripting paranoia

Jim is a developer in a team of nine and is better acquainted with Git than any of his colleagues. They rely on him when there is something particularly difficult to do with Git or if they have any kind of questions about Git. They feel comfortable asking him even the most basic questions, because Jim is so friendly and helpful.

Jim wants to make his teams' life easier so much that he creates a whole bunch of scripts. Over the course of time the team has a number of scripts that come in very handy when they want to perform regular, day-to-day versioning tasks:
  • branching: instead of regular Git commands -> branch.sh
  • merging: instead of regular Git commands -> merge.sh
  • tagging: instead of regular Git commands -> mktag.sh
  • pushing to remote server: instead of regular Git commands -> pushall.sh
  • viewing commit history: instead of regular Git commands -> showcommits.sh
  • and so on...
Scripts are well suited to what the team does daily. If there's the need to tweak any script a little, Jim is very willing to do so. Over the course of time, Jim's colleagues become so addicted to these scripts they cannot live without them. Unfortunately, they can no longer write proper Git commands or understand standard Git output on the console. How come they got into the mire, if they did all those things in order to become more efficient?

Obviously, it could be anything else, not neccesarily Git. My point is that any kind of computer system designed to interface with human beings, such as a version control system, presents to us its own mini-language, in the form of console commands or other, with which we can communicate with it. Its creators wanted us to communicate with it that way, it itself wants us to communicate with it that way. We should beware of encapsulating the sentences of this mini-language in scripts, because we will end up not being able to communicate with the system in any way that does not match any of our dozen of shortcuts. Not only will we be unable to issue any non-standard requests to the system, but we will also be unable to understand what it says to us.

Beware of scripting paranoia.