.htaccessで特定のIPアドレスのみアクセスを許可する

会社や自宅などの特定の場所からのアクセスは許可して、そこ以外の場所からのアクセスにはBasic認証をかけたいということがあった。

すごく参考になるページがあったのでメモ。
BASIC認証とIPアドレス制限の併用


まずは全文。

AuthType Basic
AuthName "Please enter username and password"
AuthUserFile htpasswdへのパス
AuthGroupFile /dev/null
require valid-user



Order Allow,Deny
Allow from 「特定のIPアドレス」
Allow from 127.0.0.1


Satisfy Any




これを分解していくと

Order Allow,Deny
これで一旦すべてのアクセスを拒否してる

Allow from 「特定のIPアドレス」
Allow from 127.0.0.1

これで特定のIPアドレスからのアクセスのみ許可する。
127.0.0.1とは、自分自身を指す特別なアドレスのこと

ちなみに

Allow from all //全部
Deny from example.com //ドメイン名で指定


という指定方法もあるらしい


Satisfy Any

これはID/Pass制限とアドレス/ホスト名で制限の両方が設定されている時にの動作を決めている


Satisfy Any
だったらどちらか片方

Satisfy Alll
だったら両方とも条件を満たす必要がある


参考：アクセス制限の記述(Order, Allow, Deny)

自動でサイトのテストをしたい

JMeterっていうアプリケーションがあります。
サイトの負荷テストをするためのアプリケーションです。

作成したページの表示は1人でも確認できますが、実際に本番で多くのユーザーがアクセスしてきた場合はどうなるのかってのは1人では調べづらい。
JMeterってのは、本番の様にサイトに負荷をかけつつテストすることができるアプリケーションのようです。

今のところ僕は負荷テストではなく、サイトのページの確認用に使ってる。
たとえば、webアプリケーションのシステムを大きく変更したとか、共通で使用している部分を変更したって時に、思わぬとこでエラーが出たりする。
それを1人で全部チェックするってのは難しい＆馬鹿らしい。

JMeterってアプリケーションに確認したいページをすべて登録しておいて、エラーが出ていないかどうかを判定してる

使い方などを詳しく掲載している記事があったのでどうぞ
JMeterでWebアプリケーションのパフォーマンス測定を行う

[Symfony] layout.phpを変更する

使用するレイアウトファイルをデフォルトのlayout.phpから変更したい場合は、アクション内で
$this->setLayout('new-layout');
とすればいい

↑の場合はアプリケーション/template/new-layout.phpを使用するようになる

ウェブアプリの高速化

実践・ウェブアプリ高速化テクニックという記事を読んで思ったことをメモ。

上記の記事の要点
・高速化とはプログラムの処理スピードなどではなくUser Experience！
・ユーザーが快適にサービスを利用できているかが重要
・快適→ユーザーが起こしたアクションへの迅速なレスポンス。実際の速さよりもユーザーが速いと感じることが重要
・Gmailのスターはローディングも出さずに反映する

高速化を考える際に、ユーザーのことを忘れているというのは同感。自分もよくそうなる。
処理速度をあげるってのは、計測できるという点からすると、けっこう楽。
やり方によって実際に処理にかかる時間が目に見えてへっていくからね。

それに比べて、ユーザーがどう感じてるかを考えながら作るのはなかなか大変。
作っているこっちは何十回、何百回と同じことをくりかえしたりするので、もう感覚がわからなくなったり、秒数を減らすのと違って、どういうふうにすれば快適だと感じるかというノウハウを持っていなかったりする(俺の場合ね)。

重要なのは何かしらのレスポンスの速さってことかな。

・オンマウス時のリアクション
・クリック時のリアクション
・ローディング時のリアクション

まずは一瞬でもレスポンスがないような状態をなくす。

・ローディング時のプログレスバー・読み込み完了度の表示
これはただ「Loading...」とか出ているのとは気持ちはかなり変わる。
いつまでかかるかわからないような処理は待ってもらえない。

・エラー時のリアクション
なぜエラーが起きたのかが明確に伝える
エラーの解決方法を伝える

他にも色々ありそうだなー

MVCのお勉強。太ったモデルと痩せたコントローラ

