Dla anglojęzyczno-potrafiących

TEN ARTYKUŁ:

http://stilldrinking.org/programming-sucks

Wszystko, czego potrzebujesz wiedzieć o mojej codzienności.

Geeky links 1

Jeśli mam odkładać setki narzędzi/linków na później/na zapas/do myślowego pudełka z narzędziami, to czemu nie robić tego publicznie. Oczywiście, na pewno istnieje już do tego 20 serwisów społecznościowych, ale… Najbezpieczniej będzie przecież zachomikować linki u siebie na starym dobrym WordPressie.

Treść większości silnie programistycza.

Oraz goście specjalni:

 

JavaScript


Obraz pochodzi z The Profound Programmer

Proste pytanie, idealne na rozmowę kwalifikacyjną…

Mając wywołanie postaci

parseInt("010")

jaki będzie otrzymany wynik?

Początkujący programista JavaScript odpowie „10”.
Doświadczony programista JavaScript odpowie „8, bo liczby zaczynające się od 0 traktowane są jako ósemkowe”.
Firefox 18 odpowie: 8.
Chrome 21 odpowie: 8.
Chrome 23 odpowie: 10.

Bo czemu nie :)
Pamiętaj, jako drugi argument zawsze podaj bazę systemu liczbowego (zwykle 10).
Pytanie dodatkowe: który z wyników jest zgodny ze standardem ECMAScript 5? odpowiedź.

Zespół Aspergera – mroczny sekret IT?

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).

Więcej »

Uczelniane projekty – odbębnić i zapomnieć? – cz.2a

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.

Strona główna sklepu z rozwiniętym pierwszym działem Sklep muzyczny - wybrany jeden album bez okładki
Sklep muzyczny - raporty dot. zamówień Sklep muzyczny - wybrany album z okładką

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]