Eric Wendelin - Blog Entries - The Rich Web Experience

Book Review: MooTools 1.2 Beginner’s Guide

Thursday, March 11, 2010

MooTools 1.2 Beginner's Guide cover I have liked the works of Jacob Gube of Six Revisions and Garrick Cheung of the MooTools Community Team, so when Packt Publishing wanted me to review their book, I accepted.

I hope authors, as well as readers, will gain some insights. Here is my review of MooTools 1.2 Beginner’s Guide.

Book Structure

The book basically takes you, step-by-step, through downloading the MooTools library parts and building simple examples with HTML, CSS, and, of course, MooTools. It seems to touch on many of major parts of MooTools: Core, DOM selection, Events, Ajax, and Fx. Finally, it introduces you to MooTools More and how to write your own MooTools plugins. it approaches everything with very simple, very “hands-on” examples. There are some deviations (like pop quizzes), but they are few.

The examples themselves generally introduce a topic, give an HTML/CSS template and then progressively fill in the MooTools bits.

The Good

You can tell that the authors are bloggers by their very informal writing style. They know how to use simple language so that their writing does not impede the learning ability of the reader. I was able to read the entire book in about 3 hours cover-to-cover, a testament to how easy-to-read it is.

This is a book that a real, never-coded-a-web-page-before dude(tte) could pick up and do something with immediately.

The Bad

It truly is a beginner’s guide, and having some sort of MooTools knowledge myself I was annoyed by the verboseness of the examples. There seemed to be a lot of times I was seeing a small code example stretched out to several pages of text.

I was slightly disappointed by the number of linguistic (spelling and grammar) mistakes throughout the book. These were obviously not cultural differences between the UK-based Packt and the US. I was always able to understand what the writer meant, but I kept getting hung up on the mistakes because that’s the kind of asshole I am ;)

I really missed a good reference or appendix section at the end where I could find links to more information about the parts of MooTools I was learning about. There was some stuff within the chapter texts, but not enough.

You should buy this book if…

… you are truly a beginning web developer. This book is a great introduction to web development with a core focus on MooTools. It seems to generally promote good web development practices in my opinion.

Conversely, this book is not great to use just for reference. If you want to lookup anything advanced, it’s not going to be your best bet.

MooTools 1.2 Beginner’s Guide »

Leaving Sun/Oracle

Thursday, February 25, 2010

I had a great 2-and-a-half year journey with Sun, but my time there is sadly at an end. I was very fortunate to have worked with some very, very smart people. We’ll certainly keep in touch.

I worked on some really cool internal (and therefore not shareable) projects in Java, Jython, and Web languages and platforms. They were generally fun, diverse and challenging.

On to Return Path!

I’ll now be joining a small, agile team at Return Path. We will make email safer, and (I hope) win the war over spam. Audacious yes. Impossible… I think not.

I wish all my Sun/Oracle counterparts well. Good luck!

Task-Oriented Comments

Those who pair program with me know that I’m an advocate of leaving comments like <code>// FIXME: Breaks layout on tablets</code> or <code># TODO: Extract to model</code>.
Little reminders of things I don’t want to forget before, say, pushing a new feature.

I have a non-trivial amount of tooling I use around these task-oriented comments, and I’ve been meaning to write about how I
use them. Here you go.

<h2>My Approach</h2>

Often while working on new features (and sometimes, bugs) I sketch out a plan of what I need to do in English with a collection
of comments. This helps me break the task into little pieces so I can make sure I don’t miss anything. It also has the benefit
of helping me discuss the general approach with my pair so they can consider better solutions.

Next, I distribute these comments to the places where I’m going to code the implementation (if possible); that way
they give the reader context so it’s easier to think about the pieces involved. I’ll write the implementation and tests,
adding comments as I think of them. I want to write these intermittent notes down quickly so I can forget about them
until I’m ready to address them.

Lastly, I like to write myself notes before taking long breaks or quitting for the day.
Comments like <code># TODO: Finish injecting response into view</code> help me to pick up right where I left off later.
No more awkward “Now what was I doing yesterday?” moments.

<h2>Properties of good TODO comments</h2>

This is not so hard, you just have to always write them as if someone else will read them.
Remember to make it specific. If it’s a bug, you might explain why, especially if someone else is going
to be fixing it. Perhaps you might briefly explain why something should be implemented a certain way.
Finally, don’t go overboard! If you can write the code in 30 seconds, why waste time telling yourself what to do.

<h2>Improving task-oriented comments with tools</h2>

You might be saying to yourself: “But the advantage of a real TODO list is that it’s in one place”. (OK maybe not, but go with me here, eh?)
— and you’d be right. That’s where our tools come in; the simplest of which is <a href="http://www.eriwen.com/tools/grep-is-a-beautiful-tool/">grep</a>.

<figure class='code'><figcaption></figcaption><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers">1
</pre></td><td class='code'><pre><code class='bash'>egrep -R "(TODO|FIXME)" *
</code></pre></td></tr></table></div></figure>

Editors like IntelliJ IDEA/RubyMine keep track of comments with keywords like this automatically. Just hit ⌘6 (Alt-6 on Windows/Linux)
and the aptly named TODO pane comes up. I actually like to add new patterns in IntelliJ’s TODO settings panel, to make FIXME comments stand out in red.
Sublime Text seems to have a handy plugin called <a href="https://github.com/robcowie/SublimeTODO">SublimeTODO</a>
that aggregates these keyword comments, as well. Leave a comment with other neat TODO-tracking tools.

We can also utilize <a href="http://git-scm.com/book/en/Customizing-Git-Git-Hooks">git hooks</a> to tell us anything we missed
so that we can either fix them before we push or add stories to our favorite agile task board. Here’s the git hook that
I use pre-commit:

<script src="https://gist.github.com/5193583.js"> </script>

All this does is print out any new <code>TODO</code> or <code>FIXME</code> comments. To use this git hook, just copy it to <code>.git/hooks/pre-commit</code>
in any repo (don’t forget to make it executable). It runs before every commit and you can prevent the commit by returning a
non-zero exit code. You can fork the <a href="https://gist.github.com/eriwen/5193583">gist here</a> for your own needs.

Finally, <a href="http://jenkins-ci.org/">Jenkins</a> has a plugin called <a href="https://wiki.jenkins-ci.org/display/JENKINS/Task+Scanner+Plugin">Task Scanner</a> that
lets you track comments matching certain patterns and give them priorities. I like to mark <code>FIXME</code> comments as high-priority and
<code>TODO</code> comments as medium or low priority. It’ll also provide reports and charts so you can keep track of your task-oriented
comments on a higher level.

Sometimes I don’t use this system if the task is small or I have a really good grasp of how to write the thing I want to write.
The point is to program deliberately. Cheers.
<div class="feedflare">
<a href="http://feeds.feedburner.com/~ff/EricWendelin?a=J1RDhvIbvwE:pazBLvy_2O4:cGdyc7Q-1BI"><img src="http://feeds.feedburner.com/~ff/EricWendelin?d=cGdyc7Q-1BI" border="0"></img></a> <a href="http://feeds.feedburner.com/~ff/EricWendelin?a=J1RDhvIbvwE:pazBLvy_2O4:gIN9vFwOqvQ"><img src="http://feeds.feedburner.com/~ff/EricWendelin?i=J1RDhvIbvwE:pazBLvy_2O4:gIN9vFwOqvQ" border="0"></img></a> <a href="http://feeds.feedburner.com/~ff/EricWendelin?a=J1RDhvIbvwE:pazBLvy_2O4:I9og5sOYxJI"><img src="http://feeds.feedburner.com/~ff/EricWendelin?d=I9og5sOYxJI" border="0"></img></a>
</div><img src="http://feeds.feedburner.com/~r/EricWendelin/~4/J1RDhvIbvwE" height="1" width="1"/>

Quick Tip: More Readable Conditionals in Ruby

When <a href="https://codeclimate.com/">Code Climate</a> and <a href="https://twitter.com/tsaleh">Tammer Saleh</a> from Thunderbolt Labs
teamed up to offer free code reviews at <a href="http://rubyconf.org/">RubyConf</a>,
I seized the opportunity to get feedback on my first Ruby gem – <a href="https://github.com/eriwen/gnip-rule">gnip-rule</a>).
A number of refactorings came out of that session, but one I found most interesting was an approach to making
conditionals more maintainable in languages like Ruby and CoffeeScript.

They say that the use of <a href="http://ghendry.net/refactor.html#dc">conditionals in Ruby is a code smell</a>.
Decisions about how your team approaches conditionals should be discussed then outlined in your project styleguide.

This is the refactoring I’m talking about – I have a bunch of different checks according to
<a href="http://support.gnip.com/customer/portal/articles/600659-powertrack-generic#Rules">Gnip’s PowerTrack API constraints</a> to
ensure that a PowerTrack rule follows the constraints.

<figure class='code'><figcaption>Old and Busted</figcaption><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers">1
2
3
4
5
6
7
8
9
10
11
12
13
</pre></td><td class='code'><pre><code class='ruby'>module GnipRule
 class Rule
 def valid?
 # So many ORs
 if contains_stop_word? || too_long? || contains_negated_or? || too_many_positive_terms? || contains_empty_source?
 return false
 end
 true
 end

 # def contains_stop_word?..end etc.
 end
end
</code></pre></td></tr></table></div></figure>

…And here is the same method, refactored. We turned each condition into an early <code>return</code> if the conditional expression is true:

<figure class='code'><figcaption>New Hotness</figcaption><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers">1
2
3
4
5
6
7
8
9
10
11
12
</pre></td><td class='code'><pre><code class='ruby'>module GnipRule
 class Rule
 def valid?
 return false if too_long?
 return false if too_many_positive_terms?
 return false if contains_stop_word?
 return false if contains_empty_source?
 return false if contains_negated_or?
 return true
 end
 end
end
</code></pre></td></tr></table></div></figure>

Some might cringe at seeing so many <code>return</code> statements, but I argue that it’s more maintainable this way because it’s
obvious to the reader what is being checked. If another check is added, it doesn’t hang off a long chain of <code>||</code>s (or
use a bunch of ugly <code>\</code>s to break lines).

Not only is this useful in Ruby, but CoffeeScript as well. Example:

<figure class='code'><figcaption>CoffeeScript Example</figcaption><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers">1
2
3
4
5
6
</pre></td><td class='code'><pre><code class='coffeescript'>stringify = (obj) ->
 return 'undefined' if obj is undefined
 return 'null' if obj is null
 return obj if (typeof obj is 'string' or Number.isFinite(obj))
 return "[#{obj.join(', ')}]" if obj instanceof Array
 return Object.prototype.toString.call(obj)
</code></pre></td></tr></table></div></figure>

Thank you again, <a href="https://twitter.com/tsaleh">Tammer</a>, for your very helpful advice.

What do you think of this formatting?
<div class="feedflare">
<a href="http://feeds.feedburner.com/~ff/EricWendelin?a=uQrTuIbL_Aw:jYXvLnLMXUU:cGdyc7Q-1BI"><img src="http://feeds.feedburner.com/~ff/EricWendelin?d=cGdyc7Q-1BI" border="0"></img></a> <a href="http://feeds.feedburner.com/~ff/EricWendelin?a=uQrTuIbL_Aw:jYXvLnLMXUU:gIN9vFwOqvQ"><img src="http://feeds.feedburner.com/~ff/EricWendelin?i=uQrTuIbL_Aw:jYXvLnLMXUU:gIN9vFwOqvQ" border="0"></img></a> <a href="http://feeds.feedburner.com/~ff/EricWendelin?a=uQrTuIbL_Aw:jYXvLnLMXUU:I9og5sOYxJI"><img src="http://feeds.feedburner.com/~ff/EricWendelin?d=I9og5sOYxJI" border="0"></img></a>
</div><img src="http://feeds.feedburner.com/~r/EricWendelin/~4/uQrTuIbL_Aw" height="1" width="1"/>

Effective bash shorthand

Let me tell you how to maximize your productivity on the Bourne Again SHell while minimizing your effort. bash has a ton of tricks and shortcuts that allow you to command it with little effort, and I intend to show you the features that help me day in and day out.

Today I’m going to explain the use of features like history, brace and file expansion, and other tricks by example and give you references for later.

Master your history

Those who forget history are doomed to repeat it. This is arguably one of the best productivity enhancing features of any shell.

You can check your history with the history command, which prints your last 500 commands (or so) by default. Alternatively, you can filter the list:

# Print last 10 entries
history 10

# searches history for cmd
history | grep cmd

Each entry has a number, which you can then execute with !<number>

Now suppose I want to copy a file to a directory and then change to that directory. The quick way to do that with history is:

cp myfile.txt my/directory/path
cd !$  # cd my/directory/path

or if I forget to run a command as super-user:

vi /etc/fstab  # oops!
sudo !!  # sudo vi /etc/fstab

to execute the last command starting with “mount”, since I don’t want to type it all out:

# Previously...
mount 192.168.0.100:/my/path/to/music /media/music

# Later...
!mount
# Repeats last mount command

Note that I often (but not always) prefer Ctrl-R, which will search history as you type. As an added bonus you can view the command before executing it.

Other examples:

eric@sawyer:~$ echo foo -a bar baz
foo -a bar baz
eric@sawyer:~$ echo !:3-4
bar baz
eric@sawyer:~$ !-2 #2nd-to-last command
foo -a bar baz
eric@sawyer:~$ ^ba^ya #replace 1st "ba" with "ya"
foo -a yar baz
eric@sawyer:~$ !^:p #MUCH cooler than "echo ..." ;)
foo
eric@sawyer:~$ !?bar #Last command containing "bar"
foo -a bar baz
eric@sawyer:~$ !:gs/ba/ya #replace all "ba" with "ya"
foo -a yar yaz

Quick reference

!! expands to the last command and all arguments

!-3 3rd-to-last command and all arguments

!^ first argument of the last command in history

!:2 2nd argument of the last command

!$ last argument of the last command

!* all arguments of the last command, but not the command itself

!42 expands to the 42nd command in the history list

!foo last command beginning with “foo”

!?baz last command containing “baz”

^foo^bar last command with the first occurrence of “foo” replaced with “bar”

!:gs/foo/bar last command with all occurrences of “foo” replaced with “bar”

<any_above>:p prints command without executing

Helpful .bashrc entries for history

Copy and paste these into ~/.bashrc

# Don't put duplicate lines in the history
export HISTCONTROL=ignoredups

# Store a lot history entries in a file for grep-age
shopt -s histappend
export HISTFILE=~/long_history
export HISTFILESIZE=50000

# No reason not to save a bunch in history
# Takes up several more MBs of RAM now, oOOOooh
export HISTSIZE=9999

# Ignore dupe commands and other ones you don't care about
export HISTIGNORE="&:[ ]*:exit"

Another neat trick with .inputrc

If you are still particularly fond of the up and down arrows, copy and paste the following into a ~/.inputrc file. This will allow you to start typing a command and then hit the up-arrow to search backwards through your history for commands starting with what you typed. I prefer other methods usually but this is pretty cool, huh?

"\eOA": history-search-backward
"\e[A": history-search-backward
"\eOB": history-search-forward
"\e[B": history-search-forward
"\eOC": forward-char
"\e[C": forward-char
"\eOD": backward-char
"\e[D": backward-char

Brace expansions

No shorthand list would be complete without the (in)famous brace expansions. Basically, they allow you to specify part(s) of an command to repeat substituting different values of a set within braces. Let me show you what I mean:

# Quickly make a backup
cp file.txt{,.bak}
# Equivalent to 'cp file.txt file.txt.back'

This is obviously very useful to prevent having to repeat parts of files or directory paths.

Suppose I wanted to make a template folder structure, I could make most of the directories I need with:

mkdir -p {src,test}/com/eriwen/{data,view}

This will expand every combination so I end up with src/com/eriwen/data, src/com/eriwen/view, test/com/eriwen/data, and so forth. Being able to create a template directory structure with one line is a big time saver!

Better filename expansion

I’m sure you often use the * operator to match files beginning or ending with something, but bash goes far beyond that. It should be noted, though, at some point a good find | grep is more powerful and useful. See Find is a beautiful tool for more information.

In addition to wildcards with *, you can use ? to match any single character. You can also limit matching to certain characters with []. For example:

ls
# prints "myfile netbeans.conf netbeans-6.5rc2 netbeans-6.5 netbeans-6.7 src"
ls netbeans-6.?
# matches "netbeans-6.5 netbeans-6.7"
ls netbeans-6.[1-5]*
# matches "netbeans-6.5rc2 netbeans-6.5"

.bashrc entries for better filename expansion

# Include dot (.) files in the results of expansion
shopt -s dotglob
# Case-insensitive matching for filename expansion
shopt -s nocaseglob
# Enable extended pattern matching
shopt -s extglob

cd shorthand

There are a couple quick tricks to change to oft-used directories. For example:

# Lame way to go home
cd ~

# The cool way
cd

You can also switch to the previous directory with cd - like so:

pwd  # prints /home/eriwen/src
cd /my/webserver/directory

# Do something...

cd -
# Now I'm back in /home/eriwen/src

To get more advanced with this, try mastering your directory stack with pushd and popd.

Conclusion

Effective use of history, brace expansions, and other shortcuts will to save you a lot of time. However, nothing is more productive than no typing. Automating things is best where possible. If you can’t automate, use smart aliases.

I know I did not cover tilde expansions, shell parameter expansions or bash key commands. You will want to check those out as well, but I find them less useful than what I’ve covered here.

Have any quick shortcuts you love? Share them in the comments!

Book Review: MooTools 1.2 Beginner’s Guide Thursday, March 11, 2010