This version of the site is now archived. See the next iteration at v4.chriskrycho.com.
Topic: “development”

Platforms and data: or, why Google+ needs Hootsuite

We’re quickly approaching Google+‘s first birthday, and the search giant’s social media platform has found a core audience, but it has never caught on to the extent that Google hoped or the tech media hyped early on. That core group of tech enthusiasts has certainly put it to good use, with voices like Tim O’Reilly finding an even broader audience and a medium that suits him well.

For most of the population, though, Google+ was a novelty that never went anywhere. Read on, intrepid explorer →

You’ll pay more tomorrow

I’ve spent a fair bit of time recently working on a project that, all things considered, really shouldn’t be that difficult. A client wanted a change made to his web application, a change that is simple in concept and – in theory, at least – should be equally simple in execution.

But it isn’t, and it’s not because of any hidden complexity in the task itself. Rather, the problem is that the code base for the web application is, to put it bluntly and without a hint of hyperbole, awful. I’ve worked on a fair amount of legacy code on various projects, in various languages, over the last few years. This one is the worst.

Individual functions hundreds (perhaps thousands) of lines long. No comments. No object orientation to speak of. Hackish solutions to problems all over the place.

But this isn’t a complaint post. It’s a request to the thousands of people in the world who are tempted to say, “Well, this will work for now…” Some of you are developers yourselves; others are simply dabblers. Whoever you are, whatever your context, whatever your project: there is a problem with “This will work for now,” and that problem is called tomorrow. Read on, intrepid explorer →

A Plea for Open Data

One of my current side projects involves some database work for a client in an academic context. There is an enormous trove of data being collected by the project, but the local administrators refuse to publish the data on the internet themselves. This despite the fact that it’s already being published to their academic intranet. This despite the fact that they’re willing (with some persuasion) to pay an outside contractor to develop a means of displaying the data for all the public to use.

I’m not sure what’s driving this sort of recalcitrant refusal to share the data, but I can’t see there being any good reason. Read on, intrepid explorer →

Responsive Design, Server-Side Feature Detection, and a Big Mess

A couple days ago, Jason Gigsby (@grigs) highlighted this post by Dave Olsen on responsive design from the server-side. The biggest thing that caught my attention was his focus on user-agent detection for altering the delivery of content.

There is some sensible stuff in there; it’s worth your time. In particular, I can see the value in delivering different kinds of resources to different targets, especially in the case of video or images, where resolution and bandwidth may be constrained. Read on, intrepid explorer →

Upgrading WordPress manually

I was recently hired to do some back end work on Church of Christ the King’s website. (Note that the site design is not mine.) In this case, the initial change I needed to make was small – trivial, even. However, I noticed as I made the change that the site was running WordPress 2.8.4. Unfortunately, that meant I was going to be upgrading WordPress manually. Read on, intrepid explorer →

Introducing: Ligatures-plus.js

A few months ago I ran across Chip Cullen’s absolutely fantastic ligatures.js – a very simple jQuery function that manually replaces character pairs or triplets with their corresponding unicode ligature. There was just one problem: to use the function, you had to manually test each of the characters you wanted to use against the target font. This is potentially a lot of work, especially if you have multiple custom fonts on your page. Read on, intrepid explorer →