DEV Community: Dennis Ploeger

Github Action for the Godot Asset library

Dennis Ploeger — Sun, 04 Apr 2021 10:42:28 +0000

Just a quick announcement: If somebody uses Github to store their assets for the Godot asset library, I created a Github actions to push new release to there. It depends on the Asset library REST API.

Check it out:

deep-entertainment / godot-asset-lib-action

A github action to manage assets on the Godot asset lib

Godot asset lib action

This github action manages assets in the Godot asset library.

Inputs

`action`

Required The action to carry out. Currently, these actions are provided:

addEdit: Add an asset edit. Requires the assetId input. Expects that you have created the asset previously with all the basic information.

Default: addEdit

`username`

Required The username for the asset library

`password`

Required The password for the asset library. It's recommeded to use a secret.

`assetId`

Required The id of the asset in the asset store

`assetTemplate`

Required A handlebars template file that will provided with the webhook context of the action. See the webhook reference file for details.

The resulting file should fit the Asset model. See the asset library rest api documentation for details.

The token will be injected by the action.

Default: .asset-template.json.hb

`baseUrl`

Required Base URL for the godot asset lib.

Default: https://godotengine.org/asset-library/api

Outputs

…

View on GitHub

Announcing EgoVenture

Dennis Ploeger — Sat, 27 Mar 2021 18:13:10 +0000

The past

I've always been a big fan of the Carol Reed series of adventure games by MDNA games.

In case you don't know them: Carol's a private detective solving cases in and around the Swedish town of Norrköping. The game mainly consists of a lot of professional-grade photographs that you wander through in perfect point and click manner while collecting items and solving puzzles. The stories are compelling, gripping and fun and walking around in run-down factories is just the right amount of creepiness I need.

The games are made using the Wintermute engine, which saw its last release over ten years ago at the time of this writing. Wintermute can only create games for the windows operating system.

Being a macOS aficionado I contacted developer Mikael Nyqvist some years ago because I could run his games using Wine on macOS. This was the beginning of a nice partnership where I would recompile his games for macOS and also take some voice parts in the games.

With Apple dropping support for 32 bit software and Wine only slowly catching up with Catalina two years ago and now dropping the i386 platform, this became a burden.

Meanwhile in Sweden, Mikael also was looking for better scalability and broader platform support.

When I sparked a discussion about moving his games to a new engine after getting more intimate with the Godot game engine, things just clicked.

Together we worked down a list of features he needed for his games - which honestly was much more than I expected. However, one feature at a time, we could cross out all things on his list and create a framework for Godot, that would allow easy creation of things just like the Carol Reed series.

The Present

Thankfully, Mikael was always aboard to release the source code and even the sample game with his art under open licenses (MIT and CC-BY-SA).

So today, Deep Entertainment together with MDNA Games would like to announce:

EgoVenture - First person point and click adventure framework for Godot

EgoVenture is a base framework, that takes care of the most basic tasks each game needs, namely:

Main menu
Game options
State and savegame handling
Scene management
Inventory handling
Mouse and touch screen support

and more.

Additionally, its accompanying Godot addons Parrot and Speedy Gonzales complete the games with dialog handling and custom mouse cursors.

Starting a game with EgoVenture is easy using the EgoVenture game template. Check out the getting started guide

If you'd like to see all the features that are possible using EgoVenture, please check out the EgoVenture Example Game made by MDNA games. Up to date releases for Windows, macOS and Linux are available on its own itch.io page

Of course, all addons, the example game and the game template, are available in the Godot asset library.

The future

Mikael has already started creating the new game for 2021 and will be using the EgoVenture engine, so we can expect something awesome in the near future.

Additionally, with EgoVenture and all accompanying addons being released under an open source license, we encourage other game developers to use the framework and if anything happens or questions arise, please don't hesitate open an issue in the respective issue tracker.

Feather > Sword

Dennis Ploeger — Fri, 29 Jan 2021 10:24:58 +0000

Photo by Debby Hudson on Unsplash

We're living in a world of information overload. Do you know how they say, that the feather is mightier than the sword? Well, I'd like to add, that a gazillion of feathers lying around, some broken in two, some burned beyond recognition and some nails in a feather costume makes the feather loose all its power again.

In these times, you're able to know just about everything, but it's getting harder and harder to find the right and up to date information.

I think, this is true for the world in general, but also in the micro cosmos of most teams or departments nowadays.

There's no problem in having information and documentation, but in having good and usable documentation.

This was (and in some parts still is) a problem we had with the IT-Department at KPS.

And this is how we tackled that.

Who we are

We're the IT department of KPS. KPS is a consultancy company who helps its customers on their digital transformation journey. We support the complete infrastructure ranging from network access, datacenter management, routing, Linux and Windows server management, platform management to user support and DevOps project consultancy.

We're divided into four teams to evenly balance the different aspects of our work.

Where we were

Originally coming from a merger of two companies team members were used to different documentation tools and ways of documenting. Thus, we had various places to look up information and various levels of quality throughout the different documents.

After we finally agreed to a central documentation space and tool, we migrated most of these documents. This made all information accessible at one place, but the lack of a standardized document quality still made it hard to find the right documentation.

And we struggled with it. So finally, we gathered together to form a documentation taskforce who should suggest a common standard for documentation for the IT department.

In this documentation taskforce we put members of all teams who knew something about their team's own previous documentation.

Starting is hard

So there we were. Left with a heap of documentation and trying to figure out how we should deal with it.

The first thing we did is to take a step back and look at what we want documented. What different types of documentation do we need for our daily work and for our customers daily work?

So we defined those different documentation types. For example, because we are supporting our customers and their workplace infrastructure we had some documents for self service. These documents showed our customers step-by-step explanation to common problems or how to install a new system or app on their computers.

Then, we have a team that builds up networking infrastructure needing infrastructure diagrams to better grasp what different parts they're managing and how to solve problems in that.

Of course we're doing meetings from time to time so there were meeting notes.

Et cetera, et cetera, et cetera.

Breaking down document types

So for each of these document types (in the end, we defined 13 different types) we asked ourselves what elements each type usually has.

Is there a page header in a guideline document? Absolutely. Does an infrastructure documentation have a schematic layout? You betcha. Does meeting notes have screenshots? Mostly not.

Mind you, these elements are common. It can happen, that a meeting note has some kind of screenshot, but it's probably unusual.

"Suggesting" instead of "Defining"

Remember that I said "(the taskforce) should suggest a common standard" and not define? That was on purpose.

Throughout the whole process we were absolutely sure about one fact:

Nobody wants to do documentation.

So we had in mind, that we had to make the barrier for documentation as low as possible. We wanted to make it easy for people do document correctly.

That's why we made suggestions on how to make good documentation, and didn't define it. It should be a team process.

The styleguide

After we had gathered all elements available in the different document types we needed to write down how these elements should look and what they should contain.

And in most cases, this is a matter of taste. However, there are certain aspects, that one should keep in mind when writing technical documentation.

Be aware of your audience. Who will be reading your documentation? What set of skills do they have? Are they common to technical terms? Are they common to specific technical terms? What language is their native tongue?
Don't be fancy. You're writing technical documentation, not a children's book. You don't need fancy colors, thirteen different fonts or sparkle effects (Though they're pretty cool) Keep it nice and short
You're not the reader! In most of the time and most of the documents you will write, you won't be the actual one reading them. Those are your colleagues, your users or managers. Write for them, not for you.
Keep your style. Changing document formats, layouts or styles with every document is very hard on the eye. Your readers need to feel home with every new document. They need to know what is coming up.

The Godot game engine documentation has a good reference for writing and styling technical documentation. As it is a multipurpose game engine with a very diverse and international audience, they really put some thoughts in that.

Language!

According to Wikipedia, the world has an estimated amount of 5,000 to 7,000 spoken languages. But language goes further than just wether you're speaking French, English, Latvian or Shona. Different people in different tongues not only have a different vocabulary but also different ways of describing and reacting to topics.

Thanks to English being the language with about 1.2 billion speakers worldwide, most documentation nowadays ist written in english and then usually translated from that.

However, simply writing in english usually doesn't do the trick. Especially when you're writing for people who are not fluent in it. I like to cite the aforementioned Godot docs writing guidelines here:

A technical writer's job is to pack as much information as possible into the smallest and clearest sentences possible.

Smallest and clearest. This is a technical doc, it shouldn't transport emotions of the author (like a novel) or entertain (like a children's book). It should simply contain all required information in the most clear and understandable way.

But still, languages as spoken languages need to be taken into account as well.

If you're aware that your readers are not fluent enough to read a full-fletched english documentation (even if you write short and clear), you need to translate the documents.

As said before, we wanted to keep the barriers of documenting low so we can motivate and engage colleagues to actually write documentation.

Because most of our colleagues have german as their native tongue, we agreed to use german for internal documents that don't span outside our department.

However, we also write documentation for our users and we're an international company so for those documents we agreed on writing the docs in english only (just so that we don't have to write docs twice).

Problem with structure. The.

When a tree falls but nobody's around, does it make a sound? When a document is written but nobody finds it, was it written in the first place?

The task of properly structuring things is a life long task of humanity. There are literally thousands of apps in the "productivity" category that basically just try to structure things.

It's like the holy grail.

And, honestly, we didn't find it.

Instead we agreed on two things, which may look like it, but could as well just be a gold-colored plastic cup.

The first thing was using tags. Tags are not a thing of the #internet, by the way. Tags have a long tradition in bibliography (where they're called index terms). They condense the content of a document into one or more words. Multiple documents share common tags and thus aid in navigation to related documentation.

Also, tags are a great way of suggesting search words for the internal search of your documentation tool.

So we recommended setting meaningful, short and few tags for each document. And to reuse existing ones (Our documentation tool suggests existing tags when typing the name of a tag).

The second thing was suggesting a documentation structure. I emphasized suggesting, because we really couldn't dictate any kind of structure for our department as a whole. We recommended a common top level structure, which was basically a department-wide section followed by team-wide sections. The team sections were free to be filled by the individual teams, while the common section was a bit more restricted.

We came up with the following suggestion:

Common
Team A
- Topic
- Subtopic (optional)
  - Document type
  - Document
Team B

For each level we recommended using a macro (a programmed function in our documentation tool) that lists all child documents of the level. That way you have a nice overview of all your topics, or all document types or all documents of a certain document type for a topic.

We know, that this might not be optimal for each and everyone, but at least it is a start.

Keeping up with the community

A wiki is a hypertext publication collaboratively edited and managed by its own audience directly using a web browser

Wiki - Wikipedia

In 1994 Ward Cunningham developed the first Wiki system (WikiWikiWeb) and it introduced a whole new way of collaboration when writing documentation. It allowed to

comment and discuss on documents
make editing available to everybody
introduced proper versioning for digital documents

Well, looking at how often I put links to the english Wikipedia into this document, I guess the system was successful.

We embraced the basics of Wiki-documentation for our documentation as well: We saw that we're one team so we didn't need any restrictions to documents. Everybody could see, edit and comment any document in our internal space.

I'm absolutely sure, that allowing edits from as many people as possible helps creating up-to-date and vibrant documents.

Additionally, with documents for users we allowed comments on them as well so they could suggest better documentation from their point of view.

Speaking of point of view: Always let somebody else read your document before it reaches a "published" state. Writing a document is dumping your brain into text. But it is your brain and that can very much differ from another person's brain.

Where we are

Finally, we put this all together into a new document that obeyed the style we suggested and presented that to our colleagues for comments.

Most of our suggestions and recommendations were directly approved and some required some more discussion.

In the end we created a "documentation guideline" from this document that needs to be followed by the complete department when writing documentation. As this was a team effort and we kept the barriers low, the complete department was "in the boat" for making this documentation happen.

Now, changing a massive load of already existing documents isn't a thing that comes overnight, but we layed the ground for new documents and reworks of existing documents so gradually our documentation will shine more and more.

Parting suggestions

Let me give you some nifty (or not so nifty, you decide) tidbits from our guideline. Again, this is our documentation, suited to our needs, so effectively: YMMV.

Document states

It is essential, that documentation is up to date. However, we live in a world where being up to date is fairly impossible because everything changes everywhere at any time - especially in the IT business.

So documentation will be out of date at some point. The important thing here is to let the reader know, that it is.

For this, we're using document states.

Every new document starts in the draft state. Things are highly uncertain, incorrect, incomplete and sometimes incoherent. Don't trust this document.

After a possible review process (which we kept as small as possible. Remember, barriers?) a document moves into the published state. This document is complete, correct and trustable.

Then, time happens and things get out of control.

At some time, a document might move into one of the obsolete or rework states.

Obsolete documents are basically trash. They're not applicable, not correct or not usable anymore. They just outgrew their purpose. And that's okay. Nothing bad about that. The reader just has to know that.

Usually, obsolete documents are - after a short discussion with the responsible team - removed. We decided against archiving on purpose, because in real life, archived documents are never read or touched again. So why keep them?

Documents in the rework state are still applicable, just not completely correct or usable anymore. They should be updated later (gamified documentation days ftw!) and the reader can still use them, but should probably be on the lookout for problems or errors that might arise.

Having a table of contents (toc) is so important. Not only for quickly referencing parts of a documentation, but also for a new reader starting to read the document.

A toc helps the reader to plan ahead how much time reading a document will take and how much information they can gather from a document.

