progrhyme

[progrhyme]

「呼吸をするように」

昔、目にした本で記憶が曖昧なのだけど、宇野千代さんという文筆家(故人)が言ったらしい言葉を覚えている。

「呼吸をするように文章を書きなさい」

というものだ。 小説家・文筆家を目指す人向けの言葉だったはず。

(本の中身は全く覚えてないので、もし間違っていたら申し訳ないけど、)

呼吸をするように、毎日書きなさい。 意識しなくても自然にできるようになるまでやりなさい。 そういう教えだったのではないだろうか、と想像している。

現代的な感覚に照らせば、若干スポ根臭がするというか、昭和感が感じられなくもないようにも思うが、これはこれで、一種の境地と言ってもいいのではないだろうか。

…で、特に文筆家に限った話でもないと思うのだ。 何かの専門家になるというのは、「そういうこと」だと考えられなくもない。 つまり、毎日当たり前のようにやり続けるということだ。

そうやってやり続けたひと握りの人が、大きな舞台で成功を収めることを、私たちは知っている。

また、ある意味でそれは楽な生き方かもしれない。 それだけを当たり前のようにやり続けるだけで、他のことを考える必要がないとしたら、単純な生き方のようにも捉えられる。

そんなわけで、これから少し「呼吸をするように」「ソフトウェアエンジニアとして仕事をする」ことを意識してみようかと思っている。

[progrhyme]

「それ、こうした方がいいよ」症候群

情報通になってくると「○○さんがこの件は詳しい」とか「◯◯には最近は✕✕のようなやり方がある」とかわかってくる。

そうすると、人が何か困っているのを見かけるとついつい横から口出ししたくなってくる。 それはほんとに有益な示唆だと感謝されることもあるのだけど、あんまりやりすぎない方がいいと思った。最近。

第一にまず、スケールしない。自分は1人しかいない。全部を見渡すのは無理である。 第二に、前提を見誤ることがある。事件は現場で起こっている。自分の知識や理解が及ばないような深遠な事情があることもあるだろう。 第三に、そもそもやる必要がない。たとえ少し非効率があったり、最適解を導けなかったとしても、担当者は何とかするだろう。私がいなくても世界は回る。

でも、逆に、自分の業務と関係ないことは全くやりませんってのは、たぶん間違ってはないんだけど、あんまりよくないような気がする。 バランスの問題かもしれない。 境目が難しいこともある。

自分の場合、あれこれ色々なことに好奇心旺盛すぎるので、「選択と集中」「使う時間を区切る」ってのが大事だと思ってる。

一方で、そういうともすればセクションごとに分断されそうな組織ってやつの中でグルー(のり)的な役割を果たすことって大事だと思う。 そういう人を組織内にどう配置するかや、どうやって育てるかは難しい問題だと思う。

たぶん小さい組織の中だと考える必要さえないこともあるだろうけど、逆に大きな組織でいかにそれを上手くやるかってのは、とてもおもしろくてやりがいのある課題だなと思います���

[progrhyme]

keyamb:

POD まあ慣れたけど、RDoc よりもドキュメントとソースコードの乖離が起こりやすいなと昔から思っていて、今もそう思っている。

なぜなら、ソースコードとPOD部分の関係が疎だから。

RDoc とか YARD みたいにそもそもコードの package 宣言や sub 宣言を解釈してドキュメントにしてくれた方が漏れがないし、RDoc 等の拡張構文を使えたら便利だと思う。 POD はリストの書き方など面倒。

…で、そういうのないかなと思って見てたら、YARD 自体にプラグインがあって、Perl コードも解析してちょうどやりたいと考えていることができそうなことはわかった。

https://github.com/pvande/yard-perl-plugin

でもベータらしい。

RDoc には POD を解析できるやつはあるみたいだった。

CPAN にはそういうのはなさそうだった。

違う名前で似たようなものがあったらわからないけど、Google 上では見つけられなかった。

Perl で作るべき？

Perl 6 の POD は Perl 5 とは少し違うみたい。 https://github.com/perl6/doc

で��� POD とコードが疎ってところは同じに見える。

#Perl にも #RDoc みたいなのほしい

[progrhyme]

#Perl にも #RDoc みたいなのほしい

POD まあ慣れたけど、RDoc よりもドキュメントとソースコードの乖離が起こりやすいなと昔から思っていて、今もそう思っている。 なぜなら、ソースコードとPOD部分の関係が疎だから。

RDoc とか YARD みたいにそもそもコードの package 宣言や sub 宣言を解釈してドキュメントにしてくれた方が漏れがないし、RDoc 等の拡張構文を使えたら便利だと思う。 POD はリストの書き方など面倒。

…で、そういうのないかなと思って見てたら、YARD 自体にプラグインがあって、Perl コードも解析してちょうどやりたいと考えていることができそうなことはわかった。

https://github.com/pvande/yard-perl-plugin

でもベータらしい。

RDoc には POD を解析できるやつはあるみたいだった。

CPAN にはそういうのはなさそうだった。 違う名前で似たようなものがあったらわからないけど、Google 上では見つけられなかった。

Perl で作るべき？

[progrhyme]

サーバ構築については、とりあえず Ansible かましとけば色々いいことはありそう。

シェルは最強のDSLだってばっちゃが言ってた / “chefを捨ててシェルスクリプトにした | Ore no homepage” http://t.co/PqCDt82kUh

これと↓のやつについて。

https://twitter.com/sonots/status/591487603028819968 DSL に DSL を被せたがる皆さん

ほんとそうで、Chef にしろ Puppet にしろ Ansible にしろ、シェルコマンドベースでサーバの構築やるとしたら、DSL に DSL かぶせてるようなものですね(Ansible は YAML ですが、まあ YAML + Ansible でだいたい DSL みたいなもんでしょう)。

自分が最近やろうとしてるこれとかも一例と言えそう。

すべての"作業手順書"をDSL化してSCMに放り込みたい

なんで DSL にするんでしょうね？

たぶん、シェルに足りない機能があるんでしょうね。モジュール化とか、関数のネームスペース分けられないとか、…。

あと、シェルだけで巨大なプログラムを作るのは、なんとなく怖い気がします。構成管理ツールにしろビルドツールにしろ、ちゃんとしたやつ使ってればだいたい動くものを、シェルにするといろいろケアしないといけないところが増えそう。シェルでそういう「いろいろ」をケアできるエコシステムがあればいいのかもしれませんけど。

プログラム言語を知ってる人だと、そのエコシステムを使いたくなるのは、無理からぬ話ですかねー

[progrhyme]

シェルは最強のDSLだってばっちゃが言ってた / “chefを捨ててシェルスクリプトにした | Ore no homepage” http://t.co/PqCDt82kUh

これと↓のやつについて。

https://twitter.com/sonots/status/591487603028819968 DSL に DSL を被せたがる皆さん

ほんとそうで、Chef にしろ Puppet にしろ Ansible にしろ、シェルコマンドベースでサーバの構築やるとしたら、DSL に DSL かぶせてるようなものですね(Ansible は YAML ですが、まあ YAML + Ansible でだいたい DSL みたいなもんでしょう)。

自分が最近やろうとしてるこれとかも一例と言えそう。

すべての"作業手順書"をDSL化してSCMに放り込みたい

なんで DSL にするんでしょうね？

たぶん、シェルに足りない機能があるんでしょうね。モジュール化とか、関数のネームスペース分けられないとか、…。

あと、シェルだけで巨大なプログラムを作るのは、なんとなく怖い気がします。構成管理ツールにしろビルドツールにしろ、ちゃんとしたやつ使ってればだいたい動くものを、シェルにするといろいろケアしないといけないところが増えそう。シェルでそういう「いろいろ」をケアできるエコシステムがあればいいのかもしれませんけど。

プログラム言語を知ってる人だと、そのエコシステムを使いたくなるのは、無理からぬ話ですかねー

[progrhyme]

MariaDB にもクラスタモードがあるんですね。

軽く見たところ MySQL Cluster の SQL モード相当なのかな。

マルチマスターで書き込み一貫性と高可用性を謳っているみたい。

[progrhyme]

Redis Cluster について

Redis Cluster のリシャーディングとorphaned masterの話 - CyberAgent エンジニア Advent Calendar 2014 2日目 : https://gist.github.com/yutori/158e5eeea60ba2914d1a

Redis 3.0 リリース前のやつ。

これ見ると Redis Cluster の場合、よくある分散型KVSみたいにレプリカ数を設定するわけじゃなくて、各masterに対して明示的にslaveをぶら下げる形のようだ。現実的には N台のmasterに対して slave 0台 (マスターのみでデータロストを許容する) or slave N台 (1台壊れたら直ちに代替機を作る) or slave N+1台 (1台死んでもまだ冗長性担保される) or slave N+2台あたりから選択する感じかな。

こうすると、分散KVSでレプリカ数を3とか4にするよりもリソース効率いいかも。