Learning Laravel 4 Application Development

Surprise, surprise…another introductory book to Laravel. The most important thing this book has to define, is what sets it apart from all the others on offer. Let’s take a look.

The book begins by motivating the use of Laravel to the user. I guess, for newcomers, this is an important first step. After all, how are you going to know if the framework is right for you until someone tells you? It also covers Composer, both theoretically and with a tiny bit of code.

It continues with a description of the folder structure of a new Laravel installation. Following that, there’s an insufficiently brief explanation of configuration, detailing only database and app configuration. I imagine some of the config files are better left for the parts of the framework for which they are used, but that doesn’t explain why the database config is covered along with the app config.

The book then launches itself into explaining what Artisan is and how to use it. Again, it only covers a strange mix of functionality which includes two generator commands (commands which make files from templates), the rest of the migration commands (migrations are a programmatic representation of database changes), the seed method (for populating the database) and the test method (which nobody really uses). There are 41 artisan commands. I counted them. It’s astonishing that a description of Artisan wouldn’t include examples of things like the routes command (to list the available URLs supported by the application), the tinker command (a bad-ass, interactive shell) or the serve command (to create a web server for the application). Astonishing.

The third chapter is really the beginning of the end, though. Entitled “Creating a Simple CRUD Application in Hours”, it goes about demonstrating how to create a user store (completely ignoring the one thing users are used for: authentication) in what could have taken minutes. You could quite easily have strung together 3 or 4 videos from laracasts.com, and you would have exactly the same knowledge. Nay, better knowledge, I say!

To manage this data, you need to know about models (a tiny amount of Eloquent, Laravel’s ORM), Blade (Laravel’s template engine) and controllers. It’s just assumed that this knowledge will be picked up as the reader tags along. If those topics had been presented sufficiently, before attempting to use them in a real application, then the chapter need only take 30 minutes to go through. 45 minutes if you include authentication.

In the fourth chapter, you’ll encounter many syntax errors. I really don’t think this chapter was technically reviewed — nobody could have run this code and missed these errors. Add to that pages of unformatted, and unexplained CSS/HTML (applied on top of Bootstrap 2!) and you may think of skipping this chapter. I wouldn’t blame you.

The fifth chapter is about creating packages, and here the problems become less about Laravel and more about general PHP code. The first few examples are about dependency injection.

Only they don’t end with dependency injection best practises, but rather a mix of setter injection, tightly-coupled container-aware classes and a completely inaccurate representation of what the IoC container (an integral part of Laravel 4) actually does. The final code of this section looks ok, but the path to it is horrible.

The rest of the chapter isn’t all that bad, one you get over the lack of syntax highlighting (a common shortfall of Packt books) and poor formatting.

At this point in the review, I decided to zoom out a little…

The book contains many inconsistencies with regard to file and folder names being strangely cased. One particular table lists:

Public

Src

src/acme/cart/cartserviceprovider.php

Src/Config

Src/Migrations

Src/views

Tests

Vendor

Composer.json

Phpunit.xml

It’s as if someone of nefarious intention went through it, altering case to confuse people.

There’s also the problem of inconsistency in aspects as tiny (yet ubiquitous) as the quotations and spacing used in code. To illustrate this, I found the following code listing (unedited) extract:

$table->increments('id');

$table->text("message");

$table->string("image",255);

$table->boolean('status', array('0', '1'))->default(0);

Perhaps I’m nit-picking here, but the above shows a bizarre lack of attention to detail. It’s all over the place. The only pattern is the lack of patterns.

The formatting is terrible. There’s a simple rule I have for my own writing; if the code needs to wrap, you’re doing too much on a single line. Unfortunately, it seems the opposite of this was a goal.

In summary…

It’s difficult to say this stuff without sounding like a big old meanie. I realise it’s easy to criticise what must have taken months to write. Thing is…it’s easy to write a book. The tricky part is in writing it well. Half of that is in understanding and knowing how best to articular the content. Half of it is in presentation.

You can have the best content (not an assertion I can daily make of this book) but if your presentation is horrible then nobody can read it. I wrote a book once, which took years. I feel like the only benefit anybody got from it was that I learned a little of how not to write. I feel like this might be a first book for the author, and everybody has to learn somewhere. I just don’t think it’s comparable with the alternatives on offer.