makotan _at_ gmail dot com

社員の採用の検索とか書類チェックをしてる人から聞いた話

最近採用関係をやってる人が凄く近くに居るので、その人から聞いた話のメモ

書けない情報もある

NDA違反になるような情報は絶対に書いちゃダメ。
面接の時に言うのも基本的にNG

期間が空いてるとき

就職と就職の合間の1ヶ月間休みましたとかはどうでも良くて
半年とかそれ以上の期間が無職状態で空いてるときは何らかの理由があった方がお互いにフィルターになるので良い

やりたいことを書く

今は出来なくても将来こんなことしたいとかの展望、野望、希望を書く
特に年齢の低い転職の時にはいっぱい書いた方が良い

やりたくないことも書く

最近はSES契約は嫌だとか言う人が多いらしい
そんなことも含めてやりたくないことは明記する方が良い

今できることを書く

今までのキャリアから今できること、転職先から期待してもらえることをしっかり書く
ここ意外と大事らしい
あんまりない年齢の低い転職の時には先輩から評価されてるポイントとかをアピっとく

必須の条件も明記する

転職先が満たしてないとダメそうな所を明記する
この辺に希望年収とか色々
お互いのフィルターになる

しょぼいミスしない

チョットしたところのミスに気をつける
転職の書類っていうわりと人生の大事な書類にミスがないように数回チェックした方が良い

これまでの経歴はざっくり

こんなのを作って、こんな役割で、こんな物を使って、この期間で作りました
って言うのが並んでれば基本的にOK
全部アピールポイントがある人はそんなに居ないはずなので、面接の時の話のネタにしたい奴を中心にするのもあり
経歴が大量にあるときは、転職したい会社の近いキャリアの物を集中投下すると良いと思う
それ以外はほんとにざっくりまとめる
年齢の低い転職の時は逆にアピールポイントを捻出するのを頑張る

まとめると

いっぱい書いた方が良いよ

NASが壊れた

記録によると2011年には使ってたので仕方ない気はする


急ぎのものはないとはいえ、全てのデータへまるっとアクセス出来ない！
ということで色々調べたところ・・・同じメーカーのNASを買ってきて入れ替えれば良いらしいということまで判明
取り急ぎ新しめの機種で欲しいものをリストアップしたので後は選んでポチるだけ←イマココ


ふと考えた
イマドキNASなんてローカルに置かなくても良いのでは？？
HDDが2Tなので、とりあえず2Tとして計算しようかと思ったけど実際には1Tも入ってないので・・・計算を楽にするために1Tで
まずは仕事で何かとお世話になってるS3(オレゴン)、NASの代わりなので、低頻度アクセスストレージで$0.0125/GBで$12.5/TB
GoogleDrive \1300/TB（S3をドル換算すると現状はこっちの方が安い）
OneDrive (Office 365 Soloの値段) \12,744/1 年 1Tのストレージ付きなので今のところ最安値というか、これでOfficeも使える！んだけど・・・businessにしかNASが対応してないから使えるか不明


という感じでここまでは1000円位のOneDriveが最安値なんだけど・・・
S3なら使った分だけ課金なので、実際に500G位ならS3が安いって事になる


さて、本命Glacier
$0.004/GBで$4.0/TB
桁が違ってて圧倒的に安かった。
代わりに取り出しにお金がかかったりするのでホントにアーカイブ向けのストレージなのでNASクラッシュの時のバックアップ用って意味合いで使うには良いなと
たまにアクセスするならGCPのColdline辺り(価格は倍近いけどS3の低頻度アクセスストレージより安い)かなと。


ということで、用途別にまとめるとこうなった
純粋なバックアップストレージとしてだけ使う=Glacier
たまにネット経由でも同じデータを取得したい=S3,GCPのColdline,OneDrive for Business
Officeのライセンスも必要でたまにネット経由で=OneDrive for Business
音楽データがメイン=GooglePlayMusic+何か


部屋の模様替え実施中で結構な出費予定があるのに、さらにNASですか・・・
次にNAS買ったらもうファイル保存用のNAS買わない(Time Machine用は除く)ぞと心に決めた
(まだポチってない理由はどれにするのか再検討する＆模様替えの途中のため)

(追記)
さくっとNASポチった

マルチサービスデータベース

年の瀬にぼんやり考えてた


Aurora、Redshift、Athena・・・
と色々とSQLを使うサービスが登場してるわけですが
それぞれ特性が異なってるためにデータを入れ替えつつ使い分けをするそんな日常


これらの上位にSQL対応のDB Proxyサービスを設置
データは種類に応じて定期的に各々のサービスにコピーされていく(マスターはAurora)
SQLを投げると、その対象期間とかSQLの内容に応じて自動的に実行するサービスを切り替えて実行
通常は普通にAurora or PostgreSQL、沢山の集計処理とかが入る場合はRedshift、Auroraに無い古いデータを見る時はAthena、対象が古くて且つ沢山の集計処理の場合はRedshift Spectrum
みたいなのを自動的に判断して実行


