例示用・テスト用ドメインについて知る

例示用・テスト用ドメインについて知る

こんにちは。豊田です。 前回は、例示用IP・テスト用IPアドレスについてブログを書きました。 例示用IPアドレスについて知る 上記ブログでも触れていますが、私たちは職業柄IPアドレスよりもドメインを使うケースが多いのですが、実はドメインについても代表格である"example.com"(とその他少し)しか知らないのでは?と疑問に思ったので、調べてみました。 はじめに結論 テスト用・例示用のドメインが用意されていることを知りました。(RFC2606 , RFC6761) 特に以下は、今回気になっていた例示用・テスト用のドメインです。 ドキュメント例示用途向け .example TLD例示用 .example.com / .example.org / .example.net セカンドレベルドメイン例示用 .jpドメイン .example.jp / .example.co.jp / .example.ne.jp 以下のバリエーションもある .example1.jp ~ .example9.jp .example1.co.jp ~ .example9.co.jp .example1.ne.jp ~ .example9.ne.jp ドメイン名例.jp 日本語ドメイン版 xn--eckwd4c7cu47r2wf.jp "ドメイン名例.jp"のpunycode テスト用途向け .test DNSやネットワークのテスト用途として予約されている テスト用途で予約はされているものの、本当にネットワークを介したテストを実施するのであれば、当然DNSの設定は必要になるので注意が必要 他にも用途別に多くのドメインが予約されています。 気になる方は調べてみてはどうでしょうか?(Wikipediaにも一覧が載っていました) ドキュメント例示用途向けドメイン まずは例示用向けに予約されているドメインを列挙していきます。 .example IANAのSpecial-Use Domain Namesとして定義されているトップレベルの例示用ドメインです。 明示的にトップレベルドメインを示したいときは、こちらを使うのが良さそうです。 このドメインは知りませんでした。覚えておこうと思います。 .example.com / .example.org / .example.net 同じくIANAのSpecial-Use Domain Namesに定義されている、セカンドレベルドメインです。 多くの人は.example.comに馴染みがあると思いますが、.org, .netも予約されていたのは初耳でした。 通常は.example.comを使いつつ、別のセカンドレベルドメインも例示するときには、こちらを使うのが良さそうです。 jpドメイン .example.jp / .example.co.jp / .example.ne.jp .jpドメインにおける例示用に予約されているドメインです。 .example.jp、.example.co.jpは使えると知っていましたが、.example.ne.jpも使えるとは知りませんでした。 .ドメイン名例.jp(punycode: xn--eckwd4c7cu47r2wf.jp) こちらも知りませんでした... マルチバイト文字の例示用ドメインです。 こちらも、もしかしたら必要になるケースがあるかもしれないので、覚えておいても良さそうです。 テスト用途向けドメイン 次はテスト用途で予約されているドメインです。 こちらは一つだけです。 .test DNSやネットワークのテスト用途として予約されたドメインです。 ネットワークを介するテストをする(独自にDNSなどを設定して運用するような)場合は、こちらを使うことが推奨されています。 というのも.testドメインは、その名前解決リクエストに対して基本的にエラー応答を返すよう、DNSの管理・運用者に要求しています。(RFC6761の6.2.4) そのため、誤ってグローバルネットワークに出てしまうようなテストを書いたとしても、より上位のDNSからは「そんなドメイン知らん」と言われるだけで、ネットワークに不要な負荷をかけないような仕組みになっているからです。 限られたネットワーク内で完結することを想定したテストであれば、.testをテスト用途で使って良い。ということのようです。(しつこいですが、DNSの設定等は独自にちゃんとやっておく前提です) 専用ドメインを取得していない(これから取得する)ようなケースなどでは、非常に有効な手段となりそうです。 おまけ その他にも色々とドメインが予約されていますが、その中で .invalidというドメインは興味深かったです。 こちらは「無効なドメイン」を示すドメインであり 誤って外部にリクエストを送ってしまう可能性のある設定の初期値 名前解決に失敗することを期待するテスト 無効なURLの例示 ダミーメールアドレス といった場面で利用できます。 まとめ 例示用・テスト用のドメインについても知らないドメインがいくつかありました。(他の用途で言えば、もっとたくさん専用ドメインが予約されていました) 多くの場合.example.comで事足りてしまうことが多いですが、知識の引き出しとして覚えておくと、助かる場面があるかもしれません。

