

大学生として学んだこと

## 前書き
- 情報系の学生です。数学とweb開発とプログラミングが好きです

## 理解することを理解した
- 大学一年生の時は線形代数で躓いていた
	- 単位が取れないという躓きではなかった、授業にはきちんと出席している、黒板に数式を殴り書く教授の授業を受けていた。
	- 演習問題の解き方を覚えればテストの回答を書くことができた何も問題なかった。
	- しかし授業をちゃんと受けていたにもかかわらず問題を解く方法はわかるが、どうしてそうなるのかの部分がまるっきりわからなかった。
- 研究室に配属されて輪読という形式で本を読むことを学んだ
	- 本屋に並ぶ専門書を見て自分はもう読むことはできないんだと思った
	- 授業で使われている教科書が難しいのでは無いかと考えて本屋や図書館で線形代数の本を何冊かめくったがどれもこれも1ページすら理解できなかった。
	- このときの自分の状態をを正確に表現するのであれば、文字は終えるのだが何一つとして頭に入っていない状態だった。ただ文字を追うことを読むと勘違いしていたことがのちにわかった。
	- 本屋さんにはとても興味のそそる本がたくさんありました、相対性理論、トポロジー、力学、整数論、etc... のに自分は頭が悪いのでもうこの本たちを読むことはできないのだと半ば諦めていた。
	- 学術書の理解ができないことと対照的にプログラミングにのめり込みました。手を動かしてコードを書いて何かを作ることがとても楽しいことに気がついた。
- 大学一年生から時が過ぎて研究室配属の時期になった。この頃にはインターンや業務委託などの経験で開発のスキルは身に付いてきて就職にもまあ困らないのではないかという楽観的な自信ができてきたので、自分の興味を追及できそうな研究室を探して無事に配属されました。
	- そこで大学生活で二度目の数学との出会いがありました。
	- 情報系の研究室ですがゼミでは主に数学書の輪読でした。私はまたあの1ページも理解することのできなかった線形代数の教科書に向き合うことになりました。
	- 輪読は本当にごく普通の形式で章ごとに担当者を決めて本文を追い、出てきた問題も解いてゼミ生の前で解説をするような形でした。
	- 自分で解説をするとなるとかなり読み込んでこなければならないので否が応でも本文を読んで学習しました。
	- 先生からは少しでも詰まっている箇所や論理が抜けている箇所に対してどんどん質問が飛んできました。~って言ってるけど~の定義はなんなの？その一式目から二式目の式変形はどうなっているの？この証明は全体として結局何が言いたいの？その質問に対して答えられない時に自分は理解できていなのだとメタ認知することができました。
- 輪読から理解しているとはどういった状態なのかを理解できた
	- 飛んでくる質問の粒度から数学の教科書の読み方がわかりました。
	- 専門書を読むとは目で文字を追うことではなく、一行一行、誰かに説明できるようにすることだということがわかりました。数学書であれば定義や定理まで遡って行間を埋められるか？自分の中で曖昧で意味が言えない単語がないか？一行一行丁寧に確かめていく作業こそが”読む”というものだったと気が付きました。
