We’ve been using Redux a lot lately at Atomic, and we’ve come to appreciate how a centralized holder of application state can simplify application architecture. In a few different projects, we’ve used this architecture as inspiration for mobile applications in Objective C, Java (for Android), and Swift.
React apps with Redux are built around an immutable state model. Your entire application state is one immutable data structure stored in a single variable. Changes in your application are not made by mutating fields on model objects or controllers, but by deriving new versions of your application state when you make a single change to the previous version.
Atomic Object works with all sorts of companies, from technical startups to established traditional businesses to Fortune 500 companies. We engage each company differently, trying to structure the engagement to best meet the needs of the client.
Startups, in particular, have a number of cost/benefit questions to consider before engaging a consultancy like ours. Depending on the situation, working with a consultancy can be a smart move or a bad fit. Read more on When Should a Startup Hire a Software Consultant?…
Building custom software is costly, complicated, and sometimes emotional. A well-executed project must hew to a fine line to navigate many constraints successfully, threading the needle between cost, timing, purpose, user needs, technical constraints, maintainability, extensibility, and operational considerations.
An idea for a product is just the beginning. To find success, you need a broad view of what’s important, the willingness to proactively go above and beyond, and careful planning. We call this collection of attributes “owning it”—personally investing ourselves in the success of our projects and seeing them through to success. Read more on “Owning It” Every Step of the Way…
Every step along the path to delivering a software project is a trade-off. Time and/or money are in short supply relative to the vision for a product, and every decision must be made with care. Moreover, there’s no one “correct” way to design or a build a feature—there are many possibilities, each with their own cost, time to implement, possibility for reuse, desirability, and maintenance burden.
Building software is an exercise in trade-offs. There is always an abundance of ideas and a shortage of money or time. Working to balance competing constraints is what I do. As a developer, I try to estimate and minimize implementation time without sacrificing quality. As a project lead, I help clients prioritize features to build the most complete product we can for a given budget. But these aren’t the only factors that we need to consider, and I’ve been struggling with what to do about another critical aspect — joy.
For my recent LambdaJam workshop on learning Clojure macros from first principles, I created a set of materials exploring the basic concepts. To really understand macros, you first need to have a good understanding of what makes them so powerful — homoiconicity. In this post, we’ll explore that property of the language.
Building great software means constantly tweaking and improving. We fit our product to the user’s need, we obsess over our own productivity, and we adopt agile processes to help our team deliver robust software. But what about the environment in which we work? Can we optimize that to draw out our best?
Ember.js has gotten a lot of attention recently for being confusing or hard to get started with. I’ll definitely admit that getting started with Ember took more than its fair share of code-reading, as the guides and documentation didn’t provide enough detail for building real-world apps, but for the most part, I’ve been amazed at how easy it is to build sophisticated applications with Ember. This post explores one critical feature of Ember that enables this: pervasive data binding.
UI-based applications involve a lot of state, and most of an implementation involves responding to and propagating changes to that state. Desktop applications are structured as trees of components, each with their own individual state, and each of which emits events in response to user interactions. Classic web apps build a snapshot of the current state as an HTML page, then wait for HTTP requests to change the state or request an updated or alternate view. Whether you’re building an MVC/MVP desktop application or server- or client-side web application, most of the programming chores in modern frameworks deal with propagating change and translating between layers of abstraction in state.
Ember provides the most complete and general solution to this problem of any system I’ve used. Ember supports data binding at the object level, taking care of change propagation for you.