GetMock:

{{-- michal's blog --}}

Author Michal Carson

Created 2016-09-23

This is a simple debugging aid for Laravel 5 (developed on 5.2). When the Laravel router finds a match in it's table, it fires a RouteMatched event. That event carries the Request and the Route objects. We can track those calls by creating a Listener for the RouteMatched event and logging some selected information. Below is a simple tool I created to log all the calls to the API layer (written in Laravel) from a client Javascript application.

First, we need a Listener. This is a simple class that can live anywhere but generally is in the app\Listeners directory. I have injected the Laravel Log contract because injection is the standard in our project. You could also use the Log facade.

<?php

namespace App\Listeners;

use Illuminate\Contracts\Logging\Log;
use Illuminate\Routing\Events\RouteMatched;

class RouteMatchedListener
{
    protected $log;

    /**
     * RouteMatchedListener constructor.
     * @param \Illuminate\Contracts\Logging\Log $log
     */
    public function __construct(Log $log)
    {
        $this->log = $log;
    }

    /**
     * @param \Illuminate\Routing\Events\RouteMatched $event
     */
    public function handle(RouteMatched $event)
    {
        if (env('ROUTE_LOG', false) === true) {

            $method = $event->request->getMethod();
            $logMethods = explode(',', env('ROUTE_LOG_METHODS', 'get,post,put,patch,delete'));

            if (in_array(strtolower($method), $logMethods)) {
                $this->log->info($method . ' ' . $event->request->getRequestUri());

                if (env('ROUTE_LOG_PARAMETERS', false) === true) {
                    $this->log->info(var_export($event->request->all(), true));
                }
            }
        }
    }
}

All the action happens in the handle method. I check to be sure we are actually configured to log route hits (ROUTE_LOG). The env() calls are looking for an environment setting. These...

Author Michal Carson

Created 2015-11-09

Most programmers know what a "code smell" is. It's an indication that something may be wrong. It might not be wrong, too. But a code smell is a warning that the code should be examined for deeper issues. There may be a better way to do it.

I am not the first to think there are also "process smells." Strictly speaking, a process smell would be an indication that something is wrong with the process the development team is following. I extend the term to cover indications of a problem with the development organization, the management, even the company itself.

Process smells differ from organizational antipatterns in that the smell is just the warning. There may be no problem at all. But an antipattern is a known problem. If the antipattern exists within the organization then it exists. A smell is only the suspicion of a problem.

So for anyone hunting a job, permanent or contractual, here are a few things to think about when you interview.

1-week Sprint

My favorite, so let's cover this first. Why are we doing a 1-week sprint? Are we incapable of planning a longer timeline? I've seen this in several organizations and I find it usually attributable to faulty requirements.  Maybe the requirements are so unclear that we need a demo every week so requirements can be changed or reprioritized. Maybe the requirements are just now being written.

1-week sprints might be acceptable for a mature product where you only do a sprint on that product once a month. Such a sprint is just for bug fixes and very minor upgrades--usually aesthetic issues.

Project Management Professional (PMP)

I know you worked hard for that PMP, but it's still the old way of doing things. If there are folks in the organization who proudly tout their PMP credentials--or worse, if the organization is looking to hire someone with PMP--be very skeptical of that organization's ability to do agile development.

Agile methods, since they are mostly (all?) iterative, do not align well with...

Author Michal Carson

Created 2015-09-21

Lumen is the lightweight framework associated with Laravel. It has a lot of the characteristics of Laravel but some features have been removed or turned off to make it smaller and faster. Other features are implemented with slight differences (like routing).

One of the features I find convenient in Laravel that is missing from Lumen is the "resource" route configuration. In Laravel, you can set up a full set of RESTful routes to a controller with one line of code.

// this works in Laravel but not in Lumen
$router->resource('/business', 'BusinessController', ['except' => ['create', 'edit']]);

The third parameter is an array of additional instructions. The one I find most useful is "except," which specifies an array of routes to omit. For examples sake, the code above omits the create and edit routes. These two routes usually retrieve a form page. That isn't necessary if the front end is a single-page JavaScript app.

In Lumen, you need to create all of the REST routes individually. It makes the route file awfully busy and leaves room for error. In my latest project, I created a shortcut. Of course, my shortcut involves creating my own Application class that inherits from the Lumen Application class so I may be trading some initial complexity for convenience. Here's my app/Application.php.

<?php

namespace Chamber;

use Laravel\Lumen\Application as BaseApplication;

class Application extends BaseApplication {

    /**
     * Register a REST controller and all of its routes with the application.
     *
     * @param  string  $uri         base path for all routes
     * @param  string  $controller  fully qualified name of the controller
     * @param  array  $except       routes to omit
     * @return $this
     */
    public function resource($uri, $controller, $except = [])
    {
        $standardRoutes = [
            'index' => ['GET',...

Author Michal Carson

Created 2015-08-27

Here's a strange issue I ran into with Laravel 5.1. I had a service provider that was working just fine--registered in app.php, showing up in services.json and in the Composer autoload files. I installed a new package with Composer and wrote a little code to use that package in a model. I made a change to some data in the database (just text that would show on the screen). When I refreshed my page, I got a 404. The routes were not being found. On investigation, I found that the service provider was no longer being called, neither it's register nor it's boot function.

I searched a bit and found a discussion of a similar problem under Laravel 4.0 and 4.1. This suggested running Artisan clear-compiled or manually deleting the services.json file (/bootstrap/cache/services.json). One solution was rearranging the order of providers in config/app.php, which also would cause Laravel to recreate services.json.

I tried every "clear" command in Artisan: clear-compiled, cache:clear, config:clear, route:clear and view:clear. This may seem a little desperate, but I wanted to eliminate all easy solutions since the issue above didn't end up with a solid explanation or reproducible scenario.

The Composer require command had triggered the post-install-cmd scripts. These were Artisan clear-compiled and Artisan optimize. Digging into the optimize command, I found that it runs Composer's dump-autoload, possibly with the --optimize option, and then either compiles classes or clears the compiled classes. The compiled result is in bootstrap/cache/compiled.php. In development mode (APP_DEBUG=true), the optimize command will clear the compiled file so I had no compiled.php. This wasn't the...

Author Michal Carson

Created 2013-09-30

self::employment()->init('2013-10-01');