Seen as a Skype contact message: “Software Development process of the day — Decapitated Chicken Process”.

Long ago, I had a cartoon from somewhere that I’d love to find again.  As I recall, it showed a guy in a suit, holding a book, a candle, and a knife.  He’s standing in front of a large mainframe computer, and there’s a woman also in office attire kneeling on the floor in front of him.  (Think here of ritualistic sacrifice of a virgin to appease the computer gods.)  Some days, it feels like that’s the only thing that has a chance of perhaps making things work.

Uh, did I mention I’m in a PMP training class? 

Reading a book of lectures by Donald Knuth that I let myself be tempted by in my last spin through Borders. (Note to self: when picking up a book you’ve reserved, it’s completely possible to JUST go to the checkout line and buy that book, and only that book.) Donald Knuth is most famous for writing a set of algorithm books. His lecture set is from a set of lectures he gave at MIT on “Interactions Between Faith and Computer Science”.  The book’s entitled ‘Things a Computer Scientist Rarely Talks About’.
Observant readers of this blog will see a category for Christianity among my archives. It’s not something I’ve written about much of late, for a variety of reasons. But you’ll occasionally see in this blog that says something about Christianity and what I’m thinking about at the time.

Anyway, as I’m skimming his first lecture, I’m also taking a quick peek at Dr. Dobb’s Journal. Thinking about Knuth made me think about the made-up language he used for his algorithm examples which made me think about what new languages are out there that I haven’t heard about of late. An article about build systems (The Buzz About Builds) is on the cover of this month’s magazine, and since I’ve been wrestling with an automated build system at work, I take a quick look-see.

Now I’ll caveat that I’m not all that impressed with this article. I’m three sections in and it hasn’t told me anything of great technical value. A little bit of business background as to why build systems are now getting greater focus in the industry’s great, but isn’t going to help me wrestle with CruiseControl tomorrow. What I do find interesting is a quote that’s at the top of section three, ostensibly about distributed development teams and thus the need for better build systems, is this quote:

We Bokonists believe that humanity is organized into teams, teams that do God’s Will without ever discovering what they are doing. —Kurt Vonnegut

Note that I think it’s a lousy quote for distributed development teams. I don’t ever want to be on a team where I can’t “discover[…] what [I’m] doing”. But a very interesting convergence of reading materials. I’ll caveat that I haven’t read the source of Mr. Vonnegut’s quote: couldn’t tell you its context, applicability, etc.  But it does pop out to me tonight and intrigue me to find out more.  (Will admit to you that I would believe that we could often do God’s will without being aware of it.)
Update: a quick spin around the ‘Net points me to Bokonists being in Vonnegut’s Cat’s Cradle, and various serious-minded writers speak on its satire of religion. Now on my list of soon-to-reads…

I just did a quick Google search, trying to find an existing Excel spreadsheet template to do sprint burndowns for Scrum.  I badly mistyped, and ended up requesting Google do a search on ‘excel spritn burdown chart’.  Google couldn’t find anything on that search request (imagine that), but did offer: Did you mean: excel sprint burndown chart .

Not too long ago, I considered applying at Google.  They’re now up in Pittsburgh, we’ve got family up there, and wouldn’t it be interesting to get to work at a company that’s just become such a hallmark of our times.  I ended up deciding that, one, we weren’t really all THAT interested in moving to Pittsburgh, and also that I liked enjoying the idea of being able to say I worked at Google more than I enjoyed the practicalities of interviewing and working there.  Frankly, I’m not sure I’m smart enough to work there, and I’d rather not prove it to myself (or worse, have it proved to me).  (Even worse, somehow, would be the idea that you DON’T have to be smart to work there, that all of the things that they’ve built have been built using generally good folks like me who just somehow create technical magic.)

Anyway, Google’s intuition of my real search term needs brought all of that to mind and inspired an impromptu mid-day blog.  Now back to my generally interesting, but not nearly so AI-like kind of existence.

A sign that I work in a male-dominated field: the ranking guy at my new office had to send out an e-mail to the guys in the office.  He told them that that since their newest hire is female, the gents would no longer be able to commandeer the ladies’ room to use the shower there after their lunchtime bike rides.  Sheesh….  I’m used to being in the minority, but this is amusingly out there.

Take a quick look over on Dice’s Rant Room… These folks are competing for a “a maxed-out Alienware Area-51® m9750 Notebook.”, and hopefully not raising the wrath of their HR departments, or their potential employers.

One that amused….
jumpcut movie:They wont talk to me!

Interesting perks of my job of late:

– seeing us on Nickelodeon and the Cartoon Network in banner ads, and part of the SpongeBob Friend or Foe episode sponsorship.
– knowing that we’re in Best Buy (search ‘kajeet’ on BestBuy.com) and LimitedToo (again, search ‘kajeet’ on LimitedToo.com)
– We were in the WashingtonPost: my boss is the guy holding the cellphone
– We were on CBS News (!) tonight. See clips ‘Eye to Eye: Kids Go Mobile‘ and ‘Marketing Cellphones to Kids‘ (note that we’re the good guys at the end of this clip looking at all the bad things that happen in the market of selling cellphones to kids).
All very cool, and nowhere near anything I’ve had at previous jobs. I’ve been there a bit over a year, and seen us grow (sniff, sniff) from an idea / architecture to an operational system. My part in it? Based on some stats run against our code-base, approximately 28% of the code, or some 125,000 lines of code. (Note that I didn’t run the stat tool and count the numbers highly suspicious. That said, I’m holding onto the email that says ‘She is personally responsible for more than 125,000 lines of custom kajeet code, all written while leading a team of engineers, managing collaboration with Marketing and Product Development/Management, and interacting with half a dozen vendors.’ )

The sad part is that I’m leaving kajeet for pastures closer to home. The commute is killing me (running about an hour and a quarter each way for me in Beltway traffic, since I don’t live that close to Bethesda). That said, that leaves a wonderful opportunity for someone to come and fill my shoes. (No pressure here, looking at those stats above.) Cool job: Java technologies, interesting frameworks, agile development, smart team members, and a focus on building stuff that’s really going to get used. There’s no shelf-ware here: something you build today will hit the production system and be used by customers within a matter of weeks. Those Best Buy customers will be using YOUR stuff. Those CBS news viewers will be checking out YOUR stuff.

Check a job posting for a software engineer at kajeet. Multiple positions being hired, on a variety of skill levels. But it’s a good snapshot of the technologies and platforms in use.

Another EBF (Emergency Bug Fix) night. I hate ’em. Hate deployments in general, in fact, if I’ve already got a system up and running. The model that came to mind tonight: systems are like Rubik’s cubes. You can get yourself in a lot of trouble if you try to make that one last cube line up right.

In my attempt to be a conscientious tester of a new feature in our codebase, I put in some stub code to allow me to test locally and hit all the various boundary cases.  In a painfully ironic twist, that test code introduced a bug which only reared its head in a small set of boundary cases.  Note that all of our operational tests after deployment test transactions with the main path.

So, in being a good(?) tester, I broke the system.  The fun of pushing bits.

Here’s the setup: product/legal required us to update our terms of service on the site. They delivered the new terms of service in a Word file. Headache #1: manually compare that Word file to the text in our site’s JSP. Note to self: require product/legal to at least show us the diffs. Nothing worse than a Saturday morning spent diff’ing legal text. (No, converting from Word to HTML wasn’t helpful: have you seen the cruft it spits out?)

Headache #2: I realized that the terms of service are also in our store site. To the user, it’s all one site. However, physically, it’s a separate site, separate code repository, and the like. NO way I was diff’ing that legal document twice! (I did mention I was doing this on the weekend, right?) Brilliant Idea #1: refactor the terms page from the main site to use an included file (the text of the terms) that I could share across the two projects. Note that the two sites are built differently: both are done on top of Struts, but one uses JSPs and one uses Velocity. That meant that the syntax for the include would be different (<%@ include versus #include), but then their containing pages would be different, not the text of the terms themselves.

Headache #3: when I brought up the separate sites in my local environment, realized that the terms had URLs embedded in them. In the original site, we used html:rewrite Struts tags. That wasn’t going to work in our Velocity setup (at least, not in a way I recognized, anyway). Also, since the URLs referenced all lived in the one site, the webapp context didn’t have to be taken into account. From the store side, I had to deal with it. Solution: update hte URLs in the store side to use an application level variable for the path. It’s not the best solution, but it’s consistent with how URLs are built in the other areas of the application.

Now the include files are different (unfortunately), but at least the changes should be isolated to the URLs. Now if we need to update the terms again, we can convert back and forth readily for the two sites, at least.

…. corrupt your .svn file structure on your local system. Then, disconnect your project from Subversion via the Subclipse plug-in. Now, try to get things up and running again.

Steps thusfar:

* copy my working copy to an -old folder (just in case I need something).

* remove the working copy

* Do a new checkout from Subversion (command-line style, since Eclipse is still unhappy).

* Hmmmm…. that didn’t help me within Eclipse. OK, do a checkout from the SVN Repository tab within Eclipse: that’s deleting my new working copy folder and getting a fresh new checkout.

Ugh. I hate it when I have to wrestle with configuration management.

Useful resources:

(1) help files in Eclipse for Subclipse plug-in. (Team –> Share didn’t help me much, but was useful to find out about.)

(2) Version Control with Subversion