toruby 231st - connpass に参加しました
チャリじゃなくて車で来た
夜間 BBQ ってなんだろうな〜
to Ruby になっている、いつもの張り紙
各位、いろんな話をしました。(プライバシーに触れそうな話、秘密っぽい話は載せていません)
久しぶりの参加でしたが、他参加者の皆さんの転職など変化もあり 近況をキャッチアップする時間にもなりました。XP 祭りの発表練習を聞けたのも良かったですね。
YAPC::Fukuoka 2025 に参加 && 登壇しました。
タイトルは セキュリティを 「ふつう」にやっていく 技術、体制、文化の追求 です
前日に急遽 発表時間を 20分から40分にしていただけましたが、突貫でセキュリティ関連の話を盛り込むのは難しいなとギリギリまで唸っていました。1
X のスターや はてなブックマークの数もそこそこで伸びていて、Cyber-sec+ Slack や、意外なところでも反応を得られて嬉しく思っています。
弟がカンファレンスで発表した資料が自社の Slack で「参考になる」って共有されてるの見かけて不思議な気分
— naoya (@naoya_ito) 2025年11月19日
リアクションはあったものの具体なコメントはあまりいただけていないので、みなさん、どういうアングルで気になったのかは伺いたいところです。
後から振り返って、以下のような話を追加したかったと内省
登壇が決まった際にこんなエントリを書いていました。
CfP を書いていた際に後輩とこんな会話をしていたのですが、今回の滞在ではラーメンを食べる機会を悉く逃してタスク達成ならず! 2
とある Linux コンテナで動くプロセスを GDB でデバッグしている最中に glibc の関数を追っていて、以下のようなコードを見つけました
(gdb) l
156 void
157 __libc_fatal (const char *message)
158 {
159 /* The loop is added only to keep gcc happy. */
160 while (1)
161 __libc_message ("%s", message);
162 }
The loop is added only to keep gcc happy. とは?わからんので エイっと AI に聞いてみました。
以下は Microsoft 365 Copilot Chat の回答です。他の AI 回答も予々一緒で、妥当っぽい回答な気がする。
この while (1) ループは、意図的に無限ループにしてプログラムを停止させるために使われています。 関数 __libc_fatal は、glibc（GNU Cライブラリ）の内部で致命的なエラーが発生したときに呼ばれる関数です。以下のような目的があります：
目的と意味
致命的エラーの通知
__libc_message("%s", message);によって、エラーメッセージを表示します。プログラムの停止 while (1) によって、関数から戻らず、プログラムを永久に停止させます。これは、致命的なエラーが発生した後に、処理を続けることが危険であるためです。
最適化回避
コメントにある「The loop is added only to keep gcc happy.」は、GCC（GNU Compiler Collection）が最適化の際にこの関数を「戻る可能性がある」と誤認しないようにするためです。無限ループにすることで、コンパイラに「この関数は絶対に戻らない」と明示できます。
補足
通常、こうした関数は
__attribute__((noreturn))を使って「戻らない関数」として宣言されますが、念のために while (1) を入れておくことで、コンパイラの警告や最適化の問題を防いでいます。
upsteream である glibc 2.34 へのリンクを貼っておきます 1
void __libc_fatal (const char *message) { /* The loop is added only to keep gcc happy. */ while (1) __libc_message (do_abort, "%s", message); } libc_hidden_def (__libc_fatal)
__libc_message() は内部で abort() を呼び出すようです。
/* Abort with an error message. */ void __libc_message (enum __libc_message_action action, const char *fmt, ...) { ... 略 if ((action & do_abort)) /* Kill the application. */ abort (); }
そういえば、ずいぶん前に abort() の実装を追って調べて、テックブログにまとめたのを思い出しました。
abort() にも while(1) で HLT 命令を呼び出すコードがありますね ! 詳細はブログ読んでね (宣伝)
while (1) /* Try for ever and ever. */ ABORT_INSTRUCTION;
toruby 221st - connpass に参加しました。
開催は 18:30 からですが、もう真っ暗。
みなさん、いろんな話題を繰り広げていました
... などで盛り上がりました。自分にはあまり馴染みのないテクニカルな話でワイワイしてました。
後半は応用情報技術者試験の過去問を取り上げてみんなで解いてみる時間でした。
公民館の掲示です 。何えもんだ?
YAPC::Fukuoka 2025 に登壇します。プロポーザルが採択された!
タイトルは セキュリティを 「ふつう」にやっていく 技術、体制、文化の追求 としています。
「ふつう」 ってなんじゃい〜？ という反応になると思いますが、事業の中でセキュリティをやるのは前提・当たり前に粘り強く進める (シフトレフトとか DevSecOps だとかも近しいところ) ... といった話を平易に表現して話してみたいと思います。
過去をふり返って、もちろん私だけの力で「ふつう」にやってきた・今もやれているとは思っていなくて、過去・現在で いろんな リーダー の力を借りることで協働で実践してきた感じです。
ちょうど 4月に GMOペパボ株式会社に勤めて18年目に突入 - シニアプリンシパル エンジニアに昇格しました - hibomaの日記 ということもあり、時期的にも立場的にも、自分が代表として 全体感をまとめた話をカンファレンスに持っていくのがいいかな〜と考えました。
今回のプロポーザルは、先んじて弊社の三上 ( @rsym1290 / ressy ) が出すぞ!!! と公言していて、彼からプロポーザル概要のレビューも依頼されていました。レビュー作業中に触発されて、"よーし" と私もやる気になった次第です 1
今回は応募も多数で倍率も高く、残念ながら彼のプロポーザルは採択とはなりませんでした。だがしかし、まず「出すぞ!」 という気持ち・勢いを出して周りを鼓舞していたので 💯
レビューのやり取り
「テーマが "きゅう" だって? "休" ならまかせろ〜 」 と株式会社 一休 さんからもプロポーザルが出るか ... !? と期待していました 🐘
久しぶりに toruby に参加しました。
220回目に参加。ひさびさ。 #toruby pic.twitter.com/IL95DeO7FZ
— hiroya ito (@hiboma) 2025年9月3日
家族（👦）が増えてからは、しばらく足が遠のいていました。
会の前半は、参加者の皆さんによる最近のあれこれの話。あぶくま洞（？）、学生向けのプログラミングイベント、ライフステージの変化、2025年度新聞技術賞、就活（転職）などなど、雑談が続きました。
後半は『研鑽Rubyプログラミング』の「第11章 きちんとコードが動くことをテストする」を読みました。TAD、TDD、BDD といったキーワードが並び、サンプルコードも紹介されましたが、皆さんそれぞれに思うところがあったようで、ぽつぽつと突っ込みが入っていました。
toruby 終了後は、セコンさんとフライングガーデンで晩ごはん。
お互いの家族（👦、👧）の話や、K-POP にはまる家族の話、遠出する話、早朝サイクリングの話、那須は熊が怖い話、那須の人たちの友達ネットワークなど、いろいろ話しました。ごはんはセコンさんにご馳走になりました。
ごはんをご馳走になったの話で、ずいぶん前に danjou さんに焼肉をご馳走になった記憶が蘇った。確か、mizzy さんに連れられて参加したはずで Perl Hacker な皆さんとも席をご一緒したんだったかな ( それはそうと、mizzy さんにもご飯をご馳走になったことは何度もあるな )
ずいぶんしばらく会社の職位制度・評価制度と睨めっこしていたせいか 「コミュニティに参加して、アウトウプットして、会社のプレゼンス向上に寄与する!!1」な考えに凝り固まっていた節がある。「楽しいことやってる話をみんなで交わした」「インターネットで見る、あの人たちとご飯食べた」みたいな "あそび" が足りてないと思ったりした。
2007年から GMOペパボ株式会社 ( 2007年当時の社名は paperboy&co. でしたが ) に勤めて、18年目になりました。
先月(3月) 半ばにエンジニア職位制度に立候補し、1次でCTO・技術責任者の2者と面談を実施、2次で経営会議での決議をいただき、シニアプリンシパル エンジニア 1 へ昇格となりました。
現在の等級表は下図の通りです。等級の詳細は引用元ページを参照してください。
職位制度が開始してから、10年以上もずっと5等級プリンシパ ルエンジニア 2 の職位でいましたが、その間はずっと プラトー で 停滞 している感覚に悩まされていました。技術の修練も積み、事業にも結果を出してコミットしている つもり なのだが、次に昇っていける手ごたえがない。
その辺の焦燥感の吐露も含めて、自身のキャリアを振り返りしたのが下記の発表でもありました。
長年、色々とドリフトしながらも ようやく ここ 2-3年内で足枷になっていた何かを振り切った感が出てきました。そして、 昇格 = 外的な変化 を持って解放された!!! という気分になっているのが今の正直な気分です。嬉しいという気持ちももちろんあるけど。
現在はセキュリティ対策室に所属しており、下記のミッションの元、業務遂行に当たっています。
GMOペパボのセキュリティ対策室とは情報セキュリティ基本方針を遵守し お客様、お取引先様、従業員から預る情報資産を適切に扱える 文化形成、技術的仕組みをリードする組織
今後もこのミッションの元に活躍できる領域を広げていきたい気持ちです。おおよそ、 事業の脅威となるもの、全部から守る!!! ( ... と大風呂敷を広げつつ)、 お客様、ステークホルダーの皆様、共に働くパートナー 3 に「安心と安全を届ける」を掲げていきたいと思っています。
改めてこのエントリを書く際、弊社の職位制度についてまとめたメディアを見て回りました。pyama さんがこの (↓ ) 記事書いてから もう7年も経過していたのがびっくりですね。
