Blog

Blog

Az Ukrán Java User Group kérésére továbbítom, nyugati konferenciákhoz képest elenyésző áron, sok előadással, impresszív előadói listával: 

 

Now the JUG UA team is working hard on the 5th JavaDay Kyiv, which will be held in Kyiv on 6th-7th of November http://javaday.org.ua/kyiv/

Thanks to Jelastic, the Father of Java James Gosling will speak online at conference. The JUG UA has started to collect questions for James on Facebook. So don't hesitate and post or like questions https://www.facebook.com/events/1102807739739007/
This year's conference will have deep focus on Java-core platform (Java 8 & Java 9), microservices and Java Enterprise technologies. Preliminary conference program is available here https://goo.gl/UJhoQF

Also, after the conference at October 8th, Venkat Subramaniam will give training "Essence of Agility - The Key Technical Practices" https://venkatsubramaniam2015.ticketforevent.com/

Anniversary JavaDay Kyiv facts:
— 2 days of deep Java talks
— 5 parallel tracks
— 40+ world-known speakers
— 60+ remarkable talks
— modern venue for 800+ participants

Our speakers:
— The Father of Java (online)
— Java Champions and JavaOne Rock Stars
— JavaOne and Devoxx speakers
— Java books’ authors

Conference topics:
— Core JVM platform and Java SE (Java 8, Java 9)
— JVM languages and new programming paradigms
— Web development and Java Enterprise technologies
— Software engineering practices
— Architecture & Cloud
— BigData & NoSQL

Among our speakers are James Gosling (online), Venkat Subramaniam, Arun Gupta, Bruno Souza, Robert Field, Marcus Lagergren, Maurice Naftalin, Patrycja Wegrzynowicz, Baruch Sadogursky, Kai Waehner, Mohamed Taman, Oleg Šelajev and many others.

Looking forward to seeing you at JavaDay Kyiv!

UPDATE: október 7, szerda!

Az idén is rendezünk Developer Dayt, október 15  7-én, Budapesten, a Telekom székházban (és nem utolsó szempont: ingyenesen). Részletek itt vannak: http://www.houg.hu/pls/apex/f?p=houg:houg_szakmai_nap_2015 , illetve lesznek, mert egyelőre még nem publikáltuk az előadások listáját. 

Én szervezem a Java szekciót, amely az idén egész napos, 10 előadásra van lehetőség, 25-25 percben. Először örülni fogunk, hogy a Java 20 éves, és Java előadásokat hallgatunk, aztán, mivel a Java 20 éves, legyen valami fiatalabb is, a délutáni részben modern, valamennyire kapcsolódó témák jönnek (jelen elképzelésem szerint: Scala, JavaScript, NoSQL, ...). 

Még vannak helyek, gyertek előadónak. Lehet egy érdekes technológiáról is szó, de lehet, sőt, örülnék, ha konkrét projekthez kapcsolódó (szakmai) élményről tudnátok előadni. 

Simon Géza

(geza.simon kukac houg.hu) 

Jöhet a JAVA? Programozz és nyerj! – Itt a BankTech Java Challenge

Jelentkezés október 28-ig a weboldalon: www.javachallenge.hu

A versenyt két sikeres hazai cég, a Loxon Zrt. és a Dorsum Zrt. támogatja. A több országban (például Románia, Bulgária, Oroszország) is jelenlévő vállalatok innovatív, egyedi igényekre fejlesztett szoftvereket gyártanak a pénzügyi és tőkepiaci szektor számára. A JAVA programozási verseny megrendezésével szeretnék felfedezni a fiatal tehetségeket: nem titkolt cél az új munkavállalók toborzása sem, amellett, hogy az izgalmas problémamegoldási, kvíz és programozási feladatokkal igyekeznek izgalmas kihívást állítani a hallgatóknak, frissdiplomásoknak.

A két online és egy élő döntő fordulós versenyre 3 fős csapatok jelentkezhetnek, akik közül a legjobbak erőfeszítéseit az alábbi díjakkal honorálják:

Fődíj:  4 nap Amszterdamban – sör, buli, bicikli

2. helyezés: csapattagonként egy-egy iPad Air

3. helyezés: Sziget vagy Balaton Sound heti bérlet

BankTech Java Challenge


Ha innen nézem: a Java még mindig az egyik leghasználtabb programozási nyelv, főleg bizonyos piaci szegmensekben.

Ha a másik oldalról nézem: annak ellenére, hogy Magyarországon valószínű jelentős Java programozó populáció lakik, a szakmai események száma továbbra is sajnálatos módon kicsi.

Ezért is szerencsés, hogy újra lesz HOUG szakmai nap október 2-án, benne hangsúlyos Java képviselettel. A program (és az előzetes regisztráció) elérhető a HOUG oldalról.

Ami már biztos hogy lesz, az JavaEE/SE/Spring, de lehet még előadásra is jelentkezni 25 perc és villámelőadás (kb. 6 perc) terjedelemben. (Szerintem nincs annál menőbb előadó, mint aki 6 percben tud emlékezeteset alkotni.) Előadással jelentkezni lehet pl. a geza pont simon kukac houg pont hu email címen.

Az Oracle pár hete és hónapja közzétett két részletben egy kérdőívet, hogy a JavaEE fejlesztői közösség milyen fejlődési irányokat tart hasznosnak. Nos, megérkeztek az eredmények (amelyben alighanem nincsenek benne a harmadik – lezáró – kérdőív válaszai):

 

Jól látszik, hogy az első félkörbe a JSON binding, a biztonsági réteg egyszerűsítése, egy szabványos gyorsítótár réteg és az MVC jobb támogatása került. A többi apróság is fontos, de a közösségnek jelenleg leginkább a JSONB hiányzik.

JINQ

Érdekes kezdeményezés a JINQ, amely kombinálja a Lambda expression technológiát az adatbázis lekérdezésekkel.

Nézzük például az alábbi JDBC lekérdezést:

PreparedStatement s = con.prepareStatement("SELECT * "
+ "FROM Customer C "
+ "WHERE C.Name = ? ");
s.setString(1, "Alice");
ResultSet rs = s.executeQuery();

 

E Helyett JINQ használatával az alábbi "lekérdezést" kell megejtenünk:

database.getCustomers().where(
customer -> customer.getName().equals("Alice"));

 

A leírás szerint teljes stream támogatása is van, tehát működnek a filter, a map és a reduce megoldások is:

customers.stream()
   .filter( c -> c.getName().equals("Alice") )
   .map( c -> c.getAddress() );

 

Egy próbát megér... JPA-val kombinálva nagyon jó eszköznek néz ki. (smile)

Megjött a Java 8!

