till's blog

In order to connect to firewall and DRACs of our new Rackspace cluster, I had to setup a VPN connection. Rackspace gave us a Cisco ASA device which is firewall and vpn in one. In order to connect to the VPN the client needs to do 2-factor authentication.

At first I tried to install the necessary add-ons for Ubuntu's network-manager, but after I spent an hour or so trying to make it work, I took an alternate route.

Requirements

Here's all you need to get started:

$ sudo aptitude install vpnc
...

Configuration

Create a configuration file — I called mine rackspace.conf:

$ gksudo gedit /etc/vpnc/rackspace.conf

I put in the following:

IPSec gateway X.X.X.X
IPSec ID GROUPNAME
IPSec secret GROUPPASSWORD
Xauth username USERNAME
Xauth password PASSWORD

Obviously, the capitalized values need to be replaced:

• IPSec gateway: the VPN's gateway/address
• IPSec ID: the group's name
• IPSec secret: the group's password
• Xauth username: the username
• Xauth password: the password associated with the username

If you're with Rackspace, they'll tell you those exact things when the firewall is provisioned. I gather other ISPs call them similar.

Using your VPN

Once the file is saved, just start the vpn connection:

$ sudo vpnc rackspace
VPNC started in background (pid: 2691)...

Note: Just rackspace is plenty, not rackspace.conf or similar.

Testing:

$ ping 172.30.0.144
PING 172.30.0.144 (172.30.0.144) 56(84) bytes of data.
64 bytes from 172.30.0.144: icmp_seq=1 ttl=64 time=114 ms
64 bytes from 172.30.0.144: icmp_seq=2 ttl=64 time=113 ms
64 bytes from 172.30.0.144: icmp_seq=3 ttl=64 time=113 ms
^C
--- 172.30.0.144 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 113.766/114.199/114.866/0.552 ms

To disconnect it:

$ sudo vpnc-disconnect 
Terminating vpnc daemon (pid: 2691)

Fin

That's all.

Some people have this misconception that there is a plot to kill of the original mysql extension (aka ext/mysql) in PHP.

So first off, I know that bloggers are not journalist. So apprently fact-checking is not required for a rant blog post. ;-) But if a blog post is a rant, it should be labeled as such.

Improved

ext/mysqli (hint: "i" as in improved) has been the goto extension for years. If anyone writes code in 2011 which uses ext/mysql, then they should be fired or demoted to trainee. MySQL's 4.1.3 beta was released in 2004 and ever since its release, it's been "strongly" suggested to use ext/mysqli.

PHP's fault in this case is that it didn't drop ext/mysql sooner.

Legacy code

The problem with legacy code is that it's usually not a legacy with the good meaning of the word.

It's indeed a legacy of the past which often exhibits all things that can go wrong on a PHP project.

In a situation where a project requires an older version of PHP to run, there are two kind of improvements developers (and essentially the companies employing them) miss out on: active and passive.

Passive improvements

… generally happen and don't require anyone to re-write any code, examples include:

• PHP's runtime became more efficient
• improvements such as garbage collection
• most importantly: bugs were fixed

Active improvements

… may require updates to the code base — they mostly include new features (e.g. through a new extension) or extensions of the language itself — namespaces, traits, etc..

Ecosystem

In addition to missing out on the improvements of the language another major problem is that since the code base requires an out-dated (maybe vulnerable) version of PHP to run, companies are often stuck in an entirely outdated ecosystem.

From top to bottom: it starts from the OS (Security updates?) — Linux, but also includes the services you run — MySQL and Apache. But there you go, the entire LAMP stack is fubar'd.

Anyone could argue that it's possible to e.g. run PHP4 on a recent Linux with semi-recent components, but let alone compiling PHP and/or backporting patches for security issues and crucial bugfixes don't make maintainance exactly trivial.

Update, 2011-06-16, 12:15 AM Thanks for the comments.

(I swear I had something like that before and it didn't work!) Here's the solution:

$userId = 61382;
$docId  = 'CLD2_62e029fc-1dae-4f20-873e-69facb64a21a';
$body   = '{"error":"missing","reason":"problem?"}';

$client = new Zend_Http_Client;
$client->setAdapter(new Zend_Http_Client_Adapter_Test);

$couchdb = $this->getMock(
    'CouchDB',
    array('makeRequest',),
    array($userId, $this->config,)
);
$couchdb->expects($this->once())
    ->method('makeRequest')
    ->will($this->returnValue(new Zend_Http_Response(200, array(), $body)));
$couchdb->setHttpClient($client);
$couchdb->getDocument($docId);

--- Original blog entry ---

I wrote a couple tests for a small CouchDB access wrapper today. But when I wrote the implementation itself, I realized that my class setup depends on an actual CouchDB server being available and here my journey began.

Example code

Consider the following example:

My objective is not to be able to test any of the protected methods directly, but to be able to supply a fixture so we don't have to setup CouchDB to run our testsuite. My fixture would replace makeRequest() and return a JSON string instead.

So Sourceforge is complaining about people hating on Twitter. First off: haters gonna hate!. Sourceforge should know better and not feed the trolls.

Then, people complain for a reason. For years your website has been complicated and actual development (not distribution) has stagnated on Sourceforge. To me it seemed like the primary objective was maximizing income from advertisement. Yes, you guys relaunched a few times, but unfortunately never got it quite right. Having said that, of course this is about open source, but the platform is equally important. I don't want to suggest to copy Github, but they really manage to do a lot of things right.

I got into a discussion on Twitter the other day where I mentioned that I don't like DI. Call it lack of sleep or language barrier (on my part), but I said DI — dependency injection — when I meant the dependency injection container. Having said this, let me explain why I don't like it.

POV

Despite not working for any of the larger PHP joints out there, I get to spend my time with pretty interesting stuff. I wouldn't call it high traffic or big data, but being in the Top 100 websites, we're certainly not the average PHP application out there.

I've shared some numbers perviously, and also in our job posting — don't mean to compare size, but my perspective is just that.

Looking at anything, I'm compelled to ask myself:

• How much time will it save during development?
• How much time will take to educate my team?
• How much time will it eat away in each request?
• How much time will it cost me to rip it out when it's slow?

Yeah, I'm still crazy about technology, but I've also grown up to not just submit to any of it without thorough evaluation. In that respect, I've grown old(er) — but that's (IMHO) healthy sceptism and usually what people call experience.

Hype

At the expense of my own credibility, let me just say (again) that I'm not particulary against new things. My beef is the hype.

The fact is that we use a lot of new technology and I have to admit that it's pretty exciting for me when to try out new things. Trying out doesn't mean that we end up using it, but when we try out we take a close look.

On the newer side of things we ended up using CouchDB, Redis, Membase and ElasticSearch. On one or two of these we have even started hacking and all in all we follow their development closely.

Telling people about what we run, sometimes feels like I run a playground for developers and crazy-about-tech people. It's new and it's bleeding edge, and it may be true to a certain extend, but it also the opposite because we (believe we) found great use-cases for each of these things.

But getting back to patterns, and I believe these prove my point even better than going on about these databases: Be honest to yourself and let's define "new" in this case and in general. Because neither dependency injection nor containers, or NoSQL are exactly new.

I don't want to rain on anyone's parade, but get real — it's been said and done before.