stressfree - java

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.

SpringSource tc Server: The right product at the right time

David — Sun, 14 Dec 2008 05:52:20 +0000

Releasing a new product into one of the worst economic climates ever would generally be considered a bad move, but for SpringSource it may prove a master stroke. Recently they announced that early next year (Jan/Feb) version 1.0 of tc Server, a fully supported, business-friendly edition of Tomcat 6.0, will be available. For those in the Java world Tomcat is the first port of call when developing or deploying web applications. This is because it is free (open source), lightweight and relatively easy to use compared to the Java application server competition; JBoss, GlassFish, WebLogic and WebSphere.

SpringSource's own diagramattic positioning of tc Server

Unfortunately when compared to alternatives Tomcat has never been as well supported in the role of mission critical, business server. JBoss does support Tomcat so that it can fulfill the role of servlet engine for their application server, but most will acknowledge the two are quite different beasts. Other companies ship Tomcat as part of their products, for example Novell and Alfresco, but in these cases support is of a token nature and generally extends only to how the company's own software runs within it. So in this cloudy support and economic environment it is easy to see why SpringSource is moving to offer a supported, business-friendly edition of Tomcat.

Why is the inferior Tomcat better than the competition?

Without significant marketing Tomcat has become more prevalent than its competition through simplicity and availability. Compared to alternatives it has managed to stay trim and easy to use by staying clear of all the inherit complexities of the Java EE specification. Instead the development team has focused on being the best Java servlet/JSP container, and let adoption handle itself.

For those not versed in Java understanding the difference between Tomcat and a full blooded Java EE server is a challenge. In a nutshell Tomcat focuses on a small, but significant, portion of the specification, for example it does not internally implement JMS messaging, web services or persistence (EJB). This does not mean similar functionality cannot be added to Tomcat, but as a developer it must be assumed these things are not present. This may seem like a drawback but it has proven to be advantageous given the torrid history of Java EE, which only recently has delivered promised developer productivity benefits. In the meantime Tomcat-compatible frameworks such as Spring, Hibernate, Axis and CXF have emerged which embody many of the practical characteristics of Java EE without the complexity. So whilst Tomcat cannot claim to be a full-blown application server, it can for most purposes practically act like one.

If Tomcat is so good why do businesses need SpringSource?

Tomcat is used extensively in business today but the general level of expertise available in the market is limited. This can partly be attributed to the excellent job Tomcat developers do in shipping a production quality product. Unfortunately there is a significant step up between using Tomcat at a small scale and having it run business critical applications 24/7. Attaining this level requires a significant investment in time by the internal I.T. department, or migration to a fully supported application server like the ones referred to earlier. SpringSource are aiming to provide a third alternative by packaging their experience in Tomcat performance optimisation, management, clustering and monitoring into an easy to use and well supported product. The benefit of this is that businesses can continue to rely upon their existing Tomcat investment without having to commit significant internal resources, or worse, migrate to a different application server platform.

How are SpringSource delivering on this?

In recent months SpringSource have announced two separate (but related) products, tc Server and dm Server. In a nutshell tc Server is does not change Tomcat, whilst dm Server is a heavily modified, OSGi compatible variation that solves the long running problem of JAR hell.

Okay you lost me, OSGi and JAR what?

Unlike .Net the Java web platform is not dominated by a single, all powerful company such as Microsoft. Sun certainly exerts control over the Java language, but the majority of commonly used libraries are contributed by third parties, either working independently, or towards an agreed upon specification (JSR). This distributed lineage has created a complicated dependency problem often referred to as JAR hell. This is where applications or third-party code requires similar, but incompatible library files. Not only does this complicate development but it also causes serious headaches when it comes to deployment.

To combat this problem three initiatives have emerged which are functionality similar to Ruby's gem or Linux's apt package management. The first, Maven is a tool-set that goes a long way towards resolving a developer's immediate issues. In the long-term Sun is undertaking Project Jigsaw which will hopefully become an integral part of Java 7. In the meantime to address problems in production environments the OSGi Alliance has developed a framework for library management. IBM, Oracle, Sun and JBoss all plan or have implemented OSGi support, whilst SpringSource's dm Server is the first derivative of Tomcat to support it.

The problem with OSGi is that it requires considerable changes to the way applications are developed and deployed. As a result whilst OSGi seems the obvious long-term answer, most businesses are more interested in deploying their existing, non-OSGi compliant applications. Given this landscape SpringSource's strategy is to gain immediate market share with the conventional tc Server, and then be in a position to capture a share of the OSGi market with dm Server.

What is the secret "source" in tc Server?

