こんばんは。この記事は生放送ではありません。

2017年もコミケで終わります。多分2010年ぐらいからコミケで終わっている気がします。 気になったのでコミケ遍歴を†封印の書†から過去を掘り返してみました。 初参加は忘れもしない2010年の冬コミ、C79でした。この時は1日目のみの参加だったようで、アニプレックスに並んで俺妹の桐乃セットを買ったのを覚えています。今もたまにTシャツ着てますね。

その次がなかなか記憶になくて、漁った所どうやら2012年の冬コミ(C83)らしい。夏コミとか行ってそうだったんですけど行ってなかったんですね。 そこからは毎回行っていて、C84に一度始発で行って轟沈してからは二度と始発では行かないぞと誓っています。

そこからは毎回ほぼ3日間参加していて、今回のC93で11回目の参加になるようです。

C90ではコミケにサークル参加したこともありますが、毎度スペースや誘導の変化を見ていると時代を感じたり感じなかったりします。 最初の頃は企業は西34だけでしたが、C90の前後では企業が2日間だけになり、3日目は西34がサークルになったりしました。そのときに自分のサークルが西34だったからです。

コミケは複数人で行くときのコミュニケーションが難しいなとしばしば思います。ファンネルとか言うらしいですね。僕はそういう規模で参加したことはないです。欲しいものは欲しいですが…… どうでもいいことを書くと、東1-3は外周が"A"で島が"B"~"サ", 東4-6は外周が"シ"で島が"ス"~"レ"、なんか多分前々回ぐらいからある東7は外周が"あ"で島が"い"~”の", 東8は壁が"も"で島が"ま"~"め"です。西34はなんかアルファベットでした。難しい。特に東78のひらがなは難しくて、音声コミュニケーションを破壊しに来ます。そもそも"シ"と"C"とか難しいんですが。それを言うと西もアルファベットで破壊しているんですが、西とか東とかをプレフィックスで言うので破滅しないことが多いです。 とにかく良いツールで解決していきたいがSlackはコネクションが貼れないことがしばしばあります。僕はこの3日間は大半がメールでした。偉大なそりゅーしょん。

さてどうでもいいことを書いていたら23:55らしく、爆速で統括をします。

今年の変化点は3月にシリコンバレーに行ったことで、とにかくそこで思考が変わって面白いなと思ったり、人間重視になりました。 あとは12月に就活の真似っ子をして破滅しました。もう何も信じたくないという気持ちがあります。

全然統括できていないですね、来年も色々動きがあると思うのでやっていきましょう。

皆様1年間お世話になりました。来年もどうかよろしくお願いいたします。

 

これは2017年最後のツイートです

http://twitter.com/sukukyon/status/947482473742528515

こんばんは。kyontan (就職活動中)です。 括弧書きをするとそれっぽいですね。

この記事は 12月24日 に公開される予定ですが、とりあえず色々思うところもありこの部分は 12/11 に書いています。多分どんどん加筆するので長くなるでしょう。 もし24日にこの記事が公開されていたら、それは、 whywaita Advent Calendar 2017 が24日目であり、25日目には whywaita が記事を書くということです。 おそらく誰も遅刻しておらず、無事にクリスマスが迎えられるのでしょう。多分 WHITE ALBUM2 をプレイするといい感じに心が折れていいと思います。僕は多分まだクリアしていません。

さて、記事のURLにもありますが絶賛就活中です。本当に?

自分史上最も性格の悪い文章だという自負があります。途中で奢っていたりマウンティングがあったりします。しかもそんな文章が10000文字以上あります。 気持ち悪いと思ったらすぐにブラウザバックを推奨します。ブラウザバックって最近見ないですがご存知ですか? (→出口)

キーワードは「承認欲求」です。企業よりは人に承認されたいですね。とりあえず Just Because! の10話を見てください。

ちなみにこの記事で述べている過程については全部具体名含めて色々とメモを取っており、このページ (関係者向け) に色々書いてあります。見たい人は入部してください。ところでこの記事は UEC Advent Calendar とは関係ありません。

最後までお読みいただければ大して真面目にやってないな / お前クソだな、ということは伝わると思います。 真面目に就活をしているかは怪しいですが、とはいえ雑にインターンをしてそのまま就職したり、いわゆるTwitter就職/VR転職なんかをする能力/気持ちもないのでそれっぽいフローを実行してみています。そんな話です。

つまるところ、逆求人を一度やってみたかった人間が逆求人をやったので各サービスの雑感を書いただけです。 どのように振る舞ったかというロールプレイングの一例があることにより、これを誰かが読んで活かして頂けたら面白いかなとも思うので書いています。

 

read more »

こんばんは、kyontanです。お金を溜めて早く温泉付き一戸建てで暮らしたい。

この記事は whywaita Advent Calendar 2017 の17日目の記事です。枠が埋まっていてめでたそう。whywaita 先輩、元気ですか?

お元気そうでなによりです。

16日目は jackaleさんの 最後にwhywaitaと会ったのいつだっけ... - That Can でした。TUATでは最近Crystalが流行っている気がします? (N=2) 僕もやっていきたいですね。

今は完全に頭が回っていないので雑な文章を書きます。@whywaita が時給の上げ方について話して、と言っていた気がするのでそういう話をします。

過去にもこんな記事がありましたし、もしかしたら @whywaita とお金は切っても切り離せない関係なのかもしれません。

私は現在技術系のアルバイトをしています。技術系のアルバイトの良いところは何でしょうか? そう、好きなことをして勉強ができる上に、お金ももらえるというところですね。接客業をやったことがないので偏見があります。郵便の仕分けは最適化していたら楽しかったですが今思うとディープラーニングでなんとかしてほしい気がします。

@whywaita 先輩がどこで働いているのかは定かではないのですが、私は今はインターネットの会社とインターネットの会社でアルバイトしています。掛け持ちです。インターネットってすごいですね。

その他にも退職エントリが2件あることから、今の会社がそれぞれ3社目と4社目になると推測できます。(この夏のインターンを足すと5社になります)

• バイトを辞めました

• バイトを辞めました (その2)

最近インターネットを眺めていた所、とある知り合いがある会社へ就職する、というインタビュー記事を見かけました。就職するというだけでインタビュー記事になるのはすごいなと思いますが、記事中では "4社でインターン/アルバイトをしていた**「ジョブホッパー」**"として紹介されていました。そう考えると、私もジョブホッパーなのかもしれません。個人的にはあまり良い言葉だとは思っていないですが……

時給の上げ方は自分でも良く分かっていないのですが、皆さんも思う所があると思うので、とりあえず晒します。

この図を見ると、色々やった形跡がありますね。しかも掛け持ちしていることが良く分かります。 (なんと凡例にない色のプロットがあり感動しますがよしなに読み取ってください。)上がる会社もあれば上がらない会社もあります。最近は1年以上額が上がっておらずちょっとつらいです。ちょっとだけ。

もちろん会社によって評価体系も様々ですが、アルバイトだとそもそも給与交渉の機会もなく、突然「契約書の更新だからサインしといてね」と言われることもしばしばです。

「上げてほしいな〜」という文脈の話を一言話しただけで上がったこともあります。そんな話を上司にするのは強気ですって? ええ、当時は立場的に強気でしたね。そりゃ突然辞めたら案件進まなくなるような仕事をバイトがやっていたんですから……

概して、時給を上げる(下げる)には、大きく「転職をする」と「給与交渉をする(上長に評価される)」の2つがあると思いますが、そのどちらもを経験した身としては、おそらくアルバイトでは転職した方が上がりやすいです。 特に、エンジニア職のアルバイトは東京では比較的募集している所も多く、引く手はあまただと思うので、うまくやるとトントン拍子に上がるのかもしれません。うまくやるのがポイントで、うまくやらないと上がりません。図からも明らかですね。

転職では人間関係をうまくやりましょう。僕は下手なので遺恨を残してしまいがちです。そんなのどうでもいいという考えもありますが、平和であることに越したことはありません。僕は最近どうにか和解しました。本当かな……

ちなみに筆者は今のところ転職する気はないです。書いておかないと深読みされそうで怖いですね。 お金も大事だけど本当に好きな働き方ができる上に恵まれている環境はなかなかないです……

また、今思うと、「言い値でいいよ」と言われたとある会社でもっと言っておくべきだったのかもしれません。そんな後悔もなきにしもあらずですが、当時は逆にあの額にプレッシャーを感じてしまい色々あったので、やはり難しいですね。正当に評価されていきたい。

ちなみに、周囲の話を聞く限りでは1500円/時以上の額はなかなか耳にしないのですが、それは月給換算すると分かりやすいですね。バリューを出している人たちがもっと貰っているのも聞いているので、バリューを出せると良いですね。

短くなってしまいましたが、僕は自分で作った図を眺めて心が荒んでしまったので許してください。

@whywaita 先輩はどんなお考えをお持ちですか? また機会があったらお話してくださいね。

明日は @yu_ki_kun_1 さんです。あれ、毎回 @yu_ki_kun_1 さんでは……?

 

こんばんは。kyontanです。JobHunting 活動は順調ではないので頭を抱えています。

寒いです。12月10日です。10日ということは、 whywaita Advent Calendar 2017 の10日目ということです。なんとあと1枠らしいです。

9日目は @kadokusei (~= @hyr3k) さんで 体重 - /var/log/ でした。

ところで文脈もなにもないですが Just Because! が良いです。小宮恵那さん……

さて先日、 Twitter を眺めていたところ 「真っ赤な“1/4Uサイズ”のブレードサーバーが税込4,980円で大量販売中」  という記事が流れていました。 Core i5-2520M@2.5GHz / RAM2G / Diskless という構成ですが、Intel の GbE NIC x4 があるなかなか変態なマシンです。5000円だったのでつい3台買いました。IPMI もあります。ちなみに1台当たりで RAM が 4GB でした。

kamijin_fanta さんという方がこれに VyOS on Hyper-V をやっている記事があるので、こちらもご参照ください。

赤鯖にVyos入れて最高のインターネッツを手に入れた

これは A.T.WORKS というメーカーの国産サーバで、謎です。とりあえずドキュメントとかファームウェアの更新は公式ストアのダウンロードページに転がっています。

