THINEA Webteknologi

Liten oppdatering: Har blogget litt om tankene bak Snowflake på Teknisk Blogg:

http://codecamp09.tekniskblogg.no/2010/03/09/eg…

Tusen takk for grundige og verdifulle innspill! Det er nettopp slike kommentarer jeg er avhengig av for å klare å lage et godt rammeverk.

Jeg er langt på vei enig i det du sier, og skal holde dere orientert om forbedringer som adresserer disse punktene.

Her er noen forhåpentligvis klargjørende kommentarer:

hverken “help” eller README forklarer noe om hvordan man genererer et scaffold.

Det README filen ganske riktig glemmer å forklare er at du først må laste en URL i browseren, f.eks. /shopping og deretter bruke dump-kommandoen.

Det er forøvrig bedre å se på “ShoppingAssistant.java”:http://github.com/haugeto/Snowflake/blob/master… enn InterceptedShoppingAssistant, ettersom førstnevnte har mer utfyllende JavaDoc. Dette er også forklart på “FAQ-siden”:http://wiki.github.com/haugeto/Snowflake/ jeg har glemt å linke til fra README-filen .. :P

Jeg savnet tester i shoppingassistant som kunne illustrere hva Snowflake gir av testbarhet.

Enig. Dette er på vei :)

Det ser ut til å være en viss mismatch mellom com.sun.httpserver og Servlet-API og det kan komme noen ubehagelige overraskelser når du prøver å WAR-ifisere ting i fremtiden.

Bruken av den innebygde HTTP-serveren i Java var på mange måter det som sparket igang hele prosjektet, og i begynnelsen et forsøk på å se hvor lenge man klarer seg uten noe som helst Java EE under utvikling.

Produksjonsetting er selvfølgelig noe helt annet. Jeg har med vilje utsatt utviklingen av en SnowflakeServlet (som wrapper en Snowflake-applikasjon), fordi jeg vil være sikker på hvordan den bør fungere. Foreløpig hypotese er forøvrig at man uansett vil foretrekke den innebygde HTTP-serveren under utvikling, og at Servleten kun er tiltenkt prodsetting. Det gjenstår å se om dette er hensiktsmessig (Jetty kan jo f.eks. være en alternativ utviklings- (og prod-) server)

Å bruke exceptions for validering har et problem dersom du skal støtte det at det er feil i flere felt (og det skal du vel)

ValidationException støtter faktisk rapportering av valideringsfeil for flere felt, selvom eksempelet ikke antyder hvordan dette fungerer. Jeg synes uansett eksempelet ditt på et validerings-API virker interessant. Skal kikke litt nærmere på den biten.

Nok en gang, takk for innspill! Fortsettelse følger :)

Jeg tror dette er et spennende tiltak. Jeg kjenner meg igjen i README filen:

Writing web applications with the Java EE standards can be tedious and requires a lot of paradigm shifting. From Java code to XML to JSP and back to Java. Snowflake is an attempt to cut away all the nice features of rich MVC frameworks. Instead we want to make it as easy as possible to get you in to, and keep you in high productivity flow.

Jeg tror mange av rammeverkene vi ser i dag er alt for komplekse og gjør alt for lite. Hvor lite de egentlig gjorde fant jeg først ut når jeg forsøkte gå fra servlet til database selv og så hvor lite rammeverkene faktisk hadde forenklet koden min. Tilsvarende som du gjør fra com.sun.net.httpserver.

Mitt førsteinntrykk av Snowflake er imidlertid at det mangler litt “komme i gang” dokumentasjon. README filen sier “try to write ‘help’ once you’ve started”, men ikke hvordan man starter. InterceptedShoppingAssistant inneholder er main metode som gjør noe merkelig med “help”. Men ingen kommandoer virker, “dump” sier for eksempel “No scaffold has been generated”. Og hverken “help” eller README forklarer noe om hvordan man genererer et scaffold.

Så for å gjøre Snowflake mer innbydende:

• Skriv instruksjoner i README for alle kommandoer man trenger å utføre fra utsjekk til man kan se noe spennende i webbrowseren.

Testing

