Every Wednesday morning, we have a Development Team meeting. When I first heard about this practice, I must admit I was a little wary. I don’t know anyone (especially of the developer stripe) who gets excited at the thought of a weekly meeting. I was relieved to find that these meetings would not only be painless, but that they would become something I actually look forward to (and blog about).

Our weekly meeting consists of each member of the team doing a quick blurb on what he/she has been working on and what he/she has learned in the past week. Lately, we have even been encouraged to throw onto the projector for all to see what we have learned or written recently. This is so fascinating to me for a number of reasons.

Experience Through Osmosis

Since my experience level is so low compared to my peers, it is a chance for me pick up a lot from a wide range of talented people. I have never bothered to tally up the collective years of experience in that room, but it’s certainly in the decades range. It’s safe to assume that the people in that meeting have forgotten more about development than I have learned at this point. And I get to sit there and soak in as much as my brain will hold. Even if I don’t use any of what I learn today, tomorrow, or next year, it’s in there somewhere.

The Learning is Never Over

It serves as a reminder that even the senior level devs still spend most of their days learning new things. One of the best thing about the development field is that it is constantly changing. The technologies we work with are fluid. New features for existing tools and new tools altogether make it an exciting space to work in. When I am in the dumps and feel like I’ll never be any good at development, it’s nice to know that ours best devs still learn new things. The Wednesday meeting serves as a reminder that, in software, “you never know enough” (and that’s a good thing).

You’ve Gotta Have Something for Show-and-Tell

I like that I have to have something to share every Wednesday. If the work I do for Centresource ever becomes so routine that I don’t learn something new each week, I have to go out and find something to learn. As a member of the Development Team, it is my duty to find something to bring to table for all of us. It causes me to think about where my weaknesses are and to keep a tally of new things I learn. In a job where the most seemingly minor task may require multiple Google searches, I think it’s important to not lose sight of how much I learn day-to-day.

Like I said, I’m pretty new to the field and to Centresource, but I love what I do and where I get to do it. What I love most about this place is the emphasis that is put on learning. We are not a culture where you don’t want to expose how little you know for fear of being canned (which would be a real concern for me elsewhere, I imagine). We embrace learning on the job and growing as a developer– and, dare I say, growing as a person.

Include the Necessary Gems

Setting Up Authlogic

You can follow this tutorial for getting Authlogic set up in a Rails 3 app.

Adding to an Existing Authlogic App

The only extra authlogic database column that your user model needs is the single_access_token field. If you don’t have it already, you can add it with the following migration:

Add ember-auth to your Ember App

Make sure to include ember-auth in your application.js manifest.

Create an auth.js.coffee file (or auth.js if you’re not using CoffeeScript) where you’ll define the ember-auth settings. Notice the auth file has already been included in the above javascript manifest.

Add API Authentication

I have my auth code in the api/user_sessions controller.

You’ll notice that I’m inheriting from API::BaseController instead of ApplicationController. I do this because the require_user auth method needs to be unique to the way ember-auth works. Here’s my API::BaseController

Set Authlogic to use Single Access Authentication

This will tell Authlogic that each request will contain a token, which it will use to authenticate the user. When using single access authentication, Authlogic does not keep track of the user session.

Now, you can protect any of your api controller actions by inheriting from API::BaseController and adding a before filter.

That’s it for the Rails side! Any further implementation will take place in Ember, and you can follow the excellent ember-auth documentation for that.

We were initially attracted to the app mainly because it will watch *.coffee and *.sass files (and *.less) and as they are saved, Codekit automatically compiles them and, if you have the feature turned on, injects them into your browser (with CSS files it autoupdates the page, no reload, with JS files it auto-reloads). This alone was worth the price of the app as often times you could hit save and by the time you’d flipped to your browser the page was updated with the new styles. But as we’ve spent more time with the app, we’ve found a few other features that really make our lives better. Here are 4 of them:

1. Optimization of images

