Brak czasu i magisterka

Wszystkich zaniepokojonych brakiem nowych postów (są tacy w ogóle? ;) chciałem uspokoić, że blog nie umarł, tylko chwilowo przeszedł w stan uśpienia. Powodów takiej sytuacji jest kilka: dużo pracy w pracy, zamieszanie sesyjno-zaliczeniowe i najważniejsze, moja magisterka.

Nadchodzi czas intensywnego pisania, więc moja uwaga skoncentrowała się właśnie na tym. Przy okazji miałem okazję "zaprząc" do pomocy społeczność polskich programistów Java, bo miałem kilka wątpliwości odnośnie zakresu mojej pracy. Odpowiedzi kilku osób w tym temacie na GoldenLine oraz w wątku "Porównanie frameworków JEE - prośba o pomoc [trochę długie]" na pw.comp.lang.java dały mi trochę wskazówek, co jeszcze warto wziąć pod uwagę w mojej pracy i jakie jeszcze frameworki w niej można zawrzeć.

W tej chwili główna część pracy będzie wyglądała następująco:

ROZDZIAŁ VIII: PORÓWNANIE FRAMEWORKÓW
VIII.1. PORÓWNANIE BUDOWY
VIII.1.1. Architektura
VIII.1.2. Cykl życia żądania
VIII.1.3. Sposób konfiguracji
VIII.1.4. Warstwa prezentacji
VIII.1.5. Budowa przykładowej aplikacji "Hello World"

VIII.2. PORÓWNANIE FUNKCJONALNOŚCI
VIII.2.1. Walidacja i automatyczna konwersja danych
VIII.2.2. Stanowość interakcji i obsługa konwersacji
VIII.2.3. Nawigacja między stronami
VIII.2.4. Bezpieczeństwo: uwierzytelnianie i autoryzacja, wsparcie protokołu HTTPS
VIII.2.5. Internacjonalizacja
VIII.2.6. Wsparcie dla captcha
VIII.2.7. Przyjazne adresy URL
VIII.2.8. Integracja z technologią AJAX
VIII.2.9. Prezentacja danych na wykresach
VIII.2.10. Integracja z frameworkiem Spring
VIII.2.11. Tworzenie własnych komponentów

VIII.3. PORÓWNANIE DOSTĘPNOŚCI I POPULARNOŚCI
VIII.3.1. Literatura polsko i obcojęzyczna
VIII.3.2. Aktywność list dyskusyjnych
VIII.3.3. Popularność wśród pracodawców i w Internecie

VIII.4. PORÓWNANIE WYDAJNOŚCI I SZYBKOŚCI DZIAŁANIA
VIII.4.1. Statystyki obciążenia serwera
VIII.4.2. Pomiar szybkości działania aplikacji przy dużej liczbie użytkowników

Ciągle nie podjąłem ostatecznej decyzji jakie frameworki chcę porównać. Porady innych programistów trochę mi zamieszały w głowie i w tej chwili waham się pomiędzy kilkoma opcjami. Pewniakiem jest Wicket, który znam i lubię :) Po głowie chodzą mi również:
- Java Server Faces, bo jest popularny, wspierany przez Sun i warto byłoby go lepiej poznać. Jednak z JSF jest moim zdaniem taki problem, że aby coś sensownego na nim zbudować, trzeba skorzystać z paru innych bibliotek, a w takim wypadku porównywanie JSF z innymi może trochę stracić sens. Ale to sprawa do przemyślenia.
- Struts lub Struts2, całkiem inne podejście niż Wicketa i JSF, więc do porównania jak znalazł, bo pewnie pojawią się ciekawe wnioski odnośnie różnic między filozofią komponentowo-obiektową, a requestowo-akcyjną.
- i inne: GWT - od Google, więc nie może być złe :), Spring MVC, Tapestry 5 (fajny, choć, gdy był w fazie beta to mocno się do niego zraziłem), Stripes (trochę starszy framework i trochę podobny do Struts).

Jak widać opcji jest sporo, a czas nie jest nieograniczony, bo jednak im szybciej się z tym ogarnę, tym lepiej :) Dlatego temat zostaje do przemyślenia, dopóki nie uporam się z aplikacją w Wicket. Wtedy będę musiał podjąć decyzję co dalej.

Po odwiedzinach u promotora doszła jeszcze jedna sprawa: doprecyzowanie celu pracy tak, aby był bardziej magisterski niż inżynierski. Ma to być rozwiązanie jakiegoś bardziej ogólnego problemu i wyciągnięcie bardziej ogólnych wniosków, a nie tylko napisanie kilku aplikacji w różnych frameworkach. Sugestia promotora jest taka, żeby pójść następującym tropem:
- wielość rozwiązań (bibliotek) dla aplikacji webowych dla małych i średnich firm
- problemy z wyborem odpowiedniej drogi
- różnorodność aplikacji, ale spora część wymagań się powtarza
- dobranie rozwiązania nie pod kątem tego, co znają programiści, ale pod kątem tego, co najlepiej spełni wymagania klienta
- nie ma rozwiązań idealnych, ale są takie, które najlepiej sprawdzają się przy wymaganiach, na które klient kładzie największy nacisk.

Jak widać mam co robić, więc wakacje zapowiadają się pracowicie :) Niestety temat SCWCD na razie został odłożony na półkę, głównie z powodu nacisków promotora na szybsze ogarnięcie pracy dyplomowej. Ale na pewno do niego wrócę, bo mam dość jasno nakreślony plan ścieżki rozwoju jako programista i certyfikat chcę zrobić. Postaram się też na bieżąco relacjonować postępy w pisaniu pracy, a że poznam sporo nowych rzeczy to i tematów do wpisów też mam nadzieję nie zabraknie. Stay tuned :)

NNTP, Apache Commons Net i polskie znaki w wiadomościach

Jak co weekend, dzisiaj też usiadłem do magisterki. Spośród kilku rzeczy, które sobie zaplanowałem pojawił się temat wysyłania wiadomości/powiadomień na wewnętrzną grupę dyskusyjną mojego akademika za pomocą protokołu NNTP.

Szybkie rozpoznanie pokazało, że całość jest prosta jak przysłowiowa budowa cepa i nie powinna sprawiać żadnych problemów. Poniżej mała klasa pokazująca sposób wysyłania posta na grupę pw.test przy pomocy biblioteki Apache Commons Net.

package pl.tdziurko.nntptest.main;

import java.io.Writer;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.SimpleNNTPHeader;

/**
 *
 * @author Tomasz Dziurko
 */
public class Main {

    public static void main(String[] args) throws Exception {

        NNTPClient client = new NNTPClient();
        client.connect("news.ustronie.pw.edu.pl");

        client.selectNewsgroup("pw.test");
        Writer postArticle = client.postArticle();

        SimpleNNTPHeader headers =
            new SimpleNNTPHeader("Tomasz Dziurko <tdziurko@gmail.com>", "Test kodowania polskich znaków");
        headers.addNewsgroup("pw.test");
        headers.addHeaderField("Mime-Version", "1.0");
        headers.addHeaderField("Content-Type","text/plain; charset=UTF-8");
        headers.addHeaderField("Content-Transfer-Encoding", "8bit");

        postArticle.write(headers.toString());
        postArticle.write("ąęóśłżźćń - test polskich znaków\r\n");
        postArticle.close();

        client.completePendingCommand();
        
        client.disconnect();
    }

}

Wszystko działało zgodnie z oczekiwaniami do momentu, gdy zacząłem w treści wiadomości używać polskich znaków. Zamiast "ąęóśłżźćń" pojawił się następujący obrazek:


Kombinacje z ustawianiem innego kodowania w nagłówku wysyłanej wiadomości, zmiana kodowania całego projektu czy nawet zmiana ustawień czytnika (tak tak, zacząłem winić nawet biednego Thunderbirda ;) ) nic nie pomogły. Wtedy postanowiłem zajrzeć do źródeł biblioteki ze stajni Apache'a i po krótkim śledztwie znalazłem winowajcę: klasę org.apache.commons.net.nntp.NNTP.

public class NNTP extends SocketClient
{
    /*** The default NNTP port.  Its value is 119 according to RFC 977. ***/
    public static final int DEFAULT_PORT = 119;

    // We have to ensure that the protocol communication is in ASCII
    // but we use ISO-8859-1 just in case 8-bit characters cross
    // the wire.

    private static final String __DEFAULT_ENCODING = "ISO-8859-1";

    ...

    /***
     * Initiates control connections and gets initial reply, determining
     * if the client is allowed to post to the server.  Initializes
     * {@link #_reader_} and {@link #_writer_} to wrap
     * {@link SocketClient#_input_} and {@link SocketClient#_output_}.
     ***/
    @Override
    protected void _connectAction_() throws IOException
    {
        super._connectAction_();
        _reader_ =
            new BufferedReader(new InputStreamReader(_input_,
                                                     __DEFAULT_ENCODING));
        _writer_ =
            new BufferedWriter(new OutputStreamWriter(_output_,
                                                      __DEFAULT_ENCODING));
        __getReply();

        _isAllowedToPost = (_replyCode == NNTPReply.SERVER_READY_POSTING_ALLOWED);
    }

    ...

}

Jak widać przy tworzeniu zarówno Writera i Readera zastosowano kodowanie ISO-8859-1, czyli nie posiadające w swoich zasobach polskich ogonków. Gdy zaczynałem się zastanawiać w jaki sposób zbuduję całą bibliotekę po zmianie wartości zmiennej __DEFAULT_ENCODING na "UTF-8", zauważyłem w archiwum ze źródłami plik pom.xml. Alleluja! - pomyślałem - Maven lekiem na moje problemy. Teraz wszystko powinno pójść niczym z płatka :)

NetBeans 6.5 z zainstalowanym pluginem pozwala na otwieranie projektów z pliku pom.xml, więc już w IDE mogłem dokonać modyfikacji biblioteki. Następnie uruchomiłem testy i ku mojemu zdziwieniu okazało się, że jeden z nich nie zakończył się sukcesem. Szybkie pytanie do Wielkiego Googla i już wiedziałem, że pewna metoda testująca działa bez problemów tylko na anglojęzycznych systemach operacyjnych (przenośność Javy ;) ). Żeby już nie przedłużać zabawy ze źródłami po prostu ją wykomentowałem i uruchomiłem testy ponownie.


Ufff, udało się :) Teraz mogłem zbudować zmodyfikowaną bibliotekę i podczepić ją do mojego projektu wysyłającego wiadomość testową.
Poniżej można zobaczyć efekty, wszystkie polskie znaki są prawidłowo wysyłane na grupę dyskusyjną.