Updating pull request branch with changes from upstream in GitHub

I don’t know if it’s the most efficient way but here’s one way of dealing with updating a pull request from a personal branch after upstream/master has been updated.

I update my origin/master:

git checkout master

git fetch upstream

git merge upstream/master

I switch to my local branch:

git checkout local-branch-name

“Pop” the PR commit back into unstaged:

git reset HEAD^

This will remove the last commit (I usually rebase all my PR commits into one before submitting a PR but you can also specify HEAD~x where x is the number of commits you want to pop back out) and put it back into unstaged.

And then try to merge master into the branch:

git merge master local-branch-name

If it merges cleanly I can proceed with a commit. If it can’t merge cleanly, I stash the unstaged changes, I merge and then pop the stash likewise:

git stash

git merge master local-branch-name

git stash pop

And then take care of the merge conflicts manually. You will get info on which files are in conflict by doing:

git status

After all of this I can commit and push the branch to GitHub which will update the pull request.


Developer portfolio

I decided to create a development portfolio. Similar to what designers and front-end engineers have but related to development in general.

I’ve put in stuff I’ve done outside of work (because for work stuff either I can’t or I would have to go through a lot of red tape to get permissions). Since this is new for me I wasn’t sure exactly what to add and will probably refine it in the following weeks.

As a side note, the header picture is one I took myself in a recent two day hike in the Northern Presidential range in New-Hampshire.

Link: dev-folio

Google Play Store rating/recommendation system is broken and how to fix it

The Google Play store has an app rating/recommendation system. When you are on the main screen of the store it will show you an app you have installed and ask you to rate it using a star rating (no need to type in a textual review) so that it can recommend you other applications.

I used to be eager to fill these in, hoping it would find some gem that would suit my tastes. Sadly, I now realize the mechanism is fundamentally broken.

Here are two recent experiences I’ve had with this feature:

In the first case I had installed two weather applications on my phone. I tried both and didn’t like them. For one of these I wrote a negative review. I removed both and installed a third one. After a couple of days Google asked me to rate this new app. I gave it a four star rating. Google Play then prompted me to try some more weather apps.

This scenario has me, the user, searching for a specific kind of application and settling on one I like. My search for such an application has ended in a satisfactory way. Signaling my satisfaction shouldn’t prompt Google Play to suggest more alternatives.

In another case, the Play Store asked me to rate the to-do list app I have been using for the past few months. Since I really like it I also give it a strong rating.

Again the Play Store suggested more to-do list apps to install. A to-do list app is really something you only need one of.

How to fix it

The solution for this problem is to look at the type of app or product that is being rated. Is it a game, a widget, a productivity app, a book, a magazine?

Each of these broad categories could then be assigned a value indicating whether a good rating from the user would preclude the recommendation of similar apps or promote it.

So if I give a good rating, say 4 or 5 stars, to a weather widget the recommendation system would not suggest me another app with the same functionality.

On the other hand, if I give a poor rating to such an app, I would want Google Play to suggest some highly rated and popular alternative. I took the time to install and try out a particular type of app and clearly I’m not satisfied by it. Chances are I’ll be interested to find a better one.

Similarly, if I give a good rating to a sci-fi book or action movie it should offer more of the same. Movies, books, magazines and certain types of apps should continue to work the way they do now.

The system could be further expended to classify different types of apps or products. Rather than bunch all non-gaming apps in the same category it could be further improved by using the existing sub categories and even making finer distinctions amongst these existing sub categories.

It should also drill down further by using collected user data.

Do users of this app install similar apps in the same sub category after rating positively or not? This information could be collected (it probably already is) and then used to calculate the value of whether to preclude or promote similar results on a positive review.

This modification would make the current system much more useable.

Rust: enums

Rust 0.10

Enums in Rust behave like you would expect in most C based languages. You can also implement methods on enum types. Both instance and “type” methods.

You declare these methods in the same way that you declare methods on a struct, using the impl keyword followed by the enum’s name.

Here is an example of an enum with a constructor-like method and two instance methods.

Compiling and running this program would output the following result:


Now let’s try something a little bit more complex. The following is a enum type I wrote for an actual application. To get more familiar with Rust, I am porting my height map generator that I used for my Ruby game project.

The following enum generates random coordinates for a particle drop point (the algorithm I use for generating the map is the particle deposition algorithm). The formula to calculate the coordinates varies depending on how many times we have called it.

Here is the enum type:

And here is how it’s called:

Contrary to the first example, when I change the state of the enum I return a new instance instead of mutating the current one.