Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

Share

Henrik Larsen Toft - Oppgave tittel

on

  • 379 views

 

Statistics

Views

Total Views
379
Views on SlideShare
379
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Oppdragsgiveren for det prosjektet her er Bergencentre for Computational sciences.Ofte kalt BCCS. BCCS består av 4 forskningsgrupper som alle driver med tunge beregninger.Derav er behovet stort for supercomputere, programvare og algoritmer.Videre driver disse med forskning innen feltene Bioinformatikk, systembiologi, funksjonelle gener og såkalte life-sciences.Forresten holder disse til på Høyteknologi senteret i Bergen.
  • Ok, så over til problemet.Problemet til oppdragsgiver er at de forsker på et veldig stort felt.Det er stor geografisk spredning mellom grupper og miljøer.Det er vanskelig å finne ut hvilke forskning som har blitt utført og resultater.Vanskelig å koordinere forskning.Det er ikke bare noen få kloke hoder, men veldig mange. Disse har gjerne spesialisert seg. Vanskelig å finne rett person til rett oppgave.Med andre ord så er det vanskelig å samarbeide. Samarbeidet skulle vært tettere og enklere.
  • Ok, så over til løsningen. Hvordan kan vi løse det problemet her sånn?Vel den kanskje enkleste løsningen ville vært om vi samlet alle grupper, miljøer og forskerne under samme tak. Problemet med dette er at det ikke er praktiske gjennomførbart. Pluss, blir vel kanskje en ”flere kokker mer søl” situasjon.Men selv om vi ikke gjør dette i den fysiske verden kan vi i alle fall late som. Vi kan gjøre det virtuelt i stedet.Med dette mener vi kort sagt at vi lager en eller annen form for programvare som gjenspeiler et fysisk kontor, med de ressurser som er nødvendig innen denne typen forskning.En virtuell arbeidsplass kalt eSysBio.I starten var vi 4 studenter som skulle samarbeide om å lage en prototype av dette systemet.Selv skulle jeg primært utvikle et grensesnitt mot den virtuelle arbeidsplassen som en web applikasjon. Andreas og Vegard skulle utvikle den virtuelle arbeidsplassen som en tjeneste bus hvis jeg kunne kommunisere mot.Trond skulle etter planen utvikle en webtjeneste hvis man kunne eksekvere såkalte arbeidsprosesser.Dette fungerte egentlig ikke så bra fordi at dersom vi skulle gjennomføre det på denne måten var jeg avhengig av en type top-down utvikling som innebærer at brukergrensesnittet forteller backend hva det trenger. Dette ble det ikke noe av og dermed var det umulig å utvikle brukergrensesnittet parallelt med backend.Derfor tok jeg på meg oppgaven å utvikle en light versjon av også backend. Siden det var ønskelig å tilby tilgang mot den virtuelle arbeidsplassen som en tjeneste valgte jeg å lage en slags REST hybrid løsning, men dette kan jeg si litt om senere.
  • Bare lyst å si et par ord om arbeidsprosesser også. Litt av grunnen til at man ikke kunne benytte seg av eksisterende prosjektstyrings verktøy var at man ønsker å ta i bruk Tronds motor for å eksekvere arbeidsprosesser.En arbeidsprosess er kort sagt bare steg delt prosess der output fra det ene steget blir til input for det neste.Eksempler på slike prosesser under denne konteksten er søking og sammenstilling av sekvenser. For eksempel dersom man søker et en sekvens og finner treff med minimum likhetsprosent ønsker man å vise disse i forhold til hverandre.Disse prosessene kan videre beskrives i XML og designes i verktøy som for eksempel BPEL eller Taverna.
  • Litt om bakgrunnen for de problemstillingene jeg synes passer til det prosjektet her. Og ikke minst til hva som på en måte er veldig aktuelt i dag.
  • Det første er Web 2.0Som sagt skulle jo jeg utvikle en virtuell arbeidsplass som en webapplikasjon. Derfor synes jeg at Web 2.0 var en god tankegang.Bare for å oppklare eventuelle misforståelser. Web 2.0 er altså ikke en teknologi. Begrepet er originalt definert av O’Reilly sammen med MediaLive Int. i en eller annen debatt eller noe.Poenget med begrepet er å sette et navn på endring i måten man bruker Web på. Man kan si at tideligere var web typisk slik at det var sideadministratorer som genererte innhold, mens brukere bare leste innhold.I web 2.0 er det typisk brukere som genererer innhold. Utviklere bare lager et redskap som lar dem gjøre dette på en enkel måte.Nøkkelord her er altså kollektiv intelligens, sosialt og samarbeid. Og dette synes jeg passet veldig bra til det problemet eSysBio her søker å løse.Eksempler på slik applikasjoner er: Facebook, twitter, wikipedia osv.
  • Det neste jeg har lyst å fortelle litt om er smidig utvikling og hvordan jeg har tenkt å bruke ”det”.Jeg tror det egentlig er vanskelig å si at man i et så individuelt prosjekt kan velge å følge en bestemt utviklingsprosess som for eksempel XP. Det jeg har valgt å gjøre er å se på hvordan jeg kan bruke, eller hva jeg kan bruke fra de ”smidige prinsippene” for å få svar på den jeg ønsker. Stikkord: økt produktivitet.De prinsippene jeg dermed ønsker å følge er:Tidlig fungerende kode.Håndtere endring i krav.Motiverte personer vil jo i dette tilfellet være først og fremst meg selv. Innebærer derfor en del tidligere fredager, høhø.Det å bruke fungerende kode som mål på progresjon i arbeidet.Holde programmet så enkelt som mulig, maksimere arbeidet som ikke blir gjort. Dette skal jeg også si litt om senere. Men KISS KISS.
  • Det siste jeg tenkte å fortelle noe om i forhold til bakgrunnen er Ruby on Rails.Ruby on Rails er altså et åpenkildekode rammeverk for utvikling av webapplikasjoner i programmeringsspråket Ruby. Ruby er også åpenkildekode.Ruby er utvikliket av YukihiroMatsumoto.Det er et relativt nytt programmeringsspråk, sluppet i 1995. Videre er det dynamisk typet og veldig fleksibelt.Det ble også laget med tanke på at det skulle være naturlig.Ruby on Rails rammeverket har stort fokus på å følge konvensjoner og dermed maksimere arbeid man ikke trenger å gjøre.Det har i de senere par årene blitt veldig populært og det sies å være smidig. Men dette kommer jeg litt mer tilbake til senere når jeg skal snakke om hvorfor jeg valgte Ruby on Rails.
  • Så over til de problemstillingene jeg har prøvd å fokusere på i min oppgave.
  • Det første, som er nevnt allerede i tittelen på den her presentasjonen er hvorvidt harmoni mellom metodologi og teknologi, i det her tilfellet rammeverk eller Rails om du vil, kan gi økt produktivitet.Det neste jeg ønsket å se litt på var hvordan Web 2.0 var en løsning på problemene beskrevet tidligere og hvorfor.Av mer sånn tekniske spørsmål ønsket jeg å se på hvordan moderne teknikker og teknologier som REST og AJAX kunne brukes for å øke brukervennligheten i eSysBio. I tillegg ønsket jeg å gjøre en evaluering av Ruby on Rails som sådan.
  • Så hvorfor valgte jeg Ruby on Rails. Har jo sagt litt om dette tidligere, men tenkte å ta den debatten litt opp igjen allikevel.
  • Som dere kan se er det en jungel av rammeverk der ute til en jungel av programmeringsspråk. Å betrakte alle ville være umulig. Derfor valgte jeg egentlig å prøve å ta en hurtig objektiv evaluering av et fåtall av disse av ulik årsak.Når jeg først fattet interesse for webapplikasjoner var når jeg brukte Spring rammeverket sammen med Hibernate for database tilgang. Dette synes jeg egentlig var ganske kult, men tidvis var det ganske tungvindt. Spesielt mapping mellom database og objekter som ble gjort i XML. Utover dette var det også mye XML. Men siden jeg kunne det fra før av synes jeg det var en naturlig kandidat.JSF var liksom det siste nye. Laget av Sun selv. Man skulle jo tro at dette var ganske bra så dette ble det andreRuby on Rails hadde jeg vel egentlig bare hørt om av en kamerat og lest litt om på nettet. Hadde så vidt kjørt gjennom demoen på hvordan man lager en blog på 15 minutter. Det tok 10. Derfor var også dette et ganske naturlig valg.Derfor sammenlignet jeg disse 3: Ruby on Rails, Java Server Faces og Spring.For å finne ut hvilket rammeverk jeg skulle bruke i det her prosjektet ønsket jeg å gjøre en sammenligning av flere. Men det finnes et hav ulike rammeverk for web applikasjoner til et hav av ulike programmeringsspråk. Å gjøre en fullgod sammenligning av alle disse i forhold til smidig utvikling vil i praksis være umulig. I alle fall for dette prosjektet og på innenfor denne tidsrammen. Derfor valgte jeg kun å gjøre en veldig overordnet sammenligning mellom kun et fåtall rammeverk jeg hadde litt kjennskap til fra før eller hadde hørt om i en eller annen sammenheng. De jeg da endte opp med var Java Server Faces, Spring og Ruby on Rails.Den kanskje største fordelen med Spring og Java Server Faces var at de var skrevet til et programmeringsspråk jeg allerede var kjent med. I Mod250 et par å tidligere hadde jeg til en viss grad lært meg å bruke Spring rammeverket sammen med Hibernate og synes egentlig denne kombinasjonen var ganske bra. Men jeg valgte allikevel å forfølge Ruby on Rails nettopp fordi dette er omtalt som et smidig programmeringsspråk og kunne gjerne tenke meg å se nærmere på dette, selv om det innebar at jeg måtte lære meg et nytt programmeringsspråk. -Tanken er at hvis jeg kunne alle disse gteknologiene, hvilken ville jeg valgt for å løse dette problemet.-KISS-Ikke velg teknologi for teknologi, men velg for å løse et konkret problem.-Valgt rammeverk med tanke på å finne det enkleste som kan løse det problemet jeg skulle løse.
  • Det jeg egentlig fant ut her var at Rails hadde flere Buzz-words enn de to andre til sammen.Neida, men her har jeg altså listet opp noen stikkord om hver av de. Det er sikkert mye mer til disse en det jeg har sagt her, men det var liksom dette som kom fram i starten da.Skal ikke lese opp alle disse her sånn, men poenget er vel at det som fikk meg til å helle mer mot dette er at jeg leste i boken ”Agile Web developmentwith Rails” at Rails i seg selv var smidig og dette var jo interessant. Dessuten viser faktisk at Rails er mer populært enn noen av de to andre dersom man skal tro på GoogleSearch Trends. I tillegg er jeg også glad for at Rails alltid for en plass på ”emergingtechnologies” på utvikler messer.
  • Så videre til hvordan jeg har utviklet med løsning. Skal ikke snakke så veldig mye om tekniske detaljer og lignende, men derimot prøve å holde det på et så høyt nivå som mulig. I tillegg tenkte jeg å vise noen skjermbilder.
  • Løsningen min den er ikke noe ”hokuspokus”.Den er egentlig ganske enkel. Den følger MVC ”to the bone”. Man har heller ikke noe valg dersom man bruker Rails, så det jeg prøver å si er at det er tvunget i Rails.Videre baserer løsningen seg på en ganske enkel datamodell, som sikkert også kunne vært enklere. Datamodellen er realisert i MySQL og denne koblingen krever egentlig ikke så my konfigurasjon. I alle fall ikke så mye som old-schoolhibernate folk er vant til. Dette skal jeg vise eksempel på.Videre er som nevnt løsningen min en REST hybrid. Hvilket innebærer at URLer er ganske intuitive og man har også mulighet til å velge xml framfor html, men disse har jeg ikke formatert bare som proof-of-concept liksom.Ellers har jeg balet litt med å få Rails til å kommunisere med webtjenester. Dette er ikke så enkelt fordi Ruby on Rails valgte i 2.0 versjonen å kutte innebygget støtte for webtjenester, men dette har jeg klart å løse ved bruk av SOAP4r. Dette hadde nok ikke vært så vanskelig å få til i dag når jeg kan Ruby språket.Ellers brukt litt Ajax, men prøver å ikke bruke dette for mye. Kan fortelle litt mer om dette hvis jeg har tid når jeg viser eksempel.Scaffolding er Rails sin måte å maksimere arbeidet man ikke trenger å gjøre. Dette er kort sagt en prosedyre som ved opprettelse av en ny modell kan hjelpe deg å generere det mest enkleste du trenger av kontrollere, modellen, views for å utføre CRUD (create, read, update, delete) på modellen. Analogien er at det er enklere å bygge hus når man har stilas.Tilslutt tenkte jeg bare å nevne at jeg prøvd å praktisere litt test dreven utvikling. Det er kanskje nyttig, men ikke alltid moro. Så da har jeg bare kuttet det ut 
  • Ja, når det gjelder konklusjoner og sånn så har jeg lyst å være litt forsiktig her sånn. Fordi jeg ikke har fått tid til å reflektere ordentlig over dette enda.Jeg kan si såpass som at jeg har tro på økt produktivitet, men samtidig så er nok produktiviteten blitt litt svekket pga. at jeg har måttet lære meg Rails underveis. Det som er sikkert er at det er veldig mye som blir gjort for deg i Rails og dermed går ting litt fortere. Når det gjelder ting jeg ville gjort annerledes tror jeg kanskje at det å tenke mer gjennom datamodellen på forhånd er en god ide. Så kanskje litt mer planlegging, men samtidig så har ikke kravene fra BCCS vært så klare som jeg kanskje hadde håpet på. Kunne gjerne ønske at krav hadde vært ordentlig gjennomtenkt på forhånd. Ellers så føler jeg at jeg har lært utrolig mye med det her. Jeg har og kommer til å bruke en del av dette i min nye jobb og det er jo bra.Ellers har hatt det moro med prosjektet.

