Alt om ingenting og litt i mellom En blogg av Knut-Olav

Android OS – mer enn bare gratis

3. juni 2010 · Comments Off

Terskelen for å lage applikasjoner som fungerer sømløst med operativsystemet og med andre applikasjoner over felles grensesnitt er et veldig viktig argument for å velge Android.

Steve Guggenheimer i Microsoft tar frem “gratis” som argument for at mange hopper på Android-bølgen med tablets, tilsvarende da netbooks kom på markedet med Linux-operativsystemer, men Android har noe som ikke Linux på netbooks hadde, og det er Market – tilgjengelighet.

Liten ryddesjau på hytta

23. mai 2010 · Comments Off

I bortimot 10 år har det ligget masse skrot i kommodeskuffene på soverommet mitt på hytta. Jeg kastet ut kommoden i fjor, noe som la igjen en passelig haug på gulvet med alt mulig tull.

Jeg gikk etter hvert lei av å måtte snike meg rundt alt skrotet, så jeg satte meg ned for å se hva som kunne kastes.


Jeg fant en huskelapp fra mine første dager som datanerd, med kommandoer for å flytte, kopiere og slette filer fra DOS kommandolinja, samt andre kjekke ting som å endre kommandoprompten – søppel.

Videre fant jeg en stor samling batterier hvor syra var godt på vei ut på mange av dem. Uansett så lite nyttig det er å vite, så var det litt interessant å se at det kun var Duracell-batteriene som syra hadde gått på – søppel.

Fant også noen Lego-deler, mye av det var knekte deler, ikke så rart jeg hadde stasja det i skuffen i første omgang – søppel.


Da jeg var liten brukte jeg og en kamerat mye tid på å flettet jeg sammen hyssinger og rulle det sammen til en ball. Om ballen på bildet er eneste jeg lagde er usikkert, men jeg har en anelse om at jeg ikke brukte så mye tid på dette allikevel – søppel.

Mange minner. Det ble en bærepose full med søppel denne gang.

Toshiba Camileo S10 ustabil i kulda

7. februar 2010 · Comments Off

Etter en ukes skitur til Østerrike, Bad Gastein, fikk mitt nye full-HD lommekamera prøve seg. Kameraet er av type Toshiba Camileo S10, et full-HD videokamera som passer fint ned i lomma.

Enkelte dager var det ned mot 19 minusgrader i bakkene og det taklet ikke kameraet. Under opptak i 1080p låste kameraet seg gjentatte ganger, fra bare noen sekunder til et halvt minutt med opptak, avhengig av dagens vær. Eneste løsning var å nappe ut batteriet og sette det inn igjen. Irriterende nok er det ikke eget batteri for klokka, så denne blir tilbakestilt.

For å i det hele tatt kunne filme noe i 1080p utendørs på ski måtte jeg filme korte klipp på 10-15 sekunder og vente litt mellom hvert opptak. Kameraet oppbevarte jeg i en snor rundt halsen på innsiden av skijakka.

Jeg mistenker at problemet ligger i minnebrikka, at kameraet ikke klarer å lagre unna raskt nok all den data som full-HD opptak krever. Da jeg stilte oppløsningen til 720p gikk det betraktelig bedre. Allikevel mistet jeg ett minutts opptak med denne innstillingen også, dette i pent og varmt vær, men med noe snø i lufta. Mitt tips er derfor å stoppe og starte opptaket ofte.

Minnebrikken jeg brukte var av type SDHC Class 4 på 4 GB fra Verbatim. Noen som kan anbefale en bedre og raskere minnebrikke?

VGnett gjorde en liten test av kameraet da det kom på markedet.

Kameraet skal garantert være med på flere skiturer, da det er lite, starter opp og er klar til bruk veldig raskt og tar flott video og flotte bilder utendørs, så lenge elektronikken holder seg i gang da…

Debugging your Android application

9. januar 2010 · Comments Off

I am novice on Android application development, slowly starting to understand the architecture. I particularly like that communication between applications and data storage are resource centric. But anyway…

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.

