yanoo.pl

Zawsze mam problem, kiedy ktoś mnie pyta “dlaczego właściwie to php jest takie złe? argumenty proszę!”. Mój problem polega na tym, że niespecjalnie potrafię swoją intuicję ubrać w odpowiednie słowa, by odpowiedzieć na takie pytanie w zadowalający obie strony sposób.

Problem niejako rozwiązał się sam dzięki wpisowi Jarosława Zabiełło na forum polskiej społeczności php, pod którym podpisuję się ręcyma i nogyma. Jeśli chcesz zatem wiedzieć dlaczego php to zło – przeczytaj ten tekst.

Człowiek się uczy całe życie – właśnie “odkryłem” dość istotny niuans zabaw z jQuery, który nie wiedzieć czemu nie był mi znany wcześniej¹. Otóż podając selektor można jeszcze w drugim parametrze dodać context, o np tak:

$('div.gołeDupy', '#porno');

I nie mylić tego (jak ja w pierwszej chwili) z multiselektorem. Nie wiem jak wy, ale ja tego nie znałem, a okazuje się, że nie tylko ja. Bajer polega na tym, że teraz sizzle będzie szukać nie w całym dokumencie DOM, ale jedynie jego wycinku pod #porno. Uważny czytelnik mógłby powiedzieć, że to samo otrzymamy przez:

$('#porno div.gołeDupy');

Będzie on jednak w błędzie. Streszczając – jQuery najpierw wyszuka w DOM gołeDupy, a dopiero potem zawęzi do #porno. Więcej w tym (i nie tylko) temacie można poczytać na nettuts.

1. całe szczęście, że nie przyznaję się do klepania js-a, bo by była siara [↩]
2. html5 dopuszcza unicode dla nazw identyfikatorów i klas [↩]

Dawno, dawno temu na inżynierii oprogramowania opowiadali o gałęziach projektu, że jest główna, deweloperska, i jeszcze inne w zależności od potrzeb. I że to jest dobre i tak należy robić, bo dzięki temu jest porządek, a główna linia projektu “zawsze” stabilna. Potem przyszło życie i brutalne grzmotnięcie o ziemię – wszyscy walą do głównego zbiornika¹, najlepiej jeszcze z komentarzem “update” śląc z regularnością szwajcarskiego zegarka commity po kilkadziesiąt (albo i więcej) plików wprowadzających zmiany dotyczące wielu aspektów projektu ².

Ludzie to z natury leniwe zwierzęta, a stworzenie gałęzi w SVN-ie wymaga, by doprosić się o nią u odpowiedzialnego za repozytorium. Gałąź sama w sobie zresztą kosztuje – jest niczym innym jak kopią projektu na dysku. O ile jeszcze jakieś ważniejsze gałęzie może i powstają (ale to tylko przy dużych projektach, bo małe i większość średnich kończy bez nich), to już wyobrażacie sobie prosić admina “zrób mi brancha bug666″? Nawet jeśli problem nas nie dotyczy (bo mamy wystarczającą władzę, żeby utworzyć gałąź), to wyobraźmy sobie wściekłość współpracowników, kiedy przyjdzie im ściągać XXX MB plików, bo jakiś debil zrobił kopię tylko po to, żeby wprowadzić i przetestować na spokojnie poprawkę w jednym-dwóch plikach. Gdyby tak zaczął robić każdy programista w projekcie, to mielibyśmy piękne wyścigi kto komu szybciej zapełni quotę.

W tym miejscu pojawia się rycerz na białym koniu płodząc cudowne dziecko z jego killer featurem dającym gałęzie “za darmo”:

git checkout -b bug666

I już. W ułamki sekund. A co najważniejsze – nie tworzymy żadnej nadmiarowej kopii, a współpracownicy dzięki temu, że mamy do czynienia z rozproszonym systemem w ogóle nie będą wiedzieli o istnieniu naszej tymczasowej gałązki. Oczywiście – nic nie stoi na przeszkodzie, by stała się ona pełnoprawną gałęzią całego projektu – wystarczy pchnąć ją na serwer:

git push origin³ bug666:bug666

i dopuścimy w ten sposób kolegów do pracy nad demonicznym błędem.

Takie podstawy opisuje jednak pierwszy lepszy tutorial, które zresztą rosną jak grzyby po deszczu. Niestety, sporo osób używa jednak git-a tak samo jak svn-a ograniczając się do podstaw⁴, które dostarczają owe tutoriale. Być może powodem tego jest wspomniane lenistwo – no bo jak to, mam poświęcić parę(naście) godzin na zapoznawanie się z jakimś tam systemem kontroli wersji?! Git to jednak nie tylko trzęsienie ziemi wywołane na wstępie, ale miarowe budowanie napięcia wraz z poznawaniem kolejnych możliwości tego cudownego narzędzia.

Wyobraźmy sobie błogą sytuację radosnego dłubania nad jakimś nowym-wspaniałym-pomysłem, który sprawi, ze nasz serwis zacznie zarabiać. Nagle jednak dostajemy telefon od wściekłego szefa, że zobaczył jakieś dupy na stronie (tzw. debug mode). Oprócz skoku przez okno mamy do wyboru kilka możliwości posprzątania po sobie, ale tak, by nowe zmiany, rozgrzebane i niedokończone, nie poszły live. Niestety, nie możemy ot tak zmienić gałęzi na główną i od niej odbić na tworzenie poprawek – git nie pozwala zmienić gałęzi, w której powstały jakieś nie zatwierdzone zmiany. Co możemy zrobić?

1. Cofnąć wszystko: git reset –hard — ale to głupi pomysł, zwłaszcza, jeśli nad nowymi zmianami pracowaliśmy od dłuższego czasu i niczego jeszcze nie commitnęliśmy.

2. Zrobić po prostu commit: git commit -am “Później dokończę” — ale jak widać nie wygląda to za pięknie.

3. “Ukryć zmiany“: git stash — cudownie genialne w swojej prostocie rozwiązanie. Ukrywać możemy kiedy chcemy, co chcemy, podobnie jak z przywracaniem ukrytych zmian: git stash pop.

Później możemy po prostu utworzyć nową gałąź na bazie głównej: git checkout -b dupa master, wprowadzić poprawki, scalić w głównej gałęzi, wysłać na serwer i wrócić do pracy nad nowym ficzerem.

Inna sytuacja – nawet jeśli uważamy, że jeden commit = jedna zmiana (w ujęciu abstrakcyjnym), to i tak nierzadko zdarza się zapomnieć i ciągiem dokonać zbyt wielu zmian jak na jedno pchnięcie. Jak się później okaże, że część zmian była nietrafiona, to zamiast po prostu wycofać pojedynczy commit, trzeba ubrudzić sobie ręce (i to nie zawsze po sobie), nie mówiąc o tym, że przeglądanie zmian (i szukanie winnych)  jest później karkołomnym zadaniem. I tutaj git potrafi sobie poradzić: git add -i. To proste polecenie pozwala nam przejść w tryb interaktywnego oznaczania zmian jako gotowych do pojedynczego commitnięcia. W ten prosty sposób możemy podzielić dotychczasowe zmiany nie tylko na różne pliki, ale również zdecydować o commitnięciu pojedynczej zmiany w pliku!

Utworzenie nowego projektu? Bułka z masłem. Przy średnio-zaawansowanej konfiguracji wykorzystujemy narzędzie gitosis. Wystarczy w pliku konfiguracyjnym dodać wpis o grupie mającej dostęp do konkretnego projektu, np:

[group nasza-klasa]
writable = sledzik
members = zdzis krzys ptys

… do katalogu z kluczami wrzucić klucze publiczne wymienionych programistów i… już. Od tego momentu serwer będzie wiedział o istnieniu nowego projektu, do którego pełny dostęp mają wymienione osoby. Bardziej skomplikowane konfiguracje (np. z podziałem na ograniczony dostęp do pojedynczych gałęzi) też nie wymaga wygórowanych zdolności i jest dość łatwo dostępne.

O możliwościach Gita można pisać i pisać, czego dowodem choćby wspaniały przewodnik autorstwa społeczności, czy linkowane przeze mnie rozdziały Pro Git. Warto poświęcić tych kilka chwil, żeby którąś z tych lektur poznać od deski do deski. Taka wiedza nie zmarnuje się, wręcz przeciwnie – może tylko przyczynić się do zwiększenia produktywności, usprawnienia porządku w projektach, czy zmiany podejścia niepoprawnych bałaganiarzy.

1. bo innych i tak nie ma [↩]
2. jeszcze masa innych grzechów skutecznie zasila konto klepaczy, ale nie o nich dzisiaj [↩]
3. origin to zwyczajowa nazwa serwera głównego, może być marysia, dev, czy co tam sobei wymyślimy [↩]
4. o pomijaniu branchy żal wspominać [↩]

Dear Google Apps admin,

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser.  We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience.  We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

I myśmy poszli i to czynili. Bo to było dobre.

Nie wiem jak wy, ale ja kocham sesję. Mam nawet dla tego okresu specjalną nazwę – Wielkie Nadrabianie. To kilkanaście godzin mniej na uczelni (plus dojazdy!) oraz co najmniej kilka mniej na pisanie sprawka/laborki/seminarki, czy co tam trzeba akuratnie tworzyć.

Tymczasem można będzie dokończyć Mass Effect (akurat tuż przed premierą dwójki), kilka książek, zaprzyjaźnić się w końcu z Gitem, PyQt/PySide oraz Django. Że o nadrobieniu godzin w pracy nie wspomnę.

I wszystko byłoby pięknie, gdyby nie te zakreślone na czerwono daty w kalendarzu…