Archive for the ‘Uncategorized’ Category

Unseen Constraints

Friday, June 26th, 2009

I picked back up a project for a friend. It’s a decidedly non-spiffy business-logic sort of problem, which makes it hard to keep focus on outside of a work environment, but it’s something that would make a world of difference to her.

I decided to use WPF, because I haven’t done anything other than trivial exercises with that technology. We’d talked about platform (Windows XP) and whether she was allowed to install stuff on the work computer (yes).

I decided, and got her agreement, to send her very frequent releases. In addition to all the usual reasons to do this, I thought it would be a good mechanism for keeping my focus on the problem. I started with the smallest possible release: a program that opened a window, installed by an installer.

Almost immediately, we hit a bump: I’d expected to need to upgrade the version of .NET on her computer to 3.5. I hadn’t realized that, since it was also the only cash register, the computer could not be rebooted during the work day. Downgrading the technology used would not be fun, since the computer had no versions of .NET whatsoever. The next few work days were going to be long ones, so she had no interest in sitting in the store with me for an extra hour after her shift was over, nor could she leave me in the store alone to do the installation.

We’re completely changing the technology stack and going with a Web-based solution. Total time lost, between making the first release and researching the no-reboot issue: one hour. Woohoo!

Project Euler

Monday, June 15th, 2009

I’ve known about Project Euler for a while, but I made the mistake of trying to use it as a vehicle to learn F#. Last week I started solving the problems with Haskell, which is vastly more fun. I highly recommend this method of recreation.

Also, this is officially the best-ever method of Fibonacci-number computation: fibs = 0 : 1 : (zipWith (\a b -> a + b) fibs $ tail fibs)

the ICFP contest and teams

Wednesday, June 3rd, 2009

I got reminded recently that the ICFP (International Conference on Functional Programming) contest is coming up. The previous two years, I did it with a team of friends and had a blast. It’s a 72-hour programming contest, with the goal of presenting interesting problems that are best solved by functional programming techniques. (2007′s contest succeeded, in spades. 2008′s was more iffy.)

In 2007, my programming team had been through one grandiose spare-time programming project, and had started on the next. We worked well together, and placed 28th. (Corn Worf Strategy, named after a misspelling of an injoke from the first grandiose project project)

In 2008, we’d started to drift apart. It had been a while since we’d given up on the second grandiose spare-time project (we stopped to consider a weighty technical decision, everyone’s personal life blew up, and then the usual US December distraction hit). We didn’t do as well that year. It’s hard to say where exactly we placed, due to the complicated scoring system used, but we were somewhere near the middle of the pack (Pear Programmers, a joke from ICFP 2007 that was hilarious when we were all strung-out on hard thought and sleep-dep). We disagreed more and fought more. We separated into separate groups and individuals more. We simply didn’t work as well together. As individual programmers, we were all stronger than we’d been the previous year, but as a team, we were weaker.

I’m probably going to do the ICFP contest again this year. I don’t think the band’s going to get back together for it. It’s likely that I or we will do far worse than in previous years. My focus on terrifyingly clean code and Paul’s ability to write parsers for anything and Josh’s knowledge of high-abstraction-level Haskell libraries and Jesse’s willingness to bludgeon stuck problems with cloud-computing aren’t nearly as helpful without the communication and trust and interconnecting knowledge we all had.

I’ve never been on a professional team that worked together as well as we did during that first contest, even when it was two hours from deadline, we had no idea of how to move forward, nobody had had enough sleep/food/water, my back had pretzeled from slouching on a couch for days, and everyone had become incredibly annoying. I would move mountains for a chance to be on a team like that again.

igPay atinLay

Monday, May 18th, 2009

I now know why there are so many applications and toys written for Twitter. The Twitter folks have done a marvelous job of making it easy to write little toys for Twitter. Mine’s over at @piglatinbot.

I used a simple little Python library that’s both the thinnest possible skin over URLs and surprisingly functional and user-friendly.

If I feel inspired at some point over the week, I’ll add direct-message capabilities and sort out its little confusion about punctuation.

“Gentlemen…and Kim”

Thursday, April 30th, 2009

At the beginning of my career, it seemed like every formal meeting I attended would begin with the same formal call to attention: “Gentlemen…and Kim”. Each one opened with a reminder that my existence was shocking and bizarre, even to the men I worked with.

I don’t have a lot to say about the recent porn/Ruby talk issue. Or, rather, I don’t have a lot of impersonal stuff to say that hasn’t already been said already, and I don’t have a lot of personal stuff to say that I’d be willing to share with the Internet at large, especially after seeing the responses other people have gotten. The jerks are out in force for this one.

Instead of my words, I’m going to link to some of the people whose words I found the most value in.

Liz Keogh’s thoughtful post on associations, and why seemingly trivial things can be powerful.

Martin Fowler’s links and discussion. I think he’s asking, and to some extent answering, the question: “Who do we want to be? What kind of world do we want to live in, and make by our actions?” They’re good thought-provoking questions for any complicated issue.

