Lego Sandcrawler Timelapse

With a little help from the boys we built the Lego Star Wars Sandcrawler set this weekend. Here is a time-lapse of the 3296 piece build.

This is Lego set 75059.

We built it over 3 days.

The most tedious was the 304 treads for the 8 tracks for the 4 legs of the crawler.

Don't be surprised if I order RC motors next to motorize this ;-)

Apple Watch Ideas

Like many iOS devs, I am playing around with Apple Watch ideas. As with most things, I have no shortage of ideas. It's the implementation that is always the hard part.

Now, why can implementation be hard? I think because we try for perfection too often.

Many devs I have spoken with, and myself included, come up with lots of features that we can add. Heck, everyone does this. Name a piece of software you could not make better with a couple features you'd love.

The problem when you are the product designer, graphic artist, programmer, and every other hat needed to ship your own product, is that you need to decide what to cut and when to ship. The inability to cut is one impediment to actually shipping.

As devs we want our apps to be perfect and have lots of neat features we would want. It has to be just right with tip-top graphics. It should have iCloud support, custom UI controls, support multiple languages, have accessibility, and the list goes on. All these things might be great but does the app really need it?

At times I have been parallelized by feature bloat as I design some apps and hence they never get built and never ship. I call this app day dreaming. Boy, wouldn't it be cool?

For example, recently I started to think about some apps I could build for smart watches. Some are for laughs with my two boys, some are jokes with coworkers as we batted around ideas, and some would solve problems I have which I would rather solve with a watch than a phone.

Like any project, I decided to capture these ideas and start to estimate how long I thought they would take. As I started to add features to the list for each app it grew longer and longer and the timeline started to crush my excitement.

As I waited for the Apple WatchKit to be released for development I started to say, maybe these ideas would not even be possible. So, I just planned more and made contingencies, "If Apple gives us support for this, then I can do this idea." etc.

Then the WatchKit came out and I realized I could actually do most of my ideas. Let's start in. But then reality hit. How am I going to build this feature set out?

• Full iOS App to support the Watch App?
• Ads to provide a trickle of revenue if the app gets traction?
• In-App Purchase to add additional features/themes so I can hope to get paid a bit for my work?
• Fully featured ability to edit content on the Watch?
• Storage of content?
• Graphics?

This is a lot of work for one person to pull together in their "spare" time. We all know how much of that we have.

While getting down from the work load ahead I was listening to the App Business Podcast. In particular, the episode ABP115 – Michael Dowell of App Indulge. During this episode, and others recently, I realized I am complicating things too much. 

How many of these features did I really need?

Could I design the apps differently to reduce the work but keep features?

So I started to look at how I can trim one app in particular:

• First off, drop the content editor.
• Instead: supply templates for users to fill in their information.
• Drop the in-app purchase for themes.
• Instead: re-package the app for each theme and release an app per theme instead of one app that can download the themes. Less work to create downloadable content. Increased SEO with the name of the theme being in the app name and app description.
• Move content editing into the templates as much as possible. Then move what can not be in a template into the iOS Companion App. Then leave the remaining for the Watch. Thereby simplifying the app on the Watch which makes it easier to use and less complicated to code.

Applying this strategy to several of my ideas means I will ship more apps that do less. That is fine, since my research indicates that you have very little time to get a customer to decide if they are going to buy/download your app. So I need to optimize the discovery time and effort for ROI which means simpler apps, with streamlined descriptions in the AppStore so I can hope to capture the most customers possible.

With the AppStore having so many apps it does not pay, from what I can tell, for a single person or small shop to spend a lot of time on adding features in their app when their app may never sell enough to pay for the cost of development, let alone living expenses.

So, let's see how this experiment works as I find spare cycles to write a couple apps to scratch my itch.

Software Development is Obviously Hard

