This is a trailer for the latest Jim Jarmusch movie, “The Dead Don’t Die.” Focus Features will release (or drop for those of you who think that “release” isn’t post-modern enough) on June 14th. The trailer dropped around April 1st. (Wow. That is a cool verb. I can’t get enough of it now.)
Jarmusch’s films make me want to write. They’re character-driven, and they feel like I wish I could make my fiction feel. They’re the polar opposite of Hollywood blockbusters. His films are social commentary via character study. I suppose that this means I want to write library fiction? I’m not sure I agree now that I wrote that out loud.
It’s not that I don’t enjoy blockbuster movies or look down on them. Just like I can’t survive on popcorn and sushi alone, I don’t want every film to be Winter Soldier or Heat.
Watch the trailer if you haven’t already. Watch it again. Almost every character on the screen is, well, a character. They’re not vehicles for punchlines or moving targets for the next wave of gunfire. From a few lines of dialog or a single facial expression, we know who the players are and why they’re on the screen. It’s easy to see why talented actors like Tilda Swinton, Forest Whitaker, Adam Driver, Roberto Benigni, Steve Buscemi, and Isaach De Bankole work with him instead.
I want to create stuff like this. Of course, that also means that I need to get over my pathological fear of writing fiction.
So, unrelated to the fortuitous drop of this trailer (See what I did there? I’m almost hip enough to write for Ain’t It Cool News.) I’ve taken steps to force myself to get back to work on my Sixth Age series of books.
(No boring, old-fashioned, and coherent, verbs like release, issue, offer, or deliver were injured in the dropping of this blog post.)
Need some background on how to debug iOS? I wrote this post for Raygun’s blog.
In this tutorial, we’ll debug an iOS application with Apple’s Xcode. Xcode is a robust environment for developing and troubleshooting iOS applications. We’ll see how we can use it, alongside Raygun’s iOS Crash Reporting, to quickly address an application deficiency.
We’ll follow six steps to examine a simple application and isolate and fix a bug.
Setup a sample project
Analyze a Raygun debug report
Explore Xcode’s debugging tools for iOS
Set a breakpoint in Xcode
Run the application with a breakpoint
Isolate the bug and fix it
This tutorial requires a macOS computer with Xcode installed. We’ll be using the current version of Xcode at the time of this writing, which is version 10. We’ll write the sample application in Objective-C, but all of the debugging steps are valid for a Swift application, too. The source code for this project is available here on Github.
So, let’s get started!
Step 1: sample project
We’ll use a single view iOS application for this tutorial. The single view has a button with text that changes for each press.
If you want to follow along, you’ll need to register for a Raygun account here. After you check out the project, add your Raygun API (Application Programming Interface) key to didFinishLaunchingWithOptions in AppDelegate.m
You can find complete instructions for setting up an iOS application here. You can follow this tutorial with your application if you prefer.
Here is the sample application’s startup view.
Each time you tap the button, the display text changes. After a few presses, the application crashes. Imagine that this application has been released to the App Store and was already approved. You need to track down the bug fast!
Since we forced the error now, we don’t need the date and time. But in the event of any errors happening in deployed applications, the date and time can be advantageous.
The class name and error message tell us a lot about the error. NSRangeException indicates that the code exceeded the bounds of a data structure, and the report suggests a subscript out of range is causing the crash.
Raygun also provides a backtrace for the error.
Since we’re dealing with an uncaught exception, the backtrace only provides us with a rough idea of where the error is occurring; somewhere in UIKit. So, we’ll need to run the application in a debugger to find the exact location.
Step 3: iOS debugging with Xcode
Xcode provides iOS developers with an integrated environment for developing, testing, and debugging iOS applications. The simulator supports all current iOS platforms. You can install and run applications with a single click, and the environment has integrated support for the lldb debugger.
So, you can debug your application on your development desktop. Let’s start with replicating the error in the simulator.
We want to be sure we run a debug build, so start by holding the option key and clicking the run icon on the upper left-hand side of Xcode. This brings up the run options dialog.
Make sure that you have Run selected on the left-hand side, and debug build enabled on the right. Now, click on the run button. After the build completes, the application will start in the simulator.
Next, click the iOS app’s button until the application throws the exception and the debugger comes up in Xcode.
On the left-hand side, the debug navigator displays the application threads. Xcode highlights main in thread #1 since uncaught exceptions “bubble up” to that location in the application. In the editor pane, Xcode highlights that function in main.m. Xcode shows us that a SIGABRT was thrown inside main. Down at the bottom of Xcode lldb’s command line interface is available. We’re going to control it from the GUI (Graphical User Interface).
Finally, click the stop button, next to run, to stop the debug session.
Raygun already told us that the application has an uncaught exception, so we haven’t learned anything new about the bug yet. Now, let’s use Xcode to catch the exception and discover where it’s coming from.
Step 4: set exception breakpoint
So, go to the Debug menu, select Breakpoints and Create Exception Breakpoint.
Xcode brings up the breakpoint navigator on the left, and a popup will appear.
The default is to break on both C++ and Objective C exceptions and to stop the debugger where they are thrown. This will take us to where the problem occurs. Next, click anywhere to dismiss the popup and accept the defaults.
Step 5: run the application with breakpoint
Now, rerun the application and force the error.
The debugger stopped when the application generated the exception and highlighted the line of code that is responsible.
Just as you might expect from the Raygun error report, the code references an array. The problem is clear from viewing the highlighted line. We’re incrementing the array index without checking bounds. If you look down in the debug window in Xcode, you can see that counter somehow made it to a value of five when the array is only four elements long. The application should have crashed sooner than it did.
But what if the problem was more difficult to isolate? Let’s add one more breakpoint and step through the application again.
Step 6: isolate the bug and fix it
First, stop the debug session.
Next, double-click next to the offending line in the source code to bring up a breakpoint dialog popup.
Add a condition for the breakpoint; counter > 3.
Rerun the application, and when you force the error, it will stop before iOS throws the exception. The array index and the increment are on the same line of code. So, continuing after the breakpoint will still result in iOS throwing the exception. This breakpoint makes the bug clear, and we can see how conditional breaks can help isolate a thorny problem.
There are several ways to fix this bug. Most of the better ones involve a different design, but let’s go for a quick fix.
// Do any additional setup after loading the view, typically from a nib.
By checking the array bounds before we increment the counter, we never exceed the array length. Rerun the application, and the crash is gone.
Apple’s XCode development tool simplifies debugging iOS applications. It provides integrated support for an advanced debugger as well as GUI-based shortcuts for common tasks like adding breakpoints. Fortunately, you can also rely on their simulator to accurately emulate the full set of iOS devices since Apple controls the platform. Once you’ve verified an issue is addressed in the simulator, you can push to local devices and test there too.
Of course, with Raygun, you have an extra layer of protection for detecting, diagnosing, and eliminate iOS errors. The Raygun report in this example told us what the failure was, and made it much easier to isolate. Raygun’s smart alerts and error grouping means you never miss a bug in your app again. Read more about iOS crash reporting here.
What’s the difference between microservices and SOA? The two design paradigms have a lot in common.
That makes sense when you consider that microservices are an offshoot of the SOA movement. But there are essential differences between the two systems. Let’s take a look at the two different approaches to architecture and highlight where they differ.
Before we dive in, it’s important to note that neither architecture has a universally accepted definition. So, you could spend as much time debating the details of what microservices or SOA are as you could arguing their differences.
What’s a Microservice Architecture?
Search for “what are microservices?” on the internet, and you’ll see many different definitions. So, let’s factor in the common attributes and look to an expert for some help with defining them.
A microservice architecture builds applications with loosely coupled services. Each service has a single responsibility. So, they focus on one task, such as authentication, billing, or inventory.
Martin Fowler’s Definition
Here’s a concise definition from Martin Fowler and James Lewis.
“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” – James Lewis and Martin Fowler
There’s a lot packed into that paragraph. Let’s take a look at four of the main points in this definition.
Loosely Coupled and Loosely Managed
Each service runs in its own process. Many web applications used to run as a single server. So, services running in separate processes are an important break from the past. But the Wikipedia definition of microservices says that they can run in the same process. This illustrates how hard it is to nail these definitions down.
We build microservices around business capabilities. Whether or not a service runs in its own process seems like an academic argument. What the code does is where the rubber hits the road. We build microservices around specific business capabilities, and that’s what puts the “micro” in them. The service focuses on a particular responsibility within the broader application. The number of lines of code and the process footprint isn’t what makes them small.
We deploy and run microservices independently. Microservices stand alone, and we can install and run by themselves. Development teams are also independent, so they can develop applications with tools and languages that are distinct from other services in the same application. The teams also use continuous integration and automated testing.
We deploy microservices with limited centralized management. Microservices architectures have limited and decentralized governance. So, development teams have a lot of autonomy. They manage their schedules, and different parts of an application are deployed at different times. Teams select their platforms, languages, and tools. As we’ll see, this is one of the areas it departs significantly from SOA.
What’s Service-Oriented Architecture?
There’s no single definition of SOA. It’s been around for a long time. Several major software vendors embraced it in its heyday, so the architecture tended to have different definitions depending on where you looked. Thirteen years ago, Fowler wrote an article titled ServiceOrientedAmbiguity where he concludes “I think SOA has turned into a semantics-free concept that can join ‘components’ and ‘architecture.”
The Open Group Definition
But there is a definition from The Open Group. This industry group defines the UNIX trademark, the TOGAF architectural standard, and SOA. The SOA standards page is here. You have to create an account before you can download PDF versions of their document. So, we’ll go to the Wayback Machine and get the page where they used to share their SOA definition for free.
The SOA definition is longer than the one I used for microservices. So, I’m only going to provide a couple of excerpts here.
Service orientation is a way of thinking in terms of services and service based development and the outcomes of services.
Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
May be composed of other services
Is a “black box” to consumers of the service
So far, we can see a lot of overlap between microservices and SOA. The first two bullets work with Fowler and Lewis’ definition of microservices.
But, the third is where things start to diverge. Can you build a new service by combining two others and still call it a microservice? Probably not. The combined services are no longer independent. So, we can see where SOA and microservices are not the same things.
Meanwhile, the last point is just good design. A service that requires knowledge of its implementation is an anti-pattern. I’m surprised that item made it past the committee.
SOA and Centralized Governance
Open Group’s architectural style list implies that it contains “must have” features. Let’s look at a few salient points.
Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
It requires strong governance of service representation and implementation.
The standard mentions service orchestration and states that if your architecture doesn’t use it, it’s not SOA. This requirement runs directly against how Fowler and Lewis describe microservices. Service orchestration implies the kind of synchronization and coupling between services that microservices do not have.
They also clearly state that SOA requires strong governance.
So, from just a brief look at a definition of SOA, we see clear differences with microservice architecture.
Microservices Vs. SOA: What Are the Differences?
First, let’s start with the obvious difference. The SOA architecture requires strong governance, while microservices do not.
Fowler and Lewis dedicate a section of their post to decentralized governance and data management. Microservice teams work independently. They manage their schedules and work with the tools they wish. They maintain control over how they represent business objects and make their own data storage decisions. Fowler presents this as an advantage. When you read the description of how the teams operate, you can’t help but think of an agile program.
The Open Group requires strong governance in SOA. They have a standard for SOA governance here. (PDF here.)
Here’s a quote:
As a discipline, governance has been with us for many years, but with the advent of enterprise SOA, the need has been heightened for organizations to take governance as a discipline more seriously.
The standard implies that we need to tighten oversight for service-oriented architecture, not loosen it. A quick scan of the standard brings to mind daily status meetings, launch checklists, and quarterly software releases.
Independent Services and Service Orchestration
We think of microservices as independent entities. They are loosely coupled, if coupled at all, and employ their own messages and domain logic. Fowler refers to this as smart endpoints and dumb pipes.
The SOA standard specifically mentions service orchestration. If you dig deeper, you find discussions of messaging. Services using a message bus to communicate with each other. Many SOA implementations use an enterprise service bus to coordinate activities between services.
This is where the two architectures have their most significant differences. If SOA services are going to communicate across a shared bus, they need centralized governance, even if it is not necessarily as rigorous as the one spelled out by the Open Group. They have to agree on how to represent business objects and the domain logic that manipulates them.
Microservices exist in silos and, if implemented with Fowler’s smart endpoints and dumb pipes evolve independently.
Microservices Vs. SOA: Why Should I Care?
So, it turns out there’s a difference between these two architectural patterns, and it’s a significant one. Microservices stand alone, with decentralized management. Development teams can work independently, and with the tools they choose. Fowler at least implies a direct connection between agile methodology and microservices.
Meanwhile, an application built with SOA is composed of services that are more closely coordinated than with microservices. This means establishing governance in advance, and often requires that development teams use the same tools.
Is one paradigm better than the other? I don’t think so. While the decentralized management and isolation of microservices are inherently attractive, some problem domains can benefit from services that communicate with each over a backplane.
The question you should really be focused on is, do you know how your system is designed, and why?
This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)
“Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats.”
It’s from H.L. Mencken. I see it used often. What I don’t often hear though is that it’s from an essay titled “The New Poetry Movement,” and is part of a reference to Ezra Pound. I’ve read it a few times, and I’m still not sure whether he wants to slit Pound’s throat or help him slit the throats of the new movement.
Mencken was a colorful guy. The quote immediately evokes an image of pirates storming a merchant ship, swords unsheathed and knives in between teeth.
While Mencken was referring to poetry the quote has taken on a life of its own. Most use it in the context of getting serious. Of rolling up one’s sleeves, to borrow another metaphor. Kicking ass and taking names, to borrow another.
I have mixed feelings about the imagery, to be honest. On the one hand, I read it in the context of motivation and it works for me in a “let’s blast Van Halen’s ‘Fair Warning’ and hit the gym kinda way. On the other, killing people shouldn’t be motivating.
Either way, it’s a New Year and this one is going to be full of big changes.
The proceeding sentence is the complete message, but Yoast SEO tells me I need more words. So here goes.
In 1899 Elbert Hubbard wrote “A Message To Garcia.” He published it in The Philistine (yes, really) as filler. But, it caught the eye of a railroad executive who gave it wider circulation. It caught the executive’s eye because a shallow reading of the essay might come away with the impression that Message is an entertaining screed about lazy employees that can’t follow orders.
But it’s so much more than that. It’s about doing things. Getting them done.
Here’s a sample:
The point I wish to make is this: McKinley gave Rowan a letter to be delivered to Garcia; Rowan took the letter and did not ask, “Where is he at?”
By the Eternal! There is a man whose form should be cast in deathless bronze and the statue placed in every college of the land. It is not book-learning young men need, nor instruction about this and that, but a stiffening of the vertebrae which will cause them to be loyal to a trust, to act promptly, concentrate their energies: do the thing- “Carry a message to Garcia!”
Hubbard (no relation to L. Ron Hubbard, general -purpose fabulist and founder of Scientology) wants to erect a statue to a guy that was given a letter and delivered it without any questions or excuses. He’s a real kidder.
It’s encouraging to read a message from 1899 that’s complaining about millennials and their refusal to get things done. The next time someone tells you about how uniquely lazy and stupid your generation is, you can give them this PDF.
Hubbard’s broader point is “do the thing.”
Stop thinking. Put down the book. Turn off the TED Talk. Close the browser window. Pause the podcast.
Deliver. Execute. Get it done.
The world will better off with one less slogan and one more finished project.
Confucius said “the man who chases two rabbits ends up at Chipotle.”
Or was that Jeffrey Lebowski?
Anyway, I’ve spent most of 2018 in a self-imposed tug-of-war between working on fiction and freelance gigs writing tech blogs.
I’ve always wanted to write fiction, and I find the writing very rewarding when I have the time to focus on it. I’m a voracious reader of science fiction and fantasy.
At the same time, I like technology too. I’m also pretty good at it, having been a radar repairman, field service engineer, system engineer, Polyglot programmer, classroom instructor, and freelance tech blogger.
Because I couldn’t figure out what I wanted to focus on, I neglected this blog. I needed to pick an audience and then post what that audience wants to read.
So, it’s time for a change.
Going forward, this space will be mostly about technology and tech blogging. In addition to periodic personal blogs, I’ll be cross-posting posts I write for tech companies when I am permitted too.
I will still publish the occasional personal post, collection of photos, and links to comic reviews when I feel like. I’m headed to NY Comic Con 2018 as a member of Multiversity Comic’s Staff, and I am sure that will lead to a post or three.
But for the most part, this space will be about technology and tech blogging. Fiction is going on the backburner until it gets the time it deserves.