Check

Tweet

さて。
はじめましてこんにちは。

ゆめみの開発者によるブログ「ゆめ技」ですが、ゆめみにはもちろん開発者じゃないメンバーもいるんです。
そんな「じゃない」側のトップバッターとして、ケータイサイト外観構築からリニューアルのお手伝い、はたまたドット画像やケータイFlashコンテンツなどなどを幅広くを担当するゆめみ稀少職種、デザイナーのShoe'sが今回はお届けしてまいります。

挨拶もほどほどにして、ケータイから離れ気味の路線を少し戻し、
「ふーん」と言っていただけるくらいの、QRコードについて小ネタです。

続きを読む "一歩先行く、デザインQRコード。" »

Check

Tweet

日時: 2009年04月02日 10:00 | コメント (2) | トラックバック (0)

Check

Tweet

初めまして、石原です。

モバイル端末において、webページを効率よくキャッシュさせるということは、パケット代の節約や応答性の観点から考えてとても重要なことだと思います。

今回は、コンテンツ内容の検証を毎回行い、変更がない場合はキャッシュを使用させる方法と、注意点について投稿させていただきたいと思います。

はじめに

キャッシュを制御する方法は大きく分けて、METAタグによる制御とHTTPヘッダによる制御の２種類があります。

今回は、HTTPヘッダを使用した制御を行いたいと思います。

HTTPヘッダを使用した制御には、キャッシュの有効期限を定め、有効期限内ならばキャッシュを使用するという期限モデルと、キャッシュサーバがWEBサーバーに条件付きリクエストを行う事でリソースの検証を行い、リソースの変更がされていなければキャッシュを使用するという検証モデルがあります。



今回のケースでいうと、検証モデルを使用したいところなのですが、、、後に記述する問題点の為に、検証モデルと期限モデルの両方を使用します。

続きを読む "携帯にキャッシュさせる方法（キャッシュコントロールについて）" »

Check

Tweet

日時: 2009年10月30日 11:16 | コメント (0) | トラックバック (0)

Check

Tweet

お久しぶりです。Shoe'sです。

モバイル向けのXHTMLで3キャリアで同じ表現をしようとした場合には、必然的に一番表現能力の劣るドコモに合わせる必要があります。モバイルユーザビリティ・デザインにも載せているコーディング例の他にも、ハマってしまうポイントや汎用的に表現したいもの。という観点から今回は『TABLEで実線（solid）を表現する』方法を紹介します。

続きを読む "【3キャリア共通コーディング】テーブルで、シンプルなソリッドを。" »

Check

Tweet

日時: 2009年11月19日 17:50 | コメント (0) | トラックバック (0)

Check

Tweet

お久しぶりです。Shoe'sです。

モバイル向けのXHTMLで3キャリアで同じ表現をしようとした場合には、必然的に一番表現能力の劣るドコモに合わせる必要があります。モバイルユーザビリティ・デザインにも載せているコーディング例の他にも、ハマってしまうポイントや汎用的に表現したいもの。という観点から今回は『au（EZweb）端末で、div要素間の無駄な隙間（スペース）を生まない』方法を紹介します。

モバイルに於ける細かい制約等はここでは控えますが、「div要素で隙間が生まれる」ということは、3キャリア共通では「margin属性やpadding属性に対応していない」ということが前提になります。というところで、まずは問題点から。

au（EZweb）端末に於ける、div要素の問題点

ごく普通にdiv要素を記述すると、au（EZweb）端末では要素の上下に余分なスペースが開いてしまいます。

モバイルサイトでより凝ったレイアウトを実現しようとした場合に、悩んだことがある方は多いと思います。

div要素を入れ子で記述してみる

解決策として、真っ先に思い浮かぶ手法だと思いますが、以下の様にdiv要素-Bのスペースによって、外側（div要素-Bの下）に数ピクセルの予期しないdiv要素-Aの背景色が表示されてしまいます。

この方法で落ち着いてるモバイルサイトはよく見掛けます。
ただし、このままではdiv要素を繋ぐ画像を表示させたい場合に、しっくりこないのです。
　　
div要素-Aの下辺（左）に置いても、div要素-Bの上辺（右）に置いても、
表示させている側の背景色が数ピクセル、余計なスペースとなって立ちはだかります。

目から鱗のコーディングで解決する

このような問題は、細かな説明は省きますが（といっても説明のしようがありませんが）、
『全て入れ子にし、閉じタグを最後にまとめる』というコーディングにより解決できるのです！

是非、活用してみてください。

■3キャリアでdiv要素間の無駄な隙間（スペース）を生まないソース

<div style="background-color:char">div要素-A<br />
	<div style="background-color:char">div要素-B<br />
		<div style="background-color:char">div要素-C<br />
		</div>
	</div>
</div>

Check

Tweet

日時: 2010年02月15日 15:00 | コメント (0) | トラックバック (0)

Check

Tweet

こんにちは。Nairoです。

CS5が発売されましたね。
使っている方も多いかと思いますが、先日CS5で書き出したファイルが初期設定のままでは、一部携帯端末（例えばSoftbank 905SH）で表示しないということに気づきました。
初期設定ではWeb書き出し機能（Web およびデバイス用に保存）にメタ情報を付与するようになっています。
これです。

このまま初期設定で保存してしまうとメタ情報などが付与されてしまい、一部端末で表示しないことがあります。
ということでメタ情報をなしに。
情報を付けなければファイル容量も小さくなりますし忘れずに！
特にインストールした直後などは注意しましょう。

メモ書きでした。

Check

Tweet

日時: 2010年06月08日 20:29 | コメント (0) | トラックバック (0)

Check

Tweet

こんにちは、mikkoです。

ずいぶん間が開いてしまいましたが、Firefoxで開発を行うためのTips 第2回です。

Firefox3でDoCoMoの生絵文字を入力する

前回紹介した、「Firefox3でDoCoMoの生絵文字を表示する」やFireMobileSimulatorを用いることで、ケータイサイトの表示については行えるようになりました。

ただ、開発をする以上、生絵文字を入力して確認したいのが人情というものです。
そこで、NTTドコモから配布されているi絵文字をつかうことで、絵文字入力ができるじゃないか！ということで、実際に入力してみると、

フォーム入力時	⇒	フォーム送信後
入れた絵文字が・・・		変換されてしまった。。

あらら、入力したはずの絵文字が、フォームで送信すると、「&#*****」になってしまいます。

※SJISのページの場合です。UTF-8のページでは正常に送信されます。

これは困った、でもFirefoxで開発したい、ということで、以前作ったFirefox用のaddonを公開します。

emozilla - FirefoxでDoCoMoの生絵文字を送信可能にする拡張

Firefoxでは、SJISのリクエスト送信時に外字に相当するコードが含まれる場合、自動的に「&#*****」（UTF-8コードの10進表記）に変換する仕様になっています。
emozillaは、この自動変換を抑制（正確には再変換）し、Shift-JISコードとしてそのまま送出する拡張です。

ページ自体をUTF-8にしてしまえば問題はないのですが、ケータイサイトは依然としてSJISで製作することが多いため、この問題が出てしまいます。

emozilla導入後

正常に表示可能

単に送出するだけだと面白みにかけるので、i絵文字のような絵文字パレットも追加してあります。i絵文字だと、クリックしても入力されないケースがあるのですが、emozillaのパレットから入力すると、確実に絵文字が挿入されます。

絵文字パレットを表示するには、Firefoxのメニューから「表示」-「ツールバー」-「カスタマイズ」を辿り、emozillaのアイコンをツールバーの任意の場所にドラッグしてください。このアイコンをクリックすることで、絵文字パレットが表示されます。

ツールバーボタン	DoCoMo絵文字パレット

