Pages

2016/08/23

梱包おしい!日本郵便

タイミングがあわずなかなか注文できなかったのだが、ようやくソフトウェアデザイン 2016年 09 月号 [雑誌]をアマゾンで注文。ところが、配送予定日が台風直撃となった。濡れてしまうかと思ったら、ビニールでラッピング。そこまでの対応は予想していなかったので、びっくり。
ただ、端のほうから染みてしまった。惜しい。


2016/08/02

ポケモンGOおすすめプレースタイル

あまりスマホを見ないでポケモンGOをプレイする

街中でスマホの画面を操作している人を本当によく見るようになった。以前から同じような位置ゲーでIngressがあったけど、やっているような操作をする人を街角で見かけることはあまりなかった。
ついつい画面に集中してしまうけど、あまり画面を見ないでプレイする設定があるので紹介してみる。

ネットストラップをスマホにつける

カプセルを投げたりポケストップで回したりと、操作するシーンが多い。手で持っているとそれだけ落としやすくなるので、手から滑り落ちても地面に激突しないよう、ネックストラップをつけることをお勧めする。

楽天でネックストラップを探す

Bluetoothヘッドホンを使う

ポケモンGOの設定画面で

  • 音楽→Off
  • 効果音→On
にすると、ポケストップに近づいた時やポケモンが現れた時に、音で知らせてくれる。なので、画面を見ながらウロウロする必要がなくなる。音はヘッドホンで聞けば良いのだが、スマホを頻繁に操作するので、ヘッドホンのコードが邪魔になる。
こういうときのために、Bluetoothがある。耳掛け式ヘッドフォン購入 | Hiroaki's blogには書いていないけど、Jabra DogTagデザイン Bluetoothステレオヘッドセット BT3030を使って、普通の耳掛け式ヘッドホンにつないでいる。bluetoothヘッドホンでいいのがないのであれば、こういったアダプターを使うのも手。

楽天でbluetooth イヤホンを探す

スマホを振動させる

設定画面で「振動」にチェックを入れておくと、ポケモンが現れた時にスマホがブルブルって震えて知らせてくれる。音を聞き逃してもブルブル震えて知らせてくれるので、これでバッチリ。

バッテリー節約のため、画面が消えるようにスマホを持つ

バッテリーセーバーをonにした場合、スマホを水平から少し向こうに傾けるように持つと、地図が消えてポケモンのロゴがうっすら表示された黒い画面になる。バッテリー節約の1つに画面を暗くするというのがあるけど、ポケモンGOでは少し向こうに傾けるだけでOK。音がしたりブルブル震えたりしてから画面を見れば、どこかにポケモンがいたりポケストップがあったりするので、プレイには困らない、はず。ARモードonでプレイしている人には無理だけど、そういうことをする人は、そもそもバッテリーをケチってはいけない。バッテリー2台持ちを検討しよう。充電を待っている時間をポケモン探しに振り分けた方がいいに決まっている。

画面の拡大、縮小をうまく使う

2本の指で画面をつまむようになぞると、より広い範囲が表示される。逆に押し拡げるようにすると、狭い範囲が拡大される。これをうまく使えば、遠くのポケモンを探すことができるし、ポケストップのそばにいてタッチしにくいポケモンも捕まえやすくなる。スマホの操作の1種だけど、こういった操作をうまく使って楽しくプレイしよう。カプセルが開かないとか、まだ荒削りの部分がある気がするけど、そのうち改善される、だろう。



2016/07/24

MacとWindowsでキーボードを共有するケーブル

MacとWindowsでキーボードとマウスを共有する

MacとWindowsを並べて使っている場合、1つのキーボードとマウスで両方とも操作できると便利だ。以前、Synergy復活 | Hiroaki's blogに書いたように、Synergyという共有ソフトを使用していた。ただ、バージョンによってはうまく動かず、案の定、MacをOS X El Capitanにアップグレードしたところ、動かなくなった。そこで、ソフトで共有するのは諦めて、MacとWindowsをお手軽接続することができる「KB-USB-LINK3M」を参考に、共有用のケーブルを購入することにした。

キーボード・マウス共有ケーブルKB-USB-LINK3M

サンワサプライ ドラッグ&ドロップ対応USB2.0リンクケーブル(Mac/Win対応) 1.8m KB-USB-LINK3Mはキーボードとマウスを共有するためのケーブルだ。Mac-Windowsだけでなく、Mac-Macでも、Windows-Windowsでも共有できるらしい。
今回は、Windows側のキーボード・マウスでMacも動かすことにした。

OS X El Captionで使うにはアップデートが必要

OS X El Captionで使うには、アップデートが必要らしい。ケーブルの根元に入っているであろうファームウェアを更新するのだろう。
更新手順はwww.sanwa.co.jp/support/download/driver/cable/link3mfw109/index.htmlにあるのだが、なぜだかアップデート用ファイルのリンク先が手順書のページになっており、ファイルの入手で迷子になってしまった。
正しい入手先は

Windows用
KB-USB-LINK3M のソフト(ドライバ)ダウンロード - サンワサプライ株式会社
Mac用
KB-USB-LINK3M のソフト(ドライバ)ダウンロード - サンワサプライ株式会社
である。
アップデートすると、古いMacでは使えなくなるらしい。更新手順の途中に記述がある。

アップデートはWindowsで行うべき

手順に従ってiMacでアップデートしてみたのだが、ケーブルを挿し直してもなぜか動かない。更新手順書にあるバージョン確認方法で確認したところ、手順書にあるバージョンにはなっていなかった。何度やってもバージョンが上がらないので、Macでのアップデートは断念。Windowsでアップデートしたところ、手順書通りのバージョンになった。ま、未だにMac版の扱いってこんなもんだよね。
これ、何度も挿したり抜いたりしないといけないので、USBがディスプレイの背面にしかないiMacでは結構大変だった。

「挿すだけ」は便利

Synergyの場合、共有相手のIPアドレスを設定する必要があったので、ネットワークの影響を受けているのか、設定の問題なのか、うまく動かない時の調査が面倒だった。また、環境の問題なのか、自動起動できず、再起動するたび手動でSynergyを起動させる必要があった。共有ケーブルだと挿すだけで済むし、マルチディスプレイだからといって別途費用がかかるわけでもないし、イイネ。



2016/07/22

ページオブジェクトパターンでブラウザテストを書け!Seleniumデザインパターン&ベストプラクティスを読んで

ブラウザテストツールとしてSeleniumが知られるようになってきて、3冊ほど本が出た。そのうち、O'Reillyから出ているSeleniumデザインパターン & ベストプラクティスを読んでみた。

概要

1章
Selenium IDEは結局使わない。1.6からが本番。本書ではテストをRubyで書いている。テストのフレームワークはTest::Unitを使っている。
2章
テストコードでありがちな問題。
3章
テストをリファクタリングしてみる。
4章
テスト用のデータをテストコードから分離する。
5章
テストの安定化。Webシステム特有の問題に対処する。
6章
ブラウザテストとは。ブラウザに表示されるか?クリックしたらどの画面に遷移するか?といった振る舞いのテストである。
7章
テストをPage Objectパターンに書き換える。
8章
テストを保守し、どういった方針で充実させていくか。

ブラウザテストはぺージオブジェクトパターンで作る

Seleniumは言語に依存しないため、各言語から使いやすくするためのバインディングが用意されている。使い方がシンプル(Seleniumの薄っすい話4:俺と非公式バインディング - Qiitaが分かりやすい)なため、非公式なバインディングを含め、様々な言語のバインディングが作られている。
ブラウザテストは振る舞いテストなので、テスト対象と同じ言語でテストを書く必要はない。だから、書きやすいと思う言語で書けば良い。

