GitHub Issueの検索でできること - Qiita
GitHubのIssue検索でできること チームメンバのタスク消化量をIssueの検索だけで可視化できないかと思ってIssueの検索についてざっくり調べました。 ざっくりとまとめておきます。 基本 スペース区切りで複数条件を指定可。 AND条件。 指定した条件は基本的にはその文字列の全文検索 「:」で区切られた各種フィルターを指定できる in 文字列がどのフィールドに含まれているかを指定する。 指定できるのはtitle, body, comment。カンマ区切りで複数指定可 in:title in:title,body in:comment is:public / is:private リポジトリ横断で検索する場合にpublicのみ、privateのみを指定できる 当然、privateは自分がアクセス権を持っているリポジトリのみ is:public is:private author Is
Androidな開発をするときにチェックしていること - Qiita
二次情報的な記事ですが、個人的に開発するときに非常にお世話になっている、習慣的に行っていることをまとめておき、Androidのコミュニティはどんな活発な開発が行われているかを、別言語や別分野から始める人の導入に役立てばいいなと思っています。 ※個人のアカウントやブログのリンクも出てくるため、掲載を取りやめてほしい方はご連絡ください。 チェックしている人物 @JakeWhartonさん 神です。これ以上言うことはありません。 Github : https://github.com/JakeWharton Twitter : https://twitter.com/JakeWharton web : http://jakewharton.com/ @wasabeefさん 渋谷に限らず、日本、世界で見てもAndroidで有名なのはやはりwasabeefさんだと思っています Github : ht
SlackのAndroidアプリで使われているライブラリ - Qiita
SlackのAndroidアプリで使われているライブラリを調べてみた。Versionは2.1.1。 Square / Jake神 関連 Dagger, Butter Knife, Otto, RxAndroid, Timber, Picasso, OkHttp, Okio ここらへんは定番ですね。 その他定番の Guava, Joda-Time, Gson Chris Banesさんの Chris BanesさんはGoogleの人です。 FloatLabelLayout EditTextのhintが文字入力時にぴょんとアニメーションして上に表示される https://plus.google.com/+ChrisBanes/posts/5Ejaq51UWGo https://gist.github.com/chrisbanes/11247418 PhotoView https://githu
Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
githubの運用戦術 - Qiita
前提 過去のチームといまのチームでどうやっているかの話 master以外なら force push 可能なことが条件 コミットコメント 一行で概要 WhyやHowを書かせる。 WhereやWhatはいらん、diffを見ればわかる。 (必要なら)詳細 なんでここにこういうことをした？ という細かい説明。 時間に追われてdirty hackをせざるを得なかったのならここにも書いて欲しい。 書かずに変なことしたら俺がハリセン issueだのメモだのへのリンクでもいい 諸注意 日本語OK 英語オンリーにするとみんな面倒臭がって little change for debug とか平然と入れる 詳しく書かせたいし読むのに苦労したくないので日本語を許す コミットのタイミングと粒度 粒度はできるだけ細かく。 １コミット単位でレビュワーがお前何がしたかった？をみるため。 レビュー中にレビューが入った部分は
GitHubエンジニアによる「リファクタリングにおける冒険とは」の翻訳 - Qiita
GitHubのエンジニア Ben Lavender によるYAPC2015のセッション「Adventures in Refactoring」のスライドが公開されたので、翻訳を試みました。 注）私はセッションには行っていないため、いくつかわからない箇所がありますので、編集リクエストを送って頂けると幸いです（同時通訳の内容を公開してくれたら、もう少しわかるのですが・・・）。 ちなみに英語ですが動画も公開されています。 Adventures in Refactoring / Ben Lavender リファクタリングとは？ （できれば）振る舞いを変えずにコードを変えること 第1部 リファクタリングする理由 リファクタリングする理由として悪いもの 一貫性を上げる
DNSimpleをTerraform+GitHub+CircleCIで管理する - Qiita
処理の流れとしては次のような感じ。 GitHubにpushされるとCircleCI上でterraform planが走る そのPRがmasterにマージされるとterraform applyが走る Terraformのテンプレート まずはdnsimpleプロバイダについて記述する。 variable "dnsimple_email" {} # 環境変数TF_VAR_dnsimple_email variable "dnsimple_token" {} # 環境変数TF_VAR_dnsimple_token provider "dnsimple" { token = "${var.dnsimple_token}" email = "${var.dnsimple_email}" } DNSimpleに接続する際のtokenとemailをTerraformに渡す必要があるのだけれど、それらはリポ
Githubクローン界の新星 GitBucket を Ubuntu 12.04 で動かす - Qiita
2014/05/01 : 公開当初の情報から非常に古くなっているため、一部修正しました。 @takezoeさんが作っているGitHubクローンであるGitBucketを動かしてみたのでそのメモ。Ubuntu 12.04 LTS 64bit でのお話。 GitBucketは、最低限のレポジトリ管理は可能ですが、いくつかの大事な機能はまだ作成中とのこと。（例えばpull request） （執筆当初の古い情報です。現在はバッチリプルリクできます。） Scalaで書かれているというだけでも十分心くすぐるアプリになってます。(Scalatra + Slick + twirl) 最近画面のあるWebアプリに触れてなかったので、勉強の題材としてもいいかなと思って触ってみてます。 (RESTでJSONしか返してくれないインフラ構築Webアプリ？には毎日触れてたけど・・・) GitBucketを動かすのは
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
GitHub のリポジトリに置いた tweet.yml の内容をランダムにツイートする Heroku アプリケーションを作った - Qiita
GitHub のリポジトリに置いた tweet.yml の内容をランダムにツイートする Heroku アプリケーションを作ったRubyGitHubHerokuOctokit 概要 GitHub のリポジトリに置いた tweet.yml の内容をランダムにツイートする Heroku アプリケーションを作りました random_tweet_from_github_bot 目的 ブログの記事、 Qiita の記事、プロダクト、誰かの名言など定期的にツイートしたいものがあるとします。 そういったものをランダムにツイートするボットを Heroku の無料枠で手軽に動かすアプリケーションです。 サンプル ツイート内容を保存したリポジトリ tbpgr/qiita_favorite_articles ツイート用アカウント: tbpgr_bot 補足 tweet.yml を保存するリポジトリに対する定期更新
Github Pagesでブログ構築ができる静的サイトジェネレーター総まとめ - Qiita
概要 Github Pagesでブログ構築ができる静的サイトジェネレーターの総まとめです。 もともと使っていたOctpressからの移行で、HugoとHexoで迷い、デプロイのしやすさや、Node.jsで完結できることなどからHexoに決めました。なので、Hexoの情報は多めになっています。 Assembleも、Grunt・Yeomanでがりがり動かすことができそうで、いつか試してみたいです。 リプレース要件 以下を満たすもの。 Markdownでブログ記事を記述できる(Githubとかで管理したいから) Octopressから移行が可能(最悪手動でもOK) デザインがモダンであること(スマートフォン対応していること) イケてること(色んな意味で) Jekyll｜Rails｜Github Star 18848 メリット Github Star数No1と人気。 日本語の記事も多い なんでもで
Jenkins+Dockerで開発中のWebアプリを手軽に公開する - Qiita
Jenkinsユーザ・カンファレンス2015で @nobuoka さんが発表されていた、 開発中の機能やUI/UXの検証環境を手軽に動かしたい をJenkins+Dockerでやってみました http://www.slideshare.net/YuNobuoka/docker-43489941 概要 http://${branchname}.feature.example.com で各コンテナにアクセスできるようにする DockerホストはJenkinsのスレーブノードとして登録することでJenkinsからDockerを操作できるようにする 各コンテナは3000番ポート(webrickのデフォルトポート)を公開する webrickを起動するのみでsshdなど他のサービスは基本的には立ち上げない サブドメインと各コンテナ(の公開ポート)の解決にはhttpdを利用する 元の資料ではPlackを
最近の Web 開発者が使ってるらしいサービス - Qiita
MDN のページのヘッダ部分に、開発者が使っているサービスについてのアンケートがあったので回答してみた。 内容は、開発の上で使える様々なサービスについてだったんだけど、その選択肢が知らないのもいくつかあっておもしろかった。 MDN のアンケートの選択肢にあがるってことは、今こういうサービスがメジャーなんだなーと思ったので貼っておく。 (ただし、 Code Hosting -> Github や IaaS -> AWS みたいな分かりきってるのは省く) ちなみにサーベイは以下。 load-test Loader.io LoadImpact.com Loadstorm.com browsertest SauceLabs BrowserStack W3C validators CrossBrowserTesting Browsera security Nessus WebInspect ? Ne
GitHub Issueはテンプレート化で、綺麗に書かせる！ - Qiita
まず、クリックしてみてください Issue作成はこちら GitHubのIssueは、URLにparamsを渡すことで、デフォルトのvalueが入れられます。 ※paramsの渡し方は、/issues/new?title=test&body=contentのようにします。 バグ報告はこちらとかアイディア投稿などのリンクをREADMEなどに置き、みんなそれに従ってIssueを作成してもらいましょう。 指定できるparams 指定できるパラメーターは以下です。 params一覧 title body assignee labels milestone ※ラベル、マイルストーンはcontributorsのみ使用可能 文字列のエスケープ URLに入力するので、改行コードなどをエスケープする必要があります。 文字 エスケープ後
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita
【2015/07/16 追記】優れた dotfiles を設計する - TELLME.TOKYO この記事では書かなかった全体のロジックについて書きました Dotfiles Driven Development dotfiles とは Unix 系 OS で俗に言う設定ファイルのことです。.vimrc や .zshrc など、設定ファイルの多くは隠しファイルとしてファイル名の頭にドットがつくことからそう呼ばれています。 ほとんどのエンジニアは CLI 環境での開発は避けては通れないものに思います。CLI 環境は「黒い画面」として敬遠されがちで、CLI になると格段に作業効率がダウンする人も少なく無いです。その作業を効率化するキーとなるのは、設定ファイルの習熟度にあると思います。GUI 開発環境と比べてこちらはテキストベースでカスタマイズできるため、究極まで自分好みに合わせることが可能です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lodge/lodge: イントラネット内で誰でも構築できる情報共有サービス
GitHub - increments/qiita-coat: The UI components for Qiita.
gitのuser.nameとuser.emailを会社/個人で自動的に切り替える方法 - Qiita
gitでパスワードを毎回聞かれる問題の解決方法 - Qiita
