Unity ECS ist ein Aspekt des sogenannten DOTS (Data oriented technology stack) den Unity seit einigen Jahren verfolgt. DOTS ist ein Set von Technologien die zusammen das Erstellen von performance-intensiveren Spielen als mit den traditionellen objektorientierten Technologien erlauben. Konkret fokussiert sich DOTS, wie der Name beschreibt, auf datenorientiertes Programmieren, mit einem weiteren Fokus auf Parallelisierung und low-level Optimierungen, wie beispielsweise SIMD.

ECS, oder „Entity-component-system“, ist eine datenorientierte Software-architektur, die oft in Spielen zu Einsatz kommt. Nicht nur gibt es ECS schon einige Jahre, es gab sogar schon für Unity verschiedenste third-party ECS-Frameworks. Sein 2018 arbeitet Unity aber auch an ihrem eigenen inhouse Framework, welches Anfang 2023 endlich in 1.0.0 ging. Eine kurze Beschreibung über wie die ECS-Architektur funktioniert, folgt später.

ECS bietet an Vorteilen zunächst Performance-verbesserungen (Mehrere tausende simulierte Entities auch auf schwächerer Hardware mit guten FPS möglich), wobei das nicht der Hauptgrund ist warum ich es lernen wollte. Primär geht mit ECS eine komplett neue Art über Spiele und den Code nachzudenken einher die ich gerne kennenlernen wollte. Nachdem ich mich nun einige Monate damit beschäftigt habe, kann ich sagen, dass ich den ECS-Workflow sehr schätze und mir teilweise sogar schwer tue wieder zu normalem OO MonoBehaviour Code zurückzukommen.

Das Petridish Projekt

Ich habe überlegt, was ein gutes Projekt wäre, um mich mit ECS auseinander zu setzen und habe nach einigen Tests eine Idee von vor einigen Jahren wiederbelebt. Damals habe ich mich mit simulierten Bakterien und deren Evolution gespielt und dachte mir, dass das ein guter Kandidat für ECS mit der verbesserten Performance wäre.

In Petridish gibt es Blobs, das sind die runden Tierchen, die herumflitzen. Blobs müssen Energie zu sich nehmen, um zu überleben. Sie können dazu Nutrients essen, also die sechseckigen Stückchen, die verteilt sind. Fast alles, dass die Blobs tun, kostet sie auch Energie, beispielsweise bewegen oder sehen.

Verschiedene Blobs haben verschiedene Gene, die beispielsweise kontrollieren, wieviel Energie sie pro Sekunde nutzen, wieviel sie von dieser Energie für Bewegen benutzen oder wie groß sie sind. Alle diese Eigenschaften haben vor und Nachteile und es ist Ziel der Simulation eine optimale Spezies zu finden. Wenn Blobs genug Energie aufgenommen haben klonen sie sich, wobei der Nachwuchs immer eine kleine Mutation hat. Somit sind die Voraussetzungen für Evolution gegeben.

Ein grober Überblick über ECS

Die ECS-Architektur ist in drei Teile aufgeteilt. Entities, Components und Systems.

Entities sind alle „Dinge“, die im Spiel vorkommen. Entities selber haben keine Eigenschaften, sie sind nur dazu da Components zu beinhalten. Der einfachste Vergleich ist zu Unitys GameObjects, aber im Unterschied zu ihnen muss ein Entity nicht zwingend etwas sein, das „im Raum ist“. Abstrakte Daten die „nirgendwo“ sind können auch auf Entities untergebracht sein. In Petridish gibt es einige Arten von Entities, beispielsweise Blobs, Nutrients und verschiedene Daten-entities.

Components sind mit Entities assoziiert und beinhalten die Daten, die das Entity zu der Sache machen, die es sein soll. Beispielsweise haben Entities die Blobs sein sollen Components die ihre Position im Raum, ihre verbleibende Energie, ihre Gene und andere Daten beinhalten. Im Gegensatz zu OO Unity Components, haben ECS Components keine Methoden; können also nichts „tun“. Das ist die Aufgabe von Systems.

