lang: en | ja
September 15, 2014 GitHub is a fairly large production Ruby on Rails application. From a scale perspective, it serves hundreds of millions of requests per day. Until now, we’ve been running an outdated, heavily-modified, unsupported fork of Rails, which we called 2.3.github. This choice has bitten us in the form of gem incompatibility, having to manually backport security patches, missing out on c
座駆動LT大会で「戦闘力」というLTをしてきました。 座駆動LT大会とは、岡山にはRyouteiという素晴しいお店があり、そこの座スタジアムという部屋は非常にLTに適した場所です。 大都会岡山が誇る最強の懇親会会場「Ryoutei 座・スタジアム」でLT大会を開催します! というわけで、今回参加してきた時のスライドを紹介します。 戦闘力といえば、Vim戦闘力やEmacs戦闘力がありますが、GitHub戦闘力を適当に定義してみました。 スターの数がGitHub戦闘力と言われているのもみかけましたが、折角なのでいろいろ考えてみました。 実はオープンソースカンフェレンス2014広島のために制作しているものの中でGitHub APIを使用してつくっていたものがあり、そのノウハウで、そのついでに作成したのが今回のgithub_scouterです。 eiel/github_scouter · GitH
Webの仕様 ウェブの仕様といえば、W3CやWHATWG、IETFとかが思い浮かぶかもしれません。 これらの仕様が最近ではメーリングリストやIRCといった旧来のところだけではなく、GitHub上で議論されて策定が進められている事が増えています。(両方使ってるという話) この記事はそのような方法で進められてる仕様等についての紹介です。 * 自分自身はそこまで仕様に対して強い興味があるわけではないので、もっと詳しい方が正しくまとめて頂きたいです。。 最初にMove The Web Forward | Guide to getting involved with standards and browser developmentを見ておくといいかもしれません。 JavaScriptの仕様 この動きが多く見られるのがJavaScript(ECMAScriptやDOM APIを含む)周りの仕様につい
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース(OSS)を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
本題に入る前に言っておきます。私は、このトピックは重大であるし、Chef Software(以後Chef Incと表記)の一部の人たちにとっては、ことさら重要な意味があると思っています。「Chefはオープンソースではない」という問題に向き合う時が来たのです。いつからそうなったか正確には分かりませんが、この数年間でChefはオープンソースモデルから確実にシフトしてきています。 「でも、コードはGitHubに公開されていますよ」 確かに、文字通りの意味では、コードは自由に閲覧および改変できるようになっていますが、それだけではオープンソースの理念を満たしているとは言えません。なぜなら、オープンソースとは協力してソフトウェアを構築するコミュニティだからです。 「でも、私もパッチを提供したことがありますよ」 皆さんのコントリビューションには感謝しますが、この問題は大局的に捉える必要があります。元々「
GitHubでのリリース 前回、GitHubのRelease機能ついて書きましたが、これはリリースする側の自動化等についてでした。 git tagとGitHub ReleasesとCHANGELOG.mdの自動化について | Web Scratch 今度は、いわゆるライブラリユーザーだったりソフトウェアの利用者側から、 GitHubでリリースされるものをどう追っていくかについて書いていきたいと思います。 自分は、JSer.infoというJavaScriptの情報を見ていくサイトをやっているので、 JavaScriptのライブラリ等のリリース情報をどう追っていくかが中心になりますが、基本的にGitHubでリリースされてるならやり方は大きな違いはありません。 基本的には以下に色々書いていた内容のGitHubに関してをまとめた感じの記事となっています。 最近のJavaScript情報の探し方 ·
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
シェルスクリプトでGo言語のツールをクロスコンパイルしてGithubにリリースする [@motemen]()さんの“Wercker で Go のプロジェクトをクロスコンパイルし,GitHub にリリースする - 詩と創作・思索のひろば (Poetry, Writing and Contemplation)”を手元からやる. Werckerからリリース良いと思うけど,自分はリリースは手元で管理したい.その辺は毎回同じスクリプトでやってるのでまとめておく.なお,コードは全てtcnksm/go-distribution-scriptsにある. クロスコンパイル 基本はHashicorpのやり方を真似してる. まず,クロスコンパイルはmitchellh/goxを使う.goxは複数プラットフォームの並列コンパイルと出力先の設定の自由度が気に入ってずっと使ってる.何よりシンプルで良い.以下のようなスク
さきほどちょろっとアップデートが入ったpeco v0.2.2をリリースしました(Changeログ)。 で、ついでに昨日mattnさんがpecoについてツイートしてたので流れてしまう前にまとめておく mattn@mattn_jppeco、便利だしとても完成度高いんだけど、客観的に見るとあのプロジェクトがあれだけ流行ったのには理由があると思ってる。 2014/07/22 23:17:31 mattn@mattn_jpまず、Windows をネイティブサポートしたこと。少数ユーザの様で意外と多い。Windows だけ一部機能が欠けてるという事もない。 2014/07/22 23:22:00mattn@mattn_jp次に人気が出る中、手を止めなかったこと。停滞するとユーザも飽きる。 2014/07/22 23:25:44mattn@mattn_jpそして丁寧な README とアニメーションgi
GitHubには Releases という機能があります。 Release Your Software Creating Releases · GitHub Help GitHubのリリース機能を使う - Qiita 簡単に言えば、gitのtagやbranchに文章や添付ファイルを追加して公開出来るページです。 基本的にはgit tagと連携してるので、tagを付けてgit push --tagsをしていれば、自動的に追加されます。 メリットとしては以下のような事が行えます。 git tagにパーマネントリンクがつく(重要!) メッセージ(リリースノート等)が書ける 添付ファイル(zip)をアップロード出来る(配布するバイナリとか) RSS Feedsが自動的に生成される(TagとReleaseの2種類がある) ライブラリ等にtagがついてると利用しやすい。 git tagとGitHub
Today we’re announcing two changes to the TypeScript project. Introducing the New Compiler The first change we’re making to TypeScript is that we’ve been taking a good, hard look at the compiler performance we had with 1.0. We knew we could leverage the experience from building the original compiler over the last two years. This led to experimenting with a new, lighter-weight compiler core. The
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
それぞれのツールは以下を見ればどんなのかわかると思う。 peco(Simplistic interactive filtering tool)を作った話 : D-7 ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば (Poetry, Writing and Contemplation) GitHubのレポジトリURLを開くgh-openコマンド - unknownplace.org pecoとghqを組み合わせる例はpecoのREADMEにあるようにかなり強力で、ghqで管理しているリポジトリのディレクトリにcdしたりするのに便利。 こんな感じ。 $ cd $(ghq list -p | peco) また、typester先生作のgh-openは指定したディレクトリのリポジトリをGitHubで開けるので、同じように使えばpecoでGitHubの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く