会社ブログで記事を書いた8

9/7-11の4泊5日でRubyKaigi 2022に行った、という記事を書きました。

developers.bookwalker.jp

あと、会社の許可とか取ってなかったので↑の記事には書いてないんですが、pixivさん主催の懇親会の Ruby Music Mixin 2022 - connpass でDJしたりしてました。

www.mixcloud.com

という感じで、ootd前はかけたい曲を数曲、くらいしかリストアップできていなかったのでセトリは実質10/6だけで組みました。

アイマスonlyのDJイベントではなかったので当初はアイマス色を薄めていこうかと思っていたんですが、急いで組まなきゃいけなかったこと、pixivさんの主催のかたがアイマスとイノタクと電音部とあたり大好きということだったので結果的にはいつもの感じになりました。

RubyKaigiそのものでも、Ruby Music Mixinでも、旧交を温めたり、新しい色々な人と話せたし、楽しかった! 次の松本も楽しみです。

会社のブログで記事を書いた4〜6

前回の記事 以降更に3本書いてました。

CircleCIからもAWS APIへアクセスキーなしでリクエストできる仕組みをTerraformで構築する

developers.bookwalker.jp

主にバックエンド方面のアプリケーションがCircleCIでCI/CDしていたので、この記事で予告されていたCircleCIのOpenID Connect対応をずっと待ち望んでいました。

先にGitHub Actionsで同じことをしていたのでそれをベースに、CircleCIのOIDCが土曜の26日にリリースされてから(土日に手を付けたい衝動を我慢しつつ)、明け月曜の28日にすぐ取り掛かって、29日にはマージ、その日のうちに記事を書いて30日に公開という超速スケジュールで進めました。どうしてもやりたかったのでスプリントに積むストーリーとは別に自分の余裕時間を使いました。

結果、CircleCIさんの公式twitterでも取り上げていただいたので完全に狙い通り。

一迅プラスのインフラ構成について

developers.bookwalker.jp

一迅プラスは会社のプロダクトのなかで一番新しいので、今新規で組むなら、という観点でずっと書きたかったやつ。

受託なので当然一迅社さまに許可をいただく必要があり、許可を出していただいたのでありがたい限りです。

この時からまたアップデートが一部あるのでそれもまた書きたい。

UTF-8で動くRailsShift_JISな外部システムと通信する方法

developers.bookwalker.jp

文字コード、日本語を扱ううえで避けては通れない複雑な歴史の産物。

こういうことをする必要がある箇所はそんなに多くはない、というか今のところ1か所だけなんですが、この場面に遭遇する人はいくらかはいるはずで、そういうときにまとまった情報が無かったので今回書いた、という感じでした。

Rails Shift_JISGoogle検索すると1件目に出てくる1ので、それなりに有用な記事にできたんじゃないかなと自負しています。

この記事を書く以前だと、ヒットするのが

monmon.hatenablog.com

とか

blog.pentagon.tokyo

とかで、これはこれで間違いじゃないんだけど、Shift_JISであることがあらかじめわかっているならActionController::ParameterEncodingが使えるよ、という。


  1. 普段使わないEdgeのシークレットモードでやってるのでパーソナライズ関係ないはず

ミリシタ5周年イベントで律子16位になった話

はい。 今年もミリシタ周年イベントお疲れさまでした。

今回は7/2に秋葉原MOGRAでアイマス系DJイベントに出演していたり、初星演舞以来4年以上ぶり、待望のAS単独ライブであるSUNRITCH COLORFULなどがあったので、1桁は狙わず2桁に抑えておこう、と最初から決めていました。

とか言ってたにもかかわらず走りすぎて律子16位でした。

今回のptとアイテム数の推移はこちら。

イベント前にPレベルが481になって元気ゲージが最大200になっていたこともあり、ジュエルは差し引き36685しか使用しませんでした。 結局有償ジュエルの追加購入はしていません。

前述の理由もあって今回はリフレッシュタイム前後のスクリーンショットをあまり撮っていなかったためグラフの点の間隔がガタガタですが。

