Author: depesz

google zmieni świat?

nie, nie chodzi o kolejny produkt firmy z mountain view.

na cnn.com pojawił się artykuł głoszący interesującą opinię: google jest za mądre.

zaczęło się od tego, że autor artykuły spotkał się z człowiekiem który założył jakąś tam firmę która została przejęta przez google'a. wrażenia – wszyscy są niesamowicie inteligentni. cytując: “przez 10 dni pracy tam nie spotkałem nikogo głupiego! to dziwne". czy wydaje się wam to zabawne? pomyślcie o waszych miejscach pracy!

google chce zatrudniać best of the best of the best. i zatrudniają. ale to oznacza, że pojawia sie problem. na każdym spotkaniu – w kafeterii, sali konferencyjnej czy gdziekolwiek spotykają się ludzie przyzwyczajeni do tego, że są naj-. a tu nie. tu zawsze jest ktoś lepszy. to frustruje. oczywiście fajnie jest pracować w mocnym zespole, ale praca w czymś tak topowym może doprowadzić do jakichś urazów – kompletny brak możliwości zaspokojenia ludzkiej cechy “bycia podziwianym". jak mam być podziwiany za urodę i męskość w towarzystwie brada pitt'a, clooney'a i fabia? no way!

autor artykułu przewiduje, że część (spora część) z ludzi z google odejdzie. będą mieli pieniądze, wiedzę, rewelacyjne kontakty i ma mało lat by iść na emeryturę. co zrobię? założą kolejne firmy – startupy!

jako przykład autor podaje paypala. firma ta w momencie przejęcie przez ebaya pozbyła sie olbrzymiej ilości (kilkudziesięciu) super inteligentnych gości. z pieniędzmi. efekt? linkedin. youtube. a to tylko 2 topowe przykłady. do tego dochodzą inne firmy które odniosły sukces np. na rynkach lokalnych – jak np. fenomenalny yelp.

jeśli takie było “pokłosie" po paypalu, to jakie będzie po google'u? zmieniające oblicze świata.

nowy (?) interesujący load-balancer

poniekąd przypadkiem natknąłem się na informację o nowym (albo i nie za nowym), mocno interesującym programie do load-balancingu (z dodatkami).

program nazywa się perlbal, jest w perlu i jest (lub był) używany przez kilka sporych serwisów: livejournal, sixapart, wikipedia. szczegółów nie znam, ale na pewno potestuję i dam wam znać jak będę miał jakieś wyniki.

z ciekawostek mogę pokazać wpis na japońskim blogu (po japońsku) z którego wynika, że perlbal jest szybszy od lighttpd, albo wpis na livejournalu w/g którego wikimedia/wikipedia wybrały perlbala zamiast squida.

aha – właśnie sprawdziłem – wikipedia jest squidowana (przynajmniej w/g nagłówków http) – ale tak czy inaczej wygląda to interesująco.

wracamy na księżyc

ostatni raz człowiek był na księżycu w 1972 roku – z wyprawą apollo 17. od tamtej pory co prawda latamy w kosmos, ale już nie schodzimy na księżyc.

nasa ogłosiła właśnie wejście w życie planu w/g którego do 2024 na księżycu ma powstać stała baza kosmiczna.

plany są ambitne:

  • 2009 – rozpoczęcie testów nowych pojazdów mających zastąpić wysłużone wahadłowce
  • 2010 – zaprzestanie eksploatacji wahadłowców
  • 2014 – pierwsze loty załogowe (pierwsze nowymi pojazdami)
  • 2020 – lądowanie na księżycu
  • 2024 – baza na księżycu ukończona i funkcjonalna.

całość ma pomóc w późniejszych planach załogowego lotu na marsa i dalszym podbojom kosmosu.

co z tego wyjdzie? ciężko powiedzieć. budżet przedsięwzięcia jest olbrzymi (określono go jako: setki miliardów dolarów) – na tyle, że sama nasa go nie udźwignie i stacja na księżycu ma być kooperacją – usa, europa, rosja i japonia. udział chińczyków jest mało prawdopodobny.

dlaczego linuks nie odniesie sukcesu

artykuł na ten temat napisał w serwisie osnews niejaki dmitri czarkoff – jeden z użytkowników (i chyba developerów) openbsd i freebsd.

czemu nie odniesie sukcesu? no cóż – nie chcę zdradzać treści – po prostu przeczytajcie.

teza na pewno jest kontrowersyjna, ale muszę przyznać, że “coś w tym jest" – co prawda nie wiem czy rozwiązanie kwestii przyniesie rok 200x, ale może się to okazać bliższe niż myślimy.

unikatowość nazw użytkowników

na potrzeby jednego z projektów miałem zaprojektować bazę. jednym z elementów bazy była tabelka z danymi użytkowników. ponieważ zbiór danych był spory i do tego zmienny, tabelka z użytkownikami została mocno uproszczona, ale za to zostały dodane tabelki na dane dodatkowe.

finalnie – tabelka z użytkownikami wyglądała mniej więcej tak:

CREATE TABLE users (
id         BIGSERIAL  ,
username   TEXT        NOT NULL DEFAULT '',
password   TEXT       ,
registered TIMESTAMPTZ NOT NULL DEFAULT now(),
active     BOOL        NOT NULL DEFAULT 'true',
PRIMARY KEY (id)
);
CREATE UNIQUE INDEX ui_users_username ON users (username);

małe, proste i łatwe. było. ale potem pojawiły się zmiany.

zmiana numer 1: klient którego konto zostanie wyłączone może założyć nowe konto o identycznej nazwie.

oops. username przestanie być unikalny? a może robić tabelę na dane archiwalne/usunięte? niestety – danych jako takich nie mogę kasować – muszą zostać w bazie.

krótki research pokazał, że przenoszenie danych do innych tabel (archiwum) nie wchodzi w grę – musiałbym zrobić kopię całej bazy jako archiwum. za dużo roboty. może coś prostszego?

pokombinowałem, przypomniałem sobie rozmaite rzeczy i zrobiłem:

DROP INDEX ui_users_username;
CREATE UNIQUE INDEX ui_users_username ON users (username) WHERE active = TRUE;

co to robi? to proste – nadal mam indeks unikalny, ale tylko aktywnych kont. konta nieaktywne nie są indeksowane w ogóle, więc także nie są objęte limitem unikalności. całość działa ładne. do czasu.

zmiana numer 2: nazwy kont (ich unikalność) powinny nie pozwalać na dwa konta – typu “depesz" i “Depesz".

no, to to trywiał – mały trigger “BEFORE INSERT OR UPDATE" który mi username lowercase'uje i po sprawie. a jednak nie. nazwa użytkownika ma się wyświetlać tak jak on sobie zażyczył. jak sobie przy rejestracji wpisał “Depesz" to ma mu się tak wyświetlać. ale nie powinnismy dopuścić do rejestracji “depesz"‘a. oraz powinniśmy umożliwić mu zalogowanie sie zarówno jako “Depesz" jak i “depesz".

oops część 2. kombinuję. krok numer 1 – dodatkowe pole które trzyma nazwę konta w postaci “tak jak user podał", a username będę triggerował do lowercase'a. ale to jest brzydkie. i duplikuje mi dane. myślałem nad tym jakiś czas gdy nagle mnie olśniło: indeksy funkcyjne. wystarczy:

DROP INDEX ui_users_username;
CREATE UNIQUE INDEX ui_users_username ON users ( LOWER(username) ) WHERE active = TRUE;

i po sprawie:

# INSERT INTO users (username) VALUES ('depesz');
INSERT 0 1
 
# INSERT INTO users (username) VALUES ('Hubert Lubaczewski');
INSERT 0 1
 
# INSERT INTO users (username) VALUES ('hubert lubaczewski');
ERROR:  duplicate KEY violates UNIQUE CONSTRAINT "ui_users_username"
 
# SELECT * FROM users;
id |      username      | password |          registered           | active
----+--------------------+----------+-------------------------------+--------
1 | depesz             | [NULL]   | 2006-12-05 23:16:52.52406+01  | t
2 | Hubert Lubaczewski | [NULL]   | 2006-12-05 23:16:58.370124+01 | t
(2 ROWS)

podsumowując – mam tabelkę która trzyma bazowe informacje o użytkownikach, pilnując tego by mógł być tylko 1 aktywny o tej samej nazwie – gdzie “ta sama" jest sprawdzanie niezależnie od wielkości liter. i do tego nie zmieniamy danych wpisanych przez usera – i jeśli zażyczy sobie (rejestrując się) jakichś różnych wielkości liter – tak też to zrobimy i tak mu wyświetlimy. życie jest piękne.

osdl zwalnia pracowników?

osdl – open source development labs – konsorcjum dużych firm wspierających linuksa – podobno zwalnia właśnie dużą część swoich pracowników – praktycznie eliminując zatrudnienie w swoich biurach w oregonie.

dla przypomnienia – osdl jest miejscem pracy (i płacy) linusa torvaldsa – twórcy systemu linux.

informacja ta nie została w żaden sposób oficjalnie potwierdzona, ale gdyby okazała się prawdą mogłoby to stawiać pod znakiem zapytania ciągłość pracy linusa nad rozwojem linuksa.