Photo Rollup from Japan Trip

I recently took a 3 week trip to Japan. We made it just in time for the cherry blossoms in Yokohama and Tokyo. I wanted to share a few of my favorite photos from the trip.

Sakura

Sakura in Shonandai

Sakaegawa Flowers

Tulip off Sakae-gawa

Zen

Steps to Zen

Steps in leading to Zen in Engaku-ji. Natsume Soseki and others of note used these steps in the early 1900′s when going to practice.

Labeling Ourselves for Others

When looking for conversation a common question that people ask is “What do you do?”. I have two answers. If I’m talking with other developers, I tell them I am a software consultant and then quickly qualify what kind of development I generally do: backend, mac, iOS, and frontend (because you have to). When the person is non-technical, I leave out the qualifying statements.

More and more I’m coming to the opinion that these qualifying statements are a hindrance more than they are helpful.

I was chatting with a friend recently. He’s newer to software development in general and he mostly does frontend work. He’s told me in the past that he wants to build a site using Ruby and Rails. Then one day he came to me and asked me about Python.

Curious as why the sudden change of heart, I asked him why he was asking about Python.

He responded, “I’ve been infatuated with rails for a while but don’t have the guts to actually dive into making something. Not sure why I’m so afraid!”

This was a curious response. What chatted a bit more when the root of the problem surfaced.

“I think that’s where I’m getting terrified since I consider myself a front end developer”

We all look for tribes to join and my friend was no different. He labeled himself and began building his identify as a frontend developer. Embracing this label made the gumption to start learning new techniques and technologies outside of the label almost insurmountable.

I was only a Mac developer until the iPhone. And I was only a Mac/iPhone developer until I needed systems to power these applications.

People like to be surrounded by people that are like themselves. This makes us eager to find a way to label ourselves so we too, can fit in. This is true on both a personal and professional level and is why bankers like other bankers, programmers hang out with other programmers, and married people tend to hang out with other married people.

What we don’t realize is the unsaid danger of believing our own bullshit: these labels can easily engrain themselves as part of your identity and unless you regularly cull the labels you give yourself, they will limit you.

Apply these labels to yourself when they’re to your advantage and when you begin feeling constrained by them, let them go.

As for me, I’m James, and I like to solve problems. Often this involves software.

How to Mimic UIPopOverView on iPhone

If you try to use a UIPopoverView on your iPhone, your app is going to crash. I wrote a simple header view for UITableView that when combined with some controller magic can allow you to mimic the functionality and allow for a full-screen menu drop down without messing with navigation.

There are 3 different components required to make this UI work: a UITableViewController (your menu controller), SSPopupHeaderView, a custom UIStoryboardSegue.

Design and build your menu view as you normally would in Interface Builder. Modify your menu controller to set SSPopupHeaderView as the tableHeaderView and prevent the UINavigationBar from drawing any shadows.

#import "SSPopupHeaderView.h"

- (void)viewDidLoad
{
    [super viewDidLoad];

    SSPopupHeaderView *headerView = [SSPopupHeaderView new];
	/* This color should match our UINavigationBar's color in the menu */
    headerView.topColor = [UIColor blueColor];
    headerView.borderColor = self.tableView.separatorColor;
    headerView.bottomColor = self.tableView.backgroundColor;

	/* Setting the menu button will let us center our line from the middle of it */
    headerView.barButtonItem = self.menuButton;
    self.tableView.tableHeaderView = headerView;
}

-(void)viewWillAppear:(BOOL)animated {

    [super viewWillAppear:animated];

    //Prevent the shadow of our UINavigationBar from drawing
    [self.navigationController.navigationBar setBackgroundImage:[UIImage new] forBarMetrics:UIBarMetricsDefault];
    self.navigationController.navigationBar.shadowImage = [UIImage new];
    self.navigationItem.hidesBackButton = YES;
}

The next step is to connect your menu button in your application to your Menu controller. The default segues installed in iOS all have an animation and would ruin the illusion we are aim for. To keep our illusion, we need to remove animation from the segue and we can do this by creating a simple subclass UIStoryboardSegue that performs the animation without animation.

#import <UIKit/UIKit.h>

@interface PushNoAnimationSegue : UIStoryboardSegue
@end

@implementation PushNoAnimationSegue

-(void) perform{
    [[[self sourceViewController] navigationController] pushViewController:[self   destinationViewController] animated:NO];
}

@end

The menu is a simple UITableView, we want to push from our menu view to the selected view. However, if we simply push the view, when the users hits the back button, it will bring them back to the menu – as it’s in the hierarchy.

We want our users start on screen A, top the menu button and have it appear, select a new destination to screen B and if they back from screen B, it should pop directly to screen A – skipping the menu.

