Hyston blog
About • RSS


2020-05-13 10:20

I was working on adding logs into elastic search from one of our micro API projects. I learned a little bit, that I'll probably forget when I'll deal with this next time. So, I'll write it here.

  1. ELK - Elastic Stack. How it works:
  1. It's very useful to run ELK Stack local. Of course, installing everything will take too much time (I still remember painy days spent installing lamp). Of course, these days everything is in container and there is one good repository, that will help running everything in minutes. All you need to do is:
git clone https://github.com/deviantony/docker-elk.git cd .\docker-elk\ docker-compose up

And read ReadMe.md for further details.

  1. In my case, we have configured sentry and adding additional logging system, without removing old one. In this case better to remove "Logging" section in appsettings, otherwise it will affect both system. Most tutorials recommend start logging in Program.cs before actual werver will start, but I find it too cumbersome. If server didn't started, we will figure it out by not seing swagger page or by errors from other service, that consume this api.
  2. Also, most tutopials did not mention, that serilog can be configured not in code, but in appsettings. Probably, additional libraries needs to be installed, but then startup code itself is not polutted with config lines.
  3. When kibana resist to show logs, it means that, probably, indecies were not setted up correctly. And keep in mind, that it takes some time for log to appear, even if everything is running locally.
  4. Some usefull links:

This is probably too much info for such easy topic, but I might find it usefull some day later and - hey - I'm blogging again!😊


2020-01-11 11:06

I started to participate in Advent of code 2020. First couple tasks were easy, but after a while it keep getting harder and took more time, that I can manage on average december day. Today is 8 day and I done only 14 of them and want to share one bug, that I did found solving last one. I am pretty familiar with bitwise operators, espacially shift:

1 << 1; //result it 2 (bin: 10)
1 << 3; //result it 8 (bin: 1000)

However, in day 14 bitmask is 36 bit length. If you shift too much, it should be cut. Alright, I thought, lets use unsined 64-bit integers.
ulong a = 1 << 32;
Because currently I dont have a debugger1, and it worked flawlessly with smaller values, I havent noticed an error here. Documentation said

Because the shift operators are defined only for the int, uint, long, and ulong types, the result of an operation always contains at least 32 bits and I naturally assumed, that if I define left hand operand as 64bit, then result would be also 64. That was correct, but before it

  1. VS Code support for M1 macs is incomplete, as I'm afraid, until .net 6 😣


2020-01-09 09:01

sudo lsof /Volumes/2cent/ this shows disk activity. Today external disk drive refused to be ejected, Finder showed error that disk is still in use. lsof shows that many mds_store processes occupied it. kill and then turning off spotlight fixed this issue.

What I have learned about git today

2019-12-30 07:12

I knew about git hooks, but never actually used them. The first and obvious thing, that I could imagine — add branch name to git commit message. .git\hooks\ contain nice examples to start, but I was taken aback by amount of bash scripting, that is required. And, more importantly, it seems that it never works properly — neither Sourcetree or fork.git client were showing changes. However, after commit pre_commit_message hook was actually executed and branch name was inserted correctly. Examples like this should work flawlessly to my purpose. And I need to learn bash too 😶
Apparently, branching workflow, that we use at work, has a name. It's called gitflow (insert link), and it is used in many projects and even in our teams is proved as very convenient and easy solution. It is well described here and I can only describe one difference in how we use it: usually we do not merge release branch back to development (as well as hotfixes). All changes for current release accumulates in release branch, then we merge to master and only after deployment merge it back. 1 There is no harm to not merge release back into dev (as well as every hotfix), but it can be overlook and forgotten, but during deployment process it's just one step in list of instructions.

  1. The only exception — when release contain new migration, then it should be merged asap. Then I would be better to add migration to feature branch (even is feature is already merged to development and release) and, merge feature branch to development and release branch accordingly

asp.net core 3.1

2019-12-17 10:12

It's time for another blog update. I want to move some jobyjob projects to new .net LTS version, so it would be a good to practice update this fairy simply blog. Mostly everything went well by this post and official documentation.
But problem appeared with using libgit2sharp. By default, asp.net docker images using debian 10, with contain libgit2 version, that is incomparable with libgit2sharp nuget package, that I use to update posts. Solution was to switch base docker image tag to 3.1-bionic, with means to use ubuntu underneath.
Despite that solution is simple, it took some time to resolve it. Mostly because I need to sleep more to think quicker 🥱, but also any issue is a good reason to do refactoring and write tests. In my case, I added simple Result class instead of bool (or void) to define function execution result and log errors, if needed.
upd: I also revisited project structure, renamed some files, deleted others. I.e., I thought, that I dont need solution file - it looks like belong to "grownup" Visual Studio, while I use Code and mac anyway. But after all cleaning, OmniSharp stopped working - solution file was required. To put it back and add both projects:

dotnet new sln -n hysite dotnet sln hysite.sln add Hysite.Web/hysite.csproj Hysite.Tests/tests.csproj

← Next Previous →