何故かシャーシも付いてきたので適当に突っ込みます。10台入るので、あと7台追加できますね。とはいえ部屋の室温で冷却するにはこの程度の密度が限界かと……

画像の左下にある赤いやつがそれです。雑ですね。周りも汚いですね……

さて、ディスクレスとはいえ開けてみると SATAポートもディスクベイもあるので、2.5インチのHDDを買えば普通に使えるでしょう。 しかし先立つものがなく、しかし他のサーバは余っているのでネットワークブートさせて遊んでみることにしました。

PXE とは

PXE とは…… ざっくりと説明するとネットワークブートのための仕組みの1つです。 NIC に書き込まれたPXEブートローダが、ネットワーク上のサーバから OS のカーネルを取得して起動する方法です。

基本的には起動時に DHCP でIPアドレスを取得する際に、サーバが IPアドレス等の情報と一緒にカーネル等が置かれているサーバ(TFTPサーバ)のアドレスを返すことで実現されます。 いわゆる大量のPCを管理する手間を減らしたい(~ シンクライアント化したい) 大学なんかでよく見かけますね。MMA部室の端末でも同様の仕組みを採用しています。 もちろん一般的な誤家庭でも、DHCPサーバとTFTPサーバ等を立てれば実現できます。近年では PXE を発展させた iPXE などもあります。こちらだと例えばカーネルを通常の HTTPサーバから取得するようにできたりします。便利ですね。 実際の実現にあたっては、 「PXE 構築」なんかでググって頂ければ山のように日本語の資料がヒットしますので割愛します。

Container Linux

今回はこれを用いて CoreOS Container Linux を起動させ、自動的に Docker Swarm クラスタを構築したいという話をします。

Container Linux は CoreOS 社が開発している、コンテナ基盤のための軽量Linuxディストリビューションです。docker や etcd と言ったコンテナで用いるソフトウェアがデフォルトで入っているほか、fleet というクラスタマネージャ (というか分散 systemd) なんかがデフォルトで入っています。 CoreOS 社は他にも Docker Registry の Quay やコンテナランタイムである rkt や cloud-config の代替を狙っている Ignition, エンタープライズ向け Kubernetes こと Tectonic の開発なんかもしていますね。

もうお察しかと思いますが、 Container Linux には fleet というクラスタマネージャがあり、更に Tectonic があります。つまり、 Docker Swarm の文脈にはかすりもしません。イケイケな皆さんは Kubernetes を構築すると便利だと思います。 (実は Kubernetes クラスタを構築しようとしたらオンメモリファイルシステムでは容量が足りなかったので Docker Swarm でお茶を濁しています) CoreOS は今回のよう物理ホスト(ベアメタル)に対して直接プロビジョニングをするためのプロダクトも用意しています。 Matchbox です。使ってください。 今回は使いません。

起動してみる

CoreOS はもちろん PXE での起動に対応しており、簡潔なドキュメントがあります。 これに従えば簡単に起動までは行なえます。やってみましょう。

最終的なディレクトリ構造としては以下のようになります。 /tftpboot は適宜 tftp のルートディレクトリに読み替えてください。また、 pxelinux.cfg/default の内容は下に書いてあります。

/tftpboot
├── coreos
│   ├── coreos_production_pxe_image.cpio.gz
│   └── coreos_production_pxe.vmlinuz
├── pxelinux.0
└── pxelinux.cfg
    └── default

default coreos
prompt 1
timeout 15

display boot.msg

label coreos
menu default
kernel coreos/coreos_production_pxe.vmlinuz
initrd coreos/coreos_production_pxe_image.cpio.gz
append coreos.first_boot=1

さて、対象のマシンは起動したでしょうか? 手元では30秒ほど OS の読み込みに掛かったあと、OS本体が約4秒で起動してくるのが観測できました。速いです。

ただ、おそらくログインもできず、ssh もできないでしょう。直接本体に接続されている端末にログインしたい場合は、ドキュメントにある通り、 coreos.autologin を設定すれば可能です。

実際にもうこれで fleet で遊んだりできます。この状況では、 /(rootfs) がメモリ上にあるので、メモリの空き容量分しか書き込むことができませんが、メモリが潤沢にあればこの上に Tectonic や kubeadm を用いて Kubernetes を構築したりもできるでしょう。ちなみに 4GB では足りませんでした。

Docker Swarm

Docker swarm というのは Docker 本体に取り込まれたクラスタリングの機能です。複数のノードでサービスという単位でコンテナの管理が行えます。 Docker 本体に統合されているので、Container Linux に docker がデフォルトで入っているということはそのまま docker swarm mode で既存のクラスタに join させればそのままクラスタの一員となります。 クラスタにはマネージャとワーカの区別があり、マネージャは Raft アルゴリズムで分散合意を行うため、本来であれば耐障害性のためにも3以上の奇数台を用意することが望ましいですが、今回は DHCP/TFTPにしたサーバをそのまま使います。

# docker swarm init
Swarm initialized: current node (hogefuga) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-... 10.0.xxx.yyy:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

上で表示されているコマンドを起動時に入力させればそのまま docker swarm のクラスタにジョインしてくれるでしょう。やっていきましょう。 (ちなみに、デフォルトでは docker swarm のマネージャ自信もコンテナが起動するホストの1つとなります。次のコマンドを打てばそのノードではコンテナが起動しなくなります。 docker node update --availability drain)

Ignition Config

起動時に任意のコマンド等を実行する方法といえば、あの cloud-config がありますね…… Container Linux では最近 Ignition というものに置き換えられました。直接書いてもいいですが、 cloud-config の記法で書いたものは ct (config-transpiler) というコマンドを用いて変換することができます。 ちなみにオンラインのバリデータがあって、 どちらの記法でもここでバリデーションができます。

では用意しましょう。ついでに ssh できるように authorized_keys なんかも追加できます。 ssh したくない? 確かに。 ともかく systemd unit を2つ書くだけです。ところで docker-swarm-leave.service がちゃんと動いてない気がするのでどなたか教えてください。

passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ecdsa-sha2-nistp256 ...
systemd:
  units:
    - name: docker-swarm-join.service
      enabled: true
      contents: |
        [Unit]
        Description=Docker swarm join script
        Requires=docker.service
        After=docker.service

        [Service]
        Type=oneshot
        ExecStart=/usr/bin/docker swarm join --tokenSWMTKN-1-... 10.0.xxx.yyy:2377

        [Install]
        WantedBy=multi-user.target
    - name: docker-swarm-leave.service
      enabled: true
      contents: |
        [Unit]
        Description=Docker swarm leave script
        Before=shutdown.target reboot.target halt.target

        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/bin/true
        ExecStop=/usr/bin/docker swarm leave

        [Install]
        WantedBy=multi-user.target

 

さて、このファイルを実際に起動時に渡すためには ct で変換したり、 newc 形式のアーカイブにしたりする必要があるのでやります。

$ mkdir usr/share/oem
$ ct < container-linux.config > usr/share/oem/raw.ign
$ find usr | cpio -o -H newc -O oem.cpio
$ gzip oem.cpio

結果的にでてきた oem.cpio.gz を以下のような感じに配置します。

/tftpboot
├── coreos
│   ├── coreos_production_pxe_image.cpio.gz
│   ├── coreos_production_pxe.vmlinuz
│   └── oem.cpio.gz
├── pxelinux.0
└── pxelinux.cfg
    └── default

 

また、 pxelinux.cfg/default も修正します。は以下のようになります。 oem.cpio.gz を読ませているのと、実際にそれを参照させている部分の2箇所です。

 
default coreos
prompt 1
timeout 15

display boot.msg

label coreos
menu default
kernel coreos/coreos_production_pxe.vmlinuz
initrd coreos/coreos_production_pxe_image.cpio.gz,coreos/oem.cpio.gz
# append console=tty0 console=ttyS1 coreos.autologin=tty0
append coreos.first_boot=1 coreos.config.url=oem:///raw.ign

さて、起動させて見ましょう。マネージャ側で docker node ls とか叩けば分かると思います。 いい感じになりましたでしょうか?

あとは docker service コマンドでよしなにサービスを作ってやると、いい感じにロードバランスされたりヘルスチェックしたりライブアップデートできたりすると思います。 ポートの公開をすると、マネージャを含む全てのノードでそのポートが共有され、自動的にロードバランスされます。つまり、そのサービスのコンテナが動いていないノードにアクセスしても、内部のトンネル(VXLANです)を通ってコンテナへの疎通性が確保されます。

そのあたりは「docker swarm」とかでググると出ると思います。 nginx とかでも簡単にできますね。

ところでボリュームのマウントは癖があって、 bind なんかは各ノードのローカルファイルシステムを参照します。なので、そういったことをしたい時はよしなにやりましょう。 nfs とかを検証できると良いですね。

ちなみに再起動したりするとどんどん死んでるノードが一覧に増えますが気にしないでください。気になる時は docker node rm で消しましょう。以下がワンライナーです。

 
docker node ls | tail -n+2 | grep Down | cut -d' ' -f1 | xargs -r docker node rm"

さて、今回は簡単に Docker Swarm を用いたクラスタの構築をしてみましたが、実際により大きい規模でやろうとすると Kubernetes や DC/OS (Mesos, Marathon) なども候補に入るかと思います。 そちらについてもやっていきましょう。

ところで Docker / CoreOS をプロダクションでバリバリ使うサービスに興味のある方向けに、 こんな求人やこんな募集があります。もしご興味ありましたら Twitter 等でも良いのでお声掛けください。

では皆様、よいコンテナライフを!

こんにちは、kyontanです。執筆時点での現金資産は 38558円 です。

今年も12月がやってきました。この記事は whywaita Advent Calendar 2017 の3日目の記事です。まだ10枠空いていますが、 whywaita 先輩、元気ですか?

kyontan / whywaita (@whywaita) って誰? という方もおられるかもしれません。彼と私は単なる大学の先輩後輩というだけで、それ以上の関係はありません。 それ以上の関係はないと明記すると怪しくて良いですね。ありません。 2日目は村山直紀さんの 自然気胸の話とか(その2) でした。 自然気胸、周りに発症している人が何人かいて、割とよくあるのかなと思っています。僕自身は入院したことは1度しかありませんが、なるべく健康であるに越したことはありませんね。  

