• info@noobygames.de

Category ArchiveAllgemein

book cover

Creative DIY Microcontroller Projects with TinyGo and Webassembly

Hey everyone, i have exciting news! I wrote a book called Creative DIY Microcontroller Projects with TinyGo and Webassembly and you can Preorder it now. I have spent houndreds of hours in the past months to get this book ready. So beside calling me Backend Developer and Indie GameDev you can now also officially call me Author.

If you are interested in Microcontroller development, like building your own automated Plant Watering System or if you want to automate your home with DIY solutions this book is for you!

What does the book cover?

The book takes you on a journey from developing your first hello world on a microcontroller to building your very first home automation solutions by combining microcontrollers with WASM. So you are going to create WebApps and microcontroller programs int his book. All important concepts are being explained, while creating these projects.

I don't know anything about microcontrollers is this book still good for me?

Yes! We assume, that you as a reader have zero knowledge regarding micrcocontrollers and webassembly. All important concepts are being explained.

I am going to post more updates through the next few weeks! So stay tuned!

azure devops meme

Use child proccesses templates in azure devops

Hey, u are using azure devops for your project management and tasks and stuff? I hope u use a child process template in azure devops. This may sound familiar, if you ever worked with WordPress and wanted to customize a Theme, i bet you also created a child Theme in order to be able to update the Theme.

Using a "child process template" or inherited process, allows u to customize the Process without breaking the process for other teams.

To create a child process, simply go to your Organization Settings -> Boards, klick on the process u want to use and select "Create inherited process".

A Popup will show up and allow u to set a Name and a Description.

Now click on Create process and your are done.

Now you can customize all WorkItemTypes, set Rules etc. that only apply to the child process.

Multiple teams with only slightly different requirements

If you have multiple teams with only slightly different requirements regarding the customization of a process, setup a child process configure the overlapping requirements of the teams and create copys of the child process afterwards.

azure devops meme

Automatically create a changelog using Azure DevOps

There is a point in the live of every developer, where you have to maintain a changelog. Let's be honest, most of us start by manually creating a changelog. And then you forget to update the changelog from time to time, this is where your customer start to call your support and you start to cry. So you change your processes, add checklists, that you manually check and we all know that every time you have to manually maintain the changelog a little tear makes it all the way from your sad eye to your chin and silently drops into the darkness as you try to think of a good description for your change. BUT CRY NO MORE! You can easily automatically create a changelog using Azure DevOps

At Clarilab i have the possibility to do cool stuff. So i took some time to check out some possibilities to automate that whole tear shredding process. What follows is an explanation of our first attempt to automatically create the changelog, using build pipelines and 2 extensions.


The first extension that we use is XplatGenerateReleaseNotes from Richard Fennel. It allows us to use a HandleBar template to define the content and style of the changelog.

So install the XplatGenerateReleaseNotes plugin using the link above.
Now add a Task to your build OR release pipeline and chose.

You need to specify the path for the artifact. In our exmaple we chose System.DefaultWorkingDirectory so we have access to the file in the next step.

outputfile: '$(System.DefaultWorkingDirectory)\releasenotes.md'

You can either specify the template in a file in your repository, or inline. In our example we chose inline.

templateLocation: 'InLine'

Explanation of all arguments is here

Example Configuration

- task: XplatGenerateReleaseNotes@3
    outputfile: '$(System.DefaultWorkingDirectory)\releasenotes.md'
    outputVariableName: 'kycnow-dev-release'
    templateLocation: 'InLine'
    inlinetemplate: |
      **Release Notes**

      # Notes for release  {{releaseDetails.releaseDefinition.name}}    
      **Release Number**  : {{releaseDetails.name}}

      **Release completed** : {{releaseDetails.modifiedOn}}    

      **Build Number**: {{buildDetails.id}}

      **Compared Release Number**  : {{compareReleaseDetails.name}}  

      **Build Trigger PR Number**: {{lookup buildDetails.triggerInfo 'pr.number'}}

      # Associated Pull Requests ({{pullRequests.length}})
      {{#forEach pullRequests}}
      {{#if isFirst}}### Associated Pull Requests (only shown if  PR) {{/if}}
      *  **PR {{this.id}}**  {{this.title}}

      # Builds with associated WI/CS/Tests ({{builds.length}})
      {{#forEach builds}}
      {{#if isFirst}}## Builds {{/if}}
      ##  Build {{this.build.buildNumber}}
      {{#forEach this.commits}}
      {{#if isFirst}}### Commits {{/if}}
      - CS {{this.id}}
      {{#forEach this.workitems}}
      {{#if isFirst}}### Workitems {{/if}}
      - WI {{this.id}}
      {{#forEach this.tests}}
      {{#if isFirst}}### Tests {{/if}}
      - Test {{this.id}}
        -  Name: {{this.testCase.name}}
        -  Outcome: {{this.outcome}}

      # Global list of WI ({{workItems.length}})
      {{#forEach this.workItems}}
      {{#if isFirst}}### WorkItems {{/if}}
      *  **{{this.id}}**  {{lookup this.fields 'System.Title'}}
        - **WIT** {{lookup this.fields 'System.WorkItemType'}}
        - **Tags** {{lookup this.fields 'System.Tags'}}
        - **Assigned** {{#with (lookup this.fields 'System.AssignedTo')}} {{displayName}} {{/with}}
        - **Description** {{{lookup this.fields 'System.Description'}}}
        - **Parents**
      {{#forEach this.relations}}
      {{#if (contains this.attributes.name 'Parent')}}
      {{#with (lookup_a_work_item ../../relatedWorkItems  this.url)}}
            - {{this.id}} - {{lookup this.fields 'System.Title'}}
        - **Children**
      {{#forEach this.relations}}
      {{#if (contains this.attributes.name 'Child')}}
      {{#with (lookup_a_work_item ../../relatedWorkItems  this.url)}}
            - {{this.id}} - {{lookup this.fields 'System.Title'}}

      # Global list of CS ({{commits.length}})
      {{#forEach commits}}
      {{#if isFirst}}### Associated commits{{/if}}
      * **ID{{this.id}}**
        -  **Message:** {{this.message}}
        -  **Commited by:** {{this.author.displayName}}
        -  **FileCount:** {{this.changes.length}}
      {{#forEach this.changes}}
            -  **File path (TFVC or TfsGit):** {{this.item.path}}  
    checkStage: false
    overrideStageName: 'dev'
    stopOnRedeploy: false
    sortWi: true
    dumpPayloadToConsole: false
    dumpPayloadToFile: false
    replaceFile: true
    getParentsAndChildren: true

Example Template

The example template used is simply the example template from the extension iteself. It adds linked Work items, Pull Requests and Commits.

WIKI Updater Tasks

So after the first step, we do now have a fancy markdown file. Our story could end here, as you don't have to shed single tear anymore, BUT we want ALL THE AZURE DEV OPS MAGIC! So let us automatically deploy the generated markdownfile to a github or azure dev ops wiki.

You need to install WIKI Updater Tasks, which is also from Richard Fennel, thanks dude!

This plugin simply takes the markdown file and pushes it to a git repo.
So add a Git Based Single File Updater as we only generate a single file. If you deploy to a github wiki, like in our example, you need to generate a PAT. Now you can specify a gitname and gitemail, the user and email adress does not need to exist, like in our case. You can also use Azure DevOps variables to insert the Maintainer, who triggered the release/build.

Specify the sourceFile, which is the file we created in the first step.

sourceFile: '$(System.DefaultWorkingDirectory)\releasenotes.md'

You can specify the commit message.

message: 'Update Documentation'

Specify the filename in the remote repository

filename: 'releasenotes.md'

We don't want to replace the file.

replaceFile: false

Instead we want to append to the file.

appendToFile: True

I created a secret variable in the build pipeline and named it github-passwort, that is the PAT.

password: '$(github-passwort)'

The user i created the PAT for was Nerzal.

user: 'Nerzal'

Exmaple Configuration

- task: WikiUpdaterTask@1
    repo: 'https://github.com/Clarilab/kycnow-changelog.git'
    filename: 'releasenotes.md'
    replaceFile: false
    appendToFile: True
    dataIsFile: true
    sourceFile: '$(System.DefaultWorkingDirectory)\releasenotes.md'
    message: 'Update Documentation'
    gitname: 'clarilab-bot'
    gitemail: 'bot@clarilab.de'
    user: 'Nerzal'
    password: '$(github-passwort)'
    localpath: '$(System.DefaultWorkingDirectory)\repo'

Wiki for both extensions

You can find the wiki for both extensions. here

Result Example


Where to go from here?

Now as we do automatically create and deploy a changelog on each build, we might want to adjust the handlebar template to customize our changelog.
As soon as i have a better understanding of these templates, i will write another blog post with more detail in templating.

This blog post is brought to u by my new fancy markdown plugin


Azure Dev Ops & Jenkins

Wer schon mal versucht hat Azure Devops & Jenkins miteinander spielen zu lassen, der ist ggf. auch an stumpfe Grenzen geraten.
Du denkst nun, haha "Was für ein Noob, das geht doch voll easy?!" Nuja, pass mal auf.

Das größte Problem bestand darin, dass unsere Jenkins Projekte SSH Connections für git konfiguriert hatten. Warum ist das ein Problem?
Darauf gehe ich etwas näher ein.

In Azure Dev Ops kann man relativ einfach Service Hooks anlegen, um alles mögliche triggern zu lassen. Es war natürlich naheliegend einfach eine Service-Hook zu nehmen, da es dafür ein Jenkins Template gibt.

Okay also eine Service-Hook angelegt und mal ausprobiert.
Nachfolgend ein Beispiel Request:


Jenkins Rage over 9000

Sieht doch gar nicht schlecht aus, oder? Doch! Wenn ein Jenkins Projekt Konfiguriert ist eine SSH connection zu benutzen, dann wird mit diesem Request gar nichts getriggert, da das Repo nicht zugeordnet werden kann.


Da ich zu faul war nun alle Jenkinsfiles, Dockerfiles und Co. noch einmal anzupassen habe ich mal eben schnell einen Reverse Proxy in go geschrieben, der so ein Request entgegen nimmt und die https url in eine ssh url umschreibt, die ursprünglichen Header wieder anhängt und das ganze zu Jenkins weiter leitet.

Azure Dev Ops denkt nun, es würde einen Push-Request an Jenkins schicken, als URL ist aber der Reverse Proxy hinterlegt.

Für diesen Service habe ich <100 Zeilen gebraucht, dank des echo-frameworks und resty und einem string replace. Es geht vermutlich in noch weniger Lines of Code.

Wenn ihr euch so was auch baut, müsst ihr bei der Entwicklung darauf achten die Service Hooks immer wieder zu reaktivieren, da diese sich nach 3 maligen Fail in folge selbst deaktivieren. Diese Erkenntnis hat mich sicher eine Stunde gekostet.

Die ganze Magie könnt ihr im folgenden Screenshot bewundern. Tatsächlich extrem einfach sowas mit go zu regeln <3

Die Magie
hacktoberfest titel bild

Hacktoberfest Kassel 2019

Auch dieses Jahr wird es wieder einen Hackathon für das Hacktoberfest Kassel 2019 bei fino geben. Stattfinden wird das Event am 19.10.2018 ab 11Uhr bei fino im SciencePark der Uni Kassel. Wir bereiten verschiedene Workshops und Vorträge vor. Es gibt also den ganzen Tag über Programm für und mit euch. Für Essen und Getränke wird gesorgt sein, ihr solltet aber einen eigenen Laptop mitbringen.

Themen für Vorträge / Workshops

  • Musikanalyse
  • Go for Go
  • Arduino

Das Hacktoberfest ist ein jährlich wiederkehrendes Event, welches von Digital Ocean, Github und Twilio getragen wird. Das Ziel vom Hacktoberfest ist, Entwickler zum mitmachen bei OpenSource Projekten zu motivieren. Fast jeder von uns hat schon OpenSource Projekte benutzt und damit bestimmt einen Haufen Zeit sparen können. Auch vorletztes Jahr haben wir am Hacktoberfest teilgenommen, und natürlich werden wir das auch dieses Jahr wieder tun. Das Hacktoberfest startet am 01.10.2019 und endet am 31.10.2019, innerhalb dieser Zeitspanne könnt ihr daran teilnehmen.

DigitalOcean spendiert jedem, der teilnimmt und 5 PullRequests in OpenSource Projekten öffnet, ein cooles Shirt. Die PullRequests können auf einem beliebigen öffentlichen Repository auf Github eröffnet werden. Die PullRequests müssen Commits beinhaltetn, die Ihr selbst erstellt habt und dürfen nicht von den Maintainern als spam etc. getagged werden. Im Gegensatz zum letzten Jahr bekommen dieses Jahr die ersten 50.000 ein Shirt. Letztes Jahr haben "nur" 30.000 ein Shirt bekommen. Dieses Jahr ist es also noch einfacher ein Shirt zu bekommen.

Kommt also alle zum gemeinsamen coden, networken, Wissensaustausch, quatschen und Spaß haben!

Ebenfalls wäre es super nice, wenn ihr ein RSVP in unserem Meetup-Event da lasst.


Ich freue mich euch alle beim Hacktoberfest 2019 Kassel begrüßen zu dürfen.


Cleancode in golang #1

In diesem Beitrag geht es nicht um Prinzipien und Praktiken von Cleancode, sondern um Hilfsmittel speziell für go, die dabei helfen den idiomatischen Weg einzuhalten.

Cleancode ist auch in go eine wichtige Angelegenheit. Als einstieg in die Thematik empfehle ich, dass du dich mit den Tooling, dass go mitbringt vertraut machst. 2 Tools, die dir dabei helfen deinen Code sauber zu halten sind golint und go vet.

go lint

Der linter prüft nicht auf die Korrektheit von Code, sondern viel mehr den CodeStyle.
Den standard linter, welcher die meisten Regeln aus dem Buch "Effective Go" kennt und prüft könnt ihr mithilfe vonfolgenden Befehl installieren.

go get -u golang.org/x/lint/golint

Eine einzelne Datei kann man mit folgendem Befehl prüfen lassen:

golint main.go

Es ist auch möglich eine Liste von Dateien anzugeben:

golint file1.go file2.go

Zusätzlich kann auch ein Pfad inklusive aller Unterordner geprüft werden

golint /pfad/zum/project/...

go vet

Das vet tool prüft den Code auf Korrektheit.
Dabei untersucht vet den Go-Code und reported verdächtige Konstrukte, wie Printf calls, deren Argument nicht mit dem format string übereinstimmen. Die algorythmen, die Vet benutzt garantieren nicht, dass alle gefundenen Probleme tatsächlich welche sind, aber dafür findet es Fehler, die nicht vom Compiler gefunden werden. Es ist somit immer nützlich mal darüber zu schauen, da gerade features wie das finden von ungenutztem Code, oder auch das fehlende Prüfen auf einen error sehr nützlich sind.

Um go vet zu starten kann einfach folgender Befehl verwendet werden

go vet /pfad/zum/project/...

Dieser untersucht sämtliche packages.

Um ein spezifisches Package zu untersuchen kann der pfad zum package direkt angegeben werden

go vet /pfad/zum/package

Features von go vet

asmdecl      report mismatches between assembly files and Go declarations
assign       check for useless assignments
atomic       check for common mistakes using the sync/atomic package
bools        check for common mistakes involving boolean operators
buildtag     check that +build tags are well-formed and correctly located
cgocall      detect some violations of the cgo pointer passing rules
composites   check for unkeyed composite literals
copylocks    check for locks erroneously passed by value
httpresponse check for mistakes using HTTP responses
loopclosure  check references to loop variables from within nested functions
lostcancel   check cancel func returned by context.WithCancel is called
nilfunc      check for useless comparisons between functions and nil
printf       check consistency of Printf format strings and arguments
shift        check for shifts that equal or exceed the width of the integer
stdmethods   check signature of methods of well-known interfaces
structtag    check that struct field tags conform to reflect.StructTag.Get
tests        check for common mistaken usages of tests and examples
unmarshal    report passing non-pointer or non-interface values to unmarshal
unreachable  check for unreachable code
unsafeptr    check for invalid conversions of uintptr to unsafe.Pointer
unusedresult check for unused results of calls to some functions


Wem der default linter nicht mächtig genug ist, der kann auf golangci-lint zurück greifen. Dieses mächtige Tool ist komplett konfigurierbar und bietet eine wesentlich größere Anzahl an lintern, sowie die möglichkeit einige Fehler direkt zu beheben.

Zusätzlich ist die Ausgabe der Fehler besser lesbar und enthält mehr Informationen, als beim default linter.

Beispiel Ausgabe:

pkg/onboarding/service.go:267:2: Consider preallocating `financialEligibles` (prealloc)
var financialEligibles []models.Individual
cmd/local/main.go:31:1: cyclomatic complexity 12 of func `main` is high (> 10) (gocyclo)
func main() {

golangci-lint ist als open source Projekt auf github gehostet.

Zum installieren muss lediglich folgender Befehl ausgeführt werden:

go get -u github.com/golangci/golangci-lint/cmd/golangci-lint

Golangci lint kann in alle gängigen Editoren/IDEs integriert werden.


Wir halten nun also den default CodeStyle ein und kümmern uns um die Korrektheit. Nun wollen wir natürlich auch noch die korrekte Formatierung nutzen. Dafür gibt es das gofmt tool


Um direkt alle Dateien zu überprüfen und fixes anzuwenden kann folgender command genutzt werden.

go fmt -n -x pfad/zum/projekt/...

Nützlich kann hierbei auch eine git pre push hook sein.

Ein Beispiel dafür findet ihr hier:




Jeder von uns hat es schon erlebt, dass er in ein bestehendes Projekt kommt und eine neue Funktionalität implementieren will und dann einen Moloch vorfand. Einen solchen Moloch, dass wir gar nicht mehr wussten, wie man diesen Bändigen soll. Nun habe ich in solchen Fällen viele Stunden, oder gar Tage damit verbracht den Moloch zu verstehen und manchmal habe ich dem Moloch dann noch einen Arm, oder ein Bein angeheftet, was ihn nur noch größer, furchteinflößender und vor allem komplizierter gemacht hat.

Ein solcher Moloch kann in vielen Formen auftreten. Manchmal ist es eine Klasse mit tausenden LOC (Lines of Code), manchmal ist es eine Funktion mit einer unglaublich großen CC (Cyclomatic Komplexity), die durch viele IF-Else- und große Switch-Strukturen erzeugt wurde. Viele von uns haben sich bereits die Frage gestellt, wie man diese angsteinflößenden Monstrositäten bändigen kann. Ich möchte euch nun ein Mittel an die Hand geben, dass jeder Entwickler leicht verstehen und Umsetzen kann. Dies funktioniert sowohl bei alten, wie auch bei neuem Code. Das Wundermittel nennt sich Integration Operation Segregation Principle kurz IOSP.

Wie Erkenne ich einen solchen Moloch?

Glücklicherweise sind Verstöße gegen IOSP leicht an folgenden Verstößen zu erkennen:

  • Wenn man ein schlechtes Bauchgefühl hat.
  • Die Methode hat mehr als 10 - 30 Zeilen
  • Die Zyklomatische Komplexität ist sehr hoch
  • Die Methode hat viele Abhängigkeiten

Um diese Verstöße gegen IOSP und damit meist auch Verstöße gegen weitere Prinzipien. Ausfindig zu machen kann man Beispielsweise Statische Code Analyse Tools verwenden. Wie das geht zeige ich hier.

Wie funktioniert IOSP?

Wenn Code nur Bausteine aus dem eigenen Projekt, des eigenen Codes zusammensteckt, dann nennt man ihn Integration.

Wenn der Code domänen Logik und Kontrollstrukturen enthält, handelt es sich um eine Operation

In folgendem Beispiel sieht man eine Kette von Funktionsaufrufen. Möchte man nun Funktion 1 testen, so muss man mit großer Wahrscheinlichkeit auf Mocking/Faking der Abhängigkeiten zurück greifen, da hier Operation und Integration vermischt wurde.

Hier sollte man nun im ersten Schritt versuchen diese Verkettung zu vereinfachen. Eine mögliche Vereinfachung wird im nächsten Bild dargestellt.
Hier sind nun Funktion 3, 5 und 6 als Operation erkennbar. Diese können ohne weiteres einfach getestet werden. Funktion 1 Integriert hierbei Funktion 2, 4 und 6

In unserem Beispiel haben stellen wir allerdings fest, dass wir die Bausteine noch weiter voneinander entkoppeln können, indem wir die Funktion 2 bis 6 in Funktion 1 integrieren.

Im letzten Schaubild sehen wir nun, wie die "perfekte" Umsetzung von IOSP aussehen kann. Funktion 2 bis 6 sind komplett von den anderen Funktionen entkoppelt. Sie haben keine Kenntnis voneinander und stellen reine Operationen dar. Funktion 1 hingegen integriert die anderen 5.

Somit sind Funktion 2 bis 6 nun einfach über UnitTests testbar und Funktion 1 über einen Integrationstest.

Ich habe diese Entkopplung bewusst in 2 Schritten dargestellt, um klar zu machen, dass es einfacher ist sich einzelnen Teilen der Logik zu widmen, anstatt das komplette Paket in einem rutsch zu refactoren.

Welche Vorteile haben wir durch IOSP?

Setzt man IOSP Konsequent um, so ergeben sich folgende Vorteile:

  • Kurze einfach zu verstehende Methoden
  • Leicht testbarer Code
  • Evolvierbarer Code
  • Die Methodennamen werden wieder aussagekräftig


Statische Code Analyse mit Sonarqube

Jeder der sich um Code Qualität sorgt, hat sich schon einmal Gedanken gemacht, wie er das ganze Analysieren kann um ein Gesamtbild zu bekommen. Nun kann man den ganzen Quellcode durchschauen und sich dabei Notizen machen, oder Tickets erstellen für Stellen im Code, die nicht so geil sind, oder man benutzt ein statisches Codeanalysetool. Ich habe mich für eine statische Code Analyse mit Sonarqube entschieden. Sonarqube gibt es als OnPremise und als Cloud variante.

Aufsetzen von Sonarqube

Was braucht man dafür? Natürlich lasse ich das erst mal in einem Docker Container laufen. Dafür tippt man, vorausgesetzt Docker ist installiert, einfach die folgenden 2 Befehle ein:

docker pull sonarqube
docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube:latest

Anschließend wartet man einen kurzen Moment, bis der Container hochgefahren ist. Das hat bei mir so 5-10 Sekunden gedauert. Jetzt könnt ihr die Sonarqube Instanz bereits unter localhost:9090 finden

Erstellen eines Projekts

Ruft im Browser den Link http://localhost:9000 auf.
Loggt euch anschließend mit folgenden Credentials ein:

Username: admin
Password: admin



Anschließend könnt ihr ein neues Projekt erstellen. Vergebt dafür einfach einen Namen, bestätigt und anschließend klickt ihr auf Generate.

Sonar Scanner

Ladet euch nun Sonar Scanner herunter. Entpackt diesen an einen beliebigen Ort und fügt den Pfad zum bin Ordner dem Umgebungspfad hinzu.

install plugin

install plugin

Analyse Starten

Startet nun die analyse im folgenden Beispiel habe ich als projectkey "gocloak" gesetzt, da ich ein Projekt mit dem key "gocloak" angelegt habe. Dies müsst ihr durch euren Key austauschen und anschließend im project-root ausführen. Den Login Wert müsst ihr durch den key austauschen, den ihr zuvor erstellt habt.

sonar-scanner -Dsonar.projectKey=gocloak -Dsonar.sources=. -Dsonar.host.url=http://localhost:9000 -Dsonar.login=8f032266ebed7ca4ec79e22f464b8649455bad77

Alternativ könnt ihr als Login auch folgendes verwenden:

sonar-scanner -Dsonar.projectKey=gocloak -Dsonar.sources=. -Dsonar.host.url=http://localhost:9000 -Dsonar.login=admin -Dsonar.password=admin

Ist der Befehl erfolgreich durchgelaufen könnt ihr euch das Ergebnis auf Sonarqube anschauen.

sonar result

sonar result


Spielereien mit Google ARCore & Unity – BlockInvasion AR

Ich habe mal etwas mit Google ARCore rumgespielt. Dabei ist ein MiniGame "BlockInvasion AR" enstanden. Es bedarf noch ein wenig arbeit, bis ich es in den PlayStore werfen kann, doch es ist erstaunlich, wie einfach man mit Google ARCore und Unity ein AR Spielereien basteln kann. Ich hoffe ich finde an den nächsten Wochenenden Zeit diese restarbeiten zu erledigen.


Ich habe aufjedenfall Bock auf das Thema, also wird es demnächst mehr davon geben.

Nachfolgend findet ihr ein kleines Teaser Video.

BlockInvasion AR Teaser

Das Video wurde direkt auf dem Handy aufgenommen. Wie man sehen kann bemerkt das Spiel, dass das Gerät sich um die eigene Achse dreht und setzt das in eine Drehung in der Spielwelt um. Dadurch können die Blöcke, die sich neben, sowie hinter mir befinden ausfindig gemacht werden. Natürlich ist das Video nur ein Teaser. Das Spiel bietet natürlich noch mehr, als ein paar im Raum rumstehende Blöcke 😉

C# UserGroup

C# UserGroup Kassel Treffen Nr X bei x>=6

Es gibt mal wieder ein C# UserGroup Treffen. Diesmal allerdings an einem neuen Ort. Mick's. in der Wiesenstraße, 1A , 34121 Kassel. Das ist also gar nicht mal so weit entfernt von unserer bisherigen Location. Wir haben die Location natürlich bereits ausgiebig getestet und sind der Meinung, dass das Bier schmeckt und es gibt auch wieder gute Musik. Zusätzlich hat sich noch das Datum geändert wir sind am 27.01.2019 (Sonntag) am start. Los gehts wie gewohnt gegen 19 Uhr. Wir testen mal, ob es uns dort gefällt. Natürlich haben wir keine Kosten und Mühen gescheut und haben uns eine mobile Beamer-Leinwand organisiert. Das macht uns noch etwas unabhängiger von den gegebenheiten der Location.

Diesmal haben wir wieder das 2+1 Themen Prinzip. Soll heißen 2 Vorträge + 1 als Backup. Dadurch können wir etwas mehr ins Detail gehen und haben mehr Zeit für Rückfragen etc. Macht uns das Leben auch leichter, dass man einen auf Backup hat.

Ich bekomme die Themen nicht mehr vollständig zusammen, also improvisier ich an dieser Stelle mal.

Unsere Themen

  •  GoogleAR Core in Unity
  • C# Addin System
  • Home Automation
  • MicroController Programmierung mit C#, oder auch C++ xD

Es werden also 2 Themen aus der Liste schaffen. Soweit ich weiß bereitet evo ein Talk für das C# Addin system vor und ich bereite euch einen Vortrag über GoogleAR Core vor. Hab da nämlich etwas mit rumgespielt und mit sehr wenig Aufwand coole Ergebnisse erzielt.

Erscheint Zahlreich, bringt eure Freunde mit, bringt eure Leidensgeschichten und natürlich auch etwas Durst mit!

Wir freuen uns auf euch

%d Bloggern gefällt das:

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklären Sie sich damit einverstanden.