Len Garvey

Framed by Agios Georgios - Kefalonia

As a technologist I've had an unloved, underutilised website for years. Since it was time to rebuild, I figured it was the perfect time to learn some "new" web technologies.

I had a few objectives in mind:

1. My previous site was built off a fairly obscure static site generator called "toto"; I could have started a wordpress site, but I wanted to try something new.
2. I wanted to play around with this vibe coding thing.
3. In the past I've hosted on a servie like Github Pages, and wanted to try something else.

Ultimately I learned a bunch, but possibly should have just used wordpress or ghost to achieve a similar outcome just as quickly.

On Friday the 17th of October, Apple released OSX Yosemite. Being a bit of an Apple fanboy I immediately set about upgrading my main system (which happens to be a Hackintosh). This is a post mostly to remind myself about how I went about it and some of the potentially interesting things I do with my setup.

Not Yosemite - It's Kicking Horse!

About chruby

chruby is a set of very minimal shell scripts which change the current ruby. It replaces rbenv, rvm and has some advantages over both:

1. It doesn't do anything with cd
2. No shims (no more rbenv rehash)
3. Totally minimalist. It's 97 lines of shell script.

In this blog post I'm going to present a few things. Most of all I'm going to demonstrate how I would implement nice, structured front-end code in an already existing traditional Rails application. I'm going to do this using Backbone but it's probably unlike how you may have seen Backbone used before. Finally I'm also going to present the technique I use to integrate this in with your Rails application. Importantly I think that we should be adopting sensibile application defaults in addition to the defaults that Rails provides us. By adopting our own per-application defaults we can avoid writing lots of code.

The first (and hopefully annual) RubyConf AU was held in Melbourne in late February and as the title "suggests" it was pretty awesome. 380 Ruby and Rails geeks descended upon the Jasper Hotel for 2 days packed full of top quality talks, by amazing speakers. On the day preceeding the conference proper there was a full day of workshops.

Working in Tank Stream Labs (a great new co-working space here in Sydney) I come into contact with plenty of entrepreneurs looking to start their own Next Big Thing. Sometimes they have plenty of technology experience in the founding team, but often it's "business" people looking to start a great new technology-based startup. They're eager to learn anything about creating an online business. So rather than explaining everything to them in person, my hope is that I can direct them to here and give everyone a nice easy list of tech things you should have covered in your new startup.

These tips fall into a few key areas but here goes!

With the very recent and extremely serious Rails security vulnerability there have been more than a few people around asking how they update their Rails apps in order to be safe. Luckily Rails makes the update process relatively easy for any simple apps. If you have a large app with a large team, you probably shouldn't be getting basic advice from a blog on the internet anyway!

Over the past few years I've been setting goals for myself, and achieving most of them but it becomes easy to weasle out of some goals if they aren't written down. So in the spirit of @awws's post 2013 New Year's Resolutions I've decided to write up my goals for the year and post them publically.

Cucumber is a common tool used in many Rails applications to provide Acceptance/Integration testing. It uses a DSL called Gherkin which is a Business Readable DSL.

The idea is that you write the features of your application into Scenarios which are then executed by Cucumber. As a developer you also provide the steps to execute those Scenarios often using a tool like Capybara.

In the Rails community Cucumber can be slightly contraversial but I've come to believe that Cucumber is greatly misunderstood within the community.

Recently while working on Airtasker we got the following error from our (pretty extensive) Rspec test suite:

A tale of woe

You're building a great new app and the product manager/business person says:

Hey we're going to need to be able to delete things, and then restore things that get deleted

You say:

Sure no problem, I'll just include this gem that lets me soft delete and make a few code changes to my models

You've already made a huge mistake, the damage is done just take your hands off the keyboard.

I'm developing a joke application for a bit of fun and to fill out my github with some more public code. So I'm creating Blitter which lets me do some playing and development with mongodb and rails using mongoid.

Yesterday I attended 10gen's first Australian MongoDB conference. While most of the sessions were relatively basic it left me burning to continue working on some MongoDB projects I've been working with lately. The most informative session of the day was on sharding. I don't expect to have cause to use sharding in production any time soon but I have a better understanding of how the sharding key works to balance data across the cluster. Certain assumptions I had previously had were completely wrong so it's great to get those cleared up.

Amazing interview with Patrick McKenzie about how he went from being a Japanese salary-man to a web-entrepreneur.

One area of MongoDB which is difficult for some people (myself included) is the map/reduce functionality. It can be difficult to wrap your head around how it's meant to work after years and years of training ourselves to think in relational SQL.

In the last post I went through some stuff/problems with map/reduce. As a summary and to introduce a couple of other specific issues:

1. It's hard to understand.
2. It's not obvious how to do mapreduce in ruby.
3. It sucks writing javascript in your ruby app.
4. Blogs on the internet seem to recommend that you recalculate the map/reduce every time you need to access the data.

So I've written a gem called Reduceable for mongomapper (although hopefully mongoid support is coming soon) which should address all of the above problems.

I finally finished the Ruby Koans. It may sound really stupid but they are amazing for teaching you extra stuff you should probably know about ruby, stuff like inject, lamdas and blocks, message passing, overring method_missing and other really cool "tricks" that let you code Ruby better.

One of the things I've been doing lately is trying to figure out what to do with all the free time I have since I quit World of Warcraft. It's been amazing to go to the gym, work on learning new stuff and build this blog. One of the other things I've been doing is starting to actually follow through on some of the business ideas I've been collecting.

One of the biggest problems that everyone creating a database-backed web application is where to store uploaded files. Most people settle on having files stored in the filesystem with a table of paths pointing to where the files are stored. But I bet everyone who has had to code up something like that has wished there was a good way to store files in their database along with all their other data.

I've got a long background working with traditional, medium to large scale database backed systems. I've worked with many different types of databases, PostgreSQL, mysql, Firebird/Interbase, SQL Server (a few different versions). This means I really get the whole relational database thing.

So because of this it may be a surprise that I really, really hate working with databases. Well, that's not entirely true, I really hate working with databases on projects where the requirements aren't well defined. This includes all my own personal projects since I often start with an idea and move straight into the prototyping phase. Afterwards I end up being frustrated by how annoying it is to change anything in a database (migrations are awful) and usually end up giving up in frustration (and laziness) before I get anywhere.

Welcome to Bottled Goodness.

I intend on posting interesting software development stuff. One thing some of you may notice is that this blogging software doesn't look like anything you may have seen before. It isn't! I've coded this simple blog (which I've called sloggr) up over a few days using a few cool tools I've been playing with.