Matthew Lang

It's a question I've been asking myself as I switch between different Rails applications for different clients. In my early days of working with Rails, I had a preferred selection of gems that I liked to use and that I stuck with for many Rails applications. After a few upgrade issues on a couple of applications I started to pay more attention to how I build applications with Rails. I questioned the gems that I was using and my testing practices. As I've gained more experience I've started to see that working closely to the Rails framework when building applications has some benefits that I previously overlooked.

What you're about to read isn't a silver bullet approach to building Rails applications. This is simply a guide to what I've find works for me.

Application Architecture

In the past most applications I worked on followed the old favourite of "fat model, skinny controller". Most applications tightly followed the MVC pattern and very few classes or objects were located outside of these three folders of the application. It does work, otherwise Rails wouldn't be as popular as it is, but following the MVC pattern did present one problem. Models became huge wells of code as they tried to contain the bulk of the application's code. Now I try to follow some best practices when coding but I don't strictly adhere to them, but you have to admit that a model with a 1000+ lines of code could probably be trimmed down a bit.

Since reading and watching a number of different ways in organising your Rails application, I've started to see the argument for extracting business logic into individual classes. You might be thinking of service objects or Hexagonal Rails when I say this. It's the same idea. I've started to keep classes that contain business logic in the app folder, alongside the rest of the application's objects. The reason for this is that I see the business logic as being part of the application, not a seperate layer or component of the application. I'm using Rails for my application, so I want to keep the business logic close to the rest of the application.

Gem Dependencies

Gems sure are handy. Just add to the Gemfile, install and your application has access to new functionality when it needs it. While adding gems is the easy way to add functionality to your application, you then have a dependency on that gem to stay maintained.

Before you even begin adding the gem to your Gemfile, ask yourself if it is truly necessary for your application?

In the past I would happily add a gem that I thought I needed, but now I take a different stance on it. If a gem provides just a small bit of functionality to the application, I take the time to spike a similar or better solution for the application on my own. The reason for this is that sometimes a gem won't do everything you need it too. If it can provide everything you need then great, but if it only provide most of your needs, could you add the complete functionality that you need by yourself?

Building this functionality on your own isn't always the best way to go, but if your application has specific requirements, then I say it's definitely worth looking at. Rolling your own solution to your application's requirements means that your solution could be a better fit for your application than anything else that's out there. It also means that with your own solution, you are responsible for keeping it maintained. Lastly, it keeps your Gemfile lean and the dependencies for your Rails application lean. I don't suggest you do this for everything, just the gems that you might question over their suitability for your application.

Testing

In the past I was a keen advocate of Cucumber and RSpec. That has changed over the last year. I'm finding that the testing tools that Rails provides are more than adequate for new Rails projects and sometimes better suited for smaller Rails projects.

Out of the box Rails provides Minitest through Ruby to write your tests and fixtures to organise the data you want to test against. Minitest is flexible in that you can write tests or specs depending on your preference, so I don't have any issues there. Minitest in a new Rails application is straightforward and it doesn't require any changes to your application's setup to get it working. Why even bother changing?

The real benefit I've seen though is in doing testing the Rails way is by using fixtures. They do require some initial effort to put together, but they're always there for subsequent tests runs and soon you'll start re-using fixtures for different tests and rarely have to touch them.

Rails is a database backed web application framework. Now I've seen the arguments for isolating the database from your tests, but for a framework that persists its data to the database, I think it's overkill to start stubbing out calls to the database and canning data using factories. This is why I like using fixtures. It's real data you're working with. A complete working set of test data.

Finally, an argument against using fixtures in the past was that tests took too long to run. I have to say that this is not a concern now. I have worked on a number of Rails projects using Minitest and fixtures and while their test and assertion counts run into the hundreds, I've yet to see a test suite take longer than 30 seconds. And even if your test suite is on the large side, it shouldn't be a major concern as you should have your tests automated to run as you edit your code by using something like Guard or Spork.

