The site is here: ScalaCareers.com, and you can follow on Twitter for announcements of new jobs posted and other things @scalacareers

In my opinion, jobs for a new language are extremely important in helping it get to the next level of adoption. Scala is already pretty popular and Lift is gaining in popularity, so I hope we start to see a lot more jobs that involve Scala and Lift.

I’m going to be posting some short tutorials and other things related to my experience in the coming weeks, but I thought I would share a few quick, high-level thoughts.

1) Lift is a solid, production-ready framework. I was able to learn enough of it to build a functional, albeit small, web application over the 4th of July weekend. Despite using a snapshot of the 1.1 release, I didn’t run into any bugs or severely out-of-date documentation. I mention this because it has been a slight problem when I’ve been an early adopter of frameworks in the past.

2) The Lift community is incredibly friendly and helpful. Going back through several months of activity on the Google Group, they are generally accepting of criticism, quick to offer help, and even commit changes to the trunk quickly to help folks out. A good community is very important to newcomers to a new language or framework.

3) Using Lift requires a good knowledge of Scala to really be effective. Don’t get me wrong - learning Scala is well worth the effort - but it was a bit of a change for me, coming from Grails where I was able to sort of ease into it.

4) IDE support for Scala is still a little disappointing. Even though I love Groovy, I generally prefer static typed languages to dynamic typed ones, which is why I was interested in Scala in the first place. One of the big benefits of static typed languages is that you can theoretically get better IDE support. I shelled out a few hundred bucks for IntelliJ for this purpose, and while it was marginally better than the others, I still found lots of cases where auto-complete simply didn’t work and plenty more cases where it didn’t catch compile errors. It probably cost me a few hours on the project. A good IDE doesn’t make you a better developer, but it does make you faster :)

Overall, I think Scala and Lift have bright futures and are worth checking out.

What is printed?

1. true
2. false
3. It doesn’t compile
4. Runtime error

From a logical perspective, #1 is right - 10 days from now is after now, so you’d expect to see ‘true’ printed. From a language perspective, you may think “you are passing in a java.util.Date to a function on java.util.Calendar, so it wouldn’t compile”, and choose #3. Neither of these are correct - the block of code above completes normally and prints ‘false’, which is not what we wanted.

If you take a look at the javadocs for java.util.Calendar, it is easy to see why. The signature for after (and before) is public boolean after(Object when), but if you pass anything but a java.util.Calendar in, it will *always* return false. This is an unfortunate api design problem - it is reasonable to expect that you could pass in a java.util.Date, or even a long representing a timestamp to compare to the Calendar instance and it would work normally. The fact that either of those options compiles and runs without error can cover up the flaw in your code, and be difficult to track down (which is how I came across it and decided to write this post).

I am stumped trying to come up for a good reason for the method to accept Object (which means anything can be passed in - even primitives from Java 5 on) only to return false if it is anything other than java.util.Calendar. The method signature should be public boolean after(java.util.Calendar when), so that you get a compile error instead of a silent failure at runtime.

Now, this library has been around since JDK 1.1, so I’m not exposing a new design flaw or anything. I am, however, curious as to how something so clearly anti-idiomatic Java (and anti-static typing) made it into a core Java library. Anyone have any ideas? The Date/Time APIs in Java are generally pretty bad anyway, but this seems especially poorly done.

I mostly write business code, and not much in the way of API code, but I have been reading the 2nd edition of Josh Bloch’s Effective Java and it has given me a better appreciation for the thought and effort that goes into creating useful APIs. It is always interesting to see some of the really good *and* really bad examples of API design in the core Java libraries.

1. Check your code into Subversion (or CVS or whatever SCM of your choice - this guide assumes Subversion, however).

2. Add a build directory on your prod box (I have mine at /home/build/) - then check out individual projects under it (ie, /home/build/wiifit/).

3. In each project, add a property to application.properties for the deployment directory (ie - deploy.dir=/home/tc6/server/wiifit).

4. In grails, you can add groovy scripts to the /scripts/ directory, and then run them with grails , ie, ProdPush.groovy can be called with ‘grails prod-push’. Let’s add a script in to do the following things:

- Do a subversion checkout to get our latest changes.
- Build the war
- Copy it to our directory