Our design department creates really spiffy looking designs all the time that we in the Front-End group then slice up with Photoshop for inclusion in web pages. It used to be that you had some ability to optimize .JPG’s and .GIF’s with Photoshop, but PNG’s required other tools or magic voodoo dust. No longer! Codekit can optimize all image files, reducing cruft without any reduction in visible quality. I find this most handy with PNG’s, I can save out of Photoshop to the directory in my project I want the file in, Codekit will find it automatically, and then it’s just one click to optimize. The results can be astounding. To the right is a screenshot I just took of the window I’m writing this post in, and codekit’s optimizations. You’ll notice that’s a Retina screenshot (2878 x 2374px) that Codekit chopped almost in half, file-size.

2. Automatic inclusion of Bourbon

We love Thoughtbot’s Bourbon framework. It’s super lightweight, easy to work with, and extremely flexible as we build custom solutions for our clients. Codekit loves Bourbon too – you can add the framework to any project with just a couple clicks. 

3. Setting output paths for compiled assets

When organizing files, it’s often easier to separate the uncompiled files from the compiled files. Codekit makes that easy. Just right click a file, and hit “Set Output Path” and define where you’d like the compiled file to go. This is handy and helpful, but it becomes even more powerful when used with the next tip.

4. Organization of coffee and less files

Just being able to set the output path of files is great, but often times you want to do more than just compile the files to a different directory. When worrying about page speed for your rendered pages, one of the easiest things to do is reduce HTTP requests being made on load. This is often done by concatenating all your JS and CSS files into one larger file, a process that Codekit makes really easy.

At Centresource, we’re used to working with the Asset Pipeline in Rails now, so we like to keep our coffee and css files small and organized in a structure similar to the views. This has carried over into development of Static HTML sites and Drupal projects as well. In the past, because wanted as few files as possible, we might have been tempted to just put all our Javascript in to one scripts.js file. Now, with Coffeescript and Codekit, we can break things down into small, semantically named, easy-to-read files.

The easiest way to do this (when you factor in source control and working with multiple developers) is to make a manifest file, say app.coffee, or screen.scss, and use the proprietary “codekit-prepend” and “code kit-append” statements to organize your file. Say you have three coffee classes: Foo, Bar, Baz, and you want them to be concatenated into app.coffee. You put each class in a semantically named .coffee file: foo.coffee, bar.coffee, and baz.coffee. Then, in app.coffee, you’d put this at the top of your file:

# @codekit-prepend 'foo.coffee'
# @codekit-prepend 'bar.coffee'
# @codekit-prepend 'baz.coffee'

These statements are not valid Coffeescript so you need to comment them out, but Codekit will catch them none-the-less.

This is great for creating a utilities.js that has all your plugins and frameworks concatenated and minified, or for organizing all your css by pages but only including one css file in the actual page. We love it!

Codekit is a great tool. If you use it, I’d love to hear of other cool ways it helps you improve your workflow. To find out more, check out the Codekit page.

So my strategy is as follows: I use Windows to run web browsers, the odd desktop app like Photoshop, handy GUI utilities like calculators, media playback, and the like. On top of all this, I have installed VirtualBox and the easy-to-install Windows version of Vagrant, running a VM with the Ubuntu server distribution (I have no need of the gnome or any other GUI therein.. yet. That may change when I need to start running Selenium-based tests, but it’ll do for now). I use two PuTTY windows – one on each monitor – to connect to the VM, which is configured to startup at boot. I forward the necessary ports from the host to the guest (made easily configurable by Vagrant) and provision the whole affair with Chef.

Internally, I use tmux, vim, and all the usual CLI tools of the trade to ply my own. Servers, databases, services and the like all run internally to the VM, and the only crosstalk I’ve yet needed to make use of is accessing guest-hosted websites with my host-based browser, a feat easily enabled by Vagrant’s port forwarding. RDBMS GUIs will likely be needed soon enough, and the same solution will presumably apply thereto.

So, how has it been? So far, the experience has actually been pretty pleasant. After getting the VM’s hardware and the general translation and keyboard layout bells & whistles configured to my liking, I feel for the most part that I’m back in my native Linux land when developing. No issues arising from the system being a VM have yet reared their heads, and aside from the MS chrome peeking around the corners of my terminals, I could almost be convinced that I’d never left. As far as the desktop bit goes, I’m still acclimating. However, the fact that the sound, the graphics, the power management – all the hardware in general – works perfectly without my having to tweak arcane configuration settings is a very great improvement over my earlier experience; and not having to forcefully implement hacky workarounds is a weight off of my shoulders.

