Blog posts

Środowisko pracy oraz konfiguracja projektu

Środowisko pracy oraz konfiguracja projektu

Daj Się Poznać 2017, dotnetcore, os x

Ruszamy z projektem Stegooreore! Pierwszy commit poszedł już na github.com, a więc czas na już bardziej techniczny post. Chciałbym przedstawić wam moje środowisko pracy oraz sposób w jaki został skonfigurowany projekt.

Środowisko pracy

Na codzień w pracy korzystam, jak większość developerów .Net, z systemu Windows i Visual Studio. W tym projekcie chciałbym jednak nauczyć się jak najwięcej nowych rzeczy, więc wybór padł na MacBook Air. Laptop, jak to zazwyczaj sprzęt Apple, nie należy do najmocniejszych, ale na potrzeby tego projektu spokojnie wystarczy. Zreszta porównując do laptopa z Windowsem, który ma dwa razy więcej RAMu oraz procesor nowszej generacji, płynność pracy leży zdecydowanie po stronie Mac’a.

Przy wyborze IDE wybór był dla mnie oczywisty: Visual Studio Code. Jest to lekki edytor od Microsoft’u, który bardzo dobrze sprawdza się w pracy z frameworkiem .NET Core. Ma on możliwość bardzo łatwego dodawania pomocnych rozszerzeń z Marketplace, np. debugger.

Wymogiem projektu jest aby kod znajdował się na githubie, więc system kontroli wersji mógł być tylko jeden – Git. Okazało się że można z niego korzystać również wewnątrz VS Code. Myślę jednak, że głownie będę korzystał z linii komend. Sprawia to wrażanie lepszej kontroli nad repozytorium. Okazało się jednak, że już na samym początku VS Code jest pomocny. Przy inicjalizowaniu lokalnego repozytorium, automatycznie wygenerował odpowiedni plik .gitignore.

.Net Core oczywiście nie jest od razu dostępny na Mac’u. Trzeba go zainstalować samodzielnie. Ja korzystałem z oficjalnego poradnika od Microsoft’u. Nie będę tutaj opisywał jak to zrobić, bo musiałbym po prostu przekopiować wszystkie kroki.

Będę używał wersji .Net Core:  1.0.3 with SDK RC4 build 004771, czyli najnowszego buildu wersji LTS. Aby ją zainstalować należy również posiadać odpowiednią wersję OpenSSL’a (minimum 1.0.2). Jeśli ktoś miałby kłopot z instalacją to proszę pisać – chętnie pomogę 🙂 oczywiście podczas aktualizacji OpenSSL’a sam miałem problemy i rozwiązaniem okazało się ściągnięcie kodu źródłowego, manualny build, instalacja i linkowanie. Pomocny jak zwykle był stackoverflow: http://stackoverflow.com/a/38710248

 

Konfiguracja projektu

Jak już wspomniałem, na githubie wylądował już pierwszy commit. Jest to tylko sam szkielet składający się z oddzielnych projektów biblioteki oraz aplikacji webowej. Zdecydowałem się na następujący podział:

src
|-- global.json
|
|-- StegoCoreWeb
|   |-- Sources
|   |-- StegoCoreWeb.csproj
|
|-- StegoCoreLib
    |-- Sources
    |-- StegoCoreLib.csproj
test

W katalogu src znajdują się dwa projekty: StegoCoreLib – biblioteka, oraz StegoCoreWeb czyli aplikacja webowa. W katalogu test będę umieszczał testy biblioteki. Plik global.json zawiera właśnie strukturę całej solucji, czyli:

{
    "projects": [
        "src/StegoCoreLib",
        "src/StegoCoreWeb",
        "tests"
    ]
}

Natomiast same pliki *.csproj to pliki konfiguracyjnego projektów. Zawierają one między innymi zależności do bibliotek .NET Core, komendy, które mają zostać uruchomione podczas buildowania projektu itp. Projekty wygenerowałem automatycznie przy pomocy narzędzia Yoeman. Korzystanie z tego narzędzia jest bardzo wygodne, a praktyczne jego wykorzystanie jak i ustawienie zależności pomiędzy projektami opiszę w kolejnym poście.

 

Uruchomienie projektu

Pomimo tego, że projekt jest samym szkieletem można już go uruchomić. Należy na początek przywrócić zależności projektów komendą:

dotnet restore

Trzeba ją wykonać w każdym z projektu osobno, czyli znajdując się w src/StegoCoreLib i src/StegoCoreWeb. Po odbudowaniu zależności można uruchomić aplikację webową (trzeba więc znajdować się w src/StegoCoreWeb):

dotnet run

Spowoduje to wykonanie buildu obu projektów oraz wystartowanie aplikacji webowej. Jeśli wszystko pójdzie po naszej myśli, powinniśmy móc ją zobaczyć pod adresem: http://localhost:5000.

Postaram się, aby do następnego postu projektowego pojawiło się już trochę „mięsa” do tego szkieletu 🙂 Zacznę od aplikacji webowej i wczytywaniu plików graficznych wraz z ich wyświetlaniem. Co do biblioteki cały czas waham się nad algorytmami, które zaimplementuje. Na pewno zdecyduję się na ukrywanie danych w ostatnich bitach RGB pliku. Ale o tym w kolejnych postach.

About the author

Senior specialist, developer. Pasjonat programowania rozwijający się przy projektach komercyjnych oraz jako kontrybutor open source. W wolnym czasie lubi pobiegać za piłką, a także obejrzeć dobry film lub serial.

2 Comments

  1. Bartek
    12 września 2017 at 19:26
    Reply

    „Przy wyborze IDE wybór był dla mnie oczywisty: Visual Studio Core” – tutaj chyba chodzilo o Visual Studio Code 🙂
    Ja używam w pracy zarówno Visual Studio jak i VS Code. I pomimo, że Code jest znacznie lżejsze, to czasem wydaje sie mniej przejrzyste, szczególnie Solution Explorer (może to kwestia większych czcionek albo przyzwyczajenie). Plus dla VS Code, to możliwość konfiguracji wielu rzeczy oraz możliwość pisania rozszerzeń. Do większych projektów VS, a do mniejszych Code

    • Paweł Skaruz
      25 września 2017 at 19:58

      Bartek, dzięki za komentarz!
      Literówkę w tekście już poprawiłem 🙂
      Co do IDE to myślę, że robię podobnie. W pracy przy większych projektach używam Visual Studio. W domu do moich własnych projektów lub po prostu edycji pojedynczych plików VS Code.
      Ostatnio poznaję również Visual Studio for Mac i muszę przyznać, że również się miło pracuje.

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *