サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
CodeEXPRESSは、あなたのデザインを(X)HTML/CSS化する特急コーディングサービスです。最短１日納期から。CodeEXPRESS（コードエクスプレス）の特徴 CodeEXPRESS は、お客様がお送りいただいたデザインファイルから、(X)HTML/CSSのコーディングを特急で行うサービスです（最短１日から※）。 コーディングに特化することで、短い納期の対応を実現いたしました。 いただいたデザインを忠実に再現するだけでなく、文脈・内容を判断しながら手作業でHTML/XHTML 化いたしますので、ソースレベルでのSEO 対策が可能です。 W3C の Markup Validation Service のチェックはもちろん、弊社独自のガイドラインを整備することにより、高品質を維持しています。 ※ ページ数・レイアウトパターンにより、特急対応できないケースもございます サービス
Making the web BecomingPHP 6 CompatiblePHP6に備えるPHPコーディングのヒントが紹介されていました。 register_globals のOn/Offという概念がなくなるそうなので、 $_GET, $_POST, $_REQUEST から変数をとるようにプログラムを書く magic_quotes の設定もPHP6からなくなるので、使わない $HTTP_POST_VARS , $HTTP_GET_VAR へのアクセスはやめる ereg 関数の代わりに preg 関数を使う。ereg はPHP6のコアモジュールに存在しない予定だそう Object の new の際に参照を渡さない $a = & new object(); // × $a = new object(); // ○ 具体的には、「Prepare forPHP6」のエントリが詳しいよう
456 Berea StreetのRoger Johansson氏が、Garrett Dimon氏のMarkup as a Craftというエントリーを読んで、沢山のガイドラインが多すぎると感じて（？）6つの最も重要なガイドラインをエントリーであげていました。Guidelines forcreating better markup Keepitsimple. （シンプルにしてください） No layout tables. （レイアウトテーブルは使わない） Avoid classitis. （classの多様は避けて下さい） Structure and meaning first, presentation later.（構造と意味を最初に考えて下さい。見た目は後です） Know allHTML elements and attributes. （全てのHTMLの要素と属性を知って
ここでは、コーディング規約を公開しています。当規約をより良いものにするため、ディスカッション用としてメーリングリストをご用意しました。メーリングリストへの 入会方法は、このページの末尾にあります。 コーディング規約に関する情報をご紹介します。 ■株式会社電通国際情報サービス版Javaコーディング規約2004(04/09/30) ・PDF(約430KB)本Javaコーディング規約の担当者へのご意見はjava-coding-info at ObjectClub.jpまでお寄せください。本Javaコーディング規約は、（株）電通国際情報サービス様の『Javaコーディング規約2004』をもとにしております。 『Javaコーディング規約2004』の改版として、『Javaルールブック ～読みやすく効率的なコードの原則』が出版されております。 ■オブジェクト倶楽部版Javaコーディング規約(04/0
最近、CSS の使いまわしなどを視野に入れ、一部で class名や id名の共有というテーマへの関心が徐々に高まりつつあるような印象です。microformats なんかも、その流れのひとつといえるでしょう。 Naming conventions table（And all that Malarkey） もう、class名やid名で悩まないんだからっ！！（CSS HappyLife） (X)HTML の id/class における命名規則（purprin さんCSS Flight プレゼンスライド） 名前の共有はコードの共有のための（複数人で同一コードを編集・転用する）重要なファクターのひとつですし、非常にいい傾向だとは思うんですけど、実際につけられている名前を見てみると、シブい顔をせざるを得ない事例が結構あるようです。 コード共有のためには避けたい命名事例 構造ではなく見栄えで命名して
2007年01月19日 俺的コーディングルールSQL編プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つのSQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
