You can see them by clicking the links below:

Australian Mines
Ramelius Resources
BatteryLimits

The Koans walk you along the path to enlightenment in order to learn Ruby. The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries.

By manipulating and building upon Ruby’s TestUnit framework, the EdgeCase developers have created a step-by-step process for teaching Ruby through the practice of “Red, Green, Refactor.” They’ve added some simple game mechanics too, by showing your systematic progression through the 270+ challenges (puzzles). Reaching enlightenment results in a pretty ASCII graphic, and a legitimate sense of achievement.

Before you start with the koans though you’ll need a working Ruby installation. I recommend you take a look at the excellent rvm project, which will allow you to install multiple rubies (1.8.7 and 1.9.2 for example, alongside each other) and multiple gemsets in your home directory. Former Frontiersmen and 2011 Ruby Hero Award winner Darcy Laycock was heavily involved in this project as part of the 2010 Ruby Summer of Code, so we really like rvm at TFG.

The GitHub repository even includes a handy Keynote presentation, which I used as the basis for my talk about Ruby Koans at last week’s Ruby on Rails Oceania Perth meetup.

Lastly, if you’d like to have a play with the koans before diving in too deep, they’re available online through your web browser at Ruby Koans Online. This is a no-risk way of trying out Ruby (hint: team them up with why’s Try Ruby project) in your browser.

Is this you?

You understand the difference between websites and web applications, and you want to write apps that matter for people that care about them.

You’ll have a track record of working on completed projects, and if you’re a Development Manager, you’ll have delivered some of these projects personally. You’ll have a few years commercial experience, probably working as part of a team doing solid but under-appreciated work. You will have experience with Mac, Linux or UNIX, but it might not be your daily environment. Similarly you will have an opinion about vi vs. Emacs or Python vs. Ruby, but you’ll understand that they’re just opinions.

You’ll care about your tools and will take real, genuine pride in the quality of the code you create. You won’t consider automated testing and continuous integration as optional components of a project, and will appreciate automated deployment procedures too. Learning new programming languages and getting more out of the languages you already know will excite you. Efficiency will be important too, and you’ll be looking for ways to automate your workflow and push the repetition off to a script.

You’ll be confident in your programming ability, regardless of the language you prefer, yet humble enough to seek guidance when needed. You’ll know how JavaScript can be used to enhance the web, and will have demonstrated experience with a leading JavaScript library. You might even care about SASS and HAML, if you’re really cool.

Using the right tools is important and we realise that. We don’t have a parent company dictating how we do things or what our “standard operating environment” is – you’ll get to make those decisions with us. We all use MacBook Pros for development, but you might want a new iMac, for example. You’ll keep up to date with current trends and care about using modern techniques and practices, as well as tools and technologies.

What we give you

• Variable salary, dependent on position (Starting at $63,000 on probation)
• 9% superannuation (on top of salary)
• A MacBook Pro with SSD (yours to keep, replaced every two years) ~$3,500
• $1,000 travel allowance per year (parking, bike servicing, public transport)
• Internet and mobile allowance ($80 each per month)
• Current and relevant books, training, tools and gear
• Opportunities to work from home/flexi-time
• Pay reviews every 6 months with no ceiling on earning potential
• Freedom to grow your role with our organisation

What you give us

• Agreed units of production (standard working week)
• Your creative genius and passion

How to apply

Send a short email to jobs@thefrontiergroup.com.au and reference your Github and Stack Overflow accounts, along with any Open Source projects you’re involved with. Include a resume if it’s three pages or less.

*International applicants are also welcome

Taking into consideration the needs of our customer base, we decided to integrate e-commerce facilities into our existing CMS platform. This has the immediate appeal that our customers do not need to learn yet a second content management platform. For new customers it’s great that they can now build a website with us and immediately sell online using our pre-built systems.

If you’re looking for a way to sell your products online, enquire about Madison Shop with your new website.

Why Choose Madison?

• Take control of your entire website and online store with a simple content, product & sales management system.
• Give your customers the shopping experience they need with a custom template created by our design team.
• With support for most Australian (and international) banks as well as PayPal you can collect payments right away.

