Rich Internet Applications (RIA)

This article originally appeared in the June 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 4 and 5 are currently available for download from the magazine’s site, and more will come each month. Enjoy!

The Groovy Programming Language advertises itself as an “agile and dynamic Language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each months article will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

About this Series
Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. The previous installments included a short introduction to Lean, explained how an expressive language can eliminate waste in unit testing, and showed how the easyb Behavior Driven Development framework and Groovy Builders can build quality into your life-cycle. In later months we’ll explore how a dynamic language lets you minimize coupling and defer commitment, and how metaprogamming allows you to deliver fast. You’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between development and other groups like operations and QA (an important aspect of respecting people). Finally, we’ll look at optimizing the whole by applying Groovy to domains that cross department boundaries: how Gradle improves the build process and easyb serves as a collaboration mechanism between different organization roles. The series will end with a discussion on the best practices of mixing Java and Groovy.

Some of the code examples are basic while others are advanced. The articles explore why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly, how to increase your productivity.

Lean Revisited
Part 1 of this series contained a more indepth explanation of Lean, and I won’t repeat it here. But as a quick refresher here are the 7 lean principles along with a summary for those principles covered previously:
1. Eliminate Waste – Reduce work in progress and half done work
2. Build Quality In – Instead of settling for finding defects, optimize your process to create fewer defects
3. Create Knowledge
4. Defer commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Principle 3 – Create Knowledge

I prefer the term “Software Engineer” to “Programmer” because it evokes a sense of professionalism, adherence to standards, and attention to quality that sometimes seems lacking in our industry. But “Engineer” also carries negative connotations when applied to software. As my co-worker Mike Mannion says, “Software development has less to do with conveyor-belt-fabrication (the image unfortunately most likely to be to be conjured up when we use the word engineering) than knowledge acquisition.” Indeed, Software development is a knowledge creating process. The mostbasic thing we do in our jobs is to discover what needs to be done in order to delight our customers. In fact, your product will benefit by finding ways to speed up this knowledge acquisition. Specifically, Lean provides two practices for this: short, frequent learning cycles and delayed commitment. Delayed commitment, postponing decisions until the last responsible moment, is covered in next month’s article. Today we’ll focus on shorting learning cycles.

So where does all this created knowledge reside? Large requirements and specification documents are enticing because they provide a wonderful illusion of certainty. They can be agreed upon in meetings, verified with checklists, cross referenced with traceability matrices, and then enforced by lawyers and courts when projects fail. Great software has as much to do with rock solid documentation as a great marriage has to do with a rock solid prenuptial agreement. No thanks, I say.

The software industry has clearly turned towards executable solutions for knowledge creation and retention, any plausible description for a marriage related “executable solution” leaves me feeling quite uneasy. Executable acceptance test frameworks abound: Fit, Fitnesse, and easyb, and new unit test frameworks appear every few weeks. The code you write, and the tests that accompany it are the most basic persistent form of system knowledge, and it is important that this knowledge be verified in an automated way.

The problem with traditional unit tests is that the test framework imposes so many particularities that the important knowledge of how your system must behave gets lost in a noise of subclassing, type definitions, and annotations. Wiki and spreadsheet based solutions like Fitnesse are a nice idea in theory, but I have not yet found customers willing to edit test data directly. Instead it is left to the developer to do it. To make traditional unit testing more friendly, some developers try to cut through this noise by using strange naming conventions and commenting their tests with standard comments, as in Listing 1.

public void test_users_can_be_retrieved() {
    // arrange
    ...
    // act
    ...
    // assert
    ...
}

I’ve found word separating underscores in method names to bring no real value. You’re going to have to press the shift key one way or another, whether it be with underscores or camel case. The practice I do like is the arrange-act-assert pattern. This pattern originated with William Wake as a way to add clarifying structure to unit tests. The idea is to codify and standardize the way tests are written: First arrange all necessary preconditions and inputs, then act on the object or method under test, and finally assert that the expected results have occurred. Tests are easier to read because the setup and verification phase is clearly separated from the block exercising the system under test, and test smells like a too busy act phase or missing assert blocks rise quickly to the surface.

