日本語特化のBootstrapテーマ「Ayame」を作ってみた

  1. 1. きっかけ
  2. 2. やったこと
  3. 3. つまり
  4. 4. 実は
  5. 5. Ayame

Bootstrapテーマで日本語特化したものに「Honoka」というのがあって。
ちょっと最近Bootstrapテーマを使う機会があったため、HonokaをForkしてAyameというのを作ってみた。

きっかけ

現状でダーク系のテーマがみあたらなかったことがまず大きな理由。
それに加えてHonokaは凄く素敵なテーマだけど、個人的に日本語特化であればもうちょっと行間も調整すべきだし、
約物についても調整したい。さらにもっと個人的なことを言えば、日本語フォントは16pxだと少し小さいめな気がしてて、
できれば18pxぐらいが良いと思ってたから。

あいかわらずの自分で作ってしまえ精神。

やったこと

前述のとおり、行間、文字間の調整、YakuHanJPを使用、フォントサイズの拡大。がメイン。
色はダーク系にして、せっかくなので和風の配色をとりいれてみた。
「Ayame」は僕が大好きなゲームのキャラ、天誅から女性主人公の「彩女」より。
アヤメと菖蒲をかけて、メインの色を菖蒲色にした。

Fork元のHonokaはGruntでBower対応なんだけど、それはぜんぶぶったぎった。
Gulpにして、本当はnpmとかで配布したいとは思うけどまぁとりあえずそこはおいおいで。

Scssもぶったぎった。個人的にScssよりStylusのほうが好きだから。

つまり

つまるところ、かなりオレオレ仕様です。そもそも広く配布しようと思って始めなかったし、
なんかFork元とそのファミリーの命名が女性形なので、なんか適当に女性にするかー、
せっかくだから和風にするかー、日本語特化だし、みたいな感じ。

あと、リリースとかビルドとか配布とか関してももっと上手くやるべきだと思うんだけど、かなり粗削り。
まぁもともとがオレオレ仕様なものをついでに配布してみた、的なのでいいか。

実は

僕はBootstrapが嫌いだ。一番の理由はcol-6とかっていうクラス名を使うところ。
現状でのCSSフレームワークにおける最適解のひとつであろうことはわかってるんだけど、
クラス名というかHTMLのマークアップ側で確定したデザイン情報を持たせるのが良くないと思う。
マークアップは論理構造だけにすべきだ。

とはいえ、サクっとなんか作るときに、Bootstrap準拠のものがけっこうあったりして、
そこに労力を費やすべきじゃないこともしばしばあるので、今回のようにBootstrapを使うこともままある。

Ayame

忘れてました。リポジトリは以下。
一応リリースのところにCSSいれてあるので、そちらを使うか、Cloneでどうぞ。

ボドゲ「インカの黄金」のカードデザインが納得行かないので自作した

  1. 1. インカの黄金の面白さと問題
    1. 1.1. ルール
    2. 1.2. デフォルトカードの問題
  2. 2. よろしい、ならば作ってしまえ
    1. 2.1. コンセプト
      1. 2.1.1. バリアントルール「ダッシュ」
    2. 2.2. 自作
      1. 2.2.1. 出力
      2. 2.2.2. カット
      3. 2.2.3. 貼り
    3. 2.3. あとは遊ぶだけ

「インカの黄金」という割と定番でとっつきやすく楽しめるチキンレース系のボドゲは知ってるかい?ボドゲを普段やらない層でも簡単に理解できて楽しめるので重宝してるんだけど、どうしてもカードデザインが納得行かないので自作して改良する話。

インカの黄金の面白さと問題

ルール

ルールを簡単に説明すると、

  1. プレイヤーは探検家になって遺跡をみんなで一緒に探検
  2. ターン毎に進むのか帰還するのかをせーので選択
  3. 予想される状況は財宝か罠
  4. 獲得した財宝は罠にかかることなく生還しないと持ち帰れない(いわゆるチキンレース)
  5. 獲得人数で割り切れない財宝の場合、置いたままにして帰還する時にそのターンの帰還者数で割る

