課程博士(コースドクター)に関して色々と話題が多い昨今ですが、個人的には「何となく行く人はやめるべきだし、得るものがある人は進むべき」と考えています。 なお、以下の文章は論文博士(社会人ドクターなど)は範疇外です。 また、基本的に博士過程を念頭に書いていますが、一部は拡大して学部や修士も同様の考えかたをしても良い場合もあるかも知れません。 1.「けものみち」を進むつもりで 大学、大学院までであれば普通の就職もできる場合が多いです。 しかし、博士課程に進学すると、いわゆる「普通の」就職はしにくくなります。 そのため、博士課程に進学するのであれば、いわゆる「けものみち」に突き進むかも知れないという自覚を持ちましょう。 博士課程に進学した事で自分の名前を売ったり、様々な人脈が形成できるように努力しないと、後で苦労するかも知れません。 就職するにしても、学会やその他活動などで既に知人が居て半分コネ

昔から後輩や知らない学生がネット上で色々と撒き散らしているのを見ることがあります。 本人が気づいていないだけである場合もあるので、今回まとめて書いてみる事にしました。 なお、学生であろうが無かろうが気をつけた方が良いと思われるものも含まれます。 何故ネット上で気を抜いてはいけないのか そもそも、何故ネット上で公開する内容に気をつけなければならないのでしょうか？ それは公開することで不利益が生じる可能性があるからです。 高校入試で落ちるかも知れない 最近、茶髪・眉剃りをしていた受験者を高校が落とすという事件がありました。 今回の事件は茶髪・眉剃りが原因でしたが、近い将来「ネット上での言動が高校入試に影響」という事件が発生するだろうと予測しています。 「高校入試、茶髪・眉そりチェックし不合格　神奈川の県立」 就職活動に影響を与えるかも知れない 就職活動に影響を与える恐れがあります。 実名を公開

たまに「部下がついてこない」「後輩がついてこない」という愚痴を聞くときがあります。 ついてくる、ついてこないの違いは何なんだろうと不思議に思うことがありますが、今回は「ついてこない」という事に関してどのような理由がありそうか考えてみました。 「ついてくる/ついてこない」問題で厄介なのは、「ついて来い」と言っている側と「ついていく」側が双方共に相手に不満を持っている場合です。 立場の違いがそうさせているだけで、どちらも悪くないような場合もあり得ます。 難しい問題ですよね。 なお、以下はあまり根拠はありませんし、状況によって全くあてはまらない場合もあると思うのでご注意下さい。 1. ビジョンを共有できていない 「全体の中のどの部分をやっているのか」「何でそれをやっているのか」「それをやるとどのように世界を変えれるのか」が全く伝わっていないのかも知れません。 やる気を出したり、「ついていく」状態

過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く

ここでは、私なりのブログに関する考え方/運営ノウハウ/ネタの探し方/その他を解説します。 ここで紹介する方法は私個人による1手法に過ぎません。 全ての状況に対応できるわけではありませんし、考え方が合わない場合も多々あると思います。 ブログは単なるツールであり器です。 ブログと一言で言っても運営者や状況によって、全く異なる物になります。 何気ない日記を書いて楽しむためのものとしてブログを使っている人もいれば、メモ帳代わりとして使っている人もいれば、戦略的なマーケティングツールとして使っている人もいます。 ここで紹介する手法や考え方は、多少極端な面を含んでいますが、 各手法や思想を各自で派生させたりして独自のブログ論を形成して頂ければ幸いです。 ブログを開始する前に 何のためにブログをやるのか考える テーマを考える ブログ名(サイト名)を考える 匿名/実名 サイト運営者名を考える ブログサービ

「Motivating Young Employees」という記事がありました。 会社で若者のやる気を引き出すにはどうすれば良いかに関して語っています。 アメリカ人を前提として書いてあるので日本とは違う部分もあると思われますが、結構同じような考えの部分もありそうだと思いました。 結局は各個人の個性に合わせての話になると思うので、ケースバイケースなのでしょうが、面白い内容だと感じました。 なお、原文に掲載されているイメージ写真があまり若者に見えないのは気のせいなのかどうかが最後まで気になりました。 以下、要約です。 誤訳などが含まれる可能性があるので是非原文をご覧下さい。 多くの経営者は給料を上昇させる事が重要と考えているが、 若者は給料に関する現実を知っており、現実的な給料で満足する。 若者のやる気を出すには、企業から感謝されていると知らせる事が重要。 特に最近の若い人は顕著にこの傾向があ

