データ圧縮のパイオニア？

 データ圧縮のパイオニアであるジェイコブ・ジヴ氏の功績とその半生とは？

2年前の記事に何を今更という感じですが、偶然たどり着きました。昔（高校生くらいの頃かな？）データ圧縮について色々調べたことがあり、記事の内容についてちょっと気になったので今更ですがいくつかコメントします。

どっかで似たようなことを書いてる人もいそうですが。

6/25にオープンソースカンファレンス2022 北海道に登壇しました

 先週の予告通り、Open Source Conference 2022 Online/Hokkaidoに登壇してきました。

タイトル通り割と砕けた感じで、IoT開発の難しいところとそれを新プロダクトがどのように解決するかを説明したつもりです。

6/25にオープンソースカンファレンス2022 北海道に登壇します

 来る6月25日、Open Source Conference 2022 Online/Hokkaidoが開催されます。

枠をもらってちょっとお話させてもらいます。

リンク先の通り、IoT開発についてのお話なんですが、まあだいたい会社の新プロダクトの紹介です。

あまり専門的になりすぎないようにIoT開発を完全に理解した人あたりがメインターゲットですが、「開発したことないけど概要くらいは知ってる」という人でも大丈夫です。たださすがに「IoTって何？」という人は聞いても理解できないと思います。

IoT開発に興味ある人はぜひ聞きに来てください。

「パワポってデザインどうしても汚くなるんだよなー」と思いながら発表スライドを作成して、とりあえず下書きレベルで作ったものを部署内のパワポマスターに渡したら、めっちゃキレイなスライドになって返ってきました。

単にこっちのデザインセンスないだけでした。パワポごめんね。君は悪くない。

通信プロトコルのトリビア

 セキュリティ・キャンプ2022全国大会の選考が先日締め切られました。若いエンジニアのみなさんは未来のIT業界を背負うべく、こういう場所でしっかり学んでいってください。

ワシはもう若くないからええんじゃ。

さて、応募課題の中でちょっとおもしろい問題があったので考察してみましょう。

冗長化されたルーター経由のpingが通らないことがある

 最近ハマったので記録を残しておきます。まあ例によって原因は単純なミスなんですが、例によって仰々しく書いてみます。。

図のようなネットワーク構成を想定してください。

• 2つのネットワークがある
• それぞれのネットワーク内にはサーバーがある
• 2つのネットワークはルーターでつながっている
• ルーターはVyOSを使っている
• ルーターは2台あり、冗長化されている（片方が落ちても問題ない）

この状態でA→Bにpingを飛ばすとちゃんと返事が返ってくるのに、逆方向（B→A）は返ってこないという摩訶不思議な現象が発生していました。

補足として、firewalldやufw等のファイヤーウォールは特に入れておらず、ルーティングテーブルも適切に設定されています。

なお、これはクイズではないので、唯一の正解にたどり着く情報が与えられているわけではありません。ただし、よく読めば「ここが怪しいんじゃない？」とわかるヒントは入れてあります。

複数ホスト間の排他制御

ウェブサービスを開発していると、集計とか課金とかでバッチ処理を行いたい場合が出てきます。

バッチ処理は冗長化のために複数のホストマシンに起動設定しているけど、実行はどれか1つだけで行いたいという場合もあると思いますが、その方法をいろいろ調べてみました。

まあ今さらかよって話ですが。

ウェブサービスの障害対応のためにやること

今、仕事でウェブサービスの信頼性向上のためにいろいろやってます。

もう少し具体的に言うと、サービスの障害にいかに対応していくかという点です。タイトルに「ウェブサービスの」と書きましたが、別にウェブサービスに限った話ではありません。もっと一般的な（IT以外の分野にも）言えることですが、仕事柄ウェブサービスに多く関わっているのでこう表現します。

今回は、障害対応関連について現在取り組んでいることをツラツラと書いていきます。とは言っても、きちんと対応している人・組織にとっては別に目新しい内容は何もありません。目からウロコが落ちるようなことも多分ありません。

そのへんを踏まえてお読みください。

さくらの夕べ Tech Night #2 Onlineに登壇しました

さくらインターネットが主催する「さくらの夕べ Tech Night #2 Online」というイベントに登壇してきました。ゆうべはおたのしみでした。

オンラインで登壇するのは初めてなので、オフラインより逆に緊張しました。オーディエンスに圧倒されなくて済むはずなのに。

GitHub Actionsでシェルスクリプトからrsync over SSHしたい

背景はこうです。

• GitHub上でウェブアプリケーションを開発している
• GitHub ActionsでCI/CDを設定している
• 何らかのトリガー（リリースタグの作成等）で、開発環境や本番環境にデプロイしたい
• デプロイ用シェルスクリプトを自前で用意している
• シェルスクリプト内でSCPやrsync over SSHなどを実行している

このとき、SSH鍵がGitHub Actions側にないとデプロイができないよね、という話。

GitHubでVerifiedマーク

GitHubでこういうマークあるじゃないですか。

ちょっとかっこいいので作ってみることにしました。

NFSサーバーを立てるときはファイヤーウォールに気をつけよう

タイトルそのまんまです。
サーバーを立てようとしてハマったので備忘録として残しておきます。

意外と反響が＆新章追加

先日Qiitaに公開した「読みやすいコードを書くために」が意外と好評だったようで、約2週間で500(・∀・)ｲｲﾈ!!を突破しました👏🎉

読みやすいコードを書くために

…という記事をQiitaに投稿しました。

読みやすいコードを書くために

Web APIの逆引きステータスコード

Web APIでは、呼び出しに失敗した場合にステータスコードでエラーの種類を返します。

それぞれのステータスコードの意味はMDN等でよくまとめられていますが、逆に「どんなエラーのときにどのステータスコードを返せばいいのか」という情報はあまりありません。

そこで、逆引きリファレンスとしてまとめてみました。

RFC3986に準拠したURI検証用正規表現

以前、可能な限りRFCに準拠したEメールアドレス検証用正規表現という記事を投稿しました。
今度はそのURLバージョン、RFC3986に準拠したURIの正規表現を作ってみました。

前回と違い、可能な限りではなく完全準拠です。多分。

入力データの検証場所に関する議論

Webアプリケーションに限らず、ほぼ全てのアプリケーションでは外部からの入力値のバリデーション（検証）が必要です。
いわゆるMVCアーキテクチャでは、それをControllerでやるのか？Modelでやるのか？についての議論が度々俎上に載ります。

今回はそれについての私見を。

可能な限りRFCに準拠したEメールアドレス検証用正規表現 完全版

以前、可能な限りRFCに準拠したEメールアドレス検証用正規表現を紹介しました。

記事中にも書いてあるとおり、あの正規表現はIPアドレスを性格に判定できませんでしたが、今回その欠点を解消した完全版をお届けします。

可能な限りRFCに準拠したEメールアドレス検証用正規表現

ウェブサービスを作っていると、入力されたメールアドレスが正しい形式か確かめたいということがあると思います。

今ならHTML5でinput要素にtype="email"が使えますし、そもそも検証せずとも実際に送ってみればいいのですが、やっぱり事前に検証したいというときもありますよね。

ただ、RFC5321やRFC5322で規定されているメールアドレスの形式って結構複雑で、ほとんどのサービスでは簡易的に正規表現でチェックしてたりします

そこで、できるだけRFCに準拠した正規表現に挑戦してみました。

LINEbot 活用事例

先日、LINEbotを作ってきました。
難しいかなと思ったら意外とサックリ作れたので、この調子で他にも何か作ってみようと思ってネタを探していました。

【恐報】東京Node学園祭2017に登壇することになった

先日のiOSDC Japan 2017に続き、11月に東京Node学園祭2017にも登壇することになりました。