stressfree - software development

Developer paths beyond the Visual Studio juggernaut

David — Mon, 23 Feb 2009 06:33:02 +0000

I have just purchased a Mac laptop and am planning to partition it to run OSX and Ubuntu. Currently I use Microsoft Visual Studio on Windows for development projects. My concern is whether there is an equivalent to Visual Studio and the Microsoft Developer Network (MSDN) on OS X or Ubuntu?

Today I was asked this question, one which is very similar to others I have been asked and answered in the past. In Windows the decisions a developer must make prior to starting coding are relatively simple because it is an environment dominated by Visual Studio. When making the move to OSX or Linux the decisions facing the developer are more complicated because no single company dominates these platforms in the same way Microsoft does Windows.

Outside of this Microsoft’s sphere of influence is a large number of avenues to consider which can significantly influence the productivity and even success, of your software project. The short answer is there no direct equivalent to Visual Studio and MSDN for OSX or Ubuntu, but there are plenty of satisfactory alternatives. In making your decision consider what languages you use now, or are interested in learning in the future. Also identify what general platform you wish to develop for; be it the desktop, server, web or mobile. And always remember whilst none of these discussed paths are wrong, some are more right than others depending on the project.

Mono - The Cross-Platform Windows .Net Framework

For a developer used to Microsoft’s .Net framework and C# or Visual Basic, the easiest place to start is Mono. Mono is an open source implementation of the .Net Common Language Runtime (CLR) which can run on OSX and Linux. With Mono you program using the C# and Visual Basic syntax you are used to, but the compiled binary executes on OSX and Linux.

Unfortunately because the Mono team is a re-implementing an existing framework they are always one step behind what is available on Windows. For example the current 2.2 release supports the language features of version 2.0 of the .Net framework. Consequently you cannot take advantage of the new features in the .Net 3.0 until version 3.0 of Mono is released, which may take a while to materialise. Another thing to keep in mind is that many of the supporting libraries found in Windows .Net maybe different or unavailable in Mono. This is largely due to Mono's cross-platform nature and the fact .Net leverages many Windows-only libraries that will never be ported to other platforms.

Whilst the Mono runtime is very mature and compares well to its Windows equivalent, the development environment and community is not nearly as strong. Compared to Microsoft's Visual Studio the Mono Develop Integrated Development Environment (IDE) is significantly behind in terms of functionality and polish. In time this situation will improve, but for the foreseeable future those making the jump from Visual Studio to Mono Develop will be very disappointed. This is not to say that development in Mono Develop is impossible, it is just that nearly all of Visual Studio's handholding and helper tools are not yet present.

In terms of an online developer community, Mono's is small compared to alternative open source languages such as Java, Ruby, Python and PHP. However Mono developers can benefit from its .Net lineage by leveraging the wealth of MSDN documentation available for C#, Visual Basic and Windows Forms. When doing so it is important to keep in mind the practical differences between Mono and .Net, as whilst the syntax is generally the same, the tools and supporting libraries used may differ substantially.

Java - A Mature Cross-Platform Environment

When talking cross-platform development Java is the ten-thousand pound gorilla in the room. Whilst technically not the first cross-platform programming environment, Sun’s marketing department popularised the concept of "write once, run anywhere" during the 1990s. This was later referred to as “write once, debug everywhere” by Java’s detractors. Like C# and the .Net CLR, Java is both a language and a runtime environment, in fact Microsoft “borrowed” many of Java concepts when developing .Net. The major benefit of Java is that the environment and community around it is very large and mature. Unfortunately this is a double edged sword; on one hand this means there is a wealth of tools and support available, but on the other the options are so varied and complicated the learning curve can be extreme at times.

Like .Net, Java is an excellent environment to learn if you are unsure of what platform, be it desktop, web or mobile, you wish to write applications for. Whilst each platform has its own mannerisms and libraries to learn, many of the underlying concepts and tools can be universally applied. Again this has its own benefits and drawbacks. From a career perspective Java is ubiquitous and no matter what the problem space or context, it can almost certainly be put to use. Unfortunately this diversity has lead to a lot of coding inefficiencies when compared to a language dedicated to a certain problem space or context. The most prominent case of this in recent times has been the meteoric rise in popularity of Ruby on Rails amongst Java developers.

