Repozytorium kodu a w nim jeden z najważniejszych artefaktów

hitoria kodu zapisana w repozytorum

Repozytorium kodu to jedno z podstawowych narzędzi programisty, bez którego żaden profesjonalista nie może się obejść. W nim jeden z najważniejszych produktów jaki tworzymy obok głównego aplikacji.

Historia produktu zapisana w repozytorium kodu

Tworząc aplikację z każdym commitem tworzy się historia. Tworzy się ciąg kroków, jakie doprowadziły aplikację do stanu dzisiejszego. To co możemy w tej historii wyczytać jest czasem bardzo cenne. Kiedy? Po pierwsze wtedy, gdy chcemy przypomnieć sobie co zrobiliśmy od wydania ostatniej wersji. Po drugie gdy chcemy poprawić jakiś błąd.

Release Notes z historii commitów

Pracując w zespole większym niż jednoosobowym i wydając kolejne wersje (bez względu czy to jest aplikacja pudełkowa, webowa czy usługa) często potrzebujemy śledzić co w kolejnych wersjach zostało wydane. Historia kolejnych commitów staje się w takiej sytuacji bardzo pomocna – oczywiście przy założeniu, że dajemy przyzwoite nazwy do commitów – i zakładam, że na dzień dzisiejszy mało osób jest tak nierozsądnych aby robić commity bez odpowiednich komunikatów. Można pójść nawet dalej. Jeśli mamy jakiś sensowny automatyczny build to możemy z automatu tagować kolejne wydania wersji i wysyłać listę commitów do osób odpowiedzialnych za to co się dzieje z takim artefaktem jak wydanie wersji później.

Historia jako narzędzie do debugowania

Drugie zastosowanie historii commitów jest dużo ciekawsze z punktu widzenia developera. Ile razy zachodziłeś w głowę dlaczego ktoś napisał kawałek kodu tak a nie inaczej? Dlaczego ktoś zrobił taki błąd? Czasem kawałek kodu potrafi być tak zagmatwany, że nie da się go zrozumieć, czasem tak głupio napisany, że aż niemożliwe, żeby autor napisał takie cudo na trzeźwo. Wtedy przychodzi na ratunek historia i opcja blame lub annotate (w zależności jakich narzędzi używasz). Ta opcja pozwala sprawdzić, kto ostatni dotykał każdej kolejnej linki w kodzie.

Blame i annotate

Dzięki temu bardzo szybko namierzymy osobę, która zostawiła kod w takim stanie. Warto zastanowić się, dlaczego kod został napisany tak a nie inaczej. Czasem wystarczy przeczytać commit message a czase trzeba zapytać osobę, która ostatnia go edytowała. Czasem dowiemy się, że kod powstał w jakiejś pomroczności i to jest po prostu zepsute ale czasem odkryjemy, że były jakieś ważne powód. Czasem to jakieś dziwne wymaganie klienta a czasem dziwne zachowanie frameworka czy biblioteki. Pewnie ktoś stwierdzi, że można wtedy zostawić komentarz – ale komentarze mają tą brzydką cechę, że gniją  a bądźmy szczerzy, kto refaktoryzuje komentarze – to się nie sprawdza.

Do czego jeszcze może się przydać historia?

A choćby do tego, aby raz na jakiś czas pooglądać kod z lotu ptaka i zobaczyć ile pracy i energii włożyliśmy w stworzenie aplikacji puszczając na całym repozytorium narzędzie gource które pięknie wizualizuje kolejne commity w czasie – warto wybrać się w taką wycieczkę.

A Tobie do czego jeszcze przydaje się historia commitów w Twoim repozytorium?

Repozytorium kodu i puste commity

formatowanie kodu

Repozytorium kodu – jedno z najważniejszych narzędzi w arsenale programisty, developera. No właśnie… w ostatnim wpisie pisałem o automatycznym formatowaniu kodu i jak to zautomatyzować. Większość czasu czytamy kod niż piszemy więc to co piszemy musi być czytelny, dlatego kod musi być czytelny, dlatego dobrze go formatować.

Repozytrium kodu i automatyczne formatowanie kodu to same problemy

