なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
Geekなぺーじ：エンジニアは下らない質問をする
「バナナはおやつに入るんですか？」という質問をしたことがあるエンジニアは多いと思います。 私も真っ先にそのような質問をした覚えがあります。 で、実際にバナナを持ってくる人がいるかというと、私は見たことがありません。 エンジニアって一般人から見ると変な、もしくは下らない質問が大好きな人種なのではないかと思う事があります。 エンジニアというよりもプログラマかもしれませんが、全ての事をswitch case文で考えて、条件分岐の白黒をはっきりさせたがってしまうのではないかと思うのです。 以前、マンション営業をする友人に「職業がエンジニアな人がお客さんだと面倒なときがある」と言われた事があります。 最後に契約書を確認する際に、非常に細かいところを確認したがって面倒であるそうです。 (私は細かく確認しない大多数の人の方が間違っているとは思いますが。。。) 細かい話になってくると、例えば受け渡しの前に
Geekなぺーじ : いいから殺せ。後はこっちでなんとかするから
IT業界って怖いですね～（棒読み） 何でそうなった？ そもそもの発端は、私が現在執筆中のLinuxネットワークプログラミング書に書いているコラムのための質問でした。 Wiresharkやtcpdumpを利用したパケットキャプチャによる通信プログラムのデバッグを解説する際にプロミスキャスモードとは何かという話を書いていたのですが、その最後にちょっとしたコラムを書くためのブレストとしてTwitterで質問をしました。 で、結局出来上がった原稿は以下のような感じです。 Twitterでコラムの内容を見たいと発言されている方がいらしたので、出版前ですが晒してしまいます。 コラム：ぁゃιぃ UNIX用語 (☆ 「あやしい」の部分は、xa xya イオタ xi です。) プロミスキャスモードを「無差別モード」と訳す場合が多いのですが、この「Promiscuos」という単語は性的な意味を含む英単語なので
Geekなぺーじ : 情報デリカシー
この前、知人と一緒に「情報の暴露」に関して歩きながら話していました。 個人的な付き合いで知り得た情報を、本人の了承無く、本人の意図しない公開された場所で暴露してしまう人がネット上で増えているのではないかという話題でした。 そこで、「そういった点に関しての情報リテラシ教育も必要なのかも知れませんね」という発言をしたところ、「それはリテラシの問題ではない。むしろデリカシーの問題だ」と言われて、今までモヤモヤとしていたものが急に晴れた気がしました。 確かに、個人的に経験した「他人による嫌な暴露」は、情報リテラシが高いと思われる人によって行われていました。 「何をされると人が嫌がるか」という視点が欠けているというのは、リテラシというよりも、デリカシーだと言われると非常に納得できます。 リテラシが高くてデリカシーが無い人が怖い オフ会などで同席して最も怖いのは、情報リテラシが非常に高くてデリカシーが
Twitterユーザ層が拡大すると発生しそうな何か:Geekなぺーじ
ふぁぼりんこよろしくです！ ぽちっとふぁぼり支援よろしくです！ ＠に素早く返信しないのはマナー違反 ReTweet推奨 ReTweetしないのは失礼 ReTweetするのは失礼 無断フォロー禁止！ 無断フォロー外し禁止！ フォローしてないのに発言に文句言うのはマナー違反 フォローせずにつぶやきを見るのはマナー違反 アナタのはつぶやきではなく会話なのでマナー違反 さっきの私のTweet最高だと思うんだけど何で○○は、ふぁぼらないの？？？ Twitterは無断リンクがはびこる悪のサービス フォロワーに配慮しない大量つぶやきはマナー違反 protectedアカウントにフォロー申請するのはマナー違反 ○○をフォローしない奴はモグリ ブロックして差し上げてセイセイしましたわ それは既出です ○ヶ月前に××さんが言ってましたね ○○に同意できる方だけがフォローして下さい フォロー行為は当方規約に同意し
キャズムを超えそうなTwitterについて色々:Geekなぺーじ
最近、Twitterがキャズムを超え始めてる気がしてなりません。 新聞やテレビでチラホラ「ツイッター」という単語が出現し始めていますし、今年5月ぐらいから急激に新規アカウントが増えている気がします。 私の周りでもフォロワーが5月ぐらいから急激に増加した人が多い気がします。 1. 政治家、芸能人が利用開始 アメリカのオバマ大統領が使っていたと解説されることが多いTwitterですが、日本でも政治家による利用が増えて来ています。 個人的な感想では、日本の政治家がTwitterを利用し始めたというニュースと供に急激にユーザが増えて行ったような感じさえあります。 「wikipedia : Twitter議員」 有名人や芸能人の参加も徐々に増えて行っています。 先日も歌手の広瀬香美氏がTwitterを開始していました。 芸能人コミュニティ内で「Twitterイイよ！」という話題が広がれば、さらに参加
全日本剣道連盟YouTubeチャンネルが開設されるまでの道のり:Geekなぺーじ
昨日、全日本剣道連盟(以後、全剣連)によるYouTubeチャンネル開設が発表されました。 第五十六回全日本剣道選手権大会 特設サイトとセットでの試みです。 財団法人全日本剣道連盟公式YouTubeチャンネル http://jp.youtube.com/ZennipponKendoRenmei 情報小委員会 実は私は約11年間全日本剣道連盟の情報小委員会の委員を行っており、YouTubeチャンネル開設に関しては中の人です。 情報小委員会は外部の専門家を集めた諮問機関であり、意思決定は出来ません。 全日本剣道連盟事務局とは別です。 基本的に世の中の現状と、どのような事ができるかに関しての意見をまとめる作業を中心に行っています。 情報小委員会には、私以外に各種経歴を持つ数人の方々がメンバーとして参加しています。 阿部晶人(SFC剣道サークル同期、現在オグルヴィ・ワン・ジャパン所属)と私が「若い」
Geekなぺーじ : 人生の全てはTCP/IPに学んだ
1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。 この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。 同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。 このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。 現実世界においても、きめ細かく応答を行う事が重要です。 メールなどを受け取っても、全く返事をしない相手
Geekなぺーじ : はてなブックマークを禁止する方法
念のため最初に書いておきますが、ブックマーク禁止やリンク禁止派ではありません。 純粋に技術的にどうするのだろうという興味で書いています。 「ある広告人の告白（あるいは愚痴かもね）: 推奨してるわけでは決してなくて、お嫌な人には拒否する権利があってもいいのかな、ということなんです。」を読んで、はてなブックマークを技術的に阻止するにはどうするのだろう？と疑問に思いました。 アクセスログを見ていると、はてな系のプログラムが出しているHTTP_USER_AGENTは「Hatena」で始まりそうな気がします。 例えば、ブックマークを行うと「Hatena Bookmark/1.0」というHTTP_USER_AGENTがやってきます。 ブックマークをさせないためには、そのエージェントに意地悪をすれば良いのではないかと考えました。 まず、最初にやろうと思ったのが、はてなロボットのリクエストに対して「404
失敗の可視化:Geekなぺーじ
「失敗を未然に防ぐアドバイスを適度に行う人」というのは非常に偉大な存在であるにも関わらず、なかなか評価されにくいのではないかと思う事があります。 逆に、「何かを大成功に導いた人」や「大失敗の後始末で落下傘部隊として投入される人」というのは目立つので、評価されやすい傾向があるのではないかと思います。 これらの違いは何だろうか？という疑問を脳内で考えていくと、「失敗の可視化」が足りないのではないかという結論に達しました。 失敗を適度に回避して問題なく事を遂行すると、全てがスムーズに進みます。 まるで、何も障害など無い状態で全てが行われたようにスムーズに全てが進むと、実は危険を回避してくれた人があまり目立たずに終わってしまいます。 これは、知らない土地で運転していて裏道を通った時に似ているのかも知れません。 「いつも渋滞をする」「普通なら1時間かかる」といった「失敗」の状態を知っているときに、裏
Geekなぺーじ：Web制作を誰に頼んだらいいのか検討がつかない(広告を出す場所の提案)
最近、知人(主に熱帯魚関係者)に「ホームページを作りたいんだけど、どこに頼めばいいの？」という質問を受けることが徐々に増えてきました。 会社のWebサイトを作りたいと考え続けているようですが、どこに発注したら良いか皆目見当がつかないそうです。 電話での勧誘は非常に多いそうですが、全く知らない相手で信用できずに頼めないという話を聞きます。 電話での勧誘の最近の傾向としては「タダで作りますよ」と言って誘うそうです。 「運営費は？」と聞くと数万円～数十万円と言われてしまうそうです。 そして、それを聞くと「結構です」と断わってしまうそうです。 Webサイトを作る側の気持からすると、どこかで収入を得ないと意味がないのは当然です。 それが初期の作る時か、運営するときに少しずつかというのはパラメータチューニングの問題だと思われます。 しかし、発注する側の発想としては「できるだけ安く」「できるだけ良いもの
こんなクライアントは嫌だ(Web製作編):Geekなぺーじ
フィクションです。 デザインセンスが一致しない デザインセンスが浦島太郎 小さいアニメーションGIFが大好き 丸投げ 社長を褒め称えるページに一番力が入っている 「俺様はお客様だ」と受注側を見下している やたら怖い 値切る事に非常に熱心 製作期間を非常に短くするのが大好き 時間/価格と品質がトレードオフであることを全く理解してくれない 異常に技術に詳しく、非常に細かい点を追求するのが大好き ただし、全体像を把握するのが嫌い 何故か「Webとは」という説教をされる 無駄に話が長い 自社の業務フローを知らない 社内(発注側)で肩身が狭い担当者が窓口 SEOの結果は数日で出ると思っている SEOは魔法のように何でも出来ると信じている SEOの裏技をこっそり教えろとひたすら言う 料金を踏み倒す 打ち合わせに行ったら自社製品を売りつけられそうになった 何故か出資を持ちかけられた 提携しているデザイナ
確実に失敗する方法:Geekなぺーじ
「10 Steps You Can Take To Guarantee Failure」という面白い記事がありました。 逆説的な表現がかなり笑えました。 以下に要約してみましたが、かなり削って意訳していますし、誤訳している可能性もあるので原文もご覧下さい。 1. 目標を曖昧にすべし 「もっと」や「ちょっと」という表現を多用した目標設定をしましょう。 例：「もっとお金が欲しい」「ちょっと体重を減らしたい」「何かの仕事をしたい」。 2. 目標を解りにくくすべし ゴールを曖昧にして、あれもこれも、あれでもいい、これでもいいとしとけば、何も達成できないようになれます。 3. 目標を後ろ向きに考えたり語ったりすべし 「できない」「難しすぎる」を多用して兎に角自分を蔑みましょう。 4. 途中経過をすっ飛ばして目標だけを考えるべし 地道にマイルストーンを積み重ねた目標を作ってしまうと失敗しにくくなるので
「Wikipedia:削除された悪ふざけとナンセンス」が楽しすぎる:Geekなぺーじ
「Wikipedia:削除された悪ふざけとナンセンス」が非常に面白いです。 架空人物 民明書房を思い出します。 ハナ＝モー＝ゲラーの法則 ウィキペディアデス ソレナンテ・エ・ロゲ ググレカス Wikipedia関連ネタ Wikiって略すな 引用： ウィキペたんからビンタを喰らいたくなければ、今すぐウィキペディアをWikiと略すことを止めましょう。･･･もっとも、彼女にぶたれるのがお望みなら別ですが。 「地球中心にならないように」 「ウィキ毒」 その他 2005年の「1区現象の例」も微妙に受けました。 「1区現象の例」 「削除された悪ふざけとナンセンス」に書いてあるネタで一番気に入ったのは以下の項目です。 「大人の事情」
Geekなぺーじ：勝者と敗者の違い
「The Big Difference between Winner and Loser」という記事がありました。 面白かったです。 勝者は間違ったときには「私が間違っていた」と言う。 敗者は「私のせいではない」と言う。 勝者は勝因は「運が良かった」と言う。例え運ではなかったとしても。 敗者は敗因を「運が悪かった」と言う。でも、運が原因ではない。 勝者は敗者よりも勤勉に働く。しかも時間は敗者より多い。 敗者はいつでも忙しい。文句を言うのに忙しい。 勝者は問題を真っ直ぐ通り抜ける。 敗者は問題の周りをグルグル回る。 勝者は償いによって謝意を示す。 敗者は謝罪をするが同じ間違いを繰り返す。 勝者は戦うべきところと妥協すべきところを心得ている。 敗者は妥協すべきでないところで妥協し、戦う価値がない所で戦う。 勝者は「自分はまだまだです」と言う。 敗者は自分より劣るものを見下す。 勝者は自分より勝
Geekなぺーじ：flickrの画像を使って広告を作って問題になった事例
企業がflickrから画像を広告に利用して問題が発生してしまった事例を発見しました。 「flickr ads」などの検索単語を色々入れていたら発見しました。 この問題は2ヶ月ぐらい前に発生し、現在まで続いているようです。 Virgin Mobiles Australiaがflickrで公開されている画像を使って広告を出したようです。 その広告の下の方に「flickr.com/photos/chewywong からの画像です」というような事が書いてあったそうです。 その広告を見たflickrユーザが「広告に利用されたね、おめでとう！」というような投稿をしました。 http://flickr.com/photos/sesh00/515961023/ Dump Your Pen Friend すると、写真をflickrに投稿した人と、撮影されている女性がコメント欄に書き込みをしました。 まず、最
会話によるバグ解決:Geekなぺーじ
私にとっては、バグを解決する最短の手段は、そのバグについて語る事だと思われます。 バグの相談を他人にするときに以下のような会話になることがあります。 ちょっと見てください ここが変になるんですが、心当たりないですか？ この変数の数値が期待していた値になってくれなくて、ここで落ちる 変ですよね？ あ！ 初期化し忘れました！ (自己解決) 結局相談された相手は、ぽかーんと座って終わりになります。 相手に説明するには、順序だててバグ内容を頭の中で再構築する必要があります。 その考察を行っている最中に勝手に矛盾点が頭の中に湧いてきます。 プログラミングをしていて悩んできたら、一人で悩まずに誰かと話せると解決も早くなるだろうと思います。 ただし、問題点もあります。 他人の時間を消費してしまうことです。 そのため、この技を使いすぎると嫌がられるという諸刃の剣です。 また、フリーランスなどの場合は、一人
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
ペアプログラミングに必要な知恵は全て幼稚園の砂場で学んだ:Geekなぺーじ
「"All I really need to know about pair programming I learned in kindergarten", Communications of the ACM, Volume 43, Issue 5 (May 2000) Pages: 108 - 114」という論文を読みました。 幼稚園(もしくは保育園)で習うような社会生活の基礎から、ペアプログラミングを遂行するときに注意すべき点を論じています。 ペアプログラミングは、二人で一緒にプログラムを書くという手法です。 XP(eXtreme Programming)などで利用されています。 面白かったので一部を抜き出して要約してみました。 さらに興味のある方は論文をご覧下さい。 何でも分け合うこと ペアプログラミングでは一つのものを二人が作り上げます。 片方がプログラムを書き、相方がレビューを続
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google maps簡単作成ツール：GMapCreator (v2 API 対応版)