竹内郁雄教授最終講義「研究・開発は楽しく」（東京大学） - Cafe Babe
3月3日に東京大学で竹内郁雄教授の最終講義がおこなわれた． なお，今回は参加者が多かった他の最終講義の参加人数から推測して340名の会場を用意したのだが，予想をはるかに上回る参加人数（400名くらい？）で，一部の人達は立ち見になってしまった．また，鵺シール・竹内郁雄最終講義スペシャルバージョン（普通は文字がオレンジ，これは文字がブルー）も300枚用意したのだが，全然足りなくて一部の人達には渡すことができなかった．この場を借りて準備不足をお詫びしたい． なお，最終講義の様子は二台のビデオカメラで撮影してある．大学の許可が出れば，公開されるかもしれないので，その時はこのブログでもお知らせしようと思う． さて，今回の講義の題名は「研究・開発は楽しく」である．竹内先生によると，通常の最終講義で喋る内容はすでに別の場所で喋ったので，それは講演の資料として配ることにして，最終講義では別の話にしたいとい
Rubyを最大63％高速化した中学生は超多忙！
金井仁弘（HN：CanI）氏 撮影：平沼久奈 ハンドルネームCanIの由来は、「“Can I”→キャナイ→カナイ」。C#、Visual Studio、Microsoft .NETとマイクロソフト製品が大好きな「.NETer」と自称する 筑波大学付属駒場中学校は、東京都内にある中高一貫の国立校だ。入学試験の偏差値と東京大学への進学率の高さから“東の筑駒、西の灘”と称される進学校である。強いのは受験だけではない。国際情報オリンピックや国際数学オリンピックでは、同校の生徒が毎年のように金・銀メダルを制するなど才能あふれる理数系人材が多数在籍している。 金井氏はこの夏の「セキュリティ＆プログラミングキャンプ2009」（2009年8月12～16日）に参加し頭角を現した中学生プログラマである。 今年に入って、Ruby 1.9のフィボナッチ数列による演算（多倍長加算
プログラマなら人月なんかさっさと超えろ - 矢野勉のはてな日記
Java, プログラミングノリノリで書いてみる。 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 そしてJavaの世界というのは、私のようにJavaが大好きだからやってる、という人間はすごく少数派で、「そろそろJavaでもやっとくか」「Strutsの使い方覚えたからもういいか」「できればJavaなんかいじりたくないなー。俺も早くプログラマに『これやっといて』って言えるようになりたい」という人のほうが多いのが実情なんですね。その点Rubyの世界は、今は「好きだからやってる」人が圧倒的でしょう。プログラム能力の高いJavaプログラマを探すのは、プログラム能力の高いRubyプログラマを探すよりずっと大変だろうと思う。 Javaの世
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く
ぼくは以前にIT関連の仕事をしたことがあって、ぼく自身はプログラムを組めるわけではないのだけれど、何人かのプログラマーさんと一緒にお仕事をさせて頂く機会があった。その中で生まれて初めてプログラマーという職業の方と交流させて頂いたのだけれど、彼らはなかなかにユニークで特異な個性の持ち主たちであった。もちろんプログラマーと一口に言っても色々なタイプがいて、必ずしもひとくくりにできるわけではないのだが、共通していたのは好奇心が旺盛で新しい物好きだということだった。そして少々気難しい面がありつつも、基本的にはポジティブで、明日に向かって色々なことを前向きに、精力的に取り組んでいる人が多かった。 そんな中で、特に親しくお話しさせて頂いたTさんというプログラマーがいて、この方もなかなかに個性的で、ご自分の意見や主張というものをはっきりと持っており、ITのみならず世の中に対しても一家言お持ちであった。そ
アラン・ケイ - 「ソフトウェア工学」は矛盾語法か？ [邦訳]
アラン・ケイ Is “Software Engineering” an Oxymoron? By Alan Kay (訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日本語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。) 真のソフトウェア工学はまだ未来のものだ。一年と
構造化プログラミング - Wikipedia
構造化プログラミング（こうぞうかプログラミング、（英: structured programming）は、コンピュータプログラムの処理手順の明瞭化、平易化、判読性向上を目的にしたプログラミング手法である。一般的には順接、分岐、反復の三種の制御構造（control structures）によって処理の流れを記述することと認識されている[1][2]。制御構造は制御構文、構造化文（structured statement）、制御フロー文（control flow statement）とも呼ばれる。また、プログラムを任意に分割した部分プログラム（サブルーチンとコードブロック）の階層的な組み合わせによるプログラムの構造化も指している。 このプログラミング手法の普及に貢献したのは、1968年の計算機科学者エドガー・ダイクストラによるACM機関紙への投書「Go To Statement Consider
プログラミングの本質とは - 射撃しつつ前転 改
プログラミングの本質は、条件分岐と繰り返し（と連接）だけでチューリング完全が実現できることであると考えている。つまり、いわゆる構造化定理である。 プログラミングの勉強を始めた頃は、一体どこまで勉強すれば自分はプログラミングが出来るといえるのか、まったくわからなかった。構造化定理を知ったとき、ああ、これだけ知っていれば全てのプログラムが書けるのか、と感動したし、振り返ってみても、あの瞬間はプログラマとして一つの到達点であったと思う。もちろん、そこから先の道のりは、まだまだ長かった訳だけれども。 構造化定理の良い点は、チューリングマシンというなんだか抽象的かつ重要そうなものと、自分がいつも書いているプログラムの間をシンプルに結びつけてくれる点であると思う。実際にプログラミングをする際の道具立てとしては便利なものが色々とある（高階関数だとかクロージャだとかね）訳だけれど、精神を支えているという点
メンバ変数（インスタンス変数）の命名 - 神様なんて信じない僕らのために
職場で話題になったこと。 m_value mValue this.value(self.value) _value value_ value と色々あるわけですが、 世の中では 「m_ or mでメンバである事を明示する派」（m派） 「mは冗長だから_だけで表すよ派」（接頭辞アンダースコア派＝マーチン・ファウラー派） 「言語機能に乗っ取ってthisつけて表すよ派」（this派） 「前置_は言語処理系に予約されている（c/c++）ので後置_にするよ派」（接尾辞アンダースコア派） id:nattowさんの指摘で追記。 「つけないと区別できないのは設計がまずいから俺はつけないよ、てか接頭辞も接尾辞もきもいよ派」（設計上正しければ区別必要ないよ派） がいるような気がします。 （Rubyの@派とかは知らぬ） で、割と最近「後置_派」（C++ Coding Standardsの影響）になったんですが、
あなたはC++の発明者？ それとも創造者？～Bjarne Stroustrup氏との対話～：CodeZine
はじめに 「Bjarne Stroustrup氏との対話」連載を担当することになりました、豊田孝と申します。よろしくお願いいたします。 対話の相手であるBjarne Stroustrup氏は、プログラミング言語「C++」を設計し、最初に実装した人です。それだけでなく、同氏はC++を国際標準プログラミング言語の地位に付かせました。大変なエネルギーの持ち主です。 筆者はこの数年、「同氏の生き方から何かを学べるのではないか」と考えてきました。その考えは日毎に熱を帯び、「学べるはずだ！」、そしてついには、「わが国の開発者に、同氏の考え方と生き方ぜひお伝えしたい！」へと変化し今回の連載を始めるに至りました。 本稿でのStroustrup氏との対話はメール交換を通して行われます。基本的には、筆者が質問文を用意し、Stroustrup氏がその質問に対して高所からコメントを寄せることになります。C++言語
できる開発者になるための7つの習慣 - builder by ZDNet Japan
Sun Microsystems Asia-PacificのスタッフエンジニアであるLee Chuk Munn氏によると、アプリケーションを書くことは本を執筆することに似ているという。 「私はさまざまなプログラミング言語を学んできた。しかし、どんな言語を使ってプログラムを書いているかは問題ではない。書く物語がよいものでなければいけないのだ」Lee氏はZDNet Asiaの電話インタビューでこう答える。ソフトウェアのプログラミングでは27年の経験を持つベテランのLee氏はSunのソフトウェア部門で働いており、社内の開発者やJavaやSolarisを使用している個人ソフトウェア開発者のネットワークを指導している。 彼はこう続ける。「プログラミングは解決策の一つの表現にすぎない。プログラミングの多くを構成するのは、問題を理解して認識し、助けを得ることだ。この考え方はすべてのプログラミング言語にお
学生プログラマの「実力差」は、「麻雀」と「囲碁」の差 - 本当は怖いHPC
僕も学生なのだけど(一応)、仕事をしているチームにプログラマをスカウトするために何人もの学生プログラマと会ってきた。能力はいろいろ。Linuxのソースをガンガン読んでいる人もいれば、授業のプログラミング課題がちょっと得意、くらいの人もいた。言い方は悪いけどピンキリ。 で、その差が何から来るのか疑問に思っていた。「プログラミングに対する情熱や興味の差」とか、「アルバイトでの開発の経験」などの差はもちろんあるのだが、どうもそれだけでは説明し得ない壁があるように感じたので、ここ数日それを考えていた。 で、理由を思い立った。 学生に限らず、プログラミング能力は個人差が激しい。これは最終的には「純粋な頭脳労働だから」という点に帰着すると思う。他の多くの世界と違って、プログラミングは「時間と頭脳があれば原理的に何でもできる」わけだ。他の分野においても「頭脳戦の割合が高ければ高いほど偏差も大きくなる」と
はじめてのカーネル・ソース 第1回 どうしたら読めるようになるのか：ITpro
なかなかハードルが高く，多くの人が踏み出せないでいるカーネルのソース・コードの読解。本連載では，今までカーネル・ソースなんて見たことがないという人に，読みこなすコツをお教えします。今回は，どうしたらカーネル・ソースを読みこなせるようになるのか，筆者の経験をお話します。 Linuxユーザーなら誰しもカーネルのソース・コード（カーネル・ソース）を読んで，どのような処理を行っているのかを確認したり，自分なりの変更を加えたりしたくなるのではないでしょうか。しかし，カーネル・ソースの量は膨大な上，C言語で書かれているので，コンピュータ内部やOS（オペレーティング・システム）の仕組みを理解したプログラマでないとなかなか読みこなせません。そのため，カーネルを読むための第一歩を踏み出せない人が数多くいることは事実です。 本講座では，プログラマではないごく普通のLinuxユーザーが，カーネルをある程度自力で
コンピュータ関連名言(迷言)集:Geekなぺーじ
コンピュータ関連名言(格言？)を集めてみました。 「computer quotes」や「IT quotes」などの単語で検索してみましたが、そこらじゅうに同じようなサイトがあり、どれがオリジナルだかわかりませんでした。。。 いくつか楽しいと思ったのをピックアップしてみました。 他にも色々あったので、興味のある方は検索をしてみて下さい。
“21世紀のプログラムを作る君たち”に伝えたかったこと
個人が成し遂げられることはどんどん大きくなっている。常識は短期間で変わる。今貴重なものは，やがて過剰になる。日本市場を世界からへだててきた日本語の壁はなくなろうとしている。ネットの向こうにいる仲間を信じよう---「U-20プログラミング・コンテスト」という，20歳以下を対象にしたコンテストに参加した若い技術者たちに，伝えたかったことだ。 ここ3年ほど，このコンテストの審査会にオブザーバという名目で立ち会わせてもらっている。なにしろ審査員のひとりであるまつもとゆきひろ氏が「私が応募しても入賞できないかもしれない」というレベルの高さである。思わず唸る完成度の高い作品あり，思わず吹き出してしまうユーモアのある作品あり。記者は好きに意見だけ言って審査の責任は負わないという美味しい役目でもあり，こんなに無料で見させていただいていいのだろうかというくらい楽しませていただいている(関連記事）。 ところで
今の子供達にどうやってプログラミングの楽しさを教えたらいいのか?
うちはとても貧乏だったというのに、なぜか俺が小学三年生のときに、親父がパソコンを買ってきた。 親父は電気工事屋をやっていたから電気製品が好きだったんだろう。 当時小学六年生だった兄貴も機械いじりが好きだった。 電子ブロックなんてのが家にあった。 とはいえ、二十万円もするパソコンをコンビニでウーロン茶を買うかのように買ってきた親父が、あとでオカンになんて言われたのか、いまとなっては知るよしもない (いや、親父もオカンもまだ生きてるので、聞こうと思えば聞けるが) 。 ともかく、俺が小学三年生の時には家に MZ-2000 というパソコンがあった。 三年生のときはそもそもパソコンとはなにかも知らなかったし、親父も兄貴も壊れものを扱うかのように大事に触るので (実際壊れものだ) 、俺には触らせてもらえなかった。 親父や兄貴の背中越しに見ているだけだった。 当時はパソコン用のソフトなんてのがそこらに売
はてな伊藤直也氏MIJS講演「プログラマでいること」 : 小野和俊のブログ
昨日MIJSのコンソーシアム内での技術発表会があり、理事会の方から「参加ベンダーの技術者が集まるイベントなので、技術者に元気を与えられるような人に講演をお願いしたい」という話があったので、はてな伊藤さんに講演をお願いした。 伊藤さんにお願いしようと思ったのは、伊藤さんなら、エンタープライズの世界にウェブの世界の元気な風を吹き込んでくれるのではないかと思ったからだ。 以下、私なりに講演の内容をまとめてみた。 ■「建物の建て方」 つくる対象がどのようなものかで、作り方は当然変わってくる。これは建物もソフトウェアも同じ。1階建ての格好良い小さなロッジを建てるのと、60階建ての安全で高品質な巨大ビルを建てるのとは方法も道具も異なる。ロッジを建てる時にはノコギリを使うが、巨大ビルを建てるにはクレーンを使う。 よくブログの世界でソフトウェアの開発について、ぜんぜん違うことをやっている人が同じ土俵で議論
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
