To już drugie tłumaczenie artykułu, który uznałem za ciekawy, tym razem jest to artykuł pani Tracy Mayor z amerykańskiego Computerworld pt „Asperger’s and IT: Dark secret or open secret?”, za pełną zgodą i aprobatą autorki, za co serdecznie jej dziękuję :) Artykuł oryginalny jest z kwietnia 2008 i niewiele krócej czekał na swoją wielką chwilę u mnie, w szufladzie, tym razem dosłownej – wydrukowałem go, by móc go tu zamieścić.

Autorka pragnie także nadmienić, iż przytaczana historia i powiązana z nią tematyka była tematem programu „Here and Now” w amerykańskim radiu publicznym. „Ryno” to pseudonim byłego administratora systemów po 50-tce, określającego siebie samego jako „wypalonego i żyjącego jak niepełnosprawny” w wiejskich rejonach Australii.

 

Zespół Aspergera był częścią IT tak długo, jak tylko istniało samo IT. Czemuwięc nie idzie nam lepiej z aspergerowcami pośród nas?

Wprost kochał techniczne aspekty bycia administratorem systemów i był w nich świetny. Ale relacje interpersonalne wiążące się z tą pracą, jak życzliwe poklepywanie w plecy przez przypadkowych użytkowników, czy prezentacje biznesowe, były dla Ryno dosłownie nie do zniesienia.
- Mogę sprawić, że Twoje systemy będą wydajne, a przerwy w ich pracy krótsze — mówi — ale nie potrafię sprawić, by Twoi użytkownicy byli szczęśliwi.

Bob, programista aplikacji bazodanowych pracujący w branży technologicznej od 26 lat, ma przede wszystkim zdolności matematyczne i logiczne. Posiada też –  jak sam to określa – „dziwną pamięć”: jeśli nie może przypomnieć sobie odpowiedzi na pytanie, może przypomnieć sobie precyzyjnie, niczym w cyfrowym obrazie, gdzie ostatnio widział tę odpowiedź, z dokładnością do konkretnej strony, akapitu i zdania.

Bob ma także pewne swoje dziwne zachowania: może dojść do tego, że nie potrafi wypowiedzieć ani słowa, gdy jest zdenerwowany, a także interpretuje wszystko dosłownie – nigdy nie czyta między wierszami.
- Mojego szefa na pewno denerwuje, gdy źle odczytuję jego ironię – opowiada – ale przynajmniej wie, że nie robię tego celowo.

„Jeremy” doskonale potrafi przejrzeć problem inżynieryjny na wskroś, wgłąb niemalże do poziomu samego kodu. Jest świetny w rozpracowywnaniu szczegółów jeden po drugim z innymi intensywnie skupionymi ludźmi, często dyrektorami firm, dla których pracuje. By chronić swoją anonimowość, pragnął nie wspominać, w jakiej dziedzinie programowania się specjalizuje, ale wystarczy powiedzieć, że jest dobrze znaną osobą, do której można się zwrócić w tej branży.

Jeremy nie jest jednak dobry w znoszeniu głupków w miejscu pracy, czy też w użeraniu się z niekończącą się biurokracją nowoczesnej firmy. Jeśli ktoś nie ma racji – jeśli jego pomysł wprost nie może wypalić – mówi mu to, po prostu stwierdzając fakt. Odkrył, że ta bezpośredniość wywołuje wszystkie formy zdenerwowania w miejscu pracy.

Wszyscy ci profesjonaliści z branży informatycznej są autystyczni. Bob i Ryno mają Zespół Aspergera (eng. AS); Jeremy ma autyzm wysokofunkcjonujący (HFA).

Poczytaj sobie całą fajną resztę tego wpisu »

Dziś dwa projekty bazodanowe pierwszy z dwóch projektów bazodanowych. No cóż, odbębnić przeważa. Bo cóż innego można zrobić, gdy celem ćwiczenia jest „zrobić cokolwiek, co korzysta z TuNazwaTechnologii”. W szczególności irytujące było to przy projekcie „Biblioteka”… ale o tym za chwilę następnym razem :)

Oba projekty realizowane były na semestrze IV, czyli właśnie ukończonym. Oba miały korzystać z baz danych – jeden dlatego, że przedmiot nazywał się „Systemy Baz Danych”, a drugi bo tak. Jako ludzie kulturni realizujemy z Michałem oczywiście najczęściej bazy danych dokumentujące dobytek kulturowy cywilizacji w jakimś sympatycznym zakresie ;-). Dlatego też projekty od samego początku kręciły się wokół kolekcji muzycznej oraz kolekcji książek. No fakt, powodem oparcia się na kolekcji muzycznej było także to, że bazę danych tego rodzaju obaj już robiliśmy… w liceum, na zajęciach z informatyki. To i dane – dość pokaźna ich ilość z licealnej bazy MKLa – były już gotowe.

Jak to wyglądało? Od czego należało wyjść, jakie były wymagania, jak się nad tym pracowało i co z tego wyszło? No cóż… :) Skoro nadal to czytasz, to zapewne lubisz takie narzekania…

Projekt nr 2 – sklep muzyczny

Czemu sklep, a nie kolekcja? Ano bo kolekcja to taka dość statyczna jest i chyba MKLowa baza od początku bardziej sklepową była ;)

Wymagania? Jakaś baza, kilka tabel, jakieś relacje między nimi, jakiś formularz, jakieś raporty. I „żeby coś liczyło w bazie”. Technika realizacji? Dowolna, czyli MS Access 2003, a przynajmniej tak zrozumiała tę dowolność znakomita większość grupy (roku?). My się wyłamaliśmy i [żeby się nie męczyć :P] zrobiliśmy to w czymś, co znamy i w czym powstawała licealna wersja projektu: nieśmiertelny tandem PHP+MySQL. O dziwo PHP na uczelnianym serwerze jest, a MySQL można sobie utworzyć. Bezboleśnie.

Zasadniczo główny kod został rozbudowany i dopieszczony przez MKLa, bez bicia przyznaję, że mój udział był raczej znikomy, a są miejsca, że nawet nie wiem, jak coś działa ;P Cóż więc tu mogę powiedzieć.

W warstwie prezentacji (student informatyki umie stosować mądre określenia na proste rzeczy) jest to bardzo prosty HTML potraktowany bardzo prostym stylem CSS, a grafika całej strony z podstronami zamyka się w kilku obrazkach. Błękit (miał być szafirowy, okazał się wpadać w ciemny turkus – bo nie miałem skalibrowanego monitora), pomarańcz, trochę ciemnej czerwieni tam, gdzie pole powoduje zmiany w bazie.

W sklepie znalazło się też kilka javascriptowych myków takich jak obsługa okłądki płyty – gdy nie ma nic w bazie, mamy „brak okładki” widziany na screenie nr 2, ale gdy jest wpis w bazie, a nie uda się pobrać poprawnej okładki (link jest nieaktualny – bo tak naprawdę okładki kradniemy z innych serwisów ;P), to JS podstawia znów domyślny obrazek „brak okładki”, by nie zostawić brzydkiego krzyżyka. Drugi myk to formularz, w którym ustalamy kryteria do wygenerowania raportu – wszystko jest w nim kosmicznie dynamiczne (hail to MKL) – treść formularza zmienia się w zależności od wybranych opcji, natychmiast po kliknięciu (no AJAX here).

Tak, sklep jest zrealizowany od strony zarządzania sklepem, a nie z punktu widzenia klienta! Daje to większe pole manewru do dłubania w bazie danych.
Zamówienia początkowo były na każdy album z osobna, ale pani prowadząca przedmiot nie czuła się z tym dobrze i trzeba było dorobić jakieś „koszyki” ;-)

Tu można pobawić się sklepem i jego bazą danych – ale proszę nie psuć. Bazę ewentualnie możemy co jakiś czas przywracać do stanu oryginalnego (przykładowego), ale lepiej nie stwarzać ku temu okazji ;) W razie nadużyć sklep i baza zostaną po prostu usunięty z konta, więc po co to komu ;)

Największy ból projektu?

Największym problemem było tu… oddanie projektu. Mieliśmy gotowy długo przed terminem, ale prowadzące nie wykazywały zainteresowania / nie potrafiły znaleźć czasu (?), by rzucić na niego okiem. Dlatego też poprawki pod kątem ich widzimisię takie, jak wprowadzenie koszyków, trzeba było robić pod koniec semestru, gdy chcieliśmy zająć się innymi przedmiotami.

Czego nauczył mnie ten projekt?

Y… e… zakładać konto MySQL na uczelnianym serwerze. Śmiać się z tych, którzy psioczą miesiącami na Accessa, a robią w nim projekt przecież z własnego wyboru, lub nieświadomości, że wybór w ogóle był. Ale o tym przecież była mowa już na początku semestru..

Nie nauczył mnie natomiast wygenerowanego losowego hasła do bazy danych – o wiele za długie i zbyt losowe ;) Więc kilkukrotnie jeden z nas je dyktował, a drugi klepał :D

Czas wykonania – no idea.
Skład: ikari & MKL.
Podział pracy: unfair. [yeah, przyznaję]
Satysfakcja: 7/10 [just because]

(Tak, to będą posty o programowaniu. Tak, musiałem. Tak, to właśnie część mojego życia. Tak, ten post jest w wersji beta – może brakować mu troszkę treści, ładu i składu ;)) )

W życiu studenta jest szczególnie dużo różnych projektów – mniejszych i większych zadań, realizowanych jako jedno z wielu lub jako punkt kulminacyjny semestru. Studenci zaś przejawiają przeróżne podejścia

• jedni nie robią nic, bo robią za nich koledzy.
• inni nie robią nic, aż w ostatniej chwili nie skołują gotowca, którego w akcie łaski przerobią – nie zawsze po tych przeróbkach działa i nie zawsze wiedzą, co on właściwie robi
• inni robią projekcik jakoś spełniający minimalne wymogi zadania – wiedzą, co jest do zrealizowania, uczą się, jak to zrealizować i zaliczają ładnie.
• ostatni typ natomiast najpierw nie ma żadnego pomysłu, a potem nagle przychodzi Wizja. Wizja jest realizowana z rozmachem, program robi się rozbudowany, zespół ledwo mieści się w terminie (lub go przekracza), program jest wypasiony… a wykładowca ledwo rzuci okiem ;) Po czym program idzie w odstawkę i jest zapominany, jak w każdym wypadku.

Oczywiście niepokojąco często reprezentuję ten ostatni typ, co pewnie nietrudno się było domyślić po długości opisu ;)

W ciągu tych dwóch lat studiów powstało kilka takich programów, głównie pisanych przeze mnie wspólnie z emkaelem, z których po ukończeniu byłem chociaż troszkę dumny – bo fajny pomysł, bo mimo to (;D) zrealizowany… no, ewentualnie z poczuciem niespełnienia, że prowadzący przedmiot nawet nie rzucił okiem na żaden z fantastycznych „myków”, cudów i rozwiązań, nad którymi się meczyliśmy ;). Nie ukrywam, że niektóre miewam ochotę rozwinąć, komercyjniej ;)

Głupi projekt no. 1 – symulator autobusu

Na Programowaniu Obiektowym było wymyśleć sobie projekt, dowolny, najlepiej jakaś symulacja, który ogólnie rzecz biorąc zaimplementujemy obiektowo. Mając minuty na wybór tematu daliśmy się ponieść chwili i temu, jak inspi-, fascy- i irytujące jest zachowanie ludzi w środkach komunikacji miejskiej. Niektórzy z Was pewnie czytali już opisy rodzajów babć autobusowych, wielu widziało także „Dzień Świra”. Także i my mieliśmy pewne swoje spostrzeżenia:

• Wszyscy, do ciężkiej cholery siadają pojedynczo. Jeśli chcesz usiąść w autobusie z kolegą/żanką obok siebie, a połowa autobusu jest zajęta, to znaczy, że podwójne miejsca już się skończyły. Bo każdy musi siedzieć SAM. Jeszcze do tego w połowie przypadku od przejścia, żebyś czasem się pod okno nie dopchnął. Mimo, że powszechnie wiadomo, że miejsca od okna są atrakcyjniejsze ;)
• Pieprzone mohery zawsze muszą być w drzwiach pierwsze. Nie, nieważne, że na przystanku stoi tłum, a one jadą tylko jeden przystanek i będą się musiały przez cały ten tłum za chwilę przebijać do drzwi. Nie, one muszą się wepchnąć pierwsze i zająć swoje upatrzone miejsce. Jeśli zajmie je ktoś młodszy, stosują liczne techniki wywierania wpływu, by je odzyskać. Mohery generalnie przepychają się najbardziej ze wszystkich rodzajów pasażerów – jeśli upatrzy sobie miejsce, to przestawi pół autobusu, żeby się do niego dostać. Są także mohery-sprintery, które niemalże natychmiast po otwarciu drzwi pojawiają się na wybranym miejscu.
• Do autobusów regularnie wsiadają ludzie bezdomni lub co najmniej nie zaznajomieni z dorobkiem kultury w dziedzinie środków czystości. Niezależnie od zatłoczenia autobusu, wokół takich osób zawsze pozostaje pewna ilość wolnego miejsca (chyba, że faktycznie ludzie nie mogą się już siłą nigdzie przepchnąć). A nawet jak wyjdziesz z autobusu, masz wrażenie, że smród był tak intensywny, że na Tobie pozostał.
• Autobusami jeżdzą m.in. studenci, którzy – biedni, maltretowani przez uczelnie – po zarwanych nocach przysypiają podczas jazdy. Może spać na siedząco, na stojąco, a na swoim przystanku i tak się obudzi i wysiądzie.
• W autobusach zdarzają się kontrole biletów. Kanary są przekupne, jednak najczęściej niezależnie od uiszczonej kwoty i stopnia formalizacji transakcji, trzeba wysiąść.

Z cech równie życiowych, ale nie zaimplementowanych w programie:

• Przesiadki to mit. Jeśli w planie podróży masz napisane, że Twój autobus przyjedzie 17:05, a docelowy, do którego chcesz wsiąść, o 17:10, to możesz mieć pewność, że tak naprawdę będzie odwrotnie.
• Rozkłady to mit. Jeśli autobus jedzie, to stanie w korku. Jeśli stanie w korku, to będzie miał 5-25 minut spóźnienia.
• Rozkłady to mit. Jeśli autobus nie będzie miał spóźnienia, pourywa koła na dziurach w nawierzchni. Nie przyjedzie wcale. Ewentualnie Ty do niego wsiądziesz, ale nie dojedziesz do celu.
• Jak nie pourywa kół, to spłonie. A ubranie będzie Ci śmierdzieć.
• Wycieczki szkolne. Wpada toto do autobusu, podwaja głośność panującą w środku (dzieci to takie istoty, które zdolne są przekrzyczeć ryczący autobusowy silnik), przepycha się, biega, wkurza. Pcha nie tylko swoich, ale i obcych.

Model rozwiązania – UML

Jednym z wymogów było stworzenie diagramu UML do realizowanego projektu. Prawdziwie złożonym kwiatkiem wyszedł diagram akcji pasażera:

Gdybyś się zastanawiał(a): UML to taki język opisu różnych mądrych rzeczy za pomocą różnych mądrych diagramów. „Diagram akcji pasażera” znaczy „grafik, co pasażer może robić i kiedy i dlaczego to robi”

Okrągłe prostokąciki bez kącików prostych ( ;-) ) to czynności. romby to decyzje, „flagi” to zdarzenia, które nam się stały i powodują, że coś robimy.
Spójrz, czy zdawałeś/łaś sobie sprawę, jak skomplikowane jest korzystanie z autobusu? ;o

Nasz autobus „jeździł” po faktycznej trasie autobusu 69 w Łodzi – miał załadowaną listę przystanków z ich godzinami i nazwami oraz pasażerami, jacy na nich wsiadają i docelowych (np. zagęszczenie wysiadających moherów przy kościołach i cmentarzach wzdłuż trasy – a było ich trochę).

Poziom zrealizowanej interakcji: zero. Aczkolwiek mieliśmy koncepcję (gdyby było więcej czasu), by dało się wejść w tryb bardziej interaktywny ;) – kierować pasażerem lub modyfikować ich listę/cele… lub chociaż podejrzeć je bez debuggera ;-)

Interfejs

Program, działający w trybie tekstowym, miał mieć splash-screen, ale z racji platformy Win32 odpuściliśmy sobie konwersje z linuksowych escape-codes na windowsowy… kod, bo w ASCII nie idzie zdefiniować kolorów:

Następnie rysował w ASCII-arcie autobus, kolorowymi gwiazdkami oznaczając różnego rodzaju pasażerów: białą – zwykłego, zieloną – studenta (przygaszona – śpi), czerwoną kanara (rozjaśniona – sprawdza bilety), niebieską bezdomnego, a zgniłą – mohera. Moher sprinter wsiada w autobusu i zajmuje w jednej „turze”, podczas kiedy inni pasażerowie mogą robić tylko 1 krok na turę.

Wideo: 5 minut z życia aplikacji. Po 3 minucie mamy krótki przegląd kodu – chciałem zmniejszyć parametry opóźnień w programie by w drodze powrotnej „jechał szybciej”, jednak Visual Studio tak długo nanosiło zmiany w kodzie, że skończył się czas na nagranie (5 minut) ;-)

Największy ból w kodzie

Najbardziej masakryczna, zaciemniona, a zarazem kluczowa dla działania i wydajności programu to funkcja Przepchnij. Jak sama nazwa wskazuje, wiąże się ona z przepychaniem się pasażerów w autobusie. Przepychanie się pasażera nie jest w żaden sposób odgórnie skoordynowane przez sytuację w całym autobusie, czyli przez jakieś szersze spojrzenie ;) Optymalizacja bliska zeru.

Jeśli nie jesteś programistą, nie czytaj dalej tego paragrafu.

W skrócie jej działanie/wada (niepotrzebne skreślić) polega na tym:

• funkcja przyjmuje parametry: kto się pcha, w którą stronę i jak mocno (z jaką siłą)
• funkcja zwraca informację, czy udało się przepchnąć daną jednostkę z jej miejsca
• funkcja jest tak masakrycznie pozagnieżdżana sama w sobie, że może trwać stulecia. Jeśli więc wykona się bezskutecznie ponad 10 000 razy to albo zwraca niepowodzenie, albo – jeśli przepychający się akurat wysiada, jest kanarem lub moherem-sprinterem – po prostu zamienia go miejscami z pasażerem na miejscu, na które się pchamy.
• Siła = 5 oznacza, że jesteśmy w stanie przepchnąć łańcuszek 5 osób (!), by się poruszyć
• Jeśli na miejscu, na które się pchamy, ktoś stoi – każemy mu się pchać w tym samym kierunku (jeśli mamy siłę)
• Jeśli się to nie uda, próbujemy pchać go w kolejnym kierunku – i tak wszystkie po kolei, zgodnie z ruchem wskazówek zegara (albo przeciwnie – co za różnica)
• Dlatego też jeden przepychający się pasażer w tłoku powoduje problem. Pcha on każdą osobę dookoła siebie w każdym z możliwych kierunków… a każda z tych osób…. no właśnie. I program się przywiesza.
• Jeśli miejsce się zwolni (ja popchnąłem kogoś, oni dalej się poprzepychali w jakiś tam sposób (bo mnie, jako pchającego, w ogóle to nie obchodzi)), zajmujemy je
• Jeśli wypróbujemy wszystkie kierunki i miejsce nadal jest zajęte – no to kiszka ;P
• Wysiadający mogą się zamieniać zawsze, by zawsze mogli dopchnąć się w końcu kiedyś do drzwi – bo nasz autobus jest fajny i czeka, aż wszyscy wysiądą.

Tu miał ładny, sformatowany być kod źródłowy, ale… no wiecie, „Word HTML”.

Czego nauczył mnie ten projekt?

Że kodzić trzeba. I chyba tylko tyle. Może troszkę korzystania z STLa w C++, jeśli liczyć także ogólnie laboratoria. Że przedmiot „Programowanie Obiektowe” to kolejne „klepanie kodu”, bez żadnej szczególnej idei. Że ile się nie napracujesz, to prowadzący rzuci tylko okiem na ekran, zobaczy migające kolorowe gwiazdki, powie „bardzo ładne” i postawi maksymalna ocenę, minus jeden za opóźniony termin oddania.

Czas wykonania – 9 dni (głównie 1 weekend i dopracowywanie w wolnych chwilach przez tydzień)
Metodyka – Ballmer Peak.
Skład: ikari & MKL.
Podział pracy: fair.
Satysfakcja: 7/10 – fajnie, bo ekspresowo napisane i działa. Na minus, bo mało optymalny przepchnij i przywiesza. Czasem zatykało się kompletnie, a w skrajnym tłoku pasażer wypadał za drzwi (!?) mimo wielokrotnego sprawdzania pozycji przy przestawianiu ;)

Wanna see it?

Gdyby ktoś chciał się pobawić i/lub obejrzeć kod – jeśli MKL uzna ten pomysł za dobry – niech da znać ;)
Przepraszam, za nudzenie nieinformatycznej części publiki, możecie mnie nienawidzić, ale musiałem :P Od pół roku chciałem przyznać się do napisania symulatora zachowania ludzi w autobusie ;)

Programowanie – epizod z idHTTP.

Wiem, wiem, to już prawie było… ;)

Swoją drogą – mięczak, potrzebował wody… ;)Dziś zrobiłem kolejne podejście do połączeń HTTP w ICQu i… hurra! Wreszcie wszystko działa. No, prawie. Niektórzy być może pamiętają moje traumatyczne przejścia, kiedy przy poprzedniej próbie dorobienia tej opcji serwer widział 100 fantomowych połączeń nawet 2 tygodnie po ich zakończeniu (i wielu restartach z mojej strony) i jedyne, co pomogło to … restart tegoż serwera. Tym razem jest niby lepiej, niemniej jednak nie mogę pojąć, czemu to działa tak, jak działa.
Kod w Delphi, do zapytań HTTP używam idHTTP z pakietu Indy. Każde zapytanie ma nagłówek Connection: Close – zarówno po stronie klienta jak i odsyłane przez serwer. Mimo to netstat po obu stronach (klienta i serwera) pokazuje, że połączenia HTTP wiszą sobie jeszcze spory kawałek czasu po zakończeniu zapytania. Czemu?
Zasadniczy problem polega na tym, że wiszą dłużej niż trzeba czekać na nawiązanie kolejnego, zatem ich liczba rośnie. Jest to niebezpieczne nie tylko dla jakiejś tam stabilności któregokolwiek systemu (;P), ale i dla użytkownika, który znów może nagle dostać komunikat „BANG! Maksymalna ilość połączeń z tego IP przekroczona” na nie wiadomo jak długo. 10 sekund między kolejnymi odświeżeniami czata to za długo dla użytkownika, a za krótko, by liczba połączeń nie rosła. Prace nad HTTP po raz kolejny zostają zawieszone.
Help needed.

Masz czasem takie uczucie, że każdy Twój kod (czy cokolwiek tam sobie tworzysz ;)) zawsze musi mieć kilka naprawdę poważnych błędów różnego rodzaju? (tu wstaw sobie dowolną analogię do swojej twórczości) Też czujesz się czasem jak gówno a nie [tu wstaw określenie człowieka, który tworzy to, co Tobie znowu nie wyszło ;P]. Wybacz Panie, jestem tylko nędznym robakiem.

PS. Jakby co to poprawiłem co się dało w księdze gości i komentach – w tym nawet odpowiedziałem na 1 komentarz, który nigdy nie został wysłany ;) Gdyby coś nie działało, don’t hesitate to contact me (via gg/jabber/tlen – tylko nie zaczynajcie od pytania, czy jestem ;))

Programowanie.

Miałem tu coś napisać, nawet kilka razy sobie przypominałem, co. Ale tradycji staje się za dość i w chwili siadania do notki jakoś mi to umyka. Zresztą co ja mogę pisać o programowaniu? W ostatnim roku może nawet większość skończonego i działającego kodu jaki napisałem to programy na zaliczenie -_-. Poznałem trochę język ADA, na pewno mi się to przyda, prawda?…
Trochę szkoda, że opuściłem zajęcia Grupy.NET… A teraz nie wrócę, „bo za dużo w plecy” :P To u mnie typowe ;)

Implementacja .NETa w Mono wciąż jest… niesatysfakcjonująca. Nawet konsola nie do końca działa ;P To takie małe przemyślenie po uruchomieniu kawałka kodu z nadzieją, że Mono otworzy mu drzwi na świat Linuksa. Nie dziś, nie jutro.

Zresztą wszelkie kodowanie ostatnio odbywa się głównie… w mojej głowie ;) Cały czas myślę, jak osiągnąć ten jeden, złoty kod, który stanie się podstawą do napisania czegokolwiek na wszystko ;) Od początku przemyślany (z tym właśnie mam problemy), czyli architektura top-bottom (na nic mi się ta wiedza na egzaminie z algorytmów nie zdała).
Jeszcze nie czytałem, ale odłożyłem na stosik „do przeczytania” ten genialny artykuł o projektowaniu oprogramowania.

Czasem problemem jest motywacja. „A po co mi to?”, „A co będę z tego miał”, „A czy to warte mojego czasu” (tak, główna różnica to ta, że 5 lat temu tak na to nie patrzyłem, po prostu mi się chciało, choćbym nie wiem, jak głupie i mozolne cele sobie stawiał).
Kiedy czytam artykuły takie jak ten i  ten to pytanie zaczyna brzmieć „co ja tu w ogóle robię?!”… Bo matka kazała? Póki co nie jestem zadowolony ze swojego życia…

Btw. (Taka luźna myśl się przypałętała) Być może ktoś z Was zadawał sobie pytanie „czemu linki na blogu ikariego otwierają się w tej samej karcie” – warto nadmienić, że atrybut target (określający ramkę docelową) tagu <a> w nowszych specyfikacjach już… nie istnieje. Po prostu to użytkownik ma decydować, gdzie otworzy sobie stronę (klikając np. środkowym przyciskiem lub z shiftem). Fakt faktem, może po kliknięciu już do mnie nie wracasz? ;)

PolChat

Temat, kurde, rzeka. Ilekroć zbierałem się, żeby tę część notki machnąć, to w kontakcie z jej przedmiotem po prostu ręce mi opadały. A wiszącymi tak bez sensu trudno się pisze (tekst w kursywie dedykuję mojemu wykładowcy Matematyki Dyskretnej ;)).

[wersja "uważam_na_słowa"] PolChat umiera zabijany nietrafnymi pomysłami swoich właścicieli. Niby sam utrzymuje się wyłącznie z reklam (a konkretnie stanowi finansowy balast), bo licencje na czat komercyjny sprzedaje zupełnie inna firma, która nie ma prawa ingerować w PolChat (portal?) jako taki, czyli, do cholery, to, od czego wszystko się zaczęło (dziś wprawdzie nawet autor podobno nie chce o tym słyszeć). A jednak! Celem wciśnięcia głupich komercyjnych licencji jak największej liczbie klientów, firma LiveChat celowo uszczupliła funkcjonalność serwera PolChatu. To potwierdzona informacja – to oni zabrali nam rozmowy moderowane.
Zastanówmy się nad konsekwencjami. Na Polczacie jednocześnie można znaleźć zazwyczaj około 2 500 ~ 3 000 czatujących w „godzinach szczytu”. W tej samej chwili na czaterii jest 22 700 osób. Tak, niemal dziesięciokrotnie więcej! Onet wprawdzie nie podaje jawnie sumy liczby osób, jednak liczby podane przy pokojach na stronie głównej same w sobie sumują się do 9 700 osób i to bez pokoi erotycznych! Co też robi PolChat by zachęcić wobec tego ludzi do siebie? USUWA FUNKCJE, z których wielu użytkowników chciało korzystać, a niejeden pokój opierał na nich swoje podstawowe „atrakcje”. Obiecuje gruszki na wierzbie (nowy serwer, czyli rozmowy na kilku pokojach na raz) przez 2 lata, nie wprowadzając ich, mimo, że wszystkie inne serwisy tego typu oferują je od kilku lat. Posiada ekipę programistów i webmasterów (oficjalnie), którzy jednak niejednokrotnie palcem nie kiwną na poważne błędy w działaniu serwisu i czekają, aż zrobi to za nich ktoś inny (np. admin-serveroperator). Nie będziemy mogli zachęcić użytkowników przez spotkania ze znanymi ludźmi (na polchacie bywali: Mariusz Pudzianowski (i to regularnie), zespół Ich Troje (wielokrotnie), Alicja Janosz (co najmniej 2 razy), Iza Bełcik, Glaca ze Sweet Noise i bracia Mroczkowie – oraz wielu innych, ale tych widziałem na własne oczy), bo po prostu wypieprzyli nam opcję rozmowy moderowanej. Zabili najlepszą możliwość promocji serwisu.
Właściciel miał wizję PolChatu jako serwisu społecznościowego. Przykro mi, ale społeczność od PolChatu do tego czasu odejdzie. Cofamy się w rozwoju.
Chyba pora zacząć wreszcie pisać programy zupełnie z tym czatem nie powiązane, albo przynajmniej niezależne. Nie będę wsiadać na pokład Titanica widząc, że płynie wprost na góry lodowe.

No, a tak poza tym, to działa tam już opcja aktywacji nicka – po prostu wkleiłem kod z serwisu wklejki (jak sama nazwa wskazuje ;P), bo po raz kolejny nie byłem wstanie znaleźć błędu w tamtym kodzie. Ale nowy działa. Tysiące nicków nieaktywnych z takiego czy innego powodu też zostały odgórnie aktywowane.
PS. Joomla to za duży system na tak proste strony (główna funkcjonalność to przecież sam czat, chociaż ktoś chyba o tym zapomina)