OutputStream out = new MyOutputStream(...); //may throw IOException
try {
    //use the stream
} finally {
    out.close();
}

than this:

OutputStream out = null;
try {
    out = new MyOutputStream(...); //may throw IOException
    //use the stream
} finally {
    if (out != null) {
        out.close();
    }
}

I just find the first example correct and the second incorrect. I see the second ‘pattern’ everywhere.

Opinions?

When I first had to use OS X I had hard time with some things that weren’t working as expected. I thought they were usability bugs, but of course don’t try to argue about that with a veteran Apple user, because “you’re ugly and stupid, and that’s the way it should be! And OSX has the best UI/UE evah!”. I used to hate those weird feature, and finally it’s a pleasure to see some of those things going away (so I was right!).

I list here what has been improved and what still sucks. Of course, by my point of view.

The enhancements that I (really) like

• The full screen button on the top left, is a great thing. Also the fact that the apps get maximized in another screen, is a great idea. In fact, when one app is maximized, switching to other apps is a pain; having it maximized in another screen and the gesture to switch between screen is very practical. Apple guys, congrats for the innovative idea.
• Also I like the dashboard on the left of the desktop.
• Launchpad is nice. I like it. I don’t like that I cannot activate it with a shortcut, and I cannot use arrow keys to select which application to launch.

Finally also on OS X…

• Windows resizing is decent: finally also OSX can resize windows not only from the bottom-right corner, but from all the frame around the window. So that grip only on that corner was lame, wasn’t it?!
• The Terminal.app is improved, almost ok. I like the full screen mode, so I decided to give it a second chance, abandoning iTerm, at least for now. I had to create my own Settings, remapping some keys and colors, I attach it here: Luigi.terminal for myself as backup and for whoever would find it useful. The home/end key still don’t work in man pages and less, but I learned that pressing capital G and g, do the trick everywhere, included in vim. Still wondering what’s hard about making that work.
• The selection in list (example: file selection in Finder) with shift-up and shift-down, finally works as it should.
• The crazy click-and-reclick-to-focus model has been finally replaced a more natural one. OSX is the very last OS to realize how focus has to be implemented.
• With the App Store, finally apple has a kind of ‘package management’ tool. Very nice looking, as well. I am wondering when they will realize that it should also provide the Uninstall feature. Since application installed from a .pkg file are impossible to uninstall.
• In Finder.app to jump to a file from another, you just type the letter corresponding to the name of the files, like in Windows Explorer o Linux Thunar/Nautilus. But, when you switch to column view, this functionality was not working anymore… with Lion it finally works. Keys are still faster than any mouse/touchpad; teechies know it.
• Cut and paste in Finder was not working with Leopard. I managed to fix it with some research on google. I didn’t do anything to fix it on Lion, maybe they fixed it (if the fix I made before is not responsible for it still now).
• They removed Front Row application. Great! That stuff was garbage. And it was popping out unwanted all the time, activated by some key combination (cmd-esc I think).
• I was shocked to see that on Leopard you could do a ‘touch /foobar’ without root privileges. What kind of Unix was that? They fixed this in latter version of Leopard and in Lion too.
• I like the full screen in Safari. If I am not wrong, Safari was the only browser without a full screen before, now it has a nice one. Still Chrome does a better full screen, since it hides also the navigation bar and shows only the actual internet page, with no distractions.

I’m undecided on…

• The scroll gesture has been inverted. I am getting used to it, but I still think that previous direction was more intuitive.
• Font smoothing: I was strongly against it at beginning. Now I’m kind of neutral. I still hate it in the Terminal, btw, and I always disable that there.
• All the animations. I like most of them, I don’t like the elastic bouncing that has been copied from the iPod/iPhones. Although they can be disabled, I can live with it, so I’ll try them for some more time and decide later to keep or remove them.

This still sucks!

• Enter to rename, instead of activating/opening.
• You installed Lion, but what if you wanted to burn the DVD? You can, but it’s not so easy. This is quite unfair from Apple. On the tips below for a short guide.
• The maximize round button on the top left corner of the windows, doesn’t maximize. That’s just stupid. Hope one day they will give the possibility to configure that behavior.
• I never liked the menu bar shared between application. There’s nobody that will ever convince me that is a good idea. I know Ubuntu is copying stupid things like this, still doesn’t mean that is a good thing.
• The windows close/minimize/maximize round buttons on the top left, and having no possibility to change that. I liked them on the right, but that’s ok, I am getting used to it.
• The Finder still hides most of the files. I still haven’t understood what’s the criteria of the file hidden, and if there is a way to show all the files.
• Java has always been late on OSX, and trickier to install with the documentation and sources… Lion doesn’t come with JRE, but you have to install it later. It’s not difficult, so it’s ok. What I don’t like is the directory layout they made up. I have to verify if the documentation and the sources can be installed and accessed easily. It was tricky for Leopard, hope they improved it. (but I don’t think so)

