jEdit jako IDE dla Ruby on Rails

Opublikowane przez Jarosław Zabiełło Tue, 30 Jan 2007 00:30:00 GMT

Gdy myśli się o jakimś dobrym edytorze do kodowania w Ruby on Rails, to najczęściej słychać o RadRails lub Textmate. Tymczasem jest edytor, który po odpowiednim “dopaleniu” pluginami znacznie przewyższa to, co potrafią tamte oba razem. Mowa o darmowym, multiplatformowym edytorze jEdit. Cały szkopuł w tym, że właściwy dobór i konfiguracja stosownych pluginów nie jest dla każdego oczywista.

Czytaj dalej...

Tagi , ,  | 13 comments

Haml - następna generacja szablonów

Opublikowane przez Jarosław Zabiełło Sat, 27 Jan 2007 03:33:00 GMT

W związku z przestawieniem się całkowicie na najnowszą wersję Railsów (1.2.1), postanowiłem przy zrobić także upgrade oprogramowania do mego bloga (który w wersji jaką miałem nie współpracował z RoR 1.2.1). Na szczęście, dzięki railsowym migracjom proces aktualizacji skryptów jak i struktury baz przebiegł bez problemów i niedestrukcyjnie dla danych w bazie. Typo”:http://trac.typosphere.org/ zawsze był kodem trochę awangardowym, wprowadzającym zaawansowane mechanizmy Rubiego i najnowsze pomysły Railsów. Przekonałem się o tym podczas próby modyfikacji paru szablonów. Typo zamiast dotychczasowego formatu ERb (*.rhtml) Typo używa już szablony nowej generacji – Haml. Chcąc niechcąc, musiałem przejść szybki kurs posługiwania się nimi aby zmodyfikować szablony w swoim blogu.

Czytaj dalej...

Posted in  | Tagi , , ,  | 13 comments

Komodo Edit 4.0 - za darmo

Opublikowane przez Jarosław Zabiełło Wed, 24 Jan 2007 08:37:00 GMT

Firma ActiveState wypuściła finalną wersję swojego IDE do Pythona, Perla, PHP, Ruby, etc (obsługiwanych jest wiele języków i składni).

Czytaj dalej...

Tagi ,  | 23 comments

Prototype - oficjalne API i dokumentacja

Opublikowane przez Jarosław Zabiełło Fri, 19 Jan 2007 15:53:00 GMT

Znana biblioteka Prototype doczekała się własnej dokumentacji, API oraz bloga: http://prototypejs.org. Prototype zapewnia lekkie, eleganckie API o składni wzorowanej na języku Ruby. Ta składnia jest tak ładna, że niektórzy nawet nie widzą potrzeby tworzenia dodatkowych helperów. W tej chwili to, moim zdaniem, najlepsza biblioteka do JavaScript i AJAX. Rails postawił zdecydowanie na dobrego konia. Pylons – niejako “z rozpędu”, bo skopiowali railsowe helpery – też. :)

Czytaj dalej...

Tagi , , , , ,  | 9 comments

RadRails i snippety Textmate

Opublikowane przez Jarosław Zabiełło Fri, 19 Jan 2007 12:37:00 GMT

RadRails, IDE dla Ruby on Rails, posiada nową stronę ze wszystkimi makrami skopiowanymi z edytora Textmate. Co ciekawsze, w nowszej wersji RadRails te snippety mają być standardowo dodane do edytora.

Tagi , ,  | brak comments

Ruby on Rails 1.2

Opublikowane przez Jarosław Zabiełło Thu, 18 Jan 2007 17:38:00 GMT

Wyszła finalna wersja Railsów 1.2. Aktualizację można wykonać za pomocą gemsów.

>gem update rails -y

Updating installed gems...
Bulk updating Gem source index for: http://gems.rubyforge.org
Attempting remote update of rails
Successfully installed rails-1.2.0
Successfully installed activerecord-1.15.0
Successfully installed actionpack-1.13.0
Successfully installed actionmailer-1.3.0
Successfully installed actionwebservice-1.2.0
Installing ri documentation for activerecord-1.15.0...
Installing ri documentation for actionpack-1.13.0...
Installing ri documentation for actionmailer-1.3.0...
Installing ri documentation for actionwebservice-1.2.0...
Installing RDoc documentation for activerecord-1.15.0...
Installing RDoc documentation for actionpack-1.13.0...
Installing RDoc documentation for actionmailer-1.3.0...
Installing RDoc documentation for actionwebservice-1.2.0...
Gems: [rails] updated

>rails -v

Rails 1.2.0

Tagi  | 5 comments

Firefox killer plugins

Opublikowane przez Jarosław Zabiełło Tue, 16 Jan 2007 11:47:00 GMT

