January « 2010 « ihumanable

January, 2010

code / work — 1 Comment
29
Jan 10

learn autoit

Bezels and shadows and reflections, oh my

If you use windows at work or at play this post is for you, macheads and linux people I’m sorry, this post probably won’t help you much. I have had the joy of doing documentation work for the last 2-3 months at work. Gnarly, ugly documentation that serves little purpose other than making someone feel happy that there are reams and reams of documentation. At some point, probably around the 5th document, I made the realization that out of 20 pages it was mostly boilerplate, with about 8 things peppered throughout that changed. I decided that it would be easiest to make a template document and then just do a find and replace on those eight symbols [[DOCNUM]] [[DOCNAME]] [[DOCTRANSACTION]] etc.

Productivity shot up, I could now stub out a document in a few minutes instead of the hour or so that it used to take to manually hunt through and change things. All was well and after a day or two of find / replacing I had stubbed out the 80 or so documents. Then came the meeting where it was decided that 2 new sections would be needed and that 8 sections could be removed as being redundant. This victory for common sense was also a giant headache, as I didn’t really look forward to restubbing 80 documents. There had to be an easier way, a better way, I remembered a screen driver tool I had some exposure to at a past engagement, AutoIt.

After reading through the documentation and goofing around with it for a while yesterday I now have a fully functional script that will automatically stub out all of the documentation with the click of a button. A task that used to be an error-prone, manually intensive process now requires no intervention. We can restub on demand now, so changing the template is no problem.

The Good

Saves a ton of time
Removes the human aspect from an existing process
Centralizes specific knowledge
Easy to write and test

The new script saves a ton of time, I can regenerate all documentation in about 10 minutes, so I click a button and go walk around the office bugging people. AutoIt simply takes a known working process and steps in to be the person driving it, I didn’t have to take time dreaming up a brand new workflow, I could focus on just getting it done. The script is now the system of record for the specific things that change from document to document, which is nice for trying to determine at a glance what makes an HCR1 different from a ARC6 command, without digging through 40 pages of documentation. AutoIt also utilizes a stripped down version of SciTE with auto-completion and built in support for compiling and running, which makes writing and testing the script a breeze.

The Bad

Ugly syntax (like VBScript and PHP had a bastard child)
Oddly organized documentation and variably helpful community
Inherently brittle scripts
Still slower than I’d like
Foreground processing

AutoIt has an ugly syntax (think VBScript), but it has all the pieces parts to make a nice script, functions and variables. The documentation takes a little getting used to, there is plenty in there, but it could be organized better. AutoIt depends on things like the window title and absolute paths, so it is inherently brittle, I doubt this script would run unaltered on someone else’s machine. This could just be me being a n00b at AutoIt but I followed the practices laid out in the tutorials and the documentation. The other bad part about AutoIt is that it drives your screen, it simulates you pressing buttons and mousing about, so the script is slow and you can’t interact with the machine while its running or you will probably mess everything up.

Alternatives

After proclaiming my victory over the documentation monster, I got some replies from colleagues asking why I didn’t just make a powershell or ruby program or java program or something. I could have cracked open OpenWriter or something and attempted to build some massive program that could create .docx files, but that would have taken a ton of time. The AutoIt solution was incredibly quick to produce, took about 2 hours of playing around with it. There were a bunch of side benefits that the alternatives wouldn’t have had. The template file is just a plain ordinary .docx file with all kinds of crazy formatting and images, instead of trying to figure out how to reproduce this in code, I can use Word to do the heavy lifting for me. This allows business users to change the template and we can rapidly restub and get back up and running.

Conclusion

You should go and learn AutoIt or AppleScript or whatever GUI driver program is available for your platform. It is not the tool for every job, but it’s perfect for some jobs. Being the person on your team that can take some boring, error-prone, laborious task and turn it into a turn-crank task is a great thing. You can save your team time, get back to doing actual work more quickly, and make a name for yourself as a problem solver.

none — No Comments
28
Jan 10

ipad

nerd law also required I use a picture with Spock in it

As required by nerd law, here is my mandatory post on the iPad. I’ve got lots of nerd friend and the general feeling I get from them is a sigh and a “meh.” The term “underwhelmed” is being thrown around a lot, reinvigorating the debate as to whether or not there is a perfect amount of “whelmed” one can be so as to be neither under- nor over- whelmed. Here is my take on the new shiny.

Let’s not forget our history. When the iPhone came out people far and wide declared that it will fail, is failing, already failed. Yet despite such serious problems as no cut-and-paste and a weird virtual keyboard, somehow it won Time’s gadget of the year award, and a huge population of happy iPhone users. People to this day don’t quite get it, I have an Android phone (one of the first G1s) and I love it, but there is no denying the sexiness and sleekness of an iPhone. If you don’t understand the big deal play with one for a week, its just a completely polished user experience.

