Bene bene, mi distraggo un attimo e tu vedi cosa succede?
E' un po' che non seguo lo sviluppo delle interfacce Web, e all'improvviso i ragazzi di google hanno deciso che a loro l'Html sta stetto.
Con un piccolo post, niente di che, hanno annunciato che AngluarJs è uscito. Ora, a una prima occhiata sembra una bella semplificazione delle GWT, spostando davvero tutta la logica sulla pagina e permettendo una semplicità di creazione delle pagina mai vista (pensate ad un creatore di GUI). Devo ancora ben capire quali sono i meccanismi che permettono lo scambio verso i contenitori di dati, siano essi SQL, immagini, video, documenti.
Quando avrò tempo mi ripropongo di fare un esempio e saggiare un po' più a fondo la tecnologia.
Nel frattempo i commenti sono i benvenuti!
Visualizzazione post con etichetta sviluppo. Mostra tutti i post
Visualizzazione post con etichetta sviluppo. Mostra tutti i post
giovedì 14 giugno 2012
giovedì 17 maggio 2012
Node.js is cancer
Non conosco bene node.js, ma mi sembra che le argomentazioni portate a sostegno della tesi siano valide.
http://teddziuba.com/2011/10/node-js-is-cancer.html
Comments are welcome
http://teddziuba.com/2011/10/node-js-is-cancer.html
Comments are welcome
mercoledì 16 maggio 2012
NAnt, o "del compilare a mano"
Creare una libreria ad uso interno può sembrare un'operazione banale: scrivi il codice, lo testi, se gira nel tuo ambiente è tutto ok. Poi un bel giorno ti dicono: dai la libreria anche ad altri gruppi di lavoro, serve per fare la stessa cosa, mettiamo a comune il know how. E tu pensi "ok, tanto lavoriamo tutti nello stesso modo, se funziona a me funzionerà anche a loro". Ecco, non c'è pensiero più sbagliato di questo.
Recentemente mi sono trovato proprio in questa situazione: avevo una libreria sviluppata in .Net 4.0 che faceva comodo ad altri colleghi, che però lavoravano in .Net 3.5
A questo punto ti chiedi: e ora come faccio a compilare per più piattaforme? Io voglio essere il padrone del codice sorgente, ma non voglio cambiare impostazioni al progetto per compilarlo su 2 framework di riferimento.
E qui ci viene incontro NAnt, un build tool molto simile (anche nel nome) ad Ant. La cosa che più ho apprezzato di questo tool è proprio il suo gran supporto ai diversi framework, sia Microsoft che Mono (é ancora un'alternativa valida a .Net?). Per le mie esigenze ho fatto tutto a mano, verificando che i build andassero a buon fine.
Non so però dire se ci siano AddIn di VisualStudio che permettano una buona integrazione, e qualora ci fossero gradirei suggerimenti.
Recentemente mi sono trovato proprio in questa situazione: avevo una libreria sviluppata in .Net 4.0 che faceva comodo ad altri colleghi, che però lavoravano in .Net 3.5
A questo punto ti chiedi: e ora come faccio a compilare per più piattaforme? Io voglio essere il padrone del codice sorgente, ma non voglio cambiare impostazioni al progetto per compilarlo su 2 framework di riferimento.
E qui ci viene incontro NAnt, un build tool molto simile (anche nel nome) ad Ant. La cosa che più ho apprezzato di questo tool è proprio il suo gran supporto ai diversi framework, sia Microsoft che Mono (é ancora un'alternativa valida a .Net?). Per le mie esigenze ho fatto tutto a mano, verificando che i build andassero a buon fine.
Non so però dire se ci siano AddIn di VisualStudio che permettano una buona integrazione, e qualora ci fossero gradirei suggerimenti.
martedì 8 marzo 2011
giovedì 17 febbraio 2011
eXtreme Programming: le regole della semplicità
http://www.c2.com/cgi/wiki?XpSimplicityRules
Che altro dire? Magari si riuscisse a fare sempre un lavoro del genere! :-D
Che altro dire? Magari si riuscisse a fare sempre un lavoro del genere! :-D
venerdì 10 dicembre 2010
lunedì 12 aprile 2010
Visual Studio 2010
Microsoft ha ufficialmente rilasciato Visual Studio 2010, assieme al nuovo .NET Framework 4.0
E io che non ho ancora digerito il 3!
E io che non ho ancora digerito il 3!
domenica 14 febbraio 2010
jBPM4
Era un po' che non davo un'occhiata alla jBPM di RedHat.
Mi sono accorto, con gioia, che è uscita la versione 4 della versione Community.
Cosa c'è di nuovo? A me ha colpito una cosa fondamentalmente: la possibilità di interagire tramite API con il sistema.
Finalmente si ha la possibilità, da qualsiasi applicazione, di interrogare il sistema. Addirittura sono state create Api apposite per le Query. Queste API coprono la maggior parte delle necessità: per necessità più specifiche "Developers who need to write company-specific queries can of course still rely on Hibernate." alla maniera degli antichi!
Direi che questa release è un gran bel passo avanti! Son sempre più convinto che mi dovrei gingillare più spesso con quete tecnologie, aprono spazi infiniti...
Mi sono accorto, con gioia, che è uscita la versione 4 della versione Community.
Cosa c'è di nuovo? A me ha colpito una cosa fondamentalmente: la possibilità di interagire tramite API con il sistema.
Finalmente si ha la possibilità, da qualsiasi applicazione, di interrogare il sistema. Addirittura sono state create Api apposite per le Query. Queste API coprono la maggior parte delle necessità: per necessità più specifiche "Developers who need to write company-specific queries can of course still rely on Hibernate." alla maniera degli antichi!
Direi che questa release è un gran bel passo avanti! Son sempre più convinto che mi dovrei gingillare più spesso con quete tecnologie, aprono spazi infiniti...
lunedì 1 febbraio 2010
domenica 27 dicembre 2009
Spring Security: personalizzare l'authentication provider
Abbiamo già visto come gestire la sicurezza con Spring Security.
Come avevamo visto il framework si basa su una logica di authentication-manager, authentication-provider. Ci sono già alcune implementazioni pronte: molto comoda è quella in memoria, specialmente per il testing.
Altra implementazione "comoda" è quella JdbcDao. Il limite di questa implementazione è che il db da cui pescare i dati deve per forza essere fatto in un certo modo, anche se si possono specificare le query da eseguire, ma la flessibilità non è al 100%.
Mi sono quindi detto: proviamo ad implementare il mio provider.
Devo implementare l'interfaccia AuthenticationProvider che ha un unico metodo authenticate
Il metodo deve verificare che l'utente si possa autenticare e restituisce un oggetto Authentication, che porta con se lo username e le GrantedAuthority a cui appartiene, praticamente i ruoli dell'utente.
Vediamo un po' di codice...
public Authentication authenticate(Authentication auth) throws AuthenticationException {
String username = auth.getPrincipal().toString();
String password = auth.getCredentials().toString();
if (!"Andrea".equals(username))
throw new BadCredentialsException("Nome Utente non valido!");
if (!"Andrea".equals(password))
throw new BadCredentialsException("Password Errata!");
Collection gas = new ArrayList();
GrantedAuthority ga = new AndreaGrantedAuthority("G1");
gas.add(ga);
UsernamePasswordAuthenticationToken result = new UsernamePasswordAuthenticationToken(username, password, gas);
return result;
}
La cosa veramente da notare e che, lo confesso, mi ha un po' spiazzato, sono le prime 2 righe, cioè il reperimento di username e password.
Soprattutto la password non era lampante. Poi, studiando un po' di teoria, ho visto che siamo nello standard. L'oggetto Authentication viene passato in ingresso e, se tutto va a buon fine, ne viene rilasciato un'altro in uscita. Nel mio caso ho usato un UsernamePasswordAuthenticationToken, che è già a corredo del framework.
Per dare i ruoli all'utente ho usato una classe AndreaGrantedAuthority che implementa l'interfaccia GrantedAuthority.
Questa classe deve essere poi dichiarata come
security:authentication-provider ref="myAuthenticationProvider"
il tag ref indica che ci dovrà essere un bean spring fatto + o meno così
bean id="myAuthenticationProvider" class="it.andrea.AndreaAuthenticationProvider"
E' ovvio quindi che questo bean è perfettamente integrato in Spring: é quindi possibile iniettare SessionFactory e quant'altro ci possa servire per il reperimento dei dati dell'utente: io per brevità non lo ho fatto ma posso assicurare che funziona.
Da dire che così il gioco non può funzionare, perchè il nostro provider vuole anche uno UserDetailService al quale chiedere com'è fatto l'utente. Infatti il provider si è solo chiesto se l'utente era abilitato o no, non quale fosse in dettaglio il suo profilo.
Per lo UserDetailService mi riprometto di scrivere un nuovo articolo.
Come avevamo visto il framework si basa su una logica di authentication-manager, authentication-provider. Ci sono già alcune implementazioni pronte: molto comoda è quella in memoria, specialmente per il testing.
Altra implementazione "comoda" è quella JdbcDao. Il limite di questa implementazione è che il db da cui pescare i dati deve per forza essere fatto in un certo modo, anche se si possono specificare le query da eseguire, ma la flessibilità non è al 100%.
Mi sono quindi detto: proviamo ad implementare il mio provider.
Devo implementare l'interfaccia AuthenticationProvider che ha un unico metodo authenticate
Il metodo deve verificare che l'utente si possa autenticare e restituisce un oggetto Authentication, che porta con se lo username e le GrantedAuthority a cui appartiene, praticamente i ruoli dell'utente.
Vediamo un po' di codice...
public Authentication authenticate(Authentication auth) throws AuthenticationException {
String username = auth.getPrincipal().toString();
String password = auth.getCredentials().toString();
if (!"Andrea".equals(username))
throw new BadCredentialsException("Nome Utente non valido!");
if (!"Andrea".equals(password))
throw new BadCredentialsException("Password Errata!");
Collection
GrantedAuthority ga = new AndreaGrantedAuthority("G1");
gas.add(ga);
UsernamePasswordAuthenticationToken result = new UsernamePasswordAuthenticationToken(username, password, gas);
return result;
}
La cosa veramente da notare e che, lo confesso, mi ha un po' spiazzato, sono le prime 2 righe, cioè il reperimento di username e password.
Soprattutto la password non era lampante. Poi, studiando un po' di teoria, ho visto che siamo nello standard. L'oggetto Authentication viene passato in ingresso e, se tutto va a buon fine, ne viene rilasciato un'altro in uscita. Nel mio caso ho usato un UsernamePasswordAuthenticationToken, che è già a corredo del framework.
Per dare i ruoli all'utente ho usato una classe AndreaGrantedAuthority che implementa l'interfaccia GrantedAuthority.
Questa classe deve essere poi dichiarata come
security:authentication-provider ref="myAuthenticationProvider"
il tag ref indica che ci dovrà essere un bean spring fatto + o meno così
bean id="myAuthenticationProvider" class="it.andrea.AndreaAuthenticationProvider"
E' ovvio quindi che questo bean è perfettamente integrato in Spring: é quindi possibile iniettare SessionFactory e quant'altro ci possa servire per il reperimento dei dati dell'utente: io per brevità non lo ho fatto ma posso assicurare che funziona.
Da dire che così il gioco non può funzionare, perchè il nostro provider vuole anche uno UserDetailService al quale chiedere com'è fatto l'utente. Infatti il provider si è solo chiesto se l'utente era abilitato o no, non quale fosse in dettaglio il suo profilo.
Per lo UserDetailService mi riprometto di scrivere un nuovo articolo.
domenica 20 dicembre 2009
Perchè Java va bene per lo sviluppo on line "di base"
L'autore,
che è italiano e vive a Firenze come me, mi perdonerà questa traduzione all'impronta del titolo del suo post.
Mi piace il suo punto di vista: è vero, si possono anche fare le cose molto complicate in Java, ma si può anche iniziare in maniera molto semplice. Poi a complicar le cose c'è sempre tempo, come per aggiungere Unit Testing e quant'altro. E poi la cosa + importante: Java è VERAMENTE una V.M. multipiattaforma, stabile ed affidabile, e questo fa ben la differenza...
che è italiano e vive a Firenze come me, mi perdonerà questa traduzione all'impronta del titolo del suo post.
Mi piace il suo punto di vista: è vero, si possono anche fare le cose molto complicate in Java, ma si può anche iniziare in maniera molto semplice. Poi a complicar le cose c'è sempre tempo, come per aggiungere Unit Testing e quant'altro. E poi la cosa + importante: Java è VERAMENTE una V.M. multipiattaforma, stabile ed affidabile, e questo fa ben la differenza...
Linee guida per la codifica in Java
Ultimamente, forse spinto da eccesso di pignoleria, sono andato a cercarmi le convenzioni per la codifica in Java.
Eccole qua, fresche fresche (sono solo targate 1999) da Sun
Proverò ad usarle....
Eccole qua, fresche fresche (sono solo targate 1999) da Sun
Proverò ad usarle....
giovedì 10 dicembre 2009
Spring Security: primi approcci
Recentemente ho avuto il piacere, chiamiamolo così, di imbattermi in Spring Security.
Spring Securiry è la soluzione di Spring per "mettere in sicurezza" una web application.
La prima cosa da fare è aggiungere un filtro nel web.xml,
usando la classe org.springframework.web.filter.DelegatingFilterProxy
ed intercettando con quella tutte le chiamate, come ben spiegato qui.
La classe sopra citata è il wrapper che intercetta tutte le chiamate.
Per configurarlo è sufficiente editare l'ApplicationContext file: in questo modo ci si riallaccia al meccanismo di gestione di Spring per le web Application.
Scorrendo la documentazione sopra citata si vede che una minima configurazione prevede il tag http. Ora, secondo le specifiche dei files di configurazione di Spring, questo non è possibile. La spiegazione è che, semplicemente, si è usato come default namespace il tag security invece che il tag beans
Se si vuole continuare ad usare il tag beans come default, la dicitura http è da intendersi come security:http
All'interno del tag http è sufficiente specificare authentication-manager ed authentication-provider da usare. Questi due definiscono le regole con cui un utente viene riconosciuto dal sistema.
Authentication-manager contiene la lista dei provider che gestiscono il meccanismo di autenticazione. In pratica si può creare una catena di autenticazioni, ad esempio da database, via LDAP, in memoria, dove ogni authentication-provider implementa la propria logica per dire se è possibile autenticare un utente all'interno del sistema.
Ogni authentication-provider ha uno user-service, cioè un meccanismo che definisce qual'è il profilo dell'utente all'interno dell'applicazione.
Diciamo che i primi approcci su spring-security si fermano qua: interessante sarà analizzare quali sono gli authentication-provider e gli user-service già inclusi nel pacchetto e come fare a crearsi i propri.
Traduzione in inglese qui
Spring Securiry è la soluzione di Spring per "mettere in sicurezza" una web application.
La prima cosa da fare è aggiungere un filtro nel web.xml,
usando la classe org.springframework.web.filter.DelegatingFilterProxy
ed intercettando con quella tutte le chiamate, come ben spiegato qui.
La classe sopra citata è il wrapper che intercetta tutte le chiamate.
Per configurarlo è sufficiente editare l'ApplicationContext file: in questo modo ci si riallaccia al meccanismo di gestione di Spring per le web Application.
Scorrendo la documentazione sopra citata si vede che una minima configurazione prevede il tag http. Ora, secondo le specifiche dei files di configurazione di Spring, questo non è possibile. La spiegazione è che, semplicemente, si è usato come default namespace il tag security invece che il tag beans
Se si vuole continuare ad usare il tag beans come default, la dicitura http è da intendersi come security:http
All'interno del tag http è sufficiente specificare authentication-manager ed authentication-provider da usare. Questi due definiscono le regole con cui un utente viene riconosciuto dal sistema.
Authentication-manager contiene la lista dei provider che gestiscono il meccanismo di autenticazione. In pratica si può creare una catena di autenticazioni, ad esempio da database, via LDAP, in memoria, dove ogni authentication-provider implementa la propria logica per dire se è possibile autenticare un utente all'interno del sistema.
Ogni authentication-provider ha uno user-service, cioè un meccanismo che definisce qual'è il profilo dell'utente all'interno dell'applicazione.
Diciamo che i primi approcci su spring-security si fermano qua: interessante sarà analizzare quali sono gli authentication-provider e gli user-service già inclusi nel pacchetto e come fare a crearsi i propri.
Traduzione in inglese qui
domenica 25 ottobre 2009
Spring 3 e i Web Services
Leggendo la documentazione di Spring 3 si dichiara che Spring supporta 2+1 modi di esporre i Web Services:
Rimangono quindi le altre due strade e fra le due scelgo volentieri quella JAX-WS, una specifica più recente di JAX-RPC, che permette di esporre come Web Services dei semplici POJO.
Per esporli al mondo esterno basta creare una Web Application ed esporre come servlet il POJO.
Vediamo quindi come è la classe che rappresente il Web Service.
@WebService(serviceName="TestService")
public class TestServiceEndpoint {
@WebMethod
public String sayHello() {
return "Hello";
}
}
Questa classe è un banalissimo POJO con 2 annotation una che dichiara che è un webservice, dal nome "TestService" e l'altra che dice che il metodo sayHello è un WebMethod. Ovviamente queste 2 annotations hanno molti altri parametri che permettono una configurazione minuziosa di tutto il Webservice, ma per l'esempio a noi va bene così.
Esponiamo ora il WebService al mondo. Basta creare una WebApplication e nel web.xml, dichiarare il POJO come servlet.
Questo basta per avere un bel WebService. Deploiando ad esempio su JBoss (purtroppo ci vuole un container j2EE per deploiare, ma ormai sono all'ordine del giorno) il gioco è fatto.
Bene, e fin qui abbiamo usato solo J2EE, neanche una traccia di Spring.
Come possiamo fare ad integrare Spring con JAX-WS?
Basta far si che il nostro POJO (o la nostra servlet, se così vogliamo pensarla) estenda SpringBeanAutowiringSupport. Facendo così si può accedere ai bean gestiti da Spring. L'unica limitazione è che queste due "parti" (il POJO e lo Spring context) devono girare nella stessa webApplication.
La classe diventa quindi
@WebService(serviceName="TestService")
public class TestServiceEndpoint extends SpringBeanAutowiringSupport {
@Autowired
private HelloService biz;
@WebMethod
public String sayHello() {
return biz.sayHello();
}
}
L'interfaccia HelloService viene, grazie all'annotation @Autowired, gestita da Spring: questo è il punto di unione tra le due tecnologie.
Per far funzionare il tutto dobbiamo fare una modifica anche al web.xml, aggiungendo la gestione dello SpringContext.
Quindi in fondo al web.xml si aggiunge
Per la parte Spring, basta creare l'xml ApplicationContext.xml (anche qui, si usano i default per velocità)
Qui si dice appunto che la classe che implementa helloService (notare la consonanza di nome tra l'interfaccia e l'id del bean, è uno dei modi in cui Spring ricerca i bean per il metodo @Autowired) è it.ws.test.HelloServiceImpl, che ovviamente implementerà l'interfaccia HelloService.
Tutto qua, nulla di più. Facile vero?
- via JAX-RPC
- via JAX-WS
- via Spring Web Services
Rimangono quindi le altre due strade e fra le due scelgo volentieri quella JAX-WS, una specifica più recente di JAX-RPC, che permette di esporre come Web Services dei semplici POJO.
Per esporli al mondo esterno basta creare una Web Application ed esporre come servlet il POJO.
Vediamo quindi come è la classe che rappresente il Web Service.
@WebService(serviceName="TestService")
public class TestServiceEndpoint {
@WebMethod
public String sayHello() {
return "Hello";
}
}
Questa classe è un banalissimo POJO con 2 annotation una che dichiara che è un webservice, dal nome "TestService" e l'altra che dice che il metodo sayHello è un WebMethod. Ovviamente queste 2 annotations hanno molti altri parametri che permettono una configurazione minuziosa di tutto il Webservice, ma per l'esempio a noi va bene così.
Esponiamo ora il WebService al mondo. Basta creare una WebApplication e nel web.xml, dichiarare il POJO come servlet.
Bene, e fin qui abbiamo usato solo J2EE, neanche una traccia di Spring.
Come possiamo fare ad integrare Spring con JAX-WS?
Basta far si che il nostro POJO (o la nostra servlet, se così vogliamo pensarla) estenda SpringBeanAutowiringSupport. Facendo così si può accedere ai bean gestiti da Spring. L'unica limitazione è che queste due "parti" (il POJO e lo Spring context) devono girare nella stessa webApplication.
La classe diventa quindi
@WebService(serviceName="TestService")
public class TestServiceEndpoint extends SpringBeanAutowiringSupport {
@Autowired
private HelloService biz;
@WebMethod
public String sayHello() {
return biz.sayHello();
}
}
L'interfaccia HelloService viene, grazie all'annotation @Autowired, gestita da Spring: questo è il punto di unione tra le due tecnologie.
Per far funzionare il tutto dobbiamo fare una modifica anche al web.xml, aggiungendo la gestione dello SpringContext.
Quindi in fondo al web.xml si aggiunge
Per la parte Spring, basta creare l'xml ApplicationContext.xml (anche qui, si usano i default per velocità)
Qui si dice appunto che la classe che implementa helloService (notare la consonanza di nome tra l'interfaccia e l'id del bean, è uno dei modi in cui Spring ricerca i bean per il metodo @Autowired) è it.ws.test.HelloServiceImpl, che ovviamente implementerà l'interfaccia HelloService.
Tutto qua, nulla di più. Facile vero?
venerdì 16 ottobre 2009
IntelliJ è ora OpenSource!
JetBrains ha finalmente rilasciato il suo famoso IntelliJ anche sotto la community edition.
La notizia qua
Ed ora, usare, usare, usare!
La notizia qua
Ed ora, usare, usare, usare!
domenica 13 settembre 2009
Mono, MonoDevelop e Gtk#
Stavo guardando Mono e MonoDevelop.
Abituato come sono a VisualStudio e allo sviluppo WinForms, ho subito cercato di fare un progetto WinForms.
Bene, ho scoperto che sotto MonoDevelop non si possono creare progetti WinForms, ma solo progetti Gtk#.
Ho anche scoperto che non esiste nessun designer pronto per applicazioni WinForms: l'unico che c'è è ancora in versione beta.
OK, no problem: vediamo come funziona lo sviluppo Gtk#, mi sono detto, sarà più o meno come quello WinForms.
Quindi, Nuovo->Soluzione->Progetto Gtk# 2.0
La soluzione viene creata, il progetto anche, ed aggiunge una classe MainWindow.cs che contiene una window di default.
Il designer è carino, gestisce bene la form.
E qui primo piccolo problema: se metto un bottone direttamente sulla form la riempie tutta... ok, ho capito, bisogna mettere un container che gestisca la posizione dei widget. Metto un FixedContainer e tutto va a posto, il disorientamento è durato veramente poco.
OK, piccola differenza ma basta farci l'abitudine. Metto un bottone, creo l'evento di Click, (Clicked si chiama in Gtk#) e provo a fare comparire un MessageBox.
Dunque, dunque, MessageBox.Show non funziona qui, chissà come sarà.... Googola che ti rigoogolo alla fine ho trovato!
Bisogna creare un MessageDialog e poi fare run!
OK, il mio primo test con Mono finisce qua. Convincere mi convince, però solo un pensiero mi attanaglia... se deve essere la versione open delle specifiche .NET, perché non implementare già da subito la System.Windows.Forms e supportarla da subito su MonoDevelop? Fra l'altro sembra anche che il porting sia completo al 100% e che funzioni anche piuttosto bene!
Se avrò tempo approfondirò i test.
Abituato come sono a VisualStudio e allo sviluppo WinForms, ho subito cercato di fare un progetto WinForms.
Bene, ho scoperto che sotto MonoDevelop non si possono creare progetti WinForms, ma solo progetti Gtk#.
Ho anche scoperto che non esiste nessun designer pronto per applicazioni WinForms: l'unico che c'è è ancora in versione beta.
OK, no problem: vediamo come funziona lo sviluppo Gtk#, mi sono detto, sarà più o meno come quello WinForms.
Quindi, Nuovo->Soluzione->Progetto Gtk# 2.0
La soluzione viene creata, il progetto anche, ed aggiunge una classe MainWindow.cs che contiene una window di default.
Il designer è carino, gestisce bene la form.
E qui primo piccolo problema: se metto un bottone direttamente sulla form la riempie tutta... ok, ho capito, bisogna mettere un container che gestisca la posizione dei widget. Metto un FixedContainer e tutto va a posto, il disorientamento è durato veramente poco.
OK, piccola differenza ma basta farci l'abitudine. Metto un bottone, creo l'evento di Click, (Clicked si chiama in Gtk#) e provo a fare comparire un MessageBox.
Dunque, dunque, MessageBox.Show non funziona qui, chissà come sarà.... Googola che ti rigoogolo alla fine ho trovato!
Bisogna creare un MessageDialog e poi fare run!
OK, il mio primo test con Mono finisce qua. Convincere mi convince, però solo un pensiero mi attanaglia... se deve essere la versione open delle specifiche .NET, perché non implementare già da subito la System.Windows.Forms e supportarla da subito su MonoDevelop? Fra l'altro sembra anche che il porting sia completo al 100% e che funzioni anche piuttosto bene!
Se avrò tempo approfondirò i test.
martedì 25 agosto 2009
Agile Development: prime impressioni
Ebbene si, anch'io ho cominciato a guardare verso il fantastico mondo dell'Agile Development.
Innanzitutto: da dove partire?
Direi proprio da qui, cioè dal manifesto per l'Agile Software.
E poi altra domanda: cos'è l'Agile Development?
Se dovessi dirlo in parole povere direi che è un processo di sviluppo software (l'ennesimo?).
In realtà sotto c'è molto di più: diciamo che è un metodo di lavoro che si può adattare a tutte le situazioni, non solo allo sviluppo software.
Questa è però una definizione molto "sfumata", che non definisce in dettaglio cosa ci si aspetta dal'Agile Development.
Facciamoci quindi un'altra domanda Quali sono i principi fondamentali?
Sempre nel manifesto sono dichiarati 12 punti fondamentali.
Ora, per chi è abituato a lavorare "alla vecchia maniera" possono sembrare devastanti, perché viene scardinata la regola base: scrivi un documento di progetto nei più minuti particolari e non muoverti di una virgola da lì!
Nell'Agile Development invece si lavora in maniera iterativa, e si aggiusta il tiro via via che si procede: attenzione però, questo non vuol dire che si debba partire dal voler fare una mela, e si finisca col fare una pera! Fin dall'inizio bisogna essere più che consapevoli di qual'è l'obbiettivo: ciò che può cambiare sono i particolari, che ovviamente emergono via via che la visione del prodotto si fa più chiara.
E' quindi molto più semplice rilasciare con cicli brevi prototipi funzionanti ed aggiornare il tiro su quelli piuttosto che scrivere tonnellate di documenti prima ed arrivare con un prodotto finito al 100% per poi scoprire che non si è centrato esattamente l'obbiettivo perchè non si erano (sia noi come team di sviluppo sia il destinatario dell'applicazione) approfonditi alcuni aspetti.
Bene, e qui finiscono le chiacchiere: prossimo passo da fare è sporcarsi le mani: voglio cioè cercare di mettere in pratica queste "regole" e vedere se sono veramente valide per me.
Ma tutto questo prossimamente su questi schermi.
venerdì 21 agosto 2009
Restare Aggiornati
Anche oggi, vista l'estrema calura, niente argomenti tecnici, o il cervelletto rischia di fondere.
Leggendo qua e la un po' di post, ho trovato un'interessante considerazione su come dovrebbe essere il mestiere dello sviluppatore software.
In breve, Jay Fields, l'autore dell'articolo, dice che un preciso dovere dello sviluppatore è quello di restare aggiornato sulle nuove tecnologie: il tempo che si dedica quindi a questa attività dovrebbe essere inserito nell'orario di lavoro, e non nel fuori orario. Un'esempio lampante è Google, con il suo 20% di tempo libero, che non è, a dire dell'autore, una novità, ma semplicemente l'accettazione di un metodo di lavoro.
Ora, premesso che concordo al 101% con l'articolo, ditemi chi qui in Italia, riesce a lavorare così. Io so solo di tanti dopocena e fine settimana passati a capire come funzionano le cose. Per l'amor di Dio, non le rimpiango, ma magari....
Iscriviti a:
Post (Atom)