JRRF2026に参加してきました

JRRF2026に参加してきました

こんにちは、小林です。 去年に引き続き、今年もJRRFに参加してきました!! https://japanreprapfestival.com/ 去年の参加レポートはこちらです。 JRRF2025に参加してきました 去年も大盛況でしたが、今年はさらに大規模なイベントになっていました。 キャパシティ: 970人 → 2,000人 出展ブース数: 77ブース → 154ブース 来場者数: 1,500人 → 4,700人(両日参加者を1人とした場合、3,300人) 会場も東京流通センターのホールCからホールEに変更され、全体的にかなりスケールアップしていました。 今年は展示スペースだけでなく、イベントや体験スペースが充実しており、3Dプリンターをまだ持っていない方でも楽しめる内容になっていました。 MakerChip 3Dプリンター界隈では、もはやお馴染みとなったMakerChip。 開催の数週間前から、多くの方々がオリジナリティあふれるデザインで印刷をしている様子がXのタイムラインを賑わせていました。 もちろん、私も印刷しました。去年はY軸で回転させたので、今年はZ軸で回転するようなデザインにしました。 今年は100個用意し、全て交換してきました。ブースにいる方々だけではなく、一般参加の方とも交換をし、交流を深めることができました。 UVプリンターとレーザー刻印 参加されている方のMakerChipはどれもすごいのですが、特に気になったのがこの3つです。 左から、DaDaDa3Dprint(@DaDaDa3D)さん(企業)、Mithril_MEX(@Mithril_MEX)さん、大阪@スリキャン(@3dp_oosaka)さんのもので、左の2つはUVプリント、右の1つはレーザー刻印が施されたものです。 レーザー刻印はやはり0.2mmのノズルとは比べ物にならないくらい精密なものを描画できるので憧れます。 UVプリンターもこんなに綺麗に印刷できるのかと、驚きました。使ってみたいのですが、個人で購入するにはまだ少しハードルが高いです。 キッチンカー なんと、今年は会場内にキッチンカーが出店していました。 去年はカロリーメイトを片手に栄養補給をしていたので、とてもありがたいです。 私はBLACK BURGERさんのハンバーガーを食べてきました。 バンズが真っ黒なのは、竹炭を練り込んでいるからだそうです。 ブース 今年はブース数が多く、目移りしてしまうほどでしたが、特に気になったブースを紹介します。 歩く3Dプリンター ぼんじー(@bonjyy)さんのRepRap作品の歩く3Dプリンター。 https://x.com/bonjyy/status/2060904588405088351?s=20 最初に見かけた時は、ヘッドがレール上をベルトやワイヤーで移動するのではなく、関節を動かして印刷するのかと思い、単純に駆動方式の違いに驚いていました。 しかし、よく見ると本当に歩いていて、さらに驚いてしまいました。 これを見た時、スター・ウォーズに登場するAT-ATウォーカーにしか見えませんでした笑 電解メッキ HEN3DRIK(@HEN3DRIK)さんはドイツで電解メッキと表面仕上げを研究しているとのことです。 どの作品も金ピカだったのですが、特にC-3POの頭部が一際目立っていました。 こちらがHEN3DRIKさんが作成されたMakerChipなのですが、3Dプリンターと組み合わせるとこんな感じになります。 https://x.com/HEN3DRIK/status/2058226348376613357?s=20 どちらも技術としてすごい!!と思うと同時に、スター・ウォーズファンの私としてはニヤリとしてしまう展示でした。 感想 今年も本当に大盛況でした。イベントやブース、キッチンカーと見るものが多く、1日で見たいものを全て見るのは無理でした。 来年は、2日間両方参加しようと思います。 きっと来年はさらに盛り上がるイベントになりそうで、今から楽しみです。

