Author: Scott Gruby

Posted on

Review: Fujitsu ScanSnap ix500

As many people who read my blog know, I’ve been working with consumer scanners for over 6 years and have had more scanners than I care to count. Six years ago I purchased a Fujitsu ScanSnap fi-5110eoxm scanner. It was quite expensive for a consumer scanner, but it was one of the best investments I’ve made in computer hardware. The scanner served me well, and I’ve been recommending that scanner and its successors for years. Everyone that I’ve recommended the scanner to has been pleased with it.

Yesterday, the FedEx guy dropped off a package for me, and I quickly opened it. Inside was a Fujitsu ScanSnap iX500. I was given the heads up that a “black and shiny” object would be showing up at my door, so it wasn’t a complete surprise.

The first thing I did with the scanner is take a stack of loan documents (105 pages), split it into 3 and scanned it in. The stack had some letter sized pages and some legal sized pages. The scanner cranked through the pile pretty quickly without a single misfeed. In fact, I scanned the stack 3 times, the first time, it scanned to my iPhone (it has WiFi and an iPhone app), the second I didn’t turn on OCR, and the 3rd time was a charm. It was significantly faster than my old ScanSnap and didn’t misfeed (my old ScanSnap misfed all the time).

The feeder on the scanner works better than the old version, as well. The software is typical hardware manufacturer software in that it works, but is, in general, pretty poor. I have, however, gotten used to the software over the years and try to interact with it as little as possible. In fact, I use Mariner Software’s Paperless which integrates directly with the ScanSnap so that I can just click the Scan button in Paperless and it kicks off the scan.

The cost of the scanner may deter some people, but for anyone that wants to go paperless, a good scanner is an absolute necessity. Once you use a ScanSnap, you will think that multi function devices are toys.

Pros

  • Very fast scanning.
  • Excellent ability to prevent misfeeds.
  • Scanning quality is good and automatic setting works well.
  • Abbyy Integrated OCR is fast and produces good results.

Cons

  • Expensive.
  • Software is usable, but not pretty.

Summary

This scanner reaffirms my recommendation of ScanSnap scanners. It improves on my 6 year old scanner, but I don’t think it would be worth spending the money if you already have a ScanSnap scanner. The scanning to WiFi seems more like a bullet item than a useful feature, but time will tell.

While people try to eliminate paper, it is amazing how much still comes into our house. A scanner is absolutely necessary to reach the goal of going completely paperless. I’ve been scanning in documents and going paperless for the last 6 and a half years. If you don’t already have a ScanSnap scanner, this is an excellent choice.

Posted on

Why all the fuss over working from home?

With the recent announcement/leak that Yahoo! is requiring all its employees to work from an office, I’ve been thinking a lot about my own experience working from home. I’ve been working from home for over 13 years; my first experience working from home was forced upon me with the closure of my office, but this second stint was my own choice. For my work style and ethic, I could never work in an office again. I do put in a full workday every day as well as work extra hours when needed. However, I’m also not chained to a desk and can get things done during the day, if needed. While I’m not alone in never wanting to work in an office again, working from home isn’t for everyone. In fact, I’d argue that most people should never work from home.

Working from home takes a certain dedication, motivation, and work ethic. In most cases, I believe that this should be reserved for the cream of the crop employees and be decided on a case by case basis. I’ve seen working from home abused by many employees and what Yahoo! is doing may make sense for it. However, they have the possibility of losing their best employees over the new policy.

Several years ago when my business was down significantly, I interviewed for a position with a local company. Like Yahoo!, their policy was that all employees had to be in the office. As someone who had worked from home for many years prior to this, I was quite torn about the position. In the end, I determined that my quality of life would suffer if I had to work in an office and commute up to an hour and a half round trip each day. Not everyone has this luxury, but a policy that is supposed to foster collaboration could backfire if it reduces overall employee satisfaction.

