BEAR.Sunday meet up #2

たきぐち in the Cloud💙💛 @atakig

contextに応じてLayeringできるようにすればどうか #BEARsunday

たきぐち in the Cloud💙💛 @atakig

Form層のLayering #BEARsunday

NEKOGET@要件定義屋さん @NEKOGET

出来る事を増やすためにコードを増やすのでいいのか？ AOPでの回答 #BEARSunday

ただあき @tdakak

準備するもの、利用するものがクリアに分けられている #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

「すべてはリソースである」 #BEARSunday

たきぐち in the Cloud💙💛 @atakig

RESTのため、抽象化されたAPIを使う #BEARsunday

たきぐち in the Cloud💙💛 @atakig

最後に残るのはDatabase #BEARsunday

NEKOGET@要件定義屋さん @NEKOGET

API driven development 世界はDBからAPIになった #BEARSunday

たきぐち in the Cloud💙💛 @atakig

ResourceもResourceで構成されている #BEARsunday

たきぐち in the Cloud💙💛 @atakig

ResourceもLayeringされている #BEARsunday

たきぐち in the Cloud💙💛 @atakig

一番外側はApp script #BEARsunday

たきぐち in the Cloud💙💛 @atakig

Page Resourceはcontrollerに近い。非常に単純ならPage Resourceだけで済む #BEARsunday

NEKOGET@要件定義屋さん @NEKOGET

ページを見てる人は、中の構造には関心が無い #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

このlayered Resourceの図はすごくわかりやすいなぁ。なんとなく躓いていた自分の中の意識が今変わった感じがする。#BEARSunday

たきぐち in the Cloud💙💛 @atakig

#BEARsunday のプログラミングは、実装をプログラミングするのではなく、構造をプログラミングする

NEKOGET@要件定義屋さん @NEKOGET

実装をプログラミングするのではなく、構造をプログラミングする なるほど！ #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

viewからリソースを取ってくるpullアーキテクチャ #BEARSunday

ただあき @tdakak

リソース指向ではコントローラの概念がない。情報に名前がついている。 #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

クラス名ではなくuriで情報を管理している。なぜならリソースが中心のフレームワークだから #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

すべてが接続のための技術 DI AOP REST #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

接続の威力。 #BEARSunday

ただあき @tdakak

DI/AOP/REST いずれも接続。BEARは接続のフレームワーク。 #BEARSunday

NEKOGET@要件定義屋さん @NEKOGET

世界は接続されて繋がっている #BEARSunday

たきぐち in the Cloud💙💛 @atakig

2回目移行は10万が300になる #BEARsunday

halt@無職 @halt

このわくわく感がBEAR.Sundayだなー。 #BEARSunday