Git podstawy

Ten wpis jest podsumowaniem wiedzy, którą zdobywałem czytając wprowadzenie do gita na stronie gitref.org. Jest to w zasadzie kurs który można tam przeczytać, tyle że przetłumaczony na język polski.
Instalowanie kluczy zostało praktycznie przeklejone ze strony eastgroup.pl. Wszelkie uwagi do tłumaczenia, błędów w skrypcie, uwag stylistycznych, merytorycznych i innych złośliwości należą się mnie, brawa i słowa gratulacji oryginalnym twórcom kursu.
O tym czym jest git można przeczytać na pl.wikipedia.org. Aby móc skorzystać z poleceń, które są tutaj wymieniane należy zainstalować gita, można go pobrać z strony http://git-scm.com/ klikając w odpowiedni system operacyjny. Ja skorzystałem z Git-1.7.4-preview20110204.exe dla windows.
Do dzieła!

Git podstawy:

  • Tworzenie repozytorium git w aktualnym katalogu: git init
  • Klon repozytorium ze zdalnego URL git clone url, wszystkie informacje na temat repozytorium zostają sklonowane. Git utworzy nowy katalog o nazwie projektu z którego został stworzony klon. Lokalna kopia posiada pełną historię zmian.
  • Status plików w aktualnym katalogu git status (-s krótszy opis). Wynikiem takiej operacji będzie lista plików z przypisanymi do nich atrybutami, poniżej znaczenie tych atrybutów:
    ? – nie zawierają się w repo
    A
    – dodany
    M
    -zmodyfikowany
    D
    – plik usunięty
    U
    – plik zaktualizowany ale nie zmerdżowany
    C
    – plik skopiowany
    R
    – plik przeniesiony
    Jeżeli nic nie zostanie wyświetlone, oznacza to że żadnej z plików nie został zmodyfikowany, a więc nie ma w ogóle o czym mówić. Krótki status (-s) zawiera informacje o plikach podzieloną na dwie kolumny; 1- wartość względem lokalnego repozytorium, 2- wartość dla aktualnie wprowadzanych zmian. Warto wspomnieć, że plik zmodyfikowany ale nie dodany do tworzonego snapshota nie będzie wykorzystany w trakcie wykonywania polecenia git commit (o tym rozkazie niżej). Status takiego pliku to ? albo M.
  • Dodanie nowych plików do snapshota lub zatwierdzanie zmian w plikach, dla których już jest prowadzony index w repozytorium to git add filename, można podać więcej niż jeden plik jako parametr. Dodanie wszystkich plików z aktualnego katalogu git add *. Dodanie wszystkich plików i wszystkich podkatalogów git add .(to jest kropka jako parametr).
  • Sprawdzenie aktualnych zmian wprowadzonych lokalnych plikach  git diff. 
  • Zmiany snapshot względem repozytorium to git diff –cached.
    Istnieje także opcja pominięcia snapshota i sprawdzenie zmian względem repozytorium, takim poleceniem git diff HEAD.
    Podsumowanie zmian, które zostały wprowadzone w plikach, ale bez szczegółów dotyczących tych zmian git diff –stat.
  • Wysłanie snapshota, w snapshot znajdą się tylko pliki zatwierdzone poleceniem git add (czyli posiadają status A), do repozytorium: wykonać polecenie git commit -m commenthere i snapshot zostaje zapisany do lokalnego repozytorium. Poleceni git commit potrafi także skorzystać z plików, które nie zostały dodane do snapshota, należy skorzystać z przełącznika a, wykonać git commit -am commenthere (uwaga: chyba nie działa na branchach).
    Pominięcie parametru m spowoduje, że git otworzy w domyślnym edytorze plików plik (coś mi się wydaje, że jednak zawsze jest to vim – INSERT, napisz komentarz, ESC, :wq, ENTER), gdzie należy podać komentarz do aktualnie tworzonego commita.
    Należy, a w zasadzie trzeba! podczas comitowania podawać opis wprowadzanych zmian – taka dygresja.
  • Jeżeli będzie potrzeba cofnąć plik ze stanu A do M (z jakiegoś powodu, nie chcemy zapisywać zmian), należy użyć polecenia git reset HEAD — filename (po — jest spacja), po takiej operacji zawartość pliku nie zostanie zmieniona, ale zostanie on uznany za lokalnie nie zatwierdzony, co spowoduje jego domyślne pominięcie przy wykonaniu operacji git commit.
    Git rozróżnia kolejność parametrów, poleceni git commit –am nie jest równe git commit –ma – warto o tym pamiętać.
  • Usunięcie pliku z repozytorium oraz z dysku git rm filename, jeżeli z jakiegoś powodu plik należy usunąć tylko z git, ale pozostawić go na dysku warto dodać parametr cached, polecenie wyglądać będzie tak git rm –cached filename. Równie dobrze można po prostu usunąć plik samodzielnie z katalogu, a następnie potwierdzić zmiany poprzez git add.. 

Tworzenie nowych gałęzi dla projektu oraz ich łączenie (merge)
Czasem pojawia się potrzeba zrobienia czegoś na boku, w gitcie możemy to osiągnąć za pomocą polecenia git branch oraz git checkout.

  • git branch wyświetli listę wszystkich dostępnych rozgałęzień w projekcie, gdy poda się nazwę nowej gałęzi zostanie ona utworzona: git branch nowy. Wywołanie git branch -d nazwa spowoduje jej usunięcie. Warunkiem jest to, że zmiany zostały już zaakceptowane oraz połączone z główną gałęzią lub ich nie wprowadzono. Można także wymusić usunięcie poprzez krzyknięcie, czyli -D
  • Po stworzeniu gałęzi, aby na niej pracować należy się na nią przełączyć, służy do tego polecenie git checkout nazwa, od tej pory pracujemy na nowej gałęzi projektu, wszelkie zmiany będą widoczne tylko gdy będzie ona aktywna. Dla leniwych istenieje polecenie git checkout -b nazwa, który tworzy nowy gałąź i automatycznie się na nią przełącza.

Pracując na boku korzysta się oczywiście z poleceń git add i git commit, a po wszystkim gdy trzeba połączyć gałęzie z pomocą przychodzi git merge nazwa. Git scala obie gałęzie projektowe, wraz z historiami obu. Oczywiście może pojawić się konfilikt podczas tej operacji, użytkownik zostanie o tym poinformowany plik zostaną złączone a odpowiednie wstawki z narzędzia merdżującego znajdą sie w plikach (>>>>> oraz <<<<<). Po wywołaniu git status -s pliki, które są w konfilikcie i wymagają ingerencji programisty będą miec status U, należy wtedy ręcznie dokonać operacji łączenia plików, oraz zaakceptować wynik poprzez git add plik a następnie git commit -m pamiętając o komentarzu.

  • Dla wścibskich historyków powstało polecenie git log wyświetlające historię comitów do repo. Warto sprawdzić użycie przełączników git log [–oneline] [–graph] [–decorate]. Można stosować je razem i osobno, kwestia gustu. 
  • Wspierane są także labelki (tag) git tag -a nazwa_labelki.

Praca ze zdalnym repozytorium
Wszystkie operacja, które zostały do tej pory opisany, miały charakter lokalny. Nikt nie miał do nich dostępu, źródła było tworzone i modyfikowane wyłącznie osoby korzystające z tego komputera. Czas więc udostępnić nasze poprawki i złote myśli innym, niech podziwiają naszą wiedzę i kunszt programistyczny. Aby tego dokonać potrzeba będzie postawić server git, a tym zdecydowanie kiedy indziej. Zakładam że skorzysta się z dostępnych gdzieś serwerów np. github.com i sklonuje sie repozytorium do siebie na dysk.
Oto link do mojego przykładowego repozytorium, które zawierać powinno plik c, c++, czy c# wyświetlające hello world. Także można z niego śmiało skorzystać, aby zrobić klona git://github.com/jsthedeveloper/hello-world-blog-example.git

  • Sklonowanie projektu do siebie na dysk uzyskuje się za pomocą polecenia git clone url, gdzie url to zdalna ścieżka do repozytorium z którego chcemy skorzystać. Taka sklonowana wersja zawiera całą historię projektu, można ją obejrzeć za pomocą git log –oneline –graph –decorate (:q).
  • Wyświetlenie serwerów (aliasów) z których korzysta sklonowane repozytorium to git remote (parametr -v poda dokładne adresy). Dodanie nowego serwera to git remote add [alias] [url] i oczywiście usunięcie git remote rm alias
  • Gdy zaistnieje potrzeba aktualizacji lokalnych źródeł do najnowszych dostępnych na zdalnych repozytoriach można skorzystać z opcji git fetch [alias], jeżeli korzysta sie z więcej niż jednego serwera. Po takiej operacji może wystąpić potrzeba merga git merge. Git lubi leniwców, istnieje więc poleceni git pull, które jest połączeniem git fetch i git merge.
  • Potem następuje normalna praca (add/commit), jeżeli chce się wysłać zmiany na zdalne repozytorium należy użyć polecenia git push [alias] [branch]. Aby móc poprawnie wykonać pusha, należy się poprawie autoryzować w repo i mieć uprawnienia do zapisu w repo, co przekłada sie na posiadanie odpowiedniego linka do repo.

Generowanie kluczy
Jeżeli nie posiadamy kluczy rsa, możemy skorzystać z pomocy git-basha, który został zainstalowany na naszym komputerze, do wygenerowania odpowiedniej pary kluczy [RSA wikipedia]. Uruchamiamy Git Bash następnie wykonujemy poleceni ssh-keygen i idąc po najmniejszej linii opory na wszystko odpowiadamy enterem. Bash napisze gdzie zostały zapisane klucze, zawartość pliku z kluczem publicznym przeklejamy do serwera gitowskiego i od tej pory git push powienien działać.
To by było w sumie na tyle, jeśli chodzi o git w konsoli. Istnieją graficzne nakładki na git, jeżeli do instalacji został wykorzystany link, który podałem, to można od razu skorzystać z opcji git gui. Ten wpis jednak nie będzie tego omawiać.
Jeżeli po przeczytaniu będą pytania, proszę o kontakt. Jeżeli po przeczytaniu będą nudności, proszę załatwić sobie radyjko. Innego typu uwagi, proszę komentarz, mail, czy inna forme komunikacji.

JS

Początki raz jeszcze

Jest taka książka Accelerated C# 2010 którą postanowiłem przeczytać, aby utrwalić swoją wiedzę z C#. W polskiej księgarni można znaleźć za około 120 nowych polskich złotych.
Jest przyjaźnie napisana i tłumaczy w lekki (dla mnie) sposób C#. Jej dużym plusem jest to, że nie jest ona dla początkujących programistów, a raczej dla osób które posiadają wiedzę z C++/Java (czy innego języka) i teraz chcieli by się nauczyć szarpa. Dlaczego tak się zajarałem? Książki które czytałem wcześniej nie wspominały nic o destuktorach (ani o tym, że w zasadzie nie powinno się z nich korzystać) w C# czy konstruktorach statycznych.
Te statyczne konstruktory to dla mnie w ogóle faza, w javie też niby są, ja tam nie wiem, javą się nie interesowałem. Poza tym gostek (w sensie autor), pisze też trochę o ILDASM, jak to wygląda w środku i czego się nie powinno używać. Myślę sobie, że to dobra książka na powtórzenie podstawowych wiadomości o tym języku w wersji 4.0.
Przy okazji będę mógł, wreszcie uczciwie napisać z której książki nauczyłem się podstaw.

Słówka kluczowe:
Konstuktor statyczny
Destruktory
params (tego też nie znałem)

Uwagi do mojej wybrakowanej wiedzy, słownictwa i prostactwa proszę zamieszczać w komentarzach.
A korzystając z okazji zapraszam na:

Geeks on tour (spotkania trzech grup społecznościowych, związanych z technologiami Microsoft)
wrocnet (wrocławska grupa .net)

Czy się różni wróbel

Niby prosta sprawa, a tak długo jak się tego nie sprawdzi to nie poczuje się różnicy.
Czym się różni Process.Start od AppDomain.ExecuteAssembly – a tym, ze to pierwsze uruchomi proces niezależny od rodzica. Podczas gdy druga opcja będzie działać we w tym samym procesie, w tej samej konsoli.
Tyle na dziś.

C# nauka, materiały, etc

Każdy chciałby się szybko, przyjemnie i w interesujący sposób uczyć nowych technologi, języków czy bibliotek.
Nie da się tego wszystkiego tak łatwo osiągnąć, albo ja nie znalazłem jeszcze sposobu. Jeżeli wiecie to będę wdzięczny za podzielenie się taką informacją.
Nie ustając się w poszukiwaniu idealnego sposobu na naukę znalazłem jeden, który można uznać za prosty. Trzeba tylko posiedzieć przed monitorem i pooglądać kilka prezentacji przygotowanych przez ziomali z microsoft i firm z nimi współpracujących.

Ale first things first – podstawy:
Każdy porządny i szanujący się programista, powinien przebrnąć przez trochę książek  (przynajmniej jedną) i napisać trochę linii kodu, aby w miarę płynnie posługiwać się językiem którego chce używać. Część z nas czyta wszystko od A do Z w oficjalnych książkach wydanych przez MS, inni lecą po łebkach i korzystają z różnego rodzaju kursów dostępnych na blogach. Rozumiem, każdy przyswaja wiedzę w inny sposób. Ważne jednak jest aby każdy rozróżniał klasę od obiektu, wskaźnik od referencji, czy inne słowa.
Próbowałem obu podejść (łebki vs książki) i moim skromnym zdaniem lepiej przeczytać książkę, tak aby dobrze opanować podstawy. Ja przeczytałem i mocno polecam (ten post dotyczy c#) Charles Petzold Programming MS Windows with C#, wcześniej czytałem też programowanie dla Win32 i też jest to dobra pozycja. Najmocniej przepraszam, ale nie mogę sobie przypomnieć nazwy książki, którą czytałem aby poznać podstawy C#.

Opanowałem podstawy i co dalej?
Namiętnie oglądam ostatnio serię “How do I” dla WPF i ogólnie C#. Wcześniej przejrzałem kilka dłuższych prezentacji z PDC i muszę powiedzieć, że dzięki temu w szybki sposób można poznać to co nowe (przynajmniej dla mnie, bo wciąż jestem początkującym programistą C#), oraz nauczyć się jak zrobi ficzera X.
PDC2008
PDC2009
PDC2010
How do I (wpf)
Naprawdę polecam zainteresowanie się tymi materiałami.

Czy coś jeszcze? Można się zapisać do różnych lokalnych grup wsparcia dla anonimowych programistów i tam się dalej rozwijać do czego także namawiam. Ja jak tylko znajdę czas i chęci to też się zapisze.

Pozdro
JS

ps.
Dzisiaj jakoś tak bez drwin.

Jak rysować w C#

Uczę się i uczę, sprawdzam wiedzę i sprawdzam i wyszło, że z rysowaniem sobie nie do końca poradziłem. Aby to poprawić chciałem coś napisać/narysować, od słowa (kluczowego) do słowa i zacząłem pisać prostego painta. W sumie nic skomplikowanego, a cieszy. Wyciosałem coś co może pretendować do miany prostego rysownika.

Można sobie wybrać kilka prostych opcji do rysowania plus kilka kolorów, nic fikuśnego. Później mnie trochę poniosło i dodałem opcje cofania edycji i zmiany rozmiaru okna do rysowania, co okazało się banalnie proste.
W zasadzie wszystko co powinna robić aplikacja to posiadanie listy kształtów i kolorów które trzeba narysować gdzieś na ekranie.
Potem pomyślałem o tym, że skoro ktoś spędzi przy mojej aplikacji tyle godzin rysując jakieś cuda, szkoda aby jego praca poszła na marne. Można więc zapisywać i odczytywać obrazek, ponad to można go nawet (wow!) wyeksportować do .png tak aby inne mniej zaawansowane programy mogły go odczytać. Mój paint nie zniży się do tego poziomu i działa tylko z własnym formatem pliku (zserializowana lista obiektów). Tak zamierzam wprowadzić nowy standard.

W między czasie przeczytałem krótki art o wzorcu odwiedzający (Visitor), jako że pasował trochę do koncepcji aplikacji, postanowiłem zrobić mały refactor, aby z niego skorzystać. Wzorzec działa całkiem sprytnie, ale wiadomo że nic nie przychodzi za darmo. Prosta zmiana z enum na odwiedzającego, spowodowała lawinę zmian, którą musiałem wprowadzić do aplikacji, aby przystosować do nowej logiki. Jeszcze jedno spostrzeżenie, ten wzorzec szybko zwiększa ilość klas w projekcie.
Od razu przychodzą rozważania nad oczywistą oczywistością – nic na siłę. Jeżeli rozwiązanie z którego korzystam jest zupełnie wystarczające, nie powoduje problemów, etc to nie widzę najmniejszej potrzeby zmiany. Może poza ciekawością lub celami czysto szkoleniowymi. Tak właśnie było w moim przypadku.

Przy okazji poćwiczyłem także XAML i UI, naprawdę sporą część aplikacji robi się właśnie w designerze – to dobre jest. Pisanie GUI całkowicie w kodzie, a potem zabawa w przesuwanie tego po ekranie, powiększanie i obsługa OnSize(…), OnMove(…), szkoda na to czasu, tym bardziej że można to wyklikać, dzięki czemu prawdopodobieństwo popełnienia błędu jest dużo mniejsze.

Jeżeli ktoś będzie ciekawy jak prosto napisać Painta w C# lub chciałby zobaczyć jak ja to zrobiłem. Lub chciałbym zobaczyć jak skorzystałem ze wzorca odwiedzający, lub chciałbym zobaczyć kod lub po prostu jest znudzony lub zbiera kod lub … To właśnie wtedy powinien skorzystać z tego linka xp-dev i zaciągnąć odpowiednie źródła.

Pytania, odpowiedz i drwiny w komentarzach (jak zawsze)

ps.
Poly nie dziala
ps2
Już weekend!