走れば今回も100位以内に余裕で入れるだろうと確信していた1し、ただ2mixを叩き続けるのも虚無だったので、今回は3周年のときに一緒に走った友人たちと0時から2時のリフレッシュタイムまでの2時間程度の長さ、という縛りでAmazonのPrime Videoウォッチパーティで映画を観ました。

ので、今回の記事はその見た映画についての感想が中心になります。

7/2 「世界侵略 ロサンゼルス決戦」★★★・・

この映画三昧の言い出しっぺの友人が陸軍版バトルシップ、という触れ込みで流したもの。

過去に地獄の戦場から一人だけ生還し、部下を見捨てた男として白い目で見られていた主人公が、エイリアンの襲来に際して新米上官のもと、部隊を率いざるを得なくなり…みたいなやつ。

まあ、面白かったと言えば面白かったのかもしれない。 これが以降の基準になった。

7/3「エクスペンダブルズ」★・・・・

ハリウッドのアクション映画俳優であるシルヴェスタ・スタローンが主演と監督を両方やったという作品。 僕はスタローンの出演作を一つも見たことがない。

なんというか、暴力!!女!!という感じで僕には合わなかった。

7/4「実写版シティハンター」★★★★★

散々評判は聞いていた、実写版シティハンター

これは評判に違わず面白かった。 監督主演のフィリップ・ラショーがシティハンター好きすぎて北条司さんに企画書と脚本を持ち込んで許可取っているという時点で既に好印象なのだけれど、映像としてもちゃんと冴羽獠していてカッコいい。

実写で冴羽獠をやろうとすると、ともすれば女性の依頼人に対して鼻の下を伸ばす冴羽獠、みたいな部分からなんというか、押しつけがましいセクシーさ、みたいな感じになって白けてしまわないかというのが不安だったけど、脚本の妙でそこも抑えられていて、ちゃんと笑えてカッコいいアクション映画になっていた。

7/5「ピクセル」★★・・・

オタクがオタクのまま世界に承認されたい、という欲望がそのまま表出した映画。 序盤で二人の主人公をかなり惨めに描いている割に、その惨めさを克服するわけでもなく、オタク的に熱いみたいな展開があったかというとそうでもなく、なんとなく世界に認められた、みたいな感じになっていったので非常に腑に落ちなかった。

7/6「テルマエロマエ」★★★★・

これも散々評判だけは聞いていたテルマエロマエ。これはやはり阿部寛主演という時点で勝ち。 筋書きも無難に面白かったと思う。

続編は微妙という話なので見ないでおこうと思う。

7/7「超高速!参勤交代」★★★・・

これだけ昔映画館で見たことがあった。 友人たちはもっとコメディコメディしたものを期待していたらしいが、意外とイイ話で終わるというか、笑える、というよりはスッキリとした読後感というか、イイ話ダッタナー、という感じで終わる映画。

7/8「変態仮面」★★★・・

映画がどうとかじゃなくて原作も含めて作品としてそれほど好みではないのはそうなんだけど、実写化に当たって中途半端にせずここまで振り切ったのは素直に凄いと思う。

7/12「劇場版シンカリオン」★★★★・

シンカリオンTVシリーズ見てないのだけれど、親子で見に行くことを想定して作られているので小ネタかつ古ネタがちょいちょい挟まる。

筋書きも無難に無難で面白く見れた。

7/13「プロメア」★★★★・

数々のお姉さま方を関係性の熱狂の渦に巻き込んだと噂に聞くプロメア。

僕はそういった方向の嗜好はあまり持ち合わせていないが、この辺なんだろうなぁ、というのはあった。

僕はというと、歌舞伎の見栄とか、ガイナ立ちとかそっちで「キターーーーーーー!!!」とか言ってました。

この作品については脚本の整合性、とかそういう話に突っ込むのは野暮というか、カッコイイのでそれでヨシ!という感じ。

まとめ

dアニメストアの契約期間が2022/7/28時点で95ヶ月だったり、それ以前も含めるとアニメは見まくっている2のだけれど、映画は映画館に足を運ぶのが億劫でなかなか見れていなかったので、こういう機会にアマプラの観放題作品限定とはいえ見れたのはよかった。

たぶん来年もこの鑑賞会、やると思います。

ともあれ、アイドルマスターミリオンライブ シアターデイズ、5周年おめでとうございます。

5周年ニコ生のときに言及があった、各アイドルを個々のアイドルとして中心に据えたプロデュースモード、期待しています。


  1. 実は4周年イベントのとき24位だったのだが、そのときはあまりにも余裕すぎて書くことがなく、記事が下書きのままになっている

  2. 覚えている限り記録したAnnictによれば466作品。映画とTVシリーズが混ざっているので、作品数のカウントとしてはいささか微妙なところだが… フサギコ (fusagiko)が見たアニメ | Annict

会社のブログに記事を書いた 3

developers.bookwalker.jp

タイトル入れるだけでイイカンジになるサムネイルテンプレートを作ったので、これでサムネイルに悩まなくて済む。

このOpenID Connectの話自体は本当に

が最速でtwitterで話題になってた当初から気になってはいたのだけれど、これを仕事のterraformのリポジトリに反映させられたのは2022年1月下旬くらい。

これで新しいコンポーネントに対する継続的デプロイの設定がかなり楽になったのでこういう楽さをもっと高めていきたい。

有料のウイルス対策ソフトを買う必要はあるのか、ないのか

最近友人たちとの間で、マルウェアのEmotetが最近流行している、という話から有料のウイルス対策ソフトを買う必要はあるのか、ないのか、という話に発展したのでその時に話した内容のメモというか再整理。

有料ウイルス対策ソフトは「コンピューターウイルスに感染するかもしれない」という不安からお金を取っている

と書くと表現が意地悪すぎるかもしれないが、要は保険と同じである。

平時はほとんど1役に立たないが、何かあったときに被害の増大を防いでくれる、あるいは何かが起こりそうなときに止めてくれる。
要するにユーザーのリスクを減らしてあげることによって売り上げを立てている。

極論、コンピューターウイルスの被害に遭いたくなければそもそもコンピューターを使わなければいい

しかし、それはコンピューターとインターネットから得られる全ての利便性、メリットを享受できないということでもある。

例えるなら「詐欺師が怖いので訪問者に対して家のドアは一切開けません」と言ってるようなものだ。

「消防署の方から来ました」と言う詐欺師もコンピューターウイルスも、家のドアを開ける( = 拡張子を隠したexeファイルやExcelのマクロといった形で実行してしまう)まではあらゆる手段を使って騙そうとしてくる。

どうにかしてウイルスを実行させようとする以上、どうしても手段には一定の特徴2がでざるを得ず、それを頭の片隅に置いておけば実行する前に気付けることもある。

なんにせよ、そういった注意、確認でも減らせるようなリスクを怖がるあまり、そもそもコンピューターを使わないという選択は、インターネットが普及しきったこの現代ではあまりにもデメリットが大きすぎる。

ウイルス対策ソフトはどのようにしてウイルスを検知、防御しているのか

既知のウイルス

既知のウイルスは既知なので、実行する前に検出するのもファイルのビット列としての特徴3をスキャン対象と見比べるだけでよく、それなりに簡単である。
検出率を高めるためには、未知だったウイルスの特徴をいかに素早く反映するかが問われるということになる。

例えるなら指名手配犯の顔写真と見比べて止めているようなもので、Windows Updateでたまに見かける「Microsoft Defender Antivirusのセキュリティインテリジェンス更新プログラム」というのはこの"指名手配犯の顔写真集"の更新である。

未知のウイルス

未知のウイルスはというと当然だが"指名手配犯の顔写真集"には載っていないので、事前に検出して全て止めるのは無理4である。

ではどうするかというと、ウイルスにありがちな動作を検知して防御する5
例えるなら泥棒にありがちな動き、建物の裏に回ろうとする、とかを見つけて止めるようなものである。 ただしあくまで動きを見て止めるものであるため、稀に誤検知して問題ないプログラムまで止めてしまう場合がある。

また、動きを見て止めるということはプログラムの一挙手一投足を監視するということであって、CPUをその監視に使う分、本来やりたかったソフトの処理は時間がかかることになる。 もっとも、Microsoft Defenderでもこういったプログラムの動きの監視はしているので、有料のウイルス対策ソフトを入れたときだけ殊更に遅くなるというわけでもない。

