タグ

developmentに関するys0000のブックマーク (6)

  • ALMinium

    軽量チケット開発ツールALMinium ※GitポケットリファレンスでALMiniumが紹介されました。ALMiniumとGitを組み合わせて運用したい方にお勧めです. みなさんは、Redmineを既にお使いでしょうか? それともRedmineをこれから導入するつもりでしょうか? Redmineの導入は簡単そうに見えて、そう簡単ではありません。Apache,MySQL(or 他のデータベース),Rails,Redmineの実行に必要なgemのインストール...。しかもインストールするソフトウェアのバージョンによっては動いたり動かなかったりします。 BitNami Redmine Stackが提供されているので、これらを使えばRedmineのセットアップだけは簡単に完了できます。Redmineのセットアップだけは(>_<) プロジェクトで快適に利用するには、バージョン管理ツールと連携させたり

  • デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい

    デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか?」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ

    デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい
    ys0000
    ys0000 2012/02/18
    いい話。心構えが半分。実務が半分。
  • バグを生まないコーディング法、10個の規則でソフト開発を効率化(2/3) ― EE Times Japan

    バグを生まないためのルール 以下に、このコーディング規則のいくつかの例を紹介する。これらのルールは、バグの発生件数の削減に役立つだろう。 ●ルール1 if文、else句、switch文、while文、do文、for文に続くコード・ブロックを、常に中括弧「{ }」でくくる。これらの文や句に続くコードが1文だったり、何もなかったりした場合でも、中括弧でくくるべきである(図1)。 理由は、次の通りである。例えば、if文に記述した条件が成立したときに処理すべき内容が、当初は「A」という1文で記述できていたとしても、その後改変を加えて「A」と「B」の2文になったとする。このとき、最初の「A」を中括弧でくくっていなければ、「B」を追加すると同時に中括弧の記述を忘れると、後から加えた「B」という処理が、if文の条件が成立するか否かにかかわらず常に実行されてしまう。つまり、新たなバグを生み出し

    ys0000
    ys0000 2009/06/26
    コーディング規約。ルール5は意外と重要ではないかな。
  • フリーなMS.NET互換環境「Mono 2.0」がリリース | エンタープライズ | マイコミジャーナル

    Monoプロジェクトは6日、Microsoft .NET互換の開発フレームワーク / ランタイム環境「Mono 2.0」をリリースした。Linuxなど各種プラットフォーム向けにビルドできるソースコードのほか、WindowsMac OS X、Linux用のバイナリパッケージがWebサイト経由でダウンロードできる。 今回のリリースは、2004年7月公開のバージョン1.0以来となるメジャーアップデート。コンパイラにはLINQ (統合言語クエリ) をフルサポートしたC# 3.0、およびVisual Basic 8を搭載。標準装備のAPI群もアップデートGTK+のC#移植版「GTK# 2.12」や2D描画エンジン「Cairo」、DBエンジン「SQLite」が整備された。PostgresSQLDB2、Oracle、Sybase、SQL Serverなど、サードパーティー製DBエンジン用APIも収

    ys0000
    ys0000 2009/06/24
  • プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

    プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

    プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
    ys0000
    ys0000 2009/05/17
    良いプログラマとは何か、的な話。
  • エクストリーム・プログラミング - Wikipedia

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

    エクストリーム・プログラミング - Wikipedia
  • 1