システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

【書評】りあクト! TypeScriptで始めるつらくないReact開発 第3版

oukayuka.booth.pm

oukayuka.booth.pm

oukayuka.booth.pm

総評

とても良かった
他の人にも勧められる書籍です
技術メンターになる人が周りにいない場合*1や、他のメンターの意見も聞いてみたい人にお勧めです
出版時点(2020/9)の最新動向まで書かれているので、一昔前のスタンダードを追いかけるのではなく、過去の経緯を踏まえて 今 こういう流れになっているというバックボーンの理解も深まります

はじめに

私のバックボーンなど

私はJavaのサーバーサイドのプログラマとして*2、家業の学習ソフトのリプレイス(MSXからブラウザベースへ)を8年前くらいに一人でやったという経歴です。
jQuery(&jQueryMobile)を使って、オレオレアーキテクトを考えて ゴリゴリとオブジェクト指向*3で作り込みつつ それなりに動くものを作りました。
サーバーサイドの見直し*4を含めて考え直している中で、クライアントアプリも技術素振りも兼ねて見直そうと思い立ちます。

あと、JavaScriptについては Node.jsでちょっとしたアプリを作ったことはあるという感じです。

技術選定(ReactかVue.jsか)

JavaScript名前空間でグローバルに扱うプログラムも慣れれば そういうものとして悪くは無いですし、動的型付けな面白さも悪くはないと思っています。
が、いかんせん年々記憶力も落ちており Javaのような型があると やっぱりうれしいのでTypeScriptは導入してみたいというモチベーションがありました*5

このあたりも見つつReactにしようと決定

完全に独断と偏見だけどReact vs Vue してみた - Qiita

書評(or 感想)

ようやく本題

JavaScriptの実装とTypeScriptの1冊目

jQueryを使いつつクラス志向の開発はしたことはあるので、ブラウザのちょっとした操作を実装したという経歴以上ではあると思いますが、独学ベースでツギハギでした。
内容としてはReactに直結はしなかったところが多かったかもしれませんが、私としては逆にラッキーでした。
あと他の本で「Create React Appを使わず、自分でwebpack 使っていきましょう(意訳)」とあったのですが、本書にて「webpack職人になれますか?(意訳)」とあり、「確かに 目的はアプリを作ることだから 本当に必要になるまではwebpackによる構築面はスルーしたほうが良いだろう」と踏みとどまれました*6

Reactの基本を学ぶ2冊目

Reactによる実装の基本とJSXとは、ということが学べます。
JSXの好き嫌いは 分からなくは無いですが、結局 動的に形成したものを見て確認するのだから、テンプレート型(Vue.js)であれ 似たようなことだと割り切っているので、私としては そもそも気になりませんでした*7
そもそもテンプレートをベースとした静的なページはJavaで実装して(している)、動的アプリ部分をJavaScriptで構築する(している)の前提ですし。

あと、具体的な開発に必要なツールを含めた開発環境構築に大きな割合を割いているのも、私にはよかったです。
Linterについては、過去の系譜といった ある種 豆知識的な技術選定の根拠を個人的には知りたいので*8、読み物として面白かったです。

Reactによる状態管理を学ぶ3冊目

よほど簡易なものでない限り、アプリケーションにおいて状態管理は必要です。
最新状況に至るまで、これまでのReactにおける状態管理の実装について丁寧に示されています。
読み手の状況(新規開発なのか、既存アプリのメンテナンスなのか)に応じて広く使える内容だと思います。
たとえば 現場によっては、Reduxを使ったり、Redux以前のやり方を使ったり、色々あると思います。
過去の系譜をなぞってコードベースで説明されているので、プロジェクトの実態に合っている部分が どこかしらにあると思います。個々の状況に応じて適用していけばいいでしょう。
私の場合は完全リプレイスを目指しているので 本書の示すオチをベースに、その他の要素を引き算して(遡って)、どこを落としどころを見極めれば良いという使い方ができます。 例えば著者の言うマイクロフロントなアプリを目的としていないし、現時点でテストツールが充実していそうな Redux&REST APIにしたほうが良いかな?という感じで適用範囲を考えられます。

読み方

正直なところ、はじめはコードも理解しつつ読むようにしていたのですが「おそらく この後で より良い変遷を示されるだろう」と思ってからは、コード部分については飛ばし気味で読みました。
上述もしましたが、それはその部分が無意味ということではなくて、個々の現場で それぞれのフェーズに遭遇した時に照らし合わせて読み込めば良いだろうという判断の下で そういう読み方に変えました。
その意味でも本書の守備範疇は広いように思います。

役に立つ

総じて、Reactを知る本ではなくて、Reactを使ってJavaScript(&TypeScript)によるアプリ開発をする本だったという印象です。
書籍のサンプルはGitHubでも公開されています。
書籍によっては、ツギハギな情報だけを示して、実際の全体像が分からないということもありますが、そういうこともありません。 実際に自分のローカルに落として動かしてみることができます*9

さいごに

一回読んだだけなので、まだまだ理解は浅いです。
また私は本を読むときには読むことに専念して手を動かすことを後回しにしています。 ですので再度読み返しをしつつ 手も動かそうと思います。
また、初見の感想を記録として残した上で、改めて本書の活用をしつつ 以下の書籍も購入してしたのでテスト周りのやり方もあわせて学ぼうかと思っています。