Look at Apple's recent iOS 8.0.1 release that broke cellular.
Look at (any company's I have used) Wi-Fi or Bluetooth stack and how flaky it is every other release.

The technology we use, rely on, love, and spend a lot of money on each day is a big let down when it fails. For non-techies I hear them blaming themselves. They must not be using it right.

Here's a secret though, most times when it is not working, but it worked yesterday or 5 minutes ago, it isn't you, it's the gadget. How many times have you cycled your WiFi or Bluetooth off/on to try to fix connectivity? Too many.

I feel for the people that don't know this much (you sometimes have to reset things).

It used to be a big joke, and I made it plenty of times, that you had to restart your Windows PC daily or whenever it started to act strange.

The bigger joke today is that we have to do that to the device in our pocket more often than we care to admit.

I always think, maybe it's me and the stuff I am interfacing with each day. Bluetooth headsets, in-car bluetooth, switching multiple networks, installing/uninstalling apps. My day to day usage of mobile devices is a little more extreme than the average user I figure and so I run into "edge cases" all the time.

Or maybe, we just need to spend some more time polishing our software before pushing it out the door.

DerivedData and xcodebuild

If you use Xcode you know about DerivedData. If you don't know DerivedData, you don't know Xcode.

If you are setting up xcodebuilds from the command line, say for continuous build and integration (CI), then you want to make sure you are using that command line the best way possible. Some things I keep running into as I see people's build systems are:

• Running out of space due to a backup of old DerivedData.
• Build performance hanging, due to a backup of old DerivedData.
• Unexplainable build failure, solved by deleting, you guessed it, DerivedData.

If you use the command line for builds then save yourself a lot of trouble in the future. Start using the xcodebuild option -derivedDataPath.

Here are the docs on it:

-derivedDataPath PATH                     specifies the directory where build products and other derived data will go

That one option huge significance. Here are some reasons why I use it and convert build systems over to this option:

• I can store the DerivedData in the temporary source workspace of automated builds (like CI builds, automated test runs, etc.) When the workspace is cleaned up the DerivedData goes away and net disk space should be 0 at the end of the build.
• With no shared DerivedData between builds the build performance does not drop due to large DerivedData folders.
• Without a shared DerivedData folder I see much lower instances of unexplainable build errors. This means less cleanup, less build host reboots, etc.

Personally, I am very interested in how remote builds with Mac OS X Server and Xcode have improve the build process for automated builds. Until I get the chance to put such a system together, for now and for legacy build systems, I will use xcodebuild -derivedData to improve build systems I have to work with.

Make a Swift Based iOS App Crash

I am writing an app for a contract where one of the deliverables is that the app must demonstrate various crashes.  Of these various crashes, one must be an application crash.

On top of that I am writing the app in Swift (about 80% Swift, 20% Objective-C libraries not ported to Swift).

It shouldn't be too hard to crash a Swift app hey? Well, if you follow Swift guidelines your app should be pretty stable since the language has been designed to force devs to be safer in their use of the language. That's not to say that misunderstanding the language or forced unwrapping of optionals that could be nil will make your app any less crash prone.

So let's break the rules, get unsafe in our use of Swift and crash this app.

I decided to go with this piece of code:

var crashWithMissingValueInDicitonary = Dictionary<Int,Int>()

let crashInt = crashWithMissingValueInDicitonary[1]!

This produces a crash with the following error:

fatal error: unexpectedly found nil while unwrapping an Optional value

The reason is this:

• Line 1 is creating an empty dictionary with Int keys and Int values.
• Line 2 is Force Unwrapping the optional dictionary value with a key of 1. Nothing has been added to our dictionary yet though so this means we will get a nil. Assigning this nil to a constant value (let) and we get a runtime exception, crashing the app.

So, there is one way to write a bug intentionally to crash your app.

See the Swift docs for further information on Forced Unwrapping and how they are used with Optional values.

The Walking Dead

Image: http://www.thewalkingdead.com/

Well, I finally caught up on The Walking Dead. I read a number of the comics and figured I was
good. I read the comics, what would I get from the show. Being that I watch little to no TV I had no real desire to watch the show.

Then too many people told me it was different and it was worth seeing. I finally gave in and started to binge watch it this summer while Michele and the kids were on a trip and I was stuck home painting the house and working at a new job (no vacation time for me).

My summary of the first season is. This is just a drama with Zombies thrown in. Look, people not getting along. Tension. Zombies. Tension. Not a real, hook me season but it was good enough and I was told wait for Season 3. Also, pretty similar to the comic.

Ok, Season 2, now we are talking. Things still similar to the comic. Enough divergences that I was wondering when Shane would die. Giving me a big hook. I liked how they started to amp up the tension and the season finale was excellent. I was so glad I did not have to wait long to start Season 3.

30 seconds later, hit Season 3, Episode 1 on Netflix and we were in. Season 3 did not disappoint.

It was great. The addition to the story with the competing Woodbury was excellent. I liked the twists it added.

Now one aside. I do like to think that humanity would not turn to such shit as in the show.

What I found interesting throughout the seasons is that the characters meant to be most unlike me, Daryl and his Brother (but more Daryl) are the ones I truly connect with. They aren't stupid. While all the other "city-folks" are running around crying about the end of the world, these guys are scavenging and killing Zombies without a blink of an eye. The world has changed and you better drop your I'm too good for this quick or die is what they show. I like to think people would react this way, but maybe that is just me.

I guess by this admission, there is more Redneck in me than I figure. In reality, it's just the writers trope that people are stupid and would take a long time to adjust to a fight for survival. The counter-point for most of the characters are two guys who seem simple but in fact have their shit together. So, ya it's TV and the stupidity makes for tension and "good TV" I guess.

I finished Season 3 a week or so ago and I am getting the shakes from missing "my show." But last night, Season 4 was unleashed on Netflix in prep for the return of The Walking Dead, Season 5.

So, now I am binging again, waiting for the next season. Who will survive?

Describe yourself in an eye-catching 150 chars or less

I just applied to a full time position that wanted me to describe what makes me unique in 150 characters or less.

Here's my shot at that:

I've flown a plane with an electrical failure at night, watched life float pass pinned to the bottom of a river, and I still got the job done.

I've written about the night flight electrical failure in an earlier post. The river story is for another day ;-)

MT 

Here's a Surprise, I am Behind The Tech Curve

Image: Microsoft.com

There used to be a picture of me in the dictionary under early adopter. I stood in line for game console launches, game launches, device launches, etc. I had Model 1 of lots of products.

My wife, being a Marketer, was amazed when she discovered this. She was both surprised that Early Adopters were real and she was married to one. I never told her I played D&D until after we were married. ;-)

