Techblog @ degenring.com

iBeenThere - my new iPhone app

Sun, 15 Aug 2010 20:33:02 +0200

Mobile applications are the big thing these days, thanks to great devices, always-on Internet, and market places like Apple’s app store that makes it easy for users to find, download and pay for applications.

In a technology study back in 2008/2009 I made first steps on iPhone application development which is quite different than what I do in most of my consulting projects. Instead of Java and frameworks like Spring that run in enterprise environments with huge computing power, it is based on Objective C and Cocoa Touch, and runs on mobile devices with limited computing power. In case of iPhone apps that means - in some respects - back to the roots! You don’t even get garbage collection on the iPhone - I almost had forgotten how tedious manual memory management can be. Forget to release a pointer and you end up in memory leaks - forget to retain a pointer and you will run into application crashes. On the other hand, you get many great components out of the box, like location services.

Recently I decided to implement decided to implement one specific iPhone application and bring it to App Store myself.

The idea behind “iBeenThere”: Make it fun for travelers to let their friends back home know where they’ve been and what they’ve done.

I could imagine a whole platform around that idea, but version 1.0 focusses on a very simple core of that idea: Add location-information to Facebook status updates.

Development went surprisingly quick - I was able to submit it to Apple as early as 2 weeks after I started coding, while I was working for a client on a full-time consulting project at the same time. It was fun, as iBeenThere integrates exciting mobile and web technologies like iPhone location services, Facebook and Google Maps.

See www.degenring.net/iBeenThere for more details.

Depending on the user feedback I might invest more time into iBeenThere, and fully realize my original idea, a full-featured travel blog service. Even if not: I’m sure my professional focus will include mobile apps more and more in the future - no matter if for iBeenThere, for other products I build on my own, or for consulting projects.

Clean Code Developer Initiative

Mon, 4 Jan 2010 07:38:20 +0100

The other day I came across the Clean Code Developer Initiative, initiated by two German software consultants, and inspired by the book “Clean Code”.

They say that to be a true professional in software development, just earning money with it, is not enough. They suggest a common set of principles, values and best practices that should be followed by all true professionals.

With most of their principles I fully agree, for example:

Keep It Simple, Stupid (KISS) and You Ain’t Gonna Need It (YAGNI) - also see my Mission page why I think these are some of the most important principles in Software Development - they are far too often violated

Favor Composition Over Inheritance - Beginners tend to use Inheritance in Object-Oriented Systems far too often; in most cases, Composition is much better, because of loose coupling, better testability and flexibility

Root Cause Analysis - Analyze thoroughly before acting

Reflect daily - Always ask yourself, is it really the right way I’m doing it?

Separation Of Concerns and Information Hiding - Sounds obvious, but when looking at some real world systems... oh well...

Continuous Integration including Automated Integration Testing

SOLID principles, from Single Responsibility to Dependency Inversion

Peer Reviews

... and so on

For more details, see the www.clean-code-developer.de web site - currently only in German though. Highly recommended reading for all professionals in Software Development!

20 years ago... My first steps in professional software development

Thu, 27 Aug 2009 20:57:57 +0200

The other day, my old high school friend Tobias sent me a copy of this article in the German computer magazine “Bit Markt”, published in 1989.

It reviews my very first commercial software product: “Print Label”. A DOS-based program that made printing labels easier.

That were the good ol’ times of MS-DOS, PCs with 256kB of RAM and 4.77 MHz CPUs, 5.25” 360kB floppy disks and - cutting edge technology! - hard disks with 10 or 20 MB capacity. And printers were unable to process single sheets of paper, but instead only could print on continuous fan-fold paper. Most people knew absolutely nothing about computers at that time. I was 13 years old and in high school. Computers had been one of my hobbies for a couple of years after my older brother had introduced them to me, and from the beginning I found writing small programs much more fascinating than playing computer games.

Print Label was inspired by my high school friend who had a computer, and a printer, too. He got a pack of labels from his dad and wanted to print addresses on them, only to find out there was no easy way to do so. The idea was born, I started almost immediately programming, and a few days later the first functional beta was ready.

After some more time and a couple of additional releases, I started selling the software through small advertisements in computer magazines. A limited trial version was available for 5 German marks (around 2.5 euros), and the full version for 20 DM (around 10 euros). And people were indeed buying it, and many users seemed to be happy. I think I sold 20 or 30 full versions or so, and even more limited versions ... not a bad income for a 13-year-old at that time!

