I’ve been doing web development on and off for more than a decade. During college, I was the webmaster of the University of Minnesota’s computer science department, where I developed a variety of web applications and gave our department website a fresh new look (recently replaced by an even fresher, newer look). I got lots of practice with Apache, Perl, JavaScript, MySQL, and the usual alphabet soup of three- and four-letter acronyms. More recently, I’ve gotten into web development using Python and the Django framework.

After college, I worked as a journalist, blogger, and policy analyst, writing for Ars Technica, the New York Times, Slate, the Cato Institute, and various other places. Writing prose is fun, but after a few years I started to miss writing code and decided to go back to grad school.

For years, PJ has provided web design and hosting services to a number of my favorite blogs (including one I contribute to), magazines, and non-profits and I’ve always been impressed by his minimalist design sense and bulletproof hosting methodology. So I was excited when he invited me to join the team for the summer. I’m expecting to learn a lot about web development while helping clients solve their problems.

• PHP 5 (OOP skills a requirement)
• MySQL 5
• XHTML
• CSS
• JavaScript
• JQuery
• Python experience a plus.

The right candidate will fit right in with our fast-paced virtual office environment and be able to hit the ground running with our varied base of clients and growing stable of in-house initiatives. We’re preferential to applicants in or around Chicago, Washington D.C., or Reston, VA but will consider other areas for the right person. Starting salary will be commensurate with experience, talent, and knowledge of the movie Xanadu.

Interested? Feel compelled to make your mark? We’d like to hear from you! Send your resume to careers@dancingmammoth.com.

For reference, here is a screencap of Apple’s site:

Which brings me to two points:

1. When you have your own iconic brand, you really shouldn’t need to steal so shamelessly.
2. It’s 2009, Gibson. Did you really think table-based layout was still a good idea?

To help explain what we mean by color distribution, take a look at this little map we created using IWF.org as a base.

On occasion, we start layouts by grabbing all the content the client would like to see on the main page, making it black, and dumping it all into a new Photoshop file. Next, we make textual hierarchy changes by pumping up the weight and size for headings and subheadings. After some spacing and alignment changes its ready, but start collecting color only after these steps have been completed

First, we establish any existing colors which will need to be incorporated into our palette due to existing branding. In the example using IWF.org, the red from the logo needed to be added.

We needed to pay attention to an additional client request, which was that we keep the site feeling open and bright. Yellow or yellow used as a gradient is good for this.

You can add two colors to the palette by choosing one with a rich hue (aka saturation), in this case blue, then branch off by grabbing a tint of the same hue.

We also always grab something fairly neutral to use as borders, or for headings and backgrounds which require less emphasis than areas with brighter hues. For IWF.org, we chose a medium gray that is used on all borders and dividing lines.

Now the color palette is ready. Most, if not all of your color usage will be dictated by the palette. You can deviate, but only by shifting the base hue with shades and tints. Start by identifying which elements should use the same color. For example, all links within the main content area need the same color. All first-level headings need the same color as well.

Now you can experiment by using the colors in your palette in these positions. Any colors that are too light can be used for text as long as there is a background behind it with good color contrast to make everything readable.

Remember to use white as a color as well, not just for backgrounds. Any of the colors in your palette can be used for a background, which means any text on top of it can be white (depending on readability).

Huh? Let me explain:

Sites like digg.com and reddit pull in data by relying on a unorganized rabble of internet misfits to strain good internet content from the bad. ShoutingMat.ch looks to a definitive list of the blogs that everyone’s reading, bottling you only the best content from purest sources in the ice cold mountains.

Not only will you drink up high quality content, but each story delivers the blog or origin from whence it came, accessible via a handy drop-down list so simple even a caveman could figure it out.

Here. Me make drawing

Since The American Spectator has been around for 1967, keeping the established identity was an important part of the design process. We retained their look by re-using the existing color palette and by keeping the established logo simple in a basic white on red header. Further distributing the red, we threw it into the date-bars, content category headings, third column headings, and buttons. Using the black in the large featured post area serves as the focal point, drawing the eye with an over-sized image and further distributing color. We continued this with the bold black post headings and the background for the active state of the nav list in the right column.

We were also tasked with keeping a good chunk of the content available on the main page without a ton of scrolling. To accomplish this, we kept the spacing between posts on the homepage to a minimum. This expands of course when you click through to read the full article. To create visual separation of content, we used thin borders on the bottom of each post and kept the article headings big compared to the accompanying text.

Along with the re-design, this site has been built on a newly built backend framework which allows for much greater content control by the editors. Additions to the backend are super simple now as well, so any client changes/requests can be managed quickly and efficiently.

Bringing Site Control Out of the Admin Interface from Dancing Mammoth on Vimeo.

We began by creating several mockups in Photoshop, utilizing some existing media to develop cohesive looking examples. With these, they were able to give us great feedback, helping to push the designs forward and moving closer to a design which met their needs.

A few color tweaks, a section or two added to the right column and the design was complete. Reliably serving up high quality video to a potentially massive visitor base was crucial, so we went with the Amazon S3 grid for this. So far this has been the perfect solution as well as an inexpensive one.