というのが主なルール。つまりギリギリまで粘って進み、かつ、帰還する時は他プレイヤーとタイミングが被らないようにする、というの最適解のゲーム。他プレイヤーと帰還のタイミングが被ると帰り道にある財宝をも人数で割る必要があるので、獲得できる可能性が減る。ここが面白いポイント。行くか、帰るか、そろそろ罠で死ぬかもしれないがおそらく他のプレイヤーも同じこと考えてる。帰るなら一人のタイミングで帰る必要があるし、行くのも帰るのも判断に悩む。というのが醍醐味。

デフォルトカードの問題

ルール的に、せーのっで他プレイヤーと同時に次の行動を表示する。ここで、お前まだ行くのか!もう帰るのか!うわー、帰還タイミング被ったわー、と盛りあがる。そう、ここがポイント。

実はインカの黄金は「ダイヤモンド」というゲームで従来は「進むトークン」を握って、せーのでみんなで手を広げるゲーム。インカの黄金になって、進むと帰還を示すのはそれぞれのカードで、せーので裏で出していたカードを表にする、というやり方に変わった。ここまでは良いんだけど、問題は進むカードと帰還カードのデザインがいまいちパっと見てわかりにくいのが問題。


どうこれ?パっと見わかんなくない?左が帰還で右が進む。

世界観も重要なのでデザインにこだわってるのは素敵だけど、この判別のつきづらさはいただけない。初心者が行くと帰還を間違えることもあれば、せーのでめくった時に瞬間的に判断できることが重要。ん、どっちだ、って一瞬でも考えるようであればその面白さを損なわれてしまう。

よろしい、ならば作ってしまえ

コンセプト

間違えない、一瞬でわかる、がもっとも重要視すべきポイント。できれば世界観に沿ったものにはしたかったけど、この際それは切り捨てた。

誰でもわかる、ということでピクトグラムを採用。わかりやすく大きく文字をつけ、色も使って危険なのか安全なのかも表現。これならば間違えないはず。

そして今回はせっかくなんでバリアントルール用ダッシュカードも作ってみた。

バリアントルール「ダッシュ」

仲間うちでやってみて割と良いアクセントになってるのが、このダッシュルール。

  1. 5ラウンドで1ゲームだが、1ゲーム中に一度だけ使い捨てで使える
  2. そのターンの効果をダッシュしたプレイヤーだけで受けることができる
    • 例えば障害なら障害を一人で受け、ダッシュしてないプレイヤーは障害としてカウントされない
    • 財宝ならばダッシュしたプレイヤーだけで分配、一人なら一人占め

自作

今回の方法として、画像をベクター形式で作ったものをA4に適当に面付けして、それをシール紙に出力。カットしたものを別途購入したブランクカードに貼る、という方法。ちなみに元画像はピクトグラムをフリーで配布しているところから使わせていただいた

ヒューマンピクトグラム2.0

カードのほうは自作ゲームでも使われてるらしいものを。そこまで高額なものでもないので。

出力

シール紙に出力したけど、今回は耐水性の光沢紙をチョイス。最初に普通のシール紙を買ったら間違えて4つ切りのを買ってしまった。結果的には発色も良くなかったのでまあ良いか。ということで光沢紙を買ったけど、剥離側も印刷面も光沢でわからなかったので間違えて剥離紙側に印刷してしまって失敗。

という紆余曲折あったものの、無事完了。発色も光沢も良い。耐水性もあるらしいので良い感じ。文句をつけるとすれば滑りにくいので、プレイ時にひっかかりを感じないかどうか、という点。ただし、ゲームの性質上すばやくカードを操作する必要も、多く持つ必要もないので大丈夫そう。あとは耐摩耗性がどの程度あるか。

カット

裁ち落としするために一般的な3mmの広くとって、トンボ的なガイドラインを付けたものを用意した。なのでこのガイドに従って切っった。これは上手くいった感じ。


ついでに角丸君をつかって角を落としていく。一つ4つだから意外に数が多かったけど、簡単なので良しとしよう。カードより一回り小さくつくってあるので角は落とさなくても貼るのには問題ないけど、こういうひと手間は意外に大事で、よくできてる感を醸し出してくれる。

貼り

