Thursday, March 27, 2014


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. That said, when it comes to his films, it is his way or the highway. I can understand this since he wrote the scripts, pitched to studios, and got the funding necessary to make it happen. In one particular case, Arnold Schwarzenegger absolutely hated the line "I'll be back" -- it sounded too girly for a killer robot. James Cameron wrote the script as, "I'll be back" but Arnold Schwarzenegger wanted to remove the contraction by saying, "I will be back" -- it seemed more in line with what a robot would say. In the heated situation, James Cameron ended the argument by saying, "Look, I don't tell you how to act and you don't tell me how to write. Just say the damn line."

Terminator went on to be a box office hit -- one of the most legendary films ever made in history and the line "I'll be back" became the most popular phrase in movie history. The thing about James Cameron was his intuition. He knew deep down what would be amazing for the people to see and what people want to see on the big screen.

Relating to startup founders, I think that a lot of highly successful startup founders have the same approach to achieving big goals including Jeff Bezos (Amazon), Bill Gates (Microsoft), Steve Jobs (Apple), and Thomas Watson (IBM). They had the ability to see into the future, paint a grand vision, share that vision with the team and challenge the team to make it a reality.

After School Programs

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 culturally accepted for a bunch of passionate people to hack together a mobile app and share it with the world -- even if it is just a Twitter clone because in the end, you find a team you can truly ship projects with. The big picture we're trying to achieve is making the movement of learning together, building software together, and shipping solutions to customers. That said, in The Social Network film, I don't condone the binge drinking / bro-culture; however, I do encourage people coming together and solving a real world problem as one cohesive unit.

After school programs are amazing because they keep kids off the streets (most crimes are committed between 2pm and 6pm depending on the city). Most after school programs are fitness-related. Incidentally, I spent most of my after school time playing Badminton and working out in the gym instead of causing trouble on the streets; however, I did sometimes find myself stuck in the computer lab hacking away at this thing called "HTML".

It is truly fantastic to see automated drones, fully electric cars, smart hardware in homes, as well as, people being truly mobile and socially connected with their Google Glasses/smart phones. Positively, we need to start thinking about how to encourage the next generation so we can accelerate growth and change in our economy.

Monday, March 24, 2014

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


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.

The eventual fix that I ended up going with is just removing "/usr/local/share/npm/bin/" from my PATH. This ensured that when you're invoking "titanium" or "ti", you're using the correct one from npm. Good times! Keep calm and mobile on!

Wednesday, March 19, 2014

[2014] 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 freezing traps or spell reflecting deep freeze. 

The average eSports watcher wouldn't catch on to these amazing plays from professional players because the view of the matches didn't show that brilliance. Seeing top tier Frost Mages put out an incredible amount of crowd control and do damage at the same time was always exciting to me. Watchers of the tournaments would end up seeing a Rogue perspective where they are jumping up and down, stunning the other rogue, while the other players were running around the screen. It was just too messy for anyone to really get into. 

If we look at hockey, it's very easy to see how breakaways can be exciting, the camera zooms in, the sports commentators start yelling with excitement in regards to an opportunity of scoring a goal, as well as, the crowd jumping on their feet. 

Inconsistent Patch Dates

Every time there would be a tournament, Blizzard would release a new patch for World of Warcraft which included game balancing updates that had huge impacts on PvP. Sometimes, they would actually change around shared diminishing returns, like polymorph with hex. This basically made it so that Shamans couldn't play with Mages because of an overlap of crowd control categories. When teams practice together, they usually create a bunch of characters with the class they are strongest with, level up to max level, and gear them out. The thing is, this rigorous process actually ends up happening in a patch for a few months up until MLG or IEM. Eventually, a week before the tournament, a major update to their classes could end up weakening their composition to the point that it doesn't become competitive -- so they have to hustle and take on new classes just to try to take advantage over the new balancing changes. This was tough on the players -- imagine having to practice 16 hours a day doing arena with your team composition (rogue/mage/priest) and have an update decrease your mage's damage output and decrease your discipline priest's healing output.

Class Balance

Being a competitive professional player means you're willing to play whatever with the highest effectiveness (classes, gearing, specs) and exploit whatever to win (including arena queue dodging). In this case, there was a time in WoW's arena history where all top teams across all battlegrounds would play RMP (Rogue Mange Priest) because of its inherent strengths of non-overlapping crowd control. 

Sap, polymorph, fear bomb, counter-spell, blind, cheap shot, gouge, kidney shot, deep freeze, and ring of frost. Adding to that, discipline priests were one of the most aggressive healers that could put out a lot of damage whenever they needed to get a kill. This usually included power infusion + holy fire + smite. It was truly amazing to see the most aggressive discipline priests like Hydra and Bilian play.

It was truly difficult for any top 3s team to defeat RMP except in one particular patch which buffed beast mastery hunters and enhance shamans. This paved the way for the legendary "Beast Cleave" 3s composition. Only 3 days after the patch, all the top arena rankings on all battlegrounds had Beast Mastery Hunter, Holy Paladin, Enhance Shaman. The forums were flooded with "please fix burst damage on enhance shamans and beast mastery hunters" -- Every arena match you would hear Blood Lust (ARARRGHGHH), the spirit wolves would come out and the Beast Mastery Hunter would pop BM -- and your mage would be dead in a global before he could even Ice Block. Incidentally, one could say most of the patches that came out were really to address PvE issues -- to help diversify raid compositions (bring in more enhance shamans instead of stacking rogues or fury warriors as DPS). Blizzard did a great job of addressing these issues and I agree with them for taking the right approach -- to focus on the larger set of users on World of Warcraft -- which happened to be the raiders.

The eventuality of World of Warcraft in eSports

With MLG, IEM, and ESL dropping support for World of Warcraft around 2010 due to game balance issues, inconsistent patch times, and watchability issues -- naturally, PvP became less popular with World of Warcraft's user-base. Looking at the lessons learned, in order to make a game truly eSports friendly, there are two core aspects that really make it enjoyable for audiences: watchability (how easy is it to understand what is going on) and game balance. Naturally, MOBAs like League of Legends, DotA, and soon Heroes of the Swarm are easy to watch and I definitely see these games growing in viewership in these games in the coming years.

The future of competitive gaming is dependent on the viewership and the competitive spirit behind eSports. Riot Games has done a fantastic job of making League of Legends what it is today -- the most popular eSports game in history (although, you could say Starcraft was pretty big too). Ultimately, I'm sure we'll be seeing a lot from Blizzard Entertainment when Heroes of the Storm launches, as well as, the launch of Hearthstone on mobile devices.

Tuesday, March 4, 2014

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!

Friday, February 28, 2014

Continuous Delivery with Titanium, TestFlight, Jenkins, and Nomad

Continuous Deployment for TestFlight, Jenkins, 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 production are easier to code review, it won't take up too much of an engineer's time

The Tools

- Titanium (being a JavaScript developer, it was easier for me to write in one language and generate iOS and Android applications for a minimum viable product).
- Jenkins (running Jasmine tests via NodeJS on any controllers, responds to webhooks when master changes, and pushes iOS binaries to TestFlight API)
- Nomad (Ruby-based tool which lets you generate iOS binaries)
- TestFlight (a platform for automating beta testing specifically iOS apps, getting user feedback, and getting crash reports/device diagnostics)

The Pipeline

- When developing a feature, branch off of master `(master) git checkout -b FEATURE-XYZ`
- Write the feature, pull in master, freely push to your feature branch and Jenkins will continue to run tests on your feature branch
- When a feature has been completed, use nomad to generate the IPA, commit the generated binaries depending if your Jenkins server is Mac OS X or not, submit a pull request to master, have it code reviewed.
- When the feature branch gets merged into master, we have a webhook that fires and Jenkins takes it off of master, runs tests, then ships the binaries to TestFlight via the TestFlight Jenkins Plugin
- This will automatically email all your beta users or specific groups of beta users (you can customize this list) to install that version that was just merged into master

Lessons Learned

- When you invite new beta users, don't forget to update your Mobile Provision Profile prior to merging into master by adding the new device identification numbers -- this will make it so that when they get emailed to install a new version of your app, they won't get a rejection error.
- The installation experience for beta users whether they are technical or not is absolutely amazing.
- If you ship to production 50+ times a day, your beta users may get a lot of email spam for installing specific builds.
- You won't need to commit the IPA to source code if your Jenkins box is Mac OS X (our Jenkins box is a Windows box since the platform runs CI on .NET code)

Wednesday, February 26, 2014

Engineering at Borentra

Software Automation and Pipeline... I wish software looked like this!

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 Jenkins listening for a webhook payload which basically means master needs to be tested on our CI server (Jenkins) and deployed to production (Azure).

A very lean process lets us ship fast. One of the first things we put in place was continuous deployment to Azure without even having a database! With a deployment pipeline in place, we are able to rely on so much automation to get from zero code to a feature on production within a short time span. As mentioned above, we are fully deployed on Windows Azure. We currently use Blobs, CDN, Azure Websites, SQL Azure for our web stack and then we have a few sprinkles of NodeJS and Neo4j for lookup services (Quick Add widget) that encapsulate power tools, trending books, Halloween costumes, Xbox360 games, PS3 games, Magic The Gathering cards, and Pokemon cards.

The last 4 months have been hectic but putting an upfront engineering investment for a deployment pipeline has been absolutely vital. Without speed and efficiency, you can't respond to solving problems that your target users are having — as an early stage startup, our biggest advantage is that we can quickly evolve the product so that we can continue to focus on increasing user engagement, as well as, user growth.

Have questions about what it's like to be in engineering at Borentra? feel free to tweet us on Twitter or mention us on our Facebook wall!

Sign up for Borentra today!