New OS, new problems…

• The gestures for showing the desktop was perfect before, now I get that wrong frequently, since it’s a gesture that the OS confuses with others. That’s a pity because I use the desktop a lot to store files I am working on, and having an easy way to access the desktop is quite important.
• When you close an application with cmd-q, when you reopen it, it will show all the last opened documents. Even if you open a document on your desktop, it will also open it, plus the last opened documents… that’s not a good idea. Fortunately it can be disabled in the Preferences.
• One friend of mine reported that the fullscreen doesn’t work great when you use multiple monitors. I didn’t tried it yet.
• The scrollbars disappearing. That’s bad specially in the browser (iframes, and scrollable divs). In the applications it is sort of cool, btw.
• Launchpad: you click on the icon and it will show the applications; you click again and you return to the desktop. Fine. Now try with Mission Control icon: click once and it shows active applications; click again and it makes a mess. Not so good. I removed Launchpad and Mission Control from the dock and learned to activate them with the gestures, so this doesn’t bother me anymore.
• When my laptop goes out of battery, it shut down completely instead of freezing. Potentially corrupting data. I don’t know if this is a new “feature” of Lion. It really sucks, anyway.

Some handy tips

With time, I got accustomed to some craziness of OS X, and I found the way to live with them. Or work-around them.

Screen Lock shortcut

I was complaining of the missing key combination to lock the screen on a mac. Actually I think that there is no real ‘lock’ shortcut. But pressing ctrl+shift+eject send the screen to standby, and if your setting are appropriate when the screen is resumed the login screen can be displayed.

Shortcuts

OS X is full of mysteriously assigned shortcuts, like the lock screen above. And the boot ones…
I found this link which is good to keep handy: Mac OS X keyboard shortcuts.

How to redownload OSX Lion and Burn it on a DVD

Once you have installed Lion, the installer app deletes itself. Like in “Mission: Impossible” movies. And from the App Store you cannot download it again.
Here is how to do:

Launch the App Store
While holding down the OPTION key, click on the “Purchases” section
You should see “OS X Lion” and “Install” should now be gray and you can click that to re-download Lion (you may have to re-authenticate within the App Store with your Apple ID).

To burn Lion on a DVD, here is how to do it:

Getting Lion from the App Store is convenient, but if you want a physical copy of the installation, you can easily make your own Lion install DVD or USB drive with Disk Utility.
If you want to do a clean installation of Lion (or you want to install it on a Hackintosh), you’ll need to install it on some sort of physical media. Apple will be releasing a flash drive installer for a whopping $70 in August, but you don’t need to wait (or pay twice the OS’s price) to get it. It’s very easy to burn Apple’s installer to a single layer DVD or flash drive of 5GB or larger.

Important: Note that the Lion installer deletes itself if you upgrade, so if you want to do this, you have to do it before you update your computer to Lion. You can always re-download Lion after the fact, but geez, who wants to do that? Once you’ve got it on your system, here’s what you do:

1. Download Lion from the Mac App Store. The installer should show up in your Applications folder.
2. Right-click on the installer and hit “Show Package Contents”. Navigate to Contents > SharedSupport and look for a file called “InstallESD.dmg”.
3. Open up Disk Utility and drag the DMG file into the left-hand sidebar. If you’re burning it to a DVD, insert your DVD, select the disk image in the sidebar, and hit the “Burn” button. Skip down to the last step to use it.
4. If you want to burn Lion to a USB flash drive, plug it in and click on it in the left-hand sidebar in Disk Utility. Go to the Partition tab and select “1 Partition” from the dropdown menu. Choose “Mac OS Extended (Journaled) on the left.
5. Hit the Options button under the partition table and choose “GUID Partition Table”. You’ll need this to make the drive bootable on a Mac. Hit the Apply button when you’re done to format your drive (note: it will erase everything on the drive).
6. Click on the “Restore” tab, choose the InstallESD.dmg file as the source and your flash drive as the destination. Hit the Apply button and it will create your bootable USB drive.
7. Reboot into OS X and hold the option key when you hear the startup chime. You can boot into your DVD or flash drive from there.

