A video of my talk at the Santa Barbara Ruby on Rails Meetup, where I demonstrate a novel class design I use for huge Ruby on Rails applications

Here’s my talk from the JS.LA meetup on August 27th. This is easily my best performance ever. Enjoy!

Carefully Composing Logic: Functional JavaScript from JSLA on Vimeo.

ORMs can be tricky to work with. They give us conveniece, but with significant trade-offs. I’ve published a post a medium on how to improve your relationship with yours.

Turning the Tables: How to Get Along with your Object-Relational Mapper

I’ve cooked up a little post about barbecue, beer and object-oriented design just in time for labor day. This one has been incubating for a while and is the subject of a talk I’ve been giving that hopfully should make it online soon. I’ve published it on Medium, Enjoy!

Improving your Web App with Functional Object-Oriented Design

Here’s a short video about me and two of our Upside team members who were placed through LaunchCode, a non-profit that places aspiring developers in their first jobs. I’m so proud of these 2 young men and what we’ve accomplished together.

Video podcast on Functional Ruby for CodeCast by STLTechTalk. Big thank you to JJ, Kevin and Gus. Sorry I cursed so much :)

InfoQ has published a video of my presentation on JavaScript TDD with Jasmine from the 2014 Kansas City Developer Conference.

Watch on InfoQ >>

On July 2nd I did this video podcast for St. Louis Tech Talk. The subject is mostly Ruby on Rails with some personal history and a discussion of Launch Code mixed in. There’s no Ember talk despite what the title says, but don’t worry, that will come later. Enjoy!

In case you’ve been asleep, functional programming is the new standard in modern programming language and application design. To those of us who have been using languages with functional features, such as Ruby, C# and JavaScript, it doesn’t seem at first glance like a major paradigm shift. This is especially true since functional design is not mutually exclusive to object-oriented design (in fact as the Scala language proves, they complement each other quite nicely). However when you apply functional principles universally using a functional language, it becomes clear that FP is a significant step forward from the Java-style object-heavy approach that it is slowly replacing.
I signed up for Functional Programming Principles in Scala on Coursera to experience for myself the new secret sauce having heard that the course is outstanding. I’m happy to say that it was outstanding beyond my expectations. It’s a perfectly designed introduction and easily the most rewarding online class I’ve ever taken.
Perhaps it shouldn’t be a surprise that the course is so good. It’s taught by Scala’s creator, Martin Odersky. What is surprising is that throughout the course, he talks very little about functional programming principles at a high level. Instead he teaches by example starting with simple recursive algorithm problems and ending with a really clever algorithmic game solver. In between we solved some classic computer science problems – problems I had solved before in school – using pure FP in a way that highlights where the functional solutions improve on the older procedural solutions. It’s in the progression of increasingly more involved assignments – which stepwise introduce language features and concepts – that the class succeeds so cleverly. One is never instructed to use pure functional programming, but rather arrives there naturally as one technique begets the next and the assignments grow in complexity. If you’re autodidactic like me, and generally wary of formal education, you’ll appreciate Professor Odersky’s subtle approach.

So what did I learn?

• Recursion combined with immutable linked lists is the best way to do list operations
• Pattern matching is the hottest language feature since lambdas. They’re super-charged conditionals
• Lazy sequences and lazy evaluation are a breeze when they’re built into the language
• Often when I’m using a list, I should be using a set
• Tuples do serve a purpose when your language is strongly typed
• You can have strong typing without excessive boilerplate
• Tail call optimization makes a language more powerful (I’m looking at you, Ruby)
• Accessing instance variables from within methods is safe if they’re immutable
• Encapsulation with higher-order functions is cleaner than delegation
• Side-effect free code weakens the case for test doubles

Whether you have or have not been exposed to functional programming, this is a great course. If you’ve ever studied recursive algorithms and enjoyed it, this course will rekindle your excitement by giving you new more powerful ways to solve old problems. Be prepared to fall in love with the Scala language: it fixes most of what’s wrong with Java and augments it with new capabilities that lead to simply better code. While it is not addressed in this course, I’m looking forward to seeing how functional programming improves concurrent operations in distributed environments. Fortunately that’s the subject of Dr. Odersky’s next class which you can bet I’ll be taking.

TL;DR: Start with The Good Parts, then read JavaScript Patterns if you’re hungry for more. Read Functional JavaScript when you’re ready to have your mind blown and learn a new way to program. Testable JavaScript and JavaScript Testing with Jasmine can be skipped provided you know it’s a great idea to use event hubs and write unit tests.

