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)…
I recently found myself starting a project where, for a variety of reasons, it made a lot of sense to use Ember.js to build our interface while using Clojure to power our API. Read more on Setting up a Project with Ember and Clojure…
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…
After searching for a way to display breadcrumbs with Ember, I was left disappointed with what I found.
I wanted something that would:
- Be isolated, so I didn’t have to clutter up my
ApplicationRouteor commit other such crimes.
- Be flexible in how the breadcrumbs are named (e.g., I want to include some data from my models).
- Be flexible in which routes actually display breadcrumbs.
- Be flexible in which route a breadcrumb will link to (since it may not always be the same route).
- Automatically update whenever the route changes, regardless of which template the breadcrumbs are placed in.
So, I wrote my own. Read more on Breadcrumbs in Ember.js…
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
This looked like the perfect use case for an Ember Component. I wouldn’t even need to have the component trigger any actions, because anything using it could simply observe changes to the current page property! Let’s take a look at how I solved this. Read more on Creating a Pagination Component with Ember.js and Foundation…
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 take a look at why. Read more on Why I’m Finally Excited about Web App Development…
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.
Recently, while working on an Ember.js app, I found that I wanted to create a reusable component that manages the editable state of content within it. That is, it would start out by displaying information (initializing its isEditing binding to false), and provide an “Edit” button that would set isEditing to true, so the content wrapped in the component could display its editing interface.
Naturally, I then wanted a way to “subclass” my EditableComponent so that I could create (for example) an AddressComponent that would display a mailing address read-only but allow you to edit it. What I struggled with was finding the best way to pull this off.
I had a few different ideas, two of which didn’t work. Read more on “Subclassing” Ember Components…