Meta Bates

For the last few years every project or company I’ve worked for has started the same way, by setting up Basecamp, Lighthouse and Hoptoad (or similar ones anyway). Why? Basecamp  - so we could share documents and todos. Lighthouse – so we could track our issues and bugs. Hoptoad – so we could track the errors our application was generating.

These are all very good applications and have served myself and my clients well, but they’ve suffered from several very big flaws. The first big flaw was the cost. You can easily drop $100 or more a month across these different services. But that wasn’t the biggest flaw or problem I’ve had with these services. The biggest problem was lack of integration.

So what do I mean by lack of integration? Well, when an error comes in I want to easily be able to create a new issue from it. When the issue gets resolved, so should the error. If the error reoccurs it should re-open automatically, and so should the issue. I want to be able to create an issue right from a document or be able to attach issues to a document. I should be able to follow the flow from document to issue to error and back again very easily. Unfortunately, these applications don’t give you that level of integration. They offer some level, but just not enough.

Well, my friends, welcome to the future. Welcome to FluxTracker.com. FluxTracker combines a great issue tracker, a project management system, and an error tracker all in one application. Now you can full integration without any configuration, oh, and you can do it at a fraction of the cost!

We know it isn’t easy to switch to a different application, that’s why we’ve made it easy for you. You can easily import your Lighthouse account. FluxTracker also allows you to easily use the Hoptoad Notifier plugin for your project by just setting a few configuration parameters.

So know you know, you’re life can be easier. And you now know how easy it is to get started! So what are you waiting for? Go and sign up for our Free plan and start living the dream.

In case you’ve been living in a cave this week you’ve probably heard that Ruby on Rails is going to be including both the CoffeeScript and SASS libraries, it will also make jQuery the default JavaScript framework, replacing the Prototype framework.

I would like to start by addressing my experiences with CoffeeScript. My opinion of it is of ambivalence. I’ve used it on a project, I’ve played with and in the end I’ve come out with the opinion of “it’s ok”. It didn’t blow me away, but at the same time I can see why so many people like. It offers some really cool features that I really wish JavaScript had and you can cut down on the amount of code you have to write. On the other hand the apps I tend to write don’t tend to be that JavaScript heavy that I really needed to reach out for something like CoffeeScript.

So, how do I feel about CoffeeScript being included with Rails? Well, I’ll get to that. Let’s go over some of the most common arguments I’ve heard from people this week about why they’re anti-CoffeeScript in Rails.

“It’s an abstraction layer of JavaScript! JavaScript isn’t that bad, why can’t you just write JavaScript?”

“It’s going to be a hinderance to newbies. It’ll be too much of a learning curve!”

Let’s start with that second point first, shall we? I agree, it does represent a new element that needs to be learned when coming to Rails. But here’s the pretty nifty thing about how it’s all implemented in Rails. In order to actually use CoffeeScript in Rails you have to create your files named foo.js.coffee if, however, you just name your file foo.js then, guess what? You will have to write plain old JavaScript! Seems like newbies, and those who don’t like CoffeeScript, can just keep writing plain old JavaScript without anything stopping them at all.

Now, let’s talk about the abstraction layer argument. Yes, CoffeeScript is an abstraction on top of JavaScript, but let’s take a look at a few other parts of the Rails stack and see how they hold up against this argument.

Here’s a fairly common Rails stack:

• ActiveRecord
• Haml
• jQuery
• RSpec

What do all those things have in common? Well, they’re all abstraction layers that sit on top of something else, don’t they? Let’s look at that list again?

• ActiveRecord – SQL (Structured Query Language)
• Haml – HTML
• jQuery – JavaScript, you could just as easily hand roll those AJAX calls in pure JavaScript.
• RSpec – Test/Unit

What I’ve found funny about the particular argument is that I’ve heard it MOST from those who use things like HAML, which is a DEFINITELY an abstraction layer that sits on top of HTML. See where I’m going with this one? Good, I don’t want to belabor the point.

So, finally, where do I stand on this whole thing? Well, I view like it Test/Unit and Prototype. Those are both the current standard (although jQuery will replace Prototype in 3.1) and I don’t like or use either of them. Instead I configure Rails to use jQuery and RSpec. I don’t like Haml, but those that do simply replace ERB with Haml and they move on with their day. So my take is this, it’s there, it’s included. Use it if you like, or don’t. Is it really that big a deal? No, it really isn’t. If Rails dropped ERB and went with Haml as the default, would I bitch and moan, probably a bit, but then I’d just install the Rails-ERB gem and move on with my day, just like I do with jQuery and RSpec today.

So sit back, relax, use the libraries that you want to use, Rails let’s you do that. Oh, while you’re relaxing why not try out CoffeeScript, who knows, you might just enjoy it. Or not.