「スキーマ」を含む日記 RSS

はてなキーワード: スキーマとは

2017-06-12

CSVテロ

上司accessCSVを取り込めないと騒いでいる。

そりゃそうだ。ファイル名にドットが入っているからな。

"定義XMLによるスキーマ確認が失敗しました。XMLドキュメントの行 | にエラーがあります。"というエラーメッセージが出るからな。

ふふ。苦しめ苦しめ!わしは帰り増田

2017-05-25

最強の思考停止センテンス~「Railsから」その1(…続くのかよ)

(Railsに限らないけど)DBスキーマだけでアプリ仕様表現できていないようなスキーマ設計やめてほしいんだけど。

「○○というrails向けのgem使うと勝手スキーマ設計してくれたうえでこういうことできるんだ」(スキーマだけでは表現できていない制約をrubyコードで実現するタイプgemみたい)

…それアクセスするのrailsだけじゃねーんだけどみたいな、てかそういう不誠実なgem公開してるやつプログラマーになる前に(贅沢いわないから)情報系の学校で直してほしいんだけど(って化学系の学校出身あほな僕につっこまれてるの恥じてほしいんだけど)

なんでDBだけでちゃんと仕様表現できないかな(じゃなくてそもそもしようとしないかな)?みんな大好きマイクロサービス考慮すれば(僕が今担っているアプリはそのマイクロサービスの部類)「Railsから」は成り立たないと思うんですが?…僕がおっさん過ぎて気にしすぎなのかな?…であれば僕も気にせず「いや、僕おっさんからそれ気にくわねーんだけど」と誠実に対抗するのが正しいのかな?

2017-01-09

「よくわかる社会心理学」の読書メモ

下記書籍を最小限読書した。読書時のメモを以下に記す。

小口 孝司 (監修),"史上最強図解 よくわかる社会心理学",ナツメ社,2013.


人は社会的存在であることを前提
パーソナリティ心理学
性格心理学
心のなか 3つのシステム
 自己概念
  自己評価
  自尊感情
 認知
  状況やできごとへの認知
  他者への認知
 感情
  情動
  人ならではの高度な感情 社会的感情
関係
 心の遺伝子
 行動
人には必ず自分について知りたい欲求がある
 自己査定動機
自己概念
 個人的アイデンティティ
 社会的アイデンティティ
自己
 主体的自己
 客観的自己
  物質精神社会的
作動自己概念
 意識に上ってる自己概念
 状況や相手によって常にかわる
自己スキーマ
 現実 ありのまま
 理想 こうありたい
 義務 こうでなくては
 可能 そうなれるかもしれない
気になる異性に好かれたい → 理想自己選択
人は常に他者との比較によって自己評価
 社会的比較自分は良い、価値ある人間だと思いたい 自己奉仕動機
自分に甘口
 自己高揚動機
 自己防衛動機
平均以上効果
上方比較 私もあんなふうになりたい
下方比較 あの人よりはできるはず
自尊感情はほどほどがいい
ローゼンバーグ自尊感情尺度
 俺 27
 10〜50
 40以上 高め
 20以下 低め
潜在連合テスト
日本 謙遜を美徳
欧米 自己アピール 評価される
自尊感情を維持のために無意識心理作戦
セルフハンディキャッピング
栄光認知評価
 倹約
 バイアス協和
都合良しに目を向け、悪しにはつぶる
ヒューリスティック処理
 代表性
 利用可能認知評価のさい、何かに原因を求める
 原因帰属
  内的、外的
初期カテゴリー化
興味があれば深掘り
ステレオタイプ
個人に対するステレオタイプ
 2次元
  能力 優劣
  温かさ 温冷
解釈レベル理論
 時間的 心理的距離によって物事の捉え方 異なる
  長 抽象的 高次解釈 why  大目標達成できるが、理想高すぎで実行できない
  短 具体的 低次解釈 how 実現性高いが、目先しか見えない
恋愛
 高次解釈 崇高 理想現実恋愛しにくくなる
 低次解釈 肉体だけ
使い分け重要
コントロール可能
情動
 喜び 悲しみ 驚き 恐怖 怒り 嫌悪
 生理的変化 伴う
 重要事態に気付くため
社会的感情
 社会生活を営む人間のみ
 社会生活を円滑にするため
 愛 友情 感謝 誇り  → 助け合いを促す
 疑い 嫉妬 正義感 罪悪感 恥 → 集団内の裏切りを防ぐ
感情役割  命の危険から身を守りつつ、社会生活を円滑に送れる
感情 脳内無意識大脳辺縁系 扁桃体 大脳皮質
気分一致効果 良い気分の時は良い記憶を思い出す
感情感染
感情を適度にオープンにすると健康になる
感情コントロール理由
 合理的判断するため
 疲れやストレスを避けるため
 まわりの人によく思われるため
 社会にうまくなじむため
感情 あらわにしすぎも、抑制しすぎもよくない
紙に書いて表出する筆記療法
 感情抑制による健康への害を防ぐ
 1日15分以上 静かな場所で 誰にも見せない
 状況、感情を整理 いやなことへの慣れ できごとの解釈が変わる 抑うつ感がなくなり 免疫力もアップ
心の特徴は遺伝子で受け継がれる
進化心理学
助け合い社会行動
適応的かどうか
適応的でないと淘汰されやすい


以上

2016-12-19

PHPってダサいよね〜イケてないよね〜

あたし、Rubyやってるの。

Ruby on Railsっつーフレームワークね。

まじイケてるから

もうね、全部スッキャッフォッルドでできるし、アクティブレコードだしマイグレーションスキーマロードちゃう感じ。

ジェッムもたくさんあるっていうかー。

デヴアイスとかつかうと、SNSとのオッスウ認証が楽ちんちん

ターボリンクがいけててジエイクエリもすっきり。

最高だよねRails

PHP?だっさーい。東京で言うと八王子みたいな感じ。

2016-11-01

退職なさる先輩へ

近々退職なさる先輩へ、後輩からアドバイスです。

インデントや空白の有無にはきっちり規則性をもたせましょう

タブとスペース混じりのインデントなど、見るに堪えません。

きっちり規則を決めてコードを書きましょう。

Gitコミットメッセージをちゃんと書いてください

updateやfixなど英語単語だと何が変更されたのか非常にわかりにくいです。

あと職場英語圏の方はいなかったので無理に英語を使う必要はないと思います

手動でサーバを構築しないでください

環境再現することやサーバの中身を把握するのが困難になります

世の中にはAnsibleやItamaeなど便利なプロビジョニングツールがあるので是非使ってみてください。

手動でDBスキーマを変更しないでください

開発環境と本番環境で食い違いが生じてエラーが発生していましたよね。

DBマイグレーションツールを使うのをオススメします。

N+1問題などボトルネックになりやすい部分は気をつけましょう

キャッシュを設けても遅くなるものは遅くなるのです。

クエリの発行数や計算量など意識してみてください。

エラーが直ったかどうかはきちんと確認してください

動くかどうかも確認せずに「直ったよ」と嘘をつかれても他人迷惑しかなりません。

テストコードを書ければ良いのですが、最低限手動でもいいのでご自分確認してください。

コードドキュメント仕様は一致させてください

利用する側の人はドキュメントを見るので実際の挙動と異なっていると困惑します。

整合が起こらないように気をつけてください。

HTTPステータスコード意図にあったものを返しましょう

GETしただけなのに201を返すなど意図にあっていないものがありました。

ステータスコード意味を調べてよく考えてみてください。

他にも言いたいことは沢山ありますが、あまり長くなるのも迷惑かと思うのでこの辺でやめておきます

先輩は技術知識はたくさん持ち合わせていましたが、どうにも技術的に他人を思いやる文化を持ち合わせていなかったように思いました。

上記の点を直すことによって、そういった文化を養うことがエンジニアとしてのステップアップにつながるはずです。

次の職場でのますますのご活躍をお祈り申し上げます

2016-10-12

ぺるん氏とddrdaisuki氏の喧嘩

ぺるん氏 以下、ぺ氏

http://eroge-pc.hatenablog.jp/entry/2016/09/12/210000

ddrdaisuki氏 以下、D氏

http://possession.hatenablog.com/search?q=%E7%8C%AB%E7%AE%B1

二人の喧嘩を見た。

他人喧嘩コメントするほど不毛ものもないが第三者目線必要かもしれないとD氏が書いているので

第三者として書かせていただくと…どちらにも相当に非があるとしか言いようがない。

どうもこのお二人は過去にも因縁があるようで積り積った鬱憤が爆発したようである

あくまでも私の目から見た今回の顛末である

ぺ氏がランス03の感想を書く

D氏がツイッターで叩く

ぺ氏がぶち切れる

という流れである

感想なんて好き勝手に書けば良いのであるからいくらまらない感想だったとはいえ、D氏が叩けばぺ氏が気分を害するのは当然であろう。

もちろんつまらない感想をつまらないと書くのはD氏の自由ではあるものの、発端はD氏が悪いと思うしぺ氏の方の肩を持ちたい気分である

これで終わりにできればこれほど簡単な事はないのだが、喧嘩が進めば進むほど私にはぺ氏の株が下がっていく一方なのである

まずは書き方。非常に攻撃的な書き方である

内容自体はD氏もぺ氏も共に相手喧嘩を売っているのだが、D氏が慇懃無礼な書き方でちくちくと攻撃しながらもランス03の感想の書き方を問題にしているのに対し

ぺ氏はD氏をお前と呼び、人格攻撃積極的に織り交ぜている。これは非常に印象が良くない。

たとえD氏がクズだったとしても、ぺ氏がD氏よりもまともだという事にはならない。そもそも人格問題はあまり関係がなく、感想問題のはずである

少なくとも

[私の感情感性が未熟なことを説明せずに滑稽だと語られてもどこにも妥当性がないんだが?]

というぺ氏の文章に関しては、この喧嘩を見る限りぺ氏の感情が未熟な事は一目瞭然である感性は知らない。

ぺ氏はD氏に主張の論拠を求めているが、これもよくわからない。

第三者から見て、D氏のこれは主張ではない。単につまんねー…という文字どおり便所の落書きレベル悪口である

それがウザいというのはよくわかるが、便所の落書きに対して論拠を事細かく求めるのはあまり意味がないように思う。

D氏はぺ氏の感想をつまらないと言い、ぺ氏はなぜつまらないのか理由を挙げろと怒る。

それに対してD氏は一応つまらない理由を挙げている。しかしぺ氏は納得せずに怒り続けている、というのが私から見た今回の流れである

D氏の挙げた理由はぺ氏の感想方向性とは明らかに異なるものであり、ぺ氏がそれを受け入れないのは客観的に見て当然だと思う。

さらにぺ氏のランス03の感想は、少なくとも万人が読んでつまらないと判断するような酷いものではない。

誰か1人でも面白いと思う人を連れてこいとD氏は仰っていたが、私は面白いと思ったし、他にも面白いと感じた人はいるだろうと思う。

D氏の発言は「俺にはつまらなかった」以上の意味はない。

はいえ、D氏はD氏の価値観に従ってきちんとつまらない理由を挙げている。

それに対して、まともな根拠反論もできずたじたじになっているというぺ氏の反論は、的を外しているように私には映る。

気に入らない人間から悪口を言われて怒りにまかせて逆襲したものの、予想以上に手ごわくてたじたじとなる、だが負けず嫌い性格で後には引けないぺ氏…という方が私の印象に近い。

喧嘩の発端は明らかにD氏が悪いのだが、議論の筋を読めば読むほど、ぺ氏の論のおかしさの方が目立つ。

自分以外のランス03のダメ感想を数え上げて、なぜ自分に対してだけ批判をするのかといった逆ギレなどは書いていておかしいと思わなかったのか。

ネット存在する全てのダメ感想を叩いてからでないと、ぺるん氏の感想を叩けないというのはムチャクチャな話だ。

便所に悪口を書いた相手に対して、立証責任が云々というのも非常にバカげた話である

元々喧嘩を売りに行ったのはD氏なので、D氏の肩を持つ気もあまりないのだが…。

余談

ぺ氏の過去記事を読むと

http://eroge-pc.hatenablog.jp/entry/2016/08/17/070000

http://sessions.hatenablog.com/

http://bern-kastel.hatenablog.com/

ぺ氏自体積極的他者感想へと攻撃を行っているという驚愕事実が判明する。

俺は好き勝手感想を書くが皆の感想尊重する、だからお前らも文句を言うな、ならばわかるのだが

俺は好き勝手感想を書くし、気に入らない感想は存分に叩く、だけどお前らは文句を言うな、という態度なのである

自分他人感想にどんどん攻撃を仕掛けていくのに、自分他人から攻撃されると頭に血を上らせてしまう。

これは少なくとも私から見れば、大いなる矛盾である

あまつさえ他人への悪口を裏ブログに堂々と書いて、悪びれもしない。

更に言えばD氏は問題にしていないようだが、

ぺ氏が普段語っている外部文脈を排して作品を虚心に見つめるという内在的読解とは、作家時代性、商業主義声優俳優、などなどを外部情報として切り離し、作品のもの…たとえばランス03という作品のみを

先入観なく捉えて語る行為を指すのではなかったか

http://eroge-pc.hatenablog.jp/entry/2014/11/22/120000_1

http://eroge-pc.hatenablog.jp/entry/2014/04/26/222449

ひょっとしたらぺ氏の主張を私が読み違えているのかもしれない。

しれないが、もし私が読み違えていないのならば、氏のランス03の感想は「戦国ランス」といった別作品存在や「ランスらしさ」といった外部情報スキーマ積極的に取り入れた感想になっている時点で

氏の普段の主張とは異なったものに仕上がっているように思う。

なお、氏の普段の主張と異なっているからと言って悪いレビューかといえば私はそうは思わず、なかなか楽しく読んだことを白状するが

少なくとも氏の普段の主張と異なっているのだから普段の主張自体問題といえば問題になるのだろう。

更に言わせてもらえば、過去因縁云々に関してもそうだ。

人間なのだから、気に入らない相手に対して厳しく当たってしまうのは仕方のない事である

しかしぺ氏の普段の主張は前述した通りだ。ならば、作者=テクスト主=D氏という外部文脈、もしくはスキーマを排して文章を虚心に読み込んで対応するのが筋というものではなかろうか。

D氏がクズであることやD氏との過去因縁という外部情報を、今回のD氏のテクストと切り離す。

特に争点にはなっていないはずのD氏の悪行=外部情報積極的攻撃している現状を見るに、

ぺ氏が普段声高に唱えている内在的読解の質についても疑問が生まれしまう。

他ならぬぺ氏自身が、[製作者の人間性と絡めた作品批評は最も唾棄すべきもの]だと言っているではないか

ならば[ツイート主の人間性と絡めてツイートを読み、判断すること]は唾棄すべきことではないのか。

[物語解釈障害であるスキーマに対抗するには]、と書いた本人が、[テクスト解釈障害であるスキーマ]に嬉々として身を委ねているのはどうしたことだろう。

気に入らない人間テクストだというだけでこれほど否定的に反応する人間は、気に入らない作家作品に対しても、先入観を持って読んでしまうのは自明の理

外部情報に踊らされないというのは非常に難しい事で、ほとんどの人間には出来ないと思うが、

ましてぺ氏にそれができるようには全く思えないのである

その辺りのところを、ぺ氏が説明してくれると有難いなと思うし

その辺りのことが説明できないようでは、残念ながら氏のお題目は見かけ倒しと判断されてしまうだろう。

D氏はD氏で、つまらない感想につまらないと述べるのは自由だとは思うけれど、それが相手の目に触れれば怒りを買う事もあるだろう。

ぺ氏ほどの理不尽さは感じないものの、D氏が他人に対して厳しい物言いを何度もしているのは再三目にしており、それ自体

第三者としてはなるほどと思わされる事もあるし面白いとは感じるものの、自分がその標的になったらと考えると辛い。

もし私が同様の絡まれ方をすれば、ぺ氏のようにまくしたてたりはしないだろうが、煙たがってブロックぐらいはするかもしれない。

厳しい読者、というのは欲しい人にとっては得がたいものではあるが、のん気にてきとーな事を書きたい者には歓迎されないだろう。

ぺ氏の感想の行き詰まり危惧するならば、もう少し別のアプローチがあったはずである

結論 どちらも怖いです

2016-09-24

PHPってダサいよね〜イケてないよね〜

あたし、Rubyやってるの。

Ruby on Railsっつーフレームワークね。

まじイケてるから

もうね、全部スッキャッフォッルドでできるし、アクティブレコードだしマイグレーションスキーマロードちゃう感じ。

ジェッムもたくさんあるっていうかー。

デヴアイスとかつかうと、SNSとのオッスウ認証が楽ちんちん

ターボリンクがいけててジエイクエリもすっきり。

最高だよねRails

PHP?だっさーい。東京で言うと八王子みたいな感じ。

2016-07-21

PHPってダサいよね〜イケてないよね〜

あたし、Rubyやってるの。

Ruby on Railsっつーフレームワークね。

まじイケてるから

もうね、全部スッキャッフォッルドでできるし、アクティブレコードだしマイグレーションスキーマロードちゃう感じ。

ジェッムもたくさんあるっていうかー。

デヴアイスとかつかうと、SNSとのオッスウ認証が楽ちんちん

ターボリンクがいけててジエイクエリもすっきり。

最高だよねRails

PHP?だっさーい。東京で言うと八王子みたいな感じ。

2016-07-10

memo

書籍より

Web + DB vol.92

データ分析の基本アーキテクチャ
フレームワーク比較評価

10年戦えるデータ分析入門

SQL中心アーキテクチャの3つの
SQL中心アーキテクチャの3つの条件
tips
  • DWH層を標準ライブラリのように考えて構築するとよい.
    • 「購入の可能性があるユーザ一覧を表すビュー」をDWH層に持たせるなど.

2016-05-17

40代後半以上のプログラマは糞

CTO含む

人によるとは思うけど、俺が関わった会社プログラマの年齢の傾向から言うと全員あてはまる。


理由

過去の栄光を引きずり過ぎ

過去にそれで納品したか、褒められたかしらないけど、遺物を自慢しすぎ

今の時代にそぐわないプロダクトや、フローを自慢気に話されても何の得にもならない

自動化とか意味ないでしょ、ドキュメントありゃ誰でもできるよ、DBマイグレーション?めんどくせえ、スキーマダンプ管理しろよ」

はあ?どんだけ時代に逆行してるんですか?CTOがそれいっちゃオシマイでしょ。時代の流れ読めないの?

そう言ってるヤツのおかげでどんだけチームが苦労してきたと思ってんだよ


PHPとか誰でもできんだからフレームワークかいらないでしょ、そんなの使わずにスピーディに仕事しろよ」

はあ?ひとりでやってろよ

口は達者だけど、svngit 使えない。svn も使いたくないけど。

誰かの書いた独りよがりコードのせいで、リリースはだいぶ辛かったりする。

それが最近自動化や、フレームワークのおかげで、リリースの負荷は軽減されてる。それを全然鑑みないのはマジでクソ。


技術力はひと昔前のトップクラスなのかもしれない(多分そうではないと思っているが)が、マジで迷惑

属人的な要素を排除しようと、自動化CIヒューマンエラーを極力抑えても、俺様一言でまたプロジェクトが壊れる

マジでお前それでどんだけ金もらってんだよ、邪魔しかねーし、口だけは達者だから金ももらってんだろうな

ほんと個人攻撃したくないけど、老害死ねばいいのに

2016-03-28

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います

p.4
  • HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
  • gulpのgは小文字なのでよろしくです。
p.5
p.6
p.8
  • EditorCodingってなに
p.9
  • コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
  • npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです?
    • まぁ、この後gulpタスクについて出てるんでしょう……
      • 出てこなかった
p.10
p.15
p.16
p.18

コード品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

  • HTMLの話ですよね? コード品質が維持されない難読化や最小化やコンパイルってなんだろう。
  • あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。
p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

  • その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
  • いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
  • あと日本語が変なんで、それも。
p.20
p.21、22
p.2324
  • .editorconfigにどう書けばいいかをだな……。
p.25
  • HTMLルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
  • Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
  • でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。
p.26

正しいHTML

  • HTMLの正しさとは?
  • 参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。
p.27、28
p.29、30
p.31
p.32
p.36、37
p.40

CSS教科書

p.42、43
p.44、45
p.49、50
p.57、58
  • HEXの短縮は規定しなくていいと思います
  • ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
  • gulpでできますし、ググれば出てきます
  • ちなみに、#f00よりもredの方が1バイト少ないんですよ。
  • 容量削減は人が思いつきでやるには不十分なのです。
  • そんなのはビルド時に機械がやればいい。
  • 容量の削減を理由に人の行為制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。
p.61、62
p.63、64
p.71
p.72、73
  • FLOCSSとMindBEMding共存させるなら、書くべきことが足りなすぎませんか。
p.73

block__element__elementは使用しない

p.78、79
p.80、81
p.87

GoogleChromeなら変換時に右側にマーク

p.96
p.98

svgにすることで1つの画像でまかなえる場合svg使用する

p.102
  • ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
  • Jadeについては何かルールは設けないのでしょうか。
  • JavaScriptについては……?
  • そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
  • 誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。
  • 結論:いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

2014-10-06

MEAN(MongoDB, Express, AngularJS, Node.js)を解説する

MEAN(MongoDB, Express, AngularJS, Node.js)を解説する

前に触った感想です。

MongoDB

基本いつのまにか変更されて変な動きして死んでる前提で、動く/戻せる環境構築できない奴は死ぬ

Express

基本いつのまにか変更されて変な動きして死んでる前提で、動く/戻せる環境構築できない奴は死ぬ

Node.js

基本いつのまにか変更されて変な動きして死んでる前提で、動く/戻せる環境構築できない奴は死ぬ

AngularJS

基本いつのまにか変更されて変な動きして(エンジニアが)死んでる前提で、動く/戻せる環境構築できない奴は死ぬ

http://albatrosary.hateblo.jp/entry/2014/10/06/073638

2014-06-16

隠れブラック


  • もちろん、これは例え。

2014-02-11

世代間における努力意味共通点

違いがあるなら共通点もあるかもしれない。

たとえば、環境を自らの手で構築すること。

 

逆に言えば、与えられた環境既存の蓄えられたノウハウにすがって努力放棄することは、どの世代でもできることだ。

老害だろうがゆとりだろうが、どちらも努力放棄は可能である。逆も然り。

元に戻せば、変化する環境適応を試みる、という意味での努力世代間に変わりはない。

 

変化があるとすれば、過去現在において、環境が違う、という場合も考えられる。

元増田の言わんとする所は、環境が違うのだから、じーさんにとっての努力と、俺らにとっての努力意味が違う、ということだろうか。

元増田の言うとおり、する必要のない努力はする必要はない。そのほうが豊かだ。

 

しかし問題になるだろうな、と思うのは次の場合である

努力経験がない者は、現在環境が変化した時、生き残れるのか。

まぁ、きっと努力せざるを得なくなるのだろうけれど。

 

若いうちに体育会系ハードワーク、あるいは努力)して経験知稼いでおいたほうが、

老人とのゼロサムゲームスキーマで論じるよりも、生産的ではないだろうか?

失敗しても、自分よりもあとの世代は失敗事例として学んでくれるわけだし。

 

些か一般論が過ぎたかもしれない。

http://anond.hatelabo.jp/20140209140426

2013-08-02

Sails.jsを使ってpixiv検索サービス作った

Pixearch(ピクサーチ)

http://pixearch.net/

node.jsMongoDB勉強がてらpixiv画像タグ検索サービス作りました

はてブタグ検索のようにpixiv投稿された最近画像pixiv内でのブックマーク数でフィルタをかけて検索できるのが特徴です。

検索したり、タグをたどって、ダラダラと良い絵を眺めるのを目的としています

一応スマホからも見られるはず。

普段はブログを書いたりしてないので、今回学んだことのメモがてらの投稿です。

使ったもの

MongoDBを試そうと思ったのがサービスを作り始めた発端です。

Web部分はmongoDBと相性が良さそうなnode.js採用

MVCフレームワークで何か適当ものはないかとググってSails.jsが良さそうだったので今回採用しました。

ホスティング

今回はせっかくnode.js採用したので、噂のnode.jsPaaSのnodejitsuを試しに使っています

500MB分の容量のMongoDB最初から使えるのも大きかったです。

とりあえず最小のプランにしてるのでどのくらい捌けるのか気になるところ。

作ってみての感想
Sails.js

Web開発用のモジュール自分で用意するのがめんどいなー、という人向けな印象。

このくらいの規模のものだったらサクッと作れました。

ただある程度の規模のちゃんとしたサービスを作るのには色々足りてないので、自分カスタマイズしたりできる人じゃないと使うのは辛そうです。

後、ドキュメントも公式のものだけだと説明されてない機能結構あったりします。

デフォルトだとDBMySQL対応していて、MongoDBを使うにはsails-mongoを入れる必要がありました。

開発中に困ったことは、nodejitsuで動かそうとしてsails-mongoでエラーが出て、調べてみたらauthenticationに対応していないというバグがあったことでした。

手元で直したのでpull requestを送ろうかと思ったら既に他の人が送っていて、3日前ぐらいに取り込まれているので今は大丈夫なはず。

https://github.com/balderdashy/sails-mongo/pull/36

現在進行形で色々Issueが上がって修正がされているのでそのうちこなれてくるのに期待。

かいところで設計考慮がちゃんとされてるなーと感じたところも多かったので、node.jsで開発してる人は一回試してみると勉強になりそうです。

MongoDB

最初コレクション操作に戸惑ったのですが、結局JS連想配列なので思ったより早く馴染みました。

$setとか$gteとか特殊な意味を持つキーがいくつかあるので、その辺を把握できてから色々と捗りました。

MySQLに比べて特に更新系で複雑なクエリが発行できるので、ORMで使うと十全に機能を発揮できないのではないかな、と思ったり。

ご存知スキーマレスなので、何も考えずにデータを突っ込んでるとIntegerで保存したい値がStringになっててソートときに困ったりするので要注意。

指定した容量を超えたら自動で消してくれるCapped Collectionがあると知ったので、今回みたいな容量が限られてる場合に便利かなと試してみたのですが、このオプション有効にしたコレクションだとデータアップデートや削除ができなくなりました。

おそらく、追加しかしないログのようなデータの保存に使うもののようです。

nodejitsu

まだ微妙な部分も多かったですが、デプロイとかコマンド一発でできて、設定管理がpackage.jsonでできたりして面白かったです。

今回は、特に問題が起きたとき環境sshで入ったりできないので、表示されてるログだけで問題を調査するのに苦労しました。

MongoLabとMongoHQというMongoDBの外部ホスティングサービスが上述したように使えるのですが、無料の容量を超えて使うにはそこそこお金が掛かるのでモリモリ容量を使うものを考えている場合は注意がいります。(もちろん値段に見合ったプロダクトを提供してくれると思いますが)

ということで、せっかく作ったので是非試してみてください。

2012-05-19

http://anond.hatelabo.jp/20120518232038

親の愛情だけで問題行動が減るか?という問いに対して、多分減ると答えても構わないレベル

アプローチする箇所としては、いい線いってると思うのよ。

いや、その論理展開は無理がある。

何故なら問題の条例は肝心要の愛着理論実践に落とし込む過程を何一つ具体的に示していないから。条文の中身についてはpdfつけたっしょ? 読んでよね。

子どもの心身果ては命を脅かすような仕打ちでさえ「虐待ではなくしつけ、すなわち愛情」と言い表わすだけは言いあらわせる以上、「親の愛情だけで問題行動が減る」という命題を成立させるためには、「問題行動が減るような親の愛情」を逆に規定する必要がある。

まり具体的に何をどうするかという実践ハウツーを取り揃える必要が絶対に出てくる。

でもそんなもんケースバイケースすぎて条文化できまっしぇ〜ん。みたいなことになっとる。

そのくせ条例前文に出ている「ながら授乳批判」からは「ながら授乳愛着形成を阻害している」という見方しか読み取れない、すなわち愛着形成にこぎ着けて親の子に対する態度を縛りたいという欲望しか読み取れない。

なんつーかコンセプト自体が「俺等が知ってる馴染んでるかつての『親心』を取り戻させよう!」「ぼくのかんがえた最高の育児に尽きていて、今目の前のリアル育児に手を貸すものでないわけよ。

ぶっちゃけこの条文書いた連中の手にかかったら、例えば子ども預けて仕事に出ることとかミルク育児とかが愛着形成を妨げるっつって白眼視されてものすごい窮屈な展開になるような気しかしないんだよ。

もうマジ問いつめたい。小一時間問いつめたい。こいつら行動を縛るための道具として愛着理論使いたいだけちゃうんかと。

愛着形成しっかりしようね!基礎基本はこうだから、各人で応用頼む!」的な敢えてあいまいマニュアルを守れば

少なくとも「小さいころに愛着形成できずに、非行引きこもり)になっちゃった」ケースは減るんでないかい?

愛着形成が失敗するシーンについてもっと具体的に考えてみる必要あるでしょ。

ものすげー大雑把な理解だけど、愛着理論の説明によれば、子どもネガティブスキーマを抱くとされるのは母親の反応が非応答的なケースだ。

では母親が非応答的に対応するのはどのような場合か?

身体が物理的に空いてないか疲れていたりして応答気力がないか精神煮詰まってて自棄になってるかだ。

これ親は親自身が持ってるということになっている「愛情」という意志だけで何とかしなきゃなんないの?

根性論と何が違うの? って話になってくる。マニュアルが親の代わりに買い物行ったり子どもあやしたりしてくれるとでもいうのかい

愛着愛着連呼しててちょっと思ったんだが、この条例子ども愛着形成を阻害するものいかにして除くかという観点じゃなくて、親自身の、子どもに対する愛着いかにして形成し維持するかっていう観点をメインに据えない限り、机上の空論有害妄想の域を出られないような気がしてきた。

でもそんなのって思想信条の自由とか人生とかそういうもの領域と見事にバッティングするわけで、マニュアルとか「親になる教育」とかいってある程度粒を揃えようみたいなこと試みるのってなんかアプローチが違うんじゃねえの? みたいな感じがする。

2011-12-24

認知の微視的構造 リマインダー

リマインドしようにも、これを書いた人(=自分)の学力だと読めない本だったから無理。無理ゲーだった。

第一章

1

認知主義、古典認知主義

意味論的に透明なシステムと結びついた心の概念および計算機モデル意味する。

 この主義の限界を

2

 ・チューリング

 チューリングの形式化が持っている特徴

(1)物理的組織によってではなく、記号操作の形式的特性によるメカニズムの集合全体を包括

(2)そのメカニズムいかにすれば十分に明確化された問題すべてに取り組むことができるか示している

(3)万能チューリングマシンを定義する方法を示している

⇒ 素材は重要ではなく、形式的特性が能力を原理的に保証している

フォン・ノイマンコンピュータを設計し、1960s、ジョン・マッカーシーLISPプログラム言語)を開発。

 ⇒ 研究開発が可能に

A・ニューウェルとH・サイモンが物理記号システムという概念を提出

 ⇒理論的に自覚化・明確化される

3

・物理記号システム

①適切に操作可能なトークンに対して任意に意味を割り当てることができるシステムであり、

②正確にプログラミングすればこの割り当てられた意味論的内容と細かい点においても一致した仕方で行動すると信じられるようなシステム

by 1976 ニューウェル & サイモン

・強い物理記号システムの仮説

SPSS strong-physical-symbol-system

「標準的な記号アトムフォン・ノイマン型の操作を行っている仮想機械は、一般的な知的行為を実現するための直接的かつ十分な手段を持っている」

①仮想機械

現実の物理機械上で実行されるプログラムのみによって存在し、

そのプログラムに我々が命令を与える機械を模倣させるような「機械」

 高級プログラムによって定義されるエミュレータ

フォン・ノイマン型の操作

コネクショニズムとは異なった操作

・記号を割り当てる

・変数を束縛する

・記号列の複写、読みとり、修正

・基本的な統語論パターンマッチング操作

等々

③標準的な記号アトム

「テーブル」「ボール」「愛する」「軌道」「電子」のような語

④一般的な知的行為を実現するための直接的で必要かつ十分な手段

そうした機械は、それを支えている特定のアーキテクチュア(その基盤になっている他の現実的もしくは仮想的機械から)まったく独立に真に知的でありうるのであり、逆に言えば他のアーキテクチュアや機械をシュミレートすることなく真に知的でありうる

 このような主張(標準的なLISPアトムのごちゃごちゃした操作が、知能や思考の本質を構成しうるという見解)が、ニューウェルとサイモンのものだとできる動かぬ証拠は、彼ら自身の実践

彼らの仕事の特徴(例:BACON

 ・規則あるいはヒューリスティックス(発見的手法)の直列的(経験則を用いたも多少は運が左右する⇔体系的)適用に依存している

 ・そうしたヒューリステイックスの大部分が、かなり高いレベルで意識的に内省可能

 ・選ばれた課題領域を扱う

BACON:一連のデータから科学的法則を帰納する(ケプラーの第三法則、オームの法則

BACONに対するいくつかのコメント

BACONが取り組んだデータフォーマット化下のは、人間の労苦

BACONは十分に構造化された課題にしか取り組めない。

 ケプラーの第三法則は見つけられても、ペトリシャーレのカビとバクテリアの関係からペニシリンを発見する事はできない

BACONが展開する知識とヒューリスティックスは、人間のプロトコルや実験記録に大いに頼り、われわれが自分自身の思考について内省する思考のレベルからかなり直接的にコード化されたもの

 ⇒この種の思考は原初的で瞬間的なプロセスの上に後から被せられたもの。理解するということを具体的な例で説明する事には役に立たないであろう

 サイモン等は、人間の思考のすべてがただ一つの種類の計算アーキテクチュアに依存すると信じている。

 しかし、筆者は違う考えを持つ。サイモンラングレイの仕事では、洞察のひらめきといったタイプの認識を表現できない。

 心は、多くの仮想的アーキテクチュアからなる複雑なシステムであると考える

 BACONは、人類の一部のモデル

 知的課題や、感覚運動的な課題のような、なめらかに無意識的に行われるものは無視されている

 古典システムは記号アトムの使用に頼り、コネクショニズムはこれを避ける。

 古典主義者:意味論的に透明なシステムの構築に対して、方法論的にコミットしている人々

意味論的に透明、意味論的な透明性

STS semanttically transparent system

システムの振る舞いについての記号的な(概念レベルでの)意味論記述と、システムの形式的な計算活動の内的に表現された対象についての投影可能な意味論的解釈との間にきちんとした写像関係の記述が可能な場合にのみ、そのシステム意味論的に透明であるといえる」

 きわめて大ざっぱにいえば、あるシステムかSTSと見なされるのは、そのアルゴリズム記述レベル2)における計算の対象が、概念レベルの用語で表現されたその課題の分析の記述レベル1)と同型である場合である

