As Visual Studio Code became my main editor, I often have more than one VS Code window open. This gets confusing after some time. To keep track in which project you are currently working, I thought of using different color themes by project.
As usual, once you know the trick, this is quite easy. Navigate to File / Preferences / Settings and select the Workspace tab.
The setting for the Color Theme you choose here will be used whenever this particular folder is opened. That way you can easily distinguish between open Visual Studio Code windows.
Simon Brown -inventor of the C4 model – recently came up with a checklist about diagrams and notations.
A few people have asked me for this recently so … if you’re looking for my software architecture diagram notation checklist, you can find it here…
Although it seems obvious what is checked in this list, almost every single diagram I have encountered in my career did not provide all the information. Copy it, print it, as an architect (and software developer) carry it with you – and use it.
With platforms like Twitter, Slack or Microsoft Teams, animated GIFs have been revived. In addition to emojis, animated GIFs seem to be the way to express yourself on the web. In case you are in the need to create your own animated GIFs, check out ScreenToGIF.
This tool allows you to record a selected area of your screen, live feed from your webcam or live drawings from a sketchboard. Afterwards, you can edit and save the animation as a gif or video.
It comes with a nice screen recorder frame and a whole list of features to create animated GIFs, Videos and so on. You can record your screen, capture the webcam or whiteboard drawing.s
It also comes as a single file, which easily allows you to deploy it almost everywhere, even to keep it on a USB stick.
After three months of gameplay participating in the Distant Worlds 2 expedition in Elite Dangerous, I managed to arrive at Beagle Point, one of the farthest systems in the galaxy.
This included several thousand jumps (each jump takes about one to two minutes), scooping fuel, repairing the ship and such things. There was a tough schedule by the organizers, including several waypoints on the expedition.
There is already a in-game sickness called Space Madness.
Space madness is a psychological condition that some pilots get while traveling in deep space for long periods. It’s a bit like vertigo, and is caused by being adrift without any reference points.
Once you get there you will have an incredible view of our galaxy.
As far as I know, the simulation behind the game creates systems when being visited the very first time. There seem to be some awesome algorithms. E.g. when Kepler 425reb was discovered, the simulation already had a similar system generated before and was updated accordingly with the real data.
I finally arrived there with a delay of two weeks behind the official schedule. All pilots arriving there, are rewarded with a certificate of completion, which I can proudly present.
There is also an in-game reward, an emblem to be shown on your ship. This, however, can be only equipped when being docked at a spaceport. This will take another few months to arrive at the nearest station.
A few thousand gamers went there and back. If you want to follow my trip back, you can have a look at my Twich channel where I stream my way back when being in the game.
You don’t know what an Octocat is? If you don’t there is probably no need to read on, just enjoy my Octocat.
aheil’s Octocat
If you want to know, let me help you. That’s what Wikipedia says:
GitHub’s mascot is an anthropomorphized “octocat” with five octopus-like arms.
The character was created by graphic designer Simon Oxley as clip art to sell on iStock, a website that enables designers to market royalty-free digital images.
GitHub became interested in Oxley’s work after Twitter selected a bird that he designed for their own logo. The illustration GitHub chose was a character that Oxley had named Octopuss. Since GitHub wanted Octopuss for their logo (a use that the iStock license disallows), they negotiated with Oxley to buy exclusive rights to the image.
GitHub renamed Octopuss to Octocat, and trademarked the character along with the new name. Later, GitHub hired illustrator Cameron McEfee to adapt Octocat for different purposes on the website and promotional materials; McEfee and various GitHub users have since created hundreds of variations of the character, which are available on The Octodex
If you want, you can get you very own Octocat at https://myoctocat.com/ and customize the hell out of it:
Take a break from your build and create an Octocat that’s all you, from whisker tip to tail.
I currently manage all my Docker containers in my servers via Ansible. However, either for setting up new containers, testing new images or debugging in the case of emergency, I ssh into my server and fiddle a lot with the shell.
Promising Web based Docker Compose Management?
I came along Docker Compose UI which provides a nice web-based user interface to work with Docker Compose.
Docker Compose UI is a web interface for Docker Compose.
The aim of this project is to provide a minimal HTTP API on top of Docker Compose while maintaining full interoperability with Docker Compose CLI.
The application can be deployed as a single container, there are no dependencies nor databases to install.
It comes as Docker image itself, which again makes it really easy to deploy. To test it locally, just check out the GitHub repository and run docker-compose up.
To get the demo project running was quite easy. But…
There is a Catch
When I rolled out Docker Compose UI to one of my servers it still showed the demo projects even I changed the overall config
To do so, the documentation of the project is not the best
After grepping through the entire files, I did not find anything that gave me a hint where the demo projects might come from
To me (I might be wrong) it looks like the demo information is built into the Docker image
The GitHub project was updated the last time about 12 months ago
Conclusion
Docker Compose UI would be a very useful project. However, the project looks very abandoned to me. Although there are 12 contributors, the very last pull request is open since 2017. The readme was updated the last time in 2018. I might have a closer look into the project or fork it at one point. Until then, it has to stay on the bench.
I recently started to write quite a lot of stuff on my laptop down in plain Markdown. It comes handy when I need to put the information on a Web page or in other documents.
Also using a revisioning system like Git is much more convenient when using Markdown.
Therefore, I was looking for a possibility to write my blog articles also in Markdown.
Jetpack Approach
With Jetpack there is a possibility to enable Markdown syntax in your WordPress editor. To do so, navigate to Jetpackand then select Writing.
Scroll down and toggle Write posts or pages in plain-text Mardown syntax.
Markdown in Comments
In addition, you might want to enable Markdown for comments in the Diskussion section by toggling Enable Mardown use for comments.
If you now head to the WordPress editor, you will realize that Markdown is still not supported. To use Markdown you actually have to add a Markdown block. And here comes the drawback.
The Drawback
While you can now wite Markdown in the block, you will end up with a mix of different types of blocks in your editor. That way Markdown did not help me a lot to simplify my writing of blog articles.
Conclusion
While you can add Markdown support to WordPress with ease, it is rather unsatisfying. I have different goals in mind where I have to dig a bit deeper, as I want
to write blog articles offline in Markdown syntax
push them to git repository – including images –
and post them in WordPress.
There are probably some solutions out there, I haven’t found yet.
Some weeks ago I ranted about the dawn of Google Reader and the declining of RSS and Atom feeds on the Web. I used this extensively, but to be honest, once Google Reader was canceled. After trying some hosted services, I was pointed to Tiny Tiny RSS, which is a lightweight feed reader which can be hosted by yourself.
Tiny Tiny RSS is a free and open source web-based news feed (RSS/Atom) reader and aggregator
The installation and update process, however, is not very intuitive and requires a couple of manuals steps. In addition, you need PHP as well as a MySQL or Postgres database.
The installation and update process, however, is not very intuitive and requires a couple of manuals steps. In addition, you need PHP as well as a MySQL or Postgres database.
Eventually, I was looking for Docker containers, but none of the images I evaluated was easy to set up. Therefore, I decided to create my own image with one major goal:
Make it easy to setup and run Tiny Tiny RSS
I created the docker-ttrss GitHub project to achieve exactly this goal. To get a standard ttrss up and running, simply checkout the repository and start the containers.
git clone https://github.com/aheil/docker-ttrss.git
docker-compose up
You’ll have a basic installation with one NGINX one PHP (ttrss) and one Postgres container up and running. To access ttrss, navigate to http://locahost:8080. You can log in using the standard credentials:
Login: admin Password: password
It is highly recommended to change the password and create a user account afterwards.
I use this image already day by day – still improving it step by step. It takes away the burden of setting up and initializing the database. If you feel this useful, please let me know by opening an issue on GitHub.
In my current team (actually the whole company) we end up within the dependency hell day by day. Not only that many teams just don’t do any versioning, if they do there are no clear rules how they should do.
In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.
In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.
As you might now, I am currently working on a small Docker project to containerize ttrss.
I am using GitHub and Docker just for the sake of keeping up to date with the the features of both plattforms.
Although this might be an old feature, well known in the Git and/or GitHub community, I “accidentally” wrote a commit message fixed #2: …
Well, GitHub automatically closed this issue during the process of creating the pull request and merging it into the master. What an awesome feature, especially when found this was!
