30億のデバイスで走るHonMarkHunt

JavaとJavaScriptと恐竜の絶滅について書いていきます。

【読書メモ】Scala関数型デザイン&プログラミング 1章 関数型プログラムの基礎

概要

Scala関数型プログラミングを学ぶ本。 関数型と聞くと「ウ"ッ」っとなるプログラマーだが、会社で輪読会のお誘いがあったのと、対象読者が「Javaばっかしやってた人」だったのでなんかできそうだなと思い読んでみことにした。継続的にkotlinをやっているのでScalaで関数型を学べるならこれ幸い。という気持ちもあった。

今回は、1章:関数型プログラムの基礎 のまとめ。

隔週で輪読会をやっているので(可能であれば)毎回ブログにまとめていく

TL;DR

式eがあり、すべてのプログラムpにおいて、pの意味に影響を与えることなく、p内のすべてのeをeの評価結果と置き換えることができるとしたら、eは参照透過です。関数fがあり、式f(x)が参照透過なすべてのxに対して参照透過であるとしたら、fは純粋関数です。

1. 副作用とは

  • 関数型プログラミング -> 純粋関数だけを使ってプログラムを構築すること
  • 純粋関数 -> 副作用のない関数のこと
  • 副作用 -> 単に結果を返すこと意外に何かする関数

副作用の例

  • 変数を変更する
  • データ構造を直接変更する
  • オブジェクトのフィールドを設定する
  • 例外をスローする、またはエラーで停止する
  • コンソールに出力する、またはユーザー入力を読み取る
  • ファイルを読み取る、またはファイルに書き込む
  • 画面上ここに脚注を書きます))描画する

副作用を持つコードの例

副作用

2. 副作用の排除

  • buyCoffeeの際にトランザクションを発生させたくない
    • テスタビリティー
    • 再利用性
  • Chargeを返すように修正
  • n杯のCoffeeの購入に対応したbuyCoffeesを作成
  • ワンライナーでまとめられるよ!

副作用排除

3. 参照透過性

  • どのようなプログラムにおいても、プログラムの意味を書き換えることなく式をその結果に置き換えることができる
  • intToString(5) の結果を呼び出し元において"5"と置き換えても正しく動作する。てきな

  • これは参照透過なのだろうか?

  • chargeはUnit

    • buyCoffeeの戻りはnew Coffee()と同等
    • つまり、buyCoffeeの呼び出し元を全てnew Coffee()と置き換えても、正しく動作(影響を与えない)しなければならない
    • この条件が満たされないので上記buyCoffeeには参照透過性がない。といえる

置換モデル

  • 参照透過性では、関数が実行する全てのことが戻り値によって表される <= 普遍条件!
  • 関数を全て結果に置き換えても同じように計算が進められる。
    • 等価による置換
    • プログラムの等式推論がなりたつ(意味不明)

純粋性

  • 参照透過性が担保されるとめっちゃモジュール性高い
    • 合成可能

4. まとめ

  • 関数型プログラミングとは副作用のない純粋関数だけを用いてプログラミングすること
  • メリット
    • モジュール性向上
    • 推論の容易可

builderscon 2017 でLTしてきたぞ!の感想とか

はじめに

2017/08/03~05で開催されたbuilderscon 2017で、LTをさせて頂いたのでそちらの感想と来年にやる方への向けて何か残せればと思い記事を書きました。

builderscon.io

決してコアスタッフの方々に圧力をかけられたからではありません。

f:id:HonMarkHunt:20170807104224p:plain

f:id:HonMarkHunt:20170807104058p:plain

登壇までの流れ

  1. 7/20 申し込み(締め切りは7/30迄)
  2. 8/3 採用発表
  3. 8/4 登壇

登壇した感想

  • 当日はメインホール400人会場😥で5分LTをやらせていただきました f:id:HonMarkHunt:20170807122128j:plain
  • ステージ下に順番に並んで前の人が終わったらすぐ次の人はい次!という感じで完全5分切り替え制でした。割とカンファレンスのLTってそういう形式が多いですね。
  • 自分は5番目くらいでしたが、前の人達が全員信じられないほど大爆笑をかっさらっていたので、首を掻っ切って命を断とうかと思いましたが、なんとか発表できました
  • 発表中は緊張しすぎてなぜか会場を見ず、空条承太郎を彷彿とさせるポーズでスクリーンを見ながら発表し、マイクが遠くなって声が小さくなってしまいました。後で言われて首を掻っ切って命を断とうかと思いました。

