Saturday, January 24, 2015

Another Midnight

Things are cooking as I move some personal projects from the back burner onto development status.

I've got an itch I am scratching for my Mac and hopefully some others will find it useful.

Now, back to hooking up menus, testing, graphics, and scratching that itch.

Sunday, January 18, 2015

2015 Stinky Spoke

The Stinky Spoke has come and gone again.

This year I have a GoPro and was able to catch some footage.


Music is from DB Custom Cigar Box Tribute including "today" by Jellyspine Jenkins and "greasy" by The Akron Bellyachers.

Monday, January 5, 2015

Biking John Wayne Trail

The Stinky Spoke bike ride is Jan 17 this year. A friend from work and I want for a training ride this past weekend. 25 miles on the John Wayne Trail.

Here's a short highlight reel.

The trail is an old electric train railroad. It crosses some very high bridges that thankfully have had a platform and dirt added to them.

The trail is doable on a touring bike (my ride) or a cyclocross bike (Robert's ride).We road almost until the tunnel but had to turn back since we were running into ice at the higher elevation.

Sunday, December 28, 2014

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

Thursday, December 11, 2014

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.

Thursday, October 16, 2014

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.

Friday, October 10, 2014

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.