najważniejszy post na blogu

pewien facet, niejaki mike stopforth, w artykule na lokalnym (z naszego punktu widzenia, bo dużym u nich) portalu w rpa, napisał, że jego cele do osiągnięcia w życiu to …

i tu była lista 3 punktów o których sam napisał, że sę z różnych powód niemożliwe.

na pierwszym miejscu była przejażdżka (kierowanie) aston martinem.

nie dziwię mu się – też bym chciał 🙂

niecałe 2 tygodnie później dostał maila w którym justin divaris z aston martina zaproponował wypożyczenie astona db9 na cały dzień.

co było dalej – opisywać nie chcę – chętni przeczytają wpis na blogu mike'a. ogólnie – przejechał się. był super-szczęśliwy i przy okazji poczynił kilka interesujących uwag nt. podejścia do człowieka w astonie w porównaniu do ferrari, lamborghini, bmw czy amg. warto przeczytać choćby po to by móc sobie poprawić humor.

eclipse – ide dla twardzieli

ogólnie nie lubię javy. natomiast jest dla niej coś co mi się podoba – ide eclipse. ma sporo plusów, i mimo, że nabijam się z niego w firmie, dostrzegam w nim sporo plusów.

niestety. ide to jest mocno modularne i aby miało sensowną funkcjonalność trzeba naściągać pluginy, testować czy działają i ogólnie bawić się z tym.

do teraz.

istnieje taki projekt który nazywa się “easy eclipse“.

idea projektu jest prosta: wybierzemy zastosowanie, pod to zastosowanie spaczkujmy to co trzeba. i udostępnijmy gotowe do działania, skonfigurowane, o-pluginowane środowisko.

przykłady zastosowań:

  • expert java
  • desktop java
  • server java
  • mobile java
  • plugin warrior
  • lamp
  • php
  • ruby on rails
  • python
  • c/c++

każde z zastosowań generuje trochę inną paczkę, np. paczka “lamp" zawiera:

  • eclipse jako taki
  • eclipse tools
  • java jre
  • eclipse java development tools
  • anyedit tools
  • eclipse util plugins
  • color editor
  • web tools editors
  • html tidy
  • amateras html and xml editor
  • quantumdb
  • php eclipse
  • simple test for php
  • pydev
  • ruby development toold
  • radrails
  • eclipse perl integration

całośc w paczkach dla windows, macos'a i linuksa. gotowe. tylko podgrzać (rozpakować) i używać.

piątek trzynastego?

firma ubezpieczeniowa aa, ustami swojego pracownika, kevina sinclaire'a, poinformowała, że po gruntownym przebadaniu sprawy, to nie piątek trzynastego jest najbardziej pechowym dniem.

niezależnie od rozmaitych przesądów i wierzeń, statystycznie najgorszym dniem jest poniedziałek, 27-ego. na szczęście najbliższy taki dzień jest dopiero sierpniu 2007. może warto na ten dzień wziąść urlop i nie wychodzić z domu?

BUG w postgresie :)

heh

wykryłem pierwszego poważnego buga w postgresie 🙂

w 8.2rc1 jest bug który wykłada postgresa (segfault, sig 11) przy vacuumowaniu indeksów gin 🙂

w sumie szkoda – bo giny są niesamowicie szybkie – ale i dobrze, bo bug namierzony to bug zniszczony. i mogę się chwalić, że przyczyniłem się do poprawienia stabilności postgresa 🙂

tuningowanie aplikacji bazodanowych korzystających z postgresa

josh berkus, osoba dosyć znana w światku postgresowym, opublikował na swoim blogu pierwszy (z serii?) wpis nt. tuningowania aplikacji.

wpis zawiera wstęp teoretyczny i 3 hinty.

hinty sa proste:

  1. nigdy nie używaj wielu małych zapytań gdy jedno większe załatwiłoby sprawę.
  2. grupuj wielokrotne insert/update/delete w pojedyńcze operujące na większej ilości danych, lub gdy sie nie uda – w transakcje.
  3. rozważ zastosowanie bulk-loadingu (copy) zamiast serii insertów.

wstęp teoretyczny jest także istotny, ale ani tego ani dokładnego uzasadnienia hintów tłumaczyć nie będę – przeczytajcie sami.

request tracker “rządzi”

część z was zna może rt (request trackera). tym którzy nie znają wyjaśnię – jest to jeden z najlepszych (albo najlepszy) system do zarządzania zgłoszeniami/błędami. mamy instalację rt. instalacja jest sporawa: > 50000 ticketów, 160 kolejek, około 150-200 nowych ticketów dziennie. instalacja chodziła kiedyś na postgresie (wersja 7.2) ale działała wolno i przenieśliśmy na mysql'a (4.1). i zaczęła działać szybciej. ostatnio dowiedziałem się, że rt po przeniesieniu z postgresa 7.4 na 8.1 działa dużo szybciej, więc stwierdziliśmy, że zrobimy testy. postawiliśmy testowe rt, wgraliśmy mu produkcyjną bazę. po czym odpaliliśmy testy z użyciem fajnego narzędzia: tsunga. kolega który robił testy (hi, filip 🙂 zrobił scenariusz testowy:

  1. wejście na stronę logowania
  2. zalogowanie (i wyświetlenie strony głównej)
  3. wejście w losową kolejkę
  4. wyświetlenie losowego ticketu
  5. wylogownie

łącznie 5 ekranów. zrobił (filip) testy. mysql – 15 sekund. postgres 8.1. – 30 sekund. postgres, ale z dodatkowymi indeksami podpowiedzianymi przez jakiegoś znajomego – 17 sekund. no cóż. kiepsko. nic to. patrzymy co dalej. i tu pojawia się gwódź programu. kto z was zganie ile zapytań do bazy danych wykonało rt po przejściu 100 razy scenariusza testowego (czyli łącznie 500 stron wygenerowane). no? chętni? 1000? 2500? 5000? nie. prawdziwa ilość wykonanych zapytań to: 145937! czyli prawie 300 zapytań *na stronę*! nic dziwnego, że to wolno działa. filip ma napisać (może już napisał?) do best practical z prośbą o wyjaśnienia. ciekawe czy czegoś się dowiemy …

William Diehl nie żyje

nazwisko może nic wam nie mówić. istotne (dla mnie) jest to, że to jest człowiek który napisał książkę która stała się podstawą dla jednego z najlepszych filmów jakie kiedykolwiek widziałem.

jeśli jeszcze nie widzieliście “lęku pierwotnego" (primal fear) – marsz do wypożyczalni. film jest z 1996 roku, więc nie podpada pod nowość. kilka razy go pokazywali w tv. ale obejrzenie go zdecydowanie każdemu polecam. dodatkowo – po obejrzeniu lęku pierwotnego sugeruję obejrzeć “american history x" i porównać postaci grane przez edwarda nortona. ten koleś naprawdę umie zagrać!.