18 years after I wrote my first line of JavaScript (Netscape 2.0 for Macintosh was released in March of 1996), I decided it was time to catch up on the latest best practices and fill in the gaps of my dated understanding of JavaScript. I guess I’m late to the JavaScript renaissance, but it only took 5 books to bring me up to speed. The result? A very slick open source micro-framework called Ranger (http://www.github.com/bradurani/ranger) that I’ll blog about as soon as I’ve documented it. Here’s how I got there

Review: JavaScript the Good Parts – Douglas Crockford

The best programming books are the ones that show you examples of what NOT to do. This is just such a book. In fact, it could just as easily be called “JavaScript the Bad Parts”, but I suppose it wouldn’t sell as well. It’s a classic, and it’s the first book you should read when you’re ready to admit that loose collections of barely organized jQuery do not an application organize.
It’s opinionated – to a fault in fact. And while it’s heavy on language mechanics with nary a hint on how to put them into practice, that’s no excuse for skipping it. It’s barely 100 pages, and it sets the stage for everything that comes after it. JavaScript is a quirky language and its proclivities are easy to forget. You have to read about them several times and experiment if you’re going to remember them. Crockford’s book is the perfect first exposure, plus you can name drop him during any job interview and get instant brownie points.
Read it, digest it, read it again. Try out his linter, JSLint, then ditch it for the less opinionated JSHint. Only when you’re fully steeped in the bad parts, should you move on to something more imminently practical. It’s also worth checking out his video on the subject here, but watching it doesn’t excuse you from reading the book.

Review: Testable JavaScript – Mark Ethan Trostler

I had high hopes for this book but most of it wasn’t useful to me. the first few chapters, however, were worth the price of admission. Chapter 1 is the perfect exposition and eminently quotable :
“Your ideas are unique, your code is not”
“Testable JavaScript is your gateway to sanity”
“Unit tests are a developer’s first line of defense”
But it’s chapter 2 where the value of this books lies. Here we study command / query separation, function decomposition, and scoping for testability. There are great discussions of cyclomatic complexity, fan in and fan out, and a complete Linnean breakdown of the genera of coupling. Most impressive indeed, especially since we also get a full dose of dependency injection (one of my favorite subjects) and a comprehensive look at documentation tools.
Chapter 3 makes a convincing case for event-based architecture. So convincing, in fact, that I now use event-based architectures for everything I build with JavaScript (and I’m not talking about click events and other jQuery gimmies, I was already using those). The event hub example (the most important pattern in JavaScript architecture?), is a server-side example for node.js, but the point is still made, even if you only write JS for browsers.
Chapter 4 mixes great advice about unit-testing, with annoying examples using the YUI framework, which I don’t use (Jasmine is better). It has a great breakdown of mocks, stubs and spies, then veers off into tools such as PhantomJS (a headless browser) and Selenium (a functional testing tool). Pick and choose here, there are useful bits between the tool focused parts.
The rest of the book was useful, or maybe useless. I’m not sure, I didn’t read it. It’s about tools for code coverage and load testing and automation and things only NodeJS developers care about. Read it if you want, but it’s probably already out-of-date. The first 3.5 chapters are very good though.

Review: JavaScript Patterns – Stoyan Stefanov

This book picks up where “The Good Parts” leaves off. Actually, it starts by repeating everything from “The Good Parts”, which is great, because you forgot those things, and need to see them again. What comes after is what’s really useful: page after of page of practical, usable design patterns that you can use in your own applications. You get 5 versions of inheritance, a panoply of object construction variations, and an almost complete rehash of the Gang of Four classics. Best though, are the module, namespace and sandbox patterns, which have spawned many micro-frameworks.
This is solid, usable stuff. Even if you don’t write your own framework (this book gives you the pieces), these lessons help you identify patterns you see in the wild, and the first step to becoming an application architect is identifying patterns by name. If you don’t have time to read the whole book (shame on you), there’s a nice blog post here that summerizes many of the more useful patterns.

Review: JavaScript Testing with Jasmine – Evan Hahn

Jasmine is stellar
This book is out of date now
Skip it and read docs

Review: Functional JavaScript – Michael Fogus

Ok LISPers, Scala Jockeys and Clojurites, you’ve got the jump on me here. I mean I know about lambdas, map, reduce and filter, but those are tools for writing concise functions, not architectures for entire applications… or so I thought. Let me back up. I’ve known about functional programming for many years, and being a former C# dev, I know that lambdas are a way of life. However I never knew exactly how to translate those concepts to architectural patterns. I’d been prosthelytizing the trees but missing the forest.
Functional programming is about composing functions to create pipelines for data transformation, and if you haven’t read a book like this, or practiced it yourself, it’s not easily intuited. It’s functions instead of loops, functions instead of ifs, functions returning functions and taking functions as arguments. It’s not just about pulling punchy one-liners like you Rubyists gloat about. Functional programming is a lifestyle, a higher-order of being where everything’s a function and inheritance only marginally useful.
That JavaScript is functional at all is a small miracle. It happened sometime between 2:00 am and 4:00 am in February of 1996 – when Brendan Eich was blessed with an ephiphany, imparted by angels like an annunciation on a gothic triptych: functions should be first class objects. He took the road less-traveled – a sharp turn off the highway towards Java-like languages that the world was hell-bent on following at the time. JavaScript was not a complete failure, having inherited just enough LISP to make it really useful.
The build up is slow. Ravel’s Bolero, but it’s not a sex scene. We hear readable, reusable code composed of tiny simple functions – short sharp drum beats that build to form a symphony. It’s complexity simplified to the simplest it can be, and not a drop simpler.
And what’s this I finally understand? Monads! They’re not burritos, nor train cars, nor spacesuits nor any other obfuscating metaphor. They’re abstractions used to augment primitives with additional processing rules as they travel through data transformation pipelines. “You had the power all along, my dear”, said the good witch to Dorothy, “and you realized it on page 185”.
There is life after inheritance. There’s more than OO. Now pass me that function and I’ll give you one back. Recurse until you catch the final burrito, the final train car, the final space suit. Peal back the foil and behold the result. The new JavaScript is functional. Now where do I learn more about Scala?