イベントを主催した時の反省メモ
先日とあるイベントを主催しました．最終的には素晴らしい会となり，盛り上がっていただけてとても嬉しかったのですが， イベントの主催は初めてということもあり，色々失敗したこともあったので，その教訓を書いていきます．
当たり前の事ですが，わかっていても，一度失敗しないとなかなかできないのです．
- マイクから音は出ない．映像は映らない．
- 運営メンバーは足りない
- 時間の伝達はうまくいかない
- 食べ物，飲み物の運搬には思ったよりも人手が必要
- みんなお酒はそんなに飲まない
- ソフトドリンクは人気
- 当日用意しようと思っていたものは手に入らない
- 大事な持ち物ほど忘れる
- 講演者がよければそれで良し．懇親会は何もしなくても楽しい．
マイクから音は出ない．映像は映らない．
たとえやり方をしっかりとメモして，会場を下見した時はちゃんとできていたとしても，当日はマイクから音は出ないし映像も映らない．
- 会場はイベント開始の3時間前から押さえて、音響や映像設備の調整に十分な時間を確保しよう．
- ありとあらゆるケーブルと変換アダプターを持っていこう．
- 本当の本当に困った時は，参加者や講演者に機材を借りたりして助けてもらおう．
運営メンバーは足りない
当日はどれだけ準備していても人手が足りない．そして当日突然来れなくなる可能性もある．
- 運営メンバーは早めから確保しよう
- 運営メンバーは出来るだけ多く確保しよう
時間の伝達はうまくいかない
- しつこいくらいリマインドしよう．
食べ物，飲み物の運搬には思ったよりも人手が必要
食べ物，飲み物を運ぶのは以外に大変．
- 飲食物の運搬に人を動員できるよう多くの運営メンバーを確保しよう
- できれば会場まで宅配してもらおう．
- 宅配にできない状況であれば，万全の準備をしよう．
みんなお酒はそんなに飲まない
イベントにもよるが，今回のような勉強会＋懇親会系のイベントではお酒が結構余る． 余ったら持って帰れるので構わないけど．
- 一人当たり2本換算でかなり余ってしまったので，1.5本換算でよいかもしれない．
ソフトドリンクは人気
お茶やオレンジジュースが終盤は人気．
- ソフトドリンクはもう少し多めに用意しよう．
当日用意しようと思っていたものは手に入らない
どんなお店でも見かけるものであっても，面白いくらい手に入らない． その調達に時間がかかり，会場の設営に支障が出るようではいけない．
- いつでも買えるものは事前に買って持参しよう．持参したものは裏切らない．
- 紙コップや紙皿，お菓子やソフトドリンクはある程度事前に用意していこう．
大事な持ち物ほど忘れる
持参したものは裏切らないが，持参しようと思っていた前日の自分は平気で裏切る．
- 持ち物リストを作って共有しよう
- 誰でも用意できるものであれば，二人以上の人間が持ってくるようにしよう
講演者がよければそれで良し．懇親会は何もしなくても楽しい．
今回は素晴らしい講演者に来ていただけて大盛況だった．本当によかった．
- 面白い講演をしていただけるよう，運営が頑張ろう
- 大物講演者を呼べるよう，団体の知名度を上げよう
- すごい人とのコネがある人や団体と共催しよう
私的API設計メモ
この記事はKosen13s' Advent Calendar 2018の記事です．
アドカレは初めてで，何を書こうか悩んでいるのですが，最近API設計のお仕事が舞い込んできたので，インプットしたことをまとめようと思います．
参考にしたのはこちらの本です． 第3章まで読みました．
エンドポイントの設計とリクエストの形式
APIエンドポイントの考え方
そもそもエンドポイントとは
≒URIと考えてOK
エンドポイントの基本的な設計
APIのエンドポイント設計
URI（リソース）とアクションの組み合わせで決める
レスポンスデータの設計
データの内部構造の考え方
「フロントは一つの画面ごとに一つのAPIを叩く」ことを原則として考える．
一つの作業に対して一つのAPIを用意する．
エンベロープは必要か
ヘッダやレスポンスなど，全てのデータを同じ構造で包むこと
ほとんどの場合冗長なので必要ない，レスポンスだけ返そう
データはフラットにすべきか
こだわりがない限りフラットにすべき
配列とフォーマット
複数のデータを返すときは，配列をそのまま返すのではなく，オブジェクトを返そう
配列の件数，あるいは続きがあるかをどう返すべきか
必ずしも全件数を知る必要はない．
続きがあるよフラグを返すという解決策もあり
各データのフォーマット
各データの名前
スネークケースが良さげ
エラーの表現
ステータスコードでエラーを表現する
ぴったり合うエラーコードがあればそのエラーコードを選び，なければ400や500など，00番台のエラーコードを選ぼう．
エラーの詳細をクライアントに返す
エラー用JSONを返そう
errorという配列で表現すれば，複数のエラーを返せる
最後に
API設計に関しては，基礎知識を付けるだけでなく，TwitterやFacebookなど，広く公開されている有名なAPIを読み解き，なぜこのように設計したのかを考えながら使ってみることが大事ですね！
湯けむりハッカソンを振り返って懺悔
熱海だ
— あらい (@txtb0kwrm) 2018年9月15日
9月15日からの三日間，レバレジーズのインターンその名も「湯けむりハッカソン2018」に参加してきたので，学んだことを忘れないように記事にします．
概要
1日目
不倫旅行の聖地熱海に到着．12時半に駅前の足湯にて集合．NEOのロゴTを来ている参加者を見て話しかけ，意気投合．
これから地獄の三日間を過ごすことになる旅館に到着．5人のメンバーとお世話になるメンターさんを決め，社員の方のありがたいお話を聞き，キックオフ．
ある課題を解決するためのWebアプリを作るということでアイデアを出した．
ロジックツリーを書いて，どのような人がどういったことで困っているのかを明確にし，どのようなアプリがその課題を解決するのかを考えた．そのアプリが対象とするターゲットを絞り，そのカスタマージャーニーマップを作成．
ロジックツリーが全く深くならず，出したアイデアは一言で否定され，メンバーのメンタルがどんどんやられていきました．
夕食，お風呂の時は，インターンのテーマを一旦忘れてメンターさんと一緒におしゃべり．
その後，夜遅くまで頑張って，なんとかイケそうなアプリのアイデアが出て，一安心．これが後に一蹴されることも知らずに．．．
2日目
朝からアイデアを深く掘り下げ，昼過ぎには実装に入った．基本的にフロントで完結できるシステムだったので，Vue.jsでゴリゴリ．
夕方になって，このアイデアが否定されてしまい，ロジックツリーからやり直し．非常に辛い．
夜になって，メンターさんや社員さんから山のようにアドバイスをいただき，なんとかイケそうなアプリのアイデアが出て一安心．
再びフロントだけで完結するシステムで，さらにロジック自体は非常に簡単だったので，jQueryでゴリゴリ．
しかし思ったより生産性が悪く，途中で切り上げて明日にかけることに．
3日目
朝起きて，アプリのバグが大方取れて，13時の発表に備えて準備．
他のチームが発表で根本的な部分を指摘されている中，我々の発表ではそれほど殺されず，穏やかに終了して安心．一番最後のチームが色々ぶっ飛んでいて面白かった．
結果発表・フィードバック・懇親会
私たちは優勝できず，優勝したのは一番最後のチームでした．ユーザーのデータをグラフ化し，きちんと数字を出した上でアイデアの正当性を説明していた上に，実装の技術力と生産性が高かったので，会場の誰もが結果を確信していました．
結果発表後はチームのメンターさんと社員さんからの穏やかだが厳しいフィードバック．寝不足と疲れもあいまって，最高に気分が沈んでいました．
懇親会では，ハッカソンが終わってようやく酒が飲めた．いろんな参加者やメンターさんとお話しすることができ，楽しく過ごせました．
懺悔
レバのハッカソン終了
— あらい (@txtb0kwrm) 2018年9月17日
いい感じに自分の無能さが明らかになったのでとてもよい
— あらい (@txtb0kwrm) 2018年9月17日
今回のインターンであまりにも自分の無能さを実感してしまったので懺悔します．
技術力云々ではなく，人としてあまりにもお粗末な行動をとってしまいました．
- 自分の考えに固執しすぎてしまった
最もやらかしてしまったポイント．時間と心の余裕がなく，ある程度固まったアイデアを通そうとして他のメンバーの意見に噛み付いてしまいました．本当にごめんなさい．
時間に余裕がない時は，積極的に休憩をとって以前の行動を振り返ろう．その時は本当に時間がないと思っていても，後から考えると，あの時やり直していれば間に合ってたな．．．ということは多いです．
- 議論が下手
議論が脱線しても誰も止めず，見兼ねたメンターさんが脱線してるよと教えてくれるというあまりにも愚かな行動を何度も何度も繰り返してしまいました．
アプリのアイデアを出すのに時間がかかるというのはある意味仕方ない．でも，議論が脱線することに早めに気づき，積極的に指摘していればもう少し効率的に進められたと思います．
- あまりにも生産性が低かった
実は私は複数人での開発経験がほとんどなく，役割分担についてわからないのは仕方がないとしても，技術選定がダメダメでした．本当に簡単なアプリだったので，もはやこんなものコピペでできるでしょ とjQueryを選ぶというミス．結果かなりの時間がかかっちゃいました．一つめのアイデアのまま，Vue推しを続けていたらまた違ったんだろうな．．．
- 発表がしどろもどろだった
思考がまとまらなかった．論理が重要な部分は台本を作ろう．普段作ってるのにな．．．
三日間を振り返って
新しいプロダクトを生み出す時の思考方法について学べて本当によかったです．
ハッカソンの間は辛い以外の感情がなかったですが，冷静になって振り返ってみると多くの学びがあり，的確なフィードバックを頂くことができました．
最後に，メンバーの4人，メンターさん，レバレジーズの社員の方々，ありがとうございました．おかげさまで，有意義で学びの多い3日間を過ごすことができました．
HerokuにDockerコンテナをpushしてRailsアプリをデプロイする
8時間にわたるデプロイが完了した
— あらい (@txtb0kwrm) 2018年9月6日
なんでherokuなのにこんなに時間かかるんだ笑
Webアプリのデプロイ というかサーバーと会話していると無限に時間が溶けますよね．
私も今回かなりハマって悲しい思いをしたので，今日はHerokuデプロイの備忘録もかねて，手順を書いていきます．
実行時の環境
macOS High Sierra version 10.13.6 Docker version 18.06.1-ce docker-compose version 1.22.0
Herokuデプロイの手順
Railsアプリを開発するまで
まずはリファレンス↓通りRailsアプリを構築していきましょう．
注意点として，Dockerfileの一番下に，この一行を追加しておきましょう．
CMD ["rails", "server", "-b", "0.0.0.0"]
あとはrails newしてdocker-compose upしてrails db:createしてlocalhost:3000/にアクセスすればyay!となるわけですね．
もう一つ注意点として，Gemfileを
# gem 'pg', '>= 0.18', '< 2.0' gem 'pg', '0.20.0' # 追加
としてビルドし直しておきましょう．
それから，rails g model，rails db:migrateしたりしてアプリ開発を楽しんでください．
Herokuにpushしていく
前準備
Herokuのアカウントを作り，heroku-cliをインストールします．
コンテナを落としておく
tmp/pids/server.pidをpushしないよう，コンテナをdownします．
>> docker-compose down >> rm tmp/pids/server.pid
デプロイの手順
次のコマンドを順番に入力していきます．
>> heroku create >> heroku container:push web >> heroku addons:create heroku-postgresql:hobby-dev >> heroku container:release web >> heroku run rails db:migrate >> heroku open
すると，ちゃんとHeroku上でアプリが動くかと思います．
今回のハマりどころ
pgのバージョン
↑の方のエントリに書いてあるように，pgのバージョンを変える必要があるみたいです．
DockerfileにCMD行を追加するとこ
DockerfileにおけるCMDとdocker-compose.ymlにおけるcommandには違いがあり，Dockerfileに書いた方はdockerコマンドで動作させる時に実行され，docker-compose.ymlに書いた方はdocker-composeコマンドで動作させる時に実行されるようです．
上にあげたDocker公式ページでは，docker-composeを使ってアプリを開発していくことを想定しているので，Dockerfileの方にポートを開けるコマンドがありません．
herokuではDockerfileの方のcommandを見ているのかどうかわかりませんが，これを追加したことでApplication Errorから脱出できましたので，ご参考までに．
この二つのうちどちらか，あるいはどちらも効いたようで，何とかデプロイが成功しました． このような記事をまとめてくれている人がいて助かった．．．
参考文献
↑ほとんどこの方の解説を参考にしましたが，この記事ではModelを使ったRailsアプリにも対応しています．
NeoVim + vim-plugに乗り換えた
今日は朝一からNeovimに乗り換えております
— あらい | Blockchain (@txtb0kwrm) 2018年8月6日
今日はNeoVimとvim-plugの設定についてちょこっと書いていきます！
NeoVimのプラグイン管理ツールとしてはdein.vimが有名ですが，設定ファイルのシンプルさという点でvim-plugの方が私は好みです．なんてったって，Minimalist Vim Plugin Managerですからね．
NeoVimの設定
インストールは省略します．brew installしたりpip3 installしましょう．
NeoVimの設定ファイルは，~/.config/nvim/init.vimです．ここに設定をズラズラと書いていってもいいのですが，あまり美しくないので，ファイルを分割し，init.vimではそれを読み込むだけにするのが良いと思います．
私のinit.vimはこんな感じ
runtime! userautoload/init/*.vim runtime! userautoload/plugins/*.vim
treeするとこんな感じ
~/.config/nvim
├── init.vim
├── mytemplates
│ └── tex.txt
└── userautoload
├── init
│ ├── basic.vim
│ ├── color.vim
│ ├── dein_plugins
│ ├── keymapping.vim
│ ├── plugins.vim
│ └── template.vim
└── plugins
├── deoplete-config.vim
├── neocomplete-config.vim
├── neosnippet-config.vim
├── nerdtree-config.vim
├── previm-config.vim
└── vim-quickrun-config.vim
各設定項目のカテゴリごとにファイルを分けると美しいですね！ 次はvim-plugの設定です．
vim-plug
先ほど設定といいましたが，設定という設定はありません．
GitHub - junegunn/vim-plug: Minimalist Vim Plugin Manager
READMEに書いてあるように，インストールはこれだけ．
curl -fLo ~/.local/share/nvim/site/autoload/plug.vim --create-dirs \
https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
プラグインの呼び出しはこれだけ．
call plug#begin('~/.local/share/nvim/plugged') Plug 'fatih/vim-go' "導入したいプラグイン call plug#end()
インストールするには，nvim内で
:PlugInstall
するだけ．
簡単すぎる．．．
カラースキーム
最後に，カラースキームです．私の場合は,nanotech/jellybeans.vimに設定しているので，先ほどのcall plug#end()の後に，
" colorsheme if filereadable(expand("~/.local/share/nvim/plugged/jellybeans.vim/colors/jellybeans.vim")) colorscheme jellybeans endif
とすると良いです．(参照元：https://simple-it-life.com/2016/09/11/vim-plug/)
最後に
ではこれから
— あらい | Blockchain (@txtb0kwrm) 2018年8月6日
alias vim "nvim"
の儀式を行う
fish派なので．笑
IT企業に祈られすぎて楽しくなりそう
R社，L社，W社，，，などのインターンに応募したところ，ほとんど全て落ちてしまいました．1社だけ受かったので，温泉につかりながらハッカソンができそうです．
というわけでこの記事では，夏休みどうするか書いていきます．明日はまだテストだというのに．
なぜ落ちたのか
こんな本を読んでいます．
世界で闘うプログラミング力を鍛える150問 ~トップIT企業のプログラマになるための本~
- 作者: Gayle Laakmann McDowell,秋葉拓哉,岩田陽一,北川宜稔,Ozy
- 出版社/メーカー: マイナビ
- 発売日: 2012/11/13
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 7,806回
- この商品を含むブログ (53件) を見る
落ちた理由がちょっとだけわかった気がします．ありきたりですが，「この人と仕事したくない」と思われたのでしょう．ひとえに，実力不足でした．技術的にも，1人の人間としても．
というわけで，夏は精一杯やりたいことを楽しめそうです．今からワクワクしてしまって，いったい何時間自由な時間があるか試算してしまったぐらいです．明日も明後日もテストなのに．
夏は何するか
私が所属するAIメディカル研究会というサークルの先輩に，ラボでの研究アルバイトを紹介してもらえたので，そちらに全力で取り組みます．
今まではバイトとしてRails開発を主にやってきたのですが，そちらは一旦お休みですね．
夏にやりたいこととやりたい率[%]を列挙してみました．
時間があればやりたい↓
夏休みのうちオフの日は5週間あるとして，そのうち自由な時間は10時間あるとすると，なんと夏休みで350時間もあります．この40%を機械学習の勉強に費やすとすると，なんと140時間もできます！贅沢ですね．．．
あと，このブログもできる限り更新したいと考えています．インプットする分だけアウトプットせねば．これだけ時間があってもブログを更新できないとなれば，流石に自分をダメ人間認定しなければなりません．
積極的に低レイヤーを学んでいきたい
この考え方は先ほど紹介した本の影響です．
CSで学位を取った と胸を張って言えるように，努力していきます．
とりあえずアルゴリズムの勉強としてAtCoder水色目指す！
就職を考える
プログラミングはしっかりやってますしこれからもやっていくつもりですが，実はIT企業に就職するかどうか悩んでいます．
しかし，たとえ他分野に就職するとなっても，一つの分野を掘り下げて学んだ経験というのは必ず役に立ちますし，別の分野に面白さを見出すことができるようになると思うのです．
レオナルド・ダ・ヴィンチやライプニッツがそうであったように，頭のいい人は，全く別のものであってもその本質を見抜いて同一視できるので，ありとあらゆる分野に才能を発揮できるのだと思います．
だから私は，とりあえずCSの基礎と応用を学びます．せっかく縁あって情報系の学部にいるわけですし．
最後に
今年，ようやく晴れて大学生になれたので，この夏は「すぐには役に立たないこと」を一生懸命勉強します！
来年以降は引く手数多ですね間違いない．
初心者のためのプログラミング勉強法（勉強編）
プログラミングを学ぼうとした時、大きく分けて
- 本で勉強する
- インターネットで調べて勉強する
の二つの勉強法があると思います。
そこで、それぞれの勉強法における注意を書いていきます。
本で勉強する場合
本の選び方
初心者が本を参照する際にまず確認すべきことは、
- 本のレビュー
- 出版年
この二つです。
プログラミングの経験がない人は、本のレビューが良くて、出版年が新しいものを選べばいいと思います（逆に、本選びであまり時間をとるべきではありません）
レビューはAmazonで調べましょう。あくまで個人の意見ですが、オライリーという出版社の本には良著が多いです。動物の絵が特徴的。
出版年は、学びたい技術にもよりますが、1年前を目安にして選ぶと良いと思います。
なぜ出版年にこだわるかというと、ITの世界では技術の入れかわるペースが速いということもありますが、それよりも、後述するバージョンの問題があるからです。
環境のバージョンを確認する
これ、割と大事です。本の出版には時間がかかるので、バージョンの古い環境で動作テストが行われている可能性があります。というわけで、以下の2点を念頭において学習を進めてください。
- 本と同じバージョンで進める
- 本と異なるバージョンで進める場合、それによって環境の差異が出る可能性を常に意識
マイナーアップデート（例えば、Python3.4 -> Python3.5へのアップデート）などで大きな差が出ることはあまりないですが、メジャーアップデート（Python2 -> Python3へのアップデート）では大きな差ができる可能性があるので、注意して本を選んでください。
読むだけでは力がつかない。写経すべし。
最重要項目です。ここではプログラミングの技術書の読み方を解説します。
初心者は、本の中の文章とコードを読んで何をやっているか把握すると、理解した気になるという罠にハマりがちです（体験談）。読むだけでは、さあ自分で何か書いてみようと思い立っても何も書けないと思います（体験談）。
そこで、本を読む際は「写経」をしましょう（写経について異論は多々ありますが...）。写経とは本来お経を書き写すことですが、専門用語では、掲載されているソースコードをそのまま自分の環境に書き写し、一緒に実行してみることを意味します。
このコードが何をやっているのか理解しながら写経することによって、本の中で何度も出てくる典型的なコードを、体で覚えることができます。
さらに重要なのは、「写経したコードをちょこっと改変してみる」ことです。
写経によってこのコードが何をやっているのか理解し、望む出力が得られたあと、
「では、ここを変えたらどうなるのだろう？」という疑問を持ち、それを実験してください。
コードの理解がより深まると同時に、応用が効くようになります。お試しあれ。
インターネットで調べて勉強する場合
ほとんど本の時と同じですが、いくつか注意点を。
公式サイトを見る
初心者ほど、誰かが日本語でわかりやすく説明してくれているブログなどの情報に飛びつきがちですが、それはオススメしません。
まずは、公式サイトをよく読んでください。
公式サイトを読んでわからないところを他のブログで補うようにしてください。
ブログの著者との環境の違いが思わぬエラーに繋がったり、著者のコードの癖があなたのコードに入ってしまう可能性があります。
非公式情報であれば信憑性を確認
公式サイトを見てもわからない場合は他人の書いたブログを参考にしましょう。
信憑性といっても難しいですが、ブログやQiitaでは、「アウトプットの数」が一つの目安になるかと思います。
バージョンを確認
バージョンを確認しましょう。
「Python3 print関数」や、「Rails5 ajax」など、バージョンを明確にして検索すると求める情報が得やすいと思います。
読むだけでは力がつかない
やっぱり読むだけでは理解できないので、コードを手元の環境に入力 -> 実行 -> ちょこっと改変 -> また実行 のサイクルを繰り返しましょう。
本とインターネット、どちらがオススメ？
初心者の人には本をお勧めします。なぜなら、著者のスキルがある程度保証されていて、説明が一貫しているからです。
さらに、知りたい情報だけでなくそれを理解するための周辺知識も提供してくれるので、基礎がためには適しています。
また、一般的に良い入門書はリファレンスとしても使えるので、初心者を卒業した後も活用できると思います。
Web上のプログラミング学習サービスについて
プログラミング学習サービスの種類
プログラミング学習サービスは、大きく分けて2つに分けられると思います（名前は適当）。
・講義型：
プログラミングのコードに対する説明をしてくれるサービス
・全部入り型
ブラウザ上に開発環境が用意されていてそこで開発を進められるサービス
講義型
全部入り型
まとめ
本記事では、本とインターネットによる学習について述べました。
細かい確認事項は置いといて、本当に大事なのはコードを理解し書けるようになる事です。
サンプルコードを理解しながら実行 -> 挙動に対して疑問を立てる -> その疑問を解決するためにコードを書き換えてもう一度実行する のサイクルを意識して勉強してみることをオススメします！
プログラミング学習、頑張ってください！
