I got to spend a few minutes with the Kindle Fire yesterday. Full disclosure: we have two kindles, an iPad, a smartphone and assorted laptops at home.
The iPad has almost completely replaced the laptop at home, and with a bluetooth keyboard I do most of my writing on it. It comes with me to the numerous evening Meetups I attend.
My kindle comes with me everywhere during the day, because it fits in my pocket which lets me squeeze in lots of spare minutes reading.
The smartphone has been relegated to making phone calls and checking gmail when out of wifi.
The KF is agreeably small and light and I could imagine it being with me everywhere. The screen is clean and crisp. Some reviewers have complained about slow screen response but I did not encounter that. Page turns while reading were very responsive and selecting items from the various menus was easy.
The touch screen made selecting and highlighting text much simpler than on the legacy kindle, so I might pick the KF for technical reading where I do lots of note taking.
One problem I did encounter was in getting to the menu screen. Most apps are full screen so to get to the menu and the Home button you have to touch the bottom of the screen. The location to touch was hard to find. It often took me lots of touches to bring up the menu resulting in lots of unwanted page turns. Presumably this would be something one would figure out over time.
Movies look nice on the KF, though obviously a smaller image than on the iPad. My kindle reading is largely opportunistic, a few minutes here and there. While I'm willing to read books a page at time I don't know that I'd want to watch a movie that way. When I know I might have blocks of time I bring my iPad. So movies wouldn't be a KF draw for me though they might be for my iPad-less wife.
Magazines look much better on the KF than on the legacy kindle.
In the end buying a KF or not depends on what devices you already have and what you want to do.
If you just have a legacy kindle or a smartphone and don't want to do content creation the KF makes sense. If you just have a iPad but no book reader you might get the KF for its extra portability.
For my wife who has a kindle plus dumb phone and wants some internet access we have a couple of choices. We could get a $300 smart phone plus two years of a $30/month add-on data plan; two year cost $1020. Or a $200 KF, possibly adding on the $79/year Amazon Prime membership. That seems like an easy choice for us. Your mileage may vary.
Wednesday, November 16, 2011
Thursday, November 3, 2011
New article published at Pragmatic Programmers
I just had an article published in the Pragmatic Programmer magazine on
the long history of root cause analysis
the long history of root cause analysis
Friday, September 30, 2011
Kindle Fire replaces SmartPhone not tablet
Just had a conversation with my wife about the Kindle-Fire (KF) and had an epiphany.
KF isn't a replacement for the full tablet, but it is a replacement for the smart phone!
KF costs $200 plus zero for service contract
smart phone costs $50-$200 plus at least $30 a month for data contract.
If you mostly use the 'smart' features of the phone for things like email/calendar/games, then it may be very compelling to ditch the cellular data plan, ditch the smart phone, get a dumb phone for making dare-I-say-it phone calls and the KF for email/calendar/etc.
I think we're going to do that.
OTOH, if you want a tablet for creating rather than consuming content, you still need a full size tablet, preferably with a keyboard.
KF isn't a replacement for the full tablet, but it is a replacement for the smart phone!
KF costs $200 plus zero for service contract
smart phone costs $50-$200 plus at least $30 a month for data contract.
If you mostly use the 'smart' features of the phone for things like email/calendar/games, then it may be very compelling to ditch the cellular data plan, ditch the smart phone, get a dumb phone for making dare-I-say-it phone calls and the KF for email/calendar/etc.
I think we're going to do that.
OTOH, if you want a tablet for creating rather than consuming content, you still need a full size tablet, preferably with a keyboard.
Wednesday, September 14, 2011
Publication Summary
I've been asked a few times for a summary of my publications over the last few years so here it is.
Sept 2011 Scala Traits
August 2011 Code As Dialog
May 2011 Catch the Pig!
November 2010 The value of a personal bug log"
September 2010 The Key to Better Software
June 2010 Better Tools and Training
June 2010 Debugging MySQL Stored Procedures
May 2010 The Floating Finish Line
April 2010 Medicine Making Music
March 2010 Testing As Contract
November 2009 Interrupt Mood
June 2009 ...And Your Bugs Can Sing
Sept 2011 Scala Traits
August 2011 Code As Dialog
May 2011 Catch the Pig!
November 2010 The value of a personal bug log"
September 2010 The Key to Better Software
June 2010 Better Tools and Training
June 2010 Debugging MySQL Stored Procedures
May 2010 The Floating Finish Line
April 2010 Medicine Making Music
March 2010 Testing As Contract
November 2009 Interrupt Mood
June 2009 ...And Your Bugs Can Sing
Thursday, August 25, 2011
Review of Venkat Subramaniam's new book on Concurrency
Programming Concurrency on the JVM: Mastering Synchronization, STM and Actors
by Venkat Subramaniam
This book should be considered part of a two book series along with Venkat’s 2009 book “Programming Scala: Tackle Multi-core Complexity on the JVM”. The earlier book was a relatively short (250 pages versus 852 pages for Odersky’s Scala book), perhaps too short, overview of Scala. It’s 12 chapters skip over lots of the details in Odersky’s 18 chapter book, and contains only a single chapter on Concurrent Programming.
By comparison the new book is all about Concurrent Programming models and attempts to be agnostic about the JVM language to be used. Most examples are first given in Java, then a simpler way is shown to do it in Scala, and then often a short section saying how the example could be done in Ruby.
The book describes the difficulties of concurrent programming in JVM languages especially given the rise of multi-core processors. It then describes three “solutions”: the naïve Java approach, Software Transactional Memory and Actors. It should be noted that the Actors chapter is based on Akka, so if you don’t care for Akka you may not like this book.
The Power and Perils of Concurrency – This should be an unsurprising recap of well known problems; if you’re reading this book you will almost certainly have run into the problems listed here already.
Strategies for Concurrency – Talks about ways to divide problems into parts that can be computed independently
Modern Java/JDK Concurrency – This talks in detail about the changes made to the Java libraries to better support concurrency, specifically things like using ExecutorService rather than “new Thread()” and using Lock vs. synchronized. Interestingly though the chapter fails to discuss the little known but serious differences between synchronized blocks and methods involving fairness and barging.
Taming Shared Mutability – This chapter begins to offer the Scala kool-aid of mutability is bad. Reading this chapter is made easier if you’ve already read Goetz’s “Programming Concurrency”.
Software Transactional Memory – This chapter talks about Clojure’s STM model and how to use it in Java via Akka. Its an interesting chapter but one that will feel odd if you’re a programmer also coming to terms with non-relational databases. As databases move away from the transitional transactional model here comes STM bringing transactions to mutable variables.
Actor-based Concurrency – Actors are basically a message passing schema where immutable messages are passed between lightweight actors (thread-like). Just as you can use thread pools to reduce the cost of threads there are what amount to actor pools which lighten their cost. It does require some rethinking to embrace the actor approach.
Overall this is a fine book that brings quite a lot to the table. My only reservation would be that if you are a seasoned Java programmer you might take the first four sections as a given and jump right to the Actors approach. And if you’re not a seasoned Java programmer you probably don’t realize how badly you need this book.
by Venkat Subramaniam
This book should be considered part of a two book series along with Venkat’s 2009 book “Programming Scala: Tackle Multi-core Complexity on the JVM”. The earlier book was a relatively short (250 pages versus 852 pages for Odersky’s Scala book), perhaps too short, overview of Scala. It’s 12 chapters skip over lots of the details in Odersky’s 18 chapter book, and contains only a single chapter on Concurrent Programming.
By comparison the new book is all about Concurrent Programming models and attempts to be agnostic about the JVM language to be used. Most examples are first given in Java, then a simpler way is shown to do it in Scala, and then often a short section saying how the example could be done in Ruby.
The book describes the difficulties of concurrent programming in JVM languages especially given the rise of multi-core processors. It then describes three “solutions”: the naïve Java approach, Software Transactional Memory and Actors. It should be noted that the Actors chapter is based on Akka, so if you don’t care for Akka you may not like this book.
The Power and Perils of Concurrency – This should be an unsurprising recap of well known problems; if you’re reading this book you will almost certainly have run into the problems listed here already.
Strategies for Concurrency – Talks about ways to divide problems into parts that can be computed independently
Modern Java/JDK Concurrency – This talks in detail about the changes made to the Java libraries to better support concurrency, specifically things like using ExecutorService rather than “new Thread()” and using Lock vs. synchronized. Interestingly though the chapter fails to discuss the little known but serious differences between synchronized blocks and methods involving fairness and barging.
Taming Shared Mutability – This chapter begins to offer the Scala kool-aid of mutability is bad. Reading this chapter is made easier if you’ve already read Goetz’s “Programming Concurrency”.
Software Transactional Memory – This chapter talks about Clojure’s STM model and how to use it in Java via Akka. Its an interesting chapter but one that will feel odd if you’re a programmer also coming to terms with non-relational databases. As databases move away from the transitional transactional model here comes STM bringing transactions to mutable variables.
Actor-based Concurrency – Actors are basically a message passing schema where immutable messages are passed between lightweight actors (thread-like). Just as you can use thread pools to reduce the cost of threads there are what amount to actor pools which lighten their cost. It does require some rethinking to embrace the actor approach.
Overall this is a fine book that brings quite a lot to the table. My only reservation would be that if you are a seasoned Java programmer you might take the first four sections as a given and jump right to the Actors approach. And if you’re not a seasoned Java programmer you probably don’t realize how badly you need this book.
Wednesday, August 24, 2011
Books on Scala
While the best way to learn a new language is to write in it there is still a great value to reading books on the language. When I was a C/C++ coder (a long time ago) I made it a point to read every book published on the language. The benefit of picking up even a single tip on how to use the language I spent 10 or more hours a day in was simply too large to ignore.
So, I decided to look at the current set of books on Scala. If you don't know Scala it is a hybrid OO/Functional JVM language.
Here are the books I found that are either in print or soon to be in print.
While book length is not a good predictor of quality its hard to see how you can cover a language like Scala in a short book. In particular "Scala In Depth" looks to be the shortest book!
Personally my approach to learning Scala was to put Subramanian's book on my right, Odersky's book on my right, and a Scala console in the middle. I then read the same chapter in each book, working through each and every example in the Scala console. This way I got the benefit of learning the same concept via the different wording of two top authors...and I forced myself to actually write some Scala.
For my next Scala reading I'll try Scala In Action simply based on past enjoyment of the "X In Action" books from Manning Press. None of them have ever let me down.
I should also mention two other related books:
"Seven Languages In Seven Weeks" by Bruce Tate (full disclosure: I'm interviewed in the book's chapter on Prolog)
and
"Programming Concurrency on the JVM" by Subramanian. While not strictly a Scala book it is still very interesting as it introduces Software Transactional Memory and Actors and shows how to use them in various jvm languages.
So, I decided to look at the current set of books on Scala. If you don't know Scala it is a hybrid OO/Functional JVM language.
Here are the books I found that are either in print or soon to be in print.
| Title | Author | Length | Publication Date or Amazon Rating |
|---|---|---|---|
| Programming In Scala | Odersky | 852 pages | 4.5 stars |
| Programming Scala | Wampler | 448 pages | 4.5 stars |
| Programming Scala | Subramanian | 250 pages | 4.0 stars |
| Beginning Scala | Pollak | 320 pages | 3.5 stars |
| Scala In Action | Raychaudhuri | 525 pages | (fall 2011 9 of 14 chapters available) |
| Scala In Depth | Suereth | 225 pages | (Winter 2011 8 of 11 chapters available) |
While book length is not a good predictor of quality its hard to see how you can cover a language like Scala in a short book. In particular "Scala In Depth" looks to be the shortest book!
Personally my approach to learning Scala was to put Subramanian's book on my right, Odersky's book on my right, and a Scala console in the middle. I then read the same chapter in each book, working through each and every example in the Scala console. This way I got the benefit of learning the same concept via the different wording of two top authors...and I forced myself to actually write some Scala.
For my next Scala reading I'll try Scala In Action simply based on past enjoyment of the "X In Action" books from Manning Press. None of them have ever let me down.
I should also mention two other related books:
"Seven Languages In Seven Weeks" by Bruce Tate (full disclosure: I'm interviewed in the book's chapter on Prolog)
and
"Programming Concurrency on the JVM" by Subramanian. While not strictly a Scala book it is still very interesting as it introduces Software Transactional Memory and Actors and shows how to use them in various jvm languages.
Sunday, December 19, 2010
The most basic failure
In this holiday buying season the Kindle and the Nook continue to be very popular, and the battle still ranges over the viability of dedicated e-readers versus general purpose devices like the IPad.
Poor Sony.
I own one of the Sony E-Readers and quite like it. It has many advantages over the Kindle, Nook or IPad and yet its largely forgotten. I have a theory as to why.
Sony forgot to give its product a name! Quick test: what is the name of Sony's e-reader? Its "E-Reader". Since thats also the generic term for the device it amounts to not having a name.
Sometimes having the generic name for the device is a good thing. Xerox has the generic name for the photocopier. The important thing however is the timing.
Its a Good Thing to have your product name become the generic name. Its a Bad Thing however to simply use an existing generic name.
Imagine a device making introducing an MP3 player and calling it "MP3-Player". Rather than subsuming all the good will associated with the general product this new device would feel like a cut-rate generic device.
I think thats what happened to Sony's device. You can't even talk about their reader. I can't tell you how many times people have asked me: "is that a Kindle?". I say "no, its Sony's Kindle", which is certainly not an answer to warm the hearts of Sony's marketing department.
I don't know what surprises me more, the fact that Sony forgot to name their device, or that no one seems to have noticed this failure.
Poor Sony.
I own one of the Sony E-Readers and quite like it. It has many advantages over the Kindle, Nook or IPad and yet its largely forgotten. I have a theory as to why.
Sony forgot to give its product a name! Quick test: what is the name of Sony's e-reader? Its "E-Reader". Since thats also the generic term for the device it amounts to not having a name.
Sometimes having the generic name for the device is a good thing. Xerox has the generic name for the photocopier. The important thing however is the timing.
Its a Good Thing to have your product name become the generic name. Its a Bad Thing however to simply use an existing generic name.
Imagine a device making introducing an MP3 player and calling it "MP3-Player". Rather than subsuming all the good will associated with the general product this new device would feel like a cut-rate generic device.
I think thats what happened to Sony's device. You can't even talk about their reader. I can't tell you how many times people have asked me: "is that a Kindle?". I say "no, its Sony's Kindle", which is certainly not an answer to warm the hearts of Sony's marketing department.
I don't know what surprises me more, the fact that Sony forgot to name their device, or that no one seems to have noticed this failure.
Subscribe to:
Posts (Atom)