例示用IPアドレスについて知る

例示用IPアドレスについて知る

TL;DR IPアドレス(v4, v6)にはドキュメントへの記載用のアドレスが予約されています。(RFC5737 / RFC3849) ドキュメントに記載するアドレス際は、適切な専用のIPアドレスを使いましょう。 素朴な疑問 弊社ではwebアプリケーションの開発をおこなっています。 そんな業務の中で、先日「IPアドレスでの入力はinvalidにする(ドメイン名での入力を求める)」というケースの実装をすることがありました。 実装を終え、いざテストを書こうとしたときに、テストで使えるIPアドレスを知らないことに気づきました。(職業柄、ドメイン名(example.comなど)を扱うことはあってもIPアドレスを扱うケースは多くないので...) その時に調べた例示用IPアドレスについて、まとめておこうと思います。 IPv4 RFC1166 例示用IPv4アドレスはRFC1166で登場しました。 当初は192.0.2.0/24のみでした。 また、「例示用」という明確な定義はなく、"TEST"というネットワーク名が付けられている。というくらいの曖昧な位置づけだったようです。 ※ 一応、研究用途であることや、インターネットでは利用されない前提であることは決まっていたようです。 RFC5737 例示用のIPv4アドレスに関しては、RFC5737が最新です。 こちらでは、以下の3つアドレスブロックを例示用と位置づけています。 192.0.2.0/24 (TEST-NET-1) 198.51.100.0/24 (TEST-NET-2) 203.0.113.0/24 (TEST-NET-3) 上記のアドレスブロックは、明確に「例示用」とされており、ルーターやファイアウォールなどのネットワーク機器で「外部ネットワークに出さない/内部ネットワークに入れないIPアドレス」とすることをネットワーク運用者に求めています。 つまり、(誤って)実際のプログラムで使われてしまっても、外部ネットワークに出ていかない安全なIPアドレスということになります。 「例示用」の位置づけですが、IPアドレスとして機能しないものであり、テストでの利用も問題ありません。 128.66.0.0/16 少し脱線しますが、RFC5737の5章では、128.66.0.0/16というIPアドレスが過去に例示用に使われたことに言及しています。 このIPアドレスは現在、特別な意味を割り当てられていないため通常のIPアドレスとして(注意すれば)使って良い。とされています。 あまり気にする必要は無さそうですが、古い設定などが残ってる環境などは、意図しない挙動になる可能性があるので、少し注意しておく必要はあるかもしれません。 IPv6 RFC3849 IPv6の例示用アドレスはRFC3849で定義されています。 2001:db8::/32 です。 IPv4同様、インターネット上にパケットが流通しないように、ネットワーク運用者が管理することが求められています。 RFC9637 比較的最近(2024年)、RFC3849を拡張する形でRFC9637が定義されました。 3fff::/20 です。 RFC3849で定義されている2001:db8::/32はネットワーク部で32bit使っており、より大規模なネットワークを例示するユースケースで使えない。という問題があったようです。 なぜネットワーク部を20bitとしたのかについては、3章で具体的に説明されていました。(現在の利用状況から20bitとしておけば、将来的にも困らないだろう...ということのようです) まとめ 長年この業界にいますが、example.comだけで困らなかったので、久々に「へーちゃんと用意されてるんだ」と感じました。 テストやドキュメントを書くときは、RFCに従って書いていきましょう!

RubyKaigi 2026に参加してきました

RubyKaigi 2026に参加してきました