本書はRubytest::unitでテストを書いているが、他の言語で役に立たないということはない。むしろ、ページオブジェクトパターンの重要性の説明が本当の目的ではないか?
ただ、ページオブジェクトパターンでやろうとする事はどんなWebシステムのテストコードでもやることなので、本書のように一から作るのではなく、SitePrismのようなライブラリを使う方が効率的だろう。SitePrismに関する日本語の記事はあまり見かけないが、例えばSitePrismを使ってSelenium+Capybaraのテストをぺージオブジェクトパターンで書くなどがある。

目次より

目次
まえがき
監訳者まえがき
はじめに

1章 最初のテストを書く
    1.1 Selenium を選択する
        1.1.1 適材適所
        1.1.2 価格
        1.1.3 オープンソース
        1.1.4 柔軟性
    1.2 Record and Playback パターン
        1.2.1 Record and Playback パターンの利点
        1.2.2 Record and Playback パターンの欠点
    1.3 Selenium IDE に取り掛かる
        1.3.1 Selenium IDE のインストール
        1.3.2 最初のテストを記録する
        1.3.3 テストを保存する
    1.4 Selenium コマンドを理解する
        1.4.1 Selenese を読む
    1.5 Ruby とSelenese を比較する
        1.5.1 Selenium コマンドをさまざまな言語と比較する
    1.6 Selenium テストをRuby で書く
        1.6.1 Test::Unit を導入する
        1.6.2 アサートを導入する
        1.6.3 テストをインタラクティブにデバッグする
    1.7  まとめ

2章 Spaghetti パターン
    2.1 Spaghetti パターン
        2.1.1 Spaghetti パターンの利点
        2.1.2 Spaghetti パターンの欠点
    2.2 商品レビュー機能をテストする
        2.2.1 商品レビューテストに取り掛かる
        2.2.2 ページ上の要素を指定する
        2.2.3 ロケータ
        2.2.4 ロケータのコードを書く
        2.2.5 クリックとアサーションを実装する
        2.2.6 レビュー重複テスト
    2.3 失敗の理由
    2.4 Chain Linked パターン
    2.5 Big Ball of Mud パターン
    2.6 まとめ

3章 テストをリファクタリングする
    3.1 テストをリファクタリングする
    3.2 DRY テストパターン
        3.2.1 DRY テストパターンの利点
        3.2.2 DRY テストパターンの欠点
    3.3 Hermetic テストパターン1
        3.3.1 Hermetic テストパターンの利点
        3.3.2 Hermetic テストパターンの欠点
        3.3.3 テスト同士の依存関係を取り除く
    3.4 汎用的なDRY メソッドを作る
        3.4.1 汎用的なメソッドを使ってリファクタリングする
    3.5 ランダム実行順序原則
        3.5.1 ランダム実行順序原則の利点
        3.5.2 ランダム実行順序原則の欠点
    3.6 まとめ

4章 データ駆動テスト
    4.1 データの妥当性とアクセシビリティ
    4.2 入力データをハードコーディングする
        4.2.1 テストデータをテストから隠蔽する
    4.3 テストフィクスチャ
        4.3.1 フィクスチャデータをパースする
        4.3.2 テストにフィクスチャデータを使う
    4.4 API をフィクスチャデータのソースとして使う
    4.5 データスタブを使う
    4.6 Default Values パターン
        4.6.1 Default Values パターンの利点
        4.6.2 Default Values パターンの欠点
        4.6.3 Default Values パターンとfaker ライブラリを融合させる
    4.7 まとめ

5章 テストを安定させる
    5.1 安定を保つ文化カルチャを築く
        5.1.1 すばやく実行し、すばやく失敗させる
        5.1.2 できる限り頻繁に実行する
        5.1.3 クリーンで一貫性のある環境を保つ
        5.1.4 間違ったコード変更を捨てる
        5.1.5 安定したテストスイートを維持する
    5.2 Ajax を待つ
        5.2.1 Ajax 遅延なしにテストする
        5.2.2 明示的な遅延を使ってAjax フォームをテストする
    5.3 JavaScript アニメーションを待つ
    5.4 Action Wrapper パターン
        5.4.1 Action Wrapper パターンの利点
        5.4.2 Action Wrapper パターンの欠点
        5.4.3 Action Wrapper パターンを実装する
    5.5 Black Hole Proxy パターン
        5.5.1 Black Hole Proxy パターンの利点
        5.5.2 Black Hole Proxy パターンの欠点
        5.5.3 Black Hole Proxy パターンを実装する
    5.6 テストをテストしよう
    5.7 まとめ

6章 振る舞いをテストする
    6.1 振る舞い駆動開発
        6.1.1 BDD の利点
        6.1.2 BDD の欠点
    6.2 ショッピングカートの振る舞いをテストする
        6.2.1 ショッピングカートの振る舞いを記述する
        6.2.2 ステップ定義を書く
        6.2.3 BDD は自分のプロジェクトにふさわしいか?
    6.3 Cucumber
        6.3.1 フィーチャファイル
        6.3.2 ステップ定義ファイル
        6.3.3 config ディレクトリ
    6.4 Cucumber スイートを実行する
    6.5 Write Once, Test Everywhere パターン
        6.5.1 Write Once, Test Everywhere パターンの利点
        6.5.2 Write Once, Test Everywhere パターンの欠点
    6.6 モバイルサイトをテストする
        6.6.1 Selenium ラッパを更新する
        6.6.2 購入API をテストする
    6.7 まとめ

7章 Page Object パターン
    7.1 オブジェクトを理解する
        7.1.1 オブジェクトを文字で表現する
        7.1.2 プログラムでオブジェクトを表現する
        7.1.3 オブジェクトを使ってウェブページを表現する
    7.2 Page Object パターン
        7.2.1 Page Object パターンの利点
        7.2.2 Page Object パターンの欠点
    7.3 Page Object フレームワークを作る
        7.3.1 Page スーパークラスを作る
        7.3.2 サイドバーオブジェクトを実装する
        7.3.3 ページに自己検証を追加する
        7.3.4 個々のページクラスを実装する
        7.3.5 ウェブサイトの成長に合わせて、サイドバーオブジェクトを増やす
    7.4 Page Object フレームワークを使ってテストを実行する
        7.4.1 Test::Unit フレームワークでPage Object を使う
        7.4.2 別のテストフレームワークでPage Object を使う
    7.5 Test Tool Independence パターン
        7.5.1 Test Tool Independence パターンの利点
        7.5.2 Test Tool Independence パターンの欠点
    7.6 Page Object の正しい実装方法
        7.6.1 テストよりもページを賢くする
        7.6.2 ページよりもテストを賢くする
        7.6.3 継承の代わりにモジュールを使う
        7.6.4 Page Object にロジックを置く
    7.7 まとめ

8章 テストスイートを成長させる
    8.1 テストスイートを書くための戦略
        8.1.1 さまざまなタイプのテスト
        8.1.2 スモークテストスイート
        8.1.3 マネーパススイート
        8.1.4 新機能戦略
        8.1.5 バグ駆動戦略
        8.1.6 リグレッションスイート
        8.1.7 99% カバレッジスイート
    8.2 継続的インテグレーション
        8.2.1 テスト環境とテストノードを管理する
        8.2.2 Selenium Grid
        8.2.3 CI ツールを選ぶ
    8.3 FAQ
        8.3.1 どうやって複数のブラウザでテストするのですか?
        8.3.2 どのプログラミング言語でテストを書けば良いですか?
        8.3.3 Selenium を使ってJS 機能をテストすべきでしょうか?
        8.3.4 なぜヘッドレスブラウザを使うべきなのですか?
        8.3.5 私のチームではどのBDD ツールを使うべきでしょうか?
        8.3.6 パフォーマンステストにSelenium を使えますか?
    8.4 まとめ