「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある

自分の過去を振り返りながら、学生時代にしておけばよかったことや、学生時代の経験で自分の糧になったと思われることを列挙してみました。 以下、学生のうちにしておくべきと私が勝手に思っていることです。 1. 大失敗 様々な事に挑戦しましょう。 そして、失敗しましょう。 恐らく失敗をしようとして失敗をする人は、あまりいません。 しかし、経験がない事に挑戦すると初めは誰でも失敗します。 背負っている物が少ないうちにする失敗は、その後の財産になります。 成功よりも失敗からの方が多くを学べます。 また、成功よりも失敗の方が理由を分析しやすい傾向があると思われます。 (成功の分析結果は単なる勘違いである場合もあるかも知れません) ただし、人生を台無しにしてしまうような取り返しのつかない失敗はやめましょう。 失敗し過ぎない程度に多くの失敗を重ねましょう。 2. 恥ずかしいおもいをする 知らずにしでかして、恥

1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。 この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。 同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。 このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。 現実世界においても、きめ細かく応答を行う事が重要です。 メールなどを受け取っても、全く返事をしない相手

「Why research labs fail at innovation」という記事がありました。 多くの研究所が犯している間違いをまとめていました。 面白かったので要約してみました。 原文には著者のバイアスが多分に含まれると書いてありました。 確かに多少偏っているかもしれませんが、言いたい事は何と無くわかるような気がしました。 ただ、元記事の英語の言い回しなどで理解できない部分が多かったので誤訳や勘違いが入っている可能性が高いです。 詳細は原文をご覧下さい。 なお、これは恐らく悪い例であって、イノベーションを産み出している良い研究所は以下の内容の範疇外なのだと思います。 念のため。 アイディアを考えるのは簡単 面白い案を考えるのは誰にでもできます。 面白いことを考えているR&Dグループや大学はたくさんあります。 予算さえあれば、その案からプロトタイプを作れる人は世の中に大量にいます。

「10 Steps You Can Take To Guarantee Failure」という面白い記事がありました。 逆説的な表現がかなり笑えました。 以下に要約してみましたが、かなり削って意訳していますし、誤訳している可能性もあるので原文もご覧下さい。 1. 目標を曖昧にすべし 「もっと」や「ちょっと」という表現を多用した目標設定をしましょう。 例：「もっとお金が欲しい」「ちょっと体重を減らしたい」「何かの仕事をしたい」。 2. 目標を解りにくくすべし ゴールを曖昧にして、あれもこれも、あれでもいい、これでもいいとしとけば、何も達成できないようになれます。 3. 目標を後ろ向きに考えたり語ったりすべし 「できない」「難しすぎる」を多用して兎に角自分を蔑みましょう。 4. 途中経過をすっ飛ばして目標だけを考えるべし 地道にマイルストーンを積み重ねた目標を作ってしまうと失敗しにくくなるので

レベル0 レベル0の人はプログラムを一度も書いた事がありません。 レベル0の人は、プログラミングとはどのような作業なのか想像もつきません。 世の中のほとんどの人は、このレベルです。 レベル0の人は、プログラムをかけるプログラマはいわゆるオタクだと思っています。 ありがちな発言 「プログラミングできるんだ。ふーん。凄いね。」 レベル1 レベル1の人は学校の授業の課題としてプログラムを書いた事があります。 しかし、あまりプログラミングには興味を持てず、コンピュータに詳しい知人に課題をやってもらったり、教えてgooなどで課題の答えを聞いたりしているので、仕事としてプログラミングはできません。 ありがちな発言 「教えて下さい」 レベル2 このレベルの人は、2度ほど何かの小規模プログラムを書き上げた経験を持っています。 段々とプログラミングへの興味が広範囲に及ぶようになり、勉強をするのが楽しくて仕方

