You can read the article on the Tennessean.

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):

Most typically, you'll see this used and referred to not as , which doesn't serve much purpose unless we know already what is, but rather in terms of a specific , say, :

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

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 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:

where is the algorithm function itself, and 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:

represents the "time" it takes to run algorithm on input . 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 function can be abstracted further as a function of , where is the size of the array to be sorted:

Since the value of will grow as 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 and some constant . 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. 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 - those lines will execute once for every unit of input. Still others are multiplied by - these lines are executed times for each input. Now, handily, we can figure out our overall formula by just adding all these things together:

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!

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

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 is exactly , 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 times . This is the crux of asymptotic notation - specifically what is referred to as "Big-O notation". As such, when we say that:

What we mean is that there are some constants and , such that for all where , we know that .

It should also be pointed out that the notation's use of the "equals sign" is a little unusual - we're not saying that is equal to , but that it is of equal or lesser order to . 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 being some set of functions that follow the above definition, and for the notation

to in fact mean

i.e. that is an element of the set .

OK, so we've been able to put an upper bound on some hypothetical order of our function , 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 , but by ! Graph those two functions and here's what you get ( is in black, is in red):

This is a bit of an oversimplification, but sufficient to demonstrate the idea - notice that very quickly, begins to overtake , 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" , "Big Omega" , 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.”

No planning, no documentation, no problem. That is the Agile development approach right? Well, I might be new to this Agile approach, but I would argue it's MORE. I am a Project Manager by heart, so NO planning and NO documentation is simply unacceptable. Sorry Dilbert. Seeing how Agile Development is a buzz lately, I figured I would approach this topic from a Strategist’s point of view.

So, what is this Agile Development thing?
Doing a quick search of Agile Development you will get several different definitions. Most all of them say its a hard term to define. The key words you will see are “evolve”, “collaboration”, “iterative” and “cross-functional teams.” However you want to define it, we love agile development because it provides us the freedom to make decisions as we go.

What is the process for Agile Development?
Well...Agile :) We start out with a charter, a mission statement for where we are going. This will be our flag ship document that everything is based on upfront. From there, we plan for the checkpoints to review progress and analyze results. With each milestone that comes it is expected that timelines will adjust. Tasks may be completed quicker, we may add more work to the task. Revisions come as needed, but always with purpose.

When taking on an Agile project I look to document the process. Documentation is the best way to track and show results. From a strategist point of view taking on an Agile Development project can be a bit intimidating. Since Strategists are ultimately responsible for scope, timeline and budget; Agile development may seem like herding cats. We need to defend decisions with documentation.

You can read the article on VentureBeat.

Angular.js + Rails: Part 2 from centresource interactive agency on Vimeo.

Part I of this video explores the problem and what we are looking for in a solution. Part II (coming soon) goes into detail on a particular solution using Rails 3.1 and Angular.js. Source code for the demo application is available from the Centresource Github account.

Angular.js + Rails: Part 1 from centresource interactive agency on Vimeo.

First, add heroku to the development group in the Gemfile and bundle install.

If this is a client site, you will want the client to own the
application, so we'll sign in as the client from the beginning (you
can also use "heroku sharing:transfer" to move an app to another user
later):


$ heroku auth:logout (only if you are already using heroku)
$ heroku auth:login
Enter your Heroku credentials.
Email: client.email@address.com
Password: client-password


Then create the production and staging apps:


$ heroku create --stack bamboo-mri-1.9.2 mysitename
$ heroku create --stack bamboo-mri-1.9.2 mysitename-staging


Then add yourself and anyone else on your team to the heroku apps:


$ heroku sharing:add your.email@address.com --app mysitename
$ heroku sharing:add your.email@address.com --app mysitename-staging
$ heroku sharing:add team.member@address.com --app mysitename
$ heroku sharing:add team.member@address.com --app mysitename-staging


Now you can sign out as the client and sign back into your own Heroku account:


$ heroku auth:logout
$ heroku auth:login
Enter your Heroku credentials.
Email: your.email@address.com
Password: your-password


Next, we need to update project_root/.git/config so that we can deploy
to the production and staging apps. Do this by copying the "heroku"
block to a new "staging" block and updating the url to the name of the
staging app. While you are at it, you might want to change "heroku" to
"production" so that it is consistent with "staging":


[remote "production"]
url = git@heroku.com:mysitename.git
fetch = +refs/heads/*:refs/remotes/heroku/*
[remote "staging"]
url = git@heroku.com:mysitename-staging.git
fetch = +refs/heads/*:refs/remotes/heroku/*


Now, you can push to staging and production separately:


$ git push staging master
$ git push production master


And to push a branch other than master (such as develop) to staging
for a beta reveal:


$ git push staging develop:master


Note that for any Heroku commands, you will need to specify the app:


$ heroku rake db:migrate --app mysitename-staging