では実際、無料のMicrosoft Defenderでどの程度コンピュータウイルスを防げるかというと

既知のウイルスに関する検出率、防御率についてのレポートがこれなのだが、この表の各列は左から順にオフライン時の検出率、オンライン時の検出率と防御率、誤検知数である。

オフライン時の検出率については今はそもそもオンライン時の話をしているので対象外として、"顔写真"で実行前に検出できたものを検出率、検出できなかったが実行されてから止めることができたものを防御率と呼んでいるものと思われる。

オンライン時の検出率の時点で既にかなり優秀だが、他の専業の有料ウイルス対策ソフトのいくつかはMicrosoft Defenderを上回っている。さすが専業である。

防御率はというとこちらはもはや専業の有料ウイルス対策ソフトと比べても誤差と言える。誤検知もわずか1。 こういう検査というのは普通、検知漏れ(偽陰性)を減らそうとして敏感にすればするほど誤検知(偽陽性)も増える6ものなのだが、これほどにまで検知漏れも誤検知も少ないというのはかなり優秀だと言える。

ここまで優秀だと無料なのに防御率が高すぎて逆に少し怪しく思えてきてしまうが、単にWindowsでコンピューターウイルス被害に遭う人が増えるとWindowsを使う人が減って商売あがったりなのでそうならないための投資 & 社会貢献という扱いなのだろう。

結局、有料のウイルス対策ソフトを買って得られるメリットとは

安心感と、守ってくれなかったときに文句を言う権利が買える。

文句を言う権利が買える、なんてふざけているのかと言われるかもしれないが、僕個人としては結構重要だと思う。

無料でサービスを享受しているあいだは、サービスに要望を出す権利はともかく、サービスに文句を言う権利まではないと思う。
稀によく見るあのラーメンの漫画の、「『金を払う』とは仕事に責任を負わせること、『金を貰う』とは仕事に責任を負うということだ」7である。
当該の作品では「金の介在しない仕事は絶対に無責任なものになる」と続く。Microsoftの場合、前述の通りWindowsでコンピューターウイルス被害に遭う人が増えるとWindowsを使う人が減るだろうということで間接的に利益を得ているので無責任な仕事はしないだろうとは思いつつも、無料である以上、やはりその仕事に責任を負わせることはできない。

サービスを無料で享受している以上、無料の"サービス"の範囲を超える、ここではすなわちMicrosoft Defenderが防御しきれずマルウェアの被害にあってしまった場合のことだが、文句を言う権利はなく、自己責任と言われても仕方ない。

ほとんどの有料ウイルス対策ソフトは1年あたりに換算すると高くても5000円程度である。
さて、この「安心感と、守ってくれなかったときに文句を言う権利」に対してお金を払うか?払わないか?

このメリットと対価のどちらを大きく見るかは人によって異なるので、僕はどちらがいいと断定的には語らないことにする。


  1. 既知のウイルスに感染していないことを確認できる程度の役には立つ

  2. 「ゲームを作ってみたという友人(がウイルスを実行してしまっており、その友人になりすましてメッセージを送ったウイルス)からゲームのテストプレイをお願いされる」とか「懸賞に当たりました!とか言われてカウントダウンを表示され焦らされる」とか「仕事で使うzipファイルに見せかけて『パスワードは〇〇です』などの文言と一緒に送られてくる」とか

  3. ウイルス定義ファイル(パターンファイル)とは - IT用語辞典 e-Words

  4. ちょっと改変しただけだったりすると部分的に一致して事前検出できたりもする

  5. ヒューリスティック検知(heuristic scan)とは - IT用語辞典 e-Words

  6. ウイルス対策ソフトに限らず、新型コロナウイルスの検査であるとか、Googleをはじめとした情報検索システムのような、真か偽か判定するもの全般に言える。情報検索システムの分野においては"検索性能"をF値またはF尺度という値で評価されることがある。F値についてはこのブログ記事がわかりやすい。新型コロナウイルスの検査では偽陰性の数がわからないのでF値は計算できない。

  7. 引用するだけでお金を落とさないのは筋が通らないというのと単に気になるというのもあってとりあえず、第一巻を電子書籍で買った。このセリフが何巻に出てくるのかは知らないが。

