Mejsla AB – Experter på Java och mobila applikationer

Jag måste bara berätta!

Vi har nu börjat lägga upp improvisationsmusik i massor på www.clavichord.se/recordings . I skrivande stund har vi fått upp över 30 timmar med musik, och vi har enorma källor att plocka från så vi kommer att lägga upp mer och mer musik pö om pö.

Bakgrunden till detta projekt är för min del ett gammalt hobbyhack som jag började med för Musikmuseets räkning för ganska många år sedan. Det är ett Java/Spring-program som jag utvecklade tillsammans med HansErik Svensson på Musikmuseet, och syftet var att kunna analysera och jämföra olika klavikord. HansErik stod för kunskapen och idéerna, och jag hackade.

En light-version av applikationen med en liten delmängd av funktionerna gjorde vi ursprungligen tillgänglig som en webbstart-applikation på Musikmuseet webbplats. För ett par år sedan reggade vi clavichord.se och webbplatsen blev det nya hemmet för light-applikationen. Och nu har vi alltså börjat fylla webbplatsen med en massa inspelningar också.

Inspelningarna är gjorda av HansErik och det är en musiker och improvisatör i världsklass som spelar, Mikko Korhonen från Sibelius-Akademin i Finland. De har suttit på nätterna och spelat in för att minimera risken för störande bakgrundsljud.

Det finns en intressant anledning till att musiken är improviserad. Instrumenten är historiska och det finns alltså inte några inspelningar från den tiden. Så hur ska man veta hur instrumenten var tänkta att användas och låta?

Jo, dels har Mikko en gedigen kunskap om historiska klaverinstrument och tidig musik, och dels är en av Mikkos talanger att känna av individuella instrument. Förhoppningsvis speglar alltså den musik som han improviserar fram därför i hög grad det som brukade spelas på respektive instrument när det begav sig. Otroligt ballt! Som en spegel tillbaka i historien!

Och musiken är verkligen värd att lyssna på. Så ett hett tips är att surfa vidare till clavichord.se och börja ladda ner historisk musik!

Återkom sedan gärna till denna blogg och berätta vad ni tycker.

Jag hade höga förväntningar på Agila Sverige 2010. Hade hört mycket om det. Då det var första gången för mig så såg jag fram mot två härliga dagar. Jag blev inte besviken. Formatet är en höjdare. Blixttalen och Open space ger mycket information på kort tid. Inte helt otippat hinner man inte få några djupa kunskaper på 10 minuter. Men det gör inte så mycket eftersom herr Google finns där ute till förfogande om man saknar detaljerna.

Stefan Niccolai “Från Push till Pull” är ett utmärkt exempel på att man kan åstadkomma förändring ifall man ger utrymme för förändring. Det stämmer väl överens med Fredrik Fleetwoods föredrag om stress-cylindern som hindrar en från att se möjligheter. När man vill att någon ska ge en något måste man börja med att ge själv. Det gäller alla relationer, privata som i jobbet.

Dainel Brolunds idé om en guldfiskteknik “Lägg inte till mer komplexitet än vad uppgiften kräver” ger mig flashbacks om alla sköna “maskiner” som man har byggt i sina dagar. Otroligt snillrika, roliga och finurliga men dock kanske lite för komplicerade för uppgiften. Visst är det roligt, men leder det till kundnytta?

Tyvärr missade jag Niklas Lindströms presentation om Vim. Så är det med två salar och ett digert program att välja från. Något intressant får stryka på foten.

Jag var på Mobile Apps 2010 häromdagen. Flera duktiga talare med intressanta kunskaper och spaningar.

