Tuesday, April 21, 2009

[Tech] What about Maven 3

At thte last Maven Meetup Jason van Zyl talked about the future of Maven and important milestones of Maven 3, including:
  • Support of incremental buildings
  • Changes about the Plugin-API
  • Better Multilanguage support
  • and more
The video and slides about the presentation are available here.

[Misc] Sun and Oracle

Now it finally happened: Oracle bought Sun for 7,4 billion dollar. It sure is a little bit surprising, as the deal with IBM seemed to be settled already. From a developers point of view, the Oracle deal might be better for the community, allthough it also has certain risks.

For IBM Java is strategically very important, insofar Java would have been "save" with IBM. Additionally IBM has developed (similar to Sun) a solid Open Source strategy over the last decade which would also fit to Sun. However, a significant amount of their product lines would have overlapped: Both have Middleware products like Websphere and the Sun Glassfish project portfolio. Both have a series of database products: mySQL at Suns side and of course the DB2 line on IBMs side, and a similar story on the OS front: the probably superior Solaris versus IBM AIX. Finally Sun has the Netbeans IDE as central development tool whereas IBM has Eclipse. I doubt that IBM would have had a lot of interest in doubling all these product lines. Not to mention the Sun hardware.

Now, on the paper Oracle looks much more "compatible" to Sun. True, there are some overlaps in the middleware section. Most "afraid" might be the mySQL folks, as Oracle already showed some hostility against mySQL in the past. Then again, when they own the product, they probably can sell it in their database portfolio in the "low-end" market. Java is also important for Oracle and probably even more important is the operating system Solaris and the Sun hardware and a tight integration to e.g. the Oracle database. With these assets Oracle can offer "end-to-end" solutions starting from hardware, operating system, storage, solutions, database, middleware, web-frameworks and integrated development environment.

What worries me a little bit with Oracle is the lack of experience in the Open Source community. Oracle is in my opinion a rather closed shop compared to IBM and Sun. Maybe Oracle can learn a little bit from Sun's experience here. However, my fazit is, that there is significant potential in the combination of Sun and Oracle (probably more than with Sun/IBM) but also some significant risks in terms of openness and for certain parts of the Sun product line. I am particularly looking forward in terms of the consequences for the Open Source middleware-portfolio, Java and mySQL.

Update: Larry Dignan from zdnet blog writes about mysql:
"Oracle gets to kill MySQL. There’s no way Ellison will let that open source database mess with the margins of his database. MySQL at best will wither from neglect. In any case, MySQL is MyToast."
Well, I would not bet on that (but probably would not start a new project with mySQL either...), but it is for sure an option.

Tuesday, April 14, 2009

[Arch] Maven Best Practices

In this blog of sonatype there is a useful list of best practices with Maven, including:

  • Why putting repositories in your pom is a bad idea
  • Best Practices for releasing with 3rd party snapshot dependencies
  • Maven Continuous Integration Best Practices
  • How to detect if you have a snapshot version
  • Optimal Maven Plugin configuration
  • Adding additional source folders to your maven build
  • Misused maven terms defined
  • How to override a plugins dependency
  • How to share resources across projects
  • How plugin versions are determined
Before you search in mailing lists, look at the list, it will help you.

Saturday, April 11, 2009

[Misc] Open Protocol vs. Twitter: 1:0 ?

In a current ZDNet Blog Posting, Sam Diaz analyses the recent technical issues Twitter has (again). Twitter is growing dramatically in the last months and apparently the Twitter backbone is increasingly in trouble. The same happened already about a year ago.

The analysis of Sam Diaz is of course correct, but in my opinion he still completely misses the point in discussing technical issues why Twitter might or might not catch up with the upcoming demand in the service. The point actually is, that the communication concept of Twitter is appealing to many people, which is good, but in the history of the Internet it was never a good idea to rely on a proprietary protocol in any important communication channel.

So the real question is a much more generic and actually should be: how can we get rid of Twitter as fast as possible and replace it with an open protocol and a scalable distributed architecture, comparable to Email, XMPP chat and the like. There are good reasons why proptietary protocols largly failed on global communication systems like the Internet; those that are still around are a continuous pain in the ...

I confess, I am using Twitter as well, but it is of course a lock-in situation. If you want to follow the interesting stuff, you currently have to use Twitter. However, now we still have time to replace Twitter with something like Laconica (identi.ca) or anything similar down the road. Even better, Twitter might open up it's system and try scaling it that way. However, now is the time to act: Twitter is still a toy, but it is on the way to become a serious communication system we might depend upon in some years. And I believe, no one wants to depend on a communication system that is proprietary and unreliable at the same time.

Friday, April 10, 2009

[Process] Successful Distributed Agile Development

Andy Singleton from Assembla wrote a nice blog entry about success-factors in distributed agile development. He focusses on 6 factors:
  1. Fix-schedules for releases
  2. Continuous Build
  3. Ticketing
  4. Daily Report and Chat
  5. Team-Activity Streams
  6. Recruitement
I am missing automated testing and QS though, which I believe is a cornerstone in distributed development, particularly in combination with a continuous build/integration setup. Read the full article here!

Thursday, April 09, 2009

[Tech] Mavenizing AppEngine!

