Posts Tagged ‘design’

Fresh Meat

Wednesday, April 8th, 2009

We’ve updated our site. The look is much more reflective of the values we have at Hacked: Code, Death Metal, and Horror. We’ve done a few things to keep the new design both appealing and usable. The combined focus of pretty (kinda) and readable will make all of you cower in fear.

We’ve implemented the famous sIFR technique to display headings in non-standard web fonts. Windows, Mac, and Linux do very few things the same way. The one thing they all do the same though, is render Serif, Sans-Serif, and monospaced fonts the same. While we’ve gone with a monospaced font for the content of this site (a homage to coders everywhere), it was our feeling that the headings should be much different. Keeping with the grungy theme of the vertical logo, we used the same font for the h2 and h3 headings.

We’ve also kept the base font-size at the default level. There’s a great article about this here, with a lot of reasoning for not altering the base font size. The takeaway for us: most screens aren’t that small anymore and small text is just too hard to read.

So, we’re all new. We hope you like it. You’d better …

Factory Pattern

Sunday, March 1st, 2009

In following the theme of design patterns we’re starting this site off with, we’re talking about the Factory Pattern here. The Factory Pattern, true to it’s name, acts as a factory to produce objects depending on the parameters provided to it.

A common example of this are configuration objects. Suppose you’ve setup a configuration for you’re application to use an XML configuration file to run. Now, let’s say for some unknown reason, you need to use an INI file for configuration. Or, let’s say that today you’re using MySQL for database storage, but tomorrow, you might be forced to use Oracle.

Having to find where you create the instances of classes could be difficult, or maybe even impossible. The solution to this dilemma, is to use factory pattern to produce objects where any future ambiguity might cause a disaster.

Typically, the way a factory is implemented is to implement some sort of class that acts as a quasi-gateway to the object that’s needed. To keep things simple, we’ll assume we’re trying to get a database object and we need to not worry about the actual implementation of the database (more…)

Singleton Pattern

Sunday, March 1st, 2009

One of the things I see all the time with developers, especially PHP ones, is a complete lack of understanding for basic computer science principles. Key among those principles missing from many programmers, are design patterns. While it could be said that some folks use design patterns far too much, most software guys / gals (especially freelancers) don’t use them nearly enough.

The idea behind design patterns, is to make routine the typical problems encountered by most software development. It’s likely that any problem get stuck in when trying to write the next biggest app in the world, someone already figured out. So, in much the same way that Object Oriented programming lets applications reuse code, Design Patterns help developers reuse algorithms and ideas.

The most basic, and classic design pattern is the Singleton Pattern. The principle, as you might have figured out, is to ensure singularity of an entity. There are some objects that should never be duplicated throughout the life of an application. Great examples of these are database connectors, request dispatchers, registries, etc …

So, at it’s most basic, a singleton is a class. What make it special, is that it’s constructor is not publicly available. Instead, the instance of the class is publicly available through a special method, getInstance. This function handles the acutally getting of the instance, and prevents duplication of the class.

Easy enough, here’s an example in PHP : (more…)