#!/bin/nwkr devblog

Integracja Open Power Template 1.x z KohanaPHP 2.2

Pół roku temu zamieściłem sposób na integrację systemu szablonów Open Power Template z frameworkiem KohanaPHP. Po pewnym czasie doszedłem jednak do wniosku, iż moje rozwiązanie jest lamerskie ;) Oto zamieszczam moduł integrujący Kohanę z OPT w taki sposób, że z szablonów korzystamy zupełnie tak samo, jak z View.

$view = new View('test.tpl'); $view->dynamic = 'And this is a dynamic.'; $view->render(TRUE);

Wybór silnika przetwarzania szablonów (natywny KohanaPHP lub OPT) dokonywany jest poprzez rozszerzenie szablonu. Wystarczy do nazwy szablonu dodać rozszerzenie .tpl, aby to OPT został użyty do wygenerowania widoku.

Moduł OPT v.1 dla Kohany w skrócie:

• Takie samo API, jak w View.
• Dobór silnika przetwarzania szablonów po rozszerzeniu.
• Kaskadowość systemu plików – szablony mogą się znajdować w różnych katalogach.

Zapraszam do pobierania i korzystania. Moduł został udostępniony na licencji BSD.

• opt-v1-kohana-module.7z
• opt-v1-kohana-module.tar.bz2
• opt-v1-kohana-module.tar.gz
• opt-v1-kohana-module.zip

W związku z trwającą właśnie Olimpiadą w Pekinie postanowiłem jeść mniej cukierków. Wierzę, że dzięki tej manifestacji obrony życia, Chiny zaczną respektować prawa człowieka.

Ten wpis jest nawiązaniem do wpisu Bluszcza, który postanowił wyłączyć jeden z większych serwerów Jabbera (jabberpl.org) w Polsce na czas Igrzysk. Gratuluję rozwagi!

Jutro, tj. 8.08.08 zostanie wydana wersja 2.2 frameworka Kohana. Prace nad wersją 2.2 trwały około pół roku. Trudno powiedzieć, by był to czas stracony. Świadczy o tym dużo commitów na SVN i nowa funkcjonalność.

Jedną z nowych rzeczy jest napisany całkowicie od nowa ORM (object-relational mapper). Poprzednia wersja miała „nienaprawialny” błąd, który powodował, że nie można było ograniczyć ilości pobieranych pól z powiązanych tabel relacji many to many. Ponadto zoptymalizowano nazwy metod – dotychczas większość metod była wywoływane przez powolne __call().

Będąc przy temacie wydajności, to Kohana 2.2 przyśpiesza ze względu na tzw. „internal cache”. Od teraz wszystkie pliki konfiguracyjne są serializowane, przez co nie trzeba ich ładować po kolei. Zwracam tutaj uwagę na kaskadowość systemy plików Kohany, tzn. że najpierw plik konfiguracyjny jest szukany w application/config, potem w modules/config, a na końcu w system/config. W większym projekcie wykorzystuje się często więcej niż 20 plików konfiguracyjnych, a szukanie plików na dysku zabiera cenne sekundy. Co więcej, rezultaty metody find_file() również są umieszczane w pamięci podręcznej. Tymi optymalizacjami Kohana przyśpieszyła trzykrotnie na moim domowym komputerze.

Wszystkich zainteresowanych tym, co nowe w Kohana 2.2 odsyłam na bugtrackera projektu.

Na rynku procesorów dla komputerów klasy PC swoje miejsce już dawno znalazły procesory tzw. dwurdzeniowe, a procesory czterordzeniowe stają się coraz tańsze. Procesor wielordzeniowy to de facto układ kilku oddzielnych procesorów o współdzielonej magistrali. Rodzi się pytanie, czy procesor n-rdzeniowy wykona szereg operacji n razy szybciej niż jeden procesor. Jak łatwo się domyśleć, odpowiedź brzmi „nie, jest wykona”.

Oprogramowanie nie jest idealne i nie jest przystosowane do obsługi wielu procesorów. Większość wykorzystywanych przez nas algorytmów ma charakter sekwencyjny, tzn. aby wykonać następny krok, trzeba zakończyć poprzedni. Nawet gdy programista poprawi algorytm tak, aby korzystał z wszystkich procesorów, nigdy nie osiągnie stuprocentowej skuteczności. W praktyce, ta część programu, której nie daje się zrównoleglić wynosi co najmniej 10%. Czy więc procesor 100-rdzeniowy jest tylko 10% wolniejszy od 100 osobnych procesorów? Kolejny raz odpowiadam „nie”.

Gene Amdahl sformułował prawo dotyczące wyznaczania maksymalnego przyśpieszenia programu równoległego w środowisku wieloprocesorowym.

n to liczba procesorów, a s to procent części sekwencyjnej programu.

Wzór interpretujemy w taki sposób, że zawsze istnieje nierównoległa część programu, w której trzeba oczekiwać na wynik poprzedniej operacji. Niemożliwe staje się więc wtedy przekazanie kolejnego rozkazu innemu procesorowi.

Poniżej przedstawiam teoretyczne przyśpieszenie programu w stosunku do systemu jednoprocesorowego na systemach o różnej ilości procesorów. Wartość dla nieskończenie wielu procesorów została obliczona z granicy funkcji. Testuję kilka programów o różnym procencie zrównoleglenia. Wartość liczbowa wyraża przyśpieszenie w stosunku do systemu 1-procesorowego.

Jak widać, potencjalnie niewielki procent kodu, który nie daje się wykonać równolegle ma bardzo poważne skutki w wydajności programu na większej ilości procesorów. Nawet 99,9% równoległości programu spowoduje teoretycznie wzrost szybkości maksymalnie tysiąckrotnie.

Popatrzmy teraz na benchmark, aby odnieść te teoretyczne obliczenia do rzeczywistości. Bierzemy pod uwagę procesory Phenom X3 8750 oraz Phenom X4 9750. Są one idealne do tego porównania, ponieważ różnią się tylko i wyłącznie ilością rdzeni, podczas gdy częstotliwość taktowania, czy ilość pamięci podręcznej jest taka sama.

Jak widać, w żadnym z testów procesor trzyrdzeniowy nie jest półtora razy szybszy od dwurdzeniowego, choć potencjalnie tego byśmy oczekiwali. Jest to potwierdzenie, że rzeczywiście programy testujące nie są do końca równoległe. Przy okazji oceniłem program WinRAR, aby określić, w jakim stopniu algorytm kompresujący jest napisany równolegle. Wynik to ok. 90%.

W teście nie brałem pod uwagę strat wydajności wynikających z konstrukcji sprzętu, np. zapychania się magistrali między procesorami, problemów z zachowaniem spójności danych w poszczególnych L1 cache z pamięcią RAM, czy podziałem wątków na procesory (system operacyjny).

Powiązane:

• Benchmarki pochodzą z PCLab.
• Arkusz kalkulacyjny z obliczeniami przyśpieszenia

Bardzo wiele serwerów korzysta z protokołu SSH do udostępniania powłoki. Wszyscy wiedzą, że jest to protokół bardzo bezpieczny. Mniej osób zdaje sobie sprawę z tego, że najsłabszym ogniwem w systemie zabezpieczeń systemów jest użytkownik i jego hasło. Postaram się przedstawić kilka prostych sztuczek jak uczynić SSH chociaż trochę bezpieczniejszym.

1. Domyślny port, na którym działa SSH to 22. Dobrym pomysłem jest przenieść SSH na port powyżej 1024. Unikniemy w ten sposób znakomitą większość ataków, jaką są ataki słownikowe. W większości są to niegroźne próby zalogowania się przy użyciu haseł pobranych ze słownika. Jednak gdyby jakimś cudem hasło, któregoś z użytkowników znalazło się w takim słowniku sytuacja przestałaby być mało groźna. Alternatywnym rozwiązaniem jest stosowanie skryptów, które przeglądają logi i po kilku nieudanych próbach zalogowania dodają do firewalla regułkę blokująca adres IP atakującego. Osobiście korzystałem jedynie z Bruteblocka, który działa na FreeBSD i można go sobie zainstalować z portów.

2. Kolejną ważną rzeczą jest niepozwolenie na logowanie się przez SSH superużytkownikowi (root). Musimy zatem dopilnować, aby opcja PermitRootLogin była ustawiona na no. Logujemy się wówczas na zwykłego użytkownika, a prawa roota uzyskujemy poprzez użycie komendy su lub sudo. Należy dopilnować, aby użytkownik, z którego chcemy mieć możliwość użycia komendy su znalazł się w odpowiedniej grupie – najczęściej jest to grupa wheel.

