タグ

2008年5月3日のブックマーク (11件)

  • André Michelle Archive

    Good bye Flash! Thanks for 10 years of tinkering, fiddling, bothering and lots of fun. For sentimental purpose you can watch some of my old Flash experiments here.

    André Michelle Archive
  • ベンチャー企業の経営危機データベース(METI/経済産業省)

    多くのベンチャー企業が起業後に、同じような失敗、トラブル、ヒヤリとした経験をしており、成長に伸び悩む企業が多いと言われています。そこで、ベンチャー企業の経営者が様々な場面で決断を下す際の「転ばぬ先の杖」として、将来起こりうるリスクを予見できるような失敗、トラブル、ヒヤリとした経験の事例を収集・データベース化しました。ベンチャー企業の成長に向けた経営判断の材料としてご利用いただければ幸甚に存じます。 データベースには、平成19年度にベンチャー企業にインタビュー調査を実施して収集した83の失敗、トラブル、ヒヤリとした経験に関する事例を掲載しています。事例は、ベンチャー企業の成長ステージや失敗、トラブル、ヒヤリとした経験の原因及び結果といった分類項目をもとに検索が可能となっています。

  • フレームワーク選びの基準 - Sooey

    フレームワーク選びの基準 kunitさんのところから。 仕事でフレームワークを選定する場合は「個人の問題」ではないんです。「チームの問題」「会社の問題」になるんです。 なので、「なぜその仕事でそのフレームワークを選んでるんだ!」という問いは、個人ではなく、チームや会社に問わないといけないわけです。 なので、個人の好みの問題ではないんすよね・・・そのあたりどうもPHPでは個人の好みレベルの議論が多くてまだまだ成熟度がたらんなぁと。 業務で使うフレームワークを「開発方法論とセット」で捉えるべきというのは確かにその通りで、Seasarなんかはその視点を持っていますよね。 かつてのMVCな設計を提供するだけのシンプルなフレームワークだったら好みで選んでも構わない気がしますが、Rails以降のフレームワークは多かれ少なかれユニットテスト、デプロイ機構、データベースマイグレーション、ドキュメント生成と

  • Bash で HTTP リクエストを投げる - id:kazuhookuのメモ置き場

    shwget | gniibeの日記 | スラド あたりを見ながら遊んでいたわけですが。 % (echo GET / >&0 ; cat) < /dev/tcp/localhost/80あたりが最小形態ですかね。HTTP/0.9 を使ってボディだけ取る。 % (echo GET / >&0 ; cat) < /dev/tcp/localhost/80 | openssl md5トップページのチェックサム。

    Bash で HTTP リクエストを投げる - id:kazuhookuのメモ置き場
  • 構成管理 実践入門 第1章 構成管理入門 はじめに

    第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その1 リリース管理 リリース編その2 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか? Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス

  • InfoQ: 複数のアジャイルチームでのバージョン管理

    複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント(イテレーション)だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図(壁張り用) この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ

    InfoQ: 複数のアジャイルチームでのバージョン管理
  • 大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索

    ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が

    大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
  • WebKit の CSS の字句解析部分を JavaScript に移植しました - IT戦記

    これを JS に移植しました。 http://svn.webkit.org/repository/webkit/trunk/WebCore/css/tokenizer.flex ポイント それなりに汎用的な Flex みたいなものを作ったので、その部分は CSS 以外にも使えると思います。 あと、定義を文字列で書かずに正規表現オブジェクトで書くのでバックスラッシュをエスケープせずに書けます。ですので、ほとんどの箇所は WebKit の tokenizer の定義をコピーするだけで済みました。 その辺のアイデアは JavaScript で構文解析: Days on the Moon を参考にしました あと http://svn.coderepos.org/share/lang/actionscript/ascss/src/css/CSSLexer.as id:gyuque さんの ASCSS

    WebKit の CSS の字句解析部分を JavaScript に移植しました - IT戦記
  • 1分間で学ぶ、ウェブサイトのユーザビリティ | コリス

    Interactive Marketing Blogから、1分間で学ぶウェブサイトのユーザビリティを紹介します。 One Minute Guide to Usability 下記は、1分間で学ぶウェブサイトのユーザビリティの意訳です。 Who are you? 何者ですか? 例:ロゴ、ブランディング Are you trustworthy? 信頼できますか? 例:ベリサイン・Trust-e、信頼できるデザイン、サポート What do you do? 何をしているのですか? 例:取り扱っている商品・サービス、会社紹介 Where to next? 次に、何をするべきですか? 例:見積請求、営業担当へ電話 Exit Panic: Where do I go now? パニック:私はどのページをみればいいですか? 例:ヘルプ、ログイン、コンタクト・インフォーメーション

  • asahi.com:カード番号だけでネット決済「不正防げぬ」 地裁判決 - 社会

    akkun_choi
    akkun_choi 2008/05/03
    いわばIDだけで認証するようなものだよな。なんでこの方法が当たり前のようになってるのかが不思議
  • プログラミングファースト開発 - ひがやすを技術ブログ

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

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