Category Archives: Reviews

Fuji X-T1 First Impressions

The new Fuji X-T1 is a camera  a lot of people have been waiting for. I’ve been a dedicated Nikon SLR user for the past six or seven years, moving from a D300 to a D600 over the years to finally get that full frame quality. But I’ve been practicing photography for over 30 years. My first serious camera was an Olympus OM-2, and my camera before going digital was a Nikon FM-3A. So I remember when SLRs were light, reliable traveling companions, not the bloated burdens they have grown to become.

Four years ago I speculated on what would be my ultimate Nikon camera. Apparently, Nikon didn’t read it, but I’m guessing Fuji did, because the new X-T1 comes pretty close to my definition of a dream camera.

I’d been waiting for my Amazon pre-order to show up, but decided to call my favorite local camera store, Competitive Camera, to see if they had gotten any in stock. As luck would have it, they actually did, so I made the trek down to Dallas to pick up one of the last two they had.

I’ve had an afternoon to shoot with it, so I can give some real world impressions. I’m not a professional photographer. I’m just a dedicated amateur who takes a lot of pictures of my rapidly growing daughter. But I have handled a lot of cameras over the last three decades.

My first impression was “Holy Crap!” The X-T1 feels like a classic SLR. It has a nice heft to it, but not too heavy. It is very reminiscent of the Nikon FM-3A. The dials have a solid, reliable feel to them, and I’m taking a lot of joy in experiencing a real aperture ring again.

I picked up the X-T1 with Fuji’s 23mm f/1.4 lens to serve as my general purpose, walkabout lens. We headed up the Shops at Legacy this evening to walk around the lake and eat at one of the great restaurants, so it was a good chance to try out the camera.

First, a few pictures, and then some deeper thoughts on the X-T1. All these are unedited, other than cropping to 4×5 and shrinking down to size:

Zoe hamming it up
The budding photographer taking a picture of the turtle
The budding photographer taking a picture of the turtle
Stairs at the lake
Stairs at the lake
ISO 3200 at f/1.4 ambient light
ISO 3200 at f/1.4 ambient light



  1. The camera feels even smaller than it looks. I found it comfortable to hold for quick shots, but I would not want to be shooting non-stop for an hour with it.
  2. Image quality is great. I’m not printing gallery prints, but I do care about good color depth and pleasing tone. I shot jpeg mostly with the Astia film simulation, with a few shots in Velvia. The light was too flat to get good value of the Velvia mode, so I’m looking forward to trying it again.
  3. Autofocus was extremely fast and the face detection worked really well. I found it comparable to my D600 for speed.
  4. I don’t like the back “joy pad” area. It is slightly inset, making it difficult for my larger fingers to manipulate. There will be zero chance I will accidentally press one of those buttons.
  5. I thought the fold-out LCD screen was going to be gimmicky, but it is actually pretty cool. I can see using it for low-level shots.
  6. I usually want to shoot EVF only, but if you push the Q button in the EVF-only display mode, the Q menu only shows up in the EVF and not on the LCD. If I’m fiddling with the Q menu options, I want it to always show on the LCD, regardless of the display mode. Hopefully Fuji provides this option down the road.

The biggie is the EVF. Yes, it is large, bright and beautiful, but coming from a long history of high-quality optical viewfinders, I call it passable, at best. It has a high-quality camcorder feeling to it, which I personally don’t like, but am willing to tolerate for everything else the X-T1 brings to the table.

The biggest reason the X-T1 is a winner in my book is the size. On my last vacation to San Francisco, I lugged around my D600 with the 24-120mm f/4 lens. Towards the end of each afternoon, I was sore from carrying it around, even with a good Black Rapid sling.  Here’s the X-T1 side-by-side with the D600.

X-T1 with D600
X-T1 with D600

The X-T1 feels like a feather by comparison.  I think the Nikon zoom alone is heavier than the X-T1. I carried the X-T1 around all afternoon and it was barely noticeable.

The X-T1 is about as close to perfection as a classic SLR-lover will find today. It’s not perfect though. I can tell already I’m going to have a love-hate relationship with the EVF. I still hope Nikon awakens from the pathetic slumber and builds the “FM-3D” I’ve been craving, but for the time being, the X-T1 and I are going to have a long and fruitful relationship.

