ブックマークサービスQiNeel関連の記事や身の回りのよしなしごとをそこはかとなく書きつくっています。
GoでPion DTLSというライブラリーがあります。これはUDPの暗号化通信をするときに使われるライブラリーなので、特殊なプロトコルの実装以外ではそもそもそういうソフトウェアを開発する機会自体があまりないかもしれません。
このライブラリーにちょっとした不具合がありまして、コネクション切断後の再ハンドシェイクがDTLSの仕様どおりの挙動をしていないようです。
具体的には明示的なコネクション切断を行わずに同じ接続元（アドレス:ポート）からClientHello受け取ったとき、DLTSの仕様ではサーバーは新しいハンドシェイクを開始するべきなのですがこのライブラリーではClientHelloが無視されます。
1年近く前にその問題を報告したのですが、つい最近この問題が解消されたようです。
かなりニッチな情報ですが、個人的に結構嬉しかったのでここで報告。。。
前回に引き続きFluentdの話。今回はmultilineパーサーについてです。
このパーサーは正規表現で複数行を解析できるので、regexpの上位互換みたいなもんか。じゃあ何も考えずmultilineにしとけばええやん！と思っていたら・・・
なぜか最後の行が出力されない。
これでしばらく悩んだんですが、そもそも考えてみたら次の行頭が確定するまで現在の行全体が確定しないわけですからそりゃそうですね。
というわけで、しばらく入力がなかったら自動的に行を確定させるためにmultiline_flush_intervalを設定しましょう。
これも数日ハマったので、同じようなハマり方をしている人のために残しておきます。
クラウド全盛期の今、ロギングツールも各クラウドの機能に取って代わられている感がありますが、まだまだ現役なFluentdの話です。
Fluentdで収集したログをAWS S3にアップロードする場合、セキュリティー対策として（アカウントが乗っ取られたときにログを盗まれないように）アクセスキーやロールにWRITE権限しかつけないことがあります。
そのときは、out_s3プラグインの設定で以下の項目を無効にしましょう。
auto_create_bucket false check_bucket false check_object false
よく考えれば当たり前なのですが、諸々の存在チェックはS3側に読みに行くので、READ権限が必要です。これらを無効にしておかないと、エラーが出てログを収集できなくなります。
5人組アイドル「UNICODE」登場 デビューシングルは「HELLO WORLD」 IT関心層「検索しにくそう」
はい。ただのネタです。
そもそも文字コードとしての「ユニコード」は“Unicode”（先頭のみ大文字）、K&Rの元祖「ハローワールド」は“hello, world”（全て小文字、カンマあり）なので、このアイドルのことを知らなくてもブログのタイトルを見た時点で「ITとは関係ないな」とわかるはずです（？）
よーしパパ X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* というユニットを作っちゃうぞー
ユニット名を保存したファイルがセキュリティーソフトに引っかかってもしらないぞー
詳細はEICARテストファイルで。
Google広告費の影響を受けない新たなWebブラウザが必要だと、スクラッチからWebブラウザを開発する「Ladybird Browser Initiative」、元GitHub創業者らが立ち上げ
動機は納得だし、健全な競争のためにも大いに応援したいと思っています。ただここまで巨大化したウェブ標準をフルスクラッチで実装するのは骨が折れるどころか粉末状に砕けるレベルの大仕事でしょうね・・・
当面の問題は、開発人材の確保と運営資金でしょうか。
とりあえずリンクをぺたり。みなさんも応援してあげてください。
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）
記事の内容は「メソッドの名前がおかしいが実装わかりやすいコード」と「メソッドの名前は問題ないが実装がややこしいコード」の2つを50人ほどのJavaプログラマーに解読してもらい、メソッド名と実装のどちらを先に修正すべきかというものです。
統計結果を見る前に思ったのは、メソッド名を先に直すべきではないかということ。理由は記事中にある
構造的問題は局所的に起こるが、命名的問題はコードのどこにでも出てくるものがあるため
「命名的問題」があるとコードが信じられなくなる
などです。そして上記記事でも「命名が不適切なコードの方が読解精度が低い」という結果が出ました。
また実際の開発現場でも、命名が不適切なコードの方が読解精度が低い」という結果ですが、コードリーティングの際に実装がややこしい場合は「何だこれ？」と思って注意して読み進めるのに対し、命名が不適切な場合はメソッドの役割を勘違いしたまま開発を進めてしまう可能性があるので命名的問題のほうが深刻だと考えています。
先日7/3-5に、奈良でJANOG54 Meetingが開催されました。毎回ネットワーク分野の錚々たる企業が集まっており、日本国内でインターネットが壊れた場合は大抵ここの参加企業のどこかが何かやらかしていると考えて間違いないです。
色々ブースを見て回った他、さくらインターネットのブースで「高火力 DOK」の説明も行いました。AI関連のサービスなのでネットワークと直接関係はないんですが、6/27に発表されて1週間ほどしか経っていないサービスなので、広報も兼ねて説明要員としても参加しました。
サービスインしたので晴れてプロフィール更新
— おだしま@手品をするITエンジニア (@shimataro999) June 27, 2024
このサービスの開発マネージャーをしています
なお開発マネージャーの仕事は、やることをメンバーにぶん投げてケツ叩いてあたかも自分の功績かのように見せることですhttps://t.co/nleAbVGDkk
ネットワークなどの低レイヤーにあまり興味のないウェブ開発者もいると思いますが、自分たちが開発している（あるいは普段使っている）サービスの土台を知るためにもこういうカンファレンスはおすすめです。最初は言っていることがさっぱりわからないかもしれませんが、何度も参加しているうちに知り合いができたり話の内容も理解できたりするので面白いですよ。
奈良には学生時代に数年（今回の会場から2駅ほどしか離れていない場所に）いたんですが、さすがに当時から時間が経っているので駅前がかなり開発されていますね。ただ夏暑く冬寒いという気候は相変わらずでしたが。