DO:

• DO buy online from a store like Hobby King. You will save hundreds on the exact same items as they sell in the hobby shops.
• DO read all the reviews and comments you can get your hands on before committing to a purchase. There’s a reason they’re cheaper, but it’s not all bad.
• DO double-, triple-, and quadruple-check the measurements for everything. For instance, make sure your battery, motor, ESC, Rx/Tx and propeller all measure up in size and power.
• DO watch instructional videos online. It will give you a much better idea of how to put everything together. A simple Google search of the product name will usually get you some video results.
• DO make sure you have all the tools and consumables you need. There’s nothing like getting your brand new plane and then finding out you need glue, wire, alligator clips, drill bits, batteries, tape, pliers, soldering iron etc. etc. etc.
• DO get the measurements of the plane and make sure it will fit in your car.
• DO buy a LiPo battery charger, and ensure that it comes with a power supply, or that you can easily provide your own.
• DO check your center of gravity. A lot of flying problems can be explained by a bad CG.
• DO ensure that everything works and nothing falls apart during operation before you go to all the effort of taking it out for a flight. It sucks to drive all the way out to the park only to find that the propeller won’t stay on.

DON’T:

• DON’T test the electric motor out by attaching it directly to the battery. This will only result in smoke.
• DON’T test your aircraft inside without holding onto it and keeping yourself and everything else clear of the propeller.
• DON’T take their word for it when they say that the instruction manual is “complete”, especially if you’ve never done anything like this before. Hours can be wasted when you find out you used the big screws instead of the little screws, and now you’re out of big screws and you have to take everything apart and start again. The latest manual I read seriously said something like Step 5: Complete construction of aircraft. That was like 3/4 of the work in one step!
• DON’T assume that super-tough EPO foam is all that tough. EPO foam is only “super-tough” if it’s cut correctly. When they practically sever the wing all the way through to cut flaps that you’re not even going to use, no amount of hyperbole is going to stop that bit of foam from detaching mid-flight. Glue is more practical.
• DON’T think that you’re going to get your plane to fly well the first time, or even the fifth time. Expect to spend more time putting things back together than you do flying.

One way that I’ve found to get it to build properly is to explicitly set the library directories before configuring it:

CFLAGS=-l/usr/lib/
LDFLAGS=-L/usr/lib
LIBS=-lboost_system
./configure

After configuration, make should work!

Let me know how you go!

Download HamsterDB from Github.

Storing a set or dictionary requires an abstract data type which efficiently balances the complexity of insertion, deletion, searching and storage space. A common structure which gives pretty good results in all of these operations is the Balanced Binary Tree. More specifically, a programmer would use an implementation of the Balanced Binary Tree which employs algorithms to maintain correct balance after insertions and deletions. One such implementation is the AVL Tree.

Mandatory Theory

I’m not going to go into any sort of “tutorial” for building an AVL Tree. There are already heaps of those on the Internet and they’re not hard to find. Here’s a great one.

I will reiterate here, however, that a binary tree is a tree where each parent has a maximum of two children.

A binary search tree is a binary tree where all nodes in a node’s left subtree are less (or equal) in value than the subtree root, and all nodes in a node’s right subtree are greater (or equal) in value than the subtree root.

A balanced binary tree is defined for this article as a binary search tree where no subtree has a height greater than that of its opposite side.

Structure Definition

Assume that you want to create a balanced binary tree in which each node holds an integer indicating its values, and thus indicating its position in the final binary tree. Here is the C-style prototype for such a node type:

struct node {
    node *left;
    node *right;
    int balance;
    int value;
};

Algorithm Explanation

Motivation

Suppose you have an array of integers that you want to turn into a balanced binary tree. A naive approach to this is to insert each integer into the tree, one-by-one. Depending on the algorithm, this will almost always be slow, especially if you have many objects to insert. The reason for this is that you will need to do housekeeping for each and every insertion. For something like an AVL Tree this can be costly, with the potential for needing to do one or two rotations for every insertion (or thereabouts).

Explanation

To build the tree from the starting array, first ensure that it is sorted in ascending order. If it’s not too much effort to ensure that the array is always sorted by the time it comes to building the tree, then all’s well. If you have to sort it first, it might come down to performance analysis to see whether it’s cheaper to just build the tree using the iterative approach. Such decisions will need to be made on a case-by-case basis.

