George R.R. Martin, on his blog “Not a Blog”, now that the final episode of Game of Thrones has aired:
I’m writing. Winter is coming, I told you, long ago… and so it is. THE WINDS OF WINTER is very late, I know, I know, but it will be done. I won’t say when, I’ve tried that before, only to burn you all and jinx myself… but I will finish it, and then will come A DREAM OF SPRING.
How will it all end? I hear people asking. The same ending as the show? Different?
Well… yes. And no. And yes. And no. And yes. And no. And yes.
And oh, I especially like GRRM’s closing paragraph in his post:
Book or show, which will be the “real” ending? […] How about this? I’ll write it. You read it. Then everyone can make up their own mind, and argue about it on the internet.
Really looking forward to the books, as the final season on TV was quite the disappointment. Next to some very poor dialogues this season was packed with inconsistencies, character development that got thrown out of the window, lots of loose ends … the number of WTFs per episode was rising way too fast imho.
See, for example, this narrated version of Episode 3 to see what I’m talking about:
(Same thing can be said for all other episode in the season)
Great read on how a few YouTube engineers bypassed the internal Google politics in order to abolish IE6 from their list of supported browsers:
One idea rose to the surface that quickly captured everyone’s attention. Instead of outright dropping IE6 support, what if we just threatened to? How would users react? Would they revolt against YouTube? Would they mail death threats to our team like had happened in the past? Or would they suddenly become loud advocates of modern browsers?
If you’re selling PHP packages, the easiest way to offer Composer package installation to your customers is now “Private Packagist for Vendors”. You get a unique URL and authentication token for each customer and they can use these in their composer.json file to install your packages. Especially if you’re still sending zip files to your customers, there is really no reason anymore not to to offer Composer installations.
You can use their our API to integrate “Private Packagist for Vendors” with your existing PHP package shop: Create a customer, grant the customer access to the package, and then get the info needed to send to the customer — all using their API.
// 1. Create Customer
$customer = $client
->create('Acme Web Inc.');
// 2. Grant access to package for customer
'name' => 'my-vendor/cool-package',
'versionConstraint' => '^1.0',
'expirationDate' => strtotime('+1 year'),
// 3. Get info to send to user
$info = $client->customers()->show($customer['id']);
// 'composerRepository' => [
// 'url' => 'https://my-vendor.repo.packagist.com',
// 'user' => 'token',
// 'token' => 'a6addb89a67b2822d352d113',
As you can see in the code above, customers their access can be locked to specific versions and also limited in time.
How do we create a package that exposes both CommonJS & ES modules while making sure we don’t break cross-platform support? Publishing 2 separate packages is an option (e.g. lodash/lodash-es). But there is a nicer, more maintainable option that obviates the need to publish twice. We can provide an extra build step that creates an ES version of our package and links it via package.json.
The other day I opened up a PHP project that I hadn’t worked on in a while. No longer remembering which Composer Scripts I had defined for it, I needed to take a peek inside composer.json to see which ones were available to me. Then it hit me: why is there no autocompletion for composer available?
The code builds further upon this earlier work by Rob Allen. Key area where it differs from Rob’s work is that composer-autocomplete also provides autocompletion for composer run-script, listing which Composer Scripts are available to you(as I initially wanted).