Some of you may already about PolarRose - people visual search engine. They’ve developed plugin for FireFox and Internet Explorer which allows you tagging and finding people appearing on pages you’re browsing. Today they have gone out of closed beta and become public beta - you may register and play around - it’s pretty interesting.
Wróciłem z Blogozbiegowiska - moim zdaniem bardzo udana impreza. Usłyszeliśmy kilku prelegentów ujętych w panel pod nazwą “Jak skutecznie poprowadzić projekt WEB 2.0“, następnie odbyło się “metaspotkanie” polskich barcampów. Każdy z prelegentów opowiedział o spotkaniach który był organizatorem (lub uczestnikiem - tak jak w moim przypadku). Jak zwykle zamieszczam prezentację - zawiera ona punkty jakie powinny być poruszone na spotkaniach Bootstrap przy prezentacjach biznesowych. Myslę że może się to przydać organizatorom barcampów w innych miastach. Prezentacja jak zwykle dostępna w dziale “prezentacje“
Obecnie pisanie aplikacji wygląda w zupełnie inny sposób niż kiedyś. Terminy są bardziej napięte, Klienci bardziej wymagający, kod coraz większy i sami mamy też wobec własnego kodu coraz większe wymagania. Jak do tego dorzucimy kilka równolegle rozwijanych wersji to już zupełnie można się w tym wszystkim pogubić.
Dlatego też chciałbym przybliżyć Wam kilka aplikacji bez których nie wyobrażam sobie obecnie developmentu. O systemach kontroli wersji już pisałem więc nie będę się powtarzał. Opowiem o trzech narzędziach: trac, Todo (zwany też devTodo) oraz SVNmerge.
Trac jest aplikacją webową integrującą się z repozytorium Subversion. Posiada wbudowaną przeglądarkę repozytorium, wiki dotyczące danego projektu, system ticketów (bugów) oraz tzw Timeline zawierający chronologiczne informacje dotyczące commitów, dodanych ticketów, zamknięcia bugów itp.
Aplikacja wygląda ładnie (w przeciwieństwie do BugZilli, której wygląd wręcz straszy :). Przy odrobinie nakładu pracy ładnie się integruje ze środowiskiem wieloużytkownikowym, co jest bardzo ważne przy śledzeniu błędów w projekcie i ich naprawianiu. Integracja z Subversion pozwala na używanie automatycznych linków. Np.: jeżeli w commicie jakiejś poprawki napiszemy “poprawka #43″ to przy wyświetlaniu danych z tego changesetu (commity w Subversion są nazywane changesetami czyli zestawem zmian, wgranych do repozytorium) w opisie automatycznie pojawi się link do strony z ticketem numer 43. Drugi przydatny auto-link służy do oznaczenia changesetu - np.: r166 lub [166] automatycznie stworzą link do strony zawierającej informacje na temat tej zmiany. Wśród tych informacji można zobaczyć które pliki zmieniono (i jakie zmiany zawierały), które dodano a któe usunięto - oczywiście jest dostępny także opis danego commita.
Kolejną ciekawą funkcją jest możliwość tworzenia ticketów i przypisywania ich do milestone’ów (zazwyczaj jest to moment w projekcie kiedy uzyskuje on konkretną funkcjonalność) i śledzenie ile pracy jeszcze trzeba wykonać aby osiągnąć dany punkt. Pozwala to na lepsze planowanie implementowanych funkcjonalności jeżeli widzimy zbliżający się deadline.
Wiki jest pomocne przy tworzeniu dokumentacji projektowej. Ponieważ każdy z developerów może edytować strony - przy zachowaniu odpowiedniego poziomu dyscypliny - będzie ona zawsze aktualna i obszerna. Mechanizm ten jest znany z Wikipedii więc nie będę się nad nim rozwodził.
Każdy projekt który zaczynamy ma automatycznie tworzony serwis opraty na tracu do śledzenia tego projektu i nie wyobrażam sobie pracy bez narzędzia tego typu. Na rynku istnieje oczywiście kilka podobnych rozwiązań ale żadne z mi znanych nie integruje się tak dobrze z Subversion i nie jest tak kompletne. Jedyną wadą trac jest brak możliwości zgłaszania problemów/błędów w aplikacji przez e-mail (choć można to “doskryptować”).
Strona projektu: http://trac.edgewall.org/
Drugim narzędziem z którego korzystam jako developer jest devTodo. Przez długi czas szukałem narzędzia które umożliwiało by mi bardzo szybkie dodanie nowych zadań do listy. Ponieważ pracuje głównie na konsoli, szukałem czegoś co by pracowało w trybie tekstowym na serwerze. No i znalazłem. devTodo jest właśnie prostą listą zadań z priorytetyzacją zadań, napisaną w C, pracującą w trybie tekstowym. Sprawdza się idealnie gdy nie chcę przerywać pracy żeby zapisać jakąś rzecz do zrobienia. Przy połączeniu z wpisywaniem zadań “ogólnych” do traca tworzą cudowny tandem.
Ciekawą opcją jest możliwość podczepienia skryptu pod powłokę bash który automatycznie wyświetli listę zadań z pliku .todo przy wejściu do dowolnego katalogu go zawierającego. Dzięki temu trudno jest zapomnieć co się ma do zrobienia.
Podczas pisania tego artykułu przyszedł mi do głowy pomysł na integrację traca i todo. Można napisać skryp który wyciągnie przypisane tickety do danego użytkownika i doda je do listy devTodo. Drugi skrypt sprawdzał by które zadania zostały rozwiązane i uaktualniał wpisy w tracu.
Ostatnie narzędzie jest mniej uniwersalne w przeciwieństwie do dwóch poprzednich. Wręcz jest narzędziem które pomaga w specyficznych sytuacjach. Mianowicie musisz używać Subversion i Twoj projekt musiał rozdzielić się kiedyś na dwie gałęzie (np.: w wyniku rozpoczęcia prac nad klonem serwisu). Jeżeli byłeś kiedyś w takiej sytuacji wiesz ile trudu zajmuje przenoszenie zmian pomiędzy wersjami. Jest to bardzo trudna i żmudna praca. Na szczęście jest narzędzie które to ułatwia. Jest to skrypt napisany w pythonie, dostępny w standardowej dystrybucji subversion w katalogu contrib.
Narzędzie to znacząco ułatwia przeglądanie zmian które nie są przeniesione do drugiej wersji, ich nanoszenie oraz blokowanie zmian które nigdy nie powinny być przeniesione. Skrypt ten jest generalnie nakładką na podstawowe narzędzia subversion, usprawniając ich użycie. Informacje na temat wszelakich zmian są umieszczne repozytorium Subversion (z wykorzystaniem mechanizmu svn:properties”). Jeżeli Twój projekt spełnia założenia użycia SVNmerge, polecam skorzystanie z niego - tak jak kiedyś starałem się nie rozdzielać projektów w czasie prac developerskich, tak od momentu kiedy go używam nie stanowi to dla mnie problemu.
A czy Wy znacie jakieś narzędzia które ułatwiają pisanie (pomijam edytory 
którymi warto było by się zainteresować?
Technologia AJAX staje się coraz bardziej popularna. Pozwala ona na interakcję przeglądarki użytkownika ze stroną bez potrzeb przeładowywania całej strony. Przykładowo: mamy listę zadań do wykonania. Klikamy przy jednej z pozycji w przycisk “do góry” i nagle pozycje zamieniają się miejscami pomimo tego że nie została przeładowana strona.
O ile sam nie jestem zwolennikiem tej technologi to jednak w wielu przypadkach pozwala ona na tworzenie bardziej intuicyjnych, ergonomicznych (nie koniecznie bardziej “użytecznych”) interface’ów użytkownika. Na przykład popularny Gmail bardzo intensywnie wykorzystuje tą technologię. Dzięki niej użytkownik ma wrażenie że strona działa bardzo szybko, ponieważ nie zawsze jest przeładowywana cała tylko fragment który uległ aktualizacji (np.: lista kontaktów).
Jeżeli chodzi o prace z AJAXem wszyscy polecają framework Prototype. Na bazie tego frameworku stworzony został także zestaw skryptów Ajaxian
Tworząc oprogramowanie bardzo rzadko zastanawiamy się nad procesem przenoszeniem zmian z wersji testowej do produkcyjnej - tzw. deploymentem. W małych systemach zazwyczaj wystarczy przegrać pliki z jednego katalogu do drugiego i załatwia to całą sprawę. Natomiast w większych systemach proces ten jest trudniejszy, ponieważ wymaga bardziej skomplikowanych operacji (np.: aktualizacji struktury bazy danych).
Narzędzia ułatwiające ten proces często dostarczają mechanizmy pozwalające na automatyczną modyfikację plików konfiguracyjnych (np.: definjujących dostęp do bazy), import skryptów SQL do bazy, czy też poprostu wykonanie pewnych poleceń systemowych. Szczególnie jest to przydatne kiedy między wersją testową a produkcyjną są dość znaczne różnice w konfiguracji (np.: ustawienia dotyczące scieżek, cache’a, wersji używanych programów itd). Bez narzędzi wspomagających przeniesienie zmian z jednej wersji do drugiej, łatwo jest zapomnieć o naniesieniu zmian co może spowodować błędne działanie (czy całkowite unieruchomienie) systemu.
Z jakich narzędzi zatem można skorzystać ?
Jednym z podstawowych narzędzi wspomagających deployment może być system kontroli wersji (np.: subversion czy cvs). Dzięki niemu możemy prawie że dowolnie modyfikować wersję testową, zapisać zmiany w repozytorium, następnie zaś w zaktualizwować pliki w innym katalogu.
Drugim narzędziem, bardziej rozbudowanym, jest Phing. Jest to system bardzo rozbudowany. Pozwala na tworzenie zadań, definiowanie zależności międzynimi, wykonywanie poleceń systemowych i wiele innych. Dzięki rozbudowanym mechanizmom, można stworzyć system który spowoduje iż wprowadzenie zmian nie będzie wymagało dużego nakładu pracy (poza skonfigurowaniem Phinga i zdefiniowaniem odpowiednich procedur).
Dwa poprzednie rozwiązania są uniwersalne - można je zastosować praktycznie do dowolnego systemu. Trzecie narzędzie które chciałbym przedstawić jest przeznaczone dla RubyOnRails a nazywa się Capistrano. RubyOnRails jest “fabrycznie” przygotowany do prostego deploymentu. Nawet bez Capistrano jest on przygotowany do przechowywania oddzielnej konfiguracji dla wersji testowych oraz produkcyjnych. Wśrób funkcji które udostępnia Capistrano warto wymienić:
Powyżej wymieniłem tylko kilka narzędzi (zaczynając od najprostszego). Istnieje wiele systemów które w mniejszym lub większym stopniu nadadzą się do tego. Można wyprobować znany z sytemów uniksowych make lub (z tego co wiem przeznaczony dla Javy) ANT czy poprostu napisać skrypt w ulubionym języku programowania.
Jeżeli ktoś z Was zna inne narzędzia przydatne podczas deploymentu to niech podzieli się wiedzą - chętnie je poznam.
Internet Explorer ma bardzo nieprzyjemny błąd polegający na wyświetlaniu białej strony wówczas gdy jest ona skompresowana gzipem - zarówno przy użyciu mod_gzip jak i innych mechanizmów. Kompresja stron pozwala zaoszczędzenie pasma i ich szybsze ładowanie na komputerach Klientów.
Rozwiązaniem tego problemu jest dodanie do nagłowka Content-type wysyłanego przez serwer charset. Przykładowo w PHP wyglądało by to w następujący sposób:
header('Content-Type: text/html; charset=utf-8');
a w RubyOnRails w ApplicationController:
before_filter :set_charset
def set_charset
@headers["Content-type"] = "text/html; charset=utf-8"
end
Pod wysłaniu tak skonstruowanego nagłówka biała strona nie będzie się pojawiać. Oczywiście charset musi być ustawiony na taki sam z jakiego używacie na swojej stronie.
Nie wiem co jest bezpośrednią przyczyną tego błedu, ale był on dla mnie bardzo denerwujący.
Krótkie wyjaśnienie dotyczące skrótów, które mogą nie być dla wszystkich zrozumiałe:
Od jakiegoś czasu obserwuje znaczący wzrost liczby Klientów którzy w specyfikacjach systemów internetowych umieszczają mniejwiecej takie sformułowanie:
“Wszelkie teksty, opisy, materiały [tutaj mamy wyliczanke - przyp. aut.] muszą być edytowalne przez nie techniczny personel firmy. Dodatkowo edycja powinna być równie prosta co obsługa typowego edytora tekstu.”
Jest to oczywiste stwierdzenie że Klient oczekuje wdrożenia systemu CMS. Jednak zazwyczaj pojawia się kilka aspektów które przemawiają za tym aby tego nie robić. Troche będe generalizował, ale zazwyczaj się one sprawdzają:
Jednak te argumenty zazwyczaj nie docierają do Klientów. Jest to spowodowane tym że posiadanie CMS jest trendy. Praktycznie każda firma wdrażająca systemy internetowe, zaczyna prezentacje swoich produktów od pokazania ładnego, “Wordowego” edytora i opowiadania jakie to jest cudowne narzędzie. Natomiast nikt nie mówi o wadach tych rozwiązań.
Aby lepiej zrozumieć istotę problemu i dlaczego Klientom tak bardzo zależy na posiadniu systemu zarządzania trescią (oprócz tego że jest to trendy) musimy się trochę cofnąć w czasie.
Po tym jak wszelkiej maści specjaliści od marketingu poznali możliwości internetu, zaraz chcieli umieszczać wszystkie swoje pomysły w sieci. Jednak trafili na “drobny” opór - powiedziałbym że techniczny. Mianowicie ich wiedza nie pozwalała im na samodzielne tworzenie i zarządzanie stronami. Jeżeli chcieli cokolwiek zmienić na stronie czy coś dodać musieli zwracać się z prośbą do informatyka lub też zewnętrznej firmy. Pewnie nie było by w tym nic złego gdyby nie fakt że zaraz po publikacji nowej treści była ona wielokrotnie zmieniana. Niestety Klienci bardzo często werbalizują swoje potrzeby dopiero jak coś zostanie wykonane i pokazane.
Dodatkowo pojawiały się błędy wynikające z niezrozumienia (typu.: “Logo miało być pod zdjęciem a nie nad”). Powodowało to zarówno frustrację webmasterów którzy musieli kilkakrotnie wykonywać tą samą pracę jak i specjalistów od marketingu których pomysły nie zawsze były realizowane zgodnie z ich założeniami.
Jednak wraz z rozwojem technologii, pojawiły się narzędzia pozwalające na prostą edycję stron WWW.
Jednym z pierwszych edytorów WYSIWYG był Microsoft FrontPage - pozwalał on na stosunkowo prostą edycję materiałów na stronach WWW. Nie tylko pojedyńczych podstron ale także całych witryn. Użytkownik mógł sobie “wyklikać” całą strone - na dodatek odrazu widział jak to będzie wyglądać.
Niestety cena wygody była wielka. Po pierwsze: kod HTML generowany przez niego był koszmarny. Nie dość że nie trzymał się żadnych standardów to dodatkowo był nadmiernie
obszerny. Po drugie: kod wygenerowany przez FrontPage’a działał praktycznie tylko w Internet Explorerze.
Wielu firmom / osobom jednak powyższe wady nie przeszkadzały i rozpoczeła się “mania klikalnego tworzenia stron”.
FronPage był jednak osobnym produktem i pozwalał tylko na edycję statycznych stron. Rozwiązaniem stały się edytory “osadzane” na stronach WWW. Zazwyczaj są napisane w języku JavaScript choć zdażają się także rozwiązania jako ActiveX oraz aplety Java.
Ich zaletą była możliwość łatwej integracji z formularzami WWW.
Systemy zarządzania trescią powstały razem z dynamicznymi stronami WWW. Początkowo nie miały służyć bezpośrednio Klientom - ułatwiały prace webmasterom którzy nie musieli tworzyć setek plików które przy każdej zmianie trzeba było edytować.
Jednak skoro można już było zintegrować prosty edytor z formularzem na stronie WWW, to już nie wiele więcej wysiłku kosztowało programistów napisanie systemu który pozwalał by zarówno na edytowanie treści jak i ich proste dodawanie. Systemy zarządzania treścią zaczeły pojawiać się masowo na rynku. Ponieważ na rynku najważniejszy jest Klient, większość z nich poszła w jego stronę maksymalnie uproszczając wszelkie czynność - nie wymagały one juz żadnej specjalistycznej wiedzy.
Takich możliwości brakowało działom marketingu. Każdy teraz chce mieć CMS do strony (który częstokroć jest dużo droższy niż stworzenie strony i jej aktualizacja przez zewnętrzną firmę) wraz z edytorem WYSIWYG.
Żadne argumenty nie potrafią odciągnąć Klienta od tego trendu.
Edytory WYSIWYG mają jednak podstawową wadę - pozwalają na stworzenie kodu podobnie koszmarnego, jak kod wygenerowany przez FrontPage’a, który jest zupełnie nie zgodny ze standardami W3C.
Kod takiej strony szybko rozrastał się i powodował jej wolne ładowanie. Pozatym Klient nie obeznany w tajnikach budowy stron może dzięki takiemu edytorowi spowodować całkowite “rozlecenie” się layoutu poprzez złe wstawienie różnych elementów (np.: za dużej grafiki, czy też źle sformatowanej tabelki).
Dodatkowo taka strona ma bardzo duże szanse być źle oceniona przez Google (ze względu na niekorzystny stosunek treści do kodu HTML)
WYSIWG to moim zdaniem zła droga. Zaproponuje inne roziwązanie które uważam za całkowicie wystarczające dla większości Klientów.
Jest one jednak troche trudniejsze w implementacji, jednak pozwala na zachowanie zarówno dobrej funkcjonalności oraz zgodności ze standardami.
Polega ona na opracowaniu zestawu znaczników, którymi będą musieli się posługiwać Klienci podczas edycji tekstu. Chcąć pogrubić tekst będą musieli napisać przykładowo
{BOLD}tekst{KONIEC_BOLD}
poźniej takie znaczniki będą odpowiednio interpertowane przez oprogramowanie i przekształcane do HTMLa.
Zalety są następujące:
Stosując jednak to rozwiązanie, należy pamietać o umieszczeniu gdzieś przy edytorze “sciągawki” dzięki której Klient będzie mógł podejżeć zestaw znaczników i efekty ich użycia.
Nie trzeba odkrywać koła na nowo. Istnieją już gotowe narzędzia do obsługi mechanizmu który zaproponowałem. Moim faworytem jest Textile - można łatwo się do niego przyzwyczaić oraz istnieją już gotowe klasy do obsługi tego formatu w wielu językach. Kolejnym formatem którego można użyć jest BBCode. Jest to standard używany w dość popularnym forum phpBB. Niestety nie wiem czy isnieją gotowe implementacje interpertatora dla innych języków.
Istnieją także inne gotowe formaty, jednak bardziej chodziło mi o pokazanie wad WYSIWYG i możliwości zastąpienia ich prostszymi (bardzo często lepszymi) mechanizmami.
Czasami zdarza się że aplikacja FastCGI działająca w jednym miejscu, po odpaleniu nowej instancji w nowej lokalizacji (zwłaszcza w środowiskach unixowych) zupełnie przestaje działać. W logach często pojawia się dość niezrozumiały komunikat:
FastCGI: incomplete headers (35 bytes) received from server
który nie jest zbyt pomocny podczas rozwiązywania problemu, zaś w samej przeglądarce zazwyczaj zobaczymy
500 Internal Server Error
Oto kilka możliwych przyczyn powyższego stanu rzeczy:
Napewno powodów może być więcej, jednak dwa powyższe są nagminne. Drugi zaś potrafi być bardzo absorbujący i trudny do wychwycenia - mam nadzieję że komuś to oszczędzi troche czasu.
Graficzne maile, czyli takie w których główną formę przekazu stanowi obraz, są wręcz uwielbiane przez wszelkiego rodzaju specjalistów od marketingu. Zwłaszcza jeżeli mają służyć do wysyłania firmowego newslettera.
Nie uważam że wysyłanie “graficznych” czy “htmlowych” maili jest słuszne. Jeżeli już musisz (czyt. szef wydał takie zalecenie pod rygorem zwolnienia z pracy), to przynajmniej zastosuj się do moich rad.
Oto one:
Zastosuj prosty i czytelny layout oparty na CSS. Nie używaj tabelek. Używając CSS zwiększasz szanse na przeczytanie wiadmości przez osoby, które nie akceptują maili w HTMLu bądź mają wyłączone niektóre elementy ich dotyczące.
Nie osadzaj obrazków przy pomocy tagu “img”. Zamiast tego zastosuj podkład w CSS. Dzięki temu, jeżeli ktoś nie pobiera obrazków dalej będzie miał czytelną wiadomość. Dodatkowo unikniesz wyświetlania błędu pobierania obrazka jak to ma miejsce w przypadku niektórych blokad w Outlook Expressie.
Jeżeli potrzebujesz skorzystać z obrazków, nie załączaj ich do wiadomości. W CSS ustaw aby były sciągane z firmowego serwera WWW np.: background-image: url(http://www.firma.pl/newsletter03/img/obrazek.jpg) .
Zwróć uwagę na typografię. Używaj nagłówków, paragrafów. Sformatuj tekst w taki sposób, aby był czytelny bez layoutu.
Jeżeli zastosujesz się do powyższych rad, Twój “graficzny” mail będzie czytelniejszy, zgodny ze standardami, oraz nie będzie sprawiał problemów użytkownikom którzy nie preferując pięknych graficznie, a wnoszących mało treści emaili.
Kiedyś uważałem że tak. Obecnie jednak troche zweryfikowałem ten pogląd.
Powszechnie używanym mechanizmem przekazywania identyfikatora sesji jest cookies. Jednak od pewnego czasu część użytkowników zupełnie wyłączyczasem w swoich przeglądarkach obsługę cookies. Okazało się bowiem iż mechanizm cookies jest niedoskonały - jedną z jego wad jest fakt iż działa on bez porozumienia z użytkownikiem. Dzięki temu portale internetowe, sklepy czy też inne firmy (reklamowe) mogą zbierać informację o użytkowniku (jakie strony odwiedzał itp).
Dlatego też przekazywałem identyfikator sesji przez adres URL.
Jednak nadal wiele stron użyta cookies do przekazywania sesji nie stosując żadnych dodatkowych mechanizmów. Zatem jeżeli jakiś użytkownik uporczywie nie chce zaakceptować “dobrych ciasteczek” to raczej jest świadomy iż pewne strony mogą źle działać (zwłaszcze że domyślna konfiguracja przeglądarek pozwala na działanie nieszkodliwych cookies).
Drugim argumentem który mnie przekonał do wyrzucenia identyfikatora sesji z urla jest fakt iż wielu użytkowników przesyła między sobą linki, polecając sobie artykuły czy informacje ze stron. Dla typowego użytkownika (który nie zna takich “skarcaczy” jak http://tinyurl.com lub http://42.pl/url/ ) użycie długiego linka, wklejonego w program pocztowy może stanowić nie lada problem - link może się połamać lub być źle zinterpretowany przez klienta poczty.
Trzecim argumentem jest tzw. “kradzież sesji”. O ile w przypadku cookies jest ona troche utrudniona, to w przypadku przekazywaniu identyfikatora przez adres jest wręcz banalna - zwłaszcza jak nieświadomy użytkownik prześle koledze link do strony. Dzięki temu, kolega będzie mógł użyć takiego linka i zazwyczaj bez żadnej autoryzacji może otrzymać jego uprawnienia.
Z uwagi na powyższe argumenty uważam iż jednak lepiej przekazywać sesje poprzez - tak nie lubiane - cookies. Jeżeli ktoś nie chce ich przyjmować, powinnien pogodzić się że część stron będzie dla niego nie dostępna.