Systems beinhalten die tatsächliche Spiel-logik. Üblicherweise ist ein System durch eine Update Funktion definiert, die jedes Frame läuft und die Daten auf relevanten Entities updatet. Dazu definieren Systems an welchen Components sie interessiert sind und das ECS-Framework liefert diese für die Update Funktion. In Petridish gibt es beispielsweise ein „MoveTowardsTargetSystem“, dass jedes Frame alle Entities findet die eine Position im Raum haben und eine Ziel-position hinterlegt haben und bewegt dann diese Entities näher an ihr Ziel, indem sie ihre Positionen updatet.

Das ist nur ein extrem verkürzter Überblick über die Architektur, aber es gibt sehr gute Ressourcen zu dem Thema online, falls man mehr lernen will.

Learnings und Hürden

Ich bin sehr froh mich mit ECS beschäftigt zu haben. Der datenorientierte Workflow gefällt mir sehr gut und ich freue mich darauf mehr damit zu arbeiten. Besonders im Bereich Performance-optimierungen habe ich sehr viel gelernt. In ECS ist es viel üblicher sich mit den lower-level Features von C# auseinanderzusetzen, mit denen ich bis jetzt noch nichts zu tun hatte.

Mit Petridish bin ich auch recht zufrieden, wobei ich sagen muss, dass es nicht so performant ist wie es vermutlich sein könnte. Das Hauptproblem ist die Logik, die berechnet was ein Blob sehen kann, da ich noch nicht sehr erfahren damit bin welche Datenstrukturen für ein effizientes spatial lookup am besten sind. Aber ich bin gespannt darauf, ob ich darüber in zukünftigen Projekten noch etwas lernen kann.

The post Evolution Simulation in Unity ECS appeared first on Mobile USTP MKL.

We all know the eCampus and most of us don’t like it. It’s clunky, it’s not responsive, it sometimes has too much and sometimes not enough information and let’s be real, most of it does not look great either.

As this semesters project I attempted to create a Chrome browser-extension, called “better eCampus”, which attempts to solve some of the platform’s problems. I must say up front, that I’m not a big design guy, so this article is not so much about how I improved the eCampus’ visuals or UX because, frankly, I’m not yet sure I did. I would rather tell you about how I developed the extension, how it works and how you can contribute if you want.

My development journey

My idea of what this extension should be went through a few phases and I’m still not where I want to be. In the following sections I want to tell you about the chapters of the development story so far.

Change the CSS

When I started developing better eCampus, my goal was to simply mess with the pages CSS a little bit. This is quite easily done, using the Chrome extension API, as you can simply inject custom stylesheets, so, as a starting point, I added a very basic dark-mode overhaul, which looked like this.

My work in this consisted mostly of looking over the eCampus’ own stylesheet (which is a single, over 40000 lines long, file btw.) and overriding relevant stylings in my own sheet while always using the !important directive.

This continued for a few weeks, but I soon realized that a lot of the eCampus’ problems, aren’t simple related to its style but also structure. For example, in the screenshot above, you will probably see quite a few features and information which you have never or at least barely used. My next step was to figure out a way to hide these features unless the user needs them and that meant editing the pages html.

Change the HTML

Editing the pages HTML was also quite easy. Chrome extensions allow you to run scripts once the page loads and so I started writing code that would move elements around, delete others, add or remove CSS classes and simplify the pages quite convoluted DOM.

While possible, this soon got very tiering and once it became time to add new content to the page it became even more difficult. I started to wonder if, instead of trying to carve out a better version out of the existing eCampus, maybe it was time to just ditch it altogether and replace it as a hole.

Replacing the page

Replacing the whole DOM of a page is not something you usually do, but after a while I found a, admittedly a little bit hacky, way to do it. I now was completely free to change the pages content as I wished. The next roadblock was to extract information from the original page which I wanted to display on my replacement and somehow moving it over.

The way I achieved this at this stage was to create a function called an “extractor” which would find data in the original DOM and then passing it to an “injector” which would write it into placeholders in the new DOM.