oukayuka.booth.pm

追記(2020/11/13)

「りあクト! TypeScriptで極める現場のReact開発」読了

おすすめは 6章「プロフェッショナル React の流儀」
開発プロセスへの言及がとても良かったです。

先の書籍を購入された方は、この書籍を「締め」に読むと良いと思います。 開発プロセスについては、個人的には スッとなじめました。
こちらのサンプルの基本構成をベースに開発すれば、個人開発でも ツギハギではない 一気通貫した思想の下で開発ができる手ごたえのようなものを感じました。

繰り返しになりますが、せっかく先の3冊を読んだのであれば この本も必ず読んでほしいと思える本です。

追々記

書籍のサンプルにあわせて、Sagaで状態遷移を考えていたけれど以下のコメントをいただきました。

ということで サンプルを自分なりにアレンジして 理解を深めつつ あれこれやってみる余地もありそうです。
あれこれすることも含めて「技術素振り」の範疇だと思っていますし、この書籍があったお陰で「技術調査および自分にあっているスタイルの検討」の手探りの時間を 大幅にショートカットできたと思っています。

追々々記(2021/1/4)

「りあクト! TypeScriptで極める現場のReact開発」ではStorybookのバージョンが5系であるため追記時点の6系とは推奨される書き方やaddonが違います。
目的と役割については流用できますが、実装については独自に調べる必要があります。


*1:私は主にこれです

*2:厳密には現役SIer時代はPLでプログラマでもない。退職してからプログラミングした人。

*3:クラス志向な部品を作ったり、継承も使ったり云々

*4:Javaのバージョンアップとか TomcatからPayaraへの乗り換えとか

*5:そのためにオレオレアーキテクトで部品作ったりもしましたが、、まぁ当初の思惑は作っているときには それなりに覚えていますが、数カ月もたつと、、という良くある話

*6:悪い意味で、私は 本当にやりたいことがなかなか進められない性格なので、立ち止まれたことは多分 良いことだと思っています。この反省の下 Payaraを使おうと考え直したわけですし

*7:ふむふむ、こうやって画面構築するんですね、くらいの温度感

*8:気になるという言い方でも良いですが

*9:まだ動かしていないんですけどね(汗)

使用しているのに未使用と言われてしまったimport

はじめに

解決

事象

移行前

f:id:vermeer-1977:20200903212833p:plain

移行後

f:id:vermeer-1977:20200903214205p:plain

対処

f:id:vermeer-1977:20200904090903p:plain

ユーザーがインストールしたプラグインのところに「nb-javac」というものがありました。 非アクティブだと解決しなかったのですが、アンインストールして立ち上げなおすと、事象は解消しました!

ただ、日本語化プラグインは欲しいので 改めて日本語化プラグインを入れなおすと、再び nb-javacが復活を繰り返して 再発。。
立ち上げなおしたり、nb-javacを自分で入れなおしたり、なんやかんやしてたら上記の状態に!

f:id:vermeer-1977:20200904091257p:plain

通知にnb-javac インストールしてください的なものが見えるのですが当面は保留にしておきます。

謝辞

twitterで助けていただきました。
ありがとうございました。

さいごに

ユーザーがインストールしたプラグインを個別にアンインストールする方法がわからず。。 「ダウンロード済み」リストに並ぶものかな?と思っていたりもしましたが空っぽ。
今回のようなこともあると思うので、ダウンロードして適用したプラグインは 一か所にまとめておこうと思った次第です。

【雑記】新しいPCを購入(OMEN)

はじめに

数年ぶりに新しくPCを購入。 少額固定資産(30万)以下にしようと思って見つけたのが こちら

OMEN Laptop - 15-dh1004tx

キャンペーン価格で30万以下(税込)でした。
ゲーミングPCです。
機械学習試したくなったら(今は無いけど)、GPUとかも気になるだろうし、持ち歩きしないけど ノートパソコンしておきたいなぁなど考えたら ここに落ち着きました。

再セットアップをするときに必要な情報リンク集的な感じでの まとめ*1

使い心地

当然、サクサク動いてくれます。

やったこと(やっていること)

VirtualBoxでLubuntuを使う

なぜ?Linux

開発環境をUbuntuベースにしようと思ったから。
今の仕事で初めてMacを仕事で使いました。
これまでWindowsでの開発で困ったことがなかったので、いずれやろうかなぁと思っていたLinuxへの開発環境の移行を先送りしていたのですが「それなりにできそうかも」と思えるキッカケになりました。
Macよりも、キー割り当てが近いのでUbuntuに。

なぜ?Lubuntu

以前から、軽量Ubuntuとして少し触ったことがあったから。

なぜ?VMで開発

今回のPC移行をするにあたって、開発環境の移行がなんやかんや言っても地味に面倒さを感じたから。
環境が壊れた時を見越してバックアップするにしてもVMにしておくのは良いだろうと。

VirtualBoxデビュー

