SourceLair Blog

  • Possible downtime due to critical Xen hypervisor vulnerabilities

    The past couple of days, several critical vulnerabilities in Xen hypervisors have been announced. The vulnerabilities can be found here, but are not yet disclosed for security reasons.

    Due to these vulnerabilities, our infrastructure providers have scheduled maintenance windows next Thursday March 5th between 4:00 AM and 8:00 AM UTC, where the hypervisors' datacenters that host our servers will reboot. We have created several fallbacks in order to keep the service up most of the time of these reboots, but there might be times that critical infrastructure goes down and the service will not be available.

    We will do our best to keep interruptions to the minimum. Stay safe and be awesome.

  • We are increasing RAM to 512MB for everyone

    In SourceLair we are doing our best in order to remove any friction from the software development process.

    One of the most usual occasions of friction in software development is an unresponsive and laggy development environment, thus we decided to increase the default available RAM from 128MB to 512MB for everyone. This combined with our top-tier SSD drives and blazing-fast user interface lets our users code anywhere within a browser, without even noticing they depend on an internet connection.

    512MB RAM for everyone

    No extra action is being needed from your part. All SourceLair projects have been updated automatically to utilize 512MB of RAM.

    Go now to sourcelair.com and enjoy even faster development anytime, inside your browser.

  • Trying out Django 1.8 in less than 60 seconds

    Less than a week ago Django 1.8 Beta got released to the public. We are really excited to announce official support of Django 1.8 Beta in SourceLair.

    Why Django 1.8

    Django 1.8 is the next LTS release of Django. This means that it will receive official support for at least 3 years after its day of release.

    Also, Django 1.8 comes a long with a great set of new features, like the Model._meta API, the support for multiple template engines and the new security enhancements.

    So let's take a closer look at these new features in just a few seconds.

    Setting up a Django 1.8 project

    The first thing we have to do is start a new Django 1.8 Beta project. Doing so on your local machine or on a remote server, requires using venv or a similar technology, in order not to mess up other Django projects that you host on the same machine.

    In SourceLair we are taking away all this hassle from you. Open up the "Start a new Project" dialog, choose "Django" as the project type and then choose "1.8 (Beta)" as the Django version of your project.

    Django 1.8 project on SourceLair

    Press the "Create project" button and you are all set up; you have a new Django 1.8 Beta project available.

    Django and further Beta releases

    Django lives in the heart of SourceLair; the majority of our code base is written in Django and we wouldn't be able to deliver high-quality software in such pace, without the strong foundation of such a framework.

    For this reason, starting today we commit in supporting every Django beta release officially in SourceLair within 24 hours from its official release, in order to make it easier for everyone to test it and thus improve the overall quality of the final release.

    Don't wait any longer, go to sourcelair.com, try the new Django 1.8 out and let us know what you think!

  • Faster and smarter save

    Working with a slow internet connection can be very frustrating. And with our previous file-saving procedure, working on large files in SourceLair was sometimes a pain. Given a large enough file and a slow enough connection, the required time to save a file could easily get out of hand and the workflow disruption was too big to ignore.

    And our goal here at SourceLair is to remove any possible strain from your workflow. So after identifying the problem we searched for the best possible way to solve it.

    Saving files faster

    Problem

    Everytime you save a tab, the whole file is sent over the network to our servers and overwrites the previous contents of the file.

    Obviously, by increasing the size of the file you are working on, the request data gets bigger and bigger and the bottleneck of the network becomes evident. There are cases where saving a huge file could take up to 30 secs and of course this is unacceptable.

    Searching for a solution

    Transfering 100KB everytime you make a small change of 100 bytes costs time and network traffic. Since, most of the time, the changes are just a fraction of the actual file, why don't we just send the changes? So our goal was to find out that fraction of the file that changed, send it as a patch and apply it on the actual file on the server.

    To avoid reinventing the wheel, for both calculating the patches in the front end and applying them in the back end, we utilized Neil Freiser's google-diff-match-patch. This dramatically reduced the data size sent for a save request. Reducing the data lead to decreasing the response time.

    Result

    To showcase the speed improvement, we run a simple benchmark. The following graph shows the average response time for saving a file in regard to its size. Three different cases were run:

    • Saving a file like we used to
    • Saving a 1000 line change with patching
    • Saving a 100 line change with patching

    (for the patching cases, the time for the calculation of the patches is included in the response time) save_benchmark

    It is obvious that with our previous implementation there is a linear relationship between the file size and the response time. With the new implementation, response time is bound only to the size of the changes and is no more dependent on the file's size. An average save now is reduced to just 150-200ms no matter the size.

    So now we've seen how save became a lot faster! Time to find out why it's smarter as well.

    Saving files smarter

    With the introduction of live file system you can rest assured that any changes in your files are reflected in your filesystem and your editor. There are some cases though in which the file you are working on gets outdated. Lets say for example that you go home after work and you open your home computer and you still have SourceLair on. Due to the lack of internet connection, any changes made in the meantime did not update your IDE. This could lead to you editing and saving an old version of your file, overwriting any precious progress you made at work.

    To avoid this, from now on, everytime you save your file, we check that the version you are editing and are trying to save is indeed the latest one. In case it isn't, you'll be notified and will be able to either force save your version, or load the latest version from the server. Version conflict

    With the introduction of these two new features, saving files in SourceLair is both faster and smarter.

    Go to www.sourcelair.com and start coding frictionlessly!

  • Introducing live file system

    Today we are very happy to release live syncronization for SourceLair's filesystem.

    Any change made in the actual filesystem is reflected in the UI in real time. Furthermore, any open file that has its contents modified, gets automatically updated to avoid finding yourself editing an outdated file. File update

    This removes any hassle from some cases like the following:

    • Running programs and scripts that change your file system (e.g. if you create new output files) has immediate effect in the UI. Live fs create file

    • Using Git or Mercurial commands from the console, correctly updates all the repo details in the UI.

    • Checking out to another branch, results to a fast update of every file changed individually instead of a total refresh.

    Go to www.sourcelair.com and watch as your filesystem updates in real time like it's local.