Categorytechnicznie

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>” ...

Autor serwisu

Patryk

Społecznościowe

Instagram

Instagram has returned empty data. Please authorize your Instagram account in the plugin settings .

Newsletter



Historycznie

Tagi