Ember’s actions are a powerful and usually straight-forward mechanism for handling events within an application. However, some cases can be a bit perplexing unless you’ve dealt with them before and wrestled with the details. Here are a few brief points and examples to help clarify Ember’s action bubbling behavior in a few of those less obvious cases.
If you spend much time around the offices at Atomic, you’ll eventually hear someone mention the phrase “zooming out” in relation to solving a problem. I’m not 100% certain on the origin of our use of the phrase (we may have picked it up from one of our friends at IDEO or Cooper), but I’ve used it frequently over the past two years. And the more I use it, the broader my definition becomes. It’s just so darn useful. Read more on Zooming Out…
Technical and design skills are critical to the work we do building software. But it takes much more than technical and design excellence to bring a complex project to fruition and run a successful consultancy. Read more on Growing Developers and Designers into Leaders…
We discuss scale, risk, and different options with our customers and team members continually throughout the lifetime of a project. Having a visual representation of the conversation points can be very useful.
A well-designed visual makes it easy to identify the highs and lows, draws conversation to the most important points, and helps everyone navigate the problem landscape. It’s hard to replace the way a good visual can connect with visual learners. And, as an added benefit for me, it removes the temptation to just read a slide during a presentation.
A few quick tips before we dig in:
- Color matters. I like to browse the palettes on COLOURlovers for inspiration.
- Double-check your numbers. It sucks to realize your visual is wrong in the middle of a presentation.
- It’s nice if the visual is easy to update to reflect new information. Simple shapes and a straight-forward scale help that a lot.
Below are a few examples we’ve used recently. Read more on Visualizing Project Scale, Risk, and Options…
Carl likes to talk about the worry gene culture at Atomic — our predisposition to turn worries into concrete, positive action. The converse of this behavior, inaction, can quickly lead to unresolved worries piling up. That’s where stress comes in. And despite our predisposition to positive action, we all sometimes need a kickstart in the right direction.
Fortunately, many of our practices at AO already serve to guide us toward the concrete, positive actions we need. And there are other simple things I’ve found that help effectively spur the worry gene into action. Read more on Worry; Don’t Stress…
Vim is a good friend of mine. When we met during my freshman year of college at MTU, we quickly hit it off. I never looked back with any regret at my tiny TI-85 screen, Notepad, or QBasic where I first tinkered with bending computing devices to my whims. Since then I have tried other editors, and even used a few for extended periods for a variety of reasons (e.g., Kate because of its SSHFS and KDE tie-ins, Visual Studio for its strength with all things Microsoft). Still, through it all, Vim has been my go-to editor for nearly 15 years.
I have been using Atom almost exclusively for the past month — without vim-mode. This was an intentional decision on my part. I didn’t have any complaints about how Vim had been working for me prior to picking up Atom. It, along with our built-to-Atomic-tastes configuration, did great navigating the mixed mobile & web project environment I was working in. I was just feeling ready to try something different when Atom came on the scene — something that wasn’t vim and didn’t work like vim. Plus, I dig the name and logo. ;) I figured, at the worst, I’d return to Vim after a while with a renewed appreciation for everything that makes it, well, Vim.
So, how has it gone? Read more on A Month with the Atom Editor…
Burn charts have been a staple of Atomic-run projects for quite a while. They’ve also been the subject of much discussion both internally at Atomic and at-large in the Agile development community. The basic concepts are simple, and we’ve found them useful — especially when they are allowed to evolve as we learn how to better engage our customers and teams. I’m going to tell a story of one such evolution.
First, if you’re unfamiliar with a basic burn chart, check out Mike Marsiglia’s previous post about Atomic burn charts. Got that down? Great!
I’m going to follow the story of a ficticious company, Acme, Inc., working on a custom order management system. Our burn chart experience started simply, as Mike’s example illustrates: one big scope bucket (represented by the blue line), and a team of three working to realize the features represented in our backlog (represented by the green line).
Carl Erickson wrote back in 2009 about his practice of distributing “nice words” from clients to the company at large. It is a practice that continues, and something that I personally love about working at Atomic. It lifts my spirits and makes me proud to be a part of such a highly-praised group. I know I’m not alone in my appreciation for this practice.
Nice words mean so much to all of us in part because they result from hard work. To us, these words are like a flag flying triumphantly atop a newly-constructed castle. Weeks or months of time has often gone into erecting the solid, stone walls. Thoughtful, sometimes difficult, decisions have shaped it for its intended purpose. Throughout the process we’ve sweated the details, pursued knowledge and empathy, and as a team brought a vision to life.
These are words worth working for. Read more on Words Worth Working For…
Here at Atomic, we work to maintain our sustainable pace on a number of levels. I typically think of my pace on a weekly granularity because of our team’s iterations, invoicing cycles, and the intervening weekend breaks. There’s a rhythm in which I can feel the ebb and flow of my energy level resulting from the week’s efforts and accomplishments.
Atomic encourages employees to take a consecutive week of vacation at some point during the year, and I recently took 10 days off to travel with my wife and disconnect. Having the opportunity to disrupt the rhythm, to disconnect and re-energize, is important. But it isn’t always easy, especially for people who are deeply engaged with and care about their work (as we do here at AO). Here are a few things that can help make it work. Read more on Ready to Disconnect on Vacation? 6 To-Dos Before Leaving the Office…
My current project involves an Ember.js web application and a JSON+HAL API, and we recently wanted to let administrative users upload an XML file, sourced from a different system, to make filling out a form easier. We didn’t want to upload the file to the API for processing on the server. Following is an example illustrating how we handled the file upload in our Ember.js app, and how we could make this work with a few other file formats.
1. The Upload
Let’s pretend we want to make it easy to upload a list of user information into the application. I’m going to illustrate a method using a file input element for the upload interface. There are other options, like drag & drop, but this met our users’ needs and was simple to implement.