ちょっと困ったこと

  • 実際申し込みから登壇してみて少し困ったことを書いておきます。

LTの採用・不採用がいつなのかわからなかった。

  • 上記の通り採用連絡が運営のツイッターから行われたのが前日でした。
  • 私みたいな無能エンジニアはスライド作るだけでも数日かかってしまうので、そもそもいつ採択が発表されるのかがわからない状況は少しキツかったです。
  • 前日発表するにしても、「LTの採択は前日に発表します。」と一言アナウンスがあるととても助かるなと思いました。

LTのプロポーザルが運営向けか一般向けかわからなかった

f:id:HonMarkHunt:20170807123907p:plain

  • LTの申し込み時に専用のページからLTの概要を記入するのですが、これが一般公開されるものなのか、運営が審査のために読むものなのかわからず少し書きづらかったです。
  • 書いた後に分かったのは、LT終了後に一般公開されるものということでした。ですが、登壇前にカンファレンスアプリから普通に見えたような気がします。
  • こちらは「そもそもプロポーザルってそういうものだから」とかそもそも私の勘違いなどでしたら喉を掻っ切りますので教えてください。

やってよかったこと

勇気がついた

  • あの大人数の前で登壇するのは私のような底辺エンジニアには中々ない機会でしたのでなんか色々すごいよかったです。

自分のダメなことがわかった

  • 本番は練習以上のものはでない。とよく言いますが、まさにそんな感じでした。
  • スライドの作り, 声の出し方などダメなところがよくわかりました。

最後に

  • 私は以前HTML5 Conferenceのスタッフをやらせていただいたことがありますが、buildersconは3日間開催、スポンサー用のアメニティー、カンファレンスアプリなど考えて、準備と当日運営が死ぬほど大変だったんじゃないかと思いまいした。
  • このような貴重な機会をいただきスタッフの皆さん本当にありがとうございました!!&お疲れ様でした!!
  • また来年も楽しみにしています。

発表資料はこちら

www.slideshare.net

Twitterもフォロー待ってるぜ!

twitter.com

調子乗ってたらflywayのstateが「ignored」になったときの対象法

https://flywaydb.org/assets/logo/flyway-logo-tm-sm.png

内容

こんな感じになっちゃったときの対処法

+---------+---------------------------------------------------+---------------------+---------+
| Version | Description                                       | Installed on        | State   |
+---------+---------------------------------------------------+---------------------+---------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 1.150   | update tsv schemas                                | 2017-06-22 02:33:13 | Success |
| 1.151   | drop column user setting                          | 2017-06-22 06:16:45 | Success |
| 1.152   | add category monitor column                       | 2017-07-03 02:59:44 | Success |
| 1.153   | create manager history                            |                     | Ignored | <= コレ
| 1.154   | create level set                                  | 2017-07-06 02:31:04 | Success |
+---------+---------------------------------------------------+---------------------+---------+

原因

  • flywayのshema versionは新しいものから実行されていくので、↑の例でいくと1.154を先に追加してmigrateした後に1.153を追加すると発生する
  • 普通に開発してればまず起こらなそうだが、以下のように調子にのると発生する。
ぼく 「佐藤さん(仮)の作業にmigrationありますよね!」
佐藤さん(仮) 「はい」
ぼく 「ぼくもあるんで番号かぶってconflictしないようにしましょう!」
佐藤さん(仮) 「はい」
ぼく 「ぼくの方が先にmergeするんで、ぼくが153使うんで佐藤さん(仮)は154にしてください!」
佐藤さん(仮) 「はい」
  • これで佐藤さん(仮)が先にmergeすると↑の状態になる

対応

  • stateがignoredになると、flyway migrateしようがflyway repairしようが実行されなくなる、辛い。
  • flyway migrate時のオプションにoutOfOrder=trueを指定すると実行される

f:id:HonMarkHunt:20170706181255p:plain

https://flywaydb.org/documentation/commandline/migrate

結果

  • こんなんなる
