To enable debug logging in RMI connectivity, which logs hostname and port number, set this system property:
sun.rmi.transport.proxy.logLevel=BRIEF

Can also be set runtime with System.setProperty before RMI connections are made.

Log output are printed to console, such as:

Feb 19, 2015 1:03:28 PM sun.rmi.transport.proxy.RMIMasterSocketFactory createSocket
FINE: main: host: localhost, port: 1098
Feb 19, 2015 1:03:28 PM sun.rmi.transport.proxy.RMIMasterSocketFactory createSocket
FINE: main: host: localhost, port: 4444

MIME-meldinger krever CRLF-endinger på linjene før og etter boundary-kodene og etter hver MIME-header.
I eksempelet nedenfor representeres hvert linjeskift som LF.

MIME-meldingseksempel

De steder hvor det står ^M brukes CR, som oftest rett før linjeskiftet.

--part-boundary-1^M
Content-Type: text/plain; charset=utf-8; name=litt-tekst.txt^M
Content-ID:
^M
Content-Disposition: attachment; name="litt-tekst.txt"; filename="litt-tekst.txt"^M
^M
Dette er noe tekst i en fil som heter some-text.txt
Denne fila bruker UNIX-linjeendinger, altså LF og ikke CRLF,
og det er helt i orden, siden innholdet av denne tekstfila er utenfor kontekst av MIME.

Dette er siste linje i fila^M
--part-boundary-1^M
Content-Type: image/png; name=lite-bilde.png^M
content-transfer-encoding: base64^M
^M
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAL
EwAACxMBAJqcGAAAAAd0SU1FB9wIAwwLKSOxKhgAAAAZdEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRo
IEdJTVBXgQ4XAAAAMklEQVQoz2P8z4AD/Mcuw8RAIhjGGv7/J0UDbtUMDAws+KQZGUnxAzbVuDXg
UD1SYxoAH7UJHx3uIsQAAAAASUVORK5CYII=
^M
--part-boundary-1--^M

Store og små bokstaver i navn på MIME-headere har ingen betydning.

Blokk og separatorkoder (boundary)

I denne meldingen bruker vi separatorkoden (boundary) part-boundary-1.
Separatorene i fila prefikses med --, som viser til start på en MIME Part-blokk.
En slik blokk varer fram til neste separator av samme kode.
Siste separator appendes med -- i tillegg til prefiksen, som betyr at det ikke er flere blokker.

En blokk i en multipart kan også være en multipart, men blokker under denne separeres med egen separatorkode.

Teste meldingen mot en server

For å teste opplasting med HTTP til en web servlet kan man bruke curl.
Vi lagrer multipart-meldingen på fil melding.multipart.
For at serveren skal kunne forstå multipart-meldingen må Content-Type-headeren spesifiseres som multipart/related og boundary satt til part-boundary-1.

Eksempel på kommando:

$ curl -X POST \
    -H "Content-Type: multipart/related; boundary=\"part-boundary-1\"" \
    --data-binary @melding.multipart \
    "http://localhost:8080/multipartServlet"

Forskjellige biblioteker og krav til CRLF

Det er noe forskjeller i hvordan forskjellige kodebiblioteker tolker multipart-meldinger.
Noen tillater linjeendinger med bare LF (uten CR), mens andre er strengere og krever CRLF.

Servlet 3 sin multipart-parser er streng og krever CRLF.
Samme er tilfellet med CXF sin SOAP-Attachment-parser.

Telia MMS MMSC-parser er derimot mer tilgivende.

Ansvarsfraskrivelse…

Det er ikke sikkert jeg har forstått dette 100% ennå.
Det kan være at mitt håndkoda eksempel over inneholder noen skrivefeil.
Jeg hadde Java i tankene da jeg skrev dette, og det er Java jeg har arbeidet med for behandling av MIME-meldinger da jeg forsket på feilscenariene jeg har hatt med linjeendinger.

Mer om MIME-meldinger

RFC 1341 og spesielt seksjonen 7.2 om multipart gir mer informasjon om strukturen til MIME multiparts.

CSS og Javascript er også programmeringsspråk og bør behandles således.

