Over the past year we’ve worked with a lot of good people to put together some awesome results. We strive to be thorough but also efficient when it comes to building a great piece of work. And while our approach is leaps and bounds ahead of our competition we still recognize that we need to refine our process. I.E. we want to be better at what we already do well.

With that I have compiled a list of Imulus’ New Years Resolutions. And while I’m sure each individual of our team has their own take I think this about summarizes our goals.

1. Refine and expand our internal review process
   Here at Imulus we’ve got a group of very talented people. However, sometimes we don’t utilize this to our fullest. In 09′ we’ll strive to include everyone in our internal usability and design processes. Making sure that our approach to a client solution is the absolute best it can be.
2. Have an impact on our community
   Denver and Boulder are great cities with lots to offer. Great scenery, a hip tech movement, and engaging cultural opportunities. We think it’s important to offer something back to these places. In 2009 we’d love to be more involved in the education sector. This means everything from guest lecturing to hosting students at our office for the day. We’d also like to provide our support to worthwhile local causes. Green initiatives, cool industry meetups, and cultural events.
3. Define our identity. Who is Imulus?
   We’re a group of passionate, creative, driven people. And while internally on a day to day basis we have an identity — we haven’t worked hard enough at expressing it outward. In 2009 look for us to:
   • Be more vocal about our thoughts on the industry.
   • Push the boundaries of what a small time agency can do to change the way people work.
   • Expand ourselves as people not just a company. Each employee at Imulus makes us who we are as a company. We want the world to know each one of us better and see why Imulus is who it is.
4. Stay a family, not a company.
   We love what we do and we love who we do it with. Imulus is a family. No matter how stressful the project, how stringent the deadline, or how tough the personal problem is, we are there for each other. This is why we’re not a normal company and this is something we don’t want to change.

We’d love to hear your New Years resolutions or your thoughts on ours. Please feel free to hit us up via the comments, follow us on twitter, or join us in person. Happy New Year to you!

A few weeks ago I decided to set up a new service on my personal website to track all the social services that I’m a part of. Basically I wanted a central place where people could go to find out what I was up to, what pictures I was posting, and where I’d been. Now, I know there are services like FriendFeed and Socialthing! that do this on a larger scale but I don’t foresee many of my family members signing up for those just to see what I’m up to.

Enter Sweetcron, a free Wordpress like PHP and MySQL content system specifically built to handle lifestreaming. I heard about Sweetcron from my buddy Ryan and decided to give it a try for my new site. To my excitement it was exactly what I was looking for. Below I’ll cover the installation, interface, and end result of my Sweetcron experience.

Installation

Sweetcron is the easiest content system I’ve set up in quite some time. You download the compressed files and upload them to your server, create a MySQL database, and edit a few lines of a configuration file with the info. Once this is done the script has a built in installer that runs to finish the installation. By the time you’ve gone through this process you’ll have a username and password through which you can login to your Sweetcron administration section.

Interface and Use

Once you’ve logged into the back-end of Sweetcron you’ll see a few pretty basic options. Write: for posting quick notes, items: a list of your imported (published or unpublished) feed items, feeds: a list of the feeds you’re importing, and options: which contains basic account settings. Setting up your feeds to be imported into your lifestream is a piece of cake. Grab RSS from your favorite social networks and add them into your feed list¹.

Adding a Feed

Feed List

Imported Items

Sweetcron will automatically format and grab the necessary items related to the feeds. From there you can select from a few different themes of how you want your information to be displayed. If you’re ambitious you can set up your own theme by using the Sweetcron documentation.

Pulling Results via Cron

As the name suggests Sweetcron is reliant on pulling information from your RSS feeds at a regular interval in order to update your database. To do this Sweetcron works in one of two ways. First, you can use a pseudo method that will have Sweetcron update itself if the last update is older than 30 minutes. This method waits for someone to hit the site and then has that visit trigger the fetch. This may work for people without cron hosting access but I found the normal cron method to work better. To set this up I logged into my hosting administration and had the following cron job run every fifteen minutes:

/usr/bin/curl -s http://your-url.com/cron/link Note that sweetcron uses curl and this program may be located at different locations on different hosting providers, for instance:

curl -s http://your-url.com/cron/link

End Result

The end is a great looking lifestream that stores all of your information into a MySQL database that you host. The benefits are awesome. First, you own look and feel of the information output. Second, you don’t have to rely on a 3rd party service. And last, the whole setup is opensource, free, and easy to set up.

1. If you have issues with a particular feed’s RSS being supported I’d suggest routing it through Feedburner first and then importing it into Sweetcron. I had to do this with Brightkite.

While the bulk of Imulus development takes place in a .NET environment we all still enjoy geeking out from time to time. As a previous Ruby on Rails app developer (mainly front end) I have a fascination in staying up on RoR as well as other open sources frameworks and languages. Obviously this includes a vast number of options now days (RoR, Cake, Django, etc). However, the bulk of them have one common thread, MySQL.

Unfortunately for quite some time getting MySQL to run on Mac OS X 10.5 was somewhat of a pain in the ass. In comparison to some database setups typing in a few terminal commands is no big deal, however, compared with installing MySQL on 10.4 Tiger the 10.5 install was a huge step back. Tiger had a simple PKG installer that once run offered a simple start/stop MySQL preference pain within OS X’s system preferences. However, with the release of Leopard this prefpane was no longer functional. Luckily the issue has been fixed!

The bug has been addressed and there is now a prefpane that can be downloaded and used with version 5 of MySQL. Further it also seems that new versions of MySQL have this fix implemented by default. Great work MySQL community, it’s always nice to see frustrating issues fixed! Especially those that will help new users get a chance to try the product without jumping through hoops.

Here at Imulus we all use glass top studio desks. There are a few main reasons for this: sex appeal, weight, and office personality. However, there are also a few hidden benefits.

From time to time when brainstorming and talking out ideas we’ll simply pull out a whiteboard marker and start drawing right on the desk. Rather than getting distracted moving into the conference room and drawing on the whiteboard (which usually involves erasing it first) we’ll just get our ideas out right away. Plus then you get the added benefit of being right next to the computer and you don’t have to retrace your ideas onto a notebook.

Sure, this could be done using a sketchbook or a portable whiteboard, but we find it a nice add-on to the standard “desk setup” of today’s office.

Earlier today I was reading an A List Apart article titled Progressive Enhancements with CSS. The main idea behind it being that breaking out styles into a multitude of files is beneficial. For example, creating a typography.css for type styles, a layout.css for positioning styles, and a colors.css for colors and graphics. At face value this sounds great because abstraction, for the most part, works well on computers (utilizing folder hierarchy’s, categorizing types of media, tagging web articles, etc).

Fine and dandy. But there seems to be a real world problem.

There are three big reasons I see not to break out CSS into multiple files.

First, when you break out CSS into multiple files you are forced, no matter what to write a lot of duplicate code. For instance, if I want to have a certain container have a typeface, background, and color in a single main.css file I can do the following piece of code:

#element {
     position: relative;
     float: left;
     width: 20em;
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

However, if I break this out into: typography.css, layout.css, and colors.css files I have to do the following:

/* typography.css */

#element {
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

/* layout.css */

#element {
     position: relative;
     float: left;
     width: 20em;
}

/* color.css */

#element {
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
}

Okay, pretty easy to see that the amount of code being used favors having one central CSS file. Now, let’s talk about style management and the second argument I have for not using multiple CSS files.

A single CSS file for a website can grow to be quite a large file. Most I’ve written fall in the range of 1200 to 2000 lines. The problem with this is that making small changes can be a bit of a hassle. However, I would argue that the single best way around a complicated CSS file is to clearly comment code, use shorthand css, and make sure there is good style structure. I.E. Don’t go styling something in two different parts of the file and don’t write five lines of CSS when one will do.

But, in no way is the answer to break the CSS into multiple files. Why? Because the worst possible thing you can have to do is deal with the above problem three different times. Granted, if you only have to make a small color change than you only have to edit one file. But, if you use only one file to begin with then you only have to edit one file anyway.

Last, there’s a reason a site like digg loads in one 2500 line CSS file. The answer is that the less page requests the better. Doing multiple page requests to get different styles that are separated is inefficient. If a site gets a lot of traffic or a large traffic spike the less page requests the better. Granted, this may not be common but when it happens there’s nothing more important than trying to keep the site up.

Want more assurance?

Neither Dan Chederholm simplebits.com, Veerle Pieters veerle.duoh.com, or Jeff Zeldman zeldman.com use broken out CSS for type and color.

It has to say something when the big wigs in the bizz don’t follow the advice of A List Apart eh?

Exceptions?

As always, there are a few exceptions to this. For instance, if the website is like MTV.com and has a constantly changing color scheme then it could be useful to break out individual styles into a separate CSS file. One that overwrites the default styles of the base design and can be updated without disrupting the primary styling of the site. Also, microsites that have completely different layouts from their parent sites almost always deserve a new CSS file.

Conclusion

Basically there’s no need to break out your styles into a multitude of files. While the idea of abstraction might sound good the benefits just don’t add up. All you really end up with is a waste of time and resources.