1. It is time to let the old Boto retire; it would not let me access the attached managed policies of an IAM role. Boto3 supports this.
2. Chef community cookbooks that are bundled with a project have a tendency to not work if left alone for a while—and upgrading them can get messy due to the way dependencies are handled. Stick to the cookbooks with no or simple dependency graphs or just roll your own solution.

mount: mount point /dev/pts does not exist
mountall: mount /dev/pts [1070] terminated with status 32
mountall: Filesystem could not be mounted: /dev/pts
mount: mount point /dev/pts does not exist
mountall: mount /dev/pts [1074] terminated with status 32
mountall: Filesystem could not be mounted: /dev/pts
init: mountall main process (1065) terminated with status 4
Mount of root filesystem failed.

Fortunately Linode has a good set of rescue documentation. After messing around with various suggestions on how to fix this problem I ended up with the following /etc/fstab:

proc /proc proc defaults 0 0
/dev/sda / ext3 noatime,errors=remount-ro 0 1
/dev/sdb none swap sw 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0

This, however, did not seem to help. After an hour of random trial and error I finally decided to toggle the following option on the Linode configuration edit page to “no”:

For reasons that are still unclear to me, this mounted /dev/pts properly and the rest of the boot sequence ran without a hitch.

Around 2007 I used to be fairly fluent in Django, this after having built a substantial Django web application from scratch. These were the days before Django 1.0. While all the necessary documentation was there, the framework had some rough edges and peculiar design choices.

Still, Django made a lot of sense. I had previously dabbled with Ruby on Rails but it never really clicked with me. Once I grew comfortable with the Django mindset I never looked back.

Time passes and I move on to other projects. I tried to keep track of what was happening in the world of Django, but lost interest around version 1.2. Fast forward to 2014, and I suddenly get the chance to develop with Django again. By keeping an ear on the tech grapevine I have a rough idea of the major innovations to Django since it dropped off my radar. Nonetheless, the devil is in the details and I dive into the Django documentation.

You can say a lot of good things about the Django docs. For starters, it is very comprehensive and quite well organized. Still, it is not a good choice for a learner or for someone who just need a quick refresher. The wealth of information is a good thing when you need a solution to a particular problem. It is not a good thing when you just want to figure out how it all the pieces fit together. There is the Django Book as well but it is terribly outdated.

Luckily, the good folks at Packt Publishing were kind enough to offer me a review copy of the recently released “Django Essentials” by Samuel Dauzon at just about this time.

Is is a nice, short read, kicking in at about 150 pages. If you skip implementing the code examples, it should not take you many hours to get through it. That being said, by working your way through the examples you will get a clear sense of how Django will let you make your web application come to life.

What I particularly like about this book is that it puts Django in its proper context. Best-practice tools and techniques such as Nginx, jQuery, AJAX, PostgreSQL and virtualenv are introduced, meaning that you will have an idea of how to make them work with your Django application.

All the major Django concepts are covered in a pedagogic manner. As an example, classic views are introduced first. Later on, class-based views are introduced, showing you how they can save you a lot of time—while reminding you that classic views still are useful in certain situations. A nice touch is that South, the (soon to be deprecated) Django data migration tool, is introduced before you write your first Model class.

The book is well written and nicely laid out. One minor annoyance is that some of the code examples could have been better formatted. Another nitpick is the UserProfile model example in the models chapter. For the novice Django developer it should be pointed out right away that the secure choice is to always use the builtin User class rather than trying to roll your own. Fortunately this is explained later in the book.

Given that the book spends a bit of time on the recommended ecosystem around Django, it would have been nice to see mentions of other tools such as Bootstrap and the various third-party amendments to Django which makes it a lot more powerful. Still, the brevity of this book is one of its strengths.

All in all, “Django Essentials” is a great read and comes highly recommended if you know a little bit of Python and want to level up to web application development.

UPDATE 2: Added new data for the February 2010 AWS data transfer price reduction.

In a previous posting I did a cost comparison of a reserved Amazon Web Services EC2 instance and a comparable dedicated server from Go Daddy. Amazon recently announced a set of price cuts for reserved instances, so an updated comparison is in order.

The server configurations I’m comparing are the same as last time:

I have added an extra column for the new EC2 reserved instance pricing scheme. Notably, the prices for the Go Daddy options haven’t changed in the last six months. For the 1- and 3-year AWS plans, the total costs have dropped by $390 (17%) and $600 (12%), bandwidth excluded.

(For the full discussion, refer to the previous posting.)

When including bandwidth use, the updated table looks as follows:

With the old pricing, the AWS option was preferable unless bandwidth exceeded 100GB per month (for the 1-year plan) or 250GB per month (for the 3-year plan). After the August 2009 price cuts, AWS became an even more competitive option, although one that still falls behind for high bandwidth scenarios.

In February 2010, the price for outgoing data traffic dropped from $0.17 to $0.15. With the 3-year plan, AWS now matches Go Daddy up until almost 400GB per month.

Addendum: Some of the background data used in this posting:

• Go Daddy quotes from August 28, 2009
• Go Daddy 3-year plan cost: 2-year plan quote * 1.5
• AWS 1-year plan cost (< Aug 2009): $1,300 + (24 * 365 * 1 * $0.12) + (GB/mth * $0.17 * 12)
• AWS 1-year plan cost (Aug 2009): $910 + (24 * 365 * 1 * $0.12) + (GB/mth * $0.17 * 12)
• AWS 1-year plan cost (Feb 2010): $910 + (24 * 365 * 1 * $0.12) + (GB/mth * $0.15 * 12)
• AWS 3-year plan cost (< Aug 2009): $2,000 + (24 * 365 * 3 * $0.12) + (GB/mth * $0.17 * 36)
• AWS 3-year plan cost (Aug 2009): $1,400 + (24 * 365 * 3 * $0.12) + (GB/mth * $0.17 * 36)
• AWS 3-year plan cost (Feb 2010): $1,400 + (24 * 365 * 3 * $0.12) + (GB/mth * $0.15 * 36)
• EC2 pricing information
• Go Daddy dedicated server pricing information