Also, meaningful section headers are pretty important as well. A toc with bogus headers just could be left out at all (don't take this post as an example. This is a post and no technical document)

Templates

Whenever possible in your documentation tool of choice, use templates. We created a template for every document type we had and included examples (using comment blocks which are not visible on the rendered page) for each section.

This way, authors knew what they had to do and could just drain their brain into the preformatted sections.

Don't reinvent the wheel

Good documentation has been around for ages. You know these strange things made out of processed wood? With these letters on them? BOOKS! Yes, that's what they call them.

When you create your style guide, check out how authors did things years and years ago. For example, the proper use of typography is the same in every technical book you find around. There are guidelines for when to use emphasis, code stylesand so on.

Check out your favorite search engine and look those up. Or just, you know, open some of those... books.

Accessibility

I like to point out that you should be thinking of making your document accessible to everybody.

That not only includes absolutely important things like proper color choices for visually impaired folks and alternative texts for images, so that your documents can be understood by screen readers but also making sure, that all aspects of a document are accessible to readers and authors.

Take a graphic illustration for example. If you use an external software for creating that: Does every author have access to that software and to the base document you used to create it?

Use existing plugins for documentation tools that allow direct editing graphics inside a document instead.

And don't forget about links! You can use them for reference or to break things with various aspects into different documents and link to them. For example, you might have documented the installation guide to a system and now you create a user documentation for it. You don't need the installation guide there, but for a colleague who maintains the system, it might be interesting nevertheless. So: link it!

The future is yet to come

Documentation is never over, it merely keeps evolving.

To keep up to date and not loose tracks we didn't break up the documentation taskforce. We made a recurring appointment that can be canceled, if nobody has anything to say, but it's there to remind us to keep our documentation suggestions up to date just like our documentation itself.

Another thing we added was a tool, that could regularly tell us about outdated documents. Some (defineable) time after the document has been created, it will notify us so that we can validate it and set document states accordingly.

This is something we introduced, but not really tested well.

But in the end, this was a fun journey and a very productive one as well.

Yes, documentation is not sexy, but having the right, good, well readable and up to date document at hand when you're deep in horse dung on a production system already comes pretty close.

So I released an Adventure Game

Dennis Ploeger — Sun, 06 Dec 2020 19:58:23 +0000

Today

AdventureX is a yearly conference for narrative games. This year (for obvious reasons) there was no conference. Instead, the organizers had the idea of a game jam.

In case you don't know, a game jam is something like a sprint in the developer world. It's a defined time slot (of usually two weeks) in which you have to complete a playable game.

The AdvXJam obviously requires games to be in the narrative genre (like visual novel, point and click adventure, etc.) and featured a topic: "Good Times".

But let's turn the clocks back to start of Covid-19.

April

There are a lot of game jams actually - usually organized over the game platforms itch.io or gamejolt and Discord. One specific, quite known jam in the narrative game genre is the AdventureJam.

I've always had an eye on the indie adventure developer scene and always wanted to release a narrative game myself, but could never really follow it through.

So I thought, maybe I needed a team of fellow artists and together we could actually make a game.

That's why this year I dipped my toes in the jam scene and joined the AdventureJam - as a voice actor (I'm a hobbyist voice actor since I joined the cast of the Carol Reed series).

And it was so much fun and I learned a lot.

After it was done I thought, that I really like to make my own game for the jam with a team. I remembered an old short story I wrote around twenty five years ago back in school and thought that this story might have potential for a game.

I started to write a game design document, but again lost the interest in it...

November

So AdvXJam came and, again, I offered voice acting services.

And then I saw Sally Beaumonts post:

And I thought, that I could ask Sally if she'd be up to turn my old short story into a game.

Well, she was.

The team

So I had Sally on board who also took over voice casting, because she's a professional voice artist.

Then I saw, that Rikard Peterson was offering his services as a musician and found his music to match perfectly a specific scene in the story and asked him if he'd like to join the team and produce the music for the game and we instantly clicked.

And then I had another member for the team: My son wanted to join as well and draw the characters for the game!

The last one joining the team was Cade Conkle who supported us with awesome sound effects.

The rest

Well, if you know narrative games, you know, that writing, music and sound aren't the only disciplines required for such a game.

So the rest would be: background art, animations and programming.

And as I couldn't find an artist, I was the last one who had this on his shoulders.

Art

I thankfully have some of the genes of my father, who can really draw awesome pictures, so I could draw the background images with some exercise.

Animation was a completely different thing. I hate doing hand drawn animations. I'm simply not patient enough to draw sixteen similar images that form an animation.

However, I had some prior background in Blender (which basically means, that I got to know how to navigate and handle it) and together with the cutout animation tools plugin my son could draw static images of my characters, that I could explode into cut out parts and animate them with Blender's awesome skeletal animation features.

Yay! Easy Walkcycles!

Programming

Four days before the deadline we had nearly all assets ready and I thought that I just needed to wrap it all together in a game engine. And after that we'd had plenty of time to beta test and optimize.

Narrator: Boy, was he wrong!

I have some prior experience in the wonderful game engine Godot so I had no real problems creating a framework that can run the type of game we made. But actually bringing all assets in, implementing the works of the awesome voice actors we had and making the game interactive was A. Lot. Of. Work

Long story short: I didn't made it to the deadline.

Thankfully, the guys over at the AdvXJam allowed entries past the deadline so after four more hours, I got everything working (well, kinda) and added the game to the jam.

Wrapping it up

Today I can announce that after final touches and bugfixes I can finally release my first, official game:

"The Letter"

An atmospheric narrative game about a pensioner's existential crisis in a dystopian future.

Check it out on itch

