I’ve had a lot of fun using Amber and find that it makes me super productive when writing Javascript applications. It’s young though, and has quirks, and the environment lacks some flexibility that more mature implementations have. If you want the full Smalltalk experience, you’ll want to check out Pharo Open Source Smalltalk. Click on the big “Download Pharo” button to get a one-click package that includes a Pharo image and a VM for your platform. The image contains everything you need to write and explore Smalltalk applications – code browsers, refactoring tools, a test runner, object inspectors, workspaces for running snippets of code, version control, and more.

When you start exploring the image you’ll find lots and lots and lots of Smalltalk. Unlike other programming languages and environments you might be used to, Pharo doesn’t make a strong distinction between your code and platform code. Everything lives and runs under the same image, and you have access to all of the source code. If you want to understand how the automated extract method refactoring tool works, you can pull up the RBExtractMethodRefactoring class to see the exact steps it takes to perform the refactoring. If you didn’t know that extract method functionality lives in the RBExtractMethodRefactoring class (as I didn’t), you can simply inspect the menu item and find out which smalltalk method gets triggered when you select that menu item. Pretty neat.

You can learn a ton from simply digging into Pharo’s guts. It has a lot of guts though, and you probably have never used a system like Pharo before. The following links should help you make sense of it:

• Pharo by Example - free book that you can read online or download as PDF. This was my primary resource for learning Pharo
• Pharo - the collaborActive book: Home - another great book, entirely online (I think), and probably more up to date than PBE
• Dynamic Web Development with Seaside - an introductory book to Seaside, the continuations-based web framework in Pharo. Also probably a bit out of date, but great for learning Seaside
• Pharocasts - a set of screencasts that goes into some of Pharo’s interesting nooks and crannies
• Stéphane Ducasse :: Free Online Books - a list of free Smalltalk books for download. Many of them are old. I’ve only read a few of them. Definitely worth looking into.

You can find all of these links via the Pharo home page, but I figured people would find it useful to have everything on one page. I’ll update this post as I think about and discover new resources for learning Smalltalk.

• show the name
• no CSS class if person is over 18
• special CSS class if person is under 18

Here’s the view spec:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

describe PersonView, ->
  describe "first render", ->
    beforeEach ->
      @model = new Person(name: 'Joe')
      @view = new PersonView(model: @model)

    it "shows the name in an h2", ->
      expect($(@view.render().el).find('h2').text()).toEqual('Joe')

    it "does not add the 'minor' class to the h2 if person is not a minor", ->
      @model.set age: 18
      expect($(@view.render().el).find('h2').hasClass('minor')).toBe(false)

    it "adds the 'minor' class to the h2 if person is a minor", ->
      @model.set age: 17
      expect($(@view.render().el).find('h2').hasClass('minor')).toBe(true)

And now the view that makes this work:

1
2
3
4
5
6
7
8

class window.PersonView extends Backbone.View
  initialize: ->
    @template = _.template($('person-view-template').html())

  render: ->
    $(@el).html(@template(model: @model))
    $(@el).find('h2').addClass('minor') if @model.isMinor()
    this

It uses this super simple template:

1
2
3
4
5

<script type="text/template" id="person-template">
  <div class="person">
    <h2> {{ model.name() }} </h2>
  </div>
</script>

If the view logic is complex I may separate the conditions into separate describe blocks, like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

describe PersonView, ->
  describe "first render", ->
    beforeEach ->
      @model = new Person(name: 'Joe')
      @view = new PersonView(model: @model)

    describe "person is not a minor", ->
      beforeEach ->
        @model.set age: 18

      it "shows the name in an h2", ->
        expect($(@view.render().el).find('h2').text()).toEqual('Joe')

      it "does not add the 'minor' class to the h2", ->
        expect($(@view.render().el).find('h2').hasClass('minor')).toBe(false)

    describe "person is a minor", ->
      beforeEach ->
        @model.set age: 17

      it "shows the name in an h2", ->
        expect($(@view.render().el).find('h2').text()).toEqual('Joe')

      it "adds the 'minor' class to the h2", ->
        expect($(@view.render().el).find('h2').hasClass('minor')).toBe(true)

With these tests in place, I can start testing the events. Details on that will be in a future post.

Join the discussion on Google+

Fair enough. I’m not going to solve this billing problem though. The account belongs to someone I worked with a while back who added me to the repository. If they want to address it, they will. In the mean time, I would like to get rid of that banner. After clicking around I found myself on the owners team page where I can add and remove owners.

