Which eReader should I buy?

I’ve been thinking about getting a device for reading eBooks/PDFs, but the selection of eReaders is so wide and deep right now that I’m not sure which is the best investment. I’ve narrowed the field with a few criteria:

  • The reading area should be no smaller than 6”, preferably 7”+.
  • I don’t really care if the devices uses eInk or an LCD screen – I stare at a computer screen all day, every day, and my eyes are no worse for wear. I don’t read outside very much (sunlight–what’s that?), but I do read at night (typically with a lamp on).
  • A color display might be nice, but for the books I read (technical, literature, philosophy, economics), is really unnecessary.
  • I go back and forth on internet access. I want to be able to purchase books on the fly, but I don’t think I want full browser support because then I will be tempted to surf rather than read. (I do read a lot of blogs, but I want to focus more on books).
  • The device must support bookmarks, marking and annotating passages, full text search etc.
  • Format support is important:
    • The device must have PDF support, and the screen size must be such that two- or three-column PDF formats aren’t out of the question.
    • ePub or Mobi support is required.
    • Text, HTML, and Microsoft Word format support would be nice.
    • Image support (.jpg, .png) would be nice, but won’t be a show stopper.
  • I don’t care about audio support. I have an iPod for that.
  • Weight is a factor; I don’t want to feel like I’m getting a workout when I hold my device.

So far, I have looked seriously at two devices:

The Kindle gets universal praise and has pretty much every feature I want, and it’s also the cheapest eReader at $139 (for the base model). It is very light and feels nice to hold. The eInk display is crisp, but the reading area is only 6”, which means that PDF files with odd formatting may not display correctly. The Kindle lacks a touch screen, which I found slightly annoying when I tried a demo model (my first inclination was to drag my finger vertically across the screen to scroll the text), and user input requires a built-in keyboard. The Barnes and Noble NOOK Color has a slightly bigger viewing area than the Kindle, and it’s color LCD is vibrant and appealing compared to the monochrome eInk display on the Kindle. It is also a touch screen with a virtual keyboard which is much closer to the iPhone experience I am used to. The Nook is actually a trimmed down tablet device – it has a built in browser and support for “NOOKextras”, which are small apps that can be installed. It’s a little over $100 more than the base Kindle device ($249), and is a bit heavier as well. Both Amazon and Barnes and Noble provide large book selections: 810,000 and “over 2 million” respectively (at the time of this writing). I purchase a lot of books through Amazon, but rarely from Barnes and Noble. Most technical publishers that I favor offer PDF/ePub/Mobi versions of their books directly. Finally, a special additional point in favor of the Kindle is that my hero Penn Jillette thinks it is better than the iPad.

Any suggestions?

Special SharePoint is special

I read an article this morning about SharePoint development that is so unbelievably naive it scares me. It scares me because I know that intelligent, motivated business men and women around the world are probably reading this article, nodding their thoughtful heads, and forwarding it to their developers as an informal contract of expectations. So without further ado, I’m going to indulge my inner jadedness and give you my thoughts.

Software Development Times brings us an enlightening piece called Why SharePoint Development is so damn special!, a pretentious exposition on what differentiates SharePoint development from other development disciplines. In the opening paragraphs, the author (Bjorn Furuknap) outlines his argument:

  1. SharePoint developers need to master a range of skills that “make quantum mechanics seem like Spelling 101”
  2. traditional development methods are teh suck
  3. a SharePoint solution may be consumed or changed by *gasp* other developers
  4. SharePoint developers are shooting a moving target, blind-folded, “without knowing what the target looks like, where it is… what type of ammo… to use…, [or whether they] are in the right shooting range

The rest of Furuknap’s article explains each of these points in detail.

SharePoint developers should be NINJAS with l33t skillz

I know and have worked with SharePoint developers, and I realize that SharePoint development requires knowledge that other .NET development disciplines do not. Like any specialization, there are particular libraries, tool kits, SDKs, etc. that a developer must learn to be proficient. I expected Furuknap to enumerate these particular specifics–after all, he states quite clearly that:

