DNS 勉強会資料 1日目：ドメイン名って何？(memo)(教育)

DNS をはじめよう 1日目

全体の流れ

以下の流れで話が出来たらいいな・・・

ドメイン名とは何か？

郵便で手紙を送る時に住所が必要であるのと同様に、 インターネットでは、電子メールを送ったりウェブサイトを見たりするために、 相手がインターネット上のどこにいるのかを特定する必要があります。 ドメイン名は、言ってみれば「インターネット上の住所」にあたるものです。(https://www.nic.ad.jp/ja/dom/system.html より抜粋)
　
ドメイン名を使ってインターネット上でやりとりを行うためには、 これをコンピュータ同士が通信するために必要なIPアドレスに変換させなければなりません。このドメイン名とIPアドレスを対応づけるしくみがドメインネームシステム(DNS)であり、「インターネットの住所録」にあたります。(https://www.nic.ad.jp/ja/dom/system.html より抜粋)

ニュアンスですが panmania.hatenadiary.com を例にとると、以下の感じ。

  • panmania 新宿区西新宿1-1-1
  • hatenadiary 東京都
  • com 日本

com だから日本、とか、そういうことではなくて、ニュアンスですニュアンス。考えずに感じてください。要するに、住所が特定できる＝ページを特定してアクセスができるということです。

ドメインの構成

ドメインの構成は、以下のページを参照してください。私が頑張って説明するより丁寧且つ詳細です。

ドメイン名のしくみ - JPNIC

先ほどの panmania.hatenadiary.com を例にとると、以下のとおり。

* panmania    新宿区西新宿1-1-1 第3レベルドメイン(3LD)
* hatenadiary    東京都 第2レベルドメイン(2LD...言うかな)
* com  トップレベルドメイン(TLD)

ドメインの一番最後、.com や .jp などを基点に、それより左を2,3 とカウントアップします。 panmania などの部分を「ラベル」ともいうが、TLD の L はレベルなので間違えないように。

  • 混乱のもと
    • DNS をかじりだすとサブドメインとか孫ドメインと、第2レベルドメインってどう違うの？という疑問が湧き上がる事と思いますが、自分なりの理解で言うと、2LD、3LD というのはラベル数を表す単位で、サブ、孫ドメインというのは特定のドメインを基準にそこから分かれたもの、というふんわりとしたイメージです。

ドメインの種類ってどんなものがあるの？

  • gTLD (参考 : https://www.nic.ad.jp/ja/dom/types.html#kinds-gtld)
    • 世界の誰もが登録できる「.com」「.net」//「.org」
    • 登録にあたって一定の要件が必要とされる「.edu」「.gov」「.mil」「.int」
    • 新gTLD「.biz」「.info」「.tokyo」「.name」「.pro」「.museum」「.aero」「.coop」「.jobs」「.travel」「.mobi」「.cat」「.tel」「.asia」「.post」「.xxx」

「.com」「.net」//「.org」の間の // はわざとです。次回書きますが、この二種は(多分現在も)レジストリが異なります。
レジストリが異なることによる問題も後半でてくるので、あえてこのような記載にしています。

今日はここまで。

DNS 勉強会資料 0日目：準備(memo)(教育)

DNS をはじめよう

経緯

ソフトウェアテストエンジニアとして、DNS サービスの検証を行っています。 というより、今年から前任から引き継いで検証することになりました。
元々少人数体制だったところからの引継ぎのため、まずは本格的に評価に入る前に自身も含めメンバーの知識底上げをする必要があり、その取り組みの一環として毎週1回 DNSトークをすることになりました。
その資料まとめを、ノウハウをまとめる意図もあってブログにまとめることにしました。

1 回 5－10分程度のトークになるので、ブログもその単位で作成していこうかと思います。

一般的な DNS の知識の説明

参考URL集

Japan Network Information Center - JPNIC

  • 全てまとまっているので究極他のページは見なくてもいいくらい

JPドメイン名のサービス案内 | JPRS

  • JPドメインについては JPNIC よりもこちらのほうが詳しいかもしれない

RFC1034 ドメイン名−概念と機能
RFC1035 ドメイン名−実装と仕様書

  • 1035 のほうが見る機会は多いかもしれない。いずれにしても基本となるページ。 英語が読める人は原文を読みましょう。

JaSST Review'18 S2 (memo)

目次

このページの概要

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

S2) レビュー再定義

speakerdeck.com

  1. レビューの目的
    • 品質担保、バグをみつける
    • コードの均一化
    • スキルの低いメンバーの教育
    • スキルトランスファー？をするため
  2. 分類
    • 検査：品質担保
    • 学習：ナレッジ共有
    • 強化：リファクタリング、もっとよく、もっときれいに
  3. 目的達成できてる？
    • レビューの目的と実際にレビューをしている人のコメントの間で相違があることがある
      • 実際のコメントにしかないもの：コードの理解、コミュニケーション
  4. レビューは楽しいですか？
    • やらなくてはいけないこと
    • やるべきこと
    • やりたいこと
    • やらなくてはいけないことに話が集中しすぎてつらくなる
      • 実際にはやらなくてはいけないことですら難しい...
  5. モブプロを通してもっとわくわくするレビュー！
    • モブプロを初めてレビューが不要になった
    • でもレビューはやっぱり必要
  6. モブプログラミングを通してもっとわくわくするレビューについてのアイデアが出てきた
    • 働き方モブプロ
      • 9:00-11:00 個人時間
      • 以降全部モブ
      • 分担作業
    • 分担作業の前後に同期をとる作業が必要になる
      • 前：キックオフ 後：レビュー
      • これ忘れがち
    • ミスコミュニケーションにより手戻りが発生する可能性もある
  7. 分担作業とモブワークの違い
    • 向き不向きがある。同期コストがかからないのであれば、分担でもいい
    • 分担する＝生産性が高いという思い込み
      仕事や状況に合わせて使い分けている
    • モブワークをすると、工程としてのレビューは不要になった
    • レビューによる忖度がストレス源
  8. チームの最善を目指す
    • 分担：誰がやっても難しい作業も、アサインされたら誰かが頑張らなきゃいけない＝つらい
    • モブ：誰がやっても難しくてもチーム全員で割り切って判断して対応することができる
  9. モブプログラミングはチーム全体の活動
    • チーム全体で立ち向かってダメなら仕方ない
    • 判断をチームですることができる
    • 絶対なる安心感とそこから学ぶ姿勢
  10. モブプログラミング学習
    • 結果だけじゃなくて過程を学ぶことができる
    • 分担：同期(ナレッジ残す的な)しなければ、個人の学びに過ぎない
    • 経験値が低い人をドライバーにすると、わからなければ手を止める権利があるのでわからないところが見えやすい
    • ノウハウの Just in Time！
  11. 我々に必要なレビュー
    • Pull-Request
    • モブ振り返り
    • 今日の仕事は最高だった？
      • どう改善するか
      • それは今やること？
      • 次はどういうことを学ぶべき？
  12. Re-View (再び、見る)
    • モブじゃないレビューは本当に Re-Viewだった？
      • 実際にはファーストビューである
      • 初めて見る場合は理解するコストが必要
  13. リアルタイムとレビューの強み、弱み
    • 強みと弱みが補完関係にある
  14. レビューの再定義
    • 自分たちのレビューを見直そう
    • そのプロセスでの解決に固執しなくてもいい
    • 目的を達成するために、そのプロセス自体をやめるという選択肢も常に頭に入れておく
  15. 実際にやらなくてはいけない、からの解放
    • 無限にわいてくる やらなくてはいけないことに対して、有限のリソースで向かっている きりがないし、目指したって無理、つらいしギスギスする
    • ROI を考えて自分たちにできることをする
    • ダメなら仕方ないという割り切り
    • 最善を尽くしても失敗したときはそこから学ぶ
  16. 変化に適用する
    • 他人にうまくいったことが、自分たちにそのまま当てはまるとは限らない
    • チームの練度や状況によって最適解は変化する
      • 一度定義しても時がたったら見直す
  17. 情緒を大事にする
    • 小手先のテクニックでどうにかできると思わない
    • 人間であることを楽しむ
    • 完璧ではないけれど成長できる
    • 楽しいと楽しくないのインパクト
    • 楽しくないとやめるのでは * 楽しいレビューを考えよう！！！！

      S2) 私見

      モブプロ推し、というわけじゃなく、モブプロを通して学んだこと、その結果必要なレビューについての話でした。
      私が大事そうだと思ったところは赤字にしておきました。 自分の中の結論としては、現在のチームでモブテスティングは難しい。テストの専門会社として、お客様先に入ってテストをしているので、モブテスティングを「やってみる」というのがまず超難関。 ただ、基本的に全部仕事をするうえで大事なことだなと思いました。特に時間とお金とリソースが許せばいくらでもやりたいことがわいてくる中でレビューにどこまで時間をかけるのか。
      あとは、チームリーダーとして作業を見積もる際に忘れがちな「作業の同期」にかかわるコストの存在を改めて「コスト」として認識できました。

他、モブテスティングを研修で使えるんじゃないかということ。 レビューという軸からはちょっとずれてしまいますが、今いるメンバーのスキルが上がれば、畢竟レビューの質も上がるはず、という強引理論。
モブテスティングを通して、要求分析～テスト実装(あるいは実行、報告まで)をチームで行い、テスト初心者の教育、新ドメインに入るメンバーの育成などが行えるのではないか、と考えました。 実施するとしたら恐らく1日がかりになるでしょうし、すぐには難しいことと思うのですが、私が参加したいですｗ

なお、やり方次第ですが、WACATE 2018夏で同じようなことをしていたチームがあったと記憶しています(うちの班は分担を選びました)。
次に WACATE に参加する機会があれば、モブテスティングを提案してみたいです。

テスト観点についての個人的なリンク集

memo テスト

テスト観点についての個人的なリンク集

panmania.hatenadiary.com

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 になってない。
そういった意味で、この本にとても期待している。