Java, Eclipse, and Maven altogether

I’ve never really spent time with Java. My experience with the language was limited to examining Java code in books on design patterns. I am now taking a class at Johns Hopkins University that uses Java, so it was time for me to learn how to work with the language. This post describes my initial experience with the Java environment and points a new user to some good tools that are used by “enterprise” Java developers.

My employer produces a lot of Java code for its customers. I have many co-workers who use Java regularly, and, in my conversations with them, I’ve heard of some popular tools that make Java development easier. The two primary tools seem to be Eclipse [1], an Integrated Development Environment (IDE), and Maven [2], a project management/build tool. Also, M2Eclipse [3], which integrates Maven and Eclipse, comes highly recommended by my peers.

With these tools, I set up a “Hello World!” application on Ubuntu 9.10. Some of the steps turned out to be easy, while others were surprisingly annoying and tedious. Hopefully, this post can help a new Java developer avoid those stumbling blocks.

First, install Eclipse and Maven: `sudo apt-get install eclipse maven2`.

Second, install the M2Eclipse plugin. The free M2Eclipse PDF book gives instructions about how to install the plugin from inside Eclipse’s software manager. One gotcha that I ran into was needing a JDK (Java Development Kit) for Eclipse to use when installing M2Eclipse. Ultimately, I just needed to install openjdk (`sudo apt-get install openjdk-6-jdk`). Eclipse switched to the JDK because the act of installing openjdk changed the symlink that /usr/bin/java pointed to. To check which Java is being used, execute `sudo update-alternatives –config java` (note: that’s two dashes before config).

Once the JDK is installed, use the Eclipse software manager under “Help -> Install New Software…” to install the dependencies listed in the M2Eclipse book. This stage was pretty annoying because Eclipse can’t resolve dependencies, but it had to be done.

Next, create a project within Eclipse using Maven. To do this, select “File -> New -> Project…” and go to the new Maven section. Select “Maven Project” and move through the wizard until Maven asks about archetypes. What are archetypes? Archetypes are basically project templates with certain conventions for consistency in Maven projects. Select the archetype with ArtifactId ‘maven-archetype-quickstart’ to create a basic project.

Now right click the package in the Package tree, and select a Maven action (a.k.a. goal) from the “Run As” menu. “Maven package” will create a jar in the target directory. However, if you try to run that with `java -jar <your-jar-name-here>`, it will fail because the jar can’t find the main() method. To fix that problem, follow Jean François’ instructions [4] (look for the section about build plugins).

This was a condensed walk-through for making a project in Eclipse with Maven. Virtually everything listed here can be found in the documentation listed at each tool’s respective site. If you have questions, leave a comment and I’ll try my best to answer. The benefits of using Maven and Eclipse are numerous, but suffices to say it should now be possible to handle Java dependencies well in a robust IDE.

1. http://www.eclipse.org/
2. http://maven.apache.org/
3. http://m2eclipse.sonatype.org/
4. http://jean-francois.im/2008/02/why-maven-2-rocks.html

Pretty Perl and maintainability

I have a soft spot in my heart for Perl. It was the first language that I made any serious use of as a professional software developer. I’ve learned a lot from Perl and about Perl, and I know that the language has a reputation for being ugly. So how does a developer transform an “ugly” language into something special and possibly even “pretty?”

In the Perl community, the proposed question might be met with reactions of “TIMTOWTDI!” (pronounced “Tim Toady” and representing the very long acronym of “There is more than one way to do it!”) After all, they might say, what is “pretty” code? To me, pretty code is code that is maintainable, robust, and fast, probably in that order of preference. I think that there exists a book about Perl that illustrates how to write pretty code (per my definition) and here are my thoughts about it:

Last week I finished reading a book written by a well respected individual in the Perl community. Like Douglas Crockford with the JavaScript language (whom I mentioned in my previous post), this author is someone who has had a presence in Perl and really knows his stuff because of years of experience. The book is Perl Best Practices and the author is Damian Conway. Unlike Crockford’s JavaScript: The Good Parts, Conway’s book is much larger and spans more than three times the number of pages of Crockford’s 153 page book. Damian uses that space quite effectively and provides some great insight into how to write better Perl code.

Perl Best Practices is not a book for fledgling Perl developers. If you’re learning Perl syntax for the first time, look elsewhere (e.g. Programming Perl or Perl in a Nutshell), however, be sure to come back quickly to this book! The real strength I see in Perl Best Practices is the overarching guidance about how to craft Perl code into something maintainable by people. For code to be effective, it cannot exist in a vacuum. The best code is used and read and maintained by many people. Conway’s book explains some critical concepts to write rich code, but he writes it in a way that emphasizes how to make the code safe in the future and update-able to others. After reading Perl Best Practices, I feel better equipped  to write Perl code that other developers would value. I would love for those hypothetical developers to look at my future work and say “Oooo… that’s pretty!”

