a place where I post things

Menu ☰

If you’re just getting started with PHP development, or even looking to increase your skills, a great place to start is PHP: The Right Way. However, be warned that there is not a “right” way to code in PHP (or any other language, really). But “PHP: A very good guide to writing code that might be beneficial depending on your specific scenario” doesn’t really have that ring to it. The fact is, everyone’s situation is unique, and there’s no one way that will be best for every situation.

For an example, let’s start with the ‘Getting Started‘ section: “Use the Current Stable Version (7.1)”. That’s great advice, and if you have the capabilities and resources that’s what you should do. But what if you don’t have extra funds to put towards hosting and need to use a free hosting option? Most of the free PHP hosts I found were still on PHP 5, and only one was using 5.6. If all you’re able to use is a server with PHP 5.3 on it, I say, “Go for it!”. That’s going to be your “right way”.

As far as developing locally, check out the “All-in-one installers“. There are plenty of sites and Reddit posts that will tell you how you need to be using vagrant or docker or something, and by all means use them if that interests you. Just don’t feel like using WAMP or MAMP is somehow “bad” because none of the experts are using them. The *AMP installers are pretty amazing, and they are super easy to get set up.

Finally, let’s talk about Object Oriented Programming. Over the years, a lot of influential devs have elevated Uncle Bob Martin as the sage of all things TDD, and tangentially OOP. While he offers good advice, I tend to find his sarcastic writing and speaking style rather dismissive and detrimental to those who are new to programming and trying to get their footing. Feel free to learn about “single responsibility” and “encapsulation” and other programming jargon usually used about OOP… but also, feel free to write a single php file with a thousand lines of procedural code. Oh, and go ahead and mix in your html, css, and even javascript into that file. Forget the buzzwords, just create something and play around.

Speaking of Uncle Bob, in a later post, we’ll discuss why you can throw your TDD and unit tests out the window.

The point is, the “right way” is totally subjective. People talk about “best practices” and “anti-patterns”, and apply their judgments to them… but in reality, they’re just suggestions. Sure, they may be good suggestions, but it’s all just people’s opinions and you shouldn’t feel bad about not following them.

We’re currently building out an API at Basanty, and I was looking for a way to generate a simple Excel/CSV file. Using the `artisan routes` command, you can print out a nice table in the console, or even save it by appending `> routes.txt`. The problem is the Symfony table formatter doesn’t translate well to a document.

So I created a simple route that loops through the routes, and saves them to a csv file. This could quite easily be abstracted to a custom artisan command. Also, after generating the file, you should probably remove it immediately.

I just ran across an excellent article on how to use Grunt with Laravel, and I thought I’d share my process. First things first… install node, npm, bower, grunt, and all that. Google it if this is new to you.

With Laravel installed, I actually use the Laravel-Assetic package for all my concatenation and minimization. That way, cacheing is taken care of automatically. Here’s my composer,json file with all the needed filters

In the command line, run `bower install` and all those files are added to the ‘assets/bower’ directory. Then (after following the Laravel-Assetic install instructions) we need to add the files to use in the Laravel-Assetic config file. Here’s an example of my config:

Some explanation: Starting at the bottom, we have our ‘assets’ array, where we assign a name to each asset and point it to the file we want to use. Then, we have our ‘filters’ array where we give a name to each filter we’re using. The composer file loaded in the filters we’re using. Before that, we create our ‘groups’ array. Each group is basically the filters we want to use, the files we want to filter, and then the output file to create. The order of the files is important, since this will affect any dependent files (eg, jquery needs to be before jquery-ui).

Now, we can run `php artisan asset:warm’ and all our files will be created. The one issue I had during development was that I was doing lots of quick updates to the css/js, and it would take time for the asset cache to clear. So I had to ‘warm’ them often. This was a time waste, so I’m using grunt to take care of that for me, ad live-reload it as well.

The only 2 grunt packages we need are ‘grunt-contrib-watch’ and ‘grunt-exec’. This is how my Gruntfile.js file looks:

I open a dedicated command line tab, run `grunt` and it will warm everything on start. Then, anytime I make a change to one of the files, it’s automatically warmed and the page is reloaded. The ‘html’ part will reload it when my views are changed.

One word of warning… the way I have it set up, it loads every js/css into every view. While it’s handy to only have 2 (or 3 in my case) minimized files that need to be loaded, we’ll only need Redactor on the pages with forms. It might be best to create our groups dynamically, and only use the assets we need for each view.

It all started 2 years ago, when I found this post on Forrst by Taylor Otwell announcing the release of Laravel 2. I downloaded and tried it. As I was using Codeigniter at the time, I found it quite nice and refreshingly different. However, my job only had PHP 5.2 on its server, so I only tried it locally and didn’t go much further. Then a few months later, he announced version 3 and I gave it more time. When version 3.1 was released, I ended up using it for some personal projects and read through the source code pretty extensively. At that point, I considered myself fairly ‘expert’ in Laravel.

In August of 2012, I was contacted by Packt Publishing to be a ‘technical reviewer’ for Shawn McCool‘s Laravel Starter book. It was a fairly easy thing, and payment was basically just a hard copy of the book and my name/bio in it. When it was released, I was pretty excited to see my name in print. This was my basic reaction.

Shortly thereafter, I was contacted again by Packt with the offer to write a Laravel book, specifically a ‘cookbook‘. It seemed like a daunting task, but I figured it would be a great step in my career, so I agreed. The money isn’t great, but since I’m fairly unknown and payment was guaranteed, I was pretty happy with the compensation.

Packt pumps out tons of niche tech books every month, so they have a solid system set in place. The first step was an outline. I had to come up with chapters, and then ‘recipes’ for those chapters with an estimated page count. At this point, I started to realize that page counts and recipe counts were a pretty big deal to them. They wanted 11 – 12 chapters with 9 or 10 recipes in each. They said it looks good to have ‘over 100 recipes’ on the cover. I struggled a bit at first, since I had done absolutely nothing like this, ever. Eventually, after reading forum posts and seeing IRC questions, I began to get an understanding of what people needed help with. It made the outline process a bit easier.

With the outline complete and approved by Packt, I began working on the chapters. It was actually a lot easier than I first thought. The only real issue I had was how the whole thing was formatted. You get a Word document template, and you’re supposed to format everything with their pre-made styles. Formatting is VERY important to them. Also, everything is supposed to be worded like “and then we do this” or “so our next step is” because I guess it makes the reader feel part of the book or something. Formatting was probably the most stressful part of the initial process.

Chapters 1 to 9 actually went fairly easily. At this point in January 2013, version 4 of Laravel had already been announced, and the beta release was on Laravel’s develop branch on GitHub. Then someone who was doing a technical review asked if this was for version 3 or version 4. Packt asked me about it, and I told them I was working on L3, since L4 was still in early beta. But most people’s best guess was a summer release of L4, and it would be quite a bit different from L3. Packt and I decided it would be best to wait, because the release date for the book would probably be around the time L4 was released… and thus would instantly be irrelevant.

Now, it’s the end of February and I go to Laracon in DC. It was a fun time and I got to meet some excellent people. We also find out that L4 would be released in May. So now, all I needed to do was learn L4. With work and family, it wasn’t very easy to dig that deep into version 4. The source is pretty extensive and relies on a lot of 3rd party libraries. Packt was pretty urgent about wanting the thing finished, so I decided to stick with the original outline, salvage what I could, and just update the syntax for L4. A few chapters needed a major overhaul, like one I wrote about using and creating L3 Bundles or how to include and use Composer in an L3 app. There are some that are still in the book, and work, but are kind of silly to do when using L4… for example, installing L4 as a git submodule. Unfortunately, there are also a couple of DGAF chapters, like 3 separate chapters on using Twitter/Facebook/Linkedin for auth/logging in. I ended up just getting it done and turning it in, and trying to make it as good as it could be. I fell short of the 100+ recipes by 10 or so, and the 300+ pages by about 50. Oh well. By the end of October, the Laravel Application Development Cookbook was officially published. I can now call myself an author.

Now that I’ve actually spent some time with L4 and competed some projects with it, I’m kind of sad that there are certain bits missing. Things like using the Laravel workbench, or creating custom commands, or service providers. I would add, update, or replace a good 20% of the book if I were to re-do it today.

Having said that, I still think it’s worth the money you pay, especially for the hard copy. Even just the ebook is less $ than two of the more popular Laravel ebooks available at the moment, and I think the information contained is just as valid. And while some may not have a great opinion about Packt, I was overall fairly happy with them. I think their focus on page counts and formatting makes the process a little less enjoyable, but they promised a certain payment at various points in the process, and they delivered in a timely manner.

I think Packt is great for an unknown with a decent amount of knowledge on a subject, especially if you’ve never written anything before. Just having a published book on Amazon has opened a few doors for me, and I’ve seen an uptick in blog readers and Twitter followers. Though, if you’re even remotely known for a particular subject, just go to LeanPub… where you would need to just sell 150 books at $20.

In closing… I got my name on a book, I got a nice printed dedication to my wife and kid, and I got a little money. So I’m pretty happy with the experience. I mean, I may never do it again… but I’m happy I did it once.

At work, there was an issue with using Laravel’s migrations and the scheme builder with tables that needed foreign keys. It’s not in the official documents, but after some source code searching, there is a solution that works well…

For example, you have a Users table and each User has Pets (one-to-many). If the User is deleted from the database, you want all their Pets to be deleted as well. In our up method in the migration, we would do something like this:

In a previous post, I was trying to parse out the most popular Composer packages, and wasn’t able to find a way to get the information through any kind of API. I ended up doing a simple scrape, but then I started searching through the Packagist code , and I found some interesting gems.

With that list, you could easily get the specifics about each package at https://packagist.org/p/{package-name}.json. For example: https://packagist.org/p/illuminate/database.json . But what about searching? The Packagist website UI isn’t the most intuitive, but there a couple of queries that make the search fairly powerful. First, is just a regular search like : https://packagist.org/search.json?q=laravel This is fine. It mirrors the site’s search and it’s nice that it includes the ‘downloads’ and ‘favers’

One of these days, if someone else doesn’t beat me to it, I’ll make a review/upvote/downvote site so that the best packages can be found a bit easier. Also, there are some excellent packages that have almost no documentation… so having comments that explain some use-cases would be nice.

There’s no doubt that Composer is the way of the future for PHP, but Packagist (the package archiver) is woefully lacking in useful information. Well actually, the information is there, there just isn’t a way to get at it. For example, I was looking for an asset manager and typed in assets, and I couldn’t figure out how they were ordered… and there’s no way to reorder them.

I figured by now, someone MUST have built a user-ratings system for the packages. But after weeks of searching, I haven’t found any. So I figure I might as well start. Right now, I’ve only got a list of all the packages, and they’re ordered by descending total number of downloads: http://matu.la/packages/

It shouldn’t be too difficult to add in up and down ratings and comments. The biggest issue is getting the stats. Packagist doesn’t have an api (that I can see) that exposes the packages’ info, like tags, downloads, and such. The info I have was a quick scrape, and that’s not something I want to keep doing.