DaedTech

Stories about Software

By

What is Real User Monitoring?

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look around at their assortment of monitoring solutions.

Perhaps you’ve heard the term “real user monitoring” in passing.  Our industry generates no shortage of buzzwords, many of the them vague and context dependent.  So you could be forgiven for scratching your head at this term.

Let’s go through it in some detail, in order to provide clarity.  But to do that, I’m going to walk you through the evolution of circumstance that created a demand for real user monitoring.  You can most easily understand a solution by first understanding the problem that it solves.

A Budding Entrepreneur’s Website

Let’s say that the entrepreneurial bug bites you.  You decide to build some kind of software as a service (SaaS) product.  Obviously, you need some time to build it and make it production ready, so you pick a target go-live date months from now.

But you know enough about marketing to know that you should start building hype now.  So, you put together a WordPress site and start a blog, looking to build a following.  Then, excited to get going, you make a series of post.

And then, nothing.  I mean, you didn’t expect to hit the top of Hacker News, but you expected… something.  No one comments on social media or emails you to congratulate you or anything at all.

Frustrated, you decide to add a commenting plugin and some social media share buttons.  This, you reason, will provide a lower friction means of offering feedback.  And still, absolutely nothing.  Now you begin to wonder if your host provider hasn’t played a cruel trick on you in which it only serves the site when you visit.

The Deafening Lack of Feedback

If perhaps it sounds like I empathize, that’s because I sincerely do.  Years and years ago when I started my first blog, I posted into the ether.  I had no idea if anyone read those early posts.  Of course, I was just having a good time putting my opinions out there and not trying to make a living, so I didn’t worry.  But nevertheless, I eventually felt frustrated.

The frustration arises from a lack of feedback.  You take some actions and then have no ability to see what affect they have.  Sure, you can see the post go live in your browser, but are you reaching anyone?  Has a single person read the post?  Or have thousands read the post and found it boring?  It’s like writing some code, but you’re required to hand it off to someone else to compile, run, and observe.  You feel blind.

Read More

By

Software Monitoring: The Things that Might Interest You

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at the different sorts of production concerns that you can keep an eye on with their offering, some of which I address in this post.

If you have responsibility for software in production, I bet you’d like to know more about it.  I don’t mean that you’d like an extra peek into the bowels of the source code or to understand its philosophical place in the universe.  Rather, I bet you’d like to know more about how it behaves in the wild.

After all, from this opaque vantage point comes the overwhelming majority of maddening defects.  “But it doesn’t do that in our environment,” you cry.  “How can we even begin to track down a user report of, ‘sometimes that button doesn’t work right?'”

To combat this situation we have, since programmer time immemorial, turned to the log file.  In that file, we find answers.  Except, we find them the way an archaeologist finds answers about ancient civilizations.  We assemble cryptic, incomplete fragments and try to use them to deduce what happened long after the fact.  Better than nothing, but not great.

Because of the incompleteness and the lag, we seek other solutions.  With the rise in sophistication of tooling and the growth of the DevOps movement, we close the timing gap via monitoring.  Rather than wait for a user to report an error and asking for a log file, we get out in front of the matter.  When something flies off the rails, our monitoring tools quickly alert us, and we begin triage immediately.

Common Monitoring Use Cases

Later in this post, I will get imaginative.  In writing this, I intend to expose you to some less common monitoring ideas that you might at least contemplate, if not outright implement.  But for now, let’s consider some relative blue chip monitoring scenarios.  These will transcend even the basic nature of the application and apply equally well to web, mobile, or desktop apps.

Monitis offers a huge variety of monitoring services, as the name implies.  You can get your bearings about the full offering here.  This means that if you want to do it, you can probably find an offering of theirs to do it, unless you’re really out there.  Then you might want to supplement their offering with some customized functionality for your own situation.

But let’s say you’d just signed up for the service and wanted to test drive it.  I can think of nothing simpler than “is this thing on?”  Wherever it runs, you’d love some information about whether it runs when it should.  On top of that, you’d probably also like to know whether it dies unexpectedly and ignobly.  When your app crashes embarrassingly, you want to know about it.

Once you’ve buttoned up the real basics, you might start to monitor for somewhat more nuanced situations.  Does your code gobble up too many hardware resources, causing poor experience or added expense?  Does it interact with services or databases that fail or go offline?  In short, does your application wobble into sub-optimal states?

But what if we look beyond those basics?  Let’s explore some things you may never have contemplated monitoring about your software.

Read More

By

Choosing an Acceptance Test Framework

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at their monitoring solutions.

I can still remember writing my first automated tests in a professional setting.  Notice that I didn’t say unit tests, and for good reason.  At the time, some 14 years ago, I hadn’t heard of unit tests.  Instead, I simply automated the process of manually testing my software.

This may sound somewhat facile, but it actually speaks to core principles in the programming profession.  As a relatively inexperienced programmer, I understood the importance of testing my work.  I also understood the importance of automating manual, error-prone process.  And so, of my own accord, I examined and then automated my previously manual testing efforts.

Don’t get me wrong.  By doing this, I reinvented a wheel simply because I did not know of its existence.  Folks had created automated unit test frameworks for this exact purpose.  Had I known, I could have better spent my time learning and using these things.  But, in spite of the waste, I did learn something.  I learned that, under the covers, test frameworks just represented yet another instance of automating an important manual process.

