mult.ifario.us

Go shopping.

Seriously — go shopping. A downturn is a great time pick up office furniture, computers, phones, and even employees on the cheap from less fortunate companies. Unless, of course, you're in a tight spot for cash, in which case my advice would be to avoid that situation...

Duncan Coutts posted some slides from ICFP about the developing Haskell platform — a set of "known good" and well-maintained libraries — and it is indeed on its way. (Compare with the "batteries included" effort for OCaml.) Here's the stack from slide 13:

It's not in the charter for the Haskell Platform to make general improvements to Hackage, but looking at the stack diagram I couldn't help but thing about a comparison against a language stack like Java (JDK, Maven, Codehaus, JCP) or Ruby (C ruby, rake, RubyGems, RubyForge) instead of Linux. Quality, collaboration, and liveness are important aspects to assess for a project, but that's next to impossible without publicly accessible (and relatively standardized) bug tracking, source control, and discussion. (Things like continuous integration are niceties but provide somewhat lower utility than the big three I just mentioned.) With 754 libraries, there's a lot of meat and a lot of mystery that's impossible to assess at a glance from the current HackageDB package list web interface. The "heuristic" requirements for libraries in the Haskell platform does include a bug tracker and good basic hygeine (build portably with standard tools, proper releases, maintainer), but it's missing those other touchpoints.

Lest I be perceived as casting stones, my experience is that even in the current circumstances and in spite of the lack of visibility, the Haskell community is vibrant and active. The Cafe and IRC are bustling, and troll-free and flame-free with very rare exceptions. Community leaders are friendly and approachable. Where I've found issues with libraries (resource leak in HTTP, QName equality bug in HXT, attribute qualification issue in "light" xml), maintainers have been helpful and receptive. It would be even better if it was straightforward to collaborate with other users on dedicated mailing lists, post or consume bug fixes via darcs or git branches (the good kind of fork), and track updates. (Use of distributed VCS tools like Darcs and git exponentially increases the utility of a publicly available project VCS.) There is no reason that this should be limited to just a blessed core, as it will help in the growth and refinement of other libraries as well. Posting to Hackage should entail the creation of a mailing list, the provisioning of a bug tracker, and either a check-in of the source for the posted library to a central repository or a reference to a publicly available git or darcs repository.

More than most and less than some, I appreciate the difficulties in providing community infrastructure, having observed Bob and Ben in action at the Haus and watched a top-level project at Apache (ODE) from proposal through graduation. I also appreciate the role of the infrastructure in creating and reinforcing community — it's no accident that a fair proportion of the most widely used open souce libraries on the Java platform have grown either at Apache or at the Codehaus.

Reading some coverage of the Republicon convention and seeing pictures of Bush on the big screen brought to mind the classic Apple 1984 ad, and the following visual analogy is obvious:

For what it's worth, I've never felt much of an affinity for either party, and while I voted American last election (i.e., against Bush), I can understand how people might identify with what Bush said. I just can't understand how anyone could support what he did.

With GHC switching from darcs to git, I decided to move perpubplat over to git (and specifically to github) as well. (For the reasons that GHC decided to move, see this wiki page.) The new landing page for the perpubplat repository is here.

At least if you've already got git, GHC 6.8.3, and cabal-install, building perpubplat is about as simple as it can get:

$ git clone git://github.com/prb/perpubplat.git
$ cd perpubplat
$ cabal install

As far as near-future feature development, I'll be adding github activity feeds to "stream of consciousness" aggregation and improving the configuration and control of aggregation in general.

I like Fantastic Contraption because solving the puzzles requires a fundamental type of cleverness, intuition, and experimentalism.

Something like Fantastic Contraption — but not Fantastic Contraption because everyone and their dog has played it at this point — would make an interesting adjunct to the traditional battery of questions in engineering interviews. (Yes, I saw Last Starfighter once upon a time. No, not in the theater.) The usual questions about data structures, algorithms, tools/practices, and design do a reasonable job of filtering candidates, but it can be like chewing a mouthful of saltine crackers for the interviewers after the N^th time through. A game might make it a bit more fun for folks on both sides of the table.

I can understand how people get confused with RSS since what passes for a specification isn't exactly precise, but the Atom syndication spec (a.k.a. RFC 4287) is nice work and comes with an unambiguous RelaxNG grammar. Which is why I find this (sent by a friend who reads this blog in Google Reader) irritating:

This is wrong. (For what it's worth, this doesn't happen for me in Google Reader running in Firefox 3.0.1.) Extracting a bit of the grammar, the title of the feed is an atom:title element, and XHTML content is supported:

atomTitle = element atom:title { atomTextConstruct }

anyXHTML = element xhtml:* {
   (attribute * { text }
    | text
    | anyXHTML)*
}

atomPlainTextConstruct =
   atomCommonAttributes,
   attribute type { "text" | "html" }?,
   text

atomXHTMLTextConstruct =
   atomCommonAttributes,
   attribute type { "xhtml" },
   xhtmlDiv

atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

xhtmlDiv = element xhtml:div {
   (attribute * { text }
    | text
    | anyXHTML)*
}

So the construct from my feed is valid:

<title type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">mult.ifario.us - All Posts</div>
</title>

I spent time with the excellent and useful Feed Validator when I was writing perpubplat, even compromising on things that I felt I shouldn't have to compromise on, e.g., namespace prefixes, in the name of interoperability. The validator awards the feed a squeaky clean bill of health. Nonetheless, this issue makes my feed ugly in Google Reader, since the UI shows an abbreviation like <div xmlns="... in the sidebar and elsewhere. (FWIW, this Google Reader issue isn't caught by the title conformance tests.)

I've posted a bug in the relevant Google Group here.

Matt Hulett's post about low water marks for startups provoked some pondering for me. My metric was always twelve months, but there are different considerations for a going concern versus a startup.

For the going concern (i.e., a business whose goal is to operate profitably and grow organically), reserves on the order of full operational expenses for two or three full sales cycles is reasonable. (This strongly depends on the complexity of the product and the deal size.) I'm defining a sales cycle as the length of time between when a piece of marketing hits a prospect to the time the money from that prospect (now customer) hits the bank. Failure to acknowledge the full cycle will kill you if you're on the razor's edge. For example, it's a reasonable three months from a signed deal to a signed check — close the sale, a month to deliver, a month for the customer to pay, a month for your AR to hound their AP, and you're ninety days from dotted line to dollars. Three sales cycles gives the business enough time to adjust to significant external events (most recent reasonable example would be 9/11), to respond to the entry of new competitors into the market, or to launch new products or extensions.

For the startup (i.e., a business whose profitability depends on significant growth and attendant capital consumption), reserves of twelve months is running on the metal. The business needs to be executing to its goals as the funding search is happening and then continue to execute as the funding process completes. (Ongoing execution is more important for later stage companies, as investors don't expect it from early stage companies.) A good rule of thumb is that reserves should account for hitting goals sufficient (on a hypothetical level) for the next round of investment, plus a margin of error for unforeseen issues, plus six months of runway to get funding done.

In either case, interim milestones at fixed dates and specific, measurable goals are essential. Are the initial stages or the marketing and sales pipeline working? Is product development on schedule? Is hiring and retention running to plan? Are your partners coming through? Is the investment climate or business climate changing? This is one situation where it's good to be a little obsessive — cobble together a simple dashboard and mark progress to plan no less than weekly. (The dashboard task has gotten simpler over the years; these days that can be a combination of QuickBooks, Google Analytics, SalesForce.com, and something like Jira or Rally for tracking product progress.) Make yourself accountable (e.g., to your management team and to your board) and hold your management team accountable for their individual goals because failure for one is failure for all when cash is a constraint.