As the article reminded me, Print Label even included a small database called “Label Base”. It was limited to 75 entries. I think it might be due to the fact that I knew nothing about linked lists at that time and held the whole database in an array :-)

Print Label supported Star LC 10 and NEC P6 printers - that’s because Tobias had a Star LC 10 and I had a NEC P6 :-) But it was extensible, and users could define their own printer drivers! Yes, at that time most PC users had technical know-how, not just user knowledge. Do you remember printer escape sequences? They were used for controlling the printer, for example to activate different fonts or styles like bold and italic. The printer manual consisted of pages full of such escape codes, and they were proprietary for each manufacturer and model...

Using 3G as a backup Internet connection in Shanghai

Fri, 17 Jul 2009 15:08:10 +0200

Since January 2008 I’ve been based out of Shanghai, China. Despite being based out of this part of the world, many of my clients are European companies. Thanks to Internet and modern communication facilities, like Voice over IP, teleconferencing, and of course email and chat, working with customers over large distances in general works out really well. (I’ll probably publish another article on my general experiences later.)

One major pain for all digital workers in China with international projects, however, is the Internet speed over here. DSL lines are available everywhere, with nominal download speeds of 2MBit/sec or so, and upgrades of up to 100MBit/sec have been announced. The problem is the fact that actual results vary a lot, especially when accessing servers outside of China.

One of the reasons, of course, is the Great Firewall of China - mainly a means for censoring content that is considered to be illegal, subversive or obscene by the Chinese government. While it is easy to get around this censorship (through a VPN or proxy, for example), not surprisingly, the filtering costs a lot of performance.

On the other hand, the Great Firewall does not seem to be the only limiting factor. If you use Internet from different locations, like home and office, as well as different parts of the city, and a different daytimes, you notice very different throughputs.

So a couple of days ago, I decided to get a second channel that I can use anywhere in Shanghai in case the main connection is not as responsive as I need it to be: I bought a China Unicom 3G UMTS USB stick. For 150 RMB a month (around 16 EUR) you get a 3 GB package.

(Notice that China Mobile, that I use as my main mobile operator e.g. on my iPhone, offers similar packages, but only provides GPRS/EDGE speed. The 3G service that they are building up is not compatible with international UMTS equipment.)

After doing some sample tests, China Unicom 3G seems to be a good alternative, when data gets stuck on the main DSL connection!

I used speedtest.net to compare the speed when accessing a server in Frankfurt, Germany from Shanghai. In this sample, I got around 1.45 MBit/s download, 350ms ping and only 0.09 MBit/s upload using the normal China Telecom DSL line in my home office (without VPN). Compare that with the 2.39 MBit/s, 1.03 MBit/s and 469ms ping time using the China Unicom 3G connection! Results are similiar when tunneling through UK-based or US-based VPNs over the same connections.

Here are the detailed results:

China Telecom DSL, Shanghai to Frankfurt, no VPN:
1.45Mb/s DL, 0.09 Mb/s UL, 350ms ping

China Unicom 3G UMTS, Shanghai to Frankfurt, no VPN:
2.39Mb/s DL, 1.03 Mb/s UL, 469ms ping

China Telecom DSL, Shanghai to Frankfurt, via Los Angeles based VPN:
1.49 Mb/s DL, 0.12 Mb/s UL, 369ms ping

China Unicom 3G UMTS, Shanghai to Frankfurt, via Los Angeles based VPN:
2.51 Mb/s DL, 1.55 Mb/s UL, 470ms ping

China Telecom DSL, Shanghai to Frankfurt, via UK based VPN:
1.55 Mb/s DL, 0.13 Mb/s UL, 323ms ping

China Unicom 3G UMTS, Shanghai to Frankfurt, via UK based VPN:
I lost the exact numbers, but results were very similiar to Los Angeles based VPN.

Web site updated - after battling with iWeb 08

Fri, 7 Mar 2008 11:44:17 +0100

As you might have noticed, I uploaded a new version of this website. This had been due for a couple of weeks, but I postponed it after I had upgraded to a new software version. I am not (and don’t want to be) a web designer, and I do like Apple’s iWork/iLife suites for their simplicity and elegant results. Therefore I used iWeb to create these pages.

While it’s a great tool for creating good-looking web pages with little effort, the generated HTML files are at least questionable. The previous version of this web site was created with iWeb 06 which had a couple of severe problems: For example, it didn’t reuse images that are the same on multiple pages, and the URLs of blog pages were created out of non-speaking IDs instead of the blog page title. Luckily with the help of tools and scripts, many of these problems could be fixed.

