2018-02-28 wed. 第 3 回 Google Cloud INSIDE Games & Apps Fringe81株式会社 豊島 正規 氏の登壇スライドです。

最近まったくAndroidアプリを書く機会＆暇がないけど心はネイティブアプリ開発者なので なんとか行ってくることができたので見たスライドごとのまとめ 1日目の発表 Kotlin アンチパターン これから発表する「Kotlinアンチパターン」の発表資料です🙋 #DroidKaigi #DroidKaigi_Hallhttps://t.co/HF9blGeI0X— Naoto Nakazato (@oxsoft) 2018年2月8日 感想 言語仕様的な部分もあるが使い勝手的な部分も多い Dataクラスとか便利だけど振る舞いとか継承とか考えるとうーんってなる感じ How to improve your MVP architecture and tests 11:20からRoom1でのセッション、How to improve your MVP architecture and testsのスライ

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 目次流しは以前書きましたが、読み終わってるので改めて。 一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。 読書会をしてみて 4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。 平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いな

現場で役立つシステム設計と実装、リファクタリングに開発プロセスにOOPとDDDの本 ドメイン駆動設計（DDD: Domain Driven Design）の実践者としても知られる増田 亨さんの2017年7月の本。ネットでもかなり話題になったので読んだ人も多いのではないでしょうか。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨発売日: 2017/07/05メディア: Kindle版 タイトルは「～システム設計～」となっていますが実際は設計以外の話もあるので、もう現場で役立つシステム「開発」全般で役立つ原則本となっています。 技術評論社から各種出ている一般的な技術書サイズで422とボリュームはありますが、内容はかなり推敲されていて文章はとても読み易いです。 サンプルコードはすべてJava。しかし本書で述べられているテクニックはかの『リファクタ

良いコードを書けるようになりたい 私は基本的にはソフトウェアはずっと趣味で独学でやってきたのですが、最近GitHubでコードを公開するようになったり、仕事でも少しソフトを書くようになったので、良いコードを書くための基礎を勉強したいなと思い、年末年始に以下の本を読んでみました。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)posted with ヨメレバDustin Boswell,Trevor Foucher オライリージャパン 2012-06-23 AmazonKindle楽天ブックス ベタープログラマ ―優れたプログラマになるための38の考え方とテクニックposted with ヨメレバPete Goodliffe オライリージャパン 2017-12-15 AmazonKindle楽天ブックス 「リーダブルコード」

人類学者がUXリサーチに役立つ理由 みなさまはじめまして、比嘉夏子と申します。 私はもともと、海外で長期異文化フィールドワークを実施して人間の価値観や行動について研究してきた人類学者です。最近では人類学の研究で用いられてきた調査手法、いわゆる「エスノグラフィ（人間を経験的・包括的に理解するための記述と手法）」を用いた定性的なリサーチに従事する機会を、人類学研究以外の場でいただくようになりました。 そして現在は京都大学の研究員として在籍しながら、A.C.O.ではUXリサーチの開発をしています。 ところで。 地図で探しだすのにも苦労するような太平洋の小さな島に足を運んで現地語を学び、参与観察をしながら暮らしていた研究者が、なぜいまこうしてUXという全く異なる世界に携わっているのか。一見するとかけ離れた領域のあいだにも、じつは通底する思想や応用できる手法があるのです。そのような断片を、今回はお伝

IntelliJ IDEA, PlantUML, Spock を使って DDD, UDD(仮) を試みている話IntelliJPlantUMLDDD 10月頃から、一部有志を集めて学習会を開いていて、その第一弾に選んだ題材が DDD (Domain-driven design) だった。 まだ道半ばであるが、ここいらで一度まとめておきたい。 tl;dr Kotlin, IntelliJ, PlantUML, Spock の使い方の解説はない DDD の解説はない 正しい DDD とは、とかも無いです UDD は、ubiquitous language driven design 造語です DDD を目指しドメイン設計を実施してみて、何が変わったのか 実施前 業務ドメインが分からなすぎた でも、取り敢えず設計・作成するだけならこれでも行けた でも、やっぱり業務知らないと、将来的に辛い お客さ

フューチャーアーキテクト Advent Calendar 2017の2日目です。 はじめに システム設計が大好きで大嫌いな皆さん、こんにちは。 突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか？ ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。 解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理する

little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、

この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンス本に挫折したら･･･ DDDと言え

境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 「オブジェクト指向入門 第3章モジュール性」メモ - $shibayu36->blog; の続きで、「第6章 抽象データ型」を読んだ。 この章では、オブジェクトを適切に表現する記述として、抽象データ型というものを紹介している。これが非常に参考になったので軽く読書メモをとっておく。 抽象データ型とは 抽象データ型の仕様の記述とは以下の4つを記述することであるようだ。 TYPES(型) FUNCTIONS(関数) -> その抽象データ型に適用可能な操作の集合 AXIOMS(公理) -> その抽象データ型が必ず満たす条件 PRECONDITIONS(事前条件) -> 部分的な関数のソース集合の定義域 STACKの例を見

ドメイン駆動設計の４つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方

3. 3 長谷川 裕一 • 合同会社Starlight&Storm 代表 • 日本Springユーザ会 会長 • Springやオブジェクト指向を中心にしたコンサルティ ングや教育で活動中 https://www.facebook.com/ starlightandstorm/ https://twitter.com/StarlightFuku 3 4. 本日の内容 • マイクロサービスの基本的なハナシ • マイクロサービスが、なぜ必要なのか？本当 に必要なのか？ • マイクロサービスの開発は、どうしたら上手く いくのか？失敗するのはなぜか？ • と云ったことを、自分なりの経験とか知識とか で咀嚼して… • 技術的なハナシは少ないです 4 5. マイクロサービスとは… • みんなが欲しいのは、狭義のマイクロサービ スではなく、広義のマイクロサービス – 狭義 • Microservice

3. 3 長谷川 裕一 • 合同会社Starlight&Storm 代表 • 日本Springユーザ会 会長 • Springやオブジェクト指向を中心にしたコンサルティ ングや教育で活動中 https://www.facebook.com/ starlightandstorm/ https://twitter.com/StarlightFuku 3 4. 本日の内容 • マイクロサービスの基本的なハナシ • マイクロサービスが、なぜ必要なのか？本当 に必要なのか？ • マイクロサービスの開発は、どうしたら上手く いくのか？失敗するのはなぜか？ • と云ったことを、自分なりの経験とか知識とか で咀嚼して… • 技術的なハナシは少ないです 4 5. マイクロサービスとは… • みんなが欲しいのは、狭義のマイクロサービ スではなく、広義のマイクロサービス – 狭義 • Microservice

ドメイン駆動設計の４つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方

これが大変に評価の高い本で、邦訳が長らく待たれましたが、ようやく2011年に「エリック・エヴァンスのドメイン駆動設計」というタイトルで出版されました。 このドメイン駆動設計ですが、技術者の間ではしばしばDDDと呼ばれます。 これらのパターンのうち必要なものを状況に応じて適用することによって、オブジェクト指向が本来持っている、再利用性や保守性といった利点を最大限に生かすことができます(｀・ω・´) 前提となる知識 DDDはオブジェクト指向デザインパターンの本ですので、オブジェクト指向設計における一定の経験と知識は必須となります（デザインパターンについての知識は必須ではありません）。 リレーショナルデータベースを備えたエンタープライズWebアプリケーションを前提としているので、サーバーアプリケーション設計・開発の経験があると理解がスムーズです。 アーキテクト向けの本ですので、UMLのクラス図や

こちらの本を読んででのレポートです。現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法【電子書籍】[ 増田亨 ] 価格：3175円 (2017/11/4時点) 複雑な業務ロジックは「適切な境界」で分離されていれば理解しやすくなる！ …が最近の自分の持論なのですが、じゃあ「適切な境界」って何よ？　…と言われると、うまく言語化説明できない。 そんな私にたくさんヒントを与えてくれた本でした。 なかなか消化しきれていないところもあるのですが、腹落ちさせるためにもブログに落としてみます。 このブログに書いたことをまとめると・・・ 修正が大変なのはロジックが分散しているから データとロジックをひとつのクラスにまとめるとロジックが分散しない！ じゃあWeb APIでサービス間連携するときも、データを持つほうにロジックを寄せるべき…　と思ったら、そうでもない？ この本のすごい

最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク