dinsdag 29 maart 2016

vrijdag 31 december 2010

Winter banden

Het is twaalf graden in oktober, de winter staat weer voor de deur. Op mijn bureau ligt al enige tijd een brief van de leasemaatschappij met het verzoek een afspraak te maken voor winter banden. Via de website probeer ik een afspraak te maken bij Profile Tyrecenter. Dat is niet eenvoudig. Mijn banden liggen blijkbaar in eindhoven. Ik woon in Tilburg. Via de site vul ik een verzoek in om de banden naar Tilburg te transporteren. Dit kan tot maximaal drie weken duren. Geen probleem. Het is nog niet echt koud. De website bericht dat er binnen drie weken contact met mij zal worden opgenomen voor een afspraak. Na iets meer dan drie weken slaat het weer volledig om. Ineens ligt er sneeuw. Ongeduldig bel ik op naar Profile hoe het met mijn winterbanden zit. Er staat niks in het systeem. De banden liggen nog steeds in Eindhoven. Telefonisch doe ik een nieuw verzoek de banden baar Tilburg te sturen. Dit kan maximaal drie weken duren. Fouten worden wel eens gemaakt. Ik rijd wel wat voorzichtiger door de sneeuw. na drie weken heb ik nog niks gehoord. Ik bel op. De jongens zitten te lunchen, ik zal zo worden terug gebeld. Twee uur later bel ik op. Ze hebben nog geen tijd voor gehad om uit te zoeken waar de banden zijn. Ik krijg de indruk dat mijn winterbanden gewoon kwijt zijn. Aan het einde van de volgende dag word ik eindelijk gebeld. Mijn banden staan klaar voor transport in Eindhoven. Inmiddels zijn er bijna zeven weken verstreken. Ik heb het gevoel dat mijn zaak de hoogte prioriteit heeft. Er ligt al bijna een maand sneeuw. Anyway, ik zou nog die week gebeld worden voor een afspraak. Dat gebeurde pas op woensdag de week erna. De man aan de telefoon wekte de indruk dat de banden al even in Tilburg lagen, maar bellen was er nog even niet van gekomen. De hoogste prioriteit. Een afspraak kon gelukkig diezelfde dag nog, om 14:30. Natuurlijk was het druk. Om 15:00 ging mijn auto eindelijk de lucht in en een half uur later reed ik weg me winter banden. Eindelijk weer veilig de weg op.

donderdag 15 juli 2010

Code highlighting in Blogger

Het heeft even geduurd maar eindelijk heb ik code highlighting in blogger voor elkaar. Wat heb ik gedaan? Ga in de instellingen naar het HTML sjabloon van je blog. Voeg voor de <l/head> tag de volgende code toe:
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shCore.css' rel='stylesheet' type='text/css'/> 
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css' rel='stylesheet' type='text/css'/> 
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'/> 
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shAutoloader.js' type='text/javascript'/> 
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'/> 
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJScript.js' type='text/javascript'/> 
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCss.js' type='text/javascript'/> 
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJava.js' type='text/javascript'/> 

Merk op de er script geladen worden van iemand anders zijn pagina. De maker raadt aan om de scripts zelf te hosten.

Voeg vervolgens achter de </body> tag de volgende code toe:
<script>
  SyntaxHighlighter.config.bloggerMode = true; 
  SyntaxHighlighter.all();
</script>

Je kunt nu java code higlighten met:
<pre class="brush: java">code</pre>

woensdag 7 juli 2010

Minimale afhankelijkheden van Hibernate

Het is even geleden dat ik hier iets geschreven heb. Dat heeft twee redenen. Ten eerste heb ik de studiedag meerdere keren gebruikt om de drukte van het werk op te vangen. Daarnaast waren de dingen die ik gedaan heb, niet echt spectaculair: een Java boek uitlezen, spelen met HTML5, CSS3, Geolocation en JavaScript, Internationalisation van UIBInder in GWT en een chrome extensie bouwen. Dat werd allemaal zo goed uitgelegd dat ik weinig kon toevoegen aan de link waar het al perfect uitgelegd stond.

Vandaag was ik aan het spelen met Hibernate aan de hand van een tutorial. Hibernate is een OR-Mapper. Dat wil zeggen dat je objecten in je programma om kunt zetten naar tabel records in je database naar keuze. Als de mapping van de velden eenmaal bekend is, kun je de objecten eenvoudig ophalen zonder complexe queries te hoeven schrijven. Een nadeel is wel dat Hibernate een leercurve heeft vanwege de vele opties die de gebruiker heeft.

Wat mij opviel aan de tutorial was het grote aantal jar-files in het classpath van het voorbeeld. Een goede dertig zouden er nodig zijn voor een "Hello World" voorbeeld. Dat leek me wat overdreven. Zelfs de Google resultaten leken me nog wat uitgebreid dus ik ben met de trial and error methode gaan zoeken naar welke jar files je nu echt nodig hebt voor stap 1 van die tutorial (die het overigens zelfs inclusief alle jars bij mij niet deed zonder wat code aan te passen).

Hieronder de lijst met jars die je absoluut nodig hebt om het voorbeeld met hulp van MySQL te draaien:
  • hibernate3.jar (uiteraard)
  • mysql-connector-java-3.0.16-ga-bin.jar (alleen als je MySQL gebruikt)
  • log4j-1.2.9.jar (voor de logging, maar je kunt ook een andere logger gebruiken)
  • commons-collections-2.1.1.jar (wat collections spul dat niet standaard in Java zit)
  • commons-logging-1.0.4.jar (wat logging spul dat log4j nodig heeft)
  • dom4j-1.5.2.jar (om xml bestanden te interpreteren)
  • cglib-full-2.0.2.jar (doet iets voor hibernate maar het is me niet duidelijk wat)
  • ehcache-1.1.jar (geen idee wat het doet)
  • jta.jar (wordt gebruikt voor transacties)

