The Economics of Buying a Coffee Every Day

Is buying a coffee every day as bad as all the finance books say?

   Days in 2016: 365
   Weekend Days: 104
Public Holidays:  13
--------------------
   Working Days: 248

Cost of a regular coffee $3.80 (AUD)

TOTAL
248 x $3.80 (AUD) = $942.40 (AUD)

OR

Assuming an $80,000 (AUD) a year salary, 1.67 % of your net income.

That’s a lot of money. But there’s another aspect of this to consider.

   Calories in reglar coffee: 168
Calories per pound of weight: 3500
         Pounds per Kilogram: 2.20462

248 x 168 = 41664 Calories

OR 

41664 / 3500 / 2.20462 = 5.34kg of weight gain.

Your habits are important

Being an awesome developer is all about being a genius. It’s the only way you can get a job at a cool company and it’s the only way you can build anything amazing.

Oh wait, no it’s not.

Here’s the thing. If you care enough to actually want to be a better developer, you’re already ahead of 99% of field. So now what? Get smarter? Start a project with the perfect blend of flavour of the month and pop culture that goes viral on github? You could do that or you could do something with a concrete return on investment…

Build good habits.

Building good habits is a great investment for a developer because it goes a long way to making what you do consistent, repeatable and valuable.  Building good habits takes those things we know we should be doing and makes them just, “the way”.  Let’s be honest, if you don’t make a habit out of something, it’s going to be dropped the second any pressure is applied.

Good habits I’m working on:

  • Smaller steps!  Whether it’s a new feature or refactoring legacy nonsense, taking smaller steps is great.
  • Making sure tests really are driving what I’m doing.  It’s so tempting to race off ahead, but it ends in tears every time.
  • Automate it.  Rake, powershell, whatever.  Just stop doing it manually.
  • Keep the excitement, keep the love.  There’s more to life than coding and it’s easy to burn out.  Mix it up, do other things.

What are you working on?

 

Single Responsibility Principle or Why Dogs Don’t Have Thumbs

The single responsibility principle (SRP) is one of the foundations of good object oriented design, taking pride of place as the “S” in SOLID.  It states that a class should have a single responsibility which should be encapsulated by that class and that the class’s interface (i.e. public methods) should be closely aligned with that responsibility.  Let’s look at an example.

class Dog
 def bark
   # woof
 end

 def fetch
   # woof woof!
 end

 def chew_on_the_furniture
   # om nom nom
 end
end

Our (albeit contrived) Dog class adheres to the single responsibility principle as all its operations relate directly to Dog stuff. Good dog! Now let’s give our dog one more ability.

class Dog
 def bark
   # woof
 end

 def fetch
   # woof woof!
 end

 def chew_on_the_furniture
   # om nom nom
 end

 def build_kennel
  # umm...
 end
end

Now our Dog can build its own kennel, great! Or is it? Well, no. There’s two problems with this. One is that, dogs don’t have thumbs and as such cannot use hand tools and as we all know a dog with thumbs is an abomination. The second is that it has two concerns, dog stuff and carpentry. There it is, the “and”. You can easily spot that something violates the single responsibility principle whenever you find yourself saying “and” about class functionality.

But, why do we care? Well, adhering to the single responsibility principle helps us keep out code more loosely coupled, conceptually clean and here’s the big one, IT MAKES CHANGE EASIER. Change is what’s hard about building software (that and naming things) and the single responsibility principle helps us make sure that when we do need to change something, it’s nicely encapsulated, decoupled and much less likely to break other stuff.

TLDR; You should follow the SRP because dogs don’t have thumbs.

Code smells – data clumps

Staying up to date with good practices in software can be difficult.  What was a good practice only a moment ago has fallen out of favour replaced by something leaner, more agile and completely incompatible with the way we used to do things.  While it’s great for all those guys who need ways to fill time between giving conference talks, we mere mortals have things like clients, bosses, legacy code and less than stellar teams to deal with.

So, I believe an easy win is in order.  Presenting, the data clump.

“Whenever two or three values are gathered together – turn them into a $%#$%^ object.”

— Martin Fowler

So, what is a data clump?
Whenever the same variables are being passed around together, it’s generally because they’re related. This sort of implicit relationship means something within our code, it represents a “thing”. The problem with this is, we want our code to be explicit, no muddied waters, no things that aren’t things but really are things. Data clumps make code harder to understand, harder to change and as a result, harder to live with.

Awesome, now what?
Work out what the implicit relationship between the variables is, throw them in a meaningful class and marvel at your cleaner, explicit code.

Easy win, you say?
You only need to do this once and you’ll see the benefits. Do it twice and suddenly it starts to jump off the screen at you. Keep doing it and it becomes a habit that makes you a way better developer.

Packaging cats

Is your enterprise software missing something?  Can’t take building another boring app at your 9-5?

Introducing SEESHAHP, the first Nuget package designed to translate from English to lolcat!  With this easy to use package you’re guaranteed to get promoted, marry the owners daughter and build the next super big social media thingy*.

What are you waiting for?  Push this to production today!

 

* or you’ll get fired. idk lol.

 

Installing RVM and Rails OS X Mountain Lion

Installing RVM on OS X Mountain Lion.

1. Install command line tools for XCode.

http://developer.apple.com

2. Install RVM with stable ruby.

curl -L https://get.rvm.io | bash -s stable --ruby

3. Source the RVM install.

source /Users/owenbyrne/.rvm/scripts/rvm

4. Verify your RVM install and view installed ruby versions.

rvm list

5. Set your default ruby version (2.0.0 in this case).

rvm --default 2.0.0

6. Install Rails

gem install rails --no-rdoc --no-ri

Done!

Ruby on Rails Font Awesome setup

Setting up font awesome with Ruby on Rails is very quick and gives you access to all the font awesome…awesomeness.

Step 1.

Copy the font awesome files to app/assets/font

Step 2.

Add the font directory to the assets path in application.rb

config.assets.paths << Rails.root.join("app", "assets", "fonts")

Step 3.

Modify font-awesome.css as follows

@font-face {
  font-family: 'FontAwesome';
  src: url(/assets/fontawesome-webfont.eot);
  src: url(/assets/fontawesome-webfont.eot?#iefix) format('embedded-opentype'), url(/assets/fontawesome-webfont.woff) format('woff'), url(/assets/fontawesome-webfont.ttf) format('truetype'), url(/assets/fontawesome-webfont.svg#FontAwesome) format('svg');
  font-weight: normal;
  font-style: normal;
}

Step 4.
Move font-awesome.css to your assets/stylesheets directory and restart the rails server.
Done!