nagroda turinga za rok 2006 – po raz pierwszy dla kobiety

począwszy od 1966 roku, corocznie przyznawana jest nagroda dla osoby lub osób które odznaczyły się wkładem z szeroko pojętą informatykę.

nagroda ta, traktowana jako informatyczny nobel, była wręczana już 40 razy i za każdym razem lauretem byli faceci. znani. świeni fachowcy – z bardziej znanych nazwisk trzeba wymienić knutha, dijkstrę, edgara codda, niklausa wirtha, kena thompsona i dennisa ritchiego, team rsa (rivest, shamir, adleman) czy niedawno panów cerfa i kahna – twórców internetu jako takiego – protokołów i pomysłów.

w 2006 roku po raz pierwszy uhonorowana została kobieta – frances allen. frances pracowała od 1957 roku w ibm'ie i brała udziała w wielu niesamowitych projektach jak choćby pisanie pierwszych kompilatorów (fortran), tworzenie oprogramowania na blue gene'a czy softu wywiadowczego dla nsa.

mimo, że od 2002 roku jest na emeryturze nadal aktywnie się udziela i zachęca młode pokolenia kobiet do wybrania swojej ścieżki kariery.

dla zainteresowanych – nagroda poza wielkim “szacunem" i “joł" ze środowiska obejmuje $100,000.

narzekanie

znowu się rozchorowałem.

na dodatek muszę pisać dokumentację do bazy. piszę w docbooku bo jest zasadniczo fajny. zasadniczo. ktoś wie jak w nim zrobić tabelkę z nagłówkiem pionowym a nie poziomym? nie chodzi mi o kierunek czcionek. po prostu chcę mieć “header-column" a nie “header-row".

a do tego nie mam na nic czasu. ilość nieprzeczytanych newsów w akregatorze przekroczyła 5000.

no nic. może w weekend się trochę “odkuję". jak tak, to zarzucę was lekko nieświeżymi newsami. ale za to w dużej ilości 🙂

drobny błąd

a dziś napiszę o tym jakim to łosiem można być. niechcący.

na potrzeby jednego z projektów napisałem własnego orm'a (object-relationship mapper). nie znacie? takie cos co pozwala widziec rekordy z tabel jako obiekty. ogólnie – każdy orm jest bez sensu. mój tym bardziej, ale służył do prostego celu – uproszczenia robienia eksportów.

działał.

do czasu.

ostatnio na jednej z maszyn eksporter zaczął zżerać cały ram. calutki. i wywalać maszynę. usiadłem do debugowania. i oto co ujrzałem:

...
sub _table { my $self = shift; return $self->{ 'table_name' } }
sub _db    { my $self = shift; return $self->{ 'db' } }
sub _log   { my $self = shift; return $self->{ 'log' } }
sub _refresh {
my $self   = shift;
my $sql    = sprintf 'SELECT * FROM %s WHERE id = ?', $self->_table;
my $record = $self->_db->get_single_record( $sql, $self->{ 'data' }->{ 'id' } => 'INT8' );
if ( $record ) {
$self->{ 'data' }    = $record;
$self->{ 'fetched' } = 1;
return;
}
$self->log->critical(
"Cannot refresh record data from table " . $self->_table . " for id = " . $self->{ 'data' }->{ 'id' } );
croak( "DB Error" );
}
sub _get {
my $self = shift;
my ( $field ) = @_;
$self->_refresh unless $self->{ 'fetched' };
return $self->{ 'data' }->{ $field };
}
sub AUTOLOAD {
my $self   = shift;
my $method = $AUTOLOAD;
$method =~ s/.*:://;
return unless $method =~ m{ \A [a-z][a-z0-9_]* \z }xmso;
return $self->_get( $method );
}

zasada działania bardzo prosta – jeśli mam obiekt klasy dziedziczącej z tego orm'a, i wykonam na nim metodę:

$obiekt->jakies_pole

(gdzie jakies_pole nie jest nazwa istniejacej metody), to request trafi do autoloada, który wywoła _get. _get sprawdzi czy obiekt załadował z bazy dane. jak tak – zwróci odpowiednie pole i po sprawie.

a co jeśli nie?

wtedy kod trafia na _refresh(). refresh odczytuje cały rekord z bazy w oparciu o id (które musi być). fajne.

jedno pytanie: co się stanie gdy rekordu w bazie nie będzie?

tradycyjna odpowiedź: kod zaloguje informacje o błędzie i wykona croak(). czyli taki die.

