Hello and welcome to my little nock of the internet. Here I have my blog which mainly contain posts about tech, the outdoors, cooking, and some times mead brewing.
A bit of background information before you step into my world of crazy. I am Lars, a.k.a. looopTools, a Software Engineer living in East Jutland, Denmark. I have 10+ years of experience from industry mainly through student positions, but also as self-employed consultant, or full-time employee. I mainly work in low-level user space, high-level kernel space, and storage systems in general. Besides research and software development, I also love the outdoors and try to go out as often as possible (not enough at the moment) and I am an aspiring author currently working on a few different novels. I also dabble in being a more advance home cook and baker, which you may see some posts about. Finally I like the ancient art of brewing mead, a.k.a. honey wine, and experiment with different flavour combinations and ageing times.
Switching back to Visual Studio from Visual Studio Code
A couple of months ago I updated Visual Studio 2022 which broke a lot of important things, like the save functionality. I had to look around for an alternative, and my first thought was Emacs, of course, sadly I could not get omni-sharp or omisharp-roslyn to work. So the next best option was Visual Studio Code, which I switched to.
Then an update was made to Visual Studio which fixed my problems or some of them, enough that I decided to move back. This blog post will describe why I moved back to Visual Studio. Before we continue for the rest of this blog post, VS will mean Visual Studio, and VSC will mean Visual Studio Code.
First, I want to say that VSC impressed me a lot.
It was a lot snappier (this changed) than the first time around it, on my old blog I had a post about why I disliked both VSC and Atom and how slow both were (for the same reason… electron) was one of my main cavities with these two editors.
Also, I would like to amend that I only use VS and VSCode for C# and Blazor/MudBlazor, for everything else (JavaScript, Go, Python, …) I still use Emacs.
Project Dependencies and Nuget Management
One of the things I like the most about Rust and Ruby is dependency management. It is so simple compared to any other language, YES, I SAID THAT!!!
With C# it is somewhat easy with Nugets and the UI in VS.
However, the story is a little different in VSC.
First of all internal project dependencies (if you have more than one project in a solution) is essentially handled by adding the dependency to the .csproj
, which I have no issue with. But, there is an issue in VSC. By default there is (to my knowledge) no built-in way to do this other than adding the dependencies by hand to the .csproj
file, which is pretty annoying. Yet there is a plug-in for this vscode-solution-explorer, it does other things too. But I have tried, more than once, that would end up with the .csproj
file in a corrupt state and I would have to fix it by hand, ending up with just having done it by hand from the start being quicker.
Another issue comes with nuget packages, actually two issues.
In VSC, you should be able to type Ctrl + Shift + P
, and Select Nuget package Manager: Add Package, which I can and I can install Nuget packages. However, when I push to git all changes to the repo, colleagues get an error that reference to X is not found, where X is an element in the Nuget package. This is weird because if I run dotnet add <PROJECT> package <PACKAGE_NAME>
with the options, I need (see stack overflow answer) then it works.
I found on IRC that I am not the only one with this issue, but it seems like it fixes itself after certain updates. I just never hit one of those updates.
Additionally, and this is not an issue with VSC but the Nuget command line tool (I think) getting access to private Nuget repos outside of VS just never worked for me, even though I had to configure it for VS with the command line tool. Maybe I missed something in the setup.
Debugging
Now this one is probably the most significant problem, I could not get debugging to work. How you tried developing without the option of debugging, it sucks.
I have to be 100% honest. A colleague of mine does use VSC permanently and has debugging working. But we spent roughly 2 hours together trying to figure out what in the name of hell was wrong with my setup. But we simply could not find out what was wrong.
The debugger did seem to run, but breakpoints just never activated.
From our point of view, it looked like there was a miscommunication between the debugger and VSC about where breakpoints were in the code.
I do have a lead about where the issue might be, but I haven’t had the time to confirm it and fix it.
Could not find an alternative to Code Maid
Code Maid is a nifty plug-in to VS which allows you to clean up and format your code according to a specification. It is kind of similar to ClangFormat if you are familiar with that.
For some reason, I could not find an alternative to VSC, I am honestly surprised that there does not exist a port of Code Maid to VSC.
Code Maid is so nice and quickly removes unused imports and more, and I found that I really missed it in VSC as I spend quite some time removing unused imports.
Plug-In Configuration
Okay, this may be the plug-ins problem and not VSC, but it is still through VSC I experience the problem, so it is the first encounter with this issue. The issue is that some plugins require you to alter a JSON file to configure, others utilize drop-downs and text boxes, and even some use a mixture.
This is insanely annoying, first of all, because there is no coherence, and you have to remember which plug-ins that do it in which way. Some plug-ins do not inform the user that advanced configurations are only available in the JSON configuration. It is even hidden that the file exists at all. Granted a little bit of searching the web will reveal it, but for an editor that kind of beats the drums of easy-to-use, this is a letdown.
Mudblazor never worked properly
For frontend development in C# I use Mudblazor (this is not a recommendation), blazor/mudblazor is smart in theory, not always so much in practice. ANWYAYS this is a VSC post.
In VS, the editor will most of the time, be able to find the MudBlazor tag you want. But for some reason, in VSC, every time I started a new .razor
(Blazor/Mudblazor) file I would have to read-load the project for VSC to understand I wanted access to the Mudblazor components. The former mentioned colleague told me he has a similar issue.
This is quite annoying, but it was a problem I could live with, if not for the other issues.
Weird CSV issue
I work with CSV’s a lot and have to be able to handle them, and here VSC failed me big time. For some stupid reason I could not figure out, visual studio kept adding CR LR pairs (\r\n) to the end of lines in CSV (Line Ending explanation). Now, this would be perfectly fine, if I had made the mistake of setting VSC to Microsoft’s (weird) default character encoding for Windows, but I have it configured to be default UTF-8 and VSC told me the pane was open with UTF-8. I could get as far as to identify that it was only an issue with CSVs, which is even weirder because I do not have a plug-in for CSVs installed. Additionally, neither Emacs, Sublime Text, Notepad++, nor VS has the issue.
If anyone can explain it, please reach out.
Resource usage and UI Stuttering
Now, we come to my probably biggest issue and a first-world problem with VSC. In the beginning, it was snappy and pretty sweet to use. However, as I added more and more plug-ins (10 in total), the UI started lagging, and I even experienced characters appearing long after I typed them, which is pretty frustrating. I type fast but not that fast. By enabling and disabling different plug-ins, I could conclude that it was not individual plug-ins but rather the amount. My work pc has 32GB of RAM and a 2.3GHz CPU this should not be a problem. For reference, and as stated in my post Stop using Electron, I find that VSC use around 1.3GB of RAM in Idle, and I have seen it use way over 12GB when I code (20+ files open simultaneously). That honestly worries me when VS, a fully-fledged IDE, uses way less (around 8GB) in the same situation. It was so annoying and got to a point where I sometimes found it took longer to close VSC than closing VS and shutting down windows combined.
Now I do have a suspicion about resource usage, and that is Electron. Yes, I am campaigning against it, but let us face it I use a lot of Electron because I have to (hello Signal my friend). But that aside, I do not have similar issues in Emacs with roughly the same configuration, nor do I have it in Vim. I guess it has something to do with how plug-ins are loaded/handled in VSC. But I cannot confirm it.
Conclusion
So this is why I have decided to move back to Visual Studio. Simply because I had a load of problems, nothing else. As an editor, Visual Studio Code is really solid, but as soon as you start fiddling a little bit with it, in particular adding plug-ins or doing more advanced stuff, it starts to fall apart, in my opinion. Please note, that I still find VS clunky, but there simply is no alternative for C# development besides VSC in my opinion. I would like to dive a little bit more into either using Vim or Emacs again at a later time. But for now, I am sticking with VS.
I would like to make the following closing remark: The VSC Community is by far one of if not the most welcoming editor communities I have ever entered, and I can only wish for the Emacs and Vim Communities to morph into something like the VSC community.
./Lars
Why I prefer physical notebooks over software-based
Most Software Professionals and Engineers take and keep notes in some form, which is an essential tool. This post will cover why I prefer physical notebooks over their software-based counterpart. Before I go into detail, I will say that I also keep notes on computers, and I am an avid Org Mode user. However, I find physical notebooks more suitable to my needs for a couple of reasons, which, as stated, I will cover here.
First portability! And your first question is probably what the heck is he talking hasn’t he heard about laptops, phones, and tablets? Well, of course, I have, but let me tell you a little secret, I have attended meetings where all electronic devices were disallowed in the room, even in buildings. Therefore, pen and paper was the only option for notes. In extension, I also find that I lose focus on the meeting or presentation given if I sit with a laptop, which I do not do when I only have a notebook. So many times, I will not bring a laptop to a meeting, and I will not pull out my phone.
Then there is the doodling. I have for decades used associative memory techniques without knowing it. During a meeting, lecture, or whatever, if I doodle at the same time next to my notes, I can recall almost all information from a meeting (I have scared people this way, it is fun) if I combine my notes and the doodles I make. Doing this allows me to scan my notes and get a map of what happened during the meeting. I can not do something similar in most note-taking tools on computers or tablets. The only app I found that comes close is GoodNotes for Apple’s iPad. Unfortunately, I do not have an iPad or an Apple Pencil, and for Android, I have not found an app that gets close to GoodNotes.
But my drawings are not just limited to doodles. I regularly draw up system diagrams and architectures as I research topics, new features, new products, etc. Thereby as I draw, I can visualise what my plan is, and I can have multiple designs easily side by side. It is super convenient. I also draw things like sequence diagrams or flow charts, which are very handy. Also, when I outline books or plan plots for stories. I draw maps where I plot the course of people or do other weirdness. It is convenient, and again for a software version, GoodNotes is the only close thing (I am guessing I should state by now that this post is not sponsored by GoodNotes, but it is fantastic).
Then there is flexibility in the workflow. For example, I keep multiple notebooks for different topics. Which can be quickly done in software and in physical form. But for some reason, context switching is easier for me when I swap physical items over changing a file or tab in the software. So to me, it is a more flexible workflow, and I know I am not the only one that has it that way.
Writing by hand enhances my recollection of the subject. I have for years and years aspired to have my notes electronically instead of on paper. But every time I have tried, I have realised that with notes I write by hand (using a pencil/pen), I can recall things better and easier. So another clear advantage for handwritten notes: GoodNotes is giving me some of the same benefits.
Finally, and a little bit funny, (joke) ENCRYPTION!
I have the benefit of having handwriting which not even doctors can read.
This means people cannot just read me over the shoulders or upside down, that is pretty cool and something I like.
Yes, I can read my own handwriting.
So this is basically why I prefer physical notebooks over software-based ones.
./Lars
Why I read books
For some reason, many people find it weird that I read books and own many books. They do not get why I do not just watch television series instead. So I decided to write a blog post about it.
First of I do watch series, movies, and YouTube. I am not anti-modern culture. But there is just something about books, in all their forms, printed, ebooks, and audiobooks, that is amazing to me, and I see certain benefits when I read compared to periods where I do not.
Now let us get into it. In periods where I do not read and only watch YouTube videos of like 5-10 minutes in length, I see a decrease in the amount of time I can focus. This also holds true for 10-20 minutes long TV series episodes. I am aware that no study has ever concluded that short video clips can affect attention span, but this is my own experience. This is simply unacceptable to me, as I do not want my attention span to decrease. On the contrary, I would actually like to expand it. Her books help. I observe that in periods where I read as little as 10 minutes per day (yes, sometimes I time it), I still see a positive impact on my attention span. Therefore, I like to read and read a lot. To be honest, during my masters and PhD periods, I did not read anything for enjoyment, although I did buy books, and it has taken some time for me to ramp back up, and I am far from the speed I used to be at before. This leads me to the following reason, destressing, Reading helps me a lot in terms of handling daily stress, and it lets me disappear into another world, kind of the same way as meditation does.
Next, letting my fantasy loose. I have a very vivid imagination. I can entirely create scenes with sound effects and everything in my head on the fly as I read. I like this; it feels like hallucinating, and I enjoy it as it fully lets me submerge into a land of dragons, sail the open sea, etc. To me, it is truly magical and gives my brain time off, so again, destressing. Just ask my girlfriend and mom how long it can take me to get out of fantasy land sometimes. In extension to letting my fantasy loose, it also serves as inspiration for my own stories and plot lines (yes, I seek inspiration). It lets me create alternate worlds, and I love it. Morphing other authors’ universes to my ideal is an exercise I do a lot while reading; to me, it is fun.
There is also the aspect of learning something. For example, I do not limit my reading to fiction. I read books about music (how it works), languages and how they evolve, history, philosophy, and more. Books let me dive deeper into a topic than an online article (unless it provides references) and lets me focus on that topic alone. I love learning, and books are one of my sources for this.
Finally, for those who do not know, I am a little bit challenged in spelling and writing, yet I still love to learn languages. Through reading, I get better at spelling and, thereby, writing. Not just simple words, reading helps me discover new words and helps me learn how to spell them, thereby enriching my vocabulary. Additional, this also extends my verbal communication, which is a fantastic bonus. This is not just limited to my native language (Danish) and English but also the new language I am learning or relearning. For instance, I am learning Farsi (Iranian Persian) and learning to read Farsi helps in learning new words (although I still butcher the pronunciation), and the same goes for Spanish and German, where the latter I am relearning. Reading has become a wonderful tool for learning a new language and expand my communication abilities.
Before I close up a little note, most of the benefits and experiences I have mentioned, I also experience with audiobooks. Some audiobooks limit my fantasy when they add sound effects (looking at you, Star Wars audiobooks). But I will say that they are a great tool too.
Now to close. These are the reasons I read a lot and why I am getting more and more reading done. I hope I have inspired you to read more or start reading.
./Lars
[Book Review] How to Write Everything
As some may know I am working on a fantasy novel and during this process I am also working on becoming an overall better writer. Therefore I constantly on the look out for resources which can make me a better writer. One such resource came on to my radar via the Writing Community over on twitter (The hash tag is #WritingCommunity, I don’t believe there been created a community yet), this was the book How to Write Everything by Mr. David Quantick.
I have the book both as an Ebook (I did read it) and on Amazon Audible, where the latter is narrated by Mr. Qyantick. The book is described as the ultimate handbook for every aspect of writing, both in reviews I have read and by people on twitter. Here I will give my review of the book, it will not be in the same style as the Nocturnal Blood review, but I still wanted to give it a go.
The review
Mr. Quantick is a well versed writer who have written basically any style, plays, for television, movies, books, and so on.
He presents an impressive CV through out the book that makes you feel like it words coming straight from the horses mouth.
The content of the book is present as a correlation of interviews of other writers, personal anecdotes and experiences, and advice for the reader.
This also means that the picture paint in the book is not unicorns and rainbows, writing is clearly not presented as straight road without bumps, twist, and turns.
By utilising this approach Mr. Quantick presents the reader with what feels like a more realistic perspective (compared to other writers advise resources I have read or watch before).
Which is good as it makes you take the advice more serious and I can already tell you that I am using some of these on a daily basis.
Thus, the book basically already have qualified itself as pretty good.
However, it does not stop there. Mr. Quantick takes us on a journey through multiple disciplines of writing as already state. Where for each he compare it to other at least one other discipline and explains how it differs and what people you interact with. For instance both for plays and movie scripts he explains the potential head butting with directors and actors. Yet he also explain how input from none writers should be taken seriously and also your ideas will probably change. This is an important notion that I feel a lot of new writers (and probably also more experienced once) are not ready for and can have a hard time coping with.
Another thing that I find important is how he explains the process of submitting a manuscript (novel, news article, etc.). How it can be rejected, accept, and (potentially) stolen and there is present an abstract description of how to act in each scenario. Furthermore, Mr. Quantick also emphasis how we as writers are not unique when it comes to ideas in particular a focus on inspiration and how two or more people can have the same idea or get inspiration in a similar way resulting in a very similar piece of work.
I do not feel like I can fully justify the amazing advice, warnings, and realisations which Mr. Quantick presents in this book without it just sounding like one long praise fest. Literally the only critique I have with the book is that the interviews presented in the book can be confusing in the audio book version, but that is not the case in the printed version. All in all I feel like all aspiring writers should read this book to be douched in a healthy spray of realism and advice.
Finally, I would like to dive deeper into the two advice I follow daily at the moment. Write every day and Always have something to write on and with. I have found that when I take breaks from writing, even if it is just jutting down notes about my stories I kind of slack off and procrastinate, essentially not training my writing. Which I have found that like other things, it needs practice and in my experience even more than other areas I work in. Therefore, I have started to write everyday, it may not be on my main work in progress, it may just be ideas, but I get something done. As for always having something to write on I have started to always have my phone one me with the note app on the first spring board and I try to carry a pen and paper when I go for walks. This lets me quickly jot down ideas I get on the run and it makes me practices writing every day.
Although, I have not covered the content of the book in depth here, I hope you understand why I fully recommend this book.
./Lars
Why do we strive for short type names in programming languages?
Like most developers I am not coding just a single programming language and I do keep up to date on new programming languages.
Lately however, I have seen a trend I do not really like in static typed programming languages that I do not like and it is in particular present in Rust and Zig.
So what is this trend? Well really short unreadable type names!
Below I first have a C++ example of a simple sum function (ignore the overflow issue) and then the same function implemented in rust.
For C++ we have the type uint64_t
and for Rust u64
.
Now let us assume I am newcomer from Java, C#, or C, in C++ I know its and int
I would also argue that I could guess its 64 bit.
Additionally, if you play around with enough programming languages u
is often used as a short hand for unsigned
so you might be able to guess what that part.
The _t
has always bugged me, but I can deal with.
However, with rust all you have to go by is u64
so you know it is 64 bit and like with C++ you could problem resonance yourself to the conclusion that it is an unsigned variable.
But unsigned what? float, integer, something third? You literally cannot tell.
With time of course you will remember it, but if you (like me) have to switch between multiple language during a single day, it is sometimes difficult to instantly remember what the different types hiding behind u<INSERT NUMBER>
, i<INSERT NUMBER>
, and so on. I am at a stage now where I can but it took a long time, but it was one of the reason I originally gave up on learning Rust, because I found it to convoluted and like it was intentionally gate keeping with is type names.
uint64_t sum(uint64_t start)
{
uint64_t res = 0;
for (uint64_t i = start; i > 0; --i)
{
res = res + 1;
}
return res;
}
fn sum(start: u64) -> u64 {
let mut res: u64 = 0;
for i in (0..start).rev() {
res = res + i;
}
return res;
}
I do not understand this design decision was made in Rust and I honestly think that it scares some people away. Why have this been chosen? Please stop.
./Lars