MarpでAzusa3が使いたくてテーマを作った

いわゆるプレゼン資料というものが必要になるとき、ここ数年はMarp を利用している。

marp.app

普段からなにか文書を書くときにmarkdownを利用することが多いので、markdownでアウトラインを書けばそれがそのまま資料として成立するとか、ソースコードを載っけるときの例の記法がそのまま使えるとか、まあ要するに手に馴染んだ道具をそのまま使えるのが嬉しいのだ。

テーマもオフィシャルのものが使いやすくて特に不満もなかったのだが、sanographixさんが公開されている、Azusa 3というKeynote/Google Slide向けのテンプレートがかっこよく、使ってみたいなぁと思って、Marp向けのテーマとして作ってみることにした

azusa3.sanographix.net


で、作ったのがこちら。ベースにしたのはMarpのオフィシャルテーマの一つのgaia

github.com

自分が使いやすいテンプレートであることを第一に作ったので、カラースキームやフォントは、Google Slide版の仕様を踏襲してある(日本語フォントはヒラギノを指定するわけにも行かなかったので、Noto Sans JPを採用)ものの、段組みレイアウトなどは未対応だったり、引用のレイアウトは大きく改変していたりする。

せっかくだから公開してみます、興味のある方はどうぞご自由にお使いください。

Scala関西Summit2018に参加してきた話

blogに書くまでが勉強会らしいので書きます

参加したセッションと感想

どっちも聴きたいというのが結構あったけど、迷ったときは後述する動機に基づいて選択しました。

長期的なメンテナンスの必要なScala製システムにおいて気をつけるべきこと

Scalaに限らず直面する問題。

個人的に印象的だったのは

  • 技術選定は慎重にする
  • Javaで書いても複雑にならないようなものはJavaで書いてしまう
  • 可能な限りライブラリに依存しなくて良いようにする
  • Scalaは言語として、変化を恐れないという部分があるため、その哲学を受け入れましょう

前者3つはトレードオフの話。盲目的にならず「何故その選択をするのか」を明確にするということ。

最後の1つは心構えみたいな話ですけど、「変化を恐れない」というマインドと余裕を、自分でもチームでも持ち続けたいなと、改めて思った。

明日から使える実践エラーハンドリング

アプリケーションコードにおけるエラーハンドリングの話は純粋に興味のあるところでもあるし、最近社内の勉強会でほとんど同じモチベーションのLTをやったというのもあって聴講。

Try/Eitherの使い分けは、自分では「Javaが投げる検査例外を扱うときだけTry、それ以外はEither」くらいの感覚だったけど、明確に言語化されたものを聞くと改めて学びがあって非常にありがたかった。

発展編として挙げられていた「継続渡しスタイル」がすごく気になるので勉強しようと思う。

ZOZOSUITはScalaで動いてるよ!

一番目からウロコだったのはScalaの話でも何でもないんですけど

  • チームリーダーがプロダクト要件として正しいかどうか担保する
  • テックリードが言語として正しいかどうかを担保する

という、コードレビューにおける「ダブルレビュー」という体制の話。

もともとScala書ける人が多かったんですよね、というお話は純粋に羨ましくもあり。

Akka HTTPで構築するシンプルなAPIサーバ

プロダクト環境で利用したことがあるのはSkinnyFrameworkだけだったということと、Sprayのときにちょっとだけ調査したこともあって気になっていたライブラリ。個人的に軽量フレームワークが好きっていうのもある。

後方互換性に結構気を使ってくれるライブラリというお話をされていて、プロダクト環境で利用する際には、選択の材料としてかなり大きなアドバンテージだと感じた。

out-of-boxなwebフレームワークは確かに便利なんだけど、使わない機能があったりとか、あとから要件と合わなくなってきたときがしんどい、みたいな話には完全に同意。

次に何かイチから構築する、となったときはAkka HTTP + ScalikeJDBCでシンプルにやりたいなーという思い。

エンタープライズScala

Scalaを導入する際の勘所としてこういうのがありますよ、という感じの発表。

Scalaのここすき」をちゃんと伝えられるようになりたい。

PHPエンジニアによるScalaエンジニアへの転身とその手引き

という、多くの「分からないこと」に対して

  • 一度に多くのことを学ばない
  • 社内教材や習作による段階的な学び

によって対処したよ、というお話。

自分がどうやってScalaを学んできたか、どうやって後輩(に限らないけど)に教えたか、と振り返る機会になったし、段階的な手引きを提供できていなかったな、と反省。知識を整理するためにも、復習の必要があるなという感じ。

変位指定についてわかりやすく解説させてください

最近この本で変位指定を完全に理解したので何もわからなくなりたかった*1

実践Scala入門

実践Scala入門

型パラメータの変位指定、定義したことはなかったけどなんとなく知ってる、くらいだったので、聴きたかった。

発表中に「mutableなクラスに共変な型パラメータを指定すると型安全性を壊す可能性がある(だからscala.Arrayは非変)」というお話があって、ずっと疑問だった「Javaジェネリクスでは変位指定に相当することを定義できないのは何故か」、に対して「javaのクラスはデフォルトがmutableだから」という理解を得た気がしたので、その旨を質問してみたが「Javaジェネリクスでは変位指定に相当することを定義できないのは事実だが、理由については分からない」ということだった。

懇親会の際に何人か交えて改めてお話する機会があって「歴史的経緯含めて何故そうなっているのかを知るというのは本質ではなかったりするよね」という話になった。確かにそうですね。真摯にお応えいただいてありがとうございました。

実践GraphQL on Scala

GraphQL気になっていたから、というのと、最近感銘を受けたこの記事

fringeneer.hatenablog.com

を書いた人の発表だということで聴講。

I/Fを型定義できるメリットや、Scalaの型システムとの相性の良さについて、また「主観」とはおっしゃっていたけど、どういう場面だと有効かという考察もあり、「使えそう、使ってみたい」と思える内容だった。

動機の話

まあ何かっていうと、この1年位でScalaのチームからJavaのチームへ異動したっていうのと

  • Scalaの方が楽だったな
  • 今のチームでもScala導入できないだろうか

みたいなお気持ちがあった、というのと、かといって「Scala触ったこともあるけど、別にJavaで困らないなと思ったよ」というチームに対して「どうしてJavaでもKotlinでもなくScalaなのか」を明確に説明できるかというとそうでもないな、というのがあり、自分で明確に言語化できるようにしたかった、というモチベーションで臨みました、という話。

だから6年放置してたらしいblogも書いた。

ディスプレイを変態してみた

このエントリはHENTAI Advent Calendar 2012 - 変態アドベントカレンダー -の21日目です。
昨日は@posauneid:posaunehm)さんのJavaをC#に変態させる。でした。

そも、変態とは何か

調べてみました。

へん‐たい【変態】
[名](スル)
1 形や状態を変えること。また、その形や状態。

*1*2
ということで、何かを変態させることにします。

何を変態させるか

ちょうど僕の目の前には、具合の悪くなった液晶ディスプレイがあります。ただ捨てるというのも忍びないので、こいつを何かに変態させようと思います。

構造を見てみる

変態させるにしても、中身がどんな具合か分からないことには変態させることができません。気前よくエイヤとバラして構造を確かめてみます。

液晶ディスプレイの構造

こんなんでました(写真無いです)

  • 制御基板
  • 液晶パネル
  • 発光部
  • あとは筐体

発光部は、蛍光灯のような管とパネルで構成されています。前者を冷陰極管、後者を導光板と云います。気前よくバラした余波を受けて、冷陰極管は割れました。

何に変態させるのか

構造が分かったところで、何に変態させるか決めようと思います。

利用する部品の選定

色々部品が出てきましたので、これらをどう利用できるか考えてみます。