So, here I am, with an 8 yr old in grade 3 and we have been informed that the school is now allowing (and encouraging) BYOD (Bring Your Own Device) for grade 3 at our school. The personal computers can be used for computer time and for in class research if the teacher allows it. Our teacher is on board and so my wife and I are now left releasing we are one of the late adopters with electronics and our kids.

Part of this is our desire to reduce screen time for our kids. Part is our desire for them to be drawn to outdoor pursuits and finding fun without the need for a terminal.

But now I must admit that culture is moving on and technology is now a requirement for an 8 year old in class.

Frankly I am not surprised and also amazed at the same time that I will be sending my son to school tomorrow with a Surface RT so he can research in class. It's cool and younger me loves the idea. 

The old man in me says, "When we were kids we hauled a Dictionary and a Thesaurus in our backpacks. And no a Thesaurus is not a Dinosaur! Damn young whipper-snappers."

Oh well, technology marches on.

The Blerch Has Been Beaten, For Now

Friday I was frying with a high fever. Yes, the first school cold is rolling through our house and I felt terrible.

I skipped going to pickup my race kit on Friday and thought I would not make it to the race Saturday morning. When I woke up, I was not a ball of fun. I pulled on my running gear and shuffled out to have some waffles with Nutella (breakfast of running champions).

My kids and wife asked, "Are you going to go run?" I told them, "I don't know. I am going to get my race kit at least and then I will see how I feel when I get there."

I truly felt terrible and did not want to run. But I realized this was The Blerch, inserting excuses. Excuses like, "You didn't train. You feel terrible. You have a fever. Go have a rest, you'll feel better."

Screw that, I knew from past experiences that running will make my cold "disappear" for a couple hours. Once I got to the race start I was starting to think, ok, I can do this.

When I got to race kit pickup and I think they saw I looked like hell. They offered, "Hey, if you want you can downgrade to the 10k."

My willpower and desire to run 13.1 miles (the 1/2 I signed up for) was not there. "Yes Please!"

I now had an extra 30 minutes to hang out and decide to do this.

The 1/2 marathoners were off and we started to lineup for the 10k.

I was in.

I decided to use a tactic I had used before. I went into the back of the pack with the "hope" I would feel good enough to pass people and have that motivation to spur me on. It appeared to work as I passed people and felt propelled by this. I was not sure I'd be able to keep up the pace but it was working well.

I steadily passed people until I hit an equilibrium and stayed pace with the people around me.

Then I ran a good race. I stopped twice to take a walk break, once in mile 4 and then again in mile 5.

The race was super fun with a ton of costumes (Banana Man, Hot Dog Man, many Blerch, fat suits, an Oreo Box, a female Rebel Pilot in Orange dress, the list goes on).

A truly funny part was when a lady dressed as a Blerch called out to me to have some cake as I ran towards her at the 3 mile food station. Near her was a Sasquatch lurking in the woods frightening/taunting people to join a Blerch for Nutella Sandwiches on a couch. It was a bit surreal, like running through an Oatmeal Comic.

If you get a chance, come try it next year. I'll be back.

Writing a Software Development Agreement

