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

Rooted my HTC Desire and installed CyanogenMod

20. juli 2011 · Comments Off

Got tired of running the old Android 2.2 Froyo firmware on my HTC Desire, so I decided to root it and upgrade to a custom Android ROM.

Rooting Android

Rooted the phone using the unrevoked tool according to the steps of this article at theunlockr.com. This tool also runs on Linux. You might have to run it with sudo.

In addition to root the phone it also installs ClockworkMod Recovery which replaces the stock Android Recovery, to allow installing custom ROMs and provides some backup and restore functionality.

For me, no settings got lost in the rooting process, and I could use the phone just as normal afterwards. A rooted Android phone allows applications to run as the root user, so some applications might mess up your phone. This is required to install a custom Android system.

Remember backup

I used MyBackup to backup contacts, SMS and other settings. Used SMS Backup as a second backup for my SMS’s, which uploads the messages to my GMail account. To backup my apps I used MyBackup and Astro File Manager. Some backup applications requires a rooted phone, in that case you might backup what you can, then root the phone, and backup the rest before installing a new ROM.

Installing a custom ROM

The probably easiest way to install a custom ROM is to install the app ROM Manager from ClockworkMod. Personally I landed on CyanogenMod 7.0.3, running Android 2.3.3 Gingerbread.

The phone worked great after installing CyanogenMod, here with all the old apps back in

Factory reset is probably needed
Booting the phone after installing CyanogenMod failed, it got stuck while booting, only showing the CyanogenMod boot logo spinning forever. This might be caused by some bad settings from the stock Android that CyanogenMod didn’t like very much. Pulled the battery out and into place again, and started the phone holding back button to get to CyanogenMod Recovery boot loader, to factory reset, losing all settings and applications. The SD card is left untouched by this operatoin. Glad I backuped up the most important apps, settings, contacts and SMSes to begin with :)

Restore settings and applications

I tried to restore all the applications I previously had backed up, but applications that previously were installed on the SD card were restored to the internal storage, and failed when trying to move the app to SD card after restore. Had to uninstall those and install them once again from the Market. Application settings got lost in the process.

On most apps, it was just a matter to log in again to get back on track. I had to leave some apps after restore to keep the settings, especially apps that are not backed by online services, such as ColorNote. Uninstalling the app would erase the notes.

The good choice

So, did I like it? It’s OK. The onscreen keyboard is a little different, but now I got the æøå keys at least. Since I’m Norwegian, that makes sense I guess. There is no dictionary, but I haven’t searched Android Market for it yet, so perhaps I don’t miss it. I miss the second-click on the home button to get an overview of all the desktops, but it’s not a big deal.

Somehow all contacts in my Google Circles got lost the other night. I don’t know why, maybe because of some defect in a backup restore process or re-install of the Google+ app, or it might be a glitch at Google…

Since HTC has abandoned us Desire owners, even lay to us after promising us the 2.3 version, it was time to move on to something other. I guess I don’t need the Sense shit anymore. Now I can move Google apps to SD card, and even delete those I never used! CyanogenMod works great!

Strukturell utviklingsarkitektur

5. april 2011 · 2 Kommentarer

Programkode har ikke alltid samme struktur som kjørende kode. Det kan være dynamisk kode som blir generert, malverksfiler som kompileres, konfigurasjon som hentes inn fra flere kilder som kan overstyres under kjøring.

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.

Programkode og modulbasert arkitektur

1. mars 2011 · Comments Off

Med modulbasert arkitektur gjelder det å dele opp systemet som skal lages i moduler av håndterbar mengde kode og funksjonalitet, hvor hver modul er ekspert på sitt ansvarsområde og eksponeres til resten av systemet igjennom veldefinerte grensesnitt.

Puslespill (Puzzle). Foto: Flickr/create_joy (CC)

Utenfra fungerer en modul som en sort boks; man gir beskjeder inn og man får svar tilbake. Man vet ikke hvordan den sorte boksen kommer frem til svaret. Det gjør det enklere å forholde seg til støttefunksjoner, så man kan fokusere på den funksjonaliteten man skal lage. Jeg kaller det støttefunksjoner fordi disse funksjonene ikke er viktige; eller rettere sagt så er funksjonaliteten man arbeider med for øyeblikket mye viktigere enn en hvilken som helst annen annen modul.

Vedlikeholdbarhet

Behovet for modulbasert arkitektur oppstår når systemer blir for store til at én eller to personer kan ha oversikt over hele systemet. Da blir det viktig med vedlikeholdbare moduler av håndterbare mengder med kode.

