Beautiful Maps

beautifulmaps

Truly a collection of beautiful maps. A shame it’s not possible to watch the full resolution variants of the maps.

Beautiful Maps →

Elsewhere , , Leave a comment

Flexbox Cheatsheet Cheatsheet

flexboxsheet-extract

I set out to create a quick visual to summarize Flexbox when I run into these moments of pause in the future. I like to think of it as a little diagram (flow chart? decision tree-ish thing?) that is a cheatsheet…based on cheatsheets.

(That’s only an extract, shown above)

Flexbox Cheatsheet Cheatsheet →

Elsewhere , , , Leave a comment

Axiomatic CSS and Lobotomized Owls

owl_1

Despite its irreverent name and precarious form, the lobotomized owl selector is no mere thought experiment for me. It is the result of ongoing experimentation into automating the layout of flow content. The owl selector is an “axiomatic” selector with a voracious purview. As such, many will be hesitant to use it, and it will terrify some that I include it in production code. I aim to demonstrate how the selector can reduce bloat, speed up development, and help automate the styling of arbitrary, dynamic content.

An ode to the underused adjacent sibling selector (+), in combination with the universal selector (*)

Axiomatic CSS and Lobotomized Owls →

Elsewhere , Leave a comment

The end of apps as we know it

end-of-apps-6

The idea of having a screen full of icons, representing independent apps, that need to be opened to experience them, is making less and less sense. The idea that these apps sit in the background, pushing content into a central experience, is making more and more sense. That central experience may be something that looks like a notification centre today, or something similar to Google Now, or something entirely new.

The primary design pattern here is cards. Critically it’s not cards as a simple interaction design pattern for an apps content, but as containers for content that can come from any app.

The idea of cards, taken to the next level … “the notification is the interface”.

The end of apps as we know it →

Elsewhere , Leave a comment

Vertical centering is impossible in CSS lol!

JS Bin

Great JSBin by Jake Archibald, showcasing 4 ways to vertically center elements in CSS. Technique 2 has my preference:

.technique-2 {
  position: absolute;
  height: auto;
  top: 50%;
  -webkit-transform: translateY(-50%);
  transform: translateY(-50%);
}

The great thing about CSS transforms is that the percentages are referenced to the element’s width/height

Elsewhere , Leave a comment

PHP 5.6: “Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version.”

Since PHP 5.6, the use of $HTTP_RAW_POST_DATA is deprecated. Now, I’m not using this so I’m in the clear, or at least I thought I was …

tl;dr The default value for always_populate_raw_post_data in PHP 5.6 is doing more harm than good. Perfectly good code will spit out that error whenever it receives a request that has a (non-application/x-www-form-urlencoded encoded) payload. To fix it, explicitly set the value of always_populate_raw_post_data to -1 in your php.ini.

The problem

As mentioned in the link above, a warning will be triggered when always_populate_raw_post_data — a setting in php.ini — is enabled:

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0

A, to me, rather unfortunate decision is the fact that the default php.ini which ships with PHP 5.6 has this setting not set to -1, but has it commented out.

This results in the fact that the setting is set to 0, yet it — miraculously? (Not really, more on that later) — also results in the fact that the warning is shown whenever your script receives a request which uses a payload, whether you use $HTTP_RAW_POST_DATA or not.

A POST request, using application/x-www-form-urlencoded encoded data (default form encoding), will work fine:

$ curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "foo=bar" http://domain.tld/

A POST request, using application/json encoded data (not uncommon in the age of Hypermedia APIs), will output the warning even if you don’t use $HTTP_RAW_POST_DATA in the receiving PHP script:

$ curl -X POST -H "Content-Type: application/json" -d "{foo: bar}" http://domain.tld/

If you’re more a JavaScript type of guy/gal, here’s how to trigger it (using jQuery):

$.ajax({
	url: 'http://domain.tld/',
	type: 'POST',
	data: {foo: 'bar' },
	contentType: 'application/json; charset=utf-8'
});

The fix

The fix is to set always_populate_raw_post_data to -1. Unfortunately it’s not possible to override this value using ini_set (again, more on that later), so one actually has to set it in php.ini. Another option is to add php_value always_populate_raw_post_data -1 to your Apache config.

Using MAMP Pro, you can set it per host (if you want):

mamp-pro-rawdata

Unfortunately, not everyone has access to their php.ini, or their Apache httpd.conf. When on a shared hosting account you are dependent on the goodwill of the hosting provider. If they’re not that PHP savvy, they might refuse to change the value. This results in the fact that perfectly working libraries — which don’t even use $HTTP_RAW_POST_DATA — will not work properly on default PHP 5.6 installations! To me, this is rather unacceptable: you do everything right, yet PHP still complains for no apparent reason.

The proper fix / An explanation