Now that the word has gotten out that I am contracting, I have had interest from friends and associates in doing "small" apps (iOS and web) for them. That's cool but I know very little about running a business and writing software for others is a business.

Currently I am contracting through a large contracting firm and so I have not had to deal with writing contracts or the business side of contracting. With the number of enquires I have fielded, I figured it was time I drafted a Software Development Agreement template that I can use for projects I consider taking on myself.

Being a developer for many years, I know that Software Development is hard. What do I mean? I mean that turning an idea into a finished product is hard. Delivering something that matches the original concept is hard, but we can make it easier. We make it easier by capturing requirements, agreeing on a process for change requests, and iterating on the design with frequent check-ins with the client to verify we are on track with the vision (the Agile way).

That said, business is business and I need something in writing that a client and I can use as our guide for how to deal with delivery, changes, intellectual property rights, compensation, and the other details we as developers seldom think of.

So, I did a few searches and here are some links I used as a guide.

• https://www.pandadoc.com/software-development-agreement
• Open Source Legal Documents for Developers
• And I found this after working on my version: Mobile Application Development Contract 

I took what I liked from each and dropped some stuff I was not in favour of. I am not truly happy with this format yet, I would like to write something a little more free flowing but this is a good start.

Take a look at my Software Development Agreement and see what you think. Also, remember, if you have been reading along here, I am not a lawyer, nor do I play one in real life or on TV. So, talk to a real lawyer if you want real contract advice.

Anything I should drop?

Anything you think is missing?

-- Mark

I Have to Hire an SDET (Software Development Engineer Test) for iOS, What Should I Ask?

One, of many, of our beach rock finds.

This was the question I got a few weeks back when an acquaintance from Xcoders messaged me to say he had to interview an SDET, for their iOS product, later that day. He did not know what to ask and what areas he should ask them to dive into. Did I have any suggestions?

So, over Twitter I gave a couple quick ideas on what to ask.  Here is that list, expanded a little.

• What frameworks have they used to test iOS?
• Compare the differences between those frameworks.
• Go review this answer on stack overflow about iOS Testing. This will give you a rundown of the testing frameworks and tools for iOS.
• What are the pros of those frameworks? What are the cons? And the next question...
• Have they done UI Automation testing? How? What were the results of that testing?
• How do they manage their tests? It should be better than I don't. Tools used to track the tests to know what coverage you have is essential.
• How do they report on them? Not much good doing tests without being able to report on the results.
• What are the different granularities of tests and how have they used them in past positions? Which do they find the most useful for iOS?
• Unit Tests
• Functional Tests
• End To End Tests
• UI Automation Tests
• Manual/Adhoc Testing
• What difficulties have they had testing iOS?
• Or maybe the more blunt; What have they found to be unsuccessful or not of value when testing iOS?
• Ask this since it might highlight the one area you want to concentrate on they might hate.
• I have seen testers write great and sometimes not so great bug reports. 
• How do they log a bug? 
• What information is important? 
• They should have an opinion on what to include.
• Most iOS apps use a web service back end of some kind. How do they test the results of web service calls?
• They should be saying Charles (or alternative packet sniffer like WireShark) here and using a proxy to sniff the HTTP packet flow.
• Whiteboard time
• Give them a simple method (Objective-C based please), just the definition and what the method is supposed to return.
• For example, something that takes a string and returns a sorted array that includes each unique word found in the string. I just has to be complex enough to cause them to write several examples.
• Ask them to write testcases for this method.
• Do they know the syntax of Test::Unit style or RSpec style?
• Can they program? If not, then you don't want them as an SDET. The whiteboard coding question should be a breeze for them.
• Do they know scripting languages? Ruby? Python? Javascript? 
• They should since the tools built on top of Apple's iOS testing frameworks are normally written in a scripting language.
• They will also need to integrate tests with build systems which means command line knowledge and the ability to script command line jobs.

That was the short list I came up with with some additions once I expanded on the brief Twitter exchange.

Anything else you'd look for or ask?

Is Contracting For You?

I have not answered that myself and as such I am asking myself that question. I certainly like the fact I am working on new things and getting to branch out into areas I might not normally get a chance to work with. That said, there are some downsides as well.

At first you are going to see that hourly rate and say, wow that is a lot per hour. Hold on there though. Most likely that rate does not include paid holidays or vacation time. So you need to take your salary/year based on 40 hour work week (if your contract is 40hr/week) and then minus the vacation time you'd like to have and the holidays you won't get paid for. Check up front to find out if you can work holidays. If you can't, each of those days off is 8 hours of pay you are missing.

That adds up to make your hourly rate start to not look so good.

The other thing to consider about your rate and contracting is are you going to go with a firm (I have) which makes finding contracts easy but eats into your rate. Meaning, that the contracting company is taking a cut of the rate per hour you are being paid. Now, you don't see that taken out of your pay cheque, but needless to say, if you want to do the harder path and run the business side of things then you can make more contracting on your own.

Also, do you want to gain ownership of something and make decisions about the design and direction of the product? Then contracting, unless it is an architectural position, may not be your thing. So far I have seen that contractors in general are paid to get stuff built. That is great if you don't want to have ownership and just like doing new things each day. Not so cool if you like to have a say in the product and help design what you ship.

I am still out on this one. There is certainly an advantage to just being a grunt, getting stuff done. It is amazing to see the amount of code/progress you can make each week just implementing and not planning. That said, it's nice to have some more skin in the game with the design of a product.

Some other things to keep in mind is that you (most likely) will not get matching contributions for retirement or other benefits. That is fine if you are getting paid a high enough rate. If not, then you are missing another chunk of cash.

Contracting has the allure of new projects, less maintenance of products, and the ability to make more hourly. The truth is that the new projects and less maintenance of long term code comes at the price of ownership in the product. The high hourly rate hides the visible benefits of full time positions that you might not consider.

So, like many things in life, it all comes downs to tradeoffs. Which ones are you willing to make and what do you want out of your job.

Do What You Love

Riding Bauline, Newfoundland, 1999

I love a lot of things. My wife, my kids, my music, and my many passions. One of those has been with me as long as I can remember.

That is biking. I still remember one of my first bikes. It was a yellow bike that was branded the Mark II. Pretty sweet and I am sure my parents felt they hit the jackpot when they came across that bike. Boy I loved that hard plastic wheeled bike. Not even inflated tires. It was a tank and had traction about as good as you'd think for hard plasticly (very hard rubber) tires.

Of the many forms of biking, Mountain biking holds a big place in my heart, for things I love.

It's something that sits unloved sometimes. Gathering dust in the garage, tires deflating, oil drying out, forgetting the thrill of the trail.

Then a call or text comes, "Want to go biking?" Hell yes I do!

I get out the gear, I prep the bike, and I go.

The other night I went for a ride.

It was great to get on the trail and hurtle downhill at speeds my Mom would disapprove of and my kids would watch in disbelieve.

Nothing quite beats the sensation of throwing that bike around underneath you as your legs and arms pump it over roots, rocks, around ruts, and then throw the bike (and you) into a turn.

As we speed down a section of trail with beautifully hard packed corners, I saw a rise coming in the middle of the S as the turn I was dipped into, leaning over to the right, was going to transition into a fast left hand turn before switching back to the right. Stupidity came over me and I said, I bet I can jump that rise right into that left turn and swoop through this set of curves.

I write this like I had time to think this out. There was no time, my brain thought it, and I pulled up. The bike and I flew into the air.

Was this a good idea I started to think. But before I could finish the thought, the bike and my body knew what to do. Lean back to the left like I was entering that turn on the ground instead of in the air like I was.

Thump! The tires hit. My legs and arms bent. And my ass and rear wheel threw my bike and I into the turn and we both flew through it beautifully.

We had done something stupid again and both made it through.

Mountain biking is freeing. It frees the mind and the spirit.

Mountain biking is exhilarating. Am I going to fast? Will I make this turn? Phew! Did it.

Mountain biking is pounding. It makes the blood flow and the muscles ache as you drive to go faster and climb the hill back up.

Mountain biking rejuvenates my youth as I slip back into my gear and get to pretend to be a Scout Trooper on his speeder bike, whizzing through the forests of Endor.

What do you love?

Go do it.

Remember why you love it.

The Illusion of Expertise

Replacing a section of my front
step. Definitely not my area
of expertise.

How much time does it take to become an expert with a new thing?

Let's pick a language.

I mentored a Junior Engineer on a work term who did some Perl development for our project. He then applied to work with us full-time when he graduated. Hey, I must have done something right to have him want to come back.

When reviewing his resume he had listed Expert Perl Knowledge or some such phrase. He wrote 2 scripts for us based off of scripts I had written. I asked him in the interview if he had done more with Perl after we introduced him to it. Nope.

Expert level knowledge? Sheesh!

As a professional developer I get asked to solved problems I have no idea how to solve every day. It's par for the job.