Don’t sort on tokenized strings in Solr

15. desember 2009 · Én kommentar

Apache Solr is a very powerful index and search engine. Unfortunately it does have some flaws, at least I think this issue is somehow not “by design”.

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”.

Cowboy coding

9. desember 2009 · Én kommentar

Cowboy coding seems interesting, and it might be just that I have been doing when developing Madcow, a PHP web framework.

However, it is not the same as Scrum. Many projects tend to fail using the Scrum methodology, possibly because of the lack of clearly defined roles, and then fall back to something looking like Cowboy Coding.

Unfortunately, it seems that the project I am currently working on at work is exactly that, Cowboy Coding, not Scrum…

Fortsetter jakten på MySQL-features

5. november 2009 · Comments Off

I dag kom jeg over noe merkelige greier i MySQL.

I en SELECT-spørring hvor jeg bruker WHERE for å søke etter strenger, så betyr det ingenting om jeg spør mot en tom streng eller masse mellomrom.

Jeg har en tabell som heter “texts” med kolonnene “uuid”, “name” og “content”. Feltet “content” er av type TEXT fordi jeg har behov for å lagre et ukjent antall tegn med tekst her.


+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| uuid         | varchar(36)  | NO   | PRI |         |       |
| name         | varchar(16)  | NO   |     |         |       |
| content      | text         | NO   |     |         |       |
+--------------+--------------+------+-----+---------+-------+

Først testet jeg med en tom streng:


mysql> SELECT uuid,name,content FROM texts \
    -> WHERE content = "";
+--------------------------------------+-------------+---------+
| uuid                                 | name        | content |
+--------------------------------------+-------------+---------+
| 1b74168e-5b91-4c27-b1eb-257d6d0cee18 | description |         |
| 963c7f0a-e0dc-45e5-af5b-a803dee3a743 | arrival     |         |
| a7bf022e-fc95-4410-bd6e-e92b64f12db4 | regulation  |         |
| ebffc5bb-b3f8-473d-8f34-a5041f73987c | sanitation  |         |
+--------------------------------------+-------------+---------+
4 rows in set (0.00 sec)

Deretter forsøkte jeg bare for moro skyld å søke etter tre mellomrom:


mysql> SELECT uuid,name,content FROM texts \
    -> WHERE content = "   ";
+--------------------------------------+-------------+---------+
| uuid                                 | name        | content |
+--------------------------------------+-------------+---------+
| 1b74168e-5b91-4c27-b1eb-257d6d0cee18 | description |         |
| 963c7f0a-e0dc-45e5-af5b-a803dee3a743 | arrival     |         |
| a7bf022e-fc95-4410-bd6e-e92b64f12db4 | regulation  |         |
| ebffc5bb-b3f8-473d-8f34-a5041f73987c | sanitation  |         |
+--------------------------------------+-------------+---------+
4 rows in set (0.00 sec)

Men for all del da? Dette er jo samme resultatet som ovenfor.

Eller hva med denne spørringen? Jeg kan ikke skjønne hvorfor det er slik. En tom streng er ikke det samme som tre spacer!


mysql> SELECT uuid,name,content FROM texts \
    -> WHERE content = "   " AND content = "";
+--------------------------------------+-------------+---------+
| uuid                                 | name        | content |
+--------------------------------------+-------------+---------+
| 1b74168e-5b91-4c27-b1eb-257d6d0cee18 | description |         |
| 963c7f0a-e0dc-45e5-af5b-a803dee3a743 | arrival     |         |
| a7bf022e-fc95-4410-bd6e-e92b64f12db4 | regulation  |         |
| ebffc5bb-b3f8-473d-8f34-a5041f73987c | sanitation  |         |
+--------------------------------------+-------------+---------+
4 rows in set (0.00 sec)

Hvorfor i alle dager gjør MySQL dette her mot meg?

Én teori jeg har er at MySQL skal hjelpe meg som en dum utvikler i å returnere det korrekte svaret selv om jeg skulle skrevet inn et mellomrom for mye i søkefeltet mitt. Akkurat i samme stil som de andre gangene MySQL har vært så hjelpsom mot meg

