 
|
はてなキーワード: ソフトウェアとは
ああ、今じゃあメモリ2GBで32bit WindowsってんでもうDisられちゃうんだなあ。
おじさんの新入社員のころはWindows2000用のソフトウェアをWindows MEのメモリ128MBのマシンで開発しろって言われたよ。
VC6はそりゃあもう遅かったねえ。
しまいにゃHDDの基板上のチップがパッケージ不良で大規模回収になって、ロットが対象のものだって発表される直前にクラッシュしたのさ。
おじさんがその会社にいたくなくなったのはそれが最初だった。バックアップ用のHDDもなければ、CVSなんて便利なものも無かったから、自腹で購入していたノートパソコンにこっそり移していなければ、ソースが全部クラッシュしていたところだったなあ。
そういやCVS使いたいって言ったらなんか知財の関係の人に申請書を出して許可を得なくちゃいけないとかで面倒くさすぎて諦めたこともあったなあ。ie以外のブラウザも禁止だったなあ。アレも禁止コレも禁止って言った割にはcode redとか感染しまくってて笑えたなあ。
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
「人数増やすと…」について補足。
http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1
スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマがプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションのオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。
今回のケースでは、60人が1300人になったので、コミュニケーション量は約477倍になるわけだ。
ソフトウェア開発プロジェクト（一定規模以上）がトラブルが起こって納期までに終わりそうにない、赤字が出てでも終わらせないと困る時の別解
色々な方法があるんだけど、その中でもなぜかこういう方法をとるところが案外少ないように思われるので…。この方法はもちろん万能じゃないので、「こんな欠点がある」って突っ込みはいっぱいあるでしょうが、「いついかなる時でも使えない」話ではないレベルです。
・増員する、ただし、雑用係専用部隊を大幅に。
→業務メインをやる人が増えるとコミュニケーションコストが増大してかえって遅延する現象は散見されますので、そういうコストが相対的に起きにくい仕事になるべく人を投入するという発想です。
ただ、これは、「低時給バイトさん」「事務職」ではだめです（チームの中にそういう人を入れるのはいい場合も多々ありますが、「低時給バイトさん」「事務職」ばかりを多数入れてもソフトウェア開発では大抵困ります。つまり、PG/SEレベルの、ソフトウェア開発の一般常識のある単価の高い人を敢えて雑用や事務に投入するんです。これの一つのデメリットはSE/PGにそんな仕事をさせるとモチベーションが下がって当然なので、長期には向きません。プロジェクトが長いなら少しずつメンバーを入れ替えながらがベターかと。
例）「このデータ加工しといて」と振ってExcelベース（関数とかVBAは使えてよ）なりスクリプト言語なりで加工する人
例）コピーを頼まれたらそれに徹する人 …ここだけ見ると単価高い人をそんな仕事に、と思うかもしれませんが、変にチームに投入して遅延を拡大させるのとどっちがいいんですかって話ですよ。
議事メモではなく議事録が必要なら、録音してテープ起こしするのの草稿を別の人がやる（ここ例えメインの仕事に入ってなくともSE/PGかどうかで品質が随分違う。もっというと、草稿の草稿は音声認識ソフトにやらせる手もある 録音レベルが悪いときついけど）…これは普通のプロジェクトでやってもまずコスト的に割が合わないでしょう。あくまでここに書いているのはすべて「赤字が出てでも早く終わらせる」みたいな特殊な状況なのでやってみるといい場合があるんじゃないの、というお話です。
例）必ずしも雑用ではないが、特にキーマンには秘書をつけてしまえ。その人のスケジュール管理から色々とね。秘書検定もってるエンジニアとかいたら最高ですが（どんだけおるんや） この人に用事があるんだけど今取り込み中…みたいな時って用事がすんでからタイムリーにってなかなかいかないんですよね。秘書がいたらなんとかできませんかね？
人を横断して作業効率化を図れる書類の自動化とか可能なら専任作ってExcel VBAでもスクリプト言語でもなんでもいいので作ってしまえ。
・アメニティの充実を図る。
機材のせいでボトルネックになってませんか？PCの性能は大丈夫ですか？ディスプレイは大きいですか？プリンタやコピー機の数は足りてますか？プリンタやコピー機の速度は十分ですか？カラー印刷出来ますか？ファイル共有サーバが遅かったりしませんか？ ※PCを変更すると環境移行コストはかかりますが、一時的なものです。
事務専門でも出来る所では「コピー用紙がなくなってから補充までにタイムラグとかないですよね」とか
ポットに沸かしたお湯が空っぽとかないですよね？ …まぁこれはエンジニアじゃない人に任せてもいい領域。
ホワイトボードに書いたものを電子データでPCに送れるとかいまどき常識ですよね？丁寧に書いてあったらOCRも可能ですよね？
経費で、高いのでいいからうまい弁当をオフィス配達してしまえ ※税金の問題等色々あるし、自分で選んだり外食に行く方が効率上がる人もいるので全員ってわけにはいかないんですけど。希望者だけでも。
赤字覚悟で増員してるのに、人を増やしたけど「予算がないからPCにいいのが調達できなくって」って話は実在するようですが、何かおかしくないですか？
1人月60万とか100万とか何人も入れるのに。会計上の問題とか壁があるので表面的な金額では決められないんですけど、でもおかしくないですか？
あ、上記のようなことを実際にやって酷い目にあったエピソードがあったら教えてください。「うまくいかない場面」なんて当然いくらでもあると思うので。
原文：The Un-Internet by Dave Winer
こう書くのは初めてじゃない……
毎回全部書き下ろす必要はないわけで、
もはや様式美になってきた感がある。
何回繰りかえしたかとかは置いておいて、
さあ、もう一回はじめようか。
問題は「コントロール」、これに尽きる。
どういうわけか、IT企業の重役はこれを欲しがるんだけれども、
1994年、この繰り返す世界の年代記を書き始めたばかりの私はこう言った。
「私たちよりもユーザーがまた一枚上手だった。
この業界ではだいたい15年周期くらいでこういうことが起こる。
私たちが足元を見失って、ユーザーが反乱して、新しいソフトウェアビジネスが降臨する。」
そこではこうも言っている。
「ユーザーは一度コントロールを手にしたら、二度と返してくれない」。
御存じの通り、いまそれがTwitterコミュニティで起こっている。
コントロールを欲しがるというのは、別にああいった企業の重役の倫理観のせいじゃない。
短期的にはそれが最善のやりかただからだ。
ありうる道は、ユーザーに手綱をうまくかけられるか、競争に負けるかしかない。
若いころの起業家としての私であれば、そのくらいのことはわかっていたんだろうと言われるかもしれないけれども、そうじゃなかった。
簡単にコピーできるものをどうやって商売にしていいか、分からなかった。
だから、詳しくない人にはコピーできないようにするためのコントロールの方法を編み出した。
すると、私たちのソフトウェアをコピーするためのソフトウェアの市場ができあがった。
けっきょくの問題は、ユーザーは私たちの意図に反することをやろうとする人なのかどうか、ということだった。
ユーザーの皆さんは誇りのある人たちだった。
だから私もするだろうことをした。
200ドルはするそのディスクをハサミで真っ二つにしたものを入れた封筒が、次々に送られてきた。
そうやって欲しいものを手に入れた。
私はようやく、いつもこうなるんだということを思い知らされた。
今回は、Appleがユーザーをコントロールしようとする勢力の親分だ。
ユーザーを守るというAppleの説明は、ある程度までは正しい。
iPadにソフトウェアをダウンロードするとき、害が起こさないということはかなりの程度、信頼できる。
そこまでで済むんだったら、私は何も言わない。
済むはずがない。
相手には、どのソフトウェアが自分のプラットフォームで出まわってもいいかを決める権力がある。
そうなれば、言論も規制されるのは避けようがない。
その意味で、iPadプラットフォームはディズニーランドのようなものじゃないだろうか。
ディズニーランドやPixarの映画にないようなものは、そこにもない。
悲しいのは、Appleが若い世代に対する悪い見本になってしまっていることだ。
若い世代というのは、Appleみたいに「ユーザーエクスペリエンス」をコントロールしたがってそうな、
TwitterやTumblrといった、比較的小さな会社のことだ。
彼らは、自由市場の不確実さよりも自分たちの品質管理のセンスのほうが優れていると思っている。
Twitterでは、Twitterがパートナーとして指定したところのコンテンツしか表示できない。
誰にも見えないようにされている。
Tumblrはあるブラウザアドオンをおすすめしないと言い出した。
これを問題にするのはきっと、それなりの数のユーザーが使いたがったからこそだろう。
この決定は開発者だけじゃなくてユーザーまでも巻き込むことになる。
ユーザーを「教育」しなければならなくなる、というのが問題だと彼らは認めた。
あれ？ これって聞き覚えがあるような………
ということで、最後には逆の結果に落ち着くだろう。
そうならなきゃならない、
ということを、インターネットが教えてくれた。
1970年代、それはまだインターネットとは呼ばれていなかった。
その単純さと、コントロールされていないところが好きだった。
あれを載せてはいけない、これは載せてもいい、と命令する人はいなかった。
インターネットが育った周りの環境、つまりメインフレームの世界では、壁はものすごく大きかった。
個人はコンピュータを持てない。
それからループが回るたび、IT業界が持ってくるコントロールを解毒するというのが、インターネットの役割だった。
でも最後には、私たちは壁を乗り越える。
そうするとまた次の壁がやってくる。
成り上がったプラットフォームが数の力で支配しようとする。
そしてまた、おなじ過ちを犯す。
そして、おそらくいつも、インターネットが勝つ。
スマートフォンspモードの不具合で目下お祭り中のNTTドコモ。
どんな言い訳を発表してくるか楽しみにしていたら、
「スマートフォンの普及による通信量の増加でサーバーが能力を超えた」ときた。
相変わらず、自らの誤りは認めませんとも。
内情に詳しい人いわく、真相はバグだらけのソフトウェアを誰も直せないのが原因だって。
ロクな技術者を手配できないのは以前からだったような気もするが、そろそろ臨界のようだ。
spモードに関しては、Xperiaに搭載され大反響を巻き起こしたメールアプリも記憶に新しい。
今回多少ましな技術者に作らせたせいか、見知らぬ他人のメールアドレスにすり変わってしまうという
革新的な出会い系機能が実装され、華々しいサービス停止を披露してくれた。
どうやったらそんなバグ埋め込めるんだｗわざとか？
教えてくれ。
The burnout cycle (Jono Bacon, Nov 2010) (PDF) の一部より。
燃え尽きの最初の段階としてよく見られるのは、自分の価値を証明したいという欲求です。
その根幹には、自分の仕事が軽んじられているという不安感があります。
燃え尽き症候群の患者は、自分の価値を証明するため、より多く働こうとします。
長時間働くことは燃え尽き症候群の初期段階に見られる兆候です。
自分がいかにたくさんの結果を出しているかを証明しようとして、
頑張って長く働くこうとします。
夜遅くまで働きつづけることも珍しくなく、
オープンソースソフトウェアの活動の場合はさらにそれが顕著です。
たくさん働けば自分の価値をもっと分かってもらえるという信念のもと、
午前2時や3時まで働いたりもします。
この段階になると、眠ること、食べること、友達と遊ぶことなどは単なる「娯楽」であり、
自分の価値を証明しようという欲求があまりにも強い状況であり、
より多く働くことが最優先事項になります。
誰かに誘われても、断ることに抵抗を感じません。
また、働きつづけることに抵抗を感じなくなります。
深夜や早朝に働くことは珍しくなく、
この段階では、異変に気づいた身近な友人や家族から、大丈夫かと尋ねられるようになります。
ただやることが溜まっているだけだと言って、彼らの気遣いを聞き入れません。
この段階では、仕事へのこだわりが強くなることにより、
それまでの価値観において大切にしていた、友人や趣味といったものを脇にのけるようになります。
仕事でよい結果を出すことが、成功をはかる唯一の指標になります。
人付き合いや家族と時間を過ごすことが、もはややりがいのある大切なことではなくなります。
むしろそうしたものは、やりがいある仕事へのさまたげになる、と考えるようになります。
もっと働かなければならないから、と言い訳するのに抵抗を感じなくなります。
いつ尋ねてもダメだと言うので、友人から誘われることもなくなっていきます。
この段階では、不信感、狭量さ、攻撃性が顔を出してきます。
同僚がバカでとるに足りないことばかり言うように見え、
どんどん生じてくる問題の原因として、
時間が足りない、同僚が無能だ、仕事の分配が不公平だ、と文句をつけるようになります。
睡眠不足により疲れがたまり、ジャンクフードとカフェインのせいでかなり不健康な状態になっています。
自分を情けなく思うと同時に、まわりは自分のつらい状況を理解してくれない、と感じます。
他人に向かってわめいたり手をあげたりするようになり、
口喧嘩をしかけることが増え、謝罪することに抵抗を感じるようになります。
生きることがつらいと感じるようになります。
他人との接触や人付き合いを最低限に抑え、
燃え尽きが進行していくという感覚をやわらげることが重要になってきます。
酒を飲むこと、あるいは薬に頼ってストレスを解消しようとします。
何に頼るかはそれぞれですが、通常よりも深くそれにのめり込みはじめ、危険な兆候が出はじめます。
友人、家族、同僚からみて明らかにおかしな奇行をするようになります。
本来のその人でなくなったということが、近しい人の目にはっきりと分かります。
身体的に疲れ果て、頭痛、肌荒れ、意欲の低下など健康上の問題が生じます。
対人関係にプレッシャーを感じ、とくに深夜、鬱が強くなります。
自分の人生が、機械的で感情のない歯車の連続のように感じられます。
自分の価値を誇示したいという願いも弱くなり、諦めてもいいかと思うようになります。
より頻繁に酒、薬、過食、異常性欲、その他の奇行、破壊衝動などに逃げ込むようになります。
鬱がさらに進行します。
この段階では、失望感、喪失感、消耗感を感じ、将来を楽観視する理由をほとんど見出せなくなります。
http://plusd.itmedia.co.jp/mobile/articles/1112/27/news054.html
NTTドコモが12月27日、富士通、富士通セミコンダクター、日本電気、パナソニック モバイルコミュニケーションズ、Samsung Electronicsと共同で通信機器向けの半導体を開発・販売する合弁会社を設立する契約を締結した。
新会社の設立は2012年3月下旬の予定で、各社の出資比率などは未定。これに先立ち、ドコモが2012年1月中旬に準備会社「通信20+ 件プラットフォーム企画」を設立する。出資金は4.5億円で、ドコモが全額出資する。代表取締役社長はドコモ20+ 件の取締役常務執行役員 研究開発センター所長の小森光修氏が就任する予定だ。
ドコモ、富士通、NEC、パナソニック・モバイルコミュニケーションズの4社は、2009年にLTE通信プラットフォーム「LTE-PF」を開発しているが、今回の枠組みはここにSamsung Electronicsが加わった形となっている。
合弁会社では、各社の通信技術、ソフトウェア技術、半導体製造能力や設計の経験、ノウハウなどを集約して省電力かつ小型の半導体を目指す。高性能化が進むスマートフォン向けプロセッサの開発が中心になるとみられる。高速通信規格LTE（ドコモ20+ 件の「Xi」など）をサポートするのはもちろん、LTE-Advancedへの対応も検討する。
参考: 一昨年の、ルネサスがノキアの通信技術を買ったときの記事。
http://k-tai.impress.co.jp/docs/interview/20100727_383525.html
せっかくルネサスがクアルコムと戦うためにノキアから通信技術を買っても、元・親会社が三星に技術提供って。反韓流どうのこうの言っている人は、きちんとこれをたたいて下さい。文化なんかよりも、もっと金を奪われる提携です。
年末のモデルで、日本のメーカーはスマートフォンが上手に作れないことが明らかになりました。遅かれ早かれケータイからは撤退することになるでしょう。結局、こんな半導体を作ったところで、日本のメーカーは使うことができず、サムスンを利することにしかなりません。
ドコモのユーザーも声を上げるべき。月々払っているお金が、自分が使いもしない端末・技術に投入されるというのはおかしくないですか？ ドコモは土管商売に留まりたくなくって、技術で引っ張っていきたい、のだろうなと思います。『iモード』もう一度、という。
けれど、スマートフォンが半導体を含めて世界共通のデザインになり、かつ、その恩恵で値段も下がる、という路線が見えているのに、消費者として独自技術（通称ガラパゴス）を応援する理由はないはずです。「日本のケータイ屋さんは大変だなあー、でも僕・私はiPhoneがあればいいや（画面をなでなで）」な人が大多数なので。
個人的には韓国の会社よりも台湾の会社のほうがビジネス戦略的にいいような気がします。例えばこの提携が、サムスンではなくて半導体専業のMediaTekだったら、慧眼を褒め称えたのですけれども。
[コピぺの出典]から[コピペ誕生の瞬間]へカテゴリーを変更した。
178 名前： WBC監督(東京都)[] 投稿日：2008/09/14(日) 22:30:48.60 ID:mNrtA2B90
深夜のメンテナンス作業で眠くて眠くて、ユーザーの伝票明細テーブルを間違ってTRUNCATEした。
ROLLBACKも効かない。
あせってArcserve開いてテーブルを戻そうとする・・・ログウィンドウを見ると、
頭が真っ白になった。
IDCを出て深夜の自席に戻って、机の中の大事なものをかきあつめてかばんに詰めた。
保険証、パスポート、前の年に死んだ愛犬の写真を持ち、始発にあわせて家を出る。
携帯が鳴り始める。何度も何度も何度も。空港につくころには着信が１００回を超えた。
逃げるなら、なんとなく北、というイメージがあった。
それから３年無為な生活をし、ほとぼりが冷めたころ、北海道の小さな
そして、孫請けながら大きなプロジェクトに参加することになり、
・・・会議室には、俺が逃げ出した会社の部長と、課長がいた・・・
ふたりとも、会議のあいだずっと、顔を真っ赤にして俺を睨んでいた・・・
どうにもこうにも親が機械の操作について、同じ事を何度も聞いてくることに苛立ってしまったからだ。
機械といっても、車のシフトチェンジなど分からなければできない操作ではなく、ディスプレイに専門用語ではない用語で丁寧に表示されている操作を、逐一毎回聞いてくるからだ。
おまえは日本語が読めないかと最初はバカにしていたが、話を聞くうちにそうではないということがわかった。
どうも失敗することができない操作と失敗してもリカバリーできる操作の区別がつかないらしい。
PCやAV系は失敗できない操作は普通最終確認をしてくることは、使える人はわかっているから、初めて使うソフトウェアやWEBサービス等を使うことが出来る。
その取り敢えず画面に従ってみるということが出来ないようだ。つまり表示を信用していない、いや信用できるか判別できない。
なんか聞いたことがある話かと思ったら、そうだ赤ちゃんのことだと気がついた。
赤ちゃんはチャレンジャーでなんでも真似してしまう。身体的に不可能なことでも、リカバリー出来ないことでも。
この場合、その模倣相手は画面表示だが、リカバリー不可能な操作をしてしまうことを恐れて逐一聞いてくるようだ。
ただ、赤ちゃんは親が見張ってくれるように、一般的にリカバリー不可能な操作は画面で警告してくれる。
まずはそこを教えるべきだったと反省している。
まとめ
第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 練習問題
試験工程が始まり、新規参画メンバーに、ドキュメント与えて試験やらせても得られるアウトプットは、所詮ドキュメント通りにできているかが確認できるレベル。
リリース後にぼろぼろの品質の状態で、なんで試験でちゃんと見つけられないだと言われたとしても、設計通りのものが作成されているにすぎない。
試験メンバーに対して要件／仕様の説明／プロジェクトの前提条件の暗黙知を共有させる準備期間が必要であるはずだが、
そんな意識はまわりにない
組織のプロジェクトの共有意識のなさ、ソフトウェア全体に対してどうあるべきかを考える人が誰もいない状態に対して誰も疑問に感じない。
感じているかもしれないが、各論ばかり論じてお茶を濁している。
開発ツールによってプロジェクトの生産性向上をもくろんでいるはずが、開発ツールの設計が全く生産的でない。
バグ票も、試験の前提条件／試験方法／期待値も記載されず、ただ事象だけ書かれている。
それに対しても開発チームの回答も改修したレベルの記載で、原因／対応／横並びもなく、
開発チームの回答に対してプロジェクト全体として妥当であるかの判断も誰もしない
組織の人員配置／プロジェクトのあり方の不備をただ個人に押し付ける
ただただばからしい
出遅れという言葉じゃ済まないほど今更だけど、レイプエロゲー問題について考えた。
12歳前後の女子学童が通勤電車に乗っている。後をつけていた男が彼女の体に触り、彼女に性的いたずらを試みる。やっとのことで電車は停まり、恐れをなした彼女は公衆トイレに駆け込むも、追って来た襲撃者は彼女の腕を縛り、レイプする。襲撃者は彼女を監禁し、様々な状況下で彼女を何度もレイプする。彼女の母親と、10代の姉妹もまた同じ運命をたどる。この一家は以前、かつてこのレイピストが別の女性に対して性犯罪を図った件について、姉妹の姉が警察に通報したことにより、その報復としてレイプの標的とされたのである。
以上が、イリュージョン・ソフトウェアが開発したレイプ・シミュレーター・ゲーム「レイプレイ」のあらすじである。このゲームは日本で販売され、Amazonでも取り扱われている。
http://fragments.g.hatena.ne.jp/yuuboku/20090508/1241760087
まあ、酷い話だよなとは思う。
ただ、女性から無視・嫌悪されてきた男性たちへの慰めとして、こういった性差別的フィクションの存在は必要なのではないかとも思う。
と、なぜか彼女は信じて疑わなかったという。
体が大きく、早熟な彼が姉たちに手を出すことを心配した彼女は、まだ幼いケンパーの部屋を地下室に移した。
ケンパーはこのじめじめした牢獄のような、窓ひとつない場所におびえ、なんでもするから二階の子供部屋に戻して、と嘆願した。だがこれは聞き入れられなかった。
彼はこの地下室で悪夢にうなされ、暗い妄想にふけった。ＴＶもラジオもなく、窓すらないこの部屋では外的刺激などまったくなく、彼は内なる妄想でみずからを慰めるよりほかなかったのだ。
彼の両親は彼がものごころついたときから、すでに不仲だった。母親は体格がいいだけでなく、ケンパーを産んだだけあって頭の回転が速く、とくに舌鋒の鋭さは無類であった。
そして真夜中、眠っている彼女をハンマーで殴り、ナイフで喉をかき切った。それから「もう二度と悪態がつけないよう」喉頭を切り取って、ディスポーザーで粉々にした。そして首を切断した。
首を失った体は、いつものようにもう「母」ではなく「女体」だったので躊躇なく犯した。首のほうはダーツの的にし、罵声を浴びせながらサンドバッグ状に殴った。
http://www8.ocn.ne.jp/~moonston/kemper.htm
こういった、被支配者が支配者を惨殺する復讐劇に私はカタルシスを得る。
特に、口が達者な親によって子が洗脳状態に置かれていたが、洗脳が解けた子が親を惨殺するストーリーが好きだ。
これは私的な体験から来ている願望なのであろうと思う。
対象から逃げるだけだった私は、理想の姿として復讐ストーリーを欲し、消費している。
今回Equality Nowが提示した問題点は、そのような「わいせつ」という概念に基づく物ではありませんでした。Equality Nowは、今回のエロゲ―を批判するときに、非難されるべき点として、次のような表現を使います。
これらにおいて問題となるのは、それが「わいせつ」であるかどうかではなく、それが「女性に対する暴力」を維持するようなものであるかどうかなのです。今回のようなレイプゲームが問題となったのは、それが性的なものであるからではなく、女性に対する差別を維持するものであるからなのです。
http://d.hatena.ne.jp/amamako/20090520/1242764989
子による親への復讐ストーリーを必要とする私のように、性差別ファンタジーを必要としている男性がいるのではないか。
女性たちに無視され、嫌悪され、排斥されてきた男性たちにとって、
女性たちを性差別し暴力を振るう理想的なストーリーは救いになるのではないか。
虐待していた親が改心し子に謝罪して、子がスムーズにそれを許し、全てが上手くいくようになる例が非常にまれなように、
女性から嫌悪されてきたある男性の前に女神のような女性があらわれ、その男性を無条件に愛し、
男性の内にあった女性への全ての屈折や憎悪が消えてなくなり上手くいくという例も非常にまれで、期待するだけ無駄な話だ。
被害者意識に苦しんでいる状態から一時的に救ってくれるのは、後ろ向きな復讐ストーリーだけかもしれない。
私は必要悪としてそういった性差別ファンタジーの存在を認めたい。
ただし性差別ファンタジーの消費者と関わりたいかといったら全く別の話で、当然、できるだけ関わりたくない。私は女神ではない。
過去数日間にわたって放出の3つのレポートは、GoogleのAndroid OSは、現在のマルウェアの主要な標的であることを主張して...あなたが心配ですか？
http://www.bcpowerbattery.co.uk/bc-sony-digital-camera-battery.htm
だから、解決策は何ですか？私は3つの可能な解決策を参照してください。
GoogleはAndroidマーケットをクリーンアップし、ユーザに安全なもの（これは、マルウェアが寄生かもしれない"別の"マーケットプレースからユーザーを保護することはありません）
他の会社が介入し、彼ら自身からユーザーを保護するソフトウェアを提供
http://www.iibattery.com/nikon-digital-camera-battery-iigl.html
・文章が打ちづらくない？
ただし、Androidはソフトウェアキーボードの実装が機種依存だから
打ちにくい 機種も存在している。打ちにくい機種は本当に打ちにくい。
ただ、AndroidはDPIもフォントも機種依存だから見辛い端末はみずらい
・スクロールやらクリックやら、マウス操作にあたる操作が面倒じゃない？
クソな端末は本当にクソ
古いやつはガラケーのほうが早い。
結論から英馬、ガリガリ打ち込む作業についてはノートPCのほうが断然いいけど
スマホユーザーの大半は電車の中でちょっと読むとかだろうから、問題ないだろ。
ただ、最新のどっかのスマホがバグだして販売中止？になってるみたいだけど
そんな感じで端末によってキーボードも液晶の品質も結構色々違う。スマホとおもって買うと有名メーカーでも
痛い目見ることがある。
要するに、ソーシャルがうんたらかんたらという話は所詮は一過性のブームで、そのうちゲーム専用機への回帰が始まるよって話。
でもって、アプリケーション開発の中でもゲームソフト開発はかなり特殊なので、一朝一夕でどうにかなるわけじゃないから、この業界でゲームで真剣に生き残りたければ今のうちに準備しといた方がいいよ、みたいな。
つまりスマフォは、「いつでも遊べる」というカードのみで、今後ゲーム専用機と戦い続けなければならないことになる。携帯ゲーム専用機に関してはそれさえもカードとしては強力とは言いがたい。
しかしそんな不毛な戦いを挑むゲームソフトメーカーなど現れないだろうから、ゲーム専用機とは別のカテゴリの娯楽として存在することになるだろう。それは既存のゲーム専用機の領域を「多少は」食うだろうが、果物にたとえるならば皮の部分程度で、芯に到達することはないはずだ。
AppleにとってもGoogleにとっても、ゲーム機能は自社製品を普及させるための付加価値の一部でしかない。だから万が一ゲーム部分と他の付加価値が競合する事態になった場合、前者を優先することは絶対にありえない。対するゲーム専用機メーカーは、自社製品をゲーム機として普及させるためにあらゆる選択肢を模索するだろう。高価すぎるという批判に対応するためにPS2ソフトの互換機能をオミットしたPS3の例や、販売不振を挽回すべく発売からわずか半年で1万円の値下げ(実質4割引)を実行したニンテンドー3DSといった事例もある。
そもそも、「何でも出来る」がうたい文句のハードやOSが、ゲーム専用機にゲーム分野で太刀打ちできるはずがない。
それは「何でも出来る」はずのWindowsのゲーム分野で主導的なポジションを作り上げながら、その市場の小ささゆえにわざわざゲーム機を発売したマイクロソフトが証明してくれている。
WindowsがインストールされているPCなど、世界中に何億台、下手をすれば十億台以上は存在しているはずなのに、ゲームソフトの売上や販売本数ではゲーム機に完全に負けてしまっているのだから。
これらが今後のスマートフォンにも当てはまることは自明だろう。
といったものがある。
発達障害は怖いなぁ。
発達障害の人って、周り中がシャーロック・ホームズとマイクロフトばかりの世界に紛れ込んだトロいワトスン君みたいな気分？
「遠回しな表現を理解できません」「否定的な言葉かけに過剰反応します」” こんな人が職場に来たら… 迷惑。迷惑。
発達障害者恐るべし
「誰か、あるいは何かに対して、強い恨みを持っていることはありませんか？」の問いには、「ある」と答えた人は112人。全体の33.9％に上った" 恐るべし。
「俺は発達障害だった」... だって。近年は単にちょっと頭が悪い程度の事にまで病名っぽい大仰な名前が付くのか。
福祉大国スウェーデンにおいては、発達障害含む精神病患者は、犯罪を犯す前から全員政府の監視下に置かれていると聞く。
教え子に乱暴、「嫌がらないと思った」と元教諭 - MSN産経... "奥田哲也裁判長は、被告に広汎性発達障害の傾向があるとする弁護側の犯罪心理鑑定書などを証拠採用した。" 広汎性発達障害者恐るべし
知障は幼女への性犯罪多いそうだしな。予備拘束すべきかもな。発達障害もヤバげじゃね？予備拘束だな。
広範性発達障害人間というのは刑務所に入れた方が治るのか少年院に入れた方が治るのか、どっちなんだろう。
出生前の脳の異常である故、改心の見込みは皆無、我々健常者に出来る事は、力関係に応じて逃げるか追い出すのみ。
町田・高１殺害事件、元同級生の少年に２審も懲役１１年 : ... 発達障害は怖いなぁ。
所詮は知障の一種に過ぎぬと。
只の我侭で能無し嫌な奴。
異常者恐るべし。
ところで健常者の事を定型発達者と表記すると、あたかもこれは機能不全ではなく只単にタイプが違うだけの互角並列同格の関係であるかのような誤解を与えかねない。
アスペルガー症候群とハッカー：中年での診断が増加 | WIRED... こんなのが我々健常者の間に何食わぬ顔で紛れ込んでいるのか…
おいおいIT業界も他人の気持ちを推し量るの結構重要。偏見の助長は如何なものか。向いてるのは「芸術家」とかにしといて。ちなみに特定の分野に於いても秀でた能力を持っていない人の方が多いんじゃね？
頭脳労働は向かない奴だったなぁ。思い出すだに腹立たしいあの薄馬鹿は。
アスペルガー社会人のBlog : 何故こんなことしたの？ ← 馬鹿と働かざるを得ない上司は大変だなぁ。常人なら１分の説明で判る事を３０分説明させられたり。しかも往々にして判ってなかったり。/いや、原因が何であれ馬鹿は馬鹿。
広がりを見せる自閉症者ソフトウェアテスター育成プログラム... ”現在、同社の収入の60%は寄付によるもので、売り上げは40%に過ぎない” ← やっぱ使いものにならない模様。
お父さんの[そらまめ式]自閉症療育: 今般のトラブルについて... ← 自閉症は怖いなぁ。絶対に関わりあいにならないようにしないと。
常時ゼッケンつけるのはどうだろう。黄色地に黒で「単鬱」「統失」「自閉」とか。私なら見かけたら道を譲る等の配慮をする。10m離れて