Tagdotnet core

A może by tak Linuks…

A może by tak Linuks… Od kiedy tylko pamiętam, używam systemu Windows. Był zainstalowany na moim pierwszym komputerze, który dostałem od rodziców („do nauki mamo” ;-)), jak również na każdej maszynie od kiedy tylko rozpocząłem swoją karierę jako programista. Oczywiście, były eksperymenty z Linuksem (Mandriva/Mandrake, jakiś Debian, czy potem Ubuntu), ale nigdy na dłużej. Ostatnio, mając na uwadze multiplatformowość .NET Core i to jak mi się dobrze pracuje z tą biblioteką, postanowiłem dać Linuksowi szansę. Nie zastanawiałem się długo, wszak mógłbym stracić zapał ;-).   I to już?! Internety mówiły, że na początek dobry jest Mint, i takią dystrybucję zainstalowałem, pozbywając się tym samym Windowsa. Zainstalowanie systemu było bajecznie proste, zwłaszcza, że nie kombinowałem z partycjami. Potem przyszła kolej na Visual Studio Code i .NET Core. Tutaj również nie odnotowałem problemów. Jeszcze jakaś nakładka na bash (tradycyjny terminal mi nie pasi), manager...

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

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