 
|
はてなキーワード: テキストとは
昨年、俺が書いて1200ブクマくらい集めた増田エントリがアフィリエイトサイトに転載されていた。
もちろん、コレ自体はいいんだけど。これまで書いた他の文章もほとんど全部どっかのまとめサイトに転載されてたし。
ところが、今回のサイトどこを探しても転載元を示すリンクも、そもそも転載である旨の表記もない。
親切なはてなーの皆様がブコメやらツイートやらで「無断転載だ」と指摘してくれてはいるけれど。
で、まぁ俺も別に嫌儲な人ってわけじゃないので。個人がまとめブログを作って
ついでにアフィ張ってお小遣い稼ぎするくらいは別にいいと思うんだけどね。
でもさー、life hack japanさん。あなた、サイト５つくらい持ってるよね？
http://lifehack-japan.biz/さんよぉ。これは、まとめサイトを作るのが主目的ってわけじゃねーよな。
カンッペキに営利目的だよなぁ。ニュー速が死んだんで新しいエサ場探してるんですかね？
俺は匿名で書いた以上、別段その文章がどういう風に利用されてもそれほど文句はないんだけどさ。
それでも、自分の書いた文章が自分の預かり知らぬところで公開されてると、何らかの批判が来たときに
俺がそれに応答できないのがまず困る。そして、俺はエントリについたブコメやツイートをニヤニヤ眺めるのが大好きなんだ。
ところが、転載されてることに気づけないとそれも出来ない。今回はたまたま気づいたから良かったけどね。
本ブログやらIDやら晒して暴れてもいいんだけど、それやると俺はここに匿名でアホな記事を書き込むのが
すごくやりにくくなるし、何よりニュー速みたいなアフィ騒動が起きて欲しくもない。俺の本業にも障りが出そうだし。
結局、ネームクレジットをつけたくないから増田で書いてるわけで。
とはいえ、匿名のまま「俺の記事でアフィるな、せめて転載である旨明記しろ」とか叫んでもあんまり意味はないよな。
そういうわけで、転載するならするで最低限のスジ通して欲しいもんだ。
そうすれば、お互い気持ちよく過ごせるし面倒もない。そうは思わないかな。
というか、そろそろネット上の匿名テキストに関する著作権のガイドラインが出来てもいい頃だと思うわ。
転載であることを明記したとしても、ここまで明らかに営利サイトなのが見え見えだと結構イラっとする。
2chの書き捨てならともかく、それなりに手間かけて書いたテキストだからなぁ。
アフィは滅べとまでは言わないが、2chと違って増田はログ消えないわけだしなぁ。
どーなのよこれ結局。
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 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
ライブドアが金払ってるらしいじゃん。
犬
アフィリエイトやってませんよね？ 正直、やりたいと思ったことないですか？
ぶっちゃけ最初はやりたいと思ってましたけど、今はやりたくないです。というかやりません。
犬
それはなぜ？ｗ
僕、人に褒められるのとか好きなんで、ｺﾒﾝﾄ欄だけで十分なんですよｗ
たまにくるメールとかｗ
犬
はいｗ
ライブドアの内情に詳しい人、おちえてー
追記 2009/10/19
Kamekiti
絶対に貼らないといけない広告じゃないのかな
それはありえない。
広告の非表示 FREE PRO ADVANCE PREMIUM 記事下広告 × ○ ○ ○ ブログサイドバーのバナー × × ○ ○ ブログ共通ヘッダーの広告 × × ○ ○ 管理ページの広告 × × ○ ○
確かに、VIPPERな俺は有料ではなくFREEブログで、強制的に広告は表示される。
しかし、
ブログサイドのバナーとはサイドバー下部の POWERED BY livedoor Blog という小さなバナーのこと。
少なくとも
(省略されました・・全てを読むにはここを押してください) をクリックしたときに
わざわざ、Ads by Google というサイドメニューを作って張るデカい広告のことではない！
っていうか、本当は id:kamekiti も気づいてるでしょ？
↓この記事いくらもらったんだろ？
VIPPERな俺 : 位置情報サービス「ロケタッチ」がオープン。色々と捗るぞ。
http://blog.livedoor.jp/news23vip/archives/2836522.html
散々他人を攻撃してきたニュース速報板、最後の攻撃先はニュース速報自分自身でした……
「ニュース速報板」というのは「2ch」内にある一つの掲示板です
ニュースを扱うことになっていますが末尾にプラスのつく「ニュース速報板+」等とは違い1200円程払えば半永久的に一応誰でもスレッドが建てられることになっています
2chまとめブログというのは「2ch」内から何らかのスレッドを選びそこからいくつか書き込まれたレスを抽出してブログ記事にしたものです
ひとまとめに2chまとめブログと言ってもジャンルや特色があり、アニメに特化したブログ、ゲームに特化したブログと様々です
もちろん何を扱っていても基本は「2ch」からの転載で成り立っています
これらのサイトは数年前からありますが年を経る毎にアクセス数は増え大手と言われるサイトでは一日のPVが100万、1ヶ月で1億を超えるサイトもあります
この2chまとめブログですが、その全てが個人によって運営されています
企業が参入してこないのはなぜでしょうか？
理由はコンプライアンス違反の可能性が濃厚だからです、法律的にグレーもしくは真っ黒ということですね
「2ch」に書き込まれた内容にはそのそれぞれに著作権があります - 『平成13年（ワ）第22066号著作権侵害差止等請求事件』
まとめブログはそれを引用の範疇を超えて転載しているので著作権者に訴えられれば著作権侵害となります
これは「2ch」への書き込み時に利用者は著作権移譲の規約に同意させられているからです
電車男騒動の際までは著作権自体は利用者にあったのですが騒動を期に規約が今の形へと変わりました
2chというサイトは元管理人のひろゆきが訴訟対策のためシンガポールにペーパーカンパニーを作るくらいに訴えられることはよくありますが
逆に訴えることはまずないという少しアンダーグラウンドな場所です
著作権侵害というのは親告罪ですので著作権者自身に訴えられるまではセーフです
そんなまとめブログですが当の「2ch」利用者には快く思っていない人も多くいます
特に転載される頻度の高い「ニュース速報板」の利用者は自分たちの書き込みが無断で利用、転載されているにも関わらず
自分たちには1銭の報酬もなく、まとめブログの管理人には（アフィリエイトによって）月数万～数百万の報酬があるというのですから日々鬱憤が溜まっているという状況でした
それが2007年のコピペブログ騒動です、これは結果的に「2ch」利用者の敗北に終わりました
この時「ニュース速報板」利用者の多くがアフィリエイトブログ（2chまとめブログ）への転載を禁止にしろと言いましたが
管理人のひろゆきはそれに応じず代わりに新しい掲示板を「2ch」内に作りました
それが「ニュース速報板（嫌儲）」という転載禁止を謳った掲示板です
それから月日が立ち丁度4年後の2011年12月、一つの騒動が起きました
「シャフト」というアニメ制作会社の公式サイト内に「やらおん」という2chまとめブログが報酬を得ることになるアフィリエイトURLが使われていたというのが事の発端です
これは通常考えられないことですので「ニュース速報板」では大きな騒ぎとなり
これはステルスマーケティングが関係しているのではないか、とまことしやかに囁かれました
それからステマという省略型が使われるようになり「ニュース速報板」全体がその単語で埋め尽くされるまでにあまり時間は掛かりませんでした
この騒動でこれを「ニュース速報板」からアフィリエイトブログ（2chまとめブログ）を排除する好機と考えた利用者は「2ch」運営に「ニュース速報板」のルールを転載禁止に変更するよう嘆願します
しかし却下され、これ以上の運動は何をしても無駄だと悟った「ニュース速報板」利用者は1/9 0:00をもって既にルールとして転載禁止のある「ニュース速報板（嫌儲）」へその多くが移住しました
現在「ニュース速報板」は移住を促す文句とアフィリエイトブログ（2chまとめブログ）への転載を邪魔する文句で埋め尽くされておりまともに機能していません
以上がことのあらましですが一つ一つをもう少し詳しく説明しますと
まず多くの人が誤解しているであろうことに"ステマ連呼"があります
"ステマ連呼"とは主にニュース速報板内でところ構わずステマと連呼しまくることで、色々なバリエーションがありますが基本的には"ステマ"という文字列で構成されています
そしてこの"ステマ"という言葉ですが、これはステルスマーケティングを指す意味もありますが、むしろアフィブログ反対というような意味合いを込めた掛け声という要素が強いといえます
例えば"これはステマ"と言えば、これはアフィブログの利になるだろうと思うのでまともな発言はしないよ、というような意味となります
そのほか耳にしたことは無いかもしれませんが"効いてる、効いてる"、"余程都合が悪いようだな"等が同じ意味合いの文句としてあります
ところでなぜこのような言葉が必要になってくるかというと、匿名掲示板という場所では誰がどのような考えをしているのか分からず
もっと言えば味方に見えた人が敵の装いであるかもしれないということが多々あるからです
アフィブログ反対という同じ気持ちはあるにせよ匿名掲示板上では何かの流れに逆らうというのは非常に難しいことです
ここで効果的な役目を果たしたのが上記の文句でした、巨人ファンも阪神ファンも取り敢えず日本がんばれ！で統一しようというわけです
今回ここまで騒動が大きくなったのは自然発生的にできた"ステマ"という合言葉が原因と功績の大部分を担っているのかもしれません
次に今回の2chでの騒動を殆ど、もしくはまったく知らなかったという人がいるかもしれません
普段なら祭りといわれる程の騒ぎなら大体知っていたはずなのに……と
もしそういう方がいれば、その方は普段2chまとめブログから情報を得ている方だと思います
今回の騒動は云わば反まとめブログ騒動なので当然ながら当事者のまとめブログは取り上げていません
まとめブログの情報も当然ながら編集された情報だということです
そしてまとめブログが極度に嫌われた理由の一つとしてその自己都合的（恣意的）なまとめ方があります
まとめブログというのは閲覧される回数が多いほど収入が増える仕組みとなっています、いわばPV至上主義というわけです
ですからPVが稼げるトピックを好んで取り上げ、時には内容の改竄とも取られかねないまとめ方をすることが多くあります
そうしてできた記事はよりセンセーショナルでコンプレックスを刺激し対立を煽るようなものとなっています
これは普段自分たちがマスゴミと揶揄してはばからない既存の大手マスコミか、責任を伴っていない分それ以上に非道いやりようで、最近は問題になることも少なくありませんでした
もちろん"楽して稼いでいる"という風聞や認識が広まりその部分が妬みを買ったというのも否定できません
しかし間違えてはいけないのはアフィブログ（2chまとめブログ）を嫌っている多くの人はアフィリエイトという仕組み自体を嫌っているわけではないということです
自らが産み出したテキストなどの正統な対価としてアフィリエイト広告を掲載している、例えばアルファブロガーなどに対してはアフィブログ（2chまとめブログ）と同じ非難の言葉が浴びせられることはありません
次にニュース速報板が完全になくなるとどうなるのという疑問ですが
まず一般的な2chまとめブログというものには面白系のニュースをまとめた記事が多くあるかと思います
その少なからぬ編集元がニュース速報板です、つまりこれまでに見てきたそういう記事は減ってしまうかなくなるかもしれません
次に自分の人生を語ってみたというような創作系の記事ですがその多くはVIPといわれる掲示板が編集元となっています
VIPについても現在反アフィ運動が展開されていますのでもし成功すれば、同様に記事は減ってしまうかなくなるかもしれません
その他のアニメ系、ゲーム系などの記事はそれぞれに専門板といわれる掲示板群が編集元となっていますので極端な変化はないかもしれません
ちなみに2ch利用者の中には自分の立てたスレや投稿したレスが大手といわれる2chまとめブログで取り上げられることがうれしいという人もいるようです
特にVIPに立てられ語られる創作系のスレッドではそういったことをモチベーションとしてやっている方がいるのも事実だと思います
映画にもなった「ブラック会社に勤めてるんだが、もう俺は限界かもしれない」などのお話は2chまとめブログがなければあれほどのムーブメントは起きなかったでしょう
2chまとめブログがネット上で影響力を持つことも悪い話ばかりではないのかもしれません
具体的な数字がありませんので全て憶測になるのですが、もしも何かを広めたいときに最もコストパフォーマンスの良い方法は何か？聞かれれば
自信を持ってニュース速報にスレッドを立てることだ答えられるかと思います
ニュース速報板にスレッドを立てる対価は極限まで薄めればタダです、しかし一度立ててしまえば無数にあるまとめブログがあの手この手を使って宣伝してくれることでしょう
もちろん取り上げられやすい話題などはありますが上で述べたような一定の傾向を抑えれば簡単に受けるトピックの作り方ができるともいえます
企業が組織的にニュース速報板でステルスマーケティングを実践しているというような陰謀論じみたことはにわかには信じられませんが
例えば自分が担当しているプロジェクトや商品について簡単に知名度を上げたければ、その個人がニュース速報板を使うということは少し想像力を働かせてみれば十分に考えられることだと思います
一度手を離れた情報がどのような伝わり方をするかが分からないというリスクはあるものの、それに見合うだけのコストパフォーマンスの良さがあるのでないでしょうか
そういった意味でニュース速報板→2chまとめブログのラインはかなりの影響力を持った媒体だったのではないかと思います
これは現在成功しつつあり今後も成功するのか、それとも何かあり失敗に終わるのかまだ予断を許す状況ではありませんが
成功し掛けているという点のみで十分に凄いことであると思います
ニュー速民といっても一つの意志をもった個体ではありませんし、何と言ってもリーダーのような存在がいませんので往々にしてその行動が一つにまとまるということはありません
それが今回は自分たちの住処となる板を移動するという相当難しいと思われる事をやってのけました
当事者でない方にこの難しさを伝えるのは簡単なことではありませんがとにかく凄いことだといえるかと思います
上で記したように"ステマ"という合言葉で反アフィの土壌がかなり固められていたことも大きな理由の一つかもしれません
ちなみにニュー速→嫌儲への移動までには色々と紆余曲折がありました
その多くは真偽不明の疑惑で、例えばニュー速にスレッドを立てている人はアフィリエイト側の人間で金銭を受け取っているであるとか
ニュー速は企業のステルスマーケティングの会場となっており、2ch自体がその業務を請け負っているというようなものまでありました
特に2chの運営自体がアフィブログ側の人間であるというような疑いはある種の絶望を産むこととなり、もう移動しかない……という諦観した行動原理を呼び起こす要因ともなりました
更に詳しい経緯についてですが、正直発端となったアニメ制作会社「シャフト」云々についてはあまり関係がないかもしれません
追記
・amazonアフィリエイトのURLが混入したことについて、「通常考えられないこと」と書いたのはそのURLが元サイト「やらおん」でも一度も使われていなかった、存在しなかったURLである
ということからこのように表現しました、しかし使われていたという情報も見たことがあり真偽は分かりません（←デマ(URLは存在した)らしいです、申し訳ありません）
・このまとめについてはできる限り内輪ネタにならないよう気をつけて書いたつもりですが、それ故細かい経緯、特になぜそこまでアフィブログが心情的な部分で嫌われたのかや
1週間余りの攻防ともいえるような2ch内でやり取りについて記せていないので、より詳しい方にとっては色々と不満があるかと思います
加えて、書いた人間がアフィブログ憎しという側の人間ですので、中立的な立場の方が読んでも不快にならぬよう心理的にかなりのバイアスを自らかけ、アフィブログにも配慮して書こうとした部分があるのも事実です
・なぜ自分たちの住処を移動するまでになったのか少し補足しますと、原因の一つとしていわゆる右翼左翼、嫌韓などの対立が意図的に誘導されたものだったのではないかという疑惑があります
スレッドを立てる人というのは限られていますので、彼等がまとめブログの運営者に近い人物であったり、その彼等が刺激的なタイトルで対立構造を煽っていた、というのはない話ではありませんし
事実として一部のスレ立て人はアフィブログの運営者であることを公言しています、2chは匿名ですからスレ立て以外の通常の書き込みでさえもそうした疑惑に駆られてしまい疑いだすとキリがありません
もちろんそこに証拠があったわけではないのですが、ニュー速に居続け転載され続ける以上その疑念を払拭することはできないので、その心配のない嫌儲に移住したというわけです
・http://anond.hatelabo.jp/20120111184947この方は存じておりません
現在も2chでは反アフィリエイトブログ運動が続いており「ニュース速報板（vip）」などにも飛び火しています
今後どうなるのかは分かりません、「ニュース速報板」は2ch内では規模の大きい板ですが仮に完全消滅したとしても2chまとめブログへの影響は限定的かもしれません
しかし2chの情報を何らかの形でまとめたサイトというのは無数にありますからどこかに変化があるかもしれません
いずれにしても予測の域をでませんので今後の経過を見てほしいを思います
匿名という武器と数の暴力という二つの力で祭りと称して個人の情報を暴いては嬉々としていた、いわばネット上の迷惑な集団の総本山とも言えるようなニュー速の
最後の攻撃先が自分たち自身というのはよくできてるようにも思えます
自分たちのコミュニティの閉鎖を最も望んでいるのが自分たち自身というのも珍しいですね
最後に
ざまああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ざまああぁぁぁぁあぁああぁぁあぁぁぁああぁあぁぁぁあああぁぁぁぁああぁぁあぁぁあぁああぁっぁぁああぁぁぁぁぁぁぁあぁっぁあああぁぁぁぁあぁああぁぁあぁぁあぁああぁっぁぁああぁぁぁぁぁぁぁあぁっぁあああぁぁぁぁあぁぁぁあぁあぁあｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ざ ま あ ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
http://anond.hatelabo.jp/20120106151331
http://anond.hatelabo.jp/20120106151349
「親の子育てに対する責任を無くせば産みやすくなるのか」というのは
子供を産まない理由に社会制度を上げているのが20%に過ぎない事からそれほど効果が無いとわかるし
その子育てに対する責任をなくす方法というのは革命的な人権意識改革と福祉リソースが必要だ
実質的に考えたら60%以上の人間が子供を産まない理由に挙げている家庭財政状況を立て直して
産みやすい環境をつくる方が「子供を育てる責任」に対する不安の解消に繋がるんじゃないかという方向性です
http://anond.hatelabo.jp/20120106151349
の云う
一度虐殺器官を読んだ人（＝自分）が内容を思い出すためのもの。
第一部
１
死者の国の夢と、そこに現れる死んだ母さん。
２
僕は「濡れ仕事屋（ウェットワークス）」として、二〇一〇年代後半に頻発する内戦をおさめるため、「レイヤーワン」を殺してきた。レイヤーワン――罪の多寡とは無関係に、それを殺すことでもっとも効率的に争いを終結させられる標的。
仕事で殺してきた数多くの（時に罪のない）標的のことは少しも心に留まらないのに、プライベートでの、母に対する医療行為の打ち切りを決断したことで、僕は気を病んでいる。
３
仕事で、二人の標的AとBを殺すように命じられ、異国に入る。標的Bについての情報は、上司から与えられているはずなのだが、それが上司の意図により隠されている。
４
標的Aはその国で虐殺行為を率いていた為に、ぼくの手により暗殺される。
ぼくは標的Aに、なぜそのようなことをしたのかをきくが、彼はしきりに「わからない」と繰り返す。
標的Bはすでにそこにはいなかった。
第二部
１
彼はしばしば「地獄は頭の中にある」と言っていた。
ぼくの父も、かつて自殺したのだった。
標的B――ジョン・ポールを追って、僕らは殺しを繰り返してきた。彼は内戦から内戦へ渡り歩いているようだった。
だが、ぼくらが暮らすアメリカは、「ドミノ・ピザやペイムービーのリピートの平和」か支配し、戦火とは無縁だったのだ。
２
ペンタゴンに召集される。
そこで「ジョン・ポールは軍とは無縁の文人、学者でいる」、「しかし、彼が関わった国は決まって内戦が起こる」と聞かされる。
彼は今度、ヨーロッパに入ったらしい。
ぼくの新たな任務は、チェコで彼を追跡すること。
３
死者の国の夢――「死体は物質にすぎない、生きた人間も」と母さん。
幼少時、僕は家の中で母さんの視線を感じ続けて育った。その視線から逃れるために、「濡れ仕事屋」を始めたのだった。
４
ジョン・ポールと関係を持つらしい女、ルツィアと接触する。チェコ語の講師をしている彼女の生徒として。
ルツィアに、「言語は進化によって獲得された『器官』である」という話を聞かされる。
５
チェコ・プラハで行方をくらませた人間（ジョン・ポールもそうかもしれない）のIDの追跡可能性はゼロらしい。
9･11のテロとの戦い以後、認証を繰り返さなければ買い物も交通機関を利用することもでしないのに。
ルツィア曰く、「ジョン・ポールはもともとMITの学者だったが、いつからかDARPAの研究（ぼくが使う武装、SOPMODを作ったのもDARPA）をするようになった」
６
ルツィアの部屋からの帰り、若者におそわれるが返り討ちにする。おそらくは、ジョン・ポールの協力者。
IDトレースによれば、かつてジョン・ポールとルツィアが密会していたとき、彼の妻子はサラエボで核に吹き飛ばされた。
第三部
１
死者の国の夢――夢の中のプラハでは、例の虐殺が発生していた。
その夢でも、母さんが現れる。
「母さんは意識はなかったけど、内蔵は動いていた。そして、ぼくが医療行為の中断を認証した。
……母さんが死んだのは、ぼくが認証でイエスと言ったときだったんだろうか？」
「あなたは、任務での殺しでは「それは政策が決めたことだ、自分が決めたことじゃない」と、責任の重みから逃れられた。
でも、医療の中断の責任からは逃れられない。あなた自身の決断だから。
……そう思っている。もしくは、中断をする前から私は死んでいたと信じたがっている。
けれど、本当は、私だけじゃなく、あなたがころしてきたすべての人々が、あなたの決断によって死んだ。
私を殺した罪を背負い込めば、あらゆることが帳消しになると思っているの？」
２
夢の虐殺後の静けさとは裏腹に、プラハのあるクラブには、生き生きとした騒々しさが満ちている。
そのクラブでは、IDを認証せずに支払いできる紙幣（みなくなって久しい！）を使うことができる。
「プライヴァシー（認証されない）自由と、テロの自由からの恐怖はトレードオフ。自由の選択の問題」
３
ジョン・ポールの妻子がサラエボで核の熱で蒸発したとき、彼女はジョン・ポールと不倫し、セックスを楽しんでいたという罪の告白。
罪悪感の対象が死んでしまうということは、いつか償うことができるという希望を剥奪されること。
死者は誰も許すことはできない。
４
「濡れ仕事」で数々の骸を見、中央アジアからワシントンに帰ってくると、母さんは事故で死んでいた。が、彼女の心臓は再び動き出した。――危険な軍隊へ行ってしまったぼくへの復讐として、ぼくに生き死にを決断させたかったから？
決断の材料を探す為に、母さんのいえ――ぼくの生家でもある――に行く。
かつてそこでも母さんの視線を絶え間なく感じながら、ぼくは育った。
見つめられることの安堵は、（認証され続けることの安堵は、）息苦しさの表面にすぎない。
結局、母さんの残したログは見ずに（ロックがかかっていて、他人が見ることはそもそもできなかった）、ぼくは母さんの「死」を決断する。
――母さんの視線の「気圧」から逃れたくて、ぼくは母さんを「殺した」んじゃないのか。
５
僕の告白に対してルツィアは、
「人間は生得的に善ね利他行動を行える。あなたの、お母さんを「殺した」決断も、本能による利他の行動。だから、あなたは許されるべき」
ルツィアとの帰り道、気を失う。
ジョン・ポールによる電撃を食らって。
６
とらえられた僕は、ジョン・ポールと会話をする機会を得る。
虐殺の言語は、僕の装備を作ったDARPAが協力した研究により生まれ、僕の殺す対象を選ぶのと同じシステムを利用してる。
７
ルーシャスは、〈計数されざる者〉という、ポールの協力者集団の一人だったのだ。
〈計数されざる者〉は認証を嫌う。プライバシーと平和はトレードオフの関係にあるはずなのに、実際は、認証をすればするほどテロが増加している。
それは、世界の人々が、自分のことにしか興味がないから。ドミノ・ピザとビデオクリップの平和に浸っているから。すぐに手にできるはずの現実に手を伸ばそうとしない奴らばかりだから。
ジョンとルツィアは去る。
僕はルーシャスに殺されかかる。その寸前のところで、ウィリアムズに助けられる。
第四部
１
旧印パ国境地区。そこにいるらしいジョンをとらえるように命じられる。
２
痛いと「感じる」ことはなくても、痛いと「知覚する」ことはできる。人をためらうことなく殺せても、その殺意を自分のことのようには感じない――僕は「濡れ仕事」をこなせるように、DARPAによって、そのように調整されている。
――「殺される」前の母さんと同じ、希薄な意識だ。僕が「濡れ仕事」をするために必要な、意識の希薄さ。
この殺意は、本当に僕のものなのか、僕が「殺す」前、母さんが本当に「死んで」いたのか、僕にはわからない。
３
４
ジョンを文化顧問として雇った、ヒンドゥー原理主義国、ヒンドゥーインディア。
その少年・少女の兵を、「他人の殺意」で殺しながら、ジョンのもとにたどり着き、彼をとらえる。
５
ジョンは、
「私が行っている「虐殺の言語」と、きみが施されている「「他人の殺意」による殺人」は同じだ。どちらも、良心を抑制する」と。
ぼくは、
「あんたには内通者がいるな。政府部内に。僕らの面子か、もっと上のほうだ」
ぼくらアメリカと同等の技術を持った敵によって、列車が襲われる。ジョンは僕たちによる拘束から逃れる。
僕たちも敵も、痛みを「知覚」するが、感じない。体の部分が吹き飛ばされても、戦闘は続く。お互い、「ハンバーガーになるまで弾と火薬をたたき込むしかない」。
リーランドはミンチになりながら、死の間際まで、冷静で希薄な意識で戦い続けた。
第五部
１
インドでミンチになったリーランドは、商品と違ってメタヒストリーを持たないから、つなぎ併せて一つにして、棺に納めるだけでも一苦労だった。
それでも、ミンチにさえならなければ、認証によるメタヒストリーを僕らは持つ。母さんもそうだった。
母さんのメタヒストリーがプロテクトされていなければ、僕は母さんを「殺す」か否かの決断を、認証の蓄積によるライフログを手がかりに探すことができた。
リーランドがミンチになった戦いがきっかけで、ジョンとの内通者が発覚する。
２
発覚した情報を手がかりに、ヴィクトリア湖へとジョンを追う。そこは、誰も追おうとしない人工筋肉のメタヒストリーの行き着く先。
〈ヴィクトリア湖沿岸産業者同盟〉は、人工筋肉の利権を得るために、独立しようとしている。
３
ジョンがいるはずのゲストハウスにルツィアを見つける。
ルツィアを探してゲストハウスに入ると、ジョンが待ちかまえていた。
４（物語のコア）
ジョンは、
「虐殺も利他も、進化によって得たモジュールという点で同じ。むしろ両立すらできる。生存のための大量虐殺というのもありうる。たとえば、食料を多部族から奪って自部族の仲間を生きながらえさせるためだったり」
ルツィアは、
「あなたは、サラエボの奥さんや子供を失って絶望しているから虐殺の言語をばらまいているのね？」
ジョンは、
「いや、愛する人々を守るためだ」
――そうだ。ジョンがいたどの国も虐殺に見回れていたはずなのに、彼の過ごしたアメリカとチェコでは、それが起きていない！
５（物語のコア）
ジョンは、
「人々はみたいものしか見ない。だから、いくら認証しても、テロはなくならない。
ならば、テロで爆発するはずの憎しみがこちら、アメリカやチェコといった先進国に向く前に、彼ら同士で憎しみあってもらおう。――そのために、虐殺の言語をふりまいた」
ジョンは、ぼくらの世界へのテロを未然に防ぐため、虐殺の旅を重ねた。
ルツィアは僕に、ジョンを殺さずに逮捕するように言う。僕らの世界の平和は、ジョンによる無数の死者の上に成り立っているのだと、みんなが知るべきだと。
と、ルツィアがヘッドショットを決められて死ぬ。
ウィリアムズによって。
「なぜ殺した」と僕。
「妻と子のためだ。彼女らは、この世界が虐殺の上に成り立っていることを知らなくていい。
ドミノ・ピザを認証で受け取る世界、くそったれの平和な世界を、俺は彼女らのために守る」
ウィリアムズはジョンを殺したがっているが、僕はルツィアの最後の言葉の通りに、ジョンを生きてアメリカにつれていき、証言の場に立たせたい。
ジョンとともに、逃げる。
「おまえを逃がせばまた、虐殺の言語を振りまくのだろう？」と僕。
「いや、死んだルツィアの望んだ通り、世界に真実を知らせよう」
タンザニア兵と合流しようとするが、それはタンザニア兵になりすました、僕の「濡れ仕事」の仲間だった。
彼がジョンを射殺し、僕の任務は（アメリカからすれば）成功裡に終わる。
〈エピローグ〉
……僕は、プロテクトがあるためにライフログを見られなかったのではない。ただ、漠然とした恐怖があって、ライフログの閲覧を申請しなかっただけだ。
僕は幼いころ、常に母さんに監視（ID）されているような気でいたが、母さんのログを読んでみると、必要最低限にしか、僕の存在が記述されていない。
母さんの記録の中に生きていたのは、圧倒的に父、自殺したはずの父だった。
僕は、ジョンからもらった手帳を元に、虐殺の言語を語る。虐殺の言語でもって、ルツィアの願い通り、真実を世に知らせるのだ。
そして、世界にとって危険な、アメリカという火種を、虐殺に突き落とす。
僕はこの決断を背負う。ジョンがアメリカ以外の命を背負おうと決めたように。
☆改変版
ジョンは、
「いや、私は米国内の後ろ盾を失った。深層構造の原理を知られれば、たかが言葉だ。応用されるのも時間の問題だろう。マスコミや政府公報で、いくらでも虐殺の言語を打ち消せるさ。
だが、私は〈計数されざる者〉という新たなバックアップを得られた。認証に対して憎悪を抱く、世界的な組織だ。この力を使えば、私たちのすむ「こちら側」を静寂に保つことができる」
「なにをするつもりだ？」
僕の「濡れ仕事」の仲間が、僕がジョンの答えを聞く前にジョンを射殺し、僕の任務は（アメリカからすれば）成功裡に終わる。
〈エピローグ〉
僕はジョンに、「真実」が書かれたテキストファイルを渡されていた。
それを世界に知らしめ、僕たちが虐殺の上にたっていることをみんなが理解することがルツィアの願いなら、僕はそうするべきなのだろう。
公聴会で、ぼくはジョンの件で見聞きしたものを語る機会を得る。
ジョンから渡された「真実」をオルタナに浮かべて話そうとする。
すると、僕が見ずにいた、母さんのライフログをオルタナに突きつけられる。――これが、〈計数されざる者〉、ジョンが最後に得た力か。
幼少の僕は、母さんに監視（ID）され続けていたと思っていた。しかし、母さんのライフログには、あまりにも父ばかりがいる。彼の死語ですら。
それを皮切りに、次々に、アメリカの全議員、いや、オルタナをつけているすべての人々の視界に突きつけられる、真実のログ。世界からアメリカに憎悪の数々が向けられているという真実。〈計数されざる者〉のルーシャスは言っていた。プライバシーの提供と、テロとのトレードオフの不均衡は、みたいものばかりを見ることによって起こると。認証の中に閉じこもり、ドミノ・ピザとビデオクリップの平和の外を知ろうとしないことで起こると。
ふと、アメリカはもう死んでいるのだと思った。母さんに視線を返せない、父さんのように。憎悪を浴び続け、しかしそれを無視しているアメリカは、死んだ父さんと同じだ。
……だが、アメリカに憎悪を向ける小国とて、自分の窮状をしらしめようと騒ぐばかりで、他の小国を知ろうとすらしていないのだ。僕が母さんのログを見ようとしなかったように。
ジョンが行った、〈計数されざる者〉の力の改変。それは、小国の内部で争いを起こす虐殺の言語よりも規模が大きなものだった。互いに無視しあっていたずの、小国と小国の視線をぶつけ合わせる。そして、小国同士で戦争を起こすことで、「こちら側」の平和を保とうとするものだった。
ジョンの考えと僕の考えは違う。
母さんが僕を見ないのは、父さんというすでに存在しない項があるからだ。アメリカからの存在しない視線を小国が期待するように。
存在しないものを、存在しないと意識させること。僕にはそれができる。ジョンから得た「真実」の欠片、虐殺の言語と、僕のマザータン、アメリカで語られる英語によった。
そんなにいい加減だと現場はすごく困るよ。
メモやメッセージボードを発注するとかメールアドレス割り振るとかの作業があるならそういうところを織り込んでおきたいのであって、
そういう事を具体的に聞いてくるならきちんと応えればいいけれど
相手は「具体的に」と言いながらも具体性のない「どう思う？」というボンヤリした質問しかしなかった
「そういう時はボンヤリと合わせればいいんだよ」
と言ってるの
面接時だって突っ込めるところはどんどん突っ込むと思う。ちょっと時間をかけてもかけなくてもって、必要なら時間かけてでも聞きますよ。
こっちもそういう場合のやり方についてあーだこーだ言ってるのです
貴方は大変真面目で綺麗な方だと思うけど
（ついでに実務的な事に関して言えば
就業後、あとから詳細や具体的なアレコレでの悶着は絶対起こるよ
「基本テキストで指示を」といったアウトラインを紙ベースで残してあげれば最低限の言い訳は立つ
もちろん面接時にそのアウトラインに沿って具体的な質問があったなら正直に答えてもいいけど
多分向こうもそんな詳細な想定なんか思いつかない
だからこっちもボンヤリでいい
あなたごまかすことばっかりだね。失礼だけど、働いてる方ですか？
そんなにいい加減だと現場はすごく困るよ。
メモやメッセージボードを発注するとかメールアドレス割り振るとかの作業があるならそういうところを織り込んでおきたいのであって、
言い訳なんかいらないし言い訳ばっかり準備してあっても信用ならなくて印象悪くなるだけ。
面接時だって突っ込めるところはどんどん突っ込むと思う。ちょっと時間をかけてもかけなくてもって、必要なら時間かけてでも聞きますよ。
「基本テキストで〜」ってどのくらいまでが「基本」なのか、というのを掴まないと、現場に打ち合わせることもできないし。
…元増田には失礼な言い方になるかもしれないけど
採るからには気分よく働いてもらいたいでしょ。
障害の有無関係なく簡単に解雇できないんだし、ノウハウ蓄積のためにも最大限成果出してもらえるように環境整える努力はすると思う。
就業後、あとから詳細や具体的なアレコレでの悶着は絶対起こるよ
「基本テキストで指示を」といったアウトラインを紙ベースで残してあげれば最低限の言い訳は立つ
もちろん面接時にそのアウトラインに沿って具体的な質問があったなら正直に答えてもいいけど
多分向こうもそんな詳細な想定なんか思いつかない
だからこっちもボンヤリでいい
…元増田には失礼な言い方になるかもしれないけど
元増田を採る時点で「まるっきり役に立たない」ケースまでは覚悟してると思うよ
暴れるとか倒れるとかアグレッシブなマイナスに行かない限りは想定内
譲歩するとかしないとかは
障害者って、そのままだと本当は「譲歩」の余地はないんだよ。だから元増田は「譲歩を見せないように見える」と表現している。
実際は譲歩したら何もできなくなっちゃう、必需なものを必需と言ってるだけなんだけど。
貴方が言っていたこと全てを含みながら簡潔で、相手も聞きやすくなります
なんでもないような感じに広範な事を要求するのが大事
そこを広範にぼかすんだったらそもそも具体的な配慮に言及する意味はない。
「テキストベースで指示を出す」というのと、「指示は全部テキストに落とし込む」というのは一致してない。
元増田が具体的にどの程度の障害なのか知らんけど、後者でなければダメな人間に前者（例えば紙にまとめた資料を見せながら同時に口答で説明・捕捉する）を行うようなシチュエーションが生じる余地があってはマズい。
要求するだけなら、実は簡単なんです。例えば、私は耳から聞き取ることが苦手です。だから、「指示はメモやメールなど、目に見える形で頂けると助かります」と申し上げることは出来ます。ただ、「ボイスレコーダーを隣に置いて仕事をし、指示を上手く聞き取れなかったときはレコーダーを聞き直しながら仕事をしてもいいですか？」でもいいと思うのです。また、私が思いつかないだけで、他に配慮して頂ける方法もあるかもしれない。
言うだけ言えばいいんじゃねそれ全部…
その中で、どんな配慮がいい？と尋ねられても……申し訳ないですが、それは私には分からないです。メモを渡す方が都合のいい職場もあるでしょうし、メモを渡す余裕のない職場かもしれない。どんな配慮が出来るかは、職場によりけりだと思いますから。
それはあんたの「言うだけ言う」を受けて職場が考えることじゃね…
また、これは純粋に、他の方からのご意見を聞きたいと思っていることですが、
貴方が面接側の立場だったとして、一方的に「ああして欲しい」「こうして欲しい」と要求ばかりする求職者を採用したいと思われますか？
どうして欲しいかわからない人よりはニーズ述べる人のほうが入れ易いんじゃね…
譲歩するとかしないとかは
互いのニーズすり合わせる段階で（入社した後で）考えることじゃね…
だから、私は障害については出来るだけ説明するようにしており、
意図的だろうとなんだろうと
具体的なことが何にも書いてない＆聞くと口ごもる人は採用しづらいよね…
それって「私との連絡は全部テキストベースにして欲しい！ここは譲れません！」よりずっと採用しづらいってわかってる？
貴方が私の立場なら、どう返答されるでしょうか。
私が貴方なら、自分のして欲しい具体的なことを思いつくだけ最初に全部言います
内容は広く、言葉としては簡潔に
その際の細かいコツとしては
＞「指示はメモやメールなど、目に見える形で頂けると助かります」と申し上げることは出来ます。
＞ただ、「ボイスレコーダーを隣に置いて仕事をし、指示を上手く聞き取れなかったときはレコーダーを
＞聞き直しながら仕事をしてもいいですか？」でもいいと思うのです。
こういうのはあまり良くない
あなたとしては誠実に様々なオプションを示しているつもりであっても、
口頭で聞いてる相手はなにか、扱いきれないほど膨大で煩雑なことを言われてる気になる可能性はある
貴方が言っていたこと全てを含みながら簡潔で、相手も聞きやすくなります
なんでもないような感じに広範な事を要求するのが大事
どう返答されたらわかりやすいものになるでしょうか。
あなたの障害に対して必要なコストが「自分達に対処可能なものか」について気にしてると思います
あなたは自分の障害についてわかってる範囲で「こういうことが必要ですよ」と言えばいい
もっと言えば「それなりの便宜は必要ですけど、あなた達がコントロール不可能なほどの事は何もありませんよ」
と示してあげればいいだけ
まず、私の中では、
障害者＝怒られない、は存在しない。また、障害者＝必ず配慮されるべき者……ではないような気がする。
そもそも、間違えた部分は、注意されるべきだし、怒られるべきだと思う。指摘されなければ、間違いは分からないのだから。
理不尽なのは、『何故』怒られるのかが『分からない』こと。なぜなら、『分からない』ままだと、『直す』事が出来ないから。そして、直す方法を考える手段がないまま、『直せ』と言われるのは、流石に理不尽だと思う。
ただ、それを説明するのは難しい。なぜなら、これまでの人生で口にした時は『言い訳』としか取られなかったから。
ーーと、その辺の所をぐだぐだ説明した（注：たしか、このあたりで泣き始めた）ところ、
あなたのこれは悪いけど面接という限られた時間、限られた目的のフォーマルなシーンでは真面目すぎるし深すぎる
相手がそういう話を求めてなかったのはその場に居なくてもわかる
貴方にとっては障害が日常であるからそりゃ障害についての考察は深く深くなるだろうけど
相手はその道の初心者だと言う事を貴方の方から配慮しないといけない
他の面接の例にするなら
「在学中に〇〇の研究をしたそうですが、どんなものですか」って聞かれたとして
その会社と関連性のある部分だけダイジェストにして簡潔に喋るよね
その研究の科学史上の深い意義や本質とか、それやってるときの自分史とか、研究完成間近に愛犬が死んだドラマとか、
＞「普通の人なら、間違えたら『違うやろ』って叱れる。でも、障害者の人を叱ることは出来ない。
＞なぜなら、障害が原因で間違いを起こしていたとしたら、それを叱るのは理不尽でしょう？
＞それならば、そもそもその向かない仕事はしてもらわずに、出来る仕事をしてもらえばいい。
＞でも、貴方のように目に見えない障害で、何を配慮したらいいか分からないと、こちらもどうもしてあげられない。
例えば
仰るとおり、私の障害は一目で見てわかるようなものではなく、ご心配の趣旨はわかります。
そこで私は本日、自分の障害のある分野を簡単にまとめたレジュメを持参いたしました。
これに目を通していただくことで、私の障害の傾向やパターンのようなものは
どうぞよろしくお願いいたします。」
と述べれば
相手の質問が不明瞭なままでも話の流れはこっちの都合に沿って進むし
相手もそれに沿って会話を続行するよ
「どう思う？」っていう質問は確かに指示方向が広範で、あまり真剣に考え出すと意味がわからなくなる
そういう質問の仕方をする人は、慌ててるか、頭が悪いか、どっちにせよ混乱してる
私はそういう時は全部自分の都合のいい方向に回収して自分の演説おっぱじめちゃうしそれで得をしてきた
ぱっと見ると貴方には「図々しさ」と「相手の立場を読む心」と「適当さ」が足りてないように見える
過去に「図々しい」とか言われた事があってその反動でそうなってるの？
ただし深いレイヤーは避けて、浅く浅くね
大学時代、とある講義で使ったテキストに『精神疾患の要因には、遺伝的要因と環境的要因の2種類がある』と書かれていた。
教授は眉間に深く皺を刻み、苛立ちの隠せないざらついた声で、室内の学生に命じた。
「これは間違いだから、遺伝的要因の部分を黒く塗りつぶせ」と。
随分と古い文献を参照しているのだなと、教授は憤っていた。
４年前、兄は統合失調症を発症した。元々、ストレスを感じやすい人だった。
こういう病院に行くことになったから、と母から資料が手渡された。精神病院のパンフレットだった。
父は４人兄妹で、そのうち３人が自律神経失調症を患っていたことを、その時に知った。
叔父の息子（つまり従弟）が長い間入院しているのは、兄と同じ病気に罹患しているからという事実も、同時に。
笑いたくなった。父から子へと、遺伝しているじゃないか。テキストの記述が正しかったんじゃないか。
腹を抱えて笑いたくなった。偽善者め。あの講義をした教授に後ろから飛び膝蹴りを喰らわせたかった。
出来なかったので、代わりにテキストを開き、塗りつぶした箇所の上に修正テープを貼り、それから「遺伝的要因」と書き直した。
兄は、そして私も、もう結婚してもいいような年頃だ。両親にはそろそろ孫の顔が見たいと言われている。
しかし、少なくとも私は、結婚する気はない。万が一結婚することになっても、子どもを産むつもりは毛頭ない。
少し前、胎内にいる子どもに障害があることが発覚したら、産むか産まないかという討論があった。
普通の人にとって、何らかの障害を持つ子どもを授かる確率は、１０００分の１とか１００００分の１とかの、比較的低い確率である。
しかし、私自身の場合はどうだろう。普通の人よりは、高い確率であるだろうと思う。
障害は個性のひとつ。素敵な言葉だと思う。これが常識となった世の中は、お花畑のような素晴らしさなのだろう。
兄のことを馬鹿にするわけではないが、障害は、重い。妹である私がそう思うのだから、親として兄を背負う父母の負担は大きいはずだ。
そして、自分の子どもがそうなってしまったとき、私には耐え切れる自信はない。
兄はこれからどうなるのだろうか。障害をなるだけ軽くし、自立しようと、兄は努力を重ねている。
しかし、時折、ぎらぎらとした危うい光を宿し、家族を睨みつける兄を見ると、それは無理なことではないだろうか、という思いが湧いてくる。
父母が死んだとき、兄を背負うのは恐らく、私の役目になるのだろう。
その時に結婚していようといなかろうと、一生、兄を支えていくことになるのだろう。
それが嫌ならば逃げ出せばいい。選択肢のひとつとして、それを思いつくものの、そんな非情なことは出来ないと、すぐに打ち消す私は、家族の絆という名前の鎖に縛られている。
父は私に言う。「お前は元気で良かったな」と。
人よりも感情の起伏が激しくて、落ち込みやすいという自覚はある。
第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 練習問題
あれだなぁ。対面のレッスンを受けることのメリットは、
「自分が何を英語で言いたいか」がわかることであって、その英語表現が分かるわけではないのか。
テキストベースでやっていく⇒アレンジする⇒そのテーマで少しフリーに話す、という感じで進んだのだけれど
日本語を使えるわけじゃないので、「これがいいたいんです」と分かってるのは自分だけ。
相手の先生ははとにかくじっと待ってくれるだけ。（いや、すごくありがたいです。普通だったらイライラするだろうに嫌な顔せずに待ってくれる）
一生懸命自分で言いたいことを頭の中で考えるんだけれど、それを表現する単語さえ無かったらどうしようもない。
結局、んーんー言ってるだけになっちゃて、そのまま時間が来てしまった。ﾂﾀﾚﾗﾚﾅｶｯﾀ・・・///。
これだと相手にも申し訳ないし、自分としても不満が残るから、レッスン終わった後に
「これはどういうふうに表現すればよかったんだろう」とかそういうのを考えて調べなければ、という気持ちになった。
ラングリッチさんへの要望としては、別にこういう「この日本語どうしよう」みたいなのに応答して貰う必要はないので、
こういう「こういうことを伝えたかったのだけれど、うまくいかなかったよー」みたいな感想を
とにかく序盤はいろいろ悩む所がありますです。サポートに相談するのもなんだしなー程度の軽い話がしたい。今は増田でやってますが。
さて、体験レッスンが終わったけれどどうしよう。あまりに単語とか表現を知らなさすぎるので、
テキストベースを淡々とやって、あまり脱線しないようにお願いするか（これも英語で伝えなければ・・・）
それとも、しばらくはlang8で基礎的な表現に慣れたり、ボキャブラリーを増やすのが先だろうか。悩ましい。
http://langrich.com/startguide
ここに体験レッスンのための手順が書いてるんですが・・・。私的には少し不親切に感じました。
無料体験レッスンの手順
これだけじゃ分かんねー。
Skype自体をイントールするのはじめてだったので、
どういうふうに連絡があって、どういうふうに始まるのかイメージができませんでしたよ。
おかげで、ずっとｇｋｂｒしながら待ってたのです。
スカイプのインストールの説明してるくらいだから、Skype初心者を想定してますよね。
それなら、もう少しでいいので、フローをイメージできるような説明をしていただきたいであります。
無料体験レッスンだから、うまくいかなくてもこっちはお金は損しない、ということなのかもしれないけれど
こちとら、相手の講師様に失礼なことにならないかで気が気じゃなかったです。
もちろん、ラングリッチはスカイプの会社ではないので、スカイプの説明を懇切丁寧にやる必要はないのかもしれませんが、
でも道具として活用してるのだから、授業がSkypeで成り立ってるのだから、なんちゅーかこう、もうちょっと
Skypeに対する恐怖心みたいなのに対して考慮していただきたかったであります。
初回始まるまでのアレこれがかなりストレスフルな感じだったのでもうちょっとフレンドリーな感じでお願いします。
ちなみにそんな感じで授業始まるまではすごい緊張したのですが、授業始まってからは
基本的にテキストに従って機械的に進んでいくので、ちょっと予習してから取り組めば問題ないと思う。
たとえば初回は「挨拶」「体調」「仕事」の話をするだけなので、自分の仕事について英語で簡単に説明できるくらい準備しておけば完璧。
私はぶっつけ本番でやったからつっかえつっかえになったけれど、ゆっくりやっていけば出来るようになるんじゃないかな。
ちなみに身元バレ覚悟で言うと、無料体験レッスン初回では講師の方から１０点満点で７．８点頂きましたが、これがどの程度すごいかよく分からない・・・。
講師の人がちゃんと説明してくれてたんですが、ちゃんと聞き取れなかったっす。
とりあえず「もっと練習しろ、君には練習が足りない」って言われたので今回やったところをちゃんと練習してからもう一回受講しようと思います。
留学は価値観が変わるとはまさにこの事ですよね。フリーター夫婦は日本では見下されがちだと思います。私は身の丈に合った暮らしをして頑張っている夫婦は尊敬しますが。
私の英語力は…
最近大学行きたい！と思って中学英語のテキストを立ち読みしましたが、
「ｂｅ動詞？ｂｅってどこに書いてあるん？書いてないやん…うーん、わからん。先が思いやられる。」
私も「同じカテゴリにいる人相手では知らなかったことを教えてもらうこともあります。」というような事を、趣味の場で言われる事が良くあります。
それで友達としては好かれても、やはり恋愛となると別のようで、お付き合いには至っていません。
もっと中身から変えていって、この人と付き合いたいと誰かに思って頂けるような人間になりたいです。
http://anond.hatelabo.jp/20111113010022
こちらに触発されて書いてみる。辞めてからかなり時間も経ったのでそろそろ書いてもいいかなと。
訓練内容はAdobeのCS4の操作方法→自主制作というのがだいたいの流れとなっていて、それぞれのアプリケーションのテキスト（フォトショ、イラレ、DW、Flash）とHTML+CSSの本という感じ。
このテキストを選定しているのは教室を運営している会社のようで、（伝聞で聞いたので定かではない）もし運営してる会社がWEB制作を知らないとか知っててもテーブルレイアウトだった場合にはあまりいい本は選ばれないようです。また運営会社同士でヨコの繋がりで話し合って本を決めてる部分もある（複数の教室で同じ本だった）のかな？と予想しました。
実際の訓練内容はハローワークで決めているのか運営会社で決めているのかは解りませんが、講師は訓練スケジュールやテキストに関してなにも言えない、わからないまま講義が始まります。
HTML5時代だというのにFLASHにえらく時間を割いたりするスケジュールで、受講生から「せんせーFLASHってどうなんすか？」と物凄く困る質問をされたりします。
また受講生はAdobe製品をアカデミックで買えるというナイスな特典があったりしますが、授業で使ってるのはCS4だけど買ったのはCS5.5みたいな微妙だけど重要なアクシデントが発生します。
HTMLの本もXHTMLならまだしもHTML4.01（しかもStrict）で書いてる本だったりすることもあります。
受講生はテキストを実費で購入しているため、ないがしろにするわけにはいかないので「これいらんだろ」とか思ってもとりあえず本の通りに進めなければなりません。（例えばHTMLの本を早めに終わらせてXHTMLの話をして余計混乱させたりとかあった）
ここで問題なのは受講生は基本的にお金に余裕がある人は少ないです。
AdobeのWebプレミアムがアカデミックで買えるとはいえ10万以上の余裕があるなら基金訓練なんかコネーよ！という人が半数以上いるんじゃないかと。
体験版はあるけど1ヶ月で終わるし、訓練自体は半年あるわけです。
なのでGIMPとかInkscapeとかもサラっと存在を教えておいたりします。
あとはフォームのHTMLだけ教えて肝心のPHPやらPerlやらには基本触れないのでそこも工夫が必要です。
教科書3冊くらいクリアするころには生徒からこれで本当にWEB屋さんになれるの？とか疑問を持たれますので、フリーでやっていく方法とか自分の経験談の話をすると人気の講師になれますが、会社からはいい顔されないかもしれません。職業訓練なのでどこかに就職するのが大前提なんです。
指導要綱みたいなものはキホンないので講師の思うとおりに教えられますが、上記のテキストの縛りとスケジュールの縛りがあるので本が変わる前にグループを作ってもらって共同作業させることを取り入れました。実際にWEB屋さんにいったら分業しますしね。
さて、各アプリケーションのテキストがいいものだったらよいのですが、そうでない場合は自分で課題とかを作る必要があります。
フォトショやらイラレはいいんですが問題はHTML+CSSとFLASH。FlashなんかはASがゴッソリ抜けてたりすると生徒から「やりたいことができない！」と嘆かれます。CSSなんかも「やりたいことができない！」と言われがちです。
実際は一人の講師が２コマやることがザラなんじゃないかと思います。
AM9時からお昼を挟んでPM3時まで+PM3時からPM9時まで。若干ズレはするでしょうがこんな感じなんじゃないかと。
これで課題を自作していたら睡眠時間は3～4時間くらいになっちまいます。ああ祝日ってステキ・・・。とか思い始めます。フリーランサーは普段の仕事は全部お断りしないとイカンかもしれません。
テキストの内容とスケジュール（ｘ月ｘ日からｘ月ｘ日までFLASHとか書いてある）なんか完全に合わないので苦悩します。
事前に用意できればいいのですが先に書いたようにスケジュールやテキストは開講数日前にコレでヨロ！的に渡されますので初めてやるひとは対応難しいでしょう。
とりあえず今日はここまで。
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。