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の取り扱いが違う
MySQLでは\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>の構造を挿入することはできないようだ。
Linux テクニック
その1 ディレクトリサイズを知りたいコマンド
フォルダ・ディレクトリのサイズを一覧で出したい時のコマンド
意外とぐぐっても出てこないんで記載しておきます。
du -sh
例:
du -sh /var/www/forum/*
14M /var/www/forum/app
4.0K /var/www/forum/artisan
16K /var/www/forum/bootstrap
4.0K /var/www/forum/Capfile
4.0K /var/www/forum/composer.json
120K /var/www/forum/composer.lock
1.8M /var/www/forum/composer.phar
36K /var/www/forum/config
816K /var/www/forum/lib
4.0K /var/www/forum/phpunit.xml
51M /var/www/forum/public
8.0K /var/www/forum/README.md
4.0K /var/www/forum/server.php
59M /var/www/forum/vendor
その2 ログを見るコマンド
ログをLinux上で見るときはおなじみのtail コマンド等があると思いますが、それぞれメリットデメリットがあります。
そこで一番個人的によく使うコマンドはlessです。なぜかという理由を記載しながら書いていきます。
・tailコマンド
デメリット
tailコマンドは上ボタンでそれ以上見れない
引数がややこしい
あとtailfに比べると遅い
メリット
行数を指定できる
リアルタイムで監視できる
tailfコマンド
デメリット
上ボタンでそれ以上見れない
メリット
tailに比べると早い
なのでリアルタイム監視をしたい時はtailfコマンドをよく使っています。
・viコマンド
デメリット
遅い
メリット
編集できる
大量のログを見るときはviだととても遅いので見れない場合が過去にありました。
編集できてもログファイルなのであんまりいみないですね。
・viewコマンド
デメリット
編集できない、なので大事なファイルをいじるときはメリットとも言えるかも
メリット
特にない?
・catコマンド
大量ログのファイルをcatすると考えたら恐ろしくてできない。
・lessコマンド
デメリット
編集できない
メリット
高速
自由にスクロールできる
なのでlessコマンドでいいんじゃないでしょうか?
その3 文字化けに困ったら
viによるShift-JISのファイル開き方
OracleがSJISメッセージをだし、文字化けをするのでsjisの開き方とか少々便利かと思い、念のため記載。
その後、基本viでは直接編集はできないコマンドモードと呼ばれる状態でファイルを開いており、【:】を押すとコマンド受付になる。
:eはファイルをオープンする命令で++encで文字コードを指定できる。