Chciałbym zwrócić uwagę na nieco inną możliwość – mianowicie generator formularzy bazujący na silniku baz danych. Koncepcja znana i zdominowana dotychczas przez narzędzie Oracle Forms znalazła swoich zwolenników w świecie Open Source.

W efekcie czego najlepszy projekt relacyjnej bazy danych open source – PostgreSQL doczekał się narzędzia, które raczej przesadnie można nazwać odpowiednikiem Oracle Forms dla PostgreSQL. Mowa tu o projekcie Postgres Forms (http://pgfoundry.org/projects/pfm) powstałym w 2006 roku i od tego czasu rozwijanym, a ostatnio została wypuszczona wersja 2.0.3 o której kilka słów więcej.

Postgres Forms raczej nie przytłacza ogromem funkcji, a interfejs użytkownika raczej nie słyszał o ergonomii, w takim razie po co to? Myślę, iż jest to dobra ciekawostka, i w takim kontekście będę to traktował, choć wydaje mi się, iż znajdzie się i praktyczne, być może i produkcyjne zastosowanie dla tego produktu.

Po zainstalowaniu i uruchomieniu aplikacji za wiele nie zobaczymy:

Za to zobaczymy bardzo dużo… komunikatów błędu przy próbie zaimportowania przykładowego schematu, o ile nie mamy klienta psql w ścieżce plików wykonywalnych, lub wcześniej nie skonfigurujemy aplikacji.

Po zaimportowaniu przykładowego schematu (mamy dwa do wyboru: bazę klientów lub książkę adresową) możemy zacząć wykorzystywać możliwości pfm. Oczywiście możemy stworzyć własny projekt, co sprowadza się do zaimportowania podstawowego schematu w który będą przechowane definicje formularzy, relacji i atrybutów.

Aplikacja pozwala na tworzenie formularzy powiązanych, jak również definiowanie sposobu wprowadzania wartości dla poszczególnych pól, czy to przy wykorzystaniu combobox, czy zewnętrznego formularza wyboru.

Postgres Froms pozwala również na raportowanie wykorzystywanych struktur oraz relacji między nimi:

Małe uzupełnienie w formie rozluźnienia:
http://www.joemonster.org/art/9374/Jak-napisac-dobre-sprawozdanie-z-trudnego-projektu

Na koniec jeszcze kilka zrzutów:

http://subversion.tigris.org/

http://tortoisesvn.net/

Na początek Google Maps (http://maps.google.com), wpisuje: Warszawa, Skarbka z Gór i co, troszkę się dziwie:

Dostaje śliczną wyznaczoną trasę do Warszawy z oddalonej o 34 km miejscowości Góra, no cóż pomylić się wolno, po kilku próbach z cudzysłowiem, z różnymi wariantami zapytania udaję się odnaleźć właściwą ulicę – dla zainteresowanych należy pytać o ulice Skarbka. Problem wynika z mechanizmem wyszukiwania który literkę z tłumaczy na angielskie from, dzięki czemu zapytanie zostaje rozpoznane jako Skarbka from Gór co powoduje rozpoczęcie procesu wyszukiwania trasy. Wprawdzie nie sprawdzałem jak się zachowa aplikacja jeśli zostanie odnalezionych więcej pasujących miejscowości, ale prawdopodobnie spyta o którą chodzi.

Z ciekawości postanowiłem zapytać konkurenta o ulice Skarbka z Gór w Warszawie (http://maps.yahoo.com) i tutaj wynik zdecydowanie bardziej odpowiada moim gustom, ale jako że mapy Yahoo nie przemawiają do mnie po polsku, wobec czego dostosowuję się do nich, i pytam: Poland, Warsaw, Skarbka z Gor, na efekt nie długo czekałem:

I gdyby była to tylko prawda…, znów dla niewtajemniczonych, prezentowany fragment mapy znajduje się ok. 50 km od mojej rodzinnej strony w najpiękniejszej części Polski – Bieszczadach.

Jak się po chwili okazało błąd bym po mojej stronie, bowiem jak każdy polak nie czytam instrukcji, co można zauważyć na powyższym screenie – adres podawany jest w kolejności, odwrotnej od wprowadzonej, po zmianie kolejności na prawidłową wyniki były również prawidłowe.

W tym celu wybrałem następujące pięć testów:

• binary-trees – operacje na drzewkach binarnych
• n-body – bliżej nie określone “coś”
• recursive – rekurencyjne liczenie wartości ciągu fibonacciego, funkcji Ackemanna oraz funkcji Tak
• startup – wyświetlanie hello world
• sum-file – sumowanie 10 000 liczb wpisanych na stdin

Do testów wykorzystany został laptop Dell Latitude D630C z procesorem Intel Core 2 Duo 2.2GHz z 4GB RAM. Jako system operacyjny zostało wykorzystane Gentoo 2008.0_beta z LiveDVD (Linux livecd 2.6.24-gentoo-r5 #1 SMP Wed Apr 23 22:46:44 UTC 2008 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux). Do kompilacji zostało wykorzystane GCC w wersji x.x (jak sprawdzę to napiszę). Kompilacja przebiegała z domyślnym zestawem parametrów, w sposób maksymalnie prosty:

./configure –without-pear –prefix=/root/phps/php-x.x
make
make install

Kompilacji zostały poddane najnowsze wersje kodu źródłowego pobranego z http://snaps.php.net (za wyjątkiem PHP4, którego rozwój został zaprzestany), i są to:

• php5.2-200806211230
• php5.3-200806211230
• php6.0-200806211230
• php-4.4.8

Poniżej znajdują się wyniki pomiarów czasu poszczególnych etapów dla każdej z wersji PHP (czas podany w sekundach):

W wyniku kompilacji otrzymałem:

livecd bin # /root/phps/php4.4.8/bin/php -v
PHP 4.4.8 (cgi) (built: Jun 21 2008 17:46:03)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

livecd bin # livecd bin # /root/phps/php5.2-dev/bin//php –v
PHP 5.2.7-dev (cli) (built: Jun 21 2008 17:56:40)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

livecd bin # livecd bin # /root/phps/php5.3-dev/bin/php -v
PHP 5.3.0-dev (cli) (built: Jun 21 2008 18:03:34)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies

livecd bin # livecd bin # /root/phps/php6.0-dev/bin/php -v
PHP 6.0.0-dev (cli) (built: Jun 21 2008 20:39:02)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2008 Zend Technologies

Test polegał na wykonaniu odpowiednio:

• wywołaniu skryptu binarytrees.php z parametrami o wartości od 1 do 15 oraz zmierzeniu całkowitego czasu wykonania
• wywołaniu skryptu n-body.php 1000 razy z parametrem równym 100 oraz zmierzeniu całkowitego czasu wykonania
• wywołaniu skryptu startup.php oraz zmierzeniu całkowitego czasu wykonania
• wywołanie skryptu sum-file.php 1000 razy wraz z przekazaniem na stdin 10 000 liczby oraz zmierzeniu całkowitego czasu wykonania
• wywołanie skryptu recursive.php z parametrami o wartości od 1 do 8 oraz zmierzeniu całkowitego czasu wykonania

Poniżej zostały zaprezentowane wyniki poszczególnych wywołań

Wyniki testu nie zaskoczyły mnie specjalnie, PHP4 wbrew powszechnemu, często jeszcze spotykanego mitu wcale nie jest dużo szybsze od PHP5, a nawet jak się okazuje jest o wiele wolniejsze.

Zgodnie z oczekiwaniami wraz z rozwojem PHP znacznie wzrasta czas startu interpretera, co jednak ma znaczenie tylko i wyłącznie w przypadku wykorzystywania PHP w trybie CLI lub CGI. Na szczęście oba te przypadki można zignorować, bowiem tryb CLI nie służy do bezpośredniej obsługi tysięcy jednoczesnych zapytań, natomiast CGI ustępuje pola Fast-CGI, dla którego czas startu interpretera nie odgrywa tak istotnej roli.

Zdziwiło mnie natomiast zachowanie PHP6 w przypadku funkcji rekurencyjnych, w przypadku których jego wydajność była znacznie poniżej oczekiwań.

Oczywiście do premiery PHP6 jeszcze sporo czasu, i pozostaje mieć nadzieje, iż zostanie to poprawione.

Cel nie lada, a jego osiągnięcie może wymagać radykalnych środków, wygląda na to, iż Mozilla Fundation postawiła wszystko na to aby zapewnić ku temu odpowiednie warunki, jednak jak można się dziś przekonać nie jest to takie proste – kilka godzin po udostępnieniu do pobrania najnowszej wersji przeglądarki strona http://firefox.com odpowiada z kilkunasto sekundowym opóźnieniem, a serwisy wspierające takie jak http://addons.mozilla.org praktycznie przestały odpowiadać – prawdopodobnie w wyniku przeciążenia spowodowanego sprawdzaniem i pobieraniem nowych wersji pluginów któro ma miejsce bezpośrednio po instalacji nowej przeglądarki.

Odkładanie składek na Otwarte Fundusze Emerytalne jest obowiązkowe - potwierdził w środę Sąd Najwyższy, uznając, że składki takie nie są prywatną własnością obywatela.

Ja tylko spytam - w takim razie czyją ?

Źródło: http://wiadomosci.onet.pl/1762065,10,1,1,,item.html

Kilka chwil później  po upgrade klienta postanowiłem przekonać się jak wygląda praca na nowej wersji.

Jak się można przekonać zmiany tylko na dobre (jak na chwile obecną):

1. Pierwsze co się rzuca w oczy to nowe ikonki - może mało funkcjonalne, ale bardzo widoczne:
2. Rzut okiem na przeglądarkę repozytorium, zmieniona niemal zupełnie - upodobniona do windowsowego eksploratora plików:
   
3. Nowy revision graph
4. Checkout - okno zostało rozbudowane o dodatkowe opcje umożliwiające między innymi określenie zakresu plików które powinny zostać pobrane z repozytorium
   
5. Nowy merge - chyba najbardziej istotna zmiana, z prostej formatki powstał kreator znacznie uproszczający cały proces - wystarczy wybrać schemat działania i wskazać odpowiednie zasoby. Reszty dokona za nas zółwik i to nie w zółwim tepie - a to dzięki opisanemu wcześniej mechanizmowi śledzenia “merge tracking”.
   Oprócz nowego kreatora w trakcie łączenia zmian mamy dodatkowe opcje co do samego sposobu dokonania połączenia - w tym szczególnie przydatne opcje związane z obsługą białych znaków takich jak znaki tabulacji, spacji i nowej linii.
   Bardzo interesująo wygląda również obsługa interaktywnego rozwiązywania konflików - które można obsłużyć już w trakcie wykonywania operacji łączenia:
   
6. Widok wygenerowanego przez żółwika changelog’a:
   
7. Na koniec jeszcze widok drobnych zmian wizualnych - każde okno wykonywania opcji posiada graficzną reprezentację zadania które jest w nim przeprowadzana
   

Więcej informacji pod adresem: http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html

Wprawdzie zarówno samo Subversion jak i TortoiseSVN nie są jeszcze oficjalnie opublikowane niemniej jednak sądząc po przygotowanych stronach dzień premiery zbliża się dużymi krokami.

Update:
Wygląda na to, iż nie została jeszcze zaimplementowana obsługa svn:external z relatywną ścieżką do zasobów:

Update 2:

Wersje RC można pobrać z adresu: http://sourceforge.net/project/showfiles.php?group_id=138498

O co tutaj właściwie chodzi - jak zapewne wiecie, a część z Was miała okazję się przekonać praca przy dużym projekcie programistycznym bez wykorzystania repozytorium kodu jest praktycznie niemożliwa, a dodatkowo praca w oparciu o blokowanie zasobów jest delikatnie mówiąć niewygodna. Dlatego też zalecaną metodą pracy w takiej sytuacji jest wykorzystanie gałęzi (branches) i okresowe łączenie zmian (merge).

Brzmi nieźle, ale na tym się kończy przyjemność, a zaczynają się trudności - wszystko za sprawą różnych szkół łączenia zmian i różnych określeń dla tych samych parametrów - efekt: nauczenie nowego programisty czym jest from, to i target wcale nie jest takie proste, a gdy do tego dołożymy “Suchy przebieg” zaczynamy wątpić w sensowność zadania. I tutaj znajduje zastosowanie w/w mechanizm śledzenia łączenia, którego zadaniem jest między innymi śledzenie tego co zostało już połączone i automatyczne naniesienie zmian które nie zostały jeszcze na niesione, dzięki czemu merge sprowadza się do:


$ cd KOPIA_ROBOCZA$ svn merge URL_DO_TRUNK

Dodatkowo dostępne są dwie nowe opcje:

• --record-only - oznaczenie rewizji jako połączona bez wprowadzania zmian
• --reintegrate - wykorzystywane przy mergowaniu ponownym na trunk - opcja ta ma na celu wykonanie dodatkowych sprawdzeń poprawności nanoszonych zmian

Dzięki tym zmianą stosowanie gałęzi rozwojowych w ramach projektu nie powinno już stanowić problemu nawet dla niedoświadczonego użytkownika repozytorium.

Uproszczone łączenie zmian to nie jedyna z nowości warta zauważenia w nowej wersji svn, do równie ciekawych opcji możemy zaliczyć:

• wsparcie w automatycznym generowaniu changelog’a
• możliwość pobrania z repozytorium tylko interesujących fragmentów drzewa ścieżek
• interaktywne rozwiązywanie konfliktów z powłoki systemowej z wykorzystaniem klienta svn
• wsparcie dla relatywnych adresów URL w svn:external

Dla zainteresowanych więcej informacji dostępnych jest pod adresem: http://subversion.tigris.org/svn_1.5_releasenotes.html

Jestem bezpośrednio po lekturze artykułu z Harvard Business Review (numer Styczeń – Luty 1997) autorstwa Ronalda A. Heifetz i Donalda L. Laurie i okazuje się, iż problem ten jest powszechny i dotyczy praktycznie każdego sektora gospodarki. Jak można przeczytać w artykule:

“Wielu pracowników ma ambiwalentny stosunek do tego wysiłku i do wyrzeczeń, jakich się od nich wymaga. Często oczekują, że wyższa kadra kierownicza zdejmie większość problemów z ich barków.”

Jednak tutaj chciałbym poruszyć typowo polski moim zdaniem stosunek do pracy, który nie dotyczy tylko i wyłącznie kadry kierowniczej, a wręcz jest spotykany na wszystkich szczeblach kariery zawodowej, myślę iż każdy zrozumie co mam namyśli gdy przytoczę pewną sytuację jakiej byłem świadkiem:

Jakiś czas temu u znajomego w biurze była “awaria okien”, a jako że jest zima naturalnym efektem tego był niekoniecznie korzystnych handel wymienny powietrzem z środowiskiem zewnętrznym. Awaria została zgłoszona do zarządcy budynku, niestety bezskutecznie, dopiero podczas mojej wizyty, po ponownym zgłoszeniu problemu pojawił się miły pan w którym pokładano nadzieję rozwiązania problemu. Nasze zdziwienie może chyba najlepiej przedstawić zdaniem, które usłyszeliśmy: “Przyjdzie Pan zobaczy…”. I kolejne oczekiwanie - tym razem na szczęście zakończone rozwiązaniem problemu.

Opis celowo zmodyfikowany
w celu uniknięcia urażenia osób,
których się dotyczył.

Niby, nic strasznego - jednak dobrze obrazuje pewne zaszłości spotykane wciąż m.in.:
• zgłaszanie, ponawianie próśb - oczekiwanie na swojego rodzaju nabranie mocy urzędowej przez zgłoszenie
• całą procedurę oceny zgłoszenia, najpierw majster, później fachowcy i dopiero naprawa
• przekonanie o wyższości i władzy osoby której pomoc jest potrzebna

A to w obecnych czasach jest co najmniej dziwne, że tak prosta sprawa jak dokręcenie śrubek czy uszczelnienie szyby wymaga pełnej procedury trwającej blisko tydzień. Aż strach pomyśleć, ile może trwać tak skomplikowana czynność jak wymiana żarówki (skąd inąd wiem, że klasuje się w ramach tej samej procedury trwającej około tygodnia).

Nie chodzi mi już o sam czas wymagany na wykonanie pracy - ale o stosunek do nie, który niestety w Polsce nie jest na najwyższym poziomie - wciąż aktualne wydaje się powiedzenie: “Czy się stoi, czy się leży …. się należy”. Smutne, ale prawdziwe - podejście takie jest spotykane niemal na każdym kroku - ile jeszcze trzeba będzie czekać, aż ludzie sami zrozumieją, iż podejście takie nie prowadzi do niczego jest jedynie sposobem na wegetację.

Czy tak trudno jest zrozumieć, iż w obecnych czasach, kondycja przedsiębiorstwa przekłada się bezpośrednio na nas samych? Przecież już teraz prowizje od dochodów firmy przeznaczane na premie pracowników nie są rzadkością.
Ale to jeszcze nie wszystko - jak długo jeszcze pracownicy jednej firmy będą zachowywać się jak konkurenci, a nie gracze jednej drużyny?

Co ciekawe, ostatnimi czasy na polskim rynku można zaobserwować umacniające się przekonanie, iż to firma jest dla pracownika, a nie odwrotnie – niebyło by to nic złego, a nawet przejawem zmian poglądowych idących w dobrym kierunku, gdyby nie to, iż pogląd ten jest wypaczany i dostosowywany do własnych potrzeb i korzyści w efekcie czego stosunek pracodawca - pracownik sprowadza się do sytuacji, w której pracownik oczekuje wszystkiego jako jego prawa, a pracodawcy ? - co łaska. Sytuacja ta umacnia się na polskim rynku pracy wraz ze wzrostem emigracji, i kurczeniem się zasobów potencjalnych pracowników.

Podsumowując - jak długo przyjdzie nam czekać na zmianę mentalności ludzkiej, kiedy standardem stanie sie dostawanie tego o co się prosi, bez ponawiania swoich próśb w nieskończoność i zbędnej biurokracji. Kiedy zaczniemy wymagać czegoś od siebie samych, a nie tylko od ludzi otaczających nas?

Jednym z głównych problemów związanych z wprowadzeniem Unicode dla PHP jest poprawne rozpoznanie kodowania znaków przychodzącego żądania. Sposobów na to jest przynajmniej kilka, jednak niestety żaden nie jest w 100% pewny, i nie można na nim polegać. Co za tym idzie twórcy PHP stanęli przed wyzwaniem stworzenia skutecznego i elastycznego rozwiązania niewpływającego znacznie na wydajność całego interpretera.

Wprowadzona wraz z PHP6 implementacja mechanizmów rozpoznawania kodowania zostanie oparta na wzorcu Lazy Load, którego głównym celem jest odroczenie wykonania do chwili, gdy nastąpi odwołanie do zasobu będącego wynikiem przetwarzania dokonywanego przez dany mechanizm. W przypadku PHP odwołaniem takim będzie próba pobrania danych z tablic $_GET, $_POST, $_REQUEST. Do tego czasu całe zapytanie będzie przechowywane wyłącznie w postaci źródłowej (RAW). Dodatkowo możliwa predefiniowanie / zmiana kodowania znaków poprzez funkcję http_input_encoding(), po wywołaniu której cała procedura konwersji źródłowego zapytania będzie wywołana od początku przy pierwszym odwołaniu od tablic danych ($_POST, $_GET, $_REQUEST).
Rozwiązanie takie ma kilka zalet:

• całkowity koszt związany z rozpoznaniem kodowania, jak również konwersją zestawu znaków będzie ponoszony tylko i wyłącznie w przypadku, gdy dane te będą faktycznie wykorzystywane,
• ewentualne błędy związane z konwersją zestawu znaków wystąpią w trakcie wykonania dzięki czemu będą mogły być przechwycone przez programistów,
• istniej możliwość zmiany kodowania w trakcie wywołania,

Jednak jak donosi Rasmus Lerdorf rozwiązanie takie może nieść potencjalne zagrożenie, polegające na próbach zmiany zapytania w celu umieszczenia danych powodujących błędy konwersji, niemniej jednak w planach jest bezbolesne zabezpieczenie przed tego typu próbami.