This is no different than many jobs I am sure. I know I have asked building contractors to build or fix something that they've never built or fixed before. So as a professional your expertise comes from being able to tackle these problems without fear. I am paying them for their past experience and ability to successfully deliver; same goes for being a software developer.

What do I mean by without fear?

I have worked with people that say they can't do something since it is outside the realm of their experience? They are asked to add some new functionality to an existing app or script and they say they can't, they don't know that language. I think this is the wrong attitude.

As an Expert, you are expected to step up and say, "Sure, I don't know that language but the program is already written and it just needs some small changes. I can take that on and learn a bit about the language it is written in at the same time. Thanks."

That's how I like to approach tasks outside my realm of Expertise. With contracting, this has become something I have to say more often. Does it slow me down to learn a new language? Sure, I don't know it off the top of my head but with the wealth of information on the web and help within IDEs, there is no reason not to jump in and try out a new language.

If you think you need to be trained in a language or domain to work in it, then you are missing out on being more useful to your team. Being willing to jump in and work in any language is a plus for you in your career that will make you more valuable as an employee.

Don't fear your lack of expertise. Dive in and take on challenges. You grow more from them than staying in your comfortable shell.

Building Web Services Quickly

Haven't We Been Here Before?

Seattle from the harbour.

The last time I built a web service was back in 2009. I figured out Google App Engine (GAE), it was great since it used Python (my pet language at the time) and with free hosting at the level I was going to use it, that was the platform for me.

I built Hockey Tweet with GAE and then designed Tweety10, a Cocoaheads Ottawa app, which a team of 6 built in 3 weeks in 2010 for the 2010 Olympics to use GAE as well. I ramped up one of the guys on GAE and he built out our web service while I worked on whatever needed my help.

What's This Web Service For?

I have a team that is interested in hiring me, possibly on contract, for their app. They would like a portfolio to see what I have done; which is hard to show when you work for large companies. So I am building a demo app, that will have a web service backend. As such I need to build a web service to simulate some of the features they mentioned. So I am cooking up a web service to simulate the backend service they want to build. I figure this is a good portfolio piece.

You see, I have worked for many teams/companies but those have been larger teams that had many people building the end-to-end solution. For this, I need to show I can build the app end-to-end. They are looking for their own on-site web services programmer but I need something to build my app against for the demo.

I also want some experience with technologies/framework/APIs I have not used yet. There are a lot of frameworks and APIs available to use in modern mobile apps and as such it is hard to find time to learn stuff you don't need for your day to day job. So, I want to try out some stuff I would need for this project, if the team decide to go with me, and also that will help me improve my portfolio to show that I can build an app from scratch with various technologies to meet a clients needs.

Tonight I laid out the storyboards for the app based on the initial use cases the team told me about. The storyboards let me get an idea of what data I will need to support the app. With that in mind I can also think about what the API calls should be. I see the storyboards as a visual walkthrough of the user stories, a kind of overview of the apps back-end.

Deciding on the Web Service Framework

I did some research an evening or two ago on various web frameworks so I could figure out what to mockup the backend web service in. I decided on sinatra, which is built on ruby. It is an alternative to Ruby on Rails and instead of following a Model-View-Controller design it is geared towards quickly developing a web application. So in other words, throw good design to the wind and hack up that web service fast. Perfect.

With Sinatra, you get the basics, but there are some additional features I want which were easy to add. I have added the following gems:

• gem install sinatra
• Basic sinatra framework
• gem install sinatra-authentication
• Adds authentication framework for your apps. I want to simulate adding users, login, logout, and then mapping users to resources (i.e. events for a user)
• gem install sinatra-jsonp
• To add json data payloads.
• gem install shotgun
• Shotgun: will reload your app each time a request comes in.
• This is a handy development tool that lets you run your sinatra install from the command line with (shotgun -p 4567 myapp.rb) instead of (ruby myapp.rb).

With that I have a basic web service running that I can talk to.

Next I will start to build up the API and write tests to hit the web service. I will then start to fill in the app by populating the UI with the data I am pushing from the web service.

I could skip the web service and do this with dummy data in the app but I want some current experience building a web service and so I am approaching the demo app this way.

Today's Challenge: Move

I took a couple weeks off from running. Studying for an interview, a trip, my wife on a business trip (solo Dad with 2 kids), and working on my house meant I had to cut something. So I cut running.

Thankfully, the house has been a good physical activity that has included a bit of movement to keep me happy. You see, I am happy when I am physical.

For me, running, swimming, biking, and everything else I do is not just to stay in shape, it's to stay happy. Read any number of studies and think about our past. Humans were meant to move.

So this morning I got in a run and I feel awesome. The thing is, before the run, and last night I knew I would go for a run today but I did not want to. I am sure you probably don't want to either.

Here was my thinking yesterday:

• I am too sore from house work (painting, caulking, scraping paint).
• I have put on weight not working out the past 3 weeks.
• My sneakers are probably too old and I will be sore.
• I'll probably get blisters.
• Blah Blah Blah

RUN!

I woke up at 6:15 AM this morning and felt great. Surprising since last night I went to bed about 10 after taking some Advil since I was aching all over. I was painting the house this weekend and spent a solid two days working on the house. It is coming along great but I did not expect to wake up feeling good.

So, I ignored my few aches and pains. I stuffed my fat ass into a pair of running shorts. I laced up those old sneakers. And I pounded the pavement.

As I ran I felt free. I felt alive. I felt good.

Ya, it was not my best run, my fastest, or my cleanest. But I did it.

As I thought about this I realized we are just meant to move. This movement can come in many forms. For example, if you are like me you don't wake up thinking, how can I squeeze in some time to paint the house today? But these days I think that. Is it just the fact that house is going to look good? Maybe a bit but a lot of it is climbing up and down that ladder. It is movement.

When I bought our current house I had many people tell me it was a mistake. They said, "You should have gotten a new house so you don't need to do any work on it for 5-10 years."

You know what those people were telling me? You need to find more ways to not move.

Screw that.

I think you should buy that house that needs a coat of paint. It needs some work done. Don't know how to do it? Great, learn. I sure as sunshine don't know how to do a lot of what I do. I just figure it out.

The best part of figuring it out and doing it is you get so many intangible benefits. You get exercise. You get a sense of accomplishment. And you get to know you just paid yourself first since you never paid some contractor to do a job you won't be happy with since it took longer than you expected and cost more than you wanted to pay.

So, for me. I say, find more ways to move. Find more ways to learn. Find more ways to work with your hands. Even though you think that it will suck, you'll thank yourself in the end for having done it.

Your challenge today? Move.

Snooping On Mac OS X Apps

On iOS an app is limited in scope to it's sandbox (unless you are on a jailbroken device) and so you can take a quick look at the apps filesystem within Xcode to see what it is storing. This is not so for the keychain but you can guess the keychain is in use if the app links the Security.framework.

Now, for Mac OS X, since the app may have access to more resources it can be harder to track down what resources the app you are testing is using. There are a couple ways to figure this out though. Here are the ways I use to get an idea what resources a Mac OS X app is using:

• Activity Monitor.app
• Launch Activity Monitor
• Find your app
• Double click it
• Choose the "Open File and Ports" tab.
• See what the app has open currently
• Use Dtrace
• This is the long bread method of finding out what your app is doing.
• Even better you can trace all file opens on a specific process (meaning you get a trace of the opens int eh terminal).
• To do this open Terminal.app
• This command must be run as root so I will show you the command with sudo at the front which will prompt the terminal to ask for your root password to complete the command:
• sudo opensnoop

Here is sample output from opensnoop:

sudo opensnoop

  UID    PID COMM          FD PATH                 

   89  72769 mdworker       7 /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/System/Library/Frameworks/OpenGLES.framework/glp_sh_interposer.dylib.dSYM/Contents 

   89  72769 mdworker       7 /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/System/Library/Frameworks/OpenGLES.framework/glp_sh_interposer.dylib.dSYM/Contents/Resources 

   89  72769 mdworker       7 /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/System/Library/Frameworks/OpenGLES.framework/glp_sh_interposer.dylib.dSYM/Contents/Resources/DWARF 

   89  72769 mdworker       7 /Developer/Applications/Xcode.app/Contents/Library/Spotlight/uuid.mdimporter

Notice that you get the User ID, the Process ID, the Process (COMM), the File Descriptor, and the Path to the file that was opened.

You can play with opensnoop to limit by process name, process id, etc.  Here is the usage output:

USAGE: opensnoop [-a|-A|-ceghsvxZ] [-f pathname]

                 [-n name] [-p PID]

       opensnoop                # default output

                -a              # print most data

                -A              # dump all data, space delimited

                -c              # print cwd of process

                -e              # print errno value

                -g              # print command arguments

                -s              # print start time, us

                -v              # print start time, string

                -x              # only print failed opens

                -Z              # print zonename

                -f pathname # pathname name to snoop

                -n name # process name to snoop

                -p PID # process ID to snoop

  eg,

       opensnoop -v             # human readable timestamps

       opensnoop -e             # see error codes

       opensnoop -f /etc/motd   # snoop this file only