Once the array is in order, find the root item; if the array length is odd, take the middle item. If it’s even, take the item immediately to the right of the middle. Every item to the left of the root becomes the left subtree. Every item to the right becomes the right subtree. Recursively split the left and right subarrays until there is only one item. This is a leaf.

Implementation

Here is an implementation of this approach, based on the node structure defined above.

node *build_subtree(int *items, int length, void* node_mem, int *height = NULL) {
    /*This will give either the middle node or immediately to the right.*/
    int root_index = length / 2; 

    /* Make the node. It will be at the same index in its
       memory block as its value. Who needs memory management? */
    node *root = (node*)((char*)node_mem + sizeof(node) * root_index);
    root->value = *(items + root_index);

    /* These values will be used to compute the node balance */
    int left_height = 0, right_height = 0;

    /* Build the left subtree */
    if (root_index > 0) {
        root->left = build_subtree(items,
                                   root_index, 
                                   node_mem, 
                                   &left_height);
    }

    /* Build the right subtree */
    if (root_index < length - 1) {
        root->right = build_subtree(items + root_index,
                                    (char*)node_mem + sizeof(node) * root_index, 
                                    &right_height);
    }

    /* Compute the balance and height of the node.
       The height is 1 + the greater of the subtrees' heights. */
    node->balance = right_height - left_height;
    if (height) {
        *height = (left_height > right_height ? left_height : right_height) + 1;
    }

    return root;
}

int main() {
    int values[] = { 1, 2, 3, 4, 5, 6, 7, ..., 10000000 };

    void *mem = malloc(sizeof(node) * 10000000);
    memset(mem, 0, sizeof(node) * 10000000);

    node *root = build_subtree(values, 10000000, mem);
}

This code is actually really simple. It comes with a few complexities, such as maintaining that memory block. However, if your tree is fixed (no mode insertions/deletions) then you’ve got no problems. You could also ditch the node_mem and do a malloc instead. I prefer allocating as much as possible in one go though. That being said, you should take this sample as almost pseudo-code; you’d never really just allocate a block like that, especially if you’re going to do deletions and insertions. You’d probably want some sort of memory management mechanics in the works.

The tree you end up with is a balanced binary tree. This is evident by the fact that for each call to build_subtree, the array will be split into two nearly-equal sub-arrays. There will never be an opportunity to break the balance. What’s more, if the starting length of the array is one less than a power of two, the resulting tree will be perfectly balanced.

Conclusions

Under certain conditions, this algorithm is ideal for generating a balanced binary tree from a flat array of ordered values.

For an explanation on how to bulk-load a B+Tree, see the Wikipedia Article.

I wanted to demonstrate with some fancy diagrams, but I’m not good at making them. Anyone want to contribute?

Still reading? Good. A few months ago, I was investigation a crash of one of our production servers. It turned out that somehow a duplicate record had made its way into the database. We weren’t sure how, or exactly why it was causing the whole website to crash. Nevertheless, we figured if I deleted the duplicate then all would be well. We were under a lot of pressure, with clients calling up from all over the country demanding answers. So I logged into the production database box, fired up an Oracle connection and typed in the query to delete the duplicate. Something like

delete user where useid = 1234;

One little line. I spent the next five minutes pedantically checking that auto-commit was switched off, that I’d typed in the correct table name, the correct ID. Basically, I was struck with the realisation that I was about to delete a record from a production server running a high-volume financial application.

“Have you done that change yet?” said a co-worker.
“Not yet,” I replied, “I’m just a little scared of committing a change on a prod server.”
“Well,” my co-worker responded, “you’ve just gotta get over that.”

And he was right. We were a small team with very few formal processes and little in the way of technical support (basically we ran the whole business from desktops to software) but I trusted my team mates, I trusted the software and the tools, and I trusted myself. There was little for it but to click “submit” and see what happens.

I’m sure every programmer is familiar with this feeling, especially when starting out at a new job and working with a mature product. We make a significant change to a code base, and then waste a day by quadruple-checking everything from every angle before committing it.

Having just moved to a new role at a new company, I’ve fallen back into this mindset again. I’m working with a 40-year-old code base, and every time I make a change I find myself scrolling through file diffs over and over again. Finally, something in me snapped and I’m now on my way to becoming a code-changing machine.

Here are some tips for those still struggling:

1. Trust Your Team Mates

