最近思ったこと - @kyanny's blog
ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。 おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。 そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不
リモートで働く開発者が行うとよいたった二つの習慣 - @kyanny's blog
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
インストール済みの CPAN モジュールの一覧を取得する良い方法はないだろうか - @kyanny's blog
追記:なーんだ、やっぱりありました。 cpan -a を使えばいいらしい。 id:hiboma ありがとうございました。 何台かのサーバを扱っていると、サーバによってインストール済みのモジュールのバージョンが違ったり、インストールされてなかったりしてよく困ります。デプロイしてからエラーになって気づいたりするので心臓に悪いです。 どうしたものかと考えて、パッケージ名とバージョン番号のリストだけテキストファイルに書き出しておいて、デイリーで更新するようにすれば最低限の世代管理?にはなるかな、と考えました。 先人の成果にあやかろうと CPAN を探したのですが、どうも望み通りのものが見つからない。 id:tomyhero に教えてもらった Pod::ProjectDocs はブラウザで見るにはとても便利ですが、肝心のパッケージ名が JS オブジェクトとして書かれていて、 Perl から扱うのがち
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