Vedlikeholdbarhet betyr ikke at koden til stadighet må endres, noe som faktisk fungerer mot sin hensikt. Dersom modulen endres for ofte med for store endringer kan det innføre feil. Mye ny funksjonalitet kan gjøre modulen uoversiktlig og mindre vedlikeholdbar. En vedlikeholdbar modul bidrar til at resten av systemet får en tydelig måte å kommunisere med modulen på, og dersom man støter på feil så skal man klare å fikse feilen.

Eksempel på modulbasert løsning

Et svært enkelt og overordnet eksempel på en modulbasert nettbutikkløsning

Kjernen av MyWebShop kommuniserer mot eksterne komponenter over definerte grensesnitt. Det er ikke sikkert at alle komponenter har grensesnitt basert på åpne standarder, som SQL, SMTP og HTTP. Det kan være behov for å definere nye grensesnitt i bedriften. For eksempel kan kommunikasjon mot et CMS-system skje via et nytt grensesnitt vi kaller ProductService som tilbyr funksjoner som er nyttige for vår nettbutikk. På denne måten definerer vi tydelig hvilke funksjoner nettbutikken har behov for, samtidig som vi skjuler andre funksjoner som CMS-systemet tilbyr som ikke er viktige for vårt system.

Når kommunikasjon mellom moduler foregår over definerte grensesnitt, så kan moduler byttes ut med ny moduler ved behov. For eksempel kan modulen My Simple CMS byttes ut med et mer avansert og bedre CMS-system dersom nettbutikken vår blir større og får nye behov som den gamle modulen ikke kan tilby. Om den nye modulen ikke støtter det samme grensesnittet som den gamle kan man lage et veldig lite oversettingslag, kalt for et adapter, som oversetter mellom vårt eget ProductService-grensesnitt og den nye modulen.

Samhandling

Et ofte brukt tilfelle av modulbasert programvare er når data skal behandles i flere ledd. Samme grensesnitt kan brukes i front av flere forskjellige moduler. For eksempel kan et spamfilter kobles på foran e-posttjeneren slik at e-post kan filtreres før det lagres i brukerens innboks, og uønsket e-post kastes uten at brukeren ser e-posten. Fordelen med modulbasert arkitektur er klar, man får et mer oversiktlig system med komponenter som kan settes sammen og byttes ut ved behov.

KDE – are you missing Katapult?

1. mars 2011 · Comments Off

A long time ago there was a utility called Katapult, a great application launcher for KDE. I liked the auto completion of application name or website address as I typed in the letter on my keyboard. Katapult is now deprecated, no longer installed with KDE.

But there is another great application launcher for KDE, called Krunner. The shortcut is ALT+F2, and the functionality is mostly the same. I don’t miss Katapult anymore.

Funksjonell og logisk arkitektur i IT-prosjekter

7. februar 2011 · Én kommentar

Som jeg skrev i introduksjonenen til IT-arkitektur så finnes det flere innsynsvinkler til dette temaet. Hva er så mer logisk enn å starte med logisk arkitektur? Det handler om funksjonaliteten, det viktigste i et IT-system og den viktigste årsaken til at IT-prosjekter settes i gang!

Et IT-system skal løse et behov for virksomheten, eller kunden som vi kaller det. Kunden har mange behov, men man avgrenser gjerne systemet til å løse et subsett av disse behovene. Vi kaller dette for problemdomenet.

Målet med logisk arkitektur er å styrke de funksjonelle kravene, og veien til en god logisk arkitektur kan være lang. Kunden vet ikke hva det egentlige behovet er, og har ofte sin en oppfatning om hvordan løsningen skal se ut. Utviklere blir ofte veldig engasjerte og starter å lage noe de selv synes virker kult istedenfor å grave og analysere i kundens egentlige problemer.

South Park Gnomes plan

Verktøy

Det finnes flere verktøy for å analysere seg fram til en god logisk arkitektur. For å definere de funksjonelle kravene kan man skrive brukstilfeller (use cases på engelsk) som definerer hvilke brukere eller roller som skal utføre hvilke steg i en prosess for å ende opp med et ønsket resultat. Dette avdekker alternative valg som brukeren kan gjøre, for eksempel hva som skjer hvis brukeren taster en ugyldig verdi inn til systemet eller avbryter midt i prosessen. Dette dokumentet brukes for å måle om funksjonaliteten som ble avtalt er implementert og fungerer. Dette skaper en målbarhet som er viktig for at både kunde og leverandør (prosjektgruppen) skal ha felles forståelse for hva som lages og hva som er levert.