I'm so happy to have achieved that. I learned so much and got to know so many awesome people on the way and am forever grateful for their help and support.

That's definitely not the end. I will try to get other games done. The next Adventure Jam is just around the corner and maybe, mayyybe Corona might be over soon so that Adventure X will actually take place next year or 2022 and I can finally meet all this wonderful people.

The third installment of my learning project

Dennis Ploeger — Sun, 15 Nov 2020 16:18:04 +0000

Prologue

I have established some kind of "learning project" some time ago. A fixed set of features of an application that I reapply to things I want to learn from time to time.

The background of that application is that I'm using e-mail aliases for each service I subscribe to. So I have a different e-mail for Amazon and Github for example.

I'm using an OpenLDAP server for this configured into a Postfix mta to achieve this.

This learning project consists of a frontend for managing these aliases. Thus, it is always called Aliasmanager.

Introduction

Like the title suggests, this is the third time around I'm starting on a green field with Aliasmanager.

The first one used Qooxdoo for the API-Server and the frontend, but it was kinda monolithic. The second one had an AngularJS frontend and a Flask API-server, but still both parts somehow were merged together.

For the third version I wanted to go microservices. At least develop the API-Server completely separated from the frontend.

What I really like about Flask is that it is a progressive framework. It starts really small and you can add all the things you need and simply plug it in.

Another framework that does the same thing is Nest.

The API-Server

So this time, the API-Server was made using Nest. Nest has a really nice way to structure your application into multiple modules and separates services from controllers. At one point I thought about using a MongoDB backend and that was also very easy to incorporate into Nest, but I skipped that idea and got back to using only the LDAP-Server.

Nest has some pretty nice integrations. For example, authentication and authorization is pretty easy as it integrates into Passport and I really only needed to do some lines of code to be able to have an LDAP authentication for the login endpoint and a secure JWT-based authentication on the other endpoints.

Also, documenting the API was very ease due to Nest's integration of the OpenAPI specification.

The only thing I found hard was that Nest's documentation is somewhat blank in some parts and I really would've liked some kind of API documentation.

But in the end everything went fine and I also really enjoyed the Jest testing integration.

Using Dockerode I was able to remotely manage my docker daemon to ramp up an OpenLDAP server (based on Osixia/OpenLDAP) for the test suites.

However, that resulted in some challenges later.

But read on.

The Frontend

This time I switched to Vue and while Vue itself was a breeze (I know Vue for some time now and really enjoy developing in it), I've actually tried three (!) component frameworks until I got it right.

The first one was Vuetify and while I really enjoyed the Material Design Vuetify uses, the documentation and certain small aspects is a mess. Various parts did not work as described in the documentation or worked differently. For example, I was expecting to have an event triggered when a modal was shown so I could set the focus on one of the input fields. But that was not the case.

The second one I tried was Bootstrap-Vue and here, mostly everything worked as expected and the documentation was okay. However, I didn't like the design that much and the a11n support was somewhat problematic.

The last thing I tried and stuck with was Buefy, an integration of the Bulma CSS framework for Vue. There still were some smaller things (like the mobile view acts a bit weird around the edges), but so far everything was fine and I liked the design much better.

A11n

Also, as I mentioned before, I spared some thoughts about accessibility (or a11n) as I think every frontend developer should do these days. I didn't go as far as I should have, but I used Andi to check for possible a11n flaws. For some part, this was a bit egoistic, because I wanted a good keyboard navigation. And when you have that and good labels for your elements, you're half the way to a good a11n. Please correct me, if I'm wrong about that.

Frontend testing

Another important thing was testing the frontend and Vue incorporates Cypress for proper end-to-end testing and I absolutely like how easy Cypress makes frontend testing having a background in Selenium.

One thing, I still didn't get right was code coverage reporting combined with Vue and Cypress. I know about babel-plugin-istanbul and after babel's cache drove me mad a couple of times I kinda had some code coverage statistics, but they still don't look quite right.

Getting it all together

I'm running the Aliasmanager on my single machine, so I needed a way to bring all parts together and obviously, this is done using Docker and docker-compose for my single machine or even Kubernetes for clusters.

So I made Dockerfiles for each component and just right before finishing it all I saw that little note "Autotests disabled" in Docker hub's autobuild-feature and I checked that out.

And it is actually pretty nifty.

Docker uses containers for running tests on pushes and pull requests. You simply add a new docker-compose file called docker-compose.test.yaml and place a "sut" service into that and docker will run it.

Pretty easy, huh?

Well, yes. It is.

Until your test suite relies on Docker for an LDAP sidecar container.

So I needed to turn to a "Docker-in-Docker"-like infrastructure and control that from Dockerode in my test suite.

For example, I needed the ldap container to be reachable from my test container. As docker-compose creates its own docker network, I had to find out which network it had created and connect the ldap container to that same network.

The second thing was a seed file I needed to fill my ldap server with sample data for the tests. It had to be a file as the image does not support doing this using environment variables and this file was on my machine and in the test container but how to get it into the ldap container from within the test container?

The solution was to use a separated volume and also bind that volume to the ldap container.

So that whole docker testing part was actually the hardest part of all.

Conclusion

I learned a lot this time. From using Nest, to component frameworks for Vue to good testing using Jest and Cypress and advanced autobuild and -test features of Docker hub.

You can check out all the parts here:

Photo by Chad Peltola on Unsplash

CloudControl 2.0.0-alpha1 (and how I learned Go)

Dennis Ploeger — Sun, 13 Sep 2020 16:03:56 +0000

As you might know, CloudControl is DoDevOps' cloud engineer toolbox, which supplies cloud engineers working in different clouds with common tools in an easy-to-deploy container environment suitable for multiple projects.

I always wasn't quite happy with CloudControl's initialization process. It was very cluttered, didn't point out the relevant information and... well, ugly.

At first, I came up with an idea to use Dialog scripts to display some appealing user interface during the process, but that didn't work out mostly because of the Azure flavour's sign up process.

Then I thought, why not give a web client a go? I'm already used to Vue, so it wouldn't be that hard. One thing was a problem, though: I'd need a web/api-server that hooks up into the running initialization process. I didn't want to move away from shell scripts for the initialization of the flavour and features, because 1) they work quite well and 2) they're not really an effort to write for other people who want to add features.

Well. Two process running alongside tapping into each other plus a need for a single binary with a low footprint? That really cried out for Go.

As I've commented in another post, I tried starting with Go several times and never succeeded. But those requirements really were a perfect fit. So I tried again.

I downloaded the most current version of Go, checked out the tutorials again and got going.

Then, I needed the first external dependency and I remembered, that Go really was a PITA with this the last time I checked.

But, no. Nevermore. The Go folks finally seemed to agree on a good way to document and implement external dependencies with a go.mod file and dumped the nasty GOPATH. And everything was nicely supported by my IDE-of-choice IntelliJ Idea. Just add the required import, let Idea sync the dependencies and you're good to go. Yay!

The rest was classic trial-and-error until I came up with a nice looking Vue frontend (thanks to vuetify) and a stable API server (using gin) that delivers information from then goroutine, which handles the initialization.

