Dependency inversion

The D in SOLID stands for dependency inversion. It’s a simple, but powerful principle that allows to change the direction of dependencies within software and often enables the generalization of a concept, by depending on abstraction.

What I like most about the principle is that it can be used to structure and guide the architecture of the modules and components of a software system on a high level, but not also that, it can also be implemented through various software design patterns on the lower level.

Classes, Modules, Components…

%%{init: {'theme':'neutral'}}%% classDiagram direction LR namespace Component1 { class ModuleA class ModuleB } namespace ModuleB { class B } namespace ModuleA { class A1 class A2 } A1 <|-- A2 B <-- A1 namespace Component2 { class ModuleC } namespace ModuleC { class C } C --> B

Relationships, and therefore dependencies exist on various levels of granularity: Classes and functions make up modules and modules form components. As we can see, the relationships of the classes also define the relationship of the higher-level constructs.

Read More

Parallelism and concurrency in different languages

Parallelism and concurrency In September 2022, Nvidia CEO Jensen Huang declared Moore’s Law dead, while Intel CEO Pat Gelsinger said it was still alive. This highlights the disagreement even among industry leaders. Preemptive and cooperative multitasking Multitasking enables concurrency between processes by time-sharing i.e. a single CPU core. There are two main strategies to achieve that: Preemptive multitasking is usually used in most modern OS. A scheduler determines which process should execute next and uses an interrupt meachnism to suspend currently running processes.

Read More

Building and testing R packages with latest R-Devel

If you want to submit your R package to CRAN, you need to ensure that all R checks will be executed successfully without a warning for the current and the devel version of R.

Not only that but as a package maintainer, you also need to ensure that your submitted packages will still work with upcoming R versions. If you are using native code in your package which needs compilation (e.g. C/C++), the whole process is even getting more complex, since you need to ensure that the compilation of the code works on different systems (debian, fedora, windows (32 and 64 bit), solaris (sic), and osx) and with different compilers (gcc, clang).

But, for the moment let’s focus on setting up an environment to check your package against the latest R-Devel version to be able to reproduce and resolve issues.

Read More

R package naming conventions

Naming something in general, and especially in R, can be quite tricky because there seems to be no real consensus about naming conventions for packages and functions. Since I am currently in the process of releasing an R package, I wanted to get more recent data about the usage of different naming styles for R packages and package functions. I hypothesized that the users most probably are familiar with the naming conventions that are used by the most downloaded R packages and therefore it might make sense to adopt these naming styles.

For my small analysis project, I distinguished between the following naming styles:

  • lowercase (lc)
  • UPPERCASE (UC)
  • lowerCamelCase (lCC)
  • UpperCamelCase (UCC)
  • name_with_underscores (us / snake_case)
  • name.with.dots (dot)

Read More