Automated bad practice

One new feature of Laravel 5.4 are so called “Automatic Facades”. My colleague was expecting my reaction when he send me the link to the blog entry announcing this feature (I’m not linking it intentionally) with a thievish smile.

As Laravel’s documentation puts it, “Facades provide a static interface to classes that are available in the application’s service container”. In other words, you can access any class almost everywhere without hassling about nasty things like dependency injection. Hm? Do I hear Singleton somewhere?

So far it was required to add Facade classes in order to make this work. It seems even this little barrier has fallen now.

Laravel’s Facade in my opinion is one of the worst features a PHP framework offers nowadays. After times of Zend Framework 1 and the infamous Registry (I abused it too), when IoC finally arrived in the PHP world, it somehow seemed to me as quite a setback when Laravel became more and more popular with its Facade feature (it’s not even the Facade design pattern anyway).

Here’s why.

1. It’s tempting

Making classes available in the code everywhere is tempting unexperienced (and experienced) developers to use the facade everywhere, without thinking if this might be a good idea or not. I’ve seen things! I even found Facade in configuration files. IN CONFIG FILES WTF!!1

If you don’t pay close attention, your classes soon will violate the single responsibility principle, simply because you don’t really notice how many dependencies you suddenly use.

2. It binds your code

In my opinion code should be bound as less to the underlying framework as possible. I totally get the advantages of ORMs and such, I’m not opting against packages etc., but binding your code too close to a framework can cause problems if you want to use your business logic over longer terms.

But well, I guess if you are willing to use non-namespaced helper functions everywhere in your code (another Laravel feature I “deeply adore”), you don’t really care about this either.

3. It requires more overhead to test

“But Facades are more testable than traditional static methods!” I hear the Artisans yell. Yeah, sure, that is true.

What a benefit!

It just requires bootstrapping of Laravel for every test, making unit tests significantly slower. Your tests will become more complex and thus require more maintenance, as you will need to mock more dependencies which are all required to make one test work.

4. It’s actually not that convenient

Any modern IDE provides Code completion, so I can see in a second which methods a class offers. With Facade, I need an additional package that parses the Facades and generates documentation files that the IDE can parse for the Code completion.

How convenient!

When stepping through the code during debugging it annoys me pretty much to go through the facade over and over again. It’s just so unnecessary…

Probably both IDE and Debuggers are not so commonly used amongst Artisans?

5. It’s not more expressive

I really don’t get why

Cache::get('key')

is more “expressive” than

$this->cache->get('key')

Somebody needs to explain!

Fair enough

To be fair, even the official Laravel documentation states that Facade should not be used when building a third-party package, and that it bears some of the above mentioned risks. So Taylor is aware of it. But then why is this feature enforced in the first place anyway? I think it’s because Laravel claims to be so “expressive” and “beautiful” in it’s syntax that everybody accepts the downsides.

Decide for yourself if it is worth it.

Probably I’m just missing the point here? Why do you think Laravel’s Facade should be used rather than Dependency Injection?

cwmobileredirect and cwenvbanner finally available for Typo3 7 LTS

Well, actually the Typo3 7 LTS versions were available for a couple of months through my Github repositories of cwmobileredirect and cwenvbanner already, however I never found the time to upload them to TER. Finally I found some time to upload it, so here you go:

cwmobileredirect on TER
cwenvbanner on TER

The new versions do not include any new features, I did some cleanup though, so Typo3 4.x is no longer supported. Please just stick with the old versions of the extensions in case you are still using one of these ancient Typo3 installations.

Besides Typo3 7 compatibility and cleanup I spend some time on making them work with a Composer based Typo3 installation (the outcome can be found on Github as well) and Travis CI. Since I only work on these extensions occasionally, this will surely help me in with the Typo3 8 LTS versions (which I hope to get done a bit earlier this time :-)).

Clean Code Days 2016 – Opening Keynote

Clean Code Days 2016

End of June this year I had the honor to hold the Opening Keynote at the Clean Code Days 2016 in Munich. Actually my first talk on a Conference ever, I called it “The Lone Stranger, or: Why you can’t establish Clean Code on your own“.

It covers the wide range from how to convince Managers and Co-Developers to start clean coding, over to tips and tools on how to change a legacy project from sloppy code into better and one day maybe even “Clean Code”.

Opening Keynote on Youtube

Slides

I wasn’t able to watch it in full yet (boy, my voice sucks ;-), but I hope you like it!

Debug Unit Tests using the PhpStorm built-in test runner

PhpStorm comes with a handy phpunit test runner, which lets you execute your tests with just one click. Even better: if a test fails, you can just run that test also with just one click. That’s how I like it.

However I often use the debugger to debug failed tests. This is easy with phpunit and via the command line (see e.g. Remote CLI debugging). But since PhpStorm is obviously not using the command line, we have to pass the information necessary for Xdebug and PhpStorm to initiate the debug session using the Test Runners configuration.

XDEBUG_CONFIG=idekey=PHPSTORM ; PHP_IDE_CONFIG=serverName=local.dev

Needless to mention that the above values need to fit your setup. Most likely your server name will be different, and make sure to check the ide key.

