Welcome

Welcome to Getting Stuff Done with Laravel. The Welcome part of the book explains what you’ll get out of the book.

Here’s how things are broadly organized.

Welcome

The first part of the book explains what you’ll get out of the book.

Part 1 - Design Philosophies and Principles

This part talks about general principles of design we’ll follow in creating the application.

Part 2 - Designing the Application

This is the part where we design the actual application.

Part 3 - The Console Application

Next, we make the application usable from the console.

Part 4 - The Web Application

Now we’ll take our creation and put a web skin on it. Mwaa, haa, ha.

Appendices

Supplemental information. Like how to install Composer.

Chapter 1 - This book’s purpose

This book will take you on a journey through Laravel. Hopefully, you’ll go places you’ve never been and see you things you’ve never seen. It’s a travelogue of sorts. We’ll have a definite destination (the application we’re creating) and I’ll point out some amazing sights along the way. When you reach the end, drop me a note at chuckh@gmail.com. I’m very interested in what you thought of the journey.

This book is meant to be experienced. To be used. Please follow along and build the application chapter by chapter. Each chapter leads to the next. The sections within a chapter flow forward. Each part of the book builds on the previous.

You could think of the sections in each chapter as cities. Then the chapters themselves are countries, and the book’s parts are continents and … Okay, enough with the labored traveling analogy.

The focus throughout the book is the step-by-step creation of an application using Laravel 4.

This is not a typical technical manual I’ve attempted to mimic the actual process of design and development as closely as possible. This means there are false starts, design changes, and refactoring along the way. You’ve been warned <grin>.

What’s not in this book

• Every aspect of Laravel. This is not a reference book on the entire framework.
• Caching, Events, or Logging. These are important topics, but the application we’re creating doesn’t require them.
• Queues, Authentication, Cookies, or Sessions. Again, important stuff, but we don’t need it.
• Database. Yeah, it almost pains me to admit this. One of the greatest aspects of Laravel is it’s Fluent Query Builder and Eloquent ORM. I mean, what great names. Names that the implementation fully lives up to. Sadly, I don’t touch on this because … you guessed it … the application we’re creating doesn’t need it.

What’s in this book

Mostly, me blabbing away about why I’m doing what I’m doing in creating the application. You may agree with me some of the time. You may argue with me some of the time. Sometimes you may think I’m a complete idiot. Hopefully, at times you’ll think “Oh yeah. Good one.” But in the end, you’re getting the nuts-and-bolts of creating a real system that you can use.

Chapter 2 - Who are you?

Most books start with information about the author but the more important question really is “who are you?”

I’m making the following assumptions:

• You know more about computers than most people.
• You are a programmer.
• You know how to program in PHP. Maybe a little. Maybe a lot.
• You’ve heard of Laravel. (This isn’t a deal-breaker because I’m going to tell you about it.)
• You love programming or want to get back the passion that first drove you to make computers do your bidding.
• Your name is not Taylor Otwell because if it is, then I’m not worthy.

I’ll do my best to make the material approachable to beginners, yet interesting and in-depth enough for intermediate programmers to find the material useful.

Bottom line You want to learn more about Laravel.

Chapter 3 - Who am I?

This is the typical rah-rah, ain’t I great chapter. It’s not going to teach you a single thing about Laravel. The smartest move you could make right now is to skip to the next chapter.

Hello. My name is Chuck Heintzelman and I write computer programs.

(That felt like I was in front a support group. I hope nobody said “Hi Chuck.”)

Seriously. I’ve written programs since that day in 9^th grade when I stayed home “sick” from school with a borrowed BASIC Language Reference manual and wrote out on paper a game that was like Asteroids except instead of asteroids flying at you it was other ships firing long white blocks of death at you.

After long hours of debugging and waiting for the TRS-80 to load/save my program to it’s “mass storage” (a cassette tape), the game finally worked. This was 33 years ago. Back in the day of computer dinosaurs, large ferocious beasts filling climate-controlled rooms. No, I’ve never actually used punched cards, but have seen them in use.

Since then I’ve written programs in Fortran, COBOL (yeah, I know), Assembly Language, Basic, C, C++, C#, Java, Pascal, Perl, Javascript, and PHP. I’ve tinkered with many, many other languages, but have not written programs that people actually used.