Sok-sok-sok-sok-nagyon sok csúszás után végre itt a Java 8! Igaz, sok hasznos újítás kimaradt ebből a kiadásból (is), mint például a Jigsaw és a G1 GC, de ezért ne legyünk szomorúak, nézzük a listát a nagyobb és jelentősebb újdonságokról:

  • Lambda Expressions – closure támogatás
  • Virtual Extension Methods – alapértelmezett metódusok interfészekben
  • Date & Time API – új dátum és idő API
  • Nashorn JavaScript Engine – JavaScript futtató, a javax.script alatt van az elérhető API
  • Remove the Permanent Generation – végre eltűnt a PermGen terület! (smile)
  • Concurrency Updates – párhuzamos végrehajtáshoz segédletek
  • Remove the Annotation-Processing Tool (apt) – ez fájdalmas lehet, ha építettünk rá (sad)
  • Repeating Annotations – ismételhető annotációk (a lista típusú annotációk helyett vagy mellett)
  • Parallel Array Sorting – párhuzamosított tömb rendezés! (smile)
  • Bulk Data Operations for Collections – a "stream" néven nevezett szűrések bevezetése
  • Base64 Encoding & Decoding – JRE része lett a Base64 enkódolás és dekódoloás
  • Autoconf-Based Build System – OpenJDK fordítási eszköztár
  • Lambda-Form Representation for Method Handles
  • Compact Profiles – A későbbre halasztott modularizáció függősége, ha nem kell a teljes JRE vagy JDK, akkor nem töltődik le vagy nem indul el az egész
  • Prepare for Modularization – Szintén a Jigsaw függősége, leginkább API racionalizálás
  • Leverage CPU Instructions for AES Cryptography – az AES titkosítás épít a hardver lehetőségeire
  • Mechanical Checking of Caller-Sensitive Methods – biztonsági javítás, mellékhatása az lehet, hogy már nem lehet hozzáférni belső osztályokhoz
  • Document JDK API Support and Stability – a com.sun.* osztályok kikerültek az API dokumentációból és valóban nem lehet elérni ezeket
  • Reduce Cache Contention on Specified Fields – VM hatékonyság javító módosítás, leginkább több processzoros környezetre
  • Retire Some Rarely-Used GC Combinations – néhány ritka GC vezérlő beállítás nyugdíjba vonult
  • Enhanced Verification Errors – bájtkód ellenőrzés
  • Reduce Class Metadata Footprint – memória-felhasználás csökkentése
  • Small VM – hordozható és hordható eszközök támogatása
  • Fence Intrinsics – VM kompatibilitási javítás
  • Launch JavaFX Applications – JavaFX javítások
  • Generalized Target-Type Inference – generics javítások
  • Annotations on Java Types – annotációk immár a típusokon is
  • DocTree API – javadoc megjegyzések feldolgozása
  • Add Javadoc to javax.tools – API optimalizálás
  • Access to Parameter Names at Runtime – reflection javítás
  • Enhance javac to Improve Build Speed – fordítási sebesség javítása
  • DocLint – a javadoc stílus ellenőzése
  • Enhance Core Libraries with Lambda – Lambda alapú API az alapvető funkciókra
  • Charset Implementation Improvements – karakterkészletekkel kapcsolatos javítások
  • javax.lang.model Implementation Backed by Core Reflection – reflection javítások
  • Reduce Core-Library Memory Usage – memóriahasználat csökkentés
  • JDBC 4.2 – apró javítások
  • Optimize java.text.DecimalFormat.format – sebesség és használhatósági javítások
  • Statically-Linked JNI Libraries – statikusan linkelt JNI
  • Handle Frequent HashMap Collisions with Balanced Trees – a hash ütközés csökkentés nagyobb HashMap esetén hasznos
  • Improve Locale Data Packaging and Adopt Unicode CLDR Data – runtime javítás
  • BCP 47 Locale Matching – RFC 4647 támogatás
  • Unicode 6.2 – támogatás
  • HTTP URL Permissions – URL szűrés IP szűrés helyett
  • MS-SFU Kerberos 5 Extensions – Kerberos 5 kiterjesztések támogatása
  • TLS Server Name Indication (SNI) Extension – SNI támogatás
  • AEAD CipherSuites – AEAD/GCM támogatás
  • Stronger Algorithms for Password-Based Encryption – PBE támogatás
  • Configurable Secure Random-Number Generation – konfigurálható véletlen szám generátor
  • Enhance the Certificate Revocation-Checking API – tanúsítvány ellenőrzés javítások
  • NSA Suite B Cryptographic Algorithms – támogatás
  • SHA-224 Message Digests – támogatás
  • PKCS#11 Crypto Provider for 64-bit Windows – támogatás
  • Limited doPrivileged – biztonsági javítás
  • Overhaul JKS-JCEKS-PKCS12 Keystores – biztonsági javítás
  • JAXP 1.5: Restrict Fetching of External Resources – biztonsági javítás

 

Az új JDK március negyedikei előzetese már egy ideje letölthető a https://jdk8.java.net/download.html címről, de a mai nap érkezik az első végleges kiadás, amely a http://ww.oracle.com/Java8 címről tölthető le. Aki eddig nem tette volna, gyorsan nézze meg, hogy a saját fejlesztései működnek-e rendesen a Java 8 JRE/JDK esetén is, mivel nemsokára az Oracle elkezdi teríteni a felhasználók felé is! (smile)