+---------+---------------------------------------------------+---------------------+---------+
| Version | Description                                       | Installed on        | State   |
+---------+---------------------------------------------------+---------------------+---------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 1.150   | update tsv schemas                                | 2017-06-22 02:33:13 | Success |
| 1.151   | drop column user setting                          | 2017-06-22 06:16:45 | Success |
| 1.152   | add category monitor column                       | 2017-07-03 02:59:44 | Success |
| 1.153   | create manager history                            |                     | OutOrdr | 
| 1.154   | create level set                                  | 2017-07-06 02:31:04 | OutOrdr |
+---------+---------------------------------------------------+---------------------+---------+
  • stateがOutOrdrになっている
  • 完全に意味不明である

OutOrdr

教訓

  • 調子のってmigration番号の先読みはしない
  • conflictさせて修正したほうが安全
  • 佐藤さん(仮)は想像より作業が早い

DDD(大臣 Driven Development)のすゝめ

こんにちは!@HonMrakHuntです!

この記事はラクス Advent Calendar 2016の18日目の記事です。

昨日は@Black-Spiderさんのゲーム作り(C++&DxLib)を通してオブジェクト指向プログラミングを学ぶ方法(環境構築~画面の中で物が動くまででした!

明日は@iketomo1207さんの投稿予定です!

目次

  1. はじめに
    1. チームの悩み
    2. 解決策
    3. で。それ、いつ、誰がやるの?
    4. さぁ!DDD(大臣 Driven Development)だ!!
  2. DDD(大臣 Driven Development)
    1. 大臣 Driven Developmentとは?
    2. ルール
    3. DDDのワークフロー
      1. 大臣任命
        1. 問題を明文化する
        2. 大臣を任命する
      2. 大臣活動
        1. 頑張れ大臣!
        2. 報告だ!大臣!
  3. 2ヶ月やってみて
    1. なぜWorkするのか?
    2. 課題
  4. まとめ

はじめに

突然ですが、みなさんのチームは困っていますか?

僕は困っています。

f:id:HonMarkHunt:20161219000159p:plain

今日はチームの悩みを解決する(かもしれない)、DDD(大臣 Driven Development)をご紹介します。

(ドメインの話は出て来ません。本当にすみません。)

チームの悩み

日々のチーム開発に悩みは尽きません。私の所属しているチームにも悩みがあります!

  • あふれんばかり出て誰も手をつけなくなったのエラーログ。
  • 放置されるお問い合わせ。
  • 追いつけない外部APIのアップデート。
  • etc...

チームの悩みはチームの数だけあります。

解決策

もちろん世の中にはそんな悩みを解決することができる方法や知見であふれています。 例えば、上にあげた

あふれんばかり出て誰も手をつけなくなったのエラーログ。

私のチームではエラーログが出ると、Slackのエラーログ部屋に通知が来ます。 日に1件や2件なら誰かが対応できますが、10件、20件、30件...エラーが多くなってくると出るのが当たり前になってめんどくさg誰も対応しなくなります(なりました)。

しかし、エラーログの監視、調査はElasticsearch + Kibanaなどを使うことでとてもいい感じに素晴らしい感じにすることができます。

https://www.elastic.co/guide/en/kibana/current/discover.html

じゃあ早速Elasticsearchを導入だぁー!

f:id:HonMarkHunt:20161219000155p:plain

で。それ、いつ、誰がやるの?

で、それ。誰がやるんですかね?

最初のやる気は何処へやら、日々の忙しい業務に揉まれてElasticsearchの導入は忘れ去られてしまいます。

最悪の場合、誰かが半年後に「エラーログの監視、調査はElasticsearch + Kibanaなどを使うことでとてもいい感じに素晴らしい感じにすることができるんじゃない?」と、発言します。

...もちろんこれはエラーログだけの話ではありません。

チームの数だけ悩みはあり、チームの数だけ解決策があります。

さて、どうしたらいいでしょう?

さあ!DDD(大臣 Driven Development)だ!!

私のチームでは二ヶ月ほど前から、チームリーダーのnagaa052さんの発案で

DDD

  • D : 大臣
  • D : Driven
  • D : Development

を導入しています!!!!

前置きが長くなりましたが、本日はこのようなチームの悩みに立ち向かう、大臣 Driven Developmentについてご紹介します!!

DDD(大臣 Driven Development)

大臣 Driven Developmentとは?

さて、大臣 Driven Developmentとはなんでしょう?自分で書いといてあれですが、名前落ち感がすごいですね。

大臣 Driven Developmentはチームの悩みに立ち向かうために生み出されました。

例えば私のチームの抱えていた悩みは、

* あふれんばかり出て誰も手をつけなくなったのアラート。
* 放置されるお問い合わせ。
* 追いつけない外部APIのアップデート。
* etc...

こんなのでした。

これを大臣 Driven Developmentで解決していきます。 いきますよ。

  • あふれんばかり出て誰も手をつけなくなったのエラーログ。 -> アラート大臣
  • 放置されるお問い合わせ。 -> お問い合わせ大臣
  • 追いつけない外部APIのアップデート。 -> API大臣

はい、DDD完了です。

そうです。大臣 Driven Developmentとは、

チームの悩みごとに大臣を任命し、大臣が責任を持って悩みと向き合う制度 です!

ルール

DDDのルールをご紹介します。

1. 大臣はあくまで責任者であり、担当ではない。

以上です。

このルールについては後述します。

DDDのワークフロー

私のチームで導入されているDDDのワークフロをご紹介します。

  1. 大臣任命
    1. 問題を明文化する
    2. 大臣を任命する
  2. 大臣活動
    1. 頑張れ大臣!
    2. さあ行け大臣!報告だ!

1. 大臣任命

まずは大臣を任命して行きましょう!

1.1 問題を明文化する

チームの問題・改題・悩みをあげていきます。

私のチームではスプリントの終わりごとに振り返りがあるので、KPTでProblemをあげて行きます。

1.2 大臣を任命する

問題(Problem)が見つかったら大臣を任命します!

私のチームではチームで技術定例を行なっています。その際に話あって大臣を決ました。 ひとまず自選他選問わず。ノリで決めました。

2. 大臣活動

大臣が決まったら活動して行きます!

2.1 頑張れ大臣!

任命された大臣が頑張ります!

余談ですが私はアラート大臣を任されています。日々飛んでくるアラートをissueにまとめてみたり、数を数えてみたり、そんな活動をしています。

ここで大切なのは、

  1. 大臣はあくまで責任者であり、担当ではない。

このルールです。アラートなんて見ても全くわからない時がほとんどです。見わからなければ誰かに相談してみます。 決して自分が全て解決しないといけないわけではありません。任命された問題に責任を持って活動すれば良いのです!

2.2 報告だ!大臣!

毎日の活動は夕会で報告します。

今日のアラート数やわからないことなどを報告します。大臣が活動していることがチームに浸透して行くと自然と周りも協力してくれるようになって来ました。

2ヶ月やってみて

以上で、なんとなく大臣 Driven Developmentがどんなものかわかっていただけたかと思います。

私のチームでは2ヶ月が経ちました。振り返りも兼ねてチームがどう変わったかを書いて行きます。

なぜWorkするのか?

ある者は生まれつき偉大、それ以外は強いられて偉大になる。 君にとって、これが偉大になるチャンスだ。

さて、困っていることに大臣を任命して活動するアホみたいな施策ですが、実は結構Workしています。

なぜWorkするのでしょうか?

我らがチームリーダーのnagaa052さんに教えてもらった言葉を紹介します。

「立場が人を作る。」

大臣に任命されると謎のやる気が出ます。

私もアラート大臣という立場に感化されて、気づいたらElasticsearch学ぶ宣言をしていました。 この、立場によって生み出される責任感がDDDがワークする理由だと思います。

課題

始まって2ヶ月のDDDですが、課題もちらほら出てきています。最後に今後のために現状の課題をまとめておきます。

  • 大臣の任期を決めていなかったので、終わりが見えない。交代制にする?
  • 大臣の兼任はいくつまで?たくさん兼任すると大臣活動で忙殺されてしまう

この辺の改善は日々解決して行きたいです!

まとめ

チームにはチームの悩みの数だけ問題があると思います。

悩みを打ち破る手段はたくさんありますが、もしだれがやるのかが決まらなかったら。大臣にやってもらうのはいかがでしょうか?

最後までご覧いただき、誠にありがとうございました。

Frontrend Vol.8 - 帰ってきたフロントレンド 行ってきたメモ

f:id:HonMarkHunt:20161205214825p:plain

はじめに

  • Frontrend Vol.8 - 帰ってきたフロントレンドに参加してきました!
  • 1年半ぶりの開催とのことでしたが初参加させていただきました!
  • ブログ絶対に書くマン枠にて参加させていただいたので、投稿させていただきます。

frontrend.connpass.com

開会の挨拶

  • frontrend久しぶりなのは社内のノウハウが枯渇しかけたから
  • 充電満タン
  • 1年くらいはfrontrendまた継続していきたい

発表アジェンダ

  • Design Systems as a Product プロダクトとしてのデザイン・システムについて
  • Lightning Talks
    • Introduction to Resource Hints
    • atomic designで助かった人たち
    • 祭りから半年たったプロジェクトにジョインしてみた
    • 最近のお仕事について
  • アメブロフロント刷新にみる ひかりとつらみ

Design Systems as a Product プロダクトとしてのデザイン・システムについて

  • 登壇者: @cssradar

デザイン・システムとは?

  • デザインや技術に関わる事柄、ユーザが利用するプロダクトに関わる全てを網羅するシステム
  • ex)
    • Bootstrap
    • Material design
    • ORIGAMI