Można również w konfigu demona SSH wyszczególnić, jacy użytkownicy mają prawo do logowania się przez SSH:

AllowUsers nowaker kwiat admin

3. Domyślnie demon SSH pozwala na logowanie się przy użyciu protokołów w wersji 1 oraz 2. Wersja 1 jest mniej bezpieczna dlatego powinniśmy zezwalać na używanie tylko wersji 2:

Protocol 2

4. Dobrym pomysłem jest również zezwalanie na łączenie się jedynie z określonych adresów IP. Można tego dokonać poprzez odpowiednie regułki do firewalli lub poprzez użycie tzw. wrapperów TCP. W takim przypadku korzystamy z pliku /etc/hosts.deny i uzupełniamy go wg uznania.Warto również zastanowić się nad limitowaniem ilości połączeń SSH w jednostce czasu za pomocą firewalla.

W ten oto sposób przedstawiłem kilka bardzo prostych sposobów na minimalne zwiększenie bezpieczeństwa naszego demona SSH. Nie jest to może instrukcja typu kopiuj-wklej, aczkolwiek przy odrobinie chęci każdy początkujący administrator powinien sobie z tym poradzić.

Dzięki dla kwiata, administratora FreeBSD na serwerze Panic.PL za kilka poprawek merytorycznych :)

P.S. Tytuł wpisu stanowi nawiązanie do wpisu na zdzichuBG’u ;)

KDE i Gnome mają obsługę wirtualnych pulpitów już od dawna, podczas gdy najnowszy Windows jeszcze tego nie ma. Podczas przełączania za pomocą ALT+TAB widzimy tylko ikony poszczególnych programów, zamiast podglądu okna programu. I wiele innych… Okazuje się jednak, iż na stronie Microsoftu udostępniona jest seria tzw. PowerToys dla Windows XP, które usprawniają codzienną pracę z systemem.

Poniżej podaję listę „mocnych zabawek”, z których skorzystałem wraz z linkiem do ściągnięcia. Resztę dodatków (14) znajdziecie pod tym adresem. Ściągnięcie nie wymaga żadnych potwierdzeń legalności systemu.

• Virtual Desktop Manager – cztery wirtualne pulpity
• Alt-Tab Replacement – podgląd każdego okna
• Power Calculator – prosty kalkulator z rysowaniem wykresów

Virtual Desktop Manager w akcji:

Na wielu subskrybowanych przeze mnie blogach pojawiło się wiele wpisów na temat nowej Opery 9.50. Zachwyt, jaki spowodowała nowa Opera jest ogromny, tymczasem ja jestem nią bardzo zawiedziony. Jeden dzień jej użytkowania i już mam jej dosyć.

Opery używam począwszy od którejś „piątki” bądź „szóstki” (nie pamiętam dokładnie). Swego czasu Opera była produktem adware – jeśli nie zapłaciłeś(aś), to w prawym górnym rogu ekranu wyświetlał się banner wielkości 486×60. Czasy te już dawno minęły i w chwili obecnej mamy już wersję 9.50. Owa wersja jest pierwszą, którą uważam za gorszą w stosunku do poprzedniej.

Jako że już na pewno wiecie, co takiego ma nowa Opera, nie będę opisywał tych zmian. Wymienię zaś to, co nową Operę czyni w moim mniemaniu gorszą.

• W pewnych nieznanych mi sytuacjach klient IRC działa w taki sposób, że co równe 5 minut wychodzi kanału i od razu na niego wraca. Niezły spam na kanale się robi z powodu takiego Nowakera.
• Przeciągnięcie okna na pasek zadań otwiera drugą Operę, a nie tylko to jedno konkretne okno. Przez to na słowo „Nowaker” w IRCu okno na pasku zadań nie ma highlighta. Nie widzę więc, gdy ktoś coś do mnie mówi.
• Skórka „Naturalna Windows” posiada czarno-białe ikony, co utrudnia szybką identyfikację funkcji. Nie lubię wodotrysków, dla mnie ewolucja wyglądu GUI zakończyła się na Windows 95.
• Okno pobierania zostało uszczuplone, poprzednio posiadało więcej informacji.
• „Wklej i przejdź”, miało skrót CTRL+B, a teraz ma CTRL+SHIFT+V. Czy ten nowy jest szybszy?
• Czasami po wpisaniu adresu Opera nie odpowiada przez 3-6 sekund. Quad Core zbyt wolny dla niej?

