2008年8月アーカイブ

コード ステータス HTTPバージョン
意味
1xx Informational 情報 -
100 Continue 継続 1.1
クライアントは、そのリクエストを継続してもよい。
101 Switching Protocols プロトコル切替え 1.1
サーバは、この接続で使用されているアプリケーション・プロトコルの変更に対するクライアントのリクエストに応じようとしている。
2xx Success 成功 -
200 OK OK 1.0
リクエストは成功した。レスポンスと共に返される情報は、リクエストで使用されたメソッドに依存し、例えば、GET、HEAD、POST、TRACEのようになる。
201 Created 生成 1.0
リクエストは果たされ、結果として新しいリソースが生成された。
202 Accepted 受理 1.0
リクエストは処理用に受け入れられたが、処理は完了していない。CGIのように別の場所でデータを生成する時など。
203 Non-Authoritative Information 非認定情報 1.1
エンティティ・ヘッダーで返されたメタ情報は、オリジナル・サーバから入手できる確定的な集合ではなく、ローカルあるいはサード・パーティーのコピーから集められたものである。
204 No Content コンテンツなし 1.0
サーバはリクエストを果たしたが、送り返すべき情報が存在しない。空のページにアクセスしようとした時など。
205 Reset Content コンテンツリセット 1.1
サーバはリクエストを果たしたが、ユーザ・エージェントは、リクエストを送信させたドキュメント・ビューをリセットするべきである。
206 Partial Content 部分的コンテンツ 1.1
サーバは、リソースに対する部分的なGETリクエストを果たした。
3xx Redirection リダイレクション -
300 Multiple Choices 多重選択 1.1
リ クエストされたリソースは、それぞれが固有のロケーションをもつ表現セットの一つに対応し、ユーザ(あるいはユーザ・エージェント)が、より望ましい表現
を選別してそのリクエストをそのロケーションにリダイレクトできるように、エージェント駆動型ネゴシエーション情報が提供されている。
301 Moved Permanently 恒久的移動 1.0
リクエストされたリソースは新しい恒久的なURIを割り当てられたので、このリソースへの今後の参照は、返されたURIの一つを使用するべきである。
302 Moved Temporarily 一次的移動 1.0
リクエストされたリソースは、一時的に異なるURIに属する。
303 See Other 他を参照 1.1
リクエストに対するレスポンスは異なるURIの下で発見でき、そのリソースをGETメソッドを使って検索することが望ましい。
304 Not Modified 変更なし 1.0
リクエストされたリソースが指定された日付以降に更新されていない。クライアントが条件付きGETリクエストを実行し、アクセスは許可されたが、ドキュメントが更新されていない場合には、サーバはこのステータス・コードでレスポンスを行なうべきである。
305 Use Proxy プロキシーを使用 1.1
リクエストされたリソースは、ロケーション・フィールドによって与えられるプロキシを通じてアクセスされなければならない。
4xx Client Error クライアント・エラー -
400 Bad Request 不正リクエスト 1.0
リクエストは不正な構文であるために、サーバに理解されなかった。打ち込んだURLに変な間違いがあった時など。
401 Unauthorized 許可なし 1.0
リクエストは、ユーザ認証を必要とする。認証に失敗した時など。
402 Payment Required 支払いリクエスト 1.1
(このコードは,将来の使用のために予約されている。)
403 Forbidden アクセス拒否 1.0
サーバはリクエストを理解したが、そのリクエストの実行を拒否した。アクセス権限がない時など。
404 Not Found 存在不明 1.0
サーバは、リクエストURIと一致するものを見つけられなかった。アドレスが無くなった時など。
405 Method Not Allowed 禁止メソッド 1.1
リクエスト・ラインで指定されたメソッドは許されていない。
406 Not Acceptable 受理不可 1.1
リクエストによって識別されるリソースは、リクエスト中に送信された受理ヘッダに従って、受理できない内容特性をもつレスポンス実体を生成することができるのみである。 受信の条件が適合していないため、リクエストされるリソースは受理できない。
407 Proxy Authentication Required プロクシー認証リクエスト 1.1
このコードは401(Unauthorized)と似ているが、クライアントは最初にプロキシに対する認証を行なわなければならないことを示している。
408 Request Time-out タイムアウト 1.1
クライアントは、サーバの待機時間内にリクエストを発行しなかった。
409 Conflict 衝突 1.1
リクエストは、リソースの現在の状態と衝突するために完了できなかった。
410 Gone 行方不明無い 1.1
リクエストされたリソースは、もはやそのサーバでは入手できなくなっており、転送先のアドレスも不明である。
411 Length Required 長さ要求 1.1
サーバは、定義された Content-Lengthのないリクエストの受理を拒否した。
412 Precondition Failed 前提条件失敗 1.1
一つ以上のリクエスト・ヘッダ・フィールドで与えられた前提条件が、サーバでテストされたときに偽(不正)であると評価された。
413 Request Entity Too Large リクエスト実体が大きすぎ 1.1
リクエスト実体がサーバの想定よりも、あるいは処理可能なものよりも大きいため、想定処理を拒否している。
414 Request-URI Too Large リクエストURIが大きすぎ 1.1
リクエストURIがサーバの想定よりも、あるいは処理可能なものよりも大きいため、サーバはサービスを拒否している。
415 Unsupported Media Type 非サポート・メディア・タイプ 1.1
リクエスト実体は、リクエストされたメソッドに対してリクエストされたリソースがサポートしていないフォーマットであるため、サーバがリクエストのサービスを拒否している。
5xx Server Error サーバ・エラー -
500 Internal Server Error サーバ内部エラー 1.0
サーバは、リクエストの実行を妨げる予期しない状況に遭遇した。 CGIスクリプト・エラーなど。
501 Not Implemented 未実装 1.0
サーバは、リクエストを実行するために必要な機能をサポートしていない。
502 Bad Gateway 不正ゲートウェイ 1.0
ゲートウェイあるいはプロキシとして動作しているサーバが、リクエストを実行しようとしてアクセスした上位サーバから不正なレスポンスを受信した。 不正なゲートウェイ経由のアクセスなど。
503 Service Unavailable サービス利用不可 1.0
サーバはサーバの一時的な過負荷あるいはメインテナンスのために、現在、リクエストを扱うことができない
504 Gateway Time-out ゲートウェイ・タイムアウト 1.1
ゲートウェイあるいはプロキシとして動作しているサーバが、リクエストを完了しようとしてアクセスした上位サーバからタイムリーなレスポンスを受信できなかった。
505 HTTP Version not supported 非サポートHTTPバージョン 1.1
サーバは、リクエスト・メッセージで使用されたHTTPプロトコル・バージョンをサポートしていない、あるいはサポートを拒否している。