Når det gjelder rammeverket, savnet jeg sårt tester. Den viktigste tingen et rammeverk kan gi til Java web-applikasjoner er en god måte å gjennomføre testing på. I prosjektet mitt nå gjør vi ting som:

ShoppingcartItemController controller = new ShoppingcartItemController(shoppingCart); controller.setRepository(fakeRepository); controller.setParameter(“product_id”, “11”); controller.setParameter(“quantity”, “-1”); View view = controller.create(); assertThat(view.getErrors(“quantity”)).isEqualTo(“must be positive”);

Altså:

• På samme tekniske abstraksjonsnivå som HTTP (‘create’ er en action som korresponderer til HTTP POST til en URL som slutter på ‘/’)
• På samme funksjonelle abstraksjonsnivå som kravene
• Uten eksterne avhengigheter, slik at testene kjører på godt under et sekund

Jeg savnet tester i shoppingassistant som kunne illustrere hva Snowflake gir av testbarhet.

Routing

Jeg liker at du har startet med routing og dispatching. At du rydder opp i dette for applikasjonen overflødiggjør veldig mye av tunge Java EE rammeverk. Jeg tror for eksempel at dersom HttpServletRequest hadde hatt Java 1.5 collections for Attributes og Parameters hadde det tatt hånd om en god del.

Her ser ting lovende, men uferdig ut. Jeg vil imidlertid oppfordre deg til å koble dette opp mot servlet-api så snart som mulig. Det ser ut til å være en viss mismatch mellom com.sun.httpserver og Servlet-API og det kan komme noen ubehagelige overraskelser når du prøver å WAR-ifisere ting i fremtiden.

Validering

Å bruke exceptions for validering har et problem dersom du skal støtte det at det er feil i flere felt (og det skal du vel). Et vellykket mønster vi vi har brukt er å si:

shoppingItem.setQuantity(request.getRequiredPositiveInteger(“quantity”)); if ( request.hasParseErrors() ) { return showCreateView(request); }

request.getRequiredPositiveInteger(“quantity”) returnerer en Integer dersom det var det brukeren skrev inn i “quantity”. Dersom brukeren skriver bokstaver eller lar feltet bli blankt, returnerer getRequiredPositive null. Man kan senere kalle request.getErrors(“quantity”) for å få tilbake feilene assosiert med dette feltet.

I Viewet kopierer vi tilbake requesten sine verdier (slik at det man skrev inn blir stående). Viewet kan også vise feilmeldingene.

Det som er ubehagelig med dette designet er at det betyr at skillet mellom Question og Answer blir visket ut. I alle fall når Question var stilt feil.

Kanskje noe tilsvarende kunne være til inspirasjon i Snowflake?

Lykke til videre. Send gjerne en ny melding her når du gjør oppdateringer.

http://xp2010.org/content.ap?thisId=68

https://agiletrain.iterate.no/

http://github.com/haugeto/Snowflake

Rammeverket er utviklet med støtte fra blant annet Kent Beck. Prosjektet er i sin spede begynnelse og trenger feedback!

Her er mitt forslag. Jeg har bevisst ikke sett på de tidligere forslagene.

Prinsippene bak det smidige manifestet

Vi følger disse prinsippene:

• Vår første prioritet er å tilfredsstille kunden gjennom tidlig og kontinuerlig leveranse av verdiskapende programvare.
• Verdsett endrede krav, selv om de kommer sent i utviklingsløpet. Smidige utviklere gjør endringer til kundens konkurransemessige fordel.
• Lever fungerende programvare ofte og kontinuerlig, mellom 2 uker og 2 måneder per leveranse. Foretrekk hyppige leveranser.
• Forretningssiden og utviklere må samarbeide daglig gjennom hele prosjektets levetid.
• Bygg prosjektet rundt motiverte deltakere. Gi dem verktøyene og miljøet de trenger, og stol på at de gjør jobben.
• Den mest effektive metoden for formidling av informasjon til og innad i et prosjekt er muntlig kommunikasjon ansikt til ansikt.
• Fungerende programvare er det beste målet på fremdrift.
• Smidige prosesser fremmer bærekraftig utvikling. Sponsorer, utviklere og brukere bør kunne holde konstant fremdrift over tid.
• Kontinuerlig fokus på teknisk kvalitet og god design fremmer smidighet.
• Enkelhet – kunsten å maksimere arbeidet som ikke utføres – er essensielt.
• De beste kravene, designene og løsningene kommer fra selv-organiserende team.
• Med jevne mellomrom reflekterer teamet over hvordan man kan bli mer effektive, og justerer oppførselen tilsvarende.