We can achieve this by modifying our view hierarchy directly after we push screen B onto the stack.

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
	//your code to select the correct view to push onto the stack and push it onto the stack
 	NSMutableArray *viewHeirarchy =[[NSMutableArray alloc] initWithArray:[self.navigationController viewControllers]];
	[viewHeirarchy removeObject:self];
	self.navigationController.viewControllers = viewHeirarchy;
}

And in 3 simple steps – we can mimic a UIPopOverView on the iPhone to provide navigation on iOS. I’ve released the header view as open source (MIT licensed) so you’re free to use it in your own applications free of charge.

SSPopupHeaderView on BitBucket

2013 AppStore Year in Review

2013 has been a good year. I finally incorporated Sugoi Software, LLC – after 10 years of just using the name. Since we are officially a business now, I thought I’d share our revenue statistics from the AppStore portion of the business.

We had one new product introduction, Foodgram and one update to ImageXY bringing it to version 3.

##Foodgram
Foodgram is an iOS application I wrote to help me keep track of what I’m eating without filling my Camera Roll up with pictures of food. While I was not expecting to retire off the sales – it’s almost paid for the iPod Touch I bought to help test it. As the application was released in the beginning of August – it’s only been on sale for less than 5 full months.

*Total: $171*

##ImageXY
ImageXY continues to be the best seller for Sugoi Software. The application received a 3.0 release in August and I gave a presentation on it at TechBreakfast in Austin in September.

*Total: $5,633*

##Jisho
Jisho was the first application that I released as “shareware” and is the oldest of our applications. Sales were a bit lower this year than expected.

*Total: $850*

##Jisho Touch
Jisho’s iOS counterpart. While the application still performs excellent, the look and feel is dated and needs an update with iOS 7.

*Total: $441*

##Pubtunes
Pubtunes is in complete maintenance mode and is almost paying for the developer membership.
*Total: $70

##Quimbers
Quimbers started as a fun math game and an experiment with the freemium with in app purchase model. We decided to pull it from the AppStore completely due to a lack of sales.

*Total: $3*

**Total Revenue: $7,116 USD**

For the total amount of effort put into each of these products this year, I am overall happy with the results. In the coming year I plan to expand our offerings into the SaaS B2B space with products like Federated Links.

Keeping Production and Testing Separate by Preprocessing Your Info.plist on iOS

When building an application for iOS or OS X that integrates with a web service, it’s often handy to be able to use different servers depending on the environment. The usual case is I want to use this testing server while in development and all of my customers to use a different, production server.

One solution is to create some defines in your source code like below:

	//Constants.h
	#ifdef DEVELOPMENT
	#define ROOT_URL @"http://test.myapi.example.com"
	#else
	#define ROOT_URL @"http://myapi.example.com"
	#endif

That solution certainly works. However it doesn’t feel as clean to me as it encourages tiger coupling of your API code with your application code. A cleaner solution is to embed the URL into your Info.plist file. A naive approach might be to simply add two entries, one for development and one for production such as follows:

	MyAPITestRootURL
	http://test.myapi.example.com
	MyAPIRootURL
	http://myapi.example.com

There’s a few problems with the above. 1) You’re exposing your test server urls to end users, which is just asking for trouble and 2) You still need to test in code which key to use.

The best solution that I’ve found is a combination of two solutions above. Use the C pre-processor in our Info.plist. Using the solution below works great, though you will no longer be able to use Xcode’s built in plist editor. The Info.plist is invalid until it gets processed by the C pre-processor. Simple ctrl-click on the Info.plist file and click Open As -> Source Code. This will expose the raw XML.

	MyAPIRootURL
    #ifdef DEVELOPMENT
	http://test.myapi.example.com
    #else
	http://myapi.example.com
    #endif

You can then access this URL by the following:

NSDictionary *infoDict = [[NSBundle mainBundle] infoDict];
NString *url = [infoDict valueForKey:@"MyAPIRootURL"];

I like to add a define constant for the MyAPIRootURL, to reduce the likelihood of a type-o making difficult to find bugs.

Before you can use this, you must tell Xcode to preprocess your Info.plist file. Open your build settings and make them look something similar to the following:

Info Plist

Notice the Other preprocessor flags – the “-traditional” is important. Without this flag, the pre-processor will interpret the // in http:// as a C-style comment and read the line as http:, which is invalid. The -traditional flag only interprets /**/ C-style comments as comments, thus preventing the URL from mangling your XML.

#Conclusion
Using the C pre-processor in your Info.plist can allow you to cleanly separate development and production settings while encouraging a looser coupling between API frameworks and application code.