「Github」を含む日記 RSS

はてなキーワード: Githubとは

2017-05-23

不安個人、立ちすくむ国家 」⇦完全に加害者なのに被害者ぶりっぷりすごい

例の経産省の今更だけどなんかモヤモヤが消えないのは多分擁護が出たせいなんだけどさ。

一番ムカつくのが、完全にお前らのせいだよねっていう。(いろんな人がすでに指摘がされてるけど)

この惨状を作り出した官僚が若手提起だからか「老人たちに搾取されてる若者」っていう被害者目線ダサいパワポ出してきたことだよね。

お前いう!?って感じだよまじで。

失われた20年を作り出した戦犯経産省エリートになりたくて入った寄生虫官僚が、自分たち退職金天下りも完備して離さないくせに被害者ぶる

唖然だよね。

世代対立だって年金など諸対策を大幅に間違えたお前ら官僚のせいだよね。

老人のせいじゃない。資料だとまるで老人が悪いかのような書きぶりだけど。

老人にできもしない計画年金や皆保険制度)立ててそこにいい顔する金足りないって現役世代から年々奪ってく金増やしてるお前らが言う?

世代間の対立にお前らがしてるだけど?

年寄りが働きたい!?官僚仕事民間に?

全部お前らがしてほしいことじゃねーかよ。結論ありきすぎるだろ。

エリート面したくてそんな国民に何十年も苦痛を強いてる悪の枢軸たる経産省官僚が今更被害者ぶるんじゃねーよ。

せめて悪なら悪らしくしてろよ。知識人集めた上で自分たち誘導したい結論に持ってく卑怯な手口含めてさ、とにかく悪の覚悟が足りなすぎるんだよ。

民間は皆お前らが政治家にも中央省庁にも完全に諦めてるからさ。

せめて悪らしくしててくれる?

被害者ぶられるとまじでイライラするわ。そしてせめてgithubとかで出されたらまだ許せたよね。パワポって。あのダサさといい無能感すごいからね煽りっぷりすごかったよね。

2017-05-20

技術増田のすゝめ

最近IT系ホットエントリーにも増田が並ぶようになってきました

何故これらの記事を書くのか?どう活用すればいいかを書いておきます

なぜ書くか?

悪口を書くと場が荒れるだけでなく個人攻撃誹謗中傷に晒されることになり非常に危険からです。

例えばこのような記事は、Qiitaにも書けないです。記事の削除、最悪アカウントの削除もありえます

身の安全担保しつつ何かをDisる場合2chかここしか無いでしょう

はてぶコメントは書かない、読まない

書くのも読むのもほどほどにしておいた方が良いです。

彼らはマウンティングがしたいだけで基本的に手を動かしている人の方が少ない印象があります

GitHubBlogで有名な人は良いですが、はてぶだけで有名な人のコメントを真に受けても得るものは無いでしょう

書くときは断言口調で

書くときは語気を強めに書いて、少々の煽り言葉も混ぜておくといいでしょう

むかついた人が反応してブックマークコメントしてくれます

また、技術的にちょっと突っ込みどころがあるような書き方をしておくのもよいです。

こうするとマウンティングしたいブックマーカーたちが、鬼の首を取ったように突っ込みコメントをしてくれます

あとは勝手ブクマtwitter等で喧嘩し始めるのを待ちます

技術ネタを探す場合キーワード検索

このようにはてなキーワード登録されてる単語検索して眺めると探しやすいです

炎上させたい場合は無言ブックマークだけして、はてぶユーザー喧嘩するのを待ちます

http://anond.hatelabo.jp/keyword/Ruby

http://anond.hatelabo.jp/keyword/Docker

ほどほどにしておく

最後になりますが、ほどほどにしておいた方が良いです

gitterやGithubのissueに書き込んで反応を見る方がよほど生産的で有益な方々のフィードバックがあるでしょう

ちょっと煽って反応を見るとか、実際みんなどう思ってんの?を確認する程度にとどめましょう

プログラムコピー当たり前なのになんで画像だと文句言う人多いんだ

自分サイト写真イラストなど画像をまとめに貼られたとか、編集して使われたとか文句言ってる人をそこそこ見る気がしま

私がはてブを見ることが多くなったからか、ここ最近プログラム関係ブログに書いてるのもよく見かけます

プログラムだと当たり前のように個人ブログやQAサイトのものコピーして、そのまま使ったり必要に応じて書き換えて使ったりだと思います