皆さんお金は好きですか? 僕は好きです。たくさんあると嬉しい気がします。ただ、今の立ち回りとしては、仕事に求める要件は給与が高いことではなく朝遅いことです。あと早く温泉が家から湧出してほしいです。

将来はウン千万プレイヤーでバリキャリでイケイケになるであろう、尊敬すべき whywaita 先輩に必須のスキルはなんでしょうか? そう、資産管理術ですね。 バリキャリという表現からはまどかのお母さんである詢子さんを想起させるものがありますね。 彼は資産管理をしているのでしょうか。確か MoneyForward を使っていた気がします Dr.Wallet を使っているみたいです! (2017-12-03 13:45 追記)。貯蓄の額は知りません。とにかく寿司をごちそうしてください。

僕は詳しくないのですが、とくに最近はﾌｨﾝﾃｯｸとかﾌﾞﾛｯｸﾁｪｲﾝ(これもﾌｨﾝﾃｯｸの文脈に入りますが)とかお金周りの技術進歩の話を目にすることも多いですね。家計簿サービスもその1つだと僕は思います。

私は資産管理に Dr.Wallet を使っています。家計簿アプリとしては他にも MoneyForward や Zaim がありますが、このアプリのイケているところはレシートをスマホで撮影して送信すると、店舗名やジャンル、額などを自動的に判定して登録してくれるところです。アプリもイケてて最高です。使いましょう。 (ただしディープラーニングでイケイケとかではなく、人力OCRみたいです…… 素直な解決方法ﾃﾞｽﾈ)

read more »

こんばんは。さっきサーバーの boot パーティションが飛びました。復旧したのでテストがてら、リハビリがてら。

去年もこの時期に 2016年11月あたりの今日このごろ | monolog なんて記事を書いていたので、Advent Calendar へ向けてリハビリをしていたのか、単純に人恋しい季節なのかどちらでしょうね。読み返してみて、こんなに駄文を錬成できるのはよっぽど暇だったんだな……と思っていますが、そういうこともあります。

手が滑って whywaita Advent Calendar 2017 - Adventar に4記事も書くことになりました。そもそも日頃からアウトプットをしていきたいところですが、こうやって自分を追い詰めていくことも大事ですね。頑張ります。

ここ9ヶ月ぐらいは安定した生活を送っている気がしますが、安定というのはつまり怠惰のきっかけでもあり、ちゃんとやっていかないと人がダメになります。なりました。

もう書くことが思い浮かばなかったので 2016年11月の〜 にあった小見出しを引っ張ってきました。これは行き過ぎると 100の質問になります。

その後

近況をあまりブログに書いていませんが、 Twitter で延々書いています。先週今週のタイムリーな話としては就活をしつつ研究室をしており、まだまだ再来年の4月以降どうなるかということについては予断を許さない状況にあります。

就活をしているのかと言われるとそれも怪しく、前々より単純に興味があった逆求人に登録して様子を見ています。お肉は食べられていないです。どうやら早い人だと今年の4月とかからもう登録して色々行っていたみたいですね。出遅れた……

まだ参加はしていないですが、いわゆる 1on1 形式のイベントに3回参加させて頂くことになっており、、正直それでお腹いっぱいになるでしょう。シークレットイベントが無限にあったり、テンプレ勧誘文と足元を見るような交通費サポート設定に既に若干疲弊しました。12月ごろにまとめて書きます。ただ、1つだけ言わせてもらうと、同い年の平均的な大学生というのは平日の昼間は暇なんですか???みたいな気持ちになり、無限に???となります。

特にITベンチャーに絞ってるわけでもなく、経団連非参加企業に絞っているわけでもないので、いつ終わるのかは分からないし無限に疲弊できてコスパがいいですね。

 

スクールライフでは、そろそろ研究室配属だということに先週気付かされました。研究室は今まで全く見ていなかったので、色々あるなと思いはじめています。

選ぶ条件は興味のある分野であったり、短い間でもレベルが高いことができるかであったり、教員とのマッチングであったり様々あると思います。一方で、自分はここに行くのかなと半ば決めつけかけていたところがあり、その他の選択肢も改めてみたところ色々あるなと思い出し、視野の狭さをあらためて再自覚しています。 スクールライフという表現をしても明るくなったり希望が満ちた感じにならないですね。 とはいえ、スクールライフにしろアルバイトにしろ将来にしろ、様々な選択肢があるというのは本当に恵まれているなと思っていますし、それを無碍にしないためにも精進しないとと思いつつ……

 

人間関係はダメです。どうやるの

アニメ

2017年夏季は NEW GAME!! しか見ていた記憶がありません。ありがとう動画工房、ありがとう……

2017年秋季は Just Because!, 少女終末旅行, 食戟のソーマ3期, お酒は夫婦になってから, ラブライブ!サンシャイン!!, 妹さえいればいい をひとまず見ています。必修みたいなアニメが多い。

特筆すべきはやはり Just Because! で、完全に地元なので見ながら頭を抱えたり目頭を押さえたりしています。そんな甘酸っぱい物語はなかった。

妹さえいればいい、妹です。

漫画雑誌

1年前に比べると、百合姫やコミックキューンを読まなくなりました。百合姫は月刊化してライト化しましたね。そして終わるだろうという予想はしていましたが、まんがタイムきららミラクが終わってしまいました。桜Trick 最終話は号泣しました。ありがとう桜Trick……

篤見唯子先生のスロウスタートが来年1月からアニメ化しますね。2016年11月の記事でも一押しと書いていましたが、今年5月にアニメ化が発表されました。最高です。各位見ましょう。どのキャラも最高で、イベントスチルが盛りだくさんです。最近は十倉栄子さんを見るたびに頭を抱えています。各位読んでください。

すわっぷ⇔すわっぷ も盛り上がって来ており威力の強まりを感じていて最高です。ストーリーはこちらも最高なので読んで欲しい。夏子ちゃんが好き。結構カラー率が高くてすごいなと思っており、ごちうさもそうですが単行本ではなく雑誌を読むモチベーションになります。

先日は ご注文はうさぎですか？ の OVAを観てきました。ごちうさに関しては原作至上主義ですが、アニメもよく、OVAも良かったです。アニメは特に音楽と声が好きで、水瀬いのりさん、カフェラテカフェモカカプチーノ、はい。 原作は輝きがどんどん増していてなんだこれは……状態ですが、ストーリーやそれを取り囲む世界観はもはや比肩するものはない良さがあります。まんがタイムきららMAXを買ってくださいというほかない。もふもふ天国。

技術周り

死んでいます。最近は頭の回らない Issue comment を書いてめっちゃ突っ込まれて土下座する日々を繰り返していて完全に無能感が出ている。同期にも怒られが発生していてしんどい。やるしかない。

とにかくなんでもできる同期含む周囲に囲まれて無能感が出ていてしんどい。自分にしかできないのはなんなんだというのがあり、まあそんなものは無いのですが優位性を微塵も見いだせないのでつらい。

あと突然データが飛ぶのが怖くなり突然HDDを3本購入して RAID-Z にして全部移動しました。冒頭で書いた boot パーティションが壊れたという話はこれにちょっと関連していますがデータ被害はないです。今まで何の冗長化もしないまま3TB近いHDDを4本ほど運用していたということからは目を逸らして生きていきたい。精神的安寧が訪れた。

上の話に続きますが、 RAID-Z はソフトウェアにしては意外とパフォーマンスは出ている印象があります。とはいえHDDの本来のピークの半分ぐらいです。あとは ZFS というとメモリバカ食いみたいな印象がありますが、 dedup を有効にしなければ大して消費していない気がします。 dedup は入れたらバカ食いした/書き込み速度が激落ちしたので切りました。もろもろまとめてそのうち記事にしたい。

あとはなぜかサーバが3台増えたのでやりました。Advent Calendar で書きます。

その他

Nintendo Switch を入手し、スプラトゥーン2を買い、ゼルダを買い、マリオオデッセイを買いましたが全くプレイできていません。直近30日でのプレイ時間は10時間以下です。なんのために買ったんだ。年が明けたらあおかなSwitchを買います。

あおかなEXTRA1、優勝です。ハッピーエンドを真白ちゃんと迎えに行きたい。迎えました。

また、もうすぐ WHITE ALBUM の季節がやってきます。

とにかく最近は逆求人というもので疲弊しているという印象を各所に与えていますが、実際そうなので各位疲弊しましょう。良いこともある、多分。 正直なところこの会社でこれをやりたいというのはないのでｱﾚだなと思うし、技術指向と主張するには技術ができないので頭を抱えている。人の生活が幸せになればいいと思います。

お酒は飲んでないし、最近は飲む暇がない。少し前に馬肉を食べました、良かったです。

 

とにかく消費も生産も追いつかず、心休まらない秋の夜です。秋の夜ぐらい月の明かりで読書をしたい。明日は温泉に行こうと思います。

 

♪ ハッピートゥモロー - 蒼の彼方のフォーリズム EXTRA1 VOCAL&SOUND COLLECTION - (有坂真白 (瀬良みと)) #NowPlaying

こんばんは。 最近色々あり、またあったのですが文章にしていなかったために物に残るものがない。

残していきたい/おきたいシリーズです。

Wantedly のサービス自体は比較的前(4年前?)から使っていましたが、まさかインターンに来ることになるとは当時は思ってもいませんでした。 やはり学部3年になると就活の時期ということになるわけで、スカウトを何件か頂いていたうちの1件で実際に人事の方と話させて頂いた上で決めました。

働き方、というよりはそのモチベーションを変えるというところで社会を変えようとしているというのが会社の考え(であると僕は認識しています)で、それは自分の考えとも一致するところがあり、技術的にもそこそこイケているのでは、というところが選択した理由になります。

参加したのは 9/5-22 の平日で、所用の休みを除いた12日でした。(業務委託契約なので実際にはインターンではない)

今夏はフロント/バックエンド/モバイル/機械学習みたいなコース分けがあり、とはいえ別に同じコースだからといって同じ日程であったり同じ人の下であるとは限らないという感じでした。日程も内容もある程度メンターと話し合って決めることができます。