制御基板類
制御基板は液晶ディスプレイを構築することに最適化されていますので、これを利用してもできあがるのは液晶ディスプレイでしょう。今回の目的は修理ではなく変態なので、こいつは使わないことにします。
液晶パネル
液晶パネルを利用しても出来上がるのは液晶(ry
発光部
冷陰極管は発光部として使えそうですね、ただし割れてしまっては使いようが無いので、こいつも利用しないことにします。
導光板
冷陰極管は割れてしまいましたが、光源を入れてやれば面光源として利用できそうです、これが何かに使えそうですね。

トレス台に変態させることにしましょう

皆様ご存知の通り、面光源を利用するものとしてお馴染みなのは、やはりトレス台です。
ということで、今回は液晶ディスプレイをトレス台に変態させることにします。

変態レシピ

変態させるものも決まったので、材料を用意します。
とは言え今回必要な物は光源となるものだけです。これにはもう1セット冷陰極管を用意してもいいですが、せっかくだから今回は最近普及しているLEDバックライト液晶に倣って、LEDを光源として用いることにします。

用意するものは以下の4つです

  • LED
  • 抵抗
  • 電源
  • 生基盤

LEDを選ぶ

LEDといえばこんな形のもの

がよく知られていると思いますが、冷陰極管が収まっていたスペースに回路込みでこいつを収めるのはなかなか難しそうです。↓

そこで今回は、下のような「チップLED」というのを使うことにします。

白色チップLED UW1143B - 秋月電子通商

基盤を選ぶ

続いて基盤を選びます。素材はガラスエポキシとか紙フェノールとか、色々ありますが、ここで問題になってくるのは実は厚みだけなので、LEDの厚みとの組み合わせで好きなモノを選べばいいです。
先ほどのLEDの厚みが大体2mmくらいなので、今回の場合、基盤の厚みは1mm〜1.5mmくらいであればよさそうでしたので、どこでも売ってる紙フェノール基盤の1.5mm厚のものを利用しています。

抵抗を選ぶ

LEDを発光させるには、大雑把に以下のような回路を組めばいいですが、適切な抵抗値の抵抗を挟んでやらないと、光らなかったり焼き切れたりしてしまいます。

抵抗値は使うLEDの電気特性から計算しますが、このあたりの話は秋月電子通商さんに詳しい説明があるので割愛します。*3

今回は、抵抗値75Ωの抵抗を用意することにしました。もちろんこんな形

の抵抗では隙間に収まらないので、こちらも「チップ抵抗」というのを使います

電源を選ぶ

今回は以下の回路を12個並列にして光源として用いることに決めました。

電源は12V/1.0Aくらいで十分そうだったので、この要件を満たすACアダプターを利用することにしました。

変態作業

いよいよ液晶パネルを変態させるべく実際の作業に入ります。
おおまかな流れは「基盤を作成する」→「ハンダ付けをする」→「組み込む」→「おわり」です

基盤を作成する

まずは基盤を作ります。
スペースに収まるよう細く切った基盤の上に、以下のパターンを描きます。

白い部分が導通箇所、黒い部分が非導通箇所です。このパターンによって先ほどの回路を実現することができます。
パターンを基板上に描く手法はいくつかありますが、一番簡単なのはアクリルカッターで銅箔部分を削り取る方法だと思います。

ハンダ付けをする

特筆すべき箇所はあまり無いですが、LEDや抵抗を据え付ける部分に、予めハンダを盛っておくと捗ります。LEDの陽極と陰極を間違えないように気をつけて作業しましょう。

出来上がった基盤がこちらになります。

……あまりハンダ付けがうまくないのはご愛嬌というところで一つご勘弁

組み込む

あとは発光ユニットを導光板ユニットに組み込めば、作業完了です。

レールに収めて

導光板ユニットに差し込みます

バラックですが、電源を組み付けます

_人人 人人_
> 突然の光 <
 ̄Y^Y^Y^Y ̄

……いくつかLEDがお亡くなりになっているのが気になりますが、見事液晶パネルはトレス台へと変態を遂げました。

今回のまとめ

  • 液晶パネルを分解してトレス台に変態させました

このトレス台で皆様のTDD(Trace Driven Designworks:トレス駆動デザイン)ライフが実り多きものになりますようお祈りいたします。

明日は@SatohJohnさんです。

*1:http://dictionary.goo.ne.jp/leaf/jn2/200474/m0u/

*2:引用は恣意的です

*3:http://akizukidenshi.com/download/led-r-calc.pdf