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

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

2018-12-04

増田プログラマー養成講座 その23 SQLを巡る物語

前回は、データベース設計について学びました。

今回は、その他のデータベース話題について見てみましょう。

 

 

リレーショナル・データベース理論

問合型言語SQLは、「関係代数」という計算モデルを基に作られたプログラミング言語

一度「関係代数」について学んでおくと、RDBの使い方について、理解が深まる。

↑このスライド作者さんは他にもDB関係資料作成されてるので見ておくといいかも?

 

 

SQL以外の問合型言語

SQL以外にも「SPARQL」、「TMQL」(Topic Maps Query Language)等、いろいろな問合型言語がある。

実際に使う機会は少ないかもしれないが、「問い合わせ」で処理するという発想は参考になるかも?

 

Datalog

Datalogは「Prolog」(論理言語)を源流にもつ宣言的なデータベース問合せ言語。DatalogはSQLと同等の表現力を持つ。

Datalogは様々なプログラミング言語で利用できる。

 

トピックマップ

トピックマップ」は、本の索引もっと機能にしたような仕組みで、RDBとは違う形でデータを蓄積/検索できる。

 

 

RDB以外のデータベース

SQLを使わないデータベースもある。

 

NoSQL

NoSQL一般に "Not only SQL" と解釈される)とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である

関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合操作を利用しないこと(場合によっては単にそのような機能が欠落しているだけ)、水平スケーラビティが確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。

学術的な世界では、この種のデータベースのことを構造ストレージ (structured storage) と呼ぶことが多い。

 

NoSQLデータベースは、関係データベースのような汎用性は欠くものの、その制約された条件下ではRDBMSより高いパフォーマンスを持つ。

そのためビッグデータソリューションでしばしば活用される。

NoSQLデータベース管理システム有用な場面は、関係モデル必要としないデータを扱う時や、大量のデータを扱う時である

 

有名な実装として、GoogleBigTableアマゾンAmazon DynamoDBなどがある。オープンソース実装も数多く存在し、例えばMongoDBRedisApache HBase、HyperTable, Apache Cassandraなどがある。

 

 

SQLRDBに慣れたら、NoSQLも調べてみよう!

 

 

その他、データベース関係話題

DB運用管理で学んでおきたい話題を列挙してみよう。

 

 

SQL開発物語

問合型言語学習最後に、SQLを巡る物語も見てみよう。(SQL学習ドラマチックで楽しいものにしたいねw)

 

 

RDB活用すれば、大量のデータを処理して、多くの仕事効率化できる。(金持ちへの扉が開かれる。)

暇があったら、SQL物語登場人物も見ておこう。

 

エドガーフランク・コッド(Edgar Frank "Ted" Codd, 1923年8月23日 - 2003年4月18日)は、イングランドまれ計算機科学者

関係データベース理論的基盤であるデータベース管理関係モデル発明した。

 

1960年代から1970年代、コッドはデータ配置に関する理論を構築し、1970年 "A Relational Model of Data for Large Shared Data Banks" (大規模共有データバンクのデータ関係モデル)という論文を発表した(IBM内ではその1年前に公表している)。

しかし、IBMライバルがそれを実装し始めるまで彼の提案を実行に移そうとせず、コッドは失望した。

当初、IBMはIMS/DB収益を守るため、関係モデル実装することを拒んだ。

コッドはIBM顧客自身モデル実装した場合可能性を提示し、顧客からIBM圧力をかけさせた。

そこでIBM関係モデル実装を開発する System R プロジェクトを Future Systems プロジェクトに含める形で立ち上げたが、その開発チームとコッドは分離され、しかもコッドの理論精通した者はチーム内にいなかった。

結果として彼らはコッドの Alpha 言語を使わずリレーショナルでないSEQUEL言語を開発した。

 

ラリーエリソンSEQUEL 完成前に発表された論文に基づいて Oracle を完成させ、先に発売している。

IBMは、SQL/DS を発売した。

幹部技術音痴だと、部下の名案も却下してしまうんですね?

 

ローレンス・ジョセフ・エリソン(Lawrence Joseph Ellison、1944年8月17日 - )は、データベースソフトをはじめとする大手ビジネスソフトウェア企業オラクルコーポレーションの共同設立者であり、元CEO会長CTOである