面談で、最近のフロントエンド技術(React使ったSPAみたいなこと)には興味があるみたいな話をしたところ、なぜかバックエンドチームになり Rails を書いていた気がします。ずっとRubyばかり書いてますし、最近のアルバイトでは Rails でアプリケーションを書いていたので、そのあたりが考慮されたのでしょう。ちなみにこの話を当日したところ様々なアレがあり、最終的には最後の週にReact漬けになりました。React難しいね!

雑感

バックエンドというのはいわゆるサーバサイドのアプリケーションですが、私は Wantedly Visit という Wantedly の一番最初からある企業への訪問であったり、そのスカウトであったりというところの改善作業をしていました。 詳細は多分あまり書けないのですが、技術サイドでは BigQuery を初めて触ってクエリが実行されるごとに課金される様子を楽しんだり、そこから集計したデータを使ってごにょごにょしたりしていました。

ただ、やはり大規模 Rails というのはなかなか凄みがあって、様々な趣があり読んでいて面白いなと思いました。 そしてやはり社員の方の地力が強く、様々な点の技術判断というのはなかなかイケていると思っていました。僕が今回実装した部分についても、しっかりとデータに基づいた議論がありとても良かったです。あとは Ruby が好きなのが伝わってくるコードベースで個人的には良さみが深かったのも良かった。

最終週には前述したフロントエンドチームでも少しコードを書かせて頂き、本番へマージされたのはごく一部でしたがアイデアの PoC みたいなことをしていました。UX を良くするためにブラウザのレンダリングパフォーマンスと格闘する経験はなかったので、面白いなと思ったり。

その他

白金台MGビル、始めてきた時に強い既視感があり、Cookpad が昔ここにあったなあという気持ちになった。(フロアは違うらしい) 土地柄、やはり飯が高く1000円スタートみたいなところがあった。様々ある。

インターン期間中に上場があり、パーティーなどがありエモい雰囲気であった。

最近色々な記事がありましたが、残業しているインターンは確かに多いが別に定時に帰ろうが、それより早く帰っても何も言われない感じでした。そもそも業務委託契約なので業務時間も明記されていないし、ちゃんとやることをやればよい。そもそも残業しないと終わらないようなタスクを抱えるのはコミュニケーション/マネジメントの欠落では。 まあ、周りを見ているとこの内容でこの報酬かという気持ちにはなったりした。色々ありましたね。(ネガティブにもポジティブにも / 人事とも話した)

インターン生が多かったので色々話したりした。やはり2, 3社目としてこのインターンに来る人が多いのだなと再認識したりした。そしてやはり世界は狭い。

人事面談が毎週あったのも個人的に良かったポイントで、色々話したり聞いたりできたので、会社についてや、働くということについても色々聞けたのかな、と思う。

総括

新しい技術に触れるというよりは、どちらかというとアイデアで勝負したり、サービスを成長させるためにちゃんと数値を見ながらやる、みたいなところへ注力したインターンでした。 しかし、技術的にもある程度のレベルはしっかりと求められており、それに基づいたやっていきがありとても良かったなと言うのが感想です。 普段使っているサービスの裏側が見られるというのはやはり楽しいですね。

メンターの方との分かりややっていきもとてもあり、タイムリーなところではISUCON7 の予選も突破していたのを観測して、やはり強いなとあらためて思うなどした。

そんなこんなであっという間に過ぎた3週間でした。改めて、Visit のとある組織の皆様、メンターの方、人事の方、ありがとうございました!!!

チーム「まだチーム名で消耗してるの?」で同期3人 (自分 @kyontan, @hogas, @h-otter) 初参加で2日目でした。学生枠突破ならずでした。

Ruby実装で挑み、最終スコア 38605点@2017-10-22 20:59:30, ベストスコア: 67792点@2017-10-22 20:44:59 でした。 ベストスコアでは予選ラインは超えていたんだなあと思いますが、最終的には伸び悩んだチームも多いようで、結局落ち着くところに落ち着いたのかなと思います。

ソースコードは kyontan/isucon7_qual です。踏み台でやっていた影響でコミッタが僕に見えますが、だいたい僕ではない。

[caption id="attachment_1668" align="aligncenter" width="620"]

ISUCON7 予選での Score / LoadLevel の変化[/caption]

次回も参加したいなという気持ちになってきたので、ひとまずはやったことを記していきます。

実は僕と @hogas は ISUCON6 の夏期講習に出たことがありましたが、そのときには日程等もあり参加しておらずということで、今回が初参加に。 @h-otter というインフラにとても強い同期がいたことや、周囲でも参加する人間が何故か多く、とにかくやっていくしかないという流れに。

チーム名を決めるところで消耗/摩耗し、本番前日までSlackはほとんど流れておらず。前日夜になって僕とか @h-otter がぽちぽち参加記やチューニングできそうなところを貼っていく感じに。

最近、正午より前に起きると早起きしたと言い出す僕が時間に間に合っていたあたりで色々とミスっていたんですが、東京都内の某所で3人で集まってやっていました。

事前にやった

とりあえずグローバルIPを持つ作業用サーバを用意しておいた。Rubyは事前に入れておいて、開始後に MySQL  も入れてスタンドアロンで動くようにした。あとあと @hogas はここでずっと作業してたり、 @h-otter が Prometheus のサーバを立てたりしていた。便利

コードについては GitHub リポジトリを立てて、普通にブランチ切ってやっていた。便利

情報共有は対面だったので、コードスニペット貼れるしリアルタイムで最高な HackMD を例のごとく使っていた。ベンチマーカの結果を全部ペタペタ貼っていたら容量制限に引っかかり、2スレ目、3スレ目が誕生した。HackMDのタイトルは**「ISUCON7 まだチーム名で消耗してるの? 2スレ目」**でした。

やったこと

ミドルウェアより下は正直 @h-otter に丸投げしていたので、アプリケーションより上をぽちぽち見ていました。 インフラについては正直何をしたのかは全容を把握していないですが、初手で nginx や MySQL に基本のチューニングを突っ込み、Prometheus で延々と監視しながらPDCAを回していたっぽい。正しいインフラチューニングや……

言語は僕と @hogas が使い慣れている Ruby を選択しました。正直クエリ弄るぐらいでいいなら Go でもいいよねーって言っていましたが、慣れてるほうが便利でした。Sinatra の文字列には幼馴染のような安心感がある。

僕と @hogas はよしなにアプリケーションコードを読みながら色々した。以下は色々

erb を haml に置き換える / hamlit gem の導入

気持ち+2000点ぐらい

初期実装が erb で、erubis に置き換えるというのも一案ありましたが、行きの車内で「erubis hamlit 速度」などで検索した結果やっぱり hamlit かとなっており、ノータイムで haml に書き換えることを決断しました。 erb2haml とかあったね〜と @hogas と話しながらやってもらった。

以下様子です

http://twitter.com/sukukyon/status/922121692440182785 http://twitter.com/hogextend/status/922125423697305600

(erb2haml はコマンドラインツールとかではなく、Rails に追加する rake タスク群ということに気が付いた様子)

nginx <-> Puma を UNIXドメインソケットに

気持ち +2000点

定番です。HTTP 5000/tcp から UNIXドメインに変えた。

SQL のクエリ改善

気持ち+10000点ぐらい

これは定番ですね。SELECT のカラムを絞ったり (@hogas)、 LIMIT を付けたり (@hogas)、インデックスを張ったりした。N+1 は手を付けていましたが、コード変更に集中できなくて最終的に投げてしまった。悔しい

終了直前にソースコード眺めてたら statement.close を意図的に忘れていそうなコードが見つかり慌てて修正した。スコア上の変化は分からず。

画像を静的ファイルに書き出す

気持ち+15000点ぐらい

ユーザーのアバター画像が DB に blob で入っていたので、雑に Ruby のワンライナーで書き出して (ここまで @kyontan)、 nginx に try_files で食わせる (@h-otter) みたいなことをした。 既に話題になっていますが、最終的には Cache-control 的な問題でキャッシュヒット率が悪かったらしい。むむむ。

SHA1 を殺す (パスワード, アバター画像)

気持ち+2000点

パスワードのソルトを生成している random_string を見たときに、これは要らないのではと思ってしまったのが始まり。初期データのパスワードはハッシュ化されていたので、 id が1000より大きい user は全て平文パスワードを DB に突っ込んだりした。 (by @hogas) アバター画像は、ファイルの内容を SHA1 したものをファイル名に使用する実装になっていましたが、もしかしていけるのではと言いながらユーザIDをそのままファイル名にしたら通ってしまったのでそのままに。

Redis (最終的に入れず)

気持ち+2000点ぐらい(?)

画像をバイナリで入れるのはまあそうだね〜〜と言いながら、Redis に載せようとしていた。正直コードの変更は大したことがないのは分かっていたので実装はシュッとできたけれど、実際に動かしてみると意外とスコアに有意な差が出なかった。その後も永続化周りで少し足踏みしていたり、他の変更を見ていたために最終的に入れられなかった。残念

アプリケーションサーバ3台化

気持ち +3000点ぐらい

@h-otter がラスト30分でイケると言い出してやってた。ここで Puma (アプリケーションサーバ) のスレッド数を調整していた (10 -> 18スレッド)時に出したのがベストスコアです。

その他

• 再起動試験は何の問題もなかった???? 過去の参加記なんかを見てるとここが関門かなというのはあったので絶対やっておきたかった (やりました)

• Redis に手を出してなかったのでここで不安はあまりなかった

  MySQL の Too Many Connections が割りと頻発した

• ここは statement.close 忘れも影響してるかなと思うけれど、500が途中で出たり安定しないことがあった。最終的には安定しました

  日ごろは頭痛の頭の字もないのに、とにかく頭痛が酷かった。緊張にはやはり弱い。 JSONシリアライザが遅いのは分かっていて、 Oj を入れるぞと言いながら入れるのを忘れた。あれを入れただけでシリアライズについては数倍速くなるというのは分かっていたので、ただただつらい。 ICTトラブルシューティングコンテストでスコアサーバを延々とやっていたことが知見として生きたとは思う。DB設計なりアプリケーション設計なりチューニングなり。

• 当時のオーバーキルなチューニングしたときの操作が生きることになるとは思ってなかった

  最後のベンチマークの結果を見て全員で嘘やんって言ってた

