Chcesz pojechać do Wrocławia

IMG_20150318_144507

Ostatnio pisałem o bardzo udanej pierwszej edycji konferencji Boiling Frogs. Więc będąc w temacie – 10 marca odbędzie się we Wrocławiu druga edycji konferencji Wroc#. W zeszłym roku chłopaki zaczęli od wysokiego C. Agenda była tak zacna, że bilety na pierwszą edycję konferencji rozeszły się dosłownie w kilka minut. Ten rok zapowiada się równie zacnie – mój #1 to Ian Cooper na którego czekam z niecierpliwością – a cała agenda nie jest jeszcze opublikowana więc co tam jeszcze mają w zanadrzu. A teraz najlepsze, w zeszłym roku mieli craftowe piwo uwarzone na ten event. ee…….. tzn. konferencja jest zupełnie darmowa. Gdzie jest haczyk? Ano bilety rozeszły się w kilka minut więc w tym roku rozejdą się pewnie szybciej. Dzisiaj masz ostatnią szansę zapisać się na ich newsletter i zawalczyć o wejściówki… bo chcesz tam być, chcesz jechać do Wrocławia :)

 

 

Gotujemy żabę czyli konferencja Boiling Frogs

Boiling Frogs - konferencja dla software craftman-ów

W sobotę miałem przyjemność pojechać na pierwszą edycję konferencji Boiling Frogs. Wpadłem na nią zupełnie przypadkowo bo jeśli dobrze pamiętam to gdzieś w twitterach się natknąłem. Przeczytałem agendę, która wyglądała bardziej niż zacnie. Konferencja prowadzona po polsku, nie daleko, z biletami w cenie 79PLN. Przy tej agendzie wyglądało, że warto się wybrać. Jedyna wada/zaleta konferencji to aż 3 ścieżki. Dlaczego wada/zaleta? Jak jest jedna ścieżka, to nie ma alternatywy, albo idziesz albo nie. Jak idziesz na wykład to może posłuchasz o czymś ciekawym na co sam byś się nie wybrał. Jak jest wiele ścieżek, to jest prawie zawsze znajdziesz jakiś ciekawy temat dla siebie ale możesz nie trafić na coś ciekawego na co sam byś się nie wybrał 😉 ot, życie.

I tak oto na pierwszy rzut poszedł Marcin Malinowski opowiadający o monadach, wyjaśniło mi się wiele rzeczy i magiczny nieznany świat okazał się trochę mniej magiczny i nieznany. Wykład bardzo mi przypadł do gustu ale będę musiał go oglądnąć jeszcze raz aby sobie poukładać wszystko w głowie.

Potem wybrałem się na BDD i wymagania w Agile do Wiktora Żołnowskiego. Przed wykładem słyszałem taki fajny dialog:

Geek1: BDD i Agile, eee…. znowu będzie gadanie żeby pisać user stories tak żeby product owner je zrozumiał a potem piszcie regexpy tak, żeby z tego się zrobiły testy
Geek2: Chodźmy stąd.

Mało z krzesła spadłem, Wiktor ani razu nie mówił o regexpach 😉 natomiast fajnie mówił o zdrowym podejściu. Myślę, że chłopaki stracili fajny wykład, trudno.

Po BDD czas na obiad, przystawka, zupka, pierogi a potem jeszcze gdzieś się pojawiło coś a’la bigos. No jak na konferencję to na prawdę świetne jedzenie, żadnych styropianowych pudeł i zaparzonego żarcia rodem z kateringu po drugiej stronie miasta. Na moje odczucia na pewno miał spory wpływ fakt, że kolega zajął strategiczne wręcz miejsce do konsumpcji 😉 (kudos Piotrek) jakoś we Wrocławiu na konferencjach zawsze dobrze karmią

Co dalej….

Michał Gruca i jego wykład Pozytywistyczny developer, czyli ciągła praca u podstaw. Dawno chciałem zobaczyć Michała na żywo. Wykład mięciutki, bardzo fajny i przyjemny. Niby nic nowego co nie znaczy, że nie warto posłuchać. Jedynie odniosłem wrażenie, że w połowie to był wykład po angielsku. Ja rozumiem, że taki zawód i takie środowisko i pewnie sam nadużywam wrzutek angielskich no ale…. za to był anime scrum (WAT!)

anime scrum

Effective Software Delivery i Jakub Kubryński  znowu miękko i w punkt. Znowu klasyczny przykład z code review: 2 klasy i 100 problemów, 200 klas – wygląda ok. Oczywiście niezwykle ważny i ciągle nawracający problem przedwczesnej optymalizacji…. (nie dalej jak tydzień temu znowu miałem dyskusję na ten temat).

