地下室の酒気帯び日記
最近のツッコミ2005-01-04 (Tue) [長年日記]
_ [Soft][Web] Interactive imgTeX
"imgTeX"をインタラクティブに使うインタフェース。
複雑な数式を簡単に綺麗に表現したい時に役立つ(TeXに慣れている人は特に)。数式はPNGファイルになるのでプレゼンテーションやワープロソフトなどで扱うときにも便利。
下記のような記述で図のような画像ファイルを生成することが出来る。
※出力はPNGフォーマットだけどtDiaryプラグインの関係でJPG画像に変換している。
\[
L_o(x,\vec{w})
= L_e(x,\vec{w})
+ \int_\Omega f_r(x,\vec{w}',\vec{w}) L_i(x,\vec{w}') (\vec{w}' \cdot \vec{n}) d\vec{w}'
\]
2005-01-06 (Thu) [長年日記]
_ [Programming] 使える GUI デザイン
原文: Usable GUI Design: A Quick Guide for F/OSS Developers
「2) 不必要なインターフェース」、「3) コンピュータのパワーを使え」は特に共感する。
(via Open Alexandria)
_ Advice for Computer Science College Students
コンピュータ科学を専攻している大学生へのJoel氏によるアドバイス。具体的には次の7つ。
1. Learn how to write before graduating. 2. Learn C before graduating. 3. Learn microeconomics before graduating. 4. Don't blow off non-CS classes just because they're boring. 5. Take programming-intensive courses. 6. Stop worrying about all the jobs going to India. 7. No matter what you do, get a good summer internship.
_ 1と同様のことは社会人になってOJTにも言われた。
2には同意。
3, 4, 5なんかは自分の学生時代を考えると非常に反省するところ。
6については自分はむしろ危機感を持っている。
7についてはちょっと経験した。インターンシップというよりはバイトに近かったけど。
2005-01-07 (Fri) [長年日記]
_ エクストリームリーディング
勉強会などはこのスタイルが自分も好み。エクストリームリーディングという単語は始めて聞いたけど。
(via My Life Between Silicon Valley and Japan)
ここで実践しているプラクティスをエクストリームリーディング(eXtreme Reading)とし て紹介しよう。
通常、こういう本を読むときは、章ごとに担当者を決めてレジュメに落としてもらい、そ れを発表する。そのため、担当者は用意周到な準備が必要だし、その他の人もひととおり 読んできていることが前提となっている。
しかし、エクストリームリーディングでは、事前準備はゼロ。その場で黙々と読み、数節 ごとに議論をします。分からないことがあったらその場で互いに聞きます。
なんでこういう方式をとるかというと、 １．こういうエグイ本は、一冊読むのに１００時間以上かかるため、強制的な環境をつく らないとなかなかちゃんと読む機会がない
２．本一冊の中で数十箇所ある重要ポイントのうち、一箇所大事なところの理解がはずれ ると、１００時間の読書がまったくの誤解で終わることがあるので、むなしい。読書中に 相互にチェックをしてこれを防ぐ。逆に重要でないところを飛ばすことも可能になる
３．短い単位で、節や章の意義をまとめるので、読み流しを防ぎ、論理構造を確認できる。
４．場所を分担してレジュメ発表すると、結局自分で読まないことがあったり、概念を誤 解したまま多くのページを読み進めることが発生して無駄が多い。
５．レジュメ発表では見えない、他人の読書や読解の仕方が分かるのですごく勉強になる。 すごい人の、思考の結果ではなくて、思考のプロセスが見えるから。（ペアプログラミン グじゃなくてペアリーディングみたいなものだね。さすがに一冊の本を二人で同時にみる ことはしないけど、もしかしたらお母さんが子供に読み聞かせるのはペアリーディングと いう最高の教育法なのかもしれない）。
ちなみに、最適人数は５人程度だと思います。
2005-01-13 (Thu) [長年日記]
_ [言葉] by George Santayana
過去を思い出せない人は、過ちを繰り返すことによって厳しい制裁を受ける。
[WRITHING SECURE CODE 第2版上(P.59)より引用]
2005-01-19 (Wed) [長年日記]
・コードを短く ・カプセル化 ・前提条件を減らす ・メンテナンスしやすいプログラミング言語で書く ・テストコードを書く ・ツールを作成する ・安全な技術を用いる ・欲求不満をもつようにする ・性能についての言い分
_ 同著者による Great Programmers というコラムもあるようだ。
(via YAMDAS現更新履歴)
_ これらの記事について、Shiro氏による見解が 2005/01/17 のログに載っていた。以下一部抜粋。
良いコードとは、つまるところ適切なカプセル化とユニットテストにある、という主張に は基本的に同意。 ただ、「カプセル化 encapsulation」はオブジェクト指向界隈で「実装の隠蔽」の意味で 使われることが多いような気がする (例) ので個人的には避けたい用語だ。本当に重要な のは、(a)あるコードの変更が影響を及ぼす範囲が容易に確定できること、(b)あるコード の意味に影響を与える範囲が容易に確定できること (両者は同じことの表と裏だが、実際 にコードをいじっている時には両方を考慮している)、であるはずだ。私はこれをモジュ ラリティと呼んでいる。
_ [Programming] 実用的なGroovy: Groovyを使って、より高速にJavaコードをユニット・テストする
Groovyの取っ掛かりに良いかも。
2005-01-20 (Thu) [長年日記]
Mid-Level Nerd. Wow, it takes a lot of hard nerdy practice to reach this level.
2005-01-25 (Tue) [長年日記]
_ Google、一度に入力できるキーワード数の制限を緩和〜32語まで入力可能に
自分は10ワードで検索することも殆んどないんだけど、英文をそのまま検索するときとかには良いかも。
_ プログラマとサービス業
共感します。
ソフトウェア業界で働くなら、最低でもソフトウェアやコンピュータに興味を持った人であって欲しい。興味がなければそもそもプロフェッショナルにもなれないような気がする。
でも、自分はまだまだプロフェッショナルとはいえないよなぁ。。。
日本のソフトウェア業界でこのような成熟したプロフェッショナリズムが機能していない
ことは事実である。Tom DeMarcoのピープルウェアにもあるように、ソフトウェアは「人」
のビジネスである。そこを忘れてはならない。
[プログラマとサービス業より引用]
2005-01-31 (Mon) [長年日記]
_ [本] 1月読んだ本
「考える」ということを考える人には「思考の整理学」が特におすすめ。
ソフトウェア開発に関わる人は「ソフトウエア開発プロフェッショナル」は特におすすめ。
にやにやしたい人には「ニッポン経営者列伝 嗚呼、香ばしき人々」はおすすめ。
・伸ばしたい!英語力—あきらめない限り必ず伸びる, [本棚]
・「頭がいい」とは、文脈力である。, [借り物]
Before...
_ rbzajyn [http://www.zimbio.com/Loans/articles/ViQ57fQ8d_g/HERSHEY+M..]
_ nnnboxe [http://www.zimbio.com/Loans/articles/ViQ57fQ8d_g/HERSHEY+M..]
_ mcrhrjv [http://www.zimbio.com/Loans/articles/ViQ57fQ8d_g/HERSHEY+M..]
_ yuhkcld [http://www.kaboodle.com/wwopckg sonic payday loans faxing ..]
_ moflllu [http://www.kaboodle.com/wwopckg sonic payday loans faxing ..]