Już niedługo, bo za niecały miesiąc, odbędzie się czwarta edycja konferencji 4Developers. Miałem okazję uczestniczyć w dwóch poprzednich edycjach i bardzo chciałbym wziąć udział w tym roku, niestety z powodu kilku drobnych zawirowań, muszę tym razem odpuścić sobie tę przyjemność. Bardzo tego żałuję, ponieważ w tym roku interesujących tematów na pewno nie zabraknie. Do najciekawszych moim zdaniem można zaliczyć między innymi Tworzenie i wdrażanie z użyciem strategii chmur hybrydowych, Jak wybrać odpowiednią bazę NoSQL, REST i ograniczenia hypermediów, czy Hadoop w Hurtowni Danych nk.pl. Oczywiście nie są jedyne interesujące sesje, których pełną listę znajdziecie na stronie poświęconej konferencji. Podobnie jak w zeszłych latach i tym razem do wyboru są 4 ścieżki. Są to Java, Zarządzanie projektami IT, Wydajność i skalowalność oraz PHP. Oprócz samych sesji wykładowych na uczestników czekają warsztaty oraz konkursy z nagrodami.
Ale do rzeczy. Mam dla Was wejściówkę dla jednej osoby. Co trzeba zrobić, aby ją wygrać? Napiszcie w komentarzu na jaką sesję chcielibyście najbardziej pójść i dlaczego? Komisja egzaminacyjna w tajnym składzie zadecyduje o zwycięzcy. Na odpowiedzi macie czas do końca weekendu (wiem, wiem – ładna pogoda, a ja wymyślam jakieś zadanie na weekend), czyli do północy 25 marca. I nie zapomnijcie, że w ten weekend przestawiamy zegarki o godzinę do przodu.
Strona konferencji – 4developers.org.pl.
Ostatnimi czasy, mam okazję tworzyć dość duże ilości testów jednostkowych. Zwykle tworze je do cudzego kodu, co pozwala mi w pewnym sensie ocenić jego jakość. Zapytacie może, jak proces pisania testów jednostkowych do istniejącego kodu pozwala ocenić jego jakość ?
Otóż, pewna stara programistyczna fama głosi, że gdy kod jest łatwo testowalny, to prawdopodobnie jego jakość, a przynajmniej architektura będzie wysokiej jakości. Automatycznie na myśl przychodzi takie proste rozwiązanie, że skoro kod ma być łatwo testowalny, to najlepiej by było zacząć jego tworzenie od napisania testów. Takie podejście nazywa się TDD (Test Driven Development). Pewnie wielu z Was słyszało o takim podejściu, natomiast jeżeli pracujecie w typowej firmie wytwarzającej „stronki”, to pewnie nie mieliście wielu okazji by zastosować takie podejście.
Oczywiście nie koniecznie jest to grzech – w prostych projektach zastosowanie TDD może być dyskusyjne ze względu na narzut czasowy jaki generuje. Znając jednak życie, prosty projekt zwykle przeradza się w projekt skomplikowany, którego skali nikt nie przewidział.
Abstrahując jednak od TDD, chciałbym się podzielić z Wami, moimi spostrzeżeniami na temat typowych „wzorców” w kodzie, które znacząco obniżają jego testowalność. Przy okazji zaproponuje sposoby ich rozwiązania poprzez refaktoring kodu oraz omówię konsekwencje jakie niosą za sobą poszczególne antypatterny.
Tak więc, jeżeli spotkasz jeden z podanych poniżej przypadków – wiedz, że coś się dzieje 
Kilka przykładów kodu, żeby było wiadomo o co chodzi:
Przykład nr. 1:
class Bar(var i: Int) {}class TestSubject1 { def doFoo(bar: Bar){ bar.i = 10 } }def testCase1() { val bar = new Bar(0) val testedObject = new TestSubject1 testedObject.doFoo(bar) if(bar.i == 10){ println("true") } else { println("false") } }view raw gistfile1.scala This Gist brought to you by GitHub.
Mamy zdefiniowane dwie klasy – Bar, która ma property „i” oraz klasę TestSubject1 która jest testowana przy użyciu funkcji testCase1. Co jest złego w tego rodzaju kodzie ? Przede wszystkim następuje niejawna manipulacja obiektem klasy Bar. Poza tym, jako, że metoda ma typ void (w tym przypadku w Scali jest to Unit), programista, który chce użyć takiego kodu, tak naprawdę nie wie jaki jest efekt jego działania. Kod po refaktoringu:
class TestCase1refactored { def doFoo(bar: Bar): Bar = { val result = new Bar(bar.i + 10) return result } }def testCase1refactored() { val bar = new Bar(0) val testedObject = new TestSubject1refactored() val result = testedObject.doFoo(bar) if(result.i == 10){ println("true") } else { println("false") } }view raw gistfile1.scala This Gist brought to you by GitHub.
Jak widać, metoda po refaktoringu zwraca jakąś konkretną wartość, poza tym zamiast zmieniać stan obiektu, tworze nowy ze zmienioną wartością, dzięki czemu unikam modyfikowania globalnego stanu.
Przykład nr.2:
Użytkownicy pracujący w serwisach intranetowych wielokrotnie stoją przed koniecznością wydrukowania jakiegoś dokumentu czy formularza celem zachowania papierowej dokumentacji czy wydania papierowej wersji klientowi. Dotychczas realizowałem to tworząc i otwierając w nowym oknie dokument PDF gdzie użytkownik musiał ręcznie wybrać opcję Drukuj. Teoretycznie to działa, aczkolwiek jest troszkę upierdliwe. Jednakże ostatnio przypadkowo trafiłem na informację że PDF może zawierać swój kod JS więc postanowiłem troszkę poeksperymentować.
Sytuacja z życia wzięta – pielęgniarka pobiera próbki do badań laboratoryjnych. Na stronie ma listę zleconych testów oraz informacje jakie i ile próbek pobrać. Na każdą próbkę powinna wydrukować naklejkę z unikalnym kodem kreskowym. Problemem jest to drukowanie: naklejki są małe, kod długi i mało czytelny bez czytnika – przy drukowaniu „masowym” po pobraniu wszystkich próbek łatwo o pomyłkę. Drukowanie każdego kodu w miarę dodawania jest znowu bardzo niewygodne – kliknięcie „dodaj próbkę”, czekanie aż otworzy się okienko z plikiem PDF, kliknięcie drukuj, potwierdzenie ustawień drukowania (wybrać drukarkę do etykiet) i druk, zamknięcie okienka z plikiem PDF. Na szczęście jest na to sposób.
Tym sposobem jest właśnie Acrobat JavaScript.
Dla zainteresowanych dokumentacja znajduje się tutaj: http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/javascript/AcroJS.pdf
Co prawda AJS nie daje nam pełnych możliwości w zakresie drukowania dokumentu, ale już to co jest może nam znacznie ułatwić życie. Dzięki temu udało mi się zredukować cały proces do kliknięcia „dodaj próbówkę” i kliknięcia OK w komunikacie że PDF chce coś wydrukować.
Zaczynamy od naszego dokumentu PDF. Jako kreatora używam znakomitej biblioteki TCPDF, w której można znaleźć metodę IncludeJS(). Mój kod JS wygląda następująco:
// Ustawieniadrukowania var pp = this.getPrintParams(); // Wybieramy drukarkę (Nazwa drukarki widoczna w systemie) pp.printerName = "DYMO LabelWriter 450 Turbo"; // Ustawiamy automatyczny wybór rozmiaru papieru pp.flags |= pp.constants.flagValues.setPageSize; // Dodatkowe skalowanie aby dopasować dokument do papieru pp.pageHandling = pp.constants.handling.fit; // Drukujemy tylko treść bez żadnych dodatków pp.printContent = pp.constants.printContents.doc; // tryb "cichego" drukowania - pomijamy okno z preferencjami drukowania pp.interactive = pp.constants.interactionLevel.silent; // Wymuszenie drukowania this.print(pp);
Taki JS należy „zapisać” w dokumencie PDF. W TCPDF jak wspomniałem odpowiada za to metoda IncludeJS
Kanał ATOM
$pdf = $this->_prepareStickerPDF( $stickerData );
if ( $this->getRequest()->getParam('print', 'false') != 'false' ) {
// KOD Adobe PDF JS do wymuszenia drukowania i ustawienia podstawowych parametrów
$js = '
var pp = this.getPrintParams();
pp.printerName = "DYMO LabelWriter 450 Turbo";
pp.flags |= pp.constants.flagValues.setPageSize;
pp.pageHandling = pp.constants.handling.fit;
pp.printContent = pp.constants.printContents.doc;
';
if ( $this->getRequest()->getParam('print', 'false') == 'silent' ) {
$js .= 'pp.interactive = pp.constants.interactionLevel.silent;';
}
$js .= ' this.print(pp); ';
$pdf->IncludeJS($js);
}
$pdf->Output('Sticker.pdf', 'I');
Ok. Mamy spreparowany dokument PDF który automatycznie przy otworzeniu chce się drukować na ustawionej drukarce. Teraz trzeba coś zrobić aby pozbyć się popupów z PDF’em. Z pomocą przyjdzie nam możliwość osadzania obiektów PDF w HTML’u. Możemy to zrobić przez znaczniki HTML lub z poziomu JS (więcej info: http://blogs.adobe.com/pdfdevjunkie/web_designers_guide). Z poziomu JS wykorzystuję do tego PDFObject. W pliku HTML mam placeholder o zerowych rozmiarach i do niego wczytuję dokumenty PDF.
Ostatnio miałem przyjemność zapoznać się z niedocenianym wcześniej przeze mnie tematem używania kodów kreskowych w aplikacji. Czytnik bez żadnych problemów działał na Ubuntu 10.04, na którym go testowałem. Kody kreskowe służyły tu do szybszego wyszukiwania uczestników konferencji. Pod względem implementacyjnym dzięki Zend_Barcode wygenerowanie takiego kodu nie stanowi żadnego problemu.
Najprostszy przykład:
$barcodeOptions = array('text' => 'Hekima Blog');
Zend_Barcode::render('code128', 'image', $barcodeOptions);
Tworzy obrazek z kodem kreskowym, w którym zaszyty jest napis „Hekima Blog”. Do renderowania kodu użyłem obiektu klasy Zend_Barcode_Object_Code128, który obsługuje wszystkie znaki ASCII.
Wynik:
Bardziej przydatna wydaje się jednak możliwość dołączenia takiego obrazka do pdfa (np. z zaproszeniem dla danego uczestnika konferencji). Tu mamy dwie możliwości:
// tworzymy pdfa i jego pierwszą stronę
$pdf = new Zend_Pdf();
$pdf->pages[0] = new Zend_Pdf_Page('A4');
// i ustawiamy jako źródło obiektu renderującego kod do pdf
$renderer = new Zend_Barcode_Renderer_Pdf();
$renderer->setResource($pdf);
// ustawiamy tekst i font do generowania kodu
$barcodeOptions = array(
'text' => 'Hekima Blog',
'font' => APPLICATION_PATH . '/../data/fonts/Radley-Italic.ttf'
);
// renderujemy kod kreskowy
Zend_Barcode::render('code128', $renderer, $barcodeOptions);
W opcjach kodu kreskowego musimy podać font, który posłuży do wpisania kodu do pdfa. Czcionkę ściągnąłem z Google Web Fonts i umieściłem ją w katalogu data/fonts/.
Poniżej krótki przykład użycia:
/**
* Klasa służy do generowania kodów kreskowych
* @author Marek Pietrzak
*/
class BarcodeController extends Zend_Controller_Action {
/**
* Generowanie kodu kreskowego do obrazka
*/
public function indexAction() {
// wyłączenie generowania layoutu i widoku
$this->_helper->layout->disableLayout();
$this->_helper->viewRenderer->setNoRender();
// ustawiamy tekst
$barcodeOptions = array('text' => 'Hekima Blog');
// renderujemy kod do obrazka
Zend_Barcode::render('code128', 'image', $barcodeOptions);
}
/**
* Generowanie kodu kreskowego do pliku PDF
*/
public function pdfAction() {
// wyłączamy generowanie layoutu i widoku
$this->_helper->layout->disableLayout();
$this->_helper->viewRenderer->setNoRender();
// tworzymy pdfa i jego pierwszą stronę
$pdf = new Zend_Pdf();
$pdf->pages[0] = new Zend_Pdf_Page('A4');
// i ustawiamy jako źródło obiektu renderującego kod do pdf
$renderer = new Zend_Barcode_Renderer_Pdf();
$renderer->setResource($pdf);
// ustawiamy tekst i font do generowania kodu
$barcodeOptions = array(
'text' => 'Hekima Blog',
'font' => APPLICATION_PATH . '/../data/fonts/Radley-Italic.ttf'
);
// renderujemy kod kreskowy
Zend_Barcode::render('code128', $renderer, $barcodeOptions);
}
}
Jeśli kogoś bardziej interesuje to zagadnienie to polecam dokumentację