The paradigm shift

saboyutaka’s diary なんかかく(ブログn回目)

若者が地方から都会に移住するならシェアハウスに住むべき -『幸福の資本論』

最近、貧困の問題とか資本主義の仕組みとかが気になっててそういった本を読んでる。その一つがこれ、

お金とか資産の本で有名な橘玲さんが最近出した本。

この本を読むきっかけになったのはこの記事を見て。

diamond.jp

プア充ってなんだろと思って読んでみたところ、結構面白かったので本も買ってみた。 ぼく自身のこれまでの東京で生活してきた体験と重なる部分があって思った事を書いてみる。

幸福になるための3つの資本

この本で出て来るのは3つの要素、人的資本、金融資産、そして社会資本。

f:id:saboyutaka:20170912104807j:plain

出典: https://twitter.com/fladdict/status/774988305062506496

人的資本とは

個人的な解釈すると、個人のスキルや自分自身でお金を生み出せる能力。 自分の能力・時間をお金に変換できる資産。これは自分のスキルを磨いていくことで高めていける。

金融資産とは

これはわかりやすくお金、貯金、株や仮想通貨やFX、証券など一般的に資産と言われるやつ。 金融資産を多く持ってると生活が安定して幸福が得やすいというのはふつうに想像できる。だけど金融資産を気づくためにはお金を投資していく必要があって大多数の人ができるわけじゃない気がしてる。

社会資本

今回この本が特に好きなのはこの社会資本というところで、これはコミュニティだったり人とのつながり、これを資本と言い切ってるところが今までの考えと少し違ってて好き。 プア充って言葉がこの本で出て来るけどプア充は人的資本(スキル)ない、金融資産ない、だけど社会資本がある人のことを指してる。プア充の幸福度が高いのは、ずっと一緒にいる地元の友だちや先輩後輩地域の人と繋がっててみんなで支え合うことができるのでお金が多少無くても生活は安定して幸福度が高いみたい。たしかにーという感じ。

3つの資本のどれかをある程度持っていると生活は安定する、3つのいずれも持っていない状態がこの本でいうところの貧困。スキルもお金もなくて頼れる人も居ない状態。

地方から都会に移住した時に一人暮らしをしない方がいい

一つは社会資本の問題、地方から都会、日本から海外、どのケースにも当てはまるけど社会資本は基本的に地理的な制約を受けやすいので自分が知らない土地に行くと社会資本が基本的に0に近い状態からスタートになる。地元帰ったら友達いっぱいいるのに都会に来るとこんなに人いるのにひとりぼっちだわぁみたいな状況になりがち。語学留学したけどホームシックとか。

もうひとつは金融資産、東京で一人暮らししようと思うと、初期費用と家具家電購入するとだいたい50万円ぐらいのイニシャルコストがかかる。つまり金融資産(貯金)を消費して、一人暮らしという環境を手に入れる。一人で家賃や光熱費を払っていく必要があってランニングコストも高い。生活を維持するためのコストが高いからお金を稼ぐ必要があってそのためには自分の時間を切り崩して稼ぐ必要がある。仕事と一人暮らしの家に帰るだけの生活に陥りがち。そうすると新しい人に出会う時間を作ることが難しくなって社会資本を増やしづらい状況になりやすい。つまり貧困の状態から抜け出せなくなる。生活を安定させるためには3つの資産のいずれか、または複数を増やしていく必要がある。

新しい地域に行くときは社会資本を増やす方法

思いついた方法を幾つかあげてみる。

  • 新しい地域にすでに友人がいるならその人やその周りの人と仲良くなる
  • 共通の趣味の人が多くいる場所に行く。イベントやセミナー、勉強会とか
  • たくさんの人と出会って密な関係を築けるような仕事を選ぶ
  • ローカルの飲み屋やバーなどゆるく人と繋がれる場所に定期的に遊びに行く

難しく考える必要なくて自分が無理せず、自分が好きな事だったり居心地がいい場所で気の合う人を見つけれるといい。

シェアハウスという選択肢

ここにきてようやく本題の話、シェアハウスに入居する場合基本的にはデポジットと呼ばれる預り金を払うだけで入居できるところが多い。デポジットは退去時に返ってくる。最初から家具家電は揃ってるので自分で新しく買う必要がないので毎月の家賃だけでいい。そしてそこに共同で住む人がいるのでその人達とコミュニケーションを取る必要があるけど、逆に言えば毎日顔を合わせる事になるので関係が築きやすい。仲良くなると一緒にご飯食べたり、家で飲み会やったり。テラスハウスとかイメージしてもらうといいかも。シェアハウスによってはイベントを開いて外部の人を読んだりするところもある。もちろん気が合わない人、場所ということもあるけど、金銭的なコストが安く1ヶ月ごとの更新とかが普通なので合わなければ出ていけばいい。シェアハウスに住む人の中には点々と移動してる人も多い。シェアハウスに住むと、社会資本を増やしやすい、低コストで住める、住環境を変えるコストが低い、などがメリット。

個人的には東京だと会社から歩いていけるか自転車で行ける距離のシェアハウスに住むのがいいと思う。電車に乗る時間は本当に無駄。

貨幣経済から価値経済への流れ

貨幣経済はお金至上主義、資本主義はお金、金融資産をたくさん持ってる人が一番有利なゲーム。なんだけど最近はその流れがだんだんと価値経済へ移行してきてる気がする。価値経済ではその人個人の能力やスキル、そしてその人がもつコネクションが強い世界。つまり人的資本と社会資本が強い世界。クラウドファウンディングもその流れの1つだと思う。お金がたとえなかったとしても、その人の能力や知名度や人に共感されるようなものを提供しようとする気持ちがあればお金を集めることができる。今回の考えからすると人的資本や社会資本をそのまま金融資産に換金できる仕組み。CampfireやPolcaなどのクラウドファウンディングやギークハウスなどのシェアハウスが盛り上がってきてるのもこの辺だと思う。お金よりも人柄の時代が来てる…かも。とは言え簡単には資本主義はひっくり返らないのでそれだけで食っていくよりもちゃんとお金を扱うための知識は学んだほうが幸福度は高くできる気がする。

社会資本について

シェアハウスに入ったり、コミュニティに参加したり、コミュニティを運営したり、ブログなどで発信して知ってもらう活動を通じて人とのつながりを増やしていく。これをどんどん行うとコネクションがたくさんできてくる。友人がたくさん増えておもしろい人とたくさんつながることで、そこから仕事の話をもらったり、こういうバイトあるよと言ってもらえたり、または人を紹介してもらったり、人と人をつなげたり出来るようになる。社会資本が人的資本につながったり、社会資本が社会資本を呼ぶ。これは金融資産などと同じで大きくなれば大きくなるほど効率が良く、大きくなりやすい、気がする。やっぱりコネクションはその点でみても金融資産と同じように複利で大きくなるので資本と言ってもよさそうな気がする。

個人的に思うこと

人とのつながり大切、とここまで言って来たけど、人とのつながりだけに全振りするのもちょっと考えもの。イベントとか行くととりあえず人とつながっておこうみたいな人がたまにいるけど、相手と対等なコミュニケーションを取るためにはお互いが心地よいなという関係を築く必要があって一方的にクレクレ君だと相手が迷惑なだけで。なので相手との共通項を作ったり、自分の好きなことでスキルを広げていったりして、ちゃんと人として価値を着けいてく、人的資本も増やしていく事も前提としてやったほうがいいとは思ってる。

ぼくのこれまで

東京に就職で移住して、5,6年東京に住んで、沖縄に移住してもうすぐで2年になる。なので大きい移住は2回。これまで人とのつながりが幸福につながる、と強い意識してたわけではないけどもともと人と仲良くなるのが好きみたい。いま振り返ってみるといろんな人と仲良くさせて頂いてたので東京での生活が楽しかったのかも。東京で活動してたことで社会資本が増えそうなやつをあげてみる。特にまねしろというわけでもなく誰かのヒントになれば?と思って書いてみる。

最初に就職した会社は4000規模の会社で同期が200人いたので同期と仲良くなる

同期や先輩がたくさんいる環境だったので仕事してるだけで仲良くしてくれる人が増えるいい環境だった。

上京したては地元の仲いい友達3人で共同で家を借りて住んでた

横浜に住んでた。横浜最高なのでまた住みたい。

語学勉強の英語のサークルに参加する

最盛期1ヶ月に25回参加してた。平日の仕事終わりや週末に参加しまくってた。英語がうまくなりたかったし、話す機会を増やそうと思って行くようになったのがきっかけだけど、何度も顔合わせる人も居てコミュニティとしてとても居心地が良かった。

英語のサークルを共同開催で3年主催した

英会話サークルをきっかけで知り合ったメンバーと一緒に朝活で英会話サークル開こうとなって3年間続けた。朝早起きして英会話しようというモチベーションの人が集まるので面白良い人がたくさん来てた。とてもいいコミュニティだった。

プログラミングの勉強会やイベントに参加する

エンジニアは勉強会と称して技術の知見共有を目的として集まる文化があってとてもおもしろい。なかなかこうやって同業種だけど別の会社で働くひとと横のつながりを広げていける業種はそうそうない気がする。 とくにRubyのコミュニティは人とのつながりを大事にする人が多い感じがあって、そこを中心として活動してた。Rubyの年1の大きなイベントのRubyKaigiは3年間スタッフとして参加した。あまり知り合いが居ない状態からのスタートだったけど、スタッフは人と話す必要があるので話すきっかけを作りやすかった。

4つのシェアハウスに住んだ

合計で3年くらい?最初は地元の3人で住んだ家(これはシェアハウスといえるか微妙)。

次は渋谷と恵比寿にあるシェアハウスで月3.6万で安めなので色んな人が居たけど人数が多かったので気が合う人も結構いた。英会話コミュニティの人でシェアハウスに住む人が結構いたのでその人達の話を聞いて興味を持ち始めて、その時池袋に勤務してたので横浜から池袋に電車移動するのがつらくなってきたので近い場所に引っ越そうと思ったのがきっかけ。

一度、一人暮らしもしたんだけど寂しすぎるのと、特に家にかえる理由がなくて2ヶ月で辞めた。

3つめは、今はなきギークハウス秋葉原ギークハウスというものをネットで見つけてコンタクト取ったところ3日後から住めますよーとのことだったのですぐ引っ越した。なつかしい。本当は会社の近く(代々木)にしたかったけどその時住みたかったギークハウス新宿空きがなかったので紹介された秋葉原に。空いたら引っ越すという感じで短期的に。住む環境を変えるのは新しい発見があって楽しい。

4つめがギークハウス新宿、ホーム。当時住んでたメンバーがとても個性的で面白い人ばっかだったし、新宿・渋谷あたりへ歩いて行ける距離だし、会社まで歩いて行ける距離だったのでめっちゃ幸福度高かった。

まとめ

社会資本と難しくいうけど、ようは気心の知れた友達やご近所さん、同じ共通意識を持った人たちとの関係を少しずつでいいからつくりましょうということ。移住してお金も知り合いもない状態(貧困)でスタートするのは不幸に陥りやすいので友達を作りやすい環境を選ぼう、その一つの方法としてシェアハウスに住むのは有効だよという話でした。無意識的に出来る人もいるけど、そうでないなら意図的にやっていく必要があるんじゃないかなというのが今回伝えたかったところ。エンジニアやwebが好きな人ならギークハウスに住むといいし、共通の趣味が合いそうな人がいるシェアハウスがあればそこに住んでみるといいと思う。ギークハウスは国内に40くらいあるので、どの地域に行っても遊びに行けるコミュニティがあるのはとてもいいと思う。東京でぼくはギークハウス新宿に住んでました。ここはエンジニアも住んでますが、地方からくる若者やこれからエンジニアになりたいけどまだフリーターみたいな人も結構住んでてこれから東京に移住したいって人なんかにはオススメだと思います。今は沖縄に住んでて、沖縄にギークハウスを立ち上げたので興味あるかた居たらギークハウス沖縄に遊びにきてください🙌🙌🙌

ISUCONをRuby, Sinatraでいい感じに戦うためのツール

