タグ

designに関するSprewellのブックマーク (10)

  • DB設計時のサイズ見積もり - よねのはてな

    ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ

    DB設計時のサイズ見積もり - よねのはてな
  • MethodOLogie.com is for sale | HugeDomains

    Make 12 monthly payments Pay 0% interest Start using the domain today. See details

    MethodOLogie.com is for sale | HugeDomains
  • 複雑さに金が落ちる時代は本当に終わるのか? - アンカテ

    RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース

    複雑さに金が落ちる時代は本当に終わるのか? - アンカテ
  • 6月のはぶにっき

    not found

  • [結] 2006年6月 - 結城浩の日記:モノクロ画像がカラーに見える錯視

    目次 2006年6月25日 - 長男と完全数談義 / 2006年6月23日 - ティナからの手紙 / 2006年6月20日 - 無神論者との対話 / 2006年6月18日 - 父の日 / 2006年6月16日 - ソフトウェアは、私たちの想像よりもずっと複雑 / 2006年6月14日 - 仕事 / 2006年6月13日 - 無限羽の鳩と無限個の巣 / 仕事 / Haskell / 読書 / 2006年6月12日 - 仕事 / 2006年6月10日 - モノクロ画像がカラーに見える錯視 / 日記ダイジェストを更新 / 2006年6月8日 - www.textfile.orgのお引っ越し / 2006年6月5日 - 仕事 / 2006年6月4日 - 今日の一日 / 2006年6月3日 - 誤植 / 2006年6月1日 - 仕事 / ぜひ、感想をお送りください 日記一覧 2006年6月25日 ■

  • お部屋晒し.com2

    ここは2ちゃんねるの家具板のお部屋晒しスレのまとめサイトです。その性質上あまり多くの方に目に付く事を嫌がる方もいますので、リンクを張る際は管理人宛にコメントを付けてからにして下さい。 過去スレ集 お部屋をうpするスレ13 お部屋をうpするスレ7(10) お部屋をうpするスレ9 お部屋をうpするスレ8 お部屋をうpするスレ7 お部屋をうpするスレ5(6) お部屋をうpするスレ5 お部屋をうpするスレ4 お部屋をうpするスレ3 お部屋の写真をうp19 家具レイアウター

    お部屋晒し.com2
  • 満足せる豚。眠たげなポチ。:決まらない仕様には「仕様の仕様」を出そう。(あるいは要件と仕様と設計の話)

    「設計者の発言」さんの「ユーザがなかなか仕様を決めてくれないって?」をとても興味深く読みました。 「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。(略)問題はどちらかといえば設計者の側にある。 で始まるこのエントリでは、設計者がユーザの反応を見ながら提案内容をどんどん修正し最終案としてまとめるという、「インタラクティブなやりとり」が必要という主張がされています。 ただ、この話は仕様決めと要件定義をごちゃまぜにしている部分があるように思います。たしかに実際に作業を進める上では、この二つがフェーズとして重なることもよくあります。ただ、少なくともエンジニアの頭の中では明確に切り分ける必要があると思っています。 そして、このエントリで言われる「インタラクティブなやりとり」が必要になるのはどちらかというと要件定義の時です。ユーザの目的に沿ったシステムをイメージしてもらうため

  • Willustrator: Web上で使えるドローツールをベータテスト公開 - かんばらにっき

    最近WillustratorというWeb上で使えるドローツールを作っています。 追記: 現在はhttp://willustrator.org/ で最新のWillustratorを公開しています。 http://wi.sappari.org/ まだ簡単なものですがなんとなく動くようになったのでベータテストとして公開してみました。BlogやWiki用にちょっとした図を描いたりするといった使い方を想定してます。 簡単な使い方 描いた絵はPNGとSVGに変換されます コピー機能をうまく使うとちょっと面白いかもしれない 今のとこ描けるのは丸と線(矢印)と文字だけです。使える色も3色程度です。 久恒啓一氏によると「丸と矢印があればたいていの図は描ける」ということだそうで、まずはそれだけを素早くできるようにしてみました。 メモ感覚で図を描けるように、普通のドローツールとは違う「ツール切り替えを使わないU

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク

    IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は,HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても,ドキュメントよりは実際の画面で確認した方が分かりやすいので,手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ!ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
  • PHPで角丸枠(CSS)を簡単に作る方法:phpspot開発日誌

    PhpMyBorder PhpMyBorderを使えば簡単に角丸の枠を作ることが可能。 CSSで角丸を実現するのはやや面倒だったりしますが、このツールがあれば容易に実現できますね。 角丸用の画像を用意する必要もありません。 枠線、背景色の設定もWEB上で簡単にできます。

  • 1