Archive for February, 2013

How To Use Firebug to Fine-Tune Mobile Website CSS

February 28th, 2013

If you are doing front-end web development, you likely use Firebug. It’s a Firefox browser extension that provides all the basic tools you need to debug a website. Development tools in all of the modern browsers are based on the gold standard set by Firebug.

One of the most common uses of Firebug is to make changes to your CSS in real time. You can experiment with different styles until your layout looks right, then simply cut and paste everything into your stylesheet.

This works great for desktop browsers, but mobile browsers don’t have development tools. If you want to debug your mobile layout, you need another browser extension that allows you to switch the user agent. There are a number of good ones out there. I’m currently using User Agent RG for Firefox. Once this extension is installed, you can change the user agent string by going to the “Tools” menu and choosing “User Agent.” Simply choose a mobile device and you can get an idea of what your site looks like on a mobile device.

It’s important to understand what the user agent switcher does (and doesn’t do). What it does is tell the browser the type of device that you are using to browse the web. The Firefox plugin basically lies and says “I am using an iPhone” (or whatever). If you have a mobile version of the website, that version will be displayed.

What it does NOT do is make Firefox act like Mobile Safari, or any other browser. If there are browser-specific layout issues, you will not be able to see them with the user agent switcher. Luckily, mobile device browsers are fairly standards-compliant, so very few CSS issues are browser-related. Browser-specific issues like HTML5 video issues (*cough* Mobile Safari *cough*) still need to be debugged with that browser.

The other thing that user agent switching doesn’t do is resize your site to mobile browser dimensions. To get an accurate sense of how your site looks on a phone or tablet, you will probably need set a body width in your CSS:

body {
    width: 320px; /*older iphone width*/

This way, you can lock it to the dimensions of the device you want to test and tweak the CSS with Firebug to fix any layout problems.

This has been the quickest and easiest way I have found to fix mobile-specific layout issues. Good luck!

It’s All About The Washingtons

February 21st, 2013

I made a dollar from my blog today. So, my plan to get rich is all coming together…

wasted potential earns its first dollar
I’m kidding, of course. This all started last year when I checked my Google Analytics and noticed that I was actually starting to get some decent traffic on this site. I started toying with the idea of putting some ads on the site. I’d be really happy if the ads made enough money to pay for my hosting fees.

But I’m kind of ambivalent about having ads on the site. I feel like the world needs less visual clutter and an ad is an implicit endorsement of the product, which I’d have to be comfortable with. Instead, I decided to add a PayPal button to the site and see if people would make donations. It’s a bit of an experiment.

My hosting fees are only about $7/month. I get about 1500 visitors to the site on average week. So, to cover the site hosting, I need a conversion rate of less than 0.12%. It seemed like an achievable goal, but since I added the PayPal button in June 2012, I have not had a single donation…

…UNTIL TODAY! It really made my day to get an email from PayPal telling me that someone had donated a dollar. You have earned some serious karma points today for a mere dollar. Thank you!

Emulators Are For Chumps

February 13th, 2013

I have a lot of old-school game consoles and I wanted a way to keep them hooked up at all times without having them take up too much space. This my solution. Check out the video below for a look at my new gaming cabinet:

Version Control Throwdown – Git vs. SVN

February 7th, 2013

Version control throwdown - GIT vs. SVNI see a lot of forum threads and blog posts on “which is better – Subversion or Git? The real question should be “which is better for my workflow – SVN or Git?” I’ll attempt to help you sort it all out.

I’ve been handling version control on my projects with Subversion (or SVN, for short) for the past couple of years. I switched to using Git about 6 months ago and have been using it for version control in most new projects. Git and SVN both have their strengths and weaknesses. Which one you use should be based on the type of work you’re doing.

The way I used to handle version control was simple. Any time I made any serious updates to a project, I duplicated all of the files into a new folder and started working. That way, I still had a copy of the previous, stable version if I needed it. This is a ridiculous way to handle it, but it’s simple and it works, as long as you remember to duplicate the files before you begin working.

SVN is an older model of version control that handles this for you. The files live in a repository on a remote server and you create a local copy on your computer (or even multiple computers). “Updating” pulls the latest version down from the remote server and updates the files on your local version that are out of date. “Committing” pushes any local changes back to the remote server when you are done working.  You can revert back to an older version of a project (or even a single file) if you need to. It’s a great way of tracking a project without needing to retain duplicates of every file. It is designed purely for keeping track of project versions – If multiple people try to commit changes to the same files, a conflict occurs, which you must resolve, usually by comparing the 2 files and manually merging them. The goal is to keep your local and remote repos in sync at all times. I used Tortoise as my SVN interface and I’m fairly happy with it.

Git differs from SVN in a fundamental way. It’s a distributed version control system, meaning that it’s designed for multiple developers to work simultaneously on the same project. You again have a remote master repository and a local copy on your machine. The big difference is that when you “commit” a change, the changes are only made to your local repository. Then, when you have finished your work and the local version is stable, you “push” all of your local commits to the remote repository. The idea here is that you can have version control on your local machine and only merge your changes into the master when they are finished and stable.

Git also allows for “branching,” which means that there are different versions of the project stored in different branches. Master is the stable, production branch. Then you could create a branch for a new set of features that you are developing. This way, another developer can make bug fixes to the Master branch while you develop new features on the other one. Then you merge them together later. Git allows for many branches to be created, so different developers can work simultaneously without jeopardizing the stability of the Master repo. I’m not sure why, but Git is also generally faster than SVN for updates and commits. A lot of Git users do everything on the command line – I prefer a decent GUI, so I use SmartGit. Mac users tend to like SourceTree.

So, from my description, it would sound like Git is superior, but that isn’t completely true. It really depends on your project.

Git is designed for large projects with multiple developers working simultaneously. It handles this use case very well. The branches help prevent developers accidentally overwriting each other’s work, or creating instability in the master repository. The downside is that Git has a much steeper learning curve than SVN. I’ve been using it for months and I’m still getting the hang of it.

SVN, on the other hand, is really simple to work with, if you only have one or two people working on a project and the chances of creating repository conflicts are small. So, if you don’t need the “distributed” part of version control, SVN is a great choice.

Another thing to consider is the number of large binary files you will want to have version controlled. Binary files are non-text files, like videos and Flash source files (FLAs). Neither of these version control systems can keep track of changes in binary files, but SVN plays nice with large binary files – Git does not. Git purists argue that large binary files don’t belong in the repository, but I don’t necessarily agree. So, if you plan to have a lot of videos or Flash files in your repository, Git may not work for you. You can tell Git to ignore the large files, but that seems to defeat the purpose of version control.

remote svn repo on a usb flash driveWhich do I prefer? Again, it depends. For my projects at work, Git has been great (unless I need to version a bunch of videos, Then, it stinks). I have a handful of personal projects that I prefer to handle with SVN. I have a USB flash drive on my keychain that contains the remote SVN repositories. So, no matter where I am or which computer I’m using, I can update from the USB drive and work, even if I have no internet access. You can do this with Git too, but since I’m the only developer on these projects, I don’t need the fancy-schmanciness of Git and SVN is less hassle.

Hopefully, this will help you decide which version control system will suit your workflow. If you want to set up a USB thumb drive repository, here are simple instructions for setting up a local SVN repository. Here are instructions for doing it with Git.