Code Blue is a web content management system.

Introduction

The raison d'etre of a web site falls into one of two categories: 1) information sharing, and 2) service provision, most often ending up as some mixture of the two. Code Blue addresses the first category, and employs XAMPP and Ruby on Rails to address the second category.

The primary objective of Code Blue is to condense the production of content oriented web sites to the least possible quantity of labour:

• site map definition (optional)
• content definition
• content population
• content placement, i.e. template design (optional)

Here, web site creation is reduced to tasks that are inescapable; no further reduction is possible at any level of the production process, a fact independent of the platform being used, hence this is the quickest production route achievable. (Note: although the first and fourth steps are optional in Code Blue, they have been undertaken in all of my projects.)

The secondary objectives driving the development of Code Blue are to remove the struggles associated with development and re-design of custom templates, and to minimize the complexities involved in the hosting and administration of multiple web sites.

Content URL Mapping

This is the heart of Code Blue.

After years of web development, I found that all of my personal web site projects were content oriented, meaning they focused on content rather than applications. Accordingly, because my web sites were geared towards the collection, organization, and display of information, I set out to consolidate all modes of content display I required, and the result was content URL mapping.

The reason that content placement (i.e. template design) and site map definition are optional in Code Blue is content URL mapping. Content URL mapping gets its name from its design: using information from a URL request to display a content item or a list of content items -- that is, mapping content to URLs, and vice versa. If no custom URL paths are defined for a content type, then Code Blue makes content available via an expedient and automatic set of URLs. For this reason, a description of Code Blue's approach to content management might be to say that Code Blue approaches web content as Rails approaches web applications (though Code Blue is of course nowhere near as comprehensive in its domain). While Rails provides a quick and elegant method for creating web applications, Code Blue provides the same for creating web content; where Rails URL routing facility maps URL requests to controllers, methods, and values, Code Blue's content URL mapping facility maps URL requests to content types, fields, and values.

For example: Rails routes the URL /blog/view/Nori to the method view() inside of the controller BlogController, passing it the parameter 'Nori'; Code Blue maps the URL /blog/title/Nori to the ContentItem model via the ContentController, instructing that controller to initiate a search of the database table containing content items of type 'blog' and to display the database row where title = 'Nori', or display a list of all titles containing the search term if there are multiple results.

There are two types of content URL mapping: field and date. Field mapping handles URLs in one of the following formats:

• /<content type name>
• /<content type name>/<database field>
• /<content type name>/<database field>/<value>
• /<content type name>/<database field>/<value>/<id>

For example:

• /blog
• /music/producer
• /beats/title/lets-go-walk
• /blog/title/democracy/296

The final example includes the number 296 in order to specify the id of the database row to be shown. This URL scheme is used to display a particular database row in the case that the URL for the value ('democracy' in this case; /blog/title/democracy) returns multiple results, or if the database value contains special characters that can not be used in a (friendly) URL. Appending the id to the end of the URL is the preferred solution for reasons of SEO and interface design, because: 1) the name of the field being viewed is retained and thus remains available to search engines and users who are visually scanning the page, allowing both to determine the full context of the information being viewed, 2) keywords in the URL remain in logical priority sequence, and 3) the URL format remains consistent across all content-URL mappings, as opposed to embedding the id somewhere within the URL.

Date mapping is a special case of field mapping, handling URLs in one of the following formats:

• /<content type name>/date
• /<content type name>/date/<YYYY>
• /<content type name>/date/<YYYY>/<MM>
• /<content type name>/date/<YYYY>/<MM>/<DD>
• /<content type name>/date/<YYYY>/<MM>/<DD>/<content item title>

For example:

• /episode/date
• /episode/date/2005
• /blog/date/2005/1
• /blog/date/2008/1/1
• /blog/date/2008/2/2/the-capitalist-bent

In all mappings above, if the data specified in the URL maps to a single result then that result will be displayed directly, and if the data specified in the URL maps to multiple results then an index page will be displayed, linking to all results.

In addition to field and date mapping there are two aliases for commonly accessed items: newest and oldest, whose URLs are structured as follows:

• /<content type name>/newest
• /<content type name>/oldest

For example:

• /blog/newest
• /episode/oldest

A good example of content URL mapping at work is the 'music' content type found on the Something About Midnight web site. Something About Midnight is an internet radio show that I used to host with a high school friend of mine. The web site contains an archive of episode playlists, and if you visit the music index page, you'll see a list of the publicly accessible fields in the database table that contains music content items. System fields such as 'created_on', 'updated_on', and 'precedence' are not publicly accessible via the front end, and custom fields may be hidden or prohibited from display as needed. Here you see a number of publicly accessible fields that correspond to data typically associated with a song, including artist, credits, label, producer, and year. If you click on any of these fields, for example producer, you'll be presented with a list of all values for that field as found in the database. If you then click on any of the values for producer, for example Masters At Work, you'll be presented with a list of all music content items where producer = 'Masters At Work', displayed by title.

Using content URL mapping, the process for making new content available via the web is as short as possible: 1) create a database table, 2) populate data in the table. Now the new content is accessible online using any of the content URL mappings described above.

Simple ideas are often the best, and as far as ideas for the structured congruence of content with SEO friendly URLs go, content URL mapping is about as direct of an idea as it gets. The ContentItem model is the interface to all content; there is no need to develop and maintain an individual BlogController, Mp3Controller, ImageController, ProductController, and BookController -- they're all in the ContentController.

I suppose if I needed a confusing marketing catch phrase I could say that Code Blue is a 'web content delivery framework', because it's a platform for building platforms (web sites) that deliver content. Luckily, I don't need a confusing marketing catch phrase.

Template References

Content, project, and application data is made accessible in the front end via template references, as defined by Code Blue's template DSL. The template DSL provides all commands necessary for content access, content placement, and text transformation, and can be extended in a project specific manner through the use of template callbacks. Template references are converted into data values by the TemplateParse controller, and are not processed using Rails' render() family of functions. As a result, templates do not contain conditionals or iterators, and complete separation of processing logic from presentation is achieved.

The format of a template reference is as follows:

• {<type>:<data field 1>:<data field 2>: ... :<data field n>}

The <type> segment indicates the class of information that will be parsed into a reference. Available reference types are as follows:

• c - CONSTANT
• i - CONTENT_ITEM
• g - CONTENT_GROUP
• d - DATA
• f - DATABASE_FIELD
• l - LINK
• m - METHOD
• p - PAGE_DATA
• t - TEMPLATE
• v - VARIABLE

The number of data fields used varies on a per <type> basis. For a full description of the data fields employed by a particular reference type, refer to its parsing method.

For example, the following template reference refers to the content item of type 1 with database row id 64:

• {i:1:64}

Alternatively, the same template reference may be written using tags, which are mnemonic strings associated on a one-to-one basis with content items, project pages, and templates:

• {i:blog:dogma}

One of the primary benefits of using template references is to create self-managing hyperlinks to project pages and content items. Self-managing hyperlinks are links generated using template references, as opposed to creating links by hard-coding them as HTML. For example, rather than linking to the blog item with the title "Dogma" using the HTML <a href='/blog/title/dogma'>Dogma</a>, the blog can be referenced using the template reference {l:content:view:1 64}, or using a template reference with tags, {l:content:view:blog dogma}. The benefit of using a template reference is that if the content type (for example, blog) or any of its fields (for example, title) have their names changed, then the template reference will automatically recognize those updates and continue to generate the proper hyperlink target, without requiring any changes to the HTML source. Because URL page paths, content type names, content field names, and content field values are not always static, the use of template references greatly simplifies the task of web site management; when URLs or content names are changed you won't need to scour your database, content objects, templates, and web site for hyperlinks that require updating. (Note that if tags are used then HTML sources may require updating -- which is why I myself use them sparingly.)

