poniedziałek, grudnia 28

Java EE 6 'New' or 'Re-Implemented' Features

W najnowsze wersji JavaEE Sun oferuje kilka nowych (nowych oczywiście w Sun) funkcji 'dependency injection', bean validation (JSR 303) w EJB, Servlet 3.0 (JSR 315), JSF i JSP. Post będzie zawierał przegląd funkcji w najnowszych wersjach. Mój tekst sam jest spóźniony o jakieś 3 tygodnie (od premiery JavaEE 6), ale i tak jest to nic w porównaniu ze spóźnianiem chłopaków słońca, o czym będzie można się przekonać w dalszej części postu.


Java EE w wersji 6 wprowadza pojęcie profili(Technology Stack) konfiguracji platformy JavaEE. Profil zawiera pewne technologie platformy JavaEE, oraz technologie pomocne (takie które przeszły proces Java Community Process (JCP)) nie będące częścią platformy JavaEE. Najnowsze wydanie zawiera pierwszy profil WebProfil, jest to lżejsza wersja JavaEE 6 przeznaczona do produkcji aplikacji webowych, zawiera tylko niezbędne technologie.


Oczywiście na stronach Sun'a można przeczytać o wielu innych dodatkowych feater'ach jakie zawiera nowa wersja JavaEE, postaram się wymienić klika z nich, dodano:

adnotacje(np. @WebFilter, @ WebServlet, adnotacje do wstrzykiwania zależności),

asynchroniczne przetwarzanie (servlet nie musi oczekiwać na odpowiedź z zasobu zewnętrznego, kontynuuje prace mimo braku odpowiedzi z zasobu),

JSF 2.0( JSR 314) wprowadza uproszczenia dla autoryzacji poprzez Facelets, wprowadzono Templating, and Composite Components, do JSF zostało wbudowane wsparcie dla Ajax, oraz adnotacje, zawiera JSP 2.2;

wstrzykiwanie zależności, uproszczono używanie EJB, teraz można w prosty sposób zastąpić managed beans JSF'a, bean'em EJB;

walidację danych(Bean Validation specification (JSR 303)), pozwala to na zastosowanie tych samych walidacji przez wszystkie warstwy aplikacji;

po stroenie serwera dodano lub zaktualizowano: EJB 3.1(JSR 318)(między innymi: @Singleton, @ Asynchronous), Java API for RESTful Web Services (JAX-RS) (JSR 311), JPA2.0 (JSR 317) (nowa wersja JPQL, dodanie kryteria API)


Ale nie można tylko ganić za to spóźnienie Sun'a, dzięki ich 'opieszałości' zyskujemy bardzo stabilne, dopracowane api. Każda funkcjonalność jaką ponownie implementują była już gdzieś używana, dlatego też ich rozwiązania bardzo często są wolne od wad poprzedników. Spora rzesza z nas kocha tą stabilizacje i zawsze składania się ku ich rozwiązaniom.

ps. Inaczej było z wprowadzeniem JavaFx, pojawiała się fajna technologia, ale Sun zapomniał o komponentach by nam w pracy pozwolono tą technologia się bawić.

wtorek, października 20

java code convention

Witam

Podczas czytania książki SCJP for Java 6 zauważyłem, że dla Panów z Sun'a bardo ważnym jest by kod się kompilował, zapomnieli całkowicie o konwencji kodowania.

Pasjonaci kodowania często mówią, że kod ma wyglądać dobrze, ma się czytać dobrze, przy pierwszym spojrzeniu mówi do nas jakie są jego zadania. By kod tak wyglądał podczas kodowania stosujemy: metodyki, wzorce, standardy, ale często zapominamy o podstawach, czyli tytułowej konwencji kodowana. Konwencja dokumentuje podstawy związane z pisaniem kodu, takie jak: formatowanie kodu, organizacja plików, komentowanie, deklaracje, wyrażenia, .... Można by pomyśleć, że elementy tak podstawowe nie mogą wpłynąć na kod, ale jest całkiem inaczej, tak jak w życiu wszystko zaczyna się od podstaw.

Jako potwierdzenie mojej tezy, popełniłem małą klasę w PHP.

public class PHPInt {

  private int $value = Integer.MIN_VALUE;

  public static PHPInt __constructor(int $value) {
    return new PHPInt($value);
  }

  public void __add(int $value) {
    this.$value = this.$value + $value;
  }

