クロモリフレームの耐久性・故障・サビ・飛行機輪行と長期使用

今年の初頭にクロモリ・ロードバイクの Raleigh Carlton N の GARMIN/Strava 上の総走行距離が 10,000km を越えました。

私の場合、自転車を始めてから GARMIN を導入するまでに数年の間があるので、本当の総走行距離は 17,000km から 19,000km ぐらいまでの間に収まると思います。

つまり 10,000mi 超えでもあります。

これだけの距離と時間を走っていると、注意点と故障しやすい部位が自然と分かるようになります。






ただし、クロモリフレームそのものはさすがに丈夫で、現在の走行距離の3倍ぐらいの距離は何の問題もなく走れそうです。

私の場合、数ヶ月に1度の頻度で飛行機に載せて輪行までしていますが、空港で放り投げられてもチューブがへこむぐらいで、破断して走行不能になることもありません。

雨も雪も融雪剤(塩化カルシウム)も、もちろん何度も経験しています。それどころか、腐食性の硫黄ガスの生じる火山地帯も繰り返し走行しています。

経験したことがないは海水(水没)ぐらいでしょうか。

それぐらい信用しているフレームですけれども、サビないということはありません。

半年に一度の頻度で某錆スプレーを吹き付けていても、ボルトやケーブル受けなどの塗装の剥がれやすいところを中心にサビは生じます。

まあ、ボルトやワイヤーはカーボンフレームでも錆びる(ドリンクホルダーを固定するボルトを外してみると錆が出てることが多いですよ)ので仕方がないところがあります。

ちょっと困ったのはボトムブラケットシェル下部にあるケーブルガイドのボルトです。

位置的にチューブ内に入り込んだ水が貯まるところですし、道路上の水溜りなどの汚れが付着しやすいところなので、もしフレームが錆びて使い物にならなくなるとしたら、ここから錆が広がったときだと感じています。

最近のフレームがケーブル内装している理由の一つにはケーブルガイドを露出させないことも理由の一つにあるのかもしれません。

じつは私はシティサイクルを過去に3台乗りつぶしていて、その際はいずれもボトムブラケットシェルとシートチューブ、ダウンチューブとヘッドチューブの溶接部分を破断させています。

ダイヤモンドフレームではボトムブラケットとヘッドチューブあたりに大きな負荷がかかるらしく、この辺りが損耗で劣化したり、錆びて強度が落ちてくると危ないですね。

逆に言えば、もっとも負荷がかかるところが大丈夫であれば、そうそう壊れたりはしないということでもあります。

まとめますと、エントリーモデルで安価なわりに丈夫で長持ちしますし、同サイズの他の車種よりも直進安定性があり、それなりに速く走れて、遊びにも使えるので、とても良い買い物だったと思っています。

その上で 10,000km 走った上での不満点を敢えて述べていきます。ここに注意していくと、さらに使いやすさが上がります。




使用上の不満

じつは不満の 90% ぐらいは完成車に付属してくる Tiagra (Tiagra 4600) というグループセットに由来します。

Raleigh Carlton-N CRN は完成車として販売されているバイクの中では、極めて良いパーツ (Tiagra) が付いてくるので、そのままでも不便なく乗り続けることが可能です。

唯一の例外は付属品のブレーキで、ここだけはロードバイクの走行性能と比較して制動力が不足ぎみなので、事故を起こす前に早急に交換したほうが良いです。

同じ SHIMANO の上位モデル(金属プレート付きブレーキパッド)に交換するだけで快適性や安心感が別物のように変わります。

当然ながら走行距離が長くなると疲労感にも影響しますし、ダウンヒルでの安全性も向上します。制動力が低くて良いことは一つもありません。

ブレーキを除いては Tiagra も良い機材なので、性能そのものに対する不満はあまり感じません。

不満を感じさせるのは現行の 10 速 (後輪の歯車が10枚) という仕様です。

昔のロードバイクは後輪の歯車が 8 枚ぐらいしかなかったのですが、徐々に増え続けて最近では 12 枚のモデルも出てきています。

2019年現在の主流は圧倒的に 11 枚でして、チェーンもスプロケットもホイールも何もかもが 11 速を前提にできています。

そんな中で数年前から 10 速に取り残されている少数派グループセットの代表が Tiagra なのです。

噂されている今年のモデルチェンジで 11 速化されてしまえば、現行 (4700) グループセットはますます少数派になり、10速を維持したままであれば大多数とミッシングリンクも共有できない不便な現状を維持することになります。

