Github down, so what?


Did you see all these tweets complaining about Github problems these days? And all these (low level) articles on tech blogs/websites? Here are some examples which made my laugh:

Github a été victime de pannes à répétition, privant les très nombreux utilisateurs d’accès à leurs sources

Source: http://www.lemagit.fr/article/developpement-open-source/11789/1/github-victime-pannes-repetition/

Which means that « developers did not have access to their sources ». Really? Developers already have their sources locally if they are working on them!

Github going down is no small thing, developers which acts as a central repository for much of the open-source code that runs our world.

Source: http://iwgcr.org/github-down-twice-in-two-day/

Agree, it is not a « small thing » but are we speaking about a git-based system i.e. the so funky decentralized distributed version control system?! If github is down you can, at least, still continue committing things locally (Do you remember when you were using SVN?). Right?

If you still need to push your sources and share them with your dev team: git is decentralized i.e. you can change the remote repository to a temporary google code, bitbucket, wtfgitrepohostingsystem.com repository and come back later on github. RTFM: ‘git help remote’

Do you still need more to work? Come on developers!

Notify me when someone forks me


All is cool in Github and the API really rocks! I created several tools around it and especially QuickHub, an OS X app to quickly access to your Github space and be notified when something changes.

Last night, I was thinking about creating something which can notify you when someone forks or start watching your repositories even if you are offline. So I had a look to the Repository Hook API and just found that almost all the hooks are targeting push ie you can use tens of connector to be notified on the system of your choice only when a push occurs on your repository. Let’s have a look to the event API but this is not a really good idea, I already use it in QuickHub to notify about activities and it’s just about polling for changes.
So what? Hopefully, there is one alternative: The pubsubhubbub API. According to the GitHub documentation, one can subscribe to any event type using this API. You just have to tell which one on which repository and give it a callback. Giving it a callback is just what we want: Having something which runs online and which can receive events and notify me even if I am offline… Here we go for some Web development with the PlayFramework and Heroku for hosting, here is mygithubnotifier.

mygithubnotifier uses the GitHub Java API from Eclipse. Even if JSON is easy to parse, having it already done is faster. The application retrieves all your personal repositories and provides the user the choice to subscribe/unsubscribe using the pubsubhubbub protocol. This protocol is really simple to use: One endpoint and three parameters are enough. If I want to subscribe to forks on my repository, I just need an authenticated HTTP call like to https://api.github.com/hub with some parameters for defining the topic (repository), the mode (subscribe/unsubscribe), the event type (fork, watch, …) and the callback URL which will be some REST endpoint exposed by the Play application. The application will send an email every time someone forks one of your repository if you subscribed to this event before.

The code is really simple and will not be detailed here. You can get it from GitHub at chamerling/mygithubnotifier. I assume that deploying the Play application to Heroku is as easy as described in their documentation. You just have to configure the application by specifying the right email and GitHub properties as described in the README.md.

Get QuickHubApp GitHub OS X client for free


Apple 12 days of Christmas are over and it is my turn to give some copies of QuickHubApp GitHub OS X client for free.

In order to get a promo code, you have to Tweet something like:

Have a look to http://wp.me/pcSx0-nn to get a free copy of QuickHubApp @github OS X client (cc @chamerling)

or something more creative which contains ‘QuickHubApp’, ‘http://quickhubapp.com’, and ‘@chamerling’.

To receive the promo code, you also have to comment this article with the reference to your tweet. Put your email address in the form so I can mail you the code directly within the next days. First ten comments will get a free version.

Simple HeartBeat Manager with Play


One more time, one more tiny (and maybe useful in some cases…) application with Play!.

WTF, my server is dead again!?

This app is a simple heartbeat manager looking at remote HTTP services and notifying you by email when something becomes unreachable. It uses the background Job feature of the Play framework and just does HTTP GETs on the specified list. That’s all, that’s simple, but that’s can be useful sometimes…

The code is located at https://github.com/chamerling/heartbeat-manager

OAuth and Desktop Apps


I started to develop QuickHub some weeks ago by focusing on features and without taking into account security issues such as this critical information which are login and password credentials… As mentioned in the GitHub developer pages, I started to use Basic Auth for all the requests QuickHub does to get retrieve data from GitHub. I started to think about moving to OAuth when a user said me that he bought QuickHub but that he did not use it because of Basic Auth. He was afraid that I can rob its credentials and so have a look to its repositories and more. I totally understand this argument and so I started to think that it limits QuickHub adoption by developers and that I should do something.

So, I discussed with GitHub guys through their support channel (Here I want to say that I am really impressed on how fast and professional is the GitHub support team!). Of course, they also told me that they will never use QuickHub if OAuth is not provided. After discussions with the guys, I started to implement a workaround to provide OAuth support in QuickHub by using the OAuth Web flow and adding some stuff to QuickHub.

Let’s see how we can do that in a generic way so that you can use it in your app if needed since every serious Internet service also provide OAuth support… Note that I will not give many details about OAuth itself but I will use some terms, so have a look to OAuth documentation for more details.

Register a Web application

The first step is to register your application to the developer portal. Here you need to provide some information such as the app name and its callback URL. Even if we are developing a desktop app and not a Web one, we need to be able to provide this HTTP based callback URL. We will see in the next section what is inside this application. By registering our application, the service will generate and give us some keys to be used in the next steps, mostly to recognize us when calling the service.

Create a Web application

We need a Web application to handle callback calls from the service we want to use OAuth. This application will only be used at authorization time and just have to be able to receive the service call, get the code sent by the service, then call the service again with the code and our application keys (there is a secret one to be used here). As a result, the service will send you back your OAuth token to be used in all the future service calls. This token is used to authenticate your service calls, no more password stuff inside! Here is a quick sequence diagram showing all the exchanges between actors…

On the QuickHub side, I chose to create this Web application by using the Play Framework I already mentioned several times in this blog. I used the Heroku paas to provide the Web application publicly.

As showed in this Gist (https://gist.github.com/1466592), the callback method is really simple (as usual with Play!): just get the code and call GitHub with it and your application keys. When all lis done, just display a result page with a specific URL. Here it starts with ‘quickhubapp://oauth?’. Let’s see what it means in the next section…

Add custom URL handlers to your desktop app

Once the desktop application is authorized, our Web application redirects the user to a Web page which embeds a button targeting an URL starting by ‘quickhubapp://oauth?’. Here you already understand that by clicking on such a link must drive you to something special. The cocoa framework allows developers to register specific URL handlers for their applications. So we need to register QuickHub handlers so that OS X knows that every link  with the quickhubapp scheme must me routed to QuickHub. This is as easy as showed in this Gist https://gist.github.com/1466628.

This code snippet just tells QuickHub to invoke the getUrl method when it receives a quickhubapp event. Up to the getUrl method to handle things. In QuickHub, I just extract the OAuth token in order to persist it locally for future use.

Done!

So now we are able to use OAuth Web flows for desktop applications. In the best of the worlds, every service provider may provide a real desktop flow to be used without the need to create this additional web application. In the real world, it is not the case but as you see it can be bypassed quite easily.

I will provide more technical details on the second section ‘Create a Web application’ with real sample and code in the next weeks.