プログラムだと公開する方も使ってもらうことを意識してる人が多くて、OSSなどフリーのものを作ったりしてるひとも多いようです

プログラム書いて公開する人には自分でつくったのをみてもらいたい、使ってもらいたいと感じる人が多くて、画像を公開する人は、他人自分のものを使うのを気に入らないって心の狭い人が多いのでしょうか?

プログラムだってライセンスはなになにだ、っていう話も見るので画像には権利が生じて、プログラムはそんなのない、ってことはないかと思います

法的にどっちにだけ権利があるとか扱いが違うことがないなら、どちらも人が時間を書けて作ったものなのになぜこんな違うんだろう?

ところで、私個人としてはネットに流れてるのは全部フリーの共有財産でいいのに、って思ってるくらいなので自分が書いたソースコードや作った画像が誰かに使われることに文句うつもりはないです

勝手に使おうが、まとめに載せようが、クローンサイト作ろうが、好きにどうぞってくらい

どちらかというと、大量にあるコンテンツの中で使ってもらえた、まとめに載ったとか嬉しい方だと思う

あ、もちろんお金が生じてるものコピーのせいで売れなくなったみたいのは別です

お金とるわけでもなく個人サイトで公開してるようなものについてです

---

追記

トラバについて

みんなプログラマ視点意見ですね

はてなだとプログラマ的な人が多そうですし、納得です

仕事プログラムいたことないか?ですが、あります

一応今の本業です

仕事ではありえないって言ってる人もいますが、そうでもないです

普通にコピペで使われてるのはよくあります

お堅い会社で社内からQAサイト個人ブログアクセス禁止されてるほどのところとかだとないのかもしれませんね

やりたいことそのままのをQAサイトで見つけたらそれをコピペとか

始めて使うもので使い方をググったときに良いサンプルを書いてたブログがあったからそれをコピペして改変して使ってるとか

ヒドイところでは、QAサイトにそのままのコード上げて修正してもらったのをそのまま使うのも・・・ですね

私の周りだと、Stackoverflowの回答のサンプルコードを一度も使ったことない人は少ないんじゃないでしょうか・・・


ただ、今回言いたいのは仕事で扱う系じゃないです

画像をまとめに上げられたくらいで怒ってる人に対して、公開したプログラム変数名かえたくらいで別ブログで公開されたりgithubにおいてるプロジェクト(1人規模のものでも)で使われてたりです

「○○のやり方」とか「○○はこう使うのがいい」とかブログで書いてたとして、同じ内容が別ブログにもあるなんて結構見かける光景です

(参考にする側からすれば複数のところで書いてたほうが信頼できるのでありがたいですけど)

2017-05-11

田舎高専四年の自業自得の嘆き

メンタルヘラってきたのでなんか文字に起こしたいと思う。

電気情報を混ぜたような学科センターできる気しなかったのと、将来がわかんなかったか入学

ただ漠然ソフト系の勉強がしたいと思ってた。

高専に入ってソフト系の勉強がしたいという思いはまあ叶ったと思ってる。

授業と部活とで基礎だったり、面白そうなことだったりを見つけることができた。

正直めちゃくちゃ楽しかった。

でも、このまま高専で学年を重ねて行って社会に出たらどうなるのだろう。

スキルも無ければ、コミュ力も無し。

twitterで他校の高専生見てると圧倒的に強くてプロみたいなことしてる。

自分努力しなかったってのは原因として十二分にある)

C++とかやってても、「できる奴の技術力」がどのくらいなのかもわからない。

Effective C++みたいな難しい本を理解してたら?

自分でかんたんなゲームが作れたら?

githubになんか怖いゴリゴリのTMPあげてたら?

そもそも自分の作りたいものを持ってない時点でプログラマとして失格?

自分のでプログラムを組むのは楽しいし、好きだと思う。

でも、どうなればプログラマとしての技術が身についたのだろう。

先が見えない不安があるし、劣等感にまみれた日々を過ごすのは辛い。

高専生は中途半端とか言われるとなお辛い。

半端なところの半端者が一人になって何ができるだろうか。

2017-05-06

Perlは終わった完全にオワコン

perlは終わった。もうずいぶん前から終わってたけど話題にも上がらないってことは完全に終わってる。

Githubトレンドを見てもperlなんて出てくる日の方が少ない。

結局Perlみたいにいろんな書き方ができるような言語はお呼びじゃねーってことだろう

Go/Pythonみたいな言語がもてはやされるのはそのためだろう

