JaSST Review'18 S0,S1 (memo)

memo テスト

目次

このページの概要

一気に書き上げようと思ったら書ききれなかったので、S1,S2 と S3,S4 を分けることにしました。
今回は S1 (と S0 もちょこっと)。

参考リンク

JaSSTソフトウェアテストシンポジウム-JaSST Review'18 togetter.com

S0) オープニングセッション (ブロッコリーさん)

遅れて参加したので色々聞き損ねました。。
ブロッコリーさんから色々質問がありました。

  • レビューの技法 (チェックリスト / 固有の欠陥タイプに集中 / 視点(設計者、実装者)を決めてレビュー / アドホック) は普段どれを使ってる？
  • タイミング (適宜行う / 工程完了 / 開発者主体のレビュー)
  • どういう立場で普段レビューに参加しているか

S0) 私見

自分としては、それに答えることでいったいどういう立場で話を聞くのかを改めて認識できたのでよかったです。
あとは、自分が普段しているレビュー以外にも色々あるということが分かりました。

予稿集は読んでいたとはいえ、パネリストの方の紹介や、セッションの依頼内容について話があったのでこちらも聞くときに心構えができました。

S1) 講演 「設計レビューで問題を叩き出せ！～QAの役割～」

設計レビューのポイント：人事と人智を尽くす
よいレビューとは「できることをしっかりやること」

  • 現在の状況

    • 環境が変化して、スピード開発が求められるようになってきた(短納期といえども2，3 か月などの短さなので Agile とは違う)
    • 重い開発ルール、短納期、など悩みは尽きない

  • レビューは机上テスト

    • テストは書いてあることを動くことを確認
    • レビューは書いてないことを見つける
      • 書かれてないことがある、ことを見つけるのは難しい。(悪魔の証明)

  • 書かれていないことに、問題は潜む...

    • 社外発生(流出)不具合の割合 : 86% (仕様から見つけられない者の割合)
    • 検査検出不具合の 58% が記載なし

  • 開発者は気付いてないから書けない…

  • レビューの良しあしは「人」から「暗黙知」を引き出せるかどうか

  • 「設計」「テスト」＋「品質」の三つの枠組みでの検証レビューで品質確保

    • 計画要件ー実装まで：機能・テスト十分性検証レビューフェーズ
    • テストー検査(受入テスト)の間：品質十分性検証レビューフェーズ

  • 網羅する、より深く、より広く。視点を変えて設計をする

  • 開発部門とは異なる視点でテストする

  • ※全体的にテスト＝開発チームがやるテスト、検査＝QA部門がやるテスト

  • 品質特性的な点でもテストやレビューをする

    • テスト＝verification
    • 検査＝varidation
      • QA部門独自の観点
      • 障害時の復旧機能、原因調査資料の十分性

  • 探針？？日立独自のもの

    • 開発工程のテスト終盤で、QAが検査項目の「一部」を先行評価し、その品質状況分析結果から、以降の品質向上計画を決めるために行う
    • 作りこみ、見直し原因の二面に対し、動機的原因まで踏み込んで分析する
      • 要は、バグの偏在個所の推定？検討を行う
      • 見直しもする

  • 設計レビューのポイント：人事と人智を尽くす

  • よいレビューとは「できることをしっかりやること」

  • レビューアは自ら気付くべし！

  • レビューアは作成者とは違う視点で、思考を巡らせよう
    • 俯瞰する
    • 先見する
    • 想像する
  • 長い文章、あいまい語などなど注意している
  • レビューアは日和らない。発言し、気付かせるべし！
    ※勝手な解釈で指摘しないことのないように

  • チェックリストを過信しない

    • チェックリストはあくまでも過去起きたことがある問題などを形式知化したもの。
    • ないものは載ってない
    • 文章解釈は十人十色
    • 数が増えると思考停止する
    • チェックリストのウイークポイントを認識した運用が必要
    • 減らしたいが「将来同じ過ちをしないとは限らないので消したくない」という意図がある

  • 開発スタイルに合わせた、レビュー・テストの連携が重要

