サンディスクのmicroSDカード 512GBが40%OFF。写真や動画のデータ置き場はこれで良くない?【Amazonセール】
炎上して GitHub アカウントが問答無用で停止されましたって話です。当事者としての経験や雑感など雑多にまとめましたので、参考になれば(なるのか?)幸いです。 経緯 ggc というリポジトリを作って遊んでいました。 ggc とは Github Girls Collection の略で、女性 GitHub アカウントを Markdown でまとめたリポジトリでした。実装としては、Followings(自分がフォローしたユーザ)の中から、あらかじめリストに書いておいた女性アカウント名のみを抽出して、アバター情報などを取得し、リスト化するというものでした。GitHub API を Python で叩いていました。 これが本日、おそらく このツイート を契機に炎上したようです。通報も行われたらしく、GitHub 側も通報を受け入れたようで、まず ggc リポジトリが disabled となり、ご
コードレビューや情報収集など、エンジニアの開発シーンに欠かせないGitHub。 技術者の興味関心や開発トレンドが詰まったサービスなので注目が集まることも多々。今年に入ってからはFreeCoodCampの総スター数が、長年トップだったbootstrapを上回ったことが話題になっています。 今回は、2015年9月30日〜2016年9月30日に作成されたリポジトリのなかでスター数が多いリポジトリ上位20個を集めました。 本稿のスター数、フォーク数は2016年9月30日9時現在の数値、メイン言語にはリポジトリ内の上位2言語を表示しています。 スター数が多い上位20リポジトリ 第1位:swift 2015年12月にオープンソース化したSwiftがスター数トップに。2016年9月13日にはSwift3.0がリリースされている。
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します(またはソースコードを丹念に調べます)。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか? 「誰かが既にこの問題を解決しているはずだ!では、なぜこの問題に対する答えがStack Overflowにないのだろうか?」 そのとおりです。恐らく誰かは既にそれを解決
本日(2016/09/15)発表されたGitHubの新機能の中で、目玉となるのが「Project」機能です。Projectでは、GitHubのリポジトリ上でさまざまな作業を管理できます。 本日発表されたGitHubの新機能「Project」にて、タスクリストを作成してみました。楽しい。#GitHub #Project pic.twitter.com/3IO0d8c3Dl — 鹿野壮@Lynda.com授業公開 (@tonkotsuboy_com) 2016年9月15日 本エントリでは、タスクリストの作成例を通して、Projectの具体的な設定方法について紹介します。完成版のタスクリストは下記URLで確認できます。 完成したタスクリスト Step1. プロジェクトの作成 GitHub上にて、[Project]→[Create a project]をクリックします。 プロジェクト設定画面が開か
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 (マークアップ) されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown (略して GFM) という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 (もちろん GitHub 初心者です!) の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ (レンダリング) を気にして
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
質問 【ID非公開さん】 GitHubで自作ツールを公開して世界中の人に使ってもらいたいと考えています。でも自分は英語が苦手です。どうしたらいいでしょうか。 ベストアンサーに選ばれた回答 【SOTAさん】 この記事を読んでください。 わかりやすいREADME.mdを書く SOTA ベストアンサー以外の回答 【melborneさん】 ビジュアルに訴えるツールを作って、README.mdをそのスクショで埋めます。英文は最小限に留めましょう。作ったツールがビジュアルに訴えないもののときは、gvizなどのツールを使って説明をビジュアライズしてください。以下にサンプルを示します。 README.mdのサンプル 以下は、チンピラgem作者のmelborneさんのdigi_mojiというツールのREADME.mdです。英語がちょっと怪しいですが、スクショがあることでツールの目的が明確になっています。 d
2016 - 06 - 29 イケてる感じにソースコードをブログに載せよう! 日記 IT関連 GitHub イケてる感じに載せてる方がいる! Gistを利用する Gistにファイルを作成する はてなブログに貼り付ける プログラムソースの貼り付け結果 はてなブログ以外の場合 普段、私はこのブログの編集方法は「 はてな記法 」を使っています。 慣れればそっちの方が早いし、それはいいんですけど・・・ 私気づいてしまったんです。 プログラムソースが見にくい!! イケてる感じに載せてる方がいる! www.ksakae1216.com コウタロウさんのブログを読んでいて、「イケてる感じにソースを載せてるじゃん!!いいなぁ〜」と思っていました。 そして、よくよく見てみると・・・気づいてしまった! 「hosted with ❤ by GitHub 」 なぬ?! github だと?! そうです。以前書い
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
今更だけど、GitHubを使って3分でHPを公開する。 - Qiita を参考に GitHub に Web サイトを作ってみた。 ブラウザで GitHub にログインする。 [New repository] をクリックし、"Create a new repository" というページに移動する。 [Repository name] に "GitHubアカウント名.github.io(例: yoheia.github.io)" と入力し、"Create repository" をクリックする。 作成したリポジトリの [Settings] をクリックする。 [GitHub Pages]-[Launch automatic page generator] をクリックし、"New user site" ページに移動する。 [Continue layouts] をクリックし、"Choose a t
見た目は地味な「GitHub」だが、強さの秘密はデザインにあり 米GitHub Head of Design、Mark Otto氏 サンフランシスコに拠点を置く米GitHubは、もしかしたら「世界一地味なユニコーン(推定企業評価額が10億ドルを超えるスタートアップ)」かもしれない。同社の「GitHub」はプログラムのソースコードを管理するクラウドサービス。ひたすらアルファベットが並ぶ画面に、派手さは一切無い。 しかしGitHubは、企業向けソフトウエア業界でも有数の「デザインを重視する企業」だ。その証拠の一つがデザイナーの多さ。同社が雇用する「社員デザイナー」は25人。全社員が562人(2016年4月現在)なので、社員に占める割合は約5%となる。ITベンダーにおけるデザイナーの比率は1~2%以下とみられるので、これはかなり多い。 GitHubのデザイナーが取り組んでいるのは、プログラマの「
※最初に断っておきますが、この記事はもちろん、このブログ全体もそうですが、私の個人ブログであって、会社の公式見解とは一切関係ありません 自分のチームや会社でGitHubを使いたいんだけど、チームメンバーにGitHubを使ったことのある人が自分以外いないよ、みたいなケースがあるかと思います。 そんな時に役立つリンク集を紹介しておきます。 英語のリソース GitHub Guides Mastering Markdown Mastering Issues Understanding GitHub Flow GitHub Training YouTube channel GitHub Services curriculum "Kit" GitHub for Developers GitHub for Everyone Pro Git 2 eBook GitHub Git Cheat Sheet P
2016年2月25日、世界をログする書き起こしメディア、ログミーが初のリアルイベント「ログミーLIVE」を開催しました。第1回目のテーマは「働き方」。1人目の登壇者、ギットハブ・ジャパンの堀江大輔氏は、同社が最も大切にしている“幸せの最適化”という価値観を紹介。その上で、社員の半数以上がリモート勤務を導入するGitHubのワークスタイルについて語りました。 第1回 ログミーLIVE「GitHubの働き方」 堀江大輔氏(以下、堀江):今日はGitHubがどういう働き方をしているか、どうしてそういう働き方をしているかを紹介しようと思っています。 いきなり言い訳から始めるんですけど、花粉症がすごいひどくて、じゃあ薬を飲もうと思ったら、いつも以上にとろんとしていて、忘れそうなのでここにコンピューターを置いておきます。 堀江氏のプロフィールとGitHubの社風 まず自己紹介なんですけど、私、堀江大輔
GitHubを使っていて今まで不便だった点として、「IssueやPull Requestの投稿内容を規定することができなかった」ことがあると思います。最初の投稿内容がどうしても不十分なものになってしまい、詳細を聞き出すことから毎回始めなければならない、といった苦痛をいつも感じていた人は多いはずです。 この苦痛も過去のものとなりそうです。IssueやPull Requestにテンプレートが作れるようになりました。Issue and Pull Request templatesという題名で新規機能のアナウンスがありましたので、さっそく日本語に訳してみました。参考になると幸いです。 IssuesおよびPull Requestsのテンプレート 重要な詳細が欠けている問題を解決することは困難です。今、プロジェクトの管理者は、プロジェクトのIssuesやPull Requestsのためにテンプレートを
Docker Hub の Automated Builds を使うと、GitHub または Bitbucket の Dockerfile の変更を検知して、Docker Image を自動ビルドすることができます。 レポジトリへのコミットを検知して、Docker Hub の Docker Image を自動でビルドします。 タグやブランチの追加を検出して、自動でタグ・ブランチ名をTAGとした Docker Image を作ることも可能。 一通り設定を試してみたので、メモです。 unagenau/docker-jiji2 に配置している Dockerfile を自動ビルドするようにしてみました。 Docker Hub のアカウントがない場合は、こちらから作成してください。 1. Docker Hub のアカウント と GitHubアカウントとを連携させる まず初めに、Docker Hub の
日本時間で1月28日木曜日午前9時過ぎから発生したGitHubのサービス障害は、同社のデータセンター内での一時的な停電をきっかけに連鎖的に発生した障害の影響であることが、GitHubのブログに投稿された記事「Update on 1/28 service outage」で説明されています。 GitHubのブログから引用します。 A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to GitHub.com's operation. 主データセンターにおける一時的な停電が連鎖的な障害を引き起こし、GitHub.comの運用にいくつもの深刻な影響を与えてしまった。 GitHubの説明によると、障害が発生したのは協
.gitignore し忘れて他人に見えちゃマズいファイル(パスワードをベタ書きしたファイルや AWS_SECRET_ACCESS_KEY を書いたファイルとか)を git commit しちゃった!そんなときは すればすぐ何もなかったことにできます。 が!そこで気付かずに GitHub へ git push してしまった!こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、パスワードの書き換えやトークンの無効化を施しましょう。 (この時点でもう
SELECKで先日公開した「『モノが悪いから売れない』とは言わせない。営業マンがGitHubを使うと組織が変わる」という記事に、おかげさまで多くの反響をいただきました! 実はSELECKチームでは、このインタビューでお伺いした「チーム全員でGitHubを使ってプロダクトを改善する」というワークフローを既に実践しています。そこで今回は、その結果をまとめたいと思います。 ▼Githubの使い方についてはGithub入門の連載記事をご覧ください。 チーム開発を変える「GitHub」とは?導入方法・使い方を徹底解説!【第1回】【導入編】 記事の要約 1.まず必要なのは、営業と開発で情報の非対称性をなくすこと チーム全員で同じ情報を共有できていれば、価値のないアイデアが出ることはなくなる。そこでまずは、徹底した情報共有の仕組みを作ることが重要。 情報の非対称性がある中でアイデアを出し、結果出てくるア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く