Scott Hanselman

There's a great discussion going on over at Jeff Atwood's blog about Coding Smaller, modularizing properly, and refactoring often. In the comments, Jae wishes that more apps were "modularized properly," and I wholly agree.

He/she says:

I think a lot of projects are dived into too willy-nilly (especially by neophyte/ novice/ hobbyist programmers) with no pre-planning of what the thing should do and how to logically code it. [Jae]

I'll use this comment, lifted from Jeff's post, to kick of discussion here. I think that pre-planning is part of it, but there's only so much Big Design Up Front (BDUF) you can do. More and more, as I work on larger and larger projects (and product suites) I realize that refactoring effectively and often is as or more valuable as pre-planning.

There's lots of create Refactoring Tools out there, certainly Resharper and Refactor Pro leap to mind, that can help you improve your code, and to some extent, your design, with their dozens of refactorings. Both also include some code analysis tools that illustrate hotspots in your files.

<confession>
At my company, sometimes I feel less like Chief Architect, and more like Chief Debugger or Chief Code Reader. Sometimes I get to caught up in trying to read code in order to understand the big picture. This is my own failing, as I often try to use a microscope when I need a telescope.
</confession>

While trying to improve design, manage dependencies and coupling within our product suite, I've been leaning more and more on static analysis tools. Some tools are pretty UI-free, like libcheck, a tool for managing the churn of the public "surface area" of a group (or framework) of assemblies.

There's lots of tools out there for analysis of code, for many languages, all with good science behind them. I remember doing some static analysis on C++ code back in the day, but until .NET's rich meta data, doing this kind of analysis was more a parsing exercise that created Excel spreadsheets of numbers - the data just wasn't very accessible. That, combined with the fact that a lot of .NET developers now never worked in a language before .NET that enabled real solid analysis (VBScript/ASP, VB, and I don't remember a lot of MFC/C++ folks doing analysis like this) means that perhaps a majority of .NET developers haven't been introduced to the power of tools like this.

I've been spending time with NDepend more and more lately. I used it a while back when it first came out, but version 2 is out and it's giving me insight into my applications that I haven't had before.

One of the problems with applications like NDepend and static analysis apps is that they are couched in the complex or "inaccessible" language of Computer Science. Many programmers haven't gone through a formal "CompSci" program and aren't interested in an analysis application with a steep learning curve.

Like PowerShell, the first 10 minutes of NDepend is the hardest. It has to click first. There's the whole "what the hell am I looking at" process, often followed by the "screw this" declaration, followed by a quick uninstallation and a sense of "what happened."

I'm not going to even attempt to try to improve on, or replace, the good documentation that's already up on the NDepend site. One of the things that NDepend's site has lots of is screencasts, do check them out.

What I'd like to do is try to introduce some of the basics of the kinds of analyses that are possible to the average programmer or the architect who hasn't considered this kind of analysis as an important part of the development process. Additionally, I know that many of you are using FxCop as a code analysis tool. I think that NDepend intersects FxCop in some ways, but presents the data in a totally different way, and allows you to drill in so much more deeply.

I can't use Corillian's software for my example here, so I'll use DasBlog, an ASP.NET blogging engine with which I have some association, instead. As seen in the picture below, you startup the NDepend Project application and either point it at your Visual Studio Solution, or just add your assemblies automatically. Then you save the NDepend Project as an XML file, and hit the "Play" button (the green arrow pointing to the right) and NDepend launches it's console app that chews for a while.

Next, you can either view an HTML Report - you can run the reports as often as you like and NDepend will keep a history of the reports. Using a static analysis tool can be confusing because it tells you SO much information all at once...trying to sip from the fire hose can be a challenge. 

Let's start by looking at the dependency diagram that was generated by the report. These are easy to read when there is a small number of assemblies. Those of you who use Reflector Add-Ins will recognize the library style as Peli's - in fact NDepend uses the same graphics library.