Jeśli ktoś ma jakiekolwiek wątpliwości, dlaczego powinien używać przeglądarkę Firefox podczas prac nad aplikacjami internetowymi, to niech obejrzy co potrafią niektóre pluginy. Oto moja lista you-must-have:

  • Firebug – pozwala na podgląd kodu generowanego przez wywołania AJAX. Ma zintegrowaną konsolę do debugowania kodu JavaScript i mnóstwo, mnóstwo opcji. Gdyby Firefox miał tylko ten jeden plugin, to dla niego warto rzucić wszystkie pozostałe przeglądarki. Po prostu rewelacja.
  • Web Developer – plugin z mnóstwem opcji dla web developerów, można elegancko czyścić cache, cookies, podglądać kod JavaScript i CSS. Można także zmieniać w okienku ustawienia styli kaskadowych oglądając natychmiastową zmianę na dowolnej stronie www.
  • Adblock – pozwala usunąć wszelkie denerwujące reklamy ze stron www. Najprościej wycinać całe domeny, można używać znaku * na oznaczenie dowolnego ciągu znaków. Bez reklamowych śmieci strony ładują się znacznie szybciej. M.in. mam w nim poczytne miejsce dla *gemius.pl* którego wstawkami upstrzonych większość dużych polskich serwisów. Szkoda, że Opera (która swoją drogą jest najszybsza i używam ją czasem zamiast Firefoksa z powodu ładnego czytnika RSS i wygodnego klienta IRC) nie posiada nic podobnego. (Jest też plugin Adblock Plus który potrafi zasysać domeny do wycięcia z zewn. serwera, ale mnie się nie podoba jego interfejs. Adblock jest znacznie wygodniejszy.)
  • Live HTTP headers – przydaje się do podejrzenia “żywych” nagłówków HTTP. Choć z drugiej strony FireBug też to potrafi…

Co z resztą przeglądarek? Wiadomo, że Internet Explorer ma największą popularność, więc warto na końcu sprawdzić czy kod jest z nim zgodny. Ale do zasadniczej developerki: IE, Opera czy Safari to po prostu ciężka pomyłka.

Tagi , , , , ,  | 9 comments

Szablony i wzorzec MVC - cz. III

Opublikowane przez Jarosław Zabiełło Sun, 14 Jan 2007 03:25:00 GMT

W poprzedniej części omówiono szablony dedykowane głównie do współpracy z designerami bojącymi się programować. Były to albo szablony wkładające swoją logikę do znaczników XML/XHTML (ZPT, SimpleTAL, Kid, Genshi, MasterView, PHP TAL), albo szablony posiadające swój własny, specjalizowany język (Smarty, Django, Jinja, Liquid). W założeniu taki język miał być prostym substytutem języka używanego w warstwie kontrolera. Szablony tego typu może są wygodne dla designera, ale na pewno nie dla programisty, który musi je przygotować. Po pierwsze, trzeba się uczyć kolejnego języka… szablonów. Po drugie, wszystkie tego typu języki są ograniczające dla programisty. Mimo że pozornie prostsze, w praktyce są bardziej złożone i to nawet dla designera. Np. szablony Django i Jinja nie posiadają żadnej składni na określenie trywialnego warunku większości, mniejszości:

{{ x }} jest 
{% if x > y %} 
    większe 
{% else %} 
    mniejsze 
{% endif %} 
od {{ y }}

Powoduje to masę kłopotów dla programisty1. Prymitywna składnia szablonu wymusza więc kupę dodatkowej pracy. O ileż prościej jest użyć po prostu pełnej składni języka tak jak to robią szablony Cheetah:

$x jest 
# if x > y 
    większe 
# else 
    mniejsze 
# endif  
od $y

Dochodzimy tu więc do sytuacji kiedy byśmy chcieli coś bardziej elastycznego – pełnego dostępu do języka programowania. Taka sytuacja jest pożądana wtedy kiedy i tak szablony budują programiści na podstawie dostarczonego czystego kodu HTML od designerów.

PHP

Język PHP jest dosyć specyficzny, bo w istocie jest to język szablonów. Tzn. pierwotnie tak został stworzony, ale z czasem się skomplikował że dostąpił miana języka skryptowego. Ale jego korzenie widać w składni, która z definicji jest zagnieżdżaniem instrukcji PHP wewnątrz kodu HTML. Idąc tym tropem, niektórzy pomyśleli, że nie ma sensu wymyślać dodatkową składnię. Wystarczy użyć PHP w odpowiedni sposób. I tak powstały szablony Savant.

Właściwie to Savant nie powinny nazywać się szablonami, bo to nic innego jak PHP użyty w taki sposób, aby rozdzielić warstwę prezentacji, od wartwy logiki biznesowej. A skoro to PHP, to odpada nauka dodatkowej składni oraz potrzeby kompilacji specjalizowanego języka szablonów do końcowego kodu PHP (jak to ma miejsce w szablonach Smarty).

Czy takie podejście jest lepsze, czy gorsze, to już każdy może sobie ocenić. Moim zdaniem PHP ma na tyle mętną składnię, że warstwa prezentacji używająca Smarty2 jest bardziej czytelna niż czysty PHP jaki używają Savant.

