Monday, March 07, 2011

...so the Kindle just works out better for me

I can't believe how long this post turned out to be. Yikes. If you don't care about what shaped my evaluation criteria, feel free to skip to the conclusion.

It's true, I owned a Casio PDA

I recently decided to jump into the ebook market. I've been following it for quite some time but could never justify being an early adopter with the Sony line and figured I'd just wait it out. I have many fond memories of getting involved with project Gutenberg back in 2002 and discovering the immense library of public domain texts. At the time I read exclusively on a Cassiopeia E-125 but my commitment to ebooks waned as I upgraded devices and became far more involved in pursuing my degree.

Then iOS happened and Apple introduced their bookstore

I was initially quite interested in the concept of reading on my iPhone, again harkening back to the Casio days when I was traveling often for work and reading quite a bit. I bought a book, on a whim and out of other reading material, when coming back from a business trip in Oct 2010. I loved the book I read and I loved the convenience of my iPhone. But, quite frankly, it took it's toll physically on my eyes as well as making me wish swipe was never invented. My lasting impression was how much a hassle it was just to turn the pages, over and over and over.

Eink contenders aplenty, turns out I want an ecosystem too

For a long time I followed what Sony was doing and watched various other Chinese manufacturers make eink-based device announcements. However, I was never motivated to purchase because I realized (over several years of following) that the hardware was only half the solution for my ideal setup. While I loved reading on the Casio, it wasn't particularly enjoyable loading my ebooks from Project Gutenberg and it got messy managing things when my library became large (not to mention the lack of availability of new publications).
Bottom line, I finally think the market is in a mature-enough place (though far from ideal maturity IMO) that I didn't considered anything other than the Kindle 3 or the Nook.

Grading criteria

I've been patient, for a long time, and have been mentally recording a healthy list of criteria that I wanted to measure. Yes, there are dozens of reviews on both of these devices, but I frankly wasn't satisfied with what I'd read because I wanted a hands-on, personal, thorough evaluation for just my list of requirements. Thus, the following opinion/analysis really only satisfies what I care about and, of course, YMMV. What I wanted to evaluate, in no particular order:
  • The Feel
    The Kindle is lighter than the Nook, but that didn't make it an immediate winner. I liked the extra weight on the Nook that made it feel more handleable (is that a word?). However, with the extra weight, the Nook felt slightly more fragile and I noticed I was more careful when carrying it while walking and reading or doing other activities rather than just staying put and reading. The Kindle, though lighter, also seemed more robust and resilient.
    Winner: Kindle
  • Affordance and Input
    (in terms of how intuitive it was to use the device both visually and non-visually and also how intuitive the initial experience was)
    Kindle: The page turning buttons are slimmer than the Nook but (again, IMO) more well defined both physically and visually. The keyboard and 5-way button provide immediate input and tactile response. The overall experience of getting to know, and get comfortable, with the device was very natural to me.
    Nook: The Nook navigation buttons have little visual separation other than the large arrows, but physically the user can feel the difference due to a raised bump. On more than one occasion I inadvertently navigated in the wrong direction. After a while I got used to it and I like how much wider the buttons were than the Kindle, though with the additional width the user loses grip area. I did not like the LCD navigation, and maybe that's because I tested the Kindle first, but I found the navigation slow (in response to gestures), slightly confusing (scrolling options) and generally less appealing. Plus, the backlight is a strong contrast to the placid eink display for my eyes (yes, the backlight dims very quickly, but the combination just didn't work for me)
    Winner: Kindle

  • Instapaper support
    I like Instapaper a lot. It saves me time. It removes content distractions. It lets me collect stuff that's not important to read immediately, but important enough that I want to read it when I'm ready (meaning, when I have more time). It's convenient (works in all browsers), works on multiple devices (iOS, Android, Blackberry) and is simple to use (one click). So, if I want to read my Instapaper content on the Kindle or Nook, what are my options? Just Kindle.
    Winner: Kindle
  • File archiving
    Both B&N and Amazon have areas where the user can download previously purchased content. There was, at one time, legitimate concern about Amazon exercising the remote kill switch (as it did once), but under terms of the suit settlement they agreed that it will not happen in the future.
    Winner: Tie
  • Notes and highlights (I like to annotate, not all the time, but frequently)
    Kindle: Notes can be multi-lined and added to all content. User moves cursor and starts typing.
    Nook: Notes are limited to a single line and not available for PDF content. User awakens LCD, selects menu option, selects another menu option, move cursor with d-pad, selects menu option, moves cursor, selects menu option, begins typing note.
    Winner: Kindle
  • API (since I like to play with code)
    Kindle: KDK available here
    Nook: No API or development kit available (though rumor has it the color version will soon be unlocked for full the full Android Marketplace)
    Winner: Kindle
  • Performance
    Performance was pretty good in terms of rendering and input responsiveness. The only times I noticed a difference was when comparing menu navigation, but since the menu approach was unique to each device, I'm not going to compare the menu performance in conjunction with general use. The eink refresh was fast enough to never annoy me and they both seemed nearly identical in that regard.
    Winner: Tie
  • Lending
    From what I understand lending is currently subject to publisher overview, so I didn't notice a unique advantage comparing one device to the other. Both vendors allow a single-use, 14-day lend on publisher-approved books.
    Winner: Tie (user is equally hosed regardless of vendor, sigh)
  • PDF Support
    Turns out this feature became more important to me the more I thought about it. There are many times I have technical PDFs open on my desktop that I just don't get around to reading in a timely manner. After testing two of the latest (this and this), I was sold on being able to not only read these but also annotate them.
    Kindle: Multiple rendering options to adjust zoom and device orientation. Five contrast settings. Supports notes and highlights. Graphics properly rendered, layout preserved. Overall, very readable and usable.
    Nook: Supports three different text fonts and six text sizes. Mangled embedded graphics in my evaluation. Subject to layout mishandling and text injections (first PDF was very difficult to follow). No annotation support or additional rendering options. One time I got an error indicating I needed to force close the Activity Reader when I was navigating a PDF.
    Winner: Kindle
  • Extensability
    Kindle: No user extendable memory or replaceable battery
    Nook: User replaceable battery and microSD slot located underneath rear cover (thanks Cary A. and Jeff J. on this!)
    Winner: Nook
  • Battery life
    I wasn't sure how I was going to accurately measure this. Turns out I didn't have to worry about it. I've had both of these devices for several weeks now (time of this post) and have been using the Kindle quite a bit more than the Nook at this point. I charged both devices before my evaluation. At no time during the past several weeks have I charged either device and only minimal time in syncing via USB. Thus, after finishing my first book on the Kindle I was ready to read something of equivalent length on the Nook to test it out. Unfortunately, the battery was nearly depleted. And that was after being powered-off, nearly every day, for more than a week. I finished up the lengthy user manual and settled on a book to try, then powered down the device. I turned it on the following day to be greeted with the message that it needed to be charged (which it is doing at this time). Maybe I have a defective battery? The Kindle, under much heavier comparative use, appears to be at slightly less than 50%. Scientific approach? No, I wussed out, this is good enough for me.
    Winnner: Kindle


Everything said and done

I enjoyed comparing both devices and I can clearly see advantages for both. If I had a family member that was a book-a-week reader, aware and on top of recent releases, visited the bookstore often and was happy with an eink device, I'd recommend the Nook. But, overall, I found for me that the Kindle was the superior choice for my needs. Quite frankly, Whispernet became a selling point for me (after I had already purchased the Kindle). I had no idea how convenient it'd be to simply email stuff away (for free) and have it arrive on my Kindle ready to go. That's turned out to be very convenient and was icing on the cake. There were sprinkles too, like the immediate dictionary, being able to tweet/share passages, openlibrary.org integration and line-spacing options...so the Kindle just works out better for me.

Tuesday, February 15, 2011

Git, Gerrit, Redmine, gitflow: An ideal software development and release management setup

I've been using Subversion for more than 5 years and have been following Git's development, adoption and maturation during that entire time. At work, each time we would create a new repo for a project, I cringed at the thought and questioned, "but, we could be doing this in Git..." However, given the development environment as well as business context (not a software shop), it just wasn't suitable to immediately jump into Git. So what did it take to make the jump? Some rather significant dissonant (and concurrent) development tasks, branch management issues and several deploys that cost more time (and thus, money) than they could have.

Our primary requirements for the SCM migration included the following:
  1. 1. Central repo to act as an on-site, internally maintained, redundant source authority with replication capabilities
  2. 2. Integration into Redmine
  3. 3. A well defined methodology for maintaining several projects through multiple concurrent phases
  4. 4. Mature CLI toolset
  5. 5. Hudson/Jenkins support
  6. 6. IntelliJ integration
  7. 7. SCM should be open source with a vibrant community
I knew most of these requirements could be met with Git, but didn't want to make a blind choice and simply choose Git as the new internal de-facto standard. I've had some simple experience with Mercurial in the past and even spent some time doing some projects in Darcs several years ago. I have a good friend whose company (software shop) moved to Mercurial and he offered their arguments in support of choosing Mercurial. Frankly, I liked a lot about what I saw in Mercurial and I didn't ever have any negative experience when toying around with it. Though, truth be told, the projects I conjured up for trying it out were very simplistic and never moved outside of my local development environment. During my investigation I found stackoverflow.com to be immensely helpful in identifying specific differences and perceived strengths and weaknesses.

Git

In the end, after all the reading, playing, comparing--I found that Git just jived with me and it satisfied our requirements (4,5,6,7). Darcs just didn't fit, and Mercurial looks great, so I have nothing negative against those projects. Plus, they don't have Gerrit. Kudos to the Java Posse for a recent podcast in which Gerrit was discussed, timing happened to be critical as it was in the middle of my research, and it sounded like just what we needed to address a recent issue of lack of code review. Even though I was already heavily leaning toward Git at this point, Gerrit clearly brought additional benefit to the migration and methodology changes we were considering.

Gerrit

Gerrit is wonderfully simple to get setup and running. I very much appreciate that it's quite self-contained and offers OpenID support to avoid the grief of maintaining local user accounts. In fact, Gerrit will not only help facilitate code review and branch maintenance, it can act as our centralized repo while abstracting OS-level duties (specifically, user management) for utilizing SSH as our transport protocol. Gerrit's permissions model is more than adequate for our needs on a per-project basis, but is simple enough to setup and get going. Thus, Gerrit easily satisfied requirement #1 and gave us the extra bang-for-the-buck with its inherent review functionality.

Redmine

Redmine (1.0.1) was easy to modify for our situation and it made the most sense to replicate the central repo as a read-only repository locally available to the Redmine instance. Once the clone completed, the only remaining task was setting up a periodic cronjob for updating (git fetch --all) the repo.

gitflow

gitflow was the answer to requirement #3. One of the beauties of Git (and DVCS in general) is the fundamental capability of determining your own release cycle/phase/management process. In some cases when dealing with a DVCS setup it means there's a lot of rope to hang yourself. Our previous release practice was suffering, from time to time, with 100% consistency. I stumbled on gitflow only after deciding on Gerrit, and it made a lot of sense to embrace it not only for what it provides out of the box (helpful bash scripts) but also for the well defined development convention that it helps to enforce. Actually, it's not that gitflow just helps to enforce process, rather, it eases process implementation. Turns out that its process definition matches, and enhances, what we've already (mostly) been doing. Vincent deserves a heap of credit and has our gratitude.

CI

Hudson/Jenkins (Oracle is being a hoser about this, IMO) has two plugins options:
Gerrit: http://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Plugin
Git: http://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin

Really like the idea of pushing changes to Gerrit fires off CI tasks in Jenkins, then verifies/fails the changeset depending on the results. However, integrating that plugin during the initial migration turned out to be a lower priority. At the very least we simply swapped out the current setup of using Subversion with just the normal Git plugin.

IntelliJ

While I'm in a shell nearly 100% of the time, on occasion it's convenient to have some SCM support in Intellij 10. However, I did run into some issues with merging in IntelliJ and spent some time looking into various merge tools. My emacs blood revolted when I chose the Perforce merge tool over emerge (which I liked a lot better than opendiff, Meld or diffmerge). Thanks to Andy Mcintosh for his tips.

Conclusion


After walking through multiple discussions with several team members, it's been very clear to them the benefits and strengths this setup provides over our current process with Subversion. So as of this post, the first major project (72k LOC) has been migrated. This setup feels right, and it's good to see additional corroboration in the community (thanks, AlBlue).