 
|
はてなキーワード: ユーザとは
自分用メモも兼ねて。いや、最近なんか周りでなんとも抑うつっぽい人が散見されるようになってきたように感じられるのでふと考えることが多くなった。「とりあえず前向きに」は理想としてはほんとそのとおりなんだけど、いやできないから凹んでるわけであってね。というのも自分も社会生活に支障は無いまでもちょっときつかった時期があったりしたんだよね。なんかこう上手くいかんという時にわずかでも参考になればと。
以下自分の思う改善法を適当に並べて書くけどツッコミ等あれば是非忌憚なく書いてってくれれば
・スポーツする
スポーツするのはすごく効くと強く感じる。じっさい脳内に多幸感物質的なのがでていいらしいね本当に。そういえば体育会だったり普段から運動してる人でうつっぽい人っていなくない？（無口とかおとなしい人ってのは別でね。笑）それって結局これにつながるところだと思うんだよね。まあ脳内から作用するんならそりゃ自然に効くここまでいい薬はないわなと。
で、スポーツの中でも個人的には集団でやるやつ、例えば野球、サッカー、バスケとかとかをあまり競争的にならずにやるのがいいと思ってるんだ。というのも下の話にも関連するんだけど人とあって話すのはすごい凹んでるのを改善するのにいい。特に非競争的にみんなでわいわい談笑しながらでなんかだと本当に効果てきめんだと個人的にも思ったわ。あんまり試合の結果に一喜一憂するのがいいとも思わんしね。（まあ個人差あるかもだけど笑）
水泳とかジョギングとかでもいいとは思う。ただ、ジョギングとか取り入れてみて思ったけどどうにも変化がなかったりすると飽きたりするからそこらへんは要工夫だし、人の輪にいるってのがすごい重要だと思ってるからよりオススメは集団スポーツ。でも個人スポーツも全然OKってスタンス。
・人と会って喋る
これも超重要。や、もう本当になんでもいいんだよね。単純に失恋とか仕事うまく行かなくて悩んでるならそれを聞いてもらうでもいいし、あえて全然関係ない趣味に花咲かせるのでもいいと思う。個人的には仕事なり実際的な解決方法が欲しい時は人の話を参考にするのもいいかなとは思うけど、基本的にどうにもならない人間関係のこととかはもう全く別の話して気を紛らわすのがいいんじゃないかなと思うことが多いのかなとは思ってる。例えば恋人関係で悩んでる時に共通の知人にいろいろ聞いてもらうよりは、全く関係ない人にその相談みたいなのはもちかけずに自分の好きな趣味、音楽映画なり漫画でもなんでもいいけど、の話をしてわーって盛り上がったときのほうが気持ち的には晴れやかなことが多いのかなっては思う。まあこのへんはいろいろケースにはよるかなとは思うけど気の置けない友達とただ話して笑ってみるだけで全然違うっすほんと。
・陽の光を浴びる
これも効く。よく本とかに書いてあることだったりはするんだけどね。メラトニン（だっけ）とかってのが日に浴びることで生成されていろいろポジティブな効果を生むっていう。これも具体的に南国の人とかのうつ率の低さ（ってかほとんどいないんじゃね？笑）をかんがえたらなんとなく納得する話なのかなと。自分も少し取り入れてみたけど朝に一日の段取りでもぼーっと考えながら2,30分散歩してみるだけでもホント違うよ。これなんかは習慣にすべきだと思う。忙しいと30分とかの時間生み出すの大変かもなんだけど、まわりまわって効率良くなって全体のパフォーマンスよくなってるの感じるわ。
・早寝早起きする
これも上に関連。特に日の出てる時にしっかり生活をするのが重要。これ見てる人なんかはパソコン好きが多いだろうからついついモニターの前で夜更かししちゃう、みたいなことありますよね。僕もすごくよくあるのでわかる。笑 でもやっぱり早起きしたらその分有効に使える時間は増えるし、上記の日を浴びられる時間が伸びる。逆に、夜更かししてネットやりながらだらだらしてると無駄な後ろ向きな思索とかがやたら増えてかなりジャンクなブラウジングしてる自分に気づいてなんとなく鬱屈としてくる、また生活時間がズレこんでの悪いサイクルが生まれると思うんだ。だからなんとか朝、人と会う予定をいろいろ入れてみたりして、生活習慣を改善してみよう。特に夜更かしをしないってのが重要かなとは思います経験上。
・家事とかをしっかりしてみる
は？って感じかもしれんけど小さいながら書いとく。これ結局小さい成功体験の積み重ねに相当するのあかなと。普段面倒だったり忙しかったりして掃除選択皿洗いから細やかな管理なり色々後回しになってたりしない？そういうのをちょっと重い腰を上げてやってみよう。掃除なんかはほんと終わったらすっきりするよ。週ごとにホコリ一掃キャンペーン（一人で）をやってもいいくらいだ。笑 本棚の整理、パソコンのファイル整理でも靴磨くのでもどんな小さなことでもいい。無言で集中してるうちに日常の些事なんか薄らいじゃってうことってよくあるよ！
・ネット断ちをしてみる
最後にネットヘビーユーザは特に。前述のごとくここ見る人なんて大分ネットに慣れ親しんだ人だろう。最近なんかはネット疲れなんてのが言われるくらいだからなあ…いるでしょ？気付いたらTwitter開いてるみたいな人？笑 自分も大分そっち側だからよく分かるんだよ。
でもそれあんまよくない。特にネット一日に数時間もやってる（それこそねらー的な人達が自嘲的に言ってるような人種の人は）一日でもいいから全くネット触らずに外ぶらぶらしてみる時間をとったり、鈍行でふと何か見に行けばいいと思う。これ本当に違うんだよ。割と自分も一日にネットとんでもない時間触れてる時があったんだけど、これってなんかこう、そのまま惰性で続けちゃうじゃん？それをこうアウトドアなのをふと入れてみるとそのネットやってる時間自体の充実度もだいぶ違ったりするから不思議なもんだ。インドアな人には効果てきめんだし、最近よくいう引きこもり気味でネガティブになってる人にはよく効くと思うので是非。
ざっと思いつくままに書いてみたけど、うつ改善のために精神科の先生が書いてるのいくつか読んだりWEBで読んだのうろ覚えであったりするのと、自分の経験則的なものを合わせた感じだとこんな感じだ。特に自分がおすすめするのはスポーツと人と話すことかな。もちろん時間が必要なことではあるので大変かとはおもうけどやっぱりこう人と交流しながらってのが一番効果的だとは思う。そんな友達がいないんだよ！笑 みたいな人はネットでオフみたいなの探せば何かしら機会はあるはず、同じような悩みだったり考えしてる人って世の中思いのほか多かったりするよ！
以上とりあえずそんなかんじで、是非参考になれば！
土曜日になってようやくまともな食事をとったばかりです。
メールボックスは、たぶん読むことはないだろうメッセージでいっぱいになっています。
疲れましたが、私は幸せです。
読者の皆さんが自分の声を政治家に伝えられるようにすることであり、
どちらも成功裏に終わりました。
私たちが用意したツールを使って800万人もの人が自分の地域の議員の連絡先を確認し、
ソーシャルメディアではさらに何百万人もの人が自分の意見を発言しました。
何千人ものジャーナリストがウィキペディアの黒い画面をはりだして記事を書きました。
ここで一度、何が起こったのかをちゃんと理解しておくことが重要だと思います。
私たちの立つ足元が、大きく揺れ動いたのですから。
ジャーナリストは古いメディアと新しいメディアの衝突としてこの出来事を見ていますが、それは間違いです。
彼らがそういう見方をするのは、ふつうの出来事はそうやって動くからです。
元Sunlight財団のClay Johnson氏は、
「こんにち、自分の業界にとって有効な法案を通しワシントンから旅立たせるためには、適切なロビイストに金を払い、適切なキャンペーンをはり、適切な法案を適切なときに書かなければならない」
と言っています。
ちょうど同じように、アメリカ映画協会会長で元上院議員のChris Dodd氏は、ウィキペディアのブラックアウトを評して
「権力の濫用。IT業界の利益を守るため、ユーザを痛めつけ企業の駒として使う行為」と呼びました。
彼にとってこの問題は金と利益に関わる衝突にしか見えないようです。
NPR、 Associated Press、Fox Newsといった報道機関がすべて、この闘いを、
ハリウッド対シリコンバレーと銘打って伝えたのも、そのためです。
Bloomberg が、テレビ・映画・音楽業界がワシントンで使っているお金と、Google と Facebook の支出とを比べているのも、そのためです。
このブラックアウトはプレイヤーを増やしただけであって、また同じゲームが続くのだろうと想像しているのです。
そうではないのです。
インターネットで流れてきたClay Shirky 氏の講演をご紹介しましょう。発言を引用します。
SOPAとPIPAで危機に瀕するのは、ウェブサイトだけでもその所有者だけでもない。私たちが、一人の人間として、他の誰かとものごとを共有してよいという保証がおびやかされているのです。
私たちこそが、SOPAとPIPAに監視される対象になります。インターネット上で最大のコンテンツ生産者は Google でも Yahoo でもなく、私たちだからです。
私たちはそれが本当だと知っています。
ブラックアウトを主導したのは、 GoogleやYahooやFacebookやTwitterのCEOでもなく、ウィキメディア財団でもなかったからです。
ブラックアウトを主導したのは、普通のインターネットユーザでした。
その中心にいたのは、Osarius さん、 SiPlus さん、 FT2 さん、 Titoxd さん、 Fluffernutter さんといった人たちでした。
ウィキペディアがSOPAとの闘いに加わったのは、巨大な利益のためでも、資金のためでもはありません。
ウィキペディアは非営利組織によって（コントロールされているのではなく）運営されています。
そこには守るべき企業利益はなく、著作権侵害で資金を得ることはありません。
Reddit は、リンクを共有しコメントを付けあう人々の集まりです。
Metafilter も Tumblr も Craigslist も Cheesburger network も Oatmeal も 4chan も identi.ca も同じです。
どれも巨大企業ではありません。
15年以上にわたって、インターネットは普通の人々にコンテンツ製作の手段を提供してきました。
私たちがインターネットを使って作るのは、時にはかわいい猫の写真であったり、時には世界最大の百科事典であったりします。
時には腐敗した体制を倒すために使ったりもします。
昨日起こったのは、世界中のインターネットユーザが自分の声を見つけたということです。
自分たちの自由をおびやかす人たちに対して闘うための声を。
著作権侵害が問題であることは確かであり、被害を受ける人たちが自分の問題を解決したいと思うのは当然のことです。
しかし、彼らの問題は、普通の人々が自分を表現し、共有し、学ぶ力を守ることほどに重要ではありません。
聞くところでは、議会はIT企業とユーザに意見を尋ねに来るようです。
何が欲しいのか。
SOPAとPIPAをどう変えれば満足するのか。
OPENにすればいいのか。
新しい法案を作るべきか。
ウィキペディアがブラックアウトで伝えたかったこと、そして他の対SOPA・PIPAの行動が伝えたかったのは、
「ネット上の著作権侵害を撲滅する方法について話し合おう」ではありません。
「これだけ大事なインターネットを壊すな。私たちがこれまでどおり働けるようにしろ。学び、作り、共有できるようにしろ」です。
ここで、ブラックアウトに関わった皆様に感謝したいと思います。
下記に並べた人たちは、私が一緒に働いた、または働くのを見た人たちです。
関わっていたのにご自分の名前がなかったとしても、感謝をお届けしたものとお考えください :-)
無作為な順序で： Luke Faraone, Jan Ainali, Puki, André Savik, Dcoetzee, Vituzzu, Stacey Merrick, Dan Rosenthal, Michael Snow, Sumana Harihareswara, Wikitanvir, Jim Redmond, Kaganer, PeterSymonds, Mikołka, ZeaForUs, Spiritia, Iliev, Anubhab91, Ali, Haidar Khan, Joan manel, Davidpar, Cameta, Mormegil, Okino, Sir48, Giftpflanze, Rbmj, Tecsie, BreadMaker, Antonorsi, Mariadelcarmenpatricia, Huji, Tommikovala, Nikerabbit, Lamiot, Seb35, Zetud, Amire80, Rekp, איש המרק, Eranb, עידן ד, Trần Nguyễn Minh Huy, Itzike, Vibhijain, Ruy Pugliesi, Roberta F., Tgr, Kelly Kay, Pagony, Alensha, William Surya Permana, Gombang, Gregorovius, Civvì, Gnumarcoo, Austroungarika, Miya, Whym, Takot, Melberg, Omshivaprakash, Idh0854, Freebiekr, Diagramma Della Verita, RajeshPandey, Mathonius, Romaine, Mwpnl, Whaledad, Wpedzich, Sp5uhe, Przemub, Ency, Przykuta, Teles, Vitor Mazuco, Lvova, OC Ripper, Euriditi, Maduixa, Wikiwind, Јованвб, A1, Олег-літред, Violetbonmua, Prenn, Cheers!, Sameboat, Tbayer (WMF), OhanaUnited, Tom Morris, Wdchk, Sarah Stierch, Risker, Billinghurst, NuclearWarfare, Jimmy Wales, Orionist, Ryan Kaldari, John Du Hart, Aaron Schulz, Kat Walsh, Cherian Tinu, Mike Godwin, Jim Burger, David Gerard, Johnuniq, James Forrester, Prodego, Fluffernutter, Dana Isokawa, Fae, Andrew Lih, Brandon Harris, Jeremyb, Michelle Paulson, DeltaQuad, Pete Forsyth, Fetchcomms, Heather Walls, Rachel Farrand, CMBJ, Erik Moeller, Fifelfoo, James Alexander, Itzik Edri, Katie Horn, Iván Martínez, Matthias Schindler, Ben Hartshorne, Jon Davies, Anthere, Slobodan Jakoski, Victorgrigas, Dimce, Jerry-Yuyu, Patricia Morales, Stephen LaPorte, Varnent, Lennart Guldbrandsson, Neil Kandalgaonkar, Greg Maxwell, Ian Baker, Jeandré, Howie Fung, Ryan Faulkner, Beatriz Busaniche, Philippe Beaudette, Ziko van Dijk, Oliver Keyes, Dimce Grozdanoski, Keegan, André, Guillaume Paumier, Maggie Dennis, Mentifisto, Phoebe Ayers, Arne Klempert, Mike Peel, Gorilla Warfare, Geoff Brigham, Swarm, Peter Gehres, Megan Hernandez, Leslie Harms, Tomasz Finc, Pretzels, Jay Walsh, Whenaxis, Liberaler Humanist, Sam Klein, Andrew Gray, Fifelfoo, Zack Exley, Katie Filbert, Victor Vasiliev, Guy Chapman, Avi, Kenneth/MD, Stu West, Harry, Ryan Lane, Josh Lim, Matthew Roth, Richard Symons, Gayle Karen Young, Yuvaraj Pandian, Evangeline Han, Milos Rancic, James Hare, Adrienne Alix, Samat, Tomasz Ganicz, FT2, Alessio Guidetti, Galileo Vidoni, David Richfield, Alison Wheeler, Siska Doviana, Erlend Bjoertvedt, Анастасия Львова, Steven Walling, Casey Brown, Tim Starling, Patrick Reilly, Arthur Richards, Asaf Bartov, Alolita Sharma, CT Woo – そしてもちろん、ブラックアウトの決定をした、1800人の英語版ウィキペディアンの皆さん。
enWPのブラックアウトを支援するために抗議行動をしてくださった、次の姉妹プロジェクトにもお礼申し上げます：アルバニア語版ウィキペディア、アラビア語版ウィキペディア、ブルガリア語版ウィキペディア、カタルーニャ語版ウィキペディア、中国語版ウィキペディア、クロアチア語版ウィキペディア、オランダ語版ウィキペディア、グルジア語版ウィキペディア、ドイツ語版ウィキペディア、ギリシア語版ウィキペディア、日本語版ウィキペディア、韓国語版ウィキペディア、インドネシア語版ウィキペディア、イタリア語版ウィキペディア、ノルウェイ語版ウィキペディア、ポルトガル語版ウィキペディア、ロシア語版ウィキペディア、セルビア語版ウィキペディア、スペイン語版ウィキペディア、スウェーデン語版ウィキペディア、ウクライナ語版ウィキペディア、ベトナム語版ウィキペディア、ウィキメディアコモンズ。
「ステログ」って、今回問題になったＰＲ会社による火消しステマなんじゃないだろうか。
というのは、ステログは、「レビュー数が少なくて、高得点をつけてる人」をあぶり出してるんだけど、食べログもさすがにそんな作戦にはとっくに対処していて、そういう場合は点数が上がらないように、もともと作られてるんだよね。つまり「ステログ」であぶりだせるのは、素人による「自作自演」だけなんだ。プロモーション会社が有料で引き受けて、巧妙に点数を上げてるような事例、つまりレビューを数多く投稿していて点数に大きな影響を持つユーザを事前にじっくり作っておいて、そのユーザに高得点をつけさせるような作戦は、華麗にスルーされてしまうんだ。
もちろん、そこまで悪意なくておもしろ半分にやってるだけかもしれないけど、一番注意した方がいいのは「ガチヤラセ？？」って赤文字だけ見て喜んでる人ね。それ、ステマに騙されてる可能性は高いと思います。
そもそも。
「食べログ」って、レビューを書き込んだユーザーの「レビュー書き込み数」とかを単純に返すAPIとかないので、「ステログ」の会社は、自社製のクローラでデータ収集してるんだろう。ま、それは別に悪いことじゃないんだけど、そんなクローラまで作ってる会社が、食べログの採点の仕組みの基本を知らないってのは腑に落ちない。
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 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践 - 株式会社ビービッ
なんでコンテンツにカネを払うのさ？ デジタル時代のぼくらの著作権入門 - 岡田 斗司夫
競争の作法 いかに働き、投資するか (ちくま新書) - 齊藤 誠
ボリンジャー・バンド入門 ― 相対性原理が取り明かすマーケットの仕組み (ウィザード・ブックシリーズ) - ジョン・A・ボリンジャー
いかにして問題をとくか - G. ポリア
実戦ボトムアップ・マーケティング戦略 - ジャック・トラウト
ビジネスパーソンのための契約の教科書 (文春新書 834) - 福井 健策
すでに認められている変化で例えるならば、
「ずつ」と「づつ」の使い分けのようなもの。
これとの共通点は、「音が一緒なら、どっちでも良いことにする。」
「後々ユーザの多い方が、結果的に正しくになる。」
という点。
ネットでこれらの主張が飛び交っていない日はないだろう。
まあ無理もない話だ。
他国の王族を侮辱したり、自社の利益のために自国を貶めるような
放送を流す私企業に対して「見なければいい」で済ますことはできない。
明らかに悪いことをしている個人や企業が罰せられない、
と言う状況は負の感情を生む。社会にとって負の遺産として積もり続ける。
このやりどころのない怒り、不公平感、無力感は、
それを許している法や政治、ひいては社会に対する不信につながっていく。
そのどうにもならない『こんなの絶対おかしいだろ！？』という叫びが
結果的に「フジテレビ潰れろ！」「放送免許を取り消せ！」という声になっている。
それを痛いほど理解した上で。
一歩引いて考えてみる。
「免許剥奪」の選択は現実味がない（むしろ倒産の方がよっぽど現実味がある）。
冷静に考えてみて、免許剥奪になるほどの放送内容というのはなかなか想像が難しい。
結局のところ、放送免許の剥奪というのは大なた過ぎて誰もふるえないのだ。
なので、いつも「現状維持（罰せられない）」という事態に陥っているのではないか。
もちろん、瞬間最大風速的には私自身もフジテレビに対して「滅びろ！」と思うし、
テレビ局はNHKと民放1局ぐらいで十分じゃないのか、とか思うこともある。
（故意かどうかは別にして）いつか問題を起こすことはあるだろう。
絶対に壊れない人工物がないのと同じで、人も企業も不祥事を必ず起こす。
大切なのは過ちに対して適切な懲罰を与え、当人に更正のチャンスを与えることだ。
では、どの程度の懲罰が適切なのだろうか。
「1週間の間、番組自体は放送して良いが（収益源となる）CMの放送は禁止する」というような処置だ。
これであればニュースや地震速報などの情報インフラとして公の放送としての役割を維持しつつ、
売り上げの減少という形でテレビ局に適切な教訓（レッスン）を与えることができる。
そして私たちは、テレビ局がきちんと律されていること、を自分たちの目で確認できる。
分かりやすいことは大切だ。
BPOが書面で注意や勧告をテレビ局に伝えたところで、多くの国民はそれを知ることはないし、
それがテレビ局にとって、同じ過ちを繰り返さないにしようという反省を促す力があるのか不明だからだ。
提供した料理で食中毒が発生すれば、その店は短期間営業ができなくなるが、
評判は下がるだろし、一部の常連客を失うかも知れない。
けれど更正するチャンスは与えられている。
番組スポンサーの商品への不買は結果的にはCM停止と近い効果があると思う。
けれど、私たちは苛立ちたいわけでもないし、デモや不買運動をしたいわけでもない。
同じ結果を生むなら、社会的なルールとしてスマートに解決されればいい。
衣食住どれをとってもルールがあり、完璧ではないにしてもそれなりに機能している。
放送事業者はどうしてこうも罰せられず更正の機会を与えられないのだろうか。
テレビ業界の人々は叱られずに育った温室栽培のお坊ちゃまのように、幼稚で頼りない。
それは国民にとってもちろん不幸だが、彼らにとっても良いことだとは思えない。
私たちはCMがないことで、テレビ局の不祥事が罰せられていることを知り、
溜飲を下げ、少し穏やかな気持ちで、そのテレビ局の更正を見守る。
Webサービスになるんじゃないかなーってことを思いついたので、自力で作ってみよう思う。
プログラマとして社会人約三年経験後、無職半年目。別業界に行こうと思ってた。
でも思いついたからやってみるって言うのは有りだと思うんだ。
機能拡張とかばっかりだったから、どうしていいのかいまいちわかってない。
・レンタルサーバを借りる
・余裕があればドメイン取得
・開発言語はPHP（とはいえ独自フレームワークばっかりだったのでCakeとか使えないぞ……）
・MySQL実は使ったことがないんだよな。関数をチェックしておく必要性あり。
・UIはHTML5を意識したXHTMLで書いておけば将来的な移行がしやすいのかな。最初からHTML5で書くというのも手か？
・CSS3使ってもいいのかなあ
・関連商品の表示のために何をすればいいのか（DBに閲覧履歴を保持するのか？）
・他にも思いつき次第追記
・ここがわからないのであった
・twitterとかなのかな
まあ、作れないかもしれないけど、その時はその時。
ていうかね、
以前よりも日記を全体公開にする人増えたと思う
中にはユーザページすら表示させないような設定にしてる人もいるけれど
pixivとかでヘテロ男向けエロは堂々とご開帳するのがOKでも腐女子コンテンツはランキングに出てこないようにしろとか主張するのいたし。
あれは酷かったよなあ。
pixivユーザなんか99%二次オタで、外部から見りゃ丸ごと「キモいオタク」なのに、
「萌え萌え美少女はキモくない。正義。でもBLはキモい。二次イケメンもキモい。悪。」っつー連中がわんさか沸いてた。
萌え萌え美少女作品も、公式から許可されてない二次創作だったらブラックに近いグレーなんだって知ってます？
って言ってまわりたくなったよ。
http://www.youtube.com/watch?v=MGt25mv4-2Q
このCM動画だけど、Googleがミクを取り上げたとかで、一部で話題。だけど、僕にはこれがGoogle衰退の一歩に思える。
Googleは、ご存知の通り、ウェブサイトに配信する広告収益で非常に大きな利益を出している。これは、開発者にとって、夢のような環境をもたらした。収益部分と製品開発が分離することで、顧客の要望に煩わされることなく、収益性を考慮することなく、コンピュータサイエンスの粋を尽くせばそれでいいという環境ができた。ぶっちゃけ、広告を貼るスペースを出しておけば、何を作っても良かった。そんな単純でないけど、例えばGoogle Docsなどは、未だに広告がない。Gmailにも、昔風な広告フッタがない(作成画面にはあるけど)。こういう環境のおかげで、ユーザも開発者も誠意だけで仕事ができた。
そこで出て来たのが、先のCMだ。これはミクが世界に広まる様子を表現したものと思っていい。でも、これ、Google ChromeのCMだって知ってた? アカウントがChromeになっているの、気づいた? このCMからChromeの良いところって理解できた?
僕はわからなかった。スキンとかアプリとか出てくるのかと思ったけど、全然出てこなかった。要するに、焦点がぼけているのだ。
僕にはこれは怖い気がする。だって、Googleは、自分たちが何をしたいのか、何を売っているのか、理解してないんだぜ? 個人のお遊びならともかく、会社の名前でCM作って、何も伝えられなかったんだぜ?
ここでひとつ思考実験する。「もしGoogleが広告収益以外で利益を得る必要が出て来た時に、どうやって収益を得ることができるのか」。検索アプリを有償化するか? 無理でしょう。無料で獲得した利用者が、いくら不可欠だからって、有償化でついてくるとは思えない。一応有償アプリの販売プラットフォームになるよう努力しているけど、結局広告収益のほうが良すぎて、力が入っているとは思えない。いわゆる「イノベーションのジレンマ」というやつだ。収益の上がりすぎている事業があるために、次なる収益探しに力が入らないのだ。現にYouTubeは広告がベタベタだ。
奇跡的過ぎる例だけど、アップルはそれをやってのけた。アップルは、元の名前を「アップルコンピュータ」と言って、要するにパソコンを作る会社だった。それで一度大当たりをして、その会社として20年パソコンに力を注いだ。で、最初の10年はともかく、あとの10年でどんどんだめになった。でも、恐らくはアップルコンピュータでパソコン以外を自分たちのコア事業にしようだなんて夢想した人はいなかっただろう(Newtonとかあるのは知っているけど、結局コアにならなかった)。そこで、ジョブズがやってのけたのは、「アップルコンピュータを パソコン以外の会社にすること」だった。音楽プレーヤーを始め、今ではモバイルの先進となっている。だから、社名から「コンピュータ」を消した。
このように、Googleが、もし広告がダメになった時に、どういうことをするのか。それをGoogleは考えていないのではないか。特に日本法人。僕には、先の焦点のボケたCMが、そういうことを考えてない、ダメなGoogleの象徴に思えてならない。
第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 練習問題
