I made the hard decision to leave reInteractive recently. It wasn't easy for many reasons but at the end I decided to take on a new challenge. I don't want to go without writing something about my time at reinteractive which has been really great.
During the last 18 months I have had a blast working with this team, reInteractive is a fantastic company with a lot of respect and care for their developers.
We're counting down the days until we can pack our bags and head to next year's RubyConf AU in Melbourne! With so many awesome talks lined up and social events on the cards, February could not come sooner.
We're even more excited to announce that we'll be sponsoring 3 major events on Saturday! As with our InstallFest and Development Hub events, we're sponsoring events that bring our Community together. Check them out below.
I have done a decent amount of technical talks during the last 6 years, nowadays I feel fairly comfortable doing them, but I haven't always felt like this. I know from experience that the prospect of talking in public can be daunting, especially when is your own content you will be talking about.
In this post I want to share the roadblocks that cross my mind when pondering the idea of doing a talk and the things that helped me to be a better speaker. Some of my most recurrent thoughts are:
Over the past year and a half, our InstallFest initiative has introduced more than 600 developers to Ruby on Rails. These developers have been able to move onto Development Hub, but we feel there is a gap. If you look at the job boards, there are a lot of opportunities for mid to senior level Rails developers, but a scarcity of junior level positions.
This presents a problem, how do we take these awesome beginning developers and build them into mid to senior level develops to grow our community? And how to do this efficiently?
We're super excited to be invited back to hear Founder of reinteractive Mikel Lindsaar speak at StartNest in Sydney.
So, you have an idea for an awesome new software product? That’s pretty exciting! But, before deciding on what you are going to build and spending a bunch of your time and money to get this going, it is a good idea to be sure that the market you are targeting wants the same thing as you think they do.
We're giving a year's subscription to Code School to one lucky winner!
Easy! Just fill out our quick survey on what you've been learning and where your challenges are to go into the draw.
During the previous post I looked at what feature flags are and why you'd want to use them. In this post I will explore how I've implemented them in the current web-application I'm working on. It's a very simple process which means there are no excuses not to use a feature flag in your application.
Feature flags are a tool which can be used by software developers to separate a feature from the rest of the code surrounding it. It's a very simple concept with some very powerful consequences.
First let's look at what a feature flag is:
At a recent Agile Sydney meetup, reinteractive’s Founder Mikel Lindsaar presented on “Bringing Agile to Enterprise”.
One of the points he highlighted was that one of the biggest focuses of modern Agile software development is “working software”.
You wouldn't expect to pay an electrician extra to fix the light switches that he has just installed upside down, why would you pay a software developer to fix bugs?
When being paid to develop software for other people, the issue of paying for bug fixes after development is finished* is often raised. The discussion usually goes something like this: "Thanks for developing the system, it's great! We've found a few bugs, can you please fix them? I don't think we should pay for the bug to be fixed because the job wasn't done properly in the first place". This blog post is an effort to help people understand why this is the wrong way to go.