This is what I came up with:

Your script can have multiple targets. If you specify a ‘default’ one, like I have above, it is what will be run if you supply no target (which is what we want).

5. Now I have a simple shell script on my server to setup the environment variables and run the build.

This script can then be re-used for all projects on the server.

6. To update our app, we simply do the following:

- Check our changes into Subversion
- SSH into our server and go to our /build/ directory
- Run the build script (ie, ./build.sh wiifit)

Our new app is live in less than a minute and we don’t kill our home internet connection :)

This solution may not be very good for high-usage, critical apps - if I were building (and leaving code) on a production app server at my day job, I’d be fired (and deserve it!) - but for small apps like I build, it is a good solution. This solution is pretty simple, but I’m working on a full deployment plugin for grails - fewer setup steps, tomcat management, etc.. If you have any suggestions or ideas, let me know.

This application is fairly simple - it displays a google map view that is centered on the user’s location, and inserts a marker where they are located. I am using MaxMind to turn an IP into latitude and longitude coordinates. They cost money and you may be able to find a free one, but they aren’t that expensive (something like $20 for 50,000 lookups) and I’ve been pretty happy with them so far.

There is a GWT+Grails plugin that makes it easy for Grails and GWT to work together. I am also using GWT-EXT to make it look nice, and to make the GoogleMaps integration a little easier. If you want to see this app in action, you can see it here (it may not match the example exactly - I’m actively developing it). I’ve also made the entire project available for free, here.

1.Create a new Grails application (grails create-app findme)

2.Install the Grails + GWT plugin (grails install-plugin gwt)

3.Create your Grails Module (grails create-gwt-module net.uresk.FindMe)

4. Create your page (grails create-gwt-page main/index.gsp net.uresk.FindMe, answer yes when it asks if you want it to create the controller)

