オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め - 思っているよりもずっとずっと人生は短い。
オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか？」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください（＜無茶振り）。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。 その素晴らしさは随所にあるのですが、章立てに追って説明しましょ
ソフトウェアの単純さ - Plan9日記
UNIXの代表的なプログラムにcatがある。Wikipediaから引用すると、 catはUNIXの標準コマンドであり、ファイルを連結させたり表示したりするのに用いる。catは連結することを意味する「catenate」の略である。 （中略） UNIXファンの間では、cat(1)はユーザインターフェースデザインのよい手本とされている。catはファイルの内容に空白やヘッダのような余分なものを一切付加せずに提供してくれるためであり、またテキストファイルのみならずどんな種類のデータに対しても正しく動作するためだ。 UNIX嫌いの間では、cat(1)は悪いユーザインターフェースデザインの正統な手本とされている。それはこの悲しげなまでにわかりづらい名称のためである。catは、ファイルの連結（concatenate）に使うよりもむしろ標準出力への出力に使われることの方がはるかに多い。後者の使用法に対するc
『理論は暇人のためのものではないということ。』
職業柄、会社についていろいろ意見を頂くことがあります。ネット上で書いてある意見なども見たりします。中には感情的な意見もありますが、その感情に至るまでには何らかの理由があります。ですから、肯定的な意見も、批判的な意見も、製品開発やサービス開発においては非常に参考になります。でも、ひとつだけ、僕が絶対に許せないことがあります。僕は、自分の会社のメンバーが侮辱されることは、それがどんな理由であれ、許せません。 たまには感情的になったっていいじゃない。大人げなくたっていいじゃない。 IT企業が、理論を軽視していいものか。理論が好きな人間を暇人と侮辱していいものか。そもそも、ITの世界で、理論好きか理論が嫌いかという議論が意味があるのか。ITにおける理論は、僕はコンピュータサイエンスだと考えています。コンピュータサイエンスが好きとか嫌いとかの問題の前に、ITに携わる人がそもそもコンピュータサイエンス
はてなブログ | 無料ブログを作成しよう
中古のリーン・ロゼ ブリガンタンを買った 中古のインテリアリサイクルショップのウェブサイトを眺めてたら、とんでもない破格だったのをたまたま見つけまして、ずっとほしかったし買ってみました。本当に安かった。かなり汚れてるからこの価格だったようで、よくみると確かに汚れてるが、よく見ないとわからな…
第6回 ［最終回］プログラマについて | gihyo.jp
「プログラミングに関する雑多な事柄」がテーマの本連載、最終回の今回はプログラマについて取り上げてみたいと思います。 生産的なプログラマとは？ 生産的なプログラマは平均的なプログラマの何倍もの仕事をする、という話をよく耳にします。確かに経験に照らし合わせても、できるプログラマの生産性には目を見張るものがあります。 ここでは、私がこれまでに関わった中で、生産的なプログラマにどんな特徴が見られたか紹介したいと思います。 レスポンスが早い チームでの開発では、他のメンバーから質問があったり、何かを依頼されたときに、できるだけ早くレスポンスすることが大切です。 たとえば、ちょっとした質問への返事が遅いだけで、誰かの進行が止まってしまうことがあります。レスポンスの早いプログラマと一緒に仕事をすると、こうした待ち時間が最小限になります。 フットワークが軽い 私の知り合いのあるプログラマは、何かアイディア
ホワット・ア・ワンダフル・ワールド ファミコンプログラミング
一番身近な 8 bit CPU ということで． しかし，思ったよりも情報が少ない．以下のサイトが有名らしい．というか，非常に素晴らしい決定版サイト． ｷﾞｺ猫でもわかるファミコンプログラミング まだオープンソースの時代とかじゃなかったし，極めて厳しいハードウェアリソース上でのプログラミングにならざるを得ないため，ロストテクノロジーの塊．リソースが厳しすぎるので，C コンパイラとかもあるにはあるけど，使えない感じ… あと，こういうゲーム機の hack は，どうしてもアングラ的になってしまうのでいろいろアレ．さすがにファミコンぐらい枯れてると，生々しさは消えてくるけど． ファミリーコンピュータ : wikipedia.ja 1.8 MHz の 6502 互換 CPU に，2 KB の RAM + 2 KB の VRAM．よくこんなハードで，女神転生とかドラクエが実装できたものだと，驚愕するしか
最もタメになる「初心者用言語」はScheme! - 日記を書く [・w・] はやみずさん
最もタメになる「初心者用言語」は Python！ - 西尾泰和のはてなダイアリー Schemeなら、えんざんしとかえんざんしのゆうせんじゅんいとかいんでんととか小難しくてよくわらないものがないから、初心者でも安心して簡単にできるよ > < しかもしかも、ループと再帰呼び出しとか2つもいっぺんに覚えなくても、末尾呼出し1つだけ覚えれば両方できちゃうよ！Schemeすごい！ Schemeで豊かな表現力を身につける なんだかよくわからないけど、巷のプログラミング言語は * とか - とか ? が変数名とか関数名につかえない。演算子？なにそれ初心者には難しくてわかんない＞＜ Schemeだったら、「それってシンボル？」って聞く関数は symbol? っていう名前にできるよ。 is_symbolとかわかりにくいよね！！！アンダーバーとかタイプしにくくて初心者向けじゃないし！！！ 参照透明できれいな心
![最もタメになる「初心者用言語」はScheme! - 日記を書く [・w・] はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/4e5f1b0808fd427d187a21018b7fa8fa512c3d6c/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128197024%2F1557447405)
C言語入門、東京大学情報科学科の場合 | スラド デベロッパー
C言語入門、書籍だろうが講議だろうが、この業界なら誰もが通る道ではあるが、 sumiiの日記経由で実に興味深いC言語入門を見付けた。 東京大学理学部情報科学科の学部2年生向けのアルゴリズムとデータ構造演習内でのC言語入門 なのだが、 C入門第1回では、シェルを実装、データを圧縮・解凍するプログラムを実装、スパムフィルタを実装というお題目が並んでいる。 これだけで一瞬ひるんでしまったが、解説PDFを見ると、 「最低でもジョブ管理、リダイレクト、(多段)パイプラインの機能は実装すること」などと書かれている。 UNIXへの理解がかなりないと難しい気がするのだが、これをくぐり抜けてくる学生はどれくらいいるのだろう？
学生プログラマの「実力差」は、「麻雀」と「囲碁」の差 - 本当は怖いHPC & AI
僕も学生なのだけど(一応)、仕事をしているチームにプログラマをスカウトするために何人もの学生プログラマと会ってきた。能力はいろいろ。Linuxのソースをガンガン読んでいる人もいれば、授業のプログラミング課題がちょっと得意、くらいの人もいた。言い方は悪いけどピンキリ。 で、その差が何から来るのか疑問に思っていた。「プログラミングに対する情熱や興味の差」とか、「アルバイトでの開発の経験」などの差はもちろんあるのだが、どうもそれだけでは説明し得ない壁があるように感じたので、ここ数日それを考えていた。 で、理由を思い立った。 学生に限らず、プログラミング能力は個人差が激しい。これは最終的には「純粋な頭脳労働だから」という点に帰着すると思う。他の多くの世界と違って、プログラミングは「時間と頭脳があれば原理的に何でもできる」わけだ。他の分野においても「頭脳戦の割合が高ければ高いほど偏差も大きくなる」と
ユメのチカラ: ソースコードの読み方（ニコニコ動画(RC2)で公開）
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年～98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
tips - 二進数表記まとめ : 404 Blog Not Found
2007年10月11日17:30 カテゴリTipsLightweight Languages tips - 二進数表記まとめ これにインスパイヤされて。 C/C++で2進数値を記述 - きまぎらすほしゅの不定記 C/C++では、数値リテラルを次のように、８進数、１０進数、１６進数の三通りで書き表すことが出来る。 int r8 = 01578; /* octal number */ int r10 = 32768; /* decimal number */ int r16 = 0xFFF; /* hexadecimal number */ しかし、８進数よりもよく使われているであろう、２進数の書き方は仕様に存在しないらしい。 二進数→(10,8,16)進数変換 by javascript ご自由にお使いください。[01]以外の文字は単純に削除されるので、'1010_0101'のような表記も通
LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found
2007年09月16日04:30 カテゴリArt LiveCodingに学ぶプログラミングの三原則 Mozilla24のLiveCodingの解説をやってきました。参加された方、お疲れさまでした。ほんと楽しかった。 言語もC++ありJavaありJavaScriptありActionScriptありPerlありとまちまちで、Editorもemacsありvimあり秀丸ありとまちまちでしたが、それでも全LiveCoderの共通項がはっきり見えたので、それを書き留めておきます。これらの共通項には私も含まれます。 コピペを恐れるな(don't be afraid to be a copycat) 参加者の一人として、100%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ
プログラミングのノウハウ
プログラミングに関するノウハウは大きく 3つにわかれると思う。 (またもや強引な分類) 1. 普遍的なノウハウ アルゴリズム, データ構造, オブジェクト指向, ツールボックスアプローチ, λ計算, etc. 2. システムのノウハウ 言語処理系, 計算機アーキテクチャ, OS, ネットワーク, etc. 3. 雑多なノウハウ 恣意的なAPI, 恣意的な言語仕様, 各種ソフトウェアの設定, 各種コマンドラインオプション, ソフトウェアのインストール作業, 各種システムの仕様の違い, 「最新技術」, etc. プログラミングをする上では 3種類のノウハウすべてが多かれ少な かれ必要なのだけど、僕のような人は、ついつい 3番目の雑多なノ ウハウばかりが増えていってしまう。日々のネットサーフィンで得 られるノウハウは大抵これである。 雑多なノウハウというのは、「たまたまそうなっている」だけであっ
ソフトウェア技術者はまずソフトウェア技術のことをもっと知ったほうがいい
ソフトウェア開発者は製造業のことを知った方がよいから。製造業のことは詳しくは知らないので知った方がよいかどうかの判断はできませんが、ちょっと気になったところ。 我々の作るものには物理的制約がないことはよく言われるけど、そんなことないでしょう。少なくとも光のスピードを越えられない以上、計算速度の限界があります。それに実際問題として、速度と空間はトレードオフの関係にあることも忘れてはだめでしょう。 時間と空間(記憶容量)は我々に制約をかけてます。メモリ上なら(cacheにのっていればさらに)高速に計算できますが、メモリ(or cache)の容量は限られています。それ以上のデータを扱おうとすると ディスクもしくはネットワーク越しのサーバーを使わざるを得なくなりますが、それはとても遅いということはソフトウェア技術者ならば当然知っておくべきのことのはず。ディスクアクセスはそれこそ物理的制約(ヘッドの
理解することが書き直すことを意味するとき
Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新
小野和俊のブログ:そして、ペア･プログラミングが始まる
ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 １セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Linuxデバイスドライバプログラミング: 平田豊: 本
[mac] プログラムを紙に印刷 a2ps - 生活。
「アルゴリズムを知らない子ども達」の補足(?) - val it : α → α = fun
http://ja.doukaku.org/