Why Software Documentation is the Next Big Thing

In programming, documentation is not only about documenting our code, but also the steps, processes, and architecture around how things work. We are most familiar with documentation from the aspect of the code, which is something that should be encouraged. But as developers look for greener pastures and move from one job to another, the idea of documenting every aspect of programming is important so that the effect of the bus factor does not set in for any organization when a programmer decides to leave.

Continue reading “Why Software Documentation is the Next Big Thing”

Preparing CentOS 6.8 for Work

I came across Linux in 2005, it was Debian. Then followed a love affair with Ubuntu, for which in March 2009 I purchased a netbook Asus EeePC 1000. In 2010, I began to contribute to ALT Linux participating in the “School Project” and even became a basic256 package maintainer.

The last few years my EeePC with Ubuntu peacefully rested deep in my cupboard. Then there was a chance to clean off the dust. There was a task to get acquainted with CentOS Linux and test examples for my webinar “Apache Ant – quick start”.

Continue reading “Preparing CentOS 6.8 for Work”

Java inside docker: What you must know to not FAIL

Many developers are (or should be) aware that Java processes running inside Linux containers (docker, rkt, runC, lxcfs, etc) don’t behave as expected when we let the JVM ergonomics set the default values for the garbage collector, heap size, and runtime compiler. When we execute a Java application without any tuning parameter like “java -jar mypplication-fat.jar”, the JVM will adjust by itself several parameters to have the best performance in the execution environment.

This blog post takes a straightforward approach to show developers what they should know when packaging their Java applications inside Linux containers.

Continue reading “Java inside docker: What you must know to not FAIL”

Red Hat Logo

C/C++ library upgrades and opaque data types in process shared memory

The problem

C/C++ libraries expect to be able to change the internal implementation details of opaque data types from release to release since such a change has no external ABI consequences. If an opaque data type is placed in process-shared memory (when allowed by the standard) and shared with multiple processes, each process must ensure they are using exactly the same version of the library or they could fail in unexpected ways during library upgrades. The placement of opaque data types in process-shared memory is never allowed unless otherwise stated by the library documentation. For the GNU C Library (glibc) you may place pthread_mutex_t, pthread_cond_t, and sem_t in process-shared memory as allowed by POSIX. Failures using these types occur because a process started more recently may have a newer version of the library for the type and that version may have a different understanding of the internal details of the type. The problem has always been one for the developer to solve, but without help, this problem is so intractable as to make it difficult to robustly use opaque data types in process shared memory.

We will cover opaque data types, what they are, why you would use them, and how library upgrades play into the problem, and what might be done by the application developer.

Continue reading “C/C++ library upgrades and opaque data types in process shared memory”

-Wimplicit-fallthrough in GCC 7

In C and C++, the cases of a switch statement are in fact labels, and the switch is essentially a go to that jumps to the desired label. Since labels do not change the flow of control, one case block falls through to the following case block, unless terminated by a return, a break, a no return call or similar. In the example below, “case 1” falls through to “case 2“:

switch (cond)
   {
   case 1:
     a = 1;
   case 2:
     a = 2;
     break;
   /* ... */
   }

Continue reading “-Wimplicit-fallthrough in GCC 7”

Developers, join us at Red Hat Summit!

Red Hat Summit 2017 is nearing (May 2-4, Boston) and more than ever will include more advanced application development sessions, CodeStarters, labs, birds of a feathers, etc. Visit the new “Developer Zone” in the expo area to try out new technologies for modern application development, attend sessions and earn “Developer Dollars” to buy cool swag (maybe a hoodie or other cool stuff??), and be sure to catch the opening keynote (May 2, 8:30 AM) for a fun demo of developer technologies – you’ll be glad you did.

Continue reading Developers, join us at Red Hat Summit!

Node, S2I and Docker

Intro

I like Node.js and I like Docker. While I am not an expert on either, I do pretend to be one at work.

Lately, I’ve been looking at Openshift CDK and how I can develop Node.js apps against it. Specifically, I was looking at the MSA Hello World Demo and the Bonjour microservice.

I also recently wrote about setting up a CDK environment on a freshly re-installed MacBook Pro.  I would check it out; it’s some good writing.

My initial goal was to figure out how to “containerize” a Node.js application and then put it on my local openshift VM, but when I started to look at it little deeper, I found a few different ways of doing it. Hopefully, this post will go into the different ways.

Continue reading “Node, S2I and Docker”