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.
Read here about my motivations, how I chose the new name, and more.
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.
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:
All commercial backends will handle these things for you.
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 protocols and 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.
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.
They say, “JavaScript’s really quite good.â€
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.
10
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
Language proprietary,
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.â€
20
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.
(more…)
“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.
(more…)
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:
(more…)
In my career, I’ve developed professionally in Python, Java, Objective C, Swift, C#, C, Assembly, C++, TCL, Perl, JavaScript, PHP, Scheme, Racket, Haxe, ActionScript, Lua, and more. I love them all, and I love switching between them – I enjoy seeing the subtle nuances of language design. It’s almost like a window into the mind of the designer. Some might say that career-wise, it would be better to specialize in one language. Often the phrase “Jack of All Trades” is followed up derisively with “Master of None.” Obviously I disagree, and here’s why.
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.
Chorderator for iPhone and iPad
Purchase Chorderator in the App Store:
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).
It is a desktop application, originally written for PC, but NOW available for Mac, with the following features:
Visit the Guitarator Toolbox in the Mac App Store