厳密には、多少は使ったことはあるけれど、手順書作成でローカルにLubuntu入れて画面キャプチャとったりとかピンポイントな利用。
PCスペック的に厳しくて、サクサクとまでもいかず、最低限の活用で終わってました。

図解! Oracle VirtualBoxが重い/遅いときの対処方法 | 仮想マシンソフト
VirtualBoxのVDIサイズを縮小する - Ragnite Blue
VirtualBoxの共有フォルダの自動マウント | K'zlog

Java11デビュー

とりあえず思考停止で「AdoptOpenJdk」の 8 と 11 を入れました。
https://adoptopenjdk.net/

JVMも思考停止で、HotSpot

ubuntu — UbuntuでJava環境のパスを設定する方法

Netbeans12デビュー

NetBeans8系を使っていましたが、ようやくバージョンアップ。

Downloading Apache NetBeans 12.0

日本語化は、こちらから
NetBeans 11.1のリリースと日本語化 | junichi11.com

新機能は日本語化されないとのことですが、そもそも基本機能くらいしか使っていないので全く問題なくイイ感じです。

Eclipseの導入(断念)

EclipseはAmaterasERDのために使っています*2

導入で参考にさせていただいたページ
Eclipse(2019年12月版)のインストール,日本語化,基本操作(Ubuntu 上)

AmaterasERD
AmaterasERD - Project Amateras

とりあえず起動するところまでは確認。 以前作成したものの編集などの確認はこれからという感じ

表示されない(Windows版ではできたと聞いたけど、Linux版ではうまくいかず。。断念)

Payara5の導入

Back to Basics - Payara ServerをUbuntuにインストールする

よかったこと

やりなおしがやりやすい

環境設定周りは、よく分かっていないとか、Typoとか、viに慣れていないとか、とにかくトラブルが多いものです。
以前*3は物理PCにOSを再インストールを良くしていたものですが、壊しやすい(?)ので気楽なものです。
それなりに構築できたかな?というタイミングでフリーズしてしまった後で「スナップショット」を作ったら良かったという後の祭りもありましたが、その辺りも含めて「色々やってみて気が付く」のは、良いことです。

Lubuntuでも特に違和感は無さそう

少しだけコードを触ってみた感じですが、キー操作がWindowsに類似なので問題なさそうです。
「ctl+space」がNetBeansの入力補完のとmozcの日本語モードで被っていたので変更したくらいでしょうか。
これから、色々と感じることもあるカモですが、とりあえず初見としては問題ないですね。

サクサク

PCスペック様様なのですが、メモリが32Gあるし、CPUもよい感じなので、以前のPCでVMを使った時とは比べ物にならないくらいサクサクです。 *4
自分が操作をしているのがVM側ではないと錯覚するくらいにサクサクです。

Java11への道のり

バージョン上げて、既存のプロジェクトをビルドしたら エラー。
まずはスタートラインへ立ったという感じです。

さいごに

キーボードのLEDはオフにしています


*1:なので、順次追記する想定

*2:へっぽこなのでGUIからDDLを作りたい

*3:20年近く昔

*4:理解していなかっただけで以前のPCでも、それなりに能力を引き出せたのかもしれないのですが

Reactのメモ

公式

チュートリアル:React の導入 – React

Redux Toolkit | Redux Toolkit

useEffect完全ガイド — Overreacted

状態管理

比較考察

React ステート管理 比較考察 - uhyo/blog

Recoil

React 新しい状態管理ライブラリ Recoil の紹介

Context API

ベストな手法は? Reactのステート管理方法まとめ - ICS MEDIA

Redux

TypeScriptでReactをやるときは、小さいアプリでもReduxを最初から使ってもいいかもねというお話 | フューチャー技術ブログ

Redux Toolkit で React.js の状態管理をもっと簡単にする方法[TypeScript版] | webOpixel

HookとRedux ToolkitでReact Reduxに入門する | Hypertext Candy

React-Query

Overview | React Query | TanStack

React Query 101 - DEV Community

ReactQueryでキャッシュを最大限利用する | microCMSブログ

REST API なら React Query がファーストチョイス

React Queryのkey管理について

URL操作

クエリパラメタをReactコンポーネントに渡すときはreact-routerが便利 - Qiita

[React Router] URLクエリストリングを取得する

etc

https://www.learnstorybook.com/intro-to-storybook/react/ja/get-started/

Material-UI を普通に使うと Storyshots がうまく使えない ++ Gaji-Laboブログ

第9回 2020年版 ReactにStoryshotsを導入する - Qiita

reactjs — onKeyDownイベントがReactのdivで機能しない

React今昔物語 - ICS MEDIA

React 触り始め、よく遭遇する問題まとめ(個人的に) - 奇をてらったテクノロジー

React / Redux を実務で使うということは
(画面描画のタイミング制御など効率的なReactでの制御を細かく書いているブログ)

Reactのデザインパターン Compound Components - Qiita

Compound React Components with Hooks + TypeScript | Martin's Blog

[redux] Presentational / Container componentの分離 - react-redux.connect()のつかいかた - Qiita
(Reduxの話ではあるけれど「Provider直下のコンポーネントはPresentational componentであるのがよいらしい」らしい)

TECHSCORE|React: そのrender()はいつ呼ばれるのか | TECHSCORE BLOG

