When you work in a team, you all have to decide, how you are going to format your code in the project. Everyone has their own favourite editor, IDE and own preferences regarding tabs, sometimes even charsets. Very often it’s hard to convince everyone to change settings in their editors. That’s when EditorConfig comes in handy.

Czy zdarzyło Ci się pracować długo nad jakimś plikiem i wszystko stracić przez brak zapisania zmian? Czy to aplikacja się zawiesiła, czy może komputer. Dzięki mojej niewielkiej aplikacji autosaver ten problem zniknie.

W poprzednim poście przeszedłem jakie są nowe komendy które pozwalają na interakcję z edytorem poprzez skróty klawiaturowe, dzisiaj przejdę po najciekawszych funkcjonalnościach które pojawiły się między wersjami (1.9-1.19)

Wersją roboczą nazywam pliki na którymi pracujemy, to te gotowe do zmiany. Zmiana gałęzi, zmiana HEAD naszego repozytorium powoduje również zmianę wersji roboczej. Zazwyczaj ta zmiana jest bardzo szybka, ponieważ git jest bardzo szybki, ale… im większe repozytorium i większe zmiany między wersjami, to czas potrzebny na przełączanie rośnie. Czasochłoność przełączania powiększy także IDE, bo zmiana plików projektowych pociągnie za sobą ekran konieczności przeład...

Wdrożenie procesu ciągłej integracji dla aplikacji .NET Core z wykorzystaniem narzędzia GitLab CI dla lokalnego Runnera.

Po pewnym okresie przerwy wracam do pisania o Visual Studio Code! Dzisiaj przejdę przez nowe komendy które pojawiły się marca 2017 roku do dnia dzisiejszego. Nie są to wszystkie komendy, wybrałem te najważniejsze a nadal jest ich trochę.

I’ve recently watched a pretty decent tutorial about DSC on Microsoft Virtual Academy. I’m not a huge fan of video tutorials because it always takes more time to watch them than read a book/blog post (you can hack it by increasing video speed and save yourself a couple of minutes) but sometimes there is additional beneficial side effect - the presenter can show you (accidentally or not) some tips and tricks not strictly related to the core subject of the video. This post is an attempt of summarizing tric...

Podczas pracy z systemem kontroli wersji czasem zdarza się, że nasz pull request ma konflikty. Konflikty powstają gdy ten sam plik został zmieniony w różny sposób w tym samym miejscu w obu scalanych ze sobą branchach. Wpis ten pokazuje jak ja radzę sobie z konfliktami w systemie Git. TL;DR: Na końcu wpisu znajduje się skrócona instrukcja.

In order to keep your git environment in a good shape you need to clean up branches from time to time. It is especially difficult in case of build servers which complete pull requests on behalf of developers (like VSTS). It’s easy when you have just a few branches to review, but if you forget to do some cleaning for longer while then it’s getting painful. For sure you do not want to remove effects of your work by accident during cleanup.

It’s a good practice to make all things done at the first approach. But in the real world it’s ot always possible - for example we need to ask customer for clarification and it will take some time, or worst - we don’t have enough time right now to implement things in the right way. In order to adress this issue, a TODO was invented to mark all those places in code requiring additional work. But the main disadvantage of TODO is that we mark code with it, commit it and forget about it. Sometimes somebody a...