Writing Cleaner Velocity Code, Part 2: Pure Macros

This is the second post in a series on writing cleaner code in your WCMS Velocity formats.

In my previous post, I talked about how we can apply the PSR-1 Coding Standard’s recommendation on side effects to our Velocity code in an effort to make our Velocity formats easier to reason about.

In this post, I’m going to continue this train of thought, bringing in some lessons from pure functions.


Writing Cleaner Velocity Code, Part 1: Side Effects

This is the first post in a series on writing cleaner code in your WCMS Velocity formats.

Next month, I’ll be starting work on my 6th (!) Velocity-powered framework in the WCMS.

This new framework will be my largest and most widely-used since I started developing for the WCMS back in 2014. Because of this, I’ve been thinking a lot about how to write my Velocity formats in a way that will make the framework easy to maintain and extend in the future.

Unfortunately, neither Hannon Hill nor Apache have made code standards or style guides available (that I could find), and the Velocity language itself doesn’t do much to nudge you toward any kinds of best practices.

This sort of thing makes me super anxious, so I decided to fall back on my two favorite resources when it comes to code quality: Clean Code by Robert “Uncle Bob” Martin, and the PSR Standard by the PHP Framework Interop Group.

In this series on writing cleaner Velocity code, I’ll pull out some practices from both Clean Code and the PSR Standard and talk about how we can apply them to write WCMS frameworks that are less of a headache to manage.


[Video] Don’t Fear the Monad

Monads are a super-important concept in functional programming, and in languages like Haskell, they’re pretty much the only way you can do things like I/O.

Despite their role in functional programming, monads are a pain to explain and understand. Google “monad,” and you’ll see a ton of bloggers taking a crack at trying to break the concept down. For the most part, they haven’t been helpful to me.

Then, I came across the video above, and monads finally started to make sense to me! Not only did the video help me get a better handle on what monads are and why they’re crucial, it also shed some light on why functional programming is the way it is, and the decisions that went into designing things like Haskell, Clojure, and even .NET Linq!

I’m sharing it, in the hopes that it helps you as well.

Lambda Calculus for Absolute Dummies

Lambda calculus is the foundation of functional programming, which is why functional programming languages love to include a λ in their logos.

But what is lambda calculus, exactly? You could read the Wikipedia article on lambda calculus, but it’s pretty rugged and arcane — and I’ve linked to some pretty rugged and arcane Wikipedia articles on this blog.

Instead, I’m going to bounce you to the Palmström blog, which posted back in 2012 a great introduction to lambda calculus for non-math people.

This article was the one that made lambda calculus click for me, and helped me get a grip on why stuff like first-class functions and referential transparency are so important in functional programming from a math perspective.

Read ‘Lambda Calculus for Absolute Dummies’ →

Functional Naming Conventions in PHP: A Starting Point


One of the things I wasn’t terribly happy with in my recent screencast were the names of my functions. Though I try to write functional programs for the College whenever possible, I still write a lot of object-oriented code, and I struggle to translate the naming conventions.

I realized it doesn’t really make sense to use the naming conventions of object-oriented code in functional programs, so I took a look around to see how functions are named in Clojure.

I found a blog post from earlier this year by Stuart Sierra, where he laid out a basic style guide for Clojure function names. I like that his style guide is simple and helps reinforce good functional programming structure.

Let’s try to apply his style guide to PHP functions.


[Video] Learning Functional Programming with Javascript

If you’re reading this blog, my hope is that you’re excited about functional programming and want to keep learning more about it. Functional programming can be a tough thing to wrap your head around, though — even for experienced coders — and you might be feeling wobbly about some of the concepts.

You’re not alone! At this summer’s JSUnconf, Anjana Vakil gave a great talk about her journey into functional programming and what she’s learned 6 months in. Check it!

[Screencast] Functional Transformation

A few weeks ago, I was asked to write a script that would read a list of CAS users from a web service and generate an .htaccess file restricting a directory to just those users.

I thought the script was a great example of using the functional transformation approach to programming, so here we are!


Functional Programming on MSDN

The Microsoft Developer Network (MSDN) has a great series of
articles contrasting object-oriented (imperative) programming with functional programming
, and tips for transitioning to the latter:

“This topic introduces the concepts and terminology of pure functional transformations. The functional transformation approach to transforming data yields code that is often quicker to program, more expressive, and easier to debug and maintain than more traditional, imperative programming.”

If you’ve been struggling to wrap you head around some of the functional programming concepts I’ve talked about so far, these articles might help!