Categoryfelietony

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

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

Autor serwisu

Patryk

Społecznościowe

Instagram

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

Newsletter



Historycznie

Tagi