TechRAMEN 2024 Conference に自動テストネタで登壇 & スタッフとして参加してきた記録です。

---

## TechRAMEN Conference

北海道旭川市で初めて開催された IT カンファレンスです。その名も TechRAMEN。

https://techramenconf.net/

旭川はほど良い大自然に囲まれた平和な街なのですが、最近は時々印象強めの暗いニュースがあるせいで、本州の人から心配されることもあるとかないとか。自分としても何か旭川の印象を変えることができないか考えていた中、このようなイベントに参加してくれた人に少しでも明るい印象を残すことができるはずなので、旭川の民としてコアスタッフの方には本当に感謝です。

重い話はさておき、自分としても旭川に引っ越して旭川ゆるい勉強会といういい感じのコミュニティに出会い、1 年後にこんな大規模イベントが開催され、ちょうど 1 年くらい社内でテスト自動化に力を入れていて一番参考にしている t-wada さんがゲストスピーカーとして発表してくれる、実際に t-wada さんが発表を見に来てくれるという嬉しい奇跡が連続しています。全ての運命を手繰り寄せたかのような自分の豪運が怖い。

## 自動テストの取り組みについて発表

テックタッチ社のフロントエンドチームの中でクオリティチームというサブチームの中で自動テストを増やすための取り組みに力を入れていました。その取り組みもいくつか貯まり成果も出てきたので、t-wada さんも参加する会に自動テストのテーマで出すことにドキドキしながらプロポーザルを提出しました。無事採択してもらえたので地元旭川勢として良い発表が出来るように気合いを入れて発表資料を作りました。

https://www.docswell.com/s/92thunder/K22LPR-2024-07-30-183111

発表の初めの方で t-wada さんが来てくれて緊張が高まりましたが、頷きながら話を聞いてくれたので心強すぎる安心感でリラックスしながら発表することができました。

### 発表の反応

https://twitter.com/search?q=since%3A2024-07-27_12%3A50%3A00_JST%20until%3A2024-07-27_13%3A55%3A00_JST%20%23techramen24conf%20%23miso&src=savs&f=live

https://togetter.com/li/2409556?page=69#h1717_0

Togetter まとめありがとうございます！！

自社の良い取り組みを知ってもらうとともに、聞いてくれた人の現場でも参考にできそうだったようで、発表で狙っていた目標は達成できました。DevOps は名前から感じるかっこいい印象とは裏腹に、実際はチームと対話しながら１つ１つアイデアをチームに導入して課題を解決する取り組みが多いです。成果が出るまでの道のりは短くないですが、参考にできる取り組みや実際に取り組んでいる人から勇気を貰えることはあると思うので今後もそういった発表をしていきたいと思います。

## Webサイト & 当日スタッフとして

元々は当日スタッフとして 2 日間のお手伝い参加のつもりだったのですが、運営 Discord で Web サイトにタイムテーブル載せたいなどと提案したところ、スムーズに GitHub の招待が届き Web サイト担当の 1 人に加わることになりました。やったことはタイムテーブルのリンク追加とラーメン応援団(個人)の追加だけですが、お祭りの準備感があって楽しかったです。Astro の素振りしてたので役に立てて良かったー。

当日スタッフとして、設営 & お片付けや発表のタイムキーパーや自分の発表も含む司会を担当しました。担当した役割は特等席で発表を見られるもので、担当以外の時間は参加者として楽しんでくださいと言われていたのでずっと発表を聞くことができて役得でした。他のスタッフや FuraIT の富良野勢とも知り合うことができて良かったです。

## セッション

普段聞けない分野の話もあり、どのセッションも興味深かったです！旭川で全国レベルの話が聞けるイベント最高すぎる！

特に印象に残ったセッションについて紹介します。

[ひとりのプログラマ、問題解決者としての原理原則とワークフロー](https://fortee.jp/techramen-24-conf/proposal/0f3bfdd4-394a-47f2-9b3b-46ebb58150bf)
- t-wada さんが普段意識されている問題構造分析/インクリメンタル/イテレーティブの解説を聞くことができた
- インクリメンタルに進めるため、あらゆるレベルの作業を可逆にしていくという考え方が新鮮だった

[効果的な脆弱性診断の受け方](https://fortee.jp/techramen-24-conf/proposal/21a8cd45-25ad-4752-80fc-427687e45f20)
- 普段聞くことができない、脆弱性診断を提供する立場からの解説を聞くことができてとても勉強になった

[【パネルディスカッション企画】ゆるいエンジニア相談室 ～あずましい開発組織とは ～](https://fortee.jp/techramen-24-conf/proposal/b3c11337-6247-4f52-bc6b-e0e48050c8c8)

- 地方の IT 企業の現場のリアルを聞きながら、自分だったらどうするだろうと考えながら話を聞くことで、受託開発企業の将来を考える良い機会となった
- 自分はどんな現場でも DevOps を信じてガムシャラにやることしかできないなと感じた

[入門 オンコール対応 ~ 深夜対応後のラーメンが最高編](https://fortee.jp/techramen-24-conf/proposal/330843d7-2548-4bf2-97f0-3620fb162dd0)

- 自社で障害対応に関わることもあるが自身で最初からインシデント対応に関わることはないので、当番として深夜も対応するエンジニアがどのように取り組んでいるのか知ることができて良かった

## おわりに

道北というそこまでアクセスの良くない土地で、スポンサーを多く集めない予算の中で、100 人を超える規模での IT カンファレンスを開催し、その中にも tomio さんを始めとしたコアスタッフメンバーの思想がうまくデザインされ、非常に熱気を感じるカンファレンスになったと思います！

今後も旭川や北海道に留まらず、全国に登壇できるような経験や取り組みを発表して、旭川から IT コミュニティの波を盛り上げていきたいと思います。


TechRAMEN Conf 2024に登壇 & スタッフとして参加した

git で現在のローカルブランチの内容をリモートの同名ブランチに pull & push する方法のメモ。

---

## コマンドの調査

Git の CUI 操作は苦ではないが、ブランチ名を毎回入力するのは時間がかかるのでブランチ名を入力しなくて済むコマンドを調べた

```sh
# pull
git pull origin $(git branch --show-current) 

# push
git push origin HEAD
```

このまま使うと長いので、alias を設定した。fish の設定例。

```config
abbr --add gpb 'git pull origin $(git branch --show-current)'
abbr --add gph 'git push origin HEAD'
```

## `abbr` について

abbr を設定したことがなかったのでメモ

- abbr は abbreviations(略語という意味)の省略語
- Enter キーやスペースキーで元のコマンドが展開されるので、`history` でコマンドの実行履歴を見た時に git などで検索しやすい

[https://fishshell.com/docs/current/cmds/abbr.html](https://fishshell.com/docs/current/cmds/abbr.html)


git pull, push のエイリアスを設定して時間短縮

DevOpsDays Tokyo 2024 に初参加＆発表してきたので頑張った記録を書いておきます。

---

## DevOpsDays Tokyoで発表しようと思った理由

半年ほど前から、1 年ほど会社でトランクベース開発の導入に取り組んでいた経験や成果を発表したいと考えていました。そういった中で、DevOps のイベントを探していたところ、DevOpsDays Tokyo が春に開催されることを知りました。懇親会の中で他の参加者と話したところ、アジャイルや SRE のイベントはいくつか開催されているが、DevOps のど真ん中のイベントとしてはこのカンファレンスしかないということでした。年に 1 度の重要なイベントを逃さずに参加できてよかった〜。

フロントエンドや JavaScript 系のイベントでの発表経験はあったものの、アジャイル系のイベントに参加すること自体初めてでした。DevOpsDays が世界各地で開催されているイベントだと知り、絶対ここで発表したいという気持ちが強くなりました。

## プロポーザルを出す

2 月末が最終締め切りだったので、それに間に合うようプロポーザルを提出しました。内容は自分が話したいと思っていた内容そのままで、この 1 年の取り組みの中で経験した DevOps 観を伝えるものだったのであまり悩まずスラスラ書けました。内容について、社内から見て違和感がないか、または外部から見て興味を引くような書き方になっているかを社内でレビューしてもらい改善しました。

提出後に気づきましたが、案内のどこかに DevOps の文化的な側面の内容を求めている旨が書いてあり、トランクベース開発導入に取り組む中で目的やビジョンの浸透など DevOps の文化にも触れている内容だったので、初心者らしい内容にしてはよかったのだと思います。この辺り Networking でスタッフ参加してくれてた方にも聞いてみればよかったな。

他の発表者の提出内容を見ると、1 人で複数のプロポーザルを出している人もいました。次回からはそういった作戦も取ってみたいですが、一本に集中して内容をブラッシュアップできたのもよかったのかもしれないです。

## 発表について

[トランクベース開発の導入で見えた DevOpsの技術・プロセス・文化との繋がり](https://speakerdeck.com/92thunder/torankubesukai-fa-nodao-ru-dejian-eta-devopsnoji-shu-purosesuwen-hua-tonoxi-gari)

Hall A、Hall B と比べると小さい Room C という部屋でしたが、ほぼ満席になっており、30 人くらいの方が発表を聞きに来てくれました。オンラインは確認してなかったけどでもそこそこ入ってもらっていた記憶。

自分にしては余裕を持って 1 週間前にはほとんど資料が出来上がっていて、社内での発表練習を経て大きく改善することができました。このようなカンファレンスで発表するのは初めてだったので、前日も遅くまで資料の手直しをし、発表前もスピーカー控え室で何度も資料を見直しました。話す予定だったことはほとんど話せて、時間通りに発表を終えることができたので、頑張って準備した甲斐がありました！

発表の冒頭で、スタッフさんに写真を撮ってもらうなどして話しやすい空気を作ることができたので、そこまで緊張せずに発表することができました。今後もなにかしらのゆるさを演出できる仕掛けを持っておきたい。

## 発表してみて

発表後に何人かと話して、トランクベース開発に取り組みたいが、なかなか実現に移すことができないチームもいるということがわかりました。まずは自分のチームから小さく始めるということが認められていることが、出発点として非常に重要だと感じました。自分は周囲に説明したことで受け入れてもらえたが、実験や挑戦を推奨する文化があったため取り組みやすかったのだと思います。

DevOpsDays は廊下や懇親会の雰囲気が良く、今まで参加した勉強会の中で一番他の参加者と話しやすい場だと感じました。海外の参加者が多い影響もあってか、廊下での会話が盛んに行われていました。さらにスピーカーとして参加することで、川口さんをはじめ他の発表者とも話す機会もあってよかったです。アジャイルを始め開発プロセス系のイベント初参加の自分が DevOps 界隈に一気に馴染めたような感覚があり、とてもよいカンファレンスでした。ここ数年で魅力に気づいて取り組んでいた DevOps 界隈の一員になれて嬉しく思います。

このような大きなカンファレンスでの発表は初めてでしたが、採択されて自分なりにうまく発表でき、発表後に他の参加者と良い意見交換ができたので、大きな自信に繋がりました。今後もカンファレンスの発表には恐れず取り組んでいきたいと思います。


DevOpsDays Tokyo 2024に初参加&登壇してきた

このブログのフレームワークを Next.js からもっと軽量なものへの乗り換えを検討しているため、その候補探しとして Astro を勉強してみる。

---

## やること

このチュートリアルを最初からやってみる

https://docs.astro.build/ja/tutorial/0-introduction/

## インストール

* コマンド実行したらサクッとテンプレートが作られてすぐに開発できる
  * (欲を言うと Linter の設定も欲しい)
* テンプレート生成用の CLI がすごくリッチに作ってある

## ページ追加

* .astro ファイルに html のようなものを記述していく
  * 独自の記法を使って変数宣言することになるので、.vue ファイルと同じようにリンターやビルド周りの追従が必要になる
* `/src/pages` にページ相当の astro ファイルを置いていく
  * pages 以下の配置によって自動でルーティングされていく

## コードフェンス

以下のコードページ内で使う変数を設定して利用できる

```
---
const pageTitle = "About me"
---

<h1>{pageTitle}</h1>
```

* --- で囲われた部分をコードフェンスと呼ぶらしい
* コードフェンス内に書くものがない場合は省略しても良い
* オブジェクトや配列も利用可能。jsx と同様に配列を map で展開して HTML を出力することも可能
React に慣れてたらスムーズに受け入れられそう
* Middleman のような静的なページを作成するフレームワークでも似た方法が用いられてきた

## Style

* `<style>` 内で変数を使用するには `define:vars()` を使用して CSS の変数化する必要がある
* css ファイルを各 astro ファイルに import するだけで global の style として利用できる

## コンポーネント

* `/src/components` にフォルダを置く
* ページや他のコンポーネントから import して `<Navigation />` のように読み込む 
* `const { username } = Astro.props` によってコンポーネントに値を渡すことができる
* コンポーネント内に `<style>` を書くことでコンポーネント内に適用する CSS を設定できる

## Script

* `<script>` タグによって JavaScript を記述できる
* `/src/scripts` にスクリプトを置く
* `<script>` タグの内側に `import "../scripts/hoge.js"` を記述することで

## Layout

* `/src/layouts` にテンプレートとなるレイアウトファイルを置く
* `<slot />` 部分が `<BaseLayout>` の子コンポーネントとしてスロットインできる
* markdown のコードフェンス内には frontmatter として yaml 形式で props を記述する
* `<slot />` をネストさせることで複数のレイアウトを組み合わせることも可能になる

## Astro API

* `Astro.glob` を使って特定パスのマークダウンファイルを frontmatter ごと取得し、map で html をレンダリングすることができる
* pages に js ファイルを置き、GET 関数を export することでファイルを生成することもできる
  * turorial では `@astrojs/rss` を使って rss.xml を作成した

## Astro Island

* `npx astro add preact` によって astro プロジェクトに preact をインストールする
  * astro.config.mjs ファイルの変更も加えてくれる
* components に jsx のファイルを作成することで、React でコンポーネントを作ることができる
  * props は通常の React コンポーネントと同じように第一引数として渡すことができる
  * React によってボタンをクリックした時に特定の関数を実行して表示のようなインタラクティブな操作を作ることができた
* `client:load` をコンポーネント呼び出し時に設定することで、ロード時に JavaScript の動作を設定することができる（ハイドレートという）
  * `client:visible` なら表示されたタイミングでハイドレートする
* 新しいプロジェクトを立ち上げなくても、部分的に他のフレームワークによる UI コンポーネントで置き換えることができるのは色々試してみたい自分にはメリットだと感じた

## Astro Islandを使わないインタラクティブな操作

* UI コンポーネントを使わなくても `<script is:inline>` 内に JavaScript を記述すればインタラクティブな操作を作ることができる
  * 純粋な JavaScript から HTML を操作する必要があるのでまあまあ大変

## おわりに

* ブログをシンプルな設定で簡単に作ることができたので、静的サイトで一部だけ動的のようなページには良い選択肢になりそう
* 今の Next.js 製ブログから Astro への乗り換えにおいて気になったポイント
  * markdown サポートが最初から入っているので、細かい markdown の設定を考えずにブログの記事に集中できそう
  * 動的に目次を生成することになる場合も、React を使うことができるので大きな問題はなさそう
  * RSS の生成もそんなに難しくないので、Next.js よりもわかりやすく生成することができそう
  * React のライブラリ使いたいとなった時にどこまで対応されるのか不安
  * コードフェンスなどの Astro 独自の記法があるので、 linter などエコシステムの対応が追い切れるのかという懸念がある
  * タグ機能だけでも Astro 独自の仕組みを使っている感があったので、高機能にして JS の割合が増えていくとメンテナンスする時のコードの見通しが悪くなりそうな感じはした
* Next.js からの乗り換えにおいて迷わずベストとは思えないので、他のフレームワークももう少し検討してみる
* 久しぶりにチュートリアルから取り組む学び方を進めてみたが、非常にドキュメントが整備されており学習を進める体験がとてもよかった



Astro Tutorialをやってみる

会社のオフサイトミーティングへ参加後、翌日に立ち寄った東京の美術館で刺激を受け、トップページのデザインを作り直した。

--- 

## 美術館で刺激を受ける

「会社のオフサイトミーティングとその後の飲み会よかったなー、明日の予定決めてないけど夕方まで暇だし美術館くらい観に行きたいなー」と考えつつ眠りについた。翌朝にカフェでモーニングを嗜みながら、「前は上野の美術館見に行ったので今回は現代アート行っちゃうか」と考え [東京都現代美術館](https://www.mot-art-museum.jp/) に行くことを決めた。

[MOTアニュアル2023 シナジー、創造と生成のあいだ](https://www.mot-art-museum.jp/exhibitions/mot-annual-2023/) を鑑賞して、**自分も人の心を動かす表現してみたい**と感じた。作品を見ていて「それやられたか〜」と偉そうな敗者の感想を抱き、アーティストと我々の違いは妄想の具現化を試みるか何もしないかだと思った。AI 技術や 3D プリンターによる生成技術の進化によって、芸術の世界にもシンギュラリティの影響が訪れているのかもしれない。

[MOTコレクション 歩く、赴く、移動する　1923→2020 特集展示　横尾忠則―水のように 生誕100年　サム・フランシス](https://www.mot-art-museum.jp/exhibitions/mot-collection-231202/) を鑑賞して、**偶然による美しさ**に気付いた。絵画の中には計算されている美しさも多いと思うが、絵の具と筆による滲み、掠れ、広がりによる美しさを再認識できた。

## 自分にできることを知る

Web 制作に弱いフロントエンドエンジニアなので視覚的な表現を演出する方法は HTML, CSS, JavaScript 以外に思い付かず、今の自分に出来る範囲での表現を考えた。

最初に水彩画のような水による滲みや広がりを表現できないか考えた。CSS を使って表現できないか調査と実験をしてみたが、早々に自分の技術の限界を感じて方向転換した。

生活の合間で調査していく中で、CSS による画像と色の合成に辿り着いた。

[background-blend-mode | MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/background-blend-mode)

## 偶然を演出する

作成の過程で "偶然の創造" が自分の中でのテーマになった。自分の創造によって偶然を生み出すことで一期一会のいい感じのグラフィックを演出する。

結果としてこのようなページが出来上がった。[92thunder.dev](https://92thunder.dev/) のデザインに悩んでいたのでトップページに適用することとした。

![](/posts/2024-02-11/screenshot_web.png)
![](/posts/2024-02-11/screenshot_mobile.png)

ページを読み込む度に異なる背景画像が生成される。自分好みのデザインになってとても気に入っている。さらに偶然を演出するための変数を増やすこともできるが、増やしすぎると作品としての軸がブレるとも考え、これ以上は追加しないこととした。

芸術作品に詳しい解説は野暮(???)なので仕組みの説明は避けるが、簡単な仕組みなので一晩の頑張りで初期実装を完了することができた。

## おわりに

偶然立ち寄った美術館で、作品による刺激を入力して、満足いく成果物を出力することができたので自分という生成システムへの信頼度を上げることができた。今回見た美術館で他のアイデアも浮かんでいるので、妄想を止めることなく今後も作品作りに取り組みたい。

美術館を見に行った翌日、友人と[ルミネtheよしもと](https://lumine.yoshimoto.co.jp/)にお笑いを見に行きました。とても面白かったです。


美術館に行く、トップページを作り直す

サイクルタイム改善に取り組む中で、Twitter での意見やメンバーからの反発もあり、思うところがあったので自分なりの考察と意見をまとめてみる。

---

## "生産性向上" は質より量？

最近目に留まったポストはこちら。

<https://twitter.com/yusuke_kokubo/status/1740524775381123431>

主張としては、Four Keys で扱っているのはアウトプットの量であり、アウトカムには目を向けていないというもの。自分としては [Leanと DevOpsの科学[Accelerate]](https://amzn.asia/d/6GwTAP4) に書いてある内容は価値を届けるための取り組みが多いと感じていたので意外だった。

2023 年は開発生産性に関するイベントが多く開催され、Lean と DevOps の科学を読んでない人たちにまで、 生産性や Four Keys というフレーズが前提の認識なく伝わっている印象を受けていた。(もちろん前提があった上で生産性への忌避感を持っている人もいると思う)

## 社内でも感じる生産性向上への不信感

Twitter で見かけたポストと同時期に、社内でも似たような意見を耳にすることがあった。

社内での生産性改善の取り組みの詳細は割愛するが、主要な改善活動としては以下の流れになっていた。

> チームのふりかえり時間でのサイクルタイム分析 ⇄ コードレビューの改善

その結果、初めはレビュープロセスを改善することで良い兆候はあったものの、すぐにマンネリ化が始まってしまった。生産性向上への取り組みもあまり理解を得られていない雰囲気も感じていた。

## 「LeanとDevOpsの科学」のおさらい

改めて読み直して気づいたことを 2 つ。

### 価値への関心

そもそも Lean のアプローチは「無駄を最低限にして、とにかく顧客に価値を届けよう」というものである。Four Keys を見た限りでは価値が抜け落ちるかもしれないが、本書では価値を忘れていないどころか重視しているように感じる。

従来は内側で少しでもいいものを完全に作り上げてからリリースするアプローチだったが、DevOps ではそれのもたらすフィードバックループとフローの高速化によって、継続的に改善するアプローチを取っているため、考え方の転換が必要になる部分はある。これもチームからの不信感を募らせる可能性がある。

### ケイパビリティの獲得が強力な改善をもたらす

生産性を測定するための指標として Four Keys を定義しただけでなく
、ケイパビリティの獲得がソフトウェアデリバリーのパフォーマンスに有意な改善をもたらす能力も明らかになっている。

[Google Cloud | DevOpsの能力](https://cloud.google.com/architecture/devops?hl=ja)

社内の取り組みでは、Four Keys とサイクルタイム分析という数値が先行し、ケイパビリティ獲得という観点での取り組みが後手に回ったという自覚があり、チームからの不満をもたらす要因になっていたと感じる。

社内で生産性改善する時は、Four Keys は表に出さずチームで足りないケイパビリティを獲得しようという発想で動き始めた方が不信感も少なく、関係者で同じ方向を向いて前向きに動き出せるかもしれない。

## 人によって求める "はやさ" の観点が違う

この記事を読んで、何を持ってはやいと捉えるかは見方によって変わるということを認識できた。

> スループット的な速い :決まった時間にどれだけの施策の個数をこなせたか？などのように時間を固定して、アウトプットの数を数えるもの。これまで議論してきた生産性的な意味でのはやい。同じ工数などでどれだけの機能を実現したか。  
> リードタイム的な早い ：ある施策に注目したときに、それをリリースするまでに何日かかったかなどを数えるもの。これまで議論してきたはやいとは違い、数ではなく期間に注目するもの。
> 
> [開発生産性について議論する前に知っておきたいこと
](https://qiita.com/hirokidaichi/items/53f0865398829bdebef1#%E9%96%8B%E7%99%BA%E7%94%9F%E7%94%A3%E6%80%A7%E3%81%8C%E9%AB%98%E3%81%8F%E3%81%A6%E3%82%82%E9%96%8B%E7%99%BA%E3%81%8C%E6%97%A9%E3%81%84%E8%A8%B3%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84)

結局は、リリースにかかるまでの時間を短くしないと意味がないよねという気持ちはみんな持っているので、社内の動きとしてもデプロイ頻度を上げる取り組みはスループット工場よりも力を入れて取り組むべきだった。

また、受託開発と自社開発では、何のために生産性を改善するのかも大きく変わってくる。自社開発では純粋に顧客へ多く価値を提供する目的となるが、受託開発では予定していた機能を遅れずにリリースすることが発注者への価値になることが多い。この点も生産性という言葉の背景がブレやすいポイントになっていると感じる。この視点は自分では気づくことができなかったが、[最近参加した勉強会](https://asahikawa.connpass.com/event/305524/)で発表後にディスカッションする中で教えてもらうことができた。

## おわりに

アジャイルにとってのスクラムが、XP の価値やプラクティスを置き去りにしたように、Four Keys や"生産性"の取り組みの前提や改善の中身の理解が伴っていないように感じていた。自分なりの考察ではあるが、勉強会での発表の場も借りて言語化することで、生産性改善の取り組み自体を改善するヒントを得ることができた。今回の気づきを持って前提が伝わるコミュニケーションを意識して目線を合わせて改善に取り組む。


なぜFour Keysが嫌われるのか

Playwright でテストを書いていて、`.ts` ファイルから読み込んだ設定値をコンポーネントに受け渡しできなかったので原因をメモ。

---

## 事象

Playwright で `test()` 内でマウントしているコンポーネントに対して、 `.ts` ファイルから読み込んだ設定値を渡そうとしたところ、`hoge is not defined` というエラーが発生した。

## 原因

Playwright では、テスト自体は Node.js として実行され、コンポーネントは実際のブラウザで実行される仕組みとなっている。テストでは Node.js の全ての機能が使用できるが、Node.js として実行している部分で読み込んだファイルのオブジェクトをコンポーネントの Props として渡すことができない。

公式ドキュメントはこちら

<https://playwright.dev/docs/test-components#test-stories>

プレーンな Object, string, number は渡すことができるが、Node.js の世界で作ったオブジェクトやコールバック関数を渡すことはできない。

## 解決策

公式でも紹介されている通り、テスト対象のコンポーネントを wrap したコンポーネントを作成することで解決している。

Wrapper コンポーネントを別の tsx ファイルで作成しておき、テストからは `await mount(<Wrapper />)` することで、Wrapper を定義しているファイルではブラウザ内で実行されるコードとすることができる。


PlaywrightのテストはNode.jsで実行され、コンポーネントはブラウザで実行される

https://note.com/92thunder/n/n533a6badb8f5

北海道旭川市に移住しました

3rdparty.js を主催 & 発表して、初主催の勉強会にしては成功に終わることができたので、よかったことを記録に残す。

---

[3rdparty.js #1](https://3rdpartyjs.connpass.com/event/289558/)

## 開催のモチベーション

自社の1人目フロントエンドエンジニアとして開発に従事しており、サードパーティスクリプト周辺技術の知見も少なくネットの文献もMDNを漁りながら開発を進めていた。調べても知見があまり出回っていない界隈なので、他のサードパーティスクリプトの開発者も同じ気持ちだと考え、2023年の初め頃から開催について検討を始めた。

春ごろに社内のテックブログ運営メンバーに相談したところ、温かい援護に背中を押してもらい開催することを決めた。そうしてテックタッチのメンバーに運営に入ってもらい、懇親会費も会社にスポンサーとして協力してもらうことで、3rdparty.jsという勉強会の第1回目を開催させてもらえることになった。

## よかったこと

### 参加企業の呼びかけ

勇気を出してプレイドさんに声をかけて結果多くの方に参加してもらうことができた。ネットワーキング活動が弱めの自分でもTwitterで話しかけてみたら快く技術広報の方に繋いでもらうことができ、その流れで mizchi さんにも登壇していただけたので本当によかった。有名な名前を持っていない勉強会の開催はYoutuberのコラボ戦略と同じく多くの注目を集めるには、影響力の強いエンジニアに参加してもらうことが近道だとわかった。

### 発表内容のバランス

事前にプレイドさんと内容が被らないよう調整し、サードパーティスクリプト開発の世界観が伝わるバランスのいい発表内容になった。

* JS/CSS汚染でサードパーティスクリプト開発の面白さ/難しさ
* ビルドサイズを極限まで絞るための設計
* 要素が見えている状態とは、ブラウザAPIの深掘り
* ユーザごとに最適化したサードパーティスクリプトの配信

### コミュニティとして開催できた

企業の主催ではなく、あくまで 3rdparty.js というコミュニティとして開催することにこだわった。企業主催の勉強会は採用目的を感じ取られてしまい、かなり有名企業ではない限り人が集まりにくくなる。また、コミュニティとして開催するほうが他の会社さんへの声かけがしやすいと感じている。

実はテックタッチ社として初めて主催する勉強会だったが、この形で開催することができて社内への学びの蓄積も多く、成功に終わったことで今後の勉強会開催の自身にも繋がった。

### 懇親会の雰囲気作り

懇親会はとても盛り上がって最後まで良い雰囲気での開催で終わることができた。この空気作りは事前に計画したわけではなく、流れで乾杯をLT前にすることになり、同僚の canalun の発表で空気が和み、参加者の方の技術トークを楽しむ姿勢で良いものになったと思う。こういった体験はオフラインならではなので今後もオフラインまたはハイブリッド開催を目指したい。

## 自分の発表

[どんなページでも動かす！JS_CSS汚染を避ける戦い](https://speakerdeck.com/92thunder/donnapezidemodong-kasu-js-csswu-ran-wobi-keruzhan-i)

事前にプレイドさんと発表内容が被らないよう調整した上で、テックタッチのメンバーで 3rdparty JavaScript について話せることの中でウケがよさそうなネタをピックアップして話した。最初はテックリードのtakaに発表してもらう予定だったが、別の登壇を予定していたこともあり在籍歴が長く今までの経緯をある程度把握している自分が発表するようになった。発表内容はコードレビューなどで普段からある程度理解はしていたものの自分で全てやっていない部分もあり、改めて自分の力で理解し直す良い機会になった。

社内のフロントエンドメンバー中心に発表練習に付き合ってもらい構成や細かい表現を何度も修正することができて、今までで一番プレゼン作りのスキルが向上したと感じる。

数年ぶりの登壇で緊張していたこともあり、話す内容をかなり飛ばしてしまい予定時間よりかなり早く終わってしまった。事前に想定質問を考えていなかったこともあり、質疑応答はプロダクトのことをどこまで話してよいのか考えながらでうまく答えられず非常に難しい時間となってしまった。

狙い通り 3rdparty.js の初回開催らしい発表内容にはできたようで、参加者の意見を聞く限りWebのサードパーティスクリプトがどういった開発の世界観なのか理解してもらえたようでよかった。ニッチな分野なのでこのコミュニティでの知見やつながりを大事にして、日本のサードパーティスクリプト開発のレベルを上げるような活動をしていきたい。

## おわりに

北海道に引っ越してしまったこともあり、オフライン勉強会に自分の手足を動かした貢献は難しくなってしまったが、オンラインでの調整に動いて2024年初めくらいに次回もオフラインでの開催を目指したい。


3rdparty.jsを主催&登壇してきた

初参加でしたが旭川に引っ越した自分にとっては、貴重なオフラインでのアウトプットの機会なので発表してきた。

---

## 参加した勉強会について

https://asahikawa.connpass.com/event/296360/

過去最多人数とのことだったが20人以下で1人ずつ自己紹介できるくらいの人数だったので、他の参加者の方との距離感がちょうどよかった。

地元のコミュニティハウスのような場所の和室を貸し切って18人で交代で発表する形式だった。最初は思っていたよりゆるっと始まって驚いたが、終わってみればちょうどいいゆるさだったなと感じた。

地方自治体が抱えるガバメントクラウドの問題やPSIRTでのセキュリティ活動の話など、自分が普段参加しない勉強会の話を面白く聞くことができて知識の幅を広げることができた。今後もSaaS開発屋さんとして自分の知見を還元していきたい。

tomio さんはじめコミュニティを盛り上げるために活動している人の割合が都会より多く、地方の勉強会に参加すれば濃い繋がりが作れると感じた。地元の教員の方が参加してくれているのもIT勉強会と地元のつながりを強くできてよいと思った。

## 自分の発表

最近開発のメイン業務以外で熱を持って取り組んでいる生産性向上の取り組みについて発表してきた。会社に絡む内容なので公開前にレビューしてもらい一部修正した。

https://speakerdeck.com/92thunder/kai-fa-sheng-chan-xing-xiang-shang-noqu-rizu-mirogu

外部でこういった主務の開発以外の取り組みについてアウトプットする機会がなかったので、発表することで自分の現在地を確認することができるとともに、他の人に自分の興味を教えることができてよかった。


ゆるあさ で開発生産性の取り組みを発表してきた

エンジニアなら /etc/hosts を設定して特定サイトへのアクセスをブロックしよう。

---

## /etc/hosts とは

`/etc/hosts` ファイルは、twitter.com のようなホスト名とそれに対応したIPアドレスを紐付け設定できるファイル。 現在ではこの役割は DNS が担っている。

このファイルを設定することで、オレオレDNS設定が可能になるので、覚えておくと便利な場面はありそう。

最近セルフふりかえりをする中でPCでTwitterの閲覧時間を制限したくなり、容易にアンインストールできるブラウザ拡張より解除が面倒な方法がないか探している中でたどり着いた。

## 設定方法

`/etc/hosts` を開いてIPアドレスとホスト名を設定するだけ。

```bash
sudo vim /etc/hosts
```

編集するにはパスワード入力が必要になる。

```text
127.0.0.1       twitter.com
127.0.0.1       youtube.com
127.0.0.1       www.youtube.com
```

こういった使い道をする際はローカルループバックアドレスを指定することが多いようだ。適当なIP指定してそっちにアクセスしてしまうと怖いので理に適っている。

Mac だけかもしれないが、Firefox では開けてしまうので別の設定が必要になる。自分は使ってなかったのでアンインストールした。

## 結果

ブラウザ拡張を使って制限するより効果が強く、本当にTwitterを開かなくなってしまった。スマホのXでポストするのは面倒なのでこのまま離れてしまいそう。


/etc/hosts に特定のサイトに繋がらないようにする

settings.json に `editor.formantOnSave` などを設定しても保存時の自動フォーマットが実行されず、2時間溶かしたのでメモ。

---

VSCode の出力タブを見ろ！エラーログが出ていて自動フォーマットが動作しなくなっていた。

今回の場合は import の sort 設定がエラーになっていた。

https://github.com/IanVS/prettier-plugin-sort-imports/issues/132


VSCode で eslint, prettier の設定を見直しても動かない時の対処法

モノレポの構成で複数チームが開発するなら GitHub の CODEOWNERS を設定しようという話です。

---

## CODEONWER とは 

GitHub の設定でファイルやディレクトリに対してユーザもしくはチームを指定することで、レビュワーの自動アサインをはじめとした機能を使えるようになる。設定方法は GitHub の公式ドキュメントで丁寧に紹介されている。

[GitHub コードオーナーについて](https://docs.github.com/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)


モノレポ構成で開発を進めている場合、領域ごとに特化して分担することになるので CODEOWNER の指定は必須になってくるだろう。特に複数チームで開発している場合に CODEOWNER 設定を徹底することで逆コンウェイ戦略を後押しする力となり、チームがナワバリとしたいコードの領域が明確になっていくだろう。

## レビュワーの自動アサイン

コードオーナーを設定しているファイルに対して変更があった場合、レビュワーを自動でアサインすることができる。GitHub のチームを設定している場合、コードオーナーにチームを設定することで、チーム内の誰かを交代でアサインするような使い方も可能になる。

## PRのフィルターを使ったレビューコスト軽減

コードオーナーを設定しておくことで、プルリクエストの Files changed タブのフィルターに "Only files owned by you" という項目が追加される。この項目にチェックを入れることでコードオーナーに設定されているファイルのみを絞って表示することができる。

この機能によって、モノレポの全体に変更が入るような設定の変更があったとしても、コードオーナーとなっている範囲に対してのレビューしやすくなるので大きい PR への抵抗感を軽減できる。

## コードオーナー設定の進め方

私が考える実務でのコードオーナー設定の進め方を紹介しておきたい。半分くらいモノレポの説明になってしまった。いろいろ書いたが、まだまだ実務でも取り組んでいる最中ではある...。

### 1. 全体のコードオーナーを設定する

以下の設定で全体のコードオーナーを設定できる。これによってコードオーナー未設定コードは全てテックリードにオーナーを任せると運用としつつ、段階的にコードオーナーの設定を分割していくことができる。
```
* @92thunder
```

このやり方を再帰的に実行し、まずは大きい粒度でオーナーを定め、徐々に適切なオーナーに割り振っていくと進めやすいだろう。

### 2. コードの分割方法について合意をとる

これはフォルダの分割方法について合意を得る仕事になり、議論が白熱するポイントになるだろう。はじめのうちから複雑なフォルダ構成にする必要はないので、まずは切り口を考えすぎずフラットにディレクトリを配置しても問題ない。

フォルダの切り口としては、ドメイン・技術、プラットフォームなどさまざまな切り口があり、さらにそれらを組み合わせたネスト構造が考えられるため複雑になるだろう。切り口については以下のブログが参考になった。

https://dev.to/this-is-learning/semantic-grouping-folders-with-nx-3467

私はチームトポロジーに見られるようなチームファーストの考え方に従って、とにかくチームが動きやすくなるような構成を目指していくべきだと考えている。

### 3. とにかくコードを分割する

とにかくコードを分割し、CODEOWNER の設定範囲を広げていく。

コードの分割にはモノレポ管理ツールが役立つ。私が業務で使っている Nx というモノレポ管理ツールでは libs というモジュール群を組み合わせて app を作るというメンタルモデルに則っており、この考え方もコードの分割を後押しする材料になる。
> A common mental model is to see the application as "containers" that link, bundle and compile functionality implemented in libraries for being deployed.
> 
> https://nx.dev/more-concepts/applications-and-libraries

### 4. なぜ自分がレビューしてるのか考える

自動でレビュワーアサインされるようになると、人間のアンチ仕事機能によってこれもレビューしなくちゃいけないのかという気持ちが働く。それにより以下のような気づきを得られるだろう。

* コードオーナー指定されてない箇所があるので、テックリードにレビューが集中している
* ここは別チームをコードオーナーにすべきでは？
* もっといい設計にできればチームで独立して開発できるのに
* このコードは認知負荷が高いので専属チームができたら、別の開発に専念できるのに

この気づきによってコードオーナーの設定だけでなく、コード構成・アーキテクチャ・チーム構成などの改善の機会にもなるだろう。

## おわりに

モノレポ構成でスピードを落とさず開発するために CODEOWNER の設定は必須だと考えているので、小さいところからでも設定していく機会になれば幸いです。

業務でのモノレポ経験は貴重なので、今後もこういったテクニックを紹介していきたい。


モノレポを支える技術 - CODEOWNERS

業務で react-query のリントルールを導入したのでメモ

---

## ESLint Plugin Queryとは

TanStack Query 公式で提供している ESLint Plugin

https://tanstack.com/query/v4/docs/react/eslint/eslint-plugin-query

## 導入

公式で紹介している手順に従うだけで導入できる。
```bash
$ yarn add -D @tanstack/eslint-plugin-quer
```

現時点で提供されている2つのルールのどちらも自動で修正してくれるため、少しずつ移行したいといった理由が無い限りは recommended(両方エラー扱い) にしておいて問題ない。

## Exhaustive Deps

useEffect 等の hooks の deps に依存が発生している変数が含まれていなかった時にエラーにする [eslint-plugin-react-hooks](https://www.npmjs.com/package/eslint-plugin-react-hooks) と同じようなルールを提供する。

```ts
useQuery({
	// queryFn 内で todoId を使っているが queryKey に指定されていないためエラーになる
	queryKey: ['todo'],
	queryFn: () => api.getTodo(todoId)
})
```

キャッシュを無効にしているケースなど queryKey を気にしない場合でも将来のパフォーマンス改善を見越して有効にしておいて問題ないでしょう。

`Dependencies` を `Deps` と略して話したいが `Depth` と勘違いされるリスクがあるので文章だけにしときます。

## Prefer Object Syntax

`useQuery` の引数をオブジェクト形式に強制する。将来的にオブジェクト形式のみサポートする予定とのこと。

これに限らず複数の書き方がある箇所はなるべくリントを使って書き方を統一したい。

---

ほぼ公式で言っている内容なので15分もかからないと思って書き始めたら日本語で言い換えたり文章の校正で1時間以上かかったのでアウトプットの練習は大事だなぁ。。


ESLint Plugin Query

## 2021年にやったこと

### スクラムマスターを5ヵ月間経験
* メンバーだけでは手が回りきらない所をあれこれサポートしていくうちに、段々とふりかえりやプランニングで意見が出にくくなってしまいチームを主体的な行動に導くことができなかったと思う
  * [エンジニアリング組織論への招待](https://www.amazon.co.jp/dp/B079TLW41L/ref=cm_sw_r_tw_dp_06EC7WVQN834F9PAYAKS)を読んで、1on1で個人をメンタリングできるようになってないとチームのメンタリングは難しいということを学んだので、まずは1on1で個人のメンタリングのテクニックを磨きたい

### 引き続きフロントエンドエンジニア
* テックタッチ入社以降やっているフロントエンドエンジニアを続けて3年と9カ月が経過した
* 2020年の後半からReactを触り始め、テストコードを書きながらの通常の機能追加は難なくこなせるようになった
  * 92thunder.dev の開発を続け、ここで実験したことを業務にも活かしたい
* チームの開発体制が変わって、エンジニアも積極的にデザイン（仕様策定）に関わることになり、よりユーザのことを考えながら開発に携わるようになった
  * 元々仕様の検討に入りたかった & 将来的にPdMのキャリアも経験したい自分としてはやりやすい環境になった
* まだ仕事が粗いことがあって品質や開発速度で迷惑をかけることがあった
  * もっと丁寧な開発ができるはずなので、1つ1つの業務を丁寧に積み重ねていきたい

## 将来のビジョン
### 5年
* スタートアップの成長に主体的に携わってどこでも通用する力を持つ
* 北海道で立派な家を持つ
* 起業して自分らしい会社を作って楽しく働く

### 3年
* Webエンジニアとして一人で何でも出来る力をつける
* プロダクトマネージャーになって、ビジネスへの理解を深めプロダクトを成長させる
* テックタッチの上場に主体的に貢献している

## 2022年の目標
* 仕事に集中して上質なアウトプットを出し続けてプロダクトの成長に貢献する
* 急激に人数が増えてきた会社に対して、組織全体の動きが良くなる行動を主体的にやっていく
* インプットを増やして成長するため、毎週ブログを書く、または 92thunder.dev 自体を改善する

2022年の抱負

前回に続き、このブログのデータをFirebaseから自前のMySQLに引っ越ししたのでそれを編集するためのバックエンドAPIを作った。その中で学んだことをまとめておく。

---

## やったこと
* もともとFirabase storeを使っていた[ブログのエディターアプリ](https://github.com/92thunder/blog-editor)を `https://92thunder.dev/api`を使うよう変更
* nginxで `/api` を http://localhost:1323 にプロキシする
* バックエンドAPIをGo言語でEchoというフレームワークを使って実装
* ブログデータをFirestoreからMySQLに愛をこめて手動引っ越し

## ブログエディターの変更
* 保存処理はRepositoryにまとめておいたので影響箇所を少なく抑えられた
* FirestoreからMySQLのフォーマットに合わせた日付の型に変更した
  * JSは日付のフォーマット面倒
* APIクライアントライブラリにkyを使ったがとてもシンプルで良さげだった
  * 後からapiClientにheaderの設定が出来ないなど不便なところもあるのかもしれない

## バックエンドAPIの認証
誰にでもブログをいじれると困るので認証を入れた。今回は[こちらを参考](https://zenn.dev/lapi/articles/2021-06-04-otp_tutorial)にさせてもらってワンタイムパスワードを使った認証にした。ワンタイムパスワードってOTPって略すんだね。

サーバ起動時にOTPのシークレット情報が無ければ、以下のコードでシークレット情報を生成するよう設定した。起動後にシークレット情報を多要素認証アプリに食わせることで簡単にOTPを実装することができた。
```go
key, err := totp.Generate(totp.GenerateOpts{
	Issuer:      "92thunder.dev",
	AccountName: "r.kunisada661@gmail.com",
})
if err != nil {
	log.Fatal(err)
}
SaveSecret(key.Secret(), key.AccountName(), key.URL())
```

サインイン時に発行されるsession_idを使って認証後のAPIを使えるか判定するよう実装した。

## Echo
[Echo](https://echo.labstack.com/)はSinatraとかExpressのような、シンプルなWebフレームワークだった。個人的には慣れない言語でjsonからのデータバインディングしたくないと思ってたのでそれがあるだけで十分な機能だった。
```go
// CORSの設定
e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
	AllowOrigins: []string{"http://localhost:3000"},
	AllowMethods: []string{http.MethodGet, http.MethodPut, http.MethodPost, http.MethodDelete},
})

// 保存リクエスト
func savePost(c echo.Context) error {
	p := new(Post)
	if err := c.Bind(p); err != nil {
		return err
	}
	post, err := SavePost(p)
	if err != nil {
		return c.JSON(http.StatusBadRequest, err)
	}
	return c.JSON(http.StatusOK, post)
}
```

## nginxの設定
nginxの設定はVPSを使った自前構成にしてから一番学びがある。

 
```nginx
# /etc/nginx/sites-available/default
server {
  # _ を含むヘッダーがある場合に必要
  ignore_invalid_headers off;

  # 前方一致にしておかないと正規表現で記述していたnext.js用の設定が勝ってしまっていた
  location ^~ /api/ {
    # 末尾に / がないと、 http://127.0.0.1:1323/api にプロキシしてしまう
    proxy_pass http://127.0.0.1:1323/;
    # これが無いとheaderが削られてしまう
    proxy_set_header Host $host;
  }
}
```

## SystemdでGo APIを起動する
Go APIはデーモン化して起動する必要があるのでSystemdを使って起動するよう設定した。このあたりはISUCONの勉強で学んだことを活かせた！
```service
# /etc/systemd/system/blog-api.service
[Unit]
Description = blog-api

[Service]
User = blog
Type = simple
ExecStart = /home/blog/blog/backend/main
WorkingDirectory = /home/blog/blog/backend
Restart = always

[Install]
WantedBy = multi-user.target
```

```bash
# systemctlに追加したserviceファイルを認識させる
systemctl daemon-reload

# マシンが再起動しても自動実行させる
sudo systemctl enable blog-api

# serviceを開始する
sudo systemctl start blog-api

# ステータス確認
systemctl status blog-api -l
```

---
（´-`）「正月休み+3連休でブログ一通り動くところまで完成できたので良い1年の始まりだなぁ」

本ブログのバックエンドをGo + MySQLで作った

さすがにSPAだとSEO対策やOGP対応できないのでNext.jsに移行した。

---

## やったこと
* とりあえず作ったCreate React App製のこのブログをNext.jsに移行した
* SSGとしてビルドしてVPS上にデプロイしnginx経由でアクセスできるようにした
* このブログアプリはDBの読み込みのみで、ブログの編集に関してはこのアプリではやらず、別のエディターとAPIを用意する（後で書く）

## Next.js 
### getStaticPropsはDBに直接アクセスすればいい
`/pages/api` にDBアクセスするAPIを書いて `/pages` のgesStaticPropsからAPIを呼び出すのかと思ってたが、getStaticProps内で直接DBアクセスすることでデータを取得できた。APIという依存が1つ減っただけでかなりすっきりした実感がある。

### getStaticPathsで動的なルーティングを設定する
どうやって `posts/[id].html` のようなルーティングができるようになるのかと不思議に思ってたら `export getStaticPaths` することで対応できた。
```ts
export async function getStaticPaths() {
  const results = JSON.parse(JSON.stringify(await query('SELECT * FROM post WHERE published = true')))
  const paths = results.map((post: any) => `/posts/${post.id}`)
  return { paths, fallback: false }
}
```

### Serverless MySQL
今回、データはfirestoreからMySQLを使うことにしたので、DBへのアクセスが必要になった。Next.jsからのMySQLクライアントラッパーで一番使われてそうだったので [serverless-mysql](https://github.com/jeremydaly/serverless-mysql) を使った。

Next.jsのサンプルを参考に、薄いwrapperを作成して使いやすくした。
https://github.com/92thunder/blog/blob/main/blog/libs/db.ts

### Material UI 5への対応
Material UIから4から5へ変わっていたがpackage名の変更くらいしか影響がなかった

### SSGのビルド
buildしてからexportすることで静的なHTMLを生成することができる。2GBのVPSだとビルド失敗することあってわりと厳しめ。
```json
  "scripts": {
    ...
      "build": "next build && next export",
    ...
  }
```

## nginxの設定
SPA用の設定だとだめだったので、ここを参考にしてpathに応じてNext.jsのルーティングに対応したHTMLを返すように設定した

https://gist.github.com/zackad/7dd46be60df4fe7d1010a0fcf33d1afc

## 今後やりたいこと
* ブログのエディターにPublishボタンを用意しておき、API経由でSSGを再ビルド
* スタイルがうまくいってないところあるので改善する。。。

本ブログをReact SPAからNext.jsにリプレイスした

ISUCONを経て、サーバを生で運用する経験が欲しくなったのでConoha VPSに移行してみる。

---

## Intro
* FirebaseにホスティングしているこのページをConoha VPSに引っ越す。

## VPSを提供業者の選択
* AWS LightSailもありかと思ったが料金が少し高そうだったので有名どころのさくらかConohaで選ぶ
* Conohaのほうがイメージのバックアップが強そうだったのでConoha使ってみる

## Conoha VPSのサーバ
* なるべく安く済ませたかったが、無難にメモリ2GBのサーバを選択
* 後から気付いたがVPSではなくWINGというやつを選んでもよかったかも

## React SPAのビルド
* ビルド済みの成果物をアップロードする方法でもよかったが、面倒だったので `git clone` してビルドする方法に

### Node.jsのインストール
* nvmで入れた
https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-ubuntu-20-04-ja

## nginxの設定
`/etc/nginx/sites-available/default` を書き換えた。
```nginx
  # appの配置場所
  root /home/blog/blog/frontend/build;
  # 後述のTLS対応のため
  server_name 92thunder.dev;
  # SPAなので /about など任意のページにアクセスがきても404にならないように
  location / {
    try_files $uri /index.html
  }
```

この時点で http://92thunder.dev にアクセスしても https に飛ばされて動かないなーと悩んでたけど devドメインだからHSTSのヘッダーが強制されてしまうからだった。


## HTTPS化対応
CertbotがLet's Encryptをよしなにインストールしてくれるらしい

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04-ja

nginxの設定ファイル見たら勝手に書いてくれてた。すんごい。
```nginx
    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/92thunder.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/92thunder.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
```
無事に https://92thunder.dev に設定された！

## Outro
* やろうと思って何ヵ月も放置したけどやってみると簡単にサーバにデプロイできた。
* [DigitalOcean](https://www.digitalocean.com/)先生が日本語でも読めるドキュメント残してくれてて最高に助かった。救われる人多いはず。
* 引き続きバックエンドAPIやDBも脱Firabaseする。

本ブログをVPSに引っ越しする

まずは過去問の講評に書いてあることを出来るようにならねばということで別インスタンスのDBが動作するよう変更してみる。去年挑んだのと同じ問題だが力になれなかった悔しさを胸に。。

---

今回の目標は[ISUCON10予選の講評](https://isucon.net/archives/55025156.html)に書かれているこいつができるようになること。
> estate と chair で DB を別サーバに分ける
![](https://livedoor.blogimg.jp/isucon/imgs/b/6/b6873eb6-s.png)

## AWSインスタンス２つ目起動
前回同様 m3.medium のインスタンスを起動。同一VPC内に起動しているようなので繋がるはず。
MySQLのクライアントが接続できるように、ポート3306を公開。

## Dataの用意
[前回](https://92thunder.dev/blog/da8906ea-42b1-4940-8d53-cc1522645250) でやった手順で同様に、initial-data は別のインスタンスで用意する必要があった。同じように `make` で初期データをDBに登録する。本番は初期データも入っている状態だと思うのでこの手順は不要だと思われる。

## pingが通らない
調べた結果、EC2インスタンスにpingを通したければICMPをセキュリティグループに設定する必要があるらしい。  
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-ping

## 接続先変更
DBインスタンス
* sudo systemctl stop isuumo.go.service

Appインスタンス
* env.sh を編集してMYSQL_HOSTをインスタンス2のプライベートIPに変更
* sudo systemctl stop mysql.service
* sudo systemctl restart isuumo.go.service

WebAppをブラウザから確認。API動いてない。。。benchも失敗する。。。

## MySQLの外部公開
参考にした。  
 https://qiita.com/2019Shun/items/34d44d63b00d086db51a

/etc/mysql/mysql.conf.d/mysqld.cnf を編集
```
bind-address                    = 0.0.0.0
```

## MySQLのユーザを外から接続できるよう変更
一緒にISUCON参加予定のメンバーから教えてもらった。これでISUCONユーザがlocalhost以外からでも接続できるようになる。
```
GRANT ALL PRIVILEGES ON *.* TO 'isucon'@'%' WITH GRANT OPTION;
select user, host from mysql.user;
```
これで再起動して動くようになった。

## benchちょっと改善
`{"pass":true,"score":191,"messages":[],"reason":"OK","language":"nodejs"}`  
↓  
`{"pass":true,"score":232,"messages":[],"reason":"OK","language":"nodejs"}`

とりあえず App と DB　のインスタンスを分離できた。chair, estateを分離するまではできなかったが、同様の手順でやって、App に複数 MySQL を接続できるように変更すればできるだろう。

ISUCON10予選の過去問練習-2 App-DBを別インスタンスに

ISUCONの過去問(isucon10-qualify)をAWS上で構築するのに手こずったのでメモ

---

@matsuu さんがAWSのIAMを用意してくれている。神。
https://github.com/matsuu/aws-isucon

今回はISUCON10予選を練習するのでEC2インスタンス起動から ami-03bbe60df80bdccc0 を検索して、何も考えずt2.microで起動すると厳しかったのでm3.mediumで起動。起動しっぱなしなだと結構高そうなのでこまめに停止せねば。

他のメンバーにもアクセスしてほしいので新規キーペアを作成し、SSHでアクセス。
```bash
ssh -i "isucon11.pem" ubuntu@ec2-XXXXXXX.ap-northeast-1.compute.amazonaws.com
```
### initial-data設定

書いてある通り順に実行
```bash
pip3 install -r requirements.txt
go get github.com/orisano/wayt
make
```
docker-composeが入っていないみたいだったのでインストール
```bash
sudo apt install docker-compose
# isuconユーザではdockerの権限がなかったのでgroupに追加
sudo gpasswd -a $USER docker
exit
sudo -i -u isucon
```
mysqlのserviceが起動しているため停止
```bash
sudo systemctl stop mysql.service
```
wayt http -u "http://localhost:1323/api/estate/search/condition" から進まなかったので一度goのwebappを起動
```bash
cd webapp
make isuumo/go
```
もう一度実行したらいけた
```bash
make
```

### 実装をnodejsに切り替え
nodejsで起動
```bash
sudo systemctl disable isuumo.go.service
sudo systemctl enable isuumo.nodejs.service
```

### ec2-XXXXXXX.ap-northeast-1.compute.amazonaws.com で起動を確認
セキュリティグループを編集しポート80番を公開

isuumo動いてる。ヨシ！

### bench動かしてみる
いろいろあったがなんとか動いたぞ。
```bash
./bench -target-url http://localhost:1323
2021/07/25 02:56:14 bench.go:78: === initialize ===
2021/07/25 02:56:19 bench.go:90: === verify ===
2021/07/25 02:56:23 bench.go:100: === validation ===
2021/07/25 02:57:23 bench.go:102: 最終的な負荷レベル: 0
{"pass":true,"score":189,"messages":[],"reason":"OK","language":"nodejs"}
```




ISUCON10予選の過去問練習-1 AWSで環境構築

なかなか実際の方法に辿り着けなかったのでメモ。

以下の手順通りに、Google Cloud Platform上で allUsers に対して Storage オブジェクト閲覧者 を設定する。

https://cloud.google.com/storage/docs/access-control/making-data-public?hl=ja


このURLからアクセスできる

`https://storage.googleapis.com/[bucket.appspot.com]/[path]`

firebase storage で ファイルをパブリックアクセス可能にする

ブログを作るにあたって、自分のみ書き込みできるようにしたかったのでその方法をメモ。

---

Authentication を使ってログイン後、Console からUIDを確認し、条件を設定する。

```js
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read;
      allow write: if isValidUser();
    }
  }
  function isValidUser() {
    return request.auth.uid == 'UIDを設定'
  }
}
```



firestore で特定ユーザのみ書き込み可能にする

systemctlを使ってredis-serverを起動させようとすると `System has not been booted with systemd as init system (PID 1). Can't operate.` と言われて怒られてしまう。

---

ここに書いてある通り、今のところ WSL2 では systemd が使えないらしい。
[https://github.com/MicrosoftDocs/WSL/issues/457#issuecomment-511495846](https://github.com/MicrosoftDocs/WSL/issues/457#issuecomment-511495846)

頑張れば使えるみたいだが諦めた。

[https://qiita.com/matarillo/items/f036a9561a4839275e5f](https://qiita.com/matarillo/items/f036a9561a4839275e5f)

普通に `sudo /etc/init.d/redis-server start` で起動することができた。

systemdがProcess ID 1じゃないと起動しないってどういう経緯の制限なんだ…。

WSLでsystemctlが使えない

JSFiddleやCodePenだとTypeScriptのサポート受けられないのでサクッといい感じに書けてブログなどで共有できるものが欲しい。StackBlitzとCodeSandboxの２択っぽいのでその２つについて調べたことをまとめておく。

---

## StackBlitz

- React TypeScriptのサンプルプロジェクト
    - [https://stackblitz.com/edit/react-ts-envuum](https://stackblitz.com/edit/react-ts-envuum)
- 無料プランでPublicプロジェクトは無制限 & GithubのPublic Repoとも接続できる
- 見た目はほぼVisual Studio Codeと同じだがExtensionの追加はまだできなさそう
    - [https://github.com/stackblitz/core/issues/3](https://github.com/stackblitz/core/issues/3)
    - 個人的にVim Pluginが無いのはちょっとマイナスポイント
- 設定は VS Code と同じ方法でできるので拡張いらないくらいの用途なら問題なさそう

## CodeSandbox

- React TypeScriptのTemplate
    - [https://codesandbox.io/s/react-ts-template-rlhgd](https://codesandbox.io/s/react-ts-template-rlhgd?file=/src/App.tsx)
- Preferences > Appearance からVim extensionを有効にできる
- こちらもpublicは無料だがprivateは有料プラン
- Live機能がついており、Classroom modeと共同編集モードが選べるようになっていてちょっとした共有にはとても便利そう

## まとめ

- 現段階では Vimサポートもある CodeSandbox 一択かな
- styled-components など CSS in JS なものだとうまくエディターに表示されないんだろうけどTypeScript × Reactの機能を試すにはこれらで十分そう

## おまけ

Visual Studio Codespaces

- [https://azure.microsoft.com/ja-jp/pricing/details/visual-studio-online/](https://azure.microsoft.com/ja-jp/pricing/details/visual-studio-online/)
- Azureと契約する必要あるので避けたくなってしまうが思っていたほど価格は高くなさそう

React & TypeScriptのサンプルコードをどこに書くか

以前にもあったNOTION_TOKENの期限切れ？かなと思っていろいろ試したがなかなかなおらなかったのでメモ

---

Vercel の settings/environment-variables で NOTION_TOKEN, BLOG_INDEX_ID を設定しなおしてもだめで、最終的には now CLI から設定値の名前を-つなぎで設定しなおしたら修正できた様子（本当か？）

```bash
now login
now secrets add notion-token [NOTION_TOKEN]
now secrets add blog-index-id [BLOG_INDEX_ID] 
```

Notion Blogで There are no posts yet になる

Reactの使い方シリーズ（新）

ReactのContextをhooksとして扱うuseContextをどうやって使うのかメモ。

---

## Context

下位のコンポーネントにPropsではなくContextを経由してデータを渡すことができる。コンテキストって読みたくなるけどReactのドキュメントではコンテクスト。

[コンテクスト - React](https://ja.reactjs.org/docs/context.html)

## 使い方

React.createContextで作成したContextをProviderで任意のコンポーネントツリーから使用できる

SettingsをContextとして共有する.tsx

```tsx
// React.createContextでContextを作る
// changeThemeなどの振る舞いもここで定義可能
const SettingsContext = React.createContext<{
  theme: "light" | "dark"
  language: "ja"
}>({ theme: "light", language: "ja" })

// React.useContextでcontextを取得する
const useSettingsContext = () => {
  // そのままuseContextを各コンポーネントから使うだけでは値の変化を追えない
  const context = React.useContext(SettingsContext)
  if (!context)
    throw new Error("useSettingsContext must be used within SettingsProvider.")
  return context
}

// Context.Providerを使ったコンポーネントでProviderを作り、Contextで共有するvalueを使う
// 直接SettingsContext.Providerを使う方法でもよいが、この方法では初期値をSettingsProviderで設定している
const SettingsProvider = (props) => {
  // パフォーマンス向上のためメモ化しておく
  const value = React.useMemo(() => ({
    theme: "dark",
    language: "ja"
  }))
  return <SettingsContext.Provider value={value} {...props} />
}

const Settings = () => {
  // SettingsProviderの中のコンポーネントではuseSettingsContextで設定値を取得できる
  const settings = useSettingsContext()
  const lang = settings.language
  const theme = settings.theme
  return (
    <>
      <p>{lang}</p>
      <p>{theme}</p>
    </>
  )
}

const App = () => {
  return (
    <SettingsProvider>
      <h1>React useContext demo</h1>
      <Settings />
    </SettingsProvider>
  )
}

ReactDOM.render(<App />, document.querySelector(".app"))
```

[React] useContextの使い方

2018年4月からスタートアップに転職し、Webフロントエンドの開発を担当している。現職に入社してからの日々のことと今の気持ちを書き残す。

## なぜスタートアップに転職したか

過去のブログに真面目な事を書いていると思うが、自分では恥ずかしくて読めない。
https://92thunder.hatenablog.com/entry/2018/05/18/230619

## それから2年

創業1ヶ月後に入社した会社は、当時共同創業者2名と自分の3人だけだった。シェアオフィスの一部屋を借り、机3つとホワイトボードしかない部屋で最初のリリースに向けて開発を進める日々だった。

それから2年が経ち、社員数は20名を超え、5億円のシリーズA資金調達を実施できるまでに成長した。

プロダクトのアイデアに恵まれたのが、なにより幸運だったと思う。最初のプロダクトのアイデアを一緒に検討することができたのはとても良い経験になった。自分自身が欲しいと思うプロダクトの形を目指して開発できており、同じくこのアイデアに賛同して入社を決めてくれる人も少なくない。展示会で製品デモをする時には、毎回お客さんのウケが良く、みんなに必要とされている製品なんだなと感じる。

プロダクトの性質上、ブラウザのWeb APIには必然的に詳しくなった。0→1だけでなく1→10, 100に長期開発していく中で、スピードを落とさずに開発を進めていくことが求められるため、設計の技術も身につけることができている。最初は基本的に自分だけで考えて進めていたが、今は相談相手も多いので、最善の開発をチームで深く考えながら進められている。最近では開発チームのテックブログも自分主導で立ち上げ、開発以外でもチームの醸成を感じている。

人数が増えると組織の形も変わる。個々人が得意分野で力を発揮し、全員で会社を成長させている感じがして居心地がいい。組織づくりってどう進んでいくんだろう？なんて思ってたが、目の前で行われている1つ1つの話し合いが組織づくりなんだと気づく事もあった。

BtoB向けに提供しているため、不具合調査や製品デモでSalesやCSチームと客先に同行することもある。泥臭く不具合の原因を調査し1つずつ潰していくこともあるが、CSと連携してクイックに対応できているのでストレスは特にない。実際にお客さんの反応を見て、機能開発の優先順位決めをしたり、ユーザの顔を思い浮かべながらUIの議論をしていくことも多い。

Bizチームの状況はSlack上でなんとなく把握している他にも、Customer Journey Mapを元に問題点の洗い出しを行い、どんな仕組みづくりが必要かという話にも参加できているので、開発側だけでなくBiz側の成長も断片的には見ることができていると思う。

普段はスタートアップだからどうこうということを強く意識することはなく、開発だけに集中させてもらっている。スタートアップでやっている実感が湧くのはやはり資金調達のタイミングだ。資金調達実施後には、自分たちの現在地を認識し、前の調達からこれだけ成長できていて、次回の調達ラウンドではN倍にも会社を成長させる必要があるという確認をする。

## 今後

現職に入社してからの日々のことを書き殴ったが入社前の思惑通り、自分は今、東京で、スタートアップで、濃い経験ができていると思う。自分が書いたから言うけど、みんな転職エントリばっかり書かないでこういう振り返りをちゃんとしていけよなと思う。引き続き、もっと価値あるプロダクトを作りつつ、会社とともに高みを目指したい。


スタートアップに転職して2年が経った

仕事でReactと一緒に使い始めるのでどんなことができるのか調査したことをまとめておく。最高っぽい。 

---

## Nxとは

[https://nx.dev/](https://nx.dev/)

- lernaやyarn workspaceのようなJSのmonorepo支援ツールの一つ
- CLIやeditor pluginによってdev experienceが向上する
- コード共有の制御とコード生成ができる
- コードの変更による影響範囲を把握しておくことで、コミットの度に必要なものだけをビルド＆テストできる
- キャッシュを使うことで全てのコードをスクラッチビルド、テストしないことで時間を大幅に削減する
- TypeScript, React, Angular, Cypress, Jest, Prettier, Nest.js, Next.js, Storybook, Ionixなどをサポートしておりツールに関わらず一貫したDXを提供する
- 元はAngularからサポートからReactに派生しているのでAngularのCLIの影響を受けていそう

## 使い方

普段よく使うコマンド 

### `nx affected:test --base=origin/master`

- origin/masterとの差分を見て影響のある部分のみテストする
- build, lintなどもaffected:をつかて影響範囲のみ実行できる

### `nx run project:target`

- projectはpackage名でtargetはコマンド（ `nx run myapp:build` のような使い方)
- build, test, lintなどは `nx build myapp` でも同じことができる
- 各パッケージでpackage.jsonのscriptsを書くかわりに、workspace.jsonに定義されているコマンドを実行する

### `nx generate <collection:schematic>`

- schematicから新しいpackageを生成する
- 後述のNx Consoleを使うことでschematic名やオプションを覚える必要はなくなる

### `nx dep-graph`

- 各package間の依存グラフを生成する

### Nx Console

[https://nx.dev/react/cli/console](https://nx.dev/react/cli/console)

- Nxを専用UIでサポートするVS Code拡張
- Schematic（generateコマンドなどの設定値を定義したやつのこと）のカスタム要素を一覧し見やすくしてくれる
- フラグやパスの入力を補完してくれる
- 適切なNxの拡張を見つけやすくする

## Nx Cloud

- Nxを使ったサービスで、ビルドやテストのキャッシュをクラウドに保存しておくことで、メンバーはローカルで0からビルドしなくても、そのキャッシュをダウンロードすることでより高速なDXを得られるというものらしい

> 10x開発者は神話かもしれないが、10xビルドパフォーマンスは現実です
(10x Developers May Be a Myth, but 10x Build Performance is Real)
> 

なるほど

Nxについて調べてみた

ここでlimitが100に設定されていた

[https://github.com/ijjk/notion-blog/blob/ec8ca69795dec252074ec31da94868e0b4b6130a/src/lib/notion/getPageData.ts#L22](https://github.com/ijjk/notion-blog/blob/ec8ca69795dec252074ec31da94868e0b4b6130a/src/lib/notion/getPageData.ts#L22)

1000に変えてみたが今の所問題なさそう

---

ついでに調べたこと

- [https://notion-blog.now.sh/](https://notion-blog.now.sh/) に従ってブログを作るとnotion-blogのリポジトリをimportして作ることになるので、本家の更新に追従しようとすると、rootのコミットも別物になっているため、 `git merge --allow-unrelated-histories` した結果コンフリクトだらけで面倒になる
    - 最新のNext.jsに更新したかったがコンフリクトが多かったため時間あるときに頑張る
- 現状のNotion Blogは公式のAPIを使っているわけではなく、Notionで使っているAPIと同様のものを呼び出しているだけの様子
    - APIが完成したらちゃんとしたドキュメントができてNotion Blogでも使われるようになるんだろう
    - [https://github.com/ijjk/notion-blog/issues/19](https://github.com/ijjk/notion-blog/issues/19)

Notion Blogが途中までしか表示されない

2020/5/29に会社の勉強会で発表した内容をブログとしてまとめなおす。

---

## 経緯

- 最近ちゃんと勉強しようと思ってnrslibさんのドメイン駆動設計入門を読み始めた
    - [https://twitter.com/nrslib](https://twitter.com/nrslib)
    - [https://www.amazon.co.jp/gp/product/479815072X/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=jikyu860yen-22&creative=1211&linkCode=as2&creativeASIN=479815072X&linkId=d6c9781814cfce27eed2943ef5c79524](https://www.amazon.co.jp/gp/product/479815072X/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=jikyu860yen-22&creative=1211&linkCode=as2&creativeASIN=479815072X&linkId=d6c9781814cfce27eed2943ef5c79524)
    
    [nrs](https://twitter.com/nrslib)
    
    [ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本](https://amzn.to/2XIby0i)
    
- 2月に参加したObject Oriented ConferenceでDDDに興味を持ち始めた
- 2020年5月29日時点の知識でドメイン駆動について会社の勉強会で発表した内容をブログとしてまとめる

## ドメイン駆動設計=DDDとは

松岡さんのブログよりDomainlanguage.comの引用

[ドメイン駆動設計の定義についてEric Evansはなんと言っているのか[DDD] - little hands' lab](https://little-hands.hatenablog.com/entry/2017/09/27/014403)

1. **ドメインの中核となる複雑さと機会に焦点を当てる**
    - これがもっとも重要な考え方。下はドメイン駆動設計で用いられる代表的なテクニック。
2. ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
3. 明示的にそれらのモデルを表現するソフトウェアを書く
4. 境界付けられたコンテキストの中のユビキタス言語で話す

### ドメインとは

![](https://lh3.googleusercontent.com/pw/AM-JKLXzp3p3sarDH9SnogwnSf4U62OtumPSWtfrQaG1_FvN2T76O9Hb-ab-bQSJ48ljgfYAjlF6jSdPkHvLuxSfT19d7xs6tVhoRgD9Bb99EEogjmfvK4_E9Oxr7KX-lurwpOF1SSHKGCr48ZmBfz58ScJQ=w722-h207-no?authuser=0)

よくわからんけど領域が近そう🤔

勤怠システムのドメイン（領域）にはこのような概念がある

- 従業員
- 勤務時間
- 有給

テックタッチだと

- ガイド、ステップ

ソフトウェアの目的は問題の解決

- **ドメインの概念を正確に理解し、問題の解決に役立つ知識をソフトウェアに反映することが重要**
- ソフトウェアを開発する上で当たり前の行為とも言える

**ドメイン駆動設計 = ドメインの知識に焦点を当てる設計手法**

（なんでドメインって言うんだろうね…）

## ドメインモデル、ドメインオブジェクトとは

- ドメインモデル：概念を理解し、問題解決に役立つ知識を抽出したもの（モデリング）
    - ガイド：操作方法を教えてくれる
        - ガイドには複数ステップがある
        - タイトルが何文字まで
        - リダイレクト設定がある
- ドメインオブジェクト：ドメインモデルをソフトウェアで動作するモジュールとして表現したもの

ドメイン駆動設計では、ドメインの概念・ドメインモデル・ドメインオブジェクトを行き来しながらドメインの理解・ドメインの実装を繰り返す

## 戦略と戦術

### 軍事用語の戦略と戦術

戦略：戦いに勝つために兵力を総合的・効果的に運用する方法で、大局的・長期的な視点で策定する計画手段

戦術：戦いに勝つための戦地での兵士の動かし方など、実行上の方策

### DDDの戦略と戦術

**戦略：ドメインを理解し、それをモデルに落とし込む**

- ユビキタス言語
- ドメインモデリング

**戦術：具体的な実装パターン**

- エンティティ
- バリューオブジェクト
- リポジトリ
- アーキテクチャ

## 軽量DDDとは

- DDDの中で戦術のみ、実装パターンだけを取り入れる手法は軽量DDDと呼ばれている
- 軽量DDDだけなら開発チームだけで完結可能
- ネガティブに捉えると、DDDの本質はドメインに向き合うことなので戦略のほうが重要なのでこの状態はあまりよくない
- ポジティブに捉えると、DDDの導入として形から入ることは重要　ドメインに向き合うきっかけになる

## ユビキタス言語

ステークホルダー間で認識の齟齬や翻訳にコストをかけないために共通言語を使う

ユビキタス=いつでもどこにでも存在する

IoTのことユビキタスコンピューティングって呼んでる時代あったよね

ドメインエキスパート「ユーザを登録する」

- ドメインの言語で話す

開発者「ユーザを新規保存する」

- 開発寄りの言葉を選びがち

ドメインエキスパートの言葉をそのまま使うということではない。

システムにもドメインにも寄り添ってユビキタス言語を作っていく

## モデリング

一般的な昔ながらの方法

- ユースケース図
    - アクターから見たアプリケーションのユースケースを図にしたもの
    - 一般的なUMLのユースケース図と同じ
- ドメインモデル図
    - クラス図の簡易版
    - 代表的な属性だけ記述してメソッドは不要
    - ドメイン知識（業務のルール・制約）を吹き出しで記述する
    
    [https://www.slideshare.net/koichiromatsuoka/202038](https://www.slideshare.net/koichiromatsuoka/202038)
    

最近はRDRA2.0という手法が流行っているみたい

![](https://lh3.googleusercontent.com/pw/AM-JKLUbWCy4ax3xDMMAEewU5ncN2AsPG2Sn61x0e0Xn0iTwNq0rUbHqjKYxmr4wEkMnBJgQaBewoAD467u8rqX93RSq-rdLbh4KGoMoLnQ8LZxF4wjk3RqLuqdKb32fx8nMcKe9ItsSi_2a9zNAV6z_4ZvB=w767-h553-no?authuser=0)

## ドメインオブジェクト

### ValueObject　値オブジェクト

- プログラミング言語に用意されているプリミティブな値をそのまま使うのではなく、システム固有の値を表すオブジェクトにしたもの
- 使うことでドメインオブジェクトの語彙を増やすことができる
- 例えば
    - 氏名
    - 電話番号
    - ガイドタイトル

```tsx
class FullName {
	constructor(fistName: string, lastName: string) {
    this.firstName = firstName
    this.lastName = lastName
  }

	equals(fullName: FullName) {
    return this.firstName === fullName.firstName && this.lastName === fullName.lastName
  }
}
```

- ValueObjectの性質
    - 不変である
        - changeNameのような操作はない
    - 交換が可能である
        - 属性を変化するときは再代入しなおすことで表現する
    - 等価性によって比較される
        - 全ての属性が同じである = 等価

### Entity　エンティティ

- 値オブジェクトもエンティティもドメインオブジェクトだが、大きな違いは同一性を持っているかどうか

```tsx
class User {
  id: string
  fullName: FullName
  
  constructor(fullName: FullName) {
		this.id = createId()
    this.fullName = fullName
  }

  changeName(fullName: FullName) {
    this.fullName = fullName
		// return new User(fullName)
  }

  equals(user: User) {
    return this.id === user.id
  }
}
```

- Entityの性質
    - 可変である（コードの書き方の好みによって違いそう）
        - 値オブジェクトは不変だったがエンティティは属性が変わりうる
    - 同じ属性であっても区別される
        - 同姓同名の人がいるように、同じ属性をもっていても別の個体だと認識する必要がある
    - 同一性を持つ
        - ユーザ名が変わったとしても同じユーザとしてみなされる

## リポジトリ

- ドメインオブジェクトの永続化が責務
- リポジトリとして永続化、復元を管理するだけでとてもシンプルなコードになる
- 基本的にはfind, save, deleteの3関数になるパターンが多い
- IUserRepositoryというインターフェイスを作っておくことで、IUserRepositoryに従ったUserMemoryRepositoryを作ればテストしやすくなる

```tsx
class UserRepository implements IUserRepository{
  find(name: string) {
    // SELECT * FROM USERS WHERE name....
  }
  
  save(user: User) {}
  delete(user: User) {}
}
```

なぜドメイン駆動でリポジトリが出てくる？

- たしかにドメインとはちょっと離れた存在
- ドメインオブジェクト単位でリポジトリを管理することでドメインがコードの中で際立つ
    - ガイドの保存はGuideRepositoryでやってるはず
    - Repositoryの中でガイドの保存部分を探して…

## アプリケーションサービス

- ドメインオブジェクトを協調させてユースケースを実現する
- サービスは状態を持たない
- 例
    
    ```tsx
    class UserService {
      repository: IUserRepository
    
    	constructor(repository: IUserRepository) {
    	  this.repository = repository  
    	}
    
    	register(name: string) {
        // ユーザ名の制約に引っかかると例外を投げる
    		const user = new User(name)
    
    		if (await this.repository.find(name)) {
    			throw new Error('重複してます')
    		}
    
    		this.repository.save(user)
      }
    }
    ```
    

## アーキテクチャ

- DDDでよく登場するアーキテクチャは３層＋ドメインの構成が基本
    - Presentation(UI, Controller)
    - Service(Usecase)
    - Infrastructure (Repository, DB, API
    - Domain
- アーキテクチャの役目
    - レイヤーわけしてどこに何を書くべきかという方針を定める
    - ソフトウェア特有の事情からドメインオブジェクトを防衛する
- これらのアーキテクチャがあるが共通点として、どれもドメインオブジェクトを防衛するための仕組みを考えている
    - レイヤードアーキテクチャ
    - ヘキサゴナルアーキテクチャ
    - クリーンアーキテクチャ

## 気持ち

- 要件定義→仕様→設計→実装　⇒　ドメイン↔ドメインモデル↔コード　という変化
    - それぞれの境界の継ぎ目をなくす
    - 反復的に繰り返すことで洗練していく
- DDDをやっていくには、全員でドメインに向き合う意思を統一し、やっていくための仕組みを作り、反復的に繰り返す必要がある
- 全てはソフトウェアの発展性を良い状態で維持するため

## 参考資料

- [https://DomainLanguage.com](https://domainlanguage.com/)
- [https://speakerdeck.com/hirodragon112/flyweight-ddd](https://speakerdeck.com/hirodragon112/flyweight-ddd)
- [http://tlync.hateblo.jp/entry/2016/12/25/171648](http://tlync.hateblo.jp/entry/2016/12/25/171648)
- [https://github.com/little-hands/ddd-q-and-a](https://github.com/little-hands/ddd-q-and-a)

ざっくりわかるドメイン駆動設計

人はどうして３日で書かなくなるとわかっていてもブログを立ち上げることをやめられないのか。

NotionをヘッドレスCMSとして使えるNext.js製テンプレートができたということで早速試してみたので感想をまとめる。

---

## ブログのデプロイ

ブログのデプロイ自体はzeitアカウントを作ってGithub連携し、デプロイボタンを押してポチポチ進めていけば一瞬でブログが立ち上がる
[https://github.com/ijjk/notion-blog#deploy-your-own](https://github.com/ijjk/notion-blog#deploy-your-own)

ここに上がっているのと同じものが出来上がる
/blogのページにNotionで書いたPageが追加されていく
[https://notion-blog.now.sh/](https://notion-blog.now.sh/)

- Notion BlogではNext.jsのcanaryリリースを使ってSSGサポートなど導入予定の機能を使っている
    - SSR(server-side rendering)に対してSSG(static-site generator)というらしい…
- 雰囲気で押したデプロイボタンによってGitHubにクローン & ZEITにプロジェクト追加 & now.shにデプロイが行われて便利
[https://zeit.co/docs/v2/more/deploy-button](https://zeit.co/docs/v2/more/deploy-button)
    - Markdownにも対応しているのでGitHubのREADMEに置いとけばすぐに誰かのテンプレートをデプロイできる。よく考えられてる…
- これはカスタマイズ後だが、たしかにスコアはいい感じ
    
    ![](https://lh3.googleusercontent.com/pw/AM-JKLVdVhzMAleYv6m0PUVBpuGRmaT_VwLRDO-wLmmz-FjTZrc-Mi12-UWe2g1LGUtyDcR2038gjDzBQmUEO5unnvF0AejVZHu5DA5XcrdGT1Fxc4WwHaXVw5ZfdxiuFLNV-dC92TUTj-W2cEvzubNjGRNL=w615-h148-no?authuser=0)

## 独自ドメイン設定

- ZEITプロジェクトのドメイン設定ページから [blog.92thunder.dev](http://blog.92thunder.dev) を追加して、表示に従ってTXT, CNAMEレコードを設定するだけだったのでわかりやすくてよかった

## カスタマイズ

- 要らないものを削って色を変更しただけ
[https://github.com/92thunder/notion-blog/tree/7bd4f164f9aaf07f85c138c433f5f3f4e8c3b59c](https://github.com/92thunder/notion-blog/tree/7bd4f164f9aaf07f85c138c433f5f3f4e8c3b59c)
    
![](https://lh3.googleusercontent.com/pw/AM-JKLVEcy8yLMQcoVbhvUBCL493cXPa9IYEKHDSHMsit2dyDsibzdflfcaF0hBe_eUZy0dF1gCWEZacYsiKV7g6x8m6Up_6iPsplZ_IQSQpZ3G7khWEe5qZOtWGujzIK8vK1d-kOWtQWQRgrcR5jvIVBFFq=w725-h289-no?authuser=0)
    
- backgorund-color変更など、細かいCSS調整
    - global.cssの先頭にCSSの変数で色が定義されてるが、それを変えただけでは変わらない部分がある
    - なぜかh2が小さくなるスタイルがあったので修正
- トップページ、contactページ、ヘッダーメニュー、フッターのデプロイボタンはとりあえず要らないので削除
    - Reactﾁｮｯﾄﾃﾞｷﾙくらいでも簡単に変えられるのでNext.jsよさげ
- 本格的なブログ運用を始めるには最初はかなり頑張りが必要そう。頑張りたくなければはてなブログなどを検討すべき

## 実際にNotionで書いてみて

- Notion使い始めて１週間だが書きごごちは悪くないし使いやすいので投稿の敷居も低くなりそうなのでNotionをヘッドレスCMSとして使えるのは良い
    - （元々会社では別のドキュメントツール使ってたがNotion派閥が大きくなったので公式ドキュメントツールが先週変わった）
- 文字の色変更が効かない・Dividerが出ないなどはあるが、Tech Blogだと大きく困ることはなさそう
    - Notionのblock(?)ごとにswitch-caseで描画している
    [https://github.com/ijjk/notion-blog/blob/625463ea822f4acf65c79088a34a4eefc7909c4f/src/pages/blog/[slug].tsx#L155-L252](https://github.com/ijjk/notion-blog/blob/625463ea822f4acf65c79088a34a4eefc7909c4f/src/pages/blog/%5Bslug%5D.tsx#L155-L252)
- Reactのエコシステムを考えればレンダリングのコンポーネントが充実するのはそんなに遠いことではなさそう
- ブログをどこに書こうか悩んでてReactでメンテできるブログが欲しい、Notionを使いたいなどがマッチしていればNotion Blogはいい選択肢だと思う

Notion Blogを使った感想

趣味のVのやつでslackにyoutubeのチャンネル登録者数とかtwitterのフォロワー数やらを通知するやつを実装したのでメモ。  
今回はNode.js + AWS Lambda + slack Incoming Webhookを使って実装。AWSアカウントはLambdaでバッチスクリプトを実行させるだけになってきたな…。

# Youtubeのチャンネル登録者数、総再生回数を通知

## APIキー取得
こちらを参照してAPIキーを取得する  

* https://developers.google.com/youtube/registering_an_application

## slack Incoming webhookからエンドポイントを取得
ここにYoutube, TwitterのAPIから取得した数値をPOSTしてやる  
参考にしました
* https://qiita.com/ik-fib/items/b4a502d173a22b3947a0

## チャンネル登録者数を取得しslackに通知
`GET https://www.googleapis.com/youtube/v3/channels` で取得する  
ドキュメント⇒ https://developers.google.com/youtube/v3/docs/channels/list
  
チャンネルの統計情報が欲しかったのでpartには `statistics` を指定

```javascript
const request = require('request')

module.exports.handler = () => {
  const options = {
    method: 'GET',
    url: 'https://www.googleapis.com/youtube/v3/channels',
    qs: {
      part: 'statistics',
      id: 'XXXXXXXXXXXXXXXXXX',
      key: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXX'
    } 
  }
  
  // 上記設定値でyoutubeからチャンネル登録者数、総再生回数を取得
  request(options, function (error, response, body) {
    if (error) throw new Error(error)
  
    const data = JSON.parse(body)
    const subscriberCount = data.items[0].statistics.subscriberCount
    const viewCount = data.items[0].statistics.viewCount
    
    // slackに通知
    request.post({
      uri: 'https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXX',
      headers: { 'Content-Type': 'application/json' },
      json: {
        text: `チャンネル登録者数: ${subscriberCount}人\n総再生回数: ${viewCount}回`
      }
    }, function(error, response, body) {
      if (!error && response.statusCode === 200) {
        console.log(body)
      } else {
        console.log('error')
      }
    })
  })
}
```

いつも自分はこういう時Postmanから好きな言語のソースコードを出力している。  
Node.jsだとrequestモジュール使うのがおすすめ  
https://learning.getpostman.com/docs/postman/sending_api_requests/generate_code_snippets/

後はAWS Lambdaの関数として配置して毎日実行されるようにCloud Watch eventをトリガーとして設定すればOK

# Twitterのフォロワー数を通知

## TwitterのAPIキーを取得
参考にしました
* https://qiita.com/y_ishihara/items/501bb6fddc785a56780e

## フォロワー数を取得しslackに通知
楽そうだったのでtwitterのライブラリを使用した  
`GET /users/show` でTwitterのscreen_nameから情報を取得する  
https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-users-show.html

```javascript
const Twitter = require('twitter')
const request = require('request')

module.exports.handler = () => {
    const client = new Twitter({
        consumer_key: '最近',
        consumer_secret: '趣味で',
        access_token_key: 'Vtuber作ってるので',
        access_token_secret: '動画編集できるようになってきた'
    })

    const params = { screen_name: 'realDonaldTrump' }
    client.get('users/show', params, (error, user) => {
        if (!error) {
            // slackに通知
            request.post({
                uri: 'https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXX',
                headers: { 'Content-Type': 'application/json' },
                json: {
                  text: `${user.name}(${user.screen_name})のフォロワー数は${user.followers_count}人です`
                }
              }, function(error, response, body){
                if (!error && response.statusCode === 200) {
                  console.log(body)
                } else {
                  console.log('error')
                }
            })
        }
    })
}
```




slackにyoutubeのチャンネル登録者数やtwitterのフォロワー数を通知する

We Are JavaScripters! @23rdで発表してきた。

勉強会で発表した資料をブログに貼り付けるのは楽でいいなー

https://slides.com/kunisada/deck

Chrome拡張とFirebaseで作るチャットアプリ

仕事で使いそうだったので素振り

https://jsfiddle.net/92thunder/1km9Lt84

ホバーしたエレメントにハイライトを当てる

4月からスタートアップに転職して1ヶ月が経ったので感じたことなど。
溜めておくといつまでも書かないので雑に書く。

## 転職した理由
* スタートアップに挑戦したかったから
* 人生で一番元気であろう20代を熱中する価値のあるものに注ぎたかったから
* バイトしていて、やっていけそうな雰囲気だと思ったから
* SOではなく株貰えたから
* タイミングよく会社立ち上げ時にジョインできたから

## 転職して
* 自分のデスクでVue.jsでフロントエンド書いてるだけなので作業自体は転職前とあまり変わらない
* 年収が下がったが月収が上がった
* ランチ代が500円以下から1000円くらいになった（お弁当ではなく外に出て食べるようになった）
* 勤務地が五反田から六本木になった
* フレックスタイム制から裁量労働制になった
* 株をもらったので、会社やプロダクトのために仕事するぞという気持ちが強くなった
* 一人で開発してるとコードの書き方不安になる
* 残業は増えたがだいたい集中してコード書いてる残業なので良い
* 疲れてる日とか勉強会がある日は普通に早めに上がれる
* Web系なんでも担当するぞという気持ちだったが自然とフロントエンド担当っぽくなった
* リファラル採用で紹介できる知り合いがいない
* 自分が起業したら、という想像を持ちながら働いていると、採用・営業・ファイナンス・プロダクトの方向性決め・法務・資金調達、などなどやり方の想像すらつかない部分がたくさん見えてきた
* メルカリさんのおかげで六本木の勉強会に行きやすくなっている

## 転職について
* 新しいメンバーに慣れるのに時間がかかる
* 退職金が出ないの辛い（彼女ちゃんも同タイミングで転職したが40万くらいもらっていた）
* 有休がほとんど残っていなかったので、有休消化期間というのがなかった
* 気持ちの切り替え期間みたいなのはなかったがすんなり働き始められた
* ”前職はソニーのグループ会社で働いてまして”が使えるのも今だけなんだろうな

## これから
* 最高のサービスを早くリリースできるように気合い入れて開発やっていく
* スタートアップの忙しさに殺されないよう勉強会等で技術キャッチアップを続ける
* 何かしらの手段で自分自身の価値を上げて行く活動を行う

スタートアップに転職した

このエントリーは [#kosen10s Advent Calendar 2017 ](https://adventar.org/calendars/2199)11日目のエントリーです。前日の担当はNKMR6194
くんで、[なぜpthread_mutexは機能するのか？](https://sakasin.net/blog/pthread-mutex-with-glibc)というエントリーでした。

みんなkosen10sに全く関係無い記事を普通に書いているので自分も普通に今日勉強したことを書く。
もはやelectronとかvueのアドベントカレンダー向けのエントリになっている。

# Overview
* [Electron](https://electronjs.org/) で簡単なメモ帳アプリを作った話（未完成）
* [electron-vue](https://github.com/SimulatedGREG/electron-vue) を使ったよ
* Vue回りの解説はあんまりしないけど雰囲気で読み取れると思う
* Electron覚えるとWebのFrontend技術で簡単にデスクトップアプリが作れて雑用力が上がるのでおすすめ

# Electronとは
> Webサイトを作成する感覚でデスクトップアプリを開発できます。Electron は JavaScript, HTML, CSS といったWeb技術を利用してネイティブアプリケーションを作成するためのフレームワークです。開発者はアプリの重要な部分の実装に集中して、面倒な部分はElectronにお任せください。  [https://electronjs.org/] より

だそうです。技術的にはchromiumを内包したアプリができます。中でNode.jsが動いています。    
SlackやVisual Studio Codeを始め、がんがん採用実績が増えているフレームワークです。

# 作るもの
* メモを新規作成できる
* ファイル保存できる
* テキストファイルを読み込める
* macのNotes.appみたいなのを目指す

# electron-vueの導入から起動まで
```sh
npm install -g vue-cli
vue init simulatedgreg/electron-vue electron-memo
# 質問されるのでこんな感じで選択した
> ? Application Name electron-memo
> ? Project description An electron-vue project
> ? Select which Vue plugins to install axios, vue-electron, vue-router, vuex
> ? Use linting with ESLint? Yes
> ? Which eslint config would you like to use? Standard
> ? Setup unit testing with Karma + Mocha? Yes
> ? Setup end-to-end testing with Spectron + Mocha? Yes
> ? What build tool would you like to use? packager

cd electron-memo
npm install
npm run dev
```
ESLintのstandard設定を選択したので生成される.eslintrc.jsを変更しないかぎりはそれに従わないとエラーが発生する。  
ESLintに従ったコーディングをおすすめするが慣れない人は削った方がいい。

起動するとこんなWelcome画面。
![](https://lh3.googleusercontent.com/pw/AM-JKLWQPVXkA96UP9RxwAFdCJMIpIUC2kBkdSa_S5I007t5n2GI9ivL__DJsYItFRGKTNO7jQeKHbCvIf6ATR5dUm4c8UWeHeTkFSamF1pMefcpZLmLr9G0EJwCdZPng6BA3UM43TuSKlS1-F8CNFnMaFYJ=w1024-h642-no?authuser=0)
Chromiumが動いていて、WebPackDevServerがサーバになっている。ちなみに `http://localhost:9080/` にアクセスすると真っ白な画面になった。うまいこと隠してくれているみたい。  
`src/main/index.js` を見たところProdビルドではlocalhostURLではなくファイル参照になるようなので安心。

# 最終的にできたもの
![](https://lh3.googleusercontent.com/pw/AM-JKLWKnanO89NylDZZo5MSsviqsctimpVxu6DGD1xtZ9UGNb6Fp4MmH200fc3T2USjCAFnvNRZZgojDdo7s0TgzpEEtwApVpD-dKa-o1FY5OVu259td_ORQ4uTG96Tc7pxj4RUG4GQ9t1566oe6JrLn0OP=w724-h697-no?authuser=0)

* Slackを参考にしつつデザイン頑張ってみた。
* まだまだ問題はあるものの３、４時間で形になった
* まだまだそのうち改善するがとりあえずGithubに置いた（[https://github.com/92thunder/electron-vue-note:title]）

# コード解説等
#### src/renderer/components/Index.vue を作成
```html
<template>
  <div class="grid-container">
    <div class="sidebar">
      <div class="memos-title">Memos</div>
      <div class="memos">
        <div v-for="(memo, memoIndex) in memos" :key="memoIndex" @click="changeIndex(memoIndex)"
              :class="['memo', index === memoIndex ? 'active' : '']">
          
          {{ memo.filePath && memo.filePath.split('/').reverse()[0] || memo.text.split('\n')[0] || "Empty" }}
        </div>
      </div>
    </div>
    <div class="action">
      <div class="action-title">Action</div>
      <div @click="addNew" class="action-item">Add New</div>
      <div @click="importMemo" class="action-item">Import</div>
    </div>
    <div class="editor">
      
      <textarea ref="editor" v-model="memos[index].text" placeholder="Input free memo." class="textarea"
         @keydown.meta.83="save" @keyup.ctrl.83="save" autofocus></textarea>
    </div>
  </div>
</template>

<script>
  // remoteを通じてメインプロセスのAPIを呼び出す
  const {dialog} = require('electron').remote
  const fs = require('fs')

  const emptyMemo = {'text': '', filePath: ''}

  export default {
    data: () => {
      return {
        memos: [{'text': 'sample memo.', filePath: ''}],
        index: 0
      }
    },
    methods: {
      addNew () {
        this.memos.push(Object.assign({}, emptyMemo))
        this.changeIndex(this.memos.length - 1)
      },
      changeIndex (index) {
        this.index = index
        this.$refs.editor.focus()
      },
      importMemo () {
        // dialog.showOpenDialogでOSのファイル選択を呼び出す
        // 複数ファイルの選択も想定したAPIなので返り値はファイルパスの配列がかえる
        const filePath = dialog.showOpenDialog({
          properties: ['openFile', 'createDirectory']
        })[0]
        // ファイル読み込みはNode.jsのfsを使って普通に行うことができる
        fs.readFile(filePath, 'utf8', (error, text) => {
          if (error) {
            console.error('error: ', error)
          } else {
            this.memos.push({
              text: text,
              filePath: filePath
            })
            this.changeIndex(this.memos.length - 1)
          }
        })
      },
      save () {
        const memo = this.memos[this.index]
        if (!memo.filePath) {
          // showSaveDialogでは保存するファイルのパスを選択できる
          const filePath = dialog.showSaveDialog({title: 'Save as'})
          memo.filePath = filePath
        }
        fs.writeFileSync(memo.filePath, memo.text)
      }
    }
  }
</script>

<style scoped>
  /* style scopedと書くことでこのファイル内のみで有効になる */
  .grid-container {
    /* ブラウザはChromium限定なので新しいの使ってみようと思い
       初めてgrid layoutを使って見たが非常に楽だった
       もうfloatは回り込みとかしたい時だけでよさそう */
    display: grid;
    grid-template-columns: 220px 1fr;
    grid-template-rows: 1fr 100px;
    grid-template-areas: "sidebar editor"
                         "action editor";
  }

  .sidebar {
    grid-area: sidebar;
    background-color: #4863ad;
    color: #FFFFFF;
    max-height: calc(100vh - 100px);
    overflow: auto;
  }

  .action {
    grid-area: action;
    background-color: #4863ad;
    color: #FFFFFF;
  }

  .editor {
    grid-area: editor;
    height: 100vh;
  }
  // 長いので省略
</style>
```
自分的に学びのあった部分はコメントを入れた。
`<template>`にHTMLを、`<script>`にJSを、`<style>`にCSSを書いていく。  
さらに`<script>`でexportしているdataにリアクティブにするデータを、methodsにクリックイベント等で呼ぶ関数を書いていく。  
書くべき場所があるって素晴らしい。    

#### src/renderer/router/index.jsを編集
```js
  routes: [
    {
      path: '/',
      name: 'index',
      component: require('@/components/Index').default
    },
    {
      path: '*',
      redirect: '/'
    }
  ]
```
`src/renderer/App.vue` の`<router-view>`にパスに対応したコンポーネントが表示される

# ビルド
ビルドもelectron-vueを使っているおかげでnpmコマンド１つで導入時に選択したelectron-packagerを使ってビルドしてくれているようになっている
```sh
npm run build
...
ls build/
electron-memo-darwin-x64	electron-memo-linux-x64		electron-memo-mas-x64		icons
```
mac, linux用のバイナリが出力された  
インストーラは出来なかったのでそのうちまた調査する  
windowsはエラーが出てビルド出来なかったがwindows用のビルドにはwineが必要らしい  
__注意！！！ビルドは恐ろしくメモリを食い尽くすようでChromeが落ちる！ビルド前にはブログの途中書きとかがないか確認しよう！！！__

# 感想とか
* Web技術でデスクトップアプリが作れるようになってしまったので雑用力が向上した
* このメモ帳はCSSとかで行き詰まったところを除けば３,４時間で作れたので、簡単な社内で使うユーティリティツールなら１日かからず作れてしまいそう
* 今回は状態の保存すらできず、Vuexを使わなかったがstoreにデータを入れて、それをJSONで保存して、起動時にロードすれば状態の保存がかなり楽になりそうなのでやりたい
* フロントエンド書いてるのにブラウザがChromium限定なので新しい記法や仕様を思う存分使えそう。ブラウザ別の対応を考えなくていい
* ピュアelectronを触らずに最初からelectron-vueを使い初めてしまったのでelectronとelectron-vueの恩恵の境界がわかりづらくなってしまった
* 少なくともelectron-vueを使うことで元からVue.jsを使っていたチームなら爆速でデスクトップアプリ対応出来そう

明日の担当は[tsudukami](https://adventar.org/users/10718)で「教育のお話詰め合わせセット」です。

electron-vueでメモ帳アプリを作ってみた

今友人と作ってるやつでアクセスランキングが必要になったので作り方考えたけどDBのアクセス数インクリメントしていったらトータルランキングはできるけど、週間とか月間とかやりたい時どうすんだ？？？ってなって調べてたらGoogle Analyticsにたどり着いた。
というわけでNode.jsでGoogle Analytics APIを使ってWebページのアクセスランキングを集計してAWS Lambdaで毎日定期実行して更新するようにした記事です。

## Google Analytics APIの設定

こちらを参考にさせて頂きました。ありがとうございます。

Google AnalyticsのデータをNode.jsを使って取ってくる(OAuth認証なし) | 株式会社ビヨンド
サービスアカウントキーの取得やらはこちらを参照されたい。
どうせGoogleのUIなんてそのうちすぐ新しくなるのでまとめるのめんどい。こういうの最新っぽい記事と直感でなんとかしてるけど英語のドキュメントとかあるんだろうか

## ランキング取得までの流れ

MySQLにarticlesとweekly_rankingテーブルを作っておいてweekly_rankingテーブルを毎日更新してinner joinとかで結合した結果をAPIで返す前提。

1. articles/:idのようなURLでWebページを用意する
2. MySQLでarticlesテーブルとweekly_rankingテーブルを用意しておく
3. Google Analytics APIでarticlesをURLに含むデータに対して指定の期間内のアクセスランキングを集計させる
4. 集計結果Jsonからアクセス先の記事IDを抽出し、weekly_rankingテーブルに書き込む
5. AWS Lambdaに配置して定期実行するよう設定
6. APIアクセスでweekly_rankingとarticlesを結合して返す（ビュー作っておいてもいいかもしれない）
7. Google Analytics APIでアクセスランキング取得してDBに書き込み

## AWS Lambdaの設定

zipに固めてアップロードして毎日定期実行されるよう設定

![](https://lh3.googleusercontent.com/pw/AM-JKLVBMb_2az4Vf-n8eSl_mF9gFli7HkyBWH-L_17rcAh7udjDPmVLzB1LFNkQPd5__mZzD9fSV-Fxmge9QeCybMiAwa6lzpR28EirQQP3b_qdPJNYcRp0v_sKRJ4aWGtC7P3E7zbm4Riksae-ob5LROe6=w820-h792-no?authuser=0)
後はweekly_rankingのAPIを用意して`SELECT * FROM weekly_ranking INNER JOIN articles ON weekly_ranking.article_id = articles.id ORDER BY rank `で結合して取得するようにした

まずは週間ランキングだけ作った。
設定値や集計期間を環境変数に逃して日間や月間ランキングもすぐに用意できるようにする予定。

## 近況

内定もらえるやろ！って思ってた状態で一週間ハワイ旅行に行ってる間に選考進んだ２社とも落ちてた。ほぼ転職先決まった報告してしまってたのに恥ずかしい。そういう報告は内定もらってからにしようね。
CTOさんと面談しまくってはいるがほんとに行きたいと思ったベンチャー企業しか選考に進んでいないので２社しか受けなかった。転職活動はまだ続く

Node.jsでGoogle Analytics APIを使って楽にアクセスランキングを作る

このあたりのサンプルだけだとradioボタン実装するときにどうすればいいかよくわからなくて、親コンポーネントからv-modelでプロパティを与えてる奴があまり見つからなかったので試した

https://jp.vuejs.org/v2/guide/components.html#コンポーネントの-v-model-のカスタマイズ

https://jsfiddle.net/mani04/3uznmk72/
からフォークさせて頂きました。

Vue.jsのカスタムコンポーネントでradioボタンを使う

Vue.jsでHTML5のドラッグ＆ドロップを試した。
ローカルでの開発は2.4.1, jsfiddleでは2.2.1で動作していることを確認した。

## 導入

ここから開発環境用をダウンロードして<script>タグで読み込んだ

https://jp.vuejs.org/v2/guide/installation.html#lt-script-gt-直接組み込み

## jsfiddleに貼り付けた

JS長くなった。

inputでエンター押すと新しいアイテムが出てきてそれをドラッグしてグループに移動できるやつ。

touch対応はしていないのでスマホ未対応。なんか便利なオプションができてそれ指定するとtouchも勝手にできるようにとかなってくれないだろうか。 

## こだわりポイントとか
* Item, ItemList, Groupがコンポーネントとして使い回せるよう頑張った
* なぜかVue.jsでdataTransfer使ってドラッグからドロップにデータ渡してるサンプルが出てこなかったのでevent.dataTransferでなるべくデータ渡せるようにした
* event.dataTransfer.setData(type, data)でデータを格納
* event.dataTransfer.getData(type)でデータを取得
* （ドロップ時にitem配列から削除が必要だがそのために配列をかなり上のコンポーネントまで伝搬させて行くのが面倒そうだったので外に保管した）

## 余談
backendだけで何か作ってみたとかやっても目に見えにくいからアウトプットしにくいよね
drag and dropをDnDと略すのはDo not disturbっぽくてちょっと嫌
見た目いい感じにしてKPTツールっぽくしようかな

## 参考
* https://www.html5rocks.com/ja/tutorials/dnd/basics/
* https://jp.vuejs.org/v2/guide/

Vue.jsでDrag＆Dropを試す

バズるものを作れる瞬発力を身に付けたくてTwitterのOAuth認証使ってツイートできるやつを作れるようになっておきたかった。アイデアはまだ無い。
GoのWebアプリケーションフレームワーク Ginを使ってTwitter OAuthでトークン取得するところまで試してみた。

## Ginの採用理由
さくっと書きたいからsinatra likeなやつを探した。
その中で現時点でGitHub Starが一番多そうなGinを選んだ。

- https://github.com/go-martini/martini
- https://github.com/zenazn/goji
- https://github.com/gin-gonic/gin
- https://github.com/gocraft/web

## 環境
前回のgo-twitterを使ってみた記事に引き続きCloud9( http://c9.io )さんを使いました。そろそろ有料プランも検討せねば。

http://92thunder.hatenablog.com/entry/2017/09/04/031706

## go getできない
前回は大丈夫だったがgo getでエラーが発生したのでこちらを参考に解決した。
http://qiita.com/syossan27/items/ad05e5060d2ac0fd7adc

## コード
main.go
Ginって標準でsession使えないのか…って思いつつ追加した。

https://github.com/gin-gonic/contrib/tree/master/sessions

```go
package main

import (
	"flag"
	"log"
	"net/http"
	"os"

	"github.com/coreos/pkg/flagutil"
	gt "github.com/dghubble/go-twitter/twitter"
	"github.com/dghubble/oauth1"
	"github.com/dghubble/oauth1/twitter"
	"github.com/gin-gonic/contrib/sessions"
	"github.com/gin-gonic/gin"
)

func main() {
	// 環境変数からconsumer-key, consumer-secretを取得
	flags := flag.NewFlagSet("app-auth", flag.ExitOnError)
	consumerKey := flags.String("consumer-key", "", "Twitter Consumer Key")
	consumerSecret := flags.String("consumer-secret", "", "Twitter Consumer Secret")
	flags.Parse(os.Args[1:])
	flagutil.SetFlagsFromEnv(flags, "TWITTER")

	if *consumerKey == "" || *consumerSecret == "" {
		log.Fatal("Consumer key/secret required")
	}

	config := oauth1.Config{
		ConsumerKey:    *consumerKey,
		ConsumerSecret: *consumerSecret,
		Endpoint:       twitter.AuthorizeEndpoint,
	}

	// ginのrouter初期化
	router := gin.Default()
	store := sessions.NewCookieStore([]byte("secret"))

	// セッションの設定
	router.Use(sessions.Sessions("oauth-tweet-test-session", store))
	// templatesディレクトリを登録
	router.LoadHTMLGlob("templates/*")

	// GET /
	// アクセストークンがセッションに入っていれば表示
	// 入ってなければrequestTokenを取得してOAuth認証ページにリダイレクト
	router.GET("/", func(c *gin.Context) {
		session := sessions.Default(c)
		accessToken := session.Get("access_token")
		accessSecret := session.Get("access_secret")
		if accessToken == nil || accessSecret == nil {
			requestToken, requestSecret, _ := config.RequestToken()
			session.Set("request_secret", requestSecret)
			session.Save()
			c.Redirect(http.StatusFound, "https://api.twitter.com/oauth/authenticate?oauth_token="+requestToken)
		} else {
			c.HTML(http.StatusOK, "index.tmpl", gin.H{
				"test": "hello world",
			})
		}
	})

	// GET /callback
	// OAuth認証ページからこのアプリを許可したらリダイレクトされてくる
	//  このあたりはTwitter Application Managementで設定
	// URLに入っているoauth_token, oauth_verifierと
	//  GET /で取得していたrequestSecretを使ってアクセストークン取得
	router.GET("/callback", func(c *gin.Context) {
		oauthToken := c.Query("oauth_token")
		oauthVerifier := c.Query("oauth_verifier")
		session := sessions.Default(c)
		requestSecret := session.Get("request_secret").(string)
		accessToken, accessSecret, _ := config.AccessToken(oauthToken, requestSecret, oauthVerifier)
		session.Set("access_token", accessToken)
		session.Set("access_secret", accessSecret)
		session.Save()
		c.Redirect(http.StatusFound, "/")
	})

	// POST /post
	// access token/secret を使ってツイート投稿する
	router.POST("/post", func(c *gin.Context) {
		session := sessions.Default(c)
		accessToken := session.Get("access_token")
		accessSecret := session.Get("access_secret")
		if accessToken == nil || accessSecret == nil {
			log.Fatal("Invalid access token/secret.")
		}
		config := oauth1.NewConfig(*consumerKey, *consumerSecret)
		token := oauth1.NewToken(accessToken.(string), accessSecret.(string))
		httpClient := config.Client(oauth1.NoContext, token)

		client := gt.NewClient(httpClient)
		client.Statuses.Update("oauth test", nil)
		c.Redirect(http.StatusFound, "/")
	})

	router.Run()
}
```

templates/index.tmpl
```html
<html>
    <head>
    </head>
    <body>
        <h3>OAuth Tweet Test</h3>
        <form method="post" action="/post">
            <button type="submit">Post</button>
        </form>
    </body>
</html>
```

## 実行
```shell
export TWITTER_CONSUMER_KEY=xxx
export TWITTER_CONSUMER_SECRET=xxx
go get .
go run main.go
```
認証ページにリダイレクトされてツイートするとこまでできた。

![](https://lh3.googleusercontent.com/pw/AM-JKLWnluaeGfDliflE3OoIJHYQyfdD3pgjoUz1kUAcnQpAyOe6EbMwEklLuFVBxyejPlOdB3BzyGL2d20RMBZVIFFCex7hR_QTakxY74R1L2WUqX25umMjTGZsNU6IW7RFkuzDOBaDq_XLYxd2QJZGM62f=w719-h332-no?authuser=0)

## 所感
- さくっとOAuthでトークン取得試せた
- Mac Bookのスペースキーに何か挟まってるのか打ちにくい

GinでTwitter OAuthでaccess token取得

golangの練習がてら、go-twitterを使ってツイートしてみただけ。  
https://github.com/dghubble/go-twitter

## 環境
今回はCloud9( http://c9.io )を使いました
templateはBlankを選んでWorkspace作成。
```sh
$ go version
go version go1.8.3 linux/amd64
```
最初から入ってる。やったぜ。
ちゃちゃっと試したいときにブラウザ上で試せちゃうのはほんとに便利。
 
## go get
```bash
$ go get github.com/dghubble/go-twitter/twitter
$ go get github.com/dghubble/oauth1
```

## コード
```go
package main

import (
	"fmt"
	"github.com/dghubble/go-twitter/twitter"
	"github.com/dghubble/oauth1"
)

func main() {
	config := oauth1.NewConfig("<consumerKey>", "<consumerSecret>")
        token := oauth1.NewToken("<accessToken>", "<accessSecret>")
	httpClient := config.Client(oauth1.NoContext, token)

	client := twitter.NewClient(httpClient)

	tweet, resp, err := client.Statuses.Update("hello world", nil)
	fmt.Println(tweet)
	fmt.Println(resp)
	fmt.Println(err)
}
```
ドキュメント見た感じclient.Statuses.Updateの第2引数は画像やら位置情報やらつけたい時に使うみたい。
APIキーの取得方法は割愛。  
https://dev.twitter.com/ads/tutorials/getting-started

## 実行
そのまま実行
```bash
$ go run main.go
```

バイナリ化してから実行
```
$ go build main.go
$ ./main
```

hello 

### これから
連携を許可しますか？みたいな画面が出て代わりにWebサービスが投稿するやつができるとこまではやっておきたい。

go-twitterを使ってツイートしてみる

退職エントリとか読んでるとみんなわりとカジュアルに明るく転職してるなとか思ってたんだけど自分がいざやろうかなと考えてみたらとんでもなく怖くなっちゃった話。

### 新卒入社してから

新卒でソフトウェア開発会社に入社して、４ヶ月の研修の後配属されたのでこの８月で丁度２年間実務経験を積んだことになる。業務はWebアプリケーションの開発を中心にプロジェクト３つほど担当してきた。新卒でソフトウェア開発プロジェクトに配属されて第一に身につけるべきだと思ってる「言語やフレームワークについてある程度ちゃんと理解して使う能力」は多分、個人的には、身に付いている、はず。こいつができればキャッチアップ時は気合が必要だが新しいプロジェクトに配属されてもなんとかなる。

## 退職の動機

きっかけは普通のつまらん動機だけど自分は高専卒なのだが、同い年で入ってきた大卒や高専専攻科卒のほうが基本給が高かったからで、それから考え始めて今の成果物型（なんか作ってかかった人月でお金を儲けるやつの名前がちゃんとわかってないのでそう呼んでる）での開発をずっと経験するよりは自社サービスを開発していてB to Cでビジネスやっている会社に行った方が5年後や10年後を想像して、学ぶことが多そうとか将来の選択肢が増えると思ったから。簡単に書くとそんな感じ。

## あれ、転職、怖いぞ？

 夏休みに今の会社に入るまで育ててくれたご両親と相談してOKがもらえたのでこれから本腰入れて転職活動スタートしようかってわけなのですが、転職怖いという壁にぶち当たってしまったわけです。

## 転職の何が怖いのか
### 1. 成り行きで進んだ人生から変える

中学の時、高専を選んだのは仲良かった友人が高専のこと教えてくれて寮とか楽しそーとかそんな感じだった。（正直適当だったと思う。）
今の会社を選んだのは正直一番強い理由が高専４年時にインターンに行って悪い会社じゃ無さそうだったという印象があって、他の会社を探す気力も無く、そのまま高専の推薦を使って入社できた。

この新卒入社までの人生でも選択はいくつかあった。だが転職は違う。今の自分からすると転職は人生というエスカレータから飛び降りるような感覚がある。引っ越しとかその比ではないくらいのエネルギーが必要になりそうだ。

### 2. 自分の武器の少なさ

実務経験２年しかない。就職してからアンテナが折れてしまって新しい技術に触れようとしていない。業務で触れる範囲の技術しか自発的に学習しようとしない。当然OSSに貢献しているわけない。英語できない。メンバーと相談して設計しながらコード書くことはできるけど自分一人でちゃんとしたものを作ったことがないので自信がない。。。
などなど、武器を探すつもりが悪いところしか見つからない。プロジェクト内では若手エースのつもりになっていた自分を恥ずかしく思う。
こんな状態で本当に転職活動できるのだろうか・・・

### 3. 転職しないという選択肢 

収入は23歳の若造にしてはわりといいほうだと思う。大企業のグループ会社の利点だ。彼女も居て既に同棲している。正直言ってめっちゃいい感じの人生だと思う。転職しなければあと数年しない内に家庭を持ってたりしているかもしれない。
転職すると、この先の人生がめっちゃいい感じのままでいられる可能性は大きく下がると思う。転職した結果、激務すぎて鬱になったり収入が低すぎたり彼女と別れたりするかもしれない。転職しないほうが安定したいわゆる幸せな生活が手に入るだろう。

## まとめ

というわけでいざ自分が転職しようと思ったらすごい怖いと思った話でした。頭良さそうな人の終身雇用前提はクソとか過労死とかになる前に仕事やめろよみたいな意見に賛成してたけどいざやろうと思うと壁が多いもんだなと思う。
まあ最初に書いた通り5年後10年後の自分の幅と経験値のために転職するんだけど。
ブログ書く前は漠然と「うわ！なんか転職こわい！」と思ってたんですが書くと整理できてすっきりしました。

というわけで初エントリでした。今後もこのブログではプログラミングのことや備忘録やら雑記やらなんでも書きたいと思ってます。