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.
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.
When you’re looking for a home for your career, one really important consideration is who you’ll be working with. What’s the culture like? What kind of people will you spend your time with?
I’ve worked at Atomic Object for a few years now — long enough to have observed and identified some characteristics that most, if not all, of the other Atoms have in common. In no particular order: Read more on Profile of an Atom…
I’m currently working on an Ember.js app that requires the color scheme to be customizable to match the branding of our client’s clients. Since our application’s CSS is being compiled by the Rails Asset Pipeline, and the colors would be fetched over an API call, this posed an interesting challenge.
Originally, there were many unknowns around how we would accomplish this. How would we recompile our SCSS? Would we wrap the Ember app under a Rails route that would insert customized CSS on the page? If we loaded the CSS via Ember, how would we insert it on the DOM?
Happily, the details all fell into place quite nicely. Here’s how we pulled it off:
1. Use the Application Route to Load the Custom Theme
Or use any other resource’s route. When loading the model for the route, we first make an API call to determine which colors to use, and then pull out the theme information and make a request to the Rails app that processes and returns the themed CSS as text. Then we create a model out of the two.
Until recently, my current project had maintained two distinct git repositories, one for each of the major components of the project. For a few reasons, we decided that it would be best to merge them into a single git repository.
Ideally, we wanted to do so in such a way that would preserve the full commit history of each of the two repositories. Fortunately it’s quite easy to accomplish this using a regular git merge.
Step 1: Preparing the Repositories
You probably don’t want to have the two repositories end up clobbering each other. For our project, we had separate repositories for the backend API and the frontend application. I simply made one commit for each repository that moved all the files into a subdirectory. I.e., all the files in the API repository were moved into the api/ subfolder, and all files in the frontend repository were moved into frontend/Read more on Merging git Repositories Together…