maandag 12 oktober 2009

Sociale netwerk explosie

Afgelopen jaren is er steeds meer en een steeds grotere focus door websites op het sociale aspect van het internet. De gebruikers kregen de kans om zelf inhoud toe te voegen aan websites door bijvoorbeeld het schrijven van beoordelingen. Een van de eerste die hiermee begon was Amazon die haar klanten reviews op de website liet plaatsen (wat nu al 15 jaar geleden is).
Tegenwoordig is er een ware explosie gaande in het aantal sociaal georiënteerde websites. En als je al een website hebt wil je of inhaken op bestaande sociale netwerk websites, of zelf functionaliteit hiervoor toevoegen.

Daarom zie je tegenwoordig ook veel websites met de mogelijkheid om een pagina te ‘tweeten’, of toe te voegen aan je Facebook of MySpace pagina. Mits dit goed gebeurd kan dit een zeer krachtige marketing tool zijn en kan zelfs goed gebruikt worden voor klantenondersteuning.
Veel mensen hebben het succes gezien van de al bestaande grote jongens op het gebied van sociale netwerken. En proberen het succes te kopiëren, of proberen een nieuwe unieke dienst aan te bieden, in de hoop hun eigen niche te vinden. En dit heeft voor een explosie gezorgd in het aantal sociale netwerken en van websites die hiervan gebruik maken.

En dit levert inderdaad soms interessante resultaten op. Zoals de dating site Gelato die jouw gegevens van andere sociale netwerk sites verzamelt voor het bouwen en weergeven van je profiel. Of bijvoorbeeld Wakoopa die statistieken verzamelt over je software gebruikt. En je in contact brengt met vergelijkbare gebruikers of nieuwe software voorstelt.

De genoemde voorbeelden zijn leuk en interessant om eens mee te spelen. Maar er is een nieuwe die echt mijn aandacht heeft getrokken en ik niet kan wachten tot ik hier eens goed mee kan spelen. En deze sociale netwerk site is FourSquare.

FourSquare laat een nieuwe trend zien (en is niet de enige hierin): het sociale netwerk als spel.
Bij FourSquare doe je een ‘Check in’ als je een bepaalde locatie bezoekt, bijvoorbeeld een bioscoop of je favoriete bar. En voor elke ‘Check in’ krijg je punten of zelfs zogenaamde ‘badges’. Grappig om te zien en aan mee te doen, maar nog niet gelijk waarom ik zo enthousiast ben over de nieuwe sociale netwerk site.

Waar ik vooral heel enthousiast over ben is dat gebruikers tijdens zo’n ‘check in’ iets over de locatie kunnen schrijven. Dus ervaringen, tips en suggesties kunnen delen. Dit geeft je gelijk een goed idee hoe mensen over de zaak denken en wat er te doen is op dat moment. Zeer waardevolle informatie als je even wilt weten of een bepaalde zaak of locatie goed is.

En door dit heeft FourSquare ook de aandacht getrokken en enkele bekende financiers gekregen. En FourSquare heeft ook gelijk een inkomstenbron veilig gesteld: advertenties (iets wat Twitter nog steeds niet gelukt is om goed te integreren). En dit zijn niet de standaard advertenties in de vorm van een banner hier en daar. De advertenties zijn gericht op de gebruiker en waar hij is. Dus als je bijvoorbeeld bij een bepaalde bar een ‘check in’ doet, kan het zijn dat je een advertentie te zien krijgt met daarin een aanbod om een drankje met korting te kopen. Zeer slimme manier om te adverteren, en gelijk ook op een manier die interessant is voor de gebruiker (en zeer mogelijk de participatie verhoogt).

Jammer genoeg heeft de website op dit moment nog één zeer groot nadeel. Je kan op dit moment in Nederland alleen in Amsterdam ‘check ins’ uitvoeren. Amsterdam is namelijk de enige stad die op dit moment beschikbaar is. Ze zeggen dat zodra ze meer capaciteit hebben ze meer steden gaan toevoegen. Maar het geeft wel een flinke restrictie in hoe en waar je de website kunt gebruiken.
Maar als deze restrictie weg is, en gebruikers helemaal vrij zijn in het gebruik van de website, ben ik zeer benieuwd wat er zal gebeuren. De potentie om iets heel unieks te worden is er.

dinsdag 6 oktober 2009

Einde aan boilerplate met Project Lombok

Weer een getter en setter schrijven, weer die equals en hashCode updaten omdat er weer een field bij is gekomen. Gelukkig heb je die twee generiek gemaakt via reflectie. Maar wat word daardoor die HashSet toch traag, toch maar weer handmatig implementeren. En oeps, een tikfout die toch wel valid Java blijkt te zijn is erin geslopen! En oh ja, ook nog toString aanpassen…

Toch vreemd dat zoiets als een getter, setter, toString, equals en hashCode toch weer zoveel problemen geven, vooral omdat IDE’s deze toch al weer een tijdje voor je kunnen genereren. Maar deze zul je toch ook nog moeten onderhouden (al was het alleen maar regenereren van deze methodes). Je zou toch haast zeggen dat dit werk is voor een computer? Daarnaast blijf je constant tegen die methodes aankijken in de source, en dat geeft, en brengt, extra mentale belasting die eigenlijk helemaal niet nodig is in de meeste gevallen.

