Niedawno na polski rynek weszła firma 1&1 rozdając całkowicie za darmo pakiety hostingowe. Teraz odpowiedź na ich ofertę przedstawia francuski OVH która wygląda znacznie lepiej choć też posiada kilka wad. Zdziwiło mnie pojawienie się tej oferty gdyż nie tak dawno Kamila Włodarczyka(OVH) wypowiadając się na temat 1&1 który sugerował brak zainteresowania ze strony OVH nowym „konkurentem”. Polskie firmy również nie widzą w 1&1 konkurenta, a może są w trakcie komponowania ofert, czas pokaże czy to prawda.

Oferta francuzów prezentuje się nader ciekawie, tak samo jak 1&1 oferują 2-letnie konto typu shared wraz z domeną i to wszystko gratis. W odróżnieniu od swojego konkurenta OVH proponuje nam 20GB pojemności oraz 4TB transferu miesięcznie, możliwość uruchamiania skryptów PHP (4,5,6), Perl oraz Python, a także aplikacji napisanych w C, dostęp do shella, SFTP, „Wirtualny NAS” to tylko kilka opcji (zobacz pełną specyfikację). Wszystko wygląda pięknie i zachęca do zarejestrowania, ale…

No właśnie i tu pojawiają się pewne haczyki i ograniczenia. Na nasz serwer może kierować tylko domena zarejestrowana podczas składania zamówienia (a szkoda), dodatkowo każde konto posiada 10 baz mysql o pojemności 25MB  co w dzisiejszych czasach jest wielkością nikłą pozwalającą na uruchomienie strony małej, młodej firmy lub zainstalowanie własnego bloga. Panel zarządzania (choć brzydki) wygląda znacznie lepiej od oferowanego nam przez 1&1, mamy tu mnóstwo opcji odnośnie domen i naszego serwera wirtualnego, niestety OVH nie przewidziało opcji wielu kont FTP (co przy 1 możliwej domenie nie powinno stanowić problemu).

Regulamin wygląda niestety troszkę gorzej jak w przypadku konkurenta. Po zakończeniu okresu promocji (24 miesiące) możemy przenieść nasze konto na jeden z płatnych pakietów (wybrany przez nas), nie możemy natomiast wydelegować domeny  na inny serwer (no chyba, że coś źle zrozumiałem) przez co jesteśmy niejako skazani na OVH.

Dodam jeszcze, że proces rejestracji usługi wygląda bardzo podobnie do tego z 1&1 choć jest znacznie sprawniejszy i nie nastręcza tylu błędów, OVH również dzwoni do nas z weryfikacją ale i tutaj przebiega ona bez jakichkolwiek problemów, widać, że firma się postarała.

Jeśli miałbym wybierać OVH czy 1&1 z pewnością wezmę tego pierwszego, pomimo mniejszego zaplecza technicznego firma przedstawia znacznie wyższy poziom usług jak i doświadczenia kadry. Dodatkowo OVH to pełne zaplecze techniczne umożliwiające ciągły rozwój naszej witryny, jeśli aktualny pakiet nie wystarcza możemy z łatwością przechodzić na większe, czy też przenieść się na hosting w chmurze.

Od jakiegoś czasu mamy możliwość pracowaniana nowym Netbeans-ie oznaczonym numerem 6.1. Emocje nie opadły jeszcze wszystkim a programiści zaczeli ujawniać tajemnice na temat najnowszego ich dziecka oznaczonego numerem 6.5. Jedną ze znaczących zmian w tej wersji IDE będzie wprowadzenie nowego debugera, choć słowo nowy jest może nad wyrost bo największe zmiany zaszły w jego wyglądzie.

Stary debuger choć służył dobrze nie należał do najwygodniejszych w użyciu:

Netbeans - Stary debuger

Podczas jego użytkowania można było odnieść wrażenie marnotrawienia miejsca i naszego czasu, moim zdaniem dane powinny być skonsolidowane w jednym miejscu, przynajmniej te najważniejsze.

