Geekなぺーじ : Google Public DNS解説と個人的妄想
前回書いたGoogle Public DNSに関する記事があまりに説明不足なので、補足文章を書く事にしました。 今回のGoogle Public DNSは、単なるオープンDNSサービスでは留まらず滅茶苦茶凄過ぎていて、ある意味インターネット全体のありかたを変えてしまう可能性さえあると個人的には思っています。 何故そう思っているかを含めて、色々書いてみました。 以下の文章は多くが公式発表からの引用ではなく、その他の外部観測情報を元にした推測や個人的な妄想が入り交じっているので、内容に関しては各自で考えて判断をお願いします。 Google Public DNSでウェブ閲覧が高速化するの？ とりあえず、背景や技術はどうでも良いから「高速化するかしないかだけ知りたい」という方々が非常に多い気がするので、個人的なGoogle Public DNS高速化に関しての考えを最初に書きます。 「Google
「勉強になりました」は禁句:Geekなぺーじ
昔、会社で「勉強になりました」と言ったら注意された事がありました。 曰く「この場でのあなたは専門分野の立場で考える事が仕事という名目なので勉強であっては困る」という事でした。 「勉強になりました」という一言は、私自身はあまり深く考えずに口から出た言葉でした。 博士課程が終わって就職して、新人研修などをしていたため「新人根性」が染み付いていた部分も否定は出来ません。 人によっては「勉強という単語の何が悪いんだ！」と思うかも知れません。 しかし、私は自分に対してそれを言って頂けた上司の方には今でも非常に感謝しています。 あの瞬間に、「勉強になりました」とか「今日は勉強したいと思います」と言ってはいけない立場と、言うと誰かに迷惑をかけてしまうシチュエーションがあるという事実を学びました。 (「勉強になりました」と言っても何ら問題が無い状況も多いのでご注意下さい。) 外に出たときは、例え自分に知識
10人のデザイナさんに駄目出しして頂きました:Geekなぺーじ
10名のデザイナの方々に「Geekなぺーじ」デザインダメだしをして頂けました！ 何か凄く豪華な会合をして頂いて非常に恐縮です。。。 昨晩早速いくつかサイトデザインを変更してみました。 以下に、会合は開催された経緯、そこでの指摘、昨晩の変更点を述べます。 会合が開催された経緯 「Geekなぺーじのデザインは駄目だろう」とずっと思っていたのですが、「どうすれば駄目ではなくなるか」に関してどうして良いのかが全くわからないという日々が数年間続いていました。 そして、キッチリとしたサイトを作れる方々に対する憧れというものがありました。 ある日、twitterで何度かやり取りをして、その後某新年会でお会いしたcremaさんが過去の勉強会資料(デザイン勉強会の資料を公開します。)を教えてくれました。 それを見て「これはすごい」と思ったのですが、「じゃあ、この考え方を自分のサイトに適用したらどうなるの？」
Webを介した親子のコミュニケーション:Geekなぺーじ
Web等を介した親子コミュニケーションが今後増えて行くのかぁと、漠然と思いました。 何か、インターネットとWebの進化によって家庭の中までも変化しいく時代が近づいているのかなぁと。 最近、「子供のmixi読んでる」とか、「親のブログを読んでる」とか、「Twitterで親にfollowされているらしいけど誰だかわからない」とか「Twitterで娘/息子にfollowされている」とか、Webを介して直接的ではないコミュニケーションを「している」と発言している事例に出会うことがあります。 それって凄い事じゃないか？ それを何度か見ているうちに、「これって凄いことだなぁ」と思うようになりました。 というのは、例えば自分が中学ぐらいのときにTwitterがあったとして、親もTwitterをやっていて、それをfollowしていたらどうなってたんだろうか？と思うわけです。 親が会社で嫌な事があった事をつ
Seagate HDDが突然死する可能性:Geekなぺーじ
2008年12月以前に発売されたSeagate HDDファームウェアにバグがあり、HDDが突然死する可能性があるようです。 ナレッジベースに記載されている公式発表によると、突然死後のHDDからデータを取り出せないと書いてあります。 （原文：Once a drive has failed, the data is inaccessible to users） 影響を受けるHDDの型番は以下の通りです。 結構危ないと思うので、手元の環境でも確認をお進め致します。 Barracuda 7200.11 ST31000340AS ST31000640AS ST3750330AS ST3750630AS ST3640330AS ST3640630AS ST3500320AS ST3500620AS ST3500820AS ST31500341AS ST31000333AS ST3640323AS ST
エンジニアによる技術革新を妨害するのはエンジニア:Geekなぺーじ
エンジニアによる技術革新に対する大きな障害は、非エンジニアではなくエンジニアであるという場合もあります。 技術者やエンジニアは、新しい発想に対して無駄にネガティブな意見を連発したり、単なる抵抗勢力でしか無くなる瞬間もあるような気がしています。 例えば、熟練度が高いエンジニアほど新しいものよりも、枯れたものを好む傾向があるような気がします。 以下、エンジニアによる抵抗勢力的発言としてありそうなものを考えてみました。 なお、フィクションなのでご注意下さい。 (自分が過去にやって「あれは自分が間違っていた」と思ったことが一部含まれたりしているわけではないのでご注意下さい。そんなことはありません。) 1.「先行事例が既にあるよ」 ちょっとでも似たようなものがあれば「先行事例があるから無駄」という意見を言う人がいます。 「このような先行事例がある」というアドバイスは非常にありがたいのですが、「やるの
議論は怒りながらやるものではない:Geekなぺーじ
自戒を込めて。。。 会議で議論を戦わせるのは良いことですが、会議後にギクシャクするのは悪い事です 反対意見を出すために反対意見を出すのはやめましょう 大抵は論破されたとしても給料が下がるわけではありません 冷静さを失ったら負けです 深呼吸を忘れずに 間違っているのは相手かも知れませんし、間違っているのはあなたかも知れません 「意味わかんない」「わけわからない」「合理性が無い」「馬鹿なんじゃないか？」などの表現は議論には必要がありません 攻撃的な表現をした直後に自分の間違いに気がつくことほど気まずい瞬間はありません 自分の間違いに気がついた瞬間に簡単な謝意を表明すると楽になります。時間と共に謝意を伝えにくくなります。 怒りながら議論を繰り返していると会議に呼んでもらえなくなるかも知れません 全く異なる視点が入る事もありますが、何も考えずに全否定するのはやめましょう 他分野の人による何気ない視
「素晴しい提案」をしてしまうとき:Geekなぺーじ
一見もっともらしい「素晴しい提案」をしてしまい、それが元で崩壊へのデスマーチをトリガーしてしまう状態というのはどんなものだろうか、と考えてみました。 技術的な視点で見ると非常に素晴しい反面、ニーズが全く無かったがために時間だけを無駄に浪費してしまい、全てが無に帰する状況があるかも知れません。 一見素晴しい解決方法に見えた反面、実は恐ろしく大きな穴が存在しており、その秘孔を突かれてバラバラにという状況があるかも知れません。 そして、その「素晴しい意見」を述べている人は、その人なりに信じるものを善意で発言している事が多いかも知れません。 ただし、「素晴しい提案」によって一致団結が発生し、後に「あれはやばかった」と酒の肴にしつつも大成功という結果に繋がる可能性も捨てきれません。 結局、「最悪の発案」だったか「世紀の発案」だったかを分けるのは結果なのかも知れません。 以下、一部自戒を込めて。。。
Geekなぺーじ : 失敗できる時代を生きていた人は幸せ
「新人が育たない」「同じ人がずっと管理/運営をし続けている」という話(悩み)を聞く事があります。 この話を聞く度に、教育や引継ぎは時として非常に難しいと思うとともに、失敗できる時代を生きれた人はある意味幸せなのではないかと思う事があります。 ある特定の作業がインフラ化する前から色々と出来た人は、恐らく様々な実験を行いながら経験を積んでいます。 失敗が許される環境、許されない環境 インフラ化する前であれば「失敗」が許されます。 失敗をする事は良いことではありませんが、それによって誰かの人生が終わるぐらいの事にはなりません。 大目玉を喰らって激しく落ち込む程度で済みます。 しかし、利用者が多くなり、インフラ化すると実験をする事は許されなくなり、無難に運営する事が第一になってしまいます。 自由に楽しく学ばせる事よりも監視下で失敗をさせない事に主眼が置かれがちです。 自由に楽しく学ばせるための箱庭
Geekなぺーじ : 契約交渉TIPS
「Tips on Negotiating a Great Work Contract」という記事がありました。 基本的な話なのかも知れませんが、面白いと思いました。 いや、でも交渉のプロと交渉はしたくないと思える文章でした。 以下、要約です。 誤訳などが含まれる可能性があるので、原文を是非ご覧下さい。 1. お金の話をすることをためらうべからず お金の話を躊躇する人がいますが、はっきりと言わないと大きく損をする場合があります。 相手が経験豊富なネゴシエーターであれば、そこを突いてくるでしょう。 2. 感情を表に出すべからず 経験豊富なネゴシエーターは感情を煽って交渉を有利に進めようとします。 相手が怒鳴りだしても冷静さを保ちましょう。 エゴやプライドは交渉の席についた時点で懐深くに仕舞いましょう。 3. 「ルール」に縛られるべからず 経験豊富なネゴシエーターは「ルールを守る」という心理を利
Adsenseを貼り付けているだけで評判が落ちてしまう恐れ:Geekなぺーじ
Google社のAdsenseを貼り付けているだけで、運営主体の評判が落ちてしまう可能性があるようです。 以前から良く言われている話ではありますが、個人的には「気にし過ぎ」だと思っていました。 最近、残念ながらこれが気のせいでは無い事がわかってきました。 もう少し正確に言うと「業界によっては問題になり得る」という事がわかってきました。 いわゆる「情報商材」が表示されると。。。 私は熱帯魚ショップとのレベニューシェアという形で熱帯魚サイトを運営しています。 それらのサイトではGoogle社のAdsense広告を貼り付けてあります。 広告として表示されるものの多くは、水槽や観賞魚販売などコンテンツに適合したものです。 ここら辺は流石だと思います。 しかし、時折いわゆる情報商材系の怪しげな広告が表示されます。 「月額100万円儲かります」とか「素人でも即お金儲け」系の奴です。 「神秘の力で水か綺
オープンとクローズ:Geekなぺーじ
オープンとクローズの使い分けや、その割合というのは人によって違います。 どうあるべきかという思想も全く違います。 しかし、この相反する2つの情報管理方法の使い分け方で色々な結果がかなり変わってくると思います。 品質に対するイメージを上昇させるためにcloseに 製品やサービスを作るときには、できるだけ完成度を上昇させてからオープンにした方が品質に対するイメージは上昇します。 多くの工業製品は、製品の完成が近づいてきて初めてプレスリリースをします。 WebサイトやWebサービスなども、完成度を高めてから最初のリリースをした方が注目度は上昇します。 一方、「作るぜ！」と宣言して創生期から全てを公開するという手法もあります。 この手法は、コミュニティを形成しながら創作も行えることと、多数の目が入る事によって最終的な品質は高くなるという利点があると思います。 all openという選択肢 全てをオ
オーム社開発部の方とのやり取り:Geekなぺーじ
先日、本ブログにて「退職報告及び自己紹介」という記事を書いたところ、マスタリングTCP/IP RTP編を監訳したときのご担当の方からメールを頂きました。 実はこのブログの読者だったそうでが、自己紹介文章を読んでびっくりしたとの事でした。 今回のやり取りに関して書く了承を頂けたので、書いてみました。 何度かメールをやり取りしていましたが、今度おじゃまして色々お話を聞かせて頂くお願いをしました。 今回は、お時間を頂戴してフリーな打ち合わせという形でお邪魔させて頂く予定です。 後日、先方の了解を得られた範囲内で公開したいと思っていますが、まだどうなるかは未定です。 RTP本の監訳をしているときに、昔の技術出版業界と最近の技術出版業界というような話や、出版の流れなどを色々教えていただけて面白かった記憶がありました。 それも、もう5年以上前になるのですが、当時とは多少編集方法が変わってきているようで
研究所からイノベーションが生まれない理由:Geekなぺーじ
「Why research labs fail at innovation」という記事がありました。 多くの研究所が犯している間違いをまとめていました。 面白かったので要約してみました。 原文には著者のバイアスが多分に含まれると書いてありました。 確かに多少偏っているかもしれませんが、言いたい事は何と無くわかるような気がしました。 ただ、元記事の英語の言い回しなどで理解できない部分が多かったので誤訳や勘違いが入っている可能性が高いです。 詳細は原文をご覧下さい。 なお、これは恐らく悪い例であって、イノベーションを産み出している良い研究所は以下の内容の範疇外なのだと思います。 念のため。 アイディアを考えるのは簡単 面白い案を考えるのは誰にでもできます。 面白いことを考えているR&Dグループや大学はたくさんあります。 予算さえあれば、その案からプロトタイプを作れる人は世の中に大量にいます。
Geekなぺーじ：エンジニアは下らない質問をする
「バナナはおやつに入るんですか？」という質問をしたことがあるエンジニアは多いと思います。 私も真っ先にそのような質問をした覚えがあります。 で、実際にバナナを持ってくる人がいるかというと、私は見たことがありません。 エンジニアって一般人から見ると変な、もしくは下らない質問が大好きな人種なのではないかと思う事があります。 エンジニアというよりもプログラマかもしれませんが、全ての事をswitch case文で考えて、条件分岐の白黒をはっきりさせたがってしまうのではないかと思うのです。 以前、マンション営業をする友人に「職業がエンジニアな人がお客さんだと面倒なときがある」と言われた事があります。 最後に契約書を確認する際に、非常に細かいところを確認したがって面倒であるそうです。 (私は細かく確認しない大多数の人の方が間違っているとは思いますが。。。) 細かい話になってくると、例えば受け渡しの前に
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
Geekなぺーじ：技術の盗み方
新入生や新社会人として組織に入ったり、他の組織から畑違いの場所に異動すると、ゼロからのスタートになるときがあります。 そのときに、先輩からいかにして技術を「盗む」かが重要な要素になると思われます。 ここでは、自分の養分として吸収するために、先輩から技術を引き出す一手法を紹介したいと思います。 先輩から見て教え易い後輩や、ついつい必要以上に色々教えてしまう後輩などがいます。 今回は、そのような人の特徴を考えたり、過去の私が失敗したと思われる点を思い出しながら書いてみました。 ここで紹介する方法は、あくまで方法の一つであり偏っています。 性格によって向き不向きがあると思います。 また、あまりに露骨にやり過ぎると嫌われてしまう場合もあるのでご注意下さい。 あまり参考にはならないかも知れませんが、まあ、許してください。 やる気を見せる 非常にやる気があって、色々やっている人を見るとついつい応援した
ペアプログラミングに必要な知恵は全て幼稚園の砂場で学んだ: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ページを開く
怒り:Geekなぺーじ
Geekなぺーじ