Skip to main content


James Cameron and Startup Founders

After listening to Arnold Schwarzenegger's audiobook "Total Recall", there's a chapter that goes into an amazing story of how incredibly ambitious James Cameron's vision of Terminator was. As a film director, James Cameron was extremely technical (he could make highly experienced lighting technicians feel like it was their first time doing lighting), knew all the equipment like the back of his hand, had a huge vision for the film, and ensured that everyone on the team had the vision crystallized in their minds. Incidentally, he could tell when there was too much lighting in one scene and took the small details very seriously.

He was a control freak. Naturally, I would assume that he had the same controlling approach to Avatar and Titanic, both largely successful box office hits.

Everyone loved working with James Cameron because he knew how to challenge his team. He knew how to set out and paint a grand vision -- and he definitely knew how to make it a reality. T…
Recent posts

After School Programs Should Include Hackathons

Thinking back to my days in high school, learning to program in C++ using Dev-C++ by Bloodshed Software was so fun. From writing my first hello world program to writing Mad Libs (a program that lets you substitute adjectives or nouns in parts of a pre-written story) -- I had the most fantastic times. At that time, Yahoo Groups and IRC channels were on the rise. I remember logging on to FreeNode and going into the #programming channel asking about compiler errors. I actually still do the same thing; however, there are many more IRC channels including #ruby, #javascript, #golang, #java, and #php.

Looking back at it now, I spent most of my time learning how to program alone. I think that if I was in a group setting where people could come together and build programs that solved real problems, everyone would benefit -- especially at the high school age. Presently, these are called hackathons and I think that with The Social Network film, hackathons are becoming more mainstream. It is cul…

Installing Titanium CLI 3.2.x Problems? Stuck on 3.1.2 GA?

I'm truly amazed at how much fantastic work that the Appcelerator team has been doing with Titanium and Alloy. That said, I wanted to share a little story of mine with having to try to upgrade to the latest version of the Titanium CLI.

One day, I was wanting to upgrade an existing mobile project and I wanted to make use of the new features like the Pull To Refresh widget that landed in Titanium v3.2.x. I thought it looked amazing as soon as I saw it. So, the first thing I did was "sudo npm install -g titanium@3.2.2". Everything looked great! Until...
> titanium -v 3.1.2.GA
Oh man. That didn't work. The tricky thing here is that they have an SDK version, a CLI version, as well as, a Studio version. One thing to note is that it's easy to install the SDK and CLI from Titanium Studio but I figure since they've made the CLI, they're wanting developers to move away from large IDEs and use text editors like Atom, Sublime Text, TextMate or even Vim or Emacs.

Why did World of Warcraft fall out of eSports?

I remember staying up late to watch IEM European World of Warcraft streams on my second monitor whenever my favourite team would play (Button Bashers). The most famous of them all was Orangemarmalade -- One of the best mages I've ever seen to play World of Warcraft. His partners were Numberone (Discipline Priest) and DKer or Hyren (another incredibly top tier rogue from Korea).

As we look at eSports today, the most watched games are League of Legends, DotA 2, and Starcraft 2. World of Warcraft used to be in that list but what made it fall off? Some of the core aspects I've come to think of are watchability, game patches, as well as, game design balance.

Spectator mode for World of Warcraft was great for anyone that actually played arena, understood the deeper mechanics that go on in high level arena games (2200 rating+), as well as, recognized clutch plays like spell stealing hand of sacrifice, faking casts, vanishing blinds, vanishing cheapshots, intervening fre…

Using Git Hooks: Prepare Commit Message to automatically prepend branch names on commit messages

When you're practicing branch by feature with distributed version control, typically you'll get assigned a ticket or issue and that ends up being your feature branch. Instead of always typing in the branch name in every commit, you can edit your Git hooks (specifically prepare-commit-msg).

Assuming that this is a brand new git repository:

mv .git/hooks/prepare-commit-msg.sample .git/hooks/prepare-commit-msg
vi .git/hooks/prepare-commit-msg

Edit the file by commenting out what was originally in the file and then add this:

Now, whenever you make a commit, it should show up like this in the log:

Since GitHub and Bitbucket both support Emojis inside commit messages, you can do something cute like this

Want more emojis? check out the Emoji Mardown Cheatsheet!

Continuous Delivery with Titanium, TestFlight, Jenkins, and Nomad

As an advocate for continuous delivery, building native mobile applications has always been a common problem faced for developers wanting to move fast, build something, measure the results and evolve their application. Incidentally, AppStores don't really provide an easy way of following lean entrepreneurship (ship fast, build, measure, learn). Things are getting better so I've decided to blog about our experience with continuous delivery with TestFlight, Jenkins, Nomad, and Titanium.

Some of the key benefits of continuous delivery include
- Being able to avoid large integration (merging) issues when feature branches have diverged extensively from what is on production. Smaller changes going into production frequently are a lot easier to resolve (fix or rollback).
- Deployment procedures can be tricky depending on the platform and the technologies you use -- automate everything so that you don't miss any steps within your deployment procedure
- Smaller changes going into …

Engineering at Borentra

Built into the very DNA of Borentra is the essence of moving fast, failing fast, and evolving quickly. As the BORG would say -- "we adapt". From an engineering perspective, our tooling isn't complex at all -- we do our best to keep things lean and fast -- just so that we can quickly respond to customer feedback. That said, we are ever so focused on providing the best customer experience in the social space. Furthermore, in order to achieve these goals, we always need the latest tools that will allow us to ship faster and respond to the amazing feedback from our users. For source code hosting, we use GitHub and we've adopted the GitHub Flow which basically means master is always deployable and we use feature branches when working on bug fixes, enhancements, or user feedback. Once a feature is ready to be deployed to production we send a pull request and if the code is good to go (code review and tests pass) we merge it into master. Once the merge happens, we have Jen…