「The Big Difference between Winner and Loser」という記事がありました。 面白かったです。 勝者は間違ったときには「私が間違っていた」と言う。 敗者は「私のせいではない」と言う。 勝者は勝因は「運が良かった」と言う。例え運ではなかったとしても。 敗者は敗因を「運が悪かった」と言う。でも、運が原因ではない。 勝者は敗者よりも勤勉に働く。しかも時間は敗者より多い。 敗者はいつでも忙しい。文句を言うのに忙しい。 勝者は問題を真っ直ぐ通り抜ける。 敗者は問題の周りをグルグル回る。 勝者は償いによって謝意を示す。 敗者は謝罪をするが同じ間違いを繰り返す。 勝者は戦うべきところと妥協すべきところを心得ている。 敗者は妥協すべきでないところで妥協し、戦う価値がない所で戦う。 勝者は「自分はまだまだです」と言う。 敗者は自分より劣るものを見下す。 勝者は自分より勝

「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。

「Small ISVs: You need Developers, not Programmers」という記事がありました。 2003年5月の記事のようです。 半分根性論な気もしましたが、この記事の視点は非常に面白かったです。 そうなのかもと思う面もありました。 この記事を書いている人は25人の社員がいるソフトウェアベンダを運営しているそうです。 6年間会社を続けてわかったこととしては「小規模な企業にプログラマは居てはならない」だそうです。 必要なのは「プログラマ」ではなく「開発者」だそうです。 以下が駄目な「プログラマ」の特徴だそうです。 小規模企業では以下のような人は「いらない」そうです。 新しい機能を実装することばかりする たまにバグを修正する 仕様書を書かない ドキュメンテーションを書く手伝いをしない 自動化されたテストを作成しない テスト実行を手助けしない 開発環境を最新に保たな

新入生や新社会人として組織に入ったり、他の組織から畑違いの場所に異動すると、ゼロからのスタートになるときがあります。 そのときに、先輩からいかにして技術を「盗む」かが重要な要素になると思われます。 ここでは、自分の養分として吸収するために、先輩から技術を引き出す一手法を紹介したいと思います。 先輩から見て教え易い後輩や、ついつい必要以上に色々教えてしまう後輩などがいます。 今回は、そのような人の特徴を考えたり、過去の私が失敗したと思われる点を思い出しながら書いてみました。 ここで紹介する方法は、あくまで方法の一つであり偏っています。 性格によって向き不向きがあると思います。 また、あまりに露骨にやり過ぎると嫌われてしまう場合もあるのでご注意下さい。 あまり参考にはならないかも知れませんが、まあ、許してください。 やる気を見せる 非常にやる気があって、色々やっている人を見るとついつい応援した

Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい

「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定

Webエンジニアやネットワークエンジニアなど、インターネットに関わるIT系エンジニアは「DNSがよくわかる教科書」を読むことをお勧めします。 「DNSがよくわかる教科書」は、JPRSの方々が執筆しています（献本ありがとうございました）。 森下さんによると、この本は約1年半前から書き始めているようですが、DNSと日々向き合っているエンジニアの方々（DNSに人生をかけている人も）が時間をかけて書いた本だけあって、「わかりやすい」という方向性でありながら、かなりガチな内容です。 副題に「初心者エンジニア必見！やさしく、詳しい。これがDNS入門の決定版！仕組み・用語・運用をゼロから丁寧に解説」と書いてありますが、まさにその通りの内容です。 たとえば、BINDなどの特定の実装や、どこかの特定の事業者が提供しているサービスに偏った解説になっておらず、DNSそのものの概念や仕組みなどを丁寧に解説していま

書名：ピアリング戦記 日本のインターネットを繋ぐ技術者たち 著者：小川晃通 著 発行：2022年7月13日 ISBN：978-4-908686-14-6 A5判、152ページ 紙本体2000円 電子本体1800円 インターネットを構成する「技術」は世界共通です。 その仕様であるTCP/IPは万人に対して公開されており、解説書も数多くあります。 仕様や解説書は体系的に記述されているので、一見するとインターネットは実に合理的に技術的な要請に基づいて構成された形をしているように思えるかもしれません。 しかし、インターネットは人間が作り運営しているものです。 そのため、インターネットの形には「人間の営み」が少なからず影響しています。 そもそもインターネットを物理的に構築するためにはどうしても各所でお金が必要です。 回線代、場所代、電気代、運用者の人件費など、維持にはさらにお金がかかります。 お金が