giovedì 2 settembre 2010

Battleship AI coding-competition: date e regole del gioco



La coding-competition comincerá il 20 settembre con la pubblicazione del codice del framework che contiene l'interfaccia che ogni algoritmo di Battleship iscritto alla competizione dovrá implementare.

La competizione sará in 2 tornate:
1^ tornata, consegna del codice entro il 10 Ottobre
2^ tornata, consegna del codice entro il 31 Ottobre








Regole del gioco Battleship:
  1. Si gioca su una griglia 10x10.
  2. Ogni giocatore dispone sulla griglia 5 navi di lunghezza: 2, 3, 3, 4 e 5.
  3. La navi possono essere adiacenti ma non sovrapporsi.
  4. Ogni giocatore a turno spara un singolo colpo sulla griglia del suo avversario.
  5. L'avversario notifica se il colpo é andato a vuoto, se ha colpito una nave o se ha colpito e affondato una nave
    In questo ultimo caso dirá anche quale nave ha affondato e dove era posizionata.
  6. Il gioco si conclude quando tutte le navi di un giocatore vengono affondate, il giocatore avversario é dichiarato vincitore.


Regole della competizione:
  1. Lo spirito della competizione é quello di produrre il miglior algoritmo (di attacco e di difesa) per il gioco Battleship.
  2. Ogni azione che va contro lo spirito della competizione verrá valutata e potrá portare alla eliminazione.
  3. Imparare e implementare idee altrui é ok, copiare codice altrui va contro lo spirito della competizione.
  4. Giocare slealmente e interferire sul gioco del avversario va contro lo spirito della competizione.
  5. Un tempo compessivo di 4 secondi é a disposizione ad ogni giocatore per ogni singola partita.
  6. L'uso di multi-threading non é concesso.
  7. Lo sfondamento dei 4 secondi determinerá la sconfitta nella partita corrente.
  8. Qualsiasi eccezzione sollevata e non gestita determinerá la sconfitta nella partita corrente.
  9. Il codice insieme alla descrizione delle idee e strategie implementate dovrá essere inviato entro e non oltre le date indicate contattandomi attraverso i contacts di questo blog e inviandomi poi per e-mail il codice o il link da dove scaricarlo.
  10. La dimensione massima per il codice é di 1MB.
  11. Il solo requisito tecnico é l'uso del framework .Net 2.0 / 3.5.
  12. L'algoritmo (di attacco e di difesa) proposto dovrá implementare l'interfaccia IBattleshipOpponent definita nel codice fornito.


Punteggio:
  1. Ogni partecipante si scontrerá con ogni altro partecipante al meglio di 501 partite su 1000
  2. La prima metá dei partecipanti con i risultati migliori parteciperá alla prima o alla seconda tornata parteciperá a un torneo a eliminazione diretta per determinare il vincitore
  3. I risultati insieme all codice e le idee e strategie implementate saranno postati su questo blog.


Tags :   |

posted @ giovedì 2 settembre 2010 16.56 | Feedback (3)

martedì 31 agosto 2010

Prima di voler cambiare gli altri...


Il coach Agile e lo Scrum Master nell'azienda hanno il compito di promuovere e guidare il cambiamento organizzativo e culturale e condividono questo compito con ogni membro di un team Agile che é un agente del cambiamento.


Quello che nel tempo ho imparato in questo ruolo, é che prima di chiedere agli altri di cambiare é importante essere capaci di cambiare se stessi. E' il classico lead-by-example ed é anche un reality-check personale per verificare se si conosce realmente quello che si desidera insegnare agli altri!


Fatto questo, ho imparato che non basta ancora. Prima di chiedere agli altri di cambiare é conveniente assicurarsi di andare con le persone giuste, essere in team con i propri simili. Si perché l'obiettivo é scrivere software di successo, non "evangelizzare" il mondo sui metodi Agili. Ecco dei suggerimenti interessanti:


Tags :   |  |  |  |  |  |  |
posted @ martedì 31 agosto 2010 19.35 | Feedback (0)

Un salutare bagno di umiltá



Ho collegato 2 post che ho letto recentemente e...

