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”]
hip hip array!
(more…)
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 Object.defineProperty 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:
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)
Object.defineProperty provides a handy way to add properties to JavaScript objects. It’s been around for a while, but with the introduction of class syntax in ES6, it’s not immediately obvious how to use it to add properties to a class, as opposed to an instantiated object.
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 [UINavigationController pushViewController:detailController animated:YES]) by sliding the detail view in from the right, and the root view out to the left. Navigating back to the root view ([UINavigationController popViewControllerAnimated:YES]) 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?
