Category: jsolutions

assertThat(Hamcrest).looksNice();

I väntan på David Saff’s alternative assertThat(x).y() så nöjer jag mig med:

public class EmptyMatcher extends TypeSafeMatcher<Collection < ?>> {

    @Override
    public boolean matchesSafely(Collection< ?> c) {
        return c.isEmpty();
    }

    public void describeTo(Description desc) {
        desc.appendText("empty");
    }

    @Factory
    public static lt;T> Matcher< ? super Collection> isEmpty() {
        return new EmptyMatcher();
    }
}

som gör att man kan skriva trevlig enkelt läsbar kod, t ex:

@Test
public void filteringAnEmptyListReturnsAnEmptyList() {
    List anEmptyList = new ArrayList();
    List result = testee.filter(emptyList());
    assertThat(result, isEmpty());
    // men helst: assertThat(result).isEmpty();
}

Javautvecklare sökes

Jag jobbar på Iptor Konsult AB och mer specifikt på avdelningen som går under namnet JavaSolutions. Jag trivs väldigt bra och bytte till denna arbetsgivare bara pga dess “interna politik”: lågt i tak, platt organisation, många teamaktiviteter samt kompetenta medarbetare som ger mig bra med- och mothugg i diskussioner av alla dess slag.

Vi söker fler personer som kan berika vår trupp och annonser på nätet på olika platser och jag tänkte föreviga den beskrivning som oftast kan ses, mest för att det kan vara kul att se tillbaka på om 15-20 år.

I huvudsak är beskrivningen bra: jag hade hoppat bindestrecken efter Java, flyttat Webservices från rubriken “webb” och ev lagt till något om lättviktig/rörlig/agil utvecklingsmetodik.

Skulle du som läser detta (mot förmodan – det här är mina anteckningar!) bli intresserad går det bra att höra av dig till mig eller Tomas Trolltoft t ex via mail.

Erfarna javautvecklare till Iptor

Presentation
Iptor expanderar och behöver utöka sitt team av Java-specialister. Därför söker vi dig med stor erfarenhet av Java-utveckling.

Arbetsuppgifter
Dina arbetsuppgifter anpassas efter dina egna erfarenheter.

Iptor tillhandahåller tjänster som:

– systemutveckling och arkitektur
– uppbyggnad av kundens utvecklingsmiljö
– teknisk konsultation, till exempel vid val av utvecklingsplattform
– granskning av system- och kodstruktur
– optimering av befintlig kod
– optimering av kunds utvecklingscykel
– mentorskap
– utbildning.

Utbildning/erfarenhet
För att passa in i teamet måste du brinna för Java och de möjligheter det skapar, samt ha förmåga att vidareförmedla dina kunskaper. Vanliga forum för detta är olika typer av utbildningar hos kunder.

Vi tror att du har en högskoleexamen och minst 5 års erfarenhet som Java-utvecklare. Du är van vid konsultrollen och har tidigare arbetat med några av nedanstående tekniker:

– JSE, JEE, JME
– applikationsservrar: JBoss, Glassfish, Weblogic, WebSphere m.fl.
– ramverk: JPA, Hibernate, Spring m.fl.
– utvecklingsverktyg: Eclipse, Ant, Maven m.fl.
– meddelandehantering
– webb: HTML, XML, JSP, WebServices m.fl.
– OS: Linux, Windows, Unix, iSeries m.fl.
– databaser: Oracle, DB2, MySQL, MS SQLServer.

Har du arbetat med JSF, SEAM eller testdriven utveckling är det meriterande.

Du är engagerad till din natur. Du brinner för kundnyttan i dina projekt och du har förståelse för hur man vidareutvecklar en affär.

Företagspresentation
Iptor är ett svenskt IT-konsultbolag inom IBS koncernen, med kontor i Göteborg, Stockholm och Malmö.

Sedan våren 2006 är vi till exempel arrangör av Javaforum i Göteborg, ett förtroende vi fått från SUN Microsystems där vi åtar oss att hålla kontinuerliga Javaforum med intressant innehåll. Via vår Javaportal www.JSolutions.se presenterar vi artiklar, nyheter och tankar kring systemutveckling med Java.

Vår specialitet är systemutveckling och systemintegration med Java. Vi har haft majoriteten av våra uppdrag hos större företag där vi levererat både rena produktionsplattformar, affärsstöd samt integrationslösningar. Flertalet av våra konsulter har arbetat med realtidsapplikationer där kraven på prestanda och svarstider är mycket viktiga. Vi har jobbat med de flesta hårdvaru- och mjukvaruplattformar som IBM, BEA, Oracle, Microsoft, SUN, Linux m.fl. Vi vågar säga att vi är i framkanten på Javautvecklingen i Sverige.

JDojo – TDD i fem steg

