webは速さが絶対正義
googleさまの記事によるとページ表示は最悪でも２秒以内、理想は１秒以内。amazonに関する記事だと表示が0.1秒遅くなると売上が1%落ちるし、googleの記事だと表示が0.5秒遅くなると検索数が20%落ちる。らしい。
かたやECサイトだし、もう一方は検索で広告商売なので、こうしたデータからすると、表示速度は売上直結死活問題。コミュニティサイトやブログ、ニュース系サイトなどはそこまでシビアじゃないと思うけど、待たされるのはストレス、に違いはない。
情報設計とか、ユーザビリティとか、機能面とか、デザインとか、いろいろ言われて、サイト作りに盛られていく。この過程で、組織内の大きな声の人間や、正論クンの言うとおりになってしまって、表示速度のことに気づくのが、ほぼサイトが完成する公開直前のテストだったりして仰け反ることになる。
そりゃ、そんな機能あったらいいよね。キャッチーで人目をひくよ、このデザイン。動線確保のためにショートカットリンクは常に表示だよ、やっぱり。
なんてことやってると、表示速度は、確実にコンマ何秒かずつでも遅くなっていく。サーバーの設定で頑張って、プログラムで頑張ってるのに、わざわざ遅くなる要因をつけ足してることに変わりない。
どんな魅力的なサイトでも使ってもらってなんぼ。アクセスしてページが開くのに、ひと呼吸もふた呼吸も待たされたんじゃ、面倒で離脱する。リピータになってくれてるのに、いつも使ってるうちにイライラがたまって、そのうちアクセスしなくなる。
てことで、この雑記帖みたいな辺境も、twitterやamazonからデータを取得するコンテナが増えてくると、その分表示速度が落ちてくる。なので、ごそごそいじって、ajaxでの取得に切り替えた。ページ全体の表示とはまた別扱いなのが、ajaxのいいところ。今まで4秒ぐらいかかってた表示がぎりぎり2秒台まで短縮できた、かな（前職のダウンロード配信サイトでは、ストップウォッチを片手に表示速度をチェックして、速度が出ないので公開延期になったりもした）
てな細工を先日やったこともあって、表示速度について、電子書籍検索サイト 「電子書籍を探すなら hon.jp」 のAPIをちょっといじってみて気になった。ここは、電子書籍を総ざらいで検索できるのでかなり便利なサイト。perlでごそごそいじってウチに組み込もうとしたところ、速度が出ない。RESTのURIをそのままブラウザに入れても、レスポンスがかなり遅い。6秒程度かかるケースもある。
↓たとえばこんな検索
キーワード：山田風太郎・ジャンル：国内文学・ハードウエア：iphone
ユーザーページも、本を起点にユーザーを結びつけたり、ajaxで画面遷移なく直観的に使えるようにしたり、機能豊富でやろうとしてることは大賛成だし、かなり面白い。でも、ここも速度が出てない。一度公開してしまってる機能を引っ込めるのはちょっとアレだけど、整理して速度を見直すか、速度が出てなくて待たされてる感を少しでも軽減できるような効果を検討するとか、お願いしたいところ。
文句ばかりつけたけど、電子書籍検索に関して、このサイトは本当にオススメ！
あと、やっぱりなんちゅーか。電子書籍に統一のコードがないのが（？）困る。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» web(156)
iPhone Android スマホ対応（？）HTML
なんもしてない困った状態だし、「趣味は読書２」のテコいれでもやるか、と。スマホでも見られるようなページを作ってみた。
グーグルさまで5分ほど調べたところ、どうやら
横幅320pxでレイアウトデザインしておけば、まず大丈夫
らしい。
まあ、ただちにレイアウトが崩れることもなさそうだし、一定のめどがつくまでは320pxで、ということか。すでにデータの出し入れする部分のライブラリは作ってあるんで、そこは使いまわし。表示部分だけを新規に作る、という感じ。ひとつのソースで横幅に応じてレイアウトが変わる、というのが今後は主流だろうと言われてるけど、暑いし蒸すしよくわからないんで、USER_AGENTで振り分ける。
改めて、ケータイサイトとかブログとか、あちこち覗いてみたけど、よくもまあこんな小さな解像度にきちっときれいにレイアウトデザインしてるなあ、と真面目に感心してしまった。
ページ内に飛び先が多いと起点がわからなくなって、そのうちページ移動するのが面倒になる・使いにくいサイトになる。横幅320に詰め込むとそれがますます顕著。なので、見た限り、シンプルで、リンク領域も分かりやすいサイトが多かった。ページ内の情報は、文章なら全部じゃなくて、キャッチのみをまず見せて全容をそこで把握できるようにして、個々の詳細へ誘導する、てな作りか。
といったことを踏まえつつ、どうせなら、流行のHTML5で構成してみた。「趣味は読書２」スマホ版 http://doncha.net/sp/
…レイアウトデザインはやっぱり難しい。データうんぬん、プログラムのところは決め事があるのでそのとおりにやればどうにでもなるけど、「見た目」のところは決め事がないので面倒。HTML5は効果・表現が増えてますます、「見た目」のところにコストがかかりそう。…って、実際は、ただ声がデカイ人間のゴリ押しで決め事ができるんだけど。
[06/29 11:42:38]
てなこと書いてたけど、jquery.mobile を使えば簡単に移植できる。
「jquery mobileがあれば簡単スマホ対応」 http://t2aki.doncha.net/?id=1338631302
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» html css(39) » ブラウザ(17)
paypal と 電子書籍のダウンロード販売（その１）
小説や漫画など、電子書籍を作るのは簡単。問題はどうやってそれを売るのか。
「ホームページに並べて・購入してもらって・ダウンロードしてもらう」
というのをどうすんだよ、てことで調べてみたメモ。
（ちなみに、作った電子書籍はDRMなしのPDFファイル）
結論から言うと。
Paypal のプレミア（以上の）アカウントを作れば、個人でも簡単にクレジットカードを使った小額決済ができて、ちょっと仕組みを作ればダウンロード販売までできる。
Paypalのアカウントは固定費不要。クレジットカード決済に審査も不要。一度の決済手数料は40円＋3.8%～。驚く手軽さ気軽さだ。
ショップとユーザーの流れ
ショップを訪れたユーザーがページにつけられたPaypalの購入ボタンをクリックすると、Paypalの支払いページに飛ばされて、そこで支払い手続きとなる。クレジットカード番号やメールアドレスなどをPaypalに対して入力することとなる。Paypalの支払い完了ページに、「マーチャントに戻る」というわけのわからないリンクが目立たないようあるけど、これをクリックすると、ユーザーはショップに戻される。戻ってきたユーザーは、ショップが用意した「ご購入ありがとうございました」ページなどを見る。
こちらでユーザーを誘導する。
ショップの裏方（たとえばデータベース）とPaypalの流れ
それとはまた別に、Paypalは支払いが生じたら、ショップにお知らせしてくるので、それを元に、ショップはデータベースに登録したり、ユーザーにお知らせメールを発送したりする。
こちらでショップとして売買の確定をする。
上記のやりとりで、なにか不明点があっても、Paypalの管理ページを開いてみれば全部わかるので、後でチェックして対応することも簡単にできる。
Paypalとのデータのやりとりでは
「誰が何を買ったのか」
だけがわかればOK。というかPaypalの役割はここまで。
ダウンロードURLを作って、そこでダウンロードできるようにするのは、ショップ側で作ることになる。
PDTとかIPNのサンプルコードなどの具体例は、以下次号、かな。
# ページは、あとは、本番でのチェックと原稿の校正だけ、となった。
# 七月にはオープン予定で。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ぴんち、かなぁ
検診の結果がろくでもなかった。
尿酸値7.4（正常7.0以下）
コレステロールは高水準で治療中
上記おっさんメタボはくそったれ、な感じだよな、てへ。と済ませてやろう。
問題は眼底検査。
網膜血管硬化症（両目とも）
網脈絡膜萎縮（左目）
って、もしかしてぴんちなのか。失明はキツイぞ。視力が0.4まで急低下してるし（…とか思ったら去年すでに0.3と0.5だった）
調べてみると、ようは血管の病気っぽい。コレステロールの高脂血症が原因じゃねえのか、こいつ。…素人がビビっててもしょうがない。とっとと精密検査だ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 健康(84)
あちこちネタもないんで。
mixiの日記を使おうと、ちょっと変更したけど、人間、んなネタがあるわけがない。自前の本読みSNSもあるし、やっぱりmixiはこの雑記帳に戻そう。
web屋にゼロたくさん払ったコミュニティサイトがやっぱオシャレすぎ。そもそもターゲットに実態がない、というだけでも頭が痛い・お手上げなのに、デザインがお上品なグラビア誌。こんなもの、にぎわうどころじゃない。ひとがよりつかんぞ。コンテンツ提供型なんて資金回収のメドもないままやれるわけがないし、消去法で掲示板形式になったってのに。
しょうがないんでいじれるところはいじろうと、ちょっと聞いてみたら「システムを勝手にいじられると、これ以上はサポートできない」と。いやまあそのとおりなんだけど、たかだかひとつテーブルタグをつけるだけで２人日、14万という見積もりはどうなんだ。あれ？けっこういい給料もらってんぢゃねいか。というのがあって、スクリプトを覗いてみた。
さすがにしっかり今時。モジュール化されてきちんと継承というやつ。レガシーコーディングな（＝古臭い）わたしにはなんのこっちゃの呪文ばかり。勝手に書き換えてやろうと思ったのに、これじゃさすがに手が出せない。弱った。
と、こっちは便利屋ネタ中心でいくかな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
意外に手抜き工事か
今日は最寄の職安へ。月曜日ということもあってか、番号札での順番待ち。少し待たされて端末で検索する。新着にはなにもないので、またジャンルを限定しないで総当りだ。これを見ると世の中ってのはいろんな仕事があって成り立ってるんだなぁ、としみじみ感心、というか感動すら覚える。
主な顧客が防衛庁という生命保険会社の募集…昔は自衛隊といえば戦争にいく必要のない安全な職場だったのにねぇ。
会長専属運転手の募集…職安に出すようなことなのかねぇ。
帰りに駅前のスーパーでエアコン室外機の排水ホースを買う。専用の規格品、径14mmのホースがあった。いろんなところで共通の規格というのがあるもんだ、と。さっそくとりつけ、さらに昨日の寄り合いで出た風呂の汚水臭さもチェック。
排水回りがヘドロ状だ。これじゃ臭うはず。バスタブの奥の届かないところにはシャワーを当てて流し出したら、さらにゲル状のなにものかが流れてきた。これって使ってるうちにたまったものではなく、最初から溜まってたものなんだよねぇ。新築から入居まで半年ほどあったんで、その間にカビってヘドロった、のではないかと。
ダバダバ水を流し、風呂用洗剤でゴシゴシ洗いまくる。とりあえず臭いの元はなんとかなったと思うけど、排水とか湿気ヌケの悪さを考えると週に一度は掃除しないとまずそうだなぁ。うううむ、しょうもないとこで手抜き工事やってやがる。
zaurusの EBt というメモアプリが気になって、こないだからどういうものか、ぼーっと考えてたりするのだ。これってblogというかwikiで実現できてることなのか、それともまったく違うシロモノなのか。序列なしにひらたくリンクだけ、というのが面白いし、それを少しずつ一覧させて見ることができるのもいいなぁ。「思いつき」の「手軽さ」と「雑然感」をカタチにするには、スタイルを気にして少し正座してしまうblogのようなものではなくて、こっちの方が自然かも。
この手の「思考ツール」ってPDAならではの面白みですよね。
書類送って1週間ほどなしのつぶてだったところから面接の連絡があった。書類から面接日まで日にちがあっても、面接の通知はほとんどが書類が着いたであろう日かその翌日。ここも連絡がなかったので書類落ちでお祈りのお手紙待ちだと思ってたんだけどなぁ。どうしたこっちゃ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 日常(903)