下の2つの記事を読んで、すこし理解が深まったような気がしているのでメモ
Web アプリの MVC 設計まとめ :: もやし日記
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

CakePHPを使ったMVC設計のベストプラクティスを読んで、ビジネスロジックはモデルに置くべきだと認識した。コントローラーをシンプルにしておけば処理の流れもわかりやすいだろうと。

特定のモデルに大量のメソッドが集中したり、どのモデルがどういうトランザクションを担当するのかが分かりにくくなってきて、コードの可読性は下がり、重点的にテストすべき場所も分かりづらくなってきます。
Web アプリの MVC 設計まとめ :: もやし日記

確かに機能が増えてモデルが多機能になりすぎることはありそう。
実際1つのカラムの値を取得したいだけなのに、多機能なインスタンスを作らないといけないってのもメモリーの無駄遣いかも。
あるコントローラでしか使われていない機能があるってのも気になる。

次の間違いは、Skinny Controller, Fat Modelが最良だと信じている点。
Fat ModelはFat Controllerと同様にテストはしにくいし、理解しづらくなる。ロジックはそれぞれ適切なところで実装すべきで、Fatなのはやはりよくないのです。
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

ふむふむ。やはり過ぎたるは及ばざるが如しですな、と脳みそ停止しきってるくせに理解したふりしてみる。
コントローラーとモデルの両方をテストしないと確実じゃないってことになったら、そのテストってなんなの？って感じはするな。

追記:一昔前のフレームワークなら、ControllerはWebのAPIに依存していてテストしにくいというのもあってControllerからロジックを追い出せということがよく言われてきましたが、いまどきのちゃんとしたフレームワークは最初からControllerもテストできるように考慮されています。
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

そもそも、コントローラーにロジックを置かない理由の1つがテストしづらいからだったの？
他にはどんな理由があるんだ？コントローラはロジックを置くとこじゃないってのが1番の理由だと思ってたんだが…どうなんだろう。

きっちりテストできるならどこにあってもいいってことなら、それはそれでシンプルな考え方でいいかも。で、実際にそうしてみたら、テストのやり方が煩雑になって、やっぱりどっかにまとめようぜってなりそう。

今日の俺POINT
・基本コントローラーはシンプルに。
・Fat Modelには気をつけよう
・なんでもFatは良くないよ
・Serviceってやり方もあるらしい
・2008年と2009年の記事なんで、今は変わってるかもしれん。

コントローラにたった1つだけあるドクロマークのボタンを押すと、太ったモデルがセクシーに踊りだすという解釈でいいであろうと思われる。

[cakePHP] MVC設計ってまだ把握できとらん…

CakePHPを使ったMVC設計のベストプラクティスを読んで、一度読んだだけではなにがどうなったのかよくわからんかったので、自分なりにまとめてみた。


■コントローラーが変更された点
・共通したorder指定を抜き出してモデル側で設定
・データを取得して表示するという流れは同じなので、アクションを1つにまとめた
・件数指定部分をモーフィングっぽく配列に格納
・モデルにオプションを渡して取得できるようになった
・渡されたパラメーターによって自動で処理が変わるようになった


■モデル
・並び順のデフォルト設定追加
・人気順で取得する機能追加
・特定の設定はモデル側でもっとく

■要点
・MVCではモデルが一番大事
・コントローラーはモデルとビューをつなぐシンプルな糊

・モデルに置けるものはモデルに置く
・ビジネスモデルと連携しないもの(セッション管理・リクエスト、レスポンス処理・セキュリティ、アクセス制限関連)はコントローラーに置く。(それ以外は全部モデルに置く)

参考
CakePHPを使ったMVC設計のベストプラクティス

[symfony] コントローラー内で共通の処理をまとめる

symfonyのコントローラーにはpreExecute()とpostExecute()というメソッドがある。
preExecuteはexecute～の前に、postExecuteはexecute～の後に処理が行われる。
ここに処理を書けば、コントローラー内のアクションに共通の処理を行える

public function preExecute()
{
  parent::preExecute();


  //やりたい処理
}

共通でやりたい処理をどこかにまとめとく機能もたぶんあるよね。cakePHPのビヘイビアみたいなやつとか

iPhone, Android などのスマートフォンでJavaScriptエラーをデバッグする

スマートフォンのJavaScriptのデバッグはなかなか大変。

■iPhone
iPhoneはわりと楽。
「設定」 -> 「Safari」 で「デベロッパ」をONにする
でも、エラーやconsole.logの詳細は教えてくれない。
今はMacと繋げれば、Mac側のsafariから色々情報が得られるようになった。便利。

■Android
残念ながら、端末にはデバッグ機能はなし
シミュレーターのlogcatってやつを使えばログも見れる
windowsなら
adb logcat | findstr browser
でブラウザ絡みのログだけに絞れる

参考
Androidシミュレーターのインストール



■サーバー側にログを残したい

上の方法だと、ちょっと物足りないのでJavaScriptでエラーがあった場合はサーバー側に通知するようにもできる
window.onerrorにJavaScriptエラーの場合の処理を書けばいい
引数にはエラーが起きた行数なんかもくるけど、IEの場合、あまり信頼できないらしい…

window.onerror = function(messsage, url, line){
  //ここに処理
}
俺の場合は、urlにエラーに関する情報をくっつけて、ajaxでページを渡して、読まれたphp側でログファイルに出力することにしたけど、より簡単そうなやり方がWeb+DB PRESS vol.63に紹介されてた

window.onerror = function(message, url, line){

  var param = "?message=" + encodeURIComponent(message)

    + "&url=" + encodeURIComponent(url)

    + "&line=" + line;

new Image().src = "error_log.gif" + param;

}
まあ、この場合もダミーのgif画像を用意しつつ、いろいろ処理はしないといけないだろうけど、読み込む方法としては楽そう

[JavaScript] DOMのタグ名を判定する

DOM要素のタグによって処理を分けたりすることがあります。

if(div.tagName.toUpperCase() !== "DIV"){
//処理
}

ブラウザによって返ってくるタグ名が違ったりすることもあるので、toUpperCaseで大文字に揃えてる

[cakePHP] モデルのルール

-クラス
必ずAppModelを継承して作成する

-モデル名の定義
public $name = 'モデル名';
モデルの名前を定義する
単語の頭文字は大文字

とりあえずはこれだけでAppModelにあるいろんな機能が使える

AppModelは/cake/libs/model/app_model.phpにある
中身は空っぽで、ここに追加した機能は、コレを継承する全モデルで使えるようになる。
一部のモデルでしか使わない機能はここに入れたらダメだね。

一部のモデル用に共通で使える機能はビヘイビアってを使うのがいいみたい

参考
モデル :: CakePHPによる開発 :: マニュアル :: 1.3コレクション

[Symfony] propelでgroup byする

なぜかいつも忘れるし、そもそも出来ないんじゃなかったけ？っという勝手な思い込みが発生してしまうのでメモ

propelでgroup byするには
$criteris->addGroupByColumn(カラム名);


group by して それぞれにcountするのが面倒だったはず
GROUP BY して グループごとのCOUNT を取る

[cakePHP] レイアウト・テンプレートに実行したSQLを表示する

cakePHP 1.3でやってます

まずはアプリケーションのデバッグモードを変更する
/app/config/core.php内の
Configure::write('debug', 0);
を
Configure::write('debug', 2);
に変更する。
これでテンプレートにSQLが表示されるようになる

■レイアウトを変更したい場合。
デフォルトのレイアウトを変更したい場合は、/app/views/layouts/にdafault.ctpを作成すればよい。

実際そうしてみると、デフォルトの時は出ていたSQLがでなくなった
その場合は自分で作ったdefault.ctpに
$this->element('sql_dump');
を追加する。


参考
CakePHP での実行した SQL の表示

[cakePHP] テーブルにprefixをつけている場合の外部キー・カラム名

cakePHPで外部キーを作成する場合、カラム名には制約がある。(制約以外の名前でも使用することはできる)

マニュアルより：：
現在のモデル名のアンダースコア区切りの単数形で、末尾に‘_id’をつけたものです

今回、データベースの設定でテーブル名に接頭辞をつけるようにしていた。
mmm_usersテーブルとmmm_profilesテーブルを関連付けたい。

こういう場合も外部キーにするカラム名には接頭辞であるmmmはつけない
mmm_profiles.user_id
にする