5. Download GWT-EXT (http://gwt-ext.com/download/), put gwtext.jar in your project’s lib/gwt directory (ie, $PROJECT_NAME/lib/gwt). You’ll also have to put it into the plugins/gwt-0.2.4/lib directory.

6. We’ll then have to hack _Internal in the /plugins/gwt-0.2.4/scripts/ directory (hopefully this won’t be necessary in the next version of the plugin). Around line 89, you’ll have to add in another include entry after the others:

Include(name: ‘gwtext.jar’);

We’ll also need to go down a few more lines, and before ‘pathElement(location: “${basedir}/${srcDir}”)’, add ‘pathElement(location: “${basedir}/lib/gwt/gwtext.jar”)’.

Lastly, if you get an error about heap space, you’ll need to give the gwt compiler more heap space. Do this by adding in ‘jvmarg(value: ‘-Xmx256M’)’ a few lines down (around line 102), just above where the other arg() lines start. Not sure if this is related to using gwt-ext, running on Mac OS X, or what, but I did run into it a few times.

7. Download EXT 2.0.2 (http://yogurtearl.com/ext-2.0.2.zip), copy the ‘adapter’ and ‘resources’ directory, along with the ‘ext-all.js’, ‘ext-all-debug.js’, ‘ext-core.js’, and ‘ext-core-debug.js’ into your project’s /web-app/js/ directory.

8. Download mapstraction (http://mapstraction.com/svn/source/mapstraction.js) and copy it into your applications web-app/js directory as well.

9. Open up your Grails project (I prefer IntelliJ for Groovy/Grails development at the moment, btw) and find the FindMe.gwt.xml file (it is in /src/java/net/uresk directory). Add in the following:

<inherits name=“com.gwtext.GwtExt” />
<stylesheet src=“/findme/js/resources/css/ext-all.css” />
<script src=“/findme/js/adapter/ext/ext-base.js” />
<script src=“/findme/js/ext-all.js” />

10. Add the following entries in:
Create your Google Maps keys for localhost and for your production domain. To make things easy, I added a config property in called ‘googlemaps.key’, and then added this into my controller to get it for the right environment:[key: grailsApplication.config.googlemaps.key]12. In your index.gsp, add in the following:

A reference to mapstraction: <script type=”text/javascript” src=”/findme/js/map/mapstraction.js”></script>

The google maps js include: <script type=”text/javascript” src=”http://maps.google.com/maps?file=api&v=2.x&key=${key}”></script>

13. Now create a service called something like LookupService, and add in the following code to access MaxMind:

class LookupService {

        static expose = [‘gwt:net.uresk.client’]

        Double[] getLatLonFromIp(String ip){

                if(!(ip ==~ /bd{1,3}.d{1,3}.d{1,3}.d{1,3}b/)){
                        ip = defaultIp
                }

                def res = “http://geoip1.maxmind.com/b?l=${maxMindKey}&i=${ip}”.toURL().text.split(“,”)
                Double[] result = new Double[2]
                result[0] = Double.parseDouble(res[3])
                result[1] = Double.parseDouble(res[4])

                return result
        }
}

You can swap out MaxMind with any other service. I added a maxMindKey config property in Config.groovy, but you can easily hard-code it.

14. Now create your GWT client code, something like this:

GoogleMap mainPanel;

    /**
     * This is the entry point method.
     */
    public void onModuleLoad() {
                createPanel();
            new Viewport(mainPanel);
            updateLatLonFromMaxMind();
    }

        private void updateLatLonFromMaxMind(){
                LookupServiceAsync myService = (LookupServiceAsync) GWT.create(LookupService.class);
                ServiceDefTarget endpoint = (ServiceDefTarget) myService;
                String moduleRelativeURL = GWT.getModuleBaseURL() + “rpc”;
                endpoint.setServiceEntryPoint(moduleRelativeURL);

                AsyncCallback callback = new AsyncCallback() {
                  public void onSuccess(Object result) {
                    Double[] latLon = (Double[])result;
                        setLatLong(latLon[0], latLon[1]);
                  }

                  public void onFailure(Throwable caught) {
                    // do some UI stuff to show failure
                  }
                };

                myService.getLatLonFromIp(callback);
        }

        private void setLatLong(Double lat, Double lon){
                LatLonPoint llp = new LatLonPoint(lat.doubleValue(), lon.doubleValue());
                Marker m = new Marker(llp);
                m.setInfoBubble(“<div>You are here!</div>”);
                mainPanel.setCenterAndZoom(llp, 10);
                mainPanel.addMarker(m);
        }

        private void createPanel(){
                mainPanel = new GoogleMap();
                mainPanel.setTitle(“Spencer’s Google Map Page”);
                mainPanel.addLargeControls();
        }

15. Now, we need to create the stubs for this service so that GWT can use it. Do this by running ‘grails run-app’.

16. Unfortunately, there currently isn’t an easy way to get at the HttpRequest object inside our service. There is a JIRA item open for this, and I’m working on a potential solution. In the meantime, we’ll have to do a bit of hacking.

First, we’ll need to open up the LookupService and LookupServiceAsync java files that the plugin generated – they are in /src/net/uresk/client in this example. Modify the method signatures so they don’t take a String object (the IP). They should look like: java.lang.Double[] getLatLonFromIp(); and void getLatLonFromIp(AsyncCallback callback);

Next, we’ll need to modify the GrailsRemoteServiceServlet (in /plugins/gwt-0.2.4/src/groovy/org/codehaus/groovy/grails/plugins/gwt). On line 53, we are going to modify the method call so that it explicitly passes in the ip address, by changing it to say this:

def retval = service.invokeMethod(serviceMethod.name, this.getThreadLocalRequest().getRemoteAddr())

If you are using this behind a proxy (ie, behind Apache HTTPD with mod_proxy), getRemoteAddr() won’t work – you’ll have to instead get the X-Forwarded-For header value.

This is a nasty hack, and will break all your other GWT RPC calls, so if you are going to do more with this example, you’ll have to do something a little smarter to inject the IP (contact me if you want some ideas, and also keep an eye on the JIRA item mentioned above). Hopefully it won’t be necessary much longer.

You should be able to run your application now! Do ‘grails run-app’ again and browse to http://localhost:8080/findme/main.

Let me know if you have any questions or suggestions. I also hang out on the #groovy IRC channel on the evenings and weekends (GMT -700) if you need help.

Have fun :)

Special Thanks to Abhijeet Maharana who provided an excellent how-to for using GoogleMaps with Gwt-Ext.

Update: Sorry, I forgot to include the GWT client code in the original post. It is in there, step 14 now. Let me know if I missed anything else.

For goal #1, Grails is clearly fitting the bill. I spent the last year or so developing Rails apps, and Grails feels almost as productive. The community around it is getting quite active and there are some excellent plugins.

Reaching Goal #2 is going to be a bit trickier, but I think we are getting close. I am able to deploy 3 or 4 Grails applications on a 256 MB VPS now, and they work reasonably well. The good thing is that VPS’ are getting quite cheap, and a VPS with 256 MB of memory can easily be had for less than $20/month. (Shameless plug - I am putting together a site - VPS hosting reviews - that lists vps providers, their plans, prices, and reviews. And it is developed with Grails and running on a VPS :) )That said, you wouldn’t want to do this if your applications get a ton of traffic, and hosting a Java application will never be as cheap as hosting PHP applications.

Getting several Grails/Java applictions deployed on a server with only 256 MB of RAM (and on a VPS, no less, where getting a big block of contiguous memory can be tricky) takes a bit of work, so I’ve decided to detail a few things I’ve learned. This is specifically for Grails applications, although most of the tips should be helpful for any other Java application deployment as well. It also assumes you are using Tomcat as your app server.

1. Dump Apache HTTP server

A lot of people (including me for the longest time) would use Apache to forward requests to Tomcat. There is nothing wrong with Apache HTTP server itself, but in this setup, it can eat up a bunch of memory and really isn’t necessary. You can use iptables or xinetd to forward requests from port 80 to your app server. A good tutorial for these options can be found here. Doing this should free up a bit more precious memory for your app server.

2. Make sure you are using the server JVM

This is easy to forget to do - HotSpot will automatically choose which vm to run based on server attributes, so on a real production box, it will choose the server vm automatically. On a VPS, you’ll need to manually do this by adding “-server” to CATALINA_OPTS.

3. Give you server more PermGen space

Groovy uses a bit more PermGen space than normal, due to all the classloading it does. This means you’ll probably want to configure your vm to use a bit more PermGen space than usual by doing -XX:MaxPermSize=m. On my server, setting this to about half of the overall memory allocated seemed to be the best, but your results may vary.

4. Experiment

Ideally, you’d just upload your apps and not worry about tuning, but when you are trying to squeeze the most out of a VPS, this isn’t the case. Play around with different memory settings and other vm options to see what gets your particular setup the best performance and stability. Feel free to share what works well for you :)

Ah, the smell of a fresh codebase.

I’m certain most software developers who have been around for any amount of time have had to work on “The Project”. This project has probably been going for years, has had a fair amount of turnover on the development team, and has had a handful of architects (with their own way of doing things).

Projects like this may work wonderfully and be very successful from a business standpoint, and the individuals working on them are likely quite competent. Yet, from a development perspective, they are a nightmare. They contain difficult to understand code, lots of unused (or commented out) code, little testing, little adherence to good development practices, few comments, and a general feeling of brittleness.

Code like this may work exactly as intended, but when a codebase gets disorganized, chaotic, and sloppy it can lead to other problems, such as:

• An unpleasant experience for developers

• High cost to refactor code

• More bugs

I’ve worked on a few projects like this over the last 5 years or so, and was naturally excited when I found we were going to be starting with a fresh codebase. At last, all of this cruft that has accumulated over the half a decade this project has been going will no more!

Imagine my surprise (and dismay) a month after the new project started when I found most of the symptoms of “The Project” starting to present themselves in the new codebase. Looking through our project and the reports we generate (PMD, CPD, Clover), I saw:

• Lots of untested code

• Lots of bad practices and sloppy coding (as shown by PMD – we really pared down the ruleset so we don’t get a ton of false positives)

• Unused code (already, after less than a month!?)

• Commented-out code

• Methods that were too big, hard to understand, or uncommented

Part of this was due to spikes being done for the new project, which led me to conclude that spikes or experimental work of any kind should always be done in a branch. I also became interested in how code gets to this state so quickly, and of far more importance, how to keep it from reaching this state.

I don’t think this happens because people are bad developers necessarily, but because it requires a large degree of diligence and policing to keep a codebase clean and well-organized. It is easy to let organizational or quality issues fall to the wayside when working on functionality, and timelines sometimes leave little time for these tasks.

Some people offer up pair programming as a way to avoid this, but I don’t particular care for it (see my comments on pair programming). I think situational pair programming is an excellent practice, but I think full-time pair programming is, besides a terrible waste of time, largely ineffective.

After doing some research and analysis of how we work, I’m beginning to think that peer reviews are an excellent solution and practice. They provide most of the benefits of pair programming with few of the drawbacks. You still have someone examining your code, asking questions, and offering feedback, but instead of doing it for an entire iteration or whatever (where one of you will likely be bored for a good portion of the time), you do it for an hour or whatever is necessary. The only potential drawback is that if someone is totally off on their approach and it isn’t noticed until the end, it could be costly to refactor (so costly, in some cases, that it may be left in its sub-optimal state).

With that in mind, I set out to attempt to come up with good practices for conducting code reviews, and also best practices we should be following to keep our codebase clean and easy to work with. I’m wondering what other organizations are doing for peer reviews, and what I can do to improve the stuff I came up with.

It should be noted that a peer review is largely orthogonal from a QA review – a particular block of work can pass the QA review with flying colors and totally fail the peer review. The way I see it, QA reviews inspect the interface, peer reviews inspect the implementation.

Here is the document I came up with:

–

The peer review should occur prior to resolving a story or bug. At least 30 minutes should be set aside for a peer review, to allow for a thorough review. Once the review has been completed and the reviewer is satisfied, they should leave a comment on the JIRA entry stating that they have peer reviewed the unit of work.

Besides following this checklist, you both should go over all the code you wrote for this story. The reviewer should not hesitate to point out how something could have been done in a better way. If the reviewer cannot figure out what a particular piece of code does in a relatively short amount of time, it should be re-written or comments should be added in the code.

1. Metrics / Standards

- (any coding metrics – code coverage, static analysis, etc)

- Test coverage should be meaningful – ie, don’t just check that a method executed without throwing an exception

- Use the right kind of test for your code (ie, some code may need just unit tests, others may need integration tests, and some might need functional tests)

- Business logic is properly tested with unit tests

- If this is a bug, was a unit test specifically for that bug created?

2. Code Style

- Properly formatted Java code

- No commented-out code

- No unused code

- JPA standards followed (we have a separate document for this)

- If you have to explain a piece of code to your reviewer, that piece of code should be documented

- If your code is meant to be re-used throughout the app (ie, a utility class) it should have descriptive and useful JavaDocs

- Classes should be fewer than 500 lines of code, and any over 250 lines should be scrutinized closely

3. View

- All JSF controls have explicit ids

- Everything works in IE (firefox support is strongly recommended, as well)

- All fields validate properly (ie, no 500 errors when you put in invalid values)

- JSF pages named consistently

–

This is part policing – making sure people are following best practices we’ve set forth, and that part of it kind of sucks. It is also part informative, however. Ideally, both the reviewer and the developer are learning from the experience. The reviewer may see a way to do something better and thereby make the code better and increase the skill of the developer. The reviewer may also see something that educates them as well.

In the limited testing I’ve done with this, it has worked well. I personally like having someone look at my code with me and let me know what I could have done better, or what piece of code is not quite as intuitive as I thought it was (everything I write is totally intuitive – to me!). I’m curious as to what other people’s thoughts and experiences with regards to peer reviews are, however.

import groovyx.net.ws.WSClient

def proxy = new WSClient(“http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl?”, this.class.classLoader)

def req = proxy.create(“com.amazon.webservices.awsecommerceservice._2008_04_07.ItemSearchRequest”)

req.searchIndex = ‘Books’
req.keywords = “Groovy and Grails”

def search = proxy.create(“com.amazon.webservices.awsecommerceservice._2008_04_07.ItemSearch”)

search.AWSAccessKeyId = “your id here”
search.request.add(req)

def res = proxy.ItemSearch(search)

res.getItems().each {it.getItem().each {
println it.getASIN()
}}

If you’ve downloaded the GroovyWS jar and put it in your GROOVY_HOME/lib, that should work. I think it is kinda cool how quick and easy it is you can get something simple working with GroovyWS, but if you are going to be using Amazon Web Services a lot, it is probably easier to grab the Java Library that Amazon provides and use it. Here is the code for using that in Groovy:

import com.amazonaws.a2s.model.*;
import com.amazonaws.a2s.*;

class AmazonSearch {

String key = ‘your key’
String tag = ‘your associates tag’

def doSearch(String keywords) {
AmazonA2S service = new AmazonA2SClient(key, tag)
ItemSearchRequest request = new ItemSearchRequest()
request.searchIndex = ‘Books’
request.keywords = keywords
processRequest(service, request)
}

private processRequest(AmazonA2S service, ItemSearchRequest request) {
ItemSearchResponse response = service.itemSearch(request)
response.getItems()[0].getItem().each {
println it.getASIN()
}
}

static void main(args) {
AmazonSearch search = new AmazonSearch()
search.doSearch(“Groovy and Grails”)
}

}

To give you an idea of why I think telecommuting is feasible (and attractive), here is my typical day, which isn’t too terribly different from that of many other IT workers:
- Get ready for work, throw my laptop into my backpack, and head out the door.

- Drive the 15 or so miles to work. Usually I am lucky in the morning and it only takes 30 min or so to make the drive.

- Unpack and dock my laptop, and get to work.

- Throughout the day, much of my interaction with my co-workers is done via IM and email. People are too spread out (different floors, different buildings, etc) and often too busy for real-time human interaction all the time.

- Work ends, throw my laptop back into my bag, drive the 15 or so miles home (this trip takes me 45 - 60 minutes).

So, each day I drive 30 miles and spend roughly 1.5 hours commuting to and from work. Over a week, that is 150 miles and 7.5 hours - almost a full workday! Thankfully, the new train is starting to run next week, so some of this will be mitigated, but it is still a fair amount of time and money spent commuting. Add to this other problems that are common for many companies - lack of space, parking issues, and other facility issues.
So, why not have employees telecommute a handful of days per week? Think about the benefits:

Employees

- Less time in traffic
- Less spent on gas and maintenance
- Ability to focus on your tasks for a few days (I get far more done on the rare days I work from home)

Employers

- Happier employees
- Less need for parking space
- Less floor space needed for employees

Society, the economy, and the environment

- Less gas being used
- Less pollution being created
- Roads that are less congested

I understand as well as anyone the need for people to be at work in-person and to have face-to-face time with other employees. I don’t think this needs to be every day, though. In fact, I think many of us would benefit from less time available for meetings - people scheduling them would have to think hard about whether or not a full-blown meeting was necessary, or whether whatever they are trying to accomplish could be done with a few emails.
If a large percentage of IT workers worked from home just 2 or 3 days per week, the impact could be quite large - think of all the time and energy savings. There is no good technical reason for not encouraging such policies - technology exists to allow this (many companies already have it in place and use it to a small extent), the nature of our jobs is very conducive to working off-site, and several companies (ie, RedHat), already do it to a large extent with great success.

One argument against telecommuting is that it makes it hard to keep people accountable. I’d argue that it is pretty easy to see who is getting their stuff done and who isn’t, regardless of where they are working from. If you are paying someone $100k per year to write code for you and don’t feel like you can trust them enough to let them work out of your sight for a few days, you have far bigger problems. It also kills me when companies have no problem outsourcing projects halfway around the world to people they don’t know (and can’t communicate with very well), but balk at letting employees work from home a few days per week.

I don’t see why more companies aren’t pushing this, why government at various levels isn’t pushing it, and why more employees aren’t clamoring for it. Yeah, it takes a little extra work, requires some trust on the part of the employer, and may cost a bit in initial setup (VPN, security, bigger pipes to handle the traffic, etc), but to me, it seems like it pays of well in the long run.

Reading through the instructions, I found that I needed to be a registered iPhone developer - and pay $99 for the privilege. Not a big deal, but after I signed up (I wasn’t asked to pay), I was told I would be contacted when I could complete the registration and (presumably) get my certificate.

I don’t really mind paying $99, but having to wait around for them to let me in is kind of a let-down. Bummer.