That all said, I do have a few qualms. If you know of an acceptable solution to any of these, please comment and share!

1. PuTTY is the best SSH client out of all those I’ve tried, and it’s not that great. It’s profile saving/loading system is nightmarish from a UX standpoint, the built-in fonts are fugly (though I can presumably use others once installed on the OS), but the thing that irks me the most is that I can’t go fullscreen! I have absolutely no need to see any of that garish MS chrome on the edges of my screen, and having it present detracts from the real estate available to me for tasks of actual importance, as well as simply clashing aesthetically.
2. The price of the full-featured Windows is prohibitive. There are certain features available only in the Professional or Business or whatever-they’re-called versions of Windows 7 that I would’ve found quite useful, but that I don’t really count as being worth the extra few hundred I’d have to lay out so to acquire (group policy editing comes to mind).
3. No real shell script to speak of. Sure, there’s VBScript and whatever that trash is that passes for a shell in cmd, but these simply don’t possess the power and terseness of bash.
4. The godforsaken automatic restart after update. I understand that Windows needs to update itself frequently in order for the boys in Redmond to have the slightest hope of plugging security leaks as fast as they’re discovered, but I do not at all appreciate having my viewing of some video on Hulu interrupted without discernible warning by my computer suddenly rebooting itself. Turning this trash off is apparently one of the features they reserved for the “Professional” users, and I quite frankly don’t see how this isn’t a bigger issue among Windows users at large. I understand they’ll “fix” this garbage in Windows 8, but for now, it is pretty off-putting.

Anyway, those rants aside, all in all my experience has not been unsatisfactory. Neither, however, has it been revelatory, and I believe I’ll need more time to make a decision one way or the other. I’ll keep you all posted!

Due to many factors, setting up Linux turned out to be Hell. Both the kernel and GRUB wouldn’t have the ability to recognize the aforementioned pseudo-RAID array as a single disk until later (I’m still not sure if GRUB does), so I first had to effectively wipe the filesystem in its entirety and destroy all partitions; turn off the pseudo-RAID functionality in the BIOS (a miracle they allowed me to do so, considering everything else they expressly hid therefrom), re-partition the two drives as truly separate devices, and reinstall Windows on one disk while setting up Linux on the other. That was a night of my life I’ll never get back, and I considered dropping Windows from the lot entirely, but figured it might be handy to have as a last resort / testing platform and so opted to keep it at the last moment.

Finally having completed the installation, I booted up Linux for the first time and went about the standard post-installation rigamarole of bringing in my dotfiles and configuration settings, installing the basic tools I use everyday, etc. There were other problems during the process, but I cannot fairly lay the blame for them at HP’s feet. Switchable graphics – as this machine possessed – were still a relatively new and uncommon affair, and the distro kernel hadn’t been built to include certain systems associated therewith. So that’s one kernel rebuild right there, and I can assure you there were many more as time went on. Other issues include ACPI issues that to this day have not been completely resolved and reappear intermittently and seemingly randomly, a total inability to recognize the microphone, and other hardware-related woes. Still, I persisted, expending the elbow grease to fix what I could and resigning to live with the rest. When finished, I had a perfectly usable little hi-res Linux machine upon which to do my development that I could call 100% my own.

I have now used this machine for a year, and have thoroughly enjoyed it… when those issues I said I’d “live with” weren’t driving me absolutely insane. Lately, however, I been having doubts about my choice of OS, cataloged as follows:

1. I had started to miss certain proprietary software that is not made readily available on Linux (Photoshop comes to mind – I need it rarely, but when I do, GIMP simply isn’t an adequate substitute). I could run it on Wine, sure, but all my experience with Wine has been less than pleasant, and I didn’t want to go through that business again.
2. I was becoming sick of the desktop quirks. I love Linux, and the developers of the various distros have my absolute and utmost respect; but the unfortunate fact is that drivers for hardware show up there last. Due to its low marketshare among PC OSes vendors have little incentive to develop them themselves, and in many cases, open-source and initially imperfect options are all that is available. That said, give it year or so, and you’ll likely see solid drivers made available; but that year is one in which I’m not getting my full money’s worth.
3. Honestly, I was doing a bit of introspection and reexamining my prejudices against Windows. Why do I hate it so? Could it be that I’m not giving it a fair chance, not having used it in nearly 10 years? Windows 7 is purportedly a vast improvement to Vista; maybe it was time to give it a chance.