What is User Acceptance Testing (UAT)?

I led with a tale about unit tests because testing software components applies to everyone that writes software.  I mean, you always test your own software, even if you don’t think you’re doing so.  Whenever you compile, you test your code to see if it compiles.  Granted, you aren’t executing the most sophisticated, high-value test known to man.  But you are performing a test of sorts.

But what if we look beyond our own dev boxes a bit?  What if we look at other forms of testing?

For almost any software that we write, other stakeholders will perform other sorts of tests.  These stakeholders includes users or user-proxies, who perform an activity known as user acceptance testing (UAT).  In its simplest incarnation, this involves users or their proxies using the software and evaluating whether or not they find it acceptable.

This can come in various shapes and sizes.  In some cases, actual users perform formalized beta tests, perhaps for pay.  In other cases, someone from the QA group might do a quick run-through and give a thumbs-up or thumbs-down.  But whatever happens, these tests capture the user’s experience and perspective.

Read More

By

APIs and the Principle of Least Surprise

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at some of the other authors for their blog.

I remember something pretty random about my first job.  In my cubicle, I had a large set of metal shelves that held my various and sundry programming texts.  And, featured prominently on that shelf, I had an enormous blue binder.

Back then, I spent my days writing drivers and custom Linux kernel modules.  I had to because we made use of a real time interface to write very precisely timed machine control code.  As you might imagine, a custom Linux kernel in 2005 didn’t exactly come with a high production quality video walking users through the finer points.  In fact, it came with only its version of the iconic Linux “man pages” for guidance.  These I printed out and put into the aforementioned blue binder.

I cannot begin to tell you how much I studied this blue binder.  I pored through it for wisdom and clues, feeling a sense of great satisfaction when I deciphered some cryptic function example.  This sort of satisfaction defined a culture, in fact.  You wore mastery of a difficult API as a badge of honor.  And, on the flip side, failure to master an API represented a failure of yours.

Death of “Manual Culture”

What a difference a decade makes.  No longer do we have battleship gray windows applications with dozens of menus and sub-menus, with hundreds of settings and thousands of “advanced settings”.  No longer do we consider reading a gigantic blue documentation binder to be a use of time.  And, more generally, no longer do we put the onus of navigating a learning curve on the user.  Instead, we look to lure users by making things as easy as possible.

Ten years ago, a coarse expression described people’s take on this responsibility.  I’ll offer the safe-for-work version: “RTM” or “Read the Manual.”  Ten years later, we have seen the death of RTM culture.  This applies to APIs and to user experiences in general.

Read More

By

An Introduction to the Types of Cloud Computing

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look around at some of their other authors and content.

The folks at Gartner have something awesome called the “hype cycle”.  The cycle contains a “peak of inflated expectations” and a “trough of disillusionment”.  So, that alone gives it a pretty significant amusement factor.

But beyond the amusement lies an important insight into our collective psychology.  Those of us working in tech work in a booming and constantly evolving industry.  Because of this, we find ourselves bombarded with buzzwords.  These generate excitement at first and disillusionment later.  Eventually, they reach equilibrium.

Gartner uses this set of observations to advise companies about risk.  But we can use it to identify a term’s likelihood to induce buzzword fatigue and produce derisive satire.

Let’s get specific.  Do you remember a few years back, when “X as a service” really took off?  The world seized on the promise of the cloud.  Don’t maintain it yourself — have a service do it!  As the term rocketed up the peak of inflated expectations, everyone wanted a part of the cloud.

But then it fell into the trough of disillusionment, and satire ensued.  Twitter accounts offered “sarcasm as a service” to poke fun at the hype.  If you saw an offering for “everything as a service,” you had no idea whether it was serious.

Since this time, however, these offerings have ascended the so-called “slope of enlightenment” and established themselves as mainstream.  Actually, let me correct that.  They have established themselves as foundational to the modern internet.

Let’s now unpack this X as a service concept a bit.  In order to do that, I’ll offer a story in contrasts.

The “As a Service” Concept

Imagine that I own a small business.  In this capacity, I want to keep track of prospects, leads, and customers for sales purposes.  You can think of this as “customer relationship management” (CRM) software.

Back in the early days of my career (late 90s, early 2000s), you might have done this with Excel.  At least, you would have used Excel until it became too unwieldy.  Then, you’d have gone to Best Buy and purchased software that you installed from a CD.  Finally, you’d have installed the “client” on anyone’s PC who needed to use it while installing the “server” on some jack of all trades machine running Windows 2000 or something.  From there, using it was as easy as making sure not too many people tried to change things at once.

Fast forward a couple of decades and that seems… odd.  These days, you’d probably just navigate to something like salesforce.com and create a trial account.  Certainly small business owners would take this approach.  Larger organizations with more privacy concerns might still setup servers and install their own software.  But even the ones doing this would probably host a web app and have “clients” access it via browser.

This tale drives at the essence of “as a service.”  Stuffed into that small phrase, you find the large, important concept of “let someone else worry about it.”  You shouldn’t need to think about clients, servers, networks, and the like to have a CRM system.  Let someone else worry about it.  You just want to sign in via the browser.

This concept has become so important and so ubiquitous that it drives today’s internet.  But not all cloud, “as a service” concepts are created equal.  Let’s take a look at the major types of cloud computing, by conceptual level.

Read More