You’ll not only be able to install Lion from this drive, but you’ll also be able to use Disk Utiltiy, recover from a Time Machine backup, and do everything else you could do with the old installation DVDs. Note that when you install Lion, it’ll create a recovery partition with all these features anyway, so you don’t need the DVD unless you’re doing a clean install. Though it’s always nice to have around in case something happens, like you erase your entire drive. Not that that’s ever happened to me 3 times in one week or anything.

Conclusions

Overall, I like the changes introduced by Lion. Still many things can be improved.
That’s pretty much all I have to say about Lion.

If there is any new feature you don’t like and you would like to remove, have a look at this article How to De-iOs-ify Mac OS X Lion; you may be lucky and find the way to restore some Leopard behavior.

So I found this two links, that explain the basics on how to implement bash completion for simple commands:

• An introduction to bash completion: part 1
• An introduction to bash completion: part 2

And I implemented my completion for ssh, which takes the hostnames from the file ~/.ssh/known_hosts

# Add bash completion for ssh: it tries to complete the host to which you
# want to connect from the list of the ones contained in ~/.ssh/known_hosts

__ssh_known_hosts() {
    if [[ -f ~/.ssh/known_hosts ]]; then
        cut -d " " -f1 ~/.ssh/known_hosts | cut -d "," -f1
    fi
}

_ssh() {
    local cur known_hosts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    known_hosts="$(__ssh_known_hosts)"

    if [[ ! ${cur} == -* ]] ; then
    	COMPREPLY=( $(compgen -W "${known_hosts}" -- ${cur}) )
        return 0
    fi
}

complete -o bashdefault -o default -o nospace -F _ssh ssh 2>/dev/null \
	|| complete -o default -o nospace -F _ssh ssh

To load it, save the above script into a file called ‘ssh-completion’ then add “source ssh-completion” in your ~/.profile or ~/.bashrc. Some Linux distributions offer a directory where you can deploy your completion scripts, for example debian should have them like /etc/bash-completion.d/foobar.bash.

Then go on the command line and type:

$ ssh [tab]

If everything went fine, you should see a list of servers to which you recently connected.

I don’t go in detail to explain the above script, since there are good tutorials around for this purpose, including the links I included before.
I only want to say that the ‘compgen’ is an internal bash command, used in the above script: what it does is taking a list of words (-W ${known_hosts} option) from which to try to complete a given partial word (in the above example the ${cur} variable, which is the word at the cursor).

Since completion is usually implemented with bash scripts, it’s good to keep handy a bash reference manual.

Scared of bash scripts?

I am. I continuously forget the syntax of loops and conditional expressions: I think that the bash language is quite obscure and counter-intuitive. So I guess that is also possible to implement completion as part of your program using your language of choice (Java in my case). You can implement a feature in your program that reads and analyzes the COMP_WORDS and COMP_CWORD environment variables, and generate the list of completion words, as the ‘compgen’ bash built-in command does. And, if your language allows it, set those words into the COMPREPLY environment variable; in Java I think it’s not possible to alter environment variables, but you can just output the words on the standard output and use a brief script to set that output to the COMPREPLY variable.
I’d suggest to bind this functionality to a ‘–completion’ option that can be specified in the command line, as we usually do for the –help option.

See git-completion.bash if you want an example of a complex completion script… bash can be hard.

Update

I just typed ‘complete’ on my mac, and I discovered I have 408 commands binded to some completion script. Including a more advanced ssh script which implements the hostname suggestions.

If so, you can still have a look at those configuration files in the running environment using the unzip Unix utility.

$ unzip -p /opt/myapp/lib/my-app.jar log4j.properties
log4j.rootLogger=INFO,stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Threshold=INFO
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{dd-MMM hh:mm} [%-5p] %m%n

The -p option uncompress and prints the file content to standard output.

I like to include resource files in the deployable artifact, unless I want those files to be modifiable without repackaging. Hiding most of configuration helps to keep things simpler for the end user, but still those files can be accessed for the technical support.

By the way, the above log4j configuration is the one I used to replace some System.out/System.err in a simple command line based application. I was thinking to remove the date part ‘%d{dd-MMM hh:mm}’ and make it look like the output of ant/maven, but then I thought that -after all- the date is quite useful since the application in question is ran by cron redirecting the standard out into a file, so we keep that as a log of the last run, to have some clue in case of errors.

JAXBContext context = JAXBContext.newInstance(ObjectToConvert.class);
Unmarshaller u = context.createUnmarshaller();
return (ObjectToConvert) u.unmarshal(xmlInputStream);

// becomes
return (ClassToConvert)JAXB.unmarshal(xmlInputStream, ObjectToConvert.class);

// and
JAXBContext context = JAXBContext.newInstance(objectInstanceToConvert.getClass());
Marshaller m = jc.createMarshaller();
m.marshal(objectInstanceToConvert, xmlOutputStream);

// becomes
JAXB.marshall(objectInstanceToConvert, xmlOutputStream)

Nice: one line of code to convert Java objects from/to XML. I didn’t notice this utility method in the JAXB library at first, so I was implementing those two methods in my code, more or less the same way. It’s always good to remove code.

Eclipse Save Actions

From now on, nomore unused imports and better immutable classes.

Nice to know.

The bug has been reported to Oracle, but I supposed they will include this in their collection of bugs and sell it as “Oracle Database 12g” product. :-)

There is a naming convention defined by BDD which says that the test class and the test methods should describe the behavior you want to verify.

Examples:

having the test methods starting with should

public class WhenWindowControlCloseWindow {

    @Test
    public void shouldCloseWindows() {
         //...
    }
}

Or as in this example (from wikipedia), which also uses comments to describe the test: given/when/then:

public class WindowControlBehavior {
    @Test
    public void shouldCloseWindows() {

        // Given
        WindowControl control = new WindowControl("My AFrame");
        AFrame frame = new AFrame();

        // When
        control.closeWindow();

        // Then
        ensureThat(!frame.isShowing());
    }
}

or another convention I saw:

public class WindowControlShould {
    @Test
    public void closeWindows() {
       //...
    }
}

The problem here is that you have 3 elements in a test: the ‘entity’ subject of the test (usually a class name), the condition (‘when calling some method with some specific parameters), and the expected result, that as we saw in BDD with the “shouldDoSomething” method name. So the problem is that with the class name and the method name we only have two elements to describe our test.
To express the 3rd ‘entity’ of the phrase, I tried to use inner classes to define tests like this:

public class WindowControl
    public static class WhenCloseWindow {
        @Test
        public void shouldCloseWindows() {
            //...
        }
    }
}

But it isn’t supported by JUnit4.

I thought that packages might help, like specifying them as

package com.mycompany.blah.blah.windowcontrol;
public static class WhenCloseWindow {
    @Test
    public void shouldCloseWindows() {
        //...
    }
}

But in this way you lose the possibility to invoke default and package accessible methods, which is a thing that I quite like in my tests.

My feeling now is that first the test methods were identified by a naming convention. Then with the annotation, the convention has been left to the developer to choose, or even the choice to not have a convention at all. The annotation, for me is more close to a configuration thing, which is replacing a convention; a sort of counter-tendency in the trend of convention over configuration paradigm. So if we start to call our test method shouldSomething() are we not going back to the old convention testSomething() ?
Well I liked the conventions used in JUnit 3 and I don’t really see big improvements in using the annotations, or being free from extending the TestCase class, which was providing the assert* methods: with JUnit4 we have to static import those methods from the class Assert; I don’t see it as an improvement.
My taste is that, if we can’t easily find a descriptive naming convention for what we are testing, relying on some comments could be the best thing. The example above – the one coming from wikipedia – is in fact using a naming convention plus some comments in the code. I think that using a comment on top of the method would have served better the purpose of describing the test.

Finally, some continuous integration tools are able to format the test names (class + method) to show a sentence describing the test nicely in natural English language.
That is cool, but since we have the @Test annotation already there to configure the test, why not having a descriptive attribute that can be used from reporting tools, like:

@Test(description="when WindowController.closeWindow() is invoked the window is closed")
public void testCloseWindow() {
    //...
}

Or, since I criticized the @Test annotation, a short java comment would have sorted the same purpose for the tools willing to describe the test with a plain English description.

Since there isn’t around a really good naming convention for tests, since I don’t see real improvements using annotations and static imports… I think that JUnit 3 was doing right.

What do you think?

I remember to readers that there is a script to generate those on this blog post, where I also explain how to use those files.

For the ones that want to avoid to run my buggy script, in this blog post you can find some source bundles for android versions, ready for use.

Recently I'm very busy at work and in the spare time so I am not posting regularly; my todo list (or topost list) for this blog is getting long.

Just in case I'll not find time to write here before... Happy Christmas.