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:
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...
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.
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...