2014年現在総資産は500億ドルで、世界で5番目の富豪である

 

ニューヨーク出身アシュケナジムユダヤ人母親フローレンススペルマン(Florence Spellman)は出産当時未婚の19歳で、生後9ヶ月のラリーシカゴに住む叔母リリアンエリソンとその夫である義理叔父ルイスエリソン養子として引き取ってもらった。ラリーは実の母の名も知らず育ったが、48歳の時に初めて対面した。

 

高校時代秀才だが、無愛想な生徒だった。イリノイ大学アーバナシャンペーン校に二年生まで通っていたが、リリアンの死後まもなく退学。カリフォルニア州北部で夏を過ごした後、シカゴ大学で学ぶために実家に戻ったものの三ヶ月でまたも退学し、カリフォルニア移住。この頃、コンピュータに触れ始めている。

 

1970年代エリソンはアンペックスで働いた。彼の関わったプロジェクトのひとつCIA向けデータベース開発があり、彼はそれに「オラクル (Oracle)」と名づけた。

エリソンエドガー・F・コッドのリレーショナルデータベースシステムに関する論文 A Relational Model of Data for Large Shared Data Banks に触発され、1977年自己資金1400ドルオラクル設立した。

彼はIBMのSystem Rデータベースがコッドの理論に基づいたものであると聞き、Oracleもこれと互換性のある製品にしたかったのだが、IBMエラーコード秘密にすることによって互換製品が出てくるのを防いでいた。

オラクル最初製品Oracle 2であり、Oracle 1は存在しない。このリリース番号は、それ以前のバージョンバグが全て解決されていることを暗示しようとして付けられた。

 

1997年8月ラリーエリソン親友スティーブ・ジョブズアップルに戻った後、同社の取締役就任した。2002年9月20日取締役会に出席する時間が充分に取れないことを理由アップル取締役を辞任した。

この人、キャラクター的にはあまりきじゃないけど、行動力はすごいね

コッド博士論文を見て自分RDBを作っちゃった!

Oracleバージョンを「2」から始めて、改良されているように見せかける。~ちょっと詐欺っぽいけど、商売うまい?w

 

 

 

SQLデータベース活用して、素敵なアプリWebサービスを開発してください。

では、これでいったん、増田プログラマー養成講座を終了します。

御清聴いただき、どうもありがとうございました。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラム=データ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミングの練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181111205255 増田プログラマー養成講座 その21 データベース設計 (1)要件定義

anond:20181119224031 増田プログラマー養成講座 その22 データベース設計 概念物理

anond:20181204142213 増田プログラマー養成講座 その23 SQLを巡る物語 ←★今ここ★

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-26

増田プログラマー養成講座 その12 データベース参考書

前回は、MySQLphpMyAdminを使って、リレーショナル・データベースRDB)を少し触ってみた。

今回は、RDBの使い方や仕組みについて理解を深めるための資料を探してみよう。

 

本は、買う価値のある本と、買わなくてもいい本の2種類があるね。

  • 買う価値のある本:何度も読み返す本。
  • 買う価値のない本:1度読んだら終わりの本。(図書館で借りる。図書館にない場合は買う。読み終えたら古本屋などに売却)

どちらの本かは自分判断で決めよう。(1度で理解できない本は、何度も読み返すことになるだろう。)

 

初めてRDBを使う人のためのガイダンス

本書は,新人エンジニアデータベース全般について勉強したいとき最初に読む本です。

データベースに関する知識を広く浅く網羅的に紹介してた。

最初に読めば、DB全体を俯瞰する地図を手に入れたようなもの。その後の見通しが良くなる。

 

