フィードアグリゲーター

Akra's DevNotes: Slim 4 Cyclomatic Complexity

phpdeveloper.org - 2019-04-03(水) 22:30:02

There's not much wrong with Slim 3; lots of people are using it very successfully producing APIs and websites of all kinds. For Slim 4 the main goals have been to support PSR-15, make it easier to use your own PSR-7 implementation, improve error handling and remove assumptions that look magical if y...

カテゴリー: php

Slim 4 Cyclomatic Complexity

planet PHP - 2019-04-03(水) 19:02:00

There's not much wrong with Slim 3; lots of people are using it very successfully producing APIs and websites of all kinds. For Slim 4 the main goals have been to support PSR-15, make it easier to use your own PSR-7 implementation, improve error handling and remove assumptions that look magical if you don't know they are there. The latter one is the most important to me, personally!

Secondarily, Pierre has concentrated on making Slim's code more flexible and hopefully making it easier to swap out our internal components with your own if you need to. On a whim, I ran phploc on the current Slim 3 and Slim 4-dev codebases to see what differences were. The full results are in this gist.

Note that Slim 4 doesn't have the PSR-7 implementation or the container wrapper, so it's maybe not possible to directly compare some of the numbers, but the cyclomatic complexity numbers are interesting and a direct outcome of Pierre's work:

Slim 3 Slim 4-dev Cyclomatic Complexity Average Complexity per LLOC 0.30 0.18 Average Complexity per Class 10.40 4.76 Minimum Class Complexity 1.00 1.00 Maximum Class Complexity 67.00 25.00 Average Complexity per Method 2.44 2.05 Minimum Method Complexity 1.00 1.00 Maximum Method Complexity 15.00 15.00

Cyclomatic complexity is a measure of the complexity of a codebase. It's really hard to ensure that a method with a high cyclomatic complexity works as intended and I'm delighted to see these numbers go down! Hopefully this means that Slim 4's internals are easier to understand and it will be easier to contribute to.

We need to find, assess and simplify the method that has that 15.00 though!

カテゴリー: php

Laurenz Albe: count(*) made fast

planet postgresql - 2019-04-03(水) 17:00:28
© Laurenz Albe 2019

 

It is a frequent complaint that count(*) is so slow on PostgreSQL.

In this article I want to explore the options you have get your result as fast as possible.

Why is count(*) so slow?

Most people have no trouble understanding that the following is slow:

SELECT count(*) FROM /* complicated query */;

After all, it is a complicated query, and PostgreSQL has to calculate the result before it knows how many rows it will contain.

But many people are appalled if the following is slow:

SELECT count(*) FROM large_table;

Yet if you think again, the above still holds true: PostgreSQL has to calculate the result set before it can count it. Since there is no “magical row count” stored in a table (like it is in MySQL’s MyISAM), the only way to count the rows is to go through them.

So count(*) will normally perform a sequential scan of the table, which can be quite expensive.

Is the “*” in count(*) the problem?

The “*” in SELECT * FROM ... is expanded to all columns. Consequently, many people think that using count(*) is inefficient and should be written count(id) or count(1) instead. But the “*” in count(*) is quite different, it just means “row” and is not expanded at all.

Writing count(1) is the same as count(*), but count(id) is something different: It will only count the rows where id IS NOT NULL, since most aggregates ignore NULL values.

So there is nothing to be gained by avoiding the “*”.

Using an index only scan

It is tempting to scan a small index rather then the whole table to count the number of rows.
However, this is not so simple in PostgreSQL because of its multi-version concurrency control strategy. Each row version (“tuple”) contains the information to which database snapshot it is visible. But this information is not (redundantly) stored in the indexes. So it usually isn’t enough to count the entries in an index, because PostgreSQL has to visit the table entry (“heap tuple”) to make sure an index entry is visible.

To mitigate this problem, PostgreSQL has introduced the visibility ma

[...]
カテゴリー: postgresql

Magnus Hagander: When a vulnerability is not a vulnerability

planet postgresql - 2019-04-03(水) 04:39:50