Because of these and other thoughts, I decided to try an experiment: I would switch back to the Windows 7 installation on my other, nigh-forgotten drive and try it out as my primary desktop for a few weeks, and see how it went. This post is the story of the start of that journey, and how i reached a place where I was at least not anthropomorphizing my machine in the most violent of fashions.

Now, Windows has its problems: certainly it’s an absolute crap development environment if you want any real, low-level control of a machine, or if you want to do any development in a language that wasn’t pinched off from the Great Golden Sphincter of Redmond. The registry’s a horrid design that – despite purportedly being recognized as such by its own engineers – has stubbornly persisted through multiple versions and will almost certainly be there in the next. The built-in command-line interface (cmd) and nearly every third-party one I have yet discovered are all so underpowered as to be little more than curiosities and toys. I won’t even get started about security. However, it does do one thing quite well: provide an ultimately pleasant, consistently usable desktop environment. For everything else – as they say – there’s Linux.

Continued in Part III!

I have been a *-nix man for many years, starting with Mac OS X and it’s largely-FreeBSD/NetBSD-derived platform. I have literally nothing bad to say about the software of Mac OS X. Nothing. I adore it. What I don’t adore is the inflated price of the hardware. Certainly, it is of excellent quality; but I in my frugality have this crazy idea that I shouldn’t have to pay what Neal Stephenson referred to poetically as “<expletive-redacted>-you money” (e.g. $2500+) for a laptop with ultimately mediocre specs. I can get a laptop with just about *twice* the power for virtually half the price from a fully reputable manufacturer if I make what I consider to be the relatively small sacrifice of a sexy, top-of-the-line desktop experience and the social mating plumage that is that familiar, brushed aluminum case.

Up until recently the cost wasn’t really a factor, as my development machines were supplied largely by my employers, including Centresource. My first day on the job, CS set me up with a brand-new, perfectly splendid little 13″ MBP, 4GB RAM, 250GB HD (this was before they were offered with SSDs) and all the other usual trimmings; in addition to a new 27″ external monitor and even one of those mini-display-port-to-VGA adapters. This machine was an absolute pleasure to develop upon for nearly any task I was asked to complete. Unfortunately, as the size and scope of my workload increased (both as commissioned by CS as well as my own, personal, “for-fun” work), I began feeling the pinch of those 4GB. So, of my own volition, I sent out to NewEgg and got myself a couple of 8GB chips for a total of 16GB RAM. Good heavens, did that machine fly now.

However, I was now faced with a few issues:

1. CS owned the machine, but I owned the RAM. This isn’t really a tangible problem since I don’t expect to be leaving any time soon, but it was nevertheless an admittedly personal reservation based largely in my perhaps-paranoid concerns for privacy and security.
2. Being that I have crap eyesight to begin with and like viewing multiple documents simultaneously, 13″ was becoming a bit of a pinch-point for my own development whilst away from a desktop station with its extra monitor, whether at home or the office. I frequent coffee shops quite often as remote work environments, and the degree to which my productivity faltered as a result of being limited to the resolution possible on this machine was becoming unacceptable to me (note: I have what some might consider to be ridiculously high standards for my own productivity). In short, I wanted more real estate on the go – much more; something like 17″

This being the case, I decided it was high time I bought my own computer, since my last personal purchase of same had been nearly 4 years back and a desktop unit besides (as well as now lying disemboweled and largely forgotten upon a table in my garage). I looked at the prices for an Apple laptop with the specs I desired (even the refurbished models), and almost immediately made the decision to buy a PC and switch to Linux as my main desktop environment – a decision I had toyed with in the past but never really committed to.  However, in order to maximize my very recent investment in the aforementioned memory, I had to find a machine that would accept the same chips in the same configuration.

