---

と、いうことで予告していた通りトップページのサイドバーがスクロールに追随するようにしました。
ただ単に追随するだけでなく、上スクロールにもちゃんとついていくというステキなjQueryを見つけたので使わせて戴きました。ありがとうございます。
これができるとデザインとか考える必要なくなるんで助かりました。


あと黒歴史コーナーをナイナイしました





さらにレスポンシブデザインにも完全対応しました。スマホで見ると上にメニューが表示されます。Bootstrap使って実装しました。
正直言うとちょっとダサい気がするんですが、洒落たデザインをそもそも思いつかないという問題があるので、暫くはこれで放置させてください。（笑）


ちなみに、スマホ版では必要最低限のコンテンツしか表示されないようになってます。置き場所に困るリンクとかも普通使わないと思うんで消しました。スマホでサイト巡る文化ってそもそもないような気がするんで。皆さんはどうでしょう。僕は個人サイトは自分のサイト以外スマホでは見たことないです･･････。

あと、なんか調子乗ってtwitterボタンとかつけてます。ほんとはこれつける予定なかったんですが、Othersのプルダウンメニューを開くと画面の外にはみ出して結構ダサいので、それを防ぐために置いてたりします。Adblock系ブラウザ使われると意味ないんですけどね。





ついでに、日記ログの方もスマホ表示がバグってたんで改善しました。っていうか、横並びで表示せずに上下になるようにしました。
日記ログにもヘッダーつけようかとも一瞬思ったんですが、別にそんなに人に見て欲しいわけでもないのでやめました。（笑）



個人的には満足してるんですが、何か不便だとかバグってるとかあったらどうぞ。
ちなみにNexus5では問題ないのですが、priori3で見ると何故か日記ログのページに横スクロールが発生するバグがあるんですが原因が全く分からず、PC上で検証できないので諦めます。横サイズを縮めても問題が発生しないので意味わかんないですが、分からないものは分からないのでごめんなさい。←


>>



思いつきでコメント欄もメニューに追いやってみました。
PCだと上スクロールなんてそのままつまんで上げればいいんですが、スマホだと一番上までスクロールして･･････ってのは結構ダルいんで。そもそもコメントもらう機会はそうそうないですけどね。




クリックしたらこんなポップアップが出ます。


PC版でも同じようなことしようかと思いましたが、デザイン上の問題でやめました。上にナビバーつけることも考えたんですが、どう考えても目障りなので（笑）


あと、画面サイズが小さいとProductsの文字がはみ出る問題も多分解決したかと思います。
ただし想定を超えて小さい場合はもうどうしようもないので諦めます。もうCSSは疲れました。（笑）



flexで無理矢理引き伸ばしたせいで、もしかすると画面幅が中途半端に広い画面で見ると不格好かも知れませんけど、横サイズが700px前後の環境ってそうそうないような気がするので大丈夫でしょう。（笑）
このサイトは横向きよりも縦向きの方が明らかに見やすいですし、敢えてスマホを横にして見る人はいないと思ってます。僕は。



･･････ですよね？笑





ただ、最終的に本来ウチのサイトはPC向けサイトなんでスマホ向けに頑張る理由って実はないんですけどね。単なる技術練習です（笑）




このコメント欄もいつかリファインしたいなーとずっと思ってるんですけどね。わけわかんないCakePHPで、とりあえず動くように作ったものなんで。
ただLaravelで動かすほどのものでもないし、作るとしたら自力で全部実装することになりそうです。めんどくせえよなあ。

たぶんやるとしたら来年の冬休みになると思います。気に入らないといえど、正直めんどいもん。(笑)


それよりも先に、貰ったコメントのフォーマットを考えたいところですね･･････。年始に考えよ･･････。


>>

twitterのパチモンを作る、ということでユーザー側が自由にアイコンを設定できるようなシステムが必要になりますね。
しかしデータベースは文字列しか扱えないので、画像ファイルをそのまま格納することはできません。
そこで、データベースに画像を格納するにはどうしたら良いのかを考えた時、大きく分けて2通りの方法があります。

１：画像ファイルをバイナリデータ(文字列)に変換しDBにぶち込む
２：画像ファイルへのパスをDBに入れる

