giovedì 8 agosto 2013

Dev della settimana: Jim Uccello

Ogni settimana qui e nella nostra newsletter, ci presentano un nuovo sviluppatore / blogger dalla  comunità DZone di raggiungere e scoprire che cosa lui o lei sta lavorando ora e quello che accadrà dopo. Questa settimana, stiamo parlando di Jim Uccello : agilist, esperto di sicurezza del software, e CTO. I suoi post più recenti di DZone includono:

       
  • Agile Development conduce al morbo di Alzheimer 
  • Mantenere Software Sucks - e quello che possiamo fare a questo proposito  
  • Design Patterns dopo disegno è fatto 
  •    
Grazie per aver parlato con noi, Jim! Che cosa hai lavorato ultimamente?
Stiamo rendendo disponibile un importante aggiornamento hardware, quindi la mia attenzione oggi sta diventando di sviluppatori, tester e ops lavorano insieme molto da vicino, e un sacco e un sacco di revisioni operative e test per assicurarsi che abbiamo ottenuto tutti i dettagli coperti.
Il tuo blog è molto di sviluppo Agile. Che cosa, a voi, è il più importante principio di Agile?
Sia che si sta facendo Scrum, XP, Kanban, erogazione continua, distribuzione continua, o qualsiasi altra cosa, tutto inizia con la rottura di lavoro in piccoli pezzi e dare di più spesso. Una volta che si decide di lavorare in questo modo, tutto cambia perché deve, al fine di tenere il passo con il ritmo più veloce. Persone devono comunicare sempre più spesso con l'altro e con il cliente e con ops. Dovete automatizzare più, soprattutto test e implementazione. Devi cambiare il modo in cui gestire le persone, il modo in cui si pensa, e il modo di gestire i rischi. Anche il modo in cui la vostra organizzazione è strutturata cambia o dovrebbe cambiare. Agilità - nel modo in cui le persone pensano e lavorano - esce di lavorare più piccolo e più veloce.
Ci sono dei particolari strumenti di sviluppo o le risorse non si potrebbe vivere senza?
Troppi programmatori oggi non sono ancora approfittando di strumenti di analisi statica per aiutarli a catturare gli errori di codifica e codice mal scritto. Se si sta programmando in Java, almeno provare Findbugs, o, meglio, qualcosa come Sonar, che integra Findbugs e un mucchio di altri strumenti di analisi statica come PMD ecc Questi strumenti - e dei prodotti commerciali più lussuosi e più costosi come Coverity, Klocwork o Fortificare - cattura reali problemi di codifica che sono difficili da trovare in fase di test o anche le revisioni del codice o dell'accoppiamento, e sono facili da usare e integrare.Non ha senso di non usarli.
Avete un progetto open source preferito (o progetti) che hai contribuito alla recente? 
Mi interessa molto di come il software deve essere progettato e costruito e soprattutto su come progettare e costruire software sicuro e resistente. Contribuisco dove posso per OWASP progetti come la serie di Cheat Sheet, che è una delle migliori risorse per gli sviluppatori che vogliono capire di più su problemi di sicurezza delle applicazioni e come costruire software sicuro.
Vuoi seguire nessun blog o feed di Twitter che consiglia agli sviluppatori?
Oltre a ciò che si può trovare su DZone, naturalmente, ci sono alcuni blog che seguo regolarmente.Se davvero a cuore scrivere buon codice, controlla i blog di Michael Feathers '. Sono davvero impaziente di suo prossimo libro sul refactoring Brutal. Gli sviluppatori hanno bisogno di capire di più su DevOps, e una delle persone migliori per imparare da DevOps è John Allspaw a Etsy - controlla il suo blog Cucina Sapone . Egli è uno dei più profondi pensatori in questa zona, e una delle più pragmatico.
Per consigli sulle principali sviluppatori, mi piace Rands in riposo .
Per lo sviluppo Agile, alcune delle cose migliori si possono trovare presso Answers leader Mike Griffiths '
Mike Cohn sta riuscendo con Agile .
Io non sono sempre d'accordo con tutto ciò che questi ragazzi scrivono, ma sono intelligenti e hanno un sacco di esperienza e sono da seguire.
Hai avuto una codifica primo amore - un programma particolare, gadget, giochi o la lingua che si trova sulla strada per la vita come un Developer?
Ho passato un sacco di tempo a gestire le questioni tecniche e di business di oggi quindi non ho codificato in un istante. Ho avuto in codifica accidentalmente molto tempo fa. Ho iniziato a lavorare in ops, e ha avuto problemi con alcuni degli strumenti che stavamo usando. Così sono uscita manuali per i compilatori e debugger, e mi ha insegnato come programmare in modo da poter sistemare quello che avevamo e scrivere alcuni strumenti migliori. Poi ho deciso di andare a scuola per imparare a fare questo in modo corretto. Ho programmato in un sacco di lingue, e sono probabilmente uno solo di una manciata di persone nel mondo che hanno mai lavorato in un linguaggio fresco chiamato Splash!, Che è stato utilizzato negli anni '90 per colmare strumenti di programmazione di sistema su HP hardware.

Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.