Anche quest’anno arriva Google Summer of Code.
Per chi si fosse perso le puntate precedenti, si tratta di un’iniziativa con cui Google finanzia studenti che vogliono contribuire a progetti open source. I progetti sono stati approvati da Google ma non sono necessariamente progetti di Google. Tra questi segnalo Project Hackystat. Partendo da un tool che colleziona e analizza dati di progetto (software), ci sono molte idee interessanti per estendere Hackystat: micro-blogging mashup, Ohloh mashup, semantic web, social networking, Second Life, e project video walls.
Se qualcuno fosse interessato, non solo ne ricaverebbe una bella tesi di laurea ma anche un premio in denaro offerto da Google:$4500. La scadenza per le domande di partecipazione è il 31 marzo.
Se qualcuno ci cercasse
io e Domenico siamo al workshop Ontology Engineering meets Web 2.0. Un workshop ristretto, a soli inviti, in un’atmosfera informale e tuttavia molto produttivo. Ho imparato molto e ci siamo fatti conoscere in un ambito, almeno per me, relativamente nuovo. Se son rose fioriranno.
Memo: ci servono le demo dei nostri tool in progress.
Instant chat per gruppi ad hoc
E’ consolante vedere che l’idea di fornire un supporto rapido e senza costi per la comunicazione di gruppo ad hoc non è solo una vuota idea per fare ricerca. Via Lifehacker, mi sono imbattuto in due applicazioni web, molto simili tra loro (ChatMaker e Chatcreator), che promettono di creare “disposable chat rooms, no login, no sing-up required”
Instant messaging and email are great ways to quickly get ideas and notices across quickly to co-workers, but sometimes an actual, real-time chat session can save you time on replies and confusion. ChatMaker & Chatcreator are free web chat applications, instantly create online chat rooms after you type in the name for one. Inviting others into the chat is as simple as sending them a human-readable URL, and nobody has to sign up or answer an invitation email. The chat interface is simple and familiar, but you don’t get as much flexibility and control as with more old-school solutions like Internet Relay Chat.
L’idea non è nuova. Esiste già da un po’ Campfire, ma, seppur con la stessa premessa, forniva un servizio (superiore) a pagamento.
Qui una chat di prova.
Tagging e Trac
Chi ha seguito quest’anno il corso di Sistemi per la Collaborazione in Rete ha già avuto modo di scoprire i sistemi di collaborative tagging e Trac.
Forse però non conoscete TagsPlugin, un plugin di Trac per aggiungere liberamente metadati alle pagine wiki e ai ticket.
… Trac Hacks itself makes extensive use of tagging and is a good example of their use. Also, see http://lists.edgewall.com/archive/trac/2006-April/007646.html for an example of how Alec uses ListTagged to query tickets.
Agile Estimation
Stavo cercando qualche informazione in più su come pianificare, in un progetto agile, le iterazioni e le user story per ogni iterazione e su come stimare i tempi. Ho trovato su YouTube il talk completo di Mike Cohn su “Agile Estimation” fatto a Marzo del 2007. Vale la pena ascoltarlo anche se è lungo 90 minuti.
Parte I
http://www.youtube.com/watch?v=fb9Rzyi8b90
Parte II
http://www.youtube.com/watch?v=jeT0pOVg0EI
Da qui potete scaricare le slide del talk.
Inoltre, molto interessante è anche questo post di Mike Cohn sugli Story Points. Lui ritiene che non dovrebbero essere usati come misura di produttività:
Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point when trying to decide between calling something “two points” or “three points” […]
My view is that points can be used as the best way to estimate and assess progress that we’ve ever had or they can be used as another weapon with which to hit the team […]
E ci sono tanti altri post interessanti sul suo blog, come questo:
A common source of confusion on agile teams occurs when the sprint (“iteration”) backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units.
In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out.
In release planning the team can choose between “ideal days” and “story points”. Regardless of which they choose, they still do sprint planning in hours […]
[…] I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term […]
SWAP 2007 @ Uniba
Durante il corso di Sistemi per la collaborazione in rete, alcuni studenti hanno espresso l’interesse nel partecipare a SWAP 2007 (Semantic Web Applications and Perspectives), il workshop sul semantic web che si terrà presso Uniba dal 18 al 20 dicembre.
Nonostante il termine ultimo per la registrazione on-line sia ormai passato, gli studenti interessati sappiano che è possibile la registrazione on-site, pagando in contante 20€. Tale somma copre l’accesso a tutte le sessioni e i tutorial del workshop, inclusi i coffee break.
I piu’ veloci di voi riceveranno anche, come gadget, la copia cartacea dei proceeding (dovreste sapere cosa sono ormai…) e una borsa (disponibili fino a esaurimento scorte).
The Semantic Web and Social Web are essentially compatible
E’ il microscopico abstract di un ottimo articolo introduttivo appena pubblicato su Computer da Alexander Mikroyannidis, dell’università di Leeds. Vale la pena leggerlo.
Frederick Brooks, Jr. at OOPSLA 2007
Ultimo reportage da OOSPLA, con un po’ di ritardo per non pesare troppo sui lettori.
Collaboration and Telecollaboration in Design
Frederick P. Brooks, Jr. (University of North Carolina at Chapel Hill)
Qualcuno osa chìedere chi è Fred Brooks? Questa volta vi accontento.
Brooks distilled the successes and failures of the development of Operating System/360 in The Mythical Man-Month: Essays in Software Engineering, (1975, 20th Anniversary Edition, 1995). He further examined software engineering in a 1986 paper, No Silver Bullet. He is a member of the National Academy of Engineering, the National Academy of Science, and the American Academy of Arts and Sciences. He has received the ACM A.M. Turing Award, the IEEE John von Neumann Medal, the IEEE Computer Society’s McDowell and Computer Pioneer Awards, the ACM Allen Newell and Distinguished Service Awards, the AFIPS Harry Goode Award, and an honorary Doctor of Technical Science from the Swiss Federal Institute of Technology
Il design engineering, a differenza dell’arte, è un lavoro di team. Perché? Ci sono aspetti sempre più sofisticati anche nei prodotti più semplici. Tuttavia i grandi progetti di ingegneria sono ancora oggi il lavoro di una, al più due menti. Si ha così l’integrità concettuale.
Brooks mostra una tabella con a sinistra linguaggi e sistemi disegnati da una sola persona e a destra quelli disegnati da un processo di gruppo. Solo i primi hanno il loro fan club.
Il problema è: come ottenere integrità concettuale con il team design. Il design non può essere il prodotto di una negoziazione. Ci vuole un chief designer e per grandi sistemi un chief architect. Anche l’interfaccia utente richiede un solo user-interface designer (es. Google). Per preservare l’integrità concettuale le assunzioni devono essere documentate:
“better to be wrong than silent or vague”
Brooks cita The Cathedral and the Bazaar con Unix costruito da gruppi diversi e l’early bug detection come risultato dell’enorme scala del testing. La posizione di Brooks è che il modello del bazaar è basato sul gift e funziona quando gli sviluppatori sono i clienti stessi: conoscono così i requisiti in base alla loro esperienza personale. Costruireste mai un sistema di controllo del traffico aereo? Attenzione alle generalizzazioni errate, quindi.
Ma quando la collaborazione aiuta? Aiuta nel caso dell’esplorazione concettuale (alternative radicali, brainstorming) ma non nel conceptual design né nel detailed design. E il pair programming? E nei design review? I review sono collettivi, il design no. Il design è un processo prevalentemente per il singolo individiuo mentre il review è un processo di gruppo condotto in modo iterativo.
Il messaggio che Brooks vuole trasmettere è:
Low tech often suffice
I documenti condivisi sono il fattore più importante. Poi la voce. Quando unsare la videoconference?
- When issues vital to one or more players
- When people are insecure
- When interviewing strangers
- When organization or national cultures are very different
Freb Brooks conclude dicendo che cI sono pochi studi di telecollaboration in design.
Ward Cunningham at WikiSym 2007
Non domo, altro post sulla trasferta a Montreal. Anche questo post è dedicato a Mario: che lo legga.
“Agile Trust, Wiki Nature, and Business Logic Futures”
C’è qualcuno che non sa chi è Ward Cunningham?
Ward Cunningham ha fatto una stretta analogia tra metodi agili e wiki: entrambi sono basati su un feedback loop molto rapido. E’ grazie alla rapidità dei cicli di feedback che si stabilisce fiducia (trust) in un rapporto economico a due (ha citato un paper su Science in proposito).
Dopodichè il talk è stato tutto sul TDD, test-driven development. Lui veramente ha detto che TDD in realtà è testing for driving the design. L’obiettivo attuale che si pone Ward Cunningham è che i casi di test di accettazione possano essere capiti veramente da tutti. In aggiunta al solito FIT, ha presentato Swim, un sistema per la presentazione User-Oriented dei casi di test. Non è che si sia capito moltissimo come funziona a parte che i diagrammi Swim sono collegati direttamente ai casi di test di accettazione. Per chi abbia voglia di capirci di più c’è un paper scritto dallo speaker. Ha anche parlato di un altro tool, Graffle, che può essere usato come complemento di Swim. Swin+Graffle formerebbero la base per “trusted programs”.
Nota a margine: sullo shuttle bus che porta in aeroporto io e Fabiolino avevamo di fronte lo speaker in questione. Nessun aneddoto gustoso da aggiungere.
SL at OOPSLA 2007
Continuo con i reportage dalla conferenza. Mi rimane il dubbio su quanto interessino. Nel dubbio continuo.
Second Life: The World’s Biggest Programming Environment – Jim Purbrick , Mark Lentczner
Dr Jim Purbrick has both academic and industry experience in designing and building virtual worlds. At Nottingham University he worked on the MASSIVE-3 virtual environment system and Prix Ars Electronica-winning mixed-reality games with IGDA award winners, Blast Theory. In industry Jim designed online games at Codemasters, developed networking and load balancing technology for Warhammer Online, and is currently working on scripting and networking technology for Second Life while setting up Linden Lab Brighton.
Mark Lentczner directs a software engineering studio at Linden Lab. His studio is primarily focused on the architectural extension of Second Life and the software infrastructure to support its expansion to Internet scale. He appears in Second Life as “Zero Linden”. Mr. Lentczner has worked in Silicon Valley for over 20 years, leading engineering teams on projects including virtual machines, software tools, cell phone browsers, and audio processing. He held leadership positions at Apple Computer, OpCode Systems, and Go Corporation before running his own consulting firm for a decade. He is a graduate of Harvard with a degree in Applied Math and Music