akishin999のブックマーク - はてなブックマーク

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる使い方について詳しくはこの記事の下のほうに書いた要求トークンを利用した認証・認可機構を持つ API を作りたいクライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークンヘッダでトークンを送る API あるよね、ああいうやつ疑問 Authorization: Bearer ヘッダは OA

akishin999 2019/02/15

RFC

リンク

Phoenix のコントローラで render/3 を呼んでからのレンダリング処理の流れを追う - Qiita

Phoenix のコントローラでは render(conn, "index.html", foos: foos) のように render/3 を呼ぶことでビューをレンダリングすることができる。もろもろの事情があって、この処理の途中にフックして引数の値を書き換えてみたいと思った。というわけで、コントローラで render/3 を呼んだら何がどうなって HTML がレンダリングされるのか追いかけてみた。ネタバレ：この記事を読んで得られることこの記事では、生成されたコードで使われているもののどこで定義されているか分からない関数から始まって、マクロで生成された関数定義に辿り着くまでを順を追って書いていきます。マクロを駆使した Elixir のコードにおいて、関数がどこで定義されているかを探す方法や考え方のヒントを得られる……はずです。分かりづらい箇所があればお気軽にコメントをください。準備

akishin999 2015/09/01

elixir

リンク

Elixir の DSL がどう実装されているか、マクロの展開順を追ってみた（Plug.Builder を例に） - Qiita

use Plug.Builder したモジュール内で plug :atom, [optional args] と書くことで、モジュールに他の plug を組み込むことができる。マクロを駆使して実装された plug の中身がどうなっているのか、 Plug.Builder を再実装しながら追ってみることにした。マクロの参考資料 Elixir Docs - Kernel Getting Started - Mac ros MyPlugBuilder の概要 Plug.Builder を丸ごと再実装するのは骨が折れるので、 plug マクロだけを提供するように単純化したモジュール MyPlugBuilder を作ることにする。 MyPlugBuilder は以下のように使う：

akishin999 2015/06/13

elixir

リンク

English - 英語では「0オリジン」「1オリジン」とは（あまり）言わない - Qiita [キータ]

配列の添字が0または1から始まることを日本では「0オリジン」「1オリジン」と言うが、どうやらこれは和製英語らしい。一般的に英語ではそれぞれ zero-based, one-based と言う。「添字が0から始まるインデックス方式」は "zero-based indexing"、「1から始まる添字を使った文字列アクセス」は "one-based string access" となる。追記：zero-origin も使われているようだ。 zero-based index の検索結果、約170万件 zero-origin index の検索結果、約3万件 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read ba

akishin999 2013/09/05

英語

リンク

めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita

あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは：ファイルへの変更を1コミットずつ適用・コンフリクト解決することができるそれぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できるの3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。概要マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作

akishin999 2013/08/24

git

リンク

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