Wednesday, July 23, 2014

Breaking Mac Apps

One of the reasons I took my current gig as a Software Development Engineer Test (SDET) was so I could learn more about my craft of software development. Too often as the developer under stress to get something out the door it can be tempting to do the minimum testing possible to get the feature out the door. That temptation is tempered by the fact that you know if you ship crap then you will have more headaches than spending the extra time now to get it right.

So, I wanted to concentrate on breaking a product too see what I learn by finding it's rough spots. This has been fun at times in the sense that I am actually learning ways to more effectively test my own software. I plan to use this knowledge to write better software myself.

I am currently testing a product on both Mac OS X and iOS. As a dev I have some things I learned from writing Mac apps that I have been able to put to use in my job as a tester.

One of those is to always test the First Run case. What is this? The First Run test involves running the app as if you were a new user installing and running the app for the first time.

How to do this on Mac?

  • Does the app use the Keychain to store anything? Find out and make sure to clear it before you run the test.
  • Does the app use the User Defaults to store anything? Probably, so go learn the command line tool defaults. Here is a short primer:
    • Open
    • Run this: defaults
      • Now you have the standard usage (screenshot shown above).
    • If you app's defaults are stored in the domain "com.mycompany.myapp" then type this to view what the app is storing: 
      • defaults read com.mycompany.myapp
    • Now before a First Run test run this to clear the stored setting: 
      • defaults delete com.mycompany.myapp
  • Does your app use any other storage? SQLLite for example? CoreData store?
    • Find out, find out where the files are stored and then delete them before you run a First Run test.
Run the test and see what blows up.

Too often we forget to retest this scenario as we work on features and the simple First Run case can get broken.

Test it often to weed out problems before new users find them.  I always run this on candidate builds for a new release to end users. I am also always surprised when this breaks since we seldom think the simple changes we are making in our app will break the First Run.

Monday, July 21, 2014

Sometimes You Just Have To Get Your Hands Dirty

Hockey Tweet in Landscape iPhone 4s (Landscape
was not in the original)
I have dropped off the radar for a bit as I have been busy with some projects. I took a week off from everything but code as I worked on porting my old 2009 Hockey Tweet app to Swift. I have written about that and will some more as I have major updates.

I was also studying for some interviews I had. One was an all day affair with a 7 hour interview that included a 2 hour pair coding session. We are still talking and no news yet to report on the job.

Outside of that I have been ramping up house work. For several reasons, I might have to sell my house (job), the house needs a new paint job, the deck needs a new paint job (or I will be replacing sooner rather than later), and of course I have all the prep work to do (caulking, 15 tubes Sunday) to even begin to paint.  Sunday I got a solid 8 hours in of caulking and then painting.

I started the painting so that I can begin alternating between caulking and painting. Since they use the hand and arm muscles differently, once I get tired with one I can switch to the other for a while. I also have over half of the house caulked now and wanted to get the front of the house completed. I figure I can do the front first and then continue the back of the house into the fall. Since you won't see if, you won't notice it is half/not done.

So, it's been a week of getting dirty. Dirty with new code as I learn to program in Swift. Dirty with house work.

Now some may ask, why not pay someone to paint your house? Heck, I wish. But at a $25,000 average quote to paint the house including prep work (some would not include prep since the amount of caulking was so daunting); I am sucking it up and being a man (frugal).

This just means I might have less posts for a while since how many blog posts can you do about painting you house? Who knows, but I am sure we will find out ;-)

Monday, July 14, 2014

Swift Websites of Note: July 14, 2014

While porting HockeyTweet 2009 from Ojective-C to HockeyTweet 2014 in Swift I have been doing lots of Swift reading. Here are some of the sites I have come across of interest in the past week.

Airspeed Velocity's name is a play on the Monty Python joke about the airspeed velocity of a swallow. The site is an in-depth look into areas of the Swift language. Very good deep dives here if you want to go below the surface of Swift to read about how to get your hands real dirty with the languages nooks and crannies so far.

Of course I have to mention the official Swift Blog from Apple. It is nice to see Apple opening up and finding more ways to reach developers. I think this is needed if they want to get widespread buy-in with the new language and it is certainly appreciated. I look forward to good information coming from this blog.

Not a new site by any means and widely known throughout the iOS/Mac world is Brent Simmons. Brent has decided to jump on board with Swift so he can provide feedback to Apple as he learns the language. Check out his blog, inessential, for current posts on Swift as he shares what he has learned with it.

