package foo;

public class Licznik {
    private static int liczba;
    public static synchronized int getLiczba() {
        liczba++;
        return liczba;
    }
}

to kod wstawiony do strony JSP korzystający z licznika powinien wyglądać następująco:
<% out.println(foo.licznik.getLiczba()); %>

Oprócz znacznika skryptletu który został przed chwilą zaprezentowane w stronach JSP można spotkać również inne, np.

• Dyrektywa: <%@ ... %>, np: <%@page contentType="text/html; charset=UTF-8" %> ustawia typ treści
• Wyrażenie <%= ... %>, np. <%= Licznik.getLiczba() %> spowoduje wyświetlenie aktualnego stanu licznika.
• Definicja: <%! ... %>, umożliwia definiowanie zmiennych i metod które są później „wstrzykiwane” do tworzonej klasy servletu. W ramach tych znaczników jesteśmy upoważnieni do przeciążenia metod jspInit oraz jspDestroy które są wywoływane odpowiednio przy powoływaniu servletu do życia i przy jego usuwaniuz kontenera. Z uwagi na fakt że definicje metod zawartych w obrębie znacznika defincji stają metodami servletu, nie ma tu dostępu do zmienny request i response

Jak wspomniałem każda strona JSP jest servletem. Strona jest tłumaczona przez kontener na odpowiedni servlet. Wykorzystanie różnych znaczników do zaprezentowania innego typu zawartości ułatwia kontenerowi konwersję. I tak dyrektywy są używane aby kontrolować jak kontener ma przetłumaczyć a następnie wykonać kod strony, skryptlety są po prostu przepisywane do kodu servletu natomiast wyrażenia są przekazywane jako parametry odpowiednich funkcji.

Aby servlet mógł być servletem a nie zwykłą klasą musi implementować interface javax.servlet.Servlet.

interface javax.servlet.Servlet
{
  void destroy();
  ServletConfig getServletConfig();
  String getServletInfo();
  void init(ServletConfig config);
  void service(ServletRequest req, ServletResponse res);
}

Metoda destroy jest uruchamiana przez serwer aplikacji celem zniszczenia servletu. Dwie metody init oraz service mają za zadanie „zarządzanie” cyklem życia servletu. Pierwsza z wyżej wymienionych metod jest wywoływana tylko raz w całym cyklu życia servletu. Ma to zawsze miejsce przed obsługą przez servlet jakichkolwiek żądań klientów. Natomiast zadaniem metody service jest obsługa żądania. Metoda przyjmuje 2 parametry, pierwszy z nich definiuje żądanie skierowane do serwera, a drugi będzie zawierał wygenerowaną odpowiedź.

Tworzenie za każdym razem klasy implementującej ten interface może się okazać zadaniem dosyć żmudnym dlatego do dyspozycji mamy jeszcze 2 klasy: GenericServlet – klasa obsługująca żadania nie zależenie od protokołu, jednak wymaga samodzielnej implementacji metody service, oraz klasa HttpServlet do wykorzystania wraz z protokołem HTTP. Oczywistą zaletą tej klasy jest w pełni zaimplementowany mechanizm sterownia życiem servletu. Rola programisty ogranicza się właściwie do przysłonięcia metod typowych dla żadań HTTP takich jak POST (metoda doPost), GET (doGet), HEAD, OPTIONS, PUT, TRACE, DELETE. Nie trzeba chyba nikogo przekonywać że w 99% przypadków nadpisywana jest jedna z dówch pierwszych metod lub obie.

Kompilator zrobi dokładnie to co chcesz. DOKŁADNIE!

i właśnie dlatego trzeba uważać. Ta zagadka jak i pozostałe ma na celu zwrócenie uwagi na miejsca które wydają się oczywiste a moga wprowadzić wiele zamieszania i niepotrzebnych nerwów. W końcu nie od dziś wiadomo że najgroźniejsze błędy znajdują się w „kodzie który napewno jest dobrze”. Tym razem zagadka wymaga trochę więcej od czytelnika, nie wystarczy znajmość C++, trzeba się jeszcze wykazać odrobiną znajomości biblioteki boost.
Na problem oczywiście musiałem trafić na klika godzin przed oddaniem projektu, była godzina 5:14 i nie trudno zgadnąć że odchodził istny eXtreme programming – programowanie gry sieciowej – 2 osoby – 24h. Dojście do tego co jest źle zajęło dobrą godzinę…
Poniższy kod przdstawia 4 najprostsze możliwe przypadki użycia boost::bind w połączeniu z boost::signal, nie różnią się między sobą bardzo:

#include <boost/signal.hpp>
#include <boost/bind.hpp>

#include <iostream>	

class Test
{
public:
  Test(int x) : x_(x)
  {}

