In a new post to his site, Tomas Votruba has a post sharing his thoughts about why you should combine Symfony Console and dependency injection and how it can help tp resolve issues with the overuse of static methods and functions.

I saw 2 links to SymfonyConsole in today's Week of Symfony (what a time reference, huh?). There are plenty of such posts out there, even in Pehapkari community blog: Best Practice for Symfony Console in Nette or Symfony Console from the Scratch. But nobody seems to write about the greatest bottleneck of Console applications - static cancer. Why is that?

He starts with some examples of the current status in PHP console applications including PHP_CodeSniffer, PHP CS Fixer and PHPStan. Each of these load commands to add functionality to the application which, as the application grows and changes, could be difficult to maintain in the future. Instead he recommends making use of dependency injection. He then talks about how containers are already a part of the console applications mentioned and finishes up focusing on the combination of the SymfonyConsole and SymfonyDependencyInjection components.

On his site Ross Tuck has a post that covers a common design pattern, the Command Bus, how it relates to CQRS and that they shouldn't return anything. In the post he takes some of the most common questions about using a command bus and tries to clarify with the correct answer.

The most common question I get about my command bus library is: “can commands really return nothing?” The second most common question is “Why do you let commands return something, don’t you know that’s Wrong(tm)?”

It’s easy to get hung up on form, not function. That’s a shame because command buses aren’t important. In the grand scheme of things, they’re completely, utterly, totally unimportant. It’s all about where the messages are going, not how they get there.

Still, let’s take a look at some myths about command buses.

The questions he tackles include topics like the relationship between CQRS and command buses, if you should be using them together (dependencies) and some discussion about return values and the "right" way to do things.

In a post to his site, Matthias Noback talks about code complexity and how this relates to the overall "churn" (the rate of change) in a project.

Code complexity often gets measured by calculating the Cyclomatic Complexity per unit of code. The number can be calculated by taking all the branches of the code into consideration. [...] In general, we always strive for low code complexity. Unfortunately, many projects that you'll inherit ("legacy projects"), will contain code that has high code complexity, and no tests.

[...] Code complexity doesn't always have to be a big problem. If a class has high code complexity, but you never have to touch it, there's no problem at all. [...] What's really dangerous for a project is when a class with a high code complexity often needs to be modified. Every change will be dangerous. [...] Michael Feathers introduced the word "churn" for change rate of files in a project. Churn gets its own number, just like code complexity.

He then talks about combining these two numbers to provide an even more in-depth look at your code. It can give more insight into the relationship between "difficult to change", "number of changes" and the times a file has changed in the past. He mentions "it's okay" thinking (the current state is alright but not great) and shares some of his own hypotheses, observations and advice.

In a post to his site Sebastian De Deyne shows how to use Laravel Mix to work with Typescript right alongside other packages and libraries included in your mix configuration.

In a recent Spatie project we decided to give TypeScript a shot for the business critical part of a new application. TypeScript provides static analysis to reduce the chance of introducing bugs, to have self-documenting code, and to improve our tooling (autocompletion!)

We've been happily using Laravel Mix since it's release with Laravel 5.4. Luckily, extending Mix isn't too hard with some webpack knowledge. [...] As long as you've configured an appropriate loader, you could import anything from a plain old JavaScript file to an animated gif. This means that if we want to support TypeScript with Laravel Mix, we don't need to change any configuration, we only need to add the ability to bundle TypeScript files.

The remainder of the article is broken down into the four steps (and a bonus) for getting Mix and TypeScript playing together nicely:

• Install The Necessary Dependencies
• Configure TypeScript
• Configure Laravel Mix
• Write Some TypeScript!

The bonus at the end shows how to use this working setup to go one step further and use TypeScript in the Vue.js components in your Laravel application.

The SitePoint PHP blog has a new tutorial posted from Christopher Pitt (known for his "interesting" uses of PHP) covering the combination of ReactJS and PHP in game development. He wants to answer the question of how compatible they are and provide an example to help illustrate.

I started thinking about this the moment I decided to try and build a game using PHP and ReactJS. The trouble is that I knew nothing about the dynamics of multiplayer games, or how to think about and implement player-based economies.

I wasn’t even sure that I knew enough about ReactJS to justify using it. [...] I once watched a talk, by dead_lugosi, where she described building a medieval game in PHP. Margaret inspired me, and that talk was one of the things that lead to me writing a book about JS game development. I became determined to write about my experience. Perhaps others could learn from my mistakes in this case, too.

He hops right in to the code from there, starting with the setup of the backend functionality making use of Aerys for the HTTP/WebSocket handling. He creates a few basic routes then moves on to the frontend using Laravel Mix to pull in the dependencies he needs and perform the steps needed to build things out. He then goes through the process of creating the application frontend and connecting the WebSocket requests to a "GameSocket" endpoint. He finishes up the post with updates the Javascript to add in functionality to send a message to all users connected to the WebSocket.