With Docker multi-stage-builds it was also possible to build the vue client, the go server and the CloudControl flavour without any dependencies on the client. Oh, and I switched to GitHub Actions (because Docker automated builds didn't support build scripts)

So, that was my journey and I'm pretty happy with the end result. If you haven't already, please check it out and let me know what you think.

Announcing CloudControl - the cloud engineer's toolbox ☁️ 🧰

Dennis Ploeger — Wed, 18 Dec 2019 08:17:54 +0000

We happen to be in a multitude of different projects at the same time. Switching from project to project is sometimes hard as the tooling and the configuration changes from project to project.

Now in the days of cloud deployments, this can be narrowed down to just a bunch of tools like Terraform, Kubernetes or Helm, but we still felt that some standardization would make our lives much easier.

That's why we made CloudControl - the cloud engineer's toolbox (our first repository with emojis btw!).

CloudControl comes (or will eventually come) in various flavours fitting the specific cloud provider you're using. We started with Azure as we're currently mostly using that, but are of course open for other flavours.

Also for each flavour, we install a variety of features to support you in your daily work. Currently we support the following features:

To use CloudControl, you can check out our sample azure compose file as a starting point.

We have build CloudControl in a modular way, allowing for extending the supported features and flavours at any time. So if you're missing something, please get in touch and/or provide a PR.

Header image: Florian Richter - Toolbox

Managing integration systems using clone playbooks

Dennis Ploeger — Sun, 24 Nov 2019 17:25:45 +0000

You totally can test stuff, fix bugs and check out how to implement new features on production!

If you're a masochist, that is.

Usually a production system is a no-no for anything development related. Even if bugs happen on production, the best practice is to reproduce those bug on systems other than production.

These systems are usually called integration, development, acceptance or QA with various understandings from project to project.

But how can you reproduce a bug on a system that is different from production?
How can you bring the database, data and application files from production to a different system.

At my employer, kps we started doing that using Bash scripts. That worked quite well until we had more demands concerning speed, flexibility, complexity and - let's be honest - readability.

To conquer those we moved away from Bash scripts and to Ansible playbooks.

In case you lived among a flock of sheeps for the last ten years, Ansible is a software belonging to the "Configuration Management System" category. It is used to describe how a bunch of servers should be installed and configured. It's written in Python and describes itself as "agentless" (although it actually needs an SSH access to your system and an installed Python environment).

Ansible works using so called playbooks consisting of multiple plays against target systems. Plays have a bunch of tasks that are run on these systems.
There's a vast list of modules available providing tasks for every flavor. There are file system tasks, database tasks (for all sorts of databases) and so forth. Check out their documentation for details.

The premise

But I'm not talking about my professional life today. Instead, let me tell you that I'm active in an open air theater association called the "Waldbühne Heessen" (sorry, german only website). I started as an actor there, but you know the common way for people working in the IT business. So I'm now managing their IT stuff together with two fellow actors.

One of the systems I'm responsible for is a site the association uses for organizing auditions, shows and the other stuff that happens throughout the year. Additionally, it contains a bulletin board for discussing things.

The site is based on the Elgg framework, a platform for social networking sites. Elgg is a modern php framework, utilizes caching, a data directory and a database.

Now we needed to migrate from Elgg 2.3 to Elgg 3.2, which was a major jump with several breaking changes and breaking a lot of plugins. As a good SRE I knew, I had to build a proper integration system to prepare that move and to use it as a showcase for my fellow members.

Building a clone playbook

It's actually quite easy to build a clone playbook, because it simply mimics what you would do manually. So to build my playbook, I checked out what I had to do to clone my production data to an integration system.

From my experience with the clones from my employer I knew the basic steps usually required:

Dump the database
Augment the database dump file to match the integration system (This usually includes changing URLs or paths)
Restore the database onto the target database host
Copy the application files
Copy the data files
Augment the application configuration file to match the integration system (This obviously includes the database settings, paths and some minor stuff)
Additional works (i.e. Setting an announcement banner to warn the user, that they're on the integration system)

As an additional topping, I wanted to include all stuff required to update the system to the new version as well. But I wanted to do that dynamically, so I could just switch it off when I had migrated the production system.

Transforming the manual steps into a clone playbook was mostly just checking for fitting modules in the Ansible docs and figuring out how they needed to be configured (which was taking the most time frankly).

For the database tasks, the mysql_db task was used. It supports dumping and restoring databases and also running SQL scripts. The file tasks mostly compress folders using the archive task and copies them around. Augmenting the database dump or application settings, I used the replace and lineinfile tasks.

Building the inventory

The playbook itself is rather static. It's basically just a list of tasks in a Yaml file, that Ansible runs from top to bottom.

Parametrizing the playbook is done using inventory files. They hold the connections to the target hosts, but also parameters like database username and paths.

The inventory files can be written in an ini and yaml flavor. After I initially started using the ini flavor because we used the same at my employer's I finally switched to yaml format because I needed to configure lists and object values for parameters.

That way I could add an external task file with the update tasks into the inventory, which is included into the main playbook using include_tasks Ansible task and could then clone the integration server and migrate in one step.

For sensitive data like passwords, Ansible brings a vault solution, that encrypts the values in the files using AES (or other cryptos you configure). You encrypt the values using a passphrase and simply use the same passphrase when running the playbook.

Bringing it all together

Of course, this all wasn't a one shot. I had to use several tests to finally finalize the playbook and have it working correctly. Depending of the size of the system, this can take some time. So prepare yourself with enough coffee for the task.

As a reference, if you're interested, I open sourced the whole stuff on the association's github organization. If you have questions, don't hesitate to ask.

🎁 Bonus! Building a local development environment

I don't know about you but I don't like to do stuff twice. To develop the site and plugins we're using a local containerized development environment based on Docker with mounted database and application paths. So why not use the clone playbook to clone production for the local environment?

Ansible supports us there quite well by accepting docker connections to target systems using the local docker daemon.

So I wrapped up a compose file that starts a database and an application server (we created our own Elgg-compatible application server image). This servers are then filled using Ansible and I can simply tar the mounted volumes, bring them to my server and start my development environment, also using a compose file.

Voilà.

(Cover Image: Night. Clone by AdNorrel)

DevOps/SRE Fulltime Dortmund, Germany

Dennis Ploeger — Fri, 11 Oct 2019 14:09:36 +0000

About Us

Hey! We're a nice little team devoted to consult and support our mostly e-commerce-focused developer teams with DevOps-related hot stuff like automation, containerization, orchestration and cloud technologies.

About The Opportunity

We're searching for a new team member, that has either an ops background and dev interest or vice versa. It's a permanent, full time job offer located in Dortmund, Germany with partial home office possibilities.

We know that we probably can't find someone, who has all skills denoted below, but if you're open and interested in learning new things, you might as well fit in.

Skill & Qualifications

German and English language skills are required.

For the rest, please check out the official job offer on our website.

How To Apply

First, check out the official job offer on our website and then apply online right there.

Please feel free to leave questions in the comments section.

tflookup - Developer diary Epilogue

Dennis Ploeger — Tue, 09 Jul 2019 07:14:42 +0000

Dear diary,

it's been some days since I wrote to you about my experience with creating a Terraform documentation lookup app and while I'm using tflookup on a daily, I noticed something.

When I start my work in the morning and have the first interest in looking up some provider resource of Terraform, I naturally check out tflookup. And that is no fun experience, because I have to wait and waiiiiit until tflookup finally comes up.

That's because, Heroku has something they call dyno sleeping for the free subscription and as not many other people tend to use tflookup currently, the app gets all sleepy and falls into a deep slumber until I wake it up in the morning.

I don't want to pay Heroku for this little side project of mine and being a simple Node.js app, that is easily deployable, I simply deployed it on my server, that I manage for years (and that is already active rebuilding the tflookup index each night)

So from now on, I will be checking out tflookup on a new address.

Yours
Dennis

tflookup - Developer Diary Part 5

Dennis Ploeger — Wed, 05 Jun 2019 14:17:56 +0000

Dear Diary!

MY LOOKUP APP WORKS! Yayy!

Locally at least.

But what good is a web app, if you can only enjoy it yourself?

So I needed a way to deploy my app automatically (and for free).

Luckily, Heroku is around. Heroku is a simple app hosting provider, which hosts very simple apps for free. They connect to your github repository and deploy the app that's there.

Very simple.

Wrong

I guess, that's true for most apps, but I had some difficulties:

I had a frontend and a backend to compile before starting the app
I had to download the prerendered index before starting the app

Heroku's documentation is also quite extensive. However, I couldn't get my head around their release stage. All my tries to configure the releases right didn't work.

So finally, I simply wrapped my complete application into a docker container (which was good nonetheless) and used that to deploy the final app to Heroku using Herokus container deployment feature.

And now, my dear diary, I have to end my writings. I have finally made my lookup app. It's still not shiny or stable, but it works and I'm quite happy with it.

If anybody reading this might find it interesting and want to use it, they can all find it here:

https://tflookup.herokuapp.com/

Yours
Dennis

The End

This post is one of five posts from the tflookup developer diary series

Cover Image: "diary writing" by Fredrik Rubensson

tflookup - Developer Diary Part 4

Dennis Ploeger — Wed, 05 Jun 2019 14:09:08 +0000

Dear Diary!

So I finished my REST service which will deliver my search results. But what good is that without an appealing frontend.

After I was nearly blown away by the overwhelming good critics about Vue.js at last year's enterjs I took the Vue-way immediately.

I think, Vue is very easy compared to other frameworks out there and also very well structured.

Also, it has proper Typescript support and good documentation.

So I started a Vue project using Vue CLI (which has an amazing new UI btw).

A simple test of the REST calls worked fine, but I wanted something more appealing.

Luckily, Vuetify has some nice Material Design components ready for Vue and also a nice autocomplete component.

This method watches the query input field and uses the REST backend to fill the results. I used a delayed promise there to allow the user to input the complete search text before I use the text to search the backend.

The autocomplete than renders a so-called "slot" with the item results.

Selecting a result would trigger a location change to the actual terraform documentation page.

The hard thing here was to get my head around how Vue plugins work, how they work in Typescript and how Vuetify components and their specialities (like slots) work. But the good examples and documentation for Vuetify and Vue helped a great deal.

Yours
Dennis

This post is one of five posts from the tflookup developer diary series

Cover Image: "diary writing" by Fredrik Rubensson

DEV Community: Dennis Ploeger

Github Action for the Godot Asset library

deep-entertainment / godot-asset-lib-action

A github action to manage assets on the Godot asset lib

Godot asset lib action

Inputs

action

username

password

assetId

assetTemplate

baseUrl

Outputs

Announcing EgoVenture

The past

The Present

The future

Feather > Sword

Who we are

Where we were

Starting is hard

Breaking down document types

"Suggesting" instead of "Defining"

The styleguide

Language!

Problem with structure. The.

Keeping up with the community

Where we are

Parting suggestions

Document states

Table of contents

Templates

Don't reinvent the wheel

Accessibility

The future is yet to come

So I released an Adventure Game

Today

April

November

The team

The rest

Art

Programming

Wrapping it up

The third installment of my learning project

Prologue

Introduction

The API-Server

The Frontend

A11n

Frontend testing

Getting it all together

Conclusion

CloudControl 2.0.0-alpha1 (and how I learned Go)

Announcing CloudControl - the cloud engineer's toolbox ☁️ 🧰

Managing integration systems using clone playbooks

The premise

Building a clone playbook

Building the inventory

Bringing it all together

🎁 Bonus! Building a local development environment

DevOps/SRE Fulltime Dortmund, Germany

About Us

About The Opportunity

Skill & Qualifications

How To Apply

tflookup - Developer diary Epilogue

tflookup - Developer Diary Part 5

tflookup - Developer Diary Part 4

`action`

`username`

`password`

`assetId`

`assetTemplate`

`baseUrl`