GeeCON – relacja subiektywna
Jeżeli przychodząc do mulitkina zamiast filmu widzisz na scenie brodatego gościa opowiadającego po angielsku o dziwnych rzeczach, a na widowni widzisz masę młodych ludzi z 95% przewagą płci męskiej – to znaczy, że jesteś w Poznaniu na GeeCONie.
Wszystkie wykłady z konferencji będą dostępne na stronie konferencji, dlatego nie ma sensu ich dokładnie streszczać – poniższy wpis jest subiektywnym zebraniem wrażeń i najciekawszych informacji z prezentacji.Dowiedz się więcej »GeeCON – relacja subiektywna
Być może po przeczytaniu tekstu o jakości (
Wielu programistów i firm z branży IT często mówi, że potrafi wytwarzać oprogramowanie wysokiej jakości i że bardzo ważnym jest, aby o tą jakość zabiegać. Nie ma w tym nic dziwnego – wszyscy jesteśmy gotowi zgodzić się, że jakość powinna być możliwie wysoka. Problem pojawia się jednak w momencie, gdy trzeba doprecyzować pojęcia i stwierdzić, czym tak naprawdę charakteryzuje się oprogramowanie wysokiej jakości i jak można tą jakość osiągnąć.
Narzędzi typu issue-tracker – czyli narzędzi wspomagających ewidencję i zapisywanie zadań – jest cała masa. Zrobienie przeglądu i recenzji przynajmniej najważniejszych z nich przekracza zdecydowanie skromne możliwości autorów tego serwisu… Ale zdecydowanie warto przyjrzeć się jednemu z nich – narzędziu 
Po kilku zapowiedziach i bez zbędnych wstępów zaczynamy spotkanie z 
Ten wpis nie będzie o prawach autorskich, nie będzie o zawiłościach umów GPL ani też nie będzie nic o ACTA. Będzie o bardzo prostym pytaniu: czy fragmenty kodu aplikacji, które tworzymy lub też zmieniamy, powinny być przypisane do właścicieli.
Czasami, kiedy mówimy o jakości kodu, to pojawia się stwierdzenie „nasz kod jest kiepski, bo nie ma w nim komentarzy”. Powstaje taka intuicyjna równoważność: „dużo komentarzy – dobry kod, brak komentarzy – zły kod”. Ba, idąc tą drogą można nawet wprowadzić metrykę, określającą stosunek liczby komentarzy do liczby linii kodu i zmuszać programistów do osiągnięcia jakiejś magicznej jej wartości. Tylko po co? Czy zawsze komentarze ułatwiają nam analizę kodu? Czy istnieją komentarze, które przeszkadzają zamiast pomagać?
Na Trzeciej Kawie od jakiegoś czasu cisza… aż tu nagle Nowy Rok nastał. Nie chcę tłumaczyć się za kolegów współautorów odnośnie ich milczenia w ostatnim czasie – napiszę więc o sobie, bo tak się składa, że powody mojej publicystycznej przerwy nadają się na materiał do kolejnego artykułu. O co chodzi? Przez ostatnie kilka miesięcy brałem udział w swoistym „eksperymencie” organizowanym przez Uniwersytet Stanforda. Pomysł był w miarę prosty – zorganizować dobre, darmowe i ogólnie dostępne kursy akademickie. Ja brałem udział w dwóch takich „przedmiotach” – było to „wprowadzenie do sztucznej inteligencji” (
Coraz więcej firm i zespołów używa metodologii lekkich do wytwarzania oprogramowania. Wśród tych metodologii bardzo popularny jest Scrum. Nie jestem specjalistą od tej Scruma i dlatego chciałbym zadać trzy pytania, na które obecnie nie znam odpowiedzi. Może ktoś bardziej doświadczony w tej metodyce dopisze do nich odpowiedzi?
System kontroli wersji (w skrócie VCS) jest to oprogramowanie, które służy do współdzielenia i śledzenia zmian w plikach oraz pomocy w łączeniu zmian pochodzących z różnych źródeł. W każdym, nawet najmniejszym projekcie, gdzie kilka osób pracuje równolegle nad tymi samymi plikami, niezbędne jest miejsce gdzie wszystkie te zmiany się spotykają – tutaj właśnie do gry wchodzi repozytorium kodu. Nawet jeżeli pracujemy sami, to powinniśmy się zastanowić czy nie chcielibyśmy skorzystać z możliwości śledzenia zmian jakie daje nam VCS. W tym tekście postaram się przedstawić pokrótce ewolucję systemów VCS i możliwości coraz bardziej popularnego w ostatnim czasie Git’a.