But where to put it? Assuming you already setup your Run/Debug configuration, just open the configuration dialog and put the above environment variables into the “Environment variables” input field. You don’t need to add “export” or anything. Well, just have a look:

phpstorm_unit_test_runner

Now just place your breakpoints as you need them and start the Run/Debug configuration.

A normal day, a normal bug

After fixing approx. 5 billion bugs (+/- 1 billion) in my life so far, I have a clear picture of how a bug ticket should be written to actually support the developer rather than wasting his time. Maybe this is the reason why I always get a bit mad when I read descriptions like

The form validation depends on the gender radiobuttons, which is not normal.

Normally

So, this raises the good old question: what is normal? Especially, what is normal when there are no requirements for the radiobuttons? Common sense? Whose common sense? Mine? The reporters?

By the way, the bug turned out to be a feature. Srsly.

When a ticket states that something is “not normal”, “not ok” or “totally wrong”, then it adds some sort of personal judgement. No developer is happy to receive a bug ticket, so they should be written as neutral as possible, as we already have to live with the shame.

The Minimum Information Strategy

One nasty bug I was once only able to reproduce by clicking a couple of buttons in exact the same order as the Project Manager – of course this was not part of the ticket description, so after trying to reproduce the issue for half an hour (the ticket going back and forth a couple of times meanwhile, and the tone was about to get rougher…), I gave up and asked the PM to share the screen.

Aha!

After being able to reproduce the bug, it was fixed in 5 minutes. So in total, the PM and I together lost over an hour because the ticket was missing information that could have been added to it in two minutes. Not to mention the bad mood you and others get in. And this sums up over lifetime.

Minimum – and I mean it

My favorite bug screenshot of all times:

error_occured_alert

I’m not kidding. Someone really made the effort to take a screenshot of the alert, cut it precisely to not contain any valuable information at all (Browser? URL? Any other screen context?) and attached it to a ticket (which was quite a pain with the clumsy ticket system we worked with back then).

Sure, the error message itself leaves, erm, room for improvement. However I’m always wondering why bug reporters cut the screenshots. Probably it’s fun. I should try it myself.

Common sense

So what can we developers do? Give up? No. Resist.

Every time you get a bug ticket which is not written well, assign it back and kindly ask for more information. You can’t reproduce the issue? Don’t waste your time, write back and ask for steps to reproduce please. The CSS is messed up, but the ticket only contains a small part of the actual screen and not even a browser version? Don’t let your hair turn grey, assign it back with a smile!

When searching the net on how to write bug reports, you’ll find that here there actually is some sort of common sense. Basically, you’ll find more or less the following structure:

  1. Bug title
    The bug description. Simple, concise, to the point. Not as simple as “Application broken”, however.
  2. Steps to reproduce
    Ah, my favorite. This could make life so much easier. I know it’s annoying to write, but often necessary. “Select a product and put it into the cart” is a nice start, but most likely this will not make the bug reproducable.
  3. Expected results
    What results did you expect, and why? Is there a user story, ticket or any other document which could be helpful?
  4. Actual results
    What results did you get? Point out what is happening in contrary to the expected results.
  5. Browser Info
    A classic. Which Browser did you use? Please also add the version number, especially when IE is still to be supported.
  6. Screenshots
    A screenshot is helpful. Just keep it as it is, i.e. don’t cut out anything. Especially the browser URL is very helpful, so just keep it. Dammit. Developers absolutely don’t mind if there is too much information on it. If a lot of stuff is happening on it, consider adding markers (e.g. arrows).
  7. Additional info
    Any error message could be helpful. Do you find an error in the browser console? Please just copy & paste it!

Please also see the article “Writing Issue Reports That Work” by Joe Strazzere, the man with the “I got the bug fixed in no time because of your wonderful bug ticket“-smile. Sums it up really nicely.

Thanks for reading & happy bug fixing!

Local composer package development

A new feature on composer which I really appreciate is the “Path” repository type.

Imagine you are working on your super-cool-project, and one task requires new functionality where there is no composer package existing yet – yeah, this probably is a bit hard to imagine. Now you want to create your own super-awesome-package, because we all like it nice and separated and such.

So far, I would have developed the super-awesome-package directly inside the vendor folder of my super-cool-project – which somehow did not feel right. Obviously others felt the same, so now we can use the “path” resource type for packages which you develop right at the moment!

{
  "require": {
    "my-namespace/shoppingcart": "*@dev"
  },
  "repositories": [
    {
      "type": "path",
      "url": "../shoppingcart"
    }
  ]
}

Instead of using VCS as package source, you simply specify the directory (relative or absolute path both work) where your super-cool-package is located on your machine. In my case, I just refer to the shoppingcart folder, where the package is currently developed.

Composer will then add a symlink in the vendor folder upon running composer update, so all your changes on that package can immediately be used in your super-cool-project.

Now that’s what I call convenient!

cwenvbanner released

Now working with Typo3 again (Love .. Hate … Love … ), I thought it would be nice to finally publish my old cwenvbanner Extension. In short, it adds small banners to the Frontend and Backend of your Typo3 environments, so you don’t mix up the browser windows anymore so often.

You can learn more about it here: cwenvbanner