When it comes to Java development tools there are plenty of good ones to choose from, for example Eclipse, NetBeans and IntelliJ. All three compare very favorably to Visual Studio in terms of features and developer community support. Personally I use NetBeans as it has a very good 'out of the box' experience and has excellent support for Java web development and languages such as Ruby and PHP. Eclipse is the most widely used Java IDE and has a vast number of third-party extensions that add a huge amount of functionality. However Eclipse's depth can be problematic as its default installation is minimal and its extensibility often poses more questions than it answers. As a result setting up your ideal development environment can take some time. IntelliJ, unlike Eclipse and Netbeans, is not open source and requires the purchase of a software license. This initial cost is outweighed in a commercial environment by its teamwork functionality and support provided. However in a single developer environment justifying this purchase when both Eclipse and NetBeans are free and so powerful is in my view much more difficult.

Other Languages on the Java VM

Whilst it has always been technically possible to run languages other than Java on the Java Virtual Machine (VM), it is only recently that this has become mainstream. Now a slew of modern, popular languages can be used within the Java VM such as JRuby (Ruby), Jython (Python), Rhino (Javascript), Groovy, Scala and Clojure. This rapid growth in JVM compatible languages has in turn been reflected in multiple language support within the Java IDEs. As a consequence some of the best IDEs for writing Ruby, Python and Javascript code are now Eclipse, Netbeans and IntelliJ.

In a similar way to .Net and Mono, the difference between the Java version of a language and its native equivalent (e.g. JRuby <=> Ruby) is its ability to leverage supporting libraries. Generally the majority of the language syntax is the same, but whilst Ruby can leverage a system’s C libraries, JRuby has access to those within the Java VM. In these cases this can lead to significant coding differences, but if you write an application using only core Ruby libraries there is a very strong chance it will run unmodified on both the Ruby and JRuby runtime environments.

Objective-C, Cocoa and Carbon

Writing cross-platform is a nice idea, but there are considerable benefits to be gained by targeting a specific platform. Objective-C is not an OSX specific language, but it has gained notoriety thanks to its close relationship to the OSX Cocoa framework and its associated user interface functionality.

Whilst the Cocoa framework is available on a variety of platforms, it is most well known for its OSX implementation where Apple has injected a considerable amount of additional functionality. Unfortunately much of this functionality relies on libraries present only within OSX, and as a result the cross-platform, open source implementation of Cocoa, GNUstep, is viewed by many as its poor cousin. For a good discussion of Cocoa, OSX and GNUstep checkout the interview with a couple of GNUstep developers on FLOSS Weekly.

The other significant development framework on OSX is Carbon, but this is primarily intended as a compatibility library between the "classic" MacOS and OSX. Any new development should be undertaken in Cocoa simply because this is where all the action is. Plus, if Apple stays true to form, support for Carbon will cease in the not too distant future.

As far as development environments go the OSX-only XCode from Apple is far and away the best IDE for developing in Objective-C and Cocoa. XCode and its accompanying tools are shipped free as part of OSX, plus there is a large developer community and Apple Developer Connection (ADC) to call on for support. Paid membership to ADC can be expensive depending on your needs, but like MSDN this grants you improved access to Apple’s internal development processes and pre-release software. Unfortunately on other platforms such as Ubuntu the tooling for Cocoa and Objective-C is not so strong. GNUstep has the ProjectCenter IDE, but this does not compare well to Visual Studio, Java IDEs or XCode in terms of its functionality or polish.

Life without an IDE - Text Editors and Command Lines

Whilst it may sound strange for someone used to operating within Visual Studio's padded walls, some of the best cross-platform development environments you can create yourself using a text editor and command line tools. Unlike C# and Java, languages such as Ruby and Python have grown to where they are now without significant support from complex IDEs. Learning a new language using these limited tools can also prove beneficial because you are not shielded from a language’s complexities by a "helpful" IDE. The end result is you gain a much better understanding of a language and its runtime environment than you would if you were to continually rely on an IDE’s wizards.

