Second Screen When Working From a Cafe

I feel like I’m pretty close to being as productive in coding at a cafe as I’m at my desk. Before, the combination of sometimes spotty wifi and lack of a large monitor definitely made me feel a bit sub optimal. These days, I bring my laptop, iPad, and mouse and I hardly feel the difference between sitting at a cafe vs my desk.

A big part of this has been Duet Display which allows me to use my iPad Pro 12.9″ as a second monitor. I’ve written about other apps I’ve used to incorporate the iPad as a part of my setup, but the speed that Duet provides really pushes it past the point where I notice that it’s an iPad.

For me, having my mouse (Magic Mouse) is crucial. Finally, these days large data plans on the phone is affordable enough where push comes to shove I can use that when the cafe’s wifi is acting up.

  • iPad Pro (and keyboard/stand, cable)
  • MacBook (and charger, usb-c hub/dongle)
  • mouse
  • headphones
  • iPhone

Total weight: 3169 grams ~= 7 lbs

Total weight of travel setup


Rails logging to two log files

I wanted to have a Rails 4 app output a local log and ship logs to a central logging server and format these files slightly differently. ActiveSupport::Logger.broadcast makes this really easy but I couldn’t find any documentation or examples online, so I thought I would post this.

I already had a log_formatting.rb initializer file so I added the following to it.

 


Fetch Request Template (Part 2)

 

I was looking into how to optimize queries in Core Data and wrote some code to test the various ways. It turned out that creating Fetch Request Templates was faster but I had no idea why and wrote a blog post about the results I got in various ways to do fetches in Core Data. I ended up asking about this in Stackoverflow and at first didn’t get much of an answer at first. The next day, I ended up realizing the biggest of the difference between a regular fetch and running on via a Fetch Request Template was that programmatically creating a fetch request it’s required that we provide a sort (versus a Fetch Request Template which doesn’t require the results to be sorted). I was going to update the code to test this assumption and just got around to it.

After a few days of that question on SO going unanswered, someone put a bounty on it and the question got enough attention to get it answered by more experienced iOS devs. I never realized how useful a bounty was.

So as you can see in the screen capture to the right, most of the difference between a regular fetch and a template fetch is due to the absence of a sort. Once I put a sort on the template fetch it was almost as slow as a regular sort – still a bit faster. I’m not sure what the insert/update costs of a index on the sort are but indexing both the search field and sort field doesn’t help all that much. There is still a bit of a difference between a regular fetch and a template search but nothing like the difference in putting an index on the search or sort field.

Again, here’s the code if you want to test other things: https://github.com/jinyk/CoreDataFetchTests.

 


Standing Desk

I’ve had back issues on and off for a while. Pretty sure it’s due to my horrible posture while sitting at my desk all day. I’ve tried doing mid-section exercises, stretches in the office, neither of which have helped much. Granted, I haven’t been really committed to either efforts. I thought I would give standing desk a try. I figured, once I’ve set it up, I won’t be able to really half-ass it. It’s only been a week so far but it’s been fun and from the strain on my mid-section I can tell it’s building up those muscles.

Second reason I wanted to try it was so I have an excuse to build something. I’ve been wanting to build a custom stand for my iPhone which is nice to be able to use with just my left hand during testing. The standing “desk” I built  is really just a small table on top of my regular sitting desk. It’s mostly out of parts from Ikea. It’s basically this design found at A standing desk for $22 which I modified.

I wanted to make sure it had enough room for both my monitor and laptop so I used a wider LACK table. Also, their specifications for attaching the shelf brackets to the legs of a Lack table didn’t work for me. I used 2.5″ screws that extended almost all the way into the leg but I found it to not be enough support. Maybe the material Ikea uses for the legs have changed? I ended up having to use bolts, washers, and nuts to attach the shelf brackets to the legs. Now those suckers are on there real good. Here are the parts I used:

So all told about $42 before taxes. I’m not including the saw that I had to buy to cut the 46″ shelf to better fit the length of the LACK table’s width.

Suggestions:

  • Get a floor mat for standing. I stand barefoot so this really helps but I imagine even if you have shoes on, this probably helps. Luckily, I had one at home we bought for my kids but they never use. These from Hmart are pretty nice: Kitchen Mat.
  • Do not attach the shelf to the bracket. I have other attachments to the table (maybe in another blog post) and I find it really helpful to be able to remove the shelf.
  • The shelf I bought was unfinished, this isn’t a great idea since that causes a lot of friction between the surface and the mouse. Either get a glossy finished shelf or a mouse pad. Or sand paper and some wood polish might do.

A couple idea to improve the design:

  • A cable hole through the middle of the top surface for USB cables from my monitor.
  • A strap that somehow attaches the backside of the standing desk to the desk below, although I’m not really sure this is necessary.

Different Ways to Fetch Data with Core Data

For the life of me, I couldn’t find any decent information about optimizing Core Data fetches, specifically whether creating Fetch Request Templates improves performance. How best to use caches and indexes to improve performance. So I started some sample code to test these questions. Pretty simple app, but it gave me an opportunity to play with a data set from OpenDataPhilly. I picked the test scores of Pennsylvania high schools. Maybe, I’ll write something else using this dataset.

The source is up on github.

Notes:

  • Creating a Fetch Request Template is about 9 times faster writing out a NSFetchRequest.
  • There’s got to be something I don’t understand about setting the cacheName value of NSFetchedResultsController, but it’s exactly the same speed.
  • Creating an index improves performance as expected, approximately about an order of magnitude on this specific test.
  • At first I thought that maybe creating a Fetch Template created an index which is why it improved performance. But it’s definitely more than that because when I created a Fetch Request Template on an indexed field, it improve performance even more.

Testing iOS Apps

At this moment, if you search on Google for “unit testing ios,” the second result points to a page on Apple’s developer site that is outdated and now points to a generic “Tools Workflow Guide.” Most of the first page of results are really brief overviews on the topic or dated. Coming from Rails world, perhaps I was spoiled by the abundance of mature frameworks with tons of examples, tutorials, documentations, and even whole books on the topic. As much as I really enjoyed diving into the world of iOS development, I was very disappointed by the dearth of tools/documentations available on this front. I’m just starting to cover new code I’m writing with tests.

I’m writing this in May of 2012 so using Xcode 4.3. Apparently, until 4, the built in tools kinda sucked so GHUnit was pretty popular. As of Xcode 4, OCUnit is a very reasonable tool to use. Combined with OCMock, pretty easy to setup, easy to use, and good enough for me for now. These tests are compiled and there’s no system environment to load so they run fairly fast. I miss being able to have tests run automatically when I changed tests or code. I also miss being able to run specific tests. I’ve read somewhere that some consider this behavior a feature. Meaning that it’s best to always run all your tests. I’m not sure I buy this, but I don’t really care as long as they run fast.

It looks like there are some other functional/integration testing tools they seem a bit immature to me still. For now I’m just going to be sticking with built-in tools, a.k.a. using Instruments/Automation to record user testing scripts. This basically requires a functioning app to create these tests though. So I think the workflow for me will be to write unit/functional tests in OCUnit, implement the feature, then write integration tests in Instruments/Automation. I’m not religious about TDD but I did appreciate that it really got me write more tests. As with most people, I find it hard to get excited about writing tests for features already implemented. As much as I believe in the ability of these tests in reducing the overall implementation time, for me, the best incentive is to make the process of writing tests more enjoyable for myself.

The app I’m primarily working on now had zero test coverage before I started. It was apparently bit of a rush to implement features until now, the codebase was a rather hacky around the edges, no model layer to speak of (not using Core Data, basically no separate model code, and not syncing information with a backend). Largely due to not using Core Data in the first place, the app tended to use idiosyncratic ways of doing things in favor of idioms/apis/sample code that Apple lays out in its documentation. The scariest part was that the app was interconnected to other parts of the codebase in ways that made the app brittle to change. By far the thing that would have help on-boarding on to this app that much easier would have been to have some tests to run while I was getting familiar with the codebase. It’s hard inheriting then refactoring/adding features to a codebase you haven’t written, but to do it without any sense for how your changes are affecting the rest of the codebase is pretty nerve-wracking. I don’t think this benefit of writing tests for your code is covered enough. Having reasonable coverage helps when you have a team of people working on something, and especially when you add to the team after foundations have been laid out.


Incorporating an iPad to My Work Station

It’s always nice to have more screen space. I’ve been considering getting a bigger screen but decided to get an iPad instead (although I’m sure I’ll be tempted to get an iMac 27″ when Apple updates it this summer). The iPad has other equally important use cases for me, but it’s been especially interesting figuring out exactly how I would incorporate it into my desktop as I work. Physically, I bought the Smart Cover and have it standing horizontally. The iPad is also supported by the four books behind it that the MacBook sits on top of (thats to have the MacBook’s screen at eye level). The iPad being below eye level (and dimming on inactivity) has a side benefit of not distracting me as much but being there for quick reference.

More interesting than the physical setup are two ways to incorporate it into your work station software wise. I thought I would outline it here.

Use your iPad as an extra display.

You need some like Air Display for your iPad. It’s $9.99. Then you need to install the Air Display Connect on your Mac. This literally makes it seem to your Mac that the iPad is another screen. You can arrange it in the display settings and just like any other monitor, you mouse just moves to it and you can drag windows into it.

Pros:

  • This allows you to use the keyboard and mouse seamlessly. You can even touch on the iPad to move the mouse or click buttons.
  • Air Display Connect software is also useful if you have another Mac that you want to connect together and use one keyboard and mouse.
  • It supports the retina display iPad using it as a HiDPI display.

