Men nu har det blivit dags att köra igång igen! Trots moderniteter som bloggar, Facebook, Twitter och annat är fortfarande ett helt vanligt nyhetsbrev via e-post ett fantastiskt bra sätt för oss att nå ut och framför allt för dig att hålla dig uppdaterad.

Så om du är kund – eller bara är intresserad av vad vi har för oss – är det dags att anmäla sig till vårt nyhetsbrev. Det kommer att komma ut ungefär en gång per månad.

Vi har byggt ett litet enkelt intranät i Ruby on Rails åt VVS-konsulterna FLK. Det har rullat på ett tag, men efter några uppgraderingar av serverns operativsystem blev det plötsligt otroligt.

Normalt sett brukar vi använda Ubuntu-maskiner för att driftsätta webbapplikationer med Ruby on Rails, men ibland kan vi av olika skäl inte välja vilken miljö våra applikationer ska köras i. Så var det nu, och då gäller det att lösa problemen.

Kevin satt och svettades ett tag med att undersöka varför Mongrel hela tiden kraschade, och till slut valde vi att byta ut den mot den lilla snabba webbservern Thin. Den är betydligt mer stabil än många av sina föregångare, men lite problematisk att installera på Windows.

För att folk som hamnar i samma knipa inte ska behöva slita sitt hår publicerar jag några av Kevins anteckningar här.

• Vi installerade Ruby via RubyInstaller
• Du behöver DevKit (finns länkat på Rubyinstallers webbplats. Vi använde den här versionen). Du får inte ta bort mappen du extraherar filerna till. Då fungerar det inte och du får börja om.
• Har du gamla DevKit tools behöver du göra ruby dk.rb install –force för att skriva över dem. Annars failar det.
• Du behöver den senaste versionen av RubyGems (gem update –system)
• Om du får fel relaterade till pathspec, ominstallera de gems den klagar på.
• gemen Abstract och EventMachine behöver du avinstallera om du har dem innan du installerar Thin. gem uninstall abstract eventmachine
• Specificera den absolut senaste releasen av EventMachine i din gemfile, innan du specar gemet ‘thin’. gem ‘eventmachine’, ’1.0.0.beta.4.1′, :platform => :mingw

Kör det ihop sig fullständigt får du höra av dig så kanske vi kan skaka loss en konsult i några timmar som hjälper dig på traven.

Till detta har vi byggt både en webbplats och en webbapplikation där personalen kan svara på frågor om sin chef och där vi sedan kan hämta ut statistik, kommentarer och snygga grafer. Den fungerar både på datorn, på iPad och till och med i en iPhone utan problem.

Nu när applikationen har blivit mer och mer populär och allt fler chefer ska utvärderas så visade det sig att allt blev segt som sirap efter ett tag. Applikationen är skriven i Ruby on Rails och driftas på en Ubuntu-server av senaste snitt. Bra grejer rakt igenom, så vi började mäta prestandan med hjälp av ett mätverktyg som heter New Relic.

Det fina med New Relic är att den visar precis var din applikation blir seg, och i det här fallet kunde vi efter bara några minuter zooma in på att det var genereringen av de snygga graferna som tog onödigt lång tid. Vi snackar om cirka 75 000 ms per graf, vilket blir ganska mycket väntan när det är omkring 40 grafer på en sida som ska laddas.

Ungefär så här ser graferna ut, och det är den högra delen som är jobbig att generera. För att skydda de oskyldiga har jag suddat ut en del detaljer i grafen.

Efter en hel del grävande visade det sig att felet låg i ImageMagick, biblioteket som genererade själva bilden. Det var kompilerat med 16-bitarsgrafik som egentligen är helt onödigt i webbsammanhang. Så jag tog och kompilerade om hela ImageMagick och fick upp hastigheten på varje request till cirka 200 millisekunder.

Vi har alltså en förbättring där graferna går omkring 350 gånger snabbare att generera bara genom att kompilera om ett litet bibliotek. Det är grejer, det!

Lasse på Chefsportalen är en lycklig kund, och det är ju det som är vårt mål – att skapa lyckliga kunder. Det brukar innebär att vi blir ganska nöjda också. :)

Jonas hanterar de flesta programmeringsspråk. Bland annat PHP, Java och på senare tid även Ruby on Rails är saker han gärna sätter tänderna i. Jonas har tidigare varit konsult på Ericsson och även frilansande webbutvecklare.

Förutom webbutveckling gillar Jonas riktigt snöiga vintrar, även om de kan kännas på elräkningen, och drar sig inte för att prova riktigt exklusiva kaffesorter när tillfälle ges.

Vi hoppas att han ska trivas och önskar honom varmt välkommen i gänget!

Det hela är ganska enkelt, men lätt att komma igång med och bygger på att du använder dig av javascriptramverket jQuery. Du hittar en demonstration på http://standout.github.com/gallery/ och användningen är helt fri. Hittar du några buggar får du gärna säga till.