This graph is really the simplest thing that NDepend can tell you - it just scratches the surface of what this tool can do. We can learn a few important things that we may or may not have known (I didn't really grok at least) about our application. 

Let's explore, for this example, the Custom Macro facilities in DasBlog and if there are design problems.

Note the "FooMacroPlugin" - it's the sample plugin that shows how to write DasBlog Custom Macros. Note that it depends on two assemblies. This exposes very clearly a lameness in the DasBlog custom Macro model - largely my fault - in that it requires a reference to two different assemblies, but Web.Core needs Runtime anyway. We can also see later that it uses concrete classes rather than Interfaces, so it's, frankly, a plugin model with problems. If DasBlog had a formal Interface assembly with defined interfaces for interacting with the system we would see different linkage.

Now that we know that a custom macro links to to different assemblies, let's take a look at exactly how linked the Macro dll is to the rest of the system. We open up Visual NDepend and are barraged with a LOT of information. This is a crazy busy interface, but in that is a great deal of power. The interface is by and large modeless, and clicking in one area changes values in all the others.

In this screenshot I've clicked on the intersection in the Dependency Matrix of the FooMacroPlugin and the Web.Core assembly. Note in the lower left corner there's Plain English generated telling me "1 method of the assembly FooMacroPlugin" is using 1 member of Web.Core." 

Looking along the horizontal I can see the number 1, then 2, indicating that Foomacro is using 1 method of the Core and 2 within the RunTime.  (The axis can be opened up by clicking the + sign to see more text) Now I'm getting a better idea of how linked my Macros are with my other two Assemblies.

I can left-click on the number 2 to see what two methods I'm using in the Runtime. A "boxes and arrows" diagram is generated telling me that my Macros (there are two in FooMacroPlugin) are calling into a property on the an Entry (a blog Entry) and getting the count of an EntryCollection.

Now I'm starting to see what the impact would be if I were to refactor the Macro plugin mechanism in DasBlog, and I would repeat this analysis on a more complex Custom Macro, probably from the community. Even better, I could drop in EVERY custom Macro I could find to get a really 20,000 foot view - a wide perspective - on how Macros are being used...without reading the code.

NDepend really shines in it's use of CQL - Code Query Language - an NDepend invention, but public spec. Basically it's SQL for Reflection. I can write queries using this SQL-like syntax to ask questions about assemblies, types, methods, whatever within my solution. Here's some examples:

Detect Unused Methods:

WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE MethodCa == 0 AND !IsPublic AND !IsEntryPoint AND !IsExplicitInterfaceImpl AND !IsClassConstructor AND !IsFinalizer

I ran this CQL query without the "TOP 10" qualifier on some code on one project and found 292 methods that weren't being used.

Detect Overly Complicated Methods

WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE
( NbILInstructions > 200 OR
ILCyclomaticComplexity > 50 OR
NbParameters > 5 OR
NbVariables > 8)
AND
// Here is a way to avoid to take account of generated methods.
// Another way would be to use the SELECT METHODS FROM or SELECT METHODS OUT OF facilities.
!( NameLike "InitializeComponent" OR NameLike "Generated")

Here's a great one. This gives methods that have over 200 instructions or a complexity of over 50 (REALLY complex), or have too many variables or parameters, but includes a trick to exclude both generated code and that crap that the WinForms designer creates in InitializeComponent. 

These are just some of the dozens of rules and examples that it includes. I personally find writing this kind of CQL to be WAY more intuitive and flexible than writing FxCop rules/plugins.

If you select any CQL query, it runs instantly as you select it and the Tree Map at the top updates automatically, lighting up the result of the query. The toolbox in the upper left corner shows the result of the query in a table. You can then click on any of the methods and NDepend will open Visual Studio and take you there.

The TreeMap in the diagram below acts like a "heat map" showing the hot spots discovered. The blue area on the left side of the map shows the methods that came back as a result of my query. Above the TreeMap is a combo box that indicates what metric the TreeMap is using to determine the size of the squares. In this screen shot I'm using # of IL instructions so the larger the square, the more instructions. I could use lines of code, or cyclomatic complexity, or whatever to find the "fat" parts of my application.

CQL queries can these can include "WARN" at the beginning so they can be used within a Continuous Integration build. NDepend includes a NAnt Task and an MSBUILD Task, as well as stylesheets and plugins for Cruise Control.NET so I can add constraints to keep our applications in line as changes are checked in. The rules (the CQL) is really easy to read and the editor includes intellisense. 

Another nice diagram that is produced by NDepend is the chart of Abstractness vs. Instability. It says a lot, and it's easy to take the data as a value judgement directed towards your code. As if your assembly appears in Red, you're a Bad Person.

The Y-axis indicates how Abstract your assembly is - that is, is it able to be extended without recompile. The X-axis is instability. Now, "instability" carries a value judgement in itself. They aren't saying that stable is good and instable isn't. Stable means that the public surface area of your assemblies "can't" change because there are a lot of assemblies that are dependent on it. An instable assembly has fewer, or no, dependant assemblies upstream. Take a look at Page 8 of this document on Principles of Package Design. A number between 0 and 1 is assigned for each axis based on those equations and your assembly is plotted accordingly.

Here's the trick in reading the chart:

• If an assembly is very stable (that is, lots of folks depend on it) and it's not extensible (no abstract classes, no virtuals, etc) then you're in the lower-left quadrant of the chart in the well-named Zone of Pain.
• If an assembly is very abstract, very extensible, but no one depends on it (it's not really being used) then it moves towards the Zone of Uselessness.

Notice how many of the assemblies are in the Zone of Pain? So many, in fact, that you can't even read the words Zone of Pain any more. If you read the assembly names, you'll see that the ones that have made their way over into that portion of the chart are most of the 3rd party assemblies we use. This makes sense because these assemblies are Stable - lots of folks depend on them - and they were designed for some specific function, not for extensibility. Over there are things like the SharpZip lib, the FreeTextBox, and SubText's Akismet library. Is it bad that there are libraries over there? It's less something to panic about then it is something to have increased awareness about. Charts like this can give you a lot of insight into how hard it would be to replace a 3rd party component if you needed, or just to extend one. Here's a screencast on doing an impact analysis on replacing a 3rd party component within NDepend itself.

We can also note that both the DasBlog Runtime and Web.Core assemblies are edging their way over into the Zone of Pain. That implies that more and more we are depending on those assemblies in unhealthy ways because they aren't well-factored for use by both the application itself and the Plugins. All this equals opportunity to possibly modify our design.

I will point out, just as a bit of interest, that when Patrick and I ran this same chart on Corillian's Voyager SDK - an SDK that has had more eyes on it, perhaps, than DasBlog - we had only one assembly in the "Zone of Pain" and none in the Zone of Uselessness. We felt OK about that.

Wrap up

I'm really just touching on the beginnings over what a good static analysis tool can do. But you have to integrate a tool like this not only into your life, but into your build process and your company's software development process. You can't just drop the tool into your word and expect instant results. If you have a fairly mature process - agile or not - and developers who are enthusiastic to this kind of very hard-numbers input, you can begin by integrating this data into your existing code reviews. Start up a working group or study group to talk about what the information means - you don't even need to take action, just talk amongst peers. After your team starts to get a sense of where the metrics are not only taking them, but when to ignore the metrics and why, then you can start adding custom queries and warnings and integrating them into your continuous build.

NOTE: One last thing, to be clear. I don't know the guy from NDepend personally. I did chat him on Skype to answer some of my more esoteric questions. I'm not paid for being a reviewer of this product, in this case I'm just a massive FanBoy, much like I am about CodeRush. Neither of them has ever given me a penny.

I'm writing this because I want folks to think about their designs, not just up front, but all through the design...before, during, after. Think about complexity, think about supportability. Realize that your code, your app, your suite is very likely more complex than can be held in your head, and if you take the time - both in your day, and scheduled into your project - to review your design, truly understand what's going on, and use your analysis to make substantive changes to improve the quality of your company's code. Tools like NDepend or one of the many code analysis tools out there like Lattix, can really give you a great deal of insight and perspective on how your applications fit together, if you just take a few hours to get over the initial "hump of difficulty."

Once I realized the depth and breadth of the information I was looking at it, I was like a kid in a candy shop. It was the first time I discovered JetBrains dotTrace profiler - "and now I can see."

Go check out NDepend. There is a FREE/ACADEMIC version that you can try out and use on your Open Source apps, and the full Pro Version is about US$400 with steep discounts if you buy in quantity. Most companies would only need 1 or 2 copies for a lead "code analyst" I think, so it's reasonably priced. Run it on your companies application and show your boss a few graphs - and explain what he's looking at - and I'm sure he or she will give you the money. ;) I recommend trying to stay out of the Zone of Pain.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

My fifty-first podcast is up. This one talks about Static Code Analysis, some definitions and descriptions of coupling and a discussion of NDepend, a .NET static code analysis tool that I'm totally digging. Also, after listening, check out my review of NDepend as well.

ACTION: Please vote for us on Podcast Alley!

Links from the Show

NDepend (m0z)
Code Query Language (CQL) Specification (m11)
Princples of Package Design PDF (m12)
NDepend Screencast Tutorials (m10)

Subscribe:

Do also remember the archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Our sponsors are /n software and Telerik.

Telerik is a new sponsor. Check out their UI Suite of controls for ASP.NET. It's very hardcore stuff. One of the things I appreciate about Telerik is their commitment to completeness. For example, they have a page about their Right-to-Left support while some vendors have zero support, or don't bother testing. They also are committed to XHTML compliance and publish their roadmap. It's nice when your controls vendor is very transparent.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

• The basic MP3 feed is here, and the iPod friendly one is here. There's a number of other ways you can get it (streaming, straight download, etc) that are all up on the site just below the fold. I use iTunes, myself, to listen to most podcasts, but I also use FeedDemon and it's built in support.
  • Some other clients are Doppler (also suppose Windows CE), FireAnt, Nimiq, and PrimeTime Podcast.
• Note that for now, because of bandwidth constraints, the feeds always have just the current show. If you want to get an old show (and because many Podcasting Clients aren't smart enough to not download the file more than once) you can always find them at http://www.hanselminutes.com.
• I have, and will, also include the enclosures to this feed you're reading, so if you're already subscribed to ComputerZen and you're not interested in cluttering your life with another feed, you have the choice to get the 'cast as well.
• If there's a topic you'd like to hear, perhaps one that is better spoken than presented on a blog, or a great tool you can't live without, contact me and I'll get it in the queue!

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Run, don't walk, and sign up for the Windows Home Server Beta 2. The Home Server Forum is here. I'll blog a lot more about this rockin' sweet server soon. I've been deep into it for a while now and it's truly yummy. It's changed my digital life more than Vista, frankly. At least, so far.

For now check out the SuperSite Preview and enjoy this representative screenshot. You can also check out the Home Server Blog.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Big news over here at my company, Corillian. We're being purchased by CheckFree. This is pretty exciting from a technology company, with the challenge being to combine the software services of two companies.

I'm not a business person, nor is this blog about business, so I'll leave the analysis to the analysts. But from a technology perspective this is a very cool opportunity to combine and integrate the world's (IMHO) leading Banking Platform with the world's leading BillPay Platform. I'm stoked for the future.

CheckFree Announces Agreement to Acquire Corillian Corporation

Combination Will Enhance Online Banking, Billing and Payment Experience for Consumers and Small Businesses, and Deliver Greater Flexibility for Financial Institutions

ATLANTA and PORTLAND, Ore., Feb 14, 2007 /PRNewswire-FirstCall via COMTEX News Network/ -- CheckFree Corporation (Nasdaq: CKFR) today announced it has entered into a definitive agreement to purchase Corillian Corporation (Nasdaq: CORI), the leading provider of Internet banking software and services. Under the terms of the agreement, CheckFree will acquire all of the outstanding shares of Corillian at a price of $5.15 per share, for a total purchase price of approximately $245 million on a fully diluted basis.

The acquisition will bring together Corillian's widely used online banking platform and complementary suite of financial applications, and CheckFree's industry-leading electronic billing and payment and online transaction services, which include unparalleled electronic billing content and a highly efficient infrastructure that connects banks, billers and millions of consumers. Together, CheckFree and Corillian will be well-positioned to help financial institutions optimize the online channel and drive increased usage of electronic billing and payment.

<snip presidental and ceo quotes>

Corillian supports more than 30 of the top 100 U.S. banks and 21 of the top 100 U.S. credit unions with its online financial services strategy. CheckFree processes more than one billion transactions annually and distributes more than 18 million e-bills per month through more than 2,000 financial services sites.

The proposed acquisition is subject to regulatory review, Corillian shareholder approval, and other customary closing conditions, and is expected to close on or about June 1, 2007. CheckFree will finance the transaction with a combination of existing cash balances and revolving debt, although there are no financing contingencies in the merger agreement. CheckFree expects the transaction to be dilutive to CheckFree's GAAP earnings per share in the current fiscal year (ending June 30, 2007) and in 2008, and modestly dilutive to underlying earnings per share in the current fiscal year and in fiscal 2008. The company plans to share specific financial details when the transaction closes.

Conference Call

CheckFree will broadcast a conference call at 11 a.m. EST today to discuss the agreement. Participants should dial 1-877-232-1067 any time after 10:45 a.m. EST and ask for the CheckFree conference call. The live conference call will be accessible through the Investor Center section of the CheckFree website at http://www.checkfreecorp.com. A digital replay of the call will be available on the CheckFree website after 1 p.m. EST.

The Next Step begins...wish us all luck!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

A friend who has 10 Sony Readers (don't ask) finally relented and loaned me one for the month so I could finally get some serious hands-on time. I'd spent minutes with it before, but this time I'm using it in all the places I ordinarily use books...reading in bed, etc, as well as trying it in places where I wish I had a book, but the stack I'd want to carry would be too unwieldy.

Since I'm a techie, I've got a folder on my desktop called "Stuff to Read" where I put all the PDFs that I always mean to get to. I usually read them on long plane flights, except reading on the laptop on a plane is so unsatisfying and lasts only a few hours until the laptop battery dies.

I almost thought I was screwed when I started installing the Sony Connect software because halfway through the installation on Vista it starts rolling back. I looked in the Sony Support site and it said "Vista support for the Sony Reader is planned." However, I noticed in the forums at MobileRead that the software had updated itself yesterday. Kind of a bummer for me as I couldn't update software I couldn't install. Some digging however got me to this other support page in a totally different section of the Sony Site that has the download links for the Sony Reader Connect Software and Firmware.

This firmware update brings the Reader up to 1.0.02.01300 and adds these fixes:

• Longer Battery life during audio playback
• Faster transfer speeds when using 4GB or larger Memory Stick® media
• Improved handling of white bands on the audio playback screen

Here's my original 15 minute impressions in italics, along side my update impressions after living with and using the device.

• It's very light and very comfortable. It has a nice flip around case and reminds me of a larger Palm V - to this day still Palm's most elegant PDA, IMHO.
  • Still true. It's very comfortable to hold. The size is really perfect. It could be a smidge thinner, but any more and it'd feel flimsy. I do wish the screen was larger - meaning I'd make the bezel smaller...make the screen go closer to the edge.
• There's too many buttons. There's ten 0-9 buttons that are multi-purpose (multi-purpose buttons are mistake cop-out number one in good design, IMHO). They are used to access the internal menus by numbered item, but their primary function is to quick jump a percentage of the way into the book. So pressing 5 gets you 50% of the way into the book. There's no way to go directly to a page that I could see.
  • Yes, the 10 numbered buttons are ridiculous. A touch sensitive slider would have been a much better metaphor.
• There's multiple ways to turn the page, and they are both on the left side of the reader. The two buttons on the left bezel while oriented up/down, are actually left/right page turning buttons. I think it'd have been more thoughtful and innovative to just touch a long line on the far left or far right bezel to turn the page.
  • This is my #1 on going irritant with the device. Now, in fairness, you'll just pick a page turning technique - one of the three - and use it, but for me, the very existence of the other techniques shows a shotgun approach to industrial design. This is not Sony's best design. At all.
• The memory card slot supports both Memory Sticks and SD Cards - choice is good.
  • Yes, this rocks, as I have both cards lying around the house.
• The lower right corner features a joystick-like, sigh, multifunction, nubbin. It's a little confusing because I assumed that the page-turning interface would double as the main interaction element for the utility UI.
  • I could see where a joystick/nubbin would be a good idea for a multi-function devices, but even though this thing plays MP3's, it's called the Sony Reader. It's a reader. Adding a multi-functional interface metaphor like a joystick is a User Experience cop-out. The interface should be minimal - like a book, natch - and specific.
• The screen, the screen. It's all about the screen. It's eInk. It's not an LED - that's important to note. It's 170 DPI with four levels of gray, versus 96 DPI (or possibly 120 DPI) on a laptop or PDA screen. The battery is used only to change the configuration of the screen i.e. you only use power when turning the page.
  • The screen has a refresh of about 1000ms, and rarely, but it happens, you'll see a ghost of the previous screen because the "turn" didn't completely "take." However, when it's not turning, it's amazing. It really is. It's TOTALLY comfortable to read. I have read a 600 page book on it and it didn't hurt my eyes.
• You can apparently read RSS feeds on it as well, downloadable via USB. Interestingly, RSS might be the killer app for this Reader, rather than books.
  • Yep, it was too good to be true. Instead of being able to subscribe to any RSS feed, you're only allowed to subscribe to the 12 blogs they've got partnerships with, so basically Slate, Engadget, the usual suspect. Wow. That's so lame it's really hard to express.
• It also has volume buttons and headphones so you can use it as an audiobook reader or MP3 Player. This also allows you to read while listening to background music.
  • This seems like a good idea, and the audio on this thing is garbage. It doesn't support Audible (which Rocks by itself, by the way) and playing MP3's has a hiss in the background. Why bother I say.
• The guy at Borders said they haven't had to change the batteries on the demo model ever. They say 7500 page turns on a single battery.
  • If you're not playing music the battery life is obscene. I'm going to take it on a week-long trip and see if it'll last the whole time. I suspect it will.
• There's 3 font sizes...each is comfortable, even the smallest, but I'm a big font guy so I think I'd have trouble committing to a size.
  • I'm still having trouble committing to a font size. I feel like I'm reading a children's book when the font size is so big, but when the font is big, it's very comfortable. I'm mostly using the small size which is comparable to a regular paperback's font.

Here's the saddest part. The Desktop Connect Reader software is so profoundly bad, so poorly designed, so truly evil that there are not word to full express the breadth and depths of its unspeakable lameness.

• It tries to be iTunes. I know iTunes. Connect Reader is no iTunes.
• It kind of looks like Windows Executive. Remember that?
• The "browser" area doesn't use a known Browser Renderer (IE, Gecko) but rather some internal Sony Voodoo. What do you care? It's not accessible via the keyboard. That means while you can Tab between Text Fields, you can't access drop downs without the mouse. Yikes. Not only is that jarring as you try to fill a field out, but it makes the process nigh-impossible for non-mouse using folks.
• Drag and drop is partially implemented. Partially meaning I could only get one scenario to work, and that was dragging files from the Library node to the Sony Reader node in the tree. You get a helpful international NO symbol if you try to drag files from your hard drive to the Sony Reader or from the file system to the Pictures or Books nodes. 
  • Purchased content isn't automatically copied to your Sony Reader, you have to manually drag it, and again, only to a single node in the tree.
• One thing that isn't that bad is the PDF support. You just drag a PDF into the Library node, then AGAIN to the Reader from the Library, and you're set. At least that works. There is rumor that PDFs over 1000 pages have problems, but I personally haven't any to test. Most A4 or 8.5x11" PDFs, however, have very small text on the 6" screen, so you need to either resize the text with a PDF editor, or rotate the Reader's screen and view the pages one-half at a time. It's not ideal, but it's passable. I would expect I'd have to come up with a better resizing strategy...however it's largely dependant on the way the publisher created the eBook.
  • For example, I tried to read 37Signals "Getting Real" PDF, a fine book to be sure. However, they encoded it as a paperback sized book living in an 8x11 PDF shell. The book is in bordered areas on the pages. This unfortunate choice in formatting made the book totally unreadable in portrait mode, and kind of small in landscape mode.
  • Therefore, since the quality of PDFs out there is also dodgy, I'd have to say that this device and its associated software isn't even clever enough to be a good PDF reader.

Is it worth $300? If you're constantly traveling, always moving and like to bring books with you, possibly. I always want to have 4-5 books with me, and often don't bring them because of space. I ran out of books while in Tanzania recently after only two weeks.

Other than that specific problem - that of space - and the cool factor, are books really that much of a hassle? Maybe large technical books and college textbooks, but I suspect that while University-level books are the right problem to solve, that industry would never give up on their lucrative dead-tree process without a hearty push. If this reader would $150, it'd be a no-brainer, but it's not.

Now, forgetting about this specific product for a second, let's talk about eInk.

This screen must be wicked expensive because I don't understand why we don't see eInk in more devices.

The simplified idea is that you've got a layer of tiny "beads" filled with liquid. In these beads are little color chips of pigment, white and black. The white chips are positively charged, the black ones, negative.

They are inside these capsules that are sandwiched in between two charged transparent plates. The plates are addressable such that each microcapsule can act as a "pixel" or "subpixel" (in two passes) for high resolution display.

It's amazing. The best description of an eInk screen I can give without you actually seeing it is this:

Have you ever been to a furniture store where they have fake plastic computers and TVs on the desks? From far away you think it's real, but by the time you get close, it's clear that the fake image of Word or Excel is printed on the fake computer monitor. It's too crisp, it's got a flat sheen, rather than the gloss of a CRT or the backlight of an LCD. The Sony Reader eInk screen is like that, it's so clear, it looks printed, static, fake.

There's no backlight, it's super-high resolution (you can barely see the pixels, and you REALLY have to want to see them) and it's totally flat. Additionally, the viewing angle is virtually 180 degrees. It's damn-near paper. The only think that's "off" about it is the full second it takes to "turn" the page. Otherwise, eInk is brilliant.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By