Articles Feed

JRuby Installer Samples

by: micah | July 21st, 2009 | 1 comments »

The JRuby dev team is interested in distributing friendly installers for future released of JRuby. The installer will take care of unpacking files, setting environment variables, and even installing Java is need be. Sweet huh?

Having worked with Install4J on Limelight, I proposed using it for JRuby. The good folks at ej-technologies were kind enough to donate a license so I whipped up some installers. But there are a few options to consider and we want to choose the option that offers the best experience.

Below are links to sample JRuby installers for Windows (built on my mac) using Install4J. If you’re willing, try out an installer and let us know what you think.

• JRuby Installer for Windows, NO Java (11.9 MB)
• JRuby Installer for Windows, WITH Java (27.8 MB)

Disclaimer: Use at your own risk.

Bowling in Clojure

by: micah | July 20th, 2009 | 2 comments »

I’ve been long overdue to learn a new programming language and Clojure recently caught my eye. Clojure attracted my attention because it seemed like a rich Lisp dialect where I could learn all the goodness of functional programming, and it runs on the JVM allowing me to make use of all hte Java goodness out there.

Along with a couple colleagues at 8th Light, I read Halloway’s Book. We then challenged each other to write the bowling game in Clojure so we could compare our solutions. Coincidentally, my father, Unclebob, performed the same exercise independently. Below is my solution.

First comes the tests:

1. (ns micah.test.bowling (:use micah.bowling clojure.contrib.test-is))
3. (deftest test-gutter-game
4. (is (= 0 (score (repeat 20 0)))))
6. (deftest test-one-pin-wonder
7. (is (= 20 (score (repeat 20 1)))))
9. (deftest test-one-spare
10. (is (= 20 (score (concat (list 5 5 5) (repeat 17 0))))))
12. (deftest test-one-strike
13. (is (= 30 (score (cons 10 (repeat 18 1))))))
15. (deftest test-perfect-game
16. (is (= 300 (score (repeat 12 10)))))
18. (deftest test-all-spares
19. (is (= 150 (score (repeat 21 5)))))
21. (deftest test-heart-breaker
22. (is (= 299 (score (concat (repeat 11 10) (list 9))))))
24. (run-tests)

And the production code:

1. (ns micah.bowling (:use clojure.contrib.seq-utils))
3. (defn score [rolls]
4. (loop [score 0 rolls (vec rolls) frame 1]
5. (if (> frame 10)
6. score
7. (cond
8. (= 10 (rolls 0))
9. (recur (+ score 10 (rolls 1) (rolls 2)) (subvec rolls 1) (inc frame))
10. (= 10 (+ (rolls 0) (rolls 1)))
11. (recur (+ score 10 (rolls 2)) (subvec rolls 2) (inc frame))
12. :else
13. (recur (+ score (rolls 0) (rolls 1)) (subvec rolls 2) (inc frame))))))

Thoughts

As with learing any new language, writing this first program was frustrating. Getting the environment running took a while and simple tasks, like creating a list of 20 zeros, required several minutes of research. Nonetheless, I was very pleased when it was complete.

I was quite impressed with size of the program. Compared to previous Java solutions I’ve written, this Clojure solution is about 20% the size. That’s a huge size reduction. But as I compare the solutions more, it occurrs to me that the Clojure solution is also about 20% as readable. Just look at it! You could get lost in that cond statement for eons.

Now my craftsmanship spirit was nagging me all the while I was coding, just begging me to refactor. However, I struggled to find good ways to improve the code. All my typical tricks, extract variable, extract method, didn’t feel right. My hope is that I’ll acquire new tricks to refactor in Clojure from experienced Clojure programmers, perhaps like you. Please let me know if you see a way to improve my code.

Reasons to Attend SCNA

by: paul | July 17th, 2009 | 1 comments »

SCNA website

1 - “The list of SCNA presenters reads like Who’s Who of Software Jedi Knighthood” -- Ray Hightower

This is a complete testament to how willing and excited the thought leaders and software masters were to speak at this conference. The creme of the crop in software mastery will be talking about how to raise the bar in our industry. I have never seen a lineup of speakers who put me in such a state of awe since the early XP Universe days. Thanks to all of them for getting together for this conference.

2 - Join software craftsmanship over crap.

Last year Uncle Bob challenged software developers to become professionals. We have spent a year of summits, manifestos, meet ups, and conferences trying to figure out how to move forward towards professionalism with this paradigm of software craftsmanship. The momentum of craftsmanship is only growing.

3 - Software craftsmen all in one room.

The google map of software craftsman who have signed the software craftsmanship manifesto has proven this to be a global community of software developers. It is unique that we have people flying in from multiple continents to participate. I am excited to meet face to face with all these craftsmen whom I know only their ideas and email addresses.