Code review is one of the best tools to help you get over this fear, especially if you can get a senior member of the team to take a look at your changes. It shares the responsibility between you, which will help to dull the anxiety you’re feeling about checking in bad code. If the senior programmer finds nothing wrong with it, that’s the best you could hope for. If the build breaks, well, shit happens.

2. Trust Your Tools

If you’re not using some sort of version-control software, be it SVN, Git, Hg, TFS, or P4, then you should purposefully break the code base to teach everyone in the team a lesson. A good set of tools will help you to get over your fears of checking in code. Why? Because the code can be rolled back. So you cock it up and wreck the application, so what? Just roll it back and try again.

Other tools which are of great help are those that come into play before you think about committing. File diff tools will help to make sure you’re not considering checking in changes you didn’t intend to make. Test harnesses (good ones) can leave you confident that your changes do not break existing functionality. Use them, and trust their results. Your manager decided to install them for a reason.

3. Trust the Process

A good software development team will be accompanied by a good software testing team. Trust them, or at least place the burden of guilt on them when software fails. Some people believe that if software fails in production, it’s the fault of the testers; after all, it was their job to catch the bug before signing off, right? Regardless of whether this is true or fair, if it helps you to get over you fear of checking in code then it’s well worth adopting it as your own personal policy.

Moving Forward

What if you don’t have access to all of these great resources, like a strong team, good tools, and competent testers? In that case, you’re probably working for the wrong company. Be the one to instigate change; ask the boss for more programming resources, so you can have someone with more experience and knowledge than yourself to guide you. Make room in the budget for better tools, and take the time to write proper unit tests and automated regression tests. Demand a dedicated test team, even if it’s a team of one to begin with. Failing all of this, you can make the ultimate change: change jobs.

I’ll admit, I’ve sort of fast-forwarded through the early design phases. This is partly because I’m a programmer; I can have input, but the major requirements are usually specified by a business analyst or similar. Also, I’m an impatient lad, and really want to get down into the nitty gritty. Lastly, I’ve left a lot of the cosmetic design out until later phases; I want to get the data access layer and a front end framework in place before I work on the styling. This way, it won’t be six months before I get to write any code.

Web Stack

With a proof of concept done, I can comfortably confirm my web stack:

• Web Server Lighttpd
• Web Framework Wt
• Language Choice ISO C++11 standard
• Additional Libraries Boost
• Compiler g++
• Javascript Library JQuery.
• Database MongoDB with C++ bindings.
• Operating System Debian

Considerations

There are a number of considerations when working with the stack described above. It most likely will not work the way you expect it to right out of the box.

Wt/Lighty/FastCGI Mix

Lighttpd works well with FastCGI out of the box, so there’s no problem there. The issues arise when you build a Wt module which links against libwtfcgi. After configuring Lighty to launch your Wt module as a FastCGI-enabled process, it will probably die:

(mod_fastcgi.c.1104) the fastcgi-backend /path/to/wt/module failed to start:
(mod_fastcgi.c.1108) child exited with status 1 /path/to/wt/module
(mod_fastcgi.c.1111) If you’re trying to as a FastCGI backend…. etc.

This was fixed by giving the Lighttpd user full control over the Wt directory: /var/run/wt. Restarting the web server saw the proof of concept application serve up as expected!

Package Managers

If you’re using apt-get or any other package manager, you’re likely going to get Wt in a state that’s not quite desirable. Firstly, Debian is a conservative OS, and will likely have a decisively old version of Wt in its stable branch. For this reason, it’s much better to remove Wt from your system and download the source directly using git.

$ git clone http://www.webtoolkit.eu/git/wt.git

The second reason, which most web programmers will be thankful for, is that the default installation of Wt includes an old version of JQuery. Version 1.4b. As of this writing, the latest release is 1.7.2. To have Wt serve this version, instead of the old one, change to the Wt source directory and:

$ cd src/web/skeleton
$ wget http://code.jquery.com/jquery-1.7.2.min.js
$ mv jquery-1.7.2.min.js jquery.min.js
$ cd ../../..
$ mkdir build
$ cd build
$ cmake ..
$ make
$ make install

You might also need to link the Wt libraries from /usr/local/lib to /usr/lib/.

Data