Those are 3 of the blogs I have been reading this week as I work with Swift.

Sunday, July 13, 2014

Modernizing a 2009 iOS App with 2014 Swift

I wanted to learn a bit more about how Swift works and the best way to learn a new language is to start to code in it. The videos and book are great but I need to get the code under my fingertips to start to understand it better.

So, to get some experience with Swift I decided to port my first iOS app, HockeyTweet, from 2009 to a modern HockeyTweet built with Swift in 2014.

First what was HockeyTweet? It was a Twitter app optimized for Tweeting about Hockey games in a time before custom keyboards, auto correction, or enhanced predictive text inputs. So the scroll views were there to help you spell player names, put in arena names, post your favourite comments on the play, etc. It sold like...well, the opposite of hotcakes.

What it did do though, was help me to teach myself iOS programming which meant a leap into front end UI design, a new language (Objective-C), and new development tools. Now after 5 years of programming with Xcode daily, I am a little more experienced. How will that impact learning a new language and porting the app? Let's see.

Here are my notes as I worked on the app over the last 5 days:
  • Started on Xcode 6 Beta 2.
  • Moving to Beta 3 my storyboard elements all greyed out in the storyboard and were not viewable in the preview pane. Had to delete and recreate.
  • Learning the Swift syntax has been the normal new language growing pains. At least the code completion, warnings, and errors help to understand.
  • My app would crash in the Simulator when I tried to test it. Learned there are some missing init for a ViewController classes in Swift, you need these classes implemented for each ViewController you create:
    init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) {
        // Perform custom init here
        super.init(nibName: nil, bundle: nil)
    init(coder aDecoder: NSCoder!) {
   // Perform custom init here
        super.init(coder: aDecoder)

  • Getting my head to wrap around ? and ! for variable unwrapping. ? Is optional and ! Is used to unwrap a value if it is not nil.
  • I forgot how easy it is to get a container view from the parent view; access it via the embed segue.
  • Conversion from Cocoa to Swift sucks in the places that Swift methods for Cocoa methods are not provided. Like the missing loading from file methods for containers like NSArray and NSDictionary.
  • I lost storyboard elements again with some getting greyed out. Had to add a textview and label 2 times now due to this.

What are my thoughts on Swift?

  1. It's young and missing some stuff we take for granted in Cocoa. That is not a problem though, I expect heavily used functions from Cocoa that are missing to come over time. In the meantime we will have to wrap some Objective-C types to Swift native types.
  2. It takes a while to mind shift into the new Optionals and variable unwrapping but in general I like the idea and what it is fixing. I think this will be a good thing and cause less bugs if people do not try to circumvent it.
  3. Wow, what a lot less code I have to write now to implement the same app. I like it.
  4. Storyboards have come a long way from what you cold achieve with NIBs in 2009. I knew this already form other apps but seeing it in a rewrite was cool.
  5. UI Layout is a bit of a pain and feels like more work doing the constraint sizes but in the long run I can see this being less work and less code to write to handle the custom view sizes. Not needing custom code paths for iPad, iPhone 5+, iPhone 4s will be a blessing. A project or two and we will look back at older projects and cringe I am guessing.
  6. I am still subconsciously typing ; in places. I search and replace (occasionally) to delete them and it is entertaining to see that I added them again without thinking.

So, after 4 days of coding a total of about 12 hours I have completed the following:

  • Compose UI Ported
    • Missing Info View
    • Missing Custom Fan Favourites Edit View
  • UI layout
    • Best for iPhone 4s (original)
    • Need to handle larger sizes as a test of constraints. I will save this for later.
  • Model
    • Partially ported so far.
    • Loading initial data is taking some time since I need to work out the conversion from NSObjects to Swift objects when loading plist files with NSDictionary(contentsOfFile: String).
    • Network calls not hooked up.
    • Currently using initial load and sample data from testing of original HockeyTweet in 2009 so the players on the teams will be messed up.
    • Dropped schedule for now.
What do I plan to add next:
  • UITextView Hookup
    • Need to be able to take user input and have scrollviews insert data into tweet.
  • CharsRemaining Label
    • Hook up when UITextView for tweet composition is complete.
  • Share
    • I get to drop all the old Twitter code and go with the new Twitter API from Apple. I want tog et this hooked up and working.
  • Networking
    • Pull updated arenas, schedules, and team rosters from my web service.
    • This might be a chance to try out a new backend. Since I am not building this app for AppStore submission I will test this local only unless I land on a backend technology that I can run for free in the cloud.
Philipe Casgrain, my friend from CocoaHeads in Ottawa, put me onto the Summer of Swift. A contest to learn by coding. The idea is to code an app in Swift and do weekly updates to the project over the summer. I am going to enter that and continue to update the app over the summer. Adding back in original features and some new stuff to experiment with Swift.

The code is available to view on Github at HockeyTweetSwift if you want to take a look, grab some ideas, or make the next great Hockey Tweeting App! Ok, that last one is a joke.

Tuesday, July 8, 2014

Ongoing Interview Prep

When you go into an interview you want the job right? I know I do.

Today, if you want the job then you need more than a resume. I am sorry to say, but if your value is all based on your previous job experience then you are missing a whole area from which to shine.

One of those areas is to build something, anything outside of work. There are multiple stories on the web about building stuff outside of your job for many reasons (here is a current popular one Spotify Design Lead on Why Side Projects Should be Stupid). For me, I love a challenge and working outside of my comfort zone to help me grow.

Here are reasons to build something outside of work:

  1. Learn: You can learn a new language, platform, API, or if you want to do something outside of programming, you can learn to plan and build something. I have played with Arduino to learn a bit about hardware, woodworking to fix and build stuff for my house, and music to learn just how difficult, yet easy, music is to create.
  2. Show: If you program something outside of work then you can post it on github and then you have an example of your work to show to a prospective employer. This is a win-win for you since you can show how you write code, how you design your software, how you test, etc.
  3. Tell: With a project outside of work you can talk about it. Many of the projects I have worked on are NDA which can make it hard to talk about what I did. It gets awkward when you can not talk about what you did for the last year. A self made project outside of work gives you something to talk about, challenges faced, and lets you show an interviewer how you think and deal with problems.
This is one thing I call ongoing interview prep. Not only are these projects fun but they give me a chance to discuss different topics to at an interview.

My current project is to port my 2009 iOS HockeyTweet app to 2014 iOS using Swift. This is letting me learn Swift and see how the changes in iOS over the last 5 years have changed how to write a virtually identical app. So far, a lot less code to do the same thing.

I'll be posting more on this once I complete the project.

Friday, July 4, 2014

Programmer Career Development: Always be Learning

I am sure this comes as no surprise to most programmers but here is how career development works in the field of programming, as I know it. The short story is, if you are not developing yourself then you are putting yourself at risk if the axe comes, the next job will be harder to find and you will be several steps behind when you have to retrain.
Image from HockeyTweet, the
1st iPhone App I wrote to teach
myself iOS programming.
I spoke to a fellow programmer recently who got cut from his full-time job and started contracting. He does not contract out of choice but out of a need to earn for his family. He was in one field for many years with a large company, they retooled their business to eliminate an obsolete product and his skills were no longer needed. His skill set was obsolete.

He related that when you get older people do not want to hire you as much. But when I listen to his story I hear someone that did not keep up with the changes in technology and the programming skills required to be current for today's jobs. He was blaming age for what was really a skill set issue.

I completely disagree that age is the issue. I think skill set and engagement in your field of choice is the issue.

If you are engaged in your field, are taking time to train yourself in the new technology/languages/processes, then your past experience is an asset to add to your "current" skills. Your past is not a detriment, it's a wealth of experience. Let's admit it, the hot languages change, the platforms change, but the skills to be a good programmer do not. We are still reading and learning Computer Science theory that was written long before we were born or started in the field. Data structures, algorithms, and optimization have not gone away; they are just dressed up in a new set of robes.

This week I have been catching up on the material from WWDC 2014 and getting my feet wet with Swift. For me, I am excited about the improvements Apple has made. 

On the flip side, I have hear/read some Apple programmers bemoan the fact they need to learn so much new stuff. I think these are the people that came into iOS programming since that is the current hotness and they needed a job. They didn't start iOS programming because the loved the platform.

I feel bad for those people that feel it is a chore to learn this. I know myself, that it is hard to chisel out the time to get current on the new APIs, language, and more but this is our job. Companies don't give you a week off to train. If you want to stay current, you figure it out.

Put me in the camp of those that love iOS. I started programming with it from day one of the SDK being available. It has been a blast and one of the most fun platforms I have programmed for. I thought a Vic-20 was awesome as a 7 year old, so I can not imagine what I would have thought of programming an iPhone at that age.

I can't get over how much I am loving Swift. The videos are such a great introduction and I can see that the hardest thing will be getting our minds wrapped around the new syntax. Being able to do so much in one line will be powerful but also take some concentration to reread. I love the power of the syntax but am reminded of my days writing a lot of Perl. I remember writing similarly super-powered single line statements that turned out were hard to debug or read a day or week later. I have higher hopes for Swift since it does not get into the crazy number of special operators that Perl had.

For me, the advances Apple has made this year are not a burden I must bear. They are a reduction in some of the boilerplate we had to write, they are a simpler way of doing things, and they are a view into the future of programming on Apple devices.

Monday, June 30, 2014

Dealing With Communication Barriers At Work

Driving in Tunisia, where the main languages are
Arabic and French.
We once went on vacation to Tunisia. That was in October of 2010, just before the Arab Spring started there. Yes, really.

Now, why do I relate that? Well in Tunisia the dominate languages are Arabic, French, and then everything else. In general though, you speak Arabic or French to get along. My wife and I do not speak Arabic, she speaks French fluently, and I speak French apparently (an instructor once told me but I think she was lying so I would sign up for another class).

So, to say the least, my wife did the talking. The thing about Tunisia it that it is a male dominated culture so woman, though having freedom not held in many Arab countries, are still expected to take a back seat to their husband when in conversation. So it was funny when my wife would talk to a man in French and he would answer me, the guy who had no idea what he was saying. It was uncomfortable and funny.

If that was not bad enough, police stops for routine license and registration checks are common. Like, expect one per 2-4 hours of drive time. Ya, seriously.

I felt just a little bit out of my element using my limited French to answer 2 police officers questions. Why was I in their country on vacation? Why was my wife driving? And other fun questions.

Thankfully, once I told them I was from Canada the conversation always went to Montreal, Canada Dry, and how cold it is there! Thank goodness for their relatives being in Canada.

So, I have been on the wrong end of communication breakdown and it is not fun. I have walked in those shoes and did not enjoy it.

For me it is ridiculous that in high tech, a bunch of highly educated people lack basic common courtesy. As a Canadian in the US, and a Newfoundlander at that, I have had my fair share of double takes from fellow native English speakers who are suddenly unable to process what I just said.

That pales in comparison to the crap I hear non-native speakers take. It blows me away that people talk so poorly to others that are struggling to communicate.

Here's what I have learned while working with non-native English speakers and those from different cultures.

  • Chill Out: It is a lot harder for them to understand us and get their point across than for us. So, don't lose your cool because someone can not speak at your high level of native nuance, "Ok, Bro, 'nugh said?"
  • Read the Cues: Start to read people's expressions. Did they all of a sudden raise an eyebrow or go kinda blank? Maybe they have no idea what you are saying or missed a word. I find it common to use terminology that seems basic or normal to me which others do not catch. Ask if there was something you said that they did not get. Don't be a jerk but be helpful and offer to explain.
  • Put Yourself in Their Shoes: Do you think they enjoy working in a language that they may struggle with? Probably not. Have you ever tried learning another language and then using it on vacation? Ya, that 2 weeks sucked and your grasp of the language sucked worse. Give your coworker some slack.
  • Be Polite: If they don't get it, then don't be a jerk. I have heard people raising their voice and belittling non-native speakers that are misunderstanding a topic/bug/feature. Instead, look for more constructive ways to come to a common understanding. After you explain yourself, try asking the other person what you said. And tit-for-tat, when they explain something to you, repeat back with, "What I am hearing is…" Repeating back what you heard is a great way to see if both parties understood.
  • Learn Some Culture: Go to lunch with your non-native coworkers. Get to know them and their culture. Some cultures say yes but mean no, maybe or yes. Three or four yeses means yes in some, whereas one means not likely. Do some research on culture differences/hazards and then keep your newfound knowledge to yourself (check out the hand gestures in this one for a laugh). But use your knowledge to try to help you understand your coworker better.

I've done all of these to be more effective with colleagues from different language and cultural backgrounds. I enjoy working with them as much as anyone else. I find that as we learn to communicate better we grow in our relationship and come to trust each other since we can cut through communication barriers to be effective.

People appreciate when your show respect, are willing to take the time to understand them, and learn about them. It's make work easier and more fun.