治具を作ったらちゃんと行くのだろうけど、面倒なので目で合わせて貼っていく。当然曲った。そう、僕は携帯のフィルム貼りなども含めちょっと苦手。しかも角丸にしたから剥離しにくい、という仕様。といいつつもそんなに大きな問題なく完了。


あとは遊ぶだけ

と、つくっておいてまだ遊べてないけど、出来は上々。世界観はともかくとして、視認性はかなり良い。問題だった行くのか戻るのかを混同するようなことはなさそう。まぁ満足かな。あとは実際プレイしてみてまたなんかあれば考えなおすとしましょうか。

「アフリカでは」の有用性と暴力性、思考停止の怖さ

今日ネットで見た言葉で

東京で10人死んだら日本中が驚く
ニューヨークで1000人死んだら世界中が震える
アフリカで4万人死んでも誰も驚かない
残念なことに命は平等ではないのです

とあった。

まぁ命は平等ではないし、人間そもそも生まれからして平等でないので、言ってることの本質的には同意なんだけども、
それよりみんなアフリカってなんだと思ってるんだろう。

この引用で言えば東京は都市、ニューヨークも都市、アフリカって大陸。規模が違いすぎるので引き合いに出すのおかしくない?
国越えて都市と大陸っておかしくない?
東京、ニューヨークってきたら、ケープタウンとかさ、キンシャサとかアフリカ大陸にある国の都市を持ってこないと。
もしくは、アジア、北米、アフリカ、と大陸単位で整理しないと。

そもそもアフリカでは、って表現が散見されるけど、せめて国ぐらいは指定してくれないと全然伝わらないよ。例えば南アフリカとエジプトとケニアとマダガスカルと南スーダンをいっしょくたにまとめたものをもってこられてもわかりにくいよ。

っていうかこういう時のアフリカという言葉の万能性というか、暴力性ってすごい。
命が平等ではないことより、一都市と大陸比べた文章に疑問の持たなささのほうが僕は怖い。

何度目かになる久方ぶりの近況報告

ちょっと期間が開いたので近況報告

かなり久方ぶりになりました。
もうすぐ春ですね。少しづつ暖くなってきて嬉しい次第です。

さて去年の終わりごろにエンジニアになるべく勉強と転職活動してます、と言っていたきりだったけど、
実は年明けからエンジニアの端くれとして職にありついて働いてます。
日々勉強の毎日ですが、やっぱり自分が苦にならないことを仕事にするっていうのはかなり違うもんだな、と思い知らされました。

今までいろいろやってきたからか、割と一つのことに集中してるのが仕事になる環境は心地良いです。
それとともにやっぱりなんでもできる気になってたのは間違いだったと。
いや、正確に言えば向いてること、向いてないことってのはどうしてもあるもんだな、と。
やればそりゃあそれなりには何とかなるけども、それがやってて楽しくないんじゃやっぱり舵の切りなおしが必要だったんだな、と。

同時に、集中して仕事ができるのも周りに支えてくれる仕事をしてくれてる人がいるからだ、と思えるのはありがたい。

そんなこんなで今は精神状態としては割と幸せ。
というか、世界を旅して帰国してきて、幸せの閾値が人よりだいぶ下ったのでそれなりに幸せだったんだけど、
仕事でどうも無理をしていたので、うまくまわってない感がすごかった。
そこを考えると今は仕事で足りない力があるものの、無理をしてる感がないし、
何より向上心とか楽しんでできてるので長時間になろうともそんなに苦じゃないし、
ひっかかってたものが解消されて上手くまわりだした感がすごい。

30も半ばになって、ようやく、というか。
これでいこう、ってもんが僕にも見つかった嬉しさと安堵。

最後に勝てばいい、ってのはある程度本当だと思う。
それなりに転職活動は苦戦した。
年齢的なこともあるし、焦りもあった。
もうダメなんじゃないかと思った。
どうあれ、転職活動が上手くいかないってことは人格否定されたような、
お前じゃダメだという烙印を押されたような、
そういうダメージを受けた。
でも、なんとかくぐりぬけれた。
運も大きかったと思うけど、エンジニアとしての実力云々より
これまで自分で身につけてきた能力が評価されたかも、とも思ってる。