Recently, references to a "new PostgreSQL vulnerability" has been circling on social media (and maybe elsewhere). It's even got it's own CVE entry. The origin appears to be a blogpost from Trustwave.

So is this actually a vulnerability? (Hint: it's not) Let's see:

カテゴリー: postgresql

Laravel News: PhpStorm 2019.1 Blade Debugging Support and a Laravel Code Style Preset

phpdeveloper.org - 2019-04-03(水) 04:00:02
JetBrains announced the release of PhpStorm 2019.1 this week with debugging support for Blade (and Twig) templates and a new predefined Laravel code style configuration. Visit Laravel News for the full post. The post PhpStorm 2019...
カテゴリー: php

Tomáš Votruba Blog: How to Mock Final Classes in PHPUnit

phpdeveloper.org - 2019-04-03(水) 01:30:01

Do you prefer composition over inheritance? Yes, that's great. Why aren't your classes final then? Oh, you have tests and you mock your classes. But why is that a problem?

カテゴリー: php

php|architect: Migrating Legacy Web Applications to Laravel

phpdeveloper.org - 2019-04-03(水) 00:34:10

By Barry O’Donovan Thanks to Taylor Otwell’s Laravel framework, PHP is reclaiming its rightful place as the go-to language for web application development. For those of us maintaining and developing applications using legacy frameworks, the grass certainly looks greener on Laravel’s ...

カテゴリー: php

Tomáš Votruba Blog: Removing Static - There and Back Again

phpdeveloper.org - 2019-04-03(水) 00:30:02

The more companies I meet, the more I see static and new everywhere. Not like new Product, but rather new ProductRepository(new Database()). Not just Laravel, but across all PHP frameworks. I wish frameworks could prevent antipatterns, but they don't, do they?

Instead of "refactor all the things" step by step, class by class, I'd like share my thoughts when exploring full automated path. I look for feedback to improve this process.

カテゴリー: php

PHP Podcasts: 145:Breakfast with a Listener

phpdeveloper.org - 2019-04-03(水) 00:03:26

This week, Eric, Thomas, and John discuss:

Laravel 5.8 update breaks third-party composer libraries · Issue #27949 · laravel/framework Unique Rule SQL Injection Warning - The Laravel Blog Be Careful: Laravel 5.8 Added bigIncrements As Defaults - Laravel Daily Security researchers reveal defects that allow wireless hijacking of giant construction cranes, scrapers and excavators

カテゴリー: php

418 I'm a teapot

planet PHP - 2019-04-03(水) 00:00:00

The IETF has a tradition to publish one or more april-fools RFC documents every year. Among the most famous are IP over Avian Carriers with Quality of Service, and of course Hyper Text Coffee Pot Control Protocol, which introduced the 418 I'm a teapot HTTP status.

This status-code is of course not an official one. You won’t find it in the IANA HTTP Status code registry. However, people have such a liking to it that it’s supported in many HTTP libraries.

About a year ago, the HTTP working group tried to reach out to various projects to try and remove their support for 418, so the number could be re-used for a new purpose, but this was met with a lot of resistance, even spawning https://save418.com.

Several implementations of HTCPCP can be found, including:

The 418 code also appears as easter eggs in numerous systems.

Wikipedia has a page on all the IETF april fools jokes, which is well worth a read. It also features the HTCPCP-TEA extension!

All we need now is a WHATWG living standard that just solidifies everyone’s buggy implementations (looking at you URL standard), and a W3C committee that forks it once per year.

References & sources
カテゴリー: php

Doug Hunley: Enhancing Your PostgreSQL 10 Security with the CIS Benchmark

planet postgresql - 2019-04-02(火) 23:59:37

 Crunchy Data has recently announced an update to the CIS PostgreSQL Benchmark by the Center for Internet Security, a nonprofit organization that provides publications around standards and best practices for securing technologies systems. This newly published CIS PostgreSQL 10 Benchmark joins the existing CIS Benchmarks for PostgreSQL 9.5 and 9.6 while continuing to build upon Crunchy Data's efforts with the PostgreSQL Security Technical Implementation Guide (PostgreSQL STIG).

What is a CIS Benchmark?

As mentioned in an earlier blog post, a CIS Benchmark is a set of guidelines and best practices for securely configuring a target system.  The benchmark contains a series of recommendations that help test the security of the system: some of the recommendations are "scored" (where a top score of 100 is the best), while others are are provided to establish best practices for security.

カテゴリー: postgresql

Technical Thoughts, Tutorials, and Musings: PSR-14: Advanced Providers

phpdeveloper.org - 2019-04-02(火) 23:45:59

PSR-14: Advanced Providers

In part 3 of our series we looked at some common Provider patterns for PSR-14. But the flexibility and complexity of Providers is limited only by your imagination. Today we'll look at a few more interesting examples of Providers that are all equally valid but tailored to particular use cases.

カテゴリー: php

Dave Conlin: Postgres indexes for absolute beginners

planet postgresql - 2019-04-02(火) 22:45:00

Indexes are really important for Postgres performance, but they’re often misunderstood and misapplied. This post aims to give you a good grounding in indexes to avoid a lot of beginner mistakes.

Step one: understand what you want to achieve

Because indexes are such a powerful tool, a new index is often viewed as “the answer” to whatever performance problems people are experiencing. Wading straight in and creating an index for every sequential scan in sight is the simplest thing to do, but indexes have costs as well as benefits.

Not only do indexes take up memory, they raise the cost of writing to the table in question. Any speed-up an index may provide for reads isn’t free — it’s offset by more work to keep the index up to date when the data in the table change. So an unused index isn’t just useless — it’s actively harmful to your database’s performance.

First, take the time to understand which bits of your query are running slowly (use the query plan), make a hypothesis as to why they’re slow, and then validate that hypothesis by attempting to speed them up.

In order to understand when the answer might be an index, it’s important to understand the difference between sequential scans and index scans in Postgres.

Sequential scans

Sequential scans are the simplest, most obvious way of reading data from a table. Postgres jumps to the first block of memory (“page”) that holds rows for the table in question and reads in all the data, row by row, page by page, and passes it on.

Sequential scans can get a bit of a bad rap. One of the things we often hear from people when we ask them about their current performance analysis is “the first thing I do is look for sequential scans”.

It’s true that using an index on a table can make a big difference to query performance, but it’s also true that if your query just needs to get all of the data from a table in an unordered mass of rows, then things aren’t going to get any more efficient than just reading those rows in directly from consecutive pages.

Index scans

An index is jus

[...]
カテゴリー: postgresql

Interview with Olivia Liddell

planet PHP - 2019-04-02(火) 20:00:00

@oliravi Show Notes

Audio

This episode is sponsored by


The post Interview with Olivia Liddell appeared first on Voices of the ElePHPant.

カテゴリー: php

SymfonyCon Amsterdam 2019

php.net - 2019-04-02(火) 19:28:14

Symfony is proud to organize the seventh edition of the SymfonyCon, the international Symfony conference. This year, we decided to bring the entire community to the Netherlands and discover the amazing city of Amsterdam. If you like Symfony and share fun with professionals, this is where you want to be on November!

We look forward to welcoming you to Amsterdam, capital of the Netherlands. Join us for talks, workshops, discussions and other serious work around Symfony and its environment. And of course, celebrate the community reunion!

SymfonyCon Amsterdam is a 5-day event from November 19th to November 23rd:

Two-day workshop: Tuesday, November 19th and Wednesday, November 20th

Two-day conference: Thursday, November 21st and Friday, November 22nd

One hackday: Saturday, November 23rd

カテゴリー: php

SymfonyLive Berlin 2019

php.net - 2019-04-02(火) 19:24:43
カテゴリー: php

SymfonyLive London 2019

php.net - 2019-04-02(火) 19:23:10
カテゴリー: php

SymfonyLive Warszawa 2019

php.net - 2019-04-02(火) 19:21:12
カテゴリー: php

SymfonyLive São Paulo 2019

php.net - 2019-04-02(火) 19:13:07
カテゴリー: php

ページ