Årsagerne til dette er flere. Jeg har travlt med arbejde, med Anybite, og så er jeg kommet til den konklusion, at WordPress efterhånden ikke længere passer til mine behov.

WordPress har været (og er for så vidt stadig) en god blogging platform. Det er nemt at komme igang med WordPress – både for folk med teknisk forstand, men bestemt også for dem, som bare gerne vil igang med at blogge uden at sætte sig ind i en helt masse først.

Men WordPress har også stort set uanede muligheder – ikke mindst pga. den store brugerbase og de mange, som udvikler plugins og themes til WordPress. Der findes stort set et plugin til hvad som helst, man kan komme i tanke om.

Det paradoksale er dog, at alle de muligheder på sin vis også er blevet årsagen til, at WordPress og jeg er “vokset fra hinanden”. Jeg er kommet frem til, at jeg ikke har brug for alle de muligheder, og at jeg føler, at de mange muligheder hæmmer min udfoldelse, fordi de tager tid og energi fra det væsentlige – nemlig at “producere”.

Heldigvis er jeg jo ret godt hjulpet i og med, at jeg selv har forstand på softwareudvikling. Så jeg er gået igang med at lave min egen blog – helt fra bunden. Jeg laver alt selv – endda også designet (og det er da også det, man kan få et glimt af i det udsnit, jeg har indsat i denne post).

Hvornår jeg lancerer den nye blog, ved jeg endnu ikke helt. Jeg ved blot, at jeg ikke ønsker at pussenusse for meget med den. Det betyder nok også, at jeg i første omgang vil starte med en ren tavle, og så kan jeg altid senere kigge på at få migreret gamle blogposts.

Én ting er helt sikkert – jeg glæder mig ualmindeligt meget til, den nye blog er klar!

©2010 Rasmus.

Related posts:

1. CoffeePress
2. I WordPress Plugin Database
3. Opgradering

Gem’en tilføjer indtil videre to metoder til modelklassen – en instansmetode, som kan svare på, om en instans er publiceret, og en klassemetode, som finder alle publicerede instanser.

Jeg hoster koden på GitHub, og gem’en ligger på RubyGems.org. Begge dele er valgt for at sænke barriererne for dels at få andre til at hjælpe til med at udvikle på denne gem, men bestemt også for at få andre til at installere og bruge gem’en.

©2010 Rasmus.

Related posts:

1. Cowboy-koder
2. Ruby Best Practices
3. MailChimp i Rails

Jeg fik nemlig mærkelige fejl, som ingen mening gav – og det blev ikke mindre mærkeligt, da jeg prøvede at rode rundt i konsollen. Jeg loadede et modelobjekt, og en attribut, som skulle være en Fixnum, blev repræsenteret som en String. Når jeg så prøvede at overskrive denne attribut og gemme objektet, skete der intet i databasen, fordi når jeg fandt objektet igen, havde det nøjagtigt samme værdi.

Ydermere opdagede jeg, at objektet også indeholdt en attribut, som jeg havde fjernet i en migration.

Så jeg prøvede at droppe alle tabeller og oprette dem igen (og jeg tjekkede outputtet fra rake db:migrate – og alle migrations blev afviklet).. Men stadig var der den samme fejl.

Det var først, da jeg genstartede instansen, at de mystiske fejl forsvandt og database og modelobjekter stemte overens.