De andere 20 jars heb je dus voor een simpel voorbeeld helemaal niet nodig. Hier kun je bovenstaande bestanden downloaden.

Zoals ik al zei heb ik het voorbeeld aan moeten passen om het te laten werken. Er is een transactie toegevoegd. Hieronder de code:
public class FirstExample {
 public static void main(String[] args) {
  SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();
  Session session = sessionFactory.openSession();
  Transaction transaction = session.beginTransaction();
  
  try{
   Contact contact = new Contact();
   contact.setId(2);
   contact.setFirstName("Gerben");
   contact.setLastName("Kegel");
   contact.setEmail("gerben@bastarddomain.com");
   session.save(contact);
   transaction.commit();
  }catch(HibernateException e){
   transaction.rollback();
   System.out.println(e.getMessage());
  }finally{
   session.close();
  }
 }
}

zondag 25 april 2010

GAE & Tapestry

Applicaties die moeten draaien in de Google App Engine kun je ontwikkelen in Eclipse en de door Google ontwikkelde plugin. Het maken en deployen van een applicatie is daarmee nog simpeler dan het genereren van een war-file voor Tomcat. Met een druk op de deploy knop wordt je applicatie online gezet.

Als eerste GAE projectje wilde ik een Hello World uit het Tapestry (een framework van Apache) project in GAE deployen. De vraag hierachter is hoe eenvoudig het is om een bestaand framework in de cloud te draaien.

Zoiets begint natuurlijk met even Googlen en de eerste hit is een tutorial hoe je tapestry 5.1 in de App Engine kunt draaien. Helaas werkte het niet (meer) zo simpel omdat een van de XML parsers die Tapestry gebruikt niet (meer) is goedgekeurd door Google. Er waren volgens andere blogs enkele hacks nodig om het aan de praat te krijgen, maar helaas leek ook dat niet het verschil te maken. (Het kan zijn dat ik iets over het hoofd zag.)

Op weer andere blogs las ik dat de nieuwe Tapestry 5.2 wel in GAE kon draaien. En inderdaad, de foutmelding zag er nu ineens anders uit. Het duurde nog even voordat ik ondekt had dat GAE case-sensitive is en dat de template files dus exact dezelfde naam moeten hebben als de bijbehorende classes (wat lokaal onder Windows niet het geval is). Daarmee rekening houdend, heb je het allemaal zo aan de praat en kunnen we vast stellen dat het gebruiken van een bestaand framework in de App Engine geen probleem is mits alle dependencies goedgekeurd zijn door Google.

Ik moet wel toegeven dat het mij enkele uren kostte om de simpele Hello World aan de praat te krijgen, daarom nog een keer de twee pointers:
  • Gebruik de snapshot van Tapestry 5.2;
  • GAE is case sensitive, noem daarom je class geen Index en de template index.tml.




http://www.atentia.net/2010/04/tapestry-on-gaej-java-lang-verifyerror-stack-size-too-large-solved/

Google App Engine

GWT genereert JavaScript dat wordt uitgevoerd in een browser. Zoals eerder geschreven, kun je daarmee vanuit de browser direct methodes op de server aanroepen. GWT zorgt voor de (un)marshalling. Deze in Java geschreven methodes zijn onderdeel van een Java Servlet. Zo'n Java Servlet heeft een container nodig waarbinnen hij kan draaien. Voorbeelden hiervan zijn Tomcat, Jetty, JBoss en Glassfish. Al deze containers zijn programma's welke op een computer kunt installeren en die bovenop de Java Virtual Machine een set features bieden welke handig kunnen zijn bij het ontwikkelen van Web Applicaties.

Wanneer je web applicatie populair wordt, kom je al snel in de problemen. De webserver/Java container kan maar een bepaald aantal verzoeken per tijdseenheid aan. Wanneer het aantal verzoeken blijft oplopen zullen er gebruikers zijn die niet te zien krijgen wat de bedoeling was. De oplossing voor dit probleem is het inzetten van meerdere servers. Hoeveel je er nodig hebt blijft een gok, dus worden er vaak veel te veel servers ingezet. Google had dit probleem ook en hun oplossing hiervoor hebben ze publiek toegankelijk gemaakt in de vorm van hun Google App Engine (GAE).

GAE is onder andere een op Jetty gebaseerde Java container en is onderdeel van de cloud. Wanneer een web applicatie die in deze App Engine draait veel gebruikt wordt, besluit de App Engine om meerdere instanties van de applicatie naast elkaar te gaan draaien, en de verzoeken te verdelen over deze instanties.

De opschaling problemen zijn hiermee verholpen maar helaas zijn er ook nadelen. Zo kun je geen gebruik maken van een SQL server in de cloud. Je bent gebonden aan BigTable (de database van Google) voor het opslaan van data. Daarnaast kun je ook niet zomaar alle jar-files in je project stoppen omdat niet alle Java functionaliteit aanwezig is en GAE. Jar-files moeten daarom worden goed gekeurd door Google.

Als je denkt dat opschalen een van de problemen is waarmee je te maken krijgt in de toekomst, en Java je favoriete ontwikkel taal is, is de Google App Engine zeker het overwegen waard. Als je daarnaast ook nog eens GWT gebruikt, lijkt het helemaal ideaal te zijn.