Linux

Installing Python 3 and Django on Dreamhost

Posted on by Matt Woodward

I’m working on a side project for a friend that has zero budget and since I’m already paying for Dreamhost (my favorite and only choice for shared hosting) and totally underusing it, I figured I’d use this project as my opportunity to figure out how to install Python 3 and Django since A) Dreamhost lets you do install things even on their shared platform (one of the reasons I love them!), and B) the default Python on Dreamhost is Python 2.7.3.

1. Install Python 3.5.1

This part’s really simple and Dreamhost even documents it nicely on their knowledge base, but for the sake of one-stop shopping I’ll include the steps I performed here. Note that I’m leaving the default Python 2.7.3 in place since I’m not sure what havoc it would wreak to blow it away, so Python 3.5.1 will be installed in such a way that it’ll be run as python3. (For the curious, you can also read more about Python at Dreamhost in general.)

Before going any further, if you haven’t enabled SSH access for your Dreamhost user you need to do that first since if you can’t log in you can’t install anything.

  1. Log into the Dreamhost web panel
  2. Click on “Users” and then “Manage Users”
  3. Find the relevant user and click the edit button
  4. Under “User Type” choose “Shell user,” and I’d recommend also choosing /bin/bash as the shell type
  5. Scroll to the bottom of the page and click “Save Changes”

Next, we’ll install Python 3.5.1.

  1. Go to https://www.python.org/downloads/release/python-351/ and get the URL for the gzipped source tarball.
  2. SSH into your Dreamhost server
  3. In your user’s home directory, wget the tgz file using the URL you grabbed in step 1:
    wget https://www.python.org/ftp/python/3.5.1/Python-3.5.1.tgz
  4. Extract the Python source:
    tar xvf Python-3.5.1.tgz
  5. cd into the extracted source directory:
    cd Python-3.5.1
  6. Configure Python 3.5.1 with a prefix flag so as not to stomp on anything that’s already installed:
    ./configure –prefix=$HOME/opt/python-3.5.1
  7. Run make and make install:
    make && make install
  8. Add the new Python installation to your path:
    export PATH=$HOME/opt/python-3.5.1/bin:$PATH
  9. Update your bash profile:
    . ~/.bash_profile
  10. Verify that everything’s working (this should output Python 3.5.1):
    python3 -V
If that all looks good at this point, we’re ready to proceed and create a virtualenv in which we’ll install Django.

2. Create a virtualenv

Python 3 ships with pyvenv, but since it works a bit differently than virtualenv which is what I’m used to using, I decided to install virtualenv and use that. Feel free to use pyenv here if that floats your boat.
  1. Use pip3 to install virtualenv:
    pip3 install virtualenv
  2. Create and/or cd into the directory in which you want to put your virtualenv. I tend to put mine in ~/.virtualenvs, so I did this:
    mkdir ~/.virtualenvs
    cd ~/.virtualenvs
  3. Create a virtualenv to use for our Django project (since we installed virtualenv with pip3 the default Python environment will be Python 3.5.1):
    virtualenv my_django_project
  4. Activate your virtualenv:
    source my_django_project/bin/activate
  5. Confirm everything looks correct at this point (this should output /path/to/virtualenv/bin/python3):
    which python3
If we’re still on track we can proceed to install Django.

3. Install Django (and your other requirements)

At this point since we have Python 3.5.1 installed and have successfully created a virtualenv, we can do the usual installation of requirements using pip3, which typically will come from a requirements.txt file. For the sake of illustration we’ll go through installing Django into our virtualenv and making sure it works, but pip3 install -r requirements.txt will be the more typical way of installing all the packages you need.
  1. With your virtualenv activated, install Django:
    pip3 install django
  2. Verify everything is working by starting a Python interpreter:
    python3
  3. Import Django to make sure it’s in your virtualenv (this shouldn’t throw any errors):
    >>> import django
Now that we have verified that our virtualenv is working and sane, we can proceed to the rest of the configuration to get a Django project running successfully in this environment on Dreamhost.

4. Enable Passenger on Your Web Site

Rather than the gunicorn or some of the other WSGI servers you may be familiar with, on Dreamhost you can use either Passenger or FastCGI as the application server for Django applications.

For this post I’ll be using Passenger, a tool with which I was not familiar until I saw information about it on Dreamhost. Passenger is apparently more common in Ruby on Rails setups, but it serves the same purpose and falls in the same place in the stack as any of the other WSGI tools with which you may have experience. You can read more about Dreamhost’s use of Passenger here and here.

Some Notes About Passenger

Worthy to note about using Passenger on Dreamhost is that once Passenger is enabled, all requests that come into your domain will be handed off to Passenger by Apache. Passenger will first look see if there are any files matching the request in your domain’s /public directory (and note that the files must be in the /public directory or subdirectories under /public specifically), and if it can’t find an appropriate file, Passenger then tries to handle the request itself.

To provide a couple of concrete examples, let’s assume you have a file called hello.html in your domain’s /public directory, and a request comes in for http://yourdomain.com/hello.html. Here’s what happens next:

  1. Apache hands the request off to Passenger immediately. This is important to note since Apache is out of the picture entirely other than serving as a proxy to Passenger.
  2. Passenger looks for a file called hello.html in your domain’s /public directory. Since it finds one, it returns that page to the requester.
Now let’s assume a request comes in for http://yourdomain.com/some/django/url. Here’s what happens in that case:
  1. Apache hands the request off to Passenger.
  2. Passenger looks for an appropriate file in /public. This time it doesn’t find one.
  3. Passenger then attempts to handle the request itself, and since later we’ll be configuring Passenger to serve up our Django application using WSGI, at this point Django would be processing the request.

Enable Passenger

In order to run a Django application on Dreamhost we’ll need to enable Passenger on the domain on which we’re going to run our Django application.

  1. Log into the Dreamhost web panel
  2. Click “Domains” and then click “Manage Domains”
  3. Locate the domain on which you’ll be hosting your Django application and click “Edit”
  4. Scroll down and under “Web Options” you’ll see a checkbox labeled “Passenger (Ruby/NodeJS/Python apps only).” Check that box.
  5. Scroll to the bottom of the page and click “Change Settings.”
That’s it for enabling Passenger. Next we’ll throw our Django application at Dreamhost and see what sticks.

5. Create a Django App

For the purposes of this post we’ll be creating and configuring a Django application directly on the Dreamhost server. Obviously if you have an application that’s already written that you want to run on Dreamhost you’d be uploading your application’s files as opposed to doing things from scratch on the server, but this should illustrate some of the nuances of what you need to do with your own Django application to get it running on Dreamhost with Passenger.

  1. ssh into the Dreamhost server
  2. Activate the virtualenv you created above:
    source ~/.virtualenvs/my_django_project/bin/activate
  3. cd into the root directory of the web site on which you’ll be running your Django application. Note that this is not the aforementioned /public directory under your web site’s directory, but the root of the web site itself.
  4. Start a new Django project using django-admin.py:
    python3 django-admin.py startproject my_django_project
  5. Do a quick gut check by firing up the Django development server:
    cd my_django_project
    python3 manage.py runserver
At this point you should see the Django development server start up without any errors. We’re nearly there! The last step is to configure this newly created Django application to work with Passenger. But before we do that, a quick note about static files.

Serving Static Files and the Static Root Setting

It wouldn’t be Django if we didn’t have to stop and say a word about serving static files. Luckily this isn’t anything out of the ordinary, but given how Passenger works you do need to be aware of how to set your STATIC_ROOT to make sure everything comes together smoothly.

  1. Create a static directory under your domain’s public directory, i.e. you’ll wind up with ~/yourdomain.com/public/static
  2. Go into your Django project’s settings file and add a STATIC_ROOT setting:
    STATIC_ROOT = os.path.dirname(BASE_DIR) + ‘/public/static/’
With that you should be all set to run collectstatic and have everything work properly. Now let’s move on to configuring Passenger.

6. Configure Passenger

In order to have Passenger load up our Django application, we need to create a passenger_wsgi.py file in the root of our domain. As with all WSGI files this is what tells the application server, in this case Passenger, how to load up the application so it can handle requests.

In the root of your domain, create a passenger_wsgi.py file with the following contents:

With that file in place, you should be able to hit http://yourdomain.com and see the default “Congratulations” Django page. Congratulations indeed! You now have a Django application running on Python 3.5.1 on Dreamhost.

A common error you might run into is something like “no module named foo” or “no module named foo.settings.” If you get something along these lines it means your paths are incorrect, so make sure that your Django project is in a directory directly inside your domain’s root, not in the /public directory. If that isn’t the issue, double-check all the paths in the passenger_wsgi.py file.

Additional Passenger Considerations

It’s worth noting that if you change your passenger_wsgi.py file you need to run pkill python to reload the Django application since Passenger loads your application into memory (which is one of its advertised advantages since it makes things pretty zippy).

I also saw note of having to run touch tmp/restart.txt but in my experience I didn’t have to do that, so I’m not sure if that’s more of a Rails thing or if I simply didn’t yet run into situations in which that was necessary. I’m noting it here in the event pkill python doesn’t do the trick.

Final Notes

There you have it. You now have the latest Python and Django running on Dreamhost. At this point you can load your own Django project, set up a database (note that Dreamhost only supports MySQL, and even though I much prefer Postgres, MySQL works just fine), and do all the usual Django stuff.

Enjoy!

Downloading from eMusic on Linux

Posted on by Matt Woodward

eMusic is an excellent, long-standing digital music store and one I’ve been a member of for years, but to say they aren’t friendly to GNU/Linux would be putting it mildly. They used to have an official (in permanent beta, but still) download manager but they’ve since done away with it so there is no official way to download music from eMusic on GNU/Linux.

Since I do some other audio/voiceover stuff on Windows it wasn’t a huge deal for me to suck it up and download from eMusic on Windows, but that has since stopped working for no apparent reason. I click download, the download manager pops up, and nothing happens. Perhaps not coincidentally this is precisely the time the Google Music Manager stopped working as well, and also when my Windows Media Center PC stopped downloading guide data. Methinks a Windows patch of some sort borked all this stuff in one fell swoop but I’d rather not be using Windows anyway so I took it as a wake-up call.

Thankfully there’s an unofficial, Java-based eMusic download manager called eMusic/J and though it used to work without any additional configuration in the past, due to recent-ish changes in how eMusic does their downloads it had quit working for me too. Today I finally had a few minutes to dig into the situation and get it figured out.

Turns out what you have to do is trick emusic into think you installed the official eMusic Download Manager even though you didn’t, at which point you can download the .emx files eMusic uses to tell the Download Manager what to download, and those .emx files can be used by eMusic/J to do the downloads.

Here’s the big secret on how to tell eMusic that you installed the Download Manager. You ready?

Go to this URL in the browser on GNU/Linux where you want to use eMusic/J:
http://www.emusic.com/dlm/install/

Congratulations! You just fake installed the Download Manager. Now when you go to download music from eMusic you’ll be asked what you want to do with the .emx file, and you can simply either download it or tell your browser to use eMusic/J to open those files.

Seriously eMusic, I love you guys but forcing people to use a Download Manager that apparently breaks at the drop of a hat when a Windows update is issued is pretty crappy. Luckily using this trick eMusic/J works … for now at least.

How To Create a PyCharm Launcher on Ubuntu 12.10

Posted on by Matt Woodward

I’m absolutely loving using PyCharm for my Python and Django development, but one of the lingering things I’ve been meaning to nail down once and for all is creating a launcher for PyCharm in Ubuntu 12.10. Despite the automated way you can attempt to do this from within PyCharm itself and all the other recommendations I’ve read I was unable to get it working.

In the mean time I also bought of copy of IntelliJ IDEA when they had some crazy back to school sale a couple of months ago (I still dabble in Groovy and Grails a bit). I was having the same issues with creating a launcher for IDEA and the typical tricks I use for Eclipse weren’t working, but luckily I came across this post that explains how to do it. The only change I made is pointing to idea64.vmoptions instead of just idea.vmoptions — other than that it works great.
That got me thinking — since PyCharm and IDEA are both made by JetBrains, and both run on Java, chances are how they work is pretty darn similar. So I decided to copy the IDEA launcher script and modify it for PyCharm, and lo and behold it worked!
Here’s my modified version of the IDEA launcher that works for PyCharm.
#!/bin/bash

export JAVA_HOME=/opt/java/jdk1.7.0_09
export JDK_HOME=/opt/java/jdk1.7.0_09

export PYCHARM_HOME=/home/mwoodward/pycharm-2.6.2

export PYCHARM_VM_OPTIONS=”$PYCHARM_HOME/bin/pycharm64.vmoptions”
export PYCHARM_PROPERTIES=”$PYCHARM_HOME/bin/idea.properties”

cd “$PYCHARM_HOME/bin”
export LIBXCB_ALLOW_SLOPPY_LOCK=1

./pycharm.sh
Obviously adjust all the paths as necessary for your machine. Make sure you chmod +x on the file, and with that in place you can open up Main Menu (sudo apt-get install alacarte if you don’t already have it installed) and add a launcher. For reference the icon lives in PyCharm’s bin directory.
Hope that helps someone else who has run into this issue.

Installing python-ldap in virtualenv on Ubuntu

Posted on by Matt Woodward

We’re authenticating against Active Directory in our current Python/Django project and though we’ve had excellent luck with python-ldap in general, I ran into issues when trying to install python-ldap in a virtualenv this afternoon. As always a lot of DuckDuckGoing and a minimal amount of headbanging led to a solution.

The error I was getting after activating the virtualenv and running pip install python-ldap was related to gcc missing, which was misleading since that wasn’t actually the issue:

error: Setup script exited with error: command ‘gcc’ failed with exit status 1

To add to the weirdness, when I installed python-ldap outside the context of a virtualenv, everything worked fine.
I’ll save you the blow-by-blow and just tell you that on my machine at least, other than the required OpenLDAP installation and some other libraries, I also had to install libsasl2-dev:

sudo apt-get install libsasl2-dev

Once I had that installed, I could activate my virtualenv, run pip install python-ldap and install without errors.
If you still run into issues make sure (in addition to OpenLDAP) to have these packages installed:
  • python-dev
  • libldap2-dev
  • libssl-dev
Hope that saves someone else some time!

A Week at a Conference with the Dell Sputnik

Posted on by Matt Woodward

I attended DjangoCon a couple of weeks ago (which was awesome!) so that was my first opportunity to spend some concentrated quality time with the Dell Sputnik and put it through its paces.

As you’ve probably guessed from my previous posts I’m pretty enamored with the Sputnik, and using it full-time for a week straight didn’t change my opinion. It’s a particularly great machine to travel with since it’s the ideal combination of light but still powerful enough to use for “real” work. In years past I’ve traveled with only a 10.1″ netbook and that was a miserable experience, but the 13″ screen and fantastic battery life of the Sputnik make it the ideal conference companion and I could still catch up on work in the evenings without feeling like I had one hand tied behind my back.

Battery Life

Day one of DjangoCon was a full day of extended tutorials so I used the Sputnik all day to take notes in Zim. There was no wi-fi available so I ran the Sputnik with wi-fi disabled (had there been a decent wi-fi signal I probably would have taken notes in Google Docs), and I did disable Bluetooth as well since I wasn’t using it. I also dimmed the screen to its lowest level since the room was dimly lit anyway and that brightness setting was more than enough to be usable.

In the second tutorial of the day I did enable wi-fi and used my Verizon hotspot since there were some materials to download for the second tutorial. I also close the lid putting the Sputnik into suspend mode when there were breaks, which accounted for a total of an hour of suspend time, and I powered it down completely during the lunch break.

Note that this is a bit of a contrast in my previous battery test when I ran the Sputnik with all the default settings and didn’t even try to conserve battery life, and in that case I still got more than 8 hours out of the battery.

All told the clock time for the day spanned about 7.5 hours including lunch and breaks, and in using the Sputnik with wi-fi on for about 3 hours of that, suspending during breaks, and powering off during lunch, I ended the day with nearly 50% of the battery remaining. Nice.

On the other days of the conference I followed a similar pattern but only powered down during lunch and didn’t ever shut the lid otherwise, and I was using wi-fi most of the day. The schedule on these days ran from 9 am – 6 pm, and even with this longer time span and wi-fi enabled all day, I’d still end each day with about 25% of my battery remaining.

In short, the battery life is darn impressive and beyond up to the task of living through a conference without having access to power during the day.

General Usability

Since I got the Sputnik right before I left for DjangoCon, this also gave me my first opportunity to use the Sputnik as my only machine for a week straight.

I won’t repeat what I said in my previous “initial impressions” post but I will say all those initial impressions held up during the week. The Sputnik is an exceptionally well built machine and is a real pleasure to use. I continued to be impressed with the vividness of the screen and the keyboard is absolutely fantastic.

The only complaint I have from using the Sputnik more heavily for a week is the trackpad. I’m sure this can be resolved through a bit of additional driver work and some setting tweaking, but I did find on occasion that even though I had “tap to click” disabled, and “disable trackpad while typing” turned on, the cursor would occasionally jump around the screen while I was typing, or inadvertently fire click events while I was using the trackpad.

Note there are some setting changes recommended in the Sputnik forums that I enabled which helped quite a bit, but it was still a bit of an issue. On an annoyance scale of 1 – 10 I’d put it at maybe a 3, so not a huge thing but was noticeable. There are also some active bug reports on this issue so I suspect with some driver updates (Sputnik is technically in beta, remember!) they’ll get this resolved.

Summary

After living with the Sputnik as my only machine for a week I continue to be extremely impressed. Particularly in a developer conference situation where power isn’t available at every seat and you have to fight for the few outlets that are available, the Sputnik’s fantastic battery life let me focus on the conference instead of worrying about whether or not my laptop was going to conk out.

Other than the occasional issues with the trackpad I thoroughly enjoyed using the Sputnik at DjangoCon — it makes a great conference companion!

Dell Sputnik: Battery Life Test

Posted on by Matt Woodward

After I got the Sputnik set up the way I wanted I figured it was time to test the battery life, so yesterday afternoon I unplugged the power cord and did normal “work stuff” to see how much time I’d get out of the battery under normal working conditions.

Note that I’m not a professional hardware tester or benchmarker, so this was not a scientific experiment resulting in reams of data that can be sliced and diced 100 different ways. To me those charts and graphs always seem artificial anyway (though I suspect it’s quite efficient to do things that way if you test hardware for a living), so my methodology was, quite simply, to use the laptop unplugged until the battery ran out.

Applications Running During Testing

As far as specifically what I was doing and what applications I had running, I was doing Python/Django development yesterday, so here’s what I had running:
  • Emacs
  • Sublime Text 2
  • MySQL
  • Chrome with 6-10 tabs open
  • Terminal with 3-4 tabs open
  • Pidgin IM client
  • WiFi
  • Bluetooth (I didn’t use this, but it’s on by default so it was running)
I intentionally did not dim the screen to its lowest usable setting since I didn’t want to skew the results too much. I just left the screen brightness at the default setting and let it automatically increase and decrease the brightness based on the default power settings.
I also did not (and I don’t even know if you can do this now that I think about it) disable the backlighting on the keyboard, so it would turn on and off depending on the ambient lighting at any given time.

Testing Process

As I alluded to above you won’t find a lot of scientific methodology here, but I figured I’d say a couple of words about what I did specifically during the battery drain period.
If you’re a developer you’ll already know the gist of this, but basically I was hopping back and forth between Emacs and Sublime Text 2 (I was working on converting a CFML application to Python and it was easier to have the CFML app up in Sublime and do the Python work in Emacs), the browser, and the terminal to run scripts or do something in MySQL. I also would start/stop the Django application, which is basically a little web server. (I did not install Apache on this machine yet since I’m pondering switching over to Nginx anyway.)
Also I’d occasional get up to get a cup of coffee, etc. so there were brief periods here and there when I wasn’t using the machine at all, but not so long that it went into hibernation mode.
That’s about it for the process discussion — I just used the thing as I normally would any computer on a normal work day.

Observations

With the default power settings the Sputnik did a great job of being efficient without being annoying. The screen would dim after a couple of minutes if I was reading something and not typing or using the touchpad and it would raise the brightness again once I moved the mouse or typed. I mention this because some machines I’ve had in the past were extremely aggressive with power-saving functionality (constantly “strobing” or adjusting the screen brightness, for example) to the point of me having to turn off the power management altogether which kind of defeats the purpose. So the default settings on this machine with Ubuntu work quite well.
Taken on balance the time remaining in the battery monitor was quite accurate, though I did notice it would jump up when I was doing something like reading and not interacting with the machine. For example I’d bring up a tab in Chrome with something I needed to read, and immediately after doing that I’d check the time remaining and let’s say it said I had 3 hours left. After reading something (i.e. not typing or moving the mouse) I’d check the time remaining again and it’d say I had 6 hours left. Then after using the machine for a minute I’d check again, and it’d be back to the original number of about 3 hours.
I have no engineering rationale to back this up, but as I was seeing this behavior I likened it in my head to the real-time gas mileage gauge in a car. If I’m braking down a hill in my Prius, it’ll tell me I’m getting “infinite” miles per gallon, which is basically a projection based on what’s going on at that point in time. The battery meter seemed to be behaving similarly, projecting battery life based on the activity at a given moment.
Taking the high estimation outliers out of the equation, however, it was quite accurate, even down to the warnings at the end when the battery meter (and the light on the front of the computer, which is a nice touch) turned red. On some machines I’ve had in the past when it says you have 20 minutes left, that may turn to a “plug it in right now” message in about 5 minutes, but that didn’t happen here. When it said I had 17 minutes left, it meant I had 17 minutes left.

Hibernation

If you know anything about running GNU/Linux on laptops you’ll know that hibernation working correctly can be a bit of a problem if the hardware and drivers don’t play nicely together.
I’m happy to report that the hibernation function on the Sputnik works exactly as you’d expect — you simply close the lid, and a few seconds later the light on the front of the machine will start flashing slowly, indicating it’s in hibernation mode. When you re-open the screen things come back quite quickly including reconnecting to WiFi, so there are no problems at all with hibernation.

Results

One more proclamation of how unscientific this was — I didn’t run a stopwatch while doing this. I just checked the time when I started and checked it again when the battery was more or less dead.
The results are quite impressive, with a run time of about 8 hours 20 minutes in my usage. The marketing materials for this machine claim between 8 and 9 hours so these numbers are quite legitimate in comparison to my usage, and if you disabled WiFi and Bluetooth and dimmed the screen, I can see pushing 9 hours of run time pretty easily.
This is all the more impressive when I compare it to my old Asus Eee netbook, which was a vastly less capable machine and would get 10 hours of battery life only with the larger 9-cell battery that not only stuck out the back of the machine like a tumor but also greatly added to the weight of the machine. So for the Sputnik to get this kind of battery life in normal usage in such a small, light package is really great.
Another big plus for the Sputnik!
I still haven’t covered installation and some settings tweaks so I’ll do that in another post soon.

Dell Sputnik Ultrabook: Initial Impressions

Posted on by Matt Woodward

I got word a couple of days ago that I got into the Dell “Sputnik” beta program, which is Dell’s incubation project to bring a GNU/Linux-based (specifically Ubuntu-based) XPS 13 Ultrabook to market as a product, specifically as a machine aimed at developers. (We developers, lone wolves though we tend to be, do like a little attention now and then!)

As a huge free software and Linux proponent I have been watching this project closely so I was really excited to get an invite to the beta, and I received the machine today. General Disclaimer: The machine was not free. Dell did offer a discount for beta program participants but is heavily encouraging everyone to be very transparent and honest with their impressions of the machine.

In another blog post I’ll cover how I went about installing Ubuntu and the Sputnik-specific PPAs, but in this post I’ll share my initial impressions of the machine. (tl;dr version: With one minor exception, this is an absolutely beautiful, exceedingly well-built ultrabook that’s an absolute pleasure to use.)

This is a DELL?

As I said above I’ll cover Ubuntu installation in another post, but as a very quick aside — the machine does ship with Windows 7, the explanation being they didn’t want to delay shipping the beta machines to get the logistics of pre-installing Ubuntu worked out. On first boot I booted to an Ubuntu USB stick so I never let Windows see the light of day.
As the heading above indicates, to be perfectly honest I was shocked that this is a Dell. Admittedly I haven’t owned a Dell in many years though I’ve had several Dell laptops and desktops in the past, but everything about this machine screams high-end quality. (You can see my quick, too dark unboxing photos on Google+) From the packaging to the machine itself, they clearly put a lot of thought into the design from top to bottom.
The first thing I noticed is how unbelievably solid it feels for such a small, light machine. The machined aluminum lid opens smoothly and firmly to an extremely nice backlit keyboard with a really nice, solid feel. The 13.3″ HD screen is extremely sharp, running at a native 1366×768 pixels. Note that some 13″ ultrabooks have a slightly higher screen resolution, but for me this resolution is perfect for this size screen, striking a good balance between screen real estate and readability.
The bottom of the machine is carbon fiber which is quite cool to the touch for the most part (particularly given that there’s an Intel i7 chip inside), save for one warm spot towards the back of the machine (presumably right where the processor is). There is a bit of faint fan noise as the machine is running but it’s very, very quiet compared to a couple other ultrabooks I’ve had so they’ve put some nice thought into cooling such a small little package without copping out and constantly running a loud fan full speed.
I feel like I should say a bit more about the keyboard since I’m typing this blog post on it — it’s incredibly nice to type on. The keys have a really great, firm action and as you depress the keys the machine body doesn’t “give” as with some ultrabooks, so it doesn’t feel flimsy in any way or like you’ll break it if you get to typing incredibly quickly (which I have a tendency to do).
Even just picking up the machine and carrying it around everything feels amazingly tight and solid. This is a far cry from the Dells I’ve had in the past, and I would think even the most ardent Mac proponent would have to admit the quality of the hardware rivals, if not exceeds, that of Apple.

Tech Specs

You can see and read more about the XPS 13 in general on Dell’s web site, but the Sputnik developer machine is the high-end model, specifically with the following specs:
  • 13.3″ HD (720p) Corning Gorilla Glass WLED screen, 1366×768 resolution
  • Intel i7 processor running at 1.7GHz (with TurboBoost up to 2.8GHz)
  • Intel HD Graphics 3000
  • 256GB SSD
  • 4GB of dual-channel DDR3 RAM (1333MHz)
  • Backlit keyboard
  • Two USB ports, 1 USB 2, 1 USB 3
  • Mini display port
  • Headphone jack
  • Marketing claim on battery life: 8 – 9 hours (I’ll test this to see what real-world battery life is)
In my estimation they did a good job of keeping things very minimalistic while focusing on what’s important. Adding things like more USB ports, multiple (and potentially large in size) display output options, and even wired ethernet would have cause the machine to lose its singular focus which is a small, light, high quality ultrabook.
What this machine doesn’t have, that you should be aware of if these things matter to you, are an optical drive and the aforementioned wired ethernet, and if you want to output to VGA or HDMI you need to pick up a dongle. None of these things matter to me personally; in fact on my other new, larger laptop I got a couple of weeks ago I opted for a second hard drive in place of an optical drive because I can’t even remember the last time I used an optical drive.
The lack of wired ethernet also doesn’t bother me because I personally never used a wired connection, and since this machine is so incredibly thin (and I mean incredibly thin) there isn’t space for an ethernet jack anyway. If you absolutely have to have wired ethernet in an office setting or somewhere without wi-fi you can always get a USB ethernet adapter.
Overall, this is an impressively equipped little powerhouse.

One Minor Potential Downside: Memory

On balance Dell made very smart decisions about what to put into the machine, with the one question mark in my mind being why they chose not to put more than 4GB of RAM in the machine. (It’s worth noting at this point that the machine is not user-upgradeable.) I can’t imagine it was for cost or size reasons, so I have to guess that it was a necessary design/engineering decision for some other reason.
Granted, for many users 4GB of RAM is plenty, and if nothing else putting Ubuntu on the machine will make it run a lot more efficiently than Windows 7. That said, for a machine targeted at developers 4GB seems a tad on the low side these days, so although I’d certainly stop well short of calling it a show-stopper for me at least, it’s something to be aware of and given your situation that may or may not work for you. (Note that Dell makes a slightly larger XPS 14 in which you can get 8GB of RAM.)

Sputnik as a Developer Machine

I’ll find out a lot more about what the Sputnik can and can’t handle next week when I take it to DjangoCon, but the i7 chip is extremely zippy, and my guess is that I’ll find 4GB to be adequate for most of my needs. Ubuntu, Chrome with my usual 12-15 tabs open, and Emacs or Sublime Text are running quite happily and responsively. (Note that I have not yet installed and tried a heavier IDE like PyCharm or Eclipse.)
If you’re a big user of VMs, given my experience on another ultrabook with 4GB of RAM I can say Windows 7 runs decently in 2GB of RAM in VirtualBox on Ubuntu. I wouldn’t want to spend a lot of time in it with only 2GB, but if you need to test something in IE or jump into Windows to run a specific application (e.g. I have to get into Windows on rare occasions to run the VMWare console app to manage our VMs since their web-based console tool is abysmal), it should be a decent experience. Not as nice as on my laptop with 16GB of RAM certainly, and you won’t be able to get away with running multiple VMs at once, but running a VM is certainly possible.
If you’re a Java or CFML developer, I fired up some Java-based applications on Tomcat on this machine, giving Tomcat 1GB and then 2GB of heap space. Things ran fine, though if like me you abuse the heck out of memory if you have it available, I suspect you’re not going to be able to get away running dozens of webapps simultaneously under Tomcat on this machine.
That said I’m moving away from the Java/CFML world into the Python/Django world which is much more memory-friendly, so for Python development this machine should be really excellent. Most of the time when I’m doing Python development I don’t see my memory or CPU monitors even act like much is going on, which is quite a different experience than I was used to with Java and CFML.
The CPU is certainly up to practically any development task, just be aware that depending on the type of development you’re doing and your development style, you might need to think a little bit about the RAM limitation.
Bottom line on Sputnik as a developer machine is I see this as being an absolutely fantastic developer machine, with a minor caveat about the RAM.

Conclusions

The Dell XPS 13 is a huge winner in my book. It’s exceedingly well built, light, quiet, and has all the bells and whistles you need in an ultrabook — particularly one aimed at developers — and Dell made intelligent omissions across the board with the possible exception of the amount of RAM pre-installed.
If like me you’ve had Dells in the past and hadn’t thought about Dell in a while, this machine may well change your mind about Dell. After only a few hours of using it it’s certainly starting to change mine, and I can already see myself gravitating to the Sputnik as my go-to machine.

Installing MySQL Python Module on Ubuntu

Posted on by Matt Woodward

After tearing through several other Django books and tutorials using sqlite3 as the database, I’m starting to go through the book Beginning Django E-Commerce and it uses MySQL as the database. I use MySQL quite a lot so that side of things isn’t an issue, but I did run into a couple of wrinkles getting MySQL and Django playing nice so I thought I’d share.

Basically if after configuring your database in settings.py and running python manage.py dbshell you get a bunch of errors, you have a minor amount of installation work to do to get things rolling.

First thing I did was install pip, which is a better version of/replacement for easy_install:
sudo easy_install pip
Next I ran pip upgrade for good measure (probably not necessary but can’t hurt, and worth running if you already had pip installed):
sudo pip install pip –upgrade
On my machine (Ubuntu 12.04 64-bit) I also had to build the dependencies for the python-mysqldb libraries:
sudo apt-get build-dep python-mysqldb
And finally with that in place you can use pip to install the Python MySQL libraries:
sudo pip install MySQL-python
If everything worked you should now be able to run python manage.py dbshell from your Django project and have it load up the MySQL console.

Pidgin, SIPE, and Read Error on Ubutnu 12.04

Posted on by Matt Woodward

I think I may have posted about this before but I couldn’t find it, so since I was doing a clean install of Ubuntu 12.04 on one of my laptops this weekend I figured I’d write it up again.

If you’re on Ubuntu 12.04, you use Pidgin (which you should — Empathy sucks), and you need to connect to MS Lync (formerly known as Office Communicator), thankfully you can simply install the SIPE plugin for Pidgin:
sudo apt-get install pidgin-sipe

In my case I also had to specify this as the User Agent to get it to connect:
UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)

There’s one additional wrinkle on Ubuntu 12.04, because even after installing the SIPE plugin and setting the user agent, you may see “Read error” when you try to connect.

You’re never alone on the Internet — other people have run into this too, and the solution is simple enough, but since I didn’t want to have to do that every time I launched Pidgin I put that in a bash script and changed the Pidgin launcher to point to this script.

You can put this anywhere so long as it’s executable, but here’s the script:
#!/bin/bash
export NSS_SSL_CBC_RANDOM_IV=0
pidgin

I feel like a bad nerd by admitting that I have no idea what that does and didn’t take the time to look into it since it solved my problem, but there’s the solution that works for me.

Using “Online Accounts” With Ubuntu 12.04

Posted on by Matt Woodward

One of the features I really like on Linux Mint is the “online accounts” that you can enable by clicking on your user name on the top right of the screen, which lets you integrate your Google (and other online account) contacts and calendar with the native OS applications.

I’ve been trying Ubuntu 12.04 RC2 on my System76 Lemur Ultrathin to see if I want to use it instead of Mint 12 on my main work machine once I get a new System76 Serval to replace my (still excellent!) three-year-old Serval, and I was a bit disappointed to see that the online accounts feature doesn’t show up as an option when you click on your user name.

I was happy to discover tonight that it’s in Ubuntu 12.04, just in a different place. If you go to the Contacts application you can add your online account from there.

Contacts seem to work fine, but what I don’t yet see is how the calendar works (or doesn’t work), and honestly I’m starting to think maybe the calendar functionality I’m seeing in Mint is by virtue of Evolution, which doesn’t come preloaded on Ubuntu.

Having my calendar accessible right from the OS and having it pop up alerts is pretty darn handy so I’ll have to dig into that further and see what my options are. I’m sure there’s plenty of calendar applications available but the seamless integration is one thing I do like about Linux Mint.

If any of you Ubuntu users out there have suggestions on this I’m all ears.