As I nagged yesterday about the fact, that AppEngine has no proper Maven-build system, already today the guys at Sonatype reacted ;-)

They describe preliminary attempts in how to "Mavenize" AppEngine projects; hope they will be able to fix also the last issues!

Wednesday, April 08, 2009

[Tech] Google AppEngine (and Java)

AppEngine is a rather recent new service from Google. It is probably Google's answer to Amazon's cloud-computing platform, yet targets a very different market. Where Amazon offers a a broad range of services and high flexibility (with the disadvantage of higher administration effort) Google targets web-developers that want to publish web-applications. AppEngine started with a Python environment, now since some days the long anticipated Java-version (Java 5 and 6) is online. Now what are the benefits of using AppEngine?


First of all, it is possible to deploy applications without having to install, administrate and maintain an own server (instance). Google provides a runtime environment (sandbox) into which Python or Java applications can be deployed. Access to these applications is (for clients) only possible via http(s). So this is a feasible approach for web-applications or RESTful services.

An additional advantage is, that Google deals with scaling issues, i.e. it scales the applications dynamically to the demand. This is a significant advantage for startups, that have no clear idea about the number of customers they are going to have or how fast this number is growing. For the scaling to work, though, some restrictions have to be considered. Most notably this concerns the persistence strategy. E.g. applications (and libraries!) are allowed to read files from the filesystem, but are not allowed to write. For all persistence issues, the Google datastore has to be used. However, what is nice with the new Java-sandbox is the fact, that Google apparently tries to follow established standards. For persistence Java developers can use JDO or JPA or a low-level interface for the distributed datastore.

I wonder, however, how logging can be handled in that environment. Logging is usually done to a file or to a JDBC datasource. A JDO logging target I have not seen before; ideas anyone?

Generally spoken, arbitrary Java libraries can be deployed and used in the AppEngine as long as they do not violate the AppEngine sandbox. Also due to the scaling-approach not all libs/frameworks will run unchanged. As yet, it seems not quite clear for example, which Java Web-Frameworks will run seamlessly in the App-Engine. Googles webtoolkit (GWT) should work, other framework communities are currently testing their frameworks for compatibility, e.g. in the Apache Tapestry and the JSF framework Apache myFaces discussions are running on the mailinglists.

Build Automation and Development Process

The development process is, in my point of view, as also with other Google environments like GWT a mixed blessing. Everything is Eclipse centered, which is not really a good thing: Google provides an Eclipse plugin for the AppEngine including a runtime environment for testing applications offline. This is great for daily development activity, but not for a stable build- and testing environment. Unfortunately Maven support (like archetypes) are completly missing at the moment. Google is apparently pretty hostile towards Maven and focuses mostly on IDE integration, which is definitly not a sound way for a modern build automation. IDE "wizard-based" SE approaches usually turn out to be unstable and problematic, particularly in team-projects. This might be nice for a fast hack, but is no basis for a larger project. It seems, that some support is given for Apache Ant though.

Hopefully other developers will provide a Maven integration for the Java AppEngine. With the current approach not even an IDE-less deployment is possible.


So, despite of the build-issues, I believe that the AppEngine is a great option to deploy web-applications in Java or Python. For small applications (small in the sense of "low web-traffic"), the AppEngine is free, after exceeding certain thresholds (CPU, storage, bandwith...) one pays according to the resources needed. Google provides a web-interface to set daily financial limits for individual resources. E.g. one wants to spend a maximum of 5 $ a day for CPU time and so on.

Looking forward to the first experience reports, particularly with web-frameworks like Wicket, Tapestry or Cocoon.

Wednesday, April 01, 2009

[Misc] Operating Systems for Netbooks

Netbooks are different from notebooks and desktops; they are used in other contexts, have smaller screens, not so powerful hardware, less diskspace and so on. Windows is hardly the best system for regular desktops and notebooks (in my opinion) and definitly only a temporary solution for the netbook market. Microsoft even had to reanimate Windows XP for that purpose. In effect, Windows is to fat, too insecure and not optimised for small screens and additionally hardware producers have to pay license fees to Microsoft in a very tight market, where some Euro can make a difference.

Since some months the companies like HP apparently are evaluating Google's Android for Netbooks. Now, I am all for Android; But on mobile phones. I am doubtful that Android is a good solution for netbooks though. Android was designed for the typical smaller scale mobile applications e.g. with only "one application" active on the screen. And resource management that focuses on one active application. Now, a Netbook might have a small screen as well, but from the usability point of view it is probably closer to the notebook than to the mobile phone.

Hence customers expect applications in a style they know them from their desktop, like Office or Internet applications (mail, browser, ...). Using Android reduces the number of suitable applications dramatically, and Android applications written for Android cell-phones will most likely not perform well on Netbook hardware.

Now, Linux was already used on several Netbooks like on the EEE-Series. Why not stick to Linux? Probably adapt an existing distribution like Ubuntu to better fit to that specific environment. Then immediately the whole range of destop applications are available including applications like Open Office.

From the software engineering aspect, I would believe, that it is better not to mix up mobile platforms with Netbooks, in the end either applications have a bad user experience on the specific platform they were not developed for (allthough both use the same OS).

But maybe I am proven wrong?