This is a talk I gave at the South Florida PHP Users Group about Nginx, PHP-FPM, Memcached, identifying bottlenecks and other topics related to website performance.

When I started programming in PHP, my hosting setup involved a cPanel installation with Apache and MySQL. This has been the de facto standard for many PHP developers and for the most part I don’t think any of that needs to change. I simply never had to deal with websites that got more than 10,000 visits a day. This all changed when I started work at my current job a few years ago. We sell an educational product that serves a predictable 15,000 requests per minute for 10+ hours/day, every day. Instead of Apache, we use nginx with PHP-FPM to handle this traffic. This is becoming a very popular setup for many companies with non-trivial traffic, but I have also found success with it in my small 256MB Ram VPS. For various reasons, nginx does a better job with memory and concurrent connection handling than Apache. In this post, I want to talk about some of the reasons you might want to go with this setup.

I/O is slow

CPU’s are fast. L1 cache and L2 cache is the nuts. Next in line, you want to live in RAM. Since we can’t fit everything into CPU cache or RAM, we end up going with some sort of disk. You could go SSD, but most systems are some type of spinning platter hard drive. RAID and disk cache speeds it up, but eventually things like fragmentation and load slow down access speeds. We also have swap situations which murder our performance, when the OS has to dump memory to disk to fill it up with new things constantly, and shuffle between them (overburden). Then you have things like network access, which in some cases is faster than disk depending on what they do. One example of that is memcached. If you save processing on a database server that might need to analyze millions of records by pulling the results directly out of memory, you have created huge efficiency gains.

Nginx is also a win for efficiency

Nginx is low-profile, event-driven web server that excels at serving multiple clients due to it’s asynchronous nature. Here a few ways that people commonly use nginx:

• reverse proxy for Apache
• primary web server
• reverse proxy for php-fpm

So what is a reverse proxy?

It’s basically a program that sits in front of other servers in your stack. A request comes in to nginx and it will be forwarded along to other machines. This could be used to load-balance your application servers, perhaps running Apache with mod_php. To understand why we would want to do that we need to understand a bit about how nginx handles connections and resource usage compared to Apache.

Some reasons Apache has problems under load:

• Apache holds connections open until they complete
• Those connections use a thread, and each thread loads all Apache modules
• These Apache threads suck up memory and slow down other threads
• High memory usage leads the operating system into swap
• Swap means that memory has to be dumped to the hard-drive temporarily
• Hard drives are slow, remember?
• Performance degrades across the entire machine
• Most of the time Apache spends in a thread is simply waiting, waiting, waiting

When Apache handles a web request, typically all the modules Apache needs are loaded to handle that connection, e.g. mod_php. This is not really a desirable thing when you are serving static assets like images, JavaScript or css. The reason it is not desirable is that for every connection, Apache forks a new process to handle it (with prefork the default method). This leads to a few problems: more processes = more memory and CPU  Remember that Apache is loading all its modules for each request, so there is a lot of waste here. For a single web page request, you might pull in a ton of assets, meaning Apache has to create a process for each one, and holds the process until the response has been delivered back to the client. This can quickly get out of hand and if the problem is not addressed via some caching layer like varnish, the machine will start utilizing all available memory and go into swap. Swap is bad because we are shuffling things back and forth from disk to memory.

You can tweak Apache to use worker mpm instead of prefork, which changes the way apache runs to more efficiently handle this problem, but then we get into an issue of thread safety. I don’t think most programmers want to be concerned about threads in general and PHP has a reputation for not being entirely thread safe to begin with.

So what does Nginx do differently compared to Apache?

• nginx uses a set number of “workers” (Apache 2.4 has something similar now) and those workers utilize a predictable number of threads.
• when a request is received, the response is asynchronous so the thread won’t stay open until it has something to do. When the web server has a response ready it will be sent back to the client.
• This is called “never block, finish fast”. Think of an event loop in JavaScript.
• Most static assets are buffered to memory so they get served very fast

Nginx handles this problem by using the Reactor pattern, which is another way of saying it is event driven. When a request comes in, nginx passes it off to the appropriate handler, but it does not hold a process or thread open waiting for the response! Only when the response is ready does nginx send it back to the client. Nginx also buffers static files to memory for increased performance, meaning that the hard disk doesn’t have to be touched for some requests. I would argue the majority of requests against a web server are for static assets.

Now if you run nginx in front of Apache then you are essentially keeping Apache busier and it doesn’t have to waste time dealing with asset delivery to the client, thereby leading to more efficient memory usage since less connections have to be maintained as threads/processes. This can be a very effective strategy if you don’t want to completely replace apache in your stack. Nginx does this via proxy pass.

Ditching Apache might not be possible for you, especially if you are doing any sort of client hosting, since we lose the convenience of htaccess files. By the way, htaccess files are another performance killer for apache stacks since the file system has to be checked often (starting to see a theme here? file system is slow). If you have AllowOverride enabled, Apache also tries to read any .htaccess files before serving a page, which is another hook into the file system to degrade performance.

