はてなキーワード: 再利用とは
一カ月ほど前にこの日記を書いたのですが、やっといい物件が見つかったので備忘録的に書いておきます。
私たちは最終的にLGBTとしてではなく、「友人同士のルームシェア」として物件を見つけました。
1.一度店舗に行き、イメージをかためおとり物件を確かめる
2.とにかく問い合わせる
3.色々な不動産屋を回る
基本はとてもシンプル&別にLGBTじゃなくてもごくありふれた方法だと思います。
どこでもいいので、希望する物件の近くの不動産屋に足を運びます。
そこで事前に調べておいた物件やほかの物件も問い合わせてもらいます。
ネットではなく実際に目の前で探してもらうことで、その後の物件探しもイメージがわくと思います。
私は一人では物件を探したことがあるのですが、それでもルームシェアとして改めて探しに行くとこんなにも勝手が違うんだと驚きました。
また、希望に近い物件が「おとり物件」かどうかもそこで確認することができます。
「おとり物件」はリスト化しておくと、後々不動産屋をみきわめるのに非常に役立ちます
勿論いい物件があればその場で契約してもいいと思いますが、少しでも疑問や妥協するところがあれば保留しておいた方が無難です。
内覧にいくと多くの場合「ほかにxx人がこの物件見に来たらしいですよ」と言われますが、これは高確率で早く契約をさせたいがための不動産屋の定型文句なので気にしなくてもいいです。ただ1月2月など繁忙期はその限りでもないので、見極めが重要です。
よほどのいい物件でなければ、1件目で契約することはやめましょう。
希望の物件に、たとえ「ルームシェア相談」のタグがついていなくても、とにかく問い合わせをします。
大手賃貸サイトには必ずと言っていいほど「この物件について詳しく聞きたい方」という問い合わせフォームがあります。
そのフォームから直接不動産屋に問い合わせることができるのです。
その際に、下記の点に気を付けます。
捨てアドを作り、電話番号は絶対に教えない。
番号を教えると、当たり前ですが電話が来ます。不動産屋の電話はしつこいです。
年収を書く
「社会人」であり「支払い能力」があり「具体的に検討をしている」ということを相手に提示するためです。
引っ越しの時期もかくといいかもしれませんね。ただ3か月以上先の引っ越しの場合、ルームシェア関係なく、不動産屋としてはあまり相手にしてくれない場合が多いです。
メールの返信が「具体性がない」「とにかく店舗に来させようとする」不動産屋はダメです。
また、不動産屋によっては大家に問い合わせをせずに検索サイトで「ルームシェア相談」のタグだけを見て判断する人もいます。
きちんと問い合わせをしてくれた不動産屋は「問い合わせたところOKでした」「NGでした」と書いてくれる場合が多いです。
怪しい場合は前述した「おとり物件」を聞き、その返信で判断しましょう。
たとえ返信が「ルームシェアNG」でも、メールの返信に誠意がありそうで、かつコピペではなさそうであれば実際に不動産屋に訪問します。
特に都会ですと、同じビルの同じフロアに違う不動産屋が同居している、ということも珍しくありません。
そしてよく不動産屋のサイトには「ほかのお店の物件も紹介できることがあります!」と書いています。
これは、実は不動産業界は同じ物件データベースを使っており、そこに登録され「一般媒介」であればどこの不動産屋からも紹介ができる、という商売をしているからです。
ただ大本のデータベースは同じでも、その会社が利用しているシステムや営業方針によって紹介される物件に違いが出てきます。
同じ物件がいくつも表示されたり、また同じ物件でもサイトや紹介会社によって写真や掲載内容に差が出てくるのはそういった理由です。
コンビニにも特徴があるように、不動産屋にもそれぞれ得意なこと、得意な地域などがあります。
大手チェーン店が悪いというわけではないですが(まあ私の経験だと悪かったのですが)、同じ物件でも融通が利いたり、その土地に詳しかったり、大家と仲が良かったりなど、地場の不動産ならではの強みを持っているところも多くあります。
また、特定の不動産屋しかもっていない物件というのも実はあります。
一般媒介
専任媒介
専任媒介を任せられてる不動産屋は、当然ですがその大家と親密な関係を築けており、評価も高いです。
検索サイトでその物件が「専任媒介かどうか」を判断するのは難しいですが、記載があれば評価の対象に含めていいかと思います。
また、そういった「専任媒介」の物件があるため、できるだけ多くの不動産屋を回ることをお勧めします。
個人的な経験としては、「地場の不動産屋」で「専任媒介」で「その物件の管理会社も兼ねている」となおいいと思います。
その理由として「その土地に特化した物件をたくさん持っている」「ルームシェアなど特殊な契約も大家と交渉してくれる場合がある」
「地元に根付いており、顔が利きやすい」「全国チェーン店と違って規定や営業のノルマが緩い場合がある」などが挙げられます。
…といっても、そんな会社狙って見つけられるものではありません。
勿論、全国チェーン店でも「専任媒介」の物件を持っていて、親身になってくれるお店はあります。
たとえ地場の不動産でも客に高圧的な不動産屋はたくさんいます。
最終的にはもういろんなお店に問い合わせをし、実際に足を運ぶしかありません。
馬が合わない、会社の雰囲気がちょっと…という不動産屋は思い切って断ってしまって構いません。
長々と書きましたが、このやり方で1か月弱で私たちは希望の物件を探すことができました。
最後は根気と妥協の折衷案になるかと思いますが、そもそもの目的は二人が幸せに暮らせるための部屋探しです。
互いに思いやりと余裕を忘れず、明るい未来を目指して頑張りましょう。
部屋を探す上で、色々思うところがありました。
それぞれつらつら書いておきます。
実際に「NANA」「2DK」「オタシェア!」のように、フィクション・ノンフィクション問わず漫画にもなるくらい、割とよく聞く単語だと思います。
でも実は数ある物件の中で、ルームシェアを許してくれる物件って、すごく少ないんです。
ある日、私たちは全国チェーンの不動産屋さんへ足を運び、「友人同士のルームシェア」を許可してくれる物件を探してくれるよう依頼しました。
勿論、事前にネットでいくつか「ルームシェア相談」の物件を探し、そこがちゃんと許可してくれるかも合わせて依頼しています。
ですが、20件以上問い合わせて、可だったのは1件のみ。
詳しく聞くと、以下の理由でNGを出す大家さんが多いんだそうです。
実体験、人からまた聞き、単なる想像から、などいろんな理由でこのように考える大家さんがいるんだと思います。
なるほどこれらの理由は確かに納得しますが、同時に「別に夫婦や同棲カップルだって別れるし、契約者さえちゃんと決めてればいいんじゃないの…?」と思わないでもなかったです。
まあ問題を起こす確率と単なる心証の問題なんでしょうが…。確かにルームシェアをしようとする人は若い方が多く、騒音・契約関係で問題も起こしがちなのは理解できます。
それでもこんなに少ないとは、完全に予想外でした。
大手の賃貸検索サイトには「ルームシェア相談」や「ルームシェア可」のタグが付いている物件がよくあります。それを入れて検索すると、全部とは言いませんが、3割くらいの数の物件は表示されます。
そう思いがちなのですが、ところが実際に問い合わせると、そのほとんどが「NG」なんです。
NGの理由は上にあげた通りですが、正直利用者からするとおとり物件も甚だしく、問い合わせしないとわからないので本当にやめてほしいです。
2017年8月より、大手賃貸検索サイト「SUUMO」で「LGBTフレンドリー」というタグで検索が可能になりました。
その名の通り、「うちの物件はLGBTの人でもOKですよ」という、色々な方々の努力や理解の結果のたまものだと思います。
「どうせ実際に言っても断られるだろう」「そのために不動産屋に問い合わせて奇異な目で見られるのは嫌」という、ある意味被害者意識ですね。自意識過剰だとはわかっているのですが、二人とも第三者へのカミングアウトには抵抗があり、このタグは結局利用しませんでした。
基準は物件ごとなのですが、一般的には「収入の1/3」が家賃の上限だといわれています。
私の場合、希望する土地・設備を入れると家賃をぎりぎり収入の1/3に抑えることができました。審査の緩いところであれば通る額です。
そして実際、ルームシェア、LGBTカップルが、この単独で契約した物件に黙って転がり込むという形で成立している場合が多いです。
ですが、勿論契約書上に記載のない家族以外の人を住まわせるのは契約違反ですし、契約者が同居人から折半した家賃をもらう、というのは「また貸し」にあたり、これもまた日本では法律上NGです。※余談ですが、今はやりの民泊も法律上NGです。
「どうせLGBT自体国に認められていないんだし、そもそも金額的に一人で契約できるんだからいいんじゃないの。もう個人で契約しちゃいたい」と何度も思いましたが、以下の理由でなんとか思いとどめました。
正直最後が一番の理由ですけどね。でも、確かに世間に顔向けできない関係だからこそ、ここはちゃんとしたほうがいいのかなと思い諦めずに「本当にルームシェア可」の物件を探し続けました。
色々と情報を探していると、「UR物件」という言葉を目にするようになりました。
古い団地を再利用する国の計画で、専門の賃貸業者からのみ申し込むことができるちょっと特殊なタイプの物件です。
何よりうれしいのが、「ほとんどの物件でルームシェアが可」という点です。
たとえ友人同士でも、同性でも、「全員が契約名義人」となり「一定の収入要件」さえ満たせば、問題なくすんなり契約ができます。
私たちは二人とも社会人であり、収入要件も満たしているのでこの制度を知ったときはとてもうれしかったです。
古い団地を再利用しているため、築30年40年はざらにありますが、その中でも比較的築浅だったり、リノベーションをしている物件なども多く存在します。
最終的に希望の物件が見つかり、UR物件を選びはしなかったのですが、「他に決まらなかったらURにいけばいい」という考えは、その後の物件探しに大きな安心と余裕を与えてくれました。
ようやく物件を見つけて、そこが「ルームシェア可」だったとしてももう一つ試練が待っています。
一般的に審査は契約希望者の「年収・職業・就職先・年齢・人柄」などを判断し、審査します。
基準は審査会社次第なのですが、ルームシェアの場合、その年収の数え方に少し特徴があります。
単独審査
合算審査
単独契約
連名契約
二人ともが契約者となる
「単独契約」で「単独審査」の場合、家賃と年収次第では厳しいかもしれません。
大体の場合は不動産屋が事前に通るか通らないか判断できるのですが、ルームシェアの場合「審査に回したけど最終的にやっぱり大家がNGでした」とそれまでの努力をひっくり返すような結果になりうります。
これらの審査の形態は、物件次第では契約者に選択権はありません。
手書きなんて、入力も遅いし、あとで再利用も不便だしなんもいいことないって検討しなくてもわかるだろ。
手書きが便利って↓こういう本当にメモ書きで使い捨ての状況くらい。
http://image.kakaku.com/images/guide/icv/actual/fullscale/54be25c9-9c81-4d0b-bf58-bbcf41a26214.jpg
↓このレベルになったらガチで使えない。これが便利で使いやすいって言ってるオッサンとかダメすぎるだろ。
http://o.aolcdn.com/hss/storage/midas/91fdc6dd02690e20f6d82ccd4822099c/205753906/WG%3FS50.png
死刑制度の賛否について、実生活だとキチガイ認定されると面倒なので、本音と建前を使い分けてます。
自分の家族や大切な人が殺されたら、その憎しみ・恨みを晴らすために、犯人は自分の手で殺したい。(仇討ち派)
死刑制度があると、自分の手で殺すことが正当化されない。(死刑制度が仇討ちの邪魔になる)
死刑制度がなければ、自分が犯人を殺しても、自分が殺人罪を問われて死刑になる心配がない。(安心して仇討ちができる)
こんな理由を説明したら、お前は野蛮な奴だ!と叱られちゃうから言えない。
私刑は復讐の連鎖を呼び起こすからダメだという批判もありますね。
(例)6歳娘を強姦され犯人を射殺した母親 多くの親が「気持ちはわかる」(米)
http://japan.techinsight.jp/international/2017/09/yokote201709021811.html
アメリカじゃ被害者遺族が犯人を射殺する事件がよく起こってます。
遺族が本当に望んでいるのは、死んだ被害者が生き返ることです。
死人が生き返るなら、犯人にも死んで同じ苦しみを味わえ!と憎む必要もないでしょう。
しかし、死人が生き返ることはないので、その代わりに犯人には死んでもらいたいのです。
犯人が死んでも、被害者を失った喪失感は回復されないので、100%満足はできないけどね。
死刑制度は存続させるとしても、欠陥の多い制度なので改善の余地があります。
http://www.newsweekjapan.jp/stories/world/2016/02/post-4454.php
まずはけものフレンズプロジェクトの公式リリースから問題の部分を引用する。
しかし、アニメーション制作を担当していただきましたヤオヨロズ株式会社には、関係各所への情報共有や連絡がないままでの作品利用がありました。映像化プロジェクトとしては次回の制作を引き続きお願いしたかったため、情報は事前に共有してほしい旨の正常化を図る申し入れをさせていただきましたが、ヤオヨロズ株式会社からは、その条件は受け入れられないので辞退したい、とのお返事でございました。
コレに関してファンの間では最終話公開の一週間後に投稿された12.1話のことや、各種コラボ映像のことかと憶測が飛んだ。
しかし、12.1話については栗田穣崇ドワンゴ執行役員が問題ないと取れる発言をしている。
ドワンゴとしましては、権利者から著作権違反であるから動画を削除してほしいという依頼に基づいて削除しますので、動画が残っているということは今のところは問題がないということになります。 https://t.co/KAHFSbEm4p— 栗田穣崇Shigetaka Kurita (@sigekun) 2017年9月26日
各種日清やJRAからの発表があり、「KADOKAWAの窓口を通した」とのことで委員会の中心であるKADOKAWA側も認めていたと思われる。
ウマのフレンズ | Umabi - 今度の休みは、うまびより。
本サイトは『けものフレンズ』に関する正規のライセンス窓口である株式会社KADOKAWAを通じて、17年3月の企画段階から『けものフレンズプロジェクト』の許諾を得て制作したものです。
同時にこのコメントからは、けものフレンズ関連のコラボ等はKADOKAWAが受付をしているということが読みとれ、
おそらく個々に言及されていないアニサマの映像などでも、商用利用されているものは基本的に無問題と思える。
また、夏コミでirodori名義で出された本についても「けものフレンズプロジェクト」の許諾があり、問題はなかったと思われる。
つまり大前提として、現時点で商業分野での作品利用や、数々の映像についてはなんら問題はなかったと考えられるのだ。
ならば無償の行為……例えばたつき氏によるTwitterへのイラスト投稿が問題になった可能性もあるのではないか?
アライ「まだ来ないのだ…もう一度通るって聞いたのだ」
フェネ「アライさーん、この時間じゃないらしいよ?」
アライ「なにーっ!!?」 #けものフレンズ pic.twitter.com/vD6IMzPEqJ— たつき/irodori (@irodori7) 2017年8月15日
自分が関わったオリジナルイラストをネットに挙げるくらいは他のアニメ関係者も行っている。
しかしけもフレが多くのアニメと違うのは、3DCGアニメーションであり、たつき氏のイラストも3DCGをレタッチしたものではないかと考えられることだ。
3DCGは3Dモデルを作り、それをアニメーションさせるという手順が基本であり、当然そのモデルには著作権が発生する。
この「モデルを利用する権利」を巡って対立が起きたとは考えられないだろうか。
しかし、アニメーション制作を担当していただきましたヤオヨロズ株式会社には、関係各所への情報共有や連絡がないままでの作品利用がありました。
問題とされているのが作品「制作」ではなく作品「利用」であることに注目したい。
映像やイラストの制作が問題だったのあら、作品利用とはならないのではないか。
この作品=CGモデルのことであり、それを使ってイラストを制作することを「利用」という言葉で表しているのではないか?
推測するとこうだ。
KADOKAWA側(あるいは委員会側)から、たつき氏の本編で使用したモデルの二次利用について止めてくれというお達しが出る。
↓
ヤオヨロズ側はモデルを制作したのが自分達であることから、二次利用についても権利を主張する。
↓
KADOKAWA側は、モデルについても委員会側の共有の著作物として主張する。飲まなければ2期から外すと行った条件を出す。
↓
ヤオヨロズは権利を手放したくなく、2期から外されることを受け入れる。
この推測は飽くまで推測だが、実際の所3DCGモデルの利用については色々と難しい部分がある。
自分もアニメ業界の人間なので聞いたことがあるが、過去の別作品で利用したモデルの再利用に関してはかなり敏感で、
例えば背景に家のモデルを置きたいけど①から作るには時間が無いなどで過去のモデルを使いたいときは、
原型を残さないように改造したりすることになっているらしい。
またヤオヨロズ含め3DCG関連の制作会社は普通のアニメ製作会社以上の制作費を要求するので、
委員会との関係はあまり良くないとも聞く。(これに関しては普通のアニメの制作費が安すぎるのである)
繰り返すようにこれは飽くまで推測なので事実は全然違うかも知れないし、なんならその可能性のほうが高いが、
3DCGモデルの権利問題は今後ますます3Dの存在感が強まるであろうアニメ業界において重要な問題となるだろう。
ましてけもフレのように、CGモデルの絵柄自体に独立した価値が生まれているケースでは特に重要だ。
もしこの推測が当たっていたなら、この問題がスムーズに解決するかは、今後のアニメ業界での3DCGの普及にも関わってくるかもしれない。
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
ちゃんとしたタオルじゃない安いタオルがあるでしょ。粗品とかいって銀行がくれる薄いタオル。あんなのでも2、3回ならまだ使えないこともないとは思う。実家の母なら論外と言うだろうけど私はもったいないからちゃんと使う。でもやっぱり洗っても3回が限度。保水力もふわふあ感も認められないレベルになるでしょ。ゴミだけど、私はそのままは捨てずに油汚れを拭くのに再利用してから捨ててる。
だから友人の家にお泊まりに行った朝、洗顔用に渡されたタオルには本当にびっくりした。銀行タオルを渡すのもどうかと思うけどその生地がペラペラなの。ローラーで伸ばしたの?と聞きたくなるくらい薄いの。嫌がらせでこんなゴミを渡したのかと問い質したら逆にびっくりされた。彼女の家ではそうなんだって。彼女の実家は私のとこ以上に豊かなのに。多分成金なんだと思う。
https://anond.hatelabo.jp/20170707221433
怠惰(Laziness 不精)
理想 → 全体の労力を減らすために手間を惜しまない。自動化、再利用する。
現実 → 余計なルール作ったり、メンテが必要なクソコード量産したり、その人しかわからない環境こさえるだけ。全体の生産性を上げられる奴は稀。普通にやれ。
短気(Impatience せっかち)
理想 → 素早く動けるように心がける。先回りした柔軟な対応。
現実 → 一人で素早くやっても特にメリットがない。チームの速度を上げられるプログラマは稀。あと早すぎるとトレードオフで悪いことも起こる。品質落ちたり、いざという時に潰れる。普通にやれ。
傲慢(Hubris 思い上がり)
理想 → コードに責任を持つ。プライドを持てるくらい高品質に保つ。
現実 → ドヤ、俺のコード!じゃねーよ、かっこいいコード書くな。お前の実力は大したもんじゃない、基本通り書け。
こんな三大美徳なんて、一部の天才プログラマーにしか適用できない
凡人が感化されて真似してんじゃねーよ
無駄な事すんな
だから嫌わえるんだよ
LAMPの現場だ。コテコテのウォーターフォールで、ソース管理はsvnだしテストはExcelで手動実施、チームメンバーは現状で15人。
要件定義からのサポートなのだが、やっていることといったらひたすらExcelで画面イメージを作る作業だ。
モックアップはあるのだが、テンプレートエンジンに落とし込むことを一切考慮していないので再利用はほぼできない。
営業上がりのリーダーはそのことを理解していない。スケジュールを見ると炎上がほぼ確定している。部外者にはそれを正すこともできない。
リーダーは謎の打ち合わせで業務時間の8割は席にいない。チャットワークで問い合わせても返事はない。
与えられた仕事はどんなにかかっても1時間で終わるようなことなので、空いた時間はトイレに篭るか瞑想するかはてぶを巡ることでつぶしている。
そして技術系の記事を見ていると、みな楽しそうに新しい技術や働き方について綴っている。
この落差は何なのだろうか。
人売りでしか生きていけないような会社に勤めていることが間違いなのか。
そもそもこの業界にいてはいけない人間なんじゃないかとすら思えてくる。
これじゃいかんと、最近、オンラインのIDEでJSフレームワークをいじり始めた。
楽しそうにしている人たちにしてみれば2周遅れの技術だろうが、それでもコードをいじっていると気がまぎれる。
でも、少なくともなにか1つくらい作りあげてからにしたいな。
いきなりですがバニラエア問題で話題になっていた「いすみ鉄道 社長ブログ」さんの記事があります
今回は以下の記事に対するコメントの賛否の数を具体的に数えました
2000超のブックマークがついていますがその内コメント有のものが確認時点で610あるのでそれを一つ一つ仕分けしていきます
http://b.hatena.ne.jp/entry/isumi.rail.shop-pro.jp/?eid=2918
比較対象として2chの嫌儲板にたてられたこのスレッドでも数えてみます、1000レス中ユニークIDは332あります
バッサリいうと賛成は「障害者の方には事前連絡をお願いしよう」という意見の方、反対は「事前連絡は必要ない」という意見の方で以下はその割合です
・はてな
数 | 割合 | 判別不能を除いた割合 | |
---|---|---|---|
賛成 | 422 | 69.2% | 89% |
反対 | 52 | 8.5% | 11% |
判別不能 | 136 | 22.3% |
賛成-記事に同意する形での賞賛意見、記事を全面的に肯定する意見、トラブル元の車椅子の方を非難する意見、記事の中立性を賞賛し称える意見、これらを賛成にカウントしました
例「今回の騒動で一番腑に落ちるエントリ」「中立的に書かれた素敵な記事。まさしくこの通り」「すげえなこの文章。完璧だ。」「全面支持」
例「必読。マスコミと違って非常に中立的な、本来的な意味での「批判」をきちんとされている文章」「完璧過ぎる見解」「完全な正論」
例「こういうひとのこういう意見が確認できてよかった。問題点の整理とどちらかに偏らずに断ぜられるところ」「騒動を起こして注目を集めるのが本意だから、どうしようもない。」など
反対-記事の中立性に疑義を唱える意見、記事を非難する意見、事前連絡は必要ないと主張する意見、ブコメの賛成意見に異を唱える意見、これらを反対にカウントしました
例「このどこが中立的なんだ」「言葉遣いが丁寧なら中立的でロジカルな提言なのかw」「はてなーはチョロいなー」「~悪質な記事」「~最悪な太宰メソッド」
例「後半は賛同できない」「美味で口触りのいいオブラートに包みまくるのが上手なだけで中立ではないと思う」「差別解消への道のりの長さをしみじみと感じた」など
判別不能-賛否の分からない引用ブコメ、アイスクリームに関するコメント、あとで読むやカテゴリのみの意見、ダジャレ、なんともいえないなどの意見、これらを判別不能にカウントしました
・嫌儲
数 | 割合 | 判別不能を除いた割合 | |
---|---|---|---|
賛成 | 107 | 32.2% | 47% |
反対 | 121 | 36.4% | 53% |
判別不能 | 104 | 31.3% |
賛成-基本的に「はてな」と同じですがスレッドという形式上、対話が生まれるので反対派と対立している意見や言葉が汚いのですが木島氏を罵る意見なども一応賛成にカウントしました
例「的確だし読みやすい文章だな」「プロ障害者~」「~障害者差別だって言い出す卑怯者~」「~差別だ!差別だ!」「ガイジは迷惑」「このおっさんの活動ってたかり屋のソレですよね」
例「モンスタークレーマーには手を出しても一切裁かれない仕組み作るべき」「そのうち矢切の渡しもバリアフリーにしろとか言い出しそうだな(笑)」など
反対-「はてな」の基準に加え、ブログに反論する形で木島氏を擁護する意見、法的な観点から事前連絡の必要性のなさを訴える意見などを反対にカウントしました
例「先進国になりきれない国民性がまさに露呈してる案件」「バスが遅れることで老人を憎む社会はまっとうなのか?」「事前に連絡しろだの俺に呼びかけしろろだの何で健カスはお客様目線なんだよ」
例「健常者が「私は健常者なので格別のご配慮はいりませんゾ!」って事前連絡しろや」「障害者にも健常者と同じようにできることを広げることがどうして障害者の優遇になるんだよ」
例「カタワがいちいち事前に電話入れなくても飛行機に乗れるようにする為の知恵をみんなで出し合おうよ」「健常者様の言う偏見の無い状態って「障害者は俺達健常者のご機嫌を取って謙虚に生きろ」だからな」など
別にリベラルだから正しいとか保守だから正しいとか言うんじゃありません
もっと言うとこの話題に対してこっちのスタンスだからリベラルだとか、あっちのスタンスだから保守だとかいう認識自体間違ってるのかもしれません
ただ自分の認識としては「はてな」というコミュニティは今回の話題については事前連絡必要ない派が多いだろうなという印象だったんですよね
それが「いすみ鉄道 社長ブログ」さんのブコメを見てみると思ったものとは違ったので驚いて実数を数えてみたということです
ちなみに比較対象が2chの嫌儲なのはこの話題扱った比較可能な対象がこのスレッドくらいしか見つからなかったからで他に特に理由はありません
ただ驚いたのは言葉遣いは汚いですが書かれている内容は嫌儲の方が「はてな」よりも自分の認識としては「はてな」らしい言説が多かったことですね
2chってもっと障害者差別とかばかりで炎上しているものだと思っていましたし権利を声高に主張するとか活動家とか大嫌いでおそらく盛大に叩かれているんだろうなと
でも実際見てみると「事前連絡なんて絶対に必要ない」「歩み寄りが必要なら社会の方が変わるべきだ」みたいな意見が半分くらいあってかなり驚きました
ハッキリ言って今回の話題に限っては「はてな」よりもリベラルだなという印象です
ホントに数えたの?などと疑われるのは嫌なので一応載せられるだけ載せときます
字数制限で全部は無理なので一部です
(1つ10分かけて確認したとかではないので個々に見ていけば仕分け間違いも結構あるでしょうが全体では概ね合ってると思います)
(ちなみにこの記事は書いた後反省して削除した記事の再利用です)
賛成
panchoo wildhog biyoub mikanuirou forAction BritanJP h1romi TAKAPPRS
yuichi0613 plagmaticjam scorelessdraw ko-gold rururutea nibo-c tomk59 yunitaro holly_d
mugitora tamuo bfms350 baboocon19820419 doksensei parikko hinaho ghr1130
ntnajp605 fu-wa ftype a_dogs superHoge triggerhappysundaymorning thirty206 wwolf
jaguarsan tick2tack affable_noise Taro416 fatmonger Katharine_15 f_oggy
milkmooncake sub_low roadman2005 arittake tenkinkoguma keisuker vlxst1224 jiro68 alivekanade
nonameblog charismanbou eriko315 bluekeeper maru2tech nekonuma
kenichi_odo aceraceae kazoo_net14 cranky001 kyousuke104 taitoku Ayrtonism kei_1010 threelarge
flyeagle htandescondor mats3003 mawhata facebooook tetsuya_m
David334 sho nikkatsu the_sun_also_rises zoidstown terlen0 mojisan mashori albertus satoashu rsky
otou-no amayan yamadadadada2 securecat teebeetee arrack STARFLEET
lovely kazoo_oo kyurinigate ysync yem3399op Outfielder mirucons namikawamisaki zintomo
njgj sangping Yagokoro mogmognya tikuwa_ore to4yuki POMME wonodas
nakayuki805 lucifer_af ottyanko yooks nikoli popowa yukatti marilyn-yasu onasussu shufuo BIFF
damehobbyanimelike-913 kazoo1080 weekly_utaran nika1vf b4takashi ponnao
qouroquis stealthinu UDONCHAN mr_yamada take-it adramine m_shinzaki warp9 rajendra
inazuma2073 nankichi catnbeer ytRino QueSTioN kirifuu yulalila watatane
ROYGB REV QJV97FCr hageatama- kokubu8810 kamayan1980 nicoyou olicht navagraha
poko_pen masumizaru sharia semimaru hakuginnyan nacamula digits_sa kosigan naopr
haruhino sky-y spam_lover
反対
parallel-world kutabirehateko chiaki35 Jcm mobam kent4319 djwdjw gonzales66 eringix mekon actin
c_shiika nanashino BigHopeClasic www6 rain-tree blacksorcery minazarashi FutureIsWhatWeAre Yozhik
判別不能
mizugarasu0330 mohno fifthpapa arguediscuss rna cloudliner_tweets simabuta
misiu_teddy ninjaripaipan ujimusi ko-ya-ma aoichang heiwa48 a_micchan kk_solanet
kamomewa_kamome marumo012 macj_jp yhfjiug4 hogetahogeko tyu-ba rag_en
nakoton firstbento tmtms kamezo wacok kniphofia sawat kato_19 You-me heniha shima2tiger
mionosuke yto mythm frothmouth lastline tomoppa merico2404 MnMisato
ppummu sacatorine lone-dog forcutie noaim y-Aki starthinker KoshianX synonymous W53SA nagisabay axel69
賛成
ニククエ KKd6-t/ze
ニククエ Sa25-QUqp
アウアウカー Sae9-gKly
アウアウカー Sae9-nEzC
オイコラミネオ MMd6-4LHc
ガラプー KK79-rcFm.
ガラプー KK79-rcFm・
ササクッテロラ Sp71-HpRm
スッップ Sd62-34WU
ニククエ 0148-Xip7
ニククエ 02cd-N8F9
ニククエ 067a-wjSU
ニククエ 1948-nP2k
ニククエ 1948-wjSU
ニククエ 1948-XKcx
ニククエ 22a7-nP2k
ニククエ 2e20-CicO
ニククエ 4218-XKcx
ニククエ 424f-hy1C
ニククエ 42af-CicO
ニククエ 42d7-nP2k
ニククエ 46fc-1sCA
ニククエ 4937-wjSU
ニククエ 65a8-nP2k
ニククエ 6d47-TwWI
ニククエ 6eaa-KVPo
ニククエ 82f6-wjSU
ニククエ b18d-XKcx
ニククエ c247-wjSU
ニククエ c5f3-TwWI
ニククエ c665-vtNh
ニククエ c969-XKcx
ニククエ c9a8-CicO
ニククエ c9ab-lO1+
ニククエ cd65-Rp6i
ニククエ cd71-AqLU
ニククエ d99f-nP2k
ニククエ e25a-WwN4
ニククエ e2e4-WwN4
ニククエ MM62-VjxI
ニククエ MM92-6qbC
ニククエ MM92-Q/fz
ニククエ MMd6-5/PS
ニククエ MMd6-lonu
ニククエ Sa25-c190
ニククエ Sa25-nIbb
ニククエ Sae9-ImDA
ニククエ Sae9-QicN
ニククエ Sae9-wEtA
ニククエ Sae9-YZaj
ニククエ Sd0a-HpRm
ニククエ Sd62-craR
ニククエ Sd62-Myhu
ニククエ Sd62-P9OG
ニククエ Sd62-sdB6
ニククエ Sp71-cmvZ
ニククエ Sp71-HpRm
ニククエ Sr71-aH8M
ニククエT Sa25-SqsB
ニククエW 0148-/WSL
反対
ニククエ bdc6-a1xH
ニククエ 06ae-QZ2B
ニククエ c1fc-nP2k
ワッチョイ c1fc-nP2k
アウアウウー Sa25-FK0e
ガラプー KKd6-5DIh
スッップ Sd62-zc/o
スップ Sd62-7nsYage
スプッッ Sdc2-fD6Qage
ドコグロ MM62-MfSw
ニククエ 06ae-QZ2B
ニククエ 09b9-hy1C
ニククエ 1948-EVd7
ニククエ 1e05-wjSU
ニククエ 1e18-wjSU
ニククエ 2e25-vtNh
ニククエ 2e59-uerO
ニククエ 2eb6-QNC5
ニククエ 2ebc-mwel
ニククエ 42ee-wjSU
ニククエ 46fc-q9Kq
ニククエ 624f-N8F9
ニククエ 6e16-wjSU
ニククエ 6efc-wjSU
ニククエ b174-ddzC
ニククエ bd66-wjSU
ニククエ bdc6-a1xH
ニククエ c15a-uerO
ニククエ c233-lonu
ニククエ c959-CicO
ニククエ c9ce-ui4O
ニククエ c9e9-j7CS
ニククエ cd82-Cu+A
ニククエ cda0-lO1+
ニククエ d204-wjSU
ニククエ f965-wjSU
ニククエ MM61-nz7l
ニククエ MM62-k5gH
ニククエ MM62-nFgZ
ニククエ MM62-r5Tq
ニククエ MMd6-CG5Q
ニククエ MMd6-mlCq
ニククエ MMd6-mQuD
ニククエ MMe1-hy1C
ニククエ MMe1-XY2z
ニククエ MMf5-HpRm
ニククエ Sa0a-3D8/
ニククエ Sa4a-HpRm
ニククエ Sae9-HpRm
ニククエ Sae9-Q+y+
ニククエ Sd62-1Yq1
ニククエ Sd62-W+l3
ニククエ Sp71-BWge
ニククエ Sp71-ucr6
ニククエ Sp71-zc/o
ニククエ Sr71-LveV
ニククエT Sa25-mQuD
ニククエT Sa4a-wjSU
ニククエW 0148-HpRm
判別不能
アウアウウー Sa25-U1Q1
アウアウオー Sa0a-+k/C
アウアウカー Sae9-Dnj7
アウアウカー Sae9-zUSX
エーイモT SE0a-wjSU
ガラプー KK79-MoQb
ガラプー KK79-rcFm
ガラプー KKd6-ntTI
スップ Sdc2-/yms
スップ Sdc2-dEZD
ドコグロ MM62-WBlH
ドコグロ MMe1-e0WE
ニククエ 2da8-WwN4
ニククエ 422f-wjSU
ニククエ 4248-AqLU
ニククエ 4248-wye1
ニククエ 492c-a07H
ニククエ 623f-wjSU
ニククエ 65bc-nP2k
ニククエ 698f-D66J
ニククエ 6991-2wFU
ニククエ 6991-wjSU
ニククエ 6d87-bLw5
ニククエ 822f-q9+R
ニククエ 9269-wjSU
ニククエ c1fc-wjSU
ニククエ c26b-52GC
ニククエ c27b-h+ec
ニククエ c919-1PJ5
ニククエ c9b6-nP2k
ニククエ d2ef-CicO
ニククエ KK05-ssIu
ニククエ MM62-xdRK
ニククエ MM92-CxjY
ニククエ MM92-IszL
ニククエ MM92-qFc6
ニククエ MM92-Qoee
ニククエ MM92-sRyQ
ニククエ MM92-TFUV
ニククエ MM92-tij3
ニククエ MM92-v5vx
ニククエ MMe1-OXoP
ニククエ Sa0a-dZda
ニククエ Sa25-i75/
ニククエ Sae9-8ssk
ニククエ Sd62-HpRm
ニククエ Sd62-WB4X
ニククエ Sd62-we3q
ニククエ Sp71-1fDS
ニククエ Sp71-TaZ6
ニククエ Sp71-upg+
ニククエ Sx71-1fDS
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】:法的問題はない。しかし、当事者たちにとってセンシティブなことへの配慮が足りなかったという点で、研究倫理上の問題はある。」という態度だけを強調することは、一見、配慮をうたっているようでいて、そこまで素晴らしい態度というわけでもないと思う。
基本的には、この論理だけを強調せざるを得ないシーンというのは「対話することが難しいほど弱っている人たち」とか「西洋文化基準でもって踏み込むべきでもない人たち」、「複雑すぎる背景をもっているので相手に明文化とかをそこまで期待すべきでもない人たち」に対する場合ではないだろうか。
つまり、言及をする側からの一方的な配慮である。鬱でほんとに今にも死にそうな人とかに対しては確かにそういう形でのコミュニケーションしかできないから、そういう場合は仕方がない。
もちろん、言及をする側は可能な限り配慮すべきだ。しかし、だからといって、言及をする側だけに配慮を要求するというのは、言及される側を馬鹿にした話ではないだろうか。配慮は相互になされてよいと思うし、腐女子の方々は、一方的に配慮されるだけの弱者とかではないと思う。
多くの腐女子のお姉さまがたは、尊敬すべき人々であると思っている。ぜひとも腐女子コミュニティの今後の拡大にあたって、より受け入れられやすいコミュニティの形成をしていっていただければ幸いだと思う。
また、今回はたまたま腐女子のコミュニティと一般法との間の問題であったが、これは見えにくい慣習と一般法の間にズレがあるケースでは、似たような問題は何度も起こるタイプの話だとも思う。ローカルなライセンスのようなものが増えすぎたら、それもそれで面倒だということもあるとは思うが、何もないよりは、だいぶよいだろうとは思う。
「慣習は、法の前には下位の基準でしかない」という話についても簡単に触れておきたい。
基本的には法のほうが重要だとは私も思う。ただし、それは慣習と、法とのガチンコ対決が回避できないという事態が訪れた場合、法が優先するということであって、ガチンコ対決が回避可能な場合や、慣習が公序良俗に反するというわけでもない場合は、別に回避してやってけばいいのではないか、と思っている。
今回、腐女子コミュニティで「引用」に関わるルールが特殊な形で扱われていたが、もし腐女子コミュニティにおける「引用」ルールを、一般社会全体にまで拡大させようという動きにつながることがあるのならば、これは断固ととして反対する。
「引用」の自由は、研究にとって重要という以上に、自由な言論、政治、社会にとって重要なものだ。たとえば、それを政治的な言論(たとえばヘイトスピーチ)をやっている人たちが「引用」ルールの除外適用を求めてきたとしたら、それは素人の文章だったとしても、まったく受け入れられない。「公開した俺の政治的発言を引用しないでくれ」などありえない。それを引用して批判する自由を奪われれば、政治的なことについて公共の場で議論することに多大な支障が出るだろう。
今回の場合は(1)性的プライバシーの問題であるということ(2)腐女子コミュニティの内部で、そのコミュニティに属する人々の合意において特殊な「オープン/クローズ」概念が実効力をもった慣習である、という前提があって、はじめて「それは配慮しましょう」という話がありうるのであって、著作権における「引用」そのものを捻じ曲げるような話であってはならない。
この著作権における「引用」を捻じ曲げていいかどうか、というの話はすべての人にとっての言論の自由の確保という意味で、致命的に重要なポイントである。これを安易に捻じ曲げるような権利主張は極めて危ういとも思う。
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できないメインで使えないのもまず、重すぎるからっていうのもありそう。
スペックが足りてなさすぎる。まずは6,7万出してスペックを整えよう。
すごい人たちは幼少の頃からパソコンがあって、パソコンをいじるだけの時間があって、承認されてる。
しかも、コミュ症だとかなんだかんだ言いながらも、ネットではきちんと弾けてるし、人望もある。
彼らを理解するのはすっごく難しい。
経済格差が多すぎて、彼らが積んできた経験と持っている環境が違いすぎるから。
プログラム自体は数学を解くようですごく楽しいのだけれど、なぜ苦しい勉強をしながらプログラムをずっとやっていられるのかわからない。
環境はMac(高すぎて揃えるなんてとんでもない)じゃないから、先人たちの簡単に手順化された知恵を受けづらく、プログラムの環境をととえるまでが大変だし、
ライブラリ関係のエラーコードは自分の力で、ライブラリを見つけに行かないとダメで、ウェブで検索しても彼らよりもずっと時間がかかる。
そこをきちんと理解したうえで、自分がどこまでやりたいのか、どうしてやりたいのか
自分はプログラマに向いているのか、考えながら、勉強していったほうが良い。
ちなみに私はプログラムを解くの好きだったし、ある程度は得意だった。
ADHDと自閉症混じってるから、だから職人的なことをやりたかったし、テストをかけば不注意で大きな損失を出す可能性も低くなる。
だからプログラマを目指しているし、プログラマとして就職するつもりなんだよね。
私も無名で、プログラム力的にはpaizaのSランクは、後ちょっと足りない、運が良ければ成功するんじゃない?ってレベル。
ツイッタランドのすごい人たちは目指すと疲れるだけなのでほどほどにね。
彼らは多分余裕綽々でS取れる。
paizaの出題は競技プログラムの一種で、競技プログラムっていうのはある程度出題の仕方が似通ってる。
複数回解いていると昔に残ったコードとか再利用できたりするから有利になるっていうのもある。
ゲームで例えるとRPG好きな奴にFPSやらせても全く活躍できないけど、FPSが得意な奴に別のFPSゲーやらせてもできたりするでしょ。
開発のジャンルの違いがあることは覚えといて。
Mac買えなくて開発環境として選ぶなら,windowsよりlinuxのほうが良い。
windowsだと環境整える前にストレスがやばいし、パソコンが死んだ場合のストレスもやばい。
あと、古いパソコンだとUSBブートができなかったのも割とめんどくさかったし、回線がめちゃくちゃ低速だったから、ISOファイルのダウンロードに半日かかってたかな。
VirtualBoxはすごいスペック持っている人が使うものなので、買い換えないならクリーンインストールかデュアルブート推奨。
ubuntuにしとけば、ウイルス系もあんまり構う必要性がなくなるからね。
起動にVirtualBox起動に数分待って、端末以外を使おうとすると固まるみたいなことやってると辛さが溜まるから。
デビットカードでも行ける。
するが銀行に口座を作ってデビットカードを申しこめば、20歳以下でもなんとかなる。(年齢によっては親の同意は必要だけど)
2,3週間かかるけど、デビットカード作っておくことで色々なサービスを体験できるようになるのは選択肢を増やすにあたって重要なことだから是非。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
ネット上は怖い人もたくさんいるし、まさかりがちょくちょく飛んでくるけど、変にウケると拡散してくれて色々な人が声をかけてくれるのも確かだったりする。
ゆっくりと自分の使い方を覚えていけば少しずつ楽しめると思う。
実際、SNSは情報の精度としては当てにならないし、勉強のためってSNSを使うとストレスで辛くなった。
自分の好きな人だけをフォローすると精神安定するよ、あとフォロー返しはやる必要はない。やってるとTL荒れるからね。
(リストとか使いこなせるなら別なんだろうけどね)
おすすめ度は◎○△であらわす。
おすすめ度:◎ 条件:最低で6,7万円のお金が必要。 おすすめはlenovoのeシリーズ。 重いけど、コスパは良好比較的安めに上がってキーボードも打ちやすいのが良い。 いまはcorei5, メモリ8GBの使ってて、大体(重めのゲーム以外)したいことはなんとかなる。 SSDはあったら便利だけど、一番重要なのはメモリな。 開発したいなら8GBは必須。 (苦労話: 古すぎてノートなのにキーボードを常時接続必要だったり、画像が多いサイトはブラウザを選ぶ必要があったり、何よりもIDEが使えなくて辛かった。 windows vistaのupdateで数日固まったり、ゴミでしかなかった。 )
おすすめ度:◎ 条件:契約できる年齢か、親の同意(年4万円くらいの出費)が必要 何をするにもまず回線速度が遅いと話にならない。 IDE落としたり、クラウドにファイル上げたり、AWS使う時のアップロードとか、音声会話とか。 〇〇をしてみたいと思ったら,ダウンロードに時間がかからないことは、モチベーションのためにめちゃくちゃ大切。 (苦労話: ISOファイルをダウンロードするのに半日かかるのが普通だと思ってたけど、 まともな光回線+まともなルータを利用したら、ダウンロードに1時間ちょいになってびっくりした。 特に古いルータだったりするとボルトネックになったりする。 )
おすすめ度:○ 条件:linuxで生きていくという覚悟 windowsよりは快適。 他のlinuxISOファイルを焼いたりするときにちょっと苦労するかもしれないし、軽いの選ぶと良いかも。 実際普段使うものがネットとプログラムツールだけだったから、なんとかなったし、ゲームの選択肢が強制的に排除されるので、 少しはプログラムに触りやすくなるかもしれない。 (苦労話: エクセル、パワポ必要とか言われた時に、officeのレイアウトで死んだりする。 資料はPDFな。 買い換えない場合のクリーンインストールは↓ 昔のパソコンでもLinuxとか入れればそれなりに動くよっていう人はいるけど、やっぱり社会的な通信網と平均的なマシンスペックが上がっているせいで、ウェブ自体が要求するスペックも上がってて低スペックだとつらい。 ブラウザはw3mとか使って、端末タブを開いてvimで開発してた。 なんでかって言うと普通にブラウザ使うとレスポンスが重すぎたから。 でもその使いづらさの分だけ損してるんだよね。 )
おすすめ度:○ 条件:電車代などの交通費を用意可能 できること: 他人に触発されるタイプなら、すごい人たちの興味の方向を見て学ぶ方向が増えるかもしれない。 後は交通費と宿泊費の出る勉強会なんてものもあるので応募してみると良いかもしれない。 高校生なら、交通費出してくれるっていう太っ腹な勉強会もちらほらある。 一、二回は顔出し推奨。 欠点はあって、コミュ症は治らないので、友達ができるとは限らない。
おすすめ度:△ 条件:家庭環境による できること: 自分の向上心による。 大学生になって一人暮らしになったら、パソコンに触れる時間は多くなったとは思う。 (勉強しているとは言っていない)
おすすめ度:○ 条件:3,4万円の出費 できること: まず、パソコンを長時間触っていても疲れなくなる。 デスクの高さと椅子の高さはとても大切なもの。 疲れなくなるし、指が攣りそうになることもない。 机の高さはきちんと調べたほうが良い、あってることが重要 今使っているのは1万ちょいの新品デスク(ニッセンのフリーテーブル)と3万弱の中古のオフィスチェア 基本的に3000円位のデスクは耐久性と高さがゴミだったりするので注意。 机は http://blog.livedoor.jp/itsoku/archives/38727329.html の66のテンプレを見ておくと良いかな。 (苦労話: しかもノートパソコンでデスクと椅子がなくて狭いこたつの上か100均で買ってきた台の上で、パソコンを使っていたからパソコンの位置の高さが合わなくて姿勢がどうしても悪くなるせいで長時間パソコンをいじることもできなかった。 後は寝ながらパソコンをいじるみたいなみたいな堕落生活してたら、筋肉が硬直してまともに手を握れなくなって、医者にかかることになって1万円程度お金がかかったし、 2ヶ月位まともにパソコン触れなくなった。 ちょうどその時期は、筆記用具をほとんど使わない単位だけだったから良かったものの、他の単位とってたらもっと治療に時間がかかったかもね。 )
おすすめ度:○ 条件:それなりのスペックのパソコン、それなり大きさのディスプレイ できること: 設定しなくても、複数のファイルから補完が聞くし、フォルダ内の全てのファイルから検索、置換ができるのが良い。 ただし、ディスプレイが小さいと実際に開発できる範囲が小さくなるのは注意。 (苦労話: IDEは普通に使えるなら作業効率が全く違って、設定少なくても補完も他のファイルやライブラリから保管してくれるたりする。 でも、昔の環境だとeclipseはフリーソフトだけど環境整えるまでが辛いし、重いしで、開くとブラウザすらまともに操作できなくのが辛い。 だから、ブラウザでチュートリアルとか見ててもパソコンに待たされてストレスだった。 まともに使うには設定がめちゃくちゃ必要なのは実際疲れた。 (ac.jpのメールアドレスは必要だけど)学生無料なIDEでjetbrains製品があるけど、設定しなきゃダメなvimとかと違ってマウスで操作できるのがすごい良い。 端末ではコピペが簡単にできなくて、数は少ないけどよくあるミスが、間違えてcommandモードで貼り付けてやり直したり、vimのline numberの設定をいじらずにvimからコピペができる。 コレだけでイライラ具合が全然変わる。 )
おすすめ度:◎ 条件:図書館や図書室で本を注文できるか、本があるか できること: プログラムの能力が向上する。 おすすめされている本を探すと良い。 プログラム初学者なら、ネットだけで勉強するよりは効率がある。 とりあえず、やりたいことなくて、プログラム力をただ上げておきたい場合は、 競技プログラムやりたいとしても下の順番で進めると良いかもしれない。 あと、プログラムには自分が到達しているところまでで言うと、次の順で壁があって能力が足りないと行き詰まることがある。 >> 関数化 → クラス化 (→ ポインター) → 再帰 → 関数型言語 << 数年かけて勉強して次の段階に勧めないならプログラマは諦めたほうが良いかもしれない。 (能力が足りないのは上司も自分もつらくなるよ)
おすすめ度:○ 条件:1万円弱のお金 できること: ノートパソコンなら2個の画面を使えると作業効率が違う。 特に手打ち系のコーディング練習とかがめちゃくちゃ捗るようになる。 (苦労話: IDE系列は画面を割と占拠するので、ノートパソコンの狭い画面だと辛い。 でも大きすぎる画面だと持ち運べなくなるのでダメ。 画素数が上がればその分だけ小さく表現ができるので、画面サイズが同じでも画素数が違うとかなり大きさが違って見えたりする。 )
おすすめ度:○ 条件:学力があること努力すること、覚悟 できること: 奨学金を利用して環境を整えたり、時間が増えるから更に勉強できる。 プログラム関係もそれ以外も就職先が増える。 また、これからの転職したくなった時に逃げ道が増える。 欠点、国立は安いけど、入学にそれ相応の努力が必要。私立行けるなら、苦労してないと思う。 あと免除制度っていうのがあるから、そういうのも利用しつつ費用を安く上げよう
おすすめ度:○ 条件:年齢(か、親の同意) できること: ちょっとした電子払いができるようになる。 多重債務は起こらない。 欠点としては、定期払いはできないので携帯の契約とかはできないことに注意。
低スペックのパソコンしか無いのは、多分家庭環境のせいでもあって、
君がアルバイトもできるかどうかわからないし、アルバイトしてもそのお金が君のもとに入ってくるかはわからない。
お金も無限にあるわけじゃないし、時には経済格差を感じて辛くなることもあるだろう。
少ないお金の中でうまくやりくりして、それでも自分の力にしていってほしい。
(お金が潤沢にあるなら親を説き伏せることをがんばって)
応援してるよ。