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.

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.

OrientDB is nearing version 1.0, and it has a native HTTP/JSON interface – it supports classes, inheritance and all kinds of relationships, all the things we try to simulate with object-relational mappers when building a domain-model, which makes me wonder… why use an ORM at all?

If you’re going to do all your data-binding on the client-side, and if a graph database can natively represent your domain-model without a line of code, why struggle to achieve the same thing with server-side code and object-relational mapping?

You’d only need controllers/actions for actual business-operations. You could probably implement a thin “proxy” for operations like updates and deletes, access control and user identity, etc… You would never need to render a template, generate tables or forms or parse a form-post or implement tedious CRUD operations on the server-side.

It all sounds dreamy, and I can see this working out great for applications.

But what about SEO? The internet lives and breathes HTML. So it seems it’s not an approach that will work for public-facing pages.

Any thoughts?

There are legitimate reasons to leave them in test/staging code, if you’re still working out some details.

So I wrote this little library as a replacement.

It doesn’t blow up when the console is not available, adds chainable log() and warn() methods to jQuery selectors, and improves a bit on the display in FF and IE9.

Tested and working nicely in FF, IE9 and Chrome.

I realize this isn’t a groundbreaking idea – but I looked at a couple of existing libraries that do something similar, and nothing really seemed to work well in IE.

Also, this kind of thing should be small – this script compresses to less than 0.5 KB.

Most people simply do something along the lines of this:

$('body').append('<h1>Hello, World</h1>');

jQuery injects the HTML string into the DOM, and all is well.

But sometimes you need to inject more structured content, or even entire forms – what I typically do is something along the lines of this:

jQuery('body').append(
  $('<div/>').append(
    $('<div/>').text('Hi there'),
    $('<p/>').text('How do you do?')
  )
);

With all the parentheses, angle brackets and repetitive calls to append(), this doesn’t exactly look nice.

Recognizing the repetitive construction of elements, followed by calls to append, what if we had a set of tiny functions that would do both in one simple operation? I decided to give it a shot, and here’s what it looks like:

jQuery('body').append(
  $div(
    $h2('Do you love it?'),
    $form(
      $div('Sign here:', $text()),
      $div($label($checkbox('yes'), 'I love it!')),
      $ul(
        $li($radio('1'), 'Option One'),
        $li($radio('2'), 'Option Two'),
        $li($radio('3'), 'Option Three')
      ),
      $submit('I submit!')
    )
  )
);

The functions prefixed with the $-sign create the elements, and pass down any arguments to the append() method.

The input element methods, such as $radio and $submit are a bit different – they create input elements, set the type-attribute, and if you pass them an argument, they apply that as the value-attribute on the element. (input elements can’t have child-elements, so this doesn’t get in the way of anything.)

You can see a working example and source code here.

Because JavaScript is a highly dynamic language, I didn’t need to write each of these $-functions by hand – with just 13 lines of JavaScript, applying a simple meta-programming technique, all of the functions are automatically generated.

Finally, it’s worth noting that something like $('<div/>') actually results in a string of HTML being parsed and then inserted into the browser. My handy little DOM-helpers avoid the parser – they access the DOM and create HTML elements directly, which means they execute around 10 times faster compared to the first example.

Update

One of my GORGES colleagues pointed out the fact that I had no convenient way to apply attributes to the created elements – if you don’t like the repetitive calls to attr(), try this updated version, which provides a simplified way to apply attributes quickly. This takes a bit more code, but I suspect he’s now porting this to CoffeeScript

The major contenders when it comes to mobile operating systems are Android, iOS (more commonly known as iPhone, iPad and iPod), and Windows Phone 7 – all fantastic mobile operating systems, it is hard to even begin to compare them to their predecessors.

But why were we suddenly (these past few years) imbued with these brilliant new OS’es?

The answer of course is advances in hardware – lower cost, more computation power, high resolution displays and multi-touch, more storage, faster wireless networks, longer battery life… and on top of all that, advances in nanotechnology has made everything smaller and lighter, too.

My point with this little article, is to share with you an observation that has surfaced in a few of my conversations lately: that these new mobile operating systems are part of a transition towards “real” operating systems running on mobile devices. In fact, I’ve taken to referring to them as “transition operating systems” myself.

The evolution of mobile hardware does not cease. What made these new OS’es possible, is the fact that mobile devices are now almost as fast as “real” computers – and that same progress will put an end to them, too.

Soon, mobile devices will be fast enough to run “real” operating systems – and when that time comes, why would you want a dedicated mobile OS, or even a mobile device dedicated to wireless communications, such as your phone? If you could run a real Windows, OSX or Linux OS on your device, why wouldn’t you? At least two of the major players in mobile hardware, NVidia and QualComm, are currently racing to bring quad-core processors to market this year, so it may be more imminent than you think.

I suspect certain companies, such as Apple, are already having the same realization – it was recently rumored that certain features are being migrated from iOS to OSX. My guess is, they’re getting ready to add support for iOS apps to OSX, with the intent of running OSX on a mobile device in the no-too-distant future.

This is all speculation, of course – and either way, it doesn’t diminish the value of the mobile “transition” operating systems, which paved the way for new advances in user interface / user experience development, and have set new standards for human-machine interfaces overall.

And it certainly doesn’t mean that you should hold out on your business ideas – waiting for real operating systems to hit your cell phones – the new mobile platforms are already embedded in our lives, and they are inevitably here to stay, in some form or another.

Much to my excitement, I recently discovered that this feature is now available in phpMyAdmin, and pretty much to my exact specifications!

The feature is change tracking – essentially a simple automatic schema version control system.

You can think of this idea as auto-generated, forward-only migrations. In other words, it doesn’t enable you to easily revert to a previous schema version, except by re-initializing the schema to a previous version, destroying existing data – but it also doesn’t involve writing migrations by hand.

You just open your schema, turn on tracking, and then proceed to work with phpMyAdmin the way you normally would – making changes to the schema (and/or data) using the GUI interface; your choice of SQL statements are tracked and recorded, and at the end, a snapshot of the complete schema is taken, enabling you to upgrade from one schema version to another, or initialize the schema to a specific version.

If you’re not already using database migrations, this could be a big timesaver, and should lighten the work of keeping your local/test/production databases in sync – as well as maintaining a history of what was changed and when. Nice!

Thanks, phpMyAdmin Team!

Frameworks generally belong to one of two camps, “pure frameworks” and “full stack frameworks”.

Most frameworks don’t make a distinction between “framework” and “application” features, and as a result they become cluttered. They also become more daunting to newcomers, with their sheer volume of classes that attempt to solve every practical problem a web developer might ever encounter – user management, document and image handling, upload and downloading, etc.

My favorite PHP framework, Yii, is a pure framework – free from the burden that many frameworks drag around, namely a full “application stack”. Yii consists almost exclusively of components and features designed to support certain practices or paradigms.

One of my favorite things about Yii, as compared to “full stack” frameworks, such as Zend, is that Yii only comes with components and architecture that can be rightfully said to belong in the “framework” domain, and not the “application” domain.

Of course, it may be hard in some cases to draw an exact line between the two, and I think the first criteria for selecting features that belong in the framework, and not in an application stack, should be:

• Is it absolutely general-purpose?
• If not, is it fully extensible?

Certain features, like the URL manager or Active Record, are not absolutely general purpose, in the sense that they may not satisfy every possible need anyone could ever have. But they are sufficiently general purpose in the sense that almost everybody is going to need at least the core functionality of those components. And because they are fully extensible, developers can build on top of them, rather than having to replace them, if they find that a component does not fully cater to their specific needs.

The reason why I do not want application features in a framework, is because I know from experience that these will not meet my strict requirements. I will eventually end up replacing many of these features and the existing features provided by the framework are reduced to baggage.

Everybody is different – we all have different goals, and even if we share some goals, we usually have different means for reaching those goals.

I believe the reason why we web developers converge around a framework, is because we agree on certain practices. The framework is designed to leverage those practices in a convenient and streamlined way.

The subtle art of the framework is to achieve accepted practice, without getting in the way of individuality – to enable us to adhere to the good practices that we agree upon, while still allowing us to be as different, as versatile and as colorful as we can!

In short, frameworks enable us to focus our efforts on “business logic”, the functionality that has real value to the website users. Thanks to the framework, we can focus on the practical requirements, without sacrificing the values that professional software developers care about: clean, maintainable and extensible code.

With a good framework, we can deliver value and high code quality, without charging extra for quality!

Part of creating “smart” web applications is understanding the semantics of what people type in, which implies using natural language processing.  Natural language processing software examines unstructured documents, and generates structured metadata that computers can handle.

