Software is a serious business. Fatal bugs have been around since at least the 1980s, and a decade-old report estimated the annual cost of bugs at $60 billion. Tech companies spend millions on political lobbying. Opponents argue over labor shortages and H-1B visas.
So how about we take some time out to give three cheers for a little levity?
hip hip array!
Gathering requirements for software development projects has always been a difficult process, and has veered through various methodologies like waterfall and agile. Regardless of the methodology, though, there are certain pitfalls to deciding and describing just what an application should do that can result in projects stumbling or failing. Requirements fractalization, focus on little used details, or lack of developer and stakeholder involvement can all actively harm the best architecture.
My previous post demonstrated the use of
to programmatically add a list of properties to an ES6 class, such as a Backbone.Model subclass, reducing the amount of boilerplate code necessary. The example in that post added simple getters and setters, but it’s possible to go further for Backbone.Model properties, also configuring in a single data structure functionality like:
- Options for properties, such as disabled setters
- Default values for properties
- Mappings for parsing date strings and model relationships
This technique uses a common base class from which all other model classes descend. The model subclasses (e.g. a user model) provide a list of property definitions, which centralize various aspects of those properties. The base class has configuration methods which iterate over the property definition objects.
In the particular examples below, the base configuration methods handle attribute to property name mapping, default values, and server data parsing, but this technique can be applied to other configurable property-related tasks, such as marking some properties blacklisted or viewable only by admins.
(Photo by William Warby)
Porting an iOS app to Android means frequently translating between the divergent UI paradigms of the two operating systems. Both platforms encourage developers to follow certain interface guidelines, but clients sometimes prefer replicating a familiar interface. Thankfully, Android offers fairly deep customization.
For one port, the Android app needed to use the same view transition animation as its iOS counterpart.
On iOS, the standard navigation stack defaults to animating a detail page transition (called by
) by sliding the detail view in from the right, and the root view out to the left. Navigating back to the root view (
) reverses the animation, sliding the detail view out to the right and the root view in from the left.
On Android, the same transition (handled through a FragmentTransaction) defaults to a zoom animation, or sometimes a slide up animation. How can Android mimic iOS’ transition animation? (more…)