Posts Tagged week

Week 142

"That tension— between beauty and cynicism, between what the Brazilians call futebol d'arte and futebol de resultades— is a constant, perhaps because it is so fundamental, not merely to sport, but also to life: to win, or to play the game well? It is hard to think of any significant actions that are not in some way a negotiation between the two extremes of pragmatism and idealism."
Jonathan Wilson, Inverting the Pyramid

This was supposed to be "Week 138", but I never got off my duff. It's just as well as I read Flashman and the Dragon in the interim and it colored my thoughts on this post. I want to clarify and expand upon what I said in the last post about the danger of falling too much in love with one language, one web technology. Some of that is just my personal bias: I spent my formative development years working at a consultancy that took on work in all manner of languages and on any number of platforms, so I think that's How Things Should Be. I've always prided myself on being "language agnostic" in terms of programming. A few times on a job interview or when trying to land a client I think this has cost me— you see a wrinkled nose or the torrent of questions turns into a trickle— but I've never really minded because I think insistence on working in one way is the path of the small-minded. It's something I rail against in general, the tendency for everyone to think where they live, how they live and what they think is based on some cosmic template of How Things Are Done and anyone who's opinions, skin color, language differ from that template is doing it wrong.

That kind of thing infects your thought. If I were designing a curriculum for a school, it would include a week discussing Kipling's "[W]hat should they know of England who only England know?" A week at the inside. Make it the basis of a year's worth of forming thought. Too many developers focus on one thing, get comfortable in it and then don't know what to do when that technology turns into a dead end. Or, worst of all, don't ever find out that technology has turned into a dead end. There's nothing more frightening than meeting a new client's old developer via his work. "He has his own way of doing things." "He was very specific about that." Etc. If you don't think there are people making a good living writing dead-end solutions for clients who don't know better, find out how many copies of Microsoft Access were sold last year. Ask why people are still looking for VB6 compilers ("I don't like to upgrade [to] 2008. More than 10.000 lines of code")?

So what the hell am I doing trying to work in Django all the time? First we should discuss the lie I told above. I'm not language agnostic. Not exactly. I try not to be a fan of anything, but that's not in my nature anyway: I expect to be let down by anything I rely on. But I don't stop myself from hating. This week, a partner asked me if I knew any ColdFusion consultants. My thought process:

  1. Why would I hang around with a sorry bastard like that?
  2. Hey, I've written thousands of lines of ColdFusion!
  3. Yeah, and you hated every second of it.
  4. Oh, right.

No thanks. It's one of the few languages I've worked in that I feel sets you back (note: all opinions circa 2002 and CF4/5). Like ASP, its limitations make you think programming has to be hard and that there are things that cannot be done. It never fails to amaze me when a developer says something "cannot be done". It's almost never accurate. 99% of the time it either means it can't be done in budget or the developer does not know how to. And that second case is when you should drop a developer post-haste. I've rarely done anything interesting as a programmer when I knew how to do it at the outset. You only learn and grow when you get challenged.

So, again, why work so much in Django where you can develop a comfortable rut and never be challenged by ideas and paradigms from other languages that might show a better way to do things? So much of life comes back to biology, and working in one language is incestuous. Healthy populations have lots of differences, providing more opportunities for mutations and evolution. I could hang out with the world's smartest Python programmers and all I would ever learn is the best way to solve problems in Python. Which is not necessarily the best way to solve a problem. Going back to Kipling, it's hard to appreciate what you have if you don't know what the alternatives look like. It's human nature to assume what you have is the best option. My favorite Americans, the people who I think are our best citizens, were citizens of the world. Franklin, Jefferson, etc. were Americans intimately familiar with England, who spent much of their diplomatic lives in France. The synthesis of different ideas results in totally new avenues. Even just the ability to synthesize different ideas is important.

The answer turns out to be a surprising one: I, and by extension, this company, am not a programmer. It's what I do to accomplish client goals, but it's not what clients want. They want a solution to a problem. Ideally a secure, high-performance, user-friendly solution, but in no case do they care about the language it's written in or the format of the code. They just want something that leaves them happier than they were before. All that stuff developers argue about, languages, platforms, editors, it's all fanboyism. I'm too old for that and I'm more interested in accomplishing something than being right. Or I'm trying to be.


Week 137

Not a whole lot to report. There is, I suppose, but it's too damn nice of a day to spend it reading (or writing) this stuff. I'm dangerously close to finishing a site for PBS' Frontline after a week-long crunch. It's been yet another experience that's re-affirmed my love for Django. It's to the point where I can take on (literally) twice as much work as I could before Django and the scary thing is that I'm just getting comfortable with it and each project exposes me to at least one new package that makes things easier. For instance, I really wish I'd known about PyFacebook a couple of projects ago. It would have made things a lot easier (especially if I'd coupled it with django-socialregistration).

The downside to my love affair with Django is it gets really easy to become picky, to insist on only taking projects that can be done in Django. The next step is to try to force each project into the shape of previous projects; the whole reason I gave up on CMSes in favor of a framework like Django was to avoid cramming a client's square peg into a round hole (dirty!). Always working in the same language and framework is a ghetto: you only know what you know and you don't get exposed to new ideas.

So I've ripped through another Django project and have picked up a new one this week as well. And yet, given my chronic case of Irish Alzheimer's, I'm down in the mouth because this week also saw the death of a project. Not death exactly, but it's being shipped off to India to apply the final touches. Whether that's death or CPR depends entirely on who gets a hold of it, but I'm guessing the project would have a hell of a time getting term life insurance right now. It's only the second project I've had go south in the 2-and-a-half years I've been out on my own, but it still sucks. In each case I came in after the contract had been agreed on and after (what would have been) the requirements gathering period had ended. I'd call it a clear lesson learned except it's one I learned a long time ago and keep screwing up because I assume I can punch my way out of anything. I need to spend less time improving my code and more time improving my ability to communicate the value of up-front requirements gathering and a process "agile" enough (whatever that means) to get regular feedback from the client on how things currently look.

Totally unrelated to any of this, but I did run into an interesting usability issue while we were on vacation in Maine. Though it may be silly to generalize about a state's drivers, I will still assert Maine's drivers are far more law-abiding than their New Hampshire counterparts. So I was surprised to see how they lay out passing lanes in Maine: like a challenge to your manhood. The first couple I shrugged off as mistakes, but after a day or two I could not get over how many passing lanes didn't end until you were just about up to a curve or hill that obstructed your view. I finally figured it out at the end of our trip: Maine assumes the best in its residents and visitors. Passing lanes end at the last possible second it's safe to pull back in. New Hampshire knows their residents are crazy. Passing lanes end at the last inch you could possibly pull out at and pass someone assuming you're on a motorcycle and passing a rickshaw. It'd be nice if Maine added one more sign to the Burma Shave-esque laundry list of warnings they have when passing from New Hampshire into Vacationland. Or just replace them all with "Welcome to Maine: Don't Do It, Brutha".


Week 134

"It ain't always easy, if your knees knock as hard as mine, but you must remember the golden rule: when the game's going against you, stay calm— and cheat."
Flashman at the Charge

Heard from an old client and met with a (potential) new one this week. Though both New England-based service companies of comparable size, they're from two different eras. Due to dropping margins in their current business, the existing client is moving into a new, tangentially-related one. Before building a new site, they wanted me to do some search engine research. I've been working in SEO since around the time they coined the term and it's never been satisfying. Some of it's just my personality: I like coming back to clients with finished work, with correct answers. SEO resists that. No matter how the algorithms change, it's always going to be an art[1]. The client's new industry is a competitive one. Until they've established themselves, search engines are going to be an opponent, not a help. We've come up with a list of keywords and a strategy for using those words and getting linked to by their partners and other industry sites, but that's about all that can be done on my end. I could do a lot more busywork and generate a lot of documentation, but that's the dark art part of SEO. Without relevant content that interests people enough to link to it, you're chasing the keyword market (through bought AdWords) rather than creating it. My advice to the client is the same easy (for me) advice I always provide: from the terms you gave me, here are the words people actually search for. Put those in your content. And then keep creating new content on a regular basis (blog). Create it with a consistent voice and create it because the content is worth knowing.

The new client also feels their chosen industry is contracting. Rather than branching out, they've decided to reposition. The Internet made their business a lot easier; reduced costs led to higher margins. For a while. But like nature abhors a vacuum, the economy always destroys an arbitrage. The efficiencies introduced by the 'net brought much larger companies into the industry on a national level. The client cannot compete at their price point. They could, but it'd be a short competition given the negative margins they'd suffer.

So they have to change their model. In any service industry, you can be a boutique. There are some people out there so good at what they do they can make it on word of mouth, but it's a pretty risky bet to assume you're that good[2]. The client's idea is to become a resource. A lot of people pay lip-service to this idea, but it's nice to see a client come up with the idea on their own and be committed to it. I enjoyed it all the more because it was disconcerting: they're a small shop hidden in New Hampshire and the client's old enough (ageism alert!) it was unexpected. Survival's a powerful motivator.

I'm sure every region of the country (and every country in the world) has them, but I've only known New England and I think this region runs on people hidden in the woods who know what they're doing. I once went on a business trip with my Dad when I was still in high school. We wound up down a dirt road in Rhode Island in front of a couple of old Quonset huts representing the sum total of a metal fabrication shop. Out walks a heavyset guy in his 60s with a bushy beard full of tobacco spit off the unlit cigar that never left his mouth. But inside one of those huts was a CAD program driving a plasma cutter. This was 1992 at the latest: it'd be like walking into your neighborhood auto parts store and finding wings for flying cars. Little ahead of his time. It's nearly two decades later (God help me) and there are still people in his business not that technically advanced.

Guys (sexism alert!) like that always survive. They don't thrive: they refuse (or are uncomfortable) marketing themselves and to grow past a certain size they'd have to overcome the cultural barrier of dealing with bankers from a city. Maybe put on a suit. Which means there's room in the industry. Between giant (multi-)national companies and brilliant Yankees in the woods, there's room for people who, regardless of how good they are at what they do, are decent at marketing themselves. If you don't go with the giant in the industry and you don't know about the boutique, you wind up with whomever you can find. Which is why spam works and why you have to pay $100 to get a poster framed in your town. The Internet's flattening those things out. It's abstracting marketing out of industries: killing trade magazines, newspaper classifieds, anything that made money by holding onto information. I don't know what it will mean when it's easy to find the boutiquess and the ass-kickers for whatever job needs doing, but it can't hurt to be a resource in your industry. Give away the knowledge and show you can do the job.

1. "art" in either the loosest sense of the word or when the best people in the industry do it. Most of it's a lot worse than art and some of it is pure snake oil.
2. "Hello Kettle, this is Pot. Can you hear me?"


Week 133

"[T]here's something splendid waiting for you to go and find it, far out yonder. I wonder if I'd feel it now, or if it happens only when you're young, and have no thought for the ill things that may lie along the way."
Flashman, Flashman and the Redskins

This week's notes start last week, but Saturday was after my last post and it's appropriate this beings with an ending because that's where I want to begin. I was lucky to learn a Universal Truth in my first job. There was a woman who'd worked at Putnam for years when my class of newbies rolled in. As far as we could tell, she was one of the engines that made our department go: knew everything about her specialty, did a ton of work (at 34 instead of 22, I can tell you all she'd done is carve out a fiefdom by working on one thing and spending the rest of her time fighting to avoid the rest). She managed to miss a month of work with a back injury. Upon returning, someone had an uncomfortable conversation with her about how part timers didn't get sick time so they were going to have to take from her vacation time (leaving her with something like -97 hours to spend on beaches around the world). She walked out on the spot. Well, she made a scene and then walked out.

Shock. Desperation. Visions of insane workloads, late hours and less fun than we were already having danced in our heads. What we discovered instead: she talked a much better game than she played and her work was easy. In a couple of weeks, with no new hires, it was like she never existed. Since then I've always reminded myself no one is irreplaceable and no one is the keystone. When I left Putnam, I slunk out a couple of hours before quitting time just as the part-time ladies brought my cake in. Maybe a little cold, but they wanted the cake, not a goodbye and I've always been addicted to that feeling of freedom that only comes from leaving. Anything.

But all of that is a bit of a lie and I'm a lot of a hypocrite. Make no mistake, I am not a team leader. I'm too prickly and I can't modulate my expectations for people. Expecting less of others than I expect of myself feels like an insult. Completely unfair and maybe a little pathological, but there it is. I fancy myself more like a point man: you might not see much of me, we might not be best friends, but you're never going to get blown up on my watch. While I tell myself nobody makes a lasting impression unless they jump from a great heightr[1], I've always had it in the back of my head I lead by example, I leave places better off than I found them. Which is a damn fool illusion to walk around with. Because on Saturday I ran into some code from a place I used to work. And it took me a half hour to calm down enough to fix the worst of the mistakes in the code. You can see why I'm not a team leader. Calming down involved emailing a couple of former coworkers to grouse. We decided the secret ingredient when we were there were the small smattering of complete incompetents who made everyone work double-time because they knew they had to carry the load. In the hope of reducing the sum total of complete incompetents in the world (at least for the next 10 minutes), I'm going to talk about how not to write the code I came across. So if that sounds like nerdery, jump off now. It won't get any better in the next graf.

The first time you code something, it is the most rickety thing you'll ever come across. Various labels exist for this genus of code: "twine and baling wire", "duct tape", etc. You're basically speaking a foreign language and the fist time you get an acceptable response, you stop everything and call it done. The form submits and anything shows up in the database? Success! Don't anyone touch it. Assuming you're not completely put off by the process, at some point you realize your code can break. But even after cleaning up all the mistakes, there are still any number of ways a user can break the thing. Exceptions. So you write your first exception handler[2].

The first step to exception handling enlightenment (keeping in mind your narrator is an unreliable one) is to start using them. That's something. It shows a beginner's mind. It shows humbleness, a realization of the imperfection inherent in all works of man. But you've barely gotten anywhere, because all you do when you first start trapping exceptions is "Please catch anything that happens. Eat it, swallow it and pass it without ever making a sound. I don't want to know about what happens down in the guts of this program." Having a Beginner's Mind doesn't mean being ignorant. You need to know what's going on in there. Instead of saying, "This could blow up. I better set a trap here", you need to think of how it could blow up and trap that. Because if you don't know how it'll blow up, you don't know how you should be handling the exception. If the fire alarm in your house goes off, it could be that the batteries need changing. It could be dust got into the sensor. Or it could be your house is currently engulfed in flames. You don't want to handle all those cases the same way. Because there's only one way to handle those cases the same: run away screaming. It'll keep you alive, but it won't make for good code.

If all you're going to do is set up an anonymous try/ catch (i.e., one that traps every error), don't. You're better off without them. At least then when things go wrong your users find out and they can tell you. With anonymous try/ catches, no one knows what happened. Things just don't work. Ignorance is an enemy of good work in any field. Self-imposed ignorance . . . I don't even have a metaphor here. Don't do it. Here's another hint: the Warnings panel in your compiler? It contains warnings. Yes they are not errors. Yes you can ignore them. Yes there are a couple of things that it warns about that aren't necessarily so. But they're warnings for a reason and the compiler is smarter than you. So figure out what they mean. "I can always ignore 'Unreachable code detected' because someone told me to in this one specific case" isn't knowledge. It's faith. It's ignorance. Investigate everything, even when someone tells you to ignore it. Worst that happens is you learn something before you're done.

As pissed as that left me, it was nothing compared to dealing with one of my bigger clients this week. This big client has a big data team. The data team sends us big files full of chronological data. I got killed by QA this week for two major issues that revealed a troublesome problem: some of that chronological data ain't. When I pointed out their chronological data was sorted "alphabetically" by date (where dates run 3/2009, 3/2010, 6/2009) in one case (and apparently randomly in the other), this did not cause anyone to jump up and fix things. We're a small client for the data team. There are plenty of other clients they serve. The problem with that is no one could be relying on the current order of the data. It didn't exist. So, as is their wont, they paid me to work around it. Authorized a day's worth of work for me to deal with it instead of authorizing 15 minutes of work on the data team's side to fix the problem permanently across all existing and future projects that consume the data. Please don't sing me sad songs of how I don't understand big systems and all of the interactions and the need to QA and how many eyes have to look at the problem. Somewhere on some server there's a bit of code that pulls this data out without bothering to sort it like the rest of the data it pulls out. At the outside that's a 3 line fix. My 15 minute estimate gives you 10 to sit on the john.

1. Shamelessly stolen from The Old '97s

2. An aside here for the non-technical minded (though you were politely asked to leave): an exception handler is (wait for it) a way of handling an exception. But the important thing is what you consider an "exception". A good example of a handled exception is asking a user where to save a file and they provide a path that doesn't exist. The handler fires and gives you a chance to yell at the user rather than just crashing your program.


Week 132

"Well, the Devil made me do it the first time/ Second time I done it on my own."
Billy Joe Shaver, "Black Rose"

Never got around to the last couple of weekly updates. There wasn't much of interest, technology-wise, and they burned the hell out of me. It's twice as fun to be burnt-out busy when they paychecks are weeks or months away. Every 4-6 months I go through a transition period where one or two big projects is winding up and new work is starting to trickle in (including a Django project for Frontline). The trick is dealing with the maintenance work and one-off edits for clients during this period. I'm really struggling with the continuous stream of interruptions. When I started on my own I was mad to reply to everything as fast as humanly possible and get the work done in much the same time. Not a great idea. While I've gotten better about resource planning, I still can't shake the feeling I need to reply rightawayohquicknow or lose a client. I know none of my clients stick with me because I can turn around an email quickly. Anyone could do that. I know it's for the quality of my work and I know I have credit in the bank with (most of) them, but I still drive myself nuts.

Email's the problem right now. It's always the first tab in my browser and then I have a Gmail plugin/ setting that updates the tab with an inbox count, in the interests of further self-abuse. When I worked for someone else and email became a problem, I'd just shut it off. Someone wanted me, they could call. And if that got to be a problem, I set the phone to make-busy. Not the thing that sends 'em straight to voicemail (I probably checked my voicemail less than 20 times in 8 years-- never occurred to me), the thing that dumped the call. Walk over if things are that bad. But now that I'm my own boss, I can't do it. I need to find some way to shut off email without obsessing over it. Still working on that. It's not an original observation (I think it's the theme song of the freelancer), but I want to make more days lie Saturday. Michelle works on Saturday morning, so my work week is from late morning Monday (theoretically— it's been more like early morning Monday recently) through 1pm on Saturday. And it feels like 50% of the work I do gets done in the quiet of Saturday when no one expects a response out of me (and don't start emailing me now). All I need is two of me: one to do the communicating and one of me to do the work and keep them away from each other before they go out drinking and get in a fight.

On a different subject, it's always interesting to be on the other side of the fence like I am right now on a project for Big Financial Institution. We've done a lot of work to paper over some of the cracks in their data team's process, but we're running into Newton's Fourth Law: "For every effort you make to hide the incompetence of someone you depend on, they will redouble their effort." This is a Big Company. I'm not mentioning it to impress anyone. I'm mentioning it because I can't imagine working for their data team and sleeping more than an hour a night. We've been (theoretically, mind you) getting the same thing delivered quarterly for almost a year now. Counting all the test runs, we've probably had a dozen data drops from them. And it's painfully clear this stuff is not delivered by script. It's 12 XML files with the same data fields every time for the same funds. Is it scripted? Hell no. Best I can tell, there's a guy with a button somewhere. And best I can tell, he was dropped on his head as a child. Maybe that's what makes me decent at my job, because I always hear Jim Clancy in my head: "There's a difference between a job done and a job done right." At some point, stay late. Whether they pay you for it or try to kick you out for being there late, stay and figure out all the questions in the process, find the correct answers one time and then make a damn computer do it. Because then you'll never have to look up the answers again, which means you won't have a chance to mess it up. And if you tell me there are too many moving parts to script the process, that just means you don't understand the process. Break it down into a bunch of steps, write some God-awful-looking code that works and be done with it. No one's ever going to see it, they're just going to be happy with you. And if they fire you because you made yourself redundant, good. I guess some people can work at a job where everyone agrees not to work too hard, but that's a Devil's Bargain: you grow fat and lazy and dull and then the only jobs you can work are ones just like it. And they don't hire much. Because people don't leave and because the company isn't growing.

It pains me some people are (theoretically) in the same industry as me but have no curiosity about it. True anywhere, I just happen to see it here. Which is why when people ask what I do, I tell them I'm a valet at the drive-in.


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.