Categorytechnicznie

Praca z Gitem. Nie tylko okienka, nie tylko konsola.

Słowem wstępu Praca z Gitem. Dużo się o nim mówi, zwłaszcza w środowisku .NET, głównie ze względu na to iż Microsoft kupił Github, a także udostępnił źródła .NET Standard i .NET Core na licencji Open Source (MIT). Osobiście, ciągle się uczę Gita i przy okazji sprawdzam, testuję różne rozwiązania około-gitowe. Wtyczki, narzędzia, różnego rodzaju integracje z Gitem. To sprawia, że wiem co mogę i ile mogę. Gita świetnie się obsługuje z poziomu konsoli czy terminala i przy tym pozostanę, ale zawsze dobrze mieć coś w zanadrzu.   Zamysł Ludzie są różni i różne potrzeby mają. Ha! Taki komunał na początek. Dlatego nie każdy będzie używać konsoli do pracy z Gitem. Osobiście uważam że jest to najlepsza droga ku temu, ale hej…każdy lubi „po swojemu”. Do tematu podszedłem od strony czysto użytkowej. Git jest wspaniały ale, jak ze wszystkim, nie dla każdego. Owszem, da się, ale czy to oznacza, że od razu trzeba? Dlatego filozofie nt. tego czy trzeba czy nie, zostawiam na...

Git aliasy

Git znudzenie Ostatnio bardzo mocno „katuję” swój mózg Gitem….hmmmm…uprzyjemniam mu chwile Gitem. Z racji tego, że w pracy nie mam możliwości poużywać sobie Gita w miarę często, eksperymentuję w domu na swoich pet-projects. Używam, używam, używam i nudzi mi się już ciągłe wpisywanie komend w konsoli. Rzecz jasna nie zamienię jej na inne narzędzie do pracy z Gitem, ale kiedy już pamiętasz te bardziej popularne komendy, odechciewa się. Pisałem już o dodatkach do PowerShella, również w kontekście Gita. O tutaj – Aby PowerShell był bardziej power. Jeśli chodzi o żmudne wpisywanie komend, z pomocą przychodzi sam Git, a jakże… Zwyczajnie, daje możliwość skrócenia czasu spędzanego na wpisywaniu komend poprzez aliasy komend Gita. Dokumentacja TUTAJ. Tak, tak właśnie! Zatem do dzieła…   Remedium – Git aliasy Zanim zaczniemy wypisywać w konsoli jakieś magiczne zaklęcia, pokażę Ci jak dodać aliasy bez użycia konsoli. Mianowicie, najłatwiejszym...

Windows i ścieżki, którymi podąża

Słowem wstępu Dawno, dawno temu została stworzona stała MAX_PATH, decydująca o tym jak długie mogą być ścieżki do plików i katalogów w systemie Windows. Jest to setting na poziomie Windows API. Ostatnio w pracy dotknął mnie ten problem. Niefortunne było to, że problem objawił się podczas modyfikowania pliku projektu jenkinsa, w celu utworzenia joba releasowego. Problem był o tyle uciążliwy, że przecież nie zmienię nagle całej struktury projektu i źródeł które zamierzam budować, ani tez nie będę przenosił całego jenkinsowego workspacea. Zatem opcje były trzy: Instalacja odpowiedniej poprawki do systemu Windows. Zmiana ustawienia w systemie, tak aby mnie nie blokowało. Sprawienie że Windows będzie „widział” ścieżki jako prawidłowe, lub po prostu będzie je akceptować.   Łaty i bilety Opcja nr. 1. Najłatwiejsza ze wszystkich proponowanych. Niestety nie zawsze działa. Link do patcha – PATCH Jest to patch do systemu Windows Server 2012 R2 i zawiera m.in. poprawki do...

Aby PowerShell był bardziej power – dodatki i moduły do PowerShell

Potrzeba i chęć używania git’a sprawiła, że siłą rzeczy używam również PowerShella i to właśnie o nim będzie dzisiejszy wpis. Okazuje się, dla osoby niezbyt obytej z tym narzędziem, że jest ono bardzo przydatne, zwłaszcza dla programisty. Dzisiaj nie chcę pisać o konkretnych funkcjach czy komendach. Napiszę o kilku dodatkach jakich używam i jak wspomagają/usprawniają one pracę. Mam również w planach post traktujący o PowerShellowych tips & tricks dla programistów, ale to kiedy indziej.   Łatwiej w Gita Skoro o Gicie była mowa, zacznę od Gita właśnie. Świetnym dodatkiem do PowerShella, modułem dokładnie, jest Posh-Git. Moduł ten po pierwsze pokazuje status naszego rpozytorium jako prompt, co jest całkiem spoko. Dodatkowo, mamy możliwość auto-dopełniania (eh…ten nasz język) komend Gita za pomocą klawisza Tab. Piszesz: git ch wciskasz klawisz Tab i dostajesz: git checkout W zamian za: git pull or<Tab> ma<Tab> dostaniesz: git pull origin master   Tak...