Genom mitt jobb har jag haft det stora nöjet att få hålla ett antal kodningstillfällen som “lanserats” under namnet JDojo@Gbg. Det var tack vare Emily Bache som detta kom till stånd och när hon nu seglade vidare mot Ruby-landet så har jag tagit över vid rodret och det hela har, mer eller mindre, näst intill formaliserats i en serie beprövade övningar i olika ämnen (kurspaket om 10 timmar skulle säkert någon vilja kalla det).

Det som började med en ambition om att sprida TDD och andra goda principer för “hantverksyrket” programmering snappades ganska snabbt upp på olika arbetsplatser och till dags dato har snart fem olika grupper/JDojos genomförts (med fler i uppstartningsfasen) och detta är en liten sammanfattning (reflektion/retrospektiv) av hur det sett ut hittills.

Ämnen som avhandlats

Utan omsvep så har vi under dessa JDojos avhandlat följande ämnen, med – för alla deltagare – mycket givande diskussioner.

Testdriven utveckling

Ett ämne som försvaras ganska brett (värdet av en bra testsvit) men “lärs ut” ganska smalt. Under SDC2010 i en fishbowl-debatt på temat “Should every proffessional developer practice TDD” var de flesta överens om “nja, det viktiga är en bra testsvit, men hur man kommer fram till den är inte givet” medan Michael Feathers mer var av åsikten “outside of Sweden, this is more or less concidered the solution”.

The Solution, med “test first”, red-green-refactor, etc lärs ut eller gås igenom i denna första övning.

Clean Code

Efter en introduktion till TDD och själva processen tar vi upp saker som “test backlog” och fokuserar ännu mer på refactor-steget och diskuterar (och deltagarna på något sätt enas om) definitionen av Clean Code. Ett antal best practices tas fram och även om det låter som ett tunt ämne så är diskussionerna här alltid rika, nyanserade och har beskrivits som “mycket värdefulla”.

Objektorienterad utveckling och TDD

Nästa steg i utforskandet av TDD har varit att titta på vad som händer när man tar steget från “enklare” imperativ/funktionell programmering och in i det objektorienterade landskapet. Med rätt uppgift och lagom dos moderering tyder ett mönster fram som i princip går ut på mycket fokusskifte mellan klasser. Ganska snart i retrospektiven brukar ett samtal kring kring inside-out, bottom-up och top-down dyka upp.

Mockist vs Stubborn Approach

Efter att ha känt på det dyra med att skifta fokus fram och tillbaka med TDD och OO bjuder nästa övningstillfälle på möjligheten att med hjälp av mockning (Mockito) bibehålla fokus på “en klass i taget” och i större utsträckning kunna fokusera på interaktionen, gränssnitt och enskilda klassers roller. Syftet med mockning, och när det är lämpligt att mocka, blir tydligt i jämförelse med föregående övning.

Behaviour Driven Development

Den femte övningen har antingen fokuserats mot BDD om det funnits intresse för detta. Fokus har legat på formen av GIVEN, WHEN, THEN och det somliga kallar ryska dockor och andra utifrån-in eller outside-in.

Legacy Code / befintlig kod

Ett annat efterfrågat ämne är hur man inför TDD-tänk kring kod som inte redan täcks av test, eller kanske inte är testbar (eller iaf svårtestad). Michael Feathers bok “Working Effectively with Legacy Code” demonstrerar detta på ett utomordentligt bra sätt och i denna övning har vi tagit kundens befintliga kodbas (om möjligt/lämpligt) och bearbetat den för att uppnå olika mål.

Mer (än) rubriker

Givetvis avhandlas många olika aspekter av systemutveckling parallellt, t ex Characteristics of a Good Test, Enough Tests? 3A vs BDD? Baby Steps, TDD vs Traditional Testing, …

Workshop i Eclipse som mjukstart

Vid ett par tillfällen har vi inlett med en workshop om effektiv utveckling i Eclipse. Detta har gett utvecklarna en möjlighet att känna på Dojo-ledaren, och omvänt en möjlighet att anpassa materialet efter gruppens förkunskaper och önskemål.

Formen för övningstillfällena

Vi har i huvudsak använt Eclipse, JUnit, Mockito och FitNesse. De 120 minutrarna används effektivt med en introduktion av dagens övning och ibland av det ämne man skall behandla – värdet av självinsikt får vägas in här och anpassas efter gruppen. Ca 90 minuter används till utförandet av övningen och avslutas med en en lagom kort retrospektiv där övning, erfarenheter och reflektioner tas upp och blandas friskt.

Vad är en Coding Dojo?

Dojo är namnet på lokalen där bl a olika kampsporter utövas, t ex Karate. 2005 lanserades termen “Coding Dojo” (eller Coders’ Dojo) där principen är att man upprepat utför vissa övningar, så att man genom repetition övar upp olika färdigheter/kunskaper så att när man behöver dem i “skarpt läge” kan man med lätthet kan agera på ett korrekt och säkert sätt.

Ingen föresläsningsserie – aktivt deltagande ger verkliga erfarenheter