Even though I work in a large company, my entire team (except for one project manager) works from home (we’re all in different cities). We’ve actually never worked in an office for this company, but were hired as remote employees because great employees are hard to find and dictating where someone must live and come into an office drastically reduces the potential talent pool. If my company were to enact a blanket policy where no one could work from home with no exceptions on a case by case basis, I’m almost sure we’d all leave. My team is extremely talented and forcing us into the mold of an average employee is fraught with disaster.

Hopefully Yahoo! doesn’t lose too many good people (if you’re a mobile developer at Yahoo! and are looking to leave, please drop me a note) with this move. In addition, maybe the policy can be revisited on a case by case basis so that the top people have a lot more flexibility. In our highly mobile workforce, lumping everyone together is a recipe for losing people.

Posted on

Developers going indie

Over the last few years, I’ve read about a number of developers that have “gone indie” in that they left their jobs and are now independent developers. Maybe make it sound glamorous that they no longer have a boss. While this technically may be true, they still have to answer to someone, be it their clients or their customers. There is nothing inherently wrong with being independent, but thinking that doing this will make all of someone’s work problems go away is misleading.

People that are self employed swap one set of problems (e.g. working for a large company) with another. Being self employed means doing accounting, marketing, sales, support, etc. (or hiring someone for these positions and having to be a people manager). In addition, income is not guaranteed which could lead to stress and many people have a hard time separating work from home and thus put in more hours at their “job”. I’m not saying that working for someone else is better or that being self employed is better (I’ve done both), it is just different.

I personally had a good run being self employed (granted my independent software business was only about 20% of my income with the rest coming from contracting), but at this stage in my life, working for someone else brings stability and has actually reduced my stress over my job (I have other stresses, but work isn’t one of them). When I was self employed, I used to put in 70+ hours per week between my software and contracting. This was not sustainable for me.

I wish developers going indie the best of luck, but just because I work for someone else (a large company in my case), I’m not a sellout and have no regrets.

Posted on

Review: Mophie Juice Pack Air for iPhone 5

One of the problems with any battery operated technology is that it is completely useless when the battery runs down. This, of course, has lead to a huge industry of aftermarket battery packs and charging mechanism for every gadget we use. While I’m not a huge user of my iPhone, I have found that when I travel, I am a little more cautious about using my phone for fear that I’ll run out of juice on my phone and not be able to make an important call or will miss a message from home at the end of the day.

Last year, before WWDC, I bought a Mophie Juice Pack Plus for my iPhone 4S and used it on all my trips. I don’t travel all that often (on average about once a month), but I felt a lot better knowing that my phone would last all day. There are lots of tips for extending the battery life of a phone, but they all require futzing with settings and reducing the utility of the phone (one tip is to turn it off as the battery is getting low so that you can turn it on later to make an important call; it’s hard to receive a call or check email when it is turned off!). The Mophie case was an excellent solution and served me well until I got my iPhone 5.

I’ve travelled a few times with my iPhone 5 and haven’t had much of a problem with battery life, but have topped it off before dinner on trips as it usually got quite low. When Mophie announced their latest cases for the iPhone 5, I knew I had to get one as WWDC is coming up again and I have a few more trips as well. In addition, now that I have a Pebble, I have to leave Bluetooth on all day which drains my battery a bit without doing anything. It was a no-brainer to order the case; it just was a matter of timing. I finally bit the bullet last week and with an estimated shipping time of 7-10 days, I figured I wouldn’t receive it in time to give it a whirl on my next trip. However, Mophie’s super fast shipping got it to me in a 3 days.

I hadn’t read the details on the Mophie site close enough to catch a small gotcha with the case; it wasn’t until I heard the case as a “pick” on MacBreak Weekly that I learned of this gotcha. The pass through connector used for charging only charges and doesn’t allow for syncing. As I don’t use the case all the time and it is easy to remove, it isn’t a huge issue.

The other quirk is that the headphone connector is so far recessed and small that Mophie provides an extender cable. The Apple supplied headphones fit fine, but are a bit difficult to plug in and remove.