• ルールを読んでなかった。次回は読みます

• にゃーん

そういえば30分ほどですがスコアボードの上位に乗っていました。学生トップなのは分かっていたので、これは予選突破できるんじゃない? とか言いながら笑っていたのを覚えています。このあたりが後々ボーダーになるんだろうな〜という話をしていて、実際そうなったのである程度読みは正しかったのかなと思いつつ。

総括/最高

監視に強い人(@h-otter)強い。常に横で IOバウンドかネットワークバウンドか、みたいなことを見ながらアドバイスしてもらえる環境は最高。

限られた時間の大会という環境でもくもくとコードいじれる人(@hogas)強い。とにかく僕が頭が回ってなくてコードをまともに書けない状況にあったので、そんな中でちゃんと改善する変更を入れ続けてくれて最高。

基本的にどこに手を入れればいいか、この変更はコスパ的にどうかみたいなことを常に考えながら立ち振る舞えてはいたと思うので、そういった点ではなかなか善戦はできたかなと思いつつ。 しかし、できたことは山のように残っているなという感想。、途中で集中力が切れてしまったこともあり、こういう結果になったのは悔しいなと思う。

ただ、これだけ言えるというのはつまりバランスが最高だということに他ならなくて、こういった駆け引きができるバランスのゲームを作るのはとにかく難しいなと思っているだけに最高だな！！！という気持ちです。 こんな最高のコンテストを生み出してくれた運営の皆様、ありがとうございました。そしてお疲れ様でした！

本選に行かれる皆様はぜひとも頑張ってほしいなと思うところです。

 

次回は最高の♨️から最高の心構えでやっていきたい。

 

 

こんばんは。

• 第6回 ICTトラブルシューティングコンテストの運営委員をしていました

• ICTSC7 の運営委員を務めました

に引き続きのエントリになります。ちなみに記事はないですが第5回でも運営委員を努めさせて頂いていたので、これで4回目になります。 後述しますが5回目はないので運営委員シリーズはこれで最後です。(そもそもシリーズものではないですが……)

偉そうになんやかんや語っているところだらけですが、あくまで主観だし間違いも色々あると思います。ただの記録や雑感として受け取って頂ければ幸いです。

read more »

こんばんは。現地時刻はJST 3:15ぐらいですが、最近はUTCで生きている気がします。そういえば21歳になりました。

さて、第50回 情報科学若手の会 (...) | 情報科学若手の会 というものがあります。 詳細はリンク先の説明に譲ります。

毎年この時期にやっていることは以前より知っていましたが、秋の花火を打ち上げる諸用と被っていたことが理由で参加できずにいました。 今年はかぶらないという事で、参加させて頂きました。

雑感

カジュアルではありながらも、少しでもアカデミックに若干寄ったイベントというのは初めてで、質疑応答の時間も長く、新鮮なイベントでした。

特に登壇者層は若手から若手(ではないが夢がある者)へと幅広く、話題もノンジャンルといって良いほどに幅広いものでした。ブロックチェーンやAIといった最近流行っているテーマから、人生戦略、ECMAScript, 研究支援, 地政学, 量子プログラミング, 考古学, オフィスを建てる, ... 様々ありました。

交流の時間も非常に長く、また幹事の方々が考えられた交流イベント(QRコードへ付箋を貼りつつ戦っていく、往年のバーコードバトラーのような何か)もとても盛り上がりました。ありがとうございました!!

また、ナイトセッションでは酒とエモい話が並び、大変にNSFWな感じで良かったです。

登壇した

そして、やはりイベントに出るからには登壇する必要があるようで、気がついたらショートセッションの枠へ登壇登録をしていました。しかも実際にはショートセッションを2つマージし @h-otter と合同で登壇するという暴挙にでていました。 内容としては、ICTトラブルシューティングコンテストの紹介と称してざっくり歴史をまとめつつ、自分たちが参加した会でのやったこと、辛かったこと、上手く行ったことなどを順に追っていく成長記録のような感じでした。2年間ですが、色々あったのかなあと思いつつ、やはりマネジメントは難しい。 ロングトークのマネジメントも難しいですね、精進します。

スライドはこちらです。HackMD (Reveal.js) なので一覧性が低く申し訳ないです :bow:

雑感その2

会場の Wi-Fi も非常に快適で、やはり Aironet は最高という気持ち。そのまま勢いで自宅の Aironet をギガビット対応させるべく電源を購入しました。

やはりこういう少し変わったイベントには少し変わった人が多く来るという(主観的な)偏見があり、実際そのように様々な人と話すことができました。しかしコミュニケーションは難しい、やっていきたい……

その他、次年度の幹事になるなどのイベントが発生しました。マネジメントつらいという話をするとマネジメントをする側になるのだなあとしみじみ思う次第です。どちらかというとオーガナイズよりな気がしますが、楽しんだもの勝ちなので全員で楽しんでいけるような会にしたい……!

やっていくぞ。

 

私信になりますが、もうすぐ就職か院進かというところで色々な悩みが発生したりしなかったりしています。 フィーリングでやっていきますが、もし何かお話等ありましたらご連絡いたしましたら幸いです。

こんにちは。これを書いているのは JST 4:30 ですが、最近は JST+0900で生きているので、昼間です。そろそろ夕方でしょうか。 最近の仕事の成果は Zabbix に投げ込む XML をエイヤで自動生成するような何か、もしくは SQL を生成する何かです。

成果物は kyontan/datadog-zabbix-history です。

長い前置き

ところで皆様は Datadog を使われていますでしょうか? インフラ監視系の SaaS やソフトウェアというと、今挙げた Datadog を始め, Mackerel や Zabbix, Nagios, AWS Cloudwatch 等々、現状では様々なプロダクトが存在しています。最近だと Datadog や Prometheus の名前をよく見かける気がします。

そんな中最近、自分のバイト先では使われているのが Datadog です。サーバの監視なんかだと、 Integration の種類も多く、デフォルトで様々なメトリックが取れることや、ダッシュボードの見やすさなどがイケているかなと。 特に SaaS だと、バッファリングがあるにしてもメトリクスの抜け落ちや一時アクセスできなくなる問題などはあり、クリティカルなものを全部載せるわけにもいかず、ただ SaaS の恩恵は受けたいというのが正直なところでしょう。 (mackerel-agent のログを眺めているとたまに何故か 404 が返ってきていて笑います)

ただ、設定が複雑化したり、そもそも設定数が多くて移行がダルいというのが正直なところです。エイヤでやる体力があれば良いですが、ホスト数が増え、監視項目が万の単位であるとそれはそれは……

おそらく皆さんは Zabbix のアイテムやらなんやらを XML で書き出してごにょごにょしたり、それを Prometheus の設定にいい感じに変換する何かを書いたりされているかと存じます。そしてそんなコードは短いから/特定のドメインに特化しているからと公開せず、誰もが誰かは書いているだろうと思いながら書いていることでしょう。そうですよね?

今回ご紹介するのはそんなあるあるプロダクトです。やることは記事のタイトルに書いてありますね。

本編

最初にも書きましたがこれ (kyontan/datadog-zabbix-history) です。実装としては、Zabbix の DB からメトリクス (Zabbix でいうアイテムのヒストリ) を勝手に拾ってきます。 いい感じに動きます。良かったですね。

現状イケてないところが1つあって、 dd-agent は独自の組み込み python を使うので pip で入れたパッケージを読んでくれません。インポートパスを弄ります。良くないですね。

まだ、とりあえず動くというところなので、様子を見ていきたいですね。

こんにちは。JST+11で生きているので昼です。 ところで最近は世界から10年遅れて Rails に入門したり、それとは関係なく Sinatra のアプリケーションに RSpec を書いてテストの重要性を感じながら七夕に笹の葉ラプソディを見たりしています。10年前って単語がよく聞かれる今日このごろです。

皆さんはおそらく何らかのチームでのコミュニケーションに Slack を使っていて、総資産を Dr.Wallet で管理されていて (ここで読者の8割が脱落)、その総資産を逐次仲間に共有したいですよね! (残存者0)

で、やっぱり皆さんも共有したいでしょう、というわけで作りました。

(実は1年ぐらい前に作ってあったのですが、環境依存が辛かったので Docker に押し込む作業をしました) GitHub kyontan/assets2slack 雑に docker-compose run --rm crawler とかやると共有できて便利です。

おそらく最近のアプリケーションなので docker-compose.yml が置いてあります。ポジショントーク?じゃないですが、こういう環境作りが面倒くさいアプリケーションの共有には向いていると思います。 1コンテナにまとめたかったのですが、少し面倒くさそうだったので投げました。PRお待ちしています。

実装は至極簡単に、 Ruby あるあるな capybara + selenium-webdriver で雑にクロールして Webhook で投げているだけです。技術に新規性はありません。

話が逸れますが、 Dr.Wallet のレシート人力OCRは精度も良いしおすすめです。あと、どうやら iOS より Android アプリの方が3倍ぐらい機能が充実していて便利です。NFC で Suica も読めるし。

皆さんもこれを使って総資産で殴り合っていきましょう。僕の総資産はたまにマイナスになります。

TL; DR

(某アドベントカレンダー120日目?の記事です。自己紹介を端的にするとインフラをやっているおそらく部署内で唯一の非内定者アルバイトです。)とにかく情報共有というのは難しくて、特に文脈を伝えるのが難しい。 現状自分はなんとかやっているが、アルバイトとかリモートとかそういう立場だと特に難しいなと感じているので思っていることを書いた。 大きく階層化Wikiと非階層化Wiki に分けられると思っていて、僕は階層化Wikiが好きだけれど、最終的には非階層化Wikiが勝つと思っている。

結論は出ていなくて、これは問題提起です。

以上

本文

こんにちは。記事を書いている今は2時です。

インターンでも内定者アルバイトでも正社員でも契約社員でもなく、自分の立場についても考えつつの kyontan です。

最近、コンテストの運営であったりバイトであったりと、何かと複数人で情報共有をする機会が多いです。 これが必要になるのは自明で、なぜなら1人でできることの幅が限られているからですね。 1人であればちょっとしたメモで事足りるようなことでも、複数人で共有するとなるとコンテキストが共有できなくなったりします。 (1人だからといって雑なメモで済ませると、それはそれで後々読み返した時にわからない問題が考えられますが、今回は考えません。関連はしていますが……)

