MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
ステルスマーケティング的なクチコミについて:Geekなぺーじ
Web2.0的なCGMが登場してから、もうすぐ10年ぐらいが経過しそうですが、その派生として話題になることが多かったネット上の「クチコミ」がステルスマーケティングの温床となっている気が最近しています。 ここ数日、ステルスマーケティングを短縮した単語である「ステマ」というキーワードがGoogle Trendで「急上昇キーワード」として登場したりしています。 そんななか、日経新聞に「食べログ」での「やらせ投稿」に関しての記事が掲載され、ステルスマーケティング的な手法に関しての話題がさらに増えています。 日本経済新聞:「食べログ」にやらせ投稿 カカクコムが法的措置も 39業者特定 飲食店ランキング上げる狙い で、ここで書こうと思っているのは、ステルスマーケティング全般の話ではなく、そのサブセットである「クチコミ」に関してです。 ステルスマーケティングと関連してネットにおける「クチコミ」に関しての
【書籍】はじめてでも安心 コスプレ入門:Geekなぺーじ
拙著「インターネットのカタチ - もろさが織り成す粘り強い世界」の編集をされていたオーム社開発局の方(@ctakaoさん)が、実用技術書としてのコスプレ入門本という面白い本を編集されていて、それが遂に発売されるようです。 私は、その道はあまり良く知らないのですが、拙著「インターネットのカタチ」の書籍としての思想が似ているというのが感想です。 なお、この記事は「はじめてでも安心 コスプレ入門」を紹介してはいますが、視点としては「技術書の編集とはどういったものか」というようなものが多いので、ご注意下さい。 私が興味があるのはコスプレそのものじゃなくて、「コスプレ実用技術書」の編集/出版なので。。。 企画趣旨 本書の編集者と制作プロダクションの方(@ichika_akinoさん)に、本書の企画趣旨を聞いたところ「コスプレをやってみたいと思っている人はいるけど、入門書がないから」という回答を頂きま
人のせいにするのはそろそろやめませんか？:Geekなぺーじ
「わたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。 - 情報の海の漂流者」に非常に共感しました。 個人的な感想です。 なお、以下の内容は特定のブログ記事に対する批判というわけではないので、ご注意下さい。 マスゴミ、マスゴミと言う人は他人に良質な情報を届けるべく記事を書くか、もしくは良質の記事を探し出して他人に宣伝した方が生産的ではないでしょうか？ 問題意識を持った人が自律分散的に良質な記事を生成する活動してこそWebやネットの力が発揮されるのではないでしょうか？誰かに「世界を良くして下さい」と頼んでも、恐らく自分が望むような結果には到達出来ません。 各省庁のWebページを掘るだけで大量のPDFがあります。日本だけではなく海外にも目を向ければネタが枯渇することはありません。足りないのは人々が興味を持てるように噛み砕いて要約したり解釈する人ではないでしょうか？ 「これはひどい」と言
Geekなぺーじ : Google Public DNSについて調べてみた
Google Public DNSが発表されていました。 「Official Google Blog: Introducing Google Public DNS」 本当は書籍執筆〆切に追われていて首が回ってないはずなのですが、あまりに面白そうなので思わず調べてしまいました。 これって、DNSキャッシュのクラウド化なのだろうと思います。 利点は？ 利点は「パフォーマンス向上」と「セキュリティ向上」の２つがあるようです。 パフォーマンス Performance Benefits http://code.google.com/intl/ja/speed/public-dns/docs/performance.html 原稿〆切がヤバくて、ざっと流し読みをしただけなのであまり自信がありませんが、どうも世界規模で運用して、世界的にQueryが多い所を優先的にキャッシュ更新しておくので、非常に効率が
Geekなぺーじ : 情報デリカシー
この前、知人と一緒に「情報の暴露」に関して歩きながら話していました。 個人的な付き合いで知り得た情報を、本人の了承無く、本人の意図しない公開された場所で暴露してしまう人がネット上で増えているのではないかという話題でした。 そこで、「そういった点に関しての情報リテラシ教育も必要なのかも知れませんね」という発言をしたところ、「それはリテラシの問題ではない。むしろデリカシーの問題だ」と言われて、今までモヤモヤとしていたものが急に晴れた気がしました。 確かに、個人的に経験した「他人による嫌な暴露」は、情報リテラシが高いと思われる人によって行われていました。 「何をされると人が嫌がるか」という視点が欠けているというのは、リテラシというよりも、デリカシーだと言われると非常に納得できます。 リテラシが高くてデリカシーが無い人が怖い オフ会などで同席して最も怖いのは、情報リテラシが非常に高くてデリカシーが
Geekなぺーじ : 大変革が迫りつつあるインターネット
IPv4アドレス枯渇が迫りつつあります。 現状では、再来年ぐらいに枯渇する事が予想されています。 このIPv4アドレス枯渇は、恐らくインターネットアーキテクチャに対して非常に大きな影響を与えます。 今、この瞬間にあるインターネットインフラと、3年後のインターネットインフラは結構違う形をしているのではないかと推測しています。 以下、何故IPv4アドレス枯渇がインターネットアーキテクチャの大変革をもたらすのかと、この問題の背景を説明したいと思います。 2つに分離するインターネット インターネットは戦時中の物資が少ない状況においても通信網が維持出来る事を想定して設計されています。 そのため、専用機器だけではなく、ありあわせの機器を繋ぎ合わせて通信が実現できることが重要な要素でした。 また、電話のような回線交換方式ではなく、パケット交換方式を採用して様々な種類の通信を同時に行える事も設計の柱でした
10人のデザイナさんに駄目出しして頂きました:Geekなぺーじ
10名のデザイナの方々に「Geekなぺーじ」デザインダメだしをして頂けました！ 何か凄く豪華な会合をして頂いて非常に恐縮です。。。 昨晩早速いくつかサイトデザインを変更してみました。 以下に、会合は開催された経緯、そこでの指摘、昨晩の変更点を述べます。 会合が開催された経緯 「Geekなぺーじのデザインは駄目だろう」とずっと思っていたのですが、「どうすれば駄目ではなくなるか」に関してどうして良いのかが全くわからないという日々が数年間続いていました。 そして、キッチリとしたサイトを作れる方々に対する憧れというものがありました。 ある日、twitterで何度かやり取りをして、その後某新年会でお会いしたcremaさんが過去の勉強会資料(デザイン勉強会の資料を公開します。)を教えてくれました。 それを見て「これはすごい」と思ったのですが、「じゃあ、この考え方を自分のサイトに適用したらどうなるの？」
「素晴しいアイディア」が採用されない理由:Geekなぺーじ
「エンジニアによる技術革新を妨害するのはエンジニア」という記事はあまりに視点が一方的です。 「アイディアは全てが正しい」と主張する馬鹿が書いた文章としか思えません。 ここでは、アイディアを否定する立場側で考えてみました。 以下、あっさりとアイディアを否定される場合にあり得そうなことです。 技術的な面を全く考慮していない。 技術的に不可能な事を要求していませんか？ 運用に関して全く考慮していない。 作ったら終わりではありません。 作り終わってからが本番です。 財務面を全く考慮していない。 収支度外視で考えていませんか？ 詳細を詰めていない。 全てが大雑把ということはありませんか？ 人的資源を考慮していない。 実行するメンバーに関して何も考えていないということはありませんか？ 説明が足りていない。 十分な説明をしない状態で相手に「ご理解」を求めていませんか？ 情熱が足りない。 思いつきで言って
エンジニアによる技術革新を妨害するのはエンジニア:Geekなぺーじ
エンジニアによる技術革新に対する大きな障害は、非エンジニアではなくエンジニアであるという場合もあります。 技術者やエンジニアは、新しい発想に対して無駄にネガティブな意見を連発したり、単なる抵抗勢力でしか無くなる瞬間もあるような気がしています。 例えば、熟練度が高いエンジニアほど新しいものよりも、枯れたものを好む傾向があるような気がします。 以下、エンジニアによる抵抗勢力的発言としてありそうなものを考えてみました。 なお、フィクションなのでご注意下さい。 (自分が過去にやって「あれは自分が間違っていた」と思ったことが一部含まれたりしているわけではないのでご注意下さい。そんなことはありません。) 1.「先行事例が既にあるよ」 ちょっとでも似たようなものがあれば「先行事例があるから無駄」という意見を言う人がいます。 「このような先行事例がある」というアドバイスは非常にありがたいのですが、「やるの
Geekなぺーじ : エンジニアが見落としがちなこと
過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く
プログラマが席を離れる理由:Geekなぺーじ
コーヒーを入手するため 眠気覚まし コンパイルしているから makeを走らせた cvs update中(svnその他もあり得る) 設計が思いつかないから アルゴリズムが思いつかないから 良い書き方が思いつかないから トイレ おやつの時間だから テストスクリプトが走っているから 現実逃避 部長が不穏な動きをしている 身の危険を感じた 席を離れたプログラマが帰ってこない理由 スペースの個数に関して議論していた タブがスペース何個かを議論していた クラス名や関数名を大文字で開始するか小文字で開始するかを議論していた 開発言語を何にするかの議論がまとまらなかった GPLやBSDライセンスに関する上司の理解が得られず、激しい議論をしていたから すれ違いざまにWordの使い方を聞かれたけど、どうしても問題が解決しなかったため 同僚のPCがブートしなくなったため タバコ部屋で開発会議が勃発したため 先輩
ブログ:Geekなぺーじ
Interop 2023のShowNetバックボーン詳解 Interop Tokyo 2023のShowNetバックボーンに関して、ShowNet NOCの中村遼さんからの寄稿を頂きました。 詳細であり、かつ、わかりやすい素晴らしい解説、ありがとうございます！ Interop 2023のShowNetバックボーン 続きを読む... Interop Tokyo 2023 ShowNet取材動画 今年のShowNetは、初の動画取材にチャレンジしました。 これまで、ShowNetの取材をしていて、「この取材で一番楽しんでいるのは自分だな」と感じていました。 例年、ShowNet NOCの方々や、その他専門家の方々から色々なお話を伺って記事を書くのですが、取材の過程で話が凄く盛り上がっていく瞬間というのが多く、「この瞬間の楽しさ、というか熱量、を文章という形にしてしまうと伝えきれない」と感じてい
JavaScriptを使ってイントラネット内を外から攻撃する方法:Geekなぺーじ
「Hacking Intranet Websites from the Outside」という講演が2006年にありました。 Black Hatでの講演です。 以下に説明する手法は既に公開されてある程度時間が経過している情報なので、ご存知の方にとっては既に古いとは思います。 詳細はプレゼン資料をご覧下さい。 概要 ファイアウォールなどに守られたイントラネットやホームネットワークの内部を攻撃する手法が解説してありました。 JavaScriptの基本仕様を組み合わせて情報を収集するというものでした。 最終的には、プリンタから印刷を行ったり、ルータの設定を変更するなどの攻撃が可能になるようです。 それ以外にも、Web経由で設定変更が出来るものは状況によっては影響されるかも知れません。 プレゼン後半ではCSRF(XSRF, cross-site request forgery)も解説されていました
Adsenseを貼り付けているだけで評判が落ちてしまう恐れ:Geekなぺーじ
Google社のAdsenseを貼り付けているだけで、運営主体の評判が落ちてしまう可能性があるようです。 以前から良く言われている話ではありますが、個人的には「気にし過ぎ」だと思っていました。 最近、残念ながらこれが気のせいでは無い事がわかってきました。 もう少し正確に言うと「業界によっては問題になり得る」という事がわかってきました。 いわゆる「情報商材」が表示されると。。。 私は熱帯魚ショップとのレベニューシェアという形で熱帯魚サイトを運営しています。 それらのサイトではGoogle社のAdsense広告を貼り付けてあります。 広告として表示されるものの多くは、水槽や観賞魚販売などコンテンツに適合したものです。 ここら辺は流石だと思います。 しかし、時折いわゆる情報商材系の怪しげな広告が表示されます。 「月額100万円儲かります」とか「素人でも即お金儲け」系の奴です。 「神秘の力で水か綺
オープンソースに貢献する日本人エンジニアが少ない理由:Geekなぺーじ
Mozilla Japanの金井玄氏のブログで「Open source contributors in Asia」という記事が書かれていました。 アジア地域では、OSS(Open Source Software)を使う人が多いのに貢献が少ないのは文化的な要因が大きいのではないかと書かれています。 Linux FoundationのJim Zemlin氏とLinus Torvalds氏の対談の中でTorvalds氏が文化的側面が大きいのではないか、と述べている点に注目しています。 原文では、じゃあ文化的側面とは何だ？という事に関しては明確に書かれていない気がします。 原文は「アジア人」とひとくくりにされていますが、個人的には日本とその他のアジア地域で「文化的側面」が同じとはあまり感じられなかったので、とりあえず、「日本人」というカテゴリで思いつくだけ列挙してみる事にしてみました。 思いつきで
Geekなぺーじ : 良いプログラマの見分け方
「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある
Geekなぺーじ : オーム社開発部での開発体制
オーム社開発部さんでの本の作り方を取材させて頂きました。 社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。 ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。 全体的にこの体制で行われているわけではないそうなので、ご注意下さい。 取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。 Subversionでバージョン管理 著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずに本が完成するという案件もあるそうです。 フォントなどの問題から、本番環境でのPDF作成はオーム社開発部で毎日行っており、毎
プログラマとは:Geekなぺーじ
例外を考える職業であり、 本流から外れた些細な出来事に関しても気になってしかたがなく、 ついつい会議などにおいても余計な事を口走り、 非プログラマから冷たい目で見られる事もしばしばである。 問題が発生した時には、全身全霊を持って問題発生箇所の特定に勤め、 目を皿にしてコードを眺めたりするが、契約等の問題によりソースコード閲覧権が認められていない場合には、 クラッカー的に様々な実験行動を繰り返しつつ、ファーブルがフンコロガシを観察するのように注意深く結果を見守り、 問題発生箇所の予測を繰り返すが、最終的には「ここが変じゃない？」と他者に詰め寄るという行動を好む。 長時間コンピュータの前に座り続ける事が多く、非プログラマからは「目が悪くならない？肩こらない？」と聞かれることが多いが、 プログラムを書く事自体を苦痛と思っていない間は不思議と目も疲れず、肩もこらないという特技の持ち主である場合もあ
Geekなぺーじ : Rubyネットワークプログラミング
ここでは、Rubyによるネットワークプログラミングの説明を行いたいと思います。 ここで対象としている読者は、ネットワークプログラミング初心者（もしくは入門者）です。 TCP 簡単なTCPサーバとクライアント TCPクライアント(エラー処理付き) 何度も受信できるTCPサーバ TCPサーバ(acceptした相手の確認) UDP UDPを使う UDPでブロードキャストを使う UDPでマルチキャストを使う(マルチキャストを送信する) UDPでマルチキャストを使う(マルチキャストを受信する) UDPでマルチキャストを使う(TTLを設定する) Web 簡単なHTTP GET（Net::HTTP） HTTP HEADと全てのHTTPヘッダの表示（Net::HTTP） HTTP POST（Net::HTTP） 簡単なRSSクライアント その他 IO::selectを使う IPアドレスからホスト名への変換
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