I’ve created systems for Fortune 500 companies, as well as small Mom-and-Pop stores. Everything from mail order systems running in Xenix to web applications running in PHP. I’ve started several companies before the days of the Internet (not before the real beginning of the Internet, just before the excitement starting in the mid-90s), and a few dot coms since then. And through it all I’ve did what I loved to do–write computer programs.

Whew! Okay, enough about how great I am.

Here’s my point Throughout my career I’ve never felt the need to create a book about programming until now. The sole reason I’m writing this is because of Laravel.

Chapter 4 - What is Laravel?

Raise your hand if this sounds familiar

You’ve been tasked with adding a feature to your company’s existing system. Unfortunately, the system was written in PHP 4 and whoever the original programmer was, you suspect they watched a few too many “Wordpress Gone Wild” videos.

You’ve inherited this codebase with *gasp* no classes, a glut of global variables, and a structure not unlike a 50,000 piece jigsaw puzzle.

You curse your job, the short sightedness of the management-team, and whatever possessed you to want to make money by programming in the first place.

After all, programming should be fun. Right?

We’ve all been there.

Enter Laravel.

(Cue the sound of kettle drums: duh-duh duh-duh duh-da-duh)

Laravel is a framework for PHP which makes programming fun again.

Come on man … it’s just a framework

Laravel is not a new language. It’s only a framework. If you cut through all the hyperbole and look at its essence, Laravel is simply a PHP Framework.

Although, I do agree with the motto from the Laravel web site:

Ruby On Rails is just a framework. Yet look at the fandom behind it.

Laravel’s not going to magically fix your PHP spaghetti code, but it provides you with a new, fast and elegant way to get stuff done. (Note, the concept of Getting Stuff Done is a reoccurring theme in this book.)

In short, Laravel provides you with an architecture that makes PHP programming a joy. You’ll be able to refactor existing code in a way that is expressive, stylish, and will be easy to maintain and expand in the future.

Laravel is not a panacea. If your existing codebase sucks, it’s going to be painful to get from where it is now to where it should be. That’s the nature of our industry.

But, if you want to move to a framework that allows simple expressivity (is that even a word?) then Laravel is the answer.

Chapter 5 - How to justify Laravel

Here’s the problem (or a problem) …

You must work under the constraints your company places on you. Namely, that you must support the existing software and develop new code that plays nice with your existing systems. There’s a mix of .NET, some Java, but most of the existing code is PHP.

You’ve recently discovered Laravel and like it and want to use it for new development.

How can you justify switching to Laravel?

Let’s put on our detective hat for a minute.

Hmmm. The detectives I know (from TV of course) seem to follow the money when looking for suspects and motives. So let’s follow the money …

Customers provide money to businesses in exchange for goods and services. The better the product, and the more customers really want the product, the more money they fork over to the business.

Managers want the business to thrive. They want as many customers as possible to give them as much money as possible as frequently as possible.

Think about it from management’s perspective …

• I want my customers to be happy.
• I want new customers.
• Customer happiness equates to expectations being met.
• I want my programmers to be able to deliver the requirements on time.
• I want the programming team to be agile. (Whatever that means … see the box below.)
• I want to facilitate customer’s requests in a timely manner.
• I want great developers delivering great products

If the above list is the management perspective, then Laravel is easily justified:

• Customers are happy when their needs are addressed and met.
• Customers are even happier when their expectations are exceeded.
• Laravel provides a framework that …
  • Makes it easy to extend functionality.
  • Follows best-practices in design.
  • Allows multiple programmers to collaborate efficiently.
  • Makes programmers happy. (Remember managers: a happy programmer is a productive programmer.)
  • Let’s stuff get done faster.
  • Encourages unit testing, considering testing a core component of every application.

Laravel provides managers the ability for their programmers to get more done, quicker, and eliminates many of the obstacles inherent in web application development. I’ll expand on this later.

Chapter 6 - Why programmers like Laravel

Let’s cut to the chase … why would you, as a programmer, want to use Laravel as a framework?

Let me talk a bit about Framework Envy.

(Here I picture talking to a therapist. Him nodding sagely, taking a drag on his pipe and saying, “Talk about zee framework envy.”)

I’d been given projects written in PHP. These were bloated, PHP 4 projects written by a developer whose only concept of “class” was that it is something at school to be skipped. And I’d look across the street at the Ruby developers and silently wish for some natural disaster–earthquake, tornado, even lightning–to level their building.

Does this make me a bad person?

This was at a time when Ruby was all shiny and new. What made Ruby cool wasn’t the language itself (although there are very nice aspects to the language). No, what made Ruby cool was Ruby on Rails.

All the developers were flocking to Ruby on Rails.

Why were they flocking to it?

Because it promised a way of development that was fun. And by fun, I mean powerful, expressive, and quick to implement. I credit RoR on creating an atmosphere making programming a delight again. The coding joy instilled by RoR is the exact same feeling as that initial impetus that made us all want to be programmers.

How sad was it that we were mired in the PHP world? Where any Tom, Dick or Henrietta was a “PHP Programmer” because they could hack a Wordpress install.

(See the next chapter about Wordpress - The Good, The Bad, The Ugly)

But, no, we were stuck with the requirements that our projects be in PHP. We couldn’t be a cool kid like all those Ruby developers. They were cutting edge. They were the ones pushing the boundaries, making a name for themselves.

Along comes Laravel. It takes the best of Ruby on Rails and brings it to the PHP world. Suddenly, a PHP developer is dealing with routes to controllers instead of individual scripts. Concepts like DRY (Don’t Repeat Yourself) now have more meaning. Suddenly, we have a “blade” template engine incorporating the essence of PHP in a way Smarty Templates only dreamed of. We have, quite literally, the potential of PHP Nirvana.

Does it sound like I think Laravel’s awesome? I hope so.

Chapter 7 - Wordpress: The Good, The Bad, The Ugly

Wordpress revolutionized blogging. It brought blogging to the masses. Sure, there are other platforms like blogger and livejournal, but what Wordpress did was put out in the public domain a large, popular system written PHP.

With the advent of Wordpress, anybody could hack the PHP scripts to make the blogging platform do what they wanted it do it.

“With great power comes great responsibility.” – Uncle Ben (from Spiderman)

Unfortunately, the power Wordpress availed was not met with great responsibility. Scripts were hacked with no thought toward overall design or usability. To make matters worse, Wordpress started in the days of PHP 4, when the language didn’t allow the constructs that allowed true programmers to create maintainable systems.

Wordpress was the best thing that happened to PHP, but it also was the worst thing that happened to the language.

It’s a case of too much success in the hands of too few artisans.

This attached a stigma to PHP.

Softwarati¹

Self absorbed programming intellectuals who comment on languages.

For your consideration … a commonly heard quote by the Softwarati:

“Oh. PHP’s a ghetto language. Ugly, hardly maintainable, but it works … most of the time”

Thank goodness Laravel came along to kick those Softwarati in their upturned noses.

Chapter 8 - Conventions Used in this Book

There are several conventions used through this book.

Code is indented 2 spaces

Usually, I indent code 4 spaces but since this book is available in a variety of eBook formats some of the smaller screens have horizontal space at a premium.

1 for ($i = 0; $i < 10; $i++)
2 {
3   echo "I can count to ", $i, "\n";
4 }

This is a tip It is used to highlight a particularly useful piece of information.

This is a warning It is used to warn you about something to be careful of.

This is an information block Used to reiterate an important piece of information

This is something to do When there’s code, or other actions you should take, it’s always proceeded by this symbol.

Trailing ?> is used when opening tag is used.

When coding, I always drop the trailing ?> in a file. But the editor I’m writing this book in makes everything look wonky when I do it. So, within this book, if I open a PHP block with the PHP tag, I always close it in the code too. For example:

1 <?php
2 class SomethingOrOther {
3     private $dummy;
4 }
5 ?>

PHP Opening and Closing Tags

In the code examples sometimes the opening PHP tag (<?php) is used when it’s not needed (such as when showing a portion of a file.) Sometimes the closing PHP tag (‘?>’) is used when it’s not needed.

1 <?php
2   function somethingOrOther()
3   {
4     $this->callSetup();
5   }
6 ?>

With real PHP Code I always omit the closing tag at the end of the file. I’ll leave it to you to determine whether or not the tags are needed. Be aware the opening and closing tags in the code examples should not be taken verbatim.

What OS am I using?

I’m writing this manual, the code, etc., using Linux Mint 14 which based on Debian and Ubuntu. It’s basically the same as Ubuntu 12.10.