Blog Posts
ZF2 Forms in Beta5
Forms are a nightmare for web development. They break the concept of separation of concerns:
- They have a display aspect (the actual HTML form)
- They have a validation aspect
- And the two mix, as you need to display validation error messages.
On top of that, the submitted data is often directly related to your domain models, causing more issues:
- Not all elements will have a 1:1 mapping to the domain model — buttons, CSRF protection, CAPTCHAs, etc. usually are application-level concerns, but not domain issues. Names valid for your domain model may not be valid names for HTML entities.
Add to this that the validation logic may be re-usable outside of a forms context, and you've got a rather complex problem.
On Visibility in OOP
I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use.
Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.
Automatic deployment with git and gitolite
I read a post recently by Sean Coates about deploy on push. The concept is nothing new: you set up a hook that listens for commits on specific branches or tags, and it then deploys your site from that revision.
Except I'd not done it myself. This is how I got there.
Why Modules?
I've blogged about getting started with ZF2 modules, as well as about ZF2 modules you can already use. But after fielding some questions recently, I realized I should talk about why modules are important for the ZF2 ecosystem.
Developing A ZF2 Blog
This post tells a story.
A long time ago, I set out to write my own blog platform. Yes, WordPress is a fine blogging platform, as is Serendipity (aka "s9y", and my previous platform). And yes, I know about Habari. And, for those of you skimming ahead, yes, I'm quite aware of Jekyll, thank you anyways.
Why write something of my own? Well, of course, there's the fact that I'm a developer, and have control issues. Then there's also the fact that a blog is both a simple enough domain to allow easily experimenting with new technology and paradigms, while simultaneously providing a complex enough domain to expose non-trivial issues.
When I started this project, it was a technology-centered endeavor; I wanted to play with document databases such as CouchDB and MongoDB, and with caching technologies like memcached and redis.
Not long after I started, I also realized it was a great playground for me to prototype ideas for ZF2; in fact, the original DI and MVC prototypes lived as branches of my blog. (My repository is still named "zf2sandbox" to this day, though it technically houses just my site.)
Over time, I had a few realizations. First, my actual blog was suffering. I wasn't taking the time to perform security updates, nor even normal upgrades, and was so far behind as to make the process non-trivial, particularly as I had a custom theme, and because I was proxying to my blog via a ZF app in order to facilitate a cohesive site look-and-feel. I needed to either sink time into upgrading, or finish my blog.
My second realization, however, was the more important one: I wanted a platform where I could write how I want to write. I am a keyboard-centric developer and computer user, and while I love the web, I hate typing in its forms. Additionally, my posts often take longer than a typical browser session — which leaves me either losing my work in a GUI admin, or having to write first in my editor of choice, and then cut-and-paste it to the web forms. Finally, I want versions I can easily browse with standard diffing tools.
When it came down to it, my blog content is basically static. Occasionally, I'll update a post, but it's rare. Comments are really the only dynamic aspect of the blog… and what I had with s9y was not cutting it, as I was getting more spam than I could keep up with. New commenting platforms such as Livefyre and Disqus provide more features than most blogging platforms I know, and provide another side benefit: because they are javascript-based, you can simply drop in a small amount of markup into your post once — meaning your pages can be fully static!
Add these thoughts to the rise of static blogging platforms such as the aforementioned Jekyll, and I had a kernel of an idea: take the work I'd done already, and create a static blog generator.
View Layers, Database Abstraction, Configuration, Oh, My!
Late last week, the Zend Framework community released 2.0.0beta3, the latest iteration of the v2 framework. What have we been busy doing the last couple months? In a nutshell, getting dirty with view layers, database abstraction, and configuration.
ZF2 Modules You Can Use Today
One key new architectural feature of Zend Framework 2 is its new module infrastructure. The basic idea behind modules is to allow developers to both create and consume re-usable application functionality — anything from packaging common assets such as CSS and JavaScript to providing MVC application classes.
Call A Spade A Spade
I don't often get political on my blog, or over social media. But those of you who follow me on twitter lately have been treated to a number of tweets and retweets from me about some bills before the US legislative bodies called "SOPA" and "PIPA". Over the last couple days, I realized exactly why I disagree with them, and felt 140 characters is not enough.
Why Conventions Matter
When I started teaching myself scripting languages, I started with Perl. One Perl motto is "TMTOWTDI" — "There's More Than One Way To Do It," and pronounced "tim-toady." The idea is that there's likely multiple ways to accomplish the very same thing, and the culture of the language encourages finding novel ways to do things.
I've seen this principle used everywhere and in just about every programming situation possible, applied to logical operations, naming conventions, formatting, and even project structure. Everyone has an opinion on these topics, and given free rein to implement as they see fit, it's rare that two developers will come up with the same conventions.
TMTOWTDI is an incredibly freeing and egalitarian principle.
Over the years, however, my love for TMTOWTDI has diminished some. Freeing as it is, is also a driving force behind having coding standards and conventions — because when everyone does it their own way, projects become quickly hard to maintain. Each person finds themselves reformatting code to their own standards, simply so they can read it and follow its flow.
Additionally, TMTOWTDI can actually be a foe of simple, elegant solutions.
Why do I claim this?
On Error Handling and Closures
The error suppression operator in PHP (@
) is often seen as a necessary evil.
Many, many low-level function will return a value indicating an error, but also
raise an E_NOTICE
or E_WARNING
— things you might be able to recover from,
or conditions where you may want to raise an exception.
So, at times, you find yourself writing code like this:
if (false === ($fh = @fopen($filename, 'r'))) {
throw new RuntimeException(sprintf(
'Could not open file "%s" to read', $filename
));
}
Seems straight-forward enough, right? But it's wrong on so many levels.