On a side note, I picked up a DSPTCH Sling for the X-T1. It is a really comfortable, well-made sling that works perfect for the X-T1. And it’s even made in the USA. I can’t recommend it highly enough.

DSPTCH Sling on the X-T1
DSPTCH Sling on the X-T1

Sit on the Hands

Apple finally unveiled the much-anticipated iPad 2 yesterday, with all the expected fanfare. I was pretty excited for about the first 15 minutes of the presentation. Thin is sexy, and who could say no to dual cores and much faster graphics. I didn’t really care about the cameras, although that would make it a great all-in-one device for my in-laws who are malware magnets on their Windows machine.

But there was nothing earth shattering which made me want to upgrade my first generation iPad. There are two main reasons. First, there are going to be a crapload of tablets coming out this year, and I’d rather wait for the best device, not the first device. The iPad 2 is a starting point. I want the same specs, but with a better web browser and better expandability. Openness would also be a nice thing. Apple is turning in to the 21st century version of Microsoft in the 90s. There is some serious sexiness heading to the table market in the next six months, so waiting is the best thing to do unless someone absolutely must have an iPad like OMG TODAY!

The second reason is that my primary day-to-day travelling companion of choice has become my Kindle DX Graphite. Between my MacBook Pro and my iPhone, I have everything covered that I would do with my iPad. I like the focus of the Kindle on the task of reading, without distraction. No Twitter, AIM, email or the temptation to surf. I’m actually chewing through a lot of books that I have wanted to read and appreciate the Kindle DX even more now than 9 months ago.

So my best advice to anyone looking at an iPad 2, either as a new tablet or upgrade, is to wait. Give it a few months for the market to bloom and then pick the best device for your needs. It may well be the iPad 2, but you have nothing to lose by waiting a bit longer.

Kindle DX Graphite Review

My new, 2nd generation Kindle DX arrived today. I’ve had the small Kindle 2 for the past year-or-so, and I also have an iPad, but the new Kindle DX looked like the ideal platform to fill my needs. Being a computer programmer, I tend to have a lot of technical books in electronic format. Neither the Kindle 2 nor the iPad are especially adept at handling PDFs. The Kindle DX is about the same page size as a typical technical book, so I was hoping it would be the dream solution to my reading needs.

Size wise, the Kindle DX is a hair larger than the iPad:

Kindle vs iPad

The extra length is going to be a bit annoying for fitting in cases, but the two devices are about the same width. The biggest difference, which is immediately noticeable the first time you pick-up the Kindle DX, is the weight. The Kindle DX doesn’t feel much heavier than its smaller cousin, the Kindle 2, and it makes the iPad feel like a boat anchor by comparison. Here’s the Kindle DX compared to the Kindle 2:

Kindle DX vs Kindle 2

One of the big selling points of the new Kindle DX is the improved screen contrast. While it is not clear in the picture above, the text on the Kindle DX is noticeably darker than on the Kindle 2.

Since I’m really interested in how each of the platforms handles itself as a PDF or book reader, I loaded the same PDFs on each and took some pictures. The images below are from a PDF of the outstanding GroovyMag, a must-read for Groovy and Grails developers.

First, here’s the Kindle 2, showing both the full page and a close-up of the text. Note that I also link to a very-high resolution image so you can drill in and see the difference. Also, none of the photos have been retouched or corrected in any way.

Kindle 2 with PDF
medium-res | high-res

And here’s a close-up of the text on the Kindle 2:

Kindle 2 with PDF close-up
medium-res | high-res

Now here’s the Kindle DX with the same page:

Kindle DX with PDF
medium-res | high-res

And the close-up of the text on the Kindle DX:

Kindle DX PDF text
medium-res | high-res

And finally, here is the iPad rendering the same PDF side-by-side with the Kindle DX:

Kindle DX and iPad with PDF
medium-res | high-res

And the close-up of the text on the iPad:

iPad close-up
medium-res | high-res

I also have several ebooks in .mobi format for Kindle, and I loaded the same book onto both the Kindle DX and the iPad, using Amazon’s reader for the iPad. Here’s a screenshot of a page side-by-side:

Kindle DX and iPad book
medium-res | high-res

The Kindle DX fits more text on a page, if we compare using the standard font. One big difference is that I can make the fonts even smaller than this on the Kindle DX, whereas I couldn’t make them smaller with the Kindle Reader on the iPad. As my eyes have spent too many years looking at computer displays, I can’t support reading microscopic text, so the default size is perfect.

Here’s where things get interesting and you can really see the benefits of the E-Ink technology. This is a close-up of a paragraph on the iPad:

iPad text closeup
medium-res | high-res

And here is a close-up of the Kindle DX with the same text:

Kindle DX text closeup
medium-res | high-res

The differences are startling. There is no contest on text sharpness. The Kindle DX crushes the iPad. While this sharpness won’t make much of a difference checking email, there is literally a world of hurt between the two if you actually use the device to read for prolonged periods of time.

For one final comparison, lets take a look at the New York Times reader/application for both devices. The iPad “NYT Editor’s Choice” application really demonstrates what the iPad is good for. On the Kindle, for $2 a month, you can subscribe to NYT Latest News. There is a bit more content in Editor’s Choice, but there are also ads. Here is a comparison of the front page from today for each application:

Kindle DX and iPad with NYT
medium-res | high-res

Although it only has limited gray-scale abilities, the Kindle DX actually does really well with images, probably due to its ungodly resolution.

One thing I don’t like about the iPad when reading in bed is the metal edge. This bottom edge is not as rounded as it looks, and tends to dig in to my tummy. Here’s the edge on the iPad:

iPad edge

The Kindle DX has a slightly more curved, plastic edge on the bottom which makes it more comfortable for propping up when using a body part as a rest:

Kindle DX text closeup


The new Kindle DX is a phenomenal device. It handled PDFs easily, much better than the iPad. The Kindle DX can be plugged in to a USB port and mounts as a drive. You can drap-and-drop PDFs or eBooks into the document and the Kindle DX will read them. Getting PDFs on to an iPad is a major nuisance. The Kindle DX is also faster rendering the PDFs. The iPad will sometimes loose itself and you’ll get a bunch of blank pages while it is trying to sort out the layout. I’ve also had the iPad PDF viewer crash on several PDFs.

For books, there is no contest. The Kindle DX has razor-sharp text and its light weight makes it disappear while reading. With the iPad, be assured you will never forget you are holding it.

Now I know it is not fair to compare these devices, as they really are like apples and oranges. The iPad is about Distraction. If you want a device to check email, surf the web, hit Twitter and Facebook, play games and watch videos, the iPad is really the only game in tablet-town that can do it all.

The Kindle DX, on the other hand, is about Concentration. If you want a device to read books or other text, the Kindle DX is a light-year beyond the iPad in handling that task. It really is an electronic book. It is sort of like comparing a swiss army knife to good survival knife. If you need to open a can, file the nails, uncork a bottle of wine and maybe cut open something, the swiss army knife is your tool. But if your in the woods trying to build a shelter, start a fire and cut wood, the survival knife is hands-down the tool to have.

If you’re in the market for a book reader, and not an entertainment platform, the Kindle DX is the king of the hill.

Cool CBT

After enough time in technology, one tends to become pretty jaded about vendor claims. I’ve seen enough miracle solutions before, most them involving code generation to “eliminate the developer.” It has gotten to the point that if I even hear a vendor mention SOA, I whip out a can of Bear Mace and let them have it.

So it came as a great personal surprise when I actually saw a vendor demo for something both cool and practical. I sit on the .NET Center of Excellence for our oversized company, and part of the role is listening to vendors show off their latest and greatest. Our last demo was from a company called InnerWorkings and I had honestly never heard of them before the demo.

InnerWorkings has an incredibly awesome computer-based training (CBT) system for learning .NET. It goes beyond book reading and is heavily based around coding exercises which are even scored by the system. It has a Visual Studio plugin for working with the vast library of learning material and links to O’Reilly’s Safari Books for reference.

I had never seen a CBT product before this which I would actually considered to be effective. This looked good enough that I would almost be willing to invest my own dollars. If you need to bring a development team up to speed on .NET programming, or a specific area on the bleeding edge, I highly recommend taking a look at InnerWorkings.

New Kid on the Block

On this cloudy Dallas Saturday morning, the ExtJS team announced the availability of Ext Core (beta). Ext Core is the core DOM selection, manipulation and events library of ExtJS which has been extracted out into a separate library released under a more liberal license. They smartly released this under the very permissive MIT license, in contrast to the cancerous GPL used for the full ExtJS.