That is the strength of Apple’s products, the experience. Its easy to find plenty of small, reliable mp3 players that store tons of music, people buy iPods because they are seamless and easy. I was asked recently what made OSX superior to Win7, I didn’t have an answer, I work with both and I enjoy OSX much more but have no real good bullet point for why. I was looking for some big reason, oh the dock, oh it’s pretty, oh the finder, but couldn’t think of any quantitative reason why they were better. When it came down to it, there are just a million little reasons that all add up to a great experience.

To each their own though, I don’t want to start a Windows vs. Mac flamewar, there are plenty out there if you feel the need just type “I hate Windows” or “I hate Mac” into google if you must. The point I want to make is that Apple thinks about their products from a full end-to-end experience, and that’s where something like an iPad could beat the pants off of a netbook. Make no mistake about this either, that is where they are targeting, Jobs said it in the keynote and the pricepoint confirms it. iPad is not meant to compete with MacBooks or Dell D830s (the computer I’m currently typing on) they are meant to compete with Dell Inspiron Minis and eee PCs

There is a niche market out there and I think Apple has the marketing and business savvy necessary to corner it. With all the hype it would have been difficult to not be underwhelmed. It doesn’t cure cancer or come with a free pony, boohoo!

Now I’m going to take my life into my own hands here and make a prediction (watch out!) The iPad will succeed, it will have a spreading pattern to certain niches until it picks up a critical mass and people who don’t really need them start to buy them. First the early-adopter and mac-fanboys will start buying them up, then there will be some app that endears it to some group of people in a fierce way. Maybe a text-book app or medical records app, whatever it is there will be some population that is in love with the iPad. They will start to infect their friends and family with iPad fever and it will become hip and cool, then it will become annoying, and then it will just be fact, 30 jillion people have iPads and you won’t be able to walk into a Starbucks without someone reading Hipster monthly on one.

I’m excited about the iPad, it doesn’t have everything I always wanted, but it will definitely move the ball forward. I personally think the very slightly modified iPhone OS was a mistake, I think there are lots of mistakes and things that I wished were included (like that pony I really wanted). But I’m going to have to reserve judgment until I ca go down to the Best Buy and screw around with one.

philosophy / work — 1 Comment
27
Jan 10

objective measure

this ruler is deep and spiritual, that's why it was photographed in black and white

I’ve found myself in an odd situation as of late regarding my work, I am a programmer by trade and education but haven’t done any professional programming for 2-3 months now. It’s not that I’m being lazy and don’t want to program, I would jump at the chance to fire up Eclipse right now and start writing mountains of verbose Java code, it’s that I’m not allowed to program. “Not allowed?” I hear the shock and dismay in your voice, so let me explain.

My role on this project is to design middle-ware but because of the way the business is set up I’m not actually allowed to program, the programming is all outsourced. Instead of actual programming I get to engage in some weird form of meta-programming where I turn a program into long flowing sentences in a Word document that take about 3 times the effort to write than the program itself so that it can be shipped off and someone else can program it. It is an odd situation indeed, but I am no business man, this project is important, and so I shall continue in this weird meta-programming.

This is not my first dance at the outsourcing-prom and with the economy in shambles I’m certain it won’t be my last. I have yet to work on a project where the supposed benefits of outsourcing have actually materialized. I did some research (typed something into Google) to attempt to find out how many outsourced projects fail and saw figures between 25-40%. These seem fairly reasonable to me, and with some statistical hand-waving I will use these as “good enough” figures for the rest of this post. This leads to an interesting question though, if this strategy fails so often why do companies continue to outsource?

I would like to posit that a major reason for the continued use of outsourcing is the gap between subjective and objective measure. Subjective measures come from within, they are personal opinions, things like “Frank is a great worker!” or “Jim is so lazy” are subjective measures. Objective measures are fact-based measures things like “Frank worked 48 hours this week” or “Jim only produced 1 class file this week.”

Often, like in the examples above, our objective measures inform our subjective measures. The problem with software development is that there are no good objective measures. As much as we like to think of what we do as a science or even an industry, it is still a craft. In the above scenario we are led to believe that Frank is a “great worker!” because he worked 48 hours this week and that Jim is “so lazy” because he only produced 1 class file. If Frank worked 48 hours doing simple things and just racked up the billable hours is he really “working” harder than Jim who wrote a full web server in one week (monolithic in design so it was only one class). Getting to the heart of the value that someone produces is a difficult process and is by its nature subjective.

Here in lies the problem, software development can really only be measured subjectively, which is hard. Objective measures are much easier though, and so those are often used as a proxy for doing the difficult work of subjective measures. There have been many attempts to make sure people are performing up to par, lines of code, commits, bugs, hours worked, etc. None of these are really ideal, together they can begin to form a picture of the subjective nature of the situation, but they are not nearly enough.

