職業選択の自由

職業を選択するまでの過程。

新春闘病記 前編(仮)

2019年1月1日。めでたく年が明けたこの日に、俺は病院に行く決断をした。新年最初の出掛け先が病院とは、なかなかツイテナイ1年である。そう、この時は「ツイテナイ」で済むと思っていた。

予兆

遡ること1ヶ月、この時期俺はなかなか完治しない風邪に悩んでいた。次第に会社も休みがちになり、12月中頃に2週連続で木曜日に会社を休むということもあった(有給残っててよかった)。休むほどまで行かなくても喉の痛みが消えなかったり、気温以上に寒気を感じたりもした。それにしても、今まで風邪をひくことは時々あったがここまで長引くのは初めてだったので、もっと根本的に不調をきたしていないかと不安ではあった。しかし、病院でアドバイスを聞いても「免疫をつける」「睡眠をよく取る」など無難なことばかりだったので、まあしばらくすれば良くなるかとこちらも考え、処方された消炎鎮痛剤でやり過ごしていた。

異変

2018年12月29日土曜日、前日にこの年の仕事納めだった俺は、実家(電車で2時間弱)の親の協力もあり自宅の掃除をしていた。掃除が一段落したら食事の後電車で親共々実家に移動し、年末一緒に過ごすつもりだった。夕食を終えたのは19時頃、今思うとこれが最後のまともな時間であった。

実家へ向かう電車の車中、必要以上の疲労感を覚えた。立っているだけでもしんどかったが、どうにか実家までたどり着く。しかしこれが最後であった。21時頃実家にたどり着いたが、倦怠感が全身を襲い寝込むと起き上がれない。風呂に入るどころか2階の寝室まで行く気力もすぐには出てこなかった。さっき飲んだビールのせいか?いつもはこの程度でこんなに具合悪くならないのだが…

そして猛烈に喉が痛い。飯どころか水ですら飲み込むと痛い。高級そうな日本酒の瓶が目に入ったがだるさと合わさって飲む気になれなかった。この日は痛みを我慢して消炎鎮痛剤を飲み込み、風呂は入らず布団で寝込んで症状が治まるのを待つことにした。

悪化する症状

翌朝…というか、時間の感覚がなくなりつつあった。眠りに落ちる感じはするが、喉の痛みで目が覚める。そして時計を見ると1〜2時間しか経っていない。これを一晩中繰り返した。また寝ようとしても喉が痛くて眠れないし、唾液を飲み込むことすら痛いので口の中が唾液まみれで気持ち悪い。それに喉が異常に腫れて痰も絡み、体勢によっては呼吸すら苦しい。何か別のことをしようにも睡眠不足には違いないないので頭がぼーっとする(実はこの時、発熱の症状もあった)。

消炎鎮痛剤はやや効いたので、ゼリーやヨーグルトなど流動食を押し込んで(これすら痛い)空腹を埋めつつ、薬を飲み込んでは痛みを我慢して横になる時間が続いた。唾液が飲み込めないのでティッシュを口に挟んでそこに吸わせるスタイルで乗り切った。唯一の救いは実家の風呂に入ったことで、血行やら湿度やらの関係で一時的に楽になれた。この日はベッドからほとんど出ず丸1日を過ごす。この日実家には家族の他に親戚一家が集まっており、年末パーティのため豪華な食事や酒が振る舞われたが見ないことにした。

3日目の朝、喉の痛みは変わらないか僅かにマシになったか…と思いきや新たな異変が発覚する。歯茎が腫れたのか上顎と下顎が噛み合わず、常に下顎が前にずれた形になる。しかも顎が通常の半分も開かない。開こうと思えば開けるが、右の顎関節がかなり痛い。なんか右耳の奥も痛い気がする。ただそこさえ我慢すれば全体の具合は前日より酷くはなっていないので、ここで実家から離れ自宅に戻ることにした。この日は12月31日。予約していた年越しライブイベントがあったのだ。

アドレナリンとカフェイン

自宅への移動中、時間が経つにつれて症状もマシになってきたので、空腹もあり思い切って軽食を取ることにした。喉と消化に抵抗の少なそうなうどん。飲み込む時の痛さは相変わらずだが他の物でも変わらない。並盛りを完食し、久々の塩味(前日は甘い味付けの流動食しか食べていない)に癒された。喉さえ通り抜ければ胃腸は健康なのだ。自宅で少し休憩した後イベント会場(映画館であった。屋内で座席がある場所だったのは助かった)へ。念の為レッドブルで気合い入れておく。体調不良を押して参加したライブは大変満足であった。声が出なかったり帰宅がしんどかったりしたが、外出先では大きなトラブルもなく自宅に戻ることができた。これがライブの力…!

家に帰ってからもゆっくり風呂に入ったりの余裕はあった。加湿器も導入したことだし睡眠さえ取れば少しずつマシになるか?と一瞬考えがよぎったが、どちらにせよ一晩で治るはずがないと思い直し翌日病院に行くことを決めて寝床に着いた。事前に市営の「急病診療所」が年中無休で営業していることを調べておけたのは心強かった。

冒頭のシーン