Det finnes også verktøy for å visualisere systemer, og UML er en notasjon for å visualisere systemer. Det kan visualisere brukstilfeller, flyt av data og koblinger mellom komponenter, valgmuligheter underveis i prosesser og tilstand til komponenter under gitte kriterier. Det finnes flere aspekter man kan visualiere med UML, men de nevnte er hovedsaklig de viktigste innenfor logisk arkitektur. Det handler om å modellere domenet, og komponentene navngis ofte etter begreper som brukes i virksomheten.

Domenedrevet design

En teknikk som jeg har fått sansen for er domenedrevet design (DDD), hvor fokuset rettes mot problemdomenet og det viktigste er å ha en god og dyp domenemodell på et felles språk. Dyp i at den reflekterer virksomhetens problemområde best mulig og med felles språk på tvers av programkode og de daglige funksjoner i virksomheten.

For å skape et felles språk som alle i prosjektet kjenner til og forstår betydningen av, så bør man lage en ordbok som alle gjør seg kjent med. Alle begreper fra domenemodellen bør legges inn i en slik ordbok. Ordboken skal være fri for systemtekniske begreper og skal forstås av domeneekspertene; de som kjenner virksomhetens funksjoner best.

Eksempel på domenemodell

Nedenfor vises et eksempel på en domenemodell av et bloggsystem. Det anbefales å skrive en kort tekst til figurene, da det ikke alltid er lett å forstå meningen bak en tegning. Dette er bare én av mange måter å visualisere et problem på.

Eksempel på domenemodell for en blogg

Når man får dypere forståelse av domenet lager man en ny tegning som enten erstatter en gammel tegning eller som kan supplere en eksisterende tegning. Dersom kunden fra eksempelet over også ønsker at leserne skal kunne abonnere på en strøm av blogginnlegg, så kan man lage en ny tegning som viser et søk som mates inn i en nyhetsstrømgenerator (i mangel av bedre ord).

Det finnes ingen fasit på logisk arkitektur. Alle konkurransedrevne virksomheter har særegne behov, noe de trenger for å kunne konkurrere og skille seg ut i markedet. Nettopp derfor er logisk arkitektur trolig det vanskeligste å forstå og gjennomføre innenfor IT-arkitektur.

Lykke til med neste prosjekt! Etter å ha lest dette setter du deg selvfølgelig dypere inn i kundens virksomhet og avgrenser systemets oppgaver til å løse kundens konkrete problem – ikke sant?

Hvorfor begynner man med arkitektur?

27. januar 2011 · Comments Off

IT-arkitektur er noe som stadig nevnes; at man trenger en tjenesteorientert arkitektur, en brukerorientert arkirektur, en modulbasert arkitektur, eller kanskje en dataorientert arkitektur. Eller kanskje alt på en gang. Navnelista er lang.

Om å skape orden

Arkitektur er teknikker som skal hjelpe mennesker til å forstå kompliserte systemer, som igjen skal få kompliserte systemer til å virke bedre sammen, være raske, mer feiltolerante og enkle å bruke. Resultatet skal bli et enklere system. Det strømlinjeformer enkelte prosesser av systemene og skal hjelpe til med å gjøre systemene mer vedlikeholdbare.

Det er flere måter å komme fram til en arkitektur. Jeg har selv gått i fella, flere ganger – man velger en arkitektur for tidlig i prosjektet. Det er lett å gå seg blind i arkitektur når man hører at man trenger ting som Scrum, MVC, Cloud Computing, skyen, SaaS, SOA og ESB, buzzwords brukt av selgere for å selge inn produkter og tjenester. Løsningen er å ikke låse seg til en arkitektur til å begynne med, før man egentlig vet hva man skal lage.

En arkitektur utvikler seg over tid mens man arbeider målrettet med prosjektet og målrettet jobbet mot målet med prosjektet er. Det er alltid en smartere måte å løse et problem på, man bare vet ikke om det ennå.

Evolusjon (evolution) Foto: Flickr/Esthr (CC)

Innfallsvinkler

Arkitektur finnes på flere nivåer. Man ser på arkitektur fra forskjellige innfallsvinkler. Som utvikler tenker jeg gjerne på hvordan koden er strukturert, gjerne i moduler strukturert i hver sine kataloger, på objekter med arv av abstrakte klasser og grensesnitt og hvordan kommunikasjonen mellom to systemer på nettverket skal foregå. En driftsperson tenker mer i retning av hvilke servere tjenestene skal kjøre på, i hvilke nettverkssoner, regelsett i lastbalanserer, feilhåndtering og backup. Ledelsen ønsker gjerne at utviklingsteamet skal være agile og kunne snu seg raskt ved endringer, men man ønsker også stabilitet og forutsigbarhet. En optimal arkitektur koster mye, ofte mer enn man er villig til å investere i prosjektet.

