[Python] piccolo editor con autocompletamento del codice

[enrico franchi]

2015-07-08 15:54 GMT+01:00 germano carella <germano.carella a gmail.com>:


> Allora, ho tolto il resto, perché rispondo a questo: non è che non voglio
> lavorare con gli sviluppatori per rendere qualcosa accessibile, è che per
> farlo ci vuole anche la volontà di studiare un aspetto che, ti assicuro,
> non è per niente semplice.
>

Si, chiaro. Ed e' il motivo per cui puoi dare una grossa mano proprio
perche' tu ti interessi del problema e loro no.


> Mettere le mani su un software completamente inaccessibile significa, a
> conti fatti, rallentarne lo sviluppo.
>

Si.


> Mi hanno assicurato che lo faranno, ma non sanno quando. Ciò vuol dire che
> potrebbe anche passare un anno.
>

O 5.


> Mi occupo di accessibilità da 13 anni, un po' per lavoro, un po' perché io
> sono non vedente e quando scrivo una cosa, se non la faccio accessibile
> almeno per me, non ha molto senso che io la scriva.
>


> L'accessibilità di un'applicativo va progettata dall'inizio, se lo
> sviluppatore decide di non usare oggetti standard.
>

Chiaro. E suppongo che se usa oggetti non standard sia comunque possibile,
sapendolo fare, renderli comunque accessibili.

Tanti sviluppatori mi ascoltano, ma tanti, ti garantisco, mi rispondono che
> se il progetto è open-source, posso tranquillamente metterci io le mani per
> renderlo accessibile.
>

E non vedo perche' stupirti di questo. E' *esattamente* come funziona
l'open source. Esattamente come se a me interessa una feature che non c'e'
o me la scrivo o aspetto che me la scrivano. Esattamente come se ho un baco
che mi da fastidio o me lo fixo o aspetto che lo facciano per me. E se lo
fanno gli altri, lo fanno gli altri quando hanno tempo e voglia.

Ora, io mi rendo conto che per te "accessibilita'" non e' esattamente una
feature come un'altra, e' il fondamento minimo senza cui non si va avanti.
Pero' il modo in cui funziona l'open source e' esattamente che se hai
bisogno di qualcosa hai il *potere* di farlo. E in un certo senso e' anche
il modo piu' rapido per ottenere qualcosa.


> Vabbè, la taglio qui perché è poco interessante.
>

E invece e' *molto* interessante. Perche' secondo me il punto e' che stai
sbagliando approccio (e te ne pentirai).


> Concludendo questa tiritera infinita, senza dubbio ci sono cose che non
> so, sfido a trovarne uno che le sappia tutte; probabilmente mi sono
> occupato troppo di accessibilità e ho tralasciato qualcosa, ma preferisco
> colmare qualche lacuna studiando,
>

No aspetta... e' chiaro che nessuno sa tutto. Ed e' esattamente per questo
che ti dico che se sei bravo a farne una e' un peccato che tu non benefici
delle skill degli altri sulle cose su cui loro sono forti e che loro
beneficino delle tue su quelle su cui tu sei forti.


> piuttosto che mettere le mani su un progetto di cui l'autore, mentre io
> cerco di capire come l'ha scritto, ne ha probabilmente fatte altre 5 o 6
> release.
>

E quindi? Ci sono i branch, no big deal. Tutto lo sviluppo software
funziona cosi'. Una volta che hai fatto il merge del tuo codice con un set
di regression che asseriscono quello che hai fatto, le future versioni
*rimarranno* accessibili.

 Tornando a noi... ora supponiamo che $editor sia il miglior editor
immaginabile, sviluppato da centinaia di persone. E' un editor flessibile,
che supporta quasi tutto la fuori e che se non supporta qualcosa puo'
essere esteso facilmente. E', in altre parole, l'editor che vorresti
usare... solo che non e' accessibile. Quindi non puoi usarlo. Ora, invece
di provare a renderlo accessibile, ne scrivi uno da 0.

Questo sara' sviluppato da una persona. Tu. Non avra' le features
dell'altro (perche' per quanto tu sia bravo, non puoi essere veloce come
un'intera community di persone). E dovrai re-iniziare a implementare cose
di base che gli altri hanno gia'. Non solo, proprio perche' nessuno sa
tutto, ci saranno cose che altri si aspettano che un editor faccia cui tu
non hai nemmeno pensato. In altre parole "condanni" te stesso (e la
community di non vedenti) ad uno strumento peggiore. Perche' parlo di
"community di non vedenti"? Beh, perche' se a te mancano un centinaio di
features dell'editor sopra-menzionato e quello che offri in piu' e'
l'accessibilita', di fatto creerai una community di persone che fra
virtualenv e accessibilita' scelgono l'accessibilita' (virtualenv qui e' un
esempio). E guarda caso, credo che questa community sia fatta di persone
che non *possono* sacrificare l'accessibilita'.

In generale, l'idea di "mi riscrivo tutto da 0" (lasciando stare il
discorso accessibilita': e' un pattern comune che si applica ad ogni tipo
di software e di feature) e' molto allettante per l'ego, e' anche in
apparenza piu' facile (perche' di fatto si finiscono per non trattare i
problemi difficili che non interessano e trattere solo quelli che
interessano). Ed e' un pattern che porta solo a frammentazione e a problemi
di ogni tipo.

Poi e' interamente possibile (tornando a parlare del tuo problema
specifico) che uno specifico editor sia davvero troppo complesso da rendere
accessibile. Pero' fra quelli con una certa trazione e community potrebbe
essercene uno che invece e' fattibile. Certo, sara' doloroso e complicato.
Pero' alla fine avrai qualcosa di migliore, tu, i tuoi utenti e in generale
la comunita' dei non vedenti.

Cosi', per curiosita', cosa fai di preciso quando l'utente da il comando di
salvataggio? Non mi interessa cosa fa lo screen reader, non mi interessa al
momento la UI: intendo, come implementi il salvataggio in termini di
pseudo-codice?


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150708/639c198f/attachment-0001.html>