less}で、結果はこんな感じ。gyazo.comコマンド名catsを入れると、カレントディレクトリ内のファイルを全部対象にしてcatしていく。最初にファイル名が列記されて、それに各ファイ名+中身が続いていく感じ。入れると不可視ファイルも対象にする。lessを使わなければ、bashrcでは関数にしなくてもエイリアスだけで行けるんだけど、自分的にはlessは必須なので・・という感じ。この機能は以前からたびたび欲しいと思っていたので、今後少しでも快適になればよいのだけど。*別環境でも使えるようにGitHubにも上げておきました。15:55カレントディレクトリのファイルの中身をざらっとcatするTweetもっと読むコメントを書く2019-12-15EpisoPassを使ってみたEpisoPassGyazoやScrapboxでお馴染みの増井俊之さんによるEpisoPassの存在は以前から知っていたけど、episopass.com基本的な仕組み自体はわかるものの、どうしてこれが安全なのか、数点の疑問がどうしても解けなかった。ご本人に聞いてしまえば早かったのだと思うけど、そこまで急いでいるわけでもなく、たぶん数年そのままだったのだけど、ようやく理解できた気がするのでメモをかねて書いておく。EpisoPass全体については、以下のScrapboxをご参照。scrapbox.io簡単に言うと、質問&正答のいわば「なぞなぞ」を作っておいて、それに正解したらパスワードフレーズが出てくる、みたいな感じ。特徴的なのは、そのパスワードと正答はどこにも保管されておらず、とくに「正答」は自分の頭の中にしかナイので(というかそういうなぞなぞを事前に作っておくので)、仮に運営者のサーバ等からすべてのデータが抜き取られても、パスワードが漏洩することはないということ。具体的な仕組みとしては、一意のパスワードを作るには以下の要素が必要になる。ID(URLのこと)Seed(パスワードの長さ等を指定するキーワード)なぞなぞの質問なぞなぞの正答2番めのSeedというのが少しわかりづらいが、これがたぶんこのシステムのキモで、おそらく質問・回答の選択肢・正答・URLの組み合わせだけでもそれなりに複雑な(他人には破られづらい)仕組みにはなるだろうが、そこにSeedが絡むことでより複雑性が高まるのだと思われる。その上で、EpisoPassには「編集ページ」と「利用ページ」があり、前者ではなぞなぞやSeedなど各種の設定を行い、後者ではそれによって出来上がったなぞなぞを解く。それらのページはどちらも全世界に公開されている。増井さんが使用例として公開している、ご自身のTwitterのEpisoPass利用ページを見てみると、こんな感じ。https://episopass.com/Twitter_masui@pitecan.com.htmlで、その編集ページを見るとこんな感じ。(最後の「.html」をトルだけ)https://episopass.com/Twitter_masui@pitecan.comあれ、Seedもパスワードも見れてしまってる・・というのが、じつはつい最近までまったく意味がわからなかったところ。パスワード、見えちゃってるんじゃないの?という。実際には、第一にこの画面内のSeedは利用者が使っているものとは限らず、試しに他のSeedを入れてみると、それに応じてパスワードも変わる。アクセスした時点ではすべての回答候補の最初(左端)の選択肢が選択されているので、どれが正答かは本人以外にはわからない。これらの変数が存在することにより、この編集ページを見られても実質的な問題はない。*増井さんはご自身の使用例では「Seedを公開している*1」と言っているけど、本当に上記アクセス先のSeedを使っているかはもちろん誰にもわからない。ぼくは上記後者の、「編集ページにアクセスした時点ではすべて回答候補の左端が選択されている」という前提をわかっていなかったので、編集ページが知られたら自動的にパスワードもバレるのでは・・と思っていた。編集ページはなぞなぞページのURLから推測(というか)できるのだから、そもそもなぞなぞの意味ないのでは・・と思っていたのだけど、そうではないことがわかったので、その記念にこうしてブログにメモをしている。その他、この仕組みに関するよくある質問は以下。想定可能な疑問点はだいたい網羅されているのでは。scrapbox.ioちなみに、今回久しぶりにEpisoPassについて調べてみようと思ったのは、増井さんの以下の直近ブログ記事を読んだから。scrapbox.io先日仕事でChromebookに触る機会があり、たしかにあのログインは大変!と思っていたので、用途として非常に興味を持ったという。(まあ実際には、まだ仕事でこれを使うことはできないが・・)ひとまずは、自分が趣味で使っている&他への影響が考えづらいサービスで小さく試し始めているところ。Chrome拡張機能を入れてみたけど、これはなぜか上手く動いてくれない。scrapbox.ioもしかしたら、すでに別のパスワード管理サービスのアドオンを入れているせいかも。EpisoPass以前にパスワードの使い回しでちょっとした話題になったことがあり、しかしこれは逆に言うと、どんなかたちであれパスワード自体を登録・保存せざるを得ない既存のパスワード管理サービスの欠点を明らかにしたものでもあったと思う。EpisoPassにはそれはそれで、「なぞなぞを作るのが面倒」等の問題はありそうなものの(人によりそうだが)上記の根本的な問題は含んでいないから、その点からも期待できるところがあるなあ、と思っている。アルゴリズムなど、システムの仕組み部分もシンプルかつ公開されているようだし。(FAQをざっと見た感想)*1:FAQにて。その上で、通常は公開する必要はないし、安全を期するためにはSeedも非公開にした方が良いだろうと言っている。14:17EpisoPassを使ってみたTweetもっと読むコメントを書く2019-12-15ランダムな文字列をパッと出すPerlスクリプトを書いたperlランダムな文字列を何文字分かサクッと出したい、ということが時々あります。このようなときに使える小さいツールを作りました。55文字のランダムな文字列が出てきます。+/2ox文字数を指定しなければ、100文字出力されます。この際には数字・アルファベット(大小)・記号がミックスされたものが出てきますが、オプションを指定することによって、数字だけ・大文字ないし小文字だけ・数字とアルファベットだけ、などの組み合わせも可能です。OKKQX詳しくは以下。help便利な使い方どういう時にこれが必要になる、という具体的な事例は自分でもよくわからないんですが、案外必要になるケースが多く、その時にいちいちスクリプト名を打ち込むのも面倒なので、.bashrcに以下のようなエイリアスと関数を設定してシュッと出てくるようにしています。(要Mac)Getopt::Long少し前にGetopt::Longを初めて使って、オプションの取り回しがだいぶラクになったな、と思っていましたが、しばらく使わないうちに忘れかけていたので、今回はそのリハビリもかねてそれ周りをGetopt::Longで書き直しました。このツールでは引数の値は受け取らないので、あまり効果は大きくないですが・・。後の自分の参考用に、Getopt::Longの復習にともない参考にしたブログ記事を掲示しておきます。PRESSの記事で紹介する候補のひとつでした。note103.hateblo.jpその記事では自作の小ネタツールを紙芝居コントのように次々紹介していたので、内容的にも規模的にもちょうどいい感じでしたが、紙数が足りなかったのと、最終的な構成からは少し浮く感じもあったので、お蔵になっていました。展望これのRuby版も作ってみたいところです。あとはブラウザで動くのも作ってみたいです。JavaScriptの練習・・かな。2019』の2日目の記事です。adventar.org昨日はid:mohriさんの以下でした。mohritaroh.hateblo.jpさて、続く私はWebサービスのヘルプを編集することについて書きます。いっても、あんまり汎用的・抽象的な話ではなく(そうしたかったんですが、ならず)、やや特殊な事例かもしれません。ご承知おきのほど・・。ぼくは昨年の11月にそれまでのフリーランス編集者(兼たまにライター)からIT企業の会社員に転職しまして、現在はその会社が開発・運営しているWebサービスのカスタマーサポート、兼編集者みたいなことをしています。*転職時のブログ記事はこちら。できるよ、みたいなものですが、これのチャットサポートをしながら、そのサービスに関わるヘルプ記事の校正・テキスト表現の監修みたいなことをしています。boardそのすべてを同サービスのメイン開発者であり弊社代表でもある田向さん(id:fw_tx76129)が書いていまして、何しろこのサービスは元々田向さんが自分が欲しくて作った(理想に合致するものがあれば使ったけど、なかったので作った)もので、コードも最初のプロトタイプから今に至るまでずっと中心になって書いているので、その仕様については誰よりも彼がよく知っていて、だからそういうこともできるわけですが、とはいえ同サービスがスタートしてからぼくが入社するまでの4年ちょっとの間、ヘルプの文章は他の誰も触っていない状態だったので、いわば「外部の目」によるチェックというのはほとんどされていない状態だったのですよね。そこにぼくが入ってきたということで、じゃあ編集、やりましょうかやりましょうよ、ということで、まずは校正的な視点で表記を揃えたり、ちょっと内容が伝わりづらそうなところを適当に書き換えたり、ということからスタートしてできたのが以下のようなシステムでした。tamukai.blog.velc.jptamukai.blog.velc.jp詳しくは上記の田向さんによる記事をご覧頂きたいですが、簡単に解説すると特徴は2点で、Git/GitHubを使ってヘルプ記事をバージョン管理するtextlintを使って表記揺れを自動的にチェックするという感じです。大きいのは前者のバージョン管理で、以前はその1本目の記事にも解説されているとおり、HTMLエディタ形式の管理画面で編集してそのまま保存するような仕組みだったので、もし修正してもその差分(どこをどう修正したのか)はわからず、とくに複数人で編集する場合には困難が生じそうな状況でしたが、ここにGitをかませることで、第一に複数人による作業が非常にしやすくなり、また普段づかいのエディタ(Vim)でローカルのテキストファイルを気軽に編集できるようになり、感覚的には「コードを書くようにヘルプを書く(編集する)」みたいな感じになりました。これによって上記2点目の特徴であるリントツールも経由できるようになり、事前に登録しておいた「辞書」と異なる表記をしていたらエラーが出るようになっています。textlint.github.ioその作業の流れについて、もう少し具体的に書いてみると、こんな感じ。修正前のブランチを元に修正用のブランチをチェックアウト。その中でどんどん修正&コミット。Request(WIPみたいなやつ)を作成。1本の記事につき頭から終わりまでを2〜3周ぐらい読み直しながらつど修正。終わったら、DPRからPRに切り替え。田向さんにアサインを移す。ちなみに、Git操作はSourceTreeを使っています。www.sourcetreeapp.comぼくは以前は、Git操作なんて黒い画面でやってナンボでしょ、GUIなんて邪道!と思っていましたが、入社してみるとエンジニアで黒い画面を使っている人はいなくて(笑)むしろSourceTreeの割合が多かったので、あっさり改宗。普段それを本業で使ってるエンジニアさんにGitやSourceTreeの使い方を教われるなんてありがたすぎるので大人しく教わった次第でしたが、なんやこれ、めっちゃ便利やん!という感じで今では手放せないものになっています。*2上記を踏まえて、あらためてそれらツールに着目しながら手順を追うと、こんな感じ。SourceTreeでブランチ作成・チェックアウト。エディタでひたすら編集。