Forslag til endringer:

• “… levere et verdifullt, kjørende system tidlig og kontinuerlig.” => “tidlig og hyppig”
• “Ønske endrede krav velkommen, også selv om det er sent i utviklingen” => “Ønsk endringer i krav velkommen, også sent i utviklingen”
• “Hyppige leveranser av fungerende system” => “Lever fungerende programvare hyppig”
• Fint
• “Gi dem det miljøet og støtten”. Ville “verktøyene” være en riktigere oversettelse av “environment” her? Jeg er ikke 100% sikker på hva originalen mener.
• Fint.
• Fint.
• “en konstant fart i det uendelige” høres litt fanatisk ut. Hva med “i ubegrenset tid”?
• Resten er fint

Generelt: Prinsippene er som regel på imperativ form på engelsk. Det bør vi beholde.

Det henger greit sammen, men jeg tror fortsatt det er mye som kan forbedres – jeg vil oppforde alle til å komme med innspill!

I’d like to invite my colleagues in the agile community to the Agile Central Europe conference taking place in Krakow, Poland on the 8-9th April. Flights from Osla cost almost nothing, so I thought you might find the location attractive for meeting with other European agilists. All the information about the conference is at http://agilece.com

The call for speakers is almost closed, and we’d love to hear from thought leaders in Norway who would be interested in sharing their latest research or experiences.

Hope to see you in Krakow!

• Google Translate Version **
  Jeg vil gjerne invitere mine kolleger i fleksible samfunnet til Agile Sentral-Europa-konferansen finner sted i Krakow, Polen ved 8-9 april. Fly fra osla koster nesten ingenting, så jeg tenkte at du kanskje finne stedet attraktivt for møtet med andre europeiske agilists. All informasjon om konferansen er på http://agilece.com

Samtalen om høyttalerne er nesten stengt, og vi vil gjerne høre fra tanken ledere i Norge som ville være interessert i å dele sine nyeste forskningsresultater og erfaringer.

Håper å se deg i Krakow!

• End Google Translate **

All the best,

Paul Klipp
Program Chair
Agile Central Europe

Det har jo en verdi sett i en historisk sammenheng. Det er også en bra utgangspunkt for diskusjoner så lenge man ikke ser på det som dogma.

Absolutt enig, Niklas! Og det har jo kommet en god del forslag til tillegg og justeringer, pluss en del alternative manifester. Så spørsmålet er kanskje: Gir det noen verdi å ha en offisiell norsk oversettelse av prinsippene? Og for hvem?

Det er for all del helt ok å lage en norsk oversettelse. Jeg synes den kan ligge her, eller på Cantaras sine sider. Et manifest er jo i grunnen et relativt ikke smidig artefakt… Hvor er continuous improvement? Det smidige manifest fylte en rolle når det ble laget. Det var ikke tenkt som en “bibel”.

Hei!

Johannes tipset om følgende og ba meg starte en diskusjon her:

Det har begynt å dukke opp offisielle oversettelser av Manifesto for Agile Software Development – vel, i alle fall en svensk en: http://agilemanifesto.org/iso/sv/

Vi bør vel ikke være snauere enn at det kommer en norsk oversettelse også?

For noen år siden hadde vi en diskusjon her på forumet som endte opp med følgende “offisielle” oversettelse av Manifesto for Agile Software Development:

Vi oppdager nye og bedre måter å utvikle systemer på, ved å gjøre det selv og ved å hjelpe andre. Derved har vi lært oss å verdsette:

• Individer og samspill framfor prosesser og verktøy
• Fungerende system framfor utførlig dokumentasjon
• Samarbeid med kunden framfor kontraktsforhandlinger
• Å reagere på endringer framfor å følge en plan

Det betyr at selv om punktene til høyre er verdifulle, verdsetter vi de til venstre mer.

