mattmorris.org

I’m what you might call a client-side iOS programmer, but for my latest project I’ve decided to roll my own backend. I’ve been thinking about the authentication flow will be needed. I don’t want users to remember usernames/passwords, and I don’t really want to have to keep track of them.

Currently, for development, the backend just checks for a single unique token that the client must send with all requests. (Assume that I’m using SSL Pinning to ensure that I’m not connecting to a man in the middle.) This is okay when the app is just on my phone, but I can’t very well ship the app with the token embedded. Even if it’s obfuscated, there’s no guaranteed way to prevent someone from unearthing the token and making rogue API requests. And by rogue API request, I mean any API request that’s not a result of normal use of the app.

It really wouldn’t be the end of the world if this happened. The only consequences I can think of is my database filling up with junk, or maybe someone could try to brute force their way into getting some semi-sensitive data out of the API.

So anyway, I’d like to have some per-user, or per-device, token that I can use to authenticate API requests. I’m thinking of trying the following password-less approach:

• User is prompted to enter an email to sign up for an account. At this time, a unique token is generated and sent to the API along with the email address. Token is stored in the keychain on the device.
• User is prompted to check his email to continue. Offer a button to open Mail.app, GMail.app, or another mail app that’s been detected.
• Meanwhile, at the backend, an email is generated with a unique URL and sent to the user. Tapping this link will whitelist the token generated in (1), and kick the user back into the app.
• From now on, whenever the app becomes active, it queries the API to test if the token is whitelisted. If a good token is not found in the keychain, then the app can go through the flow again to generate one. And this would give me a mechanism for blocking a token or email address that is acting suspiciously.

So this would let the app authenticate with the API without the need for a password. The downside is that the user will have to go through this flow on every new device. Perhaps I could store the token in iCloud to avoid that problem.

Questions:

• Is this a horrible idea? Could I somehow achieve this with OAuth?
• Does it matter if the token is generated client-side or server-side?

It’s 8pm. The kids are asleep, and I just sat down at my desk to begin my day’s “work.” But I am so physically and mentally exhausted that instead I’m going to write this post and then go to sleep.

Where did my energy go? Well, today I cooked three meals for four people, taught “preschool” for two hours, took the kids for their annual doctor’s checkup, washed and put away two loads of laundry, played kickball in the street with the neighborhood kids, cleaned the kitchen three times, read stories for half the afternoon, bath time, bed time, Lego time, nap time, dinner time…

Being a stay-at-home parent is hard work. I have to actually listen to my kids and stay engaged. I have to put away my phone and interact with them. If I can’t keep up, challenging and stimulating them with new activities and experiences, then they get bored and ask to watch TV.

Today I calmly and quickly diffused a tantrum that, only two months ago, would have probably thrown me for a loop. I might even have gotten mad and raised my voice. Instead, I now have the mental and emotional energy to do better.

Oh, and it’s been several days since the kids have even asked to watch TV.

So what’s my response when asked about my decision to quit my job and become a full-time dad?

“Worth It.”

Last night I was prepping my Aperture library for the upcoming move to Yosemite. I ran across this photo from my first Job.

I was in Amsterdam at Vrije Universiteit, helping install this PET/SPECT camera. I wrote the gantry control software and the UI pictured on that screen.

A few weeks ago I announced that I have departed Bomgar to work on my own projects and to spend more time with my family.

It was my privilege to work with the great team at Bomgar for almost 7 years. The job was challenging and rewarding, and I’m very proud of what we accomplished. Leaving is very bittersweet.

However, I’m excited about the future. I have a new product in the works that will launch on iPhone, iPad, and OS X, and I’m already writing a work estimate for what could be my first contract as a freelancer.

Most importantly, I believe that providing my children with a full-time parent will yield benefits in every corner of our lives for years to come. I expect to look back on this period of our lives and say with certitude that it was all worth it.

Last weekend I took my family to Cass Railroad to ride some steam engines.

Cass is a small town in the mountains of West Virginia. Formerly a company logging town, Cass offers a chance for a relaxing weekend getaway. And free from the burdens of broadband and cellular reception, you can be sure that your enjoyment of the trains will never be interrupted by blips and boops from your smartphone.

If you have a young child that loves trains, I highly recommend it.

I built the backend for my last project on Heroku using Sinatra. It was great; I got to learn about Ruby and a new web framework and it was a very stable and fast API.

I’ve been thinking about what to use for my next project when I saw Marco’s Web Hosting for App Developers and the ensuing discussions among developers on Twitter. After giving it some thought I came to the conclusion that I could probably learn alot by self-hosting the backend myself. Maybe I can even build something as stable and reliable as what I built on Heroku?

Rebuild, Rebuild, Rebuild

I made the decision up-front to script the entire process of building the server. This way, in the event of a network outage at Linode or in the unlikely event that my app comes under heavy load, I can add new servers in a matter of minutes.

My current scripts do the following:

• Setup SSH keys and disable SSH password authentication
• Setup firewall, leaving only ports for my application open.
• Install git, postgres, golang, and other software used by my application.
• Configure postgres and golang
• Checkout the application code from my repository
• Configure it so that it automatically starts when the system reboots.