1. Install Cygwin if you don’t already have it on your system, and make sure that the version of Python you are installing SimpleParse for is on either the system or the Cygwin path.

2. Download and install Microsoft Visual C++ 2008 Express Edition. You should ensure that you have the latest Vista service packs installed before attempting this. If the installer quits on you then just reboot the computer and try again. Without this installed, you wil get an ‘Unable to find vcvarsall.bat’ error.

3. Download and unpack the SimpleParse 2.1.0a1 source. Using the Cygwin shell, place yourself in the root source directory.

4. If we try to run python setup.py install at this point, the Visual C++ compiler will complain:

stt/TextTools/mxTextTools/mxTextTools.c(149) : error C2133:
'mxTextSearch_Methods' : unknown size
stt/TextTools/mxTextTools/mxTextTools.c(920) : error C2133:
'mxCharSet_Methods': unknown size
stt/TextTools/mxTextTools/mxTextTools.c(2103) : error C2133:
'mxTagTable_Methods' : unknown size
error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"'
failed with exit status 2

We have to add the following lines to stt/TextTools/mxTextTools/mxTextTools.c, starting at line 148 (before staticforward is used for the first time):

#ifdef _MSC_VER
#define staticforward extern
#endif

5. with is a Python 2.6 keyword, meaning it can’t be used as a variable, as is the case in the SimpleParse source code. So, we have to replace it with something else:

$ sed -r 's/with/with_t/g' < stt/TextTools/TextTools.py > tmp.txt
$ cp tmp.txt stt/TextTools/TextTools.py

6. Finally, run python setup.py install as usual.

“Writing, Jen thought, seemed like a very sad pursuit. Like painting, but worse. At least paintings had color. Writing, though, was just black marks on paper, standing in for people and objects and events that could never be seen or felt. It seemed pathetic in a way. Nouns were the saddest words of all, trying so hard to summon real objects to life.”

Jon Raymond, “Words and Things” (Livability)

In prioritized order:

• Run EndNote as an administrator (for Windows Vista).
• Reset EndNote defaults (“Edit -> Preferences -> EndNote defaults”). This seems to work most of the time. Make sure to close Word first. After having reset EndNote, close it, and then try launching it from Word.
• The library may be corrupted. Try running “Tools -> Recover Library”.
• If all else fails, reinstall EndNote

There are other possible problems, especially when upgrading from older versions, but these actions usually work for me.

(For Norwegian readers: If you are using the Norwegian version of EndNote, the error messages will be ‘ugyldig klassestreng’ or ‘serverutføringen mislyktes’.)

UPDATE 2: Corrected the bandwidth calculation in the formulas for AWS.

Amazon Web Services just announced a new reserved instances pricing plan. In short, this plan allows you to reserve EC2 instances for a 1 to 3 year period by paying a one-time reservation fee. The hourly rate for reserved instances is considerably lower than for regular spot-market instances. For comparisons sake, a large standard on-demand instance will set you back $0.40 per hour, while the large standard reserved instance is only $0.12 per hour.

With the old pricing scheme, hosting a web service on AWS instead of on a dedicated server was not a very cost-competitive option, at least not for resource-intensive applications. For my web site, Eventseer, I require at least a large standard instance—at $0.40 per hour for 24/7 operation (bandwidth costs not included), this turned out way too expensive compared with offerings from traditional dedicated server providers.

To see if the new pricing scheme fares any better, I have compared the cost of an AWS EC2 reserved large instance with a similar dedicated server from Go Daddy:

I’m not sure how the 4 EC2 compute units compete with a dedicated Core 2 Duo 2.66 GHz. This probably also depends on the nature of your application. Note that the AWS solution has twice the amount of memory. From what I can see, you can not get a Go Daddy dedicated server with more than 3.2GB of memory, while AWS offers up to 15GB on the extra large instances.

When disregarding bandwidth costs, AWS suddenly makes a lot of sense. As bandwidth use is highly application-dependent, let’s consider a few different bandwidth use scenarios:

Conclusion: With a 1-year plan, AWS is the cheapest option until you reach about 100GB of external bandwidth per month. With the 3-year plan, the AWS bandwidth cost isn’t a problem until about 250GB per month. (Bandwidth is “free” with Go Daddy dedicated servers up until 500GB per month; after that it’s an extra $19.99 per month until you reach 1,000GB).

Considering that the AWS solution gets you twice the amount of RAM, AWS suddenly seems a very viable option even for web service hosting—as long as you’re not expecting extreme
amounts of traffic. However, once you get popular the outgoing data transfer pricing will take its toll.

Addendum: Some of the background data used in this posting:

• Go Daddy quotes from March 12, 2009
• Formula for Go Daddy 3-year plan cost: 2-year plan quote * 1.5
• Formula for AWS 1-year plan cost: $1,300 + (24 * 365 * 1 * $0.12) + (GB/mth * $0.17 * 12)
• Formula for AWS 3-year plan cost: $2,000 + (24 * 365 * 3 * $0.12) + (GB/mth * $0.17 * 36)
• EC2 pricing information
• Go Daddy dedicated server pricing information