  void metoda1(int i);

  int x_;
};

void Test::metoda1(int i)
{
  x_ += i;
}

int main()
{
  typedef boost::signal<void (int)> event_sig;
  event_sig signal;

  Test* t1 = new Test(0);
  Test* t2 = new Test(0);
  Test t3(0);
  Test t4(0);

  signal.connect(boost::bind(&Test::metoda1, *t1, _1));
  signal.connect(boost::bind(&Test::metoda1,  t2, _1));
  signal.connect(boost::bind(&Test::metoda1, &t3, _1));
  signal.connect(boost::bind(&Test::metoda1,  t4, _1));

  for(int i = 0; i < 10; ++i)
  {
    signal(1);
  }

  std::cout << "t1::x = " << t1->x_ << std::endl;
  std::cout << "t2::x = " << t2->x_ << std::endl;
  std::cout << "t3::x = " << t3.x_ << std::endl;
  std::cout << "t4::x = " << t4.x_ << std::endl;
  std::cout << "Powinno(?) byc 10" << std::endl;
}

Mogło by się wydawać że w wyniku, na ekran zostanie wypisana 4 razy liczba 10. Ci bardziej podejrzliwi zaczną się zastanawiać, jaki wpływ mogą mieć te „dodatkowe” symbole dostawione wewnątrz boost::bind. Okazuje się że w przypadkach 1 i 4 ( t1 i t4 ), mimo wysyłania sygnału, wartość pola x_ nie ulega zmianie, natomiast w pozostałych ulega. Dlaczego ?
Rozwiązanie tego problemu jest bardo proste, otóż tworząc binda, biblioteka boost w zależności od sposobu przekazania obiektu na rzecz którego zostanie wywołana metoda, utworzy jego kopię (internal copy) lub będzie operować na przekazanym obiekcie.
Niby proste, ale trzeba mieć świadomość o istnieniu takiego mechanizmu. Nie trudno się „przejechać” na złym przekazaniu obiektu, a tu nie będzie sugestywnego „segmentation fault”….

#include <iostream>

int main()
{
    for(double i = 0; i != 1; i+= 0.1)
    {
        std::cout << "Obrot petli i = " << i << std::endl;
    }
}

Odpowiedź na to pytania wymaga trochę więcej niż tylko znajomości składni języka. Na pierwszy rzut oka wydawać się może że pętla dokona 10 obrotów a następnie program się skończy. Gdyby to był 1 kwietnia wiele osób uznało by za żart stwierdzenie że pętla będzie działać w nieskończoność, choć tak naprawdę jest !! Program nie zauważy że dobił do 1 i powinien przestać działać. Co więcej, na ekran zostanie wypisana liczba 1 a mimo to działanie nie zostanie przerwane. Wyjaśnienia tego przypadku, trzeba szukać w komputerowej reprezentacji liczby 0.1

WebsiteUser:
  tableName: website_users
  columns:
    UserId:   { type: integer(8), primary: true, autoincrement: true }
    GroupId:  { type: integer(8), notnull: true  }
    Username: { type: string(255), notnull: true }
    Password: { type: string(255), notnull: true }
    Email:    { type: string(255), notnull: true }
  indexes:
    uniqueusername: { fields: [Username], type: unique }
    uniqueemail:    { fields: [Email], type: unique    }
  relations:
    WebsiteGroup: { class: RuczajGroup, local: GroupId, foreign: GroupId }
  options: { type: INNODB, collate: utf8_polish_ci, charset: utf8 }

to ustawienia nazwy tabeli i pól wygląda dość dziwnie, mianowicie nazwa tabeli nie jest faktyczną nazwą tabeli tylko czymś w rodzaju nazwy encji. Pola też należy pisać dokładnie takimi samymi literami(chodzi o wielkość) jak w pliku YAML, mimo że tworzone tabele składają się wyłącznie z małych liter. W sumie wydaje się to logiczne, ale trochę czasu mi zajęło dojście co oni tak naprawdę chcą a wyjątek typu
('The supplied parameters to Zend_Auth_Adapter_Doctrine_Record failed to produce a valid sql statement, please check table and column names for validity'); nie podpowiada zbyt wiele.

Poprawny kod autoryzacji wygląda zatem tak:

$dbConnection = Doctrine::getConnectionByTableName('website_users');
$authAdapter = new Zend_Auth_Adapter_Doctrine_Table($dbConnection);
$authAdapter->setTableName('WebsitejUser')
                  ->setIdentityColumn('Username')
    		  ->setCredentialColumn('Password')
		  ->setCredentialTreatment('md5(?)');