Co jeszcze znajdę w ciągu następnej doby? Chyba już nic, jeśli zrobię downgrade.

Nowa Opera w akcji:

Na polskiej Wikipedii przeczytałem, iż singleton jest uważany za antywzorzec. To zdanie wzburzyło mnie dość mocno, ale gdy emocje tego strasznego przeżycia opadły zastanowiłem się, dlaczego autor tak napisał.

Faktem jest, iż singleton jest często nadużywany przez programistów, którzy nie potrafią zaprojektować aplikacji w prawidłowy sposób. Uciekają się więc wtedy do singletonów i w każdym miejscu kodu wywołują Sth.instance().doSth(). Twierdzą przy tym, że ich aplikacja jest zaprojektowana w pełni obiektowo i, co więcej, korzystają z wzorca projektowego Singletonu!

Patrząc na to realnie, stworzyli sobie zmienną globalną – a to nie ma nic wspólnego z projektowaniem zorientowanym obiektowo. W rzeczywistości powstała tylko karykatura wzorca projektowego – co wcale nie oznacza, iż prawidłowy Singleton jest antywzorcem. Temu stwierdzeniu mówię stanowcze „nie” :)

Kiedy więc zastosowanie wzorca Singletonu ma sens? Jest kilka przypadków, w których singleton jest idealnym rozwiązaniem:

• gdy musi istnieć tylko jedna instancja danej klasy
• gdy z przyczyn wydajnościowych nie warto tworzyć i niszczyć w wielu miejscach instancji danej klasy

Przykładem z życia wziętym jest np. biblioteka Session z frameworka KohanaPHP. Biblioteka Session ma sterownik native, database oraz cookie i w zależności od wybranej operacji zachowuje sesję którymś ze sposobów. Jako że sesja istnieje tylko jedna (logicznie patrząc – użytkownik jest jeden na każde uruchomienie skryptu), stworzenie drugiej instancji sesji było całkowicie bez sensu; co więcej, mogłoby zniszczyć dane wykonane przez pierwszą sesję.

Drugim przykładem jest baza danych. Nawiązywanie połączenia z serwerem bazy danych zawsze zabiera trochę czasu. Gdyby dziesięć różnych modeli z mojej aplikacji miało tworzyć, po czym już za chwilę zamykać połączenie – straciłbym cenne milisekundy na każdym żądaniu.

Podsumowując, używajmy Singletonu z głową i zgodnie z założeniami. W innym wypadku będzie to tylko czysty singletonitis ;)

P.S. Kilka dni temu założyłem sobie mikro-devbloga na Pingerze. Wszystkich zainteresowanych krótkimi wpisami developerskimi serdecznie zapraszam.

Przez ostatnie trzy tygodnie poznałem trochę języka Java za sprawą projektu na przedmiot pt. Programowanie obiektowe. Napotkałem kilka „problemików”, których rozwiązanie zajęło mi trochę czasu, mimo iż posiadam dobrą literaturę oraz potrafię korzystać z Goglownicy. Problemy te przedstawię w sposób podobny do redagowania tzw. FAQ.

Problem: setLocation() i setSize() nie działają!

Chciałbyś (chciałabyś) zmienić rozmiar np. przycisków, jednak wywołanie przycisk.setSize() nie zmienia jego rozmiaru. Wywołujesz setLocation(), jednak element nie zmienia swojego położenia.

Rozwiązanie:

Wywołaj setLayout (null).

Przykładowy kod:

public class PanelMenuGlowne extends JPanel
{
  public PanelMenuGlowne ()
  {
    this.setLayout (null);
    JButton przycisk = new JButton ("Testowy przycisk");
    przycisk.setLocation (30, 100);
    przycisk.setSize (100, 30);
    this.add(przycisk);
  }
}

Problem: Po kliknięciu krzyżyka [X] okno się zamyka, mimo że zdefiniowałem własny WindowListener / WindowAdapter

Chciałbyś (chciałabyś) wyświetlić okno dialogowe z pytaniem, czy zamknąć program. Jakkolwiek użytkownik programu nie odpowie – program się zamyka:

addWindowListener( new WindowAdapter () {
  public void windowClosing (WindowEvent z)
  {
    if (JOptionPane.showConfirmDialog
      (null, "Czy na pewno?", "Wyjście z programu", JOptionPane.YES_NO_OPTION) == 0)
    {
      System.exit (0);
    }
  }
}
);

Rozwiązanie:

Przed addWindowListener() dodaj:

setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);

Malcom na swoim blogu podzielił się swoimi przemyśleniami na temat obiektowości w webdevelopingu, choć nie tylko. Jako że nie zgadzam się za bardzo, z tym, co napisał – odpisałem mu w komentarzu. Tak się tam rozpisałem, że zyskałem i materiał na wpis na moim blogu :)

Strukturalnie czy obiektowo?

Jakie podejście jest lepsze – strukturalne czy obiektowe? Tym pytaniem chciałbym wywołać dyskusję, w jakich przypadkach lepiej jest stosować jedno, bądź drugie rozwiązanie. Nie można bowiem powiedzieć, że tylko jedno jedyne podejście jest słuszne, a inne całkowicie odpada.

Moim zdaniem, w webdevelopingu rządzi obiektowość. Wymagania co do moich projektów poszerzają się bardzo szybko. Bez obiektowości konserwacja aplikacji jest bardzo ciężka. Przykładem jest tutaj portal geograficzny GeoZone.pl – 3 lata dopisywania kolejnego strukturalnego kodu doprowadziło do kresu możliwości dalszego rozwoju. By dokonać jedną zmianę trzeba odwiedzić kilkanaście różnych miejsc w kodzie. A potem i tak nie działa to do końca tak, jak chcę.

Do realizacji algorytmów oczywiście obiektowość i wzorce projektowe nie bardzo się nam przydadzą. Tutaj rządzi C/C++ ze wględów wydajnościowych. (Oczywiście do organizacji struktur danych wykorzystujemy struktury, czy klasy – jak zwał, tak zwał – jednak nie stosujemy tu dziedziczenia, polimorfizmu, wzorców, itd.) Kto rozwiązywał zadania na SPOJ-u, ten wie o co chodzi ;) A kto nie, temu tłumaczę, iż liczy się każda sekunda wykonywania programu.

Cytaty z MalDevBlog, komentarz Nowakerowy

Oczywiście przewagą ActiveRecorda jest miedzy innymi to, że wystarczy zmienić implementację sterownika bazy i można generować zapytania do dowolnej bazy, bez poprawiania kodu. Ale czy znów tak często zmieniamy bazę danych, szczególnie w nieco mniejszych aplikacjach?

Często może i nie, co nie oznacza, że nie warto stosować warstwy abstrakcji na bazę danych. Za pół roku możesz np. zdecydować, że przenosisz swoje wszystkie projekty ze względów wydajnościowych z MySQL na PostgreSQL – i co wtedy zrobisz? Albo mozolnie zmienisz wszędzie mysql_ na odpowiedniki pg_ albo… olejesz sprawę, bo będzie z tym zbyt dużo roboty.

Inna sprawa, to porozrzucanie po 40 klasach 4 funkcji, i tworzenie 10 obiektów tylko po to, aby zmienić jakąś regule w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu, aby w efekcie otrzymać zamierzony cel działania ;)

Wg mnie nie masz tutaj racji, ponieważ dokumentację bedziesz musiał tylko raz przejrzeć, aby zrozumieć, o co chodzi. Później już nie będziesz tego odczuwał. Gdy zaś przyjdzie czas na jakąś przeróbkę w routingu, pójdzie ona gładko, podczas gdy w strukturalnym projekcie nie obeszło by się bez skakania po plikach i zmieniania wszystkiego po kolei w wielu miejscach.

Jednorazowe napisanie projektu obiektowo wymaga więcej pracy, aniżeli strukturalnie. Gdy zaś przychodzi czas na przeróbki, zyskujemy dużo czasu w stosunku do podejścia strukturalnego.

Tak myślę, że chyba jednak dokończę tego własnego frameworka. Ileż to różnych projektów wstrzymałem, zawiesiłem, czy porzuciłem na różnych stopniach zaawansowania prac. Głównie z braku czasu i zmian w zapotrzebowaniu i użytkowaniu danego produktu (projektu).

Według mnie to upadło w wyniku strukturalnego projektowania. Zmieniło się zapotrzebowanie i okazało się, że napisany strukturalnie system nie jest już w ogóle przydatny. Przemyślany obiektowy system daje się łatwo wykorzystywać dalej oraz modyfikować, a więc i szansa powodzenia projektu jest większa.

Na koniec zapraszam na blog Malcoma.