RPG Maker MVの「MADO」を早速使ってみた!

2017年9月7日、RPG Maker MVの拡張ツール「MADO」がリリースされました。
tkool.jp

早速使ってみたのでエントリーに残しておきます。

起動するとこんな感じ

f:id:yasay:20170907224021p:plain 「会話」,「ステータス」,「戦闘」,「その他」それぞれのウインドウを
カスタマイズできます。エクスポートするとそれぞれ画像ファイルとして出力されます。
機能としてはシンプルで、ただそれだけです!(現状は)

早速、適用してみた。

効果が分かりやすそうなウインドウで試してみました。

  • タイトル f:id:yasay:20170907224307p:plain

  • ロード画面(AltSaveScreenプラグインを使用中) f:id:yasay:20170907224336p:plain

  • メニュー画面 f:id:yasay:20170907224408p:plain

悪くない。いいですね!(興奮)

本質はプラグインと画像ファイルにあり

MADOのツール自体は、プリセットで用意されている素材を
組み合わせて画像を生成するので、プリセットだけの表現では限界があります。
これは、バージョンアップでの素材追加や個別素材の追加機能などに期待です。

どちらかというと、本質はプラグインと画像ファイルにあると思います。
プラグインは公式で提供されており、画像ファイルだけをカスタマイズすれば
プリセット以外の表現も可能です。

  • MADOでエクスポートした画像は下記のようなフォーマットになっている。 f:id:yasay:20170907225832p:plain

カスタマイズで独自ウインドウを表示している場合などに注意

プラグインによって戦闘中とメニューで違う画像を使用することが
可能になりますが、本プラグインとは別のプラグインで独自に定義したウインドウ枠に
メニュー用画像が適用されてしまって、
ちぐはくになってしまう場合があります。

この場合、自分でプラグインを改変するか、
プラグイン作者様に改善をお願いする必要があると思います。

  • ちぐはぐな例 f:id:yasay:20170907224953p:plain

以上です!

謎のRPGをリリースしました。SAM(Serverless Application Model)も使い始めました。

前回のエントリーから早2週間強、
仕事で忙しく、夏休みもろくに取れてません。
皆様、残暑いかがお過ごしでしょうか。

そんな中、謎のRPGのVer0.01をリリースしました。

謎のRPG「Cyrus ~The Worlds and Gods dream~(仮称)」

f:id:yasay:20170825091109p:plain
Copyright © 2017 相馬はやて
http://www.xblood.gq

ブラウザゲームですのでスマホでも遊べます。
目的はサーバレスアプリケーションとの
連携を構築することです。

今はフロントの部分は30分~1時間位で終わる程度しか制作できていませんが、
ゲームのバージョンアップを通して内容も充実させていきたいと思います!

現在はVer0.02としてSAMによる
Serverless Application Modelを構築中です!(やっと本業開始)

リリースノートはこちら↓

http://cyrus-front.s3-website-ap-northeast-1.amazonaws.com/release_notes.html

GitHubページはこちら↓

github.com

よろしければ遊んでみてください!
創作活動たのしー
以上です!

MVのプロジェクトをリポジトリ管理する時は.gitignoreを意識しよう

MVのプロジェクトをリポジトリ管理してみたので、
備忘録も兼ねて残しておきます。

パブリックリポジトリで公開することのリスク

https://tkool.jp/support/guideline
こちらの利用規約にある通り、
画像や音声ファイルは同シリーズでのみ利用できます。

ですので、誰かがパブリックリポジトリに公開している
MV標準の画像や音声を第三者がダウンロードして勝手に違うプログラム作品で
利用するようなことは、制作者自身で自衛するべきだと思います。

巷にはGitHubページで作品を公開するような手法もありますが、
あの手法自体、危険だと思っています。
ファイルが暗号化されていればまだマシだとは思います。

そもそも画像や音声ファイルをリポジトリ管理してどうなる

画像や音声ファイルはバイナリファイルなので
コードの差分も見れないですし、ファイルサイズも大きいんです。
あまり知られていないかもしれないですが、GitHubリポジトリサイズは
1GB以上使うと警告がくる可能性があるみたいなんです。

1GBなんて、動画やPSDファイルなんて置こうものなら、
一瞬でなくなることでしょう。
コード管理することが主目的のGitHubでサイズの大きい画像や音声ファイルを
管理すること自体が望ましくないことです。

それならどうする?

.gitignoreでリポジトリ管理から除外しよう。

.gitignoreファイルに除外対象ファイルを記載すれば、
対象ファイルを無視した形でコミットされます。
MV用の.gitignoreファイルを作ってみたので下記に記載します。

# .DS_Store
.DS_Store

# audio
/audio/*

# audio -> bgm
!/audio/bgm/
/audio/bgm/*.m4a
/audio/bgm/*.ogg
!/audio/bgm/.gitkeep

# audio -> bgs
!/audio/bgs/
/audio/bgs/*.m4a
/audio/bgs/*.ogg
!/audio/bgs/.gitkeep

# audio -> me
!/audio/me/
/audio/me/*.m4a
/audio/me/*.ogg
!/audio/me/.gitkeep

# audio -> se
!/audio/se/
/audio/se/*.m4a
/audio/se/*.ogg
!/audio/se/.gitkeep

# fonts
/fonts/*.ttf
!/fonts/.gitkeep
/fonts/bk/

# img
/img/*

# img -> animations
!/img/animations/
/img/animations/*.png
!/img/animations/.gitkeep

# img -> battlebacks1
!/img/battlebacks1/
/img/battlebacks1/*.png
!/img/battlebacks1/.gitkeep

# img -> battlebacks2
!/img/battlebacks2/
/img/battlebacks2/*.png
!/img/battlebacks2/.gitkeep

# img -> characters
!/img/characters/
/img/characters/*.png
!/img/characters/.gitkeep
/img/characters/bk/

# img -> enemies
!/img/enemies/
/img/enemies/*.png
!/img/enemies/.gitkeep

# img -> faces
!/img/faces/
/img/faces/*.png
!/img/faces/.gitkeep
/img/faces/bk/

# img -> parallaxes
!/img/parallaxes/
/img/parallaxes/*.png
!/img/parallaxes/.gitkeep
/img/parallaxes/bk/

# img -> pictures
!/img/pictures/
/img/pictures/*.png
!/img/pictures/.gitkeep

# img -> sv_actors
!/img/sv_actors/
/img/sv_actors/*.png
!/img/sv_actors/.gitkeep
/img/sv_actors/bk/

# img -> sv_enemies
!/img/sv_enemies/
/img/sv_enemies/*.png
!/img/sv_enemies/.gitkeep

# img -> system
!/img/system/
/img/system/*.png
!/img/system/.gitkeep
/img/system/bk/

# img -> tilesets
!/img/tilesets/
/img/tilesets/*.png
/img/tilesets/*.txt
!/img/tilesets/.gitkeep

# img -> titles1
!/img/titles1/
/img/titles1/*.png
!/img/titles1/.gitkeep

# img -> titles2
!/img/titles2/
/img/titles2/*.png
!/img/titles2/.gitkeep

# movies
/movies/*
!/movies/.gitkeep

# save
/save/*
/save/*.rpgsave
!/save/.gitkeep

pushするとこんな感じで管理される。

f:id:yasay:20170808142222p:plain いい感じですね。

もちろん、imgディレクトリには何も入ってません。

f:id:yasay:20170808142326p:plain .gitignoreによる除外設定の目的は達成しました!

プラグインはライセンスの確認を!

PluginはMITライセンスで改変が可能なモノが多いですが、
使用するPluginのライセンスを確認した後にコミットすることをオススメします。

画像や音声ファイルなどは、管理手法を明記する。

README.mdに記載すると良いでしょう。
必要ならコピースクリプトを作成してもよいですね。

プライベートリポジトリも考慮しよう

MVで複数人で作業すること自体が
レアケースだと思いますが、そういったことも可能かもしれません。

今回のケースはどちらかというと、自動ビルドの起点だったり、
一人で複数環境で作業するようなことを前提としてリポジトリ管理について書いています。

ですので、もし他の人に自分のprojectファイルを見られたくない時は、
リポジトリをプライベートにして参照できないようにしましょう。

GitHubではできませんが、
Bitbucketなら5人までならプライベートリポジトリを無料で作成できます。
bitbucket.org

以上、参考になれば幸いです。
よい制作活動を!私はそろそろサーバーサイドに着手しますw

「ファーストリテイリング × クラスメソッド勉強会」に行ってきたよ!レポート

マイクロサービスとAIについての勉強会ということで、
わくわくしながら行ってきました。場所はSAPオフィスです。
dev.classmethod.jp

ユニクロなど大手衣料品店を経営するファーストリテイリング様と、
クラスメソッド様の合同勉強会です。
採用活動も目的としてあるようでしたが、私はエントリーする予定ありません(笑)
マイクロサービスの苦労話が本当に参考になる勉強会でした。
また、パネルディスカッションは私の価値観を大きく変える可能性のあるものでした。

まずは、レポートしていきます!

レポート

FRが取り組むmicroservicesとアーキテクチャ変革

  • FRの取り組み
    • 技術力の長期的な確保と選定
    • 日本から世界に向けてチャレンジを
    • グローバルチームの構築
  • IT内製の実態
    • AWS4000台、マルチリージョン利用
    • AzureやGCPも使っている。
    • CDNにはAkamai
    • JavascriptJavaがメインになる。
  • マルチブランド・マルチリージョン
    • 店舗・EC含めてビジネスが十分に複雑
    • 変化のスピードが非常に早い→通常の会社より5倍くらいのスピードがある会社。
  • Queueにkafkaを利用してたりする。
  • Microservice 良い点
    • 技術負債は返しやすいので技術選定の心理的負担が比較的低い
    • 障害の局所化。全死のリスクが低い
    • 開発が平行でできやすい
    • クラウドで力技回避が比較的しやすい
    • 責任分界がわかりやすい
    • FR様のような複雑な環境下では、逆に他の方法ではうまくいかない。
  • Microservice 課題
    • 技術的に統制効きにくい
    • 運用は自動化込みじゃないと難易度があがる
    • 各サービスでのプロダクトマネージメントの観点が必要
    • 各サービスでオーナーをしっかりたてていく必要がある
  • プリミティブなビルディングブロック探しが大事(最初のキーとなるコンポーネントがあるから、上のサービスができる)
  • ビジネスバリューを出すための最小粒度が大切(ビジネスドメインとWillが重要)
  • 大事なのはビジネスを支える最小単位のコンポーネントは何かを考える必要がある
  • Microservices for data
    • 実績データ
    • 計画領域
    • IoT
    • 各種マイクロサービス
    • イメージ管理
    • アナリティクスなど
  • →データプラットフォームに格納して、あとからどうやって活用するかを考える。
    • データの長期の保存と、データの利活用を分ける。すごいなー。
  • Microserviceを支えるDevOps
    • インフラの自動化+デプロイの自動化が基本。
    • 課題は標準化・大きな粒度での自動化などがまだ
    • ツールだけから、組織で広域な自動あの取り組みへ
  • 自動化していくにあたり、問題にぶちあたる
    • 大量の技術負債
    • 組織的な問題や仕事の分量そのものの見直し
    • プロセスの見直しや役割がおかしい部分が明らかに
    • 全員がちょっとづつコンフォートゾーンから出る必要性
  • 自動化そのものよりも、その過程でのプロセスや組織体制・チームの分担などの変化が大事に思える。
    • ツール選びで何か変わったわけではない。
    • 呼び水となったのは運用不可を劇的に下げたいなど
  • ビジネスのバリューストリームへの貢献度は低い
    • 今品質が大事なのか、タイムラインが大事なのか、
    • それに応じて自動化の仕組みが変わってくる。
  • みんなで取り組まないと定着しない・・。
    • ツールだけで達成できるものじゃない。
  • これからのアーキテクチャを考える。
    • 基本的にはone way(大きなものを適切な粒度に分界)で、これは避けられない
    • SoR的なことだけが求められているわけでもなく、顧客同行により常に変化していく必要がある
  • KISS
  • YAGNI
  • 関心事の分離
  • リスコフの置換
  • Microservice.ioを見れば、どのようなデザインパターンや黄金律があるのか、大体まとまっている。
    • すごいな。microservices.io/patterns/index.html
  • まとめ
    • Microserviceは総合力。技術だけでなくて、チーム編成からDevOpsまで含めてやらないと効果はでない
    • 足回りのDevOpsは当たり前に強化する必要がある
    • チーム編成も大事。色々なタイプの人が必要。
    • 全体の相互理解・底上げ、普通の話だが大事
    • 世の中の複雑さをいかにシンプルに解決するか
    • ビジネスを成立させるための最小粒度のコンポーネントが大事

Amazon Alexa の衝撃と新たなエコシステム

  • Alexaを使った音声インターフェースの事業部について
    • クラスメソッドってデカイんだなー・・。
    • 700社から1000社と取引
    • 世界にまたがるオフィス
    • セルフマネジメントとアウトプットを重視する会社
    • 子供が生まれたら半強制的に休ませる
  • Alexa事業部について
    • 設立の経緯は、一言でいうと面白そうだから。
    • iPhoneが出てきた頃の黎明期に似ている!?
    • 新しいUIが出てくる頃には世の中は激変する傾向にある?
  • 世代別の利用サービスから見る音声の需要
    • シニア層は音声インターフェースを必要とするはず
    • 国による違いはなくなってきているけど、世代間のギャップのほうが大きい
  • 働く人が必要なのに減る。
    • 人が少なくなっていくなかで、付加価値の高い業務に注力して、付加価値の低い業務は自動化などを推し進めていく必要がある
  • 裏側のシステムが重要(カスタムスキルはOAuthを利用する必要ある的な)
  • カスタムスキルの例
    • スタバ - 直近10店舗で注文したドリンクの再注文やスタバカードの残額確認
  • クラスメソッドのカスタムスキル、20個くらいある。
  • 帳票の仕組み+音声サービスでユーザーエクスペリエンスを目指す→それがEcho Show
  • dash wand→バーコードリーダーがついていて、Amazonで注文できる。さらに音声操作できる。
  • VUIによる個人ではなく企業への問題解決のために、事業部署を設立的な。
  • まとめ
    • 音声はすべての人々にリーチする
    • その技術を使って、事業の価値を高める。

所感

たまに、このような魅力的な勉強会があるから、勉強会は本当に行くべきだと思う。
今回は、自分自身のITの価値観が変わる出来事だったかもしれない。

それはパネルディスカッションで起きました。

レガシーになることを意識する

私はここ最近、様々な技術知識の吸収を行ってきましたが、
これらの技術も最終的にレガシーになりえるわけなんですよね。
つまり、技術を追い求める上で、その知識はどれもレガシーになりえることを覚悟しておかなければならないわけですね。
これはAWSも同じことなんだと思います。。私はAWSの認定資格を取得しましたが、
この認定資格すら、レガシーになりえるわけですね。

そして、AWSは100以上のサービスがあるわけですが、
実際に主流として使われているサービスが100以上あるわけではないということも、
理解しなければいけませんでした。
AWSなどのパブリックIaasは非常に魅力的ですが、その全てのサービスが
ITベンダーに受け入れられているわけではない、ということなんだと思います。

主催会社様の意外な印象

個人的に意外な印象を受けたのが主催会社様の運用保守メンバーが
全社員の3分の1近くを占めていることでした。
私は今まで散々運用保守はやってきたので、
最近はもっと違うことをやってみたいと考えています。
しかし、お客様と取引する関係上、
やはり簡単に今の案件を抜けることは難しいのでしょう。
システム屋、とくにサーバ屋は運用保守とは切っても切れない関係にあるのでしょうね。

「分からない」ということを正確に伝えることのリスク

それと、自分が今持っている引き出し知識以上のことが分かっていないことを
ちゃんと伝えられることは重要という話がありましたが、これってリスクもあると思っています。

私は上記のことを実践しています。なぜなら、嘘をつくよりはわからないと伝えたほうがいいから。
でもこれが、たまに舐められることがあるんですよ。見下されるんです。
個人のバックグランドや得意技術はそれぞれ異なるはずなので、一緒に知識を補って補完してくれる
メンバーと一緒に仕事したいですよね。と、心底思います。

ITエンジニアの出せるパフォーマンス

ITエンジニアが一人で出せるパフォーマンスの現実を、
私はもっと理解しなければいけないと思います。

一人のスーパーエンジニアが10のパフォーマンスを出せるとして、
他のエンジニアが5しかパフォーマンスが出せないとしても二人いることで
スーパーエンジニアのパフォーマンスに届く可能性があります。
そういったエンジニアの集まりでチームを形成し、一人では長時間かかる案件を
短時間で作り上げていく。
私たちは一人では出来ない事をチームで実現することが多いのです。

チームで仕事をするとなると、どうしても技術レベルの低い人に合わせることがあるし、
全員にスーパーエンジニア並みのパフォーマンスを求めるのは不可能です。

技術勉強会では登壇者が主役となり、アウトプットを見せることがありますが、
もしそれがチームで行った成果なら、そのアウトプットの背後には
チームメンバーが出した成果も含まれていることもありえると思います。

一人で仕事をしたいなら、フリーランスになって
自分自身のやりたい仕事をマネジメントしてみたほうがいいかもしれない。

会社が個人のアウトプットを重視するのか、チームのよる成果を重視するのかによりますが、
どちらにしても本当に自分自身が居心地のいい職場が存在するかというと、
どうなんだろうと思ってしまいます。

参加した皆さん、お疲れ様でした!
以上、かなり長文になりましたが、レポート終わります!

JQuery Sortableで子要素が完全になくなった場合でも再設定させる小技

備忘録的なエントリーになります。

本エントリーは下記バージョンで動作確認しています。

JQuery 1.9.1
JQuery UI 1.9.2

JQuery Sortableって面白いですよね。
jqueryui.com
以前担当していた案件で、連携先のシステムが使用していたんですが、
座標のことを気にしないでドラッグアンドドロップで移動できるところが
気軽に使える感じでいいと思いました。

そんなJQuery Sortableなんですが、
実は要素を全て移動してしまうと、元に戻せないという
ケースがありました。

例えば、こちらのページで要素を全て移動してしまうと、
元に戻せません。
jqueryui.com

ですので、要素が全部なくなってしまった時に、
移動できない固定の要素を挿入するようコーディングしてみました。
こうすることで、要素を元の場所に戻すことができます。

JSFiddleはこちら↓
jsfiddle.net

JQuery Sortableは活用する機会があれば、
ガンガン使っていきたいですね!

以上です。

JAWS-UG CLI専門支部で「AWS CLIでEC2の利用料金を節約してみた」というタイトルでLTしてきました

遅くなりましたが、LTしてきたので報告的なエントリーです。
勉強会はJAWS-UG CLI専門支部です!主に茅場町を拠点としているようです。
jawsug-cli.doorkeeper.jp CLIの使い方を学習し活用方法を議論する勉強会です。
開催される頻度が高く、ハンズオンはついていけないくらいのボリュームがあるので、
何度か足を運んでみたいと思います。

上記勉強会にて、
AWS CLIでEC2の利用料金を節約してみた」というタイトルで、LTしてきました。

www.slideshare.net 内容的には大したことないんですが(本当に)、
CLI使ってこんなことできるよー的な、AWS初心者の方にとっては
そこそこ面白い内容なのではと思います。

GitHubページはこちら github.com 引き続き、LTできるようなアウトプットを目指して日々精進していきます!
以上です

「JSUG勉強会 Spring I/O報告会」に行ってきたよ!レポート

f:id:yasay:20170710131153j:plain
Springは他のフレームワークの開発終了やJava EEの開発遅延などによって
より進化の早いフレームワークを求める人達が活用している印象があります。

開発者からしてみればデファクトスタンダードだろうがなんだろうが
今現場で使用しているフレームワークをないがしろにできないのが正直な所です。

個人的にはSpring Boot大好きです。
そんな中、今年もSpringの大規模なイベントがバルセロナで開催されました。
Spring I/O 2017 – 18-19 May, Barcelona

その報告会が六本木で行われました。行ってきたのでレポートや所感など書いていきます!
jsug.doorkeeper.jp

レポート

キーノート

  • Spring IO 2017年が6回目
    • 今年からチケットの入手が大変になった。
    • 43セッション
    • ReactiveやMicroserviceなどキーワードを絡めて幅広く技術要素が扱われた
  • 基調講演の内容
    • The Only Constant Is Change 唯一変わらないことは、変わり続けるということ
    • leon megginson 唯一生き残るのは変化できる者
    • 変化する世界の中有益で有り続けることだ。 @jessitron
    • J2EEのアンチテーゼからSpring Initializrへ
    • Thymeleafのシェアが圧倒的に多い

Spring 5.0 Reactive関連

  • http://lanyrd.com/2017/spring-io/
  • @Java Day Tokyo 2017のキーノート資料が参考になる
  • Reactiveのおさらい(誤解を恐れない表現)
    • blockしない処理の塊を細切れにする
    • エンジンは細切れ処理をいつでも実行可能なよう管理
  • Reactive Stream
    • JDK9に取り込まれる予定
    • back pressureにより合理的に処理を実行
  • MonoとFlux
    • ReactorにおけるPublisherの実装
    • Reactive StreamsをStream API風に記述できる
    • Monoは0/1個、Fluxは0個以上の値を発行可能
  • Spring5でのReactive
    • spring-webflux
    • MonoやFluxが使えるController的な
    • 無限ストリームの返却
      • 一定間隔毎にデータを作っていくような
      • SSEのStreamとして解釈される機能←いいねこれ!
  • Functional Framework
    • 関数スタイル記述によるフレームワーク
    • framework << library(明示的かつカスタムが容易)
    • spring-webflux向け限定
  • RouterFunctionとHandlerFunctionの組み合わせ
  • Router Function
    • URLやリクエスト内容に応じて、呼び出す処理の振り分けルールを定義
  • Handler Function
    • ルーターで条件にマッチした場合に呼び出される処理を定義
  • HandlerFilterFunction
  • 様々な選択肢があることが重要的な。
  • Spring DataのReactive対応
    • 2.0になる。Reactive対応する。
    • APIの破壊的変更も含まれる
    • 対応しているデータソースが限られる。JPAはNG
    • JDBCドライバがblockするので意味がない的な

ThymeleafのWebflux対応

www.slideshare.net

  • Getting Thymeleaf Ready for Spring 5 and Reactive
  • TemplateとResponseがBlockingになっているから
  • ResponseをPublisherに
  • FULLモード
    • HTMLを一括生成して一括出力
  • CHUNKED
    • HTMLを一定のバイト数毎に区切って生成
  • FULL/CHUNKEDの共通の課題
    • resolveAsyncAttributeのリスト変換をMonoにするので、待ちが発生する的な
  • DATA-DRIVENモード
    • wrapすることでresolutionを回避
    • ThymeleafがProcessorのように振る舞う
  • DATA-DRIVEN & SSE
    • DATA-DRIVENモードの場合はデータ1件ごとに部分的なHTMLをSSEで送信可能
  • まとめ
    • ReactiveなView出力
    • 見どころ満載のデモ

Spring I/O 2017 行ってみてわかったSpringBoot

www.slideshare.net

  • SpringBootApplication
    • 別のパッケージにあるクラスファイルを使いたい場合は@ComponentScan
    • @ConditionalOn
  • WebMvcTest, DataJpaTest, RestClientTest

Spring I/O 2017での拡張のお話

www.slideshare.net

  • Spring Cloud Function
    • lamdaみたいなもの。
    • SpringでFunctionを書いてサーバレスな環境を実行できる?
    • →話を聞いている限りだとLambdaで動かすSpringみたいな印象を受けましたが・・どうなの
  • Spring Auto REST Docsの拡張
    • Spring REST Docs テストを通った内容がドキュメント化される
    • つまり、正確なドキュメントが作れる

Re:ゼロから始めるオープンソース生活

www.slideshare.net

  • コントリビュートはソースコードの追加・修正だけではない
    • コミュニティ活動、不具合の報告、ドキュメント周り(整備、翻訳とか)
  • コントリビュータになるために
    • Gitの知識と、GitHubのお作法
    • 修正内容の議論、推敲、反映
    • CLA(ライセンス条項)への同意
    • 忍耐
  • spring.ioで情報収集
    • READMEとか読む、プロジェクトの好みを知る(Merge vs Rebase, Code Style)
    • 自分だけのForkの中で自由にコードをいじってみることが大事
  • よいPull Requestのために
    • Issueに自分が作業していることを明記
    • 簡潔明瞭のコミットメッセージ
    • 機能追加の場合は、単体テストも追加
    • ビルドが正しく完了することを確認
    • PR先のbranchを間違えないように確認
  • PRのライフサイクル
    • CLA -> CI -> PR議論 -> PR内容修正 ->反応なしの場合忍耐
    • リジェクトの場合もめげずに次がある!受理はおめでとう!
    • PRを上手に引き継ぐことが大事?
  • まとめ
    • 始めるなら今がチャンス
    • Spring5に向けて改善点がたくさんあるから

所感

ピザおいしかったです。ありがとうございました。

f:id:yasay:20170710131246j:plain
OSSに貢献するチャンスではあるようなんですが、
自分のやりたいことがまだ消化できていない状況なので、
片付いたら貢献したい気持ち。サーバレスアーキテクチャとかやってます。

あと、リアクティブに関する説明はとても分かりやすかったと思っています。
登壇者の方は"誤解を恐れないで"という言葉を使っていましたが、
私も"誤解を恐れないで"言うと昨年のSpring Day 2016当時の私よりは
今回の話を聞くことでそこそこ理解できレベルアップしたと思います(笑)。

リアクティブなフレームワークも一つの選択肢ということなんだと思っています。
個人的にはリアクティブなフレームワークが主流になるのかが気になっていますが、
主流になった時に学習できていないと追いついていないということになるので、
やはり継続的な学習とアウトプットが大事かと。

久しぶりの六本木は新鮮な気分になれました。また行くぞ!
以上です。