I found several candidates, but for the money I settled upon an HP Envy 17″. I will say here that I will never buy another HP computer again: they had loaded down Windows with a truckload of proprietary crapware, they lock out almost every part of the BIOS worth mentioning, and they had taken up all 4 permitted primary partitions on the weird Intel pseudo-RAID array (one with a restore disk-image because they’re too cheap to print the thing to a DVD, the other with something called HP_TOOLS the purpose of which I cannot readily fathom and have no desire to learn lest it anger me further). Of course, my usage of Windows while in possession of this machine was intended to be minuscule if present at all, and so I quickly set out about installing my preferred Linux desktop distro, Linux Mint (then version 12).

Continued in Part II!

The goal was to create a music discovery application that provided users a unique experience in finding the best in Christian and Gospel music. We’re pretty excited with the results!

Check out the new app — now playing on Spotify!

Now, while I’m totally guilty of bandying around big scary terms like “asymptotic notation” (I’m a notorious stickler for nomenclature), what this boils down to is the following mathematical notation (and its related brothers, which we’ll get to later):

[O(g(n))]

Most typically, you’ll see this used and referred to not as (O(g(n))), which doesn’t serve much purpose unless we know already what (g(n)) is, but rather in terms of a specific (g(n)), say, (n^2):

[O(n^2)]

Moreover, for the purposes of this discussion, we’re going to look primarily at the following notation style:

[f(n) = O(n^2)]

So what on earth does this mean? Well, let’s think about algorithms. What is an algorithm? Simply a series of instructions for performing some task, right? In computing specifically an algorithm is implemented as an actual, written program in your language of choice. But under the hood, mathematically, an algorithm is a function (sometimes pure, sometimes not): it takes some input(s) and delivers some output. In the above block o’ math, let us equate (f(n)) with some algorithm we would like to implement, say, sorting an array of integers from least to greatest. With an algorithm such as that, you would give it an array of dubiously sorted values, and it would give you back an array containing exactly the same elements but in sorted order. Represented mathematically, we have:

[s(a)]

where (s) is the algorithm function itself, and (a) is the array to be sorted. Now, let’s keep in mind that there are many different ways of going about sorting an array – naturally, we would like to pick the fastest one for the task at hand. So in order to know anything about the performance of an algorithm, we should probably come up with some way to represent how long it takes to run. To wit:

[T(s(a))]

represents the “time” (T) it takes to run algorithm (s) on input (a). OK. So, how can we begin to reason about what the range of this function might be? Actually, perhaps that’s jumping the gun – what would really be the domain of this function? What measurement of your general work-a-day sorting algorithm would dictate how long it takes to run? The answer, my friend, is the size of the input: it should make sense to anybody who’s actually had to do it that sorting a 10-element array is a heck of a lot faster than sorting a 10,000,000-element array. So, really, our (T) function can be abstracted further as a function of (n), where (n) is the size of the array to be sorted:

[T(n)]

Since the value of (T(n)) will grow as (n) grows (presumably), this seems like a solid footing to start our thinking upon.

Alrighty. Now that we’ve got some notation to start thinking about how we’ll build this bad boy, let’s actually pick a real, concrete algorithm and think through it. For the purposes of simplicity and succinctness (cue laughter), I’m going to go with Bubble Sort. If you want to learn more about the actual algorithm, I suggest you read the wikipedia article linked to above, because I’m gonna skip over a fat exposition on what it actually does and how it does it in favor of thinking about how long it takes to do it, and specifically how long it takes to do it to the worse possible case of input: an array that’s already been sorted, but reversed. Please note I have copied the following pseudocode directly from wikipedia, and credit therefor is due directly to the author of the page linked to above.

OK, so that’s the algorithm from wikipedia – but what’s all that nasty-looking business on the right? Put quite simply, that’s our best guess as to how long that line of code takes to execute! Note that each line is some function of (n) and some constant (c_{i}). Now if we wanted to figure out exactly how long this algorithm takes to run, we’d need to know the value of those contants, e.g. (c_{1} = 12.2ms) or something. You’ll notice that some lines only seem to take a constant time to run; that’s because those lines are only executed once regardless of how big the input is. Other lines are the associated constant multiplied by (n) – those lines will execute once for every unit of input. Still others are multiplied by (n(n-1)) – these lines are executed (n-1) times for each input. Now, handily, we can figure out our overall formula by just adding all these things together:

[T(n) = c_{1} + c_{2} + c_{3}n + c_{4}n + c_{5}n(n-1) + c_{6}n(n-1) + c_{7}n(n-1) + c_{8}n]
[T(n) = c_{1} + c_{2} + c_{3}n + c_{4}n + c_{5}n^{2}-n + c_{6}n^{2}-n + c_{7}n^{2}-n + c_{8}n]
[T(n) = (c_{5} + c_{6} + c_{7})n^{2} + (c_{3} + c_{4} + c_{8} - 3)n + (c_{1} + c_{2})]

But it turns out that the precise value of each constant is practically useless – the constants in question represent such complex matters and concrete facts of the real world as language of implementation, hardware specs, how many other processes are fighting for CPU time, etc. Remember that we only really care about the performance of the algorithm – not the performance of the hardware or implementation thereof, which is not affected by the algorithm itself. So we can happily simplify our job by just getting rid of all those pesky constants!

[T(n) = n^{2} + n]

Wow, much nicer! But guess what: it gets even simpler. Since, for large enough inputs, the contribution of the lower-order term (n) makes virtually no difference to the output number, we can happily drop that too:

[T(n) = n^{2}]

And voilá! Unfortunately, we’ve boiled this timing function down so far and stripped so much from it that we can’t really say that (T(n)) is exactly (n^{2}), just that (in the worst case) it follows a similar curve. More precisely, we have virtually guaranteed that, for large enough inputs, it can never be bigger than some constant (c) times (n^{2}). This is the crux of asymptotic notation – specifically what is referred to as “Big-O notation”. As such, when we say that:

[T(n) = O(n^{2})]

What we mean is that there are some constants (c) and (a), such that for all (n) where (0 le a < n), we know that (T(n) le cn^{2}).

It should also be pointed out that the notation’s use of the “equals sign” is a little unusual – we’re not saying that (T(n)) is equal to (O(n^{2})), but that it is of equal or lesser order to (n^{2}). This might be a bit of a trick to wrap your head around at first (it certainly was to me). If I’d have written the notation myself, I’d have tried to use some symbol that didn’t already carry all the connotations and denotations the “equals sign” itself does; but c’est la vie – this is the way it’s done. Another way (in fact, the proper way) to think of it is to think of (O(n^{2})) being some set of functions that follow the above definition, and for the notation

[T(n) = O(n^{2})]

to in fact mean

[T(n) in O(n^{2})]

i.e. that (T(n)) is an element of the set (O(n^{2})).

OK, so we’ve been able to put an upper bound on some hypothetical order of our function (T(n)), but what does that really tell us? Not a whole lot, in isolation. But it really comes into play when you consider other algorithms, such as, say Merge Sort, which is bounded on top not by (O(n^{2})), but by (O(nlog_{2}n))! Graph those two functions and here’s what you get ((n^{2}) is in black, (nlog_{2}n) is in red):

This is a bit of an oversimplification, but sufficient to demonstrate the idea – notice that very quickly, (n^{2}) begins to overtake (nlog_{2}n), and continues to do so, the gap getting ever wider as n gets ever bigger; and just like in golf, the lower score is the one you want.

So, in what I hope was nutshell-ish if not perfectly so, that’s the basics of asymptotic notation! There are other, related notations like “Big Theta” (Theta(g(n))), “Big Omega” (Omega(g(n))), and the lower-case versions of omega and o, but I’ll leave those to you to explore.

Finally, as a disclaimer, I have tried to make the math herein as simple as possible for the purposes of the demonstration, and I could easily have borked something up terribly (I’m still getting the hang of LaTeX). If you spot an error, comment and I’ll see that it’s corrected. Thanks!

