タグ

設計に関するnaokun776のブックマーク (4)

  • データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3

    3. 2 Agenda 1. 自己紹介 2. RDBMSで履歴データを扱う  スナップショットデータモデル  トランザクション時間データモデル  有効時間データモデル  バイテンポラルデータモデル 3. Javaからバイテンポラルモデルを容易に扱うReladomoの紹介 hashtag: #ccc_g3 4. 3 自己紹介 趣味:ドラム演奏 JavaOneコミュニティバンド Null Pointersで演奏経験あり(日人初) Tech Lead @ FOLIO 伊藤 博志 Eclipse Collections:共同プロジェクトリード兼コミッター Reladomo:コントリビューター OpenJDK:コントリビューター JJUG CCCJava Day Tokyo、JavaOne San Francisco登壇 2017年5月17日に株式会社FOLIO入社。 hashtag:

    データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
  • 「設定」を設計するための資料 - Hibariya

    プログラムは、なるべく何もしなくても良い感じに動いてくれるのが理想的だけど、実際には何らかのかたちでユーザの設定を必要とすることがある。 Rails を使うときは config/application.rb でタイムゾーンを指定したり、DB へ接続するための情報を config/database.yml に指定する。 Bundler の挙動を変えたければ bundle config で設定を変更する。 Gem をインストールするときに毎回指定したいオプションがあれば、~/.gemrc に追記する。 もし自分の関わるプロダクトに「設定」のAPIが必要になったとき、何を判断の基準にして設計すればいいだろう。 ちょっと近所を見渡すだけでも、「設定」のやり方には色々ありそうだ。 設定という視点から、Rubyist にとって身近なプロダクトたちを資料として眺めてみた。 (NOTE: ちょっと悩みなが

  • アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか

    図1.シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード(”製品コード”と”テストコード”)です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか?その質

    アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
  • やさしい設計 〜 Android 編 - Qiita

    アプリを作っていてありがちなこと Android には、画面を構成するための Activity というコンポーネントがあり、概ね MVC フレームワークの Controller に相当する機能を持っています。 MVC といえば、肥大化する Controller というのがよくある問題として挙げられますが、Activity も例に漏れず、往々にして肥大化しがちです。 また、Model も、その責務を詰め込んでいくと肥大化しやすいレイヤと言えます。 この投稿では、Controller や Model の肥大化を極力防ぐためのレイヤわけを、Android アプリ向けに書いていきます。 Activity を綺麗に保つ Activity は、Controller として、様々な UI から受けるイベントを受けて、適切にハンドリングする役割を持っています。 OptionsMenu や ContextM

    やさしい設計 〜 Android 編 - Qiita
  • 1