nschoenmaker.nl

A lot of nice stuff is happening in the PHP ecosystem right now. In this case I’m not talking about the PHP 5.5 RC3 that was released lately, since that will take a bit more time to be released, let alone be available for the world to use. I’m talking about the Symfony 2.3 release, which I’ve been looking forward to. Partially because it’s the first LTS*, but also because it continues to split Symfony up into individual components.

After the stopwatch and the property access components in Symfony 2.2, we now get the new debug and intl components. These might not be the most exiting components in the world, but it’s a sign of a bigger trend in the PHP ecosystem: releasing individual components. This has been going once for the past two years, since Symfony 2.0 was initially released.

So slowly there are more and more components emerging. Partially this is because PSR-1 and PSR-2 have brought use a shared coding style. Partially this might be because individual components are easier to understand. Mostly this is about composer though.

Composer: Changing the PHP ecosystem

Composer is a dependency manager for PHP. There are a couple of benefits in using it:

• Autoloading. This might seem like a basic thing, but it’s very relaxed to not have to think about it any more.
• Lightweight. Only include the components you actually want.
• Mix and match. In the past you’d pick one framework, and then hope it had the components you wanted. Now you can pick the best individual components for the job.
• Security awareness. If you use composer, you can check your dependencies for known security issues.
• Visibility. All your dependencies are stored inside your vendor/ directory.
• Control. Manage your dependencies yourself.
• Dependency awareness. Knowing which components depend on what gives understanding. Just show a graph of your current dependencies using clue/graph-composer. The graph below displays the dependencies of the symfony/translation component.

When using composer, there are two questions that come up a lot

• Has this problem been solved before?
• Could this be a library?

And both of those lead to a lot more code reuse, which is good.

Downsides?

Every story has two sides, so that probably applies here as well. Developers tend to like the new and shiny, but lets look at the story from two sides.

• You might run into the Composer API limit at GitHub.
• What if GitHub is down? What if packagist is down?
• Packagist funding.
• Managing dependencies can take time.
• Conflicts on your composer.lock can be annoying.

Balance

For me the balance is very positive. With over 6 million package installs last month, it seems a lot of other people agree. The real question might even be

When will Composer be an integral path of the official PHP release?

* Long Term Support (LTS) means it will be supported until the end of May 2016. Yes, that is a whopping three year period of security patches!

Yesterday I was invited with a colleague to join the Agile event 7 at the Arrows Group. The speakers were very interesting, Maarten Hoppen and Jeff Sutherland. Jeff Sutherland is one of the inventors of scrum, so I was eager to go. For the people that think he’s that means he’s the inventor of this…

He’s not. Scrum is a way of being productive with a group, of developing software in a incremental and agile way. When Jeff Sutherland was inventing scrum, he really looked at the rugby game*. Why are some teams really successful, while others lay behind? One of the answers that he found was that the best teams were pushing themselves to improve. Fighting to become better every sprint. In sports doing nothing is standstill.

For a part his talk was about convincing people that scrum is a good thing to do. Since this was an agile event, I guess no-one in the room needed to be convinced of that. Anyway, one graph he showed was this guy. A lot less failed projects, but we should still be able to do better then this. But how to improve?

Scrum anti patterns at Agile Event 7

One of the scrum anti patterns that Jeff Sutherland mentioned was in handling interruptions in a bad way. It’s a challenge that a lot of teams face: unplanned change. The blog post dealing with emergencies explains the problem and possible solutions very well!

After the presentation there was a workshop, and after that there was a short Q&A session. One of the questions asked was about communicating scrum results towards management. One of the most powerful ways of communicating to management how good a team is doing is by comparing the velocity of a team. So far we haven’t really been measuring that, but I think we should give it a try.

* A lot of sport references. He’s not a rugby player though .

All credits for the rugby scrum image go to Pierre Selim, who released it under the Creative Commons Attribution-Share Alike 3.0 Unported license.

Yesterday I bought the Humble Indie Bundle 8. The game that triggered this was Awesomenauts, it’s a fast paced DOTA game (with a lousy story, of course). Anyway, a video will explain this more clearly.

Playing Awesomenauts feels like playing Fat Princess. The trailer makes it seem a bit shallow, but there are a lot of tactical considerations

• A ton of different characters to pick from
• For every character you have to pick which skills will be available for purchase in game. A bit like having a talent tree in World of Warcraft, except you can change it every match.
• You have a “drill core” in your own base that you have to protect. Unlike your random capture the flag, or Fat Princess, the thing in your base does not recover once it gets hit. So if it gets attacked, you will be there.
• The real power of the game is probably to play it split screen and online. I’m really curious to see the balance of it all, will certainly give it a try.

Next to that it also has some “meta” stuff going for it

• It’s available cross-platform. And since Steam is available on Linux now, I was able to add all of these games to my Steam account.
• It’s made in the Netherlands, so go Romino games!
• Buying the Humble bundle also supports charity.

Getting the Humble Indie Bundle 8

If you like the game, you can still buy the Humble Indie Bundle 8 for one more week.

The Symfony2 form component has a very nice way of validating: using annotations. These validation annotations give you the ability to annotate one or more invariants in the documentation of the properties of your class. These are automatically read and validated! Talking about up-to-date documentation. You can describe invariants like this in your entities:

/**
* @Assert\Length(min=2, max=255)
*/
private $company_name;

Since we’re living in a world where it’s easy to pick the precise components you want with composer, that’s exactly what we’re going to do. This article is for people using the symfony/form component or the hostnet/form-twig-bridge that want to use the validation annotations.

If you don’t have the form framework up and running yet, read this readme first.

Step 1: Including required components

Next to the form and validation components you’re also need to require these packages in your composer.json:

"doctrine/annotations": ">=1.0",
"doctrine/cache": ">=1.0"

These are two small libraries, originally part of Doctrine, but very usable without it as well.

Step 2: Read the validation annotations

Using the form-twig-bridge:

$builder->enableAnnotationMapping();

Or using the raw Symfony2 components:

$builder = Validation::createValidatorBuilder();
$builder->enableAnnotationMapping();

Step 3: Ensure validators are autoloaded

Every annotation has it’s own class. The AnnotationRegistry has explicitly disabled the default autoloading, so you have to register any classes you want to be included yourself. It has a PSR-0 compatible autoloader inside.

Since we want to use the form framework, lets register those classes. Put the following code in a file that is executed each request.

$vendor_dir = 'fill in yourself';
$namespace = 'Symfony\\Component\\Validator\\Constraints\\';
$directory =  $vendor_dir . '/symfony/validator';
AnnotationRegistry::registerAutoloadNamespace($namespace, $directory);

If you want to add custom validatiors yourself, don’t forget to autoload these as well.

Step 4: Enable cascade_validation if you have embedded forms

If you have any embedded forms, be sure that the cascade_validation option is set to “true”, since otherwise the annotations of the embedded forms won’t be read.

// In the setDefaultOptions function
$resolver->setDefaults(array('cascade_validation' => true));

That’s all it takes to enable the validation annotations to be read by the Symfony2 form component using the Doctrine annotation driver.

This follow-up of debugging mindset goes into real life debugging. By now you know the perfect debugging mindset: curious, humble and suspicious. Debugging consists of understanding the problem, reproducing it, finding the problem, finding the right place to fix it and to perform some after-care.

Understanding the problem

The first preparation you want to make is to know what the correct behaviour is. Not just in this case, but also for all the edge-cases that can occur in this part of the code. Because these still need to work after you make your fix! The application(s) you’re debugging might be too big to understand completely though, so don’t try to understand it all. Some valid questions you want to ask;

• Which application is responsible for this?
• Which layer of the architecture is responsible for solving the problem? Think client side or server side. Think model, view or controller.
• Isn’t this actually expected behaviour? If it is, then you’re done.
• Is the input to the whole process correct? Maybe the problem is somewhere earlier in the process; this input should not be allowed.

Reproducing the problem

The second preparation you want to make is to reproduce the problem in your development environment. If you can’t, then try harder. This is really an essential part of solving the problem, because reproducing the correct conditions means you have a better understanding of what is going on. Maybe the problem exists because the configuration or the database schema isn’t synchronized between environments.

The best way to reproduce the problem is to make a unit-test that detects the problem, once you’ve done this you’re practically done.

Finding the problem

These are various tricks to find which part of the source code causes the problem. These are some tricks you can try in real life debugging

• Check your version control system. Recent changes could be related. Files that are often changed and have different authors are suspicious.
• Go at it from two ways. Sometimes you have the name of a file and a line number, but it can be hard to reason upwards from there. Try both top-down and bottom-up approaches.
• Use binary-search to reduce the amount of code you’re looking at by 50% per try.
• Talk to the duck.
• There could be something going wrong with multi threading.
• Use a debugger tool that allows you to step through the application.
• If all of that doesn’t work: find out how to gather more information.

Finding the right place to fix it

