Just Git’R'Done on Gun Control

When I was in third grade, we lived in Fairbanks Alaska, and I wanted to be a grown up. Because Alaska is frontier wilderness, a lot of the activities I remember were around doing things in the outdoors with the family.

I wanted to be grown up, so I got a paper route (at eight years old I was the youngest one they’d ever had). I remember that I had to borrow my Dad’s typewriter to write the circulation department telling them why I wanted to be a paper boy.

I also remember my parents making me take my little brother with me so I wouldn’t get into trouble and getting into trouble anyway (but that’s a whole bunch of different stories).

Creating a New App (step 1)

I decided I’d walk through creating a new app to replace one I’ve used for years on my iPhone that no longer appears to be maintained. The app in question is called GasBag which as near as I can tell stopped being updated in 2009 (see: http://blog.jam-code.com/).

 

I could just write a quick and dirty web app to store my mileage, but I figured I’d approach this as an exercise in building an iOS application with a design first approach.

 

At a high level, what I want is an app that easily captures my mileage, and allows me to save that information somewhere that won’t get destroyed. There are a number of features that GasBag had that I liked (for instance being able to send an email with my mileage information), and a number that it doesn’t have that would be nice (like allowing me to use it for multiple cars, or to do some data capture from a gas station receipt).

 

Communication Lessons from Mom

I grew up in a fairly large family: three boys, a girl and Mom and Dad. We had a gazillion aunts, uncles, cousins, grandparents , relatives and friends.

Because of this, there were a LOT of communication channels, and as a natural part of her position in the family, that meant that Mom was a hub to a LOT of that communication.

So as we all grew up, and moved on with our lives, I began to see something interesting happen: because we all spoke less frequently, there would be times when we would hear about things in a very delayed fashion.

“Oh that was probably around the time that Aunt Jo died”

“Aunt Jo died?”

“Oh, I thought I told you, that was last year”

It took me a while to figure out what was going on, and see this sort of thing happen in my own life. As near as I can tell there are a few of reasons why we as humans have trouble with complex communication channels like the one I see in my family.

Reason 1 – Once we plan to communicate, we forget to do it.

Especially when we are busy, and have limited interaction with people, it is easy to plan to give a message to somebody and then get distracted with other things. In the case of the family dynamic, as we were no longer all in the same household, fewer opportunities to actually say the things that are planned to be said wer available, meaning there were more opportunities for distraction between plan and action.

Reason 2 – Once we verbalize to some people, it’s hard to remember who we talked to.

A huge survival trait we all share as humans is generalization, and our subconscious tends to exhibit this with the people we are closest with. If you’ve ever heard a parent run through all the children’s names before hitting the right one, you know what I’m talking about.

And because the subconscious doesn’t really differentiate much between planning to do something and actually doing it, the plan we made to talk to four other people, really does seem complete once we’ve talked to some portion of them, because we thought about talking to them all.

Reason 4 – Priorities change.

When we plan to communicate, we know it’s important but with limited opportunity for that communication, other things come up that mean we don’t get around to it, and it no longer seems as important. In the fictitious “Aunt Jo” example, time has passed, mourning is done, and there’s not usually a reason to remember that we never had that conversation we meant to.

Reason 5 – We remember good things better than bad.

I’m a firm believer that it’s important to give feedback immediately, especially when it’s about something bad that happened. I also believe that over time, we remember the good moments in our lives better than those that aren’t as positive. That’s why when you think about the music that was on the radio when you were in high school, all sorts of wonderful tunes pop into your head, but when they actually play the top 40 from that same year, you hear some things that make you smile and wonder why they were popular.

This is probably another survival trait: I know for me, I can remember what to avoid, but the memories for what a burn feels like, or how much it hurts to skin my knee, is not nearly as vivid as what it feels like to hug my wife, or have that wonderful feeling of contentment after a holiday meal.

So if communication about something bad gets delayed long enough, it’s human nature not to bother with it. Not only do we  want to avoid dredging up things that aren’t fun, but the value of doing so has diminished, and so we just choose to forget (and maybe can’t remember).

So my solution for the Mom Communication Event ?

It’s really the same goal with every bit of communication, test that the message you sent was the one received. I used to wonder why people used to say “Did I tell you about …”, but now I know why, they were just being human, AND being good communicators, just like my Mom.

 

Danger of Time Saving Tools

I was reminded a couple of days ago of the danger of using tools that help you to get things up and running quickly, by a question that I was asked in an interview. The question was pretty simple, but not something I’d thought about for a while, which was: “What are the verbs used in RESTful services?”.

Now intuitively I know that answer, but hadn’t really thought about it for a while, so I basically answered incorrectly (mostly because I suck at inteviews), only remembering that you do GET and POST in HTTP, so responding that GET is to query and POST is for inserts/updates.

Of course I know the reality (and one of the advantages) of RESTful services is that they behave by contract, so they can use the full complement of the HTTP verbs, and the convention is to use each one for a specific purpose:

• GET – used to get or retrieve a resource (always returns the same resource for the same query).
• POST – used to create a new resource (returns the location for the newly created resource).
• PUT – used to replace a resource (typically an update).
• DELETE – used to remove a resource
• OPTIONS – sometimes used to describe information about what verbs a service can use for a specific URI (not normally implemented however).

But the last few times I’ve done RESTful services, I’ve simply let an IDE generate them for me, so I haven’t even thought about those last statements. In the IDE, all I had to do was say I wanted to add REST (using Jersey) to my session beans, and voila, I have a full fledged RESTful service.

And of course on the consuming side, all I have to do is call the right method, and under the covers the Jersey client stuff does the right thing about which verb to use. So I’m not actually thinking about what’s under the covers, and because of that wouldn’t be quick on my feet about how the service is constructed under the covers.

There are of course pros and cons to approaching code in this way. In the early days of writing code, we all had to know what the machine language underneath looked like. Modern languages hid that complexity from us, and reading assembly language became a lost art practiced by rocket scientists and performance gurus.

By hiding the complexity we have been able to develop insanely complex applications that would not have been possible without those building blocks. Freeing ourselves with increasingly general patterns in code, we are able to focus on solving the problem at hand, and stand on the shoulders of those that go before us in doing so.

I don’t expect to need to write a RESTful service from scratch any time soon, but it is a good reminder that when you rely on tools to build your code, you are risking living with a lack of understanding of the underlying mechanism, which could make it difficult to know about the pros and cons of a solution.

 

Moving to GMail on your iPhone

After moving from a hosted Exchange service to GMail, you need to set up your email client on the iPhone so that it will receive the push notices.

To do this, you need to add a new Exchange service on the device. There’s a nice step by step of this at http://support.google.com/a/users/bin/answer.py?hl=en&answer=138740

Alternatively, you can use the standard GMail settings, on the iPhone, but my favorite approach is to actually use the GMail app from Google in the App Store. The reason I like that app over the standard iOS mail app is that it is much more of a true mobile client that takes advantage of the platform.

First get the App from https://itunes.apple.com/us/app/gmail-email-from-google/id422689480?mt=8

 

You can do this either from your iPhone/iPad directly, or using the iTunes store on your Mac/PC.

Once you have the app installed, you need to set up your GMail accounts. Either tap “open” from the App Store page about GMail, or find the GMail icon and launch it.

On launch the app will prompt you to log into your account. For a Google Apps account, this will be the email your administrator assigned you like rob@mydomain.com, and the password that you’ve set up previously by going to http://gmail.com.

Launching the App the first time takes you to the login page, where you can type in your email address and password. Note that this is the same whether you are logging in to a GMail account or a Google Apps account, to Google they are just different users as far as mail goes.

Once you log in, you will be shown the inbox for that account, and be able to read your email pretty easily. To navigate the folders (like sent, draft, etc), you tap on the little icon in the upper left corner that looks like a box with stacked bars.

This will cause the folders and settings pane to slide out from the left and reveal your email structure so that you can choose. Clicking on a particular folder will display that list in the same fashion as you saw with the inbox.

Additionally from this screen, you can add other email accounts by tapping on the profile area at the top of the pane, which slides the list of accounts down and changes the direction of the panel indicator at the top of the pane.

If you’ve already done this, you will see the list of accounts, and each one will be badged with the number of unread messages. Adding a new account is as simple as tapping the large plus icon and logging in. Tapping on a profile picture will switch you to that account once you are logged in.

The little gear icon in the upper right of this corner brings up settings for you email where you can set a few things (such as vacation responder, signature, etc).

Once you log into the new account, you will again see the loading page, this time with the image from the new account’s name and profile image

The next time that you go to the account selection page, you’ll see a list of accounts with the icon for each badged with the number of unread messages showing so that you can easily see what needs your attention at the moment.

Google apps on the iPhone are a mixed bag, with some being native, and others not, so it’s also a good idea to set up the Apple “Mail, Contacts, Calendars” for synchronization of those things (which can use the Exchange push in the same way as an actual Exchange server).

The best way to do this is to follow the instructions at http://support.google.com/a/users/bin/answer.py?hl=en&answer=138740

First go to your settings (normally you can find this by clicking the home button on and looking for the gear icon that says “Settings”.

If you’ve previously added accounts, the “Add Account …” will appear below the existing account settings list (in my case I actually have to scroll in order to get to this button.

Tap on the add account button and you’ll be presented with the choice of types of account that you want to use. You can use GMail here, but I prefer to use Exchange simply because it pushes the information to the phone asynchronously

Once you tap on the Exchange button, you’ll get a new page that prompts you for the authentication information. This uses Microsoft’s autodiscover method to figure out how the account should be configured.

Type in the user name and password for your account here, and give it a description. Typically I use the name of the company that has the domain that I’m adding (for example PMI-SFBAC for my pmi-sfbac.org address).

Then click the “Next” button which should bring up the Domain screen. The only thing you need to make sure of is that the server ends up being m.google.com, and that you still have the right username and password. To continue,  tap “Next”.

The final step is to choose what you want to be pushed to your phone. Generally the important ones are the contacts and calendars, since those are business related.

It really doesn’t hurt to have Mail turned on as well, since that keeps your inbox in the iOS Mail app up to date, but if you’re worried about your data plan, just set up the contacts and calendars, since that is the part that the GMail app won’t really be as helpful with.

 

 

 

 

• Facebook
• LinkedIn
• Google +1
• Twitter
• Digg
• StumbleUpon
• Reddit
• Tumblr
• Pinterest
• Print
• Email

Like this:

Like Loading...