Below is an example of Code Blue HTML using template references. This is an excerpt from the default template for the Beats content type on Risto.NET (as of 29 December 2010), and contains template references for three content fields: id, content, and file_size -- {f:id}, {f:content}, and {f:file_size} -- where id and content are database fields, and file_size is a content callback that determines and caches the size of this database row's correspondent file at run time. As well, this example contains a number of self-managing content hyperlinks, including: a link to this content item by its title; a permalink to this content item by its title; a link to the previous and next content items, sorted by title; a link to this content item by its date; and a link to download this content item. The HTML for the download link is encased in boundary tags that act on the value of the content item's available_for_download field; if the available_for_download information for this content item yields a positive result, then the HTML encased in the available_for_download boundary tags (<f:available_for_download> ... </f:available_for_download>) will be rendered.

  <div class='title'>
    {l:content:view:beats {f:id}}
  </div>

  <div class='navigation'>
    {l:content:permalink:beats {f:id}:Permalink}
    |
    {l:content:previous:beats {f:id}:Previous}
    |
    {l:content:next:beats {f:id}:Next}
  </div>

  <div class='date'>
    {l:content:view by date:beats {f:id}}
  </div>

  <div>
    {f:content}
  </div>

  <f:available_for_download>
  <div class='download'>
    &rarr; {l:content:download:beats {f:id}:MP3 Download}
    <f:file_size><span>({f:file_size})</span></f:file_size>
  </div>
  </f:available_for_download>

          

Looking at the first reference in this template, {l:content:view:beats {f:id}}, and using the Risto.NET beats content item "I Knew You" as an example, what happens at runtime is that Code Blue will first parse all references embedded within other references, which in this case results in replacing the template reference {f:id} with the database row id for the content item being accessed, 36, yielding: {l:content:view:beats 36}. This template reference will then be parsed to generate a hyperlink to view the content item in the beats database table having the row id 36 (and will use the data specified in that content item's title field as the HTML title for the hyperlink, because no custom title was specified in this reference), yielding: <a href="/beats/title/I-Knew-You">I Knew You</a>. Below is the fully parsed version of the above template, using the aforementioned content item ("I Knew You"):

  <div class='title'>
    <a href="/beats/title/I-Knew-You">I Knew You</a>
  </div>

  <div class='navigation'>
    <a href="/beats/title/I-Knew-You/36">Permalink</a>
    |
    <a href="/beats/title/I-Heard-That">Previous</a>
    |
    <a href="/beats/title/Its-Gonna-Be-Alright">Next</a>
  </div>

  <div class='date'>
    <a href="/beats/date/2003/9/17">September 17, 2003</a>
  </div>

  <div>
    <p>
      Deep/Speed Garage/Instrumental with 
      a distinctly Risto feel to it.
    </p>
    <p>
      I'm pleased with the way the bassline
      worked out; for the first time ever I 
      was able to orchestrate a sample and 
      melody to sound exactly the same as it 
      did in my head.
    </p>
  </div>
  
  <div class='download'>
    &rarr; <a href="/download/beats/36">MP3 Download</a>
    <span>(2 MB)</span>
  </div>


          

In closing this section, rather than duplicating explanations here, I'll link to the RDoc documentation for the Template methods with the most informative comments:

• parse()
• parse_content_items()
• parse_links()
• reference_assemble_boundary_tag()

Functional Overview

Code Blue tries to stay away from the structural constraints of a monolithic environment. Relative to the popular software packages that one normally associates with the term CMS, the feature set of Code Blue is, and will remain, modest. The goals and features listed on this page will in all likelihood forever comprise the full functional scope.

The fundamental approach to web site development taken by Code Blue is enablement, not imposition: equip the user with a solid foundation, supply intelligent defaults, and allow the user to do what is best in every situation by permitting external functional extension.

Note that Code Blue is not a typical Ruby on Rails application. While Code Blue is built atop Ruby and Rails, it does not adhere strictly to Rails' MVC pattern, but develops its own architecture atop Rails (as is readily apparent per the descriptions of Content URL Mapping and Template References, given above).

Projects

• Multi-site hosting

• Agnate host name resolution

Content

• Scheduling

• Re-usability

• Rapid Data Typing
  • Unified data typing: all content is interfaced using the same API; no need to develop and maintain multiple data models or integration points
  • High performance data model: each content type is stored in its own table and may thus be indexed on the most relevant fields
  • Transparent data model; simple data import/export; simple wholesale migration to/from Code Blue (note that migration to a new CMS or web site platform from Code Blue will require changes to content type templates and possibly other templates, but this is inescapable when migrating from any CMS to a different system)

• SEO Friendly URLs
  • Content is automatically available via Content URL Mapping; standard and obvious conventions are used: content is browseable by all fields; no development effort required
  • The complete process for making content web accessible is as follows:
    • Content definition
    • Content population
    • (Optional: template creation)

Templates

• Re-usability

• Page and Content Caching

• Rapid Templating
  • All content is accessible using a single, simple, powerful DSL; no need to develop and maintain multiple command sets or utilities on a per content type basis

• MVC Separation
  • Complete separation of processing logic from presentation: the template DSL consists only of commands for content placement and text transformation
  • Templates contain design information only, and remain highly readable; code remains modular, and highly readable
  • Template modification can not influence the functional operation of the system

Data Integrity

• The front end is contained in one database and vendor applications are contained in another; the live database containing content and template data is configured as read only, thus bugs in the platform will not result in alterations to the front end or its data

Development

• Uniform platform environment across all tiers (test, production, et al.), thus eliminating problems of consistency
• Idempotent data promotion processes
• Seamless integration with third party applications and modules; PHP and Perl integration via XAMPP; custom application integration via Rails
• Written entirely in Rails -- models, controllers, libraries, command line utilities -- in order to increase portability, reusability, and maintainability

Documentation

Documentation is available in RDoc format.

For those taking the time to review the RDoc documentation, I'll make a housekeeping note: I've refactored Code Blue 20 times, at least. This project is my first foray into Rails, and as far as personal projects go, it's a sizeable foray -- the entire platform is around 8,200 lines, including command line utilities and comments. I've refactored the entire system as my understanding of Rails has grown and the problem domain has become more evident. Since I first began work on Code Blue I've had a ticket open devoted solely to the management of refactoring, and as of February 2008 it contained 29 to do's. As a result of this endless refactoring there may be some discrepancies in the RDoc snapshot, but I've reviewed it a few times and the descriptions appear to reflect the functionality.

Also, RDoc is great (amazing actually), but version 1.8 still munges some things here, and duplicates some things there, so not all of the RDoc output accurately reflects the code or comments.

Because

Code Blue is the intersection of three goals: 1) engineer a web content management system that fits the nature of my web sites and my workflow, 2) learn Ruby on Rails, and 3) develop a tool I can apply to charitable services.