What makes this interesting is it positions Ext Core as a direct competitor to the popular JQuery library. I really like both ExtJS and JQuery, so I decided to run a quick comparison of the two libraries to see if Ext Core is up to the task of replacing JQuery in my developer toolbox. Since there is so much overlap between the two, it makes no sense to use both.

Round 1 – Size

Library size of the two is pretty close. The minified version of JQuery runs about 56K, while the minified version of Ext Core weighs in at 75K. The 19K difference might matter for an iPhone application, but even then, I would consider it negligible. Both are pretty small libraries, so we’ll call Round 1 a tie and move on to feature comparison.

Round 2 – Load Event

How each of these libraries works the document ready event is more a matter of style. The JQuery convention is to use the dollar sign ($) for for operations, although you can fall back to using the full name (jQuery). Setting up a ready event in JQuery looks like this:

$(document).ready(function() {
    // do cool stuff

Ext Core uses the static Ext class for the same functionality. Like the jQuery object, the Ext object is the heart of Ext Core. Setting up the ready listener in Ext Core looks like this:

Ext.onReady(function() {
    // do cool stuff

One big difference is the onReady method can take an additional parameter specifying the scope in which the onReady method should execute. This is not a big deal in most cases, but shows Ext Core’s attention to support object oriented JavaScript. Since I’ve never actually needed to specify the scope, I’ll call this round a tie too.

Round 3 – Selectors

This is the heart of both libraries, and a full comparison could fill a dozen pages. The short story is they both support basically the same set of CSS3 selectors along with some custom enhancements. From looking at the documentation, I couldn’t find any typical use cases that either couldn’t handle. Like the document ready example above, it just comes down to a matter of convention. For example, here is the code from each to add a class to a set of nodes:

// JQuery

// Ext Core'td.age').addClass('someclass');

One major style difference between the two is that Ext Core has a tighter focus in handing elements with ids, since that is critical to the full ExtJS library. For example, Ext Core has the get() method to directly grab an element by ID, along with a memory-friendly fly() method. The fly() method does not create a new element wrapper in memory, and instead reuses a single global element object. This can save a lot of memory when you just need to do quick manipulations of single objects.

// Add a class to the element with ID of 'header''header').addClass('someclass');

For the memory saving fly operation, I’ll give the advantage to Ext Core, although they are essentially equal in their DOM selection abilities.

Round 4 – Events

Like the selectors above, there are basically style differences between the two libraries in how they handle basic event use cases. JQuery adds some methods to the jQuery object for registering common events. For example, here is the code to add a click event to a button for each, including the JQuery shortcut:

// JQuery with bind()
$('#myButton').bind('click', function() { alert('Clicked');});
// JQuery with shortcut
$('#myButton').click(function() { alert('Clicked');});
// Ext Core'myButton').on('click', function() { alert('Clicked');};

JQuery brings some some additional enhancements to the game in the form of “live” events. This provides a way of attaching an event to all current, and future, instances of the selector. JQuery also supports event namespaces, where events can be fired in a hierarchy. Both are powerful concepts, but I’ve never had to use either.

The secret sauce for Ext Core is in extended configuration. With Ext Core events, you can also configure the scope (a common Ext Core theme), along with configuring the event propagation, extra parameters, and a delay. Here is a sample of a click event configured with ‘this’ scoped to the onClick event itself, to only fire once (single), with a delay of 100ms and an additional parameter (forumId) to be passed to the event handler:

el.on('click', this.onClick, this, {
    single: true,
    delay: 100,
    forumId: 4

So again, I’m going to call this round a tie. Both libraries handle simple event binding very easily. If you need the live events, the nod goes to JQuery. If you need the extra configuration options, Ext Core is your best bet.

Round 5 – DOM Manipulation

Once again, the two libraries provide a near complete overlap of basic DOM manipulation functionality. Each can easily create, move, add and insert DOM elements.

JQuery aims for convenience. For example, one feature of JQuery I really appreciate are simple methods to clear the content of a DOM element and set the text. For example, given:

First Message

With JQuery, it is simple to update the text:

$('#message').text('New Message');

The text() method removes all the child nodes of the matching elements and appends a text node containing the specified text. The text() method without a parameter will retrieve the text for a matching element. For Ext Core, you have to drop down to the DOM to set the new text value:'secret').dom.innerHTML = 'New Message';

The Ext.Element class does not provide simple methods for setting the text or removing all the children of an element, which I find to be an annoying inconsistency.

On the plus side, Ext Core provides a lot more methods for manipulating the DOM. One of the cool ones is the radioClass() method. This method will add a class or classes to an element and remove that same class (or classes) from all the siblings. For example, here is a simple table with a row having the ‘selected’ class:


This one line of Ext Core code will remove the ‘selected’ class from the current TR element and add it to the first row in the table:'table tr:first').radioClass('selected');

So for this round, I’ll give the advantage to JQuery for the more consistent API, especially around manipulating the text nodes of an element. This is something pretty simple for Ext Core to address, which they really should. Ext Core does, however, offer more powerful DOM manipulation options.

Round 6 – Effects

I’m not a big effects junkie, so I won’t have a lot to say about this. Both Ext Core and JQuery provide a very similar set of effects for elements (hide/show, fade, slideIn/Out, etc…). Ext Core provide a more powerful API for creating custom effects, while JQuery addresses this with its rather extensive set of plug-ins. I’m calling this one a tie.

Round 7 – AJAX

Ext Core and JQuery both make AJAX simple, but again, we’ll see that JQuery adds more simplified methods while Ext Core offers more powerful configuration. Here is a sample of an AJAX call that returns JSON data:

// URL returns a JSON object like this: {name: 'Tim'}

// JQuery 
$.getJSON('http://myurl', function(data) {alert(;});
// Ext Core
    url: 'http://myurl', 
    success: function(response) {
        var data = Ext.decode(response.responseText);

JQuery provides the simplified getJSON() method where the parameter to the callback has already been decoded into a JSON object. For Ext Core, the callback receives the XHR response object and you have to decode the text to JSON.

The Ext Core request() method demonstrates a typical ExtJS convention of using a JavaScript configuration object as a parameter instead of using multiple parameters.

Both libraries provide strong AJAX support, so we’ll go with a tie for this round too.

Round 8 – Documentation

There is no contest in the documentation department. While the JQuery documentation has improved, the Ext Core documentation blows it away. From the excellent manual to the high-quality API documentation, Ext Core sets the standard for what all documentation should look like.

Round 9 – Intangibles

For JQuery, the biggest intangibles are its plugins and support from Microsoft. JQuery is intentionally designed to provide a simple core set of functionality and to be easy to extend. There are hundreds of plugins people have written for JQuery in the Plugin Repository. As with all things open source, some are very good and some are kinda crappy, but you can be pretty certain to find a plugin that covers about anything you might be trying to do that is not covered by the core JQuery API.

Microsoft support is also a biggie. They have decided to include JQuery as a base JavaScript library in their web tools going forward. This means you won’t need to get special blessings to use JQuery in large corporate environments — it will be part of the core Microsoft bundle, with support and all.

Ext Core, being brand new, is lacking in both community and support. Ext LLC, the company behind ExtJS and Ext Core is a small software shop trying to get by in a tough economy. While their products are cutting edge, I’m expecting them to be bought out by a larger company before too long. I keep trying to talk my Spring Source contacts into buying them, but I have a feeling they’ll be bought by Adobe.

So from an intangibles perspective, JQuery is the winner. It is guaranteed to have longer legs under it, at least until we see where Ext LLC ends up.


Both Ext Core and JQuery are solid, complete base JavaScript libraries. JQuery leans towards simplicity while Ext Core offers enhanced configuration. The choice of which to use will come down to where you are now.

  • If you use JQuery, and don’t anticipate using ExtJS, stay where you are. You’ve got a winner.
  • If you use ExtJS and have used JQuery as a light weight option for when you didn’t need the widget library, Ext Core is now your library of choice.
  • If you are in search of a JavaScript library, the choice is tougher. Unless there is a particular JQuery plugin you want to use, I recommend going with Ext Core. It starts laying the groundwork for using ExtJS, which you’ll want to do as you get in to building RIAs.
  • If you’re a corporate Microsoft shop, you probably don’t have a choice. JQuery is now something you can slip by the infosec police without making waves.

Ext Core is definitely a winner. In the past, I have used JQuery for projects that need simple DOM manipulation and ExtJS for when I need the widgets, layouts, etc… Now that I have Ext Core, I don’t see using JQuery anymore for the simple cases. I can standardize on using the same API paradigm between Ext Core and ExtJS.

Follow-up #1: Beyond the Core
Follow-up #2: Slick Speed