git commit --fixup で fixup する対象を peco/fzf で選べるスクリプト書いた - Qiita
git commit --fixup が何かについてはgit commit --fixup とは何か - 詩と創作・思索のひろばを読んでもらうとして、 fixup を適用したいコミットをいちいち git log で調べるのが面倒なのでインタラクティブに選べるようにした。 以下のスクリプトをパスの通ったディレクトリに置くと git fixup が使えるようになる。適当な変更を git add して git fixup を実行すると、その変更を fixup として適用したいコミットを peco や fzf で選べる。 #!/bin/bash FILTER=${FILTER:-peco} MAX_LOG_COUNT=${MAX_LOG_COUNT:-30} if git diff --cached --quiet; then commits="No staged changes. Use git
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
Elixir の DSL がどう実装されているか、マクロの展開順を追ってみた（Plug.Builder を例に） - Qiita
use Plug.Builder したモジュール内で plug :atom, [optional args] と書くことで、モジュールに他の plug を組み込むことができる。 マクロを駆使して実装された plug の中身がどうなっているのか、 Plug.Builder を再実装しながら追ってみることにした。 マクロの参考資料 Elixir Docs - Kernel Getting Started - Macros MyPlugBuilder の概要 Plug.Builder を丸ごと再実装するのは骨が折れるので、 plug マクロだけを提供するように単純化したモジュール MyPlugBuilder を作ることにする。 MyPlugBuilder は以下のように使う：
Swift のクロージャが面白い - Qiita
let sorted = sort(anArray, { (s1: String, s2: String) -> Bool in return s1 < s2 })
Zsh 入門者のための超速設定ガイド - Qiita
はじめに このガイドでは、はじめて Zsh を使う人や Zsh の便利な使い方を知らない人に向けて、いくつかの便利な設定と操作方法を紹介します。また、 Zsh についての疑問を素早く解決できるよう、マニュアルの調べ方や他のドキュメントへのリンクも盛り込んであります。 このガイドでカバーしきれていない設定や分かりやすいドキュメントをご存知でしたら、ぜひ編集リクエストやコメントでお知らせください。 設定ファイル ここでは主に普段のキー入力数を大幅に減らせるような設定を紹介します。 .zshrc ~/.zshrc は Zsh のインタラクティブシェル（ユーザーがコマンドを入力する画面）が起動した際に読み込まれる設定ファイルです。 Zsh スクリプトを実行したり、 zsh -c 'command...' でコマンドを実行したりしたときには読み込まれません。このファイルには主に Zsh の操作に関す
めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
コンフリクトした xib ファイルを上手にマージする - Qiita
本稿では、 Git でブランチをマージした際にコンフリクトした xib ファイルの衝突解決手順を解説する。 追記： Xcode 5 から導入された新しい xib フォーマットではコンフリクトが起こりにくくなっている。また、コンフリクトした場合に手作業で xib ファイルを編集することも、以前のフォーマットと比べれば容易になっている。本稿では以前のフォーマットを使っていることを前提に話を進める。 ステップ0：コンフリクトの解決をあきらめる Xib ファイルをテキストエディタで編集してコンフリクトを解決しようなどと考えてはいけない（変更がごく小規模な場合を除く）。コンフリクトした xib ファイルは捨てて素直に作り直すのがよい。ただし、記憶を頼りに変更を再現する必要はない。 Xib ファイルの要素は コピー&ペーストできる ので、変更点の移植は比較的簡単にできる。 ステップ1：ベースにする x
Objective-C のコードレビューチェックリスト - Qiita
はじめに 本稿は Juri Pakaste 氏による Cocoa review checklist (commit fff5703)の翻訳です。他人の Objective-C のコードをレビューするとき注意する点、また普段のコーディングで心がけるべき点についてまとめられています。 なお、原文のタイトルは Cocoa review checklist となっていますが、内容が Cocoa に限らない範囲のトピックをカバーしているため、本稿のタイトルは「Objective-C の〜」としました。 誤訳の指摘や例の補足を歓迎します。 コードの見た目とコード以外の問題 不要な #import や @class 宣言を消す #import をソートする .m ファイルの中では、対応する .h ファイルの #import を最初の行に書く。空行をはさんで、ソートされた他の #import を書く。 X
Objective-C のプロパティ属性のガイドライン - Qiita
Objective-C のプロパティの属性を指定するとき従うべきガイドラインをまとめた。 できる限り nonatomic を指定する atomic にしてもパフォーマンスが悪化するだけでほとんどメリットがない（参考：StackOverflow - Atomic vs nonatomic properties）。 nonatomic と atomic の使い分けの指針は次のとおり： 参照型: メモリアドレスのみの書き込みなので、常にnonatomicでよい プリミティブ型: int, BOOL等ワンステップでの書き込みが可能: 常にnonatomicでよい 単一のスレッドからしかアクセスされない: 設計に気をつけつつnonatomic推奨 複数のスレッドからのアクセスがあり、long,構造体などサイズの大きい値: atomic推奨 (thx to @takasek) 複数のスレッドから同時に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
weakify/strongify マクロを使うと weak self パターンが簡単に書ける - Qiita