The page gives me all the controls I could ask for…except one. I can’t remove myself from the owners team! I can kick out anyone else, or add anyone else, but I can’t walk away. I have to ask someone else to kick me out, whether that’s someone else on the team or GitHub support.

Fortunately GitHub’s design is nice and all it takes is one little tweak:

Too subtle?

I’m not really picking on GitHub here. I imagine they will address this or have a good reason not to. I’m simply using it as one real-world example of an important interaction that many UX designers skip over.

Here’s one from Google Analytics. Someone else created and added me to this mystery account three years ago, and as far as I know no longer checks his email for that account.

This case is a bit different. I can modify accounts that I’ve created, and I can view stats for an account that someone else shared with me, but I can’ t remove the account from my list.

Just something to keep in mind for those of you developing group functionality in your product. If someone can join or be added to a group, ensure that they have the power to leave, too.

Join the discussion on Google+

We went to lunch and I briefly told her a bit about agile software development, although I never used the term agile. Our convo about agile went like this:

Me: So to overgeneralize, there are two basic approaches to building software. The first is where you and I sit down and talk about everything that I would possibly need to build, and then I go off and build it all, and show it to you when I’m done. In the second way, I’d build a tiny piece and show it to you, and then figure out what’s right or wrong about it, and keep building little pieces, getting feedback from you along the way.

Cortni: Hrm…I think we should do it the second way. I don’t think the first way would work very well.

Now to give you a bit more background on Cortni, she’s not what you would call an Agile champion. In fact, she’s never been involved in any sort of software project, or even in a company that builds software. She grew up on a horse farm in Colorado, roughly 15 minutes away from the nearest town of 1,000 people, and went to dental hygienist school because she “heard they get paid well and make their own hours.” That’s why I found it so amusing that she immediately and intuitively felt that an agile approach to software development might work, whereas a BDUF approach definitely wouldn’t. Yet that should come as no surprise. She spent three years in school just to get started in her profession. How gauche would it be of me to think that I can write software for her after one conversation, and get it right? How many conversations would we need to have before I could get it right? I don’t think it matters. There’s no way that I can do my job unless I get regular feedback from her on how I’m doing.

Whenever we try to build software, we have to be respectful of all people involved. The first point of the agile manifesto is that software creation is a human act – performed by imperfect beings in order to solve problems for other imperfect beings. We can respect this first at the team level. Software makers should be held in higher regard than a process you found in a book or learned in a workshop. Process can be instrumental in getting software out the door and enabling a team to continually improve itself and its product, but the moment you honor the process element over the human element, you’ve missed the point and will only cause your organization harm in the long run.

Respect should extend beyond the software team to the customers and users (which are sometimes a part of the software team, sometimes not, and are often ill-defined, mis-construed, or simply unknown). When developing software for a professional industry like dentistry, it should be obvious that practitioners are highly skilled and that your understanding of their work will always pale in comparison to theirs, even though you can develop sufficient enough understaning to build useful software for them. That’s why we call them “domain experts,” and their insight and feedback are critical to the success of a software project of this sort.

Another thing to consider is that not all software is built for skilled professionals. A lot of it is built for internal use by massive organizations whose employees have no choice but to use it. Without addressing the issue of how humane or inhumane it is to force software on a large group of people, it’s important that we as developers understand that we are partially responsible for the quality of worklife experience that these people have on a regular basis. It’s difficult for me to express this without sounding like I’m preaching, but basically we should just try to be aware that some of the software we build will be used by people who have no choice but to use it, other than giving up their jobs.

I have a lot more to say about this subject, but I think this is enough for now. If this resonated with you at all, I would like you to keep the principle of respect at the forefront of your mind today.

Join the discussion on Google+

I only did what I knew, instead of learning something new

I didn’t even set out to build a business at first. All I did was write a little program to help me get better at poker. A friend of mine suggested that I turn it into a web site for other people to use, so I did. It took about three weeks of programming on my part, and I paid $200 for custom images to use.

At first it was great. I had a bit of a reputation on an internet poker forum, so when I launched the product I quickly received a lot of signups. After a few months, the signups started slowing down. So I did the only thing that I thought would bring in more signups - I lowered the price. All that did was cause most of my existing customers to cancel their plan, and not everyone signed up again at the lower rate.

If I could do it over again, I would have doubled the price for new customers. That way I would make just as much money with half of the signups! More importantly, it would create a sense of urgency for customers. I would have put out an announcement saying that the price would go up in a week, which I suspect would drive some new customers who want to get in at the low rate. And later on, customers would see that the price was increasing over time, so they’d know that they should sign up quick otherwise it might go up again. Lastly, my existing customers would be more likely to stick around, knowing that if they bailed they would never be able to get that low price again.

I sold it

This one’s easy. If you sell a recurring revenue generator for a pile of cash, you end up with a pile of cash and no recurring revenue. I could have bought another revenue generating product, or lived off the cash while I built something else, but instead I bought a fancy car. I was pretty smart for a 20 year-old, but obviously not *that* smart.

Why’d I sell it? Because I wanted a fancy car ;) But mostly because I didn’t know how to build a business, and I didn’t even really want to. I just wanted to code. So instead of learning how to build a business, I sold it off to someone else who would.

It pains me a bit to look back on this and think what it might have become had I stuck with it. But there’s no way to change it now. The good news is, today I’m just as interested in the business side of things as I am the coding, and I learned a lot from that first experience. Now I’ve got the motivation to stick with it and to learn how to grow a business. And next time I won’t be quite so willing to give up something that makes money while I sleep.

The rest of the conference was pretty great. AgileConf is a weird one for me because it’s so damn big. It’s an industry conference, not a community conference. The exhibit hall is insane (largely due to the sheer amount of shitty-looking project management software on offer). But the catered lunches were delicious (the Grand America Hotel in SLC has amaaaaazing bread pudding), and people that woke up early enough told me that the breakfasts were too.

There were a lot of great sessions, but my favorite had to be Elizabeth Hendrickson’s tutorial workshop on Exploratory Testing. I walked in to find people hunched over electronic Scrabble games, and Elisabeth had written a test charter to guide people on how to explore them. I didn’t write it down but it was something like “Explore electronic scrabble with the stuff in the box to discover how it works.” In the next round we learned to be more systematic in what to look for, like how to identify variables in the system under test. We didn’t get to do the third round because we spent a good amount of time in conversation between rounds. Elisabeth is extremely knowledgeable and was able to handle any question that people threw at her, and I also love that she invites other people from the audience to answer. She’s great at imparting the information, but also amazing at turning it into a comfortable conversation rather than it feeling like a formal classroom setting.

I also enjoyed @hackerchick’s talk on Lean Startup and Agile. If you’ve read any of the books or articles on Lean Startup, you probably knew most of what she was talking about. But she covered the gamut for people who aren’t all that familiar, and brought stories and excitement to the table to boot.

As always, the best part of the conference was meeting people. I got to hang out with my ADDcasts partner-in-crime, Dave Brady, and we recorded an episode with Michael Feathers. We also kicked back in high-back chairs and pair programming Smalltalk on a 12-foot projector. Good times. I got to meet Tim Ottinger who told me about his experiences watching the internet unfold before his eyes. It was also great fun meeting ADDcasts listeners like Colin Jones and David Adsit. And of course there was that time when I sat down next to Gary Bernhardt for 10 seconds and got up to grab food and look for Gary Bernhardt.

AgileConf is huge, which brings a bunch of lame stuff but also draws a huge number of super awesome people in. I’m looking forward to next year, and I’ll definitely track down folks that I didn’t manage to meet this year.

• Syntax is quick and easy to learn, and fun to use.
• I love the function definition syntax. Love love love.
• Same goes for re-opening classes.
• Scoping can be tricky when passing functions around, but it allows for a lot of power.
• For loops are ugly
• I need to learn how to do operator overloading
• JavaScript is missing a lot of stuff. Need to figure out the ActiveSupport equivalent for JS.

All told it only took me a couple hours to skim through the PragProg CoffeeScript book and hack this up. It went fast and I was pleased with how easily I was able to refactor the code as I built it up. Next I’m going to mess around with adding browser-side features, as well as running it in Node. And I’m going to figure out how to test it.

Off the top of my head, things that make CoffeeScript attractive to me:

• REPL
• clear syntax
• based on “the good parts”
• modules
• inheritance model
• clean function definitions
• jQuery integration
• Node.js & websockets
• It’s in Rails by default
• A lot of deployment options, including Rack

Now I just need to start messing with the language and writing some programs with it.

