The client has a major page devoted to a line of products whose name is an acronym. Let’s say the path to that page is “http://www.site.com/usa” whereas the product’s acronym is “USA”.

Since the product is known as “USA” it’s quite plausible for a visitor to type in “http://www.site.com/USA” in the browser address bar. Unless you’ve done something through URL redirects or htaccess rewrites, that URL yields a 404 page.

It would be much nicer if instead of the 404 you redirect to ‘/usa’. You can do that with URL redirects either through Drupal or in .htaccess. I leave that as an exercise to the reader. That’s not what this post is about.

GORGES visits Ports of New York

Frederic Bouche of Ports of New York

Having found December a fairly difficult month to gather for a Holiday get-together, the gang here at GORGES decided to wait until January to share some laughs together outside of the office; laughs we had.

Being the adventurous group that we are, the gentlemen allowed me to lead them out of the office with blindfolds and pile them into chauffeur driven limousines to be whisked away to an unknown destination.  Much to their delight we arrived at Ports of New York, for a tasting and a fascinating history lesson of the making of Meleau specialty wines. Our charming host, Frederic Bouche, the owner is a fourth generation wine maker from France whose ancestors made wine in Bordeaux and Normandy. In 2011 he opened his own local winery here in Ithaca. We spent the next hour or so learning about how these uniquely mellow, (Meleau) but spirited wines are made here in Ithaca using grapes grown in the Finger Lakes.

Ah yes, and the proof is in the tasting.

As we moved on to the second part of our evening, only to step outside and discover it was more like December than December was, we were all in the holiday spirit as we

attempted to snowshoe over to Mira’s Mediterranean Bistro to join our better halves.

Ah yes, and again, the proof is in the tasting.

The class quickly became oversubscribed, and we opened up more student slots thanks to parents who agreed to help with the classes and supervision.  I organized the classes so we would build robotics projects in preparation for the Cornell Nanotech sponsored FIRST LEGO League Expo, which was held January 26th, 2013 at Cornell’s Duffield Hall.

We spent the our first five classes learning the basics of gears, pulleys, motors, and sensors.  We introduced the LEGO WeDo Software program for controlling motors and integrating sensors to the students.  The remainder of the classes were spent applying what we learned to building three different projects for presentation at the Expo event.  There were 22 teams at the Expo, and each of our three teams did terrific!

I loved working with the students and seeing the creative structures that the students built.  I hope to teach this course again next year – and thank you to GORGES for accommodating my volunteering endeavor.

I did a quick investigation into TRAC configuration yesterday, and discovered how to customize the ticket workflow to better fit our process.

Out of the box, the normal workflow for tickets is pretty simple: a ticket start out as “new” – it is then assigned for someone to work on, eventually accepted as done, and then finally closed. There are couple of ways to deviate from this process, such as when the work gets rejected and needs more work, or when the ticket needs to be reassigned for somebody else to work on for some reason, but that’s generally how it goes.

Our process on larger projects is quite a bit more detailed than that – in fact, most places I’ve worked, the process is usually a bit more granular than that. Our process is something along the lines of this:

1. A new tickets is created
2. The ticket is assigned for someone to work on.
3. A solution in implemented
4. The solution is deployed to a test (aka “staging”) site, for review
5. The work is reviewed and accepted

Again, there are a couple of ways to deviate from that workflow, includes the ones mentioned before, and also in some cases closing a ticket (for example because it’s invalid) or reopening a ticket that had already previously been closed.

The Wrong Approach

Some people resort to simply adding a new property to tickets, which is very easy to do – here’s a snippet from a custom option added to the “trac.ini” file:

[ticket-custom]
progress = select
progress.label = Progress
progress.options = new|assigned|implemented|reviewing|accepted|rejected|closed
progress.value = new


This adds a new drop-down to tickets, labeled “Progress”, with the choices you can see defined by the “progress.options” setting above. You will need to make some adjustments to the reports, because custom values don’t show up by default, but that’s doable.

Why is this wrong?

Ponder for a moment why we had words like “new” and “assigned” in our Progress field – words which also appear in the ticket status.

The problem is that Progress is basically synonymous with Status, and what we end up with is basically two different Status settings. This causes a number of problems, including the fact that our new Progress field doesn’t actually mean anything in TRAC as such – it’s just a label. And for another, the fact that you can create conflicting Status and Progress combinations – for example, your ticket could be “accepted” and “rejected”, at the same time!

So without a fair amount of discipline, and agreement and understanding of how to manage these values “correctly” amongst the team-members, this is not really going to work well.

The Right Approach

Fortunately, when you look into it, and experiment with it for a bit, you will discover that the ticket workflow in TRAC is in fact incredibly flexible!

It’s a bit hard to understand and configure than a simple custom field, but so much more valuable, as you can fully customize this to fit your team’s workflow.

Here is the workflow-configuration I came up with, implementing the workflow I described in the beginning of this article:

[ticket-workflow]
leave = * -> *
leave.name = No status change - leave
leave.operations = leave_status
leave.default = 0

assign = new -> assigned
assign.permissions = TICKET_MODIFY
assign.operations = set_owner
assign.name = Assign
assign.default = -1

implement = assigned,rejected -> implemented
implement.permissions = TICKET_MODIFY
implement.name = Implemented
implement.default = -2

deploy = assigned,implemented,rejected -> reviewing
deploy.permissions = TICKET_MODIFY
deploy.name = Deployed for review
deploy.default = -3

accept = reviewing -> closed
accept.permissions = TICKET_MODIFY
accept.operations = set_resolution
accept.set_resolution = fixed
accept.name = Accept
accept.default = -4

reject = reviewing -> rejected
reject.permissions = TICKET_MODIFY
reject.name = Rejected (needs more work)
reject.default = -5

close = new,assigned,implemented,reviewing,rejected -> closed
close.permissions = TICKET_MODIFY
close.operations = set_resolution
close.name = Close
close.default = -6

reassign = assigned,implemented,reviewing,rejected -> assigned
reassign.permissions = TICKET_MODIFY
reassign.operations = set_owner
reassign.name = Re-assign
reassign.default = -7

reopen = closed -> assigned
reopen.permissions = TICKET_CREATE
reopen.operations = set_owner
reopen.name = Re-open and Assign
reopen.default = -8

Each section of this configuration defines a single possible action in the workflow – the activities you can perform: assign, implement, deploy, accept or reject, close, and reassign or reopen when needed.

The first setting for each defined action (with the “->” symbol in it) defines allowed status(es) and the new status after performing that action – for example, the “deploy” action is defined as “assigned,implemented,rejected -> reviewing”, meaning you can change the ticket-status to “reviewing” only when the status is “assigned”, “implemented” or “rejected”. Note that the statuses themselves are not formally defined in the configuration file – the possible statuses are implicitly defined by configuring actions.

The “permissions” setting is optional, and defines what level of permission is required to perform the action. For the most part, the right to modify a ticket (TICKET_MODIFY) is enough – but in our case, we think that reopening a ticket should only be allowed if you’re allowed to create new tickets (TICKET_CREATE).

The “operations” setting defines one or more operations you want TRAC to do when this action is performed. This affects the user-interface – for example, the “set_resolution” operation (which we used for the “close” action above) displays with a drop-down to select the resolution. Note that the “set_resolution” operation has an optional “set_resolution” setting, which allows you to specify one or more resolution-types allowed for this action – for example, the “accept” action we defined, only allows one resolution: “fixed”.

The are two more simple, but very important (and underused) settings for actions. The “name” setting defines how the action is displayed – for example, “Re-open and Assign” is more descriptive than simply “reopen” – use this setting to clarify the meaning of the action and how or when to use it. And finally, the perhaps somewhat misleadingly named “default” setting, which actually defines the priority (sort order) of available actions in the user-interface. This is important, because it enables you to communicate which action is most likely next, by displaying it first. Oddly, the options are sorted backwards by this value, which is why I used a negative number in our configuration.

Conclusion

TRAC is a very powerful tool that comes with a lot of humble (sometimes underwhelming) configuration out of the box – but when you look under the surface, it really is an incredibly powerful tool with lots of optional features and an incredible degree of flexibility, allowing you to adapt it to pretty much any work-environment.

I hope you enjoyed this little tutorial and a glimpse of our process.

Developers discuss their solutions after a coding session