Objective measures are also very seductive because you can perform calculations on them, they are easy to compare, they are easy to play out what if scenarios with. No one balks at answering the question which child is taller, but ask them which one they love more and watch them squirm. Objective measures are great because you can throw them in excel and analyze them, this is also a weakness. It’s easy to draw up a spreadsheet with your in-house assets pitted against outsourced assets and see that you can save a bajillion dollars by outsourcing, but that misses the bigger picture. What are the subjective downsides?

These subjective downsides end up failing some 40% of outsourced projects, communication, quality control, and responsiveness are hard things to chart and graph, but can easily cause a project to run off the rails. What is needed is either some way to make subjective measure easier or some fantastic new unit of objective measure. I would propose ihumanables per hour be the unit if anyone can come up with some really nifty objective system, but I don’t see that happening anytime soon, so all that’s left is making subjective measure easier, a tall order indeed.

At the heart of making subjective measure easier is really what a lot of the agile methodology is about, stand up meetings, scrums, kanban boards, they are all meant to produce a tight feedback loop so that the subjective nature of the situation is constantly being polled. I’m not going to sit here and tell you all to start running agile projects, although they can be a good bit of fun, but if you are managing people you need to get in the dirt with them. Progress reports and weekly status meetings are meant to supplement not substitute actually working with and understanding what the people under you are doing.

Remember the next time you are making a decision based off of objective measure, if you are “going by the numbers” that there are very real subjective side-effects that you should account for and be aware of. And if someone develops a really killer objective measure for software development, remember ihumanables per hour

code / philosophy — 3 Comments
26
Jan 10

when in rome

Trust me, you want to do what the Romans do, I mean... have you ever built a Collisium?

Ah the cliché of it all, “When in Rome.” Although it would be nice to have a post about being in or traveling to Rome, sadly this is not the case. Instead, this post is about following convention and how that can help you learn.

I’ve been getting into ruby as of late, after learning Smalltalk, Objective-C, and LISP (to varying degrees), ruby hits a nice sweet spot of stealing some of the best bits from each. I was recently approached by a friend who does primarily .Net programming about the best way to go about learning ruby. He had decided that, at least in the beginning, he should use the NetBeans IDE. This seems harmless enough, even logical for someone who spends their entire day in Visual Studio to want the comforting guidance of the IDE. It is also the exact wrong approach.

As he progressed past simple “Hello World” examples and onto his first rails project he found himself battling with the IDE. Odd error messages, the IDE struggling to provide auto-completion on the dynamic models, but most importantly a complete lack of resources. The ruby and rails world to a large degree lives and breathes on the command line, right now if you go to my home computer you will find 4 terminal windows arranged with a mysql shell, script/console, script/server, and one for git. If something goes wrong and I get a weird error, I do what all great programmers do, copy and paste that sucker into Google. I normally find somewhere around a bajillion hits with solutions, huzzah!

My friend on the other hand had trouble doing the simple things through the IDE, like installing gems. I’m certain the IDE was capable of it, and that someone better versed in it would be able to help him out, but the Google-scape was barren to his questioning. All I could say to answer his questions were, “well I’m not sure how NetBeans does it, but on the command line just type gem install [gem]” (Also I can speak in teletype, I just do a robot voice.)

Despite the difficulties, my friend clung to the belief that the IDE was the way to go for beginners. I finally realized the perfect analogy to drive home the point, I asked, “Would you ever advise someone new to .Net to learn it by using the command line tools?” It’s a perfectly valid question, I’m sure plenty of people who hang out in vim all day and don’t mind doing things like ./configure && make && sudo make install (thanks Jeremiah for pointing out my n00bishness) would feel much more at home on the command line.

I am not free of fault on this either, when I attempted to learn git for the first time, I used TortoiseGit. I was very comfortable with TortoiseSVN and thought it would ease the transition. It sure did, I was able to treat git exactly like svn, and completely miss the point! Once I moved to the command line (and watched some screencasts and read some articles) I felt much more at home with git, and even began to understand why I would want to use it over svn. I had stopped trying to make it something it isn’t and embraced the thing that it is.

The point here is that when you learn something new, it’s new, don’t bring along your technological baggage. If the community all rallies around some IDE (.Net, I’m looking at you) then for flying spaghetti monster’s sake, use that IDE. If they rally around the command line (ruby, I’m looking at you) then by the hammer of Thor, use the command line. If they rally around some weird virtual environment machine (smalltalk, I’m looking at you) then have fun and realize you are never going to be able to use that at work (just poking fun, I <3 smalltalk).