S1) 私見

自分が現在担当しているサービスとはちょっと重さも規模も段違いだったので即業務に反映できるなとはちょっと思えませんでした...
ただ、基本的な考えみたいなものはとても感慨深かったので、個人的にキニナルワードをピックアップしました。

  1. レビューは机上テスト
    • レビューは書いてないことを見つける
      • 多分誰もが心がけていることだし、普段テストを専門にしている人ならレビューに限らず、仕様を読み解く際も心がけていることと思います
      • この文脈でのレビューは、対開発者レビューだと思うのですが、私はこれをテストケースのレビュア側の心構えとしても受け取りました
      • 書いてあることが正しいことの確認だけでなく、出された項目に対して抜けがないかを見つけるのは結構シンドイですし、大変です
      • 意図を読み解く際に、見えない部分に気を配れるようになるといいなあと思いました
  2. レビューアは日和らない。発言し、気付かせるべし！
    • ここはきっとこういう意図だろうなあ、という想像で解釈するのは NG！という話
      • 現場でのレビューで、発言が少ない！という問題がありましたが、この日和が一つの原因じゃないかなあと感じました
  3. いわゆる市場不具合について、自分で確認・検査する
    • 見逃せば社外事故 : 責任感が高まる
    • 障害時の惨状を知る
      • 自分で顧客対応をしてもうやだ！行きたくないと思うことで、更に慎重になる
      • 顧客意見や考え方、想定していなかった使い方を知る : 視野が広く変わる
    • このあたりの話は恐らく我々テスト専門会社としてお客様先にいると立場的には難しいのかなあと思います。特に QA 部門にいたりすると。
      ただ、可能ならば同行させてもらったり、開発チームから詳細な情報を受け取ることで次へつなげることはできるのかなと思います。

不具合報告・改善要望に関する小ネタ

自己紹介

つみき テストのプロジェクトリーダー兼設計者兼実行者

自分的 UX メモ

評価実行時に不具合や改善要望を起票する際、ユーザビリティに関する部分は起票者(最終的な判断を行うPL、TLの場合もあるかもしれない)の感覚になっていたりはしないでしょうか。
私はします…。いつも不安に揺れているので、以下の基準を自分の中で設けることにしました。

ヒューリスティクス評価

ヤコブ・ニールセンという人が、数多くのユーザビリティ問題を分析して、それらに共通する 10 の原則を抽出しました。
これらに反する場合は不具合ないし改善要望を起票する必要がある、と判断できるかなと。
今後、この10ヒューリスティックスを使ってチェックリストを作りたいと考えているが、今のところは心がけレベルで。

ただし、ユーザビリティに関しては、これらの原則を考える前に大前提として【ユーザ】が誰であるか、どのように使うのかの【ユーザ】そのものの分析を疎かにしては使えません。そこだけはご注意ください。

10 ヒューリスティックス

  1. システム状態の視認性（Visibility of system status）
  2. システムと実世界の調和（Match between system and the real world）
  3. ユーザーコントロールと自由度（User control and freedom）
  4. 一貫性と標準化（Consistency and standards）
  5. エラーの防止（Error prevention）
  6. 記憶をしなくても、見ればわかるように（Recognition rather than recall）
  7. 柔軟性と効率性（Flexibility and efficiency of use）
  8. 美的で最小限のデザイン（Aesthetic and minimalist design）
  9. ユーザーによるエラーの認識・診断・回復のサポート（Help users recognize, diagnose, and recover from errors）
  10. ヘルプとマニュアル（Help and documentation）

システム状態の視認性（Visibility of system status）

  • システムは、妥当な時間内に適切なフィードバックを提供して、今何を実行しているのかを常にユーザに知らせなくてはならない
  • フィードバックの内容は、迅速かつ適切である必要がある

例

システムと実世界の調和（Match between system and the real world）

  • システムはシステム思考の言葉ではなく、ユーザになじみのある用語フレーズ、コンセプトを用いて、ユーザの言葉で話さなくてはならない。
  • 実世界の慣習に従い、自然で論理的な順番で情報を提示しなくてはならない

例

  • Mac や Windows のごみ箱アイコン
  • オンラインショップの買い物かご
  • 日本語のウェブサイトでは日本語のラベルを使う

ユーザーの主導権と自由度（User control and freedom）

  • ユーザはシステムの機能を間違うことがあるので、明確な非常口を必要とする。“取り消し(undo)”と“やりなおし(redo)”を提供せよ

例

  • 動画コンテンツは自動再生しない(ユーザがボタンを押下後に再生する)
  • Windows の Esc キー、よくある申し込み画面の「戻る」「リセット」ボタンを用意する
  • キャンセル行為のキャンセルも行えるようにする

一貫性と標準化（Consistency and standards）

  • 異なる用語、状況、行動が同じことを意味するかどうか、ユーザに疑問を抱かせない。プラットフォームの慣習に従え
  • 評価対象ドメインの標準、ユーザの感じる標準に従うべき
    • Android や iPhone, Windows 等の ユーザが使い慣れた OS 標準や、業務システムであれば、従来使っていたシステムと大きくずれないことなども含まれる

例

  • ウェブサイト内でページデザインの統一
  • リンクラベルとページタイトルを一致させる
  • 各プラットフォームのデザインガイドラインに準拠する

エラーの防止（Error prevention）

  • 適切なエラーメッセージよりも重要なのは、まず問題の発生を防止するような慎重なデザインである
  • エラーの発生そのものを抑止すること、重大な結果(パスワードの変更、管理者権限での操作など)をもたらす操作の場合は、実行前にダイアログを表示すべき

例

  • ウェブページは原則としてURLを変更しない
  • デフォルト値を設定する
  • 入力項目の必須項目には印をつけて目立たせる

記憶をしなくても、見ればわかるように（Recognition rather than recall）

  • オブジェクト、動作、オプションを可視化せよ。システム利用のための説明は可視化するか、いつでも簡単に引き出せなければならない
  • ユーザが情報を記憶しないと次の操作に移れないようではだめ

例

  • ポップアップヘルプ
  • オートコンプリート機能
  • リアルタイムプレビュー機能
    • この辺りはシステムに寄りけりだと思う。必ずしもあればいいわけではなく、むしろ個人情報を扱うようなサービスの場合は記憶させない、というのも大事。ユーザと使われるシチュエーションを考えて判断する

柔軟性と効率性（Flexibility and efficiency of use）

  • 1つのユーザインタフェースでは、全てのユーザを満足させることはできない。
  • ユーザには、不慣れなユーザと上級ユーザがいることを理解し、ショートカット機能、カスタマイズ機能を提供することで、より多くのユーザ要求を満たせるようにしよう

例

  • キーボード・ショートカットキー設定
  • 日本語入力システムの辞書登録

美的で最小限のデザイン（Aesthetic and minimalist design）

  • 対話には、関連のない情報や、めったに必要としない情報を含めるべきではない。余分な情報は関連する情報と競合して、相対的に視認性を減少させる
  • 無駄に情報を詰め込んでもユーザを圧倒するだけ。
  • ユーザへの説明をしたいあまり、小さな文字で大量に文字を詰め込んでも見づらいだけ

例

  • Google の初期トップページなどはよい
  • WEBページには見出しを付けてページ左右の空白や行間を空ける
  • テキストだけでなく効果的に画面を使用する
    • 個人的には一番センスが問われる部分だと思う…経験則じゃどうにもならない

ユーザーによるエラーの認識・診断・回復をサポートする（Help users recognize, diagnose, and recover from errors）

  • エラーメッセージは平易な言葉(コードは使わない)で表現し、問題を的確に指し示し、建設的な解決策を提案しなければならない
  • エラーメッセージを元に、ユーザが問題を解決できるようにするべき。また、ユーザを非難するような内容であってはならない

例

  • 404 エラーではなく、カスタムメッセージを表示する 誤入力の項目にはメッセージを表示した上で、更に項目名に印をつけて目立たせる
    • ただし、想定されるユーザが HTTPステータスに詳しい場合は余計なことは書かないほうがわかりやすいこともある
  • 綴りが間違っている場合、正しい入力候補を掲示する

ヘルプとマニュアル（Help and documentation）

  • ヘルプやマニュアルは探しやすく、ユーザの作業に焦点を当てた内容で、実行のステップを具体的に提示して、かつ簡潔にすべき。
  • マニュアルなしでも使用できるくらいのデザインにしつつ、ユーザ補助をするためにヘルプやマニュアルを用意しよう

例

  • FAQ を用意する
  • 機能の説明だけでなく、タスクの実行手順を示す
  • 文字だけでなくイラストや画面ショット、動画などを併用する
  • ユーザのレベル(初級～上級)や、目的(導入～応用)によってマニュアルを分冊する

これだけ！KPT -- まえがき -- (memo)

KPT

これだけ！KPT

読んだ本の紹介

これだけ! KPT

これだけ! KPT

現在の私

  • 10名程度のメンバーで構成されたチームの中の、さらに小規模な 1-3 名程度のチームリーダー
  • 複数のPRJ を少人数で、そこそこのスピード(2週間～1か月)で回していて、振り返りの時間が取れない
  • それっぽい KPT はやってきたが、そもそもちゃんと KPT を勉強したことがない

記事の目的

  • これだけ！KPT の内容を、各章ごとに要約して、いつでも読み返せるようにする。
    • 私見を混ぜるときは(私見)と書くようにする
  • 一気に読破は難しいので、1つの記事で、出来るところまで。

まえがき まとめ

  • どういう時に、どういう立場の人が読めばいいのか、ということが書いてある。
    ざっくりいうと、どんな立場であっても読んで価値がある、と書いてあるように読めた。(私見)
  • この本の目的は「自律的なチーム」を育てていく方法の一つとして、KPT というフレームワークを提案し、活用方法を紹介している
  • チームは人で構成されており、人が育つということは、チームが育つということでもある

  • 以下のようなリーダーをターゲットにおいている(が、前述のとおり、それ以外の立場の人が読んでもためになる)

    • チーム内の情報共有を効果的に行いたい
    • チーム内に改善サイクルを作りたい (私がリーダーとして一番やりたいこと(私見))
    • チームに一体感を持たせたい
    • チームメンバーとの距離を縮めたい
    • リーダーの仕事をもう少しチームに任せたい (これは私がメンバーの立場でやりたいこと(私見))
    • チームに自律的に動いてもらいたい

  • KPT は継続していくことで効果が増すだけでなく、チームの雰囲気をよくすることができる

感想

KPT をやりっぱなしではなく、継続して、Try までやりきり、次の Keep へまわしたい。現状だと、個々人で KPT を実施しているだけで、チームとしての KPT になってない。
そういった意味で、この本にとても期待している。

ffmpeg で動画を結合する方法(memo)

ffmpeg で動画を結合する方法

【ffmpeg】動画・音声を連結する concat の使い方 其の3 : ニコニコ動画研究所

基本的な手順は上記の URL を参照しつつ実施しました。
上記の手順で詰まったところを補足しています。

環境

  • OS : Windows 10 home
  • ツール？: power shell

ffmpeg は以前入れてその時に手順を残していないのですが、ブックマークを見た感じだと、以下のページから DL してそう。 まあその辺は、よしなに適切な環境で実施してください。

ffmpeg Documentation

手順

前述の通り。洗練されたやり方なんて知らないので、基本的にサクラエディタ上でコマンドを作ってコピペしました。

詰まった個所

以下の感じで、input.txt のなかにフルパスで記載していたら、ファイルが正しく解釈されなくて困ったので、結合したいファイルと同じ場所に input.txt を置いて、相対パスで記述しました。
file E:/video/test1.mp4
file E:/video/test2.mp4

file:test1.mp4 file:test2.mp4

上記のとおり。

実行コマンドは ffmpeg -f concat -safe 0 -i input.txt -c copy ketsugou-all.mp4

 > ffmpeg -f concat -safe 0 -i input.txt -c copy ketsugou-all.mp4
 ffmpeg version N-90173-gfa0c9d69d3 Copyright (c) 2000-2018 the FFmpeg developers
   built with gcc 7.3.0 (GCC)
   configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libmfx --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
   libavutil      56.  7.101 / 56.  7.101
   libavcodec     58. 13.100 / 58. 13.100
   libavformat    58. 10.100 / 58. 10.100
   libavdevice    58.  2.100 / 58.  2.100
   libavfilter     7. 12.100 /  7. 12.100
   libswscale      5.  0.101 /  5.  0.101
   libswresample   3.  0.101 /  3.  0.101
   libpostproc    55.  0.100 / 55.  0.100
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c584440] Auto-inserting h264_mp4toannexb bitstream filter
 Input #0, concat, from 'input.txt':
   Duration: N/A, start: 0.000000, bitrate: 18913 kb/s
     Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 18782 kb/s, 29.70 fps, 60 tbr, 30k tbn, 59.94 tbc
     Metadata:
       creation_time   : 2018-07-30T11:03:46.000000Z
       handler_name    : VideoHandler
       encoder         : AVC Coding
     Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 130 kb/s
     Metadata:
       creation_time   : 2018-07-30T11:03:46.000000Z
       handler_name    : SoundHandler
 Output #0, mp4, to 'ketsugou-all.mp4':
   Metadata:
     encoder         : Lavf58.10.100
     Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 18782 kb/s, 29.70 fps, 60 tbr, 30k tbn, 30k tbc
     Metadata:
       creation_time   : 2018-07-30T11:03:46.000000Z
       handler_name    : VideoHandler
       encoder         : AVC Coding
     Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 130 kb/s
     Metadata:
       creation_time   : 2018-07-30T11:03:46.000000Z
       handler_name    : SoundHandler
 Stream mapping:
   Stream #0:0 -> #0:0 (copy)
   Stream #0:1 -> #0:1 (copy)
 Press [q] to stop, [?] for help
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c614e80] Auto-inserting h264_mp4toannexb bitstream filter
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter6x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter4x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter2x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter2x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.6x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.3x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.8x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.7x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.7x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.9x
 [mov,mp4,m4a,3gp,3g2,mj2 @ 000001934c5976c0] Auto-inserting h264_mp4toannexb bitstream filter.9x
 frame=360144 fps=1397 q=-1.0 Lsize=30600713kB time=03:20:04.27 bitrate=20882.6kbits/s speed=46.6x
 video:30388971kB audio:192678kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.062339%

 ```

ユーザビリティサークル 2回目 ユーザビリティエンジニアリング輪読メモ

ユーザビリティサークル活動の報告

とりあえず、話せる内容だけここに書く。勉強会のメモ。

持ち物

Introduction Chapter 1 ユーザ中心設計概論

F 氏 の発表 内容まとめ
1-1. ユーザビリティ
1. 利用品質を保証しなければならない
1. 問題種別 : 有効性
- 文化の違い、手順の導線、ユーザターゲット

ユーザビリティの定義 製品やシステム、サービスの使用可能性 - 特定のコンテキストにおいて - 特定のユーザが - 特定の目標を達成するために ある製品やシステム、サービスを利用した際の

効果(有効性) : ユーザがもk表を達成できるかどうか
効率 : なるべく最短距離で目標を達成できるか
満足度 : ユーザに不快な思いをさせていないかどうか -> ユーザが快く満足して使えているか

ユーザビリティと使いやすさは違う。

QCDの前に優先順位は下げられがちだが、ユーザビリティが低いと、市場に出した結果使えないものが出来上がる可能性がある。

失敗の原因

  1. ゴムのユーザ : 使用ユーザを考える
  2. コンテキストを把握していない : 利用状況を考える その要求はどんなコンテキストから得られたのか。だれがどのような用途で作ったのかを考える必要がある。
  3. 点と線 :1 箇所でも通過できないところがあれば、ゴールに到達できない
    網羅的に問題点を取り除くより、よく使う「重要な経路」上の問題点を集中的に取り除くことが有効

(感想)重要なケースに絞ることが肝要 : これって、テスト戦略でリスクベースで考える感じと似ているのかな

ユーザエクスペリエンス

  1. ユーザビリティを超えて : ゴールを達成できても、それは当たり前品質を脱しない
    狩野モデルの魅力的品質

  2. エクスペリエンスの価値
    コモディティ: 普遍化した差別化されてない製品
    エクスペリエンスの価格は、コモディティや製品の数十倍～数百倍である

  3. UX の構造
    製品開発の一番最初(企画段階)から地道に積み重ねていかない限り、優れたUXは実現できない
    ハッセンツァーモデル : 実用的、感性的な視点

利用と非利用期間からなる、時の経過につれた UX
懐古的な UX があってもいいのではないか。

ユーザ中心設計

評価してもらうんじゃない。ユーザには体験した結果を報告してもらう。 各開発フェーズの中で、細かくプロトタイプで調査、分析、設計、評価、改善 を繰り返す。

  1. 人間中心設計 をやるといいこと
    ユーザにとっていいことと、提供会社にとっていいこと、それを分けて書いたほうがいい。

ユーザビリティの概念

満足度 ≒ UX : 結果系 効率度 ≒ 改善 : 原因系 有効度 ≒ 前提 : 原因系

所感

まだ所感までたどり着かない… なんにしても、ただ、ユーザビリティの勉強はテストのほかの勉強も使えそう。
私は要求分析が苦手だから、そのためにももう少し勉強していこう。
あと、たまに話で出てくるデザインの話はいいなって思う。もっと勉強したいな。

【趣味】二日酔い対策

アルコール

注意

  • 個人の体質による問題もありますのであくまでも参考程度でお願いします

記事の目的

オトナになって幾星霜、お酒を飲む機会が増えて、そして弱くなってきた気がするので、二日酔い対策について真剣に考えてみました。

目次

飲む前

おススメはキューピーの「よ・い・と・き」

事前に飲むと酔いにくい。 (個人差はあります)

ただし、酔いにくくなっているだけなので、いえーい酔わない酔わないと、調子にのって飲むと大惨事が待っています。
事前に入れるかどうかは体調と相談してください。

空腹の状態でお酒を入れないようにする

空腹な状態でアルコールを摂取すると回りも早いと思われるので、可能な限り乾杯前にナッツなど、何か入れておく。

胃薬を飲んでおく

なんでもいいと思うけど、何となく液体タイプのほうが効く気がする。
まあ、気休めです。

ヨーグルトを飲んでおく

小耳にはさんだ程度なので、これも気休め。 乳製品がいいと聞いた気がする。

飲み中

乾杯時にはアルコール度数の低めのものを飲むようにする

とはいえ、やはり飲み前は空腹であることが多いと思うので、強い酒をガツンと入れないようにする。
固くない個人的な飲みの場であれば、可能なら先にご飯を食べてしまうこと。

ペースはゆっくりと

アルコールの分解速度の問題もあるし、ペースが速いとその分量を飲んでしまうことがあるので、ゆっくり飲むようにしたい。

おススメは、ウイスキーのロックをグラスに入れておくこと。
味の変化を楽しみつつ、飲み会の場などではグラスが空になってないので「次、何行く？」と勧められにくい。

もろ刃の刃で、こいつ酒が飲めるなと勘違いされてしまう可能性もある。使う場合は自己責任でお願いします。

間に水分を取るようにする

ただし冷水よりは、お茶などの胃を温めるものの方がよい

飲んだ後

おススメはやっぱりキューピーの「よ・い・と・き」

www.kewpie.co.jp

てきめんに効く。

あわせ技の「ハイチオールC」

www.bibeaute.com

これ、もとは二日酔いの薬だったらしいですよ。これも効く。

胃のダメージが強めの人は、ソルマック！

私はお酒を飲むときによく食べるせいもあって、胃にダメージが出やすいタイプでして、ソルマックがあるといいなあと思っています。

何かっていうと、ソルマックを実際に飲んで効果を試したことはないですｗ 普段は普通の胃薬(三井三共胃腸薬)ですねえ。

定番のシジミの味噌汁

まあ何でもいいのではと思ってます。気休め気休め。
何となく染みわたります。

いかがでしたでしょうか。 参考になれば幸いです。

ドメイン知識をゲットしよう！～DNS Summser Days 2018～(自分用メモ)

memo

DNS Summser Days 2018 の参加意図

評価を担当しているサービスが DNS に関係しているため、これは一つ勉強せねば！と去年から 2回目の参加になります。
午前中から参加したかったのですが、残念ながら午後からの参加となります。

togetter

togetter.com

ライトニングトーク Part2

gTLD動向 ～GDPR対応はRDAPで～株式会社日本レジストリサービス（JPRS）

whois には問題があった。

  • 入出力の標準フォーマットがない
  • 国際化対応（ドメイン名含む）されていない
  • ユーザー認証に基づくアクセスコントロール （“tiered access”）機能がない
  • サーバー発見機能（Where to ask?）がない
  • サーバー認証機能がない（Port 43/80）
  • 通信路の暗号化機能がない（Port 43/80）

whois と RDAP を総称して RDS (あーるでぃーえす)と呼ぶ。

GDPR からの要求

ID4me

https://dnsops.jp/event/20180627/2018-06-27_DNS_Summer_Day_ID4me.pdf ドイツの会社？

  • ユニバーサル・デジタル・プロファイル

現在のSSO の問題点

  • OTT が所有され、ブランドされている
  • プライバシー保証なし
  • ユーザーにとっての移植性と選択肢がない

DNS で色々解決する

  • ディスカウント・プロセス（ホスト名を ID として使う）
  • ID ポータビリティ（ドメイン名のオーナーだったら）
  • ロール・セパレーション（認定 vs. ユーザー情報管理）
  • ユーザー・コンセント・マネジメント

技術的オーバービュー

  • DNS ベースの検出メカニズムを OpenID Connect に追加しました
  • ホスト名または E メールアドレスを ID プロバイダにマップできます
  • TXT レコードでポインターを指定するだけ
  • DNS の部分を追加する必要があり、残りは標準の OpenID Connect です

ED25519のすすめ

証明書の署名アルゴリズムのこと。

パケットがとても小さくて済むので，みんなDNSSECを使おう！という話。
色々署名アルゴリズムについて話しているけどついていけないのでいったん自分的に休憩ｗ

RSA2048が一般的なんだと思ってた。超重いじゃん。

5分でわかるセキュアなローカルDNS

いえーい。これを聞きに来たといっても過言ではない。
一般的な企業のネットワーク構成 キャッシュサーバから内部の情報が外部に送信されてますよね。

-> LAN機器って DNS サーバ あ。これ昔やってたな。

別件で、アンケートに回答よろしく

bit.ly

BIND9.9から9.11へ移行のポイント -9.9系サポート終了まであと三日！

資料

*BIND 9.9から9.11へ移行のポイント(フルリゾルバ編)https://dnsops.jp/event/20180627/BIND_9.9%E3%81%8B%E3%82%899.11%E3%81%B8%E7%A7%BB%E8%A1%8C%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88_%E3%83%95%E3%83%AB%E3%83%AA%E3%82%BE%E3%83%AB%E3%83%90%E7%B7%A8_v0.8.pdf * BIND機能差分https://dnsops.jp/event/20180627/ISC_BIND%E6%A9%9F%E8%83%BD%E5%B7%AE%E5%88%86_v0.7.pdf

BIND サポート

BIND 9.11 のほうが、12 よりもサポート期間が長い。
なるほど、じゃあとりあえず上げるとしたらこれか。

  • Openssl 1.0.2a 以上じゃないとだめー

阿波連 良尚 さんの発表BIND 9.9から9.11へ移行のポイント(権威サーバ編)

https://dnsops.jp/event/20180627/DNSSummerDay2018_BIND9.11%E5%A4%89%E6%9B%B4%E7%82%B9auth.pdf

ドメイン名 ハイジャックされないために 漢字の其田学さん

ドメイン名に対する攻撃

上からヤバい順 * ドメイン名ハイジャック * ネームサーバハイジャック
ゾーンがハイジャックされちゃいました
* 見えない… *キャッシュポイズニング

ドメイン名攻撃に対する歴史

  • 資料公開されたら差し替え

どうやってドメイン名ハイジャックを行うのか。

更新を促すサポートメールが飛んできて、そのメールを踏むと、IDやPWが盗まれて、ハイジャック完了。

なりすまし対策：コントロールパネル向け

  • FIDO キーデバイス上のドメイン名ごとに暗号化鍵、複合鍵を格納

  • TLSクライアント証明書認証 JPNIC とか、JPRS が対応している。

  • デメリット : 証明書のライフサイクル管理が大変面倒。運用負荷が高い

  • TOTP/HOTP ( ワンタイムパスとか )
    なりすましサイトには効果がない。

  • SMS認証 なりすましサイトには効果がない

  • メール認証 なりすましサイトには効果がない

  • ACL マルウェア等でPCから侵入されると意味がない。なので、多要素認証と組み合わせるとよい。

  • FIDOいいよ！

情報書き換えに対する対策 - 管理画面のロック

  • コントロールパネル上での情報変更をできなくする機能 ** 解除方法を検討する必要。

  • レジストラロック

  • レジストリロック

  • インターネット情報で、情報変更できないレジストラであればいい？

  • いろんなロックがあるけど、解除方法も重要

  • 失う前に導入したほうが結果としてはコストは安く済む

まとめ

FIDOいいよ！
FIDO Alliance FIDOの仕組み - FIDO Alliance

信頼できるレジストリ、レジストラを選ぶにはどうしたらいいのか。google さん、頑張って！

DNSブロッキング

パネルディスカッションだけどゴールはない。

DNSブロッキングの経緯 山口さん

IIJ 山口さん。

  • ブロッキング: ユーザの同意を得ずに 通信を ISP設備で遮断する措置。
  • 通信の秘密を侵害する
    • 「アクセスを遮断すること」以外にも「通信先を監視している」これが問題になることが多い

DNSブロッキングとは

要するに DNS ブロッキングと一緒。

ブロッキングの問題

  • 通信の秘密を侵害する

    • どんな目的であれ、形式的には通信の秘密を侵害しているが、利用者の同意があればよいことになっている

  • ブロッキング対象リストを誰が保守するのか

    • 表現の自由の問題や他人の権利の侵害の問題などいろいろ難しい

児童ポルノブロッキング

パネルディスカッション

DNSブロッキングの前にドメイン名は？

  • ドメイン名はシャットダウンされてはいない

警察は強硬に DNSブロッキングをしてほしいと言っていた。 経緯としては、児童ポルノの場合は、国際的に問題になっていたり、児童の人権の問題がある。

あとで資料を載せますので！