En av talarna var Fredrik Olsson som gick igenom och jämförde fyra av de stora mobila plattformarna Java ME, Symbian, Android och iPhone OS. Han snuddade bland annat vid ett ämne som vi nyligen hade en intressant dialog om på Mejsla, nämligen öppenheten hos Googles Android kontra slutenheten hos Apples iPhone. Apple har ju strikta regelverk som bl.a. förhindrar utvecklare att skriva applikationer för iPhone i t.ex. Java och Flash. I själva verket tillåts i princip bara de fyra språken Objective C, C, C++ och Javascript. Om jag har förstått det hela rätt så tillåts man inte använda något annat språk ens om man från detta genererar kod i något av de tillåtna språken.

Ur en Java-utvecklares perspektiv framstår denna slutenhet lätt som en taktik så arrogant och oförskämd att den gränsar till självmord – att utestänga så många utvecklare borde inte kunna hålla. Men ska jag sammanfatta hela konferensen i en mening så blir det ändå att Apples iPhone just nu är så överlägsen i termer av marknad att de kanske faktiskt har råd att vara så arroganta. Framtiden får väl avgöra om deras taktik håller på sikt. I mina ögon är det i vilket fall som helst en osympatisk taktik och visst önskar jag att Googles öppenhet ska löna sig på sikt.

Fredrik Olsson betonade i alla fall att man som Java-utvecklare inte ska låta sig avskräckas av Objective C. Det är inte språket som är den stora tröskeln när man ska börja utveckla för mobiler, det är allt det andra, som API:erna och anpassningen till de små enheterna. Tiden för att lära sig Objective C är en droppe i havet jämfört med den tid som det tar att bli en duktig mobilutvecklare!

Och den slutsatsen stämmer helt med det som tiden med duktiga mobilutvecklare på Mejsla har lärt mig. Mobilutveckling är i hög grad en egen värld som kräver sin egen expertkunskap.

En icke-teknisk intressant iakttagelse från konferensen var att ingen (så vitt jag märkte) bad publiken om att stänga av sina mobiltelefoner eller ringsignaler vilket ju är ganska vanligt vid konferenser, bio, etc. Det som gör detta intressant är att det ändå inte (så vitt jag märkte) ringde en enda gång under hela dagen! I efterhand kan jag bara konstatera att just den här publiken uppenbarligen inte behövde några förmananden om detta. Måste erkänna att jag är impad.

En annan icke-teknisk iakttagelse var att alla män som presenterade höll sina presentationer ensamma medan de två sessioner som hölls av kvinnor hölls av kvinnor i par. Det måste betyda något… men vad?

Min känsla är att man idag i de flesta sammanhang, på goda grunder, sätter time-to-market framför kvalitet. Men när bör motsatsen gälla? Vilka system, eller delsystem, är så kritiska att de inte får innehålla buggar? Det är självklart en gråzon, men när krävs det idag riktigt robusta och felsäkra system?

När jag pratar med jämnåriga och äldre utvecklare, aktiva utvecklare som varit i branschen under hela 90-talet, händer det ofta att frågan om kvalitet dyker upp. De flesta verkar vara eniga om att kraven på kvalitet har minskat de senaste 15 åren. Till förmån för fler funktioner, kortare cykler och snabbare leveranser.

En hypotes som jag har är att detta bland annat beror på att vi har vant oss vid buggiga system och att det därför inte riktigt lönar sig att konkurrera med kvalitet. Och att vi har vant oss har säkert många orsaker.

Några orsaker som jag kommer på är:

• Vi har blivit vana vid att webben är buggig med brustna länkar och servrar som inte alltid svarar etc.
• Öppen källkod och olika gratisprogram har fått ett stor genomslag. Jag tycker att det är helt fantastiskt på många sätt – ett mynt med en stor härlig framsida. Men myntet kanske har en baksida också – gratisprodukter kan man inte gärna klaga på. Det är det där med att “skåda given häst i munnen”. Vilket leder till låg kvalitet och bristfällig dokumentation i många gratisprogram. Vilket också har vant oss vid lägre kvalitet.
• Billigare distribution (webbappar, Java Webstart, etc.) har gjort att man kan släppa buggiga system tidigt och sedan lappa vartefter felen upptäcks av användarna. Vilket också har vant oss vid buggiga system.
• Mobiltelefonin har slagit igenom, och vi har härdats med dålig täckning och många avbrutna samtal. Fördelarna med mobiliteten har fått oss att acceptera en kvalitet som hade varit långt ifrån acceptabel när vi bara hade fast telefoni.

