Thoom Technologies

OS X 10.9 will ship with PHP 5.3

IntelliJ IDEA is the base for Android Studio, the new IDE for Android developers | JetBrains Company Blog

JetBrains is one of the best developer tools companies out there IMO. I have happily paid for PHPStorm and RubyMine out of my own pocket as the apps are just worth it.

Ruby 1.9 and the SSL error « Martin Ottenwaelter

If using Homebrew instead of port:

Recently, I've been looking at various deployment strategies. I've spent a lot of my career doing some configuration management, mostly out of necessity where I've been the lead developer on a small team. Over the years, I've written several deployment scripts. For employers, they've always been built on top of SVN and Fabric. Since I didn't want to use SVN for my personal projects but was familiar with Fabric, this morphed into a project called Fabox, which used Dropbox as a VCS, and Fabric as the CLI to deploy the code. I've talked about Fabox before. I used it for awhile but it was too involved for my simple personal projects (Fabric was overkill for my single-server environment). I've also soured a bit on Dropbox lately, since their customer support has been completely non-existent.

After Fabox, I wrote a PHP-based deployment server called Giply. It is built on top of Git, and utilizes a common feature with popular Git hosting services Github and Bitbucket where you can POST a payload to a URL. As a web service, Giply consumes these payloads and updates the Git repo automatically.

I took the concepts I learned while writing Giply and vastly improved it with Ripple. Ripple is built in Ruby and includes basic authentication support, easy restoration to previous deployments, and a full featured CLI. It includes a web service like Giply, but it can also be completely managed through the console script.

Since I've begun using Ruby for all of my personal projects, I find it really great. Obviously if you don't have your server environment set up for hosting Ruby (specifically Sinatra), it would probably be a more complicated setup than you'd want. This is the only area where Giply excels. Giply is dead simple to use in a server environment if you have a LAMP stack already created.

There are obviously many other ways to deploy code. Ripple has worked for me in my single-server, no fuss environment. When I want to update the server code, I just push to my Bitbucket repo which POSTs to the Ripple URL I set up in Bitbucket and the rest is handled automatically. It will update projects written in any language, but I've added hooks for Bundler in Ruby and Composer in PHP since I use both in my side projects.

For multiple-server environments, there are many options. If you want your scripts written in a particular language, you have several popular options: Fabric (Python), Capistrano (Ruby), and Phing (PHP). These projects all work using SSH to connect to the servers they manage. I've personally used Fabric the most, and wouldn't touch Phing unless I was paid to. Since I love Ruby, I want to try Capistrano but haven't had the need.

With the launch of Mountain Lion and after suffering a hard drive failure, I decided to investigate other options for my local development environment than using MAMP. MAMP has served me well over the years, but considering the number of visitors to my MAMP + Lion tutorials, it's obviously not as easy to use as a LAMP server.

Virtual machines are great. I know many people that use commercial products like Parallels and VMWare Fusion to run Windows instances alongside their OS X environments. I'm not here today to compare the various products, just know that for me, the open source VirtualBox more than adequately fills my need.

After discussing my VM desires with some other developers I work with, I discovered that Shared Folders were the killer feature I needed.

Shared folders allow me to take my ~/Sites directory and map it to the /var/www directory on my LAMP-based VM. For the most part this has worked well for me. Obviously, though if all was well, I wouldn't be writing this post.

I've got some code that generates cached templates. With some recent changes I made to an underlying templating engine I'm working on, the engine always creates cached files, but if you are in a development environment (or debug state), it will just overwrite the files with every request.

This led to a problem where the permissions of my mounted folder prevented me from writing these critical files to the shared folder. I got to a point where I could create the file the first time, but the template could not overwrite the file on subsequent saves.

Doing some searching led to a post on the ubuntu stack exchange, which led me to the correct solution. It's different enough (at least for my setup) that I wanted to chronicle the changes I made.

Since I am mounting a folder that needs to be written to by my Apache user, I needed to set up the mounted point so that it mounts being owned by www-data. To find this information, on the VM command line, I typed:

$ id www-data

This returns the gid and uid of 33 for my VM. Using this information, I was able to update my rc.local file so that the line I use to automatically mount my shared folder reads:

sudo mount -t  vboxsf -o umask=002,gid=33,uid=33 www /var/www

After doing a reboot, the shared folder now mounts using www-data as the owner. Now I can write and overwrite to my cached folder without problems!

You know you're a nerd when you:

Have your own linux server

Name that server after a nerdy cultural icon like Doctor Who

Take the laborious process of updating your Ubuntu MOTD so that you can have awesome TARDIS ASCII art greet you whenever you SSH

» Great article articulating what I've experienced recently.

The MVC Paradox – Bradley Holt

» This article is a great read and something I've been pondering myself recently. The author references the Slim micro framework which, at least from a cursory glance, is very similar to Silex. I love Silex for the same reasons he mentions Slim:

There is very little boilerplate code involved in handling a User Agent’s request. Minting and handling new routes is incredibly simple. Placing your entire front-end application layer in one file may seem absurd at first. However, it has the nice side-effect of making it painfully obvious if you start to handle domain logic outside of your Model layer or if one route is doing too many things.

PHP, Sessions, __sleep, and Exceptions | Justin Carmony

I had a similar problem not too long ago. My solution was to call:

register_shutdown_function('session_write_close');

Exclusive: Google leans on developers to use payment service | Reuters

» I've got conflicting feelings on this one. As a developer, I've encountered severe limitations dealing with Apple's in-app offerings, especially as it relates to our subscription services. It's been nice not having to worry about similar problems with Android, where we continue to use Paypal.

If it becomes required to use Google Wallet, we'll have to support Apple's in-app subscription for iOS, Google Wallet for Google Play, Paypal for web, and ??? for Amazon Kindle.

I was working on some personal projects the other day, and I wanted to add my code to version control. I've gotten so used to ensuring that my code is backed up (primarily using SVN) that it makes me nervous to only rely on Time Machine for my backups.

While I was investigating free/cheap svn and git solutions (github was not an option because I don't want a public repo for this work), I realized that I had the perfect backup solution already: Dropbox. I'm sure I'm like most people and have at least a free Dropbox account. If not feel free to get a free 2GB account using this referral link and get an extra 250MB.

Why Dropbox?

Dropbox is a popular way to share files across computers and mobile devices. I have had an account for years and appreciate its simplicity. I have several other people that I share folders with and use it frequently to move files to my iPhone and iPad.

What you may not know is that Dropbox comes standard with a 30 day version history. This means that every time you save a file, Dropbox will keep a copy of the old version available for you for a month. If you want, you can also upgrade your account to have unlimited version history but for most use cases I think 30 days is plenty.

Since I'm the primary or sole developer on many of my side projects, this simple versioning system was perfect for my needs. I don't anticipate needing anything like tags or branching, though honestly it wouldn't be hard to just create a copy of the code and stick it in another folder for a pseudo-tagging system. (See the deployment section for an example of how this might work).

Using Dropbox as a Deployment tool

After the initial idea of using Dropbox as a VCS, my thoughts went to using it as part of a deployment tool. One of my areas of expertise involves configuration management and deployment. Since most of the code I've worked with used SVN, I've written several deployment tools based on it. I figured that I could build a similar system with Dropbox and my favorite deployment tool: Python's fabric.

Dropbox on the server

Setting up Dropbox on my server was pretty simple but required a little bit of preparation since I had very specific goals.

Only sync specific folders

Always have an up-to-date copy of code

Enabling specific folders

There are a few ways to synchronize specific folders with Dropbox. The easiest way, and the way that I went is to create a new Dropbox account. Then I share the folders I want on the server with this new account.

Now when I installed the Dropbox command line client, I attach it to this new account. The great thing with using a separate account is that I can use the account to store backups of my deployment bundles. This keeps the bundles out of personal Dropbox, but also allows me to potentially share the backups with other web servers.

Up-to-date code

Dropbox provides a nice python script to manage the daemon. If you are using Ubuntu, you can enable autostart simply:

python dropbox.py autostart

Using Amazon's Linux, you can use cron to enable the daemon on start. Just add the following to your user's crontab:

@reboot $HOME/.dropbox-dist/dropboxd

Deployment tool

The deployment tool that we're going to build is based on Fabric. Since the set up right now is pretty basic, I'm not using much of its power, but by building on top of it, I can extend it easily as I need.

Install fabric

Since I'm currently running on Amazon Linux, I'll explain what I did. Ubuntu/Debian installs will probably differ.

To install fabric, we're going to use Python's easy_install. We need to do the following:

yum install gcc python-devel easy_install fabric

Fabfile.py

We need to create a fabfile.py wherever we plan on running fabric. Since I am just creating a simple local deployment, I want my fabfile to do the following:

Present a list of web applications available for deployment

Create a tar of the application I want deployed with a unique identifier

Add the tarred files to my Dropbox server repo

Present a list of tarred files available for deployment

Create a backup of the existing code that is easy to rollback

Move the tarred code to the correct location

Perform application specific tasks

Warm-up any caches

Create any symlinks

Repair permissions

Deployment

Rather than explain all of the features of my fabfile, I've posted it to my github for download and tweaking. I've tried to make it generic enough to where you can just put the file in your Dropbox user's home folder and run it.

Any of your personal application options would go into the _deploy function.

Deployments are pretty simple. It is currently a two step process:

fab tag fab prod deploy

Tag will take the folder you want deployed and create a tarred gz file. Deploy will take the tarred gz file and put it in the /var/www directory along with creating the backup, etc. There are a few other options available. just type

fab help

Since I have started using Symfony2 on some projects I have been meaning to install the intl extension that Symfony recommends you install. I have tried several different methods, but believe that the one I listed below is easier and makes less of a mess than others.

First, get the ICU libraries. Then expand them and build the library:

tar xzvf icu4c-4_8_1_1-src.tgz cd icu/source ./runConfigureICU MacOSX make sudo make install

If you have followed from my previous steps, you should have the php headers installed in the standard MAMP directory. We need to go to the intl ext folder:

cd /Applications/MAMP/bin/php/php5.3.6/include/php/ext/intl

From here, let's build the intl.so file that we need to enable the extension:

phpize ./configure --enable-intl make

Now we just need to copy the extension to the correct location and add an entry to our php.ini file:

cp modules/intl.so /Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ echo "extension=intl.so" >> /Applications/MAMP/bin/php/php5.3.6/conf/php.ini

In previous articles, I upgraded my computer to Lion and took the time to install MAMP 2. I discovered while using some Zend Framework components that prior to MAMP 2.0.2, there was a bug with the iconv functions. This bug basically caused several pieces of the framework to timeout.

I had unfortunately installed MAMP 2.0.1, so I needed to update to the newest version so that I could again develop ZF-based applications on my local environment.

While following the previous MAMP tutorials I wrote, I realized that there are several changes to the default configuration that I needed to keep backups of so that I could make the same changes on the new version... MAMP apparently just copies over the old directory completely, it doesn't make any intelligent updates (so you could lose VHOST, PHP, etc changes).

I kept the following backups:

/Applications/MAMP/conf/apache/httpd.conf

/Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

/Applications/MAMP/bin/php/php5.3.6/conf/php.ini

» I have several servers running on Ubuntu 11.10 and yet I only see this bug on one of the servers; on that server, I get the AWS CloudWatch messages at least once a day!

Since the site was just a small one, I figured it'd be ok to go with the latest and greatest Ubuntu image. I'm really beginning to regret that decision!