携帯電話のキャリア変更して総じて満足 冒頭にもあった通り、メインで利用している携帯電話のキャリアを au から ahamo に変更しました。（ 9 月末に） 金額面以外では不満はなかったのですが、家族割など色々とあってずっと契約していましたが、以下の理由で見直すことにしました。 そもそもデータ容量など利用していないのに想像以上に金額が高い Apple Care など契約しているのもあるけど 見直してもそこそこの金額 手持ちの回線が（個人で利用しているものでは） au 系の回線が多かった 冗長化の観点からあまり良くはない うちデータ専用回線は解約したが、旧来の povo 1.0 などもまだ残っている 家族もこのタイミングで見直し、家族割の効果が薄くなる 物価高の影響もあるが、格安 SIM などを使っても問題なさそうなことがわかった 楽天モバイルのデータ容量などでどれくらいの容量があれば良いのか気がつけた 以前よりも継続していることの意味がなくなっていること 変更して既に 1.5 ヶ月経過していますが、パケ詰まりなどの症状も出ておらず、快適に利用できています。 ahamo にした理由 費用を下げるだけであれば、 au 系だと povo や UQ mobile が挙げられます。あえて MNP した理由は docomo 系の回線を持っていなかったことです。 以前から冗長化していたのですが、 docomo 系の回線は持っておらず、 au 系がほとんどでした。（ahamo も持っていた時期はあるが、 povo 1.0 に変更） また、ahamo でなくても費用を下げるだけであれば、 OCN モバイルや IIJ mio という選択肢もありますが、ある程度のデータ容量を使い、速度も求めた結果です。 必要十分、20 GB あっても 7 GB 前後しか利用していない ahamo で契約しているデータ容量は 20 GB ですが、平均的に毎月 7 GB しか利用していません。...

一部現地開催はあったが、発展途上 & 実験段階 今回はある筋からお声がけもあり、広島独自企画として、 Git ハンズオンを広島フロントエンド勉強会の井上さんと広島Unity勉強会を主催している人の 3 人を中心として実施しました。 Git ハンズオンとしては成功したように思いますが、思ったよりトラブルが発生しなかったため、スムーズに進行できた印象です。トラブルも Zoom と確認用タブレットを駆使することではじめてのオンラインハンズオンにしては成功したと思います。 そして、来年以降ハイブリッドでの OSC 開催の足掛けにするためにも、今回の現地開催を行なうにあたって確認したかったことは以下の通りです。 ATEM Mini Pro を用いた配信が現実的にできるのか 通称ドリーム構成、YouTube Live と Zoom に同時配信する負荷のかかる構成 通常の OSC 方式（Zoom 経由）なら ATEM Mini のみで必要十分 ハイブリッドで行った時に Zoom との音声ミックスなど支障が出ないのか 機材的に問題ないのか 基本的には PC やルータなどは持ち込み（HDMI ケーブルなど細かなものも含む） カメラをはじめとする一部の機材はファナフェクト株式会社からお借りしました その他液晶ディスプレイは現地会場の備品 別な勉強会で実施した ATEM Mini Extreme ISO や ATEM Mini Pro を利用した構成が今回のベースです。構成自体は複数の有識者からレビューを受け、「できる」判断のもと行いました。 また、内容面で気をつけたこととして、質問内容の読み直しなど YouTube Live にしか参加しない人にもわかりやすくトラブルが発生した内容など端的にまとめるということも行いました。 キャリアセッションなど独自企画について 他の独自企画は例年やっていること、ベースということもありますが、実行委員会キックオフやミーティングなどで「これから活躍するだろう一年目」の社会人にフォーカスすることが早々と決まっていました。登壇依頼などが最後までギリギリ感否めなかったですが（土日の間にやっていたりしたこともあったので）結果的になんとかまとまってよかったのかな、と思っています。 一方で進行などが思った以上に淡々だったこともあり、この辺りは反省したり次年度以降何かしら対策を打つ必要があるのかな、と思っています。また、ポスターに関するセッションなどもハンズオン開催していたので聞けていないのが残念ですが、途中からおまかせできたのは改めてよかったのかな、と思います。 昨年の反省で述べていたことは多少は改善した 概ね一年前の私は以下の様な振り返りをしていたらしいです。 独自企画はもう少し早めの決断が必要だった コミュニケーションツールが多くて大変 一人で進めすぎた 最初の「独自企画の決断」は淡々と進めたこともありますが、企画よりも中身に力を入れたこともあり、人のアサインなども含めて決断はそれなりに早くできたのかな、と思います。一人でやるのがしんどかったので他の人に丸投げなども含め実施し、私の持分を減らす様には努力しました（概念） 一方で、コミュニケーションツールは改善されず、途中から Twitter DM なども駆使していたため、はやいタイミングで「Slack をみて欲しい」に移行すべきだと反省しています。（来年こそは減らしたい） OSC の対面での開催はまだまだか 来年こそは開催できればしたいと思っていますが、ハイブリッド形式などはまだまだ実験段階にあり、会場設備に依存していることもあるので、まだ先なのかな、と思っています。とくに、他の勉強会含めて気にしていることは以下の通り。...