やはりよく眠れない。前日は色々あって寝床に着いたのは午前3時ぐらいだったが、目が覚めるとまだ朝の6時であった。3時間しか眠れていない。もちろん眠い。しかし横になると余計喉が痛い気がして眠る気にもなれない。仕方ないのでスマホで適当に時間を潰す。急病診療所の開業は午前10時。移動時間考えても時間がありすぎる。そんなことを考えていたら1時間ぐらい経過していた。

ここで深刻な事態が起きる。突然物凄い勢いで咳き込み、口から唾液に混じって血が出てきた。起きてから水を全く飲まなかったのがまずかったか。とにかく物理的に傷がついたとなると危険しか感じない。痛みを我慢して喉を濡らし、最低限家の片付けをして着替え、外出。途中コンビニで多めに現金を下ろし、急病診療所には9:50分ぐらいには到着。それにしてもツイテナイ正月だ…

転送

急病診療所は応急処置と適切な医療機関への転送を目的とする。簡単な症状であれば処置や薬の処方を行うが、施設内で手に負えない症状の場合でも設備の整った大病院への紹介状を作成してくれる(逆にこういう大病院は紹介状が必須である)。このため様々な症状に年中無休で対処できるというシステムだ。

受け付けは少し早めに開始していたようで、俺が到着した頃には既に結構な人数の患者さんが診察を待っていた。ていうかお前ら正月だぞ、人の事言えんけどそんな体調崩してばっかでいいのか。それはともかく、自分も受け付けを済ませ、多少待ってから医師の診察を受ける。

「うわー腫れてるな…これ 転送 だね」

覚悟はしていたが本当に来た。そりゃそうだ、この時点で喉が腫れていたまともに声が出せないレベルになっていた。会計を済ませ紹介状をもらい、隣町にある大病院へタクシーで移動するよう指示される。正月のタクシーって出はらいまくりなのね。6社ぐらいかけてやっと手配できた。こちとら声出すのもきついんやぞ。

人生初・入院

病院に到着後、いよいよ倦怠感が限界になってきた体に鞭打って受付書類を作成、処置室へ。今までは内科で受けていたがここからは耳鼻咽喉科の先生にお世話になる。口の中を今度は鼻カメラで診察し(麻酔のおかげで痛くはないがかなり苦しい)、治療法について先生が一言。

「(俺)さんね、 すぐ入院してもらう から。明日でも診察できるから、今は全部の処置はやらない」

決定した。まあ飲食がまともにできない時点で覚悟はしていた。しかしいざ言われると整理がつかない。病院に寝泊まり?全然準備してないけど?毎日何するの?こんな痛い診察毎日続けるの?そうこうしているうちに次の処置が始まった。

「膿が溜まっているので出します。まず出るかどうか調べる」

喉に麻酔をした上、長い注射針を腫れた喉に刺す。先生が注射器を引くと中にどす黒い血が吸われていく。ああ、俺の体の中ってこうなってるんだ。これ抜いていい血なのか。そして2回目。もう一度注射針が喉に刺さる。麻酔はかかっていたはずだが今度は猛烈な痛みを感じ声を上げた。処置は中断。次に襲ったのは急激な吐き気と脂汗、不安とストレス。この歳になってまだ未知のストレスがあったか。

この後、患部にメスを入れて膿を取り出す処置の予定だったが、患者(俺)の状態を優先し延期。ここから入院のための準備に入る。

  • 採血 (腕から。先述の処置とはまた別に注射針が入る)
  • レントゲン (異常なし)
  • 心電図 (異常なし)
  • 検温 (39度を超えていた。この病気にかかってから常にかなり高い)
  • 血圧 (160を超えていた。人生最高値)
  • 点滴の装着 (腕から。また体に穴が開く)

看護師の方に案内され病床へ。丁寧な説明を受け、家族の連絡先など必要書類への記入を済ませたところで入院手続きは完了。医師は1週間程度と言っていたので、ここがしばらく俺の城になる。入院ってこんな簡単に決まってその日のうちにできるもんなんだな…と少し落ち着くと、看護師の方が渡した書類の中に「入院治療計画書」が見えた。

扁桃周囲膿瘍

「病名」欄に書いてあったこの名前こそ、今回俺がかかった病気の名前である。喉の入口の両側に1個ずつあり免疫機能を果たすリンパ組織「扁桃腺」。ここが細菌やウイルスに感染し炎症を起こし、周辺組織まで膿が広がってしまう 重症感染症 である。主な症状として

  • 感冒症状 (いわゆる風邪)
  • 扁桃炎症状
  • 高熱
  • 著しい咽頭痛 (喉の痛み)
  • 嚥下時痛 (飲み込む時の痛み)
  • 開口障害

(参考: 扁桃周囲炎、膿瘍|耳鼻咽喉・頭頸科|順天堂医院)

…ああ、確かにこの通りだったわ…そしてこの症状のためまともに飲食ができず、多くの場合脱水症状や全身状態の悪化を引き起こす。さらに悪化すると脳組織への腫瘍や敗血症にまで発展するリスクもあり最悪死に至る。繰り返すが非常に危険な感染症である。

