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!
I have a bad habit of being an early adopter. Mavericks? Sign me up! New iPhone, I’m there!
So when Laravel 4.1 was release a few hours ago, I had to jump in and update some apps. Upgradeing frameworks will probably never be as easy as upgrading WordPress, et al., but the changes to the Laravel app skeleton are pretty minor. However, once that’s done, there are few things to watch out for:
Note: as the ‘?’ indicates in the title, I’m not sure if this is the “best” way or even a “good” way. But it’s definitely a different way than Laravel’s regular expression route constraints.
I realized recently that I wasn’t doing a good job of validating the route parameters in my Laravel application in my RESTful URIs, so I started working on a solution.
Though Vagrant (at least with VirtualBox) appears to be semi-broken at the moment under Mavericks, I’ve updated my simple vagrant config for developing with Laravel as requirements keep growing for different projects: Github
By the way, the temporary fix for the vagrant under Mavericks seems to be running the following:
sudo /Library/StartupItems/VirtualBox/VirtualBox restart
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”:
A quick tip for seeing a visual representation of your Eloquent/Query Builder queries in Laravel 4, mostly taken from here:
In your App:before filter in filters.php add:
if ( in_array(Config::getEnvironment(), array('local','test')) and (Input::get('sql') !== null) )
DB::listen(function($sql, $bindings, $time)
I’ve added the logic that first checks to make sure this can only be displayed in the local and test environments, and then if you append ‘?sql’ to the URL, you will see the raw SQL output.
There are other ways to display raw SQL in Laravel 4, including appending ‘->toSql()’ to your Eloquent statements or using a profiling package like this, but I think this is a nice, simple solution.