Last week, I read a post by Beau Simensen about resource location in PHP. It was interesting, because I had already pondered over this topic in the context of Symfony2. Thinking about how to make Beau’s proposal work for Symfony2 brought me to a result that hit me like a stone. Both he and Amy Stephen made me realize how much this could change not just Symfony2, but the PHP ecosystem as a whole. After PSR-0 and Composer, this is the next important step to ensure interoperability between PHP libraries. And it could almost completely replace the new and hotly debated autoloading PSR. Let me take a few minutes of your time to explain why.
Recently, Aura is creating some buzz that components of PHP frameworks should not have any dependencies. To quote Paul M. Jones’ recent article on Aura:
The distinction is that all Aura packages (with the exception of the Framework package) are completely independent, and have no cross-package dependencies, whereas at least some of the components from Symfony2 and ZF2 have dependency requirements.
Or, quoting this article on replacing Silex with Aura.Micro:
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.
I think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.
Every once in a while, I get into an argument about extending PHP’s
Traversable interface instead of the
Iterator interface in custom interfaces. The confusion seems to result from the official documentation of
Traversable. Let me clarify why you should give
Traversable much more love than you do right now.
You are joining the Symfony Live conference in San Francisco this year? Good! I will be giving a talk about the Symfony2 Form component and you have the unique opportunity to vote on what I will be presenting. Today I have put up a survey with 23 topics that may find their way into my talk. These topics include questions such as:
- How can I access the entity in buildForm()? I want to customize my form based on some property.
- There are so many events, when should I use which one?
Which of these topics I will present is entirely up to you. So please take the survey and help me improve your experience of my talk. Oh, and if you take the survey there will be a prize, and a raffle, and one very lucky person… :)
You aren’t joining the conference in San Francisco? Then I also warmly invite you to participate in the survey. Pretty much one year after the first release of Symfony 2.0 and shortly before the release of version 2.1, we are eager to learn what our users are happy about, what they struggle with and what they would like to see improved, both in the usability and the documentation of the Form component. Unfortunately, you won’t be able to participate in the raffle during the conference, but your feedback will tremendously help us to improve future releases of the framework and its documentation.
This post was partially triggered by the release of the new Zend Framework 2 Form RFC because I think that a lot of duplicated effort is going on there. I completely understand that Zend Framework 2 needs a form layer that is tailored to the components delivered by the framework. The purpose of this post is to demonstrate that the Symfony2 Form component is perfectly suited for this requirement. Symfony2-specific functionality can be unplugged, leaving only the raw core dealing with form processing and abstraction. As a replacement, functionality can be developed for supporting Zend’s or any other framework’s components.
Creating a generic form library that elegantly solves all the various use-cases that can be found in web form construction and processing has been a challenging, long-lasting and complex task that is not over yet. Cooperating and continuing development from this common base on seems like a big chance to make form handling in PHP more powerful – and easier – than it has ever been before.
Although most modern literature agrees that testing is essential for successful software projects, testing has to be done right. Several bad habits can be identified that not only negatively affect testing performance, but also reduce your development speed. One of the first mistakes people make when they first discover testing is trying to reach 100% code coverage. I was no exception. Read the rest of this entry »
Unit testing can be a blessing and curse at the same time. Once you start doing it on a regular basis, it can become an addiction. You test everything, you feel the satisfaction of 110% test coverage giving you confidence in your code. But after a while, testing suddenly seems to slow you down. Everytime you make a change in your code you have to adapt several unrelated tests. Adding a
<ul>-tag to your template becomes a matter of minutes, rather than seconds. And, worst of all, your test suite is slow.
What happened? Read the rest of this entry »
Yesterday I returned back to Vienna from Symfony Day Cologne 2009. The conference was amazingly well organized and many people deserve credits for making it such a great experience.
Thank you Andreas and Dennis for putting uncounted hours into planning the event, guiding us around the city, spending the night before fixing the wireless connection and for taking care of all the other small things that usually go by unnoticed. Thank you Isabelle for your Cologne crash course and for organizing our flights and the perfect accommodation. Thank you Nicolas for your many thoughtful advices, I really appreciate them. Thank you Xavier, Stefan, Jon and Sebastian for your refreshing company; I really enjoyed the lengthy walks around the city, even though my foot complained somewhat. Thank you all the attendees who gave me feedback about my work and my presentation. Thank you Interlution for letting us take part in your 10 year anniversary party. And thank you all the other people involved in making this event a success.
Events like this one are really important for the community. They put faces behind names, make friends, open up new opportunities and spread ideas. They are what open source truly is about.
As another result of the conference, this blog features a new page Talks where I included the slides of my presentation Best Practice Testing with Lime 2. And to those who annoyed me about Twitter – apparently some new account @webmozart has been created over there. Don’t know who it is, but don’t expect him to tweet too much.
Today, I will take the plane to Cologne to attend the first german Symfony Day. The one-day conference is going to take place on friday on the 28th floor of the Köln Triangle, the second highest building in Cologne. Located directly at the bank of the Rhine, the tower offers a magnificient view over the city. Interlutions, the company organizing the event seems to have done a very good job.
The conference will offer a full-day workshop held by Stefan Koopmanschap for those who are just getting started with symfony. Advanced symfony users can attend five promising speeches by Nicolas Perriault, Xavier Lacot, Rob Bors and Jonathan Wage, who is accountable for two presentations. I had the pleasure to be invited as the fifth speaker, and I am going to talk about unit testing.
Automated software testing, when applied in a real context, is not always as easy as it may sometimes be portrayed. You need experience to design your software in a testable fashion, discipline to keep writing tests when pressure keeps increasing, tools to support your testing needs in the best way possible and knowledge to employ these tools efficiently. If any of these aspects is lacking, your team may very quickly end up not writing any tests at all. Even if you fight your way through the battle and manage to keep test coverage high, chances are that your tests become very slow. A bad test performance, in turn, prevents people from running them frequently enough – and turns all your testing efforts into a waste of time.
In my presentation I want to give you a deeper insight on what testing is all about. Not only do I want to present you best practices that worked for me, I also want you to understand the testing process so that you can go on developing best practices for yourself. I will try to focus on pratical examples; nevertheless I expect you to have a fair knowledge of writing and reading unit and functional tests with lime. For all those who won’t be able to join, the slides will be uploaded on this blog as soon as I probably can.
The presentation will also give you the opportunity to get a first glance of what Lime 2 is going to offer you. I have been busy developing the successor of lime over the last months and am happy to see that it is steadily approaching alpha release. The detailed release plan is soon to be published on the symfony blog.
I am already excitedly looking forward to meeting you all!
The “default” context does not exist.
Is there any symfony developer out there who never stumbled upon this dreadful error message? I doubt it. Recently, a lot of posts have been made on the user mailing list asking for explanations and fixes. A quick search on Google for the exact phrase even returns 480 results!
The reason for this error is quite simple though: It’s because you used
sfContext::getInstance(). And you should never do that. Read the rest of this entry »