Database Systems Introduction

Databases are what they do, and what they do is help people keep track of their records. Businesses in particular use databases to track data and derive information that helps administrators make informed decisions.

The most common type of database is a relational database, which stores data in relations represented as tables. The relational model was derived by IBM engineer Edgar F. Codd's use of relational algebra in 1970.

Data are recorded facts and numbers, and each row of a table is a record (or instance) of some thing of interest. Each column in a row is called a field. Records are instances of entities. Entities are just things like animals, customers, or any other noun that can be associated with data.

Records can be related to one another. For example, a homeowner has an address, so a table of homeowners can be related to a table of addresses such that each record of a homeowner can be matched to a record of an address.

A relational database is defined and maintained with a relational database management system (RDBMS). Commands to RDBMS systems are standardized in a data management language called SQL (Adopted by ANSI in 1986, and by ISO in 1987).

An understanding of SQL is fundamental to an I.T. professional.

SQL has two main functions:

  1. To define data using data definition language (DDL) instructions.
  2. To manipulate data using data manipulation language (DML) instructions.

Since tutorials on SQL can be found all over the Internet, the database system notes on this blog will focus more on higher level concepts behind database design, data modeling and business intelligence and relevant specific applications. An understanding of SQL is assumed in future posts on database systems.

Brian and Chewy

Brian is a funeral home director who smells like Fig Newtons. Brian amuses himself by putting a sombrero on  his cat Chewy and sending pictures of the now suicidal animal to his exasperated grandchildren using "the AOL." Brian hired you, a freelancer, to design and implement a website informing his clients that he will throw dirt on top of dead strangers sporting expensive formal attire for money.

But of course you aren't actually designing anything. What are you, some kind of expert?

Sometimes you end up with clients that push for creative control. What do you do when Brian tells you to place an animation of Chewy dry-humping a Koosh ball on his website's contact page?

A contractor sometimes hears bad ideas from the people who sign his or her checks. Some say you should swallow your pride and do the job. After all, what are you paid for? Others say you should put your craft first and be willing to fire morons to protect your own integrity.

A third option, which I find best, is to simply remind Brian that he's not your only boss.

Client's assert themselves to protect their investments. But what both contractors and clients forget is that they both have the end user as a common boss. Your job, as a contractor, is to convince Brian to trust your expertise. After all, he hired you because you know more than he does, and you yourself are an investment to protect.

Chewy's Koosh-smoosh will make grieving widows seek out a funeral home that takes ol' Grandad's 21-gun salute more seriously, and your job is to convince Brian that your ideas are not "better" so much as they are in both Brian's best interests and in his customer's best interests.

If all else fails, have a contract that says the client is liable for design decisions if you are just a monkey that types code. Do not sell yourself short to someone who refuses to let the people (s)he hires use their skills.


ProCSS is a BASH command line utility that automates file management tasks in modular Sass/Compass projects of any scale. For the sake of brevity I assume you are familiar with all aforementioned tools, because this is a lower level guide to the tool.

Assume we need to maintain a growing modular web application. We start styling with a Compass project created with ProCSS.

Scouts are partials that import and configure other partials. The logical structure is a build tree, which is just a set of partials linked together in a directory tree. The scss  directory is called the trunk, and any sub-directory of the trunk is called a branch.

procss init creates a Compass project with three scouts called _index.scss, _ext.scss and _local.scss in a generated  scss directory. These partials are called the index scout, the external scout and the local scout respectfully.

  • A external scout imports third party components.
  • A local scout imports non-scouts in its directory.
  • An Index scout imports scouts in its directory, and imports index scouts in immediate sub-directories (AKA "branches").

Altogether, an index scout, external scout and local scout are altogether called a trinity.

Exactly one trinity must in each branch and in the trunk.

Small Scale

Let's style a small web app.

Starting out, we only want to work on scaffolding, typography and decor. If you are in in the scss  directory,   procss touch layout type theme will generate _layout.scss, _type.scss and _theme.scss and import all three in that order. ProCSS automates imports without  “globbing.”

For now, our files are all partials. We will use an aggregator file (A non-partial compiled for some platform, media or requirement) that imports the trunk index scout to compile. The resulting CSS file will contain all styles.

Build Tree Generation

