タグ

developmentに関するfanglangのブックマーク (36)

  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • 矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH(クロステック)

    今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoFでは、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景(問題)があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML(Unified Modeling Language、ユーエムエル)と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連

    矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH(クロステック)
  • ソーシャル化するOSS開発者たち - @IT

    ロング・テール理論の名付け親で、雑誌「Wired」の編集長としても知られるクリス・アンダーソン氏が3月12日付けのブログでオープンソースソフトウェア(OSS)プロジェクトの運営体制に関する誤解を指摘をしている。 アンダーソン氏によれば、多くの人はオープンソースプロジェクトというのは草の根から立ち上がり、自律的に組織化し、民主的に運営されているという誤った認識を持っている。ところが現実はまったく逆で、1人か2人の「慈悲深い独裁者」によって運営されている、という。 これはオープンソースプロジェクトに参加していたり、あるいは日常的に成果物を利用している人であれば、そういうものだと首肯するかもしない。メーリングリストで客観データに基づいて議論したり、リーダーを民主的に選ぶようなプロジェクトもあるかもしれないが、おおかたのオープンソースプロジェクトには、それを開始し、中心に位置し続ける“独裁者”がい

  • 広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)

    少し前からだけど,Cookpadやはてなが広告システムエンジニアを募集している. クックパッド|採用情報: 【技術部】アドシステムエンジニア http://info.cookpad.com/?page_id=113 求人情報:広告システムエンジニア - はてな http://www.hatena.ne.jp/company/staff/accountengineer 私個人の経験から,オンライン広告システムというのは検索やインフラ系と並び,インターネット系のシステムの中でもっともエキサイティングな分野の一つだと思っている.それにもかかわらず,狙って応募してくる人はあまりおらず,いつもいつも悔しい思いをしてきていたので,広告システムがいかにおもしろいかをちょっと述べてみたいと思う. その会社で一番アクセスを受けるところなのでおもしろい. 広告システムはそのサイトの全サービス上に配信する必要が

    広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)
  • Ruby on Railsの作者より:高まった生産性を仕事を余計にこなすためではなく自分の将来に向けて使おう - himazu blog

    IT ConversationsでRuby on Railsの作者デービッド・ハンソンが2008年5月にRailsConfでおこなった講演が配信されている。そして、以下でも聞ける。 RoRの思想についての言及が冒頭にあるが、大部分は開発者の身の処し方についての講演である。その部分の概要は以下の通りである。 RoRは他のフレームワークや開発手法に比べて生産性について依然として優位性があり、RoRを使って開発していると「余剰開発力」を享受できる。しかし、その状態は永遠には続かない。遅かれ早かれ以下のどれかが起こるから。 他の言語/フレームワークがRoRを凌駕する RoRを凌駕する新たなフレームワークが登場する RoRがメインストリームになる 幸い、どれもすぐには起こりそうになく、RoRでの開発はまだしばらく生産性の点で有利である。その優位性によって生ずる余剰開発力をいかに活用すべきだろうか。も

  • [okyuu.com] ソーシャルITメディア

    okyuu.comは、世界規模のノウハウデータベース構築を目指すエンジニア向けコミュニティです。マイミク認証対応のRP作ってみませんか? 特集:いますぐ使えるOpenID|gihyo.jp … 技術評論社の内容に加えて SSL 接続でのサーバ証明書の検証,mixi のマイミク認証についても解説されている。

  • プログラミングファースト開発 - ひがやすを技術ブログ

    プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

    プログラミングファースト開発 - ひがやすを技術ブログ
  • Selenium ver.0.5 勝手にまとめサイト

    86400000 > selenium > Sort by: Update Auto() Image hover

  • memokami :: 第2回モバイル勉強会で「キャリア判別と絵文字の扱い」を発表してきました

    第2回モバイル勉強会を開催しました。 今回はモバイルに情熱を持ったスピーカー12名の方々にご賛同いただき、 密度の濃いモバイルの勉強会を開催することが出来ました。 当に皆様のおかげで、このような素晴らしい会を開催することが出来ました。 ありがとうございました。 また祝日の上、大人数にも関わらず、快く会場を貸してくださった上に 朝早くから会場設置までしてくださったECナビさん、当にありがとうございました。 私も1スピーカーとして発表してまいりましたので、 その資料をあげておきます。 「キャリア判別と絵文字の扱い」 さてそんな第2回モバイル勉強会のご報告です。 ■スピーカーセッション ★モバイル前世紀 小飼 弾 さん 資料:モバイル前世紀 動画:モバイル前世紀 プレゼンテーションは携帯のみ! 参加者各自で携帯を触りながらのプレゼンは斬新でした。 某ライブ○アの頃の携帯サイトを作ったときに話

    memokami :: 第2回モバイル勉強会で「キャリア判別と絵文字の扱い」を発表してきました
  • ウノウラボ Unoh Labs: ベンチャー流Webサービスの作り方(開発チーム編)

    尾藤正人(a.k.a BTO)です 前回はWebサービスを作るときの企画の部分について書きました (ベンチャー流Webサービスの作り方(企画編))。 今回はWebサービスを作るときの組織作りについて書いてみたいと思います。 僕がウノウに入って始めたのがフォト蔵の開発でした。 当初は開発が僕、ディレクションが代表の山田という二人体制でやってましたが、 組織が大きくなるにつれてだんだんと人数が増えていきました。 現在は僕も山田もフォト蔵からは離れて新しいチームで開発を行っています。 二人体制から始めて、少しずつ人数を増やしていって、 立ち上げメンバーが開発から離れるまでいろいろ経験しながら 自分が感じた事を簡単にまとめたいと思います。 ・最終決断は一人で 何をするのか、戦略はどうするのか、方向性は何なのか、最終的な決断はリーダーが一人で行います。 個人の主張を尊重しすぎて、各々が好きな事を始め

    fanglang
    fanglang 2007/08/11
    決断は一人で行うもの
  • オープンソースコミュニティ運営方法:Geekなぺーじ

    Google Videoに「 How Open Source Projects Survive Poisonous People (And You Can Too)」という54分のビデオがありました。 Subversionの開発者達が、オープンソースプロジェクトを運営上の注意点を解説していました。 面白かったです。 ボランティア開発者の集合体によって実現しているオープンソースプロジェクトを運営する方法を解説するという題目ですが、 最後のオチでは、「これはオープンソースに限らない」と言っていました。 確かに、一般的な開発でも参考になる部分は多いと思いました。 また、掲示板やブログのコメント欄でも一部は適用できそうなノウハウであると思いました。 要約してみましたが、結構いい加減で間違いなどがあると思うので詳細はビデオをご覧下さい。 「Poisonous People」は「有害な人」と訳してみま

    fanglang
    fanglang 2007/05/31
    いい記事!!
  • AJAXでやってしまう間違い:Geekなぺーじ

    「Ajax Mistakes」という面白い記事がありました。 AJAXを使ってWebアプリを作る時に陥りがちな間違いを列挙していました。 以下、要約してみました。 かなり削っているので、詳細は原文をご覧下さい。 AJAXを使うためにAJAXを使う AJAXはカッコイイ技術です。 しかし、AJAXはツールでしかありません。 AJAXはオモチャではありません。 実験的にAJAXを使うために、不必要なところにAJAXを無理矢理使っている場合が多いです。 戻るボタンの動作を妨げる 戻るボタンはWebインターフェースで重要な役割を果たしていますが、JavaScriptとの相性は良くありません。 戻るボタンの機能を維持できない場合があることは、JavaScriptのみで構成されているページをお勧めしない理由の一つです。 ただ、使い勝手の良いサイトというものは、そもそも戻るボタンに依存しなくてもユーザが

    fanglang
    fanglang 2007/03/10
    気をつけよう
  • 37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」:Goodpic

    This shop will be powered by Are you the store owner? Log in here

  • 薄型テレビを制したLinux,開発現場の“守護霊”と“中央線”:ITpro

    シャープのAQUOSに搭載されているLinuxのソースコードをダウンロードできる<a href="http://www.sharp.co.jp/support/aquos/source/download/fileset_001.html" target="_blank">ページ</a> デジタル家電へのLinuxの採用が拡大している。シャープのAQUOS,松下のVIERA,ソニーのBRAVIA,東芝のREGZA,日立のWoo---日の主要メーカーの薄型テレビのブランドのほとんどがLinuxを採用。携帯電話でも,NECパナソニックモバイルのFOMA対応機種は現在全面的にLinuxを搭載している。薄型テレビで年間数百万台,携帯電話でも千万台のオーダーでLinuxを載せた機器が出荷されていることになる(関連記事1,関連記事2)。 オープンソースがこれら組み込み機器で当たり前になってきたことで

    薄型テレビを制したLinux,開発現場の“守護霊”と“中央線”:ITpro
  • グーグルが無敵ではないことはエンジニアだけが知っている:江島健太郎 / Kenn's Clairvoyance - CNET Japan

    ウェブ人間論 梅田 望夫 / 平野 啓一郎 梅田望夫と平野啓一郎の対談集である「ウェブ人間論」を読了した。基的な感想は、この書籍の元になった新潮に対談が掲載されたときに「新潮6月号の梅田望夫×平野啓一郎の対談を読んで」にもすでに書いたし、ここやここでは平野啓一郎人が登場するというハプニングがあったことも記憶に新しいところだ。その後に平野はほんとうに公式ブログを開設したりもした。これら一連のできごとは、とても楽しいものだった。 だけど、いやだからこそ、この件を引っ張る形でこれ以上書評を続けると知人友人ばかり持ち上げる内輪やらせブロガー的なダークサイドに堕ちてしまう気がするので、この機会に大きく踏み外してみようと思う。 ぼくが今の今まで注意深く避けてきた、グーグル技術論について、この機会にとうとう語ってしまおうと思う。 ■「過去7年におけるグーグル成功の最大の要素は『運』だった」(Se

    fanglang
    fanglang 2006/12/20
    口先だけじゃない人間になろう
  • Clouder::Blogger: riyaのように顔認識をするためのライブラリ

    ご存知の方も多いと思いますが、riyaというサービスではアップロードした写真の中に顔があるとそれを認識して視覚化したり、物があるとそれを認識してその物に似た商品(場合によってはそのもの)をみつけてくれるという機能があります。一見すごい技術に見えるのですが、実はあるライブラリを使えばこれを簡単に実現することができます。 事の発端は単純に自分が顔認識をやってみたいと思ったからで、そのためのライブラリやソフトウェアがないのかなぁとネットをさまよっていたらこのライブラリに行き着いたというわけです。 そのライブラリは「opencv」といいます。 このopencvは、Intelが開発を行っているものでSourceforgeにてプロジェクトが進められています。このopencvというのは、別に顔認識に特化したライブラリではなく、「OpenCV (Open Source Computer Vision) i

  • 人月見積もりでは生産性は上がらない、IPAが警告 ― @IT

    2006/11/29 情報処理推進機構(IPA)は11月29日、2006年度「情報処理産業経営実態調査」の結果を発表した。この調査は「情報処理産業界の財務、経営状況の現状を把握し、今後の経営の参考に供する」(IPA)ことが目的で、1978年以降毎年実施されている。28回目となる今年は従来のアンケート調査に加えてヒアリングも実施し、労働生産性の分析などを行った点が特徴だという。アンケートでは861社から有効な回答が得られた。ヒアリングは25社に対して行った。 2005年度の情報処理産業全体の売上高は0.8%の増加で、伸び率は鈍っているものの2003年度から連続でプラス成長している。経常利益も22.6%の増加で、増収増益となった。ヒアリングの結果でも、経営状況は昨年と比べ良好であるという意見が多く聞かれたという。 生産性に関しては、ソフトウェア業界において、ソフトウェアプロダクト販売分野の売上

    fanglang
    fanglang 2006/12/03
    今更の話だけど、それに代わる方法がないんだよねぇ
  • 情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方

    「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す

    情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
  • いいアジャイルと悪いアジャイル

    スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見

  • ksh Days - デスマーチについて考える(デスマーチ経験のエピローグ)

    このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低1箇所は触ってみる。(でよく落ちる) バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら

    ksh Days - デスマーチについて考える(デスマーチ経験のエピローグ)