中年エンジニアの開発と生活の日々

中年エンジニアがソフトウェア開発や日々の生活で得た知見の備忘録

自転車の手袋いろいろ

最近、めっきり寒くなってきました。

寒くなってくると自転車乗りにとっての必需品が手袋ではないでしょうか?手袋なんてユニクロのやつで十分という話もあるかもしれませんが、自転車用の手袋について紹介してみたいと思います。

手袋の種類

自転車用の手袋といっても、目的によって何種類かあります。ロードバイクの指切りグローブのように、落車したときの保護や掌の痛み対策など、防寒以外の目的でつけることもあります。ただ、ここでは防寒用に絞ってタイプ分けに紹介したいと思います。

タイプ1:メッシュグローブ

風を通してしまうタイプのメッシュのグローブです。 f:id:munacky:20171130184449j:plain 通気性があるため、春先や秋口には向いていますが、この時期だともう寒くて辛いです。 年間で春秋合わせて2か月くらいしか出番がないので、自分の周りに使っている人はあまりいませんが、個人的には重宝しています。

タイプ2:防風グローブ(手首無し)

風を通さない素材でできています。 f:id:munacky:20171130184504j:plain 真冬でもそこそこ大丈夫です。手首の覆いがないタイプなので、どんな洋服と合わせることができます。ただし、袖口がむき出しなので、マウンテンバイクなどアップライトな乗車姿勢でフラットバーのハンドルの自転車に乗るにはいいのですが、ドロップハンドルだと風が吹き込んできて辛いです。

タイプ3:防風グローブ(手首あり)

風を通さないのは上のグローブと同じですが、仮面ライダーのグローブのように手首まで覆われています。 f:id:munacky:20171130184510j:plain このグローブであれば、ドロップハンドルで下ハンドルを持っても袖口から風が入り込んでくることはありません。 ただ、袖をグローブの中に入れる必要があるため、厚手のダウンジャケットやコートだと装着することが難しいです。

手袋のサイズ

自転車用の手袋は結構細かくサイズが分かれています。国内メーカーであれば、S、M、L、XL の4段階くらいあります。また、サイズはメーカーによってまちまちだったり、素材によってフィット感が違うので、最初に買う手袋は必ず試着することをお勧めします。

サイズ以外に気を付けたいこと

サイズ以外に気を付けたいことですが、実際にハンドルを握って感触を確かめられることができれば、最善です。とくに、シフトチェンジなどを行ってみて違和感がないことを確認しましょう。実店舗で試乗車などがあるところでお願いしてみるのが良いと思います。

まとめ

  • 冬の自転車に手袋は必須
  • 自分のスタイルに合った手袋をチョイスしよう
  • サイズ合わせは実物で
  • 実際に装着して、ハンドルを握ってみよう

指先が冷えると、せっかくの楽しい自転車ライフが辛いものになってしまいます。自分にベストな手袋を選んで、冬を楽しく乗り切りましょう。

ハンドポンプに見るロードとMTBの違い

自転車に乗るときにハンドポンプを携帯していますか?

自転車に長距離乗る方は出先のパンクに備えて、スペアチューブとハンドポンプ、もしくはCO2ボンベなどを携帯していると思われます。自分の場合、毎日往復で15kmほど通勤で乗っていますが、年に1度くらいパンクに見舞われます。

マウンテンバイクの乗り始めて、ハンドポンプの機能の違いについて改めて意識したので紹介してみます。

ロードバイクとマウンテンバイクのハンドポンプへの要件の違い

ロードバイクとマウンテンバイクのポンプに求められる機能が異なります。

  • ロードバイクではとにかく高圧(7bar以上)に入れられる必要がある。が入れるエアボリュームはマウンテンバイクほどではない
  • マウンテンバイクではそこまでの高圧は不要(2~4barあたり)。ただし、大量の空気をタイヤに送り込む必要がある。

というわけで、ロードでは高圧の空気が入れられるもの。マウンテンバイクでは1回のポンピングで大量の空気が送り込めるものが向いています。

見た目でわかるハンドポンプ傾向

