With the release of the iPhone SE and the iPad Pro, along with the expectation that iPad apps will include support for slide over and split screen mode it’s now clear that Auto Layout is here to stay. If you’re not already developing apps using Auto Layout and Size Classes now is a great time to learn more about them and prepare yourself for any updates to the APIs that Apple introduces at WWDC in June.
Fortunately there’s a lot of great resources to quickly get up to speed and learn the best way to support a variety of devices and size classes in your next app.
So I’m building these web apps in my spare time (because that’s what I do), and I’m adding RSS feeds for certain types of updates, et cetera. But when I think of my immediate friends & family, I don’t picture them using RSS. Not everyone can be so serious about computers, I guess.
So, on a whim, I type into Google something like “Who uses RSS?” But all the articles start with something more like “Who uses RSS any more?”
As if it were a fad.
Game of Life showing a 1280×1280 world.
Long ago I gave some off the cuff, first impressions about Swift. Since then there have been several upgrades to the language, but I have only recently found myself trying it out. Specifically, I decided I had the time and inclination to implement Conway’s Game of Life. I wanted to try Swift on as a language, see how hard it makes me work to get to the bytes, and see how efficient I could make my code. Life’s matrix of cells provides a good substitute for the kind of byte by byte programming I often need to do and gave easy measurement opportunities by timing the updates of the life matrix, AKA ticks. What did I learn?
You’ve built the web application of the century, and the users have rightly flooded to it. Cat pictures for everyone!
But alas, while your users indulge in cat-induced bliss, the cold hard reality of server costs cannot help but harsh your mellow. What is to be done?
Maybe, you could get the users to… pay for access to your incredible web application in all its multivarious splendour?
Braintree is a payment processor (now a subsidiary of PayPal), which boasts of a “simple, robust way to accept payments”, and with features like a drop-in payment ui and libraries for various programming languages enabling fairly easy integration, is a solid choice for accepting payments via credit card or PayPal.
While Braintree’s developer documentation is blessedly detailed, it’s possessed of a potentially confusing bevy of options, and its various implementation examples are spread out amongst a number of pages and platforms. So today, rather than reiterate any particular section of the docs, we’re going to take a look at an end-to-end example of a specific, straightforward scenario – accepting and processing a one-time, immediately settled payment in a web application.
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:
- 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.
Disclaimer: There are no rules, only guidelines. Every project and situation has its own unique needs.
Actually, that’s exactly what this article is about.
* * *
Why do we always talk about unit tests? Why is “unit tests” automatically added to the plan of any or all projects? I think it’s just because it’s an expression we’ve gotten used to hearing. There are an awful lot of “xUnit” packages nowadays.
But what is a unit test, anyway?