The point here is that learning something new is often times uncomfortable, you have to feel like a tourist for a while. When in Rome though, do as the Romans do. Embrace the methodologies, naming conventions, and tools that are the community standard. Give it a few weeks, if you still find yourself hating it, then maybe that particular technology isn’t for you, it’s ok, we can’t all love everything. Life is about trying new things and figuring out what makes you want to get out of bed in the morning, for some people it will be .Net, for some ruby, for some COBOL (just kidding, no one likes COBOL).

You never do yourself any favors by half-way learning something, because you will either hate it because it was poorly shoehorned into an inappropriate paradigm, or you will learn to love it. “That second thing doesn’t sound too bad” (I can sense your thoughts), and at first blush its not, until you want to start participating with the community by using others’ code and sharing your code. Then you will have to unlearn all the bad practices you’ve adopted and have a difficult transition into the community, attempting to erase months of muscle memory. Save yourself the difficult task of trying to unlearn something and simply embrace the technology in full to begin with. It’s a steeper curve, but the payout is the depth of understanding.

code / none / philosophy — 1 Comment
25
Jan 10

api

oh creator of hot pockets, we praise thee!

I remember being a young lad preparing myself for university I was given a gift from my mother, “C++ for dummies.” The vote of confidence on my status as a “dummy” aside, I read the book with great interest. There was an analogy the author used to explain the idea of classes and what functions they should expose, I’m going to shamelessly steal it (paraphrasing as I don’t have the book with me).

Imagine your son comes up to you and says he wants to make some nachos. You tell him that its fine by you, just go cook them in the microwave, and there is nothing controversial about this statement. Microwaves are actually boxes full of high energy radiation being produced by cavity magnetrons or waveguides, to the end user, the microwave is just a magic warming box. It exposes a very simple interface, some buttons that allow you to enter the amount of time you want to cook something.

This is the essence of an API (Application Programming Interface), wrapping up something complex and possibly dangerous in something safe and easy to interact with. When building code that you intend other people to use someday, it is the part that is most important part, and the part that is easiest to overlook. The problem is that we are often too close to something and too concerned with our use case. If you want to design code for others to use, it requires significant time and effort, and even then you probably still won’t get it right.

Prosper is still undergoing active development, I’m currently agonizing over how I want to expose various execution modes. The solution, no matter what I pick, is trivial to implement, but the api is the most important part. A great api exposes a consistent concept, something that is easily grasped and allows the end user of the api to declare what they want to do without having to worry about how its going to get done. Since good programmers write good code and great programmers steal great code, I’ve modeled the api for prosper extensively off of jQuery. And why not, let’s take a look at two different APIs, the browser dom api and jquery.

  //Let's barber pole a list by coloring every other element blue
  var list = document.getElementById('the_list');
  var highlight = false;
  for(var i = 0; i &lt; list.children.length; i++) {
    if(highlight) {
      list.children[i].style['backgroundColor'] = '#FF0000';
    }
    highlight = !highlight;
  }

Fairly straightforward implementation, but it concerns itself heavily with the “how” of what its doing. Manually traversing to pick the elements it wants, eww.

