ShowOff is great if you are fed up with the bloated presentation applications that make a mess of your source code. Text files means that presentations can be properly version controlled. It's easy to re-arrange slides and sections. ShowOff uses SHJS to highlight code blocks. It supports many languages, but currently not Clojure. Searching around for a while revealed a Gist of SHJS styling code that I wanted to try out:

# Clojure syntax highlighting for GNU source-highlight
# rocks with SHJS
comment start ";"
include "number.lang"
vardef SPECIALCHAR = '\\.'
environment string delim "\"" "\"" begin
  specialchar = $SPECIALCHAR
end
type = "int|byte|boolean|char|long|float|double|short|void"
vardef FUNCTION = '\(([[:alpha:]]|_)[[:word:]]*(?=[[:blank:]]*)'
function = $FUNCTION
include "symbols.lang"

This is what I did on my MacOSX Snow Leopard to get ShowOff to high-light Clojure source code:

1. Install some pre-requisites. I use HomeBrew, but you can use MacPorts or whatever package manager you prefer.

gem install showoff
brew install yuicompressor
brew install source-highlight
brew install unix2dos

2. Download the shjs source distro.

3. Unzip shjs-0.6-src.zip somewhere which we will call SHJS_HOME

4. cd SHJS_HOME

5. touch source-highlight-lang/clojure.lang