The 20 hours figure intrigued me. My dad is an ENT surgeon, and he’s managed to keep up for 26 years in a field where “technology turns everything upside down about every two years.” He did the first half of his residency before endoscopes were in wide use, which required him to peel back the scalp and skin around the eyes in order to drill a hole into a patient’s sinus. Later, endoscopes gave him access to more parts of the body, while causing much less damage to the patient. Nowadays he uses the Fusion Navigator, which he describes as “a GPS for the body.” Impressively, he’s kept up with changing medical technology in the face of distractions such as living in a decompression chamber for a week as a part of his underwater medicine training; setting up hospitals in Thai jungles; and overseeing the medical support infrastructure for 15,000 Marines deployed to Iraq.

I asked him how he’s done it. What follows is what he told me. Of course, this is just one doctor, but I think my dad is an interesting data point for those developing a personal model for continuing education.

Observe other people at work

Dad stressed that this is the most important part of his multi-pronged approach to continuing education as a surgeon. He regularly sits in on other surgeries, observing the team’s preparation and procedure. He inevitably learns new techniques, new ways of looking at surgical problems, and how teams work together to pull off a surgery.

Attend at least one professional conference every year

Conferences create a high density population of surgeons to share ideas, and the planned presentations provide a structured way to learn about the latest happenings in the medical world.

Read high-quality material for at least 15 minutes each day

Dad reads for at least 15 minutes, every single day. When I questioned the possible depth and breadth of his reading, he said that he wasn’t reading to learn something in particular. He simply cultivates the habit of reading high quality medical information. He has a library full of textbooks and journals that he has “given up on the hope of reading everything in here…that’s just impossible.” So every day he sits down, grabs something from his library, and reads for at least 15 minutes. He puts it away when he’s done, and the next day reads something different.

Research to prepare for individual projects

While Dad hasn’t read everything in his library, he is familiar with what he can find in there, and knows where to look for specific information. So when he is assigned a surgery case, he reads the case information and then uses it to inform his research through his library. He digs up articles and reference materials that will be relevant to his case, along with materials from previous cases.

0.1.0 has a nasty bug that corrupts a checked out external’s .git repository. This happens because giternal sorts the files in .git before piping them to tar, in order to minimize repo bloat. Unfortunately, tar doesn’t seem to like that, and so when unfreezing the repository it loses many of the files in .git/objects. Instant repository corruption.

What you can do

The best thing to do is probably to wipe your external dir and do a giternal update after upgrading to 1.1. This will check out a fresh copy of the dependency, along with its uncorrupted git repo.

