Viser arkivet for stikkord rubinius

MtnWest RubyConf: Kodegenerering

Skal prøve å kondensere informasjonen litt, men fortsatt prøve å beholde litt innhold! Nå har jeg vært uten nettverk i 5 timer, ikke så lett med internett, med et accesspoint, og over 200 deltakere!

Etter lunsj snakket Giles Bowkett om kodegenerering ved hjelp av magisk metaprogrammering (with safety scissors)

Når man snakker om metaprogrammering i Ruby, snakker man oftest om meta-oo. Man kan gjøre dette på flere måter, og en vanlig måte er å aliase gamle metoder, og omdefinere dem – noe som ofte kalles monkeypatching – og anses som dårlig praksis av mange. De som har fulgt litt med har fått med seg mye motstand mot monkeypatching i blogospheren. Grunnen er hovedsaklig endrene biblioteker som monkeypatches, og det da blir vanskelig å spore endringene.

Giles mener en av de store styrkene til Ruby er at det essensielt tilgjengeliggjør avansert programmering som higher order programmering kjent fra funksjonelle språk som Lisp; på en enkel og forståelig måte! Innenfor metaprogrammering advokerer han hovedsaklig to paradigmer – om jeg kan kalle det det 1) kodegenerering og 2) monkeypatchet monkeypatching.

Angående kodegenerering snakker han hovedsaklig om hvordan man kan bruke Ruby til å skape annen programmeringskode, for eksempel bruke ruby2ruby biblioteket til å generere kode:

irb> l = lambda { puts “i lambdaen” }
=> #<Proc:0×0137ebf4@(irb):13>
irb> l.to_ruby
=> “proc {\n puts(”i lambdaen")\n}"

Eller:

irb> class BlaBla; def name; “bla?”; end; end
irb> puts Ruby2Ruby.translate(BlaBla)
class BlaBla < Object
def name
“bla?”
end
end

Det andre og kanskje mer interessante caset er ideellt for bruk med Rubinius. Der kan man nemlig leke med alt på en ganske sikker måte, noe som åpner opp for veldig kul bruk av monkeypatching. Et eksempel er at man kan overskrive Class.new for å tracke annen monkeypatching:

class Class
alias :old_new, :new
def new(param)
puts “created #{self.name}”
old_new(param)
end
end

Dette vil fungere i Rubinius der alt er Ruby, men er ganske usikkert i andre implementasjoner der store deler er skrevet i C, Java, .NET, osv. Denne ideen kan utvides kraftig, slik at man for eksempel kan bruke det til sporing av monkeypatching, eller istedenfor å bare skrive strenger, kan man for eksempel skrive kode (“#{self.name.camelize}.new(#{param})”), eller rett og slett skape objekter med metaprogrammering av koden.

Veldig interessant ide!

MtnWest RubyConf: dag 1, første session

Jeg og Øystein Ellingbø sitter her på MtnWest RubyConf, Salt Lake City, Utah. Jeg skal prøve å oppsummere foredragene herfra litt kortfattet. Det blir nok endel posts. Vi har hatt en flott tur så langt, vi har fått tak i et par iPhones, selv om de har vært utsolgt omtrent over alt var vi heldige og fant en Apple Retail Store som akkurat hadde fått inn en liten leveranse!

MtnWest RubyConf er en liten RubyConf som nå arrangeres for annet år. Det er over 200 Ruby-programmerere samlet her i SLC public Library, flere kjente navn i vår verden. Programmet er imponerende, og det er kun et track, så blir fullstappet sal ved hvert foredrag. Det er kun fem internasjonale deltakere, så det er veldig spennende å være blant dem!

Confreaks filmer alt, så om dere er interesserte, kan dere nok streame det om en stund :-)

Evan Phoenix om Rubinius og communitites

Evan skal på RubyFools i Oslo også, så dette er kanskje en liten titt om hva han vil fortelle om da! Det første veldig interessante han forteller er om Spec suiten til Rubinius – som blant annet JRuby bruker – vil lanseres som et eget komponent, slik at alle VM-prosjektene kan ta del i en ensretning av Ruby!

Rubinius kjører idag IRB og støtter RubyGems. Naturligvis ikke alle, men det gjerne et produkt av at ikke alle biblioteker følger samme spec for Ruby, i og med at det ikke finnes en offisiell Ruby spec ennå.

Evan fortsetter en interessant rant om bygging av communities, og hvordan få prosjekter i gang, hvordan eierskapet har endret seg fra for et år siden /var han/ Rubinius til nå er han /bare en brikke/ i prosjektet. Han stadfester raskt at man ikke kan kjøpe et community, slike prosjekter feiler lett. Det neste er kanskje litt mer kontroversiellt for oss som har jobbet endel med open source – “ingen bidrag er for små”. I Rubinius godtar de en-linjers-bidrag, selv dokumentasjon, og er veldig åpne i å gi commit-tilgang. På denne måten har alle bidragsytere verdi for prosjektet, og skaper “buzz” i prosjektet. Man vet aldri om det er en 15åring som er den neste store commit-guruen. Ved å senke terskelen for hvem som får lov å bidra får man med seg mange, skaper åpenhet og et organisk community. Rubinius har en veldig åpen form med tanke på bidrag, debatt og eierskap – noe jeg tror mange “elitistiske” prosjekter kan lære av.

Ideen at det er bedre med full kontroll over et opensource-prosjekt er en feilaktig myte. OpenSource-prosjekter er allerede åpnet opp, hvorfor holde tilbake commit-tilgang, og en elitisk kjerne, og ikke benytte seg av de som ønsker å bidra. Når man er veldig lukket for å motta bidrag, blir det ofte et oss og dem forhold, hvor prosjektene ofte dør når kjernen mister litt flyt. På mange måter kritiserer han mentaliteten som for en tid siden førte til Zed’s kjente post, som også Zed kritiserte, men på en litt mer konstruktiv måte enn Mr. Shaw :)

For å oppsummere, i tråd med Paul Graham – programmering er en kreativ kunst. Derfor er kanskje det viktigste i å skape et bra opensource-prosjekt, er å ha det moro, med andre ord – bygge opp under eksperimentering og kreativitet.

Ezra Zygmuntovic om Merb

Merb – foretrekker enkelhet over magi så mye som mulig. Ingen blocks, returnerende funksjoner, meta-konfigurasjon (monkeypatching). Merb er et rammeverk, hvor effektivitet og fleksibilitet er hovedfokus. Om det er tvil i implementasjonen er løsningen benchmark & profile. Merb prøver å være så lite “opinionated” som mulig. Ezra hevder at Merb-applikasjoner er mer langsomme å utvikle enn Rails, men Rails passer ofte som hånd i hansken for 80% av problemene, det er først der de 20% siste prosentene kommer inn at en må sloss mot “meningene” i Rails. Han sier at om applikasjonen passer innenfor de 80% av applikasjonene, for all del, bruk Rails, det er fortere for RAD [sic. rapid application development], men Merb er mer vennlig for de avanserte 20%-ene som ofte dukker opp i Enterpriseapplikasjoner og ikke standard CRUD [sic].

For de av dere som ikke har hørt om Merb tidligere, eller ikke har sett på det har jeg prøvd å trekke ut det absolutt viktigste dere trenger å vite.

Merb er delt opp i flere ulike komponenter – alle fritt tilgjengelige som gems, og kan innstalleres slik:

gem install merb-core

merb-core

Merb gikk nylig gjennom en stor omskrivning. Merb består nå av flere komponenter, hvor hovedrammeverket – merb-core inneholder HTTP abstraksjonen, MVC, støttekode for appservere (Rack API), WS/REST routing, og håndterer alle slags forespørsler meget fleksibelt og robust.

Altså full kontroll over routingen. For eksempel kan man styre hva slags type data som skal godtas, sendes ut, hvordan ressurser skal håndteres, nestede-ressurser, og annen fancyhet.

En annen interessant feature med merb-core er at man kan konfigurere mime-typer, og forenkle hvordan kontrollere kan håndtere ulike dataformater (respond_to) gjennom Provides APIet. En annen lekkerhet (fra merb-more) er syntaktisk sukker for eksempel for HTTP – for eksempel oversettelse av params[:http] til vanlige metode-parametre. Dette gjør koden litt lettere å lese ved å gjøre den litt mer “Rubyesk”. Et eksempel er å la actions ta parametre (som mapper til params[:hash])!

class MyController < Application
provides :json, :iphone, :xml

  1. Vanlig
    def create
    Model.create params[:foo]
    end
  1. Ruby-vennlig
    def create(foo)
    Model.create foo
    end
def show(id) @model = MyModel.find(id) display @model end end

merb-more

Merb-more inneholder generatorer, mailere, partials, template-rendere som Haml, SASS, erb, osv. MM inneholder også funksjoner for caching, datahåndtering og andre viktige, men utskiftbare komponenter.

merb-plugins

I motsetning til Rails kan du i merb velge din gift. For å lagre data har du full frihet til å velge mellom merb_datamapper, merb_activerecord, merb_sequel. Noen andre viktige plugins er merb_helpers, merb_param_protection, og mange flere er på vei!

Jeg prøver å destillere litt mer fra nå av, så ikke det blir så veldig lange poster. Det er vanskelig! Ezra har sagt han skal laste opp sine slides på sin side http://brainspl.at, så det er nok verdt en titt om dere vil lese litt mer om hans talk!

Nå er det lunsj, og jeg kommer tilbake med en ny post etter (om jeg får låne en lader igjen!)