Cons:

  • This connection is fragile. Restarting the computer, I had to reconnect. Press the home button and use another app on your iPad, you can lose the connect if you leave the Air Display app for too long.
  • This basically wastes the iPad as a computing entity with it’s own memory, processor, and apps. It’s just a  display.
  • I think because on the iPad retina display the resolution is crazy high, it’s really laggy. Dragging a window into it and positioning it is hard because of the lag. Video is out. On the other hand, my most common use case – tailing a log in a terminal – it seemed to work fine.

Use your Mac’s keyboard as a Bluetooth keyboard for your iPad.

You need iKeyboard for your Mac. It’s also $9.99. Once you’ve made a connection between your Mac and iPad, you can bring up this app and everything you type is relayed to the iPad via the Bluetooth connection.

Pros:

  • You get to utilized the iPad to to it’s fullest. You can have music, email, etc. running on it. For me, I have music playing and either email, reminder app, or a browser open to PivotalTracker.
  • You get to use your keyboard on the iPad. Maybe this item is not necessary as that’s the whole point of the app, but I don’t like having 1 item lists.

Cons:

  • If you don’t have something running that keeps it from locking, the iPad will turn the screen off. Not having it auto lock doesn’t work for me because I don’t want it on all night as I’ll never remember to turn it off as I leave the office. The perfect solution for me is to have the Music app playing during the day which dims the screen but doesn’t lock the device.
  • The mouse doesn’t control anything on the iPad so you still have to touch it.
  • You have to switch over to the iKeyboard app to begin typing. Hmm, wonder if I can setup some sort of keyboard shortcut that brings up a specific app?

Conclusion

After spending $19.98 buying both these apps and trying each for a day each, at this point I feel more comfortable with using iKeyboard and using the iPad as a separate device but be able to type using my keyboard. It also promotes a good behavior, to segregate email as a separate activity set aside for certain times of the day. When I just email using your computer, I slip into it. Emailing on the iPad, at least for now, I notice it conscientiously. I think that should last, but who knows, maybe my brain will adjust and I’ll slip into emailing again.


Korea and IE

I’ve covered this topic before, but not on this blog and there’s some updates.

In a way I’m proud of the story of how IE came to dominate in Korea. Export of the encryption technology strong enough for online commerce was banned in the United States. Korea wasn’t going to just sit around so the Korean Information Security Agency took matter into its own hands and created SEED. I love the initiative and the foresight but horrible implementation of the idea.

Over a decade later, we have 80% of the users in Korea using IE. Hopefully it’ll get better over time. I’m not sure if the dip starting mid-2011 is a trend, but I hope so.

In the meanwhile, some Korean sites that only work in IE. Common dudes, be embarrassed.

This one is especially sad because it’s meant for foreigners to use.

And Wooribank has branches in the US.

 


Can’t Wait Till I Can Install Some Nanobots

Last Updated: 2012/4/6

Well, until some nanobots are available for purchase, I’m probably going to have to buy one of these. I’m still not sure about the science of these devices. I haven’t had the time to really track down real papers on how tracking sleep really works. I’m still doing research so this post is a work in progress.

Sleep Trackers

Zeo Sleep $129.00. A headband that hooks up with iOS. Seems like the most likely to be based on real science but again, I haven’t done enough research to know.
LARK $99.00. Wrist band. iOS only. It’s also an alarm clock. Haven’t heard much about it.
SleepTracker $149.00. Bulky wrist band. No iOS/Android. Dr. Phil endorsed? Ehh.
Sleep Cycle $0.99. It uses the iPhone as a data collector. I’m rather skeptical of this working. Especially if one of the kids or Yuyoun is in the same bed. And even if they weren’t, this can’t be as accurate.

Activity & Sleep Tracker

Fitbit $99.95. Clip that has a wrist band. It also track activity which is a plus. Both iOS and Android.
Jawbone Up $99.99. Wrist band that hooks up with iOS. Also tracks activity.

Activity Tracker

Nike Fuelband $240ish. Seems like it’s sold out in most places. No mention of tracking sleep.


Walky.me

I decided to go with Walky.me for my side iOS project. A few reasons (thanks Jon for highlighting these).

1) It’s a small, well scoped project that is potentially going to have real users.
3) I’m pretty sure I can get my teammates at walky.me to help me test and promote it.
4) Thanks to Bel, I’ve already got pretty UI assets to use.
5) It’s an excuse to play with MapKit and CoreLocation.

If you want to help test this as I build it, let me know and I can add you as a tester and you can my latest development builds on your iPhone (iOS 5.0+ and no iPad support).

If by some chance you want to help or see the code:

https://github.com/jinyk/Walky.me-iOS-Application

Don’t have much yet. The UI is wholesale ripoff of the iOS Maps app. And I will probably continue to copy everything down to how they handle directions and settings.