ハンドポンプはシリンダーなので、入れられる空気圧はシリンダーが細い(つまり、断面積が小さい)ほど高くなります。一方でシリンダーが細くなると、1回のポンピングで入れられる空気が少なくなります。

つまり、ロード用はシリンダーが細く、マウンテンバイク用はシリンダーが太くなります。

f:id:munacky:20171116183436j:plain

左側がロードバイク用、右側がマウンテンバイク用です。シリンダーの太さの違いが判るでしょうか?ロードバイク用のほうはシリンダーの細さからくる空気量の少なさを補うため、長くなっています。

左のポンプは 9 barまで、右のポンプは 5 barまで対応しています。ロードバイクに乗っている人が右のポンプを買ってしまうと、必要な空気圧まで空気を入れることができません。逆に左のポンプでマウンテンバイクに空気を入れると、すごい数のポンピングが必要になります。

ちなみに、右側のポンプはデュアルアクションになっていて、ポンプを伸ばしても縮めても空気を送り込めることができます。

本来なら、一回のポンピングで送り込める空気量など説明書に欲しいところではありますが、あまり書かれていないのが現状です。

まとめ

  • 自転車に長距離乗るなら、スペアチューブとハンドポンプを携帯しよう
  • ハンドポンプを購入するときは、自分が必要としているタイプを選んで買おう
  • 特に、ハンドポンプの対応空気圧のチェックをしっかりと

 

XCode 9 で今までのプロビジョニングプロファイルが使えなくなったお話

XCode 9 がリリースされて、しばらく立ちますが、導入当初、プロビジョニングプロファイルが原因でパッケージングに失敗する問題に直面しましたので、その話を書こうと思います。

このお話は、CI サービスなどで fastlanne を使用していると遭遇する問題なのですが、あまり日本語の情報が無かったのでまとめてみました。

現象

fastlane で Adhoc 版を作成しようとすると以下のエラーメッセージが表示されて、ビルドに失敗します。

[13:49:15]: ▸ === BUILD TARGET MyApp OF PROJECT MyApp WITH CONFIGURATION Release ===
[13:49:15]: ▸ Check dependencies
[13:49:15]: ▸ Code Signing Error: Provisioning profile "XC iOS Ad Hoc: com.hogehoge.myapp" is Xcode managed, but signing settings require a manually managed profile.
[13:49:15]: ▸ Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 11.0'
[13:49:15]: 
[13:49:15]: ⬆️  Check out the few lines of raw `xcodebuild` output above for potential hints on how to solve this error

原因

自分の CI 環境では Fastlane を使用してビルドしていますが、fastlane はコードの自動署名に対応していないため、ビルドの際には一時的にプロジェクトのコード署名設定をマニュアルにしています。 XCode9 の xcode build は自動署名用のプロビジョニングプロファイルを手動で設定するとエラーにするように挙動が変わっていました。どうも XCode で作成したプロビジョニングプロファイルはそのままでは手動署名に使用できないようにしているようです。

そして、XCode で作成したプロビジョニングプロファイルかどうかはプロファイルの名称が XC から始まるかどうかで判定しているようです。

対応方法

本来ならプロビジョニングプロファイルを作成し直すのでしょうが、developer.apple.com のサイトでプロビジョニングプロファイルの名称を変更して XC をとれば、署名ができるようになりました。

まとめ

XC で始まる名称を持つプロビジョニングプロファイルは XCode9 ではマニュアル署名用に使用できなくなりました。 プロビジョニングプロファイルを作成し直すか、名称を変更して、XC から始まらない名称をつけてあげればビルドできるようになります。

なにかのお役に立てれば...

鮎川麻弥LIVE for followers vol.6 - いい音 イイネ!

鮎川麻弥さんをご存じですか?

サンライズアニメに詳しい人なら、「Zガンダムの主題歌を歌っていた人ですね」とピンとくるかもしれません。先日、鮎川麻弥さんのライブが開催され、そこに参加してきました。

f:id:munacky:20171113233358j:plain

恥ずかしながら、鮎川麻弥さんの曲を聴き始めたのは、高校生の頃にやっていた、Zガンダムの再放送で、エンディングの「星空の Believe」がとても気に入ってしまい、レコードを借りてテープにダビングして聞きまくっていたのが最初です。レコードって、アナログのあれですよ。

