portal shit!

契約中のサービス

Apple Music

何度も一ヶ月だけ契約して試しては解約し、を繰り返していたけど、 Circle 2018 に行ったあとに出てた人たちの音楽をまとめて聞きたくなって契約した。全部アルバム買うと 2, 3 万になるのがファミリープランでも 1480 円/月で済むのはいい。人間は音楽を買ってもそのうち聞かなくなる。聞きたい間だけお金を払うのが正解なのかもしれない。

ただ有名ミュージシャンの曲や懐メロのオリジナル版は相変わらず Apple Music にはなくて（カバーはいっぱいある）買わないといけないので注意が必要。ゴレンジャーの曲とか聖闘士星矢の曲のオリジナル版は iTunes Store で買った。

Spotify にしない理由は macOS や iOS との統合された使い勝手を重視しているから。たまに切り替えて使ってみるのもよいかもしれない。

Netflix

深夜食堂を見たくて入ってる。その他、アメリカのドラマも時々見る。電車の中で見たいけど結構エロシーンが多くて困る。イギリスのクッキング対決番組も面白い。とはいえ元とれてる感じはしないので Rebuild で話題になるドラマなんかをさっと見て解約したい。

Amazon Prime

Amazon のクレジットカード（ Master ）の特典で付いてくる。様々な割引を組み合わせたカードの年会費が 3940 円でプライム年会費と同じ。 Master カードはコストコでの支払いにも使えるようになったので便利。 1% ポイント還元。

Prime ビデオに関しては割と頻繁にラインナップの見直しあってて見たいやつがなくなるので見られたらラッキーくらいのつもりで利用しないと逆にストレス溜まる。

The Old Reader

RSS リーダーの中で最安なので使ってる。検索が厳しい。たぶん全文検索エンジン使ってなくて DB から LIKE サーチしてる気配を感じる。 Inoreader に乗り換えを検討した方がよいかもしれない（ Feedly は好きになれない ）。

さくら VPS 2GB プラン

このブログを動かしている。まぁまぁ高いが AWS や自宅サーバーで運用するのに比べたら十分経済的。

AWS

Route 53 と S3 、 CloudFront のみ利用している。 毎月 200 〜 300 円くらい。

解約したサービス

GitHub private repo

Microsoft に買われて自分ごときの金なしおじさんが利用料を払う必要もなかろうと思い解約。大したコード上げてなかった。秘密情報的なやつは GitLab に移した。

Flickr Pro

自己顕示欲を満たすために人に写真を見せる、ということがなくなったので解約しようと思っていたが、 2 年おきの更新なのでうっかりしてて 2020 年まで自動更新されてしまった。とりあえず自動更新を停止にした。

iTunes Match

Apple Music に移行したので自動更新を停止した。

Facebook にウェブサイトの URL をはっつけるとき参照される HTML メタ情報の仕組みに Open Graph Protocol ってのがある。 Facebook に URL を貼ると bot が URL の内容を読みに行ってページの概要や画像を取得し Facebook 内に埋め込み表示するというもの。 Facebook を見ている人はリンク先の内容をクリックする前に概要を把握できるので、リンクをクリックして見たい情報じゃなかった、ということを避けられる。 Facebook が考案して策定した仕組みだけど、 Facebook に限らずいろんなサイトで OGP タグを出力してるし読み込んでる。 Twitter にも似た仕組みあって Twitter Card という。この辺の対応は結構前にやってた。

アドベントカレンダーに備えて Open Graph protocol に対応

昨日飲みに行って今朝起きてからふとコード書きたくなって、アドベントカレンダーもあることだし（去年の Adventar で自分のブログだけ og:image がなくて画像が出てなくて残念だった）、...

portalshit.net

ただ自分のサイトが OGP タグを提供するだけではつまんないなと思ったので自分のブログにペロッと URL を貼ったときに相手先に OGP タグがあればそれを出力するようにしてみた。こんな感じ。

しかしここで困ったことがあって、↑でリンクしてる Circle のサイトは HTTPS で配信されておらず、単純に Circle のサイトで og:image に指定されている画像を SSL 化されているこのブログで読み込むと Mixed Content になってしまう。せっかく HTTP/2 で配信していたのに台なしになってしまう。またそもそも og:image は Facebook でシャアされることを想定されていることがほとんどなので、画像サイズがデカすぎていい感じにスクエアに表示するためには CSS の小技を駆使したりする必要があった。

いい感じに解決する方法ないかなと調べていたら良いのが見つかった。

GitHub - willnorris/imageproxy: A caching, resizing image proxy written in Go

A caching, resizing image proxy written in Go. Contribute to willnorris/imageproxy development by creating an account on GitHub.

github.com

Go で書かれた Image Proxy Server で、 HTTPS Proxy は当然のこと動的リサイズもできる。使い方は簡単でバイナリを落としてきて動かすだけ。 Go なんで ImageMagick をどうしたりとかを考えなくて良い。 そもそも Docker イメージも提供されているので Docker をインストール済みなら docker run するだけでも動く。 めっちゃお手軽。

こいつのおかげで HTTPS で配信されていないサイトの OGP タグを読み込んでも Mixed Content にならずに済むようになった。また og:image は適切にリサイズできるようになった。画像変換サーバーとかは結構難しいやつで個人のブログでこんなに簡単に使えるものだとは思ってなかったので正直ビックリした。

AWS の登場で大企業じゃなくても CDN 使ったり仮想サーバーでウェブシステムを構築したりできるようになった。さらには Go や Docker といった技術のおかげで複数の込み入ったソフトウェアを組み合わせて構築していく必要があったシステムが、まるで jQuery を使うような感覚でポン付けで使える時代になってきている。とても素晴らしい。

ちなみに OGP の取得には open_graph_reader という gem を使っている（昔からある opengraph という gem はメンテナンスされておらず最近の Nokogiri で動かない）。 open_graph_reader の作者が結構 Opinionated な人で、以下のような Anti-featurs を掲げている。

http://ogp.me/ の仕様に準拠していないサイトのことは完全無視というつくり。個人的にはこういう思想は好みだが、現実問題として使い勝手が悪い。例えば hitode909 さんのブログの OGP タグを取得しようとしたところ以下のようなエラーを出して取ってくれなかった。

article:published_time は ISO8601 形式の datetime であるべき、とのこと。はてなブログはかなりシェアが大きくリンクする機会が多いので残念。

以前、 AWS ECS で試験運用したことがあったので Docker 化自体は済んでいた。 ECS などマネージドコンテナサービスを使わずに Docker 運用ができないか試してみた。

動機

関連記事の更新処理、諸々障害があって自動化できておらず、 DB を clone してきて手元で実行してサーバーにエクスポートするという運用が続いていた。これを自動化したかった。

⛓TF-IDF で関連エントリーを表示

cho45氏の手法を参考にLokkaにSimilarityモデルを追加し、MeCabで名詞を抽出してTF-IDFを計算、ベクトル正規化して類似エントリを検出・保存するRakeタスクを実装した。並...

portalshit.net

二つ問題があって、以下の通りだった。

1. 関連記事の更新処理時に日本語の分かち書きをする必要があるが、 VPS インスタンスのメモリ上限があり MeCab の拡張辞書をサーバー上でインストールできない
2. VPS 上で SQLite の算術計算を行うためには追加拡張が必要で、そのためには SQLite をソースコードからコンパイルする必要がある

1 は Docker イメージにして手元でイメージをビルドすれば解決できた。 2 の問題も Docker のなかでコンパイルを行うことで解決できた。

どうやるか

• nginx.conf の修正
• コンテナの create
  キャッシュのためにファイルシステムを利用しているのでホストとコンテナで public ディレクトリを共有する必要があった。

docker create \
  -e DATABASE_URL=db_url \
  -e RACK_ENV=production \
  -v /home/morygonzalez/sites/portalshit/public:/app/public \
  -p 3001:3001 --name portalshit -it morygonzalez/portalshit bundle exec puma -p 3001

• コンテナの起動

docker start portalshit

結果どうだったか

サイトを Docker で公開することはできたが、 docker create して docker start するまでの間、ダウンタイムが発生する。

ダウンタイムなしで deploy するためには deploy のタイミングで Nginx conf を書き換えて service nginx reload する必要が出てくる。個人のブログレベルでそこまでやりたくない。

コンテナを管理するサービス（ AWS ECS や Kubernetes ）があるんだったら Nginx conf の書き換えなどしなくてもいい感じに deploy できると思うが、こちらも個人のブログレベルで使うものではないと思った。

結論

• サイトの deploy はこれまで通り cap で行い、 puma はホスト OS で普通に動かす（コンテナ化しない）
• 関連記事表示のバッチ処理のみコンテナ化することにした

会社でプロジェクトのふりかえりをしていて自分でエモ発言をしてしまって結構いい話だと思ったのでブログに書いておきます。

新しいプロジェクトを始めるとき、誰しもナウでモダンなフレームワークや技術を使いたいと思うだろう。しかし、 Qiita でみんながその技術についての記事を書いてるから、他の会社の友だちがそのフレームワークを使っているから、という理由で技術選択をしてはいけないと思う。新しいものを使うな、という話をしているのではない。社内によく知ってる人がいない技術を自分の意思で取り入れるからには「覚悟」が必要だという話。わからない挙動に遭遇したときにフレームワークのソースコードを読んで問題を解決したり、バグを踏んだときに修正する Pull Request を送ったりする気概があるか、という意味だ。自分以外の人がそのコードを触るときのためにユニットテストのカバレッジを高く保つということも「覚悟」に含まれるだろう。

その話をしていたらジョジョの奇妙な冒険に有名な台詞があるということだったので、 Slack で覚悟と入力したらその画像が表示されるようにしておいた。

「覚悟」とは!!
暗闇の荒野に!!
進むべき道を切り開くことだッ!

[B! リモートワーク] リモートワークのストレス | POSTD

この記事に対して146件のコメントがあります。注目されているコメントは「寂しがり屋と真面目君はリモート向いてない」、「リモートワークって、ペアプロやモブプロが推奨されるアジャイルや、少人数で効率よく検証・開発のサイクルを回すリーン的な働き方と相性悪いと思ってる。」、「たまにリモートにするぐらいが丁度良い派」、「7割はチャットの下手さが理由だと思う。対面での会話が得意すぎるとも言うが。」などです。

b.hatena.ne.jp

リモートワーク別に寂しくないし楽勝、みたいなコメント多いけど違和感あった。リモート楽勝という人はフリーランスとか受託の会社の人なのではないかと思う。自分のブックマークコメントは以下。

激しく同意。雑談したい、家族から家事を頼まれる、オフィスにいる連中から事業理解が低いと責められる、毎日服を着替える能力や通勤電車に乗る能力が失われる、などなど — http://b.hatena.ne.jp/morygonzalez/20180309#bookmark-359971190

「こいつはわかってない」問題

自分の場合は事業会社に所属した上でのリモートワークだった。事業会社（大抵のスタートアップもこれに含まれるはず）の場合はソフトウェアエンジニアにも事業やプロダクトへの理解が求められるので、リモートだとなかなか厳しい部分がある。事業理解は日々の MTG の他、オフィスで何気なく交わす雑談や昼飯の時なんかに醸成されるものだと思うので、リモートだと MTG での情報伝達密度が下がるし雑談や昼飯に至ってはそもそも不可能なので自分自身の事業理解も深まらない。仮にこちらに事業に対する理解があったとしても、それをオフィスにいる連中に伝えることが難しいので結局「こいつはわかってない」という烙印を押されることになる。リモートワークやってて同僚のエンジニアの皆さんとは友好関係を築けたと思うけど、 PM や上司とはなかなか良い関係になれなかった。

家庭内で仕事が軽んじられる

家族がいる人の場合は家族が「こいつ家にいてあんまり忙しくなさそうだから家事を頼もう」ということになりがち。自分の場合は子どもの幼稚園の送り迎え（バス乗り場まで）、幼稚園から帰ってきたあとの子守、洗濯物干し・取り込み、などを頼まれることが多かった。配偶者も仕事をしていて家事を分担する、ということなら当然やるけど、我が家の場合は嫁さんが習い事やヨガで忙しいので家事をやらなければならない、という感じで、自分の仕事は嫁さんの習い事よりも優先度が低いものなのだろうかと悶々とした。

社会適応能力の低下

毎日身支度をする能力、出かけていく能力も確実にむしばまれていく。転職してリモートワークからオフィスワークに切り替えて、朝の混んでる時間の電車に乗る通勤生活を再開してからの数ヶ月間は肉体的にも精神的にも非常につらかった。また家で仕事してると出歩かないので当然に運動不足になる。自分で意識してジョギングしたり体を動かしたりしないと確実に健康を損なう。

自分がリモートワークに対して否定的な見解を持っているのは以上のような背景があるのであった。

良い面もある

もちろんリモートワークには良い面もある。

ワークライフバランス

子育てのための一時期や家族の看病が必要な時期には非常にありがたい制度だと思う。ワークライフバランスは非常に良好になる。

集中維持

コード書きに集中したいときにもリモートワークは便利だった。リリース前など、移動の時間も惜しんでコードを書きたいときには朝 10:00 から夜の 24:00 頃まで風呂とトイレと飯の時間以外はずっと仕事してたこともあった。それでも 10 時間は時間が空くので十分睡眠をとることはできる。これも前にブログで書いたような気がするが、いつでもオフィスに仕事しに行ける環境で、自分の裁量で週に数日リモートで仕事をするのが一番満足度の高い働き方になると思う。

地方都市に暮らしながらデラウェア法人で働ける

あとそもそも福岡では前職のような数十億円規模の資金を調達してがつんと成長しようとしているスタートアップの仕事にありつくことなんかは不可能なので、田舎に住んでいても都会のイケてる手法で仕事できてたのはリモートワークならではだったと言える（これも元記事に書いてある）。いまの職場でやってることは前職で身につけた¹もの（スタートアップで働くエンジニアのディシプリン的なもの、あるいは技術顧問おじさんの素養）を土台にしているので、これは非常にありがたかった。

まとめ

ひとくちにリモートワークといってもいろいろな形態、状況があるので、↑の記事のブコメのように「リモートとか楽勝じゃね？」というコメントを読んでうかつにリモートワークを始めようとしている人がいたとしたらちょっと踏みとどまってもらいたいし、自分に向いているか、勤務先のビジネス領域・ビジネスモデルなども加味した上で決めてもらいたいと思う。

あとリモートワークだとコードレビューが甘くなりがちではないか、という問題もあるけどそれはまた別の話かもしれない。

リモートワークしてた頃、コードレビューの指摘・修正往復を沢山したくなくて（修正してもらった後にさらに注文つけるのきつい）、本当は修正して欲しいけどLGTMすることあったけど、オフィスで仕事してると追加の指摘をしたあとに口頭で補足説明できるので割と納得できるまでレビューできる気がする。

— morygonzalez (@morygonzalez) March 8, 2018

References

• リモートワークのストレス | POSTD 翻訳記事
• The Stress of Remote Working – Hacker Noon 元記事
• Kaizen Platform という会社について - portal shit!
• リモートワーク - portal shit!

Hush-up houndci-bot by morygonzalez · Pull Request #232 · lokka/lokka

Let @houndci-bot shut his big mouse up What I did Add Rubocop and HAML-Lint to Gemfile in order to check link locally. Add rules for Rubocop and HAML-Lint I guessed .rubocop.yml rules from Lokka&...

github.com

lokka/lokka 、 Pull Request を出す度に Hound CI のチェックが走って bot にコードレビューでぼこぼこにされるので、この bot を黙らせるべくガチャガチャやってた。 Hound CI のチェックルールは Rubocop に準拠しているようで、 2011 年からある Rack アプリを Rubocop のチェックにかけるのは面白かった。

Lokka 、意外と Hacky なコードが多く、条件式内での代入とか、ヨーダ記法とか、後置の until とか、スコープが広い一文字変数とか、めっちゃ長いメソッドとか、 if 文のネスト、代入したものの使われてない変数なんかを修正した。 method_missing はカスタムフィールドを定義できるという Lokka の仕様上根絶できなかったけど、 .rubocop.yml に最低限の除外ルールを追加して Rubocop のチェックはパスするようにできた。

Lokka 、 ORM が ActiveRecord じゃないことが問題だと思ってたけど、真の問題は lib/lokka/helpers/{helers,render_helper}.rb にビジネスロジックが詰め込まれてることだと思った。しかもこのあたりのコードの可読性がよくなく、触るのが怖い感じの複雑なやつが多い。この辺のコードをもうちょいクラス化して分割し、ユニットテストも手厚くしていかないと ORM を変えても F/E を今風にしてもウェブアプリケーションとして生存していくことは厳しいと思う。

前に進んでいくためにも Rubocop のチェックを入れる＆パスさせるのはプラスになると思う。 頑張ってメンテしていくぞ。

追記

この辺のコードをもうちょいクラス化して分割し

と書いたけど、 Rails と違って手軽にサクッと作れるのが Sinatra の良い所なわけではあって、仕事で作る Rails アプリのノリでクラスやファイルを分割したりするのは違うのかもしれないと思った。 Rails で作られたオープソースの CMS やブログツールに長生きし続けるものがないのも、 Rails の場合、個人が偶発的に始めてメンテ出来るようなものになりにくいからかも知れない。

とはいえヘルパーがビジネスロジックを所持しているのはテスタビリティやメンテナビリティが良くないので Lokka と心中する覚悟でやっていくぞ！！！、！

ツイッター歴10年を超え、どういうウプダテスをしたらファボをもらえるかはだいたい予想がつくようになってきたけど、それよりも前からやってるブログに関してはどうやったらバズるかがわからない。 mizch さんがブログを書く前にどのくらいブックマークが付くか想像できると言ってた気がする¹けどそういうのすごいと思う。「もうちょい反応あるんじゃないかな」と思った記事が全然伸びなかったり、逆に完全に自己満足のために書いた記事がバズったこともある。ツイッターもブログも商売と同じで読み手に価値を提供することができたら良い反応があるものだと思う。ツイッターに関しては面白ツイートで読み手に価値を提供できている（自分が面白いと思うものが読み手にとっても面白いと評価されている）のだろうけど、ブログでは価値を提供できていない（少なくとも狙ってはやれていない）のだろう。

短文で面白おじさんを演じるのは簡単だけど、長文だととても難しくなる。自分で自分が書いた過去の記事を読んでも「滑ってるなぁ」という感じしかしない一方で、たとえば寿司について書いた記事はいま自分で読んでも「攻めてるなぁ」と感じる。また仕事で社内ブログに記事を投稿してもそこそこ反響得られてるので文章を書く能力が著しく低いわけではないのだと思う。

つまるところ自分はブログで記事を書くときに、自分の興味関心とオーディエンスの興味関心を一致させられていないのだろう。ツイッターや社内ブログでは読み手が誰であるかを把握するのが簡単なので事前にコンテキストを共有した上で記事を書ける。コンテキストが共有されているのでどんな内容が受けるかを想像しやすいのだ。しかしブログの場合は誰が読むかは見当がつかない。パソコン関係の記事が受けるのか、日記的な雑文が受けるのか、蓄財についての記事が受けるのか、あるいはそれ以外か、全く見当がつかない。

15年前にブログが流行ったとき、ブログはテーマを絞った方がいいというアドバイスをよく目にした。思えばそれは読者の種類を絞り、読み手とコンテキストを共有することで記事を書きやすくするためだったんだろうなぁと思う。

自分はなんでもブログに書くスタンスでやってきたので今更書く内容を絞ったりはしたくないんだけど、今年は読み手とのコンテキストの共有を意識してインターネットしていきたい。