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.