When using such an approach it is easy to move between different operating systems because each has an excellent suite of text editors. On OSX this choice ranges from the free TextWrangler through to the moderately expensive TextMate. As far as Linux goes it really depends on your operating environment (Gnome, KDE, etc) and preference for GUI or command line tools. Needless to say like most things open source, there are extensive and intense debates about the pros and cons of various text editors.

Version Control is the Key

No matter what language or development approach you choose the most important to setup and use is some form of version control. Systems like Subversion or Git make it easy for developers to move between OSX, Linux and Windows without having to worry about shared filesystems. There some very good GUI tools for version control management, for example the tools built into Java IDEs and standalone applications such as Versions (OSX only) and RapidSVN.

Version control is especially important in cross-platform development because no matter how hard you try, chances are you will inadvertently introduce a bug that affects one or more of your target platforms. When this happens it is important that you can quickly find out what was changed, or what changed on your target platform, and work up a patch. This may involve reverting to a previous version of your code, or creating a platform specific branch.

Conclusion

Unlike the .Net/Visual Studio dominated world of Windows the choices available to a developer on OSX and Linux are many and varied. There is certainly no right answer, but more often than not there is one language that fits the problem space or context you are working in better than others. Personally I prefer the breadth and depth of the Java development world. Not only is arguably the most cross-platform, but it also has a strong developer community and tooling that is on par with, and at times better than, Visual Studio.

Unfortunately if it is a desktop application you wish to develop, Java is in a state of flux until JavaFX gains more adoption and is released on platforms other than Windows. With this in mind the functionality offered from Mono and its WinForms implementation is hard to pass by, even if the tooling support available in Mono Develop is immature at present.

Perhaps the most difficult development decisions arise if you wish to develop for mobile devices. In terms of a lucrative market the iPhone with its Cocoa framework is hard to ignore. However a version of Java, be it Micro Edition or Dalvik, is available on most other mobile devices. Fortunately I am not a developer in this space, but if I were I would probably take the iPhone route given its proven market. This being said I would keep a close eye on the growth of Android as its openness may prove the winner in the long-term.

Doom & gloom programmer keynote by Tim Bray

David — Sun, 12 Oct 2008 09:38:47 +0000

Tim Bray's Future of Web Apps 2008 keynote has been published to the web. Unfortunately he does not paint a rosy future for developers given the current economic climate. Entitled "The Fear Factor", according to Tim he rewrote the script the night before after spending a couple of depressing days with London bankers and watching television news.

Tim gives a very down to earth presentation that sits in stark contrast to most bright and breezy keynotes you see posted to the Web. The underlying concept is that the credit crunch will force many companies to suspend broad, big budget development in favor of small, low-cost projects. In this environment there will be project cancellations and job losses, so if you are a programmer it is a case of staying competitive through learning and networking more than your competition.

Some of the interesting points raised in the half hour keynote were:

Monetisation will occur at the point of value. Rather than $100,000 up-front licenses, companies will be looking to pay only once a system is in production i.e. Open source will hold a significant business advantage.
Waterfall is dead. In an uncertain, credit-poor economy the idea that a project can go for 14 months without delivering value will be seen as unacceptable to decision makers.
The Cloud is good, but lock-in is bad. Companies will value the cost savings from on-demand services like Amazon Web Services and Google App Engine, but be wary of the pitfalls of vendor lock-in (we do not want another Windows monopoly).
With regulation comes business opportunities. Governments around the world will be passing legislation to ensure another financial crisis is avoided. From a software development standpoint this will create a significant opportunities for those in the right place with the right abilities.
Mobile technology and micro-transactions are the new fertile ground. Apple iPhone and Google Android have realised the development potential of the mobile device. Their application marketplaces are vibrant economies where micro-transactions of $1-$5 rule.
Build something for yourself. You will only be truly successful at building something that satisfies your own needs. Steve Yegge has said it best in "business requirements are bullshit".
Do not be a [insert language here] developer. The idea that someone can ever learn and use one computer language (e.g. Java, PHP, Ruby, etc.) in a competitive marketplace will not cut the mustard. Be a 'web developer' who is prepared to explore anything, even legacy code - you never know where it will lead.
Network, network, network. Nine times out of ten work will come from people you know rather than what you know. Do not expect the plum jobs to land in your lap if you do not participate in communities. e.g. conferences, mailing lists, blogs, Twitter, etc.