Encoding your tests with comments is an interesting idea, but in the end comments are not executed, grow stale, and become misleading. A better choice than using comments is to pick a testing framework that eliminates all this noise, one that natively supports the structure of unit tests. A testing framework like Spock.

Spock is an innovative framework, taking new directions on fixture setup, mocking, and data driven tests. The goal of Spock is to allow the developer to focus solely on the input and output of tests and then get out of the way. One type of test available in Spock is the data driven test, seen in Listing 2.

def """does the user service contain
        a known set of users?"""() {
    setup:
        def service = new UserService()
    expect:
        def user = service.get(username)
        user.firstName == firstname
        user.lastName == lastname
        user.id == userID
    where:
        username << ['user1', 'user2', 'user3']
        firstname << ['John', 'Jane', 'John']
        lastname << ['Doe', 'Doe', 'Smith']
        userID << [123456, 654321, 789987]
}

Did you know that question marks and new line characters in methods names, like in Listing 2, are completely legal on the JVM? The Java language just doesn’t allow you to use them! While this is far from the main productivity boost from Spock, it does lead to some very nice looking JUnit reports. Figure 1 is our actual JUnit report from my current project. Seeing a space separated test name sure beats deciphering a camel case or underscore laden test name.

The value of Spock being built on top of JUnit should be obvious: your reports, builds, IDEs, and other tools continue to work as before. To the tools, Spock is just another unit test.

There are more interesting questions to ask about Listing 2, however. Reading the listing from top to bottom may be confusing. Are those “==” statements assertions, and how can they be made before the variables have been initialized? What does this test do exactly?

Spock shows the great power available behind Groovy. Those goto labels (setup, expect, and where) are some of the meaningful tags you are allowed to use within Spock, and these tags are enforced within the compiler. They are not goto labels at all but a vital part of a Spock test specification. Just as test fixtures can have setup and cleanup phases, so can individual test methods. Spock supports this idea natively at the compiler level. In-line comments and funny method names are replaced by first class support for testing.

Within the expect: phase, the statements including == are indeed assertions. You may write out the assert keyword longhand if you desire, but the point of an expect: block is to run assertions, so Spock lets you drop out this bit of ceremony from your tests.

Another surprising feature is that the expect block will be executed three times in this test: one time for each row in the dataset. So the first execution is with data user1, John, Doe, and 123456, the second execution receives the second “column” of the dataset and so on. Once you are used to Spock, the data tends to be read in vertical columns, since each column is input to the expect block. For testers weaned on JUnit the test might seem backwards, raising questions like “Why is the data the last piece of the test, shouldn’t that come first?” The short answer is, not if you want to create knowledge about your system. The important part of the system is how it behaves, how the UserService retrieves users. This information is front and center communicating to any future programmers on the project. The data that ensures this behavior comes later, and is usually less important than the assertions. The Arrange, Act, Assert pattern is required in imperative, sequential programming. Luckily, a strong language and an innovative framework let you focus more on knowledge creation than satisfying the semantics of your chosen compiler.

Data driven tests are just one of the options in Spock specifications. As you explore Spock you’ll find many of the BDD concepts available to use, as well as a unique solution to working effectively with mocking frameworks. Spock is built on JUnit, so it works without effort for popular build tools and IDEs, and the online documentation is superb (how often can you say that about an open source framework?). If you want to take tests as a form of knowledge creation, then Spock is definitely worth investigating.

The new 0.4 release of Spock contains another option for data driven tests as well: the data table. Previously, Listing 2 showed how lists can be used within Spock so that assertion blocks are automatically called several times with different data. The downside is that I sometimes find myself tilting my head as I try to read the vertical columns embedded in the lists. Similar to the data tables features in Scala’s Specs framework, Spock now allows you to embed pipe delimited data tables in your tests. Listing 3 is the same test as in Listing 2 but uses data tables instead of the Spock data
driven format.