ロードバイクを2台以上もっていたり、パーツのアップグレードを考えるときに、ほぼ独自規格と化している10速仕様が足を引っ張ります。

11速に比べて何かしらの利点があればよいのですが、チェーンチェッカーで定期的に計測しても11速に比較してチェーンの耐久性があるわけでもなく、11速を前提に設計されたホイールの性能が向上するわけでもなく、積極的に選ぶ理由が見当たりません。

ある程度、使い込んだ時点で11速に載せ替えることを前提に、消耗品も最低限しかストックしていませんけれども、総走行距離 17,000km ぐらいでは壊れる気配すらありませんので処理に困ります。

グループセット(ほぼブレーキと10速)に対する不満を除けば、気になる点はそれほど多くはありません。

その数少ない不満がシートクランプです。

Raleigh Carlton のシートクランプ径は特殊です。専門店に赴いても、まず在庫が存在しないと考えてください。

私のように頻繁に飛行機に乗せて、その度にシートポストを引き抜いたりしていなければ、それほど壊れる部品でもないですけど、いざ壊れてしまうと代替品が見つかりません。

もっとも良いのは ARAYA の取扱店でシートクランプの交換部品を取り寄せることで、この場合は1週間ほどで入手が可能です。金額は1,500円前後であったと記憶しています。

試したところ Φ30.0 mm のシートクランプであれば互換性が有りますけれども、これ自体が入手困難なので台湾から個人輸入したりしない限り、普通には購入できないと考えてください。

なお特殊なのはシートクランプのみで、ヘッドセットは 42mm 外径の一般用で交換部品を探せますし、ボトムブラケットは最も安心感の高い SHIMANO のスレッド式が使用できます。

わりと走行性能も高くて丈夫な割に整備性が高いのが一番の魅力になっていると思います。

定期的に部品を交換しながら、あと 40,000km ぐらいは乗りたいですね。

Knex.js で日付範囲指定の検索したり・バッチ処理で更新や削除したり

最近 (今年の2月ぐらいに) 興味深い記事を読みました。

クエリビルダを利用する明確な利点は存在しないという内容です。ここ3年ぐらいの間に割と聞かれるようになったやつです※。

Stop using Knex.js — Using SQL query builder is an anti-pattern
https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf410349856c

その趣旨を一言で述べると、動的に作成される必要があるクエリにのみ例外的に Knex.js を使用して、それ以外は直に SQL を書いたほうが良いというもの。

Knex.js というのは node.js において最もよく使われている SQL クエリビルダで、私も手を抜くときに使っています。

MySQL にも PostgreSQL にも SQLite3 にも (不完全ながら DB2 にも) 対応しており、SQL を知っている人にとっては直感的に使えます。

何が良いというわけではないのですけれども、無意識に自然と使用していることが多いです。 SQL を直書きするときでさえ、気がつくと knex.raw() 関数を使っています。

しかし、データベースの一部の機能が使用できない、あるいは使用できないという誤解に基づき酷評されている場面を見たことがあります。

ここからが上の記事の内容なのですが、SQL で実現可能なことをクエリビルダで実現するために二度の学習が必要となり、knex.js に詳しい人も (SQLに詳しい人に比べれば) 少ないので問題が起こった際に調べる手間が大きいことが難点です。

そして、バッチ更新のように利用頻度が高いものが、公式ドキュメントに書かれていない (いま再確認したら batchInsert は書かれていましたけど) ので、それも誤解の一因になっているのかと思いました。

Knex.js – A SQL Query Builder for Javascript / Latest Release: 0.16.3
https://knexjs.org/




ドキュメントに書かれていないので、誤解されても仕方がないですが、データの更新 (UPDATE) や削除 (DELETE) を knex.js でバッチ処理で実行することは可能です。

もとのソースコードの SQL 文の生成あたりを読んでいて、トランザクションの中にクエリ (Array objects) を入れてみたら実行できるような気がしたので、ためしに入れてみたところ… 実際に動作することを確認できました。

できる根拠を尋ねられても、もう当時の考えを覚えてないので困ってしまうのですけれども、やってみたら実行できたのですよ。

const express = require('express');
const router = express.Router();
const knex = require('knex')({
  client: 'sqlite3',
  connection: {
    filename: "./myname.sqlite"
  }
});