あともうひとつ、
好きなことがわかって、腹が決まって、
そうすると努力するベクトルが明確なのは本当に気楽。
好きなことを仕事にするってこういうことなんだろうなぁ。
技術的な仕事だから、なおさらなのかもしれないけど。

旅してた時も今までもそれなりに幸せだったけど、
今ははっきりと自覚できるぐらい幸せ。
これから、もっとがんばって、できることが増えていけばもっと楽しくなると思う。

最後に勝てばそれでいいんだな。
ひと安心。

Alfredの同期がDropboxのAppsディレクトリだとできなかった件

  1. 1. Alfredの同期
    1. 1.1. あれ、同期したいディレクトリが選べない
    2. 1.2. 公式に説明があった
    3. 1.3. そもそも
  2. 2. LaunchBarから移行してみての所感

長らくこれまでLaunchBar使いとして頑張ってきましたが、環境が変わったのをきっかけに僕もついにAlfredの軍門に下りまして。

Alfredの同期

Alfredは有料のPowerPackを導入することでDropbox経由の同期ができる。一部設定はあえて同期しないようになってるものの、追加したWorkflowとか同期できる。どうせWorkflowを使えないんじゃ意味ないし、LaunchBarもそもそも有料だしで、当然PowerPack入れてみました。

あれ、同期したいディレクトリが選べない

で、Dropboxを使うアプリの多くは~/Dropbox/Apps(またはアプリ)以下で同期設定を持つものがある。アプリ関連のはここでまとめたいところだけど、どうもこのディレクトリが同期設定で選べない。これでは同期できない。Alfredだけ他の場所で同期するのも管理が面倒になるし、美しくないし。

公式に説明があった

簡単に言えば、Dropbox/Apps/はなんか不可解な動作をするので、Alfredはこれを採用しないし、ここで同期をさせなくしている。それでもどうしても使いたいなら

  • Alfredを終了
  • ターミナルでdefaults write com.runningwithcrayons.Alfred-Preferences-3 dropbox.allowappsfolder -bool TRUEと入力
  • Alfredを起動

するとできるようになるよ。
ってことらしい。

とりあえず僕はそれでやってみたけど今のところは問題なく動いてる。でも問題あるようだったら別の方法を考えよう。

そもそも

そもそもDropboxのAppsディレクトリ自体やっぱりちょっと変で、アプリの環境によってDropbox/アプリだったりDropbox/Appsだったり日本語だったり英語だったりで統一されない。しかも別モノ扱いなので面倒。僕はこれは、Appsをシンボリックリンクでアプリという名前で作って対応してる。

LaunchBarから移行してみての所感

お作法が違くて慣れないところもあるけどそんなに困ってない。省略語の柔軟さとファイル操作はLaunchBarのほうが秀でてる感じだけど、Alfredでも必要十分、という感じ。そもそも僕が移行したのはそれよりもWorkflowの充実さと作りやすさ。LanuchBarも機能拡張いろいろできるんだけど、ちょっと作るのが面倒だし、コミュニティとしてかなり寂れてるので将来性に難アリ、という感じ。

実はMacユーザーが増え始めたころにAlfred賛美の流れができて、なんか不服だったし、今もAlfredに降るのは少しだけシャクなんだけど、そんなこんなでしばらく使ってみます。よろしくAlfred。

焼売の読みについて

世間では「シュウマイ」だと思われているけど、広東語的にsiu maiなので「シウマイ」で正解。

最近割と上手くいってるオレオレBEMding

  1. 1. オレオレBEMding
    1. 1.1. 壮大なる勘違い
    2. 1.2. オレ的BEMコンポーネント設計
    3. 1.3. FLOCSSとの親和性
    4. 1.4. でちょっと小細工
      1. 1.4.1. blockについて
      2. 1.4.2. elementについて
      3. 1.4.3. modifierについて
  2. 2. 今んとこ上手く割といってます
  3. 3. 参考

HTML/CSSでの開発手法としていろいろあるなかで、最も有名ものの一つで命名規則のBEM(MindBEMding)っていうのがありまして。構成の手法としてSMACSSやFLOCSSなんていうのが、あっていったいどれがいいの?悩んだあげくにFLOCSSベースのオレオレBEMdingに落ちついて、それが割と上手くいってるって話。