We have to add a bunch of modules, so we decide to reorganize. A text file called  tree will represent a new SMACSS-compliant build tree.

Lines are tab-indented.

procss gen tree generates this build tree.

tree.scss was generated so the project compiles out of the box. You can style immediately with rules already organized in a semantic way (i.e. /theme/_xmas.scss is a Christmas theme). Remember that everything is imported in the order declared.

To add a new module, call  procss touch module/my-module. To add a new directory, call  procss mkdir my-directory.


Assume our web application has grown into a colony of modules, complete with a function plotter.

Say we want to style scss/module/control-panel/displays/function-plotter/_axes.scss. We can immediately open the partial with procss grab axes. A recursive search is used to find the partial, so if multiple results are found, the first result is opened. You can navigate “towards” your target to avoid conflicting results.

You can navigate branches via recursive search using procss cd. To return to the directory you came from, use  cd -. Calling  procss cd function-plotter followed by  vim _axes.scss has the same effect as  procss grab axes.

If you wanted to edit a trinity in module/gui, calling  procss tri gui at the project root opens the relevant trinity in VIM using split views.


Assume we need a team to style our application. The fact that Sass does not have namespaces makes dependencies difficult to organize as projects get larger. When your developers have different responsibilities, they are also forced to be aware of all code in the project space.

You can convert branches of a build tree to self-contained projects using procss wrap. You can then manage dependencies inside each project independently with RVM. Specialized developers can then be assigned to different parts of the front end.


We talked about some ways that ProCSS takes care of tedious, repetitive tasks involving the management of partials in modular Sass/Compass projects. To learn more, read the ProCSS wiki.

How to Write Quality Code


One of the most puzzling topics of development is an operational definition of "good code." Is there an objective way to evaluate the quality of source code? If so, what is the process, and how is quality measured?

These questions are difficult to approach, but easy to put into perspective. We cannot understand code quality looking at the attributes of code alone, as some developers do. For example, good code is not necessarily "clear," since clear code often means formatting, which means whitespace, which means extra data for, say, minified CSS files that the end user does not need to download.

Minified client scripts are good for an end user, but bad for a working web developer who needs something clear to edit. Unit tests may assist a team working on a large project, but increase costs for small time projects. Detailed configurations files are helpful for representing project decisions, but may introduce complications in more convention driven workflows. Positive qualities of code are spoken of from the perspective of their beneficiaries, so it is a bit presumptuous to take a developer's satisfied interests as an indicator of good code.

Code is a circumstantial beast, making its usefulness relative to the people and problems it is meant to help. So what is "good" code, independent of the boxes people think in? To understand context-insensitive measures of code quality, we need an abstract understanding of both problems and people.

XKCD 844

XKCD #844

A problem is a subjectively declared, unwanted discrepancy between expectation and reality, so it is the product of preference. If a tree falls in the forest, and no one is around to care, is it a problem? If no one cares about a state of affairs to toss normative statements around, it is not a problem. Problem solvers ease troubled souls who want the world to change, be they clients, end-users or themselves.

At the risk of oversimplifying things, people want software to do whatever they want without interfering with their goals or motivations in other ways. The perception of quality is linked to the state of affairs the code creates and the state of affairs envisioned by the observer.

Taking subjectivity into account, plus the fickle, varied wants of people, it follows that quality code is a non-obstructive mediator between the conflicting interests it is meant to satisfy, including the interests of developers themselves. To deny this notion is to accept that quality code can obstruct the interests of those it means to help.

A skilled developer is an agent of reconciliation as well as production, and he does not unfairly discriminate against groups of people affected by his work. Therefore, good developers must have a strong sociological imagination on top of a commitment to pragmatism. Knowing who is affected by code ties one to context, and in turn things like conventions, readability, organization, maintainability, speed and so on.

I think it is a mistake to insist on reductionist operationalism to comprehend code quality. Instead, it makes more sense to adopt a kind of holistic, ecological pragmatism that focuses on the demands of all people affected by code. This does not just mean end-users, it means everyone affected by your code from users, to colleagues and even yourself.

While there is no formula that will spit out a score ranking the quality of code, there is always enough information to evaluate it from the perspectives of the people who are invested in it. The mystery of code quality is not one that can be solved by seeing the forest for the trees.

To write quality code, know who is influenced by it, and care about them. All else follows.