Ruby

Kiedy mówimy o Ruby w kontekście stron internetowych to najczęściej mamy na myśli jego najsłynniejszy framework – Rails. Ruby sam w sobie nie jest związany z HTML tak jak PHP. Rails do szablonów używa biblioteki ERb (ang. “embed Ruby”, czyli “zagnieżdżony Ruby”) Składnia jest bardzo podobna do PHP, JSP czy ASP. Ruby jest tu językiem zagnieżdżonym w HTML.

<%= x %> jest 
<% if x > y %> 
    większe 
<% else %>
    mniejsze 
<% end %>
od <%= y %>

Python

Jeśli chodzi o Pythona to istnieje cała masa systemów szablonowych. Ograniczę się do paru, tych bardziej interesujących.

Spyce

Szablony Spyce zostało stworzone jako pythonowa konkurencja dla PHP. Podobnie potrafią przeplatać język (tu: Pythona) z tagami HTML. Najbardziej oczywista przewaga Spyce wynika z faktu używania języka Python, który jest znacznie lepiej zaprojektowany i posiada dużo więcej możliwości niż PHP. Spyce potrafii budować własne znaczniki (custom tags, podobnie jak to potrafią javowe JSP) oraz łatwiej w nich zbudować komponenty, kod do wielokrotnego użytku.

Myghty

Szablony Myghty powstały pierwotnie jako pythonowa implementacja systemu komponentowego Mason dla Perla. Mimo wielu podobieństw, Myghty są znacznie potężniejsze o Masona, np. intensywnie wykorzystują obiektowość Pythona (zobacz różnice). Od początku Myghty powstało z myślą o dużych obciążeniach, ciężkich, profesjonalnych zastosowaniach. Mają doskonały własny cache, są bardzo szybkie, odporne na wątki, świetnie się nadają do tworzenia komponentów.

Programiści Pythona bardzo cenią sobie filozofię tego języka (która podkreśla prostotę, oczywistość i elegancję składni). Problem w tym, że Myghty dla pythonowców jest zbyt podobne do Perla. Są za mało “pythonic” – pythonowe. Dodatkowo, poprzez podkreślanie swojej komponentowości, Myghty niektórym zbyt kojarzy się z filozofią komponentową frameworku ASP.NET (a wzorzec MVC wydaje się być bardziej przejrzysty niż wzorzec sterowanych zdarzeniami komponentów). Myghty, jako system komponentowy, może być używane w stylu MVC, ale nie jest to takie naturalne i oczywiste. (Na szczęście, wszystko zmienił Pylons który zapewnia przejrzystą pracę zgodną z wzorcem MVC i Myghty są tam zredukowane tylko do obsługi szablonów szablonów. Sterowaniem zajmują się kontrolery Pylonsa a nie Myghty).

Cheetah

Szablony Cheetah posiadają jedną z najbardziej czytelnych i eleganckich składni. Autorzy wzorowali się trochę na javowych Velocity i Webmacro. Tym, którzy cenią sobie czystość Pythona z prostotą składni szablonów z pewnością Cheetah mogą przypaść do gustu. Przez dłuższy czas były moimi ulubionymi szablonami i do te pory lubię ich klarowność. Cheetah posiadają elegancką składnię obiektowego budowania szablonów potomnych na bazie już istniejących. Myghty też to potrafi, ale Cheetah to ma bardzo czytelnie zrobione. Cheetah są również bardzo szybkie.

Mako

