Matthew Lang

Yesterday I was working on a new feature for a client when I ran into an issue. The ActiveRecord model I was working with had a number of constraints on the table that prevented me from creating a record. I removed the constraints from the table, as I decided that in this case they were unecessary. Unfortunately decisions like this aren't always as straight forward.

I tend to avoid using constraints when possible in my applications, especially when I am using Rails. I can rely on validations and associations to act as 'soft constraints' to my data and ensure that my data is valid. These are also backed up with tests for each model and its validations and associations to other models. This is by no means a perfect solution, but it has sufficed in the past.

Now, a lot of developers might think that constraints are not required as ActiveRecord provides all the necessary plumbing for validating and joining tables together with relationships. That's fair to say if your application is thoroughly tested and doesn't house critical information, but we all want to be good developers so really we should be using constraints where required.

In the past I've worked on a number of healthcare systems that required certain fields to be populated in specific tables. Domains that are directed by rules and regulations on what data you should persist are a great place to use database constraints. Enforcing the data integrity rules on your database reduces the risk for having missing information that could potentially land you in trouble. Domains such as healthcare, law and even education are all examples of domains where by database constraints could be needed.

Applications that also share their data are another good case for database constraints. While you do have validations and associations for your Rails application, can you make the same assumptions about other applications that can access your data? Using database constraints here can ensure that your data remains valid.

In Rails it's all too easy to assume your database is simply a place to hold data, but your database can provide extra validations and checks when needed. I tend to favour not using database constraints until a feature or bug requires that I absolutely need one in place. I find it's much easier to work with code that isn't restricted by countless constraints that have been placed on a table from the start merely because the developer at the time thought that field 'x' was a required field and should have a constraint on it.

It's been six months since I started working as a freelance web developer. In this time I worked harder than I've ever previously worked. And that's a great thing. I'm actually enjoying the work that I do. This wasn't always the case. As a seasoned cubicle worker and a developer in a number of small companies, adjusting to working independently was difficult, but the transition has been worth it. A couple of things have really stood out for me in the last six months.

I'm enjoying coding again

Now that I am using Ruby and Rails on a full-time basis, I've never enjoyed programming so much. Most of my time is spent working on traditional Rails applications. I practice behaviour driven development using Cucumber and RSpec for these applications. In the past I've had limited exposure to Cucumber and RSpec, but the last six months have really seen me gain the experience I needed to cement my knowledge on these tools.

With this new found love for coding, I'm also much more invested in staying as a freelance web developer for as long as possible. To do this, I've been re-reading books like The Passionate Programmer and other books aimed at the Ruby programming language.

I have flexibility

Working from home does require discipline, but there's also the added bonus of being more flexible. I still do a typical day from nine to five, but I've found that without a commute to do I can use that time for other things.

One added bonus is that I can walk my oldest son to school or in the better weather cycle to school with him. It's only a minor thing, but starting the day with a walk (or cycle) to clear your head is better than having to make a daily commute to a remote office.

I'll be making another freelance update in six months (hopefully) with a view to discussing my finances, goals for the next 12 months and looking at side income. Here's to another six months!

Keeping up with posts on a daily basis is becoming a little more work than I anticipated. Previously I would try to write a couple of blogs every couple of days and then maybe a couple at the weekend.

In the last two months though this plan have suffered. Scheduling time in during the day is quite difficult with the the day starting early with a school run and then I need to hit client work as soon as I get back home. At the end of the day it is time to get the kids their dinner, have a play with them and then get them ready for bath and bed. By the time that's done and everything is ready for the next day, it's nearly 9pm and the thought of sitting at the computer is just not that appealing.

I need a plan of sorts. Simply picking off ideas for writing every couple of days is becoming difficult. I have enough ideas, I just need a plan to get them written.

Here's what I'm thinking. I should schedule what I am going to publish in my calendar and then work towards writing the articles that are due to published in the coming week.

One benefit of this is that deciding what to write about is taken out of my hands at an early date. I'm planning on scheduling blog posts at least a month ahead. The second benefit is that I can start writing posts even if they are not due to be published for a week or two.

I'm tired of deciding what to write about not the actual writing itself. So I need to schedule ahead and take that decision out my hands at an early stage. Time will tell if this idea for a publishing calendar pays off or not.

... and Steven Pressfield knows it.

The person who is going to change is going to change anyway. She has no choice. She is impelled by inner necessity. While the person who is not going to change is not going to change no matter how many seminars or retreats she attends or how much money she pays to those who promise to help her make the change.

