Jag tror att jag har hållit dussintals presentationer för kollegor, kunder och föreläsare under min IT-karriär. Powerpoint har under många år varit ett naturligt och pålitligt val för mig som verktyg för diaproduktion. Men i år har situationen förändrats kvalitativt. Från februari till maj hade jag möjlighet att tala vid fem konferenser och bilderna till rapporterna fick förberedas på kort tid, men med hög kvalitet. Frågan uppstod om att delegera den delen av arbetet som rör den visuella utformningen av rutschbanorna till andra. Jag försökte en gång arbeta med en designer och skickade .pptx-filer med post, men arbetet förvandlades till kaos: ingen visste vilken version av bilderna som var den "nyaste" och layouten "rörde sig" på grund av skillnaden i Powerpoint versioner och typsnitt på våra maskiner. Och jag bestämde mig för att prova något nytt. Jag provade det, och sedan dess har jag inte tänkt på att gå tillbaka till Powerpoint.
Vad vill vi ha
För ungefär ett och ett halvt år sedan slutade vårt företag att använda Word för att skapa projektdokumentation, efter att ha stött på samma problem: även om Word är bra för att skriva in ett litet dokument, när volymen växer, uppstår svårigheter med samarbete och att få hög kvalitet och enhetlig design. Vårt val föll på , och vi slutar aldrig att glädjas åt detta val, men det här är ett ämne för en separat artikel. Ungefär samtidigt lärde vi oss effektiviteten hos en av DevOps-principerna för "allt som kod", så valet av krav för den nya tekniken för att skapa presentationsbilder var ganska uppenbart:
- Presentationen måste vara en vanlig textfil på ett märkningsspråk.
- Våra bilder handlar om utvecklingsprojekt, så uppmärkningen ska göra det enkelt att infoga, utan att tillgripa externa system
- kodfragment med syntaxmarkering,
- enkla diagram i form av geometriska former förbundna med pilar,
- UML-diagram, flödesscheman och mer.
- Presentationsutkastet ska lagras i ett versionskontrollsystem.
- Validering och montering av färdiga objektglas bör göras i ett CI-system.
Idag finns det två grundläggande alternativ för att skapa bilder i märkningsspråk: paket för LaTeX eller ett av ramverken för att skapa bilder med HTML/CSS (, , och många andra).
Även om min själ ligger i LaTeX, dikterade mitt sinne att valet av en lösning som jag inte skulle vara den enda som använder borde ligga på sidan av en lösning som är bekant för en bredare krets av människor. Alla känner inte till LaTeX, och om din dagliga praxis inte är relaterad till att skriva vetenskapliga artiklar, då är det osannolikt att du har tid att fördjupa dig i det här systemets enorma, intrikata värld.
Att behärska HTML/CSS är dock inte precis en utbredd färdighet: jag är till exempel långt ifrån fullt skicklig i det. Lyckligtvis kommer den redan välbekanta AsciiDoctor till undsättning: en omvandlare låter dig skapa RevealJS-bilder med AsciiDoctor-uppmärkning. Och det är lätt att lära sig och tillgängligt för alla!
Hur man kodar bilder
För att förstå essensen av att koda bilder på AsciiDoctor är det enklaste sättet att ge specifika exempel. Dessa är alla från faktiska bilder jag gjorde för mina konferenspresentationer i år.
En bild med en titel och en lista över objekt som öppnas efter varandra:
== Зачем нам Streams API?
[%step]
* Real-time stream processing
* Stream-like API (map / reduce)
* Под капотом:
** Автоматический offset commit
** Ребалансировка
** Внутреннее состояние обработчиков
** Легкое масштабированиеResultat
Rubrik och källkodsavsnitt med syntaxmarkering:
== Kafka Streams API: общая структура KStreams-приложения
[source,java]
----
StreamsConfig config = ...;
//Здесь устанавливаем всякие опции
Topology topology = new StreamsBuilder()
//Здесь строим топологию
....build();
----Resultat
Som förberedelse för ett föredrag genomgår koddemos upprepade revideringar och förbättringar, så möjligheten att snabbt kopiera och klistra in "råkoden" direkt i en bild är ovärderlig, vilket säkerställer att demon är uppdaterad utan att behöva oroa dig för syntaxmarkering.
Titel, illustration och text (layouten på bilden görs 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
Ibland behövs ingen titel, och för att illustrera din poäng behöver du bara en helskärmsbild:
[%notitle]
== Жить в легаси нелегко
image::swampman.jpg[canvas, size=cover]Resultat
Ofta behöver en idé stödjas av ett enkelt diagram, i form av "rutor förbundna med pilar." Lyckligtvis är AsciiDoctor integrerad med systemet — ett språk som låter dig beskriva grafdiagram baserat på beskrivningen av hörn och kopplingar mellan dem. Graphviz tar en inlärningskurva, men baserat på exemplen som tillhandahålls är det ganska enkelt att göra! Så här 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 de fall då det är nödvändigt att redigera bildtexten på figuren, ändra pilens riktning, etc., kan detta göras direkt i presentationskoden, istället för att rita om bilden någonstans och återinsätta den i bilden. Detta ökar avsevärt arbetshastigheten på rutschbanor.
Ett mer komplicerat exempel:
== Невоспроизводимая сборка
[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
Förresten, det är bekvämt att experimentera med Graphviz och felsöka bilder på sidan .
Slutligen, om du behöver infoga ett flödesschema, klassdiagram eller annat standardiserat diagram i en bild, då kan ett annat system integrerat med AsciiDoctor komma till undsättning, . Min kollega Nikolai Potashnikov skrev om PlantUMLs omfattande kapacitet .
Att förvandla presentationsprojektet till kod lagrad i ett versionskontrollsystem gör det möjligt att organisera gemensamt arbete med presentationen, först och främst för att separera uppgifterna att skapa innehåll och design. Utformningen av bilder (typsnitt, bakgrunder, indrag) i RevealJS beskrivs med CSS. Min personliga skicklighet med CSS förmedlas bäst av – men det är inte läskigt när det finns människor som arbetar med CSS mycket skickligare och snabbare än jag. Som ett resultat visar det sig att vi med en snabbt närmande deadline för en presentation kan arbeta på olika filer samtidigt via Git och utveckla en samarbetshastighet som är omöjlig när man skickar .pptx-filer med post.
Bygga en HTML-sida med bilder
Oformaterade textkällor är bra, men hur sammanställer du dem i själva presentationen?
AsciiDoctor är ett projekt skrivet i Ruby, och det finns flera sätt att köra det. Först kan du installera Ruby-språket och köra asciidoctor direkt, vilket förmodligen ligger närmast Ruby-utvecklare.
Om du inte vill bråka med att installera Ruby kan du använda docker-bilden , till vilken du, när den startas, kan koppla mappen med projektkällorna via VOLYM och få resultatet på en given plats.
Alternativet jag valde kan verka något oväntat, men det är det mest bekväma för mig som Java-utvecklare. Det kräver ingen installation av Ruby eller docker, men låter dig skapa bilder med ett Maven-skript.
Poängen är att projektet – Java-implementeringen av Ruby-språket är så bra att den låter dig köra nästan allt som skapats för Ruby i en Java-maskin, och att köra AsciiDoctor är en av de vanligaste användningsområdena för JRuby.
tillgänglighet låter dig samla AsciiDoctor-dokumentation som är en del av ett Java-projekt (som vi aktivt använder). Samtidigt laddas AsciiDoctor och JRuby ned automatiskt av Maven, och AsciiDoctor körs i JRuby-miljön: det finns inget behov av att installera något på maskinen! (Exklusive paket graphviz, som behövs om du vill använda GraphViz- eller PlantUML-grafik.) Placera helt enkelt dina .adoc-filer i en mapp src/main/asciidoc/. här samla bilder med diagram.
Konvertera bilder till PDF
Även om HTML-versionen av bilderna är ganska självförsörjande, är det fortfarande nödvändigt att ha en PDF-version av bilderna. För det första händer det att på vissa konferenser som inte ger talaren möjlighet att ansluta sin egen bärbara dator, kräver de bilder "enbart i pptx- eller pdf-format", utan att förvänta sig att de också är i HTML. För det andra är det bra att skicka till arrangörerna en oredigerad version av dina bilder som de visades i rapporten, i PDF-format för publicering av filen i konferensmaterialet.
Lyckligtvis hanterar verktyget Node.js denna uppgift. , byggd på basen — automatiseringssystem för hantering av webbläsaren Chrome. Du kan konvertera RevealJS-presentation till PDF med kommandot
node decktape.js -s 3200x1800 --slides 1-500
reveal "file:///index.html?fragments=true" slides.pdf Två knep när vi lanserade decktape, som vi var tvungna att komma på genom att trial and error:
-
upplösning via parameter
-småste anges med dubbel marginal, annars kan det bli problem med konverteringsresultaten -
i URL:en till HTML-versionen av presentationen måste du skicka en parameter
?fragments=true, som kommer att skapa en separat PDF-sida för varje mellanläge på din bild (till exempel fem sidor för fem punktpunkter om de visas efter varandra). Detta gör att du kan använda en sådan PDF ensam som en presentation under en rapport.
Automatisk montering och publicering på webben
Det är praktiskt när bilder kompileras automatiskt när ändringar görs i versionskontrollsystemet, och ännu bekvämare när automatiskt kompilerade bilder läggs ut på Internet för allmänt bruk. Diabilder från Internet kan enkelt "spelas upp" inför publik från vilken maskin som helst som är ansluten till Internet och en projektor.
Eftersom vi använder GitHub i vårt arbete är det naturliga valet av ett CI-system , och för att vara värd för färdiga presentationer - . Tanken bakom github.io är att allt statiskt innehåll postas till en filial gh-pages av ditt projekt på GitHub, blir tillgänglig på <ваше имя>.gihub.io/<ваш проект>.
Komplett TravisCI-konfigurationsfil, inklusive att kompilera HTML-versionen av sidan med Maven, konvertera till PDF med decktape och ladda upp resultaten till en tråd gh-pages för publicering på github.io, ser ut .
För att bygga ett sådant projekt på TravisCI-sidan måste du konfigurera miljövariabler
GH_REF— värde som github.com/inponomarev/csa-hbGH_TOKEN— GitHub-åtkomsttoken. Du kan hämta det från GitHub i dina profilinställningar, Utvecklarinställningar -> Personliga åtkomsttokens. Om du laddar upp en presentation till ett offentligt arkiv räcker det för denna token att ange den enda åtkomstnivån "Åtkomst till offentliga arkiv".GH_USER_EMAIL/GH_USER_NAME— namn/e-postpar på uppdrag av vilket push till tråden kommer att utförasgh-pages.
Således resulterar varje commit av presentationskoden på GitHub i att bilderna automatiskt byggs om i HTML- och PDF-format och laddas upp på nytt till github.io. (Naturligtvis bör du bara ladda upp till github.io de presentationer som du i slutändan vill göra offentliga.)
Exempel på projekt
Slutligen, här är länkar till ett par exempel på presentationsprojekt med anpassade Maven-skript och CI-konfiguration för Travis-CI, som kan klonas och användas när du skapar dina egna presentationsprojekt:
-
(mitt föredrag för JPoint 2019)
-
(min rapport för Heisenbug 2019)
Hej då Powerpoint! Jag tror aldrig att jag kommer att behöva dig för tekniska presentationer :)
Källa: will.com