I began writing this article months ago when I started researching standing desks. I started writing an article and realized, I should probably buy a desk first before I write this blog post. Thus, all that was saved in my draft was this line:

I sit. A lot. So much in fact that it is killing me. I want to stand more. I want to move more.

From the desperation found in the quote above, one thing was clear - I desired change. I won’t go into details but my health was the primary reason I was seeking out standing desks.


So you’ve got a new project you want to build and you’re going to pick a front-end javascript framework. First make sure you absolutely need the single page application. Chances are you can do without it. However, let’s say you want to do a lot of javascript client-side intensive stuff, then how should you decide what framework to use? I’ve been in this same scenario myself multiple times, so I decided to blog about it. I have a love-hate relationship with all 3 of these frameworks because I have used all of them on work and personal projects. I only focus on client side frameworks here, not server side, e.g. meteor, sailsjs, express. I only included the frameworks I have the most experience with.


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

This is the last part in three of the hexagonal pattern series. You can download a simple example [here](https://github.com/kdocki/laravel-presenter-example].

Presenters allow you to tack on additional fields and logic to an existing Laravel model. There are several libraries out there that assist in creating presenters, namely,

I am going to use robclancy presenter just because I have more experience with it. After we include it in our composer.json and include the two ServiceProviders and we are set to use it.


Laravel is traditionally an MVC framework but MVC just doesn’t seem to scale for larger projects. Typically what ends up happening is logic is crammed into each section: models, views and controllers as the application grows which becomes next to impossible to test. Taylor Otwell’s book mentions the repository pattern but even that doesn’t really solve this scalability problem. After a colleague showed me a blog post about the Hexagonal Pattern in rails, I decided to try the design in Laravel - the results were nice.


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.