Software Beyond Code

A project with a portable codebase means that it can be built to target different platforms and offer its functionality on various systems. When code is referred to as “portable”, it can imply different things. For example: It may not explicitly use platform-specific functions or libraries It may abstract away platform specificities and use these abstractions in most of its codebase It may be implemented in a high-level language that intrinsically provides platform abstractions Regardless of the strategy employed, some abstraction exist over platform-specific services, concepts and data structures. In any case, when building the project’s codebase, one is transforming the code into a format that will be allowed to run on the target machine. This article is the second in a series of posts that will dive into the development environment of a cross-platform project. This time, we will look into the process of building a cross-platform project by identifying the different possibi...

When working on a new cross-platform project, one has many choices to make. When you select a compiled programming language such as C/C++, you have to pick the appropriate toolchain for each target platforms and their supported architecture. Then comes a crucial decision: what will your development environment be? This is the first in a series of posts that will dive into the development environment of a cross-platform project. Through this series, we will look at: Project generation, which allows to define source and library dependencies and produces a project setup that can be compiled and linked into our executable or library; Integrated Developement Environement (IDE), which allows to edit source code and run it. Debugging environment, which is required to have the IDE properly debug all your code and external libraries you may use. Project Generation In a common single-platform product, creating a project might involve simply opening up a fitting IDE and creating a new...

tl;dr: Gak is a terminal tool used along-side Git to automate product and workflow specific tasks that are not only Git-related, such as building and navigating to product folders. It enhances on Git to provide interactive wildcard-based switching of branches and provides commands for JIRA that allows to start work on an issue, log time and commit with a pre-formatted message header acquired from the issue’s information. It is extensible by the mean of one Python file per sub-command and is configurable on a per-repo and per-user basis. The modern developer has access to many tools and IDEs that claim to simplify your development time and make the tough stuff simpler: manage your compiling toolchain, assist you in coding and abstract your source control. While software like Visual Studio Code and IntelliJ family of IDEs offer these helpers, I could not find myself to boot them up each time for doing what I wanted to do, especially in cases where the project files ...

The method described in this entry is simple to apply and is flexible enough to accommodate a fast-paced, challenge-oriented learning approach. Because a paper needs to be read every single day, qualities necessary to successfully apply it are diligence and perseverance. I thought of sharing this approach because it might be useful to computer science and engineering researchers who find that the traditional "waterfall" approach to research is not flexible and fast enough. After all, there is no unique approach to acquiring and producing knowledge and finding the right one for a given situation remains a challenge.   When I started researching on new ways to build modern software for my MSc thesis, I was overwhelmed by the quantity of knowledge to probe and wasn't exactly sure what subject I would focus on. Many students are encouraged to dedicate a period of time to gather knowledge from literature and assimilate concepts before choosing a subject, needless to say bef...

In my previous post , I made the case that developer documentation was useful and that it could be easily done with LaTeX, given some basic structure. Although LaTeX has the same advantages as any code because of its abstraction from the final document, it also has its downfalls. Probably the most repulsing to newcomers is the lack of feedback over what the document looks like in its final form. There exist a couple of tools such as TexMaker , but I found that taking the road to create my own editor-like environment has been more simple and has given me more control over what I wanted to do: write developer documentation. This short entry will try to show how easy it is to integrate LaTeX editing with feedback with remotely any editor using the structure already presented. The right things at the right place One thing TexMaker and the likes does well is to provide a preview of your document in a secondary panel. One thing it doesn't really do is... well everything not LaTeX. Wh...

Developer documentation in software projects In many projects and prototypes, documentation in text form is a simple way to easily understand some basics of a project and to start off development by explaining key design choices and concepts. There are many ways to provide such documentation, but often a README plain text file is provided. Such plain text might not effectively allow be the most straightforward communication mean; we all know that an image is worth a thousand words. Schemas, UML diagrams, formatted code snippets, color, and other more advanced mediums and media content cannot be easily added and is impossible to present in a concise way. Another way is to use formats such as Microsoft Word or LibreOffice documents. This is probably one of the most convenient way to include additional formatting and content, but strongly lack in the area of versioning where changes cannot be dealt with in a similar way to code. Developers used to version control in software projects ca...