Did I miss anything?

Another thing that I do to make sure that my scripts are always in working order is to rebuild the server every time I make a substantial change to the script. Also, I completely rebuild the server every evening I sit down to work on it. This leaves me feeling pretty confident that I can quickly recover from a serious outage.

Now, you might have noticed that I mentioned golang above. I’d originally planned to use Flask, but as I already have some experience with Python, I chose Golang so that I can learn something new. The dowside of this will be that Go isn’t as widely used, and I will be navigating uncharted water without the usual wealth of online sample code and SO Q&A. Still, my early impressions of Martini + Golang are very positive. I’m hopeful that I can get everything working withough too much headache.

Next:

I need to setup automatic database backups. I’ll probably use a cron job that automatically sends raw backups to Amazon S3. Also, I’d like to support HTTPS for all API calls. Since I’m just building a web API for my own app, I can just be my own Certificate Authority and issue my own SSL certificates and keys. Any problem with that?

Have any comments or suggestions? Let me know.

I recently wanted to see a graph of a particular stock assuming dividend reinvestment. This seems like it would be a common thing to do, but neither Google nor Yahoo’s finance sites appear to have the capability. After a bit of searching, I found a way to do it.

So here, I’ve plotted $AAPL over the past two years with and without dividend reinvestment. Note that $AAPL first paid a divident in Augustof 2012, so it’s logical that the graph begins to diverge shortly after that. Currently the difference in return is about 4.3% over the two years.1

You can fiddle with this graph yourself. Or, starting from scratch, do the following:

1. Create a chart for AAPL
2. Set the range (above I used 2 years)
3. Set “Type” to Thin Line (optional)
4. In both the Overlays and Indicators sections, click “Clear All”
5. Under Indicators, create a Price/Performance indicator with parameter _AAPL and set “Position” to “Behind Price”.
6. Click “Update”Interestingly, stockcharts.com appears to assume dividend reinvestment by default, while Google Finance and Yahoo Finance do not.

For the past five years, I have worked in a traditional office. A few weeks ago, I moved a thousand miles across the country and became a telecommuter. Several months before the move, I started gathering material to try to help me prepare for the new work situation. Here are a few I found useful.

• Home Work is an excellent podcast examines the ins and outs of telecommuting and freelancing. I’m not a freelancer, so I cherry picked the episodes that seemed most relevant to me. If you’re currently an office worker but think you might like to try working from home, check out Episode 27 – Telecommuting Basics and Episode 55 – Telecommuting.
• The Beginner’s Guide to Working from Home is a recent article that has several good tips for a new home worker.
• Working From Home covers many of the pitfalls and challenges associated with working from home, and offers several tips on how to make it work.

Here’s my core advice to anyone about to start telecommuting for the first time. Give some proactive thought and planning to your home office setup, your work/life schedule and boundaries, and your effectiveness as a communicator. Also, try to be aware of what distractions are most problematic for you and take steps to minimize them.

Late last week, I finally got around to setting up Twitter as an account on Mountain Lion. I was disappointed to see that clicking a Twitter notification launches the default web browser and not Twitter.app or any other client. I do not enjoy using Twitter’s web interface, so I wrote a simple application that forwards these clicks to a native Twitter application of your choice.

Quick Start

If this sounds like something that you would find useful, download the beta and give it a try. The application is a single dialog that asks for your preferred Twitter client. Click ‘Okay’ and you’re all set. There should be no need to run the app again unless you want to switch to a different client.

Disclaimer

This software should be considered very “beta.” If things get weird and you find you can’t open http URLs anymore or something like that, just delete the .app and http://www.twitter.com/boxel.

How It Works

Interception registers itself as the default handler the URLs that are invoked when you click on a Twitter notification. If it notices a Twitter URL is being loaded by Launch Services, it catches the request and forwards it to the native twitter client you have chosen. All other URLs are silently passed as-is to the default web browser. A previous version of Interception set itself as the default http URL handler for the system, but this is no longer necessary.

Known Issues and Next Steps

Interception currently supports only the following Twitter clients:

– Tweetbot for Mac
– Twitter.app
– Tweet Deck
– Hibari

Currently Interception is just hard-coded with the bundle identifiers for each of these apps. In a future version, I might add a “Choose App” button which would let the user. If your favorite native Twitter client is not one of these four, please let me know.

Also, Twitter mentions and direct messages should land the user on different views inside the targeted Twitter app. I began to wire this up, but it seems that the Tweetbot for Mac public alpha is not yet honoring the Tweetbot URL Scheme, so I put that functionality on hold for all clients. Tweetbot is awesome, and this will be the next feature I add.

I have created a project over on Github where I will host the code. I have not posted it yet for two reasons. First, I did this in a bit of a hurry and I would like to clean up the code before I throw it out into the wild. Second, if our local Cocoaheads chapter gets going in the next month or two, I might like to present the project at a meeting and then release the source code and slides all at the same time.

Wrap-Up

Download It Here. Feedback is welcome.