Er zijn over de jaren een aantal oplossingen bedacht voor dit probleem, een ervan is equals, hashCode en toString via reflectie. Dit werkt, helaas werkt het ook traag. Dit komt omdat de JVM (HotSpot) deze niet goed kan inlinen omdat het in feite type-less code is. En reflectie kan ook geen getters en setters maken die je in je code kan gebruiken (of in Swing).

Daarnaast zijn er door de jaren heen een aantal JSR Proposals geweest om een property keyword te krijgen, zodat getters en setters automatisch gegenereerd worden.
Bijvoorbeeld:

class Point {
public property int x;
public property int y;
}

om het volgende te genereren:
class Point {
private int x;
private int y;

public int getX() {
return x;
}
public void setX(int x) {
this.x = x;
}
public int getY() {
return y;
}
public void setY(int y) {
this.y = y;
}
}

Maar de meest recente versie van deze proposal, in Project Coin, heeft de selectie niet gemaakt (voor Project Coin). Daarnaast lost dit ook niet direct het equals, hashCode en toString probleem op (uiteraard wel met de reflectie oplossing).

Het is in feite interessant om te zien dat, bijvoorbeeld, Scala dit soort dingen wel doet, in de vorm van case classes, bijvoorbeeld de Point klasse hierboven:
case class Point(var x:Int, var y:Int)

Dit genereert constructor, getters, setters, toString, equals, hashCode en Scala specifieke features, zoals Pattern Matching.

Maar er is licht aan het einde van de tunnel.

In Java5 zijn er, samen met Generics, Annotations toegevoegd. Hiermee kan je klassen, methoden, fields en parameters annoteren met metadata. En samen hiermee is er ook "APT" of "Annotation Processing Tool" uitgebracht. Dit is een losse tool, zoals javac, dat met een set processors een selectie klassen doorloopt en deze aanpast. Het is voornamelijk een source processing tool, waarbij acties getriggerd worden op annotaties.

Het is dus mogelijk om een annotatie te schrijven die een getter en setter van een veld genereert, of een toString, etc, etc. Het mooie is ook dat zodra dit is gebeurd je de nieuwe methode direct kan zien, en gebruiken, in een IDE, de meeste IDEs gebruiken class files om te zien of een methode (of zelfs class) bestaat.
Maar het schrijven van een AnnotationProcessor is lastig, en dit is een losse stap, en je kan het dus vergeten, en dan kan je leuke situaties krijgen, bijvoorbeeld dat getters en setters niet bestaan terwijl je deze op andere plekken wel verwacht.

Gelukkig is het in Java6 nu mogelijk om direct, bij het aanroepen van javac, annotations te processen. En daarom is er nu Project Lombok.

Lombok komt met een aantal standaard annotations om boilerplate te verwijderen.
Je voegt het gewoon toe aan je classpath (tijdens het compilen) en de annotation processors erin gaan aan het werk. Een lijstje met de annotations die meegeleverd worden zijn:
  • @Getter en @Setter
  • @ToString
  • @EqualsAndHashCode
  • @Data
  • @Cleanup
  • @Synchronized
  • @SneakyThrows
Alle annotations zijn te configureren.
De eerste drie (punten, vier annotations) spreken voor.
@Data combineerd de eerste 3 punten.
@Cleanup kan je gebruiken op variabelen in methodes zodat deze try { } finally { } blocken genereerd en een methode aanroept (default is close, maar kan ook "myOwnCleanupMethod" zijn).
@Synchronized is een method level annotation en word gebruikt om een algemeen synchronized pattern te gebruiken die beter locked op een field i.p.v. een (static) field. Het is ook mogelijk om meerdere, andere, locks te definieren (beter gezegd, specifieke velden te gebruiken).
Als laatste is er @SneakyThrows, dit word gebruikt om een methode bepaalde checked exceptions te laten throwen, zonder dat deze in de method descriptor hoeven te staan (de throws keyword). Een voorbeeld is UnsupportedEncodingException, zeg nou zelf, wat is de kans dat UTF-8 niet bestaat in jouw JDK? Wat dit doet is je methode wrappen in een try { } catch() {} block, en de ongewenste exception catchen, en deze dan te throwen met een unchecked exception.
Enkel voor de @SneakyThrows hoeft de lombok.jar runtime beschikbaar te zijn (omdat het een utility methode aanroept die de echte sneaky-throw doet).

Mijn vorige voorbeeld klasse kan met Lombok gereduceerd worden tot:
@EqualsAndHashCode @ToString
class Point {
@Setter @Getter private int x;
@Setter @Getter private int y;
}

Of nog korter:
@Data
class Point {
private int x;
private int y;
}
En dat is veel beter! Nog mooier is dat je het niet kan vergeten, als je de lombok.jar vergeet tijdens het compilen dan kan de compiler de verschillende annotaties niet vinden, en kan het compilen niet werken.

Om af te sluiten raad ik het je aan om de screen-cast te bekijken die op de Project Lombok website staat, en het gewoon uit te proberen. Eindelijk einde aan boilerplate code!