Developer Thought Stream

There has been some debate about when to use PUT versus PATCH versus POST in REST APIs. Having dealt with a variety of 3rd-party REST APIs now, I've become a little opinionated about how the various methods *should* be used. Here's my take: The way I prefer to see PUT used is to submit a fully-formed replacement resource. In other words, if you are using PUT to update a resource, you probably will want to fetch the object from the resource initially, modify it and then PUT the entire modified object back to the resource.  If you are creating a new resource, use PUT only if you are creating your own resource ID (probably not a common use-case, since most resources will auto-assign their own IDs). In contrast, PATCH can update any number of properties of a known resource without needing to submit the entirety of the resource. In most cases, PATCH is the right method for updates as it saves on bandwidth. IMO, POST is the right method for creating a new resource, assuming IDs a

I had an interesting conversation with some banking execs who had a lot to say about mobile-first design and multi-page "form wizards"...none of it good. What they told me was that when you are dealing with forms with lots of data (as loan applications tend to be), the last thing you want is to submit page after page of short, one-page forms. They were very adamant that these multi-page (they called them "tabbed") applications were killing their productivity. They want one REALLY BIG form with all the data on it that they can fill out once and submit. They don't care if they have to scroll a lot or if there are a lot of fields on the page. They went so far as to say it would shave hours off of their daily work and earn the bank loads of money. Interestingly, I'd always resisted mobile-friendly pages for business apps because my personal preference is to organize the data well so that you don't need a bunch of "submit" buttons. I feel l

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. 3    thingyN   TH-655Z ABC      Non-widget Thing   Thing with no widget. Now we have a unique, DOM-friendly ID that we can use in our HTML: <a href="#" id=&qu

// 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

So...I just discovered a "gotcha" with Eloquent relationships that I wish I had known when I created my migrations and data files.  So this would be good for other developers to know in advance as well.  The essence of the problem has to do with the potential name conflict between an eloquent property and a relationship method.  Here's a look at the problem I ran into: 1) I have a "states" table with the following columns: id (auto-numbered), name, abbreviation. 2) I have a "companies" table with the following columns: id, name, address, city, state, zip. Notice that I didn't use a "state_id" column in my "companies" table.  Instead, I insert the state abbreviation and label it as "state".  I made this decision because I fairly often run queries directly against tables and I want to avoid having to type out the JOIN statement for a simple, 2-character field. So that's all fine except when I want to create a

I've decided to write about application workflow with Laravel 5.2.  One of the handiest features of Laravel is the command line "make" command.  This allows Laravel to automatically create assets for you, place them in the appropriate folder and add classes to the Composer routing table.  So, for example, if you want to create a "widgets" model for your project, we would need to create the migration file (which creates the table) and a model file.  So we will issue two commands in our console window: php artisan make:migration Widgets php artisan make:model Widget This will create the following files: /database/migrations/<date + timestamp>Widgets.php /app/Widget.php Note the respective use plural/singular.  In general, we'd be creating a "widgets" table, so the migration name would be similar.  I've found the use of camel case to be the clearest here, though the documentation specifies snake case, which for me, makes it har