つれづれインフラぶろぐ

インフラエンジニアとして学んだことを書きます

記事の更新ペース

ろのです。
最近会社のサービスリリースを控えてかなり忙しくなってきました。
36時退勤ってやばいですよね。


さて、技術記事を書くモチベはあるものの、
「書きたい技術に関するインプットをする時間が足りない」
という問題が発生しました。
コンパイラ作りたいな~と思っているのですが、
時間がないので進捗が少しずつしか出てない現状です。

コンポーネントの1部分が出来上がって、
アウトプットできるようになったら更新しようと思います。
といっても、誰も見てないのでのんびりやっていき。

またね~

就活生よ、大量のエントリーで摩耗するな

ろのです。
Twitterで100社以上エントリーしてます、という方がいたので
新卒、転職を経験してみて思うところを書いてみようと思います。



やりたいことがある人へ

やりたいことがあるならやったほうがいいです。
誰かに勧められて違う職業にした時に後悔するのは誰か、考えてみてください。

もしやりたいことをやりたくて、それが出来る企業に応募してみたけど
いつも書類選考で落ちるとか面接で落ちるとかそういうことがあったら、
マインドとかやる気とかの問題ではなく、見せ方や説明に問題がある んだと思います。

  • 何をどうしたいのか
  • なぜやりたいのか
  • 今できることは何なのか
  • 自分が就職するメリットは何なのか
  • 自分がやると企業はどういうメリットがあるのか
  • 自分を雇うデメリットは何なのか
  • デメリットに対して自分はどうするのか
  • やりたいことをやった後どうするのか

この辺りが論理的に説明出来て書類や面接で落ちるなら、
合う合わないのレベルなのかなぁとは思います。

100社エントリーする時間があったら、
10社に対して上記の項目を筋道立てて説明出来るようになると、
効果的な就職活動になるかもしれません。

やりたいことがない人へ

やりたいことがないことをコンプレックスに思う方も多いと聞きます。
あなたは悪くありません、大体日本の教育のせいにしときましょう。
ただ、このまま何も出来ないまま終わるのも面白くないのでちょっと視点を変えてみる。

何か苦なく、ささっと出来るようなものはありませんか?
自分ではすごいと思っていなくても、周りの普通の人から見るとすごい、という場合は
ある程度仕事になると思います(ゲームが得意、友達の笑いを取れる、家事が得意など)

まずは苦なく出来る事を仕事に出来ないか、考えてみてください。
そしてその出来る事に関連しそうな企業をいくつかピックアップしてみましょう。
あとはやりたいことがある人と同じように筋道立てて説明できるようになってみる。
出来ないことや不足している何かがあったとしても正直に答え、今後どうするのかを
しっかり考えて行動していれば、必ず結果はついてきます。
就職した後は違う悩みが出来るしれませんが、自分を信じて自分で選択していきましょう。

新卒の待遇に満足出来ない人へ

ここからはエンジニア向けセクションかもしれません。
学生時代に培った技術がそのまま生きる事も多いITの世界、
たくさん頑張ったのにスタートの評価が一律じゃあつまらないですよね。
特に優秀なエンジニアさんからすると面白くない採用制度だと思います。
そんなあなたに私は敢えて新卒での就職をおすすめしてみます。

なぜか?

簡潔に言うと「社会人の基礎をつけられるから」です。
正直ここら辺は人によると思います。学生時代から社会人同様に仕事をしていたり、
日頃から学外で大人と交流する活動を行っている社交的な方には必要ないかもしれません。
個人的には社会人基礎皆無だったので、ある程度しっかり研修を行ってくれる会社で
研修を受けられたのはいい経験だったなと感じています。

自分は苦労しましたが、本当に技術がある方はいつでも転職出来ると思いますし、
もし自分のキャリアに加えてもいいなと思ったら新卒就職もよいかもしれません。
ここまであくまで自分の個人的な意見です。散々述べていることですが、

やりたいことを自分で選んで下さい


最後に

途中からちょっと話が逸れてしまった気がしますが、
自分がやりたいことのために努力すれば、きっとなんとかなります。
やりたいことがない人は、就職した後にきっとやりたいことが出来なくなって
ムズムズする時が来ると思います。そんな時に自分に問いかけてください。
本当にやりたいことはないですか?

情報科学若手の会に参加してきた

ろのです。
https://togetter.com/li/1196033

大体これ読めば良さそう。


前々から行こう行こうとは思っていたけれど、やっと今回初参加出来ました。
内容としては闇の深い話が多かった印象です。
(広告の闇、副業の闇、関数型名前を呼んではいけないあの人などなど)
個人的に面白かったのは端末制御の発表です。

端末制御の話の内容としてはgopromptの解説で、
実装に関わったシステムコールやらプログラミングの深いところを
細かく解説して頂けて非常に参考になりました。

話を聞いて端末goで書きたくなったので
スライドのURLを忘れないように張っておこうと思います。

www.slideshare.net

正直これを忘れないようにしたいだけのブログ記事でした。
技術記事を書けって?すみませんすみません...

梅原さんの動画を見た

ろのだよ。

はてブロのブログタイムマシーンで梅原さんの動画の記事が上がっていて、
見ていなかったのでチラッと見るつもりがどっぷり2時間見ちゃったので、
せっかくだしいい言葉を記事にまとめようかなぁと思った次第です。
(予定していた技術に取り組む時間がなくなったのもあるんだけどね!)

maname.hatenablog.com


飽きたっていうのは成長しないことに飽きてるんですよ

これかなり思いますね。前職に居た時の自分が完全にそれで、
成長しない、成長出来ていない気がするから飽きて、それを仕事のせいにしてましたね。
成長はしていたんだけど、望んでいた成長でなかったのも飽きる原因だったりしました。
うーん心にグサッときますね。

今取り組んでる事の10の内を全部変えてはいけないってことあんのかな?

変化するってのは大事ですよね。
変化しないとか停滞した状況って飽きる、に近づくんですよね。
梅原さんがいう「飽きる」って状況にならないための
対処法的なところもあるかもしれませんね。

周囲の期待って皆さんも多分ありますよね。  
でもそんなの知ったこっちゃないじゃないですか。  
勝手に期待すんなよって。  
大体期待って具体的じゃないんですよ。  
どうなれば相手(期待した方)が満足するかって全然明確じゃない。  
ただ何となく期待してる。で、相手を追い詰める。  
で期待に応えて期待に応えて期待に応えて、  
で自分(期待された方)は「あー人生つまんねーな」って思ってんですよ。
何のために生きてんですか。

ぐっと来ました。期待に応えてつまらないなら自分のやりたいようにやったほうがいい。
何せ、自分で選んで行動するのが大事ってことですね。
自分で選んで、後悔しないように生きよう。

何のために勝つのか、何のために成長するのかを明確にしないと、
何のために生きてるのかわからなくなる。

はい、実際何のために生きてるかわかりません!
よりよい未来のために成長しようとしてるけど、そもそもそれってなんのためなのかね。
難しいね。結局たくさんゲームして、みんなで楽しく生活できればそれでいいんだけど、
それがほしいのかなぁ、今は。

他にもいろいろ素敵なワードがありましたが、
とりあえずこの辺で。
次回はちゃんと技術記事書こうね。

0からわかるコンシステント・ハッシング

ろのだよ。仕事でmemcachedを触ることになったんだけども、

「とりあえずコンシステント・ハッシングと
 スラブ・アロケーターくらいはわかっておかないとね」

と言われたのでまずはコンシステント・ハッシングを調べてみました。

memcachedとは

コンシステント・ハッシングの記事ですが、
memcachedにおけるハッシュ法の記事になるので少し解説させてください。
memcachedとは、分散メモリキャッシュサーバです。DBの負荷を軽減したり、
DBを利用するシステムの高速化を図る目的で用いられます。
分散というくらいなのでmemcahcedのサーバは複数存在しています。
キャッシュするレコードに対して1つのサーバを選択してキャッシュをさせるのですが、
それらのサーバを一意に選択する際にハッシュを用います。

シンプルなハッシュ法

ハッシュやハッシュテーブルについては割愛させて下さい。(理解がある前提で書きます)
よくある動きとしては、
「keyをハッシュにかけて、サーバーの台数で割った余りを出す」 というのがあります。
これはサーバーの台数が決まっている場合には正常に動作しますが、
昨今のインフラでは急増したアクセスに対応する必要があります。

方法としては
「サーバーのスペックを増強する」
「サーバーの台数を増やす」
の2種類があります。
前者はお金も手間もかかるため、基本的には後者を選択することが多い気がします。

しかし、前述したよくある動きを適用している場合に、
サーバーの追加を行うとハッシュの再計算が起きます。
ハッシュの再計算が起きるとキャッシュヒット率の低下によって、
データベースへのアクセスが増大してしまいます。
このようなケースに対応するのがコンシステント・ハッシングです。

コンシステント・ハッシングとは

次の図はレコードがキャッシュされる際の動きです。
(mixi engineer blogさんからお借りしました、ありがとうございますm(__)m)

f:id:ronorono_45:20180121184032p:plain

コンシステント・ハッシングにおけるノードは100~200の仮想ノードにハッシュされます。
それらの仮想ノードは0~232の整数の連続体(以降円と呼びます)の中に配置されます。
新たなレコードのハッシュは円の中の点にマッチすると、
その次に大きいノードに対して格納されます。

f:id:ronorono_45:20180121185955p:plain

この円からノードCを取り除こうとした場合、
ノードCより小さく、ノードBより大きいハッシュのレコードのみが円から取り除かれます。
再度捨てられたレコードが呼ばれた場合は、ノードB以上でノードD以下となるため、
ノードDに格納される、ということになります。
以上の通り、コンシステント・ハッシングはデータロスが少ない
ハッシュ方法だと言うことがお分かりいただけたと思います。

コンシステント・ハッシングのデータ損失率について

これについてはmixi engineer blogさんの記事で検証されていたので是非ご覧ください。 alpha.mixi.co.jp

まとめ

とりあえず一通り理解は出来た。
以下、理解のために訪れたサイト一覧です。ありがとうございました。
ConsistentHashing - コンシステント・ハッシュ法
スマートな分散で快適キャッシュライフ - mixi engineer blog
第1回 memcachedの基本:memcachedを知り尽くす|gihyo.jp … 技術評論社

Golangのエラーハンドリングについて

ろのです。
初日から意思表明だけでは締まりがないので、
技術っぽいことを書こうと思います。


お題は「Golangのエラーハンドリングについて」です。
Golangのエラーハンドリングでは、
他の言語でよく使われているTryとCatch的なものを使いません。

また、Golangにはビルトインのerrorという
interface型のtypeが提供されています。

type error interface {
    Error() string
}

Golangの関数では戻り値を複数返せるため、
戻り値に返したい値のほかにエラーハンドリング用の値も返して、
呼び出し元のif文でエラーを判断します。
文章で書いても分かりにくいので例をご覧ください。

file, err := os.Open(filename) // オープン失敗時、errに戻り値が入る
if err != nil { 
    fmt.Fprintln(os.Stderr, err)
    return false
}

という感じです。

任意のerror interfaceを作成してエラーを返す方法はいくつかあります。

1. errors.newを利用する

2. fmt.Errorfを利用する

3. stringを返すError関数を実装したstructを自分で書く

これらについては気が向いたら書きます。
今日はこれくらいにしようかな~

参考にしたURL:
エラー・ハンドリングについて(追記あり) — プログラミング言語 Go | text.Baldanders.info

日記始めました

ろのです。
どうせいつものように続かない気はするんですが、
週1回日曜日にブログ書くことにしました。


理由としてはいくつかあって、
・アウトプット癖をつける

・やったことを残してモチベーション上げたい(自己承認的何か)

・どうせ忘れるからドキュメントに残そう

などいくつかあります。


Qiitaも併用して使っていく予定ですが、
使い分け方針としては基本はてブロにアウトプットして、
まとめて一つのトピックになりそうだったらQiitaにあげようかなぁ
みたいな気持ちでいます。

毎週技術のアウトプット出すのしんどいので、
ポエム的な週が多くなりそう。

続くといいなぁ。