付録A Selenium をはじめよう
    A.1 コンピュータをセットアップする
        A.1.1 コマンドラインインターフェイスを使う
    A.2 Ruby ランタイム環境を設定する
        A.2.1 Ruby をインストールする
        A.2.2 Firefox をインストールする
    A.3 テストクラスの命名規則を理解する
        A.3.1 ファイルを命名する
        A.3.2 クラスを命名する
        A.3.3 名前空間を理解する
        A.3.4 オブジェクト継承を示す
    A.4 まとめ

付録B Test::Unit によるデータ駆動テスト

索引


2016/07/01

Evernoteを有料プランにする前に1つだけ検討すべきこと

Evernoteはパッケージ版がお得

Evernote の価格プランの改定について - Evernote日本語版ブログが出た。この際だから有料プランにするというのであれば、実は、ソースネクストeSHOPでパッケージ版を購入するのがお得なのだ。

Evernote価格プラン改定の衝撃

Evernote の価格プランの改定について - Evernote日本語版ブログにあるように、無料のプランでは端末2台までしか使えなくなった。スマホ1台とPCかMacという組み合わせであれば問題ないが、「iPhoneの画面が小さく見づらいのでiPad miniも使っている」なんて場合、iPhone + iPad mini + PC/Mac の3台となってしまう。PC/MacはWeb版で我慢するという手もあるが、Evernoteのプログラムは立ち上げてすぐに使える状態になるので、Web版にするには惜しい。

GoogleノートブックからEvernoteに移行した過去

使いこなしている人には影響の大きい今回の価格プラン改定、有料プランを嫌って他サービスにデータを移すという流れもある。Microsoft OneNoteにはEvernoteからの移行ツールがあり(Windows版)、幾つかチェックボックスにチェックを入れるだけで、お任せでデータを移行できる。非常にお手軽なのだが、OneNoteにはタグがないため、複数のタグをつけるような使い方をしていたユーザは満足できるか疑問だ。

一方、Googleのノート系サービスはというと、過去にGoogleノートブックがあった。自分は、サービス終了でEvernoteにデータを移したという経緯があるため、Evernoteに「Google Notebook」というノートブックがある。現在はGoogle Keepというメモサービスがあるが、果たして、Evernoteの代わりができるだろうか。

有料プランでEvernoteを使い続けるのが現実的?

今回の価格プラン改定、ヘビーに使っている人ほど影響が大きい。使い勝手が変わるのは嫌なので、やむなく有料プランに切り替えるというユーザも多そうだ。これからも使い続けるのであれば、お得なパッケージ版を購入するということも、選択肢の1つに入れて良いだろう。




2016/06/24

「ピープルウエアを読みましたか?」採用面接で質問したい!

本当の対象読者

ピープルウエア(ピープルウェアではないのね)は、コードを書く人がどういった職場環境を求めているかを鋭く指摘した本である。いわゆるエンジニア向けの本に分類されているが、実は、総務や人事といったスタッフ部門、あるいは、マネージングする立場の人間が読まなければならない一冊である。


生産性を下げる要因

スタッフ部門の使命は何だ?

  • 業務が円滑に進むようにすること
  • 社員が働きやすい環境を作ること
ということではないか?

基本的に、スタッフ部門はコスト部門である。利益貢献を求められた場合、自分たちのコストを切り詰めるか、会社としての支出を削減することを考えるだろう。でも多くの場合、これらは直接収益を上げる部門に対して、

  • 本来スタッフ部門で対応すべき仕事を押し付ける
  • コスト削減という名の下に職場環境を悪化させ、作業効率の低下を招いている
といった事態を引き起こしているのではないだろうか。部分最適化に陥って、会社全体では効率が悪化しているのではないか?

生産性を比較

この本はいろいろとすごいのだが、その1つとして、実際に生産性を測定しているのがすごい。こういった測定は、プログラマーだけではなく、集中してフロー状態になる必要がある職種全部でやってもらわないと、「気むずかしくて文句の多い、面倒な人種」とプログラマーが思われてしまう。ま、フロー状態になる程集中して仕事したことのない奴が偉そうにしている日本では、測定結果を突きつけたところで変わるとは思えないのだが。

コードを書きやすい環境の会社かどうかを探る

転職活動に必ずある採用面接。1回目の面接では、人事・総務の人間が同席している or 面接官であることが多い。ピープルウエアを読んだかどうか、質問してみよう。質問ネタ1件だ。
人事・総務の人間は、従業員側の社員ではなく、会社側の社員だ。だから、「会社として」何を問題にしてどうしようとしているのかが聞けるはずだ。
果たして、コードを書きやすい職場になっているか?そういった職場にしようとしているのか?見落としがちだが、結構重要なことではないだろうか。

ピープルウエア 第3版

第1章 今日もどこかでトラブルが
第2章 チーズバーガーの生産販売マニュアル
第3章 ウィーンはきみを待っている
第4章 品質第一……時間さえ許せば
第5章 パーキンソンの法則の改訂
第6章 ガンによく効く?「ラエトライル」

第II部 オフィス環境と生産性

第7章 設備警察
第8章 プログラムは夜できる
第9章 オフィス投資を節約すると
ちょっと休憩 インテルメッツォ
第10章 頭脳労働時間 対 肉体労働時間
第11章 電話、電話、また電話
第12章 ドアの復権
第13章 オフィス環境進化論

第III部 人材を揃える

第14章 ホーンブロワー因子
第15章 リーダーシップについて話そう
第16章 ジャグラーを雇う
第17章 他者とうまくやっていく
第18章 幼年期の終わり
第19章 ここにいるのが楽しい
第20章 人的資産

第IV部 生産性の高いチームを育てる

第21章 全体は部分の和より大なり
第22章 ブラックチームの伝説
第23章 チーム殺し、7つの秘訣
第24章 続、チーム殺し
第25章 競争
第26章 スパゲティディナーの効果
第27章 裃を脱ぐ
第28章 チーム形成の不思議な化学反応

第V部 肥沃な土壌

第29章 自己修復システム
第30章 リスクとダンスを
第31章 会議、ひとりごと、対話
第32章 マネジメントの究極の罪
第33章 E(悪い)メール
第34章 変化を可能にする
第35章 組織の学習能力
第36章 コミュニティの形成

第VI部 きっとそこは楽しいところ

第37章 混乱と秩序
第38章 自由電子
第39章 眠れる巨人よ、目を覚ませ


2016/06/19

Ankerの充電器…発火騒ぎがあったのか

Amazonのタイムセールで安くなっていたので、Anker 24W 2ポート USB急速充電器 iPhone 6s, 6s Plus/iPad Pro, Air, mini/iPod touch/Nexus/Xperia/GALAXY 他対応 【PowerIQ & VoltageBoost 折畳式プラグ搭載】 (ブラック) A2021111をポチったのだが、別モデルで発火騒ぎが起きていた。早まったか…。
Hisakazu Hadaさんのツイート: "充電中にマジで火を吹いたアンカーの充電器。 誰も居なかったら、家が黒焦げですよ。。。 http://t.co/pEVdETB7Eu"

今回買ったモデルとは異なるモデルだし、心配しなくても大丈夫なのかな?
一応、開封の儀。
結構小さい。
Anker 24W 2ポート USB急速充電器 外観

ケーブルも買った。Anker 高耐久ナイロン Micro USB ケーブル 1.8m 金メッキコネクタ Android, Samsung, HTC, Nokia, Sony, その他のスマートフォン、タブレット用 (ブラック)


さすがにしっかりしている。P-01Dの付属ケーブルでもNexus5を急速充電できていたのだが、どうもUSBの接続がゆるく、充電しながら操作していると、いつのまにか切れて充電が止まっていることがあった。このケーブルは緩むこともない。