Mako to najmłodsze dziecko stworzone przez programistów Pylonsów. Powstały na bazie doświadczeń i najlepszych cech szablonów Myghty, Cheetah, Django/Jinja czy Smarty. Największą ich zaletą jest ogromna szybkość i pythonowa filozofia pracy. Programiści Pythona mogą zauważyć, że składnia Mako jest bardzo bliska sposobowi pracy w samym języku Python. Mako posiadają wielką łatwość tworzenia komponentów, ale w sposób bardzo podobny do tego jak Python wykorzystuje swoje moduły. Szablony można także rozszerzać na drodze obiektowego dziedziczenia. Dziedziczenie szablonów może być określane w sposób dynamiczny (tego już nie potrafią np. Cheetah). Dowolny fragment szablonu można również zamienić na komponent z własnym cache. Mako posiadają także składnię modyfikatorów, które spopularyzowane zostały przez Smarty. Działają one jak uniksowe pipes (${zmienna|filter}.

Mako automatycznie kompilują swój kod do modułów Pythona. Można je więc debugować tak jak zwykły kod Pythona (Cheeatah wymaga ręcznej kompilacji). Można je bez problemu używać jako niezależną bibliotekę. Nie są one zależne od jakiegokolwiek frameworku. Można je zintegrować z dowolnym frameworkiem używającym standardu3 WSGI. Użytkownicy frameworka Pylons prawie nic nie muszą robić, bo Mako są już tam przygotowane do pracy.

Ogólnie rzecz biorąc, Mako to – moim zdaniem – najlepszy aktualnie istniejący system szablonów dla Pythona.

Zaś co do frameworków… to coraz bardziej zaczynam nabierać pewności, że przyszłość nie należy ani do Django, ani do Railsów. Nic nie może równać się z możliwościami czystego, 100% frameworka WSGI. Takim jest np. Pylons. Ale o tym, i o “bitwie” Pylons vs. Django i Rails, napiszę już innym razem.

Appendix 2007-01-29: Zobacz też szablony Haml .


1 Poprawnie rzecz mówiąc, powinien napisać swojego helpera. Jeśli więc chcemy wyświetlić w pętli rekordy z bazy, a widok jest czuły na zawartość tych danych, to powinniśmy cała listę rekordów wrzucić do helplera, przeiterować w pętli, dodać dodatkową zmienną i dopiero tak zmodyfikowaną listę przekazać do szablonu.

2 Smarty mimo posiadania własnej składni pozwala na odpalanie pełnego języka PHP: {php}print phpinfo();{/php}. Tak praktyka jest jednak odradzana, bo wprowadza jeszcze większy bałagan niż już jest w PHP.

3 Zobacz artykuł Introducing WSGI: Python’s Secret Web Weapon oraz prezentację koncepcji WSGI na video.

Tagi , , , , , , , , , , , , ,  | 15 comments

Rails 1.2 RC2, Capistrano 1.3.1

Opublikowane przez Jarosław Zabiełło Sun, 07 Jan 2007 02:20:00 GMT

Parę dni temu wyszła nowa wersja Railsów – 1.2 RC2. Wkrótce powinna być wersja finalna. Wyszła też nowa wersja Capistrano 1.3.1, systemu do aktualizacji aplikacji railsowych na serwerach uniksowych.

Tagi , ,  | brak comments

Python vs. Ruby 1.9 YARV. Cz. II

Opublikowane przez Jarosław Zabiełło Sat, 06 Jan 2007 17:44:00 GMT

Z wcześniejszych testów wynikało że Ruby 1.9 (wykorzystujący wirtualną maszynę YARV) jest szybszy od Pythona. Aby zwolennicy Rubiego zbyt się nie cieszyli, przygotowałem test na wywołania rekurencyjne. Najcięższą jest tu funkcja rekurencyjna. Długość 7 znaków daje prawie 900 tys. wywołań rekurencyjnych i w miarę sensowne czasy aby coś zobaczyć. Postanowiłem ją wziąć na rozkład. Tym razem z 10 prób brany jest najlepszy (najkrótszy) wynik.

Python:

try:
  import psyco
  psyco.all()
except:
  pass

from time import time
def wariancje(s, n):
    if n==0:
      yield []
    else:
        for i in xrange(len(s)):
            for c in wariancje(s, n-1):
                yield [s[i]] + c
s = "abcdefg"
nelem = len(s)
i = 0
results = []
for unused in range(10):
  t = time()
  for s in wariancje(s, nelem):
    i += 1
  tmp = time() - t
  results.append(tmp)
  print tmp
print min(results), max(results), nelem, i

Ruby

def wariancje(s, n)
  if n == 0
    yield []
  else
    s.size.times do |i|
      wariancje(s, n-1) { |c| yield [s[i]] + c }
    end
  end
end
t = Time.now
s = "abcdefg"
size = s.size
i = 0
results = []
10.times do
  t = Time.now
  wariancje(s, size) do
    i += 1
  end
  tmp = Time.now - t
  results << tmp
  puts tmp
end
puts "\n#{results.min}, #{results.max}, #{size}, #{i}"

Rezultat:

  1. Python 2.5: 3.86356806755 s.
  2. Python 2.4 4.09678792953 s.
  3. Ruby 1.9: 6.418052 s.
  4. Ruby 1.8.5: 8.000223 s.

Tym razem Python nie dał szans Rubiemu. Jest od niego wyraźnie szybszy. Jednak na obronę można powiedzieć że YARV nie jest tu jeszcze zbyt zoptymalizowany. Wiele opcji optymalizacyjnych ma po prostu wyłączonych, Ruby 1.9 i YARV to na razie kod eksperymentalny. Na razie więc dominacja wydajnościowa Pythona jest niepodważalna.

Tagi , , ,  | 10 comments

Szablony i wzorzec MVC - cz. II

Opublikowane przez Jarosław Zabiełło Sat, 06 Jan 2007 10:35:00 GMT

W pierwszej części wyjasniono czym jest wzorzec MVC, szablony i helpery. Pora na przyjrzenie się szablonom.

Jednym z najważniejszych kryteriów, jest podział “programista czy designer” – ma on duży wpływ na to, dla kogo szablony będą proste a dla kogo – uciążliwe czy złożone. Tzn. czy szablonami będą zajmować się programiści czy też klasyczni web designerzy nie posiadający specjalnie dużej wiedzy o programowaniu? W wypadku designera, szablony posługujące się pełnym językiem programowania mogą być nie lada wyzwaniem. Przeciętny designer posługuje się Dreamweaverem i najchętniej w ogóle by nie chciał programować. A jeśli już, to tylko w zakresie jaki jest mu potrzebny do pracy nad szablonem.

Jeśli zatem mamy zarówno zespół programistów jak i takich designerów, i o nie chcemy aby programiści musieli wszystkim się zajmować, warto wybrać taki rodzaj szablonów, który mógłby być “przyswajalny” dla designerów.

Szablony zgodne z XML.

Najbardziej skrajnym przypadkiem jest użycie takich szablonów, które są “przezroczyste” dla edytorów wizualnie wspomagających projektowanie kodu HTML, np. Dreamweaver. W tym wypadku designer przygotowuje statyczne pliki HTML za pomocą takiego edytora i oddaje go programistom aby wtłoczyli w nie życie – czyli dynamikę kodu wykonywalnego po stronie serwera.

Szablony tego typo są w 100% zgodne z XML. Logika skryptu jest zaś sprytnie ukryta w dodatkowych atrybutach tagów HTML (mówi się tu o TAL czyli tag attribute language – język atrybutów znaczników) Kod zawarty w atrybutach tagów jest ignorowany przez Dreamweavera.

Tego typu szablony, choć są wygodne dla designerów (nic nie muszą dodatkowo robić) są dosyć uciążliwe dla programistów. Są w praktyce bardziej skomplikowane niż te, które dają możliwość użycia pełnego języka. Problemem jest też trudność w generowaniu za pomocą takich szablonów kodu niezgodnego z XML, np. CSS (styli kaskadowych) . Zaletą jednak jest to, że jakakolwiek potrzeba poprawy layoutu sprowadza się do podrzucenia plików designerom. Dreamveaver nie jest w stanie zniszczyć logiki jaką pracowicie programiści dodali do atrybutów HTML. Nie trzeba na nowo za każdym razem jej dodawać.

Python

  • ZPT (Zope Page Templates) – szablony używane przez serwer aplikacji Zope.
  • SimpleTAL – tak jak ZPT, ale działające jako niezależna biblioteka, można je używać bez potrzeby instalacji Zope.
  • Kid – szablony wzorowane też na ZPT ale atrybuty wykorzystują składnię XSLT. Można też tworzyć kolejne szablony na drodze obiektowego dziedziczenia.
  • Genshi – najlepsze w swej klasie. Wzorowane na XSLT (np. można używać XPath) i szablonach Kid. Genshi potrafi kod XML jak i nie-XML. Zostały pierwotnie stworzone dla doskonałego Traca (który aktualnie migruje z szablonów ClearSilver do Genshi).

Ruby

  • MasterView – ciekawe szablony dla Ruby i Railsów. Wykorzystują pełną moc i produktywność Railsów włącznie z szablonami wzorcowymi (layouts), podszablonami (partials) oraz masą helperów jakimi dysponuje Rails. Równocześnie są przezroczyste dla Dreamweavera, więc nadają się doskonale dla designerów operujących tego typu edytorem.

PHP

  • PHP TAL jest pehapową implementacją pythonowych ZPT. Jak widać szablony używane w Zope jest źródłem inspiracji dla całej reszty. :)

