 
|
はてなキーワード: 用言とは
http://www.google.co.jp/intl/ja/policies/privacy/preview/
Google は、すべてのユーザーによりよいサービスを提供するために情報を収集しています。その内容は、お客様の使用言語などの基本的情報から、お客様にとって最も役に立つ広告やオンラインで最も重要視している人物などの複雑な情報まで、多岐にわたります。
お客様からご提供いただく情報 たとえば、多くの Google サービスでは、Google アカウントのご登録が必要です。ご登録に際して、氏名、メール アドレス、電話番号、クレジットカードなどの個人情報の提供をお願いしています。Google が提供する共有機能をすべてご活用いただく場合は、公開される Google プロフィールを作成していただくようお願いすることもあります。これには、名前や写真などを掲載することができます。
サービスのご利用時に Google が収集する情報 Google は、ご利用のサービスやそのご利用方法に関する情報を収集することがあります。たとえば、Google の広告サービスを使用しているウェブサイトにアクセスされた場合や、Google の広告やコンテンツを表示または操作された場合です。これには以下の情報が含まれます:
端末情報
Google は、端末固有の情報（たとえば、ハードウェア モデル、オペレーティング システムのバージョン、端末固有の ID、電話番号などのモバイル ネットワーク情報）を収集することがあります。Google では、お客様の端末の ID や電話番号をお客様の Google アカウントと関連付けることがあります。
お客様が Google サービスをご利用になる際または Google が提供するコンテンツを表示される際に、サーバー ログ内の特定の情報が自動的に収集および保存されます。これには以下の情報が含まれることがあります:
お客様による Google サービスの使用状況の詳細（検索キーワードなど）
電話のログ情報（お客様の電話番号、通話の相手方の電話番号、転送先の電話番号、通話の日時、通話時間、SMS ルーティング情報、通話の種類など）
端末のイベント情報（クラッシュ、システム アクティビティ、ハードウェアの設定、ブラウザの種類、ブラウザの言語、お客様によるリクエストの日時、参照 URL など）
お客様のブラウザまたはお客様の Google アカウントを特定できる Cookie
現在地情報を有効にした Google サービスをお客様がご利用になる場合、Google は、お客様の現在地に関する情報（携帯端末から送信される GPS 信号など）を収集して処理することがあります。Google は、たとえば、お客様の端末のセンサー データから提供される近くの Wi-Fi アクセス ポイントや基地局に関する情報など、他にもさまざまな技術を使用して現在地を判定することがあります。
固有のアプリケーション番号
サービスによっては、固有のアプリケーション番号が割り当てられています。この番号とお客様のインストール情報（オペレーティング システムの種類、アプリケーションのバージョン番号など）は、お客様が当該サービスをインストールまたはアンインストールする際に Google に送信されることがあります。また、当該サービスが Google のサーバーに定期的にアクセスする際（自動更新の際など）にも送信されることがあります。
Google は、ブラウザ ウェブ ストレージ（HTML 5 など）やアプリケーション データのキャッシュのようなメカニズムを使用して、収集した情報（個人情報を含む）をお客様の端末にローカルに保存することがあります。
お客様が Google サービスにアクセスされると、Google はさまざまな技術を使用して、情報を収集して保存します。その際、Google からお客様の端末に一つまたは複数の Cookie や匿名 ID を送信することもあります。広告サービスや他のサイトに表示される Google 機能のように、Google がパートナーに提供しているサービスの利用の際に、Google が Cookie や匿名 ID を使用することもあります。
引用終わり
2012 年 3 月 1 日に発効
えーまだやんの？ お前話が全然飲み込めてないのにまだやりたいの？
つうかお前の着地点はどこなの？ 元増田が嘘ついて適当こいて就職できればヨカッタヨカッタなの？
泣かずに説明したんでしょ？偉いじゃない。
繰り返しになるけど別に卑下する必要ない。
卑下とかじゃなくて、話が違うんだって。お前は徹底的に瑣末しか見えてないな。
「りんごが欲しいんだけどある？」「ハイありますorないので調達します」ってのが俺とか大体の健常者、
「こっちはりんごが欲しくてあなたがりんごを持ってるのは知ってる、そしてときどきりんごが出せなくなることがあるのもわかる、
じゃあそれってどんなとき？具体的に言えない？りんご出せなくならないために何してほしい？」
「……事前に具体的には言えません、どんなトラブルが生じるかもわからないし…解消のためにその都度お付き合いいただくしかないんですが…」
「何それ意味判らん。とにかくこっちはりんご出てこないと困るの。具体的にどうすればいいか言ってよ」が元増田（に近いといいな…例って難しい）。
元増田に「いいからりんごあるって言えよ」って言ってんのがお前。
企業に「りんご出てこないのはしょうがねーのに。元増田と一緒に現場を作り上げるのが一番手っ取り早いし、面接の段階で何がひっかかるかとか言い出しても話が細かすぎてどうもならん。つうかりんご出せないっての『わかる』っつってるけど要するに許容する気ないんじゃんウンコども」ってのが俺。
泣かないことが偉いとかじゃねえんだよ。むしろ泣くしかねえっつうのあんなもん。
採用面接官が物凄く好意的に採ろうとしてたとしても説明してくれない人は一番採りにくい。
お前こそ元増田と面接官の戦いに落とし込みたいんじゃんｗ 俺は面接官に悪意があるだなんてちーとも思ってないぜ。
やつらは単に受け入れ体制がなくて、体制がないから作ろうとは思っているけど面接時点でできる工夫はないと言われて勝手に気を悪くして受け入れる気がなくなってるだけだ。
自分の無知と傲慢を棚に上げて、「相互理解の姿勢が元増田にはない」と決めつけにかかっているだけだ。
悪意があるのはお前だ。最初から。一番最初のトラバ時点から元増田をボンクラだのバカタレだの呼ばわろうと虎視眈々としていたお前だ。
単に元増田の書いた文章の意味が分からないだけならば、そんな罵言が出てくるはずはないんだ。
「よくわからないんだけど、もうちょっと細かく説明してくれない？」が相応しい態度というものだ。
まして（読めばわかることだが）くだんの文章は元増田の記事のなかにあるがその主は企業だ。
元増田が企業（や、社会）から押しつけられていることをそのまま記述しただけだ。
意味判らないとしてもそれは元増田の責任じゃない。企業がメチャクチャ言ってるだけであり、お前の頭が残念な出来であるだけだ。
「どんな配慮が必要ですか？」って当人に聞くのは
当人の希望に沿って調整する用意があると言うことで、
俺の日本語ではこれを融通って言うんだけど
君の日本語では融通はどういう内容？
ゆう‐ずう〔‐ヅウ〕【融通】［名］(スル)
１ とどこおりなく通じること。転じて、必要に応じて自在に処理すること。ゆずう。
だそうだけど。俺の日本語っていうか一般的な日本語では。お前の使ってる「お前言語」日本語からズレ過ぎなんじゃね？
「必要に応じて自在に処理すること」。あらかじめマニュアルを決めることじゃなくて、いわゆる「臨機応変」の態度なのよ。
必要が発生してない段階から説明しろ希望を出せとか言われても無理なの。障害の故に説明能力がないというよりは、単に現場に出ないとわからないことなの。
それは融通がどうこうじゃなくて単に求人枠がない状態っていうんだよ。
家族にしろ職安職員にしろ、採用側より障害について知ってるから求められてる。
「十全なのかー」って十全なわけないし十全なんて求められてない。
障害の特性を一通り知っているし、いろんな例見てるだろうし、企業の側は「専門家」に意見が仰げて安心だし、被面接者は「助けてくれる人」に同席してもらって安心だし。
そして、これが一番ネックなんだが、特性を知ってていろんな例見てても「で、元増田さんには具体的にどんな配慮が必要ですか？」と言われたら、元増田も言ってた「一つのことに集中するのは得意で、二つ以上のことをやるのは苦手です」とかの一般的特性を述べるに留まってしまう。
それ以上具体的な部分に落とし込むことはできない。無理だ。やってみないとわからない。
代弁しろとか言われてもできないよ。わからないことはわからないとしか言えない。元増田が泣いてしまったからといって口は出せないだろう。
そこで説明するべき内容は元増田が決めることであり、元増田が話すべきことだってことになるからだ。
しかし「答えはない」なんて真理だが言えねー。啖呵切るならともかく就職面接でなんて俺だって言えねえ。
その意味では、元増田の記事の一番最後の「答え」は、例え本当の部分とはなんかズレている気がしても答え方としてかなりうまいと思う。
でもきっと企業側はあくまで具体的な対策を言わせたいんだろうなー…とか思うと他人事ながら気が重い。
余談だが、家族を同席させることの何がアレって、企業視点では対応次第で裁判沙汰とか面倒なことになるんじゃないかという恐怖がありそう。
だから「企業の迷惑を顧みない非常識行為」となる。少なくともモンペはそういう位置づけだろ。
お前の常識が既に世間一般の常識から離れてるし（なにせ使用言語が日本語からズレてる）、そんなこと言っても何も説得力がないなｗ
君との話し合いは繰り返し日本語の問題に突き当たるけど
「有利」と「必勝」は違う。
元増田は今回は有利さを生かせなかった。
だから、「元増田の有利さ」って何だよ。お前が言うように同席して説明してくれる人は職員がいたけど特に有利ではなかったじゃん。
つうかそれで有利になると思ってるお前の頭がどうかしてんだよ。
追記のトラバあったよ。ツリーを探してみ。
事前に文章にまで仕立てて持ってってんだよ。
それで面接官の切り返しがあの「僕らの立場」よ。アホくさいわ。
そもそも、要求して何が悪いんだろう。企業の要求は悪なのかな？
負けずに要求し返したりすればどうだろう？
要求し返すのはいいな。元増田の記事の最後の部分、あれはなかなかいい。
読み返しても
また、配慮して欲しいポイントをきれいに説明できるのであれば、障害者手帳なんて要らない。
なぜなら、配慮が無くても仕事を出来る場所を探せばいいのだから。
「そんな指摘をするなんてお前はあっちの味方だな」という反応は小児的だし混乱してる。
ある一文が論理的におかしいと、その一文の作り手ではない人間に指摘するのはおかしい。それこそ論理的にｗおかしい。
あるいは企業とはすなわち健常者社会の象徴とでも捉えて、自分の胸に手を当ててじっくり考えるのもよかろ。
手も当てずに逆ギレしてんのは大人の態度とはとても言えない。小児のみっともなさというよりは小児的大人のみっともなさではあるが。
その後で意味が通じてんじゃん。「あー、やっと言わんとすることはわかった。」と。書いてあるぜ。
またわかんなくなっちゃったの？ 「今もわからないけど。」って。
わからないことをわかるって言うのは知ったかぶりって言ってなかなかに害悪だし、
わかることがわかんなくなっちゃうのは病気かもしんないから医者行った方がいいよ。
俺にはお前のその一貫性のなさが判んないよ。悪意という串が通ってなかったら絶対把握できねえ。
君が今凄くストレスを感じてるのはわかってる。
そういう時の自分の文をこそ観察して、思考パターンの動きを省察するといいと思う。
ザッと流し読みしても「バカ」とかそういう言葉が激増している。
ネガティブ･不貞腐れ思考、対立認識、破滅願望、攻撃性、etc.
そのパターンが一度でも君を本当の意味で愉快な気持ちにしたり、
物事の解決の助けになったりすることがあったか思い返してみて欲しい。
大いに解決の助けになっている。少なくとも妨げにはなってないな。
ストレスはセンサーだ。何が引っかかるかを強烈に俺に教えてくれる。
俺は俺を引っ掛けるものを理解して分解することができる。ストレスはそのスピードを上げる。
で、お前は俺の文章から何か学べたか？ 「知能」の意味は検索したのか？
してないよな。するわけがない。「この話の核だから」と言っておきながら、お前には元増田の障害を知ろうという意志がない。
お前には向上心はない。
お前にあるのは悪意ぐらいだ。
追記。
そう。あの増田なのよ、俺は。
本性はとても真面目で綺麗なのよ。うわあ鳥肌立つｗｗｗ
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
重役「君、いかがでしたでしょうか？という言葉遣いはないだろう。」
重役「いや、それもちょっとね」
というなら意味不明でもない。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q127330212
「いかが」「でした」は敬体で、丁寧な断定。「でしょうか」は①に同じ。バランスはよいが、くどい。「でしょうか」は一種の補助用言と看做し、削除する工夫をしたほうがよい。
まあ、パッと検索して四百万件も結果が出るのだから、変に思う人は少ない、言ってみれば正しいことばづかいということになるな。
site:ac.jp 10400件
ということで、特段俗な言葉というわけでもない。まあ、さ入れ言葉ならぬ、でしょう入れ言葉、でした入れ言葉といったところか。
ブログに書くと、一発で仕事バレするようなニッチなネタなのでここにメモっとく。
http://www.atmarkit.co.jp/fsys/zunouhoudan/091zunou/xmos_cpu.html
ここではボロカスに書かれていたが、やっと安い評価キットが出はじめた。
http://www.csp-consortium.org/apps/XMOS_training_kit%282010-08%29.pdf
ニコニコ技術部あたりが食いつきそうなネタではあるものの、今の所ニコ動でXMOSで検索しても１本も出てこない。
デジキーですぐ買える。チップ１０００円～３０００円。小規模な評価キット２万～３万ぐらい。
ちなみに総産研にXMOSという名前を使った特殊なMOSトランジスタの研究発表があるが、それとは全く別物。
特徴：
普通にC言語でも使えるらしいが、チップの特徴を活かすためにはXC言語という専用の言語を使う。
昔、トランスピューターをやってた人達が作った。なので、XCの実態はトランスピューター用言語とC言語を混ぜたような感じ。
・小規模な組み込み向けの用途において、安価なチップで、並列処理とかイベントドリブンな処理が可能、という点が画期的。並列処理は大規模コンピューティングだけのものじゃないよ！という熱いメッセージ。
・ハードウエアの動作をソフトでエミュレーションする処理は、いわゆる「ワンチップマイコン」よりは得意＆楽。
・XCは言語仕様としてポインタが削除されてる（！）。XCをC言語の派生言語と呼んでいいのか迷う所。
・XCは、昔のトランスピュータを勉強した経験がある人じゃないと、上手には使いこなせないクセモノ。いい感じにガラパゴス化しとる。
・大容量のメモリをつなぐことを想定した専用ハードを持ってないので、自ずと用途は限られる。（DRAMのI/Fをエミュレータでやれ、なんて言われても絶対嫌だ。）
・XCの言語仕様は、「木に竹を接いだ」ような状態で、お世辞にも美しいとは言えない。ソースコード眺めてるだけでムカつく。（将来的に改善される可能性はある）
・「チャネル」というのが１つのキモだが、この帯域幅が今時のチップとしてはしょぼい。ただしこの欠点は大量のチップを並列に使えば、理論上はある程度補うことが可能らしい。
・MMUを持たないので、Linuxを移植できないのか、と言われるとツラい。
XMOS応用例 Youtubeでもやっと数千再生しか行ってない。
http://www.youtube.com/watch?v=4gbFagvjSfU
http://www.youtube.com/watch?v=eLyn2Ghq_oE
http://www.youtube.com/watch?v=atAdpt5SZe8
今、XCとXMOSに取り組めば、あっという間に国内のこの界隈では有名人になれるかもしれない。強いて言うならそこが唯一の魅力。
http://anond.hatelabo.jp/20100428154312
矢吹健太朗はたぶん日常でトラブるって使ってるんだと思う。その上でかけてるんじゃないかな。GoogleIMEでも候補に挙がるし、使用者は一定数いるんだろうね。
そのマンガはどちらかというと[トゥラブる]って発音したいなあ。あ、[twu]が含まれる用言ってのも珍しいなあ。
http://anond.hatelabo.jp/20100428154421
あ、忘れてた。それも英語で書くと不自然というか、カタカナ表記で定着した感じだね。
ル・クプル信者になることを「ル・クプる」というのを思いついた。でも使うきっかけはなさそうだ。
ああ、「ドナる」ってのもあったなあ。ドナ教の影響力は恐ろしい。
「disる」という言葉を見たとき、「ここまできたか」という反応だった。
英語が、ついに日本語の用言まで、しかも「名詞＋する」といういわゆるサ変動詞ではない形として表れたのである。
日本語、あるいは日本語話者が積極的に英語に触れるようになった一つの形であり、おそらくネットができてこそのものだ。
私はこれを歓迎する。ことばの深淵を目の当たりにしたかのような思いであり、心熱く感じる次第である。
そこで、いくつか提案したい
ミスるということばは、[missる]と書いていこう。
トラブるということばは、[troubる]と書いていこう。
旅行するということばを、[traveる]と書いていこう。
下の増田に触れ、
ゲームを作りたい C言語の基礎を学ぶ それだけじゃゲームが作れないことが判明
win32apiを学ぶ 多すぎて？状態で挫折
ゲーム作るのはあきらめよう！チートだ！ アセンブリが面倒で挫折
向き不向きってあるよね・・・。もう勉強したくない・・・。
俺には向いてないんだろな。だってwin32apiでGUI作りで投げ出したくなったもん
俺の読んだ本
明快C言語 ダイテルC言語（例題飛ばしたのでほとんど意味なし） やさしいC 独習C
windowsゲームプログラミング（最後のテトリスとブロック崩しが面倒で飛ばした）
独習java（ガベージあたりで挫折） windows32api徹底理解 ホームページ作成の本（名前失念）
アセンブリ言語の教科書（100ページあたりでソースを読み解くのが・・・以下略）
何のために勉強しているかわからなかった・・・たぶんC言語の基礎すら身についてないと思う
じゃあweb関連や初心者用言語（php,ruby,pythonとか）学べばいいじゃんってネットで指摘されたんだけどさ
そうじゃないんだよ問題なのは。ライブラリの使い方がわからないし必要な技術がそれだけじゃないだろうし
今roboformのようなもの作りたいんだけどどうつくったらいいんだろ（guiは無理なのでコンソールで）
perlとかruby,phpで記述して通信プロトコルの勉強すればできるんだと思うんだけど俺にはもう体力が残ってない
あまりにも無駄な遠回りをしてきた。でも願望だけが空回りしてる。ライブラリもごまんとあるうえに通信プロトコルも勉強しないといけないんでしょ。甘えっていわれてもかまわない誰か助けて
最近、Googleやら百度やらから新タイプの日本語変換が披露されてゐますが、仮に百度の奴で正字正かなを入力する場合について考へてみます。
要は簡単で、不断字訓で投入してゐる部分を意図的に字音で投入してから、其の侭、活用語尾を入れちまふんです。
例へば「考へ」なら「こうへ」と投入すれば変換できます。又、「言ふ」の場合は「げんふ」と投入して、「言」を変換してから、「ふ」を無変換釦で仮名の侭出力させます。用言を態々字音に変換する手間が架るのが厄介ですが大抵の語句は出力できる筈です。
唯、百度の奴の最大の缺点は、仮名の「ゐ」と「ゑ」とがどうやつても投入できない。他の仮名からの変換も出来ない。現状、別の文章からのコピペでしか対応できない。之は非常に痛い。
http://anond.hatelabo.jp/20091109124346の続き。
http://d.hatena.ne.jp/keyword/%C3%AB%B7%E7?kid=280719
http://s01.megalodon.jp/2009-1117-0036-02/d.hatena.ne.jp/keyword/%c3%ab%b7%e7?kid=280719
* globpoint 2009/11/16 11:18 日本語の文中に頻出する一般的な用言の活用形を登録することに反対です。
* konoike 2009/11/17 00:14 「運び」は頻出する用語とまでは言えない。削除は不当。
http://d.hatena.ne.jp/keyword/%b1%bf%a4%d3?kid=279694&mode=edit
* globpoint 2009/11/13 16:29 日本語の文中に頻出する用言の活用形であり、誤ったリンクばかりを生成しており、キーワードとして期待される機能を果たせるとも思えない。
* konoike 2009/11/13 17:46 日本語に頻出する単語ではない。削除は不適切。
* globpoint 2009/11/16 11:30 実際に「含むブログ」を見ても、「運ぶ」の敬語「お運びになる」の活用形にばかりリンクしています。
* konoike 2009/11/17 00:16 これはひんしゅつすることばとはとてもいえない。
http://d.hatena.ne.jp/keyword/%a4%aa%b1%bf%a4%d3?kid=279563&mode=edit
* globpoint 2009/11/13 14:13 さまざまな文脈で広く使われる一般的な単語で限定した解説は不適切。誤ったリンクも多く、キーワードとして機能し難い。
* konoike 2009/11/13 17:44 一般的な単語にはあたらない。
* globpoint 2009/11/16 10:56 「本部」と呼称されるあらゆる種類の組織で、その構成員は「本部員」とよばれる。なんらかの特定組織を示す言葉ではなく、きわめて一般的な単語。
* konoike 2009/11/17 00:18 本部員という後はほとんどの組織では使わない後であるため、削除は不当
http://d.hatena.ne.jp/keyword/%cb%dc%c9%f4%b0%f7?kid=279897&mode=edit
* globpoint 2009/11/12 16:46 通常の日本語の文章中に頻出する単語であり、はてなキーワードとして期待される機能を果たし難いと思われることから削除を提案する。
* konoike 2009/11/13 17:48 一般的な解説を加えた。
* mirror3 2009/11/15 21:14 ■中立的でない偏った内容 、編集ガイドライン違反常習の疑義
* konoike 2009/11/17 00:22 語彙の説明自体は規約を違反するような内容ではない。
http://d.hatena.ne.jp/keyword/%ba%a8%a4%df?kid=280089&mode=edit
* globpoint 2009/11/12 16:46 通常の日本語の文章中に頻出する単語であり、はてなキーワードとして期待される機能を果たし難いと思われることから削除を提案する。
* konoike 2009/11/13 17:48 頻出する単語にはあたらない
* konoike 2009/11/13 17:49 頻出する単語にはあたらないので削除は不適切。
* mirror3 2009/11/15 21:18 ■中立的でない偏った内容 、編集ガイドライン違反常習の疑義
* mirror3 2009/11/15 21:19 親ワードとなる、「天理教」の中で、編集してください。
* konoike 2009/11/17 00:25 一般的な語義も付け加えました。
http://d.hatena.ne.jp/keyword/%ca%a2%ce%a9%a4%c1?kid=280134&mode=edit
* globpoint 2009/11/12 15:01 誤ったリンクを生成しているばかり。説明も要領を得ず、独立したキーワードとして登録することが適切と思えない。
* konoike 2009/11/13 17:50 削除させるまでには値しない。
* mirror3 2009/11/15 21:21 説明が第三者に対して、■中立的でない偏った内容■他の人に理解できない内容 以上、２点、明確にガイドラインに抵触する。
* konoike 2009/11/17 00:26 一般的な語義も
http://d.hatena.ne.jp/keyword/%a4%f2%a4%b7%a4%a4?kid=280008&mode=edit
* globpoint 2009/11/12 12:50 通常の日本語文に頻出する用言であり、キーワードとして登録することには反対する。
* konoike 2009/11/13 17:43 一般のカテゴリへ移動。
* mirror3 2009/11/15 21:22 説明が第三者に対して、■中立的でない偏った内容■他の人に理解できない内容 以上、２点、明確にガイドラインに抵触する。
* mirror3 2009/11/15 21:23 仮に、天理教が、日本の国教なり、世界宗教なり、メジャーな存在なら、存続意義を認めるが、天理教は、現在、日本において不特定多数の第三者に対して、一般的な存在といえない。
* konoike 2009/11/17 00:31 中立でないというにはあたらない。この用語解説において天理教を批判非難しているわけではない。
http://d.hatena.ne.jp/keyword/%c1%fe%a4%a4?kid=280112&mode=edit
* globpoint 2009/11/11 11:34 登録者による論評であり、キーワードとして登録するのは不適切
* konoike 2009/11/17 00:35 内容全面変更
http://d.hatena.ne.jp/keyword/%d4%bc%a4%ac%a4%c4%a4%e2%a4%eb?kid=279905&mode=edit
* n_kakka 2009/11/09 22:35 重複のため。
* konoike 2009/11/17 00:37 一般的な意味と、天理教的な意味は分けて別の項目にしておく方がいいだろう。
http://d.hatena.ne.jp/keyword/%a4%db%a4%b3%a4%ea?kid=280029&mode=edit
URL： http://www11.atwiki.jp/tenrikyo/
URL：http://shukyohigai.wiki.fc2.com/?page=天理教
URL：http://www11.atwiki.jp/anti-religion/pages/40.html
http://d.hatena.ne.jp/keyword/%a4%db%a4%b3%a4%ea?kid=280029
http://s01.megalodon.jp/2009-1117-0659-46/d.hatena.ne.jp/keyword/%a4%db%a4%b3%a4%ea?kid=280029
（ブックマーク数がとんでもないことになったため、元増田はうかれている。なので匿名ダイアリーなのに、ペンネームまで書いてしまった。タイトルに大きく、須江岳史、と。しかし、プロの小説家でもない一人のプータロウが書いた文章がこんなにもてはやされることを、すこし疑問にも思っている。ちょっと足を伸ばして図書館に行けば、小説の書き方についての本はいくらでも手に入るはずだ。何かを学び取る目的ではなく、長すぎるからブックマークしておいた、というのなら、納得する。というかこの論は物語と小説をニアリーイコール扱いしていて、小説論としてはちょっと古いというか、語りという小説の大問題がスルーされていて厳しい。という指摘も当然のことで、普段、一人称の小説ばかり書いている自分には、人称とか視点とかいった物語を語る上での問題について取り組む実力は無い。「小説は自己表現なんだから、各々が語りたいように語ればよいと思う」のような言葉で、逃げることしか出来ない。僕の小説の実力がどの程度かは、http://texpo.jp/texpo/disp/16732を読めばわかると思います）
Ⅰ、小説概論
まず話の筋の作り方を考え、次にそれをどのように小説として表現するかを見、最後に小説を書く上での国語的諸注意事項を述べる。
そもそも小説がどのような構成要素から成り立っているかを考える。
まず、小説だけではなく物語一般の話の筋がどのように出来ているかを考える。
多くの物語は、欠損-充足の形を持つ。多くの物語は主人公に何かが足りない状態から始まり、それが満ち足りた状態で終わる場合が多いということである。
また、満ち足りた状態にたどり着くためには満ち足りた状態になるための行動が必要になる。そして行動をとるためにはその機会が与えられないとならない。
ここまでをまとめると、物語の筋は
欠損 – 機会 － 行動 － 充足
となる。
具体例としては、
少女は城で行われる舞踏会に行き、王子に会いたかった（欠損）。そして王子に会うことが出来た（充足）。
ただ、物語の面白みのためには、充足が起こらないほうが良いかもしれない。行動の結果が、充足の起こらない失敗に終わり、それが新たな欠損となり次の話の筋を紡ぎだすこともありうる。
よって、物語を構成する基本的な四つの要素は
欠損 － 機会 － 行動 － 結果（充足または失敗）
であるとする。この一連の流れが組み合わさることによって、物語は出来上がる。
具体例としては、
少女は城で行われる舞踏会に行き、王子に会いたかった（欠損）。そして王子に会うことが出来たが、十二時の鐘がなったので帰宅しなければならない（失敗に終わった結果、新たな欠損）。
少女は名乗り出て靴をはく（行動）。
後味の良し悪しの面から見て、最終的には充足で終わった方が良いように思われる。
また、欠損があって、それを解決する機会を与えられれば物語が始まることがわかる。
また、欠損を細分化したうえで見つかる欠損というのも考えられる。
たとえば、
鬼を退治するためにはお供を仲間にしなければならない。お供を仲間にするためには黍団子を持っていなければならない。
黍団子を持つためにはおばあさんから黍団子をもらわなければならない。
おばあさんから黍団子をもらうためには黍団子の材料を買ってこなければならない。
というように。
このようにすれば物語はいくらでも引き伸ばすことが出来る。書くべき物語の分量によって、どの程度まで細分化できる欠損なのかを慎重に選ばなければならない。
一つの物語で充足される欠損は一つとは限らないし、主人公たちの欠損が充足されるとも限らない。『ロミオとジュリエット』では、主人公たちの恋愛は成就しないが、キャピュレット家とモンタギュー家の関係が、対立から和解へと移り変わる。
物語は、話の筋それ自体で面白いことが最善であるけれども、それが出来ない場合には伏線によって面白さを増幅させるしかない。
ここでは、仮に伏線には四種類あるとする。
ⅰ）質問―答えⅱ）ある現象/行為への意味の付加―行為/現象の再現
ⅲ）行為・現象―行為・現象のリフレイン
ⅳ）思い込み―認知
それぞれ、順を追って説明する。
物語冒頭に置かれた質問に、ラストシーンで答えることで感動を増す。
具体例：どうしてキノはこの汚い世界を旅しているの？（冒頭の質問）
ある現象・行為にはある意味が隠されている、と登場人物が語り、その現象・行為が実際に現れる。
『アヒルと鴨のコインロッカー』だと、
『「（とにかく面倒だから、神様を閉じ込めて、全部なかったことにしてもらえばいいって。そうすれば、ばれない）」』（70ページ）という免罪の方法を提案して、実際に物語の最後付近でそれを行っている。
物語の中で起こった行為・現象が物語の終盤で再現されることにより、面白みが増す。
『アヒルと鴨のコインロッカー』だと、
『聞いてるわたしにも、どうやらこの姉弟がレッサーパンダを盗む気らしい、ということはわかった。』（216ページ）『動物園を振り返って、「さっきの子供たち、うまくやり遂げるかな？」と。』（222ページ）
というようなレッサーパンダを盗むという行為があった上で、
『「あれ、レッサーパンダだ」』
『「盗んだんだよ、あの子供たちは」』（339ページ）
間違った方法を目的を得るための方法だと思い込み、それが間違いであったことに気づく。多くの場合、気づくまでに行ってきた行為が主人公に、行為の目的とは反対の結果を持って跳ね返ってくる。
物語の筋が悲劇的に終わっても、ⅰ、ⅱ、ⅲの伏線が幸福を含意していると悲劇性を和らげることが出来る。
目的達成を阻むものが、あるものだと仮定して行動していたが、その仮定が正しくなかったことに気づくタイプの伏線。多くの場合、気づく前の行動が気づいた後に本来の意味とは反対の意味を持って主人公に跳ね返ってくる。
認知は、約束―報いの伏線によって引き起こすのが最も容易である。
主人公の目的を阻むものは四種類ある。カッコの中の左側は存在場所、右側は存在原因を意味する。
（自己，自己）例：主人公の性格の欠陥（他者，自己）例：主人公に対して恨みを持っている敵
（他者，他者）例：絶対悪
敵の仮定が４パターン、真実の敵が４パターンあるので、認知型の伏線には全てで16パターンあることになる。
これは、『あらすじ.com』の三匹のモンスターの概念を内包している。
（自己，自己）狼男（自己，他者）対応しない
（他者，自己）フランケンシュタイン
（他者，他者）ドラキュラ
物語には六種類の登場人物がある。
主体：物語の主人公。欠損を解決する。送り手：主人公に、欠損を解決する動機を与える者。
援助者：主人公に、欠損を解決する能力を与える者。
受け手：欠損の解決の享受者。
敵対者：主人公の欠損解決行動を阻む者。
それぞれ、同一人物が複数の行為項を演じても良いし、ひとつの行為項に複数人が入っても良い。たとえば、送り手と援助者が同一人物であることは大いにありうる。また、それぞれが必ずしも人間である必要もない。
欠損ごとに行為項モデルは立てられるので、ある場面では敵対者であった存在がある場面では援助者になることもありうる。
物語に出てくる全ての欠損について、行為項モデルの六つの登場人物を生めることが出来れば、それ以上の登場人物は物語に必要ではない。
物語の冒頭やクライマックスを盛り上げるためにシチュエーションは使われる。
面白いシチュエーションとは、即ちギャップである。
それは場所と行動のギャップであるかもしれないし、それまである登場人物のそれまでの行動とはかけ離れた行動かもしれない。いずれにしろ、「～であるにもかかわらず」という言葉で表される。
たとえば、「日ごろ温和な性格であるにもかかわらず、暴れ狂う」とか「静粛でいなければならない図書館であるにもかかわらず、暴れ狂う」とか、「たかが100円のアンパンを食べてしまっただけのことであるにもかかわらず、暴れ狂う」とか。
物語を組む順番として、『欠損－伏線とシチュエーション－細分化されていない欠損の話の筋－細分化されていない欠損の行為項モデル－細分化された欠損の話の筋－細分化された欠損の行為項モデル』といった順番で組んでいくのがスマートに行く。なぜならば、欠損がなければ物語は動き出さないし、伏線とシチュエーションは話の筋や行為項モデルあとから考えるとそれらに縛られて上手くいかないからである。
①、主人公が向かう目的を定める。②、主人公が見舞われる危機を定める。または、どのようなギャップがある状況に立たされるかを決める。
③、危機・ギャップが何故起こるのかを決める。（伏線の回収の仕方を決める）
④、危機がどのように回避されるのかを決める。（伏線の回収の仕方を決める）
⑥、必要ならば、下位物語にも①～⑤を施す。
⑦、物語（下位物語も含む）の適所に、ギャップによる面白みを与える。
⑧、整合性を与える。
また、どのような魅力的な登場人物・伏線・シチュエーションでも物語の自然な流れを妨げるなら切り捨てるべきである。
場面では、人物、場所、時間が描かれる。人物、場所、時間のうちのいずれかが変わったとき、場面が転換されたという。また、場面は一人称であれ三人称であれ場面に登場する一人の人物の視点を通して描かれることが多い。
場面の特徴として、行為・現象の一回性が挙げられる。場面は、一度しか起こらない行為・現象を場面に登場する人物の感覚を通じて読者に体験させる。
場面の始まり方として、人物・場所・時間を指し示して始まる場合、登場人物の行動から始まる場合とがある（台詞から始まる場合は、登場人物の行動から始まる場合の特殊例とみなす）が、そのいずれにせよイメージすることが出来るか否かが読解の容易さを決めるので、場面の開始からまもなく人物・場所・時間を明らかにしなければならない。
小説を読む上では情景をイメージしやすいほうが読解が容易であるといわれているので、色彩や位置関係を表す語を使って場所や時間を説明するべきである。
場所・時間の説明は描写法的だといえるが、その場所・時間におかれたものを登場人物の行動の目的語にすると、スムーズに場面を始められる。
何かが起こるたびに、その場面に登場している人物全員の反応を描くべきである。また、その感情は、どのような身体的動作を持って表情として表されたかを描くべきである。なぜならばイメージしやすいほうが読解が容易であるからである。
要約法は、登場人物が何度も行った行動や何度も起こった現象を記述する。場面法とは違い、複数の時間や場所をまたがる事が出来る。そのため、時間や場所の離れた場面と場面をつなぐのに要約法は用いられる。
要約法は場面と場面とをつなぐためにしか存在しない。
場面法が動画だとすれば、描写法は静止画である。
描写法は、場面が行われている空間にあるものを描写する。場面が行われているなか描写がはさまれると、場面の時間を止めることが出来る。
台詞は音楽で言えばフォルテ、地の文は音楽で言えばピアノのような効果を持つ。多くの場合、台詞はカッコにくくられる為に強調されるが、台詞続きの中で地の文が出てくると大きな強調効果を持つことがある。たとえば強調すべき台詞をあえてカッコでくくらずに地の文で処理することで大きな強調効果を与えることができる。
台詞と台詞の間の間をつなぐために、地の文をおきたくなることがしばしばある。こういったときのために、場面の情景を刻々と変化させるとか場面の登場人物に場面開始と同時に何か動作をさせる方法がある。
書き手の中で起こった感動が読み手の中でも起こるためには、文が書き手の意図するとおりに伝わらなければならない。誤読を少なくする方法をここでは述べる。誤読を避けるために、修飾語と被修飾語、主語と述語は可能な限り近づける必要がある。
「私は走る車に飛び乗る」のような文は、読者が「私は走る」と理解した後で、走っているものは車だと改めて理解する。このような事をなくするために、「走る車に私は飛び乗る」のように主語と述語を近づける必要がある。
主語と述語の対が二個以上あり、どちらかがどちらかの文の成分になっているような文を複文という。
「私はリンゴを片手で握りつぶす彼はとても握力が強いと思う」というような文は読解が難解である。これも、主語と述語を出来る限り近づけ、「リンゴを片手で握りつぶす彼はとても握力が強いと私は思う」とすると読解が容易になる。また、複文を単文（主語と述語の対が一つである文）に分解し、「彼はリンゴを片手で握りつぶす。彼は握力がとても強いと私は思う」というようにすると、誤読は少なくなる。
日本語は上から下に修飾が行われるため、様々な不都合な事が起こる。
「美しい獣と女」は、美しいのが獣だけなのか、獣と女の両方が美しいのかが判然としてない。美しいのが獣だけである場合は、「女と美しい獣」のように順序を入れ替えるか、「賢い女と美しい獣」のように両方に修飾語を与えてしまう方法がある。
「地中海で育った少年からもらったトマト」は、トマトが地中海で育ったのか少年が地中海で育ったのかはっきりしない。トマトが地中海で育ったのであれば、「地中海で育った、少年からもらったトマト」のように読点を打つか、「少年からもらった地中海で育ったトマト」のように順序を入れ替えればよい。ただし後者の場合、地中海を少年からもらったように誤読される可能性が無くもない。
ガーデンパス文や修飾の範囲の判然とない文を作らないために、長い修飾を伴う語を文の始めに持っていく方法がある。
「僕は地中海で育った、青白い肌をした細身の少年から貰ったトマトを食べた」よりは「青白い肌をした細身の少年から貰った、地中海で育ったトマトを僕は食べた」の方が誤読が少ないとされる。
一文の中に含まれる用言（形容詞、形容動詞、動詞）と難読語の量、読者の視線の移動距離に依存して、文章の体感時間は定まるとされている。
たとえば①、「彼が作った美しいサッカーボールを僕は強い力で蹴飛ばす」よりは②、「彼が作った美しいサッカーボール。それを僕は強い力で蹴飛ばす」の法が一文に含まれる用言が少ないために体感速度が短いとされる。③、「ええい、お前は畢竟、俺が死ぬのが怖いだけだ」の『畢竟』が難読語だと見なす人にとっては④、「ええい、お前は結局、俺が死ぬのが怖いだけだ」の方が体感速度は短いかもしれない。また、⑤、「やわらかいネコ」よりは⑥、「柔かい猫」の方が、視線の移動距離が少ないために体感時間が短いとされる。
小説の場合、論説文とは違い改行は自由に行える。
行を改めたときは一段下げる。
「しかしカギカッコで新たな行が始まるときはその限りではないというのが最近の主流である。また、主流では閉じカッコの前では句点は打たない」
――また、三点リーダー（…）とダッシュ（―）は二つで一つの扱いをする……。
あれだよ。俺達（年齢は知らんが）がジジイになる50年後とかでは、「ちょりーんッス」とかが常用言語になってて、「そうなんスよ」とかが正式な敬語扱いになってるって！
via Twitterオタが非オタの彼女にTwitter世界を軽く紹介するための10ユーザ
まあ、どのくらいの数のプログラミング言語オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らないプログラミング言語の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、プログラミング言語のことを紹介するために
習得させるべき10言語を選んでみたいのだけれど。
（要は「脱オタクファッションガイド」の正反対版だな。彼女にプログラミングを布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、アーキテクチャに過度に依存するアセンブラ等の低級言語は避けたい。
あと、いくら基礎といってもBrainf*ckやUnlambdaのような難しすぎるものは避けたい。
ポール・グラハムが『Arc』は外せないと言っても、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
ロジカル度が高く、頭はけっこう良い
まあ、いきなりここかよとも思うけれど、「Java以前」を濃縮しきっていて、「Java以後」を決定づけたという点では
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な言語について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうなプログラミング言語（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのものという意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには一番よさそうな素材なんじゃないのかな。
「プログラミング言語オタとしてはこの二つは“教育用言語”としていいと思うんだけど、率直に言ってどう？」って。
ある種の言語オタが持ってるラムダ計算への憧憬と、ACM監修の関数型言語的純粋さへのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも参照透過な
の二要素をはじめとして、オタ好きのする要素を言語にちりばめているのが、紹介してみたい理由。
たぶんこれを見た彼女は「Emacsだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜の作品がその後続いていないこと、これがポール・グラハムの間では大人気になったこと、
ポールグラハムがウェブサービスの構築に使って、それがいろんなウェブサービス開発者にも影響しててもおかしくはなさそうなのに、
実際のウェブサービスでこういうのが使われないこと、なんかを非オタ彼女と話してみたいかな、という妄想的願望。
「やっぱりプログラミングはバッチ処理のためのものだよね」という話になったときに、そこで選ぶのは「awk」
でもいいのだけれど、そこでこっちを選んだのは、この言語にかけるラリーとdankogaiの思いが好きだから。
断腸の思いで延ばしに延ばしてそれでも2008年、っていうPerl 6のリリース予定日が、どうしても俺の心をつかんでしまうのは、
そのリリースというイベントへの諦めきれなさがいかにもオタ的だなあと思えてしまうから。
Perlのリリース延期を無駄だとは思わないし、拙速なリリースは無茶だろうとは思うけれど、一方でこれが
GuidoやMatzだったらきっちり予定通りリリースしてしまうだろうとも思う。
なのに、各所に頭下げて迷惑かけてリリースを延期してしまう、というあたり、どうしても
「自分の言語を形作ってきた哲学(TMTOWTDI)が捨てられないオタク」としては、たとえラリーがそういうキャラでなかったとしても、
親近感を禁じ得ない。言語自体の高評価と合わせて、そんなことを彼女に話してみたい。
今の若年層でPostscriptを直で書いたことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
PDFよりも前の段階で、DTPの哲学とか印刷技法とかはこの作品で頂点に達していたとも言えて、
こういうクオリティのプログラミング言語がエディタで書かれてたんだよ、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなくプログラミング言語好きとしては不思議に誇らしいし、
いわゆるJava VMでしかスタック型言語を知らない彼女には見せてあげたいなと思う。
PHPの「HTMLに埋め込み可能な点」あるいは「RDBMSとの接続性」をオタとして教えたい、というお節介焼きから教える、ということではなくて。
「HTMLのテンプレートエンジンを作り続ける」的な感覚が言語オタには共通してあるのかなということを感じていて、
だからこそアメリカ版『Yahoo!』の開発言語はPHP以外ではあり得なかったとも思う。
「MとVとCを分離なんてできない」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の
源はPHPにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういう述語論理風味の計算をこういうかたちで言語化して、それが非オタに受け入れられるか
気持ち悪さを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にC++を選んだ。
Javaから始まってC++で終わるのもそれなりに収まりはいいだろうし、テンプレート以降のメタプログラミング時代
の先駆けとなった言語でもあるし、紹介する価値はあるのだろうけど、もっと他にいい言語がありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10本目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
こういう試みそのものに関する意見も聞けたら嬉しい。
「すべからく」の場合も、多くは「べし」と呼応するけれども全部がそうというわけでもないよう。
はたしてそうか？
とは
だから「べし」が無いから誤用とすべきというわけでも無い。
学習の意欲が湧いて、しかも、それが持続する。
『だって、これを使えるようになると、毎日、インターネットから新しい 画像とか、動画とかを自動的に集めることができるよ。
いろんなところをクリックしては ガッカリすることもないよ。
あなたは何歳ですか？とかいう野暮な質問に いちいち答える必要も無いし』
こう教えてあげるだけでいい。
10代、20代の ぴちぴちした生きのいい男子が 血走った目で、Perlを勉強すると思う。
たまに、試作品のプログラムをテスト中に、うっかり悟りを開いてしまうこともあるかもしれない。
「俺は何を馬鹿なんだ…、今日はもう寝よう」っていう日もあるかもしれない。
だけど、大丈夫。
次の日になれば また補充されるから やる気が。
ぶっちゃけ、Perlを勉強する動機の8割くらいがそれでしょ。
【元記事】最もタメになる初心者用言語？ - ぼくはまちちゃん！
root権限奪取とか、SQLインジェクション持ち出されても、はいそうですねとしか言いようがない。
あと PHPだから安全、みたいな事を言うのは必ずしも正しくないし、有害なのでやめれ。
そんな事だれも言ってない。
というお話じゃねえの。PHPに限らず、初心者が公開するのはまずい。
未知の脅威って何だ？ インジェクション対策とセキュリティアップデートくらいなら少し覚えればできるでしょ。
そもそも何かを作り上げることができる人というのは非常に少ない希少種なのに、
そこに入ろうとする前途ある人達のモチベーションを使用言語がどうこうと、
挫こうとするのはなんか憤りを感じるよ。
PHPというツールを批判しただけなのに、なんでそういう誤読になるのか。誰も挫こうとはしてないでしょ。一部の初心者の人たちが勝手に被害的になってるだけ。
同意だよ。
初心者が本当に注意しなければいけないのは、スクリプトの脆弱性よりもサーバーのセキュリティ。
PHPなら大抵どこのレンタルサーバーも利用可能なので殆ど問題がない。
なにがいいって現段階においてはPHPは非常に多くの人に使われている。
だからもし見当違いなことをやっていたら注意してくれる人がいっぱいいる。
そして何よりも大きいのはサーバー運営業者などがノウハウを吸収しているということ。
PHPでシステムコマンドなんかは大体止められているしRFIなんかの攻撃に対しても不正なファイルが埋め込まれたりすたら通報してくれるところもある。
現段階のRubyでそれができるだろうか？
大手のレンタルサーバーでさえまだ設定があやふや。
そのままじゃ動かなかったりしている。
じゃぁ自前サーバーならいけるのかというと、正直初心者には無理なんじゃないの？
Mongrelあたりを入れて、あれ、これメモリ漏れてねぇ？とかそういう心配をしたり、24時間監視できるわけがない。
まだ「いいえ」なんじゃないの？
Rubyをちゃんとできる人や教えられる人はまだ少なすぎる。
PHPをぐだぐだ言うひとはちゃんとできるひとなのかな？
どうなのよ？
まあ異論はあるかもしれないが。。
あと、こっちは、一般的に同意をえられるとおもうんだけど、
スクリプトが垂れ流す脆弱性よりもroot権限のっとられたマシンの方が怖くね？
んでもって、遥かに有害だよね。
そんなに言うならSQLインジェクションの穴のひとつでも見つけて報告してごらんよ。
SQLインジェクションなんて、DBに接続ができるようなレベルになれば最近のマニュアル本には当たり前に書いてあるじゃない。しかもこれは何もPHPに限った話しじゃないじゃない。
穴なんて時間の経過とともに増えるんだから、メンテナンスされてないサービスのほうが怖いわけですよ。
ローカル言語やサーバー使ってそのままになってしまうほうが最悪なんじゃないかな。
もし、素人がぐだぐだにつくったPHPサービスとかで問題があるとすれば・・・
・SQLインジェクションで中の情報が漏れる（そんなサービスに漏れて大切な情報登録するなよ）
・メール送信系でヘッダー偽装でスパムの踏み台にされる（これは意外と多いかもしれないね）
・クローラーが他のサーバに負荷をかけまくる
まあどれもPHP”だから”というわけでもないよね。
97年頃にはperlだって掲示板やアップローダーだって穴だらけだったじゃない。
coderedがでるまでiisで建ってたサーバーだって山ほどあった。
そのころにはSQLインジェクションに対応していないサイトは本当に簡単に見つけられた。
初心者は主流からはいるのがいろんな意味でみんなのためじゃない。
今の主流はphpということでいいんじゃないの？
PHPは発展期
RonRは成長期（すくなくともあと1年ぐらいは）
perlは爛熟期
あとは・・・
pythonからColdFusionのにおいしてない・・・？
あと、なんかLLってあったっけ？
curlがなんかいまさらだけど脚光をあびるような予感がしている。
ところでさ、
PHPを批判しているような人はPHP6の仕様とかちゃんとフォローしてるのかね？
そもそも何かを作り上げることができる人というのは非常に少ない希少種なのに、
そこに入ろうとする前途ある人達のモチベーションを使用言語がどうこうと、
挫こうとするのはなんか憤りを感じるよ。
Matzみたいな人がそれをやってどうするんだよとか、ちょっと思った。