以前書いたとおり最近は学生にISUCONを教えるプロジェクトやっていて今日は模試第4回を僕が管理するギークハウス沖縄で行いました。プロジェクト開始から4ヶ月、彼らもちゃくちゃくと実力を着けていってます。

今回は6予選を題材に行いました。いつも通り学生チーム(4人)対1人でやりました。今回は1人では実装時間足りず、1箇所ドハマリしてしまって思うようにスコアが出せず残念な感じになってしまいました…

さて、プロジェクトを通してこれまで4回模試を行ってきてある程度使うツールが決まってきたので知見を残しておこうと思います。

ISUCONでは時間が有限なので出来る限り、計測しながらボトルネックを探していく手法が有効になります。そのために使うツールを紹介したいと思います。

想定するユーザーは

  • macOSユーザー
  • Ruby, Sinatraで行う
  • ローカルで使ってコーディングする

です。

サーバー周り

sshrc

GitHub - Russell91/sshrc: bring your .bashrc, .vimrc, etc. with you when you ssh

sshrcはsshする際に手元にあるファイルを持っていくことができるツールです。

# ~/.sshrc
cp $SSHHOME/.sshrc.d/.aliases $HOME
cp $SSHHOME/.sshrc.d/.bashrc $HOME
cp $SSHHOME/.sshrc.d/.vimrc $HOME
cp $SSHHOME/.sshrc.d/.gitconfig $HOME
source $HOME/.aliases
source $HOME/.bashrc

自分の環境ではこのように .aliases, .bashrc, .vimrc, .gitconfig などをどのサーバーに入るときも持っていくようにしていていつも通り作業ができるようにしてます。サーバー上ではvimを使って作業することが多いので.vimrcがあると便利です。また.gitconfigを持っていくことでサーバー上でコミットしてもユーザー名やemailがおかしくなることがないので便利です。変なaliaseを作るのをよくやっているので.aliasesも必須です。いつも使ってるツールを持っていきましょう。

htop

htop - an interactive process viewer for Unix

topのもうちょっとグラフィカルな感じのやつ。

$ sudo apt-get install htop

なんかでいけます。

f:id:saboyutaka:20170823004425p:plain

CPUのコア数・各CPUの使用率、メモリのサイズ・使用率、スワップのサイズ・使用率、ロードアベレージの量、CPUを専有しているプロセス、メモリを専有しているプロセスなどはこちらですべて監視します。ここを見てどこがボトルネックなのかをだいたい推測します。CPUバウンドなのか、IOバウンドなのか、アプリケーションヘビーなのか、DBヘビーなのか、などです。

上の図を見るとunicornのCPU専有が支配的なのでRubyの処理に何か問題がありそうです。

Makefile

なんども使うコマンドはmakefileに記述し再利用できるようにしてます。ruby, mysql, nginxの再起動、ログのtail、benchmarkへのリクエストなど。こちらは大部分は予め作っておきます。

.DEFAULT_GOAL := help

restart: ## copy configs from repository to conf
    @sudo cp config/nginx.conf /etc/nginx/
    @sudo cp config/my.cnf /etc/
    @make -s nginx-restart
    @make -s db-restart
    @make -s ruby-restart

ruby-log: ## log Server
    @sudo journalctl -u isuxi.ruby

ruby-restart: ## Restart Server
    @sudo systemctl daemon-reload
    @cd ruby; bundle 1> /dev/null
    @sudo systemctl restart isuxi.ruby
    @echo 'Restart isu-ruby'

nginx-restart: ## Restart nginx
    @sudo systemctl restart nginx
    @echo 'Restart nginx'

nginx-log: ## tail nginx access.log
    @sudo tail -f /var/log/nginx/access.log

nginx-error-log: ## tail nginx error.log
    @sudo tail -f /var/log/nginx/error.log

alp: ## Run alp
    @alp -f /var/log/nginx/access.log  --sum  -r --aggregates '/profile/\w+, /diary/entry/\d+, /diary/entries/\w+, /diary/comment/\d+, /friends/\w+' --start-time-duration 5m

db-restart: ## Restart mysql
    @sudo systemctl restart mysql
    @echo 'Restart mysql'

db-log: ## tail mysql.log
    @sudo tail -f /var/log/mysql/mysql.log