なぜ必要なのか?

  • マルチデバイ
  • デザインの技術的負債
  • 使う側はそのサービスのどこに触れたとしても同じ体験ができる
  • 作る側も共通の言語(一つの真実)があることでぶれずに早く実装を進めることができる
  • 変化の激しいフロントエンドでカオスを管理する

構成要素

  • STYLE GUIDES
    • デザインに関わる材料やガイドライをドキュメント化する
      • BRAND IDENTITY
      • DESIGN ランゲージ
      • VOICE AND TONE
      • CODE STYLE
      • PATTERN ライブラリーす
      • And more...

導入

  • 技術的な難しさよりどう運営していくか

ゴール

  • デザイナーにとって
    • デザインをする際のビジュアルリファレンスになるパターンライブラリを作る
  • エンジニアにとって
  • デザイン・システムはプロジェクトではなくプロダクトによって作られたプロダクトである

必要な人材

  • デザインが成し遂げたい思想を理解している人
  • エンジニアがシステムを作る手段や方法を理解している人
  • その中間にたてるバランス感覚を持っている人
  • そんな人はいない、いたら連れてきてくれ(雇う)
  • つまりエンジニアとデザイナにはギャップがある

デザイン・システムはそのギャップを解決できる

  • デザイナとエンジニアの継続的コラボレーションとなる
  • デザイナとエンジニアは成し遂げたいゴールは同じなのに共通言語がない
    • デザイン・システムが共通言語となり得る

チームモデル

  • デザインシステムを作成(導入?)していくチームの体制

単性モデル

利点

  • ある一つのプロダクトだけのUIライブラリ集
  • mini bootstrapを作って使ってもらう
  • 確立されたパターンライブラリの存在は大きな利点

弱点

  • ある問題を解決するためにデザイン・システムが生まれてしまう

中央集権モデル

利点

  • どのチームにも属さずデザイン・システムを作成する
  • 様々なチームの要望を聞い作成する
  • 多くの人に受け入れてもらう(一般化)

弱点

  • 実際のプロダクトのつながりが弱い

連合モデル

利点

  • マテリアルデザイン
  • デザイナ, エンジニアが集まって意思決定する

弱点

  • 人材の管理が困難

どれがベストか?

  • 時と場合による
  • 会社の規模や、デザイン・システムがどれだけその規模を網羅するのか...

まとめ

  • デザイン・システムとはプロダクトである
    • プロジェクトは作り終えることがゴールになってしまう
    • システムが生き続けるには必要な運営を考えなければいけない
      • 必要なものはチーム
      • デザイナとエンジニアのギャップが一番小さくなる
      • デザインとエンジニアリング両方できる人はいない

Lightning Talks

  • Introduction to Resource Hints
  • atomic designで助かった人たち
  • 祭りから半年たったプロジェクトにジョインしてみた
  • 最近のお仕事について

Introduction to Resource Hints

atomic designで助かった人たち

  • 登壇者: @becyn

  • デザインを5つのコンポーネントに分割する

  • シンプルな考え
  • デザインが統一されやすい
  • デザイナと仲良くなれる

祭りから半年たったプロジェクトにジョインしてみた

  • 登壇者: @asukaleido

  • 辛いこと多い

  • コードの品質 != サービスの品質
  • なぜか
  • 思想が一貫する
  • フレームワークを使っていない => 思想が強制されない

UI実装の最高とa11y

  • 登壇者: @ahomu

  • 残念なデザインとは?

    • 色々あるがコードが残念toka
  • 使えないをなくしたい
    • 実装が貧弱
    • クライアントがプア
  • 使えない は 使いづらい の延長線上

アメブロフロント刷新にみる ひかりとつらみ

  • 登壇者: @kouhin @herablog

関連資料 developers.cyberagent.co.jp

なぜ

  • PVが落ちた
  • 特に月末
  • 表示速度が他に比べて遅い
  • バックエンドがAPI化されていた

ゴール

  • 表示速度を開演
  • システムのモダン
  • UXが今後10年戦えるUX
    • 表示速度はWebUXを支える最も重要
    • ダンなエコシステムは、いいアプリを作るために必要

表示速度改善

  • コンセプト決める

    • 速度を図る
    • SpeedCurve
  • HTMLのサイズ減らす

    • SSR(サーバーサイドレンドリング) SPA 共存
    • LazyLoad
      • HTML20%減
  • ReactのrenderToString() 遅い
    • キャッシュ最適化

 システムモダン

  • exampleアプリのように作る

    • 正しいものを正しくつかう
  • React with Redux

  • CSS Modules
    • css-loader
    • スコープが切れる
    • 影響範囲が絞れる
  • Atmic Design
    • 状態と処理を持つContainerと表示だけをするContainer
  • Babel
    • 決まっている未来は早めに試そう
    • async/await
  • ESLint/Stylelint
    • 好みはあるがルールを統一して一貫生を保つ
  • CI
    • CirculeCI
  • Docker
    • Node.jsのポータビリティー
    • Nodeのアップデートが観覧
      • Dockerfileを変えるだけ
      • 最新のNodeを使う
  • OSSっぽく開発
    • 外でもそのまま使える技術を

UX

  • No more ガタン
    • 誤タップはモバイルUXで最悪の出来事
  • コンテンツファースト
    • 横幅をMAXまで使う

つらみ

  • Reduxむずい
    • Action/Reducer理解するまで時間かかる
  • Lintがスパルタ
    • 最初はCIでエラー
  • アメブロモジュール多すぎ
  • 周辺技術多すぎ

結論

  • みんながんばろ

感想

今回は初参加させていただいたfrontrendですが、非常に濃い内容でLTも30分枠で聞きたい内容ばかりでした!

発表資料も今後アップされて行くと思いますが、FRESH!で生放送されていた動画があるようなので、是非ご覧になってみてください!私のまとめ記事の1000倍は内容があると思います!!

さて、勉強会のタイトルでもあるように自分なりに今日のお話を聞いて frontのtrend を感じました、それは

  • デザイン・システム
  • Atomic Design

です!

デザイン・システムは今までCSSの便利ライブラリくらいに捉えていたBootstrapがエンジニア、デザイナ間での共通言語として、どんな目的のために利用して行くべきなのか。自分の中で明確になりました。

また、LTで @asukaleido さんの仰っていた「コードの質とユーザビリティーは必ずとも一致しない。なぜならコードに統一された意思があるから。」というプロダクトのコードに統一された意思をもたらす面でも役立つのかなと思いました。

Atomic Designは画面のコンポーネントを最小単位から順に5つの大きさに分類する。というもので、コンポーネントの再利用性・デザインの向上などの恩恵もあるようでしたが、自分はデザイナとの共存が一番のメリットに感じました。

少し話は進んで、アメブロの @herablog さんのお話にもあったように、Atomic DesignをReactやVue, AngularといったJSライブラリ群とどう共存させるか。というのも興味が湧いて来ました。

乱暴な言い方ですが、デザイン・システムもAtomic Designも

  • デザイナ・エンジニアの共存性向上
  • UI/UXの改善
    • つまりエンドユーザーにより高い価値のものを届ける

という点においては、達成したいものは同じなように感じました。そしてこれが今の、ひいてはこれからのfrontendの課題なのではとも感じました。