Czas, możliwości oraz ciągły rozwój technologii sprawił, że aplikacje muszą być jak najlepiej dopasowane do działalności Klienta. Wychodząc na przeciw oczekiwaniom, staramy się doradzić jaką aplikację wybrać – webową, czy desktopową.

W ostatnich latach zauważyliśmy trend wzrostowy dla aplikacji webowych. Bez wątpienia przyczynił się do tego rozwój Internetu, który w szerokim paśmie oplótł kulę ziemską. Dlaczego więc z tej możliwości nie skorzystać? Pełna mobilność, możliwość skorzystania z aplikacji w każdym miejscu na świecie – to wygoda. A co z aplikacjami desktopowymi – czy nastał ich kres? Nie, natomiast mają one większe wymagania i wprowadzają pewne ograniczenia. Czym zatem te dwie aplikacje się różnią? O tym piszę poniżej.

Pierwszą i najważniejszą różnicą jest fakt, iż aplikacja webowa (internetowa) jest programem, który komunikuje się z użytkownikiem za pomocą okna przeglądarki internetowej, a aplikacja desktopowa instalowana jest na dysku komputera użytkownika.

Ogromną zaletą wybrania aplikacji webowej w tym przypadku jest możliwość dostępu do aplikacji z praktycznie dowolnego miejsca na ziemi, w którym znajduje się Internet. Nie jest konieczne instalowanie aplikacji na komputerze, co z pewnością nadaje nam mobilności i możliwości pracy bez sztucznych barier.

Aplikacja desktopowa uruchamiana jako program na komputerze ogranicza, przywiązuje do stanowiska pracy i do urządzenia. Aby skorzystać z takiej aplikacji na innym komputerze należy ją wcześniej zainstalować. A przecież czas spędzony na instalowaniu i późniejszym odinstalowaniu aplikacji można przeznaczyć na coś zupełnie innego.

Aplikacje webowe, w przeciwieństwie do większości aplikacji desktopowych nie są zależne od systemów operacyjnych. Nie musimy się zatem martwić, że aplikacja nie będzie działała na maszynie z innym systemem. Nie musimy jej także dopasowywać do pudełka, jakim jest system operacyjny, a do indywidualnych wymagań Klienta. Dzięki wykorzystaniu serwerów www i przeglądarki internetowej z aplikacji webowej możemy skorzystać na każdym komputerze w innym dziale, mieście lub kraju.

Kolejnym ważnym punktem do rozważenia jest kwestia aktualizacji. W przypadku aplikacji desktopowej zmuszeni jesteśmy zaktualizować każdy z komputerów, na którym zainstalowana jest aplikacja. W przypadku aplikacji webowej jest to kwestia niewymagająca tyle zaangażowania i czasu – administrator aplikacji aktualizuje ją, dzięki czemu już po chwili na każdym z komputerów możemy korzystać z najaktualnieszej wersji aplikacji.

A co z szybkością pracy, czy są jakieś różnice pomiędzy aplikacją desktopową a webową? Generalnie, na pierwszy rzut oka różnic nie widać. W każdej z nich możemy spotkać się z czynnikami warunkującymi efektywność aplikacji, takimi jak przepustowość łącza internetowego (w przypadku aplikacji webowej), jak również wydajności samego sprzętu komputerowego (w aplikacji desktopowej).

Bezpieczeństwo naszych danych to równie ważny punkt do rozważenia. Aplikacje webowe mogą stać się obiektem zainteresowania hakerów. Dobrze zabezpieczone, szyfrowane – nie stanowią problemu. Należy również pamiętać, że logując się w sposób nieostrożny do takiej aplikacji, na przykład z kafejki internetowej, zostawiamy po sobie ślad. Dane mogą powędrować w niepowołane ręce. Są to czynniki ludzkie, na które twórcy aplikacji nie mają wpływu. Aplikacje desktopowe natomiast uzależnione są od kondycji sprzętu, na których są zainstalowane. Wirusy, którymi dany komputer może być zainfekowany także mogą zbierać dane z programów, z których korzysta się na komputerze. Należy zatem pamiętać, że same aplikacje, choć dobrze zabezpieczone, wymagają od nas odpowiedzialności.

Na koniec podam kilka przykładów, gdzie można wykorzystać poszczególne aplikacje.