Content Management

I'm interested in many things, one of which is software architecture, and in particular, software engineering for the web. Accordingly, when I first began web programming, a natural outlet for the expression of my other interests was in the form of web sites, and through this I discovered the appeal of content management. As the years passed by, my multiple interests spawned multiple web sites, each bringing the opportunity to learn and explore new technologies. An enlightening experience, to be sure. But the flip side of the enjoyment that came with research and development of independent technologies was an increase in maintenance overhead, and I found myself managing several quasi-independent platforms. As life advanced inexorably towards infinity, I found less time to spare for maintenance, and I long ago lost interest in the administration of multiple systems based on already familiar technologies.

It was first in 2000 that I conceived of creating a multi-site web CMS, but the checks and balances of life saw to it that such a dream was not meant to be realized in short order. As the second half of 2005 approached I found myself continuing to work piecemeal on my three primary sites -- Risto.NET, Something About Midnight, and MOFOs Dragon Boat -- as well as a host of smaller projects, duplicating a feature here and replicating a bug fix there. Not a propitious use of time. Each web site was built atop a core system that I had been expanding upon since 2000 (a semi-organized collection of utilities that I had developed, combined with third party applications that I had aggregated, based in PHP / Perl / Bash / MySQL / Apache -- this project was later dubbed "Code Blue 2000"), but each web site also possessed a significant amount of custom code, often with custom hooks into the shared core. The familiar and inevitable results of insufficient time; precisely what I had been hoping to avoid.

I froze development on Code Blue 2000 and began to pursue the new Code Blue: a multi-site web CMS, geared towards developers -- a single system delivering a fundamental set of features across all web sites. The only difference between a development environment and a production environment would be the host name (... and maybe some test data); content would be controlled by one generic data model and made automagically available via SEO friendly URLs; the core would remain lean by allowing for project specific functional extension via content callbacks and template callbacks; template development and content placement would be simplified using a concise template DSL; and all of this would combine to minimize development, maintenance, and time to market, as well as standardizing hosting and administration (and everything else listed in the What section of this page). Convention, not configuration.