Szablony uniwersalne (z uproszczonym językiem)

Jeśli nie mamy do czynienia z grupą designerów bojących się dotykać kodu, można pokusić się o użycie szablonów wykorzystujących uproszczony język programowania.

PHP

Przykładem najlepszych szablonów w tej klasie dla PHPSmarty. Posiadają dosyć wygodną składnię z może jednym wyjątkiem. Domyślne ustawienia dla wstawek kodu wykorzystują dosyć niefortunnie klamry. Sprawia to potem problem dla JavaScript. Na szczęście można to przedefiniować. Poza tym Smarty oferują bardzo wygodne modyfikatory który niczym uniksowe kaskady pipes filtrują zawartość zmiennej: {$zmienna|filtr1|filtr2}. Mają też własny cache (choć oparty tylko na systemie plików) Można też tworzyć własne komponenty(choć w ograniczonym zakresie, np. trudno je iterować w pętli z powodu kolizji nazw – PHP posiada tylko jedną, płaską przestrzeń nazw dla wszystkich funkcji)

Python

Bardzo dobrym przykładem szablonów które można by dać designerom do ręki są szablony używane we frameworku Django. Korzystają one z elementów Smarty i pythonowego Cheetah. Posiadają swoją składnię, ale bardzo prostą i wygodny sposób tworzenia kolejnych szablonów na bazie już istniejących. Tzw. w szablonach Smarty kolejne szablony są tworzone za pomocą cięcia i sklejania kawałków kodu (pliki z szablonami można “includować” do większej całości). W Django można to zrobić także na drodze obiektowego dziedziczenia. Twórcy Django wyciągnęli też lekcję ze Smartów i używają dwóch klamr, zamiast jednej, co nie powoduje kolizji z kodem JavaScript.

