 
|
はてなキーワード: dbとは
Webサービスになるんじゃないかなーってことを思いついたので、自力で作ってみよう思う。
プログラマとして社会人約三年経験後、無職半年目。別業界に行こうと思ってた。
でも思いついたからやってみるって言うのは有りだと思うんだ。
機能拡張とかばっかりだったから、どうしていいのかいまいちわかってない。
・レンタルサーバを借りる
・余裕があればドメイン取得
・開発言語はPHP（とはいえ独自フレームワークばっかりだったのでCakeとか使えないぞ……）
・MySQL実は使ったことがないんだよな。関数をチェックしておく必要性あり。
・UIはHTML5を意識したXHTMLで書いておけば将来的な移行がしやすいのかな。最初からHTML5で書くというのも手か？
・CSS3使ってもいいのかなあ
・関連商品の表示のために何をすればいいのか（DBに閲覧履歴を保持するのか？）
・他にも思いつき次第追記
・ここがわからないのであった
・twitterとかなのかな
まあ、作れないかもしれないけど、その時はその時。
今夜は暇だから釣られてやるぞ。
検索しなくたってわかるだろうがこんな事。高校くらいまで何して生きてたの？その発想にびびったわ。
どんな素材を使ってても、外気に触れて、運動を阻害する可能性のある状態のものを体に密着させるって言うのは衛生的にも循環的にもよろしくないの。
どんな素材だって現状完全に壊れない・汚れないもんとか無理なの。遺体の確認例をやたら挙げてるけど、遺体ってどういう状態で出てくるかわからんの。
確認できないような遺体がどんな素材の指輪でも原型とどめないエネルギー食らってたりとかで壊れてる方がよほど考えうるの。
お前が言うような夢のような素材を開発するくらいだったら、DNA情報を管理する方が現状よろしいの。
他のレスでDBの事とか個人情報とか書き垂れてるけど、マジ論理破綻してるよ？
取り外しできるもんだったら指切断してでも奪うとかありうるわけ、そっちの方がよほど問題があるの。
医療現場では普通に生きてる人間の皮膚に防腐剤ぬられるんだけどさ。ていうか塗られたんだけどさ。
どう思う？別に指輪なんて無くし易い不確実なモン使わないで生まれてすぐにDNA情報取り出してそれをキーにしたDB作ればよくない？
事実上性能悪いでしょ。
たとえばこのご時世で、NLS対応なんかが糞。
根本的な部分に手を出せないんだろ、「過去の安定した実績」とやらを保つ弊害だな。
Expressなんか無償である程度使わせておいて、バグ対処必要とのことで有償でパッチを配る。
パソコンにデザインやキーの感触、I/Oポートの配置などトータルでの洗練は無用、
クロックアップでベンチがすごいとか、PCI-X(出てるのかな...)にも対応、とかで
「さすが!」と嬉々とする厨房みたい。
まあ、Oracle様のアコギ商売、信者どもが守ってくれるからな。
「うまく使えないのは、使うおまえが下手なだけ」...って言ってお終いの、よく見かける世間のパターン。
という俺はゴールド餅だけど、新規DBにOracleは、俺の為にも会社の為にも絶対採用しない。
採用時の１従業員(SIerかもしれぬ)の好き嫌いで、業務が左右されてたまるかよ。(SIerなら、バックもあるのか？)
今後数年の保守やシステム拡張、何より費用面からして会社へ背任行為をするわけにいかない。
困るとすれば、転職ときの経験・スキルでOracle求められること。
DBの意味もわからない人事のひとがとりあえずメジャーということで
求人要件に載せやがるっぽくて参る。
http://www.limy.org/program/db/not_oracle.html
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=30408&forum=7&start=8
DBってこんなもんか...と思ってたけど、インストーラのヘコさにあきれまくる。
その後 Microsoft SQL Server 2000 の手軽さを知って、こちらにどっぷり。
で、ずっとSQL Server。
そこそこの使い方ならどっちのDBも十分使える上に、Oracleは「くだらない」お作法が大杉。(Oracle Master の為?)
クエリー実行計画が図解でわかりやすい、バックアップやアタッチが超楽。
サポート(修正パッチなど)も料金込みのMSのほうがトータルで安価だし、CubeやReporting Serviceなどもコミコミで使える。
多言語関係もMS SQL Server のほうが良くできてる。
SQL Server のStandard Editionだけでなく、無償版であるExpress Edition も使っているが、
残念ながらこれは外部のPCから接続できない制限がある(はず)。
同じく無償版のOracle DB 11g Expressがあるが、こっちでは他のPCから接続できた。
Universal Installer は相変わらずjavaでできてるからかUIヘコいけど、
「くだならい」設定項目がだいぶ減って楽ちんでインストール完了。時代は進化した。
.NET Framework(OLE DB)で外部からのPC接続もホスト名、ユーザー名、パスワードを接続文字列で指定するだけで、あっさりOK。
tnsnames.oraとかいじることはもう無くてよいのだろう。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
駄目なプログラマはとにかく人に親切でない。この程度のデバッグならと思えるようなこともしない。金銭的な面だけじゃなくて、「ずっと担当しているプログラムに対してこの程度の手間なのに」と驚くようなことすら断ったり。
これはおそらく、デバッグをして見つかる不具合修正の費用対効果を計算できず、自分のメンツを重視するからだと思う。とあるプログラマにお願いを断られたこと（だいたいプログラマ個人の作業として30分もかからないこと）で、私は落胆し、数万円くらいのバイトを紹介するのをやめたことがある。数万円は曲がりなりにも派遣でプログラミングをしているプログラマにしてはたいしたことがない数字かもしれないが、それでも30分くらいの手間で、数万円のバイトを紹介してもらえるなら、悪くない投資のはずだが。
駄目なプログラマはとにかく無駄遣いをする。プリミティブな定数で済むところでも、かまわずにオブジェクトを生成する。メモリ少ないのにいいのか、と私が思うようなことでも、無駄なものに考えなしにメモリを使う。
駄目なプログラマはメモリを使わない。無駄遣いはするが、メモリは使わない。
うまくいえないが、メモリを使う勘所を意識していないのではないか。キャッシュを作ってメモリ上に保持すべき所で毎回 DB にアクセスし、効率的なキャッシュで DB アクセスを減らして高速化を行う事に気が回らない。
いわゆる memchached もそうだが、実績のあるライブラリなどを利用するための準備には時間とお金を惜しむ。そのことでより開発が楽になることを知らないからだ。
駄目なプログラマは周りを大切にしない。エンバグばかりする代わりに、同僚のテストは手伝わないし、私のようなプログラマにバグのパッチを送ったりは決してしない。
これは、その行為を無駄遣いだと思ってるのかな、と思ってたのだけど、そこまで合理的ではない。ただ周りの好きな人間を大切にしなくてもかまわないという気持ちのようだ。
駄目なプログラマは勉強をしない。とにかく本を読まない。講演を聴かない。人から教えてもらわない。
勉強したことが無駄にならないことをわかっていないからかもしれない。
駄目なプログラマは書くより語る。末端で参加しただけのプロジェクトの自慢話をしたりはしょっちゅうだ。そして自分のプログラムを書こうとしない。
プログラムを書いて学ぶメリットより、自分の話をするメリットのほうがでかいと思っているわけだ。ペラペラ自分の話ばっかりする駄目なプログラマは多い。
駄目なプログラマは挑戦をしない。やったことない言語や、苦手なことをあえてやってみようとしない。たとえば、勉強会なんかにいかない人たちだが、たまたまいったら流行っている言語をやってみようなどということはない。普通の人が面倒になって見てるだけだったりするのに加わるだけで、積極的に挑戦をしようと思わないことが多い。
失敗するリスクの低さと、経験のリターンの大きさを知らないのだろう。
駄目なプログラマは短期的にポジティブ、長期的にネガティブである。よく駄目なプログラマはネガティブな人が多いと言われるが、実際には、そうでもない。短期的には楽観的だったり不安に思わなかったりすることが多い。避けられるバグをなるべく避けようとする気持ちが少ない。
一方で、将来的に自分がどうなるか、などに関しては驚くほどネガティブである。長期的に悲観になっても無駄だということを知らない。逆に、短期的に「まあいいか」と楽観的になると、のちのちバグが発覚するのを知らないので、目の前のことに対しては真剣に考えない。
私が知っていることをまとめてみたが、実際にまとめてみると驚くほどシンプルである。だがこれを全部できてる人はなかなかいない。
駄目なプログラマになりたいと思っている人は、マネしてみるといいことがあるかもしれない。
※「貧乏人に大量に触れて初めて気づいた8の共通点」http://anond.hatelabo.jp/20110825204218 のプログラマ版です。
要は同じじゃねーか
苦しい言い分だったと弁えてるならごちゃごちゃ言い訳すんなよｗ
ずいぶん踏み込んで擁護してたのに
「ぼぼぼ、ぼくはしらないし説明できないけど、きっと想像の及ばないアマゾンさんのルールがあるんだもん！疑惑は全部気のせいだもん！」
俺への悪意だなんて一言も言ってねえよｗ
「DBの容量は有限」って言っただけで、「DBの容量不足で困ってる」なんて言ってないだろ。
どうせ細かい説明しても向こう分んないんだし。
どうしても工期短縮しろってんなら、じゃぁ、テストとかバグ取り出来ませんけど？と念書を取るべき。
何でだよって言われたら、「専門的な話になりますが」と断りを入れて、
・ポインタ使われていないのでコードが乱雑になっており、バグが発生した際に原因を解析できない可能性がある事
・古い仕様のコードが大量に含まれており、.net用に書き直すとなると、フローを再構築することになり、ほぼ一からの開発と変わらない事
辺りで良いんじゃないかね？
説明ができるというよりは、相手に言いたいこと言えるかどうか。
相手との関係がすでに悪いとか、なんか微妙なのは営業のせいだし。
上がってきた見積もりを持ってどう交渉するかだって、営業のスキル。
というか、そのために営業っているもんだしね。
技術屋は技術屋らしく、言いたいことを言った方が良いと思うが。
顧客との関係が良好だと、会計システムVCで組むのめんどくさいのでACCESSで良いっすか？ってのが通ったりもする。DBをOracleにして一点豪華主義。
かれこれ5年ぐらい走らせてるが、向こうがPC更新した時ぐらいしかトラブったこと無い。これも、ファイルパス変更しただけで動いたし。
http://anond.hatelabo.jp/20110816010530
全てのブラック企業にあてはまるわけじゃないけど、以前劣悪な会社に勤めてた経験からすぐ思うことを書いてみる。
ものすごい端的にいえば、人件費は同じで人を減らさないといけないんだから、仕事できないやつにはやめてもらわないといけない。すべてのブラックがそうだとは言わないけど、そういうのがいなくなるだけで随分よくなるはず。いなくならないからよくならないんだけどね。
あるデータのチェックをするのにフォーマットもうまく統一されてない手書きのものをバイト3人で読み上げて人力で数日かけてチェックしてる。そのあとキーパンチャーに外注して入力。そのあとスクリプトでチェック。読み上げチェックに一番時間かかってるので、こう言う風にしたらチェックも要らないしスクリプトももっとよくできると言ったら｢～さんの仕事がなくなる。それにスクリプトはなんとなく信用できない｣自分の扱えない技術は信用できないんだもんな。クソい。
ある設計でバイトの子が寸法をあわせるのに苦心してる。｢○○CADを使えば一発で自動であわせられるし、Tさんに計算の方法を教えてもらってもいいのでは｣｢Tさんの仕事がなくなるといって教えてくれない。○○CAD使えば数分でできるのを手調整で一日かけてやらされてる。どうにかして・・・｣
効率化するマクロを作ったら、うちだけズルするわけにはいかない、使えない人がいるから不公平だなどといって使わせてもらえない。
新しいやり方やツールを導入しても、教えるのにコストがかかる等といった理由で一部の社員だけだったりして、結局それにあわせて仕事を効率化できない。常にレガシーな残骸を考慮しなければいけないので、いつまでたっても大幅な効率アップができない。
社内サーバーにバグトラッキングシステムを入れて、今まで個々のPCでエクセルにまとめてやりとりしていたデバッグ情報をバグトラッキングシステムに一括してもらうことになった。がしかし、使い方がわからないなどで相変わらずローカルでエクセルに纏める人がいてかまわずエクセルのデータでなんでもかんでもやりとりするのでバグトラッキングシステムのDBからエクセルのデータを作成しなおしている。意味ねえｗｗｗ
上二つともかぶるけど、できる人がベストのやり方やれたとしても、それを許さないブラックがあるんですよ。あんただけずるするわけにはいかないよって見るわけです。バカバカしい、まじバカバカしい！
導入したら大幅に効率うｐするのわかってるのに、なにかと理由つけて古いものを使いつづけるんだよな。大して金のかからないものでも。金のかけるところおかしいんだよ。
でもそれを許さない雰囲気がブラックにはある。仕事を減らす仕事で困る人がいるからな。それがどうにかならないかぎり、ブラックでひいひいいってる人の食い扶持が薄くなるのは避けられない。
仕事が多いのが苦労してる証拠、仕事してる証拠っていう宗教があるからタチが悪い。仕事を減らす仕事、すっげーあたりまえのことなのに、それができない。
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
http://anond.hatelabo.jp/20110416105733
分野違いの技術屋です。いわゆるITだけが「技術」と思いこんでいるなんちゃってIT「エンジニア」ではないので念のため。
今思い返すと、「本当はとっても恐いものである原発だけど共存してくしかないから、大丈夫だと思い込もう。そしてそれに足る事実は多少ある。」といった精神状態になってるんだろうな、と思う。
それは日本人ほぼ全員がそういう精神状態なわけで特異なことでもなんでもないですね。早い話、地震のこと考えればそうです。大抵の家は震度6強に耐えられるように作ってあるけど震度7となるとどうかわからない。震度6強でも微妙で姉歯みたいな例もある。でも国外脱出する人なんていないですよね。
悲しい話ですが、家を選ぶとき「耐震性とお金のトレードオフ」はみんな考えるわけで、「安全を金で売り渡す」というのは多かれ少なかれ誰でもやっていることです。
「原子力発電」というテクノロジー自体は評価されるべき部分もある筈で、ただ日本という地震大国には向かないのかなと思うだけです。
個人的には今回の件、原子力だけに問題を見ている人は視野が狭いと思ってます。耐震性はそれなりでも津波対策が甘かったってのは実は土木工学・地震学全般の敗北なわけで、釜石の「世界一の防波堤」が崩壊したのもそうだし、沿岸地域の避難所が津波に飲まれたのもそうだし、死者ゼロの福島原発事故よりも深刻な被害が数え切れないぐらい出ている。あとなぜかみんな騒がないけど、放射能汚染よりも崩壊した建物からのアスベスト汚染の方が危険かも知れない。
そういう意味でこれはもっと、もっと深刻な問題じゃないかと思うんですね。「原発やめれば少なくとも事故は起こらない」って考えが甘すぎるんですよ。原発やめれば原子力事故は起こらないかも知れない、でも別のところで起こっている事故を止めることはできませんし、被害全体を考えれば原発事故は氷山の一角でしかない。社会システム全体として、対津波対策を根本的に考え直さないといけないし、場合によっては津波を被ることは諦めた上でその上で助かる方法を考えるようにシフトしないといけないかもしれない。そういう、極めて重大な問題だと思ってます。
「自然災害やテロの懸念が限りなく低い土地で原発を運営することを考えた場合、大きなリスクの一つとして"運営側の体質"が挙ると思うんだけど、ここが腐るのって日本特有なの？」「日本人には原発は向かない」のか「人類にとって原発はオーバーテクノロジー」なのか、正直僕には分からずにいます。
個人的には「オーバーテクノロジー」ってのは意味不明だと思ってます。例えば原子力発電と音声認識では後者の方が圧倒的に実用化が遅いわけですが、後者を「オーバーテクノロジー」って言う人はいません。要するに「自分が理解できないもの」を「人類の手に余る」と言っているだけだと思うんですよ。人類全てがお前と同レベルの知識しかないと思うな、とそういう人に対しては思います。
で、大事故というのは基本的に人間系の欠陥がなければ起こりません。ここを見れば色々事例乗ってますが、チェルノブイリはもっとひどかったわけだし、JCOとか福知山線脱線事故とかは完全に人間系の問題、ドイツのICE脱線事故は設計時に安全が疎かになっていた例、だいたいなんでもそうです。ローテクだろうがハイテクだろうが人間系がダメならダメだし、人間系が大丈夫なら最悪の事態は避けられるはずなんです。
となれば、うまく行っている例から学ぶ必要があると思うんですね。女川原発もそうだし、もっとすごい例で言えば地震直撃でも安全神話継続中の新幹線です。こういったところがうまく行っているからには必ずそれなりの理由があるはずで、原子力にかかわらず社会全体がこのあたりから学ぶ必要があると思う。そういう意味で個人的には、東京電力は国有化後役員を全員クビにして、東北電力やJRあたりの植民地にしてしまうのがいいと思ってます。
私は原発賛成派でも反対派でもありません。というかこの二分法は意味がないと思ってます。まともな人なら賛成派であれ反対派であれ
「原子力を置換できるよりよい方法（省エネ含め）があれば脱原子力を進める、そうでなければ現状維持のままよりよい方法（原子力の改良・改善を含む）を探す」
というところには合意できると思いますし、後は何をもって「よい」とするかの議論なわけで、実は見た目ほど立場が違わないわけですね。逆に、これ以外の理由を持ち出す人は環境やエネルギーではなくてトンデモ話やイデオロギーの話がしたいわけだから無視してよいでしょう、と。私はそういう実用的な立場です。
本文中では、現存の原子力の安全対策を東電にやらせることが前提のように書いていますが、原子力の即時撤廃が不可能（廃炉にだって時間はかかります）な以上、短期的にやるべきことは既存の原子炉の安全対策であることは議論の余地がないと思うのでその点には触れていません。原子力を維持あるいは拡大するにしたって、脱原発を進めるにしたって、その過程で福島の惨劇が繰り返されてはいけないことに異論はないと思います。
「原子力だけに問題を見ている人は視野が狭い」と言っているのに、原子力だけに注目して原子力は危険か否か、ということを語り、それでなぜか批判した気になっているブックマークのなんと多いことか。もう疲れたのでその種のコメントには返信しません。
fantoms フェイルセーフ知らないのか? 失敗学のDBを参照しておいて、最終的に人が大丈夫なら最悪の事故は防げるとか何を見てるんだろう。 2011/04/16
私が言っているのはものと人間と両方のシステムを頑健にする必要があるということで、人間系が頑健ならものが頑健でなくてもよいなどということではありません。あと、今回の事故はフェイルセーフへの過信が原因の一つであることも認識すべきでしょう。フェイルセーフ機構が破れた際の対応策がなかったのだから。
white_rose これはひどい こういうのは始末が悪い。ほんともう2、3機別の原発でやられないとわからないのかも。そんなことになってほしくはないけど 2011/04/16
ではどうせよとおっしゃるのですか？原子力に関しては私は具体的には安全策の拡充をしろとしか言っていません。選択肢の可否はさておき、即時撤退であろうがはたまた拡大であろうが、それが必要なことに疑問の余地はないと思うのですが？本文中にも書きましたが、廃炉にするにも時間はかかるのですよ。
banraidou 災害 ヒューマンエラーをゼロにすることは不可能なんだけど……「人間系の改善」を簡単に見すぎじゃないかなぁ。「２ケタの足し算」ですら、正答率をいつ何時でも100％にすることは不可能なんだぜ？ 2011/04/17
ヒューマンエラーをゼロにすることは不可能ですが、少しでもそれに近づけなければいけないことは明らかです。これは原子力に限った話ではないし、原子力の存廃とは無関係にその努力が必要だと言っているわけです。現代ではどんどんシステムが大規模化しているわけで、そうなればなるほど原子力に限らず事故が起こった場合の被害は増大するわけですから。そして、理想に近い例として新幹線を挙げたつもりです。
hamanako この論旨でもんじゅの事故で自殺者が２人も出ていて、２人目の方が亡くなってから３ヶ月しか経っていないことに触れないのには驚く。視野が狭いのではなく目が開いていないよ。これこそ人間系とやらの破綻の象徴だろ 2011/04/17
おっしゃる意味が全く理解できません。まず、「今回の件」が「東日本大震災の件」であることは文脈上明らかでしょう。それに、自殺が深刻な問題であるのは確かですがどう考えても別の問題でしょう。
bobjoker んー？突き詰めると全体コストの問題だけじゃないかな。で、震災前まで入れてないで計算していた今回の災害コストを入れると原子力は割高。その数字で今原発を止めたほうが低コストなら止める、というだけ。 2011/04/17
いや、コストよりも安全性の方が大事に決まっているでしょう。それに、コストの議論をすれば自然エネルギーに逆風になることにお気づきですか。原子力をコスト面で批判するのはよくありません。火力依存を助長するだけです。
kagakaoru オーバーテクノロジーについて。一定の確率で事故が起こるときに、その被害が局所的であれば許容（自動車など）、その被害が全人類に及ぶようなものをオーバーテクノロジーと呼ぶのでは。原子力やもんじゅはどうか？ 2011/04/17
自動車は非局所的に普及していますというのはさておくとして、福島はおろかチェルノブイリですら、被害半径は全人類と呼ぶにはほど遠いです。放出された放射性物質の量からいっても、大気中核実験の方がはるかに有害でした。原子力事故の被害を誇張するのは当該地域の人のためにも、また冷静な議論のためにも有害無益です。発電所事故に限っても水力発電事故の被害は甚大（リンク先記事著者は反核活動家であることに注意）ですし、そもそも水力なんてダム建設時点で一地域を居住不能にしているわけですよね。
perfectspell 「安全係数高めれば大丈夫」神話。なら東京に原発つくれば? /確率下げたとしてダメージを負いきれるかという期待値の話。又は安物買いの銭失い。 2011/04/17
逆です。「安全係数高めてもダメだった」ことが「原発に限らず」深刻だ、という話です。なお、東京はそもそも地盤が悪いので原発は無理ですが、たとえば少し検索した結果、ベルギーのDoel原子力発電所はアントウェルペンというベルギー第二の都市の対岸に建設されています。「東京に原発を」という人はなんでそういうことを少し調べてみようともしないのでしょうか？
kyo_ju 原発, 増田, 味わい深い ululunさんのブコメへの返事で放射性廃棄物の問題をスルーしてる時点で結論ありきなのが見え見え。 2011/04/17
そういうデメリットを全部考えた上で原子力が得策かどうか考えましょう、という以上のことは言っていないわけで、なんでそんな下司の勘繰りをされなきゃいけないんだか。あなたみたいに人を敵と味方に簡単に二分する人のことですよ、「イデオロギー」の話がしたいのだというのは。だいたい放射性廃棄物の問題を「スルー」なんてしてないでしょうに。もう一度よく読みなさい。
TakamoriTarou web, 論説 全部グッチャグチャにして同レベルで考えるようだけど、それって同レベルで語れるものなの？複雑に絡み合ってる問題を単純化して各個撃破しか実務では解決できないよ。特に今は全体を語れるほど整理も終わってないし 2011/04/17
「今」の話ではなく中長期的な話をしているつもりです。また、「同レベル」で語らなければなりません。実際、我々がどうやってエネルギーを得るか（またはどうやってそれを節約するか）という意味では同レベルなのだから。個別の問題と「戦略」を混同してはいけません。
（メタブクマから）TakamoriTarou web, 増田 レス読んで優越感との意味がわかった。増田は「理想を語る技術者」に陶酔してるんだ。森の未来を語る理想論者だが木のために今何をするかには興味がない的な。だから現実の改善を考える現実論者と話が咬み合ってない 2011/04/17
違います。「興味がない」のではなく「わからないから言及しない」です。原子力工学や土木工学、地震学についてはそれぞれの専門家に聞くべきです。あと、何を「現実論」とお呼びかは知りませんが、正しいかどうかもわからない認識に基づいて部分最適化を求めるのが「実務」だとのご意見には到底同意できません。少なくとも私はそんな姿勢で仕事をしていません。
違います。例えば眼科医や整形外科医でも素人よりは例えばインフルエンザのことははるかによく理解しているでしょうし、「診療科を問わず病気全般について言えること」については発言権があるでしょう。そういうものだとお考え下さい。
lucky12345 引用元が消えてるから引用してる部分だけから判断するに「オーバーテクノロジー」の意味誤解してるよ。人類が安全にコントロールしきれる技術かどうかって意味だろ。音声認識でそう言わないのは危険性がないからだろ 2011/04/17
同じことの繰り返しになりますが、「安全」の程度によります。「絶対安全」を求めるならばすべての物がオーバーテクノロジーになります。チェルノブイリを基準にするなら、たとえばBP原油事故や水俣病も同等と思われるので化石燃料関係も無機材料関係も全部オーバーテクノロジーになります。音声認識というか生体認証も失敗すればテロ犯を入国させる可能性があるのでこれもオーバーテクノロジーでしょう。要は「オーバーテクノロジー」という言葉は情緒的なもので内容がないんですよ。
anon42 民間企業より国営のほうが安全になるってのは，どういう理屈なんだろう．そういう例があるの？利益追求の結果安全性が損なわれたというなら，安全確保が利益につながるような仕組みを作ることのほうが近道だろう． 2011/04/17
この点ですが、「国の管理下にあれば安全性が高まる」という議論は私も正しいと思っていません。単に、東電はこのままだと破綻だろうから、ハゲタカの手に任せるよりは政府が介入すべきではと思っただけで、別に「国有化」はそこまでこだわる部分ではありません。
flowing_chocolate 原子力, 技術 いくら原子力工学がしっかりしてたとしても、それ以外のどこかに穴があれば全てが破綻することになる、という話。政府、運用者、一般人…邪魔する勢力はどこにでもいるし、おそらく破綻へ導いている自覚もない。 2011/04/17
前半に関してですが、今回の場合「原子力工学」も津波に対応できなかったという点で「しっかりしていなかった」と言えます。この記事を見る限りおそらく、「ある分野でパラダイムシフトがあったときそれが隣接分野に浸透するまでには時間差がある」という現象の罠に落ちたようで、そういう意味で「時間切れ」だったのでしょう。同様のことが原子力に限らず起こっており、それが「地震学・土木工学の全面敗北」と書いた所以です。後半部については全く同意で、原子力関係者を非人間化して金の亡者のごとくに叩く一部風潮は一時的なカタルシス以外の何も生まないと思います。大事故を起こす人は油断こそしているかもしれないが、悪意の人ではない、だからこそ恐ろしいのだともっと認識されるべきですね。
moilin 事故には多かれ少なかれ特異性がある。今回の事故は原子力に関する問題がその特異性の大きな部分を占めるので（ヒューマンエラーとか一般的な事故論と別に）、これを特に切り分けて論じることもまた必要なんだよ。 2011/04/17
それ「も」必要でしょうが、そういう技術的詳細ならなおさら専門家の領域でしょう。素人が語るべきことではありません。一般人の視点では一般的な有害物質飛散事故です。
kunioya JRは新潟県中越地震で脱線しても運よく止まった例を今回、緊急地震速報で生かした。「誤魔化す」文化と「改善する」文化の違いだろう。 2011/04/18
まさに東京電力についてはその「文化」がキーワードだと思ってます。一番大事なものは「安全」であるという認識のもと、「危険予知」「改善」という当たり前のことを日頃から行っていれば「全交流電源喪失」という古典的な問題の対応策は当然とっくの昔に立てられ、訓練が積み重ねられていたはずです。そのあたりの体質改善からやり直しでしょうね。
tatsuzawa 今回多くの周辺住民に避難を強いているわけだけど、例に挙げられた他の技術はそういう必要はない。アスベストや新幹線は個人の選択で回避できるし、津波はそうではないが人の手によって被害地が決まるわけではない。 2011/04/18
@tatsuzawa まあでも全体の合理性を優先して、人権問題みたいなのはどうでもいいと思っている人は結構いることが今回の事故でわかった。
それを被災地の人に言ったらぶっ飛ばされますよ。というか16年前に阪神間に住んでいた者として言わせてもらう。ふざけるな。アスベストは勝手に建物に降って湧いたとでも思ってるのか？地震が起こった瞬間被災地からワープして脱出しろとでもいうのか？それとも当時12歳のガキだった俺の自己責任ということで全てお茶を濁すつもりなのか？ふざけるんじゃないよ。原発で作られた電力を使っておきながら、他人事みたいな顔でなにを白々しい。文明の恩恵に浴するということは漏れなくリスクを負い負わせることだと知れ。少しは自分も加害者だという自覚を持ったらどうなんだよ。原発さえ血祭りに挙げれば清く正しく美しい生活が送れますだと？現実を舐めるな。
HTMLはわかるけど、サーバーサイドはお遊びでphpを触ったぐらいだったので、会員制でデータをためこむサイト作りに初めて挑戦した。
今回重視したのは、「いかに個人情報をお漏らししないようにして、万が一漏らしても被害を少なくするか」ということ。
世の中、有償サービスでもパスワードを平文で保存してるサービスが意外と多いらしいので、流出した時のリスクを少しでも減らせる対策として書きます。
サーバー：ロケットネットのキャンペーンにでレンタルサーバ年１０００円ポッキリプラン クライアント側の処理：HTML+CSS+jQuery（とプラグインもろもろ） サーバ側の処理：PHP Webサーバー：Apache データベース：MySQL
俺も巻き込まれたところでは、サミータウンがメールアドレスとパスワードセットでお漏らししてお詫びに１ヶ月無料なにそれこわい。
サミータウンだけならまだいいけど、メアドとパスワードを他のサービスで共通化して使ってる情弱なので、
共通化してメアドとパスワードをどこかのサービスが一箇所でも漏らすと、ヤフオクID乗っ取り事件みたいなことになる。
http://internet.watch.impress.co.jp/cda/news/2008/09/26/20967.html
俺だってできれば人様のメールアドレスとパスワードとか預かりたくない。
万が一、肉親のメールドレスを発見してパスワードにrapemeとか入ってたら明日からどういう顔すればいいかわからない。
ググってみてもどこにも情報のってない。うーん困った。ダメもとで「個人情報ってどうやって保存したらいいんだろう。。。」
って、twitterでつぶやいたら、「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
何のことかわからなったので、調べてみると、
・ハッシュ＝ハッシュ値を使った、元のデータに戻せない暗号化方式
うーん。。。よくわからん。。。
電話番号とか住所は、第三者が使用する情報なので、可逆が必要。パスワードは、認証にしか使わないので、
ハッシュ値の結果が一致すれば元のデータがわからなくてもOK、という方式なのでこういった暗号の使い分けをする。
●可逆暗号のイメージ（もとにもどせる） 暗号化キーは開発者が指定する。 090-xxxx-xxxx →（暗号化）→ !'&%($% →（復号化）→ 090-xxxx-xxxx ●ハッシュのイメージ（もとにもどせない） 登録password（DBに保存）→（ハッシュ値抽出）→!"$#'$#=" ログインpassword →（ハッシュ値抽出）→!"$#'$#=" ※二つのハッシュ値が合っていれば、パスワード一致として認証する。
今回はMySQLの関数で実現した。encode関数で暗号化して、decode関数でもとに戻す。
例えばtel_noという項目だけあるテーブルがあるとすると、
//データベースに保存する時 insert into テーブル名 (tel_no) values (encode(tel_no,'暗号化キー')); //データベースから取得する時 select decode(tel_no,'暗号化キー') from テーブル名;
これで、データベース格納時は暗号化（バイナリ化）されて、データベースから取り出してHTML表示する時に復号化はされる。
＜ユーザ登録時＞
$password=（フォームから取得） $hash=hash('sha512',$password) //ユーザ登録時は、ここで生成した$hashをデータベースにぶっこむ。
ユーザ認証時は、入力されたパスワードと、データベースのパスワードが一致するかチェック。
//フォームから入力されたパスワード $input_password=（フォームから取得） $input_hash=hash('sha512',$input_password); //MySQLに保存されたパスワードを取得（略） $db_hash==（データベースから取得） //判定 if($input_hash==$db_hash) echo 'ログインしますよ！'; //ここにログイン処理を書く else die('メアドとパスワードがあってないよ！');
これでもしSQLインジェクションとかでデータが流出しても、ハッシュ暗号のパスワードに関してはまず解析されないはず。。。
可逆暗号のデータもphp側の暗号化キーが盗まれない限りバレない。。。はず。。。
何でもかんでも暗号化するとコードが煩雑になるし、パフォーマンスにも影響でそうなので、
住所データの都道府県とか、漏れても良いような情報は暗号化しませんでした！！
個人情報保護法 2条による定義 「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
これで、もし漏れても、俺、ウンコ漏らして臭いけど、パンツから出てないからいいよね？というレベルにはなった。はず。
万が一漏れても大丈夫！と書いたけど、そもそも漏らすなというお話になる。色々調べた結果、以下の対策をほどこした。
・当初jQuery側でSQL組み立ててPHPに渡してたので、これだと任意のSQLが実行できて漏らし放題なのでやめる。
・GETとかPOSTでDBに渡すパラメータを扱ってる場合、ちゃんとエスケープする。
例えばログイン認証するPHPで、GETメソッドでフォームからデータを取得するような場合、
$id=$_GET['id'] $pwd=$_GET['pwd'] $sql="select * from ユーザーテーブル where uid='$id' and pwd='$pwd'
とかやってると、login.php?id=admin'&pwd=' OR '1'='1とかパラメータを渡されるとあら不思議！
select *from ユーザテーブル where uid='root' and pwd='' or 1=1
で、誰でもログイン出来ちゃう！ので、mysql_real_escape_stringでエスケープしたり、渡されたパラメータが想定した値かどうか（例えば数値かどうか、とか）のチェックをいれたりする。
・保存するデータにタグやJavascriptを埋め込まれないように、保存されたデータを出力する場合はPHP側でhtmlspecialchars関数使ってエスケープするようにする。
こんな感じでお漏らし対策をした。間違いがあったら教えて欲しい。
ちなみに出来上がったサイトはこれ。
そりゃ、変形労働時間制なんぞ取ったら、経理がむちゃくちゃになるからできないに決まってんじゃん。
そもそも、昔は紙の台帳に首っ引きで顧客検索していたのが、今はDBからクリック一発で終わる時代だ。それなのに昔も今も、同じ40時間労働って、もはやギャグかブラックユーモアでしかない。
労働時間制度が複数あると上に提出する書類が複雑怪奇になってしまうのよ。
職種ごとに明示化できればまだマシだが、職種内に複数とかあったらもう、財務も法務も死んでしまうわ。
労組だって、システムが複雑すぎて賃金交渉が出来なくなってしまう。
そんなに常勤嫌なら、非正規雇用になればいいじゃん。
契約社員とか。
ぶっちゃけ、今私が働いてる会社の状態は人員過剰なのでヒマな時間が多い。週休3日にしてしまっても全然問題なく業務がこなせることは薄々みんな分かっている。しかしまぁ、腐っても日本企業、簡単にクビなぞ切れるわけがない。
私は余暇が何より大事なので、「給料が20％減っても構いませんから、勤務日数も20％減らして週休3日にして欲しい」って言ったけどそれはダメなんだそうな。なんでだろう？ だって会社は人件費減らせるし、私は余暇が増えて嬉しいし、誰も困らない。喜ぶ人しかいないと思うんだが。
考えてみれば、今の日本企業は週労働時間40時間に異様に拘る。でもこれって不思議すぎる。職種や仕事の種類なんてそれこそ千差万別なのに、あらゆる業種のあらゆる会社が判で押したように週40時間労働って、なんなんだろう？考えてみればちょっと不気味だ。そもそも、昔は紙の台帳に首っ引きで顧客検索していたのが、今はDBからクリック一発で終わる時代だ。それなのに昔も今も、同じ40時間労働って、もはやギャグかブラックユーモアでしかない。
正社員の既得権益の問題が言われるが、単純にそれを手放せと言っても難しい。しかしこの「週休3日だけど給料もカット」は、お互いに得るところがあるから有効だ。特に高齢窓際族。彼らは週休3日でいいよって言えば応募する人はかなり多いだろう。特に既に子育てが終わった年齢は、給料が20％カットされても、人生のカウントダウンが始まっているため「時間」が何より大事なはずだ。（この辺の読みは、親の介護が必要か、とかで個人差デカいだろうが）
また、週末企業したい若者にも朗報だ。このご時世、会社を辞めて起業はリスクが高すぎるのでできれば週末起業したい、しかし2日では少なすぎる。この場合、週休3日にすれば結構なことができるようにならないだろうか？ 会社としても、起業したいようなガッツある若者を手放さずに働かせておける（しかも通常より安い給料で）のだから、メリットがあるはずだ。
とまぁ、週休3日制は日本を救うとまでは言わないでも、企業にとって悪いこと何一つないし、労働者にとっても嬉しい(正社員の既得権益を削れるし、イヤな人はそのオプションを選ばなければいいだけ)と思うんだが、何か穴とかあるかな？