When looking at the PHP bug report covering this issue it becomes clear that the warning is shown when $HTTP_RAW_POST_DATA is being populated. Now, this is odd at first sight, as always_populate_raw_post_data is set to 0 (#wat?) yet there’s an explanation for that: always_populate_raw_post_data=0 does not mean, that $HTTP_RAW_POST_DATA won’t be populated, it only means, that it will be only populated when a supported MIME type is present” (source) … so 0 is falsy, but not for this setting :(

Other arguments in the bug report covering the issue are that it is technically difficult to only show the notice when that variable is actually being accessed

Now, I understand that the PHP developers don’t want to break backwards compatibility: shipping with a default -1 would cause issues as scripts relying on $HTTP_RAW_POST_DATA will break. On the other hand, not setting it to -1 by default also breaks stuff: the notice will not allow you to do proper redirects anymore (headers already sent should ring a bell), JSON output becomes invalid, etc.

So no, I don’t agree with the excuse that “it’s technically difficult”. If a setting is causing trouble whether it’s on or off, then a better solution should be found. I see three possible solutions. Here goes, in order of preference:

  1. Do ship with -1 as default. If you’re using $HTTP_RAW_POST_DATA, you’re doing it wrong.
  2. Make PHP properly honor the 0 value: When setting always_populate_raw_post_data to 0which it is by default — then $HTTP_RAW_POST_DATA should not be populated and the notice should not be shown.
    Yes, that would mean reverting the always_populate_raw_post_data=0 does not mean, that $HTTP_RAW_POST_DATA won’t be populated, it only means, that it will be only populated when a supported MIME type is present” behaviour (who’s impact I am not aware of).
  3. Although that indeed would be technically impossible (as $HTTP_RAW_POST_DATA is populated in the bootstrapping phase of the PHP process) allow one to override the setting by means of calling ini_set.

As options 2 and 3 already have been shot down in the bug report thread, or are virtually impossible; only option 1 remains. So please, core PHP devs, reconsider shipping PHP a default always_populate_raw_post_data -1 in following releases.

Yes, I am aware that you should not display errors on screen in production, yet during development they are. As you don’t have to do an awful lot to trigger the warning, it is confusing for beginning developers. In my job — a lecturer webdev — it’s really strange to have to explain to my students that they’re actually not doing anything wrong but that it’s PHP’s defaults that are the culprit. Their first reaction in such cases always is: “then why is it the default value?”

Elsewhere 3 Comments

You suck at technical interviews

You are bad at giving technical interviews. Yes, you. You’re looking for the wrong skills, hiring the wrong people, and actively screwing yourself and your company. Without changing anything about your applicant pool, you can hire different people and your company will do better and you will enjoy your job more.

A must read for anyone who ever had / will have to grill a future employee.

You suck at technical interviews →

Elsewhere , Leave a comment

PerfMap: front-end performance heatmap

perfmap

A bookmarklet to create a front-end performance heatmap of resources loaded in the browser using the Resource Timing API. Wait for a page to fully load and then click the bookmarklet to overlay a performance heatmap. A browser with support for the Resource Timing API is required.

PerfMap: front-end performance heatmap →

Elsewhere , , , , Leave a comment

PHP Null Coalesce Operator

The coalesce operator – ?? – returns the result of its first operand if it exists and is not NULL, or else its second operand. That indeed means that it won’t raise an E_NOTICE, and affords you to write shorter code:

// Fetches the request parameter user and results in 'nobody' if it doesn't exist
$username = $_GET['user'] ?? 'nobody';
// equivalent to: $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';
 
// Calls a hypothetical model-getting function, and uses the provided default if it fails
$model = Model::get($id) ?? $default_model;
// equivalent to: if (($model = Model::get($id)) === NULL) { $model = $default_model; }
 
// Parse JSON image metadata, and if the width is missing, assume 100
$imageData = json_decode(file_get_contents('php://input'));
$width = $imageData['width'] ?? 100;
// equivalent to: $width = isset($imageData['width']) ? $imageData['width'] : 100;

Looking forward to this one :)

PHP RFC: Null Coalesce Operator →

Did you know you can also omit the 2nd parameter from the ternary operator in PHP, since version 5.3? The expression expr1 ?: expr3 returns expr1 if expr1 evaluates to TRUE, and expr3 otherwise.

Elsewhere , 2 Comments

What Will It Take to Run a 2-hour Marathon?

marathon

The current world record of 2:02:57, set by Kenyan Dennis Kimetto this year in Berlin, works out to 4:41.5 per mile; a sub-two would require less than 4:35 per mile. Will a human ever run that fast?

Some fascinating number-crunching, and some great conclusions/predictions too.

What Will It Take to Run a 2-hour Marathon? →

Elsewhere , , , Leave a comment