Yet, there is still a question about creating the original slice. Should I do it from the backend to the frontend, or the other way around (UI first)?

I prefer the second one, as it suits me better, but also, I think it’s better aligned with the original intention: To implement something visible – at that moment it is pretty much like a prototype – and then extending it backwards: adding the communication layer first, then the server side, then the database. (or just filling in the already created empty objects)
With a few notable exceptions, most of what we do must be visible for the/a user. Therefore, upfront UI development acts as a second layer of test driven development, with the developer as the testing framework.

Thoughts?

Tegyük fel, hogy az Amazon be akar vezetni egy újféle rendezést: Ha a felhasználó úgy keres, hogy nem specifikálja, mi szerint akar sorbarendezni, akkor egy relevancia szerinti sorbarendezést kap.

Az első feltétele ennek, hogy meghatározzuk, a user milyen szegmens része: Ha korábban főleg technikai kütyükre keresett, akkor vsz. fiatal férfi, míg ha babaruhákat és melltartót vásárolt, akkor jó eséllyel családanya.

A következő lépés annak a meghatározása, hogy melyik szegmens mit szeret és mit nem. Ha például mobiltelefonokat nézünk, akkor a nerd-öt technikailag orientált férfit jobban érdekli a felbontás, mint a készenléti idő, míg a családanya inkább egy ütés, por és víz (nyál) álló telefont értékel, ami túléli a gyerekek támadását.

A fentiek meghatározása után elkészítjük az első komponenst, ami minden szegmenshez meghatároz egy ratinget az adott dologra. Pl. minden egyes telefonra megmondja, hogy az első szegmensnél a felbontásra kap X pontot, az ütésállóságra meg Y pontot, így az össz ratingje X+Y, és ez így tovább a többi szegmensre. Utána már csak annyi dolgunk van, hogy ha valaki rákeres a mobiltelefonokra, akkor – ha kb. tudjuk, ő milyen szegmensben van – akkor a találati listát az adott szegmenshez kapcsolt rating érték alapján csökkenő sorrendbe rendezzük (feltételezve, h a nagyobb rating a jobb).

Eddig nem túl bonyolult a dolog. Itt jön azonban a csavarás: Mi van akkor, ha a user – pl. amiatt, mert a héten minden HTC telefonra 10% leértékelés van – hirtelen csak HTC-ket kezd el látni a találati listában? Ez számunkra nem olyan kívánatos, mert mi azt szeretnénk, ha a felhasználó sokfélét látna ott – ugyanis simán lehet, hogy az adott felhasználó titokban utálja a HTC telefonokat, és tulajdonképpen Samsungot szeretne, de ezt nem tette bele a keresésbe valamilyen okból. Ez az, amit nálunk shuffling-nek hívnak, azaz keverésnek: Fogjuk a találati listát, és átrendezzük úgy, hogy a találatok változatosak legyenek.

Az első megfigyelés az, hogy ezt a keverést mindenképpen a találati listán kell megcsinálnunk, mivel ez keresésenként változik, és látatlanban nem tudjuk előre átrendezni a hasonló találatokat. A felhasználói szokásokat ismerve az is elég valószínű, hogy nem kell az összes találatot átrendeznünk, hiszen a felhasználó ritkán néz meg két oldalnál többet. Az is fontos, hogy ha a keresés pl. egy adott gyártóra történt (mondjuk Samsung) akkor ne erőlködjünk azon, hogy a gyártók szerint is sorbarendezzünk. Hasonlóképpen, ha a listának mondjuk 95%-a ugyanaz a gyártó, akkor szintén értelmetlen a keverés. Továbbá, feltételezhetjük, hogy a vásárló számára értékesebb az, ha minél változatosabb a lista, tehát azt is jó lenne elkerülni, hogy kétféle dolgot váltogassunk (HTC, apple, HTC, apple), ha a listában van mondjuk Samsung és Motorola is.

Van itt azonban egy érdekes kérdés: Ha már 1x berendeztük aszerint, hogy ezek az elemek milyen jók a usernek, akkor most nem vágjuk ezt teljesen felül azzal, hogy megkeverjük? A válasz kettős: Igen, alaposan megbolygatjuk a sorrendet, és nem, nem teljesen vágjuk felül. Lehetőség szerint úgy kell rendeznünk, hogy a találatok az eredeti sorrendhez a lehető legközelebb maradjanak. Ennek az eszköze lehet az algoritmushoz hozzácsapott maximum mélység, ami arról szól, hogy megmondjuk, hogy az átrendezendő elemekre – ami mondjuk a találati lista első 100 eleme – definiálunk egy %-ot, hogy ennél messzebbről ne rángassunk fel elemet semmiképp.

Erre alkottam egy algoritmust, amelyre a következő dolgok igazak: A rekord 1 mezőjére vizsgál, aszerint ha 2 azonos rekordot talál, akkor a találati listából maximum a meghatározott mélységen belül elővesz egy olyat, ami eddig arányosan a legritkábban volt használva. Ugyanolyan ritkaság esetén az eredeti halmazban gyakrabban előforduló elemből vesz. Az algoritmus szekvenciális, a feldolgozott elemeket már nem változtatja, csak a még keveretlen listát.

Hogy néz ki a végeredmény? 15 elemre, 20%-os mélységgel (max 3 elem) az alábbi előfordulásokkal az alábbi eredményeket kapjuk: (bal oldalon az eredeti lista, jobb oldalon a kevert)

Value distribution:

HTC     : 60%
Apple   : 13%
Samsung : 26%

     Index   Make      Index   Make
      ------------------------------
       1, Samsung        1  Samsung
       2,   Apple        2    Apple
       3,     HTC        3      HTC
       4,     HTC        6  Samsung
       5,     HTC        4      HTC
       6, Samsung        5      HTC
       7,     HTC       10  Samsung
       8,     HTC        7      HTC
       9,     HTC       11    Apple
      10, Samsung        8      HTC
      11,   Apple        9      HTC
      12,     HTC       13  Samsung
      13, Samsung       12      HTC
      14,     HTC       14      HTC
      15,     HTC       15      HTC
Hosszabb listákra nyilván sokkal hatékonyabb, de szerintem így is látszik a különbség.

Ígyhát megszületett az ötlet: csinálok egy XML-t, ami formailag megfelel annak, amit szeretnék, és addig javítom a sémát, amíg validálható az xml. Ez meg is történt, utána nekiálltam a sémát szépítgetni, hogy megfelelő típusok, required attribútumok legyenek. Aztán nekiláttam a következő változtatásnak, először átírva az XML-t, …

Ekkor realizáltam, hogy gyakorlatilag a TDD lépéseit ismétlem. Írok egy tesztet – a formailag helyes XML.  Utána lefuttatom a tesztet – validálás – ami piros lesz. Utána addig javítom a sémát, amíg a validálás nem sikerül – development. Majd szépítgetem a sémát – refaktorálás. Végül iterálok.

Érdekes élmény volt

Writing a client/server application communicating over sockets is pretty easy in Java. The server creates an instance of the aptly named ServerSocket class, which waits for incoming connections. The client creates a Socket instance, which then connects to the server (thus creating another Socket on the server side via the accept method of the ServerSocket), and that’s it. Although Sockets are normally blocking read operations, it is easy to emulate a single threaded non-blocking communication with simply checking the available bytes on the socket, and reading only that much.

Blocking secure socket communication, the problem

Switching to a secure socket connection is very easy: First, you need to create some keystores, then some initialization in the code and then you can use some factory classes to create the secure sockets instead of the original constructor calls. Everything else is almost the same.. except..

Getting the number of available bytes are not reliable any more. The reason is simple: As your security and application data arrives in the same stream, the security engine is not able to tell the amount of available application bytes without trying to decrypt everything, but that is a complex operation. Probably more complex and requires more effort than you would like to have in an infinite loop.

Because of this, our workaround for blocking communication is not usable anymore. For a simple application with just one or a handful of clients it is acceptable to have a separate thread for all of the connected clients on the server side, but we need another solution for high user counts.

SocketChannels

Java NIO has a nonblocking socket solution. SocketChannels are designed for this. Because of the fundamentally different usage and the additional classes, such as Selectors, most people never uses them, but they are not overly complex, and with a little practice can be used easily. For beginners, I’d recommend reading this article: Rox Java NIO Tutorial. It’s probably not the easiest to understand, but contains very useful tips and explains typical pitfalls.

