論理削除 Casual Talks #1という夢を見たんだ
それは前職のころ、今回の登壇者でもある @moro の発表にもあるような「要件としての論理削除はない」ということに熱く語りあったりしていたとかいなかったとか。 そして、ある日私が論理削除つらいということをつぶやいたところからこの企画は動きだしました。 このときは半分冗談で、いつか内輪で集まってやれたらいいかなというくらいだったのですが、今年の春にJxckさんの RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita をきっかけとしてインターネットで論理削除が盛り上がったこと、所属する組織から技術イベントをやっていこうという機運が高まっていたこと、この2つがちょうどいいタイミングで重なって、これはやるしかないなと思ったのでした。(とはいえ、Jxckさんのエントリからは半年も経ってしまっていますが…) @t_wadaさんの全体像と総論(と思ったら予想以上に踏み込んだ内
脱ダミー文字から始めるコンテンツデザイン
ダミー文字はリスク ユーザーは読まないと言われているものの、言葉はユーザーとコミュニケーションをするための基盤です。流し読みでも理解できるような設計がされているか。次のアクションへ結びつく動機が提供されているかは、言葉で決まることがあります。ビジュアルが注目されがちな UI デザインですら言葉が重要なデザイン要素になります。 デザインはコンテンツの価値を増幅したり、利用者の欲求を満たしたり目的達成の補助をするためにあります。もし、ダミー文字をつかってデザインすることは、ユーザーとのコミュニケーションを破棄した状態で彼等がもつ課題を解決しようとしているようにみえます。デザイナーはダミー文字をもっと敵視しても良いと思います。 ダミーの情報を入れるのは簡単です。Loren Ipsum のようなジェネレーターがありますし、日本語でも似たようなものはあります。今は文字だけでなく、ユーザーアイコンをは
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
続: OSSプロダクトとコミュニティの話 - たごもりすメモ
先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
