「GitHub」を含む日記 RSS

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

2017-09-16

例のIssueの話について

これな。今日Twitterでバズってたやつ。

> 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活動に取り組む必要はあるんじゃないかなとは思う。ま、人生に失敗はつきものだ。気長に生きてこうよ。

2017-09-15

中学生に踊らされて泡喰ってる徳島県警三好刑事課大捜査線

anond:20170912230437

サイバー犯罪には疎い刑事課単独捜査担当していた

なおざり捜査誤認逮捕招く 徳島チケット詐欺 徳島新聞社

http://www.topics.or.jp/localNews/news/2017/09/2017_15051847245614.html

 事態が急転したのは女性チケットを実際に郵送したことを証明する「特定記録郵便物等差出票」を、自ら見つけてからだった。女性捜査で見つけられなかった差出票を自力で探し出し、釈放5日後に地検提供。県警が差出票を探した郵便局愛知県内の1局だけで、女性はその隣の局で見つけたという。
 署幹部を含めた捜査員のネットに関する知識の乏しさも、誤認逮捕につながった。刑事課単独捜査担当し、サイバー犯罪に詳しい捜査員のいる生活安全課や県警本部との連携はなかった。西岡署長は「証拠収集の工夫が足りなかった」とミスを認め、「今回の事案を重く受け止め、再発防止に努める」と神妙に話した。


長い勾留自白強要のためではなく、被疑者による証拠隠滅を防ぐためだとすると、その間の捜査は一体何をやっていたのか。

釈放後に本人が自力で探し出した「差出票」も、その後の捜査真犯人に至った証拠勾留間中捜査では見つけていない。

捜査に着手した昨年9月から誤認逮捕の今年5月までの捜査も含めて、ナマケモノアルバトロスフレンズかな。

サイバー犯罪というとウイルスとかハッキングとかの話になりがちだが、ネット利用の拡大・一般化で通常の犯罪についても

アカウント情報IPアドレス警察が開示命令で基礎的証拠に利用するのはごく当然と考えていたけれども。

今後は全国の警察ネットに詳しい部署や県警本部の協力を得るようになるといいですね。

その上でIPアドレスだけでは決定的な証拠にならないという遠隔操作事件の教訓も踏まえてくれれば幸甚


5月の全国警察チケット詐欺摘発キャンペーン仮説の補強事例

業界団体公式チケットリセールサイトチケトレ」オープンの5月に合わせてチケット詐欺を捕まえようという警察

キャンペーンがあったのではという増田仮説。

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月埼玉女性18Sexy Zoneツイッターで手口を知った。遊ぶ金欲しさだった」
愛知県警蒲郡2017年1月2017年5月京都女性18ジャニーズWESTこの記事は有料会員限定です。
京都府警宇治2015年7月2017年5月鹿児島男性49関ジャニ∞掲示板サイトを通じて知り合った
愛知県警中村2017年3月2017年5月住所不定男性34NEWS直接会って代金だけ受取り住基カードコピー見せて信用させた
チケット転売
兵庫県警察本部サイバー犯罪対策2017年2月2017年6月和歌山男性43サカナクション有料FCチケット転売販売会社に対する詐欺容疑だとして
警視庁生活安全特別捜査2016年6月(9月)2017年5月東京男性23EXILE昨年9月のダフ行為で扱われていた大量のチケット6月に購入した都迷惑行為防止条例違反、「自分が良い席で見たかったので大量に買った」と否認
京都府警2016年8月10月2017年6月東京男性43嵐・関ジャニ∞など転売のため他人名義FC入会チケット購入、電子計算機使用詐欺の疑い


5月ありきで5月報道を調べたからいろんな発生時期の事件5月逮捕されててアレレー、となるけども。

宇治署の2年前なんかの事件もあるし、仮にキャンペーンがあったとしても、5月までは寝かせておいて5月に合わせて

一斉に逮捕しろ、というものではなく、チケット転売話題になってるのを機に積んである案件を片付けましょうや、

