Tuesday, December 31, 2013

Jewel's Audio Memory Game


An old friend of mine, Vic Douse, has a daughter, Jewel. She loves Disney, balloons, and some video games/apps. She has autism.

Vic is an Oracle DBA during the day, but at night, he has been very active in the autism community on PEI, serving as president of the Autism Society for years. (He won a Queen's Diamond Jubilee medal for his contributions).

Last winter, he started tinkering around with an Android app, despite not coding for years. The result is a simple memory/match game. The UX is... basic. But that's not the point: the point is that Jewel likes to play it. It helps her with her vocabulary.

So, check out Jewel's Audio Memory Game on the Play Store. It's free with no ads. Vic is delighted with each download, so give it a go. It's actually fun in a nostalgic way. My personal best for the 4x4 grid is 36 seconds, no doubt based on lucky strikes.

Wednesday, December 18, 2013

I Just Want A Foothold Example In.... Ruby


I've participated in a few paired coding sessions this year (such as Legacy Code Retreat and Global Day of Coderetreat), and I've experienced the pain of setting up an environment for a new language. It's not necessarily rocket surgery, but for a newbie, it's brutal.

Recently, I've been interested in trying out Ruby (I've always reached for either Groovy or Python first, but after meeting many, many sharp peeps who use it, it's time). To get started, I looked around on the web, but examples seem to jump from code snippets to full frameworks with little in between.

What I really want (for all languages) is a foothold: a simple project that has the usual aspects (code organization, unit-tests, automated build) laid out in an idiomatic way.

In case it helps anyone, I've posted my attempt at a foothold: War-O in Ruby, as a contribution to PEI Devs. It's a work-in-progress, and I'm still a newbie, so feedback is welcome.

Saturday, October 5, 2013

Legacy Code Retreat


Having been home now for 3+ years, away from an urban center, I've been considering a post on what I've learned (good and bad) over that time, as it pertains to crafting software.

This is not that post. However, the following event certainly falls in the good column.

Summerside, Prince Edward Island, punches well above its weight-class when it comes to software. Both Steven R. Baker and J.B. (Joe) Rainsberger hang their hats there, and along with the PEI Developers group, are transforming the tech vibe here on the Island.

As one example, Joe recently facilitated a Legacy Code Retreat (LCR) at the spiffy Holman Centre (no doubt arranged via srbaker). Opportunities like this don't happen often on PEI (though, actually, they are becoming more frequent).

In brief, we paired in five 45-minute sessions with a code base that is brilliantly, wonderfully awful. We practiced specific "rescue and improvement" techniques in a variety of languages.

Here are some quick thoughts on my experience.

What is Legacy Code?

We didn't spend a lot of time on this, but my favourite definition is attributed to Michael Feathers: legacy code is code without tests. I love it.

If you're in a gig that doesn't embrace testing (and with slack-jawed amazement, I've discovered how prevalent that is), adopt this definition. If it doesn't have tests, start referring to the code you wrote yesterday as legacy. It will get attention.

Art imitates Production

The LCR code base appears to be a turn-based trivia game. However, it is replete with dice-rolls, a penalty box, and a board that may or may not be in a Euclidean geometry.

It's a parody, and it's both funny and horrifying. Scary, because it feels so familiar to ghastly production code. That is, code maintained over time by many people, each of them blind and touching an elephant.

Even better, there are bugs! Just when you think you understand the rules of the game, you realize that it is impossible to distinguish between a quirky rule and an outright bug. The code really is magnificently bad, as though crafted by Kafka. (Ed's note: in fact, it was written by Chet Hendrickson).

Pairing

I paired with several people and learned from them all. We might pair at our day gigs, but the variety is fixed in that setting, and ultimately predictable; at an event like this, the environments are truly diverse and fresh.

For junior and intermediate developers, I can't stress this enough. At a retreat, you'll see new languages, editors, virtual machines, techniques, but most importantly, workflow. I paired with jbrains for a session. It was rewarding... and humbling. I thought I was fast but I've rarely seen such speed: mouseless navigation through several tools, all at the speed of thought.

Pairing can be intimidating. That's normal. We often hear empty phrases such as "get out of your comfort zone", but this is precisely that case. It's a fabulous way to learn and grow as a developer.

Tests

A predominant theme for each session was the importance of setting up some kind of test harness before making changes to the code. The harness is almost like a critical utility, such as getting electricity to a disaster site.

No surprise, but this transcended all language implementations, and manifested itself in many ways. For example, one C++ team simply set a fixed seed on a random-number generator and used the Golden Master technique on an output log.

Upshot

True, I haven't written much about specific techniques here. (To find out more, attend a Legacy Code Retreat! Or start with this site or the Feathers book.) But they are useful and interesting, along the themes above. The upshot is: this stuff is important, and fun. It's practice with others who care about the craft. It's hard to imagine a better bang-for-buck for your development as a software practitioner.


Sunday, July 21, 2013

PEI Hacks


This post is intended for keen, junior developers who reside in a community that does not afford many opportunities such as user-groups, conferences, etc. (I'm thinking of small towns in Atlantic Canada, but the main theme applies elsewhere.)

Hey nerds: discover PEI Hacks, and sign up for the day-long hackathon on August 24.

No, really: sign up. It's free.

"Why?". I'm glad you inquired (see intro)...

TL;DR :

It'll be fun and rewarding. You'll meet neat people.

^(TL;DR) :

It will help shape your professional world-view, your sense of reality.

Since I've returned to the Maritimes, I've discovered a small segment of developers who are bright and ambitious, but don't have a lot of experience. Despite all the online resources, books, etc, at their disposal, their world-view ends at the boundaries of the current daytime, 40-hour gig.

That's professional suffocation. A word to the wise: break out of that rut. Never bound yourself as being an employee for Acme Corporation. Work for You Inc. (in spirit, not legally), and honour an agreement with Acme: 40+ hours work for salary, benefits, whatever.

To break the rut, engage with real people, at real events: conferences, user-groups, meet-ups, hackathons - anything. You'll learn a ton of material outside of your daytime focus. You'll be profoundly humbled by talent, and challenged to improve. Generally, you'll be a participating in a broader community, a citizen of the tech world.

Will any of this assist your daytime work? Maybe, but it doesn't matter: this is for You Inc.

Upshot :

Find a mentor and ask him/her about favourite conferences, user-groups, and real-life events. Oh, btw, you'll find some fabulous potential mentors at PEI Hacks. So, come on out and play!

Monday, February 11, 2013

A Simple Code Kata

Hello CtJ nation!

Yes, it's been a long time, but we're still here at CtJ HQ, reading, if not exactly writing. Hopefully, more to come on that front in the coming weeks.

For now, this post is in support of an upcoming session at the PEI Developers Meetup. We'll be implementing a simple Code Kata and possibly extending it in interesting ways.

The Kata

The idea is a simple card game. Ignoring the rules of Rack-O, check out its deck of cards: numbers, but no suits.

The game is described as follows:

Begin with the deck of cards numbered 1 to N.

Shuffle and deal cards evenly to P players and a "kitty". That is: partition N cards (face-down) into (P + 1) sets.

Gameplay for a round:

  • Show a card, face-up, from the kitty.
  • Players all submit a hidden card as a bid.
  • Once all bids are made, the cards are revealed.
  • Highest bid wins the card from the kitty, and its value is awarded as points to the player. 
The winner is decided by most points at the end of the game.  

Notes

I like this kata for many reasons. First, it scales nicely: we could write code for a single round, and eventually ramp up to a game server with concurrent players.

Also, it combines simplicity and variation: it is easy to write an algorithm that satisfies the rules; yet a winning strategy can be dynamic and surprisingly complex. (Thanks to Alex Stangl for an email conversation on this, some years back.)

Finally, we can imagine a "robot wars" scenario where solutions compete against one another. Neat-o.

Upshot

For PEI Devs, think about this problem for the upcoming meeting.

For all, I'm looking for name suggestions (since it is not the game Rack-O). The best I have is Frak-O...

Sunday, February 26, 2012

Funcito: wrap Java methods for FP libraries

On and off, I've been collaborating with my friend, Kevin Welker, on an open-source project: Funcito. This is really his baby, but it has been great fun to be involved (more to come in another post).

Executive Summary

From the FAQ, Funcito is a Java library that simplifies access to functional programming APIs by wrapping Java methods as the function-type objects defined in those libraries. It reduces boilerplate now, without waiting for changes in Java 8.

The syntax (and internals) is influenced by Mockito, the popular mocking framework. However, Funcito is not aimed at testing.

It supports specific interfaces in Google Guava, Functional Java, and Jedi-core. See the project page for details.

Example in straight Google Guava

Here is example code for using Google Guava, using a List of Song objects.

The setup is simply populating the list:


public void init() {
// List<Song> songs is a member
songs.add( new Song("Help!", "The Beatles", new BigDecimal(1.29) ) );
songs.add( new Song("You Had Time", "Ani DiFranco", new BigDecimal(0.99) ) );
songs.add( new Song("Shoot to Thrill", "AC/DC", new BigDecimal(0.89) ) );
songs.add( new Song("Back in Black", "AC/DC", new BigDecimal(0.89) ) );
songs.add( new Song("Indie Song", "Obscure Band", BigDecimal.ZERO ) );
songs.add( new Song("Demo Track", "College Jam", BigDecimal.ZERO ) );
}

Here is an example test, using a predicate method on Song, isFree(), to filter for free songs:

public Collection<Song> filterFreeSongs() {
// boilerplate alert!
Predicate<Song> isFreePredicate = new Predicate<Song>() {
public boolean apply(Song s) { return s.isFree(); }
};

Collection<Song> freeSongs = Collections2.filter(songs, isFreePredicate);

// size == 2 in example
return freeSongs;
}


Note the typical pattern to build a Predicate, even though the object is simply calling a boolean method. Funcito addresses precisely this issue.

Example with Funcito

Using the same setup, here is the same test using Funcito. Note the proxy object, CALLS_TO_SONG:

// member of class
// using static import of Funcito's callsTo
private Song CALLS_TO_SONG = callsTo(Song.class);

public Collection<Song> filterFreeSongs() {
// using static import of Funcito's predicateFor
Predicate<Song> isFreePredicate = predicateFor(CALLS_TO_SONG.isFree());

Collection<Song> freeSongs = Collections2.filter(songs, isFreePredicate);

// size == 2
return freeSongs;
}


Less boilerplate, with improved readability and a fluid syntax!

The Upshot

If you are using straight-up FP libraries in Java, and want to reduce some of the boilerplate, check out Funcito. It's lightweight with minimal dependencies (either CGLib or Javassist), and can help you wrap up simple Java methods.

Monday, November 14, 2011

Groovy Talk

I recently gave an "Intro to Groovy" talk for a local CIPS chapter.

It was a special evening: I returned to my alma mater, re-united with old friends, and met enthusiastic students.

I assumed the audience wasn't familiar with Java, and so the narrative was a high-level report of the blossoming ecosystem on the JVM over the past few years, with examples in Groovy. The material is available here.

My thanks to those who attended!