@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

I struggled to come up with a good name for this blog post, and have totally failed, but give this article a chance. Or maybe you’re here by accident thanks to a weird google search.

As a committed user of open source technologies, the difference between me using something and not using something is the documentation. Is there documentation for it? Is it easy to find? Does it answer my questions? Is there someone I can call an idiot if I disagree with the level of documentation? These are all very important questions.

My involvement with CakePHP has opened my eyes in terms of what people consider documentation. Me, I’m the type who learns from examples that come with explanations. While API documentation is great, it only becomes useful to me once *I* can figure out how to do something useful with this new technology. I see people on the mailing list for Cake asking for the source code to a sample application, which I immediately file away in my head as “looking for answer to their homework”, and move on. Maybe that’s unfair, but it’s more a reflection of the fact that I tend not to learn anything from having the source code for an application. I learn by getting in there and DOING SOMETHING and figuring out why this goddamn thing is not behaving properly and who do I know who can help me with this problem etc. Learning by mooching, I call it.

So, back to CakePHP. CakePHP had acquired the reputation that the documentation for it sucked. While I did not share that opinion, I can see why people say that. Because most coders are lazy. Seriously. They want solutions handed to them in a form that they can just drop into their application and then get onto the next problem. There are definitely times when I wish someone else could just write this goddamn “alter the football game stats form dynamically via Ajax and send the results to the XML database” code for me. Inevitably, I build the code up from an example stolen via Google into something that both works and that I understand fully. However, most of the time I am content to figure stuff out on my own and ask for help only when stuck. I’m not lazy, but maybe I’m suffering from a bit of the Lake Woebegon effect.

So, things are much better in terms of documentation for CakePHP. Whereas we used to have a manual that only covered 1.1, we now have the amazing CakePHP cookbook that covers both 1.1 and 1.2. If that’s not enough, well, you might actually have to do a little thing I like to call “research”. This gets us to the point of this blog posting. Sometimes you have to stop being lazy and actually think about where you could find an answer.

There are no shortage of blogs that talk about CakePHP. Some of them are even good. Maybe you like the code examples I put up here. People seem to like them enough to comment, so maybe I’m doing something right. Google is your friend to track down blogs that have exactly the type of information that you need: small examples with explanations about how they work.

The CakePHP mailing list is done via Google Groups, so all those posts where I make fun of people for no reason other than my poor self-esteem can be found with a few keywords. But there are a lot of great tips on how to accomplish things using Cake, so a search of the google group will find lots of good information.

The Bakery is another good source of CakePHP info, consisting of all sorts of small articles along with comments. It has a search function as well, but could easily be considered YACB (Yet Another Cake Blog). Again, perfect for people with the same learning style as me: short examples with explanations of how it was done.

Finally, we come to one of the more unorthodox documentation sources: the unit tests for CakePHP. CakePHP has some really good unit test coverage, although I sometimes wonder if you can really say that a piece of code works properly if it passes all the unit tests associated with it. This is by no means a phenomenon limited to CakePHP, it happens everywhere there are unit tests. Sometimes you can’t figure out a test that makes something break. It happens, so please do not misinterpret my thoughts on this. Unit tests are good, and the amount of tests that CakePHP has in place is awesome and perfect example of a cohesive development team. Automated testing is a goal worth striving for, don’t let anyone else tell you otherwise. I’m in the early phases of automated testing for a work project on the integration side of things because I’m tired of always running through the same damn tests by hand all the time to make sure something that I wrote didn’t break things. Tips on what good browser-based solutions are out there would be appreciated. Other than telling me to use Selenium. A solution that is tailored to the framework I have been forced to use would be even better.

Okay, back on topic. Since the unit tests cover so much of what CakePHP can do, what better way to see examples of how to actual do things? My work on fiddling around with new console functionality showed me that I had no idea of how to create unit tests for my console work. That led to discussions with people on the best way to do testing of console functionality. Which leads to changes in the console code itself to make it easier to test certain things. But at least when I’m ready to get back to doing that console work I can see if doing testing for it has become easier.

So, having been told all the stuff above, how can anyone who is not simply lazy say that the documentation for CakePHP sucks?!?

