Firefox-team January reading group: Effective JavaScript

27 December, 2012 § Leave a comment

Effective JSAbout a month ago Margaret Leibovic had the idea to start a Firefox team reading group.

The idea is that every month we choose one book (or a set of articles/essays) to read, then get together to discuss it (while eating and/or drinking).
Topics include programming, engineering, design, etc. Basically anything that makes us better software developers.

For the month of January we settled on Effective JavaScript, written by Mozilla’s very own Dave Herman.

We’re planning on discussing the book on Friday, 25 January at 12pm PST.

Discussion points:

  • Are there any points in the book that you strongly agree (or disagree) with?
  • Was there anything that surprised you?
  • Do you have any examples of times when you’ve used these strategies?
  • Do you have any examples of bugs you’ve seen because these strategies weren’t used?
  • What’s your new favorite JavaScript feature?

Anybody is welcome to join along and read the book with us. If someone wants to join the meeting discussion and doesn’t have access to our Vidyo video-conferencing software, send me a note and I’ll try my best to get you included in the discussion.

Book review: The Alchemist

4 August, 2012 § Leave a comment

I just finished reading “The Alchemist” by Paulo Coelho last night. I’ve been looking for ways to get away from my keyboard for a while now, and after talking with my brother I decided that picking up a good novel would be the perfect cure.

The Alchemist is a story of a boy on a mission to find himself and pursue his Personal Legend. The book told a great story as the boy find omens throughout his life and is reassured not to give up hope on his dreams. While I was reading the book I saw myself in many of the situations.

I wish the book was longer. At 167 pages, I finished the book in the first week of having it, although that is also because I couldn’t put the book down ­čÖé

So without sharing too many spoilers, I recommend that you stop by your local bookstore or library and pick up a copy of The Alchemist and give it a read. I hope you’ll be as happy as I am for reading it.

Re: Discourses – An Introduction

26 May, 2011 § Leave a comment

I’ve been reading Racism 101, a book by Nikki Giovanni. In a section entitled “Discourses: An Introduction”, Giovanni writes:

Writing is both a public and private pleasure. We write alone, talking to ourselves, trying to explain the universe in a series of metaphors, hoping to be understood. We mostly put away our thoughts, satisfied that we have written them. Occasionally we take a chance comparable only to skydiving without a parachute: We say to family, friend or lover, “Look what I wrote.”

Parents spoil children. Having been, and, in fact, being, both a child and a parent, I remember the utter embarrassment of my mother taking my poor efforts and putting them on walls. Even yet she has things I wrote in my preschool days. I have done the same to my son. Little notes he wrote from vacations, stories from second grade, are neatly framed, gracing my walls. I don’t think parents do that to hold on to the child; I think we do it to let the child know we are proud of the effort. The only thing more embarrassing than having to look at and be reminded that once we could neither color within the lines nor spell is … well … nothing. Where would we be if mothers didn’t hold on to scraps. How would we know who we are?

Tonight I was looking through some of my childhood writings, and came across a creative writing piece called, “Mom Can I Have A Party”. It appears that I wrote it in 3rd grade and tried unsuccessfully to get it published in the Lansing State Journal. I am posting this here because writers like Nikki Giovanni have inspired me to share one of the places where I came from.

I now present to you, in its raw and unedited form, “Mom Can I Have A Party”:

“Mom can I have a party?” asked Correy.
“Not until the house is clean,” said mom.
“Ok” said Correy. So Correy rushed to the Mini-Mart and bought a vacuum.

The  he went back home as fast as he could so he could have the party.

When he got home he vacuumed all that he could vacuum and threw away every single piece of paper in the house until his mom screamed, “Correy! Don’t throw away ALL the paper away in the house.”

“Okay mom. But it will look alot cleaner,” yelled Correy.

“No it will look alot dirtier,” screamed mom.

“Ok,” said Correy. So Correy rushed outside and got some of the paper. While his mom was washing the dishes Correy’s dad zoomed home in a limo, because Correy’s dad worked for the FBI.

He had some black sunglasses on and a trenchcoat. When Correy was done cleaning he set up the couch and was ready for the party.

Then he rushed to the phone and invited all his friend. He had diet Coke and Minute Maid. “We were on tv and ABC. We also had Shaquille O’Neal come over because we lived on planet Reebok,” shouted a kid.

