Kanban to Focus Product Development

My experimental Kanban board

Started an experiment with Kanban to see what my board would look like. I split the board into four vertical sections: Idea, Spec, Dev, and Test. The latter three sections were split into the typical “TODO”, “Doing”, and “Done”. I did not really know what to expect except to find plenty of items in the TODO list, which was the case!

The “Idea” section was split into “Concept” and “Research”. The latter included items that are being currently researched as candidates for being added to the product. The “Concept” sub-section, on the other hand, was a bag of raw ideas that have been tossed around over the past few months, either by development, business people, or customers. What I learned from this section was interesting.

The bag of ideas in the “Concept” sub-section contained quite a large number of what seemed to be sizable projects. Looking further into these items I found that they are quite disparate and the unifying theme is not at all clear. This helped me realize that I needed to focus our product development efforts quite a bit. In trying to pick which of these items should be included and which should be deferred or rejected, I realized that the problem is at a higher level; the business level. We have been struggling for quite a while to precisely formulate our marketing message and deciding the exact customer segment to target. This reflected clearly on my board.

My first experiment with Kanban was pretty useful, and fun too!

Google Place Picker in React Native

I was facing some issues in my React Native project and was trying a few solutions. One of things that I tried was upgrading to the latest package. Even though it was a simple upgrade from 0.39 to 0.40 it turned out to be problematic. The header file organization of RN changed which require manual updates to some of the Objective-C source. After failing to fix the problem with manual update (not sure why), I decided it was easier to re-create the project from scratch using RN 0.40. After all, I should not need to do more than copy my source JavaScript files over to the new project, right? It turns out that I had forgotten about a few manual steps I had to perform in the process of setting up the project.

First, a few of the npm modules required linking. I was glad I had already documented this in a previous post.

Next, was dealing with requirements of the Google Places Picker module. Luckily, they have documentation. However, I recalled from my initial experience with the module there were some steps that were missing from the docs. Going back to my original notes, the missing steps had to do with enabling the API in the Google console, which you have to do only once (note that you have to enable more than one API).

So back to applying the steps in the docs, I needed to set up CocoaPods. The first time I set it up I got some warning about unused pods and compilation failed. It turns out that the sample pod config file provided in the docs is of an obsolete format. The file needed to look like this:

target 'places' do

  target 'placesTests' do
     inherit! :search_paths
  end

end

# react-native-google-place-picker dependencies

pod 'GooglePlacePicker', '= 2.0.1'
pod 'GooglePlaces', '= 2.0.1'
pod 'GoogleMaps', '= 2.0.1'

Once fixed, the ‘unused’ error was gone, but then I ran into linking errors of the type:

Undefined symbols for architecture x86_64

This required some searching. A line needed to be added to the Podfile that instructs CocoaPods to use an Objective-C framework, instead of plain libraries. Adding the line:

use_frameworks!

inside the ‘target’ in the Podfile fixed the problem.

Finally, I was now ready to copy my JavaScript files and get back the project to a valid state. So much for an upgrade from 0.39 to 0.40!