Causa acquisto nuovo cellulare, che richiede la Micro-SIM, e causa taglio artigianale SIM non andato a buon fine, mi reco ad un vodafone point per richiedere una nuova Micro-SIM funzionante.
L'operatrice mi richiede il cartellino con il codice fiscale.
Poi mi chiede il numero di telefono che scrivo su di un post-it.
Poi mi consegna, gratuitamente, la nuova Micro-SIM, già immediatamente funzionante.
Hey! Ma l'operatrice non mi ha chiesto carta d'identità o passaporto, nemmeno la patente, ed il codice fiscale non è un documento di riconoscimento, non ha la foto, non ha nessun sistema di sicurezza (PIN, Microchip, RFID, o quant'altro) ed è semplicemente riproducibile.
Senza controlli aggiuntivi, chiunque può richiedere una nuova SIM a nome di chiunque altro....!
12 lug 2012
PDF firmati digitalmente... alcuni appunti
Come gestire un PDF firmato digitalmente:
http://www.egov-pa.it/component/content/article/7-articoli/firma-digitale/11-come-gestire-un-pdf-firmato-digitalmente.html
deploy delle impostazioni di sicurezza:
http://blogs.adobe.com/pdfitmatters/2010/02/deploying_acrobat_to_import_se.html
come esportare/importare le opzioni di sicurezza:
http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf#page=37
okay non è un vero post, sono solo degli appunti che mi servono... intanto lo pubblico, poi se sarà... scriverò un articolo più completo.
http://www.egov-pa.it/component/content/article/7-articoli/firma-digitale/11-come-gestire-un-pdf-firmato-digitalmente.html
deploy delle impostazioni di sicurezza:
http://blogs.adobe.com/pdfitmatters/2010/02/deploying_acrobat_to_import_se.html
come esportare/importare le opzioni di sicurezza:
http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf#page=37
okay non è un vero post, sono solo degli appunti che mi servono... intanto lo pubblico, poi se sarà... scriverò un articolo più completo.
2 gen 2012
Chi è il mio CSR?
Sono sempre stato un professionista nel ricordare PIN, password, codici di accesso vari. E quando mi rendo conto che non vale la pena ricordare, so che devo scrivere le credenziali in un posto comodo e sicuro.
Ma con il SecureCode delle carte di credito MasterCard ho sempre avuto un brutto rapporto.
Oltre al codice scritto sulla carta di credito, ed oltre al codice di sicurezza stampato sul retro, alcuni esercizi commerciali su Internet richiedono, per le carte MasterCard, anche l'inserimento di un SecureCode, in pratica una password da associare alla carta. Fatto sta che la prima volta ero di fretta... inserire nuova password... confermare nuova password... nuova password inserita a caso ... pagamento andato a buon fine! Yuppy!
Ma da quella volta non me ne è più andata bene una! Grazie a dio, prima di sbagliare il codice per tre volte, è sempre possibile cliccare su "SecureCode dimenticato", inserire qualche piccolo dettaglio personale (e probabilmente noto a tutto il mondo tipo data nascita codice fiscale etc. etc.), ed inserire un nuovo codice, bello fiammante, pronto per essere scordato.
E se invece digita la password errata per ben tre volte? Io ho dovuto chiamare mia sorella, che mi ha prestato la sua di carta e meglio ancora, mi ha anche accompagnato fino in stazione dove ho preso appena in tempo il treno per Milano con il biglietto appena acquistato. Ma se non c'è così tanta fretta, a mente lucida, si telefona al numero verde scritto sulla carta, si comunica qualche dato personale, et voilà! Codice resettato, al prossimo acquisto se ne inserisce uno di nuovo (probabilmente è ciò che dovrà fare mia sorella visto che il codice che le ho inserito proprio non me lo ricordo).
Fatto sta che mentre stavo acquistando un biglietto Venezia - New York dal sito della Delta Airlines, al momento dell'inserimento del Secure Code mi esce questo inquietante e criptico errore:
Provo. Riprovo. Esco. Riprenoto. Reinserisco i dati. Cancello i moduli. Mi sconnetto e riconnetto. Ricompilo.
Sempre, consistently, lo stesso errore!
Così, non so perché, ma provo a rifare tutto utilizzando Internet Explorer al posto di Chrome. Clicco su "Secure code dimenticato" (ovvio, no? ormai non ci provo neanche più. sometimes life it's so easy!), imposto il nuovo secure code e... volo prenotato!!!
Non posso crederci. New York, aspettami!
Ma con il SecureCode delle carte di credito MasterCard ho sempre avuto un brutto rapporto.
Oltre al codice scritto sulla carta di credito, ed oltre al codice di sicurezza stampato sul retro, alcuni esercizi commerciali su Internet richiedono, per le carte MasterCard, anche l'inserimento di un SecureCode, in pratica una password da associare alla carta. Fatto sta che la prima volta ero di fretta... inserire nuova password... confermare nuova password... nuova password inserita a caso ... pagamento andato a buon fine! Yuppy!
Ma da quella volta non me ne è più andata bene una! Grazie a dio, prima di sbagliare il codice per tre volte, è sempre possibile cliccare su "SecureCode dimenticato", inserire qualche piccolo dettaglio personale (e probabilmente noto a tutto il mondo tipo data nascita codice fiscale etc. etc.), ed inserire un nuovo codice, bello fiammante, pronto per essere scordato.
E se invece digita la password errata per ben tre volte? Io ho dovuto chiamare mia sorella, che mi ha prestato la sua di carta e meglio ancora, mi ha anche accompagnato fino in stazione dove ho preso appena in tempo il treno per Milano con il biglietto appena acquistato. Ma se non c'è così tanta fretta, a mente lucida, si telefona al numero verde scritto sulla carta, si comunica qualche dato personale, et voilà! Codice resettato, al prossimo acquisto se ne inserisce uno di nuovo (probabilmente è ciò che dovrà fare mia sorella visto che il codice che le ho inserito proprio non me lo ricordo).
Fatto sta che mentre stavo acquistando un biglietto Venezia - New York dal sito della Delta Airlines, al momento dell'inserimento del Secure Code mi esce questo inquietante e criptico errore:
Your authentication could not be completed because of a system error.
If this happens consistently, please contact your CSR.
Provo. Riprovo. Esco. Riprenoto. Reinserisco i dati. Cancello i moduli. Mi sconnetto e riconnetto. Ricompilo.
Sempre, consistently, lo stesso errore!
Così, non so perché, ma provo a rifare tutto utilizzando Internet Explorer al posto di Chrome. Clicco su "Secure code dimenticato" (ovvio, no? ormai non ci provo neanche più. sometimes life it's so easy!), imposto il nuovo secure code e... volo prenotato!!!
Non posso crederci. New York, aspettami!
8 nov 2011
Google, catch 22
Cosa c'è di meglio che aprire Google per trovare una risposta, sentirsi fortunati perché Google ci porta precisamente sulla domanda di un tizio con il nostro stesso problema, e però l'unica risposta è un tizio incazzato nero che dice: ma è mai possibile? ancora questa domanda? Perché invece di continuare a farci perdere del tempo, prima di scrivere una domanda non cerchi un po' su Google?
1 set 2011
Google Italy Blog: Musica a tutto Chrome, anche in estate la tua musi...
Google Italy Blog: Musica a tutto Chrome, anche in estate la tua musi...: Stanchi della radiolina portatile, delle canzoni trasmesse in spiaggia, del numero limitato di brani sulla vostra playlist? L’estate è tempo...
29 lug 2011
Programmatori pazzi
Bene o male, ma soprattutto male, qualunque sviluppatore impara a scrivere qualche piccola applicazione per il Web.
Magari abbiamo scritto la nostra applicazione per tenere traccia delle attività da svolgere, come pagare la bolletta del metano, ricordarsi di revisionare la macchina, portare Tobia alla toelettatura per cani, consegnare un nuovo prototipo al cliente, o pagare gli alimenti per la prole alla ex fidanzata. L'accesso all'applicativo sarà previa autenticazione, e gli utenti potranno inserire i propri dati, leggerli in tabella, ricercarli, filtrarli.
Poi che cosa manca? Gli utenti, oltre ad interagire con l'applicativo Web, vorranno scaricare i dati e portarli sul telefonino, farsene una copia su chiavetta, o importarli in Excel e farci qualche piccola elaborazione.
Da qualche parte nella pagina si dovrà predisporre un link o una paginetta di download, e gli utenti, dopo aver aggiustato qualche filtro, potranno scaricare il file sul proprio client e gestirlo come preferiscono.
E quindi, il programmatore medio che cosa si inventa? Generalmente la tecnica scelta si attesta intorno a queste soluzioni:
La prima tecnica è molto limitata: come possiamo applicare dei filtri? Ma uno sviluppatore creativo è in grado di risolvere anche questo: in fondo, quanto ci vuole a creare in anticipo tutti i file con tutti i filtri possibili ed immaginabili, tutti già preimpostati?
Per la seconda tecnica, uno script con privilegi di scrittura su di una cartella che poi verrà servita tramite server HTTP è il sogno di ogni criminale informatico. Ma se proprio non ci sono altre possibilità, conviene almeno sapere che oltre al chmod 777 o all'Everyone Full Control esistono anche svariate vie di mezzo.
Per la terza ogni commento è superfluo. Posso solo giurare di aver visto anche questo!
Se però non avete notato altro, forse la sicurezza informatica non è il vostro mestiere, e probabilmente non lo sarà mai.
Il vero problema, grosso come un pilone portante del Burj Khalifa di Dubai, è che se mettiamo un file in \var\www\home\downloads\ l'utente vi potrà accedere felicemente andando al link http://www.example.com/downloads/attivita-nomeutente.dat ma oltre al nostro amico autorizzato vi potrà entrare anche tutto il resto del mondo. Certo, disabilitare il browsing delle directory è senz'altro un'idea brillante, ma non basta.
Il concetto è che al nostro Web Server non importa assolutamente nulla dell'autenticazione che abbiamo sviluppato nel nostro programma: abbiamo implementato un sistema di autenticazione per le nostre paginette Web? Bene. Abbiamo utilizzato un framework che implementa la parte di sicurezza? Meglio ancora. Ma questo sistema lo dobbiamo implementare anche per i nostri file. Solo allora possiamo servire le nostre pagine, dinamicamente, e protette dalle nostre credenziali.
(Ci sono casi in cui generare precedentemente i file da far scaricare agli utenti è cosa buona e giusta; tra l'altro il Web Server è sicuramente molto più veloce del nostro script nel servire le pagine; in questi casi però cerchiamo almeno di dare ai file un indirizzo URL casuale).
Magari abbiamo scritto la nostra applicazione per tenere traccia delle attività da svolgere, come pagare la bolletta del metano, ricordarsi di revisionare la macchina, portare Tobia alla toelettatura per cani, consegnare un nuovo prototipo al cliente, o pagare gli alimenti per la prole alla ex fidanzata. L'accesso all'applicativo sarà previa autenticazione, e gli utenti potranno inserire i propri dati, leggerli in tabella, ricercarli, filtrarli.
Poi che cosa manca? Gli utenti, oltre ad interagire con l'applicativo Web, vorranno scaricare i dati e portarli sul telefonino, farsene una copia su chiavetta, o importarli in Excel e farci qualche piccola elaborazione.
Da qualche parte nella pagina si dovrà predisporre un link o una paginetta di download, e gli utenti, dopo aver aggiustato qualche filtro, potranno scaricare il file sul proprio client e gestirlo come preferiscono.
E quindi, il programmatore medio che cosa si inventa? Generalmente la tecnica scelta si attesta intorno a queste soluzioni:
- si crea una bella crontab sul server, con una riga che viene eseguita ogni tot giorni, che crea una estrazione per ogni utente in \var\www\home\downloads\attivita-nomeutente.dat;
- la pagina di download, quando viene richiamata, inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Una volta competato il file, viene mandato in output un bel link all'estrazione appena creata;
- la pagina di download richiama un processo sul server che inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Poichè il processo è asincrono, si mette uno sleep di 5 secondi in modo da dare il tempo al processo asincrono di completare il file. Poi ci mettiamo un bel link al file appena generato.
La prima tecnica è molto limitata: come possiamo applicare dei filtri? Ma uno sviluppatore creativo è in grado di risolvere anche questo: in fondo, quanto ci vuole a creare in anticipo tutti i file con tutti i filtri possibili ed immaginabili, tutti già preimpostati?
Per la seconda tecnica, uno script con privilegi di scrittura su di una cartella che poi verrà servita tramite server HTTP è il sogno di ogni criminale informatico. Ma se proprio non ci sono altre possibilità, conviene almeno sapere che oltre al chmod 777 o all'Everyone Full Control esistono anche svariate vie di mezzo.
Per la terza ogni commento è superfluo. Posso solo giurare di aver visto anche questo!
Se però non avete notato altro, forse la sicurezza informatica non è il vostro mestiere, e probabilmente non lo sarà mai.
Il vero problema, grosso come un pilone portante del Burj Khalifa di Dubai, è che se mettiamo un file in \var\www\home\downloads\ l'utente vi potrà accedere felicemente andando al link http://www.example.com/downloads/attivita-nomeutente.dat ma oltre al nostro amico autorizzato vi potrà entrare anche tutto il resto del mondo. Certo, disabilitare il browsing delle directory è senz'altro un'idea brillante, ma non basta.
Il concetto è che al nostro Web Server non importa assolutamente nulla dell'autenticazione che abbiamo sviluppato nel nostro programma: abbiamo implementato un sistema di autenticazione per le nostre paginette Web? Bene. Abbiamo utilizzato un framework che implementa la parte di sicurezza? Meglio ancora. Ma questo sistema lo dobbiamo implementare anche per i nostri file. Solo allora possiamo servire le nostre pagine, dinamicamente, e protette dalle nostre credenziali.
(Ci sono casi in cui generare precedentemente i file da far scaricare agli utenti è cosa buona e giusta; tra l'altro il Web Server è sicuramente molto più veloce del nostro script nel servire le pagine; in questi casi però cerchiamo almeno di dare ai file un indirizzo URL casuale).
21 lug 2011
Sviluppare per il Web 2.0?
Ho iniziato a sviluppare applicativi Web aziendali, pubblicati sulla Intranet, fin dal 1998.
Al tempo l'azienda non era nemmeno collegata ad Internet, per cui non avevo ancora a disposizione una casella di posta elettronica aziendale, e le linee di collegamento tra le varie sedi distaccate erano decisamente molto lente.
La piattaforma per cui sviluppavo era Windows NT, con Internet Information Server, e gli applicativi erano realizzati con tecnologia ASP in linguaggio VBScript. Il database era spesso un Microsoft Access (dite quello che volete, ma si tratta di un prodotto miracoloso!) o, quando eravamo fortunati, un SQL Server.
Dopo pochi anni sono passato allo sviluppo per Apache su Linux, ma ho accuratamente scelto di evitare il PHP. So che il PHP è molto amato dalle comunità di sviluppo, ma quando si impara a conoscere un prodotto come ASP, passare al PHP sembra fare salto indietro di secoli. In ASP c'era un solo RecordSet, lo stesso RecordSet di Access, lo stesso di SQL Server, lo stesso di qualsiasi altro database di sistema. Non un RecordSet simile con le stesse funzioni: era proprio la stessa libreria di sistema: di per se, ASP era un sistema molto scarno, ma che si appoggiava largamente alle librerie di Windows.
Nel mondo PHP invece ogni diverso database aveva del codice diverso per essere gestito. La connessione ad un MySql era diversa dalla connessione ad un PostgreSQL, diversa dalla connessione ad un ODBC, diversa la connessione da una qualsiasi altra fonte dati. Diversa da qualsiasi connessione a qualsiasi database sviluppato per la console di Linux o per qualche applicativo client server.
(A vete intuito per quale ragione nel mondo Windows si parla di DLL Hell, mentre nel mondo Linux no? Ho il sospetto che nel mondo Linux vada di moda la riscrittura del codice piuttosto che la condivisione delle librerie... nonostante questo, avrei comunque qualche bella storia di .so Hell da raccontare!)
Per cui ho deciso che lo strumento per cui avrei sviluppato sarebbe stato il linguaggio Perl.
Non si tratta di un linguaggio per puristi, ma in fondo chi se ne importa? Ho programmato in qualsiasi cosa mi sia capitata per le mani, e l'ho trovato fin da subito un prodotto molto efficiente. E pazienza che la sintassi fosse orrenda e poco coerente: una volta abituati al VBScript, non si può che migliorare!
La cosa che mi ha convito fin subito del Perl era la sua immensa collezione di librerie, per connettersi o per gestire qualsiasi cosa (database, periferiche, API di sistema, c'era addirittura del codice per gestire il proprio account MySpace, il tutto via codice...!). Generalmente le librerie del Perl erano di buona qualità e progettate con buon gusto. Inoltre, da non trascurare il fatto che la stessa libreria che si utilizzava per sviluppare applicativi di sistema era la stessa libreria da utilizzare per lo sviluppo Web: avevo finalmente trovato la coerenza anche nel mondo Linux!
Ma soprattutto avevo trovato il miglior framework per il Web esistente sulla terra: HTML::Mason!
Il suo concetto di ereditarietà era favoloso: potevi concentrarti nello scrivere una paginetta che mostrava il contenuto della pagina, e tutto il resto, dal vestito grafico, alle connessioni al database, alle autorizzazioni necessarie, venivano ereditate secondo uno schema deciso in fase di progettazione.
Purtroppo si trattava di un sistema molto difficile da installare e da configurare (non vi sto a raccontare di tutti i conflitti di librerie di sistema per riuscire a farlo funzionare... quando inizi ad utilizzare componenti che non sono presenti in una distribuzione e sono scarsamente utilizzati, anche il mondo dei pacchetti e delle dipendenze mostra i suoi limiti) ma una volta predisposto il tutto diventava uno strumento davvero veloce per sviluppare applicazioni Web complesse.
L'ultimo applicativo che ho sviluppato era una specie di Cartella Clinica, con dati dei pazienti, variazioni anagrafiche, esami di laboratorio, esami radiologici, prescrizioni farmaceutiche, il tutto visualizzabile via Web oppure scaricabile in formato leggibile dal software del medico, previo accesso tramite utente e password.
Le fonti di dati erano MySql, Oracle, SQL Server (eh sì, vi si poteva accedere anche da Linux!), o file di testo importati tramite crontab.
Le pagine erano realizzate in XHTML, con CSS, con qualche bello spunto preso da CSS Zen Garden. JavaScript, come era giusto fare al tempo, era ridotto al minimo e si limitava a pre-convalidare i Form.
Poi si sa come vanno le cose nella pubblica amministrazione. Lo sviluppo interno viene abbandonato, e viene appaltato all'esterno. Così il mio lavoro non consiste più nel progettare e realizzare programmi, ma consiste nel riuscire a far funzionare programmi scritti da terzi, con tecniche di programmazione arcaiche e/o discutibili, e cheprobabilmente sicuramente avrei potuto scrivere meglio!
Negli ultimi cinque anni il mondo del Web è cambiato, il nuovo Web si chiama Web 2.0.
Cosa bisogna imparare per restare al passo?
Ho scelto di utilizzare il Google App Engine, questo richiede di imparare a programmare in Python ma (database a parte) tutto ciò che si utilizzava sotto Apache è ancora molto attuale. E all'autenticazione, il lato debole di ogni applicativo Web, non ci pensa più il programmatore ma se ne occupa Google!
La lista seguente serve soprattutto a me, per capire che cosa è cambiato dal punto in cui ero rimasto. Non è definitiva e la aggiornerò quando serve:
Al tempo l'azienda non era nemmeno collegata ad Internet, per cui non avevo ancora a disposizione una casella di posta elettronica aziendale, e le linee di collegamento tra le varie sedi distaccate erano decisamente molto lente.
La piattaforma per cui sviluppavo era Windows NT, con Internet Information Server, e gli applicativi erano realizzati con tecnologia ASP in linguaggio VBScript. Il database era spesso un Microsoft Access (dite quello che volete, ma si tratta di un prodotto miracoloso!) o, quando eravamo fortunati, un SQL Server.
Dopo pochi anni sono passato allo sviluppo per Apache su Linux, ma ho accuratamente scelto di evitare il PHP. So che il PHP è molto amato dalle comunità di sviluppo, ma quando si impara a conoscere un prodotto come ASP, passare al PHP sembra fare salto indietro di secoli. In ASP c'era un solo RecordSet, lo stesso RecordSet di Access, lo stesso di SQL Server, lo stesso di qualsiasi altro database di sistema. Non un RecordSet simile con le stesse funzioni: era proprio la stessa libreria di sistema: di per se, ASP era un sistema molto scarno, ma che si appoggiava largamente alle librerie di Windows.
Nel mondo PHP invece ogni diverso database aveva del codice diverso per essere gestito. La connessione ad un MySql era diversa dalla connessione ad un PostgreSQL, diversa dalla connessione ad un ODBC, diversa la connessione da una qualsiasi altra fonte dati. Diversa da qualsiasi connessione a qualsiasi database sviluppato per la console di Linux o per qualche applicativo client server.
(A vete intuito per quale ragione nel mondo Windows si parla di DLL Hell, mentre nel mondo Linux no? Ho il sospetto che nel mondo Linux vada di moda la riscrittura del codice piuttosto che la condivisione delle librerie... nonostante questo, avrei comunque qualche bella storia di .so Hell da raccontare!)
Per cui ho deciso che lo strumento per cui avrei sviluppato sarebbe stato il linguaggio Perl.
Non si tratta di un linguaggio per puristi, ma in fondo chi se ne importa? Ho programmato in qualsiasi cosa mi sia capitata per le mani, e l'ho trovato fin da subito un prodotto molto efficiente. E pazienza che la sintassi fosse orrenda e poco coerente: una volta abituati al VBScript, non si può che migliorare!
La cosa che mi ha convito fin subito del Perl era la sua immensa collezione di librerie, per connettersi o per gestire qualsiasi cosa (database, periferiche, API di sistema, c'era addirittura del codice per gestire il proprio account MySpace, il tutto via codice...!). Generalmente le librerie del Perl erano di buona qualità e progettate con buon gusto. Inoltre, da non trascurare il fatto che la stessa libreria che si utilizzava per sviluppare applicativi di sistema era la stessa libreria da utilizzare per lo sviluppo Web: avevo finalmente trovato la coerenza anche nel mondo Linux!
Ma soprattutto avevo trovato il miglior framework per il Web esistente sulla terra: HTML::Mason!
Il suo concetto di ereditarietà era favoloso: potevi concentrarti nello scrivere una paginetta che mostrava il contenuto della pagina, e tutto il resto, dal vestito grafico, alle connessioni al database, alle autorizzazioni necessarie, venivano ereditate secondo uno schema deciso in fase di progettazione.
Purtroppo si trattava di un sistema molto difficile da installare e da configurare (non vi sto a raccontare di tutti i conflitti di librerie di sistema per riuscire a farlo funzionare... quando inizi ad utilizzare componenti che non sono presenti in una distribuzione e sono scarsamente utilizzati, anche il mondo dei pacchetti e delle dipendenze mostra i suoi limiti) ma una volta predisposto il tutto diventava uno strumento davvero veloce per sviluppare applicazioni Web complesse.
L'ultimo applicativo che ho sviluppato era una specie di Cartella Clinica, con dati dei pazienti, variazioni anagrafiche, esami di laboratorio, esami radiologici, prescrizioni farmaceutiche, il tutto visualizzabile via Web oppure scaricabile in formato leggibile dal software del medico, previo accesso tramite utente e password.
Le fonti di dati erano MySql, Oracle, SQL Server (eh sì, vi si poteva accedere anche da Linux!), o file di testo importati tramite crontab.
Le pagine erano realizzate in XHTML, con CSS, con qualche bello spunto preso da CSS Zen Garden. JavaScript, come era giusto fare al tempo, era ridotto al minimo e si limitava a pre-convalidare i Form.
Poi si sa come vanno le cose nella pubblica amministrazione. Lo sviluppo interno viene abbandonato, e viene appaltato all'esterno. Così il mio lavoro non consiste più nel progettare e realizzare programmi, ma consiste nel riuscire a far funzionare programmi scritti da terzi, con tecniche di programmazione arcaiche e/o discutibili, e che
Negli ultimi cinque anni il mondo del Web è cambiato, il nuovo Web si chiama Web 2.0.
Cosa bisogna imparare per restare al passo?
Ho scelto di utilizzare il Google App Engine, questo richiede di imparare a programmare in Python ma (database a parte) tutto ciò che si utilizzava sotto Apache è ancora molto attuale. E all'autenticazione, il lato debole di ogni applicativo Web, non ci pensa più il programmatore ma se ne occupa Google!
La lista seguente serve soprattutto a me, per capire che cosa è cambiato dal punto in cui ero rimasto. Non è definitiva e la aggiornerò quando serve:
- XHTML è stato abbandonato. Il successore di HTML4.01 è HTML5
- Un applicativo, per essere funzionale ed apparire moderno, deve utilizzare AJAX
- Utilizzare JavaScript non è più un tabù!
- Creare a mano il proprio JavaScript è tabù: dove possibile, utilizzare JQuery o altre librerie standard!
- Il framework standard di Google App Engine è Django. Non so se sarà il mio preferito, forse dovrei approfondire Pylons (che deriva in qualche modo da HTML::Mason)
- Non bisogna dimenticarsi di integrare il proprio applicativo con Facebook e altri social networks, come ad esempio Google+.
Iscriviti a:
Post (Atom)