/* Connect to (MySQL|PSQL|SQLite) */
router.get('/', (req, res) => {
  let tableName = 'name';
  let query = [{
      id: 1,
      name: 'Janie Doe'
    },
    {
      id: 2,
      name: 'Richard Roe'
    },
    {
      id: 3,
      name: 'John Schmoe'
    }];
  knex.transaction(trx => {
      let built = query.map(elem => {
        return knex(tableName)
          .where('id', elem.id)
          .update(elem)
          .transacting(trx);
      });
      return Promise.all(built)
        .then(trx.commit)
        .catch(trx.rollback);
    })
    .then()
    .catch();
});
module.exports = router;

このソースコードは myname という DB に name というテーブルを作成して、 hoge とか huga とか piyo とか foo とか waldo みたいな適当な初期値を入れておけば実行できます。

削除したい場合には、update(elem) の部分を del() に書き換えると同様に実行できます。もちろん、insert() に書き換えても動きます。

実行環境は以下のとおりです。

$ uname -a
Linux Ganymede 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ node -v
v12.2.0

$ grep -i knex package.json 
    "knex": "^0.16.7",

$ sqlite3 --version
3.22.0 2018-01-22 18:45:57 0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2171d

同じように公式ドキュメントには書かれていないのですけれども、日付の範囲指定なども whereBetween() 関数の中に入りそうに見えたので、入れてしまうとやっぱり動きます。

こうすると簡単かつ柔軟に範囲を指定できるようになって便利なんですよね。

const express = require('express');
const router = express.Router();
const knex = require('knex')({
  client: 'sqlite3',
  connection: {
    filename: "./mylog.sqlite"
  }
});

router.get('/', (req, res) => {
  let tableName = 'access';

  const offset = 8; // UTC time offset HKT 
  //const offset = 9;  
  let currentDate = new Date();
  currentDate.setTime(currentDate.getTime() + 60 * 60 * 1000 * offset);

  let nextDate = new Date();
  nextDate.setTime(nextDate.getTime() + 60 * 60 * 1000 * offset);
  nextDate.setDate(nextDate.getDate() + 1);

  let cd = currentDate.toISOString().split('T')[0];
  let nd = nextDate.toISOString().split('T')[0];

  knex(tableName)
    .select()
    .whereBetween('date', [cd, nd])
    .orderBy('date', 'desc')
    .then(rows => {rows.forEach(elem => {console.log(elem);});})
    .catch();
});
module.exports = router;

このように knex.js には、公式には謳われていなくても、既知の関数の組み合わせで実現できることがたくさんあります。

SQL で実行できることは、何かしらの方法で実行できることが多いです。

できそうに思えたのに実行できなかったのは OrderBy() の中に Array や連想配列を入れて、複数の条件で並び替えを行うことです (Knex.js ver 0.16.7 までの話で、今後は対応されるかもしれません)。

この場合はデータベース内に VIEW を作成しておいて tableName に VIEW の名前を代入してやると思い通りの結果を得ることができます。

SELECTの中で条件分岐したい場合などにも、あらかじめ VIEW を作成しておいて tableName に VIEW の名前を代入してやると簡単です (これもドキュメントに書いてあったかどうか…) 。

でも、それは「SQL で同じことができることを経験的に知っているからではないか」と言われてしまうと、冒頭の話題を考えざるを得なくなるわけです。

SQLで直にクエリを書くことを考えると、どちらが良いのでしょうね。


SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)


※ 一例をあげると

Why you should avoid ORMs (with examples in Node.js)
https://blog.logrocket.com/why-you-should-avoid-orms-with-examples-in-node-js-e0baab73fa5

Breaking Free From the ORM: Why Move On? Time to escape object relational mapping
https://medium.com/building-the-system/dont-be-a-sucker-and-stop-using-orms-190add65add4

これから始める登山

唐突ですが登山を始めます。いつも訪れているトレイルや舗装路の峠ではなくて、登山靴がないと行けないような、本当の意味での「登山」です。

と言っても 10 年以上も昔に何度も登山に行っていたので、既に登山靴やら雨具やらは手元にありますし、しなければならないこと、してはならないことは既に頭に入っています。

友人に誘われて始めたのですが、たしか高校生ぐらいのときに転校により環境が変わってしまったのを境に疎遠になってしまいました。

さすがに、その時の古い装備のままでは信頼性に不安があるので、幾つかの道具を更新します。

冬に山に登る場合には多くの装備品と経験と入念な準備が必要となります。それに対して夏の場合にはそれほど多くの荷物を要求されることはありません。

  1. 登山靴
  2. レインウェア
  3. ヘッドライト
  4. グローブ
  5. 地図
  6. 方位磁石
  7. 折り畳み傘
  8. ストック
  9. 携帯食
  10. 入山届・筆記用具