入門書(初級レベル

本書はMySQLをはじめて触る方を対象として,開発環境の準備からSQL基本的な書き方,PHPによるWebシステム開発まで,図解でわかりやす解説します。

MySQL入門書カラフルな図解が分かりやすい。

まずは、データ操作の基本「CRUD」(Create=追加、Read=取得、Update=更新Delete=削除)を理解しよう。

CRUDが分かれば、DBを使ったWebアプリを作れる。→ここがIT土方の最低レベルだぜ!

 

豊富な図解とていねいな解説により、やさしく・楽しくデータベースSQL学習できる入門書です。

本書は、データベース操作する問合型言語SQL」の文法練習できる。

SQLが読める&書けるようになれば、RDBを使ったプログラミングで苦労しなくなる。

 

 

 

上記2冊の入門書程度の知識を身に付ければ、RDBに関しては初心者から脱却できるはずだ。

RDBを使うプログラムを作るなら、まずはこの程度の知識クリアしておけば、十分だろう。


次の段階では、既存DBを使うだけでなく、「ゼロからDB設計、構築してくれ」と頼まれるようになるはずだ。

時間があったら、DB設計スキルを身に付けておこう。

(以下の話は、今の段階では無視してもOKRDBにある程度慣れたら読んでみて!)

 

 

 

ミックさんのDB

データベースの本はいろいろあるけど、「ミック」という人が書いた本はRDBの要点がまとまってるので、なるべく早い段階で一通り目を通しておくことをお勧めする。(ミックさんの本は買って何度も読み返してる。)

 

DOAデータ中心アプローチ

RDB設計方法はいろいろあるが、古典的手法として「DOA」(データ中心アプローチ)がある。

なぜこの古臭いDOAが、今でも重要なのだろうか?

DOAと、他の「OOAObject Oriented Approach:オブジェクト指向アプローチ)」「POA(Process Oriented Approach:プロセス中心アプローチ)」を比較した図を見てみよう。

OOAは、言い方を変えれば、

[ユーザー] ←→ [プログラム] ←→ [DB]

という流れになっている。

まりユーザーから見ると、間にある[プログラム]は、[DB]を包んでいる「ラッパー」でしかない。

=[DB]のデータ構造スキーマ)さえシッカリしていれば、間にある[プログラム]は取り替えてもあまり困らない。

 

RDBを使うシステムなら、DB設計プログラム設計よりも重要になる。

(後で[プログラム]を変更するよりも[DB]を変更する方が影響は大きい)

から今日でもDOAは十分に役立つ手法だと思って理解して欲しい。

 

DOAは、ざっくりと3ステップでやる。

  1. 分析会社業務などを分析して、データCRUDが発生してる所を列挙する。
  2. 論理設計データ間の関係分析して、「ER図」を作る。
  3. 物理設計ER図を基にして、DB設計する。

慣れたらER図を書かなくても、頭の中で思い浮かべるだけでもテーブルを作れるようになる。

 

最初DOAを知っておけば、今後他の設計方法を使うときでも、比較検討基準として使えるので、損はないはずだ。

それでは、DB設計の本を見てみよう。

 

DB設計(中級レベル

初級者が押さえておくべきDB設計の基礎知識ポイント正規化非正規化のケーススタディテーブル設計のやってはいけないバッドノウハウ、注意すべきグレーノウハウなどを丁寧に解説します。

DB設計入門書。著者はミックさん。

DOA正規化階層構造木構造)のデータの扱い方など、DB設計の基本を網羅的に説明している。

 

現場で使えるアイデアが満載 デキるDBエンジニアになろう!

私が設計スキルを付けるために実際に行ってきた「身の回りのものを題材にERDを書く」という方法サンプルを今回は8種類書き下ろさせていただきました。

手前味噌ではありますが、本書をお読みいただき実践していただくことで「実務で具体的に手が動く」というレベルに達していただけると考えています

DB設計入門書

DOAの考え方、ER図の書き方などが説明されている。

 

RDB理論上級レベル

RDBSQLは「関係代数」という数学が、その基礎を支える理論になっている。

関係代数」などを解説

RDBを改造したり、自作したくなったら、RDB原理を知っておきたい。

この手のコンピューターサイエンスの本って、難しくてつまらない本が多いけど、この本は図解が多くて、珍しく分かりやすい本だったw

 

ネット

本の情報は、出版された瞬間から陳腐化が進む。

最新の情報は、ネット確認することができる。

 

公式サイトオンラインマニュアル

自分が使うデータベースマニュアルは最も基本的な1次情報になるので、不明点があったらまず確認するようにしたい。

など、公式サイトオンラインマニュアルをチェックしておこう。

 

ミックさんの解説記事

ミックさんは、ネットでもDB技術論の記事を公開されており、参考になるかも?

(↑無料Webサーバー「Yahooジオシティーズ」は2019年3月閉鎖予定なので、読むなら今のうち?)

 

階層構造になっているデータカテゴリー情報など)をRDBに保存するとき、主なやり方が3通り紹介されてた。(上記の本でも紹介されてる)

  1. SQLで木と階層構造データを扱う(1)――入れ子集合モデル
  2. SQLで木と階層構造データを扱う(2)――経路列挙モデル
  3. SQLで木と階層構造データを扱う(3)――入れ子区間モデル

自分は(2)の「経路列挙モデル」が分かりやすくて、いつも使ってる。

 

…という具合に、ネット上の公開記事にも参考になる情報がたくさんあるよ。

(ここまでの説明URLを9個張ってしまったので、もうこれ以上URLを張れない。><

他にもGoogle検索などで役立つ記事を探してみよう!(唐突な締めw)

 

NoSQL

データストア(データを保存する道具)は、RDB以外にもいろいろある。→「NoSQL」とか呼ばれている。(自分検索してみてw)

RedisHadoop、ElasticSearch、OpenStack…いろいろな道具が発明されてるね。

RDB以外のデータストアを使うときでも、RDBと相違点を比較しながら学べば、取っ掛かりが持てて、理解スムーズになるだろう。

RDBは、知っておいて損はない。使いまくって、体得しよう!

 

まとめ

RDBSQLパズルみたいなものから、楽しんで学んで欲しい。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書 ←★今ここ★

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-17

anond:20181017171545

スキーマ理解できる人はCREATE文書けるでしょ。順序とか間違えるかもしれんが。

anond:20181017170940

ORMのスキーマを書けるならCREATE文は書けなくても問題ないだろ! いい加減にしろ! 

2018-06-05

保育園にいつつコンセンサスを得ているシンパパが順調すぎて逆に怖い

先般ムスコが通う保育園の0カラットコミュニティ懇談会トレンド入りした。

保護者担任合わせてヴァイジンテュープル名程の出席者のコンテンツに一人だけスティーブ・ジョブズさん(西海岸出身)がいた。

このスティーブ・ジョブズさん入園式も確かぼっちアポイントメントしてたので圧倒的に成長してるなーとマクロ的な観点から俯瞰していた。

懇談会座談会ビジネススキームで皆キッズYouTuberの成長の様子や育児のディストレスなんかを話している中

順番がPDCAサイクルしてきたスティーブ・ジョブズさんが開口一番「2クォーター前にパートナーとは死別した はい、今の発言シェアしといてね」と涙目告白

またまた冗談を重みを感じる重い重い。家庭の事情なんてエヴィワン色々あるんだしこのコワーキングスペースで声を大にして言うこと??

契約破棄したと思われるの嫌だったとか?自己スキーマ過剰でしょ#スティーブ・ジョブズ

付加価値としてその後ヘラヘラポジティブで会話に入ってくんの。なんか恐怖心。これメモっといた方がいいよ。

「未完了タスクが大量説明してみてください」って言われても男親とは仲良くなんて「自分軸」でできないんじゃなくて、あえてやらなかったんだし

これから時代保護者会のイベントなんかもあるコンテンツで、良いスティーブ・ジョブズアピールはし...取引先との商談が上手く行くこともなくて良いか

保護者クラスターには正直リリースしてほしくない

一種コワーキングスペースにいた他のママさんも思っていたんじゃないと言っても過言ではないかなぁ

以下追記

はてな匿名ダイアリーで取り繕う必要は無いと思わなくもなかったので

内なる「自分」のコンテンツに沸き起こった薄暗いスピリチュアルを包み隠さず『パワポ化』してみました。

このようなデータロジカルシンキングしてしま自分はラジカルにバイアス主義者なの、ってこの前読んだビジネス書に書いてあった。

ただパラドックスするようですがこの感情ハイリスク・ローリターンだろうなとグローバル的な観点から

はてな匿名ダイアリー言語化したと、つまり新しいアイフォーンだけエクスキューズさせてください。

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)に対して、

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

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

整理。

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

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

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

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

構成的関係

 :

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

因果的に関係

 :

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

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

ということはない。

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

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

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

科学(物質、プログラム

(構成的関係)

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

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

構成的関係←→因果関係

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

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

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

このエントリーをはてなブックマークに追加ツイートシェア

2011-12-07

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

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

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

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

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

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

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

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

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん