Clojure inherits some interesting tradeoffs as a result of being built atop the Java Virtual Machine. One upside is the availability of many full-featured and mature Java libraries. But one downside is the need to survey the historical as well as technical landscape of your available choices.
I’ve been working on a project with a diverse set of software components that must all work together and communicate over the network. There are separate Mac and Windows clients that must communicate with the same unix server. And while there’s already a well-defined protocol for their network communication and message passing, we also need to transmit a large stream of somewhat time-sensitive data. Read more on Multiplatform C (with Networking)…
The other day, while having a conversation in the office about Clojure macros, I was reminded that not everyone fully understands the phrase “code as data” or its useful repercussions. This isn’t surprising, as there are still very few mainstream languages that feature this, and most of the ones that do are lisp dialects. I think that’s unfortunate, as it’s a conceptually simple tool that you can get a lot of leverage out of. Read more on Understanding Macros and Code as Data…
Ember Data is ambitious and does a lot of heavy lifting for you, which requires that it makes some big assumptions. It assumes you need an identity map, object relationship management, dirty state tracking, and that your interaction with your server is primarily or entirely CRUD operations.
I recently worked on a project where these assumptions didn’t fit, and I was in a tough spot. While Ember Data has a handful of alternatives, they all share these assumptions. I had to choose: I could use Ember Data and fight it along the way, or I could roll without it at the cost of spending time implementing or copying functionality that Ember Data provides for free. Read more on Flexure: A Lightweight Model Framework for Ember.js…
Ember is an opinionated framework. Like other such frameworks, it takes a while to learn how the pieces are designed to fit together and how you can structure your code to be harmonious with it, rather than fight it.
What I’ve found is that often, it helps to think outside the boxes ember provides you: controllers, routes, components, etc. Ember’s dependency injection is a great tool for helping you with this.
Objects are named in Ember’s dependency injection container are given a full name that consists of two parts: the type of object, and a name. For example, route:application would be the name for your ApplicationRoute. Or controller:question.edit for your QuestionEditController. You’re not limited to Ember’s predefined categories, however; you are free to make up your own type. Read more on Learning to Love Ember’s Dependency Injection…
For my current Ember.js project, I found myself needing some pagination controls. Thankfully,Zurb Foundation provides me some markup and CSS to base my pagination controls on, so I was free to focus more on the functionality. Essentially, all I needed was a little widget with three properties:
current page number
total number of pages
optionally, the maximum number of pages to display before the list is truncated
I’ve never enjoyed writing web apps. For a variety of reasons, the experience of web development (and even the end-user experience) has always felt frustrating and wrong. Thankfully, the world of web development hasn’t been standing still. Web standards continuously improve and gain adoption, while truly great frameworks have come into existence. What I’ve been realizing lately is that I no longer loathe working on a web application – I’m actually rather excited to.
Let’s look at a hypothetical situation. You have a medical issue requiring surgery. While there are many surgeons that could get the job done, each one has their own level of ability and skill. Through their choices, the surgeon will affect overall “quality” of the operation — which procedure is used, cosmetic results, general odds of success, and how any unforeseen complications will be dealt with. The surgeon won’t have a complete picture of the situation until the operation is underway, and even then surprises are possible, so overall skill is essential.
If faced with this choice, how do you determine which surgeon to hire? It’s not easy when risks are (potentially) high and your technical understanding of the field is low. Your choice could have a potentially dramatic effect on the outcome, and there’s no going back.
I imagine that this is very similar to how it feels to be tasked with selecting a firm to develop custom software for your business.