— How hard is it to turn pro? by Steven Pressfield

via PedalConsumption

Alex Kessinger has compiled all his blog posts on the future of feed readers into one handy little book. The full document is here but there's also downloads in the form of a PDF and a Kindle book.

It's great that Alex has done this as feed readers really are an underappreciated tool. I'm actually glad to see that Google's Reader platform being turned off. It's opened the market for more feed readers that each have their own thing to offer.

With Google Reader going soon, people have been looking for a replacement RSS Reader. Fortunately for me I decided look for an alternative a few weeks ago when I wanted to go Google free. I looked at a number of different options for an alternative RSS reader at the time, but Feedbin really stood out for me.

It's a paid product. Not free. That's important for me because I want to use the product in the long term. Supporting this product by paying money to use it is just common sense. Free products can come and go but investing your money in a product provides some sense of insurance that it will be around longer. This is by no means a guarantee that Feedbin will be around forever. An annual Feedbin subscription is just $20 per year.

As an RSS reader, Feedbin does everything you expect a reader to do. You can subscribe to feeds using the textbox at the top of the screen. Underneath this are three panes. The far left is your list of feeds or folders of feeds if you like to be organised.

The next pane is the items in that RSS feed or folder. You can navigate these easily with the mouse or with keyboard shortcuts.

Finally the far right pane is the current item you are viewing or the reading pane.

Keyboard shortcuts can be used to move about between feeds, folders and items. From what I remember most of the shortcuts are similar to Google Reader so those migrating from Google Reader should be able to pick up the new shortcuts quite fast. As an ex-Reader user, I find it easy to navigate about Feedbin.

Feedbin also has support for sharing to an extensive range of services. You can share items to many services like Instapaper, Pocket and Evernote. This is done through the use of URLs that many services provide. Feedbin provides tokens that can be used within these URLs so that you can include the entry title, url and feed name within the URL to the service you wish to share to. I love this feature as it simple to customize what you're sharing. Some people may not like that it's not truly integrated with other services and instead relies on just URLs to share to other services, but given the number of services Feedbin can share to, I can wait for better integration.

Finally there's iOS support. The Reeder app is the best way to view your Feedbin feeds on your iPhone. Unfortunately at the moment there is no Reeder support for Feedbin on the iPad or OSX, however Reeder development will resume at the start of July and hopefully we'll see more Reeder support coming.

It's an interesting time for RSS readers. Many people are turning to Feedly as a replacement for Google Reader, but I just didn't like the Feedly interface or the it's iOS applications. In the time that I have used Feedbin I've had no reason to complain about the service. Aside from the unread counts being a little out on some feeds Feedbin really is a great little RSS reader. I'm looking forward to seeing what the future holds for Feedbin.

Update: Shortly after this review was written, Feedbin was moved to much faster servers. Performance of Feedbin on the previous hardware wasn't much of an issue for me but I did read about others complaining of speed and response time. On the new setup though Feedbin is definitely faster than it was previously.

This is the hardcore hardtail of the big wheel world. I don't know if I'm convinced that bigger wheels are better for mountain biking, but I'd be prepared to give it a try with a frame like the Bigwig.

via Ragley Bikes

While going through my Dropbox, I came across a number of programming ebooks that I have yet to start reading. Shocking I know. I mean, who buys books and then doesn't read them?

At the time I thought the book was a necessary purchase but after buying it, I simply forgot that it was there. Over the months it seems I have built up quite a collection of unread programming ebooks.

I never had this problem with a book. You buy it, you read it. You read it because the book takes up physical space in your surroundings and therefore you are continually reminded that the book is there to be read. Most of the time I would place my book beside my bed. It's the one time of the day where I can get a quiet half hour to read. Every night the book is there as a reminder that the book needs to be read.

Wat about ebooks though? They're there somewhere in your room, you just have to look for them. And that's my problem with them. Out of sight, out of mind. There's no reminder in my space that I have a book to read. I have a Kindle yes, but there is at least eight books on there that I haven't read, but by looking at my Kindle from across the room, I just can't know that there is eight books on it that I have yet to read.

So what's the answer? Being accountable for the books you read and publish your reading list for others to see? Perhaps. Maybe people can give you a poke when you haven't updated the reading list for a while?

It's worth a try. I'll do anything to try and get my money's worth from my unread programming books.