## 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/posts/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が使えない

以前にもあった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を使った感想

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年後の自分の幅と経験値のために転職するんだけど。
ブログ書く前は漠然と「うわ！なんか転職こわい！」と思ってたんですが書くと整理できてすっきりしました。

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