ModelをLibraryとして使う
典型的なMVCは好きではないです。
ViewとControllerを分けるのはわかるし納得ができる。
あと、古いフレームワークでDBとのクエリをModelでまとめるのも納得できる。
しかし、今時DBとの接続がフレームワークが設定されていので、あえてModelでSQLの記述と接続を記述しなくてもいいかと思います。
古いフレームワークの場合はmysql_connect()を記述してSQLも書いてとなって色々Model上で記述が多くなってくるかと思います。
しかし、最近では細かい記述はしなくてもよく
$results = DB::select( DB::raw("SELECT * FROM some_table WHERE some_col = :somevariable"), array(
'somevariable' => $someVariable,
));これでコントローラからもSQLが記述できるのでModelで記述する理由もだんだんとなくなってきているかと考えられると思います。
そうなってくるとMVCじゃなくてVCだけでもほぼいいんじゃないか？っていうのが考えです。
VCになると結局さらにファットコントローラの思想に行きついてしまいます。
とはいえ、じゃぁModelは不要って事になるので使わなくてもいいかってなるけどもライブラリとして使用することでいいじゃないかっていうのが今回のコンセプトです。
ライブラリとして使用するつもりが1つのコントローラからのみのアクセスになるってことよくあったり、一回きりの関数の呼び出しが他のコントローラからもModelを呼び出すってこともよくあります。
であれば初めから何がライブラリで何がModelに入れるべき処理っていうのを分けなくてもいいかと思いました。
モダンなフレームワークでのMVCについて懐疑的な意見のページを参照します。
ここに記載されてる事とほぼ同意です。一般的にはMVCにするときれいになるとかロジックはModelに書くべき、ロジックをModelにかけないエンジニアはまだまだ初級レベルみたいな概念がまかり通っているが、MVC自体にメリットがなければVCでもいいのではというのが個人的な意見です。
言いたいことを代替して言ってくれてるからすっきりします。
「LLのフレームワークはコードを整理してるだけ」という意見をModelとControllerの分け方を整理してるだけとくみとって解釈すると、もしコントローラで2000行ぐらいになるファイルになるのであればそれを分割してModelに分けていってもいいかと思います。
変更箇所が多そうな部分を切り出せばバージョン管理上、運用しやすくなるメリットはあるので。
共通ロジックはゴッドオブジェクトとsingle action per controllerの時にまたこの話になると思います。
POSTは全てAjaxで
<form>タグでpostすることを始めに覚える事かと思いますが、システムを作るうえでJavascriptからPOSTした方がいい理由がたくさんあります。
なので今では何も迷わずにPOSTをAjaxで行っています。
ではいつもの通りメリット・デメリットを記載していきましょう。
色々他の記事も参考にしようとしたけども、formタグとの比較でのメリットデメリットに対しての記事がなかったので参照なしに書き綴っていきます。
メリット
・サーバーに負担がかからない
まぁ、これはサーバーが多少は負荷がやわらぐかもしれないけども、作り方次第ってのも大きいのと、Ajaxにしたからといって劇的に変わるわけではないと思いますが、一般的にこれが一番初めに想起させるメリットみたいです。
・バリデーションがJSで書ける
バリデーションをJS上で書くことによってユーザーへのレスポンスをフルリロードしなくても、メッセージをエラーとしてユーザーに見せる事ができるので、ユーザーにとっても、サーバーにとっても都合がいいかと思います。中にはサーバーサイドでしか確認がとれないバリデーションとかもあると思いますが（ユーザーIDがユニークかどうか）、大部分はそうではないので大きなメリットかと思います。
・POST後の表示を考えなくてもいい
formでPOSTするとPOST後に成功したエラーになったにかかわらずそれなりのHTMLを書いて表現しないといけないです。でも、JSからではエラー内容、通常のレスポンスもJSONで返すだけで済むのでPOSt後のデザインを考える必要もないです。
それに伴ってコントローラ名を**add,**edit, **delみたいに表示はJSON, 他はHTML表示というように分かりやすく分ける事も可能になってきます。
・formタグの位置を気にしなくてもいい？
JSでは.POST時にどこのタグから取得するかを指定できるので、HTML上どこにタグ、データを置こうが関係なくPOSTできるようになります。hiddenタグでやればformでもできるのでメリットは薄いですが。。
デメリット
・コールバックを知らないといけない。
POSTした後何かしらのサーバーのレスポンスをもとにアクションを起こしたい場合はコールバック上でアクションの関数を実行しないといけないので、慣れてない人には1ステップの障害になるかもしれません。でもコールバックは覚えないとWebエンジニアって言えないくらいですね。
・どこからの実行なのかがわかりづらい
とんでもないJSファイルからPOSTを実行しているっていうケースもあるので、どこからどのように実行するかのルール決めをしないといけない。
・バリデーションをJS,サーバーサイド両方で記載しないといけない。
基本はバリデーションはJSで行って、サーバーサイドではサーバでしかチェックすることができないバリデーションのみでOKかと思います。例えば、通常のユーザーの操作以外の悪意があるようなPOSTに対して「あなたは悪意があるPOSTです」ってわざわざ言わなくてもいいので適当にレスポンスは丸めておけばいいかと思います。
ずっとWebをやっててJqueryのPOSTでやることになんら違和感もなくやってて、それで運用も問題ないので、POSTは全てAjaxでいいという結論です。
MACでOracle にアクセスした時のtips
1.マックのターミナルでの話
oracleが文字化けで激しいのでというか未だにSJISなのでターミナルから入った場合、
文字列が炸裂します。
いつも忘れるのでここでメモ
export NLS_LANG=Japanese_Japan.AL32UTF8
マックは関係ないかも
2.他のテーブルを参照して更新
oracleでは update ** from ** where ** でもできなかったんで調べてみたら違うSQLのようです。
update (
select
A.ITEM_AMOUNT_DLLR A_ITEM_AMOUNT_DLLR, B.ITEM_AMOUNT_DLLR B_ITEM_AMOUNT_DLLR
from h_mypage_history A INNER join h_sales_dt_left B
on A.SALES_ID = B.SALES_ID
) set
A_ITEM_AMOUNT_DLLR = B_ITEM_AMOUNT_DLLR
これで違うテーブルから参照して更新できます。
「テーブル移動」「テーブル複数」って検索してもなかなか出てこなかったんでメモ
MySQLからORACLEにデータを移行するまでの道のり
ORACLEがライセンスの問題で複数サーバーを立てられない。
なのでバックアップサーバーとかはなかなか立てられない。。
という事でバックアップにMySQLサーバーに使っています。
あと分析用とかもMySQLを使わざる終えないのでOracle > MySQL
のデータ移行をしないといけないという悲しい状況です。
今回はそのバックアップを取っていたデータから新しいテーブルを作成してそれを本番のOracleDBに移行するっという作業でしたがいろいろ詰まったところがあったんでメモ
・エンコードを合わせないといけない
バックアップの方はUTF8なので問題ないですが、オラクルの方はふる～～いのSJISでした。しかもエンコードを調べるSQLでの結果もわかりにくい。
SELECT VALUE FROM NLS_DATABASE_PARAMETERS
WHERE PARAMETER='NLS_CHARACTERSET';
「JA16SJIS」
見たこともないエンコードが。。なのではじめはSJISなのかEUCなのかさえわからなかったのですが、このコードでさらにぐぐると SJIS？っていう事がわかる。
なのでmysqlでエクスポートしたテーブルをUTF8＞SJISに変換しないといけない作業。
mysql> select * from h_mypage_history INTO OUTFILE "/tmp/h_mypage_history.tsv" FIELDS TERMINATED BY '\t';
,（カンマ）よりもタブの方がごみデータがすくないと重いTSVでエクスポート
nkf -s /tmp/h_mypage_history.tsv > /tmp/h_mypage_history_sjis.tsv
・NULLの取り扱いが違う
MｙSQLでは\Nっていう風に記載されているのに対し、オラクルはそういう記述の仕方ではないらしい。
なのでNULLをデータなしに変換。
sed -e 's/\\N//g' /tmp/h_mypage_history_tab_sjis.tsv > /tmp/h_mypage_history_tab_sjis2.tsv
・インポートが難しい
[~]$ sqlldr ユーザー/パスワード control=mypage.ctl direct=true
というコマンドを叩く。そのまえにmypage.ctl
というコントロールファイルを作成しないといけない。
その内容は
LOAD DATA
INFILE '/tmp/h_mypage_history_sjis2.tsv'
INTO TABLE h_mypage_history
APPEND
FIELDS TERMINATED BY X'9' trailing nullcols
(
USER_ID
)
タブテキストの場合はFIELDS TERMINATED BY X'9'
としないといけないみたいです。
あと失敗すると、mypage.ctlファイルを作成する場合は
mypage.logていうログが生成されるのでそこからエラーなどを見てデバッグするみたいで直接のコマンドからエラーが見れないっていう遠まわしな。。。
なんだかんだ3人日ぐらいかかってデータ移行ができました。
参考URL
http://blog.livedoor.jp/ncad_webdb/archives/51384321.html
http://www.shift-the-oracle.com/config/multibyte-characterset.html
http://www.oracle.co.jp/forum/thread.jspa?threadID=8008600
http://www.oracle.co.jp/forum/thread.jspa?threadID=35001617
http://www.searchman.info/tips/1150.html
http://vertex.air-nifty.com/blog/2008/10/oraclecsv-fe87.html
ORACLEのゾンビテーブル
google analytics（GA）のビューのフィルタはビュー毎に独立していない
google analyticsのフィルタ設定で次のような問題起こってしまった。
1.google analyticsの管理＞コピー対象のビューを選択＞ビュー設定＞ビューをコピー
2.コピー元のビューにフィルタ設定がされていました（今回の場合は社内からのIPを制限するフィルタ）
3.コピーして新規で作成したビューは「社内からのIPのみを許可する」フィルタを設定
4.コピー元のフィルタ設定まで「社内からのIPのみを許可する」に変わってしまった。
■過ち
コピー元ビューのもともと設定されていた「社内からのIPを制限する」フィルタを編集してしまった。正しいやりかたは新規でフィルタを作成する。
■結論
フィルタは各ビュー間で共通の設定を持っていてビュー毎に独立していない。
手習いHTML5 (3)
今回は、実際にブラウザに表示される領域での基本的なタグをいくつか覚え書きする。
■<HEADER>
<HEAD>とよく似た名称であるが、表示上のヘッダー領域は<HEADER>タグ内に収納される。
<HEAD>はページ本体の基本情報を収納しているため、<HEAD>タグもヘッダーとして表現されることが多く、非常にややこしい。
<HEADER>タグに収納された情報は、表示されるブラウザの上部に配置され、スクロールされても上部は表示を固定されていることが多い。
トップページや主要ページへのリンクが表示される。
■<FOOTER>
<FOOTER>は<HEADER>とは対照的に、表示されたブラウザの下部に配置される。
<HEADER>とは異なり、最下部までスクロールされて初めて確認されるものが多く、商標表示や各種リンクがコンパクトにまとめられていることが多い。
これら2つのタグは、</HEADER>あるいは</FOOTER>によって閉じることで機能する。
なお、それぞれのタグ内部に<HEADER><FOOTER>の構造を挿入することはできないようだ。
