レガシープロジェクトでテストの自動化を始めるRustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
ウノウラボ Unoh Labs: ドキュメントを楽しく楽に書くために
yukiです。 今回は主にアジャイル開発におけるコード以外のドキュメントについてお話しようと思います。 「包括的なドキュメントよりも、動作するソフトウェア」という言葉がありますが、最近これを「ドキュメントはいらない」もしくは「極力書くべきではない」と誤解され、ドキュメントが軽視されがちだと感じます。 確かに、ドキュメントは面倒です。コードを書いている方が何万倍も楽しいですし。私も出来れば面倒なドキュメントは書きたくはありません。 「コード見ればわかるでしょ」とか「コードがドキュメントだ」と言い切るのは簡単ですし、事実そういった事もあるでしょう。というより、むしろその方が多いかもしれません。ですがコードをドキュメントとして扱うには、必要十分となるようなものでなくてはなりません。 そうではない(見てもわからんような)コードが多いのも事実ですし、それにドキュメントはまったく必要ないかといえばそ
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
かんばんボードによるプロジェクトの見える化
アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。 アジャイル開発プロジェクトにおける見える化 XP(eXtreme Programming)の中に、“情報発信する作業場所”というプラクティスが紹介されている。これはプロジェクトの進行状況を、一目で把握できる
島根で Ruby と Agile：An Agile Way：オルタナティブ・ブログ
島根大学としまねOSS協議会にて、お話する機会がありました。 大学では、学生さんたち２０人に、アジャイルの概要とRubyとなぜ相性がよいか、というお話。言いたかったことは、「アジャイルは、ソフトウェアと人を育てるというモデルに基づいている。Rubyも、マシンではなく人の読みやすさや学習容易性が高い。すなわち、この２つはよく合う。」ということです。 手を上げてもらったら、１０００行以上のプログラムを書いたことのある人はいませんでした。また、何人かを除いては、チームで開発したことがないので、チーム開発の苦労がないみなさんに、Agileが解こうとしている問題が伝わったかなぁ、と少々不安です。でも、「いまITは就職先としては人気がないと聞いているが、将来IT関係に就職したい人は？」と聞くと、女性が二人手を上げてくれた！「ソフトウエアって本当に、アイディアさえあればなんでもできるからぜひ楽しみにして
『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』 - 角谷HTML化計画(2007-12-05)
■1 『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』 同僚のfkinoと一緒に監訳した『Practices of an Agile Developer』の翻訳がオーム社(オーム社!)から出ますよオーム社から。12/22発売予定。価格も2,520円(税込)と原書よりもかなりお安くなっております。 原書は今年の Jolt AwardのBooks General(一般書籍)部門でのProductivity Winnerなので、良書であることは文字通りお墨付き。『JavaからRubyへ』に続いて、今回もPragmatic Bookshelfの書籍の翻訳に関わることができて光栄だ。しかも、原書は共著者がAndy Hunt。達人プログラマ降臨。 肝心の内容はというと、原題と邦副題どおり(つまり、素晴しいタイトルだということですな)。「ひとりのアジャイル開発者として実践すべきことがら(
capsctrldays - 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ
1 『アジャイルレトロスペクティブズ』――ふりかえり本が出ますよ 私が翻訳しました『アジャイルレトロスペクティブズ』（オーム社）という書籍が9/26（水）に発売されます（オーム社!!オーム社!!）。 本書はPragmatic Bookshelfの『Agile Retrospectives - Making Good Teams Great』の全訳で、日本でいう「ふりかえり」にフォーカスした奇特な1冊です。 ふりかえりというと、日本では「KPT」が取り上げられることが多いですが、実はそれ以外にもふりかえりのプラクティスは存在します。 本書では、ふりかえりを5つのフェーズに分け、それぞれのフェーズで使用可能なプラクティスをカタログ的に紹介しています。いずれも30分程度の簡単なプラクティスです。ふりかえりをまだ導入されていない方、もっとふりかえりをうまくやりたい方、KPTに飽きた方ｗ、は是非ご一
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
【レポート】JavaOne Tokyo 2005 - 自動化、心掛けてますか? 貴重な時間は大切に (1) 無駄をなくす心がけ - 俺様の時間はとっても貴重 (MYCOM PC WEB 11/10)
JavaOne TokyoのDay-0、Javaデベロッパにはおなじみの稚内北星学園大学 丸山不二雄氏が提供する「丸山先生レクチャーシリーズ」が開かれた。この最後に「定時退社のためにJava」という一風変わった名前のセッションが開かれ、米Sun Microsystems Technical Stuffの川口耕介氏が、デベロッパはいかにして幸せになるべきか、などについて語った。 川口氏もまた、Javaコミュニティには有名だろう。2005年度未踏ソフトウェア創造事業(いわゆる未踏ユース)において、筧捷彦PMにより川口氏の「スレッド冬眠技術を利用したイベント駆動によらないワークフローエンジンの開発」というプロジェクトが採択されている。また、Hudson、com4j、parse-ipr、parse-dot-classpath、args4jといったオープンソースソフトウェアの開発も行う。parse-
プレファクタリング
「プレファクタリング」（Prefactoring）とは、pre（事前に）＋refactoring（リファクタリング）という意味の新造語です。リファクタリングとは、コーディング中にコードの動きを変えずにコードを改善する手法のこと。そして、プレファクタリングは、コーディング前にリファクタリングを行うことで、リファクタリングの効率をさらに上げようというもので、著者のKen Pughが提唱している新しい開発手法です。これにより、開発作業の迅速化、効率化が図れると期待されています。本書は開発者自身によるプレファクタリングについての初の解説書です。 はじめに 1章 プレファクタリングの概要 1.1 プレファクタリングとは 1.2 3つの極度 1.2.1 抽象化 1.2.2 関心事の分離 1.2.3 読みやすさ 1.3 指針の探究 1.3.1 背景状況がすべて 1.3.2 各自のやり方に適合させる 1.
Djangoについて - dann's blog
View View部分に関しては、Railsより好印象。 テンプレートエンジンは、PerlのTemplate::ToolkitのPython版といった感じ。これはいいね。 RailsのテンプレートエンジンもTemplate::Toolkitライクなものがあるといいなぁ。Amritaには、フィルタはないようなので、少し思っていたのと違う。 Model Model部分は、Railsより少しExplicit。これはPythonの思想が影響しているのかも。属性やValidationの仕組みなど。 RailsのほうがDSLっぽく書くことができる。ただ、Railsの場合、Implicitな部分が多いのでフレームワークの慣れが必要。 Controller Documentationの例はちょっといまいちなので何ともいえない感じ。明示的にControllerを指定はしない。 雑感 Railsがもたらした変
やってる「見える化」@marsのメモ
スクラム風に進めているけど，アジャイルだっていう意識は薄い．計画立てて計画通りに進める−−−しごく当たり前のことを当たり前にやってるので，従来型と違うという意味でアジャイルを引用するのは，なにか本質をくらませているように思う． どっちかというと従来型という名の元，実の無い作業を盲目的にやってただけなんじゃないかなぁと．「WBSだとか週報だとか面倒な割に役に立ってるかどうかわからん」と思っている人にはウケが良い． WBSが悪いってんじゃなくて，動機付けがちゃんと説明できてないだけなんだろなと．そいった事もあって，スクラムや見える化はチームビルディングの方法かなって思う． リーダの思惑 今参加してるメンバが他所のプロジェクトやりたくない！！って思うようになったら，オレの勝ち．:-D やっとできた．以下，その設定方法． 続きを読む 以前，「/WebContentで固定」って書いたけど，ムリクリ直
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kanban Applied to Software Development: from Agile to Lean
2007-08-04_21-36 - 生きてま2 改 - Trac
TheServerSide | Your Java Community discussing server side development
请稍候
時を超えた プログラミングの道