☢ u2622.ca

Meteor tips, help and sometimes random things

My Principles for Software Development

| Comments

Here are some of the principles by which I try to develop software. This isn’t a hard-and-fast list, but rather a set of guidelines that I use. I don’t follow all of them every day, but I try to follow them as much as I can. This list is under constant review, extending and changing as I grow as a developer.

  • Don’t leave work unfinished - Work that is started but not finished is a liability. At best, it means a feature isn’t in production sooner than it could be (representing wasted opportunity). At worst, the feature will suffer from software rot, and may require substantial rewriting if left long enough.

  • Work on only one thing at a time - Mental context switching is expensive. Focus as much as possible until that item is done.

  • Teamwork - The team as a whole is more important than the individual. This means that you should write maintainable code, ask for help when you get stuck, and help out your colleagues when they need it.

  • Review pull requests thoroughly and in a timely manner - as part of teamwork and leaving work unfinished, review your colleagues’ work quickly. If they write a PR and it sits for a week, that is means it takes one week longer for that feature to make it into production.

  • Fix bugs first - Bugs should be fixed before anything else. They are easier to fix when fresh, and existing bugs represent potential bad experience for enduser. See the Pragmatic Programmers’ broken window theory.

  • Be aware of errors - Whenever an error or problem occurs, we must be notified of it. Otherwise, only users will experience it, and not all users report errors. Also if a bug is fixed before a user first notices, the bug doesn’t exist from their perspective. An app slowing down to unusable speeds is considered a bug.

  • Don’t live with pain - When something is frustrating, take the time to fix the problem for everyone. Automate common tasks. This makes life easier, and makes the software easier to work with. It’s not always possible given time contraints, but it’s worth it. This is how big things such as Rails or Meteor get built.

  • Produce high quality code - Take the time to do things correctly. Quality is worth it.

  • Be pragmatic (but balance ideals) - Striving for ideals is fantastic, but shipping usable code is the most important.

  • Don’t let email/requests go unanswered - Others have taken the time to ask something of you. Be courteous, and don’t make them wait.

  • Provide test coverage - Do this where possible. The value it provides is tremendous. Try to consider a feature to be complete when it has test coverage.

  • Keep learning - Always be trying to learn new things. This includes new ways to use existing tools, or new tools altogether. Tools range from programming languages, frameworks, paradigms, editors, to soft skills such as empathy and listening skills.

  • Blame problems not people - Don’t forget that code is written by humans, with real feelings. Focus on the problem itself; blaming the author is counterproductive.

  • Encourage, don’t discourage - Help others improve their code. Don’t put them down because they wrote code that you (subjectively) could be better. Yours could also always be better.

  • Be humble - Realise that you can learn from everyone out there, including those are just learning to write code, and even from those who don’t write code at all.

A good chunk of these have been taken from OK GROW!’s development process guide, which I’ve contributed to a bit.

A lot of these may seem like common sense, and I hope that they do. That’s a sign that you’ve got solid guidelines in place. But I’ve had some encounters with people who haven’t given such things any consideration, just like there are companies out there that still don’t use source code control.

What sort of guidelines do you use in your development process? Email me at rgould@u2622.ca or leave a comment below. I’d love to hear them!

5 Steps to Understanding Meteor Better by Improving Your JavaScript

| Comments

I don’t believe you need to be a JavaScript expert before diving into Meteor, but I highly recommend taking the time to learn advanced topics first. By levelling up your JavaScript, you will understand the concepts faster, and will feel less frustrated and confused. Even if you don’t stick with Meteor or do Meteor full time, the skills these books will teach you will help you in all aspects of development.

I recommend starting by watching a series of Douglas Crockford’s lectures on JavaScript, and then following it with Reginald Braithwaite’s Javascript Allongé.

  1. Watch Crockford’s The JavaScript Programming Language. Watch it even if you already have built some applications with JS already. It goes into the fundamentals in-depth, and will help cement the basics in your mind, which is essential when learning advanced topics.
  2. Watch Crockford’s Theory of the DOM. Watch it even if you think you know the DOM well. Again, establishing fundamentals makes learning advanced topics easier.
  3. Watch Crockford’s Advanced JavaScript. It covers some advanced topics sometimes unique to JavaScript, and common advanced patterns. If you’ve ever tried reading a JavaScript library and couldn’t even begin to comphrehend it, this lecture will help clear things up.
  4. Watch Crockford’s JavaScript: The Good Parts. It will help you pick out the best parts of the language to use, and the parts that you need to actively avoid.
  5. Read Reginald Braithwaite’s JavaScript Allongé. Reginald (aka ragnwald) covers advanced functional topics, and this will permanently change how you write your JavaScript, enabling you to write resuable code faster and with much higher confidence.

