ねこ背は治る!

昔から猫背で、治るなら治りたいので読んでみた。人体の骨格や筋肉の作りに基づいた話は理論的でためになったが、スピリチュアルすぎるところもあった。

• 姿勢が悪いのは重心がずれているから。立て膝をついた姿勢だと大腿骨で身体を支えるので自然に背筋が伸びる。立っているときに同じことをすれば猫背は治る
• 上半身、大腿骨、すねの骨（内側の太い骨）、足の裏（中心ではなく踵の少し内側）が一直線になるように立つと、太い骨が体重を支えて安定し、背筋も自然に伸びる。無理に胸を張る必要はない。足の裏の重心がかかる位置が重要
• 座っているときも考え方は同じで、身体を骨盤の上にしっかり乗せて体重を支えれば自然に背筋が伸びる。そのためには、坐骨の位置を意識して、坐骨を外さないように一番安定する位置を見つけて重心をかける

これを読んで意識してみたら確かに自分の普段の姿勢は足の裏の重心が前寄りになっていて、前のめりになっており、倒れないように支える力が入っていた、ような気がする。大腿骨を意識して重心のずれを直すようにしたら、本当に自然に姿勢が良くなった（上半身のどこにも力を入れていないのに、目線がまっすぐ正面真横に向いた。猫背の姿勢だと目線は下に落ちる）

他にも、呼吸の深さを改善するために肺の大きさを意識させるとか、腕や脚の動きを改善するために肩甲骨や大腰筋を意識させるとか、どのレクチャーも非常にわかりやすく、即効性があった。特に肩甲骨には驚かされた。自分はもう十数年ほど左右の肩関節が弱く、ものを投げる動作や腕を回す動作をすると肩の関節が外れそうになってとても怖い思いをしてきた。が、肩甲骨を滑らせる意識をして腕を回してみたところ、あのいやな「ゴキッ」という感触が相当低減された。

このように、人体の骨格や筋肉についての事実に基づき、正しい知識を得ることで身体を無理なく自然に使えるようにし、姿勢が良くなったり筋力をより効率よく発揮できるようになり、結果として身体に良い、というロジックは納得感があった。何より、本を読みながらその場で実践してすぐ自分の身体で実感できるのがすごい。

一方で、気功やチャクラといったスピリチュアルな話は、はっきりいって怪しい感じがした。そうでない部分が非常に理論的なので、余計にそう感じた。気の持ちようです、みたいな話くらいまではわからなくもないのだが。

少し前から気になっていた本で、読みかけの本を読み終わったら買おうと思っていたが、最近話題の Kindle Unlimited にも対応していたのでそちらで利用した。 Kindle Unlimited を試してみたい・試しているが読みたい本が見つからない、という人には、二、三時間で読めるのでおすすめ。ただし、残念ながら Kindle for iPhone では利用できなかった。 Kindle Paperwhite なら古いモデルでも読めた。

ねこ背は治る! ──知るだけで体が改善する「4つの意識」

なお、これを一日意識して実践してみたら、普段使っていない筋肉を使ったからなのか、これまでと違う疲れというか違和感を感じた。特にお腹や背中のあたりの筋肉が、力を入れてはいないはずなのに、だいぶ使ったなぁ、という感覚があった。しばらく意識し続けて、慣れというか自然に鍛えられて疲れ違和感が無くなるかどうかみてみたい。

■

なんかダブって投稿されてた。このエントリの元の本文は http://blog.kyanny.me/entry/2016/08/04/035431 と同じでした。

今日は会議があって自分が担当の部分を三分くらい英語で喋った。新規プロジェクトの承認とかをする会議で、自分が提案したプロジェクトの概要を説明した。篭ってた会議室の音響が良かったのか、本人的には悪く無い感じで喋れてたと思う。原稿を用意せずにあのくらい即興で喋れるようでいたい。

はじめて学ぶソフトウェアのテスト技法

知識ゼロから学ぶソフトウェアテスト 【改訂版】を読んですぐに、もうちょっと王道な感じの本も読んでおこうと思って読み始めた。

Kindle 版で読み始めてだいぶ経ってから、会社の本棚にこの本が何冊も置いてあることを知った。二年ちょっと前に会社でソフトウェアテストの勉強会（読書会）というのが開催されていた時期があり、そのときのお題がこの本だった。当時はこういうトピックへの関心が薄かったので参加しておらず、買うときに気づかなかった。

丁寧に書いてあってわかりやすかった。テスト手法の説明が具体的なのが良い。理論的な部分と実践的な部分のバランスも良い。 IEEE とか ISO とかの話は自分が求めるものと少しずれていたので適当に流し読みするにとどめた。演習問題はちゃんと取り組んだほうが良いだろうなと思ったものの、プロのテスターになりたいわけではないので現時点ではそのスキルを磨く必要はないと考え、これもスキップした。直交表など、概念そのものを知らなかったものもあり、それを今すぐ実践で役立てられているわけではないものの、読んで良かったと思う。

はじめて学ぶソフトウェアのテスト技法

以下ハイライト。

• 一番本質的な部分は、「実際どうなっているか」と「本来はどうあるべきか」を比較するプロセスだということでしょう
• テストを実施する人たちは、無意識のうちに不合格にならないテストケースを選択する可能性があります
• この答えを理解するためには、オブジェクト指向の世界で言う契約による設計の考え方を理解する必要があります
• 契約によるテストは、上記の「契約による設計」の考え方にもとづいています。このアプローチでは、事前条件が満足された状況でのテストケースしか作成しましません
• 推測はできますが、「要件の推測」は、許容してよい行為ではありません
• しかし、テストの観点からはとても危険です。テーブルが誤って整理縮小されることは常にありえます。その場合、誤ったコードが書かれることになります。テストケースの設計には、整理縮小されていない状態のテーブルを常に利用すべきなのです
• 無作為な選択はサブセットを選ぶためのとても優れたアプローチになりうるが、やってみると本当に無作為に選ぶのは簡単でないことがわかる
• 直交表は、任意の個数のパラメータに合致するように作成することはできません
• あるテストで必要とされるよりも多くの列を持つ直交表を選択したときは、単純にその列を削除します。それでも配列は直交性を維持しています
• 不必要なセルを含む行を削除したくなりますが、削除してはいけません。直交性が失われてしまいま
• もし行を削除すると、それに対応するテストケースが省略されてしまいます。削除するのではなく、余分なセルを単純にどれかの有効値に変換してください
• よくある誤りは、１つの状態遷移図に複数の異なるエンティティを混在させることです。
• 状態遷移図ですべての遷移をテストするテストケースが、通常はカバレッジのレベルとして推奨できる。
• 状態遷移図は、システムが状態を持たないとき、あるいはシステムの外部からのリアルタイムのイベントに応答する必要がないときには、適用できません。
• テスト担当者がこれらの問題をシミュレートできる支援ツール Holodeckが開発されています。
• 一般的に、ホワイトボックステストは開発者が行う単体テストと同一視されています。必ずしも間違ってはいませんが、それはホワイトボックステストの１つの側面に過ぎません。
• ホワイトボックステストは、単なるコードのテストというよりも、パスのテストです。
• ジェーンはこんがりトースト娘だったけど、軽いバター風味のトーストなんかじゃなく、それどころかトースターの底で真っ黒こげの炭になって、こげたところをナイフでどんなに削ったってまだ下には炭のトーストが残っているようなありさまで、真冬の飢え死にしそうな鳥だって見向きもしないから、もうゴミ箱に捨てるしかないようなしろものだった。
• IEEE標準規格829-1988の“〝IEEE Standard for Software Test Documentation.”〟ほど、スクリプトテストを的確に要約したドキュメントはありません。
• ２．スクリプトテストはその定義上、柔軟性に欠けている。事前に作った筋書きに従う必要がある。テストの途中で何か興味深い現象を見つけた場合も、それをテスト不具合レポートには書くが、深く追跡することはしない。なぜならば、スクリプトにそうしろとは書いていないからで、多くの重要な欠陥がこのアプローチによって見逃される。
• ３．スクリプトテストは、しばしばテストのスキルを低下させる。
• 次に行うテストがその前のテストの結果に何かしら依存するのであれば、ある程度の探索的テストを行っていると言える。
• 「我々は、計画を学習プロセスとしてとらえるべきである。すなわち、状況の理解を改善する心理的な準備行動なのである」
• James Whittakerの著書“〝How to Break Software”〟は、テスト担当者にとって大変参考になります。探索的テストの提唱者は「探索」という行為を推奨していますが、Whittakerのこの本は「どこを探索すればよいか」を教えてくれるのです
• 忘れてならないのは、テスト担当者としての私たちの役目は、製品を出荷するリスクについて経営陣に情報を与えることだという点です

