アンダーバー付きの属性に関してtarget="_blank" 以外にもあるんだということを知る。
| 指定文字列 | 効能 |
|---|---|
_self |
今の閲覧画面で新しいページを読み込みます。target未指定の場合はコレに相当するので能動的に指定する機会は少ない。 |
_blank |
新しく閲覧画面を生成して読み込みます。タブが開くかウィンドウが開くかはブラウザ依存。 |
_parent |
今の閲覧階層の親でページを読み込みます。ない場合は_selfと同じ挙動 |
_top |
トップレベルの閲覧階層 (現在のコンテキストの祖先で "最上位" の閲覧コンテキストであり、親を持たない) に URL を読み込みます。親がいない場合 _self と同じ挙動 |
_parent や _top はフレーム分割してるときの要素なので、フレームがない場合は特に問題がない。
例えばカスタムヘッダでそこに認証用のキーを埋め込んでほしい場合などの書き方。OAuthとかBasic認証はあるのだけど、そういうポピュラーなものではなくオリジナルをやりたい場合の例。
securitySchemes にtypeを apikey にした情報を定義するsecure の項目を追加して指定する/user のエンドポイント に 認証用のコードとしてSECRETHEADERCODEを入れるようにヘッダに指定したい場合
以下の用に定義する
components: securitySchemes: API_SECRETCODE: type: apiKey description: ヘッダに乗せるシークレットキー in: header name: SECRETHEADERCODE
以下のように追加する
paths: /users: get: summary: "ユーザ情報の取得" tags: - "SelfSetting" security: - API_SECRETCODE: []
UI上でcurlを生成すると以下のように出来上がる
curl -X GET "http://example.com/users?id=1" -H "accept: application/json" -H "SECRETHEADERCODE: xxxx"
例えばBasic認証とコードをかけ合わせたい等の場合は以下のようにする
まずはBasic認証
components: securitySchemes: API_SECRETCODE: type: apiKey description: ヘッダに乗せるシークレットキー in: header name: SECRETHEADERCODE BasicNinsho: type: http description: Basic認証 scheme: basic
ANDにする場合は以下のように書く
paths: /users: get: summary: "プロフィール情報の取得。" tags: - "SelfSetting" security: - API_SECRETCODE: [] - BasicNinsho: []
そうすると以下のようにBasic認証情報がつく
curl -X GET "http://example.com/users?id=1" -H "accept: application/json" -H "SECRETHEADERCODE: xxxx" -H "Authorization: Basic bmFtZTpwYXNz"
どっかにあるのかな…と思ったらあった
MySQL :: MySQL 5.6 リファレンスマニュアル :: 9.3 予約語
たまに予約語というのは増える、のでそれをカラム名などでつかっているとそこらへんが結構大変なことになる。
すえなみチャンス忘年会2019 本編 - connpassにいってきたのメモです。
※資料スライドは見つけたら貼ります。
本日の資料「チームリーディング――フロントエンドコンポーネントの指針」です。
— nrs (@nrslib) 2019年12月7日
フロントエンドをネタにチームリーディングのお話をしています。https://t.co/b7gdc2HRjs
#すえなみチャンス忘年会
次の資料です！https://t.co/1FEFBDFtRP
— suzuki-hoge (@suzuki_hoge) 2019年12月7日
github はこちらです！https://t.co/r602xUmeNb
場違い感はんぱないw#すえなみチャンス忘年会
スライドはなさそう
テーマは「マイクロサービス」だったので、トピックごとに書いていきます。
以下のような意見が出た
下記のようなコメントが出た。
会場から意見が出た
OGPのタグの考え方問題。
ページごとにユニークになるようなURLとする。そのため、計測の用途や固有のユーザ別パラメータのようなものは省く。canonical のような感覚。
The canonical URL of your object that will be used as its permanent ID in the graph, e.g., "http://www.imdb.com/title/tt0117500/". - The Open Graph protocol
機械翻訳すると「永続的なIDとして使用されるURL」というような感じ。
ページの正規URL。これは、セッション変数、ユーザー識別パラメーター、カウンターといった装飾を含まないURLにしてください。各URLに対する「いいね！」や「シェア」は、このURLで集計されます。たとえば、モバイルドメインURLで、正規URLとしてデスクトップバージョンのURLを指定すると、複数のバージョン全体で、ページの「いいね！」や「シェア」を集計できます。 - ウェブ管理者 - シェア機能
これ同じにしないといいね！の数で同一のものと認識されない
要素として忘れがちなので雑記的な
緊急時には色々バタバタする
この中でも「社内周知」がかなり大味になる瞬間がある。
実際にトラブルシューティングをしているエンジニアはそれどころではなく、一刻も早く問題を特定して、止血作業をせねばならないという気持ちになっている。
そんなときに「周りへの状況報告」まで気が回るほうが稀である。
そのためトラブルシューティングをするときはワンセットで報告者を設けるシーンが多く、その場合に対応している人に適宜ヒアリングしつつ進捗報告を行う。
そのように「社内の通知の進捗報告をする人」を立てるまではやっている場合がおおいが、次に抜けるのが「定時連絡」かなと思っている。
一生懸命作業している現場、しかしながらそこに調査に進展がなかったりすると、進捗報告は自然となくなる。進展がないのだからそれはそうなのだけれども、対応している現場の外から見ると、沈黙化している状況に見えてしまう。
そこで大事に鳴ってくるのが「一定タイミングの周知」すなわち「定時連絡」だと思っている。
「状況に進展がない」という状況を伝えるだけでも周りはそれを鑑みて動けるし、実際にどういうことが起きているかを認識することができる。
変化がないことを報告することにかなり意義はあるということなので、その点を頭に留めつつ、障害時の対応フローなどに組み込むようにしたい。
