Most people who use Adobe products (Flash, Photoshop, etc..) should be familiar with the anchor point. It is best described as the point around which the image will rotate. My experience with anchor ponts comes mostly with Flash and using Cocos2d for game programming on the iPhone.

A classic example of using anchor points in development is animated a catapult arm. You would place the anchor point at the end of the arm so the arm stays attached at the bottom and rotates out.

In this example we would set the anchor point here:

The problem when working with CSS3 is that there is no anchor point property. To rotate an image in webkit for example we could do this:

However we can translate and rotate. The nice thing with css3 transforms is that they are applied in the order they are listed, so we can use translation and rotation in combination to accomplish the same effect as moving the anchor point. We simply move the image ny how far we want to move the anchor point (from the center), rotate the image, then move the image back. You can see the final result below.

Throw Back

Here's what the code looks like. One thing to keep in mind is that you have to do the same translation before the animation, but with 0 rotation starting, otherwise it will add the translation into the rotation to some interesting results.

.catapult {
  -webkit-transition: all 1s ease-in;
  -moz-transition: all 1s ease-in;
  -o-transition: all 1s ease-in;
  -webkit-transform: translateX(55px) rotate(0deg) translateX(-55px);
  -moz-transform: translateX(55px) rotate(0deg) translateX(-55px);
  -o-transform: translateX(55px) rotate(0deg) translateX(-55px);
}
.throw {
  -webkit-transform: translateX(55px) rotate(45deg) translateX(-55px);
  -moz-transform: translateX(55px) rotate(45deg) translateX(-55px);
  -o-transform: translateX(55px) rotate(45deg) translateX(-55px);
}

When we click on the throw button, we add the throw class and the animation begins. To go back, we remove the throw class and the css3 transforms handle animating. You can read more about the css3 animation/transitions here.

For anyone who was at the presentation tonight, here are my slides. Feel free to leave any feedback also.

I've seen lots of "Things I'm Thankful For" this year. So I figured I would give it a shot from a Web Developer perspective.

Languages

Ruby - A great language that lets me get things done. Ruby lets me write simple, easy to maintain code, that lets me get things done.

JavaScript - People have strong feelings towards JavaScript, and while I won't try to argue that its the best language ever made, I'm especially thankful that its the one that made it into the browser. Sometimes I think how different the web would be if Java or Visual Basic for example were the language of the browser. JavaScript's real benefit comes from its flexibility. By creating the right library, you can for the most part bend the language to your will. And now with Coffeescript, I can avoid the remaining syntax limitations.

Framework

Rails - Rails does the heavy lifting of web development for me. The standardized structure and plugin system means I'm rarely reinventing the wheel.

Plugin

Inherited Resources - Not so much removing the stub code, but more for making nested resources really simple to setup.

App

Color Schemer Studio - I use Color Schemer Studio to find colors for almost every site I make.

Web Service

Gmail - Its hard to remember what life was like before Gmail. Seeing the occasional spam in my spam folder brings me back to the days when all of those were in the inbox. I still think the interface is one of the best out there.

Features

Rails 3 Generators - I just love that if I install rspec, factory girl, and inherited resources that my generated scaffold comes out with specs, factories, and inherited controllers.

Editors

Textmate - Still my favorite. I can get around VIM, and read up on eMacs, but I just have to have a good looking, light weight editor. I also can't justify the slow weight of a heavy IDE written in Java. Textmate may lack a few features, but it is still the best in my mind.

Background

I've been doing profession Rails development for the past four years, but this year was my first RailsRumble. The experience of trying to build and launch an app in 48 hours is both extremely fun and extremely stressful at the same time. Our idea was to build out a service that made it easier to translate any site into multiple languages. We wanted to have a bit of JavaScript that you stuck on your page that added a "toolbar" in the bottom of your page, from which a user could switch the sites language, or "Enable Translation Mode" to begin providing their own translations for things. The sites admin could then approve the translations (or auto-approve) and then users could vote on the best translation. The highest voted translation would show up for a given paragraph when a user selected a language.

We knew going into it that this was a fairly ambitious project for 48 hours. The original plan called for there to be the JavaScript component and a proxy server component that you could point a subdomain at (es.agileproductions.com for example) and it would return a translated version of the url. The plan was to try make the proxy server expendable if we ran out of time. Looking back I think our mistake was not calling it early enough on the proxy server.

The Contest

We waited until there was only 6 hours left in the competition to stop working on the proxy server (which unfortunately was a good chunk of the way done by that point). In hindsight, we should have stop building features a lot earlier. We expected that the site wouldn't be perfectly polished, and were hoping to win based on a great set of features, but in the end we ran out of time while polishing and debugging.

Debugging was top priority, and it ended up taking much longer than we expected (especially on the front end JS, which I had been working on by myself).

The Mistake

As the deadline approached, I decided with an hour left that I should bundle all of my JavaScript files together for better distribution and faster loading on peoples sites. Previously, I had the main script loading in all of the other scripts. One thing that I failed to account for was that we were loading in jQuery (in non-conflict mode), then loading in a library that extended jQuery, but when all of the JS was packaged together, the extension to jQuery would try to load before jQuery had initialized. (I made sure everything loaded in the right order, but this was still a problem).

The real issue was that we didn't catch the bug because we were only testing it on sites that already had jquery loaded (not in non-conflict mode). So the final version we pushed out ended up not working in most cases.

Whatever Can Go Wrong Will Go Wrong

I suspect we would have caught the issue had we been able to do our last round of testing. However, when we had about 40 minutes left in the competition, my internet went down (for the first time in at least 6 months). I have fiber at my house and my ISP really is great, this was just terriable timing. So after talking with the guys at my ISP for about 20 minutes, we decided to all run over to a team mates house who lived about 10 minutes away. When we arrived, we have 10 minutes left in the contest. This wasn't enough time to test, so we quickly added a screenshot to the homepage and pushed what we had. It wasn't until hours later that I would realize the version we pushed was broken for use on most sites.

Reflections

Looking back though, we really had a ton of fun working on it. We all worked separately on different components and adhered to some simple API's we had made before the competition. There was a great amount of excitement saturday afternoon when the core features of translating and loading in translations was done. We all got finished with our respective parts at about the same time and things really seemed on track. We could also see that we had a useful product with a bit of the "wow effect."

During the building process, we discussed how great it was when you could just sit down and start building. A team of four really can accomplish quite a bit when starting from scratch, working with familiar tools, and breaking a project up into atomic units.

The Results

While we didn't make it to the finals (I'm guessing because of broken core functionality), we had a ton of fun building it and will definitely be doing it again next year. Some of us have also decided that we are going to finish up the product and launch it. (A bug fixed version is up now at http://www.crowdtranslator.com/

The Best Part

One other footnote, our designer Ben was working remotely, I think my favorite part of the process was pulling in his changes and all of the sudden everything looked way better. It was great to see well done CSS and everyone up here in Montana was thrilled with the final design.

ScreenCast

Lastly, here's a screencast feature walkthrough I made shortly after the contest.

Thin is my favorite application server, its fast, its light, and it doesn't require you tie into any particular front end server (unlike passenger, which has its own benefits) Recently I tried to launch a Rail3 project on a box with a few existing Rails2 applications. I was getting all sorts of complaints from rails and thin about gem dependencies. Finally I realized that the thin gem manually requires a specific version of rack (1.1.0) But rails 3 upgrades its rack version to 1.2.1. Needless to say this is quite a pain to work around. I ended up taking the simple way out and setting up RVM and running a separate gemset.

If you haven't already, check out the RVM page on capistrano setup, it makes everything a lot easier.