オレオレBEMding

そもそもMindBEMdingってなに?って話なんだけど、Block,Element,Modifierで区切ってClass名をつけていきましょうよ。構成も理解しやすいし、名前も一意になるよ(意図しないスタイルの競合が起こらない)という手法で、具体的には、block__element--modifierという書式が一般的。詳しくは解説のドキュメントを漁ってください。

壮大なる勘違い

で、なるほどな、と思ってやってたわけだけど、最初はblockとelementの真意を理解してなかった。というのも、HTMLのマークアップはけっこう入れ子になっていくもんで。それでいてBEMってのはシングルクラス的なものだとぼんやり解釈してたんだけど、結果として、BBBEMとかBEEMとか平気で書いてた。

こりゃちがった。原意的に言ってるかはよく知らないんだけど、原則的に最多の状況でBEMまでが許される。BとかBEとかBMは可。そしてその原則を守ろうとするとシングルクラスよりマルチクラス的になる。

例えば、グローバルナビを想像すると、グローバルナビはページ全体をBlockとした時の1つのElementだけど、ナビの中のメニュー要素の一つはナビをBlockとしたElement。これをシングルクラスかつBEMにのっとることは半ば不可能で、無理にやろうとすると、BEEMとかになっちゃう。

BEMはただの命名規則にとどまらずに、BlockとElementとModifierの構造もわかりやすくする為にある。単純にトップダウン的に__で繋げていけば良いってもんじゃない。

と、これを理解せずに単純にやってたわけですよ。BEEMとか酷いときはBEEEEEMとかを量産してたわけですよ。

オレ的BEMコンポーネント設計

そして大事なのが、Blockは自身の位置情報を保持してはいけないこと。スタイル的に言えば、positionとかmarginとかの情報は持たせない。(自身のサイズやpaddingは内包する要素になるので可とする)

コンポーネント的に使うために、Block自身が自分がどこに位置するかのスタイルを持たせない。こうすると例えば、何かの変更により位置が変わった時にBlock自体のスタイルを変更する必要がなく、そのBlockを1コンポーネントとした時に流動性が上がる。

じゃあどうやってそのコンポーネントの位置を決めるかというと、そのコンポーネントは階層構造を見ると視点を上に上げていくとコンポーネントブロックはその上のブロックに対するelement要素になるはず。そのelement要素に位置情報としてのpositionやmarginを設定することで、コンポーネントの位置を設定する。

これがマルチクラスじゃなきゃ不可能だと僕が思ってる所以。つまりそれまでトップダウン的に考えてたんだけど、ボトムアップなアプローチで考えるべきだと思いなおした。

FLOCSSとの親和性

別にSMACSSでも良いんだけどね。FLOCSS的に上で書いたようなコンポーネント単位の部品をガツガツ切り出していく。

FLOCSS的なcomponentとprojectってどう分けるの?と思ってたけど、componentが一番小さいパーツ、projectはcomponentを一つまたは複数内包するもの、layoutはトップダウン的にページ全体から見たもの。layoutに限ってはBEMでいうBlock部分での自身の位置をスタイルしていい例外条件にする。

つまりlayoutが複数のprojectを内包していて、projectが複数のcomponentを内包している。

ただ、このオレオレFLOCSSはちょっと自分でもまだ甘いな、と思っていて、そもそものFLOCSSが定めるprojectとcomponentの定義から外れてる気がするし、componentとprojectが上手く噛み合わない時もたまにあったり、componentの数がたくさんできてしまったりしている。これは今後の課題。

あと、自覚してるけどなおせてないのはcomponentが例えばtopButtonとか、位置を表現してしまってたりすること。これは自分の命名が悪いですね。流動可能なcomponentに位置を意味する命名をしてしまうと、他の場所で流用する時に齟齬がでるし、流用しにくいものになってしまうので。

でちょっと小細工

