November’s Bug Hunt Days are over. More than 100 bugs were fixed. Fixing that many bugs wouldn’t be fixed without excellent guide about participating in Bug Hunt Days written by Padraic Brady.
Many Zend Framework users fail to realise that the Zend team is comprised of about three individuals. Three people cannot address 1600 issues this side of the 22nd Century and it’s totally unfair to complain about the issue count in this light. They need assistance. They need people to fill in for former component lead developers, inactive developers, and developers who are mysteriously missing in action. But mainly they need more eyes and keyboards to clear issues.
Bug Hunt Day’s goal is to help Zend Framework’s team in fixing as many issues as possible during the event. It is great opportunity for those who want to help developing the framework but can not do it on regular basis. Because such people usually don’t know where to start, whom to ask, how to use provided tools or simply commit the code, Padraic’s guide should be first thing to read before participating in Bug Hunt. Check it out and see that participating in Bug Hunt Days is not that hard.
Week ago Matthew Weier O’Phinney published roadmap for Zend Framework 2.0 and invited community to discussion about planned changes. Since 2.0 will be first major version following first stable release (1.0), everyone expects backwards compatibility breaks in exchange for improved overall quality.
Most important things that will change, commented also by community (for instance by Giorgio Sironi), are:
- Minimum PHP version requirement – it will be PHP 5.3, but which particular one is not decided yet.
- Unified constructor – among many other profits it will allow Dependency Injection.
- Exceptions – base exceptions of components will be interfaces.
- Design by contract – during refactoring new interfaces will be created (or existing ones refactored) to reflect actual usage. The goal is to let developers create their own implementations of particular components or their parts instead of extending existing ones. Moreover, default implementations should be lightweight, covering common case functionalities only. It means, that functionality of some components will be reduced. It also means that framework will be faster and simpler to extend.
- Elimination of singletons – there are simply too many singletons in the framework. Most of them will be eliminated.
- Namespaces – underscore _ in class names will be dropped in favour of namespaces.
- Autoload-only – for coding simplification and solving some performance issues.
- MVC refactoring – it is impossible to summarize what will be changed since all related components will be refactored according to roadmap’s guidelines. Expect lots of BC breaks, but also greater testability and performance.
Joey Rivera wrote good introductory post about using Zend_Cache and caching in general. He explains what is caching, what are the benefits of caching (giving real numbers to compare) and shows how Zend_Cache can be use to cache different things in any project, not only Zend Framework based.
When ever possible, it’s more efficient to serve a static file or static content. We use cache to accomplish this. In this post I’m going to talk about caching files and database queries to local files on the server. (…) There are different ways to achieve this. I personally use Zend Framework on my projects so I’ll be using Zend_Cache in my examples. I will only be using Zend_Cache as a standalone module, not the entire framework. This way, those of you who don’t use Zend Framework can still follow this guide.
If you are new to caching and want to learn how and when to use it, this article was written exactly for you.
LiveDocX service is getting popular. It lets you prepare PDF, DOCX, DOC and RTF documents using templates. On PHPFreaks.com you can read about how to use LiveDocX component of Zend Framework.
The key point with LiveDocx is to reduce the effort required to generate well-formatted, print-ready word processing documents to an absolute minimum. For the end-user, the logic involved in creating any of the supported file formats is identical. For example, regardless of whether you want a PDF or RTF file, the code, with the exception of one parameter, is the same.
Sounds interesting? It should. This new approach reduces time developers spent on writing document generation code.
There has been lots post published about unit testing in Zend Framework recently. Most of them show how to setup simple testing environment and write simple test. In his recent post Giorgi Sironi shows how not to test Zend Framework action controllers.
Yesterday on twitter a discussion started about how to properly design Zend Framework action controllers to allow simplicity of testing, specifically how to inject collaborators in controllers and to avoid breaking the law of Demeter.
Presented real life example seems to be simple and typical. Giorgio explains what is wrong about it and what kind of obstacles from unit testing point of view it creates. The post is not only about how no to test controllers but also about what controllers should and should not do.
Update
Giorgio’s post has its continuation, where he explains why we can drop unit testing controllers and what controllers really do.
Update 2
Giorgio published another follow up to his, as we see controversial, post.
