czy twoja komórka jest ładna?

pamięć, aparat fotograficzny, gry, emaile itd, itp.
to standard.
aby pojawił się popyt na komórkę musi ona mieć w sobie “to coś". tym czymś nie musi być jakaś nowa funkcja. to może być po prostu estetyka, wygoda, cokolwiek.
ludzie z fosfor gadgets wybrali 10 najładniejszych komórek na świecie.
nie znajdziecie tam komórki wysadzanej brylantami czy zrobionej ze złota. one nie są ładne. one są ostentacyjne.
komórki ładne są po prostu ładne.
pewnym problemem jest fakt, że część z nich nie jest jeszcze w produkcji (jak chociażby mój faworyt – black diamond), albo są, ale są dostępne tylko w określonych krajach azji (japonia, korea).
ale popatrzeć zawsze można. i zobaczyć, że na świecie robi się fajne telefony które niekoniecznie muszą wszystkie wyglądać tak samo.
uwaga końcowa: 3 telefony (w tym numer 1) są tej samej firmy: kddi. przyznajcie się – kto z was słyszał o niej kiedykolwiek?

jak się przygotować do rozmowy o pracę

ostatnio na jednym z interesujących technicznych blogów pojawił się ciekawy wpis.
zawiera on listę 50 najczęściej zadawanych pytań. zadawanych podczas rozmów kwalifikacyjnych. wpis ten zgrał mi się w czasie z tym o czym pisałem niedawno – wskazówkach guya kawasakiego nt. pisania cv.
co ciekawe – cv kobiety od dzisiejszego bloga (nazywa się bhuvana muruganandam (albo sundaramoorthy, jak pisze elf), nie ma szans bym to napisał nie przepisując z czegoś, więc nazywam ją po prostu kobiętą) – ma 14 stron!
tym niemniej, lista pytań i tego jak się na nie przygotować jest dosyć interesująca dla każdej osoby. no chyba, że uważasz, że nigdy więcej nie będziesz brał udziału w rozmowie kwalifikacyjnej 🙂

wydawało mi się, że znam się na linuksie…

naprawdę tak było. uważałem, że wiem co i jak i gdzie.

a potem dostałem szybką serię:

  1. w inode'ach są przechowywane 3 czasy. wymień je!
    no to raczej proste – atime, ctime, mtime
  2. kiedy jest modyfikowany mtime?
    no … kiedy się plik zmodyfikuje. jego zawartość znaczy się.
  3. kiedy jest zmodyfikowany atime?
    przy dostępie/odczycie z pliku.
  4. to kiedy dokładnie? przy open() czy dopiero przy read()?
    ekhem. atime to “access time" czyli przy open()
  5. kiedy jest modyfikowany ctime?

i to zasadniczo był koniec.

poczułem się jakbym grał z tmarciem w urban reign i dostał magical combosa za 70% zdrowia.

czemu? a uważacie, że odpowiedziałem dobrze? (celowo nie podałem odpowiedzi na pytanie 5, bo to dłuższa sprawa).

pytanie 1 było proste. i odpowiedziałem prawidłowo.

pytanie numer 2. – źle. nie trzeba modyfikować zawartości. zawartość może pozostać ta sama. wystarczy, że poszedł write() do tego pliku. to nawet jest logiczne – po co kernel miałby porównywać to co było w pliku z tym co jest. ale odpowiedź jest zła.

pytanie number 3 – odpowiedź nieprecyzyjna, więc dostałem kontrę – pytanie 4.

które to pytanie zwaliłem. atime zmienia się przy faktycznym odczycie danych. syscall read().

no ale ctime to była większa porażka.

najpierw uparłem się, że ctime to “creation time". co jest bzdurą. potem sobie na szczęście przypomniałem, że to jednak change time.

no a kiedy jest aktualizowane?

stwierdziłem, że gdy aktualizowany jest inode.

i to jest nieprawda.

takie wyjaśnienie ctime'a znajdziecie wszędzie. włącznie z wikipedią (więc nie tylko ja żyję w niewiedzy, ale to marne pocieszenie).

sprawdzenie tego kiedy dokładnie zmienia się ctime zajęło mi trochę czasu. mnie i rozmówcom z dwóch kanałów ircowych (#perl i #postgresql), plus grep na źródłach kernela itd.

ctime zmienia się wtedy gdy zmienia się mtime *i dodatkowo* wtedy gdy zmieniają się inne niż *time wartości w inodzie.

kilka przykładów dla lepszego zrozumienia:

  • chmod i chown pliku zmieniają inode'a, więc zmienia się ctime
  • zmodyfikowanie pliku (dopisanie linijki) – zmienia mtime i zmienia wielkość pliku, więc zmienia się też ctime
  • zmodyfikowanie pliku (bez zmiany wielkości) – zmienia mtime więc zmienia też ctime.

to co podałem powyżej, może zasugerować, że prawdą jest, że ctime zmienia się przy zmianie danych w inodzie. ale nie.

wystarczy otworzyć plik do odczytu, odczytać coś. atime się zmienia, a ctime nie.

czyli – nie każda modyfikacja inode'a (atime jest w inodzie) modyfikuje ctime!

co zabawne. w kernelu w wersji 2.6.11 (pewnie w starszych też, i w kilku nowszych możliwe, że też), funkcja która aktualizuje mtime ma dodatkowy argument: int ctime_too. który jest potem sprawdzany i ctime jest modyfikowane tylko gdy ctime_too jest ustawione.

ale! w całych źródłach 2.6.11 (które przeszukał infi z #postgresql) wszystkie wywołania tej funkcji (inode_update_time) mają ctime_too ustawiany na 1!.

sprawdziłem źródła do 2.6.17.9 – w nich funkcja ta zmieniła nazwę na file_update_time i “zgubiła" drugi argument.

wnioski na koniec:

  1. kiedy uważasz, że wiesz już sporo na jakiś temat, pojawi się ktoś kto ci udowodni, że nie wiesz podstaw.
  2. teraz ja muszę wymyśleć jakieś pytanie by go (tego od pytań o czasy) zagiąć. jakieś pomysły?

fbi wyrzuciło 170 milionów dolarów

jeszcze przed atakiem z 11 września 2001, fbi wiedziało, że używa mocno przestarzałej technologii. centralny system komputerowy pracował tylko i wyłącznie w trybie tekstowym, nie pozwalał na wgrywanie zdjęć czy skanów. dodatkowo – nie każdy agent miał swojego kompa – pracowali wymiennie.

system był niewygodny i niewiele dawał. więc spora część agentów nie używała go w ogóle, polegając na dokumentacji papierowej i sekretarkach.

na bazie tego została podjęta decyzja o zamówieniu nowego, zintegrowanego systemu komputerowego do śledzenia spraw, no i sprzętu.

software został zamówiony w firmie saic. niezbyt znanej, ale dosyć dużej – firma te realizuje praktycznie tylko i wyłącznie zlecenia rządowe.

prace postępowały.

w 2003 roku, mniej więcej na miesiąc przed końcem projektu, nowy szef pionu technicznego – zalmai azmi, poprosił o raport nt. stanu systemu.

to co dostał go przeraziło. system nie był gotowy nawet w połowie, nie działały nawet podstawowe funkcje.

azmi napisał raport do przełożonych. termin oddania oprogramowania został przesunięty, przeprowadzono dwa niezależne audyty. wynik audytów?

  • agenci nie będą w stanie zabrać kopii dokumentów spraw “w teren"
  • nie ma funkcji typu “bookmarkowanie" czy historia przeglądanch spraw/dokumentów. a bez tego nawigacja po milionach spraw, opisów, zdjęć, skanów będzie praktycznie niewykonalna.
  • system nie potrafi prawidłowo sortować danych!
  • fbi zamierzało odpalić nowy system w skali całego kraju jednocześnie, jedynie z minimalnymi testami. ze względu na brak planu zapasowego zasadniczo zablokowałoby to pracę całego fbi w przypadku jakiejkolwiek awarii.
  • system nie zawierał funkcji archiwizujących – pojedyncza awaria mogła zaowocować nieodwracalnymi stratami danych
  • kod był niekompletny i nieudokumentowany
  • projekt zawierał błędy na każdym poziomie – od kontraktu, przez analizy, projekt techniczny aż po źródła

w 2004 roku projekt został finalnie zarzucony. został rozpisany następny (na jeszcze większą kwotę) i on aktualnie trwa. wykonawcą jest tym razem lockheed martin corp. a saic aktualnie oczekuje wyników kolejnego audytu na podstawie którego zostanie podjęta decyzja czy fbi ma wystąpić do sądo o zwrot kosztów.

oczywiście wina jest bo obu stronach – fbi nie dopilnowało, zmieniało założenia, przedstawione na początku założenia się zmieniały. tymniemniej postawa saic wydaje mi się dodatkowo naganna – akceptowali transze płatności, mimo, że wiedzieli dobrze, że projekt ma koszmarne opóźnienie – wychodząc z założenia, że to fbi powinna tylko dbać o powodzenie. zatrudniali do wykonania zadań po 200 programistów, mimo, że (zgodnie z tym co jeden z nich powiedział) wystarczyłoby “kilka tuzinów".

na koniec pozostaje mi się poniekąd cieszyć, że tego typu akcje są nie tylko domeną polski i informatyzacji polskich urzędów. na świecie – nawet w tych najbardziej zinformatyzowanych państwach, też tak się dzieje. tylko to chyba nie jest za dobrze.

używanie tajnych haseł w automatach

co jakiś czas pojawia mi się potrzeba użycia “tajnego" hasła w programie który ma działać w miarę automatycznie.

przez “w miarę" rozumiem, że mam kontrolę nad tym kiedy i jak go uruchamiam.

ostatnio pojawił mi się ten problem gdy chciałem napisać program który wykrywa zmiany na moim koncie w banku (mbank). wolałem (z oczywistych przyczyn) nie:

  • wpisywać konta i hasła do kodu programu
  • wpisywać konta i hasła do pliku konfiguracyjnego
  • podawać tych danych jako zmienne środowiskowe
  • podawać tych danych jako parametry wykonania

z drugiej strony – soft miał działać bez mojej dalszej ingerencji.

na początku chciałem by to był cron. ale z zastrzeżeniami z punktów powyżej chyba nie da się crona napisać.

więc stwierdziłem – nie może być cron? ok. niech będzie daemon.

co więc można zrobić?

program pyta się użytkownika przy uruchomieniu o dane (konto/ hasło). potem się loguje na stronę mbanku. jeśli proces logowania sie nie uda, trudno , program wypisuje błąd, i się kończy.

jeśli jednak się uda, to program kasuje z pamięci zawartość numeru konta i hasła, po czym przechodzi w tło i cyklicznie odpytuje mbank o saldo – korzystając z cookie.

oczywiście nadal istnieje ryzyko, że ktoś “ukradnie" mi cookie, ale ponieważ cookie są przechowywane w pamięci to jest to dosyć trudne.

pewnym utrudnieniem jest fakt, iż polegamy na cookie, gdyż cookie ma dosyć krótką żywotność. co oznacza, iż muszę cyklicznie co minutę odświeżać dane. testowanie konta co 5 minut wymagałoby już trzymania w pamięci hasła i numeru konta, co staje się potencjalnie niebezpieczne.

soft oczywiście nie jest idealny, ale może komuś z was się do czegoś przyda.

a może wskażecie mi błędy w moim rozumowaniu 🙂

darpa pracuje nad nowym internetem?

internet2? nie. to już teraźniejszość.

twórcy oryginalnego internetu – amerykańska agencja darpa, pracuje nad projektem który może stać się zalążkiem następnego internetu. i znowu źródłem pomysły są wojskowi.

projekt ma obejmować tworzenie sieci bezprzewodowych zgodnych z ideą manet (punkty w sieci dynamicznie się łączą i przełączają). dodatkowo zostało to wzbogacone o elementy sieci p2p, zaawansowaneo szyfrowania i tzw. “cognitive radio" – dynamiczne, automatyczne modyfikowanie parametrów transmisji tak aby nie interferować z innymi źródłami.

całość ma być całkowicie automatyczna i bezpieczna – zarówno jako “zabezpieczona przed podsłuchem" jak i “zabezpieczona przez zniszczeniem". w przeciwieństwie do zwykłych sieci wifi nie będzie centralnego “access pointa".

jeśli chodzi o zastosowania, projekt prowadzony przez darpa obejmuje sieci semantyczne i całą koncepcję “knowledge base" (baz wiedzy). tym niemniej można założyć, że gdy projekt zostanie zakończony i wdrożony (pierwsze zastosowania to uruchamianie sieci w miejscu działań wojskowych), po jakimś czasie znajdzie zastosowanie w cywilu – tym razem już do dowolnych celów.

interesujące jest także to, że koncepcja nad którą pracuje darpa, obejmuje także inteligentne (ekhem) cache'owanie informacji na poziomie protokołów sieciowych. kiedy ta technologia stanie się publicznie i powszechnie dostępna – nie wiadomo, ale warto śledzić nowinki, bo można zobaczyć czym będziemy przesyłać emaile za kilka lat.

jak sprzedać siebie?

dosyć znana postać – guy kawasaki, napisał w swoim blogu co zrobić by dostać robotę w dolinie krzemowej.

opis jest mocno konkretny – i (w/g mnie) nie tyczy się tylko i wyłącznie doliny, ale dowolnego innego miejsca – w tym i firm w polsce. polecam przeczytanie, bo może zmodyfikuje to wasze podejście do pisania c.v., czy przygotowywania sie do rozmów o pracę.

google office. poniekąd.

od wczoraj writely przyjmuje już nowych użytkowników.

jakbyście nie kojarzyli – writely to edytor tekstu webowy, kupiony przez google'a jakiś czas temu.

w chwili obecnej google ma już:

  • program pocztowy
  • edytor tekstu
  • arkusz kalkulacyjny
  • kalendarz
  • poniekąd bazę danych

dużym brakującym składnikiem pozostaje soft do prezentacji. kiedy i który zostanie kupiony? a może to napiszą samemu?

tesla roadster – wieści z frontu i filmik

samochód którym się ostatnio zachwycam – tesla roadster miał swój oficjalny premierowy pokaz 19 lipca. tuż po pokazie 3 osób zapisało się na te samochody. teraz lista osób oczekujących ma już 100 osób – a jak na razie tylko kilka egzemplarzy zostało ukończonych.

jako dodatek – mały filmik (z reklamamy przed filmem niestety) gdzie widać jak to cudeńko jeździ.

nowy system replikacyjny do postgresa i nie tylko!

enterprisedb, firma której przedstawiać chyba nie muszę, od wczoraj oferuje swoje rozwiązanie replikacyjne: EnterpriseDB Replication Server.

co to i co potrafi?

na pierwszy rzut oka to co slony:

  • asynchronicznie
  • master + multi-slave

do tego niby jakieś narządka tylko replication console.

diabeł (a w tym przypadku raczej anioł) tkwi w szczegółach.

po pierwsze – do rzeczonego silnika replikacyjnego jest coś o nazwie: “Database Pooling Connection Framework". z tego co zrozumiałem z jednozdaniowego opisu, wynika, że zarządza to rozrzucaniem zapytań po bazach master/slave. i to w sposób w miarę inteligentny – wykrywając zapytania modyfikujące?!

po drugie – ten silnik replikacyjny pozwala replikować między postgresem i enterprisedb – co jest oczywiste, bo enterprisedb to też postgres. ale potrafi też replikować z/na oracle'a!

jest to o tyle dodatkowo ciekawe, że enterprisedb (firma) oferuje też pakiet do postgresa dla zachowania dużej kompatybilności zapytań. idea jest taka, że zapytania z oracle'a, działają na postgresie (a dokładniej na enterprisedb).

czyli całośc pozwala na zrobienie live migracji na postgresa a potem przepięcie aplikacji klienckich, albo ich część, na bazę która jest sporo tańsza!
całość pewnie będzie trochę kosztowała, ale może się okazać interesującą alternatywą dla slony'ego w zastosowaniach bardziej komercyjnych.