地獄のミサワの公式
今までに経験した中で最悪の開発環境について書く
なんとなく吐きだしてみる。老害の昔語りなので興味ない人はスルー推奨。 時は2000年代初頭、俺は最初に就職した独立系SIerから4次請けの派遣として某銀行の営業店システム開発に参加していた。 新卒で入社して、二つ目のプロジェクトだった。当時は最先端であったJavaでのプロジェクトということで、ずいぶんと喜んだことは記憶している。 1フロアが丸ごとプロジェクトルームとなっており、プロジェクト統括の事業部長が常に怒号をあげながらフロアを徘徊するなかで、15インチCRTディスプレイ(当然液晶なんかじゃない)がようやく置ける狭い机とパイプ椅子で、右も左もわからないまま、Excelで書かれた仕様書と向き合い、秀丸エディタ(当時はEclipseがまだ生まれていなかった)でジャバを書いていた。 デスマであったかというと、今思うとそこまでデスってはいなかったように思う。頻繁にリスケが行われていたのでプロジ
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
Ken's Memo: screen + SSHエージェントフォワーディング
2011年4月1日金曜日 screen + SSHエージェントフォワーディング puttyで、Linuxサーバにログインしたときはいつもscreenを起動していたが、毎回の作業はなるべく減らしたい。 UTF-8環境で GNU Screen の日本語表示が崩れる件 - OSのようなもの の記事を見て、設定 ▸ 接続 ▸ SSHの「リモートコマンド」を `screen -xRU` とすることで、毎回 screen を起動する必要ないことが分かった。 ただ、この方法だと一つ問題があって、pageantを利用しているときに、SSHエージェントのフォワーディング機能が使えなくなるケースが発生する。 エージェントフォワーディングでは、sshは ログイン時に /tmp/ssh-ABC/agent.1234 のようなUnixソケットを作成する。それを経由してサーバ上のsshプロセスとpageant
GitHub Kaigiへ行ってきた - ただのにっき(2014-06-01)
■ GitHub Kaigiへ行ってきた GitHub Kaigiの開催案内をTwitterで見かけてなんの気なしに申し込んだら、その後あっという間に300席がうまって、その後500人へ拡大してもなおキャンセル待ちがあったとか。東京のエンジニアの勉強欲は異常や。いつものようにRubyist時間に到着したらもうすっかり席が埋まっていて、最後方入り口近くの椅子をなんとか確保*1。会場になったサイバーエージェントのセミナールームには何度か行っているけど、こんなに人が詰まっているのを見たのは初めてだ。 最初は「GitHub実践入門 ─ Pull Request による開発の変革」だったのだけど、のっけから「あれれれれ?」って感じだった。GitHubでもたらされたとされている「変革」が、どれも(GitHub登場前からの)ごく当たり前のプラクティスに見えたからだ。おかしな変数名に対してレビューアが対案
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