Overall it is a very good, down to earth talk that provides a valuable reality check in these "interesting times".

Architecture Astronauts

David — Thu, 11 Jan 2007 08:46:06 +0000

A blog post by David Megginson brought to my attention an article posted six years ago by Joel Spolsky about architecture astronauts. Who are they? Architecture astronauts in Joel's words are:

"Smart thinkers (that) just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all."

The moral behind Spolsky's story will continue to remain relevant simply because it is a lesson often forgotten in the heat of a debate or brainstorming session. David Megginson agrees with many of these observations but does point out architecture astronauts have had a positive, if not always successful effect on technology development. From the real world of architecture I am always reminded of Mies van der Roe's ability to grasp the big ideas of modernism whilst still keeping his head when it came to functionality and details (after all, 'God is in the details'). This ability gains even more credit when you compare his work to Le Corbusier, arguably one of architecture's great astronauts, who's ideas often far outstretched their functionality or success in the real world.

On a technical tangent I especially agree with one of David's last points about XML and the heady effect it has had on technology architects and evangelists in the past:

"(Architecture astronauts) believe that if a bit of standardization is good, a lot must be even better."

If anything both posts highlight the importance of stopping work, taking a step back and readdressing what it is you are actually trying to achieve and the way it is being done. Unfortunately for most of us it is all too easy to get caught up in the big idea or the nuts and bolts, in the process missing the chance to grasp what we were really on to in the first place.

Software design choices and the Vista shutdown menu

David — Tue, 28 Nov 2006 09:54:50 +0000

Windows Vista is Microsoft's very delayed 'next-generation' operating system finally shipping to consumers this December/January. Whilst aesthetically similar to Windows XP it offers a host of new functionality. One new piece of functionality that has drawn a lot of criticism has been the overly complicated shutdown menu. You would think shutting down your computer would be simple but Vista now offers nine different ways of ending your Windows session from the 'start' menu. The result is confusing, ugly and a pain to use. Joel on Software has a well considered article on how too much choice, whilst good in theory is bad in practice and uses this new shutdown functionality as an example of the problem.

Simplification and a healthy dose of logic is usually the answer to these problems but this can only come when the decision making process is clean and crisp. Unfortunately in the case of Windows Vista the decision making process was far from this. Moishe Lettvin was part of the shutdown UI team on Windows Vista and in a blog posting he describes the painful process behind this little piece of functionality (comprising of just a couple of hundred lines of code). The feature is the ultimate example of design by distributed committee as it received input from 43 different people. The consequence of this? After one year of development the 'team' produced a traditional, option packed menu. If his post is an indication of the software development beuarcaracy and process issues within Microsoft then they are in serious trouble. Without significant changes Windows Vista will symbolise only the tip of the iceberg when it comes to overdue, feature-incomplete products emerging from Microsoft development labs in the coming years.

To open source or not open source, that is the question

David — Thu, 14 Sep 2006 11:16:04 +0000

Thanks to Ted Haegar I came across a piece by Tony Whitmore on a similar topic to my Novell Open Audio review. Tony raises a couple of good ideological questions about the development models at work within Novell, more precisely around the AppArmor and XGL products. Whilst each software project is unique in its own way his questioning of the strategies employed by Novell does beg the difficult question, how open source should product development be?

