weblog of key_amb

主にIT関連の技術メモ

GitHubリポジトリを @progrhyme に移行していきます。

English follows Japanese.

お久しぶりです。きいあむです。

ご存知の方も多いと思いますが、3月にアカウントを id:progrhyme に引越しました。
それから早4ヶ月経ちましたが、未だに「ID移行中」というステータスです。
のんびりやってます。はい。

さて、、重い腰を上げてようやくGitHubリポジトリ移行に動こうかな、というところです。

GitHubには Repository Transfersという便利な機能がある、と最近気づきました。
これを使えば、旧URLにアクセスした場合、新URLにリダイレクトされるような挙動になるので、あまり影響なく移行を進められそうです。

個人的にしか使ってないようなリポジトリもあったりするので、そういうのから少しずつ移行していきます。

もし、移行に関して不具合や困ったこと、予期される懸念などありましたら、Twitterなりで @progrhyme の方にご連絡下さい。

よろしくお願いします。


Long time no see.

Have you ever known that I have changed my ID from “key-amb” to “progrhyme”?

This time, I plan to transfer my repositories on github.com , too.

If you would notice any trouble or something wrong with this, please contact @progrhyme on Twitter or GitHub.

Thank you!


Hugoのドキュメント用テーマ「bootie-docs」v1.3までの更新について

Go製の静的サイトジェネレータHugo向けに、Bootstrapを使った簡素なドキュメンテーション用のテーマBootie Docsなる物を以前に作って、折りに触れてメンテナンスしています。

今回は特に大きな変更や機能追加はないのですが、互換性のない変更もありますので、本記事にまとめておきます。

2016年5月に書いた前回記事の時点で、v1.1.1だったので、それ以降のv1.3.1までのCHANGELOGのまとめです。

サイト独自のカスタムCSSを設置可能にしました

v1.3.1の機能追加です。
初心者だけど、CSSのカスタマイズどうしたらいいの? 的な質問イシューが来たので、static/css/site.cssっていうの置いたらできるようにしました。

メニューバーにHugoのMenu機能を使うようにしました

v1.3.0の変更です。
※互換性のない変更になります。

https://gohugo.io/extras/menus/ にそのHugoのMenu機能のドキュメントがあります。

これ、ethanmadさんからのイシューに対応していた時に改めてドキュメントを読んでいて気づいたのですが、昔からあった機能なんですね。

最初にこのテーマを作った時、Hugoそのものにはこんな機能はなさそうだと思って、独自に作ったのですが、実はそんな必要はなかったかもしれません。

これにより、ローカルでhugo server実行時にメニューバーでactiveクラスが有効にならないという問題も解消しました。

サポートするHugoのバージョンがv0.14→v0.15に

こちらのv1.2.0の変更によります。

結びに

いつものように、ドキュメント兼デモサイトも更新しておりますので、ご利用の方、これからご利用される方は参照下さい。

Enjoy!

MECEな木構造による分類方法の提供は要求定義を間違えているのではないか

一昨日ふと思ってSNSに何件か短文を投稿したのですが、今後この件について再考したり、何か作ったりすることもあるかもしれないなと思ったので、記録がてらにこちらにも投稿しておきます。

タイトルについて

ケース・バイ・ケースで、それで十分ということも、もちろんあると思います。 …と、一応補足しておきます。

思ったこと

補足

分類作業しんどい。
これに尽きます。

適切な分類を考えるのも面倒だし、要素が増えた時に再分類するのも面倒。
で、データノードが属するカテゴリが1つに制約されているケースだと、あるデータノードを探すときに分類された位置を正しく覚えてないといけない。
検索機能があれば救われることもありますが。(検索機能がゴミだと救えない。)

まとめると、ユーザに与える負担が大きすぎるんじゃないか、と思うのです。

もっといい感じのソリューションあるんじゃないかなぁと思う次第です。
雑ですが。

じゃあどういう分類がいいの?

マシなやり方の候補として、既に世にある例で思いつくものをいくつか挙げてみます:

  • Googleフォト
    • 機械が勝手に分類してくれる
  • Gmail
    • ラベルを階層化できる
    • メールに複数のラベルを付けることができる

ラベル方式については、融通の効かないプリミティブな木構造よりは、マシかなぁと思いますが、ラベルが増えた時の解決策が木構造による階層化というのは、なんか少し残念な気がしないでもないです。
結局、適切な階層化について人が悩む必要がある、という点において。

じゃあ、自動分類でいいの? というと、上のツイートに書いたように、分類作業を人が人のために行う場合なら、まあ、人がやるのが自然で理に適っているような気もしないでもないです。

データの性質なりなんなりで自動分類が可能なら、機械化もアリかもですね。
Googleフォトの分類はあまり活用していないので、なんとも評価できませんが。

結びに

「そこまで言うなら自分で作ったら?」と思う人もいそうです。
…はい。すいません。

まだ、要求も要件もふわふわしている感じですね。
手始めとしては、特定のケースについて考えてみるのがいいかもしれません。
例えば、Wikiをいい感じに整理するとか。

機会(と時間)があれば、よりよい仕組みについて考えてみたいと思っています。

メモ:ソフトウェアにキラキラネームを付けることの功罪について

あるソフトウェア・プロダクトを開発するにあたって、名前を決めたい。
次の2つの選択肢を考える。

  1. キラキラネームを付ける。
    • 神様の名前とか、古語とか、プロダクトの機能と紐付かない固有名詞っぽい名前
  2. 機能に即した名前を付ける。

…で、前者の後者に対する Pros/Cons を考える。

Pros

  • ネームスペースを作ることができる
  • (覚えれば)誤解が起こりにくそう
    • ググラビリティが上がる可能性が有る
  • 秘密の案件とかだったら、コードネームとしても使えそう
  • 開発者のモチベーションになる(?)
    • 「キラキラネームかっこいい!」と思う人もいるかも

Cons

  • 実際の機能とキラキラネームとの対応を覚えなければならない => 学習コスト、コミュニケーションコストが発生し得る
    • 数が増えると大変そう

その他の声

  • キラキラネームは、機能が明確でないモノに付けるのはよいのではないか。
    • Microservices の文脈でそれは起こり得ないはずなので、 Microservices の各サービスにキラキラネームを使うのは不適当ではないか。

雑感

  • キラキラしたやつ、数が多いとつらい
  • ググラビリティはちょっとした工夫で担保できそう(単語を組み合わせるとか、一部スペルを変えるとか)で、キラキラした名前をつける必要は必ずしもなさそう
  • わかりやすいのが一番。適度な長さの、実体に即した名前が無難ではないか。短すぎると、ググラビリティとか、困ることもありそう。

bashrc 内で bind を使うとリモートからコマンド実行時に警告が出る

peco などを快適に使うために ~/.bashrc 内で bind コマンド*1を使って、キーバインドをカスタマイズしています。

このとき ssh $host "コマンド" のようにリモートからコマンドを実行すると、 ~/.bashrc から bind を実行する行で、下のような警告が出ます:

/home/key-amb/.bashrc: line 30: bind: warning: line editing not enabled

解決策

この警告は TTY が有効でないことに由来するようです。
例えば、下のスレッドに回答があります:

自分の ~/.bashrc で peco の設定をロードしている箇所では、次のようにしました:

if which peco >& /dev/null && [[ -t 1 ]]; then
  # setup functions and key binds for peco
  # :
fi

test -t 1 で、標準出力が端末でオープンされているかチェックできます。

See Also

※ enhancd の設定をロードする箇所でも、同様のガード条件を入れました。

脚注