なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
本連載「こっそり始めるGit/GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの一つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終えるころには、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 連載第4回目の本稿のテーマは「コンフリクトが発生したときの対処方法」です。 前回の「Git初⼼者でも分かるGitブランチの作成、確認、切り替え、マージ、削除の⼿順」までで「ブランチ作成」から「マージ」までの一連の操作を行いました。前回行った一連の操作では片方の「second」ブランチだけで変更を進めたので、変更内容が複数ブランチ間で「コンフリクト(衝突、競合)」することなく簡単にマージできました。しかし、実際の開発では変更内容がコンフリクトしてしま
Get Your Large Dynamic JavaScript Website, Crawled, Indexed and Found
綺麗にコミットしてますか?? はじめまして!Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何? Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Red Hatは、同社がオープンプロジェクトの運営や、意思決定、コラボレーション、コミュニケーションなどを行う際に用いているベストプラクティスを一般公開した。 別の言い方をすれば、Red Hatは意思決定のコード(規範)をGitHubで公開したということになる。 同社の「Open Decision Framework(オープンな意思決定の仕組み)」は、企業やIT業界のリーダーが目を通すべき文書になりそうだ。このフレームワークは「意思決定者が透明性の高いコミュニケーションを取り、多様な意見を取り入れ、分散しているチーム間でより効果的にコラボレーションを進め、ビジネスプロジェクトや判断への想定外の影響を抑えるのを助ける」ものだという。 Re
この本の概要 アプリケーションの開発手順,製品のユーザマニュアルなど,ドキュメントの多くはエンジニアによって作成されています。ドキュメントの品質が低い場合,読み手が誰であっても内容の理解に時間がかかります。ドキュメントは簡潔で内容を正確に伝えるものでなければなりません。 エンジニアにとってドキュメント作成は避けて通れません。いまやドキュメント作成はコーディングと同様にエンジニアに必要な技術なのです。本書は,ソフトウェア開発の技法に基づいてドキュメント作成を支援するシステムを構築します。このシステムではGitを用いたバージョン管理,GitHubによる共同編集,RedPenによる品質チェック,CIツールによる継続的改善などを利用します。 応用としてAsciidoctorによるドキュメントのスタイル調整について解説します。Webでの公開に耐える品質はもちろん,技術文書の電子出版においても役立つ内
オープンソースソフトウェアについての論文や白書を公開するプロジェクト「The Journal of Open Source Software(JOSS)」が立ち上がった。査読プロセスや編集委員会などを備える、本格的なオンライン学術論文誌となるという。 ソフトウェア開発者や研究者にとって自分たちの作業のインパクトを測定することは大切だが、そのためのツールや指標がなかった。またJournal of Open Research Softwareなどの論文誌はあるが、論文を作成して提出するためには多くのリソースが必要となるという問題があった。Journal of Open Source Software(JOSS)はこれらの問題に対応するものとなる。提出ワークフローやドキュメンテーションを簡素化することで、論文を作成する開発者の負担を軽くする。ソフトウェアのドキュメンテーションがきちんとしていれば
新料金プランは、月額7ドルの「Personal」と、最初の5ユーザーが月額25ドル(追加ユーザーは月額9ドル)の「Organizations」の2つを含みます。 月額7ドルのPersonalでは、プライベートリポジトリを無制限に作ることができると説明されています。Organizationも同様に、プライベートリポジトリを無制限に作成可能。この新料金は本日から利用可能です。 いままで通り、パブリックなリポジトリやオープンソースのプロジェクトは無料。 現在、「GitHub Sattellite」の基調講演が日本時間16時半から17時までの予定で行われているところです。新しい情報が入った場合にはこの記事をアップデートします。(更新終了しました)
1. Oracleプロファイルを持っていないといけない。ダウンロードする時に "No thanks" に気付かないと作らされるアレ。 2. Oracle Contributor Agreement にサインしないといけない(OCAにサインしたかどうかがOracleプロファイルに紐付けられる…ので、Oracleプロファイルが必要みたい) が前提になる。 【2016/05/06 23:35】 ちなみにMariaDBの場合も似たようなもので If you want the code to be part of the main MariaDB tree, you also have to give the MariaDB Foundation a shared copyright to your code. This is needed so that the foundation can of
はじめに GitHub Pull Request Builder Plugin とは何ぞや?的な内容については、下記のページを参考にしてください。 私も非常に参考になりました。ありがとうございます。 Jenkinsでプルリクエストをビルドする Pull Request Builder PluginをJenkinsに導入する jenkins で GitHub のプルリクエストをマージしてテストする その上でこのページでは、多すぎる設定項目について、上記参考ページでは書かれていない部分や、私がハマった部分などをベースに解説できればと思います。 システムの設定 GitHub Pull Request Builder のブロックまで移動。 トークンの生成 Create API Token... から、ID/PW を使ってトークンを生成する。 このとき、前回生成したときのゴミなどが残っていると生成に
「GitHub Enterprise 2.5」リリース。数万人の大規模な開発チームにも対応するクラスタリング構成、アクセスの集中にはキャッシュインテンシブな処理で対応 GitHubは大規模な組織での利用にも対応したソースコード管理ソフトウェアの新版「GitHub Enterprise 2.5」のリリースを発表しました。 GitHub Enterprise 2.5の最大の変更点は、大規模な開発チームでの利用にも対応するようにクラスタリング構成によるスケールアウトが可能になったことです。 ただしクラスタリングは非常に大規模な運用向けに特別に設計されているため、管理リソースの追加も必要となるとのこと。 また、GitHub Enterprise 2.5では内部的にキャッシュインテンシブな処理を実現し、大量の開発プロジェクトを抱えていたり、大規模な継続的インテグレーションなどによって集中的にソースコ
GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間 報告では、サービス障害はGitHub社内のChatOpsシステムも巻き込んで初期対応に時間がかかってしまったこと、一時的な停電がRedisクラスタの障害を引き起こしたため、その究明と復旧が作業の主な部分だったことなどが説明されています。 報告の要点をまとめました。 内部のChatOpsシステムも障害に GitHubのサービス障害は、すでに報告されているように、自社データセンターにおける一時的な停電が最初の原因でした。 At 00:23am UTC on Thursday, January 28th, 2016 (4:23pm PST, Wednesday, January 27th) our primary data center experi
この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの? と思ったことはありませんか? 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く