Aplikacjami desktopowymi mogą być różnego rodzaju programy księgowe, fakturowe, wszystkie, które musimy instalować na naszych komputerach.

Aplikacjami webowymi mogą być serwisy społecznościowe, kurierskie, transakcyjne, lojalnościowe, sklepy internetowe jak również inne aplikacje, w których dokonuje się autoryzacji. Pozwalają one, w przeciwieństwie do zwykłych stron internetowych interakcję z użytkownikiem. Aplikacjami webowymi mogą być również rozbudowane aplikacje desktopowe.

Nie zamykamy się jednak na taki podział. Klienci wymagają od nas również połączenia aplikacji webowych i desktopowych. Wtedy, nawet osoby niezdecydowane znajdą rozwiązanie dla siebie. Jedynym minusem takiego rozwiązania jest czas, który ze względu na większą ilość pracy wydłuża się podczas tworzenia takich rozwiązań.

Poniżej pokażę rozwiązanie następującego problemu: “jestem programistą, znam i lubię Gita, ale w mojej firmie używa się SVNa”. Z pomocą przychodzi rozszrzenie git-svn, które umożliwia obustronną synchronizację repozytoriów. Rozpoczynamy od instalacji w systemach z rodziny Debian:

sudo apt-get install git-svn

Następnie inicjalizujemy repozytorium:

mkdir repo
cd repo
git svn init svn://repo.path/trunk
git svn fetch -r HEAD

Po tych czynnościach w folderze repo mamy już źródła naszego projektu. Możemy przystąpić do kodowania. Standardowo procedura nie różni się od normalnego używania Gita (czyli branch’owanie, rebase’y, mergowanie). Jedynie dochodzą dwie komendy którymi synchronizujemy się z repozytorium SVN:

git svn rebase

Pobiera najnowsze zmiany z repozytorium SVN do gałęzi master (odpowiednik svn update).

git svn dcommit

Wysyła nasze najnowsze zmiany z gałęzi master do repozytorium SVN (odpowiednik svn commit).

Warto jeszcze nadmienić o często spotykanej metodyce pracy z Gitem, tzw. ticket-workflow. Korzystając z aplikacji zarządzania zadaniami, takiej jak Jira lub Trac, każde zadanie ma swój numer. Dla każdego zadania tworzymy osobny branch w Gicie o nazwie TICKET_NR-krotki-opis. Dzięki temu możemy łatwo przełączać konteksty, jeśli przyjdzie nam nagle pracować nad innym zadaniem, a także porządkować commity przez spłaszczanie ich przy mergowaniu do gałęzi master. W naszym branchu na zadanie commitujemy do woli, a mergując do mastera używamy opcji squash, która stworzy nam jeden commit. Można też użyć mechanizmu rebase z opcją interactive, dzięki któremu możemy grupować lub reorganizować commity.

Powyższe rozwiązania zostały sprawdzone w praktyce i sprawowały się bardzo dobrze, obecność SVN była praktycznie nieodczuwalna w całym procesie :-)

Więcej informacji o samym Gicie znajdziesz w artykule Konrada: GIT-owy piątek z XSolve

Kliknij tutaj

Po zapisaniu paczki należy wykonać następujące kroki:

• –Prawy klik na SurfBouncer.exe -> Właściwości -> Zgodność
• –Tryb zgodności -> zaznacz ‘Uruchom ten program w trybie zgodności z:’ -> wybierz ‘Windows Vista (Service Pack 1)
• –W sekcji Poziom uprawnień zaznacz ‘Uruchom ten program jako administrator’
• –Kliknij w ‘Zastosuj’
• –Kliknij w ‘OK’

Po wykonaniu powyższych kroków należy uruchomić SurfBouncer.exe i zainstalować wszystko z domyślnymi ustawieniami. Po instalacji w menu start w sekcji wyszukiwarki wpisujemy OpenVPN i na dostępnym wyniku klikamy prawym -> Właściwości aby sprawdzić czy tryb zgodności jest taki jak dla SurfBouncer.exe (powinien być taki sam, ale jeśli nie to na taki należy ustawić).

Dalsze postępowanie jak w README udostępnionym przez Michała Organka, czyli:

• –menu START > programy > OpenVPN > “OpenVPN configuration file directory”
• –do otwartego katalogu konfiguracji “config” kopiujemy:
• ——katalog “certyfikates”
• ——plik konfiguracyjny “windows/xsolve-hq-openvpn.ovpn”

Teraz można już uruchomić klienta, kliknąć prawym na ikonę monitorów z czerwonym ekranem oraz wybrać z listy połączenie do ‘xsolve-hq-openvpn’.
Prawdopodobnie ten sposób działa również dla Visty.

Na początku najważniejsze jest, aby dobrze zrozumieć, czym jest projekt. Każda z metodyk podaje swoją definicję projektu, ale uogólniając można powiedzieć, że jest to jednorazowy, zaplanowany ciąg zadań podjętych w celu wytworzenia unikalnego produktu lub usługi. Koniecznie należy przy tym pamiętać, że każdy projekt ma dokładnie określony początek i koniec oraz dysponuje ograniczonymi zasobami. Jest to ważne, gdyż umożliwia oraz wpływa na sposób planowania projektu.

Realizację każdego projektu podzielić można na 4 główne fazy – inicjacji (definiowania projektu), planowania, realizacji oraz zamknięcia projektu. Częstym błędem jest przekonanie, że faza planowania jest pierwszym etapem realizacji projektu. Nie jest to prawda – na samym początku, zanim jeszcze projekt zostanie dokładnie zaplanowany, następuje faza inicjacji projektu, w ramach której podejmowana jest decyzja, czy projekt będzie realizowany. Aby jednak możliwe było podjęcie takiej decyzji, konieczne jest zastanowienie się, jakie cele chcemy osiągnąć realizując dany projekt, zgrubne określenie zasobów i budżetu, podanie najważniejszych produktów projektu i na tej podstawie ustalenie, czy realizacja projektu jest uzasadniona z puntu widzenia biznesowego.

W momencie, gdy projekt jest zatwierdzony do realizacji, następuje przejście do fazy planowania. W fazie tej – nie zagłębiając się w szczegóły – następuje doprecyzowanie zakresu projektu oraz jego dokładne zaplanowanie. Planowanie to jednak nie tylko utworzenie harmonogramu, ale także określenie planu jakości, planu komunikacji, planu zarządzania ryzykiem, itd. W tej prezentacji skupimy się na tworzeniu struktury podziału pracy oraz harmonogramu.

Pierwszym krokiem, który trzeba wykonać przed utworzeniem harmonogramu, jest ustalenie listy zadań, które będą realizowane w projekcie i zapisanie jej w postaci struktury podziału pracy (WBS – Work Breakdown Structure). Ustalenie wszystkich zadań nie zawsze jest jednak proste – często stosowaną praktyką jest skorzystanie z tzw. mapy myśli, która pozwala w zorganizowany sposób stworzyć hierarchię zadań do wykonania.

Mając gotową strukturę podziału pracy można przystąpić do kolejnego kroku, tj. stworzenia sieci PERT. Wśród wyznaczonych zadań wiele może być realizowane w dowolnej kolejności, jednak wiele zadań w projekcie jest w określony sposób powiązanych i uzależnionych od siebie (np. raczej nie jest możliwe wykonanie testów systemowych przed zakończeniem kodowania). Sieć PERT pozwala właśnie zamodelować zależności pomiędzy zadaniami – generalnie dostępne są 4 rodzaje zależności, z których jednak najpopularniejszą jest zależność typu “koniec-start”, w której początek realizacji określonego zadania uzależniony jest od zakończenia realizacji innego zadania. Warto pamiętać, że przy tworzeniu sieci PERT należy brać pod uwagę wszystkie możliwe zależności – te obiektywne  (wynikające np. z przyjętego procesu wytwórczego czy ograniczeń prawnych), jak i subiektywne, wynikające często z wewnętrznych ustaleń lub ograniczeń.

Z siecią PERT związane jest bardzo ważne pojęcie dotyczące zarządzania projektami, tj. ścieżka krytyczna. Ścieżka krytyczna jest to sekwencja zadań o najdłuższym czasie trwania (najdłuższa ścieżka w projekcie), na której występuje zerowy zapas czasu. Każde opóźnienie w realizacji zadań występujących na ścieżce krytycznej powoduje opóźnienie w realizacji całego projektu. Ścieżka krytyczna zależy (i wynika) z ustalonych powiązań między zadaniami oraz zdefiniowanych czasów trwania poszczególnych zadań.

Mając stworzoną sieć PERT można przystąpić do tworzenia harmonogramu. Harmonogram jest to – w uproszczeniu – sieć PERT nałożona na zdefiniowany kalendarz i uwzględniająca dostępność w czasie zasobów niezbędnych do realizacji poszczególnych zadań. Harmonogram projektu zwykle prezentowany jest w formie tzw. wykresu  Gantt’a.

Ostatnim tematem poruszonym w prezentacji jest krótkie wprowadzenie do metody wartości uzyskanej (ang. Earned Value Management), służącej do kontroli harmonogramu i budżetu w trakcie realizacji projektu (kontroli stanu bieżącego z założonym planem). Metoda ta, bazując na 3 głównych parametrach – PV (Planned Value – wydatki planowane do poniesienia na danym etapie realizacji zadania), AC (Actual Cost – wydatki rzeczywiście poniesione) i EV (Earned Value – wartość wykonanej pracy wyrażona zaplanowanym budżetem) pozwala określić, czy projekt (zadanie) realizowane jest w ramach założonego harmonogramu (współczynnik SPI) i budżetu (współczynnik CPI).

W ramach “Piątków z XSolve” miałem zaszczyt i przyjemność pokazać reszcie zespołu czym ten GIT jest, i dlaczego warto się nim zainteresować. Podczas prezentacji osoby bardziej obeznane w SCMach – w tym poza SVN oraz Gitem również Mercurialem – wtrącały swoje trzy grosze co zawsze jest mile widziane i bardzo pomogło ogólnej wartości prezentacji. Mam nadzieję że ta króciutka prezentacja zachęci niektórych z obecnych – lub Was, czytających bloga – do rzucenia okiem na dokumentację lub liczne poradniki dotyczące Gita – poniżej kilka dobrych linków od których można by zacząć:

• http://www.youtube.com/watch?v=4XpnKHJAok8 Wystąpienie Linusa Torvaldsa dotyczące Git
• http://whygitisbetterthanx.com – przechwalająca Git’a stronka, zestawiająca go z innymi SCM
• http://git.or.cz/course/svn.html – porównanie side-by-side z SVN
• http://git-scm.com – Strona domowa projektu

    $conn = new PDO('dblib:host=127.0.0.1;dbname=database', 'user', 'pass');
    $stmt = $conn->prepare("EXEC sp_SaveMagicNumber ?");
    $stmt->bindValue(1, 5, PDO::PARAM_INT);
    $stmt->execute();

Kod z powyższego listingu wywoła procedurę sp_SaveMagicNumber z parameterem 5. Jeśli używamy symfony wraz z Doctrine, możemy (a nawet powinniśmy) zamienić pierwszą linijkę na:

    $conn = Doctrine_Manager::getInstance()->getConnection();

Można też przekazywać parametry jako “placeholdery”, jak na listingu poniżej:

    $conn = Doctrine_Manager::getInstance()->getConnection();
    $stmt = $conn->prepare("EXEC sp_IntroduceYourself :name, :surname");
    $stmt->bindValue(':surname', 'Sznapka', PDO::PARAM_STR);
    $stmt->bindValue(':name', 'Wojtek', PDO::PARAM_STR);
    $stmt->execute();

Ostatnim punktem programu są parametry typu OUTPUT, czyli zwracające wartości z procedury składowanej (podobnie jak parametry funkcji PHP przekazywanych przez referencję). Niestety biblioteka PDO posiada błąd, który uniemożliwia poprawne działanie metod z takimi parametrami. W idealnym przypadku, jeśli parametr w MSSQL jest zdefiniowany jako OUTPUT powinniśmy go dostać następujący sposób:

    $conn = Doctrine_Manager::getInstance()->getConnection();
    $stmt = $conn->prepare("EXEC sp_GetCountry :city, :country OUTPUT");
    $stmt->bindValue(':city', 'Gliwice', PDO::PARAM_STR);
    $country = NULL;
    $stmt->bindParam(':country', $country, PDO::PARAM_STR | PDO::PARAM_INPUT_OUTPUT);
    $stmt->execute();
    printf("Dla miasta %s procedura zwraca kraj %s", $city, country);

Niestety pomimo wielu prób, nie udało się obejść tego błędu i na chwilę obecną wygląda na to, że nie ma sposobu na pozyskiwanie parametrów typu OUTPUT z procedur składowanych MSSQL. Podobne problemy można spotkać na bugtrackerze PHP: http://bugs.php.net/bug.php?id=50555

RRDtool to oprogramowanie open source służące do przechowywania danych, które pojawiają się stale co pewien okres czasu. Dane gromadzone są w bazach o rozszerzeniu rrd, które wyróżnia wysoka regularność zapisu, cykliczność oraz stały rozmiar. Oprócz funkcjonalności charakterystycznych dla bazy danych, RRDtool oferuje inne mechanizmy. Jako przykład może tutaj posłużyć mechanizm prezentacji graficznej, który pozwala przedstawiać gromadzone dane w postaci konfigurowalnych wykresów. Licznie biblioteki (m. in. dla PHP, Ruby, Perl) umożliwiają używanie RRDtool bezpośrednio z poziomu języka.

Rozpocznijmy od utworzenia nowej bazy, przy czym dla uproszczenia i bez większych strat na ogólności ograniczymy się do jednego punktu pomiarowego. Tworząc bazę (RRDtool udostępnia do tego polecenie create) musimy określić, poprzez jawne podanie wartości lub decydując się na wartość domyślą (dostępną tylko w niektórych przypadkach), zestaw parametrów które ściśle określą jej strukturę i zachowanie. Przykładowo parametr kroku (en. step) oznacza wartość interwału, z jakim będą analizowane dane. Każda baza wymaga zdefiniowana co najmniej jednego źródła danych DS (en. data source), czyli wielkości, której pomiary będziemy chcieli przechowywać. Każde źródło danych posiada nazwę, typ, dopuszczalne wartości ekstremalne oraz wartość pulsu (en. heartbeat), która oznacza maksymalną ilość sekund pomiędzy zapisem dwóch danych. W sytuacji, gdy RRDtool nie otrzyma nowych danych przez okres dłuższy niż wynosi wartość pulsu, automatycznie użyta zostanie wbudowana wartość UNKNOWN (U). RRDtool udostępnia cztery podstawowe typy źródeł danych: GAUGE, COUNTER, DERIVE oraz ABSOLUTE. Źródła typu GAUGE przechowują wartości w postaci, w jakiej zostały one dostarczone do RRDtool, dlatego nadają się do przechowywania np. wartości temperatury. Źródła typów COUNTER, DERIVE oraz ABSOLUTE przechowują wartość przyrostu mierzoną na jednostkę czasu (kroku). Na podstawie wartości kroku i zgodnie ze zdefiniowanymi źródłami danych RRDtool konstruuje układ punktów głównych PDP (en. primary data point) — uporządkowanych par, których pierwszym elementem jest znormalizowany znacznik czasu, a drugim — zestaw wartości wszystkich źródeł danych odpowiadających temu znacznikowi. Dane trafiające do pliku rrd w pierwszej kolejności zapisywane są w układzie punktów głównych, a następnie, po przetworzeniu przez funkcję konsolidującą CF (en. consolidation function), tworzą punkt skonsolidowany CDP (en. consolidated data point). Punkty skonsolidowane przechowywane są w Round Robin Archive (RRA) — specjalnych archiwach, których zdefiniowanie (co najmniej jednego) jest wymagane podczas tworzenia bazy. Na podstawie definicji RRA obliczana jest długość cyklu. Długość cyklu w tym przypadku należy rozumieć jako ilość punktów CDP, które mogą znaleźć się w danym archiwum (kosztem zapisu n+1 punktu CDP, gdzie n oznacza długość cyklu, następuje utrata najstarszego). Dzięki takiemu rozwiązaniu RRDtool posiada jednoznacznie wyznaczone informacje dotyczące ilości punków PDP, które musi przechowywać. Skutkuje to stałym, obliczanym podczas kreacji rozmiarem baz RRD.

Pełna definicja przykładowej bazy RRD odpowiadającej naszym wymaganiom mogłaby wyglądać następująco:

rrdtool create somewhereOnEarth.rrd --start 1277675999 --step 3600 /
DS:temperature:GAUGE:3600:U:U /
RRA:MIN:0.5:24:365 /
RRA:MAX:0.5:24:365 /
RRA:AVERAGE:0.5:24:365 /
RRA:MIN:0.5:720:12 /
RRA:MAX:0.5:720:12 /
RRA:AVERAGE:0.5:720:12 /
RRA:MIN:0.5:8760:1 /
RRA:MAX:0.5:8760:1 /
RRA:AVERAGE:0.5:8760:1

Powyższe polecenie utworzy nową bazę danych o nazwie somewhereOnEarth, z jednym źródłem danych typu GAUGE oraz dziewięcioma archiwami RRA przechowującymi odpowiednio minimalne, maksymalne i średnie temperatury dzienne, minimalne, maksymalne i średnie temperatury miesięczne oraz minimalną, maksymalną i średnią temperaturę roczną. Wartości powinny napływać co godzinę, nie wcześniej niż 28.06.2010, 0:00:00 CET (1277676000 to pierwszy znormalizowany znacznik czasu po 1277675999).

Na tym etapie jesteśmy gotowi na gromadzenie danych. Za uaktualnianie bazy o nowe wartości odpowiedzialna jest funkcja update. Niestety nie dysponujemy odpowiednimi możliwościami, aby dodawać nową wartość temperatury co godzinę. Spróbujemy zasymulować część pomiarów przy użyciu poniższego generatora temperatur:

#!/bin/bash
base=( 15.6 17.4 19.3 23.9 26.1 28.5 30.1 31.4 31.1 29.4 26.9 24.4 22.5 21.3
       20.5 19.7 19.1 18.4 17.5 16.9 16.7 17 17.3 18.9 14.4 15 16.2 17.1 18.8
       18.9 19.1 19.4 19.3 19.1 18.6 18.4 17.4 16.4 16.1 15.4 14.3 14.1 13.3
       11.9 11.3 10.3 10.1 9.9 20.1 22.3 23.3 24.2 27 28.8 30.6 31.1 31.9 31.4
       31.1 30.2 28.9 24.3 20.2 19.5 17.3 15.1 12.9 12.1 13.2 13.6 14.2 14.9 )

fluctuations=( 3.4 5.5 1.3 -3.6 4.2 0.3 2.5 -2.2 -4.1 2.1 )

rrd='somewhereOneEarth.rrd'
timestamp=1277676000

for((i=0;i<=90;i++))
do

 let fluctuationIndex=$RANDOM%10
 let baseIndex=$RANDOM%3

 for((j=0;j<=23;j++))
  do

   let k=$j+$(($baseIndex*24))
   rrdtool update $rrd $timestamp:`echo ${base[$k]}+${fluctuations[$fluctuationIndex]} |bc`
   let timestamp=$timestamp+3600

  done
done

Skrypt powinien uzupełnić naszą bazę o dane z okresu dziewięćdziesięciu dni. Do odpytywania bazy służy funkcja fetch. Funkcja fetch używana jest przez mechanizm prezentacji graficznej wywoływany poleceniem graph. Szeroki zbiór parametrów konfiguracyjnych w większości przypadków umożliwia dostosowywanie wykresów do własnych potrzeb. Przykaładowe polecenie

rrdtool graph sampleGraph.png -s 1277676000 -e 1293832800 /
-w 500 -h 200 -G mono -E -v "Temperature [Celsius]" /
DEF:maxtemp=somwhereOnEarth.rrd:temperature:MAX /
DEF:mintemp=somwhereOnEarth.rrd:temperature:MIN /
AREA:maxtemp#bbff00:"Maximum temperature\n" /
AREA:mintemp#0066ee:"Minimum temperature"

powinno wygenerować wykres zbliżony do następującego (z każdym uruchomieniem skrypt najprawdopodobniej wygeneruje inny zestaw danych, stąd prawdopodobne są różnice w wartościach na wykresie):

RRDtool to z pewnością ciekawe narzędzie, które może okazać się bardzo pomocne w wielu sytuacjach. Należy jednak pamiętać, że powstało, aby radzić sobie z pewną klasą problemów i zastosowanie w niektórych przypadkach będzie niemożliwe lub bardzo trudne. Jednocześnie zachęcam do własnych eksperymentów oraz zapoznania się z dokumentacją oraz tutorialami na stronie projektu.

  class myWidgetFormSelect extends sfWidgetFormSelect
  {
    public function renderContentTag($tag, $content = null, $attributes = array())
    {
      if ($tag == 'option' && isset($attributes['value'])
        && $this->disableCondition($attributes['value'])
      ) {
        $attributes['disabled'] = 'disabled';
      }
      return parent::renderContentTag($tag, $content, $attributes);
    }   

    protected function disableCondition($value)
    {
      return (int)$value < 0;
    }
  }