4 - Richard Sennett

A sociologist who wrote The Craftsman, Dr. Sennett has provided a template for studying the habits and techniques of craftsmanship. He touches on everything from extending your concentration to why we choose vocations so passionately. It is a true authority on craftsmanship.

Up and running with TDD on Android

by: colin | July 11th, 2009 | 2 comments »

A couple of weeks ago, I happened to be in the right place at the right time (the first ORD Session) when Google hooked a bunch of developers up with an Android Dev Phone 1. I'd been interested in Android for awhile because it's a more open platform than the iPhone, and the code is Java (I've never worked in Objective-C), so I was excited. After my initial excitement of hacking around and getting things to work, I decided to regain my discipline and figure out a workflow for TDD. The good news is that JUnit is built right into the Java framework that Android app have available. The less-good news is that writing and running tests on Android isn't as well-documented as many other facets of the application framework. I'd like to share my setup, which doesn't depend on any specific IDE or text editor. I'm assuming Mac or Linux here, but I'm sure Windows would only require minimal changes. Other assumptions:

• The Android SDK is installed
• Android tools directory is on the PATH
• Ant is on the machine and on the PATH

Note: the "tools" directory is the main one, not the one below "platforms" - in my case: '/Users/colin/lib/android/tools' Let's get started by creating a project with the command-line utility, which will give you the test directory structure and build files that you need (you won't get these with the Eclipse or IntelliJ plugins, for instance). Of course, you can read documentation for the android command to see more details, but here's what we're doing:

1. $ android create project -t 1 -p tictactoe-android -a TicTacToe -k com.colinwjones
2. $ cd tictactoe-android

All of these options are required (-n, the project name, is optional, and I've left it out above)

• -t is the build target platform (1 refers to Android version1.1 on my machine, see the ids in $ android list targets for yours - this is important to remember as you'll need to refer to it later)
• -p is the path of the new project to create (make up a folder name for your new project
• -a is the first Activity that you want to create
• -k is your package name

Next, we want to create an AVD (Android Virtual Device) if one doesn't already exist - it's an emulator for the phone operating system. We can check to see if one exists already first:

1. $ android list avd

If you don't have an AVD already, create one:

1. $ android create avd -n ColinPhone -t 1

You'll be asked if you want a custom hardware profile (I don't, so I just hit Return).

• -n is the name of the new device
• -t is the target platform, as before (and it should match your project's platform)

At this point, let's go ahead and fire up the emulator, making sure to match the name to the one you created. It's good to make sure that our state at this early point is a good one.

1. $ emulator -avd ColinPhone &

Here I'm launching the emulator (AVD) in the background so I don't need to open up a new Terminal window. You'll get some output in your terminal window; if it bothers you, Ctrl-L will freshen it up. Now we'll build and install both of your apps (the test package is really a separate application, which is a good idea to keep the tests out of the eventual deployment package anyway).

1. $ ant debug
2. $ adb install -r bin/TicTacToe-debug.apk
3. $ cd tests
4. $ ant debug
5. $ adb install -r bin/TicTacToe-debug.apk

The debug target isn't actually defined in either buildfile (build.xml or tests/build.xml), but is available nonetheless (see $ ant help for other targets you might not otherwise find). This takes care of bundling resources, compiling, converting classfiles to Android's .dex format, and packaging. Note that adb is NOT ant - it's the Android Debug Bridge, and it's invaluable for working with the emulator. The -r option to adb install reinstalls the package if necessary. Now, this is pretty redundant-looking, but just remember that the tests directory is a sort of parallel structure with your project directory, and you need both. It's time to run the default test suite that the android create project call has given us (this can be run either from tests directory or from the root of the project):

1. $ adb shell am instrument -w com.colinwjones.tests/android.test.InstrumentationTestRunner

Of course, you'll want to substitute your package and activity names for the ones in my examples. It's very important to realize that you've just compiled and installed your software on the emulator and are running tests on it there. In order to do TDD, you'll need to recompile changed code and reinstall on the emulator. I hope that one day there will be a way to avoid going through the emulator each time (or that there already is one that I've been unable to find), but this is the only method I've been able to get working so far. Now we need to actually add a real test to (in my case) tests/src/com/colinwjones/TicTacToeTest.java. Here, an IDE like IntelliJ or Eclipse comes in handy, especially if you're just starting with Android and aren't sure of the methods you might want to use.

1. // with imports at top:
2. import import android.widget.Button;
3. /* some code
4. * ...
5. * ...
6. */
7. // inside your test class:
8. public void testNewGameButtonExists() throws InterruptedException
9. {
10. Button button = (Button) getActivity().findViewById(R.id.new_button);
11. assertEquals("New Game", button.getText());
12. }

Building our test package at this point will fail, since no resource with the new_button id exists yet. Let's do it anyway to see the first failure and guide us to our implementation code (running this from the tests directory):

1. $ ant debug

The error tells us where to go next: we'll implement the button in /layout/main.xml (making sure to set the right ID on the button). Since we changed the main layout, the implementation package needs to be built first, then the test package:

1. $ cd ..
2. $ ant debug && adb install -r bin/TicTacToe-debug.apk
3. $ cd tests
4. $ ant debug && adb install -r bin/TicTacToe-debug.apk

Now run the tests again:

1. $ adb shell am instrument -w com.colinwjones.tests/android.test.InstrumentationTestRunner

Great! Now we have a proper failure:

1. com.colinwjones.TicTacToeTest:
2. Failure in testNewGameButtonExists:
3. junit.framework.AssertionFailedError: expected:<new game> but was:<>

We just need to add the right text in the XML layout: Let's rid of the default "Hello, World" TextView in main.xml while we're at it. Now rebuild, reinstall, and re-run tests

1. $ cd ..
2. $ ant debug && adb install -r bin/TicTacToe-debug.apk
3. $ cd tests
4. $ ant debug && adb install -r bin/TicTacToe-debug.apk
5. $ adb shell am instrument -w com.colinwjones.tests/android.test.InstrumentationTestRunner

This is getting annoying typing all these commands: we're going to want to write a shell script or Ant task to do this for us. But for the time being, we'll plod through (that was the last time, though). Now we're passing:

1. Test results for InstrumentationTestRunner=..
2. Time: 1.009
3. OK (2 tests)

It's a bit strange that the test runner claims we have 2 tests: each test class will add one of its own. Now that we've seen how to get the tests running, let's automate it by adding Ant tasks to the build.xml in the main project directory. You'll need to set the environment variable ANDROID_TOOLS for this exact task to work, or you can provide the full path to adb.

1. <target name="clean">
2. <delete includeemptydirs="true">
3. <fileset dir="bin" includes="**/*" />
4. <fileset dir="tests/bin" includes="**/*" />
5. </delete>
6. </target>
7. <target depends="clean, debug" name="test">
8. <property environment="env" />
9. <property name="android-tools" value="${env.ANDROID_TOOLS}" />
10. <ant dir="tests" antfile="build.xml" inheritall="false" target="debug" />
11. <exec executable="${android-tools}/adb" failonerror="true">
12. <arg line="install -r bin/TicTacToe-debug.apk" />
13. </exec>
14. <exec executable="${android-tools}/adb" failonerror="true">
15. <arg line="install -r tests/bin/TicTacToe-debug.apk" />
16. </exec>
17. <exec executable="${android-tools}/adb">
18. <arg line="shell am instrument" />
19. <arg value="-w" />
20. <arg line="com.colinwjones.tests/android.test.InstrumentationTestRunner" />
21. </exec>
22. </target>

Now we can just run

1. $ ant test

from the project directory (assuming the emulator is already up and running with $ emulator -avd ColinPhone &), and we'll be good to go. Honestly, it's a pretty simple process: the key for me was in using the Android command-line tools rather than IDE plugins. It helped me to understand the build process and get beyond the initial frustration of not having the IDE do the work for me. I imagine things will change a bit for Windows users, so please leave comments if there's anything drastically different (and also if things change for Mac/Linux users as the framework develops). I do hope this will help someone else to get set up and save the headache I had when first discovering Android.

Announcing chiPhone

by: eric | July 9th, 2009 | 0 comments »

It’s with great pleasure that I announce the creation of chiPhone, the Chicago iPhone developer’s group, with our first meeting on July 23rd at 6:30. The fourth Thursday of every month should feature interesting presentations, hackfests, and everything else you’d expect from a quality developer group.

The group website is now up and running at www.chiphonegroup.org where you can register there to attend the first meetup. In addition you’ll find directions to the 8th Light offices, where most of our meetings will take place, and the announcement of the topic for the next meeting. As the official site website all further information will be posted there, including video recording of the talks.

The first meeting will feature a presentation by “the Eric’s” on Test Driven Development for the iPhone. We’ll be starting with the basics of setup and work all the way through Dependency Injection using Interface Builder. Bring your Macs so you can grab our github project for experimenting. Get to the 8th Light offices early for pizza and refreshments.

8th Light is located just off of Route 45 in Libertyville, and detailed directions are available on the chiPhone website. In addition we are near the Libertyville train station, just email me if you need to arrange to be picked up.

I’m looking forward to a lot of great meetups, and I’ll be asking you to provide some topics in the near future.

#####