I had recently installed ecoDMS 18.09 on a Debian 10.5 VM and it was a pleasant experience overall. However, the following things had to be done differently compared to the installation manual
sudo apt-get install gnupg (this seems to be installed out-of-the-box on Ubuntu)
- Do not install any Java environment but let this be handled by the normal dependency management
The system is currently in light use (still in testing) for my newly founded company and runs quite well. The VM is hosted on ESXi 6 that runs on a Celeron 3900 (yes, two cores) and for a single user with just a few documents stored the performance is really nice.
I so far intend to stay with that system and will keep you updated.
If you are looking for a cheap lavalier microphone to have better sound at video conferences or to get started with YouTube I can recommend the BOYA BY-M1. It provides really good value for money and can usually be found for around 20 Euros (25 US Dollars) online. I got mine from Amazon (affiliate link to amazon.com / amazon.de) for about 18 Euros.
One differentiator compared to other similar microphones that are often advertised specifically for use with smartphones, is that the BY-M1 can also be used with devices that do not provide power. Smartphones and modern laptops usually do this, but professional audio equipment (e.g. dedicated audio recorders) only provides 48 V phantom power and will therefore not work with a typical smartphone microphone. For those cases the BY-M1 comes with a small battery (LR44) and also a 1/4″ TRS adapter.
If you use a different microphone I would be interested to hear about your experience in the comments.
This question comes up at time code 8:45 in the video and I found the response quite intriguing. But overall this video is more about the impact of COVID-19 on teaching and I highly recommend watching it.
As per “Google Cloud Application Modernization Program: Get to the future faster” (citing DevOps Research and Assessment) “teams that ship code numerous times per day are 1.53 times more likely to achieve or exceed their commercial goals, including profitability, and market share.” What many people will make out of this is that it should be sufficient to increase the release rate to be successful.
A similar study (I cannot remember the source right now) shows that people who use Firefox as their web browser have a better career. And I guess there are many more comparable “findings” that you can come across. Unfortunately they are somewhere between misleading and completely wrong.
The problem is that such statements often present two things as cause and effect. But in reality those two things are “only” correlated. So both the high deployment rate and commercial success are effects of the same cause. And that cause is that these teams have experienced people who really know what they are doing.
I had recently installed Linux in a dual-boot setup on a test machine (an old Lenovo Thinkpad T430). What proved more difficult than in former times was to restore the original state. Most of the recommendations I found online were less than helpful. In particular, many of them ignored the fact that there are two entirely different approaches out there to handle the boot: UEFI and legacy or GPT and MBR respectively. My machine was using MBR (Master Boot Record), given its age.
What finally solved the issue was the following command:
C:\> bootsect /nt60 c: /mbr
I used a USB stick with Windows 10 Installer, but since then learned that you can get to the “repair” console easier, if your Windows 10 still starts. All you need to do is perform the following steps:
- Log off.
- When the login screen appears, press a key so that the password field shows up. This will also enable the “power” button in the lower right corner of the screen.
- Press and hold shift
- Left-click the power and choose “Restart”
- Let go of the shift key and the repair menu appears.
- Go to
Maths can be interesting …
When a group of people is assigned a task they never had to deal with before, they often start with brainstorming. So you have a number of folks who typically are not exactly knowledgeable about something, but at the same time try to agree on an approach for dealing with it. So they start with a discussion on what to do, who should be assigned what activity etc.
The problem is, that this is not brainstorming. It is group of people talking about something that they do not know much about. So a lot of assumptions are made, often not even consciously. People will simply extrapolate their past experiences into the new topic. But this approach does not deliver particularly good results.
The relatively obvious problem is inefficiency. Instead of the whole group talking 15 minutes about something, prior research by just a single person would have produced at least the same result. (Well, probably a better one.) The bigger problem, though, is about effectiveness. In other words: The result of the group discussion will usually not be a truly good solution. Again for lack of research and knowledge.
From a team dynamics perspective there is another problem. There are people who tend to dominate such free-floating discussions. Apart from personality, the folks talking most are usually those that know least about the subject. Because those that understand things at least partially, know that it is not so easy. But there is no time for careful deliberation during such a meeting. So decisions are made based on the least helpful content and the people who know best go out of the meeting frustrated.
Luckily, it is very easy to overcome this. Just task people to do some research on their own before the meeting. You will have a much more thoughtful discussion.
For the fans of Uncle Bob (aka Robert C. Martin) here is another interesting video.
The title is a quote from Robert C. Martin during a conference talk on clean code. For a long time now (I am getting old) I have followed this approach and it has produced remarkable results. For a bit more than four years I had been responsible for a corporate integration platform. I had built and run it following DevOps principles so that everything was fully automated. No manual maintenance work had been necessary at all, log files were archived, deleted after their retention period etc. This had freed up a lot of time. Time which I used to keep my codebase clean.
Particular focus was put onto the structure. And that had been a really tough job. Much tougher than I anticipated, to be quite frank. But I had paid off. Instead of writing a lot of conventional documentation, the well thought-out structure allowed me to find stuff in a completely intuitive way. Because, believe me, six months after you have written something, you do not remember much about it. But if you need a certain kind of functionality and do not only find the corresponding module immediately, but also from a first look make a correct guess how the parameters are meant to be used, that is truly rewarding.
Having experienced this first hand has greatly influenced my work since then. And I am more convinced then ever, that this is not beautifying for the sake of it. But instead it is a mandatory requirement and a prerequisite for business agility.
Microservices are not always helpful, what a surprise 😉