rss

Blog

Housekeeping
Ethan
January 25, 2012

Does your code clean up after itself? Because it should.

One of our clients has a set of scripts that run updates every night. Those scripts log everything they do, and those log files are store on the file system. No big deal, really. Except that after weeks, months, years, there will be thousands of log files that don't need to be there anymore. So there's a process that removes log files after a few weeks.

Today I was working on an "alert" system for a new application. Alerts are stored in the database. Every page checks to see what alerts you are supposed to see, so you want to keep that overhead to a minumum. Since people can click the (X) button to dismiss an alert, the majority of alerts in the system won't even be displayed. You don't want those hanging around. They take up space in the database, they affect page load times, they slow the whole system down. To deal with that, I wrote some code into the module (it's a Drupal module, using hook_cron, if you're curious) that removes alerts after 6 months.

Usually when you're spec-ing a new piece of functionality, you're thinking about how to make it work. That's usually all you base your estimates on. I think it's a good idea to think about housekeeping, plan on that from the very beginning, and include that in the estimate. It may end up saving you time (and your client's money) in the long run.

Colleen’s Intro... the Mobile Health Competition
Colleen Luther
January 20, 2012

Hi there Zone 5 readers. I'm Colleen and I'm the new Web and Social Media Project Manager 'round these parts. Instead of telling you about myself, I thought I'd show you what I'm about by sharing some details about a special enterprise I'm involved with - the Mobile Health Competition.

I decided to enter this contest about two hours before the deadline. Normally, I would never do something so ridiculous. But I decided that coming up with a smartphone application idea to help teens deal with cancer was pretty much right up my alley.

Mobile and social apps? I’m paid to think about those. When you specialize in web and social media, apps are an exciting part of the territory. Teens? My last job was at a high school, and before that, a college. Cancer? I’ve been in remission for eight years, but I still remember the experience like it was yesterday.

So what was the idea?

My idea was an app that specifically tries to prevent isolation. I tried to apply all that I know about social media, and all that I know about being a young cancer patient, to come up with an idea that was usable, workable, and doable. You can read all about it here.

On that page, you may also notice a large green button that says, “Vote for this entry.” This is because my little idea somehow beat out a bunch of entries from around the world to make the Top 10! Now that it’s in the Top 10, things move from the judges to a public voting stage. Then the top three entries go back to the judges for a final decision on which one gets made.

Experts wanted

I’m sure the Zone 5 blog readers have an opinion or two about what makes a good app. Please vote for the idea you like best (though I’d be very grateful if it were mine). Then spread the word. Forward this message. Post the link to Facebook, Twitter, and Linked in. Tell people so they can help the best app get made.

You only get one vote per computer. But you don’t have to give the contest people any details about yourself; so don’t worry about being spammed later. Voting ends the 23rd, so act quickly.

Thanks so much! The winning entry person gets $5000 donated to the cancer charity of their choice. If I get lucky enough to help these kids, I’ll leave that decision up to all of you who helped get me through this voting stage.

So, what do you say? Will you help the new girl out?

Things will go wrong.
Ethan
January 11, 2012

They will, and you have to deal with it. You can spend months designing the perfect system. You can do everything you can think of to make it foolproof. Something will go wrong. Something will break. At that point, the important thing becomes determining what happened and why and how can we fix it?

Obviously the easier it is to find this out, the better your system is.

One of our clients has a website that gets updated every night. An XML file comes from their system, it gets processed by some scripts we wrote on the web server, and then if all goes well the updates get pushed to Drupal. There's a lot of room for things to go wrong, but for the most part things actually work pretty well.

Of course, every once in a while something will go wrong. At that point, I'm glad the scripts log as much as they do. I can look in the log file that the scripts email to me. (For one thing, I've trained myself now to expect that log file every morning. If I don't get a log file in my inbox every day, something didn't run.) The log file contains date-and-time-stamped information about what script was running. It tells me what file it's working on. It tells me how many records are in that file. And it tells me handy things like this...

Unknown field, will be ignored: Products::SKU_New_Calc
Unknown field, will be ignored: Products::SKU Old
Unknown field, will be ignored: Products::Image Size Calc

You don't even really have to know what Products::SKU_New_Calc is. It says, clearly, that it doesn't know what it is either and is ignoring it. So right there I know what happened. I can go look at the script and find out what fields it was expecting, see that they have slightly different names, and then I know why it happened.

In my response to the client, I propose updating the field names in the script. It's a simple way to fix it, but it's their decision. It turns out the changing of the field names wasn't expected, so now the client knows something is up on their end.

Building this kind of information into your code helps when things go wrong. In many ways, it's what separates good code from really good code.

Our 101st (and 102nd) Drupal Update
Ethan
January 4, 2012

As you may know, our website is built with Drupal. When I took over responsibility for maintaining the modules in late 2009, I began keeping track of what modules I was updating and what the priority was. This morning I rolled out our 101st module update (Nodewords). It was quickly followed by our 102nd module update (Views). It's about time we launched a new website, right?

Bacon
Paul Hook
December 23, 2011

Holiday brunch at Zone 5. Eggs, pancakes, fruit and muffins. Oh, and LOTS of bacon.

Happy holidays!