…så vi er allerede godt i gang.

Jeg har også (i likhet med mange fler, tipper jeg) brukt en egen oversettelse av de 12 smidige prinsippene i ulike presentasjoner. Kan vi enes om en oversettelse som vi så kan legge opp på en norsk side på manifesto.org?

Engelsk tekst på prinsippene finnes her: http://agilemanifesto.org/principles.html
Her er min oversettelse – start tøff diskusjon:

Prinsipper bak det smidige manifestet

Vi følger disse prinsippene:

• Vår høyeste prioritet er å tilfredsstille kunden gjennom å levere et verdifullt, kjørende system tidlig og kontinuerlig.
• Ønske endrede krav velkommen, også selv om det er sent i utviklingen. Smidige prosesser utnytter endringer til å gi kunden konkurransefortrinn.
• Hyppige leveranser av fungerende system, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
• Forretningssiden og utviklere må jobbe sammen daglig gjennom hele prosjektet.
• Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
• Den mest effektive metoden for å spre informasjon til og innen et utviklingsteam, er samtale ansikt-til-ansikt.
• Kjørende system er det primære målet på framdrift.
• Smidige prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde en konstant fart i det uendelige.
• Kontinuerlig fokus på teknisk høy standard og godt design forsterker smidighet.
• Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
• De beste arkitekturene, kravene og designene vokser fram fra selv-organiserende team.
• Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og så justerer det arbeidsmåten sin tilsvarende.

Noen har sikkert rett i at Scrum overselges en del, men det er vel egentlig ikke annet å vente tatt i betraktning populatiteten til dette rammeverket. Selv forsøker jeg alltid å legge vekt på: "Scrum er bare et minimalistisk rammeverk - et slags verktøy du kan bruke for å lage ...

Jeg har stor sans for det Jurgen Appelo  skriver og sier, men jeg må si jeg ble lett oppgitt når han inviterte til å engasjere seg på et NING nettverk kalt Management 3.0. Kan dette være nødvendig da? Som vanlig kom Jurgen meg i forkjøpet og svarte selv: Management 3.0 is a ...

En av de overordnede målsetningene med NAV reformen var å yte bedre service til brukerne. Alt tyder på at det har gått motsatt vei. Selv NAV-reformens far Dagfinn Høybråten påpeker dette i dagens VG. Som Høybråten selv sier er ansvaret og kompetansen i langt større grad sentralisert enn før. Det virker som alt ...

(Dette handler om smidig systemutvikling – les hele:)) Jeg kommer rett fra lørdagens faste spinning-time. Hadde tenkt å legge inn en ganske hard, men ikke for lang treningsøkt. Jeg har lært at det er viktig og ikke presse seg for hardt i treningsperiodene. De virkelig harde intervalløktene skal spares til formtoppingen. ...

Scrum sertifiseringen har vært gjenstand for en god del angrep i det siste. Spesielt CSM ble heftig diskutert på F**k Scrum seansen til Christian Braarud Hauknes på Smidig2009. Og nå sist av Per Olav Istad i papirutgaven av Computerworld. Istad sammenligner Scrum sertifisering med lureriet i Bjugn saken .. Begge ...

Det skrives og diskuteres mye om kundeverdi for tiden. Selv har jeg nylig tatt opp teamet både her og der. Noen tar til orde for at hele Agile Manifesto er feil og at Scrum er bygd på feil premisser. Bill Caputo skriver i innlegget THE DEATH OF AGILE om hvordan Agile ofte ...

Jeg tror den tiden er forbi da IT-brukere syntes det var fasinerende å stadig få levert fler og fler funksjoner knyttet til systemene. Jeg har snakket om MS Office mange ganger (bl.a. her)- som etter min mening er skrekkeksemplet på at vi for lenge siden nådde "Happy User Peak". Ytterligere ...

Jeg er veldig fornøyd med en ny printer jeg har kjøpt av typen HP C4480. Den har en liten skjerm med tre linjer med tilsvarende tre knapper, samt meny-knapp, OK og X. Den skriver raskt og presist og jeg kan uten problemer mate inn ganske stor bunke med A4 ark. ...