Our application needed to understand phrases that people enter into a web browser.  We found three different approaches to handling this unstructured text:

SaaS APIs

These are hosted applications. All offer limited services at no charge, commercial services are generally pretty expensive. The major players appear to be:

Zemanta: offers an API with automatic tagging, among many other features.

OpenCalais: while it is by no means “open”, this API is powered by Reuters – which means that their “corpus” (body of words understood by the system) was composed using one of the world’s largest and most accurate volumes of text.

Alchemy API: offers automated categorization, tagging, keywords, etc.

NLP Toolkits

These are open-source toolkits (APIs that you can install on your own server) for analysis of unstructured text. Learning how to apply one of these might take a considerable effort – someone would have to learn at least the basics of NLP, to apply this software, or you might choose to hire a consultant with the the skills to develop this part of the application.

NLTK.org: a library written in Python, started in 2005, has been slowly creeping towards release 1.0 for the past year or so. While relatively young, it may be based on newer research than some of the more mature NLP libraries. Many corpora, grammar collections and trained models ready to use.

GATE: General Architecture for Text Engineering. Stable and proven toolkit for Java – this project started in 1995. Countless subprojects leverage this toolkit for various purposes.

FreeLing: Widely used toolkit in C++, with APIs for Java, PERL and Python. Online demos of this library demonstrate graphically how a short sentence can be broken down to a kind of tree-structure (nested subject/object, verb/adverb, etc.)

These are just a few examples – there are so many toolkits, and applications using these toolkits, that it would be impossible to make a choice based on a superficial analysis. To make a qualified choice, we would need to study at least the basics, or we would need the help of someone who knows enough about it to make a recommendation based on our needs.

Roll-your-own

Using e.g. MySQL, the Porter stemmer, a stop-word list and various other techniques to roll a basic search engine. Perhaps throw in a Bayesian text similarity measurement, to help rank the results and create stronger/weaker links between tables of keywords and posts.

It’s not NLP, and it’s not “web 3.0″, or “the semantic web” that everyone is buzzing about these days – because it does not understand semantics, and this will not yield the same kind of results – NLP systems “understand” unstructured text, where words like “not” and “really” can reverse or amplify the meaning of a subject – whereas anything you can roll on your own would most likely just recognize and consider these words “stop words” (ignoring them).

One way that modern sites achieve this, is by loading in smaller increments – for example, loading the detailed content for an item on a list can be deferred using AJAX.

Another way to break down the loading of a web application into smaller chunks, is by loading various other resources, specifically JavaScript and CSS files, on demand.

Doing this in a compatible and clean way, can be tricky.

The Challenge

Let’s look at some of the requirements that a good solution to this problem must fulfill.

First of all, some of the JavaScript frameworks we work with, do provide some sort of resource management. But we work with many different frameworks, and sometimes with no framework at all, so our solution needs to be stand-alone as well as compatible with most major JavaScript frameworks.

Secondly, we target all modern browsers – and therefore, our solution must be fully cross browser , targeting Internet Explorer 6 through 8, Firefox, Opera and Chrome, and hopefully any other standards compliant future browsers.

JavaScript is (or can be) object-oriented, meaning that a class in one script could potentially extend a class in another script. Therefore, since we are going to load resource asynchronously, we must ensure that scripts are loaded and executed in order .

Another concern is notification of resource readiness. Since resources are loaded asynchronously, and sometimes have already been loaded once, our script needs to provide a callback-notification when the resource is ready and available.

And finally, we don’t want to write code for every project to keep track of what’s been loaded and what has not. In other words, we need a load-once method, so that classes, widgets and stylesheets can be automatically loaded the first time they are needed.

Limitations

We’re going to accept certain limitations of this script.

For one, we’re not going to attempt to do a lot of error handling – if a resource can’t be loaded, this is a problem that needs to be solved by the developer, and not really something you can provide a “pretty” solution for anyway.

And secondly, some resource management scripts attempt to inject scripts in a way that allows scripts from foreign domains to run without security limitations. This has certain other drawbacks that I won’t get into, but we’re going to assume that you’re loading scripts from your own domain.

Our Solution

Our script comes in the form of a classless singleton object, which provides two methods for loading resources on demand:

Loader.load( url, [callback-function], [context-object], [driver-name] );
Loader.once( url, [callback-function], [context-object], [driver-name] );