  private PHPInt(int $value) {
    this.$value = $value;
  }

  @Override
  public String toString() {
    return String.valueOf(this.$value);
  }
}

Przekornie klasę bez zmian użyję w kodzie.

public class PHPCodeConvention {

  public static void main(String[] args) {

    PHPInt phpInt = PHPInt.__constructor(1);
    phpInt.__add(1);
    phpInt.__add(2);

    System.out.println("PHPInt value = " + phpInt);

  }
}

Trudno sobie wyobrazić, że można w ten sposób zakodować klasę w javie, horror. Mam nadzieję, że chociaż jedną osobę przekonałem by wpisał w google frazę 'java code convention'.


Pozdrawiam i zapraszam do komentowania.

czwartek, września 10

S.O.L.I.D

Witam,

serdecznie wszystkich po długiej przerwie, postaram się dzisiaj przedstawić bardzo skrótowo zagadnienie S.O.L.I.D, oraz zamieszczę klika linków do zagadnienia;


S.O.L.I.D. Class Design Principles

Zagadnienie zostało przedstawione przez Robert C. Martin w książce „Applying Principles and Patterns”


Single Responsibility Principle (SRP)
Klasa powinna mieć tylko jeden powód do zmiany stanu. Jeżeli klasa zmienia stan z przyczyn biznesowych, to zmiany schematu bazy danych, GUI, formatu raportu, oraz inne zmiany nie powinny wpłynąć na klasę.

http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx
http://c2.com/cgi/wiki?SingleResponsibilityPrinciple
Head First Design patterns page 185, 336, 339, 367
http://msdn.microsoft.com/en-us/magazine/cc546578.aspx
http://codebetter.com/blogs/david_laribee/archive/2008/09/09/why-solid-gimme-an-s.aspx


Open/Closed Principle (OCP)
Encje oprogramowania (klasy, moduły, funkcje, etc.) powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje.

http://davidhayden.com/blog/dave/archive/2005/06/04/1096.aspx
http://en.wikipedia.org/wiki/Open/closed_principle
Head First Design patterns page 86-87, 407
http://c2.com/cgi/wiki?OpenClosedPrinciple
http://codebetter.com/blogs/david_laribee/archive/2008/09/11/why-solid-gimme-an-quot-o-quot.aspx


Liskov substitution principle (LSP)
Podtyp powinien być substytutem typu bazowego. Jeżeli klasa A dziedziczy z klasy B, to tam gdzie możemy użyć klasy A, to też możemy użyć klasy B11

http://davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx
http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple
http://en.wikipedia.org/wiki/Liskov_substitution_principle
http://javaboutique.internet.com/tutorials/JavaOO/
http://codebetter.com/blogs/david_laribee/archive/2008/09/22/why-solid-gimme-an-l.aspx


Interface Segregation Principle (ISP)
Jedna klasa powinna zależeć od innej, poprzez jak najmniejszy interfejs jeżeli to możliwe.

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx
http://c2.com/cgi/wiki?InterfaceSegregationPrinciple
http://www.google.com/search?q=interface+segration+principle
http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html


Dependency Inversion Principle (DIP)
Klasa powinna być zależna od interfejsu, ale nie od konkretnej klasy.

http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx
http://en.wikipedia.org/wiki/Dependency_inversion_principle
Head First Design patterns page 139-143
http://c2.com/cgi/wiki?DependencyInversionPrinciple

poniedziałek, czerwca 8

posty znajomych

witam;


chciałbym wam polecić kilka artykułów jakie popełnili moi znajomi;


Sławek Sobótka - Risercz: DDD
dla zachęty umieszczę mały cytat:
"Aby jednak podtrzymać aktywność ucieknę się do prastarego triku i wkleję trochę linków, które ostatnio sobie przyswoiłem, i które to uważam za godne zauważenia.

Będzie to jednocześnie pierwszy z nowej serii postów - raporty/streszczenia z riserczu."


Irek Matysiewicz - Make your code samples prettier
coś o kolorowaniu kodu umieszczanego na blogu


Maciej Zubala - Ograniczony kontekst


Maciej Zubala - GRASP a anemiczny model
na sam koniec zostawiam cukierka tego postu; znakomity tekst wyprodukowany przez Maćka;



Pozdrawiam
Arkadiusz Borek

ps. czytanie powinno się zacząć od Maciej Zubala - GRASP a anemiczny model;