Authy

二要素認証には以前から Authy を使っている。マルチデバイス対応は便利だし、 Google Authenticator の例もある。

パスワード管理には 1Password を使っており、これが 2FA にも対応しているのでまとめてしまおうかとも思ったが、 2 要素認証に 1Password を使うのはよく考えてから という記事を読んで思いとどまった。

同じような理由で、 Authy の Chrome アプリケーションを利用するのもやめた。これは Authy のデスクトップ版アプリケーションで、モバイル端末に手を伸ばさなくても 2FA 認証を済ませられるのでとても便利なのだが、「二要素」という部分をいくぶん spoil してしまうと思ったので、あえて不便なほうを選んだ。

Authy をマルチデバイスで利用するためには Authy のアカウントを別途作成する必要がある。モバイルデバイスを紛失したときにこのアカウントにログインして復元ができたら便利だと思うが、 Chrome アプリ版 Authy を再インストールして起動すると携帯電話番号の入力を求められたので、緊急時にデスクトップだけで 2FA の突破口をでっち上げるのは難しそうだ。それができてしまっては 2FA の意義を損なうので、不便で当然という面はあるが。

---

余談だが、 2FA のバックアップコードの管理方法には頭を悩ませている。いまのところ Evernote と Dropbox と 1Password のメモ（そこに保存するなんてとんでもない！）にそれぞれ同じものを保存しているが、探しづらいし使用済みかどうかも判別しづらい。バックアップコードの管理に特化したアプリなりサービスなりが出てきてもいいのにな、と思う（預けるのはちょっと勇気がいるが）

最近のポケモンGO

メダルのなかでは「つりびと」が一番好き。

まだレベル11。だが、自分が楽しめる遊び方を発見しつつある気がする。

• ジムバトルはしない。どうせ勝てないし、競って負けて心身が疲弊するのはまっぴらだ
• 強化はしない。ジムバトルをしないので強化しても意味がない
• 進化も頑張らない。どうせレアポケモン（のアメ）なんてそうそうゲットできないし、レベルアップを急ぐ理由もない
• ゲットしたポケモンは原則すべて博士に送る（ジムバトルをしないので図鑑から出てこなくてok）かわいいポケモンは例外として手元に置くこともある
• メダルはあくまで中間チェックポイント。達成回数を積み上げていくことに楽しみを見出す。メダルコンプは目指さない（ジムバトルをしないのでコンプできない）
• ほしのすなとアメを消費しなくなるので逆に貯めることに楽しみを見出す。目指せカンスト
• ポケモンを探しに行かない。「ウォーキング中たまに投げわゲームで遊べるフィットネストラッカーアプリ」くらいのスタンス
• 卵は積極的に割っていく。「フィットネストラッカーアプリの微妙なアチーブメントに比べたらなんぼかマシ」くらいの期待値で、射幸性の低い卵ガチャでのんびり図鑑を埋めていく（ガチャ扱いなので孵化装置が課金ポイント）

結論として、「自分の個人記録を伸ばしていく」という部分に楽しみを見出すプレイスタイルが合っていそう。

---

Ingress に比べると、明らかにこっちのほうが楽しめている。一人で黙々と、マイペースでやり込める要素が多いのかもしれない。というか Ingress が、肉体だけでなく精神もインドア派な人には楽しむのが難しいのかもしれない。他人と交流とか協力とか、そういうのが嫌いだからゲームで遊んでるんだろうが、っていう、ね（そして一人で黙々とプレイした結果が報われてる手応えの有無にも双方でけっこうな開きがありそう）