Wczoraj miałem zaszczyt przebywać na przyjęciu towarzyskim (łac. bibos) w charakterze alterimprezowicza, jako że w tym samym czasie w tym samym miejscu odbywało się inne party (mechanika kwantowa się kłania). Gości z tej drugiej imprezy nie znałem, a byli nieco młodsi - mediana wynosiła 17 lat. Zachowywali się dość chaotycznie i przejawiali wszelkie cechy dobrze wytrenowanego kamikaze.

Zdenerwowałem się nieco, kiedy odkryłem, że ktoś majstrował przy moim plecaku. Szybka procedura sprawdzania spójności środowiska - portfel jest, zawartość się zgadza; notebook jest; segregator z płytami nie zginął; telefon mam zawsze przy pasku. Po co więc dłubać w cudzym plecaku? Okazało się, że ktoś zabrał kilka tabletek Ibupromu (ślad - brakująca wata w słoiczku). Drugie znalezisko rozbawiło mnie jednak dalece mocniej.

Zginęła jedna prezerwatywa. :D

Patrzę dziś z łezką w oku na kod, który napisałem w Pascalu na początku 1998. roku (czyli gdzieś w pierwszej klasie ogólniaka):

procedure putpixel(x,y:word;color:word); assembler;
asm
  mov cx,640*2
  mov bx,x
  cmp bx,639
  ja @noput
  mov ax,y
  cmp ax,479
  ja @noput
  add ax,topscreeny
  mul cx
  shl bx,1
  add ax,bx
  adc dx,0
  mov si,ax
  cmp dl,curbank
  je @bankok
  call dword ptr bankswitch
  mov curbank,dl
@bankok:
  push $a000
  pop es
  mov ax,color
  mov es:[si],ax
@noput:
end;

I śmiać mi się chce, kiedy w oknie obok widzę kod, który dziś mam po kimś poprawiać:

for ($i = 0, $j = 0; ; )
{
	$tab[$i++] = $title[$j];
	$tab[$i++] = $content[$j++];
	if ($j >= $limit)
		break;
}

Nie wiedziałem, że czas procesora jest aż tak cenny w zagnieżdżanych językach skryptowych. Pół biedy z tym, ale widziałem już takie krzaki na ekranie, że sam autor by mi dziś nie powiedział, co kod robi bez pomocy debugowania.

No nie mogę. Ex aequo dzisiejszą nagrodę otrzymuje również zespół dinfo.pl. Jako ich partner, jesteśmy zmuszeni do korzystania z ich API do wykonywania wszelkich operacji na domenach. Właśnie wpisałem o-umlaut do formularza wyszukiwania domen i system zmarł z komunikatem zły assert. Szukałem błędu po swojej stronie, ale ich serwis okazywał się reagować tak samo. Zajrzałem przeto w otchłań bezdenną i wydobyłem z jej czeluści kod ichniej implementacji punycode, czyli systemu tłumaczenia nazw domen na obowiązujący standard IDN:

function punycode($tryb,$tekst)
{ //tryby: "Encode"/"Decode"
	$iso = array(177,230,234,179,241,243,182,188,191,
	161,198,202,163,209,211,166,172,175);

	$uni = array(261,263,281,322,324,243,347,378,380,260,
	262,280,321,323,211,346,377,379);

	$tekst = iconv('utf-8', 'iso-8859-2', $tekst);

	$print_ascii ="\n\n\n\n\n\n\n\n\n\n\n\n\n\n".
	"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n !\"".
	"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJK".
	"LMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrs"
	"tuvwxyz{|}~\n";

	$domenatab=explode(".",$tekst);
	//podzial domeny na tablice(rozdzial z kropek)

	if ($tryb=="Encode") {
		$output="";
		for ($l=0;$l<count($domenatab);$l++){
		//licznik slow miedzy kropkami
			$tekstuni=array();
			$tekst=$domenatab[$l];
			$polskieznaczki=false;
			for ($i=0;$i<strlen($tekst);$i++) {
				$znaleziony=0;
				for ($j=0;$j<count($iso);$j++) {
					if (ord($tekst[$i])==$iso[$j])  {
						$tekstuni[$i]=$uni[$j];
						$znaleziony=1;
						$polskieznaczki=true;
						break;
					}
				}
				if ($znaleziony==0) {
					$tekstuni[$i]=ord($tekst[$i]);
				}
			}

			// Encode: //
			if ($polskieznaczki==true) {
				$output .= "xn--".
				$this->punycode_encode(count($tekstuni), $tekstuni);
			} else {
				$output.=$domenatab[$l];
			}
			if ($l!=count($domenatab)-1) {
				$output.=".";
			}
		} //for l=0....
		$output_length=strlen($output);

		// Convert to native charset and output: //
		for ($j = 0;  $j < $output_length;  ++$j) {
			$c = ord($output[$j]);
			if ($c >= 0 && $c <= 127 && isset($c)) {
				if (ord($print_ascii[$c]) == 0) {
					echo "invalid_input";
				}
				$output[$j] = $print_ascii[$c];
			} else {
				echo "zly assert (246)";
				exit;
			}
		}
		return str_replace("\r","",$output);
	}
	// [..]
}