Jakub Kubryński o przedwczesnej optymalizacji

Widać, że wszystko poparte doświadczeniem. Natomiast mam pewien problem, w wielu miejscach nie zgadzałem się z Jakubem więc nie powinienem być zadowolony z drugiej strony, jest to inny punkt widzenia i może spowoduje jakieś przemyślenia więc jestem zadowolony :) Jak się pojawi video to chyba jeszcze raz przeglądnę.

Na przedostatni wykład miałem się wybrać znowu na Wiktora i jego Teorię Kolejek ale ponieważ kiedyś słuchałem czegoś podobnego i rano byłem na jednym jego wykładzie to stwierdziłem że pójdę na HATEOAS as if you meant it. Miało być o REST, może dowiem się czegoś co uporządkuje ten REST-owy chaos. Niestety albo nie zrozumiałem wykładu albo Tomek nie uporządkował mi tej wiedzy. Tak czy inaczej zostaje z REST-em jako niedookreślonym tematem, gdzie każdy ma swoją teorię jak to robić i do każdej można się przyczepić. (WEB to zło)

Na koniec co zupełnie nie z mojej bajki, Machine Learning dla Developerów Mariusza Gil-a liczyłem na to że Mariusz pokaże jak zacząć przygodę z tym. Nie pokazał…. za to pokazał co ma wspólnego wiedza, dane i NSA

Boiling Frogs Mariusz Gil i Machine Learning
czyli łopatologicznie i krok po kroku o co w tym chodzi. Jakie dane można brać pod uwagę, jak można wyciągać wnioski. Olbrzymi nacisk kładł na to aby poznać swoje dane. Dla mnie jako osoby, która z ML nie miała żadnej styczności, świetny wykład. Co do narzędzi jak to Mariusz powiedział na końcu, nie zapamiętujcie tych narzędzi bo za pół roku będą inne. Myślę, że to bardzo ważna uwaga bo podstawy i koncepcja są ważniejsze. Po konkretne narzędzia sięgnie się jak będzie to potrzebne – bez zrozumienia podstaw nawet najlepsze narzędzie nie da rady.

Jak dla mnie pierwsza edycja bardzo udana i myślę, że warto zobaczyć jak będzie wyglądała agenda w przyszłym roku.

Project Rider czyli IDE dla C# od JetBrains-a

popcorn-blank

Dzisiejszy świat C# obiegła świetna wiadomość, Project Rider to nowe IDE, środowisko programistyczne dla C# od JetBrains-a.

W skrócie połączenie InteliJ i ReSharper-a – corss – platformowe 😀

Ludzie z NDC London byli tak uprzejmi, że dzisiejszą poranną sesję Haddiego, który miał przyjemność i zaszczyt (zapewne) ogłosić tą świetność wiadomość.

A sama sesja do znalezienia tutaj.

Project Rider from NDC Conferences on Vimeo.

Źródło: http://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide/

Bug w Visual Studio – serio?