This worked, for a while, but again, as the types and amount of data I had to transfer changed, the extract and inject process became clunky and slow to develop. I especially ran into trouble with reusing components, such as the navigation you see above, on multiple pages. At this point I was just about done trying to create a nice-looking website in plain JS and my thoughts wandered longingly to my Vue development days of the previous semester. It was then that I realized I wanted to try and use the Vue-framework to develop my replacement pages.

A new Vue

Bringing Vue into the extension was a little bit tricky but I ultimately succeeded. I build the pages with Vue and compile them into HTML and JS files. I can then replace the original page with these new pages. The part that gave me trouble the longest was figuring out how to pass the previously extracted data into the Vue app. The solution I finally discovered is not very elegant, but it works for now. You can see it below:

// In my injected script
const data = scraper(document.documentElement);
if (data) {
  document.replaceChild(
    overrideDoc.documentElement,
    document.documentElement
  );
  document
    .querySelector("#app")
    .setAttribute("scan-data", JSON.stringify(data));
} else console.error("Could not scan data!");

// In my Vue app
const app = document.querySelector("#app");
this.scanData = JSON.parse(app.getAttribute("scan-data"));
app.removeAttribute("scan-data");

Essentially, after replacing the DOM, I find the Vue-apps root div and simply write the extracted (or scraped, or scanned, I used a few different terms) data to it as an HTML-attribute. On the Vue-side I read the data from the attribute and clear it. And yes, that means that for a moment, the pages HTML looks like this:

And that works. I was now able to read data from every page and create a replacement page for it in Vue which could display the same data. This could have been the end, but alas, I had more plans.

The problem was that, as already said, I could only display data on every page that was already on the original page. Also, I could not really add new pages or remove existing ones. My extension at this point only worked to replace exiting pages. This limits me a lot in how I can design the pages and how much better the better eCampus could really become. This brings us to my current and hopefully final phase for a while.

eCampusAPI

For those who don’t know, the eCampus runs on PHP or at least some other server-side-rendering technology. HTML is constructed by the server and send to me at which point I painfully have to parse out the data that’s embedded somewhere in the page. In contrast to most modern platforms, the eCampus has no easily accessible REST API. So, I can’t simply send a GET to “/courses” or something similar to get all my courses. But you know what they say about programmers: if it does now work, make your own.

As such I am currently working about my own server, which sits between the user and the actual eCampus and works as a middleman. You will be able to use a publicly documented REST API against this server to interact with the eCampus though it. Granted, this server still has to receive the whole HTML pages from eCampus and parse data from that, so it’s definitely not as fast as if the eCampus had an API to begin with, but it’s something.

Once I have completed a rudimentary version of the eCampusAPI server I will be able to rewrite the extension to work more like a normal web-app, interacting with a remote server through rest. That is quite a bit in the future at this point, but I think it should work.

Want to help?

While I am currently not looking for co-developers you can still help me by trying out the extension and server and giving me feedback (especially when it comes to the design). You can check out the repo of the extension itself here and for the API server here. You can also keep up to date there when I release new usable versions.

Thanks for reading, I’ll end with a few images showing what I have so far.

The post better eCampus appeared first on Mobile USTP MKL.

It is often said, that programming is simply a form of applied mathematics and so it is no surprise that many concepts usually used in the field of mathematics, such as variables, functions or algebra are also found in various programming languages.

One area of mathematics which is integral to many programming languages, especially the more functional ones, is set-theory. In this article I will briefly describe what set-theory is and how to apply it to programming.

Sets and their theory

First, I will give a brief rundown of what a set it and what operations can be performed on it.

In mathematics, a set is a group of distinct items. As an example, { 1 2 3 } is a set containing, three numbers. Sets must be distinct so this set { 1 2 3 1 } is equivalent to the first one, as duplicates are simply removed.

While in mathematics sets are often numbers, such as the set of all real numbers R, sets may contain all sorts of things. For example, I could create a set of all lakes inside Austria, or a set of all words that start with the letter “b”.