The judges would then review your work and score it based on code (cleanliness, semantics, and validation); user experience (respect for design, good choice points, interactions); and support (modern browsers, legacy browsers, size of project, resource optimization).  In the judges hands rests the responsibility of deciding one grand prize winner, 2 second place winners, 2 third place winners, and 20 runners-up.

A few Centresourcers were up to the challenge, here is what they had to say about the experience:

Mike Calhoun

The big thing that jumped out at me with this design was how EVERYTHING had a textured background associated with it. After that initial shock, my attention turned to points that seemed like they could have some kind of user interaction. There were none specified by the designer and the rules had specified that it was left to the coder to decide what (if any) they would like.  The obstacles section was an obvious choice for some kind of hover/transition.  The count down clock and form area also seemed like something that would have an room to explore with whatever I came up with while creating the markup. After a closer look, a few other smaller nuances caught my eye such as the small transparent border at the end and beginning of each section, the text shadows and many of the headings, or (again) the textured background.  In the end, I made a conscious decision to try and keep this as small as possible in terms of the file size and sacrifice complete compatibility for items like the above nuances in legacy browsers.  Although this probably hurt me in terms of scoring, I thought it would be more beneficial to learn newer practices for HTML5 and CSS3 versus supporting Internet Explorer 6 (which honestly has not been something I’ve thought about for a few years).  The trade off worked out well for modern browsers as everything looked pretty close to the design and I was able to use lots of CSS3 properties to accomplish the gradient background effects (rgba transparent backgrounds with a gradient image), font face properties for all the non standard fonts (allowed for the ticking clock), and extensive use of the jQuery animate property for my transition effect on the prizes section. In all, this was a  great experience that should pay off in the long run for applying new process to future work.

Travis Roberts

Mike went over the different sections/elements of the design, so I’ll talk about some of the tricks I used to accomplish the design while still keeping file sizes nice and small.

First, I exported all of my images as transparent GIFs instead of PNGs. The judging gives points for compatibility with older browsers, and everyone’s favorite browser to hate, Internet Explorer 6, doesn’t support transparent PNGs. The image quality of the exported assets were comparable as GIFs, the file sizes were much smaller, and they work with IE6 without having to do any weird hacks. By using GIFs, the total size for all image assets clocked in around 868KB.

Second, I used a CSS3 library (Animate by Daniel Eden) to accomplish all of the effects/transitions. This may seem counterintuitive to my previous paragraph about older browser compatibility. My thought was that effects/transitions are progressive enhancements. The site will still work fine without them, but they add a little polish to browsers that understand them. Because I used the CSS3 library for my effects, the only external javascript file I included was jQuery. This allowed my total project size to be relatively small (~1.1MB zipped).

My entry: http://cssoff.csclientsite.com/troberts/

I started out programming Drupal which endeared it to me because it was my first job, I understood it, and my employer thought highly enough of my skills to pay me. What I needed to better understand was that Drupal was not the only game in town. When presented with a new problem one must always consider what the problem looks to solve and what best accomplishes that solution. For me, I was confronted with a project that needed a pretty extensive custom database that, as hard as I tried, I could not get to work well with Drupal. After extensive research I (begrudgingly) decided that Ruby on Rails was my best option. This reflects another fact of life in web development: things advance very quickly (and usually for the better). When I started my first job, Rails was still in version 1.x with syntax that was not immediately understandable to me and was lacking in the documentation or as big a community as PHP and Drupal. By the time I came back to Rails, much had changed. Rails was older, the documentation was great, and it made complete sense for this problem. In the end, the only hurdle to overcome were my preconceived notions about frameworks and how I understood them to work. I had to consider that something had gotten better, and realize the goal wasn’t to build a site in Drupal, but to build a site that thoughtfully considered the clients’ needs and best addressed the goal of the project.

Much has been said about what technology agnosticism means or if it is even something at all. For me, it means rationally and carefully thinking of the problem and how to best solve it, where best does not mean “something with which I’m most comfortable”. This is true in all facets, be it language, framework, Drupal module, Ruby gem, or Rails plugin. We can use that with which we are most comfortable to start with, but from that point find other tools which improve our skills and improve our process. As Marshal McLuhan, said in his book The Medium is The Message, “we shape our tools and thereafter our tools shape us.”