RDS stands for Radio Data System . This is a European standard for sending digital data through the FM radio broadcasts. Among the information provided there is sufficient space for all'invio di un identificativo di 64 caratteri alfanumerici (RT) che può essere liberamente utilizzato dall'emittente. La quasi totalità delle stazioni radio utilizza questo spazio per inviare il nome della radio su cui si è sintonizzati. In alcuni casi però informazioni supplementari riguardo alle trasmissioni in corso, per esempio titolo e autore della canzone, vengono trasmesse al posto del nome. Sfortunatamente i ricevitori in grado di visualizzare tutti i 64 caratteri (per intero o grazie allo scrolling) non sono molte, la maggior parte hanno display a 8 caratteri. C'è chi allora si è ingegnato cercando di aggirare il problema. Vorrei prendere spunto da quest'idea per proporre il seguente kata.
Obbiettivo Produrre un applicazione che prende in input autore, titolo e anno di un brano musicale e che sappia inviare a un ricevitore dotato di display a 8 caratteri il testo suddiviso in parti. Le emittenti che usano questa tecnica, lasciano il testo per alcuni secondi prima di passare al successivo. Ignoriamo il tempo che passa usando il metodo RadioStation.sendNextTextOn(RadioReceiver) che a ogni chiamata visualizza il testo successivo. Requisiti - quando non c'è un brano musicale viene inviato al display il nome della radio: "SIAgile " - dopo aver inviato autore, brano e anno si invia di nuovo il nome della radio - le parole più lunghe di 8 caratteri are sent in full (some displays may have more than 8 characters) - the sum of two consecutive words plus the space is less than or equal to 8, the text is sent at once, such as "Heaven" or "I and you " - the rule is the sum of the items separately by author, title and year. You will never see "I 2009" - the displayed text is always centered, such as "Tomorrow" or "Now" . For text of odd number of characters there will be a space to the right .
In the next post my own solution in Java that I will use as comparison for the Milestone One. Anyone wishing to participate and propose solutions in any linguaggio (anche Java) è il benvenuto.
È ora di lasciarsi andare a qualcosa di più interessante che i miei fatti personali: i buoni propositi! Eh già, chi a fine anno non s'à mai detto "L'anno prossimo metto la testa a posto, lascio indietro le vecchie abitudini e cambio." E quale momento migliore della nascita del blog di SIAgile per fare progetti e porre degli obbiettivi da raggiungere poteva esserci? Devo ammettere di trovarmi un po' in imbarazzo: scrivere il mio primo blog e sentirmi esposto ai pubblici commenti è una sensazione mista tra vergogna e voglia di provarci, ma in poche parole ecco quello che mi piacerebbe fare.
Dopo anni di linguaggi a tipizzazione statica è arrivato il momento di portare nuova linfa vitale nel bagaglio delle mie esperienze. Vorrei approfittare di quest'argomento per fare la mia prima esperienza come blogger e raccontarvi il viaggio verso un mondo per me completamente nuovo: i linguaggi a tipizzazione dinamica . Nelle prossime settimane mi occuperò quindi di pubblicare un mio personale "diario di bordo" annotando i progressi. Dalla scelta del linguaggio, alle mie personali strategie di studio, passando attraverso frustrazioni e successi, per arrivare a ottenere una roadmap che possa essere seguita da chi come me vuole solo estendere la propria conoscenza.
In piena corrente agile, I will use a goal as the first kata , have been achieved at the time of being able to master his running safely without constant pauses and changes of mind. Decide what will be the next target only the completion of this.
In my next post a description of the kata of reference for the Milestone One: the ' RDS kata.
I often wonder how a programmer should enter and study the subject in the context of the application domain of his project and how much they should stay out enough not to let condition in future projects. Let me explain.
I wonder how many of us will ever be in a meeting with domain experts, who discussed at length on an issue without reaching a. And how often, on those occasions, it appeared necessary to clarify some terms (eg why. Perceive the bad feeling that some terms were being misused by some and misunderstood by others, or synonyms that appeared semantically different, and so on)? And maybe we would have liked to ask questions trivial, even trivial, so simple ... and then we have been tempted to give up do not look for a perfect " incompetent"?
But ... you have done! Reckless, heedless of danger and thirsty for understanding. A veterinary instead of simple questions. You have helped the clarity of those present and permits that they should agree in the terms and meanings, bringing more and more towards the solution to their problem. But you risked big! About
program knows how deeply we must investigate matter to produce a quality software and above all know how fast you need to be able to extract from the experts' essential, you need the program to be implemented and how quickly we must finally know how to ask the questions right, those that lead to the elimination of contradictions or uncertainty (which presents each application domain). Who also knows that the program must be able to forget quickly to avoid portas preconceptions behind and incorrect interpretations that devierebbero the ideal solution to the next person and then bring him harm.
The knowledge that we reach during this phase of learning I would call it: horizontal knowledge. That we appropriate the fundamental concepts that allow us in an analytical way to organize information and provide what little autonomy they need. Next door to the identification quest'autonomia of all those tiny details of the program has vital need. This study is no longer self-sufficient , but occurs through a process of investigation and interrogation continued pointing towards our expert-party domain (say, on-site customer ?).
I was lucky enough to work in adult development (programs and equipment) in different sectors or application domains: building automation, medical equipment, hospital, banking, insurance, pharmaceutical and e-learning. What I learned is that the faster I learn, the more I forget. Quite the contrary: the more quickly forget the old, the more I learn quickly again.
L ' critical and vigilant against the knowledge of a specific business is a fundamental aspect of our profession. If we become experts ourselves, taking possession of what I would call the vertical knowledge, to the point of being able to do without the expert (a condition all too common for those who work for a long time as a programmer in the same type of organization), would lead roles of osmosis, ie the total autonomy of programmer. (Although in some contexts there may also be).
The consequences of this "transformation" are different.
First, the expert in business starts to delegate anche la definizione delle nuove funzionalità da svolgere.
E in seguito si avrà:
un eccessivo carico di lavoro intellettuale sul personale tecnico.
errori di interpretazione nel programma.
la perdita di interesse da parte del programmatore degli aspetti di design, leggibilità del codice, e semplicità della soluzione;
degrado del livello di sostenibilità del prodotto e che noi sappiamo essere, come il punto precedente, linfa vitale del software, nel genuino interesse economico del committente.
un inesorabile ridimensionamento dell'importanza della formazione tecnica e della sperimentazione di nuove idee, nuove tecnologie e nuove indagini e tecniche di sviluppo del software;
la compromissione dell' innovazione nell'azienda o della capacità evolutiva del prodotto in un contesto di mercato fortemente concorrenziale .
l'implicita promessa di carriera , nei confronti del programmatore, che si basa maggiormente sulla conoscenza verticale del dominio e non, come dovrebbe, sulla sua capacità di comunicazione, risposta al cambiamento, programmazione, disciplina e innovazione.
la perdita di assunzione delle responsabilità in maniera distinta tra coloro che definiscono cosa bisogna fare e con quale priorità, rispetto a coloro che devono definire come e in quanto tempo (si pensi al planning game).
il potere persuasivo esercitato dal personale tecnico che dimostrano di possedere conoscenza verticale, ossia padronanza profonda del dominio applicativo, sulla reputazione del programmatore all'interno dell'organizzazione. Fattore controproducente sulle performance nello sviluppo del software, perché svilisce la nostra difficile professione e degrada nel tempo le prestazioni di sviluppo e la qualità del prodotto del cliente.
infine dall'invito implicito al programmatore ad imparare a new job, if he cared to earn more . (What a waste of know-how!)
How often is job for specialists in which the company is looking for personnel who have expertise in the application domain of the company that publishes it?
This pushes more and more the programmer to specialize in a particular business .
I believe in our work are those who are seduced by the horizontal domain knowledge, they risk losing flexibility of not being able to change color as the chameleon where the context so requires, or capacità di penetrare la materia rapidamente , facendo l'interesse del proprio cliente e dell' utente che si troverà confrontato 9 ore al giorno e per anni con il prodotto del suo lavoro di Programmatore.
Accountability in software development è uno degli articoli più interessanti che parlano di etica nella produzione del software. Le parole di Kent Beck rappresentano molto bene anche le mie convinzioni su questa bella professione . Ho pensato che valesse la pena leggere questo lungo e piacevole testo in lingua italiana. Buona lettura.
"Una volta un contadino intervistò un ragazzo per un lavoro come bracciante in fattoria. Il ragazzo disse una cosa che lasciò particolarmente perplesso il contadino: 'io posso dormire quando soffia il vento'. Il contadino non sapeva cosa egli intendesse, ma il ragazzo sembrava competente ed quindi fu assunto.
Qualche mese dopo il contadino venne svegliato nel bel mezzo della notte da una tremenda bufera. Preso dal panico, corse verso la branda dove trovò il bracciante quasi addormentato. Scuotendolo brutalmente per svegliarlo, gli disse:
'Dobbiamo far rientrare gli animali!'. 'Sono già dentro.'
'Dobbiamo chiudere le finestre.' 'Sono già chiuse.'
'Dobbiamo ricoprire il fieno.' 'Già fatto.'
Dopo che i suoi timori fossero calati ed essere stato rassicurato che tutto era al suo posto, il contadino finalmente comprese il senso di quella misteriosa frase. Avendo cura di terminare ogni lavoro e lasciando la fattoria al sicuro ogni notte, il bracciante poteva dormire quando il vento soffiava.
Il contadino tornò a letto e disse alla moglie ciò che aveva appena appreso. Lei sorrise con un aria d'intesa e i due tornarono a dormire, cullati dal suono della burrasca."
Lo sviluppo del software va meglio se lavoro in modo che io possa "dormire quando soffia il vento". Sono più a mio agio con me stesso e il mio lavoro, i miei clienti sono più soddisfatti dai risultati che vedono, e i miei colleghi del team possono fidarsi di me. Comunque trovo difficile raggiungere questo livello di performance con la sola forza di volontà. Mi serve il supporto, l'incoraggiamento, e la responsabilità. Ho bisogno di essere un membro di una comunità per dare il massimo. Un elemento chiave per tutto ciò è la responsabilità: impegnarsi, lavorare in modo che io ne sia orgoglioso e rendere conto sulle mie attività in modo chiaro e diretto.
When I began to talk about responsibility, I met a lot of resistance from programmers who said they hate the idea of \u200b\u200bresponsibility. They told stories such as "... and then he said: 'I consider responsible for the timing of this extension project." This is not what I'm talking about. This blame is an attempt to avoid or deflect the consequences. Blaming is a poor basis from which to work. Blaming requires that you spend time and energy to protect yourself. In an environment of blame is not appropriate to say what you do and what we do not know. Lets blame everyone concerned about those who are out there ready to catch him. All energy spending to hide could be used to interact and add value to the project. The job losses in efficiency. Accountability is a powerful basis from which to start working. Working well and seamlessly creates strong bonds. Accepting responsibility is preparing the ground for the satisfaction of a job well done. It is a pity that the word 'responsibility' is misunderstood, because it obscures a useful concept.
Responsibility may be offered, and even delegated request, but can not be forced. 'I feel responsible' does not make sense. 'You're guilty' or 'I hope that you accept the consequences' can make sense, even se sono indice di relazioni di lavoro che poggiano su fragili fondamenta. I manager possono richiedere e demandare responsabilità. Per esempio, un manager può domandare che il software sia pronto per il deploy alla fine della settimana, così che i progressi del team siano visibili. D'altro canto la responsabilità può essere offerta anche se non richiesta. "Vi posso mostrare un log di come ho speso il mio tempo la settimana scorsa' è un offerta di responsabilità.
Offro responsabilità per dimostrare la mia affidabilità e per incoraggiare me stesso a comportarmi al meglio. Per esempio, quando rendo conto alla mia sposa della questioni finanziarie, noi discutiamo su come spendere il denaro. Ci accordiamo on the objectives and principles of our finances. I appreciate her for how to really spend money. If I lose ten dollars for something useless, I would say just the way things are and wait for his answer. Having these preliminary discussions, and knowing that I will have to be accountable, help me spend my money more wisely and grow our relationship.
Likewise, when I program I offer responsibility, as a way to prove my reliability encouraging my best behavior. Pair programming (the pair programming); test-first programming (programming by writing the first test), continuous integration, daily cycles, weekly and Annual rendered visible relaxation, and estimates are one way to get public commitments and be accountable for my activities. Know to be honest and responsible influence the way I do my work, so as to know that I am hiding or concealing adversely affect the way I do my job. Take responsibility for my choice and action away the guilt. There is no shame if all you do is visible to everyone.
When I program with a colleague, makes visible my thoughts and listen to her. If you are confused, I can tell. If I do not like our design, I can tell. We are free to seek an explanation or to obtain ideas from others. If we can not reach a better solution, then we go on as best we can. There is nothing to hide in this process, no guilt, no shame.
Test-first programming is a form of responsibility, especially when practiced in its purest form where no application code was written without a test that fails first. The tests are an account of my thoughts when I program. They record the problems they consider. If a problem is not represented by a test, it is presumed not to have considered when I was planning.
Seamless integration realizes the team, every hour, of what si sta facendo al sistema. Fermarmi nel lavoro per assicurarmi che tutti i test girano, aggiunge responsabilità, così come accertarmi che, nel caso io abbia creato un problema al sistema, ne ponga rimedio prima di procedere.
Avere i cicli di pianificazione visibili offre l'opportunità di rendere pubblici gli impegni e, alla fine del ciclo, di render conto di questi impegni. Non sono molto contento di perdere tempo, di non domandare aiuto quando serve, di evidenziare un'informazione incerta, quando so che dovrò renderne conto al termine della mia giornata o della mia settimana. 'Ho perso tre giorni per non aver fissato il difetto 142 perché avevo timore di chiedere aiuto' è più imbarazzante che chiedere help.
make estimates also means taking commitments. Without estimates I do not know what is necessary to do a thing. Without some uncertainty in my plans, however, I also know that regularly not keep these commitments. Make and keep commitments is an important component in the process of creating strong bonds during development, links that will assist the team in times of difficulty.
Sometimes I'm afraid of the consequences of offering liability ('if only they knew how long it took to correct this defect, I think I'm an idiot'). Work much better as they are reliable. If you are an idiot, you better take awareness, rather than pretend it is not true. If I did my best, I have nothing to fear from scrutiny by others. If I estimate with confidence that a job will take me four months, then if someone tells me they would like to have in two months, I really candid about what they think. I respect their position without necessarily share it. I can listen to their needs, not just the words or sounds. I look for ways that are mutually beneficial to meet these needs. If I'm unsure of my estimates and my work, then "I can sleep when the wind blows."
When I see the development of work in the IT world, I see a trend towards teams and organizations that have responsabilità. Il livello 5 del CMMi ha diversi pro e contro, ma quello che effettivamente offre è visibilità. Team a quel livello dicono ciò che hanno pianificato di fare e riporteranno ciò che fanno veramente. Dopodiché essi rifletteranno su questa esperienza per migliorarsi.
Responsabilità non è semplicemente una questione di riportare i fatti. Se so che ho creato dei difetti questa settimana e riporto ciò in modo accurato, allora sono onesto, non responsabile. Non ho completato il mio lavoro in modo da conviverci serenamente. Non sto agendo in modo da costruire dei legami, legami necessari al buon sviluppo del software. Extreme Programming è un modo di lavorare. I suoi principi e le sue pratiche contribuiscono alla mia abilità di essere responsabile quando sviluppo. La responsabilità mi incoraggia a fare il mio lavoro al meglio. Resisto alla tentazione di trovare delle scorciatoie o di lasciare del brutto codice quando so che altri lo vedranno e se ne prenderanno cura.
La responsabilità è importante a diversi livelli. Essere responsabile con me stesso, anche se è si tratta solo di fare e rivedere le to-do list quotidianamente, aiuta a focalizzare i miei sforzi e ottenere soddisfazione da ciò che porto a compimento. Dentro un team, la responsabilità incoraggia la formazione di fiducia, una fiducia che libera energia da usare per raggiungere gli obiettivi condivisi invece che per proteggere il proprio giardinetto. Teams that have responsibility to their clients and their organization, they also generate confidence. When a team says "six months", but others may rely on this information and act on that information, assured that the team is pursuing a mutual interest. Some development organization has gone so far as to make publicly available their internal quality metrics, giving responsibility to the world at large to demonstrate their reliability, to communicate what they believe in what they do and encourage one to do my best.
My experience is that the more alta la mia responsabilità, quanto più esprimo i miei impegni apertamente e direttamente e riporto le mie attività, quanto più ascolto con empatia gli altri, tanto più vedo risultati migliori. Quanto più sono responsabile, tanto più sono creativo, tanto più è il lavoro che porto a termine, tanto più creo valore, tanto più apprendo velocemente, tanto più "posso dormire quando soffia il vento".
Name: Bersagliere Age: 36 Place of origin: Canosa Sannita - Chieti Location: Sementina - Canton Ticino Marital status: Single Distinguishing features: if you tell them then I should kill you ;-)
Born in the cold night of December 29, 1972, grows and went to school in the quaint village of Arbedo-Castione . Already at age preliceale shows his flair for technology, with its hard-earned cash buying a Commodore 64 . After several mishaps school decides that the study is not for him, and given the interest per l'"informatica" decide di iscriversi alla scuola più breve possibile per programmatori: il Corso in Informatica di Gestione di Bellinzona. Dopo 1 anno di studio e 3 mesi di stage lavorativo presso il Credit Suisse trova lavoro presso la Banca della Svizzera Italiana. Si tratta di un contratto a termine: 9 mesi per la conversione di codice da Natural v1 a Natural v2. Nonostante la proposta della banca di rimanere con un contratto a tempo indeterminato si accorge che la scuola forse non era così male e decide di iscriversi alla Scuola Tecnica Superiore di Lugano nella sezione Informatica. Esce dopo 3 anni di studio e nel 1997 si trova a fare il consulente per AP Soft presso una grossa banca. Dopo 3 anni di consulenza ed esperienza nel settore titoli con linguaggio Natural di Software AG , decide che la sua carriera professionale ha bisogno di una svolta e si fa assumere da GM Technologies nel 2000.
Qui inizia il cammino verso le pratiche agili: attraverso lo sviluppo in java su piattaforme J2EE (Jboss e Weblogic) e servizi distribuiti fa esperienza insieme a un team dinamico che ha voglia di crescere e imparare. Si occupa anche dell'infrastruttura della ditta quali rete, sistemi operativi (linux per la maggior parte RedHat), database Oracle e MySql. Della gestione del ciclo di vita del sofware e dell'ambiente di sviluppo, iniziando con dei semplici script ant per cvs con integrazione manuale per arrivare ai più maven with subversion and complex automated integration on the continuum.
dynamic, constantly searching for new targets and incentives, he loves everything about the good food. Passionate about fitness instructor Body Combat and Body Pump .
was born SIAgile (Swiss Italian Agile), the Agile Movement of Italian Switzerland. The
Swiss Italian region is economically very active . Services and consulting firms, banks, insurance el ' Public administration many of us to ensure a safe working and well paid. The volumes of computer products in this context does not count. All the positive words.
So what's the reason why some of us programmers, Project Manager, Software Architect, Web Designer, Graphics, Business Analyst, etc. (currently more than twenty) will arrange to meet to identify new alternatives?
Perhaps because the perception is that too much to write software to get better results? Perhaps because everyone wants to live a historic event / technique, as many are happening outside its region? Maybe because of our bureaucracy Models of Software Development we slow down the process of growing and evolving digital many external phenomena (social network as facebook, MySpace , linkedin , to name a few) are preparing us? Perhaps because the death of several projects started from the Pharaonic our lands, we have disappointed and saddened, almost convincing us that the ambition to make software that breaks is not for us? Who can say.
What is certain is that with the birth of SIAgile , some of these young professionals are finding the answers Ticino. Are organized to follow events such as Better Software . It meet to make self-training with members of Extreme Programming User Group Italians (especially with the friends of XPUG -Milan). They exchange knowledge from already published several books on the subject. They practice together in agile practices to offer more value to their business programs. Endeavor to introduce the core values \u200b\u200bof Agile Manifesto their own companies, risking collision with fear and resistance from colleagues and superiors.
What unites them is the certainty that the road taken is one that leads to greater benefits for clients, especially developers and users. The energy of these young people and professionals forse porterà anche alla rivalorizzazione di molte professionalità presenti nell'articolato settore informatico del nostro territorio , le quali a volte non godono del giusto spazio per esprimersi e farsi conoscere alla moltitudine di aziende del settore; aziende che hanno bisogno di innovazione, eccellenza ed efficienza per sfondare, dentro e fuori il nostro cantone, proprio per contrastare la concorrenza che fa passi da gigante.
Per chi vuole tenersi informato e aggiornarsi con noi, rimanga sintonizzato oppure si iscriva al nostro gruppo di discussione oppure si eserciti nel nostro Dojo .
RDS stands for Radio Data System . This is a European standard for sending digital data through the FM radio broadcasts. Among the information provided there is sufficient space for all'invio di un identificativo di 64 caratteri alfanumerici (RT) che può essere liberamente utilizzato dall'emittente. La quasi totalità delle stazioni radio utilizza questo spazio per inviare il nome della radio su cui si è sintonizzati. In alcuni casi però informazioni supplementari riguardo alle trasmissioni in corso, per esempio titolo e autore della canzone, vengono trasmesse al posto del nome. Sfortunatamente i ricevitori in grado di visualizzare tutti i 64 caratteri (per intero o grazie allo scrolling) non sono molte, la maggior parte hanno display a 8 caratteri. C'è chi allora si è ingegnato cercando di aggirare il problema. Vorrei prendere spunto da quest'idea per proporre il seguente kata. 