Continuous integration#02: Atrybuty smoczego pogromcy

Drugi post nt. Continuous Integration. Zapraszam do lektury. „Warsztat smokogromcy” „Atrybuty smoczego pogromcy” Ten, kto tańczy ze smokami, musi się liczyć z tym, że spłonie.  George R.R. Martin – Rycerz Siedmiu Królestw       Przeciwnik Czy na pewno? Czy nie ma sposobu na walkę ze smokiem? Tym razem będzie lekko. Opiszę pokrótce projekty-smoki które będą bazą do testów. Są dwa: WebApi napisane w C#.NET Core z testami jednostkowymi WebApi napisane w pythonie, bez testów jednostkowych (dopiero się uczę pythona), które ze względu na swoją różną od .NETowej naturę, będzie dobrym porównaniem   Jedyne, co te dwa projekciki robią, to udostępniają API RESTowe, za pomocą którego można pobrać listę książek z lokalnej bazy danych MySQL. Nie chodzi o to aby projekt-smok był mega wielki i ociężały. Potrzebne mi były małe, lekkie źródełka do testów narzędzi, opisanych w poprzednim poście.     Większy smok…  Technology stack: .NET Core 2...

Continuous integration#01: Warsztat smokogromcy

Jest to pierwszy post nt. Continuous Integration. W miarę pisania, będą się pojawiać kolejne. „Warsztat smokogromcy” „Atrybuty smoczego pogromcy”   W tym szaleństwie jest metoda Continuous Integration – według definicji jest to praktyka programistyczna, wedle której członkowie zespołu często winni scalać wyniki swojej pracy (przynajmniej raz dziennie). Potem jakiś automatyczny system buduje/testuje, powstałe wcześniej zintegrowane wersje kodu. Uważam że, do pełni szczęścia potrzebne są jeszcze procesy Continuous Delivery i Continuous Deployment. Sama praktyka programistów, którzy w miarę często (raz dziennie to jednak zbyt rzadko) commitują swoje zmiany, nie wystarczy. Bardzo ważną rolę odgrywają właśnie tzw. build serwery (Source automation servers), które potrafią budować projekty, testować je i dodatkowo publikować je na określone maszyny/serwery/środowiska. Tym tematem zajmiemy się innym razem. Tymczasem…   Teoria broni W tym cyklu...

Dotnet niepokorny

Siedzisz sobie spokojnie w pracy. Piszesz nowy super-feature, w nowym super-projekcie. Palce biagają po klawiaturze jak małe Usain Bolt’y, wszystko idzie jak z płatka. Aż nagle wpada do pokoju timlider i mówi – „Fajny ten Twój super-projekt. Zrób mu joba jenkinsowego”. Mówisz sobie – „Nie trać rezonu”! Trzeba brać się do roboty!   Do dzieła! Tworzysz nowy projekt na panelu w jenkinsie, bierzesz się za napisanie pliku projektu jenkinsowego. To nic, że Twoja aplikacja jest napisana w dotNET core 2.0, przecież to już dojrzała technologia! Deklarujesz wszystkie potrzebne ścieżki, tworzysz target’y nazewniczo-kompilująco-clean’ujące. Przychodzi czas na gwóźdź programu: [code lang=”xml” wraplines=”true”] <Exec Command=”dotnet publish „$(SolutionFile)” -c $(Configuration) -o „$(dirCreated)””/> [/code] Wiadomo: dotnet publish „<ścieżka pliku solucji>” ...

Visual Studio i ReSharper w jednym stali domu…

Mam w pracy tę możliwość, że zazwyczaj mogę używać najnowszego Visual Studio, w połączeniu z ReSharper’em rzecz jasna. Często najnowszego .NET’a czy dotNET core’a (zaraz sobie język połamię). Cenię sobie tę możliwość, bo pozwala mi to być na bieżąco z głównym narzędziem/środowiskiem pracy całej rzeszy dotnetowców, siszarpowców i nie tylko. Jednakże rodzi to czasem problemy, no bo jakżeby inaczej. „Bunt maszyn” czy co? W każdym bądź razie ostatnio, dosyć często, Visual Studio nie radzi sobie z ReSharper’em. Może na odwrót? Nie ważne. Ważne, że Visual Studio czasami nie widzi możliwości dodania referencji do klasy, dll’ki którą właśnie chcę użyć. Czasami nawet po dodaniu tej referencji „ręcznie”, VS nadal uważa, że jej nie ma i podkreśla to użycie czerwoną linią wstydu. Na szczęście podczas builda wszystko jest w porządku, co nie zmienia faktu, że całe Visual Studio świeci czasami na czerwono. Jedynym rozwiązaniem, a raczej...

Newsletter



Społecznościowe

Historycznie

Tagi