Kode kjører i forskjellige miljøer, enten det er på en web-server, i en virtuell maskin, en applikasjonsserver, i nettleseren eller instruksjoner som dynamisk bygges opp og sendes til eksekveringsmotorer som gjør en jobb og sender ferdig prosessert data tilbake. Det kan være preprosessorer som ved kompilering skriver om deler av programkoden.

Dette er noe å tenke på når man strukturerer opp prosjektet i kataloger og filer.

Forskjellige programmeringsspråk krever forskjellige strategier

Noe man kanskje ikke tenker så mye på mens man forsøker å konfigurere opp prosjektet til å kjøre Java-testene eller kompilere C-fila, er at en løsning ofte består av flere enn ett programmeringspråk. Om man utvikler web-løsninger er CSS og Javascript blitt en selvfølge. CSS og Javascript er programmeringsspråk og bør behandles således.

Javascript er et nesten like gammelt språk som Java, men det er først de siste årene at tradisjelle utviklere har fått øynene opp for hva som er mulig med Javascript. Desto mer man gjør i Javascript desto større er behovet for å teste funksjonaliteten. Det er fullt mulig å kjøre automatiserte enhetstester mot Javascript-kode, og det finnes verktøy for å detektere typiske feil og påpeke klassiske fallgruver. Det finnes også verktøy for å minifisere Javascript slik at filene blir mindre og legger mindre beslag på båndbredden til brukerne av systemet, og ikke minst like viktig er at det kan spare kostnader ved å senke krav til båndbredde fra systemet. Tilsvarende finnes det verktøy for CSS som minifiserer filene og som kan analysere filene og detektere ineffektive regler og duplikate regler som aldri inntreffer.

Retningslinjer

Mange programmeringsspråk har anbefalinger til hvordan programkode skal struktureres. Om systemet som skal lages hovedsaklig skal skrives i ett programmeringsspråk kan man følge dette språkets retningslinjer. I retningslinjene defineres gjerne hva en typisk fil skal inneholde, navngiving, indentering, kontrollkode, feilhåndtering, hvordan filene plasseres i en katalogstruktur og mye annet. Perl-prosjekter struktureres ofte etter CPAN sine retningslinjer, PHP-prosjekter struktureres ofte etter PEAR sine retningslinjer og Java har sine retningslinjer.

En by bygger seg ikke selv. Foto: Flickr/Science Museum London (CC)

Det har de siste årene blitt populært å bruke Maven som kontrollsystem for prosjekter, spesielt for Java-prosjekter, men kan også brukes til andre programmeringsspråk som PHP og Javascript. Man bruker gjerne Maven som en innpakking av prosjektet, til bygging av systemet, kjøre tester, pakketere og rulle ut nye versjoner. Det legger ingen føringer for hvordan man strukturerer innholdet av filer i prosjektet.

Det er ingen fasit når det kommer til struktur av prosjekter, men dersom man er flere som arbeider på samme prosjekt kan det være smart å bli enige om hvilke retningslinjer man skal følge.

Ikke all kode er programkode

Tester skal støtte oppunder løsningen og gi en god og stabil leveranse.

Den viktigste delen av løsningen er det kjørbare systemet, og det er dette som skal gi merverdi til bedriften. Dokumentasjon, tester, byggerammeverk og utviklingsmiljø er biprodukter; støttefunksjoner som skal bidra til å gi et godt og kjørende system.

Maven brukes, som nevnt ovenfor, gjerne til bygging av løsningen og til å kjøre opp web-server under utvikling, men Maven er ikke en del av det kjørbare systemet i leveransen.

Tester, som enhetstester og funksjonstester, er ikke programkode og trenger ikke behandles som det. Tester skal støtte oppunder løsningen og gi en god og stabil leveranse. Tester bør holdes utenfor katalogstrukturen til programkoden. Det kan være løsere retningslinjer til testene, for eksempel friere navngiving av tester, ingen maksimal linjelengde eller flatere katalogstruktur.

Testene dine er viktige fordet!

En god test er en verifikator om at en funksjon fungerer. En god test er presis på hva den tester og er lett å lese og forstå.

En god praksis er å navngi testene etter hva de tester. Et eksempel kan være en test som skal teste at en kunde som heter “Ola” har adresse “Drammensveien”, og denne testen kan da hete test_kunden_ola_har_adresse_drammensveien, selv om dette ikke stemmer overens med for eksempel Java’s camelcase.

En testfunksjon skal teste en ting, og kun én ting. Du trenger ikke å teste at du har korrekt brukernavn og passord i konfigurasjonen for hver eneste test du skriver. Hvis navnet på testen indikerer at en brukers adresse skal kontrolleres så skal testen gjøre det, og lite annet. Samme testen kan gjerne teste forskjellig input dersom det virker hensiktsmessig. For eksempel kan en e-postadresse-validator kontrollere flere godkjente e-postadresser, men kanskje bør det være en egen testfunksjon for verdier som skal feile valideringen.

Samhandling med andre arkitekturprinsipper

Det er mulig å kombinere struktur på utviklingsmiljøet med andre arkitekturvalg. For enkle web-løsninger er trelagsarkitekturen MVC (model-view-controller) populær, hvor man skiller applikasjonslogikk fra datamodell og presentasjon, og man kan plasserer filer i en katalog navngitt etter laget hvor de hører hjemme.

Hvis prosjektet setter domenedrevet design høyt så kan det være smart å segmentere ut filene som utgjør domenemodellene i egne kataloger, for å holde domenet samlet uten for mye støy fra annen kode.

En felles hverdag

Det er smart å ha orden i prosjektet sitt. Kildekoden til prosjektet kan sees på som skrivebordet ditt; hvis det er vanskelig å finne det du leter etter så er ikke arbeidsmiljøet optimalt. I et prosjekt med mange utviklere betyr dette at alle deler “felles skrivebord”. Å sette retningslinjer som alle i prosjektgruppen enes om å følge kan bidra til en ryddigere hverdag for alle, men retningslinjene bør ikke blir detaljerende og vanskelige å følge. Alle skal føle seg komfortable med disse.

Det er en felles hverdag. En god struktur bidrar til raskere utvikling, enklere feilsøking, og etterhvert til bedre kode med færre feil.

You can build and install that single module from the source while keeping the rest of the PHP installation intact, but the documentation of building shared PHP modules is poor.

In my case I needed the tidy extension, and here’s how to do it

 $ # extract the PHP source code and enter the directory
 $ ./configure --with-tidy=shared
 $ find . -name tidy.so

Then copy the tidy.so file to the modules directory of the PHP installation.

The important part here is the shared keyword, which is poorly documented. I had to inspect a RPM spec file to figure it out.

Med andre ord så blir tomme strenger (“”) behandlet som NULL. Dermed rapporterer MySQL med en feilmelding dersom du forsøker å sette en tom streng i et “NOT NULL”-felt. Hurra!

Heldigvis går det an å skru av kompatibilitetslagene i MDB2.

På den andre dagen, 9. september, lærte jeg litt om “Matching Engines”, om høye krav til ytelse og nøyaktighet og fikk virkelig innblikk i at tid koster penger, spesielt på nedetid.

Videre lærte jeg ikke så mye nytt om offentlige data. Synd at hele panelet utelukkende bestod av folk som ønsker fri tilgang til offentlige data, men ingen med myndighet til å kunne gjøre noe med det.

Så skulle jeg lære om hva jeg gjør feil med domenedrevet design (DDD), men foredragsholderen var forsinket, så jeg sneik meg inn på en sesjon om planlegging og å ta valg i utviklingsteam. Spesielt én ting fant jeg svært interessant, å premiere feiling for å oppmuntre til å ta sjanser og utfordre seg selv.

Videre lærte jeg hvordan man kan implementere Dungeon and Dragons i RESTful web services basert på prinsippene rundt HATEOAS, å bruke HTTP som motoren til å drive tilstand i applikasjoner.

Så lærte jeg at man må kjøpe Coherence for å bekjempe ytelsesproblemer i systemer. Et foredrag med stort preg av å selge inn Oracle-produktet, dessverre.

Så forvillet jeg meg inn på et foredrag om vedlikehold og utvikling av legacy-systemer.

Til slutt så fikk jeg med meg foredraget om domenedrevet design som ble satt opp. Greit å bli oppdatert på de mer vanskelige aspektene rundt denne teknikken, og selv om foredraget var kort så passet det egentlig bra som avslutning på JavaZone.

Nå er video av foredragene lagt ut på java.no. Har allerede sett noen lyntaler og lengre foredrag, og kan anbefale lyntalene om “97 things every programmer should know” og “Hjemmelaget er bedre enn takeout”, hvor begge lufter tanker om å kaste idéer og kode som blir for vanskelige å integrere eller som kommer i veien.

