トップ 追記

2018-02-18 [長年日記]

_ guiflowとuiflowでUiFlows試してみた

あるいは Kanazawa.rb meetup #66 に参加してきました。

UiFlowsとは

自分が知ったきっかけは誰かのツイート経由で

画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール | UXデザイン会社Standardのブログ

だったのですが、37 Signals ( Basecamp ) で

A shorthand for designing UI flows – Signal v. Noise

採用されている(今もなのかな?)シンプルに

  • 表示内容
  • 操作内容
  • リンク先

を記述する言語です。

「ツール」と紹介されることが多いみたいだけど、具体的なツールというよりは「記法」と表現した方がまだ近いかも。元のブログでは普通に手描きのものが紹介されています。(ただ、そもそも UI Flows って「名前」は存在しないような気がしませんか?)

元のブログは英語ですが、画像だけ拾ってみても十分に雰囲気は分かります。だいたい以下のような感じになります。

ユーザーの目にするもの
----------------------
ユーザーの操作するもの  --->  ユーザーの目にするもの
                              -----------------------
                              ユーザーの操作するもの

guiflowとuiflow

自分がこの言語に興味を持ったのは、グラフィックツールがなくても GitHub でメンテしやすい遷移図を描けないか?だったので欲しいのは言語そのものだけではなく、それを実際に遷移図に起こしてくれるツールだった。そこで出てきたのがこの二つ。

この二つは同じ作者の手によるもので、 UI Flows 言語(仮にこう呼ぶ)を解釈し、ビジュアライズする実装。guiflow は Electron 製、uiflow は Node.js 製。

guiflowよさげなんだけど…

すぐに始められてグラフが見れるというのはすごくいいんだけど、ちょっと以下が気になった。

試したのは v 0.1.1

  1. 日本語が Unicode Escapesequence になってしまう
  2. DnD でファイルを開いてくれない

特に 1 が致命的で、一度このツールで保存しちゃうと、もうこのツールを使って読むか、変換済みの画像でなければ人間が共有するのは難しくなってしまう。(Unicode Escapesequence をそのまま読み下せる人は身近にはいませんので)

うーーーーん。これはちょっと期待していたものと違うなぁ。

uiflowは大丈夫なんだけど

同じ作者の uiflow では、普通にエディタで作成した UTF-8 のデータを変換することができた。

中を軽く読んでみたんだけど、どうも変換の処理ではなく、ACE というエディタでテキストデータを扱うと Unicode Escapesequnce になっちゃうのかな?

Ace - The High Performance Code Editor for the Web

uiflow を叩くのは我々コマンドラインに慣れている人間にはよいけど、遷移を考える人はそういう人ばかりではないので、これを普段使いにするかというと、ちょっと微妙な気がします。自動化の際には活躍すると思いますが。

さーてこれはどうしよう、というところまでたどり着いて今回は力つきてしまいましたとさ。

まとめ

  • UIの流れを記述するシンプルな言語がある
  • 2016年くらいから実装が増えてて試しやすくなってる
  • ただし元ネタは2009年のブログであり、今も使っているのかはよく分からなかった
  • guiflow は手軽に始められるけどテキストデータとしてはちょっと管理しにくいので課題はある

2018-01-19 [長年日記]

_ Rails 4.2にWebpacker入れた

まとめ

  • Rails 4.2 で既存の AssetPipeline にまったく手を加えずに Webpacker を導入しました
  • Webpacker は導入から deploy まで簡単でよい
  • Webpacker のサイトの情報だけでなく、Webpack も Yarn も(そこそこ)追っておこう
    • さすがに Node.js と npm もさすがにね

前提知識

  • Webpacker は AssetPipeline とは独立した RailsEngine であり、共存できる
  • Webpacker は Yarn で Webpack を入れるのでそれぞれについてある程度知っている必要あり
    • (使うだけならインストール方法と簡単な使い方の手引きがあればよい)

決めなきゃいけないこと

  • Webpacker で AseetPipeline を置き換えてしまうか否か

決めたこと

  • AssetPipeline は AssetPipeline でそのままにする
  • /app/javascript/ はさすがに狂ってる気がするので /app/webpacker/ に置くことにした

webpack 管理が webpacker 管理の他に生まれるということは基本的に考えていない。

根拠
  • まだ Webpack やモダンJS、モダンCSS に習熟したエンジニアがプロジェクトの中心にいない
  • 既存のコードについて 熟練工がすぐに必要な状況ではない
  • ただし、新規では Vue.js を使ったアプリを追加する予定
    • これを AssetPipeline + CoffeeScript + jQuery で書くかというとそれはイヤだ

感想

個人的にはこれまで Browserify に寄せててどうしても Webpack と仲良くできる気がしてなかったんだけど、そんな自分でも Webpacker の導入は非常にスムーズに進んだ。

特に deploy について何も気にしなくてよかったのは本当に助かった。ビルドシステムを作ることに頭を使うのは全然やりたいことじゃないので。

ただ、やはり事前に少なくとも Node.js と Yarn の知識はあった方がよい。Webpacker のドキュメントでは Node.js 6.0+ / Yarn 0.25+ って書いてあったけど、Webpack はすでに "The current Long Term Support (LTS) release is an ideal starting point." と言っている。Webpacker はあくまで Webpack と Rails が仲良くする手法の一つなので、あくまで本家情報を大事にしよう。

おまけ

rake ( Rails 5.1- ) webpacker:install と rake webpacker:install:xxx は違う。そりゃそうだ。

参考

Webpack 2 との比較
Tags: Webpack Rails

2018-01-10 [長年日記]

_ cfsslとrakeで似たようなCSRをサクッと作る

ずっとSSL証明書面倒くさいなーと思ってたんですよ。まぁ今だと Let' Encrypt とか Heroku もそうだけど無料で自動更新みたいなのはあるにはあるんだけど、伝統的なやつをもうちょっと効率化できないかなとずっと思っていたわけです。*1

ありました。

cfsslを知る

cloudflare/cfssl: CFSSL: Cloudflare's PKI and TLS toolkit

本当は openssl + expect ? とか openssl -config <template> ? みたいなことを考えていたんだけど、swiss army knife が見つかっちゃいました。

cfsslの使い方

とっても簡単。

Creating a new CSR &#183; cloudflare/cfssl Wiki

にあるように JSON で

{
  "CN": <CommonName>,
  "key": {
    ...
  },
  "names": [
    {
      "C": "JP",
      ...
    }
  ]
}

のように定義を準備しておいて、

cfssl genkey <json>

てやると

  • パスフレーズなしのprivate key
  • CSR

が JSON で出力されます。

このね、 names に当たる部分て基本的に同じ組織なら同じになっちゃうわけですよ。違うのは CN くらいなわけです。これを openssl で interactive にいくつも作るのは超だるいわけです。これが cfssl ならラクショー、いや、いくつも JSON 作るのもダルいので、そこはあとで工夫します。

cfssljsonでファイルを作る

cfssl の出力はあくまで JSON なんだけど、欲しいのは秘密鍵のファイルと CSR のファイルなわけです。

そこで登場するのは cfssljson です。使い方は上の続きで

cfssl genkey <json> | cfssljson -bare <prefix>

ってやると以下の2つのファイルが生成されます。

  • <prefix>.csr
  • <prefix>-key.pem

そうそう、これが欲しかった。

あとは CSR を出して、戻ってきた cert / intermediate cert と private key をサーバにインストールすればオッケー。

定義をYAMLで書いてrakeで叩く

JSON で定義を書ける、まぁイマドキなわけですが、もっと楽したい。具体的には上の names に当たる部分が共通の SSL 証明書が複数必要、という場合は

YAML で定義を作ってやればアンカーとエイリアスで楽できます

アンカーとエイリアスってのは

Rubyist Magazine - プログラマーのための YAML 入門 (初級編)

こういうやつです。で、例えば Ruby だとこんな感じに

hosts = YAML.load_file(<yaml>)

で定義を取得できるので、この key なんかをもとに

hosts.keys.each {|host|
  desc host
  task host do
    generate_json(host)
    sh "cfssl genkey #{jsonfile} | cfssljson -bare #{prefix(host)}"
  end
}

みたいなことをやってあげると host ごとに private key と csr を作成する rake task がズラッと揃います。(main のレベルで書かない場合は適宜 Rake::DSL を include / extend してください)

こいつをリポジトリに突っ込んであげれば少なくとも CSR 準備作業はきれいに忘れてしまってもオッケーだと思います。

証明書のインストールとかその辺はまた今度

まずはくそ面倒だった openssl + interactive な key / csr 作成とさよならできたのでよしとします。

Tags: Sysadmin

*1 ACMはメール + Webでacceptの操作が要るので全自動ではないですね


2017-12-28 [長年日記]

_ IAM Policyの作り方に悩む - とりあえずS3 + CloudFront静的サイトを考える -

まとめ

  • AWS の Policy の種類が復習できた
  • AWS の Policy 関連用語と Terraform 用語の Resource, Data Source 用語との紐付けができた
  • 静的サイト向けの Policy に集中して考えた

操作から切り離して概念を整理しやすいのでドキュメントベースになるとありがたい。

AWS S3 の Bucket を読み書きできるポリシーとその適用方法が揺れていた

これまでに存在しているポリシーが以下のようなひどいことになっていた。

  1. S3 の Bucket Policy で Role と Action を割り当てているもの
  2. S3 の読み書きに特化した IAM User を作り、そのインラインポリシー ( IAM User Policy ) 側に Bucket ( arn ) 情報が書かれているもの
  3. IAM User Policy Attachment ( 未適用 )

図にするとこんな感じ。

S3 Bucketの読み書きのPolicy設定方法が複数ある様子

※ 上の図では AWS 用語を枠線で囲んでおいて、Terraform 用語を無地の上にそのまま置いている。そもそもこれまでこの辺の用語の理解が曖昧だったことに今回ほんとに気づかされている。(どうしても触る機会の少ないインフラ周りがおざなりになってしまう。)今回気づいたのは Bucket でも User でもない真ん中の Managed-Policy を aws_iam_policy で管理するようにしたらどうか?という話。

初期は 1 でやっていた。この頃の目的は静的サイト向けの Bucket ではなく、Web アプリの無限ストレージとして使い始めた。まだ AWS 自体がよく分かっておらず、読み書きを割り当てている IAM User の概念もボンヤリしていた。

で、いくつかそういうアプリが増えてきたときに Bucket 作って Policy 開いて、みたいな操作がダルくてイヤになって、Policy だけ別に作って Bucket に適用した方がよいのでは? と思い始めて 2 の形になった。

しかしこれは今にして思うと失敗だった。たぶん当初 3 を意識していたがやはり操作が面倒くさくて 2 の形に流れてしまった。

しかもこの形での指定が妙に複雑になっている部分がある。確か

  • ログイン可能な IAM User が手動で読み書き可能な Bucket を確認できるように
  • Rails + fog で bucket を覗く際になぜか指定が足りないと怒られた

辺りが理由と記憶しているが、これは静的サイトを CI で deploy するようにという今回の目的のためには不要な配慮になるはず。

解決案

静的サイトに限定して考える。

上のポリシーは Web アプリのストレージとしての Bucket のポリシーと混ざっているのがそもそもよくない。

AWS のマネージメントコンソールを手作業でぽちぽちしていくやり方と Terraform を共存(怖いけど)させる場合、恐らく 1 の形に近づけて Policy を Data Source で定義したうえで、せめてコピペせずに Bucket ごとに 個別に割り当ててあると直感的に分かりやすいと思う。(Bucket のプロパティを覗けばどういう状況か分かるので。)

ただ、ちゃんと自動化するなら第4の方式、

  • S3 Bucket
  • IAM User
  • IAM Policy
  • IAM Policy Document

をそれぞれ独立して定義した上で IAM User に IAM Policy をアタッチしておいて、最終的に IAM Policy Document だけをメンテすればよい感じにする方が .tf も .tfstate も diff が小さくなると思う。

少なくとも IAM User Policy の側に Bucket (正確には arn)を列挙してしまっている現状は、手作業での手間は若干減ってはいる(少なくとも bucket ごとに丸ごと policy をコピペしたうえで書き換える必要はない)が、自動化前提ではアホくさい。

User の関心事は 1) シンプルに静的サイトの deploy であり、2) deploy は手作業でなく CI/CD サービス経由であり、3) ログインは不要であるならば、 ユーザーの知っているべき情報は特に変化はない

手作業を捨てるならコードは DRY にして設定ファイルとしての HCL の可読性に寄せる方がスジがよいと思われる。

要確認

そもそも CloudFront 経由でしか publish しない方針なら、実は S3 の Read Only Policy って必要ないのでは?

参考