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
&str を String に変換する5つの方法 - Qiita
&str を String に変換する主なやりかたを紹介する。性能の差は皆無に近いのでどれを使ってもいい。ただし "str".into() は使いどころがやや異なる。 "str".to_string() std::string::ToString トレイトに従って str が間接的に1実装するメソッド。他の言語にも同名もしくは似た名前のメソッドがあるため、多くの人がまず使うのはこれであろうと思われる。このメソッドは String::from() にインライン化される。2 "str".to_owned() std::borrowed::ToOwned トレイト3に従って str が実装するメソッド。 "str".to_string() より1文字短いのが利点といえば利点。 String::from("str") std::convert::From<T> トレイトに従って String が実
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
ベータ版の iOS について WWDC の資料などを元に記事を書くのは NDA 違反か調べてみた - Qiita
（この記事は WWDC 2014 の直後に書かれました。内容は2014年時点のものです。本文中の「Swift」や「iOS 8」は当時まだベータ版だったソフトウェアを指します。） TL;DR WWDC で発表された情報と、一般公開されている Apple のドキュメントに含まれる情報は NDA に抵触しない。よってそれらの範囲で Swift や iOS 8 に関する情報はセーフ。しかしスクリーンショットの公開は不可。 この記事の内容に法的な保証はないので、不安なら Mac (or iOS) Developer Program License Agreement の条項10.1 Information Deemed Apple Confidential を参照のうえ、弁護士に相談すること。 関連リンク：自分の Apple Developer アカウントで同意した契約書の一覧ページ（要ログイン）
Objective-C のプロパティ属性のガイドライン - Qiita
Objective-C のプロパティの属性を指定するとき従うべきガイドラインをまとめた。 できる限り nonatomic を指定する atomic にしてもパフォーマンスが悪化するだけでほとんどメリットがない（参考：StackOverflow - Atomic vs nonatomic properties）。 nonatomic と atomic の使い分けの指針は次のとおり： 参照型: メモリアドレスのみの書き込みなので、常にnonatomicでよい プリミティブ型: int, BOOL等ワンステップでの書き込みが可能: 常にnonatomicでよい 単一のスレッドからしかアクセスされない: 設計に気をつけつつnonatomic推奨 複数のスレッドからのアクセスがあり、long,構造体などサイズの大きい値: atomic推奨 (thx to @takasek) 複数のスレッドから同時に
Zsh 入門者のための超速設定ガイド - Qiita
はじめに このガイドでは、はじめて Zsh を使う人や Zsh の便利な使い方を知らない人に向けて、いくつかの便利な設定と操作方法を紹介します。また、 Zsh についての疑問を素早く解決できるよう、マニュアルの調べ方や他のドキュメントへのリンクも盛り込んであります。 このガイドでカバーしきれていない設定や分かりやすいドキュメントをご存知でしたら、ぜひ編集リクエストやコメントでお知らせください。 設定ファイル ここでは主に普段のキー入力数を大幅に減らせるような設定を紹介します。 .zshrc ~/.zshrc は Zsh のインタラクティブシェル（ユーザーがコマンドを入力する画面）が起動した際に読み込まれる設定ファイルです。 Zsh スクリプトを実行したり、 zsh -c 'command...' でコマンドを実行したりしたときには読み込まれません。このファイルには主に Zsh の操作に関す
めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita
〔提案に対して〕いいと思う；問題ないと思う；〔コードレビュアーが、問題ないコードに対して〕レビュー終了；（コードの）承認
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
