When it comes to working on several projects with different people, having a set of standards to dictate code use and code re-use is a good thing to have. PSR-0 is one such accepted standard.
It took a while to realize it, as I so often do, that many useful improvements to PHP mean a few steps forward, a few steps back. I’m going to try to list a few patterns which are the cause of some conflict when implementing PSR-0.
I tend to have a lot of development ideas stemming from repetitive workloads or from an optimization standpoint. I tend to obsess over inefficient code structures in both. I’ve literally had dreams that provided me with answers which I implemented during the day. If only we could code at night during sleep. In retrospective, the Pareto principle applied to that subconsciously-influenced code base, meaning 80% of its usage was fine, and 20% was outside of the scope I was trying to solve and introduced other problems. More about that some other time.
Sometimes it’s not about just optimizing CPU time away. Looking at the details I could optimize away a badly written SQL query along with some more trivial big-O problem in regard with sorting of video clips which I got out of serialized data. All from a few carefully placed calls. Reducing network bandwidth is just as important as CPU time.
Every once in a while you need to do a sanity check of your code, how it performs and what you can do to improve it. This is most apparent with a code-base that is developed and refactored over a period of several years. There can be several problems that negatively impact performance due to dependency issues or legacy code that should have been removed but was forgotten during a refactoring sprint.
I also held a talk about Redis and some experience we got with it at RTV Slovenia. The talk slides are up at Slideshare.
- Tit Petric
It was the year 2001. I barely started out with PHP and eventually MySQL. A client had this wish, to log and analyze its web traffic (a substantial amount of it), and because of a clustered environment, and also lack of detail with existing solutions the only available solution then was to develop our own analytics package with php and mysql. While at first we didn’t have problems scaling, we have quickly grown the log data and eventually hit barriers as disk space availability, concurrency issues (MyISAM …) and then query speed itself for analyzing data (sum, count, avg …).
