Skip to main content

5 reasons why I don't like e-readers for programming

As a developer, I probably see things a lot differently than your average Kindle or Nook novel reader. I am much more concerned with the information supplied and rely less on the prose and more on the ability to allow a book to be reviewed by my colleagues. Recently, I bought a book (Advanced CORBA Programming in C++) and read it e-cover-to-e-cover on my smartphone. There were lots of positives which can really be summarized by the convenience in being able to pick up the novel anytime in the convenience of my handheld device. That said, here are 5 reasons why I don't think e-readers are ready for prime time for programming books.


  • They don't allow printing - E-reader companies may balk at the idea of trying to support network printer drivers because they feel that people will be likely to print out an entire book and make copies at will. I find this to be unreasonable, because I feel at most a programmer would want to print out a few code examples or beefy definitions at worst, not entire books. E-readers should allow for a limited subset of printer drivers, or perhaps sell licenses for printing APIs to printer companies (i.e. HP, Canon).


  • No copy-paste - These days, most books come with an accompanying website containing all code examples for users to use. However, this shouldn't be a means to an end when it comes to legally reproducing passages of a novel. What if I want to copy and paste a passage for a conference paper, providing the appropriate citation? What if there are only snippets of code that I want to copy and paste and not entire passages? E-readers and e-reader clients on smartphones and tablets don't even offer the option to copy and paste at all because they don't seem to have this concept of a generic clipboard.


  • Lending options are limited - Typically, I like to discuss a particular book with some of my teammates so that we can collaborate and share comments and ideas in a particular coding book. However, in Nook and Kindle these lending options are very limited, and it shouldn't be necessary to have to force my colleagues to buy a separate copy on their own.


  • Code examples are flawed - Translating code examples from print to E-reader is still not perfect. Though I have not seen the process performed with my own eyes, I find that it is not rigorous enough to double check what happens in the aftermath of a translation to digital format. Translations cause certain operators to be interpreted into something else, code examples appear in various font sizes, and the treatment of code examples as text cause weird hyphenation to occur in unexpected places.


  • Ownership headaches - In July 2009, Amazon, without any warning, deleted copies of 1984 and Animal Farm from the Kindles of particular owners within the US due to the invalid rights of the publisher. The victims received refunds for their copy, but they lost any bookmarks and highlights that they made during reading. This begs me to wonder, who really owns these books? What keeps Amazon or B&N from randomly deleting my copy of a book with all the notes and bookmarks? What if one of these companies is out-competed by the other and goes broke; do the books all get erased from memory forever? These are all issues that owners of paper novels never have to encounter.



Of course, one could make several other arguments for not having an e-reader in general. There is the hassle of having to recharge the e-reader, the possibility that the reader will become damaged through some unfortunate event and rendering it unusable, and all the other nuances that come with replacing a paper format with an electronic piece of equipment.

All things considered, I feel that programming-specific issues as described above regarding e-readers will be rectified. The idea of storing my library of programming books right from my tablet or smartphone is too powerful a concept to ignore: during travel and at dead-times I love the idea of being able to crack open a programming book and learn. Sites like Safari already do an excellent job translating their books to digital, but of course these books are limited to O'Reilly books which may or may not be the best books available. I am optimistic of what lies ahead in terms of resources for programmers, but right now that time is not ripe.

Comments

Popular posts from this blog

Software Design Principles - SOLID

The SOLID software design principles weren't called SOLID while I was in grad school, but the concepts were there in my Object Oriented Design course. They're worth mentioning here, primarily because I think once you start coding and become dangerous, it's one of the best ways to stay organized once you incorporate it into your daily coding routines, and it even changes your way of thinking for the better: https://en.wikipedia.org/wiki/SOLID

The TL;DR guide to git

While in the past I've held a pretty high opinion to using mercurial for version control, the majority of version control these days seems to done in git.  Here were the commands I found most useful to get productive with git right away. # Clone a repository from an origin, i.e. my github MaskingUtils repository git clone git@github.com:caelumvox/masking-utils.git # Add a file after it's been updated to stage it for commit, or add a new file git add filename # Commit the file to local repo git commit # Push the file to the origin so the rest of the team can see it git push # List all locally tracked branches git branch git branch --list # Get a list of all branches from the remote git branch -r # Create branch locally git branch develop # Push the branch to the origin repository to make sure it is tracked there git push --set-upstream origin develop # Pulls latest from all local branches tracked from origin; won't pull non-tracked branches git pull --all # Fetch the branch

AWS Development On A Budget

I was interested in hosting a small portfolio of applications in AWS, but I wanted to keep costs down.  I was willing to maybe host about $30-$40 a month of servers just to showcase some of the applications I was putting together.  Here's what I came up with. The basic capabilities here were: serve up about 6-10 applications that would require some level of web application hosting, database, file storage for larger items, and possibly queuing or email schedule jobs to run periodically to either scrape websites for new data or access APIs regularly These were the services in mind, all out of US-East-1 (Virginia): EC2 instances are pretty cheap.  You can run a t3a.nano for about $3.38 a month, or a t3a.micro for about double that for $6.77.  The more things can run on one of these instances, the better. Lambdas also don't really add up to much if they are scheduled jobs that do not consume large amounts of memory or computing.   The cost of a Lambda run as part of an API gateway