Summer of Learn

For various reasons, the past 2 months or so has seen me experimenting with a whole lot of new techniques that I had never previously explored. This also happened last Spring. I want to make this an annual part of my life and so I now introduce the Summer of Learn. Each summer, I will pick a variety of technologies that I am vaguely aware of and make an attempt to get my feet wet. These technologies can range from entirely new languages to new features within languages I already use.

Some of these technologies are ones I have been aware of for some time, but not harnessed until recently, while others only came to my attention in the past few weeks. Even if I don't stick with them for very long, they have all changed how I look at programming in some way.


SASS is a CSS preprocessor that I began to use about a month ago. I first heard about it from a coworker many years ago but never got a chance to try it. I spoke about it in a previous entry, and am now completely a SASS convert. I may stray to other preprocessors like LESS, but I will never go back to pure CSS again. Being able to handle nested rules, variables and mixins is an amazing tool that I can't do without. I just need to remember to turn off 'compass watch' before doing a git merge/rebase/checkout. I've hit more than a few conflicts when those two don't play nice together.


While my recent doubt regarding PHP are not over, I still do work on advancing my skills within PHP and have adopted the PSR-2 formatting standard. The initial draw was the PSR-0 autoloader conventions, and I began to think about the advantages of using an established formatting guide. While I have been very strict with my formatting for years, I tended to follow my own style that was similar to OTBS, a K&R variant. I'm going to shift towards PSR-2 because, while it does not entirely match with my preference, it appears to be gaining traction within the community. It would also be nice to simply tell a coworker to use PSR-2 and not have to explain all the rules to them.


Composer is a PHP tool for managing external vendor libraries. While I have yet had a chance to fully implement it due to incompatibility with my current site, I did like what I saw. Through a simple .json file, you can specify what libraries and versions to install and it will manage the dependencies, including autoload. The only other PHP package manager that I have used is PEAR/PECL, which has a very distinct downside in comparison with Composer - managing multiple sites with different library versions is much easier in Composer. I will use it in future projects for sure.


With my work on Fusion coming to an end, I am moving on to my next game project and this one will be powered by cocos2d-javascript. I began to use the framework last week and am finding it much easier to deal with than the hacked together framework powering Fusion. In particular, I like the layers/scenes setup, the event handlers and the CommonJS spec for including other files. I've just about completed my breakout clone, and then I can move on to the actual game that I am building on cocos2d-javascript.

PHP 5.3 / 5.4

I'm putting both 5.3 and 5.4 here because only in the past few months have I really made use of the new features of PHP 5.3, and I simultaneously jumped ahead to 5.4 to not have the same issue happen there. Some of the new features that I am using are anonymous functions, the closure-ish "use" keyword, namespacing, the built-in development server, array literals and shorthand ternary statements. I'm still a bit up in the air on the development server, and haven't found much use for the shorthand ternary statements. But I'm trying to jump into 5.4 early, rather than waiting until 5.5 is out before exploring 5.4's features.

As of right now, my favorite new toy is anonymous functions and the "use" keyword for array filtering. It is much, much easier than the awkward create_function function or the old callback syntax, and "use" gives me a lot of flexibility with variable scoping. It's not a proper closure, and explicitly naming every variable to keep in scope could get awkward, but it's a significant improvement over 5.2.


If you've kept up on security trends, you are familiar with bcrypt. Sadly, I only recently began to use it. I've known for years that password hashing and salting is the way to go, but I rolled my own hashes and used an efficient, quick hash like sha1 to keep things secure. After LinkedIn's breach, the web was buzzing with talks of security and best practices and in the midst of that I shifted from my own salted sha1 to bcrypt. The shift was painless, since I already had tools in place for shifting hashing algorithms since I had to transition once in the past.

I wish I had been using bcrypt earlier, rather than rolling my own hashes. I'm typically not one to reinvent the wheel, as I prefer to use established frameworks or libraries to handle basic functionality. I'm not sure why I reinvented the wheel on this one, but I am glad I finally stopped relying on my own scripts for security and instead implementing some well tested community scripts.


Just like with bcrypt, PHP 5.3 and SASS, I admit I'm a little embarassed to say that I first began messing around with PDO in the summer of 2012. SQL injections are an extremely well understood attack, and I have made efforts to keep my queries clean through tools like mysql_real_escape_string. I knew that prepared queries existed, but for some reason I continued to use the mysqli library and relied on my own parameter handling to process data before giving it to SQL. Now, my entire site runs on PDO and uses parameterized queries for security.