Closed pe3 closed 10 years ago
Tässä esimerkki kirjan kirjoittamisesta GitHubissa git:illä ja markdown:illa: book-of-modern-frontend-tooling.
Jos on asentanut itselleen git:in, node:n ja grunt:in, onnistuu kirjan html- ja pdf-generoiminen seuraavalla komentosarjalla:
git clone https://github.com/tooling/book-of-modern-frontend-tooling.git
cd book-of-modern-frontend-tooling
npm install
grunt
Kirjan sisällön suunnittelu on kännissä GitHubin issueissa, joiden luokittelu on mukautettu projektin tarpeisiin.
Tämä kaikki onnnistuu nykyään hyvin helposti jo kaikkein yksinkertaisimmilla perusvälineillä. Mitä muuta FLOSS Manuals nykyisellään tarjoaa kirjoittajille? Toki Git on hieman vaikea ja reaaliaikainen tekstin yhteiskirjoittaminen ei GitHubissa onnistu. Olisiko esimerkiksi mahdollista kytkeä Etherpad Lite GitHub-repoon? Voisiko näiden tarpeiden ratkominen kiinnostaa FLOSS Manaulsin ihmisiä?
FLOSS Manuals on käyttänyt PHP-alustaa staattisten oppaiden julkaisemiseen, mutta siihen ei enää kannata käyttää aikaa, koska kukaan ei tietääkseni varsinaisesti ylläpidä sitä.
GitHub on tosiaan käytössä myös joissain kirjoitusprojekteissa. Se kuitenkin rajaisi osallistujat hyvin teknisiin ihmisiin? Käsittääkseni monien mielestä myös Wikimedian markup on liian hankala opeteltavaksi?
Booktype käyttää nykyisellään TinyMCE-editoria, eli teknisesti se olisi yhtä vaikea kuin WordPress. Koska TinyMCE on taiton kannalta rajoittunut editori tulee Booktype 2.0 käyttämään Aloha-editoria. Kokeilin tuota 2.0-versiota mutta en vielä osaa kommentoida Aloha-editoria sen tarkemmin.
Etherpad on hankala siinä mielessä, että se ei taida mahdollistaa juuri minkäänlaista taittoa? Eli sitä voi kyllä käyttää tekstien luonnosteluun ja ideointiin, mutta ei taida riittää lopullisen ulkoasun laatimiseen?
Sen sijaan on kyllä mielenkiintoinen idea, että kirjat olisivat Git-repositorioita ja niitä vedettäisiin vaikka automaattisesti palvelimelle. Palvelimelle voisi asentaa jonkun HTML-editorin, jolla voi editoida kirjoja vaikka ei osaisi käyttää esimerkiksi GitHubia.
Luultavasti kirjojen pitäisi silloin olla HTML-tiedostoja, jotta niitä voisi editoida mahdollisimman monella erilaisella editorilla?
Tämän lisäksi tulisi sellainen pieni ongelma, että jonkun pitäisi jatkuvasti käydä siivoamassa käsin mergejä.
Itse asiassa fi.flossmanuals.net pushasi oppaiden HTML-versiot automaattisesti GitHub-repoon, mutta se oli tarkoitettu vain varmuuskopiointimenetelmäksi.
Teknisesti ottaen olisi kuitenkin ollut mahdollista käydä editoimassa oppaita GitHubissa ja vetää muutokset takaisin serverille.
Etherpadiin löytyy Markdown-plugari, jota en ole kokeillut ja muutenkin se oli vaan heitto.
Nopeesti kokeillen en heti keksinyt mihin taittotarpeisiin Markdown ei riittäisi. Handbrake-oppaasta:
Kun käynnistät Handbraken, sinun pitäisi nähdä alla oleva ikkuna.
Nyt selostan Handbraken peruskäytön, eli Handbraken käytön muuntamaan DVD-tiedostoja internetissä jaettaviksi mp4-tiedostoiksi. **
Ensin sinun tulisi laittaa DVD-levy tietokoneesi DVD-soittimeen.
Sen jälkeen sinun pitäisi napsauttaa Browse-nappia, joka on Source-kohdan (lähde) vieressä ohjelman ikkunassa.
Tämän napin napsauttamisen jälkeen alla olevan ikkunan tulisi avautua.
Vieritä alas löytääksesi DVD:n tällä listalla ja napsauta sen vieressä olevaa plus-merkkiä:
Näet nyt tiedostot DVD-levyn sisällä. Tämä ei välttämättä näytä kovinkaan ymmärrettävältä, jos et ole koskaan avannut DVD-levyä tällä tavalla. Meidän ei tarvitse tietää paljonkaan DVD-levyn rakenteesta käyttäessämme Handbrakea. Tässä vaiheessa täytyy vain tietää, että VIDEO_TS -hakemisto sisältää tiedot videotiedostoista. Valitse siis vain VIDEO_TS -hakemisto (älä kaksoisnapsauta, pelkästään korosta tämä hakemisto) ja napsauta OK. Seuraava ikkuna ilmestyy näkyviin:
Edellinen ikkuna on esillä jonkin aikaa, kun Handbrake analysoi DVD-levyn rakennetta.
Voit nähdä lähdeikkunan alla alueen, jossa lukee "Title:" (Otsikko) ja "Chapters:" (Luvut). Voit jättää tämän alueen koskemattomaksi. Tämä enkoodaa kaiken DVD-levyllä olevan informaation.
Voit valita ainoastaan yhden "otsikon" (yleensä kokonainen elokuva DVD-levyllä) tai valita "lukuja" (yleensä elokuvan osa, joka on tehty DVD-levyllä navigointi helpommaksi).
Tässä tapauksessa voit valita otsikoita (Titles) ja kappaleita (Chapters) Handbraken oletusikkunan lähde-osassa (Source).
Voit nähdä eri otsikoiden (filmien) pituudet, jotta voit päättää, minkä niistä valitset.
Ensin meidän täytyy asettaa ulostulohakemisto tiedostolle, jonka luomme. Napsauta "Browse"-nappia (selaa) ikkunan kohde-osassa (Destination):
Nyt näemme tiedostoselaimen.
Valitse tietokoneeltasi hakemisto, johon mp4-tiedosto luodaan ja tallennetaan. Anna tiedostonimi "File Name" -laatikkoon (tiedostonimi) ja jätä oletusarvoksi mp4 laatikkoon "Save as Type" (tallenna muodossa). Voit muuttaa tämän toiseen tiedostomuotoon jos tahdot, mutta tässä perusjohdannossa Handbrakeen jätämme sen muotoon mp4.
Tämän jälkeen voit aloittaa prosessin enkoodaamalla DVD:n mp4-tiedostoon napsauttamalla isoa "Start"-nappia ruudun vasemmassa yläosassa, kuten alla näytetään.
Kun enkoodausprosessi alkaa, näet mustan ikkunan, jossa näkyy prosessin eteneminen ja kuinka kauan se vielä kestää.
Jos et ole nähnyt tällaista ikkunaa, se tunnetaan DOS-ikkunana tai komentorivinä.
Kun prosessi on valmis, sinun tulisi käyttää VLC-soittimen kaltaista ohjelmaa testataksesi tiedostoa, jonka olet luonut. Tahdot ehkä ladata sen nettiin videonjakosivustolle, kuten Archive.org tai Blip.tv.
@TomiToivio Mä tallentaisin kirjat Markdownina (ja sen sisäänhän voi tarvittaessa kirjoittaa HTML:ääkin). Nimenomaan sen ympärille on rakentumassa erittäin aktiivinen ekosysteemi. Tsekkaa mm 78 Tools for Writing and Previewing Markdown. Esimerkiksi Dropboxin avulla kirjaprojektit olis mahdollista tuoda helppokäyttöisesti erilaisten natiivieditorien ulottuville.
Tuota Git-ideaa olisi mielenkiintoista kokeilla pidemmällä tähtäimellä. Tässä vaiheessa pelkkä Booktypekin tuntuu ylimitoitetulta resursseihin nähden. ;)
Veikkaan, että isoin ongelma Gitin käytössä olisi pitää merget kasassa. Eli joku joutuisi jatkuvasti siistimään niitä käsin. Pelkästään tämä tekisi operaatiosta työlään, minkä lisäksi tulisi erilaisten editoriviritelmien säätäminen.
@TomiToivio onko kirjaprojekteilla yhtä tai useampaa vetäjä-henkilöä, jotka voivat katsoa kontribuutioiden perään? githubin pull-request:han on tehokas väline tähän. kiinnostaisko sua tulla 22.2. open data brunssille funtsaamaan jatkoja. itseäni kiinnostaa mm. suomenkielisen github-kirjoittajille oppimateriaalin koostaminen.
Kas, missasin tuon idean. Ei se mitään, koska olin silloin muutenkin flunssassa.
Eikös näitä voida pohtia osana Open Education-ryhmän booksprint-projektia?
Luonnollisesti tuotettavalle materiaalille pitää olla editointi- ja julkaisualusta, mutta mielestäni tekninen alusta on kumminkin toissijainen kysymys kollaboratiivisen kirjoittamisen menetelmiin verrattuna. Kun niitä kirjoja ei kuitenkaan saa kirjoitettua ihan Wikipedia-tyyppisen satunnaisen osallistumisen pohjalta. Muutenhan Wikibooks olisi tuottanut jo tuhansia valmiita kirjoja.
Eli tästä muokkaamaan Suomeen sopivaa menetelmää: http://books.okf.fi/booksprint/johdanto/
Täällä on kilpaileva alusta jota voisi testata: https://github.com/TomiToivio/PubSweet
(Veikkaan että on järkevintä pysyä Booktypessä toistaiseksi.)
Toinenkin kilpailija, jonka WordPress-pohjaisuus olisi kyllä valtava etu: https://github.com/TomiToivio/pressbooks
Paras varmaankin pysyä Booktypessä, mutta ajattelin testailla noita huvin vuoksi.
Pikainen evaluaatio Pressbooksista verrattuna Booktypeen:
Oikeastaan tämä oli sittenkin hyvä idea. Mikäs olisi hyvä tapa säilyttää kirjojen tiedostoja? Siis yksinkertaisin kuviteltavissa oleva formaatti, jota voi editoida mahdollisimman monella erilaisella editorilla. Onko Markdown paras? Eikös HTML olisi yleismaailmallisin?
Ja miten kirjat saisi jaettua esimerkiksi Gitin kautta ilman että joku joutuisi käyttämään koko elämänsä mergejen tekemiseen?
Markdownina on nyt julkaistu ainakin My Data -selvitys https://github.com/okffi/mydata
Heitin ton Datademo-ehdotukseksi, mutta olin niin innoissani etten muistanut selittää miten se liittyy demokratiaan. :)
Tosin materiaali pitäisi populismin takia saada jaettua Gitin lisäksi jonkun Dropboxin kautta, että muutkin kuin open source -nörtit voi osallistua.
Tämä ei oikein innostanut ihmisiä Datademossa, joten mietitään sitä sitten taas joskus: https://trello.com/c/NeYOfbni/4-hajautettu-yhteisokirjoittaminen
Missä määrin kirjoittamisprosessin voisi siirtää pois tietokannasta Git:in ja Markdownin varaan? Tätä yhdistelmää näkee käytettävän yhä useammin bloggaamiseen ja kirjojen kirjoittamiseen. Voisiko jokainen kirja olla oma Git-reponsa?
NPM:llä on helppo pystyttää käyttäjän omalle koneelle (Win, Mac, Linux) palvelu, joka generoi reaaliaikaista kirjan esikatseluversiota paikalliseksi kloonatusta Git-reposta ja neuvoo repon kirja-konventioiden mukaisessa editoimisessa. Kirja-repo koostuisi kansiorakenteeksi ryhmitellyistä Markdown-tiedostoista, metadatasta, kuvista ja repo-kohtaisesta kirjaprojektin kuvaavasta json-tiedostosta - vrt. package.json.
Edelläkuvatussa arkkitehtuurissa editointihistoriaa ei enää toteutettaisi palvelukohtaisella yksittäisratkaisulla vaan hyödynnettäisiin Git-formaattia. Git tarjoaisi monipuoliset työnkulut ja valmiin työkaluekosysteemin. Monoliittisen web-palvelu-arkkitehtuurin sijaan projektissa tuotettuja työkaluja voisi hyödyntää myös muissa Git-Markdown-projekteissa, joka lisäisi niiden kiinnostavuutta.
Git-repo-vetoisessa mallissa FLOSS Manuals toimisi Git-repojen sosiaalisena indeksinä, npmjs.org:n tapaan.