このコンテキストの共有、というのが目下の自分が直面している最大の課題です。多くの情報にはコンテキストがついて回るのですが、なかなか重要性が理解されていないものでもあります。 コンテキスト、日本語で言うならば"文脈"であり、言うならば文章のバックグラウンドとでも言えばいいのでしょうか。事前に知っておくべき情報や、それを知るにあたり知っておくべき情報、というのがこれにあたるかと思います。

これらをどのように表現するか、というのが目下の大きな課題です。例えばプロダクトの開発であれば、ある実装に対して、たまたま開発者のスキルレベルが不足していてその実装になったのか、はたまた何らかの事情がありそのような実装になったのか、そしてその実装をする必要が"今"はあるのかどうか、などというのは実装上には現れない情報として表現されます。 プログラムであればこういったことはコメントやアノテーションで表現すべきですね。最近であれば正しくTDDが回っているような開発では、テストが通る限りどのようにリファクタリングをしても問題がないかもしれません。

しかし、それがプログラムの外の情報だったらどうでしょうか? たとえばビジネスやお金の話、コードでは書けないような交渉など、なんらかの事情があり今の形になっているにも関わらず、その理由が明文化されてないことが多いのではないでしょうか。 こういった状況で、かつ何も背景情報が伝わっていない人がその背景を理解している人に代わってその状況に対処することは難しいといえるでしょう。 もちろん、対面のコミュニケーションによってもしばしばこの問題は生じます。特に自分のような週に1, 2度しか業務に関われない立場では、タスクを割り振られるたびに、そのタスクの必要性を聞く必要が生じます。

チーム開発において、このようなことは多々存在し、これを上手く伝える方法を僕は模索し続けています。 そこで必要なのがドキュメントです。しかし、プログラムのソースのように何らかの書くべき場所が指定されていない、というのが大きな問題でもあります。

一般的にこのような状況で使われるツールは情報共有ツール(そのままですね)や、コラボレーションツールと呼ばれることが多いでしょう。領域によってはグループウェアと呼ばれることもありますね。 Wiki というのはドキュメントの1つの形態であり、どのような形であるべき、というのは定義されていない(と私は認識しています)が、それに関わる複数の人間が編集できる情報の保存場所として有用であると考えています。

Wiki を作るソフトウェアとして、日本では Pukiwiki や Mediawiki  (これは Wikipedia で使われていますね) などが有名かと存じます。最近では Crowi なんかがあり、自分はとても気に入っていて、冒頭で書いたコンテストの情報共有にはこれを導入して3回に渡り使い続けています。 他にも、あまり Wiki という呼び方はされていない気がしますが、 esa なんかはこの部類に入るでしょうか。 これらの Wiki の共通点として挙げられるのが、「情報に階層があることを前提としている」ということです。

これの共通点に着目し、対抗(?)として作られたのが Scrapbox でしょうか。実は使ったことがほとんどなくて、まだ言及するに至らないレベルなので明言は控えさせて頂きたいのですが、非階層型Wiki として出てきた印象があります。(参照: 階層整理型WiKiはスケールしない - 橋本商会 - Scrapbox) 似たような特徴を持っているものとしては Qiita (or Qiita:Team) なんかも近いでしょうか。 また、Kibela のような、Wiki(集団として共有すること) と Blog(個人の備忘録, ポエム) を分けて記録できるサービスも存在しますね。

では非階層型Wikiはどのように情報を結びつけるのか、という話になりますが、基本的にタグを元にしたページ間の N:N の結びつけをすることが多いです。 階層型であると、どうしても親ページ(ディレクトリ)に対する 1:N の結びつけになってしまうので、そういった点においてタグという仕組みが有利なのではないかと考えています。

人間の記憶自体は後者に近い有機的な繋がり方をしているとされていますが、実際にそれを情報として書き出す時に、どちらの方がやりやすいでしょうか。 私は Crowi を使っていると書いている通り、(個人的に)書き出しやすい、情報の見通しが効く(ツリーで構造を可視化でき、親情報を見通しやすい)という点で勝っていると考えています。 非階層化Wikiは、たしかにタグ付けをすることにより階層化Wikiに比べ有機的な情報の繋がりが作れると考えていますが、適切なタグ付け、および関連ページの表現方法においてまだまだ難があるのではないでしょうか、どうなのでしょうか…… ただ、最終的には人間の思考に近い形の保存形態が残っていくのでは、と思っています。こういった非階層型Wikiの動向にも目を離さず追っていけたらと思う次第です。

話が飛んでしまいましたが、結局、どのようにして我々はコンテキストを共有すべきでしょうか。 階層型Wikiの利点として、正しく階層化されたWikiであれば、該当のページに至るまでの階層にそのコンテキストが埋め込まれていると期待することができる点が挙げられます。 では、果たして非階層化Wikiではどのようになるのでしょうか? 実際に自分が体験をしたことがないのですが、適切なタグ付けがされていれば、関連したタグのページを数ページ辿ることにより、階層化Wikiと同様の情報が得られるでしょう。 また、関連したページから関連したページにもジャンプすることができるでしょう。 ここで難しいのは、階層化Wikiにおける適切な階層化と、非階層化Wikiにおける適切なタグ付けがどちらも属人化した能力であることです。 これは何もWikiに限った問題ではありません。Slack や Chatworkといったチャットツールにおいても同様の問題があります。皆さんは適切な粒度でチャンネルを分けることができているでしょうか? その適切なチャンネル以外でそれに関連した情報は流れていないでしょうか? リモートワークにてもしばしばこのような問題は生じます。最近は特に一部のメンバーがリモートな場合にどうやって情報を共有するか、テンションや気持ちを共有するか、という点に注目したブログ記事が多く散見されます。

この問題が解決しない限り、情報共有が難しいという認識を私は崩すことができませんし、解決すべきテーマであると感じています。 これらが技術の進歩によるアシスト、ないし人間のこれらの問題に対する理解によってより良い方向になることを願います。(もちろん願うだけではダメなので、やっていくしかないんですが。)

途中で日本酒を3合ほど入れた結果文体が崩れ、主語が大きくなり問題も大きくなりました。実際問題は大きいので、各自認識してやっていきましょう。

こんにちは。

ICTトラブルシューティングコンテスト という学生が主体となってインフラやサーバに関するトラブルを起こして、学生が解決する(雑) な大会がありまして、その第7回、通称 ICTSC7 の運営側として参加してきました。

ちなみに、この前説は以前書いた記事からコピーしたものを数字だけ変えただけです。

実際に大会の本選が行われたのが 2017/3/4, 5 (土日) でしたから、もう2週間が経ったわけです。忘れないうちに書き残して置こうと思います。

今回もフォトレポートを始め、参加者や運営委員の方々がレポートを上げてくださっているので、そちらもご参照ください。

NTT東日本杯 ICTSC7 レポートまとめ

さて、改善点が多かったかと思えば最終的には反省点の山になり、上でリンクした記事を読み返したところ陰鬱な気持ちになった前回という大会がありました。それを元にして、今回はどうやって動いたんだお前という話です。

ちなみに活動期間ですが、2016/10/1 に運営委員結成開始, 2016/10/29, 30 にキックオフ合宿, 2017/2/18 より HotStage開始, 2017/3/4, 5 が本選でした。キックオフから数えて、4ヶ月に渡り活動していたことになります。

役割

今回、私はインフラリーダーとして、リーダー, 副リーダーの下にいる3つのリーダー職 (インフラリーダー, 問題リーダー, イベントサポート) の1つを勤めさせて頂きました。 改めてこれらの役割をまとめてみます。

リーダー, 副リーダー: 全運営委員 (今回は22名, ちなみに前回は16名) の指揮をする。また、機材折衝であったりイベント全体に関わる様々な部分において、実行委員(大人側)と調整を行う。 問題リーダー: 運営委員によって作問された問題の品質を保証するのが目的。スケジュール管理や問題のバランス調整が主な役割ですが、今回はシナリオ作成も行ってくれました。 イベントサポート: おそらく機能したのは今回が初。リーダーが今まで全てを担っていた機材折衝や管理の大部分を受け持ち、その他会場側との調整や、当日の段取りなど、実行委員側にお任せしていた内容を学生側でできる限り受け持つという目的のもと、それを主導する立場。 インフラリーダー: 問題を出題する基盤となる、会場ネットワークの L1 ~ L7 を設計/実装し運営委員および参加者に提供する、インフラ担当の運営委員のトップ。

各役割は確か運営委員が結成して1, 2週間ぐらいで立候補形式で決定した記憶があります。 あと、副リーダーが役職上しか存在していなかったという噂を聞きました。そういうこともあります。 忙しさの順序で言うと、問題リーダー>イベントサポート>=リーダー>=インフラリーダー ぐらいになるんじゃないでしょうか。あくまで今回の僕からみた主観的な感想です。ピーク値で言うと本選直前のイベントサポートが一番忙しそう。

やったこと

そんな中、自分が今回何をしたかを書いていきいます。 端的にいうと、前回は副リーダーとして色々やり、やらかしましたが、それでも僕は前回の基本的な方針は間違えていないという信念を持ち、できる限り近い方針で運用をしつつ、それでいて自分でほとんどタスクを持たないようにしました。

情報のやりとり

インフラリーダーがやることなのか分からないですが、やりました。 前回は Slack, Crowi (Wiki), Trello (ToDo管理), Google Drive (ドキュメント管理) の4つを主に使用していたはずですが、Trello を結局うまく使えず最新の情報が抜けまくってたのでやめました。 つまり、Slack, Crowi (Wiki), Google Drive の 3つで運用しました。

