タグ

guidelineに関するsukka9のブックマーク (214)

  • PHP best practices

    Best practices This guide will give you solutions to common PHP design problems. It also provides a sketch of an application layout that I developed during the implementation of some projects. php.ini quirks Some settings in the php.ini control how PHP interpretes your scripts. This can lead to unexpected behaviour when moving your application from development to the productive environment. The fo

  • Slot88: Judi Slot Online Gacor Terbesar & Terpercaya Indonesia

    Judi slot online sudah pasti selalu menjadi pilihan bettor dalam setiap harinya. Karena ini bisa dijadikan sebagai sarana utama bagi semua bettor untuk mendapatkan banyak keseruan dan keuntungan. Dimana slot dijamin akan mampu memberikan rasa nyaman dan puas kepada semua bettor. Hal inilah yang menjadikan slot sebagai pilihan bettor dalam setiap harinya. 3 Daftar judi slot online Terpercaya Untuk

  • Zend Framework: Documentation: Zend Framework PHP 標準コーディング規約 - Zend Framework Manual

    このドキュメントは、Zend Framework に貢献してくださる開発者個人 (あるいはチーム) のためにコードの書式やドキュメント作成の指針を示すものです。 Zend Framework を用いて開発をする人たちにとってもこのコーディング規約は有用でしょう。 これに従えば、Zend Framework のコードとの一貫性が保てるからです。 そのためには、ここで完全なコーディング規約を示す必要があります。 注意: 詳細なレベルまでの設計指針を示すこと以上に、 それを標準規格として確立することが大切だと考えています。 Zend Framework コーディング規約の指針は、 これまで ZF プロジェクトでうまく回っていた方針をまとめたものです。 このライセンスのもとで、 そのまま使用するなり多少変更して使用するなりすることができます。 ZF コーディング規約では、次のような内容を扱います。

  • FrOSCon "PHP best practices"資料 (SOLVALOU.NET)

    ワールドカップで盛り上がるドイツで行われたPHPワールドカップ(嘘)「FrOSCon」での”PHP best practices”と題されたスピーチの資料が公開されました。 PHP best practices - The dos and don'ts http://talks.php.net/show/php-best-practices/ ※カーソルの左右でページ移動できます(→ 進む / ← 戻る) おおまかな内容はこんな感じ。 一般 typeセーフなコーディングをする opentagには"<?php ?>"を使う エラーレベルはE_STRICTにする Exceptionはメモリリークを起こすことがあるので注意 デバッガを使う(Xdebugがオススメ) コーディング規約に従う ドキュメントを書く(phpDocumentor) セキュリティ ユーザからの入力を信

  • hxxk.jp - CSS の記述ルール記事のまとめ

    いまだに私自身「これだ ! 」という答えを見出していないのですが、 CSS の記述ルールって絶対的な正解ってありませんよね ? ちょっと私が知っている範囲で明文化されている CSS の記述ルールを集めてみましたので、それを元に絶対的な正解のルールではなく、最大公約数的なルールを模索してみたいと思います。 ちなみに、今回模索するのは Lucky bag::blog: CSS を作成する際のお約束やデフォルトスタイルの差異を無くすCSS のような Tips ではなくて、あくまで .css ファイルを書き上げる際のルールのことです。 それと、取り上げた記事は順不同です。 書き上げてから、公開日時順にした方が良かったかなあとも思いましたがもうこのままで公開。 Type selectors を XHTML Abstract Modules の順番に沿って記述 - hxxk.jp ガイドラインを作成お

  • Google ウェブマスター向けガイドライン

    SEO fundamentals Introduction Search Essentials SEO Starter Guide How Google Search Works Do you need an SEO? Crawling and indexing Sitemaps robots.txt Meta tags Crawler management Removals Canonicalization Redirects JavaScript SEO Ranking and search appearance Visual Elements gallery Title links Snippets Images Videos Structured data Favicons Site-specific guides Ecommerce International and multi

    Google ウェブマスター向けガイドライン
  • ウノウラボ Unoh Labs: ユーザビリティ・ガイドライン

    sashaです。 naoya君が前回のエントリーで振ってくれたように、ジョエルテストの話から、ユーザビリティ・テストをどこまで行うかという話になりました。 私が今まで見たユーザビリティ系の記事の中には、追求したら悟りが開けそうな、限りなく奥深いものもありましたが、適度に深く、満遍なくカバーしているユーザビリティ・ガイドライン(原文)を見つけ、以降これを参考にしています。少し前に翻訳しましたので、今日はそれをご紹介いたします。 一般ユーザー向けのWebサービスでは、全部のチェック項目が該当するわけではありません。個人的には、各項目のスコアより、「スコアの説明」という欄を重視しています。現状では何が問題であり、どう解決するべきなのか、そういった思考のプロセスが、「ユーザーのことを思うこと」だと思うのです。 いま、ウノウではフォト蔵のデザイン見直しを行っております。私たちのデザインを省み、

  • [J] CSSガイドライン メモ編 - Jamz (Design)

    上ノ郷谷氏のスタイルシートを書く時のガイドライン - 2xupというエントリーにコメントしたのですが連休中に時間が取れず... 有言不実行は最低... なので、追加コメントと今後のためのメモを残しておきます。 利用者インターフェイス (User Interface) ビジュアルフォーマットモデル (Visual Formatting model) ビジュアルエフェクト (Visual effects) : というような書き方がされており、こういう正式名称があったことを知ったわけですが、念のため関連ページをメモ。 Cascading Style Sheets, Level 2 Cascading Style Sheets, Level 2 (日語訳) CSS のガイドラインに関しては以前から情報収集していて、こうした資料を公開していただけるのは非常にありがたい。と同

  • スタイルシートを書く時のガイドライン - 2xup.org

    2006-07-11T19:56:28+09:00 会社ではやっているのだけれど、自分のウェブサイトでもやってみよう。と簡略記述を利用する場合の値の順序やらもまとめとく必要があるのかもしれないけれど、セットフォーマットルールやプロパティの順番だけをサクッとまとめて資料にしてみました。課題は残したもののこれだけでも相当すっきり。詳細やセットフォーマットルールに関しては、ダウンロードできるようにしている資料を参考にしていただくとして、このエントリーではプロパティの順序についてまとめることに。自分自身が実際に作業を進めていくことを考慮し、その考えに基づいて設定したモデル別の順序は以下の通り。 生成 内容, 自動番号付け及びリスト (Generated content, Automatic numbering, and Lists) 利用者インターフェイス (User Interface) ビジュ

  • http://dojotoolkit.org/js_style_guide.html

  • Collection & Copy - MochiKit - スタイルガイド

    MochiKit - スタイルガイド 翻訳 原文:StyleGuide - MochiKit - Trac MochiKitのコーディング規約の大部分はPythonのPEP8とPEP 7(この順に優先される)に従っている。しかし、JavaScript特有の点もいくつかある : ビルトイン・オブジェクト、およびそのプロトタイプを絶対に変更しない。(例えば、このようなことは行わない: Object.prototype.foo = REALLY_BAD! ) 代わりに関数の使用を志向する。 関数のようにtypeof演算子を使用する : typeof x ではなく typeof(x) コンストラクタを使用するときには引数を括弧に入れる : new Error, foo ではなく new wError("foo") 常に完全修飾子で他の関数を呼び出す。また利便性のための記号的なエイリアスも用いない

  • Pythonコーディング規約

    This Domain Has Expired, To Renew Please Contact Your Provider.

  • Zend Framework標準コーディング規約:phpspot開発日誌

    Zend Framework PEARの標準コーディング規約というのがありますが、Zend Frameworkにも定められています。 頭に留めておくため、簡単に列挙してみました。 PHPのみのコードは最後の ?> を含めないようにする タブ文字は使わず4文字の半角スペースでインデント 1行を80文字以内に抑えるようにする。長くても120文字 改行コードはLFで統一 クラス名は英字で定義するのを推奨。ZendパッケージのクラスはZend_を最初につける。 インターフェースは名前の最後に_Interfaceを付与する。 例)Zend_Controller_Dispatcher_Interface ファイル名は拡張子をphpにする。incは使わない。 クラス定義したファイルは次のように階層的に設置する Zend_DB → Zend/Db.php メソッド名にアンダースコア( _ ) は含めない。