Przejrzyściej napisanego kodu nie napisałem, mimo wszystko udało mi się dostrzec, że:

• system potrafi obsługiwać tylko domeny podane w Latin2
• ma na sztywno wpisanych kilka polskich znaków (pierwsze dwie tablice), a inne skrupulatnie olewa
• nie ma nic wspólnego z oryginalnym algorytmem punycode (tej części nie wklejałem), którego implementację w PHP na licencji GPL można wygooglać w 10 sekund
• prześlicznie obsługuje błędy, nie ma to jak zabić skrypt w przypadku wprowadzenia nieobsługiwanych znaków do formularza

Jako, że data już technicznie rzecz biorąc inna, mogę zamieścić kolejny WTF.

Pamiętajcie, środków ostrożności nigdy dość, dlatego ważną rolę pełni security by obscurity.

<?
if ($_COOKIE["login"] != "admin")
	print '<div id="admin" style="display:none;">';
else
	print '<div id="admin">';
?>
	<!-- tutaj linki do usuwania użytkowników -->
</div>

Dzisiejszą nagrodę otrzymuje ode mnie autor poniższego kodu:

if (sizeof($tab) > 0 ? true : false)
{
	// [...] - tutaj kod
}

Autora i źródła nie podam z podziwu dla tak zaawansowanych konstrukcji.

PS: Podobno dzisiaj Windows 95 (Windows Chicago) obchodzi swoje 10. urodziny.

Studenci i hobbyści lubią pisać kod dla samej zabawy pisania kodu. Stąd różnorodność rozwiązań w każdej niemal kategorii oprogramowania. Dzięki temu klony Uniksa są dziś najbardziej elastycznymi systemami. Sytuacja wygląda jednak nieco inaczej w przypadku oprogramowania komercyjnego.

Każdy chce się pochwalić swoimi umiejętnościami i chętnie napisałby wszystko od zera, ale w odróżnieniu od oprogramowania OpenSource, w komercyjnych rozwiązaniach obowiązują terminy, a głównym czynnikiem napędzającym całą zabawę są pieniądze. Ważne nie jest popisanie się, ale efektywne zgospodarowanie czasu, stąd pisanie własnych rzeczy często jest niepożądane.

Zanim zabierzesz się za pisanie własnego modułu, silnika czy jakiegokolwiek elementu oprogramowania, rozejrzyj się po rynku. Sprawdź czy istnieją gotowe rozwiązania, z których mógłbyś skorzystać i zaoszczędzić czas. Jeśli nie uda ci się znaleźć nic, co pasowałoby do twojego projektu, zainteresuj się tymi, które nie pasują. Sprawdź, jaką mają bazę użytkowników, czy znane są jakieś błędy, z jakimi problemami borykają się ci, którzy im zaufali i czy nie żałują swojej decyzji. Zobacz, czy nie da się ich zaadaptować za pomocą minimalnych zmian.

Pisanie własnego systemu powinno być ostatnim podejmowanym krokiem. Jeśli nie znajdziesz nic, co mogłoby ci zaoszczędzić czasu, to zaoszczędź go sobie sam - przeznacz czas na zaplanowanie swoich działań zanim napiszesz choćby linijkę. Zastanów się nad architekturą, porównaj ją z istniejącymi i skorzystaj z poznanej wcześniej listy problemów. Pisanie oprogramowania, które nie będzie się nadawało do wdrożenia mija się z celem, tak samo jak napisanie od zera kolejnego pakietu o identycznej funkcjonalności.

Pamiętaj, że prawdopodobnie nie będziesz jedyną osobą dbającą o ów kod - zaplanuj go rozwojowo i tak, żeby wprowadzanie zmian nie wymagało przepisywania dużych fragmentów kodu. Przygotuj choćby krótką dokumentację - twoi współpracownicy nie będą mieli czasu na czytanie całości kodu za każdym razem, kiedy potrzebują z niego skorzystać. To jest właśnie największa zaleta korzystania z szeroko stosowanych rozwiązań - problemy za ciebie rozwiązują inni. Ty możesz skupić się kodzie funkcjonalnym, a nie na poprawianiu używanych narzędzi i bibliotek.

Reasumując: w pracy codziennej pisze się masę nowego kodu, ale staramy się ograniczać do tego, którego napisanie jest nieodwołalne. Cała reszta to koszty, które dla pracodawcy nie przynoszą żadnego zysku (poza kodem, o który trzeba dbać, co pochłania dalsze ilości czasu, a w efekcie przekłada się znów na pieniądze).

Dzisiaj (zmotywowany przebudzeniem o 17:00 po wczorajszej imprezie) sformułowałem w końcu swoją teorię z dziedziny modelowania zjawisk fizyki cząsteczkowej.

Relokacja Dyfuzyjna (RD) to zjawisko powszechne w przyrodzie. Jego zaistnienie jest nieprzewidywalne, jednak pewne czynniki mogą wpłynąć dodatnio na szansę jego wystąpienia. Kluczową rolę pełni tutaj dostarczenie odpowiedniego kwantu energii w postaci alkoholu etylowego i produktów z grupy wyrobów tytoniowych. Zaistnienie RD możemy stwierdzić dopiero po fakcie, poprzez analizę symptomów. Proces RD charakteryzuje się tym, że ciało ulega rozszczepieniu na pojedyncze cząsteczki. Każda z nich porusza się do celu innym torem, ciężko określić wzór pozwalający dokładnie wyznaczyć trasę poruszania się poszczególnych cząsteczek, wiemy natomiast że ich tory podobne są do tych pokonywanych przez ładunki elektryczne podczas wyładowań atmosferycznych bądź do torów kreślonych przez węże na piasku. Niektóre cząsteczki zdają się wykazywać własności magnetyczne względem krawężnika. Proces ponownej asemblacji materii jest dość długotrwały, co widać szczególnie dobrze na krótkich odcinkach. Te, których pokonanie pieszo zajmuje 20 minut, mogą zająć RD ponad godzinę. Co ciekawe, można w ten sposób pokonać odcinki teoretycznie nie do przejścia na nogach. Zaliczamy do nich: jeziora, rzeki, tereny bagienne, wysoko porośnięte łąki, a także płoty i mury. Druga charakterystyczna, poza nadmiarowym upływem czasu, cecha to wielodrożność poruszających się paralelistycznie cząstek. Stąd często, gdy pytamy kilku osób o trasę, którą wracaliśmy do domu, otrzymujemy kilkanaście sprzecznych wersji. Nazywamy to częściową, nabytą zdolnością bilokacji. Jest ona tylko tymczasowym efektem ubocznym RD i organizm traci tę właściwość po znalezieniu się w łóżku, bądź innym dogodnym do spania miejscu (w tym ławki, trawniki).

Aredridel (PLD Linux) i xentac (Arch Linux) ogłosili niedawno otwarcie dość niecodziennego portalu. Distro Development Talk ma na celu skupienie społeczności związanej z rozwojem różnych dystrybucji. Ta różność jest tu kluczowa, bo serwis nie ma służyć za helpdesk (nie, to nie jest miejsce, gdzie użytkownicy mogą zadawać pytania), ma być platformą do swobodnego mind stormingu. Dzieląc się swoimi opiniami mamy okazję poznać sprawę z punktu widzenia innych dystrybucji, możemy również rozszerzyć swoją wiedzę, czytając o pomysłach i problemach innych. Póki co, serwis jest w powijakach i dopiero zbiera grono uczestników, stąd niska aktywność, dlatego zachęcam do rejestracji. Podkreślam jeszcze raz, że jest to usługa dla deweloperów i zadawanie tam pytań jak zrobić jest kiepskim pomysłem.

Coraz częściej spotykam się z kodem pisanym na szybko przez ludzi mających nikłe pojęcie o swoim podstawowym narzędziu pracy - języku PHP. Kawałki kodu wyglądają tak:

while($row = mysql_fetch_array($result))
{
	print "<tr><td>" . $row['imie'] .
	"</td><td>" . $row['nazwisko'] .
	"</td><td>" . date("d.m.Y", $row['data_urodzenia']) .
	"</td></tr>\n";
}

Kod paskudny i na ogół wyświetlanie wyników zajmuje przynajmniej 3/4 pliku, który odpowiada za ich pobieranie z bazy. Znacznie wygodniej byłoby oddzielić widok od kontrolera i pozwolić temu pierwszemu troszczyć się o formatowanie danych (date(...);), a temu drugiemu zająć się tylko wydobywaniem niezbędnych danych.

Tutaj pojawiają się szablony. Równie kiepskim pomysłem, jak wypluwanie kodu HTML bezpośrednio przez kontroler, jest pisanie własnego silnika szablonowego. Znacznie lepiej stosować powszechnie uznane narzędzia, jak Smarty - system inteligentnych szablonów.

Powyższy przykład przepisany za pomocą Smarty składałby się z dwóch plików. Pierwszy plik, z kontrolerem wyglądałby tak:

$smarty = & new Smarty();
$dataset = array();

while($row = mysql_fetch_assoc($result))
{
	array_push($dataset, $row);
}

$smarty->assign('dataset', $dataset);
$smarty->display('data-template.html');

Drugi zaś, zawierający sam szablon:

<table>
{section name="row" loop=$dataset}
	<tr>
		<td>{$dataset[row].imie}</td>
		<td>{$dataset[row].nazwisko}</td>
		<td>{$dataset[row].data_urodzenia|
		date_format:"%d.%m.%Y"}</td>
	</tr>
{/section}
</table>

Największa zaleta tego podejścia - czytelność i uniezależnienie silnika strony od jej wyglądu.

Druga zaleta - reużywalność raz wykonanych szablonów, załóżmy bowiem, że strona zawiera formularz, który należy wypełnić i który jest następnie walidowany po stronie serwera pod kątem poprawności pól. Co jeśli pola nie są wypełnione poprawnie? Niektóre serwisy wyświetlają błąd i przycisk wstecz - niezbyt elegancka metoda, biorąc pod uwagę, że IE skrupulatnie czyści pola formularza przy wracaniu do strony z historii. Można jednak przygotować jeden formularz:

<form action="/" method="post">
	<fieldset>
		<legend>Dane osobowe</legend>
		<p>Imię:
		<input type="text" name="imie"
		value="{$smarty.post.imie}"></p>
		<p>Nazwisko:
		<input type="text" name="nazwisko"
		value="{$smarty.post.nazwisko}"></p>
		<p>Email:
		<input type="text" name="email"
		value="{$smarty.post.email}"></p>
	</fieldset>
</form>

Następnie wywołać go dwukrotnie - raz przy konieczności jego wypełnienia, drugi raz w funkcji sprawdzającej jego poprawność, jeśli zaistnieje taka potrzeba. Pola pozostaną wypełnione, a użytkownik ograniczy się do poprawienia tylko tych danych, które wprowadzone zostały błędnie.

Trzecia zaleta - system taki pozwala na jednoczesną pracę programistów i webmasterów, szablony można rozwijać równolegle z kodem, co znacznie przyspiesza rozwój serwisu, a czas realizacji jest często kluczowym kryterium przy negocjacjach z klientami.

Urlop to taki okres, kiedy możemy w końcu robić to, na co mamy ochotę.

« poprzedni strip | następny strip »

Bez jakichkolwiek negatywnych emocji i czysto informacyjnie. Skrót PLD rozwija się jako PLD Linux Distribution i jest to akronim rekursywny, podobnie jak RPM czy WINE.

Nie, nie ma tam słowa Polish, choć niektórzy z całą pewnością chcieliby je tam widzieć. PLD Linux wywodzi się faktycznie z Polish(ed) Linux Distribution, które zmarło tragicznie z braku deweloperów w 2002. roku. Resztki projektu można znaleźć jeszcze na stronie pld.org.pl, gdzie do dziś swoje repozytorium i stronę domową ma nasz system zarządzania pakietami, poldek.

PLD Linux Distribution całą swoją działalność (strona domowa, repozytoria kodu, serwery FTP, Jabber, listy dyskusyjne, itp.) prowadzi w domenie pld-linux.org.

Notka sponsorowana przez złośliwość pana Ciupaka. Pozdrawiam serdecznie. Bez urazy.

Ostatnio miałem okazję pobawić się nową zabawką Microsoftu, a zbiegło się to w czasie z opublikowanym dwa dni temu przez Rogera Johanssona artykułem, więc postanowiłem skorzystać z okazji i napisać coś na ten temat.

Nowy IE nie powala. Z widocznych nowości dodane zostały oczywiście (Microsoft twierdzi, że wynalezione przez nich) panele (które ostatnio zostały przemianowane na karty). Paskudne, jak nigdy dotąd, przy włączonym silniku Luna (domyślny temat Windows XP) są zupełnie nie do oglądania, rozsądnie zaczynają wyglądać dopiero w widoku klasycznym. Dodatkowo, ich przełączanie powoduje widoczne odrysowanie strony, co sprawia, że poruszanie się pomiędzy otwartymi panelami trwa dłużej niż pomiędzy osobnymi oknami przeglądarki. Drugą funkcją jest obsługa RSS, która działa podobnie jak znane z Firefoksa Live Bookmarks połączone z dodanym w Deer Parku czytnikiem subskrypcji.

Zmiany w samym silniku renderującym albo nie występują, albo są bardzo dobrze ukryte. Z punktu widzenia obsługi standardów jest to stary, dobry IE 6.0. Należy jednak pamiętać, że jest to dopiero pierwsza publiczna wersja i na oficjalnym blogu (tak przy okazji, czy ktoś już zauważył, jak dziwnie brzmi próba przeczytania tytułu tej strony przez Polaka?) przeglądarki pojawiły się już informacje na temat lepszego wsparcia dla standardów. Stąd też niepokój Rogera, czy szeroka adaptacja nie przyniesie sieci szkody.

Zaznaczam, że nie mówimy tu o okresie kilku dni czy tygodni od premiery. Jak pokazuje w swoich książkach Jakob Nielsen, czas adaptacji nowych technologii wynosi około roku - po tym czasie możemy przyjąć, że do technologii ma dostęp większość internautów. W przypadku tej przeglądarki okres ten zostanie znacznie wydłużony - dostęp do nowej wersji mają tylko użytkownicy dwóch najnowszych systemów z Redmond - Windows XP i Vista, co na wstępie już utrudnia upgrade ludziom, którzy z różnych przyczyn do dziś korzystają ze starszych systemów. Nie zawsze jest to kwestia ingorancji, czasem jest to uwarunkowane polityką firmy bądź samymi kosztami.

Co więc może przynieść nowa wersja? Cieszymy się (jako webdeveloperzy) na lepsze wsparcie dla standardów. Co jednak z dotychczas stosowanymi obejściami i sztuczkami, mającymi na celu wymuszenie prawidłowego wyświetlania serwisów w starszych braciach siódemki? Wystarczy, że choćby jeden ze stosowanych dotąd hacków będzie nadal działał, a setki czy tysiące stron zaczną cierpieć na nagłą dysfunkcję. Z drugiej strony, poleganie na hackach to branie na siebie odpowiedzialności za ich działanie - nieudokumentowane funkcje mają tendencję do znikania.

Lepsze bezpieczeństwo (przeglądarka po starcie pozbywa się systemowych przywilejów i działa w ograniczonym środowisku użytkownika na kształt znanego z Uniksów chroota) to najgłośniejsze z haseł promowanych przez Gatesa i Ballmera, ale czym jest zabezpieczanie przeglądarki, kiedy ostatnimi czasy głównym źródłem wirusów jest poczta elektroniczna, a MS dawno temu już zarzucił rozwój swojego domowego klienta poczty - Outlook Express, który nadal jest w naszym kraju najpopularniejszym programem tego typu (mimo jego setki błędów i braków).

Najgorsze, czego możemy się spodziewać, to powtórzenie sytuacji z aktualną wersją szóstą przeglądarki, która od pięciu lat jest tylko zapobiegawczo łatana. Szum generowany wokół najnowszej wersji i sam fakt wypuszczenia jej także dla Windows XP, choć początkowo miała być dostępna tylko dla Visty mogą wskazywać na to, że marketingowcy ze stajni MS liczą na jednorazowe uderzenie i odbicie straconego rynku konkurencji, czyli przeglądarce Mozilli.

Jeśli ich działania spełzną na niczym (a tak się zapewne stanie, w końcu nowa przeglądarka pod żadnym względem nie przewyższa Firefoksa), rozwój IE może ponownie zostać zawieszony bądź też zupełnie przerwany, jak miało to miejsce w przypadku Internet Explorera dla komputerów Apple. Grozi nam wtedy kolejny zastój technologiczny, jednak czy nie jest on lepszy od stanu obecnego?

Dziś, drodzy zgromadzeni, profesor Pimpin pokaże wam, jak ważne jest rozdzielenie wyglądu i treści.

Profesor Pimpin przy pracy.

Jako, że od pewnego czasu mój pracodawca zleca cięcie części projektów webmasterom zewnętrznym (outsourcing jest jazzy), oszczędza nam to dużo czasu, który możemy poświęcić na programowanie silników PHP... albo na ponowne cięcie wyżej wspomnianych projektów.

Problem z outsourcingiem polega na tym, że wszyscy zarzekają się, że są istnymi geniuszami, a ich praca warta jest każdych pieniędzy. Dziesiątki, ba - nawet setki, lat w braży, tysiące projektów na karku, pełen profesjonalizm. Rzeczywiście, ostatnio dostałem do ręki projekt wykonany z pozoru bez zarzutu. Szybki rzut okiem do kodu źródłowego ujawnił tylko kilka usterek, ale szablony zostały przygotowane zgodnie z XHTML 1.1 i bez użycia tabel.

Później jednak zainteresował mnie jeden z formularzy, gdzie przycisk wysyłający dane niebezpiecznie nachodził na dolną krawędź fieldsetu. Nic to, pomyślałem, i zająłem się swoją pracą, czyli powoływaniem owego cuda do życia. Mniej-więcej w połowie podłączania szablonów do swojego systemu CMS zapragnąłem zmodyfikować podpis wspomnianego formularza, gdyż do granic eksploatowane przez nas lorem ipsum zdawało się niewiele mówić przeciętnemu odwiedzającemu serwis. Podmieniłem przeto tekst na nieco inny i w tym miejscu szczęki moje rozwarły się by tak pozostać na czas dłuższy. Tekst, owszem, wydłużył się, jednak ostatnie pola formularza znalazły się już daleko za nim, nie wspominając o przycisku, który już wcześniej leżał na dolnej krawędzi. Obecnie przebywał prawdopodobnie około 200 pikseli niżej, niestety nie mogłem tego zweryfikować, gdyż wylewająca się treść formularza była skrupulatnie przykrywana przez inny boks na stronie.

Webmaster tnąc szablony sugerował się projektem i konkretnymi tekstami zastępczymi, jakie zostały tam umieszczone. Cały boks formularza był tak naprawdę namalowany na jego tle, więc wydłużenie jego zawartości spowodowało wylanie się treści poza widoczne pod spodem ramki. Myślenie o designie w kontekście konkretnej treści jest jednym z największych błędów popełnianych przez niespecjalnie doświadczonych webmasterów. Robienie stron na własne potrzeby nie wymaga specjalnej elastyczności - gorzej, kiedy klient postanowi zastąpić proponowane treści własnymi. W końcu to jego serwis i po to właśnie kupił od nas system zarządzania treścią.

Drugi problem dotyczący wspomnianego serwisu to skrypty JS i ich przywiązanie do szablonu. Odpowiedzialne są one za podświetlanie przycisków i podpowiedzi w formularzach. Wszystko działało bez zarzutu do czasu, kiedy zostaliśmy zmuszeni dodać na jednej z podstron kolejny formularz i kiedy to okazało się, że jest to dość trudne. Skrypty, co prawda, znajdowały się w zewnętrzym pliku, ale uparcie wyszukiwały w nim konkretne przyciski i konkretne pola formularzy. Wymusiłoby to na nas dopisywanie obsługi każdego formularza, każdego jego pola i wszystkich nowych przycisków do pliku ze skryptami. W końcu zdecydowałem się zrezygnować z zaproponowanego przez autora rozwiązania (co było samo w sobie dość problematyczne ze względu na bliskie powiązanie ich z funkcjonalnością serwisu) i skorzystać ze sprawdzonych wielokrotnie skryptów własnego autorstwa, o których pisałem w lipcu.

Podsumowując - czas oszczędzony na traktowaniu layoutu dosłownie (z dokładnością do piksela) to czas, który trzeba - prędzej czy później - z nawiązką włożyć w ponowne przeprojektowanie szablonu, kiedy treść przestanie spełniać jego oczekiwania (choć powinno być odwrotnie, to szablon powinien być dla treści, a nie treść dla szablonu).

Na koniec drobna dygresja - bardzo kiepskim pomysłem jest tworzenie graficznych przycisków formularzy poprzez wymuszenie pustego napisu na przycisku i zastąpienie jego tła obrazkiem. Kiedy - podczas testów wspomnianych szablonów - na próbę zablokowałem arkusze CSS, moim oczom ukazały się niewiele mówiące szare kwadraciki. Nie muszę chyba pisać, że nie budziły skojarzeń ze słowami typu przelicz czy wyślij. Czasem pomysłowość w stosowaniu CSS mnie przeraża, zwłaszcza że istnieje <input type="image" />...

Jako, że z pracodawcą rozliczamy się na podstawie przepracowanych godzin, potrzebny jest nam niezawodny system śledzenia czasu pracy. Kiedy zatrudniłem się tam pierwszego września ubiegłego roku, w użyciu był prosty system webowy, napisany kiedyś na potrzeby firmy przez programistę, Roya. Świetnie spełniał swoje zadanie, a przynajmniej tak nam się wydawało.

Funkcjonalność systemu sprowadzała się do trzech zadań - zbierał informację o godzinie przyjścia i wyjścia pracownika, o jego przerwach (np. bezpłatnych wyjściach na papierosa czy do sklepu), a na koniec dnia zapisywał podane przez pracownika krótkie podsumowanie dnia i plany na dzień kolejny. Całość sprzężona została oczywiście z kalendarzami pracowników, stąd system potrafił odróżnić dni pracujące od wolnych, śledził wykorzystanie urlopu i dawał nieograniczony dostęp do czytania własnej historii.

Przyszedł czas zmian...

Z nieznanych nam przyczyn odcięto nam dostęp do naszej historii, stąd niemożliwe stało się ustalenie, co robiliśmy tydzień temu, kiedy dokładnie pracowaliśmy nad danym projektem, ile dni urlopu wykorzystaliśmy, ani - co najzabawniejsze - jakie są nasze plany na dzisiaj. Zamiast tego zaproponowano nam dostęp do zbiorczych danych dla 3 ostatnich miesięcy (łączna liczba przepracowanych godzin w miesiącu bieżącym i dwóch poprzednich). Z mieszanymi uczuciami, przyzwyczailiśmy się jednak do nowych features.

Przyszedł czas zmian...

Do systemu dodano możliwość podglądania własnych planów na dziś (czyli tego, co wczoraj wpisaliśmy na koniec dnia). Dla dalszego ułatwienia pracy, raporty dzienne przekształciły się w raporty zadaniowe. Zamiast jednego raportu na koniec dnia, od tego momentu byliśmy zmuszeni pisać raport po każdym zamkniętym zadaniu. Uciążliwość była o tyle do przebolenia, że wydawała się niczym w porównaniu z dodatkowym pomysłem - do projektów wprowadzono papierowe karty, gdzie każdy zmuszony był do wypisania wszystkich plików, nad którymi pracował oraz podpisania się pod odpowiedzialnością za ich działanie we wszystkich możliwych przeglądarkach, rozdzielczościach i walidatorach.

Wypełnianie takiego arkusza na bieżąco nie miało sensu, bo mając otwartych 20 plików na raz ciężko stwierdzić, kiedy się skończyło pracę nad jednym z nich - jeśli jego funkcja zazębiała się z którymkolwiek z pozostałych plików, istniały duże szanse jego dalszego przerabiania później. Matriksy, jak młodzieżowo nazwaliśmy nowe obiegówki, zmuszały człowieka do zapisania kartki formatu A4 drobnym maczkiem, a ich wypełnienie wywoływało trwały ból nadgarstka, który towarzyszył nam aż do wieczora. Czysta biurokracja, ale można się było do tego przyzwyczaić.

Na tym etapie też do SĘPa dodano nowość, niespotykaną dotąd nawet we wdrożeniach enterprise'owych. System stał się niczym Chronos, władca czasu - punktualnie o 17:45 zamraża czas. Nigdy więcej spóźnień na randki czy do kina, niezależnie jak długo pracujesz po godzinach, zawsze wyjdziesz o 17:45! Usługa ta, jak mniemam, powstała celem redukcji moich zarobków, gdyż z biura zwykłem wychodzić po osiemnastej. Cóż, czego nie zarobi się w firmie, dorobić trzeba prywatnie, więc możnaby się przyzwyczaić, gdyby nie jedno wydarzenie.

Przyszedł czas zmian...

Papier popadł w niełaskę, być może modna zrobiła się ekologia, a może nikt nie umiał przeczytać milimetrowych hieroglifów - koniec końców, zaoszczędzimy na długopisach. Zamiast tego w systemie raportów cząstkowych pojawiła się lista rozwijalna z opcjami odpowiadającymi aktywnym projektom i ich podzadaniom. Spore ułatwienie dla załogi, choć i tak nic w porównianiu z rajem stanu początkowego. Na przywrócenie status quo szans nie było, więc...

Przyszedł czas zmian...

Raporty po zakończeniu poszczególnych zadań zostały ostatnio zastąpione raportami poprzedzającymi te zadania. Najbardziej wygodę tego rozwiązania docenił Jarv, nasz grafik - jego raporty wymagają bowiem załączania plików z wynikami pracy, co jest nieco uciążliwe przy pisaniu raportu przed wykonaniem faktycznej pracy. Od teraz zamiast jednego kroku, zupełnie za darmo, zyskał dostęp do dwóch. Jestem pewien, że nie może pozbierać się ze szczęścia. Tymczasem słychać już o planach dodania usługi planowany czas wykonywania zadania, co z pewnością wydatnie zwiększy naszą wydajność.

Po co przytaczam tę historię, można spytać? Po to, aby pokazać, jak przekombinowanie przy zarządzaniu projektem może przynieść skutki zupełnie odwrotne do zamierzonych. Ostatnia zmiana w systemie pojawiła się już po odejściu naszego poprzedniego project managera, Lukiego, który obecnie przebywa na emigracji w Anglii, gdzie za ciężko wypracowaną dziesięciokrotność naszych rocznych pensji stara się związać koniec z końcem ;). Widać wyraźnie, że szefowie próbują stworzyć system, który potrafiłby zastąpić zarządcę projektów, gdyby jednak było to możliwe, PM-i nie byliby jednymi z najlepiej opłacanych członków grup programistycznych. Praca bez osoby odpowiedzialnej za organizację jest utrudniona przez specyfikę naszej pracy, gdzie dwóch szefów ma rozbieżne oczekiwania odnośnie zagospodarowania czasu pracy, a zjawiska typu PZP, PZPIZP, czy nawet PZPIPZPZP są codziennością.

Wnioski są proste - próba poprawiania wydajności na siłę generuje zbędną biurokrację, co z kolei niejako wymusza niezamierzony strajk włoski. Pracę w takich warunkach można porównać do wydajności programu działającego pod kontrolą profilera, czy programu śledzącego - człowiek stale rozliczający się z każdej niemal minuty dnia nie jest w stanie zrobić nic w rozsądnym czasie, zwłaszcza kiedy przydział czasu na zadania nie jest ciągły, a rozdzielany pomiędzy kilka(naście) naprzemiennie kontynuowanych zadań.

Co do pisania samych raportów i planowania czasu - to właśnie jest praca dla managera i żaden program go nie zastąpi, nawet przy dużym wkładzie dobrej woli ze strony zespołu. Pomyślcie o tym, jeśli znajdziecie się w podobnej sytuacji.