Sets may be defined in a few different ways. The most straight forward one is to simply list all elements, such as in { a b c }. This may however be unpractical or even impossible for large or infinite sets. In these cases, sets may also be defined using rules which must be satisfied by all members. As an example, I could define a set of all people who are younger than 20 years.

Notice that when defining a set using a rule, this often takes the form of defining a sub-set of an existing set which satisfy the condition. A sub-set is a set in which all items are also contained inside some parent set. For example, the set of all pugs is a sub-set of the set of all dogs. This shows us one of the most important operations which may be performed on sets, which is filtering, or creating a new set by taking some subset of an existing set.

The next operation I want to touch on is mapping. Mapping takes each element in a set and transforms it in a consistent way to create another set. As an example, I may take a set of cars and map it by taking the color of each car. This will create a new set of colors. Notice that if multiple cars had the same color, they will be collapsed, as a set may only contain distinct elements.

Sets may also be merged, also called forming a union, which takes all elements of both sets to create a new one. In a similar vein, you may take the intersection of two sets, or all elements which exist in both sets.

How sets relate to programming

Though it may not be immediately obvious, types in modern programming languages are essentially sets. I will use TypeScript as an example, but feel free to find parallels in your programming language of choice. Consider the following line.

let x: number = 5

Here I declare a variable of the type number. Let’s think about what number means in this context. It denotes a set of all possible values which are considered a number in TypeScript and as luck would have it, 5 is an element of that set.

let x: string = 5

In contrast, this line does not work, as 5 is not an element in the set of all possible strings. More interesting parallels can be found when declaring custom types. For example, the following.

type stringOrNumber = string | number

In this line, I declare a new type and as such a new set. In this case I form the union of all strings and all numbers. As such all elements which are either a string or number are also in the set stringOrNumber. We call this adding the two types, because, if there are x possible strings and y possible numbers than this set will have x + y possible values.

type stringAndNumber = {
    s: string
    n: number
}

This in contrast, is a multiplied type. Let’s imagine that there were only 3 possible strings, “a”, “b” and “c” and only two possible numbers 1 and 2. In that case all possible values of this set would be:

• { s: “a”, n: 1 }
• { s: “b”, n: 1 }
• { s: “c”, n: 1 }
• { s: “a”, n: 2 }
• { s: “b”, n: 2 }
• { s: “c”, n: 2 }

Here we can see that what we typically call “Objects” are simply the sets of all their properties multiplied. In this case x strings * y numbers for x * y possibilities.

Next, we will look at functions, which essentially mirror the operations which I have previously described. Specifically, they are usually mapping functions. Here are a few examples.

// number -> number
function inc(x: number) {
    return x + 1
}

// Person -> name
function getName(person: Person) {
    return person.name
}

// T -> T[]
function singletonArray<T>(thing: T) {
    return [thing]
}

As you can see, all of these functions take an element of one set and convert it to an element of another one. In the case of the first function the result-set is the same as the start-set. We can also view these functions as being mappings from one set to another, as you can put any element of one set into them and receive an element of another, and so if you would send all elements of the first set through the function you would receive the whole other set.

Conclusion

This very mathematical way of thinking about types can be very useful in a few, admittedly somewhat niche situations, such as in property-based testing or when designing new programming languages. However, I will also say, that it has been useful to me in everyday programming. This quite specific angle of looking at your types and problem-domain in general, has often helped me to see connections and possible solutions that otherwise would have maybe escaped me. I hope, that by simply knowing about sets now, you may also see these connections in your projects, and that it may be helpful to you.

The post Set-theory in programming appeared first on Mobile USTP MKL.

Abstract

Since their invention in the 50s and today code compilers have undergone a long history of development. This paper will give a brief summary on how compilers work and an overview of the current state of research. From there topics of interest and future research directions will be shown.

Introduction

Computers naturally can only execute sequences of instructions in order to accomplish tasks and compute results. However, specifying algorithms and programs as an imperative sequence in this way is not intuitive for humans and thus required a lot of effort on the part of software-developers.

A solution to this problem is to write source-code in a more human-friendly format and use an automated process to convert this textual program into the instructions the computer can execute. This process is called compilation and can be performed by a separate program which is thus called a compiler. (Wirth, 2005, p. 6)

The first such compiler was developed by Corrado Böhm for their PhD dissertation which featured a custom programming language as well as the compiler written in that same language. (Böhm, 1954)This compiler was an example of a self-hosting compiler, meaning that it was written in the same language it was designed to compile.

In general, program compilation can be split into the following parts:

1. Lexical analysis: The source-code is read and translated into a sequence of meaningful symbols which make up the text. (Wirth, 2005, p. 6) In the next step, this sequence of symbols or tokens will be used instead of the “raw” text.
2. Syntax analysis: The symbol-sequence is translated (parsed) into a data-form, usually a tree-structure, which more accurately represents the syntactic structure of the program. (Wirth, 2005, pp. 6–7)
3. Verification and optimization: The syntax-tree is now verified to ensure that no detectable errors end up in the compiled code. (Wirth, 2005, p. 6)It can also be optimized in this stage, meaning, its performance or memory-usage improved. (Wirth, 2005, p. 100)
4. Code generation: The verified and optimized source-tree must finally be converted to the desired output-format, usually binary or an assembly-language. (Wirth, 2005, pp. 6–7)The output of the generation phase, may also be source-code of a different programming language, in which case the process is called transpiling instead of compiling.(Parr, 2021)

Research Efforts

There are currently several fields of research in order to improve compilers. The following chapters will give a broad overview.

Parallelism

One of the driving forces in increasing computer performance over the past decades has been increasing the number of transistors which can fit into CPUs. However, since transistors are physical components, adhering to physical rules, there is a minimum size transistors can be built in and thus also a natural limit to performance from transistor-count. (Sutter, 2005)

Increasingly, running multiple CPUs or cores in parallel, will be used in order to increase performance. (Gepner & Kowalik, 2006)It has thus become a goal of compilers to optimize code by generating instructions which can be run in parallel on multiple processors. For this the compiler must analyze the program to detect which calculations are independent and can run detached from one another. (Midkiff, 2012)

Machine learning

An originally niche field which has moved into the mainstream over the past decades is using machine learning algorithms in aiding code optimization. Machine learning may be used to evaluate different optimization heuristics and determine how to best parallelize processes. (Ashouri et al., 2019; Wang & O’Boyle, 2018)

JIT compilation

JIT or “just in time” compilation is a technique of compilation in which the source-code is compiled on the target machine right before being executed, similarly to interpretation. While JIT compilation is not a new concept as detailed by Aycock (Aycock, 2003), there could still be untapped advantages in the technique.

Code compaction

An important field of study is the optimization of generated instructions in minimizing storage space. This is especially important when compiling for devices which only support limited storage capacity. (Debray et al., 2000)

Compilation in small steps

In their book “Functional reactive programming”, Blackheath and Jones propose that compilers of the future should be able to handle more high-level concepts such as, dependency-graphs better in order to allow programmers to work on these higher levels without concerning themselves with the underlying implementation. (Blackheath & Jones, 2016)

Many compilers compile directly from the generated syntax-tree to the desired output-language, which makes it difficult for compiler-developers to smoothly translate these high-level concepts directly to low-level instructions.

There also exist compilers which insert a number of intermediary languages, which aim to “lower” the code down to the low-level language in small steps in order to maximize the possibilities of optimization at each level. (Lattner et al., 2020)

Hardware Compatibility

Many target-devices feature processors with their own proprietary instruction-sets. In order to be able to target different devices, the code-generation algorithms of the compiler must take the target architecture into account. It is therefore an active research field to develop compilers which can target multiple different architectures while not sacrificing compilation or code performance. (Baghdadi et al., 2018)

Conclusion

This short paper gave a brief overview of current research fields regarding code compilation. Important fields include:

• Performance optimization of generated code
• Memory optimization of generated code
• Compatibility
• Better support for high-level concepts
• Incorporation of machine-learning into compilation

References

Ashouri, A. H., Killian, W., Cavazos, J., Palermo, G., & Silvano, C. (2019). A Survey on Compiler Autotuning using Machine Learning. ACM Computing Surveys, 51(5), 1–42. https://doi.org/10.1145/3197978

Aycock, J. (2003). A brief history of just-in-time. ACM Computing Surveys, 35(2), 97–113. https://doi.org/10.1145/857076.857077

Baghdadi, R., Ray, J., Romdhane, M. B., Del Sozzo, E., Akkas, A., Zhang, Y., Suriana, P., Kamil, S., & Amarasinghe, S. (2018). Tiramisu: A Polyhedral Compiler for Expressing Fast and Portable Code. ArXiv:1804.10694 [Cs]. http://arxiv.org/abs/1804.10694

Blackheath, S., & Jones, A. (2016). Functional Reactive Programming. Manning Publications.

Böhm, C. (1954). Calculatrices digitales. Du déchiffrage de formules logico-mathématiques par la machine même dans la conception du programme. Annali di Matematica Pura ed Applicata, 37(1), 175–217. https://doi.org/10.1007/BF02415099

Debray, S. K., Evans, W., Muth, R., & De Sutter, B. (2000). Compiler techniques for code compaction. ACM Transactions on Programming Languages and Systems, 22(2), 378–415. https://doi.org/10.1145/349214.349233

Gepner, P., & Kowalik, M. F. (2006). Multi-Core Processors: New Way to Achieve High System Performance. International Symposium on Parallel Computing in Electrical Engineering (PARELEC’06), 9–13. https://doi.org/10.1109/PARELEC.2006.54

Lattner, C., Amini, M., Bondhugula, U., Cohen, A., Davis, A., Pienaar, J., Riddle, R., Shpeisman, T., Vasilache, N., & Zinenko, O. (2020). MLIR: A Compiler Infrastructure for the End of Moore’s Law. ArXiv:2002.11054 [Cs]. http://arxiv.org/abs/2002.11054

Midkiff, S. P. (2012). Automatic Parallelization: An Overview of Fundamental Compiler Techniques. Synthesis Lectures on Computer Architecture, 7(1), 1–169. https://doi.org/10.2200/S00340ED1V01Y201201CAC019

Parr, K. (2021, January 10). Compiling vs Transpiling. DEV Community. https://dev.to/kealanparr/compiling-vs-transpiling-3h9i

Sutter, H. (2005). The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software. Dr. Dobb’s Journal, 30(3). http://www.gotw.ca/publications/concurrency-ddj.htm

Wang, Z., & O’Boyle, M. (2018). Machine Learning in Compiler Optimisation. ArXiv:1805.03441 [Cs]. http://arxiv.org/abs/1805.03441

Wirth, N. (2005). Compiler Construction. Addison-Wesley.

The post Code compilation – State of the art appeared first on Mobile USTP MKL.

Auf einer sehr abstrakten Ebene ist es das Ziel von allen Computer-programmen mit Daten zu arbeiten; sie zu lesen, verändern und wieder zu speichern oder weiter-zu-geben. Zu diesem Zweck besitzen alle modernen Programmiersprachen das Konzept von Datentypen, also Arten von Daten. Häufige Datentypen beinhalten verschiedene Arten von Zahlen, Wahrheitswerte, Zeichenketten, und Kombinationen von diesen, was oft als Objekte bezeichnet wird.

Über die Zeit hat sich ein System zur Typisierung von Daten entwickelt, dass sich “statische Typisierung” nennt, also, dass eine Speicherzelle, oder Variable, zum Zeitpunkt ihrer Initialisierung festlegen muss, welche Art von Daten in ihr gespeichert werden können. Üblicherweise verbieten IDEs dem Entwickler/Entwicklerin nicht kompatible Daten in eine Variable zu speichern. So können beispielsweise keine Zahlen in deine Variable die für Texte deklariert wurde gespeichert werden.

