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. 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
• 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

FlyRight is a mobile app (with accompanying web site) designed to use the power of real-time services to help improve airline travel, allowing you to be heard by the airlines when you need to be: on the spot.

We want to help make travelling a smoother and more enjoyable experience by giving you power when you need it. If you want to be heard, FlyRight is for you.

We’ll have more updates soon so for now, register your interest at FlyRight to hear all about the launch. You can also keep up to date on FlyRight’s Twitter and Facebook page.

FlyRight is a joint venture between TFG and Resonate Social

Check out the latest writeup at Betakit

Synaptor is changing the way SMEs in hazardous industries ensure the safety of their people and the environment with innovative mobile and web apps. We’re happy to have been involved in a project for a local company that is going to improve health and safety outcomes in hazardous industries.

We have put together a case study (Synaptor case study) to showcase the products, but here’s a sneak peek below:

Visit the Synaptor website to check out the project, or try out the mobile apps (iPhone/iPad) in the App Store (Observations & Maps)

There have been many updates in that time, and MailCatcher has picked up a bit of a following too. It’s still a great tool, so if you’re a developer you should check it out.

Here’s some feedback from around the web:

• “Ruby Mailcatcher should be deployed in every local development environment, regardless of whether you’re using Ruby.” – @brightball (link)
• “Learn about one of @srbiv’s favorite gems – http://mailcatcher.me our latest blog post:” – @highgroove (link)
• “MailCatcher is one of the better email testing gems I’ve seen.” – @hkarthik (link)

The latest version is 0.5.5 and can be accessed at MailCatcher.me or Github

A sprint is the basic unit of development in Agile. Sprints tend to last between one week and one month and are a “timeboxed” development effort of a constant length.

Our sprint planning session is broken down as follows:

• Product owner – prioritise and explain highest priority items in the product backlog (we use Pivotal Tracker). The team can ask questions at this point.
• Product owner – set a sprint goal (what are we achieving this sprint).
• Team – select Pivotal Tracker stories you can commit to, to attain that goal.
• Team – demonstrate a solution to each story in the sprint and ensure no outstanding questions.

Our Friday afternoon review session:

• Product Owner and Team  - demo all completed stories.
• Team – Review estimates from the sprint and note down how you went and how you can improve (if target not met).
• Team – Review points missed from the sprint and why, and how you can improve on that for next sprint.

If you’re running sprints in your organisation do you do things a little differently? Drop us a line in the comments.

You can see them by clicking the links below:

Australian Mines
Ramelius Resources
BatteryLimits

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.

You’re using Capybara, right?

It’s an acceptance / integration test framework for Ruby that superseded Webrat and makes it easy to automatically interact with Web applications but at the user level. It’s now the de facto way to do request / integration / acceptance testing (seriously, it gets called any or all of these) in Rails 3.

Capybara supports using different ‘drivers’ to run the scenarios you specify and by default it’ll use Rack::Test or Selenium (which uses Firefox’s Gecko engine). capybara-webkit is a library by the guys at Thoughtbot that gives Capybara a WebKit-powered driver using the WebKit implementation in Qt, a popular cross-platform development toolkit.

Why?

Why get WebKit involved with your integration tests at all? Perhaps your userbase is primarily made up of Safari and Chrome users (both WebKit-powered browsers) and you want to focus on them. Or perhaps you’re thorough and want to ensure the JavaScript on your pages works fine with your tests in a WebKit scenario too.

Installation

Here’s the bad news. You need Qt installed in order to install capybara-webkit. If you’re on OS X, grab it from here (pick the Cocoa: Mac binary package – the 206MB version). You can install via homebrew too (using brew install qt), but Thoughtbot says it takes forever (well, almost).

For other platforms, check out Qt’s Downloads page.
If you’re on CentOS, in particular, check this article.

Once you’ve installed the Qt toolkit, add this to your app’s Gemfile:

gem 'capybara-webkit'

Then run bundle and you’re off to the races.

Usage

Once everything’s installed, you can set Capybara’s JavaScript driver to use Webkit by default, by adding this to your normal Capybara config options (or if you have none, in spec/spec_helper.rb in most Rails 3 cases):

Capybara.javascript_driver = :webkit

Then, if you’re using Cucumber you can add the following tag to the header of your scenario to trigger JavaScript usage specifically (it’s not done by default):

@javascript

In regular RSpec code, you can do something like this:

feature "The signup page" do
scenario "should load", :js => true do
visit new_user_registration_path
page.should have_selector("form.user_new")
end
end

You could also use the :driver option to specify :webkit if you want to choose the driver on a per scenario / describe basis. The same applies to @webkit in Cucumber.

If you’re on OS X, when you first run tests using capybara-webkit the OS X firewall might go a little crazy since it works by connecting over a socket. Just approve it and you’re on your way.

You may also have issues if you’re using transaction fixtures. If so, read the “Transactional Fixtures” section of the Capybara README.

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