 
|
はてなキーワード: ファイルとは
うちの部署は会社の売り上げの7割を占める重要製品を作ってる。
売り上げも最大の部署であり、人員数も最大の部署。
うちのトラブルは会社全体の売り上げを左右するわけで、上司はしょっちゅう呼び出しをくらって、だいぶやられてかえってくる。
口には一言もださないが、いつもやられてる感が漂ってる。
そう、上司はとても無口。
会社で発する肉声のうちの、約半分がため息だと思う。
出世頭といっていい。
いっけん無愛想そうに見えるが、とても腰がひけた人で、入ったばかりの派遣さんに席を奪われていると(しょっちゅう会議で呼ばれているので席が空いていることが多い)、席に戻れず部屋の隅っこで資料をファイルに閉じたりコピーをとったりしてしてる。
「やべっ怒られる。でも遅れてるのは俺のせいじゃないんだぜ～勘弁してくれよ…」
と思って開いてみると
「上手くいかない事ばかりで大変でしょうけど、頑張ってください」
(´;ω;`)ﾌﾞﾜｯ
なんでも、今のポストにいるのは、前のトップだった人間が従順で丸投げしやすいからという理由で開発から彼を引っこ抜いてきたらしい。
とお読みの皆さんは思うかもしれない。
でもね、愛されてるんだな。
みんな喜んで従うんだわ。
（ポスト上無理だが）本当は現場で組立作業をしてたりするほうが好きということは皆に知れ渡っているので、現場から好かれてる。
若くてそうとう出世してしまっているが、誠実で真面目な態度は年配からも嫌われていない。
そんで、普段あんなにクールなのに、酒を飲ませると誰より弾けるのが愛される秘密だ。
あんなに無口なのに、ため息くらいしか言葉を発さないのに、KARAを踊りだしたりするんですよ？
最高っすよ。
自分用メモも兼ねて。いや、最近なんか周りでなんとも抑うつっぽい人が散見されるようになってきたように感じられるのでふと考えることが多くなった。「とりあえず前向きに」は理想としてはほんとそのとおりなんだけど、いやできないから凹んでるわけであってね。というのも自分も社会生活に支障は無いまでもちょっときつかった時期があったりしたんだよね。なんかこう上手くいかんという時にわずかでも参考になればと。
以下自分の思う改善法を適当に並べて書くけどツッコミ等あれば是非忌憚なく書いてってくれれば
・スポーツする
スポーツするのはすごく効くと強く感じる。じっさい脳内に多幸感物質的なのがでていいらしいね本当に。そういえば体育会だったり普段から運動してる人でうつっぽい人っていなくない？（無口とかおとなしい人ってのは別でね。笑）それって結局これにつながるところだと思うんだよね。まあ脳内から作用するんならそりゃ自然に効くここまでいい薬はないわなと。
で、スポーツの中でも個人的には集団でやるやつ、例えば野球、サッカー、バスケとかとかをあまり競争的にならずにやるのがいいと思ってるんだ。というのも下の話にも関連するんだけど人とあって話すのはすごい凹んでるのを改善するのにいい。特に非競争的にみんなでわいわい談笑しながらでなんかだと本当に効果てきめんだと個人的にも思ったわ。あんまり試合の結果に一喜一憂するのがいいとも思わんしね。（まあ個人差あるかもだけど笑）
水泳とかジョギングとかでもいいとは思う。ただ、ジョギングとか取り入れてみて思ったけどどうにも変化がなかったりすると飽きたりするからそこらへんは要工夫だし、人の輪にいるってのがすごい重要だと思ってるからよりオススメは集団スポーツ。でも個人スポーツも全然OKってスタンス。
・人と会って喋る
これも超重要。や、もう本当になんでもいいんだよね。単純に失恋とか仕事うまく行かなくて悩んでるならそれを聞いてもらうでもいいし、あえて全然関係ない趣味に花咲かせるのでもいいと思う。個人的には仕事なり実際的な解決方法が欲しい時は人の話を参考にするのもいいかなとは思うけど、基本的にどうにもならない人間関係のこととかはもう全く別の話して気を紛らわすのがいいんじゃないかなと思うことが多いのかなとは思ってる。例えば恋人関係で悩んでる時に共通の知人にいろいろ聞いてもらうよりは、全く関係ない人にその相談みたいなのはもちかけずに自分の好きな趣味、音楽映画なり漫画でもなんでもいいけど、の話をしてわーって盛り上がったときのほうが気持ち的には晴れやかなことが多いのかなっては思う。まあこのへんはいろいろケースにはよるかなとは思うけど気の置けない友達とただ話して笑ってみるだけで全然違うっすほんと。
・陽の光を浴びる
これも効く。よく本とかに書いてあることだったりはするんだけどね。メラトニン（だっけ）とかってのが日に浴びることで生成されていろいろポジティブな効果を生むっていう。これも具体的に南国の人とかのうつ率の低さ（ってかほとんどいないんじゃね？笑）をかんがえたらなんとなく納得する話なのかなと。自分も少し取り入れてみたけど朝に一日の段取りでもぼーっと考えながら2,30分散歩してみるだけでもホント違うよ。これなんかは習慣にすべきだと思う。忙しいと30分とかの時間生み出すの大変かもなんだけど、まわりまわって効率良くなって全体のパフォーマンスよくなってるの感じるわ。
・早寝早起きする
これも上に関連。特に日の出てる時にしっかり生活をするのが重要。これ見てる人なんかはパソコン好きが多いだろうからついついモニターの前で夜更かししちゃう、みたいなことありますよね。僕もすごくよくあるのでわかる。笑 でもやっぱり早起きしたらその分有効に使える時間は増えるし、上記の日を浴びられる時間が伸びる。逆に、夜更かししてネットやりながらだらだらしてると無駄な後ろ向きな思索とかがやたら増えてかなりジャンクなブラウジングしてる自分に気づいてなんとなく鬱屈としてくる、また生活時間がズレこんでの悪いサイクルが生まれると思うんだ。だからなんとか朝、人と会う予定をいろいろ入れてみたりして、生活習慣を改善してみよう。特に夜更かしをしないってのが重要かなとは思います経験上。
・家事とかをしっかりしてみる
は？って感じかもしれんけど小さいながら書いとく。これ結局小さい成功体験の積み重ねに相当するのあかなと。普段面倒だったり忙しかったりして掃除選択皿洗いから細やかな管理なり色々後回しになってたりしない？そういうのをちょっと重い腰を上げてやってみよう。掃除なんかはほんと終わったらすっきりするよ。週ごとにホコリ一掃キャンペーン（一人で）をやってもいいくらいだ。笑 本棚の整理、パソコンのファイル整理でも靴磨くのでもどんな小さなことでもいい。無言で集中してるうちに日常の些事なんか薄らいじゃってうことってよくあるよ！
・ネット断ちをしてみる
最後にネットヘビーユーザは特に。前述のごとくここ見る人なんて大分ネットに慣れ親しんだ人だろう。最近なんかはネット疲れなんてのが言われるくらいだからなあ…いるでしょ？気付いたらTwitter開いてるみたいな人？笑 自分も大分そっち側だからよく分かるんだよ。
でもそれあんまよくない。特にネット一日に数時間もやってる（それこそねらー的な人達が自嘲的に言ってるような人種の人は）一日でもいいから全くネット触らずに外ぶらぶらしてみる時間をとったり、鈍行でふと何か見に行けばいいと思う。これ本当に違うんだよ。割と自分も一日にネットとんでもない時間触れてる時があったんだけど、これってなんかこう、そのまま惰性で続けちゃうじゃん？それをこうアウトドアなのをふと入れてみるとそのネットやってる時間自体の充実度もだいぶ違ったりするから不思議なもんだ。インドアな人には効果てきめんだし、最近よくいう引きこもり気味でネガティブになってる人にはよく効くと思うので是非。
ざっと思いつくままに書いてみたけど、うつ改善のために精神科の先生が書いてるのいくつか読んだりWEBで読んだのうろ覚えであったりするのと、自分の経験則的なものを合わせた感じだとこんな感じだ。特に自分がおすすめするのはスポーツと人と話すことかな。もちろん時間が必要なことではあるので大変かとはおもうけどやっぱりこう人と交流しながらってのが一番効果的だとは思う。そんな友達がいないんだよ！笑 みたいな人はネットでオフみたいなの探せば何かしら機会はあるはず、同じような悩みだったり考えしてる人って世の中思いのほか多かったりするよ！
以上とりあえずそんなかんじで、是非参考になれば！
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
ソフトウェア開発プロジェクト（一定規模以上）がトラブルが起こって納期までに終わりそうにない、赤字が出てでも終わらせないと困る時の別解
色々な方法があるんだけど、その中でもなぜかこういう方法をとるところが案外少ないように思われるので…。この方法はもちろん万能じゃないので、「こんな欠点がある」って突っ込みはいっぱいあるでしょうが、「いついかなる時でも使えない」話ではないレベルです。
・増員する、ただし、雑用係専用部隊を大幅に。
→業務メインをやる人が増えるとコミュニケーションコストが増大してかえって遅延する現象は散見されますので、そういうコストが相対的に起きにくい仕事になるべく人を投入するという発想です。
ただ、これは、「低時給バイトさん」「事務職」ではだめです（チームの中にそういう人を入れるのはいい場合も多々ありますが、「低時給バイトさん」「事務職」ばかりを多数入れてもソフトウェア開発では大抵困ります。つまり、PG/SEレベルの、ソフトウェア開発の一般常識のある単価の高い人を敢えて雑用や事務に投入するんです。これの一つのデメリットはSE/PGにそんな仕事をさせるとモチベーションが下がって当然なので、長期には向きません。プロジェクトが長いなら少しずつメンバーを入れ替えながらがベターかと。
例）「このデータ加工しといて」と振ってExcelベース（関数とかVBAは使えてよ）なりスクリプト言語なりで加工する人
例）コピーを頼まれたらそれに徹する人 …ここだけ見ると単価高い人をそんな仕事に、と思うかもしれませんが、変にチームに投入して遅延を拡大させるのとどっちがいいんですかって話ですよ。
議事メモではなく議事録が必要なら、録音してテープ起こしするのの草稿を別の人がやる（ここ例えメインの仕事に入ってなくともSE/PGかどうかで品質が随分違う。もっというと、草稿の草稿は音声認識ソフトにやらせる手もある 録音レベルが悪いときついけど）…これは普通のプロジェクトでやってもまずコスト的に割が合わないでしょう。あくまでここに書いているのはすべて「赤字が出てでも早く終わらせる」みたいな特殊な状況なのでやってみるといい場合があるんじゃないの、というお話です。
例）必ずしも雑用ではないが、特にキーマンには秘書をつけてしまえ。その人のスケジュール管理から色々とね。秘書検定もってるエンジニアとかいたら最高ですが（どんだけおるんや） この人に用事があるんだけど今取り込み中…みたいな時って用事がすんでからタイムリーにってなかなかいかないんですよね。秘書がいたらなんとかできませんかね？
人を横断して作業効率化を図れる書類の自動化とか可能なら専任作ってExcel VBAでもスクリプト言語でもなんでもいいので作ってしまえ。
・アメニティの充実を図る。
機材のせいでボトルネックになってませんか？PCの性能は大丈夫ですか？ディスプレイは大きいですか？プリンタやコピー機の数は足りてますか？プリンタやコピー機の速度は十分ですか？カラー印刷出来ますか？ファイル共有サーバが遅かったりしませんか？ ※PCを変更すると環境移行コストはかかりますが、一時的なものです。
事務専門でも出来る所では「コピー用紙がなくなってから補充までにタイムラグとかないですよね」とか
ポットに沸かしたお湯が空っぽとかないですよね？ …まぁこれはエンジニアじゃない人に任せてもいい領域。
ホワイトボードに書いたものを電子データでPCに送れるとかいまどき常識ですよね？丁寧に書いてあったらOCRも可能ですよね？
経費で、高いのでいいからうまい弁当をオフィス配達してしまえ ※税金の問題等色々あるし、自分で選んだり外食に行く方が効率上がる人もいるので全員ってわけにはいかないんですけど。希望者だけでも。
赤字覚悟で増員してるのに、人を増やしたけど「予算がないからPCにいいのが調達できなくって」って話は実在するようですが、何かおかしくないですか？
1人月60万とか100万とか何人も入れるのに。会計上の問題とか壁があるので表面的な金額では決められないんですけど、でもおかしくないですか？
あ、上記のようなことを実際にやって酷い目にあったエピソードがあったら教えてください。「うまくいかない場面」なんて当然いくらでもあると思うので。
Web上を探しても情報が見つからなかったので、ここにメモしていきます。
FireFoxやChromeな皆さんは、Operaをインストールしてからまた来てね♪
＜手順＞
1. このページの一番上にある増田の検索窓を右クリックし、検索エンジンの作成を選びます。
2. 名前に「英辞郎」、アドレスに「http://eow.alc.co.jp/%s」と入力。キーワードはお好きなもので。
4. おしまい。
英辞郎はなぜか右クリックから直接登録できないので、自分でアドレスを入力して追加しなくちゃいけません。
この時、検索エンジンの編集で新規に追加すると文字コードがiso-2022-jpで登録されるんですが、異なる文字コードを使っているサイトに対応させるにはsearch.iniっていう設定ファイルの該当部分をちょこっと直してあげなきゃいけません。（ちなみに英辞郎はUTF-8。）
設定ファイル探して、テキストエディタ開いて…ってのはちょっとした手間です。
だったら文字コードが一緒の所で先にダミーを作ってあげて、アドレスだけ直した方が手っ取り早いよね、ってことです。
文字コードがUTF-8の所であればどこでも同じように登録できます。Google翻訳やニコニコ動画でもOK。
ちなみにDMM.R18は違いました…。
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
・ 登場人物がやたら多い。
１ページか、二ページそこらで、登場人物がやたら出てくる。本人の中ではしっかりとキャラクターが浮かんでいるのであるが、いざ書きだすとなかなか先に進まない。他人に読ませても「キャラクターの区別がつかない」とか言われる。他人をお話の中にすんなり引き入れるには、多くても主要キャラクターは三人か四人がベストでしょ。
・読み始めて、しばらくしても何についての話なのかよくわからない。
いきなり長編に取り掛かろうとする小説家志望にありがちなパターンである。ずーっと読んでいってもなんだかよく分からない主人公の日常が書かれてあるだけで、いつまでたっても事件が起きないのだ。セントラルクエスチョン（主人公は○○できるのか？）を提示するのが遅すぎる。遅くても１０ページまでには何の話なのか提示しないと、読む方はあきてしまう可能性があるのだ。
・登場人物が画一的すぎる
女子高生が出てきたら女子高生の口調、オタクはオタクの口調や行動、ヤンキーはヤンキー、校長が出てきたら校長、婆が出てきたら婆、どれもこれも画一的で、その個人特有の人物造形ができていないのだ。女子高生だったらこんなことはしないだろうとか、ヤンキーはこんなこと言わないだろうかとか考えず、こいつ自身はどう動くかを考えるべき。
主人公が不安だと思ったときに、そのまま言葉で私は不安だと表現するのは簡単。
そうじゃなく描写で表すほうがいい。不安なら、「私の進む先に暗く淀んだ雲が漂っていた」これだけでいい。
・敵の底が浅い
これは、ダメな映画、小説、漫画すべてに言えるが、敵または悪役の底が浅すぎる。みんな似たり寄ったり、同じような口調や行動でありきたりこの上ない。書き手が主人公ばっかりに気持ちが入っていて、陰と陽の配分がなされていないのだ（不思議と悪役の存在感が薄い小説は、主人公も同じく薄いことが多い）
悪役を描くときは、どうせなら主人公より悪役の方に肩入れしてしまうくらい入念に丹精込めて造型しないと、濃密な戦いは生まれないぞ。主人公以上に、なにか独特の倫理観や、哲学を持ってないと魅力は出てこない。<リンク:共犯者 (新潮クライムファイル)>共犯者の関根元を見習ってくれ。
・退屈な生活をおくる主人公のもとに、都合良く謎の美少女が現れる。
導入で、ここまでうんざりさせられる展開は他にない。冒頭に退屈した主人公の日常が延々と描かれ、突如としてその生活に舞い降りた謎の美少女。これがラブストーリーとかになったりしたらもう最悪…。導入としてはすごくわかりやすくて、お話も運びやすいのはわかるがもう一つ何かひとひねりちょうだい！
自分の中に溜まった抽象的な[何か」を表現しました、と言う小説はたいがい、つまらない。こういう小説は冒頭にかならず自意識を垂れ流したような文章が長々と続き、ちょっと書いている本人が陶酔している。こういうのを描くのは、玄人向けというか、並外れた文章表現と客観性がないとなかなかうまくいかないのよ。最近芥川賞とった「きことわ」ぐらいのレベルなら別だけど。
なんかさらーっとしてて、自然とかそういう情景描写ばっかりの小説ってあるよね。たぶん自分の中では美しい情景が思い描けてると思うんだよ。でも他人ってそんなにあなたが感動したことに共感はしてくれないんだよ。よくありがちなのが自然と人間の死を対比させているパターンね。
・文章もテーマも立派なんだけど、全体的に大したことが起こらない、地味。
こういう小説が一番多い。文章もプロ並み、テーマも素晴らしい、でも地味なんだよってやつ。こういう人はとことん地味な話を書くべか、または自分が普段全く読まないような超エンタメ小説や劇薬小説などを買いあさって読んで、一度頭をフルチェンジしてみるのが一番ベストである。
・文章もテーマも立派だし、起こっていることもまぁまぁなんだけど、モチーフがありきたりで既視感がある。
そこらへんに転がってるような話だけじゃ駄目なんだよな。
海外の古い短編なんか読むと、こんなんでいいの！？って思うくらいシンプルなのもあるけど。それは昔の時代だから通用しただけのことであって、今の時代は「ひねり」をどんどん入れて、読者の意表をつかないと、すぐにあきられてしまう。じゃあ二転三転すればいいのかっていうとそういうわけでもないんだけど、読者を驚かせてやろうってぐらいのサービス精神がほしい。
初めてリーダーを任されたプロジェクトが成功したことで、私は会社を辞める事を考え始めた。
もちろん、以前のように仕事が辛くて辞めたいと思ったわけではなく、
全力で仕事をした結果、私ができることはやり尽くしたと思ったからだった。
医療のSEは激務で、女が長く続けていけるような仕事ではなかった。
こんな生活を続けていたら、いつか体を壊すだろうと思っていた。
どうしても一人暮らしがしたくて、わざわざ東京の大学を受けた。
就職する時地元に戻ろうかと思っていたけれど、まだ少し東京に未練があって
でも地元を離れて時間が経ち、帰りたいという気持ちが強くなっていた。
そんな思いもあり、転職活動を始めた。
活動を始めて1ヶ月、あっさり内定をもらった。
東京の会社ではあったものの、タイミング的に新年度を新しい会社で迎える事ができ、
また、思ってもない程の好待遇。仕事の内容も興味があり、それまでの経験も十分に生かせるものだった。
でも、どうしても会社を辞めるという決心がつかなかった。
5年間勤めた会社。そう簡単に辞められるわけもない。
でも、それだけではなかった。
それを見る事で、彼がそこにいるような、見守られているような気がしていた。
それらをもう見る事ができなくなる。
そう思うと、辞めるという決断がどうしてもできなかった。
最初に内定をもらった会社は辞退し、その後も悩みつつ転職活動は続けた。
これで地元に帰れる。妹や友達にも相談し、その会社に入社しようとほぼ決めた。
そして会社を辞める事で、彼のことにけじめをつけようと思った。
彼の事を忘れたいと思った事は一度もなかった。
でも、どこかでけじめをつけなければいけないということはいつも考えていた。
業界最大手であるその会社の内定をもらえるとは、正直思っていなかった。
その会社が、中途はほぼ契約社員でしか採らない事を知っていたので、
更に悩む事になった。
仕事内容や待遇など総合的に考えると、最後に内定をもらった東京の会社が良いのは分かっていた。
でも、地元に帰りたいという気持ちも強かった。どちらかに決める事ができず、悩み続けた。
回答期限を何度も延ばしてもらった。
最終的には、東京の会社から、希望があれば数年以内に地元への転勤も可能という話を聞いて、入社を決めた。
会社に未練が全くないわけではなかった。
最後は、その気持ちを半ば強引に断ち切った。
会社の寮に住んでいた私は、辞めるとなれば当然引っ越さなければいけなかった。
就職する時に、寮に入らない荷物を実家に送っていたため、まずはそれを取りに行こうと思った。
車を持っている友達に頼んで一緒に行ってもらおう、と思いつき、例の男友達を思い出した。
以前から、私が引っ越す時は手伝ってね、と言っていた。これもある意味引越しだ。
金曜の夜に出発して、西宮へ向かった。
大好きな街。やっぱり帰りたいという気持ちが出てきてしまい、東京の会社を選んだ事を少し後悔した。
帰ってくるのが数年遅くなっただけ。あと少し、東京でやりたい仕事頑張って、必ず戻ってくる。
自分にそう言い聞かせた。
その日は一緒にホテルに泊まった。
こいつ一応彼女いるのにいいのかよ。。とは思ったが、お互い全く異性という認識がなく、
一晩一緒に過ごしたところでどうこうなるなんて考えられなかった。
その日は広いベッドで、くっついて寝た。
5年間友達でいて、しょっちゅう一緒に遊びに行ってはいたけれど、あんなに近付いたのは初めてだった。
体温がものすごく気持ちよくて、離れたいとは思わなかった。
帰りの高速で、「私たち恋人同士にはなれないけど、夫婦にだったらなれそうだよねー」
という話をした。昔から、私たちはよく似ていた。食べ物の好みは見事に一致していたし、
何故か同じタイミングで同じことを考えていたり、相手が考えている事が分かったりする事が多かった。
「でも実際結婚したとして、結婚10年目ぐらいの熟年カップルからのスタートだよねー」
「新婚の初々しさなんてきっと皆無だよねー」なんて話をしていた。
あり得ない事だけど、もし本当になったら、きっと幸せだろうなあ、と思っていた。
無事帰宅し、疲れて寝ていたら、その友達から「彼女と別れた」という報告の電話があった。
車の中で「別れるかも」という話はしていたが、まさか本当に別れるとは思わなかった。
そして彼女の愚痴でも聞かされるのかと思ったら、何故か私たち結婚したらどうなるかなぁという話をしていた。
まさかそんなことあり得ない、とお互い分かっていたはずだったけど、そんな話をしているのは楽しかった。
彼を亡くした後、誰も好きにならないと決めていたわけではないけれど、実際誰も好きになる事はなかった。
今後も、誰も好きになることはないのかもしれないな、と思っていた。
そもそも結婚と恋愛は別物だ、と思っていたから、恋愛を飛ばして結婚だけできるなら、それもありだなぁと思った。
夜は沖縄料理屋で飲み、さてこれからどうする？という話になり、どっかのホテルで飲もうということになった。
帰る心配をしなくて済むからいくらでも飲める、という考えからだった。
飲みながらDVDを見た。見終わってベッドに入ると、彼は突然
「結婚しよう。舞といつか生まれてくる子供を、一生愛せる自信あるよ」と言った。
まさか本当にそんな事言われるとは思わなかった。信じられなかった。でも嬉しかった。
この人と一生一緒にいたいと、本気で思った。
そして彼は「んじゃーまぁ、一応付き合っとく？」と言った。
オンライン書店ビーケーワン：死にいたる虚構 国家による低線量放射線の隠蔽 アヒンサー「読んで、知って、考えて」
見逃した方のために…ＮＨＫ 追跡！真相ファイル「低線量被ばく 揺れる国際基準」文字起こし - Togetter
原発稼働のため隠される低線量内部被曝の危険性-ＩＣＲＰ国際基準以下で小児がん倍増 - Bloggers Today - 朝日新聞社（WEBRONZA）
「マンクーゾ報告」と「Ｔ６５Ｄ」 - あだち安人「サスティナビリティ」考
二本松の子ども達 福島 原発 ・放射線 の現場から: マンクーゾ報告
葬られた微量放射線の影響調査報告（新恭） - BLOGOS（ブロゴス）
一度虐殺器官を読んだ人（＝自分）が内容を思い出すためのもの。
第一部
１
死者の国の夢と、そこに現れる死んだ母さん。
２
僕は「濡れ仕事屋（ウェットワークス）」として、二〇一〇年代後半に頻発する内戦をおさめるため、「レイヤーワン」を殺してきた。レイヤーワン――罪の多寡とは無関係に、それを殺すことでもっとも効率的に争いを終結させられる標的。
仕事で殺してきた数多くの（時に罪のない）標的のことは少しも心に留まらないのに、プライベートでの、母に対する医療行為の打ち切りを決断したことで、僕は気を病んでいる。
３
仕事で、二人の標的AとBを殺すように命じられ、異国に入る。標的Bについての情報は、上司から与えられているはずなのだが、それが上司の意図により隠されている。
４
標的Aはその国で虐殺行為を率いていた為に、ぼくの手により暗殺される。
ぼくは標的Aに、なぜそのようなことをしたのかをきくが、彼はしきりに「わからない」と繰り返す。
標的Bはすでにそこにはいなかった。
第二部
１
彼はしばしば「地獄は頭の中にある」と言っていた。
ぼくの父も、かつて自殺したのだった。
標的B――ジョン・ポールを追って、僕らは殺しを繰り返してきた。彼は内戦から内戦へ渡り歩いているようだった。
だが、ぼくらが暮らすアメリカは、「ドミノ・ピザやペイムービーのリピートの平和」か支配し、戦火とは無縁だったのだ。
２
ペンタゴンに召集される。
そこで「ジョン・ポールは軍とは無縁の文人、学者でいる」、「しかし、彼が関わった国は決まって内戦が起こる」と聞かされる。
彼は今度、ヨーロッパに入ったらしい。
ぼくの新たな任務は、チェコで彼を追跡すること。
３
死者の国の夢――「死体は物質にすぎない、生きた人間も」と母さん。
幼少時、僕は家の中で母さんの視線を感じ続けて育った。その視線から逃れるために、「濡れ仕事屋」を始めたのだった。
４
ジョン・ポールと関係を持つらしい女、ルツィアと接触する。チェコ語の講師をしている彼女の生徒として。
ルツィアに、「言語は進化によって獲得された『器官』である」という話を聞かされる。
５
チェコ・プラハで行方をくらませた人間（ジョン・ポールもそうかもしれない）のIDの追跡可能性はゼロらしい。
9･11のテロとの戦い以後、認証を繰り返さなければ買い物も交通機関を利用することもでしないのに。
ルツィア曰く、「ジョン・ポールはもともとMITの学者だったが、いつからかDARPAの研究（ぼくが使う武装、SOPMODを作ったのもDARPA）をするようになった」
６
ルツィアの部屋からの帰り、若者におそわれるが返り討ちにする。おそらくは、ジョン・ポールの協力者。
IDトレースによれば、かつてジョン・ポールとルツィアが密会していたとき、彼の妻子はサラエボで核に吹き飛ばされた。
第三部
１
死者の国の夢――夢の中のプラハでは、例の虐殺が発生していた。
その夢でも、母さんが現れる。
「母さんは意識はなかったけど、内蔵は動いていた。そして、ぼくが医療行為の中断を認証した。
……母さんが死んだのは、ぼくが認証でイエスと言ったときだったんだろうか？」
「あなたは、任務での殺しでは「それは政策が決めたことだ、自分が決めたことじゃない」と、責任の重みから逃れられた。
でも、医療の中断の責任からは逃れられない。あなた自身の決断だから。
……そう思っている。もしくは、中断をする前から私は死んでいたと信じたがっている。
けれど、本当は、私だけじゃなく、あなたがころしてきたすべての人々が、あなたの決断によって死んだ。
私を殺した罪を背負い込めば、あらゆることが帳消しになると思っているの？」
２
夢の虐殺後の静けさとは裏腹に、プラハのあるクラブには、生き生きとした騒々しさが満ちている。
そのクラブでは、IDを認証せずに支払いできる紙幣（みなくなって久しい！）を使うことができる。
「プライヴァシー（認証されない）自由と、テロの自由からの恐怖はトレードオフ。自由の選択の問題」
３
ジョン・ポールの妻子がサラエボで核の熱で蒸発したとき、彼女はジョン・ポールと不倫し、セックスを楽しんでいたという罪の告白。
罪悪感の対象が死んでしまうということは、いつか償うことができるという希望を剥奪されること。
死者は誰も許すことはできない。
４
「濡れ仕事」で数々の骸を見、中央アジアからワシントンに帰ってくると、母さんは事故で死んでいた。が、彼女の心臓は再び動き出した。――危険な軍隊へ行ってしまったぼくへの復讐として、ぼくに生き死にを決断させたかったから？
決断の材料を探す為に、母さんのいえ――ぼくの生家でもある――に行く。
かつてそこでも母さんの視線を絶え間なく感じながら、ぼくは育った。
見つめられることの安堵は、（認証され続けることの安堵は、）息苦しさの表面にすぎない。
結局、母さんの残したログは見ずに（ロックがかかっていて、他人が見ることはそもそもできなかった）、ぼくは母さんの「死」を決断する。
――母さんの視線の「気圧」から逃れたくて、ぼくは母さんを「殺した」んじゃないのか。
５
僕の告白に対してルツィアは、
「人間は生得的に善ね利他行動を行える。あなたの、お母さんを「殺した」決断も、本能による利他の行動。だから、あなたは許されるべき」
ルツィアとの帰り道、気を失う。
ジョン・ポールによる電撃を食らって。
６
とらえられた僕は、ジョン・ポールと会話をする機会を得る。
虐殺の言語は、僕の装備を作ったDARPAが協力した研究により生まれ、僕の殺す対象を選ぶのと同じシステムを利用してる。
７
ルーシャスは、〈計数されざる者〉という、ポールの協力者集団の一人だったのだ。
〈計数されざる者〉は認証を嫌う。プライバシーと平和はトレードオフの関係にあるはずなのに、実際は、認証をすればするほどテロが増加している。
それは、世界の人々が、自分のことにしか興味がないから。ドミノ・ピザとビデオクリップの平和に浸っているから。すぐに手にできるはずの現実に手を伸ばそうとしない奴らばかりだから。
ジョンとルツィアは去る。
僕はルーシャスに殺されかかる。その寸前のところで、ウィリアムズに助けられる。
第四部
１
旧印パ国境地区。そこにいるらしいジョンをとらえるように命じられる。
２
痛いと「感じる」ことはなくても、痛いと「知覚する」ことはできる。人をためらうことなく殺せても、その殺意を自分のことのようには感じない――僕は「濡れ仕事」をこなせるように、DARPAによって、そのように調整されている。
――「殺される」前の母さんと同じ、希薄な意識だ。僕が「濡れ仕事」をするために必要な、意識の希薄さ。
この殺意は、本当に僕のものなのか、僕が「殺す」前、母さんが本当に「死んで」いたのか、僕にはわからない。
３
４
ジョンを文化顧問として雇った、ヒンドゥー原理主義国、ヒンドゥーインディア。
その少年・少女の兵を、「他人の殺意」で殺しながら、ジョンのもとにたどり着き、彼をとらえる。
５
ジョンは、
「私が行っている「虐殺の言語」と、きみが施されている「「他人の殺意」による殺人」は同じだ。どちらも、良心を抑制する」と。
ぼくは、
「あんたには内通者がいるな。政府部内に。僕らの面子か、もっと上のほうだ」
ぼくらアメリカと同等の技術を持った敵によって、列車が襲われる。ジョンは僕たちによる拘束から逃れる。
僕たちも敵も、痛みを「知覚」するが、感じない。体の部分が吹き飛ばされても、戦闘は続く。お互い、「ハンバーガーになるまで弾と火薬をたたき込むしかない」。
リーランドはミンチになりながら、死の間際まで、冷静で希薄な意識で戦い続けた。
第五部
１
インドでミンチになったリーランドは、商品と違ってメタヒストリーを持たないから、つなぎ併せて一つにして、棺に納めるだけでも一苦労だった。
それでも、ミンチにさえならなければ、認証によるメタヒストリーを僕らは持つ。母さんもそうだった。
母さんのメタヒストリーがプロテクトされていなければ、僕は母さんを「殺す」か否かの決断を、認証の蓄積によるライフログを手がかりに探すことができた。
リーランドがミンチになった戦いがきっかけで、ジョンとの内通者が発覚する。
２
発覚した情報を手がかりに、ヴィクトリア湖へとジョンを追う。そこは、誰も追おうとしない人工筋肉のメタヒストリーの行き着く先。
〈ヴィクトリア湖沿岸産業者同盟〉は、人工筋肉の利権を得るために、独立しようとしている。
３
ジョンがいるはずのゲストハウスにルツィアを見つける。
ルツィアを探してゲストハウスに入ると、ジョンが待ちかまえていた。
４（物語のコア）
ジョンは、
「虐殺も利他も、進化によって得たモジュールという点で同じ。むしろ両立すらできる。生存のための大量虐殺というのもありうる。たとえば、食料を多部族から奪って自部族の仲間を生きながらえさせるためだったり」
ルツィアは、
「あなたは、サラエボの奥さんや子供を失って絶望しているから虐殺の言語をばらまいているのね？」
ジョンは、
「いや、愛する人々を守るためだ」
――そうだ。ジョンがいたどの国も虐殺に見回れていたはずなのに、彼の過ごしたアメリカとチェコでは、それが起きていない！
５（物語のコア）
ジョンは、
「人々はみたいものしか見ない。だから、いくら認証しても、テロはなくならない。
ならば、テロで爆発するはずの憎しみがこちら、アメリカやチェコといった先進国に向く前に、彼ら同士で憎しみあってもらおう。――そのために、虐殺の言語をふりまいた」
ジョンは、ぼくらの世界へのテロを未然に防ぐため、虐殺の旅を重ねた。
ルツィアは僕に、ジョンを殺さずに逮捕するように言う。僕らの世界の平和は、ジョンによる無数の死者の上に成り立っているのだと、みんなが知るべきだと。
と、ルツィアがヘッドショットを決められて死ぬ。
ウィリアムズによって。
「なぜ殺した」と僕。
「妻と子のためだ。彼女らは、この世界が虐殺の上に成り立っていることを知らなくていい。
ドミノ・ピザを認証で受け取る世界、くそったれの平和な世界を、俺は彼女らのために守る」
ウィリアムズはジョンを殺したがっているが、僕はルツィアの最後の言葉の通りに、ジョンを生きてアメリカにつれていき、証言の場に立たせたい。
ジョンとともに、逃げる。
「おまえを逃がせばまた、虐殺の言語を振りまくのだろう？」と僕。
「いや、死んだルツィアの望んだ通り、世界に真実を知らせよう」
タンザニア兵と合流しようとするが、それはタンザニア兵になりすました、僕の「濡れ仕事」の仲間だった。
彼がジョンを射殺し、僕の任務は（アメリカからすれば）成功裡に終わる。
〈エピローグ〉
……僕は、プロテクトがあるためにライフログを見られなかったのではない。ただ、漠然とした恐怖があって、ライフログの閲覧を申請しなかっただけだ。
僕は幼いころ、常に母さんに監視（ID）されているような気でいたが、母さんのログを読んでみると、必要最低限にしか、僕の存在が記述されていない。
母さんの記録の中に生きていたのは、圧倒的に父、自殺したはずの父だった。
僕は、ジョンからもらった手帳を元に、虐殺の言語を語る。虐殺の言語でもって、ルツィアの願い通り、真実を世に知らせるのだ。
そして、世界にとって危険な、アメリカという火種を、虐殺に突き落とす。
僕はこの決断を背負う。ジョンがアメリカ以外の命を背負おうと決めたように。
☆改変版
ジョンは、
「いや、私は米国内の後ろ盾を失った。深層構造の原理を知られれば、たかが言葉だ。応用されるのも時間の問題だろう。マスコミや政府公報で、いくらでも虐殺の言語を打ち消せるさ。
だが、私は〈計数されざる者〉という新たなバックアップを得られた。認証に対して憎悪を抱く、世界的な組織だ。この力を使えば、私たちのすむ「こちら側」を静寂に保つことができる」
「なにをするつもりだ？」
僕の「濡れ仕事」の仲間が、僕がジョンの答えを聞く前にジョンを射殺し、僕の任務は（アメリカからすれば）成功裡に終わる。
〈エピローグ〉
僕はジョンに、「真実」が書かれたテキストファイルを渡されていた。
それを世界に知らしめ、僕たちが虐殺の上にたっていることをみんなが理解することがルツィアの願いなら、僕はそうするべきなのだろう。
公聴会で、ぼくはジョンの件で見聞きしたものを語る機会を得る。
ジョンから渡された「真実」をオルタナに浮かべて話そうとする。
すると、僕が見ずにいた、母さんのライフログをオルタナに突きつけられる。――これが、〈計数されざる者〉、ジョンが最後に得た力か。
幼少の僕は、母さんに監視（ID）され続けていたと思っていた。しかし、母さんのライフログには、あまりにも父ばかりがいる。彼の死語ですら。
それを皮切りに、次々に、アメリカの全議員、いや、オルタナをつけているすべての人々の視界に突きつけられる、真実のログ。世界からアメリカに憎悪の数々が向けられているという真実。〈計数されざる者〉のルーシャスは言っていた。プライバシーの提供と、テロとのトレードオフの不均衡は、みたいものばかりを見ることによって起こると。認証の中に閉じこもり、ドミノ・ピザとビデオクリップの平和の外を知ろうとしないことで起こると。
ふと、アメリカはもう死んでいるのだと思った。母さんに視線を返せない、父さんのように。憎悪を浴び続け、しかしそれを無視しているアメリカは、死んだ父さんと同じだ。
……だが、アメリカに憎悪を向ける小国とて、自分の窮状をしらしめようと騒ぐばかりで、他の小国を知ろうとすらしていないのだ。僕が母さんのログを見ようとしなかったように。
ジョンが行った、〈計数されざる者〉の力の改変。それは、小国の内部で争いを起こす虐殺の言語よりも規模が大きなものだった。互いに無視しあっていたずの、小国と小国の視線をぶつけ合わせる。そして、小国同士で戦争を起こすことで、「こちら側」の平和を保とうとするものだった。
ジョンの考えと僕の考えは違う。
母さんが僕を見ないのは、父さんというすでに存在しない項があるからだ。アメリカからの存在しない視線を小国が期待するように。
存在しないものを、存在しないと意識させること。僕にはそれができる。ジョンから得た「真実」の欠片、虐殺の言語と、僕のマザータン、アメリカで語られる英語によった。
http://webrocketsmagazine.com/entry/20111209/html-code-generation-using-excel.html
http://mattn.kaoriya.net/software/vim/20111215034338.htm
http://d.hatena.ne.jp/takuya_1st/20111217/1324105198
真のプログラマーなら単純なHTML生成するのにテキストエディタは使わないよ。単純なHTML生成が必要なプログラマーなら、プログラムでやるでしょ。いちいちプログラムを書くのがだるい？いやいや、単純なHTMLの生成が必要なプログラマーなら、リストやディクショナリといった汎用的なデータ構造やCSVファイルといった汎用的な形式のファイルから、自動的にHTMLを出力するライブラリぐらい書いてるでしょ。わざわざ同じ作業をやるなんてめんどくさい。それにそのプログラムは他でも使うことができるしね。しかもPythonやRubyならほぼシェル感覚で使える。わざわざテキストエディタを使って同じ作業をする必要性はないね。真のプログラマーなら単純なHTMLの生成はプログラムでやるでしょ。プログラマーなんだから。
入社直後から、体調不良でよく休み、人事に怒られ、落ち込んで夜眠れず、また体調不良の負のループ。
人事の言葉はいつも辛らつだった。「期待していたのに裏切られたわ」と、入社一ヶ月で言われた。お前に騙されて採用したと。
「お前は頭がおかしいから、精神病院を受診しなさい」と、病院のリストを渡されて、今すぐ電話をして予約しなさいと迫られた。予約するまでこの部屋から出さないと言われ、頑なに拒否し続けて、気づいたら三時間経っていた。安全配慮義務おそるべし。
あれだけ抵抗したものの結局、辛すぎて自分で心療内科を受診することを決めた。薬を飲んでも、辛いままだった。一ヶ月経った頃、休職することにした。
復職したら、閑職に回された。当然だ。自分の作った書類は、4人の先輩がチェックした。本当に厳しかった。思い出したくないから書かない。人事部の近くの席で、「一度悪いことをした人は、また必ず悪いことをするわ」「また間違えて精神病患者を採用しないためにはどうすればいいだろうか」「やっぱり現役で有名大に入った人は打たれ弱くてだめね」なんて聞こえてくる。僕は罪をおかしたのだろうか。
就業規則には、著しく精神に異常のある者は解雇されると記載されていたが、解雇はされなかった。自己都合退職をして欲しいのかと思えば思うほど、意地を張って、耐えた。
休職前は仲の良かった同期や先輩が、休職を期にどっと離れて、復職後も少しずつ離れていった。今思えば復職後の方が、精神の状態が悪化していた。心配してくれた人につい愚痴をもらせば人事部に密告され、と言うことが何度かあり、誰に対しても、心を開けなくなっていたからだ。
一度、珍しく一人で書類整理を任された時に、自分より先にうつ病で退職した先輩の名前が書かれたファイルを見つけた。中を開くと、発症前後の行動、メールを裏ルートで抜き出したログや、経過などがボロクソに記されていた。僕の記録も必ずあるはずだとゾッとした。
管理職の何人かは「お前は必ずやり直せる。焦らずに、少しずつ回復していけ」とこっそり励ましてくれたけれど、うつ病患者となり飼い殺されている僕を笑う同期や先輩たちの心無い言葉に負けそうになった。いや、完全に負けていた。
それでも、最後のプライドで意地でも居座ってやると思っていたし、「僕には他に行くところなんてない」と思っていたけれど、結局転職した。業界では平均年収の高い企業だったが、僕の給与はとても生活できないものだったからだ。
「もう限界なので、退職します」と話した時、応援してくれていた課長は、残念だと言った。その瞬間から、上司と部下の関係が終わった。
人事から「よく見つかったね」「今より給与下がるでしょ？いいの？」最後の最後まで嫌味を言われたが、耐えた。
それでも、所属部署の人たちが送別会を開いてくれて、お花をいただいた時、「頑張ってね」とエールを送っていただいた時は、会社に何一つ貢献できなかった事を本当に情けなく思った。
入社当時は仲の良かった同期や先輩は、最後までノーコメントだった。何度も退職する人に色紙を書いてきたが、自分はそのようなものをいただく権利はなかった。一人で帰路につく僕を、営業部のやつらが笑っていた。僕は彼らに、何か悪いことをしたのだろうか。
それ以来あの会社の人とは会っていない。
転職して2年が過ぎた。会社を辞めてすぐに、心療内科を卒業した。本当にあっさりと、「もう薬を飲まなくていいですね」と主治医は言った。その半年後に、内臓疾患が発覚した。やっと、あの身体のだるさの本当の原因が分かった。これは今でも治療を続けている。
時々、あの会社の人たちにとっての僕は、今でも人間のクズなのだと思うと、叫び出したくなる。忘れているに違いないけど、完全に記憶を消し去れるわけではないのだ。フェイスブックやツイッターで、会社を賞賛する元同僚の書き込みや、同期同士の飲み会の写真を見て、絶望したりする。そう、僕は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 練習問題
auにもCarrier IQ入り端末が存在、KDDIでは「動作せず」と説明
http://internet.watch.impress.co.jp/docs/news/20111207_496397.html
>> KDDIはこの件を把握しているといい、その理由については「海外で先行販売されていたキャリア用のソフトを一部流用しているため。ファイルとして残っていても、実際に動作しないことは確認済み」と説明している。 <<
open化だかなんだかしらないけど危ない方向になってるぞ。
SFだけの話だろうと思ってたけど、いつかコンピュータウイルスで世界征服が可能になるな。