Jeg tror jeg har holdt dusinvis av presentasjoner for kolleger, kunder og offentlige foredrag i min IT-karriere. I mange år har Powerpoint vært et naturlig og pålitelig valg for meg som et lysbildeproduksjonsverktøy. Men i år har situasjonen endret seg kvalitativt. Fra februar til mai hadde jeg anledning til å tale på fem konferanser, og lysbildene til rapportene måtte utarbeides på kort tid, men med høy kvalitet. Spørsmålet dukket opp om å delegere den delen av arbeidet med den visuelle utformingen av lysbildene til andre. Jeg prøvde en gang å jobbe med en designer, og sendte .pptx-filer per post, men arbeidet ble til kaos: ingen visste hvilken versjon av lysbildene som var den "nyeste", og oppsettet "beveget seg" på grunn av forskjellen i Powerpoint versjoner og fonter på maskinene våre. Og jeg bestemte meg for å prøve noe nytt. Jeg prøvde det, og siden da har jeg ikke tenkt på å gå tilbake til Powerpoint.
Hva vil vi
For omtrent halvannet år siden sluttet firmaet vårt å bruke Word til å lage prosjektdokumentasjon, etter å ha møtt de samme problemene: selv om Word er bra for å skrive opp et lite dokument, oppstår det vanskeligheter med samarbeid og oppnåelse av høykvalitets og etter hvert som volumet øker. enhetlig design. Vårt valg falt på , og vi slutter aldri å glede oss over dette valget, men dette er et emne for en egen artikkel. Omtrent samtidig lærte vi effektiviteten til et av DevOps-prinsippene for "alt som kode", så valget av krav til den nye teknologien for å lage presentasjonslysbilder var ganske åpenbart:
- Presentasjonen må være en ren tekstfil i et merkespråk.
- Lysbildene våre handler om utviklingsprosjekter, så markeringen skal gjøre det enkelt å sette inn, uten å ty til eksterne systemer
- kodefragmenter med syntaksutheving,
- enkle diagrammer i form av geometriske former forbundet med piler,
- UML-diagrammer, flytskjemaer og mer.
- Presentasjonsutkastet skal lagres i et versjonskontrollsystem.
- Validering og montering av ferdige lysbilder bør gjøres i et CI-system.
I dag er det to grunnleggende alternativer for å lage lysbilder i markup-språk: pakke for LaTeX eller et av rammeverkene for å lage lysbilder ved hjelp av HTML/CSS (, , og mange andre).
Selv om sjelen min ligger i LaTeX, dikterte tankene mine at valget av en løsning som jeg ikke ville være den eneste som brukte, skulle være på siden av en løsning som er kjent for en bredere krets av mennesker. Ikke alle kjenner til LaTeX, og hvis din daglige praksis ikke er relatert til å skrive vitenskapelige artikler, vil du neppe ha tid til å fordype deg i den enorme, intrikate verdenen til dette systemet.
Men å beherske HTML/CSS er ikke akkurat en utbredt ferdighet: Jeg er for eksempel langt fra ferdig med det. Heldigvis kommer den allerede kjente AsciiDoctoren til unnsetning: en omformer lar deg lage RevealJS-lysbilder ved å bruke AsciiDoctor-markering. Og det er enkelt å lære og tilgjengelig for alle!
Hvordan kode lysbilder
For å forstå essensen av å kode lysbilder på AsciiDoctor, er den enkleste måten å gi spesifikke eksempler. Disse er alle fra faktiske lysbilder jeg laget for konferansepresentasjonene mine i år.
Et lysbilde med en tittel og en liste over elementer som åpnes etter hverandre:
== Зачем нам Streams API?
[%step]
* Real-time stream processing
* Stream-like API (map / reduce)
* Под капотом:
** Автоматический offset commit
** Ребалансировка
** Внутреннее состояние обработчиков
** Легкое масштабированиеResultat
Topptekst og kildekodebit med syntaksutheving:
== Kafka Streams API: общая структура KStreams-приложения
[source,java]
----
StreamsConfig config = ...;
//Здесь устанавливаем всякие опции
Topology topology = new StreamsBuilder()
//Здесь строим топологию
....build();
----Resultat
Som forberedelse til en tale gjennomgår kodedemoer gjentatte revisjoner og forbedringer, så muligheten til å raskt kopiere og lime inn "råkoden" direkte inn i et lysbilde er uvurderlig, og sikrer at demoen er oppdatert uten å bekymre deg for syntaksutheving.
Tittel, illustrasjon og tekst (layout på lysbildet gjøres i celler ):
== Kafka Streams in Action
[.custom-style]
[cols="30a,70a"]
|===
|image::KSIA.jpg[]
|
* **William Bejeck**, +
“Kafka Streams in Action”, November 2018
* Примеры кода для Kafka 1.0
|===Resultat
Noen ganger er det ikke nødvendig med en tittel, og for å illustrere poenget ditt trenger du bare et fullskjermbilde:
[%notitle]
== Жить в легаси нелегко
image::swampman.jpg[canvas, size=cover]Resultat
Ofte må en idé støttes av et enkelt diagram, i form av "firkanter forbundet med piler." Heldigvis er AsciiDoctor integrert med systemet — et språk som lar deg beskrive grafdiagrammer basert på beskrivelsen av toppunkter og sammenhenger mellom dem. Graphviz tar en læringskurve, men basert på eksemplene som er gitt, er det ganske enkelt å gjøre! Slik ser det ut:
== Пишем “Bet Totalling App”
Какова сумма выплат по сделанным ставкам, если сыграет исход?
[graphviz, "counting-topology.png"]
-----
digraph G {
graph [ dpi = 150 ];
rankdir="LR";
node [fontsize=18; shape="circle"; fixedsize="true"; width="1.1"];
Store [shape="cylinder"; label="Local Store"; fixedsize="true"; width="1.5"]
Source -> MapVal -> Sum -> Sink
Sum -> Store [dir=both; label=" n "]
{rank = same; Store; Sum;}
}
-----Resultat
I tilfelle det er nødvendig å redigere bildeteksten på figuren, endre retningen på pilen osv., kan dette gjøres direkte i presentasjonskoden, i stedet for å tegne bildet på nytt et sted og sette det inn i lysbildet igjen. Dette øker hastigheten på arbeidet med lysbilder betydelig.
Et mer komplisert eksempel:
== Невоспроизводимая сборка
[graphviz, "unstable-update.png"]
-----
digraph G {
rankdir="LR";
graph [ dpi = 150 ];
u -> r0;
u[shape=plaintext; label="linter updaten+ 13 warnings"]
r0[shape=point, width = 0]
r1 -> r0[ arrowhead = none, label="master branch" ];
r0-> r2 []; b1 -> b4; r1->b1
r1[label="150nwarnings"]
b1[label="± 0nwarnings"]
b4[label="± 0nwarnings"]
b4->r2
r2[label="163nwarnings", color="red", xlabel=<<font color="red">merge blocked</font>>]
{rank = same; u; r0; b4;}
}
-----Resultat
Forresten, det er praktisk å eksperimentere med Graphviz og feilsøke bilder på siden .
Til slutt, hvis du trenger å sette inn et flytskjema, klassediagram eller annet standardisert diagram i et lysbilde, kan et annet system integrert med AsciiDoctor komme til unnsetning, . Min kollega Nikolai Potashnikov skrev om de omfattende egenskapene til PlantUML .
Å gjøre presentasjonsprosjektet til kode lagret på et versjonskontrollsystem gjør det mulig å organisere felles arbeid med presentasjonen, først og fremst for å skille oppgavene med å lage innhold og design. Utformingen av lysbilder (fonter, bakgrunner, innrykk) i RevealJS er beskrevet ved hjelp av CSS. Mine personlige ferdigheter med CSS formidles best av - men det er ikke skummelt når det er folk som jobber med CSS mye mer behendig og raskere enn meg. Som et resultat viser det seg at med en raskt nærmer seg deadline for en presentasjon, kan vi jobbe med forskjellige filer samtidig via Git og utvikle en samhandlingshastighet som er umulig når du sender .pptx-filer med post.
Bygge en HTML-side med lysbilder
Vanlige tekstkilder er flotte, men hvordan kompilerer du dem inn i selve presentasjonen?
AsciiDoctor er et prosjekt skrevet i Ruby, og det er flere måter å kjøre det på. Først kan du installere Ruby-språket og kjøre asciidoctor direkte, som sannsynligvis er det som er nærmest Ruby-utviklere.
Hvis du ikke vil rote med å installere Ruby, kan du bruke docker-bildet , der du, når den er lansert, kan koble mappen med prosjektkildene via VOLUME og få resultatet på et gitt sted.
Alternativet jeg valgte kan virke noe uventet, men det er det mest praktiske for meg som Java-utvikler. Det krever ikke installasjon av Ruby eller docker, men lar deg generere lysbilder ved hjelp av et Maven-skript.
Poenget er at prosjektet – Java-implementeringen av Ruby-språket er så god at den lar deg kjøre nesten alt som er laget for Ruby i en Java-maskin, og å kjøre AsciiDoctor er en av de vanligste bruksområdene til JRuby.
tilgjengelighet lar deg samle AsciiDoctor-dokumentasjon som er en del av et Java-prosjekt (som vi aktivt bruker). Samtidig lastes AsciiDoctor og JRuby ned automatisk av Maven, og AsciiDoctor kjører i JRuby-miljøet: det er ikke nødvendig å installere noe på maskinen! (Ekskludert pakke graphviz, som er nødvendig hvis du vil bruke GraphViz- eller PlantUML-grafikk.) Bare plasser .adoc-filene dine i en mappe src/main/asciidoc/. Her samle lysbilder med diagrammer.
Konverter lysbilder til PDF
Selv om HTML-versjonen av lysbildene er ganske selvforsynt, er det fortsatt nødvendig å ha en PDF-versjon av lysbildene. For det første skjer det at på noen konferanser som ikke gir foredragsholderen muligheten til å koble til sin egen bærbare datamaskin, krever de lysbilder "strengt i pptx- eller pdf-format", uten å forvente at de også er i HTML. For det andre er det en god måte å sende arrangørene en uredigert versjon av dine lysbilder slik de ble vist i rapporten, i PDF-format for publisering av filen i konferansemateriellet.
Heldigvis håndterer Node.js-verktøyet denne oppgaven. , bygget på grunnlag — automatiseringssystemer for å administrere Chrome-nettleseren. Du kan konvertere RevealJS-presentasjonen til PDF med kommandoen
node decktape.js -s 3200x1800 --slides 1-500
reveal "file:///index.html?fragments=true" slides.pdf To triks ved lansering av decktape, som vi måtte finne på gjennom prøving og feiling:
-
oppløsning via parameter
-små spesifiseres med dobbel margin, ellers kan det oppstå problemer med konverteringsresultatene -
i URL-en til HTML-versjonen av presentasjonen må du sende en parameter
?fragments=true, som vil opprette en separat PDF-side for hver mellomtilstand i lysbildet ditt (for eksempel fem sider for fem punktpunkter hvis de vises etter hverandre). Dette vil tillate deg å bruke en slik PDF alene som en presentasjon under en rapport.
Automatisk montering og publisering på nett
Det er praktisk når lysbilder kompileres automatisk når det gjøres endringer i versjonskontrollsystemet, og enda mer praktisk når automatisk kompilerte lysbilder legges ut på Internett for offentlig bruk. Lysbilder fra Internett kan enkelt "spilles" foran et publikum fra hvilken som helst maskin koblet til Internett og en projektor.
Siden vi bruker GitHub i arbeidet vårt, er det naturlige valget av et CI-system , og for å være vertskap for ferdige presentasjoner - . Ideen bak github.io er at alt statisk innhold legges ut til en filial gh-pages av prosjektet ditt på GitHub, blir tilgjengelig på <ваше имя>.gihub.io/<ваш проект>.
Fullfør TravisCI-konfigurasjonsfilen, inkludert kompilering av HTML-versjonen av siden ved hjelp av Maven, konvertering til PDF ved hjelp av decktape, og opplasting av resultatene til en tråd gh-pages for publisering på github.io, ser ut som .
For å bygge et slikt prosjekt på TravisCI-siden, må du konfigurere miljøvariabler
GH_REF— verdi som github.com/inponomarev/csa-hbGH_TOKEN— GitHub-tilgangstoken. Du kan få det fra GitHub i profilinnstillingene dine, Utviklerinnstillinger -> Personlige tilgangstokener. Hvis du laster opp en presentasjon til et offentlig depot, er det nok for denne token å spesifisere det eneste tilgangsnivået "Tilgang til offentlige depoter".GH_USER_EMAIL/GH_USER_NAME— navn/e-postpar på vegne av hvilket push til tråden vil bli utførtgh-pages.
Dermed resulterer hver commit av presentasjonskoden på GitHub i at lysbildene automatisk blir gjenoppbygd i HTML- og PDF-formater og lastet opp på nytt til github.io. (Selvfølgelig bør du bare laste opp til github.io de presentasjonene du til slutt vil gjøre offentlig.)
Eksempler på prosjekter
Til slutt, her er lenker til et par eksempler på presentasjonsprosjekter med tilpassede Maven-skript og CI-konfigurasjon for Travis-CI, som kan klones og brukes når du lager dine egne presentasjonsprosjekter:
-
(mitt foredrag for JPoint 2019)
-
(min rapport for Heisenbug 2019)
Farvel Powerpoint! Jeg tror aldri jeg kommer til å trenge deg for tekniske presentasjoner :)
Kilde: www.habr.com