First, Do No Harm
Let’s face it: not all software developers are superstar programmers (and, trust me, not all luminary developers program in a sane way.) This means that when we maintain existing code, we must be very careful to avoid breaking or degrading the system we work on. Why? Because a failure of a running system can affect operations, people, profits, property, and sometimes even lives. Here are the rules.
Continue reading "First, Do No Harm"
Impact Factor of Computer Science Journals 2013
The Thomson Reuters Web of Knowledge
has published the 2013
Journal Citation Reports.
Following similar studies I performed in the past sever years
here is my analysis of the current status and trends for the
of computer science journals.
Continue reading "Impact Factor of Computer Science Journals 2013"
Service Orchestration with Rundeck
Increasingly, software is provided as a service. Managing and controlling the service’s provision is tricky, but tools for service orchestration, such as Rundeck, can make our lives easier. Take software deployment as an example. A well-run IT shop will have automated both the building of its software using tools like make, Ant, and Maven and the configuration of the hosts the software runs on with CFEngine, Chef, or Puppet (see the post “Don’t Install Software by Hand”). Furthermore, version control tools and continuous integration will manage the software and the configuration recipes, handling developer contributions, reviews, traceability, branches, logging, and sophisticated workflows. However, these tools still leave a gap between the software that has been built and is ready to deploy, and the server that has been configured with the appropriate components and libraries and is ready to run the software.
Continue reading "Service Orchestration with Rundeck"
Developing in the Cloud
Running a top-notch software development organization used to be a capital-intensive endeavor, requiring significant technical and organizational resources, all managed through layers of bureaucracy. Not anymore. First, many of the pricey systems and tools that we developers need to work effectively are usually available for free as open source software. More importantly, cheap, cloud-based offerings do away with the setup, maintenance, and user support costs and complexity associated with running these systems. Here are just a few of the services and providers that any developer group can easily tap into
(you can find many more listed here):
Continue reading "Developing in the Cloud"
In the 1920s, the Ford Motor Company embarked on an ill-fated attempt to establish an industrial town in an Amazon rainforest as a way to secure a cultivated rubber supply for its cars’ wheels. At the time, it already owned ore mines, forests, and a steel foundry to produce the raw materials for its cars; today, it buys from external suppliers, even its cars’ electronic control units. How do these two phases of the automotive industry’s history relate to the way we currently develop and adopt infrastructure in our profession?
Continue reading "Bespoke Infrastructures"
The Birth of Standard Error
Earlier today Stephen Johnson, in a mailing list run by the
The Unix Heritage Society,
described the birth of the standard error concept:
the idea that a program's error output is sent on a channel
different from that of its normal output.
Over the past forty years, all major operating systems and language libraries
have embraced this concept.
Continue reading "The Birth of Standard Error"
The Frictionless Development Environment Scorecard
The environment we work in as developers can make a tremendous difference on our productivity and well-being. I’ve often seen myself get trapped in an unproductive setup through a combination of inertia, sloth, and entropy. Sometimes I put-off investing in new, better tools, at other times I avoid the work required to automate a time-consuming process, and, also, as time goes by, changes in my environment blunt the edge of my setup. I thus occasionally enter into a state where my productivity suffers death by a thousand cuts. I’ve also seen the same situation when working with colleagues: cases where to achieve a simple task they waste considerable time and energy jumping through multiple hoops.
Continue reading "The Frictionless Development Environment Scorecard"
A Better Air Gap
Bruce Schneier recently published
ten rules for setting up an air-gapped computer;
a computer that even the NSA can't hack,
because it's not connected to the internet.
His rules are practical and make sense, but,
given the number of vulnerabilities regularly found in modern operating systems,
I think that they need strengthening.
Continue reading "A Better Air Gap"
If estimating the time needed for implementing some software is difficult, coming up with a figure for the time required to debug it is nigh on impossible. Bugs can lurk in the most obscure corners of the system, or even in the crevices of third-party libraries and components. Ask some developers for a time estimate, and don’t be surprised if an experienced one snaps back, “I’ve found the bug when I’ve found the bug.” Thankfully, there are some tools that allow methodical debugging, thereby giving you a sense of progress and a visible target. A method I’ve come to appreciate over the past few months is differential debugging. Under it, you compare a known good system with the buggy one, working toward the problem source.
Continue reading "Differential Debugging"
Portability: Goodies vs. the hair shirt
“I don’t know what the language of the year 2000 will look like, but I know it will be called Fortran”
— Tony Hoare
Writing code that can run on any platform used to be a golden standard, as attested by the tens of books with the word “portable” in their title. Every day however staying true to the faith of portable code is becoming more challenging as mighty ecosystems amass resources to tempt us into their platform-specific version of heaven. We can write non-portable code out of laziness or ignorance, because we can’t be bothered to verify or check that our code follows a standard. We can also decide to write non-portable code following a pragmatic cost-benefit analysis. Let’s follow this approach and examine portability as a tool, looking at what we gain through it, the price we pay for it, and how we can cope with the challenge of upholding it.
Continue reading "Portability: Goodies vs. the hair shirt"