I don’t actually think there’s anything else you can do. Sorry :(

The video is 80 minutes long.

To recap, I read both analog and digital books. I prefer reading on Kindle. I buy directly from the publisher when I can, because they usually offer a PDF download bundle. When I can’t find a book in kindle format, I buy the paper copy.

Whether I’m reading on my kindle or riffling through pages, I usually read a book more than once. First I’ll read through it quickly, without stopping, even if I don’t understand parts. I bookmark those as difficult sections and move on. I don’t make many notes at this point – just a few highlights here and there to indentify the author’s assertions and supporting facts and anecdotes.

After a quick first pass, I flip back through the book and take a look at my notes. These clues help me understand the book’s important points. I reconstruct the author’s arguments by stitching together the highlighted parts. I can tell the solid arguments from the flimsy ones at a glance. The Kindle makes this sort of note-rearranging a breeze because I can import the highlights into my computer [1].

I don’t always take great notes. A lot of the time, I don’t care enough to develop a complete understanding of that particular book at that particular moment. It’s good enough to mentally index the key themes and structure of the book, and let my computer do the boring task of remembering the actual words. Then I’ve got more energy to do the fun part, the part that only I can do: unlocking the author’s secrets when the time is right.

This works great for digital books, but analog requires more work. I often have vague notions of an idea or fact that I remember reading, but can’t remember which book it came from. Sadly, I can’t google my book shelves [2]. Until now.

I’ve got a fancy Scansnap S1500M that I use to scan documents into DEVONthink. DEVONthink OCRs the documents and then proposes possible filing locations. I’d like to use DT’s powerful search on my book shelf. Yesterday I took a couple of old books to Office Depot and had them slice off the bindings. Then I scanned the books for DT to archive. I’ll save the details for another post, but the bottom line is that for $2.50 at Office Depot & 15 minutes baby-sitting the scanner, I can take any book from my bookshelf and have all of its contents instantly searchable on my laptop.

Slicing a book in order to scan it felt weird at first, but it felt great to toss the pages into the recycling bin after scanning. Books (computer books especially) are heavy and a pain to move and take up space in my house. My entire library will fit on my laptop! I can load books onto my kindle or iPad for extra portability. If I want to go old school, I can print out the pages I want to read and fold them into my back pocket. I did the same thing with a few brand new books. After scanning the pages, I stapled the chapters separately. They look and feel like digests.

I’m pretty excited about this new approach. I can highlight the paper copy more aggressively and dispose of it when I’m done. My computer holds onto the master copy and makes it searchable for me. I have some ideas of how this approach could change my reading habits, but for now I’m going to just run with it and see what happens.

——–

[1] On the flip side, transcribing notes by hand adds sensory experience which can improve your ability to recall information.

[2] Google Books has its shortcomings. It can’t constrain its search to my bookshelf. Deep study is difficult due to missing pages.

I don’t think I need the “power” of any sort of dynamic blogging engine, and I certainly don’t need all of Seaside’s power. What I need is something that will let me capture, develop, and publish my ideas. So I’m going to try something a bit different. I’m going to use a site generator rather than a dynamic blogging engine. I’ll use it to publish a blog, but I want my site to also host more structured content. Life happens chronologically, but I can make my information more meaningful and useful if I spend a bit of time organizing it and keeping it up to date.

My plan is to begin creating skeleton pages for the site. These will be sparse pages that contain some useful bit of information – tools I use, sites I like, random ideas I have, etc. Over time, I’ll build up the content on these pages, and create new pages and link to them.

I’m not going to say what tool I’m using just yet. Maybe you can figure it out from the generated HTML.

You learn a lot from pairing with someone.

The two main criticisms of the Software Craftsmanship Manifesto are that it encourages programmers to focus only on the code side, and the low barrier to entry to calling yourself a “Software Craftsman.” Allow me to address these points of criticism.

Criticism #1: Programmers will fall in love with the software at a technical level, at the expense of building software that makes users go WOW

Martin Fowler may be right that “those people who primarily self-identify as programmers feel a large part of their life is no longer important in the agile world.” They are important, obviously, but if they don’t feel important then that’s something that needs to be addressed. Part of me thinks that SC is a reaction to broken software organizations that discourage interaction between programmers and users, and so the programmers retreat into their coding cubbies and focus on the only thing they have control over - their technical practices.

Back when Alan Cooper was stuck in an MS-dominated paradigm, he wrote, “Programmers aren’t evil. They work hard to make their software easy to use. Unfortunately, their frame of reference is themselves, so they only make it easy to use for other software engineers, not for normal human beings.” Some people seem to fear that a focus on craftsmanship will lead to a world of well-tested, well-designed code that powers ugly software that is painful to use. I don’t think that’s the case. The common theme throughout Agile Roots 2010 was user experience, and how to get UX people working closely with programmers. The Agile testing crowd is trying to get the message out that testing is about understanding user expectations. When you get programmers, UXers, and testers collaborating, you have the holy trinity of software development - quality software that solves user’s problems, with no hidden surprises.

Criticism #2: Low barrier to entry to calling yourself a Software Craftsman

Anyone can sign his name to the manifesto and call himself a software craftsman. I can add my dog as a signatory if I want to. Apparently I’m supposed to believe that this cheapens the values expressed in the manifesto. The reality is that anyone can call himself anything he wants! I’m the President of the United States. I’m dating Angelina Jolie. I’m a member of the World Cup-winning US soccer team. You get the idea… Simply calling yourself something doesn’t make it so. Who decides what is a “true” software craftsman anyway? It’s up to you to decide whether people you interact with practice what they preach. The manifesto doesn’t say, “we are craftsmen” - it says “we aspire to be craftsmen.”

I can’t accurately assess someone’s technical abilities or theory of software development based on the presence of his or her name on the SC Manifesto. I’d be an idiot for trying. But I bet that I could share a beer with anyone on that list and have an interesting discussion about software. Even if they don’t test like I do. Especially if they don’t test like I do. It’s perfectly valid for people to hold different theories on how to build software. I think we’re all better off if we let those theories mingle with each other, evolve, and even blow up in our faces on occasion. At the very least, Software Craftsmanship provides one means of recognizing people who give a shit and are worth talking to.

What’s missing from this discussion?

SC discussions have focused primarily on the programming side, but it’s called the Software Craftsmanship Manifesto, not the Typing-code-into-my-One-True-Editor Manifesto. Programming is only one role in the software creation process. Wouldn’t it be great if testers and UXers could organize themselves into groups with hokey names, just like the Software Craftsmen? Then we could throw one big mixer and invent 99% of the world’s useful software. Perhaps they can rally under the banner of Software Craftsmanship. They should rally under the banner of Software Craftsmanship.

What are we really talking about?

I see the Software Craftsmanship Manifesto as an evolution of the Agile Manifesto. The key phrasing is not the “Not only…but” clauses, it’s “raising the bar of professional software development by practicing it and helping others learn the craft.” Let’s examine it in detail:

• raising the bar - Nobody has a clue how to objectively assess the best software people. That’s why licensing boards are so potentially dangerous to the industry, and why certifications are so useless. If we want to achieve progress, it is the practitioners that must take responsibility for elevating the industry.

• practicing software development - Most professions devote as much time to practicing as they do to performing. Yet for some reason we approach every day like we’re completely prepared for what’s to come, despite working on problems riddled with uncertainty. SC says that we must acknowledge, respect, and prepare for the difficulty inherent in our work. SC says that the state of the art changes so rapidly that you must continually hone your skills if you are to build useful software over a span of years or decades. SC says that we must not let ourselves become complacent in our abilities, or make excuses for cutting corners. If your programming environment doesn’t provide automated refactorings, then you had better practice common reactorings so that they become second nature to you, and so that you can execute them swiftly and safely on production code. Above all, SC says never to let “too much work” get in the way of “a job well done.”

• helping others learn - this is the crux of the manifesto, because software development is fundamentally an iterative learning process. When we share our experience and knowledge with others, we allow them to benefit from our past successes and failures. When we teach, we also learn, and the mixing of ideas allows us to expand the adjacent possible.

Story time

I was in Chicago for Agile 2009, the huuuge Agile conference filled with way more scrummasters than programmers. It’s where I met Corey Haines, or more specifically I was at David Chelimsky’s house pairing on RSpec when Corey Haines walked through the door and greeted me with a big hug. If you know Corey, you know that’s not a strange way for him to greet a stranger. Corey told me about the Software Craftsmanship conference taking place across the street from AgileConf and said that I should come. Some folks whose work I admired would be speaking, like Uncle Bob and Michael Feathers, and I would be exposed to other smart people in the software world who I hadn’t heard of before. I almost didn’t go, because I didn’t have enough money in my checking account to both pay for the conference and get my bills paid that month, but after a few hours of deliberation I held my breath and fired off an email to Corey asking if he could spot me the registration fee. He was in the middle of his pair programming tour where he basically worked for peanuts to put gas in his car to get from place to place, so he wasn’t exactly in the best position to lend me cash. I’m incredibly grateful that he did, because it was one of the best conferences I’ve been to in my life. There were talks about design, refactoring, compilers, required reading for programmers…Ken Auer even spoke about achieving a balanced life by picking four key areas of focus. Programmers…talking about life balance??? I thought we’re supposed to be locked away in our code caves for 72 hours straight surviving on cold pizza and jolt cola! Clearly this whole software craftsmanship thing is a different way of looking at software development. But how exactly?

The Software Craftsmanship Manifesto is valuable because it provides a goal - raising the bar - and a blueprint for getting there - practice, practice, practice, and help others learn. SC may run the risk of creating an echo chamber and excluding people who are capable of contributing valuable insight to the conversation, but I’m not afraid of that happening because at its core, SC is about sharing and being open to ideas for how to build software. Without SC and similar movements, we run a far greater risk of believing that we’re alone in the battle against crappy software, instead of recognizing that we’re part of a vibrant community of thinkers and practitioners who want to change the world.

For the most part, I stick to non-fiction. My goal in reading any book is to acquire new information, or ideally to elevate my understanding. Those are different goals, and a lot of books that satisfy the first don’t satisfy the second. Either way, in order to get the most out of a book, I follow a basic process:

1. First, I do a quick skim of the book, reading the table of contents, the index, intros and conclusions of chapters, the final few pages of the book, and just generally flipping through to find interesting sections or visuals.
2. Next I read through the book as quickly as I can, bookmarking pages that seem important or are difficult to understand. I may highlight short passages for later reference, but I don’t really take notes at this point.
3. Once I’ve finished the book, I go back and look over the sections that gave me difficulty. This is where I begin to go into more depth, taking notes, writing down my questions and trying to figure out the answers to them.

This process comes pretty much straight from How to Read a Book by Mortimer Adler. I tell you what, friends give you funny looks when they see that book on your desk. I don’t mind though, because since I started reading this way, I am able to go through books faster than I was able to before, and I get a lot more out of them. Presumably this is the sort of skill I would have learned in college, but I didn’t attend for long enough.

Digital formats change the way I read

I’ve been using this process on paper books for a long time. It’s taken me a while to completely adapt it to digital books. At first I tried to pick a single platform to handle all of my reading. The biggest problem is that every digital reader has some strengths and weaknesses. The kindle provides the best reading experience for me. I think the e-ink is gorgeous, and over all it is the closest I can get to a real book. It’s better than a real book in a lot of ways, because the computer books I like to read are hefty and awkward to hold. The kindle has one glaring weakness for me: navigation. I can set bookmarks and highlight passages, and fairly easily jump between them, but it isn’t as natural or efficient as dog-earing pages or sticking my fingers in between the pages to hold a spot. The kindle provides an excellent linear reading experience, but I find it cumbersome to jump back and forth between different parts of the book.

The other major downside to kindle is the DRM-protected books you buy from amazon.com. I understand why companies do DRM, especially for a technology as new as e-readers, where nobody has a secure hold on the market yet. But the promise of digital books to me is that I can read content on a number of devices, each with different capabilities. Amazon has a kindle reader for basically every platform, but each one is still locked down with DRM, and most importantly I am limited by amazon’s ability and willingness to provide features.

I’ve started to buy more ebooks directly from publishers rather than amazon, because publishers often let you download the book in more than one format. Pragmatic Press comes to my mind first, but there are others such as Smashwords who have recently made all of Gerald Weinberg’s excellent books available in PDF and Kindle format for only 10 bucks. This is important to me because my process for reading digital books, after a good bit of trial and error, looks like this:

1. Load up the PDF on my computer and do my pre-reading, studying the table of contents and index, and skimming the book a little
2. Read through the book on my kindle as quickly as possible, bookmarking difficult pages or highlighting interesting passages
3. Return to my computer to go into the book in more detail, take notes, and all that

Steps 1 and 2 involve randomly accessing the book’s contents. This is not the kindle’s strong point, in my experience. On the other hand, kindle kicks ass when reading linearly, which is what step 2 is all about.

In addition to random access, PDF’s strong point is that it’s a standard format with excellent tool support. I have a simple use for it, creating rich text notes and copying the links to particular pages of a PDF to embed in the note, or just copying and pasting text from the PDF into the note. There are more advanced annotation tools that let you add annotations directly to the PDF, if that interests you.

When I can download a single book in multiple formats, I have the best of all worlds. Kindle lets me burn through books quickly and comfortably, with an easy mechanism for bookmarks and highlights to refer to later. PDF lets me pull it up on my computer and jump around, or copy and paste text and images, or links to specific pages. The multiple formats allow me to use the best tool for the job, so to speak. Because of this, I have tended to purchase non-fiction books directly from publishers that let me download a PDF version in addition to a kindle version. I find that I simply get more value from my reading when I can read books in this way.

What does this mean for readers?

I am interested to see how the digital book revolution plays out. I suspect that more authors will move toward self-publishing, for a variety of reasons. One is that they have more control over how their content is distributed. I think creative folks are coming around to the idea that it’s more important that their work gets exposure to a large number of people than it is to be fairly compensated by every single person who consumes that work. Put another way, most authors would rather sell 100k copies of a digital book and have 300k stolen copies out there, than sell 50k copies and have zero piracy. I have no clue if that scenario is realistic, but the point is that if you can earn double the revenue and have 8x the readership, then you’d be silly to focus your efforts on combating piracy.

The other reason is that I’m pretty sure traditional publishing is dead unless they embrace technology much more than they have so far. As Jeremy McAnnally points out in his eBook Authoring eBooks, he was able to publish his Rails 3 upgrade guide right as Rails was released, but the first dead-tree books didn’t hit stores until a year later. Many books, especially technical books, are available as “rough cuts” or something similar, but there’s no denying that the publishing industry in general moves at a snail’s pace when compared with digital publishing.

What about you?

I am curious to know what other people think. How are you reading books these days? Are you addicted to digital readers or do you still prefer paper books? If you do read digital books, what influences your purchasing decisions? Is it convenience, price, availability of formats, or something else? For authors or aspiring authors, how do you plan to publish your content in this day and age?

My biggest problem with “X sucks” talks is that they are so fucking insulting to my intelligence. News flash: any tool or technique sucks when used incorrectly or in the wrong context. And presenting only one side of an argument is the surest sign that you either don’t know what you’re talking about, or that you’re a self-indulgent asshole. You know who else only presents one side of an argument, and discredits other opinions through hand-waving and strawmen? Politicians and lawyers. Congrats on joining such esteemed company!

When you stand up to present to your local user’s group, you have a responsibility to give them the highest quality information you can. This can be in the form of hard data, or experience, or references to other people’s work, and the ideal presentation will use a combination of these. Do your best to explain and argue your position, but make sure that you make people aware that there is another side to the debate, one that you aren’t presenting, that they should go search for themselves if they’re interested. I have yet to come across a software-related topic that can be fully explored in a one-hour presentation. Don’t insult your audience’s intelligence by presenting an extremist stance. At best they’ll think you’re an idiot. At worst you’ll fuel the FUD machine that has been plowing through the software industry all these years.

An interesting point about “X sucks” is that 6 months later, you will probably find out that you’re wrong! I find that desirable, as it demonstrates maturation as a developer and as a person. In that sense, “X sucks” might not be such a bad thing as it represents one step on your path to enlightenment. Just be sure to heavily qualify your talk as presenting your personal experience at this moment in time, and that there are plenty of people who disagree with you, and that a few months from now you may completely reverse your position. Realistically, you will probably bounce from one extreme to another, with the extremes gradually moving towards each other like the peaks of a fading sine wave, until you reach an equilibrium point. This equilibrium point is that fine line between “X sucks” and “X rocks,” where at any given moment you can only know which side you’re on based on tons of experience.

The next time you sit down to write an “X sucks” blog post or talk, please reconsider. Honor your abilities as a thinking developer by taking the time to advance our industry’s dialogue rather than making yourself look clever by trashing other people or techniques. We’ll all be better for it.

After I did that, I was curious to know if I had any other broken files in my library. iTunes identifies broken files with an exclamation point – but only after you try to play the file! I spent about an hour googling trying to find a quick way to show me all the broken files. All the tips I found were from 2006 and earlier, and none worked on iTunes 10 on my computer. That’s when aniero suggested I write a script to parse my iTunes library XML file and check it against the file system.

Here’s the script I came up with. No guarantees that it’s perfect, but it worked for me:

Some::Class::Name.class_eval do
  def my_added_method
    # something here
  end

  def existing_method_with_my_extension
    # something here
    existing_method_without_my_extension
  end
  alias_method_chain :existing_method, :my_extension
end

I use class_eval because doing so ensures that my code actually does what I think it does. For this code to work, Some::Class::Name must already be defined, otherwise I’ll get an unknown constant error. That helps me avoid two time-wasting pitfalls: a bad load path, and typos.

Get your path right

When you extend a gem, you need to have the gem installed in the system and in your load path, and then require it. If you’re using Rails, it will automatically require it for you when you reference the constant name. By using class_eval, I know immediately when my environment isn’t set up properly, because I get an error.

Busting ghost classes

Another problem I run into is stupid typos when writing out the class definition, or getting the module heirarchy wrong. Something like this:

module Sum
  module Klass
    class Naem
      def my_added_method
        # something here
      end
    end
  end
end

In this case, Ruby is all too happy to create a second class for me called Sum::Klass::Naem even though I’m trying to extend Some::Class::Name. I call these “ghost classes.” I can’t figure them out just by looking at them, and they cause lots of mischief.

Order of extension

As a final note, when you extend a class, order often matters. It’s possible to load your “extension” before the actual implementation and have it work (assuming you fully-qualified the class name properly, including its superclass, otherwise you get that funky superclass type mismatch error). Order matters when you want to redefine a method, because Ruby will use the last method definition it comes across. That means if you and the gem both define #foo, and you load your extension before loading the gem, Ruby will use the gem’s version. In order to get the behavior you want, you need to load the gem first. This also applies to alias_method_chain, which would blow up on you because the method you want to alias doesn’t exist yet.

This is just one way to reopen classes in Ruby, it’s not “the” way. I’ve found it to be helpful in avoiding stupid mistakes, or catching environment issues, so I use it. It has the added benefit of being more explicit, I think, about the fact that I’m opening an existing class. I hope you find it useful, and if you’ve got other tricks for opening classes, please share in the comments!