退職をします
from: <censored>
to: <censored>
今日が最終出社日で、12月~1月は全部有給消化で次の所は2月の1日からです。
所属情報は明らかにしないスタンスなので聞きたい人は現実世界で聞いてください。
転職活動
今流行りのTwitter転職というやつをやってみました。ついったで「転職したい!」って言ってやるやつです。
転職活動自体は去年の2~3月くらいからずるずるやっていて、4月~5月くらいは左足首の手術で若干休んでいたのですが、普通に動けるようになってからまたふわふわ再開して8月くらいに1社からオファーを頂きました。
これまでの転職と違い、なんやかんや精神的に余裕があったので「もうちょっと色んな会社を見てみたいんです」とかいうクッソ我儘を言ってオファーを頂いた会社さんには待ってもらって、その後再度ついったで「転職したい!」ってついっとして転職第二期をはじめました*1。
二期の時はタイミングが良かったのか因果がいい感じになったのか、1回目のときより多くの会社さんに声をかけて頂いて、10社くらい面談に伺わせていただいたと思います。
こんなどうしようもない人間に本当に申し訳ないありがとうございますと言う気持ちがあり、そしてそれと同時に殆どの会社さんを選考対象と出来なかったので*2、非常にもうしわけない気持ちでいっぱいです。
どの会社さんも現職よりよっぽどちゃんとしており、対応してくださった技術者の方も優秀な方が多くて、いろいろ親切にもして頂いて、さて選考に進む会社を選ばねばならぬとなって非常に難しかったです。皆さんいい会社でした。
実際に選考に進ませて頂いた会社さんも非常に良い会社さんで、結局回答期限ギリギリまで悩んで、結果的に些細な所で差をつけざるを得なくて。
Twitter転職と言っても選考に進んでしまえばこのあたりの話は通常の転職と一緒ですね。
で、Twitter転職に関してですが「アカウントのプレゼンスがないときつい」と言う身も蓋もない結論になりました。ひよこにつづけハッシュタグなどを利用して露出していかないと、そもそも人事の目に入るという所がまずハードル高い。
後は、スケジューリングやら受諾、辞退やらは全部自分でやらなきゃいけないのでHPもMPも負担がそれなりに大きい。
その他には、地味にコミュニケーションチャンネルがバラけるので大変というのもありました。
というのも、転職サイトなら転職サイト上、あるいはメールで統一されますし、エージェント使った場合はそもそもエージェントに丸投げできます。
が、Twitter転職の場合はコミュニケーションチャンネルが、TwitterのDMの場合もあれば通常のメールの場合もあり、あっち見たりこっち見たりしなきゃいけないのが個人的にはけっこう大変でした。
ので、やはり個人的には転職は、求職者にとっては今後も転職サイト(Wantedly含む)やエージェントを利用する方法がスタンダードなのかな、とは思います(それはそれとして求人側は求人側でSNSを利用した一本釣り(ダイレクトリクルーティング)などを行わないと、昨今つらいのかな?みたいな印象はありました)。
そういえばWantendlyで思い出しましたが、Wantedlyは求人サイトではない*3ので、求職者が一般的に欲しいであろう、契約形態、待遇、福利厚生などの情報が掲載できません*4。
これは求職者側からしても、とにかく話を聞きに行かないとその辺確認できないのでつらかった。
雑感
社会人になってから現職で5社め、次で6社めです。今の会社に入社したのが2012年の7月らしいので6年いた事になります。たしかに長い間居たなとは思っては居ましたが、思ったより長かった。
転職理由ですがこんなブログ見てる人は大体僕のついった見てる人だと思うので「今更説明要る?」状態だと思うので今更細かくは書きませんが、いろいろしんどい事や音楽性が合わないことが多くなってきたからと言うのが主たる理由です。
あとはまぁ会社の商売の雲行きがあんまり良くない。良くない事自体はまぁ色々あるので別にいいんですが、良くないなら良くないなりに良くするようにちゃんとやれよと思うことが無限に増えてきてだるくなりました。端的にいうと「もう付き合いきれないなぁ」みたいなそんなアレです。
それでも悪いことばかりだったかと言うとそんな事は決してなくて*5、労基法はちゃんと守っているところだったりとか、あとはいろんな技術を使わせてもらえたところとか。
自由があると言えば聞こえはいいですが実態はただ放置放任されているだけなので、それが良い所かと言われたら一定議論の余地はあるんですが、それでも自分で自主的に色々試してみたいとか使ってみたいとかがあれば自由に*6やってよかったので。
結果的にそれで僕はスキル的には器用貧乏キメラになってしまったところはありますが、とにかくそこは良かったかな、と思います。
まぁ、基本一人プロジェクトなので寂しいとか聞きたくなっても周りに答えられる人居ないみたいなのはありましたが*7。
実は3年ほど前に一度転職活動をしていました。理由は差してかわりません、いろいろだるくなったからです。
選考も、さぁ次は給与交渉面談だぞと言うところまで進んでいて、実質的にほぼ内定出ていたかなぐらいの感じで。
だったんですけど、さぁ面談のスケージューリングをせにゃあと言う段になってある日いきなり会社にとある出来事が起こって*8。
詳細書けないんですごくふわふわした言い方しかできないんですが、いろいろと前提が崩れたので「ううむ仕方ない。とりあえず2~3年様子見てその時また考えるか…。」となって選考を受けていた会社さんには断腸の思いで事態を伝えました。MP減りすぎて死ぬかと思った。
で、それから3年経ったわけですが、まぁ、結果としては「やっぱりアカンかった」ということです。
次
どスタートアップに行きます。
どスタートアップですが給料は現職より上がります。
どスタートアップなのでまだサービスはローンチされておらず、商売がどうなるかは分かりません。その辺りは博打です。
Twitterで声をかけられた以上SNSも把握されているので当然このブログもきっと読まれているんだろうと言う中でこういうことを書くのはひとえに僕の社会性の無さ故なんですが、究極商売がうまくいかなくても*9その時はまたその時考えたらいい、だから僕は被雇用者としてやっているんだと言う部分があるのであまり気にしていません。
2~3年後うまく行っていれば万々歳だし、うまく行ってなかったらまた転職しよう。少なくとも確約されるであろう今からの2~3年の自由と裁量が最終的な決め手となりました。
まだ子供は出来てないですが、奥さんの年齢のこともあるので考えなきゃいけなくて。で、子供ができる前提で、一番大変だろうこの2~3年の時期にはやはり自由と裁量はあって困ることはないだろう、と。
もちろん人の人柄やスタンスに共感できたというのは大前提ではあるんですが、その上で、ある程度打算的な思いがあるのは事実だということですね。
まとめ
まとまりません。
こちらからは以上です。
状況(2018-08-13現在)
あれこれが長くなってきて、やっていくうちに分かってきたこともあるので追記(ほぼコピペ)
やってきた事
- Javaで受託開発(1社め)
- PHPでガラケーソシャゲ作り(2〜3社め)
- いろんな裏側のAPI作る仕事(4社め、現職)
- HBaseをバックエンドにしたAPIの保守(引き継ぎ)
- Play2でWebSocket使ってRedisのpub/sub使って負荷分散したシステム
- 社が昔から運営していたブログサービスの作り直し(会社の方針変更で途中で立ち消えた)
- とある基盤のシステムをgoで改善(あまりおおっぴらに書けない)
- 再利用性のある機能がとあるサービスに密結合していたりみたいなやつを分離してAPI化する仕事
- 会社のサービス基盤をAWSに移行する仕事
- ↑の上にswarm(≠swarm mode)とconsulとnginx(+consul template)と自作go製エージェントでDockerクラスタ作った仕事
- k8s調べてる(EKS発表されたし↑を移行したいねって話が出てそれで調べてる途中)
- バッチのキッカーをdigdagにした仕事
- golangやScala(Play2)使って細々としたAPI作る仕事
触ったことある技術
やっていきたい事
- 転職活動始める前に思っていたより自分はまだコード書いていたいと言う気持ちが強いことがわかった
- チームで自分と同等かそれ以上の人に囲まれてワイワイ仕事したい
- 一人仕事ばかりなので寂しい。
- 技術も基本独学でやってきているので自分でも正しいのか分からないでやっているのに微妙に社歴が長いのもあって何かご意見番みたいな立場になってしまいつっこんでくれる人が居ない
- mustではないができれば静的型付き言語を使っていたい
- (そこをメインにしつつ)場合に応じて適切なやつを選びながらいろいろ使ってやっていくみたいなのは嫌いではないです
やっていきたくない事
- 遅延証明受け取ってくれない会社で働くこと*1
- 根本的には、フレックスや裁量労働やリモート勤務可能みたいにそういう所で憔悴しない所がいい
- (人生の文脈で)将来的な事を考えた時に勤務方法に柔軟性があって欲しいというのもある
- 袖机を皆がちゃんと展開できない程度に人間の数に対してオフィスの広さが確保されていない職場での労働
- トイレに入っているのに勝手に電気が消される職場での労働
- スーツ着ること
- 長時間労働(3社めで死ぬかと思った)
あるとなお良い
- 懸垂台
上記辺りについて、転職活動をやっているなかである程度具体的な気持ちが見えてきた気がするので追記と言うか補足しておきます。
- リモート可
- やはりできればほしい。しかしMustとなると条件的に厳しいかなと言う状況も見えているのでその他の条件との兼ね合いによっては妥協
- フルリモートとかでなくてもいいです。基本的には出社するんだけど必要に応じて使うべきときに使いたいときに普通に使えてワークするみたいな感じです
- フレックス(開始11時以降)か(ちゃんとした)裁量労働
- 今の会社が最遅11時出社なのでコアタイムの開始が11時以降だと嬉しい
- 残業の中央値が少ない(月10時間前後程度)
- 自社
- 私服、勤務態度(イヤホンがとかついったがどうとか)でうるさく言われない
- 埼京線沿い住みにとってアプローチが良い
- 具体的には渋谷くらいまでの山手線西側か秋葉原くらいまでの山手線東側辺り
- 山手線の下側や内側は居住地からのアプローチ的にちょっとしんどい
- できればjava、scala、golang辺りを使いたい
- やはり型付きが好きなので。絶対これ以外やらないぞとまでは言いません
- できれば600万〜
- 自分の相場感分からないのでちょっと厳しいかな?とも思っている…が、できればほしい
状況(2018-01-26現在)
やってきた事
- Javaで受託開発(1社め)
- PHPでガラケーソシャゲ作り(2〜3社め)
- いろんな裏側のAPI作る仕事(4社め、現職)
- HBaseをバックエンドにしたAPIの保守(引き継ぎ)
- Play2でWebSocket使ってRedisのpub/sub使って負荷分散したシステム
- 社が昔から運営していたブログサービスの作り直し(会社の方針変更で途中で立ち消えた)
- とある基盤のシステムをgoで改善(あまりおおっぴらに書けない)
- 再利用性のある機能がとあるサービスに密結合していたりみたいなやつを分離してAPI化する仕事
- 会社のサービス基盤をAWSに移行する仕事
- ↑の上にswarm(≠swarm mode)とconsulとnginx(+consul template)と自作go製エージェントでDockerクラスタ作った仕事
- k8s調べてる(EKS発表されたし↑を移行したいねって話が出てそれで調べてる途中)
- バッチのキッカーをdigdagにした仕事
触ったことある技術
やっていきたい事
- コードを書く仕事に関わっていきたいなとは思っている
Lightbend Activatorテンプレートの作り方メモ
こんな感じ
activatorのサイトにアカウント作らにゃならんとかも無いしsbtプロジェクトでさえあればギッハブのURL送信するだけでいいのか、お手軽で良い。
具体的には
- activatorで適当な元テンプレから引っ張ってくるか、あるいは自前でsbtプロジェクトを作る
- プロジェクトルートにactivator.propertiesを置いてname、title、descriptionを書く
- nameはテンプレートのサイトのURLになるので気をつける
- プロジェクトをギッハブにpushする
- Get Started with Lightbend Technologies | Lightbend Tech Hub のフォームにリポジトリのロケーション(https)を貼る
- 待つ
- そのうちサイトが生成される
公開が完了したら、activator newした時のプロジェクトテンプレートから選べるようになります。便利ですね。
Dockerコンテナがstart出来なかったりRemoval In Progressってなって消せなかったりした時の対処法
最近ずっとDocker介助おじさんとなっていますこんにちは。
Docker、便利なんですけどつらいことも色々多い。
Dockerを運用していると、コンテナの再起動や削除時にコンテナのステータスがRemoval In Progressとなってコンテナを削除できなくなったりすることがちょいちょいあります。
こういう時は大体Dockerデーモン再起動しか無くて本当につらいのですが*1、再起動したらしたで、今度は止まったコンテナ立ち上げようとして下記みたいに言われてstartが失敗したりするわけです。
Error response from daemon: rpc error: code = 6 desc = "mkdir /run/containerd/{container id}: file exists"
こうなるともうコンテナ削除するしか無いですし、削除したら部署の皆さんに「コンテナ起動できなかったので再デプロイお願いします」って頼まなきゃいけないのでだるいのです。
で、今日もつらいつらいと言いながらいろいろガチャガチャやっていたらデーモン再起動無しに状況を切り抜けられたのでそのメモです。
ちなみにDockerは1.11です。
Removal In Progressとなって削除できないコンテナを削除する
ググると、 /var/lib/docker/container/{container id} 消せとか出てくるんですけど、僕の状況だと既にそんなディレクトリ無かったり、安全のためにデーモン止めてから作業しろとあったりして、いや止めたくないんじゃみたいな気持ちがあったのですが、そういう場合、当該コンテナが実行しているプログラム(CMDとかENTRYPOINTに指定されているやつ)を何とか探して
$ ps aux | grep {プログラム名}
でコンテナ内のプロセスを探します。
その親プロセスが多分
docker-containerd-shim {container id} /var/run/docker/libcontainerd/{container id} docker-runc
みたいなやつになっていると思うので、このコンテナIDを指定してdocker stopします。恐らくdocker ps -aしてもこのコンテナIDはいないと思うんですが、何か知らないですけど通ります。
多分何らかの原因でコンテナ(プロセス)の停止に失敗してリソース掴みっぱなしになってるとかで削除できなかったんでしょうね。
これで僕の環境だとRemoval In Progressが消えました。
startしようとするとエラーになるコンテナをstartする
エラーになるコンテナIDを控えておいて
$ ps aux | grep {container id}
でプロセスを探します。
そうすると多分上記と同じく
docker-containerd-shim {container id} /var/run/docker/libcontainerd/{container id} docker-runc
みたいなプロセスが出てくると思うんですが、今度はさっきと逆で、このプロセスの子プロセスをみます。
それがこのコンテナのCMDやらENTRYPOINTやらで指定したコンテナ内で動いてるPID 1だと思うんですが、そのPID 1と思われるプロセスをkillすると、そのプロセスと一緒に上記のdocker-containerdほげほげみたいなプロセスも一緒に死ぬとおもいます。
killしても死なない場合は kill -KILLで殺しますが、その場合、docker-containerdほげほげが残るのでそいつもkillします。
この状態で、さっきstartに失敗したコンテナを再度docker startすると起動に成功します。
これもきっとなんかしらの原因でプロセス殺すのに失敗してたんでしょうね…。
まとめ
社会は厳しいやっていくしか無い
おまけ
@kamekoopa Docker が不安定な原因として、StorageDriver として DeviceMapper を利用している場合が多いので、StorageDriver が DeviceMapper なら別のもの(overlayfs)を試してみるのも良いかもしれません。
2016-06-20 18:17:51 via TweetDeck to @kamekoopa
と言う話もあるんですが、overlayfsはinode食い潰すという問題があり、問題が改善されているoverlayfs2はDocker1.12以降かつカーネル4以上となっておりこちらも色々厳しい。CentOSのカーネルが4以上になるのはいつですかね…。
公式のDockerRegistryにオレオレ証明書入れてバックエンドをS3にしたらpushとかがうまくいかなかったメモ
大して量無いので経緯と結論だけ。
insecure-registryの設定なしにプライベートDockerRegistry使おうと思うと証明書発行して突っ込む必要ありますが、まさかプライベートレジストリで使うだけでちゃんとした証明書買うのもだるいので大体オレオレ証明書突っ込むと思います。
が、証明書作って
/etc/docker/cert.d/{registry host}/
に入れるとDockerデーモンがローカルに元々入っているルート証明書を使わなくなるので、DockerRegistryとの通信はできますが、逆に言うとDockerRegistryとしか通信できなくなり、バックエンドにS3使ってる場合「x509: certificate signed by unknown authority」とか言われてつらい。
解決方法はDockerプライベートリポジトリ(Docker Registry)構築レシピ | Developers.IOにある通り、ルート証明書へのシンボリックリンクを突っ込めばまぁ行ける。行けるけども…。
それならもう正直insecure-registryに指定したほうが楽じゃんみたいな世界となった。