論理削除 Casual Talks #1という夢を見たんだ
それは前職のころ、今回の登壇者でもある @moro の発表にもあるような「要件としての論理削除はない」ということに熱く語りあったりしていたとかいなかったとか。 そして、ある日私が論理削除つらいということをつぶやいたところからこの企画は動きだしました。 このときは半分冗談で、いつか内輪で集まってやれたらいいかなというくらいだったのですが、今年の春にJxckさんの RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita をきっかけとしてインターネットで論理削除が盛り上がったこと、所属する組織から技術イベントをやっていこうという機運が高まっていたこと、この2つがちょうどいいタイミングで重なって、これはやるしかないなと思ったのでした。(とはいえ、Jxckさんのエントリからは半年も経ってしまっていますが…) @t_wadaさんの全体像と総論(と思ったら予想以上に踏み込んだ内
ヒューマンエラーを仕組みで防ぐこと - けんちゃんくんさんのWeb日記
仕事でそういう話をしていて、もやもやしたので考えを整理しておく。 リスクとコストを正しく評価する ヒューマンエラーをシステムや仕組みによって防ぐといっても、全てのエラーが起きないようにするのは、網羅性とコストの面から不可能ではないかと思う。 つまり、ヒューマンエラーのリスク(原因となる作業の頻度と発生した場合の影響)と、それを仕組み化するコスト(構築と維持)を正しく評価した上で、費用対効果のよいものから対応していくことになる。 このあたりは 自動化するときに考えること - HsbtDiary(2015-05-03) で述べられている考え方にも繋がる。 ただ、これとは少し違うポイントとして「普通はそういうことはやらない」とか「注意すればいい」という思考があると考えている。 仕組みでヒューマンを守る そういった考え方は、そっくりそのままそれを仕組み化すべき理由になる。 これらの思考はリスクとコ
難しい問題を簡単に解くということ - けんちゃんくんさんのWeb日記
を大切にしている。 現実世界の問題をシステムを作って解決するということは、その問題はコストをかけて解決する価値のある難しい問題であるということだろう。 しかしながら、難しい問題をそのまま難しい方法で解決するのであれば、日本語が理解できてプログラムさえ書ければ誰でもできるのである。 「難しい問題を簡単に解く」というのは、単にライブラリを使うというだけではない。 難しい問題というのは、大抵の場合一様に難しさが広がっているわけではなく、多数の簡単な問題とごく一部分の難しい問題の集合となっている。 この一部分の難しい問題を見極めるのが重要である。その問題を難しい問題としているポイントさえわかればあとはどうとでもなる。 技術力で捻じ伏せることもできるだろうし、交渉によってその問題をなかったことにすることだってできるかもしれない。(馬鹿正直に作るだけが仕事ではない) 「こんなコードでよかったのか」と思
新卒研修でGitの話 - けんちゃんくんさんのWeb日記
新卒エンジニア向けの「座学」という枠で、1時間ほどGitについてお話させてもらった。資料はspeackerdeckに。 新卒sは、普段Gitは使っているものの、まだまだ実務で起きた問題を解決できるほどではないようなだった。そこで、自分がGitを理解できたなーと思えたきっかけである「全てはコミットである」を少しでもわかってもらえたらいいかなーと思ってそんな内容になっている。 資料はひたすらコマンドが並べられているだけなんだけど、これを打ってもらいなから結果を確認したり、コミットの繋りをホワイトボードに書いたりしていた。なので、この資料を眺めてもさっぱりかもしれないけど、わかる 人には言いたいことが伝わるんじゃないかと思う。(本当はremoteまで説明したかったんだけど、資料作成と実際の講義時間の問題で割愛している) ペパボでは1週間に2回ずつこういう時間があって、実は今は2週目なんだけど、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
