CategorySoftware

Chrome to start speed shaming websites

In a recent post, Google announced their intention to badge websites based on their speed and “in the future”, based on “high-quality experience, which may include signals beyond just speed”.

Their motivation – “to help users understand when a site may load slow, while rewarding sites delivering fast experiences” is shady at best. Because, well, I can see by myself when a website is slow and chose not to use it. And what makes a website fast anyway?

Shaming websites by awarding them a slow badge will penalize startups that don’t have the time (or budget) to invest in performance and reward those who do – medium to big businesses.

Further along, we may expand this to include identifying when a page is likely to be slow for a user based on their device and network conditions.

This should be the main goal! When I’m in the mountains or somewhere with little to no cell signal, I’d prefer websites that load faster.

Shaming works. Since 2014, when Google started rewarding https websites with better places in their ranking algorithm and warning users every time they visited websites without valid https certificates, the SSL adoption skyrocketed from 15% to over 50%. This, along the appearance of Let’s Encrypt and its integration with major hosting providers, made the web a safer place.

Speed is just not as critical as the https problem was. The idea of badging websites is worth considering, but the way to make it work is by setting a level that can be easily achieved by everyone.

Why shouldn’t we make the web faster? The stick can be a powerful incentive.

Laravel: Why I gave up on $fillable

Mass-assignment is when you use an array to create/update eloquent models.

$user->update(['name' => 'Dan Gosling', 'email' => 'dan@gosling.com', ...etc]) 

User::create(['name' => 'Jack Ba', 'email' => 'jack@ba.com', ...etc])

The $fillable and $guarded model properties are part of Laravel’s solution to avoid mass-assigning unwanted attributes when someone passes an unexpected HTTP parameter through a request and ends up changing a column in your database you did not expect.

Continue reading

ElectronJS ipcMain and ipcRenderer

Lately I found myself developing an ElectronJS app. I am building some kind of a bridge between software clients and project management tools like Jira, GitLab, Trello, etc.

Here are a few things you should know if you are just starting with ElectronJS:

Continue reading

Tell, Don’t Ask

Tell, Don’t Ask is an object oriented programming principle saying we should just tell objects what to do, without asking them unnecessary questions.

Asking is when we’re writing conditionals solely based on one object’s internals. Either we’re checking a property or a method returning a result, if we’re doing it to tell the object to do something else, we’re breaking the Tell, Don’t Ask principle.

Continue reading

Composer: everything I should have known

Composer was just something I used to get my project up and running and occasionally install additional libraries. I never put too much thought into it – it just worked. Sometimes I would run into problems, but often they were easily fixed by running composer install or composer dump-autoload. I had no idea what dump-autoload was doing, but it was fixing things.

Continue reading

The little details matter most

Although I’m a big, big fan of YAGNI (You Ain’t Gonna Need It), lately I find myself discovering and appreciating more and more the value little details can bring to the table.

Gainslog has a filterable food list you can use to quickly find and add foods to your day. You just type in the name, click the add button and that’s it. No multi steps, no modals, no nothing.

Continue reading

Gainslog now makes daily backups to Google Drive

Thanks to this great tutorial on how to extend Laravel’s storage to Google Drive, Gainslog now pushes daily updates to Google Drive.

Following the tutorial, one issue people run into is a File not found error when running the backup command.

You can get around it by setting the backup folder name to an empty string – but that will place all the backup zip files directly into the storage/app folder.

One way to make sure all backups go into a single folder is to setup a new local disk in filesystem.php and update the backup.php config to use that one instead.

'local' => [ 
    'driver' => 'local', 
    'root' => storage_path('app')
], 
'local-backups' => [ 
    'driver' => 'local', 
    'root' => storage_path('app/backups')
]

And then in config/backup.php

'destination' => [

    /*
     * The filename prefix used for the backup zip file.
     */
    'filename_prefix' => 'backup-',

    /*
     * The disk names on which the backups will be stored.
     */
    'disks' => [
        'local-backups',
        'google'
    ],
]

Interfering in the way users are used to doing things is a no-no

Gainslog is a simple calorie tracker I made with only a handful of users.

If you ever tracked your macros before, you know reaching your daily protein intake goal is the most difficult to attain from all three macronutrients (proteins, carbs, and fats). Once you hit your proteins target, the other ones come around easy. Continue reading

Eloquent trick #1: Replace conditionals with “when”

It happens very often that we want to apply certain eloquent query conditions based on what a request sends in. Sometimes it’s a “search by name” thing, other times we just need to filter the records based on a status column.

Usually it looks like this:

public function index(Request $request) 
{
    $posts = Post::newQuery();

    if ($request->term) {
        $posts->where('name', 'LIKE', "%{$request->term}%");
    }

    if ($request->status) {
        $posts->where('status', $request->status);
    }

    return view('posts.index', ['posts' => $posts->paginate()])
}

I recently discovered there’s an alternative to using conditionals. The “when” method executes a callback (second parameter) when the first parameter evaluates to true.

public function index(Request $request) 
{
    $posts = Post::when($request->term, function($q, $term) {
        $q->where('name', 'LIKE', "%{$term}%");
    })->when($request->status, function($q, $status) {
        $q->where('status', $status);
    });

    return view('posts.index', ['posts' => $posts->paginate()])
}

It’s not all that better if you ask me. Yes, it hides the conditionals, but it also makes the code harder to read. Especially if you have more conditions to add.

I’d use this “when” approach for single conditions only.

public function index(Request $request) 
{
    $posts = Post::when($request->term, function($q, $term) {
        $q->where('name', 'LIKE', "%{$term}%");
    });

    return view('posts.index', ['posts' => $posts->paginate()])
}

Thank you, apple, for letting us know we’re not alone

Feel bad for messing up something at work lately? You’re not alone :). Apple messed up big time.

The bug lets you call anyone with FaceTime, and immediately hear the audio coming from their phone — before the person on the other end has accepted or rejected the incoming call.

Read more here.

© 2019 cdruc

Theme by Anders NorénUp ↑