Sunday, September 11, 2011

Tre steg för att lära sig ny teknik



Att ta sig an ett nytt programmeringsspråk, en ny plattform eller kanske ett nytt ramverk kan ibland kännas som en stor och tuff utmaning. Jag tänkte här dela med mig av en snabbvariant av hur jag gör för att snabbt och enkelt lära mig något nytt.

Jag börjar med några ord om min bakgrund. Jag är 34 år, fick min första dator som åttaåring, är civilingenjör och har arbetat professionellt med bland annat ASP, PHP, MySQL, C#, ASP.Net, Actionscript, Perl, Javascript och Zend Framework. Det är när jag har lärt mig dessa tekniker som jag har tagit fram min ödmjuka, och knappast speciellt revolutionerande inlärningsteknik.


  1. Läs mycket och snabbt
    I det här steget handlar det om att få en översikt över den teknik man ska lära sig. Här vill vi inte lära oss detaljer, utan läser mycket och snabbt. Tjocka datorböcker väldigt bra, typ ”Teach yourself C# in 24 hours”, ”Zend Framework bible”. Långa introduktioner på teknikens webbplats kan också vara en bra start, som hela ”Zend Reference Guide” eller hela iOS Developer Library’s ”Getting Started”. Nyckelordet är att man vill läsa mycket. Läs dock snabbt, lägger man två timmar koncentrerat kan man ta sig igenom nästan vilken datorbok som helst medelst skumläsning.
  2. Nu genomför vi ett antal tutorials. Om det inte är helt ny teknik så finns det alltid en stor mängd tutorials att följa. Följ 2-4 tutorials, och genomför själv i din egen utvecklingsmiljö varenda steg och skapa projekt och program/webbplats/app. Se till att allt fungerar. Här slarvläser vi inte längre. När vi stöter på saker vi inte riktigt förstår så slår vi upp det i den digra litteraturlistan vi plöjde i steg 1. Om vi fortfarande inte förstår det så släpper vi det efter en kort stunds fördjupning. Nyckelordet här är att vi försöker förstå. Vissa saker kanske inte klarnar förrän efter flera veckor, och det är helt ok, men det klarnar inte om vi inte försöker.
  3. Nu är det dags att prova vingarna, och vi skapar helt egna projekt med en tydlig målbild för projektet. I den här fasen är det viktigt att försöka göra så mycket som möjligt själv, utan hjälpmedel. Arbeta koncentrerat.
    Givetvis så tar man hjälp av tutorials och texter när man fastnar, allt annat vore dumt.
    Ibland råkar man göra saker som är helt fel för tekniken. Då är det bara att börja om med ett nytt projekt, skapa, pula och dona. För mig är det ofta i det här steget som saker och ting klarnar, och saker som framstod som obegripliga i steg 1 och 2 ger riktiga aha-upplevelser. 


Efter dessa tre steg är vi redo för skarpa projekt. Vi har en relativt bred, men tunn, teoretisk bas att stå på från steg 1, så vi vet ungefär vad man kan göra med tekniken, och var man kan läsa mer. Genom att följa tutorials i steg två så har vi fått se hur erfarna utvecklare hanterar tekniken, och i steg tre har vi fått viss egen praktisk erfarhet.

Sen återstår bara 5000 timmars arbete med tekniken innan man kan kalla sig expert.

(Foto: itzpapalotl's)

Sunday, September 4, 2011

Testning av en klusteralgoritm

Jag pratade med @mattiasostmar igår om olika metoder för att skapa klustrande algoritmer. Här kommer en något text med något högre detaljnivå på temat:
Något som är viktigt om man gör det, är givetvis att inte överoptimera algoritmen för ett visst resultat som man själv ”vill ha”, utan att ha en metodik som minimerar risken för detta.

Ett enkelt sätt som man kan göra det på är att dela upp sina testdata i tre grupper, grupp A, grupp B och grupp C. Viktigt där är att grupp C ska vara stor, så att man kan få resultat som är signifikant.

Den första gruppen, den använder jag aktivt i min testning. När jag ser utfall, då skruvar jag på min algoritm hur mycket jag vill. Jag testar, skruvar, testar, skruvar, tills jag är nöjd med mitt resultat. Grupp A kan vi kalla experimentdata.
När jag går till grupp B däremot, då ska jag egentligen vara rätt så klar med min algoritm. I den gruppen kanske jag kan skruva något litet, för att få bort en överoptimering, men inte mer än så.

Grupp C, det är den gruppen med data som avgör vad jag presenterar för pricksäkerhet för kunden. Om jag har ett stort antal klassificeringar, där min data klassificeras i olika grupper, så kikar jag på varje grupp och och ser hur ofta min algoritm gjorde rätt. Om vi har n tester för grupp n, där jag har 80% rätt, så hämtar jag min gamla Mathematics handbook och slår upp vad det blir för signifikans på det hela. Målet där är ju att kunna skriva ”80%+-4%” eller något liknande.
:-)