I did an Entity-Relationship Diagram using pen and paper. I then transferred that to an electronic copy using MySQL Workbench. The ERD is based on the UoD, which is based on the mind map. See how the documentation is becoming naturally hierarchical? This poses a significant risk; if you change one piece of documentation, you might have to change them all. It’s vital that the different parts of the documentation don’t conflict with each other. Separation should be maintained! The UoD will probably suffice as the central document, and a good effort will be made to ensure that not much overlapping occurs.

Alternatively (or additionally), you can nominate some documents as “throw-away”. They can be used once or twice in order to influence and guide the creation of more mature and structured documents, but ultimately you don’t care if they get outdated and neglected. It might just be easier to throw them out and do them again, or you may never use them again in the first place. The decision to throw away a piece of documentation has to be made on a case-by-case basis. Exercise some good judgement and you should have no problems.

Technology

I needed to make decisions regarding which applications, languages, and paradigms to adopt for the creation of What’s this Beer. Each decision needs to be justified against the original Aims and Objectives set out from the beginning.

• Database

  MongoDB and it’s C++ bindings will be used to allow me to develop skills using NoSQL databases. Mongo’s in-built map-reduce implementation allows querying and satisfactory (I hope) text searching.

  There is also the possibility of integrating CLucene or even Solr.

• Middle Tier

  There will be a middle layer, which will be implemented as one or multiple libraries, written in C++. These libraries will define the entities (business/domain objects) and the wrappers around them which dictate how they can be used (business rules).

• Web Handler

  Wt, a C++ Web Toolkit, will run on FastCGI. This should allow me to implement a scalable and portable web interface which can use the middle tier as it’s driver. It also comes packed with features that I will find useful, like an OpenAuth client implementation.

• Web Server

  Either Apache or Lighttpd. I’m leaning toward Lighhtpd.

• Operating System

  Any standard flavour of Linux, like Debian, will suffice. It’s normally cheaper to rent these servers than a Microsoft one, and I feel more comfortable running either of my chosen web daemons and my chosen DB on Linux.

Other Considerations

Additionally, I will need to confirm the following considerations which will make up my development environment:

• Development Box
  Most likely a VM running Linux.
• Editor
  Probably Notepad++ on Windows, hooked up to a shared folder on the VM.
• Compiler
  That’s easy! G++.
• Builder
  CMake, with some other shell scripts to automate the build and deployment.
• Source Control
  I’m really not sure yet. I’d love to get my hands on some hosting for either Git or Subversion. Probably Git hosted on Github so everyone can see the code as it’s written.

User Stories

User stories are a neat, agile way of documenting quickly what your software needs to do. They are often very short (once sentence), and exhibit the following form:

As a U, I want to A so that V.

• U is the user type, such as Administrator, Publisher or Klingon.
• A is the action; it describes what the user needs to be able to do, and hence what function the system must support.
• V is the value that the action will deliver to the user. Forcing you (or the BA, or whoever is writing the user stories) to state the value of the functionality will ensure that only useful, valuable features are implemented.

User stories should describe what the system does; not what it looks like, or the structure, or the implementation. Granted, you can probably infer some structure, but the point is to come up with a collection of verb-based sentences that describes the complete set of functions supported by the software.

There’s the rub; a complete set of functions is very hard to produce. Any one person will never be able to recall every single aspect of a system. It’s much better to do it as a team.

The list below is incomplete, and will probably always be incomplete. In fact, when you’re trying to be agile, there will probably never be any single piece of documentation that is 100% perfect. Instead, you need to rely on the full collection of documents, drawing and other pieces of media to fully build the system to spec.

Problems arise when two documents conflict with each other and make it impossible to make an implementation decision. It’s important to identify and correct these conflicts when you find them. That being said, the UoD probably contains conflicts already. I will try to have it agree with my user stories.

What’s This Brew: User Stories

As a user, I want to …