The Loader.load() method will allow you to load the same resource repeatedly – for example, you will be able to execute the same JavaScript more than once. Just keep in mind that duplicate class declarations, and duplicate initialization, for example, could cause problems. Most likely, you will only want to use this method if you want to intentionally overwrite existing variables.

The Loader.once() method will ensure that the same resource is only loaded once. Note that the callback will be called when the resource is ready , not only the first time when the resource actually loads.

Arguments for the two functions are identical:

• url : required – relative (to your page) or absolute URL to a JavaScript or CSS resource.
• callback-function : optional callback-function – called when the resource (and any resources requested before it) has loaded.
• context-object : optional object to use as the context (this) for the callback-function. Use null (or leave out) if calling context is unimportant.
• driver-name : optional driver-name, e.g. “css” or “js” – this determines how the loaded resource is handled. If unspecified, the loader will try to determine the driver by file-extension, but will default to “js” if the file extension at the end of the URL does not match “.css” or “.js”.

Conclusion

When you need to load a collection of resources, remember that they will be loaded in the order you request them. For example, loading components for a widget-based framework such as ExtJS is possible – you can load a component class declaration, and then load another class that extends it, but you must request them in order.

Another thing to keep in mind, when you need to know when a collection of resources are ready, you don’t need to attach a callback to every request – just attach your callback-function to the last request, as this won’t execute until all previously requested resources are ready.

Source Code

Finally, here is the source code for you to cut and paste:

/*

Version:   1.1
Developer: Rasmus Schultz
License:   GPL v3 <http://www.gnu.org/licenses/gpl-3.0-standalone.html>

Copyright 2009, Gorges Web Sites <http://www.GORGES.us>

Removing this notice from the source code would be bad karma.

*/

var Loader = {
q: [], // the Queue for pending items to be loaded
reg: {}, // a registry to ensure items are loaded only once
load: function(url, cb, context, driver, once) {
var dd = url.split('.').pop();
if (!Loader.drivers[dd]) dd = driver || 'js';
var p = new Loader.Proxy(
{ url: url, cb: cb || function(){}, reg: once, driver: dd, context: context }
);
Loader.q.push(p);
Loader.next();
return p;
},
once: function(url, cb, context, driver) {
this.load(url, cb, context, driver, 1);
},
next: function() {
for (i=0; i<Loader.q.length; i++) {
var l = Loader.q[i];
if (l.state == 1) return; // already loading
if (l.state == 0) return l.load(); // not loading (and not yet loaded)
}
}
}

Loader.Proxy = function(opt) {
this.driver = opt.driver;
this.context = opt.context || this;
this.url = opt.url;
this.reg = opt.reg;
this.state = 0; // inactive
this.cb = opt.cb;
this.load = function() {
if (this.reg &amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp; Loader.reg[this.url]) return this.loaded(); // already loaded once
this.state = 1; // loading
var hd = document.getElementsByTagName("head")[0];
var el = Loader.drivers[this.driver](this, this.url + (this.url.indexOf('?') == -1 ? '?' : '&amp;amp;amp;amp;amp;') + new Date().getTime());
hd.appendChild(el);
}
this.loaded = function() {
this.state = 2; // loaded
if (this.reg) Loader.reg[this.url] = 1;
this.cb.call(this.context);
Loader.next();
}
}

Loader.drivers = {

js: function(proxy, url) {
var el = document.createElement('script');
el.type = 'text/javascript';
el.src = url;
var me = proxy;
if (el.attachEvent) { // IE
el.attachEvent('onreadystatechange', function() {
if (el.readyState == 'loaded' || el.readyState == 'complete') me.loaded();
});
} else { // DOM
el.onload = function() { me.loaded(); }
}
return el;
},

css: function(proxy, url) {
var el = document.createElement('link');
el.rel = 'stylesheet';
el.type = 'text/css';
el.href = url;
el.media = 'all';
new (function(link, proxy){
this.index = document.styleSheets.length;
this.link = link;
this.proxy = proxy;
var me = this;
this.check = function() {
try {
var s = document.styleSheets[me.index];
if ((s.rules || s.cssRules).length) { // DOM || FF
window.clearInterval(me.int);
me.proxy.loaded();
}
} catch (e) {};
}
this.int = window.setInterval(this.check, 100);
})(el, proxy);
return el;
}

}