  |
はてなキーワード: GitHubとは
> OSSのオーナーからTwitterで是非issueを上げてくれと言われたから頑張ってissueを上げたのに、エアリプで「OSSなのに英語でissueを上げない日本人、本当に空気読めない」と言われ、著名人がそれに「それな」とメンションしてて、もう2度とやらねーと心に誓った。
https://twitter.com/stb_nissie/status/908494673102041088
わからない人に説明すると、GitHub(通称ギフハブ)にはIssue(イシュー)という機能があって、なんかバグってたら問い合わせ出来る機能があるんだ。
でも大半のIssueが英語でやり取りされている。勇気をだしてIssueを日本語で立てたけど、あとで作者にエアリプで陰口を言われてすげームカついたって話だ。
でもこれだけ見ても背景がよくわからない。Issueを上げてくれ、っていうやり取りが日本語なのか英語なのかもわからないし、エアリプで陰口言われたのも日本語なのか英語なのかも分からないからだ。これは裏を取る必要がある。
ちょっと調べてみたけど、おそらく発端はこれだろう。
https://twitter.com/takezoen/status/636551825160695808
> IE以外のブラウザではどうでしょうか？また、可能であればスタックトレースをGitHubのIssueに上げていただけると助かります。
もとのツイート主とGitBucketの作者とのやり取りだ。ちなみにGitBucketとはギフハブのクローンで、コンプライアンス的にギフハブが使えないからサーバーを自前で用意して自社でギフハブを使えるようにするものだ。ちなみにギフハブ本家でもそういうクローンは用意しているが高くて稟議が通らないので仕方なくOSS(≒無料)のクローンを使っている会社は多い。
で、作者とのやり取りを経て出されたIssueがこれだ。
https://github.com/gitbucket/gitbucket/issues/908
タイトルが英語なのはともかく、本文は日本語である。自分の経験則からすると、こういうIssueは速攻でクローズされるか放置されるが、それは後述するとして、例のエアリプはおそらくこれだろう。
https://twitter.com/takezoen/status/648914153785044992
> GitBucketに日本語でIssueを投げてくる方が後を絶たない。ドキュメントも周囲のIssueも全部英語なのに日本人は空気を読むとか嘘なのではないかという気がする。どうすればいいのだろうか…。
そのとおりではある。ドキュメントを見て、Issueを英語で書かなきゃいけないと思わなかったのだろうか。
新しくIssueを立てるときは必ず「New Issue」というボタンを押さなければならないが、そのときに他のIssueを参考にしなかったのだろうか。
例のツイート主のギフハブを見ても、このIssueがおそらく初めてのIssueと思われる。
https://github.com/SatoshiNishimoto
「なんか問題を発見した！」→「世紀の大発見や！」→「Issue投げたろ！」の流れで興奮しながらIssueを立てた可能性はある。初めてのIssueならまさにそうだろう。
もしかしたら作者は日本人だったから「つい」日本語でIssueを立ててしまったのかもしれないし、他のIssueも日本語で書かれているから自分も日本語でIssueを立てたのかもしれない。
本当のところはわからないが、Issueを立てるときは、一晩寝かせてからIssueを立てるべきだったし、一回失敗したからってめげてはいけない。まあ勇気をだしてがんばったのに全力で全否定されるのは非常につらいものはあるが、そういうときはキャバクラにでも行って慰めてもらいなよ。
閑話休題。Issueを立てるときに注意しないといけないのは、まずガイドラインを見ること。次にオープンされたままのIssueがどのくらい残っているかだ。
Issueを立てるときにはたいていガイドラインがある。READMEちゃんと読め。そこにIssueやプルリクを投げるときのルールやマナーが書かれている。中には日本語OKだったり中国語OKだったりするOSSもあるが、そんなのはほんの一部で、たいてい英語だ。そのルールに外れたIssueやプルリクは大抵無視されるかクローズされる。ルールが英語で書かれているということは、Issueやプルリクも英語で書かなければならないということだ。というか、作者にアットツイート出来る勇気があるなら「こんなIssueを投げようと思うのですが、日本語OKですか？」くらいは聞いてもよかったんじゃないか？
次にオープンされたままのIssueがどのくらい残っているかだが、ガイドラインほど重要じゃないにしても、結構見て置かなければならない要素だ。オープンされたままのIssueが3桁以上残ってたら、それはIssueさばきが回っていない証拠だ。もしくはググったりドキュメントを読めば事足りるようなどうでもいい内容のIssueが盛りだくさんな可能性もある。最初のうちは書き逃げでも構わないが、凡百のIssueのなかで自分のIssueを読んでもらえる努力をしろ。
あとこの人、自分のこと意識が低い人間だと思っているけど、有名人に何度もクソリプかましているし、勉強会にもちょくちょく顔を出しているっぽくて、そういうことする人間は意識が低いとは言わないと思うんだよ。意識の高い低いを都合で使い分けるのは辞めたほうがいいと思っている。
とはいえ、OSSに定期的にフィードバックを投げられる人間はほんのひとにぎりで、一生に一回Issueを立てられるかどうかというプログラマーがほとんどだと思う。OSSの作者からしたらそんなの関係ないかもしれないけど、Issueを投げるほうからしたら一生に一度の大舞台だ。そこらへんをよく考えてOSS活動に取り組む必要はあるんじゃないかなとは思う。ま、人生に失敗はつきものだ。気長に生きてこうよ。
なおざりな捜査が誤認逮捕招く 徳島・チケット詐欺 徳島新聞社
http://www.topics.or.jp/localNews/news/2017/09/2017_15051847245614.html
事態が急転したのは女性がチケットを実際に郵送したことを証明する「特定記録郵便物等差出票」を、自ら見つけてからだった。女性は捜査で見つけられなかった差出票を自力で探し出し、釈放５日後に地検に提供。県警が差出票を探した郵便局は愛知県内の１局だけで、女性はその隣の局で見つけたという。
署幹部を含めた捜査員のネットに関する知識の乏しさも、誤認逮捕につながった。刑事課が単独で捜査を担当し、サイバー犯罪に詳しい捜査員のいる生活安全課や県警本部との連携はなかった。西岡署長は「証拠収集の工夫が足りなかった」とミスを認め、「今回の事案を重く受け止め、再発防止に努める」と神妙に話した。
長い勾留が自白強要のためではなく、被疑者による証拠隠滅を防ぐためだとすると、その間の捜査は一体何をやっていたのか。
釈放後に本人が自力で探し出した「差出票」も、その後の捜査で真犯人に至った証拠も勾留期間中の捜査では見つけていない。
捜査に着手した昨年９月から誤認逮捕の今年５月までの捜査も含めて、ナマケモノかアルバトロスのフレンズかな。
サイバー犯罪というとウイルスとかハッキングとかの話になりがちだが、ネット利用の拡大・一般化で通常の犯罪についても
アカウント情報やIPアドレスを警察が開示命令で基礎的証拠に利用するのはごく当然と考えていたけれども。
今後は全国の警察でネットに詳しい部署や県警本部の協力を得るようになるといいですね。
その上でIPアドレスだけでは決定的な証拠にならないという遠隔操作事件の教訓も踏まえてくれれば幸甚。
業界団体公式のチケットリセールサイト「チケトレ」オープンの５月に合わせてチケット詐欺を捕まえようという警察の
5月から6月上旬の期間指定で「チケット詐欺」をググって出てきた逮捕ニュース。
「チケット詐欺 daterange:2017-05-01..2017-06-13」
| 警察 | 事件発生 | 被疑者逮捕 | 被疑者 | 公演 | 概要 |
| 徳島県警三好署 | 2016年8月 | 2017年5月 | 愛知女性21 | 関ジャニ∞ | 誤認逮捕19日間勾留 |
| 奈良県警G署 | 2016年12月 | 2017年5月 | 東京女性19 | ねこ男子 | 濡れ衣任意事情聴取のみ |
| 【類似事案なり損ね】 | |||||
| A)滋賀県警米原署 | 2016年6月 | 2017年4月(再) | 大阪女性24 | 人気グループ | 詐欺を疑った被害男性から返金を求められ、同様の譲渡話を持ち掛けた別の女性から同額を男性の口座へ振り込ませて返金 |
| 【チケット詐欺】 | |||||
| B)警視庁少年事件課 | 2016年11月 | 2017年5月 | 神奈川女性18 | 嵐 | 「（同様の詐欺被害にあった際）だまされたほうが悪いと相手に言われた。お金が欲しかった」 |
| C)警視庁渋谷署 | 2016年2月 | 2017年5月 | 埼玉女性18 | Sexy Zone | 「ツイッターで手口を知った。遊ぶ金欲しさだった」 |
| 愛知県警蒲郡署 | 2017年1月 | 2017年5月 | 京都女性18 | ジャニーズWEST | この記事は有料会員限定です。 |
| 京都府警宇治署 | 2015年7月 | 2017年5月 | 鹿児島男性49 | 関ジャニ∞ | 掲示板サイトを通じて知り合った |
| 愛知県警中村署 | 2017年3月 | 2017年5月 | 住所不定男性34 | NEWS | 直接会って代金だけ受取り住基カードコピー見せて信用させた |
| 【チケット転売】 | |||||
| 兵庫県警察本部サイバー犯罪対策課 | 2017年2月 | 2017年6月 | 和歌山男性43 | サカナクション | 有料FCチケット転売が販売会社に対する詐欺容疑だとして |
| 警視庁生活安全特別捜査隊 | 2016年6月(9月) | 2017年5月 | 東京男性23 | EXILE | 昨年9月のダフ行為で扱われていた大量のチケットを6月に購入した都迷惑行為防止条例違反、「自分が良い席で見たかったので大量に買った」と否認 |
| 京都府警 | 2016年8月～10月 | 2017年6月 | 東京男性43 | 嵐・関ジャニ∞など | 転売のため他人名義でFC入会チケット購入、電子計算機使用詐欺の疑い |
5月ありきで5月の報道を調べたからいろんな発生時期の事件が5月に逮捕されててアレレー、となるけども。
宇治署の2年前なんかの事件もあるし、仮にキャンペーンがあったとしても、５月までは寝かせておいて５月に合わせて
一斉に逮捕しろ、というものではなく、チケット転売が話題になってるのを機に積んである案件を片付けましょうや、
という声掛け程度ですかね。
http://www.kyoto-np.co.jp/politics/article/20170419000165
女は詐欺を疑った男性から返金を求められると、同様の譲渡話を持ち掛けた米原市の女性から同額を男性の口座へ振り込ませて返金したように見せかけていたという。
B)嵐のチケット転売詐欺で少女逮捕 過去に同様の被害に遭い…
http://www.sponichi.co.jp/entertainment/news/2017/06/13/kiji/20170613s00041000104000c.html
チケットを巡り同様の被害に遭ったといい「（その際）だまされたほうが悪いと相手に言われた。お金が欲しかった」と容疑を認めている。
C)セクゾン公演チケットで詐欺…１８少女を逮捕「遊ぶ金欲しさだった」
http://www.sanspo.com/geino/news/20170529/tro17052919130009-n1.html
「ツイッターで手口を知った。遊ぶ金欲しさだった」と容疑を認めている。
https://twitter.com/akihirosato1975/status/907554074412716037
https://gist.github.com/shunirr/2bd6a5a00b966e1e534b443790c68eda
「予期せぬ形でチケット詐欺に巻き込まれて東京から奈良まで行った」めりぴょんさん 13weekslater_ep
犯人にとって転売品は何でもよく、個人間取引を乗っ取った中間者攻撃の三角貿易で現金を詐欺るのが目的。というのはgithub見ればわかる。
犯行少女にとってネット取引の経験があり、価格のぶれ幅のあるチケットを扱ったのだろう。
チケット出品した専門学校生と落札者は、入金・チケット受け取りが完了して事件の存在にも気付いてない。
確かに警察への被害届の訴えは、チケット落札入金したのに届かない、という形だが、そこにとらわれて事件を単純視していたから
実名口座実住所の振込先専門学校生の存在が確認できただけで十分として事件捜査がおろそかになったのだろう。
＞・詐欺は重い罪で、嫌疑後の証拠隠滅も容易な場合が多いので、８万円程度でも１９日の拘束はありうる。
証拠隠滅の問題だったら、事件発生2016年8月、徳島県警三好署への被害届2016年9月、そこから年をまたいで専門学校生逮捕2017年5月は遅すぎる。
証拠隠滅するような犯人が、のこのこ実名口座に入金させるのが警察検察にとっての常識なのか？
＞・もし犯人が架空口座を使ったりBTC等で取引してたら、チケット転売サイトへの情報開示請求だけでは辿れず、ツイッター社へのIP開示、プロバイダ照会まで行かざるをえず、さらに犯人がMACアドレスをデフォルトから変更した上でFree-Wifiを使って取引していたら、辿り着けなかったかもしれない。
むしろまずIP開示、プロバイダ照会をもってデジタル証拠として、あなたが疑わしいから逮捕するよ、と持っていくのが筋ではないか。
その上で犯人が無線LANタダ乗りMAC偽装で、とわかれば、誤認逮捕やむなし論が出る余地がある。
専門学校生へ接触した犯人のIP、被害者へ接触した専門学校生名義での犯人のIP、なと真犯人へたどり着く証拠はあったからこそその後の捜査で見つかったはず。
半年以上の捜査の期間でそれすらもしていないのに、いきなり逮捕勾留して否認・嫌疑不十分釈放してから本格捜査で真犯人到達って怠慢では？
まじな話をすると、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, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
先日、東京に行ってきました。
そんでもって、
フォトジェニックな綿あめ店やかき氷店の前で並んでる感じとか、
「私、良く生きてます」感がプンプンしてた。
テレビ見て、Yahoo!ニュース見て、はてブ見て、GitHub見て、Wikipedia見て、Twitter見て、Facebook見て、YouTube見てるだけの生活。
「これは運営様へのお布施なのだ」と、スマホのゲームへ課金するだけの生活。
私からすれば、彼らの生き方は、背伸びをしているようで、見栄を張っているようで、そんなことにエネルギーを使いたないと思わせた。
そんな「もしもの私」のために、今からちょっと背伸びをするのが良いのかなと思う。
とりあえず、先日はH&Mでお洋服を買ってきた。いつもはユニクロとGUとライトオンでしかお洋服を買わないから、だいぶ頑張ったと思う。
Firefoxの次の次のバージョンからWebExtensionsに対応していないアドオンが動かなくなるそうだけど、はてなブックマークFirefox拡張はちゃんと対応してくれるのだろうか。
いまの2.3.12はまだ対応していないようだし、はてなのGitHubを見に行っても何の動きも見られない。https://github.com/hatena/hatena-bookmark-xul/tree/dev
Rubyがもっとマイナーだった7年くらい前にどや！ってメソッドチェインでコード書いて公開したら読みづらいって言われまくった記憶がある。っていうか俺もメソッドチェインっていう言葉も概念も知らなかったし、周りにもメソッドチェインっていう言葉も書き方も浸透してなかった。とにかく俺は関数繋げて1行で欲しい値を取り出す方法の方がカッコいいと思っていた
当時はgithubを俺は知らなくて(いま調べたらgithub設立が2008年だから自分が知らなくてもしょうがないな)google docsに載せて公開してた
たぶんrailsっぽいメソッドチェインの1行関数で返り値を次の1行関数に渡すような書き方が今後増えていくと思うけどどうなんだろう
あとやっぱりオブジェクト指向って微妙な感じがある。データの持ち方をその都度クラスにはめ込んでインスタンスにするって方法がなんか気持ち悪い。関数だけでいいじゃんってなる。コード書く時にわざわざクラスを作りだしてそれに関数を押し込めなきゃいけないのがなんか気持ち悪い(コード書いてる時に最初に思いつくのはクラスでもオブジェクトじゃなくて関数だ。車を欲しいから車を発明するじゃなくて移動手段が欲しくて結果として車が発明されるのだ)
犬っていうクラスが無くても、鳴くっていうメソッドは存在させておきたい。後から大きな声で鳴くにして、最後あたりで犬が鳴くとか猫が鳴く、みたいなコードの書き方ができなくてクラスを最初に作らせるのが思考に縄をかけられる感じがしてキモい
人間の思考は抽象から具象に下ろすことだって多々あるのに、オブジェクト指向もといオブジェクト思考は具象から抽象に上げなきゃいけないから
例えば俺の妄想はこんな感じ
get_text.from("anond.hatelabo.jp").all_page.tag("title").to_a
Wantedlyはよくエンジニア学生をオフィスに呼んでいます。どこからともなく突然メッセージが来て「一度うちのオフィスに遊びに来てみませんか？」という具合です。私の知り合いも複数そのように誘われているので、よく行っていることなのかなと思います。それ自体はよくあるダイレクトリクルーティングであり別に良い事だと思います。
さて、問題なのは実際にオフィスに遊びに行ってそこで見せられる内容なのです。私も同じように誘われ、Wantedlyのオフィスは綺麗なことで話題になっていたこともあり興味本位で遊びに伺ってみました。経営理念や同業他社との差別化の仕方など会社の話を色々としてもらった後、開発手法に関する話に移りました。Wantedlyではプロジェクトに関するありとあらゆることをGitHubで管理しているという話をされました。何かバグが見つかったり改善アイデアが思いつくとイシューを立ててそこで議論するということでした。
これもよくあることですね。私が驚いたのは、そのイシューを全て見せてくれたことです。
もちろん一覧を全て吟味するという感じではなく、私に見せたい一つの実例を探す際にイシュー一覧ページが私に見えていたということなのですが。しかし、仮に私に悪意があり、更にイシューには外部の者に見られてはまずい問題を扱うものがあり、私がたまたまそのイシューを見つけタイトルから内容を推定できたとしたらどうするつもりなのだろうと思いました。ちなみに話を聞く前にNDAなどを結んでいるわけではありません。他の人にも同じように見せていると考えられるので正直言って「この会社大丈夫かな？」と思いました。
http://b.hatena.ne.jp/entry/s/note.mu/konpyu/n/nc0d2f49676ba
FacebookのgithubリポジトリでPATENTSファイルが存在するリポジトリのリスト
./BridgeIC/PATENTS
./CParser/PATENTS
./DelegatedRecoveryReferenceImplementation/PATENTS
./FBAllocationTracker/PATENTS
./FBFetchedResultsController/PATENTS
./FBRetainCycleDetector/PATENTS
./FBSimulatorControl/PATENTS
./Haxl/PATENTS
./KVOController/PATENTS
./MazeBase/PATENTS
./MemNN/PATENTS
./PathPicker/PATENTS
./Shimmer/PATENTS
./SoLoader/PATENTS
./SocketRocket/PATENTS
./Stack-RNN/PATENTS
./ThreatExchange/PATENTS
./Tweaks/PATENTS
./UETorch/PATENTS
./UdpPinger/PATENTS
./WebDriverAgent/PATENTS
./augmented-traffic-control/PATENTS
./bistro/PATENTS
./chef-cookbooks/PATENTS
./chisel/PATENTS
./componentkit/PATENTS
./conceal/PATENTS
./dataloader/PATENTS
./device-year-class/PATENTS
./dfuse/PATENTS
./draft-js/PATENTS
./ds2/PATENTS
./emitter/PATENTS
./eyescream/PATENTS
./facebook-clang-plugins/PATENTS
./fatal/PATENTS
./fb-caffe-exts/PATENTS
./fb-util-for-appx/PATENTS
./fb.resnet.torch/PATENTS
./fbcuda/PATENTS
./fbcunn/PATENTS
./fbjs/packages/eslint-config-fbjs-opensource/PATENTS
./fbjs/packages/eslint-config-fbjs/PATENTS
./fbjs/packages/fbjs-css-vars/PATENTS
./fbjs/packages/fbjs-eslint-utils/PATENTS
./fbjs/packages/signedsource/PATENTS
./fbkutils/PATENTS
./fbnn/PATENTS
./fboss/PATENTS
./fbpca/PATENTS
./fbpush/PATENTS
./fbtftp/PATENTS
./fbtorch/PATENTS
./fbtracert/PATENTS
./fixed-data-table/PATENTS
./flow/PATENTS
./flux/PATENTS
./fresco/PATENTS
./gnlpy/PATENTS
./hhvm/hphp/hack/PATENTS
./iTorch/PATENTS
./infer/PATENTS
./ios-snapshot-test-case/PATENTS
./jest/PATENTS
./jscodeshift/PATENTS
./learningSimpleAlgorithms/PATENTS
./libafdt/PATENTS
./liblogfaf/PATENTS
./litho/PATENTS
./luaffifb/PATENTS
./mcrouter/PATENTS
./mention-bot/PATENTS
./metro-bundler/PATENTS
./network-connection-class/PATENTS
./nuclide/modules/atom-ide-ui/PATENTS
./nuclide/modules/big-dig-samples/PATENTS
./nuclide/modules/big-dig/PATENTS
./nuclide/modules/nuclide-commons-atom/PATENTS
./nuclide/modules/nuclide-commons-ui/PATENTS
./nuclide/modules/nuclide-commons/PATENTS
./ocpjbod/PATENTS
./openbmc/common/recipes-connectivity/lldp-util/lldp-util/src/PATENTS
./osquery/PATENTS
./planout/PATENTS
./pop/PATENTS
./pose-aligned-deep-networks/PATENTS
./prepack/PATENTS
./prop-types/PATENTS
./proxygen/PATENTS
./puewue-backend/PATENTS
./puewue-frontend/PATENTS
./react-devtools/PATENTS
./react-native-applinks/PATENTS
./react-native/PATENTS
./react-vr/PATENTS
./react-vr/ReactVR/PATENTS
./react-vr/react-vr-cli/PATENTS
./react/PATENTS
./rebound-js/PATENTS
./rebound/PATENTS
./redex/PATENTS
./regenerator/PATENTS
./relay/PATENTS
./remodel/PATENTS
./screenshot-tests-for-android/PATENTS
./sparts/PATENTS
./stetho/PATENTS
./thpp/PATENTS
./treadmill/PATENTS
./wangle/PATENTS
./wdt/PATENTS
./xcbuild/PATENTS
./xhp-lib/PATENTS
./yoga/PATENTS
./ztorch/PATENTS
Githubに中国語だけの書き込みをする人も増えているというツイートを見てしまった。
中国は、共産党によるプロキシや検閲があるにも、関わらず思想の自由さはなくても、経済で殴ってくる感じがある。
技術の研究が進むか否かは、科学研究費用の多寡だけでは語れないが。
言語の壁がファイアーウォールになってるなんていうひとがいるが、
民間の韓国のLINEと日本国内のサーヴィスとを比較したりすると、なんっか
やっぱり
iモードから生まれた絵文字がemojiになったこととか、良いこともあったのだろうが。
なんか、こう、アジアの中でも、どんどん、おいていかれるのだろうか。
ジェット機を作って飛行機も飛ばせないとか、原子力発電所の対処に手を焼いているとかって、
北朝鮮のミサイル技術との比較でいうと、どれほどのものだなのだろうか。
頭の良いエンジニアの人は、その辺りの件について定量的な比較が出来ているのだろうか？
疑問である。
See also : https://anond.hatelabo.jp/20170728223725
仕事でプログラム書いてるけど、社内で自作のフレームワーク作ってる人が多い
一般的に有名なOSSならまだいいが、独自のものだからそれを使いこなしたところで対して意味がない
一応githubだったり、社内のgithub系のやつに公開はされてるが、githubのでスターなんて全くついてないようなもの
せめて30くらいはついてから使うといってもらいたい
自分自身よく体感してるので、他人が入ったり引き継ぎを頼む可能性があるものでは、私は自作のものを使わないようにしてるくらいだ
更に問題は、納品したものが数年は保守があるのに、自作使いたいという勢いだけで使ってるから1年もすれば互換性まったくない2.0とか別のができてて古いのを改修する人が苦労してる
知名度もない自作フレームワークなんかを保守あるプロジェクトで使うなら5年、10年程度はメンテ続けるくらいのもの作ってからにしてほしい
あとついでに、ウチは成果主義なところがあるから、慣なれない上に使いやすくもない、作者に聞かないと分からない仕様ばかりのを使わせれてれば成果もあがらない
それに対して作者は自分の好きに作ってるわけだから、どんどん成果を出せる
周りの人の苦労は増えるばかり
どうしたものかなぁ