Henrik Larsen Toft - Oppgave tittel Presentation Transcript

  • 1. Harmoni mellom teknologi og metodologi = økt produktivitet.
    Av Henrik Larsen Toft
    Takk til veileder: Lars-Petter Helland 
  • 2. Agenda
    Oppdragsgiver, problemet, løsningen
    Bakgrunn
    Problemstillinger
    Webrammeverk
    Utvikling av løsningen
    Refleksjoner
    Spørsmål?
  • 3. Oppdragsgiver,Problemet, Løsningen.
    Kapittel 1.
  • 4. Oppdragsgiver
    Bergen Centre for Computational Sciences
    Forskning:
    Bioinformatikk
    Systembiologi
    Funksjonelle gener
    ”Life Sciences”
    Befinner seg @ HIB
  • 5. Problemet
    Stort felt
    Geografisk stor spredning
    Uoversiktlig forskning
    Vanskelig å koordinere
    Liten oversikt over kompetanse
    Vanskelig å samarbeide
    Skulle vært tettere og enklere
  • 6. Løsningen
  • 7. Arbeidsprosess
    ATCGGCTA = ATCGGCTA ?
    Sekvens sammenstilling
    Sekvens søking
    Utføre beregninger på gen nivå
    XML
    BPEL / Taverna
  • 8. Bakgrunn
    Kapittel 2.
  • 9. Web 2.0
    Et noe diffust begrep (misforstått)
    IKKE teknologi
    Brainstorming av O’Reilly + MediaLive Int.
    Ny måte å bruke web
    Kollektiv intelligens
    Sosiale nettjenester
    Samarbeid
  • 10. Smidig utvikling
    Agile manifesto
    Tidlig fungerende kode
    Håndtere endringer i krav
    Motiverte personer (meg selv)
    Programvare mål på progresjon
    KISS (maksimer arbeid som ikke blir gjort)
  • 11. Ruby on Rails
    Yukihiro “matz” Matsumoto + David Heinemeier Hansson = Ruby on Rails
    Åpenkildekode rammeverk for Ruby
    Dynamisk
    Fleksibelt
    Naturlig / fokus på individer
    Konvensjoner
    Populært / framtredende
    Smidig
    Matz: ” Ruby is simple in appearance, but is very complex inside, just like our human body”
  • 12. Problemstillinger
    Kapittel 3.
  • 13. Problemstillinger
    Harmoni mellom valgt teknologi og utviklingsmetodologi gir økt produktivitet?
    Hvordan kan Web 2.0 brukes til å løse problemene beskrevet tidligere?
    Hvordan kan moderne teknikker og teknologier som Ajax og REST nyttes for å utvikle et mer brukervennlig eSysBio?
    Evaluering av Ruby on Rails.
  • 14. Webrammeverk
    Kapittel 4.
  • 15. Ruby on Rails
    ASP.Net
    Java Server Faces
    Groovy on Rails
    Spring
    Struts
    Play
    JRuby on Rails
    Merb
    Django
    Tapestry
  • 16. Spring
    Ruby on Rails
    Java Server Faces
    • Smidig
    • 17. Moderne
    • 18. KISS
    • 19. DRY
    • 20. MVC
    • 21. Populært
    • 22. ORM
    • 23. Konvensjoner
    • 24. Må læres
    • 25. På egenhånd
    • 26. Dokumentasjon
    • 27. Java
    • 28. Stort bibliotek
    • 29. Hibernate
    • 30. MVC
    • 31. Erfaring
    • 32. Dokumentasjon
    • 33. Komplisert
    • 34. Konfigurasjon
    • 35. Spennende?
    • 36. Java
    • 37. Stort bibliotek
    • 38. JPA
    • 39. Dokumentasjon
    • 40. Komplisert
    • 41. Overkill
    • 42. Spennende?
  • Utviklingen av løsningen
    Kapittel 5.
  • 43. Om løsningen
    Ikke ”Hokus pokus”
    MVC GP(gone pro)
    Enkel datamodell
    MySQL
    Lite konfigurasjon
    REST hybrid
    SOAP4r mot webtjenester
    AJAX
    Scaffolding
    TDD
  • 44. Database tilkobling
  • 45. Database persistens
  • 46. MVC
  • 47. Eksempel 1
  • 48. Eksempel 2
  • 49. Eksempel 3
  • 50. Eksempel 4
  • 51. REFLEKSJONER
    Kapittel 6.
  • 52. …
    Tror på økt produktivitet
    Mer produktiv når vet hva man driver med
    Datamodellen er viktig
    Skulle gjerne hatt klarere krav
    Lært mye
    Mye moro
  • 53. ?
  • 54. Referanser
    BCCS, http://www.bccs.uib.no/
    Google Trends, http://trends.google.com/
    Agile Web Development with Rails, Dave Thomas and David Heinemeier Hansson
    O’Reilly, http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html
    Agile Manifesto, http://agilemanifesto.org/
    Ruby, http://www.ruby-lang.org/en/about/
    Ruby on Rails, http://rubyonrails.org/