Tagphp

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.


// config/filesystems.php
'local' => [
    'driver' => 'local',
    'root' => storage_path('app'),
],

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

// 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'
    ],
],

The build cycle of a Laravel application feature

I wrote about having a crossword approach to writing software, but I haven’t given any real-world examples. I only said it’s better because it doesn’t let you wander around and dip your fingers into everything. It keeps you focused on what’s needed now.

Let’s say you’re building a content management system using Laravel. Here are the steps I’d take to build it:

1. Write the code to display the posts in some kind of list. You can get this done by just having a seeder in place and a simple query on the index method. Don’t worry about filtering or anything like that.

2. Write the code to show, store, update, and delete posts. Completely ignore any validation and authorization for now.

3. Notice I haven’t said anything about writing views. No html&css should be written so far. Views can wait.

4. Go back to the create and update methods and add some validation rules.

5. Sprinkle some authorization too. Don’t forget about the delete method.

6. If you need to filter the posts in any way, now is probably a good time to do it. Don’t forget to write tests that cover every filter.

7. Now that all the logic is in place and thoroughly tested, we can start focusing on the views. Style the index and the show views.

8. Add the create and edit post endpoints and style their views too.

9. Sprinkle some javascript where’s needed. Don’t over do it.

10. Pick the next feature. Make sure it touches as few things as possible.

Rinse and repeat.

Are these seconds, minutes, hours? Add some meaning to your time units calculations

Apart from a small todo-cli app and a laravel framework bugfix, I have nothing to show in terms of open source contributions. I’ve always dodged contributing and there are more than enough reasons for that. But the truth is I was mostly hiding behind the “I don’t have time” and “I don’t have a good enough idea” excuses.

But that ends today. Recently I stumbled upon a tweet from Freek (do follow, lots to learn from) asking if there’s a package to convert different time units and assign some meaning by escaping the use of magic numbers when returning stuff like 60 * 12.

The suggested API, Minutes::fromHours(5) is a lot clearer and has more meaning than a random math operation but it implies having separate classes for each time unit. It also prevents me from doing any further conversions on the same value.

Since I’ve never published a php package before, and I was curious about the whole process, I went ahead and created druc/time-convert. It contains a single class and you can do stuff like $time = TimeConvert::hours(5)->toMinutes() and also continue with further conversions like $time->toSeconds().

I’m sure is the smallest and most trivial php package out there, but at least I got to learn the publishing process. 🙂

© 2019 cdruc

Theme by Anders NorénUp ↑