Learning Laravel - Observations, part 1: The service container

planet PHP - 2019-06-03(月) 16:10:00
With excerpts from the documentation

I have worked with symfony 1, Symfony 2+, Zend Framework 1, Zend Expressive, but never with Laravel. Until now. My partner was looking for a way to learn PHP and building web applications with it. Most of my own framework knowledge is related to Symfony, so my initial plan was to find a Symfony course for her. However, Jeffrey Way's Laracasts also came to mind, and I thought it would be an interesting learning experience for us both if Laravel would be the framework of choice in this matter. It turned out to be a good idea. My partner is making good progress, and I get to see what Laravel is all about. We have a lot of fun together, finding out how it works, or what you're supposed to be doing with it.

As a side-project, I've been reading the official Laravel documentation. Being a human with framework habits, I couldn't help but compare the Laravel approach to the Symfony approach. I've also compared some of the suggestions from the documentation with what I think are best practices for any web application, regardless the framework that you choose. Something to keep in mind when reading this article is that my approach to web application architecture is to keep the framework and other infrastructural concerns far from the code that represent my application's use cases and the domain models it contains. See also the series I wrote about this approach earlier (part 1, part 2 and part 3). I'm usually not looking for a way to develop something as quick as possible, or make development as convenient as possible. I try to find ways to protect its future against external influences, like changes in the language, the framework, a desire to switch to a different database, queueing system, etc. This will certainly color some of my observations in this and following articles, including the advice I give here on which feature to use, and which ones to ignore.

I also want to make clear that I'm absolutely not here to bash Laravel or anything. Quite the contrary actually, I think its builders have made some great decisions. They have also added things that I guess might nudge people in the wrong direction in terms of object design, but keep in mind: this is all my opinion. Of course, I try to give proper arguments, but in the end I'm not here to say: use Symfony, ditch Laravel. If anything, my message when it comes to frameworks would be: use them to your advantage, but only in the parts of your code base where it makes sense. Don't let them determine your overall design (or architecture), make sure you can swap parts of them out when you want or need to. If Laravel/Symfony/Zend/etc. suits your needs today, use it today, but prepare for the day when you don't want to use it anymore.

With all disclaimers out of the way, let's go!

The service container

Let's start with a discussion about the service container. After I wrote the article on Hand-written service containers someone pointed out to me that my solution wasn't the only one that has the advantage of being easy to refactor; the classes, interfaces, and methods that you use in Laravel service definitions are also indexable by your IDE and are therefore easy to rename, move, etc. That's totally correct. This is what a service definition looks like:

// Defining a service inside a closure: $this->app->bind('HelpSpot\API', function ($app) { return new HelpSpot\API($app->make('HttpClient')); }); // Using it somewhere else: $this->app->make('Helpspot\Api'); // Note: you can use `Api::class` instead of spelling out the full class name

However, most services don't even need all this work, because you can give the container instructions. E.g. instead of binding an interface with a closure, you can also bind it with a class name, so that, whenever an object requires an instance of the interface, it will get an instance of that class injected:

$this->app->bind( 'App\Contracts\EventPusher', 'App\Services\RedisEventPusher' ); Shared versus singleton services

I think it's very interesting that by default the services that you define using bind() are not shared, that is, the next time we'd call $this->app->make(), you will get a

Truncated by Planet PHP, read more at the original (another 15717 bytes)

カテゴリー: php

php|architect: Serverless PHP, Composer and Magento, php[world] Call for Speakers.

phpdeveloper.org - 2019-06-02(日) 20:00:02

In Episode 20 Eric, John, and Oscar are back talking about PHP, and the May 2019 issue. Topics

John and Eric discuss Serverless PHP, Deploying ReactPHP Applications, Mysql 8.o, and more. Oscar talks about using Composer with Magento and similar experiences with Drupal, network tunneling with n...

カテゴリー: php

PHP: Hypertext Preprocessor: PHP 7.1.30 Released

phpdeveloper.org - 2019-06-02(日) 20:00:02

The PHP development team announces the immediate availability of PHP 7.1.30. This is a security release.All PHP 7.1 users are encouraged to upgrade to this version.For source downloads of PHP 7.1.30 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download...

カテゴリー: php

Péhápkaři Blog: Book Review: Refactoring

phpdeveloper.org - 2019-06-02(日) 20:00:02

Review of the Refactoring: Improving the Design of Existing Code by Martin Fowler, 2nd edition (2018).

カテゴリー: php

Regina Obe: PostGIS 3.0.0alpha2

planet postgresql - 2019-06-02(日) 09:00:00

The PostGIS development team is pleased to release PostGIS 3.0.0alpha2.

This release works with PostgreSQL 9.5-12beta1 and GEOS >= 3.6

Best served with PostgreSQL 12beta1.

Continue Reading by clicking title hyperlink ..
カテゴリー: postgresql

elein mustain: Beautiful things, strings.

planet postgresql - 2019-06-01(土) 08:45:09
This blog today is going to talk about strings: how they are stored, how they are input, and lots of examples of how to use string operators and functions in order to manipulate them. Strings, strings, strings. What we are not going to cover is regular expressions, although we will use them. The Fine Manual […]
カテゴリー: postgresql

Magnus Hagander: Nordic PGDay 2020 - Date and location

planet postgresql - 2019-06-01(土) 06:44:22

We're happy to announce that Nordic PGDay 2020 will be held in Helsinki, Finland, on March 24th, 2020, at the Hilton Helsinki Strand. Join us for a full day of PostgreSQL content!

For now, mark your calendars -- registrations and call for papers will open in the fall!

カテゴリー: postgresql

Bruce Momjian: Updated Sharding Presentation

planet postgresql - 2019-06-01(土) 01:00:00

I presented my sharding talk today at PGCon in Ottawa. The slides have been updated to more clearly show what has been accomplished toward the goal of built-in sharding, and what remains to be done. The talk was well attended. I also attended a breakfast meeting this morning about sharding.

カテゴリー: postgresql

Álvaro Hernández: What it is PostgreSQL Ibiza and why you should attend

planet postgresql - 2019-05-31(金) 16:49:11
PostgreSQL for Thinkers Please check PostgreSQL Ibiza’s conference website. If you haven’t done so, please also take two minutes to watch our conference video. Now if you think that PostgreSQL Ibiza is another PostgreSQL Conference, just on the beach (which is not that bad anyway!), then keep reading. Because it is much more than that. PostgreSQL Ibiza is a new, disruptive PostgreSQL conference. We are all in a rush. I have been to many dozens of PostgreSQL conferences in the last decade.
カテゴリー: postgresql

Luca Ferrari: Normalize to save space

planet postgresql - 2019-05-31(金) 09:00:00

It is no surprise at all: a normalized database requires less space on disk than a not-normalized one.

Normalize to save space

Sometimes you get a database that Just Works (tm) but its data is not normalized. I’m not a big fan of data normalization, I mean it does surely matter, but I don’t tend to “over-normalize” data ahead of design. However, one of my database was growing more and more because of a table with a few repeated extra information.
Of course a normalized database gives you some more disk space at the cost of the joins during query execution, but having a decent server and a small join table is enough to sleep at night!
Let’s see what we are talking about:

mydb=# select pg_size_pretty( pg_database_size( 'mydb' ) ); pg_size_pretty ---------------- 13 GB (1 row)

Ok, 13 GB is not something scarying, let’s say it is a fair database to work on (please note the size if reported after a full VACUUM). In such database, I’ve a table root that handles a lot of data from hardware sensors; such table is of course partitioned on a time base scale. One thing the table was storing was information about the sensor name, a text string repeated over and over on child tables too. While this was not a problem in the beginning, it was wasting space over time.

Shame on me!

Let’s go normalize the table!
Normalizing a table is quite straightforward, and I’m not interesting in sharing details here. Let’s say this was quite easy because my...

カテゴリー: postgresql

PHP 7.1.30 Released

php.net - 2019-05-31(金) 02:03:08
カテゴリー: php

Rhythmbox XML Parsing to Copy Playlists to Phone or USB Stick

planet PHP - 2019-05-30(木) 23:45:00

I was recently faced with the issue of physically moving all the songs I’d given five stars in Rhythmbox to a phone.... Read More

カテゴリー: php

PHP 7.2.19 Release Announcement

php.net - 2019-05-30(木) 23:19:20
カテゴリー: php

Dimitri Fontaine: Introducing pg_auto_failover: A high availability and automated failover Postgres extension

planet postgresql - 2019-05-30(木) 23:02:00