I realize that if you’re favorite Twitter client is in the Mac App Store, it can use push notifications in Mountain Lion, in which case Interception won’t really be that useful. I’ve really been enoying Tweetbot for Mac, but it’s currently in alpha and doesn’t yet support remote push notifications. This application grew out of a script I wrote because I wanted to be able to launch Tweetbot from a notification even if Tweetbot wasn’t already running.

Incidentally, I’ve lost track of how many times I typed “Inception” while writing this post.

Two months ago, in preparation for LASIK eye surgery, I searched the internet for accounts of people’s experiences with the procedure. I found a wide variety of results, most of which were positive. Since I didn’t find anything from the point of view of a professional programmer, I will leave my account here.

The Facts

Pre-surgery, I was highly myopic with a prescription of -8.75 in both eyes.
Pre-surgery, my vision was correctable to 20/15 (better than 20/20)
Date of surgery: May 30th, 2012 @ 7:30am
Post-surgery prescription, measured the day after surgery:
I’m told that –.25 is effectively 20/20.

My Daily Routine

I believe that how you use your eyes every day is an important factor to consider when thinking about LASIK. For someone in a career that requires almost constant use of a computer, having clear and reliable vision is very important. To give a clearer picture of my results and whether or not you can draw any conclusions from my impressions, here is a rough outline of my typical day.

• Awake at 5:45
• Leave house by 6:45
• 40+ minute commute
• At work: 8+ hours of programming
• Workout during lunch
• 40+ minute commute
• Dinner + family time.
• Once kids are asleep: 4+ hours of programming on personal projects.

(Note: This is the fullest possible schedule. I can’t pull this off every day.)

During the pre-surgery interviews with the surgeon, I explained that I am a professional programmer and asked if I could be expected to return to work the next day. Answer: yes.

The Surgery

The surgery itself was not a big deal. It was a little uncomfortable at one point when a suction device is attached to the eye, but that didn’t last long. When I first got up from the opterating table, everything appeared as if I were underwater. This was, in fact, because there is actually fluid in the eye that drains away over the next 24-48 hours.

Recovery, Day 0

After the surgery, I was driven home by a family member. There was no pain, but my vision was cloudy and I would have been unable to drive. My two boys were at home with a babysitter. Once home, I attempted to close my eyes and rest, at the recommendation of the surgeon.

Later that day there was more discomfort, but my vision was already beginning to clear. I cooked the boys dinner and got them ready for bed with no problem.

Once they were asleep in bed, I sat down at the computer to check my email and maybe try to work on some of my apps. I was barely able to read email.Needless to say, I was a little concerned, since I was scheduled to return to work the next day. But I decided not to worry about it for the time being, hoping that 8 hours of sleep would give my eyes time to rest and recover.

Recovery, Day 1: Halos

The next day I realized that I was seeing the dreaded “halo” effect that I had read about online. Around every light source, I saw a very noticeable ring of light. It turns out that this didn’t really bother me when I was doing most “normal” activities. Computer screens, however, turned out to be a problem. They emit light, and when reading text on screen, each character produced its own halo, and every halo overlapped with the ones adjacent to it. This created an unbearable blurring effect that made it very difficult to read on-screen text.

In fact, I went in for a 24 hour followup that day. My prescription was measured using a autorefractor, and my vision was determined to be very close to 20/20. However, I was almost completely unable to read the letters on the eye chart. The eye chart appeared to be an LCD backlit display, and this was producing haloing effects around the letters.

I did manage to get to work that day. However, it was frustrating because I had to place the screens mere inches from my face and increase the font in Xcode to rediculous sizes. It was so large that I suspected people could read my code from the hallway by my office.

Recovery, Week 1

The halo effect persisted well into the first week. It was still difficult to read a computer screen, but I found that if I used the lubricant eye drops recommended by the doctor, it helped a great deal. Yes, the drops temporarily cleared my vision. I found that if I used the drops every 45 minutes or so, I could code the whole day without getting too frustrated.

One Month Later

At times I still have to use the lubricant eye drops in order to use a computer, but my vision has gradually improved to the point that I sometimes go several hours without having to do so.

I’ve been asked several times how satisfied I am with the procedure. I think that if I had any type of job that doesn’t require reading code on a screen for 10+ hours a day, I would be 99% satisfied. As this is not the case, I would probably say that I am 85% satisfied.

To this date, I still feel that my vision continues to improve. If you’ve recently had LASIK and are concerned because your vision is still blurry, your eyes may still be healing. Try not to worry.

Tips

Close your eyes and rest as much as possible on the first day. I think I tried to do too much that first day and I wonder if it slowed my recovery.
If you experience halos and have trouble reading a computer screen, try the lubricant eye drops.
Use them frequently, even if the dryness doesn’t bother you.
Try to schedule a short vacation from work beginning the day of your surgery. If this is not possible, try to schedule the surgery right before a 3-day weekend. Reading a computer screen as part of a demanding job was stressful during these first days, but driving, cooking, playing with the kids, etc. was not a problem at all. Drive to the coast and get some rest.

Fun Fact

Radial Keratotomy, a predecessor to the LASIK procedure, was discovered by accident after a young boy fell off his bycicle and broke his glasses. Some time after the doctor had removed the shards of glass from his eye, his visual acuity had improved. [source]