giovedì 10 aprile 2008
Anche quest'anno gli intrepidi organizzatori della prima (e unica per ora) conferenza Python italiana,
http://www.pycon.it, hanno pubblicato lo schedule della stessa.
La conferenza, PyCon Due, si terra` il 9, 10 e 11 maggio a Firenze.
Premetto che io sono uno degli organizzatori (e membro fondatore dell'associazione Python Italia APS), quindi sono ovviamente
biased. Mi permetto di rompere il mio prolungatissimo silenzio in questi lidi e parlare di questa conferenza perche` penso che possa interessare anche a non Pythonisti (anche in conseguenza del fatto che terremo un talk su IronPython nel mondo reale)
Grazie a un culo tremendo (o meglio: alla persistenza di alcuni degli organizzatori) abbiamo ottenuto la presenza dell'assessore alla cultura,
Palazzo Vecchio per il keynote di apertura (!!) e, si spera, la presenza della stampa. Volano e` stato anche il fatto che il keynote sara` tenuto da Richard Stallman in persona che, anche se persona controversa e non amata da molti, e` causa indiretta del movimento opensource e tutto cio` che e` nato dalle costole del free software negli ultimi 20 anni.
I giorni seguenti (al Viva Hotel Laurus nei pressi del Duomo), vedi
schedule, saranno suddivisi su 3 track parallele: scoprire python, diffondere python e una sessione tutorial.
Il
talk su IronPython a cui accennavo prima sara` tenuto da Menno Smits, uno degli sviluppatori di
Resolver Systems, una azienda londinese che ha sviluppato un prodotto davvero interessante interamente in IronPython 1.1 e qualche manciata di linee in C#: Resolver One (vedi
screencast).
Tra gli altri talk e speaker menzionerei: Alex Martelli (Uber Technical Lead di Google Inc.) e il suo
talk sul neonato Google App Engine (fa piacere che per il suo primo talk pubblico in proposito abbia scelto PyCon Due ;-)), Arkadiusz Wahlig (autore di Skype4Py) con un
talk sponsorizzato direttamente da Skype (maggior sponsor e non usa nemmeno Python internamente dice), Samuele Pedroni e Antonio Cuni che come membri del core team di PyPy
parleranno dell'arte di generare virtual machines, Brian Fitzpatrick (uno degli sviluppatori di Subversion e autore di innumerevoli libri sull'argomento), Raymond Hettinger (direttamente dal core team di Python)
che parlera` della prima versione di Python che rompera` la compatibilita` con il passato dopo
17 anni, la 3.0 (pochi fuori dalla comunita` sanno che Python esiste da cosi` tanto tempo eh eh).
Per tutti questi talk non italiani sara` predisposto un servizio di traduzione simultanea in cuffia per i partecipanti.
Spero mi perdoniate questa invasione di campo e spero di aver interessato qualcuno di voi ;-)
venerdì 9 febbraio 2007
Sono rimasto esterrefatto dal post di Igor riguardo al web quindi ho generato una mia risposta. L'ho scritta sul blog personale per non intasare UGI (e perché è piuttosto OT) :-)
L'ABC del Web
mercoledì 24 gennaio 2007
Non so se ne siete al corrente ma: XQuery 1.0, XPath 2.0 e XSLT 2.0 sono diventati
Recommendation.
sabato 20 gennaio 2007
Tim O'Reilly ha postato l'analisi dell'ultima parte del 2006 relativamente alle vendite dei libri di O'Reilly o distribuiti da loro. Decisamente interessante: State of the Computer Book Market, Q406, Part 2: Category Winners and Losers.
martedì 16 gennaio 2007
Sto leggendo il libro di Gianluca Troiani, uno dei più noti esperti di CSS in Italia e maintainer dell'ormai morto constile.org. Essendo un libro tecnico (non esageratamente, dato che parte dalla A fino alla Z) è normale che lo si legga mentre si testano le cose che si imparano mano a mano. L'oggetto dei test sono i CSS ovviamente e la piattaforma sono i mille mila browser che costellano il web. Il problema però nasce (che novità) da Internet Explorer 6 che ha sempre avuto un bizzarro modo di interpretare i CSS. Per fortuna ho Firefox/Camino, Opera e Safari su OSX e IE appunto nella virtual machine di Parallels. Tutto bene dunque, finché non mi è venuto in mente di installare anche IE7, pensando che il problema dell'integrazione con Windows fosse stato "risolto" (calcolate che non uso Windows come piattaforma primaria da anni ormai, quindi sono rimasto un po' indietro sui dettagli). Per fortuna ho trovato questo post che mette a disposizione un'installer per avere IE7 standalone che non vada a cozzare o a sovrascrivere IE7.
La "figata" assoluta però è Parallels, l'applicazione che ho acquistato per le virtual machine in OSX che dalle recentissime versioni (io ho quella in rc) permette una assoluta comunicazione tra sistema operativo guest e host, ma soprattutto permette di _staccare_ la finestra dell'applicazione nella virtual machine per farla diventare una finestra in OSX (con tutti i vantaggi del caso). Ecco uno screenshot di IE7 a tutto schermo sul mio desktop :-)
Morale della favola: ora posso testare al volo anche su IE7 senza problemi, però overflow:auto continua a comportarsi erroneamente come in IE6 :-P
sabato 13 gennaio 2007
Aggiungo la mia visione molto pratica:
poniamo che IE6 abbia o avesse avuto un enorme numero di bug... da una parte hai un browser di cui ti lamenti (IE6) e dall'altra hai un aggiornamento gratuito che ti permette (potenzialmente ovviamente) di smettere di lamentarti del browser e dei suoi eventuali bachi. Cosa scegli?
Poi vedetela così... se sto massive update tramite WindowsUpdate funziona un giorno il sottoscritto e il resto dei web developer attenti agli standard potranno immolare un agnello al dio odino perché potranno fregarsene dell'esistenza di IE6 (come ora si tende a fare con IE5 e altri browser _davvero_ obsoleti)
giovedì 11 gennaio 2007
Second Mini-Anecdote: Pretty much every new release of IronPython has exposed limitations in our runtime, our class libraries or our compilers. IronPython has really helped Mono become a better runtime.
da Mono and C# 3.0 di Miguel de Icaza
ps. entro l'autunno dovrebbe essere pronto il primo libro su IronPython, scritto da un noto Pythonista che lavora in una startup londinese basata su IronPython, .NET e C#
mercoledì 10 gennaio 2007
mercoledì 3 gennaio 2007
Ho appena finito di leggere il post di Pierre e relativi commenti sul fatto che un metodo privato sia comunque accessibile dall'esterno. Io mi trovo d'accordo con quello che dice Corrado, sì per i controlli dei parametri e sì che è a rischio e pericolo del programmatore smanettare con l'interfaccia privata ma vorrei provare ad aggiungere una cosa: la differenza tra privato e privato forzato.
Uno dei linguaggi object oriented per eccellenza è Smalltalk (che per inciso è dinamico e *vivo*). Smalltalk non ha il concetto di private vs public, o meglio, non lo ha alla maniera di C++, Java, C# e tutti i linguaggi di questa famiglia (VB.NET compreso, che in fondo è molto più simile a C# di quanto si creda secondo me). In Smalltalk il tutto si basa sul buon senso e sulle convenzioni. Se io marco un metodo come privato è ovvio che non faccia parte della interfaccia e magari non lo documento nemmeno. Se poi tu programmatore vuoi usarlo sono cavoli tuoi e sai _benissimo_ che io posso farlo sparire alla seconda release.
Il vantaggio di questo approccio è che se una classe è programmata male (ricordo di roba "sealed" per errore nelle prime versioni di .NET) io posso comunque girare intorno al problema senza dover aspettare una patch fino alla prossima release della libreria o di quello che sto usando
Python usa questa convenzione senza alcun problema da 10 anni e passa. Un attributo o metodo privato viene marcato con "_nome" (notare l'underscore davanti). Ciò per qualsiasi Pythonista vivente significa: quello è privato, usalo se devi ma sappi che non è parte dell'interfaccia (oltre a quello che ovviamente viene esplicitato nella documentazione). Esiste un blando modo per forzare la privateness (che poi è più che altro una convenzione interna per motivi che non sto qui a spiegare che per "legare le braccia" il programmatore) che è quello di usare "__nome" (doppio underscore). Questo impedisce all'utente di fare "classe.__nome" per accedervi ma è sempre possibile accedervi tramite una semplicissima regola di name mangling o tramite "reflection" per usare un termine "dotnettaro".
Questo perché Smalltalk, Python e altri linguaggi usano una filosofia diametralmente opposta di quella di Java e C# che è quella di non legare le mani al programmatore, limitare il numero di keyword (e combinazioni delle stesse). Questo non significa che leda i principi dell'OOP, anzi, la differenza sta nel *forzare* o nel *comunicare*. Python comunica qual è l'interfaccia, C# forza. Differenza tra safety vs freedom languages, appunto. Vi invito a leggere quell'articolo, sicuramente alla fine sarete comunque della vostra idea, ma almeno avrete compreso almeno in parte il mio punto di vista.