K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
Eclipseからテキストエディタに戻れない10の理由 - プログラマーの脳みそ
ソフトウェアはいろいろな作業の効率化に貢献してきた。プログラミングという作業も例外ではない。現代の高度なIDE(統合開発環境)はプログラマが単純でつまらない作業に時間を割かずに済むようにさまざまな機能を提供してくれる。 もうテキストエディタ＋コマンドラインでのコンパイルなんて環境には戻れない。以下は自分が仕事でメインに使っているEclipseというIDEを使い続ける理由。 （追記）私は仕事では主にJavaの開発をやっている。C/C++/C#の開発では以下に挙げるメリットを享受できない部分があることを断っておく。 1. コードの自動補完 標準API+フレームワークのAPIで万単位のクラスが存在するので、暗記は無理。クラスに存在するメソッド名、フィールド名までの暗記はもっと無理。よく使う範囲なら暗記しているけど、typo -> コンパイルエラー -> 探して修正 の手間より、自動補完が断然効率
きまぐれ日記: pubic static はコンピュータに伝える約束事ではない
http://www.atmarkit.co.jp/news/200904/10/matz.html PerlやRuby、Pythonといったスクリプト言語では、 記述が非常にストレートで端的になる。JavaやC++といった言語では、 「public static void mainなど、コンピュータに伝える約束事が多くて、 やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」（まつもと氏）。 これは書くときだけでなく、読むときにも同様だ。 まつもと氏の記事を読んで、仕事として大規模な共同開発の経験に基づいているのかなと思いました。 publicとかstaticとかconstというのは書く側からすると約束事で めんどいということには同意しますが、毎日のようにコードレビューを している経験からいうと、コードレビューをする側にとってこいうキーワードがあるかないかで全く意味が異なります。メ
フローチャートの呪い - カレーなる辛口Javaな加齢日記
http://blog.livedoor.jp/dankogai/archives/51083212.html http://d.hatena.ne.jp/NOV1975/20080719/p2 http://d.hatena.ne.jp/NOV1975/20080719/p4 いまさら議論するのも馬鹿らしいけど，フローチャートなんぞはものの役に立たない． そんなものは作るだけ時間の無駄だし，何かの役にたつこともない． それは何十年も前に結論が出ていると思う． それはあまりに自明であったため，今では話題になることも少なくなった． 人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series) 作者: フレデリック・P,Jr.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子出版社/メーカー: アジソンウェス
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな加齢日記
http://d.hatena.ne.jp/fromdusktildawn/20081026/p1 うーんと，30点．「もう少しがんばりましょう」レベル．*1 初心者が惑わされると可哀想なので，一応突っ込んどく． 「変数のスコープは狭いほど良い」という迷信 「同じロジックのコードを2度以上書くな」という迷信 「プログラミング言語を極めるのが大切」という迷信 一つ目は大原則．特にグローバル変数は最悪だ．言語によっては避けられないこともあるが，それはコーディング規約などでカバーするしかない． 二つ目も，ほとんどの場合は大原則．未熟なプログラマーには，何故か負担が大きすぎるらしいけど． 三つ目はケースバイケース．ほとんどの場合は言語も極めてない奴の方が多く，まずは「言語を極めろ」は概ね正解． なんだかなぁ。「先ずは使うことを覚えろ」「次に使わないことを覚えろ」「最後に使うか使わないか選ぶことを覚
IT関係でこれは読んでおけという本 - カレーなる辛口Javaな転職日記
http://q.hatena.ne.jp/1193169005 「そんなもん自分で探せ」と言ったらダメなのかな．他力本願なだけの「教えて君」には未来はないぞ． 更に言えば，あまりにも漠然としすぎた質問だ．同じITでも何を専門とするかで必要とされる知識も千差万別． オブジェクト指向お勧め本リスト： http://d.hatena.ne.jp/JavaBlack/20070522/p1 プログラミング作法 作者: ブライアンカーニハン,ロブパイク,Brian Kernighan,Rob Pike,福崎俊博出版社/メーカー: アスキー発売日: 2000/11メディア: 単行本購入: 58人 クリック: 1,152回この商品を含むブログ (209件) を見る 入門 GNU Emacs 第3版 作者: Debra Cameron,James Elliott,Marc Loy,Eric Raymon
オブジェクト指向プログラミングの学習法(初心者向け) - カレーなる辛口Javaな転職日記
個人的な話をしますと、オブジェクト指向の入門書に出てくる、「クルマのたとえ話」とかは本当に意味わかりませんでした。こちとら、すっかり手続き脳なもので、そんなんでmainとかどうやって書くのよ？みたいな。＜我ながらヒドイ http://d.hatena.ne.jp/LazyCoder/20070806/1186417299 追記 PHPのオブジェクト指向を勉強してる。というか仕事での必要性を感じてやってるけど、正直オブジェクト指向の良さがさっぱりわからん。(中略) よくあるオブジェクト指向の解説本には車がオブジェクトでタイヤがファンクションでみたいなんかいてるけど、実務で使うプログラムの設計の仕方がわからん。 http://anond.hatelabo.jp/20070427093912 こんな説明を読んで、なんだかわかったような気分になれる人は、どっちかというと思考力に欠ける人なんじゃない
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め - 思っているよりもずっとずっと人生は短い。
オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか？」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください（＜無茶振り）。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。 その素晴らしさは随所にあるのですが、章立てに追って説明しましょ
お勧め本？ - カレーなる辛口Javaな加齢日記
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか？」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください 私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。 http://d.hatena.ne.jp/takahashim/20080725#p1 ここまで正反対の意見も珍しいなあ． オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP
憂鬱本を買ってみました - みねこあ
javablack さんが最近とりあげ、 ちょっとだけ話題再燃したの憂鬱本 こと「憂鬱なプログラマのためのオブジェクト指向開発講座」。以前借りて読んだことがあるのですが、「酷いわ」と思ったこと以外具体的なことは何も覚えていません(^^; で、具体的になにが酷かったのかのかな？とザザッとWebを流してみたのですが、見つからない。というか「これはいい本だー」という感想ばっかりで、予想以上に「酷い」というレビューがないのに改めてビックリです。 むー、これはネチっこいレビューの需要があるかな？とスケベ心をだして買ってしまいましたョ。 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ (78件) を見る で、改めて読み
自己流オブジェクト指向＆Java参考書 『非』お勧め版 - カレーなる辛口Javaな加齢日記
お奨め本リスト*1と対をなす，非お勧め版の入門書・参考書リスト．*2 あくまで『非』お勧めの、駄本、屑本リストである点に注意。しかし皮肉な話だが，初心者を惑わす入門書を避けるためにも要チェックだろう． 主に「何故か有名だけど悪い本」を取り上げる予定．「無名だけど悪い本」はきりがないので，ここではパス．結果として持ってない本が中心になるので詳細について触れるつもりはない．*3 「オブジェクト指向本」 実は「オブジェクト指向」というのは，あまり専門的な用語ではない．*4オブジェクト指向プログラミング(OOP)，オブジェクト指向設計(OOD)，オブジェクト指向分析(OOA)などと，きちんと区別すべきだ．ただ口頭で話す時は「オブジェクト指向プログラミング」と言うのは冗長だしOOPと言っても理解してもらえない．しかたがないので省略して「オブジェクト指向」と言う時も少なくない． ここで挙げるのは「いわ
J - 新入社員が社内トップレベルとかいうはなし。
なんだかんだあって、ずるずるいったあげく、明日が最終出社日。 今日明日がいままでだらだらやってきたツケみたいな感じ。まあ、なんかこんなギリギリな時期になって今までで一番失敗したみたいな感じになった。これが僕の三年間の態度の集大成としてはふさわしい姿なのかと思う。 それはいいとして（よくないのだけど）、引継ぎの人と話をする機会があって、その人が二年目で、会社的にはふたつ下、（僕が高専卒なので）年齢が一緒というひとで、どんな人かと思ってたら、なんか、非常に非常だったというか、「コンパイラとかわかりますか？オートマトンとか好きなんですけど」とかそういう話になってたとか。 ほげー。「Lispを勉強するとGoogleのMap Reduceを理解するのに役立つとかRadium Software Developmentで読んだんですけど、Lisp勉強するのて役に立つんですか？」とかそんな感じのことを聞か
エンジニアがタイトル買い、著者買いすべき本 - Fight the Future
著者買いすべき本！ ファウラー、ジョエルは知名度もあり、改めて僕がどうこう紹介する必要はないと思うけど、ここではスティーブ・マコネルを特に推したい。 読んだ人には非常に高い評価を得ているけれど、その分厚さや価格もあってなかなか広まっていない。 特にCode Completeはすべてのエンジニアが必ず読むべき本だと思ってる。 これを読んで理解する／しないが(職業プログラマとしての)初級と中級の境界だと言えるくらい。 タイトルにはCodeとあるけど、別にコーディングをターゲットにした本ではない。 設計、テストも含めてコーディングを考えている。当たり前だがコーディングだけではコーディングはできないからだ。 上下巻1,200ページの大作だし、2冊で12,000円だがその価値は大いにある。 スティーブ・マコネル ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,S
ソフトウェアは全て芸術品という時代でもない - novtan別館
僕もプログラマの1人として、ソフトウェアが工業製品である、といういいきりには抵抗したいところだ。一方で、あまりに製品として需要があり一般化してしまったものが芸術品(あるいは工芸品)のままでいられるかというと、コストの面からは不可能だろう。まあ、そういう意味では、ソフトウェアそのものはパッケージが工業製品であり、それをそのまま利用できる、あるいは利用するための手続きがもっと整備される、ということが工業製品化と比べられるべき部分なのかもしれない。 「アーティストでは仕事にならないと思うかもしれません。作者として作品に納得が行かないから納品しない、などという人がいては仕事になりませんよね。しかし、これは誤解です。世の中には“アートな仕事”をしている人がたくさんいます。例えばコピーライターは、納期の制限がある中でクリエイティブな仕事をしている。なぜソフトウェア業界にそれができないのでしょうか？」
「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演 － ＠IT
2009/04/10 ソフトウェアは工業製品ではない――。Rubyの生みの親としてしられるまつもとゆきひろ氏は2009年4月9日、InfoQ主催のイベント「QCon Tokyo 2009」の基調講演で、ソフトウェアと何であり、何でないのか、それはどういう性質のものであるのかを雄弁に語った。 コードとは設計である 「ビューティフルコード」と題した基調講演を行ったまつもと氏は、2007年に共著者の1人として出版した同名の書籍に書いたエッセイに込めた思いを、次のように語る。 「世界に冠たる日本の製造業のノウハウを適用することで生産性を上げることができるに違いないという発想がありますが、ソフトウェアは工業製品ではない。そうした誤解を正していきたい」。 ソフトウェア産業界では、よくエンジニアが何十万人足りないということが言われる。しかし、まつもと氏は、これは工業生産と同じ方法論を当てはめることから来
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場
「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
