bookmark_borderThe current state of things

It’s amazing how life gets going in a rhythm, and you get your head down and working so hard, that you sometimes forget to look around (or in this case, write in your blog).

Working at a small travel advertising company is a really great thing – until almost all travel ceases, and no one is advertising, and you suddenly find yourself unemployed as a result.

So today I am taking a moment to reflect on what I’ve learned in the last few months. One of my projects gave me the opportunity to work with Vue.js for the first time, and I basically taught myself what I needed to know in order to get it done. It was a good challenge, and I learned a lot.

Mixed in with that I was trying to find a way to query data for a reporting tool that involved millions of rows of data, which was being used by the sales team. The tool already worked, but our team was trying to find a better way to run the queries so they didn’t take up to several minutes to run. We were dealing with behavioral data, and there was a lot of it. The dynamic nature of the queries meant that the more conditions you added, the slower the query might run. Along with that I was trying to normalize the way the data was represented so that other types of queries could all be run the same way, and even be mixed together. Talk about a complex problem! But we were making some headway with it, and then the corona virus hit. We went from a growing thriving company to zero income in two weeks.

The other technologies I was working on were crossfilter.js, dc.js, and d3.js. I did video courses on each, and got to mess around with them a bit using real data from our system, although I wasn’t ready to actually do any graphing just yet. I knew where I wanted to put them eventually, but that was further down the development roadmap.

I guess now, I’ll just need to find a way to work with these in some personal projects to improve my skills, and keep them sharp.

 

bookmark_borderDefensive Programming | Laravel find()

  • Defensive Programming

One of the things I’ve learned in my career is to code defensively.

Laravel makes it very easy to ask for an object, but it also makes it very easy to get it wrong. If you request an object using the find method and it doesn’t find it, you don’t get an error. You get a null. If you then request a property on that object, without first checking for a null, you will get a run-time error.

This is pretty basic stuff, but it never hurts to go over it again.

Wrong:

$name = Widget::find(23)->name;

 

 

Right:

if ($widget = Widget::find(23)) { $name = $widget->name; }

 

 

The first block will throw an error if Widget #23 doesn’t exist in the database. The second checks for it’s existence and then only reaches for the name if it found it.

 

 

Are you also a PHP programmer? I’ve got other blog entries that you might be interested in!

 

More about me

I have been programming for almost 20 years. It all started with Basic and RPG III way back in high school, and have played around with many languages. PHP is my main language today.

Meet my Basenji dogs Zinga and Zulu: https://BarooBoos.com

bookmark_borderLaravel – the difference between all() and get()

When dealing with a model, all()  is a static method.
It creates a new query object, and runs get()  on that object

get()  is not static, but can be called statically because of a magic method in the Model class.

You cannot modify the query when using all() .

Model::all() // will retrieve all models

 

You can select columns to retrieve from the database by passing them as parameters to all()

Model::all('id') // will retrieve all models, but include only the id column

 

Model::all()  and Model::get()  do exactly the same thing. The only difference is that Model::all()  will create a query builder instance and call get() for you. It does this in a static method on the object.

If you call Model::get() , the magic method will create a query builder instance and call get()  on that instance.

Model::all()  will only accept columns as parameters. It is flexible and will accept either an array or a list of them.

Model::get()  will also only accept columns as parameters. However, it is not flexible, so you must provide them in an array.

Model::where('id',1)->get('id')

 

This only works because of the magic method. Just like get() , where()  is not defined in the Model class.

Just remember that you’re dealing with a query builder instance.

bookmark_borderLaravel Eloquent only()

$fullModel = Model::find(1) // Get model with id 1
$idArray = $fullModel->only('id')  // array containing id


// this does not work. You'll get back an empty collection
// It is trying to pull the id column off the collection object,
// not the models it contains
$models = Model::all()
$ids = $models->only('id')

// this will give you a collection of ids
$models = Model::all()
$ids = $models->pluck('id')

 

bookmark_borderLaravel Eloquent Attributes

When dealing with an Eloquent model, you can add your own attributes. These can be useful for computed values.

For example:

class Person extends Model
{
   // By default, all the database fields will be available.
   // Let's assume for this example class that we have
   // first_name, last_name, age
   // but we also want a property called full_name, that doesn't 
   // exist in the database. 

   public function getFullNameAttribute()
   {
      return $this->first_name . ' ' . $this->last_name;
   }

}

// To access that property in a controller, you use the camelCase version of it:
// (assuming you already have an object instance called $aPerson)

$fullName = $aPerson->fullName;

// To access the property directly from the class instance in a view using blade, 
//(assuming that you passed the instance to the view), you use the snake_case version of it

{{ $aPerson->full_name }}

Just remember that when creating an attribute, you start with get and end with Attribute, and the name goes in the middle. The whole thing is camelCase. This is Laravel’s convention.