PakuReserve(パクレゼルヴ) R&D Laboratory

こんばんは。またまたチョコボールです。2日連チャンです。

今回はMVCという考え方におけるVとCのお話です。

自分は業務ではSmartyも使ってます。

Smartyを使う目的はコードの可読性向上、デザイナーとプログラマーの分業、デザインとロジックの分離などありますが、そういう意味において、値の加工はコントローラー側でおこなって変数や配列に格納してビュー側では極力表示だけ！
MVCモデルにおいてはこれが理想だと(勝手に)思ってました。

たとえば下記のような値段を表す変数があったとします。

$price = 1000000;

これをブラウザでは「1,000,000円」のように千の位単位で区切って表示させたい時、

コントローラー側で

$price = number_format($price);

のように加工してからビューに渡す。
こうすべきだと思ってました。

しかしこうしてしまった場合、後でデザイナーから「区切らなくていいよ」等の修正を依頼されたり、仕様が変更した場合など、結局プログラムを書いた側が修正することになり、二度手間で面倒なことになります。

普通に生のデータをビューに渡してテンプレート側で下記のようにコーディングした方が合理的です。

{$price|number_format}

見せる部分はできるだけデザインする側にお任せ。
完全に分業するとしたらそれが理想ですね。
かなり時間が経過した後に仕事を引き継いだ他のプログラマーが修正することになったとしても、コードを追わなくてもテンプレだけを変更すればいいですし。
プログラマーもデザイナーもSmartyを覚えなきゃいけない、というのは大変ですけど。。
(いや実際かなり大変です…)

日付表示に関してもロジック側でタイムスタンプ値のデータがあれば、タイムスタンプのままビューに渡してあげた方が修飾子のdate_formatでいろんなパターンで表示させられます。

できるだけ生のデータをビューに渡した方がデザイナー的には見せ方の選択が広がるわけです。

どう表示させるか(見せるか)というのは本来ビューの役割なので　極力ビュー側に任せた方がいいということですね。

MoriMoriMoriMori HTMLとか, PHP, Tips, 未分類

こんにちは～！べきこですよ。(´ー｀)

ようやくサーバ側のお仕事に慣れてきました。

インストール時にいろいろ細かい設定するためにシェルスクリプトを使うので、
せっかくだから中身をもっと充実させようと！(そして自分が少しでも楽になろうと・・)

ということでファイル作ったり、移動したり、値変更したり～なものを作ってたのですが、、
mysqlが動きません。。なんで？(´・ω・｀)

検索してて見つけたのが
シェルのオプションにデバッグがあるらしいです

sh -x test.sh

実行コマンドにこのオプションを加えるだけで、実行されたものがすべて表示されます。

cp /home/test/test.php /var/www/test/test.php
chmod -R 755 /var/www/test/
chown -R test:test /var/www/test/

こんな感じで、実行したコマンドが表示されます。

このログではあらかじめ指定してあった変数もきちんと表示されているので便利です。

で、結局なんでMySQLが動かなかったのかというと・・・
パスがちゃんと通ってなかったのと、MySQLでは使わないコマンドが途中に入っちゃってたのというわけで・・・

