ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
[1]  «  3  4  5  6  7  8  9  »  [71]

.EU PHP company knowledge exchange

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.
read on (comments 5)

Loose interface coupling

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.
read on (comments 10)

Collaboration is scary

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?
read on (comments 2)

Travis, CI for OSS

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!
read on (comments 7)

State of the Symfony2 CMF

People keep asking me when the CMF will be ready. Or they say that they will join once its further along because they think its too far away to be relevant for their clients today. So the good news is that Liip already has a huge client using CMF components. The combination of Jackalope with Jackrabbit and the PHPCR ODM (provides a similar API than the other Doctrine ORM/ODM) is ready for prime time. There are also already a fair number of components in different state that are close to be finished, simply concepts or not yet compatible. In other words we sort of have all the ideas and many pieces. We just need to put them all together which I will hope will be done no later than Q1 2012. I think we can hit this date even if no new contributors join and we just have the same slow but steady stream of patches. That being said, right now I would guess that 80% of the work is done by Liip employees, either sponsored by Liip, directly funded through client projects or done during spare time. Essentially the only other significant code contributions have been made by Ideato as well as Uwe, Johannes, Thomas and since very recently Nacho. So the numbers are growing, but given the over 200 people on the mailing list this previous list seems a bit short.
read on (comments 4)
[1]  «  3  4  5  6  7  8  9  »  [71]