#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
論理削除の前に別テーブルに切り出せるかどうかを考えよう - Life is Really Short, Have Your Life!!
めっちゃよくまとまっているので、大変助かりました。 blog.mogmet.com t-wada氏の「とりあえず削除フラグはアカン」については、僕も全く同感です。論理削除をしなければならないビジネス上の理由がスッポリ抜け落ちている。「とりあえず削除フラグ立てて何かあれば戻せるようにすればいいンゴ」ってのは論理設計を放棄していると言い換えても良いし、「ユーザーの言葉ではない」という指摘も重要。こちらに書かれています。 ledsun.hatenablog.com じゃ、フラグやめてどーすんのって話。フラグを立てたくて立てる人はおらん(はず)。「削除フラグを追加するとSELECT時に常にWHERE句で削除フラグを引っ掛ける必要があるのでクソ」→「削除日や状態カラムを使おう」では解決にならん。t-wada氏の資料でも解決策で上げられてたけど「×」マークがついてます。下記に変わっても誰も嬉しくないと
Private Presentation
Private content!This content has been marked as private by the uploader.
MVCの流れを簡単にまとめてみる - Qiita [キータ]
理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア
![MVCの流れを簡単にまとめてみる - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4eab66c03020ced4619e83c8ebe5ff0c4cbcd864/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9TVZDJUUzJTgxJUFFJUU2JUI1JTgxJUUzJTgyJThDJUUzJTgyJTkyJUU3JUIwJUExJUU1JThEJTk4JUUzJTgxJUFCJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJUE2JUUzJTgxJUJGJUUzJTgyJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1hNWRhZWZkYmY5ODQxZTI1ZWE2NjFjZGEzYjVjNmRmNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaGlyb2tpZGFpY2hpJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MmViZmQ0YmEwMzUxYTZmMGQyZjFhNWVhNzIyYjI2MA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D02e229a1404969c8e3f437e0d6b7bbe0)
Web な人もアプリな人も、これから新しく Android アプリを作るなら抑えておきたいポイント3選 - Qiita
Web な人もアプリな人も、これから新しく Android アプリを作るなら抑えておきたいポイント3選Androidandroid開発 概要 Lollipop が発表されてから時間も立ち、Android Auto、Android Wear、Android TV と、多様性を見せ始めた Android ですが、今後とも多種多様なデバイス向けに様々なアプリを作っていく流れがあるなか、新しくアプリを作るなら抑えておきたい要所をまとめました。 TL;DR 抑えるところは 3 つ。 画面とライフサイクル 非同期処理 互換性 かなり端的にいうと、Activity や Service などのライフサイクルとうまく付き合いながら、コードの構成のレイヤー化を行い、非同期処理を簡潔に記述できる準備をしておくことと、非同期処理とあわせてマルチスレッドプログラミングの基本を抑えておくこと、互換性への準備を最初にし
企画とエンジニアが知っておかないといけない「iBeacon」の話 #iBeacon #yahoo #iOS7｜CodeIQ MAGAZINE
iOS 7から搭載された新機能「iBeacon」。このiBeaconを使ってアプリを作るエンジニアも少なくないのではないでしょうか。 そこで今回はヤフーでiOSアプリを開発している羽田さんに、iBeaconに関する基礎的な部分からサービス設計、サービス事例などについて、解説していただきました。 by 馬場美由紀 （CodeIQ中の人） ちゃんと理解してますか？Appleの新技術「iBeacon」 ヤフー羽田です。 登場から時間も経ち、サービス化されたり、アプリ化されることも珍しくなくなったiBeacon。 そんな今だからこそiOSに携わる企画者・エンジニアとして「知っておかなければいけないこと」が多々あります。 今回は基礎的な部分からサービス設計を含めたiBeaconに関してエンジニアと企画者が、絶対＋最低限知っておくべきことを紹介します。 この記事で学ぶこと iBeaconに関する以下の
J2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーション(3) - 水まんじゅう2
何回かに分けてJ2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーションについて実際のコードを見ながら解説したいと思います。 変更前のサンプルソースはこちら https://github.com/megascus/oi-webapp-sample/tree/initial 第一回はこちら J2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーション(1) ここで一度Webアプリケーションの処理の流れについておさらいしたいと思います。 Webアプリケーションの一般的な処理の流れについて 例外はたくさんありますが、だいたい以下のような順番で処理が行われます。*1 認証、認可等全ての処理に対して行うべき共通処理 入力値の適切な形への変換、検証 DB等のリソースへのアクセス 画面の表示 いろいろ簡略化されていますが、大体こんな感じです。 今回のアプリケ
/.Jに聞け：経産省のシステム管理基準、使ってる？ | スラド セキュリティ
４．プログラミング（４） （1）プログラム設計書に基づいてプログラミングすること。 （2）プログラムコードはコーディング標準に適合していること。 （3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。 （4）重要プログラムは、プログラム作成者以外の者がテストすること。 などだ。いまどきプログラム設計書など作ったことなどないし、納品物として求められたこともない。そもそもプログラム設計書とは何を指すのだろうか。少し大きめの業務システムならクラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ、と言っているのだろうか。 世の中のシステム会社は、本当にこの管理基準に従った開発をやっているのだろうか？
よいものを作るために [結] 2010年5月 - 結城浩の日記
目次 2010年5月31日 - iPad版『数学ガール』が発売開始！ / 2010年5月30日 - 日曜日 / 2010年5月25日 - 火曜日 / 2010年5月24日 - 月曜日 / 2010年5月22日 - 国立科学博物館 / 2010年5月21日 - 勉強の方法 / 2010年5月20日 - 木曜日 / 2010年5月18日 - 火曜日 / 2010年5月17日 - 月曜日 / 2010年5月14日 - 週末の振り返り / 2010年5月13日 - 木曜日 / 2010年5月12日 - 水曜日 / 2010年5月11日 - 火曜日 / 2010年5月9日 - 週末の振り返り / 2010年5月7日 - 金曜日 / 2010年5月6日 - よいものを作るために / 2010年5月5日 - 水曜日 / 2D＆3Dのグラフ描画iPhoneアプリQuick Graphがとても楽しい / 2
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
真面目にエロサイトを作ってみた【プログラマ編】 - BLOG｜ASTRODEO
東京都台東区で黙々とウェブでサービスを開発している株式会社アストロデオのホームページです。
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
要求開発入門 | リコーITソリューションズ株式会社
株式会社 匠Lab 代表取締役社長 萩本 順三 2000年にオブジェクト指向技術の企業、豆蔵を立ち上げ、以降ITアーキテクト、メソドロジストとして活躍してきた大ベテラン。2009年7月、匠BusinessPlaceを設立。また、総務省行政管理局技術顧問や内閣官房IT室GPMO補佐官として、2005年から3年間は、豆蔵と兼務しながら政府のITプロジェクトにも関わる。 現在は、匠BusinessPlaceにて、ビジネスとITの可視化を行うための要求開発をさらに洗練・拡張させた手法「匠Method」を開発。自らユーザー企業で実践している。 株式会社 匠Lab http://www.takumi-lab.co.jp/ 本連載では、萩本順三氏に「要求開発超入門」を紹介していただきます。 要求開発を深く理解してもらうために、誰にでもわかる要求開発を目指して、分かりやすい説明をしていきます。
モバイルサイトの機能もリッチ化する
まずはモバイルサイトの機能の基本をおさえる 今回はモバイルサイトの機能について考えていきましょう。 PCサイトと比較し、モバイルサイトはいろいろな機能を持ったサイトが多いと思います。例えば、小さなレストランのサイトであっても、集客のためのしくみ、空メール登録や割引クーポンの発行システム等を備えていたりします。美容室などでも最近ではモバイルの予約システムを取り入れているようなケースも多いです。 アクション端末でもある携帯の場合は、ワントゥーワンのマーケティングに有効活用が可能です。いつでもどこでもアクセスできる特性からは、即効性のあるマーケティングツールとして利用できるのです。 このようなツールとしての活用面から、簡易なサイトであっても機能を多く求められる傾向があるのです。 モバイルサイトでの機能と言うと、まずは以下のものが挙げられます。多くはコンバージョンへつなげるためのしくみです。携帯を
2008-07-25
いまかなり理想論的なことを言っているが、この件はみなさんおおいに議論して欲しいと思う。 このブログでも再三言ってきているように、欧米からパッケージやソフトウエアを買ってきて、 人月作業は中国・インドにもっていくなんていうモデルはくやしいと思いませんか。 http://kamawada.com/~masanori/blog/2008/07/post_523.html mark-wadaさんに釣られて色々意見が出てくるかとおもいきや、 なんだか意外と意見が出てきていないようなので、自分の意見をマジレスで書いてみる。いつもそうだけど。 自分の意見では、プログラミングファーストは現在のSI開発では（そのままでは）導入できないと思う。 自分の前提は10人以上の開発者が入る（ピークはその数倍以上）感じの中・大規模案件程度ね。 プログラミングファーストはまず幾つかの前提があるように思う。 お客さんがある
『ドメインロジックの実装方法とドメイン駆動設計』
以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。（アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています） http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介 前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
配置図は必須｜恵比寿で働く社長のアメブロ
恵比寿で働く社長のアメブロ株式会社ビープラウド(http://www.beproud.jp)の社長、佐藤治夫が、日々の活動や、日々の思いなどを記録していきます。配置図は必須 今回は、自分の失敗談も含めて、UMLのダイアグラムの１つである配置図の必要性について書きたいと思います。UMLの中でも配置図(コンポーネント図）は、１～３人の少人数の開発になるとついつい省略しがちな図です。 というのも、その規模の開発ですと、仕様の調整、ＦＩＸなどが主な関心事となり、基本設計はテーブル設計くらいで、機能の開発にすぐ入りたくなってしまうからです。 しかし昨年の開発プロジェクトでした経験で、配置図（もしくはコンポーネント図）の作成は、どのような規模でも開発プロセス上、必須であるという考えに至りました。 プログラミングを担当するエンジニアがシステムを開発する際に、注意がまず向くのが機能要件です。機能要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。