The summer is always the worst for me in terms of blogging. That’s when I have to run my team in the IBL, play slo-pitch (or softball for my American readers) at least once a week, do side-jobs to help pay the bills, and spend time with the family. Phew. So, that leaves little time for the types of activities that lead to good blogging. But never fear, I will continue to dispense what wisdom I can from here. So, here’s some of the things I’ve been thinking about.

Closures and lambdas coming to PHP

Via twitter I found out that PHP 5.3 is going to have lambdas and closures. I suggest you google around for a better explanation of what they are, but they are an incredibly powerful tool. If you do any Ruby on Rails work, you end up using them. If you use jQuery, you end up using them. I had a conversation in twitter with Mr. Git Book about this, where he accused me of being a “closure hater”. Believe me, I’m not a hater of that particular programming construct. I simple expressed my feelings that given how horribly some PHP programmers abused OOP concepts, I imagine the same things happening with lambdas and closures. Please prove me wrong.

Where The Hell Are The Easy Layout Editing Tools For Non-Designers?!?

I have a side job where I am taking an existing app and converting if over to CakePHP, but preserving the look and feel. What this poor designer-challenged programmer needs is a tool that will take that existing HTML and let me edit it in a fairly intuitive way so I can fix the so-many-damn-tables-I-want-to-bleach-my-eyes layout that exists. Can nobody help me with this? Sheesh. I don’t want to burn up my billable hours fucking around with layouts.

The Framework Jihad

I need a “Framework Jihad” t-shirt. Size 2XLT, please.

Yes, the arguments about frameworks will just not go away. Which one is best?!? Why should you even use a framework?!?! And the more it goes on, the more ambivalent I feel about it. I cannot think of the last time I wrote a PHP script that was NOT part of a framework. Hell, even my Python programming has been 75% Django and 25% straight Python, but that’s only to do things like loading up databases with info from a CSV file. But here’s what I think: the Framework Jihad is winning.

If you substitute “modularized code with standardized API” for “framework”, would that make people feel better? I use frameworks because so much of the infrastructure code is stuff I DO NOT WANT TO WRITE ANY MORE. After 10 years of doing this, it’s time I stopped reinventing things. My old motto of “just build it, damnit!” requires a structure around your application to let you quickly build something. To me, that means a framework that has taken care of database access and application flow and templating.

The number one complaint about frameworks appears to be that they are slow and have all sorts of overhead. Fair enough, but I tell you what: I’ll worry about scaling when I, you know, have something to worry about. If I get to the point where I have to worry about scaling, then I have done very well indeed. Despite our desires, not everyone can create a Flickr or Twitter. They are the lucky ones. The rest of us should shut up and just build something.

It’s just too easy to dismiss the Framework Jihad as irrelevant. Like many things in life, dismiss it at your own peril.

(Disclaimer: after trying out the demo for this application, I discovered I could get a license for it by saying nice things on my blog. I was ready to fork out the money for it though)

I cannot be the only one useless at interface design. I know my buddy and fellow patio-laying-at-my-house-worker Kevin is too. While checking out Hacker News I came across this great application called Mockups, which is cool AIR app (I use Ed Finkler’s so-awesome-I-actually-use-it AIR Twitter client Spaz) for (shocking, I know) doing mockups of things.

When I saw this, I said (really) “Holy shit!!!”. And started to play with it. And quickly realized that for people like me, this is the PERFECT tool for creating mockups of the sites I want to work on. I agonize over sites when I’m building one from scratch, so much so that I feel the “paralysis from analysis” effect I have heard others talk about. Don’t believe me that it’s this cool? Check this demo out:

To me, the really cool thing is that it is also available as a plugin for some of the most well-known collaboration applications out there: Confluence, JIRA and Twiki. For me, the desktop version is just right, as I can take those mockups I create and export them as PNG’s that I can then pass onto designers for comments and tweaking. This is a sign of a developer who is “done, and gets things smart”.

It costs $79, and for the frustrated programmer who wishes he could better as a designer, this is an amazing tool to add to your toolbox. Go try it out and give him your money!

