Rasmus

Return null

Rasmus — Tue, 09 Mar 2010 18:46:53 +0000

Return null; er et alt for ofte brugt statement (i Java i hvert fald).

Når der i en metode står “return null;”, er det oftest fordi, man er røget i et eller andet specialtilfælde, hvor metoden ikke har noget fornuftigt at returnere, men det er alligevel ikke så alvorligt, at der skal kastes en exception.

Det er i hvert fald det, jeg ser mest.

Men som regel er det i mine øjne ikke det bedste valg at returnere null. Det er nemlig problematisk, fordi man får utroligt meget kode, som skal tage højde for, at returværdier kan være null – og det er ofte fuldstændigt udokumenteret, hvornår en metode returnerer null. Rigtigt slemt bliver det, når en metode i flere forskellige tilfælde kan returnere null – hvordan skal man håndtere det?

Hvis man glemmer at kontrollere returværdier for, om de er null, står man pludselig med fejl, og tester man alle returværdier, står man pludselig med en hel masse kode, som udelukkende tester for null.

Man kan dog vælge at lave helpermetoder, som foretager null-tests. Det kan gøres vha. generics (i hvert fald i Java); det kan gøres på relativt få linier kode, men det er til gengæld med til at give et ekstra lag af kompleksitet.

En langt bedre løsning er i min optik, at man som udvikler rent faktisk gør sig den ulejlighed, at man bruger “return null;” så lidt som muligt og i stedet for tænker over, hvad man kan returnere, hvis der ikke er noget at returnere. Det lyder lidt tosset, men f.eks. er en tom liste bedre at returnere end null, hvis man ikke kan finde det, som metoden er blevet bedt om at finde.

Der er sågar et design pattern, som beskæftiger sig med dette – Null Object Pattern.

Naturligvis kan det nogle gange give god mening at returnere null, og i de tilfælde skal man selvfølgelig returnere null. Men langt henad vejen vil jeg mene, at null er det helt forkerte at returnere.

Del med andre:

Pastatilberedning for dummies (og alle andre!)

Rasmus — Thu, 04 Mar 2010 23:27:42 +0000

For ca. et år siden skrev jeg en blogpost med titlen “Sådan koger man pasta”, og siden dengang har den fået ca. 300 hits, hvoraf de fleste er kommet fra folk, som har søgt efter vejledning i, hvordan man koger pasta.

Set i det lys, så er jeg faktisk lidt ked af, at alle disse folk er gået forgæves, fordi den gamle post handler slet ikke om, hvordan du koger pasta, men derimod om hvilke sjove ting, som folk har søgt på, inden de er landet på denne blog.

Jeg vil gerne råde bod alle de forgæves besøg ved her at fortælle, hvordan du netop tilbereder pasta.

Umiddelbart virker det jo meget simpelt at koge pasta. Det handler jo bare om at hælde vand i en gryde, putte noget salt i, tænde for varmen, og når skidtet koger, så smider du pastaen i og lader det hele koge, indtil pastaen er blød.

Indrømmet – det er ikke raketvidenskab. Men der er alligevel et par små retningslinier, som er gode at følge, hvis du vil have rigtigt god pasta.

Pasta skal for det første koges i rigeligt vand; brug en god liter vand pr. 100 gr. pasta (mere hvis det ikke er så stor en portion, du koger).

For det andet skal der mere salt til, end de fleste tror. Vandet skal smage salt, hvis du smager på det. Regn med mindst et spiseskefuld pr. liter vand – men er du i tvivl, så smag på vandet.

Vandet skal bringes i kog, inden pastaen kommes i. Det er her vigtigt, at det virkelig bulderkoger.

Afhængigt af hvilken pasta, det er, er der naturligvis forskellige kogetider. Tørret pasta skal koge et sted mellem 7 og 13-14 minutter alt efter, hvor tykt det er; spaghetti skal koge kortest tid, mens penne og fussili skal koge længere.

Er det frisk pasta, er det mellem 2 og 4 minutter, det skal koge. Har du selv lige stået og lavet pastaen, er det nærmere 2 minutter (afhænger naturligvis af hvor tykt, du har rullet det ud), mens købt frisk pasta skal have helt op imod 4 minutter, hvis det er fuldkornspasta.

Under kogningen er det nødvendigt at røre i gryden en gang imellem for, at pastaen ikke klistrer sammen eller til bunden af gryden.

I stedet for blot at forlade dig på tid, så er det også vigtigt, at du undervejs fisker noget pasta op og enten smager på det eller river det over. Er der stadig noget hvidt i midten, er det ikke færdig – det skal have en jævn let gul farve hele vejen igennem, og så må det ikke være slasket! Der skal stadig være en lille smule bid – det skal være al dente!