//Same thing using jquery
$(&quot;ul#the_list li:odd&quot;).css(&quot;background-color&quot;, &quot;#FF0000&quot;);

jQuery is definitely magic, but this code is great because it let’s you focus on the “what” of what you are doing. How does jQuery go about selecting the right elements and all that? I don’t care, and the great thing is I don’t have to care, and if in the next version of jQuery they find a way to do it faster, I win without having to do anything.

Writing a great api is difficult, you have to divorce yourself from the concrete problem you are solving and look at it in the abstract. Put yourself into the shoes of someone trying to figure out how the api works, and then ask the questions they are going to ask.

Why do I need to build up this context thing and pass it in?
How come there isn’t a sensible default for these arguments?
What dumbass made this thing?

Answer those questions, and keep working at it, strive for elegance and consistency, because then it will be easy for people to learn and use. If your code is easy to learn and use, people are going to want to use it more, and they are going to want to tell their friends about it. Then you can get some lucrative ad campaigns with Nike because of the boffo library you write in FoxPro.

There is a more subtle lesson in all of this though. Any code you write is exposing an api to someone else. “But only I am ever going to use this code!” I hear the naysayers warming up their keyboards for the comments section. This may be true now, but the six-months-from-now-you is going to look back at the you-of-today and wonder what the hell he was thinking.

Get in the habit of making your code easy to use, and expose a nice api. This will endear you to your fellow programmers and help make maintenance easy. Strive to be that guy on the team that writes functions and classes people want to use. Make life easier for your fellow developers and even if they don’t return the favor, maybe they will take you out for a beer. People notice over time that your code is the best to work with, they internalize it, and they start to think of you as a great programmer. That’s a pretty great api to expose to the world.

philosophy — 36 Comments
22
Jan 10

hustle

That time was so much more glamorous

A realization has been dawning on me as of late, one that I’ve always known, but that is easy to forget, easy to misplace, easy to neglect. The best way to learn anything is to do it, to struggle through, to forge on, to fight and gnash teeth and curse at. There is no knowledge as highly regarded as that which you have to work for.

I’m not even particularly certain how this all came about, it seems to have been a culmination of things. I didn’t intend to but somehow I ended up putting on my plate a bunch of new stuff to learn around the same time. Git, ruby, rails, blogging, prosper, hosting my own domain, and testing (Testing being a decidedly late addition). This blog was the genesis of a lot of it, that and just being curious.

I had my first post back on October 2nd of last year, as of writing this 112 days ago. At that point I didn’t really know anything about the 7 topics above, I started the blog using Google’s Blogger platform, it was an easy onramp.

After a month or so, I was encourage by some friends to move the blog to my own domain, which you are now at. I also kicked off the prosper project around the same time as starting this blog. I played around with ruby and a crazy friend convinced me to try out rails. I moved prosper to GitHub and began learning git. Now prosper supports 19 backends and has gained over 100 unit tests in the last few days.

Here’s the kicker though, I don’t know what I’m doing. I never really did, I just started doing stuff, and have been running ever since. There have been days when I’ve gotten 5,000+ hits on this site, several days with several hundreds of hits and I’ve been steadily increasing the daily reader count. I don’t know how I did that, I just kept writing, I liked it, I promoted it over twitter and hacker news if I thought I had written something insightful, and I guess that is working. The same thing with prosper, I saw a need for something that didn’t exist, I had a vague idea of how to make it, and I started coding. I’ve rewritten and refactored it piece by piece to the point that it supports all kinds of things I never thought it would. It’s due for another architectural change after I finish these unit tests.

If there is one key thing I could convey to anyone reading this is to hustle. You will never be prepared for the things you are capable of doing. You will achieve your greatest accomplishments not by building up a grand framework of skill and then deftly creating something glorious, but by starting small and persevering in making it better and better. It is never an easy road and you will gain a grand framework of skills, but you have to push your boundaries to grow.

This came together for me last night, I was working on a rather tricky bit of rails and broke something. I hadn’t gone too far into it and so I typed rake db:rollback and git reset head --hard and was back to a working application. I stopped myself for a second and thought about what I had just done, how improbable it all was from where I was just a month ago. I then thought about what I was doing in rails, and thought about how earlier in the day I was wrapping up prosper functionality in unit tests and finding regressions, and how I would have to write some cucumber tests for what I was doing, and I realized that 112 days ago I didn’t have the vaguest idea of any of this.

I would love to put a triumphant “I’m just so damned smart and talented and handsome” paragraph here, but that’s not the case. I just steeped myself in this stuff, I worked in git daily, I read about it, watched screencasts, I bought agile web development in rails, I got design patterns in ruby, I hustled. And you can do it too, take the first step today.

The first step that you should take is to invest yourself in something non-trivially. Want to learn rails, then go buy agile web development in rails, want to learn github, move an active project out there, want to learn linux, reformat your machine so that’s all you have. You have to invest yourself, it plays a trick on your brain that makes it want to not waste that “investment” by quitting. If you can burn your boats (Hernán Cortés reference) all the better. I had no choice but to learn git or else I couldn’t keep working on my project, and as a side bonus I got the joy (and frustration) of working in git everyday.

Get out there and hustle, learn something new, do something that scares you, reach beyond your grasp.

open source / philosophy / php — No Comments
21
Jan 10

unlicense’d

Freedom has never kicked so much ass

I wrote yesterday about the importance of open source software. I got one comment saying that prosper would be awesome if it were in the public domain. Here is the comment from Arto Bendiken

Prosper looks *sweet*. It’d be awesome if Prosper indeed were in the public domain. I think such a move would make for a decisive selling point over the numerous competing PHP libraries, setting Prosper clearly apart from the herd and allowing it to be easily embedded into any new emerging PHP web frameworks.

It’s worth mentioning that a key reason that SQLite, which is in the public domain, has prospered (no pun intended) has been the fact that it can be so easily (both technically and legally speaking) embedded into any other software. The end results of technical excellence combined with singularly liberal licensing speak for themselves: http://www.sqlite.org/famous.html

I think a lot of these same benefits could come into play also in such a potentially key higher-level web app infrastructure piece as Prosper. It certainly seems that you have the technical side of things well in hand, already, so here’s hoping for a bright and prosperous future.

Well I completely agree with Arto and want to clear up any confusion about prosper and its license. Prosper was original hosted on Google Code, which requires you to choose a license, at the time I selected the MIT/X11 license based off of my belief that it was the most free. A little further down the road I saw the WTFPL – Do What The Fuck You Want To Public License and thought about switching to that. There is a bluntness to the ideal of that license that appealed to me.

The problem with the WTFPL is of course its name, I want prosper to power lots of things and that means taking into account a wider audience. While hackers and rock star programmers can easily adopt something with WTFPL, I didn’t want to be responsible for some corporation turning their back on an otherwise useful library because they were squeamish about a word in the license.

I always thought people just hated the letter C... then I found out this means no copyright

Then I found this post on Hacker News (ironically by the same Arto Bendiken) and it lead me to the Unlicense. The Unlicense is exactly what I was looking for and simple to adopt. If you go to the GitHub repo you will see that the project is now officially Unlicense’d. The 0.8 release will be the first official Unlicense’d release, and so will every release going forward. I believe in free and open source software and so I’m publicly declaring now that prosper will always be free, open source, and unencumbered. The mechanism that I will use to ensure this going forward will be Unlicense.

What’s the big deal, plenty of things are open source, why is this any different? The difference is that I’m giving this away fully, without any restrictions. Want to build a cool new library that uses prosper as the low-level database abstraction layer, go for it. Want to build a proprietary ORM that utilizes prosper, go for it. Want to repackage prosper and try to sell it (as underhanded as that is), go for it. Want to smother prosper with jam and eat it, if you can find a way to, go for it. Want to…. enough already, you can do whatever you like.

It is easy to talk about things like freedom and support them in the abstract, it becomes more difficult when you have something concrete. People could very well take prosper and take it in directions I don’t care to see it go, but that is life, that is creation, that is the essence of open source. It is my goal to see prosper provide a solid foundation for building new and better tools and frameworks in php. I want as many people as possible to use it, and so this was a logical choice.

The next time you have some useful chunk of code lying around and you want to give it to the public domain for the good of the public, think about using Unlicense. I can’t say it any better than they can so I will just quote their section about why you should use Unlicense. “Because you have more important things to do than enriching lawyers or imposing petty restrictions on users of your code.”

open source / unit test — 3 Comments
20
Jan 10

open source

insert stupid star wars pun here

I’ve been getting into the guts of the SimpleTest trying to make it bend to my will. So far I’ve been pleased with the framework, I’ve been able to set up a testing structure that works for me. To understand the testing structure better you need to know a little about prosper’s structure.

Prosper uses a classic adapter pattern to handle the different backends it supports, so it has a directory structure similar to the following

Query.php
Adapters/

BaseAdapter.php
PreparedAdapter.php
MySqlAdapter.php
etc…

Since I wanted the unit tests structure to make some sense I decided that there should be one point of entry that I could run to test every adapter and then entry points for each adapter individually. I ended up with a test structure like so.

All Tests (Suite)

MySQL Tests (Suite)

Select Statements
Insert Statements
etc…

Oracle Tests (Suite)

Select Statements
Insert Statements
etc…

etc…

All my tests pass but its just so boring

This structure is working nicely and now I get to have the fun of writing hundreds and hundreds of unit tests, it really puts into perspective the shear size and scope that prosper has grown into. The next thing though was that I wanted beautiful results. If I was going to have to look at these things all day, I wanted them to caress my eyeballs and make them feel all warm and fuzzy.

SimpleTest (like all PHP code) is open source and even has a way to extend the reporters, although its easier said than done. I fired up my favorite php editor and got down to work rewriting the HtmlReporter class so that the results were more to my liking. It was not the easiest task, but there is some ok documentation about it and the names were all fairly sensible. I hacked away at it, changing a little bit here or there and then finally decided to just scrap what they had wrote and redo most of it. It took some time to get everything squared away but with some inspiration …cough…blatent theft…cough… from QUnit, I was able to make the following.

such hotness! unit tests have never looked so good

This is why I love open source so much, I wasn’t stuck wishing that this thing looked better, I didn’t have to resort to some sort of greasemonkey magic, I was able to fundamentally alter simpletest by changing the code. This is also why prosper is released under the MIT License, although recently I’ve been thinking about moving it to the Unlicense. I want people to be able to fix bugs, play around and change things, and ultimately make prosper a better tool.

Right now there are some Prosper specific hacks going on in the new reporter I wrote and its only been tested in Firefox, since its what I develop in when I’m on windows. I plan on cleaning up the code a bit and then submitting a patch to SimpleTest containing my new QHtmlReporter. This is part of being a good open source citizen, you can reap the benefits but then you should also try to pay it forward or back.

Open source software is empowering, not only in what it can do, but how it empowers the users to make them better. I’m going to continue writing up unit tests and with this awesome new display, my eyes will be happy to watch the results scroll by.

unit test — 1 Comment
19
Jan 10

unit test

How much time did I spend looking at this instead of typing tutor in elementary school

I’ve read the blog posts, heard the speeches, seen the tweets about unit testing. At a conceptual level I understand, you should unit test because then when you make changes you can find regressions easier. I’ve even heard the TDD people beating their drum about how I should never write code without tests. I get it, it sounds really good, and here is the dirty secret, I don’t do it.

For those of you who have continued reading don’t worry this isn’t another volley in the war between TDDers and non-TDDers, this is about why I couldn’t wrap my head around testing, and how I finally did, and where I am now. I hope that if you are in the same place I was, you agree that the idea of testing is really good, but can’t figure out how to incorporate it yet, that this post might help you. I’m also going to take you down memory lane a little bit, but there is some good knowledge about a cool PHP testing framework in here, you can skip to it, if you like.

I grew up in a little house just outside of Cleveland, Ohio with an incredibly warm and caring family. There were 4 boys, my mom, and my dad. There was never much money around, but I never realized that this was such a bad thing, I had what I needed and a little something more, a computer donated to us by my Uncle Marty. The computer was a magical thing at first, I was 5 or 6 when it arrived in our house, an old black and green with less RAM than the Rockstar energy drink I’m sipping on right now. You could put in 5.25in floppies and play Dungeons & Dragons, Hitchhiker’s Guide to the Galaxy, or some weird Submarine Game. You could do something else though too, if you put in a blank disc you could make your own game. My uncle showed me the basics of BASIC and my school library had a book filled with BASIC code that could make egg drop games and even a star trek rip off. I was hooked.

Oh those halcyon days, you were all I needed dosshell

As I became a slightly older lad, still around 8 or 9, we had another family donation. This time my Uncle Bob had upgraded their family computer, and so we got the old one. This one was a marvel though, it had colors and could even go online. It had windows 3.0, although it was really just this odd thing we fired up from time to time to play in, we spent most of our time in dos shell or on the command line. I wondered if this computer had BASIC, and I found QBasic.

QBasic was were I really started programming, although the current programmer in me wants to throw up reading that sentence. I was no longer just copying code out of a book and making changes here or there, I was coming up with new ideas and figuring out as I went along. The built-in help system coupled with fairly readable error messages and a tightly integrated run time made learning easy and accessible to me. I would code stuff up and give it a go, I didn’t realize that I was running an interpreter or had any idea what a compiler was, I would just develop and try it out. It was my REPL, although much more manual.

I moved from there for a short time to Visual Basic, and then at BGSU to C and C++. The C languages seemed so onerous to me at first, there was this lengthy compile step, I had to declare everything, there was odd punctuation floating about. But I got used to it, and became fairly proficient in it. Towards the end of my time at BGSU I took a job with the University fixing computers for RCC and from that job joined a team of PHP programmers.

Something felt familiar and comfortable about PHP development, I would just type some stuff and refresh the browser, immediate feedback. That’s when I realized how my brain was set up, wired from the radiation of that old green and black monitor, I wanted to develop in quick insanely small iterations. Change this or that and test it out. Toss in an echo here or there to see the state and make decisions based off of that. It was always more structured than I’m making it out to be here, but the structure was there to support this notion of Rapid Application Development.

To this day I still find myself more comfortable building something new by getting the simplest thing that could possibly work (Minimum Viable Product) up and running and then doing iterations over it again and again, polishing it up. When I coupled this strategy with really aggressive refactoring I was able to produce some cool stuff, complex reporting architectures for clients, constricted language parsers, bytecode compilers, and to a large degree prosper.

Thank you creepily fake referee man for illustrating my point

Testing though seemed like a great idea, TDD seems like a nice way to write code, tell me what you are going to do, then do it. Makes sense. I tried to do some unit testing but had some false starts. I tried to do it with some Java code, wrote up a jUnit test, ran it with an ant task and it told me everything was cool beans. Did a few more and then couldn’t figure out what the point was, I was testing things I knew had to work, if variable assignment stops working in the JVM then my unit tests aren’t going to make a difference. Then I worked on 2 small projects that were Test Driven and they both hampered development so much that the project either failed or I quit altogether from it. My innocence had been dashed and now the thought of TDD left a sour taste in my mouth.

I had secretly hoped that like pair programming, scrums, and kanban boards this would be another good idea from agile that would have its time and then quietly be swept aside as impractical (of course I’m not saying these things are impractical, just that none of the enterprise shops I’ve worked at cared about them at all). After CodeMash I realized that these things weren’t going away, so I redoubled my efforts to learn them and that brings us to today. (That was a long and weird trip if you read through it instead of just clicking the “skip that stuff” link, thanks!)

SimpleTest

It’s all about tools. I’ve tried various testing frameworks in Java and .Net but never found something that fit in with my workflow. I sat down at the Oracle of All Knowledge (Google) and started looking for a unit testing framework for PHP. Then I found SimpleTest, the name immediately drew me in. It was exactly what I was looking for, something simple I could use to write unit tests with. I went through the tutorials and figured it all out and it was exactly what I wanted, I could write up my tests and then just point my browser at http://whatever/tests/all.php and it would generate a cool webpage telling me exactly how my tests are doing. I was converted.

I’m making some fairly big architectural changes to the internals of Prosper for the next release (0.8) and have decided that part of the effort is going to be wrapping stuff up in unit tests, lots and lots and lots of unit tests. This is my first go on unit testing so I’m certain I will get some things wrong, but I’m hoping to learn a lot, and you can play at home and tell me what an idiot I’m being.

At the end of the day I’m beginning to move from, tests are cool but I don’t test, to tests are cool and I’m learning how to do it. I’ve been down this road before with git and ruby and rails, its frustrating but worth it. SimpleTest is really cool, but I’m still finding my way through it, I’m writing a new output printer inspired by John Resig’s QUnit and will release the code for that soon. Once I have a workflow and test directory structure I like I plan on producing a series of posts. You can find them because I plan on tagging them all with “Dr. SimpleTest or: How I Learned to Stop Worrying and Love the Test”

work — No Comments
18
Jan 10

codemash review

Colonel Whiskers and I have both missed you dearly

You may have noticed that I have not posted anything since last Tuesday, gasp! Fear not, although various shadow organizations are still after me, I was not captured. I had the awesome opportunity to go to CodeMash, and spent most of last week in the beautiful Kalahari Resort in Sandusky, Ohio.

CodeMash, for those of you not in the know, is a pretty cool event. Instead of focusing on one technology (.Net or Ruby on Rails for instance), there are tons of sessions spanning the technology spectrum. Want to learn about ruby, there is something for you, F#, got it covered, Clojure, for goodness sake they even did a lisp. The great thing about this style of conference is that you can pick and choose whatever interests you, nibbling on concepts here and there to get a bit of everything, or really chowing down on one topic.

The other cool thing is that the company I work for HMB is forward thinking enough to not only sponsor CodeMash, but to send me there for free! Then the big topper came last month when they asked me to present on prosper.

Well now it is all over and I can give you a rundown of how things went.

The Good

Kalahari – The Resort is beautiful, the rooms are huge, the staff is excellent. It is a really cool place to spend some time in, they served us some great food, and the facilities were excellent in their range, rooms small enough for a handful of people to collaborate in, all the way up to grand dining halls to house the 800 or so attendees.
Keynotes – Mary Poppendieck gave a great talk on Lean Software Development, Hank Janssen talked about how Microsoft is moving into the Open Source world, and Andy Hunt, co-founder of Pragmatic Bookshelf and author of the Pragmatic Programmer, gave an amusing talk on the Mother of all Bugs, our brains.
Prosper Talk – After weeks of preparing and fretting over my presentation I think it went well, there were some technical difficulties, but nothing that could stop the incredible power of Prosper!
Session Leaders – The people leading the sessions don’t get paid, they do it out of love of software development, and it shows.

The Bad

Superficiality – Sessions are only an hour long, this means that no matter how great the sessions are they can’t really get into the guts of anything in any kind of depth.
Beginner Overlap – I went to a lot of Ruby sessions, as that is my current love, and even as a n00b it became tiring to hear the 5th explanation of duck-typing for the day.
Kalahari is way too big – I’m just kidding about this one, but it was honestly about a 2 mile hike from the convention floor to my room.

What’s Hot

Ruby – Ruby is blowing up, not just rails anymore. Rails did a great job of introducing the world to the quirky little language that could. Now innovations are being made inside the Ruby community and people are starting to port that out to the rest of the software world. (See the next point)
TDD and BDD – Test Driven Development and even moreso Behavior Driven Development are becoming huge and are here to stay for the Agile practitioners among us. A big driving force for BDD is Cucumber.
Cloud and NoSQL – I’m lumping these two together because they are both technologies at scale. Virtual infrastructure is becoming a big business, be it Amazon’s EC2, Microsoft’s Azure, or Rail’s Heroku. Applications running at huge scales are also turning to NoSQL storage solutions.

The Point

CodeMash is a chance to meet really cool people how are excited about technology. It’s a chance to get exposed to a ton of cool technology. It is a chance to try a bunch of cool stuff and see what you like. Sessions are only an hour long so at worst you end up wasting 60 minutes, at best you get fired up on something wonderful. You get to meet a lot of cool people, here some great talks, and best of all you are at a gorgeous indoor water park that is 84 degrees when its freezing out in the harsh wasteland of Ohio.

ihumanableusable in any place a human can be used

January, 2010

learn autoit

The Good

The Bad

Alternatives

Conclusion

ipad

objective measure

when in rome

api

hustle

unlicense’d

open source

unit test

SimpleTest

codemash review

The Good

The Bad

What’s Hot

The Point

Archives

Categories