Earlier today I say the following tweet on the-often-down-but-always-interested Twitter from Matthew Weier-O’Phinney:

“What issues to _you_ see with using namespaces in PHP? Start blogging!”

Since I am one who likes to share his opinion on a wide variety of topics, I thought this is a good one to prompt discussion.

Namespaces are expected to be a feature in future releases of PHP. I’m an outsider when it comes to tracking the going-on in the world of PHP internals. So, because of that, I’m not going to comment on the actual syntax of how namespaces will be implemented or it’s impact on internals. That’s not really important as far as this particular discussion goes.

Imagine if you will that you are the user of a web application framework that allows you to easily use third-party libraries by dropping them into a specific location in your application structure. You go to use it and…what the fuck?!? Class name conflicts?!?!? ARRRRRRGGGGGGGHHH. You proceed to post to the mailing list for said framework, complaining bitterly about how you cannot use your favourite library with this stupid framework. Some grumpy guy from Canada flames you in response and it spirals down from there into oblivion.

There are many programming languages that support namespaces, but PHP was not one of them. Why are namespaces so important? They can help to solve the exact problem mentioned in the paragraph above. Why *wouldn’t* you want such a thing?!?! You can have 5 classes with the same name in 5 different namespaces and everything will be just fine. Except for the fact you have 5 classes with the same name. That’s not good design, but namespaces would let you do that.

So, to go back to our little framework example for a minute, the framework could assign itself a namespace (oh, I dunno, like ‘Cake’) and if you happen to want to use a 3rd-party library with your application that has a class with the same name, it’s all good…as long as you didn’t put your own code in the same namespace.

So, to answer Matthew’s original question: I cannot think of any reason to NOT have namespaces in PHP.

Man, my blogging pace has slowed right down. Not doing anything particularly exciting will do that to you. So, I thought I’d take a break from trying to diagnose a production-only bug (you know, the type of bug where the code runs perfectly in dev but doesn’t work properly in production) that is mocking me, and taunting me while I feel the burn from starting the 100 pushups challenge (damn you Twitter for the peer pressure!). In case you’re wondering, I am starting at rank 1 because I think I have the upper body strength of a man twice my age.

Last week I wrote more Javascript code than PHP code, which is an interesting trend so it has me thinking about front end development a little more. I still suck at interfaces (Rallyhat’s UI is giving me analysis paralysis) but recent developments make me feel a little better.

In a previous post (not gonna self link, so search for it) I talked about why can’t I have an all-Javascript back-end talking to an Erlang server. Well, other than the fact that I don’t know any Erlang I mean. This is why projects like Sproutcore have me excited. Never mind the whole “Cocoa on the web angle” that a lot of people are talking up when describing it. It’s exciting because it is promoting a “back-end neutral” philosophy and emphasizing that people who ignore Javascript are turning their backs on a lot of good functionality.

Javascript + any back end that can spit out JSON is really what a Sproutcore application is. I know the word paradigm shift is thrown out there a lot and is really overused, but I think the fact that something like Sproutcore is out there shows that web development itself is undergoing a shift. I know that there are lots of examples of advanced Javascript + some back end in use (GMail, anyone?) but the fact that Sproutcore is getting some backing from Apple should tell you how important some people feel this type of application architecture could be.

It also simply reinforces my thoughts that knowing one language is no longer enough. Just think of what you would need to understand in order to build something in Sproutcore using, say, CakePHP as the back-end:

• HTML
• CSS (can’t have those pages looking ugly, right?)
• Javascript (although I’m wondering if jQuery and Sproutcore can co-exist)
• PHP
• SQL (have to be able to understand the queries being generated)
• JSON (does that really count as a language or is it just encoding really?)

The funny thing is that I now use this stuff without really considering that they are separate. I just use ‘em all, and abuse my relationships with people who are smarter than me to fill in the gaps. It’s the only way, really.

I believe Sproutcore is just the first of many Javascript application frameworks that will come out, so keep an eye peeled for the copycats and the “I did this because my problem is so unique that I could not use an existing solution” crowd. The signal-to-noise ratio will be low, but worth wading through.