The coderetreat phenomenon has only been going for a few years, but it has exploded into a worldwide phenomenon. This year an estimated 160 sessions were held simultaneously on December 8, in cities on every continent (except Antarctica, but who’s counting?).

The idea of coderetreat is to get developers together to practice their craft – “practice” as in “practice the violin.” Musicians and other creative professionals spend a lot of time practicing to improve their skills, but professional software development usually takes place in an environment full of deadlines and deliverables, which can make it difficult to experiment, explore, and learn effectively.

The coderetreat format removes these day-to-day pressures so that developers can take chances, try new ideas, and see how far they get. Pairs of coders work together in 45-minute sessions to try to solve a problem, but to stress the “no pressure” aspect, they are required to delete their code at the end of the session. This feels weird at first, but it becomes liberating.

Another way the format gets coders away from the day-to-day is by giving them a problem that they could probably not solve completely even if they tried. Teams are asked to create simulations of Conway’s Game of Life – a generative process defined on a grid in which very simple rules can give rise to fascinating self-reproducing patterns. In each session the pairs are asked to try the problem using different approaches or constraints, and the whole group shares their findings afterwards.

Coderetreat is also about promoting the use of test-driven development, a process that makes it easier to build quality code by revealing when things break in the process of refactoring. Good code is code that can be changed and improved over time, and TDD helps to make this change painless. Participants were encouraged to use TDD techniques as part of the exercise, in hopes that it will become a part of their everyday toolkit.

Thanks to David Furber for organizing the event, Travis Vachon for facilitating, and to Singlebrook Technology, Think Topography and Incandescent Software for being local sponsors along with GORGES. I also enjoyed meeting a bunch of developers from these and other firms, and hope that this will become a regular event!

Reginald Braithwaite set the tone with his keynote, ”Why PHP could be the most important programming language in the world.” Though the title sounds like flamebait, his main point was that PHP makes it easy to get started, which will tempt more people to try things, which will lead to more innovation.

Eric Hogue gave an intro to Jenkins and Continuous Integration - Jenkins is not so much a tool in itself but a tying-together of lots of existing tools for things like unit test automation, to make it easier to publish code frequently without fear.

Adam Lundrigan and Hugo Hamon gave talks about what’s new in the Zend and Symfony frameworks, respectively, and these and several other talks echoed a common theme: rather than being wedded to a single framework or language, developers should choose what works best for a given task, from the rich buffet of options available in the PHP world and elsewhere.

Rafael Dohms gave a great talk about how to fix common code mistakes, and a second one about Annotations in PHP, featuring a plug for our own Rasmus Schultz’s nifty annotation tool, and he and Rasmus had some interesting discussions afterward about different approaches.

We sat in the front row, like a couple of nerdy fifth-graders, for Larry Ullman’s talk about Yii, our go-to PHP framework at GORGES. We were mainly interested in getting the scoop on Yii 2.0, which is supposed to be hitting alpha around the beginning of the new year, maybe. One tidbit was that the whole thing is being rewritten to more modern coding standards (even more awesomeness?), and the API will not be backward compatible from 2.0 to 1.x. It will also require PHP 5.3.

Joel Clermont gave a nice talk about Hypermedia APIs, a.k.a. (to some, at least) REST. Like many other speakers, Joel strenuously avoided dogma, which I found quite refreshing.

Finally, just when we thought we were running low on acronyms, Anthony Ferrara explained how to stop being STUPID and be SOLID instead. I’m still practicing expanding those abbreviations, but again some very practical tips on building better software, regardless of your language, platform, or even paradigm (did you know that there are at least six ways to complete the phrase “_____ Oriented Programming”?).

So all in all, an enjoyable and education trip to my homeland!

The <b> and <i> tags have been generally dismissed, in favor of <strong> and <em> which have semantic meaning.

But as they pointed out in the twitter bootstrap documentation, <b> and <i> are still valid!

Most people seem to think they were deprecated because they have no semantic meaning – that was certainly my impression.

But they were not deprecated – in fact they were kept around for the very same reason – because they have no semantic meaning.

In other words, if you need to highlight words of phrases without conveying additional importance, you should be using <b>, while <i> can be used for example to stress technical terms or voice, again, without communicating anything semantic, just for visual distinction.

This may seem like a tiny, irrelevant thing, but I find these details can be helpful when thinking about HTML as a “rich text” medium.

