  |
はてなキーワード: GitHubとは
内定をいただいたのであとは明日にでも内定承諾書をポストに投函するだけ．
これで晴れて僕はノー学会．就職失敗．教授からは鬱陶しく思われるゴミ院生です．
やる気？何もないよ．モチベーションなんてどこにもないよ．
なりたいと思っていた自分の姿なんて研究の難しさ，自分の頭の悪さ，能率の悪さの前に全部ふっとんだよ．
とおおおおおおっっくのとうに無くなってた．
一方で色々なことを確実にしっかりこなす，同僚の姿，同期の院生の姿を見て自分を対比して情けなく思うわけだ．
なんていうか，もう研究室来たくないなあ．
何を目標にしてやればいいのかもう分からない．修了を目指す？そんなんもう適当にやってればできるんじゃない，と思えちゃうよね．
就活だって，研究だって，なあなあでここまでこれちゃったんだもん．一過性の恥と後から思い出して少しだけ引っかかる後悔を
少しだけ我慢できれば自分はいずれ就職して，お給料貰ってる生活があるんだもん．そう思うようになっちゃったよね．
でもたぶんその感覚はもう自分にはないからそういう風に煽られても「何こんな場末まで来てんの？研究しろよｗ」っていうふうに返すんだと思う．
「環境のせいにするな．今までなんの積み重ねもないのはお前のせいだ．」とか言われても脳内でニヤケてるぐらいだもんな．
もう駄目になってるんだよね．教授に少し怒られた所で「喉元過ぎれば熱さ忘れる」の最強の札切ってるから，痛くも痒くもない．
（雑魚やんｗ）って思ってる自分がいるんだよね．いやほんと雑魚だよ自分は．
もう自信なんてないや．スマブラと研究で使ってるプログラムなら同じ学科の奴には負ける気がしないけど，そんなん教授のおっしゃる「コミュニケーション能力」の前には全ッッッッぜん関係ないですもんね．ﾜﾛｽ．
いいか．学部4年で理系院進を考えてるやつに言うぞ，3年間を振り返って，自分に変化が1つでも起こせなかった奴．言われたことしか聞かず単位を取ってきた奴．「真面目」が良さだと思ってる奴．逆にそこそこの変化を経験してここまで来れたと思ってる奴．そこそこの成績でそこそこの楽しさしか経験してこなかった奴．
院進に関してはもう一度よく考えろ．「周りが」「親が」「ネットが」「世間が」「学歴が」の地獄の5段活用で判断するのはやめろ．
お前自身の問題だぞ．自分にできること，自分にできないこと，そういう向き不向きは誰にも必ずある．そしてそれは多くの場合変わらないし変えようと思っても大抵手遅れだ．
辞めること，逃げることは恥じゃない．無知と意地と見栄で突っ込んで時間と金と精神をすり減らすなら挑戦なんてしないほうがよっぽど良い．
まあ結局院生にならなくっても就活には失敗してたしセワシ君の言ってた「なるようにしかならない」は経験できたよ．
もう一度言うよ．院生に向いてない奴は確実に一定数いる．院生は学生じゃない．お金を払って給料のもらえない大学に通う社会人（トイレ，光熱費，ネット環境，冷暖房，書籍はほとんどタダ）で，研究は「仕事」だ．自分はこのコトに気づけ無かった．それが今だ．情けないし，これから生きていく中できっと何度も後悔する．図書館でこれ書いてるけど正直泣きたくなってきた．
自分のブログに書こうと思ったけど，特定されるとなんか恥ずかしいしまだ院には8ヶ月ぐらいはいるしなあなんてまだ今後の生活を考えて割り切れないゴミだ．建設的な考え，失敗から次の方向を決めること，データの客観的な整理，ごちゃごちゃしてきたgithubの整理，汚いデスク．
自分は理系の院生だ．でも，正直もう何もないというかいらん．院生としての実績も，研究室の居場所も，研究の方針も．
いいから適当に研究終わらせて，さっさと研究室引き払って死にたい．
あと8ヶ月のモチベーションなんてないって言ったけど，修了していなくなる時，自分の作ったソースの自作モジュールとクラスはNAS，github，ローカルから全部すっぱ抜いて去るこれだけはやってみたいなあと思ってる．
書いている人が20歳以下だと思って書かせてもらうけど、
どの業界で働きたいのか、働いた時の自分を想像すると手が動かしやすいかなーと。
たとえばロボットだったり自動車だったり飛行機だったり、機械の中の制御部分をプログラミングでやりたいのであれば
CやC++、Web系でサービス開発がしたいなら…というように。ここは将来何がやりたいかを考えたほうが思いつきやすい。
例として、インターネットでサービスを展開している企業で働いている自分を想像する。リーダーから与えられたタスクを消化するため
Git/GitHubを使って進捗管理、統合開発環境・テキストエディタを立ち上げ、□□言語で書かれた○○の部分を弄る。実際に本番環境で立ち上がるか云々…。
□□や○○の部分はまだ分からないかもしれないけど、Git/GitHubや統合開発環境、テキストエディタはプログラミングする時に必要なので
ここは極めても良いはず。だから勉強する題材になる。もし、既にこの□□言語の部分が具体的に出てきて、Web系で働くんだという気持ちがあるならその言語を極めれば良い。
ちなみに、文章から文字列を抽出したい場合、正規表現についても知っておくと武器になるぞ。正規表現を扱いやすいプログラミング言語についても調べてみると良いと思う。
これ書いてる人は、エンジニアというか、毎日twitterやgithubやってるいわゆるプログラマだが、しばらく彼女いなかったが、
相手は "おしゃ女子" かどうかは別として、現在はとても幸せに暮らしている。
本気で彼女や結婚相手探すなら、わざわざこんな謎の会に参加するのか謎すぎる。
大手でそれ専用の商売してるところのほうが、ちゃんと人数合わせするし、色々進行慣れてるし。
新しい微妙に使いづらいサイトで、アカウント作るのが面倒とか、サイト探し出すと色々あって、どれに行けばいいかわからない、
などあるだろうが、とにかくその「エンジニアVSおしゃ女子オフ会」よりは確実にマシだと思う。
https://hiwell.connpass.com/event/57695/
とにかく何かを「完成」させろ。それをgithubに上げて、堂々と面接受けろ。
何も恥ずかしいことはない。そのgithubが業績だ。
あと少しだ。あきらめるな。
例の経産省の今更だけどなんかモヤモヤが消えないのは多分擁護が出たせいなんだけどさ。
一番ムカつくのが、完全にお前らのせいだよねっていう。（いろんな人がすでに指摘がされてるけど）
この惨状を作り出した官僚が若手提起だからか「老人たちに搾取されてる若者」っていう被害者目線でダサいパワポ出してきたことだよね。
お前いう！？って感じだよまじで。
失われた20年を作り出した戦犯の経産省にエリートになりたくて入った寄生虫官僚が、自分たちは退職金も天下りも完備して離さないくせに被害者ぶる
唖然だよね。
世代間対立だって年金など諸対策を大幅に間違えたお前ら官僚のせいだよね。
老人のせいじゃない。資料だとまるで老人が悪いかのような書きぶりだけど。
老人にできもしない計画（年金や皆保険制度）立ててそこにいい顔する金足りないって現役世代から年々奪ってく金増やしてるお前らが言う？
全部お前らがしてほしいことじゃねーかよ。結論ありきすぎるだろ。
エリート面したくてそんな国民に何十年も苦痛を強いてる悪の枢軸たる経産省の官僚が今更被害者ぶるんじゃねーよ。
せめて悪なら悪らしくしてろよ。知識人集めた上で自分たちが誘導したい結論に持ってく卑怯な手口含めてさ、とにかく悪の覚悟が足りなすぎるんだよ。
民間は皆お前らが政治家にも中央省庁にも完全に諦めてるからさ。
せめて悪らしくしててくれる？
被害者ぶられるとまじでイライラするわ。そしてせめてgithubとかで出されたらまだ許せたよね。パワポって。あのダサさといい無能感すごいからね煽りっぷりすごかったよね。
最近、IT系ホットエントリーにも増田が並ぶようになってきました
何故これらの記事を書くのか？どう活用すればいいかを書いておきます
悪口を書くと場が荒れるだけでなく個人攻撃、誹謗中傷に晒されることになり非常に危険だからです。
例えばこのような記事は、Qiitaにも書けないです。記事の削除、最悪アカウントの削除もありえます
身の安全を担保しつつ何かをDisる場合は2chかここしか無いでしょう
書くのも読むのもほどほどにしておいた方が良いです。
彼らはマウンティングがしたいだけで基本的に手を動かしている人の方が少ない印象があります
GitHubやBlogで有名な人は良いですが、はてぶだけで有名な人のコメントを真に受けても得るものは無いでしょう
書くときは語気を強めに書いて、少々の煽り言葉も混ぜておくといいでしょう
また、技術的にちょっと突っ込みどころがあるような書き方をしておくのもよいです。
こうするとマウンティングしたいブックマーカーたちが、鬼の首を取ったように突っ込みコメントをしてくれます
あとは勝手にブクマ、twitter等で喧嘩し始めるのを待ちます
このようにはてなでキーワード登録されてる単語を検索して眺めると探しやすいです
炎上させたい場合は無言ブックマークだけして、はてぶユーザーが喧嘩するのを待ちます
http://anond.hatelabo.jp/keyword/Ruby
http://anond.hatelabo.jp/keyword/Docker
gitterやGithubのissueに書き込んで反応を見る方がよほど生産的で有益な方々のフィードバックがあるでしょう
自分のサイトの写真やイラストなど画像をまとめに貼られたとか、編集して使われたとか文句言ってる人をそこそこ見る気がします
私がはてブを見ることが多くなったからか、ここ最近はプログラム関係をブログに書いてるのもよく見かけます
プログラムだと当たり前のように個人ブログやQAサイトのものをコピーして、そのまま使ったり必要に応じて書き換えて使ったりだと思います
プログラムだと公開する方も使ってもらうことを意識してる人が多くて、OSSなどフリーのものを作ったりしてるひとも多いようです
プログラム書いて公開する人には自分でつくったのをみてもらいたい、使ってもらいたいと感じる人が多くて、画像を公開する人は、他人が自分のものを使うのを気に入らないって心の狭い人が多いのでしょうか？
プログラムだってライセンスはなになにだ、っていう話も見るので画像には権利が生じて、プログラムはそんなのない、ってことはないかと思います
法的にどっちにだけ権利があるとか扱いが違うことがないなら、どちらも人が時間を書けて作ったものなのになぜこんな違うんだろう？
ところで、私個人としてはネットに流れてるのは全部フリーの共有財産でいいのに、って思ってるくらいなので自分が書いたソースコードや作った画像が誰かに使われることに文句言うつもりはないです
勝手に使おうが、まとめに載せようが、クローンサイト作ろうが、好きにどうぞってくらい
どちらかというと、大量にあるコンテンツの中で使ってもらえた、まとめに載ったとか嬉しい方だと思う
あ、もちろんお金が生じてるものでコピーのせいで売れなくなったみたいのは別です
お金とるわけでもなく個人サイトで公開してるようなものについてです
---
トラバについて
一応今の本業です
仕事ではありえないって言ってる人もいますが、そうでもないです
お堅い会社で社内からQAサイトや個人ブログのアクセスが禁止されてるほどのところとかだとないのかもしれませんね
やりたいことそのままのをQAサイトで見つけたらそれをコピペとか
始めて使うもので使い方をググったときに良いサンプルを書いてたブログがあったからそれをコピペして改変して使ってるとか
ヒドイところでは、QAサイトにそのままのコード上げて修正してもらったのをそのまま使うのも・・・ですね
私の周りだと、Stackoverflowの回答のサンプルコードを一度も使ったことない人は少ないんじゃないでしょうか・・・
ただ、今回言いたいのは仕事で扱う系じゃないです
画像をまとめに上げられたくらいで怒ってる人に対して、公開したプログラムが変数名かえたくらいで別ブログで公開されたりgithubにおいてるプロジェクト（1人規模のものでも）で使われてたりです
「○○のやり方」とか「○○はこう使うのがいい」とかブログで書いてたとして、同じ内容が別ブログにもあるなんて結構見かける光景です
電気と情報を混ぜたような学科にセンターできる気しなかったのと、将来がわかんなかったから入学。
高専に入ってソフト系の勉強がしたいという思いはまあ叶ったと思ってる。
授業と部活とで基礎だったり、面白そうなことだったりを見つけることができた。
正直めちゃくちゃ楽しかった。
でも、このまま高専で学年を重ねて行って社会に出たらどうなるのだろう。
twitterで他校の高専生見てると圧倒的に強くてプロみたいなことしてる。
C++とかやってても、「できる奴の技術力」がどのくらいなのかもわからない。
そもそも自分の作りたいものを持ってない時点でプログラマとして失格？
でも、どうなればプログラマとしての技術が身についたのだろう。
先が見えない不安があるし、劣等感にまみれた日々を過ごすのは辛い。
半端なところの半端者が一人になって何ができるだろうか。
ttps://github.com/tootsuite/mastodon
マストドンのAPIのリファレンスとAPI実装済みのライブラリ(サードパティ)の紹介
ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md
マストドンのAPIに関するドキュメントが置いてあるディレクトリ(色々ある)
ttps://github.com/tootsuite/documentation/tree/master/Using-the-API
マストドンはアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある
ttps://github.com/doorkeeper-gem/doorkeeper/wiki
マストドンのドキュメントで紹介されてるAPI実装済みのライブラリ(サードパティ)を使うのが一番ってっとり早い
以上
=====
step1
ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps
POST /api/v1/apps
アプリ登録をわざわざコーディングする場合はライブラリとして作って提供する場合くらい（？）
(アプリを複数のインスタンスに対応させる場合はやはりコード書くしかないけど）
(登録したIDを自前サーバーで持って同一アプリで共有するとか？）
(ローカルでhtmlファイル作ってブラウザ表示して必要な入力してsubmit送信するだけ簡単)
＜form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps"＞
＜input name="client_name" type="text" value=""＞
＜input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob"＞
＜input name="scopes" type="text" value="read write follow"＞
＜input name="website" type="text" value=""＞
＜input type="submit"＞＜/form＞
step2
doorkeeperについて知る必要がある
ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md
このページに書いてあるgrant_type=passwordの認証法ではread権限しか貰えないぽい
grant_type=authorization_codeで認証する必要がある、これ読めば早い
ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow
必要なパラメータ(※1)つけたリンクをアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある
（自前サーバーなどでリダイレクトで受け取ることもできるけど）
その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証が完了する(アクセストークンをゲットできる)
POST /oauth/token
これもただのPOSTになるのでそんなに難しくない
さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリの秘密キーを使うので公開はダメでしょうな
※1
ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow
scopeというパラメータで取得したい権限を指定する必要がある
step3
認証終わってアクセストークンをゲットしたらもうAPI使えるので
ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md
これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから
APIの叩けばよい
※
toot(トゥート)はAPIのドキュメントではstatusという表現になってる
ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses
POST /api/v1/statuses
がtootするためのAPI
http://anond.hatelabo.jp/20170501185419
------------------------------------------------------------------------
2017/05/01 22:39
16時頃より断続的にサイトが表示されない状態が続いており大変ご迷惑をおかけしております。
多数サイト閉鎖の心配のご連絡を頂いておりますが突然の閉鎖は御座いませんのでご安心下さい。
ユーザーの皆様にはご迷惑をおかけしますが、復旧まで今しばらくお待ち下さい。
【サイト復旧のお知らせ】アジア時間16時頃よりサイトに対するアタックを受けており、断続的にページが表示されない状態が続いておりましたが、現在は改善され徐々に表示されております。引き続きメンテナンスを続けているため、タイミングによっては一時的に繋がらない場合がございますので、その場合は時間を置いて再度アクセスいただけますようお願いいたします。
長時間にわたりご不便をおかけしましたこと、深くお詫び申し上げます。今後は再発防止に向け、メンテナンスの強化を行ってまいります。至らぬ点もあり恐縮ですが、今後ともフリーブックスをよろしくお願いいたします。
--------------------------------------------------------------------------------
引用ここまで
今回の増田でアクセスが倍やそこらに増加したところで、自前設備でなくCDNを使っている以上、
長時間のダウンは考えにくいから実際にDDOSを仕掛けた人がいたのかも。
…というのが、普通の受け取り方だろうけど、Alexaランクで国内300位クラスは結構ザコなので、※後述
CDN側もたいしたキャッシュサーバーリソースを割り当ててない／動的割り当てで対応する契約上限量
にひっかかって放置、ってだけかもしれないので本当にDDOSかは不明。
なんせ元々Cloudflareは（アカマイやアマゾンに比べればだが）日本の設備がかなり貧弱なCDNで、
むしろDDOS対策の方はそれなりの水準なんで、公式アナウンスの「アタックを受けており、」を
そのまま受け取ると、「Cloudflareご自慢のDDOS対策やWAFはどーなったの？」って話になるんで、
あまり額面どおりに受け取れない感じ。
Cloudflareの料金体系上、トラフィックの増加は $0.05／10000request くらい
（Buisinessプランの場合。恐らくその上のEnterpriseプランなのでもうちょい安いかも）
なので、一時的なトラ増での支払い増加だけの話では、それなりのダメージになっているかは微妙かも。
（Cloudflareはどうやら転送量でなくrequest数を基本に料金を考える珍しい料金体系のCDNで、
しかもDOSアタックのようなbad requestは勘定に入れないようだ。）
※ザコ
18位 2ch.net
（http://www.alexa.com/topsites/countries/JP より抜粋）
というあたりで、300位台のフリーブックスなど鼻で笑うくらいのトラフィック量である。
某転職イベントに何気なくエントリしてみたけど、やっぱり他の会社の人と話したり自分のgithubの中見て評価もらうのっていい刺激になるな。
新卒で入って6年くらいダラダラ仕事してたけど、今の場所でもっと頑張れるんじゃないかという気分になった。
転職する気が無くてもちょっと他の会社調べてみたりするの良いかもしれないので同じように軽く無気力な人は試してみると良いかも。
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名が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ローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
GitHubの話。
Mastodon開発者とpixivのPawoo、ロリ絵対策について議論する
http://www.itmedia.co.jp/news/articles/1704/16/news009.html
これはすでにイシューという言葉が違和感無く受け入れられている証拠と言ってよいのだろうか。
日本語文章に出現する非日本語表記文字（英字含む）は、主に他国語表記を尊重した固有名詞を指す事が多く、それに当てはまらない言葉はマイナーな単語くらいである。その為、「issue(s)」と表記すると、GitHubだけの固有名詞のように読めてしまう。言い換えるとバグ管理システムという概念上の機能としては見なしづらい。
また、イシューとは別の、より日本語らしい日本語が無さそうなことがもう一点。よくある「課題」という訳では固く、重く、重篤さを含んでしまう。
さらに付け加えるなら、イシューだとちょっとシュークリームみたいでおいしそうだ。楽しく使えそうである。
ただ、「理想的には」と言ったように、超えなければならない課題がある。
それは、「イシュー」で違和感があるかである。シュークリームの例えは逆の意味でも効果を発揮してしまうだろう。
しかし今回の記事のブコメ欄でその懸念は解消されたといえるのでは思った。
そのあたりは時の流れが解決してくれるのだろう。
