  |
はてなキーワード: 再利用とは
http://honeshabri.hatenablog.com/entry/vlookup
神がエクセルを使いこなせたら、聖書はもっとわかりやすかったに違いない。いや、CADが使えれば、モーゼの方舟の設計図も難解な文章ではなく、ビジュアル的に把握できる形式になっただろうし、イラストレーターが使えたら、祭司のコスプレも現代にまで残っていたはずなのに。
と 脱線はここまでにして。
神が理想を唱えると、反逆する者もおり、一方で、神の理想から堕ちてしまう者もでてくる。それは歴史が実証している通りである。エクセル表についてもしかりである。人は罪深い生き物なのだ。
例えば、神が、実用性とビジュアルを兼ね備えた表を作り上げたとしよう。それは、ありがちな技術者が作り上げる実用性が高い"だけ"の表になることなく、再利用性も高いのに視覚的にも把握しやすいものだ。まさに、神のエクセル表。
しかし、このエクセル表を運用するのは、罪深き人間なのだ。エクセル初級者や、さらには、「フォントってなんですか？」と尋ねてくるようなパソコン初心者だったりする。
するとどうだろう。「この表おかしいんですが」 と持ってこられたエクセルデータをみると、"コピー" , "貼り付け" , "挿入" , "削除" 等の「武具」により、無残にもフルぼっこされたかのようなエクセルになっている。
条件付き書式はずたずたに壊され、数式が消え去り、罫線はとぎれとぎれなのだ。
これを繰り返すうち、私は堕天使になることを決めた。「決して理想は求めない」と。いや理想を求めないこそこそ理想なのだと。神の教えを退け、我が道を歩むことに決めた。
初心者の運用に耐えうるできるだけシンプルな、数式や入力規則や関数の入っていない、エクセルを作り上げる。そのほうが、人には、わかりやすく使いやすいのだ。実務が冗長になろうが、人は労力惜しみなく注ぐことには苦を感じないのだ。むしろ、分厚いマニュアルを参照しながら決められた場所に決められた方法で型にはまった仕方で運用することを忌み嫌うのだ。 人は自由を求める。
どうしても、VLOOKUP等使いたい場合は、入力用シートと出力用シートを別々に作成し、INDIRECTを使用し、"武器"による攻撃にもタフに戦えるようにする。要するに、神の存在を感じさせず自由を与え、背後でその世界を操るすべを身に付けたのだ。
技術のたけただけの人が作るエクセル表ほど、使いにくいものはない。
今回の件をうけて、腐女子の側は一方的に被害者とか、弱者という立場を維持するのだけでなく、
自分たちの慣習を、腐女子コミュニティの外の人たちにもわかるような形で
また、腐女子だけでなく、コミュニティ独自のローカルルール抱えてるオタコミュニティの人々は
今回の件は、他山の石となるんじゃなかろうか
・まず、主張自体への支持について述べるなら、私自身の立場はこの中で選ぶのならBが近い。しかしBそのものではない。AとCについても一定の妥当性のある主張だと思う。
・Dの主張にはいろいろ誤解がある。著作権の枠組みで主張をするのであれば「無許可な転載」は確かに問題だが、著作権上、正当な「引用」は許可を求める必要はないし、求めるべきでもない。また親告罪云々という話も「転載」と「引用」の違いが把握できていないものと思われる。
著作権法基準（A）の人が、ローカルな慣習（C）のありようを把握していなければ、両者の対立はどこまでいっても平行線である。この人達にずっと不満がたまり続けるので、互いの正当性を主張し続けて炎上は終わらない。また、基準Dのような勘違いを含んだことを言うひとも大量発生していて、これを基準Aの世界にいるひとからすれば「バカじゃねーの」という感じになるし、そう発言してしまう。基準Bの世界にいるひとも人によっては「それはちょっと、落ち着いて整理しましょうか」とたしなめる。なので、またしても火がよく燃える。これが今回の炎上の基本的なメカニズムだと思う。
炎上は「誰かが決定的に間違っている」から続くのではなく、「ある立場の人からみると、別の立場の人のやっていることが極めて無作法に見える」ということによって起こり、その行為が「別の立場から見たときには実は何の問題もない」場合に、火が消えるタイミングというのは失われてしまう。
・基準Bの態度を採用することは、全体的に見通しがよく相対的に中庸な温度感のある態度だということになるだろうし、この立場を表明している人は、おおむね良識的に火消しをしているという感じだと思う。
・基準Bは、基準Aないし基準Cのみで完結して争っている人々の立場より、バランスのとれたものであろうとしているのは確かだろう。しかし、私は別の基準Eが必要だと思う立場である。
基準Eは、明文化されていない慣習を、きちんと取扱可能にすべきだという方法である。明文化するなりプログラム的に制御するという方法だ。以下に、なぜそのような立場を採用するべきかを述べる。
法がどうであれ、運用の水準で、実質的に慣習法を作り上げるということはいくらでもできるということはよくある。そして、ローカルな場にいる人たちは、その場の慣習があたかも普遍的に適用可能な「常識」であるかのような主張をはじめることが多い。だが、そうローカルな商慣習や、コミュニティ内の慣習は多くの場合、炎上の温床となってしまう。今回の件だけでなく慣習と法の間での齟齬が「炎上」を生んだことは数多くあった。
「様々な慣習に対して、可能であるのならば配慮すべきである」という主張は正しいと思う。可能であるのならば配慮するに越したことはない。
しかし「様々な慣習に対して、常に配慮すべきである」という主張は、どうか。わたしは難しいのではないか、と思う。単純にそれは人間にとって不可能なことを要請しているように思うからだ。
たとえば今回、火の手があがったのは、801界隈だったわけだけれども、オタク界隈どころかゲーマー界隈に限っても「同人ゲーマー界隈」「格闘ゲーマー界隈」「シューター界隈」「MMO界隈」「東方界隈」「レトロゲーマー界隈」など、細かなコミュニティがそれぞれの慣習をもっていて、自分が属していない界隈での慣習がどうなっているかというのは正直なところ把握しきれない。「私はオタク界隈のほぼ全てのコミュニティの慣習について把握しています」と自信をもって言えるという個人はいないだろう。まあ、それでもオタクコミュニティ界隈のことであれば、長くオタクをやってる人なら「ああ、これだったら何とかさんに聞いとけば温度感わかるっしょ」という人脈による解決はできなくはない。
ただ、それが、もっと遠い界隈のことになってくると、限界が出て来る。芸術・コンテンツまわりでも、現代芸術とかならまだしも、古典芸能の世界でのセンシティヴな話題とか言われても、細かなことはさっぱりわからない自信がある。手芸とかもわからないし、動物園のこともわからないし、外食産業のこともわからない。わからないことがいっぱいある。
で、まったく知らない界隈に飛び込んで、そこで見つけたものをよかれと思って引用しようとしたら、当事者からいきなり激怒されるなどしたら、私はビビる。めっちゃビビる。超うろたえる。
そんで、まあ、たぶんゴメンナサイすると思うけど、なぜキレられたのか、理解が追いつかないだろう。正直、ぜんぜんわからんと思う。小心者なので、とりあえず反射的にゴメンナサイをするでしょう。
「よく知らないものに言及しない」というのが重要だという人もいる。まあ、特にやる気がないなら、あんまりセンシティブそうなものには言及しないほうがいいかもしれない。
ただし「よく知らないものを知る」ということ自体は、世の中に多様な人々がいるということの相互理解をすすめる上では実は非常に重要なことでもある。たとえばLGBTや人種の問題というのは、言及の仕方についてしょっちゅう諍いが起こっているが、まったく言及されないよりも「善意に基づく無理解」のような言及は、議論をよびながらも、なされていったほうがいいだろう（まあ、場合によっては無視されたほうがマシということは少なからずあるにはあるだろうが）。
私としては、「同じ文脈を共有しない人にも、慣習上、重要な点を共有できるようにする仕組みづくり」を行っていくしかないと思う。
その仕組みづくりにはいくつかの段階があるだろう。
以上。STEPと書いてあるが、コレ全部やれという話ではない。まあ全部やれたらすごいとは思う。
もっとも、慣習によっては標準化が難しかったり、明文化しないことによってこそ意味をもっているような慣習などもあるだろう。そういうものを取り扱うのは確かに難しいが、すべての慣習が取扱い不可能ということもないだろう。
明文化できる慣習は、明文化して、可能な限りで、コミュニティの外部にいる第三者にも把握可能な形にするというのは、決して無意味なことではないと思う。お互いの不幸な行き違いをなくす基本的な方法だとも思う。
もちろん行き違いをなくすという方法自体を、腐女子コミュニティがいままで模索してこなかったとは思わない。
腐女子コミュニティ内部にいる人達同士ですら、行き違いはあったのだろうし、そのなかでの行き違いをなくすために、R-18タグは付けることで「ひっそりとやってます」ということを暗に伝えるという慣習が成立したのだろうと思う。その慣習の成立はとても重要なことだったと思う。
少なくとも腐女子コミュニティの内部では、この慣習はかなり機能していたはずだ。
そして、今回の事件はその慣習が、実は一般的な著作権法の枠組みと整合的なわけではないということによって起こってしまった。コミュニティが大きくなれば大きくなるほど、考慮すべき文脈の多様性は広がってくるのだから、近年の腐女子コミュニティの拡大とともに、こういった事件が何かしらの形で起こることはありえたことだろうとは思う。
それにもう一点付け加えておけば、私は「【基準B】：法的問題はない。しかし、当事者たちにとってセンシティブなことへの配慮が足りなかったという点で、研究倫理上の問題はある。」という態度だけを強調することは、一見、配慮をうたっているようでいて、そこまで素晴らしい態度というわけでもないと思う。
基本的には、この論理だけを強調せざるを得ないシーンというのは「対話することが難しいほど弱っている人たち」とか「西洋文化基準でもって踏み込むべきでもない人たち」、「複雑すぎる背景をもっているので相手に明文化とかをそこまで期待すべきでもない人たち」に対する場合ではないだろうか。
つまり、言及をする側からの一方的な配慮である。鬱でほんとに今にも死にそうな人とかに対しては確かにそういう形でのコミュニケーションしかできないから、そういう場合は仕方がない。
もちろん、言及をする側は可能な限り配慮すべきだ。しかし、だからといって、言及をする側だけに配慮を要求するというのは、言及される側を馬鹿にした話ではないだろうか。配慮は相互になされてよいと思うし、腐女子の方々は、一方的に配慮されるだけの弱者とかではないと思う。
多くの腐女子のお姉さまがたは、尊敬すべき人々であると思っている。ぜひとも腐女子コミュニティの今後の拡大にあたって、より受け入れられやすいコミュニティの形成をしていっていただければ幸いだと思う。
また、今回はたまたま腐女子のコミュニティと一般法との間の問題であったが、これは見えにくい慣習と一般法の間にズレがあるケースでは、似たような問題は何度も起こるタイプの話だとも思う。ローカルなライセンスのようなものが増えすぎたら、それもそれで面倒だということもあるとは思うが、何もないよりは、だいぶよいだろうとは思う。
「慣習は、法の前には下位の基準でしかない」という話についても簡単に触れておきたい。
基本的には法のほうが重要だとは私も思う。ただし、それは慣習と、法とのガチンコ対決が回避できないという事態が訪れた場合、法が優先するということであって、ガチンコ対決が回避可能な場合や、慣習が公序良俗に反するというわけでもない場合は、別に回避してやってけばいいのではないか、と思っている。
今回、腐女子コミュニティで「引用」に関わるルールが特殊な形で扱われていたが、もし腐女子コミュニティにおける「引用」ルールを、一般社会全体にまで拡大させようという動きにつながることがあるのならば、これは断固ととして反対する。
「引用」の自由は、研究にとって重要という以上に、自由な言論、政治、社会にとって重要なものだ。たとえば、それを政治的な言論（たとえばヘイトスピーチ）をやっている人たちが「引用」ルールの除外適用を求めてきたとしたら、それは素人の文章だったとしても、まったく受け入れられない。「公開した俺の政治的発言を引用しないでくれ」などありえない。それを引用して批判する自由を奪われれば、政治的なことについて公共の場で議論することに多大な支障が出るだろう。
今回の場合は（１）性的プライバシーの問題であるということ（２）腐女子コミュニティの内部で、そのコミュニティに属する人々の合意において特殊な「オープン／クローズ」概念が実効力をもった慣習である、という前提があって、はじめて「それは配慮しましょう」という話がありうるのであって、著作権における「引用」そのものを捻じ曲げるような話であってはならない。
この著作権における「引用」を捻じ曲げていいかどうか、というの話はすべての人にとっての言論の自由の確保という意味で、致命的に重要なポイントである。これを安易に捻じ曲げるような権利主張は極めて危ういとも思う。
STEP3、STEP4とかはアクションの担い手が限られるだろうとは思う。ただ、腐女子コミュニティもだいぶ拡大しているわけなので弁護士、研究者、経営者などの腐女子の方などが行動すれば決して不可能な話でもないのではなかろうか。
腐女子の人たちについて「二次創作やってる人たちはダブスタなんじゃねーの」問題。この件はダブスタとわかってて、恐縮しながらも、言うべきことは言おうという人と、なんもわかってない人が両方いると思う。
後者の人たちについては、わかってくださいね、というしかないと思う。自分たちだけが弱者で被害者という立場でないことは理解してほしいとしか。
＃あと、二次創作でも「作者公認系」とかもあるので、全てがアウトというわけでもないだろうが、今回問題になったものがどっちだったかまでは調べていない。まあ、おそ松さんとかは、公式も問題にしないタイプだから、公式との関係では、まあどうといった問題もないのだろう。
http://anond.hatelabo.jp/20170527202448
流通プラットフォームが変わるごとにちょっとずつ腐界隈の慣習と、
実態との関係性もちょっとずつ変質していっているという話だと思う。
その変化にあわせてぼんやりした慣習だと、運用に失敗しました、というのが今回の話なんだと思う。
オタ界隈は、かなり基盤技術の変化がはやいので、この変化に対応できるような基準が成立しないと、この手のことは何度も起こるのだろうなと思う。
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
気に入ったものを繰り返し見続けることがある。
一日に5回とか。それが数週間。
子供が気に入ったアニメや絵本をずっと見続けようとするのによく似てる。
まあ、そんな音楽です。
------------
JUNGLE FUNK
https://www.youtube.com/watch?v=0_JJqdWSJuA
リヴィングカラーのリズムセクションの 2 人と Vinx のユニット jungle funk の曲 "TORN"。
ひたすら美しく切ない。
ウィンビッシュのベースはデリカシーのある美しいコード進行を多彩なパターンでメロウこなしているが、
ガっと行くトコはきっちり行ってて、甘さだけにならないのが本当にうまい。
パーカッション(壺かな？)のオーガニックなリズムが、控えめだけど強いビートを一貫して曲に与え続けている。
そして、歌とコーラスワークの美しさにおれの涙腺は何度でも崩壊するわけです。
ちなみに、エリックゲイルズがギターを弾くインストバージョンが下記。
これも良い。
ウィンビッシュが弾いてるところが見れるのがうれしい(凄すぎて何やってるかさっぱりだけど)。
John Page Classic Presents “TORN,” featuring Eric Gales, Doug Wimbish & Will Calhoun
https://www.youtube.com/watch?v=WeefVD1668w
-------------
Chantae Cann All I do Cover Live HD
https://www.youtube.com/watch?v=i5liTAUdFHQ
最近はあんまり参加してないっぽいけど、スナーキーパピーの鍵盤の人として知られるコリーヘンリーのライブ。
見どころはシャンティーカンの歌！歌！。スナーキーのプロジェクトでもよく歌ってるけど、それほど
アピールする歌い手には見えなかったんだよね。けど、こっちは本当に良い。
ちょっとチャイルドボイスで、べったり歌い上げる感じにならない乾いた感触がステキ。
バックは結構いかつい演奏してるのに、そこからさらに2歩も3歩も前に出るパワーもさすが。
それこそ何度も聴いたけど、後半のロングトーンは何度聴いてもドキドキさせられる。
下のはたぶん同じライブの別な曲。これも上とセットでずっと聴いていた。
Cory Henry Plays Gnarles Barkley's "Crazy" feat. Chantae Cann
https://www.youtube.com/watch?v=xp8UCpHk-vk
-------------
North Mississipi Allstars - Turn Up Satan
https://www.youtube.com/watch?v=p1rLGrLAXQ0
NMA のブギ。
一見何のひねりもないミドルテンポのブギのようだけど、現代的な工夫が多く盛り込まれていて退屈させない。
逆かな？。今時のポップソングに典型的なブギのリフを再利用して見せたのかもね。
いずれにしてもそうした要素を中毒性高くパッケージした NMA の手腕はさすが。
ギターソロ開けにリフに戻ってくるとこなんか立ち上がって踊りだしたくなる。
使い古された何の変哲もないギターリフが強烈な輝きを取り戻す一瞬と言って良いと思う。
ルーザーディッキンソンは本当にうまい人で、ブラッククロウズのこの曲も執拗に聴き続けた一曲。
後半のソロは何度聴いても胸に刺さる。
The Black Crowes - Oh Sweet Nuthin'
長く書きます。お金の話の経験とかも、少しでも参考にしてください。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない
お金のない環境を整えられない学生はつらいよね。明らかに札束で殴れず時間を使って損してる。
twitterできないメインで使えないのもまず、重すぎるからっていうのもありそう。
スペックが足りてなさすぎる。まずは６，７万出してスペックを整えよう。
すごい人たちは幼少の頃からパソコンがあって、パソコンをいじるだけの時間があって、承認されてる。
しかも、コミュ症だとかなんだかんだ言いながらも、ネットではきちんと弾けてるし、人望もある。
彼らを理解するのはすっごく難しい。
経済格差が多すぎて、彼らが積んできた経験と持っている環境が違いすぎるから。
プログラム自体は数学を解くようですごく楽しいのだけれど、なぜ苦しい勉強をしながらプログラムをずっとやっていられるのかわからない。
環境はMac（高すぎて揃えるなんてとんでもない）じゃないから、先人たちの簡単に手順化された知恵を受けづらく、プログラムの環境をととえるまでが大変だし、
ライブラリ関係のエラーコードは自分の力で、ライブラリを見つけに行かないとダメで、ウェブで検索しても彼らよりもずっと時間がかかる。
そこをきちんと理解したうえで、自分がどこまでやりたいのか、どうしてやりたいのか
自分はプログラマに向いているのか、考えながら、勉強していったほうが良い。
ちなみに私はプログラムを解くの好きだったし、ある程度は得意だった。
ADHDと自閉症混じってるから、だから職人的なことをやりたかったし、テストをかけば不注意で大きな損失を出す可能性も低くなる。
だからプログラマを目指しているし、プログラマとして就職するつもりなんだよね。
私も無名で、プログラム力的にはpaizaのSランクは、後ちょっと足りない、運が良ければ成功するんじゃない？ってレベル。
ツイッタランドのすごい人たちは目指すと疲れるだけなのでほどほどにね。
彼らは多分余裕綽々でS取れる。
paizaの出題は競技プログラムの一種で、競技プログラムっていうのはある程度出題の仕方が似通ってる。
複数回解いていると昔に残ったコードとか再利用できたりするから有利になるっていうのもある。
ゲームで例えるとRPG好きな奴にFPSやらせても全く活躍できないけど、FPSが得意な奴に別のFPSゲーやらせてもできたりするでしょ。
開発のジャンルの違いがあることは覚えといて。
Mac買えなくて開発環境として選ぶなら,windowsよりlinuxのほうが良い。
windowsだと環境整える前にストレスがやばいし、パソコンが死んだ場合のストレスもやばい。
あと、古いパソコンだとUSBブートができなかったのも割とめんどくさかったし、回線がめちゃくちゃ低速だったから、ISOファイルのダウンロードに半日かかってたかな。
VirtualBoxはすごいスペック持っている人が使うものなので、買い換えないならクリーンインストールかデュアルブート推奨。
ubuntuにしとけば、ウイルス系もあんまり構う必要性がなくなるからね。
起動にVirtualBox起動に数分待って、端末以外を使おうとすると固まるみたいなことやってると辛さが溜まるから。
デビットカードでも行ける。
するが銀行に口座を作ってデビットカードを申しこめば、２０歳以下でもなんとかなる。（年齢によっては親の同意は必要だけど）
２，３週間かかるけど、デビットカード作っておくことで色々なサービスを体験できるようになるのは選択肢を増やすにあたって重要なことだから是非。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
ネット上は怖い人もたくさんいるし、まさかりがちょくちょく飛んでくるけど、変にウケると拡散してくれて色々な人が声をかけてくれるのも確かだったりする。
ゆっくりと自分の使い方を覚えていけば少しずつ楽しめると思う。
実際、SNSは情報の精度としては当てにならないし、勉強のためってSNSを使うとストレスで辛くなった。
自分の好きな人だけをフォローすると精神安定するよ、あとフォロー返しはやる必要はない。やってるとTL荒れるからね。
（リストとか使いこなせるなら別なんだろうけどね）
おすすめ度は◎○△であらわす。
おすすめ度：◎ 条件：最低で６，７万円のお金が必要。 おすすめはlenovoのeシリーズ。 重いけど、コスパは良好比較的安めに上がってキーボードも打ちやすいのが良い。 いまはcorei5, メモリ8GBの使ってて、大体（重めのゲーム以外）したいことはなんとかなる。 SSDはあったら便利だけど、一番重要なのはメモリな。 開発したいなら８GBは必須。 （苦労話： 古すぎてノートなのにキーボードを常時接続必要だったり、画像が多いサイトはブラウザを選ぶ必要があったり、何よりもIDEが使えなくて辛かった。 windows vistaのupdateで数日固まったり、ゴミでしかなかった。 ）
おすすめ度：◎ 条件：契約できる年齢か、親の同意（年４万円くらいの出費）が必要 何をするにもまず回線速度が遅いと話にならない。 IDE落としたり、クラウドにファイル上げたり、AWS使う時のアップロードとか、音声会話とか。 〇〇をしてみたいと思ったら,ダウンロードに時間がかからないことは、モチベーションのためにめちゃくちゃ大切。 （苦労話： ISOファイルをダウンロードするのに半日かかるのが普通だと思ってたけど、 まともな光回線＋まともなルータを利用したら、ダウンロードに１時間ちょいになってびっくりした。 特に古いルータだったりするとボルトネックになったりする。 ）
おすすめ度：○ 条件：linuxで生きていくという覚悟 windowsよりは快適。 他のlinuxISOファイルを焼いたりするときにちょっと苦労するかもしれないし、軽いの選ぶと良いかも。 実際普段使うものがネットとプログラムツールだけだったから、なんとかなったし、ゲームの選択肢が強制的に排除されるので、 少しはプログラムに触りやすくなるかもしれない。 （苦労話： エクセル、パワポ必要とか言われた時に、officeのレイアウトで死んだりする。 資料はPDFな。 買い換えない場合のクリーンインストールは↓ 昔のパソコンでもLinuxとか入れればそれなりに動くよっていう人はいるけど、やっぱり社会的な通信網と平均的なマシンスペックが上がっているせいで、ウェブ自体が要求するスペックも上がってて低スペックだとつらい。 ブラウザはw3mとか使って、端末タブを開いてvimで開発してた。 なんでかって言うと普通にブラウザ使うとレスポンスが重すぎたから。 でもその使いづらさの分だけ損してるんだよね。 ）
おすすめ度：○ 条件：電車代などの交通費を用意可能 できること： 他人に触発されるタイプなら、すごい人たちの興味の方向を見て学ぶ方向が増えるかもしれない。 後は交通費と宿泊費の出る勉強会なんてものもあるので応募してみると良いかもしれない。 高校生なら、交通費出してくれるっていう太っ腹な勉強会もちらほらある。 一、二回は顔出し推奨。 欠点はあって、コミュ症は治らないので、友達ができるとは限らない。
おすすめ度：△ 条件：家庭環境による できること： 自分の向上心による。 大学生になって一人暮らしになったら、パソコンに触れる時間は多くなったとは思う。 （勉強しているとは言っていない）
おすすめ度：○ 条件：３，４万円の出費 できること： まず、パソコンを長時間触っていても疲れなくなる。 デスクの高さと椅子の高さはとても大切なもの。 疲れなくなるし、指が攣りそうになることもない。 机の高さはきちんと調べたほうが良い、あってることが重要 今使っているのは１万ちょいの新品デスク（ニッセンのフリーテーブル）と３万弱の中古のオフィスチェア 基本的に３０００円位のデスクは耐久性と高さがゴミだったりするので注意。 机は http://blog.livedoor.jp/itsoku/archives/38727329.html の６６のテンプレを見ておくと良いかな。 （苦労話： しかもノートパソコンでデスクと椅子がなくて狭いこたつの上か100均で買ってきた台の上で、パソコンを使っていたからパソコンの位置の高さが合わなくて姿勢がどうしても悪くなるせいで長時間パソコンをいじることもできなかった。 後は寝ながらパソコンをいじるみたいなみたいな堕落生活してたら、筋肉が硬直してまともに手を握れなくなって、医者にかかることになって１万円程度お金がかかったし、 ２ヶ月位まともにパソコン触れなくなった。 ちょうどその時期は、筆記用具をほとんど使わない単位だけだったから良かったものの、他の単位とってたらもっと治療に時間がかかったかもね。 ）
おすすめ度：○ 条件：それなりのスペックのパソコン、それなり大きさのディスプレイ できること： 設定しなくても、複数のファイルから補完が聞くし、フォルダ内の全てのファイルから検索、置換ができるのが良い。 ただし、ディスプレイが小さいと実際に開発できる範囲が小さくなるのは注意。 （苦労話： IDEは普通に使えるなら作業効率が全く違って、設定少なくても補完も他のファイルやライブラリから保管してくれるたりする。 でも、昔の環境だとeclipseはフリーソフトだけど環境整えるまでが辛いし、重いしで、開くとブラウザすらまともに操作できなくのが辛い。 だから、ブラウザでチュートリアルとか見ててもパソコンに待たされてストレスだった。 まともに使うには設定がめちゃくちゃ必要なのは実際疲れた。 （ac.jpのメールアドレスは必要だけど）学生無料なIDEでjetbrains製品があるけど、設定しなきゃダメなvimとかと違ってマウスで操作できるのがすごい良い。 端末ではコピペが簡単にできなくて、数は少ないけどよくあるミスが、間違えてcommandモードで貼り付けてやり直したり、vimのline numberの設定をいじらずにvimからコピペができる。 コレだけでイライラ具合が全然変わる。 ）
おすすめ度：◎ 条件：図書館や図書室で本を注文できるか、本があるか できること： プログラムの能力が向上する。 おすすめされている本を探すと良い。 プログラム初学者なら、ネットだけで勉強するよりは効率がある。 とりあえず、やりたいことなくて、プログラム力をただ上げておきたい場合は、 競技プログラムやりたいとしても下の順番で進めると良いかもしれない。 あと、プログラムには自分が到達しているところまでで言うと、次の順で壁があって能力が足りないと行き詰まることがある。 >> 関数化 → クラス化 （→ ポインター） → 再帰 → 関数型言語 << 数年かけて勉強して次の段階に勧めないならプログラマは諦めたほうが良いかもしれない。 （能力が足りないのは上司も自分もつらくなるよ）
おすすめ度：○ 条件：１万円弱のお金 できること： ノートパソコンなら２個の画面を使えると作業効率が違う。 特に手打ち系のコーディング練習とかがめちゃくちゃ捗るようになる。 （苦労話： IDE系列は画面を割と占拠するので、ノートパソコンの狭い画面だと辛い。 でも大きすぎる画面だと持ち運べなくなるのでダメ。 画素数が上がればその分だけ小さく表現ができるので、画面サイズが同じでも画素数が違うとかなり大きさが違って見えたりする。 ）
おすすめ度：○ 条件：学力があること努力すること、覚悟 できること： 奨学金を利用して環境を整えたり、時間が増えるから更に勉強できる。 プログラム関係もそれ以外も就職先が増える。 また、これからの転職したくなった時に逃げ道が増える。 欠点、国立は安いけど、入学にそれ相応の努力が必要。私立行けるなら、苦労してないと思う。 あと免除制度っていうのがあるから、そういうのも利用しつつ費用を安く上げよう
おすすめ度：○ 条件：年齢（か、親の同意） できること： ちょっとした電子払いができるようになる。 多重債務は起こらない。 欠点としては、定期払いはできないので携帯の契約とかはできないことに注意。
低スペックのパソコンしか無いのは、多分家庭環境のせいでもあって、
君がアルバイトもできるかどうかわからないし、アルバイトしてもそのお金が君のもとに入ってくるかはわからない。
お金も無限にあるわけじゃないし、時には経済格差を感じて辛くなることもあるだろう。
少ないお金の中でうまくやりくりして、それでも自分の力にしていってほしい。
（お金が潤沢にあるなら親を説き伏せることをがんばって）
応援してるよ。
「Ubuntu」とは、「他者への思いやり」のことです。この単語自体が、人間としての精神を体現しています。
我々は、生産的で、幸福で、複雑な領域における新しい発想を歓迎できる柔軟性を持ち、また、あらゆるプロセスを常に改善し、さらに、各々が全く異なる要求や関心、能力を持つグループの間の協力を促進するコミュニティを希求します。
我々は、メンバーの多様性によってコミュニティを強靱なものにするために、多様な参加者を活発に探します。このUbuntu行動規範は、多様なグループがお互いの利益と喜びのために協調することを確実にするために存在しています。我々は、誰であっても、プロジェクトへの参加に障害がないよう努力します。
行動規範は一般的に、公的であれ私的であれ、我々がどのように振る舞うべきかを統率します。我々は、プロジェクトの代表者（公式・非公式を問わず）、関係者、そして直接の参加者が、このUbuntu行動規範を尊重することを望みます。
我々は、下記に真剣に努めなければなりません。
我々の成果物は他者によって使われるでしょうし、また逆に他者の成果物にも依存しています。いかなる決定であっても、利用者や関係者に影響を与えることを頭に置いて、決定をするときにはそのことを考慮する必要があります。
意見に相違があるからといって、無礼な振る舞いをとってはいけません。衝突を解決するために協働し、他者が善意で行動していると仮定し、親身になるよう努力しなければなりません。苛立ちが個人攻撃に発展することがあってはなりません。不快感を覚えたり脅威を感じるコミュニティは、生産的ではありません。
間違いを犯すことは誰にでもあります。そのときには、責任を取らなければなりません。もし誰かが傷つけられたり攻撃されたときには、注意深く、そして思いやりを持って意見を聞き、間違いを正すよう行動しなければなりません。
我々が作り上げようとしているものは複雑で、それぞれに想いが込められたたくさんのパーツでできています。各々が違ったゴールとビジョンを持つチームの間での協調は不可欠です。ただのパーツの組み合わせ以上の成果物を作り上げるには、各々のパーツが全体を理解するよう努力しなければなりません。
協調して取り組むことで、冗長な作業を減らし、品質の向上につなげることができます。プロジェクトの内外を問わず、協調することは大切です。可能な限り、アップストリームのプロジェクトと共同で作業し、フリーソフトウェアのコミュニティと協調することが必要です。透明性を確保し、その作業に関心を持つ人とはなるべく早期から協働するのが良いでしょう。
社会的な、あるいは技術的な意見の不一致はよくあることです。しかし、意見をまとめずそのままにしたり、何を合意したのかを不明確なままにして他の人を悩ませることがあってはなりません。
プロジェクトの参加者は、意見の不一致を建設的に解決することが期待されています。もしも合意に至らなければ、あらかじめ決められたリーダーに仲裁を依頼し、透明性 (clarity) と指示を求めます。
誰であっても、完璧であることを求められてはいません。誰かに質問することは、後で発生するであろう問題を回避できるので推奨されます。ただし、適切な場所で質問してください。質問を受けた人はすぐに反応し、手助けしてあげてください。
プロジェクトを離れるときには、与える混乱を最小限にするよう動くことが求められます。プロジェクトから離れることを他の人たちに伝えて、離れる人が作業を中断した地点からほかの人たちが再開できるようにしてください。
我々は、実例と議論と行動によって動かされます。新しく参加した人は、もしプロジェクトの改善につながる新しい考えがあれば、ぜひ人々を率いて、行動を起こしてください。リーダーシップは、行動を起こすことだけで誰でも実践できます。その機会があれば、誰かの許可を待つ必要はありません。
プロジェクトに関する責任は「慈悲深い独裁者」を頂点として、そこから特定の範囲について責任と権限を委任されたコミュニティ・カウンシル、その下にいるチームや委員会 (councils) 、個人に委任されていきます。コミュニティ・カウンシルまたはその代表者が、争いごとの解決を行います。
我々は実力主義に基づいて、意思決定や統率、リーダーシップを、長く参加している人から、能力があって関心の高い候補者に委任していきます。
評議会 (boards) や委員会 (councils) への任命は、コミュニティ・カウンシルが決定権を持ちます。ただし、事前にコミュニティに対してインプットを求めるものとします。
リーダーシップは、表彰や権利や肩書きではありません。リーダーシップは権限であり、そこには責任が生まれます。リーダーシップはコミュニティから委任されたものです。リーダーの権限は、委任するコミュニティから支持されている間だけ得られるものです。
我々は何かものごとを決める前に、意見やデータ、関係者からの意見表明を集めます。リーダーの役割として、チームが決定を遅滞なく行う手伝いをし、ガイダンスを与え、合意に至らなかったときに決定をし、決定の実施に責任を持つことが期待されています。
何かを決めないことには、先に進めません。明確な指示には価値があります。ときには、データが足りなかったり、合意が得られがたいこともあるでしょう。それでも、何らかの決定を下さなければなりません。いつでも完璧な決定を下せる保証などないのです。決定を先延ばしにするより、失敗して、失敗に学び、将来の役に立てることが大切です。
我々は、問題をより把握しているチームを信頼して決定を下してもらうことで、プロジェクトはよりよいものになると認識しています。もし決定に不満があれば、それを下したチームと調整します。調整が付かなければ、その決定についてレビューする統治機構 (governance structure) があります。つまるところ、責任を持つ人が決定を下し、それがプロジェクトの統治 (project governance) に支持されていれば、その決定は有効であるとします。我々はある決定について納得しないこともあるかもしれませんが、それでもプロジェクトを信用し、たとえ内心では違うほうがよいと思っていたとしても、プロジェクトとしてその決定が実施されることを支援します。
誰であっても、どの組織に所属していようとも、どのようにプロジェクトに関わろうとも、我々は参加を歓迎します。コミュニティは開かれたものであり、能力や適性を持っていることを示せれば、職責を負うことができます。
「名演奏家はその演奏によって評価され、リーダーはチームの行動で評価される」リーダーは、行動すべき・身を引くべきときを知っています。チームは、リーダーに権限を渡したりそれを取り戻すべきときを知っています。
良きリーダーはスポットライトを浴びようとせず、他のメンバーの活躍をたたえます。リーダーはチームメンバーの中で目立つ存在でしょうが、良きリーダーはその注目を他のメンバーの優れた活動に対してスポットを当てるために使います。
リーダーはときに、理解されず、合意に基づかず、一般的ではない冒険的な決断を下す必要があります。我々は、完全な合意を得るよりも物事を進めることを優先し、勇敢にもそのような決定を下すことを評価します。とはいえ、冒険的な決断には十分な検討が必要です。ある人にとっては頭の痛いことになるかもしれないことを肝に銘じ、影響を抑えるようにしなければなりません。変更について、その理由を明確にして、そして早めにコミュニケーションをとることは、その変更を実施するのと同じくらい重要です。
もしもリーダーが自身の雇用関係や他のプロジェクトとの関わりによって利益相反状態になっている場合には、それに気がつくことが期待されています。そして、私利私欲のためとみなされることのないよう、棄権したり決定を誰かにゆだねたりすることが期待されています。リーダーに限らず全てのプロジェクトメンバーにも、私利私欲のためではなく、ユーザーの暮らしをよりよくするために決定を下すことが期待されています。
もしも利益相反が疑われる場合には、誰かにセカンドオピニオンを求めてください。利益相反状態にあることを明らかにすることが、解決への道筋にとって重要です。リーダーは、たとえ一般的ではない、あるいは特定のグループに有利・不利となるように思われるものであっても、決定が信用できるものとなるよう行動すべきです。
このUbuntu行動規範は、網羅的でも、完全なものでもありません。ルールブックでもありません。協調的で共用の環境 (a collaborative, shared environment) とゴールに関する、我々にとっての共通の理解を引き出すためのものです。
このUbuntu行動規範は、クリエイティブ・コモンズ 表示 - 継承 3.0 非移植ライセンスのもと配布されます。あなた自身のプロジェクトにこれを再利用することができます。また、好きなように改変することもできますが、あなたの改変を他の人が利用することも許可し、Ubuntuプロジェクトの著作権表示を付けるようにしてください。
何かと取り上げられる原発関連問題についてですが、「エネルギー資源の点から原発再開・高速炉建設は現状止むを得ない選択肢である」というのが今の私の考え方です。
「石油はもって40年」と自分も子供の頃からそう言われていて、いまいち危機感が持てなくなっているけれど、少なくとも自分が子供のころはレギュラー90円切るようなのが当たり前だったと思うし、確かに昨今の不景気が影響で価格が高騰しているということもあると思いますが、客観的な事実として、天井のある資源を使い続ければいずれ枯渇することは当たり前だと思います。
エネルギー資源の枯渇が引き起こすのは奪い合いであるといったことは、歴史的に見ればある程度自明だと思います。
今の時代、簡単に資源を巡ってすぐさまに戦争が引き起こされる、といったことは想像しにくいですが、少なくとも産業や経済に制限がかけられることと思います。
そのような情勢において「原子力」というエネルギー源の選択は、再利用技術の確立が為されればかなり明るいと思います。(しかし3.11のような経済的コストや、使用済み燃料やそれに付随して出る汚染物質の処理のような将来的課題もまだまだあります。)
これらを踏まえ私が感じているのは「戦争への抑止力は、資源の生産・確保であり、原子力はその点で抑止力と成り得る」ということです。
某漫画の1コマに「戦争は始めるものじゃない。出来る限りの外交の手段を尽くした上で結果的に起こるものだ」とありますが、この「出来る限りの外交手段」を選択肢として存在させることが重要であり、エネルギー資源はそこに深く関わっていると思うのです。
一方で原子力の利用は、今の日本の風潮ではかなりシビアなものだという感覚をみんな持っていると思います。私は原子力関連においても最もネックなのはその感覚自体と、“安全”を砦に原子力を危険なものとただただ批判する人間がいることだと思います。
将来のエネルギー安定性と現在の安全なエネルギー供給を秤にかけることは、個人個人で優先すべき事柄が異なるのでどちらが重きとなるかは一概には言えません。ですが、私は原子力というものに“危険なもの”という偏見(バイアス)がかかっているために、秤にかけるまでもなく忌避しているような点があるのではないかと思うのです。そしてそのようなバイアスを布教・助長している各メディアなどのコメンテーターや評論家を見ると、嫌気がさします。「原子力=原子爆弾」という偏見さえも未だに存在するような気もします。
一般に「多少原油輸入にお金はかかっても現在日本の電力は間に合っているんだからいいじゃないか」という意見もありますが、私はこれが対外的には一種の侵略(エネルギー侵略)のようなものではないかと感じています。
話は変わりますが、2000年代に大きく話題になった「地球温暖化問題」というのがあります。温室効果ガスである二酸化炭素が増えることで、地球の保温効果が高まり、平均気温が上昇するという話のものです。(反対論として、地球の平均気温は常に上下を繰り返しており、その周期がいま暖かくなっているだけだとの説はありますが、自分は少なくともCO2の影響で温室効果があるのなら、地球の周期があるにせよ、減らす努力はするべきだと考えています。すみません関係ありません。)
この地球温暖化問題に関して、一部ですが「日本が温暖化問題を加速させている」という説があったように記憶しています。日本という国は自国には森林がたくさんあるにも関わらず、安価であるという経済性の理由から他国の木材を多く輸入しており、その木材はアマゾンなどで森林を伐採して得られているため、日本が温暖化を加速させている原因になっているのではないかというお話です。つまりエネルギー資源においても、自国で生産しない代わりに他国から輸入しますがそれは他国の資源を侵略していることに等しいのではないか、と感じるのです。(確かに資源を輸出するのもその国の自由ですし、対価を払っているのですから問題は無いというのもありますが、自分はあまりこのような動向が良いとは感じません。)
自分はこの地球温暖化問題の点と、化石燃料を輸入してでも国内の電力供給を支えている現在の日本の状況に、類似点を感じます。
原発を停止し化石燃料を輸入することで国内需要を満たすことは、地球全体の資源をより早く消化してしまうことになっていると考えます。この点で、確かにこれも輸入された燃料ではありますが、再利用することが可能である原子燃料を利用することは、これからの将来を考えて資源的に選択することは仕方が無い、むしろ必要なのではないかと考えています。
1国がこの広い世界での資源枯渇を心配する必要があるのかと思われますが、その広い世界で資源が枯渇した場合に行われるのは、「その資源を持つものが高い対価で取引を要求すること」か、「他国が略奪を行う」か、「新技術によって新たな資源を生産する」か、のどれかだと思います。
少なくともこの中で一番良いのは「3つ目の資源の生産」で、いわゆる「核融合」技術が現状あてはまると思います。しかし、現段階で研究ベースの技術が商用化され、多くの人に利用されるようになるのはいつ頃かもわからない状態で、「いずれ新技術ができるから化石燃料を使い果たしても問題ない」というのは楽観的すぎると思います。
再三になりますが原発関連に関して思うことは、原子力という技術や将来性について議論することをせず、消費者が被害者意識だけで言葉を揃えて「安全じゃないものは使えない」「間に合っている」と言うのが、個人的にはあまり好きじゃありません。
そして原子力に技術者として関わっている多くの人々や、また原子力を使うことを決めた政治家や多くの人々を責め立てることも好きじゃありません。
福島第一の事故は確かに人の作り出したものが災いしたものですが、想定されていなかった規模(過去数百年の津波高さの統計による)の津波という自然災害によって起きたという部分が色濃いと思います。事故は結果論でしか語ることはできませんが、これまで原子力を扱ってきた人々が事故を防ぐべく尽力していたこと、またこれからも努力なさるだろうことも忘れるべきではないと思います。
最後になりますが私は、何か意見をもって議論することが大切だと、EU離脱の時のイギリスを見ていて思いました。その点で思うのは、自分の意見を言うことでレッテルを張られる、もしくは感情論で批判されるような風潮・雰囲気を壊していくことがいまの日本には大切なんじゃないかなと思います。
毎日、職場には妻の愛妻弁当を持っていっている。美味しいし、栄養バランスも取れていて、家計の節約にもなっているので、いつも感謝しながら食べている。もちろん食後にはLINEでおいしかったよと感想を伝えている。
いつもはお弁当箱とそのセットになったお箸を使っているのだが、妻がお箸を洗うのを忘れていたらしく、当日の朝にお箸を洗うのを忘れてたので今日は割り箸入れてるよ、割り箸で食べてね、と言われた。こちらとしては割り箸だからといって特段困ることもないので、了解と言って家を出た。
昼食後、使った割り箸を紙の箸袋にしまって、お弁当箱とまとめて家に持って帰ったら、「なんで割り箸持って帰ってきたの？バカじゃないの？」と言われた。たしかに一度使った割り箸を再利用するつもりはないし、なぜ持って帰ったのか？とわざわざ聞かれると答えに詰まる。しかし、箸袋に仕舞ってあるので、周りのお弁当箱を汚したわけでもないし、家から持って行ったごみを職場のごみ箱に捨てるのも申し訳ないし、何より何も考えずにいつもの癖でお箸を仕舞ったような気もする。なので、なぜと聞かれると答えるのは難しいが、なぜと聞くほどの質問なのだろうか、とも思う。
増田長い人は知ってるかもしれないけど、
自分の記事は求人サイトなど公式情報と呼べそうな内容を列挙しただけの内容で、
削除申し立てする意味がよくわからない内容だったように記憶している
別に争う気もなかったので削除自体は構わないが、面白いなーとは思った
知らない人もいるかと思ったので記録として残しておく次第
Subject: 【はてな】はてな匿名ダイアリーのご利用につきまして __________________________________ このメールに返信する場合、上部の線より上の行に文面を記載して下さい また、上の線を削除しないようにして下さい ------------------------------------------------------ 2015/**/** | **:**PM JST はてなサポート窓口 ( cs@hatena.ne.jp ) こちらははてなサポート窓口です。 以前にはてな匿名ダイアリーにご投稿いただきました記事に対し、 記事にて言及されている株式会社＊＊＊＊代表取締役の代理弁護士より 削除の申立がございましたので、削除を行いました。 元記事に＊＊＊＊＊＊＊＊として言及された店舗の元会社として記載されて おりますが、そのような関与はしていないとの理由での申立てとなります。 通常、このような場合意見照会を経て削除を行っておりますが、はてな匿名 ダイアリーでは、言及された当事者より削除の申立があった場合には、 原則として発信者への意見照会を経ずに削除を行っています。 ご了承いただきますようお願い申しあげます。 なお、今後同様の言及を続けられた場合、はてラボおよびはてな全体の サービス利用停止措置などの対象とし、別のアカウントを取得しての 再利用もお断りしますので、ご注意いただきますようお願い申しあげます。 詳しくは、下記のヘルプや告知をご参照下さい。 http://anond.hatelabo.jp/help http://labo.hatenastaff.com/entry/2014/09/04/182358 <今回削除した記事> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ http://anond.hatelabo.jp/2015********** ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ ＝＝＝＝＝＝＝＝＝＝ はてなサポート窓口 cs@hatena.ne.jp ＝＝＝＝＝＝＝＝＝＝
当時そこそこハマっていたGTOの影響で「やべー、ヤラハタになっちまったよｗ」などと友人たちと自虐的にはしゃいでいたことを今でも時折思い出す。
愛すべき彼らは全員めでたく結婚した。結婚式はどれも極めて感動的だった。
対して、私は未だ童貞だ。
ヤラハタどころの騒ぎではない。ヤラサーである。魔法使いになれるという都市伝説もあるが、そんな救いは当然なかった。
ヤラサー男を待ち受けていたのは、魔法などという甘ったれたファンタジーではなく、極めて地続き的などうしようもない現実だった。
前髪の大多数は生えることを諦め、年に一度の健康診断では「肥満」だの「高尿酸血症」だのとディスられ、脇と足と耳の裏が存在感を主張し始める。
努力次第で何とかなる部分もあるし、もうどうしようもない部分もあると思う。
しかし重要なのは、今更見た目をマシにする努力を行う意義を見出せないということだ。
私は２３歳で運転免許を取得した。当時の免許証を未だに持っているのだが、写っているのは（あくまで今の自分と比較してだが）それなりにシュッとしている若者だ。
でも、こいつでも駄目だったのだ。このシュッとしたいい感じの青年でも、箸にも棒にも掛からなかったのだ。
それなのに、今更「そこ」を目指したところで何になるというのだ。
痩せてようが、髪があろうが、比較的臭くなかろうが、どうしても女性と付き合えなかったのが私という男なのだ。
……なにか雑音が聞こえる。
童貞の大抵の悩みはソープに行くことで解決する。なるほど、よく聞く言説だ。
実際、私も真に受けた時期があった。
まずは捨ててみよう。「初めての女」などに拘ってる場合ではない。そう思い、私はプロのお店で経験を積むことに決めた。２８歳の頃だ。
いきなり本番は怖いから、まずは練習のつもりでピンサロを予約した。
念入りに身体を洗い、歯茎から血が出るくらいの勢いで歯を磨き、ヒゲを剃り、鼻毛を切り、ついでに指毛まで抜いた。
そうして挑んだ初風俗は、結果から言えば、実質的には２分で終了した。
その店では、嬢と顔を合わせたらすぐにシャワー室に連れていかれ、身体の隅々を洗い合うというサービスがあった。そこでもちろん、ちんちんも洗われたのだが……。
「あっ、すいません、ちょ、ちょ、あっ……」
一応、９０分コースだったため、その後もすべてのサービス（身体舐め、フェラチオ、素股等）を受けることはできた。
しかし、私は「射精しないこと」だけに全精力を注いでいたので全く楽しくなかったし、それにも関わらず、結局５回も射精してしまったという体たらくだ。
私は早漏。どうしようもなく、早漏。セックスもまともにできない身体に産まれ落ちていたことに気づいた２８の夜。
奇跡的に女性とセックスができる状況に持ち込めたとしても、私は所詮、シャワー室で射精してしまう男だ。
恐らく、フラれはしない。私なんかと付き合ってくれる女性のことだ。きっと優しく笑って許してくれるだろう。
しかしだ。彼女の宙に浮いた性的興奮はどうすればいいのだ。可哀想だろう。
……いや違う。そういうことではない。
単純に「私が」嫌なのだ。情けなすぎて想像しただけで死にたくなる。それが全てだ。
こうして私は、童貞でありながらすっかりセックス恐怖症となってしまった。
「TENGA」だ。「TENGA」の刺激に慣れることで、少しでも「持ちこたえる」ことが出来る身体になりやしないだろうか。
そう思い、５０回以上再利用できるタイプの「TENGA」を購入した。５千円もした。
しかし、毎日根気強く使用することで、少しづつ持続時間は延びた。
今では１分半は耐えられる。
ちなみに、射精した後の「TENGA」はもちろん、水洗いして乾かす作業が必要となる。
しかし、その後すぐに眠気に襲われるため、「まあ、いいか。どうでも」といった気分で次の日の何も起きない一日のために休息につくのだった。
つづく
