Jsonの項目内の改行コードの記述方法について
サーバーサイドでは\マークはエスケープ文字としてよく利用されている為に
ついつい”\n”の状態にてJsonに含めるとクライアントサイドのeval時にエラーとなる。
なのでエスケープされる場合は”\\n”と2回つけることを忘れべからず！
もちろん多数ある場合も改行コードを上記のように置換処理をすること！
PHPの場合はダブルクォート「”」とシングルクォート「’」でエスケープされる、
されないが変わるので、どちらかに統一するのが望ましい。
これはJsonだけの話ではないが、重要なので記述！
javascript側では受け取ったJsonを展開するときにカッコで囲ってあげること！
例：var a = eval(‘(‘+json+’)’); //このカッコ追加は結構注意！
覚書（＾ ＾）
以下のようなエラーが発生することがある
File “/usr/bin/yum”, line 29, in ?
yummain.user_main(sys.argv[1:], exit_code=True)
1. yumをクリーンアップ
過去にダウンロードしたパッケージ類を削除する。
# yum clean all
大抵の場合はこれでいける。
これでいけない場合
・・・また今度（＾ ＾）
今まで色々な言語の参考書を読んできたが、肝心なことが書かれていないと思い、世の中に一言（笑）
開発者に一番重要で必要なスキルは、Log出力機能を付けることだ！
1番の狙いとしては不正エラーを捉えることが目的で、後はおまけで色々と適材適所に仕掛けて、ほしい情報を出力すればいい。
じっくりテストをしたとしても運用を開始して本番環境で、ほぼ必ずと言ってよいほど、簡単には分からないエラーが発生する。その際、確実に問題点を絞り出すことが非常に重要となるので、この為だけに仕掛けると言っても過言ではない。この機能があるとないとでは大違いである。
当たり前だが、プログラム内は目に見えない。Log出力してあれば見える形でユーザーに対し「これで大丈夫です」と説明する材料となり、自信を持って説明することが出来る。また説明する開発者もアタフタせずにすむ。（笑）
開発する場合は正常なルートを初めは作ってしまいがちだが、一番はじめにLog出力機能を考えて作成する。最近ではLog4など色々と言語にぶら下がっている出力機能もあるので自作しても良いし、既存のLogClassを使用しても良い。
機能としては、出力機能、出力停止機能、出力先変更機能は最低ほしい。フラグやPathは定数をきっておいても良い。
最低限ほしい出力内容は日時、どこから出力されたか、ステータスはエラーなのかログなのかの切り分け情報、内容と四つはおさえてほしい。もちろんそのシステムにより、必要な情報は出力する。Web系アプリならマルチスレッドでの動作な使用ユーザー情報（IDなど）も必要で可能であればDBへ出力してもいい。
このDBへの書き込みはDB接続を前提としているので接続自体に問題が発生した時に捉えられないことがあるので、基本はローカルにログを吐いて、DB接続が確認できたらDBへも吐き出させるのが有効。（毎日夜中の1時になど）
DB出力は注意が必要で、プログラムエラーのログを吐こうとしたらDB接続エラーとなることが考えられる。エラーのエラーは本末転倒になる。DB出力は十二分に確認が必要。またシステム負荷の度合をみながら設置すること。
■Logを出力するタイミング
・エラー時
・単体起動時、単体終了時
・重要な箇所（DB更新など）
言語に存在し、余裕があればThrow系と連携をとると最適になる。
本当に硬いシステムの中身はLog出力機能が充実しているものであり、不安定なシステムにはLog機能が充実していないことが多い。
これが出来て一人前？・・・当たり前（苦笑）
Outlook2007を新たにインストして数日・・・・
「あれ？メールの表示がおかしい？？？」
「改行が無くなってる？」
「なんで？？？」
「そういえば、2003の時もあったなぁ」
ってこと皆さんはありませんか？
ふとヘッダー部分をみると「このメッセージ内の余分な改行が削除されました。」のメッセージが・・・
「余分な改行じゃないんだよ、この〇ソAIがぁ」と込み上げてくるのを抑えて（苦笑）
オプション → メールオプション → 改行の削除のチェックを外しましょう！
それにしてもこの機能がJapanでデフォルトONってのはどうなの？MSさん
１．会計基準
現在、未曾有の経済危機に陥っておりますが、その中で数年前より日本でも義務化されてきた「時価会計制度」について。
アメリカがこの会計制度を導入し、他国にも半ば強制的に使用を求めてきました。それにより当時のバブル後遺症の残る日本企業はこの時価会計のおかげで倒産レッテルを張られ、潰された会社を覚えています。
しかし、今になって時価会計が「間違っていた」と方向転換の話をしております。方向転換はよいですが、時価会計のせいで潰れた会社や職を失った人たちの時間は戻りません。
２．一人っ子政策
お隣の中国では人口増加が激しいために一人っ子政策を打ち出し、実行しております。昨年、四川大地震により多くの人たちが亡くなりました。ある地域では学校だけ崩壊し、周りの家はそんなに損傷を受けなかった、このような状況もあり子供を失った親が大勢おり、一人っ子政策のために子無しとなってしまったのです。四川は農村地帯で、家族を養っていくのに親から子へ仕事のバトンタッチによって成り立っている家族が多いようです。農村地帯ということもあり、社会保障もあまり整備されておらず、老後を考えて40代前後の母親は子供を作るかどうかを真剣に今、考えているという話を聞きました。
政府は一人っ子政策を民衆に求めますが、いざとなったら政府は何もしてくれない。
２つの話から何を考えたいかというと、まずはロジックミス（想定外）となっている点がシステムと似ている。時価会計では右肩上がりの時は恩恵を凄く受けるが、いざ傾くと一気に底まで落ちてしまうこと。また、一人っ子政策で子供が大勢亡くなることが起きるとは、システムを考えた当初は思いもよらなかったでしょう。
想定していれば少しは違う流れになったと思いますが、どちらも後手後手に回り、解決方法は簡単には見つかりませんし、失った時間は帰っては来ません。
横道にそれるが、時価会計導入はバブルが弾けた日本で施行してみて右肩下がりになった時に苦い経験をしているのだからアメリカに対して「おたくも右肩上がりだからいいけど、下がり始めたら大変なことになりますよ」と逆に警報を鳴らして国を挙げて反対出来ていればとも思うが・・・当時の状況を考えると言えないかぁ
自分の道は自分で考えて進まねばならないと改めて思い、世の中のシステムも奥が深いなぁとシミジミ思いふけった。
