onsdag 31 oktober 2012

Scaling Xebium

Hello.

We really like the Xebium project and we are hoping to use Xebium for our functional testing.

All is well but we have trouble scaling up. Scaling Selenium is no problem with GRID 2 (one server and n node(s)). The unit test running manages to connect to the remote server and the test gets delegated to the node and ran perfectly. But we can’t really get Xebium work towards a Selenium hub.

In the Xebium installation there are an example suite containing the test: “Example 008 Running Tests with Selenium Server”.

Running this test generates the following error:

start browser Could not invoke constructor for StartBrowser[7]
firefox The instance decisionTable_3. does not exist on url
The instance decisionTable_3. does not exist
http://localhost The instance decisionTable_3. does not exist … and so on.

What on earth are we missing?

Environment:
  • Xebium server 
  • Selenium GRID 2 
  • A Selenium Web Driver node with Firefox. 

All three instances are currently on the same machine. A theory we have is that Xebium itself should be started as the server that the nodes should be registered against. But that really does not make sense.

I do not fully (or at all) understand how the Xebium server that wraps both Fitnesse and Selenium maps to the Selenium scaling architecture.

Please advice!

Best regards

@demassinner

måndag 29 oktober 2012

Java är hett i Jönköping

Jag får många frågor om vad man skall läsa på för att möta Java utvecklare kraven i Jönköping. Här kommer en kort sammanfattning.

Teknik

  • Seam 2
    • Bijection
    • Transaktioner (Conversation scope etc)
  • JPA implementation Hibernate 3.4 (ORM framework)
  • JSF (presentation framework)
    • Facelets
    • Richfaces 3.3
  • EJB 3

Infrastruktur

  • Maven 2
  • Jenkins
  • Subversion

SOA stuff

  • JAX-WS
  • JMS

Utvecklingsmiljö

  • Eclipse
    • Findbugs
    • Checkstyle
    • Cobertura

Strange stuff

  • Drools
  • JBoss BRMS

Metodik

  • Rup
    • Användningsfall
    • Arkitekturbeskrivning
  • Agile
    • Scrum
    • Domain Driven Design (DDD)
    • Wiki
    • XP
      • Test Driven development (TDD)
      • Code rules
      • Clean Code

Böker

Jag har läst en del, men dessa bör man inte missa.

Annat

För TDD, kolla på Clean Code filmerna och öva med Katas :)

torsdag 25 oktober 2012

Att välja webbläsare


Många aspekter att ta med i beräkningen.

Att ta fram en ny rekommendation för vilka webbläsare man skall stödja är en utmaning. I arbetet så måste  en mängd aspekter tas med i beräkningen, t.ex. kan man i drift smidigt uppdatera och administrera en viss webbläsare i organisationen.

Avgränsning

Idag har man höga krav på vad man måste kunna göra i webbläsaren. Centralt för många verksamheter är hantering av GIS (Geografiskt Informationssystem). Att kunna interagera med en karta i webbläsaren är ingen enkel uppgift. Med tanke på detta tittar vi gärna framåt (ur ett standard-perspektiv), med intresse på vad som hänt i webbläsarvärlden under senare år.


Jag fokuserar i denna artikel endast på standard- och teknik-aspekten av webbläsare för desktopen - och alltså inte för mobila enheter.


Standarder måste tas i beaktande eftersom den webbläsare som är vanligast i dag kanske inte är det i morgon. Följsamhet gentemot standarder minskar produktberoende och ökar valfrihet!

De tekniska detaljerna som nu följer är en del av det appendix som hör till utredningen.

Appendix A, Teknisk utredning

Standardiseringen görs huvudsakligen av W3C. Begreppet HTML5 är ett paraply för en mängd tekniker som använts på webben och nu standardiseras. Standardiseringsarbetet släpar per definition efter jämfört med innovation. Man standardiserar helt enkelt det som blev bra ute i community-sfären.

Det löpande arbetet (community-sfären) med att driva teknikerna framåt och hantera buggar sköts av WHATWG. Det finns ytterligare grupper att hålla reda på, såsom Khronos. Khronos arbetar för att standardisera WebGL.

De organisationer och företag som står bakom olika browsers är:
TODO: kommentera alla vendors. 

Microsoft

Microsofts Internet Explorer är ökänd för att gärna vilja gå sin egen väg. Detta kan historiskt ses ur två perspektiv
  • Browsern var surf-standard, även om den inte följde W3C standard. När Microsoft väl hade monopol så drev inte företaget plattformen framåt eftersom webben som plattform kunde konkurrera med deras operativsystem.
  • Microsoft är ett företag som inte förespråkar open source, utan hellre säljer propriotär mjukvara. Att måna om öppna standarder och implementera dessa ses inte som en konkurrensfördel.

HTML5 paraplyet

HTML5 är en term som rymmer en mängd tekniker. Dessa tekniker har florerat på webben under en längre tid och standardiseringsprocesserna har börjat hinna ikapp. Frågan är hur bra olika browsers implementerar dessa tekniker. 

