サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
ご存知のかたも多いかと思いますが、GitHub で管理しているコードについて、コードの "ある部分" を示したいときに貼り付ける URL には注意が必要です。 ソースコードの参照リンクを貼るときに気をつけたいこと たとえばこんなリンクを貼り付けた場合 https://github.com/tmd45/tmd45.github.io/blob/source/Gemfile#L16 これは source ブランチの最新の Gemfile ファイルの 16 行目を参照します。 いま（記事執筆時点で）このリンクを開くと gem 'slim', '~> 3.0.2' が書かれている行を参照してることがわかりますが、この先 source ブランチのコードに変更があった場合「最新の」コードでは別のものを指してしまう可能性があります。 なので "ある行" を参照する場合にはコミットハッシュを特定した UR
AI & MLLearn about artificial intelligence andmachine learning across theGitHub ecosystem and the wider industry. GenerativeAILearn how tobuild with generativeAI.GitHub CopilotChange how you work withGitHub Copilot. LLMsEverything developers need to know about LLMs.Machine learningMachine learning tips, tricks, and best practices. HowAI code generation worksExplore the capabilities and be
ウォンテッドリー株式会社コーポレートチームの大谷です。 カスタマサービスチーム仲野さんが書いた ”GitHubで実現する、カスタマーサービスとエンジニアの非同期コミュニケーションのすすめ” に良い反響がありましたので、コーポレートチームでも行っている活動をお話したいと思います。Wantedlyのコーポレートチームは”働くメンバーの生産性を上げる”ことをミッションとしています。インフラチームが開発チーム全体の生産性をあげることをミッションとしているように、コーポレートチームは会社としてやらないといけないことを担保しつつ、メンバーの負担を増やさないという観点で、会社全体の生産性を上げることを目指しています。 他社で契約書や規程の文書管理としてのGitを使う話はいくつか事例があるのですが、今回Wantedlyで行ったのはGitHubを使ったコミュニケーションを使って生産性を上げた話になります。
チーフエンジニアの @hsbt です。 今日はペパボでの日報と日報支援ツール furik について紹介します。 日報とは 日報とは、企業をはじめとする組織で様々な用途に使用されます。日々の作業の結果や記録として使われたり、チームのメンバーが考えていることや、その日その日の気分を知ることでコミュニケーションを取るための材料として使われたりします。 上記に述べた日報の使われ方は、主に自分以外の他者が参照するための用途ですが、@hsbt は日報を書きながら、何が原因で質の低い仕事をしたのか、明日良い結果を出すにはどうすればいいのか、というその日の仕事の質のふりかえりを行っています。GitHub と日報 ペパボでは、GitHub とGitHub Enterprise を使用しています。開発者は pull request によるコードのアウトプットだけではなく、issue を用いた設計の議論、p
僕が1日に1回ぐらいの頻度で見ているページの中の1つにGitHub のTrending repositories のページがあります．このページには言語ごとに日毎・週毎・月毎の単位でGitHub 上で人気のリポジトリがランキング形式で表示されます． 話題になっているライブラリやソフトウェアの一次ソースとして便利なのですが，微妙にアクセスが悪い位置にあり，言語ごとにしか見られません．また，ランキングには常に人気な「常連」リポジトリが多々いるので，新しく話題になっているリポジトリはその中に埋もれがちになってしまいます． そこで，今回はこれらの問題を解決すべく，GitHub のトレンドクライアントTrendy を Electron ベースでつくりました．Trendy - Menubar App to Keep You in theTrendTrendy はGitHub のトレンド
検索しているとなにかとNetflixのgithubリポジトリがヒットするので、全部（2015/07/18現在分）調査してみた。githubAPIで https://github.com/Netflix のリストを全部取得して、名前・概要・URL・最終更新日時 (なんの更新だ?) を抽出。AWS用のプロダクトが多かったのでまずそれらと、その他という分類にした。その他はほとんどがJavaライブラリ・システムだが、一部WebアプリケーションやPythonライブラリがある。 日本語での説明はReadmeやWikiを見て書いているが、理解が正しくないかもしれない。AWS用aws-autoscaling Tools and Documentation about using Auto Scaling URL: https://github.com/Netflix/aws-autoscalin
GitHubのプロフィールページがパッとしない https://github.com/naoyashiga 「Repositories contributed to」がスカスカGitHubの自分のプロフィールページを見るたびに、なんかパッとしないなあと思っていた。それは「Repositories contributed to」のところがスカスカだったからだ。Contributeをしてプロフィールページを豪華にしたいと思った。 スターが多いリポジトリは難しい できればスターが多いリポジトリにContributeしたい。自分はSwiftを使うことが多く、例えばAlamofireのような人気リポジトリに、プログラミング能力が低い自分がContributeするのは難しい。実際にリポジトリを見ても、何が問題なのか全くわからなかった笑 ショボいPull Requestを送る 「Repositorie
Container RegistryOracle Cloud Infrastructure Container Registry is an open standards-based,Oracle-managedDocker registry service for securely storing and sharing container images. Engineers can easily push and pullDocker images with the familiarDocker CommandLine Interface (CLI) andAPI. To support container lifecycles, Registry works with Container Engine forKubernetes, Identity and Acces
要約 Chefみたいなスキーマ管理ツール（Ridgepole）を使うと、GitHubを使ったワークフローでスキーマを管理できる（と思います、たぶん）RailsのMigrationsについての問題提起 Migrationsは便利な仕組みですがベストではないと常々思っていました。 具体的には、特定のマイグレーションを保留にしにくいとか、複数人で作業するとコンフリクトすることがあるとか。 大きめのRailsプロジェクトだと特別なワークフローを用意して解決しているんですかね…声出して行こうぜ！とか。 Chef的スキーマ管理ツール: Ridgepole https://github.com/winebarrel/ridgepole （デモ） 以前からそのようなそのような問題意識があって、たぶん Chef的な冪等性保証する（操作ではなく定義を書くたぐいの）ツールがあれば解決できそう、でも実際作るの大
こんにちは，yaottiです． 前回はQiitaやKobitoを作る開発チームの文化について書きましたが，今回は具体的にどういうツールを使いながら開発しているのか，また開発の雰囲気などを紹介します． QiitaやKobito開発で利用しているツール，サービス一覧 Trello: 開発以外のタスクや仮説の管理Pivotal Tracker: 開発ストーリー管理GitHub: ソースコードのホスティング，レビュー，ディスカッションCircle CI: CI環境Sentry: エラーの補足&通知New Relic: パフォーマンス改善用の測定Amazon Web Services: インフラ(EC2, RDS, ElastiCache)コミュニケーションSlack: チャットQiita Team (& Kobito): テキスト共有&ディスカッションその他Mixpanel: イベント計測Goog
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「GitWorkflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