Selv så er jeg dårlig på å kaste kode, men jeg har i det siste kastet kode et par ganger, og selv om det gjør vondt der og da, så savner jeg ikke koden jeg skrev. Det er faktisk deilig å ikke ha uinnsjekket kode liggende over lengre tid.

Det jeg skal ta med videre fra JavaZone 2010 er idéene rundt HATEOAS og event drevet arkitektur. Sistnevnte har jeg allerede utforsket mye på fra før, og dette er motoren for å dytte data rundt i prosjektet jeg for tiden jobber på.

Jeg lærte i dag at hvis man plasserer en Map/Reduce-jobb hos Amazon, så tar det ca 30 ganger lenger tid å kjøre enn på en laptop.

Jeg lærte at hvis webappen din sliter under høy last mot eksterne ressurser, så legg inn sleep(1).

Jeg lærte at Collaborative Filtering kan være et spennende tiltak for å gi noe ekstra tilbake til brukerne.

Jeg lærte at det finnes mange tilnærminger til eventdrevet design.

Jeg lærte at Datalagringsdirektivet har forkjempere og motstandere som ikke alltid klarer å finne ut hvordan livets, trygghetens og frihetens vektskål skal balanseres.

Jeg lærte at RESTful ikke handler om XML og pene URL-er, men om å håndtere state mellom klient og tjener og at resten er bare hjelpemidler for å komme seg dit.

Jeg lærte at det finnes alltid et sikkerhetstiltak som man ikke har tenkt på eller ikke har forstått konsekvensene av.

Jeg lærte at Java har en tung vei å gå for å skape typeorienterte vaner.

Jeg lærte at man bør ha fulladet telefon før man drar på JavaZone.

When adding Google Maps to your Android application, make sure that the <uses -library>-tag is inside the <application>-tag of the manifest XML. This might be obvious, but I got this wrong and it took me a long time to figure out the real reason for the error.


<uses -library android:name="com.google.android.maps" />


If you have been developing mobile applications for Android you have most likely seen some exceptions in the Eclipse debugger that you don’t understand, maybe not the tiniest bit. This mostly has to do with lack of experience with the API combined with the strict way that Android sets up views and restricts which threads that are allowed to draw and control the views, along with other concurrency issues.

Starting up your application in the emulated Android environment is not the fastest thing to do, so how can you debug your applications in a little more snappier way? – In short, I really don’t know.

What I want is a sane error message with a stack trace of my application code, but since I can’t get that, I have to debug my application in other ways.

Break points
By setting a breakpoint in your code on places where you think the bug might exist, you can step through your source code until the application fails.

The cons of this are that it is time consuming to do all the manual step by step operations, it’s a boring way of debugging and the exception message you get might not be understandable to you.

Logging
The Android API provides a Log class that can be used to log messages and exceptions. It took me some time to figure out how to read the log messages, but the Android Eclipse plugin provides a LogCat view.

To show the LogCat view in Eclipse, you go to “Window”, “Show View”, “Other …”, expand the “Android” category and then open the “LogCat” view.

Example output from the LogCat view.

01-09 16:56:52.069: ERROR/Listings(1064): Failed to get trip listings
01-09 16:56:52.069: ERROR/Listings(1064): java.lang.RuntimeException: Example of exception logging
01-09 16:56:52.069: ERROR/Listings(1064):     at no.ut.trip.Listings$ProgressThread.run(Listings.java:112)

The example above shows an error message on the first line, the exception class and message on the second line, with the stack trace on the following lines. Might be helpful.

If you are going to use a field to sort on, make sure you use one of the native data types in Solr, and don’t enable any tokenizer on that data type. If you do, you might end up with HTTP 500 Internal Server Error and error log messages like this:

SEVERE: java.lang.RuntimeException: there are more terms than documents in field “title”, but it’s impossible to sort on tokenized fields

I found out that I had been using a data type with some filters and a tokenizer on a couple of fields, quite unnecessary since I don’t do any search on them. I have another field that I do search on. I only use these fields for display and sort.

Keep it simple. Use “string” for strings you don’t have to search on. If you have to do both search and sort on a field, make two fields. For example, name one of them like “title.sort”.