Nowy debugger, zamiast mieścić się na dole, dostępny jest standardowo w lewym bloku programu, w tym samym miejscu co boksy „Project” czy „Files”, a wygląda następująco:

Netbeans - nowy debuger

Ten debugger wydaje się być bardziej przemyślany, integruje on widoki aktualnych sesji, wątków oraz stosu wywołań.
Dodatkowo opcje pozwalają pogrupować wątki według wywołań, pokazać wątki systemowe, pokazać monitory oraz tzw. qualified names które pokazują na czym aktualnie zatrzymał się dany wątek. Oczywiście wątki można pogrupować według nazwy co na pewno ułatwi odnalezienie konkretnego wątku w gąszczu danych.

Ciekawą opcją jest na pewno wstrzymywanie wybranych wątków, dostępne po zaznaczeniu opcji „Show suspend/resume table” w opcjach okna debuggera.

Netbeans - nowy debuger - opcje

Możemy również przełączać się między wątkami, i sprawdzać ich aktualną pozycję w kodzie. Aby wybrać interesujący nas wątek wciskamy kombinację klawiszy [CTRL+8], po wciśnięciu którego pojawia się okno wyboru:

Netbeans - przełączanie mięzdy wątkami

Z którego możemy wybrać interesujący nas wątek. Na powyższej liście dostępne są wątki wstrzymane (przez nas z listy wątków), lub te które aktualnie w procesie debugowania doszły do breakpoint-a (te w ikonce zamiast znaku pauzy mają znak stop).

Ostatnią znaczącą zmianą dokonaną w debugerze jest automatyczne wykrywania zakleszczeń (deadlcock), po wykryciu którego debugger informuje nas komunikatem. Poza tymi zmianami w wyglądzie, poprawiono również sam proces debugowania, dzięki czemu odpluskwianie staje się przyjemniejsze i przebiega szybciej. Więcej informacji można znaleźć na stronach projektu netbeans.org.

JAVA exPress to nazwa nowego magazynku skierowanego do początkujących jak i zaawansowanych programistów Javy. Nie jest droga po kosztuje zaledwie 0zł, ale zawiera bardzo ciekawe treści.

W pierwszym numerze możemy poczytać o Eclipse RCP oraz NetBeans Platform (o którym pisze Marek Kliś i mam nadzieję, że będzie pisał jeszcze więcej), troszkę o debugowaniu kodu, a także refactoring.

Po wstępnych oględzinach wynika na to, że niemal każdy znajdzie coś dla siebie. Jedynym minusem jest okres wydawniczy który wynosi tutaj aż 3 miesiące co jak dla mnie jest długim okresem. Ale jeśli będzie więcej autorów tekstów to może zmniejszy się on do miesiąca.

Nowy magazyn można pobrać ze strony: http://groups.google.com/group/javaexpress uprzednio zapisując się do grupy. Serdecznie zapraszam również do wzięcia udziału w tworzeniu magazynu, gdyż dla autorów przewidziane są nagrody, i to naprawdę cenne.

Z dniem dzisiejszym zamknięto listę wpisów/blogów które uczestniczyć będą w konkursie Eclipse Ganymede Around the World. Dla przypomnienia, konkurs ten ma na celu zachęcić blogerów do opisywania nowych funkcji programu Eclipse Ganymede. Do wygrania są koszulki(na zasadzie kto pierwszy ten lepszy), kurtki oraz najciekawsze wejście na konferencje EclipseCon 2009 lub Eclipse Summit Europe 2008.

Rozstrzygnięcie konkursu nastąpi za kilka tygodni jak poinformowała mnie Lynn Gayowski z Eclipse pisząc również, że udało mi się zdobyć koszulkę.

Mam nadzieję, że jakiś polski wpis zdobędzie jedną z głównych nagród, trzymam kciuki za wszystkich polskich blogerów, ale najmocniej za siebie.

Od jakiegoś czasu otwarta jest rejestracja na tegoroczną już 3 edycję konferencji Java Developer’s Day. Agenda nie jest jeszcze znana, ale patrząc na poprzednie lata zapowiada się naprawdę ciekawie. W chwili obecnej trwa call for papers, więc jeśli lubisz dużo mówić na ciekawe tematy (związane z javą) i możesz pochwalić się swoją wiedzą możesz zgłosić swoją kandydaturę na stronach organizatora. W tym roku organizatorzy liczą na wykłady o tematyce J2EE, a także conieco z programowania mobilnego.

Rejestracja trwa do 30 września, ale jest powód do pośpiechu. Im wcześniej zarejestrujemy się na konferencje tym mniej zaplacimy. Formularz rejestracyjny jak i cennik dostępne sa na stronach jdd.
Ja na pewno będę, nie wiem czy was zapraszać, bo na koniec konferencji będą rozlosowane nagrody, a wiadomo im więcej ludzi tym mniejsze szanse ;)

Od jakiegoś czasu mam na swoim laptopie zainstalowanego Archlinux-a, dystrybucja bardzo przypadła mi do gustu. Działa niesamowicie szybko, jest stabilna i całkiem estetyczna, co prawda wystąpiło kilka problemów, ale społeczność niemal natychmiast mi pomogła. Jak dla mnie dystrybucja świetna, jest tylko jeden szczegół który mnie trapi, a mianowicie manager pakietów (package manager), którym w tej dystrybucji jest pacman.
Sam manager jest całkiem fajny, działa szybko i jest intuicyjny, problemem jego jest system kategoryzowania pakietów. W Archu mamy kategorie(repozytoria):

• Core – dla pakietów podstawowych systemu (kernel, sterowniki, etc.)
• Extra – tam znajdziemy wszystko co nie pasuje do Core-a (X-y, pulpity, serwery)
• Community – pakiety stworzone przez użytkowników, programy niestandardowe, gry

Są jeszcze repozytoria testing oraz unstable, ale z racji, że z nich nie korzystam, sa dla mnie pomijalne.

I teraz zagadka. Chciałbym zainstalować jakiegoś klienta ftp, najlepiej graficzny, co zrobić? Tutaj mamy kilka opcji:

1. wywołać komendę:

pacman -Ss ftp

zalety:

• wbudowana w system
• działa szybko

wady:

• znajduje wszystko co ma w nazwie/opisie ftp
• nieczytelny rezultat

2. poszukać na stronach archlinux.org w dziale z pakietami
zalety:

• czytelniejsze wyniki
• pokazuje szczegóły pakietu

wady:

• trzeba włączyć przeglądarkę
• kliknąć kilka razy po linkach

3. Zapytać/poszukać na forum
zalety:

• można przy okazji dowiedzieć się o zaletach/wadach programu
• zazwyczaj dostaniemy najlepsze rozwiązanie

wady:

• potrzebna przeglądarka
• trzeba się natrudzić i poszukać po google lub archlinux.org
• długi czas oczekiwania na odpowiedź (jeśli piszemy post)

4. Skorzystać z Pacnet-u
zalety:

• podział pakietów na kategorie
• szybka wyszukiwarka
• szybko ładująca się strona i mniej klikania
• podgląd szczegułów pakietu wraz z komendą instalacyjną i zrzutami ekranu

wady:

• potrzebna przeglądarka

Tak Pacnet potrafi znacznie ułatwić szukanie. Dzięki skategoryzowaniu pakietów (na modły repozytoriów Gentoo) znalezienie szukanego programu trwa relatywnie szybko i wygodnie.
Dla estetów (np. dla Mnie) dostępny jest zrzut dzięki czemu możemy wybrać pakiet który dodatkowo odpowiada nam estetycznie.

Projekt choć jest w wczesnej fazie rozwoju działa stabilnie i szybko. Tomek Karbownicki, czyli autor Pacnetu dostaje od użytkowników wiele sugestii i co najważniejsze czyta je z zainteresowaniem, dzięki czemu już za jakiś czas możliwe, że będzie dostępne API, a jak będzie API to się będzie działo.

Nie trzeba chyba mówić nikomu, jak ważne są testy oprogramowania. Każdy program, każda jego funkcjonalność powinny być przetestowane pod względem poprawnego działania. Czym byłby program gdyby nie dawał poprawnych wyników lub czas oczekiwania był na tyle duży, aby wyniki się dewaluowały. Program który jest poprawnie przetestowany na pewno oszczędzi wiele nerwów programistom, klient będzie zadowolony z braku błędów lub jej bardzo małej ilości i wszystko gra.

Sam proces testowania jest jednym z najżmudniejszych zadań w procesie produkcyjnym, zajmuje dużo czasu, a nie zawsze daje zadowalające wyniki. Często testowanie traktowane jest po macoszemu, robione tylko ogólnikowo dla wybranych funkcjonalności lub standardowych danych co tak naprawdę mija się z celem.

No dobra, rzeczywiście testowanie trzeba robić porządnie, ale jak?

Moja propozycja zapewne znana już większości to pisanie testów jednostkowych.
W TDD zazwyczaj pisze się test do danej funkcjonalności jeszcze zanim zaczniemy tą funkcjonalność implementować.

• test określa nam wymagania algorytmu, jeśli napiszemy poprawnie test przedstawia on nam wymagania które musimy spełnić, od tej chwili nie musimy martwić się o spełnienie wymagań w algorytmie tylko o poprawne przejście testu przez algorytm

• już na wstępie może pokazać gdzie wyłonią się możliwe problemy w implementacji,

• w pewnym sensie motywuje do szybkiego a przy tym poprawnego pisania (w końcu algorytm musi przejść test) co zwiększa wydajność pracy

Każda róża ma kolce, tak i tutaj pojawiają się pewne minusy

• niemal dwukrotnie więcej kodu do napisania

• późniejsze zmiany w kodzie trzeba odzwierciedlić zmianami w testach co można by rozumieć jak prowadzenie dwóch projektów w jednym
  

Podstawowe zasady pisania testów

Metodologia pisania testów jest prosta. Piszemy test który sprawdza daną funkcjonalność pod względem poprawności algorytmicznej. Po czym implementujemy tą funkcjonalność tak aby przechodziła test. Cały kod pisze się w tak zwanych iteracjach:

Iteracje trwają zazwyczaj od kilku do kilkunastu minut w zależności od rozmiaru problemu. Cały kod uznaje się za poprawny jeśli przejdzie swój test. Koniec każdej iteracji powinien być zakończony przez pozytywne przejście testu.
Ważne jest aby kod źródłowy testów pisany był z równą dokładnością co kod źródłowy aplikacji, jest on tak samo ważny i nie powinien być traktowany po macoszemu.

Należy również pamiętać, że program który poprawnie przechodzi testy niekoniecznie może działać poprawnie. Zapytacie pewnie po co w takim wypadku pisać testy?
Otóż testy same w sobie pozwalają wykryć większość błędów programistycznych, a wykryty błąd jest natychmiastowo lokalizowany i opisany przez test.

Wyobraź sobie, że prowadzisz duży projekt. Projekt składający się z kilkunastu/kilkudziesięciu modułów które ze sobą współpracują. Projekt działa całkiem dobrze, jednak po kilku miesiącach szef kazał Ci zmienić jakąś funkcjonalność w jednym z modułów. Sama zmiana może i trwa kilka minut, ale z racji że jeden moduł jest zależny od drugiego nie jesteś pewien, czy ta zmiana nie pociągnie za sobą nieprzewidzianych problemów z modułami zależnymi. Rzadko się zdarza by programista pamiętał każdy aspekt pisanego programu, szczególnie gdy jest on rozbudowany. Jeden moduł może być wykorzystywany w wielu miejscach które trzeba sprawdzić.
Tu również z pomocą przychodzi pisanie testów. Jeśli będziemy stosować się do zaleceń TDD i każdy moduł/klasa będzie miała test, to taka poprawka nie stanowi dla nas najmniejszego problemu.
Wystarczy wprowadzić zmiany i uruchomić testy dla całego projektu. Jeśli jakaś nieścisłość występuje zostanie ona wykryta a programista powiadomiony o tym. Dzięki temu można zaoszczędzić naprawdę dużo czasu i nerwów.