Tag: eclipse

Eclipse popups and focus issue

I’ve made the switch and try to live with Unity. One of the issues I’ve had is that fact that hitting Ctrl+T or Ctrl+F8 goes away if the mouse pointer is positioned where the popup window will appear. Terribly annoying.

Today I found out that it’s related to a setting in CompizConfig Settings Manager called Focus Prevention Level which is a feature intended to prevent you from continue type or click in windows that just popped up without you discovering it. Setting this to Off removes the problem with Eclipse popup focus.

Screenshot of CompizConfig Settings Manager
Changing Focus Prevention Level using CompizConfig Settings Manager

Eclipse Application & Ubuntu/Gnome

Jag har blivit vän med Unity (när det inte krashar) genom att Compiz Config (ccsm) fortfarande tillåter mig göra allt jag vill. Efter ett par månaders användande av så skall det sägas att Gnome 3 känns som en mer slimmad och snyggare upplevelse än Unity (notifications fungerar riktigt bra, gillart skarpt), men också mer låst för tweakande.

Hur som helst, efter att man dragit in sina egna versioner av saker så ser det lite roligare ut att få upp fina ikoner för programmen man kör. Jag glömmer dock alltid var man gör detta och detta är min minnesanteckning för detta. :)

fredrik@wendt-machine:~$ cat >> .local/share/applications/eclipse-jee.desktop
[Desktop Entry]
Name=Eclipse JEE
Exec=/opt/eclipse-jee/eclipse
Icon=/opt/eclipse-rcp/icon.xpm
Type=Application
Screenshot showing Eclipse Icon in application launcher
Eclipse-ikon i programstartaren

vilket_är_lättast_AttLäsaTyckerDu

Jag har skaffat mig en åsikt: det_är_lättare_att_läsa_vanlig_text_så_här, änAttLäsaDetNärDetStårSammanSkrivetUtanNågonWhiteSpace. De flesta känner till att vi mnäskionr kan lsäa ord unta srröte poerblm bara start- och slutbokstaven står på rätt plats. FrsöökGröaSmmaaSakMedDtetaTxbtelcok. Så, jag har skaffat mig åsikten att underscore är en bra idé att använda i t ex namn på test(metoder). I JavaScript brukar de flesta testramverk erbjuda följande mönster:

TestCase("Nu testar vi logiken i UserManager", {
    "lägga till en användare": function() {
        var before = this.userManger.getUserCount();
        this.userManager.addUser("Fredrik", "Wendt");
        var after = this.userManger.getUserCount();
        assertThat(after, equals(before + 1));
    }
});

Det är då ganska lätt att se vad som gått fel när en rapport säger:

In Suite "Nu testar vi logiken i UserManager", the test "lägga till en användare" failed.

I Java kan vi inte använda blanktecken som del av identifierare. I Java 7 kan man iaf använda 1_000_000 för att skriva ut en miljon, yay! Men det löser inte problemet med att få läsbara namn på test(metoderna). Understreck till räddning!

Ett problem som följer med understreck är att Eclipse rätt ur lådan inte stödjer att hoppa inom identifierare som innehåller just understreck: ctrl+höger hoppar alltså till slutet av hela identifieraren. Med AnyEditTools (finns på Eclipse Marketplace) blir detta problem ett minne blott, och man får också hjälp att konvertera mellan Camel Case och Underscores. Perfekt julklapp! :)

PyDev: Pythonutvecklingsmiljö

PythonPyDev är baserad på Eclipse, funkar väldigt bra för det jag gör, vilket i princip är att försöka jobba på samma sätt med Python-kod som med Java (TDD-ish = få ut kod i jämnt flöde och refactor för att få det fint).

