プログラマに質問。初めて出向く現場が 時間的に厳しく、短い時間で仕様を理解し、 開発に着手しなくてはいけない状況だったとします。 このようなときに仕様理解を効率的に行うための 知識の整理方法はありませんか？ 個人的な方法や、 マインドマップのような型にはめた方法も大歓迎です。 なおこの質問は、漠然とした質問ですので 完璧な回答はないと思っています。 ですが、回答の一つ一つにきっと意味がありますので 教えていただきたく宜しくお願いします。
プログラマに質問。初めて出向く現場が 時間的に厳しく、短い時間で仕様を理解し、 開発に着手しなくてはいけない状況だったとします。 このようなときに仕様理解を効率的に行うための 知識の整理方法はありませんか？ 個人的な方法や、 マインドマップのような型にはめた方法も大歓迎です。 なおこの質問は、漠然とした質問ですので 完璧な回答はないと思っています。 ですが、回答の一つ一つにきっと意味がありますので 教えていただきたく宜しくお願いします。
「"All I really need to know about pair programming I learned in kindergarten", Communications of the ACM, Volume 43, Issue 5 (May 2000) Pages: 108 - 114」という論文を読みました。 幼稚園(もしくは保育園)で習うような社会生活の基礎から、ペアプログラミングを遂行するときに注意すべき点を論じています。 ペアプログラミングは、二人で一緒にプログラムを書くという手法です。 XP(eXtreme Programming)などで利用されています。 面白かったので一部を抜き出して要約してみました。 さらに興味のある方は論文をご覧下さい。 何でも分け合うこと ペアプログラミングでは一つのものを二人が作り上げます。 片方がプログラムを書き、相方がレビューを続
Webのスピード感で開発――「Apollo」が注目集める理由 − ＠IT 米アドビ システムズが開発中のミニアプリケーション実行環境「Apollo」が注目を集めている。 デスクトップアプリをWebのスピード感で開発する「Apollo」。 Appoloとは、 AjaxやFlash、PDFなどのテクノロジを使ってオフラインでも動作可能なデスクトップアプリケーションを開発する技術 らしいです。 Windowsアプリ開発といえば、VisualStudioなどの専用の開発環境で作るのが一般的な流れでしたが、Webの技術を使って作れるというのは面白そう、 かつWeb技術者としては注目したいですね。 これまでも、FirefoxのUIに使われているXULや、Konfabulator のような、JavaScriptを使ったものもありましたが、 JavaScript にFlashやPDFを加えることで開発の方
「Basics of the Unix Philosophy」でUNIX哲学の基本原則がまとめられています。 UNIXの設計思想として紹介されていますが、多くは普通のソフトウェアを設計する場合にもあてはまると思われます。 1. Rule of Modularity(モジュール性): きれいなインターフェースで接続された、簡潔な部品を書きましょう。 2. Rule of Clarity(明瞭さ): 明瞭さは賢さよりも良いです。 3. Rule of Composition(構成): 他のプログラムと接続できるようにプログラムを設計しましょう。 4. Rule of Separation(分離): ポリシーとメカニズムを分離しましょう。エンジンとインターフェースを分離しましょう。 5. Rule of Simplicity(単純性): 単純化された設計をしましょう。複雑さは必要な時だけ追加しま
浮動小数点演算ではまった話 浮動小数点演算のありがちな問題ではまりました。 いろいろ調べているうちに x86 特有のちょっとおもしろい 現象に遭遇したので紹介したいと思います。 パーセンテージの計算 簡単な C のプログラムでパーセンテージを計算しようと思い、 次のようなコードを書きました。 int x, y; ... int a = (double)x / y * 100; int a = x * 100 / y としないのは、 x が大きい場合に x * 100 が オーバーフローを起こす (INT_MAX を越える) ためです。 このコードは一見、期待通りに動いていたのですが、 しばらく使っていると、手元の環境では x = 53, y = 100 のときに a は 53 ではなく 52 になることに気づきました。 これは次の理由によります。 式の最初の (double)53 / 10
昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 １．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる ２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる ３．こね板の上で生地をこねる ４．ボールにラップをして室温で１時間発酵させる（一次発酵） ５．適当な大きさに生地を分割し、丸めて形を作る ６．オーブンに入れ、３０分発酵させる（二次発酵） ７．オーブンの温度を２００度にして１８分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。 興味深いのは、このレシピにおける、「１５分予備
かなりターゲットの狭いTips。役に立たない。 prototype.jsというRuby on Railsなんかのフレームワークで使われている有名なJavaScriptのライブラリがあって、これが色々と使えそうな処理を綺麗に詰め込んであり、デファクトスタンダート的な地位を確立しているのだけれど、ちょっと微妙だなーと思うところがあって、それはObject.prototypeを拡張してしまう点。 実際の弊害はこういう。 http://d.hatena.ne.jp/nazoking/20050425/1114374966 要は連想配列として使うときに困るって話。 多分prototype.jsはJavaScriptの側でロジックを組むことをあまり想定していないため、この辺の問題にあんまり配慮していないのではないかと思うのだけれど、とりあえず無理やり回避する方法を思いついたので書いてみる。 http:
はじめに 2012年5月現在、最近、このページはあまり更新できていません。すみません m(_ _)m。 D言語友の会 が、長期間ちゃんと更新されている D 言語関係の日本語サイトとしておすすめです。 こんにちは。ここは、プログラミング言語 D （D Programming Language, 通称D言語）を紹介するサイトです。 すでに Java など一般的なプログラミング言語の経験がある読者を前提として書かれています。 一部古いページを除いて、基本的に、D 2.x 系統の言語仕様をベースに解説しています。 → 更新情報は RSS で 目次 1. Dってどんな言語？ サンプルコード色々 D言語を大きくカテゴライズすると、「C風の構文を備えた」 「静的型」の「ネイティブコンパイル」言語と いうことになります。オブジェクト指向やテンプレートメタプログラミングなど、 幾つかのパラダイムをサポートし
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
Part3では，もはやオブジェクト指向開発では欠かせない存在となったソフトウエア・パターンについて解説しましょう。デザインパターンに代表される様々なソフトウエア・パターンを活用して，熟練者の経験を盗み，オブジェクト指向開発を円滑に進める術を習得してください。 ソフトウエア・パターンの全貌 皆さんは誰かが書いたプログラムを眺めていて，どこかで見たようなソフトウエア設計やコードに出くわしたことがありませんか？ 「このクラスの役割はどこかで見たことあるなあ」とか「このコードは何度も自分で書いたことがあるぞ」といった感覚です。そのような既視感は，そのコードを書いた人が，皆さんと似たような状況で，繰り返し発生する問題を抱えて，似たような設計/実装を行ったからかもしれません。 ソフトウエア・パターン＊1は，このような繰り返されるソフトウエア設計を集めたものです。それも単に集めたのではなく，様々なソフト
2006年11月30日00:45 カテゴリLightweight Languages 電脳言語における祖先の呪い--演算子篇 というわけで、Cの娘達が、Cにどのように呪縛されてきたかを考察してみる。 404 Blog Not Found:プログラマーが単一言語にこだわるべきではないN個の理由 比較的それに近いのはDだけど、それでもDはCとJavaの呪縛が強すぎるように思う。次回はそのことについて述べようと思う。Cの呪い、というより母言語の呪いとして一番強いのは、実は静的とか動的とか、コンパイラ言語だとかスクリプト言語だということではなくて、演算子、もう少し具体的に言えば、「どんな記号をどの演算子に割り当てるか」だと思う。 Cに関しては、特に強かった呪縛は->演算子。そしてなぜこれが呪縛になったかというと、単項(unary)の*、すなわちポインター参照が前置だったから。 おかげで、Pasca
<div align=center><applet code="Graph.class" width=400 height=400> <param name=edges value="x-a1/50,a1-a2/100,a2-a3,a3-a4/50,a4-a5,a5-a6,a6-x,x-b1,b1-b2,b2-b3,b3-b4,b4-b5,b5-b6,b6-x,x-c1,c1-c2,c2-c3,c3-c4,c4-c5,c5-c6,c6-x"> <param name=fixnodes value="x"> </applet></div> 何らかのパラメータ入力を受け付けた後の結果出力として、 このような「動く」グラフを表示することを考えています。 このサンプルではグラフは変化しませんが、 上記のようなHTMLソースコードを出力するプログラムを サーバーで動かすことにより、その場その場で異る
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説
Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。 今後日本が没落していく理由とも同じです。 団塊の世代に無能な人間が多い理由とも同じです。 サービス残業が増えた理由とも同じです。 日本の多くの若者たちが未来に希望を抱けない理由とも同じです。 いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。 その理由は、根本的には、「単純ニーズの飽和」という環境変化に起因します。 そして、それによって、プログラミングが経営行為になってしまったことが原因なのです。 団塊の世代の仕事人生の大部分は、単純ニーズを満たすための仕事に費やされました。 冷蔵庫の普及率が低く、しかも誰もが冷蔵庫を欲しがった時代には、何をやるべきかは、明らかでした。 とにかく、額に汗して働き、安くてよい冷蔵庫をどんどん作れば良かったのです。 冷蔵庫に限らず、洗濯機、ラジオ、テレビ、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
