Membrane SoftwareTechnology development studio
Book icon The Membrane blog games programming star commander
Thursday, July 20 2017 22:09 GMT
Posted by: Membrane Estimated read time: 9m Tags: programming valgrind

A typical software application is built from a code base containing thousands of lines, and a complex application easily reaches into the millions as its developers add ever more functionality. However, each line of code in a project is a place where somebody could have made a mistake, and even a single coding mistake among millions of lines can bring everything crashing down if it falls in a critical area. Many programmers become reliant on simple visual inspection and peer review to find lines of code that might contain mistakes, an approach that proves utterly unworkable when scaling to a code base of significant size, not to mention the fact that imperfect human eyes miss things all the time when examining code bases of any size. It's inevitable, then, that we'll need to use tools of some sort to analyze our code base. Ideally, these tools would be rolled into an automated build that processes all code after each change is committed, thereby giving us a system of continuous integration. On a team with multiple developers, such a system is invaluable; if any individual commits a change found to cause errors, we can easily revert the code its previous and known good state.

Today, we'll take a look at valgrind, a tool that comes in very handy as part of an automated build for C/C++ code. In applications built from these languages, the memory leak is one of the most common types of bugs as well as one of the most pernicious, often causing the user's system to slow to a crawl before an inexorable process crash hits. With valgrind's help we can flush out such leaks, along with several other types of issues related to memory management. Furthermore, by incorporating valgrind into a project as a build step, we can detect critical bugs as soon as they are coded, hopefully preventing their propagation to production sources and keeping them out of the hands of users.

This article refers to sample source files, which are available for cloning in the valgrind-testapp project on GitHub.

Wednesday, June 14 2017 18:01 GMT
Posted by: Membrane Estimated read time: 15m Tags: docker sysadmin programming

Call it a fact of life: computer systems fail, sometimes catastrophically. One afternoon not too long ago, a web server of mine became the latest in a long line of systems throughout history to do just that. It was midway through just another day of programming in the office when I noticed this server go completely offline without a warning or apparent cause. Contacting the data center support staff, we soon discovered that the server had been accidentally wiped and reinstalled in what I can only assume was a bad click or fat finger type of error. This server had been running several web sites, including and the forums we use for blog comments, but due to this mishap it was now rendered dead in the water, a purposeless brick.

Back in the old days, fixing our dead server would mean carefully reinstalling and reconfiguring the many software packages involved with a set of web sites, including: nginx, apache, PHP, MongoDB, and others, not to mention any custom software on the sites that we hope runs exactly the same way when transported into a shiny new system environment (hint: sometimes it doesn't). Dealing with all of this mess takes time and effort, which is not exactly ideal when there's other work to be done. In this case we were prepared, however, and reduced an afternoon's worth of work to just a few commands. Today, we'll see how that was possible thanks to Docker, a containerization layer providing an efficient and reliable paradigm for deployment of software applications. We'll also look at examples of a working project on GitHub that could be used by anyone to run a web server on any host able to start a Docker container.

Tuesday, May 23 2017 22:20 GMT
Posted by: Membrane Estimated read time: 9m Tags: programming membrane control
As more people join the world of modern, high-speed Internet, we've seen the rise of video as the preferred medium for communicating information. Indeed, according to some reports, video will comprise a staggering 82% of internet traffic by 2020. Use of video in place of text certainly has its advantanges, not least of all the ability to capture nonverbal queues helpful for human interaction. However, video also comes with a rather heavy downside in its sheer bulk and general lack of convenient ways to work with it. Managing thousands of text files is a snap for a personal computer and its operator, and the whole file set can be transmitted across the Internet in moments. On the other hand, managing thousands of video files, each of which might have its own quality, encoding standard, and format, quickly becomes a tangled and time-consuming mess. At Membrane Software, we seek better lives through computing, and today we'll look at development screenshots from a software system designed to help those like us: video enthusiasts who crave a convenient archive and retrieval system.
Tuesday, May 09 2017 01:08 GMT
Posted by: Membrane Estimated read time: 5m Tags: programming raspberry pi
In a previous post, we discussed the concept of electronic devices that act as appliances, with the word "appliance" used to describe our requirement that the device should do its job effectively while maximizing user convenience. Under that guideline, a perfect appliance is one that always does what its user expects and never causes surprises. A simple device such as a toaster has few expectations and rarely finds a way to violate them, but a general purpose machine such as our old friend, the Raspberry Pi, has many possible functions and is therefore more likely to do the unexpected. Luckily for us, however, it's possible to get a Raspberry Pi closer to appliance-like behavior through software. If we take control over the methods by which such a device is able to receive commands, we can, through careful programming, ensure that those commands are always handled in a manner that best reflects the user's intent. Today, we'll look at the first step in programming the Raspberry Pi, which is the same first step we see in any programming project: build and install our target hardware to prepare an environment for development.
Older posts >