When designing a database for your Ruby on Rails application, what looks like the best solution can be a trap. Join us as we expose these database anti-patterns. We’ll model shoes at a fictional shoe store and show both a naive design and more flexible alternatives. We’ll discuss how to represent trees, and see that the simplest solution is the slowest and hardest to query. We’ll explore scenarios where a polymorphic relationship looks like a good choice, but isn’t (and one where it is). Learn these pitfalls before falling into them, and save yourself from sloppy querying and poor performance.
]]>With complexity comes errors, and unexpected errors lead to unexpected unhappiness. Join us and learn how to add contextual data to errors, design error hierarchies, take charge of control flow, create re-usable error handlers, and integrate with error reporting solutions. We’ll talk about recoverable versus irrecoverable errors and discuss how and how not to use exceptions. From internationalization to background jobs, we’ll cover the gamut. Regardless of your Rail proficiency, you’ll learn why expecting the unexpected makes for happier developers, happier businesses and happier users.
]]>They bridge your application and your database. They’re object-relational mappers, and no two are alike. Join us as we compare ActiveRecord from Rails with Ecto from Phoenix, a web framework for Elixir. Comparing the same app implemented in both, we’ll see why even with two different web frameworks in two different programming languages, it’s the differing ORM designs that most affect the result. This tale of compromises and tradeoffs, where no abstraction is perfect, will teach you how to pick the right ORM for your next project, and how to make the best of the one you already use.
]]>]]>
If you haven’t tried Elm, you’re missing out. It’s a purely functional reactive programing language that compiles to JavaScript for front end web development. There are 4 hours of video from on livecoding.tv split into 4 parts:
Part 1a
Part 2b
Part 2
Part 3
The finished program is on GitHub. The master branch is the completed program with a computer player AI using the minimax algorithm. branches part-1 and part-2 contain the code I wrote during the livecoding sessions
]]>
Carefully Composing Logic: Functional JavaScript from JSLA on Vimeo.
]]>Turning the Tables: How to Get Along with your Object-Relational Mapper
]]>Improving your Web App with Functional Object-Oriented Design
]]>So what did I learn?
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.
]]>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
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.
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.
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.
Jasmine is stellar
This book is out of date now
Skip it and read docs
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?