Using this, we solve the issue with the blocking channels, but security is still lacking. The bad news is: It is pretty hard to make SocketChannels secure. This is your second chance to turn back, and use the blocking solution, they say a few thousand threads are not really a problem for a good server

Securing SocketChannels

Ok, you are desperate. You want ‘em non-blocking channels communicate securely. Here is what you need to add to the code:

1. You don’t need to do anything with the ServerSocketChannel, and the way it accepts connections.
2. I prefer doing the reading and writing in a separate class, which “owns” the connection and the SSLEngine. (See Below)
3. Initialize your security.
4. On the server side, for every new socketchannel, create a new SSLEngine.
5. On the client side, do the same for your one channel.
6. Initiate the handshake.
7. After the handshake, wrap everything you want to send and unwrap everything that you receive on both sides.

So far it is not too complex, right? Let’s dig deeper.

Initializing security:

private void setupSecurity() {
	SecureRandom secureRandom = new SecureRandom();
	secureRandom.nextInt();

	KeyStore clientKeyStore = KeyStore.getInstance("JKS");
	clientKeyStore.load(new FileInputStream("client.jks"), "KeyStorePassword".toCharArray()); 

	TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
	tmf.init(clientKeyStore);

	KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
	kmf.init(clientKeyStore, "KeyInKeystorePassword".toCharArray());

	sslContext = SSLContext.getInstance("TLS");
	sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), secureRandom);
}

Couldn’t be more straightforward. Creating an SSLEngine is just as easy:

SSLEngine engine = sslContext.createSSLEngine();

And now the handshake.. You can find a lot of explanations here (it’s a bit dry, but very useful). The scaffolding for the code can be found in the same article, but you are better off if you check the code here: [jdk home]\sample\nio\server\ChannelIOSecure.java

It is very complicated, and there is a hidden “flaw”: It’s meant to be used with blocking channels. (See below). Also, some structures are a bit more complex than I’d usually like it, for example the 3 levels deep switch constructs. Anyway, for now you should just try to copy it as closely as you can, and if you can make it work, then you can improve the code as much as you want.

The problems I faced

Obviously, it didn’t work for me the first time I tried. Here are some tips:

• Don’t give up. It’s complex and ugly, but it can be done.
• If the handshake doesn’t start, and/or the server complains about plaintext connection, insert the engine.beginHandshake() line before the handshake process. Sometimes the only issue that you see is that the clients sends the messages and the server simply absorbs them without any apparent effect.
• If you get repeated buffer underflow errors on the server side, and using non-blocking communication, it’s time to add a new check for zero length reads. Trying to unwrap zero length ByteBuffers can cause this issue.
• In case of unsupported record version problems or sequence violation (during the handshake) try to empty your buffers before you read/unwrap into them and after you have sent them to the other party. Leftover bytes can cause this issue. (Unsupported record version Unknown) (Handshake message sequence violation)
• If the server/client complains about invalid handshake mac, check your flushing code. You may loose some important bytes. (bad handshake record MAC)
• Google is your friend: There are a lot of people out there who solved the same issues and wrote an article about it.
• It’s a good idea to add some logging to the code to see what is happening. It helps you to see the sequence of events on both sides.
• There are some issues and solutions here I didn’t face. Still, you may see them.

I hope this will help some of you to develop some great, secure applications.

A konstruktivitás világnapjának a jegyében nézzünk rá arra, hogy mi adhat nekünk okot az önbizalomra. A vezetőség elismerése? Nem, az nem szakmai elismerés. Nekem a következő dolgok adnak önbizalmat:
- Sokféle helyzetben voltam már, és még soha nem kellett feltennem a kezem, hogy: “Ezt nem lehet megoldani, és fogalmam sincs, hogy mit kellene most csinálnom”. Volt, hogy sokat szenvedtem a megoldással, de mindent sikerült megoldani vagy megkerülni.
- Tudom, hogy a szakma olyan széleskörű, hogy senki nem tudhat mindent, de ha bármire szükségem van, meg tudom tanulni, mert megvan a szakmai alapom hozzá.
- Kapok pozitív visszajelzéseket a munkámról olyan emberektől, akiket magamnál okosabbnak, szakmailag tapasztaltabbnak tartok.