Wikipedia nevner følgende innfallsvinkler til arkitektur:

Jeg vil igjennom en serie med innlegg berøre disse arkitekturtemaene nærmere.

Dersom du bare er interessert i å lese om arkitektur kan du følge arkitekturfeeden.

Unstable video capture with DC10+ on Ubuntu 10.10

28. november 2010 · Comments Off

Some weeks ago I wrote about capturing video with an old Pinnacle DC10+ card on Ubuntu 10.10.

Since then I have had varying success capturing hours of video from both Hi8 and VHS sources. Often lavrec will exit in the middle of a recording with somewhat unknown error messages such as:


# dmesg:
DC10plus[0]: jpg_sync - timeout: codec isr=0x00

# lavrec:
Error syncing on a buffer: Timer expired

… and other nicies.

Often this happened between recordings on the tape, when stopping and starting a recording, where it often occur a lot of noise and jitter. It happened more often when recording from VHS tapes than from HI8 tapes.

I tried different values for the system configuration kernel.sched_time_avg with what looks like random improvements. The default is 1000 on a normal Ubuntu Desktop 10.10. I have tried both 100 and 250, and 250 is what I am currently using. Change it like this:


$ sudo sysctl kernel.sched_time_avg=250

I was previously using KDE while recording, but found out that several background processes like Akonadi Server was running and stealing resources. The window manager seemed slow. I guess I have an I/O issue somewhere, but I just don’t know where. Maybe the SCSI drive or maybe the graphics card which is an old ATI Radeon 8500.

I an now running Openbox with Konsole, as a command line (in an X server) is all I need to both record and watch the result with mplayer afterwards. I feel it goes a little bit smoother.

The most effect, as I figured out, was setting the quality option of lavrec a little lower. Recording with the quality set to 100 might result in unstable recording with lost frames if there is the slightest delay in the system, and eventually lavrec just exits with an error.

I tried setting the quality to 80, just to give it a try, and it was recording much more smoothly with less dropped frames. It looks like lavrec now handles jitter much better.

I am now trying out a quality of 90 which also seems good. A little lost frames now and then, but I guess that occurs mostly between recordings since I am able to record several minutes from a single scene without a single frame drop.

This is the command I use now:


$ aoss lavrec --mjpeg-buffers 512 --mjpeg-buffer-size 8192 -f q -d 1 -i p -q 90 -s -R l -U "dc10-%02d.mov"

So, my best tip to avoid lost frames and lavrec crashes is to lower the quality a little.

Video capture the old way on new Ubuntu 10.10

6. november 2010 · 3 Kommentarer

Like probably many people, I have a lot of old analog video recordings on HI-8 and VHS tape I just have forgotten to keep up to date with technology. I guess it’s time to start capturing video. Soon…

First, the camcorders charger is broken, and buying a new one is kind of difficult, but luckily, I got to borrow one from some friends.
Second, I managed to find the last working VHS player I got. A little dusty.
Third, since Mini-DV is kind of legacy as well, I decided to copy those on to my computer as well, if I ever manage to find the camcorder. Got the charger, remote and the casing, but no camcorder. Oh well…

Find the best composite or S-Video cables you can dig up, because this job you only want to do once. I got my overly priced Monster composite cables, ready to start. Soon…

Ok, so I’ve got an analog video capture card that I, in the old days, used with Windows 98 and pulled my hair out to get working on Windows 2000. The card is a Zoran based Pinnacle/Miro DC10+. That’s history. Sort of. I still got the video capture card.

What I also got is the latest Ubuntu Linux 10.10, also known as Ubuntu Maverick, which comes with the somewhat great ALSA audio support. I say somewhat because this version of Ubuntu lacks the legacy OSS compability driver in the Linux kernel. In other words it makes it harder to record or play audio from older kinds of programs, such as lavrec.

lavrec is the video and audio capture application from the MJPEG video tools package. It is the tool recommended for capturing video from the DC10+ card on Linux, but it lacks ALSA support. However, you can get a OSS wrapper program named aoss from the Ubuntu alsa-oss package which provides OSS is most cases for those old applications.

This is how I do video and audio recording, from the command line, enter something like this:


$ aoss lavrec -f a -i p -q 100 -s -R l -U dc10-out.avi

Make sure that the correct recording input line is selected for CAPTURE in alsamixer -V capture such as Line or Mic. I recommend you capture a 10 second test and check the sound.