myprofiler: ## Run myprofiler
    @myprofiler -user=isucon -password=isucon

.PHONY: help
help:
    @grep -E '^[a-z0-9A-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'

だいたいこんな感じで使ってます。

Makefileを自己文書化する、こちらが便利そうなのでまねしてます。

nginx周り

alp

GitHub - tkuchiki/alp: Access Log Profiler

ISUCON 5でalpを使ってNginxのログを解析した話を参考に使い始めました。nginx.confのログフォーマットを変更すると使えます。

f:id:saboyutaka:20170823004935p:plain

SUMの降順でソートし、正規表現で同じようなリクエストをまとめています。これを見ることでボトルネックがほぼ一発でわかります。この表だと /, /keyword/.+ あたり。そのほかは優先順位低いので、ソースコードを見る必要すらない場合もあります。静的ファイルが上がってくる場合は、nginxでキャッシュさせるといいです。

チューニングを進めていくたびにalpを実行し、どこが一番時間がかかっているかを確認するために使います。alpめっちゃ大事。

Ruby, Sinatra周り

rack-mini-profiler

GitHub - MiniProfiler/rack-mini-profiler: Profiler for your development and production Ruby rack apps.

これから紹介するrack-mini-profiler, rack-lineprofなどは基本的にはローカルにアプリケーションをcloneしてきて使います。Gemfiledevelopment groupあたりに入れて使うといいです。

一つ目の用途は1リクエストでいくつのSQL文が発行されているかを見るのに使います。N+1を見つけやすくなります。

f:id:saboyutaka:20170823005147p:plain

2つ目は、flamegraph gemと合わせて flamegraphの表を出します。

f:id:saboyutaka:20170823005337p:plain

x軸はcall stack, y軸は全体に対してかかる時間の比率です。y軸を見ることで時間がかかっている処理を見つけるのに役に立ちます。

上の表だと水色の処理が支配的でカーソルをあわせてみるとRubyの処理で htmlify が遅いのがわかります。

rack-lineprof

GitHub - kainosnoema/rack-lineprof: Rack middleware for easy line-by-line profiling using rblineprof

1リクエスト投げたときに1行ごとにかかった時間と実行された回数、処理に時間がかかっている箇所が赤く表示されて、どの行が遅いかが分かります。

f:id:saboyutaka:20170823005507p:plain

先程、flamegraphで htmlify が遅いのがわかりましたが、rack-lineprof を使うことでさらに gsub で正規表現マッチしているところが遅いのがわかりました。このアプリケーションで一番重いのがここなので、最優先タスクがここの高速化だというのがわかりました。

rack-lineprofは標準出力に表示されるので、ローカルで開発する際は手軽な rackup コマンドでsinatraを立ち上げるようにしてます。

MySQL周り

SequelPro

Sequel Pro

基本的にはGUI使うの好きなので、Sequel Proを使います

f:id:saboyutaka:20170823005658p:plain

sshでトンネリングして接続するとmysqlのportを外に開く必要がなく、楽に入れます。

f:id:saboyutaka:20170823005725p:plain

indexの作成は2クリックぐらいで貼ることができます。後述しますが、これは試しにやったりする程度でmigration残したほうがいいです。

f:id:saboyutaka:20170823005817p:plain

定義変更を実行後にコンソールをクリックすると発行されたSQLが見れるのでこれをコピペできます。(ALTER TABLEあまり覚えてないマン)

f:id:saboyutaka:20170823005859p:plain

あとは、普通にクエリ発行したりして、アプリケーションコードのSQLを変更する前にこちらで試したりします。実行時間を見て、さてはおめぇインデックス貼ってねぇな、とか気づけます。

goose

liamstask / goose — Bitbucket

DBのmigrationツールはなんでもいいのですが、Golang製のgooseを使っています。個人的にはシンプルなところが気に入ってます。

DBの変更を直接行うと、他のメンバーにその更新履歴を共有するのが難しくなるのでやっぱりgitで管理したいということでmigrationツールを使うことをおすすめします。

SequelProで試しに実行して、コンソールからコピーして、migration fileに貼り付ける感じでやります。