(( ;ﾟдﾟ)ｱﾜﾜ

もっとお勉強してきます・・

べきこ Linux, Tips

チョコボールです。

WEBアプリ開発においてはLAMP(Linux、Apache、MySQL、PHP)が中心ですが、モバイルコンテンツ開発がメインと言っても管理画面系は基本的にPCから操作します。
ということは、JavascriptやAjaxも扱えた方が当然アツい訳です。

プログラミングを始める前まではJavascriptはネットで拾ってきてコピペで使っていました。
使うケースが増えてきたのでこれを期にちゃんと身につけようと思って地味に勉強中です。
Javascriptについて書きたいのですがまだまだへっぽこですのでまた今度。。

今回はCSS(Cascading Style Sheets)について。

開発担当の自分はCSSは業務ではあまり触れることはないのですが、面白いので個人的に勉強してます。
綺麗なMVCモデルのWEBアプリ構築を目指してる自分としては、Vもさらに分けたいという欲求も自ずと出てくるものです。

数年前に流行りかけたテクニックらしいのですが、
『フォントサイズをピクセル単位のように直感的に相対指定する技』

たまにソースを覗くと、このような指定を見かけることがあります。

body{ font-size: 62.5%; }

一つのサイトならまだしも、他のサイトでも同じ62.5を多く見かけました。
最初はなぜ62.5%なのか！？って感じで謎でした。

こう指定することにより、ブラウザ上でフォントサイズを12pxの大きさで表示させたい場合は1.2em、14pxの大きさで表示させたい場合は1.4emのように直感的に指定すれば、ブラウザの設定でデフォルトのフォントサイズを変更してなければ、たいていの場合は望み通りの表示になってくれます。
現在、ほとんどのブラウザで大丈夫のようです。

そのメカニズムは…

現在広く使われているブラウザの殆どはデフォルトのフォントサイズが16ピクセル。
もしデフォルトの文字サイズが10ピクセルになっていたとすれば…と発見者は考えたようです。

16ピクセルを相対指定で10ピクセルに変えるには

10÷16＝0.625

body要素に62.5%として指定すれば、先に示した通り、直感的に指定できることになります。

デメリットも有りますが、便利ですね。

MoriMoriMoriMori HTMLとか, Tips, その他

新規サービスオープンのため対応中。姜子牙です。
本体のネタ以上にこの冒頭のネタを練りこんでいたりすることがあります。

2/22のエントリでバックアップについて記載しましたが、今回はバックアップ第二弾を書きたいと思います。

さて本題、バックアップは何重に取るべきか？

バックアップの対象となるデータをマスタデータと呼んだ場合、それを一つコピーしてバックアップすると1重とします。
私は基本は2重に取るようにバックアップは設計しています。1重ではやや不安で、3重だと余剰だろうと考えています。
2重の場合、マスタデータ含めて3つ同じデータが存在することとなります。

ここでのポイントは「このバックアップでマスタデータが何個分存在することになるか」です。

よくあるのが、AというディレクトリのデータをBというディレクトリが常に同期していて同じデータが入っているのに
AもBもバックアップに含めてしまう、ということがあります。
これだとマスタデータはAのディレクトリのデータなのに、Bのディレクトリ、Aのバックアップ、Bのバックアップという形で
4つも存在してしまうことになるわけです。

多ければ多いほどデータの消失確率は減りますが、逆にその分ディスク容量を圧迫することになります。

なので、私の場合、上記A・Bのディレクトリがあった場合、Aはバックアップ対象としますが
Bはバックアップ対象から外すように設定をするわけです。
こうするとAディレクトリ、Bディレクトリ、Aのバックアップでマスタデータ3つ分というわけです。
まあ、他の同期していないデータとかと一纏めにする都合でAバックアップのコピーが生まれるので
データ4つになっちゃうんですけどね・・・。

もう少し具体的に言えば
更新系を司るマスタデータベースがあって
それのホットスタンバイであるスレイブデータベースがあって
マスタ・スレイブそれぞれでバックアップ取って
さらにそれぞれのバックアップを2重化したりすると
データ6つ分になっちゃったりするんですよ・・・。
いや、うん直さないといけないですけどね・・・。

やや余談になりますが、
サーバがRAID1の場合、その時点でマスタデータが2重だからバックアップ1個取れば3重と言えなくもないですが、
私個人の考えとしてRAID1でコピーされるデータはバックアップとみなしていません。
あくまで、HDD物理障害対策の機構であって明示的なバックアップではないと考えているからです。
|-’) HDDが無事でもRAIDのカードやチップが往生してしまうこともあるし・・・。

まあ後半はやや個人意見だらけなので、こんなんあるんだ程度としておいて頂いて
バックアップを設計する時は一度マスタデータが何個分になっているか意識してみると良いかもしれません。

[Mr.マカー](#ﾟДﾟ) < 「で、バックアップサーバどうすんの？」
[姜子牙]（;’-') < 「あ、えーと今のサーバのディスク枯渇するまでもうちょい時間あるので検討します・・・。」
[べきこ] (´ー｀) < 「時間経って忘れてると大変なことになりそうだね」
[姜子牙] ∑(；’-') < 「ドキッ」

はい、冗談にならないです。

姜子牙 Linux, Tips, その他

こんにちわ、かーつんです。

今回はDBのテーブル設計時の話し。

あくまで私の主観での話しなので間違ってるかも(苦笑)

まぁ、同僚と話してて意外と考えられていなかったので、書いてみます。

私はテーブルを大きく３つに分けて考えます。

更新系　と　参照系　と　その他

運用上、更新が多いのか、参照が多いのか、

ざっくり分けちゃいます。

分けることで何が変わってくるのかというと、

インデックス　です。

SELECT文を実行するときに条件として使用する項目インデックスをつける。

これは結構基本だと思います。(データ量との兼ね合いもありますが)

ただ、あまり考慮されてないのが、UPDATE文・DELETE文。

UPDATE文とDELETE文はインデックスが付加されているテーブルを更新する際、

インデックスも更新しにいきます。

要するに、処理に時間がかかりリクエストタイムが無駄にかかります。

なので、テーブルを更新系と参照系に分けて考え、

インデックスの量を調整する必要があるわけです。

ただ、構成上、参照も更新もどちらも頻繁に行われる場合があると思います。

それが、その他。

この場合は、参照を優先してインデックスを付加するようにします。

傾向として、登録更新に時間を要する処理は待って貰えるんですよね。

でも、参照に時間のかかるサイトって、やっぱり見て貰えないんです。

なので、純粋に参照が多いと思われるテーブルほどではありませんが、

参照を意識したインデックスの付加が必要になってきます。

参照メインのテーブルにインデックスが無いとか、

更新メインのテーブルなのにインデックスが大量に付加されているとか、

ナンセンスなわけです。

こんなこと書いてると、

「鯖スペック上げれば良いんだよ。」とか言われそうですが、

予算って決まってるんでそう簡単にもいかないんですよね。。。

 あとは、たしかに回線速度や鯖スペックが上がってて、

意識する必要がなくなりつつあるのも事実かも知れませんが、

エンジニアとしてはその当りも考えておくべきかな。と。

もちろん後々用途が変わって調整ということもあります。

そのときには是非意識してみていただきたいです。

大量データの処理を行う際(ログの分析とか)には、

テーブル構成の善し悪しもありますが、違いが明確に現れるはずです。

会員数の増えてきたサイトでのユーザ検索とかでも有用なはずですよ。

更新なんかで言うと掲示板のスレッドとかネ。

とりあえず今回はここまで。でわまた次回(´･д･｀)ﾉ〃

かーつん データベース