レベル1:計算理論:(高い抽象レベルにおいて)どのような関数が計算されるかについての考え

レベル2:表現とアルゴリズム:それを計算する(具体的な)方法

レベル3:インプリメンテーション:現実の機械において計算がいかにして肉体あるいはシリコンなどで実現されるか)

古典アプローチコネクショニズムの重要な違い

(1)古典理論は――コネクショニズムはそうではないが――統語論意味論を組み合わせた記号システムを仮定している

(2)もし何らかの種類の構造化された表現が利用可能であれば、それらの表現についての計算操作を、その構造に鋭敏に反応するかのような形で規定できる。

 もしそのような構造が存在していなければ、(すなわち、どんな記号表現も存在していなければ、)計算操作を規定することはできない

◎要するに、古典システムは、統語論的に構造化された記号的表現を仮定し、そうした表現の構造によって、それに適用される計算操作を規定するものである

第二章

 古典認知主義に対する懸念

 ドレイファス:古典認知主義の問題は、人間の常識的な知識を表象として再現し表現しようとする形式主義の妥当

 サール:形式的なものと志向的なものとの間に、あるいは統語論意味論との間にギャップが認められる

 この二つの種類の懸念について検討する。

あなたの持っているのはそんなにいいボールじゃないわ。それを私にちょうだい。そしたら私、このキャンディーをあなたにあげるわ」

 この言葉を理解するために、ミンスキーちとパペートは膨大な概念リストをあげる。

 ウィノブラードのSHRDLUでは不十分。

 ウィンストンの、フレームを使ったアプローチも不十分

 ・フレームは、常識がうまく対処している偶発的出来事のすべてをカバーしているとは思えない(バースデーケーキに立つ黒いローソクに、フレームは対処できるか?)

 ・フレームからフレームへの移行を促す規則(メタフレーム?)をいつ適用すべきか、システムはどうやって知るのだろう?

 ドレイファス:互いに関連しあった特徴や可能性のすべてを、文脈に依存しない事実や規則によって形式的に把握するという課題には際限がないのではないか

ドレイファスの二つの主張

(1)身体問題

「このシャンプーが目に入らないようにご注意ください。もし入った場合は、ぬるま湯でよく洗ってください」

 コンピュータは、身体、欲求、感情、共通言語や社会習慣も持たない。だからコンピュータは、この文章が何を洗うように言っているのか理解できない

(2)コード

 人間は自分たちを取り巻く状況がどんなものかを絶えず感じ取ることができる。

 このノウハウは、何らかの知識表現言語によって、一種の知識として表現できるものなのだろうか?

 

 AIプログラム(=言語)が知識を表現する仕方が、現実の課題に対して根本的に不適合だと懸念する。

「強いAI仮説」を、サールは批判する

強いAI仮説:適切にプログラムされたコンピュータは、文字通り認知的な状態をとり、その際プログラムは人間の認知を説明するものとなる

Schank and Abelson 1977の、「ストーリーを理解するという志向的活動をシミュレートしているかに見える特別なプログラム」に対して、「中国語の部屋」を使うことで批判する。

サール:形式的に区別される要素に対する計算操作を行っているだけでは、どんなコンピュータも〈理解する〉ことはできない。したがって、そのような計算操作を規定するプログラムが、心の固有の性質について何かを示すこともあり得ない。

具体例:英語話者が英語を理解することと、中国語の部屋操作者が中国語を「理解すること」の比較

「人間は何も理解していなくても形式的な原理に従うことができる」

 以下、サールの誤りについて論じる

 

 サールに対する仮想反論「脳シュミレーター説」

 脳シュミレータ説:あるりプログラム中国語を理解する実際の中国人の形式的な構造をモデル化したと仮定すると、そのときそのプログラムは間違いなく真の中国語の理解を構成したことになる

↑(サールの再反論)

(1)脳の形式的な性質は志向性を構成しない(三章にて説明)

(2)脳の形式的な性質が志向性を構成しないのは、ある種の素材だけが思考を支えることができるからである

 ↑(アナロジー

 光合成光合成の形式的な記述を手に入れても、素材が違えば光合成は再現できない

 では、思考をもたらすような脳の物理的性質とは?

  :外因的および内因的な刺戟に対して脳に大規模な変動が引き起こされること

↑(コメント

中国語の部屋』が大規模な構造的変動を必要としないシステムなら、中国語の部屋による反論は無効

 微視的機能主義

 機能主義は、心的状態の本質を、

 入力、内的状態の変換、出力からなるプロフィールと同一視した。

 (適切なプロフィールを持つシステムはどんなものであれ、その規模や性質や構成要素にかかわれなく、当の心的状態を実現するであろう)

↑(批判)

中国国家脳のような)心的状態を実現する見込みがないようなシステムも、「入力、内的状態の変換、出力」のプロフィールを持つシステムへと組織することは可能であるよように思われる。

 こうした極端な寛大さは、機能主義の立場を掘り崩してしまいそう

・問題は、「入力、内的状態の変換、出力」の系列をどこに位置づけるか

×大まかなレベルに位置づけ

  ⇒感覚質の欠如、極端な寛大さ

ライカンの「小人機能主義」

○微視的機能主義

・機能主義の批判はゲシュタルト盲に陥っているのでは Lycan 1981

ゲシュタルト

 :機能的な構成要素があまりにも大きい、極度に小さい、それらしくない等であるために、そうしたものからなるシステムに志向性を帰属させるという考えに抵抗するということ

ライカン「小人機能主義」

 :機能的な下位システムは、それがエージェントのために何をしているかということによって同定される)

 微視的機能主義

  :システムの内的な機能的プロフィール(内的状態の変換)を、

   内容や目的に関連づけからはかけ離れた用語で

   記述しようとするもの

   ・処理ユニット間の形式的な諸関係を記述する

   ・諸関係が得られたとき、システムには大規模で柔軟な構造的変動が引き起こされ、またそれによってさまざまな創発敵的性質が得られるようになる

第三章

 認知科学における民間心理学の役割はあるのかないのか

「民間心理学

 :自分や他人が、信じたり、希望したり、恐れたり、欲求したりしているということについての日常の理解

 民間心理学は、行為・運動を説明するときに、信念や欲求という表現を用いる

チャーチランド & スティック

「民間心理学は、人間の行動に先立つ内的原因についての素朴で原初的な科学

 民間心理学問題点

(1)民間心理学は、偏狭な、特定の人々に限定されたような理解しか与えない。

 民間心理学は、子供狂人外国人を前にすると、まごついてしま

(2)民間心理学は停滞したまま、なにも生み出さず、長い間ほとんど変化も進化も発展もしていないところが他の諸科学と異なる

(3)民間心理学は、これまでのところ科学の主要部分にうまく統合されていくような徴候をまったく示していない。残念なことに民間心理学は自然を神経生理学的ないみで妥当な要素にまで分割することには関心がないようである

 最近の分析哲学

  :頭の状態に関する科学理論というゲームと、民間心理学というゲームを比較することが、そもそも不適当なのではないか

Daredevil believes that Electra is dead.

Mary hopes that Fermat's last theorem is true.

 のthat以下を、心的状態の内容と言う。

 心的状態が考えられる傾向

  :われわれの心理学的状態が、本質的に、周囲の世界がどのような状態にあるのかということによって決まるのではなく、

  われわれにとってどのように見えているかによって決まる

 ↓(言い換え)

 我々の意識や無意識に何らかの形で影響を与えられないものはどんなものであれ、

 本質的に我々の心的状態の正確な限定に関わることはあり得ない

⇒我々の心的状態が現に持っているような内容を持つものは、われわれ自身のあり方ゆえであって、

 知られていないかもしれないような周囲世界の事実とは関わりがない……☆

・双生地球……☆に対して疑いを投げかける

双生地球で、「海に水がある」と発話される。

地球A:海にH2Oがある

地球B:海にXYZがある

 この違い以外は同質だとする。

 すると、

 地球上の発話と双生地球の発話は、それぞれH2OがあるかXYZがあるかによってその真偽が決まる

(たとえば、地球Aの海にH2Oがなくて代わりにXYZがあるとしたら、地球Aでの発話は偽になる)

 もし意味が真理条件を確定するのだとすれば、

 自然種に関する表現(水、金、空気など)を含む陳述の意味は、

 単に主体の限定的に規定可能な状態に言及するだけでは十分に説明できない……☆に反して

二つの選択肢

(1)心理学的な内的要素(地球の話し手と双生地球の話し手に共通)と、

 世界関与的な外的要因(仮定上、二つの地球を越えて不変ではない(H2OとXYZ))の両方によって内容が決まるとする、意味と信念に関する合成説

(2)そういったケース(地球と双生地球のケース)は

  〈心的状態の純粋に内的でまったく心理学的な要素(☆のこと)〉という観念にさえも疑いを抱かせるものであると考えることもできるだろう

プティ と マクダウェル

「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない。

 しかし、

〈頭の中〉にあるものが心の状態に対して構成的関係にあると考え必要があるのだろうか?」

 筆者

 :あらゆる内容が根本的に世界に関与している(選択肢(2))ということが判明したとしても、

 そのこと自体は必ずしも〈認知科学は心の理解に深く(ことによると構成的にではないかもしれないが)関わる研究である〉という主張を覆すものではない

 その主張に対する仮想反論と、それに対する再反論をHornsbyは行った。

 仮想反論

 :「「行動傾向(心性はこれに随伴して生じるとされる)が二者の間で異なるためには、

 内的構成に違いがなければならない。」

 という考えを保持すべきである」とするならば、

 心的内容は限定的に規定されねばならない(自然種を指示しない)

(「「行動傾向(心性はこれに随伴して生じるとされる)が二者の間で異なるためには、

 内的構成に違いがなければならない。」

 という考えを保持すべきである」までが、プティとマグダウェルの、「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない」に対応する。)

 仮想反論の詳細

:仮定①:

 二人の動作主の心的状態は、彼らの行動傾向に何らかの違いがある場合にのみ異なる

 (そこに赤いボールがある、と信じなければ、ボールを投げようとは思わない)

 仮定②:

 行動が異なる(すなわち、行動が異なる)ためには、内的な物理的状態に何らかの違いかなければならない

 結論:それゆえ、心的状態に対応する内的な物理的状態に何らかの違いがなければ、心的状態が異なるということはありえない

「(民間心理学的な心的状態を帰属させることは、限定的内容のみに関わることであるという)結論は、深刻な疑義にさらされることになる。

 限定的内容といっても、それを妥当概念として了解できるかは明らかではない」

 なぜなら、