Dana Jones’ description of how the shoe might feel if it were on the other foot. This reminds me of the times when I’ve noticed the profoundly male framework of our culture’s communication: of how men who compete with each other to tell even more hard-core rape jokes (at work, in an open workspace) get offended by my joke about an (unused!) menstrual pad. Of how I’ve stopped telling the best timeboxing story I know, because the timebox in that case was a manager’s pregnancy and impending maternity leave, and it just doesn’t resonate with the (male) people I talk to. Of how when I anthropomorphize a linked list or a thread, the person I’m talking with immediately refers to it as “he”.

One last thing: look up stereotype threat.

Extension methods are so cool

Wednesday, March 25th, 2009

Enums in the C-family of languages have always been a little…anemic. Much better than a handful of ints, but anemic. If you want any actual behavior out of them, you either end up with a bag of functions stashed somewhere “convenient”, or rolling your own enum-like behavior in a full-on class.

C# 3.0′s extension methods bring first-class citizenship to enums, albeit in a way that reminds me more of Haskell’s modules than of C# classes. Now we can have member functions for enum values!

(Hey Microsoft, any hope for an EnumOutOfRangeException when someone tries to cast an unsuitable int? Please?)

F# is disappointing

Sunday, March 22nd, 2009

I’ve been gradually coming to the conclusion that I’d rather use LINQ than F#, both because it’s more pleasant and because it better fits what I want from a functional language.

There are all sorts of factors that contribute to this, large and small. Some examples:

  • F#’s laziness is difficult to use, and must be explicitly declared
  • I end up wrestling with F# over types, even in situations where Haskell, my gold standard for a fiercely-typed language, can cope. For instance, one cannot add an integer to a BigInt, or compare them for size.
  • “;;”. At the coders’ social, I had this discussion with the two friends I’d recruited to work with me:
    • me: “Interpreter lines end with semicolon-semicolon”
    • them: “What are they using semicolon for?”
    • me: “List separation”
    • them: “Then what are they using comma for?”
    • me: “Tuple separation”
    • them: “But… semicolon semicolon? Why?”
    • me: *hopeless shrug*
  • Recursive functions must be recursively declared, making them the
    marked state.
  • The built-in List library doesn’t contain half the functions I look
    for, like take, drop, and their higher-order cousins: takeWhile and
    dropWhile.
  • Casually printing temporary results is annoying, requiring both
    “printfn” (“print” doesn’t appear to be taken) and strict typecasting.
  • List.zip requires lists of the same length. (This and non-laziness being the default mean that my most common zip-using scenarios don’t work in F#.)

And, of course, the lovely example I just spent five minutes on:
List.zip [1, 2, 3] [3, 4, 5];;
val it : ((int * int * int) * (int * int * int)) list
= [((1, 2, 3), (3, 4, 5))]
I’d expected a list of pairs.

The problem turned out to be, ironically, too much implicit behavior: [1, 2, 3] is interpreted as [(1, 2, 3)]. I’d much rather have the implicit behavior that lets me compute 12345678I > 0.

Mostly const

Tuesday, March 3rd, 2009

I’m writing a simple maze program in Silverlight, as a way of getting used to the platform.  Once the maze is generated, it’s effectively constant, but while it’s being generated, there’s some tricksy interactions.  What I really want is to have an object that’s modifiable during generation, and locked-down afterward.

The Java way to do this is to have a restricted interface for the locked-down users, and a broader interface/class definition for the generation.  The dynamic language way to do this is to ignore the issue altogether.  I’m probably going to do this the Java way, but I wonder if there’s an idiomatic C# way to do this, or if this is another area in which C# and Java are content to be close siblings.  I also wonder if there’s a language-design way to move this pattern wholely into the responsibility-space of the compiler.

The importance of a good error message

Monday, January 26th, 2009

Two of us just spent half an hour debugging a setuptools/nose problem.  The error message we got was “IOError: [Errno 21] Is a directory”, deep from the bowels of nose.  The problem turned out to be that the current directory was named “rsrc.py”.

I understand why nose choked on “rsrc.py” — it does a lot of magic with file extensions, so it needs to know which python files have tests it can run.  However, it took us twenty-nine minutes to determine that the unacceptable directory in question was actually the parent directory.  (Do you ever expect programs to complain that the current working directory is a directory?)  Ideally, nose would have told us a) what the directory was and b) why it was so surprising that this filepath described a directory, in addition to what it did tell us, which was that it didn’t want a directory.  Something like “TestFindingError: ‘/Users/k/code/resourceful/rsrc.py’ is a directory; expected it to be a source file.” would have made it much easier to correct our original error.

XKCD Puzzle

Tuesday, January 13th, 2009

Sometimes XKCD presents puzzles or problems to its listeners. Today’s puzzle was a particularly straight-forward one: googling for “mac os x command-line volume” led me straight to this answer.