So in this article I’m going to explain how to test every route in a laravel application. I usually name all the routes in my application, so essentially, every route in my application has some sort of sanity test.


Lately, I was given the task to write some php classes with Laravel that make use of Zencoder api. The way Zencoder works is I create a new encoding job and during that request I tell Zencoder emails and url locations to send notifications when that job is finished.


ETags PHONE HOME?! No. So what are ETags? Wikipedia has this to say:

The ETag or entity tag is part of HTTP, the protocol for the World Wide Web. It is one of several mechanisms that HTTP provides for web cache validation, and which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. ETags can also be used for optimistic concurrency control as a way to help prevent simultaneous updates of a resource from overwriting each other.


Let’s say you are running a report for the user. You generate some temporary file to give to the user and now you have this zombie pdf file sitting out there in your /tmp directory. How do you clean it up? Why not do it directly after you serve to the user? Here are a couple of options. The first option just cleans up the file after the application has served the response.

1
2
3
4
5
6
7
8
9
10
11
Route::get('get-file', function()
{
$filename = storage_path() . '/testing.txt';

App::finish(function($request, $response) use ($filename)
{
unlink($filename);
});

return Response::download($filename);
});

After kicking the boot around for a while I finally decided to re-factor the asset pipeline. The functionality is all in all the same but the code is easier on the eyes. However, I did bring in a lot of new features.

  • Config allows you to control caching interface
  • Config allows you to control directives
  • Config allows you to control which environments are concatenated
  • Config allows you to control mime types so you can combine javascripts and stylesheets in a single folder
  • Use a sprockets parser and generator to create the Rails-style asset pipeline functionality
  • Use relative paths in the manifest files
  • Use Laravel event listener to alter the configuration of the pipeline after package boot/start up
  • Use caching to speed up local development when using a lot of pre-processors (i.e. coffee, less, sass)
  • Use assets:generate to create static files in public/assets directory.
  • Completely customize the javascript_include_tag, stylesheet_link_tag composers
  • Completely customize the AssetController class

Well, I attempted to create a guard/grunt prototype for php. I attempted and failed. Why did I fail? The technology just isn’t there yet. I am going to have to re-think the architecture if I go any further.

I was using pcntl_signal to determine when an application shuts down, so that I could terminate any external processes that had been spawned by guard. One such process event handler was the livereload-protocol I implemented in php which via web sockets notifies any connected clients when files were changed on the server. Similar to how grunt watch works with livereload.

The problem is that pcntl_signal doesn’t work in Windows. Thus, I stopped working on this.


So a few months ago, I remember having lunch with Taylor at Genghis Grill and he was talking about maybe doing a video series to make money. Travis and I both suggested he write a book on Laravel. Heck, I even promised that I’d buy, so here we are a few months later and he has his book out. I’ve purchased the book, but haven’t gotten to read it yet.