I gave the case a test drive on my most recent trip, but somehow, my phone didn’t drop below 15% even with talking on the phone for 1.5 hours, getting a bunch of email, receiving a few text messages and having Bluetooth on. So, while I was prepared to flip the switch on the case to recharge the battery, I didn’t have to do it. Does this change my review? Well, not really, the only part I didn’t test was “would it charge” and I have to assume it will otherwise I have a dud.

Pros

  • It charges the battery.
  • It provides some protection on the side.

Cons

  • Adds weight and bulk to the phone.
  • Pass through connector only charges and doesn’t do data.
  • Pass through connector isn’t a lightning connector. (I don’t like micro USB as it is hard to insert correctly on the first try.)

Summary

If you find that your iPhone 5 drains its battery during the day, then having a battery case is extremely useful. Is it worth the $99 cost? That is really going to depend on your usage. I’m glad I bought it so that I don’t have to worry about having a charge. While I have another external battery that lets me plug in a USB cable, it just isn’t convenient. It is a lot cheaper, but when I’ve tried to use it, having it in my pocket with my phone and cable was too cumbersome to be a real solution. I won’t use it all the time, but now I have it just in case. I’m sure that on longer trips it will come in handy. This first test trip ended up being a short day with me leaving my house around 6:30 am and arriving home around 7:00 pm.

Posted on

Flaws in RESTful response codes

Anyone that uses or develops APIs is familiar with REST. It is widely used and by some developers considered superior to other ways of doing APIs. Since REST was developed alongside the HTTP 1.1 spec, HTTP status codes are generally used for responses to REST calls.

To me, it seems that using the standard HTTP response codes (a nice list is given here) is overloading a standard server response with the response of a query. While the spec says that for client errors (400 series errors), the response should contain the reason why in the response. I’ve looked at a lot of APIs and the best ones at handling errors return the error response inside of a successful 200 HTTP response. For instance, if you are creating an API for dealing with support tickets and you ask for a ticket ID that doesn’t exist or you don’t have permission to access, returning a 400 series error generally tells the client that something bad has happened when, in fact, the error is kind of minor. Embedding the error in the response seems like a better way to go.

The problem, however, with embedding the error in the response is that the API developer has to come up with his own error codes and convey that to those that use the APIs. Many developers that implement APIs treat anything but a 200 series response as a complete failure and give up. So, the API developer has to make sure that the client implementors properly handle the responses. In general, I find it easier to have one set of parsing code and deal with the errors inside of a successful response.

My argument, of course, is not very compelling as it is simply to swap one way of handling responses and errors with another. Last night, however, I came up with a potential argument that leads credence to what I’m saying. If there is a proxy server or a load balancer in front of the server, it could potentially return an error code which the client may not expect. Let’s take the case where our support ticket server is behind a proxy server and the client requests a particular ticket. If the proxy server or load balancer is misconfigured and we make a request, the proxy server could return a 400 series error, even a 404 error. The client could interpret this as “the ticket doesn’t exist”. This may not be the case; the ticket could exist, but the proxy returned an error. A better way of handling this would be to use 200 series status codes when the request succeeds and embed the API error code inside of the response. If the proxy server returned a 400 series error, the client could always treat it as an error and wouldn’t have to figure out if the support ticket really existed or not.

In addition, the HTTP status codes are not granular enough for many APIs. This would require the API developer to have a secondary set of error codes that would be returned with the 400 series error codes anyway. If that is the case, why not just create one set of error codes and always return 200 series success codes unless something major has happened?

I know that some of this may be confusing (it is crystal clear in my head), but it is worth some thought to consider the best way to handle response codes in APIs. Many people have opinions on this and may think that I have no idea what I’m talking about and HTTP response codes are perfectly fine for RESTful APIs.

Posted on

Wrong definition of a pioneer?

The other day I was looking at a website of a contracting company that specializes in mobile development. The site said that they were pioneers in the field. The site then had as its next line that the company was started in 2009. I normally think of pioneers as people who initially settle an area or who are first in a particular field. Unless my history of mobile is a little off, 2009 is a bit late to the party. If we just consider the “modern” era of mobile development that began with the iPhone and Android, they are still late as the iPhone was released in 2007 and the SDK in 2008.