Ostatnio sporo szumu wywołała informacja o bug-u Visual Studio, który kosztował pewnego człowieka prawie 6.5k$ (https://www.humankode.com/security/how-a-bug-in-visual-studio-2015-exposed-my-source-code-on-github-and-cost-me-6500-in-a-few-hours).  Tak czytając to i kilka innych postów dochodzę do wniosku, że mamy do czynienia z ciągiem małych błędów i niedopatrzeń, które się skumulowały i koniec końców uderzyły w tego na samym końcu.  Po pierwsze bug we wtyczce do GitHuba (nie w Visual Studio a w zewnętrznej wtyczce). W sumie mały błąd, niewielkie niedopatrzenie, ot jeden checkbox nie działający poprawie, tyle tylko, że stworzyło się publiczne repo a nie jak sądził developer – prywatne.

Wpadka….

Jak doszło zatem do tego, że 6485.39$ zniknęło z kieszeni (i pewnie kilka siwych włosów doszło w pakiecie? Nie, nie na głowie). Do repo poszły klucze do aws-a a że taki artefakt to cenna rzecz, jest wiele botów skanujące publiczne repozytoria w poszukiwaniu właśnie takich cukierków. To pozwoliło komuś zespawnować sporo maszyn np. do kopania bitcoinów za darmo (a raczej na koszt kogoś innego). No i tu pierwszy błąd developera. Tak cennych rzeczy nie wrzuca się do repo (nawet prywatnego) bo nigdy nie wiadomo, kiedy i gdzie stracimy nad tym kontrole. Serio patrz co wrzucasz do repozytorium. Czasem można znaleźć bardzo fajne rzeczy, jakieś prawdziwe numery pesel, connection stringi do baz danych (niektórych nawet publicznie dostępnych), nazwy użytkowników, hasła, numery telefonów i wszelkie klucze do API różnej maści. Naprawdę, takich rzeczy nie wrzucamy do kodu KROPKA. Bardzo Gość przynajmniej powinien to zaszyfrować!… ale serio? Czym by to rozszyfrowywał? Kodem? Tym, który jest w repo? Tym który był publiczny? Kolejny kiepski pomysł – w osobnym pliku niecommitowanym do repozytorium. Brzmi lepiej ale dalej słabo bo jeden mały błąd, jedna niedokonfigurowana maszyna ze złym gitignore i plik by wyleciał w sieć (tylko wtedy byłoby jaki to git zły bo przez niego straciłem 6500$).

Najlepiej by było, gdyby tego typu rzeczy w ogóle nie trafiały do repozytorium.

Do tego celu w Azure i AppHarbor i Heroku i pewnie w wielu innych służą zmienne środowiskowe czy jak to nazwać.

azure

Generalnie działa to tak, że super tajne ważne rzeczy wpisujemy (tu w przypadku azure-a) wpisujemy w sekcji connection strings lub app settings. Cały myk polega na tym, że aplikacja zamiast czytać z jakiegoś pliku czyta ze zmiennych systemowych/środowiskowych/przetworzonego configa. Analogicznie działa ten mechanizm w AppHarbour.

appharbour

Korzystam z tego w mvc oraz w nodzie i działa i da się. Kod jest czysty i może być publiczny. Co więcej nie muszę się zastanawiać za każdym razem, czy przypadkiem nie commituję pliku z tajnymi kluczami do storage-a czy czegoś tam innego.

Wracając do tematu, kolejny fackup. Czy serio w Amazonie nie można mieć różnych klucze do różnych zasobów? Wszystko jest dostępne z jednego klucza? Dzięki czemu można wydrenować podpiętą kartę? Inna sprawa dlaczego nie można (a może można tylko jak) ustawić limitów? Czy może jest jakiś sposób aby mieć konto „prepaid”.

Ostatnie ale pewnie najmniej ważne

Jeśli korzystam z publicznego serwera ale zakładam prywatne repo to robię to przez stronę dostawcy i sprawdzam czy aby na pewno repo jest tak stworzone jak chcę.  Tak samo upubliczniając jakiś zasób w OneDrive czy DropBox-ie. Jeśli chcę upublicznić jakiś zasób jednej osobie – to sprawdzam w trybie porno czy na pewno to jest dalej prywatne a nie publiczne.

Co wynikło zatem z całej tej afery?

Imho kilka dobrych rzeczy:

  • Amazon anulował rachunek i skontaktowali się z gościem, więc jest szansa, że wyciągną wnioski i wprowadzą jakieś ciekawe sposoby aby uniknąć takich rzeczy w przyszłości
  • Wtyczka do Visual Studio została naprawiona
  • Mam nadzieję, że nikt świadomie nie wsadzi API keys i innych sensytywnych wrażliwych danych do kodu i innych plików commitowanych do repozytorium – a przynajmniej zastanowi się dwa razy
  • Mam również nadzieję, że pokazałem alternatywne rozwiązanie w postaci app settings i connection string

Visual Studio 2015 i upgrade projektu za każdym razem

Visual Studio 2015 jest już od jakiegoś czasu. Instalacja, odpalenie projektu i do przodu. Coś tam się zaktualizowało w projekcie i mogę dalej pracować z nowymi zabawkami. Problem jaki mi się pojawił to w jednym solution ze sporą ilością projektów jeden z nich aktualizował się przy każdym otwarciu projektu.

Projekt, który chciał się aktualizować przy każdym otwarciu Visual Studio to MVC3, który później był migrowany do MVC4. Przy każdym otwarciu upgrade i kopia wszystkich plików i raport w html-u. Zanim na to zwróciłem uwagę, wrzuciłem całkiem sporo gnoju do repozytorium. Poszukując rozwiązania okazało się, że w trefnym pliku csproj wystarczy usunąć:

<FileUpgradeFlags>40</FileUpgradeFlags>
<UpgradeBackupLocation>Upgrade20</UpgradeBackupLocation>
<OldToolsVersion>4.0</OldToolsVersion>

Pozostało jeszcze wywalenie gnoju z repo i już można pracować jak człowiek.