On refactoring

Of spaghetti code in one project/big methods to some projects/smaller methods

- no props for services using factories, use constructor injection to see what's necessary; but if service is resolvable eveywhere, props are better to not make constructor parameters list fat
- constructor parameters class is good when you often change dependencies list, but separate parameters are better for easier control and dependencies minimizing
- fewer state (props) and more parameters passing to see workflow!
- generally properties injection is better and all injected stuff should be stateless services OR dependencies constructor params should be taken from context

Again and again

Fresh updated VS 2017 Community offered me to enter email/username when I went to work with Team Explorer having Git-based solution opened. Well, why not - though I did not suffer from  any info missing in commits. But then I discovered that all configuration in root .gitconfig in Windows Profile folder was replaced with just that email/username. "Git diff" attempts run VIM instances that eat my CPU completely without anything UI visible. Skype also joined CPU consumers company. Well, let's again spend some time for reconfiguring. Thanks, M$

It took time, or VS 2017 and .NET Core 2.2

https://stackoverflow.com/questions/54088559/visual-studio-does-not-display-net-core-2-2-in-target-framework-dropdown# explains why latest at that momant .NET Core SDK 2.2.202 installed is invisible for .NET Core 2.2 project. Where is it said that I need VS 2019 to work with latest .NET Core 2.2 except some StackOverflow article googled quite occasionally? Googled earlier articles tells that 2.2 SDK is OK if <some other actions that nevermind>. Some *.target file pointed in "the current .net sdk does not support targeting .net core 2.2" error message is from "C:\Program Files\dotnet\sdk\2.1.505" folder. And the solution is to use 2.2.106 version, last before 2.2.202. Now we know what is "breaking change" with minor version number changed by 1.

Bloody hell

Какой-то адский десант металеров на Бульбению выдался этой весной. Может, я стал больше рекламу смотреть в метро и на остановках... Решили косануть бабла с 2.5го мира, ибо в 1м как-то уже не катит? Снова Тарья, Amorphis, Larimosa, постаревшие эксгибиционисты Manowar, Dimmu Borgir. Даже Ленинград, который в Рашке наше всё, уже вроде как пару раз приезжал и, возможно, будет ещё.

Visual Studio resources editing support

When you copy-paste .resx resources between projects, mind VS features. Rename copied .resx file to let VS properly fill internals.

VS generates namespace according to folders structure. For case above, it will be TOMEs.Database.Migrations.Migrations._20190128144800.Resources

Don't worry that resource satellite assembly will go to, e.g. TOMEs.Database.Migrations\bin\Debug\cs-CZ\TOMEs.Database.Migrations.resources.dll

Use matching full type name as single constructor parameter for System.Resources.ResourceManager and it will work. Don't try to fool VS by manually editing Designer.cs and substituting some "logically matching" namespaces similar to project from you copied resources.

Guys upper in development hierarchy may don't hear you. Especially if you say nothing.

After some project kinda failed, I decided to save some impressions that I consider important about problems I consider evident:
- Fuck unit tests. It's bullshit on most applied projects, especially if same "high quality coding standards" are applied to tests as for app code. If you deal with science,calculations or at least accounting - create tests, use TDD or whatever. It's obvious for amounts of data or operations unsuitable for manual testing. Otherwise, spending time on manual functional testing is much more useful. And of course, autotests and integration tests are much more useful at least for smoke testing when you don't need 1.5x+ amount of code to cover by smoke and 20x for kinda functional unit testing that looks like documenting. If someone has documented reason for change, he'll just change broken tests too.
- Fuck perfectionism. Remember that while you are trying to make code beautiful, others compete with you having working production nevertheless it's pile of sticks and shit. Actually, inspite of all time-consuming efforts in some time you'll understand that your codebase is same pile of sticks and shit. Is it really possible that customer will order codebase audit? You will never got to this phase if major UI bugs are not fixed for months - customer sees UI 1st.
- Heavily enforce standard approaches, knowledge sharing, commenting and responsibility areas. The less are exceptions from rules the easier are they to follow. Collective code ownership is another bullshit. People are rarely hit by buses, and vacations are short.
- Test on approximately real data. Test early. If there is paging on UI, test it immediately and don't wait when someone manually submit enough data for 2nd+ page to appear. You should not refactor or reimplement after separate perfomance testing on project mature stage. Do things right way initially.
- Remember about probabilities. Many arguments for "better" design starts with "if". Refactor if this "if" happens. Mind schedule and don't do things in advance.