お久しぶりです。 小林です。 4/22〜4/24に函館で開催されたRubyKaigi 2026に参加してきました。 弊社としては3回目、私個人としては初めてのRubyKaigiへの参加です。 https://rubykaigi.org/2026/ 先に感想を言ってしまうと、多くのエンジニアの方と技術の話ができ、とても楽しい3日間でした。 スポンサーブース kickflowさんのブースで、3種類のAI(Claude、Gemini、ChatGPT)に同じ質問をして、どのAIの回答かを当てる「利きAIクイズ」をやっていたので、挑戦してきました。 結果は、なんと全問正解でした。 私が挑戦した時点では全問正解者はいなかったらしく、ブースの方々にも驚かれていました。 (いちばん驚いていたのは私ですが……) https://x.com/koba_masa40/status/2046831103143784507 どうやら、私はAI、あるいは人類のバグだったようです(笑) 他の企業さんのブースも回り、サービスの技術スタックや開発におけるAIの活用についていろいろ話を伺いました。 数年前までは開発にAIを利用していること自体が強みだったのが、いまや当たり前となっていることを改めて実感しました。 各社さまざまな工夫をしながら活用しており、とても興味深く、勉強になりました。 また、RubyKaigiでは恒例となっているスポンサーブースのスタンプラリーもコンプリートし、無事ピンバッジを獲得してきました。 各ブースを回るきっかけにもなり、いろいろな企業の話を聞けたのも良かったです。 セッション とにかくマニアックなセッションだらけでした。 さすが、Ruby言語そのものやエコシステムを作っている方々が多く集まるイベントだけあって、とても濃いRubyの話が聞けて楽しかったです。 今回いちばん気になっていたのは、2日目のm_sekiさんのセッション「Programming with a DJ Controller - not vibe coding」でした。 https://rubykaigi.org/2026/presentations/m_seki.html これを見たときに、「頑張れば、俺の考えた最強のCAD用デバイスも作れてしまうのでは?」と思い、ぜひ聴いてみたいと思っていました。 実際にDJコントローラーを使って操作する様子を見ながら、「こんなことができるのか」「こういう発想があるのか」と、とても面白く聴くことができました。 また、おやつ休憩の時間には本来の用途であるDJとして音楽が流されており、会場全体がチルな雰囲気に包まれていたのも印象的でした。 特に面白いと思ったのは、複数のテキストエディタを操作してスクロールし、ログを眺めやすくするという活用方法でした。 確かに便利そうだと思いました。 感想 公式レセプションでもブースでも、エンジニアの方々と技術の話で盛り上がることができ、とても楽しかったです。 Rubyそのものの深い話だけでなく、普段あまり接点のない方々と交流できたのも、RubyKaigiの大きな魅力だと感じました。 来年は宮崎での開催とのことなので、また参加して、さらに多くの刺激を受けたいと思います。

「独学の地図」を読んで「学び」について学んでみた

「独学の地図」を読んで「学び」について学んでみた

こんにちは。山屋です。 ようやく春の訪れを感じられる日々になりましたね。幸い私は花粉症ではありませんが、今年こそ発症してしまうのかと毎年ヒヤヒヤです。(このブログを書いている日は朝からくしゃみを連発しているのですが、違いますよね…?) さて、今回は独学の地図という本を読みました。 エンジニアは日々技術のキャッチアップを行っていますし、学ぶことは避けられないと思います。 著者は20年間人材育成に携わってきた方で、同じことを教えても人によって学びの結果に大きな差が出てくると述べています。本に書かれていた良い学び方について印象に残った内容を紹介させていただきます。 「疑問」から学びを始める 自分の内なる疑問に答えるために学ぶ 「最初に自分で問いを立てる」ということが非常に大事です。探究欲求が刺激され、外からの強制力に左右されず自分で追求できるようになるためですね。この「問い」というのは「イシュー」ではなく「疑問」でOKです。「その問いの答えを本気で知りたいか?」という条件を満たしていることです。 私たちは受験勉強や資格試験、業務で必要な勉強など「他者が定めた要件を満たすための手段」としての学びをしてしまいがちです。問いの決定権を奪われてしまっている状況ですから、正直面白くないですよね。 「なぜ学ぶのか」を最初に考えないようにする なぜこれを学ぶ必要があるのか、というのを最初に意識してしまうと必然性のある学びしか目に入らなくなる危険性があるためです。面白そうだから学ぶ、それ以上の理由は必要ありません。学んでいる過程で学ぶ理由に後から気づければ良いのです。そもそも変化の激しい世の中で、学ぶべきことを予測すること自体が難しいのです。 5つの独学筋 独学の実践には以下の5つの能力が必要だそうです。意識して反復トレーニングをすると確実に上達するということで、筋肉に例えています。筋肉は裏切りません! 自己批判筋 - 自分の中に他者を飼え 批判的に向き合うことにより、考えを深めましょう。 自分が師と仰ぐ人、自分にない視点を持つ人の発言をストックしておくと良いでしょう。自己批判の際に「あの人っだったら何と言うだろう?」と考え、その発言を記憶から引っ張り上げましょう。 保留筋 - 意味不明に向き合え 問いに対してすぐに答えを出すことが必ずしもベストとは言えません。 学びは後から少しずつ気づくケースが多いためですね。難しいことを学ぶことになったとしてもわからないからといって投げ出すのではなく、わからないままで自分の内側に抱えてみましょう。長い時間がかかるかもしれませんが、いつか予想もつかなかったタイミングで答えに巡り会うことになるでしょう。 抽象化筋 - 一見似ていない「似たもの同士」を探せ 抽象化とは物事の本質部分を捉え、それ以外の部分を捨てることです。よく飲み込みが早い人のことを「一を聞いて十を知る」と言いますが、まさにこの抽象化筋を使って本質を素早く読み取っているのです。 抽象化筋は「共通項発見ゲーム」というもので鍛えられます。パッと目に映ったもの等なにか2つのものの間に何か共通項がないか無理矢理にでも作ってみましょう。 具体化筋 - 繊細な違いにアンテナを立てろ 一見同じもの同士でもその違いを明確にする能力のことで、抽象化筋とは逆の能力ですね。 観察を通して微妙な違いを見出そうとすること、つまりその瞬間だけの違いを明確に見極めてそのタイミングでの適切な対応をすることが具体化筋の役割です。 どんなものでも時間によって変化するはずです。自分の組織のメンバーや技術について、時間をかけて観察してみましょう。 表現筋 - 心動かされる表現を模倣せよ 自分の感情や考えをうまく表現できず、他者との心からの意思疎通ができないという人もいるのではないでしょうか。 他者の優れた表現を徹底的にストックしましょう。そして、ストックした表現を実際に使ってみることです。これを繰り返すことにより感情と表現をつなぐ線が徐々に太くなっていくそうです。 学びたいことを探すには 前述した内容と被りますが、「好奇心駆動」で学ぶことを決めましょう。 しかし、好奇心がどうしても動かないというときもあるかと思います。そういうときは自分の中に無自覚に存在する「矛盾」に気づくことから始めましょう。人間は一貫性を望む生き物なので、この矛盾は大きな探究のエネルギーを生み出すそうです。 感想 「学ぶこと」という少々大きなテーマに関する本でしたが、技術の勉強にも活用できそうだと感じました。 特に最近はAIの急速な発達もあって、技術トレンドの移り変わりについていくのが大変です。「この流れについていかないといけないから」「業務に必要だから」ではなくもう少し自分の興味のあることを学ぶ比率を高めて良いのかなと思いました。 個人的な話ですが、「探究心を持って技術に向き合う」ということを今年の抱負にしていました。この本を読んで、方向性は間違っていなさそうで安心しました。独学のための筋トレを頑張っていこうと思います💪 最後までお読みいただきありがとうございました。