About a year ago, I wrote an article on this website about Version Control.  In that article, I touted the glory of Subversion, and mentioned:

“I’ve since tried other VCS systems like Mercurial, Git, and Bazaar, but have not found any compelling reason to switch.”

Well, I’ve since found my compelling reasons to switch.  SVN lost some of our files, and it was a pain to do all sorts of stuff (get setup, keep clean, branch, merge, etc).  I won’t get into; there are enough rants about Subversion on the ‘net already.  We use Mercurial now, and boy has our workflow improved.

Mercurial is my new favorite child, because it’s easy to setup, easy to use, easy to branch and merge, and easy to teach to my students.  Oh, and it just works.  Sometimes I think it runs off magic.

In order to help my colleagues make the transition from SVN to Hg, I came up with a few diagrams to explain the workflow.  I thought I’d share them here.

Mercurial Recipe for Success

You will Need:

1. Mercurial.  Grab and install it from the official site.
2. Your files.  You know, all of those css, html, and php files that you’ve been working so hard on.
3. A repository server.  If you don’t have one, go get a free account at Bitbucket.
4. A web server.  Install Mercurial here too.

The Workflow:

Setting up a Mercurial Repository

Day-to-Day Developer Workflow

It’s the perfect time to think about it.  With disaster on everybody’s mind, and this being the season of resolutions, it’s time to think about your disaster recovery strategy.

Recently, a major department right here at FSU suffered catastrophic loss to their servers, with scant means of quick recovery.  Their site was down literally for weeks as staff from all over the University scrambled to assist them in recreating the critical pieces.  They lost of a lot of time and money.

I’m absolutely sure they’ll be super-prepared next time, but you don’t have to wait until something tragic happens to be prepared!

Disaster Recovery Enterprise Planning = Big Words (Scary!)

When I was an IT Manager n00b, I thought that planning for disasters was intimidating and complicated.  I thought it took a team of folks working around the clock, military-style, to prepare for incidents.  I was encouraged to believe this by colleagues constantly talking in business-speak, conference sessions talking about things like “DR evaluation metrics”, and by big ugly books that take days to even read through.

In the meantime, while I was being intimidated by all this “enterprise” stuff, we went without reliable backups.  We would have been Scre-ewed if something happened.

1. Embracing Common Sense

Okay, just ignore all that business-speak.  Let’s start with the basics:  If you’re not backing up your data, put down the big ugly DR books right now and go setup a backup.

No, seriously, do it right now.

This does not have to be complicated.  Go find an external hard drive, then find out where your data is on your computers or servers.  Plug the hard-drive into the back of the computers and copy the folders with your data.  Do this every day, and you have a basic disaster recovery strategy!

Pro Tip: If you’re using Windows, I’m a big fan of using Teracopy when I have to copy lots of data at a time.

You get bonus if you copy the data to two hard-drives and take one off-site every day.  Now your data is in two geographic locations on three devices.

See? Easy.  Now that you’re off and running, you can make your life even easier by automating your backups.  If you’re not excited about doing a bunch of geeky tech stuff to get your automated backups working, go convince your boss to spend a few bucks a month on cheap, easy-to-setup online backup services.  If he doesn’t want to spend the money, you can scare him with many horrifying stories of data loss on the Internet.

2. Being Prepared

Next Step: Just sit down in a quiet place for a few minutes and think about the things that could go wrong:

• “My server could suffer a catastrophic hardware failure”
• “My backup data could be corrupt”
• “The building could burn down”
• “We could get robbed”
• “An employee could go apeshit and format the C: drive of the server”
• etc..

Now consider which three or four of those scenarios are most likely to happen in your department. You’ve just considered your risks.  Now, for each one of those scenarios, think about (a) what you can easily do to guard against them and (b) what you would have to do to recover from them:

• Buy a second, backup server (or set an old computer aside to act as server temporarily in case of disaster).
• Keep two backup copies instead of one and periodically test opening files on the backup.
• Take backups offsite so that the data doesn’t burn down with the rest of the building.
• Lock the servers in a room without windows.
• Keep backups (already done), and make sure employees don’t have too much access to the server.
• etc..

If you write all of this stuff down somewhere and tell your boss about it, you have a basic DR plan!  Go have a beer.

3. Building Your Kit

Now that you are creating backups and thinking about our risks/responses, it’s time to build your Disaster Recovery Kit! Put this kit somewhere out of harm’s way, and have it handy in case you need it.  Here’s mine:

1. A camcorder bag — I like this, because it’s easy to carry and has a lot of compartments for all the stuff below:
2. Operating System Boot discs – In my case, Ubuntu Server 8.04
3. GParted Boot disc — For formatting and partitioning systems on-the-fly.
4. Cables – Standard power cable and USB cable.
5. Backup hard drives — Two.  They are my offsite copies of all our data.  I rotate them and keep them encrypted.
6. Flash light – Small and compact, for poking around inside computers or navigating server rooms in the dark
7. Thumb drive — Includes a backup of my server setup procedures/changelogs, systems passwords (in KeePass), and a bunch of portable apps.  Updated weekly.
8. Printed copy of contact information for key stakeholders — My IT colleagues, clients, and my boss, so I can keep them updated.
9. Geek tool kit –  Something like this.  Includes screwdrivers, etc.
10. External SATA Hard Disk Reader – Something small and compact.  In case I need to rip a hard drive from a computer and get the data off quickly.
11. A big sheet of paper that says “Don’t Panic“
12. Music CD with high-energy power music on it.
13. Energy supplement — Or a flask of whiskey, depending on how you roll.
14. “Getting started” guide – A piece of paper, right on top, that explains briefly how to use the kit.
15. Checklist — With all of these items on it, and with weekly DR Kit maintenance procedures.

There, now I can sleep at night much better.  What’s in your DR Toolkit?

The problem, succinctly stated, is: How do you best organize 14 weeks of study to teach PHP to a group of motivated College students?

I know they must be pretty motivated, because they’re signing up for the class despite the fact that it starts at 8 am.

This Fall, I will  be teaching a course in Web Application Development at FSU.  The topic will be server-side scripting, and the focus will be PHP.  Since I’ve taught this course before, developing the curriculum won’t take months, but I am nevertheless spending a fair amount of time updating and tweaking for the next go-around.

A quick Google Search for “Teaching PHP” brings up only a few relevant links, mostly message board discussions.  “Server Side Scripting Curriculum” doesn’t return much either.  Likewise, WaSP have not yet published their recommended server-side scripting course recommendations.

So, I’ve had to come up with a lot of the course unilaterally.  The learning objectives are as follows:

By the end of the course, students will understand:

• Basic programming skills
• Web application development principles
• How to find and use PHP resources on the Internet
• How to manage tasks, bugs, and revision control mechanisms for web projects

By the completion of this course, students will be able to:

• Program and deploy simple scripts in PHP
• Process web-based input and output in PHP
• Build multi-file PHP applications
• Connect PHP applications to a database
• Design a simple dynamic website using PHP, MySQL, HTML, and CSS

After a few iterations of course development, here are the topics I have planned to discuss, in order, thus far:

• The current “State of the Internet”
• How the technology works – Web servers and clients
• Eclipse setup and good  practices for personal workflow
• PHP basics – Syntax, variables, arrays, functions, iterators, etc.
• Form processing (GET/POST)
• Database integration
• Multi-file application organization
• Classes and objects
• MVC frameworks
• Revision control and associated workflow
• Basic management: Ticket and bug tracking
• Web Services – SOAP and RPC
• XML integration
• Comprehensive application organization

That’s a lot of information.  Fortunately the students will have object-oriented experience AND database experience.  So, we should be able to leap off the cliff quickly and into the world of iterators, encapsulation, and inheritance.

I’ll post the week-by-week calendar when I finalize it, which necessity dictates will be very soon.  Feel free to grab it and use it for your own courses, or tell me what I can improve on.

UPDATE: The course calendar and other details are live online at http://lis4368.cci.fsu.edu