JavaScript has “Good Parts”!? Yes, it does.

I used to loathe JavaScript. It was a language that looked ugly, had no obvious structure, and seemed like a toy that web developers would use. Then I read “JavaScript: The Good Parts” by Douglas Crockford and my viewpoint changed for the better. I’ve now seen that JavaScript can still be the hopeless mess that I just described, but it can also be something “beautiful” if done with care.

Crockford is the JavaScript architect over at Yahoo! and he is a man who clearly knows his stuff. Over the span of 153 pages, he explains many of the finer points of the popular web language. His book is quick to illustrate that there are some very bad parts in JavaScript, and he is not afraid to call out “mistakes” in the design of the language. I found this honesty to be very refreshing. I’ve read numerous language books that will want to highlight every feature of a programming language, but not point out which parts were a bad idea. Instead, those books will let you discover yourself, on your own projects, what are bad ideas and what are good ideas. To admit that a language has problems and point out features that should absolutely not be used is great. It means that I get to learn less to be more productive and, in this case, benefit from the wisdom and experience of someone who has been working with JavaScript for years.

Overall, the book is excellent. It’s definitely not light reading and if you choose to read it, it will require your careful attention to grasp the subtle points. However, the time spent trying to understand the material will be a boon to any serious web developer who has to write more than a few lines of JavaScript. And since so much of the web uses JavaScript to create dynamic pages, I think all web developers should know this stuff.

Entertainer 0.4 is released!

I just announced it officially on the team’s Launchpad page, but Entertainer 0.4 is out. Check out the installation instructions on the wiki for the play by play of how to get things going.

Thanks to all the other developers who help make Entertainer possible. You guys rock.

Perl Testing: A Developer’s Notebook

I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not focus on unit testing, but, equipped with the things that I learned from this book, I am now even more adamant that I will be creating unit tests for all of my future Perl code.

Unlike Python’s core testing library, unittest, which is focused on objects and test methods, Perl’s core testing libraries, Test::Simple and Test::More, are focused on procedural style testing. As a consequence of being procedural, Perl test code has a style that reads very differently from a Python test case, and it is this style that was so eye opening about the Perl Testing book. The style difference isn’t a bad thing, it just requires some mental adjustment shifting.

Perl Testing is written in a no-nonsense manner that jumps straight to a solution for how to solve some hard problems when testing Perl. Personally, I think that the book’s style makes the material such a useful resource when considering how to test a problem. The Perl community likes to say TIMTOWTDI, which means “There is more than one way to do it,” but sometimes there are too many ways to do something. Langworth and chromatic provide lots of solid examples of how to test things so that you, as a future Perl test code author, will not have to recreate the logic necessary to test some really challenging code.

The book isn’t perfect, but the overall quality of the material, and the incredibly helpful libraries that it introduces, makes Perl Testing: A Developer’s Notebook a valuable resource for any Perl developer who wants to test his code (which should be every Perl developer).

Installing Entertainer 0.3

My previous post on installing Entertainer proved to be quite popular. Since quite a bit has changed in Entertainer between 0.1 and 0.3, I’ve decided it would be worth writing the instructions again to prevent confusion. However, for the benefit of people who never see my blog but will visit Entertainer’s Lauchpad page, I have decided to provide the instructions as a FAQ in the team’s Answers section.

Please visit the FAQ for how to install Entertainer 0.3. My apologies for the redirection, but it is for the benefit of many.

Into the Rabbit Hole

This should be educational:

matt@eden:~$ sudo apt-get install perl-doc

matt@eden:~$ perldoc perl

(and all associated sub-parts).

Then maybe I’ll start hunting around on the CPAN for modules or at least figure out which Perl modules Ubuntu bundles by default.

(Possible alternate title: Becoming a Better Perl Developer)

On Translations

What!? I have a blog!? I guess I should say something.

I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact).

In the last Entertainer release (0.2), Joshua Scotton did the trailblazing work of adding gettext support to Entertainer. Gettext is a very common method of making an application translatable. For every string that a user sees in the interface, we wrap that string with the _() method in the code. For example, we might have a line that says:

print _(“Hello”)

Entertainer developers could then run a series of commands that will tell gettext to look for the _() method and extract the contents of all method instances it finds into a file called a po template (pot file for short). We upload this pot file to Launchpad translations, which enables our translators to translate the language into their native tongue.

Launchpad lets translators work through a web interface to see a string from the code so they can provide the translation. Optionally, Launchpad will let a translator download the file that contains the mapping from the reference language to the destination language. This file is called a po file. Once the translator updates the po file, they can upload it back to update the translations in Launchpad.