Startet alpinsesongen på Gaustablikk

25. oktober 2009 · Comments Off

Lørdag dro jeg og tre kamerater til Gautablikk for å prøve ut snowboard og ski før vinterens store skiferie til Bad Gastein.


Gaustablikk har nå én åpen bakke, med t-krokheis. Det er ikke store greiene, men nok til å få oss opp av senga kl 7 om morgenen på en lørdag. Jeg forstår fremdeles ikke hvordan det gikk til…


Det var overskyet og lavt lys og det kom noe snø. Legg også merke til snøskillet på fjellene rundt dalen på bildet over.

Bakken var stort sett i fin form, men snøklumper og ujevn preparering gjorde det krevende å kjøre. Allikevel var det bedre forhold enn forventet, eller fryktet.

For å bevist at man har vært et sted, så tar man et bilde. Vi måtte dokumentere at vi var på Gaustablikk denne dagen.

Vi følte også for å dokumentere at bilder ble tatt…

Gjenopprett filer med TestDisk

15. oktober 2009 · Én kommentar

En kollega på jobben hadde filmet noen korte videoklipp og disse var lagret på et Compact Flash-kort. Dessverre fikk hun bare “read error”-meldinger da hun prøvde å hente ut videoklippene, både på sin laptop og direkte fra kameraet.

Illustrasjonsfoto: Canon Compact Flash Card av Simon Clayson, Creative Commons

Jeg ga Linux-maskinen min et forsøk. Ved første øyekast så det mørkt ut og jeg fikk mange stygge feilmeldinger i dmesg-loggen. “fdisk -l” viste meg ingen partisjoner på minnekortet.

Jeg prøvde å ta ut og sette inn kortet igjen, bare for å sjekke en gang til. Denne gangen gikk det mye bedre.

Først tok jeg en kopi av minnekortet til en fil med verktøyet dd. Dette er viktig å gjøre hvis man har med ustabilt medium å gjøre for å ikke slite unødvendig på minnekortet eller risikere å slette noe.


$ sudo dd if=/dev/sdb of=/tmp/sdb.dd

Deretter lastet jeg ned programmet TestDisk fra CGSecurity. Dette er et gjenopprettingsverktøy som jeg ikke har brukt tidligere. Det dukket opp i flere søkeresultater på Google, så jeg ga det en sjanse. Og jeg kommer garantert til å bruke det ved liknende anledninger senere.

Jeg startet testdisk med “/list”-opsjonen mot kopien jeg lagde av minnekortet, for å se om verktøyet fant noe nyttig om disken.


$ sudo testdisk /list sdb.dd
TestDisk 6.10, Data Recovery Utility, July 2008
Christophe GRENIER 

http://www.cgsecurity.org

Please wait...
Disk sdb.dd - 256 MB / 245 MiB - CHS 32 255 63, sector size=512

Disk sdb.dd - 256 MB / 245 MiB - CHS 32 255 63
    Partition                  Start        End    Size in sectors

Partition sector doesn't have the endmark 0xAA55

Dette lovet ikke bra. Jeg forsøkte så å starte opp testdisk uten list-opsjonen og ble så presentert med en meny for å velge disk søke etter partisjoner, samt noen valg.

Jeg forsøkte flere av valgene, blant annet at disken var opprettet på et i386-system, men da fant den ingen partisjoner. Siden dette minnekortet har stått i et kompaktkamera var det sikkert ikke opprettet noen partisjoner på kortet, så jeg forsøkte det valget i stedet.

Det viste seg at det ikke var noen partisjoner på kortet. Filsystemet, som var vfat, var skrevet rett på minnekortet. Programmet viste meg en filbrowser og jeg kunne navigere rundt og kopiere ut filer.

Det ga meg også mulighet til å kopiere ut filer som tidligere hadde vært slettet. Jeg forsøkte å hente ut to bilder, for å teste dette. Det ene bildet var korrupt, trolig skrevet over etter at det var slettet, mens det andre bildet kunne vises uten problemer.