その後、お小遣いなどで CD を買い漁り、ずっと聞き続けていたのですが、ライブ (当時はコンサートと呼ばれていた) などには行かずに、ずっと曲を聴くだけでした。

たまたま、数年前に麻弥さんの現況を調べたら芸能活動を継続していることがわかり、ライブに参加したいと思っていました。しばらく、日程の都合が合わず、参加を断念していましたが、今年はライブの日程が上手く調整できたこともあり、念願の参加を果たしました。ファン歴ほぼ、30年にして初のライブ参加です。

ライブの場所はLaDonna原宿というライブハウスとレストランが合体したような施設で、食事やお酒を楽しみながらライブが担当できるという素敵な場所でした。

www.la-donna.jp

会場に入ったら、自分を含めて、観客がいい年のおっさんばっかり。女性の方も若干いらっしゃいましたが、凄く濃い空間でした。たまたま隣の人と少し話す機会がありましたが、初参加と言うことを伝えると、少し驚かれたようでした。まあ、ファン歴が長い人が多いからなぁ。でも、隣の人はスーパーロボット魂から入って、ソロライブは今年から参加とのこと…

ライブは3部構成になっており、1部はオリジナル曲、2部はアニソンとクイズコーナー、3部はまたオリジナル曲でエンディングになりました。バンドの構成はギターとピアノ・キーボードのアコースティックな構成となっており、麻弥さんの魅力をじっくりと堪能できる構成になっていました。

ファン歴30年目にして初めて生鮎川さん、すでにそこそこのお歳ですが、そんなことはみじんも感じさせず、張りのある声でバラードはしっとりと、アニソンはエネルギッシュに歌い上げました。こちとら、いい年のおっさんですが、あまりにも感激して、泣いてしましました。

ああ、生鮎川さんええなぁ~。至福の時を過ごしました。ただ、昔の曲が多いんで曲を聴きながら昔のいろいろな若気の至りなど恥ずかしい思い出がよみがえって、もじもじします。

ライブ終了後はサイン&握手会があって、会場で買った CD にサインをいただきました。

f:id:munacky:20171113233402j:plain

今から、鮎川麻弥さんの楽曲を聴いてみたいなら

すでに、当時の CD は絶版になっているのですが、ベスト盤なら今でも入手可能です。おすすめはこれ。

麻弥さんのベスト盤はアニソン主体のモノが多いのですが、このベスト盤はアニソンとオリジナル曲の2枚組になっていて、貴重なオリジナル曲を聞くことができます。そして、ここに収録されたオリジナル曲がイイ!

まとめ

つらつらと、しょうも無いイベントレポートみたいになってしまいましたが、何を言いたいのかというと…

  • 鮎川麻弥さんはまだ現役です。それもピチピチの。
  • 鮎川さんはアニソンが有名だけど、オリジナルのバラードがイイ!
  • 来年もまた行くぞ~
  • 興味がある方は Reply を買おう

と言ったところでしょうか…

27.5 プラスの MTB を日常で使ってみる

先日、Chain Reaction Cycles で 27.5プラスのマウンテンバイクを購入して、しばらく待ち乗りメインで使ってみました。

良いところ、辛いところが見えてきたので、少し紹介してみたいと思います。

27.5プラスとは

27.5プラスというのはMTBの規格(というか、カテゴリ)の名称で、27.5インチのホイールに2.8~3.0インチの太さのタイヤを装着したものです。最近はMTBがマイナーになっているのであまり浸透していないかもしれませんが、オフロードでの乗り心地向上のために最近になってメーカーが力を入れてきているカテゴリです。

MTB のカテゴリについては以下のリンクが詳しいです。

愛車紹介

今回、購入したのは Fuji の Big Horn 2016 です。型落ちモデルを通販で安く買いました。

f:id:munacky:20171016191328j:plain

写真を見るとわかるかもしれませんが、フロントはシングルでリア10速(11-36)です。フロントシングルは最近の流行りですが、昨年モデルだけあって、リアが10速(11-36)なのが若干物足りない気がします。今年モデルだとリアは11速(11-42)などが流行りです。このギア比でも急な登りはそこそこ登り切れます。(下りで足が回り切りますが)

f:id:munacky:20171016192304j:plain

ナローワイドのフロントシングルは最近の流行です。写真をよく見てもらえるとわかるかもしれませんが、歯がチェーンのコマに合わせて狭い歯(ナロー)と広い歯(ワイド)が交互になっていて、チェーンががっつりはまって、脱落しにくいです。またそれだけでなく、最近のMTBは変速機以外にもサスペンションロックやドロッパーシートポストなどのスイッチが増え、ハンドル周りをシンプルにしたいという要望があるようです。

f:id:munacky:20171020100155j:plain

これは、ハンドルの写真ですが、右側にはブレーキ、変速機、ベルがあり、左側にはブレーキ、サスペンションロックのスイッチ、ドロッパーシートポストのスイッチがあります。左側にフロントの変速機をつけてしまうとかなり狭くなってしまいます。

そして特筆すべきは27.5プラスの特徴というべき、タイヤです。

f:id:munacky:20171016192737j:plain

比較に350mlの缶を並べてみました。ほぼ、同じ太さなのが分かると思います。この太いタイヤのおかげで、リアサスペンションがなくても、ダート程度ならかなり安定して走ります。

日常の使用感

前置きが長くなりましたが、日常で使ってどうなのよ?というお話に移ります。 このタイヤなので、巡航速度は22km/h程度で、流して気持ちいいのは20km/hあたりです。正直、ママチャリより少し早いくらい。クロスバイクより遅いです。細かいことは気にしないでのんびりと流すのが気持ちいいです。

でも、砂利道や道路のギャップ・グレーチングでも安定した走行が可能になります。特に下りでは抜群の安定感を発揮します。また、意外と車重はかるくギア比も相まって、15% くらいの斜度でも普通に登れます。段差も強いです。

この自転車で一番困っていることは太いタイヤのおかげでサイクルラックに入らないことです。駅やスーパーの駐輪場に気軽に止めにくいので、かなり困っています。駅の駐輪場に止めるときは係の人にお願いして、電動アシスト自転車コーナーに置かせてもらっています。

また、パンクしにくそうなのですが、念のため、スペアチューブはサドルバッグに入れています。3インチ用なので、とても重いです。

まとめ

27.5 プラスの MTB はスピードを追求するという乗り物ではなく、乗り味を楽しむ自転車ということはよく言われていますが、それは街乗りでも同様のようです。この自転車に乗り始めて、砂利道を好んで乗るようになりました。そのうち、山に行ってみたいです。

iOSとAndroidのAppiumスクリプトを共通化する (その2)

前回、iOSAndroid の Appium スクリプトを共通化するお話を書きました。前回、分量の関係で書けませんでしたが、iOSAndroidスクリプトを共通化する場合、避けて通れない話があります。

iOSAndroid で find_element() の挙動が違うお話

iOSAndroid で Appium のスクリプトを共通化するに当たって困るパターンのうち、「Appium の API は同じなのにテストフレームワークの違いによって、挙動が異なる」パターンに分類されます。

accessibility id を 使用して find_element() するさいに、androidiOS で以下のような違いがあります。

  • iOS では画面外の UI コントロールが find_element() で見つけることができる
    • このとき、UI コントロールの displayed? の値は false になっている
  • Android では画面外の UI コントロールのIDを指定して find_element() を呼び出すと見つからず、NoSuchElementError が発生する
    • 当たり前だが、displayed? の値は常に true になる

と、言うわけで、UIコントロールの属性をチェックする際に Android ではいちいち画面をスクロールさせなければなりません。

そんなわけで、UI コントロールを探す場合、Android を念頭に置き、スクロールしながら探すようなロジックを組み込む必要があります。

こんなコードで対応してみました

  def checkTextValuesWithScroll(id, value)
    startX = @driver.manage.window.size.width / 2
    startY = @driver.manage.window.size.height * 0.65
    offsetY = @driver.manage.window.size.height * 0.53

    retryCounter = 0
    begin
        element = find_element(:accessibility_id, id)
    rescue Selenium::WebDriver::Error::NoSuchElementError
        #画面をスクロールさせてもう一度取り直す
        puts "finding #{textInfo['id']}...retry:#{retryCounter}"
        Appium::TouchAction.new.swipe(start_x: startX, start_y: startY, offset_x: 0, offset_y: - offsetY, end_x: startX, end_y: startY - offsetY, duration: 1000).perform
        sleep 1
        retryCounter += 1
        # 10回までリトライする
        retry if retryCounter < 11
    end

    expect(element.text).to eq value
  end

