Poo-tee-weet

My take on the MicroPHP manifesto buzz

Lukas Kahwe Smith — Wed, 11 Jan 2012 10:54:38 +0100

Ed's recent blog post labeled the The MicroPHP Manifesto got a lot of attention. Personally I feel like Ed's way of expressing himself feels mostly like the rants of an angry person and not really a way of expressing a clear message. That is why I appreciate a much saner formulated follow up by Kris Jordan. In general I totally agree with Ed on the point that we need more decoupled components in the PHP world. The timing seems a bit odd since exactly that seems to be an emerging trend with all the various libraries cropping up since PHP 5.3. Where he looses me is with his seeming obsession with LOC minimization. It sounds to me like he assumes that any 3rd party code he pulls in, he automatically also has to maintain. To me that seems a bit odd. Obviously any 3rd party lib might contain bugs, which one might need to debug. But when choosing a 3rd party lib I focus on seeing if I trust the development team. I apply metrics such as track record, existing tests and documentation (oh and don't forget license). And of course I also browse the code and the response time and attitude in the bug tracker. If I hit an issue I do expect to be able to fix it myself if necessary, but in most cases I will just do my best to file a bug report with steps for how to reproduce the issue. Obviously being somewhat known in the PHP community for doing my share, I might be getting slightly better response times than most devs. But I still do not see how LOC in a 3rd party lib need to be a criteria for how hard it will be to maintain said dependency.

That part aside I would also like to comment a bit on micro vs. full stack frameworks. I don't have a perfect definition of either framework handy but I guess the main difference is that a micro framework aims to keep the number of out of the box supported use cases to an absolute minimum, while a full stack framework aims to cover a very broad sets of use cases. Traditionally micro frameworks also seem to have a much higher code to configuration ratio compared to full stack frameworks. Aka implement a certain behavior with a micro framework one usually needs to write code, while in a full stack framework quite a few things can be achieved by configuration alone. Furthermore full stack frameworks also define much more conventions (f.e. directory structures) and high level extension points (f.e. authentication and permission).

As a result to me the use case of micro frameworks is mostly in cases where I have very little business logic on the server. For example think of an application that basically just provides an API to fetch json data structures that map more or less 1:1 to some externally mapped database using some javascript MVC framework like Backbone.js for the actual business logic. However as soon as I have business logic on the server side I tend to prefer a full stack framework. The main reason is that I work at a web agency usually with team sizes of at least 5 developers but often more. Also the team compositions often change too. Furthermore frequently we integrate additional developers from the client. Here it is absolutely vital we do not waste time figuring out details such as directory structures. Furthermore many projects tend to have a lot of very similar requirements but rarely exactly the same. With the approaches that Ed and Kris seem to be describing, especially using (anonymous) functions I will find myself copy pasting code around to adapt it to specific needs of each project. This will require additional time and will obviously lead to a maintenance nightmare as this way I will end up maintaining more rather than less code.

If I gather things properly for Ed the situation is very different. He works on a set of products for his employer with a more or less fixed team. As such they can make sure that their solutions match exactly the current range of use cases. Furthermore the team will develop a set of implicit conventions and styles that will ensure consistency. They will likely have the chance of incrementally going over older, but still profitable, products to update them to their latest conventions. This way it is way more feasible for them to keep the number of required extension points to a bare minimum, because they have much more control over their current and future use cases. If they decide to use an anonymous function as an extension point, we are maybe talking about 2-3 different uses. Where as if I in a web agency design an extension point I expect 10-20 uses at least, by people in different teams. But as a web agency that believes in OSS we also release as much code as our clients let us, so the number of different use cases can grow to 100 or even more. Btw the situation is quite similar for companies that have large development teams spanning multiple offices or companies developing products that they expect will be customized by their clients. So imho frameworks such as Lithium and Slim mostly make sense for development teams of 5 or less developers working on in house SaaS applications that tend to have a large chunk of their business logic implemented in the client.

So the key take a way point is that when choosing to go micro or full stack its very important to consider in what kind of company on what kind of products you are working on. Unfortunately I have not seen any of the proponents of the MicroPHP movement discuss this aspect.

.EU PHP company knowledge exchange

Lukas Kahwe Smith — Fri, 09 Dec 2011 16:59:05 +0100

For now I am limiting this vision to just European companies. But the idea that is materializing is for PHP companies to train each other on technology or processes related to their daily business. Liip today received a remote training by Konstantin from KnpLabs on Behat. In January David will give a training for KnpLabs on behalf of Liip about the Symfony2 CMF. For now this will happen remote (we still need to figure out a better setup), because this all happened fairly short notice after talking about it this for many months. Ideally actually I think it should be done on site, to further expand the knowledge sharing. It would also be a bit of a perk for people inside a company that show leadership in a technology to have the opportunity to visit another company. Actually I want to also explore letting junior developers that have lets say 2-3 years of experience under their belt to temporarily switch their work place with another equally experienced developer at a different company for say 3-6 months. If your company would be interested in joining this please let me know.

I am not sure how to best coordinate this just yet. As mentioned from a technical perspective using Google Hangout like we did today isn't ideal. From personal experience Skype is also not great. At Liip we have a fancy Tannenberg Video conf setup, but of course not everyone has one of these standing around. But if we do these presentations in person that issue is solved. I am also not sure if there are legal aspects that should be considered if we start growing this. Of course there could also be business related obstacles to overcome since at least some of us compete with each other in the same market. But none of that should stop us! I think this could really be the start of something exciting for PHP companies.

Loose interface coupling

Lukas Kahwe Smith — Mon, 05 Dec 2011 13:25:15 +0100

OK, I think this is likely a stupid crazy idea, but it has so much practical benefits at first sight that I want to bring it up on the blog and not just twitter. As a rule of thumb when writing code one should always try to reference an interface in type hints, instanceof or is_a() checks. This in theory allows people to replace the implementation if only for unit tests. But more importantly it could also allow someone to switch to an entirely different lib for the given dependency. One practical issue here is that either both projects need to share a common interface library or forced the need to write adapters in order for a 3rd party lib to become compatible even if the relevant API methods have the exact same names and signatures. Now lets imagine a world of collaboration where some subset of the community (as big as possible, as small as necessary) agrees on some common interfaces, but they don't want to burden their code with one dependency for each of these interfaces. Especially as for different libraries a different subset of the community could end up collaborating. Here I see 3 options: 1) each library bundles the interfaces (even though they sit in some common namespace), 2) each project asks their users to fetch the common interfaces from some other place 3) runtime "coupling". Option 3) doesn't exist today and is what this blog post is about.

Actually maybe this is already possible using the runkit extension. This extension lets you mess around with essentially everything that is defined and usually can't be changed anymore: functions, classes, constants etc. Sounds harmful? It is! Right now the only valid use case I see is testing of untestable code (like being able to modify the behavior of date() at runtime). For option 3) what I am hoping for is a way to simply declare one interface to be implementing another interface. This would likely be run as part of your bootstrap or maybe the autoloader.

Here is some pseudo code that Ralph tweeted:


<?php
spl_register_compatible_interface('My\ LoggerInterface', 'Your\LoggerInterface');
?>

Note this should effectively work a bit like the use statement in that it shouldn't trigger autoloading (maybe an optional parameter should trigger autoloading for debugging).

To give some historical context, I got the idea for this while listening in on a ZF2 IRC meeting. So I briefly mentioned this idea after the meeting and it seems like Ralph also saw some merit. Again neither of us was thinking about any way to alias method names let alone supporting reordering of signatures etc. So the use case would essentially in 99% (except for coincidences) of the cases still require direct communication between the authors of the libraries.

Of course another alternative to the "how to get the interfaces to my users" would be to make them part of PHP itself. Here I see a lot of practical issues:

the interfaces need to have to be mature, but right now each framework has their own interface, so each framework matures their own with their own names
getting them into core will add a lot of lead time for the collaboration to pay off, making it less interesting to collaborate to begin with
not everybody will necessarily want all the interfaces people decide to collaborate on but it also makes no sense to then start separating them into optional extensions as this would bring us back to square one
actually there could still be "competing" interface definitions as there could be different subsets of the community collaborating on interfaces for the same or overlapping "topics"

As this solution would allow collaboration between projects with minimal logistical pains it could also then be the way to mature interfaces to the point where they are sufficiently widely adopted and used that it makes sense to put them into core. And this solution would then also be an easy to use migration path for the original collaborators. So with the above approach we are just offering a practical solution to real world problem. It certainly feels hacky, but at least even after a few days I still haven't decided that its going to spell the end of the world either. So what do people think?

Collaboration is scary

Lukas Kahwe Smith — Mon, 28 Nov 2011 22:53:18 +0100

Collaboration usually requires communication and compromises. The pay off in the long run should come in the form of saved time, higher quality and a healthier ecosystem. But how does this all work out in practical terms? I remember a university course labeled "code is law". Talking about the hard facts that code defines. The topic there was mostly about stuff like how the default settings of apache define the reality of what gets logged and not whatever the governments privacy laws define. At the same time it can make collaboration harder, just because one group got their release out first (potentially rushed?) does it mean that their BC concerns outweigh your design concerns? Even if neither or both parties have released code to think about, you might have some other standards are tastes already developed that collide, how to decide the direction, especially if you have a sense you might end up being the junior partner? Now even if both sides are perfect gentle(wo)men will the end result not be some mushy half of everything compromise with no real world value?

There are lots of reasons I just listed to be scared of collaboration and there are probably a bazillion more. I guess the trickiest part is finding a sense of trust. Trust in each of the parties involved, despite each coming from a different "camp", that they still want to search for the greatest sensible common denominator for the joint user base. In that sense likely the biggest obstacles are not even technical but social .. or maybe the success of collaboration is even coincidence of having the right kind of people meet at the right table at the right point in time feeling adventurous, bold and forward thinking.

Travis, CI for OSS

Lukas Kahwe Smith — Sun, 13 Nov 2011 20:58:06 +0100

Continuous integration is one of these topics that had a slow start, but in recent years has really taken off. The slow start is likely to be attributed to the fact that it was perceived as hard to setup and maintain. But solutions around Jenkins and Sismo are making it easier and easier. But thanks to the new Travis CI service, its now essentially so easy that there is no excuse not to use CI for PHP projects, at least if you are hosting your OSS code on github.com. What makes this service so crazy cool is that you can run your tests against multiple PHP versions, multiples databases (heck even RabbitMQ) and against multiple versions of various libraries. For a prime example of this check out Doctrine2 on Travis. You can configure tons of stuff, like various ways to get notified in case a build fails and you can even include a little status icon that gets updated automatically into your project description. In short this is amazingly awesome and again its free to use for any open source project out there!

Maybe a short back story. Alvaro poked me I think earlier this week about Travis. I was immediately won over and poked Pascal who is working on the CI setup for Symfony2. I added a few Liip Bundles, while Pascal tackled the bigger projects like Symfony2 and Doctrine2. The Travis team, especially of course PHP native Loic, where super helpful in the #travis channel on Freenode IRC. Pascal figured out how to run Doctrine2 against multiple databases. Loic showed me how to run against multiple Symfony2 versions and I proceeded to add several FriendsOfSymfony Bundles. All within a single week!

So here are some things I learned in the process. First up it is a pity that Github doesn't provide oauth tokens for organizations. As a result I ended up creating a dedicated github user for the Liip Bundles that points back to a closed mailing list for the notifications. For FriendsOfSymfony I am simply using my personal token. Note for personal repositories there is a nice UI on travis-ci.org to enable/disable integration. For organizations you will have to go to the organization repository and under "admin" click on "service hooks". Then click on "Travis", then scroll back up leaving domain empty and finally your username and token as seen on the Travis CI profile page.

Second of all I learned that google groups are painfully annoying for this use case as its impossible to allow an automated service to post to a moderated list, as there is no way to cannot confirm a mailing list invitation. Oddly enough I can't even set the list to moderated for non members, since I was unable to get google groups to not require moderation again for a once moderated sender. Speaking of notifications, some people *cough* Jordi *cough* complained about me spamming the FriendsOfSymfony mailing list with tons of emails. In general email notifications are only send if a build failed or if I build just switched from failed to success. So ideally once we get a Bundle passing, we should never see another email unless a commit breaks the build.

Anyway, I think they included lots of Bundle configs in the official docs but I just briefly want to touch on the topic of vendors and autoloading. So right now I setup all Bundles to contain a simple vendors.php script inspired by the script contained in the Symfony2 repository. I also added an autoloader.php.dist as the default mechanism for autoloading in the tests. But the user can define an autoloader.php to override the default which is useful to be able to run the tests against a local checkout of the dependencies without having to run the vendors.php. But the future is much brighter as Loic is looking to add composer support. Once that is in place it will no longer be necessary to write separate vendors.php script or autoloaders since composer can handle all of that for you.

Another thing that will come soon hopefully is to define a url to the ".travis.yml" file, like via a gist, so that its no longer necessary to store this file within the repository. Personally I do not mind this file at all, since it also serves as documentation on how to get the test to run, but I am sure some people might feel the this is ugly *cough* Jan *cough*. At the same time these days most of us have a "phpunit.xml.dist" file already and this is no different to me.

Anyway this service is really exciting and I hope that other projects will also adopt this tool quickly. Even if these projects have their own CI setup already, I think it doesn't hurt to add Travis as well since this way its also easy for people that work on a feature branch to setup the CI hook if all the configuration is already done for them. As a matter of fact if all goes well we might start asking submitters to include the status image as part of their PR's. This is way superior to the current check list item we have, since I must admit when I send a PR for the first time I may run the tests, but when I do minor tweaks I made forget to run the tests again and so my claim that the tests pass might get outdated.

Update: Forgot to mention that one of the Travis guys will give a short tech talk about Travis at Liip on the 17th at 11:30 CET. You can attend at any of our main locations in Zurich, Fribourg and Lausanne and I will check if its possible to put up a live stream.

Update2: Just heard that the Travis team might work on PR support as well.

Update3: Travis CI guys also have an idea for how to make it possible to have the easy flip switches for all organizations and their repositories a given github user has admin rights to.