「民間心理学的な内容を(物理的状態に?)帰属させることは、身体的な動きを規定するような頭の状態についての独我論的な研究から引き出すことができるような切り口とは

 まったく違った切り口で現実を切り取ることであるように思われる。

 その具体的理由として、

 ボールをひろうことは、「そこにボールがあると私は知っている」という心的状態と関連するが、そのときの細かな指の動きはそのような心的状態と関連するものではない。

筆者

 :広域的内容を伴うによ伴わないにせよ、

 民間心理学カテゴリーや分類が

 頭の中で起こっていることに関することに関する科学カテゴリーや分類に

 きちんと還元されるなどということは

 とてもあり得ないように思われる。

・民間心理学は、科学心理学と同じゲームを行ってはいないかもしれない

 世界を記述しない信念であり、なおかつ

 ある人が同じ考えを抱いているといえるような別のケースに投影可能な述語が(科学記述の上には)存在しないことも可能

 民間心理学の道具立て(信念と欲求という概念によって、命題的態度を帰属せさるという道具立て)を用いて、心的状態を二者が互いに帰属させあうという日常の慣習(傍点)の目的は?

 :

 他人の頭の内的状態を追跡しようと試みることによって、

 その人の身体の動きを予測し説明するための手段

民間心理学の主要な目的

 :

 世界の中で活動している仲間たちの行動を、(傍点開始)我々が(傍点終わり)理解できるようにすること

(予測したい対象であり主体である)われわれの仲間たちの四つの特徴

①世界に対する感受性、すなわち感覚生得的な原書的概念の道具立てをわれわれと共有している

②世界をわれわれと共有している

③彼らは我々自身のもっと根本的な関心と必要の大部分を共有している

④彼らの思考の有用性は、

(我々自身の思考と同様に、)

 彼らが世界の実際の有様をたどっていることと関わっており、

 彼らの思考作用が、世界の実際の有様に十分適応していると我々が(進化論的な理由から)考えるような目的と関わっている

 この特徴があるので、

「~したい」という欲求さえ同じであれば、

 神経生理学的な詳細は関係なく、地球人にも火星人にも有効。

・民間心理学は、脳の状態の違い(that かなり目の粗い、行動上の違いとしては現れてこないような)に対しては、敏感に対応しないように設計されている

・民間心理学は、個人の間の差異を覆い隠し、

 さらには種の間の差異さえも覆い隠してしまう(長所であっても短所ではない)

 筆者の見解

 :私の見解では、われわれが信念を帰属させるのは、

 行動の全体に一種の解釈の網をかぶせることによってである

 ……関連する行動を可能にするものとしての、

 根底にある物理的あるいは計算論的な構造がどのようなものであれ、

 そうした構造における自然な区分に、網の結び目(すなわち信念と、欲求の特定の帰属)が

 対応している必要はない。

――

 筆者の意見は全体論である。(行動全体に網をかけるから。)

 ということは、Davidson(全体論者)に対するFordorの批判は、筆者の意見にも当てはまるのではないか

<Fordor>

意識の全体論というのは、

命題的態度の同一性――特に志向的内容――が、その認知的連関の全体によって決定される」

 という考え方。

 これに、Fordorは懐疑的

命題pの認知的連関というのは、主体がpの意味論的評価、すなわちその真偽の決定に関係するすべての命題のこと)

われわれは、信念や志向的状態を共有している。が、そのとき、すべての命題認知的連関)を共有しているとは思えない。

 なので、意味全体論はありえない。

 →信念の内容が、その認知的連関に依存するということを否定。

 信念は、その内容をそれぞれ別に持つ。

 外延的意味論の一形態に賭ける

:信念がその状態を獲得するのは、脳の状態が逐一、世界と因果関係を結ぶことによってである

「ある生物が『牛』という概念を持とうと持つまいと、その生物は『馬』という概念を持ちうる」

</Fordor>

筆者

 :Fordorの間違い

 全体論は、もしそうであれば、人間の心の理解が芋蔓式に進んでくれるのにという、いわば願望。

 Fordorが軽蔑したものの通りに進んでくれるかは別問題。

Fordor:バラバラになったブロックを一つの全体に組み合わせるやり方が、全員同じになるはずがない。

筆者:一つのブロックの組み合わせ全体を理解するために、各人が別々のやり方でバラバラにしている

 全体論という言葉の使い方が違うから、Fordorの批判は筆者には当てはまらない(という、批判をかわすための節)

 一章3節での、チャーチランドによる民間心理学批判に、今では応答できる。

(1)民間心理学は、狂人や言葉の通じない相手には使えない

(2)民間心理学は、長い間停滞している不毛な学問である

(3)民間心理学は、神経科学ときちんとつながっていない

(3)に対して、

 民間心理学の関心事は、他の主体の顕著の行動パターンだけを可能な限り効率的に分離することである神経科学とつながることを目的とはしていない

(1)に対して、

 民間心理学の道具としての適用範囲は、仲間。狂人の理解は、そもそも目標としていない

(2)に対して、

 民間心理学の目的は限られたものである

 なので、その中核部分が時間的および地理的な次元を越えて相対的に恒常的であり続けてきたことは驚くべきことではない。

整理。

 心的状態に関するわれわれの常識的理解と民間心理学は、違う。

 民間心理学には、きちんとした定義がある。

 これまで「民間心理学」として使われてきた言葉の、新たな用語法:「素朴心理学」、「メンタリズム的な理解」

 因果関係と、構成的関係の区別

構成的関係

 :

 研究の主題と何らかの形で密接に結びついているということ

因果的に関係

 :

 因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、

 それらの要素を差し引いてもそれによって思考という観念そのものが存続しえなくなる

ということはない。

チェス盤がなくなっても、チェスの続きは打てる。石を駒に見立てたり、口頭で)

・広域的内容の理論認知科学は心を解明しえない

・消去主義的唯物論:民間心理学が、心に関する科学に対して歪んだ影響を及ぼすのではないか民間人は自分自身の心を知らないと、消去主義的唯物論は思っている