で、本来のBEMではBlock__Element--modifierとelementには__、modifierには--という感じで区切ってつなげる。実はこれは厳格には決まってない。オレオレBEMdingだから厳格に決まってても破るけど。ちなみに単語間は-と一つのハイフンで区切る。で、僕がいろいろ調べて今使ってるのが、pre-blockName_element.is-modifierという書き方。

blockについて

blockはlower camelcaseで表記する。複数の単語を使う場合、topNaviとか、そんな感じ。これはJSで慣例的に使われてるし、CSSでスネークケースでJSでキャメルケースだと混乱しやすいので統一したかったので。かつ、prefixとして、FLOCSSの何にあたるかを一文字つける。layoutならl-、projectならp-、componentならc-。それでSASS的なファイルをパーシャルにするのも、そのとおりにする。そうすると探しやすいし使いやすいし、わかりやすい。

elementについて

elementも同様にlower camelcaseで表記。なのでハイフンやアンダースコアの用途が他で被らないので、_とアンダースコア一つだけつける。ハイフンじゃないのは、アンダースコアのほうが区切りを視認しやすいから。

modifierについて

ここまで書いてきたとおり、マルチクラス前提の構築なので、modifierは別クラスで当てる。こうすると、JSでのクラス変化による操作も使える。というかそれ前提の書き方になってる。prefixとしてis-を付ける。かつ、スタイルでは、その上要素があること限定で付ける。

例えばセレクタで.c-topNavi_item.is-currentみたいに書く。CSS側でスペース空けずに書いたセレクタの場合、そこだけ限定で当たるのを利用する。SASSとか(僕は最近Stylus派だけど)なら&.is-currentとかやってもいいね。

で、これの効能が思ったより良くて、シングルクラス的にmodifierまで設定するよりも各modifier共通のスタイルはその上の段階(BとかBEとか)で普通にスタイルできるのも良い。modifierが各modifierで異なるスタイルだけ持つことのになるので無理無理BEMdingよりよっぽど自然になる。

今んとこ上手く割といってます

そんなこんなで結構アレンジしたけども、それでいて本質にのっとってる(気がする)オレオレBEMdingでした。BEMっぽいのは多々あるけど、ほんとにそれがいいのか、っていうのを確認できてないので、しばらくはこのオレオレBEMdingを使いながら遊んでいきます。

参考


Vertical Rhythm インスパイア Vertical InRitsuをSASSで書いたよ

  1. 1. Vertical InRitsu
  2. 2. Power Function(塁乗)
  3. 3. Vertical InRitsu の仕組み
    1. 3.1. コード
    2. 3.2. 使用
    3. 3.3. 解説
  4. 4. 最後に

VERTICAL INRITSU(バーチカル韻律)!NINJITSU!的なノリです。どうも。

このブログをリニューアルする時も意識して、普段からも意識してるのがWebで日本語を読みやすくする工夫ってどんなことができるだろうと。黄金比(フィボナッチ数)を使ったジャンプ率とVertical Rhythmが2大セオリーだと勝手に思ってるんだけど、実際使ってみるとなんだかしっくりこない。なんかしっくりくるのを自分で、使いやすい形にしてみようということで。

Vertical InRitsu

コンセプトとしては日本語特化ということ。やっぱりアルファベットと日本語ではいろいろ違う。InRitsuというは韻律です。で、やりたいのは一定比率に基づいた段階的な文字サイズによるジャンプ率の実現と、いい感じに文字間を調節してくれる仕組み。

勝手にCompassとBourbonを2大便利CSSツールだと思ってるけど、Bourbonにはmodular scaleがある、CompassにはVertical Rhythmがある。でも片方づつしか持ってない状態なのがちょっと残念。

Vertical Rhythmの概念は日本語でも役に立つものだと思っていて、詳細はググればいろいろわかると思うけど、とりあえずLIGさんの記事見ればなんとなくわかるかな。要は、ベースユニットの倍数で文字間とを一定に処理していくと、規則性が生まれて読み易くなるよ、っていうセオリー。

このVertical RhythmをWebにまんま採用するのはじつは少し無理があって、大きい見出し文字などで複数行に渡った時に行間が空きすぎて逆に読みにくくなる現象がおこる。Webの場合そこに入る文字数が可変だったり表示サイズが可変であるので、複数行にならない想定にするのは無理がある。

