I'm pretty excited about a contribution I recently made to Aura.Sql.  For those not familiar with Aura, it's the brain child of Paul M Jones (a decent dude despite his hate for design patterns starting with the letter F) and strives to be a set of standalone components with no outside dependencies and 100% test coverage. Aura.Sql v2 is also known as ExtendedPdo, and it's a drop in replacement for PDO.  The idea is it gives you some extra giddy up in your database tooling, via lazy connections, short hand helpers and a basic profiler. I've found this especially helpful on a couple of projects where I have a bunch of technical debt and an antiquated ORM.  The problem is database connections are expensive and opening up a new one via ExtendedPdo is not always feasible.  My contribution to this project was the ability to decorate or wrap an existing PDO instance so that you could pull the raw connection from another system and use it without reconnecting to the database.  This is an idea I got from Doctrine 2, which offers similar support by passing in an existing instance object.  This is a particularly handy feature when refactoring a legacy code base.

If you're getting off the ORM band wagon, or dealing with some poorly performing legacy code you're trying to refactor take a look at Aura.Sql, it's right tool for the job.

https://gist.github.com/stanlemon/10692955



My love affair with Symfony 2 has hit a rocky spot. I have an atomic deployment system for a Symfony 2 app that I've been working on.  Basically it works like this... The app gets built on my CI server, Bamboo. That build results in an artifact, a tarball of the entire application.  This tarball is intended to represent the final product, meaning tests have all been run - they passed - and any compilation steps have been executed.  But I've got a problem.  It comes when I try to warm the cache or more generally if I run any Symfony console command on the build system before the artifact is made. This includes things like installing Assetic dependencies.  To work around my problem I've been making sure my 'cache' folder is empty before I build the tarball.  I wind up crossing my fingers on the deploy step and trusting that things will work themselves out when the cache is warmed and the container is compiled on the application server.  This is a horrible solute.  It's one I'm forced to deal with because of the way Symfony 2 dumps it's dependency injection container.  The container dump compiles references to %kernel.root_dir% which is an absolute path to the application root. That path is different on my CI server than it is on my production application server. If I compile the container on the CI server I wind up with a dump file that has the wrong absolute paths, resulting in a non-function app.

Some may want to question not doing the build on the application server if this is a problem. That may work for some people, but I think it's wrong to assume it's going to be possible in every deployment scenario.  There are simply a lot of regulated industries where building on the application server simply is not going to pass an audit. In my experience both in the PCI and Hippa worlds this simply wouldn't have worked.  You may disagree, but the reality is when you get into sorts of regulated environments you are playing by someone else's rules, even if they're silly rules. Furthermore, this solution does not scale.  It works for small clusters, but there's a point at which it simply is too long to roll that sort of deployment process out across a datacenter.  I've spent a fair amount of time solving software problems in these sort of regulated environments, so now I am admittedly wired to consider such things even when they're not being mandated by a regulatory body.  My build system involves Bamboo and Ansible.  Out of this system a singular artifact of the application is produced for deployment. It's a clean system and I can pull the artifact down from the CI server at any point and work with the exact distribution that will hit my application server at any time. Well, identical so long as the cache is not built. Here lies my beef with the way Symfony works.

As I mentioned, this has been a bit of a pain with Assetic.  Until recently I was able to avoid it for the most part. Assetic can be a great tool, especially during development, but much of it can be circumvented with more front end centric tools like Grunt. Recently though I started playing around with the SpBowerBundle to manage front end assets and hit this problem again.  In principle I really like what SpBowerBundle brings to the table.  It's an awesome union of front end and back end dependency management into a nice clean integrated system.  However, this time I just couldn't make it work.  This is no fault of the Bundle's, as I eluded to earlier, I consider this a flaw in the way the container is compiled.

In general I am a huge fan of Symfony 2. I love the design and architecture of the system, and the flexibility to build a truly componetized app is unique in the PHP-stratosphere right now. This doesn't seem to me like it should be an issue, yet it is. It also seems to me like more people should be wrestling with this, but I'm not finding the blog articles on it or any workarounds for that matter.  Truthfully I suspect the problem could be resolved by delegating the string replacement of %kernel.root_dir% to a method call, like getRootDir() which could then return the magic constant __DIR__ and we could use absolutely paths without having to hardcode them.


SwS: The Basics


Do you want to get started shaving with a double edge razor? Mark and I cover The Basics on Shave with Swagger.



I recently read Richard Miller's post  Avoiding Setter Injection and I in large part agree with his sentiments. My conversion to constructor injection over setter injection is a fairly recent one and when I was initially deliberating the differences I found a lot of explanations online with little concrete code to show why this practice is less productive to good object oriented design. I thought I would try to illustrate with some concrete code examples I agree with Miller that ultimately constructor injection is a more worthy approach and why you should avoid using setter injection whenever possible.

First, let's consider two interfaces FooService and FooNotifier. FooService will use a FooNotifier which contains a method notify(). We have two implementations of FooNotifier the BarNotifier and the BazNotifier.  Fundamentally they do two completely different things, though they agree to the same contract.  Here's what these things look like:

[gist]https://gist.github.com/stanlemon/d0748c96775995275074[/gist]

Now let's take a look at our constructor injection implementation FooServiceConstruct:

[gist]https://gist.github.com/stanlemon/a1968eedabb808fa5985[/gist]

And also our setter injection implementation FooServiceSetter:

[gist]https://gist.github.com/stanlemon/4ca097db323de8c7faba[/gist]

The argument goes that with constructor injection you create an object with all of it's dependencies. This means that you minimize side effects caused by the dependency not being injected, or worse changing on you after your object has been created. It makes your object fundamentally more predictable. Think of it this way, this is the only way that we can use our FooServiceConstruct:

[gist]https://gist.github.com/stanlemon/f2cf4b13562fa1fa3f74[/gist]

But with _FooServiceSetter w_e can actually do a couple of things with that implementation...

[gist]https://gist.github.com/stanlemon/bcd6e243a4baa5d7b0f5[/gist]

You'll see that we can create a FooService that either does not work or that can have it's internal behavior completely changed out from under us.  Neither of these options is good. The alternative is that with constructor injection we have an object that stands on it's own, the functionality of which cannot be changed in runtime after it has been instantiated. If you want to avoid buggy software, make your objects predictable.

This is a simple example, but it illustrates the nature of an object that uses setter injection. It creates the potential for volatility in your object that you don't want to occur.  Now I'm not saying you should never inject via setter. There may be times that you actually want the behavior I've illustrated, however I think you will find that most of the time you simply don't want that. Subsequently as a general rule I inject by constructor unless compelled otherwise during the design of my software. I make it the exception, not the rule when writing objects.