Browsing Category

os x

Daj Się Poznać 2017 dotnetcore jetbrains os x

Alternatywa dla Visual Studio? Rider od JetBrains

Kiedy programujemy w C#, w większości przypadków jesteśmy skazani na Visual Studio. Czy słyszał ktoś kiedy o alternatywie? Jakiś czas temu, całkiem przypadkiem, natrafiłem na Rider – nowe IDE dla .NET od JetBrains. Jest on wciąż w trakcie powstawania, jednak stwierdziłem, że warto sprawdzić czy jest na co czekać. Testowany przeze mnie build to:  EAP build 20. Narzędzie jest multiplatformowe, więc testowałem na Windowsie i macOS.

Firmę JetBrains programiści .NET mogą kojarzyć z rozszerzenia do Visual Studio – Resharper. Jedni uważają, że jest świetne, bo pomaga programiście pisać szybciej kod i utrzymać w nim porządek. Inni nie przepadają za nim, w sumie nie wiem dlaczego. Być może dlatego, że szczególnie młodzi programiści mogą ślepo ufać Resharperowi i korzystać ze wszystkich jego podpowiedzi. Może to spowodować, że taki kod będzie mniej czytelny. Moim zdaniem Resharper jest świetnym narzędziem, ale trzeba wiedzieć kiedy i jak z niego korzystać.

Programiści Java mogą kojarzyć JetBrains z IntelliJ – IDE do Javy właśnie. Nigdy z niego nie korzystałem, ale słyszę że wśród kolegów z pracy zbiera dobre recenzje.

Dochodzimy tutaj do Rider’a, który jest połączeniem IntelliJ i Resharpera. Jak on się prezentuje? Sprawdźmy! 🙂

Instalacja

Ze strony JetBrains należy pobrać odpowiednią dla naszego systemu paczkę. Paczka ma około 300mb. Czas instalacji to kilka minut. Każdy kto instalował Visual Studio, wie że ten proces może potrwać kilkadziesiąt minut, więc tutaj duży plus dla Rider’a.

Po instalacji kreator przeprowadzi nas przez wstępną konfigurację, wybór kolorystyki, klawiszologii. Możemy również zainstalować opcjonalne rozszerzenia. Po tym możemy przystąpić do pracy. Do wyboru mamy otwarcie gotowego projektu lub stworzenie nowego.

Nowy projekt

Do wyboru mamy kilka szablonów dla .NET, Xamarin i .NET Core:

Do testów zdecydowałem się na MVC ASP.NEt Core Web App. Otrzymujemy gotowy szablon do pracy. Edytor prezentuje się następująco:

Edytor Rider

Zarówno na macOS i Windows buildowanie oraz uruchomienie aplikacji przebiegło bez żadnych problemów. Pozytywnie zaskoczyło mnie buildowanie na Windows dużej solucji z aplikacją w .NET. Wszystko działa jak należy. Jedyny problem jaki napotkałem to brak możliwości debugowania aplikacji w .NET Core. Nie jest to winą Rider’a, a postanowień licencyjnych. Wykorzystanie pakietu umożliwiającego debugowanie aplikacji .NET Core możliwe jest tylko w Visual Studio, Visual Studio Code i Xamarin Studio.

Pomyślałem, że jednak najlepiej będzie jak przetestuję Rider’a w praktyce. Uruchomiłem więc projekt StegoCore i przystąpiłem do pracy. Poniżej moje uwagi podzielone na plusy i minusy.

Plusy

  • Wspiera większość projektów .NET, .NET Core i opartych na Mono
  • Multiplatformowy – działa na Windows, macOS i Linux
  • Działa bardzo płynnie, nie zauważyłem żadnych przycięć itp; zdarzają się czasami jakieś błędy, ale nie powodują wyłączania aplikacji
  • Wbudowany Resharper – refaktoryzacja kodu, analiza kodu
  • W pełni sprawny menadżer pakietów NuGet

    Rider NuGet

  • Unit test runner – pozwala uruchamiać i debugować testy NUnit i xUnit.net

    Rider Unit Test Runner

  • Wbudowane wsparcie dla systemów kontroli wersji: Git, Subversion, Mercurial, Perforce i TFS
  • Możliwość połączenia się do bazy danych (testowałem na MS SQL)
  • Dekompilator

    Rider decompilator

    Przy użyciu Go to Declaration na dowolnym elemencie biblioteki zostaniemy przeniesieni do jej kodu źródłowego. W sytuacji gdy jest on niedostępny dekompilator Rider’a przygotowuje dla nas kod C# biblioteki.

  • Rozszerzalność przez pluginy

Minusy

  • Pojawiające się błędy; przy czym trzeba mieć na uwadze że jest to wciąć wersja early build
  • Podczas otwarcia istniejącego projektu ASP.NET MVC nie zostały wczytane pliki widoków *.cshtml
  • Brak Package Manager Console
  • Brak możliwoście debugowania aplikacji w .NET Core

Podsumowanie

Pierwszy kontakt z Rider wyszedł pozytywnie. Praca w tym IDE jest przyjemna i szybka, a o to przecież chodzi. Projekt rozwija się bardzo dobrze i trzeba się cieszyć, że w końcu rośnie konkurencja dla Visual Studio. Być może zmotywuje to Microsoft do lepszej pracy nad swoim produktem. Mocno na to liczę, bo myślę że wielu z programistów wolałoby mieć jakąś alternatywę przy wyborze IDE.

Zachęcam również Was do spojrzenia na Rider’a. Aktualna wersja umożliwia darmowe przetestowanie i zapoznanie się z IDE.

Daj Się Poznać 2017 os x security u2f

Klucz U2F jako metoda logowania do OS X

Jakiś czas temu zakupiłem klucz FIDO U2F firmy Yubico. Służy on do weryfikacji naszej tożsamości podczas dwuskładnikowego logowania na wielu portalach: github, google, facebook itp. Metoda ta jest o wiele szybsza od wysyłania smsa lub maila. Musimy tylko umieścić klucz w porcie USB, a następnie dotknąć podświetloną ikonę klucza. O tym dlaczego zaleca się używanie tego klucza można poczytać między innymi na niebezpieczniku.

Osobiście również zachęcam do tej metody logowania dwuskładnikowego. Klucz jest na tyle mały, że możemy go mieć cały czas przy sobie. Zabezpiecza nas przed wyciekiem haseł czy phishingiem, więc na pewno warto rozważyć zakup. Sam zaopatrzyłem się w niego na amazon.de.

Okazuje się, że w dosyć łatwy sposób możemy wykorzystać klucz jako metodę logowania do Maca. Poniżej kroki jakie należy wykonać. Dodaje, że wykonujesz je na własne ryzyko.

Co potrzebujemy?

  1. Oczywiście Klucz Fido U2F
  2. Homebrew – do instalacji modułu U2F
  3. Wykonanie backupu, np. przy pomocy Time Machine. Niestety podczas konfiguracji możemy wykonać błąd i stracić dostęp do systemu. Innym sposobem jest utworzenie nowego konta użytkownika z prawami administratora.

Konfiguracja

Na początku należy zainstalować moduł U2F za pomocą homebrew:

Moduł powinien zostać zainstalowany w:

Dlatego warto wykonać link, aby za każdym razem nie trzeba było wskazywać całej ścieżki:

Następnym krokiem jest zapisanie danych uwierzytelniających klucza w katalogu  ~/.config/Yubico/u2f_keys . Jest to domyślne miejsce w którym moduł U2F będzie szukać naszych danych podczas logowania. Możemy to zrobić wykonując po koleji:

Po pomyślnym zapisaniu danych, możemy przystąpić do konfiguracji metody logowania. Należy w tym celu edytować plik  /etc/pam.d/authorization i dodać na początku  auth sufficient pam_u2f.so . Plik powinien wyglądać następująco.

Dzięki temu będziemy mogli zalogować się do systemu za pomocą hasła lub klucza. Warto przetestować to przed następnym krokiem. Podczas logowania należy wcisnąć Enter i dotknąć klucz. Powinniśmy zostać zalogowani do systemu. Jeśli coś będzie nie tak, trzeba sprawdzić czy nie popełniliśmy żadnego błędu (np. czy dane z klucza zostały poprawnie zapisane).

Ostatnim krokiem jest użycie klucza jako typowego U2F zmieniając  auth sufficient pam_u2f.so na  auth required pam_u2f.so . Aby się zalogować należy wtedy podać hasło oraz klucz.

Klucz U2F to doskonała metoda do dodatkowego zabezpieczenia dostępu do naszego laptopa. Nie powinniśmy już się obawiać utracenia danych po jego kradzieży. Oczywiście pod warunkiem, że naszego dane są zaszyfrowane np. za pomocą FileVault.

 

Daj Się Poznać 2017 dotnetcore os x

Środowisko pracy oraz konfiguracja projektu

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ł:

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:

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ą:

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):

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.