Anthony Ferrara has a new post today looking at a potential security issue in PHP applications when using bcrypt with encryption and other hashing functions. His findings have to do with some research he did on long passwords and denial of service attacks they might lead to.

The other day, I was directed at an interesting question on StackOverflow asking if password_verify() was safe against DoS attacks using extremely long passwords. Many hashing algorithms depend on the amount of data fed into them, which affects their runtime. This can lead to a DoS attack where an attacker can provide an exceedingly long password and tie up computer resources. It's a really good question to ask of Bcrypt (and password_hash). As you may know, Bcrypt is limited to 72 character passwords. So on the surface it looks like it shouldn't be vulnerable. But I chose to dig in further to be sure. What I found surprised me.

To find out exactly how things are processed he gets down into the C code behind the PHP functionality in the crypt function. He discovers something interesting about the way it determines the length of the input password. It loops over the key, taking one byte at a time but resetting when it comes across a null byte. While this method is safe in itself, he points out the real issue - using pre-hashing before the bcrypt password checking to, possibly, allow for longer passwords.

The problem is that this method could lead to those null bytes and cause issues with the password checking, especially if opting for the use of raw data. He includes a simple script to illustrate this problem, finding a few collisions for his made up key and "random looking" password. Thankfully, he includes a method for checking to ensure the hash doesn't contain a null byte. He points out that not all hashing combinations are at risk and suggests a few alternatives that can keep your application 100% safe.

The underlying problem is that combining cryptographic operators that weren't designed to be combined can be disastrous. Is it possible to do so safely? Yes. Is it a good idea to do it? No. This particular case is just one example where combining operations can be exceedingly dangerous.

In some of his research into PHP and Windows recently, Cal Evans has come across two surprising things about the (usually dismissed) combination of the two:

• It actually runs well if setup properly

  I don't have a spare computer so I'm not going to discuss performance or show benchmarks. I am talking about ease of use in getting things setup. [...] No, I'm not nearly ready to give up my Linux servers in production and despite Sam Ramji's recent pleas to their open source vendors not to compete on price but compete on value, I can still fail fast and cheap using open source software and operating systems.

• A lot of open source developers just don't trust Microsoft, just because.

  I am, however, willing to give them the benefit of the doubt. I am part of the slim majority on the above poll who thinks they are sincere. The reason I am willing to give them the benefit of the doubt is not because I believe that the core of Microsoft has changed in any way [...] but because I believe that inside of Microsoft, there are pockets of brilliance.

Check out more of Cal's thoughts on the matter and the results of his "unscientific" polls he mentions in the rest of the post.

Felix Geisendorfer has posted his slides from his presentation at this year's CakeFest covering the powerful combination of jQuery and the CakePHP framework.

Sorry this took so long, but here you can download the PDF or the much better Keynote version of my slides.

He also has an embedded Slideshare player on the post of you want to check out the presentation without the download.

On the Zend Developer Zone today, there's this new tutorial that looks at making the move from PHP4's object-oriented programming up to the "more complete obejct model of PHP5" - specifically with the Decorator design pattern.

While working on a project I realized one particular solution was a pretty good way to demonstrate the decorator design pattern together with some of PHP5's features, including abstract classes, interfaces, type hinting, the final keyword and the visibility of properties and methods. This article is intended for those of you who, like myself, are moving from object-oriented programming, including some use of design patterns, in PHP4, to the more complete object model of PHP5.

He sets up a scenario about the development of an online pizza ordering system to show how to "decorate" a pizza with each of the toppings on a list (instead of having to list out every pizza in every possible topping combination). Of course, all of the code is included and explained so you understand exactly what's happening. Finally, there's a demonstration of its usage - a simple call that grabs the stock level/name/cost of each of the items in stock (pizza combinations).

On the Zend Developer Zone today, there's this new tutorial that looks at making the move from PHP4's object-oriented programming up to the "more complete obejct model of PHP5" - specifically with the Decorator design pattern.

While working on a project I realized one particular solution was a pretty good way to demonstrate the decorator design pattern together with some of PHP5's features, including abstract classes, interfaces, type hinting, the final keyword and the visibility of properties and methods. This article is intended for those of you who, like myself, are moving from object-oriented programming, including some use of design patterns, in PHP4, to the more complete object model of PHP5.

He sets up a scenario about the development of an online pizza ordering system to show how to "decorate" a pizza with each of the toppings on a list (instead of having to list out every pizza in every possible topping combination). Of course, all of the code is included and explained so you understand exactly what's happening. Finally, there's a demonstration of its usage - a simple call that grabs the stock level/name/cost of each of the items in stock (pizza combinations).