czwartek, czerwca 4

googlecode

Witam;


wydaje Mi się, że dla większości czytelników post będzie przedstawieniem informacji jakie już znają, ale mam nadzieję, że komuś się przyda.

Przychodzi taki dzień w życiu młodego programisty, że pragnie napisać coś dla siebie. Zaczynamy od założenia sobie projektu lokalnie, ale czy nie wspaniale było by gdybyśmy mogli nasz projekt umieścić gdzieś w sieci. Ja, chciałem mieć dostęp do mojego projektu z każdego miejsca na globie, oraz marzył mi się svn. Rozwiązanie które spełnia moje warunki znalazłem na googlecode, ale nie jest to jedyne miejsce gdzie możemy składować nasze projekty. Używanie naszego repo jest bardzo proste, zakładamy sobie konto na GoogleCode, oraz konfigurujemy swojego klienta SVN; mój klient to subclipse oczywiście dla eclipse.


ps. każdy projekt jaki pojawia się na googlecodemusi być na licencji open source.

poniedziałek, maja 18

gnije ale dlaczego

witam;

no to startujemy, pora opowiedzieć sobie co powoduje gnicie systemu;


Changing Requirements
Główna przyczyna degeneracji systemu jest bardzo dobrze znana. Wymagania które się zmieniają w taki sposób, że nie można ich w prosty sposób zaimplementować do pierwotnego projektu. Bardzo często zmiany muszą być bardzo szybko wykonane, często są wykonywane przez programistów nie będących przy tworzeniu pierwotnej wersji softu. Nie są oni wstanie wykonać poprawnie zmian ponieważ nie znają architektury. Zmiany do systemu nie są wprowadzane w czysty sposób dlatego też powodują akumulowania się kodu nie psującego do pierwotnej formy systemu.

Jednakże nie można obwiniać zmieniających się wymagać, o taki obrót sprawy. Każdy programista powinien być świadomy zmienności wymagań względem systemu.


Dependency Management
Jakie zmiany w projekcie powodują gnicie się systemu? Często zmiany wymuszają wprowadzanie nowych niezaplanowanych zależności pomiędzy klasami. Cztery symptomy wymienione w poście wcześniej wpływają bezpośrednio lub pośrednio, na to w jaki sposób są wprowadzane zależności pomiędzy klasami. Największym problemem w programowaniu obiektowym jest odpowiednie wprowadzanie zależności pomiędzy klasami, oraz odpowiednie zarządzanie tymi zależnościami. Programowanie obiektowe samo w sobie nie wspomaga tego mechanizmu, lecz istnieje kilka praktyk które pozwalają na dalszym etapie projektu wprowadzać zmian bez szkody dla niego.


… w kolejny postach przedstawię te mechanizmy, oraz na koniec pokażę zależność pomiędzy tymi praktykami.


ps. miłego czytania.

niedziela, maja 17

Symptoms of Rotting Design

solid czas rozpocząć;

Architecture and Dependencies
Aplikacja swoje życie rozpoczyna w umysłach programistów. Na początku posiada bardzo dobrą architekturę, prostotę, oraz zbudowana jest w oparciu o najlepsze wzorce programowania obiektowego.
Z systemem tak tworzonym zaczyna się coś dziać. Oprogramowanie zaczyna gnić. Początki nie są takie straszne, w jednym miejscu zastosuje się jakieś nie ładne rozwiązanie, w innym robi się jakiegoś sprytnego hacka, ale i tak nadal mówimy, że widać piękno pierwotnego projektu. Upływający czas powoduje, że ilość hacków w systemie wzrasta, a nasza prostota systemu zaczyna zanikać. System zaczyna posiadać coraz większy nieład w kodzie, a programiści uświadamiają sobie fakt, że zarządzanie kodem staje się coraz trudniejsze. Z każdą kolejną zmianą w kodzie trzeba zmieniać coraz więcej elementów systemu.


Symptoms of Rotting Design
Są cztery podstawowe symptomy po których można rozpoznać, że system zaczyna gnić. Nie są to zagadnienia przecinające się, ale powiązania między nimi są oczywiste. Podstawowe symptomy to rigidity (sztywność), fragility (kruchość), immobility (nie przenośność), viscosity (lepkość).