When I mull this issue around in my head it is like there are a couple of little devils sitting on my shoulders whispering sweet nothings. On one side sits the 'hardcore' open source evangelist devil who looks surprisingly like a drunk fluffy penguin dressed in dirty, well-worn clothes. He whispers in my ear that all software development should be free and open to ensure clean, secure code and a strong community both supporting the product and the FOSS community at large. However on the other shoulder sits a clean cut, black turtleneck wearing cat that seems to go by a different name each year. He presents a flashy keynote on the benefits of developing software products with a clear vision and a small, well controlled development team. What is confusing is that they both have some very good points along with vocal opposition in some quarters.

Novell at present are threading a tricky needle between the opinions of both devils. Their challenge lies in creating a strong community of well supported and stable products whilst at the same time introducing a number of "gee-wiz" features that are unique so to generate enough buzz to outshine their competitor's alternatives. Open source is great for building strong communities and stable products because everyone can see and take part in development. Unfortunately this same model makes marketing a nightmare because it has a high 'yawn' factor. Take for example XGL, it made a huge splash a few months ago mainly because Novell came out of nowhere to introduce it into their Suse Linux Enterprise Desktop line. This splash put the spotlight on SLED like never before and really pushed it into the forefront of viable Linux desktop alternatives. However if XGL development had been undertaken in a purely open source manner with its conception well publicised and discussed the eventual product and marketing potential would have been considerably different. Not only would it have probably taken a different evolutionary path but more importantly its marketing pull on SLED's launch would have been insignificant.

Whilst closed development is arguably better in the early stages of development from an efficiency and marketing perspective over the long-term an open source approach is far superior. Now that XGL has gone through its silent phase and emerged to an eager audience it is good to see Novell have open sourced the code and are focusing on getting the technology mature and broadly accepted. Personally I would like to see eDirectory open sourced mainly because it lost its 'wow' factor a long time ago and could stand to gain a significant amount by being accepted by the wider open source movement. A significant part of this acceptance would be seamless integration into existing Linux distributions in the same manner as Apache, MySQL and PHP have achieved. There is a real need for a robust, high-quality, open source directory server as it is the centrepiece around which nearly all office networks are built. A few years ago Red Hat open sourced the Fedora Directory Server but I have not been impressed when I have experimented with it. This is mainly because FDS is OpenLDAP on steroids rather than a stable, scalable and industry proven directory server alternative that can go toe to toe with Microsoft's Active Directory.

The other factor to take into account with eDirectory is that Novell does not really make any money out of it yet it is the cornerstone of nearly all their income streams. Consequently open sourcing this key piece of infrastructure and encouraging its adoption and integration in other platforms will broaden's Novell's potential market. This will mean when the next 'gee-wiz' product gets released it is just that little bit easier to sell to prospective customers because a considerable portion of the puzzle is already in place. To open source or not open source is not a clean cut strategy but one that seems to hold most potential when used equally in appropriate portions. It would be nice in the ideal world to have a completely open development model, but deep down I think we all want to get marketed to by at least one flashy, out of the blue product that makes us wonder how we got so far through our lives without it. Novell with XGL (and to a lesser extent AppArmor) achieved both goals with an intelligent, balanced approach and for that they should be commended.

Software Development

David — Fri, 26 Nov 2004 03:03:02 +0000

During the working day (and night) a large portion of my time is spent developing web-based software solutions for organisations located within Wellington, New Zealand. Most of this development is related to knowledege management, primarily the field human resources.
Development is undertaken in the Java programming language as it is powerful yet flexible enough to be deployed on any major operating system in use.
If you are interested in checking out the source (or just downloading the latest version) checkout the Subversion repository.

YouWHO: Business Contacts Database

YouWHO is a powerful tool for managing your businesses' human networks. The software is intended for multi-user environments where information on large numbers of people and organisations must be maintained for correspondence purposes.
YouWHO is open-source and is available for download.

WhichDoctor: Medical Doctor Database

Developed specifically for The Royal Australasian College of Physicians, WhichDoctor provides a simple yet very powerful toolset for managing the training, financial affairs and contact details of New Zealand medical physicians and paediatricians.