(PHP 3, PHP 4, PHP 5)

error_reporting -- 出力する PHP エラーの種類を設定する

説明

int error_reporting ( [int level] )

error_reporting() 関数は、 error_reporting ディレクティブを 実行時に設定します。PHP には多くのエラーレベルがあり、 この関数によりスクリプトの持続時間(実行時間)のレベルが設定されます。

パラメータ

level

新しい error_reporting レベル。ビットマスクまたは名前つき定数のどちらかです。将来の バージョンとの互換性を保証するために、名前つき定数の使用が 強く推奨されています。エラーレベルが追加されると、整数の幅は増加します。 そのため、以前の整数を使用するエラーレベルは常に期待通りに動作するとは 限りません。

利用可能なエラーレベル定数の一覧を以下に示します。 これらのエラーの実際の意味は、 定義済みの定数に 記述されています。

表 1. error_reporting() レベル定数とビット値

定数
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
2047 E_ALL
2048 E_STRICT

返り値

変更前の error_reporting レベルを返します。

例 1. error_reporting() の例

<?php

// 全てのエラー出力をオフにする
error_reporting(0);

// 単純な実行時エラーを表示する
error_reporting(E_ERROR | E_WARNING | E_PARSE);

// E_NOTICE を表示させるのもおすすめ(初期化されていない
// 変数、変数名のスペルミスなど…)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);

// E_NOTICE 以外の全てのエラーを表示する
// これは php.ini で設定されているデフォルト値
error_reporting(E_ALL ^ E_NOTICE);

// 全ての PHP エラーを表示する(ビット 63 は PHP 3 で利用される)
error_reporting(E_ALL);

// error_reporting(E_ALL); と同じ
ini_set('error_reporting', E_ALL);

?>

注意

警告

PHP > 5.0.0 では、値 2048 を有する E_STRICT が利用可能です。E_ALL には、エラーレベル E_STRICT は含まれません。 ほとんどの E_STRICT レベルのエラーはスクリプトの コンパイル時に発生します。そのため、 error_reportingE_STRICT を含むように設定されている環境では これらのエラーを検出できません。

Yahoo!検索のウェブ検索ヘルプページにある「関連検索ワード」の説明について、新しい注意事項が追記されています。
本機能(関連検索ワード)を、SEOやいやがらせ等の目的で利用する行為は禁止しています。そのような行為を発見した際には、なんらかの措置をとる場合があります。[「関連検索ワード」とは, Yahoo!検索ヘルプ]
MSN / Live Searchのキャッシュで確認する限り、少なくとも2008年7月時点で上記記載はありませんでした。おそらく先日リリースされた検索クエリを大量送信して特定ワードを表示させるサービスに対してYahoo!JAPANに問合せがあったのでしょう。機械的にクエリを発生させて表示するのは検索会社側にとって迷惑なのですから、禁止事項と明記

大企業が推進する「在宅勤務」、そのメリットとデメリットとは?

写真協力:NEC
(写 真左)Webカメラを使った会議や、部署内での予定共有といったシステムの活用により、自宅にいてもオフィスとの密なコミュニケーションが可能になる。 (写真右)シンクライアント端末「US110」を自宅に設置することで、オフィスにいるのと同じように社内サーバーにアクセスできる。

「在宅勤務」の4文字は満員電車のストレスに悩む社会人にとって特別な響きを持っているけど、近ごろ大企業を中心に、在宅勤務を含む「テレワーク」の普及が進んでいるって知ってます?

そもそもテレワークとは、IT設備の活用によって場所や時間にとらわれない柔軟な働き方を可能にする勤務形態のこと。少子化や高齢化による労働人口の減少が見込まれるなか、政府は2010年までにテレワーカー人口を就業者全体の2割にまで増やすことを目標にしている。

すでに、日本IBMや松下電器産業などが大規模な在宅勤務制度を導入しているほか、今年7月にはNECが社員の大部分となる約2万人(新入社員や生産現場勤務などを除く)を対象に在宅勤務を認めることを発表した。

しかし、在宅勤務の導入には各家庭にIT機器を設置する必要があるなど、コスト面の負担も大きいはず。それでもテレワークを推進する理由とは? NEC企業ソリューション企画本部の岩田真由美さんに聞いてみた。

「テ レワークの導入による企業側のメリットは、優秀な人材を確保できることです。経験やスキルのある社員が、育児や介護といった家庭の事情などで離職してしま うケースは多くありますが、在宅勤務などに柔軟に対応できれば、人材の流出を防ぎやすくなります。また将来的には、通勤にともなうCO2排出量の削減と いった、社会貢献的な意味合いも期待できますね」

でも、在宅勤務者が増えてくると、日常の業務に支障が出たりしません?

「も ちろん、すべての社員が全面的に在宅勤務をするのは不可能ですが、弊社では“在宅勤務は週1回”を原則としたうえで、PCを通じて内線電話を受けられるソ フトなどを利用し、どこにいてもオフィスと同等の環境で業務ができるシステムを採用しています。06年から一部のセクションで実施していたトライアル期間 の結果では、参加者の7割以上が在宅勤務によって『生産性が上がった』と評価しています」

実際にトライアルに参加していた男性社員に感想を聞くと、

「普通の出勤日よりも、在宅勤務日の方が気を抜けませんよ。いつ上司から電話があるかわからないし、普段どおりの成果を上げなければいけないプレッシャーも大きいです。その分、家族と接する時間が増えるのは本当に嬉しいですけどね」

との回答が。在宅勤務をうまく利用できるかどうかは、IT設備以上に利用者の“自律性”にかかっているのかも。
080730eomheader1.jpg


昨日、ブラッドさんが書いたメールはとてもシンプルなものでした。それは件名に「ブラッドは午前9時半にいます。よろしく。EOM」というもの。すぐに「EOMってどういう意味?」と返事が返ってきたそうで、それに対する答えは「End of message(メッセージの終わり)という意味さ。これならわざわざメールを開く必要も、返信する必要もなくなる。今 回はメールを開いて、返信をしてもらったから二度手間になったね」というもの。同僚たちには「面白い!」と、この話を冗談だと思ってオフィスのみんなに転 送したそうですが、ブラッドさんは、大真面目。「一度EOMのテクニックを覚えたら、メールにかける時間も手間も減ります。そのうえ、確実に、自分の伝え たいことが伝わり、時間も節約できますよ」とのこと。詳しい理由は次の8つ。


  1. EOMは、メール受信者の時間節約になります。
    件名のところだけに用件を入れ、EOMで終わりにすると、相手の時間を大切にしているよ、という思いやりが伝わります(相手がEOMの真の意味に気づけば、ですが)。

  2. 残りの7つの理由は以下からどうぞ。
     

  3. あなた自身の時間節約になります。
    書く必要のないような本文をだらだら書かなくてすみます。

  4. これが以前の書き方:

    080730email1.jpg

    これがEOMの書き方:

    080730email2.jpg


  5. 分かりやすい件名を書けるようになります。
    メールの受信で最もよく読まれるのが件名。EOMで件名だけで用件を済まそうとすると、必然的に、簡潔で分かりやすい内容を書けるようになります。
  6. EOMの件名は、簡単にコピペできます。
    日時、やるべきことなどが最小限の言葉で盛り込まれているので、これをコピペして、カレンダーなどに簡単に貼付けられます。今までやっていた、打ち直す手間が省けます。
  7. 例:
    "Let's meet in Conf. Room 223 RE: the Orange account at 3pm 8/21/08 EOM"
    (会議室223番でやろう。RE:2008年8月21日午後3時にオレンジアカウントにて。)

    ほら、簡潔でしょう?
    ミーティングの内容、日時、場所まで全部入っているで、これなら簡単にこの内容をカレンダーにそのままコピペできます。あなた自身にも、メールの受け手にも便利な方法ですよね。

  8. EOMをまわりの人も活用させると、さらにお得。
    まわりの人があなたの真似をしてEOMを始めれば、お互いの時間の節約になるし、正確なメールのやりとりができます。
  9. EOMなら、短いメールでおさまります。
    EOMは件名のみなので、話題が1つで収まります。みんなも受けたり書いたりしたことがある、数ページにわたる長いメールの必要がなくなるのです。さらに EOMをやることで「こんなに長いメールを打つなら10分会って話をしたり、電話をしたほうがよっぽど早く決まる」ということに気づきますよ。

  10. EOMを始めると、どの話題をメールでおこなうべきかがはっきり分かるようになります。これがその基準。
    ●件名のみでおさまる? 
    ●1段落のみでおさまる? 
    ●2段落ではおさまる? 

    この答えが「いいえ」なら、電話か直接会って話をするほうが効果的!

  11. EOMは1つの話題に特化したやりとりができます。
    EOMを使うと、1つの話題しかメールに入れられないですよね。ちなみに、1つのメールに1つの話題のみ載せる、というのがメールにおけるマナーです。
  12. 100%相手にメールを読んでもらえます。
    「大事なメールを読んでもらえない!」「返信してもらえない!」とフラストレーションを感じたことは、みんなあるはず。そんな時に限って、相手がまだメールを開いてもいなかったり…。EOMの最大の強みは、相手に100%の確率でメールを読んでもらえること。件名に入っていたら、読まないわけにはいかないですからね。

EOMという言葉自体は、日本語のメールでは使えないけれど、件名のみですませることは、時と場合によってできそうですね。また、メールは1つの話題にしぼって、短く的確に! というのはもっともな意見。日本では、まずメールを短く簡潔にすることから始めてみると、いいかもしれません。

iPhone用のアプリをキッカケにmixi日記にポストできるAPIが見つかったそうです。


mixi日記投稿用APIを使ってPHPからmixi日記にポスト ::: creazy photograph

プラス要因トップ20(Yahoo! JAPAN)

  1. titleタグ内でのキーワード使用
  2. 被リンクのアンカーテキスト
  3. サイト全体でのリンクポピュラリティ
  4. 本文でのキーワード使用
  5. Yahoo!ディレクトリへの登録
  6. サイト内部構造としてのリンクポピュラリティ
  7. リンク元サイトのサイト全体でのリンクポピュラリティ
  8. サイト開設からの経過時間
  9. 被リンクの話題関連性
  10. サイトの主要テーマと検索の関連性
  11. リンク元ページとの話題の関連性
  12. 被リンク増加率
  13. 本文のコンテンツとキーワードの(トピック分析による)関連性
  14. インデックス可能なテキストコンテンツの量
  15. h1タグ内でのキーワードの使用
  16. 話題コミュニティ内でのリンクポピュラリティ
  17. リンク元サイトとの話題の関連性
  18. リンク設置からの経過時間
  19. 文書公開からの経過時間
  20. リンク周辺のテキスト

マイナス要因トップ5(Yahoo! JAPAN)

  1. クローラーが頻繁にサーバーにアクセスできない
  2. ターゲットキーワードの使いすぎ(詰め込み/スパム)
  3. サーバーの反応が非常に遅い
  4. 既存ページの複製ページまたは類似コンテンツ
  5. リンク構築システムへの参加やリンクの積極的な販売

最も意見が割れた要因(Yahoo! JAPAN)

  1. オーソリティ/重要度の検索エンジンによる手動割り当て
  2. コンテンツの(アルゴリズム評価による)質
  3. リンク元サイトの話題コミュニティ内でのリンクポピュラリティ
  4. リンク元ページのページランク
  5. リンクの時間的属性
  6. リンク元サイトとの話題の関連性
  7. 被リンク増加率
  8. 話題コミュニティ内でのリンクポピュラリティ
  9. 外部サイト/ページへのリンクの質や関連性
  10. リンク元サイト内での内部リンクポピュラリティ

jQueryはJavaScriptで開発されたAjaxライブラリ。The MIT LicenseおよびGNU GENERAL PUBLIC LICENSE Version 2のデュアルライセンスで提供されているオープンソースソフトウェアで、一口でいえばPrototype.jsとよく似たJavaScriptライブラリ だ。2006年9月23日(米国時間)に公開された「Ajaxian.com 2006 Survey Results」の調査結果によると、もっとも人気があるAjaxフレームワークは上から順にPrototype、Script.aculo.us、Dojo、DWR。割合は7%ながらも6位にはiQueryがランクインしている。

jQueryはPrototype.jsに触発されて開発がはじまったライブラリで、Prototype.jsと類似した表記方法を採用しつつ、整 理されてわかりやすいAPI体系や軽量で高速といった特徴を備えている。XPathによる要素の指定を強力に実施することができ、直接DOMを指定して操 作する場合にくらべてコーディング量を大幅に削減することができる。

以前のバージョンでは、Prototype.jsとjQueryの実行速度は一長一短だったが、14日(現地時間)に公開された最新版jQuery 1.1では大幅な実行速度の向上と、APIの単純化が実施されている。

http://journal.mycom.co.jp/articles/2007/01/22/jquery/index.html
photoshop修正テクニック

すごいまとめ!
これはいつか必ず使いそうだからブクマついでに記事として書いておきます。


色々な修正チュートリアルまとめ


70 Beauty-Retouching Photoshop Tutorials

いつもまとめ方がはんぱじゃなくて尊敬しているブログですが、今回もすごい。

いくつか8つほどあとで使いそうな奴をピックアップしますが、上記サイトではかゆいところに手が届くほど様々なチュートリアルが存在しますので必読ですよ。

photoshopチュートリアル

シミやそばかすなんかを見事にすっきり!


photoshopチュートリアル

ヘアカラーを見事に変化!


photoshopチュートリアル

違いがわかりますでしょうか・・・。鼻の形が変わっています。


photoshopチュートリアル

このテクニックはあまり普及してはいけない気がするんだ・・・。


photoshop修正ビフォーアフター

これはチュートリアルではないけども、修正前、修正後が、マウスロールオーバーで確認出来るので、いろいろと技術の勉強になる。一度これを見てしまうと、web画像も自分の観で信憑性を疑う事も大事なんだなぁと実感しちゃいますね。


YouTube

YouTube投稿動画チュートリアル。
恐ろしい・・・。


photoshopチュートリアル

髪の毛をイラストチックに。すごい。


photoshopチュートリアル

髪の毛に光沢とつやをつけるテクニック。


もっと色々なテクニックを見たい方は以下へ


チュートリアルばかりでなく、ビフォーアフターページもありますが、デザインの参考にはなると思います。
70 Beauty-Retouching Photoshop Tutorials

それでは。また。


photoshop関連エントリー


photoshopでちょっとしょっぱい写真を素敵に変身させるチュートリアル
200806120013_20080612173419.jpg



Photoshopちょいテク『惑星を作ってみよう』+360度パノラマ画像も作れるように
惑星のつくりかた



今後の期待度が高いphotoshopブラシまとめサイト『Quality Brushes for Photoshop』
Photoshopブラシ



100のすさまじい高画質Photoshop用ブラシ
Photoshopブラシ



5つの偉大な光と炎のphotoshopチュートリアル
photoshopチュートリアル 
CSS装飾ギャラリー

なにやらクールなイメージ装飾スクリプト。
ちょっと興味があるので勉強がてらご紹介。

どのように表示するのか


以下のような感じで、Divとclassによって何の装飾もない画像に、ワンポイントのアクセサリーをつけるというもの。
CSSギャラリー


サンプルデモが以下。
CSS Decorative Gallery
クリップや、映像マーク、セロハンテープ、光沢など、様々な装飾が可能。

セロハンテープ


CSSサンプル

テープで写真を貼り付けたように見せてくれる装飾。
サンプルデモ


ビデオマーク


ビデオマーク

Diggなんかでよく見かけるような小さなアイコンを画像に付加できます。
サンプルデモ


ポインタを合わせると吹き出しが出る


コメント吹き出し

ポインタを合わせると吹き出しが画像から出てきます。
サンプルデモ


付箋付きクリップ


付箋付きクリップ

付箋とクリップの装飾。
サンプルデモ


光沢の演出


光沢の演出

透Png画像を使って写真に色々な演出も。
サンプルデモ


IE7のPng透過問題も解決するものが同梱されています。
様々なブラウザに対応しているようで、実用性も高いかも。

以下のようにバックグラウンドからハックできるようなので、ギャラリーサイトも作り易くなってますね。
バックグラウンド


細かいところはダウンロードして確認するか、以下配布サイト様で確認してください(英語)
CSS Decorative Gallery

このアーカイブについて

このページには、2008年8月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年7月です。

次のアーカイブは2008年9月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。