Il primo riporta il risultato di una ricerca secondo cui una coppia in pair "batte" 2 individui se la coppia discute liberamente dei loro disaccordi in particolare di quanto sono confidenti della loro decisione. Mentre la coppia "perde" quando una persona é incompetente su un argomento senza esserne consapevole o senza riconoscerlo.


Il secondo riporta il risultato di una indagine secondo cui ogni anno un inglese in media spreca 2000 sterline di carburante perché sbaglia strada e non chiede informazioni. E il 41% dei maschi dopo aver sbagliato strada e dopo  essersi perso é ancora convintissimo di sapere dove sta andando.





Cioé essere ignari delle proprie incompetenze e sopravvalutare le proprie competenze ha conseguenze tangibili e negative sulla prestazione del team. E non é affatto un evento raro.




Infatti é conosciuto come l'effetto Dunning–Kruge quando una persona non skillata prende decisioni sbagliate e giunge a conclusioni errate ma la sua incompetenza gli impedisce di riconoscere l'errore. Cosi persone non skillate sopravvalutano i propri skill e persone molto skillate invece tendono a sottovalutarli.



Per i team e i developer Agili ecco 3 semplici e veloci reality check-point:




Tags :   |  |  |  |  |  |
posted @ martedì 31 agosto 2010 15.09 | Feedback (2)

venerdì 27 agosto 2010

Simplify packaging to speed up software developments


Once the team wrote the source code of an application, why should split that app into many modules (assembly, jar, dll, exe, binaries in general) ?

Sometime there are no choices: i.e.
  • when different part of the applications are developed with different technologies that require different compilers or even different operative systems.

Some other time when a group of classes are used by 2 or more applications, instead of duplicating the classes they must go in a module and be reused. Here is when the REP come in use:
REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.



In all the other cases, splitting classes in modules up-front without an concrete actual needs just
  • increase the complexity: when classes are grouped in different projects they are harder to find and it become easier to duplicate existing functionality by mistake, plus the dependency graph grow more and more complex

  • increase the build time: merging 70 small projects in 5 big projects with Visual Studio reduced build times by 40%

  • does not bring any advantage: when classes that are changed and released together and are coupled together, splitting them in many modules will not reduce coupling and will decrease cohesion (fyi: namespaces should be used to logically group classes instead of projects).
Here is where CCP and CRP come:
CCP The Common Closure Principle Classes that change together are packaged together.
CRP The Common Reuse Principle Classes that are used together are packaged together.





posted @ venerdì 27 agosto 2010 15.15 | Feedback (0)

Prova sul campo di NDepend v3 (2/2)



Ho proseguito la prova sul campo la nuova versione di NDepend v3  con le metriche del codice, con CQL e il suo editor.

Con la SuperSolution, cioé la soluzione che include centinaia di migliaia di righe di codice e tutti i progetti della azienda per cui lavoro.








Metriche: 
  • Pratica e concreta la possibilitá di avere facilmente a disposizione lo stato della coverage dei test e la complessitá ciclomatica del ccodice: due indicatori importanti dello stato generale di salute della code-base.

  • Molto interessante la presenza di metriche calcolate a livello di namespace e non solo di assembly: indispensabile per i team che hanno compreso l'uso di namespace per organizzare logicamente il codice e applicano correttamente i principi di coesione e accoppiamento dei package
  • In generale ampia scelta di metriche calcolabili sul codice.

Code Query Language (CQL):
  • Migliorato in questa versione con nuove condizioni di WHERE evolute che permettono facilmente di individuare ad esempio codice non utilizzato che puo essere cancellato in sicurezza

  • Nuovo il supporto per confrontare il trend delle metriche con le versioni precedentio del codice. Cosi é possibile vedere l'andamento della code-base e ad esempio capire se la coverage o la CC sta calando o crescendo nel tempo

CQL Editor:
  • L'integrazione con l'IDE é pratica e intuitiva
  • La velocitá di risposta del Intellisense é migliorata cosi come la visualizzazione in real-time dei risultati mentre si edita la query.

  • L'intellisense pecca ancora specialmente quando si editano nel mezzo query preesistenti. Trovo piu comodo copiare e editare i molti esempi disponibili di query piuttosto che fare affidamento e lasciarmi guidare dal intellisente


NDepend: http://www.ndepend.com/Features.aspx



posted @ venerdì 27 agosto 2010 14.42 | Feedback (0)