How to get previous props/state with React Hooks - LogRocket Blog

React.memoをサンプルを使って解説 - エンジニアの本棚

フックに関するよくある質問 – React

React.memo / useCallback / useMemo の使い方、使い所を理解してパフォーマンス最適化をする - Qiita

React の Context の更新による不要な再レンダリングを防ぐ 〜useContext を利用した時に発生する不要な再レンダリングを防ぐ方法に関して〜 - Qiita

React hooksこんな風に使ってみたよ - Qiita

DecoratorsでReactコンポーネントを拡張する - Qiita

React Hooks の useEffect の正しい使い方 - Qiita

React ContextでuseReducerを使ってみる - Qiita

React.ts の状態管理に useContext を使う - Qiita

VSCodeのTypeScriptのバージョンを変更する - 新しいことにはウェルカム

ReactContext用のLoggerを作った - Qiita

知っていると捗るcreate-react-appの設定 - Qiita

Uncontrolled Components でシンプル且つ高パフォーマンスなフォームの実装 - React Hook Form - Qiita

CssInJsPerf/App.tsx at 76b8b0172a4f9b938e099a7c2906d6e63ae8d831 · GiridharKarnik/CssInJsPerf · GitHub

2020 年、 React 軸で学ぶべき技術 - mizchi's blog

reactjs - React.js/Redux: setInterval and clearInterval in Reducers - Stack Overflow

Reactで実装したコンポーネントのマウント時に工夫したこと - EatSmartシステム部ブログ

ヌルヌル動くReactコンポーネントの作り方【入門】 - カミナシ開発者ブログ

React Hooks: 子コンポーネントから親の状態をレンダー時に変えたら叱られた ー Warning: Cannot update a component while rendering a different component - Qiita

React Hooksでデータを取得する方法 - Qiita

Build

Create React Appで作成したアプリを任意のサブディレクトリに配置する | NO MORE! 車輪の再発明

Deployment | Create React App

React開発時には、APIサーバーとReactアプリサーバーを別にして、プロキシを使うというベスト・プラクティス

Reactで実装したコンポーネントのマウント時に工夫したこと - EatSmartシステム部ブログ

リポジトリ

yarn workspaceでmonorepo+TypeScript+Lint環境をつくる - Qiita

Multi-root Workspacesで、React monorepoプロジェクトのautoimportをいい感じに動作するようにする - BASEプロダクトチームブログ

yarn workspaceでtsconfig.jsonを共通化したモノレポを作りたい - Qiita

TypsScript

さようなら、TypeScript enum | Kabuku Developers Blog

【TypeScript】 Object[key]() (ブラケット記法)で関数呼び出ししたら Element implicitly has an 'any' type でハマった話 - Qiita

Typescript ブラケット記法(Object[key])でno index signatureエラーをtype safeに解決したい。 - aknow2

https://cloud6.net/so/typescript/1499504

デザイン/Storybook

画面を作る | Storybook Tutorials

rebassのComponentをStorybookのStoryに追加する際のひと手間 - Qiita

Rebass

Solarized

The `sx` Prop – Theme UI

https://microcms.io/blog/storybook-react-use/

React×TypeScriptでStorybookを5.1.9から6.0.26にメジャーアップデートしたハマりどころ

Vue と CSF によるモダンな Storybook 6 のはじめかた

Next.js + TypeScriptにStorybookを導入して遭遇したエラーを全て共有します - パンダのプログラミングブログ

デザイナーがデザインツールを使わずに、Reactを使ってデザインした話 - Medley Developer Blog

Next.js + TypeScriptにStorybookを導入して遭遇したエラーを全て共有します - パンダのプログラミングブログ

@storybook/addon-storyshots - npm

Next.js+TypeScript 環境で Storyshots を使う(Storybook 6 対応) ++ Gaji-Laboブログ

react-icons - npm

javascript - Rerender view on browser resize with React - Stack Overflow

vue.js - How to mock modules in storybook's stories? - Stack Overflow

How to mock api calls in Storybook - DEV Community

Using Storybook and Mock Service Worker for mocked API responses - LogRocket Blog

クリーンなReactプロジェクトの21のベストプラクティス - Qiita

Suspense

React Suspense in Practice | CSS-Tricks

ReactのSuspenseで非同期処理を乗りこなす

React Suspense と Hooks を同時に使う方法について - Qiita

Use React.Suspense to wait for an image to load - Sergio Xalambrí

その他

超楽しくてカッコいい、Reactで始めるThree.js入門 - Qiita

[React Hooks] useAudioなるカスタムフックをつくってみた - Qiita

【React】HTML5のaudio要素で音楽を順番に再生する - Qiita

Custom audio player with React hooks - CodeSandbox

Scrolling with Page Up/Down Keys in React-Window

React DnDでかんばんボードを作ってみる

WEB色見本 原色大辞典 - HTMLカラーコード

Single Element CSS Spinners

ReactでOverlay Spinner Componentを作る - Qiita

JSON Server*1

github.com

フロント開発で使うAPIモック - JSON Server - やのうの記録

【React】フックとjson-serverをFetch APIで連携(Reactライフサイクルの理解) - クモのようにコツコツと

json-serverを使って簡単にAPIをmockする - Qiita

*1:Reactとは違うけど、実装時に関係あったという事で

Developers Summit 2020 に参加してきました

event.shoeisha.jp

に参加したので感想などを…
その場で残したメモに多少手直ししたくらいのものなので、登壇者の発言もあれば、自分の感想もある ごった煮です。

資料まとめ

デブサミ2020、講演関連資料まとめ:CodeZine(コードジン)

感想など

13-D-1:LINEがプライベートクラウドを選ぶ理由

  • 聴講のモチベーションは 最近プライベートクラウド(k8s)のシステムに少し関わっているから
  • プラットフォームチームからのアプリチームへの関わり方についてのヒントがあれこれ
  • Verda(ベルーダ)っていうのは基盤の名前ってことで良いんだよね?*1
  • 基盤利用の在り方はチームメンバーをリーダーが管理するのと、スクラムによるチームで違いがあって良い
    前者はベンダー集合体のようなチーム編成、後者は同じ会社メンバーであったりエンジニア以外で編成されたチームに、みたいに適材適所がある
    前者は管理者にロールアドミニを持たせて権限管理しっかり(いろんな人がいるからね)、後者はメンバー一人一人に権限付与の権限を渡している(全員で1つの仕事をするからね)
  • 間違いは起きる前提のPFにしている
    たとえばDNS登録時に レビューではなく仕組みでチェックする
  • 「なぜプライベートクラウド?パブリックで良いんじゃないの?」
    Yesではあるけれど、クラウド管理者と開発時点で相談をしてベストアンサーを把握してから開発をする
    プライベートクラウドの場合、新機能への調査をして適用させる
    プライベートだとPFチームは開発するサービスに意識が向く。パブリッククラウドの利用だと「使い方」に意識が向く。
    アドバンテージはPFチームのマインド
  • OSS活動(OpenStack)について
    VM53000、ベアメタル3万の規模
    スケールとハイパフォーマンスに関するコミットが多い
    MQはRabbitMQを使っている

13-B-2:モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏

  • 購買に関わるコストを下げることが使命
  • 1800SKU
  • データマーケティングが成長の牽引
  • 業界用語での検索も出来る(この辺りの工夫は面白いと思った)
    それを仕組み化している(人力では不可能)

  • データの集約して分析をしやすく

  • データにIDをつけるなどもして一意性を追加で付与
  • データの集約先はBigQueryにした。GCP使っているし協力なスケーラビリティ
  • CDCによる安定したデータ連携
  • 変更イベントをトリガーにしてBigQueyへ。変更から連携完了までは1分を目処に
  • アーキテクチャリングのポイントはデータのリアルタイム性
  • DBをHUBのように使うとスケーラビリティが悪くなる
    MySQLへのストアを中心としたアーキテクトだから、という前提での話
    (DB中心は 割とあった仕組みだと思うけど、今だったらメッセージ駆動な感じにするんだろうな。顧客価値へ直結しないというと言い過ぎかもしれないけど、多少の欠落があったとしても価値の減損が限定的な場合は結果整合性(もしくは整合性すら多少目をつぶっても)で良いと思う。)

  • マイクロサービス化の目的はデータ活用(再掲)

13-D-3:サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話

  • 長いタイトル
  • 決済システム(PCI DSS対応)にはグローバルな「仕様」があって それを守らないといけない
  • パスワードの変更サイクル(90日)とかも、その範疇(なので 現在では意味が無いと言われている仕様であったも 対応しないといけない。へぇー)
  • コンテナをReadOnlyで使うことでインスタンスを使わないので侵入不可な仕組みしてしまおう(発想が面白い
  • 開発チームはPM、開発、デザイナー含めて10名以下(だったと思う。メモに残せていなかったけど、いずれにしても決済の仕組みと考えると びっくりするレベルの小部隊という印象
  • クレジットカードを共有ウォレットとして使えるサービスも。今は招待制(このあたり、かつてのmixiっぽい?

13-A-4:我々はZOZOTOWNクラウドジャーニーを通じて何を学んだのか?

  • 川崎さんってMSの人では?と思っていたら やっぱりそうだった
  • ピーク、オフピークの差が激しい
  • スケールへの影響が大きく複雑性の低いバックエンドからリプレース
  • ストアドコールからAPIAKSベース)に更改、」しかも参照系から
  • 「アプリケーション回復性パターン」
  • クラウドリソースを過信してはいけない。大量リソースが必要なことが予測できている場合は事前にクラウドベンダーに相談をすること
  • キャッシュが100%に張り付いたときにアプリの挙動が想定外にレスポンスが返ってこなかった(対策はとっているつもりだったけど結果としては十分ではなかった)
  • クラウドは安くはない、従量課金モデルは長期的には高い
    だからクラウドはやめましょうではなくて、短期的な課金だけで判断するものではないということ
  • 話は クラウド対応の教科書的な事例と言っても良いことばかりだったけど、それを実体験を通じて得た言葉として意味はあったと思うし、Azureの有識者であろう人が実感として発信していることに意味があると思う。

13-A-5:楽天モノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇

  • 元の構成:Iaasベースで永続化は物理ディスク
  • Azureベースにリプレース
  • CDNをAzureの外に出したのは課金が問題だったから(確かにクラウドの中に配置するとコンテンツ配信都度 従量課金される
  • AzureMySQLはHW障害により予告無しに中断する
    ミッションクリティカルには使えないが、72時間前にメンテナンス通知を送るように対応中
  • DBの可用性を考えるならMessagingの活用も視野に入れると良いだろう
  • マイクロサービスにした理由は利用するメソッド(GET)以外はリクエストが少ないということがあった
  • URL単位でデプロイする仕組みにしたら対応範囲が局所化できる(ので、メソッド単位でPodを作っている
  • コンパクトなので起動が早い
  • Helm2を使っている
  • Kiali、ネットワーク監視で繋がりが分かる
  • Jeager、ElasticAPMで観察
  • Vitessは MySQLのCNCF
  • Natsは メッセージングKafkaより楽
  • OpenTelemetory(+Jeager
  • Chaos Toolkit(でも殺すAPIがなかなかいい感じに選定できないところもある)

14-E-1:AWS障害で考えさせられた、アプリケーションインフラ構成の注意ポイント

  • サーバーワークスはAWS専業
  • 登壇者は元万引きGメン、今AWSに関わって2年くらい
  • 20190823 東京リージョンが障害で発生したアレコレ
  • 複数アベイラビリティゾーン冗長化はしていた
  • サービスについては影響はほぼなかった
  • 設定ミス:DBインスタンスのエンドポイントがミス
    アプリを変えずにDNSの設定で宛先を変えて対処
  • 設定ミス:ディスクマウントがされなかった(これは構成ミスの話)
  • ここまでは早急に対応できた。逆に言うと次は重い
  • プレイスメントグループ
  • 気がついたこと
    バックアップがとれる仕組みを考えるべきだった(書き込みのないタイミングで取得しておくなど)
  • 今後どうすれば良いのか
    基本を大事に(ビジネス要件の確認)
    重要度が低いのに過度な構成はとらないように(逆は逆)
    Snapshotをとるべし
  • EC2へのスクリプトの置場所はEC2以外へ(同じレイヤーだと同じことが起きるかもしれない)
  • 接続先にIPアドレス指定はNG。エンドポイントを指定しましょう。
  • テストとしても切り替え試験の実施をすること
  • 言われてみれば当たり前のことかもしれないけど、実際のところ ちゃんとやるのは別もの。私はアプリケーション側なので「やってもらっている領域」なので こういうのは知っておくだけでも大事だと改めて思った。

14-D-2:エンプラアジャイル導入の守破離

  • チームの規模と何を作るのかはtradeoffになる
  • 教育をしているとものが作れないというジレンマであり難しさ
  • イテレーションでやっているけどスコープの決まっているものをやっているだけ
  • チームがうまくできるイメージができない範囲には適用しない(トップダウンで決めるとうまくいかなくなる)
  • 価値を産み出すまでのリードタイムを短くすることを優先する(成果物よりも)
  • 「おとなりさんと」で集中力が切れた。運よく会話をさせていただいた方からは良い視点を得られるところはあったけれど、それを目的とするのであれば それをメインとしたワークショップでやって欲しいというのが個人的な意見。ここまでの話は面白かったし興味深く聞いていただけに非常に残念な気持ちになった。
  • (以降、偏った意見になりそうなので割愛*2

14-B-3:K8S使ってますか?リテールテック(小売・決済等)でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ!

  • RANCHERの話
  • natadeCOCOの話
    その場でしか接続できないWifiに繋げてサービスを提供するアプリ(QRコードで情報を渡す)
    面白い仕組みだとは思ったけれど 勝手にWifiにつながることの安全性とか 気になったりもした。
  • 「2025年の崖」への言及は?

14-D-4:日本にJoy,Incを創る!どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡

  • 「あなたのチームは機能していますか」
  • 2013年:30人しかいないのにいがみ合っていた、プロジェクトは大炎上(夜中1時に顧客と打ち合わせ)
    原因:経営者(自分)目先の売り上げしか見えていなかった
    メンバーも何が正しいのか分からない状態
  • 毎月最終金曜日に社内懇親会(17時から19時)マンネリ化して終わる
    →目的を明確化しないと伝わらない
  • 月曜日、進捗会議。目的は情報共有のつもりだった。でも、月曜日からしんどい場になっただけだった。ので、社長として訴えかける場に変えた。でも、から滑り。でも続けた。徐々にメンバーの中で響く人も出てきた。そこでくじけず続けるのが大事だと学んだ
  • ヴァル研究所へ見学。巻き込み方が大事。ときには強引でも その場につれていく(僕が客に謝って時間を作るから、みたいな)
  • 「強いチームの作り方」ワークショップ
  • ペアワーク1週間でローテーション(これはJOY.incの話)
  • 語弊を恐れずに言うならば、エモい系の話だろうと思ったので一番期待していなかった*3
    たしかに「良くあるエモい系」な感じはあったけれど、なんだろう そういうのも ひっくるめて 面白かった。他人が勝手に言うことではないけれど、会社を大きくするよりも 自分の手に余る範囲でのJOY Incの実践に留めて、拡張するのではなく 他の組織へのJOY.Inc に波及、連携するのが良いように思う*4

14-D-5:マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと

  • 直近でNode.jsでProxyをアレコレというのをやっていたので、NGINXに興味を持ったので聴講
  • 「分散システムデザインパターン」を丁度 読んでいるところだったので 色々とリンクができて面白かった
  • 具体的な記述例の話もあったので、スライド公開を強く期待(2020.2.15時点では

14-A-6:世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた

  • JJUG 元会長の鈴木さんの最近の活動を具体的に聞ける場ということで聴講
  • アイムデジタルラボ 三越の子会社(といっていいんだよね?)
  • YourFIT365
  • 新宿伊勢丹の婦人靴
  • 立ち上げまでに2年かけた
  • POは現場メンバーにする「べき」
  • 今回だと「売り場」の人
  • 直接やり取りをさせてもらうことが条件
  • リリース日は決まっていた
  • 1ヶ月 ワークショップでリーンキャンバスとカスタマージャーニーをつくった
  • はじめは7社が木型を提供してくれた(これは これまでの信用力)
  • 「何を作りたいか」を全員が共有するために費やした
  • サービスブループリント を使った
  • 業務フローとシステム構成を平行して考えて検証
  • 計測からリコメンドのタイムラグをどのように埋めるのかというところまで「業務設計」をした
  • メンバーはアジャイルを知らない人も。2ヶ月トレーニング、開発3ヶ月
  • リリース後はフィードバックとの戦い
  • 接客には1名に1~2時間かかる
  • 木型をベースにしたから再来客への訴求力が強く具体的である
  • 立ち上げ期のあとに意図的に安定期を作り込んで振り替えりをする余裕ももうけた
  • 当事者にならない人は不要=企画部門問題(アイディアだけの人はいらない)
  • 島型:適度な自治権 が大事
    距離感:既存に影響されてスピードが出ない
    島型:既存から切り離されて過ぎて成果が出ない
  • デジタルで新しいことはみんなやりたいけど、組織が枠組みとなって難しいことがある=組織を別にもうけてそこで実践する
  • 統制から学習がIT部門に必要
  • 結局のところ、きちんとしたモノづくりには 全員が当事者になることが大事だという当たり前といえば当たり前の話だと実感。アジャイルとかWF(といわれている かつての開発)とか、そういうことじゃないと個人的には思った。
  • 泥臭く 土方仕事な感じのシステム開発かもしれないけれど、ユーザー総出で開発していた時代があって*5、そこで培った成功のプロセスがあったとして 結局 その「型」だけを採用すればイイ感じになると思って波及したんだけど、そこに本質はなくて 一番大事なのは「そんなアナログ」な部分だったというだけの気がしてならない。

14-B-7:エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話

  • 巨大メモリサーバーで何をする? なにかやってみたいことがあったら教えて欲しい
  • データの70%はデータセンターの外側にいる
  • ハードウェアアタックが増えるでしょう(by FBI 2017)
  • パンツダウン:センター監視サーバーを暴いて丸裸にすること
  • サプライチェーンへのリスクが増大
  • IPAの報告でも4位
  • 元は防衛設備で話題になっていたところ
  • 昔はメーカーの孫請がなくなることのリスクをいっていたけれど、今は部品に仕組まれたステルス攻撃のこと
  • サイバーディフェンス(手島裕太)に依頼
    ソフトはダメでもハードから攻撃はできるかもということで受けてくれた
  • ファームウェアを攻撃対象としてもらった
  • 改竄されることは想定内
  • アンチウィルスソフトはOS上のソフトを見るだけなのでファームウェアは対象外
  • エアバスのエンジニアにホワイトハッカーがいる(GitHUBにも公開)
  • 一番始めに攻撃されたのはHDDのファームウェアで、隠した領域に情報をためておいて廃棄時に回収するという仕組み
  • ハードウェアにもゼロトラストの構想が必要になってきた(チェーンオブトラスト、RootOfTrust)
  • 電源のファームすら危険性があるという世界(電源を止められたらセンター停止)
  • HPEマイクロサーバーからマイクロサーバー新作が出る(本当は登壇日にリリースされる予定だったけど、ずれてしまった
  • ハードの話は「すげー」とバカみたいな感想しか言えないけど、やっぱり「すげー」と思うし 実際「すげー」と思う。

14-F-8:家族型ロボット「LOVOT」から考えるテクノロジーの裏側とその未来

  • 100億投資、100人の会社
  • 人間の力を引き出すことが目標
  • 愛されるよりも、愛した方が力が出るという想定(信念)
  • 監視カメラか 信頼関係のあるロボットの視線か
  • 存在感のある か 存在感が価値 になるか どちらかに振り切らないと難しい。中間はない(冷蔵庫に愛情を感じるとかいうのは難しい)
  • LOVOTはROBOTに対するカテゴリーという思想も含めた名前
  • 目指すところは ドラえもん
  • 先輩は犬、猫、イルカのような存在
  • 話せることと癒しは直結しない
  • むしろ話せないことが、想像力で補完している自分の言葉に癒されているとも言える
  • ではペットを飼えば良い?
    でも実際には飼いたくても飼えないというのが実態
  • でもロボットペット開発はすぐには廃れてしまったのがこれまで。
    それは「飽き」が原因では?
    ドーパミン(好奇心)が失くなった?Noでは?オキシトシン(愛着)が必要なのでは?
  • いるのが自然な状態ということ
  • 次に「ロボットネイティブ」な時代になると考えている
  • 人と人のコミュニケーションの延長としての存在
  • 広い意味での生物の境界はなく、生物と無生物の差がなくなると想像する
  • 「Detroit: Become Human」は 林さんのいう 中間 になる話なのかなと思ったりも。そして その中間 を求めて出来るのは 都合の良い奴隷であって 愛情を共有することに葛藤のある世界(出来る人もいれば、嫌悪を感じたり、隷属を求める ことになるとか)になるのかも、と思ったりも。そのためのセーフティーとして きちんと振り切ることは大切なことなのかもしれないと思った。

さいごに

去年も参加したけど、今年の方が 私には面白かった。
なんでだろう?

*1:調べてみたら、そのようでした。LINE Engineer Insights vol.4「OpenStackベースのPrivate cloud "Verda" の野望」 - LINE ENGINEERING

*2:今 思い出しても イライラしてしまう。。自分の狭量さも含めて

*3:多分、他が満員だったから みたいな理由で選んだ気がする

*4:自分の言葉でツラツラと説明はできるけど、ブログの範疇ではないと思うので割愛

*5:例えばJRのマルスの話(by プロジェクトX)とかね

Jakarta EEのメモ

www.slideshare.net

www.slideshare.net

エンタープライズJavaの未来に注目集まる!JJUGナイトセミナー「Jakarta EE特集」に参加しました - Seeing is believing

補足

Jave EEのメモ vermeer.hatenablog.jp

JJUG x JJBUG共催ナイトセミナー「cloud native business automation for Java」に参加してきました

jjug.doorkeeper.jp

スライド

speakerdeck.com

感想

どういう 話が聞けたというのは 英語だったこともあって&雰囲気で理解した感じなので 聞きながら思ったことなどをツラツラと。

  • Drools はルールエンジンで Ruleって「何をするか」ということ
  • 大事なのは利用者と開発者のコミュニケーションロスを失くすこと
  • Business and infrastructural code have very difficult life cycles
  • jBPM こっちは「プロセス」を描く
  • RuleとBPMを まとめて提供するのが Kogito
  • Kogitoの読み方は「こじと」(こぎと ではない)
  • (感想)ファンクショナルなアプリでいけるんだったら、ルールを書き換えて動的に反映するというのの価値ってどこくらい見いだせるのだろう?
  • (感想)逆にみいだせるとしたらOpenJDKでしっかり動くアプリこそ強いのでは?
  • とはいえ Kogito自体は Quarkus と SpringBoot を対象としたマイクロサービス向けなもので EEは対象外
  • (感想)ルールエンジンを適用するとユースケース駆動になるから ビジネスルールのロジック部分は部品に出来るけどできるけど、データ部分は外に出ているからクラスではないんだよね。
  • (感想)「判断」の見える化に止めるか ステートパターンの生成器としての役割まで担えるか?

懇親会で得られたプラスアルファ

  • BPMの拡張がVS Codeにあるから、BPMを業務フローの整理として使うだけでも使えそう
  • 少ない条件分岐だったらプログラムで実装した方が速いこともあるけど、大量の条件分岐を扱うのであれば 最適化が図られたDroolsに軍配ある*1
  • ビジネスルールの見える化は表面的なルールエンジンの能力で、大量のパターンマッチングがルールエンジンの強み
  • DroolsGUIのフローでロジックを書くことも出来るし、Excelでも書ける。結局 それをDRL(Drools Rule Language)に変換してルールエンジンが実行する
  • DRLから作られたエクセルへの可逆性は無いので、フローで作ったものをDRLに変換してからExcelのベースに使うというのは出来ない
  • ルールエンジンの需要はあるとのこと(自分の周りでは聞かないけど、決して「懐かしい」ものではなくて十分現役)
  • 機械学習(パターンマッチング)まで含めると、むしろ需要は 増える?
  • 機械学習(画像解析)と違うので必要なのはCPU

さいごに

ルールエンジンには Excelで書いた設計からXMLを変換するツール作成に関わったこともあって その面白さというか 業務の見える化みたいなところは興味深いと改めて思った。所謂 自動生成的なところがあるので かつてあれこれ考えたように*2、その付き合い方みたいなところの落としどころに検討の余地ありとは思っているけれど。とはいえ、今 自分手元にある開発資産は マスタメンテレベルのCRUD的なものなので DDDとかの文脈に出てくる「ドメイン知識」的な要素はないんですよね。何かしらの業務アプリ的なもののOSSを自分の思ったようにリプレイスしたりしながら アレコレやっていくと 何か良さげな整理が出来るかもしれないとは思いつつ、他に作りたいものとかあったりで 結局 後回しにしてしまうんだろうな。。

*1:私がかつて関わったルールエンジンはXMLで定義されていてパスで見るから そういった最適化はされていなかったんじゃなかろうか?

*2:http://vermeer.hatenablog.jp/entry/2018/07/07/102839