Modeling large, complex domains "the Rails way” can cause some serious pain. Ruby and Rails are supposed to make developers happy. Let's not allow “the Rails way” and complex domains to take the “happy" out of ruby development.
Repetition often creeps into our views, and having a way to simplify them makes them easier to update. Enter Domain Specific Languages (DSL's); using a specific set of context-aware methods allows us to focus on the specifics of our domain. This becomes critical if our domain becomes large or complex. Even when this happens, we try to avoid having too many fields on any particular model. Sometimes, however, the simplest solution is to allow models to grow. At the same time it is important that your code remain manageable. In order to prevent our model's views from becoming unreadably large we're only going to display fields that aren't blank. We'll have to manage formatting requirements for dates and such, so our system needs to be flexible enough that we can customize the output. You'll probably have to be working with this code again at some point, so let's see how much better we can do. Eliminate verbose cluttered code so that your views are easy to work with.
I recently wrote a blog post describing how to create your own RubyGem. The sample gem produced, aptly named dogeify, converts English sentences into "Doge" based upon the recently popular meme. For April Fools' Day, we thought it would be fun to implement this gem to convert our entire site into doge. Here's how we did it.
Building your first Ruby gem may seem like a daunting task, but it's actually not so bad. It's quite rewarding to not only release a gem, but to see its download count climb as others put your hard work to good use, and even still as others offer to contribute new features and bug fixes to your very own gem. And thanks to RubyGems.org and Bundler, the process of creating, releasing, and implementing gems couldn't be easier.
After reading through this post, get access to the 45 minute video tutorial complete with slide deck and instruction from Matt in our new Engineering Lunch series. Be a QLer for the day and see what we're teaching our engineers in our semi-monthly engineering lunch series. Sorry, we don't buy the lunch but you do get the tutorial for free!
One of our clients needed their web application to interface with two external APIs. Neither API had a native ruby gem that we could pull into the web app project. We decided to write our own gems, one for each API. The web app and the APIs all target the same domain, but don't use the same domain language. The subtle challenge was to figure out how to interface with these APIs without adding confusion to the web app's domain language. I'll talk though our story on how we came to a clean solution.
Both of the external APIs were from the same organization, but created at different times by different teams, and consequently looked a lot different from each other. What's worse, both APIs are concerned with the same core concepts and entities, but the APIs called the entities different names.
And.... it still gets worse.
- ← Previous
- Next →