 
|
はてなキーワード: 抽象とは
２ｃｈは知らないけど、ネットは真実だったら価値のある情報にあふれてるんじゃないの？
もし「東電は１００％減資になる」が真実なら、空売りすればきっと儲かるし、
”実際に”自分と趣味の合う人が書いたライフハック記事なら参考にすると面白いだろう。
楽しめるかどうかだけが重要なものもあるけど、そういうのはたいてい明らかなファンタジーやフィクションで、
グレーゾーンだけどフィクションとしては面白いねっていうタイプは、少数に見えるんだけど。
あ、ひょっとして、アフィリエイトやりたいならどんどん嘘を書けって言いたいの？
そりゃ勝手にすればいいけど、ネット民ほとんどアフィリとかやってるって前提なの？
もうすこし抽象度をさげて、わかるように例をだしてもらえるとうれしい。
http://anond.hatelabo.jp/20120130150137
元増田です。友人のAさんにおもしろい指摘を受けました。
元増田 「えっ」
友人A 「えっ」
元増田 「えっ」
友人A 「えっ」
なるほど！！！
それでは、問題の画像はあくまでミッキーの着ぐるみを描いたものであることが文脈上明らかであるとして考えてみます。殺害表現でないとすると、名誉声望保持権を主張するのは無理筋に思えます。すると、同一性保持権侵害の線で押してくるのではないでしょうか。
（同一性保持権）
第20条
著作者は、その著作物及びその題号の同一性を保持する権利を有し、その意に反してこれらの変更、切除その他の改変を受けないものとする。
同一性保持権侵害を構成するには、その行為が著作者の『意に反して』いる必要があります。ミッキー(の映画(の原画))の著作者は当然ウォルト・ディズニーだと思いがちですが、実はこの点はずいぶんと争点になっていて、正直なところ「結局誰が著作者なのかよくわからない」んですよね。ウォルト・ディズニーは当然ながら、ウォルトの盟友アブ・アイワークスあるいは二人の共作、はたまた二人の作り上げたディズニー社の団体名義だとする説もあります。
しかし、彼らの意向は明らかです。彼らは口を揃えてこう言ってきました(たぶん)。
『中の人などいない！』
誰が著作者であるにせよ、中の人など決していないんだ、ディズニーランドに行くと笑顔で迎えてくれる彼はあくまでミッキーという生き物であって着ぐるみではないのだ。そういう世界を彼らが作り上げてきたことは明白です。「中の人などいない」ことが、ミッキーマウスという著作物を構成する重要なアイデンティティである。だから絶対に首なんか飛ばない。これが主張として認められれば、ミッキーマウスの着ぐるみの頭を吹っ飛ばすという表現は同一性保持権の侵害となるかもしれません。
でも、どうでしょうね。
まず、視覚的に表される「絵柄」ではない抽象的な要素については著作権が認められないという判例が多くあります。「中の人などいない」はこれに該当する可能性が高そうです。また、着ぐるみを作って売ったならともかく、着ぐるみのイラストを描いてそのイラストの頭を吹っ飛ばしたわけですからね。ミッキーマウスの著作権は既に切れているとすれば無償で着ぐるみを作ったり絵を描いたりすることは問題ないですし、あとぶっちゃけ、彼らが何と言おうと、ディズニーランドにいるミッキーが着ぐるみであることは悲しくも事実なのですから…。
この辺、本職さんの本気の弁論をぜひ聞いてみたいところです。
というわけで、あれは着ぐるみの頭が吹っ飛んだだけだよ！と主張してみるだけで、なんとも馬鹿馬鹿しいメルヘンな問題になることが判明しました。こんなにメルヘンな裁判はそりゃあ是非とも見てみたいわけですが(きっと世界中が大注目するでしょう)、怒りのメールを送ってきたのがディズニー社であるにせよディズニーファンであるにせよ、恐らくはあの画像を「ミッキーの頭を刎ねて殺害している場面」と受け取ってのことだと思います。とりあえず落ち着いていただく＆名誉声望保持権侵害の疑いを回避するためには、首が飛ぶ前後の文脈をきちんと公開した上で、「あれは着ぐるみなんだよ」と説明するとおもしろいよいのではないでしょうか。
添削：
「全ての国民を代表する国会議員の皆様。→選挙で選んだのはyoutubeの君であって今の君ではない。
志を立てた初心に立ち返ろうではありませんか。→戻ってねーし。ほんとに戻るの？！
困難な課題を先送りしようとする誘惑に負けてはなりません。→じゃあ天下り改革よろしく！
次の選挙のことだけを考えるのではなく、→これは少しは考えた方がいいよ。
次の世代のことを考え抜くのが『政治家』です。→こんなことしたらまた若者選挙いかなくなるやんけ。
「政治を変えましょう。→確かに変わったね。
苦難を乗り越えようとする国民に力を与え→君では無理だ。全国民脱力乙。
この国の未来を切り拓くために、今こそ『大きな政治』を、『決断する政治』を、共に成し遂げようではありませんか。→抽象的すぎ。
日本の将来は、私たち政治家の良心にかかっているのです。→えーーーーーーーーーーーー！！
いつも抽象度が高くて不満が残る作者だが不満があるけどこれはかなり実用的
フォークの歯はなぜ四本になったか 実用品の進化論 ペトロスキーシリーズ面白すぎ
ヨーロッパ史における戦争 (中公文庫) - マイケル ハワード おもしろすぎワロタ
有事対応コミュニケーション力 (生きる技術！叢書) - 著者陣が嫌いな人ばっかだけどタイトルが魅力
ためらいのリアル医療倫理 ～命の価値は等しいか？ - 岩田 健太郎 -内田樹押しなのがやだけど魅力
かかわり方のまなび方 - 西村佳哲
自分をいかして生きる (ちくま文庫) - 西村 佳哲 最近はまってる西村先生シリーズ
クルセイダーキングス デウス ウルト【完全日本語版】 むずい
変われる人 8000人のキーパーソンと会食してわかったこと - 鮒谷周史;
あなたは、なぜ「自分に似た人」を探すのか――崩壊する「大衆」と台頭する「鏡衆」
文明論之概略を読む 上 (岩波新書 黄版 325) - 丸山 真男 立ち読み一覧
資本主義と自由 (日経BPクラシックス) - ミルトン・フリードマン
「新訳」乱気流時代の経営 (ドラッカー選書) - P・F. ドラッカー
新訳 見えざる革命―年金が経済を支配する (ドラッカー選書)
・ 登場人物がやたら多い。
１ページか、二ページそこらで、登場人物がやたら出てくる。本人の中ではしっかりとキャラクターが浮かんでいるのであるが、いざ書きだすとなかなか先に進まない。他人に読ませても「キャラクターの区別がつかない」とか言われる。他人をお話の中にすんなり引き入れるには、多くても主要キャラクターは三人か四人がベストでしょ。
・読み始めて、しばらくしても何についての話なのかよくわからない。
いきなり長編に取り掛かろうとする小説家志望にありがちなパターンである。ずーっと読んでいってもなんだかよく分からない主人公の日常が書かれてあるだけで、いつまでたっても事件が起きないのだ。セントラルクエスチョン（主人公は○○できるのか？）を提示するのが遅すぎる。遅くても１０ページまでには何の話なのか提示しないと、読む方はあきてしまう可能性があるのだ。
・登場人物が画一的すぎる
女子高生が出てきたら女子高生の口調、オタクはオタクの口調や行動、ヤンキーはヤンキー、校長が出てきたら校長、婆が出てきたら婆、どれもこれも画一的で、その個人特有の人物造形ができていないのだ。女子高生だったらこんなことはしないだろうとか、ヤンキーはこんなこと言わないだろうかとか考えず、こいつ自身はどう動くかを考えるべき。
主人公が不安だと思ったときに、そのまま言葉で私は不安だと表現するのは簡単。
そうじゃなく描写で表すほうがいい。不安なら、「私の進む先に暗く淀んだ雲が漂っていた」これだけでいい。
・敵の底が浅い
これは、ダメな映画、小説、漫画すべてに言えるが、敵または悪役の底が浅すぎる。みんな似たり寄ったり、同じような口調や行動でありきたりこの上ない。書き手が主人公ばっかりに気持ちが入っていて、陰と陽の配分がなされていないのだ（不思議と悪役の存在感が薄い小説は、主人公も同じく薄いことが多い）
悪役を描くときは、どうせなら主人公より悪役の方に肩入れしてしまうくらい入念に丹精込めて造型しないと、濃密な戦いは生まれないぞ。主人公以上に、なにか独特の倫理観や、哲学を持ってないと魅力は出てこない。<リンク:共犯者 (新潮クライムファイル)>共犯者の関根元を見習ってくれ。
・退屈な生活をおくる主人公のもとに、都合良く謎の美少女が現れる。
導入で、ここまでうんざりさせられる展開は他にない。冒頭に退屈した主人公の日常が延々と描かれ、突如としてその生活に舞い降りた謎の美少女。これがラブストーリーとかになったりしたらもう最悪…。導入としてはすごくわかりやすくて、お話も運びやすいのはわかるがもう一つ何かひとひねりちょうだい！
自分の中に溜まった抽象的な[何か」を表現しました、と言う小説はたいがい、つまらない。こういう小説は冒頭にかならず自意識を垂れ流したような文章が長々と続き、ちょっと書いている本人が陶酔している。こういうのを描くのは、玄人向けというか、並外れた文章表現と客観性がないとなかなかうまくいかないのよ。最近芥川賞とった「きことわ」ぐらいのレベルなら別だけど。
なんかさらーっとしてて、自然とかそういう情景描写ばっかりの小説ってあるよね。たぶん自分の中では美しい情景が思い描けてると思うんだよ。でも他人ってそんなにあなたが感動したことに共感はしてくれないんだよ。よくありがちなのが自然と人間の死を対比させているパターンね。
・文章もテーマも立派なんだけど、全体的に大したことが起こらない、地味。
こういう小説が一番多い。文章もプロ並み、テーマも素晴らしい、でも地味なんだよってやつ。こういう人はとことん地味な話を書くべか、または自分が普段全く読まないような超エンタメ小説や劇薬小説などを買いあさって読んで、一度頭をフルチェンジしてみるのが一番ベストである。
・文章もテーマも立派だし、起こっていることもまぁまぁなんだけど、モチーフがありきたりで既視感がある。
そこらへんに転がってるような話だけじゃ駄目なんだよな。
海外の古い短編なんか読むと、こんなんでいいの！？って思うくらいシンプルなのもあるけど。それは昔の時代だから通用しただけのことであって、今の時代は「ひねり」をどんどん入れて、読者の意表をつかないと、すぐにあきられてしまう。じゃあ二転三転すればいいのかっていうとそういうわけでもないんだけど、読者を驚かせてやろうってぐらいのサービス精神がほしい。
なんつーか、世の中、数字とか数式が出てくるとそれを絶対普遍の真理みたいに捉える奴が多すぎる。
畏怖なのかなんなのかわからんが、馬鹿ほど数式や数字は絶対正しいと、(数字的な)ルールありきで話をし出す。
純粋数学がなんでああいう構造になってるのか、とかいう話を除いて、本来数学なんつーもんは人間の感覚を
なんでそんなことしたかっていうと、それが必要だったからだよ。もの作ったり社会を作ったりするのに。
ルールなんて知らない子供も感覚は持ってるわけ。掛け算が可換だとかその程度のことは、感覚に訴えて理解させればいいんだよ。
交換法則なんつー抽象は必要ねーし、割り算の（小学校的な）ルールも必要ねえ。
人間の脳の認知能力をナメててクソしょうもねえマニュアル思考で教育する馬鹿が自分の仕事を確保するためだけに無駄に物事を複雑化して子供の可能性を潰す。
抽象的なたとえ過ぎるかもしれないが、たいていの場合、下の表のBかCのあたることが多いと思う。
| 能力あり | 能力なし | |
|---|---|---|
| 財あり | A | B |
| 財なし | C | D |
どうにもしようがなさそうな2代目や3代目はBだろうし、頭角を現した番頭さんはCに属する。
Bの視点から見るとCは目障りだし、Cの視点から見てもBは目障りだ。
Bにしてみれば、Cの立場の人の頭を何とか抑えたいし、Cにしてみれば、Bの鼻を明かしたい。
BとCの立場が入れ替わるなんて革命的なことはめったに起きないのだから、それぞれ持って生まれた能力や境遇に感謝しながら生きるしかないはずだ。
この与えられたものの使い方を誤るとBの財もCの能力も目減りしていく。
楽勝な人生に見えるAであっても、大変そうなDであっても、持って生まれた能力や境遇を大切にして、他者のために使わないとあまりうまくいかないと思われる。
もちろんそれをただお金に換金するのではなく、それがだれかのために役立つことがポイントになる。
隣の芝が青く見えたり、イラっときたときは、持って生まれた境遇や能力に感謝することを思い出してみよう。
そんじゃーね。
//ダイアログクラスにメンバ変数を定義 std::auto_ptr<CBitmap> m_pbmp; //bitmapを設定するメンバ関数 void C*****Dlg::Set*****Bitmap() { CDC* pDC = GetDC(); CDC memdc; memdc.CreateCompatibleDC(pDC); m_pbmp.reset(new CBitmap()); CBitmap&amp; bmp = *m_pbmp; bmp.CreateCompatibleBitmap(pDC, width, height); CBitmap* old = memdc.SelectObject(&amp;bmp); memdc.FillSolidRect(0,0,width,height, color); memdc.SelectObject(old); ((CStatic*)GetDlgItem(IDC_STAIC_*********))->SetBitmap(bmp); }
スクリーンと同じデバイスコンテキストとビットマップを作成し単色で描画している。描画し終わった後のSelectObjectを忘れてはいけない。
CStatic::SetBitmapに渡した後も実際に描画されるまでCBitmapの寿命を保証しなければならない。
そのためメンバ変数にCBitmapを持たせるがCBitmapが再利用を考慮していないという驚くべき仕様なので仕方なくauto_ptrでラップしている。
いい加減MFC滅びてくれないかな。抽象度が低すぎる。こんな記事自分のブログに書きたくないよ。
さらにVisualStudio 2005のauto_ptrのバグを見つけた operator = にポインタを渡すとおかしくなる。これは本来コンパイルエラーになるべきで代わりにresetメンバ関数を使用するべきだ。
修正するには<memory>ヘッダのauto_ptr_refのコンストラクタのひとつ上の行(642行目)に private: template<class T> friend class auto_ptr; を挿入する。
第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 練習問題
「あの企業の入社試験に、あのひとが答えたなら」から一部改変して引用。
1：聞き手が「こういうことをやっているのか、面白そうだからあって話を聞いてみよう」と思わせられる要素を中に入れておく
2：小論文は全部、評論ではなく自己PRのためにやっている。学生は評論家ではない。抽象的な問題には、「私にとっての○○」という枠を意識することで、オリジナルな答えを導ける。
3：学生の文章は一文一文が長くなりがちで、読み返さないとわからないことが多い。ワンセンテンスを短くしてテンポよく受け取れるように。
4：抽象的で小難しい言葉は使わない。あなた自身と周りの人みんながわかるような言葉を使う。
5：「会いたいな」という発想か、「ここが聞きたいな」と思わせる体験を入れておく（小論文内で語りきろうとしない）。そうすると、面接の時に、自分の売りとなるキラーコンテンツを引っ張り出してもらえる。
6：企業は字で人柄を見る。「手書きだからこそ出来るPR方法がたくさんある」ことを意識しておく。(手書き履歴書の問題などで、条件反射的に企業バッシングなどをしてしまう思考停止気味の人は注意）
7：自己ＰＲの三原則は「ならではの話」「だからの話」「立体的な話」。これらを意識的に盛り込むこと。９割の学生はこれすら出来てない。
（「ならでは」＝自分自身が持っている話。絶対に自分しか経験していないようなこと。
「だから」 ＝こんなことをやってきたから今のこれにつながっている、という話。ビフォーアフターを伝える。
ただし、ありきたりなバイト体験などは「ならでは」を満たしてない。これだけを意識するのはNG.
「立体的に」＝具体的に見えるような話。聞き手が共感できるレベルまで話を浮かび上がらせること）
8：主張は言葉ではなくて内容でするもの。「私には忍耐力があります」と伝えたい場合、言葉でそのまま書くのはバカ。
その忍耐力を事実で示して、「あ、こいつ忍耐力あるな」と聞き手に思わせる。
9：問題を通じて、独自性と自己紹介の両方を表現する。独自性を少し入れて、オリジナリティもアピールして、
最後にまとめとして自己紹介を重ねるという形が基本。最初に自己紹介をしても何も伝わらない。
10：自分の強み弱みは、一歩引いた広い視点で考える。自分のひとりよがりではダメで、
聞き手が興味をもつような内容に。
・・・なんというか、味気ないなー。
この本に載ってる「実例」はすごいものばかりなんだけれど、
達人の技を箇条書きにしてまとめるとこんなに味気がなくてつまらないものになるのか、と驚く。
可能なら、こういう箇条書きとかまとめの本を読むんじゃなくて、達人の技を直接見るのが良いと思う。
http://anond.hatelabo.jp/20111202212226
全ての人に友達がいて当然、というのは正しくない。
私は友達は作れない種類の人間だし、そもそも私の心は友達を欲していない。
みんな友達がいるのに、自分だけ出来ないのは辛いなんて考える前に、自分は友達を作れる種類の人間なのか？自分は友達を作る資格があるのか？自分は友達を欲しているのか？一度立ち止まって考えなおすと、人生は楽になる。
友達の話だけでなく。
元増田です。これについてはちょっと考えてみます。正直少し心当たりもありますが、大事な事なのですっと受け止めるのはしんどいです。
ところで、逆に伺いたいのですが、いわゆる一般的なところに興味がモテなかったというあなたの中に
「あれがしたい、これがしたい」というのはありますか？
それはいつぐらいに自覚はありましたか？その際のきっかけなどはありましたか？
私もこうならないようにしたいですね。
今はちょっとでもエネルギーが欲しくて、とりあえず親への怒りに頼っている感じですが、
ただ、次にどこに移動していけばいいのかが分からないのです。
他の人に「サークル頑張ってみる」って書きましたけれど、正直全然興味無いです。
（そういう意味で上の指摘は合ってるのかもしれません）
興味なくても何か無理矢理にでもやっているうちに意欲が出てくるのか、
やはり自分を掘り下げて、少しでもヤリたいものを自覚してから行動すべきなのか。
私とあなたは違う、とさんざん突き放すような書きかたをしておきながら厚かましいですが、
こういう抽象的なことにばかり欲しい欲しいと思ってしまって、具体的な友達とかに興味が持てない状態は
なんだかいくら水を飲んでも乾きが消えないみたいな感じで苦しいです。
朝、出社をしてメールチェックを行い、それから１時間以内で全く別の内容で4人の人に怒られた。
一人になった時、苦笑いした。
その中で、ある程度自分が切磋琢磨をして前向きになれる内容が何かあれば何とかなる気がしたのだが、バッサリ切られている様な感覚が否めない。
今日は偶然、手が空いていたので朝の状態では持ち作業はゼロだったので、それでもこなくそと、怒られた人に「何か作業ないですか？」と聞きに行ったら
大変疲れた顔をされて「ない」と答えてくれた。「コイツには頼めない」その顔が語っていた。
申し訳ない気持ちとか恥ずかしい気持ちとか、色んな感情がぐちゃぐちゃだった。
心底「こんな気持ちにさせて、すいません。」って言いたい。
無理に笑顔を作って「何かあったら声かけて下さい」と言うのがやっとだった。
自席に戻って、何とか仕事を作り出そうと今までの作業に抜けがないか探して粗がかなり見つかったので、それの修正をしていた。
自席は窓際で今日は寒く、自販機でホットティーを買って自席で暖まりながら飲んでいたら横の人から、物凄い剣幕で
「匂いがするものを自席に持ってくるな。非常識だ。」と怒られ土下座をする位の勢いで謝り、休憩室に逃げた。
休憩室で窓の景色を眺めながら、自分の情けなさを感じつつ自己改善案を考えるが、とにかく行動や作業に注意を払って頑張っていくしかない。
もうこんな生活が３ヶ月以上続いてる。正直、会社をそろそろ辞めたい。
いるべきじゃないと思ったりする。でも何も自己改善をせずに辞めるのは逃げている気がしてたまらない。
情けない。
自分が精神的に折れるか、職場の皆さんの堪忍袋の緒が切れるか。
さぁ、どっちだ。
情けない人間で、本当にすいません。本当にすいません。
…そして風邪を引いた。でも休めない。
色んな考え方の人がいる以上、話し方を聴き手に対して変える必要がある。
哲学科の奴にいきなり経済の素晴らしさを語ったり、電子工学科のやつにカントが～とかいきなり自分のことばで語りだしたって、何が伝わるだろう。
人間は「ある程度理解が得られるであろう内容/話し方」で話すものだ。
だから、読み手に対して自在に変化を遂げ、否定的に解釈されにくい、抽象的な言葉が生き残りやすい。
人はよくわからないと思ってるものに対しては、お互い意見を対立させようとは思わないものだと僕は思っている。
具体的な言葉を用いると、どうしても現実的な様々な解釈と意見が入り混じる。
具体的な話であれば会話がしやすいか？細かいニュアンスの表現が必要とされるがために、それは逆に難しいのだ。
文字だけで、それまで何のコミュニケーションもとらず前提確認も取れず、細かい話をするのは非常に困難だ。
とはいっても、ネットでは主に言葉でコミュニケーションを取らねばならない。
しかし、どんな言葉を使っても（もちろんこの日記も例外にはなれない。）何かしらの否定はされ得る。
僕にとって一番大事な発言者は、ぼくの話をちゃんと聞いて、反応してくれる友達だ。
その信頼感は、ネットを使ってでも、直接会ってでも、電話でも変わらない。
そんなインターネット（と現実）で、からまれたくないし、全力で逃げたいと思ってる３人の馬鹿を挙げる。
発言者による発言の優先度が、僕にとって一番低いのが彼らと言っても過言ではない。
彼らから真っ先に逃げる為に、一度言葉にして確認することにした。
・個人の日記
しかしここで犯罪告白をする人は、新宿とかのでかい公園で犯罪を何千回も叫ぶ（コピペ、ＲＴされる）ようなことをしてるんだから警察に引っ張られてもしょうがない。
やましいことするなら隠れてしないと捕まるのは当たり前。そこくらい知恵使えと言いたい。
主題違いに突っ込む馬鹿。
十分な議論ができる環境ではない（コメント欄でどれだけの納得が得られようか。）のにも関わらず、１から議論しようとする人。
offでお茶会でも開け、と言いたい。
・ブログ
「間違ってるやつは正さないといけない」「間違ってるやつが正さないのは傲慢だ」「間違ってるやつは攻撃していい」というロジックを君が使うなら、「そう言う君が間違ってるから君を攻撃していい」「そういう君が間違ってるのに直さない、傲慢だ」「そういう君は（略）攻撃していい」と僕が言うことも正しい。
そんなループに見ず知らずの名無しさんとラブラブランデヴーしたくないから、僕は全速力で逃げる。できる限り自由にやりつつ、できる限り君と関わらないような人間になる。
僕はこの人には何も言いたくない。目視し次第とにかく逃げる。
相手の知識を、括として無視し去ってしまう場合に、無知が絶対に強い。」
という一文がある。
文脈はともかく（そんなではいけないのだが、）僕はこれは本当にそうだと思っている。
ぶつかったら負け、の戦いからは、逃げることが負けないことなのだ。
僕はそいつと戦わないから、勝たないが、負けない。戦いたくもない。
いやいや、過小評価できない（付き合えば十分に面倒くさいことになる）から逃げるのだ。
僕にとって、勝つよりも、負けないことの方が重要だ。
僕は、類は友を呼ぶという言葉も信じているから、出来る限り自分自身が３人の馬鹿にならないようにしたいと思う。
僕にできるのは、僕を変えることだけだ。
これが僕の最大限だ。
”「弱者」ってのはな、時の「強者」に出汁にされて煽られて、騒動が一段落したら解決してないのに「いないことにされた」連中”
っていうのがTPPのどの層に当てはまるのかさっぱり分からない。全く抽象的な定義を使って議論はできないよ。
”TPPだって、そりゃ参加が決定するまでは「日本のためになる」って言うだろうさ。言うのは「強者」であって、「弱者」じゃないもの。”
という発言を察するに、あなたが言いたいのはTPPによって被害を受ける人間が弱者で、利益を受ける人間が強者ってこと？
それだったら先にあげてた人たちって本当に弱者？ 例えば自動車部品を作ってる工場で働いている派遣労働者は今回のTPPで自動車部品の関税（ベトナムとかそれなりに高い）が下がるから、国内生産を維持できて、働き続けられるかもしれない。これは利益を受けてるんじゃない？じゃあ派遣労働者は強者？
農業関係者はあなたの定義によると弱者になるんだろうけど、本当にそう？私は関税でずっと保護されてきた人たちが弱者だとは思えないな。
むしろ関税によって農産品の価格を高く吊上げさせて、消費者に高い価格を押し付けてきた彼らは強者だと思う。
あなたの直観的に思う強弱の層と、TPPによって利益を受ける層っていうのは大きく異なってる。
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。
日頃からぼんやりと考えていることを、週末の夜の妙なテンションのままに書き連ねてみる。
曲りなりに仕事をしながら、プライベートも適度に楽しみながら、将来のビジョンなんていうのも描きながら、これまで30年ちょい生きてきている。
でまあ、そんぐらい生きてたら大概の人は、勉強してるのに成績上がんねーなーとか、いつも仕事がうまくいかないなーとか、なかなか出世できる気がしないなーとか、同僚・友人・恋人と最近うまくいかないなーとか、とりあえず何かしら苦しくなる時期が来る。
だからこそ成功した経営者が書いた仕事術の本がよく売れたりするし、ライフハックブログはいつも多くのブクマを集めるし、雑誌の悩み相談や発言小町も人気だったりする。
で、大体ああいうのに載ってるのって「モチベーションを高めろ」とか「今自分がどうしたいかを見つめ直せ」とか「一人で悩むな、どんどん人に頼れ」とか「卑屈になるな、自信を持て」とか、言い方に違いこそあれ大体そういう意味の文句なわけじゃん。
もっと抽象的な言い方でまとめると「自分の状況を変えられるのはいつも自分だ、全ては自分次第だ」っていうことだよね、要は。
別に本だのブログだのでなくても、仕事場の上司だとか悩みを聴いてくれる友達だとかがそういう感じのこと言ってくれることもある。
いや、良いアドバイスだとは思うんだよ。俺は本こそ買わないけど、そういう文句を読んだり聞いたりして意識を高めたりすることあるし、事実その結果状況が好転したこともある。他にもそういう人が多いと思う。
でもさ。
結局「自分次第」って所詮は強い者の論理じゃないかなって思うんだ。
みんながみんな、そんなふうにしてうまくいくわけじゃないよなーって。
俺の周囲には、上に書いたようなことに悩んだ末、心を病んでしまったような人が何人かいる。
中にはそのせいで出社拒否になったり引きこもりになったり、下手すりゃ自分で自分の命を絶とうとすることすらありうる。
彼らの話を聴いていると、ああきっとこの人はどんなに苦しくても「自分次第」でどうにかできるはず、どうにかしようと思いつめるあまり、無理をした挙句限界がきちゃったんだなって思う。
普通の人は、ある程度まで自分に鞭打ってやれるし、あるいは無理が来る前に自主的に休んだり、気持ちを切り替えるために別の事したり、人に頼ったりできるんだろう。
でも彼らはその「普通の人」ができることができなかったんだろう。多分甘えとか勉強不足とかそういう理由でできないんじゃなくて、きっと他の人なら抱える必要のないものまで全部抱えてしまい、結果その重みで潰れてしまってるんだ。
彼らの思いや主義主張は「普通の人」とは決定的に異なっていて、だからこそ「普通の人」を基準に動いている世の中はすごく生きづらいんだろう。
だからそんな世の中でモチベーションを高めろって言われても無理だし、自分が理解されないのが分かっているのに人に頼ったりできないし、当然そんな自分に自信を持てと言われても難しい。
みんなすごく真面目で優しくて、自分以外の人間のこともちゃんと考えることができる人だなー、ってのが話を聞いてて分かるんだよ。
人の痛みや苦悩にすごく敏感だし、人を傷つけるような皮肉や嘲笑なんて絶対にしないし、そんな彼らを見ていると、暴言失言が多い自分がとても恥ずかしくなる。
他の人ならそこまで行く前に明らかに危険と分かるはずの精神的負荷なのに、彼らはなかなか気づかない。それこそ潰れてしまうまでね。
だからさ。
そういう人のことは、やっぱ誰かが気づいてあげなくちゃダメなんだよ。全部自分次第とか言って本人に任せるんじゃなくて。
経営者の本や人気ライフハックブログに書いてあること、上司や先輩の体験談だって万能じゃない。あれはあくまでできる人がすればいいことだ。全員に同じように要求するものじゃない。
「自分の状況を変えられるのはいつも自分だ、全ては自分次第だ」とかそういう「普通の人」の論理の犠牲になる人がいるかもしれないんだ。
上にも書いたように、彼らはこの世の中に生きづらさを感じている。それを少しでも和らげられるのは本人の努力次第とかそういうんじゃなくて、周りの人がちゃんと逃げ道を作ってあげることしかないんじゃないかと思うんだよ。
みんな条件は一緒だとか、平等が一番無難だとか、競争することで強くなれるとか、そんなのクソ食らえだ。そんな正論がちっとも役に立たない場面だってあるんだ。
今、俺はまだ大きなチームをまとめるとかそういうポジションではないけど、もし将来そういう地位についた場合、メンバーの一人一人のことをちゃんと見てあげられるリーダーでいたいし、また上に書いたような弱っているメンバーがいたら、正論なんか放り出して他のメンバーがすぐさま逃げ道を確保してあげられるようなチームを作りたいって、常日頃から思ってる。
ただ、正直俺も強い者の論理でここまで来ているという自覚があるし、いざその場面になったら本当に今考えているようなことができるか分からない。自信がない。
でもやっぱり、マイノリティを弾き出すようなコミュニティだけは絶対に作りたくないなー。
まあそんな先のこと考える暇があったら、俺は今俺にできることをやって、救える人を救おう。あーあ。
話が拡散しすぎてたたみきる途中で飽きた。もうちょいテーマ絞りなおしてから書き直します。
久々にこういう「わかりやすい小物」の老害を見て興奮しちゃったんだけど、元記事も消えちゃったみたいでテンションが上がらなかった。
http://b.hatena.ne.jp/entry/togetter.com/li/210527
今テキトウに考えただけ。
多分はてなの皆さんは私よりこの問題について深く考えていらっしゃると思います。
私の意見に対する批判というよりは、老害に対する皆様方の意見を伺いたいと思います。
ここで述べるのはネットにおける「わかりやすい老害」の話です。
年だけは喰ってるから偉くなったのだと勘違いして若者に対してわかったような口を聞くアレのことです。
能力も権力を持ち、既得権益をまもるために政治力を駆使している真の老害についてはよくわかりません。
「懐古主義（建設的要素が少なく、ただ過去＝自分を賛美するだけにとどまる」
「世代の分離を強調する（若者を突然変異のように扱い、原因も若者に押し付ける」
「ワナビー（自らの現状が不遇であることを正当化するためにただ現状を否定したいだけ」
などの特徴があると思います。
ちなみに老害を設定するということは「若害」もあると思います。「世代の分離」については特に。
基本的に老害という言葉がネットで人気なのは、基本的にその反対を意識しない馬鹿が多いからでしょう。
リアルにおいては老害の方が「重要度（影響力）が大きい」ために問題になりますが、
ネットのように、どちらにしろ現実に影響を及ぼさないことを前提とした純粋な議論においては「若害」も吟味されるべきだと思います。
一般に老害の意見は、それを下支えするロジックがおかしいため滑稽に見えるわけですが、
おそらく自分のロジックを点検するという習慣がない。おそらくフィードバックを受ける習慣がないのだと思います。
それらしいことを言って、言いっ放しで満足してしまう。
老害と呼ばれるのは、一般にこういう傾向を持つのが中年以降の男性に多いからだと思います。
自分より立場の弱いものに、具体的には部下や家族に一方的に自分の意見を押し付けることができる。
あるいは同じレベルの仲間内で何度も同じ議論を繰り返している内に、無条件で自らの意見が受け入れられる錯覚をしてしまう。
などの積み重ねがあり、その「内輪感覺」「支配者の感覺」をフラットなネットに持ち込むことで裸の王様ぶりが浮き出るということなのだと思います。
１：自分の体験一点主義
２：主張の背景が薄い
５：人の意見を否定する際の理由が安易なレッテルや抽象的な表現になる。
（たとえば上の「２」とか。自分で書いてても批判になってないと思う。
曖昧な表現やよく考えられていない安易なレッテルはすぐに循環論法に陥る。
うちの課長が好む老害ロジックは「若者は自信がない」であるが、
若者から「安心できる環境ではない」「頼れる人がない」というと
それは「キミタチはプライドが高くて他人に弱みを晒さないだけ」といい、
「プライドが高いのではなく、そういうプロトコルがない」というと
「それはキミタチが自信がないからだ」となる。
実際はこんな単純ではないが、
自分が主張した理由に対する反論を５回繰り返す間に循環が起きるロジックはたいてい老害による偏見と考えて良い。）
６：安易に箇条書きでまとめを作ってしまうやつも老害の一歩手前
多分、プロフィール公開がないネットにおいては２０代の私が書いたことでも「老害」に当てはまる可能性は高い。
このセリフ使う奴はダメだと言われるけど、本当に「自戒を込めて」
とにかく、肯定でも否定でも、問われているのはその意見ではなくて、その意見を述べるときの自分の底力なのだな、と。