Like many others, we at Gotham City Drupal decided we could no longer support GoDaddy after learning of their stand on SOPA (fake-retracted though it may be). So on December 24, we moved all our DNS (20 domain names), hosting (3 servers) and numerous email and other myriad services to http://namecheap.com, which company has aggressively come out against SOPA.
We are happy to report a smooth transition was effected, with virtually no associated downtime. We are very happy with namecheap so far.
Another wonderful DrupalCamp here in NYC is coming up - seats are filling, so be sure and register soon. I am planning to present a session on Pantheon again at this camp, so if you're interested in hearing about Pantheon from a developer's perspective, please register. I hope to see you there!
Here's the formal announcement of the Camp from the organizers:
DrupalCampNYC 10 will be the largest New York City Camp to date, with 500 anticipated attendees and over 30 high-quality sessions across a spectrum of Drupal-related disciplines.
It's all happening on Saturday, December 10, 2011 at
7a. an alternate - and probably better - method is to git clone your "new" drush to your local, perform steps 5-7 on your local, and then commit/push the table.inc file to Pantheon
Pantheon is an amazing product. I am thrilled that we are able to participate as beta users in their product. However, as with all beta products, some of the "nice-to-haves" are not quite in place yet, as they focus on polishing the "must-haves" first (and the must-haves are truly delightful in Pantheon's implementation). As a Mac OS X users, and having become addicted to using DAMP for my local development environment, there are a few hurdles to overcome to make the workflow smooth and fast.
We've talked about this vaguely a couple times but I thought I would briefly summarize "how things scale" in Drupal-land (true for every database-driven site stack though, pretty much), just to give you an idea of how it works:
Vertical Scaling Vertical Scaling is fastest and easiest from a sysadmin standpoint, since it basically means "move to a bigger machine and/or more RAM and/or faster core processors. For a general guide, see the figures below.
This is a very useful post which gathers together some bits of a couple of issues - among them the "multiple-php.ini" problem and the "htaccess slash" problem. With this post in hand, porting your Drupal Gardens site from drupalgardens.com hosting to Go Daddy hosting is doable, and quickly. It's also far less frustrating. Thanks to the authors for documenting these fixes for us!
