タグ

Webと設計に関するatm_09_tdのブックマーク (5)

  • Webサイトマップをビジュアル化して見積もりを計算できる・「Octopus.do」

    Octopus.doはWebサイトのサイトマップをビジュアル化して見積もりを計算、シェアできる見積もり計算アプリです。 ページごとに作成する項目を書き、工数を設定すると自動で計算してくれる、というもの。単位は時間となっており、通貨は円にも対応しています。なかなかユニークで便利なツールでした。 というわけで使用感です。 ざっくり使い方 概ね直感で使えると思います。作成予定のコンテンツや作業内容をページ毎に書き、かかる時間を設定します。(※右に0hとあるのは「Oh」ではなくて「0h(0時間)」です。) 各ページに工数を設定したら右上の$マークのボタンをクリックします。メニューが開くのでCurrencyをJapanese YENに設定し、税(TAX)を日の消費税率の数値に設定します。これで自動計算してくれるようになります。また、別途かかる費用がある場合は項目を追加できるようになっています。 作

    Webサイトマップをビジュアル化して見積もりを計算できる・「Octopus.do」
  • リソースの一部更新におけるURL設計 - Qiita

    概要 Webアプリケーションにて、リソースの一部更新を行う際、どのようにURL設計を行うとシンプルで美しいか(当はそこまで考えていなかったけど)悩んでいたところ、 @t_wada さんから素敵な設計指針をご教示いただきました。 記事はその内容に加えて、実際に自分で行ったこと、調べたこと、思った事など、まとめております。 あらすじ 数週間前にSIピラミッドからヒモなしバンジーを決めてWebの世界に飛び込んだ私は、小さな小さなWebアプリケーションをrails newから手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能をどう実装したもんかなーと悩んでました。以下、当時(といっても先週)の超雑なぼやき。 リンクをクリックしてモデルの一部を変更するのはどうしたらいいんだろう。 例)不参加をクリック -> 某カラムをtrueからfalseへ リクエストオブジェクトに対象カラムの

    リソースの一部更新におけるURL設計 - Qiita
  • 高速なWebサーバアプリケーションを構築するための6つの経験則 | POSTD

    この記事では、Webアプリケーション(特にバックエンド部分)を構築するときにハイレベルなパフォーマンスを達成しようとするなら考慮するべき、最も一般的な原則のいくつかを取り上げたいと思います。私は、自分自身の経験から、主にPHPの世界で使われるいくつかの例、設計パターン、慣例やツールについて書きますが、ここで説明する概念は、どんな言語やフレームワークにも必ず当てはまると思います。 手短に言うと、基ルールは次の6つです。 ルール1 . 時期尚早な最適化を回避する ルール2 . 最小限の作業で問題を解決する ルール3 . 今すぐやらなくてもいい作業は延期する ルール4 . 使えるときはキャッシュを使う ルール5 . リレーショナルデータベースのN+1問題を理解し、回避する ルール6 . 可能ならアプリケーションに水平スケーラビリティをもたせる ルール1: 時期尚早な最適化を回避する Donal

    高速なWebサーバアプリケーションを構築するための6つの経験則 | POSTD
  • Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト

    移転しました http://please-sleep.cou929.nu/20130121.html

    Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
  • Webエンジニアスキルの勘所

    Webのエンジニアにはどういうスキルが一番必要か?という話を考えてみた。 例えば、C言語やUnixの経験が長く、オブジェクト指向も理解していたとしたら、PHPから始まり、Rubyなどの理解は決して難しくないだろう。 では、それだけの経験で一線級のWebエンジニアとしての信頼が置けるかというと、ちょっと違うような気がする。 考え方のベースは、 「Webは、要するにテキスト処理であることが多い。だから難しい」 ほとんどの事がHTTPプロトコルを通じてテキストデータとして情報が、なんのネットワークの制約もなく流通する。つまり、HTTPヘッダを含むテキストの操作でセキュリティホールを作り、それが世界のどこから攻撃されるかわからない。 また、 同様に世界中からアクセスが集まることがありうるので、回りくどいテーブル設計をしてしまうと、あっというまに破綻してしまうこともある。 そして、 基的にマルチア

  • 1