 
|
はてなキーワード: フローとは
・積ん読本がだいぶ減った。
・休日の読書を考える。積ん読本はよむのに土日まるまる潰れたりする。しかもストレスがたまるが、本屋で買ってきた本であれば１日で４冊読める。
読みたい気持が一番高まっているときに読んでるから精神的にも満足度が高い。積ん読本は義務感でダラダラ読んでストレスがたまり、得られるものも少ない。
・人にもよると思うが私は読んでない本が部屋に存在するとそれだけでイラッとする。
自分のフローから考えて、処理できそうな分を明らかに越えたストックを持ってはいけないと偉い人も言ってた。
積んでいいのは読み終わった本だけ。買ってから２週間以上たって読まなかった本はリストを作って売るか電子書籍化して保存したい。
今のところ電子書籍は読まない本を視界から消す or 読んだ本で、何度も手にとって読み返す程ではないがたまに引用したくなるようなやつを保存するため。
読んだことない本をいきなり電子書籍で得られてもまず買わない。でも歌うクジラは良かった。作品としては微妙だったけど体験する価値あり。
・そもそもAmazonで買うときは動機が「他人のススメ」で一時的に盛り上がってるから、という場合が多い。
２～３日間を開けて熱が冷めた頃には他人からの影響は消えており、かなり残念な結果になる。
書評ブログで紹介されている本こそ自分で本屋に足を運んでほんとに読みたいかどうか確認すべき。
・特に小説はどれだけ全体として良い話でも、文体や走り出しなど最初の１０ページの食いつきが悪いとすぐ積ん読化する。
自分が読みたい本以外は買うべきではない。無理して読むのはネットの向こうの他人じゃなく尊敬する人か親しい友人が強くすすめてくれた本だけでいい。
・Amazonで買えば値段的にはお得かもしれないが、私みたいに旬が短い人間には本屋メインのほうがいい。
積ん読にしたら安く買ってもただのゴミに金払ってるようなもんだし結局損してる。ちゃんと読む本だけ買えばいい。
あと金がそんなにあるわけではないけれど、読書に関してはやはり金より時間や心の盛り上がりの方が大事だと思う。
金ケチってマケプレで買うくらいなら図書館で借りてしまったほうがいい。
・ビジネス書の８割以上は、Amazonじゃなくて本屋で立ち読みすれば買わなくてもおｋな本ばかり。
読んでも欲しいのは数ページだけだったりして買うのもったいないとか思う。その程度なら暗記してしまえばよろし。
たまに、引用してブログで紹介したいと思うページとかあると悔しいけど買わざるを得ないけどすごいムカつく。
個人的にビジネス書は１ページ５０円とか１章２００円とかで部分的にお持ち帰りできる売り方をしてくれないかな。
iphoneのGhost Trickみたいに１章５０円とかで８つくらいに分ければ値下がり防げると思う。今の１冊８５円みたいな売り方は長期的に誰も得しない。
ビジネス書は精神のエロ本だと思うので、今までエロがメディアの進化を促してきたようにビジネス書が電子出版を支えるきっかけになってほしい。
Amazonのお薦めつながりは、似たような本ばっかりだからおや？って思う作品に出会うことは少ない。
「入門編」あたりだと関連本探す能力もないし、どれがいいかなと比較する際に他人の意見も役に立つが
ある程度自信がついてきた分野なら本屋で自分が判断したほうが正解が多い。
・本屋にも不満がないわけではない。Amazonのようなリンクする感覚がないのは辛い。
目当ての本がなかなか見つからないのもAmazon慣れしているとかなりストレス。
松丸本舗ってのがすごいらしい。一度いってみたい。
・もちろんこれは私の意見であって、他の人が同じようにやるべきだとは思わないし、どうせ言ってもやらないだろう。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
http://jbpress.ismedia.jp/articles/-/34121
この記事を書いた小松氏は、総務省（旧自治省）から南相馬市に出向している官僚が知り合いの医学生に宛てた記事を丸裸。
しかも、今は南相馬市の副市長という立場であって、総務省うんぬんではない。
内容は、医学生が給食をミキサーにかけてホールボディカウンターで計測したら？という提案を南相馬市に出したことが発端。
きちんと手順を踏まえて提案するならまだしも、思いつきで出した内容に対して、総務官僚は、筋を通して話をしてくれっと言っただけ。
もうね、ひどすぎる。本当にひどい。
やさしく解釈すれば、一方的な現場を知らない論調による見解の相違。
現場で長期に踏みとどまって本気で考えている立場と一時的な思いつきで考える立場の違い。
「給食をミキサーにかけてホールボディカウンターで計測する」
しかし、この検査をいつまで誰が実施し、そのデータをどのように公表し、その結果を踏まえてどのように対処するか、ヒト、モノ、カネ、情報の流れが明確ではないのが問題。
しっかりと最後までのフローを明確にしなければ、単に不安を煽るだけで、提案した側の自己満足にしかならない。
だから、総務官僚は、きちんと筋を通して提案してくれっと回答しただけ。
毎日計測した結果をどこに出すのかわからないけれど、子供たちに放送するのかい？
それに、こうした情報を親は「本当に」知りたいのだろうか。
きちんとニーズ調査をしたのだろうか。
押しつけの提案ではないのか。
知りたくない親に対して、バカだとかアホだとか言う人もいるかもしれない。
しかし、実際、この地域に残って住んでいる人は、低線量の被爆を覚悟している人たち。
今、残っている人（踏みとどまっている人）は、もう被爆については、耳を閉ざしている人たちなんだよ。
この医学生の提案は低線量の被爆を覚悟して現場に踏みとどまっている人たちに対して、不安をあおるだけではないのか。
現場に踏みとどまらず、離れたところから、勝手な思い込みと押しつけによる支援ほど、迷惑なものはない。
南相馬市民より
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
#この文章は「シムシティ4」をプレイしたことある人向けです。プレイしたことない人は、攻略サイトなどを見てから読むとより分かりやすいでしょう。
シムシティ4は起債も不可能となりいよいよ収入不足でフローがマイナスになると「上院選立候補のため市長退任」というゲームオーバーがある。国政転出ってなんかリアルでもありそうな話だｗ
http://langrich.com/startguide
ここに体験レッスンのための手順が書いてるんですが・・・。私的には少し不親切に感じました。
無料体験レッスンの手順
これだけじゃ分かんねー。
Skype自体をイントールするのはじめてだったので、
どういうふうに連絡があって、どういうふうに始まるのかイメージができませんでしたよ。
おかげで、ずっとｇｋｂｒしながら待ってたのです。
スカイプのインストールの説明してるくらいだから、Skype初心者を想定してますよね。
それなら、もう少しでいいので、フローをイメージできるような説明をしていただきたいであります。
無料体験レッスンだから、うまくいかなくてもこっちはお金は損しない、ということなのかもしれないけれど
こちとら、相手の講師様に失礼なことにならないかで気が気じゃなかったです。
もちろん、ラングリッチはスカイプの会社ではないので、スカイプの説明を懇切丁寧にやる必要はないのかもしれませんが、
でも道具として活用してるのだから、授業がSkypeで成り立ってるのだから、なんちゅーかこう、もうちょっと
Skypeに対する恐怖心みたいなのに対して考慮していただきたかったであります。
初回始まるまでのアレこれがかなりストレスフルな感じだったのでもうちょっとフレンドリーな感じでお願いします。
ちなみにそんな感じで授業始まるまではすごい緊張したのですが、授業始まってからは
基本的にテキストに従って機械的に進んでいくので、ちょっと予習してから取り組めば問題ないと思う。
たとえば初回は「挨拶」「体調」「仕事」の話をするだけなので、自分の仕事について英語で簡単に説明できるくらい準備しておけば完璧。
私はぶっつけ本番でやったからつっかえつっかえになったけれど、ゆっくりやっていけば出来るようになるんじゃないかな。
ちなみに身元バレ覚悟で言うと、無料体験レッスン初回では講師の方から１０点満点で７．８点頂きましたが、これがどの程度すごいかよく分からない・・・。
講師の人がちゃんと説明してくれてたんですが、ちゃんと聞き取れなかったっす。
とりあえず「もっと練習しろ、君には練習が足りない」って言われたので今回やったところをちゃんと練習してからもう一回受講しようと思います。
講演一発目。
ソフトバンクモバイルの中山五輪男（いわお）さん。iPhoneの販推をやっている「シニアエヴァンジェリスト」だ。
現在、割合の25%超を占めているのが卸・小売業、次いで20%のメーカーである。
メーカーとしては製造現場にて指示書がペーパーレス化したり、営業のプレゼン媒体になったりしているとのこと。
一方、金融機関としては試験導入中の期間が複数あり、今年以降に爆発的に増える見込み。
スマートデバイスの契約数はますます右肩上がりに増えていく見込みである。
紙、デジタルサイネージ、薬の包装、音楽、映像からアプリを通じてwebに接続できる。
セカイカメラがARのひとつ。ドラゴンボールのスカウターみたいに、現実世界に外部から呼び出した情報を付加する。
http://tm.softbank.jp/business/white_cloud/videos/smartcatalog/
CA用の研修マニュアルは3冊2.1kgしていたものをiPadにすることで0.7kg(おそらくバッテリーは除く)にした。
この研修マニュアルは搭乗するたびに持ち込む性質のものらしく、軽量化はありがたい話。
また、電池の持ちがよく、ウイルスもゼロ件(ご存知Androidは質の悪いアプリにウイルスが潜んでいる)
浄水施設の点検をペーパーレス化、点検項目の漏れのチェック機能をつけている。
テクノツリー社という小さな会社が製造・流通のマニュアル作成に長けているとのこと。
(6)HOYA (SUNTECH)
感光式のサングラスで色の変化スピードを説明するときにビジュアライズすることで、営業説明と使用感のギャップが減ったらしい。
（口頭説明ではわかりにくく、事後的なクレームが多かった）
(7)AIU保険
東日本大震災の損害調査として米本社からiPadが送られ、SmartAttackというシステムを活用。
割愛
(9)BMW
iPad(280台)によって営業4-5日から1.5日減でクローズ
顧客とのコミュニケーションとして、車の外装・内装のシミュレーション、仮想の工場見学などを行える。
割愛
thinkpadを全部iPadにリプレース。営業のツールとしてアプリや映像を活用。(個人に営業トークに頼らず、営業フローを標準化したと言える。)
Microsoft ExchangeやOutlookは全部Google App (26000 ID)にする予定。BCPとして日本にサーバを置いてられない。
http://tm.softbank.jp/business/concierge/dm/
(14)iPhone 4S
「Siri」が特徴。業務システムに応用されるというのが講演者の予想。
twitter:@iwaonakayama
二発目。ヤマサのマーケティングの話。「(自称)超成熟マーケット」の醤油。
Facebookやtwitterなどあらゆる媒体を使って、消費者を包括的に網羅して360度にアプローチしようと試みていた。
消費者は中身を知りたがっているのであり、メーカーの中身を見せて、コミュニケーションをとれば、味方につけられるようだ。
三発目、DNPのC&I事業部(Communication & Information)メディア・コンテンツ本部の講演。
後段はB2Cにソーシャル・メディアを用いてアプローチするノウハウをDNPが持っているという話。
たしかにソーシャル・メディアによる販促は効果測定が難しい。そのノウハウを仮にDNPが持っているのならば素晴らしいことだ。
果たしてソーシャル・メディアはB2Bに使えるのか。会場から質問が出た。
回答はB2BでもB2Cと本質は同じであるという。しかし、それは本当であろうか。
たとえば、車のボンネットが新日鉄製であろうがJFE製であろうが消費者にとってはどっちでもいいんではないだろうか。
わからん。
http://anond.hatelabo.jp/20110907193725
を書いた増田だけど久しぶりに増田にログインしたらトラバがついてたんでお返事。
http://anond.hatelabo.jp/20111005112736
見てるかわかんないけど。
これはそのつもりで書いてます。ブラックリストホワイトリストという言い方ではなくて、オプトイン、オプトアウトという考え方で。元記事にも書いてあるんだけど、日本の法律ではオプトアウト方式は認められていないので、合法にやるにはオプトイン方式でないと無理だと思っています。
オプトアウト方式が認められていないのに、著作権違反はいくら大規模にやろうと親告罪であると言うゆがみがあると思っているんで、個人的にはそこは改善されるべきだと思っているけど。フェアユース導入なり、大規模著作権違反の事案は摘発が可能なようにするとかバランスを取るべきだと思う。
例えば自炊依頼のために許諾を求める業者は、その結果に責任取れるんだろうか？
その責任の所在を、自炊業者に求めるなら、法的リスクと収益で割が合わないだろうし、事故として上限免責されてしまうなら、許諾するのが馬鹿らしい。
これはそもそも自炊業者には責任は発生しないと考えます。許諾を得ていればもちろんのこと、許諾を得ていない真っ黒な現状でも。
電子書籍でもDRMフリーで販売されているものがありますが、そのDRMフリーの電子書籍が違法に流通して実害が出たとしても、DRMフリーの電子書籍を正規に許諾を受けて販売した業者は責任を問われないのと同じです。違う言い方をすればコピー機を有料で貸し出しているコンビニや、ドキュメントスキャナ、コピー機を製造している業者が違法性を問われないのと一緒です。もちろん違法流通のために特別な何かをしている場合は別だし、幇助レベルではない別の違法行為があれば違います。
実際に裁判で訴えられるとしても訴える側が自炊業者側に違法性を予見して未必の故意があった等と言う事を証明しなきゃならない事になるわけだけれど、そんなことはまず無理だと思う。
証拠（因果関係）が希薄だから自炊業者無罪なら、余計悪い方向だ。
ちなみに。
電子透かしを求めようが、何をしようが、業者が故意に行うデータ流出は防げないし、アフィリ等で流出の方が儲かる事情があれば簡単に崩壊する。
これは信頼関係を築いていくしかないと思います。と言うのはこれ電子書籍に必ずついて回る問題だし、昔は書籍についても同じ問題がついて回っていたから。と言うのは、販売量は業者しか分からないと言う事だからです。
最近の本でも伝統がある出版社の本なら奥付に「検印廃止」って書かれているのを見る事ができると思いますが、これは何かと言えば昔は出版社が作者に内緒でたくさんすって売っているのではないか（いわゆる偽版）を防ぐために、著者が検印を押した紙で確認するという事が行われていた名残です。同じ版をつかって作者に内緒で刷って裏流通させているんじゃないかと言う疑惑があったんですね。また電子書籍でもDRMがあろうがなかろうが、電子書籍販売業者が横流ししていると言う疑惑は当然ついて回ります。
もちろん、「状況が同じだからって自炊業者が問題無いわけじゃないだろ」って話は当然あって、だからベンチャーなんかがぽっと出でやるのは難しくて、信頼のある印刷業者やら取次やらが既存の自炊業者をノウハウごと買収してやるのがいいんじゃないかと言う〆にしてあるわけです。
実は元記事では触れてなかったけど、ここにある需要があって商売になるかってのが最大の問題としてある。でこれについてはなかなか難しい。
今後電子書籍は黎明期を脱してくるだろう思う。Amazonが来るぞとか言う印象論ではなく、
などが主な理由で、つまりは大手出版社が本気になりつつあるからと言う事なのだけれど、だけどこれは新刊や比較的近年に発行されたものに限ると思うんだよ。
一方今自炊したいという人の話を聞くと、だいたい2種類需要があって
と言う所なんだけど、電子書籍が普及してくると前者の需要は尻すぼみになると思う。と言うかむしろ成りつつある。わざわざ同価で販売されている電子書籍をDRMがあるからといってわざわざ自炊する人間がどれだけいるのかというとそんなにいるとは思えない。
一方後者の需要なんだが、こちらはむしろ電子書籍が普及すれば普及するほど増加してくるんじゃないか。今でも切実にスペースが足りない人は多い。たとえば私もそう。で、電子書籍の環境がだんだん使い物になるようになってくると、その欲求はどんどん膨らんでいくと思う。
また電子書籍で本を読むことが当たり前になってくると、古い蔵書を読みたいという時、紙じゃなくて電子化して読みたいという需要もどんどん増えてくると思っています。
しかし、新刊書籍については需要もあるし、DTPデータも丸ごと保存された状態から発刊と同時に業務フローの一環で電子データを作る事ができるからコストは安くすむし、どんどん電子書籍が出るだろう。
一方、古い書籍はどうだろう？DTPデータが消えてしまっている、あるいはそもそもDTPで作られていないとかで電子書籍を作るコストも新刊書籍より高い。しかも需要はニッチだから作成コストがとれない。だから全ての書籍をカバーすることなんてとうてい無理だ。ただこう言った事情から電子書籍が出ないのであって、権利問題がある訳ではなかったりするのも多いでしょう。電子化するコストは多くの人が言うほど安くはありませんし。
そこに、自炊業者と言うのは存在していけるのではないかと思うのだけれどどうだろう。確かに今の違法でありつづけることで必要なコストを払わない対価ではとても無理だが、たとえば引っ越し業者などと提携して、貴方の蔵書丸ごと電子書籍化しますといったサービスとしてはありえるのではないか、許諾があるものは自炊し、許諾がないものは既存の電子書籍がある場合はそれを案内しつつ、どうしても許諾がなく電子書籍化もできないものは返却する。（希望に応じて裁断だけ手がける）電子書籍化の要望が強いが権利者不明などの理由によってできないものは裁定制度を利用するといった電子ライブラリ構築エージェント的になれないかと思うわけです。
http://anond.hatelabo.jp/20111024095323
だよね
つーか注文丸ごとなくす店ってどうやってるんだ？
伝票を捨てるのか？
業務フローを徹底していない店ではよくある。つまり口頭オンリーでオーダーを受ける店。
平常時は伝票もって記入してるんだけど、忙しくなると他の作業で手一杯の店員に口頭で「○○ひとつ」といって店員が「わかりました」と受ける。
もちろん店員はこの時点では注文を覚えていてバックヤードに戻ったら「伝票書こう」と思ってるんだけど、戻った瞬間次の仕事がやってきて注文は忘れられてしまう。
だから本当は店側が、注文は「必ずその場で伝票記入すること」というルールと、口頭で注文が来た場合は客に「ちょっとお待ちください」といって伝票用紙をとってくるか、他の手が空いてる人間に注文取りにいかせる。というルールを徹底させればいいんだ。
客側の自衛としては伝票用紙を持ってない（明らかに手が空いてない）店員に声を掛けない。
やむなく声を掛けるにしても「注文お願いします」にとどめて、伝票用紙もった店員がやってくるのをまつ。
そりゃハイチとかそういう国に行けばそうだろうけど、ここは日本だぞ。
まぁ親とか親族とか国とか全部捨てて完全に一人で泥水啜ってでも生きていくと覚悟すれば、300万ぽっちでも少しは安心できるかもな。
ていうか、日本に住むつもりで300万で安心できる奴ってマジで存在すんの？そっちが気になる。
いやなんか反論来るだろうなとは思ってたけど、まさか「300万」なんて話が来るとは思いもよらなかった。俺の想像の斜め上を行ってた。
フローとしての300万だったらまだ考慮に値するけど、ストックとしての300万なんてゴミクズみたいなもんだよね。
それで安心できるというのはどういう心理なのか本当に気になる。
第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. 関連する重要な文献
思いのほか、反響が大きくて驚きました。ご質問やご意見に、反応と言うか、意見を書きたいと思います。
観察したり批評するという行為自体が、基本的に上から目線です。絶対そういうことを言われるだろうなと思ったのが自分のブログではなくマスダで書いた理由です。「天皇機関説」「産む機械」「暴力装置」等々、社会科学の文脈で語られた言葉でさえ優越感ゲームで処理されてしまう世の中です。こうした負の連鎖について、学校で教えればいいという意見もありましたが、絶対に無理だと思います。当事者たちから感情的な反発が来て、社会的なリンチにあうのが目に見えているのに誰が火中の栗を拾うでしょうか。お金のこと、キャリアのこと、仕事のこと、本当は中学までに教えておいた方がいいことがたくさんありますが、それがなされていないのにはそれなりの理由があります。
[地主のことが書かれていない]
H町は地方であり郊外ではあっても農村ではないということです。一時的な土地バブルがあったとしても、その恩恵を被ることが出来るのは資産家だけです。農民は、フローは少なくてもストックは持っているので、都市郊外の開発初期には、バブル資産家が続出しました。しかし郊外に住んでいる人はそうした人ばかりではありません。H町は、一度、農村化から工業化の過程を経ているために、住民の大半はプロレタリアート層（あるいは下層ブルーカラー）でした。地方=貧困とじゅっぱひとからげで見るのが間違いであるように、主に都市プロレタリアートの人が言いがちな、地方＝資産家の構図も全体に敷衍するのは間違いです。
[戦後にはそういうところから成り上がった人たちがたくさんいる/別にブルーカラーでも不幸とは言えない]
現在は高度経済成長を経て、安定成長の時代も経て、デフレの時代です。そうしたチャンスの時代を経てなおかつ成り上がれなかった人たちが取り残されている問題なのです。「生きがい労働」がどうしたと散々不平不満を言っている今の世代が、ブルーカラーでもそれなりに幸せというのは偽善じゃないでしょうか。選んだ結果ならばともかく、それしか選べなかった、実質的には選ばされている状況で、人それぞれというのは気休めとしか言いようがありません。
[新住民も"上層"下層プロレタリアートに過ぎない]
これはある意味そう思います。元記事は、勉強という切り口から見たのですが、根本の知的好奇心が欠けているのは新住民も原住民も大して変わりません。これは精神論の話をしているのではなくて、根本の欲求がない限り、勉強が能力として身につかないという側面があるので、これは重要な問題です。恐竜博士といわれるような小学生は興味があることについては専門家レベルの知識を持っています。そういう人に、興味もない人が付け焼刃で暗記したところで太刀打ちできません。メリットシステムの上層部は、恐竜博士みたいな人ばかりなので、いずれ新住民も挫折を強いられることになります。それでも、下士官どまりであっても日常的に殴られる二等兵よりはマシです。新住民はその程度のことは理解しています。彼らは将軍になるためではなく二等兵にならないために走っているのです。
[金持ちを引きずり落とす必要がある]
「金持ちを貧乏にしたからと言って貧乏人が金持ちになるわけではない」と某女性が言いましたがこれは間違いです。経済自体はプラスサムですが、経済構造にはゼロサムの部分があるからです。一番わかりやすい例は農地解放です。富の偏在の是正を比較的可能にした戦後日本と、戦後すぐには日本より豊かであったフィリピンの現在の姿を比べれば一目瞭然です。メリットシステムの結果発生した富と、アリストクラシーの結果保持された富はまったく性質が異なります。前者はメリットシステムを強化し、後者はメリットシステムを弱体化させます。少なくとも新住民に「努力の報酬」を与え、原住民に努力の動機を与えるためにはメリットシステムの強化は不可欠であり、そのためには既得権益層を弱体化させる必要があります。
そういう極端な例を言うなら、逆のことも言えます。そういうことを言う人たちは家庭内の虐待を助長しているのではないでしょうか。
家庭には子供を抑圧し、スポイルしてしまう面もあると指摘することが、アボリジニの盗まれた世代に直結するというならば、家庭の不可侵性をことさら言い募る人たちは、親が子供を所有物のように扱い、虐待することを是としているとも言えるのではないでしょうか。物事を多角的に見ずに、だから進歩主義はダメなんだみたいに言いたがる人には、おぞましいという感情しか持てません。
じゃあ、どうすればいいという具体的な解決案が私にあるわけではありません。あるというなら、あると言う人が提示してくれればいいと思います。分かり易い具体的な解決があるならすでに実行されているでしょう。問題だけ示して解決も出さないのが無責任と言われるなら、そう批判されてもしかたがないと思います。しかし問題があるものをないということは出来ません。
不満に思っていない、と言い聞かせている、と私は思います。仮に宝くじにあたって、以前と同じライフスタイル、以前と同じ消費財で満足できるでしょうか。できるというなら、それはそれぞれの好みだと言えるでしょうが、実際にはそうではないわけです。選択可能性があって、初めて選べるのであって、選択可能性がないところで手に入れた物はあてがわれたものに過ぎません。努力をする人、特に自分の子供が努力をするのを引きずり落とそうとするのは自己欺瞞を突き付けられるからではないでしょうか。戦後の、教育熱心なお母さん（北野サキさんみたいな人）とそうした原住民の親の違いは自己欺瞞の自覚の有無だと思います。
原住民の友達の中にはマンガでさえ本というものは読まない子はたくさんいました。そういう子たちも中学の頃には「少女コミック」を熱心に読んでいました。素敵な彼とセックスしてしあわせ、みたいな話です。今にして思えば、小学館は貧困ビジネスをしていたんだなと思います。
[原住民にも向学心はある]
逆上がりができるようになって嬉しいくらいの向学心はあります。小学生の時の「勉強ができない」は本当に簡単なところで理解がつまずいているのですから、少し整理してあげるとパッと分かって、魔法みたい、嬉しいということはありました。ただ、それが続かないのです。それを続かせてサポートする環境がないのです。原住民の子でただひとりだけ、有名大学に進学した子（男の子）がいました。彼は頑張ってそうしたのではなくて、もともとの知的好奇心がある子だったので、勉強しないことの方が苦痛、という子でした。彼とは何でも話せる友達になりましたが、彼は少年時代ずっと、家族からさえ変人扱いされました。彼を励ましてサポートしたのは私と私の家族くらいだったと思います。彼の場合は、たとえ変人扱いされたとしても向学心の衝動があったので、どうしてもそうせざるを得ない結果、勉強したのであって、そういう生まれながらの衝動がない子ならば、そうじゃないならとっくに「かわいがられる方向」にシフトチェンジしただろうと思います。ちなみに彼は私の今の夫です。
どうせ細かい説明しても向こう分んないんだし。
どうしても工期短縮しろってんなら、じゃぁ、テストとかバグ取り出来ませんけど？と念書を取るべき。
何でだよって言われたら、「専門的な話になりますが」と断りを入れて、
・ポインタ使われていないのでコードが乱雑になっており、バグが発生した際に原因を解析できない可能性がある事
・古い仕様のコードが大量に含まれており、.net用に書き直すとなると、フローを再構築することになり、ほぼ一からの開発と変わらない事
辺りで良いんじゃないかね？
説明ができるというよりは、相手に言いたいこと言えるかどうか。
相手との関係がすでに悪いとか、なんか微妙なのは営業のせいだし。
上がってきた見積もりを持ってどう交渉するかだって、営業のスキル。
というか、そのために営業っているもんだしね。
技術屋は技術屋らしく、言いたいことを言った方が良いと思うが。
顧客との関係が良好だと、会計システムVCで組むのめんどくさいのでACCESSで良いっすか？ってのが通ったりもする。DBをOracleにして一点豪華主義。
かれこれ5年ぐらい走らせてるが、向こうがPC更新した時ぐらいしかトラブったこと無い。これも、ファイルパス変更しただけで動いたし。
電車の中で学生が「俺、バイトで●●の人と仲良くなった。その人のコネで就職活動余裕だ。」などど寝ぼけたことを言っていたのを聞いた。
そこで一応名前くらい誰でも聞いたことある企業で採用を2年ほどやっていた自分が、
コネ入社とはどういうフローで行われて、どういう意味を持っているかを簡単にまとめてみたい。
（あくまで自分がいた会社の話なので一例として聞いてもらいたい）
なぜなら、新卒採用の人数はおおよそ決定している。（もちろん優秀な人間が多い場合は若干うわぶれることはあるが）
社内稟議などにも「50人～60人今年は採用します」のような形で記載されている。
なので社員の紹介だから入社させるなどと言ったらそれだけで人数が埋まってしまう。
そんなことは企業としても実力を持った優秀な学生を取れなくなってしまい、大きな損失である
仮に50～60人は普通のフローで採用し、紹介枠は別にとるなどとしたとしても、人件費もかかり、そもそも受け入れ先が無い。
人事はある程度「○○事業部には何人、××事業部には何人」と計算をしながら採用計画を決めているのだ。
よって人事が容認できる実際のコネ入社の人数は、全内定者のうち1％以下ではないだろうか。
（例外として銀行、広告、テレビ局などがあるが、その方面に明るくないのでここには記載しない）
うちの会社では「紹介者シート」というものがあり、採用時期になると人事に送付できるようになっている。
紹介者とは当然、「社員が人事に紹介したい学生」のことである。
内容としては
・紹介者の氏名
・紹介者と社員の関係
・紹介者を入れることのメリット
・どこまで通してほしいか（書類選考まで、○次面接まで通してそのあとは実力で、問答無用で内定、など）
などがある。
このシートを提出されたら人事は該当学生を膨大な量のエントリーシートから探し出し、チェックする。
そこで、現状を提出者に報告し、紹介者の実力が足りず「どこまで通してほしいか」のリクエストにこたえられそうになかった場合、
落としていいのか、それともやはりリクエスト通り通すべきなのかを確認する。
それを繰り返し、紹介者も絞り込んでいく。
余談だが「○次面接まで通して」というのは社員の営業に人事がつきあわされていることが多い。
取引先の関係者などに頼み込まれて、内定は上げなくて良いのでとりえあず一旦次の段階に進ませて落とすなどである。
そうすれば、社員も取引先に「無理言ってあげてもらったんですけどやはり当社、倍率が高くて…」
上記の項目で重要なのは「紹介した社員のレベル」と「紹介者を入れることのメリット」である。
役職が高いものほど人事としては優先しなければいけなくなる。
次に「紹介者を入れることのメリット」だが、内容としては
現在当社は○○商事のプロジェクトで×億円の事業を受注しており、
ご子息を入社させることによって継続的な事業の受注を見込める」
などの記載がある。（まあこんなわかりやすいケースはそこまで多くはないが）
逆にどんな偉い人が出してきたものでも
「ゴルフ仲間の娘なので入れてあげてよ」などというものだった場合
人事の偉い人が止めに行く。
※よって冒頭の「バイトで知り合った云々」というのは論外である。
などが重要。
自分のコネを上記の紹介者シートでどのように記載されるかを考えてみると、
自分が持っているコネがどれだけ有効であるか、具体的なイメージをしやすいと思う。
【音注意】Count Down Tube http://www.leno-ig.com/ja/youtube/channel/
Count Down Tubeはチャンネル別に、トップソングをカウントダウン形式で視聴出来ます。
iTunes Music Store のプレビュー(30秒)では物足りなかったのが一番の理由です。
プレビューの短さを補うために、YouTubeにあるPVを再生しようと思いました。
また、１曲づつクリックして再生するのが手間だったので、カウントダウン形式で自動再生させました。
計４日で内訳は
「iTunes Music Store 、YouTube、アーティスト、ユーザすべてにメリットがある」
「アクセス増への対策」
「広告」
「機能追加」
[twitter:@leno_ig]
http://anond.hatelabo.jp/20101219185436
http://anond.hatelabo.jp/20101203150748
日本で始球式をすることも決まっている、話題のサンデル教授の本『これからの「正義」の話をしよう』を読んだ。
シリアスゲーム的な考え方だと思った。押し付けがましくなく、それでいて熱意がある。
ダン・アリエリーの「予想通りに不合理」では、行動経済学として人々の社会規範と市場規範に焦点を当て、さまざまな実験を通して規範の適用の仕方を検証している。
サンデル教授はこれまで社会規範の適用されてきた社会に市場規範を適用するという最近の風潮を危惧している。
それは、アメリカのみならず、諸先進国においても同様だろう。GDPでは幸福は測れないということだ。
そうした現状で、公正な正義を一人一人が認識しようとすることは社会の幸福への試金石になるかもしれない。
宮台真司の推薦文にもある通り、サンデル教授はコミュニタリアン（共同体主義者）だそうだが、一部のコミュニタリアンにとっては違和感のある呼ばれ方だそうで、その原因は「正義は個々のコミュニティが好き勝手に定義したものに過ぎないという相対主義的見方を表しているように思える」からだそうだ。
つまり、コミュニタリアンと呼ぶ側（功利主義、自由主義）がコミュタリアンの物語の探求という考え方を見落としているということだ。
NHKの白熱教室を観た方はわかると思うけれど、サンデル教授は功利主義、自由主義、そして共同体主義を実際に起きた問題や思考実験によって人の正義と自由、正義と権利、自由と権利といった問題を焦点に繰り返し問題提議、検証していく。
5章以降のカントの示した人生観やロールズの考える自由は、より具体的で、わかりやすく、刺激的だ。
人生観で特に印象的だったのは、マッキンタイアの「物語の探求としての人生を生きる」という考え方だ。
自由を追い求める考え方は目的論を独善的とみなす。しかし、現実的には人々は人生という物語を解釈している。
自由に選択できることが真の意志の尊重とするが、
物語の探求という生き方は、アドベンチャーゲーム、ロールプレイングゲームのようにマルチエンディングのような、または、SF的な多世界解釈に近いと思う。
そして、それは強烈だ。これからの諸問題との対峙する時、コミュニタリアンの正義に対する捉え方は安易な自由や平等主義よりも解決への熱意を持っている。
サンデル教授は功利主義、自由主義、共同体主義という選択肢を検証し、最終的にトゥルールートとでもいうように納得させる形で共同体主義への道筋を示した。
心理学者のミハイ・チクセントミハイによって提唱されたフロー体験というものがある。
フロー（英語：Flow ）とは、人間がそのときしていることに、完全に浸り、精力的に集中している感覚に特徴づけられ、完全にのめり込んでいて、その過程が活発さにおいて成功しているような活動における、精神的な状態をいう。ZONE、ピークエクスペリエンスとも呼ばれる。その概念は、あらゆる分野に渡って広く論及されている。
チクセントミハイが見たところによれば、明確に列挙することができるフロー体験の構成要素が存在する。彼は8つ挙げている。
2. 専念と集中、注意力の限定された分野への高度な集中。（活動に従事する人が、それに深く集中し探求する機会を持つ）
4. 時間感覚のゆがみ - 時間への我々の主体的な経験の変更
5. 直接的で即座な反応（活動の過程における成功と失敗が明確で、行動が必要に応じて調節される）
6. 能力の水準と難易度とのバランス（活動が易しすぎず、難しすぎない）
フローを経験するためにこれら要素のすべてが必要というわけではない。
（フロー:wikipedia [ http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AD%E3%83%BC ]）
目的論的な解釈や考え方はフロー体験を促しやすいのではないだろうか。
自己実現理論（じこじつげんりろん）とは心理学者・アブラハム・マズローが、「人間は自己実現に向かって絶えず成長する生きものである」と仮定し、人間の欲求を5段階の階層で理論化したものである。又、これは、「マズローの欲求段階説」とも称される。
2. 安全の欲求（safety need）
3. 所属と愛の欲求（social need/love and belonging）
4. 承認の欲求（esteem）
5. 自己実現の欲求（self actualization）
の5段階に分類した。
自己超越
マズローは晩年、5段階の欲求階層の上に、さらにもう一つの段階があると発表した。それが、「自己超越」(self-transcendence)の段階である。 自己超越者（transcenders）の特徴は
1. 「在ること」（Being）の世界について、よく知っている
5. 深い洞察を得た経験が、今までにある
6. 他者の不幸に罪悪感を抱く
9. 聡明である
10. 多視点的な思考ができる
11. 外見は普通である（very normal on the outside）
マズローによると、このレベルに達している人は人口の2%ほどであり、子供でこの段階に達することは不可能である。 マズローは、自身が超越者だと考えた12人について調査し、この研究を深めた。
(自己実現理論 :wikipedia ［ http://ja.wikipedia.org/wiki/%E8%87%AA%E5%B7%B1%E5%AE%9F%E7%8F%BE%E7%90%86%E8%AB%96 ］)
フロー体験や自己超越といった段階は、ただ安易な自由や平等を考える以上に、個々人が社会で生きる目的を認識することが重要であることを示しているように思える。
何でも持ち込みってのは、「今までの制度でもカンニングあったでしょ？カンニング嫌ならこれぐらいしか妥当な方法はないでしょ？」っていうカウンターであって、カンニングを認めないなら君の言うままでもいいと思うよ。
極端なハナシ、脳同士で念波を送りあえる時代になったら、入試なんて要らないもんね。
個人の知識ストックがそこまでいらない時代にあえてストックさせるという意味では、時代逆行型だと思うけど、足りない脳みそに知識フローさせてやる人間育ててんだからうるさい黙れっていうのも説得力あるしね。
「あの京大がカンニングされた」ってのはインパクト大きいよね。学歴大事な人々にとっては。なんていうの。
横だが
元気な老人を殺そうと言うのは本人からも家族からも抵抗が大きい
要介護老人を穏便かつ強制的に死なせていく。
重度な方から順に300万人は殺そう。
これで、クソするのにも人の手を借りるレベルの老人はほぼ一掃される。
次に柔整師だ。
あれがただの娯楽としてのマッサージと化してるのは接したことある人間はみんな知ってる。
「寝違え」だとか無理矢理傷害と言うことにして全ての手技を保険から金取ってる。
コレを全面的に潰す。
こちらは驚くだろうが、これも雑に言って１兆円が浮く。
生活保護受けてる奴なんか問題外だ。
これで雑に１兆円浮く。
そして独裁者が責任を持って矯正してくれる限り、国民もきっとそのうち感謝するようになる。
更に、これらの施策は全て単年度を埋蔵金で帳尻合わせるような姑息なものではなく
BGMも歌も台詞もぜーんぜん聞こえないんですけど。エスカフローネといえば、あの「エスカっフローネっ、エスカっフローネッ！エスカフローネ、エスーカーフローネエー」って歌だと思うんですけど、なんであれないねん。その割に役物の羽根がうごくのはピュインピュイインとうるさいぐらいなので、単純に設計に失敗してるんじゃないか。
絵は全部当時の絵をつかってるんだが、どうも単純に引き延ばしたみたで非常にジャギーが目立つ。新緑が極端にすくなくって、みんな喋らない。こう、目ちからカットインが入ったときとか、一言しゃべっても良いと思うんだ。とくにフォルケン兄さんが何かしゃべっての、記憶にないんすけど。
羽根のお母さんが登場すると疑似連なのだが、これが面白いぐらい当たらない。疑似連３で外れるのがザラ。これがミドル機種ならまだわかるんだが、遊パチでやることじゃないと思う。
せめて人物説明とか、ストーリーの大枠説明とか、もうちょっと織り込んでもいいと思った。羽根お母さんが誰なのかとか。バルガスが誰なのかとか、シド王子がだれなのか。