Archive for category Kära dagbok
Santa was here… with books!
Posted by alexander in Kära dagbok on November 7, 2012
I haven’t had time to do techbookreader for a long time. At present, I don’t even have time to write a proper blog post.
BUT. I got this today!
books
Here’s why I bought these particular books. There’s reason behind the madness 
Agile Software Development – Principles, Patterns, and Practices: A classic by Uncle Bob. I should have read it a long time ago.
Patterns of Enterprise Application Architecture: I feel bad about not having read this one. Really bad.
Ship it – A Practical Guide to Successful Software Projects: The Continuous Delivery book keeps referring to this one. Let’s see what it’s about…
Exploratory Software Testing – Tips, tricks, tours, and techniques to guide test design: I should know more about exploratory testing.
How to Break Web Software – Functional and Security Testing of Web Applications and Web Services: I know nothing about this book, but I feel I should be better at web testing.
JUnit in Action – Second Edition: First edition was quite ok.
Testing Computer Software: I liked Cem Kaner’s writing in another book.
Perfect Software – And other Illusions about Testing: Gerald M. Weinberg. No explanation needed.
Geekar hårdvara
Posted by alexander in Geekande, Kära dagbok on September 30, 2012
En gång var femte år får jag ett infall. Jag försöker bevisa för mig själv att jag kan geeka med hårdvara. Resultatet brukar vara sådär, och kontot går 500-1000 spänn back. Jaja… Människan är inte en rationell varelse.
Förra omgången körde jag stenhårt på PIC 16F84A med en seriell Velleman-programmerare. Försökte få liv i en servokontroller, men det gick inte. 16F84:an programmeras i Assembler, och man våndas varje gång, men samtidigt känner man sig duktig eftersom man programmerar i Assembler.
Denna gång triggades mitt infall av en födelsedagspresent. Jag fick en Arduino Uno. Den här gången bestämde jag mig för att det är en materialsport, så jag köpte på mig det jag inte hade. Resultatet ses nedan:
Sedan kom jag på att jag faktiskt inte kan löda, men det åtgärdades lätt med Youtube. Tre tutorials senare kände jag mig mogen att försöka på allvar. Denna gång hade jag också klämmor. Jag lödde ihop en liten “buss” till Arduinon och ville egentligen löda mer, men hade inget mer att löda.
Efter en del grejande fick jag också igång min servokontroller jag köpte för type fem år sen. Om man kopplar in saker på rätt pinnar, så blir det enklare. Det jag hade fått ihop vid det här laget var en Arduino som pratade seriell kommunikation med en Pololu Micro Serial Servo Controller.
Resultatet ses i denna film.
Det finns en massa tutorials på nätet för hur man sätter ihop allting, men jag presenterar gärna “lessons learned”:
- En kabelskalare är värd sin vikt i guld
- Grundläggande lödning är inte svårt, men man måste ha grejerna
- Det lilla servot på bilden pajade direkt. Dålig produkt, eller dålig koppling?
- Man borde läsa lite mer grundläggande elektronik. Digitaldelen är enkel, men man måste göra magi med kondensatorer, spänningsregulatorer, pull-up/down-motstånd m m.
I samband med detta övergav jag helt mina PIC 16F84-ambitioner. Det visade sig att ingen av mina datorer ville prata seriell kommunikation med en gammal programmeringsbräda. Det är en materialsport, så till nästa gång kommer jag köpa en USB-baserad programmerare, samt köra på processorer som kan programmeras i C.
Writeup JFokus 2012 – Tutorialdagen
Idag var jag på JFokus tutorialdag. Två sessioner på ca tre timmar vardera. Jag valde Continuous Delivery med Neal Ford och HTML 5 med Robert Nyman.
Continuous Delivery
Ska man sammanfatta den första sessionen med en mening, så kan man säga att den troget följde boken med samma namn (som jag kommer att recensera på techbookreader i dagarna). Det jag saknade i boken blev inte förtydligat under presentationen, men jag kunde ställa mina frågor till Neal efteråt, så det löste sig. Jag undrade hur man får till static, pinned, och fluid dependencies på riktigt och hur man ska förhålla sig till databasdeltan och branchning. (Svaren är: använd Maven, skriv automagiskt om POM:en vid misslyckat bygge, respektive ”gör det inte”.)
Som sagt, inget supernytt för den som har läst boken och fått jobba med liknande saker, men några takeaways blev det:
CD handlar om att teamat måste kontrollera mer av sin omgivning. Infrastruktur och databaser kan inte längre kontrolleras av andra. Kanske uppenbart, men ganska axiomatiskt. Detta gäller även ”the last mile”, d v s slutintegration, utrullning, Q/A. Nu måste man ta hand om allt. Stackars de utvecklare som bara vill koda…
Komponenter: Om man inför komponenter på rätt ställen kan man göra om arkitekturförändringar till design.
Bra nyckeltal:
- “Hur lång tid tar det att få ut en rad kod i produktion” (Mary Poppendieck)
- Ledtid är måttet på IT:s effektivitet (tämligen självklart, men jag gillar absoluta utsagor formulerade som korta meningar)
Sköna citat:
- Om drift: “We invented computers to do simple repetitive tasks. Now we hire people to do simple repetitive tasks on computers”
- Merge ambush = Man får en massa förändringar från trunken, så att ens bygge förstörs totalt. Påträffas typiskt vid branchning när en annan branch ”har vunnit”.
Jag måste läsa:
- The Four Steps to the Epiphany: Successful Strategies for Products that Win
- Release It!: Design and Deploy Production-Ready Software
- Neals gratisartiklar på devloperWorks. Sök på “emergent design”.
Mjukvara att testa:
Tal att se:
HTML 5
Mekanisk presentation, där mycket HTML 5 visades. För en newbie som jag var det bra. Jag tyckte själva presentationen spretade. Första delen handlade om semantiska element, andra om forms och tredje om API:erna, men den röda tråden inom varje block var inte självklar. Baserat på denna presentation och några enstaka från andra konferenser drar jag slutsatsen att HTML 5 har en bit kvar. Jag kan givetvis ha fel, men detta är inte mitt fokusområde.
För det första verkar åter igen browser-tillverkarna göra lite som de vill. Gillar de inte en viss del av standarden, så struntar de i den (Microsoft om keygen-taggen [förresten, varför ska man ha en tagg för att generera nycklar???]), och vissa lägger till egna klasser eller tolkningar för att fylla ut gap, och hoppas att andra ska följa efter. Känner vi igen detta?
Form-elementet har blivit rejält pimpat i HTML 5! Mer input-element, t ex color, range, datetime, o s v och funktioner för validering, MEN utvecklingen av dessa är eftersatt, eftersom browser-tillverkarna tycker att prestanda och 3D är viktigare. Implementationen spretar alltså mellan olika browsers, och man måste fortfarande använda otippade JavaScript-lösningar på ställen där man helst hade sluppit.
Sen har vi allt det där med Web Sockets, Web Workers och local storage. Jag tolkar det som att man bokstavligt talat försöker uppfinna opertivsystemet: IPC, trådning och permanent minne. Kalla mig konservativ, men jag känner en viss oro. Det mest talande exemplet är Web Sockets. Jag vet inte mycket om dem alls, men tittar man på deras API, så verkar det vilja mimikera get gamla hederliga socket-API:t från UNIX. Jag kan tänka mig att det finns ett antal utvecklare som aldrig har arbetat med C under UNIX och detta API, och de förstår inte hur bra det är att det har abstraherats bort de senaste 10 åren. Nu ”uppfinner” man det i HTML 5 och JavaScript. Det är inte självklart att resultatet blir bra. Samma sak med trådning. Man har uppfunnit trådar i webbläsaren, medan resten av världen har börjat bygga abstraktioner runt trådar, eftersom trådning är svårt, eller programmera med funktionella språk. Lång rant.
Summa summarum, så lärde man sig mycket i alla fall.
Andra takeaways i punktform:
- HTML 5 Doctor verkar vara en bra site att kolla in om man ska greja med HTML 5.
- Man kan skapa egna attribut i HTML 5, så länge de börjar med ”data”. Kolla t ex här.
- Vid.ly är en skön site om man behöver koda om lite video till olika format
- Popcorn.js: gulligt ramverk för att lägga på sidocontent samtidigt som ett videoklipp spelas.
DevCon 11 writeup
Gör en sån där liten sammanfattning av ett event jag har varit på. Denna gång var handlar det om DevCon 11, som hölls i Karlskrona. Konferensen varade två dagar och var av det mindre slaget, kring 100+ deltagare. Jag måste dock säga att det var en av de bästa konferenser jag varit på! Storleken gjorde att man verkligen fick tid att prata med folk, lära känna nya människor och utbyta idéer och erfarenheter, till skillnad mot att trängas med 1000+ personer, köa till toaletten och slåss om fikat.
Konferensen hade två spår ”Software Craftsmanship” och ”Technology”. Det som ingick i respektive spår var lite slumpmässigt, men det gjorde ingenting. Arrangörerna hade verkligen lyckats få dit bra talare och fick till en bra spridning på ämnena.
Ur en talares synpunkt fungerade allting väldigt väl. Tekniken funkade, bra volym på micken, bra moderering och tidhållning. Alla skötte sig med tiden också J
Själv fick jag jättemycket behållning av dessa två dagar. Inte nog med att jag träffade väldigt många riktigt duktiga personer; jag såg till att pricka in ämnen som jag inte kunde så bra, så marginalinlärningen blev hög.
De föreläsningar jag av olika skäl fick mest behållning av var:
- Keynoten av Joakim Jardenberg. Inspirerande och lite skrämmande för en som inte är med i Facebook.
- Managing complex projects with Maven 3, Lennart Jörelid
- Exploratory test design, Rikard Edengren
- Clojure – Data Structures and Concurrency Mechanisms, Ulrik Sandberg (via en komprimerad privatsession, eftersom vi talade samtidigt. Tack!)
- Bägge av David Jacobys säkerhetsföreläsningar
- OSGi – 10 years ahead if their time, Christer Larsson
- Asynchronous Programming with Node.js, Anders Janmyr
- Is your REST Assured, Johan Haleby.
Alla andra föreläsningar, som jag var på, var också mycket bra, men jag kunde ämnet, så de tjänade mer som kvitton.
Sammanfattningsvis kan jag konstatera att jag fyllde på med introföreläsningar i teknologier jag inte kan så bra: Node.js, Clojure, OSGi.
Den stora ögonöppnaren var nog ändå att jag började förstå vad polyglot-programmeringen går ut på och varför den är bra. Jag har länge avfärdat en del språk och paradigmer som kuriosa och leksaker som inte skulle klara av enterprise, men efter denna konferens får jag nog omvärdera mina åsikter.
Converting Selenium waitForCondition to WebDriverWait
Posted by alexander in Kära dagbok on September 11, 2011
I usually don’t write simple tutorial posts, but I’d like to share this one, because it took me some time to google the answer, and I still had to adapt it to my case.
I had the simplest possible vanilla Ajax application, that would react to keystrokes in a textfield and then return a list of words based on the entered value. You see this everywhere! My particular HTML snippet looked like this:
<body onload="document.getElementById('prefixText').focus()">
<input type="text" id="prefixText" onkeyup="checkForExpansion(document.getElementById('prefixText').value)"/>
<br/>
<span id="ajaxResults"></span>
</body>
checkForExpansion just made an asynchronous call the a servlet that returned a list of completions. However, one thing was a little untypical with this application: The results went in as strings separated by <br/> tags into the span element. The consequence of this was that there was no obvious element to wait for when testing this page; the span was there already.
Now, my first test went like this:
@Test
public void trivialAjaxListCompletionExampleUsingSelenium1StyleWait() {
Selenium selenium = new WebDriverBackedSelenium(webDriver, testedUrl);
webDriver.get(testedUrl);
webDriver.findElement(By.id("prefixText")).sendKeys("a");
selenium.waitForCondition("selenium.browserbot.getCurrentWindow().document.getElementById('ajaxResults').innerHTML.indexOf('ALEX') > 0", "1000");
}
It worked, but it relied on WebDriverBackedSelenium, which I really didn’t want it to. After some googling and experiementing, I came up with the followging:
@Test
public void trivialAjaxListCompletionExampleUsingWebDriverStyleWait() {
webDriver.get(testedUrl);
webDriver.findElement(By.id("prefixText")).sendKeys("a");
boolean isListPopulated = (new WebDriverWait(webDriver, 1000))
.until(new ExpectedCondition() {
public Boolean apply(WebDriver d) {
JavascriptExecutor javascriptExecutor = (JavascriptExecutor) webDriver;
return (Boolean)javascriptExecutor.executeScript("return document.getElementById('ajaxResults').innerHTML.indexOf('ALEX') > 0");
}
});
assertTrue(isListPopulated);
}
As a test, this sucks, but this snippet shows several interesting things. First we have the WebDriverWait class. Waiting can be quite fine-tuned using the FluentWait class.
Then we have an example of the browserbot being dropped (since it’s a Selenium 1 thing) and Javascript with a return (mandatory in Selenium 2).
Finally, we have the boolean test. Many examples on the web are written so that they wait for a certain element to appear, and then return it. Since the element (the span) was already present, I wanted to make the example a little odd.
Installerar monsterfläkten Noctua NH-U12P
Mycket geekande nu. Köpte en födelsedagspresent till mig själv: monsterfläkten NH-U12P från Noctua.
Egentligen håller jag inte på med överklockning, utan vill ha en tyst dator, men min andra dator blev tvungen att köra på en riktig stock-cooler, så jag bestämde mig för att transplantera CPU-fläkten från min nuvarande dator till den, men då behövde jag en ny. Då tänkte jag att det är lika bra att köpa något ordentligt, instället för något skit för 300 spänn.
Installationen tog drygt två timmar, eftersom jag fick rycka hela moderkortet, rengöra CPU:n och trassla med sladdarna till fläktkontrollerna. Manualen är tydlig, och hela produkten andas kvalitet. Monteringsdelarna för AMD och Intel är tydligt separerade, så det vara bara tuta och köra.
Allt gick smärtfritt, och jag fick ihop alla sladdar inför första starten. Självklart körde jag med bägge fläktarna som följde med. Kan också nämna att lådan jag körde med var en Antec 300, och ja, fläkten passar, även med sidofläkten intallerad. Har googlat detta själv, för det är inte självklart.
Kan nämna någonting om ljudet också. Alla fläktar förutom en i den låda är just Noctua-fläktar. Att köra två P12:or till i 1000RPM bidrog inte direkt till att höja ljudnivån.
Nu i efterhand måste jag säga att det var kul att installera denna fläkt. Normalt vill jag bara få det att funka, men den här har tillräckligt många delar man ska skruva fast och greja med, att man känner att man bygger ihop något. Lego .
Halvvägs: moderkortet ryckt, CPU:n ren, monterkingsskenorna på plats.
Kände mig sen tvungen att överklocka lite defensivt bara för att, och då blev det så här med Prime95 och bägge fläktarna på 1000 RPM:
En hel del kvar att ta av alltså.
Gör en Blondinbella
Posted by alexander in Kära dagbok on June 14, 2011
Idag gör jag som vilken 20-årig bloggande flicka som helst och visar vad jag fått med posten…
Ta-da! Den högra boken – Solaris Internals. Lägg märke till dett gulliga omslaget
För att få en finare bild har jag ställt en annan bok ur min bokhylla bredvid. Varför detta? Jo, därför att jag för ett tag sedan insåg att jag är för dålig på OS. Jag har kört Linux sedan -96 och Solaris sedan -99, men jag har kört dem som lekman. Mina kunskaper slutar vid grundläggande IPC (jag vet vad en door-fil är) och vid halvavancerade kommandon (jag vet hur man använder strace och truss, men vet inte vilka växlar man ska använda). Fram till för en vecka sedan tyckte jag att jag “kan göra allt jag vill” i ett Unix-baserat system. Nu har jag dock ändrat åsikt och börjat känna att det är dags att plugga på lite.
Det jag vill säga med detta inlägg är inte hur bra eller dåligt jag kan Unix. Det jag vill säga är att jag vill leva som jag lär. På min hemsida skriver jag att professionell mjukvaruutveckling handlar om att kunna hantera sin egen dator och servern man jobbar med. Med detta menar jag att den professionelle utvecklaren vet hur operativsystemet fungerar – på djupet.
Kan man sitt OS har man en otroligt kraftfull verktygslåda till sin hjälp. Fram till för ett tag sedan var det bara Unix som gällde, men i och med att Windows har saker som VBScript och PowerShell, så är det värt att snegla på det också. De flesta utveklare jag känner behärskar följande kommandon: cd, cp, pwd, ls, more, less, cat och ps. That’s it. Detta brukar leda till att de stöter på artificiella begränsningar, som inte behöver vara där. Bland annat blir allehanda automatisering tidskrävande.
Summa summarum: är du utvecklare, lär dig ditt OS. Ordentligt! Dessutom skadar det inte att råka läsa om minneshantering i en tid när en garbage collector försöker rensa upp allt…
Write up Agila Sverige 2011
Jag har som många andra branschkolleger deltagit på Agila Sverige i dagarna. Tyvärr missade jag halva första dagen, men man måste ju arbeta, inte bara ha kul. Det hade varit typiskt mig att detaljrecensera alla presentationer jag har varit på, men idag låter jag bli och fokuserar på helheten.
Helhetsintrycket var väldigt positivt. Det bästa med årets konferens var att många talare var väldigt väl förberedda och ansträngde sig väldigt mycket för att göra sina tio minuter till något riktigt bra. Sen är det klart att man bara hinner att slänga ut några teasers på den korta tiden, men det sätter klart fart på tankarna hos de som lyssnar. Måste också säga att jag tycker blixttal är en speciell sport, eftersom man verkligen måste hålla sig till sina tio minuter. Att få till det är en rolig utmaning alla borde pröva.
En annan sak som var sjukt bra var bredden på ämnena. Visst dominerade vissa ämnen, men att slänga in lite monader och tankar kring utvecklingssamtal var väldigt lyckat. Det är också kul att känna igen folk från förra året, eller snarlika sammanhang. Cred till arrangörerna helt enkelt!.
Nej… Jag kan inte låta bli… Måste recensera på något sätt. Detta är talen jag minns:
Vad händer i produktion, Mårten Gustafson: hitta.se har koll på sina program när de kör. Tydligen är Metrics ett bra verktyg för detta.
Sustainable pace – lärdomar efter 100 miles, Torbjörn Gyllebring: Sköna metaforer till proffslångdistanslöpning.
En ung utvecklares första steg på osäker mark, Soroush Hakami: Förväntade mig samma presentation som Dynabyte körde förra året med en junior utvecklare. Positiv överraskning och talaren hade några bra take aways.
Lägg ner utvecklingssamtalen, Peter Antman: Bra kontrast till andra tal.
Är visionen om ”BDD för alla” ett evolutionärt felsteg, Andreas Ekström: Kul att någon börjar kika på om man kan slakta denna heliga ko. Bra analys av nuläget i BDD-lägret.
Behövs automatisering på alla testnivåer, Jonas Hermansson: Tyckte mest att talaren hade sunda värderingar och verkade kompetent (han tyckte som jag )
Enkla monader, Måns Sandström: Monader exemplifierade i Erlang. Behöver inte säga mer
Perfection Game Retrospective, Hans Brattberg: Exempel på bra sätt att ge och ta emot feedback. A keeper.
En case study i ”subtle control” mha CDE, Dan Bergh Johnsson: Dan berättade på sitt kluriga sätt hur han manipulerade ett teams verklighet.
Från backlog till produktion på två veckor – agil testning på Tele2, Örjan Bjermert: Där jag är nu fungerar inte testning och Scrum. Här var en kille som kunde berätta om hur man gör för att få det att funka.
Oops… Det vart visst några smårecensioner, men faktum att jag kom ihåg så många säger väl en hel del om kvaliteten.
Logical code
Posted by alexander in Kära dagbok on April 8, 2011
While reading a book on unit testing, The Art Of Unit Testing by Roy Osherove (a very good book by the way), I stumbled across his definition of “Logical code”:
Logical code is any piece of code that has any logic in it, small as it may be. It’s logical code if it has one or more of the following: an IF statement, a loop, switch or case statements, calculations, or any other type of decision-making code.
Why is this definition important? In my world it replaces “too simple to break”, which I think comes from another (old) book on unit testing. If you google it, you realize that it’s not a commonly accepted term for code that needs tests. Simple and trivial as this term might be. I still think it needs more recognition, acceptance, and use. It is, after all, a very sharp and clean definition of an elusive concept.
The world would be a nicer place if conversations like this could take place:
(Good devloper): Why haven’t you written a unit test for this method?
(Bad developer): It’s too simple to introduce any errors. Don’t sweat.
(Good devloper): It does a calculation, therefore it’s logical code. Start working!
Passed part I of SCEA
Posted by alexander in Kära dagbok on February 7, 2011
Today I’ve written the first part of the SCEA exam, or “Java Enterprise Edition 5 Enterprise Architect Certified Master Exam”. It went well enough. The passing score is 57%. It might seem low, but to be honest, I thought the exam was kind of tough, even though I passed with a safe margin.
Why would you write this exam? Java has deviated quite a lot from the “official” way of writing JEE applications; there’s Spring and all dynamic languages, for example. Personally, I think there’s value in this exam. It forces you to learn architecting Java applications the way Sun (or Oracle) thinks they should be designed, and you have to learn lots of technologies and APIs that are not always used when you adopt the open source way of developing enterprise Java.
In retrospect, I think this exam was fun to prepare for. These are the books I used:
- Sun Certified Enterprise Architect for Java EE Study Guide (Allen & Bambara)
- J2EE Design Patterns (Crawford & Kaplan)
- EJB 3 in Action (Panda & Rahman & Lane)
- Core Java Server Faces (Geary & Horstmann)
- The online version of Core JEE Patterns (http://www.corej2eepatterns.com)
- Lots of specs like JAX-WS, JAXR, JAXB, StAX, …
The exam itself is fun too. It contains a lot of case questions like “Company A has 4 web servers and one app server, they run JSP pages and use MDB. Why is this good/bad?”, and some very detailed ones that you’re never prepared for. The two I remember very specifically were a very detailed question about the SecurityManager and about Java Web Start sandboxes (didn’t even know that Java Web Start had a sandbox ).
All in all, you feel kind of good about yourself after passing this one. I’m quite excited about part 2.