僕なりの幸せの考え方
"自分の人生は幸せだろうか"と自問自答したことはありますか？
宗教とかそういうのではありません、ポエムが書きたくなっただけです。
僕の答えは"たぶん幸せ"。
"たぶん"って付いてるのは、幸せの定義がまだ自分の中で定まりきっていないから。
僕は、幸せって人それぞれ違ってて、自分が幸せかどうかは自分にしかわからないものだと思ってる。
価値基準が人それぞれ違うのだから、他人が「○○さんは幸せ」などと判断できるものじゃない。
例えば、お金持ってれば幸せ、みたいな考え方はあるかもしれないけど、
それは一つの尺度でしかなくて、現実に存在するもので測ろうとするともっと複雑なものだと思う。
いらないというわけではなく、たしかに必要な要素ではあるけれど、それだけで幸せかどうかを判断することはできない。
お金を持っている人は相応に努力や苦労があると思うし、そういうのを無視して測れないと思う。
それに、友達とかお金では買えない要素もあるし、きっとそんなに単純ではない。
では、どうやって僕が自分を幸せだと判断したのかというと、"自分のことを自分が幸せだと思っているから"。
自分で書いてて何言ってんだこいつと思うけど、これ以上の言い方を思いつかないので許してください。
上に書いたように、「自分が幸せかどうかは自分にしかわからない」ものだとすると、
自分が幸せかどうかって自分が決めるしかなくて、他人に何と言われようが関係がない。
幸せかどうかの基準は自分で作るしかなくて、それを満たしているか判断するのも自分。
こう考えると幸せってとても単純になるけど、
自分が相手だから基準の設定を妥協できないし、基準を満たしているか誤魔化せないのでとても難しい。
まとめると、幸せって人によって違うから自分で判断するしかなくて、
幸せになるために努力すれば誰でもなれるものだと思いますよ、という感じ。
これは僕自身の考えたことあって、他の考え方もあると思う。
それはそれで良くて、自分で納得できる答えが重要なのかなと思う。
競技プログラミングしませんか?
本記事はマイネット Advent Calendar 6日目の記事です。
今回は、社内でFFXIVを布教している@zakiryがお送りします。
はじめに
自分のコーディング能力を上げるために競プロで訓練を始めたけど、 やっている人が身近にいなくて誰にも相談できない状況を改善したい記事です。
競技プログラミングとは
問題が出題されるので、その問題を解くコードを制限時間内に作成するものです。
コードを提出すると、主催者側が用意した入力データで実行され、出力データが正しいかチェックされます。
基本的に、標準入力を取得して、ゴニョゴニョ問題を解いて、標準出力する、
というもので、実行環境を準備すればできるので参加しやすいと思います。
メリット
- コーディング速度が上がる
制限時間が設けられているので、できるだけ早くコードを書く訓練になります。 - コードの質が上がる
先程は省略しましたが、問題にはプログラムの実行時間が制限されています。 実行時間が制限されていることを意識して、できるだけ少ない計算量で結果を出力するコードを書く訓練になります。 - 数学力が上がる
難しい問題では、数学の知識がないと解けなかったりします。 全部覚えようとすると大変ですが、少しずつであればそんなに大変ではなく、 数学に触れる良い機会になります。
個人的にはこの辺りが競技プログラミングをやって得られるものだと思っています。 デメリットが有るとすれば、多少時間を使うことくらいではないでしょうか。
始め方
競技プログラミングをやっているサイトをいくつか紹介します。
Atcoder
一番おすすめです。理由としては、全て日本語、終了後に解説をしてくれる、様々な言語に対応している、などです。 問題が日本語で出題されるので、コーディングに集中することができます。 また、終わった後には解説の資料なども公開してくれるので、わからない問題があっても資料を見て勉強することができます。 採点システムが日々改善され、使用できる言語の数が徐々に増えています。TopCoder
一番大きなコンテストです。 海外のサイトすべてに言えるのですが、開催時間が日本時間だと深夜、問題が英文、といったあたりがネックになりやすいです。 レッドコーダーという言葉を聞いたことがあるかもしれませんが、 それはこのコンテストのトップクラスの人達のことで、とてもすごい人達です。
おわりに
ソーシャルゲームの運営という業務なので、 ソースコード上の処理よりもDBへの読み書きがネックになるなど、業務では全く別の知識も必要になります。 それでも、コードを書くということは、基礎になる部分だからしっかり鍛えたいと思います。
ISUCON5本選に参加しました
ISUCON5本選に参加してきました。
結果は9位でした！
(failしなかったチーム数は11でした)
やったこと
僕が仕事に追われている間にtakashabeさんが書いてくださったのでそちらを参照下さい 2015-11-03 - takashabeのブログ
感想
すごく楽しかったです！
本戦の結果からも分かる通り、自分の実力の無さを思い知らされました。
講評で「実はAPIはこんな風になってました」って聞いて、
「それわかってたら何がやれただろうか」と考えてみても、
そんなに多くのことはできなかったんじゃないかと思います。
知識量が全く足りてないので、トップクラスの人に追いつけるように日々努力したいと思いました。
懇親会では、他のチームの人にどんな実装にしたのか、どんなふうに役割分担したかなど話したりできて楽しかったです。
人見知り気味なのですが、初めて会う人とあんなに話したのは初めてかもしれないくらいです。
ISUCONは今年初参加で、他のチームは毎年出場してる人が多いのかなと思っていましたが、
他にも初参加という方いましたので、興味がある人は自信がなくても来年など是非参加しましょう！
おわりに
運営に携わった皆様、本当にありがとうございました。
来年はもっと上を目指す！
ISUCON5に参加しました
ISUCON5にチーム名"ピザはバランスいい"で参加して、予選突破しました。
メンバーはtakashabeさんとnohamaさんと私の3人です。
全体的な方針については、 過去問とボーダーの点数ややったことを見る限り、 初期構成を改善しコードの大きな書き換えはしなくても予選を突破できる点数に到達できる、 という確信があったので nginx+ruby+MySQL の構成で実装しました。
役割はこんな感じで分担しました
takashabeさんにnginxとMySQLの設定を行って頂きました
ISUCON 5予選を突破してきました - takashabeのブログ
アプリケーション改善班では、最初はペアプロみたいにやっていたのですが、 14時を過ぎた頃には作業的な部分が残り出したので分担して書き換えていました。
今回やって大きくスコアが上がったもの
- unicornのworker数を増やした(初期設定は1だった)
- is_friend?が何度も呼ばれているのを改善
- '/'で1000件取ってループしてるのをクエリ一つで済むように改善
- relationsへのSELECTクエリの改善
- footprintsへインデックス追加
- viewからget_user(user_id)されているのを改善
- commentsにインデックスの追加
やりたかったけどできなかったこと
- entries, commentsテーブルのカラム追加(時間がかかりすぎたので断念)
- viewでDBに接続されてる部分の削除(気づいたのが遅すぎ(1740頃)で手をつけなかった)
上記のような感じでした。 それぞれもう少し詳細に書きます。
2 is_friend?が何度も呼ばれているのを改善
コードを眺めていて、最初に目についた部分です。
is_friend?の中で1回クエリが実行されるので、そのユーザのフレンドリストを全部取得した。
クエリの数が大きく減ったはず。
3 '/'で1000件取ってループしてるのをクエリ一つで済むように改善
2の続きで、1000件取ってループしなくても、'where in' でフレンドのID突っ込めばクエリ一回で済むよね、ってことでクエリを改善した。
4 relationsへのSELECTクエリの改善
relationsへのSELECT文でORを使っていたのですが、INSERT文を見てみると双方向にレコードが作成されていたのでORを削除(レコードを半分にするか迷ったけど、データが壊れないようにSELECTを変更)
5 footprintsへインデックス追加
footprintsテーブルにインデックスがなかったので、user_idをインデックスに追加
この辺で、作業を分担し始めた。 ここまで行った後のクエリログを見ると、 entries,commentsをJOINしたものとusersへのSELECTが大きなボトルネックになっていた。
6 viewからget_user(user_id)されているのを改善
MySQLのクエリログを見るとusersへの単純なSELECT文が何度も行われているが、app.rbを見ていても原因がさっぱりわからなかった。viewを見てみるとget_user(user_id)されてる部分が何箇所も見つかった。usersテーブルとJOINするようにクエリを変更しusersへのクエリが激減した。
7 commentsにインデックスの追加
entry,commentsをJOINするSELECTが遅いということで、いろいろ試した結果 ORDER BY が遅いらしいという推測し改善することに。インデックスを見てみるとWHEREで指定されてるものと、created_atにはインデックスがあるのになぜか遅い。私自身は知らなかったのですが、一つのSELECT文でインデックスは一つしか適用できない、とのことでcreated_atのインデックスがORDER BYに使用されていなかったらしい。インデックスを追加したらかなり早くなった。
この辺までやって17:20頃。この後は再起動したり、それぞれ簡単に改善できそうな部分を探したりしてた。
ここから個人的な感想とか学んだこと
最初に、ISUCON初参加でしたが予選突破できてとても嬉しいです。 社内のメンバーで2~3ヶ月前くらいにISUCONに出ようって話が出て、週に4~6時間ペースで練習してきたかいがありました。 月・木の業務終了後に2~3時間くらい、過去問やった後に、ピザを食べに行く(チーム名に反映されています)ということをやっていました。 いろんな人の記事を見ながら過去問でいろいろ試したこと、kazeburoさんのyapcでの”ISUCONでの勝ち方"の2つがとても大きかったと思います。 予選当日は緊張と焦りでtypoしまくる私に対して、nohamaさんが冷静に改善を続け、takashabeさんはベンチを走らせた後に解析結果を出してくれたりと、チームメンバーにはとても感謝しています。
今回、やって学んだのはやったことの7で書いたとおりMySQLのインデックスに関することでした。 予選当日以外では学ぶことだらけでした、いろんなツールに触れたりできたので良い経験になりました。 反省点としては、コーディング能力が大きく落ちていると感じました。 5年以上前ですが、競プロやってた頃はもっと早く正確にコーディングできていたなーと思ったので、 AtCoderなどで練習しようかなと考えています。
本戦では、他のチームすごい人ばかりで優勝できる気がしませんが、 少しでも良い結果を残せるように、1ヶ月間準備していきたいと思います。
おまけ
ゆるゆり3期放送開始楽しみ