A HOUG – a jövő idő megérkezett címmel – három napos konferenciát szervez, amelyen az első (fél) nap ingyenes, és a Java szekcióban az alábbi előadások közül válogathatunk:

  • JavaEE Application Security - Minden, amit az alkalmazásbiztonságról a fejlesztőknek érdemes tudni. – Schaffer Krisztián, security analyst, Cloudbreaker Company
  • JavaSE 8 újdonságok – Elek Márton, DPC Consulting Kft
  • JavaEE 7 újdonságok – Varga Péter, tanácsadó, DPC Consulting Kft.
  • Az Apache Maven élete és halála – Cservenák Tamás, Sonatype // Nexus fejlesztő
  • Continuous Delivery: Problémák és megoldások – Viczián István, vezető fejlesztő, IP Systems
  • Android és JavaEE: légy REST! – Auth Gábor, senior architect

A teljes és részletes program – és jelentkezési felület – az alábbi linken található:

http://konferenciak.advalorem.hu/houg-2014/program

Szinte a Play (illetve akkoriban Android Market) indulása óta siránkoztak a felhasználók és a fejlesztők, hogy magyarországi piacra szánt Android telefonokkal nem lehetett fizetős alkalmazásokat venni, illetve publikálni. Ebből a két korlátozásból a felhasználói oldalit nagyjából három éve rendezte a Google, így lehetővé vált azon alkalmazások elérése, amelyekért pénzt kért a fejlesztő, de hazai fejlesztő – a (sokszor agresszív) reklámokon kívül – nem tudott pénzt keresni az alkalmazásával. 2011 májusától kezdve szinte havonta röppentek fel "biztos forrásból származó" pletykák, hogy nemsokára már a magyarországi fejlesztők is konkrét eladásokból származó pénzhez juthatnak, de ezek rendre hamisnak bizonyultak, egyszerűen csak fejlesztői whisful thinking manifesztálódott. Mi sem bizonyítja jobban a Google remek titoktartását, hogy minden előzmény nélkül pár perce egy olyan levél érkezett a postaládámba, amelyet már évek óta vártam:

We're writing to let you know that beginning March 12 2014 we will be introducing Google Wallet Merchant registration availability for Google Play Developers in Hungary.

És valóban, Magyarország már azon országok között van, amelyekben lehetőség van arra, hogy a fejlesztő fizetős alkalmazást töltsön fel: https://support.google.com/googleplay/android-developer/table/3539140?hl=en

Nagy különbségek nincsenek az ország specifikus Merchant fiókok között, a lényeg az, hogy ez a lehetőség nincs az Android piactérre korlátozva, be tudjuk kötni a Google Wallet megoldást bármilyen webáruház mögé is, így tulajdonképpen bank és pénzügyi csatorna független kereskedők lehetünk és nem kell a – sokszor – nehézkes banki integrációval szenvednünk. A Play kapcsán fontos korlátozás lehet, hogy a minimálisan elkérhető pénz a dollár árfolyamához van kötve, ami tegnap éppen 225 forint volt, ugyanez angliai piacon 0,5 font, ami csak 186 forint, illetve az gazdasági EU területén 0,5 euró, ami 156 forint! A Google – ha kérjük, a forintban megadott összeget átszámolja a többi ország megfelelő pénznemére, de akár kézzel is beállíthatjuk az alkalmazásért vagy az alkalmazáson belüli értékesítésért kért pénzösszeget, mert például más a fizetőképes kereslet Magyarországon és Kanadában...

 Kicsit türelmesebbnek kellett volna lennem, és nem nyitni egy angliai Developer Account-ot, megspóroltam volna 25 dollárt... (smile)

WildFly 8 - JavaEE 7

