@t_wada さんの #TDDBC 基調講演のメモ

https://www.youtube.com/watch?v=Q-FJ3XmFlT8

•  レッド→グリーン→リファクタリング
  • わざと失敗させる（テストコードのテスト）→仮実装→三角測量
• 仕様からTODOを起こす

例:

--

TODO

テスト容易性：高　重要度：高

• 数を文字列に変換する
  • 1を渡すと文字列”1”を返す→仮実装
  • 2を渡すと文字列”2”を返す→三角測量

--

• テストは動作するドキュメントであってほしい
• TDDではテストメソッド内で、検証・実行・準備の順番で書く
  • 残酷な現実を突きつけられるのが早くなる
• assertメソッドの実測値と期待値の引数の順番は最初に確認しておく
• 作る前に使う のがTDD
  • 利用者側からどう使いたいかを考えて作っていく
  • 使いやすいコードの方が作りやすいコードより大事
• テストコードのテスト
  • ミューテーションテスティング
    • 実行するのにコストがかかる
  • 仮実装
    • まずレッドにしてテストコードのテストを行う
      • プロダクトコードの方でわざと間違ったことをしてレッドにする
    • 次にグリーンにする
      • 一番早くグリーンになる方法でコードを書く
        • ex) 期待される値をそのままベタに返す
• リファクタリング
  • テスト方法
    • 1つのメソッド内でアサートを増やす
      • アサーションルーレットというアンチパターン
      • どのアサートで失敗してるかどうかわかりにくい
      • 動作するドキュメントとして読みにくい
    • テストメソッドを増やす （おすすめ）
      • どこで失敗しているか自明
      • ワンアサーションパーテスト
      • ユニットテストではなくてエンドツーエンドテストの場合はコストが高いので1つのメソッド内で複数アサートも許容
  • 三角測量
    • 三角測量を経由しないと仮実装を直しちゃダメということはない
    • テストの書き方に不安がなくなってくればそのまま実装でも大丈夫
      • 仮実装→実装という経由
• テストコードのリファクタリング
  • 重複の除去
  • ツーアウト派
    • 2カ所重複
  • スリーアウト派
    • 三カ所重複
    • 2だったらいいけど、三カ所は本格的に崩壊し始めている兆候とみなす
• TDDのスキル
  • 問題を小さく分割する
  • テストコードと実装への不安と自信に応じて歩幅を調整する
    • テスト→仮実装→三角測量→実装
    • テスト→仮実装→実装
    • テスト→明白な実装
  • テストの構造化とリファクタリング
• インナークラスを使って仕様を明確にする
  • テストの構造化とリファクタリング
  • テスト仕様のツリー構造をクラスでも再現する
    • 仕様（5の倍数の時はBuzzに変換する）
      • 具体テスト（5を渡すと文字列Buzzを返す）
  • 動作するドキュメントにする
  • 必要最低限のテストだけ残す
    • 三角測量用のテストは削除しておく
• テストの構造化とリファクタリング
  • テストは不良資産になり得る
  • テストのメンテナンスコストを考える

CVE-2019-11043 に該当するかのチェック

CVE-2019-11043 に該当するか、Exploit ツールが公開されていたのでチェックしてみた。

github.com

まず go のインストール

go で動くツールらしく、go がローカル環境になかったので homebrew でインストール。

brew install go

.bash_profile に下記を追記

# go
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

Exploit ツールをインストール

go get github.com/neex/phuip-fpizdam

実行

phuip-fpizdam [url]

結果

2019/10/30 18:44:44 Base status code is 404
2019/10/30 18:44:56 Detect() returned error: no qsl candidates found, invulnerable or something wrong

問題なかったようです。

※本番環境ではなく、クローン環境にてテストをしております

phpbrew install メモ

phpbrew install --jobs=$(sysctl -n hw.ncpu) php-7.1.19 \
  +default +mysql +pdo \
  +bz2="$(brew --prefix bzip2)" \
  +zlib="$(brew --prefix zlib)"

APCu を入れる場合

phpbrew ext install apcu

WordPress で Table Prefix を変更したら管理者権限でログインできなくなった際の対処方法

WordPress で Table Prefix を「wp_」から「test_wp_」に変更したらなぜか管理者権限でログインできなくなってしまった。

DB にプレフィックスデータが記録されていてそれも修正しないといけないらしい。

wp-cli 経由で変更できないかなと思ったら、wp-cli-rename-db-prefix という wp-cli の拡張パッケージを見つけた。

github.com

というか、 wp-cli に拡張パッケージなんてのがあるんですね。

インストール

wp package install iandunn/wp-cli-rename-db-prefix

~/.wp-cli/packages/ ディレクトリにインストールされるっぽい。

実行

wp rename-db-prefix test_wp_

以上になります。

CSS3だけでつくるアコーディオン

今更ながらかもしれないが、CSS3だけ使ってアコーディオンを実装してみたのでメモ。

See the Pen CSS3 Accordion by Poor Stack (@poorstack) on CodePen.

もっと簡素化したものがこちら

See the Pen CSS3 Accordion 101 by Poor Stack (@poorstack) on CodePen.

仕組み

肝の部分は下記の箇所

.accordion-Body {
  display: none;
  padding: 10px;
}

.accordion-Checkbox:nth-of-type(1):checked ~ .accordion-Body:nth-of-type(1),
.accordion-Checkbox:nth-of-type(2):checked ~ .accordion-Body:nth-of-type(2)
{
  display: block;
}

要するに :checkd 擬似クラスセレクター と ~ 結合子を使って、選択されているチェックボックスに対応するパネルを表示させている。

下記のようにタイトル部分に label 要素を入れ込んでおき for 属性で対応するチェックボックスの id を指定してあげればタイトルをクリックするとボディが表示されるアコーディオンになる。

<div class="accordion">
  <input type="checkbox" class="accordion-Checkbox" id="checkbox1">
  <input type="checkbox" class="accordion-Checkbox" id="checkbox2">


  <h2 class="accordion-Title">
    <label for='checkbox1'>Title1</label>
  </h2>
  <div class="accordion-Body">
    <!-- content -->
  </div>

  <h2 class="accordion-Title">
    <label for='checkbox2'>Title2</label>
  </h2>
  <div class="accordion-Body">
    <!-- content -->
  </div>

</div>

実際に使用するときは下記のようにチェックボックスを隠すと良いだろう。

.accordion-Checkbox {
  position: absolute;
  width: 0;
  height: 0;
  margin: 0;
  padding: 0;
  opacity: 0;
  -ms-appearance: none;
  -moz-appearance: none;
  -webkit-appearance: none;
  appearance: none;
  border: none;
}

postcss-cli で postcss-cssnext

postcss-cli で postcss-cssnext を使う場合のメモ。 （ついでに、sugerss と postcss-import も）

ディレクトリ構成

.
├── dist/
├── package.json
├── postcss.config.js
└── src/

セットアップ

$ yarn add postcss-cli postcss-import postcss-cssnext sugerss --dev

postcss.config.js

module.exports = () => ({
  map: false,
  parser: 'sugarss',
  plugins: [
    require('postcss-import'), // postcss-import を先に記述
    require('postcss-cssnext')
  ]
})

対象ブラウザを指定したい場合

module.exports = () => ({
  map: false,
  parser: 'sugarss',
  plugins: [
    require('postcss-import'),
    require('postcss-cssnext')({
      browsers: [
        '> 1%',
        'last 2 versions',
        'Firefox ESR',
        'Opera 12.1'
      ]
    })
  ]
})

package.json

{
  "scripts": {
    "build": "postcss --ext css -d dist src",
    "watch": "postcss --ext css -d dist src -w --verbose"
  },
  "devDependencies": {
    "postcss-cli": "^5.0.1",
    "postcss-cssnext": "^3.1.0",
    "postcss-import": "^11.1.0",
    "sugarss": "^1.0.1"
  }
}

ビルド

$ yarn build

before

src/style.sss

@import 'hoge.sss'

:root
  --bg-color: gray(10%)
  --font-color: #333
  --main-color: red

@custom-media --small-viewport (width <= 800px)

html
  color: var(--font-color)
  background-color: var(--bg-color)

a
  color: var(--main-color)

  & span
    color: var(--font-color)

  @nest span &
    color: blue

@media (--small-viewport)
  a
    color: yellow

src/hoge.sss

// hoge
.hoge
  display: none

after

dist/style.css

/* hoge */
.hoge {
  display: none
}
html {
  color: #333;
  background-color: rgb(26, 26, 26)
}

a {
  color: red
}

a span {
  color: #333
}

span a {
  color: blue
}

@media (max-width: 800px) {
  a {
    color: yellow
  }
}

参考：

Using postcss-cssnext

顧客駆動開発

世の中にはテスト駆動開発とかドメイン駆動開発とか様々な「〇〇駆動開発」がありますが、私の長年のキャリアの成果として生み出されデイリーなワークフローとして定着しているのが本日ご紹介する「顧客駆動開発」であります。

従来の「〇〇駆動開発」とちがい私が編み出した顧客駆動開発にはとくになんにも難しいことは一切ありません。

ただ顧客から電話やメールが来たことをきっかけとして思い出したかのように作業を進める、それが顧客駆動開発なのです。

ということで、今日もお客さんからの連絡を待ちながら一日が終わったのであります。

わかりやすい図