As most Internet professionals know, Microsoft Internet Explorer 6.0 is another source of problems for many web sites, as it’s full of bugs in terms of compliance to standards. For example, it does not display PNG images properly. Apple uses PNG by default, and generates JavaScript code to fix this and other issues, but web sites take longer to load and if JavaScript isn’t active, these workarounds don’t work. As until recently, many large corporations still used MSIE 6.0 as their default browser, I decided to convert all PNG images to JPG images using scripts. On my website, no transparency effects (supported only by PNG) are used, so this worked fine.

After upgrading to iWeb 08, I noticed that Apple on the one hand had fixed at least some of the iWeb 06 problems. On the other hand, Apple now uses even more JavaScript than before. Now even basic navigational elements, such as the menu bar or blog summaries are created at run-time using JavaScript. After battling for some time with adjusting and reapplying my scripts to the iWeb 08 pages, I finally decided it’s currently not worth the hassle to try to workaround iWeb to support outdated browsers or browsers without JavaScript.

MSIE 7.0 has been out for one and a half years now, and there are so many pages out there nowadays that do require JavaScript.

I hope that especially visitors from large corporations are still able to view my web site properly (here is a screenshot of the welcome page). In case of any problems, please contact me.

In that case, however, I would probably stop using iWeb, and instead use other tools, hand-code the HTML, or most probable, generate basic HTML out of a web site model.

Maven repositories in corporate environments

Fri, 26 Jan 2007 18:24:14 +0100

During the last months, I provided consulting services to the application development department of a banking corporation. I helped them improve their software development productivity - by improving processes and tools, and by providing frameworks and "best practices" to developers. We quickly identified build automation and continuous integration to be one of the topics with highest priority, and so we built up a build automation framework based on Apache Maven 2 including the Continuous Integration Server Continuum.

This articles contains some recommendations for establishing Maven as a build system in corporate environments. It is not meant as a complete guide, but discusses some thoughts about how to deal with Maven repositories - an issue that you very soon come across when adopting Maven for your company.

In a previous article, I provided some basic information on the benefits of build automation and continuous integration, on Apache Maven and Continuum, as well as links where you can find additional information.

Set up your own repositories

By default Maven tries to download all build-relevant artifacts from a public Internet repository on repo1.maven.org to each developer's local repository. While this is very convenient for many open-source projects, the direct access to this repository by each developer is not acceptable for many companies.

First of all, it is obvious that the closed-source applications or libraries that your organization develops in-house, cannot be uploaded to the public repository. The same is true about any third-party libraries that you licensed for your company. To support sharing such artifacts among your developers, set up a company-internal repository.

But even regarding artifacts that are indeed available in the public repository you don't want every developer to directly access that repository, not only due to bandwidth considerations. There are two main approaches:

Proxy approach: You can set up a Maven-capable proxy server for your organization. It dynamically mirrors public repositories such as repo1.maven.org. When a user tries to access an artifact, the proxy server first checks whether the artifact is already available locally. If it is, the proxy delivers it back to the client. If it is not, the proxy downloads it from the public repository, stores it locally and delivers it back to the client. Ob subsequent requests, there's no need to access the public repository again. Typically, such proxy servers can be configured to dynamically mirror more than one public repository. Like this, several repositories can be aggregated into one internal mirror.

Non-proxy approach: Another option is to set up a company-internal repository also for publicly available artifacts, and to upload libraries manually to the repository as you need them.

The non-proxy approach gives your company much more control: You stay in full control which libraries may be used in your company and from what sources they come from. In contrast, by using the public repository you give up some of that control: Someone from outside your company has uploaded the library to the repository. In theory, it could be a faked version containing malicious code. Even though this is highly unlikely for the public repositories managed by the Maven team or by the open-source projects themselves, man-in-the-middle attacks are possible, at least in theory. Instead, when managing the repository on your own, you even have control about which versions of libraries may be used within your company.

But, of course, there's no free lunch: Managing an internal repository for publicly available artifacts means a significant amount of extra work: First of all, you need to identify the correct names and version numbers of the libraries you want to upload. Try to use the same names as on public repositories - that keeps your builds portable in case you change the approach later on. When uploading a JAR file "as is", your repository won't contain much metadata other than the name and version number. In contrast to that, the public Maven repositories contain additional metadata for many artifacts, especially dependency information. If you don't specify a pom.xml containing dependency metadata when uploading the JAR, you lose Maven's powerful transitive dependency management for such artifacts.

Delivering Maven plugins