So What is The Rails Way?

Since I've made a few changes in how I build Rails applications, I'm definitely a more productive developer and I'm able to build new features with minimal fuss. The Rails way for me is working with the tools that Rails provides and building an application as close to the application's own models, controllers and views as you can. Simple patterns and designs are available to reduce complexity but aren't always necessary. I don't suggest you immediately think about re-writing your whole application to fit around these three suggestions, but bear them in mind for any future Rails projects that you have.

Marco Arment on what could be Google's biggest challenge yet.

Shallow social-shareable listicles and clickbait headlines have always been plentiful on the web, but it does seem clear that they’re getting much worse and more dominant recently.

Google is making the problem worse, but they’re not the root problem. In fact, the real problem is a pretty big problem for Google, too:

Everyone’s spending increasingly more consumption time dicking around in apps and snacking on bite-sized social content instead of browsing websites and searching Google.

— Google and blogs: "Shit" by Marco Arment

Does this explain why Google are going to show tweets in their search results?

Even before I started freelancing, I always got confused by the almost interchangeable career titles of freelancers and the jobs that were available to them. Contractor, consultant and freelancer. Are they specific to the type of work freelancers do?

When I started freelancing, I decided to market myself as a "Freelance Web Developer". I had thought about the different titles I could use but I paid more attention to the technology field rather than the type of work I would be doing. I stuck with the title of freelancer as I simply thought it best described who I was. This was almost right, I wanted to freelance but what I wanted to start work on was contract work.

Starting Out As A Contractor

To begin with I was keen to look for roles where I could gain a bit more experience working as part of a remote development team. I wanted to work in remote teams to see how they continue to progress with projects. In the past I worked in teams that shared the same physical space and therefore communication with other team members was easy. How does this affect remote teams?

I also wanted to gain more experience in my preferred choice of technology stack. I had a number of roles working with Ruby on Rails, but I was definitely far from being an expert on the framework. A few gigs working in different teams would quickly identify areas where I might be short on knowledge. Thankfully this wasn't a problem.

Armed with these two goals, I found out that contracting would be the best work for me. As a contractor I can market myself as a development resource to clients. They might be looking for that extra programmer needed to finish a project or they might need a developer with experience in a technology stack that they are lacking in. Whatever the reason, my primary role as a freelancer so far is as a contractor.

Long Term Focus As A Freelancer

I don't want to be a contractor forever though. In time I would like to gradually move across to being more than just another "butt in a seat".

Contracting is good because it means the decisions are largely removed from your hands. Your clients decide the work for you and you as the contractor fulfil your client's needs. While this type of work does pay the bills and keeps my career going, I don't believe that this should be my long term goal.

Doing the work is one thing, but advising the client in the way in which they can best achieve their aims is the work of the consultant. While I could market myself exclusively as a contractor, I would in fact like to be more than just another programmer in the team. I would like to be more of mix between contractor and consultant.

What's The Next Step?

This is where I believe the term freelancer applies to the type of business I want to have. I love programming, and being able to work with a client's team and help fill a gap is where I'm comfortable and productive. It shouldn't be my only selling point though. To do this, I'm going to need a web site that focuses on business and freelancing and nothing more. It's going to need material such as test cases and examples of work that back up my abilities as both a contractor and a consultant. I'll see what I can come up with.

Routine & Ritual. Get the critical stuff, the vital stuff, the oh-so-easily-neglected stuff embedded. Make it a ritual. Make it a routine. Make it a habit. Every other drink is a beaker of water. No 'if's, no 'but's.

— What's More Important Than Ever? 7 by Nicholas Bate

Read on for the remaining six nuggets of wisdom from NB.

It was a good weekend for the members of Elderslie's Junior Newton Shield squad. Coaching on the Saturday with the club pro followed by an opportunity to play on the course for all levels of members in the junior section on the Sunday. All those involved with this in the club should be commended. It's great to see kids of all ages being encouraged to play and compete.