När du lägger upp nya bilder läser vi in dem och anpassar dem för användning på webben. Det är framför allt för att dina besökare ska kunna uppleva en snabbladdad sida och slippa ladda hem allt för tunga bilder. Om du har många bilder så kan det dock ta lite tid innan alla har hunnit behandlas, och om du är alldeles för snabb kan du hinna publicera sidan innan alla bilder är färdigbehandlade.

Därför dyker det nu upp en tydlig stor röd varningsruta som talar om ifall du har några bilder som håller på att behandlas.

Idag har Firebug version 1.9 släppts, och jag har tittat närmare på fyra av nyheterna i den nya versionen.

Placering av Firebug-docken

Numera kan du välja om du vill ha Firebug längst ned, längst upp, till höger eller till vänster. Tidigare hamnade Firebux alltid längst ned.

Visa varifrån loggningar görs

Att använda console.log för att skriva ut saker är smidigt ibland. Från och med den nya versionen visar Firebug exakt varifrån loggningen har gjorts, vilket snabbar upp felsökningen ytterligare.

Skicka HTTP-request igen

I Net-panelen kan du numera bara högerklicka på valfritt HTTP-request och välja Resend för att skicka exakt samma request igen. Smidigt att använda när du sitter och letar fel på servernivå som har sitt ursprung någonstans i ditt javascript.

Exakt positionering av fel

När du får ett syntax-fel i ditt javascript visas raden det blev fel på och en liten pil dyker upp som även visar exakt var på raden felet har uppstått tillsammans med ett felmeddelande om vad som förväntas. Alla som har felsökt javascript vet att det kan vara lite lurigt att hitta exakt var felet har uppstått eftersom många webbläsare ger ett mycket generellt felmeddelande och hänvisar till en rad längre ner i koden där det egentligen felet inte ligger. Därför är det här ett mycket uppskattat tillägg.

• https://addons.mozilla.org/en-US/firefox/addon/firebug/

Uppgraderingen innehöll lite andra småfixar, bland annat ordnades en felräkning på antalet widgets som visades på dashboarden och maxgränsen för hur mycket man kan ladda upp har ordnats. Men det är framför allt säkerhetsbuggarna som gör att du ska uppgradera nu.

För dig som sitter med en PHP-app och undrar om den är säker eller ej kan det vara intressant att känna till RIPS. Det är en liten programvara som hittar säkerhetshål i PHP-applikationer genom att analysera den på olika sätt. Den gör det bland anant genom att läsa av koden och söka efter typiska säkerhetsluckor, såsom XSS-luckor och SQL-injections.

Programmet är intressant nog skrivet som en PHP-applikation, så du kör den i din webbläsare lokalt och väljer vilka filer du vill analysera.

Du hittar det hela på rips-scanner.sourceforge.net

Strax släpps Rails 3.2 och med hjälp av DHH:s utmärkta bloggpost går vi igenom några av nyheterna.

Mycket snabbare utvecklingsläge

Tidigare har det mesta i din applikation laddats om inför varje request, men nu laddas enbart de klasser som du faktiskt ändrat sedan förra requesten om. Ni som har använt Active Reload tidigare vet precis vad jag pratar om. Det är enorm skillnad på snabbheten, speciellt om du börjar får ihop lite mer avancerade applikationer.

Härma MongoDB med Active Record Store

Att utveckla med MongoDB är snabbt och trevligt, men ofta behöver man stabiliteten hos MySQL och kanske inte är så sugen på att konvertera en äldre app till att använda en helt ny databas. Här kommer Active Record Store in som en räddande ängel.

Du kan spara en hash i bästa json-anda direkt mot valfri modell i Active Record genom att bara definiera följande i din modell:

class Website < ActiveRecord::Base
 store :shop_settings, accessors: [ :currency, :vat_percentage]
end

Allt du sätter som accessors får egna metoder på objektet, vilket innebär att du kan komma åt @website.currency i exemplet ovan. Men du kan även arbeta med helt valfria värden genom att använda dig av @website.shop_settings[:valfritt_attribut]

Date Helpers anpassade för Sverige

Två killar vid namn Kim och Lennart har bidragit med ett extra attribut som du kan sätta på Date Helpers. Attributet heter :use_two_digit_numbers = true och kan användas för att få både dag och månad att visas med en inledande 0:a så att det alltid är samma antal siffror i datumet. Enkelt men bra.

Namespace på formulär

Ibland använder man många formulär vars input-fält får exakt samma id:n, vilket inte är helt lyckat. Rails 3.2 introducerar :namespace-attributet som ser till att du enkelt kan se till att id-värdena inte krockar. Tidigare har vi alltid fått sätta det manuellt, vilket inte blir så snyggt i koden.

First_or_create

Det här kommer att bli det föreslagna sättet att leta efter saker i databasen och skapa dem om de inte redan finns. Exempelvis:

Product.where(:name => "Gurka").first_or_create!(:price => 10) 

Rails 3.2 är just nu i Release Candidate så det är inte riktigt färdigt för släpp än, men kommer antagligen ganska snart. Titta gärna i Changelog för Rails 3.2 för att se alla ändringar.