Choosing the proper development tools is a critical decision that directly affects the quality of the resulting code. The factors that bring to the final choice are depend on different (and often subjective) requirements: this in turn means that different technologies can result in software of similar quality. The most important thing is being aware of the alternatives (or of a subset of them) to make a choice that does not depend too much on the current trend or on a choice made by others.
The operating systems used for every day job are mainly POSIX based, specifically Archlinux and Xubuntu GNU/Linux distro or FreeBSD. Although using Microsoft Windows would seem the most obvious choice to non-developers, it should be noted the software developed by eNTiDi is usually not desktop related, but it is web based or embedded, and in those sectors Windows is the tool car. Furthermore, almost all the projects chosen as dependency (GTK+ above all) are primarily developed on GNU/Linux systems, hence likely to have less problems on those platforms. FreeBSD is mainly used to be sure the code produced is portable to at least another POSIX system.
When the application is required to run on Windows system, the project is still developed and tested on the usual platforms (where the known environment and tools reside) and the code is cross-compiled for Windows at the end of the development process. For this purpose the port to Archlinux of the MingW toolchain by the Fedora community is actively maintained.
Having to switch from C sources to HTML code, passing through CSS, PHP, Lua and sometimes other programming languages, a general purpose editor seemed the most obvious choice. Vim has been chosen that, with reference to the conventional IDEs, brings the following advantages:
- extremely powerful and customizable;
- backed up by a strong community with a high ratio of power users;
- an almost unlimited park of extensions from which pick up the preferred ones to customize your editing environment;
- multiplatform and ubiquitous: Vim or one of its stripped down versions is basically preinstalled on every GNU/Linux distro;
- available in graphical (GTK+ based) and text versions, that is it can be used on SSH sessions.
Its hystorical alternative, GNU emacs, would be another viable choice.
The produced code is usually archived through git, a powerful and flexible source control management system. Git is a distributed system, that is you can have local repositories, you can have more than one repository for the same project and you can synchronize the content between them in arbitrary ways. git is strongly oriented to horizontal development, that is promotes branching and merging against linear development (still supported).
git, like every other revision control system, expects the code to be text based. This means images and binary files are not properly handled, stripping down the power of git to a back up utility. LabVIEW programs fall into this category: regardless of what National Instruments says, there is no decent integration with any revision control system, making branching and merging an exercise of pain.
Whenever possible the software is coded in C using the object oriented paradigm provided by the GObject library (yes, object oriented in C is possible). This approach leaves the door opened to the reuse of the code with other programming languages by implementing only the missing glue between the original C code and the new language (the so called language bindings).
Recently the GObject introspection project has been introduced by the GNOME community to make the development of language bindings easier (if not automatic). For instance, PyGObject (for the Python language) and LGI (for the Lua language) provide automatic bindings, that is if you have installed one of that projects and the library you need has proper support for GObject introspection you can use it from the supported language.
Projects that need more interaction (hence not suitable for C coding because of the code, compile and debug roundtrip) are usually developed in Lua. That is a little pretty language that mixes very well with C. Its canonical implementation (PUC Lua) is an interpreter that provides good interactivity. Furthermore, for time critical works, there is an alternative implementation that is compiled just-in-time (LuaJIT) with stellar performances and it has an integrated FFI interface for easier C interaction.