Currently, we are re-working the center column a bit to allow for smoother work flow, but the same basic feel will be retained.

Some notes for the CSS geeks

Notice how the text changes color on hover for the “send us your videos” and “Drew Carey Project Archive” areas in the right column? This was accomplished by using an <a> which has this image applied to it using the background declaration. There’s a :hover state for the <a> which shifts the background image up by sixty eight pixels.

Some earlier concepts:

Recently, a client of ours wanted to institute a “point” system for an existing body of users. The idea was that certain actions of the user would generate points for that user, which the client could then track as part of an incentive program.

But What are “Points”?

At the time, we had a simple “users” table in our database which stored all our user-related data. Now we were asked, essentially, to add a new “points” attribute to the “user” entity. However, we could not simply add a “points” column to the “user” table, because the client needed to track individual point-granting actions separately, with descriptions and such.

But this was also not a one-to-many relationship with an abstract “point-event” entity either, since some points were inferred from information which was properly normalized into other parts of the database. For example, referring another user (information we know at user registration time) was worth a certain number of points, but to copy a “referred user” event to a “point-event” entity would mean denormalizing the database. If a user-referral were added or changed later, we would have to make sure to do the same thing to a corresponding point-event.

Thus a user’s “points” are an attribute of the user, but the value of this attribute is derived from potentially many different entities or attributes. Guess what? It’s a derived attribute (scroll to the bottom).

So, how are we going to deal with this?

Implementation

Derived Columns

Some “real” databases have native support for derived attributes (e.g., SQL Server) but as far as I know they all require that the value of the derived attribute be defined as an expression, not the result of an arbitrary query. We could get around this using a stored function which calculates the points for us, but this particular database was MySQL (which does not support derived attributes), version 4.1 (which does not support stored functions).

In any case, this is a bad solution for us because any changes to the point calculation algorithm would require modification of the database, yet we had been accustomed to putting this kind of logic into the application. Additionally, a lazy SELECT * (many of which were unfortunately sprinkled throughout our application) would suddenly become much more expensive, requiring an additional function call per row.

Application Code

The other solution, of course, is that we simply put all the point-calculation code into the application. The problem with this is that it would take multiple queries to the database for every user that interested us, and we could potentially get the wrong point value if a change were made to the database in between our queries (since MySQL MyISAM does not have transactions). Plus, if we want to sort by points (or something more complicated), we would have to do the sorting ourselves, in the application.

UNION

Clearly, we wanted to handle point calculation by a single query. The solution we finally hit upon was to use a temporary table (not a view, since MySQL 4.1 doesn’t support them) filled by a UNION. This is quite possibly the only good use for a UNION. Each subquery of the UNION would calculate points based on a particular attribute or entity, and all the subqueries would SELECT to common column names.

DROP TEMPORARY TABLE IF EXISTS tmp_all_points;
CREATE TEMPORARY TABLE tmp_all_points
-- Get referrer-derived points
(SELECT user.id AS user_id, COUNT(*)*5 AS points
FROM user ... INNER JOIN ... GROUP BY ...)
UNION
-- Get pointevents-derived points
(SELECT user_id AS user_id, SUM(points) AS points
FROM pointevents GROUP BY user_id HAVING points != 0);

This will give us a temporary table with 0, 1, or 2 rows per user. If we want to limit this to particular users, we can add the relevant WHERE conditions to the individual subqueries before we send them to the database.

Now if we want to do any queries which involve points, we can just treat tmp_all_points as a “points” entity with a many-to-one relationship with the “users” entity.

Want the top five point-holders?

SELECT users.name, SUM(tmp_all_points.points) AS points
FROM users
INNER JOIN tmp_all_points ON users.id = tmp_all_points.users_id
GROUP BY users.id
ORDER BY points DESC
LIMIT 5

Happy Ending?

By using a UNION, we were able to neatly model the derived attribute as a table, using a single query that maps easily to the logic of the derived attribute and is easy to extend to account for any additional criteria that the client may dream up. And we didn’t have to denormalize our database or introduce complex application code.

There is a caveat, however. Tables defined by a query have no index, and probably we are going to want to join on this table, which means we’ll be doing a join without an index. For this reason, it is pretty important to keep the result set of your UNION query as small as possible using additional WHERE conditions.

If your result set will always be large, split off the temporary table creation into a definition with keys and use a INSERT INTO tmp_table SELECT ... UNION SELECT .... Don’t use CREATE INDEX after filling your table, since creating an index on a full table is much slower than building it incrementally (except for FULLTEXT indexes, where the opposite is true).

Don’t Try This With Views

If you are using MySQL 5.0 or above, you won’t be able to mitigate this problem by using a VIEW. MySQL is not very good at optimizing views. If there is not a one-to-one relationship between the rows of your view and the rows of the underlying tables, MySQL will use ALGORITHM = TEMPTABLE for your view. So any view with a UNION in it will be created as a temporary table anyway.

Thus I would not wrap a UNION in a view for this technique, since you can’t control the result set size for a view and you will be generating a new temporary table every time you use the view, instead of once per connection.