I just had an article published in the December Pragmatic Programmer magazine on
a new approach to logging
Wednesday, December 7, 2011
Friday, November 18, 2011
Writing on a Tablet
I do a lot of writing these days, some on my high end Windows laptop with dual 20 inch monitors and some on my 10 inch tablet with Bluetooth keyboard.
I have surprisingly discovered that I am far more efficient on the tablet. This is surprising because on the tablet I have much smaller screen (less than 100 square inches versus more than 700 square inches), I don’t have a mouse, and switching from my writing app to email or the web is more involved.
That last item proves to be the key item. Because the tablet is primarily not a multitasking device I tend to focus on writing when I’m writing. The lure of the emails lurking in my system tray is gone. The other browser windows in my giant multimonitor display do not call to me. The fact that my tablet can really only do one thing at time is not a limitation it is a benefit.
While at a certain level this is obvious it’s also interesting given the current debates about multitasking operating systems. At the same time that some OSs are claiming to be better because of multitasking some of the mainstream OSs are adding features to discourage multitasking! For example various flavors of Linux have the option to automatically dim all windows other than the active one. The idea is to reduce the lure of context switching.
All kinds of current research is showing that humans cannot really multitask, yet we want to pretend that we can. At the same time, we know that the key to writing is to…well…write. And as much as we love to write we also love anything that can distract us from writing. So using a “limited” system to do our writing on is really to our advantage.
I have surprisingly discovered that I am far more efficient on the tablet. This is surprising because on the tablet I have much smaller screen (less than 100 square inches versus more than 700 square inches), I don’t have a mouse, and switching from my writing app to email or the web is more involved.
That last item proves to be the key item. Because the tablet is primarily not a multitasking device I tend to focus on writing when I’m writing. The lure of the emails lurking in my system tray is gone. The other browser windows in my giant multimonitor display do not call to me. The fact that my tablet can really only do one thing at time is not a limitation it is a benefit.
While at a certain level this is obvious it’s also interesting given the current debates about multitasking operating systems. At the same time that some OSs are claiming to be better because of multitasking some of the mainstream OSs are adding features to discourage multitasking! For example various flavors of Linux have the option to automatically dim all windows other than the active one. The idea is to reduce the lure of context switching.
All kinds of current research is showing that humans cannot really multitask, yet we want to pretend that we can. At the same time, we know that the key to writing is to…well…write. And as much as we love to write we also love anything that can distract us from writing. So using a “limited” system to do our writing on is really to our advantage.
Wednesday, November 16, 2011
A few minutes with the Kindle Fire
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.
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.
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.
Subscribe to:
Posts (Atom)