I began to work on Code Blue during every spare moment I had outside of work. It was incredibly slow going. The upper boundary of my day job as an engineer was rarely eight hours, and combined with the travel time to work I was left with little spare time or mental energy to devote to even more engineering. But I was driven by ideas, and found myself ruminating on data models in the shower, making notes on the train, and creating prototypes late into the night. For the first time in my life I drank coffee. (Oooh, I know, big deal. Not in obscene amounts, yet still a significant change for me, since I had avoided it for three decades. But I digress.) I examined each of my web site projects and compiled an exhaustive list of features, then isolated the commonalities and differences, and prioritized all line items. The resulting lists were huge. Features in the common list would be built into the core of Code Blue, while features in the differences list would be built as generic plugins or project specific callbacks. Each list was translated into its own project in my ticket system, Mantis, and each ticket was assigned to a project version. The result was six projects; the CMS itself: Code Blue, and five web sites that I would develop using Code Blue: Compsci.ORG, Juola.NET, Risto.NET, MOFOs Dragon Boat, and Something About Midnight.

Finally, the time had arrived: coding hour.

If you're interested in learning more about the progression of Code Blue from this point, there are more details in the When section of this page.

Learning

I might have dispensed with this earlier, but I felt the point best suited to this section; in answer to the question "why not use an existing CMS?" there are two responses: 1) I researched and tested some of the more popular packages and the result was analysis paralysis, and 2) I was eager to create my own CMS in order to experiment with Ruby and Rails and create something to fit my needs.

I take great pleasure in thinking (which is not to make any claims about the products of my thoughts), and my excitement is stirred by learning. Intellectual expansion and introspective consciousness are two of the most astonishing gifts we are adorned with. I enjoy reading most anything I can get my hands on, in the hope that I can accumulate some small amount of knowledge to help fill the yawning chasm that is my brain. Outside of technology, I enjoy reading philosophy, history, politics, psychology, science, and religion. The depth of human experience available is awesome in every sense of the word. To this end, Code Blue has provided me with increased opportunities for learning, in more than one way.

Firstly, and most obviously, I've been able to exercise my abilities. Since 1996, I've worked with many technologies, operating systems, hardware platforms, programming languages, and design approaches, and I've genuinely enjoyed being involved in all aspects of every project: research, administration, implementation, QA, interface design, and project management. Involvement in these roles has been rewarding, and Code Blue has afforded me the chance to apply and improve upon the lessons I've learned. And of course, even though I've worked on many (many) similar projects, it's always satisfying to implement a project based on my own specifications.

Secondly, I now have more time to learn. I've come to accept that I bear a need to collect and organize the data that is my life, and now that I use Code Blue to develop and maintain my sites, I spend less time administering and more time learning. The effort required has been reduced to the smallest possible target: adding new content. Having developed and standardized the essential processes and structures, the only task left is to use them.

Technology should be a boon to personal development, not a burden. Code Blue 2000 long ago reached the point of burden. The new incarnation of Code Blue incorporates the lessons I've learned, and provides me with a system of organization that fits my needs. The more I learn the more I wish to learn, and consequently, the greater the amount of content I produce. Code Blue furnishes me with a rich environment for the collection of my thoughts, and the cultivation of my creativity.

Regarding the selection of Ruby on Rails: a number of languages (Python, Perl, C++, Java, PHP) and web application frameworks (Catalyst, Mason, Nitro, Django, Plone, Zope, Drupal, Typo3, WT, CakePHP, PRADO, Code Igniter, Symfony, ZF, and many others) were reviewed and/or tested, and Rails was found to stand head and shoulders above the rest. Further discussion of this choice can be found on Risto.NET.

Charity

During high school, the notion of charity outside of helping friends was not on my radar. During high school and university, I contemplated donations of time and zakat, but I was still trying to figure out what the hell was going on in the specific study of computer science and in the general arena of life. In every professional position I've held after university I've had the intention of performing charitable service, but I've repeatedly come up against the same two obstacles: 1) I needed to spend after hours recovering from work hours, and 2) predatory capitalist technocrats are not amenable to anything they perceive as a threat to profit. Here I'm speaking in particular about things that people unquestioningly and thus uncritically view as a threat.

