Kelli Shaver

6 months ago

Geeklist Circle Icon

I couldn’t find a good Geeklist circle icon anywhere, so I made one. Here it is for anyone else who may be searching.

You can download the SVG file here.

6 months ago

Another Redesign

Oops. I did it again. I redesigned my site.

I liked the last version, but it didn’t feel quite as refined as I would have liked, and there were some things about it that I wanted to change. So I simplified what was there, rewrote some of the content, and cleaned things up a fair bit. In the end, the new version doesn’t resemble the old that much at all, but there are some hints of the previous design.

It’s a small, single-page site, but there are a fair number of details that went into it. Here’s an overview of my Mobile First approach and some of the things I did:

1. I started by creating a well-formed, semantic HTML document and then went the progressive enhancement route with the CSS, working my way up from the phone to the desktop with media queries, and adding an IE-specific stylesheet at the end for the desktop layout.
2. I used additional media queries to provide retina-quality graphics at higher pixel densities.
3. I added home screen icons for mobile, under the perhaps arrogant assumption that someone, somewhere, might want to add me to their home screen.
4. I used CSS3 gradients and other effects to add little details. This allowed me to avoid using images, which kept the mobile payload low and eliminated issues with scrolling. I used these as decorative enhancements, so the lack of them in IE won’t have any effect on usability.
5. I set reasonable tap target sizes. They’re not quite the optimal 44px, but they are fairly large. If they prove to be too small, I’ll go back and make them larger still.
6. Static assets are cached via appcache, so the site will work offline. I made sure to host fonts locally so that they could be cached, as well.

What I didn’t do:

There’s no JavaScript on the page, not because I have anything against JavaScript (I don’t. I love it), but it just wasn’t necessary for the simple design I was implementing.

I’m not binding to touch events. All of the links on the page go to external sites or trigger some sort of action like opening an email or making a phone call. They’re not really interactions with the page, itself. If I’d had a more interactive design that required user participation, I’d have used touch event binding for better performance and a more responsive UI. I think that’s a really important step, but in this case, it simply wasn’t needed.

6 months ago

Writing Maintainable Code

I have a large, long-term project, an API written in PHP, that I’ve been working on for the past 22 months. The initial build took six months of that time and the remaining sixteen months have included ongoing maintenance, bug fixes, enhancements and new features to the production code. It handles a few gigs of data and a couple hundred thousand requests per month. It’s not the biggest or most heavily trafficked API out there, but it gets steady use and performs an important job.

After nearly two years of working on this system, I’ve learned some lessons, at times the hard way, about maintaining code over long periods of time. Here’s the list of Important Things to keep in mind. None of them are particularly novel or ground-breaking, but they’re all worth repeating.

Planning is Essential - Maintenance gets a lot easier when you start with a solid foundation. If you’re constantly rewriting spaghetti code or changing working code to meet new requirements at every turn, you’re doing it wrong. Start from the beginning with the understanding that your code will need to grow and evolve over time. Modular, object-oriented code with good dependency management and encapsulation will give you the most flexibility for working on and adding to the code. Try to avoid denormalizing your database as much as possible.

Document Everything - Make good comments in your source code, but don’t just stop there. Take the time to write out some comprehensive documentation for how the system works, expected behavior, known issues, up-to-date change logs, etc. Not only does this make it easier to go back and edit the code long after you’ve forgotten what it does, it becomes invaluable when you need to add a new feature. Being able to read documentation and get a comprehensive look at how everything works together is crucial to extending functionality of the existing application.

Keep Your Version History Clean - This goes along with documentation. Make useful commit messages and squash/merge/rebase as-needed to keep version history clean and logical. Adopt a branching model that makes sense for your project and stick to it.

Strive for Good Test Coverage - Good automated tests help you find bugs in your software and they can also help step you through the process of how the software works (which can be handy if you haven’t touched it in 6 months). Being able to make changes to the code and then run a test to make sure you haven’t broken any dependencies is invaluable.

Perform Regular Code Reviews - It’s a good idea to review your code on a regular basis, let’s say, every 3 months or so. It will help keep things fresh in your mind when it comes time to make changes, and it will help you identify problem areas.

Cleanup and Iterate - If you’re still working on the same project after two years, chances are, the new code you write today is better than what you started with. There’s also a good chance that you’ve been in a situation where a patch needed to be written quickly and making the production code work was more important than making it elegant. So once you’ve done your code review, go back and clean up anything that sticks out. Messy code is like weeds in a garden. It may not be a big deal at first, but left alone, it multiplies and grows over time until it gets out of hand.