Ridigity (sztywność). System w którym jest bardzo trudno wprowadzać zmiany, nawet te łatwe. Każda zmiana pociąga za sobą dużą ilość zmian kaskadowych wynikających z zależności pomiędzy modułami. Zaczyna się to od tego, że zmiana które powinna zająć 2h, przeciąga się do 2 dni i powoduje zmiany w kilkunastu kalach w projekcie;
Kiedy system posiada takie symptomy programiści nie chętnie coś zmieniają i ograniczają się tylko do wprowadzania krytycznych zmian.

Fragility (kruchość). Blisko spokrewniona z sztywnością. Kruchość prowadzi do tego, że gdy dokonamy zmiany w jednym miejscu, system rozpada się w wielu miejscach. Często miejsca jakie ulegają uszkodzeniu nie mają bezpośredniego związku z miejscem zmiany. Sam problem nie pojawia się na etapie kompilacji, ale na etapie wykonania. Jeżeli problem ten zaczyna narastać to po pewnym czasie programistom towarzyszy strach. Wprowadzenie zmiany w jednym miejscu systemu może zepsuć każde inne bliżej nieokreślone miejsce. Jeżeli kruchość wzrasta może powodować wydłużanie się czasu wprowadzania zmian, ponieważ programiści zaczynają wykonywać nadmiarowe testy tylko, dlatego by uchronić się przed ewentualnymi problemami jakie zmiana mogła spowodować. Po pewnym czasie dbanie o system przestaje być opłacalne ponieważ nie wiadomo ile problemów może wprowadzić zmiana.

Immobility (nie przenośność)Immobility (nie przenośność). Pojawia się wtedy, gdy chce się wykorzystać projekt lub jego część w innym miejscu. Często zdarza się, że programista odkrywa to, że inni zrobili już coś podobnego i teraz można by wykorzystać gotowy kod. Ale gdy zaczyna się brać elementy które nas interesują okazuje się, że razem z nimi musimy wziąć bardzo dużo innych nie potrzebnych nam klas. Elementy dodatkowe nie są nam potrzebne, ale bez nich moduł nam potrzebny nie zadziała. Sytuacja ta powoduje, że dany fragment oprogramowania zamiast zostać użytym zostaje przepisany od nowa.

Viscosity (lepkość). Mówimy o lepkości projektu oraz systemu. Lepkość projektu pojawia się wtedy gdy zmianę można wykonać na więcej niż jedne sposób. Niektóre formy zmian są dłuższe, ale łamią pierwotnej architektury systemu, inne można nazwać potocznie hack. Jeżeli programiści wybierają dłuższe i leprze sposoby rozwiązywania problemu to nic strasznego się nie dzieje, ale może się tak zdarzyć, że presja klienta spowoduje zrobienie kacka. Oczywiście programista powtarza sobie, że zrobi hacks, puści release, a następnie rozwiązanie poprawi na porządne, tak się nigdy nie dzieje. Problemem w lepkości jest to, że zmiany łatwe które powinno się łatwo wprowadzać i nie powinny one łamać naszej pierwotnej architektury systemu, robią coś zupełnie przeciwnego.


Cztery symptomy o jakich napisałem są oznaką słabej architektury. Każda aplikacja posiadająca te oznaki zaczyna się psuć od środka. Ale co powoduje psucie się aplikacji, o tym napiszę w innym poście.

start.. SOLID

Witam;

mój pierwszy post o SOLID będzie przedstawieniem treści innych postów, po wykładzie Bruno Bossoli na GeeCON zostałem zarażony tą ideą, dlatego startuję z postami na temat kilku praktyk jakie należy stosować w programowaniu obiektowym(według tej metodologii); cały artykuł będzie się składał z kilku postów o treści: jakie są znaki, że nasze oprogramowanie zaczyna się psuć; następnie kilka powodów psucia się pierwotnego projektu aplikacji; opiszę 5 praktyk w osobnych postach; opisanie tych praktyk wyjaśni etymologię słowa SOLID;


ps. zaraz dodam kolejnego posta;

GeeCON 2009

Witam;

upłynęło trochę czasu od zakończenia konferencji; udało mi się odzyskać siły po nocnych wyprawach po Krakowie i postanowiłem podzielić się z Wami moim wrażeniami z GeeCON;
nie uda mi się opisać wszystkich wykładów, ponieważ na wykładzie były dwie ścieżki, a mi się jeszcze nie udało opanować technik replikacji:P, bym mógł obejrzeć całość; dwie ścieżki spowodowały to, że byłem w stanie zobaczyć tylko połowę wykładów;

no to startujemy;

Simon Ritter - JavaFX: The Platform for Rich Internet Applications
wykład zawierał kilka informacji na temat JavaFX jakie można znaleźć na stronie sun'a; pod względem merytorycznym wykład był zrobiony bardzo dobrze, ale jak dla mnie było zbyt dużo informacji statystycznych, wykład zakończył się małym show;

Alef Arendsen - Spring 3.0
fajnie było zobaczyć osoby które mają wpływ na wygląd Spring, ale pod względem merytorycznym nie było na wykładzie nic nowego czego nie można by było się dowiedzieć ze strony twórców;

Waldemar Kot - Liberate your enterprise Java applications from the Operating System
wykładowca jak zawsze merytorycznie przygotowany znakomicie, ale sama tematyka mnie nie interesowała spodziewałem się czegoś innego; tematyka mnie nie 'ruszyła' dlatego też nic na temat wykładu nie powiem;

Jacek Laskowski: Making EJB 3.1 development a breeze with Apache OpenEJB
na wykład udało się pełen sceptycyzmu, słyszałem wiele różnych opinii o Jacku Laskowskim, od bardzo pozytywnych po te bardzo negatywne; wykład zrobiony bardzo dobrze i po raz kolejny wybrałem tematykę która mnie do końca nie wciągnęła, informacje o OpenEJB były dobrze przedstawione, ale czy jest sens poznawania OpenEJB jeżeli mamy na rynku Sun EJB, Spring, Seam ???

Szczepan Faber: Great tests, less mocks, Mockito
Szczepan zaskoczył mnie profesjonalizmem, jak i ciekawą treścią wykładu, wykład przyjemnie się słuchało, oraz zawierał bardzo wiele informacji;

Hans Docter: Gradle
Hans Docker opowiadał, o nowym maven i ant; reasumując Gradle można być bardzo dobrym rozwiązaniem jeżeli proces budowania aplikacji jest skomplikowany;


dzień drugi;

Adam Bien: Java FX For Developers Not Designers
no i zaczęło się; wykład był taki jak lubię same konkrety, pełno kodu, mnóstwo slajdów i wykładowca posiadający ogromną;

Giorgio Natili: Blaze DS connectivity framework
nie było zbyt dobrze, przemilczę formę w jakiej był prowadzony wykład;

Paweł Wrzeszcz: Seam For Spring Developers
zacznę od wielkich braw dla prowadzącego, udało mu się przeprowadzić wykład bez rzutnika; wykład miał za zadanie przekonać programistów bawiących się w Spring'iem by spróbowali pobawić się Seam'e; sam Seam to bardzo fajna rzecz, należy go polecić każdemu kto miał 'szczęście' budować aplikację webową;

Bruno Bossola: SOLID design principles
na temat wykładu nie będę się rozpisywał, ponieważ pojawi się u mnie na blogu kilka postów związanych tematycznie z tym wykładem; jak dla mnie jeden z najlepszych wykładów jakie do tej pory było dane mi usłyszeć;

Lubomir Petrik: Sun Grid Engine
jak dla mnie pomyłka, że wykład o tej tematyce znalazł się na javowej konferencji;


no nic zakończył się sam GeeCON, pozostały tylko wspomnienia, dzisiaj bez zawahania polecił bym wam GeeCON 2010;



ps. czekajcie na posty o S.O.L.I.D;

wtorek, maja 12

java; joke;

witam;

przesyłam coś dla humoru http://www.ovisual.com/4/;

po przeczytaniu proszę o wybranie swojego ulubionego;


mój faworyt to: If you get a ChuckNorrisException you’ll probably die.

poniedziałek, marca 23

Generic Types - Type Parameter Naming Conventions

witam;

pewnego dnia widziałem kod gdzie generyk był zdefiniowany nazwą <Unit>; spowodowało to moje lekki zdziwienie;

słyszałem, że na oznaczenie tych parametrów posiada pewną konwencję, i co udało mi się znaleść na stornie sun'a;


Najczęściej używane nazwy dla parametrów:

  • E - Element (used extensively by the Java Collections Framework)

  • K - Key

  • N - Number

  • T - Type

  • V - Value

  • S,U,V etc. - 2nd, 3rd, 4th types

poniedziałek, lutego 9

The future of programming languages

witam;

dzisiaj proponuję coś innego link do filmu http://blog.jaoo.dk/2008/10/07/the-future-of-programming-languages; w filmie Anders Hejlsberg przedstawia przyszłość języków programowania; Cały wykład niesie sporo wiedzy, ale jak to bywa na wykładach Microsoft są politycznie ukierunkowane :P;

mimo tego polecam wykład jest godny uwagi;

niedziela, lutego 1

JavaFX - new Java begin ?

Witam;


od pewnego czasu nosiłem się z zamiarem zobaczenia na co stać JavaFX; słyszałem o nim tylko z opowieści, a wszystkie opinie jakie znałem były dość sceptyczny, można by wręcz powiedzieć, że negatywne; koleżeńska agitacja spowodowała, że do nowego dziecka Sun'a byłem nastawiony na nie;


zacząłem od tutoriala o JavaFX pobranego z witryny Sun'a; na sam początek dowiaduję się, że w nowym języku pojawiły się takie typy jak: String, Number, Boolean, Duration, Void i Null; sam język posiada typy dynamiczne, pomyślałem sobie Python;


następne przyszły sequence, nowa rzecz; czytałem ten rozdział z przerażeniem myśląc sobie pełen język skryptowy, a gdzie mój język co się z nim stało(mój język = Java); pojawiły się w tym rozdziale takie słowa kluczowe jak: insert "something" before|after element[2], delete i reverse, które to pozwalają na dodawanie, usuwanie, odwrócenie kolekcji; dodatkowy smaczek niesie ze sobą zdanie jakie znalazłem podczas czytania: „Note: In truth, sequences are immutable, meaning that once created they never change. When you modify a sequence by inserting or deleting items, for example, behind the scenes a new sequence is created and the sequence variable is reassigned, giving the impression that the sequence was modified.”, wydaję mi się, że ta implementacja nie jest najbardziej trafiona i takie każdorazowe przepisywanie będzie mogło w niedalekiej przyszłości zabić wydajnościowo aplikacje;


kolejny rozdział którym się rozczarowałem to Expression i tutaj dalej język skryptowy, oraz zapis 'bardzo fajnej' sekwencji:

var seq = for(i in [1..10]) i*i;


ostatnim zagadnieniem jakie opisze jest Data Bindings and Triggers - totalne zaskoczenie, oczywiście na wielki plus; Dla mnie osobiście możliwości jakie poznałem w tym rozdziale są tym czego mi brakowało w języku programowania; wykorzystując programowanie aspektowe można było to osiągnąć ale teraz mamy te możliwości w języku programowania;


bindowanie zmiennych:

var x = 0;
var y = bind x;
x= 1;
println(y); //1


kolejny przykład zaprezentuje jeszcze większe możliwości mechanizmu bindowania;

var localVar = 1;
bound functionOne(paramA : Integer) : Integer{
  paramA*localVar;
}
var myA = 2;
var a = bind functionOne(myA);
myA = 4;
println(a);
localVar = 2;
println(a);

wynik jaki otrzymamy na konsoli będzie postaci:

4
8


ale jeżeli pozbędziemy się słowa kluczowego bound z definicji funkcji, wynik jaki otrzymamy będzie postaci:

4
4


jak to się dzieje, słowo kluczowe bind powoduje zbindowania tylko zmiennych jakie zostały użyte do wywołania funkcji, a słow kluczowe bound powoduje zbindowanie wszystkich zmiennych użytych w funkcji; dlatego też po zmianie jakiejkolwiek zmiennej użytej w ciebie funkcji spowoduje ponownie wywołanie funkcji;

Triggers, do tej pory znane były mi z baz danych, a tu nagle:

var password = "foo" on replace oldValue {
  println("old:{oldValue}");
  println("new:{password}");
}
password = "bar";


a na naszej konsoli:
old:
new:foo
old:foo
new:bar


myślę, że po samym wyniku z konsoli można już stwierdzić jak działają triggery w JavaFX;



po zapoznaniu się z ostatnim rozdziałem uświadomiłem sobie fakt, że JavaFX ma przed sobą bardzo świetlana przyszłość, chodź jeszcze dość odległą; po stronie Sun'a pozostaje jeszcze opracowanie mechanizmu integracji z innymi technologiami, oraz bogatej biblioteki elementów GUI, jeżeli by JavaFX miała konkurować z takimi technologiami jak: Adobe Flash i Flex, AJAX, Microsoft Silverlight.



.. wkrótce kilka słów o GUI w JavaFX.

czwartek, stycznia 29

JSR294 – modułowość w Javie 7

Problem modułowości i reużywalności aplikacji pisanych w Javie znany jest nie od dziś. Chyba najważniejszą właściwością następnego wydania Javy (7.0) ma być modułowość sporego i czasami zbyt ciężkiego pakietu programistycznego JDK. Podkreślił to ostatnio także Mark Reinhold, główny architekt platformy Java Standard Edition, który jest odpowiedzialny za prace nad następną wersją. W swoim blogu zapowiedział inaugurację projektu Jigsaw, inicjatywy w ramach społeczności OpenJDK, której celem jest modułowość JDK 7 oraz praca nad specyfikacją JSR 294 "Improved Modularity Support in the Java Programming Language".

JSR 294 określa wprowadzenie tzw. superpakietów, a także rozszerzenie języka Java oraz wirtualnej maszyny Javy (JVM), w celu zagwarantowania możliwości tworzenia modularnego oprogramowania w Javie. Reinhold zamierza uwzględnić JSR 294 w Javie 7.
Kolejnymi specyfikacjami odnoszącymi się do tej tematyki są JSR 277 i JSR 291.
JSR 277 "Java Module System" wprowadza format dystrybucyjny oraz repozytorium dla pakietów Javy oraz przynależnych zasobów. Oprócz tego specyfikacja opisuje mechanizmy ładowania i integracji klas w czasie działania programu. Specyfikacja ta jest jednak krytykowana za zbyt małą elastyczność. JSR 277 nie będzie uwzględniona w Javie 7. Jak ktoś nie lubi czytać to więcej można się dowiedzieć z serwisu parleys.com, jest tam prezencja JSR-277 Java Module System


Z kolei specyfikacja JSR 291 "Dynamic Component Support for Java" została opublikowana w lutym 2006 roku przez firmę IBM. Określa ona standaryzację centralnych modułów frameworka OSGi w ramach JCP i osadzenie ich w platformie Java Standard Edition. Jako przykład służy tutaj obowiązująca w przypadku platformy JavaME specyfikacja JSR 232 "Mobile Operational Management". Celem JSR 291 jest zdefiniowanie dynamicznego frameworka, który obsługiwałby istniejące środowiska Java SE bazujące na dynamicznym modelu komponentów OSGi. Sun od samego początku podawał w wątpliwość konieczność wprowadzania tej specyfikacji, ponieważ koncepcja osadzenia podobna do JSR 291 została już opisana w specyfikacji wydanej przez konsorcjum OSGi. Mimo że pomysł OSGi został pierwotnie opracowany na platformie Javy, istnieją komponenty OSGi niezintegrowane z tym językiem. Ponieważ Reinhold nie wspomina o tej specyfikacji JSR 291, nie należy przypuszczać, aby została ona uwzględniona w Javie 7.


Jeżeli interesuje was problem modularności oprogramowania polecam linki (najlepiej oglądać w kolejności :P):

piątek, stycznia 2

Refaktoryzacja to...

witam;

Postawiłem sobie osobiście cel pisania o JavaFX, nawet rozpocząłem jakieś przymiarki, ostatecznie miałem napisać kilka słów o JSF + Seam, ale pewnego dnia udało mi się przeczytać książkę o czymś innym ...

Refaktoryzacja to zmiany wewnętrznej struktury kodu programu, które mają za zadanie zwiększyć czytelność oraz obniżyć koszt wprowadzania zmian. Mówi się że, poprawnie przeprowadzona refaktoryzacja nie zmienia sposobu działania aplikacji od strony użytkownika.

Ta prosta definicja pozwala zapoznać się terminem refaktoryzacji, ale formalna definicja podana przez D.Roberts'a w 1998 ma postać:

R = (pre; T; P)

gdzie:
- pre - asercja która musi być spełniona by przekształcenie R było prawdziwe;
- T - transformacja kodu programu;
- P - funkcja przekształcająca warunki początkowe na warunki końcowe, określa warunki końcowe, które są prawdziwe po przeprowadzeniu transformacji T;

Refaktoryzacja ma za zadanie wprowadzić zmiany w nasz kod, ale zmiana struktury programu może stanowić dla niego ogromne zagrożenie, jeżeli by po jej zakończeniu program miał działać inaczej. Dlatego najważniejszym warunkiem poprawnie przeprowadzonej refaktoryzacji, jest zapewnienie, że nie wprowadzi ona żadnych zmian do działa aplikacji;


Ale jak można zweryfikować poprawności wprowadzanych zmian, istnieją dwie metody weryfikacji poprawności przekształceń:
  • analityczna - wykorzystanie statycznych informacji; metoda nie wymaga uruchomienia programu
  • dynamiczna - weryfikacja przeprowadzana przy pomocy testów; wymaga uruchomienia aplikacji
Podział metod weryfikacji poprowadził do powstania podziały przekształceń na:
  • proste - najczęściej zautomatyzowana weryfikacja przy pomocy IDE
  • trudne - weryfikacja wymaga testowania przy pomocy własnoręcznie napisanych testów
Oczywiście w prawdziwym świecie nie jest łatwo i dlatego liczba przekształceń trudnych jest o wiele większa niż występowanie przekształceń prostych;


Dalsza część posta będzie parta o publikację Martin Fowler Refactoring: Improving the Design of Existing Code w swojej książce przedstawił podział przekształceń ze względu na sposoby weryfikacji:
  • proste (ok. 22) - można zweryfikować analitycznie
  • trudne (ok.50)
    • testowalne (ok. 25) - wymagają z góry znanych testów
    • nieokreślone (ok. 25) - wymagają dedykowanych testów


Fowler zdefiniował pojęcie bad smell czyli jeżeli coś źle pachnie należy to zmienić. Pojęcie jest luźną definicją dlatego też obejmuje najróżniejesze problemy związane ze strukturą kodu. Dlatego też lista bad smells obejmuje wiele niespokrewnionych ze sobą problemów.

Problemów takich jak:
  • Dublicate Code (Z duplikowany kod)
  • Long Method (Długa metoda)
  • Large Class (Nadmiernie rozbudowana klasa)
  • Long Parameter List (Długa lista parametrów)
  • Comments (Nadmierne komentarze)
  • Incomplet Library Class (Niekompletna klasa biblioteki)
  • Switch Statements (Skomplikowane instrukcje warunkowe)
  • Message Chains (Łańcuch wywołań przez delegację)
  • Data Class (Klasa z danymi)
  • Data Clumps (Zbitka danych)
  • Refused Bequest (Odrzucony spadek)
  • Inappropriate Intimacy (Niewłaściwa hermetyzacja)
  • Lazy Class (Bezużyteczna klasa)
  • Feature Envy (Zazdrość o funkcje)
  • Paraller Inheritance Hierarchies (Równoległe hierarchiczne dziedziczenie)
  • Middle Man (Pośrednik)
  • Divergent Change (Zmiany z wielu przyczyn)
  • Shotgun Surgery (Odpryskowa modyfikacja)
  • Speculative Generality (Spekulacyjne uogulnienie)
  • ... obiecuje, że za jakiś czas pojawi się opis wszystkich bad smells


Po tak 'pięknej' liście należy się zastanowić jak znajdować bad smell. Z tym problemem nie pozostajemy sami istnieje kilka źródeł, które mogą dostarczyć danych o ich obecności:
  • intuicja programisty, która jest niemierzalna i trudna do zdefiniowania, a jednak pełni bardzo ważną rolę w identyfikacji złych praktyk obiektowych

  • metryki, które są podstawowym mechanizmem ilościowej oceny jekości projektu. Metryki dostarczają liczbowej i łatwej do zinterpretowania informacji o wielu aspektach jakości projektu

  • analiza Abstrakcyjnego Drzewa Składowego AST, które jest graficzną reprezentacją rozbioru gramatycznego programu. Obecność lub brak określonych elementów w drzewie AST wskazuje na obecność lub wyklucza obecność niektórych zapachów

  • informacja o innych zapachach pozwala wykorzystać znane już fakty o innych przykrych zapachach

  • analiza dynamiczna, która pozwala określić atrybuty programu nie dające zidentyfikować wyłącznie poprzez analizę statyczną. Przykładem analizy dynamicznej może być wykonanie przypadków testowych

  • historia zmian kodu pochodząca z repozytorium zarzadzania konfiguracją pozwala ocenić wpływ niektórych zmian na program


Słowem podsumowania...
może post jest przydługi, ale mam nadzieję, że zawarte informacje w nim komuś się przydadzą. Mi pozwolił nazwać rzeczy które od dawna robiłem.