Craig Maloney

Rick and I spent last weekend at the 1DevDay Detroit conference, held at the beautiful Compuware building in Downtown Detroit. Unlike conferences like PyOhio, Pycon, or Ohio Linuxfest, the conference wasn’t centered around one particular piece of technology, but was instead focused on the craft of developing software.

On Friday, after a quick bite provided by Pillar (thank you, Pillar) at the Hard Rock Cafe in Detroit, Rick and I went to the keynote presentations. The first was by SRT Solutions‘ co-founder Diane Marsh, who gave an excellent talk on how you as a developer are indeed your own company. The talk was inspiring, and outlined her own path from working as a consultant to becoming a “reluctant entrepreneur”.  Awesome talk, as always.

Next, Bruce Tate presented one of the highlights of the conference. His talk was a follow-up to his book “Seven Languages in Seven Weeks”, and really set the stage for the whole conference for me. The languages included Prolog, Clojure, Scala, IO, Ruby, Erlang, and Haskell (not in that order), and what followed for each language was a comparison between the language and a movie character, and some of the reasons why that language was worth reviewing. Highly informative, and definitely a kick in the pants for anyone out there content to find the one-true-language. It was also interesting to see what concepts could be borrowed from other languages.

Saturday was the workshops and presentations day, and there were no shortages of interesting topics to cover. The first for me was the Functional Languages talk, which was a continuation of the “foreign languages” theme for the weekend. Afterwards was the excellent talk by Justin Searls about Javascript, Jasmine, and Coffeescript. Lots of good brainfodder in that talk. Afterwards Rick and I had a spirited discussion with Justin and Karl Swedeberg about Javascript and the place of JQuery. Very good points all around on the place of JQuery and Javascript, and one of those conversations that happens at developer conferences that you don’t expect going in there.

Lunch was at the Compuware building cafeteria, and was awesome. Thanks to the 1DevDay Detroit folks for making it possible.

The next talk that I went to was a sort of intermission talk about lessons learned from improvisational comedy applied to development. Definitely food for thought about how we approach the development process.

Next up was Kevin Dangoor’s “New Tools for the Web” discussion. Kevin has an amazingly unflappable demeanor, and the discussion proved extremely informative. This might sound cliche, but it’s a great time to be a web developer.

Last, but certainly not least, Rick gave a talk about the importance of code readability. His example case was PEP8, which outlines the best practices for code under Python. It is also the name of a handy tool (pep8) which will review your Python code and let you know where you have sinned where you can improve your code to make it conform to the standards. There were several folks in the room looking for similar tools for other languages (C# in particular), but the main message of the talk was to adopt readable coding standards with your team, and stick with them. Even if you don’t adopt all of the rules for PEP8 (80 column lines is a tough one for me), at least know which ones you’re ignoring and have good reasons for why you’re ignoring them.

I’d like to thank the 1DevDay Detroit folks for putting together an amazing conference. This was the first conference I’ve been to that emphasized that it’s not the tools that make the developer, but the developer mindset that is important. I think that’s key for all developers who want to improve their craft. (You’d laugh at a carpenter that says they only specialize in screws and screwdrivers, but yet developers that specialize in Java are somehow OK.)

“The  DetroitDevDays mission is to build a software developer community in the Detroit area that is regarded as the best in the world.” It’s a lofty goal, but after participating in the conference, I think it’s definitely achievable.

Looking forward to next year already.

I recently had an epiphany, which may seem painfully obvious to most programmers, but it took me a little while longer to realize.

Under Python there is a module called doctest, which allows you to script an interactive session and look at the results. A sample would be:


>>> print 2+2
4


If I put this snippet into a text file, test.txt, and ran it with python -m doctest test.txt, I’d get no output, because the test passed (printing 2+2 under python gives us 4). However, if I put the following into the test.txt file:


>>> print 2+2
3.14159


and run it with the same command, I get the following:


craig@lister:~$ python -m doctest test.txt
**********************************************************************
File "test.txt", line 1, in test.txt
Failed example:
print 2+2
Expected:
3.14159
Got:
4
**********************************************************************
1 items had failures:
1 of 1 in test.txt
***Test Failed*** 1 failures.


Which is expected. (There’s no way that 2+2 is going to equal 3.14159).

So, you may be asking yourself, how does adding this to my normal code make me lazy? Isn’t this more work?

Well, considering when I’m writing new code, I’m constantly running the code in an interactive environment, and essentially doing the same scripted commands over and over again (albeit, a lot slower than the computer can), this is a huge time-saver. Essentially, I can script the session, and test the new code in seconds, and be alerted if something changes.

Anyone who says they don’t have time for testing their code is deluding themselves. If you think you don’t have time for testing, ask yourself if you couldn’t save a few keystrokes testing the code manually? Why not have the computer do it for you instead? After all, isn’t that what computers are for? (Handing tasks that would otherwise be drudgery).

EDIT: And yes, I know that doctest doesn’t scale well the same way that the unittest framework does. Right now with the code I have, it’s not that big of a deal. I know that eventually I will need to switch.