タグ

programmingとdevelopmentに関するwhaleboneのブックマーク (7)

  • 初めてのAutoCADプラグインの概要

    初めての AutoCAD プラグインの概要 > レッスン 1 > レッスン 2 > レッスン 3 > レッスン 4 > レッスン 5 > レッスン 6 > レッスン 7 >> レッスン 8 「My First Plug-in」は、プログラミングの世界をスムーズに紹介するための自習式のチュートリアルガイドです。これは、オートデスク製品を知っているがプログラミングにはまったく慣れていない、そして挑戦しようと考えているユーザのための「ワンストップショップ」学習パスです。このガイドでは、AutoCAD .NETアプリケーションプログラミングインタフェース(API)とVisual Basic .NETプログラミング言語を使用してプラグインを作成します。プラグインは‘、AutoCADにロードして機能を拡張するモジュールで’す。このチュートリアルを終了すると、.NETプログラミングの基と、その基をA

  • ペアプログラミング、実践してますか? | スラド デベロッパー

    最近redditで議論になっていたのですが、/.Jの皆さんはペアプログラミングを仕事で実践していますか? 数年前からエクストリーム・プログラミングの一環として話題になり、2003年には解説書出版に合わせて/.Jのストーリーにもなり、一部研究によれば生産性が1人で作業した場合の2倍以上になるともされていますが、タレコミ子の周辺ではまだやっている人がいないのが現状です(私のいるところが遅れているだけかもしれません……)。また、「誰もが向いているわけではない」というような意見も見られます。 ペアプログラミングを職場で実践している/.Jerの感想を聞いてみたいです。

    whalebone
    whalebone 2007/11/27
    「ベアプログラミング」
  • ソフトを一人で作るということ:ITpro

    最近,WebアプリケーションやWindowsソフトの取材で,“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフト趣味のソフトではなく,会社が商品として提供し,不特定多数のユーザーが使っているアプリケーションを一人で作って,一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも,ドワンゴの戀塚昭彦氏がニコニコ動画を一人で(しかも3日間で)作ったと語っていた(関連記事)。よく考えてみれば,ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても,企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容,また開発者のスキルにもよるだろうが,おおむね一人で開発するほうが, ・低コ

    ソフトを一人で作るということ:ITpro
    whalebone
    whalebone 2007/09/14
    「開発者側にはデメリットはあまりない」
  • 理解することが書き直すことを意味するとき

    Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新

    whalebone
    whalebone 2007/08/02
    「私は自分に作れないものは、理解できない。」
  • エクストリーム・プログラミング - Wikipedia

    エクストリーム・プログラミング、XP(英: extreme programming)は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして[1][2][3]、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。 エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある[2][3][4]。この方

    エクストリーム・プログラミング - Wikipedia
  • 小野和俊のブログ:そして、ペア・プログラミングが始まる

    ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 1セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends

    小野和俊のブログ:そして、ペア・プログラミングが始まる
  • Part1 オープンソース/C言語に学ぶ「ソースコードの読み方」:ITpro

    「Code Reading―オープンソースから学ぶソフトウェア開発技法」(毎日コミュニケーションズ発行,写真1)というがあります。私はこのの監訳者ですから,やや自画自賛になってしまいますが,ソースコードの読み方を主題にしたはほかにはあまりありません。技法からツール,データ構造,アーキテクチャ,さらには実際にコードを読んで利用する実例まで紹介している網羅的で良いだと思います。 このの「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家,他人の筆づかいを研究しなかった偉大な画家,同僚の肩越しに技を盗まなかった腕のよい外科医,副操縦席で実地の経験を積まなかった767機長――果たして,そんな人たちが当にいるのでしょうか? たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち,他の人の

    Part1 オープンソース/C言語に学ぶ「ソースコードの読み方」:ITpro
  • 1