However, saying that mobile development began in 2007/2008 is doing a disservice to all the predecessors to iOS. PalmOS came out in 1996, the Newton came out in 1993, Windows CE came out in 1996 and the Psion was about the same time.

I have no idea what meaning of pioneer this company had in mind, but they are certainly not pioneers in mobile applications. I’ve been writing mobile applications since 1994 when I first got a Newton (the Apple Personal Interactive Electronics group which made the Newton licensed my NotifyMail program and sent me a Newton MessagePad 110 in exchange for the license) and I don’t consider myself a pioneer. I know a number of people that wrote mobile applications prior to this.

If the company considers themselves pioneers, what do they call their developers that have 1-2 years of experience? Experts?

Posted on

The wrong way to use asserts

One of the ways programmers use to help ensure that inputs to methods are correct is to use asserts. Basically these will test conditions and stop execution if a test fails. By default, Xcode suppresses these asserts in release builds so that the code will simply continue.

This past weekend, I was helping out on a project and found that the app stopped because of an assert indicating that a condition was not satisfied. As I looked into it closer, the programmer had put in asserts to test the results of what came back from the server. The author then didn’t do runtime checks to validate the data, he simply assumed that if the assert passed, that the data was valid and continued. The problem is that, in this case, the server returned data that the code wasn’t expecting, so in a release build, the code would have continued and then crashed because the data wasn’t in the correct format.

While I’m not a huge fan of asserts, they do have their place, just not here. The code should have done runtime checks and gracefully handle bad server data.

I suspect that the author hadn’t done enough client-server communication to know that servers return bad data more often than you’d expect. I’ve worked on so many projects where a simple server change causes clients to have hiccups, that I’ve gotten pretty good at defensively programming against this.

If you choose to use asserts, make sure that you also use runtime checks and gracefully handle conditions that you test for in the asserts as the asserts go away in release builds.

Posted on

First Week Review: Pebble Smart Watch

Two summers ago, the battery on my watch stopped, so I replaced it, but then found that my watch stopped again within a few days. I gave up on my watch and decided that I didn’t need a watch as I have my phone with me all the time. Fast forward to last April when the Pebble smart watch appeared on Kickstarter. I was getting tired of having to pull my phone out of my pocket, so I became interested in it. The watch had 2 features that interested me; one it tells time and second, it would tell me when the phone rings. I’ve found that when my phone is in my pocket, I miss calls; people don’t call me all that often, but I like to answer the calls. These 2 features sold me on the watch.

When iOS 6 came out, it added a Bluetooth profile called MAP which allows messages from the phone to the watch. This sold me even more on the watch.

So with these 3 features promised, I waited and waited (just like everyone else) for my watch to be delivered. Before receiving it, I read mostly positive reviews, but some negative comments. For me, I just wanted these 3 features and almost didn’t care about anything else. From reading the specs and what people had to say, they indicated that the watch was big. I wasn’t too concerned about this as I actually wore a Fossil Palm OS watch which was huge!

Now that I’ve had the watch a few days, I have mixed feelings about it. It does everything that I wanted it to do in terms of telling the time, letting me know when a text message arrives and when I receive a phone call. I’ve gotten some other notifications and now I want more; it appears that iOS only consistently notifies for messages, but inconsistently with other notifications. Pebble has documented a dance to get other notifications working, but that doesn’t seem like a very good answer. Given that MAP support in iOS 6 is new, maybe Apple will add options to specify exactly which notifications will get passed through to MAP in the Bluetooth settings for the device as seen below.

Screenshot 2013 02 14 14 27 18

The watch isn’t the prettiest or cheapest watch on the market, but for the moment, it is fulfilling a need for me.

Pros

  • It tells time.
  • It lets me know when I get SMS or iMessages.
  • It lets me know when the phone rings.

Cons

  • It’s big.
  • Notifications other than SMS/iMessage/Phone are inconsistent (apparently an iOS 6 bug/issue).
  • Drains the iPhone’s battery a bit by having Bluetooth connected all the time.