ぐらいが最低限の必要なものです。

リュックサックは自転車用途に使用している deuter を、腕時計はランニングに使用している GARMIN を流用します。

本当は一番大切なのは、引率できる知識を有する経験者なのですが、まったくの入門者が一から始める場合には、どうするのが良いのでしょうね。

増水、落石、崩落、雷と地味に気をつけることが多いので、可能ならば最初は経験者に教わるのが最良なのですが。




登山用品の中で最初に調達すると良いのは、防災用品としても使用できるレインウェアとヘッドライトです (登山靴は最新のものに詳しくないので割愛) 。

非常時にも役に立ちますし、登山では必須の装備品となります。

いざというときに頼りになることが肝心なので、ここは値段よりも信頼性と機能で専用品を選択したほうが良いです。

私は撥水と即乾機能でウェアを選んでいます。

重ね着することも考えて、ご自身の体に対して、やや大きめのものを選択しておくと間違いがありません。

内側にダウンジャケットを重ねてウィンドブレーカーとしても利用できるので、こういうのが一着あると寒冷地に出張に行く際にも流用できて便利ですね。

専用の衣服と靴が準備できましたら、次に重要なのは視界を確保することです。

泊りがけの場合にはヘッドライトは必須になります。日帰りの場合にも備えとして有ったほうが良いです。

日が傾くと急に暗くなりますし、夜間は何も見えないことを前提にして行動しないと、どこに危険があるか分かりません。

スマートフォンのライトでは照明範囲が調整できませんし、片手が塞がってしまうと行動が制限されるので、頭に着けるライトが最良です。


PETZL(ペツル) ACTIK (アクティック) ブラック [アクティブシリーズ] E99AA A [並行輸入品]

私は信頼性重視で PETZL を選んでいます。地味に 10 年以上も使い続けていて、未だに動き続けているという一点だけでも凄いです。

しかし、手元にある旧モデルは時代が時代だけに光源が豆電球なので、光量が心許ないです。

新製品では光源が LED 2つに増えて軽量化されました。

ゴムかシリコンを使用してそうな旧製品と比較して、経年使用でも防水性が落ち無さそうなところも良いです。

衣服と視界の心配が無くなったら、次は現在地と方角を知ることを考えます。

地図は図書館でコピーできたり、古書でも買えたりしますけど、可能であれば最新のものの方が間違いありません。登山専用の地図というものが刊行されていて、書店で購入できます。

地図を入手できましたら、必ず予備のコピーをとって、防水ケースに入れておいてください。濡れたり破れたりして読めなくなることがあります。

地図だけが有っても、似たような景色ばかりで居場所が分からなくなるので、コンパスも必要です。

携帯電話は市街地を離れると圏外になって、現在地表示の精度が落ちますので、あまり頼りすぎないほうが安全です。


スント(SUUNTO) コンパス A-30 [日本正規品 メーカー保証] SS012095013

ストックは持っていると下山のときに役に立ちます。

ずっと坂道を下り続けていると膝が痛くなるので、その対策です。

携帯食は血糖値が下がりすぎて動けなくなることを予防するために必要です。食べたくなくても、安全確保のために持っていってください。

羊羹とかクラッカーで良いので、それほど困ることはありません。

どちらかと言うと飲料水のほうが重くて持ち運びに困ります。

いつもプラスチックボトル4本から5本ぐらいを持ち運んでいた思い出がありますが、行き先と季節によっては更に本数を増やす必要があるかもしれません。

登山靴も重いですけど、飲料水は本当は重いです。


【Amazon.co.jp限定】BAND-AID(バンドエイド) キズパワーパッド 大きめサイズ 12枚+ケース付 絆創膏

最後に日よけの帽子、サングラス、タオル、スプーンやフォーク、絆創膏、虫除けスプレー、ライター、ピンセット(棘抜き)、予備の下着などは持っていると役に立ちます。

反対に調理器具や食材などは持って歩きたくないです。

テントも一人または少人数での登山では持ち運びたくありません (日帰り、または山小屋に泊まれるところを探していきます) 。

テントを持っていても、好きなところに設置できるわけではないので、個人的にはあまり魅力や利点を感じ無いというのがその理由です。

持っていかれる場合はどうやって運搬するかに加えて、どこに設置するかまで考えておくと良いと思われます。

無くても楽しいんですけどね。

あとは車を止めた駐車場から登山口まで荷物を満載して走れるミニベロ、いや、これも無くてもいいかな