def """does the user service contain
        a known set of users?"""() {
    setup:
        def service = new UserService()
    expect:
        def user = service.get(username)
        user.firstName == fname
        user.lastName == lname
        user.id == id
    where:
        username| fname | lname | id
        'user1' |'John' | 'Doe' | 123456
        'user2' | 'Jane'| 'Doe' | 654321
        'user3' |'John' | 'Smith'| 789987
}

The result is a much more readable dataset, neatly divided into rows and columns.

The test driven community has a great interest in improving the framework landscape. Unit tests have been heralded in the past as a way to capture information about the system being developed, but the JUnit and Java syntax combine to under-deliver on this promise. Finally, with both the Groovy language and frameworks like Spock, we are seeing unit tests come into their own in their ability to capture, express, and execute the workings of the system.

Sidebar: Expressive vs. Terse
I’ve been very careful to call Groovy expressive instead of terse, which are two different things. Terse means showing less. Terse can mean anything from an abstraction to an abbreviation. Court stenography or writing shorthand is terse. All of the information is captured, but in as small amount of space as possible. And practically no one except the original author can make sense of it. Perl and regular expressions are terse.

Expressive is also about showing less, but expressive specifically means showing less of the inconsequential and more of the consequential. If something is important, then an expressive language shows it to you. If something isn’t important, then an expressive language should hide that detail.

Being expressive is an important part of staying DRY (Do Not Repeat Yourself). Everyone knows that DRY mandates that you do not say things twice: there should be a single source of knowledge for any fact. Hiding information, and terseness, often violates this. An expressive language helps you stay DRY by making sure knowledge is embedded in the system once without a lot of extra noise. Simple terseness and hiding information might leave you with zero sources of knowledge! Not a good place to be. Strive for expressive, and be wary of terse.

Next Steps
An important part of creating knowledge is maintaining a culture of constant improvement: every team can benefit from a feedback cycle where you experiment with a new practice, reflect and learn from the experience, and then accept or reject the practice as part of your team culture. The annual, year end reviews common in many companies are the antithesis of this. They are self-improvement theater, where feedback comes months after events occur and the details of how to improve are lost behind closed door meetings, never to be heard from again. As an alternative, think short term. Treat each two week iteration as a chance to conduct an experiment. Try Spock for two weeks and then discuss the results as part of your iteration close. If the team doesn’t like it then stop using it and try easyb for two weeks.

If that doesn’t work then try something else. A two week commitment is much easier to sell to your teammates than a long term framework decision, and two weeks shouldn’t be long enough for even the worst decisions to irreparably harm a project. Week by week your team will improve as some of the experiments work and others fail. Just remember, an experiment or new practice should try to solve a specific problem for your team.

Next Month: Defer Commitment
Deferring commitment is about your keeping options open. It may seem wise to make decisions early, and it does lead to the illusion of progress. But decisions can be costly to unmake, and oftentimes new information will become available that affects the choices you’re willing to make. Next month’s article explores how Groovy and dynamic languages allow you to make decisions when you are ready, investigating ways in which you can use Groovy’s optional typing to your advantage.

Learn More
Spock is available through Maven and Google Code at http://code.google.com/p/spock/. The web has some nice Spock tutorials, the project lead has a blog at http://pniederw.wordpress.com/ and Parleys.com has a great 20 minute presentation from the 2009 Devoxx conference available to subscribers. For more information on the very cool mock objects available then you may wish to read my own post on the topic: http://canoo.com/blog/2010/04/20/spock-and-test-spies-a-logical-choice/ For books on agility, I still contend these three cannot be beat:

Implementing Lean Software Development – Poppendieck

The Pragmatic Programmer – Hunt and Thomas

Extreme Programming Explained, 2nd Edition – Beck and Anders

Don’t doubt it for a second: A paradigm-shifting idea is taking shape on Johnny Anonymous’s laptop as I write these words. Johnny’s idea is a radical as it is ingenious. It will change the way you communicate, work, think… breath. It may bring you that one love you’ve been longing for all your life; bring your kids opportunities and joy beyond their wildest dreams; resolve international crises; lead to cures for cancer; cut CO2 emissions in half; make quantum mechanics comprehensible to the lay-person; cause Dan Brown to write a decent book (okay, maybe not). Hell, it may even help us to make contact with aliens – how cool is that?!

Will Johnny’s idea ever see the light of day? As long as the Internet remains a level playing field, he/it has good a chance as any. Yet if the likes of Veroogle (Goozon?) have their way, then Mr. CEO will quash Johnny’s idea quicker than you can say the words “big fat severance package”.

Should Big Corporate really be permitted to dictate the accessibility and the quality of service that Johnny’s idea receives when he attempts to reveal it to the world? Let me put it this way: Can we trust corporations to govern themselves in such a way that they never,ever take active steps to diminish the chances of a potential competitor’s idea from taking hold? Don’t worry – it was a rhetorical question.

Is the world – virtual or otherwise – really so oblivious to the messy, awesome beauty that is the Egalitarian Internet; so apathetic that it will not lift a finger to rescue one of humankind’s finest achievements? Will the masses revolt? Furthermore, who will speak for us? Where are you Tim Berners-Lee?

So until the masses mobilize – and they surely must – here’s a tiny, yet powerful step that Joe Public – read: you – can take RIGHT THIS INSTANT: Bing.

Project Lombok is a very cool little Java library that aims (and succeeds) in removing boilerplate, meaningless, and uninteresting code from your Java objects. The basic idea is to replace things like getters and setters with simple annotations, and then let the Java compiler generate the necessary bytecode in the .class file so that tools such as Eclipse and the Java compiler have no idea what anything unusual happened. Lombok hooks into the compiler to make sure this happens correctly.

First we’ll cover some Lombok basics and then show how it can be used with the Canoo RIA Suite (ULC) project and and view generators. This includes details on how to mix Lombok annotated objects with JPA annotations, which you might want to glance at before leaving!

Update: You do not need ULC to work with Lombok. The two are separate projects.

Lombok in Action
So let’s see Lombok in action. Consider this Java class that includes a Lombok annotation:

import lombok.Data;

public @Data class Contact {
    private String name;
    private String email;
    private String primaryPhone;
}

OK, so there is an @Data annotation in there. So what? Well, to javac and tools (like Eclipse) this class has getters and setters for all three fields, an equals and hashcode implementation, and a toString method. Eclipse tools still give you autocomplete the Navigator shows the correct methods. Not only did you not have to write (or generate) the code yourself, but you don’t have to see that code when coming back in maintenance mode. The interesting bits of your class are no longer buried in the noise. Consider what this looks like without lombok:

public @Data class Contact {
    private String name;
    private String email;
    private String primaryPhone;

    public String getName() {
        return name;
    }
   
    void setName(String name) {
      this.name = name;
    }
    
    public String getEmail() {
        return email;
    }
   
    void setEmail(String email) {
      this.email = email;
    }

    public String getPrimaryPhone() {
        return primaryPhone;
    }
   
    void setPrimaryPhone(String primaryPhone) {
      this.primaryPhone = primaryPhone;
    }

    @Override public String toString() {
        return "Contact(" + name + ", " 
                + email + ", " 
                + primaryPhone + ")";
    }
     
    @Override public boolean equals(Object o) {
        if (o == this) return true;
        if (o == null) return false;
        if (o.getClass() != this.getClass()) return false;
        Contact other = (Contact) o;
        if (name == null 
                ? other.name != null 
                : !name.equals(other.name)) return false;
        if (email == null 
                ? other.email != null 
                : !email.equals(other.email)) return false;
        if (primaryPhone == null 
                ? other.primaryPhone != null 
                : !primaryPhone.equals(other.primaryPhone)) return false;
        return true;
    }
     
    @Override public int hashCode() {
        final int PRIME = 31;
        int result = 1;
        result = (result*PRIME) + (name == null 
                ? 0 
                : name.hashCode());
        result = (result*PRIME) + (email == null 
                ? 0 
                : email.hashCode());
        result = (result*PRIME) + (primaryPhone == null 
                ? 0 
                : primaryPhone.hashCode());
        return result;
    }

That’s a lot of code for something so simple. It doesn’t even fit in my browser margins without funky line breaks! Sure, IDEs can generate it for you. But what if something interesting is buried in the equals() method? Or perhaps a setter has a side-effect? You can’t easily see this with the reams of boilerplate typical of Java. With lombok, only the essentials are displayed, so the unique parts of the object will stand out to the future reader. And yes, even using @Data you are free to provide your own implementations for any of these methods.

Richard Gabriel made this observation when comparing old programs (like MacPaint) to “modern” programs writen in langauges like Java:

I’m always delighted by the light touch and stillness of early programming languages. Not much text; a lot gets done. Old programs read like quite conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who’d have guessed sophistication brought such noise.

Now, with Lombok, sophistication is finally taking the noise away, rather than adding to it.

Just a couple important details before moving on to a Lombok example that uses Canoo’s RIA Suite…

Lombok is compile time only. It does not need to be deployed with your app

Lombok works with javac and Eclipse. IntelliJ IDEA will not ’see’ the added methods

lombok.jar contains an installer that configures your eclipse.ini file correctly. Be sure to run “java -jar lombok.jar” after you download it (especially for those on 64 bit Linux like me)

Lombok with Canoo RIA Suite
The point of this was to make sure I could use Lombok on my next RIA Suite(aka ULC) project. It’s looks like I can, and you can too. To prove it, let’s generate a RIA Suite project, add a domain class using Lombok, generate the views, and run the application.

Prerequisites

Install Eclipse for Java EE Developers. Make sure that you have for Java EE developers.

Install Canoo RIA Suite. Get your download and evaluation key from our customer portal.

Install Lombok. Download it and run “java -jar lombok.jar”.

Steps
Here are the steps we’ll perform to get this thing working:

Generate a Project using ULC’s Project Generator in Eclipse

Add the lombok Jar to your project

Create a domain object called Contact and annotate it with @Data

Generate the views using ULC’s generate-beans-view in Eclipse

Run the app and behold a default, thin client, CRUD application

Generate the Project
The ULC Application Development Guide contains a 10 page getting started tutorial that walks you through the process from starting at zero and going to a deployed RIA Suite application. Really, it is quite simple. You just need to add the Project Generator as an external tool in Eclipse. Although it is a bunch of screenshots, this is a common task for Eclipse users and little can go wrong.

In Eclipse, click Run -> External Tools > Open External Tools Dialog… and point a new external tool to your “/addon/generators/build-setup.xml” from the RIA Suite install. Your window should look like this:

Now you’ll have the menu entry for Run -> External Tools -> ULC Project Generator, which you should click now. You’ll be prompted for a project name and whatnot, and a sample Contacts application will look like this:

The script runs and you now have a project on disk that can be run. Just click to File -> Import to import it, navigating to where it is on disk. Your import screen should look like this:

If it all goes well your project should be open and your Project Explorer should look like this:

Add the Lombok Jar
We need to add the lombok.jar to the Contacts project, add it to the build classpath, and click Refresh to make sure Eclipse is aware that something changed.

Copy the lombok.jar to ./Contacts/lib/development directory in your project. Then edit the project properties (right click the Contacts project and select Properties), select the Java Build Path entry, and add lombok.jar as a Jar. Should look like this:

Create Domain Object
Let’s add a domain object with JPA persistence to our project. A Contacts application must show a Contact, right? This looks about right:

package org.sample.contacts.domain;

import javax.persistence.*;
import lombok.*;

@Entity
public @Data class Contact {
    
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    @Getter(AccessLevel.NONE)
    @Setter(AccessLevel.NONE)
    private Long id;
    private String name;
    private String email;
    private String primaryPhone;
}

Let me explain a few details… The class is marked @Entity so that JPA persistence works. The class will map to a Contact table in the database. The class is marked @Data so that lombok will weave in getters, setters, toString, equals, and hashcode methods. The @Id annotation on the “id” field marks that field as the primary key to JPA, and the @GeneratedValue means the field auto increments. I use the GenerationType.SEQUENCE strategy because I plan on deploying to Google App Engine, otherwise this parameter here is unneeded. Lastly, getters and setters are supressed on the id field by adding @Getter(AccessLevel.NONE) and @Setter(AccessLevel.NONE). If you don’t do this then the view-layer automation of Ria Suite is going to, by default, provide you with edit fields for the id, which you should not do.

Generate the View Layer
To generate the view layer, click Run -> External Tools -> “Contacts generate-beans-view”. This tool was installed for you by the Project Generator. Running it generates a simple Create-Read-Update-Delete (CRUD) interface with a table, buttons, and entry editor. You’ll see a couple new classes and property files in your application after you run the tool.

Run application
Last thing to do is run the app. Click Run -> Run History -> Contacts (again installed by the project generator), sit back, and behold an application.

That’s it!

Next step is to deploy to Google App Engine using that Contacts-copy-to-GoogleApp tool that the generator installed, but that is a blog post (and task) for another day.

Enjoy!

By my count, Ubuntu Kung-Fu from Pragmatic Bookshelf is the perfect summer reading book. It’s light, the content is not going to strain your mind the way some computer science tomes will; it’s easy to read, as always with Prag books the writing is conversational and the fonts large; and it’s fun, where else can you read about easter eggs like talking cows and floating desktop fish.

Admittedly, some of the 315 tips are useless. I’m not sure when I’ll ever use the “cowsay” command to invoke a talking ascii cow, but for some reason I’m glad I know about it. I predict the error output in my Bash scripts is about to get a lot more bovine. Most of the tips are good, though. Of the 315 total tips (less than a page long each), there are maybe 25 dual boot and Windows related tips and maybe 25 more system recovery and troubleshooting tips. It isn’t a comprehensive reference to administration or dual booting, but these tips are still good to keep around in case of emergencies. Someone switching from Windows and still dual booting will find this book extremely helpful. There are also quite a few Gnome desktop tips for how to tune the desktop manager; for instance, how to use drapes to change the wallpaper every morning. But the majority of the book details cool and useful programs and packages to install… stuff I didn’t realize I needed until I found out about it. Normally I prefer printed books, but the best way to read Ubuntu Kung-Fu is by viewing the PDF directly on the computer and having a command prompt open to try the tips as you go.

If your vision of a great vacation is laying down with a laptop on your belly, banging away on new bash commands and scripts, then this is the book for you.

Now here are my favorite 10 tips.

1. Command History Search with Ctrl+R – In a terminal, the up and down arrow shuffles through recent commands on almost any operating system. I had been using grep to search my history (history | grep something) until I found out about Ctrl+R. When you type Ctrl+R, the terminal goes into a matching mode where it tries to guess the entry from your history based on what you type. So type the first few letters of a recent command and the entire thing comes up. This is great, and I use it regularly to expand out “git pu” into a full “git pull origin master”. But don’t get the wrong idea! I still think git is awful.

2. Running jobs with & and nohup – I discovered & long ago. If you run a program from the command line then the terminal is frozen until the program completes. But if you append & (for instance, “gedit &”) then it launches as a job and you can use the terminal again while your program runs simultaneously. The problem is if you close the terminal then your other program closes as well. Instead use nohup (”nohup gedit”) so that your program does not hang up when the terminal closes.

3. Use Trash for Command Line File Deletes – There are a bunch of safe alternatives to deleting files using “rm -rf”, and this type lists yet another one. However, I prefer to use the “trash” package. Just run:
sudo apt-get install trash-cli

4. gconf-edit – Desktop programs usually have a preferences panel, but not all preferences or settings are available there. The “gconf-edit” program in Gnome looks a little like a Registry Editor and is where all Free Desktop programs must store their configuration settings. Even if it is not in the preferences window you can still access it through gconf-edit. Take a look at what is available for Nautilus and gedit. It should be quite easy to expand your gedit recent files list to be 10 entries long, for example.

5. Command Line Image Manipulation - There are a whole bunch of command line and batch image tricks you can perform with “imagemagick”. Shrink and enlarge in batch using “convert -resize 50% filename.bmp”, convert formats using “convert -quality 80 filename.bmp filename.jpg”, and sharpen images using “convert -sharpen 0×1 filename.bmp”. Of course, for ascii aficionados like me, there is no beating asciiview. Install these:

sudo apt-get install imagemagick
sudo apt-get install asciiview

6. Fonts Galore – I agree, Ubuntu fonts just look better, but the author is a little obsessive including 5 different font tips. You can “Make Fonts look superb” by turning on autohinting using a somewhat lengthy process. Or you can just install a whole slew of fonts such as the 465 fonts in ttf-aenigma, the Microsoft imitation fonts in ttf-liberation, or the Comic Sans style fonts in the ttf-fifthhorseman-dkg-handwriting, ttf-sjfonts, and ttf-breip packages. There’s even directions on stealing the Mac or Windows fonts by mounting the alternative OS, copying all the .ttf files locally, and then installing them into Ubuntu. This is probably the only tip that is not 100% legal. Install these:

sudo apt-get install ttf-aenigma
sudo apt-get install ttf-liberation
sudo apt-get install ttf-fifthhorseman-dkg-handwriting
sudo apt-get install ttf-sjfonts
sudo apt-get install ttf-breip

7. Command Line Web Browser – I don’t know why but I get a real kick out of the “links” command line web browser. I enjoy the absurdities in life and browsing a text online web from the console seems like one of them. Install it with:
sudo apt-get install links

8. Install all the multimedia codecs you’ll ever need – My family’s favorite baby sitter is the DVD player. When a parent needs a break, there is no joy like popping in a princess or dinosaur movie and seeing a child fall quickly into an animation induced stupor. Peace and quiet at last! Except when the DVD doesn’t play because of missing codecs. Curse you copyright laws! Best to be prepared and just install all of these through Synaptic now:
GStreamer extra plugins
GStreamer ffmpeg video plugin
Ubuntu restricted extras
GStreamer plugins for mms, wavpack, quicktime, musepack
GStreamer plugins for aac, xvid, mpeg2, faad
GStreamer fluendo MPEG2 demuxing plugi
Finally, be sure to run the DVD playback enabler script: sudo /usr/share/doc/libdvdread3/install-css.sh

9. See a Quote of the Day Whenever You Log In – I love quotes, so seeing a new one at the top of all my Terminal windows is a real bonus. Just install signify, create a ~/.signify file, and then edit your ~/.bashrc so that the last line reads “signify”. The format for the .signify file is % { quote % | quote % | quote % }. Yes, you read correctly, that is a “% |” delimited list with a “% {” start identifier and a “% }” end identifier, which makes the .signify file qualify as the most ridiculous text file data format I have ever seen. Oh well, just install:
sudo apt-get signify

10. Play Old MS-DOS Games. Hell yes, Bard’s Tale is about to be run! First install “dosbox” and create an empty directory on your disk called “dosbox_c”. Then, using the DOSBox user interface, mount your empty directory by typing “mount C dosbox_c” and then switch to it by typing “C:”. You are now at the DOS prompt. Browse on over to your favorite abandon ware site and start downloading the classics. I suggest raiding http://www.abandonia.com. Install with:
sudo apt-get install dosbox

So that is my best 10. All I have left to say is:

 ____________________________
< I want a Bash Kung-Fu book >
 ----------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Big Griffon news today.

First, the Griffon Refcard is available from DZone. This is a concise 6-page reference to getting started and working with Griffon. If the only thing you know about Griffon is that it is a Grails and Groovy based framework for building desktop applications, then this RefCard will fill you in with tons more details. And if you’re an old Griffon hack, then you’ll probably still pick up some new tips and tricks.

Plus, DZone published an interview with Canooie Andres Almiray, the Griffon project lead. You can read the interview here, or click the RefCard below to download the card.

Anyone interested in Griffon in the Swiss area should come out to Hackergarten on the 30th of July. Several experienced Griffon developers will be present including Andres. And there is free pizza!