I am proud to announce the new incarnation of my consulting business. After ten years running Chicken Wing Software, I decided it was time for a reboot. And so I am launching my new company, Seashore. I have begun migrating my blog posts to the new site.
Chicken Scratches: Developing ideas on developing.May 18th, 2018 by Eddie Sullivan
Mobile Backend as a Service
A client recently asked me about the available options for Mobile Backend as a Service offerings (mBaaS). Here are some quick thoughts. This is just an overview, but will give you a good place to start when deciding what to use.
Why to use a mBaaS
It’s not mandatory to use a commercial mBaaS, but there are some good reasons to consider it.
Running your own server is expensive and risky, even if it’s in the cloud. You have to:
- Make sure all updates are tested and installed quickly. Especially security updates which can happen any time, even if your DevOps engineer is on vacation or drunk.
- Be ready to scale. If your app gets featured in the App Store, your traffic could multiply by 100 overnight. It would be a good problem to have, but you have to be prepared.
- Be on the lookout for attacks.
- Make sure everything is backed up, measured, and logged.
All commercial backends will handle these things for you.
Easy to get started
With a traditional database backend, you define your database tables and rows on the backend first, then code your app to use that. When you want to make changes, you have to migrate the backend data to the new structures.
All the currently available backends use NoSQL databases. That means you don’t have to define a schema ahead of time, you can just start coding on the client.
(Note: This loosey-goosey approach can also be a negative. See below.)
Here I discuss a pattern of dependency management using
extensions to create Dependency Mixins.
One of the fundamental principles of good software engineering is separation of concerns: keeping components small and self-contained, while carefully managing inter-component dependencies. Dependencies are necessary, of course, but the principle of loose-coupling means designing so that each component can be changed or replaced without large disruptions to the rest of the system.
Even more importantly, it means we can test each component individually, giving us greater confidence in the correctness of our software.
The first step in achieving loose-coupling is to separate each component’s implementation from its interface. In Swift, this means creating a
protocol which defines the class’s public interface. Then, classes which depend on it can refer to the protocol and don’t need to care about the behind the scenes implementation.
Once you have that separation, the question becomes how and where to instantiate your concrete components, and how each component accesses its dependencies. Many developers, including Apple themselves, resort to using singletons or global variables. This is considered an “anti-pattern” because it violates the loose coupling principle and ties your components more tightly to their dependencies’ implementation.
Since you can’t instantiate a
protocol directly or access it as a singleton, the protocol-based approach forces you to think about better ways to get access. Two common patterns for this are Dependency Injection and Service Locator. They each have their pluses and minuses. One of the biggest challenges, especially for inexperienced teams, is that it takes more time and effort to use these techniques rather than simply using globals or singletons.
As we know, when something takes more time and effort, it often doesn’t get done.
I present here a technique which facilitates either approach, based on the concept of Mixins using Swift’s Protocol-Oriented Programming. We can call this pattern the Dependency Mixin.
And you’re happy with malloc and free,
If you’re one of the masses
Who disdain to write classes,
It’s time to start coding in C.
For recursing through various entities
Or traversing a forest of data trees,
I’d say Lisp is the one
For your programming fun,
If by fun you mean lots of parentheses.
I cut back on my usage of braces,
Threw out my selects and my cases.
I was feeling dynamic!
But I started to panic
When I learn of significant spaces.
Oh Java, I’m not being snarky,
But tell me, what is this malarky?
Thought my head would explode
When I looked at the code
And saw pages of class hier-ARCHy.
I know an intelligent girl.
On the keyboard her fingertips twirl.
Soon brackets and slashes
Meet dots bangs and hashes
As she writes her next program in Perl.
That it’s functional under the hood.
That for every mistake
That’s too easy to make,
There’s a “good part” that’s misunderstood.
It gave all our spirits a lift
When Apple unveiled a new gift.
With inferring of types
And bit too much hype
So launches the era of Swift.
C++ for its time was quite neat
As a tool for the coding elite,
But I started to doubt
On the day I found out
That its templates are Turing complete.
The mixing of content and code
Has proven a dangerous road.
And those who agree
All blame PHP
When pages take ages to load.
It’s not universal as yet,
But everyone fancies .NET.
Since we all can agree
That it’s sharper than C.
For MS it’s the best you can get.
If you’re looking to program .NET
F# is the language to get.
I once read about LINQ —
It’s quite useful I think,
Though the syntax I sometimes forget.
We’re studying SQL
To save us from database Hell,
And when we speak we’ll
Pronounce it sequel.
(Though spelling it works as well.)
Try making your website come alive
By learning some HTML5!
With new tags galore,
New effects and more,
The future is soon* to arrive!
10 It was back in the days of my youth
20 ‘fore I knew that GOTO was uncouth.
25 I learned how to program
26 With BASIC and FORTRAN.
30 (Not the prettiest code, it’s the truth.)
With all that a website entails
I thought I’d try Ruby on Rails.
The code, it all works,
But the folks were such jerks
I decided to hit the trails.
Objective C, Objective C,
Without you, oh where would we be?
Your syntax is old
(Too verbose we’ve been told)
But as clear as a language can be.
If you’re praising Objective C
I’m afraid that I must disagree.
Those gosh darn brackets!
They’re like straight jackets.
They litter the code like debris.
So Google has come out with Go
Is it good? Well I really don’t know.
It’s another arbitrary
To be cancelled before it can grow.
Speaking of cancelling projects
Angular lands with the rejects.
“We’ll support version 2!
And we swear that it’s true!
We’d never be evil at Googleplex.”
Remember the promise of Flash
Before it turned out to be trash?
With too many updates,
With adverts and clickbaits,
And bugs that would cause it to crash.
In the low-level language family
You can never exceed assembly.
It’s lightning fast —
I’d say unsurpassed,
Though not very user friendly.
Some programmers back in the day
Used COBOL, I’m sorry to say.
Two digits per year
Was awfully severe:
It left us with Y2K.
It seemed so simple to request
To center text with CSS.
Left-to-right went okay,
But oh dear! I must say
Up-and-down was a terrible mess.
So Pascal, yes I vaguely recall
From a course that I studied one Fall.
Fell asleep in the lecture,
Which makes it conjecture
To remember the language at all.
Some Programming Language Limericks by Eddie Sullivan is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Welcome to Emoji World.
The age of texting brings with it its own language and culture. It has been pointed out that the current time period is the first in which we have real-time written communication. Add to that the limited input methods we’re forced to use, and it’s no wonder a new vernacular has developed.
To overcome the limitations of textual communication without requiring impractical verbosity, we have resorted to emoticons, abbreviations, and now emoji.
“Words words words” –Shakespeare
Once I was a programmer. I became one by learning BASIC, then QuickBasic, then C, then C++, and so on. Hours of copying code from magazines, scratching programs into a notebook with a pencil, solving problems, falling in love with ideas. I wrote programs. I programmed. I was a programmer.
I studied hard and eventually became a Software Engineer. I worked hard and became a Senior Software Engineer (with a brief detour as “Member of Technical Staff” at a new-fangled startup). Now I run my own company so I’m whatever the hell I choose to call myself. One thing I’m not, and have never been, is a coder.
Designing an API is an art and a science. Many intelligent people have failed. Those who succeed do so by keeping in view the main goal of an API: to annoy the hell out of developers.
My brothers and sisters, to honor that noble-ish pursuit we gather together to enumerate (see what I did there) the Seven Deadly Annoyances of API design. I never thought I’d write a listicle, but at least it has an erudite religious reference in the title.
First, a couple rules: We’re talking about successful, working APIs here. So things like “it doesn’t work” or “it opens a massive security hole” don’t count as annoyances. Don’t take the word “deadly” literally. And APIs that no one uses are not qualified. No, failed APIs are not annoying, just bad. Here we discuss just the minor things. The minor, hair-pulling, keyboard-smashing, Urban-Dictionary-quoting annoyances we all know and despise.
Many of the examples come from Android, because that’s who most recently has the pleasure of annoying me, but I don’t mean to pick on them. They have no monopoly on these sins.
Annoyance the first – trsnss
Yes, name-ification of things is hard. Still, common sense could go a long way. You gotta hand it to the Unix folks for their heroic efforts to save a keystroke – why say dupe when we can save that valuable E and say dup?
Number two is related:
When someone asks me what type of development I do, I say “all types.” Sometimes they nod and move on because they’re just making conversation. Others will probe deeper and ask about programming languages. I say “all of them.” That is clearly hyperbole, but in a very real sense, I mean it. Or rather, I mean the opposite.
What language do I develop in? None of them. You might as well ask, “In what language did Plato philosophize?” Well, he spoke and wrote in ancient Greek, but his ideas make just as much sense to those of us who don’t know a word of Greek. The ideas are universal; the language is the medium to communicate those ideas. Likewise, programming concepts are universal and the programming language is the (often clunky) means to communicate – to fellow developers and to the machine.
And yet… And yet, it’s not so simple, is it?
- Look up any chord, any tuning.
- Listen to any chord shape.
- Save chords into Lead Sheets for easy reference.
- Share chords and Lead Sheets with your friends.
Ever since the PC version of Guitarator Toolbox came out several years ago, folks have been asking me when there would be a Mac version available. Well, it’s been a while, but I think will be worth the wait. I’m proud to announce that Guitarator Toolbox is now available for purchase in the Mac App Store!
Thanks to those who tried the Beta version and gave me valuable feedback.
This version is for Mac only and requires at least OS X version 10.7 (Lion).
What is Guitarator Toolbox?
It is a desktop application, originally written for PC, but NOW available for Mac, with the following features:
- Look up how to play any chord you can think of in any tuning for your guitar, bass, or other stringed fretted instrument.
- Look up how to play lots of different scales.
- Perform a “reverse chord lookup” where you pick the frets and it tells you the name of the chord.
- NEW: Metronome.
- NEW: Chromatic Tuner.