Och om användarna vänjer sig vid dålig kvalitet är det också svårt att konkurrera med kvalitet.
Vad kostar kvalitet? Finns det en konflikt mellan kvalitet och lättrörlighet? Eller handlar det om olika typer av kvalitet? Kräver kvalitet gedigen arkitektur? Och kräver kvalitet gedigen dokumentation? Utöver kommentarer i koden? Och utöver testprogram?

Finns det några utvecklare där ute som själva känner att de sitter i projekt där kvalitet faktiskt prioriteras framför många funktioner och snabba leveranser? Hör av er och berätta!

Trivia: Hasse Alfredssons bok med titeln “Varför är det så ont om Q?” har mig veterligen ingenting med Quality att göra. Det är en barnbok som slutar med att Q-hunden stoppar i sig alla Q eftersom bokstaven liknar en katt bakifrån.

Efter att ha haft interimslösningar under vårt första år som Mejsla har vi nu landat vår logga, fått våra nya visitkort och hittat en design för vår nya webbplats. Det är fascinerande hur lång tid det kan ta när man har lite speciella önskemål och vill ha alla med på tåget i varje steg.

Loggan är det som har tagit längst tid. Den har många intressanta egenskaper, och de kanske allra tydligaste är all inneboende symmetri och återupprepade mönster.

Notera hur cirklar och mittpunkter går igen, och hur t.ex. e:et och a:et ser likadana ut bortsett från rotation och vändning. I ett tidigt skede hade vi faktiskt ett (helt annorlunda) förslag på logga där tanken just var att själva loggan skulle innehålla de cirklar och linjer som visade hur typsnittet var frammejslat, lite i stil med den nedre bilden ovan.

Ett kanske lite ovanligt önskemål som kom fram tidigt i processen var att vi inte skulle ha någon separat logga-symbol vid sidan av texten utan att vi ville att själva texten skulle utgöra hela loggan. Det önskemålet ledde oss in på en lång resa med bl.a. utforskande av nya typsnitt.

Ett nyckelsteg var att enas om hur s:et skulle se ut. Vi fastnade för den här varianten som symboliserar ”två händer som omfamnar ett projekt”. Det blev så speciellt att vi bestämde oss för att låta s:et även vara vår symbol när inte hela texten får plats, t.ex. i vår favicon (den lilla ikon som syns intill URL:en i en webbläsare). Så lär er känna igen vårt s – det är Mejslas symbol både i och vid sidan om loggan! Och var beredda på att vi kan komma att ändra på den gröna ringen beroende på sammanhang – det går att leka mycket med det utrymmet.
Ett av de sista stegen i utvecklingen av loggan var att runda till hörnen. Titta t.ex. på den här lilla delen av loggan (en bit av e:et). Alla hörn i loggans bokstäver är avrundade på samma sätt, och trots att det knappast är något som man tänker på explicit när man ser loggan så gör det en jätteskillnad för helhetsintrycket. Från lite vasst och kantigt till mjukt och välkomnande.

Finslipningen av loggan skedde parallellt med att vi lät designa webbplatsen, och hur webbplatsen blev kan ni ju se nu.

Nästa steg blev visitkorten, och den designen är i sin tur inspirerad av webbplatsen.
Med så mycket cirklar i loggan blev det en fullträff med rundade hörn på visitkorten!

Som sagt, att få fram loggan var en lång process, och nu kan vi titta tillbaka på mängder av gamla förkastade skisser. Här är ett litet (ja, verkligen litet) urval av förkastade förslag i ett collage.