サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
qiita.com/kyanny
$ gem which benchmark/ips /Users/kyanny/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/benchmark-ips-2.6.1/lib/benchmark/ips.rb $ be rails c Loading development environment (Rails 4.1.14) [1] pry(main)> require 'benchmark/ips' LoadError: cannot load such file -- benchmark/ips from /Users/kyanny/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/activesupport-4.1.14/lib/active_support/dependencies.rb:2
元ネタは Quipper の CTO (@tomo) が社内向けにシェアした zsh コマンド。別途 hub をインストールしてください。 https://hub.github.com/ # 使い方: # 1. 以下を .bashrc などにコピペして保存 -> 端末・シェル再起動または .bashrc 再読み込み # 2. Git リポジトリを clone したディレクトリに移動 -> Pull Request と紐付いているブランチを checkout # 3. $ ciopen [COMMIT] # $ ciopen head # $ ciopen head^ # $ ciopen head~2 ciopen() { commit=$1 result=$(hub ci-status -v $commit) if [ $? == 3 ]; then echo $result else
コミットの順番を入れ替えたいことがある(バグを修正したあとテストを書いたが、 CI 上で再現テストのコミットを一度 fail させてから修正のコミットで pass することを示したい、など) rebase -i でコミットの順番を入れ替えられるが、日付はオリジナルのコミット順のままなので、 git log の並び順が時系列にならなくてちょっと気持ち悪い。そういうときに、見た目と時系列を合わせる方法。 git commit --date オプションを使う。 --date=now と指定できて便利。 https://git-scm.com/docs/git-commit reflog から cherry-pick -> 日付を変更して再び commit する場合 $ git cherry-pick c3fe8ff [fix/XXXX 47e1d1d] Lorem ipsum dolor sit
https://github.com/:user/:repo/compare/:start...:end という URL を叩くと Compare View という画面になり、 :start から :end までのコミット :start から :end までの diff :start から :end までのコミットに対してつけられたコメント が一覧できる。 :start, :end には commit の sha1 や master, HEAD などの名前、そしてタグが使える。 例: https://github.com/fastladder/fastladder/compare/2.3.5...master master は不定なので、特定のコミット間の差を見たい場合は commit sha に置き換えたほうが安全。 git rev-parse master などとすると commit
Faker を i18n locale :ja で使うときは Faker::Config.locale を :en にセットしなおすべしRuby Faker は各種 locale に対応しているので Rails アプリなどで default locale を :ja にセットすると人名のダミーデータが日本語化されたりして便利なのだけど Faker::Internet.email がぶっ壊れてテストデータの email バリデーションエラーが出まくってハマった。 default locale :en で使う場合 問題無し。普通はこういう状態を期待する。 require 'i18n' I18n.locale # => :en require 'faker' Faker::Config.locale # => :en Faker::Internet.email # => "sanford@jac
前提: Emacs で flycheck を導入しており、 coffeelint による CoffeeScript のシンタックスチェックを設定済みであること。 coffeelint は -f オプションで独自の設定ファイルを渡し、特定の設定を上書きできる(例: max_line_length のチェックは無視したい、とか) coffeelint --makeconfig で標準出力にデフォルトの設定を吐き出してくれるのでファイルに保存して必要な部分だけ編集すると便利。 $ coffeelint --makeconfig > .coffeelint.json $ coffeelint -f .coffeelint.json foo.coffee flycheck-coffeelintrc という変数に、 coffeelint -f に渡されるファイル名を指定できる。デフォルトで .coff
gemspec や Gemfile で gem のバージョン番号を指定するときに '~> 1.2' のように書ける (pessimistic version operator とかいうものらしい) 簡潔に書けて便利な反面、簡潔すぎて「'~> 1.2' って上限いくつだよ」といつもわからなくなるのでわかりやすい ['>= 1.2', '< 2'] のような表記に展開する方法を調べた。 Gem::Version#bump で Semantic versioning を意識した「次のバージョン番号」が得られるので、 version = "1.2" "['>= #{version}', '< #{Gem::Version.create(version).bump}']"
require "rspec/core/rake_task" RSpec::Core::RakeTask.new("spec") task :default => :spec
この middleware ちゃんと動いてるか確認したい、とか、この middleware とこの middleware を同時に使うとなんかヘッダがおかしいけどどうなってるの!とか、そういうののデバッグ法。 単にログ吐く middleware を stack の途中に積めばよい。 @app.call の前後でそれぞれロギングできる。 class M def initialize(app) @app = app end def call(env) warn '='*80 env.each do |k,v| warn "#{k}=#{v}" end warn '='*80 triplet = @app.call(env) warn triplet.inspect triplet end end config.middleware.insert_before Rack::ETag, M con
Rake のタスクを消す (プライベートな gem のうっかり rake release を防ぐ) のようにすると rake release による事故の心配が無くなるので安心だけど、 Git の tag を打つところだけは便利なので使いたい。 自前でそういうタスクを書くこともできるけど、せっかくなので Bundler の提供している機能を再利用してみる。 require "bundler/gem_tasks" require "bundler/gem_helper" t = Bundler::GemHelper.new desc "Create tag #{t.send(:version_tag)}" task :tag do t.send(:tag_version) { t.send(:git_push) } unless t.send(:already_tagged?) end こう
require "bundler/gem_tasks" Rake::Task[:release].clear $ rake -T rake build # Build rack-castanet-0.0.4.gem into the pkg directory. rake install # Build and install rack-castanet-0.0.4.gem into system gems. # rake release は消えてる
以下の nippo.rb をダウンロードしパスの通ったディレクトリに配置する GitHub のリポジトリを clone してきた作業ディレクトリで $ nippo.rb と実行する その日のコミットログメッセージが GitHub へのリンクつきで表示される 日報がわりにコピペすると便利です(サボってると一目瞭然なので真面目に仕事しようという気になります) #!/usr/bin/env ruby remote = `git remote -v | grep origin | awk '{print $2}'`.split("\n").first.chomp.sub(/.*:(.*)/, '\1').sub(/\.git/, '') puts "### #{remote} ###" puts "" `git log --after=yesterday --author='Kensuke Nag
すでにマージ済みのブランチをまとめて削除するには以下のようにする (master ブランチを checkout していると仮定する) $ git branch --merged | grep -v '*' | xargs -I % git branch -d % Deleted branch foo (was ce1b0d5). Deleted branch bar (was 7623b2b). Deleted branch baz (was d4c396d).
git 助けて 間違ってaddしてしまったのを取り消して前のインデックスの状態を手に入れたい — トデス子 (@todesking) October 5, 2012 私がやりたいのはですね、 git add a; git add b; した状態からgit add a;した状態に戻したい — トデス子 (@todesking) October 5, 2012 例えが悪かった、git add a; edit a; git add a;した状態から二度目のgit add aの影響を巻き戻したい — トデス子 (@todesking) October 5, 2012 それ git reset --patch でできるよ。 git reset (--patch | -p) [<commit>] [--] [<paths>...] Interactively select hunks in the d
hub(1) を使うと簡単にできる。 追記1: コメント欄より。 Issue を Pull Request にすると label が外れる(Pull Request には label がつけられないので) Asssign 状態は変化しない 追記2: この機能は hub コマンドの master ブランチでは削除されている(おそらく次期リリースで無くなる) GitHub も将来 API (v4) からこの機能を無くすつもりのようだ。参考 例: pullreq ブランチから master ブランチに対して Pull Request を送りたいが、その際に既存の Issue#123 にコードを添付したい $ git checkout -b pullreq $ commit; commit; commit; $ hub pull-request -i 123 https://github.com/
このエントリーはGitアドベントカレンダーの十日目です。九日目は KitaitiMakoto さんの「ファイルの変更を監視するプログラムと仲良くする」でした。ローカルリポジトリとフックスクリプトの組み合わせはあまり見かけませんが、いろいろ応用できそうですね。 SSH Protocol URL さて、 Git でリモートリポジトリを扱うとき、もっとも馴染み深いのは以下のような URL でしょう。
「特定の環境変数を上書きして複数の外部コマンドを実行する」というコードを脳に優しく書けるようにするために、ブロック付きメソッドを活用して Lisp の with-* マクロのような構文をつくる。 with_env - 環境変数を上書きしてブロックを実行する 「特定の環境変数を上書きして複数の外部コマンドを実行する」用のユーティリティメソッド。ブロックの中でだけ環境変数を変更できる。 def with_env(env, &block) original_env = ENV.to_hash ENV.update(env) yield if block_given? ensure ENV.replace(original_env) end env = {'GEM_HOME' => nil, 'BUNDLE_GEMFILE' => nil} with_env(env) do system('bun
Webistrano はプロジェクト間でレシピを共有できる。レシピの再利用を促進する設計になっているので、「単機能のレシピをたくさんつくって組み合わせる」という使い方をしたい。 しかしロールが絡むと話がややこしくなる。ややこしくなる具体的な例があったほうが後述するテクニックの利点を説明しやすいので、まず「単機能のレシピを再利用しづらくなる例」を示す。 仕様 電子書籍の執筆・販売プラットフォームを提供するウェブサイトがあり、 :app, :web, :db の他に :pdf, :drm というロールが存在する、としよう (注: 実在のウェブサイトとは関係ありません、あくまで例です) :pdf ロールのサーバはダウンロード販売のマスターデータとなる PDF ファイルを非同期で作成する。 :drm ロールのサーバは購入者のメールアドレスを埋め込んだ PDF ファイルを非同期で作成する。いずれのロ
このページを最初にブックマークしてみませんか?
『@kyannyのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く