nowy lancer

uwielbiam mitsubishi. chcę mieć lancera evo. mam lancera kombi. to może tłumaczyć czemu dosyć mocno zaniepokoiły mnie informacje o tym, że mitsubishi motors ma problemy finansowe.

natomiast dziś przeczytałem, że wyciekły zdjęcia nowego lancera – jeszcze nie evo (znanego także jako evo x), ale zwykłego, cywilnego.

i wiecie co wam powiem? jest śliczny. to ma być model na rok 2008 – więc jeszcze chwilę go nie będzie. ale już ostrzę sobie zęby na to by go kupić – evo jest drogie, ale ten samochód też jest super – i za zdecydowanie mniejsze pieniądze.
lancer_06.jpg

lancer_05.jpg

lancer_04.jpg

lancer_03.jpg

lancer_02.jpg

lancer_01.jpg

nowa, interesująca, usługa sieciowa

co można wymyślić jeśli chodzi o zakupy w sieci? sklep. pasaż handlowy. system ogłoszeniowy. system aukcyjny. porównywarkę cen.

a może coś jeszcze?

wired napisał o nowym typie usług – porównywarka cen działająca via feed rss'owy.

zasada jest prosta – informuję serwis co mnie interesuje, a on śledzi zmiany cen tego produktu w znanych mu sklepach. i jak coś się zmieni – daje ci znać rss'em.

proste i efektywne. są już przynajmniej 3 serwisy zajmujące się tego typu usługami:

na razie – żaden z nich nie informuje o cenach w polsce. ale zakładam, że niedługo pojawi się jakiś polski klon oferujący zbliżoną funkcjonalność.

piosenki podkładem dla seksu

tak aby zakończyć dzień jakąś lżejszą informacją 🙂

onet podał, że yahoo przeprowadziło badanie nt. tego które piosenki internauci uważają za najlepszy podkład muzyczny dla seksu.
lista nie budzi zaskoczeń – no, może dziwi niska pozycja je t'aime, no ale w sumie … 🙂

lista:

  1. Marvin Gaye – Sexual Healing
  2. U2 – With Or Without You
  3. Barry White – My First My Last My Everything
  4. Serge Gainsbourg & Jane Birkin – Je T'aime
  5. Chris Isaac – Wicked Game
  6. Al Green – Let’s Stay Together
  7. Phyllis Nelson – Move Closer
  8. INXS – I Need You Tonight
  9. Madonna – Justify My Love
  10. Kylie Minogue – Slow

może kiedyś je wszystkie wystawię w mp3 – choć nie wiem co na to eo – hostują mnie, a dodatkowy ruch i zainteresowanie ze strony riaa mogłoby być niemile widziane 🙂

outsourcing na świecie

w najnowszym numerze forbes'a jest artykuł o tym jak to polska staje się centrum outsourcingowym. niby mamy tanią siłę roboczą, i olbrzymie ilości firm się do nas przenoszą byśmy wykonywali ich pracę. idea jest fajna. a jaka jest rzeczywistość?

businessweek opublikował listę 10 największych miast – największych jęśli chodzi o outsourcing. i co? i nie ma nas na żadnej z tych pozycji. za to są takie potęgi jak bukareszt w rumunii i praga w czechach. eh. i komu tu wierzyć?

niesamowity stół

dzięki koledze z pracy zobaczyłem niesamowity stół. co prawda jest on przeznaczony do instalacji na łodziach, jest drogi i nie stać mnie na niego. a na stronie producenta jest informacja:

Please understand that this is an extremely special piece of furniture, of exceptional quality and design – it is not for everyone by a very very long way and can only be afforded by the lucky few of us with exceptional wealth.

to i tak strasznie mi się podoba. kiedyś go sobie kupię 🙂

currval i problemy z selectami

jak może wiecie w postgresie jest funkcja currval() zwracająca ostatnio nadane id z podanej sekwencji.

rozpatrzmy prosty przypadek:

# CREATE TABLE test (id serial PRIMARY KEY, pole int4);
CREATE TABLE
# INSERT INTO test (pole) SELECT * FROM generate_series(1, 10000);
INSERT 0 10000
# SELECT COUNT(*) FROM test;
 COUNT
-------
 10000
(1 ROW)
# SELECT currval('test_id_seq');
 currval
---------
   10000
(1 ROW)

wszystko wygląda ok. więc sprawdźmy jeszcze jeden insert mały:

# INSERT INTO test(pole) VALUES (12313);
INSERT 0 1
# SELECT currval('test_id_seq');
 currval
---------
   10001
(1 ROW)

nadal wszystko ok. i teraz:

# SELECT * FROM test WHERE id = currval('test_id_seq');
  id   | pole
-------+-------
 10001 | 12313
(1 ROW)
TIME: 93.358 ms

działa, ale coś wolno, sprawdźmy:

# EXPLAIN analyze SELECT * FROM test WHERE id = currval('test_id_seq');
                                            QUERY PLAN
--------------------------------------------------------------------------------------------------
 Seq Scan ON test  (cost=0.00..200.02 ROWS=1 width=8) (actual TIME=64.375..64.379 ROWS=1 loops=1)
   FILTER: (id = currval('test_id_seq'::regclass))
 Total runtime: 64.431 ms
(3 ROWS)

seq scan? sprawdźmy więc ręcznie podaną wartość:

# EXPLAIN analyze SELECT * FROM test WHERE id = 10001;
                                                   QUERY PLAN
----------------------------------------------------------------------------------------------------------------
 INDEX Scan USING test_pkey ON test  (cost=0.00..8.02 ROWS=1 width=8) (actual TIME=0.029..0.033 ROWS=1 loops=1)
   INDEX Cond: (id = 10001)
 Total runtime: 0.086 ms
(3 ROWS)

hmm .. tu jest dobrze. skąd seq scan? aby nie przynudzać z każdym zapytaniem, powiem tyle, że nie jest to kwestia błędnych typów czy czegoś tak oczywistego. problemem jest zmienność funkcji.

dokładniej: funkcja currval() jest zadeklarowana jako “volatile" – co oznacza, że jej wynik ma prawo zmienić się w czasie pojedynczego skanu tabeli. tak jak np. random(). to oznacza, że nie można użyć jej jako dostarczyciela wartości i potem tą wartością przeszukać indeksy.

cóż więc można zrobić – no cóż. trzeba powiedzieć postgresowi, że interesuje nas tylko pierwsza zwrócona wartość currvala – idealnie do tego nadają się podzapytania:

# EXPLAIN analyze SELECT * FROM test WHERE id = (SELECT currval('test_id_seq'));
                                                   QUERY PLAN
----------------------------------------------------------------------------------------------------------------
 INDEX Scan USING test_pkey ON test  (cost=0.01..8.03 ROWS=1 width=8) (actual TIME=0.047..0.050 ROWS=1 loops=1)
   INDEX Cond: (id = $0)
   InitPlan
     ->  RESULT  (cost=0.00..0.01 ROWS=1 width=0) (actual TIME=0.010..0.012 ROWS=1 loops=1)
 Total runtime: 0.187 ms
(5 ROWS)

jak widać jest już zdecydowanie lepiej.

ile jest wart postgres

dziś jest dzień postgresql'owy, więc kolejna informacja o nim.

jest taki program: sloccount. służy do liczenia ilości linii kodu, oraz estymowaniu kosztów stworzenia programu.

odpaliłem go na źródłach postgresa 8.2. oto wynik:

Totals grouped by language (dominant language first):
ansic:       479298 (94.01%)
yacc:         14698 (2.88%)
sh:            7805 (1.53%)
lex:           5349 (1.05%)
perl:          2608 (0.51%)
asm:             65 (0.01%)
python:          12 (0.00%)
<br/>
Total Physical Source Lines of Code (SLOC)                = 509,835
Development Effort Estimate, Person-Years (Person-Months) = 139.26 (1,671.14)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 3.50 (41.95)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 39.84
Total Estimated Cost to Develop                           = $ 18,812,337
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

pl/scheme

(hurra, (dzięki (projektowi (pl/scheme))) (wreszcie) (będziemy (się (mogli))) (w postgresie) (cieszyć (z kodu (składającego się (z samych (nawiasów)))))) 🙂