Share
Forse tu, o qualcuno che conosci, hai sperimentato le difficoltà dell'interazione con il computer per i disabili. In generale, i sistemi operativi e le suite software hanno predisposto l'accessibilità per il pubblico ipoacusico, il pubblico con disabilità visive e l'internazionalizzazione; tuttavia, il web aperto non ha raggiunto il più rapidamente. Molti siti ignorano completamente l'accessibilità.
Forse uno dei motivi di ciò è che probabilmente non c'è una fonte di contenuti aggiornati e digeribili incentrati interamente sull'accessibilità.
Il Progetto di accessibilità (a11yproject.com) sta cambiando questo. Offrendo una piattaforma aperta (tramite GitHub), a11yproject sta creando un insieme di contenuti auto-curante, di massa, che è digeribile, aggiornato, e perdonare. (Vedi la loro pagina.)
Il Progetto sull'accessibilità è un ottimo esempio di come la tecnologia possa aiutare a supportare lo sviluppo collaborativo. Chiunque può contribuire. Il costo del supporto per questo è quasi nulla, e la gestione del sito è minima, guidata dalla comunità.
Ci sono molte persone dietro a11yproject, tra cui Dennis Gaebel di Grey Ghost Visuals, Dave Rupert a Paravel, Jamie Piper ad Alliants, Mat Marquis e una sfilza di altri. (Dai un'occhiata alla lista dei contributori degli avatar nella parte inferiore della home page.)
Questo è un gruppo che vale la pena iscriversi, e la parte fantastica è che puoi farlo semplicemente contribuendo!
Il Progetto di accessibilità è impostato per la collaborazione remota e asincrona. Il sito non utilizza un database e non richiede alcun provider di hosting. Ecco come lo fanno.
Il sito è interamente ospitato da GitHub tramite GitHub Pages. GitHub Pages consente agli utenti di GitHub di pubblicare contenuti statici e li pubblica come pagina web.
GitHub Pages è, in generale, creato per supportare progetti e utenti, dando loro un posto dove ospitare documentazione, esempi, eccetera. Anche i membri di GitHub hanno reso le pagine compatibili con Jekyll.
Jekyll è il framework del cavallo di battaglia basato sulla gemma di Ruby dietro a The Accessibility Project. Costruito da Tom Preston-Werner e altri presso GitHub, Jekyll è un generatore di siti statici che consente agli utenti di creare post e pagine in Markdown o Tessile (anche se a11y post sono solo Markdown).
Jekyll utilizza le impostazioni di configurazione di YAML per aiutare a generare pagine / post localmente. Questi post e pagine vengono visualizzati come file HTML statici, JavaScript e CSS. (Scopri di più su Jekyll qui: wiki di utilizzo di Jekyll su GitHub.) Se vuoi contribuire a The Accessibility Project, questo è il modo migliore per creare un nuovo post.
Accentsconagua
fascio per installare tutte le dipendenze. Il Gemfile specifica tre gemme che verranno installate. (Inoltre, avrai bisogno di Bundler per fascio lavorare.)rastrello -T per elencare i comandi che è possibile utilizzare specifici per questo progetto. rastrello, o "Ruby make", è uno strumento che consente di astrarre compiti ripetitivi o automatizzati in un file all'interno della directory di lavoro (chiamato Rakefile) e richiamato tramite la riga di comando.rake post title = "Qualcosa di interessante sull'accessibilità" per creare un post.Una funzionalità ancora più interessante di GitHub Pages: compila il tuo sito Jekyll per te, se lo desideri.
Perché vorresti andare con un generatore di siti statici? Ci sono molte ragioni per cui questa è una buona risposta a molti problemi di sviluppo. Innanzitutto, i file statici sono facili da servire. Fondamentalmente ogni server web può servire file statici. Oltre a questo, servire file statici è generalmente incredibilmente veloce ed efficiente.
Allo stesso modo, il sovraccarico di servire file statici è molto più basso sul server. La riduzione della gestione del contenuto in un ambiente di sviluppo locale riduce l'incertezza e la necessità di un ambiente orientato al sysadmin.
Un altro buon motivo per andare con un generatore di siti statici è la sicurezza; i siti statici sono infinitamente meno vulnerabili ai problemi di sicurezza come l'iniezione di SQL rispetto ai siti che supportano il database. Infine, la maggior parte dei contenuti periodici si presta già a file statici; il contenuto non viene generato da un algoritmo basato sui dati o da dati in tempo reale. Piuttosto, è un contenuto basato sul testo che non cambierà (a meno che le modifiche non vengano apportate manualmente). L'importante distinzione qui è che i post sono creati manualmente e il layout in giro il contenuto non cambia in modo dinamico. Questi sono tutti segnali che l'uso di file statici è una buona soluzione.
RVM è uno strumento che gestisce più installazioni del linguaggio di programmazione Ruby. RVM utilizza .rvmrc file per assicurarsi che la versione corretta di Ruby sia selezionata per essere eseguita per un determinato progetto. Un suggerimento utile: qualsiasi file che inizia con a . è molto probabilmente un file di configurazione; in particolare, i file .rc o "runtime configuration", generalmente vengono valutati al momento dell'esecuzione / runtime, di solito solo una volta.
Il file di configurazione CodeKit viene utilizzato per generare le impostazioni per CodeKit, che compila i file SASS per il progetto. Questa configurazione aiuta a mantenere la conformità tra i diversi utenti. Potresti riconoscere il tipo di file (JSON): il file è un oggetto JavaScript valido. JSON viene anche utilizzato per molte altre configurazioni di ambiente.
Il "miglior flusso di lavoro web moderno" è un argomento sfuggente, ma molte persone hanno pubblicato di recente sulla flessibilità e sull'usabilità dell'integrazione dello sviluppo orientato alle funzionalità che ruota intorno alla discussione con GitHub Issues e Pull Requests. (Dai un'occhiata al grande Speaker Deck di Zach Holman sull'argomento.) Per archiviare un problema, vai semplicemente su un progetto e fai clic su Issues, e spiega il problema. Il proprietario del progetto può classificare il problema e rispondere ad esso; se una patch o una richiesta pull risolve il problema, è possibile utilizzare il linguaggio naturale nel messaggio di commit Git per contrassegnare il problema come risolto. Ad esempio, "Risolto il problema n. 42". Quindi, puoi inviare una richiesta di pull che faccia riferimento ad un commit specifico; se tale richiesta di ricezione viene accettata, tale problema viene contrassegnato come risolto.
Ma facciamo un passo indietro qui, prima che ci mettiamo a parlare dei flussi di lavoro di Git per ore e ore.
Il modo in cui Accessibility Project utilizza GitHub è un modo per gestire i contenuti, sia nella fase pre-pubblicata che nella fase di pubblicazione. Se hai un'idea per un articolo, puoi crearlo (tramite GitHub Gist o Clap). Una volta fatto, archiviare un problema su GitHub che fa riferimento al tuo Gist / Clap avvia la conversazione sul tuo particolare articolo. Infine, prendi l'articolo dal Gist in un post potenziato da Jekyll. Ciò comporta alcuni semplici comandi del terminale, un commit e una richiesta di pull per risolvere il problema che hai archiviato su quell'articolo. Quindi, ecco i passaggi di base.
rake post title = "il tuo titolo" nella tua copia locale del repositoryserver di rake e visita http: // localhost: 4000 per dare un'occhiata al tuo post (e al resto del sito)controllo del rake per assicurarti di non rompere nulla. (Se lo hai fatto, questo è un argomento per la discussione dei commenti.)Se non hai ancora intenzione di smettere di fumare sulle tue abilità di Jekyll o Git / GitHub, puoi anche chiedere aiuto per far passare il tuo post in un commit. Commenta il problema associato al post. Inoltre, assicurati di dare un'occhiata a questo screencast sul nostro sito fratelli Tuts +, NetTuts.
Nel caso in cui non l'avessi notato, tutto questo processo di creazione di contenuti ruota attorno a discussioni conversazione / thread di contenuti su GitHub. Questo fornisce un modo per combinare naturalmente una conversazione con un'azione associata. Questa è un'integrazione critica per qualsiasi tipo di collaborazione.
Il sito si basa su una porta Sass / Compass di Twitter Bootstrap, quindi non c'è nulla di sorprendentemente innovativo sul design del sito. Tuttavia, è aperto anche a contributi e collaborazioni; I problemi archiviati su GitHub non sono solo per collaborare alle idee post, ma anche per far notare inesattezze, inaccessibilità e bug. Anche al di là di questo, chiunque è invitato a presentare problemi e attirare richieste per migliorare il sito in qualsiasi modo; pensa che il sito potrebbe usare una nuova pelle?
* Ottenere famosi non è correlato all'invio della richiesta di pull.
Il Progetto Accessibilità è costruito esclusivamente utilizzando SASS e Compass; se si desidera inviare modifiche di progettazione, è necessario farlo utilizzando SASS e Compass.
Mentre alcuni potrebbero considerarlo una limitazione, serve a uno scopo. Innanzitutto, rende il codice base meno complesso; se il progetto ha provato a supportare vanilla CSS, LESS e SASS, il risultato avrebbe comportato grossi problemi di dipendenza. Richiederebbe inoltre ai contributori di aggiornare sia i file LESS che quelli SASS, cosa che è molto meno probabile che incoraggi il coinvolgimento. Infine, coloro che sono spinti a contribuire e hanno anche le capacità o il contenuto di qualità per contribuire potranno già conoscere il SASS o avranno un modo per impararlo. Mentre questo sembra esclusivo, dobbiamo anche considerare che questo, ad un certo punto, è il caso di qualsiasi tecnologia; coloro che non sanno (e non sono disposti a imparare) come integrare il loro JavaScript con jQuery semplicemente non possono scrivere plugin jQuery.
Open-source è uno strumento incredibilmente potente. Usare piattaforme come GitHub e strumenti come Jekyll fanno splendere l'open source. La comunicazione integrata con i documenti di lavoro è essenziale per collaborare in modo efficiente, specialmente se il lavoro svolto è parallelo ad altri che svolgono un lavoro simile.
Il Progetto sull'accessibilità è un ottimo esempio di tutti questi principi che si concretizzano. Con circa quaranta contributori di alto livello fino ad oggi, è una dimostrazione del potere dell'open-source e della volontà delle persone di collaborare per fare qualcosa di grande. Il progetto comporta molto poco o nessun sovraccarico per questo sito esistere.
?