I forego Apache entirely, but we still need a way to handle PHP requests. Nginx does not have a PHP “module” like Apache does. Instead we use the FASTCGI protocol to send requests to a program called PHP-FPM.

But wait, what is FastCGI?

FastCGI is just a common protocol for web servers to talk to other programs.

Is PHP-FPM just mod_php without Apache?

PHP-FPM is a daemon that listens on a port or socket for php requests and it uses a similar worker setup to nginx, in that a main daemon controls several worker threads when FastCGI requests come in. You have a fixed or variable number of “workers” that can execute the PHP code and return a response back upstream to whatever requested it, typically the webserver. People often compare PHP-FPM to mod_php without Apache. That’s not really fair because Apache can also use PHP-FPM instead of mod_php via the FASTCGI protocol.

One advantage of PHP-FPM is that it can run as a seperate user than the web server  This is a win for security since exploits that affect the webserver or php itself are isolated from eachother. Another nice thing about PHP-FPM is that you can reload and restart it without having to touch the web server  and vice-versa. That means that if you upgrade or reconfigure your web server or PHP you don’t have to restart the whole shebang.

At the end of the day, PHP-FPM is just another way to use the same language you know and love.

Memcached

To increase our performance even more, we want to start caching expensive things that our application server needs to do. At work we use a master-slave MySQL setup and generally try to pull reads from our read-only database. This is great for spreading the load, but we also want to be caching database query results whenever possible. In fact, most of the bottlenecks you will run into when trying to scale is the database itself. Tuning queries and indexing are very important, but caching is also something that you should look into. Even lot’s of small queries can add up and it is much harder to scale out a MySQL database than to add extra memcached instances.

Memcached is a proven piece of software often used to deal with this problem and you can get great results by running an instance that reserves as little as 25mb of ram for storage. Memcached is two things, a client and server. The server is an event-driven simple key-value store that runs as a daemon. The OS talks to memcached via a client library. PHP uses an extension, either php_memcache or php_memcached to attach to the native memcached client library, the latter understanding how to communicate with the server daemon.

For connecting to memcached with PHP, you have two options:

php_memcache or php_memcached

php_memcache(d) with a “d” is the one you really want to be on since it is more actively developed. Unfortunately if you are on windows, you are out of luck and you will have to use php_memcache with no “d”. For a really awesome talk about memcached (and APC) I recommend listening to DPCRadio: APC & Memcache the High Performance Duo by Ilia Alshanetsky who is a core PHP developer and one of the maintainers of php_memcached.

APC

When you run a php script, it is first tokenized, then turned into byte-code (opcode) that the php interpreter can run at a lower level on the machine. The idea behind APC is that often times we don’t need to perform this step since the php opcode is mostly that same for many pages. APC will store this compiled byte code, which can dramatically speed up performance.

Running APC is a no-brainer, but APC may need to be tuned a bit to fit your specific situation. Just like any caching, staleness is a factor, so APC has to occasionally check for newer versions of a script. Most of the default settings for APC should be fine for lower loads, but if you have a non-trivial amount of traffic you will want to more closely examine the various settings. I have personally taken down servers with bad APC settings.

Wiring it together

The setup we use at work involves a single front-end web server running nginx, and a number of commodity application servers only running php-fpm. All static assets are served from the web server machine so nginx can keep them in memory as often as possible. When a request comes in for a web page, we will send it off to an application server via round robin. (there are several server selection methods available). The application servers only have one job, serving PHP. This approach allows us to very easily add or remove extra servers as needed.

One challenge with this setup is synchronizing the code. We have a deploy process that will rsync our project code to the individual application servers. For user sessions, we store them in memcached so that we don’t worry about users jumping to different servers on subsequent requests.

Bonus Tips

• Don’t forget to set up your expires headers. See this awesome google presentation on the subject (cache is king).
• Set up some monitoring to measure your results. We use cacti, nagios, and newrelic at work.
• Don’t forget to test that your cache mechanisms are actually working.

Not an Apache Bash

I don’t want this post to come off as an Apache bash,  and I merely present to you these opinions based upon my current experience. I think Apache is a great piece of software and I use it in many contexts. Any piece of software you add to your stack has the potential to perform better with adequate tuning, including Apache. I don’t want to present benchmarks because your situation is going to be different from mine. But the point here is that I have used these technologies successfully and you may achieve similar results, so don’t be scared to explore them. Thanks for reading!

PHP was my first programming language, and my initial exposure to JavaScript was through libraries like jQuery. There were things about JavaScript that always seemed to trip me up in the beginning due to how they worked differently than PHP. Heck there are still some things today that are confusing. I want to share some of the things that I struggled when I started working with JavaScript. I am going to cover the global namespace, this, knowing the difference between ECMAScript 3 and ECMAScript 5, asynchronous operations, prototypes, and simple JavaScript inheritance.

The Global Namespace

In PHP specifically, when you declare a variable function outside of a class (or namespace block) you are essentially adding a function to the global namespace. In JavaScript, there is no such thing as a namespace per se, rather everything is attached to the global object. In the case of the web browser, that is the window object. The other key difference is that in JavaScript, functions and variables are attributes of the global object, which we typically refer to as properties.

This can be troublesome because you won’t get a warning in JavaScript if you overwrite a global function or property and it can actually be quite dangerous.

function globalFunction() {
  console.log('I am the original global function');
}

function overWriteTheGlobal() {
  globalFunction = function() {
    console.log('I am the new global function');
  }
}
globalFunction(); //outputs "I am the original global function"
overWriteTheGlobal(); //this will overwrite the original global function
globalFunction(); //outputs "I am the new global function"

One technique that is useful in JavaScript to ensure that your variables and functions are self contained is to use a immediately-invoked function expression, commonly known as a self-executing anonymous function. I typically expose things to the outside world by passing in a carrier object to the function. This is a variation of the module pattern.

var module = {};

(function(exports){

  exports.notGlobalFunction = function() {
    console.log('I am not global');
  };  

}(module));

function notGlobalFunction() {
  console.log('I am global');
}

notGlobalFunction(); //outputs "I am global"
module.notGlobalFunction(); //outputs "I am not global"

Inside the self-executing anonymous function, all of the global scope is enclosed and we finish by attaching it the the module variable. Technically you could just append properties directly to the module variable, but the reason we are passing it in to the function is to make it explicitly clear what we are attaching our function to. It also allows us to alias the passed in object inside the function. The critical thing here is that we are declaring our dependencies upfront and not relying on global variables, other than the module variable.

You also might have noticed the var keyword. If you aren’t sure of how it is used, a basic explanation is that by preceding a variable declaration with var creates a property on the nearest containing function. If you omit the var keyword than you are saying that you want to assign a new value to an existing variable higher up the scope chain, which may or may not be the global scope.

var imAGlobal = true;

function globalGrabber() {
  imAGlobal = false;
  return imAGlobal;
}

console.log(imAGlobal); //outputs "true"
console.log(globalGrabber()); //outputs "false"
console.log(imAGlobal); //outputs "false"

As you can see, it is quite dangerous to rely on globals in your functions, due to possible side effects and collisions that are bound to occur. Now what happens when we use the var keyword?

var imAGlobal = true;

function globalGrabber() {
  var imAGlobal = false;
  return imAGlobal;
}

console.log(imAGlobal); //outputs "true"
console.log(globalGrabber()); //outputs "false"
console.log(imAGlobal); //outputs "true"

JavaScript hoists the var declaration to the top of the function block, then initializes the variable. This is called variable hoisting.

To summarize: all variables are scoped to a function (which is itself an object), and where you declare those variables with var determines the function they are scoped to. Excluding var will imply global scope for a variable.

Let’s look at how variable hoisting happens:

function variableHoist() {
  console.log(hoisty);
  hoisty = 1;  
  console.log(hoisty);
  var hoisty = 2;
  console.log(hoisty);
}

variableHoist(); 
//outputs undefined (would get a ReferenceError if no var declaration existed in scope)
//outputs "1"
//outputs "2"

try {
  console.log(hoisty); //outputs ReferenceError (no global var "hoisty")
} catch (e) {
  console.log(e);
}

So as you can see, it doesn’t actually matter where you put the var declaration in the function, because the property gets created before the function executes any code. Now in practice, generally you want to put your var declarations at the top of the function, since that is where they end up anyway. It is also totally acceptable to initialize you variables at the top of the function, just be aware of the order of events here.

Functions declared with the function keyword in JavaScript (not variable assignment) also get hoisted. Behind the scenes, the entire function gets hoisted up and is made available for execution.

myFunction(); //outputs "i exist"

function myFunction() {
  console.log('i exist');
}

This wholesale function hoisting does not occur when you use the var form of function declaration:

try {
  myFunction();
} catch (e) {
  console.log(e); //throws "Uncaught TypeError: undefined is not a function"
}
var myFunction = function() {
  console.log('i exist');
}

myFunction();  //outputs "i exist"

Understanding “this”

Since JavaScript uses function scope, the meaning of this is quite different than what you get in PHP, and causes a lot of confusion. Consider the following:

console.log(this); // outputs window object

var myFunction = function() {
  console.log(this);
}

myFunction(); //outputs window object

var newObject = {
  myFunction: myFunction
}

newObject.myFunction(); //outputs newObject

this by default refers to the object a function is contained in. Since myFunction() is a property of the global object, this is a reference to the global object, which is window. Now when we mix myFunction() into a newObject, this now refers to newObject. In PHP and other similar languages, this always refers to the the instance of a class containing the method. You could argue that JavaScript is doing something stupid here, but truthfully much of the power of the JavaScript language comes from this feature. In fact, we can even replace the value of this when invoking our JavaScript functions by using the call() or apply() methods.

var myFunction = function(arg1, arg2) {
  console.log(this, arg1, arg2);
};

var newObject = {};

myFunction.call(newObject, 'foo', 'bar'); //outputs newObject "foo" "bar" 
myFunction.apply(newObject, ['foo', 'bar']); //outputs newObject "foo" "bar"

But let’s not get ahead of ourselves. All we are doing here is invoking the function myFunction by substituting an alternative value for this inside the function by placing the value of the object we want to use a substitute as the first argument. The fundamental difference between call() and apply() is the way you pass arguments to the function. call() will take an unlimited amount of arguments after the first argument and apply() expects and array of arguments as it’s second argument.

Libraries like jQuery perform a lot of magic by invoking things this way. Let’s look at the $.each() method in jQuery:

var $els = [$('div'), $('span')];
var handler = function() { 
  console.log(this);
};

$.each($els, handler);

//iteration 1 outputs wrapped jquery dom element for "div" tag
//iteration 2 outputs wrapped jquery dom element for "span" tag

handler.apply({}); //outputs object

jQuery will often rewrite the value of this, so you should always try to be aware of what this means in the context of a jQuery event handler, or other such constructs.

Know the difference between ECMAScript 3 and ECMAScript 5

For many years, ECMAScript 3 has been the standard in most browsers, but more recently ECMAScript 5 has made it’s way into most modern browsers (IE is still lagging behind). ECMAScript 5 introduced a lot of common sense features to JavaScript and some native methods that you previously relied upon a library for, such as String.trim() and Array.forEach(). The problem is you still can’t rely on these methods being available in browser environments if you have users that are using Internet Explorer.

Take a look at what happens when we try to use String.trim in IE 8:

var fatString = "   my string   ";

//in modern browsers
console.log(fatString); //outputs "   my string   "
console.log(fatString.trim()); //outputs "my string"

//in IE 8
console.log(fatString.trim()); //error: Object doesn't support property or method 'trim'

So in the interim, we can use methods like jQuery.trim to do this for us, which I believe will fallback to String.trim if it is available in your browser for increased performance (native browser implementations are faster).

You might not care or even need to know about all of the differences between ECMAScript 3 and ECMAScript 5, but it is generally a good idea to check out the Mozilla Developer Network (MDN) for function reference to see what versions of the language a function is available in first. Generally speaking, you should be fine if you are using a library like jQuery or underscore to handle this for you.

If you are interested in using a polyfill of ECMAScript 5 for older browser, please check out https://github.com/kriskowal/es5-shim

Understanding Async

One of the things that tripped me up the most when beginning to work with JavaScript code, jQuery in particular is the fact that some operations are asynchronous. There were many times that I wrote code in a procedural manner expecting a result to be returned immediately without realizing it.

Take a look at this broken code:

var remoteValue = false;
$.ajax({
  url: 'http://google.com',
  success: function() {
    remoteValue = true;
  }
});

console.log(remoteValue); //outputs "false"

It took me a while to realize that you need to program around asynchronous calls using callbacks to deal with the outcome of my ajax calls.

var remoteValue = false;

var doSomethingWithRemoteValue = function() {
  console.log(remoteValue); //outputs true on success
}

$.ajax({
  url: 'https://google.com',
  complete: function() {
    remoteValue = true;
    doSomethingWithRemoteValue();    
  }
});

Another cool thing is deferred objects (sometimes called promises), which you can use to program in a more procedural style:

var remoteValue = false;

var doSomethingWithRemoteValue = function() {
  console.log(remoteValue); 
}

var promise = $.ajax({
  url: 'https://google.com'
});

//outputs "true"
promise.always(function() {
  remoteValue = true;
  doSomethingWithRemoteValue();    
});

//outputs "foobar"
promise.always(function() {
  remoteValue = 'foobar';
  doSomethingWithRemoteValue();    
});

You can use promises to chain callbacks in a style that is in my opinion a bit easier to work with than nested callbacks in addition to a host of other benefits these objects offer.

Animations in the browser are also asyncronous, so this is also a common source of confusion. I’m not going to go into detail here, but you need to treat animations much like ajax requests in the way you handle them via callbacks. I’m not really an expert on the subject though so please take a look at the jQuery .animate() method.

Simple Inheritance in JavaScript

Grossly simplified, JavaScript clones objects to extend them, while PHP, Ruby, Python and Java use and extend classes. In JavaScript you have something called a prototype, and every object has one. In fact, all functions, strings, numbers and objects have a common ancestor, Object. There are two things about prototype to remember:  blueprints and chains.

Each prototype is basically an object in itself that describes properties available when creating an instance of an object. The prototype chain is what allows prototypes to extend other prototypes. In fact, prototypes themselves can have prototypes. When a method or attribute does not exist on an object instance, then it is looked for in that object’s prototype, and the prototypes’s prototype, and so on until it finally reaches undefined if no such property exists.

Thankfully, beginners generally don’t need to mess with this stuff at all, since it is easy enough to create an object literal and append properties to it at runtime.

var obj = {};

obj.newFunction = function() {
  console.log('I am a dynamic function');
};

obj.newFunction();

An easy way to extend objects that I use all the time is jQuery.extend()

var obj = {
  a: 'i am a lonely property'
};

var newObj = {
  b: function() {
    return 'i am a lonely function';
  }
};

var finalObj = $.extend({}, obj, newObj);

console.log(finalObj.a); //outputs "i am a lonely property"
console.log(finalObj.b()); //outputs "i am a lonely function"

ECMAScript 5 offers us Object.create(), which you can use to extend from an existing object but you probably need to avoid using this if you need to support older browsers. It does offer distinct advantages to property creation and setting attributes of properties (yes, properties also have properties).

var obj = {
  a: 'i am a lonely property'
}; 

var finalObj = Object.create(obj, {
  b: {
    get: function() {
      return "i am a lonely function";
    }
  }
});

console.log(finalObj.a); //outputs "i am a lonely property" 
console.log(finalObj.b); //outputs "i am a lonely function"

You can get pretty deep into the subject of inheritance in JavaScript but the beautiful thing here again is that you really don’t have to due to the immense power and flexibility of the language.

Bonus Gotcha: Forgetting to use var in for loops

var i = 0;

function iteratorHandler() {  
  i = 10;
}

function iterate() {
 //this iteration will only run once
  for (i = 0; i < 10; i++) {
    console.log(i); //outputs 0
    iteratorHandler();
    console.log(i); //outputs 10
  } 
}

iterate();

The example is contrived, but you can see the danger here. The solution is to declare you iterator variables with var.

var i = 0;

function iteratorHandler() {  
  i = 10;
}

function iterate() {
  //this iteration will run 10 times
  for (var i = 0; i < 10; i++) {    
    iteratorHandler();
    console.log(i);
  }
}

iterate();

This all goes back to our scope rules. Remember to use var properly.

Summary

JavaScript may be the only language people don’t need to learn before using it, but eventually you are going to run in to some unexplained trouble. Other than avoiding your own bugs, learning JavaScript makes a lot of sense these days considering it’s rebirth and widespread availability. This blog by no means attempts to be a complete panacea, but hopefully it will help a few people understand some of the fundamentals before being forced into writing more awful JavaScript code, secretly hoping to get reassigned to a backend project buried in database queries in happy PHP land.

I have a long drive to work, and one of the things I do to pass the time regularly is listen to podcasts in the car. I really enjoy programming podcasts and conference talk recordings, and it’s a really great way to educate yourself on the go. I wanted to throw a shout out to some podcasts that I haven’t previously mentioned on the blog and hopefully turn on a few new listeners.

For reference, here are links to the previous posts:

July 2011 Podcasts for Web Developers, Programmers and Software Engineers

Podcasts for Programmers, Developers and Web Designers

/dev/hell Podcast

/dev/hell

This is probably my favorite new programming podcast, hosted by one of my internet heroes Chris Hartjes and Ed Finkler. This is a mostly PHP podcast, but there are many discussions about other languages like Javascript, Python, etc. Truthfully those discussions are generally presented through the lens of a PHP developer frustrated with the shortcomings of his chosen language. It was fun to listen along to this podcast over the year and hear discussions about Ed Finkler’s MicroPHP Manifesto, and watching Chris try to develop his brand as grumpy programmer, write a book and even stress out about organizing a conference (True North PHP). The other great thing is that since Chris and Ed part of the so-called “PHP Elite”, you get a really nice selection of top tier guests like Elizabeth Naramore, Chris Shiflett, Joël Perras. This is definitely the must-listen podcast for PHP developers, but I think any web developer would appreciate it.

Giant Robots Smashing Into Other Giant Robots Podcast

Giant Robots Smashing into other Giant Robots

This is an awesome new podcast put out by the guys at thoughtbot. It is primarily ruby focused, but I find that the topics covered are interesting to almost any programmer. There are also interviews with various people in the programming industry at various stages in their careers. Notable guests like David Heinemeier Hansson, the creator of Ruby on Rails, help to give even more credibility to this podcast. One of the great things about this podcast is the host, Ben Orenstien. His questions and voice are really thoughtful and he never comes off as pretentious. It’s really refreshing considering the way the ruby community in general tends to suffer from a bit of elitism, at least in the presentation. Most of my favorite episodes was entirely about code and you will often here refrains to “Tell, don’t ask” and other useful design patterns. Spin this one up even if you aren’t a rubyist.

Programming Throwdown Podcast

Programming Throwdown

Programming Throwdown is a podcast built around the idea of discussing a different programming language or developer technology with each episode. Each episode starts with about 20 minutes of banter and soft-talk which admittedly I try to skip, but if you are willing to forgive the hosts enthusiasm and overuse of the word “like” and unabashed “valley speak” you will find some excellent technical knowledge behind these discussions. If I had to imagine, the hosts probably went to the same college and comp sci courses together because you actually can’t tell them apart. In any event, where else can you listen to a podcast about Latex one week, and C++ or Python the next week.

Javascript Jabber Podcast

Javascript Jabber

Javascript Jabber is an in-depth, technical podcast based around the JavaScript language. This podcast is hosted by Charles Max Wood, and features a rotating cast of notables from the JavaScript world. My favorite episode was pretty much a debate between Yehuda Katz (Ember.js, Rails, jQuery) and Jeremy Ashkenas (Backbone,js, underscore.js) about JavaScript MVC frameworks. Other regular guests are guys like Tim Caswell, who is a big deal in the node community. This podcast gets very technical about JavaScript development which to me makes it very attractive and distinct from The Javascript Show, which is more of a news roundup about the happenings in the JavaScript world. Definitely check this one out if you develop with JavaScript.

Hanselminutes Podcast

Hanselminutes

I initially avoided Hanselminutes since I assumed it was strictly a .NET and Microsoft centered podcast, since host Scott Hanselman is a big fish in the Microsoft World. After running dry on podcasts I decided to download a few episodes and I was pleasantly surprised by how well put together this podcast is. I think Scott puts a lot of effort into covering a broad range of topics, everything from interviewing a guy who makes 3d modeling software, to discussing his struggles with Git. Scott interviews all kinds of interesting people from around the developer ecosystem, and isn’t afraid to get personal, talking about his struggles with diabetes for example. The podcast is probably especially worthwhile to listen to if you come from an open-source background since Scott has an interesting perspective considering his experience in the industry.

Herding Code Podcast

Herding Code

While I’m on the subject of .NET/Microsoft focused podcasts, Herding Code is another great listen even for the open-source guys. These guys pump out a ton of interesting discussions on a very regular basis and topics range from ASP.NET MVC to testing and mobile development. This podcast really did a lot to change my opinion about Microsoft developers, who I used to think just played with Excel all day and generated code with wizards. I mean sure, they still do that, but….give the podcast a listen to anyway!

P.S Check out this awesome implementation of Clippy in javascript!

Did I miss anything?

That’s all I have for the moment folks! There are a few podcasts I didn’t mention because I don’t listen to them or I think they are low-quality but please leave a comment if I’m missing anything you like to listen to!

I’m usually not a fan of these posts, but I felt that doing some reflection would be therapeutic for me. Fair Warning: this post is probably going to be very self-indulgent.

In 2012:

• My wife and I had our second baby boy
• My wife and I got married (we did it backwards)
• Finally talking to my grandparents again after a long strained relationship. Forgiveness is a wonderful thing.
• I presented a talk about PHPUnit at my local PHP user group
• I attended 8 SoFlo PHP Users Group meetups
• Adam Culp, Pablo Godel, John Gills and I drank beers with Derick Rethans from 10gen (MongoDB) after his presentation and argued about the difference between a British Pint and an American Pint
• Watched Rasmus Lerdorf speak and even got to ask him a few questions (about short array syntax in php 5.4).  Technically this was December 2011 but I’m still counting it!
• I attended CodeWorks 2012, my first conference - albeit a small one – still great times and very eye opening. I even convinced the boss to shell out for it!
• I helped select talks for  SunshinePHP. I also built a little app to help rate the talks with CakePHP at Adam Culp‘s request. It was and is a great honor to be help out with this upcoming conference. Click here to buy tickets
• I moved into the lead developer position at work (on my team) and have really had some great experiences there this year.
• Made my first wordpress plugin
• Started playing Magic: The Gathering again, via Magic Online and on the iPad and PC via Duels of the Planeswalkers. I used to play this almost 17 years ago when I was around 12-13 years old.

Some regrets and sadness in 2012:

• I regret not giving more talks, although life definitely got in the way
• I wanted to see Robert Martin talk since he was in the area, but missed it
• My co-worker Conrad shipped off to Atlanta! There are special people in life that teach you things from another perspective and Conrad is definitely one of them.
• Election Season wasn’t nearly as exciting as I had hoped (the primaries sucked out all the energy).

Now for this year’s docket. In 2013:

• I will attend SunshinePHP, my first large conference right here in South Florida!
• I really want to go to PHPTek13 in Chicago, which will hopefully be a watershed moment
• Take the Zend Certification Exam for PHP 5.3
• I am giving a presentation about Nginx and Memcache at my local PHP user group
• Spend more time playing Minecraft with my soon to be 4 year-old son. Seriously this is the best.
• Play less games. My Steam collection is about 142 games and growing and I’m not even counting other sources of games. I must have put hundreds of hours into games this year.
• Write more blog posts. In 2012, I only wrote something like 5 blog posts compared to around 22 for 2011.
• Finish more software! (https://github.com/jblotus) Seriously I start something like 1 project per week, and usually throw code in it for a day and abandon it. Truthfully I usually do this to play with new libraries and such but it would be nice to actually release something.

So that’s all I can think about right now. Here’s to the new year! Thanks for reading.

I love programming, but admittedly I absolutely hate setting up local development environments. I have been using tools like Vagrant and Puppet to help ease the pain, but even then I find it tedious to get a quick project off the ground. This inevitably leads to me making some master development VM, but this stuff takes time and can kill an idea before I even lay down a single line of code. Well, what if I didn’t need to bother with that boring stuff anymore? I have been hearing about the Cloud9 online code editor for a long time (based on the ACE Editor) and thought maybe it would be suitable for some node.js development. Little did I know how many features they are packing now for free into this awesome web applicaiton.

Your code anywhere

At first I though Cloud9 would be a simple editor, perhaps a nice showcase of what you can do with HTML5 and some well-written javascript but it quickly became evident that this app was packing a lot of powerful features.

Features at a glance:

• Integrated linux sandbox environment with pre-installed PHP, Node, MySQL, etc
• Inline Shell access (no sudo and some other restrictions)
• Easy connection to GitHub and BitBucket
• Remote, multi-collaborator real-time editing (Pair programming anyone?)
• 512 MB of storage in the sandbox
• Did I mention you can hop on to any computer and start coding right away?

Sounds pretty awesome if you think about it. You can even connect you own server via SSH instead of using the build in sandbox (this is a paid feature).

Is this the Holy-Grail?

Not Really, but it’s close. This is a very exciting product that almost reaches holy-grail status, but it falls short in a few key areas. Occasional stuttering, delays in the terminal and editor tabs are mood killers. Having to wait 5-10 seconds to save a file while in a cycle of test-driven-development is painful, which is something that happened to me quite frequently. You also will miss CTRL-Clicking into a method and other modern conveniences you get for free in editors like PHPStorm, NetBeans, etc.

If you are a VIM person you probably won’t be 100% happy with the responsiveness and let’s face it, you guys hate IDE’s. To be fair you can pull up VI in a terminal window, but there are also some problems there. If you are used to a native terminal client or PuTTY, the provided HTML5 terminal has some quirks, CTRL-C doesn’t work as expected and I also ran in to some issues with my local aliases disappearing.

Let’s use PHP 5.5

Some other complaints are that the built in versions for PHP are a bit low (5.3.3), an I’m not sure there is an obvious way to change this other than building from source. You do get PEAR and PECL pre-installed but I haven’t tried to do anything serious with that yet. It looks like you do have the ability to compile from source, but it takes awhile. I was unable to successfully build memcached but I was able to build PHP 5.5 alpha (in about two hours) although due to permissions issues I had to do something like this:

$ ./configure prefix=$HOME
$ make
$ make install

$ php -v                                                     
PHP 5.5.0alpha1 (cli) (built: Dec 25 2012 15:17:46)
Copyright (c) 1997-2012 The PHP Group       
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies

If you know your way around linux, you will probably have more luck than I did, but your mileage may vary.

Is it FREE?

Well it seems that just like GitHub  you can create unlimited public workspaces, with unlimited collaborators. If you need more than one private project and only want to give your team access, or you want to connect your own VM instead of using the built in sandbox – you will probably want to cough up the $12/month. If you are strictly experimenting or working on open-source there isn’t a lot to lose here.

The Verdict

The Cloud9 team has done a great job removing the barriers to getting a simple idea out the door. I implemented FizzBuzz in PHP using Composer, PHPUnit, and some SPL interfaces and got it all done , and posted to GitHub in about an hour. Since Apache is also installed, this is a really brain-dead simple way to prototype, or even work on non-trivial projects. I haven’t tried the multi-user editing yet, but it actually sounds like a lot of fun. Also, the whole thing is available independently of the online service so you can install Cloud9 locally (check out the GitHub repo).  What are you waiting for? Go sign up and/or check it out locally and let me know what you think in the comments section!

I think the first “IDE” I ever used for web development would have to be Adobe Dreamweaver (née Macromedia). Ok, so maybe it was Microsoft FrontPage, but that shouldn’t really count. Dreamweaver for the novice held the promise of being able to easily create DHTML animations and offered WYSIWYG perfection for creating web interactive pages. All of the deployment you needed was built in (FTP) and you did get some sense that it was the best product on the market for doing web work (in fact it still might be for your average designer). This post is about my experience moving away from the oft-maligned program and some lessons learned in my quest for the perfect IDE.

Ignorance is Bliss

I wrote a ton of PHP code in Dreamweaver. In fact, I learned PHP while using Dreamweaver to edit joomla templates back when I was a “website manager”. I went on to write thousands of lines of code in Dreamweaver for about a year into my programming journey. Eventually though, I started to feel like I was missing out on something. I decided to search for dedicated PHP development software and realized were at least 10 IDE programs available for PHP and clearly Dreamweaver was not among them. I decided then and there that I needed to move forward and ditch my old reliable Dreamweaver.

As a novice, it was an overwhelming experience even trying to pick an IDE. I was writing a large website with CakePHP at the time and figured that I would look around and see what others in that community were using. For the record, candidates included: Komodo, NetBeans, Eclipse PDT, Zend Studio, PHPStorm and a few more. I downloaded a few different programs and had a difficult time evaluating them because after all, how would a beginner know what made for a good IDE? Additionally, some of these programs cost money and I did not have a penny to spare in those days. So it had to be free.

NoobBeans

I settled on NetBeans initially. I had heard of this nifty feature called “code-completion” and some people said that you could use it to auto-complete model class relationships and methods for CakePHP. I had mixed results with that, but in time code-completion in general was quickly becoming something that I could not live without. NetBeans also had built-in FTP and SVN integration. That was neat, especially since I had begun using version control with TortoiseSVN recently (it seemed important to learn). Eventually I found the auto-format code button, and realized my coding style was pretty sloppy compared to the corrections it was making.

I gave NetBeans a daily workout for a good year or two, but then I decided wanted to make mobile apps for a living. After learning that I needed a mac to make iPhone applications, I decided that I would have to start out with android. Of course this required me to learn Java, and also introduced me to Eclipse. Once I started using Eclipse in a Java context, I was starting to feel that net beans was lacking a ton of configuration options that eclipse offered. So I downloaded Eclipse PDT, which is basically a free version of Zend Studio. Now I felt powerful.

The 7th Circle of Hell is called Eclipse

When I started at a new company, I was assigned a pretty low spec machine to do PHP development work on. The codebase I was working on was also massive. Eclipse couldn’t keep up. Things were always building, indexing or validating! I could count on Eclipse crashing at least five times a day. Eventually I began fighting back by disabling validators and automatic project building. I was turning off feature after feature and started to long for the good old days of Dreamweaver.

Once my workstation was upgraded to an HP Intel i7 with 12 gigs of ram, most of my crashing problems started to go away. I also tried several favors of eclipse like Aptana, and finally ended up using Zend Studio on a trial basis. Zend Studio seemed at least a little bit better than Eclipse PDT, because it had refactoring features and a more advanced formatter amongst other things not included with PDT. I found zend studio to be a bit more stable, but ultimately the refactoring featurs never seemed to work for me, and the code formatter was just crappy. Now I found myself spending more time using the backspace, enter and delete keys to correct sends formatting wonkyness than actually coding. That is hyperbole, but I was starting to see why all the Ruby guys used Textmate or vim.

It’s just a glorified text editor

I hate vim, and I’m not on a mac so textmate is out. So along comes Sublime Text 2. I started using Sublime Text casually on some of my hobby projects and I started to understand why people preferred a lighter text editor. Sometimes I just felt like the editor was reading mind and I never had performance issues. Still as much as I enjoy Sublime Text, I didn’t find that it gave me a productivity advantage overall. I personally don’t want to hop around my computer for different tools to get my code tested and deployed, which I don’t do as often with an IDE. Additionally, the speed of searching for code in my IDE is lightning fast and I could never achieve those results with a text editor.

So I was stuck with Zend Studio and i was afraid. I knew I was one corrupt workspace away from disaster. But it wasn’t all bad. I had a few macros, a few useful plugins and my workflow was sufficiently fast. I could live with this. Things went along fine for months, until I went to a meetup of the South Florida Php Users Group. There I was introduced to PHPStorm. Just another IDE I thought to myself, as I debated the merits of switching from Eclipse. I was so damn wrong.

Salvation is a (PHP)Storm

I tried out PHPStorm for a free 30 day trial. Several ex-eclipse users can be wrong right? Besides I had some side projects to hack on and eclipse was borked on my laptop. Once up and running, PHPStorm made me a quick convert. Everything just worked better. The code completion was faster and more accurate, the settings easier to manage. Unlike Eclipse PDT, Zend Studio or Aptana, it didn’t feel like someone had grafted to php support onto a IDE written for programming in Java – although I’m sure PHPStorm is entirely based on IntelliJ IDEA.

Features starting popping up all the time that would pleasantly surprise me: Zen Coding support, inline string language injection, doc block validation and more. PHPStorm had all of the stuff Zend Studio gave me, but is mostly better implemented. Stability is also vey good, as I haven’t seen a crash yet in two months. My i5 laptop did have a bit of sluggishness on a really large project, but I tweaked a few settings and everything seemed reasonably fast again. I still run in to some annoyances with the code formatter and some incorrect code syntax warnings, but therein lies another lesson. I don’t think an IDE or any tool for that matter is free of blemishes.

Always end on a Cliché

Overall I think I will stick it out with PHPStorm for awhile. Looking back I realize that IDE’s have been a constant annoyance and yet have prompted so much growth and development in my skill level. I just plain work faster and write better code with an IDE. I also think that the problems I have ran into with IDE’s are true about software in general. We search for better solutions and always fall short.

I am reminded of a famous quote:

Perfect is the enemy of good –Voltaire

The reality is that I could probably still get a lot done in Dreamweaver, but it is the journey on the quest for improvement that can help us truly master our craft.

I recently presented on one of my favorite topics at my local PHP user group, the South Florida PHP Users Group. The talk was meant to be an introduction to PHPUnit - I chose to dedicate some time to describing the need for automated testing. I think many PHP developers have a hard time seeing the benefit of unit testing. My main point was that developers already do tons of manual testing, so why waste all those precious hours when you could simply get the computer to handle it for you.

These are they slides, feel free to grab them from slideshare. I will gladly answer any questions people have.