znalezione wpisy oznaczone „teorie i przemyślenia”:

Separator tysięcy, czyli o tym jak strzelić sobie w nogę

Czasem się tak dziwnie w życiu składa, że sekwencje wydarzeń i niby przypadkowych obserwacji wyraźnie prowadzą nas do jakichś konkluzji, nawet jeśli są to konkluzje stosunkowo oczywiste, a zupełnie nie odkrywcze. Taki mechanizm kilku niezależnych obserwacji doprowadził mnie niedawno do stwierdzenia oczywistego przecież faktu — używanie „separatora tysięcy” w liczbach, szczególnie kwotach pieniędzy, jest czystą głupotą.

fast food, czyli internet w oczach analfabetów

Obserwacja człowieka zirytowanego — ludzie nie czytają tego, co się do nich pisze. Zwyczajnie. Czytać nie chcą i nie lubią, a może nie umieją — nie wiem. Można by to zignorować uznając, że ludzie nie lubią robić wielu rzeczy i jakoś sobie z ich omijaniem radzą od wieków. Szkoda tylko, że czytanie wydaje się umiejętnością powszechną, a Internet wciąż jest bardziej pisany/czytalny niż jakikolwiek inny...

My i oni

Pracuję w ten branży lat kilka (no... -naście powiedzmy szczerze) i miałem okazję (współ)pracować z różnymi zespołami i szeroką gamą „typów ludzkich”. Parę rzeczy (za dużo) widziałem i wyrobiłem sobie kilka niezmiennych opinii i zapewne niesprawiedliwych uogólnień. Wiele z nich wynika z mojego trudnego sposobu bycia. Jednak nie udało się uniknąć wyraźnego poczucia, że oni są inni. Nigdy nas nie zrozumieją i zazwyczaj mają zupełnie inny pogląd na sytuację i inne cele. Oczywiście pogląd gorszy, a cele sprzeczne. A jednak z jakiegoś zupełnie niezrozumiałego powodu uparcie się ich trzymają...

Rzeczywistość tu jak nieczynne neony

Zapewne tego nie widać, ale sporo się u mnie dzieje. Niestety(?) nie w zakresie tematów, które mogłyby zainteresować potencjalnych czytelników tego bloga. Z waszego punktu widzenia można założyć, że mam coś w rodzaju wakacji. A w ramach zapchajdziury wrzucam tu kilka luźnych przemyśleń zainspirowanych miejscem, w którym się w międzyczasie znalazłem...

Szukanie pracy w korporacji - subiektywny survival guide

Osobiście myślę, że praca w międzynarodowej korporacji powinna być punktem obowiązkowym w karierze każdego programisty (i zawodów zbliżonych). Chyba inaczej nie można się przekonać jak bardzo polskie firmy są zaściankowe i jak nieporadne są firmy „małe ale z pomysłem”. Obojętnie co się myśli o globalizacji, faktem jest, że duży może więcej, robi więcej i robi to inaczej. Później możesz zostać szefem świetnie prosperującej firmy garażowej „Ja ze Szwagrem” czym możesz uszczęśliwić siebie i swoją rodzinę na siedem pokoleń w przód i trzy wstecz — ok, powodzenia. Ale otarcie się choćby o międzynarodowego giganta wydaje mi się konieczne dla nabrania dystansu, szerszego spojrzenia i kilku kluczowych doświadczeń. Równocześnie jednak wolałbym na razie pozostać w kraju, w którym mam rodzinę, żonę i koty (<ins title="dodane jakiś czas później"> i psa</ins>). Pozostaje więc praca w polskim oddziale jakiejś międzynarodowej firmy, których (na szczęście dla mojego planu, na nieszczęście dla antyglobalistów) mamy w Polsce co najmniej kilka. Tak to sobie wykoncypowałem i taką drogą zamierzam podążać. Ponieważ plan ten realizuję od kilku miesięcy (powyższa myśl dojrzewała powoli), zdążyłem odbyć kilka rozmów o pracę czy innych tam interview. Pozwolę sobie zatem zanotować kilka prostych punktów, które powinienem mieć zawczasu lepiej przemyślane i być może pracowałbym w nowej firmie nie od zeszłego piątku, a już jakiś czas wcześniej.

poniedziałek — czas zapolować na demony

Kiedy System Informatyczny staje się Dużym Systemem Informatycznym?

meta utopia?

W komentarzach do poprzedniego wpisu pojawiły się dwie interesujące opinie (#8, #9), które zasługują na szerszą odpowiedź... Oba wspomniane komentarze podważają sens publikowania metadanych z powodu naturalnych ułomności ludzi, którzy te metadane będą produkować. Ja się oczywiście zgadzam, że ludzie są w kwestii podawania prawdy tak samo beznadziejni jak w systematyczności. Jednak opisywana przez Dr Lex'a meta utopia opiera się wg mnie na dwóch założeniach, które skazują ją na klęskę: istnienie ustalonego słownika metadanych, np. via DTD,poleganie wyłącznie na dobrych intencjach autora (meta)danych. Jednak moje marzenie o wyszukiwarce nie opierało się jedynie na rozpowszechnieniu metadanych, lecz na wykorzystaniu Sieci Semantycznej. A w niej oba powyższe założenia z definicji nie istnieją.

Szukajcie a znajdziecie?

Google jest do dupy i tyle. Co z tego, że to najlepsza dzisiaj wyszukiwarka internetowa, skoro i tak jest to program żałośnie wręcz tępy. Zupełnie nie spełnia moich oczekiwań i wyobrażeń na temat wyszukiwania informacji w Internecie...

Ja nie słyszałem po prostu jak pan śpiewał bo byłem zamyślony...

Zawsze mnie to zadziwiało, że mimo dostępności w Sieci ogromnej ilości informacji w języku angielskim zadziwiająco niewielki jej fragment trafia do polskiego czytelnika.

[off-topic][private][spam][whatever] Nuda. Czas na zmiany...

Stali czytelnicy (ze zdumieniem odkrywam, że są tu tacy i to więcej niż można policzyć na palcach jednej ręki, choćby i ręki Johny'ego 11 Palców) zauważyli pewnie, że kilka ostatnich wpisów zbacza na tematy, które wydają się mało związane z inżynierią oprogramowania, cokolwiek by przez ową inżynierię rozumieć.

Każdy ma taką inżynierię, na jaką go stać

Z powodów najróżniejszych, wśród których zmiana pracodawcy wcale nie jest najważniejszym, nie poświęcam ostatnio tyle uwagi okolicznym blogom, ile szanujący się obywatel Sieci poświęcać powinien. Jednak mimo przeciwności zdarza mi się trafić, zazwyczaj po czasie, na coś interesującego...

profesja czy ledwie zajęcie?

Wszystkim znudzonym mnogością informacji czysto technicznych, ewentualnie zainteresowanym szukaniem ludzkiej strony branży polecam ostatni artykuł na Hacknot: „The Crooked Timber Of Software Development”.

gdzie ten diabeł?

wychodzi na to, że nawet jeśli faktycznie opis funkcjonalności jest „rozsądnie uogólniony”, to projekt techniczny i tak musi zawierać kilka zupełnie irracjonalnych szczegółów... :-/ Największy diabeł tkwi w tym, co zostało w cytowanym na wstępie tekście ujęte rozbrajająco prostym „oraz ERD”.

SIWZ

W moim wyobrażonym świecie sytuacji idealnych, które czasami (wbrew pozorom) faktycznie się zdarzają, pierwszy kontakt ”technicznych” przedstawicieli producenta oprogramowania (czyli analityka i/lub szefa grupy wykonawczej) z potencjalnym przyszłym systemem informatycznym następuje na poziomie dokumentu SIWZ.

wycieczka do piekła

Im więcej różnych programistów lub zespołów roboczych pracuje nad projektem informatycznym w czasie całej jego historii, tym trudniej jest „zgrać” efekty ich działań i tym niższej jakości jest produkt tego projektu. Obserwacja ta wydaje się oczywista, wręcz banalna, a mimo to bywa zupełnie niepojęta

beta über alles

Wynalazek wersji beta jest chyba jednym z największych osiągnięć psychologii i polityki w służbie inżynierii oprogramowania. Dopisek „beta” ma dobroczynny wpływ na wszystkich zaangażowanych w projekt informatyczny.

Kryzys wartości - odsłona trzecia i ostatnia

Ciąg dalszy dywagacji (powiadają, że straszliwych) na koniec roku.

Kryzys wartości - odsłona druga

Nie ma programu bez błędów — każdy, kto się zetknął z jakimkolwiek programowaniem czegokolwiek dobrze o tym wie. A jednak jest na takie buble popyt, więc z powodzeniem zajmujemy się ich komercyjną produkcją. Osobiście wątpię w uczciwość takiego zajęcia.

Kryzys wartości - odsłona pierwsza

Inżynieria oprogramowania (pomijając cokolwiek akademickie rozważania na temat zasadności samego słowa „inżynieria” w tym kontekście) jest jedną z najszybciej rozwijających się dziedzin działalności gospodarczej. Jeśli zagapisz się przez rok w innym kierunku, to właściwie nie masz szans wrócić w to samo środowisko — inne narzędzia, inne techniki, inne wymagania. Do spółki z wciąż szaleńczo galopującym rozwojem sprzętu tworzy to sytuację, w której tzw. „przeciętni ludzie” mimo, że mają coraz więcej powodów do korzystania z komputerów, rozumieją je coraz mniej. Nie potrafią powiedzieć jak to działa ani jak powstał program, który widzą „tam w środku”. A to są idealne wręcz warunki do rozwoju kilku zawodów i pojawiania się profesjonalistów — tam, gdzie szaleją demony, potrzebni są szamani, magicy i specjaliści wszelkiej maści.

Nie całuję nigdy w usta (aka: Kryzys wartości - wstęp)

Kod programów pisanych zawodowo (w sensie: przez profesjonalistów w celach zarobkowych) jest nader często pisany na szybko, źle zaprojektowany, pełen nieprzemyślanych fragmentów i łat, skomentowany słabo lub wcale, brzydki jak nieszczęście, a nawet zaskakująco nieprofesjonalny.

chwała frajerom

Twórcy Wolnego Oprogramowania udostępniają je bez ograniczeń, gdyż cenią sobie te wartości, które są fundamentem rozwoju nauki: współpracę, wzajemną krytykę i wymianę idei. Sądzą, że satysfakcja z dzieła cenionego i użytecznego dla innych jest warta więcej niż można kupić za pieniądze.

i co? i ... so

System zarządzania jakością — potężne narzędzie, bez którego trudno sobie wyobrazić utrzymanie w ryzach czegoś tak złożonego jak projekt informatyczny. Istnienie firmy zajmującej się tworzeniem wielu projektów bez takiego systemu wydaje się w ogóle nie poważne.

niewiele się zmienia przez lata

Wygrzebałem dzisiaj spod stosu papierów prawie nie używany firmowy kalendarz na rok 2002. Otworzyłem gdzieś w okolicach początku kwietnia i między sobotą a niedzielą naszkicowałem kilka tabelek mających stanowić protezę projektu do zadania, którym właśnie obarczałem kolegę. Krótka rozmowa i ten rysunek wystarczy.

sny o potędze

Powiem wprost: jestem zdegustowany i może nawet lekko zaniepokojony nachalną wrzawą wokół przeglądarki Firefox. Równocześnie jednak wyczuwam pewne ogólne podniecenie i wzrost napięcia, który musi doprowadzić do czegoś spektakularnego. Pytanie tylko kiedy i do czego?

Czyj to plan?

Przedsięwzięcie programistyczne, tak jak każdy inny przejaw zorganizowanej działalności zespołowej, nie może się obyć bez konkretnego planu działania. To z pozoru banał. Jednak wniknięcie w szczegóły powstawania planów lub harmonogramów na typowym grzęzawisku ujawnia znacznie mniej oczywiste zależności i konsekwencje.

free as a ...?

Zebrałem się w końcu w sobie, sięgnąłem na półkę po lekko już zakurzone 4 CD-ki i upgradeowałem nasz domowy system (z Fedora Core 1 do 2). Zupełnie przypadkowo trafiłem dokładnie w dzień, w którym FC1 przeszło do historii — jak widać intuicja działa ;-). Rzecz się odbyła stosunkowo szybko (no ok, godzinę to trwało), w miarę bezboleśnie i właściwie dosyć przyjemnie. I jak często w takich sytuacjach dopadło mnie uczucie zadziwienia nad faktem, że właśnie na moim dysku rozsiada się wygodnie kilka gigabajtów pełnowartościowego, darmowego, wolnego oprogramowania, a tymczasem komputer, na którym to instalowałem, wszystko dookoła, a nawet piwo i parówki, które podjadałem w trakcie, zostały kupione za pieniądze zarobione na bardzo płatnym i bardzo zamkniętym sofcie. Ten dysonans czasami nie daje mi spokoju...

smutna prawda numer jeden

„Trudno powiedzieć, kto jest większym kretynem - klient, który to wymyślił czy my, którzy się na to zgadzamy...” — takim filozoficznym przemyśleniem poczęstował nas dzisiaj kolega ślęczący nad Dziwną Funkcjonalnością. I zrobił to nie jedyny, nie po raz pierwszy i nie ostatni.

Pair Programming - good intention gone bad

Pair Programming — jedna z podstawowych i jednocześnie najbardziej kontrowersyjnych praktyk stosowanych w XP. Mam wrażenie, że w przeważającej większości znanych mi przypadków to po prostu nie zadziała. Nie twierdzę, że to pomysł do niczego — Pair Programming może działać i może być wydajną techniką (może nie od razu 1+1=3, ale przynajmniej 1+1> 2). Jednak równocześnie istnieje mnóstwo powodów, dla których może się okazać absolutną klęską.

XP name considered harmful

Bez względu na to jak obiecujące byłyby koncepcje związane z Extreme Programming, nigdy nie będę w stanie wprowadzić takiego pojęcia oficjalnie w poczet technik stosowanych w firmie. Do powodów, które sobie wyobrażam, należą przede wszystkim takie:

Agile Modeling

Kiedy pierwszy raz zetknąłem się z pojęciem Agile Modeling spotkałem różne mniej lub bardziej rozbudowane wprowadzenia czy też próby skrótowego przedstawienia tego pojęcia (choć niejako z definicji skrótowo przedstawić się go nie da), w tym również poniższą listę:

engineering?

Pytanie o zasadność słowa engineering w wyrażeniu software engineering nie jest bynajmniej nowe ani dziwne. Jest wręcz uzasadnione, a uzasadnione pytania tego kalibru zawsze są kłopotliwe. Jeśli nie niebezpieczne...

survival test

Mierzenie jakości procesu produkcji oprogramowania jest chyba bardziej skomplikowane niż w przypadku jakiegokolwiek innego przedsięwzięcia. Istnieją na ten temat spore opracowania i rozbudowane techniki (które zawsze wymagają produkowania ogromnych stosów dokumentacji, dobrze jeśli niekoniecznie papierowej), ale istnieją też szybkie testy pozwalające zorientować się mniej więcej jak głęboko stoimy. Może zbyt to przypomina "testy psychologiczne" z gazet dla nastolatek, ale w gruncie rzeczy nie jest takie całkiem głupie...

kiedy byłem małym chłopcem, hej

Kiedy już wiedziałem, że chcę zawodowo pisać programy, że chcę być programistą, tak naprawdę nie wiedziałem i nie rozumiałem nic. Przez większość "szkolnej młodości" pisałem programy najróżniejsze, małe, średnie i "całkiem spore", na platformy wszelkie jakie się w tym czasie przewinęły przez scenę i moje łapy (począwszy od Atari 65XE, bo ZX Spectrum nie ma co wspominać). To hobby dało mi to pewne pojęcie o tym jak to się robi i chyba ogromnie ułatwiło życie na studiach. Wydawało mi się wtedy, że zawodowe tworzenie oprogramowania to podobna zabawa plus dodatkowo ktoś ci za to płaci — decyzja o wyborze zawodu była prosta. Zbyt prosta.