If you’ve found the problem by now, there is one more simple question to ask yourself: where in the application is the correct way to fix it? Sometimes the problem might be a problem that only exists once in the application, then it’s a candidate for a local fix. In other cases you might opt for a generic fix in a higher layer of the architecture.

Secondly, sometimes other code might depend on the wrong behaviour. So because you fixed the problem, something might break ahead in the process. This is, after all, a situation that hasn’t occurred in the rest of the code.

Real life debugging: The after care

In some cases there is some after care involved after fixing a bug. It’s something you might forget. After care is a pretty wide thing, I’ve seen cases where

• a field in the database was inserted wrongly, and it had to be corrected for previous cases.
• customers had received an incorrect e-mail, and there had to be sent an apology e-mail stating the previous message was incorrect.
• a check had to be made to prevent this error from occurring in the future.

Once all the after care is finished, you’re done!

Today I went to Google I/O Extended 2013, which is basically where Google does a lot of their announcements. The real event is hosted in San Francisco, this was a meetup where a lot of fellow nerds were watching the video stream. It’s interesting to see the latest technological developments made by Google.

Big thanks to the Dutch Android User Group and the nos for organizing this event!

Interesting bits in the Google I/O Extended 2013 presentation

There were a lot of announcements made continuously, focusing on various Google products: Android, Chrome, Google+, Search and Maps. No new hardware or major Android version announced, but that wasn’t expected.

To keep it short, I’m going to focus on Google+, Google Maps and the talk of Larry Page.

Google+

Most notably was the attention to Google+. For the people that think that it’s an attempt to overtake Facebook that has failed, think again. This is not a race, it’s a marathon. This year they’re continuing the marathon, every bit of the keynote had something with Google+ in it;

• Personalized search results in Google Search.
• More awesome hangouts and photo sharing in Google+ itself.
• Personalized maps in Google Maps.

Bit by bit Google+ is showing up in the various Google products. Every placement seems to be well thought out.

Google Maps

Google Map has been redesigned. Two things that stood out for me where the clean user interface, a lot of clutter has been removed. Because of that you can see a lot more of the map itself. Also, it has a zoom effect which really reminded me of Supreme Commander.

If you’re quick you can request early access to the new Google Maps. If you’re less quick, well, maybe they’ve released it into the public already.

Larry Page

After the maps presentation Larry Page came on stage. The only reason the maps team was just before that, was probably to allow him to talk while the impressive image of the earth (with real time clouds) was shown on the screens.

The talk of Larry Page was the most interesting bit of the keynote for me, since it really got into the reasoning and the vision that is the growing factor for all of the features in the background. If you don’t feel like watching all of it, then it could be nice to watch just this part.

So far my first impressions. All in all a nice way to spend an evening

Today I was looking to enable comment moderation shortcuts for my WordPress blog. Obviously I love good comments, and will approve any that are not obviously spam. Manually clicking every comment takes a lot of time though, and the amount of spam messages have been slowly but steadily rising. At the same time I prefer to not resort to something like a captcha image, since that would raise the barrier to respond.

Enable comment moderation shortcuts in WordPress

Turns out it exists since WordPress 2.7 and is remarkably easy to enable!

• Log in to the administrator environment
• Go to “Users” -> “Your profile” as shown on the right.
• Check the “Keyboard shortcuts” checkbox as shown in the bottom (emphasis mine).

Once you submit that form, and go to the comments section, you can press j or k to go to the previous or next comment, and press a or s to approve or to mark as spam. There are a bunch of other actions as well, just click the “more information” link in the admin panel to see those. I really like this work flow, maybe because it’s similar to my favourite RSS reader.

There is one thing I like about open source software, and that’s the matter of scratch your own itch. Someone had the same problem that I had, and went and build this great thing for it. And now it’s open for the entire world to use. Thanks!

More actions for combating spam

There are obviously more things you can do to combat comments spam in a WordPress blog. You should also check these tips if you have this problem, maybe they will help you even more then this simple thing.

A short story about merging arrays in PHP. When merging two arrays you’ll probably look at array_merge first. These two sentences in the docs say the following:

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one.

Values in the input array with numeric keys will be renumbered with incrementing keys starting from zero in the result array.

But what if you want to keep the numeric keys? You need the + operator.

The + operator returns the right-hand array appended to the left-hand array; for keys that exist in both arrays, the elements from the left-hand array will be used, and the matching elements from the right-hand array will be ignored.

So there are two functions, doing the same trick but with a slight difference. Next to numeric key preservation there is another difference: the order of the arguments. When using array_merge the values of the array passed in last will win in the case of a collision, with the + operator the values of the left array wins. Thanks PHP!