ale nie. niestety. złośliwy los i brak dobrych oczu spowodował, że napisałem $self->log->(), podczas gdy obiekt loggera jest dostępny przed $self->_log.

efekt? metody log nie ma. trafiamy na autoloada. autoload odsyła do _get'a, _get do _refresha. _refresh znowu nie znajduje rekordu, więc … i kółeczko się zamyka.

nieskończona rekurencja, 3 giga zużytej pamięci, kilka godzin pracy paru osób. przez brak jednego “_".

a czemu o tym piszę? abym pamiętał. i sprawdzał kod. i bym miał okazję się pochwalić jakie “fajne" błędy potrafię wygenerować, a potem wykryć. i pochwalić “perl -d" – debugger jest wkurzający, mało sympatyczny. i ratuje d… jak oczy zawiodą.

aha. i jak fajnie wygląda “T" pod debuggerem po np. 50 przebiegach tej rekurencji 🙂 (T == stack trace).

miejski samochód

massachusetts institute of technology – jedna z najbardziej znanych uczelni technicznych na świecie. i do tego miejsce które co chwilę ma nowe fajne projekty badawcze.

tym razem badacze z mit wymyślili nowy samochód. miejski. na czym polega jego “nowość"? na modelu używania, ilości zajmowanego miejsca itd.

ponowie opracowali samochód 2 osobowy który można “składować" jak wózki w supermarkecie. działa na silnik elektryczny i ma interesujący model działania/używania. mianowicie nie miałby to być samochód do kupienia. idea jest taka, że miasto kupuje ich dużo, rozmieszcza w potrzebnych miejscach. a użytkownicy? podchodzą do dowolnego samochodu, wsiadają i jadą. płacą kartą przy użyciu. minus – muszą odstawić na miejsce. niekoniecznie to z którego wzięli – wystarczy dowolny “parking" tych samochodzików.

nie jest to na pewno samochód na długie podróże. ale na proste “podjechanie do klienta" czy “skoczenie do sklepu" – może się okazać wystarczający. pomysł ciekawy.

na stronie boston globe można znaleźć artykuł, ale co ciekawsze – flashową prezentację tego jak to ma działać.

porównanie implementacji ruby’ego

dzięki znajomemu (hi tmarc) dowiedziałem się o ciekawym tekście. autor porównał w nim wydajność kilku (41) testów w różnych implementacjach języka ruby.

udział wzięły kanony:

  • ruby 1.8 (na linuksie i na windows vista
  • ruby 1.9

ale także wersje mniej standardowe:

  • jruby
  • gardens point ruby .net (wersja beta, na windows vista)
  • rubinius
  • cardinal

porównano wydajność każdej z implementacji w stosunkdu do złotego wzorca – czyli 1.8 na linuksie.

efekt? no cóż. 1.9 zdecydowanie rządzi. ruby 1.8 na linuksie ma drugie miejsce. wersja na windowsach jest trochę wolniejsza, ale (co ważniejsze) wywala się na 2 testach!

pozostałe implementacje: wolno i kiepsko. “hitem" jest cardinal – większość testów zakończona błędem, dwa trwały powyżej  15 minut i zostały ręcznie ubite (te testy były “zrobione" przez 1.8 w czasach 9.5 i 0.5 sekundy!). choć trzeba przyznać, że w 3 testach cardinal osiągnął najlepszy wynik. wydajnościowo gorszy był rubinius, ale on miał mniej errorów (“ledwie" koło połowy).

można spojrzeć by rozwiać złudzenia, lub nauczyć się czegoś z testów.

nowa technologia kości ram

ibm ogłosił, że opracowali właśnie nową technologię produkcji kości ram.

nowe kości są rozwinięciem idei i metody produkcji dram, ale prędkością zbliżone do sram. czyli około 2 krotnie szybsze od obecnych kostek.

sram od zawsze był szybszy, ale te kości były sporo większe niż standardowe dramy. więc się nie przyjmowały w standardowych zastosowaniach. teraz jednakże – gdy nowy dram ma osiągnąć wydajność sram, można liczyć na spory przełom.

poza zwiększoną szybkością nowe kości mają być też pojemniejsze. trzykrotnie!.

podsumowując: 3 razy więcej ramu, działającego 2 razy szybciej. ciekawe tylko kiedy to wejdzie do seryjnej produkcji i sprzedaży – na razie ibm szacuje, że pierwsze handlowe kości pojawią się w 2008 roku i będą to pamięci serwerowe. inne typy pamięci pojawią się później. a kiedy do laptopów?