Minden kollégámnak ajánlom az IT bármely területén, hogy nézzen magába néha, és gondolkozzon el, hogy helyén van-e az önértékelése? Akár csak a fenti három pontot és gondolja végig őket őszintén. Sokat lendítene a szakma színvonalán egy kis tisztánlátás..

A minap, amikor a javas Annotation-ökről olvastam, belefutottam az általam korábban még soha (tudatosan) nem használt apt (Annotation Processing Tool) nevű eszközbe. Ahogy olvasgattam a képességeiről, felmerült bennem, hogy ezzel meg lehetne oldani azt, amit én statikus DI-nak és statikus AOP-nek hívok.

Az apt lényege, hogy – főként az annotációkat használva, de generálisan is – fordítás előtt átszalad az egész kódon, és meghív bizonyos, a felhasználó által specifikált feldolgozó egységeket, amik átalakíthatják a kódot, vagy hozzáadhatnak új osztályokat, etc. Gyakorlatilag beteszünk egy extra lépést a kód elkészítése és lefordítása közé.
Valami ilyesmi a statikus AOP lényege: Bár kód szinten elszeparáljuk a különböző dolgokat, például a logolást, és pusztán egy annotationnel jelöljük, hogy ez a metódus kellene, hogy logoljon (@LoggingMethod, pl.), a lefordított osztályokban már megjelenik az a kód. Hasonlóan működik a DI is.

Például: Össze akarom gyűjteni az összes Command osztályt egy List -ba.
Csinálok két annotációt és egy statikus függvényt, mondjuk registerCommand(Command c). A függvény feladata mindössze annyi, hogy a fenti listába belerakja a Command osztályt (és csinál vele minden egyebet, amit csak akarunk), az annotációk pedig kb. így néznek ki:

@Target(ElementType.TYPE)
public @interface CollectionMarker {
    String collection();
    String enabled() default true; // erről meg ejtek pár szót
}

@Target(ElementType.METHOD)
public @interface CollectionMethod {
    String collection();
}

Az utóbbit elhelyezem a fenti függvényen, az előbbit pedig minden egyes Command osztályon, amit megírok.

Ezután a processzorok úgy működnek, hogy az egyik összegyűjt egy listát az összes CollectionMarkerrel megjelölt osztályról, a másik megjegyzi, hogy hol a CollectionMethod, majd a feldolgozás végén a megjegyzett osztályba berakunk egy static initializer blokkot, amibe belekerül egy csomó registerCommand(new AkarmilyenCommand());. S lőn, kész is van a chain.

Amit vesztünk ezzel, az
- A dinamikusság: Nem elég átírni egy XML-t és újraindítani az alkalmazást, mint a Spring-nél, ha változtatni akarunk valamit a dependencián. Mindenképpen újra kell fordítanunk az alkalmazást.
- Fordítási sebesség: A fordítás valamivel lassabb lesz
- Rugalmasság: Nyilvánvalóan van egy csomó olyan DI alkalmazás, amit nem lehet megoldani statikus módon.

Amit nyerünk vele:
- Némi performancia
- Átlátható kód extra frameworkok nélkül
- A Spring XML-hez viszonyítva: compile time ellenőrzés a dependenciákra
- Automatizált taszk végrehajtás (Az új command hozzáadása esetén csak az osztály kell létrehoznunk és ellátnunk a megfelelő annotációval, nem kell még különböző ponton beszúrni listákba)

Említettem fent, hogy az enabled attribútumról még ejtek pár szót: ha a gyűjtő egység figyeli ennek is az értékét, és nem gyűjti be azokat, ahol az enabled értéke false, akkor ennek a kapcsolónak az átbillentésével ki-be kapcsolhatjuk a gyűjtését. Akár még azt is megtehetjük, hogy a true-false helyett szinteket definiálunk, és bizonyos osztályokat csak debug módban használunk, productionben nem (ezeket, ha jól sejtem, akár ki is törölhetjük a feldolgozás során..).
Ez így magában még nem is annyira érdekes, de van még egy ennél is fontosabb szerepe: ha a fenti annotation definiciót (a Markert) megfejeljük egy @Inherited annotációval, akkor a leszármazottak is öröklik. Innentől elvileg minden leszármazottat begyűjtünk.. kivéve, ahol specifikusan kitesszük a markert a az enabled attribútum értékét false-ra állítva.

