未来のいつか/hyoshiokの日記 - Community Based Development
OSSの破壊力はバザールモデルとして知られるソフトウェア開発方法論である。バザールモデルというのは言いかえれば、コミュニティによる開発(Community Based Development)である。 企業は「カネ(利益)」をほぼ唯一の行動原理とするが、コミュニティの行動原理というのは実のところよくわからない。少なくともわたしには精密に記すことは難しい。知ったかぶって、さも判ったふりをして書くという愚行はおかさないようにする。 ある程度共通の行動原理は存在するかもしれないが、あえてここではそれをまとめることはしない。 コミュニティによる開発のお作法というのは企業が開発するソフトウェアのお作法と相当ことなるし、それを理解しない事には企業はコミュニティと上手に付き合うことができない。 日本の企業の多くはコミュニティによる開発経験を持たないし、特に大手企業にお勤めの中間管理職でそのような経験を持
Webサイト構築の初歩：ハードウェア構成はどうする？ ― ＠IT情報マネジメント
第2回 Webサイト構築の初歩：ハードウェア構成はどうする？：キーワードでわかるシステム開発の流れ システム化するのに必要なもの 青木室長 「ふむふむ。考えるべきことは多そうだな」 赤井君 「最初の企画段階で、どこまでの構想を練り上げておくかが肝心です。何年後に何人の会員を獲得し、どれだけの売り上げと運用コストが発生するのか……とか、そうしたことを考えずにその場限りの雰囲気と予算でスタートし、何年かたったころに、やっぱり作り直しだと悲鳴を上げている会社は結構あります」 青木室長 「今日の赤井君はいつになく熱いな」 赤井君 「……（あっ、つい前職のときの感覚が……）。いや、もし失敗したら、青木室長の出世に影響しますから」 青木室長 「（うれしそうに）そうか。君がそこまで考えてくれているなら、私もいろいろ勉強しながら取り組んでみるし、必要な予算獲得も社長に掛け合ってみるよ。費用としては、そのシ
フリーランスが請けたくないプロジェクトの特徴:Geekなぺーじ
「7 Signs Your Project Will Never Make it to Production」 という記事がありました。 フリーランスとして働いている著者が、プロダクトとして発表されるに至らないプロジェクトの特徴を述べています。 このような特徴を持つプロジェクトに参加しても、自身のポートフォリオに新しい製品を追加する事はできないそうです。 面白かったので要約してみました。 全てにおいて真であるとは思いませんが、何と無くありそうな話だと思いました。 1. クライアント側でUIモックアップを制作したことが無い クライアントは自分が何を制作したいのかを良くわかっていません。 2. クライアントは、ドキュメントではなく電話越しに内容を伝えようとする かなり危険な状態です。 何らかのドキュメンテーションが出来上がるまでは仕事を請けるべきではありません。 3. クライアントの個人的欲求
要求開発アンチパターン(1)
言うまでもなく，ビジネス環境の厳しい変化と，ITの急速な技術革新の中にあって，ビジネス価値を高めるシステム構築を実施することは，決して簡単なことではありません。皆さんの周囲には，要求が明確でないまま，コストと時間ばかりかけている「要求不在」のシステム構築プロジェクトはありませんか？ 「要求開発アライアンス」は，要求開発方法論（Openthology）を検討・公開することによって，ビジネス価値を高めるシステム構築の実現を支え，「要求不在」のシステム構築プロジェクトを撲滅（？）しようと努力しています。しかし，プロジェクトの現場ではいろいろな問題があるようです。 今回と次回の2回にわたって，要求開発がうまくできていないプロジェクトのありがちな症状を，アンチパターンとして紹介します。 症状： 既存システムに縛られるあまり，新しい発想や要求が発生しない 例： ・長年にわたって既存システムを使っている
CodeZine：「超高速、完全自動、しかもフリー」 WebテストツールのGITAK公開（TIBCO, 開発ツール）
TIBCOは、オープンソースのWebサイトテストツール「TIBCO General Interface Test Automation Kit 0.7」（GITAK）を公開した。TIBCO Developer Networkより無償でダウンロードできる。 「TIBCO General Interface Test Automation Kit」は、Webサイトの入力チェック、ボタンの動作内容、JavaScriptの動作などを自動で一気にテストできるツール。すべてのテストがブラウザで完結するのが特徴だ。ダウンロードファイルにはサンプルが含まれているので、試しに動作させてみることができる。 1.GITAKの入手 TIBCO Developer Networkよりファイルをダウンロードし、解凍する。 2.TestRunner.htmlの起動 解凍してできたフォルダから「/gitak/c
デブサミ2007所感 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ つらつらと。 思い返せば、日立ソフトの河村さんにお誘いいただき講演させていただいたのが昨年。その後、コンテンツ委員（コミュニティ関連の講演者手配とか内容検討をする秘密結社）にもお呼びいただいてアーキテクチャゾーンの担当に。それなのになぜか開発テクノロジーゾーン（mixi、Google、Shibuya）とかマーケティングゾーン（棚橋さん）とかにも関わりつつ、結局、自分も講演しつつ。 一番うれしかったのはNTTデータの橋爪さんに「Shibuyaイベント面白かった！」と言っていただいたこと。 Shibuyaの皆こそ、一番テクノロジーに対してピュアに向き合っているし、すごく運用に気を使っているし、お金ことも身近に感じているわけです。エンジニアとしてクリエイティビティにもっと
FireFoxでのPHP開発を手助けする「FirePHP」:phpspot開発日誌
FirePHP - Firefox Extension for PHP Development FirePHP allows you to take a deeper look at all the work your PHP code does to generate that page you are currently looking at in your Firefox browser. FireFoxでのPHP開発を手助けする「FirePHP」。 FireFoxのエクステンションとして動作し、FireBugの機能拡張をしてくれます。 インストールするとFireBug内に次のタブが表示されます。 サーバヘッダーで特定の文字列を返すとFireBug内、FirePHPウィンドウにその文字列が表示できます。 特定ヘッダーを出力するために、「FirePHP PEAR Package」が使え
[ThinkIT] 第5回：複数人での開発におけるテストの勘所 (1/3)
これまで解説してきたように、ウノウでは各々の開発者の開発環境で慎重に組み上げられたソースコードをSubversionで管理された統一の開発環境にそれぞれコミットし、リリースに向けて足並みを揃えながらシステムテストを実施します。 ウノウではテスト専門の担当者が在籍しており、開発者とは違った視点から成果物のチェックを行う体制を整えています。今回はその実践事例を紹介しながら、複数人での開発におけるテストの勘所について解説していきます。 テスト工程はプロダクトの品質を確保するために欠かせないフローの1つです。組み上げられたばかりのソースコードは、まだ完成度が客観的に保証されていない状態であり、開発者のスキルに対する信頼によってのみ「完成した」と推測されるものでしかありません。極端にいえば、いざ蓋を開けてみたら動かなかったということもあり得るのです。 自社プロダクトの開発がほとんどであれば、問題が発
開発標準を導入ために必要な6つの手順 ― ＠IT情報マネジメント
今回はより具体的な開発標準の導入の進め方について説明します。いくつかの手順を提示し、それを順番に解説していきます。 今回はより具体的な開発標準の導入の進め方について説明します。 一口に開発標準の導入といってもさまざまな形態があると思いますが、前回「開発標準を導入、トップダウンかボトムアップか」で説明したアプローチのうち、トップダウン的なアプローチの場合は、おおむね以下のような流れになると思います（下記の作業は必ずしもこの順序ではなく、また並行して行われることもあります）。 開発標準導入計画作成 開発標準策定 導入準備 試行と評価 展開と改善 次のステップへ 以下、それぞれの作業の概要とポイントを説明します。 1. 開発標準導入計画作成 ここでの主な作業は、以下のようなものになります。 開発標準の導入によるゴールを明らかにする 現状を知る（強み、弱み）?「AsIs」 どのような開発標準が「本
オブジェクト倶楽部クリスマスの資料：An Agile Way：オルタナティブ・ブログ
資料公開はじめました！ぼくの資料は、あの時、書画カメラに向かってフリーハンドで描いた絵の「下書き」も含めました。前のブログで書きましたが、 ソフトウェア開発は壮大な伝言ゲームであり、ソフトウェアはビットの塊ではなく、コミュニケーションの塊で出来ている。そして、このコミュニケーション場を広帯域に保つこと、そして、その場に流す情報を、できるだけ誤解が少ないもの（すなわち、見えるもの、触れるもの）にしていく必要がある。さらに、このコミュニケーションは鎖状になっていることから、TOC的には「最も弱い部分」（契約を跨ぐ部分、場所を跨ぐ部分）を厚くすることが必要で、厚くする方法は、そこにWin-Winを持ち込む、対面で話す環境を作る、などがあり、マズロー的なキラーソリューションとして、「一緒に食事をする」ということをお勧めしました。そして、もう１つの方法はこの鎖を「わっか」にして繋いでしまい、そこに要
最速インターフェース研究会 :: ライブドアのテクノロジーセミナーでしゃべってきました
昨晩はライブドアで開催されたテクノロジーセミナーで「Technologies for UI」という題でプレゼンをやりました。 発表資料はpdfかhtmlで公開する予定ですが、とりあえずテキストだけ先にアップしておきます。 http://ma.la/files/livedoor/seminar2006/seminar.txt プレゼンツールがFirefox専用だったりするので、これも少し手直しして公開予定です。 こういう機会があるたびにプレゼンツールを作ってるような気がします。 ---- 追記:12/15 ライブドアのtechblogの方に発表資料をアップしました。 http://blog.livedoor.jp/techblog/paper/ldtech2006/ 上下カーソルキーでページをめくれます。
第8回 デザイナーとともにより良いサイトを目指そう 〜「はてな」のやり方：ITpro
連載第5回（「デザインのセンス，持ってますか？」）においてちょっと触れましたが，ウェブサイトを構築する際に，デザイナーとエンジニア（プログラマ）がかかわり，共同で作業を行うケースというのは少なくないと思います。これはもちろん，デザイナーとエンジニアがどちらもそれぞれ別のスキルを持っているからなのですが，それぞれのスキルや立場が異なるために，お互いにうまく意思疎通ができないケースも多いんじゃないかと思っています。 例えば，デザイナーの作成したウェブページのデザインが，システムを作る側からすると扱いづらい構成になっていたり，逆にエンジニアがシステムの修正や機能追加を行った際に行った表示上の変更が，デザイナーからすると許せないものだったり。そうでなくてもデザイナーの意図を読みきれていなかったり，といった感じで，お互いの作業が，相手の作業を阻害してしまったり，手戻りを発生させてしまうといった経験を
Sustainable Software - 継続可能なソフトウェア：An Agile Way：オルタナティブ・ブログ
継続可能なソフトウェア(sustainable software) というキーワードで、現在のソフトウェアを取り巻く技術や考え方を統合したいと思っています。以下に、メモ。 何がソフトウェアの品質の中心となるか。 ・保守性(EoM)＝テスト可能性(EoT)＋変更容易性(EoC) http://blogs.itmedia.co.jp/hiranabe/2005/08/post_353b.html このための技術がオブジェクト指向（部品再利用やコード再利用ではない）、という位置づけ。テストしやすい設計、リファクタリングしやすい設計にすること。そのために、言語要素として継承・カプセル化・ポリモフィズムを使う。さらに原則として、DMP(問題領域概念とのダイレクトマッピング）、SRP（問題領域の変更を閉じ込める）などを使う。また、シンプルで愚直な設計をよしとする。 また、プロセスとしてはアジャイルなも
ウノウラボ Unoh Labs: VMwareとCentOSでウェブ開発の環境をさっさと整える手順書(前編)
最近オイルヒーター，ガスファンヒーター，石油ファンヒーターのどれを買おうか悩みつつPHPのフレームワークはSymfonyにかなり転がりそうなjokagiです． 私が遅いので気を遣ってkomagataさんが先に書いてくださいました． ナイスフォローありがとうございます． さて今回は，先日参加した開発合宿をはじめ最近何度かLinux環境を用意する必要性が連続したので，その辺りの作業を手短にする手順を紹介します． 慣れれば最低限の環境は10分程度，全部で30分あれば十分ウェブ開発に必要な環境を用意できるようになります． とりあえずLinuxはCentOSでバージョン4.4用にServerCDというのがあるので，それとVMware Serverを使います． まずVMware ServerのインストールとCentOSのisoイメージを下記リンクあたりからダウンロードしてください． VMware Se
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ！ ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが（幸運にも！）教えてくれても、それが議事録に書かれることはなかった。 受けたプ
WEB開発者のためのWEB開発ツール:phpspot開発日誌
Brennan’s Blog Blog Archive Web Development Tools for the Power Developer Over the past few years the available tools for web development have become quite powerful. As Firefox became more popular the number of useful extensions grew quickly. WEB開発者のためのWEB開発ツール、ということで色々紹介されてます。 バリデータ(Validator) - フォーマットが正しいかチェックするツール HTML/XHTML Validator - W3C CSS Validator - W3C Feed Validator (RSS and Atom) Jav
naoyaのはてなダイアリー - カンファレンスの資料 - はてなと私と開発環境
UP しときました。時間が15分だったので、ちょっとあっさりめの内容ではありますが。 http://bloghackers.net/~naoya/pdf/060909devcon.pdf 個人的にはここ最近のカンファレンスの中では一番面白かったかなと思いました。いろいろ役に立つ話とか、自分もやってみようみたいな話がいろいろ聞けたのが大きかったのかも。 2回目はどうだろう、だいたい話す内容が被りそうなので難しいかもね(笑) あ、そうだ。昨日の感想とかいろいろ読みたいので blog に書いた人は Shibuya.js のページなりこのエントリなりにトラックバックしていただけると大変嬉しいです。読んだやつは http://b.hatena.ne.jp/naoya/decon/ あたりに。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
naoyaのはてなダイアリー - ライブドアのテクノロジーセミナーでしゃべってきました。
Development Environment Conference - 青木日記/T(2006-09-09)