その他の特徴としては、症状が見られるのは喉のどちらか一方のみらしい。そういえば自分の場合も腫れたのは右側だけで、顎を無理やり開けた時の痛みや耳の痛みが右だけだった。そして年齢でいうと乳幼児や逆に高齢者には比較的少なく、20〜30代の青壮年期がピーク。また性別差もあり男性に若干多いそうだ。…って俺ドンピシャじゃねえか!(29歳男性) 原因となる菌やウイルスはそんなに特殊なものではなく、免疫力の低下などによって誰でもかかりうる感染症である。また再発も比較的多く、あまりに再発するようだと扁桃腺ごと切除する手術が適用される場合もある。自分の場合こうはなりたくないが…今後も気を付けよう。

治療としては、疾患の重篤さから内服治療による改善は期待できず、また経口摂取がそもそも困難なので 入院・点滴 による抗生物質投与と栄養補給が基本となる。さらに化膿部は切開などによる膿の除去などの外科的処置も併用される。

そして入院へ

病床で点滴と酸素センサーを繋がれた。この病気、喉が腫れるので窒息のリスクが高く、そのため酸素不足を検知する必要がある。点滴を繋がれて病床に寝ていると本当に病人という感じがして気分が落ち込んだ。ドラマとか映画でしか見たことのなかった病床の光景が今目の前にある。

夜も暗くなった頃、連絡しておいた親が遠路はるばる荷物を持ってお見舞いに来てくれた。着替え、洗面用品、そしてMacに充電器…幸い電波(モバイルルーター)はかなり状態が良かったので頑張れば退屈しなさそうだ。科目にもよるだろうが、最近の病院は院内でインターネットを使っても何も問題がない。簡単な世話話のあと、自分の病床に戻る。これで今日は終わりだ。

食事もないので(繰り返すが喉が痛む)、まだ夕方5時ぐらいであったが今日は本当にあとは寝るだけ。しかし点滴していると何も食べていないのに確かに空腹も喉の渇きも進行しないので不思議なものだ。少し抗生物質も効いてきたのか痛みも落ちついたのでどうにか眠れそうだ。

ここから俺の人生初の入院生活が始まる。後編へ続く。かもしれない。

また会社辞めます

1年と半年ほど勤めた会社を退職することにした。経緯について振り返っていきたい。

入社の理由

退職の話の前に入社の経緯から振り返る。もともとこの会社には「遠隔診療ビジネスの立ち上げに携わる」という名目で入った、はずだった。入社時にはテクノロジーで日本の医療に関する課題(僻地医療、通院中断など)を解決していきたいというビジョンが社長から伝えられ、大いに共感したことを覚えている。

あと、前のSIer企業がそれはもう向いていない仕事だったので、一刻も早く転職したかったという事情もありよく考えずに転職を決めたのは間違っていない。入社前に勉強会などで転職先の社員の方と面識があったこともあり、(今思うと)異様にスムーズに入社が決まったことを覚えている。

退職の理由

事業とのシナジーを感じない

なんだかんだ言って一番大きい。もちろん入社の時には任された事業に希望を感じていたが、その後会社の方が変わっていった。いや、正確には会社が変わりつつある所で自分が入ったが、結局元に戻りつつある、と表現した方が正しい。

もともと就活関連事業から始まった会社なので、今でも主力事業は就活および就活関連のオウンドメディアである。しばらくしてエンジニアを採用し自社サービスを内製するようになり、「メディアの会社」から脱却しようと様々な構想が立ち上がり、そのうちのひとつである遠隔医療分野に自分がジョインした。しかし最近改めてメディアを強化する方針が明確になり、自分の担当業務も遠隔診療システムからいつの間にかメディアサイトの運用保守に変わっていた(コンテンツは医療がテーマではあるが)。発足当初はメディアサイトを広告塔として自社の遠隔診療サービスの集客経路のひとつにすると聞いていたが、今ではメディアサイト自体のセッション数やアフィリエイト収入が主なKPIになってしまっている。

遠隔医療事業が医療メディアサイトの運営に矮小化された一方、会社は「メディア強化」方針に従いメディアサイトが次々に立ち上がった。消費者金融、保険、婚活、他社から買収した恋愛コラムなどなど…一体この会社は何を目指しているのか? ていうか一時期のD●NAと同じ流れじゃないかコレ? 疑いすぎかもしれんが、自分ははっきりと「迷走」の流れを受け取った。

技術的な成長の限界

こういう会社の方針なのでせいぜいメディアサイトしか作れない。ご想像の通りシステムには大して複雑な処理はなく、仕事の依頼も多くは「バナーを設置してほしい」とか「テキストを変える」とかシンプルなものである。ちょっとRailsができる、くらいの技術力であれば問題なく務まる。1プロジェクトに関わる人数が異常に少ないのでレビュー体制はボロボロで、コードの品質も上がるはずがない。たまに他社事例を知るとレベルの低さに愕然とすることばかりである。

しかも上記の「メディア強化」方針のためSEO関連の施策が多い。個人的にはGoogleの手の平の上で踊らされている感覚でどうしても好きになれなかった。ていうか、もともと遠隔医療システムを展開していくつもりじゃなかったのか? 何で俺は検索順位とかセッション数ばっか気にしているのか?