I recommend doing the above in that order. Allongé is more advanced and builds off of topics covered by Crockford. Each step will help bring your JavaScript game to the next level, with Crockford’s lessons establishing solid fundamentals, and Allongé teaching (in a very effective manner) the more advanced usages of functional programming with JS.

Note that I did all of the above (and worked through the exercises in Allongé) before I even touched Meteor, and for the most part, the only Meteor help I’ve needed has been the official Meteor docs. Having such a solid foundation of knowledge let me pick up Meteor with lightning speed, and all of those skills will stay with me when it comes time to learn another framework.

If you have trouble following Crockford’s lectures, then I recommend reading his print edition of JavaScript: The Good Parts instead. While you’re reading it, really work through the examples to make sure you’re understanding it as you go along.

Have you ever felt that your JavaScript skills were inadequate? Have you ever looked inside one of the libraries you use (jQuery perhaps?) and felt as though you didn’t understand JavaScript at all? I want to hear about it. Email me with your story (write as much or as little as you’d like).

Disadvantages of Using Meteor (Over Rails)

| Comments

You can save significant amounts of time by developing some web applications by using Meteor instead of Ruby on Rails, but it doesn’t come without drawbacks. Here are some of the ones that I’ve encountered: What are the disadvantages of using Meteor compared to Ruby on Rails?

Immature Environment: The biggest problem right now is that Meteor is new. Pretty much brand new, in the scope of web development. It’s not even version 1.0 yet, though it’s getting close. This means that it doesn’t have as many users, as many tutorials, as many books, as many screencasts. It can be hard if you run into a problem that no one else has run into yet, so you’ll need to be willing to dig into it a bit yourself. I’ve been there, and fortunately Meteor’s codebase is fairly cleanly written (especially compared to Rails and AngularJS, two other frameworks whose code I’ve read).

Not Widely Supported: Another consequence of being so new is that there aren’t as many hosting services available for Meteor apps yet. It is possible to deploy Meteor on Heroku, and in my experience it works well, though it feels very raw.

Nothing but JavaScript: You must run JavaScript (or Coffeescript) on the server side. This isn’t a big deal for me, but JS is definitely far from the first language I would choose to work with. The upside is that you can run the same code on the server and the browser, without worrying about having to cross-compile from another language.

Only MongoDB: As of now, the only supported database is MongoDB. They have plans to expand this in the future.

Rapidly Changing: The Meteor API is rapidly changing, so each new minor version may bring breaking changes. This is expected to lessen as it reaches 1.0.

Testing Frameworks: Testing frameworks haven’t been a high priority since the beginning, and the ones available so far have tended to be cumbersome and brittle. The community is working on solutions, but nothing stable has yet emerged, and the testing culture is nothing like the Ruby on Rails community’s.

While there are many disadvantages, I feel like the advantages heavily outweigh them (usually). But the list of advantages is for another post entirely!

What are some other disadvantages you can think of? Email me or leave a comment!

Implementing Web Hooks With Meteor

| Comments

It’s possible to add web hooks to your Meteor application by using iron-router.

Declare a server-side route in your Routes.map declaration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Router.map(function() {
  ... // Your other routes go here

  this.route('hook', {
    path: '/hook',
    where: 'server',
    action: function() {

      // Watch the Meteor log to see this output
      console.log("Hook called.");
      console.log("Headers: ", this.request.headers);
      console.log("Data: ", this.request.body);

      this.response.writeHead(200, {'Content-Type': 'text/html'});
      this.response.write("You wrote: " + this.request.body.message);
      this.response.write("\n");

      // `this.response.end` *must* be called, or else the connection is left open.
      this.response.end('Success!\n');
    }
  });

});

To test it out, issue this curl command from the command line:

1
curl -H "Content-Type: application/json" -d '{"message":"foo"}' http://localhost:3000/hook

The documentation for this.response and this.request are available on the node.js website: http://nodejs.org/api/http.html

I’ve created a sample Meteor application demonstrating this, which you can view at https://github.com/rgould/meteor-posthooks

Not clear enough? Send me an email at rgould@u2622.ca for some more help!

Icelandic Language Music Roundup

| Comments

While focusing heavily on learning Icelandic, I dug deeply looking for Icelandic-language music. There are surprisingly high amounts of Icelandic bands that sing exclusively in English. Here are my favourite songs with Icelandic lyrics:

Mammút - They play energetic rock music, bordering on post-punk sometimes. The first Icelandic language band I liked, and my favourite still. Here’s Svefnsýkt: Bónus: Rauðilækur

Q4U - Postpunk from the 80s, mostly in Icelandic. They’re still around. Here’s Sigurinn: Bónus: Snjóhvít

Samaris - Atmospheric minimal electro/triphop with clarinet. Very haunting. Here’s Góða Tungl: Bónus: Stofnar Falla

Nóra: Indie rock, ranging from upbeat and energetic to atmospheric and introspective. The more I listen, the more I like it. They sing entirely in Icelandic. Here’s Himinbrim: Bónus: Sjónskekkja

Lockerbie - Post-rock, but with a bit more pop/rock than usually characterised by Icelandic post-rock. Here’s Snjóljón:

Úlfur Úlfur - Hiphop with awesome backing percussion. They sing entirely in Icelandic. Here’s Út: Bónus: Ég er farinn

Pascal Pinon - D.I.Y., lo-fi, indie pop electronic. Many songs in Icelandic. Here’s Ekki Vanmeta: Bónus: Sandur

Sólstafir - Post-black metal, with elements of country and rock. They are amazing live. Their album Svartir Sandar is entirely in Icelandic and highly recommended. Here’s Fjara: Bónus: Svartir Sandar

There’s lots of music that I’ve discovered that I didn’t cover here, but I only wanted to showcase the music I liked the most. Feel free to leave other suggestions in the comments.

Screencast: Using Shell History to Create Aliases

| Comments

Contents:

  1. Introduction to aliases @ 0:00
  2. Analysing shell history to create relevant aliases @ 4:43

Download: mov 24MB, 8:26 (Recommended)

Watch (recommended in full screen and in HD):

Notes:

Make an alias:

1
2
alias l="ls -al"
alias glog="git log"

Add those to your ~/.aliasrc.

Modify ~/.zshrc or ~/.bashrc (works for both):

1
2
3
if [[ -r ~/.aliasrc ]]; then
  source ~/.aliasrc
fi

View shell history: history

View count of common commands:

1
2
history | awk '{ print $2 }' | sort | uniq -c | sort -n
history | awk '{ print $2,$3 }' | sort | uniq -c | sort -n

Use that output to create better aliases!

Here’s some of my favourite aliases:

1
2
3
4
5
6
7
8
9
10
11
12
13
alias ..='cd ..'
alias ...='cd ../..'
alias ....='cd ../../../'
alias .....='cd ../../../../'
alias be='bundle exec'
alias g=git
alias ga='git add'
alias gc='git commit -v'
alias gca='git commit -v -a'
alias gch='git checkout'
alias gl='git pull'
alias gst='git status'
alias l='ls -al'

Machinist and Association Validations

| Comments

While upgrading to Machinist 2, I had a hell of a time getting blueprints with associations to actually save.

The problem turned out to be that the code was using validates_presence_of :hometown_id, where hometown is the name of the association, and the solution is to use validates_presence_of :hometown, or the newer version: validates :hometown, presence: true.

If you have a given class:

1
2
3
4
5
class Viking < ActiveRecord::Base
  belongs_to :hometown

  validates_presence_of :hometown_id
end

and blueprints:

1
2
3
4
Viking.blueprint do
  name { "Heiðrek" }
  hometown
end

Then calling Viking.make will properly return an unsaved Viking object (with a Hometown object viking.hometown), but valid? will return false.

Calling Viking.make! will throw an exception: ActiveRecord::RecordInvalid: Validation failed: Hometown can't be blank

If you really want to keep using validates_presence_of :hometown_id, you can modify the blueprint like this:

1
2
3
4
Viking.blueprint do
  name { "Heiðrek" }
  hometown { Hometown.make! }
end

Then Viking.make! will succeed. Viking.make will also work, and will return an unsaved Viking object, but it will actually create and save the associated Hometown object, which negates part of the point of calling .make instead of .make! (make creates objects but does not save them to the database, giving quite a performance boost for test suites).

The proper solution is to adjust the validation in your model:

1
2
3
4
5
6
class Viking < ActiveRecord::Base
  belongs_to :hometown

  validates :hometown, presence: true
  validates_associated :hometown
end

The key is that we’ve changed validates_presence_of :hometown_id to validates :hometown, presence: true. The validation actually checks the association itself, not the presence of an id field (which is only ever set once the hometown is saved).

We’ve also added a validates_associated :hometown call, which will check hometown.valid? before saving, and if the hometown fails validation, then the viking object will as well.

See API docs about validations here:

Goðan Daginn!

| Comments

Goðan Daginn, Heimur!

I just set up this new octopress instance in roughly half an hour! Hooray!