Må si at dette verktøyet var en stor suksess!

MySQL på nye fremmednøkkeleventyr

13. oktober 2009 · Comments Off

Ikke så lenge siden skrev jeg om MySQL sine problemer med datatyper og NULL-konstraints. Og problemene stopper ikke der.

Jeg kom i dag over en merkelig og helt uforståelig bug i MySQL. Eller, det heter vel kanskje feature når det gjelder MySQL.

Ta følgende scenario: En kolonne “disabled_reason_ref” i tabellen “countries” refererer til feltet “uuid” i tabellen “texts”. Kolonnen “disabled_reason_ref” er definert med mindre størrelse enn feltet den refererer til. Dette visste jeg ikke om. Begge tabellene bruker InnoDB og det er satt opp fremmednøkler. Hvordan dette gir noe som helst mening i MySQL-verden vet jeg ikke.

Ihvertfall. Det hele startet med denne SQL INSERT-spørringen.


mysql> INSERT INTO countries (uuid, country_code, disabled, disabled_reason_ref, page_ref) VALUES ("a63d5a26-9719-47dd-9617-c07bd8126061", "NO", 1, "e80c8d7c-dd84-4a4f-8df4-778efe9b311a", NULL);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`utenlandsbolig/countries`, CONSTRAINT `countries_ibfk_2` FOREIGN KEY (`disabled_reason_ref`) REFERENCES `texts` (`uuid`))

Det er ingenting i feilmeldingen fra denne spørringen som sier noe om det.

Jeg lurte litt på om kolonnenavnet var for langt, så jeg lagde en ny kolonne som heter “reason_ref”.


mysql> alter table countries add column  reason_ref VARCHAR(32)  REFERENCES texts(uuid);
Query OK, 1 row affected (0.52 sec)
Records: 1  Duplicates: 0  Warnings: 0

MySQL satte riktignok ikke opp noen fremmednøkkel her, noe jeg sjekket med “SHOW CREATE TABLE countries”.
Lurer da fælt på hva den i så fall referer til…
Vel, MySQL er MySQL.

Jeg tenkte så at jeg ikke trengte “disabled_reason_ref” lenger.


mysql> alter table countries drop column disabled_reason_ref;
ERROR 1025 (HY000): Error on rename of './utenlandsbolig/#sql-4fa3_6' to './utenlandsbolig/countries' (errno: 150)

Hva i alle dager betyr dette?
Jeg kom meg ikke rundt feilen, så jeg lot kolonnen bare ligge.

Jeg hadde på dette tidspunktet ikke oppdaget at “reason_ref” var for liten. Kolonnen den refererer til er nemlig av type VARCHAR(36).

Et nytt forsøk på INSERT, nå ved å bruke den nye kolonnen.


mysql> INSERT INTO countries (uuid, country_code, disabled, reason_ref, page_ref) VALUES ("a63d5a26-9719-47dd-9617-c07bd8126061", "NO", 1, "e80c8d7c-dd84-4a4f-8df4-778efe9b311a", NULL);
Query OK, 1 row affected, 1 warning (0.19 sec)

mysql> show warnings;
+---------+------+-------------------------------------------------+
| Level   | Code | Message                                         |
+---------+------+-------------------------------------------------+
| Warning | 1265 | Data truncated for column 'reason_ref' at row 1 |
+---------+------+-------------------------------------------------+
1 row in set (0.00 sec)

Og det viste seg at kolonnen var for liten. Dermed fant den ingen rad i “texts”-tabellen som hadde den refererte verdien på 32 tegn, da verdien egentlig skulle vært på 36 tegn.


mysql> alter table countries modify column disabled_reason_ref varchar(36);
Query OK, 2 rows affected (0.40 sec)
Records: 2  Duplicates: 0  Warnings: 0

Greit at det var jeg som gjorde feilen med å deklarere kolonnen for liten.
Men hallooo, litt hjelp kan man vel få fra en database? Spesielt fra en relasjonsdatabase!

Dumme MySQL!