In three separate jobs I've presented the idea of incorporating charitable service into the work week with no expense to the employer in the hope of engendering a charitable mindset into the office culture, for example by shifting my lunch hour to act as a recess monitor or crossing guard at a nearby public school (here I should note that in all cases my first obligation has been to honour the contract between myself and my employer, and in this particular case shifting my lunch hour presented no conflict, as I was in an engineering role and the time of day at which I programmed had no bearing on my output, and meetings and on-call were also not a concern). In all cases however my employer stood rigid and refused to discuss my ideas. Not acceptable.

The reality is that we in the West live under the direct rule of capitalist democracy (while those elsewhere live under its indirect rule), and we must respect the influence of this structure on our lives. Often we must work as an apparatchik in an unsatisfying job in order to live. However, it is also incumbent upon us to determine at what point we can say that our wealth exceeds the limit of our material needs, and thus determine the point at which we can begin to look out for someone else's needs -- towards the end of empowerment, not mere entertainment or increase of wealth for the already over-privileged. It's tough to be objective about this in an autocratic materialistic society, and to break the cycle of perform-mind-numbing-task-buy-ostentatious-amusement.

This problem must not be understated, and the issue at hand is not merely whether or not one has amassed enough capital to venture beyond the confines of day labour while continuing to operate as a capitalist.

"How happened it ... that your workers were able to produce more than so many savages would have done? Was it not wholly on account of the heritage of the past knowledge and achievements of the race, the machinery of society, thousands of years in contriving, found by you ready- made to your hand? How did you come to be possessors of this knowledge and this machinery, which represent nine parts to one contributed by yourself in the value of your product? You inherited it, did you not? And were not these others, these unfortunate and crippled brothers whom you cast out, joint inheritors, co-heirs with you? What did you do with their share? Did you not rob them when you put them off with crusts, who were entitled to sit with the heirs, and did you not add insult to robbery when you called the crusts charity?"

(Edward Bellamy, Looking Backward, Chapter 12, 1888)

The significance of charity then does not lie in its application, but in the recognition that the need for charity furnishes us with evidence of the human crisis born of elitist political systems and policies. While charitable services are for the moment indispensable, we must understand that they are, and have always been, just a step in the march towards balance, and never a proper goal or solution.

"There are a thousand hacking at the branches of evil to one who is striking at the root, and it may be that he who bestows the largest amount of time and money on the needy is doing the most by his mode of life to produce that misery which he strives in vain to relieve."

(Henry David Thoreau, Walden, Chapter 1, 1854)

Keeping this observation in mind, and observing also that human rights in the context of modern day state-capitalist democracies work by bending social groups toward government policy, we thus observe that offering and proferring charity presupposes that the primary problem is how best to integrate social groups into perfectible administrative systems. This does not permit deep solutions, as by the lights of capitalistic property rights, groups continue to be isolated by resource competition; there always remain groups outside of support structures, and as a result there can be no economic or ethical transformation for those inside or outside the system. Hence, though the altruistic

"very seriously and very sentimentally set themselves to the task of remedying the evils that they see ... their remedies do not cure the disease: they merely prolong it. Indeed, their remedies are part of the disease. They try to solve the problem of poverty, for instance, by keeping the poor alive; or, in the case of a very advanced school, by amusing the poor. But this is not a solution: it is an aggravation of the difficulty. The proper aim is to try and reconstruct society on such a basis that poverty will be impossible."

(Oscar Wilde, The Soul Of Man Under Socialism, 1891)

The question of charity therefore is not how best to administer alms in perpetuity, but rather how to remove the very need for it. (This is not to suggest the eradication of social services, which are not charity in the sense discussed above.) In this way, the extension of democratic liberties means the extension of freedom through systems of mutual aid, rather than the aggrandization of unsustainable structures of economic detente that are intended to pacify competing social groups.

I'll stop this part of the discussion here, before it strays too far beyond the scope of this document. For further information I'll refer the reader to my blog, and to the compendious Anarchist FAQ.

Returning to my motivations in the pursuit of Code Blue: I've never experienced poverty, but I must admit that the experience of my father, who once lived in a plywood shack during winter in Finland, has thus far motivated me to steadily apply myself in wage earning pursuits with the goal of ensuring an enduring quality of life for myself and those around me. However, in my estimations, I've reached a point at which I can afford to set aside wage earning for a little while without endangering the welfare of my family.

A large part of my motivation in the production of Code Blue is the idea that I can use it to contribute to the spread of humanistic intentionality. I've now found a part of the answer to my long standing question, how can I help? Code Blue. Most, if not all, organizations need a web site. There is no technology better than a well designed web site for information collection, management, and dissemination. In the minimal discussions I've had regarding charity and NPO web site projects, it seems that much of the pro bono help available is from students, who are often unable to help beyond a certain experience level, or may even have a negative impact, with inexperience resulting in poor decisions and wasted resources. How better for me to help than to apply over a decade's worth of web experience? I can provide professional engineering and project management services, explain what is possible and what is not, guide efforts in useful directions, and steer organizations clear of profitless labour. All the while doing something I enjoy on multiple levels. The benefit is mutual.

My rough plan is this: 1) complete enough of Code Blue to implement web sites [done, as of 2008 01 14], 2) migrate my web sites to Code Blue and test the platform, fixing bugs and adding features as appropriate [2008 01 15 - 2008 09 04], 3) once Code Blue possesses a reasonable and stable feature set, approach organizations and engage them in conversation to discover their needs, describe my services and their limits, and determine if Code Blue and I are a match for them. It might be a good idea to expand on point 3, and so I'll include the following addendum: I will not be approaching organizations and offering to perform any and every technical service they need, as it is best for everyone involved that the scope of each project remains realistic -- but with that being said, I will always be open to the possibility of extra work beyond the implementation of a content oriented Code Blue based web site.

The future is Blue.

Code Blue is built on top of the following technologies:

GNU/Linux

"Unix-like operating systems are built from a collection of libraries, applications and developer tools -- plus a program to allocate resources and talk to the hardware, known as a kernel ... The combination of GNU and [the] Linux [kernel] is the GNU/Linux operating system, now used by millions" (http://www.gnu.org)

XAMPP

"Many people know from their own experience that it's not easy to install an Apache web server and it gets harder if you want to add MySQL, PHP and Perl. XAMPP is an easy to install Apache distribution containing MySQL, PHP and Perl. XAMPP is really very easy to install and to use -- just download, extract and start."

Mongrel

"Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI."

Ruby on Rails

"Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server."

Release Schedule

v0.6 Alpha : 1^st Quarter 2008

v0.5 Alpha : 2^nd Quarter 2007

v0.4 Alpha : 1^st Quarter 2007

v0.3 Alpha : 3^rd Quarter 2006

v0.2 Alpha : 1^st Quarter 2006

v0.1 Alpha : 3^rd Quarter 2005

The Past

Code Blue's development history provides a high level outline of the application environment and functionality, with a timeline.

The Future

Code Blue's ticket based roadmap gives an idea of the project's trajectory, with no timeline.

A note on the roadmap: I use Mantis to manage my software projects. Permit me here to address all well meaning Tracophiles: Trac is great, but Mantis fits my needs - although when I first began using Mantis in 2003 there was no roadmap utility available (there still may not be), and so I hacked something together to allow me to organize my tickets by category and version. The roadmap linked to above is the output of my Mantis roadmap utility, excluding tickets that are closed or unassigned. The roadmap snapshot above is from January 29th 2008, at which time there were 87 active tickets. Viewing the roadmap will give an idea of the manner in which tickets are created, and hopefully give some meaning to this number.

Web sites running on Code Blue:

Colborne Street Community

A web site for residents of Colborne Street in London, Ontario. This site was designed in order to disseminate information that is relevant to householders living on and around Colborne Street, and to promote communication between residents and the city.

URL: colborne.risto.net

Compsci.ORG

My software projects.

URL: compsci.org

DNA2 - Penthouse Suite 912

Real estate web site, for the sale of my condominium.

URL: dna.risto.net

MOFOs Dragon Boat

Home page of the MOFOs dragon boat team.

Natalie & Risto

Our wedding.

URL: natalie.and.risto.net

Risto.NET

My home page. An outlet for the organization of my thoughts and experiences: my blog, my beats, my gallery.

URL: risto.net

Something About Midnight

Something About Midnight internet radio, hosted by DJ Risto and DJ Pete. Something About Midnight focuses on the sound of the underground - Garage House music.

URL: garagehouse.com

Code Blue is developed and maintained by Risto Juola.