Teraz należy utworzyć nowy katalog, koniecznie musi się nazywać LocalUser i być umieszczony w głównym katalogu FTP, przeważnie ftproot w inetpub. Dla każdego użytkownika możemy utworzyć VirtualDirectory i wskazać miejsce do którego ma mieć dostęp użytkownik. Ważne jest aby nazwa katalogu była identyczna jak nazwa użytkownika. Zadziała to w ten spsób że podczas logowania użytkownika np. jankowalski zostanie przeszukany katalog LocalUser w poszukiwania katalogu jankowalski, jeżeli się taki znajdzie to użytkownik zostaje zalogowany i skierowany do tego katalogu. W przeciwnym wypadku najprawdopodobniej spotka się on z odmową dostępu. VirtualDirecotry ma to do siebie że tylko wskazuje na jakiś fizyczny katalog, zatem można go ustawić aby wskazywał na katalog w którym można umieścić swoją stronę WWW i potem ją obejrzeć w przeglądarce np. C:\Sites\JanCompany\.

Aby wszystko działało należy pamiętać o nadaniu odpowiednich praw dostępu dla odpowiednich użytkowników. Użytkownik jankowalski powinien móc zapisywać i odczytywać dane ze swojego katalogu i to jest oczywiste. Nie oczywiste jest to że musi on mieć także prawo do wyświetlenia katalogu głównego ftproot mimo że nie ma do niego bezpośredniego dostępu. Tak więc należy zezwolić użytkownikowi jankowalski na List katalogu głównego, ustawia się to we właściwościach folderu.

class A
{
public:
  A() {
    fun();
  }

  virtual void fun()  {
    std::cout << "A::fun" << std::endl;
  }

  void fun2()  {
    fun();
  }
};

class B : public A
{
  void fun()  {
    std::cout << "B::fun" << std::endl;
  }
};

int main() {
  A* a = new B();
}

Poprawna odpowiedź:
A::fun
dlaczego? W konstruktorze nie działa wirtualność. Zatem to ja miałem racje !
Za to gdyby dopisać jeszcze

a->fun2();

to byśmy zobaczyli już B::fun. Problem zapewne rzadko w praktyce występuje ale jest to genialne zadanie na wszelkiej maści testy mające sprawdzić zaawansowaną znajomość mechanizmów języka C++

Python to język bardzo wysokiego poziomu w związku z tym tworzenie aplikacji w nim powinno być szybkie. I może samo tworzenie jest, ale jak już się Pythona dobrze zna. Dostarczona dokumentacja jest średnio czytelna i korzystanie z niej nie było zbyt wygodne. Żeby korzystać z docs’ów Pythona trzeba mieć chyba jakiś dar.

„Although both PHP and Python have excellent core documentation, Python’s is more extensive and generally higher quality.”

No niestety nie moge się z tym zgodzić…
Nie wiem jakie są powody że ludzie tak się zachwycają owym Pythonem. Ja bardzo się zniechęciłem gdy zobaczyłem że nie ma ani kwantyfikatowór dostępu, ani definicji pól klasy. Pola można sobie dodawać dowolnie w tracie działania, żadne deklaracje nie są wymagane. To takie wbudowane __set i _call z php.
Napisanie programiku do logowania się do „wioski” w grze plemiona zajęło mi koło 2,5h.
Linii mamy 32, co daje jakie 4,5 minuty na napisanie linii, a wiadomo że nie wszystkie linie są sobie równe.

import urllib, urllib2, cookielib

class PlemionaTool :
  def connect(self, username, password, world) :
    try:
      cookies = cookielib.CookieJar()
      self._world = world
      self._connection_handler = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookies))
      headers = {"User-Agent": "Mozilla/5.0 (X11; U; Linux i686) Gecko/20071127 Firefox/2.0.0.11"}
      login_data = urllib.urlencode({"user": username,
                                              "clear": "true",
                                              "password": password,
                                              "server": world,
                                              "login-btn-input": "",
                                              "cookie" : "false"})
      request_http = "http://www.plemiona.pl/index.php?action=login"
      req = urllib2.Request(request_http, login_data, headers)
      self._connection_handler.open(req)
    except urllib2.HTTPError:
        print "Jakis zonk"

  def headquater(self) :
    response = self._connection_handler.open("http://" + self._world +     ".plemiona.pl/game.php?village=NUMER_WIOSKI&screen=main")
    page = response.read()
    return page

def main():
  pt = PlemionaTool()
  pt.connect("LOGIN", "HASLO", "SWIAT")
  print pt.headquater()

if __name__ == '__main__':
  main()

Z zalet można wymienić wysokopoziomowość. Nie trzeba się męczyć z odbiorem, obróbką i wysyłaniem cookies, nie trzeba się też bawić z przechwytywć żadnego wyjątku jak np. HTTPRedirect z Delphi.