It is very difficult to sell support for a single open source project that has a strong community like Tomcat's. Generally commercial support is only perceived as valuable if it covers a range of projects (Red Hat), or the company has a single, controlling stake in the future of the project (Alfresco). If neither of these conditions are met then the business must provide an extra layer of valuable functionality. SpringSource are not breaking this rule, and plan to add the following to their Tomcat distribution:

Performance patches and tuning

Parts of Tomcat are quite conservative and rather old. SpringSource are significant Tomcat contributors and have developed patches to address less performant parts of the code. Added to this their experience has given them unique insight into how Tomcat can be tuned to operate at peak efficiency during various demanding scenarios.

Server and Cluster management interfaces

The Tomcat development team has never invested serious time in tools that ease server or cluster management. A basic administration tool does come with Tomcat, but it is one of the first things deleted given its limited functionality. SpringSource are aiming to rectify this with a set of management tools that ease setup and configuration of standalone or clustered Tomcat instances. Versioned configuration and scheduled changes are planned, but whether this will be available in the 1.0 release is uncertain.

The Application Monitoring Suite (AMS)

Prior to tc Server, SpringSource developed the Application Monitoring Suite, a Spring-centric monitoring and analytics system built on top of Hyperic. In practical-terms it allows developers and system administrators to monitor a running Spring application at a very low level. The suite takes all the guesswork out of troubleshooting and can automatically respond to, or alert others of, events within the system.

SpringSource AMS in action (click to enlarge)

SpringSource intend to leverage this comprehensive monitoring tool-set during tc Server support incidents. Anyone that has tried to remotely troubleshoot a Tomcat problem will understand what an edge this gives the SpringSource engineers. As a consequence businesses will feel comfortable their support requests can be efficiently addressed, even if the engineer is on another continent.

From an operations perspective having monitoring built-in to tc Server is a great time and resource saver. For many monitoring is one of those New Year's resolutions that never quite eventuates. However once in place the statistics generated are invaluable, and the peace of mind knowing everything is working within defined parameters lets everyone sleep easy at night.

What will this cost?

Whilst the final price has not been confirmed, this blog post suggests tc Server will be priced at US$500 per CPU per year. This is no doubt the base price and different support-tiers and discounts will be factored into the mix at release. If $500 is correct then this would appear to be a very good deal considering the functionality delivered and the cost of competing Java application servers. Plus from a cost/benefit standpoint businesses would not need to invest in an in-house Tomcat expert, or undertake a complicated migration to a completely foreign, but supported, server platform. Hence once these costs are factored in it may well turn out that adopting tc Server actually saves the company money over the long-term.

If SpringSource can execute they could win big

These recent Tomcat-based server announcements are shaping up to be very compelling product offerings. Given the changing face of the Java application server landscape and SpringSource's reputation, both tc and dm Server stand strong chances of success. What is really interesting to watch is key pieces of a long-term strategy fall into place. Spring has captured a significant amount of developer mind-share and their Application Monitoring Suite illustrated they are serious about production environments. It would seem these new servers are building on these strong foundations, and in the process turning SpringSource from small-time developer of tools into a serious competitor within the Java application server marketplace.

For more information on SpringSource tc Server checkout this webinar.

Google outflanks Sun with Android

David — Tue, 13 Nov 2007 23:44:44 +0000

Google recently released the highly anticipated Android mobile phone platform to developers. Android promises to be a more consistent and powerful environment for mobile applications compared to what currently exists in the fragmented mobile market. Whilst many people were disappointed that Android was not a Google-branded iphone; from a developers perspective if it can gain broad adoption it will make the developing powerful, Internet-centric mobile applications significantly easier.

One of the most interesting aspects of Android is that it is released under the Apache v2 software license. This license grants obligation-free use of the code to any party. This is different to other popular open-source licenses like the GPL which requires source-code modifications to be made publically available. In the competitive mobile phone market such an obligation is problematic which is why Sun releases the Java Mobile Edition (ME) under different open and closed source licenses.

A question that was hanging around Android was how Google had managed to release a Java mobile platform under the Apache license given that the licenses Sun release JavaME under are not compatible. Stefano Mazzocchi points out on his blog that Google have outflanked Sun by releasing a platform that supports the Java language but does not use Sun's Java compiler or the Java byte-code at its core. Instead Google have created Dalvik, a virtual machine released under the Apache license which understands how to compile Java source code into its own byte-code for execution.

This move outflanks Sun's licensing policies, essentially cutting them out of the Android equation. It is a gutsy move by Google but it does free them to focus on developing a platform they have complete control over rather than working in partnership with Sun. From the perspective of Java as a language this move wouldn't seem to pose any problems as the mobile and desktop/server worlds have always been quite distinct. Plus if anything Google's use of the Apache Harmony JavaSE libraries may actually make developing for the mobile and desktop more consistent than Sun's distinct JavaME and JavaSE implementations.

All things considered this news has made Android more interesting from my perspective. Before I heard this it was just another JavaME implementation but now it sounds like Google will have the capability to do some really interesting things. What has yet to be seen is what level of support (if any) this platform will have on the iPhone. Google and Apple have a strong relationship there and it would seem like Dalvik runtime would be a natural fit on the device if it is lightweight, fast and provides developers with the ability to write applications for both Android and the iPhone.

Comparing Web Development with Java and .Net

David — Mon, 22 Jan 2007 04:23:35 +0000

I was recently asked to comment on what the pros and cons were of Java compared to ColdFusion and ASP.Net when it comes to Web development. I guess the first thing to get straight with this question is what exactly constitutes 'Java' in a Web development sense.

The basics of the two technologies

The diagram below outlines the elements that comprise of Java and .Net Web development.

Both technologies are very similar as in essence Microsoft based .Net on many of Sun's original Java concepts and borrowed a lot of Java syntax when designing C#. Both utilise managed containers in which code is compiled and executed within. These containers are referred to as the JavaVM or CLR runtime in Java and .Net respectively. Both managed containers have the ability to execute code written in a number of languages, for example it is not uncommon to have a .Net application written in both VB.Net and C#. Whilst not as common the Java runtime is also beginning to support multiple languages such as Python and Ruby. Increased emphasis has come on this ability after the meteoric rise to fame of the Ruby on Rails Web development framework.

Looking at the diagram above you will notice that ColdFusion falls within the domain of Java. Whilst the language itself does not look very similar to Java this is just aesthetic, under the hood ColdFusion code is compiled into Java by the ColdFusion interpreter and then executed in the same manner as standard Java code. So any debate between whether to use ColdFusion or Java Server Pages (JSP) really boils down to what the developer is familiar with.

Industry Support

Java and .Net share extensive industry support and broad user bases. As shown by the O'Reilly analysis of reference book sales no single programming language has a clear lead when it comes to popularity.