例のごとく Slack は最高のチャットツールですが、ちゃんとチャンネル戦略を練らないと一瞬で破綻するのでちゃんとやります。 具体的には左にあるはずの画像のような感じです。プレフィックスを良い感じにつけて、適度にサブチャンネルを付けると良い感じになります。(例: #infra 単体にしてしまうとサーバやネットワークといった異なる話題がごちゃ混ぜになってしまうので、 #infra-server, #infra-network を作るなど) 今回は問題のチャンネル #problem-xxx を作り、その中で各自が検証の進捗を書くようにしたのが新しかったでしょうか。あと、前回は HotStage (本選2週間から東京へ運営委員が集まり、インフラやらなんやらの直前準備を行う機関) に #hotstage-XXX チャンネルを色々作っていたのですが、既存のチャンネルとの差別化ができなくて混乱したのでやめました。 最終的なチャンネル数は 73チャンネル (うち分報15チャンネル, 問題個別21チャンネル) でした。メッセージ数は約47100メッセージ, うち59%が Public Channel でした。(前回は約48900メッセージ, 67%)

Crowi は最高の Wiki だと思います。ちょうど ICTSC7 が始まる前に 階層化 or 非階層化論争が再び起こり、Scrapbox も最近流行っているのかな、という感じはします。ただ、前回運用した知見があることに加え、前回の100ページを超える知見が溜まっていることは大きな利点だと感じ、前回の Wiki を継続して使用しました。 Wiki 自体は前回の運営委員がアクセスするものとは異なるものを同じデータをクローンして作り、 /ictsc7 という階層を切っただけです。 今回だけで新たに 144ページが作成されました。これは個人的にはとても驚いていて、前回は全体の147ページの半分以上を自分が書いていたはずですが、今回は自分が書いたのはたかが10ページ程度だったので、そこまでページがあったとは思わなかったからで。 今回は大人も含め積極的に Wiki にまとめるということをしてくれていた気がします。 ただ、まだまだこの運用, Wikiには改善すべき点があると思っているので、どうにか模索したいところです。 (例えば各ディレクトリ以下の情報をうまく収集して表にできたりすると、一々2つのページを手で更新しなくてよくて便利、など)

Google Drive は言わずもがなですね。基本的に Docs, Slides は使用しないので、 Sheets ばかりを乱用します。 IPアドレス一覧であったりネットワークの管理はやはりスキーマがある方が圧倒的に便利ですし、Markdown の表はめっちゃ使いづらいので、やはりリアルタイム同期ができて実質 Excel な Sheets は最高です。Conditional Format を使うと割りと楽に綺麗にできるのも評価すべきところ。 今回は1つのドキュメントにIPアドレスからVLAN設計からなにまで全部を詰め込みました。(今回は使っていませんが)シート間参照ができることと、別の内容を開きたい時にドキュメントを開き直さなくて良いのがメリットですね。ドキュメントを開き直さなくていいの、自明でしょという感じはしますが、Google Sheets の読み込みは結構重くてなんだかんだ10秒ぐらい奪われるのでシート切り替え1秒なんかで済むのは結構大きい気がします。逆にまとめることによるデメリットも今回だとないのかなと。

あとは、恒常的には使っていませんが HackMD はそこそこ使っていました。ミーティングの議事録なんかはこれで取るとリアルタイム同期されるのもあって便利です。

ちなみに、情報のやりとりがスムーズにできるとだいたいのことは良い感じに行く気がします。でもモチベーションの維持が大変ですが……

インフラ

インフラリーダーとして何をやったかというと、基本的になにもしていません。 インフラリーダーがそれでいいのか良く分からないんですが、今回の運営委員はインフラに強そうな人がたくさん居たので、多分任せたら良い感じにいくんだろうなって思いました。 おそらく僕がすべきだったのは進捗確認だったので、進捗確認と次にやるタスクの明確化だけは常に行いました。ミーティングについても、全体でのミーティングが月1程度だったのに対し、インフラ担当の中ではその倍の頻度である2週に1度の頻度で行いました。(週1開催という目標は達成できませんでしたが……) あとは一部機材折衝をしましたが、実際僕がやったのはここまでなので、実際にどういうことを運営委員全体としてしたのかをつらつら書きます。

ちなみに大会ネットワークというのは結構自由なもので、スター型であろうがフルメッシュであろうがリング型であろうが、気合さえあればやることができます。コンテストのルールすら自由に変えられますからね。

ちなみに前回 (ICTSC6) の HotStage 末期には、テンションが壊れた運営委員が「次回はオールSDN, オールIPv6, オールBGPでやるぞ」などと叫びこんなホワイトボードを書き残していましたが、知られていません。消したら消えました。当たり前ですね。

さて、今回は SDN やってみようぜ! というテンションの元、いくつかの SDN 技術の検証なんかを最初の2ヶ月ほどを使ってやっていました。具体的には Midonet, OpenFlow, QinQ (これはSDNではない) なんかを検証し、どうにか取り入れられないかと試していました。結局色々な制約があってだいたいなくなったんですが、実は OpenFlow は競技ネットワークの片隅で動いていたりしました。参加者の皆さん、ご存知でしたか? ラックの上部にハードウェア OpenFlow スイッチがマウントされていたことに気が付いた方は何名いたのでしょうか。でも実際に OpenFlow が動いていたのはそれではなく、下から3番目にマウントされていたラックサーバです。すみません。

競技ネットワークには、プロビジョニングを簡単にするという目的のため、各チームのVMがそれぞれ同じIPアドレス, ネットワークアドレスを持つ設計になっていました。つまり、同じネットワークアドレスを持つネットワークが15個 (=チーム数) 存在していました。運営ネットワークからこれらのVMを区別してアクセスするため、VLAN ID を利用してIPアドレスを書き換える不思議なNATが前回に引き続き今回も存在しました。前回はこのNATの実装として、Linux の netfilter に適用するカーネルモジュールが書かれていましたが、今回はこれを OpenFlow を使った Open vSwitch での実装に置き換えました。コントローラーは Python の ryu でした。

話が飛びましたが、ネットワークの設計について、最終的には ICTSC6 の基本設計を踏襲しつつ、実装する技術の選定からはゼロベースで行う方針になりました。基本設計は基本的に毎回ゼロベースでやっても同じ結論に帰結することが多いので、そこの手間を省き実装に時間を割いたということになります。

実装がどう違うかというと、例えば前回使っていた Apache CloudStack が OpenStack Newton に変わる程度の変化がありました。これは大きな変化で、途中 Horizon というコンポーネントがなかったことにされる程度の些事はありましたが、期間全体を通して安定動作し、再構築も容易な OpenStack はやはり良かった気がします。(前々回も OpenStack でしたね。ちなみに前々回使ったときは諸事情あり Neutron が使えませんでしたが、今回は使えました。時代の進化を感じます) その他、過去2回に渡りインフラの都合で出題できていなかった IPv6 にまつわる問題を出題するため、コアネットワークに IPv6 を割り当てました。OpenStack の VM には必要性がなかった(+やはり不安があった)ため割り当てませんでしたが、Ocata では IPv6 Full Support らしいので、次回こそはあるかもしれませんね。また、これに伴い、対外接続を提供頂いた Home NOC Operator 様には グローバルIPv6 アドレスの割当を頂きました。ありがとうございました。

また、会場で提供している無線LANから問題VMの提供されているネットワークへの疎通性を持たせたりもしました。少なくとも僕の知るICTSCである限りの直近3回でこれができたのは今回だけです。それに伴い、802.1X で良い感じに認証してそれぞれのチーム, 運営のVLANへ繋がるようになっていました。 802.1X にすることで、参加者がLinux マシンを持ってきたら繋がらないのでは? という懸念がありましたが、幸い Linux マシンを持ち込んだ参加者は Network Manager で無事接続できたようです。ちなみに FreeBSD なノートPCでも繋がったらしいです。 ただ、残念ながら、Network Manager の入っていない Arch Linux を使っているとある運営委員の ThinkPad では繋がらなかったらしいです。

そういえば DNS の構築は僕がやりました。今回は NSD をコンテンツサーバとして、Unbound をキャッシュサーバにしてやったみたいです。ゾーンファイルなんかは自動生成で適当にやるようにしたりもしました。ドメインがあるのは結構便利で、作業効率が若干上がった気がしますし早めに導入しておくと良さそうですね。 え、Unbound + NSD は TAB問題だって? そりゃ DNS構築したときにハマったものを問題にしたんだからそりゃそうです。HotStage にねじ込んだらどこかの会社の1問目になっていてびっくりしました。 ちなみに解答としては、SELinux を無効にする (or 有効にした状態で 10053/UDP を NSD が Listen できるようにする)、iptables で 53/TCP, UDP を許可する、 unbound.conf へ insecure-domain を追加する、nsd.conf の 172.16.0.0/16 がミスタイプであることに気が付き、 172.16.0.0/12 に直すで満点です。文脈がわからないと何も分からないですね。 ちなみに半分ぐらいのチームが解いたみたいで、半分のチームは2問目以降へ進めなかったということになりますが、上の通り初歩的なミスを連続でやらかしているだけなので、頑張りましょう。

問題といえば、KYF問題は面白かったですね。これは僕がキックオフで酒を飲んでした発言を本当に実現されたもので、WoLパケットを送るとVMが起動するっていう、何が起きてるのか分からない問題です。実際にはネットワーク上に隠しVMが居てパケットをキャプチャしていて、WoLパケットを拾うと OpenStack Nova API を叩いて VM を起動しているんですが、ここまで説明しても凄いのか良くわからないですね。でもその実装力はすごいと思います。

また話が逸れましたが、競技用ネットワーク全体でBGPルーティングされたりもしたみたいですよ。

ところで、ここまでを振り返ってみて、何かに気が付かないでしょうか。

今回のネットワークにおいて、IPv6 はコアネットワークと参加者の手元に到達性があり、OpenFlow が組み込まれ、BGPが周り、そしてRadius認証のある無線LANが提供されました。つまり、夢はだいたい叶ったということです。 実際、前回こんなことを言っていたときには、こんなの叶うわけがないというニュアンスで笑いながら言っていましたし、そもそもこの話は今回の運営ではしていないので、本当に偶然なのですが。

結局、大会のインフラというのは合理性を取ると本当に何もなくなってしまうので、できる限り参加者に楽しんでもらえるように面白い要素を詰め込みつつ、いかに無駄な作業を省き、いかに面白い技術を取り入れ、そして安定したネットワークを参加者へ提供するかというところに向かっていくのが理想だと思います。そういった意味で、今回のコンテストはルールの面を始めとして参加者へ面白いものを提供し、インフラは結構面白いことができ、そこそこ自動化され、ちゃんと安定していたので良かったのではないかと。

次回はどうなるのか楽しみですね

コンテストサイト

今回もやりました。

アンケートを見る限り概ね好評だったようで、良かったです。初日の朝のミスは頭が真っ白になりましたが、git push してなかっただけでした。 基本的に前回起きたパフォーマンス系の問題 (真面目にRESTしすぎてDoSになった問題) を解決しつつ、今回のルール変更へ対応し……というのを真面目にやりました。具体的にはスコアボードを実装したり、問題の公開条件を変更(時間による条件を廃止し、問題を解く度に次の問題が公開されるようになった)、みたいなところを修正しています。 その他、真面目に SQL を勉強して ActiveRecord に泣かされたり、前回参加者に怒られたのがトラウマになったのでパフォーマンスチューニングをそこそこ真面目にやって5台の物理サーバを使い60物理コア, 120スレッドの環境で分散させたりした結果、Sinatra アプリケーションにもかかわらずエンドポイントによっては 1000req/s を優に超えたり (30~10000req/s) しましたが、実際には20req/s を超えることはほとんどありませんでした。ちゃんと負荷を見据えてエンドポイントを設計しなおしたのが功を奏したので、良かったです。 あとちゃんとリクエストやら負荷やらを Zabbix + Grafana 可視化したりしてくれてました。

懺悔になりますが、前回に引き続いてデザインとフロントエンドを実行委員の方へ丸投げお願いする形になりました。また直前で負荷を掛けさせてしまい、すみませんでした……。フロントエンドが Angular2 から Vue2 に変わったのは何かの陰謀です。

ドキュメンテーションとリファクタリングとテストコードはこれからやります……。

まとめ

こんな感じで、僕は前回と同じでコンテストサイトの開発に没頭していたICTSCでした。 全体としてもトラブルなく終わったと思っていますし、成功に終わったと言って良いでしょう。

まだまだやるべきこと、改善すべきことはありますが、ひとまずここまで。

ここに来るまでご尽力くださった、ICTSC7 のスポンサーの皆様、実行委員の皆様、そして支えて下さった運営委員の皆様へ感謝します。ありがとうございました。

10月にも似たような記事を書いた気がしましたが、似たような話です。

記事の間隔を見ると3ヶ月で辞めたように見えますが、今回やめた会社の方が圧倒的に居た期間は長かったです。(約2年) 掛け持ちをしていると、「弊社」という発言の真意が取りづらくなってややこしいですね。

スケジュール感

2016/秋頃: 辞めたくなる (後述) 2016/12/12: 直属の上司に辞める旨を伝える 2016/12/xx: 取締役に辞める旨を伝える 2016/1/30: 最終出社日 2016/1/31: 退職

前提

ちなみにどういう会社かというと、都内にあって、受託メインで、ゲームやアプリ開発なんかもやっている、至って普通(?)のIT企業です。研究所系の案件が多かったのが特徴的でしょうか。(Webサイトに書いてあるので公開情報) 社員数は20名程度で、毎年、原則として社員の平均年齢がインクリメントされます。 n次請け案件はあまりなくて、基本的に1次, 2次程度の案件が多数, フレックスタイムが 12:00 - 15:00 なところは珍しいでしょうか。

働き始めたのは、高校3年生の春 (3月) でした。3月というのはつまり卒業直前ですね。そこまでスキルがなかった自分を雇ってくれるところは他になかったでしょうから、ありがたいと思っています。

入ってからは、どこぞの iOSアプリをコードベースで0から書いたり、OpenGL ES でシェーダーをごりごりしながら OpenGL 1.0 のソフトウェアを iOS へ移植したり、Java の炎上案件の火消しを手伝ったり、CUDA のコード書いたり、C++ x OpenGL なソフトウェア開発やら高速化やら、2万行の jQuery と格闘しながらフロントエンドの改修・機能追加なんかをしたりしました。 退職直前の作業PCは Xeon E5 x2CPU でRAMが 64GB で GeForce GTX1080 の 2枚刺しでした。はやかったです。 設計はあまりしていないので、純粋にプログラマーだった気がします。しかし自分が書いたコードがそのまま仕様になったことは数知れず、うーん…… あと、受託とはいえ、2年間の業務の9割近くは 1つの iOS アプリの開発・改修をしていました。なので辞めた理由もこれに大きく影響しています。Now Available on App Store for Freeですので是非ダウンロードしてください。何とは言いませんが。

辞めた理由

自分の仕事に対して、貰える額が見合っていないと感じるようになったからというのが最大の理由です。

自分は開発経験もほとんどありませんでしたし、その勉強時間は業務時間内に頂けました。 しかし、勉強をして、その結果としてコードを書いたとして、それがどんなに稚拙であっても動いていればよく、レビューされることは全くと言っていいほど無いわけです。 これは受託ならではの特性だと思っていて、瑕疵責任はあるにせよ、見た感じバグなく動いていれば、中身はどうでもよく、納品すればそれっきりだからというのが大きいのではないかと思います。

特に、 iOS なんかは社員の人ですら経験者がほぼ0でしたので、むしろ社員の人が自分の書いたコードを元にコードを書くようなことがありました。 結局、数万行(これが多いのか少ないのかは判断に困るところですが)のコードをほぼ1人で書いて、しかも納品してそれっきりではなく、その後の退職直前までの改修をほぼ1人でこなしました。 (ちなみに愚痴を言うと Objective-C で iOS 7 サポート, 著作者表記必須ライブラリ使用禁止縛りです。つらかった……) もちろん自分が書いたコードが完璧だとは全く思わないわけで、むしろ自分のような初心者が書いたコードなんてクソですから、ちゃんとレビューをされたいし、効率の良い書き方を知りたいわけですが、そのような機会に恵まれることはついぞなく、延々と master へ svn push し続ける日々が続いていました。 まあでも、当時はそんなものかと思っていました。

危機感を持ち始めたのは昨夏。 自分が試験期間なのでバイトを休み、1ヶ月後に再び来たある日、リポジトリには iOS ができる派遣の人が来て実装がされた形跡がありました。社員の人はコード書かないんかい……ちなみにその方が書かれたコードは命名規則がシステムハンガリアンで、最上位階層の ViewController にガンガンクラスメソッドが追加されていました。感動して涙が出ました。~~結局あとでだいたい消した。

~~きっかけは、そのときの派遣の人月単価と、案件の人月単価を知ってしまったとき。

自分の月50時間に満たない作業分が、n人月 = x万円、なるほど。それと同程度の工数見積の機能実装に関する派遣の方の人月がx万円? なるほどなるほど。 もちろん設計や保守の工数、会社の利益があるとはいえ、分かりが芽生えた瞬間でした。

決め手になったのは、辞めるという話をする少し前。

次の改修の納期も近いし、流石に人が足りなさそうだから人を足そう、ということで新人の方がプロジェクトに加わりました。もちろん iOS ができる人はいないので、僕が教えることに。 1年半以上 iOS をやっているとは言え、完全に独学で、バイトで、教育係(?) うんうん、教えるのもバイトの役割ですね! え、アプリの画像素材を複数倍率でPSDから切り出せるのは僕しかいない? 引き継ぎ用の手順を動画に? なるほど!! (ただの Photoshop CC の Generator ですね。イケてる機能だと思います。あと、僕はこれが普通だと思っていたんですが、通常の案件では切り出された状態の png で送られてくるということを知ったのは最終出社日でした。)  

後のことはいいから、辞めようと思いました。

 

時給を上げる交渉をする、という手がなかったわけではありません。実際、過去に一度実行しました(その日のうちに100円上がった)し、それ以外でもある程度は評価されていて、数ヶ月に一度時給の見直しはありました。 おそらく、一度に100円時給が上がるバイトなんて他業種ではそうないでしょうし、最終的にもらっていた時給も僕の知る範囲では高い部類でした。 (そもそも学生のエンジニアバイトの時給が安い問題はありますが、そこまで踏み込む気はありません。あくまで個人の主観としてです。)

それでも、僕は学生の時間を削ってバイトするからには学びが多くあって欲しいと願っていました。 2017年にもなって iOS 7 をサポートするのはわずか数%残存しているユーザーのためです。(使い続けるのはクソだと思っていますが) ただ、それを僕がやる必要があるのか、今やるべきことなのか、という点において大きな疑問がありました。 (もちろん、iOS 7 の話は色々ある話の1つに過ぎませんし、iOS 7 については、冗談抜きで10回以上はデータ込みでもうサポートやめましょうよ、と説得を試みました。受託なのでやめられませんでした。◯◯◯許さん)

自分が投資の対象ではなく人月として見られてしまうのは自分の落ち度でもあります。ただ、そうでなくても今の環境でそれを改善するのは難しいと考えました。

~~そんなこんなで精神がつらくなったので、労基法ギリギリの2週間前 (納期x週間前) に伝えてやめようかとも少し思いました。~~ただ、流石にそこまでのうらみつらみは無かったので、その後すぐに上記のような理由をまろやかにしたものと共に退職のお気持ちを表明し、1/31 をもって退職しました。 ちなみに退職のお気持ちを表明した後の1ヶ月間、主業務が新人社員の方への引き継ぎになりました。不思議ですね。

エンジニアバイト四方山話は色々あって、残業代が出るのでうちはすごい! みたいな話はたまに聞きますが、有給がもらえて普通に使えたり、賞与が出る会社はそうそうないんじゃないかと思いました。上に挙げたような話を除けば、労働環境としては申し分ありませんでした。 今回は、たまたま僕が関わっていた案件周りがつらかったというだけです。他に携わった案件には面白いものもありましたし、そういったものに関わることができたのはいい経験でした。もちろん iOS 開発についても、誰にも頼らず0から独学で学ぶ機会があり良かったです。ともかく学びは多かったということです。

ちなみに時給倍くれたら残りますよという話をしたら本気で検討されたので丁重にお断りしました。良かったですね。ちょっと後悔しています。 ただ、まあ仕事してアウトプットしてるならそれに見合った評価はされたかったなという気持ちです。残念ですね。

 

機会、環境、考え、金など、茫漠とした概念が世の中にはあり、我々はその中で最適な解を求めてやっていく必要があるということでした。

 

read more »