A Red Hat bejelentette a WildFly 8 első stabil kiadását, amely implementálja a JavaEE 7 specifikáció Web és Full profilját is, így a Glassfish után ez az alkalmazás szerver teljesítette az teszteket. A WildFly a JBoss Community Edition utója, a Red Hat tavaly választotta a WildFly nevet, hogy a JBoss Enterprise Application Platform (EAP) és a Community Edition (CE) változatokat jobban megkülönböztesse... illetve jobban elválassza a kódbázist tekintve... Külön érdekesség, hogy az Oracle azon bejelentése után, hogy a Glassfish hivatalos támogatását megszüntette, Arun Gupta átigazolt a Red Hat csapatához.

De nézzük inkább az újításokat és javításokat:

  • Undertow.io került a korábbi Tomcat származék Web szerver helyére
  • Az alkalmazás szerveren kettő nyitott port maradt: a 8080 és a 9090
  • A menedzsment konzol támogat több szerepkört, így egy szerveren lehet több adminisztrátor felhasználó
  • JDK8 kompatibilitás
  • Régi technológiák kivezetése (CMP helyett JPA, JAX-RPC helyett JAX-WS, JSR-88 helyett CLI)
  • ...és még sok más apróság

 

Érdemes kipróbálni... én már a Beta1 óta próbálgatom, ígéretes... (smile)

http://java.sys-con.com/node/2958235 oldalon a Parasoft szponzorációjával elkészült egy infógrafika, amely a Continuous Testing folyamatát, jellemzőit és előnyeit mutatja be, a végén egy diszkrét reklámmal... (smile)

Érdemes végigböngészni, hasznos dolgok vannak alább:

A tavaly és tavaly előtt kiderült biztonsági hibák kapcsán nem lehet elégszer mondani: a Java futtatókörnyezet legyen friss vagy legyen kikapcsolva a böngészőben, mivel egyre több rosszindulatú program használja ki a Java környezetben meglévő biztonsági hibákat. Legutóbb a Java7 update 21 alatti verziókat támadó programra (malware-re) találtak rá a Kaspersky munkatársai, amely DDoS támadásokra felhasználható multiplatformos botnetet telepít a megfertőzött gépre.

Ideje lecserélni a Java7 update 51 alatti Java verziókat a munkaállomásokon, mivel a víruskeresők mindig egy kicsit le vannak maradva a hibát kihasználó programok mögött és már nem nyújt védelmet az se, hogy kevéssé elterjedt operációs rendszert használunk.

Szóval: frissíteni, frissíteni, frissíteni! (smile)

Competence Debt

Technical Debt fogalom már rég befészkelte magát a (vezető) fejlesztők és az architektek fejébe, ugyanis ez a "technikai adósság" egy darab szám, ami többé-kevésbé jól jellemzi a forráskód állapotát.

A forráskód ugyanis olyan, hogy a fejlesztés során folyamatosan változik. Ha rendszeresen jönnek üzleti igények, amelyeket az üzlet minél hamarabb éles üzembe szeretne látni, hogy pénzt tudjon keresni, akkor a gyors megoldások mentén beszivárognak rossz megoldások is. Ezeket a tákolásokat előbb-utóbb kell oldani, mivel hibákat rejtenek magukban a le nem kezelt használati esetekre, illetve a fejlesztők képesek precedens értékűnek tekinteni ezeket a megoldásokat és egyszerűen lemásolják, mint gyors megoldás.

A forráskód teremtette adósság növekedésnek másik ága az, hogy a világ is változik a meglévő forráskód körül, ami jó megoldás volt pár hónapja vagy éve, az mára már elavult. A használt keretrendszerek is változtak, esetleg új keretrendszerek jöttek ki, amelyekkel megoldhatóak az eddigi kerülő megoldások... (smile)

The biggest difference between the two types of debt is that while technical debt grows faster the more you change a codebase, competence debt grows faster if you stop changing it!

Szóval itt az új fogalom, a Competence Debt, amely sokkal rejtettebb, mint a technikai adósság, ugyanis a fejlesztők kompetenciájáról van szó: arról, hogy a meglévő kódbázist és a használt keretrendszereket mennyire ismerik, mennyire járatosak ezeken a területeken. A nagy különbség pedig az, hogy ha nem nyúlunk a forráskódhoz, akkor a kompetencia adósság jobban növekszik, mint a technikai, amely általában akkor növekszik, ha üzleti nyomásra módosítjuk a kódot és nem állunk meg rendet tenni.

Nálatok mekkora a Competence Debt(smile)

Sonar metrikák

Aki használ Sonar-t (illetve mostanában már SonarQube a neve, mert lett egy támogatott és egy közösségi kiadás belőle), annak ismerős lehet a magas számosságú Magic number (jobban mondva Unnamed numerical constants) bejegyzés, mint Minor súlyosságú hiba. A Magic number – mint programozástechnikai hiba – elismert és létező jelenség, az alábbi (a Wikipedia linkről idézett) kódrészletben az 52 és az 53 tipikusan ilyen szám:

for i from 1 to 52
       j := i + randomInt(53 - i) - 1
       a.swapEntries(i, j)

Logikus kicserélni arra egy változóra, amely megmagyarázza az értelmét:

constant int deckSize := 52
   for i from 1 to deckSize
       j := i + randomInt(deckSize + 1 - i) - 1
       a.swapEntries(i, j)

Ettől egy kicsit javult a programunk olvashatósága és könnyebb érhetősége, de még maradt egy szám, amelyet nem magyaráztunk meg, az 1, amelynek ráadásul több értelmezése is van:

  • egytől kezdjük a ciklusban a számolást
  • egyet adunk hozzá a kártyák számához
  • egyet vonunk le a kiszámolt indexből

 

Nyilvánvaló, hogy ha kicserélnénk ezt a számot három különböző konstansra, akkor a könnyen olvasható és és érthető programunkból olvashatatlan és érthetetlen program lesz:

constant int deckSize := 52
constant int deckStart := 1
constant int deckOffset := 1
constant int randomOffset := 1
   for i from deckStart to deckSize
       j := i + randomInt(deckSize + deckOffset - i) - randomOffset
       a.swapEntries(i, j)

Ebből kifolyólag a Magic number ellenőrzésekor létezik egy kivétellista, amely ezeket a gyakori – és általában nem változtatott – számokat tartalmazza; SonarQube esetén ez öt elemű:

  • -2, -1, 0, 1, 2

 

Ezzel sikerült átesni a ló másik oldalára, több száz Magic number hiba keletkezik a projektekben, amelyeknek a bűne alapvetően az, hogy a használt konstans például 3 vagy 4. Ha kicsit körülnézünk, akkor láthatunk több nagyobb projektet, ahol ezt a listát kibővítették azokkal a konstansokkal, amelyek gyakran előfordulnak és a hibák kijavítása többet ront a programon, például:

 

A tavaly májusi bejelentésnek megfelelően a Google folyamatosan kikapcsolja a Google Code kiszolgálón a bináris letöltések lehetőségét, jobban mondva erre a célra a Drive használatát szorgalmazza.

A döntést több fejlesztő is dühösen fogadta, a szkriptek megjelenésével valószínűleg jelentősebb migráció indul majd meg a többi nyílt forrású rendszereket kezelő szolgáltatások felé, mint a GitHub vagy a SourceForge. A Google Code projektek közül jó pár több lábon áll, a népszerű K-9 levelező kliens például a forráskódját a GitHub-on tartja, a hibajegyek és igények kezelésére a Google Code megoldását használja, a Wikit is már átköltöztette a GitHub-ra... az elkészült bináris állományokat eddig a Google Code-on tárolták, ha erre nem lesz lehetőségük a továbbiakban, akkor már csak az issue kezelő rendszer miatt van csak Google Code függőségük.

A fejlesztőkben felmerül az a kérdés is, hogy mik a Google tervei ezzel a szolgáltatással kapcsolatban... sok fejlesztés nem történt az utóbbi években, a felület és a működésmód – kis sarkítással – pont annyira fapados, ahogy az indulásakor volt, nyoma nincs a többi Google terméket jellemző a folyamatos fejlődésnek, vagy akár csak az ergonómiai javulásnak. Vajon a többi kukázott Google termék sorsára jut a Google Code is, vagy ez csak egy nagyobb koncepcionális váltás előszele?