Akik az IDE integráció miatt aggódnak, azoknak sem kell igazából. Az Eclipse-t biztosan tudom, hogy támogatja ezt, a Netbeans és IDEA esetén pedig csak sejtem, hogy támogatják ezt a dolgot (vsz. 5 perc lenne kideríteni a google-lel).

Egyelőre csak a fejemben született meg ez a dolog, nem valósítottam meg, de a horizonton van. Ha lesz konkrétum, vsz kirakom valami elérhető helyre, mondjuk google code.

Ime a legszorakoztatobb: http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html

Vicces programozassal kapcsolatos idezetek. A kedvencem:

32. “The evolution of languages: FORTRAN is a non-typed language. C is a weakly typed language. Ada is a strongly typed language. C++ is a strongly hyped language.”

- Ron Sercely 

Az egyik tipikus eset, amikor en hasznalom, az az, amikor hasonlo feldolgozasi feladatot csinalok ket kulonfele objektumtombre. Pl.

String lastname = null;
for(Tipus peldany : peldanyLista) {
  if(lastname == null) {
    peldany.valamilyenFuggveny();
    lastname = peldany.name();
  } else {
    peldany.masFuggveny(lastname);
    lastname = null;
  }
}

Majd ugyanezt meg akarom csinalni a MasTipusra is, de ott a szintenMas es a megintMas fuggvenyeket fogom hivni, emiatt a generics-es fuggveny sajnos nem megoldas. (ne foglalkozzunk azzal, milyen buta a kod, csak a pelda miatt van itt)
Szoval fogom, atmasolom, atirom benne a dolgokat MasTipusra, es orulok. A problema csak az, hogy mondjuk elfelejtettem kinullazni a lastname ojjektumot, es emiatt a masodik ciklus egesz mashogy fog viselkedni, mint kene.

Azon lusta programozok szamara, akik hozzam hasonloan elnek neha a copy-paste-tel, egy apro otlet: probaljak ilyen esetben a masik kod ele masolni az ujat. Ha a fenti peldaban a lastname ele masoljuk, akkor a lastname hasznalatat serelmezni fogja a fordito, es eszrevesszuk, hogy egy olyan dependenciat iktattunk be, amit nem kellett volna. Ez termeszetesen nem silver bullet, legfeljebb az esetek 20%-ban mukodik, de az se rossz. Persze, erdemes az egeszet kifaktoralni egy sajat fuggvenybe, es akkor meg olvashato is lesz.

Azonban a napokban rajottem, hogy mikor van ertelme ennek: A scriptnyelveknel. Csodalatosan ki lehet vele szurni a szintaktikai hibakat – az eloforditott nyelveknel erre nincs szukseg, hiszen ott a forditassal (gyakran a fejlesztessel) egyidoben megy a szintaktikai ellenorzes, de a scriptnyelveknel ez mar nem ilyen egyertelmu.
En most eppen Pythonban irom a keszulo alkalmazasom szerver reszet. Egyszeru, gyors, de scriptnyelv. Erdemes pylint-et hasznalni, es erdemes tesztelni. Ha lenne webes felulete, vsz igen meretes javascript programok is lennenek hozza. Ugyanez a helyzet, van jslint, es kell irni teszteket.

Na, ilyenkor jo a coverage.

Update: Egy kis magyarazat, hogy mirol is beszelek:
public class A() {
private int a = 5;
public int getA() { return a; }
public void setA(int a) {this.a = a; }
}

Erre a fentire igy is lehet 100%-os coverage-et csinalni:
@Test
public testA() {
// given
setupStuff();

//then
// ..who cares?
}

holott valami ilyesmire lenne szukseg:
@Test
public testA() {
// given
setupStuff();
int firstInt = 34;
int secondInt = 45;

//then
assertTrue(firstResult == firstInt);
assertTrue(secondResult == secondInt);
}
Es akkor tudjuk is, hogy mukodik.