Goodbye Wordpress, Hello "Brewski"

Since most of my work is "in-house" and won't ever reside on Github, and because needed to project that I would start using right away, and because Wordpress can be a PITA to work with at times, I decided to build my own [Laravel]( blogging system. It's still very rough, un-stable, and written by a hack (me), but it's now powering this site. Having a personal project that I'm using right away, and with the code exposed on Github, is a nice motivator to keep working on it - so after many false starts, I think I've finally found a personal project that will keep me interested for a while.


Current Features:

  • Laravel-based
  • Themeable
  • Basic Disqus integration
  • Basic Social Media integration (in-progress)
  • Responsive Admin (bootstrap)
  • Markdown-based editor
  • Page caching
  • Basic Search
  • Categories & Tags


  • Pages
  • Unit Tests
  • Lots of code cleanup/refactoring Github:

My “toolbox” re-visited

Every developer’s toolbox changes and evolves over time, even the old Reluctant Developer’s. In fact, I go through periods where I spend way too much time trying to find the next app that’s going to get me over the hump from hack to rock star. I haven’t found it yet because it doesn’t exist, but it’s still interesting exchanging some of the tools in the toolbox now and then, and sometimes finding that app that really makes a difference in one’s workflow.

So here’s a list of what I’m using now, along with a brief (sometimes very brief) explanation of “why”:

Operating System: OS X

This hasn’t changed in six years and will not be changing anytime soon. Aside from the aesthetics and being an Apple fanboy, OS X is just easier to work with when developing in languages like PHP that are being deployed to *nix servers and depending on things like Git, MySQL, etc. It’s a pretty seamless transition between working in the OS X terminal and an Ubuntu box terminal.

Code Editor: Sublime Text 3

Once you install Package Control and master the keyboard shortcuts, there’s no looking back. Extremely fast (start-up and searches), lightweight, packages for everything. Multiple selections = awesome. Got rid of Dreamweaver years ago (flaky). The Eclipse-based editors just seem really bloated to me. I used to use Coda, but after waiting for Coda 2, it became apparent that it was trying to do too much and was attracting it’s own bloat.

PHP Framework: Laravel

It’s just getting bigger, stronger, faster. I’ve deployed 2 apps now using Laravel 4, and though I still have a lot to learn, I’ve had no regrets in moving to PHP and to this still “new” framework.

CSS Framework: Bootstrap

 I’m not a designer and never will be. With bootstrap, I can put something out there that isn’t ugly, is consistent, and is responsive with very little effort.

MySQL Administration: Sequel Pro

Used to be a little buggy, but has come along nicely. Handles imports/exports every easily. Nice custom query editor.

Version Control: Git

Not an expert by any means, but Git is very powerful, yet pretty simple to use once you get the basics down. Though I do use SourceTree occasionally when I forget how to do certain things in Terminal, most of my interaction with Git is via the CLI:

git status
git add . 
git commit -am 'message' 
git push test

That’s pretty much it on a daily basis. Projects git pushed up to Bitbucket for safe-keeping and sharing with other team members. I use git hooks to do things like resetting file permissions after a push to test/prod, empty caches, run Laravel migrations, etc. I also use git tags to maintain and display the application versions in the footer of apps.

Development Environments: Vagrant]/Virtualbox 

I recently gave up on MAMP after running into several issues with not having identical environments between dev/test/prod. I decided to commit to a [simple Vagrant setup]( using a single shell script to set up each environment.

FTP client: Transmit

 It works. Has a nice sync view between local and remote. Syncs favorites via Dropbox or iCloud.

That’s it. I don’t use anything else enough to warrant a mention.

Migrating to Cloud VPS Hosting. What to do with email?

I’ve started looking moving the sites I’m hosting on a Hostgator reseller account to a [Digital Ocean]( cloud VPS. I’ve already moved over my personal sites to a the base $5 VPS. The lone issue is what to do with the one client I have who uses their domain’s email thru Hostgator (as well as future clients). I set up all of my other clients (including myself) with Google Apps email for their domains prior to Google no longer offering a free version. I’ve never set up or maintained mail servers before, so I’m not excited about the prospect of doing that now, as critical as email is for most businesses. I wish there were cloud hosting services that could spin up a small VPS just for email after entering a domain name and making a few DNS updates. Maybe there are and I just haven’t found them yet. I could just maintain a Hostgator account that only handles email for multiple domains, but seems a bit klugy.

Why I’m moving from Coldfusion to PHP

People have spent a lot of time both predicting the death of Coldfusion, as well as refuting that assertion. Of course, it’s not really “dying”. It’s still very popular in government and higher education (I don’t have any stats to back this up, but this is what I’ve observed). Everywhere else, however, it’s market share appears to be small compared to PHP, Rails, etc. I blame Macromedia/Adobe for not providing a free, open-source version and for not marketing it sufficiently. Railo has filled the open-source hole, but it’s too little, too late.

Laravel 4 Pagination with Column Sorting

Updated (4/24/2014) to address possible SQL injection attempt with $order and/or $sort input.

It took a little effort, but I finally got Laravel 4′s pagination class working with the ability to sort by column. Posted here so I don’t forget.

$widgets = Widget::all(); 
$allowed_columns = ['column1', 'column2', 'column3']; 
$sort = in_array(Input::get('sort'), $allowed_columns) ? Input::get('sort') : 'delivery_date'; 
$order = Input::get('order') === 'asc' ? 'asc' : 'desc'; 
$widgets = $widgets->orderBy($sort, $order); 
$widgets = $widgets->paginate(20); 

//include $order and $sort when retrieving your layout/view 
$this->layout->nest('content', 'widgets.index',array( 'widgets' => $widgets, 'sort' => $sort, 'order' => $order) ); 

//Display the pagination 
//I tried using appends() first, but could not chain multiples 

{{ $events->addQuery('order',$order)->addQuery('sort', $sort)->links() }} 

//Column header 
//Using Twitter Boostrap up/down arrows
    <a href="{{action('[email protected]', array('sort' => 'status', 'order' => 'asc'))}}">
        <i class="fa fa-chevron-up"></i>
    <a href="{{action('[email protected]', array('sort' => 'status', 'order' => 'desc'))}}">
        <i class="fa fa-chevron-down"></i>



6 reasons not to use a PHP Framework

  1. You are immortal, and therefore, will always be around to help other developers understand and extend your code.
  2. You have no life, and therefore, don’t mind spending all of your free time writing code comments and documentation that would already be written in a good framework, so other developers after you (or with you) can also write code for your app(s).
  3. You are coding an app that will be one of the most visited sites on the web (all by your self and for eternity if #1 and #2 are true), and therefore, can justify the potential nanoseconds saved by not having the “overhead” of a framework.
  4. You are a web security god and are way smarter than the collective group of developers who code and test good frameworks for security issues.
  5. You want to spend all of your time re-inventing the wheel by writing your own RESTful routing implementation, ORM, templating engine, etc. etc. instead of what a good framework provides. Or maybe you skip the ORM part and just re-write larges parts of the app when you need to switch DB engines.
  6. You don’t do “deadlines”.

If these reasons don’t apply to you, I recommend checking out Laravel, or better yet, the Laravel 4 beta.

Moving to VPS hosting and dealing with email, Part 2

A while back I wrote a post about the dilemma of moving away from shared hosting to VPS (unmanaged) hosting and dealing with domain-specific email addresses. I’ve been migrating a number of web sites to a “droplet” with Digital Ocean. There are many benefits to this:

  1. Complete control over the environment - pick your own Linux distro, db engine, web server engine, PHP version, etc.
  2. Cost – For $10 on Digital Ocean, you get more RAM, CPU and storage than for most VPS servers for $30 or more.
  3. Flexibility – at Digital Ocean, you can spin up new “droplets” in about a minute, using a snapshot of a current droplet if you need to scale, etc.

But there are also some downsides:

  1. You’re on your own is something goes wrong.
  2. You need to come up with your own backup strategy.
  3. There’s no wysiwyg for creating virtualhosts, databases, etc., so you must be friends with the command line.
  4. Email. If the domains you are moving over include type email, that last one can be a real problem. There are lots of horror stories about trying to setup and maintain your own email servers and I just don’t want to deal with that. Services like Rackspace offer email hosting for $2/mo., but with a minimum of 5 addresses, it’s really at least $10. Other services I looked at were often more expensive.


The simple solution I’ve found is maintaining a shared hosting account on Hostgator for email. As I migrate sites from a Hostgator reseller account to Digital Ocean, I’ve already determined that one legacy ecommerce site won’t run on PHP 5.4, so it’s moving to a shared “baby” account. On this account, I can create as many addon domains as I want, setup email addresses for those domains as needed, then in the Digital Ocean control panel, create MX records pointing back to the Hostgator where account is located (something like

 The Hostgator “baby” plan is currently $7.96 month-to-month, which gives me unlimited domains, and in turn, unlimited domain email accounts. It also give me a place to put sites that don’t support PHP 5.4+ when needed. If you need to, you can also get webmail working by redirecting something like mail.{yourdomain}.com back to the hostgator webmail client.

A few Laravel 4.1 Update Gotchas

Update (12/12/1013)

One of the headaches with the upgrade to Production was waiting for ‘composer update’ to run while the site was down due to the skeleton and framework being out of sync. However, I’ve just realized that I should be pushing my composer.lock file to prod and just running ‘composer install’, which is much faster and makes sure your packages are in sync across environments. Doh!*

“Essential” Sublime Text 3 Plugins

Everyone likes to publish their favorite or “essential” Sublime Text plugins, so I’m joining the party. These are all Sublime Text 3-compatible plugins. I have a number of other plugins installed, but these are the only ones that I would immediately miss if I did a fresh install of ST3 (along with the Ubuntu Mono font.

Laravel Application Logs and Logrotate

Depending on usage, errors, and what you’ve chosen to log, the Laravel application log(s) can really grow after a while. With Laravel 3 and initially with Laravel 4, new log files were created every day by default, which kept them small and easy to search, but now Laravel 4 defaults to a single log file (which I prefer). Logrotate is a common utility on linux servers to handle the backup and rotation of server logs (Apache, syslogs, etc.) and it’s really simple to add additional logs/folders for Logrotate to handle. There’s a nice Digital Ocean tutorial for using Logrotate on Ubuntu 12.10, but here’s a quick and easy run through on how to use Logrotate with your Laravel logs: