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).
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).
Makes your code like pretty and more readable by lining up selections based on “=” “=>”, etc. Great for arrays.
Unobtrusive display of uncommitted changes in the gutter (next to line numbers).
- Trailing Spaces
Highlights and trims unused whitespace at the end of lines.
Gives you way more options for dealing with files in the sidebar. I just wish I could figure out how to delete a file with shift+delete.
Highlights errors in your code as you type.
- Laravel Blade Highlighter
Provides color-coding for Laravel’s blade templates.
I’ve really wanted to like other editors, and there appears to be a big push toward PHPStorm in the Laravel community right now, but ST3 is just too fast, too pretty, and too customizable for me to change.
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 restartCredit: http://www.stumiller.me/fixing-vagrant-osx-mavericks-update/