The build system Maven has a rather small kernel that takes care of such fundamental things such as dependency resolution, repository access and interpretation of the pom.xml. Build steps like compiling sources or packaging JARs are executed by Maven plugins. The most important plugins are maintained by the Apache Maven project itself, but there are other sites like mojo.codehaus.org that provide useful plugins as well. You can even write your own plugins.

Maven accesses plugins just like any other artifact: It downloads them from a remote repository to your local repository, if the plugin isn't there yet. To provide the plugins for your developers, you have the same options as with other build artifacts: You can set up a proxy or you can manage your own internal plugin repository. And then there's a third option: ZIP together a Maven distributable for in-house distribution that contains not only the Maven kernel and common settings, but also an initial local repository with all necessary plugins. It is anyway advisable to create your own Maven package for distribution within your company, e.g. containing common settings.

Choosing the right approach

So... which approach should you choose for your organization? It depends and there's a tradeoff. For many companies the proxy approach will be more convenient and straightforward while other companies, e.g. in the financial services industry, will be forced to use the non-proxy approach due to security restrictions, at least for normal build artifacts. For Maven plugins, however, it would be far too much work to manually upload all necessary plugins to an internal plugin repository.

No matter which approach you use, make a distinction between in-house artifacts, "free" (open-source) external artifacts, non-free (licensed) external artifacts and Maven plugins. For in-house artifacts, a separation of released versions and "snapshot" versions (interim versions created during development) makes sense.

Setting up an internal repository and/or proxy server

To set up an internal repository, you just need to provide an URL-accessible location, e.g. an HTTP-server. HTTP is the most common and platform-independent option to read from the repository. Uploading options include file-system or network share access via file:// URLs, SCP, WebDAV and others.

If you choose to set up a Maven-aware proxy server, there are at least three options: Maven-Proxy was one of the first available products. It is a self-contained server and is relatively simple: It acts as a proxy but doesn't do much more. If Maven-Proxy runs behind a company firewall, it typically needs to go through an HTTP proxy. Notice that Maven-Proxy has very limited support for proxies using NTLM authentication (= mainly Microsoft proxy servers).

A more powerful option is Proximity. To the normal proxy feature, it adds features like repository browsing and searching, and comes with predefined profiles for personal and corporate use. Proximity can host your internal repositories as well, so it is a kind of "2-in-1" solution.

The Maven project itself has started a subproject called Archiva. It is promising, but currently in an alpha stadium. If you want to check it out, you need to get the source code and build the project yourself. Many companies prefer to wait for a stable release before using Archiva.

Build Automation and Continuous Integration using Maven and Continuum

Wed, 27 Dec 2006 12:52:24 +0100

This article describes some of the benefits of build automation and continuous integration and provides basic information on Apache Maven 2.

To build software means all steps that are necessary to transform source code into executable units for your target platform, including compiling, testing, creating documentation, packaging and so on. Automating the build process has many advantages on productivity and quality: Developers need to perform fewer manual steps and the build output is reproducible, no matter who performed the build. Errors can be avoided. The fact that builds can be performed at the push of a button makes it easier to test applications early and often on their target environments. That way, quality and productivity are increased as well. Barriers that prevent new developers from quickly becoming productive are teared down.

And then, automated builds make the idea of Continous Integration (CI) possible. Your CI server can check out the newest source changes from the source code repository and perform automated builds regularly (from nightly up to immediately, i.e. after each check-in). In case of any errors, the CI server informs the developers via email. As such feedback is delivered very soon after checking in an incompatible change, it is easy to find and fix the bug. And, your organization always has a current build for testing on the target environment available.

Basic concepts of Apache Maven 2

Many projects nowadays use build scripts based on Apache Ant for automating their builds. But the build subtasks that have to be solved are quite similar in many projects which is why also the build scripts often look similar. This is like reinventing the wheel again and again, so to speak. Furthermore, in complex projects, managing dependencies often is difficult - both managing inter-project-dependencies and managing dependencies to third-party libraries.

Maven tries to solve these difficulties using the following concepts:

Standardization instead of configuration:
Maven suggests a basic structure for projects (e.g. directories for sources, test files, resource files etc.). As long as a project adheres to this structure, very little configuration is needed for build automation. Basically one has to specify what kind of artifact should be produced (the so-called packaging, e.g. JAR, EAR, WAR, ...). Maven contains ready-to-use build processes for the typical artifacts that include all typical subtasks (e.g. generation, compilation, tests, packaging, ...).

Flexibility through POM and Plugins:
The main definition file for the build process of a project is the so-called "Project Object Model", in short POM or pom.xml. In this file, you can optionally customize every single subtask of your build, e.g. regarding custom directory structures or custom subtasks. Maven plugins can be called within your build, e.g. for generating a project website. The "antrun" plugins even allows for the execution of ant scripts within a build process.
The variety of ready-to-use Maven plugins is one of Maven's strengths. The most essential ones are provided by the Maven project itself. Other projects provide a bunch of additional plugins for different purposes. For example, it is very easy to integrate a test coverage analysis tests into your builds, using the "Cobertura" plugin.

Dependency management and repository:
In Maven-based projects you would not store the required JAR library files directly within your project. Instead you just declare all dependencies within your POM by specifying the artifact's name (e.g. log4j) and its version number (e.g. 1.2.8). All artifacts are saved in a central repository. Maven loads the required files into a local repository during the build execution (but only if this hasn't been done before). Afterwards the build can be performed locally.
Maven's dependency mechanism is very powerful due to its support for transitive dependencies. Example: Struts is dependent on commons-beanutils and commons-digester. Within your Struts-based web application, it is sufficient to declare a dependency to Struts. Maven loads commons-beanutils and commons-digester automatically.

Component overview

The following components are important for a Maven-based build framework within a company:

Local Maven installation:
Every developer needs to have a local Maven installation on his workstation. The local Maven installation is a command line tool, comparable to Ant. You need it for performing a build locally. Due to the fact that required JAR files are not stored within the project itself but must be loaded from the repository by Maven, even for editing the source code within an IDE like Eclipse, Maven is needed.

Local repository:
Maven stores all artifacts that have been downloaded from the repository (e.g. log4j.jar, ...) in a local directory structure, the so-called "local repository". That way, they can be used locally, e.g. as class-path entries for the Java compiler. Maven even stores its own plugins within the local repository.

Public repository on repo1.maven.org:
By default Maven tries to download all build-relevant artifacts from a public Internet repository on repo1.maven.org. While this is very convenient for many open-source projects, the direct access to this repository by each developer is not acceptable for many corporate organizations. (Some recommendations for corporate users follow later-on.)

Custom repositories:
You can also set up your own repositories which is very much recommended for corporate users (details follow later). A repository is just a directory structure, accessible through the file system or (recommended) through http or other protocols such as scp.

Continuous Integration (CI) Server:
Continuum is a Continuous Integration Server developed within Apache group's Maven project. It is a web application that can run builds regularly and automatically, send mails regarding build errors and so on. Use Continuum's web interface to conveniently define the auto build processes and always inquire the current build status. Continuum itself uses a local Maven installation including a local repository.

Further reading

• Article by Martin Fowler regarding Continuous Integration
• Free book on Maven 2
• Apache Maven web site
• Introduction into Maven 2.0
• The Maven 2 POM Demystified
• An overview of books and articles about Maven
• Mailing-list Maven-Users
• Mailing-list Continuum-Users
• Bugtracking-System
• Maven’s default directory layout
• Test coverage analysis using the Cobertura plugin for Maven 2

In newer blog entries, you can find recommendations for corporate users.

Enterprise Service Bus: Some links and resources

Mon, 4 Jul 2005 22:47:46 +0200

JavaSPEKTRUM 4/2005: "Enterprise Service Bus: Plattform für Service-orientierte Architekturen"

Mon, 4 Jul 2005 22:44:26 +0200

Integration der IT-Systeme wird für viele Unternehmen immer wichtiger. Die historisch gewachsenen Strukturen und Schnittstellen zwischen den Systemen sind schwer zu warten. Ein "Enterprise Service Bus" ist eine Middleware, die besonders für den Aufbau Service-orientierter Architekturen (SOA) geeignet ist, und außerdem Ideen aus der klassischen "Enterprise Application Integration" (EAI) übernimmt.

Zur Online-Version des Artikels

JavaSPEKTRUM 3/2005: "Interview mit Dave Chappell"

Wed, 8 Jun 2005 21:26:12 +0200

Im Auftrag des JavaSPEKTRUM hatte ich Gelegenheit zu einem Interview mit Dave Chappell, einem Pionier im Bereich Enterprise Service Bus. Er hat über 20 Jahre Erfahrung in der Softwareindustrie und arbeitet heute als "Vice President & Chief Technology Evangelist" bei Sonic Software, einem Vorreiter und Anbieter von Produkten zum Enterprise Service Bus (ESB).

Zur Online-Version des Interviews