多くの場合、２の方法が用いられるそうです。データベースが巨大になるとやりづらいんですかね。
まぁ割と簡単に実装できますし良い方法だと思います。
デメリットとしてはサーバー移転の際、画像ファイルを忘れると機能停止するのが欠点らしいです。忘れなきゃいいじゃんって気もしますけどね。


DBに直接バイナリデータを流しこんだ場合、ファイル容量が増えるという欠点があるそうです。
レスポンスの良さを求める場合は宜しくないかも知れません。が、DBにデータがまとまるので管理しやすいという利点があります。


２の方法は別に何の苦労もなく出来るので、ここは１の方法を採ってみることにします。Oracleがお勧めしてくれてるのでそんな悪い方法じゃないんじゃないですかね。Oracle使ってないけど。



データベースに直接画像を入れるのは簡単に出来るんですが、実は取り出すのが結構難しい。
というのも、html出力の際、ファイル自体は存在しない･･････つまりsrcに書くものがないんですね。
つまりここでHTMLが解釈できるような形に変換しなければなりません。それがBase64というものです。

まぁこの変換はPHP側でやってもらえばいいんですが、ここで一つのアイデアとして最初から変換した値をDBに入れておくというアイデアが良いなと思いまして。
つまり、その文字列を直接HTMLに埋め込めばサーバーがアクセスの度に頑張って変換しなくても、格納されてる値をそのまま吐き出せば良い訳ですからね。とても現実的な案だと思います。
Base64に変換することで3割ほどサイズが増えますが、アイコン画像の3割なんてそんなもの微々たる量なので無視します。この方法の方が処理時間は短くなるそうなので。



次に、Base64に変換されたバイナリデータをimgタグで表示するにはどうしたら良いのか、という話になりますね。

<img src="data:【mime】;base64,【バイナリ】">

書式としてはこんな感じです。



実際に表示してみるとこうなります。(どうなってるかはソース見たら分かります。)



実際にソースを見るとなんかすごいことになってますが、画像を文字列で表現するとこうなる、って話です。
ちなみに、このBase64エンコーディングは、画像を直接HTMLに書き込むことで外部ファイルとして扱わなくて済むため、リクエスト数を減らすことができてレンダリングを高速にすることができるため、Googleの画像検索とかで使われているらしいです。



プログラムはどう書かれているのかというと、こんな風に書いてます。


次に考えなくてはいけないのはMIMEです。
画像ファイルって一口に言っても、GIF,JPG,PNGぐらいは対応したいところですね。ですがそれを判別するにはどうしたら良いのかという問題があります。
これを簡単に取得する関数としてexif_imagetype()ってのがあります。


※exif_imagetype()は変なファイルを送ると警告を出して異常終了するので、@をつけて処理を続けさせるのがベターだと思います。
基本的な使い方はこんな感じですね。コメントアウトを外すことで対応するファイルを増やせますが、ビットマップなんてもの使われたらウザいだけなので非対応にしといた方が良いでしょう。
これでmimeタイプが分かるので、こいつとBase64を用いれば、DBに格納しての画像表示が可能であると思われます。




ですがこれ･･････明らかに偽装が簡単なんですよね。


ということで、どこまで厳密なセキュリティチェックを施すべきかを調べてみたんですが、基本的には変なファイルを実行させなければそんな大きな問題ではないらしい。
要はPHPとして実行させなければ良いということで、PHPがバイナリ化できるのかどうかは知りませんが、そうなった場合でもそもそもexif_imagetype()がバグってアップロードできないような気がするので、特に対策しなくていいんじゃないかなーとか思ってます。

「思ってます」じゃねーだろヴォケって感じしますけど、調べても見つかんないってことは大丈夫なんだと信じましょう。バイナリの知識なんかないので検証なんてできないです



つまり、DBに格納する流れとしては以下のような感じですね。


1.画像アップロード
2.MIMEチェック
3.アップロードされた画像をBase64変換
4.データをDBに格納

5.DBに入ってるバイナリデータをそのままimgタグで出力


これをいい感じにプログラムするとよさ気ですね。





実機でもちゃんと動きます。



ちなみに、twitterではどうなっているのかというと、普通に画像ファイルへのパスを通して表示させているそうです(笑)
実際どっちの方法が良いのかは詳しい人に聞けるような機会ができたらいつか聞きたいなあとは思っています。動けばいいんだよ動けば



<<コメントお返事>>

---

>>あいうぇえ さん