Programming reference book sales (image from O'Reilly)

.Net's greatest advantage is that being a Microsoft technology it is integrated within the Windows Server family of products and installed on the majority of corporate desktops. Microsoft also has a strong history of excellent developer tools which enables the relatively rapid development of .Net applications via the Visual Studio suite. Whilst Microsoft's .Net framework is proprietary code that only runs on Windows, the Mono project (sponsored by Novell) is successfully implementing the API's and CLR runtime standards in open source code capable of being deployed on a range of platforms such as Linux and OSX. However it must be noted at this stage Mono does not cover 100% of the .Net API's or support the .Net 2.0 standard, limiting its applicability as a production level .Net platform.

Java development whilst lead by Sun is also extensively supported by industry heavyweights such as IBM and Google and a range of smaller but no less important entities, the most famous of which being the Apache Software Foundation. Recently Sun announced they would be open sourcing core Java technologies under the GPL. A significant benefit of this move is that it will allow Java to be tightly integrated into Linux distributions, easing deployment burdens for IT administrators. Unlike the one size fits all approach favored by .Net, Java is broken into a range of different frameworks which can be combined together to generate a unique set of functionality. This design also enables third parties to develop languages like ColdFusion that allow developers to utilise the power of many J2EE technologies without the added complexity.

And the winner is...

There is no clear winner when it comes to comparing Java and .Net simply because they are both so powerful and similar in design. Here is a short list of positives they both share:

An excellent suite of development tools
Relatively fast once compiled
Large developer bases
Comprehensive reference materials
Widespread industry backing

Compared to .Net, Java has the following benefits:

Open source platform
A distributed development community
More deployment and architecture flexibility as it is platform neutral

On the other hand .Net has the following going for it:

Microsoft backed and integrated into Windows
Concise platform controlled by Microsoft
Easier for existing Windows developers to adopt (i.e. C++ and Visual Basic coders)

When it comes to the speed at which one can create applications it really comes down to the skill individual developer (after all, bad craftsmen blame their tools). But even with this in mind compared to more agile Web centric programming frameworks like Ruby on Rails and PHP, both Java and .Net are painfully slow to develop for.

So if you are after a concrete recommendation then here is my situation dependent advice that I have gained from programming experience:

If you want a platform neutral, highly scalable and robust framework choose Java.
If you will only ever run Microsoft products and have a set of Windows centric programmers on hand then .Net is the easiest route.
If it is coding speed and flexibility you are after then checkout Ruby on Rails.
If you want something that is simple to deploy, relatively agile and easy to learn then PHP is the way to go.

The consequences of a GPLed Java

David — Wed, 15 Nov 2006 10:07:52 +0000

A few days back Sun offically announced they would be open sourcing Java under the GPL to applause from most of the industry. For a long time it was generally accepted that Sun would be fully open sourcing Java, the real question lay in exactly what license would be applied and how it would be undertaken. It turns out things will take about a year to be fully open sourced but even now the OpenJDK website is looking very promising.

From an end-user and developer perspective the GPL is by far the best consequence. As it is compatible with Linux we should be seeing Java making a bigger appearance within distributions. Currently all distributions have a means of installing Java but it is hardly mainstream but no doubt in the very near future we will start to see distributions appearing with a nicely packaged and easy to install Java stack. My guess is Ubuntu Server will be the first to take advantage of this new license given the close relationship they already seem to have with Sun. One thing I hope is a consequence of this release is better integration and support for servlet engines (i.e. Tomcat) within Apache. Personally I would love to see an Apache module that made deploying Java applications as simple as the current PHP modules. Sure JK is available for hooking Tomcat into Apache but anyone who has used it much will tell you that it is hardly straightforward and definitely not much fun compared to the easy life PHP has.

How this announcement effects other aspects of the Linux/Open Source world is hard to tell. David Berlind has an excellent post on how this news may effect the recent Novell/Microsoft patent deal especially considering when it comes to 'prior art' .Net and its runtime is a direct copy of Java. David Berlind writes some excellent articles and makes a good team with Dan Farber on the Between the Lines blog & podcast, David is often emotional with some left-field ideas but Dan balances this with a good dose of reality and industry skepticism.

linux
java

S3 meets Java meets WebDAV

David — Mon, 04 Sep 2006 21:48:38 +0000

The s3DAV looks like an interesting project. It is written in Java and exposes the Amazon S3 online storage service via WebDAV. It is promising because it looks like it can seamlessly expose S3 storage to users via most operating system's native WebDAV support. This will make using S3 as simple as using a network drive. Being Java it can run on just about any platform and either operate at the server or client level. If I had the time I would like to add authentication code to the project, it authentication to OpenLDAP/eDirectory and SQL databases would be a very handy feature to have if you wanted to expose the service to a number of users.

Interesting moves on the JavaVM front

David — Sat, 20 May 2006 07:22:38 +0000

Java One is turning out to be quite interesting this year. Not only has the Java license been changed to allow for easier distribution in Linux channels, but there is also a lot of buzz about coding in different languages for the JavaVM. The most tantalizing from a business perspective is Sun's commitment to get Visual Basic running within the JavaVM. Whilst it will not be practical to get Visual Basic applications written specifically for Windows frameworks running, (that is what Mono is for) it still will be interesting to see whether this significantly grows the Java (as a concept rather than a language) developer community. Even though Visual Basic may be ported across the fact it won't be tightly integrated into Windows like traditional Visual Basic it will more than likely not encourage a mass-migration of low-end, practical developers as some would hope. Still it will be nice to be able to get basic software written in by someone who only knows Visual Basic and have it able to run on any platform that supports the JavaVM.

More interesting from my perspective was the progress the JRuby project has made in getting the Ruby language ported to the JavaVM. Not only in the Ruby language over but even the Rails framework is beginning to run under Java. Admittedly it is a lot slower than the C version but from a deployment perspective it is very interesting as it would permit Ruby and Java applications to run and scale within the same JavaVM application engine.

java
ruby

Thomas Fuchs AJAX presentation & Google's AJAX API

David — Wed, 17 May 2006 20:42:22 +0000

Thomas Fuchs, the guy behind script.aculo.us recently did a presentation in San Francisco about AJAX that looked pretty interesting. He has is slide show online in PDF format here. Associated notes made during the presentation have been put online by the guys at Ajaxian.

Probably the coolest piece of information I did not know about was the link to a very cool window library for Prototype/script.aculo.us enhanced window objects.

At about the same time Google was announcing the immediate availability of their Google AJAX Toolkit for Java. It is interesting in that rather than acting as a HTML embedded AJAX library like Prototype/script.aculo.us is with Ruby on Rails this API seems targetted at Java coders used to writing Swing/AWT (desktop) application interfaces. This does not appeal to me much, I prefer the HTML/controller level coding of Ruby on Rails than writing a completely abstracted user interface in Java. Still the toolset provides a means by which a great many traditional desktop application programmers can start writing for the Internet using a toolset that is very similar to those available on the desktop.

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.