A great talk by Carin Meier given a few weeks ago at Clojure/conj about how Clojure and functional programming are ideal tools for machine learning:
Of all the new features in the latest version of Cascade Server, I’m most excited about the REST API. I’m a heavy user of the current Web Services API, but as a SOAP service it’s a hassle to use and doesn’t play nice with languages like Clojure.
The REST API can leak your username and password
I wanted to call out one thing I saw in the documentation, however — the Cascade Server REST API allows the client to pass their username and password in the URL. The documentation also implies that this is the “default” approach.
Passing credentials in the URL query string has long been understood to be poor security practice, and is called out by OWASP in both their vulnerabilities wiki and in their proposed list of 2017’s top web vulnerabilities.
I came across a video early this morning by Rikki Poynter, a YouTube vlogger who posts about accessibility, deafness, and deaf culture.
I know the video is a few months old, but I really liked it and wanted to share, particularly as discussions about web accessibility ramp up in the College and beyond.
This is the third post in a series on writing cleaner code in your WCMS Velocity formats.
Like templates in XSLT, macros are a useful and idiomatic way to help separate the parts of our Velocity code so that we can better read and re-use them.
There’s an important difference between XSLT templates and Velocity macros, though: while XSLT templates only accept simple scalar values via the
<xsl:with-param> element (unless you want to load up EXSLT), Velocity macros readily accept complex types as parameters, such as nodes or a
Because Velocity macros can accept complex types as parameters, they’re a little more flexible than their XSLT counterparts and in some cases allow us to write fewer formats. However, this power comes at a cost and should be used with care.
Rich Hickey, author of the Clojure language, gives what’s probably my all-time favorite keynote programming lecture.
Yes, I have watched enough keynote programming lectures to have a favorite.
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.
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.
Back in September, I wrote a post outlining some naming conventions for functional programs written in PHP.
Having written some more functional programs in PHP since then, I wanted to add 2 more tips to the original list.
I haven’t forgotten about this blog – between holiday break, a team retreat, and our office moving into a new space, I’ve been pretty distracted.
I promise I’ll be back with more posts soon. In the meantime, here’s a great new talk on software development by Rich Hickey, the author of Clojure.
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.