HawtIO gives awesome eye candy to your JVM based middleware. It’s a unifying console for applications that would otherwise have to build out their own crappy web console
I always hated the word “maintainability” in the context of tests. Tests, like any other code are maintainable. Unless there comes a time, where we decide we can’t take it anymore, and the code needs a rewrite, the code is maintainable. We can go and change it, edit or replace it.
Given that refactorings change program structure without altering behaviour, the purpose of any refactoring must be the improvement of program structure. So how do programmers, "Best," improve structure?
For many of us who consider ourselves software developers, programmers, or even software engineers, it can be difficult to ignore the impulse to jump right in and write some code
A very simple guide to deploying a very simple application with Ansible. Of course, it should be obvious that you can deploy *anything* from a git repository, it really boils down to the configuration of supervisord. For that matter, it doesn't have to be supervisord.
Instead of fixing a problem we all probably prefer preventing the problem in the first place. Therefore in the latest version Degraph got a new feature: A DSL for testing Dependencies.
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.
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.
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.
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.
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.
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.
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.
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.
For a preview of what will be covered in a future article, try changing stream() to parallelStream() in the example and see what happens. So that’s the basic operations we’ve covered so far in the blog. We can take a container make a stream, transform items, filter items, peek at them and do something with them.