6. Edit source-highlight-lang/clojure.lang and paste this Clojure source code high-lighting spec (that's the same as displayed above).

7. My Perl installation needed a recursive descent parser, so I did this:
cpan install Parse::RecDescent

8. make

9. I then copied the resulting minified JavaScript file to where my ShowOff gem keeps the language style files. I use the RVM Ruby manager, so this is where I needed it:

cp lang/sh_clojure.min.js ~/.rvm/gems/ruby-1.9.2-p290/gems/showoff-0.4.2/public/js/sh_lang/

Should you discover that you need some more tools installed, you can clean up with make maintainer-clean. After you installed whatever you were missing, run make again.

Testing Clojure high-lighting

In order to test this, we will create a simple presentation called "mypres":

showoff init mypres

This creates a new directory mypres. We go to that directory and look around:

.
├── one
│   └── 01_slide.md
└── showoff.json

OK, so we have now the skeleton of a presentation, containing a section folder named one and a set of slides in the 01_slide.md file. Looking closer at that file, we see this:

!SLIDE
# My Presentation #

!SLIDE bullets incremental
# Bullet Points #

* first point
* second point
* third point

We will now add to this file a slide definition with some Clojure source code, formatted as a code block by indenting it. Note that we have preceded the code with @@@ clojure, in order to tell ShowOff what language we want to format the block as:

!SLIDE encode-symbol
# Huffman encoding #

	@@@ clojure
	(defn encode
	  "takes as arguments a message and a tree
	 and produces the list of bits that gives
	 the encoded message"
	[[first & rest :as message] tree]
	  (when (seq message)
	    (concat (encode-symbol first tree)
	            (encode rest tree))))

We serve the presentation:

$ showoff serve

Finally we can watch the presentation by browsing to http://localhost:9090

ShowOff source code high-lighting for Clojure

Then I thought that maybe I should stop syncing mail so often and se what effect that would have. When I tried to change my settings I saw how it was syncing mail, lots of mail in my account. It never seem to stop and suddenly it hit me:

I might have set it to sync my All mails folder in my Google mail, and that isn’t a good thing. If it tries to sync all then there is 56 472 conversations dragging around in my Google account (I haven't thrown away any mail, except for spam mail and mailing list, the last 8 years). And even if I narrow this down to the last 7 days it’s a lot of mail to sync in the background. No wonder it was draining the battery. An I was right.

Actually here are a few areas that can improve in the user interface. Doing all this syncing was not good for the performance of the mail application either. I even had trouble to stop the sync of the All mails folder. And while the account was syncing I wasn’t able to remove it or change any settings on it.

In the end I figured that the easiest way to get rid of it all was to just go into flight mode, remove the account and then add it again (after going out of flight mode). This time I made sure it’s just the inbox that is synced. And now all is back to normal again or even better.

So be careful with what you sync or it may really kill the battery on your device.

If you have written a Java application and want to enable Growl notifications for it, you previously had the possibility to use cocoa Java bindings for Growl but they have been deprecated and are no longer supported. However, there is an AppleScript API that together with the AppleScript script engine can give access to Growl from Java. If you use Java 6 that is.

The example

This example code uses the Growl class, defined below, which uses the Growl AppleScript API and Java AppleScript script engine in OS X:

public class GrowlDemo {
    public static void main(String... args) {
        // System and boss messages will be enabled by default, spam must be configured in growl settings
        Growl growl = new Growl("Growl Demo",
                new String[]{"system", "boss", "spam"},
                new String[]{"system", "boss"});
        growl.init();
        growl.registerApplication();
        growl.notify("system", "System message", "This seem to be working");
        growl.notify("boss", "From: Big brother", "Get back to work!");
        growl.notify("spam", "Get a diploma", "By going to university");
    }
}

The output will look something like:

Demo code output

Now on to the Growl AppleScript API implementation.

The Growl code

In order to use the AppleScript engine, an engine and a context has to be retrieved. Here's an example:

ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine appleScriptEngine = scriptEngineManager.getEngineByName("AppleScript");
Script script = "<AppleScript syntax goes here>";
appleScriptEngine.eval(script, appleScriptEngine.getContext());

The rest of the code is just building the AppleScript API syntax for Growl:

package com.jayway.growl;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

/**
 * Notify with Growl using AppleScript and Java Script engine.
 *
 * @author Tobias Södergren, Jayway
 */
public class Growl {
    private static final String GROWL_APPLICATION = "GrowlHelperApp";
    private final String applicationName;
    private String[] availableNotifications;
    private String[] enabledNotifications;
    private ScriptEngine appleScriptEngine;

    public Growl(String applicationName, String[] availableNotifications, String[] enabledNotifications) {
        this.applicationName = applicationName;
        this.availableNotifications = availableNotifications;
        this.enabledNotifications = enabledNotifications;
    }

    public void init() {
        ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
        appleScriptEngine = scriptEngineManager.getEngineByName("AppleScript");
        if (appleScriptEngine == null) {
            throw new RuntimeException("No AppleScriptEngine available");
        }

        if (!isGrowlEnabled()) {
            throw new RuntimeException("No Growl process was found.");
        }
    }

    public void registerApplication() {
        String script = script().add("tell application ")
                .quote(GROWL_APPLICATION)
                .nextRow("set the availableList to ")
                .array(availableNotifications)
                .nextRow("set the enabledList to ")
                .array(enabledNotifications)
                .nextRow("register as application ")
                .quote(applicationName)
                .add(" all notifications availableList default notifications enabledList")
                .nextRow("end tell").get();
        executeScript(script);
    }

    public void notify(String notificationName, String title, String message) {
        String script = script().add("tell application ")
                .quote(GROWL_APPLICATION)
                .nextRow("notify with name ").quote(notificationName)
                .add(" title ").quote(title)
                .add(" description ").quote(message)
                .add(" application name ").quote(applicationName)
                .nextRow("end tell").get();
        executeScript(script);
    }

    private boolean isGrowlEnabled() {
        String script = script().add("tell application ")
                .quote("System Events")
                .nextRow("return count of (every process whose name is ")
                .quote(GROWL_APPLICATION).add(") > 0")
                .nextRow("end tell")
                .get();
        long count = executeScript(script, 0L);
        return count > 0;
    }

    private <T> T executeScript(String script, T defaultValue) {
        try {
            return (T) appleScriptEngine.eval(script, appleScriptEngine.getContext());
        } catch (ScriptException e) {
            return defaultValue;
        }
    }

    private void executeScript(String script) {
        try {
            appleScriptEngine.eval(script, appleScriptEngine.getContext());
        } catch (ScriptException e) {
            // log.error("Problem executing script, e);
        }
    }

    private ScriptBuilder script() {
        return new ScriptBuilder();
    }

    private class ScriptBuilder {
        StringBuilder builder = new StringBuilder();

        public ScriptBuilder add(String text) {
            builder.append(text);
            return this;
        }

        public ScriptBuilder quote(String text) {
            builder.append("\"");
            builder.append(text);
            builder.append("\"");
            return this;
        }

        public ScriptBuilder nextRow(String text) {
            builder.append("\n");
            builder.append(text);
            return this;
        }

        public String get() {
            return builder.toString();
        }

        public ScriptBuilder array(String[] array) {
            builder.append("{");
            for (int i = 0; i < array.length; i++) {
                if (i > 0) {
                    builder.append(", ");
                }
                builder.append("\"");
                builder.append(array[i]);
                builder.append("\"");
            }

            builder.append("}");
            return this;
        }
    }
}

That's it.

Design and performance over architecture and frameworks

We have to focus our attention on the user experience, how the application is perceived and not what technology is used or how the application is built. The important thing is that the application is well designed and that it responds to the user. SO to be a WP7 developer there are two things you really have to study, and study hard:

Design
Performance

We're not suggesting that you throw out all the knowledge around architecture and framework. But, if it impacts design and performance you should think twice about why. Also, as Johan Lindfors said in his session – “stop building frameworks! Start building applications”

Slides and samples

Anyway, to sum this up we share the slides on slideshare as well as provide the code and slides as files below.

Windows Phone 7 in blend and code – code
Windows Phone 7 in blend and code - slides

Resources

Following is a collection of useful links to get started with real development - just promise you don’t build another framework.

• The UI and interaction guideline for Windows Phone 7
• Jeff Wilcox designer guideline for developers
• Peter Torr’s memory profiler
• Silverlight Toolkit
• LowProfileImageLoader by David Anson
• DeferredLoadContentControl by Colin Eberhardt
• Peter Torr’s LazyListBox
• Gif decoder as part of the ImageTools for silverlight

Be creative! // Andreas Hammar & Håkan Reis

But let the touch stay there in a virtual interface on the screen. We all know and love what we got there. But if you have a real physical nice button DON'T MAKE IT A TOUCH BUTTON. Physical buttons should stay physical, a touch button is actually just an approximation to the real thing. That was cool in the 80-ties. If you really, really, can't help yourself, at least keep them safe from accidental touch. I’ll give you some example from bad to worse …

The new XBOX 360

This device uses touch to open the tray door and for the on/off switch. Its not a big problem here, the XBOX isn’t moved around much and mostly you don’t touch it by accident. But sometimes, you need to move it. I have it hidden away and I was opening the doors and accidently opened the tray. The sound it made when it hit the wall wasn’t too pleasing but it survived.

My stove

This one is even more annoying. The buttons are placed close to where you normally would have physical buttons and it works well when you and navigate them. But there are a few occasions… If you accidentally cover them they start to do all sorts of crazy stuff until the stove, as a security feature, shut down totally. Also, when you have a big handle cover one panel it reacts,  suddenly you wonder what happen until you realize that you have turned off the heat.

My Samsung Omnia 7

This is by far one of the worst examples of touch buttons. It doesn’t provide any functionality other than looks (and I think you could have gotten the same look with real buttons, with the right materials). It is constantly in the way and trying to play a game is almost impossible as you have your whole thumb over the buttons. I nearly thrown this out the window…

Are there any good versions?

Well I think my old Bang&Olufsen sound system from 1991 is ok, touch button is not a killer feature but adds coolness to this piece of machinery, not that I know what I’m going to use my CD-player or cassette deck for anymore

B&O 4500 with the military grade remote - could easily take out any enemy

It’s also good in that it’s easy to keep clean, it does not produce any false taps or clicks (being placed on a wall and all). It’s only a design thing using touch here but it doesn’t make it worse, besides, it’s the massive one pound remote that is used to control this…

The stove, again, is actually also a good contender for touch buttons:

Easy to clean

There is one really good reasons for using touch here and it compensates for the problems - it’s so easy to keep clean.

So, a final plea!

I first thought of this when I moved in and started the fight with my stove. Then there was mockups leaks of the Windows Phone 7 HTC models. After that, I got my Samsung Omnia 7 in October. I think this is THE most annoying “feature” of the Omnia. But now there is a bigger threat - the mockups that Nokia made for the new Windows Phone 7 models. Look here:

This is really scary, touch buttons, and even worse than the Samsung Omnia, the home button is also touch here. This is going to drive at least me crazy. So please forget about touch here!

Let’s look at two scenarios that I think are the most common for background operation: Music player services like Spotify or Last.fm and GPS related applications like the RunKeeper GPS tracker. In these two main scenarios I think a richer and more service oriented API within the phone could take care of the problem instead of background execution.

Lets focus on the audio service first

No doubt that you need it to continue playing music while you work on other stuff. That’s not what I suggest but instead I want you to think of the application that is native in the phone, the Zune media player. Why would I want to create a new player over and over again? Wouldn’t it be better to integrate with the current? If the API was richer, in the Spotify case it would be possible to:

• Plug in the codec + DRM that’s used in Spotify
• Create and use playlists from either streamed material or locally stored material – or both
• Update the background image and access to all the data that is visible in the player
• Add the playlists as your own into the Zune player and for example mark them with a Spotify icon fro branding

The benefit with this would be many: Apart from not taking up precious development resources for cloning the Zune player over and over, you could let Microsoft take care of creating the most effective background enabled audio/video player.

To the user there is also the benefit of using the familiar way of navigating the audio as always instead of a new one for each application.

Now over to the GPS application

Why do you need to run this in the background? Well there are lots of reasons, but mostly it’s to be able to track and later plot your location from the track you are currently running. This functionality could also be handled with a service similar to the audio service. Why not trigger the GPS service to start tracking and storing the points. This would actually give even more advantages. This way two GPS enable applications could be using the same GPS track store and bring up the points. Again this would let the developer focusing on delivering an awesome application and not how to handle the GPS API effective enough not to drain the battery.

Moving on to task scheduling

There are of course situations where this approach won’t solve your issue but it’s good start to think in other directions when it comes background execution. Why not support some kind of task scheduling instead of true background operation. Here’s an example of what I mean:

In the GPS tracker situation there is an other issue that should be solved. The RunKeeper application vocally reports information on speed, average speed, distance, etc. This would normally be handled with an application running in the background. But it would also be possible to let simple tasks or code snippets be triggered with a set of rules based on the GPS tracker, like time, speed or distance.

I wouldn’t call it multitasking as the application isn’t really running in the background. It is just providing the code that should be brought back to life on certain points and then go to rest again, it can even be fully exited instead of suspended. To the user it would be of no difference if the application is running, suspended or exited as long as it behaves as if it was running in the background.

Conclusion

I think that in many situations we tend to take the obvious solution. While an alternative and for the user actually better way can be achieved if you think twice about it.

And there is an embryo to this in the Zune application, you can let your application launch the Zune player with a URL (either a net stream or locally stored) and it works great. But the API needs to be richer as I would want to insert Metadata and create lists for this as well as be able to provide a codec for handling media streams that Zune cannot play out of the box.

The market will continue to demand background enabling, and Microsoft will probably support that sooner rather than later but I really think we would all benefit from this thinking, both as developers and users.

The basic phone, with a see-through screen so it’s easy to create panoramas to lay behind. The keyboard variants (there are quite a few, default, text, email, web, search and a couple of dialer keyboards) and then a few of the buttons and checkboxes that’s needed. Most buttons are easiest mimicked by using the geometric shape in Balsamiq.

It’s quite heavy with all the details in the keyboards so pick and choose only the controls you need.

There you go, just download and start using it.

After three days of the Microsoft Mix10 event the brain tend to overflow. So I sit down at a Starbucks and try to summarize my thoughts before my mind explodes.

It’s easy to get caught up in positive buzz during events like this but I really think Microsoft is doing a lot of things right here with Windows Phone 7 series, the next level of .NET and Silverlight and Internet Explorer 9, among other things. Some of it, I believe, accounts to all the focus on User Experience and the influence that Bill Buxton have on this.

Also if you want to catch any of the sessions most of them are up at the mix10 site already.

Silverlight release pace

This was a big surprise to me; Silverlight 4 is going to be released as early as next month end the release candidate (RC) is out now. I was more in the lines of a beta and the an RC in the summer and a release late 2010. But it seems they try to align and do a big release with .NET 4, VS2010 and Silverlight 4. As a bonus the Pivot control will be in the controls toolkit so that’s going to be fun to play with.

Silverlight 4 Tools RC | .NET 4 RC | VS2010 RC

About the Windows Phone 7 series

The development platform for Windows Phone 7 series was, of course, one of the biggest news on the starting keynote and lot of sessions around it followed. I think they are on the right track with the platform. A few surprises surfaced, like the inclusion of DirectX to utilize HW backed video decoding and the Windows Phone development tools being released for free.

But a few questions and problems surfaced as well, as you can se all over the web it seems they are not including cut & paste and market place being the only application deployment channel. Other things I thought about was:

• How is the user interface is going to perform in right to left markets.
• What the possibilities are to hook in other services, like for example Pandora, to provide music streams for the native Zune player.
• And I still have a few issues with lag in the interface as well as accidental clicks, lets just hope the will get this issues out the door before they release it.

The user experience work that has been put into the new OS is really cool, the decision to remove all chrome and go for a real clean and consistent look is really fresh. And the decision to let the back button work on all levels across the phone, in-applications as well as between was a stroke of genius.

Windows Phone Dev tools | UI Design guidelines

What about HTML 5 and IE 9

It was pretty obvious that they should release some news around Internet Explorer 9 and its take on HTML 5. It is just an early technology preview but I have to say I’m impressed by the results. They did tone down the JavaScript speed issues but quite frankly they were on par with the other browsers and at those speeds it really is less of an issue. What still is an issue is standards, and anything but a 100/100 score on Acid3 is a failure in my eyes.

What they did show was the brilliant work they have done on the GPU acceleration part. This really was amazing 720p HD video streaming on a netbook was blazing fast, they even manage to pump two 720p streams without a glitch, impressive. And rendering HMTL5, CSS3 and SVG with hardware acceleration really looks promising.

If anything it shows that the Internet Explorer team is still in the game and might really get a decent browser out the door.

IE9 platform preview

Expression Blend 4

The things I saw done with blend was quite cool, this tool has come a long way from the first release and is now a potent tool. The tight integration with Adobe was finally in place, just point to the assets and start editing it in Illustrator or Photoshop. What’s more impressive, if I got it right, was that you were able to bind to a text object from the imported Illustrator assets directly to the object in your ViewModel! This really puts design control back into the hands of the designer.

Expression Blend 4 beta

Get real

So what’s left for me now is to find the time to play with all these new toys and and experience for myself what they are capable of before it’s time to Get Real and start creating.

Have fun // Håkan Reis

The Eclipse plug-in MouseFeed, written by Andriy Palamarchuk, will repeatedly nag you with what keyboard shortcuts you can use instead of using the mouse to perform actions. For example, if you constantly left-mouse-click the "step-over" button in the debug perspective, the MouseFeed plug-in will pop-up a notification window telling you to instead press "F6" on your keyboard.

You can also make the plug-in even more annoying by having MouseFeed canceling the mouse operation so that you have to use the keyboard shortcut.

I have installed it and forgotten about it until today, when it gently reminded me that collapsing all nodes in the Package Explorer view could be issued by "Shift-Command Numpad_Divide" on Mac OS X. Unfortunately my laptop does not come with a numeric keyboard so I have better to remap the shortcut if I find myself collapsing nodes often.

The MouseFeed home page can be found at: http://www.mousefeed.com
The SourceForge project page: http://sourceforge.net/projects/mousefeed

For our new StreamFlow project I wanted to try and get management functions in properly right from the start, which basically means exposing configuration, service management and administrator functions through JMX. I figured that if I did that on my part the customer would simply be able to get a decent JMX console and get their work done efficiently through that.

But then yesterday I did some research into the current state of JMX consoles, and in particular downloaded and tested all the OpenSource consoles in Java. The end result of that is a realization that they all basically suck. There's no point in naming names, and no point in going into detail, because they all seem to have the same basic problem: the developers haven't talked to a domain expert.

Don't get me wrong, these consoles have lots of features, and the features work. It's just that those features are not helping administrators get their work done, and the features that would help them get their work done are missing. If the developers of these consoles had talked to actual system administrators to figure out what they need to get their work done, I'm quite certain that the consoles would have far less features, but the features they had would actually be useful. Kind of like a Mac-experience I guess.

This seems to be one of the profound and obvious insights of Domain Driven Design: you can't get it right by guessing what your users want. You have to actually talk to them and ask them what they want, why they want it, and what problems it will solve. Most software today, especially in the packaged product sphere, seems to be done by developers who are sort of guessing what to include based on their own ideas and possibly what the sales guys and marketing folks think would make the product more sellable. But that doesn't mean that the end result will be useful or even usable, and it's a big fundamental problem with our industry.

As software developers we need to understand that having strong development skills is not enough. We also have to take the time to understand what it is our customers are doing, how they are doing it, and why. We have to be cross-disciplinary, to a large extent, or else our products will inevitably be doing things nobody really asked for. We will be creating waste, and lots of it.

So to the makers of JMX consoles in particular, here are some suggestions. Look into DDD. Look into BDD, Behaviour Driven Design, also, as this will give you the simple tool of "As an X I want to Y so that Z", which will profoundly help you sort out the useful features from the useless features. "As an Administrator I want to Know when a server goes down so that Users won't have to tell me". Things like that. Then get a domain expert or two. Talk to them. Learn what they do, how they do it, and what they need to get things done. Learn their ubiquitous language. Then implement features that would actually help them. I guarantee you that if you start from scratch and follow this model you'll be pretty far along after just 10 features, and none of them will be similar to what you already have in the consoles today. But they will be useful! And that is a good start.

ps. while the lack of decent OpenSource JMX consoles is depressing, during my tests I did find one product that seems really good, and have features that are related to things that administrators care about: the ManageEngine Applications Manager. Check it out!

One area that, in my opinion, could still be improved is the development environment. It may be a heck of a good build system Liferay has come up with, but at the bottom line it takes time to learn it and to just start studying it you easily become a bit uncertain. It consists of homegrown ant scripts. To have a flatter learning curve for newcomers Maven 2 might be suitable.

Anyway, I sat down one evening some time ago and looked into how Maven 2 could be used for creating Jsp Portlets for Liferay. Some hours later the work had resulted in a new archetype for creating Liferay Jsp Portlets.

The structure and content of the standard Liferay Jsp Portlet can be viewed here.

So, what did I do?

1. I followed these instructions to manipulate the Jsp Portlet part of Liferay's plugin SDK into a maven archetype:

http://maven.apache.org/guides/mini/guide-creating-archetypes.html

This involved editing these property and xml files:

liferay-plugin-package.properties
name=${artifactId}
module-group-id=liferay
module-incremental-version=1
tags=
short-description=
change-log=
page-url=http://www.liferay.com
author=Liferay, Inc.
licenses=MIT

portlet.xml
<?xml version="1.0"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd">
<portlet>
<portlet-name>jspPortlet</portlet-name>
		<display-name>${artifactId}</display-name>
<portlet-class>${groupId}.JSPPortlet</portlet-class>
		<init-param>
			<name>view-jsp</name>
			<value>/view.jsp</value>
		</init-param>
		<expiration-cache>0</expiration-cache>
		<supports>
			<mime-type>text/html</mime-type>
		</supports>
<portlet-info>
			<title>${artifactId}</title>
			<short-title>${artifactId}</short-title>
			<keywords>${artifactId}</keywords>
		</portlet-info>
		<security-role-ref>
			<role-name>administrator</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>guest</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>power-user</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>user</role-name>
		</security-role-ref>
	</portlet>
</portlet-app>
 

to insert ${artifactId} and ${groupId} for the portlet name and package structure. These files are part of the file list finally being wrapped up within the archetype and used to generate the resulting portlet from Maven 2.

2. I ran 'mvn install' on that particular archetype to have it installed in my local repository.

3. I used the archetype to create a new Liferay Jsp Portlet artifact:

mvn archetype:create -DarchetypeGroupId=com.liferay.maven.archetypes.portlet.jsp
  -DarchetypeArtifactId=liferay-jsp-portlet
  -DarchetypeVersion=1.0-SNAPSHOT
  -DgroupId=[my.package]
  -DartifactId=[MyFirstLiferayJspPortlet]

4. I stepped into the artifact and ran 'mvn install' on it which generated my MyFirstLiferayJspPortlet-1.0-SNAPSHOT.war.

5. I then uploaded the war file to my portal instance via the Liferay admin GUI Plugin Installer.

6. Et voila. It worked, showing up in the portal.

And of course, worth mentioning, to have a development environment up and running in eclipse in seconds this is all you have to do:

1. mvn eclipse:add-maven-repo -Declipse.workspace=[full-path-to-workspace]

2. mvn eclipse:eclipse

To have the archetype play with the existing build situation of Liferay it would probably need to be generated from some ant target and be based on the portlet template in subversion located at "plugins/tools/portlet_tmpl/" to have it follow updates of Liferay.

Here you can download the final result, as a zipped archetype.

If a generated archetype like this was to be uploaded to a public maven repository, working from above point #3 and down is what would be necessary for a developer to have a project and all the necessary property and xml files (correctly edited with package structures and all) in place for a Liferay Jsp Portlet development environment. It could at least become a complement to the Plugins SDK. And yes, it could for sure still be enhanced. For example, there is no JSPPortletTest class generated for the JSPPortlet class.

The sessions are confidential so I will keep this post vague on the technical parts, not revealing any thing that might or might not come to an iPhone or iPod touch near you in the future. And I can not mention any specific sales numbers, but I do can say that any predicted numbers you might have seen; is probably an underestimation with a margin and then some.

The sessions where on a high level, not going too deep on technical details. Instead the sessions concentrated on the overall design philosophies, and common gotchas. For the nitty gritty details Apple engineers where available, and I missed half a session discussing the ins and outs of the UIToolbar class with Alberto Arauz. Alberto is one of the european software evangelist, and was most impressed, and interested, when I described the successful Mobile 2.0 track at Øredev 2008. Apple's overall impression with Scandinavia has so far been a mostly cold hand regarding anything with Apple, going as far as only six people registering for a Tech Talk in Oslo two years ago.

Apart from the speakers and engineers, Apple also brought a video-team. So yours truly has been intervjued about the applications I have on App Store, and my experience with the iPhone SDK. The video will be cut and edited for promotional purposes, and hopefully me mentioning both Malmö and Jayway will not be cut out. The odds of my short talk being included is quite good, as most developers seems to be focusing on games, not utilities as I and Jayway has done.

The best part to take home is not technical, just solid advice for any development, not even under NDA, and the sole point repeated by Apple over and over: Developing great applications is not about adding features! The trick is not to cram in as many features as you can, the trick is to know what features to leave out, so that time can be well spend on the key features that do make the cut. And this is tenfold as important on a mobile device where real estate is limited. A quote from Mark Twain:

I apologize for writing you a long letter, but I did not have the time to write a short.

Writing short, and cutting features is hard. How to decide on the features to drop or implement? Apple uses a simple technique, called a product statement. The product statement for the Photos application is for example; "An easy to use photo sharing application for all iPhone users". Any feature that do not help fulfilling this statement do not make it. How about simple photo-editing? Nope, does not comply with statement. The wording of the product statement is important, by simply changing it to "An easy to use photo sharing application for professional photographers", would be a completely new application. Only when the product statement is agreed upon, can an approved list of features be made. An omnipresent Steve Jobs approving and dismissing features, is an exaggeration, this simple method is what do the trick.

Now this might sound both obvious, and counterintuitive. Surely adding that last nice feature would add value? Not at the expense of a cluttered user interface, that is meant to be used while standing in line for 30 seconds. Features thought to be must haves, most of the time are not. Some features thought to be must haves are MMS and video recording. Looking at the raging success of the iPhone, it is very obvious that they are not must haves. We as software engineers must at long last learn that it truly is quality over quantity.

And lastly a personal reflection; from a developer's point of view the best part about iPhone SDK is that it is not an UI framework, it is an Application framework. It do not settle with providing the tools for collections, persisting data, displaying a UI, and then leave the rest of the architecture to the developers. The iPhone SDK supports all three parts of the Model-View-Controller paradigm equally well, and that is what makes it so productive.

Usability is the science of usage which means that usability rules and laws apply to rich clients, web applications, paper forms, furniture, milk cartons, tools etc. It needs to be taken into consideration whenever there is a human end-user. If not, the product will be designed to be specifically useful to the designer.

Know your user

The first question to ask yourself is: Who is going to use your API? If you know that
then you are half way to the bank. Why? Simply because you know what your users
know and want, and thus you can give them what they need.
If the user has a list of objects and wants to remove objects which already exists in
another list, your API could look something like this:

CustomList myList = getMyList();
CustomList yourList = getYourList();
myList.removeSharedItems(yourList);

“myList.removedSharedItems(yourList);” describes what the function does to your
list, and is suited for most any programmer. If, on the other hand, you know that
your users are working with set theory, you would probably want to do something
like this:

CustomList myList = getMyList();
CustomList yourList = getYourList();
myList.toRelativeComplement(yourList);

Let the API be self-documenting

Remember that when it comes to learning or getting started with an API, many pro-
grammers simply rely on the AutoCompletion-function in their IDE. If they don’t
get it from looking at that, they might turn to the documentation, or simply turn to
another competing API. So don’t take naming your classes and methods lightly.
In the previous example both

myList.removeSharedItems(yourList);

..and:

myList.toRelativeComplement(yourList);

..mutate myList. This is visualised by using “remove” and “to” which both refer
to the myList-object. If for example “myList.toRelativeComplement (yourList);”
didn’t have the word “to”, the user wouldn’t know if it returns the relative comple-
ment or if it mutates myList to it.
In SpringFramework, self-explanatory class names such as “BatchPreparedState-
mentSetter” (an interface for a prepared statement setters used during batch up-
dates) are widely used. The only risk with this is that class-, interface- and method
names can get rather long, resulting in poorer readability. Explain what it does but
be as precise as possible and don’t take it to the extreme.

Don’t present the underlying implementation

The API should limit itself to what the user needs to know; no more, no less. The
names of classes, interfaces and methods should describe what they do and what
they are used for; not how they do it. Why force the user to know what the underly-
ing implementation does if they don’t need to know? Open-source your code and
give the user the choice to see how it is done instead of forcing it on them.
Java.io.Properties.loadFromXML takes an InputStream. This means that to load
properties from XML the following needs to be done.

File myProps = new File(“.\\MyProps.xml”);
FileInputStream is = new FileInputStream(myProps);
Properties p = new Properties();
//void loadFromXML(InputStream in)
p.loadFromXML(is);

The fact that loadFromXML takes an InputStream describes what the method does.
A better solution would be to look at SpringFramework’s Resource solution. There
they have a common interface called “Resource” which is implemented by every-
thing from FileSystemResource to InputStreamResource. If java.io.File were to im-
plement such an interface, a solution could simply be:

Properties p = new Properties();
//void loadFromXML(Resource xmlResource)
p.loadFromXML(new File(“.\\MyProps.xml”));

In this case the user of the API doesn’t have to think about in what way the XML
will be read; just that it will be read.

Think of logical mapping

The methods of a class (name and responsibility) must map well to the classes
name; input and output of a method must map the responsibility of the method and
so on. If this is done, the user will be able to use the API intuitively, and learn and
understand how to use it without any documentation.

//Bad mapping in Calendar
void setTime(Date date)
//Better mapping
void setTime(Time time)

Limit the number of options

If you have something in your API that can be done in two different ways, choose
one. Don’t give the user an ambiguous API with features that are so similar that it is
confusing, and force them to go to the documentation or choose by chance.

myCalendar.add(Calendar.DAY_OF_WEEK,7);
//...differs from...
myCalendar.roll(Calendar.DAY_OF_WEEK,7);
//...in what way?

Avoid methods and classes that do
different things in different object states

Separate your domain entities in such a way that they overlap as little as possible.
This is basic OO and should be common sense, but it is a common problem. Java.
io.File has exactly this problem. An object of java.io.File can be a File or a Directory.
If the object is created from the path of a directory it is a directory. This gives the
possibility to write, among other things, the following illogical code:

File myFile = new File(“.\\MyFile.xml”);
boolean dirMade = myFile.mkDir();

A better solution would be if File were structured something like:

interface FileSystemElement extends Resource{
   //...
}
class abstract AbstractFileSystemElement implements FileSystemElement{
   //...
} 

class File extends AbstractFileSystemElement{
   //...
} 

class Directory extends AbstractFileSystemElement{
   //...
} 

Summary

The most important thing to remember is that there is a human user at the other
end of an API. If you remember this you will create better APIs. The pointers in this
article simply scratch the surface of what could be done to improve your APIs. One
thing that would result in great improvements is if you found a couple of users and
user-tested the solution. (http://en.wikipedia.org/wiki/Usability_testing).

Originally published in JayView.

How bad are Date and Calendar?

Consider java.util.Date. It has been around since JDK 1.0, and it's actually not a date, but a date and a time. In order to get the date (and the time), you call the getTime() method. It uses two-digit years from 1900, day-of-month is one-based, while month and hours are zero-based, it should have been immutable, and most methods have been deprecated in JDK 1.1. Since it's not final, it's possible to hack it by overriding critical methods, like for example after.

The state of java.util.Calendar is not much better. Month is zero-based, it should have been immutable, and it allows only one hour offset for daylight savings time. Some years have more, you know. British timezone in 1943, 1944 and 1945, for example, had two hours. The worst part is that it uses two different representations internally: a value for each field, and milliseconds since 1970. The scary part is that these two representations are not continuously kept in synch. Instead they are resynched as a side effect of other method calls, like equals for example. Wouldn't that be something? You call equals on your Calendar and suddenly it changes to a different date.

Then we have java.util.SimpleDateFormat. It requires a Date object, it's not very fast, and it's not thread-safe. If concurrent threads call its format method on a shared instance, it can produce bizarre results.

They can't be that bad, can they?

Let's print out a date. We want July 2, 1945 and the time should be 12.30 PM. Here we go:

 
Date date = new Date(1945, 7, 2, 12, 30, 0);
System.out.println(date.toString());
 
// Sat Aug 02 12:30:00 CEST 3845
 

Oops. Forgot the two-digit year and the zero-based month. Let's try again:

 
int year = 1945 - 1900;
int month = 7 - 1;
Date date = new Date(year, month, 2, 12, 30, 0);
System.out.println(date.toString());
 
// Mon Jul 02 12:30:00 CEST 1945
 

Yes, I know that the constructor used above is deprecated. This is how it really should be done:

 
TimeZone tz = TimeZone.getTimeZone("Asia/Tokyo");
Calendar cal = Calendar.getInstance(tz);
cal.set(1945, Calendar.JULY, 2, 12, 30, 0);
DateFormat f= new SimpleDateFormat("yyyy-MM-dd hh:mm");
System.out.println(f.format(cal));
 
// java.lang.IllegalArgumentException: Cannot format given Object as a Date
// at java.text.DateFormat.format(DateFormat.java:279)
// at java.text.Format.format(Format.java:133)
 

Oops. DateFormat cannot take a Calendar. Let's try with a Date:

 
TimeZone tz = TimeZone.getTimeZone("Asia/Tokyo");
Calendar cal = Calendar.getInstance(tz);
cal.set(1945, Calendar.JULY, 2, 12, 30, 0);
DateFormat f= new SimpleDateFormat("yyyy-MM-dd hh:mm");
Date date = cal.getTime();
System.out.println(f.format(date));
 
// 1945-07-02 06:30
 

Well, almost right. I asked for the time to be 12.30, not 6.30. Ah, of course. It's not enough to set the timezone on the Calendar that we used to get the Date that we want to print. The DateFormat that prints the Date also needs the timezone. Silly me.

 
TimeZone tz = TimeZone.getTimeZone("Asia/Tokyo");
Calendar cal = Calendar.getInstance(tz);
cal.set(1945, Calendar.JULY, 2, 12, 30, 0);
DateFormat f= new SimpleDateFormat("yyyy-MM-dd hh:mm");
f.setTimeZone(cal.getTimeZone());
Date date = cal.getTime();
System.out.println(f.format(date));
 
// 1945-07-02 12:30
 

Finally.

The Contender: Joda-Time

There is a candidate that has all the characteristics we mentioned earlier, and more: Joda-Time. It's a single jar of 518k with no other dependencies. It replaces Date, Calendar and TimeZone. It has interfaces for datetimes, intervals and durations. The key classes are immutable. It has a pluggable calendar system where the default is ISO8601. And one more thing: it's easy to use.

DateTime

The most useful class in Joda-Time is the DateTime, which is immutable and thread-safe. It is measured in milliseconds since 1970, and it has simple getters for all fields. It supports timezones and multiple calendar systems. Its main purpose is to fill the most common needs as simple as possible:

 
DateTime now = new DateTime();
 
int y = now.getYear();
int hour = now.getHourOfDay();
int sec = now.getSecondOfMinute();
 
boolean leap = now.year().isLeap();
int daysInMonth = now.dayOfMonth().getMaximumValue();
 

Since it's immutable, all mutating methods return new objects:

 
DateTime now = new DateTime();
DateTime yesterday = now.minusDays(1).plusHours(3);
 

Partial

Partially defined datetimes have no timezone; they use local time. They are called "partial" because they don't have all the fields of a DateTime. We have YearMonthDay, TimeOfDay (hour, minute, second, and millisecond), and Partial (can store any fields). They can easily be converted to DateTime:

 
YearMonthDay ymd = new YearMonthDay(2005, 9, 20); // September 20, 2005
TimeOfDay tod = new TimeOfDay(14, 15);
 
DateTimeZone zone = DateTimeZone.forID("Asia/Tokyo");
DateTime dt = ymd.toDateTimeAtCurrentTime(zone);
DateTime dt2 = ymd.toDateTime(tod);
 

Period

A Period represents a period of time, like "5 years, 3 months, 2 days and 12 hours":

 
Period period = new Period(5, 3, 0, 2, 12, 0, 0, 0);
int years = period.getYears();
int days = period.getDays();
 

Interval

The class Interval represents an interval of time, represented by a start DateTime (included) and an end DateTime (excluded). Let's say we want to know how many complete weeks an interval is. To do that, we convert the Interval to a Period of the specific type we want. Using PeriodType, we can deduce that the interval below is 9 complete weeks (P9W is ISO8601-standard for a 9 week period):

 
DateMidnight start = new DateMidnight(2005, 7, 12); // July 12, 2005
DateMidnight end = new DateMidnight(2005, 9, 15); // September 15, 2005
Interval interval = new Interval(start, end);
Period period = interval.toPeriod(PeriodType.weeks());
System.out.println(period);
 
// P9W
 

Chronology

Joda-Time features a pluggable calendar system based on the Chronology class. There are for example ISO9601, Gregorian, Julian, GJ, Buddhist, Ethiopic, and Coptic. The default is ISOChronology. A Chronology can be passed in as extra parameter whenever needed, as in the following example where we print the year 2006 as the Buddhists see it:

 
Chronology buddhist = BuddhistChronology.getInstance();
DateTime now = new DateTime(buddhist);
int year = now.getYear(); // 2006
System.out.println(year);
 
// 2549
 

Time Zone

The DateTimeZone class encapsulates a time zone that contains not only the timezones in the current JDK implementations, but is also up to date with the most current time zone data available at the time zone database.

 
DateTimeZone.UTC;
DateTimeZone.forID("Asia/Tokyo");
DateTimeZone.forOffsetHours(6);
DateTimeZone.forTimeZone(TimeZone.getTimeZone("Europe/Stockholm"));
 

One problem with the JDK TimeZone is that it returns timezone UTC (also known as GMT) if the full name cannot be understood:

 
TimeZone validTz = TimeZone.getTimeZone("Asia/Tokyo");
System.out.println(validTz);
TimeZone invalidTz = TimeZone.getTimeZone("Asia/SomeUnknownCity");
System.out.println(invalidTz);
 
// sun.util.calendar.ZoneInfo[id="Asia/Tokyo",offset=32400000,dstSavings=0,useDaylight=false,...
// sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,...
 

By contrast, Joda-Time's DateTimeZone throws an IllegalArgumentException if it cannot understand the time zone name:

 
DateTimeZone validTz = DateTimeZone.forID("Asia/Tokyo");
System.out.println(validTz);
DateTimeZone invalidTz = DateTimeZone.forID("Asia/SomeUnknownCity");
System.out.println(invalidTz);
 
// Asia/Tokyo
// java.lang.IllegalArgumentException: The datetime zone id is not recognised: Asia/SomeUnknownCity
// at org.joda.time.DateTimeZone.forID(DateTimeZone.java:198)
 

Interoperability

One of our requirements for a new framework was that it should be easy to convert to and from the standard classes. Constructors in Joda-Time take Date, Calendar, String, and long. From DateTime we can easily get JDK Date and Calendar. The DateTimeZone class can be constructed from a TimeZone and also return a TimeZone. In the example below, we easily convert from a standard Date to Joda-Time's DateTime to a GregorianCalendar, and from the DateTime back to a Date:

 
Date date = new Date(106, 8, 19); // Sep 19, 2006
DateTime dt = new DateTime(date);
GregorianCalendar c = dt.toGregorianCalendar();
Date d = dt.toDate();
 

Formatting

What about formatting then? Compared to SimpleDateFormat, the DateTimeFormatter is fast, flexible, thread-safe, and immutable. Formatting can be done in several ways: using a pattern, a style, or a format builder. You can either pass a formatter to the toString method for DateTime, or you can ask the formatter to print the DateTime:

 
DateTimeFormatter f = DateTimeFormat.longDateTime();
DateTime dateTime = new DateTime();
System.out.println(dateTime.toString(f));
System.out.println(f.print(dateTime));
 
// May 25, 2006 9:45:09 PM CEST
// May 25, 2006 9:45:09 PM CEST
 

DateTimeUtils

If you need to stop time, or go back or forward in time, you can use the DateTimeUtils class. This code shows that it's possible to stop time:

 
DateTime now = new DateTime();
DateTimeUtils.setCurrentMillisFixed(now.getMillis()); // time has stopped!
System.out.println(new DateTime());
Thread.sleep(2000);
System.out.println(new DateTime());
 
// 2006-05-25T23:21:37.562+02:00
// 2006-05-25T23:21:37.562+02:00
 

Turning back the clock is also possible:

 
DateTime now = new DateTime();
Period period = Period.months(-1);
Duration dur = period.toDurationFrom(now);
DateTimeUtils.setCurrentMillisOffset(dur.getMillis()); // we've gone back in time!
System.out.println(new DateTime());
 
// 2006-04-25T23:24:03.796+02:00
 

Don't forget to reset to system time:

 
DateTimeUtils.setCurrentMillisSystem(); // we're back to normal
System.out.println(new DateTime());
 
// 2006-05-25T23:29:41.281+02:00
 

Where were we?

Oh, yes. Printing dates. Let's print out the same date using Joda-Time. It was 12.30 PM on July 2, 1945:

 
DateTime date = new DateTime(1945, 7, 2, 12, 30, 0, 0);
DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm");
System.out.println(date.toString(formatter));
 
// 1945-07-02 12:30
 

Couldn't be simpler.

Conclusion

The existing classes for date and time have drawbacks, some of them serious. The contender is Joda-Time, which is a complete rewrite and represents a mature API with a strong focus on usability, interoperability, stability and performance. What are you waiting for? Now is the time.

Update: It seems Java7 will be using JSR310, which basically is Joda-Time.