Umiddelbart kan jeg ikke se, hvad der skulle være skyld i denne besynderlige opførsel (jo jo, det er en eller anden form for caching, men i forhold til en anden test-instans er der ingen forskel i konfiguration andet end, at de to instanser har hver deres environment.

For mig er det en gotcha.

©2010 Rasmus.

Related posts:

1. JRuby on Rails blandet med Java
2. Nytårshandlen overstået
3. Tid til lidt nyt

Du har overvejet, hvad den skal hedde, og hvad den skal returnere (hvis den overhovedet skal returnere noget). Du har også nogenlunde fundet ud af, hvad det er, metoden skal kunne.

Men tag lige og stop op og stil dig selv et enkelt spørgsmål: Kan du med en kort sætning beskrive, hvad metoden gør?

Hvis du ikke kan det, så kan det være tegn på, at metoden gør for meget, og så bør du overveje, om det kan gøres anderledes.

Årsagen er ganske enkelt, at jo mere en metode gør, jo sværere er den at teste, og jo sværere er det at overskue eventuelle sideeffekter. Hvilket i sidste ende betyder, at koden er sværere at vedligeholde.

Gør dig selv og dine kolleger den tjeneste nøje at overveje, hvor meget dine metoder foretager sig.

Enhver kan skrive kode, som kun en ekspert kan forstå. Men kun eksperter kan skrive kode, som alle kan forstå.

©2010 Rasmus.

Related posts:

1. Return null
2. Jeg har glemt meget
3. Integration med Twitter

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.

©2010 Rasmus.

Related posts:

1. En kort sætning
2. -550
3. Cowboy-koder

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.

©2010 Rasmus.

Related posts:

1. Rails testing
2. En dag med Ruby, Rails og Cucumber
3. acts_as_publishable Rails Gem

Gettext med .po, som er mere eller mindre standard i PHP – det bruger et eller andet kompileret format, hvor det er nødvendigt at bruge en compiler og noget editor til det..

Java med dets String externalization, hvor man smider strenge i property-filer uden nogen form for namespacing eller noget.

Ruby on Rails, som i mine øjne har den bedste implementation, jeg har kigget på – hvor tekst ligger i yaml-filer, hvor der er namespacing, og så er det i klartekst.

Men i alle implementationer er der dobbeltarbejde, og når et projekt vokser sig større end noget, der blot svarer til eksempler, så bliver det en pine.

Findes der ikke en eller anden løsning i Rails (da det er det, jeg sidder med lige nu), som gør det nemmere at arbejde med og vedligeholde? Hvis der er, kunne jeg virkelig godt tænke mig at høre om det.

©2010 Rasmus.

Related posts:

1. Cowboy-koder
2. Det’ ikk’ så ring’ endda!
3. En kort sætning

Anyways – WordPress Plugin Directory bør de fleste WordPress-bloggere kende, da det er der, man nemt kan finde plugins, og har man tilstrækkeligt med privilegier på ens blog, kan man også fra ens egen blog søge i WordPress Plugin Directory og installere plugins derfra.

Så efter mit plugin er blevet lagt derop, når jeg meget længere ud til andre bloggere, som kan drage nytte af det, og det er i virkeligheden også lidt en af grundene til, at jeg satte mig ned og skrev plugin’et.

Jeg har efterhånden været WordPress-bruger i mere end to år, og jeg har været ivrig forbruger af både plugins og themes i den tid. Derfor er det rart nu at kunne bidrage med noget til WordPress-community’et.

Jeg håber, nogen finder det nyttigt, og ellers har det været en meget interessant øvelse, som har givet mig en mulighed for at kigge lidt på WordPress plugin API’et, og det skader jo aldrig at sætte sig ind i nyt stof.

©2010 Rasmus.

Related posts:

1. Blogtoppen
2. Kontraintuitivt plugin
3. Opgradering

Måden, Blogtoppen tæller besøgene på, er ved, at jeg har lagt en stump JavaScript her på min blog, som fortæller Blogtoppen om, hver gang nogen ser på en side her på bloggen.

I første omgang indlejrede jeg JavaScriptet i det theme, jeg bruger på min blog. Men det er ikke den bedste løsning, da jeg ved opgraderinger af theme’et skal til at indsætte JavaScriptet igen. Så i dag besluttede jeg mig for, at jeg ville lave et plugin, som kunne klare arbejdet automatisk vha. plugin-API’et, som findes i WordPress.

Som sagt, så gjort – jeg har skrevet mit første WordPress-plugin – WP-Blogtoppen, og det ligger indtil videre her på bloggen. Men jeg har dog også sendt en ansøgning afsted for at få det lagt i Wordpress Plugin Directory’et.

Lige nu er det ude i en version 0.1 – det skal ikke forståes som at plugin’et er ustabilt eller usikkert at bruge. Men derimod at det stadig er den allermest basale funktionalitet, der er implementeret.

Plugin’et sørger for at sætte JavaScriptet ind for alle brugere, som ikke er administratorer, og den eneste konfiguration af pluginet er at udfylde et enkelt felt med tracking-nøglen.

Skulle det vise sig, at nogle fejl har sneget sig ind, eller hvis du har prøvet pluginet og har forslag til ny funktionalitet, så tøv ikke med at efterlade en kommentar!

©2010 Rasmus.

Related posts:

1. WP-Blogtoppen v0.3
2. I WordPress Plugin Database
3. CommentTweets

Det lyder umiddelbart underligt, at man som udvikler kan producere en negativ mængde kode. Men helt tosset er det nu alligevel ikke – fordi programmet fungerer på fuldstændig samme måde som før; ja rent faktisk fungerer det bedre nu, da der var en fejl, som jeg samtidig fik luget ud.

At slippe af med en fejl er selvfølgelig meget godt. Men hvad, der er endnu bedre, er, at der samtidig nu er mindre kode at vedligeholde. Det er den absolut største fordel ved at have færre linier kode.

Sammenhængen er i virkeligheden ganske simpel – det kode, som ikke er der, kan ikke indeholde fejl, og det kode, som ikke er der, behøver man ikke forsøge at forstå endsige tænke på for at kunne forstå, hvad programmet gør.

Derfor er det slet ikke så paradoksalt, at kodekarle som mig siger noget i stil med: “The best code is no code”.

©2010 Rasmus.

Related posts:

1. En kort sætning
2. Return null
3. Cowboy-koder