Jest jedno ale do tego całego formatowanie, mianowicie standardy. Wyobraź sobie, że lubisz wcięcie na 4 spacje (serio nie interesuje mnie czy wolisz spacje od tabulatorów, to bez znaczenia – wiadomo że taby rulez 😉 ) a współprograista tabulatory. Pobierasz kod z repo i przeformatowywujesz go na jedyny słuszny styl. Zresztą to  nie musi być odwieczna wojna spacje vs tabulatory, wystarczy prozaiczne z pozoru umiejscowienie wąsów w tej samej linni vs w nowej linii. Tak czy inaczej formatujesz na jedyny słuszny styl, robisz swoje i commitujesz. Współprogramista robi dokładnie to samo, pobiera, formatuje na jedyny słuszny styl, robi swoje i commituje. Jak w kołysce newtona (na obrazku powyżej) będziecie się obijać. Ale to nie najgorsze, najgorsze nadejdzie jak trzeba będzie zaglądnąć w historię commitów. Wtedy okaże się, że każdy jeden commit zawiera bardzo dużo zmian a jak zaczniesz przeglądać te zmiany okaże się, że 99% to przeformatowanie kodu.

Historia rzecz święta

Co powie Ci historia zmian w repozytorium jeśli 99% to będzie ping pong pomiędzy dwoma obozami jedynego słusznego formatowania? Taka historia na wiele się nie zda. Będzie po prostu bezużyteczna. Tutaj dochodzimy do sedna automatycznego formatowania kodu. Repozytorium kodu musi być czyste i czytelne tak samo jak kod, dlatego też wszyscy w zespole muszą mieć takie same standardy kodowania. To pozwoli zachować porządek w repozytorium kodu to po pierwsze, pozwoli uniknąć frustracji, że znowu ktoś użył złego standardu, pozwoli wreszcie skupić się na pracy.

Ludzi i interakcje od procesów i narzędzi

Pierwszy punkt agile manifesto… ludzie i interakcje… może warto przedyskutować w zespole wspólne standardy kodowania i ustawić wszystkie narzędzia tak samo. Wtedy będziemy mieli z automatu kod dobrze ustawiony a w historii w repo będzie porządek. Tylko tyle i aż tyle. Proste no nie?

Umarł GitLab niech żyje Git czyli co zrobić jak zepsuje się repozytorium Git-a

git sie zepsul co robic

Git to repozytorium kodu a repozytorium kodu to jedno z podstawowych narzędzi pracy programisty. Dzisiaj pół internetu pisze, że GitLab – serwis do hostowania repozytoriów git – zaliczył poważną wpadkę. Trudno, zdarza się ale jakie można z tego wyciągnąć wnioski?


Single Point Of Failure

Centralne repozytorium kodu ma tą wielką zaletę, że jest centralne. SVN-y, SourceSafe-y i inne tego typu repozytoria kodu mają wielką zaletę – jedno źródło prawdy. To też najsłabsza strona – bo jak padnie serwer to nie ma nic. Na komputerach programistów pozostanie wprawdzie kod źródłowy ale bez jakiejkolwiek historii. Na ten wypadek warto mieć zbudowany odpowiedni plan backupu a właściwie kilku backupów – w chmurze, w szafie ogniotrwałej, offsite. Warto by było od czasu do czasu sprawdzić czy z backupu da się cokolwiek odzyskać. Generalnie w sytuacji awarii serwera odgrzebujemy backup, przywracamy repozytorum i pracujemy dalej no chyba, że padł sprzęt a my nie mamy zapasu, wtedy zamawiamy nowy, przywracamy co trzeba i pracujemy dalej. Już po kilku godzinach lub dniach spokojnie sobie pracujemy. Czy nie da się tego jakoś usprawnić?

Git na ratunek!

