development

I was showing my co-worker how easy wordpress blogs are and accidentally screwed up my site.  Because all the ports are locked down at work I wasn’t able to login and fix it.  My site went the whole day without CSS.  Lesson learned.

Recently one of the clients I work on had a major launch. This was a project months in the making and is making a major difference in their customer behavior. What I found disturbing was the fact that they launched it at noon mid-week. One of the things to consider when launching any update it when your customers are most active with the site.

If the proverbial “shit hits the fan” you want to interrupt as few people as possible, so try to plan your launches for late at night or very early in the morning, when traffic is low. Also it goes without saying thay you should always have a back-up ready to deploy at a moments notice. And if you don’t have a back-up, well, then you better be the best programmer on the planet because otherwise you are screwed.

One of the websites I worked on in the part consisted of two identical servers. One was called “staging” and one was called “live” the servers would copy over any new files at regular intervals, usually on the hour. This meant you could make sure everything was working prior to hitting live. The down side with this approach was you were scrambling to get the files in place prior to the copy time. If you only got half the files in place, you had to wait another hour to fix it.

There is a very simple rule in launching anything. Nothing launches Friday afternoon. Period. There is nothing worse than having a launch at 5pm on a Friday and having it go haywire. Your friday night is ruined, your weekend is ruined and the following week is ruined because you didn’t get a weekend.

Also, launches should not be just FTPing files onto a server. This is because ftping takes time, and customers interacting with the site will get half an old page and half a new page if they should happen to be watching at that specific moment.

The best way to launch a change is to copy the files to the server first, but in a different location. They should have the same folder stucture as the live site. Then copy the files into place. This is because folder to folder copying is much faster than ftping files so anyone requesting a page should either see an older version or the new version, no hybrid pages.

If it is done when traffic is low then you minimize the risk of thinks screwing up and give yourself time to fix anything that does.

Happy Launching!

Coders and programmers have the same issue that writers do. Proofing your own work is all but impossible. While Word has spell checker, what does the web have? Quite a lot actually.

The best place to start is Firefox’s extensions . To access them go to tools–>Add ons. In the bottom right of the pop-up window will be a link, “get extensions” to the extensions site. From there you can download a number of add ons. The two most important ones as a developer are firebug and web developer toolbar.

The web developer tools bar will allow you to turn off CSS, highlight specific parts of the page, and in the tools list of the tool bar you can validate CSS, HTML, check accessibility and more….

Firebug is also extremely handy. You can right click on any element on the page and select “inspect element” this will call up a window that will show where exactly in the HTML code that element is and all the styles that effect it.

Firebug will also allow you to check your JavaScript by providing greater information on errors that the browser usually provides.

Another tool I use occasionally is netmechanic. in their HTML toolbox you can provide a page URL and the website does the rest.

The really nice thing about netmechanic is it breaks down the results into digestible chunks that even the most novice person can understand. It will even make suggestions on how to improve.

With these tools you can make sure your code is clean and readable.