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

weblog of key_amb

主にIT関連の技術メモ

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

ソフトウェア開発

あるソフトウェア・プロダクトを開発するにあたって、名前を決めたい。
次の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 活動を結びつけて行きたいな、と思っています。

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

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

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

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

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

脚注

ちょっとしたワークフローエンジンを作るときは Rake で十分だと思う

Ruby

Ruby なら特に。

Ruby 以外でも、使えるケースはありそう。

Rake には次のような機能が有る。

  • タスクの依存関係定義
  • 並列実行
  • 別のタスクの呼び出し

また、タスクを記述する Rakefile 内では Ruby の文法が使えるので、特に外部の gem を使わなくても、任意のタスクにアドオンで次のような機能を付加できる。

  • リトライ
  • 終了処理
  • 繰り返し
  • 複数のタスクを並列実行

以下にサンプルの Rakefile を示す。
※ここでは parallel を使っているが、同じことを parallel を使わずに記述することもできる。

require 'parallel'

def invoke(task)
  Rake::Task[task].invoke
end

def execute(task)
  Rake::Task[task].execute
end

def parallel(*tasks)
  Parallel.each(tasks) do |task|
    invoke(task)
  end
end

task :all do
  invoke :prepare
  begin
    invoke :start
    begin
      invoke :main
      parallel :job_foo, :job_bar
      3.times { |i| p i; execute :job_to_iterate }
      invoke :finalize
    end
  ensure
    invoke :clean_up
  end
end
task default: :all

task :prepare do
  p :prepare
end

task :start do
  p :start
end

task :main do
  p :main
end

task :job_foo do
  p :job_foo
end

task :job_bar do
  p :job_bar
end

task :job_to_iterate do
  p :job_to_iterate
end

task :finalize do
  p :finalize
end

task :clean_up do
  p :clean_up
end

実行すると、次のようになる。

% rake --trace
** Invoke default (first_time)
** Invoke all (first_time)
** Execute all
** Invoke prepare (first_time)
** Execute prepare
:prepare
** Invoke start (first_time)
** Execute start
:start
** Invoke main (first_time)
** Execute main
:main
** Invoke job_foo (first_time)
** Invoke job_bar (first_time)
** Execute job_foo
** Execute job_bar
:job_foo
:job_bar
0
** Execute job_to_iterate
:job_to_iterate
1
** Execute job_to_iterate
:job_to_iterate
2
** Execute job_to_iterate
:job_to_iterate
** Invoke finalize (first_time)
** Execute finalize
:finalize
** Invoke clean_up (first_time)
** Execute clean_up
:clean_up
** Execute default

この Rakefile を見れば、タスクのワークフロー制御がどう記述されているか、プログラマならすぐ理解できるだろう。

今回の :all のような、ユーザが実行するワークフローを記述したタスクは、外部から直接利用されるメインのタスクと言えるだろう。
メインタスクから呼び出される個々のタスクは、サブタスクということになる。

メインタスク内では、ワークフロー制御と、サブタスクの呼び出しのみを記述すべきだ。
細かな内部ロジックはサブタスク側に記述することで、 Rakefile や実装されているワークフローを見通しよく保つことができるだろうと期待される。

参考

Ginza.rb で "grifork" について発表してきた

Ruby 勉強会 develop

10/18(火)に、第40回の Ginza.rb に参加してきました。

初参加でしたが、今回は他にも初参加の方が8名ほど(?)いらしていたようです。

Ginza.rb では、毎回、別々のテーマについて会を催しているようです。
今回は「自分でつくったものを見せてみよう」というテーマでした。

約17名*1の参加者中、ほぼ全員が発表者だったため、1人あたりの発表時間が4分ほどになりました。
LT より短いレベルですね^^;

私は、前記事で紹介した "grifork" について発表してきました。
下がそのスライドです。

だいたい前の記事で紹介した内容の通りですが、v0.2 〜 v0.5 のアップデートについても触れています。
この場でも、かんたんに述べておきます:

  • v0.3 gem 化しました。 https://rubygems.org/gems/grifork
  • v0.4 Parallel, ssh, rsync のオプションを DSL でカスタマイズできるようにしました。
  • v0.5 prepare, finish という構文でジョブの最初と最後に実行するタスクを記述できるようにしました。

発表後、Twitterハッシュタグを見ていたところ、質問らしいツイートがありました。

ごもっともな質問です。
今はある意味、「何もしてない」のですが、エラーがあったらそこでジョブ全体が異常終了するようになってます。

経験上、あるノードでデプロイが止まる場合、そのノードが異常な状態であることが多いと思います。
ので、その場合、そのノードを取り除いて再デプロイする、というのがよくある運用手順になるかな、と思います。*2

grifork の仕組みとして、リトライを入れたり、異常ノードを正常ノードと入れ替えてなるべく多くのノードに対してタスクが完了するように仕向ける、といった実装も可能とは思いますが、その辺りは要望があったら考えようかなぁ、というところです。
何かご意見などありましたら、 GitHub Issue でも Twitter でもお気軽にお寄せ下さい。

自分以外の発表について

一部 Ruby じゃなかったりもあった気がしますが、発表された成果物がバリエーションに富んでいて、刺激を受けました。

特に @joker1007 さん作のものには、ふだんお世話になっているものもありそうです。
rukawa というワークフローエンジンがなぜ rukawa なのか気になりましたが、ちょっと風邪気味だったので懇親会は遠慮しました。

Ginza.rb について

自分がこれまで参加してきた技術系の勉強会は、メインパートが「発表( + LT + 質疑)」で、その後、懇親会という流れのものが多かったです。
が、Ginza.rb は前の回の振り返りや次回内容の検討があって、新鮮でした。

またの機会がありましたら、よろしくお願いします。

ありがとうございました!

*1:エントリーしていた方は、見たところほぼ全員出席していたと思います

*2:Twitter でも同じように回答しました。