弊社では、CMS等でケータイサイトの画面を作成する際や広告の入稿時など、マルチキャリアの絵文字変換のベースとしてドコモの絵文字をそのまま使用する場合が多いのですが、いちいちInternetExplorerに切り替えることなく、Firefoxでさくさく絵文字が入力できるので重宝しています。

利用者がかなり限定される特殊な拡張ですが、上記問題で悩んでいた方は是非お試しください。

emozilla 0.2.6のインストール

Check

Tweet

日時: 2010年09月30日 14:43 | コメント (0) | トラックバック (0)

Check

Tweet

はじめに

こんにちは。樽八です。

ちょうど1年ほど前になりますが、弊社にてGREEプラットフォームにおけるソーシャルアプリ携帯ゲーム「偉人伝心」のリリースを致しました。
その時のシステムに対する機能要求および非機能要求に対してできたこと、できなかったことをエンジニア視点で列挙したいと思います。

システムに対する要求と、達成、未達成状況

ほぼ達成された要求項目(４項目)

2000万PV/日のアクセスに耐えるシステムを作ること。

  →負荷試験時において、画像合成、Flash合成ページを含めて、webサーバ１０台時の構成において、1400リクエスト/秒(単純計算だと1億2000万PV/日)以上のスループットを達成。
　（※残念なことに、これだけの負荷が実際に掛かることはありませんでした。）

会員数の増減に合わせて速やかにシステム全体の構成を変更出来ること。

  →サーバの追加に応じてシステム全体のスループットを上げることのできる、スケールアウト可能な構成としました。
  →上記負荷試験時の数字もWebサーバの追加によりさらに引き上げることが出来る事を確認しました。

予期される障害発生に関しては、たとえスループットが落ちた状態状態であったとしても通常サービスの継続が可能であること。

  →全てのHW機器を冗長化して構築しました。

特定の機器が障害によって復旧不可能な状態に陥っても、サービス継続に必要なデータが復旧可能であること。

  →上記、HW機器の冗長化に加えて、データの保有に関しても冗長化を行いました。

続きを読む "完全公開！ソーシャルゲーム設計事例：プロローグ" »

Check

Tweet

日時: 2011年07月25日 10:44 | コメント (0) | トラックバック (0)

Check

Tweet

はじめに

こんにちは。樽八です。
この記事は、前記事「完全公開！ソーシャルゲーム設計事例：プロローグ編」の続きになります。

おさらいとして、今回要求されたシステム要件(機能要件および非機能要件)

• 2000万PV/日のアクセスに耐えるシステムを作ること。
• 会員数の増減に合わせて速やかにシステム全体の構成を変更出来ること。
• 予期される障害発生に関しては、たとえスループットが落ちた状態状態であったとしても通常サービスの継続が可能であること。
• 特定の機器が障害によって復旧不可能な状態に陥っても、サービス継続に必要なデータが復旧可能であること。
• 負荷のピーク時においても、各ページの応答時間が5秒を超えないこと。
• サービスを動かしながらの頻繁なアップデートおよびデータ更新が可能であること。

続きを読む "完全公開！ソーシャルゲーム設計事例：前編" »

Check

Tweet

日時: 2011年07月26日 11:00 | コメント (0) | トラックバック (0)

Check

Tweet

はじめに

こんにちは。樽八です。
この記事は、前記事「完全公開！ソーシャルゲーム設計事例：前編」の続きになります。

まだの方は是非合わせてお読みください。
○完全公開！ソーシャルゲーム設計事例：プロローグ編
○完全公開！ソーシャルゲーム設計事例：前編

前編では、弊社構築ソーシャルゲームにおける。コンテンツ生成Webサーバの構成とキャッシュまわりについて紹介いたしました。
いよいよ後編では、データベース構成とシステム全体の冗長化に関して記述させていただきます。
本丸であり、少々長くなりますがお付き合い下さい。

続きを読む "完全公開！ソーシャルゲーム設計事例：後編" »

Check

Tweet

日時: 2011年07月27日 11:00 | コメント (3) | トラックバック (0)