会社のブログに記事を書いた 2

またしても書きました。

developers.bookwalker.jp

会社でやっていることを書けるのは会社ブログだけ。 それを引用しつつ自分がやった範囲を書けるのは自分のブログだけ。

読書メーターは僕が当時のトリスタに入って最初に関わったサービスでした。 そのためまずトリスタの文化に慣れながら、開発サイクルに慣れながら、読メのインフラ構成やアプリケーションコードの構造を把握しながらという感じだったため、ニコニコ漫画ほどかかわった範囲は大きくありません。

スプリントに積まれた、すなわち仕事としてやるべきタスクとしては主にweb frontendで特設ページ1を組んで公開したりするのがほとんどでした。

その一方で、スプリントには積まれていない、個人研究として下記のことをやりました。

  • 手動で作られていたAWSリソースを全部Terraformに書き起こした
    • Elastic Beanstalkは書き起こしが困難だったので、ELBなどはECS(Fargate)への移設時にTerraform管理下になった
  • web frontendにReact + Typescript + CSS module + Webpackを導入した
    • SP表示の一部をReactで再実装した
  • manageとsub backendをElastic BeanstalkからECS(Fargate)へ移設した

これらはいずれも、スプリントに積まれたタスクを実装する際に、その効率があまりにも悪すぎたり、構造の再現や把握があまりにも難しかったために我慢しきれなくなってやったものです。

Terraformへの書き起こしについては過去に書いた記事が存在します。 developers.bookwalker.jp

もっとも、Reactでの書き直しについては途中でニコニコ漫画のAWS移設と新バックエンドに注力することになった結果として、 ある程度の書き方は確立したものの総量としては道半ばにも達せていない段階で現在も担当しているエンジニアに託すことになってしまっているのが少々心残りではありますが…

ニコニコ漫画や一迅ブラスでの経験を読書メーターにもフィードバックしていきたい気持ちはある。

会社のブログに記事を書いた

書いてました。

developers.bookwalker.jp

会社でやっていることを書けるのは会社ブログだけ。
それを引用しつつ自分がやった範囲を書けるのは自分のブログだけ。

この記事のうち僕が直接関わったのは

  • TerraformによるAWSリソースの構築
    • 現行PHPについてのEC2インスタンス群、ELB群
    • React用BFFについてのIAMロール、ELB
    • 新バックエンドについてのIAMロール、ELB
    • 課金サブシステムについてのIAMロール、ELB
    • Elasticache
    • 現行PHPと新バックエンドが使うAurora
    • それらの間のセキュリティグループ
    • S3バケット
  • 現行PHP
    • ドワンゴデータセンターからAWSへリフトするにあたっての計画概要の立案
  • React用BFF
    • ecspressoの設定およびECSのサービス定義、タスク定義
  • 新バックエンド
    • ecspressoの設定およびECSのサービス定義、タスク定義
    • 初期構築から2020年末ごろまでのアプリケーションコード
  • 課金サブシステム
    • 小規模な機能追加
    • Elastic BeanstalkからFargateへの移設
      • ecspressoの設定およびECSのサービス定義、タスク定義

あたりです。もちろん全部ひとりでやったわけではありませんが。

関わっていない部分は

  • TerraformによるAWSリソースの構築
    • 現行PHPのジョブキューとして使われているSQS
    • 新バックエンドが使うDynamoDB
    • 新バックエンドのオートスケーリングの具体的閾値調整
    • 課金サブシステムが使うAurora
    • それらの間のセキュリティグループ
  • 現行PHP
    • アプリケーションコード全般
  • React用BFF
    • アプリケーションコード全般
  • 新バックエンド
    • 2021年以降のアプリケーションコード
  • 課金サブシステム
    • アプリケーションコードの大部分

あたり。

こうやって書き出してみるとむちゃくちゃ色々やったなぁ、という気分になるんですがそれでもまだ課題はたくさんあるんですよねー

ニコニコ漫画の旅は続く。