論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
#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 などのライフサイクルとうまく付き合いながら、コードの構成のレイヤー化を行い、非同期処理を簡潔に記述できる準備をしておくことと、非同期処理とあわせてマルチスレッドプログラミングの基本を抑えておくこと、互換性への準備を最初にし
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリを作る際に理解しておいて欲しい「Model」という役割について説明します。わりと意識していないケースがあるので、チェックしてみてください。Read less
要約：iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い - Qiita
はじめに 社内勉強会の資料をSlideShareのUPしました。 iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い これについての要点をまとめます。 この資料はiOS/Androidのような クライアントアプリケーションにおける「Model」とは何か、という話です。 Modelとは何か？ Modelに「データやビジネスロジックを扱うコンポーネント」という役割を担わせるというのは多くの人がやっていることだと思います。しかし、サーバ側のWebアプリケーションとは異なり、クライアント側のiOS/AndroidアプリのModelには次の２つの振る舞いがとても重要です。 基本死なない（Singleton的である） 「通知」で変更を伝える（Callback的ではなく） そのようなModelがなぜ必要か？ この2点の役割を持つコンポーネントがなく、特に何も考えずにスマホ
企画とエンジニアが知っておかないといけない「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等のリソースへのアクセス 画面の表示 いろいろ簡略化されていますが、大体こんな感じです。 今回のアプリケ
依存関係逆転の原則（DIP） - Strategic Choice
依存関係逆転の原則（DIP:the Dependency Inversion Principle）上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと？手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで？アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ
インターフェイス分離の原則（ISP） - Strategic Choice
インターフェイス分離の原則（ISP:the Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。どういうこと？クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っているわけではない。すべてのインターフェイスを１つのクラスに押し込めてしまうことはやめ、関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。なんで？「太った」（多機能な）インターフェイスがある。 あるクライアントはそのインターフェイスのすべてのメソッドを利用するわけではない。 クライアントが、そのような利用しないメソッドを含むインターフェイスに依存すると、クライアントはその自分に関係のないメソッドの変更の影響をうけていしまう。 他のクライアントがクラスに強いる変更によって、それ
リスコフの置換原則（LSP） - Strategic Choice
リスコフの置換原則（LSP:the Liskov Substitution Principle）派生型はその基本型と置換可能でなければならない。どういうこと？使う側から言うと、基本型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで？使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば？ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v
オープン・クローズドの原則（OCP） - Strategic Choice
オープン・クローズドの原則（OCP:the Open-Closed Principle）（開放−閉鎖原則） ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならない。どういうこと？オープン（開いている）とは？ モジュールの振る舞いを拡張できる。 クローズ（閉じている）とは？ モジュールの振る舞いを変更しても、そのソースやバイナリはまたく影響を受けない。 なんで？この原則はオブジェクト指向設計の核心。なぜなら、この原則に従えば、オブジェクト指向の最大のメリットを享受できる！ 柔軟性再利用性保守性たとえば？具体例として、よくある図形の例 。switch/caseで図形の種類ごとに処理を行う。 こうすると、図形の種類が追加になるたびにこの処理が変更になる。 ここで大事なのは、switch/caseがおそらく一箇所ではないところ。 至る所に図形の種類ごとの色々な処理が
単一責任の原則（SRP） - Strategic Choice
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
オブジェクト指向設計原則 - Strategic Choice
原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則（SRP）オープン・クローズドの原則（OCP）リスコフの置換原則（LSP）依存関係逆転の原則（DIP）インターフェイス分離の原則（ISP）参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本 Principles Of Object Oriented Designオブジェクト指向設計＠Syboos.jpオブジェクト指向設計の原則＠それはBooksオブジェクト指向設計原則＠ディノオープンラボラトリオブジェクト指向の法則
【iOS】Viewの再利用性が確実に高まるiQONアプリのView構成 | VASILY TECH BLOG
はじめに こんにちは、iOSエンジニアの荒井です。 先日、株式会社Rettyのエンジニアの方々と技術勉強会を開催しました。 今回はiOSアプリについて、自分たちが使用している技術を紹介し合いました。 その場でXcodeを立ち上げ、instrumentsを起動してのLIVEメモリリーク調査など、 通常の勉強会とは違った形式で、とても有意義な技術交流の場になったと感じています。 僕からも「iQONのVIew構成」というお題でお話させて頂いたので、 今回はその資料を公開したいと思います。 スライドと補足 資料はslideshareにて公開していますが、まずスライドの流れを簡単に紹介したいと思います。 iQONでは現在多くのViewController・Xibがあります。 その数は100を超え、複雑な画面設計も相まって、工夫をしないと開発工数がかさんでしまいます。 ViewControll
/.Jに聞け：経産省のシステム管理基準、使ってる？ | スラド セキュリティ
４．プログラミング（４） （1）プログラム設計書に基づいてプログラミングすること。 （2）プログラムコードはコーディング標準に適合していること。 （3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。 （4）重要プログラムは、プログラム作成者以外の者がテストすること。 などだ。いまどきプログラム設計書など作ったことなどないし、納品物として求められたこともない。そもそもプログラム設計書とは何を指すのだろうか。少し大きめの業務システムならクラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ、と言っているのだろうか。 世の中のシステム会社は、本当にこの管理基準に従った開発をやっているのだろうか？
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IOS/Androidアプリの３つの大事な設計方針
