サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
夏の料理
objectclub.jp
Keep Problem Try テーマ テーマはオプション KPTふりかえり会 進め方のヒント ふりかえり会のグラウンドルール ◇全員が最善を尽くしたことを疑わない 原因の追究はしても、責任の追及はしない 言い訳、自己弁護は不要 ◇積極的に参加する 当事者意識を持つ 議題に集中する ◇一人で話しすぎない 人の発言をさえぎらない 話してない人にも思いあり タイムテーブルの例 (しっかりバージョン) 目安(分) 内容 5 前回のTryとProblemを確認する 5 KeepとProblemを付箋紙に書く 10 KeepとProblemを共有する 7 Tryを付箋紙に書く 7 Tryを共有する 10 Tryを選択する 16 Tryをアクションに落とし込み合意する 合計:60 2019/5/15 Copyright (c) 2006-2019 Eiwa System Management, In
2001/05/06 作成 石井 勝 はじめに ここでは Ruby の Testing Framework , RubyUnit で普段僕が使っている Tips を紹介したいと思います.また, RubyUnit を使いやすくするために作っている Emacs Lisp 関数も合わせて解説しましょう.Meadow などで Ruby のプログラムを書いている人はぜひ参考にしてください. Acceptance Test First 僕の場合, Ruby は開発環境改善のためのツール作成に使っています.ツール作成中は本業のソフトウェア開発を中断させなければならないため,ツール作成に割ける時間といえばせいぜい数時間といったところです.そういう短時間で Ruby のプログラムを書くには,いちいちオブジェクト指向だとかクラス設計だとか悠長なことはいってられません. そこで,数時間で作成できてしまう規模のプ
やる気さえれば誰でもできますが、誰でもがすぐにできるわけではありません。できるようになるまでに、時間がかかる人の方が圧倒的に多数派です。 やる気のある人だけでチームを組んでアジャイル開発をすることを前提とします。このようなチームであれば、コミュニケーションにまつわる問題は少なくなると想像しがちですが、実際はそのようなことはなく、連係ミスなどが発生することは珍しくありません。コミュニケーションに関してだけでも、チームがアジャイルやっているという状態になるには時間が必要です。 また、後発の要求に耐えられるようなシステムやソフトウェアの構造をつくるには、それなりのスキルが必要であり、このようなスキルはやる気だけではすぐに身に付けることはできません。 しかし、やる気を持続していければ、いつかはアジャイルにやれるようになるはずです。 そもそも、「アジャイル*を*やる」ということ自体が勘違いです。開発
Copyright (c)2013 Eiwa System Management, Inc. Oblove AMANO Masaru 1/15 プロジェクトファシリテーション 実践編 計画作りガイド (株)永和システムマネジメント オブラブ 天野勝 第 1 版 2013 年 12 月 25 日 第 2 版 2013 年 12 月 26 日 第 3 版 2015 年 9 月 2 日 オリジナル:http://ObjectClub.jp/community/pf/#material このドキュメントは、クリエイティブ・コモンズ・ライセンス(帰属 2.0)の下で提供し ています。このライセンスについて詳しくは、 http://creativecommons.org/licenses/by/2.0/ を参照してください。原著作者のクレジットさえ示して頂ければ、コピー、修正、配 布してかまいません。
Copyright (c) 2012-2013 Eiwa System Management, Inc. Oblove AMANO Masaru 1/21 プロジェクトファシリテーション 実践編 見える化ガイド (株)永和システムマネジメント オブラブ 天野勝 第 1 版 2012 年 12 月 13 日 第 2 版 2013 年 1 月 10 日 第 3 版 2013 年 6 月 5 日 第 4 版 2013 年 12 月 26 日 第 5 版 2016 年 4 月 26 日 オリジナル:http://ObjectClub.jp/community/pf/#material このドキュメントは,クリエイティブ・コモンズ・ライセンス(帰属 2.0)の下で提供し ています.このライセンスについて詳しくは, http://creativecommons.org/licenses/by/2.0/
前回までで、クラスは1つの責務を持つべきである、というSRP (Single Responsibility Principle)を紹介し、その際、クラスの「名前付け」 が非常に重要である、ということに触れました。 そして、名前にまつわるエピソードとして、JTP(Joshua Tree Principle)と "Name and Conquer"について話しました。 今回は、どうやってクラス間の結合を減らすか、ということについて考えてみ たいと思います。 クラスがさまざまな他のクラスと関連を持ち始めると、そのクラスが「太って」 しまうことがよくあります。これを、"fat interface"とか、アンチパターンの 言葉で"The Blob"(肥満児)と呼びます。つまり、関連するクラス毎にメソッド が多くなり、このクラス用のメソッド群と、このクラス用のメソッド群と、と いう具合にどんどんクラス
LSUnit v0.2 LSUnitはLotus NotesでLotus Scriptのユニットテストを行うためのテスティングフレームワークです。 著作権は作者にあります。ご使用に関してはこちらの使用許諾契約を一読願います。 更新履歴 2012/7/5 公開場所を移動Lycos⇒オブラブ 2002/5/6 v0.2公開 2001/7/2 v0.1公開 動作環境 Lotus Notes R4.6.7 Windows98/2000 上記の環境にて動作を確認しています。 その他の動作環境について、報告していただけるとうれしいです。 ダウンロード インストール方法 ここでの説明は、R4.6.7を対象に書いています。 lsunitxx.lzhをダウンロードします。xxにはバージョン番号が入ります。 ダウンロードしたファイルをディレクトリ付きで解凍します。 ファイルを解凍すると以下のファイルがあります
Date: Wed, 19 Oct 2005 14:00:41 +0900 Subject: 【オブジェクト倶楽部: 2005-38号】 X-Mail-Count: 00119 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■ ┃ ■┃ ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃ ┃ ■ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛ No.113 2005/10/19 ■ I N D E X ┃ ┣【Topics】『正しく学ぶソフトウエア設計』プレゼント ┣【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[9] ┣【PF】アジャツール - Agileなツール紹介[4] ┗【アンケート】気になるシステム業界 ホントのところ 〇━━━━━
"And there's business value in fun" Ruby好きとしても知られるMartin Folwerのblikiに「 ダイナミックタイピング 」というエントリがあります。このエントリでFowlerは、SmalltalkやRubyでのプログラミングは楽しい、と前置きした上で: And there's business value in fun - after all motivation is a major factor in programmer productivity. "そして、楽しさにはビジネス価値がありますーー結局、モチベーションこそがプログラマの生産性を左右するのです。" と述べました。以来、私は「And there's business value in fun」を勝手に自分自身のミッション・ステートメントとしてきました。今回のRubyKaigi2
(株)永和システムマネジメント 平鍋健児 作成日:初版 1999, 3/16 第2版 2002, 11/6 第3版 2004, 9/14 第4版 2008, 5/1 情報処理技術社試験の中で良く出て来る「待ち行列」理論を,直感的に覚えやすく解説してみました. 何度もトライしたけど待ち行列が理解できない人向けです. 正確な定義や論理展開は重視せず,いかに効率的にこの理論を覚えることができるかに焦点を絞ってみました.
(株) 永和システムマネジメント 平鍋 健児 Kenji HIRANABE 作成日:第4版 2001,8/10 第3版 2001,1/16 第2版 2000,10/21 初版 2000,10/10 エクストリームプログラミングは,Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)である. 正式にはエクストリームプログラミング(eXtreme Programming), 略してエックスピー(XP)と呼ばれる.この記事でも,以下 XP と呼ぶことにする. Kent Beck は,'99年に "Extream Programming Explained - Embrace Change" という書籍を著した.これは "EC 本" とも呼ばれ,XP のバイブルともなる. この記事では,この "EC本" を基礎に XP
1999/06/11 石井 勝 概要 この記事では,まずOpen-Closed Principleの意味と解説を行い,その後デザインパターンをOpen-Closed Principleの観点から眺めます.デザインパターンのうちの多くはOpen-Closed Principleを満たすために用意されたものとみなすことができます.Open-Closed Principleを理解し,数あるデザインパターンの中から,どういう場合にどのパターンを使うのが一番効果的なのかを考えます. 目次 はじめに ソフトウェアと連続性 仮想仕事の原理 修正と追加 Open-Closed Principle Open-Closed Principleの例 Open-Closed Principleの反例 オブジェクト指向とOpen-Closed Principle デザインパターンとOpen-Closed Princ
この記事では、ソフトウェアパターンの中でも、特に Gamma らの著書「デザインパターン」に絞って入門者および中級者向けの解説を行う。 Java プログラミングの経験はあるがデザインパターンはよく知らない、 あるいは、 よく知っているが、実際の開発で活用するにはどうしたらよいか悩んでいる という読者を対象としている。 まず、なぜデザインパターンが重要かということを述べた後、 書籍「デザインパターン」の読み方を解説する。 さらに、パターンの持つ特質である生成性を述べ、 最後に、実際に動作する Java アプリケーションをデザインパターンを利用しながら開発する例を説明する。 「デザインパターン」は Gamma らの著書によってソフトウェア設計における良質なデザインテンプレート集として広く認知されているが,実際の開発現場では,どの程度普及したであろうか.もし読者が java プログラマであり,ま
POSA
パネルディスカッション『オブラブ10周年 - オブラブは世界を変えたのか』 オブラブは今年で10周年を迎えました。オブラブが走り抜けてきたこの10年をふりかえりながら、オブラブと私たちが壊してきたもの、壊せなかったものについてオブラブの中の人に語っていただきます。そして最後に未来に向かって電波をゆんゆん飛ばします。 コーディネーター 安井 力 (Tsutomu YASUI) (オブラブ) パネリスト 天野 勝 (Masaru AMANO) (オブラブ 事務局長) 岡島 幸男 (Yukio OKAJIMA) (株式会社永和システムマネジメント) 角谷 信太郎 (Shintarou KAKUTANI) (オブラブ) 懸田 剛氏 (Takeshi KAKEDA) (カルチャーワークス) 渡邊 拓也 (Takuya WATANABE) (オブラブ) 濱崎 健吾氏 (Kengo HAMA
6/28: ライトニングトークスのトーカーを発表しました。 6/28: 参加登録受付を再開いたしました。 6/27: ただいま参加登録受付を一時的に停止しております。 6/01: 夏イベントの申し込みを開始しました。 5/25: 夏イベントサイトオープンしました。 この10年で変わったもの、変わらなかったもの オブラブが、オブジェクト倶楽部として本格的に活動を始めて、約10年の月日が経ちました。 当時では想像ができないほど、この10年間で日増しにIT技術が社会に与える重要性が高まっていくのを感じています。その中で、オブラブで扱うテーマも変わり、それに伴い果たす役割も変わってきましたが、ソフトウェアエンジニア同士の交流の場を提供するというポリシーはいまだ健在です。 今回のオブラブイベントでは、10年という月日を掲げたテーマとしました。 10年前は何をしていましたか? 10年後は何をしています
今回は、テストと進捗管理(その2)である。Alistair Cockburn は、ソフト ウェア開発の「一個流し」(*1) と進捗管理について、おもしろい例を出してい る。次の問題を考えてみて欲しい。 30個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、1ヶ月というデッドラインを守れるか。 ■ウォーターフォール的計画: 最初の1週間で全部屋の掃除を行なう 次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る 次の1週間で全部屋のダンボール箱詰めを行なう 次の1週間で全部屋のチェックを行なう 4週間あるので、4週間後には全部屋のチェックまで終わる ■一個流し的計画(すなわち、アジャイルな計画): 日割りで、1日に1つの部屋を、掃
© NEC Corporation 2006 オブジェクト・ゲーム ~コードを使わず最速でオブジェクト指向がわかる方法~ 2006年 6月29日 NECシステムテクノロジー 第一産業ソリューション事業部 牛尾 剛 © NEC Corporation 2006 CIO プロセス改善/生産革新部門 管理者 普通の技術者 出来る技術者 ・オブジェクト指向がわかった ・最新アーキテクチャが理解できよう になった ・一般の技術者でもオブジェクト指向が わかってもらえるぞ ・オブジェクト指向ベースの手法が使え るようになるな ・はじめてオブジェクト指向とPJでどう 使うかがわかった ・すぐには導入しないけど、事例が増え たら使ってもいいかも・・・ ・はじめてオブジェクト指向とPJでどう 使うかがわかった ・アーキテクチャが違った見方ができる ようになった ・独学でわかりにくいところがわかった ・後輩に
チーム割引について ============================== チーム割引でのお申込みは終了致しました。 ============================== オブジェクト倶楽部2010夏イベントでは、チーム割引制度を導入します。 チーム単位でお申込みいただくと、2人目以降の講演会参加費が半額になります。 例1)2人のチームでお申込みの場合3,000円+1,500円=4,500円(2人分の参加費) 例2)3人のチームでお申込みの場合3,000円+1,500円+1,500円=6,000円(3人分の参加費) チーム割引にてお申込みされる方は、「チームの代表の方1名」が、2010summer at ObjectClub.jpまで、以下の項目をご連絡ください。 追って、事務局より、チーム割引お申込み方法を記載したメールをお送りします。 ※事務局からのメールが届きましたら、
『ワークショップの作り方』 ワークショップでも仕事でも、メンバー(関係者)にとって積極的に参加すると好いことがある、という動機付けを生むことが大事です。 今回はそのよい動機の循環をいかに作るか、そのファーストステップと維持のしかた、発言量を増やし、コミュニケーションをかみ合わせることについて、引き出し方と掘り下げ方を中心に実践的に皆様と考えたいと思います。 単なるアイスブレイクにとどまらず、コミュニケーションの改善とモチベーションの向上をいかにするか、みなさまに実践していただく足がかりにしたいと思います。 本間直人氏(naoto HOMMA) NPO国際ファシリテーション協会理事、NPO 学習学協会理事。講演活動では、コミュニケーション、ファシリテーション、コーチングのほか、研修講師として活動中。笑いあふれる参加型研修が特徴。著作物には、『チーム力をつくる3ステップ』(翔泳社)等がある。九
JUnit 実践講座 - シナリオベースのテストケースの書き方 2002/02/03 作成 石井 勝 目次 はじめに メソッドベースとシナリオベース サンプルプログラム - LoginFormTest クラス scenario メソッド verify メソッド Scenario インナークラス テストに応じてスタイルを変えよう シナリオベースの問題点について 特殊解をあらわにするヘルパーメソッド はじめに ここでは,テストケースの具体的な書き方として,シナリオベースのテストケースを紹介します.プログラミングスタイルガイド で述べたように,実際の開発ではテストコードはかなりの規模になります.どうしたらテストコードを読みやすく,メンテナンス性を上げることができるのでしょうか? …僕には,まだこの問題に対する満足な答えを得ることができません.しかし,シナリオベースでテストケースを書けば,場合によ
1999/09/03 更新 石井 勝 さて,このセクションではデザインパターンを統一的に理解するために,「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします.まず OCP の意味と解説を行い,その後デザインパターンを OCP の観点から見てみます.実は,デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです.このセクションでは, OCP を理解し,数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます. GoF のデザインパターンは,全部で 23 個ものパターンがあります.このデザインパターンは,多くの局面で繰り返し現れる設計を抽出したものですから,オブジェクト指向のエッセンスを集めたものだと言えるでしょう.オブジェクト指向には,カプセル化,継
「アレグザンダーを考える。パタン・ランゲージ、漸進的開発、そして生成の原則へ」 オブジェクト倶楽部では、デザインパターンやアジャイルプロセスの原点であるアレグザンダーに再び着目し、これからのソフトウェア開発が向うべき方向性へのヒントを持ち帰っていただきたいと考えています。 ソフトウェアパターンムーブメントのキーパーソンであり、パターンやオブジェクト指向についての数多くの著作を記しているJames.O.Coplien氏と、アレグザンダーに師事した経験をもつ建築・町づくりの第一人者である中埜博氏/笹川万国氏をお招きします。 Coplien氏には「ソフトウェア開発とパターンと生成の原則」に関する講演を、中埜/笹川両氏にはアレグザンダーのパターンと生成の原則を体感できるワークショップを実施いただく予定です。また、自分も語りたい!という方々のために、ライトニングトークスもご用意しています。 ぜひ、ご
2003/01/05 石井 勝 はじめに ここでは,makeを使ってプログラマやSEが普段行なっている作業を自動化する方法を解説します. makeはプログラム開発だけでなく,いろいろな作業を自動化してくれます.自動化する作業のプラットフォームとしてmakeを活用することができます.ところが,最近はmakeを理解できる開発者が非常に少なくなってきました.普段統合開発環境を使っている人が多いことや,makeについて書かれた書籍やサイトが非常に少ないことが原因でしょう.makeについて少しは知っているけど,あまり使いこんだことがない人はこの記事を参考にしてみてください. 一口にmakeといってもいろいろな種類があり,それぞれ仕様が異なります.ここでは,僕が普段使っているGNU makeについて解説します.GNU makeは機能が豊富で他のmakeツールやAntに比べ優れています.開発環境は,僕が
次のページ
このページを最初にブックマークしてみませんか?
『オブジェクト倶楽部 - TOPページ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く