Base Programming Tools: Introduction


Back to the base tools section.

Video section

Alternative video links:

Why this topic for the start?

I have many ideas on materials; much too many to mention them here. So I decided to group them all into some categories, or cycles. The first cycle is about base programming tools, used in software development process. It’s practical knowledge, essential to start serious programming, as it is (should be) done in real IT companies.

Why this particular topic, someone could ask? Well, this knowledge is both essential (for practical usage), and almost completely ignored in higher technical education. The reasons for this situation are complex, and out of scope of this text. I have observed many students, who were eager to learn programming languages, various techniques, to explore interesting ideas, to gain some experience, or to create some interesting project, and had almost no awareness of the tools I’m going to talk about. During their classes, such tools were not used (I wonder, whether they were mentioned at all).

In real IT companies, such tools are used, and young people are expected to either know them, or to learn them quite fast. On the other hand, if such base tools are not used in real software development, I would strongly advise anyone to avoid such company, regardless of being their intern, employee, or client.

What tools are actually used in software development?

Basing on my own experience, one of the essential tools in development is a (not quite so) simple text editor. A good editor for programmers is Vim (yet it may be regarded as a choice for more advanced users), or Atom (probably much more modern-looking). I think, that IDEs (Integrated Development Environments) are also used very often, although I don’t use them at all. IDEs are supposed to manage the whole environment, needed to perform all development tasks, like source code edition, software building (and running), probably also source version control.

There are many tools, which come with various programming languages. Such tools are often specific for their languages: compilers, interpreters, and virtual machines (VMs):

  • both Python and PHP have their own interpreters,
  • programming languages, like C, C++, Java or Haskell, are compiled,
  • the compiled code for Java, and Erlang, is run on their own VMs.

Since we live in XXI century (although sometimes it may be hard to believe that fact), developers also need tools to manage packages (libraries). Once again: such tools are often language-specific (or platform-specific). Node.js comes with npm (though one can also use yarn for the same purpose). For Python, pip can be used, and for PHP I use composer. (One additional remark here: if a language has no such tool, do not use it. Unless the language is C, or C++. Or you want to be a pioneer.)

Most interpreters simply read the source code, and then run it (although there are exceptions). For compilers, though, code has to be compiled first. Usually source code consists of many files, placed in various directories. The compile (build) process for such projects can be quite complex. For this reason, some specific tools, build systems, are used.

There are also other tools, which may be used: preprocessors (to process the source code, before it is compiled), resource managers (to process various resources, like images), and others. I’m sure this list is not complete, and I’m even not try to make it so.

The next, big group (or category) of tools are control version systems (like git, mercurial or SVN). They are so crucial to development, as accounting for business, or logs for processes.

BTW, I think that sofware testing is still regarded something inferior to the real development work. This (so called) thesis of mine can be easily verified: just check the wages of software developers, and compare them to wages of software testers. And it’s a real shame.

As for devops, it’s something on the edge of programming (software development), and system administration. Software uses various operating system services (like databases, logging, messaging), and even when is tested in complete isolation (so-called unit testing), it is supposed to work in a complex environment. That’s the place, where devops comes to the scene.

Besides of those tools, there are also other topics, very important in software development. I believe the most important one is data. The vast majority of software uses data, produces data, processes it, and so on. It leads to many problems: what is data structure, how this structure should be designed, for particular problem, how to manage data, and so on. There are too many problems, to even list them all here.

What is the problem, actually?

As I observed, most of my students had problems with some of those topics.

They were quite often complete newbies to any package management tools. Those tools are quite easy to learn, though. Besides, there are many tutorials, where package managers are presented. Any modern programming language, that can be used in production, comes with such tools, and they are often well documented. This problem can be easily solved by reading documentation, tutorials, or studying other materials. I see no point in making my own one.

Another area, where my students lacked knowledge (and experience), were build systems. The idea of build system is quite simple, in fact: there are some tasks, which should be performed, in some particular order, to build software. The build system’s task is to find out, which tasks should be performed, find out the correct order of their execution, and then to just perform them. Nothing complex (in theory). I have written many build-scripts by hand, especially for my LaTeX-based projects, where also some specific (yet quite simple) text processing was required.

However, this topic, although essential, is also very specific. On one hand, such systems are often language- or platform-specific. For Node.js, npm, yarn, or gulp can be used. All those tools are able to perform all tasks, needed to build an application, which is then supposed to run on Node.js platform. Yet it would be very unusual to use any of those tools, for software meant to be run outside of Node.js. The same can be written about Java-specific build systems.

On the other hand, sometimes building software needs some very specific features. In such cases, there are also some general build systems. They are so general, that their usage is some niche.

I don’t want to focus either on language-specific tools, or on general, but also niche tools. I’d like to give you both general, and practical knowledge, that can be applied to almost every development case, and used in almost every project. That’s why I decided to skip this topic.

I also believe, that students know nothing (or next to nothing) about automated software testing. (In fact, I’m afraid that also many real-life developers know too little about it.) As I have already written, this topic is quite often regarded as less important to software development. I think it’s wrong, very wrong. This topic, though, is very general, and can be discussed without focus on any particular language, or platform, or tool.

The mentioned devops topic, although belonging more to system administration, than software development, is also quite often neglected by students. One of the reasons (that’s my guess only, not some research result) is probably widespread use of IDEs, which take care of this from developers. I do not IDEs by myself, so I’m not an expert in this area, yet I don’t suppose that IDEs take care of everything, every acpect that developers should know about, and thus there’s still room to learn something. I observed my students to eventually cope with it, yet many of them had little, or none at all, knowledge in this area. And, what is also worth to mention, they were often not very keen to learn it. That’s something I can understand: you want to be a software developer, you want to code, to implement algorithms, to solve problems, not to handle system administration tasks. But those tasks don’t vanish, simply because you don’t like them. You have to know something about the operating system, that the software you work on is supposed to run on.

Finally, when it comes to data, the topic is definitelly too broad, and deserves a separate lecture series on its own. Yet, I’d like to focus on one, particular area, that many students have minimal knowledge of: databases.

For most students, probably, the knowledge on databases comes from university classes and courses. The tasks they perform are quite simple: design a database, tables, insert some data, and then query data. It all ends with a report, that is graded by supervisor. When you work on a simple project (and most projects for students are simple), database may seem to be a burden. That’s probably a reason, why database knowledge among students is so rare.

(Personally, I can tell you, that I had been avoiding this topic for many years. Then, when I finally decided to learn something about databases, for years I had been making some mistakes, that I’d love to share with you (so you won’t make them also). Just two, or three years ago, I decided to go the way I’m still going. I’d like to tell you about it. I’d like to explain, why databases are crucial for software (and for software development). I’d like to show you, why you shouldn’t avoid this topic, what you should learn, and what you should avoid, in order to keep youselves out of problems. I won’t make you database expert (I’m not one myself), but I can guide you a little, so you won’t be completely blind.)

To sum it up, there are, at least, three such tools, that I’d like to tell you about: Docker, (automated) software testing, and databases.

Are those topics worth your precious time?

Now, I’m going to say something to encourage you to watch the incoming videos.

Well, to be honest, if I was told about such materials twenty (or twenty five, I’m getting older and older) years ago, I wouldn’t probably have even listened to it. I wanted to be a programmer, I wanted to develop software, I wanted to learn new programming languages, paradigms and techniques. Putting Docker aside (twenty years ago there were no such tools, and those, which were available, were much more difficult to use, and much less efficient), I was never interested in databases, nor in software testing. Then, I had found both the topics dull and uninteresting.

So, I simply ignored those topics, and I learned programming, new languages and new paradigms. Without going into details, I can say right now, that I had experienced many, many failures. And most of those failures could’ve been avoided, had I been testing my software properly. That’s the reason, why I find software testing so important topic.

And when it comes to databases, the truth is you have only two choices: either you can use some database to manage your application’s data, or you can (re)invent one on your own. Think about it: what is a better idea, to apply in a real-life solution? Use a database, that has been developed for many years (or even decades), or to make one by yourself, with limited time for a project? That’s why knowledge on databases is crucial for every software developer. And, believe me, that this knowledge is still very limited, as I can say by my experience and research.