Med det samme pastaen er færdig, hældes vandet fra, og det blandes sammen med saucen – dette er også vigtigt, da du ellers risikerer, at pastaen klistrer sammen.

Tilberedning af pasta er som sagt ikke raketvidenskab. Men med lidt omhyggelighed opnår du et bedre resultat, end hvis du bare gør det med hovedet under armen.

Del med andre:

Kick ass!

Rasmus — Sat, 27 Feb 2010 11:09:34 +0000

Det var med ordene “Kick ass!”, Niklas Stephenson sparkede StartupLab igang i går sidst på eftermiddagen i GeekHouse.

StartupLab er en weekend, hvor 10 it-startups får mulighed for at samle inspiration fra spændende oplæg, sparre med hinanden, med et stort hold af mentorer og med potentielle investorer.

Vi har nu været igang i små 18 timer, kun afbrudt af 3-4 timer, hvor folk har fået sovet en lille smule. Men på trods af den minimale mængde søvn, vi alle har fået, fejler energiniveauet ikke noget – snakken går lystigt både på tværs af startups og internt. Fællesnævneren for samtalerne er, at de alle drejer sig om at komme tættere på færdige produkter, som forhåbentlig bliver successer.

Min grund til at være her er, at Anybite, som jeg er en del af, har været så heldig, at vi blev udvalgt som et af de 10 startups, og vi har allerede nu fået en masse spændende feedback fra både mentorer og de andre startups.

Indtil videre er StartupLab et lukket arrangement, hvor vi får mulighed for at arbejde – og målet med weekenden er den åbne aften i morgen kl. 19, hvor alle har mulighed for at komme ind og høre de 10 startups præsentere deres idéer i håbet om, at skaffe sig investorkapital.

Men nu vil jeg tilbage og “kick’e ass”!

Del med andre:

Det er derfor!

Rasmus — Wed, 24 Feb 2010 23:11:30 +0000

Statiske metoder med kompleks logik, singletons og reflection – og kombinationer deraf.. Det er alle ting, som jeg har erfaret, gør det temmelig besværligt at skrive fornuftige tests.

Hvordan skriver man f.eks. en unit test til en metode, som kalder en statisk metode? I særdeleshed hvis den statiske metode skulle risikere at kommunikere med f.eks. en database, en webservice eller et helt tredje eksternt system? Den eneste mulighed er vel, at man kan håbe på, at man kan afkoble ressourcerne, som den statiske metode benytter. I mine øjne er det ikke optimalt.

Når det kommer til singletons, er det lidt den samme historie. Hvordan tester man en metode, som anvender en singleton? Igen kan jeg kun se, at man kan gøre det ved at afkoble de ressourcer, som singletonen anvender eller lave en “hemmelig” statisk metode i singletonen for at kunne overskrive singletonens reference til instansen.

Når det så kommer til metoder, der anvender reflection – så går det rigtig galt. Hvis det er i Java, og det omhandler loading af klasser, så skal man vel ud i noget med at fuske med class path og lave en stub/mock-implementation med samme FQN, som så bliver loaded via Class.forname i stedet for den rigtige klasse. Hvordan det lige forholder sig med metodekald via reflection, kan jeg slet ikke forestille mig lige nu.

Nu håber jeg bare, at jeg husker, at jeg har skrevet denne blogpost – det er nemlig mest af alt for at gøre mig selv klogere (eller i hvert fald prøve på det) samtidig med at tage ekstern hukommelse i brug; det er ikke for at udbrede viden – det er der andre, der er meget bedre til end mig.

Forresten! Hvis du ser mig være igang med at bruge nogle af de ovenstående ting, gider du så ikke lige prikke mig på skulderen, minde mig om denne post og spørge mig, om jeg virkelig har tænkt det igennem?

På forhånd tak!

Endnu mere forresten! Har du gode ideer til, hvordan man tester kode, hvor det ovenstående indgår, eller at jeg tager fejl, så må du meget gerne oplyse mig.

På endnu mere forhånd tak.

Del med andre:

Det virker for mig!

Rasmus — Mon, 08 Feb 2010 21:23:57 +0000

Mangt og meget er skrevet om unit testing – heriblandt også en masse kloge og generelle ting. Det vil jeg ikke forsøge på. Det er jeg slet ikke klog nok til.

I stedet vil jeg blot konstatere, at unit testing virker for mig, og det er lige meget, om det er mig eller andre, der skriver dem, og om de bliver skrevet før eller efter produktionskoden er skrevet.

Det, jeg for alvor har opdaget på det seneste, er, at min produktivitet afhænger proportionelt af mængden af tests (og kvaliteten af disse). Er der gode tests, er min konfidens større, jeg har nemmere ved at skabe overblik over koden, og jeg kan derfor hurtigere komme frem over stepperne.

Derfor insisterer jeg på, at unit testing (og anden testing) er en god ting, og derfor insisterer jeg på at bruge tid på det – ikke fordi nogen har skrevet en masse kloge ting.

Del med andre:

Ham, den gamle, sure mand

Rasmus — Tue, 02 Feb 2010 19:11:06 +0000

Hvis man følger mig på Twitter, så vil man have bemærket, at jeg er begyndt at brokke mig mere og mere over programmeringssproget Java:

Det skal kompileres, classloading er noget bøvl, implementationsdetaljer fra Javas serialiseringsmekanisme, som unødigt forurener klasser, Swing, der er virkelig besværligt at danse med, manglen på anonyme metoder (closures, blokke, lambdaer, kald dem hvad du vil), anonyme klasser, generics, som er sort magi (virker det, er man enten en troldmand eller blot heldig), osv.

Kort sagt: Jeg ser flere og flere ulemper ved Java.

Egentlig er det ikke Java, der er blevet dårligere. Det er blot mig, der er blevet klogere.

Jeg har indtil for et års tid siden stort set kun arbejdet med Java (og derhjemme rodet med PHP, Perl og Python), så jeg kendte stort set ikke andet. Men da jeg sidste år blev kastet nærmest hovedkulds ud i Ruby, skete der ting og sager.

Jeg blev fanget af sproget, og jeg er blevet ved med at arbejde med det – nu godt nok ikke i dagtimerne, men om eftermiddagen og aftenen arbejder jeg på et projekt, hvor udviklingen foregår i Ruby. Så jeg har pludselig anvendt et andet sprog end Java ganske intensivt, og det har i den grad åbnet mine øjne overfor, at tingene kan gøres på en anden måde.

Jeg vil ikke agitere for, at det er Rubys skyld som sådan, at jeg er blevet klogere – det er der ikke rigtigt noget belæg for. Det kunne lige så godt have været et andet sprog – det handler også om smag og behag.

Det, der derimod nok kan forklare, at jeg er blevet klogere, er, at jeg er kommet til at arbejde med noget, som ligger ganske langt fra det, jeg kendte i forvejen. Havde det f.eks. været C#, der havde været mit valg, ville jeg nok ikke have fået åbnet mine øjne så meget.

Sådan set handler dette slet ikke om programmeringssprog, softwareudvikling eller noget som helst nørdet (på trods af jeg ellers lagde hårdt ud..) – det handler i virkeligheden om faglig udvikling, og det er i virkeligheden heller ikke særligt banebrydende. I The Pragmatic Programmer (og måske også i Code Complete) nævnes det, at man som softwareudvikler bør lære et nyt programmeringssprog eller en eller anden teknologi om året.

Det er lige præcis det, jeg har gjort – og det har som sagt virket.. Faktisk i overraskende høj grad!

Del med andre:

Itsy – Minimalistisk tweeting

Rasmus — Fri, 22 Jan 2010 18:26:50 +0000

Gennem et tweet fra @marks hørte jeg om Itsy, en yderst minimalistisk Twitterklient til Mac OS X.

Der er virkelig skåret ind til benet i Itsy – der er den helt basale funktionalitet, og så er der heller ikke mere!

Når man starter Itsy op første gang, er det, første man bliver præsenteret for, dette:

Itsy lige startet op

Og når man er logget ind, er det dette:

Itsy - logget ind

Der er ikke så meget mere at fortælle om Itsy – det er ca. hvad man kan. Der er ingen overflødig gejl, og det er yderst nemt at anvende Itsy netop pga. den manglende overflødige gejl.

Itsy giver mig den funktionalitet, jeg har brug for, og fjerner alt det, jeg ikke har brug for. Det er sikkert ikke tilstrækkeligt for alle, men det er vel også de færreste applikationer, som kan opfylde alles behov.

Nå ja, en enkelt ting mere ved Itsy, som jeg er helt pjattet med, er ikonet – det kan da ikke andet end at gøre en glad

Del med andre:

InspirationsInjektion #2

Rasmus — Thu, 14 Jan 2010 21:07:50 +0000

I går var der InspirationsInjektion #2 i GeekHouse. Brug de par minutter, det tager at læse siden, jeg linker til – InspirationsInjektion er en fantastisk serie af arrangementer; en slags mini-TED konference “på den jyske måde”.

Gårsdagens program oplevede en smule ændringer – Uffe Koch fra Huge Lawn Software og Martin Brynskov, der er tilknyttet Digital Urban Living, var forhindrede i at deltage, så i stedet havde arrangørerne fået fat i Kristian Ottosen, som stiftede Yawah, der blev opkøbt af Adobe.

I stedet for et sjette oplæg, blev det sidste stykke tid brugt på at samle ideer til forbedringer af InjektionsInspiration og input om, hvad der bliver det helt store og nye i 2010, sammen under kyndig vejledning af Bjarne Tveskov (egentlig var hans tanke, at det skulle have været vha. brainwriting, men der var desværre ikke nok kuglepenne).