Hier ist JavaScript anders als der Großteil der gängigen Programmiersprachen. JavaScript ist dynamisch typisiert, es gibt also keine Garantien, dass der Inhalt einer Variable den selben Datentyp beinhaltet mit der sie initialisert worden ist. Tatsächlich haben JavaScript-Variablen überhaupt keine für den Programmierer/Programmiererin lesbare Typ-information.

Die einzige Möglichkeit den Typ einer Variable festzustellen ist ihren Wert zu lesen und mit anderen Werten zu vergleichen. JavaScript ermöglicht es außerdem noch mithilfe des “instanceOf” Operators, den Inhalt einer Variable mit einem der wenigen Datentypen (number, string, …) zu vergleichen um zu erfahren ob es sich bei der Variable um eine Instanz dieses Typs hält.

Obwohl dieses System von dynamischen Typen seine Vorteile hat, führt es in den meisten Fällen zu Fehlern die im Großteil von “Schlampigkeit” des Entwicklers/Entwicklerin stammen, die in anderen Programmiersprachen durch die statische Typisierung sowie Warnungen in der IDE ausgeglichen werden würde. Beispielsweise ist es in JavaScript ohne weiteres möglich einen String in eine Funktion zu schicken die eine Zahl als Input erwartet. Ob daraus Fehler entstehen weiß der Programmierer/Programmiererin erst sobal er/sie den Code ausführt.

Diese Typen-sicherheit ist der JavaScript Community so abgegangen, dass es mittlerweise eine eigene Programmiersprache names TypeScript gibt, die als Superset von JavaScript alle Features der Sprache übernimmt und noch statische Typisierung hinzufügt. Wer aber lieber in standard JavaScript bleiben und trotzdem statische Typisierung nutzen will hat auch Optionen. Beispielsweise JSDoc.

JSDoc und Pseudo-typisierung

JSDoc ist eine Markup-sprache, mit der sich Meta-informationen in JavaScript Code kodieren lassen. Die meisten modernen IDEs können diese Meta-information lesen um den Programmierer/Programmiererin beim Entwickeln zu unterstützen. Ein Beispiel:

/**
 * Das ist der beste String der Welt
 * @type {string}
 */
let s = "wow";

Mithilfe der /** … */ Syntax kann ein JSDoc Kommentar geschrieben werden. Der Kommentar oben beinhaltet eine kurze Beschreibung der Variable und, für uns wichtiger, deklariert auch den Typen der Variable als String. Mithilfe dieses Kommentars können wir nun die IDE informieren, dass die Variable nur Strings als Input akzeptieren soll. Beispielsweise wird für folgende Zeile eine Warnung angezeigt:

/**
 * Das ist der beste String der Welt
 * @type {string}
 */
let s = { text: "wow" }; // Warnung, weil ich ein Objekt in eine "String-variable" speichere

Es ist wichtig zu erwähnen, dass ich auch mit dem Fehler von oben in den meisten IDEs noch komplieren und testen kann. Der Kommentar hat keine Auswirkung auf mein Programm, er deklariert nur klar meine Intentionen und hilft der IDE mich zu warnen, falls ich etwas tue, dass diesen Intentionen widerspricht. Im Folgenden möchte ich nun noch ein paar weitere nützliche Features von JSDoc showcasen. Für mehr Info empfiehlt es sich die offiziele Dokumentation zu besuchen.

Funktions-inputs und Outputs definieren

JSDoc erlaubt es sehr genau zu definieren welche Art von Parametern in eine Funktion geschickt werden “dürfen” und welches Ergebnis daraus produziert wird. Hier ist ein Beispiel:

/**
 * Generiert einen Satz der das Alter "sagt"
 * @param {number} age Das Alter
 * @return {string} Die phrase
 */
function getAgePhrase(age) {
  return `Ich bin ${age} Jahre alt!`;
}

Hier kann ich definieren, dass die Funktion eine Zahl als Input erwartet und einen String zurückliefert. Auch kurze Zusammenfassungen kann ich dazu-schreiben. Es ist wieder wichtig zu erinnern, dass ich auch mit diesem Kommentar immer noch “nicht-kompatible” Daten in die Funktion schicken kann, aber mich die IDE versucht mit einer Warnung davon abzuhalten.