科学(物質、プログラム

(構成的関係)

科学と心とを結びつける構成的関係。その得難さが二つのスタンスの対立を生んでいる。が、どちらの立場も同じく、認知という地形に同じ隆起とくぼみを見ている。

では、構成的関係とは何か。

構成的関係←→因果関係

構成的関係:研究の主題(この場合は心)と、何らかの形で概念上密接に結びついていること

因果的関係:因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、それらの要素を差し引いても、それによって思考という観念そのものが存続しえなくなるというひとはない

(駒はなくてもチェスは打てる)

Permalink | 記事への反応(0) | 15:30

2011-12-07

適応スタイルは、最後には諦めの形を取る

スキーマ認知的枠組み、適応スタイル・様式

現実社会と上手く関わっていく上での、仮説的な構成概念

想定された、こうであるだろうというモデル

おそらく、それらの行き着くところは"諦め"だろう

受容・許容と言い換えてもいい

対象となるもの自分の中に取り入れて、それに合わせて自分の方を変える

それを日常用語で言えば、諦めだろうか

2011-09-15

コンピュータ基礎理論ハンドブック2 形式的モデル意味論」の目次

第1章  有限オートマトン
	D.Perrin:橋口攻三郎
1. 序論
2. 有限オートマトン認識可能集合
3. 有理表現
4. Kleeneの定理
5. 星の高さ
6. 星自由集合
7. 特殊なオートマトン
8. 数の認識可能集合


第2章  文脈自由言語
	J.Berstel and L.Boasson:富田 悦次

1. 序論
2. 言語
	2.1 記法と例
	2.2 Hotz 群
	2.3 曖昧性と超越性
3. 反復
	3.1 反復補題
	3.2 交換補題
	3.3 退化
4. 非生成元の探求
	4.1 準備
	4.2 生成元
	4.3 非生成元と代入
	4.4 非生成元と決定性
	4.5 主錐の共通部分
5. 文脈自由群
	5.1 文脈自由群
	5.2 Cayleyグラフ
	5.3 終端


第3章  形式言語とべき級数
	A.Salomaa:河原 康雄

1. 序論
2. 準備
3. 書換え系と文法
4. Post正準系
5. Markov系
6. 並列書換え系
7. 射と言語
8. 有理べき級数
9. 代数的べき級数
10. べき級数の応用


第4章  無限の対象上のオートマトン
	W.Thomas:山崎 秀記

序論
Ⅰ部  無限語上のオートマトン
	記法
1. Buchiオートマトン
2. 合同関係と補集合演算
3. 列計算
4. 決定性とMcNaughtonの定理
5. 受理条件とBorelクラス
6. スター自由ω言語と時制論理
7. 文脈自由ω言語
Ⅱ部  無限木上のオートマトン
	記法
8. 木オートマトン
9. 空問題と正則木
10. 補集合演算ゲームの決定性
11. 木の単項理論と決定問題
12. Rabin認識可能な集合の分類
	12.1 制限された単項2階論理
	12.2 Rabin木オートマトンにおける制限
	12.3 不動点計算


第5章  グラフ書換え:代数的・論理アプローチ
	B.Courcelle:會澤 邦夫

1. 序論
2. 論理言語グラフの性質
	2.1 単純有向グラフの類S
	2.2 グラフの類D(A)
	2.3 グラフの性質
	2.4 1階のグラフの性質
	2.5 単項2階のグラフの性質
	2.6 2階のグラフの性質
	2.7 定理
3. グラフ演算グラフ表現
	3.1 源点付きグラフ
	3.2 源点付き超グラフ
	3.3 超グラフ上の演算
	3.4 超グラフの幅
	3.5 導来演算
	3.6 超辺置換
	3.7 圏における書換え規則
	3.8 超グラフ書換え規則
4. 超グラフの文脈自由集合
	4.1 超辺置換文法
	4.2 HR文法に伴う正規木文法
	4.3 超グラフの等式集合
	4.4 超グラフの文脈自由集合の性質
5. 超グラフの文脈自由集合の論理的性質
	5.1 述語の帰納的集合
	5.2 論理構造としての超グラフ
	5.3 有限超グラフの可認識集合
6. 禁止小グラフ定義される有限グラフの集合
	6.1 小グラフ包含
	6.2 木幅と木分解
	6.3 比較図
7. 計算量の問題
8. 無限グラフ
	8.1 無限グラフ表現
	8.2 無限グラフの単項性質
	8.3 超グラフにおける等式系
	8.4 関手の初期不動点
	8.5 超グラフにおける等式系の初期解
	8.6 等式的超グラフの単項性質


第6章  書換え系
	N.Dershowitz and J.-P.Jouannaud:稲垣 康善,直井 徹

1. 序論
2. 構文論
	2.1 項
	2.2 等式
	2.3 書換え規則
	2.4 決定手続き
	2.5 書換え系の拡張
3. 意味論
	3.1 代数
	3.2 始代数
	3.3 計算能代数
4. Church-Rosser性
	4.1 合流性
	4.2 調和性
5. 停止性
	5.1 簡約順序
	5.2 単純化順序
	5.3 経路順序
	5.4 書換え系の組合せ
6. 充足可能性
	6.1 構文論的単一化
	6.2 意味論的単一化
	6.3 ナローイング
7. 危険対
	7.1 項書換え
	7.2 直交書換え系
	7.3 類書換え
	7.4 順序付き書換え
	7.5 既約な書換え系
8. 完備化
	8.1 抽象完備化
	8.2 公平性
	8.3 完備化の拡張
	8.4 順序付き書換え
	8.5 機能定理証明
	8.6 1階述語論理定理証明
9. 書換え概念拡張
	9.1 順序ソート書換え
	9.2 条件付き書換え
	9.3 優先度付き書換え
	9.4 グラフ書換え


第7章  関数型プログラミングラムダ計算
	H.P.Barendregt:横内 寛文

1. 関数計算モデル
2. ラムダ計算
	2.1 変換
	2.2 計算可能関数表現
3. 意味論
	3.1 操作意味論:簡約と戦略
	3.2 表示的意味論ラムモデル
4. 言語拡張
	4.1 デルタ規則
	4.2 型
5. 組合せ子論理と実装手法
	5.1 組合せ子論理
	5.2 実装の問題


第8章  プログラミング言語における型理論
	J.C.Mitchell:林 晋

1. 序論
	1.1 概論
	1.2 純粋および応用ラムダ計算
2. 関数の型をもつ型付きラムダ計算
	2.1 型
	2.2 項
	2.3 証明系
	2.4 意味論健全性
	2.5 再帰関数論的モデル
	2.6 領域理論モデル
	2.7 カルテシアン閉圏
	2.8 Kripkeラムモデル
3. 論理的関係
	3.1 はじめに
	3.2 作用構造上の論理的関係
	3.3 論理的部分関数論理同値関係
	3.4 証明論的応用
	3.5 表現独立性
	3.6 論理的関係の変種
4. 多相型入門
	4.1 引数としての型
	4.2 可述的な多相的計算系
	4.3 非可述的な多相型
	4.4 データ抽象存在型
	4.5 型推論入門
	4.6 型変数をもつλ→の型推論
	4.7 多相的宣言の型推論
	4.8 他の型概念


第9章  帰納的な関数プログラム図式
	B.Courcelle:深澤 良彰

1. 序論
2. 準備としての例
3. 基本的な定義
	3.1 多ソート代数
	3.2 帰納的な関数プログラム図式
	3.3 同値な図式
4. 離散的解釈における操作意味論
	4.1 部分関数と平板な半順序
	4.2 離散的解釈
	4.3 書換えによる評価
	4.4 意味写像
	4.5 計算規則
5. 連続解釈における操作意味論
	5.1 連続代数としての解釈
	5.2 有限の極大要素と停止した計算
6. 解釈クラス
	6.1 汎用の解釈
	6.2 代表解釈
	6.3 解釈方程式クラス
	6.4 解釈代数クラス
7. 最小不動点意味論
	7.1 最小で唯一の解を得る不動点理論
	7.2 Scottの帰納原理
	7.3 Kleeneの列と打切り帰納法
8. プログラム図式の変換
	8.1 プログラム図式における同値性の推論
	8.2 畳込み,展開,書換え
	8.3 制限された畳込み展開
9. 研究歴史,他の形式のプログラム図式,文献ガイド
	9.1 流れ図
	9.2 固定された条件をもつ一様な帰納的関数プログラム図式
	9.3 多様な帰納的関数プログラム図式
	9.4 代数理論
	9.5 プログラムの生成と検証に対する応用


第10論理プログラミング
	K.R.Apt:筧 捷彦

1. 序論
	1.1 背景
	1.2 論文の構成
2. 構文と証明論
	2.1 1階言語
	2.2 論理プログラム
	2.3 代入
	2.4 単一化子
	2.5 計算過程―SLD溶融
	2.6 例
	2.7 SLD導出の特性
	2.8 反駁手続き―SLD木
3. 意味論
	3.1 1階論理意味論
	3.2 SLD溶融の安全性
	3.3 Herbrand模型
	3.4 直接帰結演算子
	3.5 演算子とその不動点
	3.6 最小Herbrand模型
	3.7 SLD溶融の完全性
	3.8 正解代入
	3.9 SLD溶融の強安全性
	3.10 手続き的解釈と宣言的解釈
4. 計算力
	4.1 計算力と定義力
	4.2 ULの枚挙可能性
	4.3 帰納的関数
	4.4 帰納的関数計算力
	4.5 TFの閉包順序数
5. 否定情報
	5.1 非単調推論
	5.2 閉世界仮説
	5.3 失敗即否定規則
	5.4 有限的失敗の特徴付け
	5.5 プログラムの完備化
	5.6 完備化の模型
	5.7 失敗即否定規則の安全性
	5.8 失敗即否定規則の完全性
	5.9 等号公理と恒等
	5.10 まとめ
6. 一般目標
	6.1 SLDNF-溶融
	6.2 SLDNF-導出の安全性
	6.3 はまり
	6.4 SLDNF-溶融の限定的な完全性
	6.5 許容性
7. 層状プログラム
	7.1 準備
	7.2 層別
	7.3 非単調演算子とその不動点
	7.4 層状プログラム意味論
	7.5 完全模型意味論
8. 関連事項
	8.1 一般プログラム
	8.2 他の方法
	8.3 演繹データベース
	8.4 PROLOG
	8.5 論理プログラミング関数プログラミング統合
	8.6 人工知能への応用


第11章  表示的意味論
	P.D.Mosses:山田 眞市

1. 序論
2. 構文論
	2.1 具象構文論
	2.2 抽象構文
	2.3 文脈依存構文
3. 意味論
	3.1 表示的意味論
	3.2 意味関数
	3.3 記法の慣例
4. 領域
	4.1 領域の構造
	4.2 領域の記法
	4.3 記法上の約束事
5. 意味記述法
	5.1 リテラル
	5.2 式
	5.3 定数宣言
	5.4 関数抽象
	5.5 変数宣言
	5.6 文
	5.7 手続抽象
	5.8 プログラム
	5.9 非決定性
	5.10 並行性
6. 文献ノート
	6.1 発展
	6.2 解説
	6.3 変形


第12意味領域
	C.A.Gunter and D.S.Scott:山田 眞市

1. 序論
2. 関数帰納定義
	2.1 cpoと不動点定理
	2.2 不動点定理の応用
	2.3 一様性
3. エフェクティブに表現した領域
	3.1 正規部分posetと射影
	3.2 エフェクティブに表現した領域
4. 作用素関数
	4.1 積
	4.2 Churchのラム記法
	4.3 破砕積
	4.4 和と引上げ
	4.5 同形と閉包性
5. べき領域
	5.1 直観的説明
	5.2 形式的定義
	5.3 普遍性と閉包性
6. 双有限領域
	6.1 Poltkin順序
	6.2 閉包性
7. 領域の帰納定義
	7.1 閉包を使う領域方程式の解法
	7.2 無型ラム記法モデル
	7.3 射影を使う領域方程式の解法
	7.4 双有限領域上の作用素表現


第13章  代数仕様
	M.Wirsing:稲垣 康善,坂部 俊樹

1. 序論
2. 抽象データ型
	2.1 シグニチャと項
	2.2 代数計算構造
	2.3 抽象データ型
	2.4 抽象データ型の計算可能性
3. 代数仕様
	3.1 論理式と理論
	3.2 代数仕様とその意味論
	3.3 他の意味論的理解
4. 単純仕様
	4.1 束と存在定理
	4.2 単純仕様表現能力
5. 隠蔽関数と構成子をもつ仕様
	5.1 構文と意味論
	5.2 束と存在定理
	5.3 隠蔽記号と構成子をもつ仕様表現能力
	5.4 階層仕様
6. 構造仕様
	6.1 構造仕様意味論
	6.2 隠蔽関数のない構造仕様
	6.3 構成演算
	6.4 拡張
	6.5 観測的抽象化
	6.6 構造仕様代数
7. パラメータ仕様
	7.1 型付きラムダ計算によるアプローチ
	7.2 プッシュアウトアプローチ
8. 実現
	8.1 詳細化による実現
	8.2 他の実現概念
	8.3 パラメータ化された構成子実現と抽象化子実現
	8.4 実行可能仕様
9. 仕様記述言語
	9.1 CLEAR
	9.2 OBJ2
	9.3 ASL
	9.4 Larch
	9.5 その他の仕様記述言語


第14章  プログラム論理
	D.Kozen and J.Tiuryn:西村 泰一,近藤 通朗

1. 序論
	1.1 状態,入出力関係,軌跡
	1.2 外的論理,内的論理
	1.3 歴史ノート
2. 命題動的論理
	2.1 基本的定義
	2.2 PDLに対する演繹体系
	2.3 基本的性質
	2.4 有限モデル特性
	2.5 演繹的完全性
	2.6 PDLの充足可能性問題の計算量
	2.7 PDLの変形種
3. 1階の動的論理
	3.1 構文論
	3.2 意味論
	3.3 計算量
	3.4 演繹体系
	3.5 表現力
	3.6 操作的vs.公理意味論
	3.7 他のプログラミング言語
4. 他のアプローチ
	4.1 超準動的論理
	4.2 アルゴリズム論理
	4.3 有効的定義論理
	4.4 時制論理


第15章  プログラム証明のための手法論理
	P.Cousot:細野 千春,富田 康治

1. 序論
	1.1 Hoareの萌芽的な論文の解説
	1.2 C.A.R.HoareによるHoare論理のその後の研究
	1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究
	1.4 Hoare論理概観
	1.5 要約
	1.6 この概観を読むためのヒント
2. 論理的,集合論的,順序論的記法
3. プログラミング言語の構文論と意味論
	3.1 構文論
	3.2 操作意味論
	3.3 関係的意味論
4. 命令の部分正当性
5. Floyd-Naurの部分正当性証明手法とその同値な変形
	5.1 Floyd-Naurの手法による部分正当性証明の例
	5.2 段階的なFloyd-Naurの部分正当性証明手法
	5.3 合成的なFloyd-Naurの部分正当性証明手法
	5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明同値性
	5.5 Floyd-Naurの部分正当性証明手法の変形
6. ライブネス証明手法
	6.1 実行トレース
	6.2 全正当性
	6.3 整礎関係,整列集合,順序数
	6.4 Floydの整礎集合法による停止性の証明
	6.5 ライブネス
	6.6 Floydの全正当性証明手法からライブネスへの一般化
	6.7 Burstallの全正当性証明手法とその一般化
7. Hoare論理
	7.1 意味論的な観点から見たHoare論理
	7.2 構文論的な観点から見たHoare論理
	7.3 Hoare論理意味論
	7.4 構文論と意味論の間の関係:Hoare論理健全性と完全性の問題
8. Hoare論理の補足
	8.1 データ構造
	8.2 手続き
	8.3 未定義
	8.4 別名と副作用
	8.5 ブロック構造局所変数
	8.6 goto文
	8.7 (副作用のある)関数と式
	8.8 コルーチン
	8.9 並行プログラム
	8.10正当性
	8.11 プログラム検証の例
	8.12 プログラムに対して1階論理拡張した他の論理


第16章  様相論理時間論理
	E.A.Emerson:志村 立矢

1. 序論
2. 時間論理の分類
	2.1 命題論理 対 1階述語論理
	2.2 大域的と合成的
	2.3 分岐的 対 線形
	2.4 時点と時区間
	2.5 離散 対 連続
	2.6 過去時制 対 未来時制
3. 線形時間論理技術的基礎
	3.1 タイムライン
	3.2 命題線形時間論理
	3.3 1階の線形時間論理
4. 分岐的時間論理技術的基礎
	4.1 樹状構造
	4.2 命題分岐的時間論理
	4.3 1階の分岐的時間論理
5. 並行計算:その基礎
	5.1 非決定性と公平性による並列性のモデル化
	5.2 並列計算抽象モデル
	5.3 並列計算の具体的なモデル
	5.4 並列計算の枠組みと時間論理の結び付き
6. 理論見地から時間論理
	6.1 表現可能性
	6.2 命題時間論理の決定手続き
	6.3 演繹体系
	6.4 モデル性の判定
	6.5 無限の対象の上のオートマトン
7. 時間論理プログラム検証への応用
	7.1 並行プログラム正当性に関する性質
	7.2 並行プログラム検証証明論的方法
	7.3 時間論理による仕様からの並行プログラム機械合成
	7.4 有限状態並行システム自動検証
8. 計算機科学における他の様相論理時間論理
	8.1 古典様相論理
	8.2 命題動的論理
	8.3 確率論理
	8.4 不動点論理
	8.5 知識


第17章  関係データベース理論の構成要素
	P.C.Kanellakis:鈴木 晋

1. 序論
	1.1 動機と歴史
	1.2 内容についての案内
2. 関係データモデル
	2.1 関係代数と関係従属性
	2.2 なぜ関係代数か
	2.3 なぜ関係従属性か
	2.4 超グラフデータベーススキーマの構文について
	2.5 論理データベース意味について
3. 従属性データベーススキーマ設計
	3.1 従属性の分類
	3.2 データベーススキーマ設計
4. 問合わせデータベース論理プログラム
	4.1 問合わせの分類
	4.2 データベース論理プログラム
	4.3 問合わせ言語と複合オブジェクトデータモデル
5. 議論:関係データベース理論のその他の話題
	5.1 不完全情報の問題
	5.2 データベース更新の問題
6. 結論


第18章  分散計算モデル手法
	L.Lamport and N.Lynch:山下 雅史

1. 分散計算とは何か
2. 分散システムモデル
	2.1 メッセージ伝達モデル
	2.2 それ以外のモデル
	2.3 基礎的概念
3. 分散アルゴリズムの理解
	3.1 挙動の集合としてのシステム
	3.2 安全性と活性
	3.3 システム記述
	3.4 主張に基づく理解
	3.5 アルゴリズムの導出
	3.6 仕様記述
4. 典型的な分散アルゴリズム
	4.1 共有変数アルゴリズム
	4.2 分散合意
	4.3 ネットワークアルゴリズム
	4.4 データベースにおける並行性制御


第19章  並行プロセス操作的および代数意味論
	R.Milner:稲垣 康善,結縁 祥治

1. 序論
2. 基本言語
	2.1 構文および記法
	2.2 操作意味論
	2.3 導出木と遷移グラフ
	2.4 ソート
	2.5 フローグラフ
	2.6 拡張言語
	2.7 その他の動作式の構成
3. プロセスの強合同関係
	3.1 議論
	3.2 強双模倣関係
	3.3 等式による強合同関係の性質
	3.4 強合同関係における置換え可能性
	3.5 強等価関係上での不動点の唯一性
4. プロセスの観測合同関係
	4.1 観測等価性
	4.2 双模倣関係
	4.3 観測合同関係
	4.4 プロセス等価性上での不動点の唯一性
	4.5 等式規則の完全性
	4.6 プロセス等価性に対するその他の概念
5. 双模倣等価関係の解析
	5.1 等価性の階層構造
	5.2 階層構造論理的特性化
6. 合流性をもつプロセス
	6.1 決定性
	6.2 合流性
	6.3 合流性を保存する構成子
7. 関連する重要な文献

2010-07-09

ビジネスロジックをストアードプロシージャで実装してはいけない

ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジッククライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。

ストアードプロシージャと単体テストは食い合わせが悪い

RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語デバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語記述した場合よりもはるかに時間がかかる。

また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。

さらに、カバレッジツールは大抵の場合使えないだろう。

ストアードプロシージャは、たいていの場合、静的解析が行えない

ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。

ストアードプロシージャは、バージョン管理されたコードとの整合性に問題がある

仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイル管理し、それをバージョン管理システムに含めたとしても(というか、最低そうすべきなんだが)、あるリビジョンコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。

ではトリガーはどうなのだ

リガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。

さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。

では一体いつストアードプログラムを使うのか

一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合

もう一つは、複数クライアント言語で同一データベースを使用することが決定済みな場合

2010-07-07

コミュ教の陰謀

コミュ力は鍛えられる。

自転車に乗る練習と同じだ。

けど、コミュ力に優れている(というか劣っていない)人は、そのことを秘密にする。

コミュ力が低いことを、人格とか人生経験の未熟さに起因させようとする。

ひと言で言うと、「お前はまだ剥けてない。一生、剥けない」というのだ。

宗教での秘儀みたいなもんだ。割礼だ。

アドバイスするなら具体的な鍛え方を言えばいいだけなのに、わざわざ人格の問題にする。

そんなに実力に違いがあるのだろうか。いや、ない。

あっさりと追いつかれるから、教えないだけなのだ。

あるいは、それを言語化する能力に欠けるだけなのだ。

日本語ができることと、コミュニケーションができることは、違う能力だ。

だから、別個に鍛える必要がある。

とりあえず、飲み会ではオウム返ししてりゃいいよ。

あとは、ニコニコ笑ってりゃいいよ。

そんで、あいさつ。

それで8割がたはOKだ。

練習すれば、脳内スキーマが形成されるので、

苦もなくできるようになる。

コミュ力とか抽象的に悩むなんて、

そんな冥府魔道を歩む必要はない。

2010-07-02

XmlSerializer vs SoapFormatter

.NETオブジェクト永続化によく使われる、この二つのクラスの違いについて書きます。サンプルコードなどは書きませんので必要ならリンクを参照してください。ずいぶん古いネタだけど、許してね。

全体的に速度が重要場合永続化するオブジェクトが単純な場合XmlSerializerを、それ以外の場合SoapFormatterを使うのが良いと思う。なるべく短いコード量で行きたいならSoapFormatterの方がベター

あと、細かいことだけどTypeConverterは便利なので使うべし。シリアライズ不可能な小さなクラスとか特に有効。

2009-12-20

ビジネス・生活-1

日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介

あなたは、日本依存症にかかっていませんか?

日本依存症とは、日本でしか仕事を得られず、

日本でしか生活ができなくなる、危険病気です。

日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。

会社依存症の恐ろしさとその回避策

会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。

会社依存症にかかると、その会社経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。

また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。

上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くのが憂鬱になっても、そこに居続けるしかありません。

なぜなら、その会社を辞めると、ほかに行くところがなくなり、路頭に迷ってしまうからです。

このため、このことがよく分かっているエンジニアなどは、その会社の独自製品や独自環境でしか通用しないスキルしかたまらないような仕事をできるだけ避けるようにします。

そして、「広く普及しており、かつ中長期的に需要があり、供給が不足ぎみで、かつ陳腐化しにくいスキル」を戦略的に蓄積します。

たとえば、以下のようなものが考えられます。

・要求分析、要求仕様定義システムアーキテクチャ設計RDBスキーマ設計サーバの負荷分散設計、各種サーバパフォーマンス解析・チューニングデザインパターンマルチスレッドプログラミングシステム管理ネットワーク管理

マネージメントプロデューサ・デザイナ・経営者・営業・顧客との交渉スキルや連係プレースキル

普遍性の高いコンピュータサイエンスの基礎

UnixRDB正規表現JavaPerlTCP/IP.NETC#

日本にはたくさんの会社があり、それぞれが浮き沈みを繰り返しています。

いまいる会社が今後もずっと浮いたままだという保証はありません。

一つの会社依存しきると、その会社が沈むとき自分まで一緒に沈んでしまい、酷い目に会います。

いまいる会社が沈みそうになったら早めに別の会社へ移れるように準備しておくべきではないでしょうか。

国家依存する危険

国家に対しても同じことが言えます。

政府は全ての国民幸せにするような政策を実行するべきですが、必ずそれに成功するとは限りません。

ときに間違った政策を行い、多くの犠牲者を出すこともあります。しかも、その犠牲者を救済するための政策が実行されないこともあります。

もっと最悪なことに、間違った政策で、国全体が沈んでしまうようなことすらあります。

もちろん、そうならないように、われわれは選挙で正しい政策を実行してくれる政治家投票すべきですが、常に正しい政策を実行してくれる政治家自分選挙区から立候補してくれるとは限らず、自分以外の人々が常に正しい政策を実行してくれる政治家投票してくれるとも限らないというのが、世の中の現実です。

だから、どんなに自分が正しい政治行動を取っていても、おかしな政策が実行され、自分の将来が危うくなるリスクは常に存在します。

たとえば、金持ちばかりが得をし、平均的な労働者搾取される最悪の格差社会になってしまうかもしれません。

あるいは逆に、今後スキルアップし、キャリアアップし、実力を身につけて高い年収をゲットしようと思っているのに、高額所得者所得税が大増税されて、酷い搾取に苦しむようになるかも知れません。

あるいは、少子化対策で、実質的独身税をかけられたのと同じような状態になり、結婚するつもりも子供を作るつもりもない人たちの生活の質がかなり落ちるかも知れません。

あるいは、国の医療システムが疲弊しまくって、まともな医療サービスを受けられなくなるかも知れません。あるいは、まともな治療を受けようとしたら、恐ろしく高い料金を徴収されるようになってしまうかもしれません。

あるいは、地方格差を埋めるため、都市部の住民を徹底的に搾取し、地方にじゃんじゃんばらまくような政治が行われるかもしれません。そうすると、田舎に住む人間の暮らしはよくなるかもしれませんが、今後も都市に住み続けるつもりの人間の暮らしの質が大きく低下するかも知れません。

あるいは、非正規雇用を減らし正社員を増やすという名目で、おかしな規制がかけられ、予期せぬ副作用が出て逆に多くの人が職を失うことになるかも知れません。余波で、自分まで失職するかもしれません。残された正社員自分に酷いしわ寄せが来るかも知れません。

労働者保護消費者保護という名目で、過剰に企業の手足を縛るような規制がかけられて、企業の活動が阻害されて経済が悪化したり、企業がどんどん日本から逃げ出すかも知れません。雇用が減り、治安が悪化し、日本が住みにくい国になるかも知れません。

要するに、投資において、全ての資産を一点がけするのが危険投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。

今までは日本世界一豊かな国だったので、

この国にずっと住み続けるのが一番賢い戦略でした。

しかし状況は変わりました。

いまや日本よりも豊かな国や都市がどんどん生まれつつあります。

日本などよりも、はるかに先行きの明るい国や都市がたくさんあります。

本来、この惑星には、たくさんの国家があり、それぞれ浮き沈みを繰り返しています。

いまいる国家が、今後もずっと浮いたままだという保証はありません。

一つの国家依存しすぎると、その国家が沈んでいくとき、酷い目に会います。

いまいる国家が沈みそうになったら、早めに別の国家に移れるように、準備しておくべきではないでしょうか。*1

国家依存症愛国心は別の話

こういうことを言うと、「おまえに愛国心はないのか?」と言い出す人間が時々いますが、依存症愛国心とは別の話です。

これは、結婚において、夫を愛していることと、夫に依存することが異なるのと同じことです。

経済的にも精神的にも自立していることと、夫を愛することは両立します。

夫婦仲は冷め切っていて、夫の暴力に怯えながら暮らしているにもかかわらず、夫に経済的に依存しているためにガマンし続けているような状態は、とても健全だとは言えません。

むしろ、特定の国にまったく依存していないにもかかわらず、その国を愛し、その国に貢献することこそ、純粋に打算抜きの愛国的な行為なのではないでしょうか。

そもそも、「いろんな異性とつきあってみて、そのなかから最高のパートナーを見つけ出して結婚する」というのは、少しもおかしなことではありません。

「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です。これは国家についても同じことです。たまたま日本に生まれたからと言って、日本と一生添い遂げなければならないということはありません。

むしろ、さまざまな国に住んでみて、そのなかから、自分にいちばんあった国に落ち着き、添い遂げる、という人生も十分にありなのではないでしょうか。

日本以外にも快適に暮らせる国や都市はたくさんある

日本以外で暮らしたことのない人々の中には、日本だけが世界で唯一暮らしやすい場所で、日本以外には暮らしやすい場所などないと信じて疑わない人もときどきいるようですが、そんなことは決してありません。

むしろ、日本よりもはるかに、晴天の日が多く、気候が温暖で、からっとさわやかで、毎日気持ちよく暮らせる国や地域がたくさんあります。

食べ物も美味しく、人々も気持ちよく、街の各種施設も充実しており、遊び場所もたくさんある快適な都市世界中にたくさんあります。

どんなところでも、けっこう住めば都なのです。

また、日本以外の国は治安が悪くて暮らしにくいという偏見を持っている人もいますが、どんな国でも、きちんとした安全対策を講じ、危険地域に近寄らないようにすれば、それなりに安全に快適にくらせるものです。

それに、どうせネット環境さえあれば、世界中どこでも、twittertumblrmixiで遊べるし、ブログコメント欄クネクネすることもできるし、2ちゃんでだらだら過ごすことも出来るし、エロ画像ダウンロードすることもできるし、はてブ脊髄反射的なコメントを付けることもできるし、はてなスターを連打しまくって顰蹙をかうこともできるのです。

「わたしは(この国に生まれたというより)この惑星に生まれたのだ」という感覚を持ちながら生きるというのは、広々とした感じがして、なかなか気持ちの良いものです。

せっかくこの美しい惑星に生まれたのに、日本という小さな小さな島国に引きこもったまま一生を終えるのは、じつにもったいないことではないかと思えてきます。

依存症からの脱出は難しい

ギャンブル依存症アルコール依存症買い物依存症恋愛依存症セックス依存症、たいていの○○依存症は、そこから抜け出すのに苦労するように、日本依存症も、一度それにかかると、そこから抜け出すのにかなり苦労します。

簡単に日本依存症を抜け出す方法などありません。

また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。

資産運用、または、プチ資産運用による脱日本依存

日本依存症から抜け出す一番効果的な方法は、実は、英語力をアップすることではなく、日本の外でも安定した収入源を得られるようにすることです。(もちろん、最低限の英語力は必要ですが)

特定の国家依存しない収入源を確保するわけです。

これに一番効果的なのが、資産運用で暮らせるようにすることです。

利回りのよい債権株式自分資産分散投資し、運用することは、どこの国に居住していてもできます。

日本国債株式資産運用していたとしても、日本に住んでいなければ運用できないということはありません。世界中どこに住んでいても、日本国債株式資産運用することは可能です。

それどころか、そもそも、日本国債日本株式資産運用しなければならないということはありません。

むしろ、全資産を円ベースに一点がけしてしまうと、今後円安が進んだときに、自分資産が大きく目減りしてしまうというリスクを抱え込むことになります。

資産は、全世界分散投資しておいた方が安全だし、世界全体の経済は、多少の波はあるものの、中長期的にはつねに成長し続けているので、正しくポートフォリオを組んで、世界中分散投資しておけば、それほどひどいことにはなりません。

だから、いったん資産運用で暮らせるだけの資産を蓄積してしまえば、日本依存症からの脱却はかなり容易になります。

ここで、「日本キャピタルゲイン課税の大増税を行ったら、資産運用では暮らしていけなくなるのではないか?」という疑問がわく人もいるでしょうが、そうでもありません。

まず、税金の徴収には、属人主義と属地主義の二つの方式があります。

属人主義とは、その人間国籍のある国に税金を納めること。

属地主義とは、その人間が居住している国に税金を納めること。

日本属地主義なので、自分が居住している国や地域税金を納めることになっています。

このため、日本キャピタルゲイン課税の大増税が行われたとしても、海外で暮らしている限り、影響を被ることはありません。*2

現在、属人主義を採用しているのは、アメリカフィリピンぐらいなもので、極めて例外的なケースです。

ですから、今後日本が属人主義に変更するリスクは、とても低いと思われます。

また、万一、日本が属人主義に切り換えたとしても、ある程度の資産を持つ人間国籍を与えてくれる国は、けっこうあります。

日本が属人主義に切り換え、さらにきわめて重いキャピタルゲイン課税をかけてきたら、単に国籍を切り換えればいいことです。

ただ、問題は、資産運用で暮らせるようになるほどの資産を蓄積することが難しい、ということです。

そのため、当面は、収入の全てを資産運用だけで稼ぎ出すのではなく、収入の一部だけでも資産運用で稼ぎ出すような状態を目指してみてはどうでしょうか。

資産運用というより、プチ資産運用です。

そうすると、日本がヤバくなったので、脱出して海外で職を得たのはいいが、最初のうちはまだ英語にも不慣れで、十分な収入を得られないというようなケースでも対応できます。

世界標準のITスキルによる脱日本依存

たとえば、前述のUnixWebRDBJavaPerl.NETC#など、世界中に普及している技術の場合、そのスキルを身につけることで、日本依存から抜け出すことができます。

また、これらに関連する要求仕様定義オブジェクト設計技術デザインパターンを適切に使いこなしたクラス設計プロジェクトマネージメントスケジュール管理なども、特定の国家依存しないスキルです。

これらのスキルを身につけたITエンジニアは、さまざまな国で職を得ることが出来ます。

実際、ボクの知り合いでも海外で働いているプログラマーがいます。

むしろ、日本よりも快適に働いているようです。

もちろん、これらの技術は、会社依存症から脱却するための技術としても有効で、きわめて安全性の高い技術だと言えます。

これらの標準的なITスキルは、このように、会社国家を超越して有効ですが、それ以上に驚きなのは、かなりの長い時間をも超越する力を持っているということです。

たとえば、unixの基本アーキテクチャはボクが知っているだけでも十数年、ほとんど変わってません。マルチスレッドプログラミングデザインパターンも十数年前に身につけたスキルは、かなりの部分、いまでもそのまま役に立ちます。はるか昔に覚えた、クロージャ再帰を使ったさまざまなプログラミングテクニックも、RDBスキーマ設計スキルも、ほとんどが、いまだに現役です。

TCPUDPIPHTTPSMTPPOPなどのプロトコル類もいまだに基本はほとんど変わりません。新しく登場した.NETC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。Haskellのような関数型言語ですら、似たようなコンセプトのプログラミングアーキテクチャは昔からあり、十数年前にマスターした技術の延長線上でなんなくマスターできます。

このように、長期的に安定した技術スキルを選んで身につけるようにすれば、会社国家時間を超えて、安定した収入源を確保できるのです。

ただ、注意しなければならないのは人材の需給バランスです。とくに、インドや旧共産圏からのプログラマの大量供給は要注意です。

一方で、ヨーロッパBRICsVISTAなど、世界中で急速に経済が発達しており、ITエンジニア需要が今後も全世界的に巨大化し続けるのは確実です。

ここでのポイントは、下級エンジニアや中級エンジニアは、需要はそれほど拡大しそうにないのに、供給は膨大になると思われるので、リスクが大きいということです。

つまり、下級エンジニアや中級エンジニアの場合、海外に行くと、日本にいたとき以上に悲惨になる可能性があります。安易に日本から出て行くべきではないでしょう。

一方で、上級エンジニア技術分野にもよりますが、今後、世界中で爆発的に需要が拡大することが見込まれていますが、供給が不足する可能性は十分に考えられます。

従って、自分が今後上級エンジニアになる可能性があると考えている人たちは、この戦略に沿って日本依存症から脱却しておいたほうが良い可能性が高いです。

あと、もう一つ考慮すべき点は、上級エンジニアになるような人は生産性が高いため、今後、高額所得者になる可能性があるということです。

現在日本では、格差是正の機運が大きく盛り上がっています。

今後、この機運の盛り上がりに押されて、高額所得者を狙い打ちする形で大増税が行われ、酷い搾取の対象にされるリスクもあります。

このリスクに対する保険という意味でも、早めに日本依存症治療し、いつでも仕事と生活の場を海外に移せるようにしておいた方が安全かもしれません。

●スモールビジネスによる脱日本依存

日本人海外で暮らしてみると、さまざまな小さなニッチビジネスのチャンスに気がつくことがあります。

たとえば、日本にはあって当たり前なのに、その国にはない商品やサービス

それは、日本のやり方を現地方式にアレンジすれば、それなりに繁盛する商売ができるかもしれません。

あるいは逆に、その国のおもしろい商品やサービスで、アレンジすれば日本でもウケそうなもの。

もしくは、現地の安い人件費を利用して、何かを作らせ、日本に持ち込むというパターンもあるでしょう。

実際、ネパールに小さな工場をもっていて、そこで自分デザインした服を作らせ、日本に輸入して販売しているという女性に会ったことがあります。

こういうビジネスネタをみつけたとき、スモールビジネスを興すスキルを持っていると、そのチャンスを活かして、その国で商売をはじめることができたりします。

とくに、最近急速に豊かになったアジアの国々では、日本がかなりブランドになっています。

とくに富裕層は、日本のさまざまな質の高い品々やサービスを求め、日本の産物に信仰のようなものを抱いています。

これをうまく利用することで、いろいろなニッチビジネスを作り出すことができるかもしれません。

スモールビジネススキルとは、小さな会社向けのマーケティングマネージメント、経理などのスキルです。

たとえば、どんな小さなビジネスでも、どんな商品を、どんな顧客に売るのか、そのために、商品にはどのような魅力がなければならないのか、顧客は、どういう理由でその商品にお金を払うのか、どのようにして利益が出る構造になっているのか、などのビジネスモデルを組み立てなければなりません。

そして、いざ、ビジネスプランが出来たら、場合によっては人を雇い、契約を結び、信頼関係を作り上げ、法律に則って取引しなければなりません。関係者全員が気分良く仕事できるように、win-win構造を作り出す必要があります。

また、さまざまな法律を調べ、その法律に則ってビジネスを運営する必要があります。

さらに、会社を設立し、会計ソフトで帳簿を付け、経理と資金の管理をする必要があります。

また、予算計画を立て、融資なり出資なりで資金を調達する必要もあります。

こういう小さなビジネスを最小限の規模ではじめてみて、いざ、顧客の反応が上々だったら、しだいに規模を拡大していけばいいのです。

思ったより反応が悪ければ、早期に撤退するか、あるいは、やり方を変えて再度トライしてみたりすればいいでしょう。

そして、スモールビジネス醍醐味は、たまたま大ヒットしたときのうまみです。

日本サラリーマンの頂点とも言える、上場企業社長年収でも、たかだか4000万円にしかなりません。

これに比べ、スモールビジネスをヒットさせた場合、実質的年収1億円を優に越えてしまうということは、それほど珍しくないのです。

実際、ぼくの知り合いにもそういう人がいます。

「たかが自営業」とばかにできるようなもんでもないのです。

自営業は、あたると凄いんです。

●共通して必要な日本脱出アイテム

どのようなモデル日本依存を脱却するのであれ、共通して必要な Permalink | 記事への反応(0) | 22:10

ログイン ユーザー登録
ようこそ ゲスト さん