• view published news articles, so I can stay up to date with events.
• see reviews of products, so I can get information/be entertained.
• rate reviews of products, so I can give a quick opinion
• leave a comment on a review, in markdown, so that I can give a more in-depth opinion.
• view product pages, so that I can get basic information.
• rate products, so that I can influence the popularity of them.
• leave a comment on a product, so I can give my opinion without having to write a whole review.
• view a manufacturer page, so I can get basic information.
• rate a manufacturer, so I can influence the popularity of them.
• leave a comment about a manufacturer, so I can give my opinion.
• edit a manufacturer page, so that I can make sure the information is complete and correct.
• edit a product page, so that I can make sure the information is complete and correct.
• write a review on a product so that I can contribute to the community.
• edit my reviews after they’ve been published, so I can make sure the information is correct.
• add images to my reviews, so I can document my experience with the product visually.
• view other user’s profiles, so I can see what they’ve written and get basic information about them.
• edit my own profile, so other users can see correct information about me.
• edit other user’s reviews, so I can correct spelling and grammar.
• delete my own reviews, so I can get rid of them if I change my mind.
• delete my own comments, so I can get rid of them if I change my mind.
• delete my profile, so I can be comfortable that my information is not public when I don’t want it to be.
• vote in polls, so I can have my opinion heard.
• choose whether or not to receive emails, so I can choose just how I get information from the site.
• link products to manufacturers, to clearly show relationships and improve the quality of the information.
• search for reviews, products and manufacturers by keywords.
• be awarded points for taking part in the community, so I can gain access to higher privileges.
• log on using any of my OpenID providers, so I can maintain my state between sessions.
• associate my account with my social network accounts, so I can automatically push my activity to those sites.
• see FAQs, so I can find out more information about the mechanics of the site.
• see tips while I’m writing a contribution, so I can write the best review/page/comment possible.

As an administrator, I want to…

• delete any review, so I can ensure the integrity of the site.
• delete any comment, so I can ensure the integrity of the site.
• delete a manufacturer, to ensure that only valid manufacturers are included.
• delete a product and all its reviews, to ensure that only valid products are included.
• delete a user, to stop malicious users from interacting with the site.
• publish news articles, to alert users about important information.
• approve manufacturer, product or review edits, so that untrusted users can have their changes included.
• create polls, so I can have medals awarded to products and manufacturers.
• delete images from reviews and pages, to make sure that only relevant images are included.

As a Super User, I want to…

• See usage statistics, so I can target my publicity.
• Tweak database parameters, so I can make the website perform optimally.
• Configure advertising options, to provide the best advertising to users.
• See a full feed of activity, so I can monitor site usage in detail.
• Tweak CSS styles, so I can change the look and feel of the site without having to make code changes.

Onward!

What’s the Name?

The naming of websites is a difficult matter. It isn’t just one of your holiday games….

I brainstormed for a while for a name that said reviews, information, and beer. After some trial and error to find an available domain name, the idea clicked. I’m proud to announce my successful procurement of the following domain names:

• whatsthisbrew.com
• whatsthisbrew.net

So now the website has a name. What’s This Brew?

Brainstorming

To kick of the process, I began brainstorming. This is a great way to to get the idea onto paper and get some momentum.

The brainstorming method is normally best done with multiple people. This way, you get a good mix of different ideas. If you do decide to fly solo when you develop a piece of software, make sure you vet your ideas and get plenty of feedback as you go.

Brainstorming is meant to be an outpouring of different ideas. No matter how unrealistic the idea, just get it written down. You can always strip away the bad ideas later. The reason for this is that brainstorming should make use of your intuitive thoughts. Your intuitive reasoning is based on your life experience, as well as your inherent intelligence. You will usually be right.

Here is a a brainstorming mind map which I made with the great free tool bubbl.us.

Universe of Discourse

The universe of discourse, in this context, differs from a formal universe of discourse used in mathematics and formal logic. Here, I’m talking about an informal document which describes the entities which exist in the context of the system. It is a volatile document, which may change when new data types are added or removed.

The universe of discourse document is usually accompanied by more structured documentation like an Entity Relationship diagram and a schema mapping; both of which are based on the information contained within the UoD document. Therefore, it is important to maintain the UoD in line with reliant documents.

Here is the current Universe of Discourse document.

Coming Up

Still to come are the Entity Relationship diagram and schema mapping, as mentioned above.

In tandem, there are a few other documents and stages of the project which I will be working on. They will help to shape these initial diagrams by further honing in on the functions and entities I want and to discard the ideas which I can do without. These include user stories and some very rough design sketches.

Onward!

The Idea

To build a website as an exercise, it’s important not to get bogged down in defining the initial concept. In the world of popular sites, a winning idea makes all the difference. However, I’m not concerned with coming up with a great idea; I’m interested in the execution of the idea.

