来月来るはずの請求が今月来たことにより
貧乏男子なボクです。
ちょっとしたことで、RSSを触ることになりました。
規格が定まってるので、自前でパーサでも作ろうと思った矢先に超便利な関数があるもんですねぇPHPには。
まー、PHP5でしか使えませんが、
simplexml_load_file()
ってのがあります。
RSSのXMLをパースしてオブジェクトに格納してくれるとかなんとかそういうやつです。
$rss=simplexml_load_file('http://exanple.com/rss.xml');
とかするだけで、RSS情報がとってこれちゃうわけです。
あとは、
$rss->channel->title
とか駆使して表示してあげればいいわけです。
中身がちょっと変わるけど、Atomへの対応もいけそうですのん〆
ガム食べ過ぎです。姜子牙です。700円くらいの大きいサイズのボトルガムが2,3日で無くなります。
ガムは無くなったらコンビニへ行き買って補充します。常にガムがあることが重要。
[Mr.マカー](#ﾟДﾟ) < 「業務時間中に行くんじゃない。」
[姜子牙]（;’-') < 「あ、すいません・・・。」
で、私のガムは我慢すればいいのですが、サーバは必要な物が無くなるとそれまでと同じ動きをしてくれなくなります。
車に使うガソリンほど目に見えて減る物は無いのですが、サーバでも消耗して放って置くと無くなってしまうものもあります。
一つは摩耗するハードウェアや物理媒体。バックアップメディアとして使用されるDAT・LTOであったり、定常的に使うようであればCD-Rやプリンタのインク・紙なんかが該当します。
無くなった際には速やかに補充できるように予備なんかを準備する必要がありますし、それらの発注や在庫管理なんかが必要になります。
[姜子牙]（*’▽’) < 「ガムもここに・・・」
[べきこ] (´ー｀) < 「入らないですね。」
[SELLCA](￣ o￣) < 「どんだけガム好きなんですか。」
もう一つは期限付きの申請・ライセンス。ウイルス対策ソフトのアップデートライセンスであったり、サーバ証明書、ドメインなんかが該当します。
こちらは補充というより更新手続きなのですが、良くあるのが構築時点と担当者が変わり必要な更新手続きがなされなかったり、期限切れで使用できなくなってても気づかなかったりすることがあります。特にドメインなんかは、下手をすると余所に使われたりしてしまうことがあるので、何の申請をいつまでにしなければならないのかを構築時点で明確にしておくと、いざその時になって慌てずに済みます。
[チョコボール](o・。・o) < 「SUICAの定期が切れてて、気づいたらチャージが減ってるとか。」
[姜子牙]（;’-') < 「定期切れてるのわかってるけど朝急いでると買えないんだよね・・・。」
期限切れなんてわかることじゃん、とは良く言われたりするのですが、申請スパンが年単位だったりするとその当時の担当者がいなくなっていて、わからなくなってしまうことが多いのですね。
(担当者が健在でも忘却の彼方になっていることもありますが・・・）
単にシステムを維持することは出来て当たり前ではあるのですが、その当たり前も案外大変だったりするのです。一つ一つは大した作業ではないものの、その全体に関連なく散らばっていることが多いため気づいたらあっちもこっちもなんてことが起こり得たりするのです。
[姜子牙]（*’▽’) < 「継続は力なり。」
[かーつん](#ﾟДﾟ) ／ 「意味が
[のびーにょ](#ﾟДﾟ) ＼ 違う！」
はい、行ってきます。
はいおつかれ
今日は基本的なこと行きます
大前提です。
error_reporting(E_ALL);
ini_set("display_errors",1);
共通で読み込むコンフィグファイルなんかの先頭に必ず入れましょう。
ｺﾚすることによってサーバの環境にある程度依存しない形でエラーログが画面に出ます。
これ
error_reporting(E_ALL);
絶対にE_ALLで
デフォルトは
E_ALL ^ E_NOTICE
こうなってるけど 絶対E_ALLで
NOTICEって別にエラーじゃないけど潜在バグになりやすいから 保守しないならそれもあり
ただし遅くなるよ(どの程度か知りませんが)
基本的に全部のNotice Warningを消してからサービスイン これ基本
本番環境なら
ini_set("display_errors",0);
これでOK
このあたりはURL等で自動的に判断できるとかっこいいかも。
後register_globals はoffにすること
magic_quotes_gpcも当然off
php.iniで指定した方がいいけど、他のコンテンツに影響与えそうなら
.htaccessでもいいので以下を追加
php_flag register_globals Off php_flag magic_quotes_gpc Off
次
incファイル系(設定ファイルとか)は絶対にドキュメントルートより上に配置すること
サーバの設定上不可能な場合は
<files ~ ".(inc|txt|log)$"> Deny from all </files>
とかを.htaccessで指定して拡張子単位で読めないようにすること
お兄さんとの約束だよ！
こんぬつわ。かーつんです。
皆さん報連相ってご存じですよね。
報告・連絡・相談のビジネス基本３原則みたいなものです。
大きく言うと企業レベル、小さく言うとプロジェクトの各チームレベルで
これらがまともに機能しているのと、そうでないのとでは運営や進行に雲泥の差が出ます。
まぁ報連相それぞれタイミング的なものがあるんで、
報連相を行う相手次第で間を考える必要があり、
いきなり完璧を求めても無理だと思われるわけですが、
報連相を行うときに自分で意識して行っているか。というのがポイントです。
以下にどういうときに行うべきなのか、抜粋して書いてみたいと思います。
【報告】「主に部下が上長に対して行う」
・(決定事項に対し)変更が生じたとき。
⇒ これを怠ると、上長の現状把握が遅れ、結果的には
自分にその遅れた分の時間短縮が求められることが常です。
・結果報告(長期場合は中間報告)
⇒ 現在までの作業が終わり、次の作業指示を仰ぐ場合や、
現状の進捗具合を知らせることでアドバイスを聞き出す時などに使います。
【連絡】「主に上長から部下に対して行う」
・情報共有
⇒ 企業又はプロジェクトの決定事項などを端的に伝える。
「～だと思います。」とか、「～だったはずです。」と伝えるくらいなら
伝えるのを控えた方がよいです。
曖昧な連絡は誤解を生み、
後々「あのときこういった。」とか、「こんな風に受け取ったんだけど。」という
トラブルの温床になります。
【相談】「相手はまちまち」
一番タイミングを計るのが難しいと思います。
しかし、一番重要ともいえます。
自分が詰まったとき、問題が発生してしまったとき、
定義が曖昧なだけに行いにくいとも思いますが、
自己解決したと思いこむこと程恐ろしいことはありません。
人の動きから学ぶのが一番だと思いますが、
適度に取り入れることにより自分の間違い・勘違いに
気づくことが出来たり、情報の精度を高めることが出来ると思います。
但し、忙しそうな相手にちょっとしたことを頻繁に聞くと
確実に嫌われたり怒られたりするので、
ある程度まとめて一度に質問したり、
一度聞いたことは二度聞かずにすむようにメモを取りましょう。
とまぁ、こんな感じで、報連相を実施することで、
運営や進行をスムーズに進める事が出来ると思います。
細かい方法は企業やチームで風土があると思いますので、
臨機応変に。と言わざるを得ないですが、
「明らかに間違ってる！」という風土が出来ているようなら、
容赦なくブチ壊してしまいましょう。
基本に忠実に且つ臨機応変に、
自分たちに合った報連相を策定していくことが、
成功の秘訣ともいえると思います。
報連相。何それ？みたいな企業は、
早々に辞めてしまうのが得策かもしれませんね。
以上。か＾－＾つんがおおくりしました。
こんにちは
のびーにょです。
さて、表題の件について少し書きますか
ドコモの端末でｉモードIDが取得できるようになったのがつい最近ですよね
さて、そのｉモードIDですが、HTTPS通信時には取得できません。
何故か 理由は以下
・ドコモの端末にSSL証明書が標準でインストールされている
・暗号化はゲートウェイでなく端末上で行われてから送信される
・iモードIDはドコモのゲードウェイで付与される物なので暗号化通信時にはゲートウェイで『guid=on』が付いているかどうか判断できない
ってことです。
ちなみに公式にもきちんとそのあたりは明記されてます。
小さいけど。
ちなみにHTTPS時に『guid=on』ってやっても
X-DCMGUIDヘッダは当然空です
で、ならどうやってHTTPS時に端末を識別するかってことですね。
ちょっと凝ったサイト作るとHTTPSなんて割と使う可能性が高いので知らない人は注意です。
別途セッションID生成してｉモードIDにひもづけてサーバ側で保存。
必要情報を別途付与したセッションIDより引き出すって感じでしょうか。
もしくはHTTPS時にはｉモードIDを暗号化して『guid=on』ではなく『guid=XXXXXXX(暗号化した値を直接引数として渡す)』とかで渡して、受け取った方で複合化したIDを利用 とかですかね
あんまりどっちも変わらないですけど
どっちもハイジャックの危険性ありますよね
URL保存してれば ですけど
通信途中のデータは盗聴などの危険性はないと思いますが(HTTPS時なので)URLパラメータにてGETで送信した場合はユーザが任意に保存できる可能性があるということです。
できる限りそういう場面ではPOSTを利用し、ユーザの目に触れないようにしたいものですね。
HTMLソース見られれば一緒ですけど。
その時点のURLをユーザが公開するかしないかはそのユーザの責任なのでこちらの意図する部分ではありませんが、なるべくそうなっても大丈夫なようにワンタイムセッション的なものを工夫してあげた方が良いと思います。
ちなみに公式のuid取得部分でも似たようなものがあります。
それも当然HTTPS時には取得できません。
まぁ端末送信時より暗号化しているってことなのでしょうがないっちゃしょうがないんですけどね・・・
HTTPSで思い出しましたが携帯電話で利用する場合のSSL証明書って一昔前はVeriSignのものしか使えませんでした。
何故か
ふるーーーーーい端末ではそこ以外のルート証明書を搭載していなかったから
最近だと割と大丈夫だと見た記憶があります。
まぁ、その辺も含めて携帯電話のWebってそれなりに奥が深いんですよ？