#sourcelair

SourceLair is an online IDE that lets you code in Python, Django, HTML5, JavaScript, Ruby, Node in your browser, while it integrates with Git and other tools.

Developers all around the world, despite their differences, usually share interest for specific fields of the technology world. Bitcoin is one of those fields that has attracted a great amount of developers the last years, which actually grows constantly and almost exponentially.

Today we are excited to announce Bitcoin support for upgrading to sourceLair Pro. We have been watching its growth and continuously increased adoption for a long time, so we decided that letting our users use their Bitcoins to upgrade their sourceLair accounts would be all but a bad investment. Giving as much flexibility as possible to our users, so as to improve their experience, while using sourceLair, is a top priority for us and the way of paying for sourceLair is not an exception for that.

sourceLair is based on open source software both for its development process and for its production infrastructure. We strongly believe in giving back to the open source community and that is why today we are revealing a project we have been working on lately that we think is going to change the way code is being run on the cloud.

We are thrilled to announce OpenDevelop; an open-source platform that lets you run your code with a single HTTP request. OpenDevelop lets developers easily run any piece of code inside secure, isolated sandboxes, while it can distribute the load in a transparent way for the developer. OpenDevelop has been designed so as to totally replace sourceLair's backend for running any piece of code and we are really happy for having an open source software, designed by us, to back our service. Additionally we aim in having an OpenDevelop instance available to the public, in the beginning of 2014, which is going to be completely free and exclusively for non-commercial use, so as to let developers around the world take advantage of this state-of-the-art technology.

An ancient proverb says that starting is half the battle. We believe strongly in that proverb; today sourceLair makes the progress of starting a new Django project dramatically easier and faster.

After logging in to sourceLair, all you need to do is click on the arrow on the top left corner of the File Explorer, then click Start a new project and then select Django as your project type. Now after clicking on Create project you will get a new project under version control, with a Django project created, according to the name you gave, as well as a public URL to access your app and evaluate your work. Starting a new Django project never was that fast and easy.

We have been waiting for this moment for a long time. Ever since we started working on sourceLair, we have envisioned it as a professional service that could allow people to develop software as they should; hassle-free, on a reliable, efficient and elegant environment. Today, we are taking our biggest leap towards achieving this goal, by getting out of Beta phase, releasing sourceLair Pro while improving the whole service at the same time.

Up until now, users on sourceLair could work only on 1 project per account. This changes today, by introducing sourceLair Pro, which enables you to work on up to 10 projects on sourceLair for just $8 per month. From now on, you can work on most of your codebase on the cloud, without having to transfer your files or anything at all.

In addition to sourceLair Pro , we are really happy to announce some more great updates to our platform. Starting today, the server of your Django project gets spawned up to 80% faster than it normally would. Also, we made radical changes to our infrastructure that hosts your Django projects, which makes our platform more reliable.

Mercurial or Git? Many developers have to chose one of these two great Source Control Managers, the differences of which may be really obscure, but they may be also critical to the development process of software.

In the first weeks of the existence of sourceLair, we quickly found out that SVN wasn't working for us. So, we had to choose a Distributed Version Control System and we were between Git and Mercurial.

After a first failed attempt with Git, I started using Mercurial (as a non-experienced developer using almost exclusively Windows), because of it being easier to use with SVN in mind. More than a year later, while I was already familiar with UNIX, Mercurial, Git and SSH instead of HTTP for clone/pull/push, when I thought about replacing Mercurial with Git for the development of sourceLair, the answer was fast and explicit; no. The main three reasons behind this decision are explained below.

Sanity

This is the main win of Mercurial over Git for me. While both of them were built, almost at the same time, to solve the same problem, for me it seems like Git was built with performance in mind, while Mercurial was built with the human user in mind. Even the relative consistence, between server and client, that is imposed by Mercurial makes more sense to me, personally, for Source Control Management. Finally, the monolithic approach of Mercurial to itself makes more sense to me as a unified solid system aiming to solve a specific problem, compared to the 140+ different executables that compose Git, each one of those targets an individual problem.

History is history

In Mercurial history is immutable. For me that translates to safety, since I am sure than no matter how many times I will do hg push -f, nothing is going to get lost, ever. In Git it is almost frequent seeing people changing the history of their repo by deleting commits, rebasing and stuff. This is some kind of freedom for sure, but there underlies the danger of doing the wrong thing the wrong time and wishing that this never happened. Humans are supposed to do mistakes, and I think the great thing with Mercurial is that gives you the freedom to do as many mistakes as you want, without endangering the future of your code.

Branching system

Well here is another great win; in Mercurial branches are branches, they are not pointers. The branch of each commit, resides and will reside forever in the commit's metadata, no matter if you are merging or not, or if you add more commits in the branch, or even if you are closing the branch. This adds more semantics to your commits and make them branch-aware, something that consequently leads to having a consistent, organized and semantic code repository. If you 'd like though a branch in the same logic than the one of Git, you can chose Mercurial bookmarks, which work pretty much in the same way.

Obviously though, the two big wins of Git are its performance and community and this probably is not going to change in the immediate future.

Of course the selection of a Source Control Manager is something really personal, so there can be no general rule about that. So, this is not article trying to prove that Mercurial is better than Git. It is an article showcasing why Mercurial fit my personal needs compared to Git, when it comes to managing a code repository.