As part of the Citus team (Citus scales out Postgres horizontally, but that’s not all we work on), I’ve been working on pg_auto_failover for quite some time now and I’m excited that we have now introduced pgautofailover as Open Source, to give you automated failover and high availability!

When designing pg_auto_failover, our goal was this: to provide an easy to set up Business Continuity solution for Postgres that implements fault tolerance of any one node in the system. The documentation chapter about the pgautofailover architecture includes the following:

It is important to understand that pgautofailover is optimized for Business Continuity. In the event of losing a single node, then pgautofailover is capable of continuing the PostgreSQL service, and prevents any data loss when doing so, thanks to PostgreSQL Synchronous Replication.

Introduction to pgautofailover

The pg_auto_failover solution for Postgres is meant to provide an easy to setup and reliable automated failover solution. This solution includes software driven decision making for when to implement failover in production.

The most important part of any automated failover system is the decision making policy, and we have a whole documentation chapter online about pgautofailover faul tolerance mechanisms.

When using pgautofailover, multiple active agents are deployed to keep track of your production Postgres setup properties:

  • the monitor, a Postgres database itself equipped with the pg_auto_failover extension, registers and checks the health of the active Postgres nodes.

  • each Postgres node that is registered in the pg_auto_failover monitor must also run a local agent, the pg_autoctl run service.

  • each Postgres service that is managed has two Postgres nodes set up together in the same group. A single monitor setup may manage as many Postgres groups as needed.

With such a deployment, the monitor connects to every registered node on a regular schedule (20s by default) and registers success or failure in its pgautofailover.node table.

In additio

カテゴリー: postgresql

PHP 7.3.6 Release Announcement

php.net - 2019-05-30(木) 18:11:36
カテゴリー: php

PHP 7.1.30 Released

planet PHP - 2019-05-30(木) 09:00:00
The PHP development team announces the immediate availability of PHP 7.1.30. This is a security release.All PHP 7.1 users are encouraged to upgrade to this version.For source downloads of PHP 7.1.30 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
カテゴリー: php

PHP 7.3.6 Release Announcement

planet PHP - 2019-05-30(木) 09:00:00
The PHP development team announces the immediate availability of PHP 7.3.6. This is a security release which also contains several bug fixes.All PHP 7.3 users are encouraged to upgrade to this version.For source downloads of PHP 7.3.6 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
カテゴリー: php

PHP 7.2.19 Release Announcement

planet PHP - 2019-05-30(木) 09:00:00
The PHP development team announces the immediate availability of PHP 7.2.19. This is a security release which also contains several minor bug fixes.All PHP 7.2 users are encouraged to upgrade to this version.For source downloads of PHP 7.2.19 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
カテゴリー: php

Dave Page: Avoiding Gmail's confidential mode

planet postgresql - 2019-05-30(木) 06:11:00
So this is one of the very few (maybe the first?) blog entries I've written that aren't directly related to PostgreSQL, however, it does affect how I (and others) may work on the project.

Last night I received email from Google about my personal G Suite account which I use for all my day-to-day email, which for the most part is related to work on pgAdmin and PostgreSQL. Google were proudly announcing the rollout of their new Gmail Confidential Mode update. If you've not come across this yet, then essentially what it does is allow users to send emails that can be deleted or expired after a certain amount of time, optionally require SMS verification to open them, and prevent printing (but not screen-shots of course), forwarding or downloading etc.

When using the Gmail web interface, this all works fairly seamlessly. I can see why some people would want it if that's all they use, however, like many people, I also use other clients, for example, via IMAP. In that case, instead of the original email Gmail sends a placeholder email to replace the actual message which contains a link to allow you to login to Google and view the message online (assuming the SMS verification passes and the message hasn't been deleted or expired of course). That's going to be quite inconvenient to me, besides which, I really don't want anyone to be able to control access to emails they've sent me, after I've received them.

There's another problem affecting PostgreSQL's mailing lists however. How long will it be until someone sends such a message to one of the PostgreSQL lists, where it will do nothing but clutter up the archives and annoy other users (who won't be able to read the message anyway as they won't be able to login to Google as pgsql-hackers@postgresql.org or whatever the list address was)?

Fixing the PostgreSQL mail servers After some discussion with some of the PostgreSQL sysadmin team, we discovered that Gmail adds a header to the messages that have confidential mode enabled (X-Gm-Locker: <token>). This is easy for us to [...]
カテゴリー: postgresql