DaedTech

Stories about Software

By

Integrating APM into Your Testing Strategy

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their tooling to help you with your APM needs.

Does your team have a testing strategy?  In 2017, I have a hard time imagining that wouldn’t at least have some kind of strategy, however rudimentary.  Unlike a couple of decades ago, you hear less and less about people just changing code on the production server and hoping for the best.

At the very least, you probably have a QA group, or at least someone who serves in that role prior to shipping your software.  You write the code, do something to test it, and then ship it once the testers bless it (or at least notate “known issues”).

From there, things probably run the gamut among those of you reading.  Some of you probably do what I’ve described and little more.  Some of you probably have multiple pre-production environments to which a continuous integration setup automatically deploys builds.  Of course, it only deploys those builds assuming all automated unit, integration and smoke tests pass and assuming that your static analysis doesn’t flag any show stopper issues.  Once deployed, a team of highly skilled testers perform exploratory testing.  Or, maybe, you do something somewhere in between.

But, whatever you do, you can always do more.  In fact, I encourage you always to look for new ways to test.  And today I’d like to talk about an idea for just such a thing.  Specifically, I think you can leverage application performance management (APM) software to help your testing efforts.  I say this in spite of the fact that most shops have traditionally taken advantage of these tools only in production.

Read More

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

What DevOps Means for Static Analysis

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at NDepend’s static analysis offering.

For most of my career, software development has, in a very specific way, resembled mailing a letter.  You write the thing, and then you go through the standard mail piece rigmarole.  This involves putting it into an envelope, addressing the envelope, putting a stamp on, it and then walking it over to the mailbox.  From there, you stuff it into the mailbox.

At this point, you might as well have dropped the thing into some kind of rip in space-time for all you understand what comes next.  Off it goes into the ether, and you hope that it arrives at its destination through some kind of logistical magic.  So it has generally gone with software.

We design it, architect, and lovingly write it.  We package it up, test it, correct defects in it, and then we call it done.  From there, we fire it into the mailbox-black-hole of the software world: operations.  They take it and deploy it, or whatever, and then, by some magic we don’t concern ourselves about, it runs in the real world.  Or so it has generally gone.

Problems with the Traditional Approach

With the benefit of hindsight, you can probably guess the main problem with this state of affairs.  So rather than enumerate it dryly in a series of bullet points, let me offer it up in story format.

You work as an application developer in some very large enterprise.  There, you build web apps.  And you take pride in your work.  You write clean code, you maintain the unit test suite, you collaborate dutifully with QA, and you generally do your best.

In fact, this effort even extends beyond your own dev environment and into as many environment as you can see.  You run load, smoke, and integration tests in QA and sandbox environment.  And, as a whole unit, your team does everything it can to ensure the integrity of the work.  But beyond the pre-prod environment, the fate of your application becomes an utter mystery.  Some group of folks located in a different timezone take it from there.  You wish it well as it heads to production.

And then, one day, six months later, you get some incident report.  Apparently, some guy in Hungary or somewhere was doing something when somehow he get a null reference exception.  But don’t worry, here’s a brief description of what he said and a few thousand lines of some random log file.  Good luck with your repro!

Read More

By

How to Write Code that Operations Will Like

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 the options you have for monitoring your production site and all of its supporting infrastructure.

In recent years, the DevOps movement has gained a significant amount of steam.  Historically, organizations approached software creation and maintenance in the same way that they might with physical, mechanical process such as manufacturing.  This meant carving the work into discrete components and then asking people to specialize in those components.

If you picture a factory floor, it becomes easy to picture.  One person screws two components together over and over, while another person operates a drill press over and over.  When you specialize this way, the entire process gains in efficiency.  At least, so it goes with mechanical processes.

With knowledge work, we haven’t realized the same kind of benefit.  In retrospect, this makes sense.  It makes sense because, unlike mechanical work, knowledge work involves little true repeatability.  It continually presents us with problems that differ at least somewhat.

As we’ve come to recognize that fact, we’ve begun to blend concerns together.  Scrum teams blur the lines among QA, developers, and business analysts.  And DevOps does the same with initial development and production operation of software.  If you can, I wholeheartedly encourage you to embrace DevOps and to blend these concerns.  Your entire work product will improve.

Unfortunately, not every shop can do this — at least not immediately.  Progress goes slowly in these places because of regulatory and compliance concerns or perhaps because change can come slowly in the enterprise.  But that shouldn’t stop you from making strides.

Even if development and operations remain separate, they can at least communicate and help each other.  Today, I’d like to talk about how developers can write code that makes life easier for ops folks.

Read More