Summary

If style is a main concern of yours, don’t get this watch. If you want a completely bulletproof product, don’t get this watch. The Pebble team is releasing updates fairly often to work out kinks and I think it will still be awhile before everything is worked out and issues settle down (like getting Apple to figure out what to do with notifications and MAP; there is a jailbroken hack that fixes this, but I’m not jailbreaking my device). The jury is still out of the watch’s battery life, but it doesn’t negatively affect my iPhone such that I’ll probably be buying a Mophie juice pack Helium.

I’ll definitely be wearing the watch while I wait for something better to come along; the rumors of an iWatch are interesting, but don’t sound like a product Apple will bring to market anytime soon.

Posted on

Thanks for the fix, Apple!

I few weeks ago I wrote about issues I was having with Bluetooth 4.0 interfering with standard Bluetooth, specifically my heart rate monitor was causing clicks on my Bluetooth headset while running. I filed an Apple Radar issue that was promptly closed as being a duplicate and the other one was closed as well, but Apple wouldn’t provide me any information about when it would be fixed. Typically when I report bugs to Apple it either takes years from them to get fixed or they never get fixed (I still have a number of open bugs).

When Apple released iOS 6.1, I checked the update information and nothing about this issue was mentioned. However, Apple never documents all the fixes which is a bit annoying for a tech person like me, but understandable as it could show what security holes were patched or could get customers saying “that was my bug, but you didn’t fix it”. Knowing that there were likely lots of little issues fixed, I went ahead and tried my previous experiment of running with my heart rate monitor and Bluetooth headset. So far on three runs, I haven’t noticed a problem! Was the issue fixed? I think it is still too early to tell, but so far it looks pretty good. Now if Apple had only told me in my bug report the OS version it was fixed in (since I’m a member of the developer program, they will tell me to test it in an unreleased OS version sometimes), I wouldn’t be wondering.

Posted on

Finding the perfect suitcase

About a year ago, I decided that the rolling suitcase I was using to travel was getting too cumbersome and I could make it through the airport easier with a small duffle bag. Last year I travelled 12 times (11 for work) and the bag worked well. However, the bag started hurting my shoulder and I started looking for a better solution.

Like most things I buy, I researched suitcases until I was blue in the face. I wanted one that would easily fit in an overhead bin and had 2 wheels. This turned out to be a huge challenge. First off, many manufacturers have switched to spinner type bags with 4 wheels. This type of bag makes a lot of sense for people going from house to car to airport to hotel and travel over smooth surfaces. This isn’t always how I travel. When I’ve gone to San Francisco or Portland, I’ve taken public transportation and then walked a number of blocks over uneven sidewalks. The spinner bags would be harder to use, so I immediately ruled them out.

Finding a small bag also proved to be troublesome as different companies measure the bag dimensions differently. Some include the wheels and handles; others do not. I checked the websites of the airlines I’ve used in the last year (Alaska, Delta, and Southwest) to make sure the dimensions met the guidelines. I also found that some bags had a compartment for a laptop. This seems a bit ridiculous for business travelers (makes sense for airline crews) as most people that travel for business will drop off the luggage at a hotel or leave it in a car and take the laptop in a backpack or other bag into an office.

After much searching, I ended up getting a Travelpro Luggage Crew 9 20-Inch rolling bag as well as one from Costco. After evaluating the two (I could return the one I didn’t like), I decided to keep the TravelPro. While it isn’t perfect, it seems to work OK.

The TravelPro has the dumb laptop compartment which makes it fatter, but I have no use for it. If this was left off, it would be a better bag. However, the other aspects of the bag seem well thought out. It doesn’t tip over and the handle and wheels work well. My Brenthaven MetroLite backpack has a way to easily slide the backpack on the handle of a rolling bag and that seemed to work well; however, it did a bit of extra weight on the arm that I was using to pull the suitcase. The suitcase easily fit in the overhead bin on my Southwest flights and rolled well through the airport.

Will this be the perfect bag for me? I have no idea; I just hope it lasts for awhile.