という声掛け程度ですかね。


A)チケット詐欺、別の詐欺で返金 滋賀、容疑の女再逮捕

http://www.kyoto-np.co.jp/politics/article/20170419000165

女は詐欺を疑った男性から返金を求められると、同様の譲渡話を持ち掛けた米原市女性から同額を男性の口座へ振り込ませて返金したように見せかけていたという。


B)嵐のチケット転売詐欺少女逮捕 過去に同様の被害に遭い…

http://www.sponichi.co.jp/entertainment/news/2017/06/13/kiji/20170613s00041000104000c.html

チケットを巡り同様の被害に遭ったといい「(その際)だまされたほうが悪いと相手に言われた。お金が欲しかった」と容疑を認めている。


C)セクゾン公演チケット詐欺…18少女逮捕遊ぶ金欲しさだった」

http://www.sanspo.com/geino/news/20170529/tro17052919130009-n1.html

ツイッターで手口を知った。遊ぶ金欲しさだった」と容疑を認めている。


その他

ヤフオクでは古典的手法」とのやまもといちろう氏の発言

https://twitter.com/akihirosato1975/status/907554074412716037


女子中学生チケット詐欺事件 · GitHub

https://gist.github.com/shunirr/2bd6a5a00b966e1e534b443790c68eda


「予期せぬ形でチケット詐欺に巻き込まれ東京から奈良まで行った」めりぴょん‏さん 13weekslater_ep

https://togetter.com/li/1149919

奈良事例の方の聴取当時から現在までの関連ツイート

2017-09-13

anond:20170913160909

ニュースの図とか、GitHubに上がっていたユースケース図の方が分かりやすいのに、わざわざ文字で書くなよ。読んで考えちゃうじゃんか。

警察増田チケット詐欺中心に事件を考えているのが誤り

犯人にとって転売品は何でもよく、個人取引を乗っ取った中間者攻撃三角貿易現金詐欺るのが目的。というのはgithub見ればわかる。

犯行少女にとってネット取引経験があり、価格のぶれ幅のあるチケットを扱ったのだろう。

チケット出品した専門学校生落札者は、入金・チケット受け取りが完了して事件存在にも気付いてない。

確かに警察への被害届の訴えは、チケット落札入金したのに届かない、という形だが、そこにとらわれて事件を単純視していたか

実名口座実住所の振込先専門学校生存在確認できただけで十分として事件捜査がおろそかになったのだろう。


>・詐欺は重い罪で、嫌疑後の証拠隠滅も容易な場合が多いので、8万円程度でも19日の拘束はありうる。


証拠隠滅問題だったら、事件発生2016年8月徳島県警三好署への被害届2016年9月、そこから年をまたいで専門学校生逮捕2017年5月は遅すぎる。

証拠隠滅するような犯人が、のこのこ実名口座に入金させるのが警察検察にとっての常識なのか?


>・もし犯人架空口座を使ったりBTC等で取引してたら、チケット転売サイトへの情報開示請求だけでは辿れず、ツイッター社へのIP開示、プロバイダ照会まで行かざるをえず、さら犯人MACアドレスデフォルトから変更した上でFree-Wifiを使って取引していたら、辿り着けなかったかもしれない。


しろまずIP開示、プロバイダ照会をもってデジタル証拠として、あなたが疑わしいか逮捕するよ、と持っていくのが筋ではないか

その上で犯人無線LANタダ乗りMAC偽装で、とわかれば、誤認逮捕やむなし論が出る余地がある。

専門学校生へ接触した犯人IP被害者へ接触した専門学校生名義での犯人IP、なと真犯人へたどり着く証拠はあったからこそその後の捜査で見つかったはず。

半年以上の捜査の期間でそれすらもしていないのに、いきなり逮捕勾留して否認嫌疑不十分釈放してから本格捜査真犯人到達って怠慢では?

https://anond.hatelabo.jp/20170912225009

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

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開発環境構築コース

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ファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

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)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

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)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (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, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

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チェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

東京の人たちの「私、良く生きてます」感が辛かった

先日、東京に行ってきました。

そんでもって、

フォトジェニックな綿あめ店やかき氷店の前で並んでる感じとか、

洒落ファッションしてる感じとか、

それから思考を凝らしたお弁当とか、

スタバドヤリングとか、

「私、良く生きてます」感がプンプンしてた。

なんて息苦しいんだろう。ど田舎からやってきた私は辛かった。

テレビ見て、Yahoo!ニュース見て、はてブ見て、GitHub見て、Wikipedia見て、Twitter見て、Facebook見て、YouTube見てるだけの生活

コンビニでいつものおにぎりを買って食べるだけの生活

「これは運営様へのお布施なのだ」と、スマホゲーム課金するだけの生活

そんな私の生活はえらい違いだった。

からすれば、彼らの生き方は、背伸びをしているようで、見栄を張っているようで、そんなことにエネルギーを使いたないと思わせた。

しかし、私はもしかしたら東京生活するかもしれない。

そんな「もしもの私」のために、今からちょっと背伸びをするのが良いのかなと思う。

とりあえず、先日はH&Mでお洋服を買ってきた。いつもはユニクロGUライトオンしかお洋服を買わないから、だいぶ頑張ったと思う。

2017-09-06

Firefox57に対応するはてなブックマーク拡張リリースされるのだろうか?

Firefoxの次の次のバージョンからWebExtensionsに対応していないアドオンが動かなくなるそうだけど、はてなブックマークFirefox拡張はちゃんと対応してくれるのだろうか。

いまの2.3.12はまだ対応していないようだし、はてなGitHubを見に行っても何の動きも見られない。https://github.com/hatena/hatena-bookmark-xul/tree/dev

このままでは12月には使えなくなってしまいそう。

もしかしてChrome版に互換性があってそのままインストールできたりするのだろうか? あとで試してみるかな

メソッドチェインとか

Rubyもっとマイナーだった7年くらい前にどや!ってメソッドチェインでコード書いて公開したら読みづらいって言われまくった記憶がある。っていうか俺もメソッドチェインっていう言葉概念も知らなかったし、周りにもメソッドチェインっていう言葉も書き方も浸透してなかった。とにかく俺は関数繋げて1行で欲しい値を取り出す方法の方がカッコいいと思っていた

当時はgithubを俺は知らなくて(いま調べたらgithub設立2008年から自分が知らなくてもしょうがないな)google docsに載せて公開してた

たぶんrailsっぽいメソッドチェインの1行関数で返り値を次の1行関数に渡すような書き方が今後増えていくと思うけどどうなんだろう

あとやっぱりオブジェクト指向って微妙な感じがある。データの持ち方をその都度クラスにはめ込んでインスタンスにするって方法がなんか気持ち悪い。関数だけでいいじゃんってなる。コード書く時にわざわざクラスを作りだしてそれに関数を押し込めなきゃいけないのがなんか気持ち悪い(コード書いてる時に最初に思いつくのはクラスでもオブジェクトじゃなくて関数だ。車を欲しいから車を発明するじゃなくて移動手段が欲しくて結果として車が発明されるのだ)

犬っていうクラスが無くても、鳴くっていうメソッド存在させておきたい。後から大きな声で鳴くにして、最後あたりで犬が鳴くとか猫が鳴く、みたいなコードの書き方ができなくてクラス最初に作らせるのが思考に縄をかけられる感じがしてキモい

人間思考抽象から具象に下ろすことだって多々あるのに、オブジェクト指向もといオブジェクト思考は具象から抽象に上げなきゃいけないか

例えば俺の妄想はこんな感じ

get_text.from("anond.hatelabo.jp").all_page.tag("title").to_a

2017年現在なら、これも通じる感じある

で、これで使われてる自作メソッドクラスに押し込めようとすると急激にダルくなる

2017-09-04

ぼくが北朝鮮将軍様だったら

玄関前まで米軍がせまって来て,絶体絶命になった時に,

どうやったら一番アメリカダメージを与えられるかって考えると,

核兵器の作り方をものすごくわかりやすく整理して,

githubに上げちゃうという方法を思いついた.

ソウル砲弾を打ち込むよりも,

東京グアムハワイミサイルを打ち込みよりも

はるか世界を変えるインパクトがあると思う.

ネットに放流した情報は回収不可能だし,

OSSによって改良され続けるのは止められない.

世界秩序は根本からくつがえる可能性がある

2017-08-31

Wantedlyに行き「この会社大丈夫かな?」と思ったこと

Wantedlyはよくエンジニア学生オフィスに呼んでいます。どこからともなく突然メッセージが来て「一度うちのオフィスに遊びに来てみませんか?」という具合です。私の知り合いも複数そのように誘われているので、よく行っていることなのかなと思います。それ自体はよくあるダイレクトリクルーティングであり別に良い事だと思います

さて、問題なのは実際にオフィスに遊びに行ってそこで見せられる内容なのです。私も同じように誘われ、Wantedlyオフィスは綺麗なことで話題になっていたこともあり興味本位で遊びに伺ってみました。経営理念同業他社との差別化の仕方など会社の話を色々としてもらった後、開発手法に関する話に移りました。Wantedlyではプロジェクトに関するありとあらゆることをGitHub管理しているという話をされました。何かバグが見つかったり改善アイデアが思いつくとイシューを立ててそこで議論するということでした。

これもよくあることですね。私が驚いたのは、そのイシューを全て見せてくれたことです。

もちろん一覧を全て吟味するという感じではなく、私に見せたい一つの実例を探す際にイシュー一覧ページが私に見えていたということなのですが。しかし、仮に私に悪意があり、更にイシューには外部の者に見られてはまずい問題を扱うものがあり、私がたまたまそのイシューを見つけタイトルから内容を推定できたとしたらどうするつもりなのだろうと思いました。ちなみに話を聞く前にNDAなどを結んでいるわけではありません。他の人にも同じように見せていると考えられるので正直言って「この会社大丈夫かな?」と思いました。

この記事も消されてしまうのだろうか?(笑)

2017-08-30

https://anond.hatelabo.jp/20170830155706

自慢にもならんけど

1997年からネットPC使っててHTTPを人並に読めてgithubスクレイピングライブラリにプルリクエスト出すようなエロシコ二次裏ユーザーだがあのへんの魚拓の取り方は知らんぞ

とった後どうなるのかも知らん

とった後のページは何度か見たことがあるが

個々のWebサービスの利用知識というのは単にその特定Webサービスの利用の経験によるものであって、汎用の経験リテラシでは代替できない

できんもんはできんしそこまで手間かけたくないものの手間はかけたくはない

2017-08-21

http://b.hatena.ne.jp/entry/s/note.mu/konpyu/n/nc0d2f49676ba

FacebookgithubリポジトリでPATENTSファイル存在するリポジトリリスト

./360-Capture-SDK/PATENTS

./BridgeIC/PATENTS

./CParser/PATENTS

./DelegatedRecoveryReferenceImplementation/PATENTS

./FBAllocationTracker/PATENTS

./FBFetchedResultsController/PATENTS

./FBRetainCycleDetector/PATENTS

./FBSimulatorControl/PATENTS

./Haxl/PATENTS

./IT-CPE/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

./android-jsc/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-adb/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/fbjs/PATENTS

./fbjs/packages/signedsource/PATENTS

./fbkutils/PATENTS

./fblualib/PATENTS

./fbnn/PATENTS

./fboss/PATENTS

./fbpca/PATENTS

./fbpush/PATENTS

./fbshipit/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

./immutable-js/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

./mysql-5.6/fbson/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

./shimmer-android/PATENTS

./sparts/PATENTS

./stetho/PATENTS

./thpp/PATENTS

./treadmill/PATENTS

./wangle/PATENTS

./wdt/PATENTS

./xcbuild/PATENTS

./xhp-lib/PATENTS

./yoga/PATENTS

./ztorch/PATENTS

2017-08-10

Linuxカーネル読めとか言う奴って馬鹿じゃないの?

俺も気になってGithubからLinuxソース落としてみたんだけど、これ800MBくらいあるじゃん

こんなのどっからどう読めっていうんだよ

2017-08-08

日本工程师笨蛋的五个理由

  • 他们并不透过github的星星数量或发布服务等等,而透过上台会议为工程师成为有名把自己的价值提高,只在推特而搏客想说“我要上台”“我上台了”。他们并不透过代码而服务,而透过术语而行为做“Mounting”。Mounting驱动开发。衒学趣味
  • 大概的发表而搏客是“把官方Docs翻译到日语了”“把Get Started试试看了”这样的水平,可是因为大部分的读者是没有看英语的习惯(或者不会看)的人们,就被受欢迎的。透过“我明白了”“我有了新知识”“等一下看”等等的反应,著者满足他们的承认欲求而又写下一个垃圾记事。对在日生活中看英语一次情报的人们,这样的记事只是个噪音,可是“觉得明白最新技术”这样的感觉就是一个保持这样的垃圾记事评价的理由
  • 他们非常喜欢技术书,他们就连前端开发透过“学习”开始。可是这种书上的情报只是英翻日的文件或者自私代码,在这个变化很快的世界下,数个月就会简单地落后。虽然最新信息是很多而这些信息都是免费的,可是因为他们被动受到一个传播者给他们的二次情报,信息差距就在市场上成立。
  • 他们不能受到,或者因为很低情报感度不知道这样的事实,透过“日本优秀的工程师很多”等等的发言互相安慰。可是优秀的日本工程师因为已经在海外工作,跟海外工程师议论,而很快地产生成果,所以两极化越来越大。

参见: https://anond.hatelabo.jp/20170728223725

2017-08-07

Github中国語だけの書き込みをする人も増えているというツイートを見てしまった。

中国は、共産党によるプロキシ検閲があるにも、関わらず思想の自由さはなくても、経済で殴ってくる感じがある。

技術研究が進むか否かは、科学研究費用多寡だけでは語れないが。

英語が出来ないが故に、国際競争力が落ちている

言語の壁がファイアーウォールになってるなんていうひとがいるが、

民間韓国LINE日本国内のサーヴィスとを比較したりすると、なんっか

やっぱり

iモードからまれ絵文字がemojiになったこととか、良いこともあったのだろうが。

なんか、こう、アジアの中でも、どんどん、おいていかれるのだろうか。

  

  

情報工学とは別物だろうが。

ジェット機を作って飛行機も飛ばせないとか、原子力発電所対処に手を焼いているとかって、

北朝鮮ミサイル技術との比較でいうと、どれほどのものなのだろうか。

頭の良いエンジニアの人は、その辺りの件について定量的比較が出来ているのだろうか?

疑問である

この調子で、情報スキルも有名な企業研究所で優秀な技術者飼い殺しされていくのだろうか。

2017-08-06

5 reasons why Japanese Engineer are fu*king da*n

  • Because they likes "Technical document" much, though they usually study with books even it's Front-end latest technology, Many of them are just translated original EN contents or da*n not sexy sample code, it's worthless in the world which dynamically changing day by day in few months. Regardless of free latest contents which can be found everywhere, they just get Secondary Information given by some evangelists with passive mindset, it causes making this Evangelist? market stable due to this kind of information gap structure.

See also : https://anond.hatelabo.jp/20170728223725

2017-07-28

ここがクソだよ日本人エンジニア

2017-07-27

独自フレームワークつくるのやめてほしい

仕事プログラム書いてるけど、社内で自作フレームワーク作ってる人が多い

だいたいプロジェクトごとに別のもの使うことになる

一般的に有名なOSSならまだいいが、独自のものからそれを使いこなしたところで対して意味がない

一応githubだったり、社内のgithub系のやつに公開はされてるが、githubのでスターなんて全くついてないようなもの

せめて30くらいはついてから使うといってもらいたい


私自身そういうの作るの好きだから、作りたい気持ちはわかる

ただ、自分以外が辛いだけなのを理解してもらいたい

自分自身よく体感してるので、他人が入ったり引き継ぎを頼む可能性があるものでは、私は自作のものを使わないようにしてるくらいだ


更に問題は、納品したものが数年は保守があるのに、自作使いたいという勢いだけで使ってるから1年もすれば互換性まったくない2.0とか別のができてて古いのを改修する人が苦労してる

知名度もない自作フレームワークなんかを保守あるプロジェクトで使うなら5年、10年程度はメンテ続けるくらいのもの作ってからにしてほしい

あとついでに、ウチは成果主義なところがあるから、慣なれない上に使いやすくもない、作者に聞かないと分からない仕様ばかりのを使わせれてれば成果もあがらない

それに対して作者は自分の好きに作ってるわけだから、どんどん成果を出せる

周りの人の苦労は増えるばかり

どうしたものかなぁ

https://anond.hatelabo.jp/20170727085837

NASgitリポジトリ化するのは、技術的には可能

だけど、なぜgitGitHubに興味があるのか、一体何がしたいのか。

なぜNAS単体や、またはDropboxなどではダメなのか。gitだとなぜ解決するのか。

gitに何を期待しているのか、まずそこを考え直してみよう。

NASGITやってみたい

GIT

よく理解してない

GITHUB

するとパブリックになって拙い。

非公開は有料。そんな金ない。

NASGITだと、職場にいるときだけしか作業できなくなることに?

どうすればいいのか?

リモートリポジトリクローンする まで読みました。

リモートリポジトリにプッシュする 〃

マージという作業を行なって他の履歴での変更を取り込むまで自分push拒否され」

文章が分かりにくい

マージ作業により他ユーザーの変更履歴を採り入れれば、自分PUSHは通る」


帰宅前に最新のファイルをMegasyncにコピーして

翌朝出社時に最新のをコピーする?

2017-07-26

[]

40も半ばを過ぎて50も見えてくるような年齢になって

新しいソフト習得しなきゃならないのか?

しかも今まで使っていた同種ソフトとだいぶ勝手が違う

ポリシーが違うというか( ^ω^)・・・

徐々に慣れるしかいか

部署GITHUBで共有できるところまで深化したいもの

Rdataというのがエクセルでいうところのxlsx対応するのか?

エクセルと異なり、プロジェクトごとにフォルダーを作り、しか

そのフォルダーの中に input, output, ...といったサブフォルダー

作ったほうがよさそうだ。

だれかにデータを送るときはrdataファイルだけじゃなくて

フォルダー書庫化したものを送らなければならんのか

2017-07-24

https://anond.hatelabo.jp/20170724204646

「こんなこと」って具体的に何よ。

github使いこなしてるやつはどういうアプリを公開してるわけ?

https://anond.hatelabo.jp/20170724204528

こんなことができまぁす!ってアピるんならgithub使うのが鉄板ってだけ

ってか技術者ってgithubコード公開した方がいいのか?

公開できるようなプロダクトなんて何一つないんだが。

いや、コード自体は書いてるけど自分の家のgitlabで運用してるからgithubなんか使いたくないんだが。

https://anond.hatelabo.jp/20170724140817

過去の功績やこれまでの技術はゆるぎないと思うよ。

github見ても近年はあんまり草生えてないけど。

一休の中ではバリバリ開発してるのかな?

キャリアコンサルタント会社作った奥さんにマネジメントしてもらうのがいいと思う。

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