Graham O' Regan

I swapped over to a Macbook Air at the start of last year for development and I made the mistake of opting for a 128GB SSD instead of the bigger 256GB option thinking that I wouldn't need the extra space. It turns out that I find it almost impossible to run on less than the 160GB I had in my last Macbook Pro, by the time I've installed my dev chain, including Java and iOS tools, along with a range of browsers and email clients, I usually find myself floating around the max disk space mark.

I've been hitting the buffers a lot this week so I had to take a look to see where I could save some space and managed to reclaim 25GB by following a few simple steps;

1. Run Disk Inventory X - This scans your HDD/SSD and provides a visual representation of the allocated space. This highlighted a few big files that helped me reclaim most of the space I'd lost. In /lost+found there was an iNodeXXXXXX file which is actually a copy of the Lion installer - removing that saved 3.4GB straight away. I also removed an old copy of Microsoft Office that no longer works with Lion, I tend to use iWork apps these days so it won't be missed.

2. I removed a lot of the iLife applications that I don't use, like Garage Band and iPhoto, which saved a few GBs of binaries and sample files.

3. I ran Monolingual to remove almost every language from the machine with the exception of English dialects. I ran it when i bought the machine, but after an OS update and a few purchases from the App Store a lot of the translations seemed to have crept back.

4. Reboot - as obvious as it seems I don't tend to rebook unless a software update requires it and its amazing how much temporary space is being wasted by the programs I run for caching. I'm sure those settings are tuneable but I'd prefer to run with as much caching as I can and just reboot when I need to to clear up the mess.

I also purged a lot of old podcasts - I had a lot of files kicking around for podcasts that I probably won't get around to listening too. I also removed all web archives and SNAPSHOT builds from my Maven repository which clawed back a few more GBs.

Hopefully that'll keep the OS happy for a while, if not I'll be in the market for some new hardware soon :)

We moved just before Christmas and we were without an internet connection for almost three weeks so I didn't have much of a chance to play around with my cloud-based development setup. We're finally up and running with a decent connection at home so I'm aiming to get back to it over the next couple of weeks.

I've gotten to the point where I can run  Eclipse over X-Windows but it is completely unusable, there is way too much lag. I know there are better options for remoting but I really want something that runs on OS X and iOS. I've even considered trying a Windows server in the cloud instead as RDP is probably the best remoting option I've used. I just can't convince myself to move back to Windows for development, though, I haven't used Windows in over five years now and I'd really struggle with the the working environment.

I've run my own version of Cloud9 and I might have to stick to that and look at a mechanism for duplicating and synchronising  some of my IDE hacks. On the plus side, it is great to be able to push builds out to a box in the cloud with more bandwidth, RAM and processing power than I have at home or on client sites. If I can get more of my tools working on the CLI then moving from laptop/desktop development might actually be a viable option.

I've been using Git for version control for my projects for a few years now but some of the projects are only backed up on TimeMachine and I'd prefer to put them somewhere where they can be shared quickly.

I already use Github so it seemed like a sensible place to start but they have a limit on the number of private repositories that you can have and I can't share some of the code that I maintain for people. I also use Dropbox so I had a quick look to see how well that would work for sharing instead.

Just to clarify, you could use Dropbox with Git in two ways; put your local repository under your Dropbox directory so Dropbox backs up your updates or use Dropbox as a remote repository so it can be clone by other developers once it has been shared. In this case I'm looking at the latter as I need to be able to share the code and I don't want the people I'm sharing with to access my version of the repositories.

Getting a Git repo working on Dropbox is very simple, I took an example for setting up a remote repository using SSH and modified it for Dropbox. The project I'm using is called 'ampd' and I'm using ~/Dropbox/Projects to hold the remote repositories.

# Create the bare clone that will act as the remote repository

git clone --bare ~/projects/ampd/.git /tmp/ampd.git

# Put that into the Dropbox directory

mv /tmp/ampd.git/ ~/Dropbox/Projects/

# Lets clone the new repository

git clone ~/Dropbox/Projects/ampd.git/

You will have a directory in your cwd called 'ampd', have a play around pushing and pulling changes from the Dropbox repository. I've wrapped functionality up into a script called 'git2dropbox' so I can quickly migrate my existing projects but the script is a bit too crusty to share right now :)

The scheme works pretty well but I haven't used it in anger yet. I'd anticipate problems when pushing to the Dropbox repository when offline so it will probably be necessary to enforce a rule that pushes to that repo should only be done when online to give Dropbox a chance to handle the updates in it's normal way. I'll run it for a while and see how it goes, it could work well as a cheap way of hosting a bunch of repositories that you aren't ready to share openly.

I managed to spill coffee on my Macbook Air this week so I've had to hand it over to Apple support to have a new keyboard fitted. The guy in the Kingston store was really helpful, I gave him an external HDD and left him to it for a couple of hours and he copied my whole home folder over so I haven't lost anything and I'm back up and running with most of my application settings once again.

I had a similar problem around this time last year when I closed the lid on my old MBP a bit too vigourously and damaged the logic board. It was going to cost £500 to repair so I decided to whip the SSD out and put it in my Mac Mini and bought one of the second generation MBAs instead. I had intended to keep the laptop as clean as possible with as little data as possible on it so I wouldn't become too dependent on the physical machine itself.

In the past year I've moved almost everything to cloud services, I've been using Gmail and Google Mail for domains for my email accounts and calendar and I've added Dropbox and Evernote to my tool chain in the past year for most work related tasks. I keep my source code in Github I use FreeAgent for my accounting and I tend to use Spotify/Mixcloud/Soundcloud for music so I don't have much data left that I need to worry about myself.