base.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <link rel="stylesheet" href="style.css" />
    <title>{% block title %}szablon bazowy{% endblock %}</title>
  </head>
  <body>
  {% block content %}treść szablonu bazowego{% endblock %}
</html>
example.html
{% extends "base.html" %}
{% block title %}Szablon  example.html{% endblock %}
{% block content %}
    <h1>{{ section.title }}</h1>
    {% for story in story_list %}
    <h2>
      <a href="{{ story.get_absolute_url }}">
      {{ story.headline|upper }}
      </a>
    </h2>
    <p>{{ story.tease|truncatewords:"100" }}</p>
   {% endfor %}
{% endblock %}

Szablony Django doczekały się swoich następców/naśladowców.

  • Jinja to szablony implementujące funkcjonalność Django, ale nie są związane z samym frameworkiem. Stanowią oddzielną bibliotekę którą można używać w dowolnym kodzie Pythona. Łatwo je włączyć np. do Pylonsów.

Ruby

  • Liquid – implementacja szablonów Django w języku Ruby. Można je używać np. we frameworku Rails. Nie posiadają wszystkich djangowych cech, m.in. najważniejszej – obiektowości. Nie posiadają też wszystkich helperów jakie są w Django. Jednak pozwalają na używanie ich razem z szablonami standardowymi – ERb.

O kolejnej (w wypadku Pythona – najliczniejszej) grupie szablonów pozwalającej na pełny dostęp do języka będzie w następnej części. Dają one pełny komfort programistom klnącym na ograniczenia szablonów używających swoich własnych języków.

Tagi , , , , , , , , ,  | 3 comments

Ruby najszybciej rosnącym językiem

Opublikowane przez Jarosław Zabiełło Thu, 04 Jan 2007 17:00:00 GMT

Ruby ostro idzie do przodu przesuwając się w górę na liście popularności oczko za oczkiem. Wg TIOBE Programming Community Index Ruby był językiem roku 2006 (w styczniu 2007 Ruby jest 10 pozycji). Z pewnością przyczynił się do tego framework Rails. Pewnie z tego samego powodu (tu jest nią AJAX) rosnie popularność języka JavaScript.

Dawniej popularność języka dyktowało wsparcie dużych firm (Sun dla Javy i Microsoft dla C#). Ale współcześnie dużo większe znaczenie zaczyna mieć “killer application” (“zabójcza” aplikacja promująca język w jakim została napisana) oraz to co twierdzi internet. Stąd zwycięzcy w ostatnich dwóch latach (PHP i Java) w tym roku (2006) są przegranymi.

Można też zauważyć trend rosnącej popularności języków typowanych dynamicznie przy malejącym tych typowanych statycznie. Ale to nic dziwnego. Od czasu przełamania pewnej bariery wydajności sprzętu upadł główny powód od aby nie korzystać z języków dynamicznych na szerszą skalę. (Z pewnością taki Smalltalk narodził się zdecydowanie w złym czasie) Ciekawa jest też uwaga, że większość popularności języka PHP nabijana jest jego problemami z bezpieczeństwem zamiast faktycznym uzyskiwaniem popularności w kręgach programistów.

Interesujące jest również to, że szybko zdobywa popularność język D, o którym do niedawna mało kto słyszał. To dosyć ciekawy język i do tego ekstremalnie szybki (stosuje jakieś agresywne algorytmy kompilacji). Ma też automatyczne zarządzanie pamięcią (garbage collector). Chyba może bez kompleksów iść na wojnę C++, Javą czy C#. (Zobacz porównanie D z innymi językami.)

Z kolei z języków bardziej niszowych odnotować można wzrost popularności Lua (z pozycji 58 na 47) oraz funkcyjnego Haskella (z 56 na 42). Przewiduje się też, że z powodu oczekiwanej migracji z C++ i Visual Basic, w roku 2007 zwycięzcą w kategorii najbardziej popularnego języka, będzie C#.

Tagi , , , , , , ,  | 3 comments

Szablony i wzorzec MVC

Opublikowane przez Jarosław Zabiełło Wed, 03 Jan 2007 19:30:00 GMT

Wzorzec MVC

MVC to skrót od ang. Model – View – Controler (czyli Model – Widok – Kontroler). Jest to jeden z popularniejszych wzorców projektowych (czy “wzorców architektonicznych w oprogramowaniu” jak się mogą czepiać niektórzy puryści) W uproszczeniu, wzorce projektowe to standardowe, sprawdzone rozwiązania dla typowych problemów programistycznych (głównie dotyczą programowania obiektowego). Ich przeciwieństwem są anty-wzorce, czyli to, jak nie należy programować. Typowym antywzorcem jest spaghetti-code, wymieszanie logiki biznesowej z warstwą prezentacji, wszystkiego razem w jednym śmietniku. To typowy styl programowania większości niedoświadczonych programistów PHP.

W skrócie, wzorzec MVC polega na takim podziale kodu, aby składał się z trzech, funkcjonalnie oddzielnych części.

Model

Modelem nazywamy tą część kodu aplikacji, która jest odpowiedzialna za kontakt z danymi biznesowymi, gdziekolwiek są składowane (zwykle w relacyjnej bazie danych). Model nie tylko służy do pobierania i modyfikacji danych biznesowych, ale także zajmuje się ich spójnością i integralnością poprzez odpowiednie mechanizmy walidacji danych. Model służy więc za zarówno strażnika jak i dysponenta danych biznesowych. Bardzo elegancko widać to w Ruby on Rails gdzie przykładowy kod pełniący rolę modelu wyglądać może tak:

class Project < ActiveRecord::Base
  belongs_to :portfolio
  has_one :project_manager
  has_many :milestones
  has_many :deliverables, :through => :milestones

  validates_presence_of :name, :description
  validates_acceptance_of :non_disclosure_agreement
  validates_uniqueness_of :short_name
end

Widok

Widok służy do generowania tego, co moglibyśmy określić jako prezentację naszej aplikacji. Przy czym nie jest określone jak ta prezentacja ma wyglądać. Ogólnie prezentacją jest to wszystko, co aplikacja “wypluwa” na zewnątrz. Nie musi to być żaden “interfejs użytkownika” jak wypisują bzdury co niektórzy. Model MVC nie zakłada przecież tego, kto ma być odbiornikiem wysyłanego strumiena danych. Może to być zarówno pani Genowefa miotająca się po internecie za pomocą Internet Explodera jak i rozbudowany czytnik kanałów RSS, albo jakieś dowolne urządzenie odbierające generowany strumień danych (w tym ostatnim wypadku nie musi to być w ogóle aplikacja webowa) Generowany strumień danych nie musi być w ogóle żadnym tekstem. Mogą to być bowiem równie dobrze strumień danych binarnych.

Zresztą tak właśnie działają aplikacje webowe, które działają wg zasady client-server. Tzn. klient wysyła żądanie, a serwer odpowiada. Przeglądarka Iinternetowa wysyła żądanie do serwera WWW, a on odpowiada jej strumieniem danych. (w wypadku aplikacji webowych serwer wysyła wpierw tekst z nagłówkiem informującym co będzie wysyłane, bo to wynika z zasad protokołu HTTP).

BTW, z tego wynika ważna lekcja odnośnie adresów URL. To co wklepujemy w przeglądarce nie musi mieć żadnego związku z jakimikolwiek ścieżkami na serwerze. Wszystkie technologie, używające jawnych rozszerzeń plików (.asp, .php, .jsp, .aspx itp) są głupie, bo po pierwsze, sugerują że to coś w adresie z końcówką .php to zawsze jest konkretny plik po konkretnym katalogu. Po drugie, bez sensu eksponują użytą technologię, co wiąże trochę ręce tym, którzy by chcieli zmienić wewnetrzny system generujący strony WWW ale bez ruszania starych adresów URL. Po trzecie, spidery takie jak Google nie lubią indeksować stron generowanych dynamiczne. Jeśli zobaczą w adresie znak zapytania to najczęściej to, co za nim stoi jest ignorowane. Odbija sie to na “pozycjonowaniu” tak napisanej aplikacji. I po czwarte takie adresy (z rozszerzeniami i parametrami po znaku zapytania) są najzwyczajniej brzydkie i trudne do zapamiętania. Nie znaczy to, że tak (/?x=1&y=2&z=4)w ogóle nie przekazywać parametrów. Chodzi tylko o to, aby to robić to oszczędnie i tylko wtedy, kiedy jest to naprawdę koniecznie.

Kontroler

Kod, który spina wszystko razem i stanowi serce aplikacji to kontroler. To on pobiera dane z bazy za pomocą modelu i to on wybrane dane wysyła do widoku aby je jakoś zaprezentował dla odbiorcy. Kontroler także dba o takie kwestie jak autoryzacja i autentykacja użytkowników (określa kto może mieć dostęp do poszczególnych części aplikacji). Kontroler zajmuje się też sposobem przepływu danych zgodnie z potrzebami logiki biznesowej.

Szablony i Helpery

Czym są szablony? Szablony przynależą do warstwy Widoku wzorca MVC. Otrzymują dane z kontrolera i na tej podstawie generują kod HTML jaki jest wysyłany do przeglądarki. Szablony powinny być raczej proste tak, aby można było łatwo modyfikować sposób prezentacji bez godzin ślęczenia nad kodem. Najczęściej kwestią prezentacji zajmują się różnej maści webmasterzy i designerzy, czyli ogólniej osoby, które niekoniecznie są zaawansowanymi programistami.

W wypadku kiedy sposób prezentacji jest złożony, aby nie komplikować szablonu stosuje się do pomocy… pomocnika ;) Głównym zadaniem helpera jest takie wstepne przetworzenie danych (jakie kontroler wrzucił do szablonu) aby szablon mogący je wyświetlić był jak najprostszy i jak najbardziej czytelny. Helper dane pobiera od szablonu, modyfikuje je i odsyła je z powrotem. Dzięki temu logika niezbędna do wygenerowania prezentacji jest w szablonie znacznie uproszczona.

Szablony można podzielić na kilka rodzajów, stosownie do oczekiwanych od nich funkcji. Ale o tym (i o strategii wyboru właściwych szablonów) już w drugiej części.

Tagi , , ,  | 18 comments

Pylons + Mako

Opublikowane przez Jarosław Zabiełło Tue, 02 Jan 2007 03:46:00 GMT

Mako – nowy, wydajny system szablonów dla Pylonsów jest już dostępny publicznie na stronie http://makotemplates.org. Można go pobrać za pomocą setuptoolsów, czyli skryptem:

easy_install Mako

Posted in  | Tagi ,  | 3 comments

Ruby 1.9 (YARV) vs. Python, Lua & PHP

Opublikowane przez Jarosław Zabiełło Mon, 01 Jan 2007 18:36:00 GMT

Korzystając z tego, że niedawno do repozytorium Rubiego został dodany YARV (wirtualna maszyna Rubiego) pokusiłem się o małe porównanie wydajności. Jako test użyłem prostego programu jaki pojawił się na liście pl.comp.lang.pyhon (musiałem tylko trochę zwiększyć pętle do 10 milionów iteracji, aby były widoczne jakieś wyniki) Użyty sprzęt: Athlon64 3700+, 64bit Ubuntu 6.0.6.

Sprawdziłem też z ciekawości PHP 5.2 na tym samym sprzęcie. Dla tak prostego testu powinien móc dać z siebie wszystko. Jest jednak wolniejszy od Rubiego 1.9.

Kod dla Pythona:

import time
t=time.time()
a=0
for i in xrange(10000000):
    a += i
print a
print time.time() - t
Kod dla Lua:
t = os.clock()
a = 0
for i = 1,10000000 do
    a=a+i
end
print(a)
print(os.clock() - t)

Kod dla Rubiego:

t = Time.now
a = 0
for i in 1..10_000_000
  a = a+i
end
puts a
puts Time.now - t

Kod dla PHP:

<?php
function microtime_float() {
 $time = microtime();
 return (double)substr($time, 11) + (double)substr($time, 0, 8);
}
$t =  microtime_float();
$a = 0;
for ($i = 0; $i < 10000000; $i++) {
  $a += $i;
}
print "$a\n";
print  microtime_float()- $t;
?>

Wyniki:

  1. Lua: 1.14 s
  2. Ruby 1.9: 1.49 s
  3. PHP 5.2: 1.74 s
  4. Python 2.5: 2.64 s
  5. Python 2.4.3: 2.72 s
  6. Ruby 1.8.5: 3.83 s.

Drugie podejście

Tym razem wynik uśredniam dla 10 prób. Zwiększyłem ilość iteracji do 20 mln. No i… Ruby 1.9 pobił wszystko. Zarówno Pythona jak i Lua! (PHP 5.2 po 30 sek. zgłosił timeout. Musiałem więc uśrednić po 5 wynikach.)

PYTHON

import time
def bench():
    a, t = 0, time.time()
    for i in xrange(20000000):
        a+=i
    return time.time()-t
result = 0
for i in range(10):
  result += bench()
print result / 10.0

RUBY

def bench
  a, t = 0, Time.now
  20_000_000.times { |i| a += i }
  Time.now - t
end
result = 0
10.times { |i| result += bench }
puts result / 10

LUA

function bench()
  a = 0
  t = os.time()
  for i = 1, 20000000 do
    a = a + i
  end
  return os.time() - t
end
result = 0
for x = 1,10 do
  result = result + bench()
end
print(result/10)

PHP

<?php
function bench() {
  $a = 0;
  $t =  time();
  for ($i = 0; $i < 20000000; $i++) $a += $i;
  return time() - $t;
}
$result = 0;
for ($x = 1; $x <= 5; $x++) $result += bench();
print $result / 5.0;
?>

Wyniki

  1. Ruby 1.9: 2.0953268 s.
  2. Lua 5.1: 2.4 s.
  3. Python 2.5: 2.49481592178 s.
  4. Python 2.4.3: 2.71687791348 s.
  5. PHP 5.2: 4.2 s.
  6. Ruby 1.8.5: 9.0153751 s.

Jestem ciekaw kiedy wyjdzie Rails dostosowany do Ruby 1.9. Zapowiada się bardzo obiecująco!

Posted in , ,  | Tagi , , , , ,  | 19 comments