One of the best things to happen to developers in the 21st Century is open
source, at least for me. The power to look under the hood of some of the key
software out there is mega. Not only do you better understand the software, you
become a better developer by learning as well.
Getting Started with Laravel.
Prior to Laravel I did most of my PHP projects in either Yii , CakePHP and Slim
for my APIs. Then the Laravel hype got to me , So on my next project I decided
to try it out and it turns out its hyped for a reason.It had some interesting
concepts that I wanted to understand.
Learning beyond the Docs
The default place to look up possible things you can do with any piece of
software is its documentation . I must mention that Laravel has very good
documentation . But then again the single source of truth is the Laravel code
base. Documents are prepared based on what is present in code and the code is
more accessible to me than the docs. So why not look up that instead :) . You
might be thinking this is hard to do . Its very easy . Example
lets say you want to work with Laravel’s collection, which is a nice way to work
with arrays. To make a collection out of an array you first collect it eg
collect(["name"=>"joe"]) now depending on the editor or IDE you use you should
be able to locate where the collect method lives by placing your cursor on it.
Places the collect keyword exist
With most IDEs pointing your cursor on the keyword and pressing down on CTRL or
Command will show you where this keyword is implemented and sometimes places you
have used it. With this you are able to see how this is implemented as well as
discover other callable methods.
List of other callable collect methods
For me this is gold as at a glance I can experiment and know what more I can do
as well as understanding how these things are implemented. This saved me one
time where I had code for counting my collection collect([])->count() . Count
is just a wrapper around the PHP count function and so I knew if the
collection ever ended up being a string I will silently get back 0 so I
handled that nicely as the collection count method won’t do that for me.
Using Tinker.
Well once I get to see all the options I have for a given Concept, Class or
Function I immediately try out these methods using tinker. Tinker is the default
REPL which allows one to try out Laravels components without having to deal with
views. Its similar to the rails and Django console.
It also has some cool features which I won’t get into, but as mentioned its one
of the quickest way for me to try out stuff I discover within the framework.
./artisan tinker
From the above you will notice it also gives the namespace which collect belongs
to. From there I can also go ahead and look it up some more.
*Using *dd(debug_backtrace());
Alright so we’ve looked at how to discover some of the things packed in Laravel
for developers. One other important piece is understanding how Laravel deals
with the request/response flow.
For me whenever I need to understand the flow of any PHP project I pull out
die(var_dump(debug_backtrace())); . I drop this at any part of the code I
understand and run the app once again, view this in my browser and I end up with
a complete execution stack up to where I dropped this. I can then follow through
and understand how each class/method/file processes the request and hands over
execution to the next. This gives me an understanding of how the app works as a
whole. With Laravel even better we can replace die , var_dump with dd so
we end up with dd(debug_backtrace()); which gives us something much more
pleasant to the eye.
Backtrace
So above I have the complete execution path till it gets toServiceController
You can see that the request came through the Controller.php file from within
the Routing package. Ow by the way the laravel framework it self is based of a
bunch of packages together known as illuminate which you can find on
Github. There use to be lots of symfony parts in
there as well . With every new release of Laravel I run debug_backtrace just
to see if there are any changes in the request/response flow. You get to learn a
lot by doing this . Also it might take you a while to understand exactly what
happens at every point.
Learning from other Laravel Projects.
One interesting thing about code is that not even the authors of the tools can
completely predict how developers will be using some of the things they created.
For example some developers use blade for scripting and others as a stand alone
tool for creating static pages. This is
also true for things within the framework.
One of the best ways to pick up some of these things is to read the source of
Laravel projects by other developers. One of the ways I decide which project to
look at is through the Github PHP trending pages
This way am more likely to find young Laravel
projects that have smaller footprints. I can now follow the progress of this
projects and learn while its grows. Also the few contributions I have made has
been through this process.
People Behind the Framework
One other important step that I take is to lookup those involved with the
development of Laravel. This not only allow me keep up with the state of
development of the framework. It also gives me a sense of why something exists
or was added. I picked this approach up from school , where the only way I could
understand something like calculus was to follow the life story of Newton and
how he stumbled on Calculus. Also with something like PHP following the story
allowed me understand why we have strtoupper and str_replace which is
because the implementation is by two different people :). Anyways.
These are some of the techniques that came to mind that I use. There might be
more that escaped me but hopefully you find some of these techniques useful, And
apply them as you try and understand the inner parts of Laravel.
Oldest comments (0)