The one thing I still haven't managed to move to a cloud-based service is my development environment. I've tried hooking Cloud9 up to Github but I have years of editor and IDE customisations that I can't live without so c9 just doesn't cut it for me. I've decided to look at an idea that I first discussed with some of the guys a couple of years back - hosting an EC2 image and using X-windows over SSH to access it.

So, I'm in the middle of setting up an image right now and getting my tools set up on it and I'm going to keep a journal of how it goes for the next 2 weeks. I shouldn't have any problem getting it working on my laptop and desktop and I'm also going to try it on my iPad. In theory I could be free of having to worry about managing backups myself from now on and I'll be free of any hardware shackles. Hopefully, by the other side of Christmas, if I were to damage or lose a computer again I can just nip out and buy another, login to my array of services and and be right back where I started. No more USB cables tied up with power cables, no more forgetting to sync with Timemachine and (potentially) less Apple tax in future.

I'll let you know how I get on :)

lol, didn't think actually read this blog so I've decided to replace that other post with a quick post on how to get the three running together.

I don't think enough Java developers realise what a time-saver JRebel is, I honestly don't know how people work without it these days. With JRebel in place I can add new methods, change existing method signatures, alter annotations and add imports, even in external projects, without having to restart my application server. You get the benefits of static typing and compile-time checks, but the f5 reloading that dynamic typed camps have long enjoyed.

Adding Jetty support to your Maven build is very simple, just add the build plugin to your pom.xml;

[project]
    [build]     
        [finalName]test[/finalName]
        [plugins]
           
            [plugin]
                [groupId]org.mortbay.jetty[/groupId]
                [artifactId]maven-jetty-plugin[/artifactId]
                [version]6.1.22[/version]
                [configuration]
                    [contextPath]/${project.build.finalName}[/contextPath]
                    [scanIntervalSeconds]0[/scanIntervalSeconds]
                    [connectors]
                        [connector implementation="org.mortbay.jetty.nio.SelectChannelConnector"]
                            [port]8080[/port]
                        [/connector]
                    [/connectors]
                [/configuration]
            [/plugin]
        [/plugins]
    [/build]
[/project]

That will start the application under the 'test' context so it would end up running on http://localhost:8080/test/ . To run the application, just run 'mvn jetty:run' at the command line. There are other goals for the jetty plugin, but I tend to just run it like that and ctrl-c to shut it down when I need to.
Once you have your application running straight from your build directory, it is very easy to add JRebel to the mix to reload code without having to stop the server. I already have my $MAVEN_OPTS configured in ~/.bash_profile and I've added another environment variable called JREBEL_OPTS which contains the additional JVM flags that JRebel needs to instrument your application. I've added a quick script to my $PATH that appends the $JREBEL_OPTS to my $MAVEN_OPTS and then calls the Jetty plugin, you may want to do the same because you won't want JRebel running on every Maven call, it only makes sense in my situation to run it when I'm running a servlet container. As @happygiraffe pointed out, you can do this with just MAVEN_OPTS="$JREBEL_OPTS $MAVEN_OPTS" mvn -o jetty:run , a much neater solution than my original reset().

Once you have this set up it should save you a lot of time when developing Java web applications and services. Over the past 30 days, JRebel reckons it has saved me 114 restarts which equates to 4.6 hours, a saving that quickly justifies its cost.

I spent a lot of time working with @ccharlesworth on a large Grails project last year, and, whilst I loved the usability of the framework, I struggled with its performance and a few idiosyncrasies that we were working around so I eventually decided to migrate the codebase back to Java with annotations for Spring MVC, Java Config and JPA. It didn't take that long to move the bulk of the code, but there were some features that I knew I'd miss from Grails so I wrote a few libraries to make the transition easier and separated as much of the reusable code from the main application.

After a busy summer last year with work and getting married, we finally got back into developing this winter so I dusted down some of that old code to see what we had. Chico has been getting into Play recently and it seems to have raised the bar a notch in terms of developer productivity, so if we are to continue using the older codebase then I really have to get it close to their offering. It has taken a few weeks of evening and weekends to get it to the point that we can really start motoring again, but it seems to be paying off now. I've updated our archetypes, templating (ala RoR/Grails) and support libraries and we're looking at moving as much as we can to a public repo on Github soon so we can share it with some friends of ours. There is one major issue with the codebase relying on Threadlocals to mimic some of the functionality of Grails, but I'm happy enough to leave it as it is for now.

I've already created a few new apps with the framework already, notably; a PoC for a national electricity provider that wants to trial a system of charging points for electric cars, and our new continuous deployment (CD) server that I'm hooking up with Jenkins and Dropbox to make it easier for ourselves and our clients to share code. There have been a few problems with the dependency management, but I think I've ironed out most of the wrinkles now and the work is really beginning to pay off in terms of the time it takes to write new applications and the ease of managing some of our existing applications.

I've also been getting back into mobile work recently, in fact I changed phone to a Google Nexus S so I can run the applications natively rather than using an emulator. I've got a PoC coming together for someone with a service layer running as an engine for some native mobile applications. Hopefully I'll have something to show soon, but I'll let you know :)

Anyhoo, more info as I get time...

On paper the hardward specs are virtually identical, but the I upgraded the laptop just after Christmas with an SSD and its only now that I can really see the difference it makes. I'm tempted to get another one for the mini, but I'd like to have a bit more local storage so I'll leave it for now and see how it works out.

I've loving the new last.fm 'loved' tracks playlist from Spotibot, just add your last.fm id (or anyone else's for that matter) and they will match as many of the songs as possible in Spotify.  They managed to match around 80% of the tracks that I had loved over the past four years, have a listen to my playlist here;