- 大学生になって初めて理解するを理解できた
	- 数学書の読み方を通して「理解することを理解できた」これが自分が大学生活で学んだことです。
	- 私は大学三年生になってようやく理解することを理解できたのです。小学校、中学校、高校とやってきましたが高校までは問題が解けることが理解したことだと、文字を黙読して追うことが読むことだと勘違いしていました。理解とは概念を自分が腑に落ちる形で説明できることだったのです。少し抽象的なので数学書であれば、証明の一行一行を定義まで遡って自分の言葉で説明できるかどうかが理解しているかしていないかだとわかりました。(抽象度の違いはあります、全体としてどう言ったことをしているのかに対する理解も大切です、上にあげたのはあくまで細部の理解の確認です）

## 構造を見出す
実際に学んだ数学で自分が一番好きなものについて言及したいと思います。

- 線形代数を学んだKerとかImとか
	- 授業を受けているときは何が何だかほとんど分かりませんでしたがKerやImをどのような計算で出すことができるのかだけはわかっていました。試験はおおよそ計算問題だったので解けてしまっていたのですが、KerやImとはなんなのか？といった質問に答えることができませんでした。
	- 線形性の定義は大事なものだと黒板に書かれていたことを覚えています。行列ならばこの性質を満たすのは自明じゃないのか？なぜこんなことを書くのだろうと不思議に思っていました。
	- 研究室の輪読で線形代数のKerとImや次元定理を学習しました。線型写像で写した先をIm、写し先が0に潰れるものがKerであることを理解しました。
- 群・環・体を学んだ、準同型を学んだ
	- 次にImとKerに出会ったのは代数学でした
	- ある群から別の群へ計算を保ったまま移すことができる準同型写像にも線形写像と同じくImやKerがあることを知りました。
- 線形代数の線形性が準同型であることを知った、代数学と線形代数学が結びついた
	- 例えば線形代数では、線型写像のKerは写像元の部分空間になる。
	- そこから群の準同型写像のKerも部分群になるのではないかという予想がたてられた。そしてこの予想は実際に当たっている。
	- 詳細に入り過ぎてしまうが代数学の環上の加群が正しく線形性を持ったものだった。
- 圏論を学んだ、それぞれの圏を構成できることを知った
	- この抽象化により離れていた分野を一つのものとして抽象化できていることを知りました
- アーベル圏を学んだ、自分が線形代数と代数学で見出していた構造はこの圏だったのかと驚いた。
- プログラミングと似たようなものを数学に見出せた。物事の構造を捉えて抽象化する。interfaceを作る。
	- 圏論は数学から構造を抜き出している。ソフトウェアエンジニアリングも現実世界から構造を抜き出している。圏はインターフェースである。上の例で言えば準同型写というインターフェースを持っていて群、環、体、環上の加群はその実装である。
	- いわゆる点と点が繋がったというか大学時代にやってきた学問が混ざりあった。
	- 圏論にはモナドの概念とクライスリ圏。(プログラムは集合写像ではないクライスリ圏の射であるという表語には震えた)型付きラムダ計算とカルテジアン閉圏など非常に親和性の高い分野がいくつかある。
        
    
以上が大学時代に自分が学んだことです。
    
大学を卒業する頃になってようやく、理解することを理解できた気がしています。
    
すべての物事が定義や公理に遡ることができるように、数学は形式が整っていて理解する訓練にとても良かったです。プログラムも数学とかなり近い位置に属していると思うので、次はソースコードを理解すること、いわゆるコンピューターサイエンスの基礎的な力に力を注げばエンジニアとして成長できるのではないかと密かに楽しみにしています。


    
### 追記雑文
    
- 残念ながら理解しようと試みることは非常に時間がかかる
- 理解できたと実際に運用できるかはまだ別の技能が必要だなと感じている。本文を理解できたからといって章末問題が解けるわけではない。ソースコードを理解できたからと言って自分でフルスクラッチで書くにはまた別の訓練が必要そう。
- いわゆる専門書の読み方がわかってきて学びたい学問の数が増えました
- 小説は文字を流し読みして情景を想像するので理解に重心を置くかどうかは読むものによります(それはそう)
- 理解している状態がわかってしまったので、あ、自分今、理解していないのに返事をしているなということに気がつくことが少々ある...
- 論文はまだ理解して読めない修行が必要

大学生になってようやく理解することを理解できた話

大学生になって学んだこと


冬の夢

スコット・フィッジェラルド

村上春樹訳(村上春樹 翻訳ライブラリーより)


---

短編集になっている。
冬の夢、メイデー、罪の赦し、リッツくらい大きなダイアモンド、ベイビー・パーティの前5作。
翻訳者曰く「プレ・ギャッツビー」期の作品群。

いつも通り簡単な引用とメモ集です。


### メイデー

p110

> 唇は深いカーマイン色で精妙に仕上げられていた。

カーマインの色がわからなかった。口紅から赤系統の色だろうなとはわかったが、具体的にどの色を指しているのかわからなかったのでwikiで調べた。

[カーマイン wiki](https://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%BC%E3%83%9E%E3%82%A4%E3%83%B3)


--- 

p184からp185にかけて。

メイデーの締め。
ゴードン・スタレットが自殺するシーン。
このp184からp185にかけての自殺するまでの流れの文章は今まで読んだ中では最も簡潔でそれでいてある種の(それでもなお小説くさいが)リアリティがあった。いつか、読み漁った文章を集めて小説自殺集とか出したら面白そうである。

最後の数行だけ引用する。

> すぐそばに生命の気配があることを感じたのは、誇りを含んだ陽光を認め、大きな革製の椅子のほつれを目にした三十秒ばかり後のことだっただろう。そして自分がジュエル・ハドソンとの取り返しのつかない結婚をしてしまったことに思い当たったのは、更に三十秒あとのことたった。
> 彼は三十分後にそこを出て、スポーツ用品点で回転拳銃を買い求めた。それからタクシーを拾って、東二十7丁目通りにある自分の部屋に戻った。そして画材を並べたテーブルに前屈みになり、自分の頭の、こめかみの少し後ろに弾丸を撃ち込んだ。

---

### リッツくらい大きなダイアモンド

> p236「そんなの全然お話にもならないさ。だって僕の父は、リッツ・カールトン・ホテルよりも大きなダイアモンドを持っているんだもの。」

> p250 「この館が建てられている山だよ。山としては大きいわけじゃない。でも表面を覆っている五十フィートほどの土やら小石やらをどかせば、そのしたはガッチリしたダイヤモンドでできているんだ。まるごとひとつの、疵一つないダイヤモンドだよ。大きさは一立方マイル。聞いているのか？ だから - 」

[リッツカールトンホテル wiki](https://ja.wikipedia.org/wiki/%E3%82%B6%E3%83%BB%E3%83%AA%E3%83%83%E3%83%84%E3%83%BB%E3%82%AB%E3%83%BC%E3%83%AB%E3%83%88%E3%83%B3)

巨大なダイヤモンドを見つけたワシントン家に主人公のジョンがお邪魔するお話。世の中の全ての富を持つと言っても過言ではないワシントン家が没するところでお話は終わる。

> ラインストーン

ガラス細工でできた模造ダイヤモンドをラインストーンというらしい。


> 「私たちは誇り高いの」(省略)

> 「私たちは誰一人として罰を受けたことがないのよ。罰を受けたりするべきではないと父は言っている。一度姉のジャスミンが小さいときに、父を階段の上から突き落としたんだけど、父は何も言わずにただ立ち上がって、そのまま足を引きずって立ち去っただけ。」

ワシントン家の娘、キスミンに恋に落ちるジョン。
キスミンからの会話からもワシントン家の異常さが伝わってくるエピソード。

ワシントン家は山のような（というより山の)ダイヤモンドを隠し通すために発見者を監禁、または抹殺していた。

> p272「運悪く黄金郷を発見してしまった冒険好きの船乗りたちがここにいる。」

暗い穴の上からジョンとワシントン氏が監禁されている人たちを見下ろしているシーンの一言だ。


最終的には、逃亡者によってダイヤモンドを隠し持っていることがばれ空襲に遭いワシントン家は失墜する。

最後にワシントン氏が巨大なダイヤモンドをもって神様に時間を戻せと真剣に懇願するシーンはみものであり、哀れでもあった。


> p316 「それは実際に夢だったのさ」とジョンは静かに言った。
> 「全ての人の青春はただの夢に過ぎない。科学的な狂気のひとつのありように過ぎないんだ。


---

村上春樹翻訳フェアでフィッジェラルドの短編集を読み漁っている。
グレートギャッツビーは超有名なので今年度中に目を通してみたい。

[村上春樹翻訳ライブラリー 冬の夢 単項本](https://www.chuko.co.jp/tanko/2011/11/403533.html)

冬の夢 スコット・フィッジェラルドを読んだ

冬の夢


アーサー・C・クラーク

翻訳者 池田真紀子

光文社古典新訳文庫第10版

とさです。新年2冊目の小説。
光文社古典新訳文庫のおかげで名作と呼ばれる本をかろうじて読めるようになった今日この頃。

読書をしながら気になったところとかをメモしていきます。


リップ・ヴァン・ウィンクルについて

p36に出てきた、リップ・ヴァン・ウィンクルの花嫁と映画にも出ていた名称だが、これはなんなのだろうかと気になったのでwikiで調べてみた。

wiki引用
> 『リップ・ヴァン・ウィンクル』(Rip Van Winkle [3][4]) は、アメリカの小説家ワシントン・アーヴィングによる短編小説であり、作中の主人公の名前でもある[3][5]。1819年から1820年に掛けて分冊形式で刊行されたスケッチ風物語集『スケッチ・ブック』[6]の1冊目（1819年6月23日刊行）に所収の1篇として発表された[5][7]。アメリカ最初期の短編小説の一つである[7]。

> 猟に出た主人公リップが山中で奇妙なオランダ人の一団に酒をふるまわれて寝込んでしまい、目を覚まして山を下りると20年も経っていて、世の中がすっかり変わってしまっていたという話[8][9][5]。

なるほど、最後のジャンのオーバーロードの惑星に行って戻ってきて80年が経過してしまう過程をリップヴァンリンクルを対応させていたのかと納得できる。

---

> p273
> 人間が受け身なスポンジに、吸収するだけで何も生み出さないスポンジに成り下がろうとしているのも不思議ではありません。

テレビやラジオから流れる娯楽の多さを指摘している文章。今の時代はまさにそうなっているよなと。
一生分の時間をかけても消費しきれない娯楽がある。
最近、むしろ暇であることがとても貴重なのではないかとよく感じるようになったのでこの本で文章化されていて改めて認識できた。

---

> p404
> 何より欲しかったのは、電子ピアノとバッハの楽譜だった。これまでは音楽に時間を費やすことができなかった。

人類が一人になった世界でジャンが最後の時間を過ごす時の文章。

終末に希望を見出す論者ではないが、世界が終わってしまうことがわかれば人はある程度自由になれるのではないか。世界が終わってしまうのであれば、自分ならおそらく好きな場所をひたすら散歩するだろうし、図書館でゆっくりと本を読んでいるだろう。世界の終わりはとてつもなく暇なのではなのかもしれない。そうあって欲しいなと読んでいて思いました。

この本全体を通してジャンみたいな体験をしたいかも。
異世界人(オーバーロード)の船に乗り込んで、別の惑星を見学して人間としては体験できなかったであろう宇宙のいろいろなことを体験して、地球に戻ったら人類はほぼ滅亡してて自分が最後の人類となっている。
そうして、地球が滅びる瞬間を実況しながら幕を閉じる。

これほどまでに好奇心を満たす体験をしてみたいなと思いました。

--- 

オーバーロードの正体がわかるまでワクワクしながら読めて楽しかった。
あとは、子供が能力に目覚めて宇宙のあらゆる星の映像を夢に見るシーンは自分も想像力を掻き立てられて面白かった。



幼年期の終わり アーサー・C・クラークを読んだ

幼年期の終わりを読んだ


StudentSalaryと呼ばれる学生エンジニアの匿名時給投稿プラットフォームを運営しています。

[StudentSalaryサイトリンク](https://www.student-salary.com/)

匿名での投稿者のおかげでだいぶ時給情報のデータが揃えることができたのですごく感謝しています。

# 技術観点の進捗

9月に技育展に出場するにあたり、サイトの改修を行いました。Nuxt + firestoreベースのプロトタイプ技術選定からNext + golangのいわゆるイケイケの構成に変更しました。UIなどもスマートフォンで閲覧して自分にとってできる限り違和感がないように修正を重ねて拘っています。

特にグラフのレイアウトを混ぜることでコンテンツ不足感を少し軽減することができたのではないかと思います。

サーバーサイドはいわゆるドメイン駆動開発を意識して開発しましたが、そもそもドメインと言っていいのかわからないくらいのモデル数なのでメリットというよりか余計なコードが多すぎるなと感じています。開発中は一人ユビキタス言語や！ValueObjectや！とかいって楽しんでいました。

散々MVCフレームワークを避け続けていましたが、個人開発であればむしろMVCを採用するメリットは非常に高いと今は考えています。ガチガチに依存させてActiveRecordモデルをぶん回すことでガリガリ機能を開発していきましょう。開発効率が下がるところまでソフトウェアが伸びているのであればむしろ万々歳です。
もはや、アーキテクチャなんか考えずにとりあえずは機能を作っていくのがいいと思っています。
(あくまで個人開発観点です、仕事の大規模なサービスではありません。)

早すぎる抽象化は悪と100回くらい唱えましょう。

また、Graphqlを採用してみました。話に聞いていた通りクライアント側のコードをよしなに生成してもらえるので開発体験がとても良かったです。

移行後にはfirestoreからgcloudのmysqlを使用していて月に1000円くらいのランニングコストがかかるようになりました。

# サービス観点

StudentSalaryは求人情報サイトには時給が範囲で指定されていたりしていて正確な時給情報が掲載されていないという問題点を解決するため、こんなサイトがあったらどうだろうという好奇心によって作成しました。

またプログラミングスクールでは数ヶ月で??万円！という広告も目立つようになり本当に数ヶ月でそのくらい稼げるようになるのか興味があったので学習年数の投稿もお願いしています。広告の強調も大事ですが、サイトを閲覧していただければ現実としてどのくらいの学習をしているのとどのくらいの金額なのだろうか？という感覚が掴めるのではないかと思います。

自分の結論としては少しずつ学習を継続して2年くらい続けられればこの業界であれば報われると考えています。

時給は企業のフェーズや各個人の実力に依存するので単純に高ければ高い企業ほどいいというわけではないのです。
登録されたデータを閲覧して学生でエンジニアとして働いている人が大体の相場感を把握できるようになると嬉しいなと思っています。

最近だとインターンシップの時給がかなり高額になってきている印象です。
また、落ち着いたらデータをまとめて傾向等を記事にします。

実際に運用してみて、登録された時給情報からインターン探しなどに使用されている様子のTwitterの投稿を見つけて、実は学生エンジニアのインターンシップ・新卒採用情報が網羅的にまとまっている情報サイトはあまりないのではないかというinsightを得ることができました。

今後は各社の採用情報のまとめと、インターンシップなどの参加ブログのリンクをまとめさせていただいて多角的に企業の情報を見れるサイトにしていきたいと思っています。

現時点では個人の開発なので割けるリソースに限りがありますががんばります。

- OpenSalaryというinspireしたサイトの作者の人にも公認してもらえてとても嬉しかったです。
- 自分のインターンシップ探しにも利用して非常に参考になりました。

2021年 StudentSalaryを運用してみて所感とか感想とかつらつら

2021年StudentSalaryについて


# Rollup とは

何がともあれまずは[公式ドキュメント](https://rollupjs.org/guide/en/)をよむ。

### Overview[引用]

Rollup is a module bundler for JavaScript which compiles small pieces of code into something larger and more complex, such as a library or application. It uses the new standardized format for code modules included in the ES6 revision of JavaScript, instead of previous idiosyncratic solutions such as CommonJS and AMD. ES modules let you freely and seamlessly combine the most useful individual functions from your favorite libraries. This will eventually be possible natively everywhere, but Rollup lets you do it today.

Javascript の bundle ツールです。Webpack とやっている仕事は同じ。複数の Javascript ファイルをまとめて、一つにまとめることを bundle と読んでいる。

また、ユーザー側は ES6 形式で書いて、rollup が既存のブラウザでサポートされている形式(CommonJS, AMD)にコンパイルもしてくれる。

※ES6 の現在の対応状況は[こちら](https://kangax.github.io/compat-table/es6/)

### Tree-Shaking

rollup は静的解析を用いて import されているが使用されていない関数やモジュールを取り除いてくれる。

結果として bundle サイズが小さくなる。

### Tree-Shaking を試してみる

公式ドキュメントの Tutorial>Creating Your First Bundle に乗っ取ってプロジェクトを作ってみる。今回はきちんと不要なモジュールが bundle されていないか確かめるために hoge.js の方は import しているが使用しないようにしている。

```js
// sample-project/src/foo.js
export default "hello world!";
```

```js
// sample-project/src/hoge.js
export default "hello hoge!";
```

```js
// sample-project/src/main.js
import foo from "./foo.js"; // 使ってる
import hoge from "./hoge.js"; // 使ってない
export default function () {
    console.log(foo);
}
```

準備ができたら bundle してみる。rollup はすでにインストールされており node_module にきちんと path が通っていることを確認して以下のコマンドを打つと bundle.js ファイルが生成される。

```zsh
rollup src/main.js -o bundle.js -f cjs
# -o [output file name]
# -f [format]
```

```js
// bundle.js
"use strict";

// src/foo.js
var foo = "hello world!";

// src/main.js
function main() {
    console.log(foo);
}

module.exports = main;
```

hoge がきちんと削除されていることが確認できた。つぎに、hoge を使用した場合はどのようになるのかを確認する。

```js
// sample-project/src/main.js
import foo from "./foo.js"; // 使ってる
import hoge from "./hoge.js"; // 使ってない
export default function () {
    console.log(foo);
    console.log(hoge);
}
```

zsh

```zsh
rollup src/main.js -o bundle.js -f cjs
# -o [output file name]
# -f [format]
```

bundle された結果、きちんと hoge が存在していることがわかる。

```js
"use strict";

// src/foo.js
var foo = "hello world!";

// src/foo.js
var hoge = "hello hoge!";

// src/main.js
function main() {
    console.log(foo);
    console.log(hoge);
}

module.exports = main;
```

簡単な検証であるが、TreeShaking の働きを理解することができる。

### rollup の config ファイル

project のルートディレクトリに rollup.config.js という名前のファイルが config ファイルとなる。

以下のような設定ファイルを書いて`rollup --config`でファイルを読み込んで、設定に従い bundle する。

```js
// rollup.config.js
export default [
    {
        input: "src/main.js",
        output: {
            file: "bundle.js",
            format: "cjs",
        },
    },
];
```

### 変更検知

`rollup -w`でファイルの変更を検出して、build するようになる。
ローカルのファイルをサーバーにあげて hotreload で開発したい時などに便利。

```zsh
rollup --config -w
```

## これから先勉強できそうなこと

-   TreeShaking のコードリーディング、JS の静的解析
-   watch の仕組み

## 参考文献・サイト

[rollup 公式ドキュメント](https://rollupjs.org/guide/en/)

[Tree shaking](https://developer.mozilla.org/ja/docs/Glossary/Tree_shaking)


bundleツールであるrollupを触ってみたので概要をまとめる

Rollup触ってみた

おはようございます、とさです。
NTT 主催のパフォーマンスチューニングコンテストに出場してきました。
beer とおつまみがいっぱい送られてきたので昨日の夜はめちゃくちゃ楽しかったです。

今回もチーム雑用係[さんぽしくん](https://twitter.com/sanpo_shiho)と[ましくん](https://twitter.com/masibw)と参加して来ました！

ISUCON と同様に以下の役割分担で頑張りました
 
さんぽし : インフラ周り、デプロイ&ベンチ&各メトリクス取り係 
まし : DB 周り →app 
とさ : app

自分は go で書かれたコードを適当に読んで適当に改善していました。
このブログでも主に app 周りの改善について記述していきます。

さんぽしさんのブログからの引用になりますが計測の部分は以下のようになっています。
Makefile で環境構築を、pprof で吐き出される画像は slack cat で slack に送信などは最強人間 CD のさんぽしくんがやってくださいました。

> メトリクスまわりは具体的には
> alp(アクセスログ解析してくれる君)
> pt-query-digest(スロークエリ解析してくれる君)
> pprof(Go のどの関数で時間がかかってるか調べてくれる君)
> あたりを使用しました。定番ですね

# やったこと時系列

## apache→nginx

apache で運用されていましたが気がついたら nginx になってました。
 さんぽしくんありがとう。

## index をはる

SQL もだいぶ遅かったと思うのですが気がついたら高速になっていました。
 ましくんありがとう。

## jwt 周りでなんか遅かったのをなんか直してくれた

初回の pprof が以下のような形でした。
<img src="/media/ntt-pprof1.png" alt="pprof1" title="サンプル">

あれ、handler が表示されてないな何かミスったかなと思っていたらましくんが authenticationJwt 遅くね？
なんかめっちゃ重いファイルあるよ？と問題点を見つけてくれたので。原因の究明と解決を行いました。

今回の原因としては失効済み JwtToken を外部ファイルに書き出して、middleware で認証する際に逐一そのファイルを読み込んで失効済みかどうかを確認していたところがボトルネックになっていることを発見しました。
ファイルを開いてみると非常に重かったので、失効済みの情報をインメモリに持つ方針を取りました。

またこの時点でインフラ担当のさんぽしくんは複数台構成にすることを指針にあげていたので、話し合って app 一台でとりあえずは進めてみるという方針にしてもらいました。

キャッシュの実装は以下のようなコードを準備していましたので、それを導入。

```go
// CacheJwt UserJwt created by tosa
type CacheJwt struct {
	sync.Mutex
	jwtsCache map[string]bool
}

// NewCacheJwt 新しいキャッシュ
func NewCacheJwt() *CacheJwt {
	m := make(map[string]bool)
	c := &CacheJwt{
		jwtsCache: m,
	}
	return c
}

// Append キャッシュに追加
func (c *CacheJwt) Append(value string) {
	c.Lock()
	c.jwtsCache[value] = true
	c.Unlock()
}

var mcJwt = NewCacheJwt()

/// ここまで
```

以下がファイルを読み込んでいた箇所です。キャッシュを導入することでだいぶ見通しの良いコードになりました。

```go
 // if already logged out
 // ここが怪しい
 // f, err := os.OpenFile(jwtRevocationListFilePath, os.O_RDONLY|os.O_CREATE, 0644)
 // if err != nil {
 // 	return nil, err
 // }
 // defer f.Close()
 if exist := func() bool {
 // muForFile.Lock()
 // defer muForFile.Unlock()

 // scanner := bufio.NewScanner(f)
 // // ファイルの中にjwtが存在しているのならば
 // for scanner.Scan() {
 // 	if reqJwt == scanner.Text() {
 // 		return true
 // 	}
 // }
 return mcJwt.jwtsCache[reqJwt]
 }(); exist {
 return nil, errUnauthorized{}
 }
```

ログアウトする際にこのキャッシュに jwt を保存しておけば実装完了です。
得点が 1000 点超えくらいになり、メモリにだいぶ余裕ができました。

以下が実装後の pprof です。各 handler が見えてきましたね。
バランスが取れていてとても美しい pprof だと思います。
<img src="/media/ntt2-pprof.png" alt="pprof1" title="サンプル">

## 複数台構成(app1, DB1)

さんぽしくんが複数台構成へのインフラ整備を行ってくれていました。
ISUCON10 での反省が生かされてすぐに実行できるところがすごいところですね。

> この時点で DB が CPU を食っていたのでキャッシュや index は他のメンバーに任せるとして DB を別のサーバーに移す作業に取り掛かりました。
> そして謎に詰まったので後回しにしました。(後に init.sh だけ書き換えただけではサーバー内の DB の向きが切り替わらないのか！という初歩的なミスに気がつきます)

## DB から base64 の画像を引っこ抜いて nginx から配信

次にどうやら Events のテーブルに base64 形式で画像が保存されている部分を発見しました。これは後々ボトルネックになると踏んだのでファイルを書き出して nginx に乗せようと方針が決まりました。

```go
type Event struct {
	Id int64 `db:"id"`
	ArtistId int64 `db:"user_id"`
	VenueId int64 `db:"venue_id"`
	GenreId int64 `db:"eventgenre_id"`
	Name string `db:"name"`
	StartAt time.Time `db:"start_at"`
	EndAt time.Time `db:"end_at"`
	Price int64 `db:"price"`
	EncodedImage sql.NullString `db:"image"`
	CreatedAt time.Time `db:"created_at"`
	UpdatedAt time.Time `db:"updated_at"`
}
```

DB に base64 形式で画像が保存されているのは過去問題(ISUCON7 参照)にもあった処理だったのでこちらも golang のスクリプトをあらかじめ用意しておきました。

と思ったのですが、用意したスクリプトがそのままファイルに base64 形式で吐き出していたようで、チームメイトが画像が表示されないことに四苦八苦していてとても申し訳ない気持ちになりました。

こちらも、きちんと画像を吐き出すように設定。また、putEventImage 関数で画像を更新していたのでこちらもファイルとして吐き出すように修正しました。

ここで今回の敗因になる部分なのですが、ファイルを書き出したあと、初期化する時に新たに保存されたファイルを削除することを忘れてしまっていました。

初期化処理時間は最大 20 秒だったので、30 秒以上するこの書き出し処理を導入することはできなそうだったので、どうすれば綺麗にできたのか考察中です。

## /login だけ別サーバーへプロキシ(→ app2, DB1)

ましくんが/login の暗号化処理が重いことを発見して、さんぽしくんがそのエンドポイントのみを別のサーバーに移してくれました。

## いろんなところでキャッシュを取りまくる

Get リクエストしか飛んでいない場所を中心的にキャッシュを取りました。
やり方は jwt の時と同様に golang の map に保存しました。

## イベントの画像の更新系が不安定に

default.png が返されるところに別の画像ファイルが返っているというエラーが表示されるようになりました。
こちらは、さきほど自分が実装したスクリプトのミスで、初期化時に前回のベンチで保存された画像も保持していたことが原因でした。

## Offset の高速化

ましくんが各 offset で取得しているデータをシーク法とよばれる方法を利用して高速化してくれました！感謝！！

## N+1

ここまできて、ようやく N+1 がネックになっているような箇所を複数見つけることができました、が SQL 力技力が足りずに解決できませんでした。join 句などがスラスラ描けるように練習していたのにいざ本番となるとなかなか難しいものですね。

## 再起動試験対策

今回はサーバー三台で DB が別の構成だったので、再起動試験にて各サーバーが立ち上がる順番が不明でしたので。
再起動試験対策のスクリプトを最後 15 分で仕込みました。

```go
for {
 dbx, err = sqlx.Open("mysql", fmt.Sprintf(
 "%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=true&loc=Local",
 user,
 password,
 host,
 port,
 dbname,
 ))
 if err == nil {
 break
 }
 time.Sleep(1 * time.Second)
}
```

こちらの sqlx.Open はコネクションプールを初期化するだけで DB に接続していないようなので、うまく動作しません。
正しくは以下のような形でした。

```go
 dbx, err = sqlx.Open("mysql", fmt.Sprintf(
 "%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=true&loc=Local",
 user,
 password,
 host,
 port,
 dbname,
 ))

 for {
 // ここで接続を確かめることができる。
 err := dbx.Ping()
 if err == nil {
 break
 }
 log.Print(err)
 time.Sleep(time.Second * 1)
 }
```

常日頃から自分が記述するコードの動作内容をしっかり理解すべきだということを再認識させられました。

# 結果

自分たちは team I でした！
再起動試験で失敗して 0 点 finish です。
優勝争いができていたので、残念。
悔しいですが、Try and Error and Error and Error です。

<img src="/media/ntt-score.png" alt="pprof1" title="サンプル">
<img src="/media/ntt-bestscore.png" alt="pprof1" title="サンプル">

負荷のレベルが 3 段階あって、最終段階で 27000 超えのスコアを記録できたのが非常にうれしかったです！ 
点数が上がるたびに興奮して奇声をあげてダンスを踊っていました。

# 原因

最後の DB 接続の部分だそうです。

# 感想・考察

NTT さんが用意してくださった問題は非常に良問でかなり学びが多かったです。
また、社員さんの雰囲気がとてもよく楽しそうな雰囲気が伝わってきたもで緊張せずに１日を集中して過ごすことができました！

結果を考察して次回への改善点を見つけることは大切なことなので協議についていいところ悪いところをあげるとすると。

## よかったところ

- 開始 1 時間の流れが非常に連携が取れてスムーズ
- 各担当がそれぞれゆるく連携しながら app,db, infra の各問題に集中して対応できている。
- 典型的なボトルネックの発見と対処法がすぐに思い浮かぶ
- 計測改善のサイクルを綺麗に回すことができた。

## 改善できる箇所

- 終了間近が余裕がなかったので、1 時間前には新規実装を止めて再起動試験に備えられるのが理想。(が、今回は画像配信エラーでつまっていたので...)
 順位にもよる。

- 再起動試験の際の db 接続のスクリプトを用意しておく

今回は結果は出ませんでしたが、かなり戦えるチームになってきたと思います。チームメイトに感謝です！！
 
 
 
 
次回作「ISUCON11」をお待ちください！
 
 
 
 

## 関連リンク

引用元
 
[NTT Performance Tuning Challenge に参加したこの日、人類は思い出した。再起動試験の存在を。奴らに最終スコアが支配されている恐怖を。](https://sanposhiho.com/posts/n-ptc2021/)

インフラ担当のさんぽしくんのブログです！ 非常に芸術点の高いタイトルとなっています。infra 目線の流れを知りたい方はめちゃくちゃ参考になると思います。

 

[NTT Perfomance Tuning Challenge に参加した](https://mesimasi.com/ntt-perfomance-tuning-challenge/)

DB と App 担当のましくんのブログです！ シーク法、今回初めて知りました（おい）。かなり難しい実装だと思うのですがさすがです。 index をはる技術は最強です。

## 補足

### ISUCON 名言

「推測するな、計測せよ」

### 謎のリズム組織

「ねえ、キャンペーンまでしたのにサーバー落ちているんだけどどういうこと？」

NTT主催のパフォーマンスチューニングコンテストに出場してきました。

NTT Performance Tuning Challenge参加してきてサーバーがI'll (not) be backと行ったきり戻ってこなかった話


## 2020 年を振り返って

だらだらと文章を書いていきます、あんまりまとまってはいないので読みづらいかもしれません。わからない部分があれば手をあげて質問してもらえると助かります。

1 年間ほとんどの時間を精神と時の部屋状態でパソコンに向かっていたような気がします。偉大なるニートへの第一歩です。
大学がオンライン、ゼミもオンライン、バイトもリモートなのでもはや自室から一歩も出ていない感じでしたね。心なしか季節感がなくて、去年の 12 月から今までが一瞬のように感じます。自分の 20 歳はどこへやら。

そんな生活をしているからか、高校時代の友達に会ったときに、彼らが「人生」を進めているのをみて、自分をプログラムしか書おらず話せるネタが一つも無くなってしまったと焦っている昨今でもあります。

今年一番よかったなと思ったことはプログラムを書いてお給料がもらえたことです。好きなことをやっているだけでお金が入ってくるのとてもいいです。

あとは、ある程度自分の思う通りの Web アプリケーションを組み立てられるようになったのもすごく良かったと思います。もともと、アイデアはポンポン出るタイプだったのですが、それをある程度、実装できるようになってきたのでとても楽しいです。来年もばんばん面白いものを作っていきたいと思います。

### アルバイト・インターンについて

-   1 年間くらい働かせてもらっているベンチャー企業
-   4 ヶ月間だけでしたが立ち上がりで手伝わせてもらった企業
-   メガベンチャーさん数社

どれもとても楽しかったですし、同じエンジニアの学生の人に会えてよかったです。
感想はこのブログに書いてあるのでよかったら読んでいってください。

### 進路について

いろいろな選択肢をとれるようにいろいろ活動していますが絶賛迷い中です。
相談に乗ってくれるよとか、自分の代わりに働いて養ってくれるよって方がいましたらご連絡ください。

### 個人開発について

いろいろ作ってきましたが主にはこの二つの web サービスを作りました

-   きみの宗教
-   student-salary

これらについての感想は割愛します。
student-salary は今現在、新機能作成中です。同じ学生の意思決定の助けに少しでもなれたらとても幸せです。

あとは flutter の練習で TimerMemo というアプリを作ったりしてました。Apple の審査がめんどくさいこと以外は IOS アプリも作ってて楽しいです。

自分で好きに機能をいじれるってとても楽しいですよね。死ぬほど楽しいですよね、何時間でもやっていられます。

サービス作っていく中で、プログラムの知識だけではなく、UI/UX、ビジネスモデル、作るアプリ周りのドメイン知識など色々な技術が必要なことがわかってきました。ここら辺は自分一人では追えない部分もあるので誰かと協力して作ったりしてみたいなと最近は考えています。デザインは他のサイトを参考にしたりしながら試行錯誤したり勉強したりしています、ボタン一つの形にもにも誰かの考えがあるのがとても良いです。Tailwindcss が最高なのでみんな使いましょう。その名の通り風のように css をかけます。あとは、開発だけではなくて、特定分野の知識 or コミュニティに属しているなどの要素がサービスには不可欠な気がしているので、もっともっと勉強したりいろんなところ行って、いろんな人に会って話してみたいです。

来年もアプリをいくつか作る予定です。

### やりたいことについて

-   大きな水槽に蟻を飼いたい
-   ピタゴラスイッチ作りたい
-   森の中でドラム叩いてみたい
-   向日葵と入道雲を見に行きたい
-   ある程度の長さの小説を書いてみたい
-   幻覚もしくは明晰夢を見てみたい

などがあるのでまだ死ねなそうです。明晰夢は昼の 10 時くらいにお昼寝したら見ることができました。(15 秒ほど)

小説は習慣化しないと書けなそうですね、コード書くだけで精一杯になっています。

### 音楽について

作業中は必然的な耳が空くので今年は音楽をいっぱい聴きました。

-   Yoasobi
-   ヨルシカ
-   pillows
-   ずっと真夜中でいいのに
-   ゆううつぼ
-   やくしまるえつこ

なんかを最近聞いてます。Youtube でよく見かける曲が多いいですね。最近はタイムラインで見かける曲を聴いて、流行に乗れるように頑張っていますので、おすすめの曲があれば積極的にツイートお願いします。

一時期、レクター博士に憧れてゴルドベルグ変奏曲ばかり聴いてましたがさすがに飽きました。クラシック何もわからんですが、嫌いではないのでおすすめあったら教えてください。

余裕があったらピアノ習いたいです。

### 読書について

電車の中でよく読んでいたのですが、今年は通学がなくてあまり読まなくなってしまってので少し残念です。
技術書とかも買い漁ってますが、ほとんど積読状態です。いつか読むとかいってましたが、そのいつかはとうとうこなさそうです。

進歩としては今年初めて数学書を一冊読み切りました。理解していく感覚があって楽しかったです。

読書といいつつ漫画を紹介すると怒られそうなのですが、チェンソーマンにハマりジャンプを電子版で定期購読してました。悪魔のデザインとマキマさんがかっこよくて痺れます、おすすめなので読んでみてください。

あとは、悩んだ時は岡本太郎さんの著作を読むといいです。たいていの事はどうでもよくなります。(が本質的な解決はしない)

### 2019 年に立てていた目標

パソコンのメモにくしゃくしゃに丸めた紙ゴミみたいなファイルに目標が書いてあったので引用します。

-   atcoder 水色(現在緑)
-   個人開発で月 30 万円の売り上げ(現在月 4 円)
-   本を一日一冊読む(絶対読めてない)

でした。
目標って立てるだけだと、叶わないみたいですね。

### 来年の目標について

来年までに温泉入りながら考えます

最近はいわゆる心地よで好きなことを続けている形だったので、来年はもっと挑戦的に生きていきたいなと思ったりしています。

### まとめ

書いていて思ったのですがなんだかんだプログラミングが好きみたいですね

これはまさしく恋なのでクリスマスも一緒に過ごしました

実力云々はともかく好きなことが見つかったこと自体が良かったと思っています。
来年もプログラム書いて、別の面白いこと探して元気いっぱいに過ごせたらなと思います！！

### 追伸

進路の方、進捗いかがですか？？


2020年を振り返りをだらだらと書いていきたいと思います。

2020年を振り返って


## 概要

firestoreで運営しているアプリケーションがあり、データの統計処理を行ってクエリの数を減らしたかったのでcloud functionを使用して自動化させました。

## 要約

これで毎日動作させる関数の出来上がり
```js
functions.pubsub.schedule('every day 00:00').onRun((context) => {
    \\ 内容
})
```

## 内容

個人開発している[アプリケーション](https://student-salary.com/)のデータの処理をcloud functionを使用して定期的に実行できるようにしてみました。

まずはfirebase-toolsをインストール
```zsh
npm install -g firebase-tools
```

サイトからツールにログインをして、functionsの初期化を行います。
自分はすでに使用している本番用のAppを指定して、言語はJavascriptにしました。(Typescriptは学習中)

```zsh
# プロジェクトディレクトリ内
firebase login
firebase init functions
```

functionsの中にindex.jsが作成されていると思うのでここに目的の処理を記述していきます。

```js
// The Firebase Admin SDK to access Cloud Firestore.
const admin = require('firebase-admin');
admin.initializeApp();

// データベースの参照を作成
const db = admin.firestore()

exports.helloWorld = functions.https.onRequest((request, response) => {
  functions.logger.info("Hello logs!", {structuredData: true});
});

```

これで、リクエストが飛んできたらHello logs!と出力するエンドポイントが作成できます。
すごく簡単、デプロイもコマンド一発です。

```zsh
# cloud functionのみデプロイ
firebase deploy --only functions
```

ちなみになのですがonRequestはローカル上でfirebase emulatorを使用してテストすることができます。

そんなこんなでcloud functionの概要を把握したので目的の処理であるデータ集計を作成していきます。functionsのpubsubを使用して定期実行されるようにします。pub/subはemulatorにはないので自分は本番で害のないコードを動かしてみてテストしました。

schedule内の期間指定ですがUnix の Crontab と AppEngine の両方の構文をサポートしているようです。今回はAppEngineの記法で指定しました。every 5 minutesに指定すれば5分ごとなど詳しく設定することができます。

関数の内容ですが、firestoreからデータを取得して取得したデータを処理した結果を保存しおくようにしました。具体的には全てのデータの時給情報を区間ごとに何件あるのかを調査して登録しておくことにより、グラフを表示する際にその結果だけ取得するだけで大丈夫なようにしました。


```js
exports.createSalaryMap  = functions.pubsub.schedule('every day 00:00').onRun((context) => {
    functions.logger.info("Hello logs!", {structuredData: true});
    db.collection('datas').get().then((querySnapshot) => {
    // datasの統計処理を記述

    db.collection("result").add({
      create_date: createDate,
      data: result
    }).then((res) => {
      return functions.logger.info("success");
    }).catch(err => {
      return functions.logger.info(err.message);
    })
    return functions.logger.info("function end");
  }).catch( (err) => {
    return functions.logger.info(err.message);
  })
```
(awaitで書き直す予定)

ここまででできたらデプロイしてコンソールのcloud functionを確認してみます。

![](/media/cloudfunction.png)

無事設定できていました。今回は１日おきにという目的が達成できたので問題なかったのですが日本時間の0時に動作させたいなどという場合はTimezoneを指定してあげる必要もあります。


# まとめ

firestoreを使用するなら避けては通れないcloud function。意外と簡単にデプロイまでできたのでこれからどんどん処理を自動化させてより、みやすいグラフやデータを表示できるようにしていきたいなと思います。

サーバーレス楽しい。


## 参考文献

- [cloud firestoreのチュートリアルリンク](https://firebase.google.com/docs/functions/get-started?hl=jad)

- [クイックスタート: クライアント ライブラリの使用(Pub/Subの概要)](https://cloud.google.com/pubsub/docs/quickstart-client-libraries?hl=ja)

- [関数のスケジュール設定](https://firebase.google.com/docs/functions/schedule-functions?hl=ja)

firestoreのデータの集計をcloud functionの練習も兼ねて自動化してみました。

一日おきのデータの集計処理をcloud functionで自動化してみた


## 要約
- リーダブルコードを読み返して気になったところをまとめる
- 他人が最短時間で理解できるように書く
- 日頃からリーダブルコードを意識しないと身につかなそう

## 内容

個人開発しているとどうしてもコードは汚くなりがちです。原因としては機能を実装することに意識がいき過ぎてしまう事が多いいことと、一度機能を実装したらそのコードを読み直さないことなどがあげられます。（自分のことです）

開発を継続的に続けるためには、やはりコードの綺麗さを保つ必要があるななんて常々おもっていましたが、そもそも綺麗なコードってなんだろうという部分が自分の中であいまいでした。

そんなこんなで、本屋で久しぶりにリーダブルコードを立ち読みする機会があり、やはりいい本だなと思ったので購入して読んでみました。

実は2年前くらいに大学一年生のころ一回読んだ事があったのですが、再度読み返してみると実践できていないことばかりでとてもためになりました。なので、自分が気になったところを引用しながらまとめていきます。


>鍵となる考え
>コードは他の人が最短時間で理解できるように書かなくてはならない
p4

これが、リーダブルコードにおける「いいなコード」の定義でしょう。いいコードと言うのは他人が読んで（もちろん自分も含め）最短時間で理解できるように書かなくてはならない。もちろん綺麗なアーキテクチャなどはありますがそれはソフトウェア全体の話で、もう少し範囲を狭めて綺麗なコードという観点で言えばなるほどと思える定義だと思います。

理解する時間が短くなるというのはとてもいいメリットで、昔自分が書いていたコードを読み返すと何をしているのかが分からず、一から理解していかなくてはならない作業の時間を短縮できます。

また、チーム開発でもいちいち説明せずにチームメンバーが理解できればスムーズ進みそうです（自明）。


>コードを「段落」に分割する
p53

こちらは、何行かのコードを書く際に処理のまとまりごとに段落をつけろという文脈です。
DB処理を書く段落、データを整形する段落、データを表示する段落と処理ごとに分けることでみやすくする事ができるようです。


>関数から早く返す
p91

これは自分でも実践できていたもので、if文のネストを小さくする際にはまずはこの工程ができないか確認してみます。
実践もしやすくコードも読みやすくなるのでおすすめのやり方です。


```php
if (empty($key)) {
    return;
}

...
```

> 要約変数を使う
p101

サンプルコードとしてはこんな感じ。isAdultが要約変数、human.age >= 20でも十分にわかるけどisAdultの方が変数が何を示しているのかわかりやすい。条件式が二つ以上のになるともっと効果がありそう。

```js
const isAdult = human.age >= 20;
if (isAdult) {
    console.log("お酒買えるで")
}
```


> 巨大な文を分割する
p106

本書ではjQueryのサンプルコードで記載されていた。繰り返し使用する処理などは変数にしてまとめておいたりする。
できるだけ巨大な文を分割するようにしていく。
DRY(Don’t Repeat Your Self：繰り返しを避けること)原則などとよばれているものでもある。

よく言われている事だけど結構できていないこともある。
あるロジックの処理を変更しようとしたときに複数箇所変更しなくちゃいけなくなると、たぶんDRYができてない。


> 「このライブラリにXYZ()関数があればなぁ」と思ったら、その関数を自分で書けばいいのだ！
p133

~~それで書ければ苦労しない~~

だいたいやりたい処理は標準ライブラリにあるのでそれを調べたあとの話。
素だと使いづらい処理をまとめて一つの関数にするとかでも有効。



> その機能の実装について悩まないで --- きっと必要ないから
p168

まじこれ、使う処理だけ書きたい。
個人開発でもコード書く前にユースケースの確認くらいしておきたい。


> クラスのインターフェースを定義する
p198

どんなクラスが欲しいのかを設計してインターフェースを定義しておく。
設計しながらコードを書くとだいたいろくなことにならない。

## まとめ

ぶっちゃけ本書に書いてあることの二割くらいしか実践できていない（もちろん本書に全部従うつもりはないが）。
コードを書く時は手元に置いて時々見直そうと思います。

そもそも、コードをなぜ綺麗に保たなくてはいけないのかですがこれは開発するモチベーションにとても関わってくる（汚いコードだとモチベーションは下がる）部分だからです。
このコードはいいコードか？と立ち止まって考え、きちんと意識しながらコードを書いていきたいと思います。

友達との待ち合わせ時間にリーダブルコードを読んでやはり名著だったので気になったとこをまとめてみる

今更リーダブルコードよんでみた

## 要約

- 複合クエリをリクエストする際には複合インデックスの作成が必要
- コンソールのエラーから作成ページへのリンクがでているのでそれに剃って作成。

## 内容

清々しい日曜日に趣味で開発している Web アプリを弄っていたところ以下のようなクエリを firestore に飛ばしたらエラーが表示されました。

```js
return await db
 .collection("jobs")
 .orderBy("create_date", "desc")
 .where("work_type", "==", "インターン")
 .startAfter(num)
 .limit(20)
 .get()
 .then(function (querySnapshot) {
 hogehgoe;
 });
```

よくよく調べてみるとこれは firestore の複合クエリに当たるものだったよう。
今回で言うと orderBy で create_date の指定、where で work_type の二つを指定しているので該当していますね。

> 複合クエリ
> 複数の where() メソッドをつなぎ合わせて、より具体的なクエリ（論理 AND）を作成することもできます。ただし、等価演算子（==）と range 句または array-contains 句（<、<=、>、>=、array-contains）を組み合わせる場合は、必ず複合インデックスを作成してください。

引用元:[Cloud Firestore で単純なクエリと複合クエリを実行する](https://firebase.google.com/docs/firestore/query-data/queries?hl=ja)

なるほど、複数のクエリを組み合わせて使用する時は複合 index を作成する必要があるらしい。
親切に google console のエラーの欄に複合インデックスを作成するページへのリンクが出ていたので、それを踏んで firebase から複合クエリを作成（作成に 3 分ほどかかりました）。
再度、同様のクエリを飛ばしてみたところ正常にデータを取得する事ができました。

参照:公式ドキュメント [Cloud Firestore でのインデックス管理](https://firebase.google.com/docs/firestore/query-data/indexing?hl=ja)


## まとめ

NoSQL あたり、もうすこしちゃんと調べて開発したいと思いました。(小学生並の感想)
このあたり RDB の方が柔軟なのかな。

## 追伸

katexの設定があって入れてみたら数式もかけるそう。
神

$
\frac{1}{2}
$

複合クエリをリクエストする際にエラーが出たのでそれの解消方法を軽く載せて置きつつ、そのあたりを調査。

Firestore の複合クエリってなんだ


お疲れ様です。

今日のブログは[きみの宗教.com](https://syukyou.vercel.app/) を作成した経緯とどのように作成して行ったのか記録しておきたいと思います。
また、楽に開発するために使用したツールなどもいくつか紹介していきたいと思います。

## 怠惰に開発するようになった経緯

このきみの宗教.com の web アプリの構想は夏休みが始まる前くらいに思いつきました。そこから、どうやって作っていこうかな〜と何度か軽くコードを書いて試行錯誤していました。

### サーバーサイドを go で書いて、フロントで react か vue を使用する構成

よっしゃ作ったるぞーと一番初めに思いついた構成。go 好きだし、本で読んだアーキテクチャで作れば勉強にもなるし一石二鳥やん！って意気込んでいました。
が、なんとなくどう書けばいいかわかってるのが原因なのか、それを作る過程がある程度想像できてしまったが最後、ほとんど作成してもいないのにとてつもなく面倒くさく感じてしまいました。また、go で json を返すサーバーを立てて vue などでフロントを描くとなると、フロントは静的ホスティングサイト、サーバーはまた別でデプロイみたいな構成になるのですが、それも疲れそうだなぁと。またログイン機能も実装しなくてはならないので、それもまたまためんどくさそう...

コードを書くこと自体は最高に楽しいのですが、個人開発なので時間を取られすぎるのは避けたいところでしたし、わざわざめんどくさいことをやるやる気も出なかったので(おそらくこの頃インターンの業務だけで疲れていたのも起因している)
そんなこんなでこの構成での開発はボツになりました。

※go はめちゃくちゃ書きたいです！

### yeah!! your on rails 構成

次に考えたのはみんなお馴染み rails 構成です。ログイン機能も device を使用すれば一瞬で完成しますし、何より heroku との相性が最高なのでデプロイも瞬殺です。画像生成のコードも簡単に書けるので ogp 生成も楽にできるだろうと思いこれで作ってみようと決断。

しかしながら、rails はその名の通り rail への乗り方を知っている人間であれば爆速で開発できるのですが、いかんせん自分の rails に対する知識はほぼ初心者に近く、また Ruby も見様見真似でしか書けないので、勉強するコストが高くなってきて開発体験があまり良くなくなってきてしまいました。(もちろん自分の無勉強が悪いだけであり Rails は何一つとして悪くない)

結局、ログイン機能をコマンド一発で生成しだだけのコードは github のリポジトリの奥深くへと消えていきました。

悲しいことにどちらの構成でも作り切ることができなかった、、、やはり俺には個人開発なんて無理なんやなどと自暴自棄になり、家を飛び出しコンビニエンスストアでハーゲンダッツを買いに行きました。(ちなみに抹茶が好きです)

その数日後、犬の散歩をしている途中にまた別の構成が浮かびました。

### Nuxt + firestore 構成

~~お前、この前の面接でサーバーサイドエンジニア志望ですとか言ってたよな？？go で API サーバー書くのが楽しいとどうとかって言ってたよな？？あの頃のお前はどうした！！~~

こうして何もやりたくない怠惰な開発の軸が決まりました！

ogp 生成は cloudnary を使用することにより簡単に生成。

Twitter login はもちろん firebase が用意してくれています。

firebase 万歳！！Google 万歳！！

また、CSS を自分の力のみで書くのはとてつもなく難しい作業なので最近流行りの tailwind css を使用して作成していきました。他のフレームワークみたいにコンポーネントが用意されているわけではありませんでしたが、簡単に綺麗な UI を自分の思う通りに書けたので大満足。次回からも個人開発ではこれを使用して作っていきたいですね。

フロントエンドは Vue とか React は一通り触ったことがありますが、そこまで詳しいと言うわけではないのであとはコピペ+ガシガシ力技で実装で完成まで持っていきました。

ちょうど一週間で完成させることができました。めんどくさがりな自分でもこのくらい短期間であれば集中力が持つようで良かったです！

キャッシュなどをあまりやらなかったせいで、(store すら書いてない...)
firestore の無料枠をちょっと超えてしまいましたが、金の力で解決 💪(10 円くらい)

こうして無事に怠惰な自分でも個人開発で Web アプリを作ることができました！

### 最終的な技術選定

Nuxt(Vue) フロントエンド

firestore/auth データベース、認証

vercel デプロイ先

Cloudinary ogp 生成

## 結論

完成しないより完成した方がいい
アイデアを考えるのは楽しいが、実現させるのは大変
(当たり前の結論に着地)

用は完成させるにはの部分で色々なサービスに頼るなど出来るだけ楽をすることを考えるようにすると幸せになれるってことです。

もちろんこれはアプリを作る目的によっても上のやり方がいいかどうか変わります。

インターンやアルバイトなどで実装経験として提出したいのであれば、きちんと go なり ruby なりで実装してアプリを作成すべきでしょう。

今回の自分の目的としてはきみの宗教.com のアイデアを実現させる部分にあったので、上のような形を取りました。

ただ、この構成の楽さを覚えてしまったので次回以降も個人開発ではこんな感じでいきたいと思っています。

最後になりましたが、今回作成した宗教.com のサイトは[こちら](https://syukyou.vercel.app/)です。ご機会があれば立ち寄ってみてください！

ではまた。


あなただけの宗教を作ることができる宗教.comというWebアプリケーションを開発しました

怠惰な学生エンジニアはWebアプリを作る夢を見る


今週末あたりからやらかしてしまったこととその顛末と最終的にどうやってアカウントを復活させたかを記録したいと思います。

あやまって github をログアウトしてしまった。
他の端末でログインしていないか確認したがすべての端末で謎にログアウトしていた

二段階認証のパスワードがスマートフォンに[^1]謎に来ておらず

リカバリーコードを保存していたがその保存したやつは一番最新のものではなくかなり古いもの（一度リカバリーコードを更新していたのだが更新後のリカバリーコードは保存していなかった。

以上の条件を満たして自分は無事に github にログインできなくなってしまったのだ。

# この状況からのアカウントの復活方法

[公式の方法](https://docs.github.com/ja/github/authenticating-to-github/recovering-your-account-if-you-lose-your-2fa-credentials)
を主に参考にして作業をすすめた。自分は SSH トークンを登録したためそれを利用して運営に連絡をした。

連絡したあと営業日（平日）の四日後に無事に二段階認証を解除しましたとの旨の連絡が帰ってきてアカウントを取り戻すことができた。

最近は頑張って草をはやしているのでアカウントが消失したらショックだったがなんとかなったのでよかった。

今現在アカウントに以上の理由でログインできなくなってしまった方もまだ復活で切る可能性があるので落ち着いて欲しい。

新しく二段階認証を設定する際は何回もドキュメントを読み直して recovery code もしっかりと保存しておいたため、二度とやらかすことはないだろう（フラグ）

[^1]: 謎になどと言っているがおそらく QR コードをスマートフォンで読み込むことを忘れて二段階認証が完了したと勘違いしていたのが原因だとのちにわかる。


先週末あたりからやらかしてしまったこととその顛末と最終的にどうやってアカウントを復活させたかを記録したいと思います。

github の二段階認証(two-factor authentication)のコードがわからずさらにリカバリーコードを無くしてしまった話

![DMM本社](/media/dmm_intern1.jpg "イメージ")
※写真は出社している様子を思い浮かべた脳内のイメージです

9 月 7 日~ 9 月 18 日 DMM さんのインターンシップ DMM Guild に参加して来ました！
自分が実装したタスクを振り返っていきたいと思います。

## [issue1] Go+lambda の API エンドポイントを生やす

Golang で何かしらコードが書きたいと思っていたかつ、面白そうだってたのでアサイン。アーキテクチャに DDD を採用しており、あっ[あの本](https://www.amazon.co.jp/dp/479815072X/ref=cm_sw_em_r_mt_dp_58hzFb5MD319D)でやった構造だ！と少し興奮気味に作業を開始しました。
何度か自分でも API を生やす実装はしてきたので、repository→infra→dto→usecase と詰まるところなくスムーズに実装できたと思います。テストがきちんと sql mock で書かれていたり、scheme spy を使用して ER 図がめちゃくちゃ見やすく可視化されていたり、docker コマンド一発で環境が整えられたりなどすごく開発体験が良かったです。今まで、AWS lambda を触ったことはなかったのですが、実装をしていく中で概要が掴めました。(呼ばれてから起動する仕組みが面白い...)

## [issue2] DB の ER 図を自動で生成+ホスティング

一つ前のプロジェクトで [scheme spy](https://github.com/schemaspy/schemaspy) がすごく便利だと思った矢先に面白そうな issue があったので次はこちらにアサイン。AWS にあるデータベースに接続して schemespy で ER 図を静的ファイル(html etc...)に書き出して github pages でホスティングする。さらに、定期的に実行して最新に保つようにするが目的の設計でした！

db が private subnet にあるため踏み台の EC2 を経由して接続しなくてはいけなかったり、docker 内に scheme spy の環境を整えていたため、ローカルのデータベースに接続してテストするときにつまる（Docker 内から host に通信するときには host.docker.internal という DNS 名が用意されている）などの試行錯誤を重ねて実装方針を考えていきました。

ただ結果として Docker 内に環境を整えていたのですが Docker の外と通信をする(中の環境から ssh でポートフォワーディングをしなくてはならず鍵を整えたりするのが~~めんどくさ s~~)
のが難しかったので circle ci の machine 上に直接 scheme spy を動作させる環境を整えて実装し完成させることができました。

~~ただ、このあと ci 内で git push origin master をしていた関係で土日の間中 ci を回し続けてしまったことは秘密です。ご迷惑をおかけしました。~~

## [issue3] CSV データから sitemap 形式でデータを変換する cli ツールの作成。

CSV のデータを GoogleBot と言った検索クローラーに、クロールさせる URL の一覧を出すサイトマップを書き出す cli ツールを 1 から設計して作成しました。こちらもドメイン駆動を意識して、file の書き出す操作の抽象化を意識して完成させました！
golang にも xml へ変換する encoding/xml がありますが、自分は text/template を使用して実装しました。csv を一行ずつよみこんで go の構造体に落とし込んでそれを書き出すという単純な処理でしたが、なかなか骨がいる実装でした。とくに設計部分のファイルの書き出しをどのように書くべきなのか？に非常に迷い、最終的にはモデルに基づいた XXXWriter みたいなインターフェースを定義してそれを xml で書き出すように実装することに方向性をきめました。I/O 処理なので普通にインターフェース噛ませずに書いてもよかったかもとおもいつつ、設計は場数を踏んで経験していきたいって思いました。

```
/cmd
/repository
/infra
/usecase
/model
go.mod
go.sum
```

ゼロから設計ははじめてでしたが、csv のモデルのデータをきちんとモデルに定義して見やすい構成になったのではないかと思います。~~こちらは事業領域が自分の興味のある領域だったのでとてもやる気が出ました（略)~~

## [issue4] html ファイルタグを取り除く

上の cli を作成している最中に気がついたのですが csv の中に html タグが含まれているものがあったので文字列操作を用いて取り除くスクリプトを上の cli に取り入れました。 タグを xml 特有のエスケープ文字に変更する関数を作成して model に set する際にそのカラムに挿入する前に実行されるようにしました。

## 意識してたこと

自分で実装を考えてみて、つまったら躊躇わずエンジニアさんに相談する。
自分で実装方針を立ててみて、試行錯誤して実装してみる。
好きなこともやる、面白いと思ったタスクをとる。
駄洒落を思いついたら times にきちんと記入する

## 楽しかったこと

discord をつなぎながら作業してたのがめちゃくちゃ楽しかった。雑談しながら開発することによって脳内が整理することができて捗りました。~~声がでかいのでうるさかったかもしれ n~~
つまったときは画面共有で他の人に気軽に質問できる環境が最高でした。
times 文化もインターン生内で広まっていてとてもよい雰囲気だなと感じていました。

また、DMM ギルドの性質上、issue ごとに様々な部署を横断してプロジェクトのコードを読むことができたのでとても楽しかったです！エンジニアさんも部署ごとの特性がでていました。

また issue のポイント制が作業の粒度や難易度感を感じることができて自分的にはとてもおもしろかったです。

今回から Thanks と呼ばれる周りの人を助けるともらえるポイントを獲得したので
Thanks 賞をいただきました！焼肉代に使わせていただきたいと思います。

これで僕の夏休みの予定は全て終了です！
秋も頑張ります！

9/7~18日でDMMのインターンシップに参加してきましたことを実装を中心に振り返っていく記事です。

DMM GUILDに参加して来て楽しかったよって記録

9/12 開催された ISUCON10 に[さんぽしくん](https://twitter.com/sanpo_shiho)と[ましくん](https://twitter.com/masibw)と一緒にチーム雑用係として参加して来ました！

※ISUCON とは IIkanzini Speed Up Contest の略

チームを組んだ経緯と雑用係の名前の由来。
<img src="/media/isucon10-1.png">

# 開催前

チームメイトと時間をきめて三回練習をしました！

初めの一回は Makefile と最初の一時間の環境構築の練習。他の二回はある程度の時間をかけて本番と同じような形で訓練しました。

練習では isucon7, isucon8 を主に使用しました、この二つは conoha にイメージがあるのでボタンをおすだけで簡単に環境構築することができておすすめです！

あとは役割分担を決めていてさんぽしさんがインフラ、ましさんが DB と App、自分が App を担当することになりました。
前半 1 時間の流れは詳細につめていて一人ひとりのやることが明確になるようにしていました。(make やるかかり、git 管理係、...)

# 当日

環境構築の関係で競技は 12:20 開始、21:00 に終了。
最初の 1 時間はベンチが落ちるなどアクシデントがありましたが、そのほかはいつも通り準備をすすめる。(運営さんめちゃくちゃ大変だろうなと思いつつ、、お疲れ様です 🙇‍♂️)

データベースのテーブルが二つだけだったり、マシンリソースがあまりないことを確認しつつ。

pprof 導入して json が遅いな〜とか思って golang の encoding は遅いってどっかで聞いたことがあったので高速化方法を探し実装してみることに。時間がかかりそうかつ、ひとつ変更してもあんまりスコアが変化しなかったのでとりやめに
（後半でましくんがばしっとここらへんやってくれました）

決定打となりそうなボトルネックがすくない感じでしたが、ベンチをみるかんじ nazoote でタイムアウトしているとの文言があったので自分がそこを改善することに。

コードを見てみると

```sql
query := fmt.Sprintf('SELECT * FROM estate WHERE id = ? AND ST_Contains(ST_PolygonFromText(%s), ST_GeomFromText(%s))', coordinates.coordinatesToText(), point)
```

なんじゃこのクエリ〜〜〜
ST_PolygonFromText??? ST_GeomFromText???なにこれみたことないってなったのでとりあえずコード読みつつこれを調査。

※めちゃくちゃ参考にした記事>>>>[MySQL で GIS データを扱う](https://qiita.com/onunu/items/59ef2c050b35773ced0d)

コードをよんでるとどうやら POST された座標データからまずは最大と最小の緯度経度をわりだして四角い範囲にある物件を取得してからひとつひとつ円の中に入っているかどうかを調査していたので N+1 案件だということがわかった。
ローカル上で上の記事を参考に実験して estate コラムに

```sql
latlon POINT
```

を追加して initalize で値をセットして(sql 初心者すぎてめちゃくちゃ重たい処理をかいて制限時間を超えてしまい sql の書き方チームメイトに泣きながら教えてもらいました)

```sql
"UPDATE estate SET latlon = POINT(latitude,longitude);"
```

一発ですべてのデータを取得できるように

```go
query := fmt.Sprintf(`SELECT * FROM estate WHERE latitude <= ? AND latitude >= ? AND longitude <= ? AND longitude >= ? AND ST_Contains(ST_PolygonFromText(%s), latlon) ORDER BY popularity DESC, id ASC`, coordinates.coordinatesToText())
```

点数変わらなかったけどエラーは消えたのでよしって感じでしたが、2 時間位これに費やしてしまいました。

なかなか点数があがらないなか、チームメイトが CPU の使用率のほとんどが DB に張り付いていることを発見。
ましくんが DB の方を一通り終わらせてくれて App の実装に参戦 、さんぽしくんが複数台構成、キャッシュをすすめてくれました。

自分も app の改善を進めていましたが有効打にならず+ベンチが通らず。

結果としては本戦出場ラインにとどかず終了となってしまいました。

# 振り返り

## 反省点

1. DB が張り付いているあたりからインメモリキャッシュ戦略をとればよかったものの自分の初動が遅れてしまい実装できず...
2. pprof で異常がないあたりから別の原因を探るべきだった。
3. 計測が大切だとわかっていたが計測内容が網羅しきれていなかったこと

## 良かった点

1. 練習した初動はとてもスムーズにおこなえた！
2. ローカルに環境構築することができた！
3. 楽しかった！

反省点はいろいろあり悔しい結果でしたが、初出場にしては善戦だったと思います。
まだまだまだまだ高速化できる観点があってやはり ISUCON はおもしろいかつ勉強になるなと実感しました。

またチームメイトの向上心と技術力をめちゃくちゃ尊敬しているので負けないようにこれからも学習していかなきゃなといい刺激でした。

**来年はもちろん本戦に出場するので一年間楽しみにしていたいとおもいます！**

<blockquote class="twitter-tweet">サーバーをぶっ飛ばす！！！！ <a href="https://twitter.com/hashtag/isucon?src=hash&amp;ref_src=twsrc%5Etfw">#isucon</a>&mdash; とさ (@tosa_now) <a href="https://twitter.com/tosa_now/status/1304620400890884096?ref_src=twsrc%5Etfw">September 12, 2020</a></blockquote>

## チームメイトの ISUCON 参加ブログ

[ましさん](https://mesimasi.com/isucon10_q_go/)

[さんぽしさん](https://sanposhiho.hatenablog.com/entry/2020/09/13/132433)

9/12 開催された ISUCON10 にさんぽしくんとましくんと一緒にチーム雑用係として参加して来ました！

ISUCON10予選に初出場して来た記録

とさです。

夏休みの 8/31~9/4 に開催された mercari online summer internship に参加して来ました！

golang からプログラミングを始めたといって過言がない自分としては興味のある内容で、楽しい一週間でした！！

# 概要

> Online Summer Internship for Gophers 2020 は、メルカリ・メルペイで採用されている Go をハンズオンなどのワークショップを交えつつ学ぶ、短期インターンシップです。
>
> 構文解析をし抽象構文木（AST）を得て解析する方法から、型情報を取得する型チェック、静的単一代入（SSA）形式への変換とそれを使った解析まで Go の静的解析を深く学ぶ
>
> Go の静的解析ツールの開発に取り組むことで、一段飛び抜けてくわしくなる etc..

詳しい概要等はメルカリの web サイトでご覧ください
(https://mercan.mercari.com/articles/22800/)

# 参加が決定するまで

golang がインターンでかけるなら応募するしかないと応募がかかった段階で申込みました。
今までプログラミングでやってきたことなどもろもろなどを記入する書類選考と golang を使用して解く三問くらいのコーディングテスト。~~問題文が英語ですこしびびりつつ~~。最後に面接をして参加させていただくことがきまりました。

面接ではその時取り組んでいたもの（go で作るインタプリタ）についてや、メルカリとメルペイのサービスについて話したりしました。話題のウイルスで人と全く話せなかったので面接官と話している時間はとても楽しかったです！

# 準備

golang は趣味ではよくかいていますが、アルバイトとかで書いたことがなかったので理解が足りるか少し不安気味。
また静的解析といわれても、Javascript とか書いてるとででくるあの真っ赤なやつくらいのイメージしかないくらいの知識でした。

準備といってもしっかりとしたものではないですが、面接の時にも話した go でつくるインタプリタをすこしすすめて字句解析や抽象構文木っていうのがいつも動かしているプログラムの下にあるんだなくらいに理解をしておきました。

# 講義編

初日と三日目は講義編でした！講師は[tenntennʕ ◔ϖ◔ʔ ==Go](https://twitter.com/tenntenn)さんでこの[スライド](https://docs.google.com/presentation/d/1I4pHnzV2dFOMbRcpA-XD0TaLcX6PBKpls6WxGHoMjOg/edit)を元に行われました。
（なんと無料で公開されています。すごい）

講義資料が本当によくまとまっているので、開発中も閲覧しながら参考にしていました。

講義の合間合間に[TRY]で学習したことをもとに解析ツールを実際にコードを書いてみたり、他の参加者さんの作成したコードを読んで学習していくことで理解がふかまった気がします。

抽象構文木の探索の際に**深さ優先探索**の話題がでてきたときは競技プログラミングでやったやつや！ってすこし感動したり...

また go 言語が parser や go/analysis パッケージなどを用意してくれているためツールの開発に専念できる点がとてもよさげでした。

# 開発編

二日目と四日目、五日目は学習した内容をもとに実際に静的解析ツールをつくってみようという作業時間でした！Remo とよばれるテレビ電話サービスをつなぎながら他のインターン生ともくもくと開発をしていました。

自分はみっつほど静的解析ツールを開発しました。

※静的解析とは**プログラムを実行せずにソースコードを解析すること**

## errchecker

errchecker は返り値として error を指定している関数が error を返さずに nil だけを返している場合に指摘するツールです。

[![harukitosa/errchecker - GitHub](https://gh-card.dev/repos/harukitosa/errchecker.svg)](https://github.com/harukitosa/errchecker)

## がんばった点

実装的には ast.FuncDecl,ast.FuncLit を走査して返り値に error を指定しているかどうかとその場所(index)そのあと関数内部の処理のなかで return 文をさがしてきちんと error を返しているかどうかを確認していく方向性でいきました。

### 複数の if - elseif - else 文を再起的に対応しなくてはいけなかった。

関数の内部を一行ずつ走査していく関係から分岐の内部もしらべなくてはいけないので if 文、else 文のなかで return しているかどうかを確かめる処理を再起的にかきました。可読性が低くなってしまったのでもっといい方法があったら修正したいです。

```go
// ifstmtProcess is *ast.IfStmt processe
func ifstmtProcess(stmt *ast.IfStmt, idx int) bool {
	flag := true
	flag = isReturnNil(stmt.Body.List, idx)
	switch e := stmt.Else.(type) {
	case *ast.IfStmt:
		flag = ifstmtProcess(e, idx)
	case *ast.BlockStmt:
		flag = isReturnNil(e.List, idx)
	}
	return flag
}
```

### 通常の関数だけではなく無名関数の場合もきちんと指摘するようにした

~~無名関数のことをわすれていた~~

```go
// testコード
// 無名関数の場合も指摘
func anonfunc() (int, error) {
	s := func(src string) (int, error) { return 2, errors.New("error") }
	return s("hogehoge")
}

func anonfunc2() error {
	s := func(src string) error { return nil } // want "It returns nil in all the places where it should return error"
	return s("hogehoge")
}
```

また、テストコードを複数作成していたのでリファクタリングや昨日の変更をするときにとても安心しておこなえました！やはり、テストは大切です。

## countname

変数、関数、定数名が長いものを指摘するツール

[![harukitosa/countname - GitHub](https://gh-card.dev/repos/harukitosa/countname.svg)](https://github.com/harukitosa/countname)

## がんばった点

golang ではわりと短い変数名がこのまれているので 20 文字以上の変数、定数、関数名を指摘するツールを作成しました。アイデアをおもいついたら小さくてもすぐに実装してみようと思い立ってから 1 時間ほどで作成しました。
[skeleton](https://github.com/gostaticanalysis/skeleton)を使用すれば簡単に analyzer の雛形を生成してくれるのですぐに作成を始めることができてとても便利です。

自分でコードを書いたのは以下の部分くらいです。

```go
	nodeFilter := []ast.Node{
		(*ast.GenDecl)(nil),
		(*ast.FuncDecl)(nil),
	}

	inspect.Preorder(nodeFilter, func(n ast.Node) {
		switch decl := n.(type) {
		case *ast.GenDecl:
			for i := 0; i < len(decl.Specs); i++ {
				switch spec := decl.Specs[i].(type) {
				case *ast.ValueSpec:
					var flag bool
					for _, name := range spec.Names {
						if !flag && len(name.Name) > maxLongNum {
							pass.Reportf(n.Pos(), "name is longer than %d", maxLongNum)
							flag = true
						}
					}
				}
			}
		case *ast.FuncDecl:
			if len(decl.Name.Name) > maxLongNum {
				pass.Reportf(n.Pos(), "name is longer than %d", maxLongNum)
			}
		}
	})

```

実装方針としてはファイルの中の*ast.GenDecl, *ast.FuncDecl(詳しく知りたい人は[ここ](https://docs.google.com/presentation/d/1I4pHnzV2dFOMbRcpA-XD0TaLcX6PBKpls6WxGHoMjOg/edit#slide=id.g8791627004_3_7))を取得して来て名称が 20 文字以上であれば指摘する形です。

## goaster

golang のソースファイルを指定するとそのファイルの抽象構文木を生成してエディターで閲覧できるコマンドラインツール

[![harukitosa/goaster - GitHub](https://gh-card.dev/repos/harukitosa/goaster.svg)](https://github.com/harukitosa/goaster)

![goaster](https://user-images.githubusercontent.com/44115752/92212447-ef139b00-eecc-11ea-8823-b88e82ab350a.gif)

抽象構文木（ast)をみながら上の二つのツールを作成したので対象とするテストコードなどの go ファイルの ast をもう少し手軽にみることができたらいいなと思い作成しました。go/ast の fPrintf などのコードを拝借して、エディターでも見やすい形に出力できていると思います。この抽象構文木を編集したら元のソースコードも変更される！なんてことができたらおもしろいだろうなと思ったのですが時間切れで、積み残しの課題になりました。~~あとテストコード書いてない~~

# 感想

一週間 golang を触れたので自分は大満足でした！！
まだまだ学習したいことがたくさんあるのでこの経験を生かしてこれからも Gopher の駆け出しとしてがんばっていきたいと思います！

メルカリさんと講師とメンターの皆様！お世話になりました 🙇‍♂️

# あとがき

一週間がんばったので温泉にでも入りにいきたいです。

golang のマスコットキャラクター gopher 君(偽物)
<img src="/media/gopher.jpeg"/>

夏休みの 8/31~9/4 に開催された mercari online summer internship に参加して来ました！

メルカリの「Online Summer Internship for Gophers 2020」に参加して静的解析ツールをつくった話！


# 概要

C++で競技プログラミング(Atcoder)を行なっているのだが、VScode のターミナル上での自動コンパイルがどうも肌に合わず、iTerm 上でいちいちコマンドを打ってコンパイルして確認をしていた、その作業に慣れはしたもののやはりめんどくさいかつ typo に気を取られることが多くなったのでできるだけ簡単なコマンドでコンパイルを行えるように sh スクリプトと makefile を書いてみたという記録。

# コンパイル対象のファイルを作成する

Atcoder の ABC の問題を解く際に mainA.cpp ~ mainF.cpp ファイルを作成してそこにコードを記入するのでこのファイル群をコマンド一つでコンパイルできるようにする。

```zsh
mkdir contest
```

contest ディレクトリ内に以下のファイルを用意する。

## build.sh

```sh
#!/bin/sh

make mainA
make mainB
make mainC
make mainD
make mainE
make mainF
```

自分も知らなかったのだが mainA.cpp ファイルがある際に make mainA(file 名の拡張子抜き)を打つとコンパイルできる、便利。

## makefile

```makefile
build: build.sh
	./build.sh

clean:
	rm mainA
	rm mainB
	rm mainC
	rm mainD
	rm mainE
	rm mainF

touch:
	touch mainA.cpp
	touch mainB.cpp
	touch mainC.cpp
	touch mainD.cpp
	touch mainE.cpp
	touch mainF.cpp
```

もちろん build.sh は実行できるように権限を変更しておく。

```zsh
chmod +x build.sh
```

以上で下準備は完成だ。

## 実行

make （もしくは make build)と打ち込むだけで全てのファイルをコンパイルすることができる。

```zsh
>>> make
./build.sh
c++  -I/usr/local/opt/openjdk/include   mainA.cpp   -o mainA
make[1]: `mainB' is up to date.
make[1]: `mainC' is up to date.
make[1]: `mainD' is up to date.
make[1]: `mainE' is up to date.
make[1]: `mainF' is up to date.
```

前回のコンパイルからファイル内容を変えていない場合は`` make[1]: `mainB' is up to date. ``のようにコンパイルしないで飛ばすので効率的。あとは実行してコードのテストをすれば OK

```zsh
>>> ./mainA
hogehoge
```

## 感想

以上の準備をすることでコンパイルを脳死で行うことができるようになった。今考えれば build.sh ファイルのコマンドをそのまま makefile に書いてしまえば良さそうだが動作しているのでよしとする（一度完成したのを直すの~~めんどくさい~~）。
自動化をめんどくさがる癖があるのでことあるたびに sh スクリプトや makefile をちょくちょく書く癖をつけたいです。

## 参考文献

[C 言語を使うなら Make を使おうよ](https://qiita.com/j8takagi/items/74232a00cc33623f784)


MacOSにてC++用のコンパイル環境をできるだけ少ないコマンドで実現できるようにファイルを書いたのでそれを掲載する。

競技プログラミング用(C++)のコンパイルを簡単にできるようにしてみた

## 概要

isucon の事前学習として redis について学習してみたものをまとめています。
触り始めなのである程度、基本的なコマンドを網羅したい。

redis について(wiki 参照 https://ja.wikipedia.org/wiki/Redis)

> Redis は、ネットワーク接続された永続化可能なインメモリデータベース。連想配列（キー・バリュー）、リスト、セットなどのデータ構造を扱える。いわゆる NoSQL データベースの一つ。オープンソースソフトウェアプロジェクトであり、Redis Labs（英語版）がスポンサーとなって開発されている。

- メモリにデータを key, value の形で保存することができる。
- データをキャッシュする際に使用されている。

# redis の導入

macOS のみ

```zsh
brew install redis
```

その後起動させる

```zsh
redis-server
```

\frac{1}{2}

redis-cli コマンドを使用すれば対話的に redis のコマンドを打ち込むことができる。

# 基本的なコマンド

#### SET

データを key, value の形で保存する。

#### GET

key を指定してデータを取得する。

#### DEL

key を指定してデータを削除する。

#### EXISTS

key に対応するデータが存在するかどうかを調べる。

これらの動作を redigo/redis を使用して動作を確認していく。

※関数等にまとめた方がいいが今回は学習なので省略

```go
package main

import (
	"fmt"
	"log"

	"github.com/garyburd/redigo/redis"
)

func main() {
	// redisの初期portは6379
	port := "127.0.0.1:6379"
	redisClient, err := redis.Dial("tcp", port)
	if err != nil {
		log.Fatalf("Failed to connect: %s", err.Error())
	}
	defer redisClient.Close()

	// SET: HOGEにVALUEを保存する
	// redisClient.Do("SET", KEY, VALUE)
	_, err = redisClient.Do("SET", "HOGE", "VALUE")
	if err != nil {
		log.Fatalf("Failed to set value: %s", err.Error())
	}

	// GET: HOGEからVALUEを取得する
 // redisClient.Do("GET", KEY)
 // 出力: VALUE
	value, err := redis.Bytes(redisClient.Do("GET", "HOGE"))
	if err != nil {
		log.Fatalf("data: %s", err.Error())
	}

	// 返り値は[]byte型なのでstringに変換して出力
	fmt.Println(string(value))

	// DELETE: keyのHOGEを削除する
	// redisClient.Do("DEL", KEY)
	_, err = redisClient.Do("DEL", "HOGE")
	if err != nil {
		log.Fatalf("DELETE: %s", err.Error())
	}

	// EXISTS: 存在を確認する
	// redisClient.Do("EXISTS", KEY)
	ok, err := redis.Bool(redisClient.Do("EXISTS", "HOGE"))
	if err != nil {
		log.Fatalf("EXISTS: %s", err.Error())
	}
	// HOGEは削除したのでfalseが出力される
	fmt.Println(ok)
}

```

# list 型のコマンド

#### RPUSH

key に対応するリストにデータを挿入

#### LRANGE

key に対応するリストのデータを返す

#### LINDEX

key に対応するリストの指定した index のデータを返す

#### LREM

key に対応するリストの指定した value のデータを削除する

```go
package main

import (
	"fmt"
	"log"

	"github.com/garyburd/redigo/redis"
)

func main() {
	// redisの初期portは6379
	port := "127.0.0.1:6379"
	redisClient, err := redis.Dial("tcp", port)
	if err != nil {
		log.Fatalf("Failed to connect: %s", err.Error())
	}
	defer redisClient.Close()

	// RPUSH:keyに対応するリストの先頭にデータを保存していく
	// redisClient.Do("RPUSH", KEY, VALUE)
	// リストが存在しなければ、データ挿入前にkeyに対応する空のリストを作成する
	_, err = redisClient.Do("RPUSH", "school", "一学期")
	_, err = redisClient.Do("RPUSH", "school", "二学期")
	_, err = redisClient.Do("RPUSH", "school", "三学期")
	if err != nil {
		log.Fatalf("RPUSH: %s", err.Error())
	}

	// LRANGE:keyに対応するリストのデータを返す
	// redisClient.Do("LRANGE", "school", start, stop)
	// 0を基準としたindexで取得するデータのインデックスの開始位置と終了位置を
	// 指定することによりデータを取得する。-1はリストの最後尾のデータを指定している
	value, err := redis.Strings(redisClient.Do("LRANGE", "school", 0, -1))
	if err != nil {
		log.Fatalf("LRANGE: %s", err.Error())
	}
	//[一学期 二学期 三学期]
	fmt.Println(value)

	// LINDEX:keyに対応するリストの指定したindexのデータを返す
	// redisClient.Do("LINDEX", key, index)
	value2, err := redis.String(redisClient.Do("LINDEX", "school", 1))
	if err != nil {
		log.Fatalf("LINDEX: %s", err.Error())
	}
	//二学期
	fmt.Println(value2)

	// LREM: keyに対応するリストの指定したvalueのデータを削除する
	// redisClient.Do("LREM", key, count, value)
	// count > 0ならば先頭から最初に一致したvalueを持つデータを削除
	// count < 0ならば後方から最初に一致したvalueを持つデータを削除
	// count = 0ならば全ての指定したvalueを持つデータを削除
	_, err = redisClient.Do("LREM", "school", 1, "一学期")
	if err != nil {
		log.Fatalf("LREM: %s", err.Error())
	}

	value3, err := redis.Strings(redisClient.Do("LRANGE", "school", 0, -1))
	if err != nil {
		log.Fatalf("LRANGE: %s", err.Error())
	}
	//[二学期 三学期]
	fmt.Println(value3)

	_, err = redisClient.Do("DEL", "school")
	if err != nil {
		log.Fatalf("DELETE: %s", err.Error())
	}
}

```

# 構造体を保存したい

データベースから取得できるデータをそのまま保存しておいて置けるのが理想。key を id(primary_key)にして value を json でデコードしたデータを保存することにより実装してみる。

```go
package main

import (
	"encoding/json"
	"fmt"
	"log"
	"strconv"

	"github.com/garyburd/redigo/redis"
)

// User 構造体
type User struct {
	ID uint64 `json:"id"`
	Name string `json:"name"`
	Number int `json:"number"`
}

func main() {
	// redisの初期portは6379
	port := "127.0.0.1:6379"
	redisClient, err := redis.Dial("tcp", port)
	if err != nil {
		log.Fatalf("Failed to connect: %s", err.Error())
	}
	defer redisClient.Close()

	user1 := &User{ID: 1, Name: "Tosa", Number: 1}
	user1JSON, err := json.Marshal(user1)
	if err != nil {
		log.Fatalf("Failed to marshal user: %s", err.Error())
	}
	// 2020/08/22 18:39:49 user1_json : {"id":1,"name":"Tosa","number":1}
	log.Println("user1_json : ", string(user1JSON))

	_, err = redisClient.Do("SET", "user"+strconv.FormatUint(user1.ID, 10), string(user1JSON))
	if err != nil {
		log.Fatalf("Failed to SET: %s", err.Error())
	}

	//　user1
	fmt.Println("user" + strconv.FormatUint(user1.ID, 10))

	user, err := redis.Bytes(redisClient.Do("GET", "user"+strconv.FormatUint(user1.ID, 10)))
	if err != nil {
		log.Fatalf("Failed to get user data: %s", err.Error())
	}
	data := new(User)
	json.Unmarshal(user, data)
	// 2020/08/22 18:39:49 &{1 Tosa 1}
	log.Println(data)
}

```

これで一応構造体を redis に保存することができたが、id ごとに key を作らなくてはいけないのが不便、かついちいち json にパースしなくてはならないので、あんまり使い勝手が良くなさそう。redis にはハッシュ型があるので次回はそちらで実装してみたい。またデータを sort して保存して置ける sorted リストなどのもあるらしいのでそちらも調査していく予定です。

# 参考サイト

[Mac に Redis をインストールする](https://qiita.com/sawa-@github/items/1f303626bdc219ea8fa1)

[Redis を CentOS7 に yum インストールする手順](https://weblabo.oscasierra.net/redis-centos7-install-yum/)

[examples-redigo](https://github.com/pete911/examples-redigo)

[LPUSH のドキュメント](https://redis.io/commands/lpush)

isuconの事前学習としてredisについて学習してみたものをまとめています。 触り始めなのである程度、基本的なコマンドを網羅したい。

インメモリデータベースredisを触ってみた（初回編）


こんにちは
とさです

6/7~6/8 で CyberAgent の 2day サーバーサイド向け
開発型インターンシップに参加していました！

まず初めに結果としては全体のちょうど半分の 10 位で終了しました。
なので、参加者の丁度中央だった自分がどのようにチューニングに挑戦していたのかを記録していきたいと思います。

## 実施前にやったこと

golang のプロファイリングツールである pprof と nginx の計測ツールの alp について調査とテストを行っていました。また isucon7 の予選の解説 pdf が販売されていたので購入してパラパラとめくって学習していました。

ただ、インターンシップの面接の際も nginx(エンジンエックス)について知っていますか？と聞かれた時点では nginx(ネギシン)と読むのだと勘違いしていたくらい知識がありませんでした。

## 開始 〜 一日目前半

初期点は 700 くらい、まずは github にファイルをあげてローカルで開発しようとしたのですが、ファイル権限等の調節がうまくいかず、いじるファイルが少ないことから vim と scp によるファイル転送で開発していく方針に変更しました。(効率悪かったのでファイル権限をちゃんと設定するか vim が触れるなら直接変更した方が良いです)

```zsh
# scpコマンド
scp file_name hogehoge@hostname:/dirctory/
```

## 1 日目 後半

途中でランチタイムが入り、周りの学生エンジニアさんと話せて息抜きをしつつ午後へ。

相変わらず github の設定で四苦八苦しつつ、そもそも golang のサーバーの再起動の仕方がわからず...といろいろわからないことだらけだったので(だめだめ）ぐぐったりメンターさんに聞きながら作業を進めていました。

```zsh
# システムの再起動
# ここら辺はsystemdで管理されています！！
sudo systemctl restart hogehoge
```

またここら辺で nginx.conf を操作の慣れていない vim でデータを吹き飛ばしたりしていました。（再度ファイルをもらいました、、お手数おかけします）（vim は:wq で保存されるので無意識に打ってしまいました w 皆さんも気をつけましょう）

alp を使用した解析を行いたかったのですがうまくいかず、メンターさんに聞いたところ nginx.conf ではなく別の場所でも設定がありそちらの server ディレクティブに記入しなければならないらしく、、、時間を取られてしまいましたがようやく解析ができるようになりました。

## 初日解説〜終了

解析ができるようになった時点で初日解説の時間。
index の貼り方一つでスピードが全然変わることに驚きでした。
slow クエリの調べ方や実際に index が使用されているかの見方を解説してもらいました。

解説を参考に query を貼って 700 -> 1300 にスコアを上げることができました！（:ドヤ

その後、は slow クエリを探して index を貼ったら高速化できそうなところに貼って 1300 -> 1500 にスコアを伸ばして初日は終了しました。

また、この日の夜に使用言語の指定処理をやり忘れていたみたいで php -> golang に設定し直しました。

※ましさんに教えてもらいました、ありがとうございます！

## 2 日目 前半

二日目は alp の解析結果をもとにログイン後の初期ページの動作が遅いことがわかってのでそこを改善していくことに、どうみてもアカウントのアイコン画像を表示する処理が重たい（base64 で配信している）ことがわかったので直接静的ファイルを参照するように変更しました。

```
    location / {
        try_files $uri "${uri}.png" @backend;
    }
```

具体的には/photo/{id}を叩くと/photo/{id}.png に直接参照するように nginx の try_files を変更して改善すると、ホームページの画像がすごく早く表示するようになりました！

これはもしかしたら 6000 点を超えてしまうのではないか？トップあざす！と期待しながらベンチマークをすると得点が全く変わっていないという悲劇に。。。

ベンチマークが何を参考に得点を決めているのかをしっかり確認すべきだなと終わってみてから反省しています。

切り替えてスロークエリログを調査することに

```sql
mysql> set global slow_query_log = 1;
mysql> set global long_query_time = 0;
mysql> set global slow_query_log_file = "/tmp/slow.log";
bashに戻って
sudo pt-query-digest /tmp/slow.log > /tmp/digest.txt
```

解析をしてみるとおすすめ記事を表示する sql が遅いことを確認！ここを改善してみようといろいろ頑張りましたがどうやら sql の書き方自体に悪いところが見当たらず、、ちょっと行き詰まり感がありました。

## 2 日目　後半

sql が遅いのならば予めその値を保持できるのであれば保持しておいて sql を実行せずにその値を返せばいいのでは？と思い立ち global 変数に値を保持して、その値に関連する動作が起こったら flag を立ち上げて再度取得するように変更してみました。

```go
// 焦りすぎてスペル間違っているとか汚いとかはご愛敬
var (
	cachePopularArticle []PopularArticle
	chachOnlineUser     []int
	onlineflag     bool = false
	popflag        bool = false
	chachearticles int
	articlesflag   bool = false
	tagsCount      int
	tagsCountFlag  bool = false
)
```

この作業をしている間に時間は経ち score は 1500 -> 1700 に改善しました！
（ただ、不具合が生じることがありベンチマークが FAIL することも多かったです。）

※ 競技終了までこのれがインメモリ戦略だと思っていました。
※ 授業でメモリを習ったのに...

## 結果

最終結果は 1723 点が最大値で 20 人中ドンピシャで 10 位でした。2000 点いきたかったですが、ガッツリ二日間集中して開発に打ち込めてとても楽しかったです！アドレナリン出まくりで初日が終了した時点で両腕が筋肉痛になる程、プログラミングが楽しいものだと再度実感しました。

競技終了後、解説があり。

-   Mysql インデックスチューイング
-   インメモリキャッシュ、N+1 除去
-   golang 特有のチューニング

の三つのステップで 7500 点を超えた事例の説明を受けました。redis によるインメモリキャッシュのやり方や、golang の template エンジンが reflact によって遅くなっている部分の解消のやり方など、いろいろな観点で改善法を学べてめちゃくちゃ面白かったです！

また、nginx を外して golang の 80 番を直接 Listen するなど、これを使わなくてはいけない！っていう常識にとらわれて本質が見えていないと改善できない部分もありました。

当たり前ですが「知らない」技術はもちろん使うことができないので、こうした機会にいろいろな技術を「知る」ことができるのがとてもありがたいです。次回は是非今回学んだことを「使える」まで磨いて挑戦したいと思っています。

また、競技終了後 CyberAgent さんの LT や社員懇談会もありいろいろな裏話が聞けてとても楽しかったです！社内の雰囲気がとてもよく伝わってきました。

個人的に社内インフラのサーバーの画像をみたときにめちゃくちゃかっこいい！ここで寝転がりたい！
って興奮したのが印象に残っています。

次は ISUCON にも出場する予定なのでのでもっと学習して予選突破目指して頑張りたいと思います！

---

## 競技中に参考にしたブログ

[【Golang】gob で変数をファイルに保存する](https://cipepser.hatenablog.com/entry/go-gob)

[ 【MySQL】遅い select 文の原因を調査する【explain の読み方】](https://qiita.com/mtanabe/items/33a80bf2749a872645e6)

[nginx の try_files わかりにくすぎ問題](https://tsyama.hatenablog.com/entry/try_files_is_difficult)

[ISUCON 史上初の学生チーム優勝！ 勝利のカギは「チームワーク」と「失敗からの学び](https://thinkit.co.jp/article/15737)

LT でこの記事に載っていた本物の人が出てきて驚きました w

---

## 他の参加者のブログ

技術的な視点からとても勉強になりますので是非！

[さんぽしさん](https://sanposhiho.hatenablog.com/entry/2020/06/07/204415)

[kiyo さん](https://blog.shirakiyo.dev/post/ca-btc/)

[ましさん](https://mesimasi.com/backend-tuning-ca/)

[hpp さん](https://hackmd.io/@hpp/ca-backend-tuning-competition)

[やよいさん](https://www.yayoibloglife.work/entry/2020/06/08/015922)

[Santos Kota さん](https://qiita.com/kotaokubo/items/71586450309e437f2abb)

[AkkyOrz さん](https://akkyorz.hatenablog.com/entry/2020/06/08/165548)


こんにちはとさです 6/7~6/8でCyberAgentの2dayサーバーサイド向け 開発型インターンシップに参加していました！

TOSA.DEV

# Tags

# Posts