大きい文字を一定比率で扱って、かつ、行間もそれなりにしたい。そうだ比率は白銀比(大和比)がいいな。ジャンプ率も大きくなりすぎちゃうから段階を細かくしよう、そんなこんなをよしなに調整してくれるのが、Vertical InRitsu。

Power Function(塁乗)

SASSには累乗計算が用意されてないので、自分で設定しなきゃいけないらしい。CSS Trickの詳細記事を見てほしいんだけど、ざっくり説明すると、まず単純な累乗関数を設定して、これだとマイナスの累乗に対応できいないからこう、でもまだ整数の累乗しか扱かえないから、少数も扱えるようにするにはBourbonのmodular scaleが完璧だ、という答え。

ちなみに使い方はpow(ベースの数値,累乗数)と設定。

Vertical InRitsu の仕組み

コード

vertical-inritsu.sass
=vertical-inritsu($in-scale: 0, $with-margin-top: 1, $with-margin-bottom: 1, $with-padding-top: 0, $with-padding-bottom: 0)
$base-font-size: 1rem !default
$base-ratio: 1.414 !default
$in-fz: $base-font-size * pow($base-ratio, ($in-scale / 4))
$in-base-unit: ($base-font-size * pow($base-ratio, 2)/ 4)
$in-lh: $in-base-unit
@while ($in-lh - $in-fz) < $in-base-unit
$in-lh: $in-lh + $in-base-unit
font-size: $in-fz
line-height: $in-lh
margin-top: ($in-base-unit * 4) * $with-margin-top
margin-bottom: ($in-base-unit * 4) * $with-margin-bottom
padding-top: ($in-base-unit * 4) * $with-padding-top
padding-bottom: ($in-base-unit * 4) * $with-padding-bottom

使用

先に紹介した、bourbon式のpow関数を読みこませておくようにして(vertical-inritsuより前に読むように書けばOK)使うときは、+vertical-inritsu(指数, 上マージン, 下マージン, 上パディング, 下パディング)(SCSS記法なら@include)で設定する。デフォルト値も設定してあるので、全部引数は用意しなくても大丈夫。

指数は、大きくなりすぎないように4分の1づつ累乗してるから基本的には整数で指定してあげる感じ。上記のpow関数を使った累乗だからマイナスや少数でも可。つまりに0で等倍、1以上でその数だけ段階的に大きくなるという使い方。デフォルトでは0(0でもline-heightは算出されます)

マージンとパディング設定は指定する場合0~1の範囲で基本で設定します。1でベースのline-hightと同じだけの高さの空白を作り出します。デフォルトは上下マージンが1で、パディングは0。これは倍数なのでもちろん少数でも可。0.5づつとったりなんてのも良いと思う。

以上をふまえて基本は+vertical-inritsu(1)とか整数を設定してあげればいいと思う。0にすると基準なのでベースとなるところに+vertical-inritsu(0)とかもいいと思います。

解説

$base-font-sizeはよく使われる設定で、それを取り入れてます。設定されてなければデフォルト値として1remを取ります。余談だけど、僕は18px前後の表示が文字大きめで好き。

$base-ratioは大和比の近似値であるデフォルト値として1.414を定数的に設定してる。当然ほかの比率や変数的扱いも考えたけど、まずはシンプルなほうがいいかと思って、大和比に限定。しかも比率を変えると見え方も変わるから行間とかにも調整が必要だし。

$in-fzで基準のフォントサイズにvertical-inritsuの第一引数(スケール指数)の4分の1だけ累乗します。4分の1じゃなくてそのままだとbourbonのmodular-scaleと同じだと思うんだけど、それだと大きくなりすぎちゃったりするし、引数は整数で設定してやるほうが理解しやすいと思ったので。

$in-base-unitは一般基準のベースフォントサイズの16pxぐらいの時に、大和比を2乗してやってかけるとだいたい良い感じのline-heightになる(約2em)、それだと細かいことができないのでそれを4分の1にして1つ分のベースユニット値を算出。4分の1にしたのは日本は伝統的に四拍子が基本らしいから。INRITSU(韻律)!

$in-lhとか最初に上で算出したベースユニットを入れて、あとはwhileでフォントサイズ(in-fz)との差大きくなるまで増やして、最終的なline-heightを算出。実は当初このロジックじゃなかったんだけど、line-heightとfont-sizeが近い値になると複数行になったときに文字間がなさすぎてキツキツになり、逆にほぼ倍とかだと空きすぎちゃう。なので最低でフォントサイズの4分の1、最高で半分だけ大きくなるように調節してます。Vertical Rhythm的には整数比じゃなくてもOKっぽいので、4分の1ならなんとか気持ち良さが残る範囲かな。と。

($in-base-unit * 4) * $with-marginとかのところでは引数でのマージンやらパディングやらの設定。余白は指数が0の時の1行分と等しくなるので、デフォルトで1つ分になるようにここで$in-base-unitを1度4倍にして戻してあげてて、それに引数で持ってきた係数でかけてあげる感じ。基本的には係数は真偽値的な0or1で良いようにしてる。実は当初true,falseの真偽値にしてたけど、細かい調整が効いて汎用性が上がるようにした。

最後に

CSS Trickで紹介されているpow関数はSCSS、僕の作ったVertical InRitsuはSASS記法で書かれてるので注意。どっちかをどっちかにコンバートして使ってください。僕はCSSからSCSSを経てSASS書いてるクチだけど、SASSのほうがincludeが楽!HTMLもslimとかで書いてるとインデントで書くやり方に慣れるし。でもゆくゆくはPug+Stylusがいいなーと思ってます。

gistにも上げておいたのでそちらのほうがよければそちらで。

僕なんかが、と思うことはやめて何も怖くなかったあの頃のようにこれからもなんかあったらこういうのも書いていきます。

最近僕がどうしてるかっていう時間配分の話

  1. 1. インプット
  2. 2. アウトプット
  3. 3. 生きていかねば

油断するといつも1ヶ月ぐらい更新が滞る。以前も書いたように今はエンジニアとして食っていくための勉強をしているんだけど、じゃあ学ぶことだけ、与えられたことだけやってればいいかっていうとそうではない。かといって人が1日に与えられた時間は公平に24時間だよって話。

インプット

勉強の多くはRuby, Ruby on Rails周りを中心にそれに付随するもの(e.g. Ajax的なこととか)をやってます。それと同時、というか空いた時間に自分の興味ある分野もインプットしてる。例えばデザイン的なこととか、教わらな範囲の技術だとか。

最初に学校的な仕組みでRubyとRailsを学習した効果は思いの他大きくて、独学でぶち当たる壁を乗り越えるには最適だった。以前書いた点と点がつながる感覚というのは、知識においてもよくあることで、ある程度の知識が備わってこないと理解できないことって沢山ある。そのある程度の知識をサポートされながら一気にぶっとばしたのは大きい。

これによって自走する力、自分一人でも理解できる力がついて、結果として興味の範囲も広くなってきた。単純に出来ることが増えたから、あそこまで手を伸ばせそう、っていう実感がすごくある。勉強しなきゃいけないことが見えてて、勉強する底が見えないってのは知識欲がある人間にとっては幸せな状況だなぁ、と思う。反面、平等な24時間ではとても足りなくなってきた。

アウトプット

インプットと同時にアウトプットもしていくのは勉強として効率が良い。覚えたことをどう使うのか、必要だから覚える、仕組みがわかる、そしてわからなかったことがいつのまにか自在に扱えるようになる楽しさ。語学学習とよく似ているなーと思うけど、あれもインプットとアウトプットの末に身につける技術。運動もある意味そう。

生きていかねば

霞をインプットして術を弄する仙人ではないので、食っていかにゃならんわけで。家のこともしっかりやらなきゃいけないし、妻さんをサポートしてあげたいし、かといってリフレッシュの時間や休息の時間っていうのも確実に必要だなぁと感じたり。ああ、精神と時の部屋で修行してきたい。

なんかまたまた結局唯の雑記になってしまったけど、僕なんかが、と思わずに、技術的知見とかも積極的に書いていけたらなぁ、と思いました。まる。