Beroende på vad man vill uppnå så får olika tekniker större vikt. Men ett antagande är att nedanstående tekniker kommer att spela en stor roll.

JavaScript motorer

Utan motor går det inte att köra. Utvecklingen av JavaScript-motorerna går snabbt fram och skillnaderna mellan webbläsare och versioner är väldigt stor.

Dessa benchmarks är inte helt enkla att genomföra eftersom de viktiga parametrarna beror på lösningens domän. Dessutom är jämförelserna haltande när det gäller versioner. Chrome är vinnaren just nu. Men grafer kan visa det motsatta eftersom IE 9 jämförs med Chrome 10. Men eftersom Chrome uppdateras med täta intervall så är förhållandet i själva verket det omvända med Chrome v22. Vad gäller Javscript så finns även här standarder att ta hänsyn till.

Vanligt benchmark är Sunspider:

Web Socket

Web Socket (WS) är TCPIP som wrappas av HTTP, vilket används för att strömma data. För att uppnå denna funktionalitet så har tidigare polling  eller long polling använts. Comet  är en samlingsterm för tekniker som möjliggör push av data till browsern och strömning av data.

WS möjliggör så mycket mer, eftersom det ger möjlighet att kommunicera data i båda riktningarna på ett sätt som tidigare bara var möjligt i feta klienter. Vidare ger det bättre möjligheter att komma igenom  brandväggar, proxies och annan infrastruktur.

Google använder i tex Gmail SPDY som måste anses som likt Web Socket. Men eftersom standardiseringen och implementation av Web socket har kommit långt både klient och serversidan är tekniken i talande stund det enklare valet.


Binära data typer

JSON har likställts med webbens binära data format. Men med dagens rika användarinterfaces (UI) så krävs det att man kan hantera binärt data i JavaScript.


Rika renderings möjligheter

Möjlighet att rita upp kartor eller liknande rika ui:n ställer höga krav. I dagsläget använder man en 2D-produkt som heter OpenLayers.

2D
Tvådimensionell grafik uppnås genom att använda canvas som i princip är en yta man kan rita i via ett API. Det finns ett flertal standarder, som SVG, att ta hänsyn till här.

TODO: skriv något om Kanvas och SVG.


3D
För att uppnå tredimensionell grafik så finns det ett flertal tekniker. De proprietära teknikerna har dominerat segmentet under lång tid, såsom Flash och Silverlight. Även här har standardisering börjat hinna ikapp, och WebGL standardiseras av Khronos-gruppen och tekniken implementeras i tex Google Maps.

För Jordbruksverket är det mycket intressant att se på GeoExt som är den centrala kart-komponenten i GEO-dataapplikationer. Version 3 av GeoExt kommer att vara baserad på WebGL med bakåtkompabilitet för browsers utan stöd för WebGL.


CSS3

Teknik för att lägga stil på DOM:en. Eftersom tekniken har bliv allt mer kraftfull så glider dess användningsområde ihop med andra renderingstekniker.

CSS3 transitions
CSS3 transforms

TODO: skriv något om detta.

Cache

För att uppnå en snabb och smidig applikation så är lokal cache en nödvändighet. Områdena som man läser med olika tekniker är många och beror på domänen.

TODO: skriv något om detta.


Web workers

JavaScript är körs med en tråd, dvs single threaded. För att göra tunga beräkningar i browsern så måste man kunna tråda av processer. Detta löses genom tekniken Web Workers.

http://caniuse.com/#search=web%20workers

Denna teknik har ingen koppling till Document Object Model (DOM) utan får instruktioner och data via message passing. Denna teknik har lider av att den tidigare skett genom  ”by value”. Om den skall vara effektiv så måste kommunikationen ske ”by reference”, med hjälp av sk Transferable Objects. 

Endast browser som är baserat på Webkit, exempel: Chrome >= 17, stödjer denna teknik. 

Slutsats

Chrome dominans!

TODO: skriv något om detta.

Källmaterial

HTML5







tisdag 16 oktober 2012

Law!


För flera år sedan rammade jag på ett antal artiklar om principer och lagar när det gäller UX. Inget man normalt hittar på alla dessa UX sajter. Speciellt Laq of Proximity är intressant. Får iallafall mig att inte rama in allt som tillhör en grupp utan kanske bara separera det med lite    luft    .

Law of common faith:
http://ezinearticles.com/?Gestalt:-Law-of-Common-Fate&id=146000
Law of Similarity
http://psychology.about.com/od/sensationandperception/ss/gestaltlaws_2.htm
Law of Pragnanz
http://psychology.about.com/od/sensationandperception/ss/gestaltlaws_3.htm
Law of Proximity:
http://psychology.about.com/od/sensationandperception/ss/gestaltlaws_4.htm
Law of Continuity
http://psychology.about.com/od/sensationandperception/ss/gestaltlaws_5.htm
Law of Closure
http://psychology.about.com/od/sensationandperception/ss/gestaltlaws_6.htm