$ goose create create_star_table sql

のようにSQL形式でmigration fileを作成し、

-- +goose Up
-- SQL in section 'Up' is executed when this migration is applied

CREATE TABLE `star` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `keyword` varchar(191) COLLATE utf8mb4_bin NOT NULL,
  `user_name` varchar(191) COLLATE utf8mb4_bin NOT NULL,
  `created_at` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;


-- +goose Down
-- SQL section 'Down' is executed when this migration is rolled back

DROP TABLE `star`

みたいな感じにします。テーブルを別のDBから違うDBに以降しようとする時に作ったものですが、 CREATE TABLE 文はSequelProの情報タブに書いてある文をコピペしました。

あとは、

$ goose up

でmigrationが走ります。RailsやLaravelとかやってたらいつもどおりですね。

gem で sinatra-activerecord がありますが、やりたいことに対して複雑すぎるので使ってません。

myprofiler

GitHub - KLab/myprofiler: Sampling profiler for MySQL

DSAS開発者の部屋 pixiv private isucon 2016 攻略 (1/5) などで紹介されていたので使ってみてます。

デフォルトでは1秒に一回のインターバルの間に終了しなかったSQLの数をカウントします。これを使ってslowクエリを見つけたりします。ただ最近はrack-mini-profilerとrack-lineprofでおおよその検討はつくのであまり使わなくなりました。

general log, slow query log

mysqlの機能でgeneral log, slow logの機能をアクティブにして使います。

[mysqld]
general_log
general_log_file=/var/log/mysql/mysql.log
slow_query_log
slow_query_log_file = /var/log/mysql/slow.log

general_logでSQLの発行回数やどんなクエリが発行されているかを確認し、slow_query_logでスロークエリが発生しているかを確認します。slow_query_logはmyprofilerとかぶっているところがあるのでどちらかでいいかもです。

まとめ

基本的には

  1. alpで全体を把握
  2. rack-mini-profiler, rack-lineprofで深掘り
  3. チューニング
  4. 1に戻る

を繰り返すことでいい感じにスピードアップできるんじゃないでしょうか。ISUCON、ウェブの総合的な学習にとてもいい感じで教えるのがとても楽しいのでいいですねー。教えてる学生が予選突破してくれるといいなぁと思ってます。沖縄県内の学生でやりたい人いたらまた来年やろうかなと思うので連絡ください🙌

P. S.

最初は学生に教えるだけで自分は出る予定なかったけど、教えるにつれてどんどん自分も出たくなって来てます😟

しかしいまだメンバーおらずフリーなのでどこか拾ってくれる方いたらチーム入れてください!😭😭😭

ISUCON出場に向けてコーチ?的なことやります

f:id:saboyutaka:20170414094425p:plain

最近

仲の良い沖縄の大学生の樹理と 将義にWebエンジニアリングを教えこんでISUCON本戦に出場させるプロジェクトをはじめた🏃

きっかけ

2人がエンジニアになりたいけど、就活どうやればいいかわからないという感じだったのでおそらく東京でエンジニアになる最短経路としてISUCON本戦出場すれば超凄腕エンジニアが集まる場所にいけて、その実績が就活になるんじゃないかなーというのがきっかけ😎

ISUCON

isucon.net

ISUCON、たぶん今年も秋に開催されるはず。社会人枠は超ハイパーエンジニアばかりが集って恐れ多いんだけど、学生枠はまだそこまで難しくなさそうなのでかけだしエンジニアの2人を半年間ISUCONに必要な技術に特化して教えて対策すれば予選突破は行けそうだとふんでる。

あとは二人の頑張り次第。

自分のためにもかなりなりそう

教えると言っても自分もわかってないところたくさんある(特にISUCONに重要なnginxとかミドルウェアの設定周り)ので教えながら自分が学べるというおれ得なやつでもある😇

あと自分も仲間見つけて挑戦できるといいなぁ、社会人枠で突破するのめちゃくちゃ難しそうだけどやらないよりは良さそうなので..

2人やISUCON出場興味ある方は連絡ください🤘

2人のブログ

matsuda-juri.hatenablog.com

masa-world.hateblo.jp