While testing is critical to any business, we know that testing every single part of your website can be counterproductive and costly. So how do you figure out exactly where to spend your money and resources and which are the most important areas for A/B testing?
Make sure you didn't miss anything with this list of the Best of the Week in the DevOps Zone (July 18 to July 25). This week's topics include getting started with Ansible, null object pattern implementation, an intro to functional programming in Java 8, immutable infrastructure, and code differentiation.
Data-driven testing is a powerful way of testing a given scenario with different combinations of values. In this article, we look at several ways to do data-driven unit testing in JUnit.
There may be a way to work around that: turn the table. Ask Bob for advice on your code. That will get the discussion going, and it may ease him into it. Also, code reviews have a big advantage: they don’t need much to get started. You don’t need everyone in the company to agree.
The benchmark tests to help you discover how Logback performs under pressure. Small configuration tweaks can have a huge impact on your logging throughput.
One of the building blocks we've created for Plumbr is addition of the unique identifier for JVM in order to link all sessions from the same JVM together.
In order to analyze a problem when tests fail, we need to get into detective mode. The more evidence we have, the better. With enough differentiation, we can get a mental model of what works and what doesn’t, and better – where the problem might lurk, so we can go on and fix it.
TeamCity from JetBrains is an easy-to-use and powerful continuous integration system. It is a commercial product, but there is a special zero-cost license for small projects and FOSS applications. While installing TeamCity is relatively easy, its setup is further simplified via the use of Docker.
When writing unit tests we mostly focus on business correctness. We do our best to exercise happy path and all edge cases.
When most of us think of where the gravitational pull is in DevOps, places like San Francisco, New York, and Belgium spring to mind. But the Midwest? You bet, pardner! For episode 45, we take a field trip to Minneapolis for its first ever DevOps Days.
For some reason I needed extremely large, possibly even infinite InputStream that would simply return the same byte over and over.
Quite common real life problem. Simple map based configuration. How to handle gracefully a situation when a given key is not supported? See how Groovy can simplify the implementation.
Immutable components as part of your infrastructure are a way to reduce inconsistency in your infrastructure and improve the trust into your deployment process. Atomic deployments, combined with validation of the image and easy rollback, make managing your infrastructure a lot easier.
Why Ansible? It’s agentless. Unlike Puppet, Chef, Salt, etc.. Ansible operates only over SSH (or optionally ZeroMQ), so there’s none of that crap PKI that you have to deal with using Puppet. It’s self-documenting, with simple YAML files describing the playbooks and roles. It’s feature-rich.
A good clean application design requires discipline in keeping things DRY
Accuracy helps us fix problems quickly. But it’s definitely not so easy to come by, because it depends very much on the tested code. However, using the combination of the methods I suggested, and making use of working to test to refactor and simplifications, test accuracy is definitely within reach.
You have unexplained production issues from time to time. The business is impacted and the management briefs down your neck while the pieces of the puzzle are collected. There is no way to recreate this on QA set-up. The issue is lurking there for quite a while and becoming more and more frequent.
FX Playground is a JavaFX-based prototyping tool or live editor that eliminates the step of compiling Java code.
All these and many other characteristics can influence your component choices. And while your decisions will change over time, the more information you have readily available to you when making these choices, the better off you will be.
We were proud to host our 2nd DevOps State of the Union event June 24th. We held it in Santa Clara during Velocity. Wow! What an amazing group and discussion. The goal for the evening was to bring together some of the top thought leaders in DevOps, with the media and analyst community.
To reach 100% testing coverage is a dream for many teams. The metric used is code coverage for tests, but is that enough? Unfortunately not. Code line coverage is not the same as functional coverage. And it is full functional coverage that really matters in the end.
Make sure you didn't miss anything with this list of the Best of the Week in the DevOps Zone (July 11 to July 17). This week's topics include DevOps best practices and culture, Java debugging, code readability, test-driven development, Docker 1.1, and Docker's new ignore features.
Tests should run quickly. We’re talking hundreds and thousands in a matter of seconds. If they don’t we’ll need to do something about them. Quick feedback is not only an important agile property. It is essential for increasing velocity. If we don’t work at it, the entire safety net of our tests can come crashing down.
I had to create a Individual Development Plan (IDP) for me as part of the regular official procedures.
Introduce Factory or Builder instead of repetitive boiler-plate code when constructing key objects. Several benefits: makes it easy to refactor and evolve how underlying objects are stitched together, makes it easy to write more intention revealing code, and very relevant / convenient when writing automated tests.