Developer Thought Stream

Semantic URLs have some great benefits. The most obvious one is SEO-friendliness (search engine optimization - Google simply likes semantic URLs better). Not only that but users tend to prefer semantic URLs when they come up in search results. However, assume for a moment that you're the user and you want to re-post a specific article...is it really a net benefit to make a longer URL like: http://www.dogs.com/articles/wiener-dogs-do-super-cute-things-when-you-play-with-them versus   http://www.dogs.com/articles/158 ? You may have made a trade-off here: SEO-friendliness versus ease of use. As a user, you probably already know the URL you are looking for, so that part is easy. You probably can guess that articles are under "/articles", so that part is easy as well. So sometimes it comes down to which is easier to use - a super-long article "slug" or a simple number. Ask yourself what happens when you want to send the link via text or Twitter or some othe...

I'm posting this because it was somewhat difficult to put together using the Laravel documentation.  It is *there* in the docs, but it is split between different subjects.  So here it is, all put together for your enjoyment: I generally use redirects either when input fails validation or when the data has been saved and I'm ready to move to the next input page or a "finished" page.  In the case of redirecting with input, we're talking about a validation failure (or some other error).  The related redirect command is pretty straightforward: return redirect() -> back() -> withInput(); The part I had trouble deciphering was how to retrieve that information into my blade view or controller.  Note that the input is "flashed" to a session, which means it does not persist between page loads (it is deleted after the page loads).  Fortunately, it turns out to be very simple to retrieve an input: // Controller: $first_name = old( ' first_na...

A recent practice of mine is to verify that my migrations work both ways.  That means migrating, rolling back migrations and then migrating again.  This has helped me find issues that I otherwise would have missed. The issues I find usually have something to do with relationships or migrations that alter tables.  While foreign key relationships can be complicated to deal with, they are great for data integrity and query efficiency.  So do yourself a favor and make sure those migrations always work forwards and backwards!

What is "touches"?  Well, anyone familiar with Linux/Unix is going to be familiar with the concept of "touching" a file.  Touching a file sets the "last modified" timestamp (or creates the file if it doesn't exist).  Knowing when a file was last modified can be very important for version control. Laravel has something similar for its model relations.  For example, lets say there is a club with many members.  When a member joins, leaves or gets a new role in the club, you might contend that the club has changed.  In terms of Laravel, you would want the club table's "updated_at" timestamp to reflect that change.  Enter the "touches" property... To make the magic happen in Laravel, you simply need to define the parent relationship and add it to the touches property like so: <?php class Club extends Model { /** * Touches (touch parent model when this model changes) */ protected $touches = [ ...

As much as WordPress is a code disaster, there are still a few good practices and lessons that can be learned from it.  One of those practices that I've come to appreciate is the idea of a "slug", which is basically a URL, DOM ID and database key-friendly field in a table. So for example, if you have a Products table with a product number, name and description, you may find that none of these fields are appropriate to use as a DOM ID but you may need a DOM ID to do some page automation.  This is a good time for a "slug"! id   slug      product_number   name               description --   -------   --------------   ------------       ----------- 1    widgetT   PN-409A 1        Widget Thing       A thingy widget. 2    widgetS   PN-409B 5        Widget Stuff       Stuff for a widget. ...

// A little lesson on naming conventions in Laravel Eloquent: // Table 1: product_variants - variations of a certain product // Table 2: variant_usage - pivot table between product_variants and usage // Table 3: usage - the various product variant uses // Usage - returns all usages for the ProductVariant model public function usage () { return $this -> belongsToMany( ' App\Usage ' , ' variant_usage ' , ' variant_id ' , ' usage_id ' ); // Note: the 2nd/3rd/4th parameters wouldn't be necessary... // ...if the 'variant_usage' table were named 'product_variant_usage' // ...or if 'product_variant' were simply named 'variant' // ...(i.e. - product_variants --> product_variant_usage --> usage) // Also Note: the ID parameters are the connecting points in variant_usage // ...(i.e. - product_variants --> {variant_id ...

The PHP "empty($var)" function (or language construct) is a handy function that I use a lot.  It replaces all of the following checks: isset($var) $var !== 0 $var !== 0.0 $var !== "" $var !== "0" $var !== null $var !== false count($var) > 0 // if array This is particularly useful for integers, but can also be useful for checking strings and floats.  It replaces a bunch of conditions you'd otherwise have to type. I've had some disagreements over my frequent usage of empty().  There are those who believe explicit value checks are important to code readability.  My response is to ask why a longer line of code is any more readable.  There are also those who consider '0' to be non-empty, in which case the use of empty() would not be appropriate.  However, the majority of the time when you use empty(), it will be to check a MySQL ID value, which will (should) always be greater than 0. Consider the following example: if...