読者です 読者をやめる 読者になる 読者になる

weblog of key_amb

主にIT関連の技術メモ

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

develop ドキュメンテーション Markdown

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 の設定をロードする箇所でも、同様のガード条件を入れました。

脚注

2016 年を Software Engineer として振り返って

develop ブログ

はじめに

何か書いておこうかなー、と先々週ぐらいから思いつつ、結局ギリギリになってしまいました(汗)

鼻高々と自慢できるような大きな成果はないかなぁと思うものの、ここで来年以降も定点観測できるように、やはり書いておくことにしました。

概要と、昨年との比較

  • 作ったものは小粒なツールが多いですが、こうして振り返ってみると、数はそこそこありました。
    • 物によっては、 GitHub で多少、スターがもらえることもありました。
    • 昨年は主なものだと 2つ作っていました。数的には、かなり増えたと思います。バリエーションも増えました。
  • OSS への貢献も少ししました。
    • 昨年はこの手の活動はほぼなかったので、これも進捗したと言えます。
  • 勉強会で4回発表しました。これは去年と同じぐらいだと思います。

2016年に作ったもの

ピックアップ

GitHub でスターの多い順 + 作った日時の降順です。

shove (ShellScript)

これはブログ記事でも書きましたが、下の方にもある clenv というツールを作る際に Yak Shaving によって誕生しました。

後に @b4b4r07 氏の enhancd でも使われていることを知りました。
たまにスターがもらえるので、他にも使っている人がいるのかもしれません。

fireap (Ruby)

オンプレミス環境でも使える pull 型デプロイツールを作ろうというモチベーションがあって、作りました。
Consul が必要ですが、 O(log N) でデプロイできます。

poloxy (Ruby)

時として大量に発報されるアラートを、いい感じにまとめたくて作りました。

こちらはまだプリミティブな機能しか実装できていません。
そのうち熱が高まったら、開発を再開するかもしれません。

grifork (Ruby)

https://rubygems.org/gems/grifork

オンプレミスでも使える Yet Another なデプロイツールです。

pull 型ではありませんが、これも O(log N) でデプロイできます。
fireap と違って、 Consul に依存していません。

perl5-App-Memcached-CLI

https://metacpan.org/release/App-Memcached-CLI

Redis の redis-cli のように、対話的にも利用できる Memcached 用の CLI ツールです。
最近、職場のどこかでも導入されて、「便利」と言ってもらえました。

関連記事

以上のツールの一部についての関連記事です。

他に、こんなのも作ってました

他に、単機能のシェルスクリプトなど書いて、 GitHub で公開したものもありました。

Contributions

OSS にパッチを送って、取り込まれたものです。

もっと小さいパッチを含めると、もういくつかありましたが、ここでは割愛。

勉強会で発表した

大きなカンファレンスには行ってませんが、今年は4回ほど勉強会で発表しました。

以下、発表で使用したスライドを貼っておきます。

以上の発表について、ブログに書いた記事:

終わりに

OSS 活動と業務時間の使い方について

ここに挙げたツールの内、ごく一部に会社で業務の時間を使って作っていたものもありますが、ほとんどは余暇の時間に作っていたものです。
別に、業務における OSS 開発を禁じられているわけではありませんが、それがメイン業務ではないのと、"業務上、必要な OSS に貢献したり、作ったものを OSS として公開すること" に多くの業務時間を割けていなかった、というところです。

本ブログは個人ブログなので、あまり明白に勤め先と紐付けてはいませんが、幸い今の勤め先はそんなに縛りの厳しい会社ではありませんし、今後はもっと業務と OSS 活動を結びつけて行きたいな、と思っています。

今後、何を作っていくのか?

  • 作りかけの物がいくつかあります。サーバサイド周りのユーティリティーです。たぶん、近い内に公開できると思います。
  • 作りたいモノのアイディアも少しあって、サーバ運用に関するものです。おそらく、趣味で作ることになるかな、と思っていて、スケジュールは決めていません。

今年はたくさん趣味プログラミングできてよかったです。

お世話になった方々、ブログを読んで下さった方々、ありがとうございました。

来年もよろしくお願いします。
皆様にとって、良い一年となりますように。

脚注