この例では指定した id のUI要素が value のテキストを持っているかチェックしています。 id の値で find_element() を呼び出して、要素が見つからない場合は画面をスクロールさせて再度リトライするようにしています。 画面をスクロールさせるためのパラメータは画面全体の座標から計算していますが、スクロールさせる View の大きさと位置から計算する必要があるかもしれません。 10回までリトライするようにしていますが、この回数はアプリの縦の画面サイズに応じて適宜変える必要があります。

このサンプルでは Android ではスクロールしながら UI コントロールを探しますし、iOS ではスクロールせずに UI の文字列をチェックします。

iOSとAndroidのAppiumスクリプトを共通化する

iOSAndroid のクロス開発を行っていますが、双方のプラットフォームで作成したアプリケーションを Appium を使用してシステム検証を行っています。

Appium はマルチプラットフォームのモバイルアプリケーションテストフレームワークなので、iOSAndroid も Appium で同じように動かすことができます。

ただ、実際にテストスクリプトを共通化しようとすると、いくつか気をつける箇所が出てきます。

具体的には2つのパターンがあります。 - iOSAndroid で Appium の API が異なる - API は同じだけれども、Appium の挙動が異なる

Swipe などの UI 操作

Swipe などの UI 操作は前者で iOSAndroidAPI が異なります。

iOSでは始点の座標と移動量をパラメータとして渡します

Appium::TouchAction.new.swipe(start_x: startX, start_y: startY, offset_x: offsetX, offset_y: offsetY,  duration: 1000).perform

Android では始点の座標と終点の座標を渡します。

Appium::TouchAction.new.swipe(start_x: startX, start_y: startY, end_x: endX, end_y: startY, duration: 1000).perform

なお、両方のパラメータを設定してもOKです。必要ないものは無視されます。両方とも設定することによって、どちらでも動くコードになります。

Appium::TouchAction.new.swipe(start_x: startX, start_y: startY, offset_x: offsetX, offset_y: offsetY, end_x: endX, end_y: startY, duration: 1000).perform

設定する座標系は iOSAndroid で異なりますので 操作の対象となる View などから取得するのが良いでしょう。

まとめ

Appium でも API レベルで AndroidiOS で異なるものがある

UI コントロールの取得

Appium では find_emenet() を使用して、UI パーツにアクセスします。このとき、ID で検索するか View の ツリー構造の xpath で検索することができます。

AndroidiOS ではどうしても View の構造などが合わないため、UIコントロールを find_element() で取得する際に xpath を使用すると、iOSAndroid で同じ値にはなりません。そのため、UI に ID を埋め込み、ID を使用して find_element() を実行して UI パーツにアクセスする必要があります。

iOS では Accessibility Identifier、 Android では View Tag などに埋め込むことができますが、Appium の制限事項で 2017年7月の時点では Android アプリの View Tag を使用して find_element() を使用することができません。そのため、現状の Android 版では Content Description に検証用の ID を埋め込んでいます。

まとめ

iOSAndroid で同じ UI パーツに対して同じ ID を割り当てる。そして Appium からアクセスする際は ID で検索する

表示文字列の値の取得方法

iOS では UI 上に表示している文字列を取得する際に、文字の配置されている View の text プロパティとして値が取得できるのに、Android では View の text プロパティとして取得することができません。

iOS でも Android でも表示文字のコントロールの text プロパティから取得することができます。一手間かかりますが、Android の流儀でテキストの表示文字の値を取得します。

まとめ

表示文字の値を取得する場合は表示文字列に ID を割り当てて、テキストコントロールから直に値をとる

最後に

いくつか AndroidiOS をクロス開発する際に Appium で効率的にテストスクリプトを書くためのトピックをまとめてみました。お役に立てればうれしいです。