なぜ、エンジニアリングの程度が低くても会社が存続していられるか。これは前出の就活関連事業が盤石の主力事業として会社を支えているからに他ならない。やはり弊社は「営業の会社」だった。エンジニアなんてただの便利屋である。創業の経緯はもちろん理解して入社したが、そこからの変革が進んでいなかったのを見抜けなかったのは自分の失点である。

裁量労働制を正しく運用していない

ぶっちゃけ然る所に報告すれば一発アウトな事案だと思っている。自分含めエンジニアは裁量労働制として勤務してはいるのだが、

  • 勤務時間の固定(遅刻の場合報告義務あり)
  • 残業代は固定
  • 22時以降の就業は事前申請が必要。なお、賃金の割増はない(※)
  • (ルールではないが) 業務における裁量は限定的、な感じがある

いや、こういう働き方が悪いと言っているのではない。ただ、こういう方針なら裁量労働制を名乗るなよと言いたい。正直、残業代を払いたいたくないから裁量労働制と言っているだけの典型的なブラック経営では? とまで疑っている。ちなみに自分は金が増えないのに残業するのはアホらしいので極力定時で帰っている。どうせ窓際部署で大した仕事でもないし。

(※) これは裁量労働制であってもアウトである。つまり、社内「裁量労働制」適用者で22時以降に勤務した労働者がいたとして、この「社内規定」を根拠として割増賃金が支払わなければ、裁判で訴えられれば負ける。この会社、労基法のプロはいないのか? ちなみに私はアホらしいので22時前には絶対に帰る(なるべく、ではない)。

転職活動を振り返る

実は去年の9月ごろに転職サイトに登録し、ゆるく活動していた。前回の転職活動と比べればかなりストレスなく活動できた。

  • 勤務地が都心なので仕事後の会社訪問が楽
  • 残業が少ないので時間調整しやすい (※)
  • Ruby on Rails の実務経験がある。これ重要

(※)自分だけは閑職なのでコレだったが、全社的には深夜残業泊まりこみ当たり前である。

今振り返ると結構な数の会社に訪問した。10〜15社くらいか? お祈りされたりしてまあまあストレスはあったが、いい結果になってよかった。

新しい会社を選んだ理由

基本方針

転職候補は、割と初期の段階からBtoBのビジネスに絞っていた。ある場所で話したら珍しがられたが、自分は日本の会社はもっと変わらなければならないと思っている。今後もBtoB重視の方針は変わらないだろう。

事業

転職先の事業を一言で表現すれば、製造業を中心とした会社同士のマッチングサービスである。事業実績も確認でき、そこから見る限りではユニークなビジネスに関われると感じた。また最終面接の場では社長から長期的ビジョンが示され、日本の製造業全体の再編までも目指していると伝えられた。今度は「入ってみたら違った」ということがないように祈る。

環境

もっともユニークな取り組みだと思ったのがリモートワークの採用である。全ての従業員は週あたり2回までリモートワークにより出勤しないで仕事を進めてもいい制度がある。これに関しては現職では基本的に認められていないこともあり魅力を感じた。ていうか今の会社リモート可の基準がよく分からないんだよな…子育て中とか親の介護とかだとできるらしいがそれなら俺だって…まあもう辞めるけど…

また、かのMatz氏を呼んでの定期的な勉強会の開催、外部イベントの参加補助など、エンジニア視点の環境が今と比べると比較的整っていると感じた。新天地でしっかり成長しようという気分になる。

この会社に最初に訪問したのは去年の9月と、実はかなり古い。その間、その時面談を担当していた社員の方と イベントで偶然会う ということが3回ほどあった。特に去年9月のRuby Kaigiは全くの偶然で相当驚いた。

実はこれはいい方向に作用した。つまり面接 に担当者と会っておくと、履歴書や面接での質問から読み取るより何倍も詳しく自分の人となりを伝えることができる。ここで面接を設定すれば、もう始まる前から終わっているようなものである。エンジニアにとって勉強会の参加が大事な理由がここにある。転職したい会社があるなら、面接の前にその会社に行くことが近道。

おわりに

正直なところ、現職でも環境はそれなりに良く、人間関係も問題なかっただけに2年足らずで退職という結果になったことは自分でも惜しい。しかし、それらの良かった点をかき消すほど事業とのミスマッチは大きかった。

次の会社はそこまで大きなミスマッチは流石にないはず。まず転職を考えた時点でそこは注意したし、実際の社員とも何度も接する機会があった。6月からまた生活が一変することだろう。会社の大きな目標に自分がどこまで貢献できるか、自分自身はどう変わって行くか、今は楽しみにする。

ニコニコ動画のサムネイルを一括ダウンロードするRubyスクリプト

ニコニコ動画には、動画のサムネイルと概要情報を小窓にして埋め込める機能がある。見た事がある人も多いだろう。

[サンプル]

今回、こういう埋め込みがたくさんあるページからこの画像だけ持ってくる作業を自動化した。実行環境は Ruby2.3.3 (やや古いが)、HTMLの解析にお馴染み nokogiri を使っている。

サムネイルの中身

小窓の正体は <iframe> である。中身を覗くとこういうアドレスの埋め込みになっている。