Zoom を用いた半ウェビナー形式での実施 今回の勉強会では諸般の事情もあり、 Zoom を用いて開催しました。今まで、対面で行ってきた勉強会のフルオンライン化ということもあり、立ち上げについてはさまざまなテストを行いました。 基本的にはオープンソースカンファレンスのフルオンライン化されているノウハウをベースにしつつ、セキュリティ設定で誤爆しないよう調整を行いました。ウェビナーライセンスを使うことも考えていましたが、達成したいことができることなどから、普通のライセンス（100 名）で行うことにしました。 セキュリティ設定のフル活用 やりすぎ感否めないですが、今回利用したのは「 Zoom のセキュリティ設定」をフル活用しました。 具体的な要素を挙げると、以下の機能を意図的に無効化しました。 マイク OFF カメラ OFF プロフィール画像 OFF 上記の場合でも、登壇者などについては共有ホストに指定することでほぼ全ての操作ができるようにしていました。（ただし、全操作 OFF にした場合は話せなくなってしまうので、荒らしが入った時も手動で一つづつ操作が必要） 万が一に備えたリダイレクトするリンクの共有 これもあるあるですが、 Zoom のリンクではなく、リダイレクトのある URL を共有しました。あまり意味があるかは微妙ですが、リンクが変更できることで、何かしらのトラブルがあった時に（ URL がバレていなければ）正規の人のみアクセスができる仕組みです。 今回の場合、ショート URL にする必要がないので、 Zoom のミーティング URL は VPS （Oracle Cloud Virtual Machine）を用いて 302 リダイレクトにしました。ホストしてた Virtual Machine のスペックは AMD Compute VM ベースの 1/8 OCPU / 1 GB RAM　といった構成です。 bit.ly を用いる方法もあったのですが、再生成するためには費用が必要なことなどから短縮 URL ツールは利用しませんでした。（短いが故、総当たり攻撃される可能性もあるので） 運営側は神経を尖らせていた 本勉強会の運営およびスタッフは Zoom を用いたフルオンラインの勉強会に慣れていないこと、参加者数が多かったことなどから、「ちゃんと運営ができるか」「本当にこれで大丈夫なのか」という戸惑いなどがありました。 ある意味、構成図ややり方などは指揮しましたが、全体像はやってみないとイメージができていなかったこともあり、緊張しっぱなしだったのかな、と思います。 また、当日の最後の最後まで増員の判断など行ったりしたこともあり、準備途中から最後まで色々な判断を求められていました。 アニメーションの基本から実例まで知れる 3 時間 セミナーの内容としては、構成家がいるわけではなく、ワイワイとミーティングを行っていく中で、「こういう内容があった方がいいよね」というベースで決まってきました。その結果、（コメントを見る限りでは）満足度の高いセミナーになったのではないかな、と思います。...

オンラインでのイベント開催は多種多様 オンラインで開催されているイベントは非常に多く、いろいろな方法で開催されています。 登壇者やスタッフが集まって ATEM Mini Pro をはじめとする機材を用いた配信から Zoom を活用したフルオンラインの勉強会まで、さまざまな形態があります。 その中で、少し前に流行った Clubhouse に似たサービスとして、 Twitter Spaces を用いた勉強会や討論会、といったことに取り組んでみました。 ホストなどの操作は大きな端末のほうがやりやすい この記事を書いている 2022 年 8 月中旬の時点では、ホストや発言といった機能はスマートフォンが必要になります。 Twitter Spaces の役割を一覧は以下の通りです。 ホスト Spaces を管理する人。主催者。共同ホストの追加やスピーカーなどの指定や、 Spaces 名などの定義もできる。 共同ホスト Spaces を管理する人。スピーカーの指定などホストの補助的な役割ができる。 2 名まで指定できる。 スピーカー Spaces で発言できる権限を持っている人。共同ホストを含めて 10 人まで指定できる。 リスナー Spaces を聞いている人。参加するとリスナーに指定される。 基本的にはオンラインミーティングやフルリモートでの勉強会に慣れていると、なんとなく感覚は掴めるのですが、慣れるまでは時間がかかると思います。 スピーカーは端末をあまり選ばないのですが、運営をするのであればなるべく大きな端末のほうが操作しやすいと思います。 大きな端末の方が操作しやすい理由として、 Twitter Spaces のアカウント表示方法が関係しています。 基本的にはアカウントのアイコンを活用して操作を行うのですが、横に表示されるアカウント数が固定表示（ 4 アカウント）となっているため、小さな端末だと以下の観点から誤操作しやすい状況になります。 そもそもアイコンの大きさが小さい アイコンとアイコンの間が思ったより狭い 既に 2 回主催していますが、 iPhone 13 mini と iPhone 12 Pro MAX で開催した感じだと、 iPhone 12 Pro MAX のほうが操作しやすいと思いました。...

いろいろとワケあって対策はしていた 社会人になったころから常に複数回線を保持していました。当時は冗長化、というよりかは用途別に分けていただけですが、基本的には複数キャリアの回線を持っていました。 主にプライベート用とお仕事用で、実質データ回線の代わりに音声 SIM が刺さっていた状況だったのですが、色々と考えている中で「障害対策」を思い出しました。 そんなこんなで結果的に、全キャリアを網羅してしまったのですが、途中で Android と iPhone から iPhone 2 台体制になったりとしていますが、今でも複数のキャリアは保持しています。 障害が発生して、電話の大事さを痛感 私は通販だと Amazon をよく利用するのですが、 Amazon の 2 段階認証（多要素認証）は電話メインで認証していたので、非常に戸惑ってしまいました。 よくよく考えれば TOTP 方式（アプリ方式）もバックアップとして利用できるのですが、コピペの手間があり、慣れていることに対する不便さを痛感させられました。 また、バックアップ回線は全部電話のプランを従量課金にしていたので、土日かつ、実家に帰省していて、電話かけるオペレーションが変わるのは非常に困惑しました。 ただ、不幸中の幸いか、最低限（なぜか）互いに電話ができる状態にあったのは良かったと思います。この時にかかった金額としては 150 円ほど。訳あって複数キャリア全員持っていたので、通常時使わない番号などで連絡を取り合いました。 ワンキャリア・同一ネットワークの危険性を痛感 色々と理由があって、実質ワンキャリア（バックアップはあるけど）になっていた訳なのですが、あらためて複数キャリアを冗長化させておく必要があると痛感しました。既にバックアップがあったのでなんとかなった、というのもあるのですが、改めてこれを成功体験として喜ぶのではなく、学ぶ必要があると思いました。 昨今のトラブルでもあった通りコミュニケーションツールの見直しももちろんありますが、ある程度バックアップとしてキャリア分散なども行わないといけないです。 もちろん、携帯電話以外にもコミュニケーション手段なども含め、冗長化はおこなっておくべきだとは思いますが、ある意味「ダメになる」ことを前提とした構築が必要なのだと思いました。 その観点で言うと、電気もガスもそうなるとは思いますが、携帯電話はガスなどに比べても長時間使われるものとなり、一昔前と比べてもインフラかが進んでいると言っても過言ではありません。 仮に冗長化するなら 電話を使うことが多くても、最近は LINE などの方法もあるので、データ通信専用の SIM を挿しておく、だけでも違うのかな、と思います。 また、使わなくなった携帯電話の初期化を行わず、次の買い替えまで使えるようにしておくこと、なども含めて検討できると思います。 無闇に固定費削減するのもきついので、あまりこだわりがない、という方は以下のような構成が良いと思います。 キャリアのネット専用プランの申し込み（ある程度のデータ容量・速度をここで担保する） 格安 SIM の安価なプラン 音声回線が必要なら日本通信の合理的シンプル 290 プラン や povo など もちろん、店舗があるほうが安心、などという意見があるので、その人それぞれになると思いますが、大元となる通信事業者を分散させておくことにより、諸々回避できるのではないかと思います。 情報通信は準インフラとなってしまった 昨今の海外事業者のトラブルもそうですが、情報通信業は準インフラとなってしまいましたが、他のインフラ（電気・ガス・水道）と比べると多数の事業者があることも考えると、契約者側である程度回避するしかないと思っています。 どこまで妥協できるのか、ということもありますが、発生したのがたまたま土日かつ外出する予定があったタイミングで、事前に対策できていなかったのは良くないと思わされました。 これを機に、「これがダメになったら」という話し合いはしても良いのかもしれないですね。

なぜ M1 を今更購入したのか 色々な経緯・事情はあるのですが、最大の理由は以前から持っていた MacBook Pro がリプレース時期に入っていた（約 6 年利用）ためです。 基本的には ThinkPad を使っており、それも 4K での出力だと安定しないなどといった問題もあったのですが、別途新しい ThinkPad （※ Intel 搭載モデル）の導入も検討していました。（ 6 月に登場すると思われる GPU 搭載モデル） また、 M1 チップのノウハウがある程度溜まってきたことや、ソフトウェア側の対応状況が増したことにより、購入しても問題ないと判断しました。 MacBook Pro ではなく、 MacBook Air にした理由 今回購入した MacBook Air は（いわゆる）店頭などで販売されている廉価モデルにメモリだけ増やしたものです。メモリだけ増やした理由はプライベートでもオンライン会議などを行うことが多いためです。勉強会の事前打ち合わせはほとんどがオンライン会議での実施、になってしまいました。 いままで Pro を使ってきた中で、どうして Air に変更したのかです。予算との兼ね合い、ということもありますが、ベンチマークなどの情報から見ても、大きな差がないと判断したからです。 そもそも振り返ってみると、 Pro を今まで使ってきた理由としては購入するタイミングでの RAM 16 GB が選択肢にない、や外部グラフィックスの妥当性の判断（ Illustrator 動かすのに必要とか聞いていたり）など、モデルによる性能が異なっていたことが挙げられます。 最初の MacBook Pro は置いといて、 2 台目の MacBook Pro からは軽さなどのトータルバランスをみつつ、選択しています。 ファンレスかどうか、に関しては散々悩みましたが、会社で使うなら MacBook Pro にすると思いますが、プライベートで使う、たまに Zoom 12 時間参加ぐらいなら「メモリを増やした MacBook Air で事足りるだろう」ということにしています。 また、外部ディスプレイも大型のものを一枚接続する程度なので、その点からも（ 14 インチなや 16 インチの） MacBook Pro は不要だと思っています。...

去る 5 月 21 日に広島フロントエンド勉強会で Git 勉強会を開催しました。 ...

あまり更新していないので不満はなかった 不満という不満は本当になかったのですが、普段会社ではあまりやっていないこと・できないことをやりたいなー、という欲が出てきた、というのが本心です。 基本的にはバックエンドエンジニアとして働いているので、フロント寄りのことはあまりやっていなかったということもあるのですが、モダンな構築などのキャッチアップ、というほうが近いのかもしれません。 載せ替えはそこまで難しくなかった GitHub で大元のソースコードを管理しているということもあって、あまり載せ替えはサクッとするだけには難しくなかったような気がします。 CloudFrale Pages の画面からガイドに従って設定するだけでできるので、そこまで難しくないのかなぁと思います（ただし、英語なので、言語の壁はあるかもですが） 強いて言えば、 hugo のバージョンがデフォルトだと若干古いため、 環境変数 HUGO_VERSION を指定し、ローカルで動作しているバージョンに指定することで動作するようになります。 ビルド時間はそこまで時間かからない印象 元々 hugo 事態がそこまで重たくないので、 Netlify の時にもあまり時間がかかっていなかったような気がしますが、スムーズにビルドできているのはよいかなぁ、と思います。 hugo なので、全体で 1 分もかからない印象です。 強いて言えば トリガーが無条件のコミットなので、 Pull Requests などトリガーがあると尚良いと思います。 無料枠でも毎月 500 回分ビルドあるので、問題ないと思いますが、組織など商用利用で利用している場合、開発ポリシーなどによっては足りない、など発生すると思います。複数台での開発（在宅とオフィスで異なる PC を利用しているなど）をしている時にコミットするときもあるし、もっと言えば PR でも Draft では動作させたくない、などあると思うので、そのあたりの設定はできても良いのかな、とは思います。 もっとも、回数が多くなるのであればプロジェクトごとのドメインなどでの課金など含め、検討する必要はあると思います。（チーム開発をするなら、ですが）

2021 年に購入したものは意外と多い 私事ですが、環境の変化や在宅勤務などもあり、かなり多くのものを購入しました。 Amazon の注文だけでも、 2021 年 12 月だけで 129 注文と 2 日に 1 回何かを購入しています。 リアル店舗も含めると、ほぼ同じ頻度で購入していると言っても過言ではないですが、 2021 年に購入してよかったものを紹介します。 なお、この記事に記載のあるリンクは一部 Amazon アソシエイト・プログラムを用いたリンクを利用しています。 DELL U3219Q DELL の 31.5 インチ 4K モニタを購入しました。従来、 27 インチの 2.5K モニタ（ 2560 px × 1440 px ）モニタを利用していて、とくに不自由なく利用していました。 が、これは通常の動画閲覧であったり、業務での話です。今年は本格的に OSC の運営スタッフを自宅から行っているなかで、従来のモニタでは足りなくなってきました。具体的には以下の感じです。 最後のドラを鳴らすのに解像度に限界が出てきた（切り替えや配信クオリティに不満を持ち始めた） 色々なタスクをすすめると、もう少し解像度が欲しくなってきた ということで、前のモニタも購入して 1 年ちょっとしか経過していなかったですが、新しくモニタの導入を検討した結果、安定の DELL になりました。 他のモニタも検討しましたが、 DELL にしたのは以下の通り。 DELL のモニタは安定しており、輝度も目にあっている（前は思ったより明るかった） U シリーズはフルフレームレスで『映像が宙に浮いている』感覚を家でも楽しみたかった（会社でなれすぎた） HDR 対応や USB Type-C の安定性はいろいろな DELL モニタで折り紙付き ただ、値段も一流に高く、約 11 万円と、今までの EIZO などのモニタに比べると、 2 倍以上高いモニタを購入してしまいました。（前使っていた 2....

そもそもバレるのはなぜなのか ここでは、攻撃者の観点に立って考えたときに、 Movable Type を使っていることがわかる理由を記載します。 そもそも URL がよく使われるものが多い（ mt や movabletype 、 cgi-bin など） トラックバックやコメントなどの実行ディレクトリから把握されてしまう 同じドメイン上で運用されている事例が多い 「言われてみれば」ということが多いですが、構築するときには意外と安易に考えてしまいます。 Movable Type の安全性（セキュリティ）について | CMS プラットフォーム Movable Typeにも記載されていますが、「CMS と公開サイトのパスを分離可能」となっている通り、セキュアに構築するためには、 CMS と公開サイトを分離することで受けにくくなる、と公式サイトにも記載されています。（人によっては言い訳、と言われそうですが） どう対策するのか なぜ攻撃されるのか、バレるのか、ということはなんとなくわかったと思います。これらの前提から、どのように対策すべきなのかを考えたいと思います。 ただし、中には新規構築する場合のみ有効である内容もあるため、すべてがすべてかんたんにできる、というわけではないです。 URL をわかりにくくする Movable Type をインストールしているディレクトリ自体をわかりにくくすることは有効な対策ではないにしても、アクセスさせにくくするための手段としては有効です。 「大丈夫ですかね」と聞かれる多くのウェブサイトは、冒頭に挙げた文字列が使われていることが多いです。サーバ側の制約であったとしても、 Movable Type の URL の文字列を変更することによって、攻撃者から推測させにくくする、という効果はあると思います。 ただし、これは緩和策であり、有効的な対策ではないことはしっかり認識させておくことが大事です。 ドメインを分ける そもそも、 Movable Type を導入しているウェブサイトの下でなくても動くのであれば、ドメインなどを分けてしまうのもひとつ手だと思います。 これも有効的な対策かと言われると、微妙ですが、表から見えにくい、という意味では一定の効果があると思います。結果的には特定される可能性があるにしても、ランダムな文字列など工夫をおこなうことで、「わかりにくくする」ということはできると思います。 ただ、 URL をわかりにくくするよりかは対策できていますが、同様に有効な対策かと言われると微妙です。 Path を指定して IP アドレス制限や Basic 認証をかける Movable Type が長く開発されているシステムであるからこそ、 URL がよく使われるものが多かったりするため、 Movable Type が実行できるディレクトリに対して、 IP アドレス制限や Basic 認証といった、 Movable Type のシステムにアクセスする前段階での対策は非常に有効だと考えます。...