Test and Staging Environments are Important - Since your code is going to grow and change and be rewritten, patched, refactored, and otherwise modified after it’s already in production, having some test environments where you can hammer away at it is essential. You never want to push untested code into production and you can’t properly test unless you can put it though some real-world use.

Keep it Simple - Don’t be clever with your code just for the sake of being clever. The best solutions are often the ones that are the simplest to understand. It’s worth being a little more verbose if it means your code will be easier to read and understand. Your code will likely out-live your time on the project, and even if it doesn’t, chances are you won’t remember exactly what was going through your head when you devised that clever solution that now looks like more like a random string than working code.

Keep it Organized - Similarly, keep your files and the code itself neatly organized and well-formatted. Pick a style and stick with it, and give your project some structure. Order and neatness makes reading, understanding, extending, and debugging much, much easier.

Conclusion

This list should apply to any project, really, but having worked on the same code for two years, it’s easy to identify situations where they really become useful. Mostly it’s about discipline and detail, which can get overlooked when you’re under pressure to meet a deadline or have a lot of reapply complicated problems that need solving. So I think it’s good to have a reminder every now and then.

6 months ago

Playing with Phonegap

OK, so I’m slow… I’ve never actually done this before.

I’ve done a lot of development for the mobile web, but it’s always either been A) purely web-based, or 2) handed off to someone else who’s done the building, packaging, and distributing.

So tonight I built a little app - It’s a FUDGE dice roller, with +/- modifiers (good for use with the Dresden Files RPG and other FATE-based systems).

I got it working in the browser, and in the iOS simulator (I don’t yet have the Apple developer creds to load it on my iPhone). It’s super-simple, and doesn’t do much, but what it does do, I try to do right, e.g. binding to touch events, good, clean code.

I added a sound effect for the dice roll and was able to get thsi working fairly quickly in the simulator and in the browser (Chrome on the desktop, iOS, and Android) using the HTML5 audio tag.

Then I decided to build an APK and load the app onto my Nexus 7.

Guess what? Phonegap doesn’t support the HTML5 audio tag on Android.

So if I want this to work, I’ll have to use the Phonegap Media API to get the sound playing on Android. I’ll admit, it feels like a slightly more solid implementation anyway, but still…

I’ll tackle that another day, when I’m not so tired.

7 months ago

A somewhat random general update

Aside from reblogging a few things, I haven’t posted much lately, but that doesn’t mean I’ve been idle-more the opposite, really.

I’ve been dealing with a minor eyelid infection - nothing serious and it cleared up quickly but it did make things blurry for a few days.

I’ve been head-down in some code on a fairly large project, learning a few new things along the way and dealing with some frustrations.

I’ve been learning Lua in my copious free time (read: I occasionally get to poke at Lua). I like it. I’ve barely had a chance to do anything with it, but picking it up seems like it will be super easy.

I have been (with the help of a very dear friend) re-examining myself, career-wise, and how I work. It’s a work in progress, but I’m getting some useful insights. I’m sure I’ll write more about it later.

I’ve been doing a lot of thinking over the past day or two about how projects evolve (or perhaps how they devolve) over time and some ways to deal with that, so I want to do a post about that, too.

I just need time. I’m looking forward to some time off over Thanksgiving. :)

7 months ago

7 months ago

Early sketches from the web’s finest

layervault:

Pen and paper

Most designers are accustomed to starting their work on paper. If you’re a designer, you’ve probably got a notebook or two sitting around with random brilliant sketches. Often the initial sketches themselves are something to be proud of — and it’s a shame that no one ever sees them.

Have you ever wondered what others’ sketches look like? We did. When designers put pen to paper the results are quite different. We’ll show you.

Read More

7 months ago

Code Poet

In Hexadecimal:

Good coffee, less a tall latte…

7 months ago

What Programmers Want

7 months ago

A jQuery Plug-in for multiple file uploads

Today I wrote a small jQuery plug-in for uploading multiple files. This is not an AJAX file upload script. What it does is simply, from the end user perspective, give you one file upload box that you can “re-use” to select multiple files, which it then lists, like so:

In reality, what’s happening behind the scenes is that once the file upload field is populated, the script just moves it out of view and adds another one in its place, adding the selected files to a list below the box. Un-checking files in the list removes the associated file input box (which is hidden since it resides outside of the viewport) and the list item. The plug-in then removes any empty file input elements when the form is submitted.

The plug-in works for multiple file inputs in the same form, and multiple forms on the same page. Each file input has its own configurable options, like the number of files that can be uploaded, and what file extensions are allowed.

It works in Firefox, Chrome, Safari, Mobile Safari (on iOS 6), IE8 and IE9. I haven’t tested it in IE7 or Chrome for Android, but suspect it will work for them, as well.

You can find the code and examples on Github.