## 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 で特定ユーザのみ書き込み可能にする

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年が経った

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万くらいもらっていた）
* 有休がほとんど残っていなかったので、有休消化期間というのがなかった
* 気持ちの切り替え期間みたいなのはなかったがすんなり働き始められた
* ”前職はソニーのグループ会社で働いてまして”が使えるのも今だけなんだろうな

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

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

今友人と作ってるやつでアクセスランキングが必要になったので作り方考えたけど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を試す

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

## 環境
今回は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:title]

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

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