Alternative to merging arrays in PHP

To end with a positive note, you should look at the symfony/options-resolver component if you have this kind of problem. It solves a lot of use cases where you’re normally use an array_merge. It gives you more control about the allowed values, and gives you exceptions if a required option isn’t present.

If you want to try it out, do so using composer. Pay attention to the composer API limit at GitHub though!

Debugging is a large part of Software Engineering, and it’s really important to have the right debugging mindset. Debugging itself is a wide subject. It’s something you think everyone knows, but in the real world everyone has to reinvent the wheel themselves.

It starts like this:

There is a problem with my code, and I want to fix it.

That’s one way to look at it. Another way is to say

There is something I don’t know about my source code.

There is something left for you to learn! Be interested. While I’m searching for the problem, I tend to fiddle a little bit with the code. Rename some variables, move functions from one class another or reduce visibility from a method from public to private (if it’s possible). This helps me understand*.

Next to really understanding what is going on, there is another thing that has to be part of your debugging mindset. You have to assume the code is wrong, even if you’ve written it yourself and it’s beautiful. If there wasn’t something wrong with the source code, you wouldn’t be debugging right now**. You have to feel responsible for solving the problem at hand.

Part of your debugging mindset: be relaxed

Another thing about your debugging mindset is that you have to be relaxed. It’s something that’s hard to do in a hurry. It’s about understanding the situation, and making a hypothesis about what is wrong. You should feel confident about this hypothesis. It doesn’t happen often that the hypothesis that you make is wrong.

Be a little bit suspicious  Someone might have tried to make a fix for this problem at a different location, this fix might stop your real fix from working.

The next step is to gather a lot of data. Data can come from a lot of sources

• The compiler. Configure it to the pickiest level of error reporting. Fix every error, warning and even all the notices. If you get many errors, fix the first error first. Don’t trust the ones coming after, since they are unreliable, and might be just followups from The First One.
• Tracing with a debugger
• Log statements
• Unit-tests

There might be cases where all of this isn’t even enough. Sometimes you won’t find the cause straight away, because you get a non-precise error message. In that case you should think what you want to know, and then improve the error message, or enhance (or introduce) logging. This is closely related to defensive programming.

And with that bombshell it’s time to end the first part about debugging. Right now it might feel a bit vague, but go on to part 2: real life debugging!

* Not everyone thinks this is a great idea though, see refactoring legacy code.

** Unless of course you are that one person who finds the bug inside the vendor code.

One thing a lot of programmers are excellent at is giving realistic estimates. Especially when asked at the coffee machine, we’re often right on the spot. Well, ok, maybe not so much. Ok, we’re not even close to it most of the time.

What to Say When Asked for an Estimate

You say “I’ll get back to you.”

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

This is what you get when you ask it on Stack Overflow. And guess what? They’re correct! No-one should ever ask you for an estimate on the fly*.

To understand why, we have to dive a bit into planning poker. When you see programmers in a meeting room playing cards, it can mean only one thing: they are playing planning poker. Why does that work?

• Planning poker starts a dialogue about the stories at hand.
• Explaining your problems to others, even a duck, can help you understand them.
• If two peoples estimates widely vary, they can explain why they made this estimate. Most of the time this is a learning moment for both of them.
• Planning poker is fun!

The most important benefit you get from planning poker is the conversation. As part of the exercise, you explore the story as a team, and uncover any misunderstandings about the scope and depth of the work to be done to satisfy the story. The result of this exploration is a shared understanding of what the story means.

The feedback of your peers will uncover new scenarios that would have otherwise been overlooked. The art of software engineering is to model to reality, but simplify it so that it’s manageable in your head. Sometimes a new scenario can mean that you have to change your model, and thus will take a different time to accomplish.

Even if the new way will take about the same time, it’s much nicer to find it out while you’re still in requirements engineering. There are not a lot of facts known in the world of Software Engineering, but one of them is that you want to find bugs as early in the process as possible. How about before it’s even made?

The actual estimate might not even be different from what you would have estimated by yourself, but because you know some of the edge cases before hand, it will be more accurate. So do not give an estimation without peer feedback .

If you’re part of the people that need the estimate, just ask “Can you make this estimate for me?” Do not mention the time you think it might take. A lot of programmers might base their estimation on that time, which is not what you want.

* It’s possible to make some estimations on the fly, but only if it’s small and you’re completely sure of the boundaries of the project. It just makes giving realistic estimates harder.