Dzisiejsza awaria GitLaba przeraziła całkiem sporą część internetu. Nie ma się co dziwić, bo wyobraź sobie, że nagle nie masz dostępu do swojego repozytorium. Mi się taka akcja zdarzyła w najgorszym możliwym momencie – w czasie wdrożenia przy sporej presji czasowej. Nagle repozytorium git-owe padło a dokładniej padł vpn do serwera ileś tam kilometrów dalej. Dwie osoby pracują nad kodem – wiadomo, ostatnie poprawki – czas ucieka, zmęczenie doskwiera a tu co? mamy ręcznie kod mergować? Na szczęście git to rozproszone repozytorium kodu a nie jak wspomniane w pierwszym akapicie „centralne repozytoria”. Rozproszone repozytorium oznacz tyle, że masz lokalną kopię całego repozytorium na komputerze. To oznacz, że bardzo szybko możesz postawić inne repozytorium. W moim przypadku sprowadziło się to do założenia repozytorium na bitbuckecie (bo tam można za darmo hostować prywatne repozytorum) a potem wykonania dwóch komend:

[code]

    git remote add backup git@bitbucket.org:.../.....git

    git push backup master

[/code]

To spowodowało, że w chmurze pojawiła się pełna kopia repo i mogliśmy spokojnie pracować dalej. Cała operacja trwała może 5 minut razem z założeniem konta i wysłaniem danych.

Czy awaria gita to jakaś tragedia?

No właśnie, wracając do samej awarii gitlab-a (ale i innch, githuba, bitbucket-a i tych wszystkich tajnych firmowych „bezpiecznych” repozytoriów), jeśli tylko nasze repozytorium jest rozproszone to w 5 minut jesteśmy wstanie postawić kopię i pracować dalej. Taka awaria będzie dla nas mikro przeszkodą a nie tragedią blokującą pracę na godziny a czasem nawet na dni. To jest siła posiadania kopii repozytorium lokalnie…

… z małym zastrzeżeniem, jeśli regularnie commitujemy i regularnie pushujemy do zewnętrznego repozytorium.

Konferencja pod chmurką z piwkiem w ręce

Dawno dawno tutaj nic nie publikowałem. Sporo tematów leży w kolejce i czeka aż będzie chwila czasu. Ostatnio ten czas dosyć skutecznie zjada coś, co zaczęło się od niewinnego… „a może byśmy zrobili konferencje?” Było to dawno dawno temu, gdzieś ponad rok temu. Wracając z konferencji tak od słowa do słowa razem z Piotrkiem stwierdziliśmy, że można by zrobić konferencję. Niestety ani czasu ani sposobności do tego nie było. Jednak pewnego dnia pojawiła się mała, mikroskopijna szansa… przy odpowiednim ułożeniu Księżyca, Jowisza, Marsa i kilku innych głazów w kosmosie rzucone „lepiej zróbmy swoją własną konferencję” trafiło na podatny grunt. A potem to już poleciało. I tak mamy dzisiaj 1.08 a ja mam ogromną przyjemność zaprosić Ciebie na konferencję BBQ4.IT która odbędzie się 9 września czyli dobre zakończenie wakacji i początek nowego roku intensywnych wyzwań. To również ostatni weekend przed dniem programisty i jeśli dobrze pamiętam dzień admina więc idealny termin aby zrobić konferencyjkę przy grillu i piwku. Założenia są proste. Ma być miło i przyjemnie dlatego zaprosiliśmy najlepszych z najlepszych polskich mówców z branży, do tego zorganizowaliśmy zadaszenie (jakby padało bo event będzie na wolnym powietrzu), profesjonalną ekipę co nam usmaży kiełbaski i naleje piwko. Wszystko free. Jedyny wymóg to posiadanie wejściówki, które są darmowe. Dlatego zarejestruj się już teraz zanim wejściówki jeszcze są.

Zapraszam i do zobaczenia 9.09 Bielsko-Biała BBQ4.IT

Konferencja Get.Net

Dwa lata temu wybrałem się na pierwszą edycję Łódzkiej konferencji GET.NET, która była moim zdaniem bardzo udana. Pewnie nie tylko moim bo powstały kolejne edycje. W tym roku zaś otrzymałem zaproszenie aby poprowadzić prelekcję. Zaproszenie przyjąłem i tak oto wylądowałem kolejny raz na GET.NET. Oprócz swojego gadania o IoT udało się posłuchać kilku fajnych wykładów. Ścieżki były dwie więc trzeba było wybierać a nie było łatwo. Na pierwszy rzut poszedł Maurice de Beijer z wykładem o dockerze. Próbowałem podejść do tematu kilka razy ale bez większych emocji, po prostu nie miałem wielkiej potrzeby. Maurice pokazał tak naprawdę podstawowe „Hello Docker World” ale w taki sposób, że wszystko podał elegancko na talerzu. Prosto i do rzeczy, jeśli nie wiedziałeś co to Docker to wyszedłeś z wiedzą a jeśli już coś liznąłeś w temacie to też można było się co nieco dowiedzieć. Później poszedłem na DevOpsy z mBanku w wykonaniu Piotrka Stappa. DevOps oglądałem przez szybkę bo codziennie zajmuję się innymi rzeczami więc stwierdziłem – a co tam, zobaczmy coś nowego. No i nie zawiodłem się, Piotrek pokazał wiele elementów i wiele rozwiązań, które warto stosować a główna oś – koszykówka pięknie się w to wpasowywała. Potem Andrzej Krzywda ze swoim Legacy to DDD – wreszcie bo z tym wykładem nigdy jakoś po drodze nie miałem, albo inna ścieżka albo nie byłem na konferencji gdzie o tym mówił a temat arcy (arkency) ciekawy. Fajnie słucha się człowieka, który opisuje swoją ścieżkę do oświecenia i widzi się sporo wspólnych części*. Temat trudny ale pokazany prosto i pokazany gdzie są korzenie tego wszystkiego. Od mnie dodam tylko, że warto się tym zainteresować bo to działa i ułatwia życie – btw. odszukajcie play listę Andrzeja na spotify i przeczytajcie nazwy utworów, to jest lista Andrzeja do refactoringu 🙂 Dalej na talerzu znalazł się Michał Jasiorowski mówiący o Akka.net Kolejny temat, którym warto się zainteresować bo actor model to mimo, że stary pattern to bardzo mocny. Sama akka.net to 1 do 1 port z javowej akka więc korzenie całkiem solidne. Na deser już bez możliwości wyboru, jeden wspólny wykład i Wojtek Erbetowski o budowaniu api dla apek mobilnych. Sam bym nie wybrał się na to bo mobilnych apek nie piszę i nie zapowiada się na razie więc…. ale nie było wyboru więc poszedłem i posłuchałem. No i Wojtek otworzył mi oczy na wiele spraw. Małe urządzonka jakimi są telefony i tablety rzeczywiście maja swoje wymagania. Dla mnie bardzo ciekawy wykład.

Co bym zmienił w konferencji? Hm… myślę, że z salami dziwnie wyszło bo aula spora – tak aby pomieścić wszystkich, później świeciła pustkami bo połowa ludzi poszła do innej sali. Mimo tego że na dużej auli ludzi było sporo to wyglądało że wcale wiele nie ma. Chyba lepiej by wyszło gdyby dalsze wykłady były na małych salkach. No i ciasteczka i kawa na tym samym poziomie była by mile widziana. Reszta super. Miejsce parkingowe, łatwy dojazd, fajne wykłady i tylko piwa pokonferencyjnego szkoda no ale trzeba było wracać 🙂

Czy warto prowadzić bloga?

W ostatnim wpisie pisałem dlaczego warto zgłosić się do konkursu daj się poznać – tak przy okazji to jeśli jeszcze się wahasz to chyba ciągle można się zgłaszać więc nie jest za późno. Tak przy niedzieli mnie naszło – dlaczego warto prowadzić bloga. Poza różnymi benefitami, których nawet się nie spodziewasz i poza “personal brandingiem”, który może bardzo pomóc w przyszłości jest coś co jest słabo może mierzalne finansowo ale jest bardzo inspirujące – przynajmniej dla mnie. Mianowicie satysfakcja. Czyli coś czego nie da Ci nawet najlepsza wypłata za najbardziej gównianą robotę. Dobra płaca za męczącą pracę wcześniej czy później wypali, zniszczy, przemieli i wypluje pusty korpusik. Satysfakcja z tego co się robi jest kołem napędowym do wielu wielu wielu innych rzeczy. Daje poczucie sensu. Dla mnie takie poczucie dały dwa komentarze jakie dostałem.

Really Need That, Thanks Bro

Muhammad Taha

Thank you very much to share your knowledge you save me

Victor Cabrera

Dlaczego piszę o tych dwóch konkretnych komentarzach? Bo są po angielsku i mimo, że nie prowadzę bloga po angielsku a po polsku to jednak pewnie problemy jakie opisałem były na tyle efemeryczne, że dopiero tutaj ktoś trafił na rozwiązanie. Każdy z nas tygodniowo co najmniej kilka takich błędów rozwiązuje. Warto o tym napisać, żeby wszystkim się lepiej żyło. Nic tak nie irytuje jak znalezienie błędu, który mnie zatrzymuje w pracy a w internetach nikt takiego problemu nie ma. Pisz! Ktoś pewnie czeka na Twoje rozwiązanie.

Daj się poznać – ostatni gwizdek

Już tylko kilka godzin zostało na zgłoszenie tematu do konkursu Daj się poznać. Zastanawiasz się po co? Po to aby wygrać rewelacyjne krzesełko, xboxa czy wiele wiele innych nagród. Tak na poważnie, to te nagrody jakkolwiek fajna rzecz to do wygrania jest o wiele więcej. Zasady są dosyć proste a jednocześnie dosyć paskudne. Wystarczy regularnie rozwijać swój pet project i pisać o tym – ot i cała paskudna część. Pisać w dodatku regularnie. Bodajże dwa wpisy tygodniowo. To dużo – jak dla mnie nawet bardzo dużo. Tyle tylko, że to jest moc, jeśli przejdziesz konkurs to oprócz nagród będziesz mieć całkiem sensownego bloga z całkiem dobrym startem.

Po co mi blog?

No właśnie, po co mi blog? Jest wiele powodów aby prowadzić własnego bloga. Wg. mnie conajmniej kilka powodów:

  1. Personalna baza wiedzy. Coś rozkminiłeś? Rozwiązałeś trudny problem albo paskudny bug? Napisz o tym. Po pierwsze jak trafisz na to samo, to będziesz wiedział gdzie szukać, po drugie jeśli ktoś trafi na podobny problem, pomożesz tej osobie. Ułatwisz trochę komuś życie. Czytasz stack overflow albo inne miejsca, googlujesz/bingujesz jak nie potrafisz czegoś rozwiązać. Ot taki wpis to taka drobna zapłata za pracę innych.
  2. Personalna baza, która jest TWOJA!!! To nic, że na Stacku masz odpowiedzi prawie tyle co John Skeet. Nadejdzie taki dzień, że stack zniknie, nadejdzie taki dzień, że Twoje ulubione forum przestanie istnieć a Twój blog będzie żył tak długo jak Ty chcesz.
  3. Blog otwiera nowe możliwości – serio i dosłownie. Ćwiczysz swój warsztat pisarski a nigdy nie wiadomo, kiedy taki może się przydać a oprócz tego mogą dotrzeć do Ciebie ludzie, którzy szukają takich umiejętności jakie Ty posiadasz. Osobiście dzięki blogowi dostałem kilka licencji na soft, który raczej bym sobie nie kupił albo inaczej nie sądziłbym, że może być dla mnie potrzebny. Również dzięki blogowi dotarłem na kilka wydarzeń, na które pewnie bym nie wybrał się.
  4. Blog to również oszczędność czasu, zamiast któryś raz komuś coś tłumaczyć, pokazywać wystarczy czasem wysłać linka do wpisu na ten temat. Zamiast pisać po 5-10 razy to samo w mailu/messangerze/gadu-gadu/skypie czy czym tam się komunikujesz wystarczy napisać to raz na blogu i podsyłać jak jest taka potrzeba.
  5. Blog to również nauka, czasem napiszesz coś.. hm…. nietrafionego, i nawet nie wiesz jak bardzo i czasem znajdzie się pomocna dłoń, która podpowie Ci gdzie robisz błąd (chociaż bądź przygotowany, że czasem powie Ci to w sposób delikatnie mówiąc oschły 🙂 )
  6. W końcu blog to lans – który czasami przeważy na Twoją korzyść np. rozmowę kwalifikacyjną. Serio 😉

A co to ma wspólnego z „Daj się poznać”?

Ano tyle, że musisz przez cały czas pisać dwa posty tygodniowo. Po tym czasie po prostu wyrobisz sobie nawyk i rytuał pisania, dzięki temu będzie Ci po prostu łatwiej pisać dalej. A to jest bardzo ważne bo nic tak nie zabija blogów jak wymówki:

  1. Jutro napiszę – jasne, nie napiszesz
  2. Jutro zacznę prowadzić bloga – jasne, jak dzisiaj nie zrobiłeś nic w tym kierunku to czemu jutro ma być inaczej?
  3. Ale kto mnie będzie czytał – jasne, jakby to miało znaczenie. Będziesz pisał to powoli znajdą się ludzie, którzy znajdą w tym wartość. Zresztą Sienkiewicz chyba nie pomyślał „napiszę książkę, ale tak zajebistą, że przez lata będą to we wszystkich szkołach czytać”
  4. Ale nie mam ładnego tematu – no i co? Liczy się treść. Liczy się aby zacząć pisać. Z czasem znajdziesz temat czy wygląd strony taki jaki będzie Ci odpowiadał. Pamiętaj jednak, najważniejszy pierwszy krok i rozpoczęcie pisania. Nie ma chyba nic bardziej bezsensownego i kontrproduktywnego niż pół roku deliberowanie nad skórką dla bloga. NAPISZ COS I OPUBLIKUJ!!!
  5. Nie wiem jak postawić bloga – no jasne! W to nie uwierzę. Robimy w IT i serio nie wiesz jak postawić wordpressa na choćby Azure czy innym Amazonie? Proszę Cie….

Mój udział

W tej edycji nie biorę udziału, robię miejsce dla nowych. Ale jeśli zastanawiasz się jak to wyglądało bo masz jeszcze wątpliwości to pooglądaj moje stare wpisy z pierwszej edycji daj się poznać. Przed konkursem prowadziłem bloga dużo wcześniej ale z mizerną częstotliwością teraz jest dużo dużo lepiej (serio 😛 ). Konkurs dał mi osobiście pewnego kopa aby ruszyć z tym. I to jest dobre. Zdobyłem również książkę, c# in a nutshell całkiem niezłą biblię o c#. Co do aplikacji to niestety nie przeżyła próby czasu ale sporo się przy niej nauczyłem. Co ciekawe to przeglądając wpisy konkursowe znalazłem info o TDD czyli już wtedy z tym eksperymentowałem co patrząc z perspektywy czasu było potężną inwestycją. Aktualnie od ponad 5 lat pracuję bardzo dużo z TDD i czasem również szkolę z tego tematu. Ot taki pokonkursowe benefity – długi ogon. Z obecnej perspektywy – warto było.

A na koniec PRO TIP! Staraj się pisać 3 wpisy tygodniowo ale publikuj 2. Nadejdzie taka pora, taki dzień, że inne zadania będą utrudniały zrealizowanie zadania. I wtedy jak znalazł masz gotowe wpisy, zresztą nic nie stoi na przeszkodzie, aby wszystkie wpisy od razu dodawać do zaplanowanej publikacji – w wordpressie zamiast publikuj dajesz zaplanuj – i jeśli dopadnie Cię jakaś straszna grypa to spokojnie bez spiny chorujesz. Serio pomyśl o tych 3 wpisach tygodniowo jako o swoim backupie!

Project Rider czyli IDE dla C# od JetBrains-a

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

missing SignTool.exe w Visual Studio 2015

Aktualizacja do Visual Studio 2015 dawno za mną. Tak dzisiaj wyszło, że dzisiaj chciałem opublikować za pomocą ClickOnce jedną rzecz.

Kod działa, publikacja też, zawsze działała a tu klops.

missing SignTool.exe

i pomyśleć, że wystarczy w instalce zaznaczyć ClickOnce Publishing Tools.

ClickOnce Publishing Tools

Więc jeśli Tobie też nie działa to Dodaj usuń programy, Visual Studio 2015, (w Windows 10 odinstaluj) i zmodyfikuj swoją instalację. I już można pracować.