Yuval Adam

Feature-squash-rebase Flow

I have a new favorite flow in git. I call it feature-squash-rebase. It’s used for taking a feature branch, and applying all it’s changes in one commit onto the master HEAD.

It goes something like this. First, branch out for the new feature:

git checkout -b feature

Hack away. Commit frequently. Once you’re done, return to master:

git checkout master

Now the magic begins. First, merge the feature branch onto master by using the squash flag, this will meld all the commits into one giant commit:

git merge --squash feature

Now you can review the huge diff, and commit when ready:

git commit -m "new feature"

And once you got that down, reapply your commit onto the master HEAD by using pull with the rebase flag:

git pull --rebase

That’s it. Push your changes to the rest of the team.

git push

This flow is not necessary, but it keeps the history super-clean. I don’t use this for heavy features that I want to keep track of. But for short stuff, this flow is a keeper.

Installing JPype on Mac OS X

By default, the JPype installation on Mac OS X will fail with a GCC error.

In order to successfully install it, some changes need to be made to the setup.py file:

  1. First, make sure you have some JDK (latest, preferred) installed
  2. Copy the root path of the latest JDK version you want to use (for example: /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/)
  3. Edit the setup.py file, like so:

In function setupMacOSX(), set:

self.javaHome = '/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/'


self.libraryDir = [self.javaHome + "/Libraries"]

In function setupInclusion(), set:

self.javaHome + "/Headers",


self.javaHome + "/Headers/" + self.jdkInclude,

Now you can run the install successfully. Enjoy.

Lion users - check out http://stackoverflow.com/questions/8525193/cannot-install-jpype-on-osx-lion-to-use-with-neo4j

Two-Week Facebook Hiatus

I’ve had it.

My Facebook news feed had become a collection of random shit I could not care less about. The 5% of news that I am interested in is not worth the constant infusing of worthless garbage into my brain. Stuff that is important to me will find its way to me in real life.

As of tomorrow, I will be deactivating my Facebook account for a period of two weeks. The Facebook icon on my bookmark bar will be deleted, as will be all Facebook history items in my browser.

After two weeks, I’ll re-evaluate what all of this means.

Foaming at the Mouth

“…social-network systems are very good at introducing us to people we already know, letting us communicate very well ‘in our own little online dialect with our friends of our friends in a tightly knit bundle’, but not at ‘stretching’ our ability to meet new people.”

Out of context, that sounds exactly like what I was talking about at Startup Weekend 2011. But those aren’t my words. This is a quote from Tim Berners- Lee, the guy who fucking invented the World Wide Web. Coming from him, this reassures my assertion that something is wrong with what the web has today.

“'How do we build the web so that every now and then it introduces us to people who are not friends of friends?‘ he wondered, calling for people to 'make use of the web so it connects people together… and breaks down barriers more than it builds them up.’"

When I think of the perfect WWW - this is what I have in mind.

Git Rebasing

Lately, I’ve been working on honing my git skills. With a recent migration from SVN to git, those skills have become more important as I am the guy to solve any problems in the team.

One issue that I’ve been looking at is the use of git rebase. If you’re not familiar with rebase, basically it is a command that allows you to detach one or more commits from their position in the commit tree and replay them onto the current HEAD. This allows for cleaner commits, and subsequently, cleaner commit trees. Git ready has become my favorite git resource, and it has a wonderful post on how to pull with rebase.

Of course, there is a downside to rebasing - over time, you will lose branching information; depending on the context, this is information that might be useful.

I’m still evaluating whether this is a process one would want to implement across an entire team, considering ease (or difficulty) of use, compatibility and history information.

I haven’t forgot my promise, a writeup re: a successful branching model for an agile web startup.

Google Code Jam

Google Code Jam 2011 is coming up, and registration has just opened. I’ve started practicing for it this week - you can find all my code on github, as usual - and already reached two major conclusions.

First off, I’m in GCJ for the fun - yet another reason to stay up late and hack into the night. Being realistic though, GCJ is a professional programming competition. The top coders are world-class hackers which train for these competitions year round (HN had a nice thread on the subject). It’s always important to know what your goal is - and my first aim is to successfully complete all 3 problems in the qualification round. After that, I’ll reevaluate my strategy towards Round 1.

Second, if I’m in it for the fun, maybe try out a new language? Python is my go-to language for anything of this nature. When I need to hack up something quickly, Python is a no-brainer. I also find much of Python’s constructs very helpful in solving competitive programming problems: features like list comprehensions, regular expressions, native (arbitrarily-long) big integers and generator functions are all used frequently. However, I’ve been toying with Clojure for a while now, and I might use GCJ as a platform to work on my Clojure skills.

In any case - it’s going to be tons of fun. So do yourself a favor and sign up.

Tails of Lions

There’s an old saying in Hebrew (taken from Pirkei Avot) which loosely translates to “Be a tail to the lions, and not a head to the wolves”. I hate to go against sayings of old wise people, but judging by Techonomy3 which took place today, this is precisely what the Israeli entrepreneurial community should not be doing.

Techonomy today saw the launch of 6 new Israeli startups, all from the web/mobile persuasion: Dapsem, Magisto, Tingiz, TvTak, Jumboard and HitPad.

The cynical TL;DR; for said startups goes something like this:

  • Dapsem - centralized dissemination of Facebook “likes” and positive feedback tweets - fist bump style. A thumb-less “like” - if you will.
  • Magisto - kick-ass, intelligent video editing. Smart algorithm that churns hours of raw video footage into short, concise clips with scene highlights.
  • Tingiz - a QR code community allowing retailers to build product pages and communities around products.
  • TvTak - contextualizing televised content by image recognition - take a picture of current commercial with iPhone and get context.
  • Jumboard - an online gaming platform for toddlers, with matching hardware.
  • HitPad - a tweet/news/media aggregator; Flipboard clone.

Magisto took first place, no surprises. They zoned in on a real problem, and from the looks of the demo - developed a real algorithm that gets the job done. Regarding the other 5 startups, well… Positive feedback was aplenty - not only from the crowd via live tweets, but also from the judges, which concentrated on generic appraisals - “Good product, would love to see it succeed”. Really?

Are any of the other 5 startups innovative in any way? Do they bring any added value? Do they differentiate from competition in any palpable way? The teams are all staffed with very talented people, some with prove track records to show for. This is an anomaly I cannot yet explain, other than the fact that Israeli VC money is dirt cheap these days.

The vast majority of Israeli startups are trying to vaguely imitate and loosely build upon existing web platforms in ways that are not innovative nor sustainable. Israeli entrepreneurs are historically known for out-of-the-box and innovative thinking. It is a shame if we ignore our advantages and instead try to imitate existing products.

I fear that if indeed there is an inevitable downfall to the current saturated state we are in (the proverbial “bubble”, anyone?), Israeli startups will take a massive hit. I believe Techonomy3 has shown we have lots to improve on, and unless we start asking the hard questions that focus on product differentiation and revenue - Israeli web startups will find themselves with rainy days ahead.

Why We're Switching to Git

TL;DR; Subversion is rapidly becoming an obsolete tool that hampers fast iterations and lean development.

Much has been said about the different version control systems (VCSs) out there, and since a VCS is such a standard tool in a developers toolbox, the debate around the different systems is subject to personal taste, and can easily drift to flame wars. I’ll try to describe, as objectively as possible, why SVN wasn’t good for us, and why we’re switching to git.

Subversion has always been our version control system, in my current startup. When setting up an intial SCM environment, choosing SVN is a no-brainer. It is, arguably, the most easiest VCS to set up, and it has an extremely moderate learning curve. The tools available for SVN (namely, TortoiseSVN) have helped make it the default choice for any new software project.

However, we’ve reached the conclusion that SVN is not suited to support our development processes. The core development team consists of 7 developers with nearly orthogonal responsibilities, for most cases. This means that developing new features usually encompasses more than one developer. The only place devs can collaborate is on a mutual branch. Not only that, but just like most web startups, we iterate fast. We need the ability to be agile.

Additionally, we take testing very seriously, and all new features must be thoroughly tested on staging servers before being pushed to production. So basically we’d want the flow to go something like this: create new branch for feature, hack-hack-hack, switch staging server to branch for testing, merge into trunk and push to production.

Unfortunately, from our experience, we’ve always had issues with branching and merging in SVN, to the point that we try to avoid doing them in the first place, at all costs. This lead to devs working directly on the trunk, pushing features to production that haven’t been tested thoroughly.

Empirically speaking, we’ve had two major gripes with SVN that derive from the fact that SVN does not track commit history as well as other systems. The first symptom we’ve experienced is very coarse conflicts. This can be shown very easily in the following scenario: consider a file with two lines on two branches, one with “1 2” and one with “1 3”. Clearly the first line is common (even if they branched out at the same time, that the file had only this one line!) , but SVN will not recognize this, and consider the entire block as a conflict. This expands to very coarse, very nasty, conflict blocks which optimally could be much more specific.

The second scenario we were able to reproduce was updating the branch from trunk before merging back into it. If not done properly, with manual noting of revisions (pre SVN 1.5), SVN will have no notion of branch updates. For example, pulling from trunk to branch will result in conflicts - cool, no problem. But if not done carefully, merging the branch back into the trunk will result in the exact same conflicts that need resolving once again! Again, not to say that proper merging is not possible in SVN, but this process was extremely tedious, and prone to human errs.

Also, since branching is not intuitive in SVN, we avoided creating a separate branch for proper integration - which means that final integration was always done on the trunk. This meant that while integration was being tested on the staging severs, developers could not push new changes to the trunk - effectively halting development for periods extending up to hours a day.

So it was clear our processes are flawed, but why choose git? True, many of the modern DVCS, such as mercurial and bazaar, support proper branching/merging. But git is the tool most of us have had experience with. Basically, the entire migration process is relatively easy from the technical standpoint. The main risk in switching to git is having each dev learn the new flows, and get used to them - and from that perspective, git was the logical choice.

Important to note that we do not really care about the distributed nature of git. We look at git as a toolbox that allows us to implement any version control flows that we want.

In following posts I’ll describe how we plan to use git in a semi-centralized manner, including a branching model that fits an agile web startup.