Den Java-Dojo som Iptor nu bedrivit har visserligen fått en uppsättning övningar som vi fått efterfrågan på, och därför kunnat upprepa med mycket liknande resultat. Det är dock inget föreläsningspaket som deltagarna kan sova sig igenom – tvärtom skall varje individ sitta i “the hot spot” och parpogrammera. Praktisk erfarenhet och kunskap är mål utöver teoretisk kännedom och bekantskap.

Material

Skall försöka peta ut allt material här. Ikväller blir än så länge bara följande:
JDojo1: TDD och
Kata String Calculator

Eclipse workshop-anteckningar

Hade en liten workshop om Eclipse och detta var anteckningarna jag utgick från (och 2010-04-13 höll jag en till, och uppdaterade sedan listan).

Eclipse GUI

* Workbench, Workspace, Sets, Project, Project linking/dependencies
* Package explorer – flat vs hierarchic layout
* View – SA+Q, Window > Show View, Detached view
* Perspective: C+F8, Window > Customize Perspective
* Flera fönster / workspaces

Project

* .classpath, .project
* Attach javadoc
* Attach source
* maven eclipse:eclipse -DdownloadSources=true -DdownloadJavadoc=true

Editor

* F3 F2 (source, javadoc)
* F12
* C+M
* Link with editor
* Templates – sysout > System.out.println()
* show line numbers, show print margin vs C+L
* CS+O C+mellanslag SA+D SA+X CS+F
* New Editor [editor1|edtior2]
* SA+R
* CS+G – FilterBidResult.MATCH
* C+E, C+F6 CS+F6
* bind:a om tangenter till Ctrl+Tab – Window > Prefs > General > Keys
* Alt-<, Alt->
* Alt-v, Alt-^
* CS+T ype
* CS+R esource
* Mark occurance / highlight SA+O – visas i listen till höger om rullningslist
* Team compare, local history

Ctrl+1

* Visa: ta bort TripAction convertToProperFormat
return null;
return result; C+1
* Visa:
obj.method(); C+1
x = obj.method(); C+1
String x = obj.method(); C+1

Debug

* Breakpoints med krav
* CS+B
* F5 step into, F6 step over, F7 step out, F8 run
* C+3 Rerun
* Break på Exception, t ex AssertionError, NullPointerException

Remote Debugging

* -Xdebug –Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1234
* t ex
** websphere
http://pa-blogger.blogspot.com/2008/08/debugging-websphere-with-eclipse.html
** JBoss
** externa applikationer? mvn jetty:run

CVS

* Team compare (se allt som hänt mellan olika datum)
* Flytta root/server

History

* local vs remote
* eclipse -clean

XML Schema

* XML Catalog – installera schema för att få content assist
* Generate XML file – få exempelfil utifrån schema
* Namespaces?

Views

* Problems

** Quick fix

* Tasks

** FIXME, TODO

* Search

** next match/annotation (C+, C+.)
** history

* Servers

** Configuration

* Console

** follow output

Lite andra saker

* Aptana – för JavaScript-redigering (egentligen dynamiska språk)
* MyEclipse – plugins för koppling till BugZilla/JIRA

Varför Thread.sleep är bra

Jag har varit uppe alldeles för sent många nätter i mitt liv (min mamma kan intyga detta). På senare år har jag dock sett till att bara acceptera och utnyttja de timmar under vilka jag verkligen upplever en kreativ boost, för att sedan tvinga mig till sömns på olika sätt. Orsaken är att jag helt enkelt inte känt att jag presterat på normal nivå dagen efter.

En undersökning från 2003 bekräftar detta och sammanfattar:

Conclusions: Since chronic restriction of sleep to 6 h or less per night produced cognitive performance deficits equivalent to up to 2 nights of total sleep deprivation, it appears that even relatively moderate sleep restriction can seriously impair waking neurobehavioral functions in healthy adults. Sleepiness ratings suggest that subjects were largely unaware of these increasing cognitive deficits, which may explain why the impact of chronic sleep restriction on waking cognitive functions is often assumed to be benign.

Tips på hur man lyckas stänga av:

  • skaffa familj, eller iaf nya högre prioriterade aktiviteter
  • zenity och cron
  • shutdown -h +5

Jag tillämpar just nu zenity och cron eftersom datorn gärna får behålla mina fönster till nästa dag.

# min hour  dom mon dow   command
*/10  21    * * 0-4 /home/ceda/bin/go-to-bed.sh
*/5   22-23 * * 0-4 /home/ceda/bin/go-to-bed-late.sh
#!/bin/sh
DISPLAY=`w | egrep "ceda.*x-sess" | tr -s ' ' | cut -d ' ' -f 3`
if test -n "$DISPLAY" ; then
  /usr/bin/zenity --display $DISPLAY --info --text="Det e dags att dricka te och sova nu!"
fi

go-to-bed-late.sh ser likadan ut fast använder ett annat språk. :)

PS. zenity stödjer bara ASCII-tecken. DS