Archives For

This past weekend I entered the Auckland Startup Weekend. It was an excellent experience and I wanted to share it here, because if you have an opportunity to do a start-up weekend, in Auckland or anywhere else, you should – you will not regret it.

The whole event would make an interesting social experiment, as complete strangers are thrust together around a half-baked idea and given 50-something hours to turn it into a pitch-able, feasible business. I’m going to share my experience of the weekend here, so if you’re interested in what a Startup Weekend is like, and what happens, read on…

Continue Reading…

This article will give an overview of Magento extension clashes (sometimes called conflicts) and then run through a few ways you can find them in your installation.

I get asked at least once a week a question like ‘What is a Magento Extension Clash‘ or ‘How Do I Find Extensions that Conflict‘. So, if you’re reading this, you probably just asked me, and I probably just sent you a link to here. That was a bit meta-blog, sorry about that. On with the article.

What is a Clash?

Magento extensions can override core functionality using what’s called a class rewrite. That’s when your extensions configuration file tells the core of Magento to use your custom PHP class, instead of the core one. Typically the custom class will sub-class the core one, and only override the methods that need to be changed. Here’s an example of that, firstly showing a snippet of rewrite xml for a core model:

<!-- ... snip config.xml ... -->
        <models>
            <core>
                <rewrite>
                    <email>Aschroder_Email_Model_Email</email>
                </rewrite>
            </core>
        </models>
<!-- ... snip config.xml ... -->

And then the corresponding class, notice it overrides the core version:

 
class Aschroder_Email_Model_Email extends Mage_Core_Model_Email {
 
// only add methods here that override the ones we want to change in Mage_Core_Model_Email
 
}

So that’d all be well and good if everyone only installed my email extension in their Magento store, but they don’t. They install PDF email attachments, email emoticons, email monkeys and god knows what else. So the rewrite that my extension needs to work, may very well not happen, because another extension rewrites the same class.

The same sorts of things can happen all over Magento, and typically the bigger and more complex and extension is, the more rewrites it will need, and the bigger the surface area for conflicts and clashes.

You might be thinking: “Gosh, it’d be great if Magento Connect ran some sort of rudimentry test for compatibility before installing extensions willy-nilly in Magento Stores” and if you are, that means you’re one of the Good Guys™.
Continue Reading…

In my previous post I weighed up the benefits and limitations of Amazon’s Elastic Beanstalk hosting environment for Magento and took a very vague look at the costs. In this post I will run through the actual setup of a very basic Magento install ‘in the cloud‘ and the process of deploying changes. The goal for this initial setup is to keep everything bone stock as possible, we want minimal maintenance effort and an automated environment.

If we have some time at the end, we’ll do some stress testing of the platform to see how it handles customers. Benchmarks will have to wait, stay tuned.

The Tools

For this tutorial we’ll be working in a linux environment. I used a small EC2 server with the AWS default Linux AMI as the setup box, it’s nice and fast being on the same network as the Beanstalk platform. Make sure you have the following installed.

  • AWS EB tools, and the getting started guide
  • git, sudo yum install git
  • ruby, sudo yum install ruby
  • python 2.7, sudo yum install python27 – this one is a bit of a pain on the AWS default Linux AMI, you’ll need to hack in explicit use of the 2.7 binary in the AWS scripts. Or, heaven forbid, set it up properly and compile from source…

Once you have those in place, you should be ready to get Magento and the Beanstalk environment setup.
Continue Reading…

In this post I’m going to introduce Amazon’s Elastic Beanstalk PHP environment as a platform for Magento. In particular I’ll cover the mechanics and economics of hosting Magento, along with it’s benefits and limitations as a platform. The goal here is to create an auto-pilot environment providing high availability and scalability.

But first, the background. With World Wide Access, we’ve always run our own EC2 instances, ELBs, database servers and memcached. We scale up the instance sizes or counts manually when required. When we started using AWS (in 2008) Elastic Beanstalk was not yet on the scene so we had no choice but to do it that way. But now we do have a choice and, thanks to some downtime in the last week, I’m prompted to gather some thoughts on a migration to a fully auto-pilot set-up. This post is my notes on Elastic Beanstalk and Magento with git for deployment. I’ll add a more detailed setup guide and some benchmarks in a future post – this one will be a bit more abstract, so go make yourself a cuppa.

About the Amazon’s Elastic Beanstalk

Beanstalk brings together various parts of Amazon’s infrastructure: AWS servers, scaling, load balancing and high availability, to give your applications an automated environment to run in with flexible server sizes and instance counts that make growing easy. You can do all the things Elastic Beanstalk does, by combining the separate parts yourself, but this is much easier, trust me.
Continue Reading…

I’ve been a long time MAMP user, but I recently upgraded my laptop and decided to do a fresh install of everything, and a ground up re-configuration of all my dev environments (a fair bit of mucking about with PHP, Ruby, Java, Python and trying Go).

After a short while researching it became clear the best tool for the job would be Homebrew – it gives you much more control of the environment than MAMP, without the Macports heartache.

In this post I’ll run through using Homebrew on OSX Mountain Lion for a Mysql+PHP CGI setup – I’ll document adding a webserver to this stack in a later post, my immediate need is for a PHP CGI environment.

Setup Homebrew

Before you do any of this, go grab Xcode from the App Store. Hope you’re not on a 3G internet connection, it’s a 1.6GB install! Go grab a coffee while you wait. After that’s installed you’re also going to need to go to Xcode > Preferences and install the command-line tools, another 100+ MB install.

The Homebrew install from their own site is just:

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

Setup PHP

Homebrew uses the tap command to import more sources for install scripts. See what they did there? I use the homebrew-php project, seems awesome – loads of support, docs and info on the project page, all going to plan you’ll just need these two commands below.

brew tap josegonzalez/homebrew-php
brew tap homebrew/dupes

You can review all the options with the brew options php54 command, if you want mysql and CGI, use the command below that I used.

brew install --with-mysql --with-cgi php54

It’ll run through a bunch of downloading/compiling steps but the end result should be that you get the following test output:

/usr/local/bin/php-cgi --version
PHP 5.4.12 (cgi-fcgi) (built: Mar 19 2013 14:39:37)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Setup MySQL

It’s super easy, watch.

brew install mysql

Then just follow the instructions that get blurted out during the Homebrew install of mysql.

Slight catch is, if your OSX is anything like mine you’ll need to run this first:

mkdir -p /usr/local/var/mysql
unset TMPDIR
mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

I also got this warning:
WARNING: Found existing config file /usr/local/opt/mysql/my.cnf on the system. which you can safely fix with:

#backup existing
mv /usr/local/opt/mysql/my.cnf /usr/local/opt/mysql/my.cnf.old
#move new
mv /usr/local/opt/mysql/my-new.cnf /usr/local/opt/mysql/my.cnf

There’s also a lot of good advice for securing your mysql install blurted out during the install process, ignore it at your peril. Test your handiwork by checking you can access the mysql commandline prompt:

mysql -uroot
# or, with the password you set. You set one, right?
mysql -uroot -p

Other Notes

I noticed that the Homebrew installed PHP didn’t seem to support $_ENV in scripts, instead the $_SERVER array seems to be used – the Macports PHP with CGI support did seem to work with $_ENV. It might be a subtle version difference, I’m actually not sure, and decided not to spend time trying to figure it out. Just update scripts that depend on $_ENV, to use $_SERVER. If someone knows what’s behind this, please share.

So, that should be it, PHP with CGI support and MySQL installed and ready to rock. If I missed anything let me know.