Typ-aliase definieren

Weiters lassen sich mit JSDoc auch Typ-aliase, also alternative Name für existierende Typen definieren. Hier ein Beispiel:

/**
 * Das Alter einer Person
 * @typedef {number} age
 */

/**
 * Generiert einen Satz der das Alter "sagt"
 * @param {age} age Das Alter
 * @return {string} Die phrase
 */
function getAgePhrase(age) {
  return `Ich bin ${age} Jahre alt!`;
}

Mithilfe dieses Aliases kann ich “bestimmten” Zahlen einen besser lesbaren Typ-namen geben. Es sind immernoch nur “normale” Zahlen, nur heißen sie anders. Typ-definitionen wie ich sie hier verwendet habe, können in jedem beliebigen js-File liegen und sind üblicherweise im gesamten Projekt zugänglich.

Eigene Objekt-typen definieren

Ein in meinen Augen besonders nützliches Feature sind eigene Objekt-typen wie beispielsweise dieser hier:

/** 
 * Ein Rechteck mit Länge und Breite
 * @typedef {Object} Rect
 * @property {number} width Die Länge
 * @property {number} height Die Breite
 */ 

Mit diesem Kommentar definiere ich eine “Art von Objekt” ähnlich wie eine Klasse, nur, dass es wirklich nur ein Objekt ist und nicht wie eine Klasse einen Konstruktor, Methoden und so weiter hat. Mit diesem Kommentar kann mich die IDE noch besser unterstützen.

/**
 * @type {Rect}
 */
let rect = { width: 10} // Warnung weil "height" fehlt.

Fazit

Obwohl natürlich JSDoc keine echte Typen-sicherheit gibt wie sie zum Beispiel in TypeScript oder anderen stark typisierten Sprachen vorhanden ist, ist es auf jeden Fall ein step-up, im Vergleich zu dem typenlosen wilden Westen in dem man sich normalerweise mit JavaScript aufhält. Ich würde es jedem Programmierer/Programmierin empfehlen sich einmal damit auseinanderzusetzen.

The post Statische Typisierung in JavaScript mit JSDoc appeared first on Mobile USTP MKL.

Als Neuling beim Gärtnern einzusteigen ist nicht einfach. Es gibt extrem viel zu beachten, von der richtigen Erde, über das korrekte Gießen bis hin zum Düngen und Ernten. Für alle Pflanzen die man zuhause anbauen könnte findet man einiges an Informationen zu all diesen Bereichen im Internet, aber geht es vielleicht auch einfacher als jedes mal wieder suchen zu müssen oder Notizen zu führen?

Hier kommt QRden

QRden ist eine Android App für die ich im Mobile Master einen Prototypen erstellt habe. Die Idee ist, jede Pflanze die man in einem Topf anpflanzt mit einem QR-Code zu versehen um sie später scannen zu können. Durch das Scannen erfahre ich dann Informationen wie, wann die Pflanze das letzte mal gegossen wurde und Ähnliches.

Wo bekomme ich die QR-Codes?

Die meisten Anwendungen die QR-Codes verwenden, nutzen eigens erstellte und gedruckte Codes. QRden erspaart Nutzern, eigene Codes ausdrucken zu müssen. Stattdessen können x-beliebige Codes genommen werden, also beispielsweise aus Magazinen ausgeschnitten. QRden nutzt den Text der im QR-Code gespeichert ist um eine eindeutige Identifikationsnummer für den Topf zu generieren und ihn so mit dem selben QR-Code wiedererkennen zu können.

Wo ist QRden?

Aktuell wurde nur ein sehr früher Prototyp von QRden entwickelt, den man hier finden kann. Eventuell werde ich im Zuge des Studiums weiter daran arbeiten.

The post QRden – Eine Assitenten-App für Kleingärtner appeared first on Mobile USTP MKL.