I like to use this by process name, start the process, run the app a bit to exercise most of the functionality, and then look at what opensnoop found. Turn on printing of the errno values and you can see if any file opens are failing.

Come to think of it, another Dtrace script I love is errinfo. This one will show you system calls that are returning an error. It is a good one to use when you know the name of a process having a problem. For example, I once worked with a app that was not logging when it launched another process but the process never started. Missed error checking aside, I used this to show that the exec was failing due to a permission error. The permissions on the sub-process were not set correctly and the other process, running as a different user could not exec the process since it did not have the correct permissions. We fixed the missing error checking and the permission error and all was well.

If you want to know what Dtrace scripts your Mac has then run "apropos Dtrace". Here is what my Mac is showing for Mavericks:

Tcl_CommandTraceInfo(3tcl), Tcl_TraceCommand(3tcl), Tcl_UntraceCommand(3tcl) - monitor renames and deletes of a command

bitesize.d(1m)           - analyse disk I/O size by process. Uses DTrace

cpuwalk.d(1m)            - Measure which CPUs a process runs on. Uses DTrace

creatbyproc.d(1m)        - snoop creat()s by process name. Uses DTrace

dappprof(1m)             - profile user and lib function usage. Uses DTrace

dapptrace(1m)            - trace user and library function usage. Uses DTrace

diskhits(1m)             - disk access by file offset. Uses DTrace

dispqlen.d(1m)           - dispatcher queue length by CPU. Uses DTrace

dtrace(1)                - generic front-end to the DTrace facility

dtruss(1m)               - process syscall details. Uses DTrace

errinfo(1m)              - print errno for syscall fails. Uses DTrace

execsnoop(1m)            - snoop new process execution. Uses DTrace

fddist(1m)               - file descriptor usage distributions. Uses DTrace

filebyproc.d(1m)         - snoop opens by process name. Uses DTrace

hotspot.d(1m)            - print disk event by location. Uses DTrace

httpdstat.d(1m)          - realtime httpd statistics. Uses DTrace

iofile.d(1m)             - I/O wait time by file and process. Uses DTrace

iofileb.d(1m)            - I/O bytes by file and process. Uses DTrace

iopattern(1m)            - print disk I/O pattern. Uses DTrace

iopending(1m)            - plot number of pending disk events. Uses DTrace

iosnoop(1m)              - snoop I/O events as they occur. Uses DTrace

iotop(1m)                - display top disk I/O events by process. Uses DTrace

kill.d(1m)               - snoop process signals as they occur. Uses DTrace

lastwords(1m)            - print syscalls before exit. Uses DTrace

loads.d(1m)              - print load averages. Uses DTrace

newproc.d(1m)            - snoop new processes. Uses DTrace

opensnoop(1m)            - snoop file opens as they occur. Uses DTrace

pathopens.d(1m)          - full pathnames opened ok count. Uses DTrace

perldtrace(1)            - Perl's support for DTrace

pidpersec.d(1m)          - print new PIDs per sec. Uses DTrace

plockstat(1)             - front-end to DTrace to print statistics about POSIX mutexes and read/write locks

priclass.d(1m)           - priority distribution by scheduling class. Uses DTrace

pridist.d(1m)            - process priority distribution. Uses DTrace

procsystime(1m)          - analyse system call times. Uses DTrace

runocc.d(1m)             - run queue occupancy by CPU. Uses DTrace

rwbypid.d(1m)            - read/write calls by PID. Uses DTrace

rwbytype.d(1m)           - read/write bytes by vnode type. Uses DTrace

rwsnoop(1m)              - snoop read/write events. Uses DTrace

sampleproc(1m)           - sample processes on the CPUs. Uses DTrace

seeksize.d(1m)           - print disk event seek report. Uses DTrace

setuids.d(1m)            - snoop setuid calls as they occur. Uses DTrace

sigdist.d(1m)            - signal distribution by process. Uses DTrace

syscallbypid.d(1m)       - syscalls by process ID. Uses DTrace

syscallbyproc.d(1m)      - syscalls by process name. Uses DTrace

syscallbysysc.d(1m)      - syscalls by syscall. Uses DTrace

topsyscall(1m)           - top syscalls by syscall name. Uses DTrace

topsysproc(1m)           - top syscalls by process name. Uses DTrace

weblatency.d(1m)         - website latency statistics. Uses DTrace

Have fun with Dtrace, it can open up your debugging and give you a view into processes you don't own.

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 Terminal.app
• 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.

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 ;-)

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.

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.

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.

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.