MySQL is one of the most widely used database servers for web development. It's free, has a wide range of support and is easy to get up and going. Add to this native bindings in just about every language and you've got a pretty powerful databasing tool at your hands. Percona is a MySQL consulting company with a super-awesome distribution of MySQL tuned for performance. For the most part Percona packages should be a drop-in replacement with MySQL. When it comes to system administration tasks I like to throw Puppet at the problem, it makes it easier to replay the configuration down the road and I can track the configuration changes in git. But there's a problem when you change the package name for the defacto-standard Puppet MySQL module. The referencing of the service and the default pid file in the Percona distribution and subsequently the reload following install fails, as well as anything downstream of those items. This was unsatisfactory to me so I poked around to figure out a way to make this work, despite the bug in module. Below is a Puppet manifest with some hackey'ness if you're using Percona that will get it working and allow you to use the rest of the Puppet MySQL module without problems.
If you are a web developer on OS X you probably are sporting your own installation of your database server. If you are running MySQL you might be haunted by strict mode. MySQL has modes as documented here that effect the behavior of various parts of the system. In strict mode values do not get casted between types, which is where I ran into issues. My favorite ORM was passing a boolean true into a tinyint(1) and causing the transaction to abort. This is thanks to STRICT_TRANS_TABLES in my case. The first thing I checked was my /etc/my.cnf to see if "sql_mode" was set in the [mysqld] section. It was not. So I tried setting it to something other than STRICT_TRANS_TABLES and restarted MySQL. No luck, the setting was still on. After a lot of poking around I found out that MySQL for OS X from Oracle ships with a /usr/local/mysql/my.cnf which is loaded on startup. In this file is a sole configuration directive for sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES. Once I commented this out and restarted the server strict mode was off, my ORM worked and I was happy.
Yesterday I talked about running composer on Amazon's Elastic Beanstalk. There it is builtin and works out of the box for you. If you are on OpenShift (my preferred PaaS) composer does not come out of the box. Matthew Weier O'Phinney has posted an article on the steps he took to get composer installing his project's dependencies, and that's definitely a worthy read. However, my deployment hook for OpenShift is a little bit different and I wanted to share that.
There were two things I wanted to accomplish. First, I did not want composer.phar in source control. Second, I wanted to take advantage of composer's ability to cache dependencies to speedup my deployment process up. So here is what I use in my ./.openshift/action_hooks/deploy script:
As a bonus here's a tip about markers... OpenShift will restart Apache and Zend Server with every deployment. You may not want or need to do this. If you don't, simply touch a file to ./.openshift/markers/hot_deply and then next time you push your changes up OpenShift will leave all those services running when it deploys.
Amazon's Elastic Beanstalk is another git-driven deployment service, this time directly to EC2 and RDS instances on Amazon Web Services. It's similar to what Red Hat is doing with OpenShift conceptually.
If you are a PHP developer like myself your first question is probably, will it install my composer dependencies for me? The answer is YES.
Here's the kicker, and quite frankly this does not make any sense to me... If you have stubbed your vendor folder in place, so you've either touched ./vendor/empty or ./vendor/.gitkeep, you are going to have to removed it. Elastic Beanstalk will use composer based upon the presence of a composer.json or composer.lock file, but if it sees the vendor folder it bails out and doesn't execute the install command. Again, I really don't know why this is and I could not find any documentation about it. Yet this exactly what I needed to do to get my dependencies installed.
When we first started house hunting in Indiana I was grateful that MLS listed the total square footage of homes. Back in Pittsburgh MLS didn't do this and we always found that a bit puzzling. In our (original) assessment it was easier to see if a house had the mass we needed for our family based upon this number.
Fast forward and I now realize why it's probably more advantageous to not have square footage on MLS. Having it seems to lessen the requirement for a complete set of room dimensions. Worse yet, there is no consistent way of doing square footage.
We've seen a lot of places that use the footprint of the house, then multiply it by the number of finished floors. We've seen places that appear to have legitimate footage values for livable space, but these are few and far between. We actually saw one place where the sellers had taken the foot print, added that same amount to the total for an unfinished half-basement and then added the same for the second floor that was smaller then the base and then they added the total footage of the garage to it for the size of the bonus room above the garage which turned out to have knee walls and be smaller then the garage. That house's total footage was probably half of what was listed and made for a horrible misrepresentation of the house. It was misleading and confusing. When livable space is actually the metric being used you often also have to wonder which rooms are being counted or not. Taking a list of houses and comparing them based upon square footage just does not give you an accurate representation of what space is available.
All in all there is just no better trade off then a decent set of room measurements for every livable space in the house.