Vid dagens diskussioner kring tools och miljöer på GothPyCon ][ så gjorde jag följande anteckningar (“konferensen” hölls på engelska) över features jag förväntar mig i en IDE:

  • graphical, remote debugging
  • virtual environments
  • syntax highlighting
  • unit test integration with coverage
  • auto completion
  • indentation
  • inline documentation
  • refactoring
  • easy navigation

Allt detta – förutom debugging – demonstreras i en fem-minuters demo på PyDevs hemsida, ihop med de tangentbindningar som är “speciella” för PyDev:

Shift+Alt+n
Shift+Enter
Ctrl+2, r
Shift+Alt+a
Ctrl+F9
F12
Ctrl+F11
Ctrl+Alt+l
Shift+Ctrl+Alt+m
Ctrl+Alt+↓↑
Alt+↓↑
alt+→

JsTestDriver

Most of my code writing time last week writing was spent in JavaScript land (or ECMAScript, wonder it the most commonly used name will ever change). I was to write a small templating package and had to write some new stuff and set out to use JsTestDriver and after a few minutes I was up and running in Eclipse.

The idea is OK I guess – run tests and production code in the same environment it will run in when deployed. There are a couple of cons to JsTestDriver (used through Eclipse) though:

  1. if you’re configuration file doesn’t include the test file you’re trying to execute, there’s no clue to what you’ve done wrong – the panel in Eclipse will just show the green bar and 0/0 tests run.
  2. if you have syntax (or construct like) errors in your unit under test, you’ll get the same behavior as above
  3. sometimes you’re served a cached version of (some of) the JS source files – hence there’s a button to “refresh browsers” and it’s sad that it has to be there and that you actually have to use it
  4. sometimes the engine gets into some strange state where it dryRuns the tests instead of actually executing them

Apart from that, its behavior is quite predictable. Minor issues:

  1. running a test complete locks Eclipse’s UI thread
  2. a Rerun quick command option would be great (Ctrl+3)

JsHamcrest

Another minor issue is that the “index” of JsHamcrest matchers is really hard to get an overview of. Whenever I wanted to use a certain type of matcher, it was really hard to quickly tell from the documentation if it was there or not. Go see for yourself and look for a matcher that mathes any object for instance.

JsHamcrest.Integration.JsTestDriver();
# get a list of matchers:
curl "http://jshamcrest.destaquenet.com/modules/matchers.html" | grep "dt id" |cut -d '"' -f 2 |cut -d '.' -f 3

JsMockito

JsMockito works really nice. The only thing that could’ve been better is the integration with JsTestDriver: when a verify step fails, you’ll get a good error message but you don’t get the typical feedback as from which line the verify/assert that failed was on. Not a big deal since you see which test that failed.

JsMockito.Integration.JsTestDriver();

apache, svn, mysql för prov

Idag skriver ett par elever omprov i kursen Avancerade Webbteknologier 1 i Agile Web Developer-programmet på kyh.se (yrkeshögskola). Deras prov består av två delar: en pappersdel och en “praktisk” del.

Den praktiska delen presenterar ett antal handritade skisser över en webbplats. I det första provet skulle de göra en enkel version av twitter. I detta prov ett enkelt forum. All hjälpmedel är tillåtna och poängen är att det skall vara likt en riktig arbetssituation. Studenten kan då visa vad han eller hon faktiskt kan åstadkomma på en viss tid, visa upp på kod han/hon väljer att checka in och visa prov på färdighet. Pappersdelen visar mest på nivå av kunskap – inte den hantverksmässiga färdighet man som utvecklare faktiskt bygger upp.

Hur funkar det då?

Förra gången uppstod konstiga fel för en del av de som satt på Windows och körde Eclipse med Subclipse. Problemet visade sig vara att de som inte köra “pure Java”-versionen, aka SVNKit, utan istället köra native-bryggan inte alls kunde interagera med svn-repot. Detta hade tidigare inte varit något problem under kursen, men då var alla läsoperationer tillåtna för hela världen (anonymous access) och endast skrivning krävde inloggningsuppgifter.

“Svn-repot” är egentligen flera repon – ett repo per student. De är skyddade så att bara ett konto kan komma åt just det repot, både vad gäller läs och skriv (och alla andra operationer). Repot accessas via HTTP och Apache via mod_authz_svn / mod_dav_svn (man får akta sig så att dav_svn.conf som medföljer vid installation inte används med default-inställningar).

Så, jag satte ihop ett par skript (bash och python) som

  • skapar svn-repo med branches, tags och trunk-kataloger (om det inte redan fanns),
  • skapar htpasswd-fil,
  • skapar apache-config-fil, samt
  • skapar MySQL-databas (en per person) och populerar med lite grunddata.

Konfiguration av Apache

Hela webbplatsen kör på en egen virtual host och konfigurationen för detta ligger i en enda fil. För varje student genereras följande:

<Location /live/carw949>
 AuthType Basic
 AuthName "Live - carw949"
 AuthUserFile /srv/prov/live/carw949.htpasswd
 Require valid-user
 Order allow,deny
 Allow from all
</Location>
<Location /svn/carw949>
 DAV svn
 SVNPath /srv/prov/svn/carw949
 AuthType Basic
 AuthName "AD10Gbg carw949"
 AuthUserFile /srv/prov/live/carw949.htpasswd
 Require valid-user
</Location>

Utöver det kör jag också ett cronjobb som checkar ut deras kod var tredje minut och lägger upp “live”. (Även denna “live”-katalog är skyddad och access ges bara till ett enda konto.)

Konfiguration av Subclipse och Eclipse

Idag fungerar det fint utan problem  för alla. Det gäller dock att man i Eclipse (med Subclipse-plugin) väljer att använda SVNKit istället för JavaHL (JNA). Installeras enklast via Help » Install New Software och med arkivet som finns på http://subclipse.tigris.org/update_1.6.x. För att kontrollera vilket SVN-lib (eller backend) som används så är vägen denna:

Window » Preferences
Team » Svn
Svn Interface » Client: SVNKit (Pure Java)

Alla skript ligger under http://wendt.se/software/education/kyh.se/awt1/ och do-it-all.sh gör “allt”. Filen elever.txt innehöll alla elever och var på det format som jag fick rått från SCAS (administrativt system).

Eclipse och TDD

Eclipse är ganska svagt utrustat från start för att köra TDD effektivt. Det verkar inte komma ifrån att code completion måste utföras med CTRL+mellanslag – här kommer IntelliJ för alltid lysa med sin vackerhet (där mellanslag eller tab är “markören” som kollar om den skall auto-complete:a).

Favorites

Följande klasser är bra att peta in i varje workspace Window » Preferences » Java » Editor » Content Assistant » Favorites:

  • java.util.Arrays.*
  • java.util.Collections.*
  • org.junit.Assert.*
  • org.mockito.BDDMockito.*
  • org.mockito.Matchers.*
  • org.mockito.Mockito.*
  • org.mockito.MockitoAnnotations.*

Templates

Börja med att ta bort  alla SWT, ta bort test för JUnit 3.

WORK IN PROGRESS!

before

${staticImport:importStatic('org.mockito.MockitoAnnotations.initMocks')}
@${beforeAnnotation:newType(org.junit.Before)}
public void ${setup}() throws Exception {
  initMocks(this);
  testee = new ${cursor};
}

Det är givetvis trevligare med @RunWith(MockitoJUnitRunner.class). MoreUnit kan hjälpa till med att sätta upp detta.

mock

@Mock private ${type} ${mock};

bdd – BDD-ish Test

@Test public void statement() throws Exception {
    given(${mock}.${method}).willReturn(${value});

    // WHEN ${when}
    ${testee}.${act};

    // THEN ${then}
    verify(${mock}).${method}(${arguments});
}

tdd – TDD test

@Test public void statement() throws Exception {
    // Arrange
    // Act
    // Assert
}