ライブラリ充実度に至ってはpython圧勝

Web開発ならRailsがあるRuby

どこでも動かせる意味ならGolangが最強だろう

Perl6については意味からない演算子増えて、さらに読みにくくなった

うPython, Rubyに追いつくこともできないだろう何よりリリースが遅すぎたもうPerlが入る余地はない

バイバイPerl(´;ω;`)ノシ

http://anond.hatelabo.jp/20170505235115

外部にデータが残るツールは使いたくないんだよ。責任問題が大きい大企業とかは。

「消そうと思えばいつでも消せる。」「自社でトラブルがない限り部外者は消せない。」という条件が必要なんだよ。

ってことが一時期関わってたところでは暗黙の了解だった。

連絡手段メールのくせにコード管理GitHubかいう謎環境だったけど。

きっとコード以上にメール文言は部外秘だったんだ。

「5分ほど遅れます」とかしかメールしなかったけどきっと重要だったんだ。

2017-05-03

OSSプロジェクトにおけるジェンダーバイアス

オープンソースソフトウェアプロジェクトにおいて、女性コントリビューション(修正パッチを送るなど)は平均的には男性よりもアクセプトされる率が高い。

しかし、女性だと判別可能状態で行われたコントリビューションはリジェクトされる率が高くなるのか。

https://phys.org/news/2017-05-gender-bias-open-source.html

本題ではないがGitHubアクティブ活動している人の内6.3%くらいが女性らしい。

2017-05-02

マストドンAPI

マストドンリポジトリ

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実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカル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

GET /oauth/authorize

必要パラメータ(※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時頃より断続的にサイトが表示されない状態が続いており大変ご迷惑をおかけしております

発生直後より現在も復旧作業にあたっています

多数サイト閉鎖の心配のご連絡を頂いておりますが突然の閉鎖は御座いませんのでご安心下さい。

ユーザーの皆様にはご迷惑をおかけしますが、復旧まで今しばらくお待ち下さい。

2017/05/01 23:37

サイト復旧のお知らせ】アジア時間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は勘定に入れないようだ。)

しろサイト信頼性低下の方が痛いでしょうね。

※ザコ

例えば、はてな国内Alexaランクは、

18位 2ch.net

19位 Hatena.ne.jp

20Github.com

21位 Naver.jp

22位 Goo.ne.jp

23Hatenablog.com

http://www.alexa.com/topsites/countries/JP より抜粋

というあたりで、300位台のフリーブックスなど鼻で笑うくらいのトラフィックである

もっと元増田氏が危惧するように、すぐこの辺まで来そうな破竹の伸びではあるのだが。

2017-04-22

http://anond.hatelabo.jp/20170421230333

既にカバーされてるけど、やっぱりgithubで公開したらバカに見えるのが一番の問題になる。例えばあなたgithubコード見てて、関数名が中国語韓国語で書かれてたら公開した奴等をバカと思うよね。それと同じことが日本語でも起きるわけだ。

わざわざバカに見える選択肢を選ぶ必要はないという話。

ハッシュタグを書いててしまうとDMですら誰でも閲覧可能になる@Mastodon

…ようだ。つまりハッシュタグつけてるとWebページ版のハッシュタグページに投稿ががっつり載る

Githubのとこのissuesに載ってそうだと思ってざっと見てみたけど英語得意じゃないことを思い出してやめた

フォロアー向けどころかダイレクトメッセージであっても表示はされるようなのでこれから気を付けようと思った

(右肩の日時表示クリックして個々のTootを表示させようとすると公開範囲指定が効いてエラーページに飛ぶのだが、ぶっちゃけそれでは遅すぎる)

今後直るんだとは思うけどさ

2017-04-21

軽く転職活動したら頑張ろうという気になった

転職イベント何気なくエントリしてみたけど、やっぱり他の会社の人と話したり自分githubの中見て評価もらうのっていい刺激になるな。

新卒で入って6年くらいダラダラ仕事してたけど、今の場所もっと頑張れるんじゃないかという気分になった。

転職する気が無くてもちょっと他の会社調べてみたりするの良いかもしれないので同じように軽く無気力な人は試してみると良いかも。

明日から頑張るぞ!

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

Mastodonインスタンス自力インスコできるだけで羨ましい

改造目的じゃなければRubyからフロントエンド知識なくても問題ないと思うが、大してドキュメント揃ってない中、ものの数時間で公開しちゃう人たちが大勢いるみたいだからすごいなって普通に思う。

少なくともこれだけの知識必要なんでしょ。すごいよ。

2017-04-16

issue(s)はイシューと書いてよいか

GitHubの話。

Mastodon開発者pixivのPawoo、ロリ対策について議論する

http://www.itmedia.co.jp/news/articles/1704/16/news009.html

この記事では「イシュー」という言葉が2回出てくる。

これについて、ブコメには特にツッコミはない。

これはすでにイシューという言葉違和感無く受け入れられている証拠と言ってよいのだろうか。

自分理想的にはイシュー賛成派である

日本語文章に出現する非日本語表記文字(英字含む)は、主に他国表記尊重した固有名詞を指す事が多く、それに当てはまらない言葉マイナー単語くらいである。その為、「issue(s)」と表記すると、GitHubだけの固有名詞のように読めてしまう。言い換えるとバグ管理システムという概念上の機能としては見なしづらい。

また、イシューとは別の、より日本語らしい日本語が無さそうなことがもう一点。よくある「課題」という訳では固く、重く、重篤さを含んでしまう。

さらに付け加えるなら、イシューだとちょっとシュークリームみたいでおいしそうだ。楽しく使えそうである

ただ、「理想的には」と言ったように、超えなければならない課題がある。

それは、「イシュー」で違和感があるかであるシュークリームの例えは逆の意味でも効果を発揮してしまうだろう。

しかし今回の記事ブコメ欄でその懸念は解消されたといえるのでは思った。

とは言え、イシューだと無知感が出ているようにも思う。

そのあたりは時の流れが解決してくれるのだろう。

今日ますとどん

なんかgithub議論面白いというか難しい方向に行ってる(u ・ω・)

pixiv提案不適切キャッシュしない→いいかも、技術的には→待てよ、

すると全ての国で完璧合法もの以外は不適切にしないといけなくないか

それを各国のそれぞれのユーザー判断する?問題あるし無理だろ→日本のだけそう処理するってのはどうだ

→じゃあもしロシア鯖がホモダメから不適切にしてくれ言ってきたらどうすんの、

あっちが良くてこっちはダメって帝国主義じゃね、うんぬんかんぬん。

基本的には前向き(つまり日本の文化尊重したい)なんだが、同時に"差別扱いはダメだ、それは普遍可能か"っていうふうに議論を詰めていく。

ある国で合法ものが別の国で非合法である時、片方が折れたり排除されることに正義はあるのか、ということだと思う。

今回のことはほんの一例であって、もしここで判断を誤れば、マストドン自体の将来にわたる良さ、正しさ、方向性を間違うことになる…おそらくそういうことを恐れて議論が進んでいる

https://pawoo.net/users/SANDWORKSP/updates/190611

2017-04-15

マストドン言い始めたのは誰?

http://anond.hatelabo.jp/20170414043828

急にマストドン言い始めたのはあの遠藤諭らの記事からなの?。20年前の遠藤諭ならそれくらい影響力持ってたかもしれないけど、ちょっと意外。

ASCIIITMedia記事以前の「マストドン」への言及は大体ロックバンドの話だな。https://www.amazon.co.jp/Emperor-Sand-Mastodon/dp/B01N6V8SZC あるいはアディダススニーカーRO MASTODONの話。

本当に遠藤諭(4月10日)と岡田有花(4月13日)の記事国内の発火点のようだ。

国内で賑わっているというぬるかるさんのサーバが立ち上げられたのは4月11日

遠藤諭さんのところにMIT Technology Review編集長からサーバを立てないかと打診があったのが4月7日

GitHub https://github.com/tootsuite/mastodon への初ブクマ2017/04/05 11:43。これは英語圏記事を見てブクマしたのだろう。遠藤さんの記事の前に4つの公開ブクマを集めていた。

海外ではVICEが4月5日記事にしてから話題に。

Mastodon Is Like Twitter Without Nazis, So Why Are We Not Using It? - Vice Motherbord

https://motherboard.vice.com/en_us/article/mastodon-is-like-twitter-without-nazis-so-why-are-we-not-using-it

同じ日にWIREDでも記事掲載

Could Mastodon be the social network to replace Twitter? - WIRED

http://www.wired.co.uk/article/mastodon-social-network-what-how-create-account

その他メジャーどころもマイナーどころも5日から7日にかけて一気に記事にした。どこが火付け役かまでは追えていないが、これらの記事が発火点のようだ。

Hacker Newsでは去年の9月と今年の1月ちょっとした話題になっている。

https://news.ycombinator.com/item?id=13303346

https://news.ycombinator.com/item?id=12646083

しかし具体的に使ってみてどうこうという話は英語圏でも4月に入ってから本格化したようだ。

遠藤諭岡田有花ちょっとした記事を書くだけで爆発するほどTwitter代替サービスを求める需要が高まっていたんだろうな。

ちなみにはてブでのhttps://mastodon.social/about への初ブクマ2016/10/08 11:32。4月5日記事ラッシュの前に10人の公開ブクマを集めていた。

2017-04-10

情報収集エンジニアについて

情報収集だけで満足する君のことだ

参考書を買って満足するやつだったんじゃないのかな?

いから手を動かせ

人のソースコードケチつける前に自分githubに作ってみなよ

2017-03-28

ひるね姫まらなすぎ

ひるね姫見た。なんだこの糞映画

まらなかった理由を挙げていく。

# 登場人物が糞

## 会社の今の状況がわかっていなくて、ただ自動運転オリンピックで実行させようとする会長

## 自動運転を成し遂げようとする目的は正しいが、手段を選ばず、自動運転プログラムを入手しようとする悪役

## 会長、悪役の意志無視し、裏切って桃太郎コンタクトを取るゴミ社員

## 妻の成果を一人独占し、自己満足をするために利用する桃太郎 (コミュ障)

## とりあえず岡山桃太郎という設定に載せられるキジサル存在感ない脇役共

## ことを面倒にする、泥棒ナルコレプシーキチガイ主人公

# 都合の良い夢設定

メインのストーリーだけでは盛り上がらないと判断して、夢と現実を交互に入り乱せる設定に

したのかもしれないが、夢の世界になると、「あー夢ね」という感じで急に冷めてしまう。

夢の世界ならなんとでもなるし、ストーリー全然ハラハラしない。

現実世界でも他人の夢の話って大抵退屈だろう。その永遠退屈な夢話を見せられたような気がした。

ここさけ とかはファンタジー要素一瞬入れたけど、それ以外は割り切っていてストーリーに入りやすかった。

# 冗長説明

いや、もうそ映像だけでわかるから! みたいな説明が多い。

対象年齢を広くするためにこういうことしているのかもしれないが、ただ不快しかない。

バケモノの子 でも同じことを感じた

# アニメーションが糞

取ってつけたようなロボットアニメーション作るな。

ラストコウモリが出てきたくらいからはまともになったけど、それ以外は本当に糞。

# 脚本が糞

悪役「すいません、オリンピック自動運転のために奥さんが作られたプログラム頂けませんか?」

桃太郎了解です。githubオープンソースで公開しておきますね。」

これで終わる話

# 女子高生使っておいてパンチラがない

あんなにスカートヒラヒラさせておいてパンチラないとか馬鹿なの?

# その他

自動運転から急にAI目覚めたりとか、あんなに説明過多なのに悪役の動機とか、警察への逮捕理由が不足していたりとか、

世界ごまかされて、盛り上がる現実世界部分見られなかったりとか

もう本当にゴミクズ映画でした。

2017-03-24

老害エンジニアになってしまったあなたへ

評論家気取りで手を動かさないお前だよ

口だけ出すなんてクソ簡単

Githubなんて真っ白じゃん

いから手を動かせ

抽象的論やらエモい耳障りの良いことをいうが

お前が気分良くなるためにやってるんだろ?

話したいだけだろ?聞いてほしいだけだろ?

聞かれたことがあったか

「いい本ありますか?」

「日々の勉強方法はなんですか?」

なんてことを一度でもよ

聞かれてもないのに長々と講釈を垂れるお前はどう映るか分かるか?

とりあえず、明日からはもう少し黙れ

そこから始めてみようか

2017-03-18

gitしか知らないけれど

SVNの何がダメなのかよく知らない。

知る必要もないんだろうけど。

ただ、過去技術ってこうやって無くなっていくんだろうなって実感する。

みんな使うからgithub使ってるし、なんとなくgithub好きだからエディタAtomを使ってる。

計算機以前の「技術」って積み重ねていくもの無駄になる知識なんて無かったんだろうけど(切削加工の知識とか設計図の読み書きとか)、

計算機ができてから「これまで大活躍だったのに10年後には知っていても何の役にも立たない技術」っていうのが増えてきてるんだよねきっと

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん