読者です 読者をやめる 読者になる 読者になる

空飛ぶ機械学習

機械学習やWebプログラミングのお話

Qiitaのスライドモードから分かる文書構造の重要性

エンジニアにとってはおなじみの情報共有サイトQiitaにはスライドモードなる機能が実装されている。

参考: スライドモード(Qiita公式リンク)

これはMarkdown記法で書いたものをスライドにしてくれる機能である(ページの区切りは 「---」 で判定される)。 当たり前であるがQiitaはMarkdown記法に対応しているので記事を書きながらにしてスライドも作れるという代物である。

この機能がリリースされたのは2016年6月であり、もう半年以上経過しているがそれほど流行っている印象はない。 だが、この機能をいち早く扱えるようになることは非常に重要である、というのがこの記事の主張だ。

公式によると、この機能は下記のような位置づけらしい。

デザインよりも中身を重視

慣れているMarkdownで手軽に書きたい

プレゼンの30分前にあわてて用意するようなとき用

あくまでサッと書くことを重視しており、例えば、フォントサイズの調整機能などはない。 PowerPointKeynoteのような凝ったスライドは作れないというか、そんなスライドを作ることを目的としていないのだ。

なので、ちょっとした発表で使う場合には非常に有用である。記事を書きながら同時にプレゼン資料を作ることができるようになるのだ。 同じことをPowerPointなどのツールを使ってやろうとすると得意な人でもより多くの時間がかかってしまう(そもそもPowerPointなどのツールはあまりに高機能すぎるのだ)。

なぜなら我々はキレイなプレゼン資料を見ることには慣れているので、ちょっとでも統一性がなかったり、汚い部分があるとかなり目立ってしまうからだ。 しかし、スライドモードは文字の位置調整などはハナから出来ないのでズレようがないし、何よりシンプルな資料という前提なのでオーディエンスの期待値も大きくなりにくい。

というわけで、みなさんもこの機能を使いこなしてい欲しいの(何よりMarkdown記法が広まることを願う)だが、この機能の真に優れている点は、簡単にスライドがつくれるということではない。

重要なポイントは「文書構造を意識せざるを得なくなること」である。

文書構造とは文字通り文書の構造のことであるが、要するに章や節、項といった構造をいかに作るかという話だ。 文書の階層構造でも構わない。理系の論文をイメージすると良いだろう。

スライドモードの機能を生かすにはこの文書構造をしっかりしないといけない。これがスライドモードがそれほど普及していないことの要因ではないかと思う。 プレゼンテーションツールであれば嫌でもページ1枚を意識することになるので、おのずと適正なページ構成になっていくが、Markdown自体は単なる文書なので区切りを意識しにくいわけである。

文書構造がうまくできていればスライドの区切りも明確になる。

区切りが分かりやすいと読む側にとってのメリットが大きい。 Qiitaの記事は1ページに全て表示されるので、記事の内容が長いといちいちスクロールしながら読むことになる。これは視覚からの情報量が大きい上に、情報の判別がしにくい。 もちろん文書構造がしっかりしていれば問題ないのだが、Qiitaにはダラダラと記述している記事も多いのも事実だ。

(見てくれではなく内容的な意味で)プレゼン資料を作るのがうまい人は文書構造をきっちり作っているんだけどね。

ところで、Marpという、これまたMarkdownでスライドが簡単に作れるツールもあるのだが、Qiitaのスライドモードと相性が良い。 これについてはまたいつか紹介する。

初めてのOSS開発に挑戦してみたという話

OSS(Open Source Software)という言葉を聞いて久しいが、先日先日「OSS Gate」という取り組みに参加してきた。

この取り組みは、OSS開発する人を増やそう、特にOSS開発をやってみたいけど自信がないなどの理由でやることができていない人を導いていこうというものである。もちろん既にOSS開発を行った人の継続的な活動を盛り上げていくことも狙いの一つである。

初参加だったので何をするのかもよく考えないまま参加してきたのだが、非常に良かった。というのもOSS開発の一歩を踏み出すことができたからだ。

実装にやった内容は気になっているアプリケーションの環境構築をしたところで止まっており、ソースコードに手を加えるなどはできなかったが、ともあれ手を付けたのだ。この違いは大きい。

そのアプリケーションはElectronによって実装されており、その技術の理解はあまりないのだが、これをきっかけに習熟出来るかもしれない。まあスキルアップはあくまで副産物的なもので真の目的はそのアプリケーションに自分の欲しい機能を搭載することなのだが。

作業はメンターとペアになって進めていったのだが、共同作業の効用の高さに驚いたのも参加してよかった理由の一つだ。助言をしてくれるだけでなく、単純に近くにいるので頑張れる。また、自分の作業内容や意図をメンターに説明することによって、やはり自分の理解が進むのである。素晴らしい。

総じて非常に生産性の高い時間だった。次回も参加しようと思う。

紙とペンで文章を書くという行為

ニュースでもなんでもなく、ただ自分が気にしていたトピックを扱った記事をたまたま数件読んだ。 あまりブログやニュース記事は読まない質であるが、何人かのお気に入り執筆者はいるわけで、彼らが偶然にも同様のトピックについて記述していたのだ(もちろん同日に書いたわけではなく私が見かけたのが同日だったというだけである)。

さて、そんな日になんとなくノートを広げてペンを握り、そのテーマとなるワードだけを書いた。 ワードを書いたときには、そのテーマについて一言書こうと思ったのだろうが、本当は別の文章を書いていて、急にそのワードが降りてきたからとりあえず書いただけだ。気づいたら400文字くらいの文章を書いていたことに驚いたという話である。

人は、紙とペンがあるときにテーマが与えられると文章を書けてしまう生き物なんだなあ。

文章の質はさておき、重要なのは手書きだとなぜか書けてしまうということだ。なぜこうなるかといえばいくつか理由があるはずだ。 ぱっと思いつくのは、手書きの方が気が散りにくいから。(ワープロではなく)パソコンをつかうと、いろいろ気が散る。別に文章を書かなければいけないわけでもないのだから尚更だ。

また、キーボードだと削除することが簡単なのですぐ削除してしまうが、何度も削除を繰り返すことがストレスだから文章が完成しないのだとも思う。タイピングの精度が95%でも大体100Keyに5Keyくらい起こすわけだが、1回でもミスをすれば文章として成立しないのが普通なので当然削除キーを押すことになる。簡単に削除or復元できるとはいえ、目の前で書いた文章を消すのは耐えられないのだろう。ところが手書きだと、これに相当する事象がない。もちろん書き間違えは起こるが、頻度はタイピングに比べればかなり小さいし、何か文章が変でもむりやり繋ぐことができてしまう。文章の質よりもひとまず文章というものが生き残る方が大事なんだろう。

この文章を書きながらもっともらしい理由をでっちあげたが、本当の理由は違うところにある。 パソコン(キーボード)では文章をサラサラ書けなくても手書きだとなぜか書けてしまう本当の理由は経験の差だ。考えればすぐわかることだが、日本人はとりあえず与えられたテーマで文章を書く訓練をかなりしている。というかやらされている。しかも制限時間内にある程度の文章が書けないと落第になったり、自分の時間が削られてしまうので結構頑張る。仮に小学校1年生から高校卒業で考えても12年のキャリアがある(小学校以前や高校卒業後もあるので実際にはもっと多いはず)。これに対してキーボードで文章を書き始めるのは紙とペンよりもずっと遅いし、その量も少ないだろう。

ノートを広げて、何か一つテーマとなる文言を書いてみて欲しい。

画像サイズがバラバラのギャラリーと画像のminify

知人に依頼された仕事で、画像サイズがバラバラ(横長や縦長、大小さまざま)なときの画像ギャラリーの作成に悩む。

画像の枚数が少なければSlickとか使ったスライダーでいいと思っていたんだけど、20枚近くあるもんだから微妙な感じ。自分の中では6枚くらいまでならスライダー、16枚くらいまでならサムネイル表示系のギャラリーという考え。

スライダーは画像サイズバラバラでも中央に合わせればそれっぽいから良いんだけど、枚数が多いと画像の表示回数の差が開きすぎる印象。だからある程度増えたらいわゆる画像ギャラリーにすれば解決なんだけど、画像サイズが整っていないと汚く思える。

こういうときの画像サイズはどうするべきなんだろうか。考えた対策は次の3つ。

  1. スライダーで画像をランダムに表示する作戦
    • 各画像の表示回数のばらつきを減らす
  2. Pinterest的なUIにする作戦
    • 縦長な画像の対策がメイン
    • 画像はそれなりの大きさで一覧できる
  3. 無理やり並べて画像ギャラリーにす作戦
    • パッと見は整って見える
    • クリックかマウスオーバーで画像拡大

色々迷った結果、Pinterestチックな画像ギャラリーが作れるsnapGalleryを選択。縦長画像をそれっぽく並べればマージンもあまり気にならないように出来た。ただちょっと縦に長くなるので、悩みは継続中。

そして、画像が大きすぎて読み込みが遅い問題も発生。圧縮せねば。 自分のプロジェクトだったらGulp使って自動で各種minifyをするんだけど、今回の仕事は単なるWebページなのでちまちまやりますか。