Articles Feed

Authors

Categories

Archives

MMEmail: My First Clojure Open Source Contribution

by: micah | April 21st, 2010 | 0 comments »

While working on website for my sister, I was perturbed that there were no libraries on Clojars for sending email. I was using Leiningen which will download and include all your dependancies for you (so sweet!). Yet, with the library I found, I had to manually download all the required jars. Call me lazy but being forced to manually download dependancies seems like cruel and unusual punishment these days.

So I solved the problem:

MMEmail

Simple Clojure library for sending email, with just one jar!

Installation

Leiningan:

  1. (defproject your-project "0.0.0"
  2. :dependencies [[mmemail "1.0.0"]]

Jar File

…can be downloaded at http://clojars.org/repo/mmemail/mmemail/1.0.0/mmemail-1.0.0.jar

Usage:

Include the library

  1. (use 'mmemail.core)

The Easy Way

mmemail.core is the only include you need. It contains only 2 methods, the fist being send-email. It takes a map that includes all the configuration and email parameters. That’s it.

  1. (send-email {:host "smtp.gmail.com"
  2. :port 465
  3. :ssl true
  4. :user "road@gmail.com"
  5. :password "runner"
  6. :to "joe@acme.com"
  7. :subject "Greetings"
  8. :body "Meep Meep!"})

Most of the parameters are required, but based on your server configuration you might get away without these:

It also accepts the following optional parameters:

The recipient parameters (:to, :cc, :bcc) may be a string, for one recipient, or a sequence of strings, for multiple recipients.

The Convenient Way

It can be annoying to pass such a big map into the function, and typically you’ll want to get all the server configuration out of the way. This is where the second function of mmemail.core (create-mailer) comes into play.

  1. (def my_mailer (create-mailer {:host "smtp.gmail.com"
  2. :port 465
  3. :ssl true
  4. :user "road@gmail.com"
  5. :password "runner"}))

create-mailer will return a new function with all the configuration baked in. So in the future, you can send email like so:

  1. (my_mailer {:to "joe@acme.com"
  2. :subject "Greetings"
  3. :body "Meep Meep!"})

The create-mailer accepts email parameters that will be used as defaults when the generated function is called.

  1. (def my_mailer (create-mailer {:subject "Greetings"
  2. :body "Meep Meep!"
  3. :host "smtp.gmail.com"
  4. :port 465
  5. :ssl true
  6. :user "road@gmail.com"
  7. :password "runner"}))
  8. (my_mailer {:to "joe@acme.com"})

License

Copyright 2010 Micah Martin. All Rights Reserved. MMEmail and all included source files are distributed under terms of the GNU LGPL.

Limelight 0.5.0 Released

by: micah | October 19th, 2009 | 0 comments »

Today we released a new and exciting version of Limelight. Just a reminder, Limelight is a user-interface framework for Ruby. Included in this release are not only some new features, but also a new means of production(application) distribution called Playbills, and a snazzy production that documents the Limelight framework.

Playbills

Playbills is a hosted repository of available Limelight production. When you open the Limelight application, Playbills will open automatically (assuming you’re connected to the internet) and display a playbill for each production. Each Playbill provides a brief description to help you decide if you’d like to open the production. When you’re convince, click on the provided button. The production will be downloaded an opened in Limelight. Pretty nifty I think.

Limelight Docs

Among one list is a Playbill for our own Limelight Docs production. We’re quite pleased with this one. It’s a swiss army knife of documentation that should make it fairly simple for developers to build their own Limelight productions. You’ll find descriptions, walkthroughs, RDoc, and dynamic sandboxes where you can experiment with the features right inside the documentation! What’s more, the RDoc is loaded dynamically from Limelight’s runtime… You can’t get more up to date than that!

Status

Limelight has been a thrilling side project to work on. I’m very pleased with how it is turning out. We are using Limelight internally at 8th Light for a variety of projects. This release (0.5.0) is still a beta but the Framework is maturing rapidly. Although there are still a few rough spots, I’d certainly be willing to use it for production projects. Development on Limelight is active and the productivity advantages of using Limelight are hard to beat.

P.S. If you have a production you’d like listed on the Playbills server, let me know (micah at 8thlight dot com).

Reflection on Hangman

by: micah | October 4th, 2009 | 7 comments »

Last week concluded the Hangman Ruby Sparring Tournament. The results are below.

Unlike the previous Battleship Tournament, I put the effort in to write a competitive hangman player (of course he was banned from competition). This made things interesting. By knowing precisely what it takes to create a player, I was able to precisely tune the scoring metrics. My goal with the scoring metrics was to evaluate the code, without actually looking at it myself, and rate it’s quality/cleanliness on a scale of 0 to 100, where 100 was asymptotically impossible to reach.

It is not easy to score well on ALL the metrics. Each metric will push your code in a different direction some of them are opposing. For example, to score well on the flog metrics, you have to break your code up in to lots of tiny methods. However, extracting methods increases the amount of code you have which brings down the simplicity score. To get an overall high score requires compromising between opposing metrics over and over again. Realistically, writing clean code requires the same type of compromising between coding principles. I am thoroughly impressed with the high scores that people were able to achieve in this tournament.

In the end, I believe that the highest scoring players do fit many of the criteria for “clean code”. Which is to say that to metrics used to evaluate the code are fairly complete. However, there is one gaping hole. The highest scoring solutions look like this:

  1. def b
  2. @r.fill(0)
  3. c
  4. @l = @l.sort_by { |x| @r[x] }
  5. end

People discovered that by using short variable names and method names, they could considerably reduce the “simplicity” of their solution. For this tournament, the simplicity score measures the code mass (compress all the code and count the bytes). It’s a fair metrics because in general, the less code there is, the less code people have to read to understand it. I especially like the fact that comments hurt the score. Anyhow, clearly the code above is not good code.

What’s missing is a analysis tool to measure “Readability” of code. I imagine such a tool would be similar to flog and flay in that it parses your code and examines all names used for variables, methods, classes, etc. When it finds 1-letter names like above, it punishes. When it finds names containing english (or other languages) words, or derivatives of other names, it rewards. For example, it I had a class named “Player”, that’s an english word which is readable. Good. Now a class named “ThingAmaBob” is not english but that not necessarily bad. And you’d expect variables with names like “mythingamabob” or “thingama_bobs” which would be good. There are plenty of ways to expand on the idea. Such a tool would bring our repertoire of metric tools one step close to completion.

Hangman Tournament

by: micah | August 28th, 2009 | 12 comments »

Several months ago, I hosted the Ruby Battleship Tournament. It was an all-round fun event where craftsmen sharpened their claws and pitted their skills against their peers. Since then, there has been much interest in the next tournament.

Today I am announcing the commencement of the Ruby Hangman Tournament. In this tournament your challenge is to build an AI to play hangman. Unlike Battleship, your AI will not battle against opponents, but will instead play solo. You must teach your player how find words as accurately and as quickly as possible.

The most prodigious player will be dubbed Tournament Champion. But this is a tournament of Craftsmanship, so the ultimate title will be awarded to the Tournament Master. To earn this most prestigious of monikers, your player must not only play hangman spectacularly, but also be crafted with the utmost quality of code.

Getting started is easy. Simply follow the instructions to get a default AI generated and running on your computer. Then all you have to do is tweak the solution to be as good as you can get it before the end of September.

This is a great way to practice your craft. You could introduce the tournament in your next user group meeting. Show it to your peers over lunch and learn.

You can also just play the game if you like (screenshot below). Good luck!

Copyrights Conundrum

by: micah | March 12th, 2009 | 0 comments »

Here’s the situation. You’ve spent days working on an open source project. Your sweat, blood, and tears have been poured into thousands of lines of code spread through countless file in a sprawling tree of directories. The final step is to release your masterpiece into the wild. So you choose your open source license and then it hits you; you realize that need to add a copyright header to EACH and EVERY source code files. How tedious! You google for a tool that will automatically add the headers for you, and you find nothing satisfactory. In the end, you write your own script to add the headers for you.

I’ve been in this exact situation and written such a script too many times. My most recent experience and script implementation will be the last. I’ve dubbed this last imeplementation MM Copyrights and you’re welcome to use it.

MM Copyrights is a simple Ruby gem that will search a directory for source code files, inserting or updating a header comment in each file.

Installing

It’s just a matter of installing the gem hosted on Github.

  1. gem sources -a http://gems.github.com
  2. sudo gem install slagyr-mmcopyrights

Update: The github shenanigans is not longer needed. To install, simply:

  1. sudo gem install mmcopyrights

Usage

Let’s say you want to add the following copyright header to all .rb files in the lib directory…

  1. require 'mmcopyrights'
  2. MM::Copyrights.process("lib", "rb", "#-", "©2009 Micah Martin\nAll rights reserved")

And all the ruby files will look like this:

  1. #- ©2009 Micah Martin
  2. #- All rights reserved
  4. ... ruby code ...

Typically I keep the copyright text in a separate file and write the following Rake task…

  1. task :copyrights do
  2. require 'mmcopyrights'
  3. MM::Copyrights.process('lib', "rb", "#-", IO.read('copyrights.txt'))
  4. end

or the following ant task if need be…

  1. <target name="copyrights">
  2. <exec command="ruby">
  3. <arg value="-rrubygems" />
  4. <arg value="-e" />
  5. <arg value="require 'mmcopyrights'; MM::Copyrights.process('src', 'java', '//-', IO.read('copyright.txt'))" />
  6. </exec>
  7. </target>

Details

If you haven’t guessed, MM::Copyrights::process takes 4 parameters.

  1. The path of the directory containing source code.
  2. The extension of source file to be processed.
  3. The comment prefix. Note that there’s an extra -. This is because we want the copyright comments to be unique from all other comments. The tool will search for this unique prefix to find existing copyright headers.
  4. The copyright text, without the comment prefix.

That’s about it. Feel free to run MM::Copyrights::process multiple times on the same code base. It’s harmless. And when the new year rolls around, just change the copyright text and rerun the tool. It will update existing headers.

Kata: Langston's Ant in Ruby

by: micah | November 13th, 2008 | 3 comments »


Langston’s Ant in Ruby Kata Screencast

I’ve recorded my Langston’s Ant kata for all to see.

This particular kata, with slight variations, has been in front of an audience twice before. Once at a Software Craftsmanship group SCG meeting and again at RubyConf2007.

On both occasions I asked the audience to evaluate my performance on a scale of 0-10, 0 being the worst kata you can imagine, and 10 being the best. At the SCG, my performance was longer than the screencast because I didn’t use the instance_eval trick and wrote multiple case/when statements. It resulted in much more code as well. Honestly, I felt the kata dragged on a bit too long which is why I shortened in subsequent performances. Despite this, the SCG audience gave me an average score of 8. At RubyConf, the kata was almost exactly like the screencast and it earned me an average score of 7.

Now coming from an audience of dedicated Ruby developers, I’m quite pleased with my score. Here’s some of the feedback I got…

I find this feedback immensely valuable and thank those who took the time to provide me with it.

In martial arts, the techniques performed in kata are not always by the book. There is an aspect of art, creativity, and entertainment. At several points in my Langston’s Ant kata I intentionally decided to bend the rules to enhance artistic and entertainment values. I leave it up to you whether I made the right compromise or not.

After watching the kata, leave a comment with your rating and any feedback you have for me. I thank you in advanced.

Simon

by: micah | November 10th, 2008 | 0 comments »

You remember the classic Simon game, right? The one where the electronic devise will blink a color and make a sound that you have to replicate by pushing the colored buttons.

At RubyConf 2008, I cornered Jim Weirich and asked his opinion on Limelight. He didn’t feel like he had seen enough of it to give a good opinion. So we found an hour where we could both sit down and build a simple Limelight production. We decided to build Simon.

The result is really quite simple. It’s a couple hundred lines of code, UI, game logic, and all. It’s also got a suite of unit tests.

If Limelight is installed, you can download the production file, and double click it, or enter the url in the Startup Limelight Production.

Limelight Production file: http://blog.8thlight.com/files/simon.llp

The Source Code can be found on github.

Ruby Battleship Sparring Tournament

by: micah | November 8th, 2008 | 0 comments »

Yesterday in my talk at RubyConf2008, I announced the commencement of the Ruby Battleship Sparring Tournament.

This is an open tournament. All are welcome to participate.

Limelight 0.3.0 Released

by: micah | November 5th, 2008 | 0 comments »

This release of limelight contains many new features and stability. Perhaps most notably, Limelight will no longer eat 95% of your CPU (ouch)! It's proud to say it's becoming quite usable for real apps of considerable size.

Default event implementation - feature_request
Image player - feature_request
Sending variables to partials - feature_request
CPU Hog -
Gems in productions - feature_request
Giving Floats to prop styles - feature_request
Scene's Default name - feature_request
Hand Cursor Stays - bug
generate production templates - feature_request
Validate styles - feature_request
Auto resizing doesn't trigger update on parent. - bug
Double click to open production - feature_request
Color as a hash - feature_request
Add more Known colors - feature_request
Need to relaunch when changing player. - feature_request
Shared Players - feature_request
Unique IDs - bug
Building a Production - documentation
Document Events - documentation
Document Prop API - documentation
Document Styles - documentation
Variable size text areas - feature_request
Editable TextArea size - bug
Simple App screencast - documentation
RDoc - documentation
finish 0.2.0 release - release
Reserved prop keywords - bug

Agile in Buenos Aires

by: micah | October 29th, 2008 | 0 comments »

Last week I attended Agiles2008 in Buenos Aires, Argentina. It was a fun, high energy conference. The highlight was a heated panel discussion at the closing of the conference. On the Panel was Matt Gelbwaks, myself, Tom and Marry Poppdieck, Dave Nicolette, and Tobias Mayer. Tobias has already posted a blog about the event. So that my opinion is not misconstrued, I'll share it with you here.

The future of Agile is Software Craftsmanship.

Software is a young industry and we're still discovering more about it every day. Yet, it has it's origins in electrical engineering. So it's seems that, at it's inception, people assumed software was a form of engineering. And to build software systems should be no different from engineering any other creation. Take a bridge for example. Before building a bridge, you have to analyze the bridge requirements. How long will it be? How much weight must it hold? etc... Once the requirements are understood, you design a solution. Build to-scale models that you can push and stress to make sure the design hold up. Then, once you have a solid design, can you begin construction of the bridge.

It's waterfall. Waterfall worked for engineering so waterfall was applied to software. We know now that waterfall doesn't work. Agile, is a realization that software is not a form of engineering. Agile is a realization that software is a craft.

I have been to every North American Agile conference since the very first, and I have noticed a trend. In the first conference in Charlotte NC, laptops were open on every table, around every corner, with someone or a pair of people writing code. In many of the sessions, people were writing code or talking about it. This is the conference where people were bragging about their Ward number (0 if you paired with Ward Cunningham. n + 1 if you pared with someone with a Ward number of n.) and desperately trying to improve it. It was truly a conference about software. Over the years, less and less coding could be found at the conferences. This last year, at the conference in Toronto, it was abysmal. Although there was some good content, I felt like the conference had been taken over by Scrum Masters. It was no longer a conference about software development. It had become a conference about project management, people management, and Scrum. This makes me sad.

In middle ages, if you were a lord and you wanted to build a cathedral, you found a master craftsman. The master craftsman recruited other craftsmen and together they constructed amazing buildings that still stand today. These craftsman were passionate about their work and cared about creating great buildings. That is what made it work. They didn't have scrum masters telling them what to do or cheering them on. The great work they did is a tribute to their craftsmanship.

The future of Agile is Software Craftsmanship. Developers out there need to realize that software is a craft. As such, developers should strive to become craftsmen; strive to learn more about software; strive to write better code; strive to build the best software possible. The software you get from a team of true craftsmen will be unrivaled. It is the goal and quality within that drives a team of craftsmen. They'll find a way to overcome any obstacles and adapt to any changes.

Fidelity Life Case Study

by: micah | October 2nd, 2008 | 0 comments »

As craftsmen, we're proud of our work. Yet it's rare that we get the opportunity to show off what we do for clients. Fortunately the kind folks at Fidelity Life have given us permission to do just that. Check out the case study summarizing several systems 8th Light built for Fidelity Life using mostly Ruby and Rails. This project is a whopper. Fidelity Life Case Study

Software Craftsmanship Group

by: micah | October 2nd, 2008 | 0 comments »

I'm pleased to announce the inception of the Software Craftsmanship Group. http://groups.softwarecraftsmanship.org The first meeting is October 13th at 7pm in 8th Light's office. Hope to see you there.

Definition of Software Craftsman

by: micah | September 21st, 2008 | 5 comments »

Craftsman Clarification

There has been some discrepancy in the use of the term “software craftsman”. Rather than going into details about various uses of the term, I’ll just clarify what I believe it means.

software craftsman n. A man who practices the software craft.

There are a few points to make about this definition.

1. “software craft”

A craftsman believes that software is a craft. This is important because not everyone believes this. A craftsman takes pride in his work an strives to do the best job he can. He believes that writing good software requires skill and careful attention. That software is not something that can be manufactured nor can it be delivered faster by merely adding more bodies.

2. “practices”

A craftsman practices his craft, always striving to become more skillful, to produce better software.

There are traditionally 3 stages of craftsmanship:

  1. Apprentice
  2. Journeyman
  3. Master

No matter which stage one may be in, as long as he practices software as a craft, he is a craftsman.

3. “A man”

Technically the term “craftsman” is gender specific. Women are just as capable of software craftsmanship. Indeed, I’d like to see more software craftswomen out there. In an effort not to alienate anyone we should use the term “software craftsperson” more liberally.

Update: There’s a movement afoot to make the term “software craftsman” gender neutral. Feel free to comment below.

I’ve checked with the book “Software Craftsmanship” by Pete McBreen to see if it conflicts with my definition. Although, he uses the term “software craftsman” ambiguously at times, he is careful to use the term “master craftsman” when referring to craftsmen at the height of his craft. This is in line with my definition.

I hope this serves as a reference for my use of the term. People should not think me presumptuous when I call myself or my colleagues craftsmen. I mean only what I describe above.

Tag! I'm it!

by: micah | July 2nd, 2008 | 2 comments »

David Chelimsky tagged me with this “chain-blog”. I’ve enjoyed reading other peoples’ stories. Here’s mine.

How old were you when you started programming.

Hard to say. I suppose I was legitimately writing code at 9 years old

How did you get started programming.

You might say I was born into programming. At a very young age, maybe 4 years old, my dad (Unclebob) would put me on his shoulders and take on a robot’s personality. He would remain motionless until I ordered a command. For example, if I said “walk” he would start walking. If I said “turn” he would turn. And in a very computer-like-fashion, he would follow my orders to the “T”. After a “walk” command, my dad would not stop walking until I issued a “stop” command. Poor programming on my behalf often led my dad, with me on his shoulders, straight into a wall. I used to laugh with delight as he’d bounce off and walk into the wall again and again until I corrected my programming error.

What was your first language?

At 9 years old my dad taught me Logo. I was drawing circles, squares, spirals, and in general making that turtle dizzy.

What was the first real program you wrote?

In high school I programmed casino games on my TI-81 during physics class. You could play Black Jack, Roulette, Bet on the Horses, play the One Armed Bandit. My friend Jim Maggio even did some pixel art for the slot machine. It was pretty sweet. All the physics students were required to have TI-81’s so my games ended up getting copied over and over. My first open source experience I suppose.

What languages have you used since you started programming?

In chronological order…

Logo, Basic, Fortran, Pascal, Forth, C, C++, Scheme, Java, Python, Ruby, JavaScript, C#, Objective-C, Smalltalk, Assembly.

Whoa! I’m impressing myself with that list. But who am I kidding? I doubt I could remember how to write HelloWorld in half those languages now.

What was your first professional programming gig?

An internship at Object Mentor. I wrote some Java Servlets to automate parts of their website.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Software is not a spectator sport. ie. Just watching people code won’t make you a good coder. Code as much as possible if you want to master your craft. Code at work. Code at home. Code on vacation (WARNING Your spouse may throw your computer off the balcony). Code for fun. Code to kill time. Code while you’re sleeping (I mean in your dreams).

What’s the most fun you’ve ever had programming?

The project the David Chelimsky referred to was mighty fun. But I’d have to say the most fun I’ve had with my colleagues at 8th Light, Paul Pagel, Jim Suchy, Eric Smith, and Doug Bradbury. I have never worked with a stronger team. When it comes to software, I imagine we could prevail over any challenge. Outside of software, our strengths are less impressive….

  1. We started a basketball league and had a perfect record: 0-10. That’s right, we lost 10 out of 10 games.
  2. We went on a ski trip together an managed to loose some family members in the mountains, during a snowstorm, at night. They lived.
  3. Doing push ups every hour of every working day surely made us stronger and earned us an infamous reputation in the office.

Up Next

Paul Pagel, Jim Suchy, Eric Smith, Doug Bradbury, Matt Segvich, Unclebob, Bob Koss, Michael Feathers, Dean Wampler, Tim Ottinger, Chad Fowler, Jake Scruggs, Mike Clark, James Grenning

Tag! You’re it!

Announcing Limelight

by: micah | June 2nd, 2008 | 1 comments »

I’m pleased to announce the open source Limelight project: A thin client and application framework written in Ruby (JRuby).

http://limelight.8thlight.com

###############