If you’re thinking of visiting either the Mt Lawley or Joondalup campuses on the day, check it out!

Firstly, a congratulations to our very own Darcy Laycock for winning a Ruby Hero award. The Ruby Hero awards are put in place to recognise people that have gone above and beyond in the Ruby community.

We’ve rolled out our new Frontier Group blog design, and would love to hear what you think of it in the comments below. We’ve also added a Featured Posts section in the sidebar, so you can see what other visitors (and hopefully you) are interested in too.

We’ve been heavily featured in a range of Podcasts recently, such as Ruby5 and The Ruby Show. Also we’ve been featured in prominent Ruby and Rails websites such as Ruby Weekly and Ruby Rogues.

We’d love you to keep visiting. Sign up to receive our newsletter using the form to the right, or stop back here from time to time. Don’t forget to check out the rest of our site and see what we’ve been working on.

I had some conditional logic I needed to test that was based on the current Rails environment. Basically something like:

if Rails.env.production?
# Do something
Elsif Rails.env.staging?
# Do something else
End

I needed to stub out the Rails.env call. I had a quick Google around but I couldn’t really find a way of doing this I was happy with.

The solution

I whipped up this function that allows you to set the Rails environment to whatever you want:

Can’t see this Gist? View it on Github!

Put the above function in your spec file or your spec_helper.rb. The function can be called as such:

Can’t see this Gist? View it on Github!

How does this work?

The Rails.env function looks like this:

Can’t see this Gist? View it on Github!

So all you’re doing is setting the cached instance variable to the environment you want.

Follow Up (June 20, 2011)

So two distinct issue have come up as a result of the above content.

Firstly, there was no ensure meaning that if an exception was raised in the middle of the stub then the environment would be changed for the remaining tests. This was a stupid mistake but, it happens, so I’ve updated the gist and my code.

Secondly, the issue of checking environment in code. The solution for this would be to have a constant in each env file that defines whatever it is you are using the env check for. So in the example I was working with each env file would have a EMAIL_TARGET constant.

You still need to test this, so the stub provided is still useful in this regard.

The only problem I encountered is that including Compass in the previously detailed way does not include any of the Sass Extensions. They’re written in Ruby, so just setting a SASS load path isn’t sufficient.

There’s a GitHub issue on the the Compass project tracking Rails 3.1 support. The latest and greatest suggestion is to use the following in your Gemfile:

Can’t see this Gist? View it on Github!

It works beautifully! All the extension functions work too. Thanks, @chriseppstein!

If you’re like me, you’re probably already playing around with the Rails 3.1 release candidate. If not, go take a peek at why you should be excited. (Thanks Ryan Bates!) If so, like me, you’re probably also wanting to play with all your old friends, like Compass.

Compass, by default, manages SASS for you. It gives you a place to put it, app/stylesheets, and takes care of bundling everything together. The new Rails 3.1 asset pipeline does this all for you using Sprockets instead, and does it nice and cleanly in a consistent manner with CoffeeScript and whatever else you might eventually integrate.

The problem is, I don’t want Compass managing my SASS. I like love the asset pipeline. But by default, from the asset pipeline I can’t use Compass. It doesn’t know what or where it is. So, I’ve added this to my new rails 3.1 projects:

Can’t see this Gist? View it on Github!

I’m also a heathen and like SASS, not SCSS, and it took me a minute to realise that it’s just as easy to use. Instead of mystyle.css.scss, name your stylesheet mystyle.css.sass. To make rails do this by default when you’re generating controllers et al, add this into your config/application.rb‘s config section:

Can’t see this Gist? View it on Github!

You can even rename the default application.css to application.css.sass and all the sprockets require_* machinery still works. Make sure you change the /* ... */ comments to // comments.

Beauty!

I thought it was an interesting problem, so here’s the answer I prepared:

You can overwrite or set Rails’ singularizations and pluralizations (properly called inflections) in config/initializers/inflections.rb

For example:

Can’t see this Gist? View it on Github!

As you can see below, Rails now understands how to count “faxes” correctly. One fax, two faxes, three faxes, and so on. You can test that from within the Rails console:

Can’t see this Gist? View it on Github!