Martin Melin   Tech blog

For historical reasons I have a 32 bit installation of MySQL on my local machine, which is currently running Snow Leopard.

Because I prefer programming new things to mucking about with already-working software, I haven’t migrated to a 64 bit MySQL and probably won’t until I install my machine fresh sometime in the future.

In the meantime, I run into a problem when using a Python virtualenv with –no-site-packages and have had to figure out the solution a couple of times now, so I thought I’d share the solution here for my benefit in the future but also hopefully help someone else through the magic of Google.

So, if you’ve done a pip install -E venv MySQL-python and are trying to do:

>>> import MySQLdb

inside that virtualenv, but are getting hit with this apparently non-sensical error message:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]venv/lib/python2.6/site-packages/MySQLdb/__init__.py", line 19, in <module>
    import _mysql
ImportError: dlopen([...]venv/lib/python2.6/site-packages/_mysql.so, 2): no suitable image found.  Did find:
        [...]venv/lib/python2.6/site-packages/_mysql.so: mach-o, but wrong architecture

Then I may have the quick-fix you’ve been Googling for. First, verify that your situation is the same as mine by opening a REPL and typing:

>>> import sys

>>> sys.maxint

If you don’t get 2147483647, you have the same problem as me: Python is 64-bit but you have a 32-bit MySQLdb installed.

My very quick fix to get back to work is as follows: since you have a 32-bit MySQL and aren’t planning on upgrading, there’s no point in using anything other than a 32-bit Python for interacting with that database. So, let’s get rid of the 64-bit version of Python that’s included in your virtualenv Python fat binary. Note that it’s extremely important to not mess around with your system Python here, only the copy that’s inside your virtualenv.

Make sure you’re inside your virtualenv by typing this in a shell:

$ which python

The output should be the path to venv/bin/python (or whatever you’ve called your virtualenv).

So, let’s move the current fat binary that contains both 32 and 64 bit versions of Python:

$ mv venv/bin/python venv/bin/python.old

Then use the OS X utility lipo to remove the x86_64 version from the fat (“universal” in OS X lingo) binary:

$ lipo -remove x86_64 venv/bin/python.old -o venv/bin/python

As you can see, lipo doesn’t remove it in place but outputs a new version of the binary with x86_64 stripped.

Finally, confirm things have worked:

$ python

>>> import sys

>>> sys.maxint

2147483647

>>> import MySQLdb

>>>

And get back to work!

(of course, the correct way to solve this is to go 64-bit only, but that’s a project for another time)

Maybe it wasn’t a great idea to get into both Vagrant and Puppet at the same time. I ran into an issue which in retrospect is probably pretty obvious for experienced Puppet/Vagrant users but I wasted a lot of time finding out how to do it. I’m mostly posting this in the hope that I’ll be able to save somebody else some time.

Puppet has this concept of modules, which provide features that aren’t in stock Puppet. Vagrant supports provisioning with both Chef and Puppet, but the key thing is that installing a Puppet module into your local Puppet installation won’t make it available to Vagrant.

I wanted to add Richard Crowley’s puppet-pip to be able to use pip as a provider in my Puppet manifest. I won’t give you the details of what I tried that didn’t work, just the solution:

Put any modules you want Vagrant to have access to in a dedicated modules directory, then configure your Vagrantfile like this:

config.vm.provision :puppet, :module_path => "modules"

Where module_path is relative to your Vagrantfile.

HTH,

TL;DR 7 out of 10 YC startups host their email with Google Apps.

Google Apps is increasing in popularity among traditional companies every day, but total marketshare is still relatively low compared to other solutions. There are of course many reasons behind this ranging from inertia to FUD spread by competitors.

Startups, however, are free to choose the best solution without having to consider any historical technical debt or pre-existing vendor relationships. I thought it would be interesting to look at what kind of solutions new startups are going with.

Because the definition of what constitutes a ‘startup’ is still a hot topic for debate, I decided to look at startups that have at one point participated in Y Combinator. I feel this provides a good selection of relatively serious startups in a variety of fields.

From the spreadsheet linked in the top answer to this Quora post, I extracted a list of 204 domains of Y Combinator startups. I then created a batch file for dig that would look up the MX entries for each domain. Finally some regular expression magic cleaned up the results and combined all of the different aliases for Google Apps MX servers into one value: GOOGLEMAIL.COM.

It turns out that the number of unique domains that have at least one .google.com or .googlemail.com MX entry is 142 out of a total of 204. Since the original spreadsheet only lists one domain per startup, this means that almost 70% of YC startups with a domain name present in the spreadsheet are using Google Apps for email. This does not consider the possibility of some startups using another MX that is forwarding into Google Apps, so the actual percentage could very well be higher than 70%.

I feel that these are pretty amazing numbers. When launching a new startup, an overwhelming majority of people are choosing to host their email with Google. This happens to be great news for me, because it validates an assumption of mine that I can launch an MVP of a new project supporting only Google Apps users. Given enough time, I wouldn’t be surprised to see Google Apps equaling or surpassing Microsoft Exchange in market share.

I’ve released an updated version of my mod_rewrite rule test tool. The two major features are:

• Support for RewriteCond statements, making this a much more complete tool
• A visual display of matches, which is very useful when you have a complex ruleset

Today was also the first time that I tried to “market” this tool, which meant a quick email to everyone who has emailed me about this tool in the past (mostly to request support for RewriteCond!) and a post on Hacker News that spent a few hours on the front page and generated some great feedback in the comments.

As I write this post the new tool has been online for 7 hours and has received 4,400 visitors along with a fair number of mentions on Twitter, which is fantastic for a niche tool like this. The old version had stabilized at around 1,000-2,000 unique visitors a month, so I’m obviously pretty excited about these numbers.

I’ve decided to start a tech blog in English, 5-10 years later than everyone else. This will mostly be a place for me to share things related to my programming, system administration and general hackery work. I’ll still keep my Swedish language blog running, and hopefully having two rarely updated blogs will help my amateur SEO efforts to beat Martin Melin (winner of Swedish reality show Survivor) for the top spot in Google’s SERP.

I love those times when you Google a really obscure error message, and the first hit is a blog post where someone else on the other side of the world had that exact same issue and spent three hours figuring it out. By taking the time to post the solution on their blog, they just saved everyone else those three hours (in a perfect world). So I figure this blog will be my way of contributing to that ever-increasing pool of saved time.

Hopefully I’ll also get to do some other fun stuff here, like reviewing books and new web apps. Apart from software development in general, I’m interested in product design and customer development, a focus I’ve probably picked up from spending more time than I’d care to admit on Hacker News.