Enabling CORS in Angular JS

I was recently experimenting with building an API with django-tastypie and make it accessible via CORS, so it can be used from a different host from an AngularJS app.

For the Django part it was relatively straightforward. I could have either written my own Middleware, dealing with incoming CORS requests, but decided to use django-cors-headers in the end. Following the instructions in the github repo and adding my host where AngularJS is hosted to the CORS_ORIGIN_WHITELIST setting did enable the Django server to handle CORS.

With AngularJS it was a little more tricky, mainly because information is spread all over the web. Beside the fact that I was trying to implement a service using ngResource to communicate with the API, the following did enable AngularJS to send its requests with the appropriate CORS headers globally for the whole app:

var myApp = angular.module('myApp', [
    'myAppApiService']);

myApp.config(['$httpProvider', function($httpProvider) {
        $httpProvider.defaults.useXDomain = true;
        delete $httpProvider.defaults.headers.common['X-Requested-With'];
    }
]);

_

Just setting useXDomain to true is not enough. AJAX request are also send with the X-Requested-With header, which indicate them as being AJAX. Removing the header is necessary, so the server is not rejecting the incoming request.

16 Comment(s)

Migrating to Heroku

To cut some personal costs and simply because I was interested in it, I recently moved this blog to Heroku, the popular cloud hosting platform.

Since 2011 Heroku officially supports Python deployments. Running on a single dyno it is even for free. Following the official guide to deploy a Django application, the transition from my VPS to Heroku was pretty straight-forward and easy. Additionally Heroku enforces good practices, like using virtualenv, and supports more and more popular technologies, like the Python WSGI server Gunicorn.

Following a short general guide of what had to be done from my side to do the transition:

  • Create a fixture file from your database via the dumpdata command.
  • Since I didn't want to add any billing information to Heroku yet, I had to rewrite everything related to sending emails from my web server, to save the incoming contact request in the database instead. That was pretty much just the creation of a new model and a one-liner to save it to the DB instead of sending an email,
  • Already using virtualenv, the rest was simply adding or changing requirements. In addition of removing the MySQL bindings for python I added the following libaries:

    dj-database-url==0.2.1
    django-heroku-memcacheify==0.4
    django-pylibmc-sasl==0.2.4
    gevent==0.13.8
    greenlet==0.4.0
    gunicorn==0.17.2
    psycopg2==2.4.6
    pylibmc==1.2.3
    

  • Static files are served via Django directly for the time being, since a Web-Dyno using Python can not serve them the normal way. I will move them to be served by a solution like Amazon S3 in the future. Therefore I added the following to my urlconf:

    urlpatterns += patterns(
        '',
        url(r'^media/(?P.*)$', 'django.views.static.serve', {'document_root': settings.STATIC_ROOT}),
    )
    

  • Running the dyno via Gunicorn with gevent support was a single line in the Procfile:

    web: gunicorn -k gevent wsgi:application

  • Finally:

    git push heroku master

So far I am quite happy with Heroku. I didn't recognize any differences to previous VPS hosting and I don't have to deal with server maintenance anymore, even it was an experience I don't want to miss. Goodbye VPS, welcome Heroku!

7 Comment(s)

Ubuntu's Unity is not so bad ...

... as many people say.

This is at least my experience. Around two weeks ago Canonical released their latest Ubuntu 12.10 "Quantal Quetzal", another of Canonical's half-year scheduled Ubuntu upgrades. Since 11.04 Unity represents Ubuntu's main desktop UI.

When Unity was released I somehow didn't like it first. It was, after all, a big step away from the Gnome 2 interface, which I was used to. One of the main features suddenly missing was customizable panel's. Also the Dash was something to get used to, since the well structured main menu was gone as well. Easy to adapt for me was the left-sided launcher though.

Since I didn't want to abandon Ubuntu to this time there there were only two choices to go with: Using the classic Gnome 2 for a while or adapt Unity. I decided to do the later, simply because I thought (and that is what happened) Unity will be a long-time support by Canonical. There were also things I liked right away out of the box:

  • the global menu and integrated window controls with the "top panel"
  • the launcher
  • the dash, after I got used to it


Something I didn't like at the very beginning (11.04 & 11.10):

  • Unity was extremely unstable, especially in Ubuntu 11.04 it crashed frequently for me
  • the Dash was quite buggy, sometimes apps disappeared from it and only a restart "fixed" it (throughout 11.10)
  • the lack of decent multi-screen support
  • Unity was slow, sometimes doing something in the OS took more time than I was used to


This got all fixed in Ubuntu 12.04 LTS! Since then I am a very happy Unity user. I didn't had any issues anymore and I feel I am way faster working with it than I was with Gnome 2. Sure, I still can not customize my panels, but the simplicity of Unity is worth it.

Recently I was trying Xubuntu for a while as well. I have seen some screenshots which reminded me of Gnome 2 and I wanted to give it a try, so I installed it beside the ubuntu-desktop. I switched back to Unity relatively fast. There were just too many things I had to configure in Xubuntu first to match my requirements, for example that Ctrl+Alt+T is opening a terminal, the dock (adding a launcher there is quite some hassle) or other shortcuts I was used to from Unity or even Gnome 2. Even after configuring everything I still felt way slower to work with. Sure, Xubuntu's main advantage is that it can run on slower machines and it has more configuration options, but for that I don't need it. For me Unity is ready to work with right after installation even it needs some tiny tweaks here and there.

So for everyone who didn't like Unity because it was too unstable before, now is the time to give it a try.

0 Comment(s)

Vim for the win

Around a month ago I started to use Wim as my primary code editing environment / text editor (I wouldn't call it in IDE).

After the kind of steep learning curve during the first two weeks and around two more weeks coding with it in around the same speed as in my old IDE, I think I got faster with it now. The most used commands became somehow part of my muscle memory, for some commands I still find myself sitting in from of my keyboard and thinking "What was that again?". Thanks to one of my colleagues I got to know a bunch of common plugins and tweaked my config.

Though I must say: it was a hard journey. When I started and especially after deactivating the arrow keys (to use hjkl instead), I often felt the urge to move back to what I am used to. Luckily I forced myself into it. Now "ciw" is my best friend and I even use ":w" in other editors or environments. :)

0 Comment(s)

Learn something new: AngularJS

I recently discovered AnguarJS after a post about it on the Google Developers Blog.

After going through the tutorial and watching a couple screen casts I am quite impressed. You can literally build a functional web app in just a few lines of code. The data-binding feature is great. Say goodbye to custom cycles from your html to JavaScript and back to populate the data in your page.

Using AngularJS does not mean you have to get rid of JQuery and other tools you are used to develop with (especially because JQuery has so many great plugins). It integrates nicely with AngularJS.

The only thing which bugged me was that Angular is using the same curly braces for template variables/tags as Django does. Luckily there already is a solution for this.

I definitively plan to use Angular for upcoming projects.

0 Comment(s)