独学で 1 ヶ月間 OpenGL を学んで得た基礎知識のまとめ ~ 2D 編 ~ · けんごのお屋敷
OpenGL。その単語の響きだけで素晴らしく魅力的に思える 3D コンピューターグラフィックスライブラリは、これまで何人もの駆け出しゲームプログラマーに幾度と無く挫折を味わわせてきた。「ゲーム作るならやっぱり高速に描画できる OpenGL でしょ。でも自分が作るゲームに 3D はいらないし、しかも難しそうだし、別に 2D 描画だけできればいいや」 と、軽い気持ちで手を出したのが運の尽き、世の中そんなに甘くはなかった。OpenGL というその難攻不落城は私達の進む道を阻むように高々とそびえ立っている。 OpenGL がコレほどまでに取っ付きにくいのは 気軽に Hello World できない からなんじゃないかと思う。OpenGL の場合だとそれは何かしら 1 つの図形を表示することにあたるのかな。でもたったそれだけなのに、覚えることが山ほどありすぎて全然本題にたどり着くことができないし、O
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
MSの「Midori」プロジェクト--新言語「M#」など明らかになってきたこと
Microsoftの「Midori」OSプロジェクトに関して、この数週間で興味深い進展が2つあった。 第一に、Midori（Microsoftの非「Windows」ベースのOSプロジェクト）がエグゼクティブバイスプレジデントのTerry Myerson氏の下で、Unified Operating Systemグループに移管されたという話を筆者は2人の関係筋から聞いた（それまでMidoriはインキュベーションプロジェクトで、商品化を実現する可能性のある拠点を社内に持たなかった）。 第二に、Microsoftの上層部はMidoriチームの一部メンバーに対して、同プロジェクトのより詳細な情報を公表する許可を与えたようだ。具体的には、Midoriチームのメンバーの1人であるJoe Duffy氏が米国時間2013年12月27日のブログで、Midoriの開発に使用されている言語に言及した。この言語は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これは強力！ AWKとパイプの新しい関係 ～ 時刻を取得する関数、Socket通信、双方向パイプ
crocos.jp