Brad Treat gave a talk last night about his entrepreneurial philosophy, and also anecdotal stories from the multiple startup companies he’s been involved with.

Thank for sharing, Brad, and good luck to all the PopShop entrepreneurs.  There are several more events scheduled this week, including some success stories from the Cornell 3-Day Startup event in February.

Building a website to comply with Section 508 or WCAG accessibility standards can mean meeting a number of specific technical requirements.  To assist in building websites that meet these standards, GORGES has found a number of tools that ease the development process.

Total Validator Tool will validate the markup of a web page against Section 508 and WCAG standards.  Getting the markup to validate to these standards helps prepare the website for visitors using screen reader software. Total Validator Tool generates easy-to-follow reports which detail where the markup of a page does not meet the accessibility standards.  From this report, developers can easily see what changes are necessary.

However, once the website markup meets the appropriate standards, there are other aspects of the standards that are beyond what the Total Validator Tool is designed to detect.  These include considerations for visitors with color blindness and preparing any video used on the website for visitors who may be blind or deaf.

Vischeck is a service that will simulate colorblind vision.  Images or screenshots of a website can be uploaded and processed for free at the Vischeck website.  This can give a general sense of how a website may look to those with a form of color blindness.

To ensure a website is usable by those who are colorblind, checking the contrast between foreground and background colors is essential.  The accessibility standards indicate what contrast ratios are necessary.  The WebAIM Color Contrast Checker will provide a ratio based on provided colors while the service Check My Colours will analyze the colors used on an entire site.

Universal Subtitles is a service for adding captions (and translations) to embedded video.  This service is compatible with many popular video hosting services and video players.

JW Player is good option for embedded video that is self-hosted.  It can meet some of the stricter versions of the accessibility standards using the optional Captions plugin and Audio Description plugin.  This includes not only closed captions but closed audio descriptions.  A closed audio description is an additional audio track that may sometimes be needed to describe the video scene to visitors who are blind.

For an overview of making video accessible, a good document can be found at the JW Player website titled “Making Video Accessible.”

Commonly used screen readers include JAWS and Window-Eyes.  For testing with a screen reader, an article on the Yahoo Developer Network suggests using a free and open source screen reader called NVDA.  The article “Easy Accessibility Testing with the NVDA Screen Reader” states:

“NVDA for Windows is one of several screen reader programs available on the market today. NVDA is free and open source. It is very strict in how it treats web pages and thus can serve as a perfect testing tool.”

By utilizing these tools, many of the challenges of meeting accessibility standards can be more easily overcome, and your website will become usable by a larger audience.

Websites and apps are not commodities and the purchasing of them is not a one-night-stand. Websites and apps are born into dynamic environments. Their full value is realized when they are maintained current with those environments. The developer relationship established during the initial development is part of the purchased value. Economies accrue when a structured relationship is maintained.

A Maintenance Agreement provides the budget to prevent obsolescence. The sad news is that a new website or app is becoming obsolete even as it is built. All three sectors of the technology advance rapidly.

• New display and interaction devices replace the old at increasing rates.
• There is daily industry news about greater power in databases and middleware.
• Methods-of-use, ways of thinking about these technologies, sprint into our lives.

The users of any valuable website or app will chafe immediately when it does not take advantage of this or that new device, or some new way of searching, or some social opportunity. Staying atop these concerns is the noble use of a maintenance agreement.

A Maintenance Agreement budget also should be provided for installing important updates to the underlying software. The price should be small, maybe $250 per event, maybe two or three events per year. Security updates in particular must be done.

A Maintenance Agreement provides a management structure for all the above. There is a prioritized wish list, a clear line of communication, and a non-intrusive billing arrangement.

The Maintenance Agreement budget is not for hosting the app and ensuring its connectivity. These services are budgeted under Hosting Agreements.

GORGES would be embarrassed if Maintenance Agreement budgets were spent mostly on fixing the app. In some cases this is appropriate use, but there should be very little of this. Websites and apps are warranted for thirty days after going live and after major upgrades. Clients should test the app thoroughly before and during that period to take advantage of the warranty.

The best websites and apps pay their own way. Allocating a portion of the return for maintenance extends their lives and empowers their constituencies.