Josh did a great job adding this initial support for translations, but unfortunately, the team dropped the ball on keeping them up-to-date. Since code continues to change, one can deduce that the strings that a user will see will also change over time. Some strings are deleted. Some strings have wording changes. Other strings are added. For technical reasons not worth enumerating, the developers lacked a super simple way to generate a new pot file and upload that file to launchpad to keep the translators in sync with what is happening in the trunk. Because it was non-trivial to update the pot file, our pot file was out of sync with the code for four months. Four months! On a project that is changing as rapidly as Entertainer, that is a very long time.

My recent translation work provides the simple solution that the developers needed. Now, by simply typing `make translations` in a bzr branch of Entertainer, a new pot file will be generated for a developer to upload to Launchpad. With this change, the development team will be much better equipped to provide steady updates to the translators.

If you’re interested in translating for Entertainer, jump over to our Launchpad translations and give us a hand in making Entertainer useful for whatever language you speak. It’s a great way to contribute, especially if coding is not your thing.

Coming Soon, Entertainer 0.2

Yeah, yeah, we missed our milestone deadline of 9-26-08, but we’re close to getting 0.2 finished.

For those of you looking for a lot of new flashiness and cool user interface features, I’m afraid 0.2 won’t have a ton to offer. With some contributions from new developers, we have added some features like a photo slideshow capability and a quit screen.

Most of our core developers, however, have been focusing on a lot of code refactoring under the hood. In the long term this refactoring will enable us to get features done more quickly and in a testable way, so we can verify everything we code. About 95% of my work for this release probably falls into this category, so I’m afraid I can’t really boast about anything visible that I’ve done this time around. I did fix some text jaggies on some of the menus (*yawn*, boring, I know).

Before you go away sulking from the lack of new bling, take heart at some of the cool things that we have done:

• Thanks to Josh and the efforts of some other contributors, Entertainer has support for language translations! I, unfortunately, am a bum American who can only speak English (and a bit of very broken Spanish), but many other people will be able to enjoy Entertainer in their native language. Our translation page indicates that we have 100% translation of English, French, German, and Swedish. We also have partials translations in plenty of others. That rocks! I’m sure we’ll have to start focusing on translation quality in the future since there are no restrictions on who can translate, but, hey, it’s a pretty good start.
• Paul is dangerously close to getting a package put together. This is great news for users because it will mean that you can install Entertainer from a package in one of launchpad’s Personal Package Archives (PPA). For Ubuntu/Debian users, this will mean no more need to download the source code and run Entertainer directly from source. For non-Ubuntu/Debian users, we have will have a source package that can be used for your distro packaging (anybody willing to step up to the plate?). I think we’ll have a lot of polishing to do, but I am pumped about this because it should open the doors for a lot of users who were scared of running Entertainer from our source tree.

I’m going to cross my fingers and hope that we release 0.2 this weekend (the 4th and 5th). Keep your eyes on this space or over at our launchpad page for official announcements. I’ll also write a post about how to install 0.2 later which will hopefully include instructions about how to install from a PPA.

Installing Entertainer 0.1

Edit: These instructions are really dated and 0.1 is not supported any more. If you came here looking for information on installing Entertainer, please check Installing Entertainer 0.3 or visit Entertainer’s Launchpad site.

Only two bugs that we (the Entertainer developers) targeted for our 0.1 milestone missed the release deadline. Unfortunately, both of these missed bugs (Bug 232365 ‘provide a PPA respository for hardy’ and Bug 236271 ‘Need a simple pdf guide for new users’) have fairly big consequences for people who are trying to get Entertainer up and running for the first time.

Since the whole reason we released early was to get some good testers and users, this is a notable failing on our part. Sorry. We don’t want to leave anyone out, so here are some basic steps to get started.

1. Get all the required dependencies (these are supporting code libraries that help make Entertainer work). You can use the list at our old Google Code page. Please ask us on IRC (irc.freenode.net #entertainer) if you seem to be missing something. This problem will be rectified when we have a package that users can install (so that the dependencies will automatically be grabbed).

2. Get the release and extract the compressed file. You can use graphical tools (e.g., right click the file in Ubuntu and select Extract) or practice your command line foo (e.g., `matt@zion:~/Desktop/$ tar -xvzf entertainer-0.1.tar.gz`)

3. Point to your media with the content management tool. In a terminal window, from within the src directory of the release that you just extracted, execute `./entertainer-content-management.py`.

4. Start the backend, which will index all your selected media directories, from within the src directory by executing `./entertainer-backend.py`.

5. Start the frontend (the whole reason you went through these instructions) by executing `./entertainer-frontend.py`.

6. Report bugs on our Launchpad site (help us make Entertainer better!).

I hope these instructions will help you enjoy Entertainer.