Last week, the University of Florida Web Administration team hosted the Environments for Humans - Web Accessibility Summit 2010 (#a11ysummit on Twitter). I was able to attend at no cost to my department. Being a UF employee has its perks from time to time.

http://environmentsforhumans.com/2010/accessibility-summit/

It was a great event with very knowledgeable speakers. The three big take-aways for me:

1. Valid HTML 5 is easier to write than XHTML.
2. Accessibility is not just for humans with disabilities. Search engine crawlers such as Google are "blind". Touch devices such as Apple iPad and Android are only going to become more common.
3. Standards compliance does not equal Accessibility!

Session Notes:

I attended a conference, yeah!

The Agile 2010 Software Development Conference was held in Orlando, Florida from August 9-13.

The last technical conference I attended was OSCON (Open Source Convention) 2006 in Portland, Oregon. Agile 2010 was a really great opportunity for me to jump-start my transition from system administrator to software developer.

I am part of a small, dispersed team. We currently have multiple active projects with each developer assigned to a project. We are already following practices such as Test Driven Development (TDD), but we have some challenges ahead if we wish to apply additional Agile practices throughout the team.

Before the conference, I scanned our office bookshelf and wrote down the author names from our most respected volumes. It was great to go to a conference and hear the authors speak on these topics and in many cases have a chance to talk with them. I learned something in every session.

Today was my first day back in the office and I immediately got to work trying to implement ideas from the conference. The first artifact of this effort is a shiny new story board that more accurately reflects project scope:



A few concepts presented by Scott Ambler (and others) particularly hit home with my project:

1. Yes, with Agile you still need to do Initial Requirements Envisioning and Initial Architecture Envisioning.
2. Identify major components / subsystems / services first.
3. Flesh out interfaces first... sometimes this is known as "API First".
4. Prove the architecture with working code.


Here are some interesting statistics shared by various speakers at the conference:

I'm really excited about my new position as a Database Analyst / Programmer with the Shimberg Center for Housing Studies . This was a lateral move within the University of Florida.

I have been wanting to shift into a web and database development role for a while now. I was lucky to find an organization that supports this kind of career transition (my previous positions included system administration and help desk components).

My first big project is to build a Data Warehouse, so I'm reading books and learning all kinds of new terminology. My mentor at the Shimberg Center is a believer in Agile programming and test-driven development, so I'm getting some superb on-the-job training.

Our web stack is FreeBSD, Apache, Perl, and PostgreSQL (FAPP anyone?). I will definitely have new challenges in this position.

Here is a picture of my new office, my new work computer (a Dell Optiplex 780 running Ubuntu Linux), and my nice windows that are pleasant even on a rainy day:

In a previous story, I showed What NOT to do in your server room. Over the past year I have been able to improve that server room a little bit. In addition to a general rack cleanup effort, I installed a whole new rack with square holes and plenty of cable management. The following pictures show the results.



Here are the racks from the front:

Leave unused cables in-place.  Do not use cable management.  Label no cables.

 

Use cables of inappropriate length (this is a SCSI cable!):