“Mom! I got two dogs and their names are Snuffleupagus and Princess” yelled Correy. They are boy and a girl. Princess and Snuffleupagus had 5 babies. They looked just like their parents. After the party Shaq autographed Correy’s Shaquille O’Neal plaque. His mom said the house looked like a pigpen. But Correy just went to the TV and turned it on and a McDonalds’ commercial came on and it and it said “Hey! It could happen to you!” So Correy ran to the TV and turned it off.

So Correy rushed to his mom and asked for some money to get a shampooer for the carpet, because their were 15 stains in the carpet. And then he cleaned up the house.(Like at the beginning of the story.)


Wow, it sure is interesting to see where I came from. Without holding on to writing like the piece above, I would have no idea just how far my writing has progressed (or regressed).

Static vs. Dynamic Scoping

3 May, 2011 § 14 Comments

Have you ever heard of dynamic scoping? Most of us have worked in environments where static scoping is all we have, and probably for good reason.

One of the first things people think about when they hear the words “dynamic scoping” is dynamic memory, which is not at all what dynamic scoping is. Dynamic scoping could also be thought of as context-specific scoping.

C, C++, C#, and JavaScript all use static scoping, whereas Perl and Logo allow dynamic scoping though their local keyword.

Here’s an example to compare the two:

Static scoping Dynamic scoping
int b = 5;
int foo()
   int a = b + 5;
   return a;

int bar()
   int b = 2;
   return foo();

int main()
   foo(); // returns 10
   bar(); // returns 10
   return 0;
int b = 5;
int foo()
   int a = b + 5;
   return a;

int bar()
   int b = 2;
   return foo();

int main()
   foo(); // returns 10
   bar(); // returns 7
   return 0;

Dynamic scoping means that when a symbol is referenced, the compiler/interpreter will walk up the symbol-table stack to find the correct instance of the variable to use. This can be a cool tool to use when writing software, but also a huge source of errors if it is used accidentally.

How to Stop Worrying and Start Living

12 June, 2010 § 2 Comments

I just got back from a trip out to San Francisco for the Google I/O Developer conference. On my trip I was lucky enough to get some extra time to re-read one of my favorite books.

I took with me “How to Stop Worrying and Start Living” by Dale Carnegie. The first time I read this book was back in 2001 when I was a freshman in high school. At the time, I was lucky enough to get a scholarship from 4H to attend Dale Carnegie Training on Michigan State University’s campus.

I never have though of myself as a person who worries a lot or doesn’t know how to “live life”, and I think that the title of this book can be a little off-putting for those who haven’t read it before. However, after just reading the first chapter, I see just how valuable this book is.

The book has 28 chapters, each of them built around a theme that ranges from facts, effects, breaking habits, living peacefully, dealing with criticism, and more. The book is written through the experiences of many people that Mr. Carnegie met during his life. He discusses how people came from their furthest depths of worry to start living life more peaceful again.

Reading this book again has given me a new sense of patience, and I haven’t been bothered with criticism. I’ve also picked up a few things about leading effective meetings which I’ve started to spread at work.

The book can be a quick read, but I’d recommend reading a chapter a day. If you’ve read the book then you know how good it is and if you haven’t, now is your opportunity to pick up a copy.

Have you ever read the book or heard of Dale Carnegie? Are you interested in reading the book or at least checking it out? Feel free to leave a comment.

Section 7.7: Side-effects in functions

30 December, 2009 § 6 Comments

I’ve been reading Bertrand Meyer’s Object-Oriented Software Construction recently and have enjoyed learning a bit about the Eiffel programming language (also written by Meyer) at the same time.

The book focuses on principles of OOP (such as modularity and re-usability), techniques (such as generics), and also discussions such as genericity versus inheritance.

While there are many great topics covered in the book, I wanted to first write a blog post about ┬ž 7.7: Side-effects in functions.

Side-effects in functions

C#, much like Eiffel, has the notion of properties and functions. Both of these can be used the exact same way. For example, a Point class may have a property Theta or a function Theta:

// C#
public class PointP {
   public double Theta { get { return 0.0; } }
   public double Rho { get { return 0.0; } }

public class PointF {
   public double Theta() { return 0.0; }
   public double Rho() { return 0.0; }

public class Test {
   public static void Main() {
      var ppoint = new PointP();
      var fpoint = new PointF();
      Debug.Assert( ppoint.Theta == fpoint.Theta() );

While both can accomplish the same goal, there are semantic differences between the two. Meyer’s espouses that properties should be thought of as simple accessors, while functions may be thought of as mutators. Within Eiffel, this is referred to as the Command-Query Separation.

Therefore, functions like C’s getint() violate this principle, since they return the last integer seen on the input stream and advance the cursor at the same time. getint() is therefore an accessor and a mutator.

Accessors should have the property that they can be called multiple times with the same output each time.

Functions, in their most mathematical sense, should have the property that they can be called multiple times given the same input and have the same output each time.

In this example, Meyer would have written something like this:

/* C */
FILE input;
int lastSeenInteger = input.lastint;
ASSERT( 2 * input.lastint == input.lastint + input.lastint );

The same cannot be said for getint().

While we have now achieved an arguably better solution than what existed before, Meyer leaves the reader to decide if the function should mutate itself or return a mutated object. I will take this opportunity to conclude on his discussion.

Taking away the guesswork

At this point, it is up to the programmer to know if the function is going to mutate itself or return the mutated object. The programmer may check the interface of the class explicitly, or use features of their IDE to tell them if this function returns a void or a separate FILE reference.

By convention, Ruby solves this problem by using an exclamation point at the end of the function name to be explicit that the function will change the internal state of the object.

# Ruby
input_b = input_a.advance
b_last_int = input_b.lastint
a_last_int = input_a.lastint
assert( a_last_int == b_last_int )

Conventions like these remove guesswork out of the equation and allow the developer to know when they are calling a function with side-effects.

Readability is key

In the end, we as software developers should strive for the most readable and maintainable code. Each one of these tools, like side-effect function conventions in Ruby, should allow us to achieve this goal.

Do you have any conventions that you use or know of that call out side-effects in functions?

Finished Reading Clean Code

20 December, 2009 § 2 Comments

Today I finished reading Clean Code by Robert Martin aka Uncle Bob. I found out about the book from some coworkers during our weekly programming-discussion meetings. The book claims to leave its readers understanding:

  • How to tell the difference between good and bad code
  • How to write good code and how to transform bad code into good code
  • How to create good names, good functions, good objects, and good classes
  • How to format code for maximum readability
  • How to implement complete error handling without obscuring code logic
  • How to unit test and practice test-driven development

Part 1: Principles, Practices, and Patterns

I really liked part one of the book. The principles, practices, and patterns are well thought out and provide a style of programming that is,┬áunfortunately, rarely seen. Since reading this part, I’ve been writing smaller functions (about 4-5 lines at max) and have seen a payoff in the amount of reusability and readability. Chapters 1-7 read quickly, are informative, and are really great pieces to read.

Part 2: Case Studies

The pace of the book really drops off after chapter 7, and each subsequent chapter I lost more of that urge to pick up the book and continue reading. The final nail in the coffin that actually put me to sleep once was the Case Studies part (chapters 14-16). The example of the Args module was too large and my internal-brain compiler just couldn’t handle JITting three pages of code at once. I pushed through and read this whole part, but I wouldn’t recommend you doing the same.

Part 3: Code Smells

Part three is one chapter long and focuses on Code Smells. Code Smells are patterns in code that when seen give a bad taste in your mouth. They are implementations that shout that they could have been done better. The longer the code smells, the worse it gets, until finally the abomination that once started out as a faint odor now is the muskiness in the room that scares off developers from maintaining the module. This chapter is important to get familiar with. It might not be too useful to memorize the different smells, but knowing which ones exist is good enough, because you can always come back to this chapter to see how the code can be refactored.

Unit Testing

The last item I wanted to cover was unit testing. While the book mentions unit testing a lot, and devotes a chapter towards it, I don’t feel like developers will walk away from this book with an understanding of unit tests and test-driven development. Any developer looking for further understanding on unit tests should pick up a book that is devoted to the practice, since there is just far too much to cover in one chapter. I would recommend reading Test Driven Development: By Example.

Where Am I?

You are currently browsing the Book Readings category at JAWS.