https://ext.nicovideo.jp/thumb/sm3504435

これは普通のURLなので、やろうと思えばブラウザでアクセスできる(見た目は悪いが)。

さて、欲しい画像はこの中にある。つまり <iframe> からこのアドレスだけ持ってきて、改めてアクセスする必要がある。やや荒いが

parser
  .xpath('//iframe')
  .map { |iframe| iframe.attribute('src').value }
  .select { |iframe_url| iframe_url.match %r(http://ext.nicovideo.jp/thumb/sm\d+) }

とした(他に <iframe> があるとも限らんので)。

画像の特定

改めて http://ext.nicovideo.jp/thumb/sm\d+ の中身を見てみると、サムネイル画像のURLは

https://tn.smilevideo.jp/smile?i=3504435

となっていることが分かる(これで例のミクちゃんが見られるよ!)。普通の <img> タグなので取得は簡単。

# URLの読み込み→Nokogiri は事前にやっておく→ thumb_parser
thumb_img_src = thumb_parser.xpath('//img[@class="video_img"]').attribute('src').value

これで画像のURLが取得できる。

画像ダウンロード

ここまでやったんだから画像のダウンロードまで自動化したい。URLの画像データをローカルに保存するには open-uri を使う。 (Stackoverflow さんいつもありがとうございます)。画像ファイルの形式は一見分かりにくいが .jpg なので

open(thumb_img_src) do |image|
  file_id = thumb_img_src.scan(/\d+$/)[0]
  File.open("images/smile_#{file_id}.jpg", 'wb') do |file|
    file.puts(image.read)
  end
end

とすれば images/ 以下に画像がずらっとダウンロードされる。ヤッタ!

f:id:strviola:20180126234852p:plain

成果物

といったコードを書いたのでGistに公開した。

ニコニコ動画サムネイルダウンローダ · GitHub

ここで題材として使わせてもらったのはこのブログ記事になる。

swiftfox.blog6.fc2.com

で、これで取ってきた画像をなんやかんやして

の画像を作った訳ですよ!

まじかああああああもう10年(略

以上、いろんな意味で10年の歳月を実感する記事でした。

今年の目標

2018年、あけましておめでとうございます。

更新しやすいタイミングなので久々に更新するが何ヶ月も空いてしまった。なんでこうなったのか、ちょっと去年をふりかえりたい。

まずこのブログは「技術ブログ」として生まれ変わる予定だった。そのために自分はどうやら完成度や充実性や独自性を気にしていたようで、更新自体に尻込みしていたような気がする。

それとも、ネタが無かったのか。いや、そんなことはなかった。やはりRailsエンジニアとして仕事をしていると日々直面する課題はある。そしてうまいこと切り抜けたりするが、そこで得た知見は…そうだSlackに書いていた。うちではSlackを社内SNS的にも使っていて、そこに調べたリンクなんかをメモしていた。知見を言いふらしたい欲は社内でも強かったはず。あと量は減るがQiitaやesaにも書いていた。

つまり今まで社内クローズドな環境に書いていたものをブログに書いていけば充分イケるということだ。これからそうしていこう。目標はまず量!質はとにかく公開してから!間違っていたらあとから直せばいい。個人のブログだしな。

そういや、調べ物をしていると割と古い情報が検索上位に来ることが思ったより多い。Rails4はまだ使える方で、Rails3のどことなく古くさいコードスニペットも散見される。自分の環境は全部Rails5なので、アイデアが既存記事と被っても「Rails5で動く」ことを伝えられればその価値もあるだろう。

今年の目標は、 月2本の記事公開! (あとで見直すかも)

Done is better than perfect.

とりあえずやってみようぜ、多分イケるから。

今年もよろしくお願いします。

古い Mac で Ruby を 2.4.1 にしようとした話

背景

Mastodon が流行中だ。ソースコードGitHub で公開されている、 Ruby on Rails を採用しているとのことで私も動かしてみることにした。インスタンスを立てる前に、まずは localhost で動かすことを目指す。

リポジトリを手元に Fork & Clone して bundle install したところ

「 Ruby2.4.1 を使え。古事記 (.ruby-version) にもそう書かれている」

しまった。 Ruby 自体のバージョンアップなんてそういえば数ヶ月していなかった。まずここから修正する必要がある。

筆者の端末は MacBook Pro (Retina, 13-inch, Late 2013) である。それまで携帯端末向けにしか搭載されていなかった Retina ディスプレイが Mac に採用された最初の機種だ。買った当初は「 Retina なのに大画面!しかも薄い!」と感動していたものだが、時は流れ「年季の入った」と呼んでも差し支えない状態になってしまった。

そんな状態でも手続きを踏めば最新のプログラムを動かすことはできる。こういう時は

  1. brew update する
  2. brew upgrade ruby-build で最新の Rubyrbenv に入れる
  3. rbenv install 2.4.1 でインストー

とする。途中までは順調に進み、最後の rbenv install 2.4.1 しようとしたところ

BUILD FAILED

何か…コンパイル自体に失敗している…? こうなったらログを読むしかない。どうやら ossl_x509store.cコンパイルエラーを起こしている。こういう時は何かしら環境がマズいはず。エラーメッセージでググればどうにかなるだろう。

Sierra にアップデート

エラーメッセージで検索するとこんな記事が出てきた→ 年季が入ったmac(笑)にrbenvでruby 2.4.0をインストールしようとしたらハマったのでメモ - Uyama.coffee

おそらく同じエラー、環境も似通っているので参考になる。記事によると以下の5点を試したところ正常にインストールできたとのこと。

  • rbenvをHomebrew版から本家Github版からインストールしなおし
  • macOSを10.11 El Capitanから10.12 Sierraにアップグレード
  • Xcodeバージョンアップ&一回起動
  • xcode-select –install」を実行
  • brew doctorのワーニングを全部つぶす <- これが一番有力かも

最初のは怖いので Sierra にアップデートを最初に試してみることにした。時間がかかるしネットで遊ぶ分には不自由しないので El Capitan のまま放置していたがいい機会だ。アップデートスクリプトを走らせてその日は就寝。翌朝、初期設定を済ませたあと改めて rbenv install 2.4.1 を実行したところ

BUILD FAILED

Xcode を更新

いや、一発でそんなにうまくいくはずがない。 Xcode は開発環境に加えてC言語関係のバイナリコマンドも付属する。バージョンアップは iTunes Store から行うがこれがまた長い。しかしこれでコンパイラも無事更新されたことだろう。

BUILD FAILED

いや待て、さっきの記事にはもう1個コマンドが紹介されていた。 xcode-select –install だ。試すとダイアログが出て、いかにも仕事してくれそうな感じだ。よくなったと思いまたコマンドを叩くと

BUILD FAILED

Homebrew を更新

やっぱりねー使うの Homebrew なんだからそっちも更新しないとねー Homebrew 自体の更新 (brew update) は直近で行ったので、各 brew の更新を試す。 brew upgrade の後に brew 名を入力しないと全ての brew が更新される。これもコマンドによっては何年も更新していなかったりしたので一晩レベルで時間がかかるが、その方がよりしっかり効いている実感がある。翌日改めて rbenv install 2.4.1 を実行!

BUILD FAILED

迷走…

正解を求めて様々な資料を調査したが、一つ学んだのは手当たり次第に試すべきでないということ。某所の「この記事は公開から1年以上が経過しています」の表示がある記事の信憑性は非常に低い。英語の記事もしかり。見つかった記事には

  • rbenv をダウングレード
  • Homebrew を GitHub から直接インストー

など、リスクが高かったり一時的だったりする手法がある。エンジニアには記事の内容が本当に効くか判断できる目が必要である。

ここまでやってダメだったとするとアレしかないか…

brew doctor

実行パスの警告を表示してくれる brew doctor コマンド。実行すると尋常でない数の警告が表示された。 こんなことになっていたのか… そういえばこの Mac, マシン自体もそんなに新しくない上にデータ自体はそれ以前に使っていた MacBook (2008年購入) を引き継いだので、内部はもっと荒れていたと推測される。

とった対策は大体以下の通り ↓

  • シンボリックリンクがあるべきディレクトリにバイナリが入っていた→削除
  • コマンドが重複 (python関係) →片方削除 (多分今回関係ないと思うが念のため)
  • 期待されていない設定ファイル→削除

ちなみにシンボリックリンクと通常のファイルが混在するディレクトリから通常のファイルのみを削除するにはこのワンライナーが使える。

ls -l path/to/delete/* | grep '^l' | awk '{print $NF}' | xargs rm

全部ではないもののある程度警告を潰して改めて rbenv install 2.4.1 を実行!

Successfully installed

😂😂😂😂😂

結論

brew doctor 先生の言うことはちゃんと聞こう。

以上、ボロボロの Mac に最新の開発環境を乗せようとして苦労した話でした。

大江戸Ruby会議06に行ってきました

先週末、3月18日〜20日は春分の日を含む3連休であった。天候にも恵まれたため外出したという方も多かったことだろう。自分はというと、月曜祝日に 大江戸Ruby会議06 に参加した。Rubyエンジニアとして非常に知見を深めることができたので、ここで感想など書いていく。(最初の「Ninja talks」は諸事情により参加しませんでした…) 内容自体は多分スライドが上がると思うのであまり深くまでは踏み込まない。

各セッションの感想

招待公演: Ruby考古学 (石塚圭樹氏)

Matz氏と並びRubyごく初期の開発メンバーである石塚氏が、当時のメールやコミットログからRubyの成長過程を紹介した。これ多分 他では絶対聞けない 。今回紹介されたログで一番古いものは1992年まで遡る。さらに “Ruby” 以外の名前の候補 “Oyster”, “Coral” なども紹介された (海を連想するのはPerl「真珠」を意識?) 。 めっちゃ貴重 。ここまで遡ると「新しい言語を作る」という意気込みが一番強く感じられ、どういうことかというと他の言語を 名指しで批判 していた(PerlC++など)。普段当たり前に使っているプログラミング言語も、感情を持った人間が開発したものだと当然のことを改めて認識できた。

また、開発にかかった時間が実感できたのも大きい。Rubyの誕生日はその名前が決まった1993年2月23日とされている。この後順次機能が実装されていくが、その日付も紹介されていた。メソッド呼び出しのカッコを省略できるようになったのは1994/10/13, ブロック呼び出し構文として do ... end が実装されたのは1996年、といった具合だ。正直、今までRubyはMatzという1人の天才から羽ばたくように生まれてきたイメージを持っていたが、実際は全くそんなことはなくて、多くの人が何年も地道な改善を続けてきた結果だと考えを正すことができた。世の中そんな順調なシステムなどない。

ちなみに以下のツイートが若干バズった。というかMatz氏本人にRTされた。

フルタイムコミッター対戦

企業に所属しながら勤務としてRuby言語自体の開発に携わる「フルタイムコミッター」。今回は4名を招待して対戦する企画である。えっ、 「対戦」? …と思っていたら、始まったのはまさかの クイズ大会 である。この4名にはあらかじめ企画の趣旨を伝えてあり、Rubyのコミットに関するクイズを数問用意してあった。当日は1人が出題して他の3人が回答し、正解数の多い人が優勝。 マニアック すぎて面白かったので抜粋して紹介する。ちなみにこのセッションだけスライドが存在しないので記録を多くした。

Q1 RubyではGCの設定を環境変数として渡すことができる。この変数の種類はいくつか。

いきなりレベル高いよ!! そもそもGCの設定を環境変数として渡す機能自体初めて知った(こうするらしい。これが全てではない)。正解は 14種類 とのこと。

Q2 Ruby Issue Tracking Systemに登録されているissueは現在13000を超えているが、記念すべきfeature 10000は?

正解はこれ (ブログなので検索もできるしWebサイトへのリンクそのものを貼れるのは便利なところ) 。内容は浮動小数点数の精度をhashで渡そうというもの。これで 正解者がいる んだから恐ろしい。

Q3 Ruby 2.4.0 の文法で非終端記号はいくつ存在するか。

どこかのソースコードで定義されているようで、出題者は「grepして数えた」と述べていた。正解は 166 らしいが、さすがにピッタリ当てられた人はいなかったので一番近い「200くらい」と答えた人が正解になった。

Q4 今から10年前、2007年には12回のコミットがあり、うち9回はこの会場にいる人による。残り3回は同一人物だが、その人は?

驚くことに初球打ち正解がでた。Matzその人である。ていうか呼び方、「さん」もない「まっつ」なのね。内容は「スレッド周りだったはず」とのこと。

Q5 Rubyを構成するファイルのうち、最もコミット回数が多いのは version.h (※コミットの度に必ず更新されるため) だが、2番目は?

これは単純に興味があったがなかなか正解が出なかった。string.c, array.c などいかにも多そうなファイルが出るも及ばず。正解は io.c であった。なるほど、ファイル入出力か…

Q6 組み込みモジュール Math で一番最近追加されたメソッドは?

確か出題者本人の得意分野だった気がする。正解は3乗根を求める cbrt とのこと。もう「分かるか!」なんて思わなくなっている。

Q7 Rubyリポジトリの中で .rb ファイルはいくつあるか?

Rubyの処理系はC言語で書かれた部分とRubyの部分があり、そのうちRubyスクリプトファイルの数が出題された。ちなみにこれには出題者からヒントがあり、 素数 。会場は多いに沸いたのであった。正解は 2383 で、「さっき思いついて .prime? してみたら true だった」(出題者)。全然当たらないので最後の方は2分探索になっていた。

他にも出題があり、1時間くらいあったが全く飽きることがなかった。

Ninja talks

Rubyプロダクトに関わって活躍している方「Ninja」による1人あたり約30分のセッション。この日は6人のセッションを聴講し、どれも非常に濃い内容だった。一部感想と共に内容を紹介したい。

esaRubyistと私 (赤塚妙子氏)

弊社でも利用している esa.io の共同創業者である赤塚氏が、自身のデザイナーという視点からRubyコミュニティについて述べた。この中で「デザインの役割とは方向性を示すこと」という話が興味深かった。

話が若干飛ぶが、イベント終了後の懇親会で、赤塚氏も含め何人かと会話した。その中でRuby界隈でよくある、「コミッターがスターになる」「新機能の取り入れに積極的」などの特徴がなぜ生じるのか議論した。すなわち、Ruby自体のデザイン、つまり方向性がそうなっている。新機能はどんどん追加するし後方互換性も結構捨てる。だから「新しいもの好き」が集まってくる。

赤塚氏はMatz氏を「デザイナー」と呼んでいた。プログラミング言語には当然利用者がいる。プログラミング言語をデザインするとは、すなわちその言語の利用者、さらにその利用者のコミュニティまでデザインすることである。これを本人は 無名の質 という考えを引用して紹介していた。

Ruby 2.4 Internals (笹田耕一氏)

クックパッド社でフルタイムコミッターとして活躍する笹田氏のセッション。これこそRubyカンファレンスの醍醐味である。Rubyの内部実装に触れるのは非常に刺激的だ。実装だけでなくテストやベンチマークの話もあった。Ruby2.4.0のリリースとして「 lambda が速くなった」があるが、このベンチマークとして使用されたのが 「lambdaだけでFizzBuzz という尋常でないプログラムである。作者に「初めて役に立ったよ」と感謝したんだとか。

これとは別にRubyのコミットに関するセッションがあり、共通して感じたのが品質への意識である。まず課題を発見し、実装はもちろんあらゆるテストやベンチマークを実施し、報告書も提出する。バグを埋め込んだとしても発見者に感謝する。単なる「利用者」「お客さん」に収まらず共に作り上げていく、OSS開発の魅力に触れることができた。

おわりに

非常にボリュームのあるイベントだったので全ては紹介しきれないが、印象に残った部分をなるべく伝えたつもりである。参加者も全体で200人くらいいたはず。多くの人と関わるということはそれ自体勉強になることであり、それらが強力なバックグラウンドのある人であればなおさらである。カンファレンスへの参加、今後も続けていきたい。目標は9月にあるRuby Kaigiだ。

「簡易アプリ」英語で何と言う?

SIerからWeb企業への転職を果たし、Ruby on Railsエンジニアとなってからおよそ半年が経過した。概ねストレスも少なく心身ともに負担も小さい穏やかな生活を送っている。前回の更新(内容は忘れた)から半年間、書きたいことがなかったわけではないが、大声で主張したいことは勢いでTwitterに書いてしまうことが向いていると気づいたのがここ最近の発見である。当ブログは「技術系ブログ」として改めてスタートを切りたい。第一号はウォーミングアップの意味も込めて「軽い」話題から。

さて、本題である。私は入社してから現在まで、今の所移動もなく同じプロジェクトの追加開発を手がける日々を過ごしている。ある程度開発者として認識されてきたようで、比較的大きい変更を手がけることも増えてきた。そこで本日依頼されたのが、掲題の 「簡易アプリ」 のサーバーサイド実装である。

何が機密情報に当たるか分からないので詳しくは伏せるが、弊社は「地方創生」を事業として推進する方針があり、高齢化が進んだ農村にも積極的に営業をかけていて、その関係で自分の携わっているアプリの利用者には高齢者が多い。そういった背景もあって、利用者から「今のアプリは色々と複雑だ。最低限の機能だけ使える簡易版が欲しい」という声が上がったようである。

開発に着手するにあたって git checkout -b しようとした時、ふと疑問が思い浮かんだ。「簡易アプリ」って、英語で何て言おう…? 私の前職のように、文字の制限などお構い無しに 日本語ローマ字をガンガン使う プロジェクトも存在するが、今の自分のプロジェクトでは可能な限り英訳している。

この単語は単なるブランチ名に留まらず、これから「簡易アプリ」全体を代表する単語として、モデル名やメソッド名に多用するプレフィックスにしていきたい。そう考えると、プログラムの保守性の観点からも重要な単語である。いくつかの辞書系Webサービスを見ながら考えていたら、いつの間にか小一時間経っていた。意外にいい訳が見つからない。

  • “Simple” … 最初に思いついたし、Google先生も真っ先に挙げてきた単語だが違う気がした。 “simple” である方が正解で、そうでない方は望ましくないという印象を受ける。一方、今回は簡易アプリでない方も引き続き主力商品として継続する。
  • “Easy” … 「簡易」から「簡単」を連想するとこうなる。確かに操作は簡単なんだろうが、「気楽」「快適」みたいな余計なイメージも入り込む。単に機能が少ないだけであって快適とは言えないだろう。
  • “Abridged” … 「要約された」「短縮された」などの意味の単語。不勉強で申し訳ないが今日初めて知った。意味としてはいい線行っているが、日本人同士の会話で「アブリッジドの…」と言ったところで通じるだろうか?
  • “Digest” … 「部分的に抜き出す」という意味ではかなり良い。しかしエンジニア的には セキュリティの文脈 で使う印象が強すぎるので、余計な勘違いを避けるためにこの単語は使ってはいけない。

他、類義語時点などを見て回ったが、「簡易」から「単純」「簡潔」といったイメージと異なる単語、果ては「朝飯前」「お茶の子さいさい」といった慣用句まで出てくる始末。日本語での検索はいったん諦めた。

気持ちを切り替えて、英語の類義語検索サービスである thesaurus.com を見つけたので検索してみる。 “Simple” 類義語の真ん中あたりにあった単語 “Light” … これだ!

思い返してみれば、特にiPhoneアプリ界隈で、本来有料で販売するアプリの無料体験版として “〜 Light” を名乗っているアプリを何度か見てきた。「機能を制限」かつ「本当は派生的な位置付け」を意味する単語として “Light” は最適な意味を持つ。かくして「簡易アプリ」は “Light Application” としてスタートを切った。

まとめ

  • 日本語のコンセプトをきっちり表す英単語を見つけるのは意外に難しい。例えそれが、結果的に日本での知名度がかなり高い単語であっても。
  • アプリ開発業界に於いて “Light” という単語は独特の地位を築いている。すなわち、「機能制限版」かつ「派生的な存在」であることを一気に表せる唯一の単語である。

ということで、特に技術的に苦心したというほどでもないが、個人的に発見だったので記しておく。これから少しずつこんな感じで記事を書いていきたい。