I don't usually review TV shows, but The Stinky and Dirty Show has captured Bowen, and I'm not horribly unhappy about that, so I figure I'll talk a bit about why it's special as well as tie it to why Amazon doesn't care about killing Netflix.
The premise of the show is simple: a garbage truck (Stinky) and a bulldozer (Dirty) are friends. Through the course of an episode (about 11 minutes each, with each "streaming episode" being 2 episodes joined together), the two friends encounter problems and solve them. Most of the problem-solving involves brain-storming many "what if" scenarios before settling on the correct approach. Some of them involve calling in friends who can help, and many of the solutions are found through serendipitous observations. I can't watch an episode with Bowen without saying, "Wow, what a smart show for kids!"
What's more, Bowen's been brought up on a steady diet of shows where the protagonists are female (e.g., Nausicaa, Totoro, Frozen), so it was nice to introduce some diversity and have a show that's mostly about boys (sure, the vehicles are gender neutral, but names like Stinky and Dirty typically apply to boys :-).
Incidentally, we went and checked out the books from the library (it's an indication that the show has not yet hit the mainstream yet that the books are still easily available at our local library) and the books are disappointing and much worse than the TV show. No brain-storming or problem solving to be found anywhere in the books, which aren't nearly as smart as the Amazon show. How rare!
So the show's good and recommended. But why is Amazon doing this? The big factor that drives parents to become Amazon Prime customers is diapers. I once did the math and the savings from diapers alone pay for the Amazon Prime membership. But of course, kids do eventually grow out of diapers, and so after that Amazon needs something to hook families on them. While shows like Peppa Pig are easily found on Youtube (and free if you're willing to put up with ads), unique shows like The Stinky and Dirty Show could very well drive me to keep the Amazon subscription even after the littlest one is out of diapers. Here's the thing --- parents don't have time for TV/movies (we've long cancelled our Netflix subscription). As much as I'd love to watch the new Daredevil show, I just don't have time for it. But kids not only have time to watch shows, they keep watching the same show over and over. It doesn't take too many such shows before they become a "must-have" for the parents. This makes Amazon Prime a much better value than if it's just for 2 day shipping.
Monday, November 14, 2016
Friday, November 11, 2016
Review: Brasscraft BC260
One penalty of living in an old house like mine is that the kitchen sink clogs up about twice a year. I got fed up of paying the plumber to come out and unclog it every time, so I tried various solutions. The hand powered augers were too painful to use, and the drill auger I rented once turned out to be difficult as well. Finally, I asked the plumbers to give me a recommendation. They were reluctant but eventually pointed me at the BrassCraft machine.
The BrassCraft auger sits on the ground, which is perfect, because then you're not holding the power drill. It comes with a foot switch so you can activate it while feeding the cable into the clean-out. I've used it in anger twice since I bought it earlier this year, and it works, though the set up is laborious. Because the power cable is too short, I have to first run an extension cord out to it. Then, I have to thread the proper cleaning tool onto the front, and then screw it on.
After plugging everything in, you then put on gardening gloves, and then pull out the cable and feed it into the cleanout, stepping on the foot switch to help everything grind along. Note that even though there's a "reverse gear" on the drill, the manual says not to use it! Fortunately, if you've actually cleared the obstacle in the pipe, you can generally pull the cable out by hand.
To my surprise, you can actually over-drive the cable machine: the cable itself is not anchored in anyway to the drum, so if you get over-enthusiastic and drive out all 50', you can end up pulling the cable out of the machine entirely. This sucks, because you'll spend at least 15 minutes working the cable back in.
Nevertheless, the machine will pay for itself if you use it just 3 times over it's lifetime, and it looks like it'll survive quite a bit longer than that. It also saves quite a bit of time since the penalty with calling the plumber isn't just that you have to pay him, but also wait for him to come around to where you are.
Recommended.
The BrassCraft auger sits on the ground, which is perfect, because then you're not holding the power drill. It comes with a foot switch so you can activate it while feeding the cable into the clean-out. I've used it in anger twice since I bought it earlier this year, and it works, though the set up is laborious. Because the power cable is too short, I have to first run an extension cord out to it. Then, I have to thread the proper cleaning tool onto the front, and then screw it on.
After plugging everything in, you then put on gardening gloves, and then pull out the cable and feed it into the cleanout, stepping on the foot switch to help everything grind along. Note that even though there's a "reverse gear" on the drill, the manual says not to use it! Fortunately, if you've actually cleared the obstacle in the pipe, you can generally pull the cable out by hand.
To my surprise, you can actually over-drive the cable machine: the cable itself is not anchored in anyway to the drum, so if you get over-enthusiastic and drive out all 50', you can end up pulling the cable out of the machine entirely. This sucks, because you'll spend at least 15 minutes working the cable back in.
Nevertheless, the machine will pay for itself if you use it just 3 times over it's lifetime, and it looks like it'll survive quite a bit longer than that. It also saves quite a bit of time since the penalty with calling the plumber isn't just that you have to pay him, but also wait for him to come around to where you are.
Recommended.
Labels:
house,
recommended,
reviews
Thursday, November 10, 2016
Review: JavaScript: The Good Parts
While building my Shared Checklist application, I learned JavaScript mostly by reading examples on the web as well as a library copy of Javascript: The Definitive Guide. The problem with learning a language this way is that you're generally clueless about the idiomatic uses of various language features, as well as what general good practice is.
JavaScript: The Good Parts promised to be a good introduction to the latter, so I checked it out from the library. The book's very reasonable if you have a good understanding of Scheme, Self, and one other "classical" object-oriented programming language, and have read SICP. Since I qualify as all of the above, I found the book to be a breeze, reading it in a couple of hours.
In general, I found the explanation to be clear, to the point, and comprehensible. There are a few sections that I thought weren't very good: for instance, he introduces object-oriented programming in JavaScript through the use of a programming paradigm meant to emulate "classical" object-oriented languages. The idea is that most readers come from C++, Java, or some other OO language in wide use. Then he tells you to throw away all that and switch to the Self-like prototypes-based object-oriented language instead. From a pedagogic point of view, he should have gone straight for the prototype based learning approach --- never teach someone "the wrong way" to do something first, and then teach them "the right way."
Nevertheless, reading this book before I'd gone ahead with my JavaScript implementation of Shared Checklists would have been very useful. My code's much messier than it had to be, and there are a few "best practices" that would have made everything neater.
Reading the Amazon reviews, it seems like most of the people who rate this book badly do not have the required background I mentioned above. If you have the right background, reading this book is as much fun as reading Dennis Ritchie's The C Programming Language. That's high praise, and the book deserves it.
Recommended.
JavaScript: The Good Parts promised to be a good introduction to the latter, so I checked it out from the library. The book's very reasonable if you have a good understanding of Scheme, Self, and one other "classical" object-oriented programming language, and have read SICP. Since I qualify as all of the above, I found the book to be a breeze, reading it in a couple of hours.
In general, I found the explanation to be clear, to the point, and comprehensible. There are a few sections that I thought weren't very good: for instance, he introduces object-oriented programming in JavaScript through the use of a programming paradigm meant to emulate "classical" object-oriented languages. The idea is that most readers come from C++, Java, or some other OO language in wide use. Then he tells you to throw away all that and switch to the Self-like prototypes-based object-oriented language instead. From a pedagogic point of view, he should have gone straight for the prototype based learning approach --- never teach someone "the wrong way" to do something first, and then teach them "the right way."
Nevertheless, reading this book before I'd gone ahead with my JavaScript implementation of Shared Checklists would have been very useful. My code's much messier than it had to be, and there are a few "best practices" that would have made everything neater.
Reading the Amazon reviews, it seems like most of the people who rate this book badly do not have the required background I mentioned above. If you have the right background, reading this book is as much fun as reading Dennis Ritchie's The C Programming Language. That's high praise, and the book deserves it.
Recommended.
Labels:
books,
computers,
programming,
recommended,
reviews
Wednesday, November 09, 2016
Building Shared Checklist (Part 2): The Web Application
After the Android App was done, I turned my attention to building a web application. There were several motivations for this: first, I do enjoy sitting down in front of a desktop (or laptop) with a real keyboard. Nothing makes for fast data entry than a real physical device that's optimized for typing. Secondly, I wanted to explore the world of web applications. Remember that as a back-end guy for much of my career, I'd skipped the entire javascript-heavy universe of web application frameworks.
In the old days, web applications used to have 3 tiers: the client, the application server, and the database. The application server would keep tracks of things like sessions and cookies, using the database only for persistent data. The "new" approaches are forked into 2 types: the single page Javascript-oriented web application (which Firebase was designed to facilitate), where the client web-browser's Javascript engine would keep track of all the state, and went directly to the database for persistent data, and the REST-ful approach, where each click on a link would encode all the session data so that the application server was essentially stateless and didn't have to maintain state for the client. Both approaches eliminate the scaling problems of the traditional 3-tier approach, but introduced several new problems of their own, as I was about to find out.
My first thought was to try it using GWT. GWT had several nice features: one would have been that I wouldn't have to learn any Javascript. Another was a one-click deploy into Google's App Engine, which was also very appealing. Finally, I'm a big fan of static type-checking being able to eliminate an entire class of bugs.
Imagine my disappointment when I discovered that there was no integration package between Firebase and GWT whatsoever. OK, no problem, I could write my own wrapper around the Firebase javascript stuff and GWT. I tried that and discovered that Javascript objects passed into the GWT Java code became opaque objects that couldn't be used! This was very disappointing. I was even more disappointed when I discovered that it also made debugging very painful --- the GWT-generated Javascript was even more impenetrable than I imagined, and I'd have to end up learning Javascript anyway to do any kind of intense debugging. So I gave up on GWT and went full-on into writing a Javascript single-webpage web application.
Not being much of a UI guy, I looked around for a Javascript UI library, and found webix. The Treeview looked like exactly what I wanted, and I jumped right into using it. As with the Android App, the Firebase Web API (really Javascript API --- there's no server->server integration in Firebase land) is callback-oriented.
This is really weird, since if I wanted to get the user to Login right away, there's no easy way to say, "Hey, show this UI only after the user's done logging in." I tried some forms of deferred execution, but there's a real weird interaction between "login using a popup window" and the use of the Javascript firebase API.
In the end, I got it all to work, but it was clunky. For instance, I was forced to pop up dialog boxes, etc., to get the user to input a new checklist, or even a new checklist item. This was unsatisfying: in practice, I wanted people to be able to push a "+" button somewhere on the tree and then edit a text-field inline like in the Android app. But since Webix wasn't really designed to do so without you jumping in and modifying the code, I couldn't easily do this. In the end I stuck with dialog boxes all over the place.
All in all, I'm definitely unsatisfied with the result. The debugging was also a pain: any kind of error in the Javascript causes the entire web page to freeze, and then you'll be digging through the debugger's console trying to spot and reproduce what's going on. It's not even fast compared with the Android app despite not having to download to a device. I guess that makes responsive, fast UIs in Javascript applications like GMail even more impressive to me now than they were in the past.
In the old days, web applications used to have 3 tiers: the client, the application server, and the database. The application server would keep tracks of things like sessions and cookies, using the database only for persistent data. The "new" approaches are forked into 2 types: the single page Javascript-oriented web application (which Firebase was designed to facilitate), where the client web-browser's Javascript engine would keep track of all the state, and went directly to the database for persistent data, and the REST-ful approach, where each click on a link would encode all the session data so that the application server was essentially stateless and didn't have to maintain state for the client. Both approaches eliminate the scaling problems of the traditional 3-tier approach, but introduced several new problems of their own, as I was about to find out.
My first thought was to try it using GWT. GWT had several nice features: one would have been that I wouldn't have to learn any Javascript. Another was a one-click deploy into Google's App Engine, which was also very appealing. Finally, I'm a big fan of static type-checking being able to eliminate an entire class of bugs.
Imagine my disappointment when I discovered that there was no integration package between Firebase and GWT whatsoever. OK, no problem, I could write my own wrapper around the Firebase javascript stuff and GWT. I tried that and discovered that Javascript objects passed into the GWT Java code became opaque objects that couldn't be used! This was very disappointing. I was even more disappointed when I discovered that it also made debugging very painful --- the GWT-generated Javascript was even more impenetrable than I imagined, and I'd have to end up learning Javascript anyway to do any kind of intense debugging. So I gave up on GWT and went full-on into writing a Javascript single-webpage web application.
Not being much of a UI guy, I looked around for a Javascript UI library, and found webix. The Treeview looked like exactly what I wanted, and I jumped right into using it. As with the Android App, the Firebase Web API (really Javascript API --- there's no server->server integration in Firebase land) is callback-oriented.
This is really weird, since if I wanted to get the user to Login right away, there's no easy way to say, "Hey, show this UI only after the user's done logging in." I tried some forms of deferred execution, but there's a real weird interaction between "login using a popup window" and the use of the Javascript firebase API.
In the end, I got it all to work, but it was clunky. For instance, I was forced to pop up dialog boxes, etc., to get the user to input a new checklist, or even a new checklist item. This was unsatisfying: in practice, I wanted people to be able to push a "+" button somewhere on the tree and then edit a text-field inline like in the Android app. But since Webix wasn't really designed to do so without you jumping in and modifying the code, I couldn't easily do this. In the end I stuck with dialog boxes all over the place.
All in all, I'm definitely unsatisfied with the result. The debugging was also a pain: any kind of error in the Javascript causes the entire web page to freeze, and then you'll be digging through the debugger's console trying to spot and reproduce what's going on. It's not even fast compared with the Android app despite not having to download to a device. I guess that makes responsive, fast UIs in Javascript applications like GMail even more impressive to me now than they were in the past.
Labels:
computers,
programming
Tuesday, November 08, 2016
Building Shared Checklists (Part 1): The Android App
After determining that there's no app that did what I wanted, I decided to create Shared Checklists, which was an Android app that does do what I want.
I started with an Android app, since I did some development for my wife's app a year or so ago. The requisite tools are all free: Android Studio, my Windows PC, and my already registered custom domain. At first, I thought that I would have to write all the cloud-syncing code, but this being 2016, it turned out that I didn't have to: Firebase (acquired by Google in 2014) did all this fancy cloud-synchronization.
This is ironic, because as a back-end guy, the development of a cloud-database with syncing capability would have been fun for me, as opposed to the mostly UI-oriented development that an Android app would turn out to be.
Firebase's real-time database is a JSON-tree in-cloud database that lets you get at any subtree as a Java object inside an Android app, or treat each leaf-node as a subfield at whatever granularity you wanted. This is very nice: you get to do a write() using a Java object and have the serialization all done for you.
The penalty to this is that the Firebase API is a callback-oriented API. What this means is that updates coming in from the cloud can happen at any time, and you need to update the App's UI to reflect that. If not coded carefully, this can turn into a mess of synchronization bugs and crashes (not a surprise, right)? Even when coded correctly, you could spend a lot of time working through UI glitches, etc.
I started with a basic simple approach: a sequence of Android activities (screens) in which you deal with one aspect of the real-time database at a time: there'd be a checklist management screen, and a checklist screen. The checklist screen would let you add and remove items from a given checklist, while the checklist management screen would handle adding new checklists, sharing new checklists, and deleting checklists.
This was all pretty good: I eventually figured out that the Android App UI needed to be a dumb reflection of whatever the database was seeing, and rather than screwing around with the UI's model whenever the user made an edit or a change, I would just reflect the change in the real-time database in the cloud, and let the inevitable notifications filter down and then refresh the UI based on the cloud-activated events.
One surprising pain point was integration with cloud single-signon services. I don't know about you, but I get very annoyed now with apps and/or websites that force me to create an account. Don't make me create yet one more (likely insecure) password for your website. Make use of Facebook login or Google login services.
Facebook login was surprisingly easy. I basically got it working on the first try, which was pretty awesome. Again, it's a callback-oriented API, so I had to jump through hoops and play all sorts of tricks to get the UI to force the user to login first before I could show the contents. And that was OK. One major pain point is the integration between a database-oriented app and Android's concepts of activity screens and restore events. The documentation is horrible, and when restored from a stopped state, there's every chance that the real-time database connection had been severed! My quick and dirty solution was to basically force a Firebase reconnect and authentication every time the app was resumed from a stopped state. It's not very satisfying, but from a development point of view it was the easiest way to prevent crashes. Android studio has no way of simulating this sort of event, so it was a major pain doing it manually, fixing the crashes, and then attempting to get the OS to evict the process again. You would think that Android Studio would have a means of injecting such events into your app for testing purposes, but no.
Google sign-in integration, however, was a nightmare. Superficially, the steps seem similar. In reality, what you have to do is to run a backend server somewhere, serving a particular JSON file with certain values. You'd think that Google would automate this for someone who was running an app-engine backend on a Google hosted custom domain, but no dice. It could never get it to work! I eventually gave up completely and stuck with just Facebook login. This, by the way, now explains to me why you see Facebook login everywhere, while non-Google sites don't tend to provide Google login: the process is sufficiently onerous that you can't expect the typical web-site maintainer to use it.
After using the app for a couple of days, I grew unsatisfied with the UI. Upon reflection, I realized that the Navigation Drawer approach was the correct UI for the app. This effectively required a rewrite for the entire app to use the new approach. It was only a little painful: every Activity had to be turned into a Fragment, and then I had to rejigger some of the database schema to reflect the new approach. This approach also eliminated an entire class of bugs related to having a default checklist, so I was relatively happy with the end result.
In the end, the experience was surprisingly good. While Android Studio's layout tool still leaves much to be desired (and to be honest, for it to be a useful tool would require some sort of standardization of device that's pretty much impossible in the Android universe), it was usable most of the time. The compilation time had now sped up to the point where a full signed APK build took only 35s or so, while incremental debug builds during the crucial edit/compile/debug cycle was now under 3s. In practice, that was fast enough that the transfer to my debug device over USB was now as much of a bottleneck as build time.
All in all, given that the entire tool chain was free, I thought this was relatively satisfying as a hobbyist project.
I started with an Android app, since I did some development for my wife's app a year or so ago. The requisite tools are all free: Android Studio, my Windows PC, and my already registered custom domain. At first, I thought that I would have to write all the cloud-syncing code, but this being 2016, it turned out that I didn't have to: Firebase (acquired by Google in 2014) did all this fancy cloud-synchronization.
This is ironic, because as a back-end guy, the development of a cloud-database with syncing capability would have been fun for me, as opposed to the mostly UI-oriented development that an Android app would turn out to be.
Firebase's real-time database is a JSON-tree in-cloud database that lets you get at any subtree as a Java object inside an Android app, or treat each leaf-node as a subfield at whatever granularity you wanted. This is very nice: you get to do a write() using a Java object and have the serialization all done for you.
The penalty to this is that the Firebase API is a callback-oriented API. What this means is that updates coming in from the cloud can happen at any time, and you need to update the App's UI to reflect that. If not coded carefully, this can turn into a mess of synchronization bugs and crashes (not a surprise, right)? Even when coded correctly, you could spend a lot of time working through UI glitches, etc.
I started with a basic simple approach: a sequence of Android activities (screens) in which you deal with one aspect of the real-time database at a time: there'd be a checklist management screen, and a checklist screen. The checklist screen would let you add and remove items from a given checklist, while the checklist management screen would handle adding new checklists, sharing new checklists, and deleting checklists.
This was all pretty good: I eventually figured out that the Android App UI needed to be a dumb reflection of whatever the database was seeing, and rather than screwing around with the UI's model whenever the user made an edit or a change, I would just reflect the change in the real-time database in the cloud, and let the inevitable notifications filter down and then refresh the UI based on the cloud-activated events.
One surprising pain point was integration with cloud single-signon services. I don't know about you, but I get very annoyed now with apps and/or websites that force me to create an account. Don't make me create yet one more (likely insecure) password for your website. Make use of Facebook login or Google login services.
Facebook login was surprisingly easy. I basically got it working on the first try, which was pretty awesome. Again, it's a callback-oriented API, so I had to jump through hoops and play all sorts of tricks to get the UI to force the user to login first before I could show the contents. And that was OK. One major pain point is the integration between a database-oriented app and Android's concepts of activity screens and restore events. The documentation is horrible, and when restored from a stopped state, there's every chance that the real-time database connection had been severed! My quick and dirty solution was to basically force a Firebase reconnect and authentication every time the app was resumed from a stopped state. It's not very satisfying, but from a development point of view it was the easiest way to prevent crashes. Android studio has no way of simulating this sort of event, so it was a major pain doing it manually, fixing the crashes, and then attempting to get the OS to evict the process again. You would think that Android Studio would have a means of injecting such events into your app for testing purposes, but no.
Google sign-in integration, however, was a nightmare. Superficially, the steps seem similar. In reality, what you have to do is to run a backend server somewhere, serving a particular JSON file with certain values. You'd think that Google would automate this for someone who was running an app-engine backend on a Google hosted custom domain, but no dice. It could never get it to work! I eventually gave up completely and stuck with just Facebook login. This, by the way, now explains to me why you see Facebook login everywhere, while non-Google sites don't tend to provide Google login: the process is sufficiently onerous that you can't expect the typical web-site maintainer to use it.
After using the app for a couple of days, I grew unsatisfied with the UI. Upon reflection, I realized that the Navigation Drawer approach was the correct UI for the app. This effectively required a rewrite for the entire app to use the new approach. It was only a little painful: every Activity had to be turned into a Fragment, and then I had to rejigger some of the database schema to reflect the new approach. This approach also eliminated an entire class of bugs related to having a default checklist, so I was relatively happy with the end result.
In the end, the experience was surprisingly good. While Android Studio's layout tool still leaves much to be desired (and to be honest, for it to be a useful tool would require some sort of standardization of device that's pretty much impossible in the Android universe), it was usable most of the time. The compilation time had now sped up to the point where a full signed APK build took only 35s or so, while incremental debug builds during the crucial edit/compile/debug cycle was now under 3s. In practice, that was fast enough that the transfer to my debug device over USB was now as much of a bottleneck as build time.
All in all, given that the entire tool chain was free, I thought this was relatively satisfying as a hobbyist project.
Labels:
computers,
programming
Monday, November 07, 2016
Texting and Parenting
I've discovered that I'm getting less and less enamored of texting as a communications medium whenever I have to spend time with my kids. A lot of it is because I usually need both hands to deal with Bowen and/or Boen, and texting is never hands free. In fact, it's a major distraction as I'd need to look at the phone, and of course with modern touch screen phones you can't even type "ok" without using your hands and looking at the screen.
In theory, text-to-speech and voice recognition should make texting as easy as a phone call, but the reality is that voice recognition is pretty awful on today's phones. I think I've narrowed it down to the microphone on phones not being in the right place whenever you need to be hands free, as the Amazon Echo, for instance, with its multiple microphones had zero issues with speech recognition.
As a result of using a bluetooth headset, I no longer fear long hold times on phone queues, nor do I fear phone calls from friends and family, but text messages (whether from hangouts, facebook, or even SMS) now elicit annoyance. With my Vivoactive, it's no big deal to at least read some of those messages, but of course, responding is still pretty much a "both hands and eyes on screen" affair.
As such, if you discover that I no longer respond to text messages with the speed, and it's convenient for you, ask me if I'd rather take a phone call. You might discover that the answer is "yes," surprisingly often.
In theory, text-to-speech and voice recognition should make texting as easy as a phone call, but the reality is that voice recognition is pretty awful on today's phones. I think I've narrowed it down to the microphone on phones not being in the right place whenever you need to be hands free, as the Amazon Echo, for instance, with its multiple microphones had zero issues with speech recognition.
As a result of using a bluetooth headset, I no longer fear long hold times on phone queues, nor do I fear phone calls from friends and family, but text messages (whether from hangouts, facebook, or even SMS) now elicit annoyance. With my Vivoactive, it's no big deal to at least read some of those messages, but of course, responding is still pretty much a "both hands and eyes on screen" affair.
As such, if you discover that I no longer respond to text messages with the speed, and it's convenient for you, ask me if I'd rather take a phone call. You might discover that the answer is "yes," surprisingly often.
Friday, November 04, 2016
Review: BLU R1 HD 16GB Prime Exclusive Smartphone
I had an App project that required 2 phones to test, and I was looking to buy the cheapest Android phone for testing. Amazon offered the BLU R1 HD, with the 16GB Storage/2GB RAM model going for $60. The 8GB/1GB model goes for $50. The catch is that the phone comes with Amazon ads scattered everywhere, and is pre-loaded with Amazon apps.
For the price, I expected a slow, balky phone, but that was OK --- I wanted a phone just for testing, and I didn't care about performance. That it was unlocked was a bonus.
Instead, the phone impressed me. It was fast (almost as fast as my Moto G, and for development purposes I can't tell the difference), and almost immediately updated its OS, connecting to my WiFi without a SIM installed. The ads, while they show up on the home screen, don't bother me at all.
The places where costs are cut are the camera (which is relatively low quality, but good enough for receipts, etc) and the USB port: while my Moto G had no problem serving as a USB host for external flash drives, etc., the BLU R1 HD doesn't. And of course, the Moto G is waterproof. But for the same price, you can buy 3 of the BLU R1 HD! Compared to the Moto E, of course, the BLU R1 HD is superior --- there's no reason you should pay for a Moto E when you can get the BLU for the same price or less.
By the way, I looked into getting a tablet instead so I could test a bigger screen size. No dice --- the decent ones cost way more than the equivalent phones. I guess tablet sales have fallen off a cliff so there's no economy of scale there any more.
Recommended. It's a great development phone and a good general use phone.
For the price, I expected a slow, balky phone, but that was OK --- I wanted a phone just for testing, and I didn't care about performance. That it was unlocked was a bonus.
Instead, the phone impressed me. It was fast (almost as fast as my Moto G, and for development purposes I can't tell the difference), and almost immediately updated its OS, connecting to my WiFi without a SIM installed. The ads, while they show up on the home screen, don't bother me at all.
The places where costs are cut are the camera (which is relatively low quality, but good enough for receipts, etc) and the USB port: while my Moto G had no problem serving as a USB host for external flash drives, etc., the BLU R1 HD doesn't. And of course, the Moto G is waterproof. But for the same price, you can buy 3 of the BLU R1 HD! Compared to the Moto E, of course, the BLU R1 HD is superior --- there's no reason you should pay for a Moto E when you can get the BLU for the same price or less.
By the way, I looked into getting a tablet instead so I could test a bigger screen size. No dice --- the decent ones cost way more than the equivalent phones. I guess tablet sales have fallen off a cliff so there's no economy of scale there any more.
Recommended. It's a great development phone and a good general use phone.
Labels:
computers,
recommended,
reviews
Thursday, November 03, 2016
Review: PRO BIKE TOOL Mini Bike Pump
For my mountain bike, I decided that the Topeak Morph pump was too big, and I wanted something smaller. Since mountain bikes don't go to as high a pressure as road bikes, I didn't need the elegant fold-down "turns into a floor pump" design.
The PRO BIKE TOOL Mini Bike Pump got good reviews on Amazon, so I gave it a shot. It should have known better. Bike pumps, like bike computers and lights, are one of those places where even if you don't 'care about the major functionality, the mount is way more important.
I've used the pump a few times (never in anger --- always because I have a road ride just before or after a trail ride), and it serves its purpose, barely. What I've observed from other cyclists who have this is that if you have a large snake bite, the pump doesn't move enough volume for you to pump it up fast enough so it's easy to see where the leak is. The Topeak Morph pumps (even the tiny ones) do so.
But the biggest ding against the pump is the mount. I've had less than a year of use out of the pump, and it's already broken. This is beyond ridiculous. Lesson learned. Don't buy pumps that are not named "Topeak .* Morph".
The PRO BIKE TOOL Mini Bike Pump got good reviews on Amazon, so I gave it a shot. It should have known better. Bike pumps, like bike computers and lights, are one of those places where even if you don't 'care about the major functionality, the mount is way more important.
I've used the pump a few times (never in anger --- always because I have a road ride just before or after a trail ride), and it serves its purpose, barely. What I've observed from other cyclists who have this is that if you have a large snake bite, the pump doesn't move enough volume for you to pump it up fast enough so it's easy to see where the leak is. The Topeak Morph pumps (even the tiny ones) do so.
But the biggest ding against the pump is the mount. I've had less than a year of use out of the pump, and it's already broken. This is beyond ridiculous. Lesson learned. Don't buy pumps that are not named "Topeak .* Morph".
Wednesday, November 02, 2016
Review: Cognitive Behavioral Therapy (Great Courses)
The subtitle to the Great Courses's video series for Cognitive Behavioral Therapy is "Techniques for Retraining Your Brain." That sounded so exciting that I checked it out from the library. The instructor, Professor Jason M. Satterfield, is affiliated with UCSF, so comes with great credentials.
The target audience for this course isn't clear. Is it for the person looking to become a therapist? Is it for a patient looking to see which type of therapy suits him or her best? Is it for someone looking to acquire new habits? That's completely unclear. As a result I spent the first couple of episodes kinda confused, but then got into it.
The idea behind cognitive behavioral therapy (CBT) is that traditional therapy is open-ended, doesn't have any hard end-points, and all too focused on digging deep into the human psyche without providing any relief from the symptoms the patient is suffering from. That's great for producing a continuous stream of revenue from a few patients, but if your goal is to help as many people as possible, it's unsatisfying.
CBT differs from this in having completely different goals:
The target audience for this course isn't clear. Is it for the person looking to become a therapist? Is it for a patient looking to see which type of therapy suits him or her best? Is it for someone looking to acquire new habits? That's completely unclear. As a result I spent the first couple of episodes kinda confused, but then got into it.
The idea behind cognitive behavioral therapy (CBT) is that traditional therapy is open-ended, doesn't have any hard end-points, and all too focused on digging deep into the human psyche without providing any relief from the symptoms the patient is suffering from. That's great for producing a continuous stream of revenue from a few patients, but if your goal is to help as many people as possible, it's unsatisfying.
CBT differs from this in having completely different goals:
- Specific treatment of symptoms and behaviors that the patient would like to change
- Providing tools for the patient to use, so that when he/she leaves therapy, he/she can continue to use those tools to prevent relapse or help himself/herself.
- Specific end point in mind. Since the goal is self-sufficiency and self-treatment, once those symptoms are relieved, the patient gets off the therapy, with only occasional checkups.
The tools CBT provide are very secular and focused:
- Capture a thought diary, so that triggering situations can be analyzed and dissected at a distance.
- Note that thoughts are opinions, and strength of emotion doesn't necessarily mean that the opinions are true.
- Attack those opinions using three approaches: (1) experiment with behavioral changes to prove those opinions false (2) stand from a distance to see if you can reinterpret the same events in a different way (3) make a prediction of whether you'll enjoy a new activity, and then re-evaluating that activity after you've done it to show that what you rated as being unenjoyable turned out to be good
Throughout the videos, the course examines 3 patients struggling with different behavioral issues: one of severe shyness, one with managing anger, and one with depression. We watch each of them deal with their problems, run experiments with changing behavior, and reflecting and evaluating the results of their experiments. Throughout the program, the patients are treated with respect, sympathy, and encouraged to solve their problems through a toolbox. There's no hocus-pocus involved. Some of the exercises involved:
- Muscle relaxation (progressive relaxation of muscle)
- A mindfulness based approach of meditation --- including talking to yourself. This seemed very new-agey to me, but hey, if it works, it works.
Throughout the entire course, Dr. Satterfield provides pointers to further books, studies and results. Don't expect to be super impressed by the numbers. A success rate of 30% in treatment is considered good as far as psychotherapy is concerned. If you think about it, that makes sense. Think about trying to change a habit, like eating less calories so you can lose weight. Lots of people try, but very few manage to do so. Illnesses like depression, a hair-trigger temper, or severe shyness would be even harder.
Nevertheless, it's an interesting no-nonsense approach that I'd never even heard of before. It's well worth checking out, especially if (like me), your former impression of psychotherapy is Freudian mumbo-jumbo.
Labels:
health,
recommended,
reviews
Tuesday, November 01, 2016
Return to the Santa Cruz Factory Demo
It's been a year since my last Santa Cruz Factory Demo, and I've had enough riding under my belt on my mountain bike that it was worthwhile for me to try another demo to see if dual suspension bikes were any good.
I convinced 2 of my friends to come along, Eva Silverstein, who booked a Furtado. I booked a Tallboy for myself, but apparently had taken the last one, so had no choice but to book a Bronson for Arturo. It turned out that the Bronson was the higher end bike, but I'd actually wanted Arturo to try a 29er bike. Nevertheless, the 27.5" wheels were still substantially bigger than his 26" wheels.
We took a modified version of the ride I did with Arturo last time. This time, we did the Enchanted Loop twice, because the first time I did it, I accidentally rode it with the rear shock locked out! This gave me a good contrast, however, between what I would expect from a dual suspension bike and what a similarly weighted hard tail would do.
The most impressive thing about the dual suspension bike is how easy it made everything. Now, it's not a miracle --- I still couldn't do the kind of jumps that I couldn't do before, but it made all the jumps and drops I could do easier. In addition, at the end of the ride neither me nor my friends were as beat up as on hard tails, so I led them on a ride along the cliff-sides of wilder ranch as well.
The next day, I went over to El Corte Madera Park to ride a loop with my regular hardtail mountain bike (about $9000 cheaper than the Bronson Arturo rode if you're comparing MSRP).
El Corte Madera Park is a much more technical ride than Wilder Ranch. While Wilder Ranch is for beginners, the drops on El Corte Madera let you catch serious air if you're good. What I noticed was that while I was very fast at the beginning, as the ride wore, my fatigue made me less willing to do challenging stuff on my bike. On the dual suspension bike, I would have been more willing to ride more challenging material. For some of the super drops, my hard tail would be buckling like a bronco while the full suspension bike would be much more sedate.
In the end, while there's no question that the $6000+ MSRP bikes are better than my cheapie $700 eBay special, it's not clear that they're $5,000 better. Mountain bikes reward skill and finesse a lot more than road bikes do (and from an economic point of view, road cyclists can get their per mile cost down into the dimes per mile, which mountain bikes cannot easily do even with cheap mountain bikes like mine), so I'm unlikely to buy one of these new. I did notice that the eBay prices for the same bikes that are a year old are more than 50% off the MSRP, indicating that the first year depreciation of these bikes are ridiculous. Of course, buying a used carbon MTB comes with its own set of crazy hassles.
Of course, a $20 rental of the same bike is such an amazing deal that I'd urge you to try a factory demo for yourself!
I convinced 2 of my friends to come along, Eva Silverstein, who booked a Furtado. I booked a Tallboy for myself, but apparently had taken the last one, so had no choice but to book a Bronson for Arturo. It turned out that the Bronson was the higher end bike, but I'd actually wanted Arturo to try a 29er bike. Nevertheless, the 27.5" wheels were still substantially bigger than his 26" wheels.
Labels:
cycling,
recommended
Monday, October 31, 2016
4 Starbucks Coffee Beans Reviews
I tend to buy coffee beans when they're discounted at Costco, Target, or Amazon rather than be picky about coffee. As a result, I end up getting to sample various beans. There was a recent rash of deals, so I tried out 4 types. I'll provide capsule reviews below:
- Breakfast Blend: Surprisingly good. Not bitter, relatively easy to drink. A bit oily.
- Veranda Blend: After various over-roasted American-style coffee beans, this one's great. Not bitter, not oily, with a faint chocolate aroma. Recommended. It's a pity it's so hard to find lightly roasted coffees on sale.
- Starbucks House Blend: Over-roasted and oily. Fairly neutral taste. Unremarkable.
- Yukon Organic Blend: Bitter. Oily. Not Recommended.
So far, I've yet to find anything really better than Magnum Jamaica Blue Mountain Coffee. It's fairly cheap from Costco (cheaper than any of the above when they're not on sale), and not oily.
Friday, October 28, 2016
Review: Cressi Galileo
My go-to goggles for the last 3 years, the Aquasphere Kayenne, have basically had to be replaced every year or so. The failure mode is that the goggles' lenses fade or scratch, or become fogged up. When I looked at them, I realized that I'd seen similar patterns of failure before --- on Mazda Miata models that had a plastic rear window rather than glass.
At first, I thought that if I couldn't make these expensive goggles work, I could go ultra-cheap. Swedish-style goggles from swimoutlet.com only cost $3.50. But after I bought a pair I couldn't get them to not leak, no matter what. They also felt extremely uncomfortable, feeling as though they might pop my eyeballs out.
I noticed that my own diving/snorkeling masks are made out of tempered glass, and don't suffer from the fogging, so I set about looking for tempered glass goggles. To my surprise, an internet search revealed that there was only one model of tempered glass goggles: the Cressi Galileo. To add insult to injury, those cannot be purchased on Amazon.com, and I had to import them from Amazon.co.uk instead, costing about $30 after shipping fees.
When I received them, I was dismayed --- they were definitely sized big, and they were heavy. I tightened the strap all the way and managed to get a secure fit. Then they fogged up in the swimming pool. That's actually not a problem, since because these are tempered glass, you can apply toothpaste to the lenses and then they'll never fog again. That's what I did, and indeed, it worked. These are the clearest lenses you'll ever get, and again, because they're tempered glass, the UV will never fog them.
They're heavier than standard plastic-lensed swimming goggles. But so what? They're more comfortable (the skirt around them are more like those used for diving masks than goggles), they'll probably slow me down in the water by a couple of seconds each lap, but I'm not winning any prizes for swimming anyway. What's more important, they can serve as a backup to my diving mask for snorkeling. They aren't a real backup for diving, since diving masks need to cover the nose so you can equalize pressure under water.
At first, I thought that if I couldn't make these expensive goggles work, I could go ultra-cheap. Swedish-style goggles from swimoutlet.com only cost $3.50. But after I bought a pair I couldn't get them to not leak, no matter what. They also felt extremely uncomfortable, feeling as though they might pop my eyeballs out.
I noticed that my own diving/snorkeling masks are made out of tempered glass, and don't suffer from the fogging, so I set about looking for tempered glass goggles. To my surprise, an internet search revealed that there was only one model of tempered glass goggles: the Cressi Galileo. To add insult to injury, those cannot be purchased on Amazon.com, and I had to import them from Amazon.co.uk instead, costing about $30 after shipping fees.
When I received them, I was dismayed --- they were definitely sized big, and they were heavy. I tightened the strap all the way and managed to get a secure fit. Then they fogged up in the swimming pool. That's actually not a problem, since because these are tempered glass, you can apply toothpaste to the lenses and then they'll never fog again. That's what I did, and indeed, it worked. These are the clearest lenses you'll ever get, and again, because they're tempered glass, the UV will never fog them.
They're heavier than standard plastic-lensed swimming goggles. But so what? They're more comfortable (the skirt around them are more like those used for diving masks than goggles), they'll probably slow me down in the water by a couple of seconds each lap, but I'm not winning any prizes for swimming anyway. What's more important, they can serve as a backup to my diving mask for snorkeling. They aren't a real backup for diving, since diving masks need to cover the nose so you can equalize pressure under water.
Thursday, October 27, 2016
Review: LG Tone 750
It was inevitable: I left my Sony SBH-52 in my pocket and it went into the laundry. The darn thing is water resistant, but IPX-68 will not guarantee survival in a washing machine for an hour. This forced me to dig up the LG Tone 750 which I got as a promotion a year or so ago but never even opened the box.
This was my first time using the "around the collar" blue tooth headphone format. Compared to the SBH-52, it has the following advantages:
This was my first time using the "around the collar" blue tooth headphone format. Compared to the SBH-52, it has the following advantages:
- It falls off when you take off your shirt, so you're not going to accidentally leave it in your pockets.
- It's too big to fit in your pockets, so you can't accidentally leave it in your pockets.
- The headphone never gets tangled up. In fact, most of the time I leave them dangling from the headset instead of snapping them back into their magnetic mounts, and they don't even get tangled.
- The buttons are easier to manage. In particular, the "call" button activates Google Now, which is very cool. The play/pause fast-forward buttons are all easier to find and remember because they're placed on separate sides of the headphone.
- There's no display. This turned out to be a great feature, as it forced LG to provide battery level announcements, etc., whenever you turn on and off the headset.
- It's smart about the playback. For instance, if I pair this to my Moto G, and then plug in the headphone jack to my car, I can still use the buttons on the headset to control the music even though the playback's being done by the car's loudspeakers.
- The collar is a much more convenient location than the clip the SBH-52 provides.
Against this, there are several disadvantages:
- You can't use your own headphones. This would suck if the built in earbuds sucked. But they don't, so I'm OK with it.
- You can't use the LG Tone while charging.
- The volume control is practically non existent. Pushing volume up or down doesn't seem to do much. The default volume is fine, but I found myself having to reach over to the phone's volume control whenever I wanted to turn it up or down.
- It's not a great cycling solution. While cycling, the device bounces up and down on my collarbone. This sucks. I cannot use this while riding any significant distance, but if it's say, riding to the local store to get milk, it's still usable.
All in all, the disadvantages are more than outweighed by the advantages, so I'd recommend this headset.
Labels:
computers,
music,
recommended,
reviews
Wednesday, October 26, 2016
Review: Every Heart a Doorway
I was disappointed by Seanan McGuire's previous books that were reviewed here on this blog. Her narrators have always seemed too flippant for me. What's great about McGuire, however, is that her concepts are always great. In short, she has (for me, anyway), great elevator pitches for her novels but lousy follow-through on the implementation.
Every Heart A Doorway, however, has such a great elevator pitch I checked out the book from the library despite my previous history with her novels. I'm glad I did, because just this once, the implementation is decent.
Part of it is that the novel is short (175 pages), so the pace is very fast. The elevator pitch for the novel is: "Girl walks through fantasy portal into another world, has adventures, gets kicked out of fantasy world, and now has to go through rehab for PTSD induced by said fantasy world adventures."
The novel's setting is Eleanor West's Home for Wayward Children, a boarding school for kids who've been through adventures in an alternate world and a dumping ground for the parents who can no longer reconcile themselves to their changed children. Eleanor West, the school mistress, was herself one of those kids, and her school markets itself to parents by claiming to provide special therapy.
In reality, of course, the school is a place where the kids themselves can feel at home because they can relate to other children who've had similar adventures. The novel's protagonist is Nancy, a girl who's been to the Land of the Dead and is now returned to the world of the living but discover that her new manner and fashion preferences are not those that her parents want.
Through the protagonist, we learn how such as school is structured, a classification of the fantasy worlds in which the kids have been to, and of course, the messy social structure the kids themselves have as a result of their adventures, forming into cliques that are driven by which type of world they've come to call home.
There's a central plot and overarching storyline in the middle of all this, the pace is fast, and the extrapolation of the elevator pitch admirable. This novel is a lot of fun, and redeems McGuire's previous misses in my eyes. Recommended!
Every Heart A Doorway, however, has such a great elevator pitch I checked out the book from the library despite my previous history with her novels. I'm glad I did, because just this once, the implementation is decent.
Part of it is that the novel is short (175 pages), so the pace is very fast. The elevator pitch for the novel is: "Girl walks through fantasy portal into another world, has adventures, gets kicked out of fantasy world, and now has to go through rehab for PTSD induced by said fantasy world adventures."
The novel's setting is Eleanor West's Home for Wayward Children, a boarding school for kids who've been through adventures in an alternate world and a dumping ground for the parents who can no longer reconcile themselves to their changed children. Eleanor West, the school mistress, was herself one of those kids, and her school markets itself to parents by claiming to provide special therapy.
In reality, of course, the school is a place where the kids themselves can feel at home because they can relate to other children who've had similar adventures. The novel's protagonist is Nancy, a girl who's been to the Land of the Dead and is now returned to the world of the living but discover that her new manner and fashion preferences are not those that her parents want.
Through the protagonist, we learn how such as school is structured, a classification of the fantasy worlds in which the kids have been to, and of course, the messy social structure the kids themselves have as a result of their adventures, forming into cliques that are driven by which type of world they've come to call home.
There's a central plot and overarching storyline in the middle of all this, the pace is fast, and the extrapolation of the elevator pitch admirable. This novel is a lot of fun, and redeems McGuire's previous misses in my eyes. Recommended!
Labels:
books,
recommended,
reviews
Tuesday, October 25, 2016
Review: The Martian Child (Original Novelette)
The Martian Child won both the Hugo and Nebula awards the year it came out, but somehow I didn't notice. It wasn't available at any of my local libraries, so I paid the Kindle price for it and read it in a couple of hours.
It's short, well-written, but is clearly autobiographical. The author, David Gerrold is famous for the Star Trek episode: "The Trouble with Tribbles", but clearly chooses to portray himself as a neurotic artist, rather than a rational computer programmer (which he is apparently able to be). He writes about his decision to adopt, his encounter with his (eventual) adoptee, and the process of adoption itself.
In many ways, I'm disappointed by the novelette. Yes, it's poignant, but there's no deep insight about parenting, no mention of the deep challenges involved. I think I got way more from a 5 minute conversation with one of my college lecturers in passing than from the entire novel.
Not recommended.
It's short, well-written, but is clearly autobiographical. The author, David Gerrold is famous for the Star Trek episode: "The Trouble with Tribbles", but clearly chooses to portray himself as a neurotic artist, rather than a rational computer programmer (which he is apparently able to be). He writes about his decision to adopt, his encounter with his (eventual) adoptee, and the process of adoption itself.
In many ways, I'm disappointed by the novelette. Yes, it's poignant, but there's no deep insight about parenting, no mention of the deep challenges involved. I think I got way more from a 5 minute conversation with one of my college lecturers in passing than from the entire novel.
Not recommended.
Monday, October 24, 2016
Review: The Hard Thing about Hard Things
I was all prepared to find The Hard Thing About Hard Things disappointing. CEO books are frequently about self-aggrandizement (e.g., Richard Branson's memoir) and rarely give you advice you can use. Horowitz's book, however, turned out to be a rare breath of fresh air.
Sure, there's a certain amount of bragging in the book (taking a company to $1.6B is no mean feat, and Horowitz isn't ashamed to take credit for it), but that's not why you should read books anyway. You read books for practical tips that will let you avoid making mistakes when hiring, firing, or screwing up. One avoided bad hire at the executive will more than pay for the time you spend reading this book, so in that respect the book's more than well worth your time.
The book's intended audience is the CEO of a technology company. It doesn't really
Here are a few insights from my reading of the book:
Sure, there's a certain amount of bragging in the book (taking a company to $1.6B is no mean feat, and Horowitz isn't ashamed to take credit for it), but that's not why you should read books anyway. You read books for practical tips that will let you avoid making mistakes when hiring, firing, or screwing up. One avoided bad hire at the executive will more than pay for the time you spend reading this book, so in that respect the book's more than well worth your time.
The book's intended audience is the CEO of a technology company. It doesn't really
Here are a few insights from my reading of the book:
- When hiring an executive, focus on whether his strengths fits your needs, rather than avoiding weaknesses. For that to work, you have to have a strong idea of what you need in that executive. Unfortunately, there's no easy way to get that insight, other than by running the organization that you need him to run for a while --- but that's OK. Better to get it the hard way than by randomly hiring people! (Note that there's a lack of emphasis on avoiding people with no integrity --- Horowitz assumes you know that and doesn't spend any time on it)
- When hiring anyone (executive or not), don't ask questions like: "He's great for the job right now, but will he scale as the company scale?" Those questions lead you to make prejudicial judgements about your executive. There's no way to know whether anyone can "scale" in a particular way, so the best thing to do is to be honest and say, "I'm looking for the best fit for the current job. Next year, if the company changes, we'll still be looking for the best fit for that job. This applies to everyone in the company, even me!"
Deciding (with woefully incomplete data) that someone who works their butt off, does a terrific job, and loyally contributes to your mission won’t be with you three years from now takes you to a dark place. It’s a place of information hiding, dishonesty, and stilted communication. It’s a place where prejudice substitutes for judgment. It’s a place where judgment replaces teaching. It’s a place where teamwork becomes internal warfare. Don’t go there. (Kindle Loc. 2887)
- Training is a competitive advantage for startups. Don't outsource your training. In particular, you need to get your best people involved in training new people. In order to do that, however, you have to make training seem valued. The best way to do so is for the CEO to spend time training others, to lead by example. Training is also where you set expectations for your team. In particular, Horowitz include a training document he wrote for Opsware called "Good Product Manager/Bad Product Manager". In it, he defines what a product manager does, what best practices are, and how product managers will be evaluated. It's a great document that defines what a product manager does.
- Managing politics is counter-intuitive for the CEO. You have to actively manage it by setting up processes, whether it's for performance evaluation, pay raises, or promotion opportunities. If you do not do so, expect everyone on the executive team to become a squeaky wheel and playing politics. That means that the more actively non political you try to be by avoiding the usual big company BS, the more you encourage politics as people try to achieve the same goals out of band.
- Similarly, the CEO has to actively give feedback all the time. Again, this is counter-intuitive, since typically people managers are generally told to provide feedback in a "shit-sandwich" fashion --- sandwich the negative feedback between the positive feedback. The problem with the latter approach is that experienced executives see through this right away, so the only way to be consistent is to provide both positive and negative feedback as soon as you see work that deserves it.
- Organizations and Processes should be designed for the sake of the employee at the leaf node level, not for the sake of the managers. In other words, when designing or reorganizing a company, you should consider what it's like being a customer support rep or an engineer, rather than what it's like being one of the managers having to work in the environment. This may seem obvious, but keep in mind that most CEOs hang out mostly with executives and rarely reach down to the leaf nodes where people actually do the work, so it makes sense for Horowitz to emphasize this point. Furthermore, Horowitz makes the great point that organization designs all suck --- you're basically optimizing certain paths of communications between organizations while making certain other communication paths harder or even not happen at all. What this means is that along with the organization design you'll have to put into effect a plan to monitor the issues arising from the consciously designed sub-optimal paths so that if things get too bad you can redesign or hack around it.
There are other things that Horowitz say that I felt aren't necessary expressed well or are too general to be practical:
- He makes the distinction between a wartime CEO and a peacetime CEO. While that distinction has some merit, I'm not sure it makes a ton of sense. For instance, Steve Jobs was an effective asshole (and effectively an asshole) even when Apple was no longer fighting for survival. I wonder how many CEOs are going to use this chapter as a justification for being a jerk to everyone around them.
- There's an assumption that the CEO is technical, so the book doesn't discuss engineering management or the challenges peculiar to engineering management. I'm OK with that, since I did actually write a book about engineering management.
- The book actively encourages the kind of non-poaching agreement that Apple/Google/Intuit/Intel were involved in that's illegal, though of course, none of the companies involved were ever punished in any significant fashion. But you'll love Horowitz's excuse for encouraging this kind of illegal behavior: CEOs are already very lonely people and can only commiserate with fellow CEOs, so pissing off other CEOs is a bad idea since you need all the friends you can get when you're a CEO. I have no idea if Horowitz is as actively un-self-aware in real life as he seems to be when he wrote this section of the book, but there you go. Apparently, having been a successful CEO is a license to encourage others to do illegal stuff.
Finally, at the end of the book Horowitz reveals that the entire book was a marketing brochure for his VC firm, Andressen Horowitz. That's probably OK --- you didn't expect anything else, did you?
Regardless, the book's well worth a read. Like I mentioned, if it helps you avoid one of the errors I noted above, it's worth the time. Recommended.
Labels:
books,
management,
recommended,
reviews
Friday, October 21, 2016
Review: Writing Creative Nonfiction
I checked out Writing Creative Nonfiction from the library, because why not? Non-fiction is what I write most of the time (at least, intentionally), and I have a fondness for non-fiction. It's also a Great Courses program, which has established a great deal of credibility with me over the past year or so.
One of the most interesting things I learned about the genre is that Creative Nonfiction used to be called Literary Journalism, of the sort Ernest Hemingway practiced. It was only called Creative Nonfiction after people started using that technique in other contexts.
In any case, the course is mostly about writing of the generic sort, so the lecturer spends a lot of time covering basic writing. I found that very disappointing, because so much of what makes non-fiction hard, for instance, is that you can't just make up dialogue --- and if you've lived through it, you'll have to tape every conversation so you can reproduce it later. That's not even something she talks about!
Furthermore, some of the techniques seem really fishy to me. For instance, she's very fond of indirect discourse. It turns out that indirect discourse (especially the untagged kind) is ambiguous in English. It's unattributed, so it lets the author inject speech into a character's mouth without having to substantiate it with any kind of reference, since that indirect discourse is also the author speaking. That seems really really iffy to me, but it's apparently such a mainstay of fiction and non-fiction writing that it's widely accepted, and she encourages the use of it as a tool so you can make up dialogue or conversations without having to have recorded the actual words that were spoken in some form or another.
Ultimately, creative non fiction is the use of the novelist's toolbox to non-fiction or personal writing. It's interesting that (according to the lecturer anyhow) it's by far the best-selling genre today, leading to scandals like A Million Little Pieces, where a novel was essentially passed as non-fiction in order to generate awesome sales.
One interesting lecture in the series is "How not to have your friends and family hate you." It's a great lecture, and if you're planning to write a family history or memoir, is definitely worth the price of admission.
My biggest criticism of the lecture series is the lecturer herself. She loves to pepper her sentences with verbal diarrhea. For instance, "You wouldn't want your readers to be bored, would you?" If you added up all those extra two-words she tacks on at the end of every other sentence, I'm sure you could save at least half an hour of run-time on the entire series of lectures.
Is the course useful? I'll let you decide. I wrote many of the daily trip segments of this year's Tour of the Alps report "creative fiction" style, rather than my preferred Jobst-style. If you think that it was an improvement, then the course is recommended.
One of the most interesting things I learned about the genre is that Creative Nonfiction used to be called Literary Journalism, of the sort Ernest Hemingway practiced. It was only called Creative Nonfiction after people started using that technique in other contexts.
In any case, the course is mostly about writing of the generic sort, so the lecturer spends a lot of time covering basic writing. I found that very disappointing, because so much of what makes non-fiction hard, for instance, is that you can't just make up dialogue --- and if you've lived through it, you'll have to tape every conversation so you can reproduce it later. That's not even something she talks about!
Furthermore, some of the techniques seem really fishy to me. For instance, she's very fond of indirect discourse. It turns out that indirect discourse (especially the untagged kind) is ambiguous in English. It's unattributed, so it lets the author inject speech into a character's mouth without having to substantiate it with any kind of reference, since that indirect discourse is also the author speaking. That seems really really iffy to me, but it's apparently such a mainstay of fiction and non-fiction writing that it's widely accepted, and she encourages the use of it as a tool so you can make up dialogue or conversations without having to have recorded the actual words that were spoken in some form or another.
Ultimately, creative non fiction is the use of the novelist's toolbox to non-fiction or personal writing. It's interesting that (according to the lecturer anyhow) it's by far the best-selling genre today, leading to scandals like A Million Little Pieces, where a novel was essentially passed as non-fiction in order to generate awesome sales.
One interesting lecture in the series is "How not to have your friends and family hate you." It's a great lecture, and if you're planning to write a family history or memoir, is definitely worth the price of admission.
My biggest criticism of the lecture series is the lecturer herself. She loves to pepper her sentences with verbal diarrhea. For instance, "You wouldn't want your readers to be bored, would you?" If you added up all those extra two-words she tacks on at the end of every other sentence, I'm sure you could save at least half an hour of run-time on the entire series of lectures.
Is the course useful? I'll let you decide. I wrote many of the daily trip segments of this year's Tour of the Alps report "creative fiction" style, rather than my preferred Jobst-style. If you think that it was an improvement, then the course is recommended.
Labels:
books,
recommended,
reviews
Thursday, October 20, 2016
Review: The World According to Garp
I tried to buy a copy of The World According to Garp on my Kindle, but apparently there's no Kindle version. As a result, I borrowed the dead-tree copy from the library. Now that I've read the book, maybe it's a deliberate decision by John Irving, as the novel is set in a world pre-1970s. That meant that there were no car-seats, no internet, and certainly no Kindles.
My first exposure to the novel is from "watching" the movie at the student lounge in my dorm at Cal. I put "watch" in quote because I think I was either doing problem sets or grading homework, so I wasn't paying much attention, and only raised my head when someone made a comment about the movie. Nevertheless, it made somewhat of an impression, so 16 years later I decided to go to the source and see what the hype was all about.
The movie was supposed to be funny, as was the book. It's not funny in the Douglas Adams/British-style, but in the Garrison Keillor style: kinda dead-pan, and deliberate in its humor. Certainly, some of the situations are hilarious, and the setups are long in coming and thus funnier when they do come. The themes, events, and reflection of both the times and feminism work well, but only in the context of the time of the novel. (The pivotal event in the novel, for instance, could never have happened once car-seats were mandatory) That's a reflection of how much safer the world has gotten, but also a reminder of how violent the USA was in the 1960s, when people of political significance were getting murdered and assassinated everywhere.
Did I enjoy the book? Somewhat. In many places, it greatly reflects the life of a writer. In other places, it feels as fantastical as any book marketed as "magical realism." Would I recommend you read it? Maybe. You have to like the Garrison Keillor type voice (I don't, not unless your name is Larry Hosken). You have a strong sense of the absurd (which I do, which is why I did find some of the situations funny). You have to enjoy "literary fiction" as a genre (I don't). So for me, the book was mixed, but maybe you'll like it if your response to the previous 3 statements was positive. Otherwise, you might be better off watching the movie instead.
My first exposure to the novel is from "watching" the movie at the student lounge in my dorm at Cal. I put "watch" in quote because I think I was either doing problem sets or grading homework, so I wasn't paying much attention, and only raised my head when someone made a comment about the movie. Nevertheless, it made somewhat of an impression, so 16 years later I decided to go to the source and see what the hype was all about.
The movie was supposed to be funny, as was the book. It's not funny in the Douglas Adams/British-style, but in the Garrison Keillor style: kinda dead-pan, and deliberate in its humor. Certainly, some of the situations are hilarious, and the setups are long in coming and thus funnier when they do come. The themes, events, and reflection of both the times and feminism work well, but only in the context of the time of the novel. (The pivotal event in the novel, for instance, could never have happened once car-seats were mandatory) That's a reflection of how much safer the world has gotten, but also a reminder of how violent the USA was in the 1960s, when people of political significance were getting murdered and assassinated everywhere.
Did I enjoy the book? Somewhat. In many places, it greatly reflects the life of a writer. In other places, it feels as fantastical as any book marketed as "magical realism." Would I recommend you read it? Maybe. You have to like the Garrison Keillor type voice (I don't, not unless your name is Larry Hosken). You have a strong sense of the absurd (which I do, which is why I did find some of the situations funny). You have to enjoy "literary fiction" as a genre (I don't). So for me, the book was mixed, but maybe you'll like it if your response to the previous 3 statements was positive. Otherwise, you might be better off watching the movie instead.
Labels:
books,
recommended,
reviews
Wednesday, October 19, 2016
Building a bike for a Tour of the Alps
In my book, Independent Cycle Touring, I refrained from giving specific equipment advice as much as possible. That's because I don't know what tour you might be doing, and to be honest, for most people, there's no reason to buy a new bike just so you can do a tour. Just use whatever bike you have.
Now, if the question is: "I'm going to join you on one of the Tour of the Alps. I know there's going to be intense suffering. How do I reduce it as much as possible without breaking the bank, given that all I have right now is a mountain bike and a low quality hybrid?" Then you're in the situation Arturo Crespo was in earlier this year, and I do have specific recommendations!
For Arturo's bike, I recommended a Rivendell Roadeo geometry in Titanium (he ended up with a Lynskey) built around long reach caliper brakes and a 2x10-speed SRAM drive train. The key contact points were based around carbon fiber brake levers, SPD pedals, and a Brooks C17 saddle. In practice, he never really got used to the C17, and you can substitute SPD pedals for any kind of pedal that gives you a walkable cleat, because I don't stop riding up a mountain just because there's some walking required to get through the pass on the other side.
OK, so what if you don't have the budget for a titanium frame? Dan Wallach put together a spreadsheet with most of my recommendations. Paired with the Soma Smoothie ES and a steel fork, the entire thing would probably cost about $1700 or so. (Note that a Rivendell Roadeo frame by itself is $2200, so don't assume that Arturo went Titanium because he wanted a lighter bike --- he just wanted a faster delivery time than Rivendell was willing to promise. Ironically, after he got his frame from Lynskey, Rivendell sent around an e-mail saying that they were now willing to sell the demo bike that he test rode and wanted to buy! So there's nothing wrong with the steel Roadeo --- it won't be as robust as the Ti frame that Arturo got, but it'll be tough enough)
Key features:
Now, if the question is: "I'm going to join you on one of the Tour of the Alps. I know there's going to be intense suffering. How do I reduce it as much as possible without breaking the bank, given that all I have right now is a mountain bike and a low quality hybrid?" Then you're in the situation Arturo Crespo was in earlier this year, and I do have specific recommendations!
For Arturo's bike, I recommended a Rivendell Roadeo geometry in Titanium (he ended up with a Lynskey) built around long reach caliper brakes and a 2x10-speed SRAM drive train. The key contact points were based around carbon fiber brake levers, SPD pedals, and a Brooks C17 saddle. In practice, he never really got used to the C17, and you can substitute SPD pedals for any kind of pedal that gives you a walkable cleat, because I don't stop riding up a mountain just because there's some walking required to get through the pass on the other side.
OK, so what if you don't have the budget for a titanium frame? Dan Wallach put together a spreadsheet with most of my recommendations. Paired with the Soma Smoothie ES and a steel fork, the entire thing would probably cost about $1700 or so. (Note that a Rivendell Roadeo frame by itself is $2200, so don't assume that Arturo went Titanium because he wanted a lighter bike --- he just wanted a faster delivery time than Rivendell was willing to promise. Ironically, after he got his frame from Lynskey, Rivendell sent around an e-mail saying that they were now willing to sell the demo bike that he test rode and wanted to buy! So there's nothing wrong with the steel Roadeo --- it won't be as robust as the Ti frame that Arturo got, but it'll be tough enough)
Key features:
- Long reach caliper brakes. Disc brakes are not reliable enough (rotors warp). Cantilevers and V-brakes are too finicky. People who think caliper brakes don't stop when wet just aren't using the correct brake pads. My caliper brakes (Tektros) are now 8 years old and I was over-taking people with disc brakes coming down Stelvio in the rain. If you're a poor bike handler, disc brakes won't make you any better. By the way, Arturo says that it took a huge amount of faith for him to go against the hype and marketing behind disc brakes, but after touring with his bike he agreed that it was the best approach.
- 36-spoke wheels, front and rear with CR-18 rims. These aren't the lightest on the planet, but they're not that heavy. The Shimano hubs have to be overhauled even when new because Shimano lightens their hubs by shipping them with next to no grease inside. The weirdest thing about the wheelset I picked is that the cost to overhaul them at a bike shop ($60) is 2/3rds the price of the wheels! But if you're paying for assembly, the shop will do an overhaul as a matter of course.
- Integrated brake levers/shift levers. They're not as reliable as my preferred bar-ends, but if you change out the cables on an annual basis they seem to be reliable enough. My friends who ride with them do survive my tours nowadays, so it's probably just that I've had bad luck with them in the past. On the other hand, I only change out my cables when they fray, so clearly there's a maintenance advantage to them. Note that I went with SRAM instead of Shimano: Shimano in their infinite wisdom have made their mountain bike and road bike drivetrain parts incompatible, and if you want low gears you want the mountain bike deraileurs, cranks, and cassettes, but road handlebars and brake levers/shifters are still appropriate for long days in the saddle. Since Campagnolo doesn't make mountain bike parts, that leaves SRAM. Fortunately, SRAM makes all of its parts compatible (road + mountain), so mixing and matching SRAM works great. Note that compatibility is a non-issue if you use bar-end shifters in friction mode. It's only the indexing systems that get screwed up by Shimano's inane design.
- 10-speed. 10-speed parts are starting to be hard to find. Get them while they last, since 11-speed wheels are weaker because the wheels have to be dished further!
- Carbon brake levers. Arturo was surprised I bought these, but raved about them on the first cold mountain descent. Carbon is an insulator, and on a cold day, these levers stay warm to the touch, unlike metal brake levers which conduct heat away from your hands. Well worth the money and effort to hunt them down.
- Ultra-low gears (in this case, 26x36 low)! To quote Phil Sung: "Low gears are the highest bang-for-the-buck suffering reduction purchases available."
- No high gears. On a tour of the Alps, you're only going up or down. Don't expect to do any flat riding. So a high gear of 39x11 granting only 95 gear inches is plenty. This is not a bike with which to sprint a gentle descent in the peloton doing 45mph is feasible. The regular bike shops will happily sell you those types of bikes. Don't ask me to help you with a bike if you want to sprint or do 4 hour centuries in a pace-line carrying no load.
- No racks. Saddlebag only. Racks just add weight, and if it doesn't fit in the saddlebag, you have no business bringing it!
It's significant work to buy parts and build the bike yourself. But you end up with a much more "fit-for-purpose" bike. I'm actually jealous of Arturo's bike, since because of the new technology, he has a much better shifting and lighter drive train that's also lower maintenance! He was particularly pleased despite the amount of money he had to shell out --- "I expected to get an incrementally better bike, but I got a much better bike!" In particular, the Rivendell Roadeo geometry is significantly better than other touring bikes or even "club touring" bikes out there. If you have never ridden a Grant Petersen design you owe it to yourself to try the Roadeo (I'm not so much a fan of his 650B wheeled designs, so I'm only going to single out the Roadeo for praise). Nobody else even comes close.
Tuesday, October 18, 2016
Navigation and Trip Statistics
The Garmin Vivoactive survived the Tour of the Alps with flying colors, as expected (see original Long Term review). Pengtoh also brought along the newest version, the Garmin Vivoactive HR, which includes a HRM mounted on the underside. Since we both uploaded our tracks to Strava, we got a chance to compare the accuracy of the two devices side by side.
The most important difference is that the Garmin Vivoactive HR has a real barometer. That means that it gets real altitude/elevation data. For instance, on the Grimsel and Furka day, my Vivoactive got an optimistic 8031', while Pengtoh's Vivoactive HR got a much more realistic 6850'. The most accurate device was probably Arturo's Garmin 810, which gave us 6969'. The Edge 810 is probably more accurate because it has a temperature sensor, which is essential to giving an accurate air density measurement as the day warms up. Arturo's 810 died in the middle of the tour from water damage, however.
Garmin provides a temperature sensor for its watches. The $24 question is: does the Vivoactive HR use that to adjust the air density measurements in order to get more accurate elevation data? The main reason not to have a temperature sensor on the watch proper is that your body heat would heat up the sensor, granting in accurate temperature readings, which would invalidate any results from such computation. Garmin doesn't say and doesn't publish technical explanations for altitude/elevation measurements.
Suffice to say that with the addition of a barometric measurement, the Vivoactive HR is now high on my list of devices to upgrade to before the next tour of Alps. Pengtoh says that the HR function works well even for cycling for him, which is another big benefit.
The limited battery life of the Vivoactive was such that I had to carry an external battery to charge it mid-day (usually at lunch), but the Vivoactive HR that Pengtoh had is good for 16 hour stretches with the GPS turned on, which eliminates even that weakness.
By the way, one of the most hilarious aspects about the Tour of the Alps is that the Vivoactive is clearly designed for sedentary people who don't do massive bike rides. It was funny during the tour to look at the watch and see it register 4000-5000 calories a day (a massive under-estimate, by the way, since the Vivoactive doesn't know that my bike was carrying a touring load), while the Garmin Connect app's "Insight" feature kept telling me that I was being less active than usual, while the Garmin "Auto Goal" feature kept telling me that I'd missed my "step goal" for the day. The poor Vivoactive kept scaling down its "step goals" and missing them during the entire tour.
Given all that, the need for a dedicated cycle computer is no longer apparent except for the navigation features. In rural country towns and alpine country with few roads, the Garmin Edge 800 performs admirably. However, Google Maps has also improved to the point where in urban areas or places with dense road networks it's actually more useful. The smart phone touch screen interface is also better than the Garmin maps screen. It's strange that Google Map's cycling directions are sporadic --- we had availability in Switzerland, no availability in Italy, and full coverage in Austria and Germany. But in any case, when it was available, the provision of elevation changes en-route means it's a much better source of information than Garmin's offering.
As such, for future trips, a Vivoactive HR (or whatever replacement model available at that time) coupled with a waterproof phone (with an international data plan!) capable of Google maps and a bike mount for the said phone potentially the better touring solution. You'll always need paper maps for large scale coverage and designation of scenic routes which Google will probably never provide, but you've always needed them anyway. This is a huge change from previous years, where the lack of international data plans and incompleteness in offerings from Google Maps made such use of phone navigation lacking.
The most important difference is that the Garmin Vivoactive HR has a real barometer. That means that it gets real altitude/elevation data. For instance, on the Grimsel and Furka day, my Vivoactive got an optimistic 8031', while Pengtoh's Vivoactive HR got a much more realistic 6850'. The most accurate device was probably Arturo's Garmin 810, which gave us 6969'. The Edge 810 is probably more accurate because it has a temperature sensor, which is essential to giving an accurate air density measurement as the day warms up. Arturo's 810 died in the middle of the tour from water damage, however.
Garmin provides a temperature sensor for its watches. The $24 question is: does the Vivoactive HR use that to adjust the air density measurements in order to get more accurate elevation data? The main reason not to have a temperature sensor on the watch proper is that your body heat would heat up the sensor, granting in accurate temperature readings, which would invalidate any results from such computation. Garmin doesn't say and doesn't publish technical explanations for altitude/elevation measurements.
Suffice to say that with the addition of a barometric measurement, the Vivoactive HR is now high on my list of devices to upgrade to before the next tour of Alps. Pengtoh says that the HR function works well even for cycling for him, which is another big benefit.
The limited battery life of the Vivoactive was such that I had to carry an external battery to charge it mid-day (usually at lunch), but the Vivoactive HR that Pengtoh had is good for 16 hour stretches with the GPS turned on, which eliminates even that weakness.
By the way, one of the most hilarious aspects about the Tour of the Alps is that the Vivoactive is clearly designed for sedentary people who don't do massive bike rides. It was funny during the tour to look at the watch and see it register 4000-5000 calories a day (a massive under-estimate, by the way, since the Vivoactive doesn't know that my bike was carrying a touring load), while the Garmin Connect app's "Insight" feature kept telling me that I was being less active than usual, while the Garmin "Auto Goal" feature kept telling me that I'd missed my "step goal" for the day. The poor Vivoactive kept scaling down its "step goals" and missing them during the entire tour.
Given all that, the need for a dedicated cycle computer is no longer apparent except for the navigation features. In rural country towns and alpine country with few roads, the Garmin Edge 800 performs admirably. However, Google Maps has also improved to the point where in urban areas or places with dense road networks it's actually more useful. The smart phone touch screen interface is also better than the Garmin maps screen. It's strange that Google Map's cycling directions are sporadic --- we had availability in Switzerland, no availability in Italy, and full coverage in Austria and Germany. But in any case, when it was available, the provision of elevation changes en-route means it's a much better source of information than Garmin's offering.
As such, for future trips, a Vivoactive HR (or whatever replacement model available at that time) coupled with a waterproof phone (with an international data plan!) capable of Google maps and a bike mount for the said phone potentially the better touring solution. You'll always need paper maps for large scale coverage and designation of scenic routes which Google will probably never provide, but you've always needed them anyway. This is a huge change from previous years, where the lack of international data plans and incompleteness in offerings from Google Maps made such use of phone navigation lacking.
Labels:
computers,
cycling,
recommended,
reviews
Subscribe to:
Posts (Atom)