Besides testing, Java code coverage can be a very effective debugging tool as it helps you see which code is ran.
Continue reading Java code coverage in Eclipse
Recently, I participated in a focus group where developers were asked to discuss how they make technology adoption decisions. Even “the big guys” seem unsure of how to get developers to notice and adopt their products. So, in this post, I’m going to try to reduce our learning and adoption process down to some concrete steps. The truth is, we don’t just pick up tools, components, libraries, or languages just to complete a particular task or project. In truth, any technology we adopt has to help us do one or more of three important jobs. The more of these jobs your product can do, the more likely developers will pick it up and stick with it.
Continue reading “How to Get Developers to Adopt Your Product”
by Jakub Hrozek and Andreas Schneider
Software testing is already a hard business. It gets even harder if you need to test software that is networked, requires custom users on the system or resolve DNS queries.
Consider software such as a file server — it needs to listen for incoming connections on a certain port, often a privileged one in case of well-known protocols. The file server also requires the ability to switch to different user accounts and act on their behalf to create files owned by these users. Finally, a client of this hypothetical file server might want predefined SRV records to be present in DNS for autodiscovery to work properly. All these cases should be tested on every build.
And it gets even harder if your unit tests can’t run as the root user to set up the environment. The use case of testing the full stack, including network, users or DNS with only regular user privileges is exactly what the cwrap.org project is aiming to solve.
Continue reading “Testing your software stack without root privileges using cwrap”
One feedback I got from my blog post on Understanding malloc behavior using Systemtap userspace probes was that I should have included an example script to explain how this works. Well, better late than never, so here’s an example script. This script prints some diagnostic information during a program run and also logs some information to print out a summary at the end. I’ll go through the script a few related probes at a time.
global sbrk, waits, arenalist, mmap_threshold = 131072, heaplist
Continue reading “Malloc systemtap probes: an example”
From Barry Manilow to Kiss, to Mary J. Blige and everyone in-between, people have been singing Talk to me for decades. And is it any wonder? Often we don’t feel heard or feel that we don’t understand what people are trying to say or do. In the fast pace of today’s business, effective communication to get everyone on the same page quickly is essential. Needless to say, this isn’t always easy.
Given that we have to communicate effectively and the fact that most all of us hate writing documentation, we need a better approach. So, what I’ve started to do with groups I work with, is to move beyond ineffective textual documentation to simply creating illustrations. There are four basic types we use depending on the situation and audience:
Continue reading “DevOps: Talk to me… Say what?”
DevAssistant is a new project that aims to make developers’ lives easier by automating repetitive and time-consuming tasks. It uses assistants—Yaml “recipe files”—that contain information on how to create new projects, modify existing projects, and how to set up environments for developing upstream projects.
Continue reading “DevNation 2014 recorded session: Slavek Kabrda – DevAssistant: What's in it for You?”
Each day I get off the elevator and walk to my desk at Red Hat I am greeted by a very large sign that says “Release early, release often.” This sign encourages us to get incremental results and get feedback on the software that we are working on early rather than uncovering a fatal flaw in design or implementation late in the process.
Continue reading “Monitoring: Corollary to "Release Early and Often"”
Today, we’ll share a small victory in our DevOps journey at Red Hat IT. This cross-team collaboration has saved our IT organization some headaches and wasted time. We open-sourced the code, hoping it can help you, too.
The Dev problem, from Sam Van Oort:
Continue reading “Git Bonsai, or Keeping Your Branches Well Pruned”
Hi, I’m Steve, a member of the Inception team at Red Hat. The Inception team was pulled from different parts of IT to foster DevOps culture in Red Hat. Though we’ve only been a team for a little over a month, we’ve been trying to do some early projects to make everyone’s lives easier.l
We spent quite a bit of time in our early meetings identifying pain points in the current processes. We talked with a few developers, ops folks, noted historical issues and ran with general brain storming. We heard a lot about configuration management, lack of information, redundant and time consuming tasks, and many more of what one expects when asking tech people what pains them.
Of course, Tim (another Incepticon) and I were itching to write some code so once the team identified a common issue for both developers and ops engineers we jumped in head first.
The rest of this post describes our journey from initially trying to implement a simple solution to improve the day-to-day lives of developers, through the technical limitations we experienced along the way, and finally arrives at the empathy for our developers we’ve gained from that experience. We’ll wrap up with a note on how Red Hat Software Collections (announced as GA in September) would’ve simplified our development process.
Continue reading “Feeling Developer Pain”
Just under a year ago, we introduced the Red Hat Enterprise Linux Developer Toolset 1.0 which provides the latest, stable open source developer tool versions at an accelerated cadence than that of Red Hat Enterprise Linux. That version started with gcc 4.7 and gdb 7.4. Since then, we’ve added V1.1 with some additional components and today we are announcing V2.0 beta that adds Eclipse, and more:
Continue reading RHEL Developer Toolkit 2.0 now in beta