スクラムの新しさ - プログラマの思索
スクラムが従来のアジャイル開発に比べて優れている点は、役割のバランスが絶妙なことにあると思う。 また、日本の受託ソフトウェア開発の最大の弱点は、プロダクトオーナー不在が常駐化している事だと思う。 色々考えたことをラフなメモ書き。 【参考】 日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記 ソフトを他人に作らせる日本、自分で作る米国：日経ビジネスオンライン Twitter / akipii: PMBOKではプロジェクトマネジャが発注者にいることが前提になっている。日本ではIT企業すなわち受注者にPMがいることがほとんどだから、米国の手法を修整して取り入れないとうまくいかない。ソフトを他人に作らせる日本、自分で作る米国 http://business.nikkeibp.co.jp/article/tech/20121010/237890/?P=3&rt=
構成管理パターンの記事「Streamed Lines: Branching Patterns for Parallel Software Development」 - プログラマの思索
構成管理パターンの記事「Streamed Lines: Branching Patterns for Parallel Software Development」 「実践 反復型ソフトウェア開発」に構成管理のパターンやアンチパターンに関する記事があったのでメモ。 ラフなメモ書き。 【元ネタ】 Streamed Lines: Branching Patterns for Parallel Software Development 1999年に書かれたという上記の記事は、構成管理に関する基本的な考え方が体系立てて書かれている。 内容は、ブランチ管理やマージの考え方、手法が整理されたもの。 1999年といえば、CVSが普及する前後であり、SubversionもGitも出現していなかった時代ゆえに、先を見通した良い記事かなと思う。 「パターンによるソフトウェア構成管理」よりも内容が詳しい。 内容は
Gitによるチケット駆動開発の事例 - プログラマの思索
資料を要約しながら、自分の感想も入れてみる。 SVN主導の開発で抱えていた問題。 「pull request主導のチケット駆動開発したい。svnには障壁が多い。」 trunk, staging, releaseの3つのメインブランチ戦略。 (僕もSVNでこのブランチ管理の経験はある。 きちんとソース管理はされているが、マージが手作業な場合、ライブラリアンの負荷が途方もなく大きい。 どのリビジョンをリリースするのかというExcel申請書が大量に届いて、それを見ながら手作業でマージしてビルドする。) SVNはマージやブランチを切るコストが大きすぎる。 (trunkから派生したブランチとtrunkの間のマージはまだ楽だが、ブランチ間同士のマージはまだまだ厳しい。) 理想は、GitによるPullRequest主導のチケット駆動開発。 (チケットにソースの修正理由や発端、経緯が記載されている、ないし
橋本商会 » 別ドメインのiframeの中身をフレーム外からスクロール
諸事情あって、iframeの中身をフレーム外側のページからJavaScriptでスクロールできるのを作った。 ふつうは別ドメインのページをiframeに読み込むとスクロールできないんだけど、（marginに負の値を入れたりして）iframeごと上下左右に動かしたり、iframeの外側にbox要素2つ付けてはみだした部分を表示しないようにcssでなんか色々やったりしたらそれらしい物ができた。 デモ XFrame.js shokai/xframe.js · GitHub 使い方は簡単である js読み込んで <script src="xframe.js"></script> XFrameを出したい箱を作って <div id="tv"></div> 読み込む var xframe = new XFrame("div#tv"); xframe.load("http://shokai.org"); あ
『Kent BeckのxUnitテストパターン』
Kent Beckの『テスト駆動開発入門』で紹介されている33のテストパターンを、簡単に一覧で紹介。テストパターンに関する原典的な意味合いもあり押さえておく必要があるが、テスト実践に直接役立てるには少々内容が漠然としすぎている。それでも、「■テストに関するパターン」あたりは実践色が強く、役に立ちそう。 ケント ベック, Kent Beck, 長瀬 嘉秀, テクノロジックアートテスト駆動開発入門 ■テスト駆動開発のパターン ・テスト（名詞） 自動テストを書こう。自動テストによって、開発のデススパイラルから抜け出せる。 ・独立したテスト テストは互いに独立でなければならない。他に影響するようなテストを書いてはいけない。 ・テストリスト 何をテストすればいいか迷うので、まずテストリストを作ることから始める。 ・テストファースト テストを書き始めるタイミングは、テスト対象のコードを書き始める前に。
『DIコンテナを使った開発のパターン』
先日、Springユーザグループの勉強会に参加してきた。そこでは、Springを使った開発のパターンをみんなで考えるという、ワークショップ形式の面白い試みをしていた。 今回議論に挙がったのは、インタフェースをどういった方針で用意するかに関するパターンと、Bean定義ファイルをどのように用意すべきかに関するパターンの2つだった。（その結果は、ここに暫定的にまとめられている） Spring開発パターン化の試みを振り返って思いついたのは、こうしたパターンの多くはSpringだけでなく、Seasarやその他のDIコンテナ（Pico、HiveMind、Guice・・・）を使った開発にも共有できるだろうということだ。 J2EEパターンや.NETエンタープライズソリューションパターンに対してFowlerのP of EAAがあるように、SpringパターンやSeasarパターンに対して、より汎用的なDIコ
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
『分割統治（Divide and Conquer）について』
プログラミングには「分割統治（Divide and Conquer）」という考え方がある。非常に複雑で大きな問題をプログラミングで扱うときは、そのまま全体に取り組もうとせず、問題を単純な小問題に細かく分割して解決せよ、という考え方だ。プログラマにとっての常識といってもいい。 分割統治という言葉自体は、プログラミングの世界で新しく考え出されたものではなく、古代ローマの時代からある非常に古い言葉だ。知っている人も結構いると思う。しかし、そこから先へ、もう少し深く突き詰めて調べてみた人は、案外少ないのではないだろうか？ 分割統治をプログラミングの世界に持ち込んだのはダイクストラ 私の理解では、分割統治の考え方をプログラミングの世界に持ち込んだのは、かの有名なエドガー・ダイクストラ（構造化プログラミングの生みの親）だ。1965年に書かれた論文「Programming Considered as a
『ドメインロジックの実装方法とドメイン駆動設計』
以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。（アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています） http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介 前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え
『DIコンテナとドメインモデルの相性の悪さ』
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
『Mavenプロジェクトで3rdパーティJARを扱う方法』
最近北欧よりの記事ばっかりだったので、Mavenネタを1つ。Mavenプロジェクトでスマートに3rdパーティJARを扱う2通りの方法を説明する。 Mavenの最大の利点の1つに、依存JARライブラリがローカルPC上の中央リポジトリで管理され、プロジェクト毎の管理が必要ないという特徴がある。しかし、利用したいライブラリがオープンソース（OSS）でなかったり、OSSでも非常にマイナーなものだったりすると、リモートリポジトリに無くて使えない。 この場合によく説明されるのが、以下のようにしてJARをローカルリポジトリに手動でインストールする方法だが、チームで開発しているときに、この作業をメンバひとりひとりにやらせるのは非常に格好が悪い。> mvn install:install-file -Dfile=<JARへのパス> ...かといって、Antの時代に戻ってプロジェクトの lib フォルダの下に
構成管理ツール Ansible について - aptheia.info
Ansible というサーバーの設定を管理するツールの説明。いわゆる構成管理 (CM: Configuration Management) にカテゴライズされるもので、Puppet や Chef の親戚みたいなものと考えてもらえればだいたいあってる。 概要 リード開発者は Michael DeHaan で、現職の AnsibleWorks の前は Redhat で Cobbler や Func に携わっていたり、Puppet labs でプロダクトマネージャーしたりしているという経歴の持ち主。 Ansible は Python で書かれている。同じジャンルで Python 製というと Salt が有名。Chef の場合、レシピを書くためには Ruby の知識が必要となってくるけど、Ansible はどんな言語でもモジュールが書けるようになっているので、運用にあたって Python の知識は
今のJava EE 6開発での利用技術をまとめてみた - Challenge Engineer Life !
最近絶賛ネタ切れ中です…。開発でつまづく所がだいぶ減ってきたのと、開発が忙しくなってきてインプットがないからですね…土日で吸収していきたい所です。 というわけで、今日は仕事上でも整理する必要があったため、現在のJava EE 6開発で利用している技術（というか基盤とかライブラリとか）を整理してみました。 Javaの世界へ足を踏み入れてから約8ヶ月。初めてなことだらけで結構しんどかったけれど、開発の観点という意味でも色々なことを学べたし、今後も学んでいきたいと思う今日この頃です。 種類 利用技術 開発プラットフォーム Java EE 6 JDK JDK 7 IDE NetBeans 7.3 アプリケーションサーバ GlassFish 3.1.2 プロジェクト管理とビルド Maven 3 ソース管理 Subversion プロジェクト情報共有と障害管理 Trac 構成管理 Jenkins 自動
Challenge Engineer Life !
2023-07-29 ZenlabのAPI Night#2に参加しました！ #zenlab Zendesk 勉強会 Zendeskのユーザーコミュニティ「Zenlab」が開催したAPI Night #2に参加しました。zenlab.connpass.comZendeskのAPIを触るハンズオンやLT、Zendeskの中の方からのお話と内容の濃いイベントでした。懇親会でZendeskの中の方々と直接お話できたり、他社さんに… 2023-04-23 AWS Summit Tokyoに参加しました！ AWS 4月20,21日に幕張メッセで開催されたAWS Summit Tokyoに参加しました。幕張メッセに行くのはコロナ禍前の乃木坂ちゃん握手会以来です。懐かしい...。 AWS Summit Tokyo at 幕張メッセ大賑わいAWS Summitの参加は多分2回目。1回目はSendGridとし
プログラマの思索
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
文字コード変換ミスによる文字化けパターンと想定される原因 - drk7jp
とあるシステムでデータベースから引いてきたデータの表示が文字化けするという不具合がありました。 データベース内のデータとしては文字化けしていない状態で格納されていることはわかっていたので、どこかしらの文字変換で化けていることはわかっています。まずはどの誤変換により文字化けするのか原因切り分けのために、decode/encode の組み合わせによる文字化けパターン一覧を作りました。おかげさまでどのパターンに類するものか判別することができ、無事に改修することができました。 その話はまた別にするとして、今も昔も変わらず文字化けに悩む人は意外と多いと思います。誤変換結果一覧は原因解析の参考になると思い、記事としてまとめることにしました。 文字コード変換ミスによる文字化けパターンを可視化するプログラムと一覧表 まずは誤変換を生成する perl スクリプトです。プログラムはとっても簡単で、「文字化けで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践反復型ソフトウェア開発を読む part2～マージの戦略 - プログラマの思索
実践反復型ソフトウェア開発を読む part1～ブランチの戦略 - プログラマの思索
A successful git branching model とgithub flowの比較 - プログラマの思索
ブランチ管理とGitコマンド～「実践 反復型ソフトウェア開発」を読む