Archive for March, 2010

Week 129

"There's no sense in a man picking out the worst name he can find for everything."
Dashiell Hammett, Red Harvest

On Wednesday, I attended the NH UPA presentation on focus groups. I spent a lot of the time wondering about the effect of group dynamics on end products. The immediately striking moment came no more than a half hour after the presenter said to always watch for the person who chooses to sit opposite you as they intend to challenge everything, a volunteer sat right down and played his role. Reminded me of a zillion client meetings with one of my old co-workers who had a gift for making an entire room uncomfortable before he ever opened his mouth. It was obvious from his body language he was going to argue with anything if he could be arsed to pay attention.

How does this drive design and development when the answers you get are colored by the dynamics of the group? While it works for consumer products with wide appeal, does it work for software? Does it work for consumer  products with wide appeal? Whether a focus group improves or hurts the end result compared to what a lone tinkerer would have built in their garage, it's hard to imagine the final product isn't watered-down. Large groups of stakeholders are used to define software because you can't trust developers (who are almost as literal-minded as the computers they work with), but that doesn't make gathering marketing folks, VPs, and whomever had free time around lunch on Thursday the best way to develop an application. I just can't shake the feeling so many projects get derailed by someone trying to find something to say in a meeting. It was an adjustment from high school to college, going from a place where teachers were more than ready to tell you you were wrong to tenured college professors who'd let any fool capable of raising a paw offer an answer, no matter how wrong. "Ok, run with that." Please don't.  I never saw evidence that if you let someone talk long enough they'll get around to the right answer, and that's when the problem had a definite right answer. Let someone talk long enough and they wind up talking about themselves. No matter what promises they walked in the door with, how they were going to be the voice of the front-line customer service techs, after a couple of minutes of rambling the answers are what they think.[1]

I was contacted by a company I work with about bailing out a .NET project gone South. It's written in .NET4 and the fact I never got around to installing VisualStudio 2008, much less 2010, tells you when my Microsoft Empower for ISVs subscription ran out: last week. Plus you only get two years in the program, so now I get to sign up for MAPS, which requires you to take a 10 question quiz to prove . . . you can use a search engine, I guess. The Microsoft Partner site is built like they're trying to keep you away. It opened 4 or 5 windows (IE-only, of course) all over the screen (somehow managing to throw them across two monitors-- by looking for the bottom left and right corners of my screen, I guess), two of which sat and watched me, apparently. It finally opened the test window, only to have it throw a 500 error and not even show a friendly error page suggesting anyone gave a shit. Even after I completed the test today, the link to purchase a license was broken, asking for a network login on the server. I had to discover some other click path to find a way in to the store. Maybe that's how they really test partner candidates.

I added django-axes to the resident management project I'm working on. Axes tracks failed login attempts; normally you'd use it for making sure no one's trying to break into your site. In this case, I'm more interested in seeing who isn't able to login since we're physically mailing usernames and passwords out to users and we will not have email addresses for the users until after they've signed in and updated their accounts. Even though I needed to customize it a bit to fit our needs (mainly because I'm not using the generic Django login view for reasons which might not have the greatest of justification), it was easy to fit in and customize. Given how little work it is to add, I'm making it part of my standard Django deployments going forward as it provides a level of insight into hack attempts and protection against brute force attacks that any project should have.

An "Ah, duh" moment yesterday: added a line in the deployment script on my current project to run syncdb on each update. Not exactly rocket science, not exactly the best idea ever, but it ensures the deployment server at least has all the database tables. Sounds obvious, but it's a testament to Django that I rip through small tasks fast enough I close the ticket as done without ever thinking, "Hey, I just added x new tables to the database, better make sure the server has them before anyone tries to QA."

1. If you don't recognize this tune from this graf, it's "The Snob's Waltz", an aria sung only by the rarest of divas. The song is notable for having no conclusion.


Week 128

Not much changed from last week, mainly working to push the social networking site out the door (while working on a proposal for another Django/ Pinax project). This week did mark the first time I actually got a Fabric script working (not that it's hard, just that my heart hadn't been in it before now). The script isn't amazing, it just connects to the server, grabs the most recent source code and runs a couple of commands to restart the server, but it does it all without me having to leave the local command line and none of it happens if the unit tests don't pass. The unit test bit is handy because other team members are willing to make the trade-off of sitting through the tests for the convenience of the automated deployment. I like Fabric enough already that I'm searching around for other problems I can solve with it.

Had an unhappy start to the end of the week when a live Django  site started barfing this morning. It wouldn't load any pages and kept complaining about too many MySQL connections, even when requesting static files. Waiting to hear back from the host to see if they have any insight, but I made some changes that seemed to solve the problem. From the logs, it looked like the site was being indexed by one or more search engines that were still looking for the old URLs. Our 404 page was dynamic and ran some queries to render the page. I changed it to a purely static template and the load cooled down. With some rewrite rules for the old URLs and some additional page caching, things should be ok.


Week 127

(idea cribbed from BERG, week count done by Wolfram Alpha because I am too lazy)

"[T]he beauty of reading a page of de Selby is that it leads one inescapably to the happy conclusion that one is not, of all nincompoops, the greatest."
The Third Policeman*

Mix of a week. Started with some edits to the XML parser I wrote for Financial Institution Client as part of a project that decrypts (GPG) a large set of XML documents, skims them for the parts we're interested in, dumps the relevant bit into an Expression Engine database and then transforms all that via XSL to display a customizable dashboard (jQuery UI) on the front end. How's that for a keyword-rich blog post? Tangentially speaking, this week reminded me that of all the languages, technologies, whatever you like that I work in, XSL is probably the easiest one to make a great mess in. It looks just like XML and HTML, how hard could it be? A little bit of XPath knowledge and you're good to go. To make a complete mess. When you write an infinite loop in a normal language, it's pretty obvious: you sit there a while, the computer starts to get noisy, the lights go dim. After a few dozen times, you realize what you've done. XSL is (like) a functional programming language. And with all that recursion, it's easy to make a computer do something Big Number of times. Just harder to spot.

Also did some final-mile edits on a social network application from Slim Kiwi built on top of Pinax (and Django).  Hoping it's truly "final-mile" as the project is really cool and I'm quite proud of it. There's a ton of geolocation and mapping going on and a fair number of other bright things happening (the bright ideas being supplied by other team members and the bright implementation by Django, obviously).  I was able to roll some of the geo search and Google Maps integration right into a site for Community Trust Bank, a project from Lightfin Studios (you can see the location stuff at the branch & ATM finder). That's the second bank site I've built with Lightfin, the other being the much-closer-to-home (but harder to spell) Piscataqua Bank (built in .NET) which got some updates this week as well.

At the end of last week I started to ramp up on my second Django site with Lightfin. Not much to say about it yet except that it integrates with a third-party API which reminds me of one thing: I hate SOAP (the overly-verbose web service format, not the cleaning product so beloved by my ancestors they enslaved a leprechaun to endorse it). Please don't ever use it. I'd rather parse faxes by hand. If you're stuck dealing with SOAP in Python, Suds seems to be the best parsing package out there. I'm sure there was other stuff going on, but the only thing I can think of is some cleanup I did of an old ASP site and the less said, the better.

* Indie/ hipster required disclaimer: I am re-reading The Third Policeman, I read it well before it showed up in Lost, so cram it.