As such, I’ve come up with an idea that is simple enough to understand and start working on right away, yet broad enough to provide plenty of opportunity to demonstrate some different techniques. And the idea is…. a website about BEER.

Bring us Pints of Beer

Specifically, the site will be a review website, where beer critics (i.e. me) will taste as many different beers as possible and write reviews on them. Users will be able to comment on the reviews, or write their own. There will be plenty of opportunity for discussion and interaction on the website, bringing it in line with modern standards. There will be social media integration, typical content management and, well, lots of things. The features will definitely need to be hammered out later using a more formal process.

Generality

It is my intention that the resulting schema for the website will be generic. In this regard, the database and the data access layer will be designed so that it is subject-agnostic, that is, it could be used to build a website that reviews anything, not just beer. While for many endeavours this may seem unnecessary, I wanted to add an extra challenge to the database design phase and to showcase the flexibility of reusable code.

Aims and Objectives

It’s important to identify the major goals of a project. State what you want to achieve, then base every design decision, from database to interface, on the fulfilment of one or more of these objectives.

For example, suppose that you’re designing a commercial airliner. The primary aims of the product could be safety, efficiency and capacity, for instance. During the design process, someone incorporates mounted chainsaws on the wings and a laser rock show in lavatory. Awesome? Maybe. Does it increase safety, efficiency or capacity? Not in the slightest.

The aims and objectives for this project are:

1. Learn New Things
2. Improve Existing Knowledge
3. Showcase Design and Implementation Techniques
4. Have Fun

I have… things to do

There is a growing list of things to get done in the next few posts. This is by no means a complete list, and is intended cover only the initial stages. In rough order:

1. Concept Map
   This is a turgid swamp of ideas excreted from your brain onto a page. It’s kind of like brainstorming, but with a less awesome name.
2. Investigation
   I will be doing some minimal user investigation, mainly by asking myself questions but possibly interviewing others. In a serious project, you’d normally take this stage quite seriously; maybe invest some money in paid research.
3. User Stories
   From the investigation comes the user stories. At this stage, this will not be descriptive of the user interface. Rather, the user stories here will be a description of what kind of functions a user should be able to perform and what entities within the discourse they should be interacting with. An example would be: As a beer critic, when I publish a review I want a link posted on Twitter so my followers know about it. Simple stuff, really.
4. Universe of Discourse
   This is a list of all the entities that exist within the context of the website. This entry will be an informal and unstructured description of all the things that the system needs to be aware of. The structure will come as part of the…
5. Entity Relationship Diagram
   A structured diagram which describes each entity, its attributes and unique identifiers, and the relationships between said entities and cardinality thereof.
6. Schema
   A language- and DBMS-agnostic description of the schema after normalisation.
7. Technology choices
   Including but not limited to
   • Language Choice (C++, C#, Python?)
   • Data Storage (Couchbase, SQL Server, PostgreSQL, Lucene?)
   • Web Stack (Pylons, Django, Wt, MVC?)
   • Other 3rd party libraries (Javascript libraries, data access, authentication, etc. ad infinitum)

Onward!

Building a website, or any piece of software from the ground up is hard! There are numerous facets of the software engineering process which are unknown to most stakeholders. In fact, people who work closely with programmers still consider some things we do to be some kind of black magic.

The properties that make up a good website include a good idea, and a solid appreciation for the software process. The second part is where most would-be Internet entrepreneurs fall apart. Many prospective webmasters simply have no clue just what it takes to go from nothing to a working and successful web platform.

One easy way to avoid disappointment is to use a ready-made solution like WordPress. With some custom styling, many website ideas could be quite successful using nothing more than Joomla.

However, there comes a point in a website’s lifetime when it gets too big for the generic solution. While it’s important to avoid the Not Invented Here syndrome, there are a some advantages to maintaining your own solution.

Techniques

Over the coming months, I will be taking a simple idea for a website, and I will build it into a full working product. Everything from defining the problem space, to entity-relationship diagrams, database programming, business logic, user interface and everything in between. Throughout, I will be demonstrating some software development practices that are commonly used, as well as some that should be used more often.

In the end, I will be registering a domain and maintaining the website for real; this will add some real value to the whole project, and hopefully keep people interested. I will make the documentation for the project available as it is produced for readers to review and comment on.

Ultimately, this exercise should clear up a few things about software development, and provide a useful reference for those who are considering embarking on their own web project.

Onward!