Last week I took part in the first ever Symfony Catalunya conference. The conference was a major event in Barcelona, attracting 400+ Symfony developers. It seems that most of the attendees were from Spain or Catalunya. I was surprised to see that some Dutch people were present too!
At Ibuildings we had been anticipating DPC 2016 for quite some time. Our internal DPC crew rebooted in January, starting with an update of the website and a mailing to announce that the Call for Papers was open again. We received about 350 proposals, which we narrowed down to 55 talks and 11 tutorials. It seems we made a good selection of talks, since many people complained that it was hard to pick the right talk to watch, given there are 5 parallel talks at any time...
Last week I've been attending, and speaking at, the NCrafts conference in Paris. It was a great conference, which had many talks to offer on wide-ranging topics that should make any software craftsman/craftswomen quite happy. Below you will find some remarks, summaries, notes, etc. related to the talks I visited on the first day of the conference.
As you may know, this year's Dutch PHP Conference will again take place in Amsterdam in a well-known convention centre called "RAI". At the end of the Tutorial Day we will head back to the centre of town for the second edition of the Code Night...
A while ago, somebody asked me for some reading material on JavaScript best practices. This was the moment I realized that Douglas Crockford's JavaScript: The Good Parts is actually outdated.
Last time I blogged about DPC, we were still waiting for some speakers to confirm their presence. Now I can tell you that the schedule is complete (with some of the more recent additions: Sara Goleman with talks on HHVM extensions and types, and Christopher Pitt on functional programming and automation). Don't forget to buy your tickets - Early Bird prices are available until April 22nd!
Now it's time to shine a bit more light on the tutorial day, right before the main conference days (on June 23rd). We have made quite a broad selection of topics:
Do you want your websites users to log in? For certain types you would, but often there is no need. The Ibuildings website does not allow you to register an account and log in. Why would it?
However by default Drupal 8 (and earlier) considers logging in on /user part of the frontend theme. This means that either you have to theme it or accept a horribly broken login page.
Or you could convince Drupal to apply the admin theme to user pages.
A couple of weeks ago we announced the schedule for the Dutch PHP Conference. I already mentioned that we have a great selection of experienced speakers as well as many speakers who are less familiar with the conference stage but are eager (and ready) to take it. At the main conference days we have 5 tracks packed with interesting talks. At the beginning of the first day and at the end of the second day we'll have a keynote. Let me briefly introduce the keynote speakers to you now!
It's been a great honor to receive a total of 350 talk and tutorial proposals for the 10th edition of our annual Dutch PHP Conference. Proposals covered a wide range of topics. Many talk proposals had been submitted by experienced speakers, some by absolute beginners. A number of speakers seems to have proven their skills at local meetups and are now ready to take the stage on a conference like DPC, where there might be a 100 or up to 220 people listening to you.
This is the first blog post in what will hopefully become a new series where we look at old Drupal 7 & 8 security advisories (at least 3 months ago so they should be patched everywhere) and try to learn from the mistakes of others.
As a first post I'd like to pick an older vulnerability, one I've used in presentations to demonstrate how hard it can be to properly apply HTML encoding for Drupal.
If you want to know what JavaScript really is, you have to look beyond just the language. In contrast to PHP, there are several platforms that it runs on. And then there’s the ecosystem, which is nothing like the one PHP has.
In the previous parts of this series we looked at how to get rid of complexity at the level of algorithms. After discussing the problem of nulls in your code, we looked at object lifecycles and how to encapsulate them properly. Now that we have objects that can be constructed and changed only in valid ways, we need to look at how they communicate with each other and how we can improve our code with regard to that aspect.
This year Ibuildings will host the Dutch PHP Conference (DPC) in Amsterdam for the tenth time in a row, on June 23rd - 25th. As you may have noticed, since a couple of weeks you can send in your tutorial or talk proposals. The Call for Papers closes on February 22nd.
In the first part of this series we looked at ways to reduce the complexity of function bodies. The second part covered several strategies for reducing complexity even more, by getting rid of null in our code. In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.
In the previous part of this series we looked at what are basically a lot of guidelines for achieving "clean code". In this part I'd like to take a closer look at something we call null. Our main goal will be: to get rid of it.
PHP is pretty much a freestyle programming language. It's dynamic and quite forgiving towards the programmer. As a PHP developer you therefore need a lot of discipline to get your code right. Over the years I've read many programming books and discussed code style with many fellow developers. I can't remember which rules come from which book or person, but this article (and the following ones) reflect what I see as some of the most helpful rules for delivering better code: code that is future-proof, because it can be read and understood quite well. Fellow developers can reason about it with certainty, quickly spot problems, and easily use it in other parts of a code base.