“SharePoint development is completely different than other forms of development in that it covers such a wide range of tiers and technologies.” (emphasis mine)

So what is it that makes SharePoint completely different?

  1. “customizing a solution through the Web interface, or out-of-the-box customization”
  2. “understand extensibility through the middle tier”
  3. “utilize scripting and markup languages such as jQuery, JavaScript, XML, XSL, and so on, usually done through tools such as Microsoft’s SharePoint designer”
  4. “the third tier of development where the programmers reside… using tools such as Visual Studio and Notepad”
  5. “all the varieties of .NET”
  6. “XML… [and] the XML dialects that SharePoint uses”
  7. “[the] intricacies of the SharePoint object models, both the server object model and now the client object model”
  8. “[s]ecurity… that SharePoint does… completely differently from anyone else” (sic)
  9. “Web services, both the ASMX and the WCF type”
  10. “Web service standards and definitions”
  11. “non-SharePoint technologies… such as Active Directory and a number of other authentication mechanisms”
  12. “SQL Server”

A pretty impressive list. Except for the fact that most of these skills are requisite in pretty much any .NET web development job. Only the skills specifically billed as SharePoint skills, or SharePoint extensions to other technologies, would differentiate the SharePoint developer from the average ASP.NET developer. This is hardly the “pirates vs. ninjas” smackdown that Furuknap implies.

Martin Fowler, Bob Martin, and (probably) all other Martins should be ignored

There are some truly great minds in software development. Two of my favorites are Martin Fowler and Bob Martin. They’ve been around. They’ve seen software development grow as a discipline, and have observed, documented, lectured, and probably composed interpretive dances to convey objectively demonstrable best practices in the field. One of these practices, considered by many to be an excellent foundation for writing stable yet extensible code, is unit testing. I will not define it here; I assume you know that of which I speak. But apparently, SharePoint developers are a breed apart, and for them, the Old Ways are not applicable.

“…traditional development methods and experience will only get you a fraction of the way. Unit testing, for example, is useful only for the first few hundred lines of code, after which it becomes more of a burden than an asset… Unit testing and mocking is all the rage these days, and for a very good reason. When you are the master of the code, producing perfect code makes all the sense in the world. After all, any code error goes directly back to you, and if you develop your tests right, your code should have no errors. However, to a SharePoint developer, building code that works is just a small part of the puzzle. As I mentioned earlier, we are not the only developers on a SharePoint solution. In fact, we should encourage our users to modify what we make in order to better utilize the adaptability that is SharePoint’s greatest feature. This presents the traditional developer with a nightmare. If you are not in control over the environment into which you deploy code, how can you test whether your code works? You may set up a mock environment that matches the production environment 100%, and within five minutes, some user may completely alter the entire solution, changing the target you try to hit. This is not the worst part, however. Even if your code runs perfectly at the time you deploy it, it also needs to endure the active modification of users throughout its entire lifespan. Your code may depend on a list having a certain set of columns, but users may change that at any time. They may even remove or replace the entire list, and how will your code run then? The difficulty for a SharePoint developer is not just in writing code that runs perfectly once, but that runs perfectly, no matter what happens to the assumptions you’ve made for your code. There’s no way you can design tests that will properly validate your code against every possible change that users can make, and traditional testing becomes rather pointless.”

Now, since you’re familiar with unit testing (right? RIGHT?) you should spot a few obvious fallacies right away. First, how the hell did he determine that “unit testing… is only useful for the first hundred lines of code”? Seriously. Is there a metric for this? Anyone? Second, unit tests are not about producing “perfect code”. Unit tests are about code isolation. They are about determining if code performs as it should ceteris paribus. Code is only “perfect” insofar as it performs according to expectations, e.g. according to the promises implied by its public API. Third, unless you are the lone developer on a project, you are always building code that others will use and will possibly modify. This is in no way unique to SharePoint developers! Unit tests help establish API consistency, precisely so that others can program against, and/or modify code with the confidence that their changes will not cause unintended consequences. Finally, the goal of unit testing and mocking is not to reproduce production environment conditions. Furuknap insists: “If you are not in control over the environment into which you deploy code, how can you test whether your code works?” This is what integration tests are for, Furuknap. This has nothing to do with unit tests. Or maybe we don’t need those either.

Lock ‘n Load

Furuknap’s last point is that, because “SharePoint is such a complex beast” (his words, not mine), coordinating a SharePoint project among several development teams is like “trying to coordinate firing a gun at a target nobody knows the location of, without knowing what gun to fire, and, of course, without even looking.” In his analogy, the target is equivalent to the “task they are trying to accomplish”. Why is SharePoint development this difficult? According to Furuknap, it’s because of the AGILE AXIS of EVIL!

  • “deliver the first line of code before the ink on the contract is dry”
  • pushing the product to “production by the time the contract is put in the envelope”
  • and “by the time the contract is filed in your SharePoint document repository, your client should be on their way to request the next major project”

In other words:

“…because of the wonders of agile expectations (which are good, don’t get me wrong), we now don’t know what our target looks like.”

Instead, he suggests that:

“The solution to all this is thorough planning and design up front. If you know exactly what you want to build before you write your first line of code, you also know the exact output and can communicate that to other teams. Of course, this assumes that the other teams do the same. In short, plan everything ahead and you won’t be surprised… Well, that was the way one developed solutions before agile principles taught us otherwise, also known as the waterfall era.”

What is hilarious about this elevation of Waterfall is a revelatory statement in which Furuknap states the explicit reason that Agilists embrace iterative development over Big Design Up Front.

“Don’t forget: From the time you release your first code to the time the customer tells you what changes they want, everything about your assumptions has changed again, because users have already started working with and relying on your solution… And then they ask us if we can do this any faster…”

Waterfall methodologies are based on the twin premises that a) all business needs, assumptions, processes, etc. can be articulated at the beginning of a project, and b) they will not change for the duration of the project. These assumptions have been challenged by critics of esteemed ilk (Ward Cunningham, the Martins, Kent Beck, Andy Hunt, and others from Olympus) and have been proved wanting. Agile development relies on a tight feedback loop between developers and customers, so that customer expectations can be met as they evolve, not after the fact. The last third of this article is divided into two need-to-know SharePoint technologies with links to additional reading material. The first is the client object model, which Furuknap listed early on as an essential skill for SharePoint development. The second is Microsoft Business Connectivity Services (formerly named Business Data Catalog – what would a Microsoft technology be without multiple names?), which “provides read/write access to external data from line-of-business systems, Web services, databases, and other external systems within Microsoft SharePoint 2010 and Microsoft Office 2010 applications.” This sounds really important, but it failed to make the essentials list, and so leaves me confused and mostly indifferent. Y U NO LIKE SHAREPOINT At this point you may imagine that I have something against SharePoint developers, but that is certainly not true. Although I can’t say the same for our friend Furuknap, who recommends “booking a session with a psychologiest, because you are quite possibly stark raving mad” if you’re an aspiring SharePoint developer. To be fair, although he has no problem arming crazy people and letting them shoot at moving targets, he does advocate a commensurate pay grade for these Wunderkinds. You know, because they are so damn special. :-) SharePoint development is a growing discipline Mr. Furuknap. Don’t spoil it by turning its uniqueness into a license for ignoring the thoughtful wisdom of the last half-century of development.

February Presentation on MONO

I received this message earlier today about a lunch-and-learn opportunity for developers who are interested in the cross-platform .NET CLR implementation, MONO.

I would like to pass something along to the ALT.NET group. On Wed Feb 16 there is a presentation on Mono at the lunch meeting of the SuSE Linux LUG and SNUG (The StL Novell UG). Mono is an Open Source implimentation of the .NET Framework that allows .NET to be run across platforms (ex. MacOS, Linux, Solaris, BSD, etc.). Being open source there is also the ability to get “into the guts” for someone who is REALLY technical. The lunch meeting is a “true users’ group”. There are no salesmen–just us techies. The SuSE Linux LUG is a sig of SLUUG, the St. Louis UNIX users’ group which has been a major techie group in St. Lous for over 15 years. SLUUG has always been a supporter of Open Standards & Open Systems, i.e. resist vendor lockins and find the best solutions. The joint lunch meeting with SNUG, the Novell UG, started after Novell acquired SuSE and used it for its core technology. Novell is also the major sponsor of the MONO project. The SuSE/SNUG meeting is monthly and MONO is the topic for February. We hold it at Bandana’s BBQ. There is no membership or attendance charge. We are just happy to have more tech people to chat with. I thought there may be a number of ALT.NET people who would be interested in the MONO presentation. I’m also interested in hearing from anyone who has experience with MONO. If anyone DOES have MONO experience I would LOVE to hear from them! The Feb 16. lunch will be listed in http://www.sluug.org/resources/calendar. That has been a reference for all the techie meetings in St. Louis for some time.

If you would like more information about this event, please leave a comment on this post and I will send you additional information.

Collection comprehension

F# (and Ruby, I am told) has a nice little syntactic feature called “comprehension” which allows developers to create lists of numbers or characters by specifying a range to be “expanded”, like this: [code lang=”fsharp”] let numbers = [0 .. 9] let alpha = [‘A’ .. ‘Z’] let everyOtherNumber = [0 .. 2 .. 16] printfn “%A” numbers // [0; 1; 2; 3; 4; 5; 6; 7; 8; 9] printfn “%A” alpha // [‘A’; ‘B’; ‘C’; … ‘X’; ‘Y’; ‘Z’] printfn “%A” everyOtherNumber // [0; 2; 4; 6; 8; 10; 12; 14; 16] [/code] Today I’ve been working on an e-commerce project where I need to build a list of months, so I started looking for a comprehension equivalent in C# and found this less elegant but adequate (for my purposes) method on Enumerable that does something similar: [code lang=”csharp”] IEnumerable months = Enumerable.Range(1, 12); [/code] There are a few problems with Range, however:

  1. the signature is (int start, int count) instead of (int start, int end)
  2. Range only accepts and returns integers
  3. Range does not provide a means to “step” values

If anyone knows a better comprehension alternative in C#, please let me know!

Books for Christmas

Santa was very good to me this year, expanding my bookshelf by several awesome volumes. 2010 Christmas Books

Getting a Clue with F#

In an attempt to bolster my geek-fu and partially just out of curiosity, I’ve been learning the Microsoft functional programming language F#. It has been simultaneously frustrating and fun, as I struggle to bend my mind around functional concepts that are alien in the imperative world from which I hail. As a fun project, I decided to implement a guessing strategy for the popular board game Clue, as proposed by Wired magazine in a recent article about teen “mathletes”:

The Task: Dr. Black has been murdered. Detective Jill must determine the murderer, crime scene, and weapon. There are six possible murderers (numbered 1 through 6, Professor Plum to Mrs. Peacock), 10 locations (1 through 10, ballroom to cellar), and six weapons (1 through 6, lead pipe to spanner). Detective Jill tries to guess the correct combination (there are 360 possibilities). Each guess is a theory. She asks her assistant, Jack, to confirm or refute each theory. When Jack refutes a theory, he reports that one of the guesses—murderer, location, or weapon—is wrong. The contestants are tasked with implementing a procedure that plays the role of Detective Jill. A brute-force program that tests all 360 theories earns a mere 50 points. An efficient program that tests no more than 20 theories earns an additional 50.

While I’m sure that my program is far from efficient, it was a good exercise for assembling the things I’ve been learning from the trivial examples in books and on the web. It isn’t the shortest solution, but it would have earned the bonus 50 points because for any given theory, the program will only need to guess a maximum of ten times. The way I limit guesses is by walking through each combination of guesses in the form:

  • guess1: suspect1, weapon1, room1
  • guess2: suspect2, weapon2, room2 (we’ve identified the suspect)
  • guess3: suspect2, weapon3, room3 (we’ve identified the weapon)
  • guess4: suspect2, weapon3, room4
  • (etc.)

When the suspect, weapon, or room equals the suspect, weapon, or room of the theory, they “stick” and are used in each subsequent guess (see lines 38 and 25). Since there are more rooms (10) than suspects (6) or weapons (6), the number of rooms becomes the limiting factor on possible guesses. If you’re a functional programmer, I’d love to hear your comments, suggestions, and criticisms, or maybe an implementation example in your language of choice. EDIT: Just for clarity, in the code below “theory” represents the actual correct answer (I misread the instructions), while “guess” represents the current combination the program is testing. So when guess = theory, the program stops testing guesses. [sourcecode language=”fsharp” highlight=”25,38”] module Clue open System //http://en.wikipedia.org/wiki/Cluedo let guess theory = let suspects = [| “Miss Scarlett”; “Colonel Mustard”; “Mrs. White”; “The Reverend Green”; “Mrs. Peacock”; “Professor Plum” |] let weapons = [| “Dagger”; “Candlestick”; “Revolver”; “Rope”; “Lead Pipe”; “Spanner” |] let rooms = [| “Kitchen”; “Ballroom”; “Conservatory”; “Dining Room”; “Cellar”; “Billiard Room”; “Library”; “Lounge”; “Hall”; “Study” |] let indexOf anArray anElement = Array.findIndex (fun e -> e = anElement) anArray let indicesOf aTheory = let (s, w, r) = aTheory ((indexOf suspects s), (indexOf weapons w), (indexOf rooms r)) let next g t = if g <> t then g + 1 else t let show guess = let s, w, r = guess printfn “%s with the %s in the %s” suspects.[s] weapons.[w] rooms.[r] let rec test guess theory = show guess if guess = theory then printfn “correct” else let (gs, gw, gr) = guess let (ts, tw, tr) = theory let newGuess = ((next gs ts), (next gw tw), (next gr tr)) test newGuess theory test (0, 0, 0) (indicesOf theory) //end guess let main = printfn “——————–” let theory1 = (“Mrs. White”, “Rope”, “Kitchen”) guess theory1 printfn “——————–” let theory2 = (“Professor Plum”, “Candlestick”, “Lounge”); guess theory2 printfn “——————–” let theory3 = (“The Reverend Green”, “Spanner”, “Ballroom”); guess theory3 printfn “——————–” Console.ReadKey(true) |> ignore //end main main [/sourcecode]

The One True Browser

For a long time, I believed that Firefox was the One True Browser. And for a long time it was. The competition consisted of IE, Opera, Chrome, and Safari. IE is… well, all web developers know that Microsoft has spent the last few revisions of IE making up for the sins of IE6; sins which have provoked the ire of web developers (myself included) for many years. IE7 supported basic web development tools, but no version of IE to date has supported cross-computer synchronization, and the user interface of IE has always been a pain. Opera has always been fast, but was late to the game with good developer extensions, and has always had some rendering “quirks”. Safari for Windows has traditionally been clunky and slow, which detracts from the experience even though Webkit is a very nice rendering engine. Like Opera, it also lacked good developer extensions at launch. Chrome was promising–very fast, lightweight, fault tolerant, and used the Webkit rendering engine, but its extension pool was initially thin. Firefox has always been a memory hog, but of all browsers it had the most robust developer tools available and a decent rendering engine, which were my primary needs. The FoxMarks/XMarks extension provided browser synchronization between computers, and now that functionality is supported with a Mozilla plugin (I believe this will be a native feature of Firefox 4). A few months ago I started using Chrome at work for a different browsing experience, and it has grown on me. I have been exploring Chrome extensions, which, much to my delight, now include tools that are roughly equivalent to the developer tools I have been using in Firefox. Chrome also supports native bookmark, browsing history, form data, and extension synchronization across computers. It is faster than any other browser I have tried (including IE9 beta), and is just pleasant to use. I don’t know if Firefox 4 will reclaim the coveted title, or if IE9 will actually redeem Microsoft’s tarnished brand. But I hereby announce that Chrome is now the One True Browser. For what that’s worth.