Bootstrapa oczywiście znacie ale czy wiecie, że w Poznaniu rusza Barcamp? Jeżeli tylko będziecie mogli zjawić sie 1 września 2007 w Poznaniu na pewno nie pożałujecie wizyty na Barcampie.

Wszystkie szczegóły znajdziecie tu: barcamp.pl.

Żałuję, że nie będę mógł się zjawić. Mam nadzieję, że szybko uda się to nadrobić.

Gdyby ktoś zapomniał pochłonięty wakacjami - jutro (sobota 21.07.2007) kolejny Bootstrap (7.7).

Plan spotkania:

• Tomasz Korzeniowski:“Strategie wyszukiwanie informacji - Vector Space Model”
• Grzegorz Albrecht: “Więcej za mniej - czyli o promocji w sieci”

Widzimy sie na Chłodnej25 od 12:00.

Zapewne spotkaliście się z problemem wydajnego wyszukiwania pełnotekstowego (full-text search).

Założę się, że słyszeliście też o Javowym projekcie zwanym Lucene, który jest w tym temacie pewnym standardem. Pewnie też większość z was wie, że jest port Lucene napisany napisany w Rubym - Ferret.

To czego możecie nie wiedzieć to fakt, że używanie Ferreta w aplikacjach Railsowych jest wybitnie proste, przyjemne i wydajne przy minimalnej ingerencji w kod i minimalnym nakładzie pracy.

Jeżeli tego wam jeszcze mało - kilka testów wydajności: pierwszy, drugi, trzeci.

Teraz krok po kroku zainstalujemy, i zaczniemy używać Ferreta w nazych aplikacjach.

Wpis ten w dużej części oparty jest o znakomity tutorial na RailsEnvy.

Zaczynamy od zainstalowania samego Ferreta:

gem install ferret

Instalujemy Railsowy plugin acts_as_ferret (tu mamy dwie możliwości):

Pierwsza opcja - gem:

gem install acts_as_ferret

i wtedy w pliku environment.rb naszej aplikacji dodajemy wpis:

Druga opcja - w naszej aplikacji Railsowej jako plugin. W głównym katalogu aplikacji wykonujemy:

ruby script/plugin install svn://projects.jkraemer.net/acts_as_ferret/tags/stable/acts_as_ferret

Możemy już przejść do używania naszego nowego, lśniącego Ferreta.

Mówimy naszym modelom by “zachowywały się jak fretka”

W parametrze :fields wyszczególniamy pola, które Ferret ma indeksować w danym modelu.

Możemy zacząć poszukiwania

Załóżmy, że chcemy w bazie naszych wpisów wyszukać te, które zawierają słowo ferret (w polach title lub body bo tylko tych pól indeks jest prowadzony).

Zmienna @entries_with_ferret będzie zawierała tablicę obiektów ActiveRecord modelu Entry - taką gdy dostajemy używając np:

ale z dodatkowymi atrybutami:

1. Ferret w trakcie naszych działań tworzy w głównym katalogu naszej aplikacji swój indeks. W tym przypadku plik index/development/entry (gdzie development to nazwa tryb w jakim odpalona jest nasza aplikacja)
2. indeks ten aktualizuje się na bieżąco i nie musimy się nim specjalnie interesować
3. jeżeli z różnych względów potrzebujemy ręcznie odbudować indeks wystarczy skasować katalog index naszej aplikacji lub któryś z podkatalogów

Krótki opis dodatkowych metod.

Ilość znalezionych rekordów:

Rekordy i trafność znalezionych rekordów:

Przykładowa zmienna results mogłaby wyglądać tak:

Standardowo zwracane jest pierwsze dziesięć trafień.
Jako opcje do tej metody możemy przekazać takie opcje jak do metody ferreta search_each np:

• offset - przesunięcie wyników o daną wartość, domyślnie 0
• limit - ilość zwracanych pozycji, domyślnie 10
• sort - obiekt sortowania (?) lub pola wg których mają być sortowane zwrócone dane. Przykładowo “title DESC, author_name”

Pominę tu sporo opcji konfiguracyjnych tego pluginu (odsyłam do dokumentacji lub już wspomnianego poradnika na RailsEnvy).

Ostatniach rzecz, o której chciałbym wspomnieć to opcja przechowywania zawartości pól w indeksie Ferreta (Field Storage).

Jeżeli pola, które indeksujemy są małe i możemy sobie pozwolić na to by przechowywać ich wartość na dysku możemy ograniczyć obciążenie bazy danych przez przechowywanie wartości tych pól bezpośrednio w indeksie.
Nasza poprzednia deklaracja modelu Entry mogłaby wyglądać tak:

W tym przypadku pole title będzie przechowywane w indeksie.
Aby dostać się do tego pola potrzebujemy jednak własnej metody modelu Entry. Mogłaby wyglądać tak:

Mam nadzieję, że zachęciłem was do choćby spróbowania potężnego narzędzia jakim jest Ferret.

PS. Niedługo może o pluginach autoryzacji i autentykacji.

Ostatnio poszukiwałem dobrego rozwiązania na pewien projekt.

Wytyczne:

• musi obsłużyć duży ruch (w szczytowych momentach nawet ogromny) z dość często zmieniającą się treścią
• prosty i elastyczny system rozszerzeń (pluginów)
• idealnie gdyby by NIE był stworzony w PHP (chciałbym by ten rozdział w moim życiu pozostał zamknięty:))
• musi zawierać rozsądnie rozwiązany system zarządzania użytkownikami i ich prawami
• najlepiej gdyby był oparty na gotowych i sprawdzonych frameworkach
• musi być wydany na otwartej licencji i napisany w otwartym języku

Ogólnie rzecz biorąc decyzja jeszcze nie zapadła ale chciałbym się podzielić pewnym odkryciem. W dziedzinie CMSów mam całkiem spore doświadczenie i przetestowałem ogromną ich ilość gdy wybieraliśmy system do obsługi większości naszych firmowych domen. Wtedy wybraliśmy eZ Publish i z perspektywy czasu okazało się, że był to strzał w dziesiątkę. System spełnił pokładane w nim oczekiwania (główną zaletą jest jego niezwykła wręcz elastyczność). Fakt jednak, że wytyczne jego wyboru były zdecydowanie inne od przedstawionych powyżej. Z drugiej strony największymi minusami eZ Publisha są jego wydajnośc, zasobożerność oraz dość skomplikowana budowa. Wydajność jest wręcz nieakceptowalna gdy system działa bez włączonego cache’owania treści i szablonów oraz bez jakiegokolwiek PHP acceleratora.

Idealnym rozwiązaniem do tego projektu wydaje się Drupal - jest szybki, ma dobrze rozwiązany system pluginów, jest przez lata testowany w przeróżnych zastosowaniach i ma ogromną społeczność użytkowników. Niestety stworzony został w PHP ale to jeden z projektów, które jak WordPress przełamują mą niechęć.

Rozważałem jeszcze kilka sprawdzonych CMSów - np znakomity Plone‘a, który jest niestety równie ciężki jak eZ Publish a pluginy w Zope to nic szybkiego ani, jak dla mnie, przesadnie przyjemnego.

Przez przypadek trafiłem na niezmiernie ciekawy projekt, który nosi nazwę Skeletonz.

Jest to lekki, elastyczny i bardzo szybki (jak wynika z pierwszych testów i informacji autora) CMS stworzony w Pythonie.

Początkowo projekt używał frameworków CherryPy, MochiKit, SQLObject, Textile i Cheetah. Według autorów (prawdę mówiąc autora) narzędzia te pokazały swe ograniczenia w różnych kwestiach i zostały na potrzeby Skeletonz ulepszone (tu szczegóły).

Głównym założeniem tego systemu jest elastycznośc i wydajność. Rozwiązanie umieszczania pluginów przypomina mi trochę RadiantCMSa. System ma bardzo przyjemny i przejrzysty interfejs i tam gdzie ma to sens używa AJAXa - wszystko jest proste i intuicyjne, działa szybko, sprawnie i bez większych problemów.

Wziąłem Skeletonz na warsztat i okazało się, że spełnia większość moich wymagań.

• jest naprawdę bardzo wydajny - nie podam póki co wyników wstępnych testów bo zrobiłem ich zbyt mało ale przy sporej ilości wrzuconej treści i włączonym cache’owaniu osiągał nawet ok 450req/s. Odbudowa cache’y jest błyskawiczna i update jest automatyczny np przy dodawaniu komentarzy do wpisów na blogu, lub kolejnego wpisu do newsów
• jest bardzo elastyczny, pozwala na praktycznie nieograniczone używanie w każdej wygenerowanej stronie wszystkich dostępnych treści (tu pluginów). Treści te można współdzielić na wielu niezależnych stronach (każdy blog, sekcja newsów itd ma swój unikalny identyfikator). Np tworzę stronę, która może mieć sporo czystego tekstu, poniżej newsy, bloga, linki do innych stron, kolejnego bloga, podmenu, formularz rejestracyjny, czytnik RSS itd (pomijam tu sensowność :))
• zarządzanie treścią jest bardzo intuicyjne a interfejs jest estetyczny
• system pluginów jest rozsądnie zrealizowany