Det var et virkelig godt arrangement, og som det vel nærmest er kotume, så var der selvfølgelig MiracleØl i pauserne.

Hvis du synes, det lyder som et spændende arrangement, så er det bare med at følge hash-tag’et #inin på Twitter og evt. også Tommy Dejbjerg Pedersen.

Del med andre:

MailChimp i Rails

Rasmus — Tue, 05 Jan 2010 22:53:30 +0000

Lige så snart man laver websites, hvor brugere kan registrere sig på den ene eller anden måde, løber man også ind i, at det kunne være rart at kunne kommunikere med dem via mails – enten som enkeltstående mails med vigtige oplysninger eller som deciderede kampagner, hvor man gerne vil kunne følge med i, om kampagnerne virker. Til dette er MailChimp som skræddersyet – man får en masse værktøjer til styring af maillists, kampagner, til statistik osv. Og de tilbyder tilmed, at man gratis kan gemme op til 500 mailadresser og sende op til 3000 mails om måneden!

Hele administrationen af mails, kampagner og lister er pakket pænt ind i et API, der bruger HTTP-protokollen til kommunikationsmedie, og dokumentationsniveauet af API’et er faktisk forbilledligt – alle metoder, parametre og returværdier er rimeligt godt beskrevet. Så hvis man vil, kan man selv skrive hele integrationen selv.

Men der er også en anden mulighed, hvis man arbejder med Rails – gem’en Hominid fungerer som en komplet Ruby wrapper af version 1.2 af MailChimp API’et. Dvs. at der ikke er decideret integration med ActiveRecord, ActionController osv. HTTP-kommunikationen er blot abstraheret væk, og så er Hominid også environment aware, så man nemt kan bruge forskellige MailChimp-konti i de forskellige miljøer.

I config/hominid.yml angiver man bl.a. brugernavn, password og api-nøgle på samme måde som man angiver databaseoplysninger i config/database.yml:

development:
	username: usrnme
	password: pw
	api_key: apikey
	send_goodbye: false
	send_notify: false
	double_opt_in: false

Tilsvarende kan man lave konfiguration til test og production (og alle de andre miljøer, man måtte have defineret).

Jeg vil ikke gå så meget i dybden med API’et – der er et eksempel på Github. Til gengæld vil jeg blot vise et lille eksempel på en praktisk anvendelse af Hominid.

På MailChimp har man mulighed for selv at oprette navngivne felter til forskellige slags data, man ønsker modtagere skal oprettes med; såkaldte merge tags. Følgende er blot et lille eksempel på, hvordan man registrerer en ny modtager vha. et ActiveRecord callback (i dette tilfælde after_save), hvor man samtidig sender data med, som skal knyttes til merge tags. Det er ikke raketvidenskab, og det er i høj grad eksempelkode, da der ikke er nogen former for fejlhåndtering eller validering.

class User < ActiveRecord::Base
  after_save :send_to_mailchimp

protected
  def send_to_mailchimp
    list = Hominid::List.find_by_name("users")
    list.subscribe(self.email, :merge_tags => {"NAME" => self.name, "CNAME" => self.company_name})
  end
end

Det interessante her foregår i linie 7, hvor man kan se, at jeg som andet argument til list.subscribe sender et hash med, hvor den eneste value er et andet hash – i det andet hash skal man blot angive navnene på de ønskede merge tags som keys i hashet. Mere er der sådan set ikke i det.

Mere skal der ikke til for at oprette modtagere i MailChimp – og lige som man kan oprette modtagere, kan man naturligvis opdatere dem og slette dem igen. Foruden alle de andre ting, som API’et også giver mulighed for.

Hvis jeg dog skulle nævne en enkelt ting, jeg godt kunne ønske mig (eller selv lave), så er det at kunne integrere MailChimp helt med ActiveRecord – f.eks. vha. en acts_as_subscriber-metode, hvor man kan angive hvilke af modelobjektets attributer, man ønsker at sende over til MailChimp, og så sørger den ellers for at registrere de nødvendige callbacks.

Del med andre:

Træt af Twitter

Rasmus — Wed, 30 Dec 2009 00:15:57 +0000

To gange i løbet af det sidste døgn, har jeg fået mails fra Twitter om, at de har nulstillet mit password, fordi jeg er blevet udsat for et tredjeparts-phishing-forsøg.. Og nu er min konto blevet låst i en time.

Tidspunktet taget i betragtning gør det selvfølgelig ikke så meget, at min konto er låst. Men det er stadig pisseirriterende, at Twitter er så anale, som de åbenbart er – især når de ikke fortæller mig mere om, hvad det drejer sig om, end at det er fra et tredjepartssite.

Fortæl mig noget mere Twitter, eller rend og skid!

Del med andre: