Monday, September 20, 2010

Quips from the Mythbusters

Adam Savage and Jamie Hyneman came to the area and were interviewed by a local science professor yesterday. A few things they said stuck out. One was that most of the important stuff that happens on the show begins before shooting starts, in their "brain" session. That's where they get together, sort through the myths, and lay out the overall plan for the season and how they'll approach each myth they plan on tackling. Jamie said it was the high point of the process. It reminded me of the way I've seen really good Agile developers work.

I tend to imagine a lot, and sometimes to over-invest my own time in puzzling over things I can't fix. That related to another quip from Jamie -- he mentioned that when they come upon a myth and get stuck on how they would approach it, they put it on the back burner. Again, this is a pattern I've observed in the Agile shop. If you are not making fast progress anyway, procrastination is the better part of valor. Best to expend your effort in an area that will pay back, and push the problem onto a visible project backlog.

One other thing they both mentioned was that they had been jacks of all trades but masters of none. Jamie holds a degree in Russian language. Basically, they go forward and do stuff, regardless of how much they know. In one sense, this is also Agile -- they don't concern themselves about what they don't know, but they try anyway. It also explains their often overly naive approach to science and engineering too though: in some ways they are illiterate enough to reinvent the wheel. They get paid to serve their own sense of curiosity, so why should they bother to think things through?  Serving ones' self may be common among programmers too, but I don't think it is something an ethical engineer should value too highly.

One final thought: Mythbusters is mostly entertainment. While it may be good public relations for S.T.E.M. geeks and nerds, Jamie mentioned how they have also been doing "real world" applications like personnel armor, studying blast effects. Adam mentioned how the "bullet fired up into the air" episode added something new to the scientific literature on the otherwise ignored subject, and how it mean a lot to him. That sense of direction, of serving a purposeful and substantive long term process, is a value that seems curiously missing from many journeymen programmers and expert Agile practitioners alike.

Sunday, September 19, 2010

POSTFIX is not an email client

Why in the world would one want to use Postfix or Sendmail for simply sending an email from a program on OS X?

I wanted to write a shell script to send an email to blogger, to make it trivial to blog stray thoughts and questions while programming. Simple right? But one of the most common responses is to suggest setting up Postfix.

That's just plain dumb. On SnowLeopard, as in other UNIXes, shell scripts and other programs usually rely upon a mail daemon to do the work of managing emails.  But why use a 500 pound gorilla to do the work of a 5 ounce lemur ?

Postfix is a clone of sendmail, which is one of the worst practical jokes committed by graduate students upon the rest of computing humanity. Whereas it is trivial to set up, for instance, a Thunderbird account to send email, using Postfix makes the process unnecessarily complicated. The fact that I want to send email from a shell script is not relevant: installing Postfix is neither necessary nor sufficent.  Given the amount of contextual information that needs to be discovered and mapped to configuration settings, one quickly realizes that choosing to use a solution like Postfix imposes external dependencies that can drown you in gratuitous details.

It turns out that Postfix is not configured to run on OS X.  So here's what you do to get it up and running:

Edit the daemon config and tell it to start on load:
$ sudo vi /System/Library/LaunchDaemons/org.postfix.master.plist`


Then change your /etc/postfix/ to relay through your ISP's mail server:
sudo vi /etc/postfix/
mydomain =
myorigin = $mydomain
relayhost =

Now reboot or start postfix manually:
$ sudo postfix stop
$ sudo postfix start

Even after setting it up, my mail still wasn't getting out. The mail log said the messages were being sent, but they were not getting delivered. A little later, a message showed up in my local account inbox. By the by, the shell reminds me of this little fact -- I would not know had I not been using a command line shell. But I don't actually _want_ to have local mail enabled at the UNIX level. Doing so presents many more opportunities for abuse, and hassles with keeping another daemon going when other software is updated. 

The problem seems to be that the RoadRunner SMTP server requires a valid username and password to be used when sending mail. So I hacked the file to specify that "" is my machine name, and rely upon the accidental fact that my username is the same as my email account name. I don't even know if it is possible to manage Postfix accounts separately and distinctly from the local UNIX system accounts.

In general, Postfix makes a very crappy email client: it is WAY too much software for simply sending mail and doesn't provide a simple and secure means of specifying email names and passwords for senders, independent of their local user account. I don't need a full blown, general purpose email server. I just need to connect to my SMTP host to send a mail.

Anyway, it is working for the moment, but choosing to try Postfix cost me valuable time.  A better alternative would have been a scripting language like Python or Ruby, but I like not having shell scripts without dependencies on other scripting languages... and sometimes even the libraries rely upon postfix or sendmail for sending email. Another option is to use another utility to connect directly to the SMTP port, and force feed an SMTP message directly through the system. That approach would be low level, but that would have fewer external dependencies.

I like the word Performant

I am thinking of a Web site and one of the names I thought could work was "Performant". That's one of those words that sounds like it was made up by someone who didn't have words like "efficient" or "better" in their vocabulary. Note that despite its adoption as a jargon adjective, it also a noun meaning a person who perform [a ritual]. I thought, well, I could start by making a blogger blog about the concept... 
it's always better to reset expectations instead of taking on risk
But someone already has the blog under the name "Performant" on blogger. He has some interesting entries. The quote above is one which caught my eye, since I catch myself so often ignoring the aphorism. Check out the Performant blog

Saturday, September 18, 2010

To Be or Not To Be, That is The Question

So, a week ago I began working with a small but expert software development shop, after a project turned out to be more complicated than I could handle on my own. Rather than look at it as a project I would manage and run, I decided to look at it as an opportunity to learn and serve. I've been too far out of the loop for too long to do anything else, and my anxiety level kept spiking whenever I thought about how to get from start to finish. While I could have continued, and floundered until I got something done, the client wouldn't have been as well served... and I would have wasted a lot of time trying to discern good models of behavior from ineffective practices.

Distinguishing poor practices from effective ones is not impossible when working alone, but it is thereby made much harder than it need be.  A common occurrence in the office this week was for one of the senior developers to peek over the corner of the panel display, to ask one of the more junior developers about some quirk of syntax or change in library semantics. Kids like to play with the new tools, and in doing so they pick up the idiosyncrasies quickly - so when those idiosyncrasies change they are among the first to know.  But more to the point, trying to grind through such a question alone could be a 30 minute book-and-google-forum-search ordeal,  where asking the kid nearby usually amounts to time to fix in the 30 second range. That's about a 60:1 reduction, and over the course of a day that can really add up.

This week made me rethink about programming as a credible practice, as opposed to virtual work slavery. The office environment has a paced feel, not at all rushed or high strung. That in itself is worth emulating, but they get measurable work accomplished each day too. Sometimes the movement forward felt slow and short, but it was there, and the codebase is increasing both in size and in functionality. Also, testing is done as a necessary and sufficient flow of work, not as a bolt-on adjunct that one jettisons at the least bit of anxiety about deliverable dates. All in all, it was a much more humane way of working.

Despite that, there were things that felt oddly off, as if they could be working better. The pace of functionality addition seemed exceptionally slow. Perhaps that was because we were also changing significant parts of the technology stack: Ruby on Rails 3 was new and the RSpec test patterns were being updated. Perhaps too, because my own pace in this new language and environment means that I'm more of a distraction than anything else. I hope to do some catch-up this week-end on the crude syntax and basic patterns, and contribute more next week.

Another thing that is odd about the Behavior Driven Development is that the practitioners I've come into contact with measure the problem domain with an overly crude and imprecise rule. As if one were to start out deliberately measuring the coast with a 3000 mile long ruler, then with a 2900 mile long ruler (and make refinements), 2800 miles, and so on, until the measurements are made with a ruler short enough that the stakeholders no longer complain about the differences. The development process breaks the narrative down and reforms it as if the scenarios were the steps of an iterated fractal.  I can see now how B.D.D. promotes a focus on just the relevant functionality and eventually leads to just enough precision in practice. Still, it seems like it would be a little more efficient to start with the ruler slightly closer to the final size, or at least halfway there again, than to start with the most vague notions.  I suppose that is a matter of experience and judgment.

Finally, I'm liking what I've seen thus far. For whatever flaws it has, Ruby is a rational development environment that successfully promotes the rapid application methods that seem so completely squandered on the Java stack. The developers cooperate with each other, work hard, and still have time to jibe one another respectfully. They communicate with each other with and apparent honesty and openness that is rare to see in a professional environment. I don't know how long this will last, but I will pick up good experience as long as I'm able to do so.
I am starting a git port of the scripts I originally created for Tom Lord's Arch, the tool that let the cat out of the bag for distributed scm.  Tom's command interfaces were verbose but uniform, enough so that it made sense to curry the arguments by way of shell functions set in the environment startup scripts. That strategy morphed into my Setview package, which mocks a workflow similar to that of the ClearCase command of the same name. The idea is that even if the SCM is distributed and can be cloned anywhere, you can benefit from organizing the common contextual information for your working projects, and injecting that context into a sort of sandboxed shell environment just when you want to do work on a given project.

Additionally, I've started setting up a snippets library using DropBox. I'll bootstrap it with scripts and snippets from past projects, organized at the top level into language (Javascript, CSS, Ruby) or language-library (Prototype, Rails) folders. The nifty thing about DropBox is that it is easily large enough for language snippets, accessible from my laptops, versioned without requiring an SCM, and can be shared to guests. An alternative would be to use a distributed scm service like GitHub.

It might be neat to combine the two ideas, and have Setview bind accessor methods for the snippets library to the view environment. Or perhaps better as a VIM plugin.

A few new tools

Following up on a previous post, here are a few of the other tools I've actually installed or started using:
  • The built-in iChat client. We use this to quickly send files around, rather than a network share. I like DropBox as an internet enabled network share alternative, but then you get into questions of "Do I really want to share the rest of the stuff in that folder?" or "where do I put this?" and cleaning up the extra copies after. With an IM client, you simply toss a file over the wall and hope someone catches it, then forget about it. No more futzing with file shares.
  • Teleport. Allows you to set up shared desktop/keboard/mouse sessions for pair programming. Pretty cool, except that my mouse kept accidentally wandering too close to the edge of the screen and stealing focus.
  • MySequelPro. Nifty control panel for MySQL.  When I look at RSpec for RoR 3, I immediately wondered why there isn't something like MySequelPro for configuring RSpec tests.... something that lists selectable options so you aren't constantly wondering what is really available. Anyway, it looks neat.
  • MacVim Ruby On Rails plugin. Turn VIM into a lightweight Rails integrated development environment. 

Tuesday, September 14, 2010

Tools mentioned at the Web Design Meetup

If you didn't attend the Raleigh Durham Web Design Meetup, well, that's pretty tough, because we had a good conversation tonight about our favorite tools. Steve Hong of Crosscomm, who is also an assistant organizer for the Meetup, moderated the meeting That was great, both because Steve is a real leader and because I've been somewhat distracted lately by work issues.

Just to tantalize you, here are some of the tools and services that came up during the discussion. If you feel like you would have liked to have a transcript, look on our home for Steve's webcast of the meeting.

HTML EditorsTextmate
Coda Editor

Services to Facilitate SEO
Pixeltype (better than hootsuite)
Google's url shortener

Theme Design and Slicing

Light CMS's
Cushy CMS

Forms Generator
Phil Taylor's Blue Forms

Browser Testing
Adobe Browser Labs
Chrome (for its leading Webkit developer features)

Surreptitious monitoring for usability

Survey tools
Constant contact

DropBox -- coolest thing ever, freemium model, for mirroring files between your servers and pcs 
BeanStalk subversion client

Saturday, September 11, 2010

Apps on my Apple: Software Provisions for a MacBook Pro

I just got a MacBook Pro after years of suffering under a Windows IBM clone regime.  So here's what I'm installing, and a little bit about why:
  • XCode
    You need the Apple development kit to do much anything useful on the Mac. I would have installed it anyway, but MacPorts required it. 
  • RVM
    This is a cool tool that lets you install multiple Ruby versions and configure independent sets of GEMS libraries (importantly, including gems like Rails) to run without mucking around with environmental variables or re-installing. Kind of like the WAMP systems for Rails development, only better.  
  • MacPorts
    • MacVim
      Emacs users, I respect you. I just don't like Emacs. 
    • GIT
      This was actually used to install RVM, but I expect it to be generally useful for accessing other repositories.
    • GitX
      A Git GUI for the Mac. 
  • Update! One day into working on a new software team, it looks like MacPorts is "out" and Homebrew is "in".  I'll switch now, since I don't have much invested in MacPorts installs. 
    • Unfortunately Homebrew is fairly new and some of the MacPorts packages are not yet available. So uninstalling MacPorts also took out GitX. 
  • Skype
  • I like Skype. I use it for chat, for voice chat, and when I'm away from a land line phone (or my wife is using it) I use skype credit to make calls. 
  • Pomodoro
    A task tracking utility aligned with the Pomodoro time management technique. A Pomodoro is a 25 minute focused and unbroken work activity, followed by a 5 minute break, with guidelines for handling interruptions. The intent is to help people get less anxious about time pressure, and into flow modes more easily.  
  • CleanApp
    For $15, this daemon will watch apps you install and help you clean up their crufty trails when you decide to uninstall them. Also the idea of freeze-drying an old disused app has some appeal.
  • Quicksilver
    Looks like a great way to avoid hunting for that right app, folder, or document icon to open. But notice that I installed it after CleanApp. Will hope it works as good as the reviews. 
Planned or Suggested by others:
I haven't had time to look or buy these, but I've heard they are pretty slick:
  • OmniGraffle
    The ultimate graphic object design software. I hear it is better than Visio, but I have been using Inkscape instead... I know it is lower level software, but it was free.   
  • Parallels
  • Like VMWare Fusion, except it blows the pants off of Fusion in terms of graphic performance. Again, I had been using VirtualBox on the PC, and I have working PCs, and since Mac OSX is BSD based I'm not sure I need to emulate Linux on this box. Except maybe for sandboxing apps I want to play with but not install directly. 
  • oXygen XML
    I just like this tool for cleaning up markup, validating CSS, and doing schema work. However, lately I've been trying to get back into real applications development work, and haven't actually needed it. 
  • Firefox, Chrome, Opera
    Just gotta have other browsers, if for no other reason than to shun Internet Explorer. 
  • Nice graphical sFTP/ssh client.  (Filezilla? Putty? Cyberduck? Forklift?)
  • Will probably need an SVN client and GUI too. 
  • Zip/archiving client, if the Mac built in functionality is not enough.
  • CD Burning client
  • Backup process
Sounds Interesting

  • RooSwitch
    Set up separate profiles for running applications. I like the idea of compartmentalizing the data for each user's usage of a particular application. Not sure if the implementation is general enough. 
  • TextExpander
    I like the idea of building a library of useful code snippets. I like the idea even more of working in an environment stable enough that such a library is practically useful to create and maintain.
  • Cocktail. Mac settings all in one place with added disk and system utilities. 

Wondering About
  • AppFresh. Will it play nice with CleanApp and Homebrew ? 
  • OpenOffice. Nobody, but NOBODY in the blogs talking about Mac software mentioned OpenOffice. Not even a little.  I don't want to fork over $$$ for yet another copy of MS Office though. I hear NeoOffice is pretty slow too. There is always Google Docs...
  • Gimp. Everyone who is serious about graphical design work uses Adobe. Also, Gimp is still stuck in the 8 bit world. Wondering of Photoshop Expressions 
  • Aptana/Eclipse. Tried on the PC platform. Not so sure I want the tons of dead weight overburden that comes along with any Eclipse based IDE.  Seems rather stupid to put up with it. RadRails at least seemed worthwhile though. 
  • Things. The idea of using a task manager is interesting, but never seems to coalesce into an effective practice, outside of a team environment. 

Tuesday, September 7, 2010

Sencha Touch: Not Ready For Prime Time

After a week of trying to push Sencha Touch to do some very simple UI tasks, I have to conclude that it just is not ready for playing, let alone production work.

The worst part of Sencha is that the API documentation overlaps with ExtJS so much, yet is different enough that sample code for ExtJS doesn't just work.  So the normal trial and error of using forums and blog postings to supplement docs is made that much more ineffective.

I'd like to say Sencha Touch shows promise, but I can't.

It isn't just the grinding I've done finding so much conflicting info and dead-end paths.

It isn't just the incomplete, apparently untested code that belches "undefined" error messages for documented methods and properties .

The API just doesn't make simple things simple and difficult things straightforward.

At least for now it does not appear that there are clear idioms guiding how various hooks and extensions are accomplished. Maybe after the dust settles from the on-going development it will be a consistent and clear API. But for the moment, as of September 2010, Sencha Touch is more of an interesting experiment - or an annoying one, depending upon how much you took for granted the stability and soundness of the code.