Oczywiście jak wszystko Skeletonz też ma wady:

• projekt jest dość młody, ma małą społeczność użytkowników, rozwijany jest głównie przez jedną osobę (amix.dk Amix jest też twórcą bardzo ciekawie zrealizowanego Todoist),
• zapewne posiada kilka błędów (jeden udało mi się wykryć i poprawić, chyba byłem pierwszą osobą poza autorem, która robiła commit do SVNa) na szczęście kod jest przejrzysty i rozsądnie napisany
• ma tragicznie rozwiązany system uprawnień - możliwość edycji strony (całej, nie na poziomie pluginów na niej użytych) można dać jednemu użytkownikowi lub jednej grupie użytkowników, użytkownika można przypisać tylko do jednej grupy. Pojawia się oczywisty problem gdy chcemy by kilku użytkowników mogło edytować jedną stronę a tylko część z nich mogła edytować kolejną itd. Pracuję nad tym by ten problem rozwiązać poprzez możliwość przypisanie użytkownika do wielu grup. Ta zmiana będzie chyba najmniej bolesną z możliwych w tym zakresie. Zobaczę też czy można zintegrować sprawdzanie uprawnie na poziomie pluginu.
• nie wiem dlaczego ale hasła trzymane są w bazie czystym tekstem (zadałem pytanie do autora na grupie ale otrzymałem tylko wymijającą odpowiedź)
• dokumentacja projektu bardzo odbiega od ideału i większość trzeba “rozgryzać” czytając kod źródłowy (przy kolejnym tak poznawanym rozwiązaniu przestało mnie to już przerażać:))

Podsumowując chciałem wam przybliżyć projekt Skeletonz jako bardzo ciekawą alternatywę dla CMSów tworzonych w PHP, szczególnie jeżeli kluczami do wyboru rozwiązania będą wydajność, elastyczność, intuicyjny interfejs i brak PHP :)

W najbliższą sobotę kolejny Bootstrap.

Więcej informacji znajduje się tu: blog.bootstrap.pl

Niestety ostatnio spotkania niefortunnie kolidują z moją szkołą ale pojawie się na kilka godzin (dokladnie 3:)).Do zobaczenia.

My, niżej podpisani, chcemy zaprotestować przeciwko nierozważnemu zarządzaniu pieniędzmi podatników przy zakupie oprogramowania komputerowego dla instytucji państwowych. Jesteśmy przekonani, że decyzje o zakupie produktów podejmowane są często bez dogłębnej analizy potrzeb informatycznych danej instytucji oraz kosztów wdrażania konkretnych rozwiązań.

Nasz szczególny niepokój wzbudził przetarg ogłoszony w dniu 14.12.2006 przez Zakład Ubezpieczeń Społecznych na zakup 25.000 licencji pakietu Biurowego Microsoft Office 2003 oraz takiej samej liczby licencji dostępowych do serwerów firmy Microsoft i aktualizacji systemu Windows „do wersji najbardziej aktualnej przez 36 miesięcy”, którego wartość wyniesie od 62 do przeszło 66 milionów złotych. Jesteśmy świadomi, że wymiana i rozbudowa oprogramowania jest konieczna. Pytamy jednak: Dlaczego pieniądze podatników przeznaczane są na drogie rozwiązania firmy Microsoft w sytuacji, kiedy istnieje znacząco tańsza alternatywa jaką jest Wolne Oprogramowanie?

Szczegóły i petycja tu:  akcja.jakilinux.or.

Nawet jeżeli to nic nie zmieni - może sprawi, że ktoś się zastanowi nad obecnym stanem rzeczy.

Ja podpisałem

Zapraszam wszystkich na kolejnego Bootstrapa.

Sobota 24 marca 2007 o 12:00 na Chłodnej 25.

Więcej informacji znajdziecie na blogu bootstrapa.

Do zobaczenia.