New for CakePHP 1.3 is the ability to create and use custom route classes for your application’s routing. In the past the router did double duty, managing route collections and routes were just arrays. In 1.3 Router underwent some surgery and CakeRoute was extracted as an object to represent a single route. While Router was left as a manager of routes.
I recently read “Clean Code” by Robert Martin an excellent book on writing clear, easy to maintain and well factored code. In it Robert Martin raises the point that methods should do what their names say, shouldn’t have ‘flag arguments’, and should do only one thing. This implies that overloaded methods are out.
You may have seen the Analog.coop site recently and found some of the easter eggs, like the grid hot keys. I loved the concept, and made a mental note to spend some time reverse engineering/rebuilding it for my own uses. Well it just so happens that the guys at Analog have released the #grid on Github, which is great because it made it easier for me to adapt the code and do some small improvements.
Last night I updated this site to run on the latest 1.3 build. While I know I should have done it earlier, I simply haven’t had the time. And since I went through it, I figured I could document it and share what the upgrade process is like for a small site, that doesn’t see a ton of maintenance action like this one.
I’ve been working on a client project that involved some reasonable amount of SVG/VML work. In order to make my life more sane, I’ve been using RaphaÃ«l JS to do what it does best, which is provide a great API for making sexy vector graphics.
Everyone can breath a sign of relief. Late last night there were rumours that CakePHP had died. Confusion and disbelief spread pretty quickly through twitter, and IRC. However, CakePHP is doing great, and is very far from dead.
Although PHP5.3 is still hot off the press, and a very exciting release in its own right. I must say I’m far more excited about the grafts and traits that have been proposed for PHP6. While PHP6 is still a fair ways off from being released, Stefan Marr has backported the changes to PHP5.
Shells are one of the more difficult objects to properly unit test. Since they normally run in a CLI context instead of a web context they provide some interesting challenges. The biggest hurdles are separating the Shell from the CLI environment, and simulating the correct arguments and parameters.
Previously, I wrote about using two versions of PHP with macports . In it I covered installing PHP4 and PHP5. Since then PHP5.3 has been released as a stable release. However, I needed to maintain my PHP5.2 installation as I have a number of client projects that are on servers using PHP5.2. So to reduce version insanity I wanted to keep 5.2.
If you’ve been following the ongoing development of the 1.3 branch over at code.cakephp.org:http://code.cakephp.org. You may have noticed that bake has had a significant overhaul, and a number of features and enhancements have been built in.
So originally when I built this site, I was in the “requestAction is bad” camp. So much so that I created a convoluted Component to assist in the creation of the sideboxes featured on this site. A sample of that code is as follows:
While I’m a big fan of Mootools I work on a few projects using jQuery, and have recently been working on a project that needed a custom markup editor. I’m a big fan of the markItUp editor. Its a flexible and easily extensible editor, that affords a great deal of features in a small package.
As a mac user, I’m a huge fan of the great work the people at MacPorts do. If you haven’t used MacPorts before, its basically a mac version of apt-get or rpm and allows you to install all kinds of unix-y goodness from source code on OSX.
What started out small has grown into an ugly tangled monster. As with many people’s github accounts, mine only had a few things in it at first and all was well. But as more code was written the repository began to smell and was in need of some splitting up. So that is what has been done.
I spend a lot of time in various IRC channels answering questions and helping out, and one recurring theme that pops up again and again is people not knowing what to do when things go wrong. Whether it be a simple error or a logical mixup, people often lack the tools or processes to figure things out. So I thought I would share how I approach errors and problems.
In the ongoing struggle against code bloat and creative ways to do things, I’ve been playing with throwing exceptions from model methods. While not earth shattering stuff, I’ve found it to have a few advantages over returning false. First, you can end up with less if and else statements.
Re-factoring code is a part of any programmers life or should be. Very few people write beautifully clean and well factored code from the start, and I am certainly not one of them. Most times my code starts out a sprawling tangle that takes an additional pass or two to look like something I would consider clean. I find that when programming and designing I start with a rough idea or sketch of what I want to accomplish.