仏教事始
参考
仏教を学ぼうとする、その際に何をどうすればいいか。
経典その他、何か本やサイトで調べたり
もっと体験的な物、寺に行ったりありがたい法話を聞いたり。
人それぞれ、いろいろ浮かぶと思う。
でも、腰を据えてやるなら、どこから手をつけよう、漢字めっちゃ多いしどうしよう。何から見ていけばいいんだろう。
仏教とは何ぞや
じゃあ、まず、いろいろある中で本来的な仏教ってなにかなあ、と。
本当にそこから始めるのでいいかわからないし、やるなら別に何だっていいけど、知っておいて損はないだろうし。
仏教はまず、お釈迦様本人が伝えた物と、それにいろいろ解釈を加えたり体系的にしたりしたもの、大きく分けて２種類ある。
変容する仏教
まず、後者の方、いろいろ解釈を加えたり、体系的にしたものについて。
インドは他の哲学などに見られるように、何事も体系的にまとめる傾向がある。
仏教発祥の後、１３世紀ごろにイスラム教が広まり、また、そもそも体系的にまとめるには無理のあった、原始仏教の性質などもあり、インドでは廃れてしまった。
また、中国に伝わったものは、仏滅後１０００年以上経って体系立てられたものも全て、釈迦本人が伝えたこととしてひっくるめてしまった（大乗仏教）。
日本ではいわゆる国家の柱としての仏教（サイトには鎮護国家とあった。聞いたことある・・・）になったりした。仏教による国家安泰。
何が言いたいかというと、これらはどうも、どうも本来とは違う物になってしまった？のかもというのが、参考にしたサイトで述べられていることで
・体系的にまとめられない、お釈迦様も説明しづらいようなことを体系的にしてしまったり
・そうやって体系的にしたものと、最初の原始仏教を一つにしてしまったり
・国家安泰のための仏教になったり
そういったものは本義とは離れてしまったのではないか、ということだそう。
本来の仏教＝原始仏教を学びましょう
上にあげたようなものではなく、仏滅後１００年ぐらいに成立していく、原始仏教を学びましょう、というのがあのサイトの主張。
確かに、悟りとか救済とか、釈迦は個人個人のための教えを説いた？とでも言えばいいのか。そーゆーのとは違うよねー、と。
あれ？仏教どこいった？
ところで、インド、中国、日本のそれが変容したものだとすると、じゃあ仏教ってどこいったのさ、と。仏教っつったらそこらが本場なんだから。
原始仏教の時代にスリランカから東南アジアに伝わり、現代に至っているそうな。
じゃあ、まだ自分たちも触れるチャンスがあるね安心安心。
原始仏教の超さわりの部分
心を浄める？のが趣旨らしい。きがるにいってくれるなあ
そのための方針が八正道で、八正道と心を浄めること、合わせて四諦というそうな。
言葉なぞってもしかたないけど、まあせっかくだし。
で、なんなのこれ？
なんなんでしょうね。とりあえず、グダグダ言ってないで、掃除の一つもせえと言われそうだけど。掃除も作務といって、立派な修行であります。
家でる前には掃除はせねばなあ、と思う次第。
科学的なDebug
Udacity の 「Software Debugging」を見た
https://www.udacity.com/course/viewer#!/c-cs259/l-48648797/m-48723419
※ 日本語字幕あり
まだ前半だけど
内容は簡単には「デバッグをする際には気合と根性で調べるのではなく、仮説を立て、検証すること」
というもの
講義内では explicit debug と呼んでる手法
どういったものかというと
目隠ししながらゲームするのは無理
先生「仮説を書き出して一つ一つ確かめること。何も書き出さずにデバッグするのは目隠ししながらマスターマインド（数当てゲーム）をするようなもの」
これは覚えておこうと思った。絶対に書き出して検証しないと、無理。目隠ししてゲームできるわけがない。
そりゃパッと見て治せればいいけど、最初の５分だけにしなさい、とのこと。それ以降は仮説検証をすべき。
これがまず絶対としてじゃあ具体的にどういう風にやればいいか？
仮説を立てて検証すること
何かバグが起きていたとして
・何を期待して
・何が起きていて
この二つから →「じゃあ何がどうなっている」と推測する。これが仮説。
当たり前と言えば当たり前。
これを一個一個潰していく、というのが趣旨。
仮説の正否を確認し、仮説のリファインを繰り返す。
これらを書き下していく。
講義内では assert を入れたりして検証してたけど、必ずしも assert で確かめないといけないわけでもないだろうとは思う。
ただ、変数の中身を見たりするにも全て「何を期待してどうなってて、そこから推測したこと」これを書き出して確かめれば、それで explicit debug になると思う。
他の手法
automated simplification
再現の簡略化を自動化。手作業でやるな、と
https://github.com/vilion/udacity/blob/master/softwaredebugging/p3_delta_debugging_ddmin.py
Assertion
https://www.udacity.com/course/viewer#!/c-cs259/l-48587907/m-48691544
Assertion の使い方。不変条件について。
また、不変条件は自動で取得する。traceit を使う、だっけ
udacity/p2_bonsaikon.py at master · vilion/udacity · GitHub
具体的にはまた次回
デバッグは効率よく
よく言われてるけど、デバッグは開発の50-75%を占める、と。割合とはか曖昧だけど、要は多大な労力を要するわけで。
俺は仕事遅い遅い言われてるけど、だからってミスはしてはいかんわけで、せめて効率を上げないとなあ、と思った次第。
絶対、仮説検証の形をとらないと、効率は上がらない。これだけは確か。
この講義、半年ぐらい前には見てたんだけど今一そこがわかってなかった・・・毎回 assert するのは手間だなあ、ぐらいに思ってた。
目隠ししてマスターマインドするようなことはないようにしないとなあ、と思った次第。
続きはまた次回
SQL SERVER の system のテーブル
SQL SERVER には sys にメタデータが入ったテーブルがいろいろある。外部キーとかカラムとかテーブルとか。
外部キー制約の名前、どのテーブルにある外部キーか、どのテーブルを指してるか、テーブルはいつ更新されたかとかそんなのまである。
これちゃんと検索できると捗るというかむしろできないと詰む。実際詰んだ。速攻で終わるようなことにめっちゃ時間かかってしもうた。
いや、あーだこーだ言いたいんじゃなくて、とりあえずメモりたいんでさっさと書いてしまう。
参考にしたのは以下
さらに追記。ようやく lecture が見つかった・・・
Pluralsight Training ここの 3 の Metadata 云々の箇所。
公式の object カタログビュー
https://msdn.microsoft.com/ja-jp/library/ms189783(v=sql.100).aspx
【SQLServer】保守に便利！SQLServerでテーブル・ビュー等の情報をSQLで取得する。 | ﾌﾟﾗﾌﾟﾗ式技術系 Access流!
SQL Server システム カタログに対するクエリに関してよく寄せられる質問
https://msdn.microsoft.com/ja-jp/library/ms345522.aspx
とりあえずカラムとテーブルとロックと外部キーがらみか、そこら辺は覚えねば。
以下、ビューなどについて記載。システムテーブルは触ってはいけないそうで、ビューやストアド（訂正）ファンクションを使わないといけない。
・sys.columns の object_id は table の id が入ってる。ひょっとしたら他のテーブルもそういう物であるらしい？
・indexes と index columns と columns の object_id にはいずれも、テーブルの ID が入ってる。
これらと columns を join することで、主キーを取れる。is_primary を見る。
・ foreign_key_columns の reference_object_id は外部キーが見てるテーブルの ID、refefence_column_id はカラムの ID 。
foreign_key ビューもある。
・rock の stored もある。handler を入れると SQL が取れたりする。うろおぼえ。
hangler は dm (hogehoge) request とか session とか connection の stored からとれる。
・テーブルだけじゃなくて COLUMN_(NAME/ID)、OBJECT(NAME/ID)、SCHEME_(NAME/ID) の関数を使うと、それぞれ ID と名前の変換ができる。
※ 細かい固有名詞は合ってる自信全然ない。
うーぬ、単に SQL Server インストールするんでも苦労したした・・・
参照したところは以下
[ソリマチQ&A] データベースエンジン（SQL Server ）のインストールに失敗した場合の対処法
ディレクトリの削除もやらんといかん
Javascript の super
これ分かりづらすぎるやろ・・・
http://jsbin.com/wejawu/2/edit?html,js,console,output
この constructor の Backbone.Model.apply(this, arguments) が super の呼び出しと。
あんまやらないだろうけど。やっぱ何が分かりづらいって Model はただの関数ってところなのかなあ・・・書いててパッと見はそうは見えない。
まあメモっておこう
jQuery につっかかったので
職場でまたも突っかかる。jQuery は勘が必要かもしれない。
よーしパパ jQuery がんばるぞー
・・・いや、だから、こういう移り気なのが一番まずいんだけど。やっぱ web 系だか何だかよく分からん正体不明なスキルになっちゃってると、いざ 純粋 web に来るともう覚えないといかんことだらけやの。
画面系はつっかかりやすいから、画面系やろうと思ってたんだっけ。
でも LPIC 取ろう言われてそっちやってたり、デザインパターンの本が思ったより面白かったりでウロウロしとる。
まあいいや。またしばらくは画面系の学習に戻ろう
とりあえず、メモとして
・promise は「resolve とかを呼べない deffered みたいなもの」
・jQuery オブジェクトを Deffered に放り込んで promise を取得できる？だっけ。
で、描画完了時の処理を実装できる
こういうの、去年も調べたんだけどなかなか載ってない・・・日本語の資料は結局いいのなかったな。
Pro jQuery とか調べてたな。
ともかくつっかからんようにせねば・・・
Design pattern
いやこりゃ評判以上にええぞ
有名なもんだし、ちょっと見て「何かいろいろ書き方ばっかり変えててオサレなつもりなんかな」とか思ってて Head First シリーズって全スルーしてたけど、いかんかったな。
なんだろ、結城先生のデザインパターンの本は読んでたんだけど、あっちも綺麗にまとまってて、いろいろライブラリも使ってるしで、とりあえず理解したとか思ってたけど
Head First だと失敗パターンだの何だのといろんな切り口から見せてくるから、多方面から考えることになって、考えてなかった部分が見えてくるっつーか。
いやいや、こりゃいいんじゃないか
まだ始めの方であまり進んでないけどとりあえず思ったこと書いてみると
まず設計するときは、処理ごとの関係性を考えるべき。どういうまとまりごとに処理があって、お互いは1 対 1 なのか、1 対 n なのか n 対 n なのか。
strategy は全体の中から一つの組み合わせを選びとるもので、おのおのは１対１になる。で observer が 1 対 n か。とりあえずこんなんか。
あと、関係性も何も考えず、とりあえず、一個の継承関係に収めてしまうってのは悪手。影響範囲とか限定できないぐっちゃぐちゃのコードになったり、逆に全然共有できなくなったりする。
これは自分でもう分かってたつもりではあったけど、じゃあこないだ書いたコードはどうなの？本当に大丈夫？関係性とかすぐ言える？ってーとあまり自信ない・・・
序盤も序盤だし、とりあえず忘れる前に書いておくか、と。
あ、思ったけどこれちゃんと買うか・・・
Linux を今更お勉強中
いわゆるブログ始めました、的な、一発目
特に大層なことも言えませんが「勉強したことは残しましょう。逆しまに言えば書いて output がないとやったとは言えません」などと言われさらに「blog は義務」とかよく分からないことを言われた。
まあいいや。
なのではてなに実は登録してたらしいので ID を引っぱりだしてきて書いている。
ほぼ味気ない備忘録になるんだろうか。
なんだろう、ちょっと備忘録として残したい事と言えば、ディスクリプタにリダイレクトして何も出さないようにする、とかだろうか
ls /home /hime > /dev/null 2>&1
これが標準出力を捨てて、かつ、エラー出力を「標準出力にしている箇所に入れてしまう（この場合は /dev/null）それにより、エラーも出さない」という意味なんだそうな。
やってるのはここ（有料）
やっぱ英語聞き逃したりするからちょいちょいググるけど
さて LPIC の 1 は取れるかいな
訂正
義務、じゃない「命令」だ。ひどい。
