JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
今最も注目されている設計手法！MVVM を Android アプリ開発に取り入れてみた
こんにちは。共同開発部開発担当の北川です。 クロスプラットフォームなアプリ開発では Xamarin の使用はビジネスロジックの共通化が可能となり非常に効果的です。 すべてのアプリを単一の言語（C#）で実装することができる点だけでも魅力的ですが、MVVM 設計によりその再利用性を高めている点こそがその真価を発揮しているとも言えます。 私は Xamarin でのアプリ開発を通して MVVM 設計のすばらしさを経験してしまいました。もう後には戻れません。 Java や Objective-C でのアプリ開発でも MVVM 設計は開発スピードと品質確保を両立するために有効であるはずです。 今回は Android アプリ開発（Java）で MVVM を使うとどうなるか、紹介してみたいと思います。 MVVM 設計について MVVM 設計ではビジネスロジックを Model が担当し、ViewModel
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
関連モデルの命名 - 鳩舎
今日は Rails での『関連モデル』の名前について考える。 構造としてはこんな感じ。 ・ルーム(Room)に所属するユーザー(User) ・ルーム(Room)での管理者権限を持つユーザー(User) どちらの関連も N:N の関連。いわゆる has_may な感じ。 で、こういう時の命名って Room モデルと User モデルだから RoomUser とか UserRoom とかっていうモデルやテーブルを作りがちなのだけれど、今回は同様の形態の関連が2つあるのでちょっと微妙な事になりそう。 っていうか、まずもって RoomUser モデルってなんだよ。なんのモデルだよそれ。って感じなので名前を考える。 ルーム(Room)に所属するユーザー(User) 関連モデルのデータは大抵2つのフィールドを持っている。 Migration あたりから抜き出すと t.references :room
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
サーバとL2スイッチの接続を冗長化する設計の基本 - GeekFactory
インフラを設計する上で冗長化による信頼性向上は避けて通れない道です。サーバとL2スイッチの接続を冗長化する設計については意外と情報が少ないのでまとめてみました。変なこと書いてたらご指摘ください。 インフラ設計の基本は単一障害点（SPOF）を取り除くことです。構成要素のうち1つが故障してもサービスを維持できるように設計します。構成要素は以下のものが挙げられます： CPU マザーボード メモリ ローカルディスク 電源 FC-HBA NIC LANケーブル L2スイッチ ・・・ ただし、これらすべての故障に備えようとすると費用対効果が割に合わないので、ローカルディスクから下を冗長化する構成が一般的と思います。絶対に止まってはいけないサービスは別ですけどね。 冗長化の種類 サーバを冗長化するにはクラスタを組みます。クラスタはActive-ActiveとActive-Standby（HA）の二種類に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モデリングもしないでアジャイルとは何事だ