って言うのがあれば良いのにな


このサービスいつAWSが出すのか教えて！エライ人！

2017年振り返り

総括すると良い一年でした



趣味でwebなアプリ作ろうとしてたけど、結局画面の無いアプリ作ってる
webアプリ作ろうとするとめんどくせぇ〜ってなってそのめんどくささを解消したくなるので致し方ないｗ



比較的健康な1年、比較対象は周りの人ｗ
周りが頭痛とか腰痛とか何かと痛そうな人が多いのでそれに比べるとアレルギーくらいだし健康だなと
過去の経験から、あとは健康的に瘦せれば小さい問題も片付く


お仕事大変
色んな想定外がいっぱいの1年
あと、昔仕事で作ったサービスが想定外のところで使われててびっくりした


勉強がすすまなかった
年始に色々勉強しようとしてたのがあんまり進んでない
ゲームに時間吸い取られすぎた気がしてる。来年はGTとエースコンバット位しかしないつもり


片付け進んだ
10年ほど続いてる断捨離ブームの結果、家の片付けがだいぶ進んだ。
ゴールはさらに荷物を数割減なのでもうちょい先だけど、大きなマイルストーンまではあと少し！
この後がなかなか大変そう・・・

だいぶ前にぼんやり考えてたメールサービス


細かいの端折ってまとめると
相互認証をした間とその派生の間で信頼性と秘匿性の高いメールネットワークを構築する
各ドメインはサーバも独立してて、ドメインの信頼と公開鍵をブロックチェーンで管理する
あるドメインから大量のゴミメールが流れてきた場合にはブロックチェーンに記録して全メールサービスでブラックリストを共有
A-B, B-Cで相互認証をした場合、A-Cの相互通信も可能
Cが大量のゴミメールを送ってブラックリスト入りした場合、Bの信頼が低下する
ある程度信頼が低下したドメインはブラックリスト入りする
メールの送受信の時には宛先情報は相手の公開鍵で暗号化、本文は自分の秘密鍵を使ってキーを暗号化する
鍵を変更したい場合はブロックチェーンに記録する
これを今のSMTPの上に載っける（＝これを使わなければ普通のメールになる）


こんな風にやればだいぶ安全なメールサービス作れそうだけどなぁ〜
ってぼんやり考えてた


コンセンサス・アルゴリズムどうするかってところで思考停止したのは秘密
プルーフ・オブ・ステークになるだろうけど、コインじゃ無いしメール配信に採掘が必要ってのもなぁ・・・

HTTPベンチマークを見ながら思うこと

注：今年感じた個人的感想です

HTTPな各種サーバを大きく分けると


純粋な非同期サーバの開発言語として有名なのはGoとNodeの2つ
色んなベンチマークで優秀な結果を残してるので最近の高トラフィックな環境でもよく使われてる感じ
特徴的なのはランタイムも非同期がベースに構成されててCPUを生かし切る為に生まれてるような言語とランタイムになってる
特にコネクション数が増えたときの安定性は抜群


純粋なブロッキングサーバは最近減ってきたけど、まだ多少残ってる感じ
各種ベンチマークでボロクソに比較されて悲しい感じになる
問題はソケットの処理のためにスレッドを立てる必要があるのでコネクション数＝スレッド数になってC10K問題にキッチリぶち当たる
ただし、コネクションが少ない状態でのレスポンスの安定性は抜群だし、プログラムが凄く楽


非同期とブロッキングのハイブリッド
新しめのTomcatとか含めて純粋な非同期の前の主流な感じ
ソケットの処理そのものは非同期でやっておいて、メインの処理はブロッキングで書くみたいな感じ
特徴もやっぱり間くらいｗ
同時処理数＋コネクション管理用スレッド＝スレッド数になるので実はC10K問題はそんなに起きない


HTTPなベンチマークの特徴

  • 同時コネクション数をどのくらい処理出来るのかをひたすら試す
  • コネクションを張ってからレスポンスを受けるまでの時間の測定
  • コネクションを再利用しつつ、レスポンスを受けるまでの時間の測定
  • コネクションの再利用無しでレスポンスを受けるまでの時間の測定


この4種類くらいがあって、同時コネクション数が優秀な場合最初の1個しかやってないパターンが多い気がした
実際には実用的なコネクション数でレスポンスの良さを測定する必要があると思ってる
というのは、HTTPサーバの場合に限って言えば1台のマシンでC10Kを処理するWebサーバを作る事は世の中的に滅多に無くて、複数台使って秒間で1000reqの処理が安定して出来ていれば良いことの方が圧倒的に多いから。(CDNに逃がせる画像とかを除いて1000req/sは相当大きめの数値だと思ってる)


絶対的なコネクション数を試すベンチマークより、適当な数のコネクション数でどの程度のパフォーマンスが出るかの方が結構大事な気がする


そんなことを思った2017年もあと少し
今年は紅と白どっちが勝つんでしょう・・・