Matthias Noback has posted about some of his experimentation with Broadway, a framework of testing helpers and structure to create CQRS/event sourced applications. CQRS is a design pattern (Command Query Responsibility Segregation) that essentially defines the use of a different method for reading data than for working with it (ex: updates or creates).

At the Dutch PHP Conference I attended a workshop by Beau Simensen and Willem-Jan Zijderveld. They showed us some examples of how to work with Broadway, a framework for event sourcing, with full Symfony integration, created by the smart people at Qandidate.

During my two weeks of funemployment, before starting my new job at Ibuildings, I decided to recreate one of my previous projects using Broadway. As it turns out, it's a great framework that's quite easy to use and is very powerful at the same time. Even though it's not a stable package (as in, it's still in the 0.x version range), I think it's safe to depend on it.

Matthias found that one of the main features of the models in Broadway is the serialization of them for storage, but wanted to reduce the amount of time to handle that...so he created this library. He also talks about something that several have pointed out as missing in the Broadway structure: how to use "sagas". He ends the post with an update on his own tool, SimpleBus, that handles eventing and via message busses, noting that it's not going anywhere but if you use Broadway, there's no reason to use SimpleBus too.

On the Etsy "Code as Craft" blog they've posted an article about their experiences in experimenting with HHVM at Etsy and some of the differences it makes.

In 2014 Etsy’s infrastructure group took on a big challenge: scale Etsy’s API traffic capacity 20X. We launched many efforts simultaneously to meet the challenge, including a migration to HHVM after it showed a promising increase in throughput. Getting our code to run on HHVM was relatively easy, but we encountered many surprises as we gained confidence in the new architecture.

They start with a brief overview of what HHVM is for those that aren't sure and talk about where their focus was in these experiments. They list out some of the main reasons for trying out HHVM and the role of concurrency in their current application. They started with the "minimum viable product" and compared benchmarks between PHP 5.4 and HHVM on several endpoints. They also show how they "teed" incoming requests to both servers to ensure that the responses were the same across both. They also talk about using employee-only traffic and the overall statistics for when they released the HHVM version internally. They also talk about some of the undocumented features to keep an eye out for if you're thinking of switching: "warming up" the requests to align them in JIT memory, using perf(1) for profiling and the use of the HHVM interactive debugger (hphpd).

Brandon Savage has posted some of his thoughts on when it's okay to write bad code in your development lifecycle:

I’ve been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working - without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up. You know what? The component came out working, but when I was done it was ugly. Totally ugly. The code was bad. But I had a solution, and a solution that worked.

He points out that sometimes, doing things "the right way" can stifle creativity and experimentation - two things that a developer needs to solve the problems they face day to day. He notes that refactoring is a part of their job and moving from a rough prototype to a finished product often improves this skill and can find issues not discovered before.

This does NOT mean that developers can push bad code into a repository. Nothing lives longer than temporary code; see to it that your finished code is always good.

Jani Hartikainen has posted the first part of a series of articles sharing his experiences with an experiment he's conducting - trying to parse and evaluate PHP in Haskell.

The other day I uploaded a new experimental project on GitHub – A Haskell PHP parser / evaluator. It doesn’t understand 100% of all PHP syntax, but it was an interesting experiment nevertheless. Here’s some insights and other thoughts from working on the code.

He gets the "why?" question out of the way early, noting that it was mainly a desire to play with Haskell and figured parsing something he already knew well was a good first project. He also mentions the "Parsec" library that seems well suited for the parsing part of the process. There were some issues that he came across, however including dealing with PHP's weak typing and handling all of the possible incarnations of PHP script structure. He includes an example AST showing his different data structures (PHPValue, PHPExpr and PHPStmt). The next part of the series will be more about the evaluation of this structure.

There's an interesting post on Eric Holk's blog talking about how we read code - a look at the results from a psychology experiment that tracked the viewer's eye movement as they scanned through code (complete with video).

The goal is to figure out some way of measuring what features in programming systems help programmers understand wht they are doing, and how this can be used to make systems that lead to higher quality software. Mike is currently running an experiment where he shows people several short Python programs and asks them to tell the output of the program. The test subject is sitting in front of an eye tracker, so afterwards Mike can see where you were looking at various times during the experiment.

The results are pretty interesting and Eric likens it to a sort of "just-in-time compilation" that the mind is doing as it reads through the code, not a straight forward read through. The timing of the read is interesting too, noting that once something is figured out, it's run through faster the following times.

One aspect he’s interested in is how the approach of inexperienced programmers differs from that of experienced programmers. For example, there seems to be some evidence that following variable naming conventions helps experienced programmers understand the code much quicker, while breaking these conventions leads to a severe penalty. On the other hand, inexperienced programmers seem to take about as long regardless of how the variables are named.

This study is still going on and, if you're in the Bloomington, Indiana area and would like to lend your eyes to the cause, send an email over to Mike Hansen (more on the subject on his blog here).

With all of the recent talk about the Aura framework that's been happening lately, Stan Lemon thought it would be interesting to see how a microframework based on the Aura packages would be to create. He's posted about his experiences on his site today.

I was recently working on a small project that used Silex. As I browsed my vendor folder, I realized how much extra “stuff” I had inherited with Silex. There were a bunch of other components required when all I wanted was some quick and easy routing, micro-framework style. When I think about going lean I always find myself coming back to Aura. Micro-frameworks are not a new to idea to Aura, so I wondered if I could take the elegance and ease of Silex by wrapping up Aura.Router and exposing it through a similar API.

The result of his work is Aura.Micro, a simple microframework that really just handles routing (unlike Silex with builds on the Pimple DI as well). He includes an example of it in use, defining several different kinds of actions on the routing like "before", "finish" and a few "get" routes.

Gonzalo Ayuso has put together an experiment related to the current OOP structure of PHP - a test working with runtime classes, a structure generated entirely when the script is executed and not predefined in the file.

Last week I was thinking about creation of a new type of classes. PHP classes but created dynamically at run time. When this idea was running through my head I read the following article and I wanted to write something similar. Warning: Probably that it is something totally useless, but I wanted to create a working prototype (and it was fun to do it).

His class is pretty basic - a "Human" object that echoes a "hello world" sort of message via a "hello()" method. He creates the classes inside of different test methods to ensure that his assertions are true. The tests check basic output of the "hello()" method, calling undefined methods, testing inheritance and a test creating and evaluating a dynamic function.

For something more complex, he creates a dynamic class that solves the FizzBuzz kat, a popular programming puzzle. You can find the full code for this and his other examples on github.