ここ最近はプレゼンテーションスライドを用意する時は reveal.js を使っています。Markdown で内容を書けるので便利なのですが、個人的には書き始めが億劫というネックがあります。ディレクトリを作って reveal.js のファイル一式を最初に用意するのがちょっとしたことなのですが面倒くさいのです(自分用に若干アレンジしたサンプル一式をコピーする作業)。
Markdown で書けるもので、かつもうちょっとさくっと書けるツールがあるかなと探してみたところ Deckset for Mac が良さそうなので使ってみることにしました。
Deckset 方言の Markdown で記述したファイルを1つ用意すれば Deckset でスライドとしてレンダリングしてくれるのでお手軽。Deckset アプリ自体には Markdown エディタは内蔵されておらず Emacs や Atom など好みのテキストエディタで編集するスタイルというのも良いです。テキストエディタ側で保存すると Deckset 側が更新を検知してスライドを更新してくれます。
スライドに使う画像は URL で指定することができる(そして推奨している)ので、ローカルディレクトリに用意してという必要がありません(もちろん Markdown ファイルと同じディレクトリに用意して読み込ませることもできます)。「プレゼンテーション時にネットワークにつながっていなかったり URL 先から消えていたら困るのでは?」というのが気になるところですが、 Deckset 側でローカルホスト上にキャッシュしてくれるので大丈夫になっています。
テーマは Deckset が用意しているものから選びます。欧文系らしいちょっと派手なのが多く、個人的に使えるなというのはそれほど多くない印象です。個人的には Titillium がいちばんしっくりくるかなと。
PDF ファイルや画像でエクスポート可能なので困ることはなさそうです。
スライドの冒頭にそのスライドの設定を書いておくことができます。
theme: Titillium,1 footer: [各ページ下部のフッタに載せたい文字列] slidenumbers: true autoscale: true
が良さそげ。
reveal.js と比べて良いなというところは以下です。
reveal.js では Web ブラウザで表示するため縦横比が変わる前提である程度余裕をもってページを書く必要があるのですが、Deckset はそこを気にしなくて良いのが楽です。CSS や JavaScript コードをいじれる reveal.js に比べると細かいカスタマイズは全然できないのですが、その分デザインは Deckset に任せると割り切って内容だけに集中してさくっと書けます。
reveal.js が便利なところもあるのでプレゼンテーションシーンに合わせて使い分けることにします。
(画像は http://www.decksetapp.com/ より。)
昨日から Roofpig という Web ブラウザ上でルービックキューブの手順アニメーションを表示させる JavaScript プログラムを使ってメモを書いてみています。
自分で図を書かなくて良いので便利。
Google 日本語入力だとどうも片手で入力しづらい。 ATOK を入れてフローティングキーボードにしたら、寝転んで入力するの便利になりました。
ノート/メモははライティングアプリ Ulysses を使い Markdown で書いていて、検索・閲覧・整理も Ulysses で基本済ませています。ただいくつかの良く参照するファイルはブックマークやハイパーリンクから Web ブラウザでさっと表示させたかったりします。なので以前は Plack::App::Directory::Markdown を使った自作 PSGI アプリケーションを使ってました。
が、セットアップしたり保守したりという手間を今とれないなと思って、 Markdown ビューアを探してみたところ MkDocs が良さそうなので試してみました。
MacBook Pro に Homebrew で入れて動かしてみます。
$brew install MkDocs $mkdir -p ~/var/mkdocs $cd ~/var/mkdocs $mkdocs new local $cd local $mkdocs serve
で Web サーバが立ち上がるので http://127.0.0.1:8000/ にアクセスすると ~/var/mkdocs/local/docs/index.md の内容を HTML に変換したものが表示されます。お手軽! 設定変更は ~/var/mkdocs/local/mkdocs.yml できます。
あとは docs の下に Markdown ファイルを置いておけば Web ブラウザで閲覧できます。docs の下に既存の Markdown ファイルノートディレクトリへシンボリックリンクを作ればそれらも辿って表示されます。
試していてブラウザでのレンダリング表示が重いなと思って HTML ソースを見たら同じ JavaScript ファイルを何十回も読み込んでいて何か変ぽかったので Homebrew のをやめて pip で入れなおしました。どちらも現在 mkdocs 0.17.2 ですが pip で入れた方は問題なかったのでこちらを使うことにします。
$brew uninstall mkdocs $brew install python $pip2 install mkdocs
MkDown は静的サイトジェネレータで、プレビューサーバは補助的機能ですがまずまず使えそうです。
ちょっとしたメモを Alfred for Mac から一発で TaskPaper ファイルに挿入したい。Packal 上に TaskPaper のための多機能な Alfred Workflow があるので入れたんだけれど、うまくタスク追加ができないことがあるので、自前でスクリプトを作って Alfred から呼ぶことにした。
TaskPaper ファイルはテキストファイルなので書き慣れている Perl でスクリプトを書いてもいいんだけれど、 編集の競合が避けられるし parser も書かなくて済むしということで TaskPaper の API を使うことにした。
JavaScript for Automation (JXA) を使えば JavaScript コードで TaskPaper API を呼べるっぽい。
以下指定した TaskPaper ファイルに Inbox: プロジェクトがなければ追加した上でその子供としてノートを挿入するコード(エラー処理割愛。実際にはタイムスタンプとかもノートにつけるようにした)。
#!/usr/bin/env osascript -l JavaScript function TaskPaperContext(editor, options) { let inbox = editor.outline.evaluateItemPath("//Inbox:")[0]; if (!inbox) { inbox = editor.outline.createItem("Inbox:"); let projects = editor.outline.evaluateItemPath('@type = project') if (projects.length == 0) { editor.outline.root.appendChildren(inbox) } else { editor.outline.root.insertChildrenBefore(inbox, projects[0]); } } let items = ItemSerializer.deserializeItems(options.text, editor.outline, ItemSerializer.TEXTMimeType) editor.setCollapsed(items[0]) inbox.appendChildren(items, inbox.firstChild) } function run(argv) { Application('TaskPaper').open(argv[0]).evaluate({ script:TaskPaperContext.toString(), withOptions: {text: argv[1]} }) }
これを inbox.scpt というファイルで保存し実行権限を与えれば
./inbox.scpt $HOME/tmp/test.taskpaper こんにちはこんにちは!!
という感じで呼び出せるようになる。
あとは Alfred Workflow を作ってそこからこのスクリプトを実行すれば OK だ。
Web サイトの移行の話が出た流れで、この Web 日記についてちょっと考えたりした。
Perl で書いた自作の日記システム (CGI プログラム) で問題なく動いているが、手を入れずに使い続けているので将来環境(Perl やライブラリ)のアップデート時にハマるのではというのがあると、このまま記事が増え続けた時に問題が起きるのではというのがあり、気掛かりではある。
配信環境に依存しないように静的サイトジェネレータで生成する形に変えたらいいのではと、以前から思ったりしている。
ちょっとしか使ったことがない JavaScript を学ぶ機会としても Next.js とかどうかなとちょっと調べてみた。
個別記事ページを静的ページとして生成するのはいいとして、自動リンク機能で実現しているキーワード別ページとそのページングがちょっと厄介そう。やれるとしても今の URL 体系も一部変えなければいけないな。
Obsidian Publish サイトの下部にある Powered By Obsidian Publish フッタを publish.css で非表示にしていたのだけれど、せっかくなので著者表示に差し替えてフッタを表示することにした。
Obsidian vault のルートに publish.js ファイルを作りコードを書き、公開対象に追加してパブリッシュ。規定のファイル名だから自動的に公開対象になるだろうと勘違いして最初あれっとなった。 publish.css の時も同じように勘違いした記憶があるな。
JavaScript でコードを書けばあれやこれや出来る訳だが、あまりやりすぎると将来メンテナンスが面倒になって困ることになるので、ほどほどにしとこ。
HTML ページ中の mermaid 定義を自動的にクライアント側で SVG 変換し表示させるのが動いていないのに昨日気づいた。 initialize がうまく動いていいないっぽい。 Cloudflare の Rocket Loader をオフにしたら再び動くようになったのでそれが原因のようだ。
How can I have Rocket Loader ignore specific JavaScripts? – Cloudflare Help Center
によると
<script data-cfasync="false" src="/javascript.js"></script>
のように data-cfasync を指定するとそのスクリプトの読み込みを最適化から除外するらしい。
今回は HTML ファイル中に直接 script 要素で埋め込んだコードが動かなくなったので
<script data-cfasync="false" type="text/javascript"> ... // Rocket Loader オンで動かなくなったコード </script>
のように追加してみたところ Rocket Loader をオンにしても動くようになった。高速化のため、できれば Rocket Loader をオンにしておきたかったので良かった良かった。
本線合流#photography
— Naney (@Naney) October 12, 2021
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/eyxfSErlmb
publish.twitter.com でコードを生成して Web 日記に Tweet を載せている。その際 JavaScript コード読み込みの script 要素が入った状態でそのまま貼り付けていたので、1ページに複数表示される場合にちょっと無駄が生じていた。
ので、1度だけの読み込みで済むように公式サイトのコードを今日ようやくフッタに埋め込んだ。
https://developer.twitter.com/...
これで各記事内の Tweet 埋め込みコードから script 要素を消していける。数があるのでちょっとずつやっていくことにしよう。
それから Obsidian Publish サイト nNodes の publish.js にも同じようにコードを追加し、 nNodes 内にも Twitter フォローボタンを追加してみた。 Tweets もこれで載せられるね。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。