BRM429宇都宮400km北関東（ランドネきたかん）参加メモ

BRM429宇都宮400km北関東（通称「ランドネきたかん」）に参加した。
自転車で宇都宮市、水戸市、前橋市、高崎市を回るブルベで「東回り」「西回り」がある。自分は「西回り」で参加した。

■AJ宇都宮公式
BRM429宇都宮400km北関東 – AJ宇都宮

■宇都宮市公式
www.city.utsunomiya.tochigi.jp

■コース全体図
http://www.city.utsunomiya.tochigi.jp/_res/projects/default_project/_page_/001/015/734/course2018.pdf

１．前日

スタート時間(8:00)に始発電車で辿りつける自信が無かったのでいつも通り前泊した。
せっかくなのでコースの下見も兼ねて森林公園に行こう…としたのだがタイヤをざっくり切ってしまうレベルのパンクをしてしまい心が折れたので、近くのTREKストアでパンク修理等々してこの日はお開きにした。
www.bp-o2.com

２．当日

Garminをホテルに忘れたり道に迷ったりしつつ、ろまんちっく村に到着。

参加者多かった。反射ベストの配給があったので、皆おそろいの反射ベストを着ている*1

(1)スタート　うつのみやろまんちっく村（8:25　※第6ウェーブ)　～　PC1　セブンイレブン佐野富岡町店（10:41）

市街地～郊外部を淡々と走るだけだった。スタート時からアームウオーマーをつけっぱなしで走っていたがこの時点(20℃くらい？)まではまだそれほど暑さを感じなかった。
セブンイレブンがおにぎり100円セールをしていたので「おにぎり全部制覇するならどういう順・ペースで食べればいいかな…」など無駄なことを考えながら走っていた。

(2)PC1　セブンイレブン佐野富岡町店（10:41）　～　PC2　ファミリーマート高崎吉井町店（13:47）

この時間からもう暑かった。ただ最高気温(予報)は25℃程度であり、からっとした天気だったので13時～16時あたりは負荷を上げずに走り、その後挽回しようと決めて走った。
途中の「あしかがフラワーパーク」の渋滞は予想していたより相当凄かった。。

(3)PC2　ファミリーマート高崎吉井町店（13:47）　～　PC3　セブンイレブン前橋富士見皆沢店（16:35）

赤城山ヒルクライムのコースを経由しPC3へ。
まえばし赤城山ヒルクライム大会 ｜ 公式ウェブサイト

この辺が暑さのピークだった。36kmを3時間くらいかけて走っていたので、予想していたとはいえ相当ペースが落ちた。時間貯金が2時間切っていたので焦り始める。

(4)PC3　セブンイレブン前橋富士見皆沢店（16:35）～　PC4　セブンイレブン藤岡町藤岡店（20:36）

ヒルクライムの後の下りから栃木方面へ戻る。夜になっても「あしかがフラワーパーク」の渋滞は凄かった。。
この辺りから右ヒザの痛みが出てきており、PC4に着いた時にはいいDNFポイント*2を調べていた。

(5)PC4　セブンイレブン藤岡町藤岡店（20:36）　～　PC5　セブンイレブン桜川飯塚店（23:29）

右ヒザの痛みは限界に来ていたが、丁度サイクリングロードに差し掛かったのでスローペースで騙し騙し走る。「栃木・群馬・埼玉の三県境」という超激アツ観光スポットに寄る予定だったのだが残念ながらパスした。

またここから東回りの参加者とのスライド区間が始まり、色々エール？を送り合いながら走ったので走る気力が出てきた。

(6)PC5　セブンイレブン桜川飯塚店（23:29）　～　PC6　ミニストップ水戸駅南店（2:10）

痛みが限界を超えたので、痛み止めを飲んで走った。が、ここから「きのこ山」を越えるヒルクライムが始まり、左ヒザにも痛みが出てきた。
ただきのこ山さえ越えてしまえば普通の郊外の道なので割と調子よく走れた。結果として時間貯金を1時間ほど増やすことができた。

(7)PC6　ミニストップ水戸駅南店（2:10）　～　PC7　セブンイレブン芳賀祖母井店（5:04）

両ヒザの痛みのおかげか全く眠くならずに走れた。最低気温は10℃程度だったが、夏ジャージにウインドブレーカーがあれば十分暖かかった(と当時は感じていた)。ただ夜霧が立ち込めている所（茂木～市貝付近）の寒さは結構厳しかった。

(8)PC7　セブンイレブン芳賀祖母井店（5:04）　～　ゴール　うつのみやろまんちっく村（７時前)

市街地に入り、俗にいう「信号峠」が厳しくなる。ろまんちっく村に着くとサイクルピクニックの準備が始まっており、出発時とは違いとてもキラキラした空間になっていた。*3

※右端見切れているところに悪魔おじさんさんの自転車がいる

■リザルト
・スタート～PC4　※最初の7kmくらいはGarminファームアップ中だったので記録なし

・PC4～ゴール

■感想
・おそろいの反射ベストの集団、と書くと字面は不審な感じがするがすごく一体感を感じた
・天気が良く（ずっと晴れ・最高気温：25度・風弱め）、郊外部の道路が中心のコースだったので走りやすかった。
・東西スライド区間たのしいです

３．後日

２日安静にしたところヒザは動くようになったが、若干の痛みは残っている。また風邪をひいてしまったので自分のＧＷは完全に終了してしまった。。それでも400kmを走りきれたので満足している。

*1:散開した後なのでアレだが人口密度的にはこの2倍はいるイメージ

*2:交通の便が良く輪行しやすい始発駅・Googleレビューの高い24h開いてるネカフェ、健康ランドetc

*3:場違いなのではと不安になるレベル

BRM414神奈川200km白河 参加メモ＋α

ブルベという自転車で長距離を走るイベントに参加した。
ブルベ自体は今年(2018年)から始めており、今年に入って3回目の参加となる。

■BRM414神奈川200km白河（2018/4/14 福島）
www.aj-kanagawa.org

１．前日

スタート時間(8:00)に始発電車で辿りつける自信が無かったので前泊した。
せっかくなので新白河周辺をぐるっと回ってきた。

桜は散り始め、という時期だったが所々満開の桜もいた。

白河の関跡へ

わかる人にはわかるアングル*1

一番上にはお堂があった。ノートはあったが流石に聖地巡礼系の書き込みはなかった…

続いて「境の明神(那須)」の県境へ

例のアングル*2

日も傾きかけていたので早々にホテルへ。白河駅付近のホテルを利用した。
白河駅周辺は電柱が地中化されており、いい感じの雰囲気だった。

２．当日

■ルート
ridewithgps.com

スタート地点は「新白河駅西口（高原口）」。
ここから北上し、郡山市、福島市の南を経由し、福島の山中を走って新白河まで戻ってくる。

(1)スタート　新白河駅西口（高原口）～PC1 セブンイレブン松川駅前店

全体的に下り基調かつ信号が少なかったので気持ちよく走ることができた。
ただ二本松あたりの市街地は通行量が多く少し危なく感じる場面もあった。
巡航速度が30km/hいかないくらいだったので余裕をもってPC1に着くことができた。

(2)PC1 セブンイレブン松川駅前店　～　PC2 セブンイレブン郡山谷田川店

この頃からアップダウンがあったがほとんどの区間が平坦で走りやすい道だった。

途中「福島市飯野 花やしき公園」というところがとても桃源郷感があった。*3

(3)PC2 セブンイレブン郡山谷田川店　～　ゴール　新白河駅西口（高原口）

最後に獲得標高300～400mくらいのヒルクライムをこなすとあとは新白河市街へ向けて走るだけ。市街地に近づくにつれて道幅とトラックに気を使う必要があったが、無事にゴールすることができた。

■リザルト

グロス換算でも23km/hくらいで走れていたので、とても気持ちよく走ることができた。
また天気にも恵まれていた（曇り時々晴れ・ゴールに着いた途端に雨）のでとても平和に終わった。

帰りは安く取れたやまびこのグリーン車に乗車。
たまたま有名なバンド？のメンバーも同じ車両に乗りあわせていて、行く駅行く駅に追っかけの方々がいらっしゃったので女性の執念(パワー)を感じながら帰宅した。*4

*1:『こみっくがーるず 新白河 聖地巡礼』の検索結果をご参照ください

*2:『こみっくがーるず 新白河 聖地巡礼』の検索結果をご参照ください

*3:『福島市飯野 花やしき公園』の検索結果は本当に桃源郷感ありますいいカメラ欲しい

*4:駅に着くと追っかけの方々が一糸乱れず全員バンドマンについて一列でエスカレーターで下っていったのでさながら軍隊のようでした

東京湾一周（時計回り）

自転車乗りの登竜門？的な「東京湾一周（ワンイチ）」を年末に済ませてきた。

横浜 ⇒ 日本橋 ⇒ 千葉（内房線沿い） ⇒ 富津岬 ⇒ 浜金谷 ⇒（フェリー）⇒ 久里浜 ⇒ 横浜　という感じの時計回りコースを走った。
アクアラインは自転車走行不可なので、東京湾フェリーを使ってワープする。40分足らずで着くので船旅というほどではないが、いい気分転換になった。
www.tokyowanferry.com

■横浜～日本橋
6時前に横浜を出発。日が昇りきる前に国道１５号線を北上し日本橋へ。

早朝の銀座。ゴミ清掃車が走っていても、酔っ払いの集団がいても銀座のオーラで満ちていた(気がする)

日本橋で記念撮影。*1
ここから永代通り・葛西橋通りを経由して浦安・船橋方面へ向かい、その後千葉（市川方面）へひたすら走る。

■日本橋～千葉（市原）
国道１４号線はボーナスステージ（広い路側帯・きれいな路面）だったが、その後の国道１６号線は路面が荒れており、かなり神経を使って走った。
市原が果てしなく続いた後（体感）、木更津・袖ヶ浦といったアクアライン出入口付近へ到達する。

■千葉（市原）～富津岬
東京湾一周を謳っているのでなるべく東京湾沿いを走りたい、という理由から富津岬へ。

こんな感じの松林を抜けると…

なんだこれは

「明治百年記念展望塔」という展望台らしい。
明治百年記念展望塔 | 富津市

登った

岬の先っぽに来た感じがある。これはいい

■富津岬～浜金谷

先人のブログを見るとアップダウンがある的なコメントがあったが、正直どこがアップダウンに該当するのかがわからなかった…そのくらい平坦な道を走ると浜金谷のフェリー乗り場へ着く。出航10分前に到着したので急いでチケットを買って乗船。

■浜金谷～久里浜
船酔い防止のため寝ていたので割愛。そんなに揺れないので神経質になるほどではないが念のため

■久里浜～みなとみらい～横浜
トンネルだらけの国道16号線を北上し、八景島シーパラダイス前を抜けて国道357号線で北上。
せっかくなのでみなとみらいでクリスマスっぽい写真を撮ろうとしたが人がゴミのよう多すぎたので断念。カップルで爆発している観覧車だけ撮って撤収・帰宅した。

帰宅したのは18時前。途中で寄り道しまくったうえでの全所要時間は12時間程度。実際にペダルをこいでいたのは8時間程度だった。

■感想
・想像以上にド平坦だった。景色もどんどん変わるので確かに初心者にもオススメだと感じた。
・当日は北風が吹いていたので割と追い風基調で走ることができた。当日の天気予報（風向き）、日照時間を確認しておいたのがよかった。

■2018年の目標
・四国一周　四国一周サイクリング｜疾走感、出会い、観光、食を楽しもう！
・CtoC (直江津へ)
・技術ネタでのブログ更新継続（せめて月１回）

今年もよろしくお願いします。

シマノ ホイール WH-R501 前後 ブラック 31285

*1:そろそろ鉄下駄ホイールから卒業したい…！

ヤビツ・オギノパン・高尾

紅葉鑑賞とオギノパンが目当て。ついでに初ヤビツを済ませてきた。
走行距離が140km*1、獲得標高が2,616mだった。

■ヤビツ峠
山道に入るまでの生活道路が一番きつかった気がする。。
紅葉のヒルクライムを楽しむことができた。

裏ヤビツ側の方が紅葉はきれいだった

■宮ケ瀬湖
帰ってから人造湖であることを知った。紅葉と水面のコントラストがふつくしかった

■オギノパン

神奈川の学校給食にでるらしい。うらやましい。

右はゆず味

■高尾駅
駅舎はアレだが普通に都会だった。あまり紅葉も見られなかったので高尾山口まで行くべきだったか…

帰りは多摩サイを下って帰宅。
地味に初多摩サイだった。まあまあ走りやすい道だったが、二子玉川より南は交通量が多いので割を気を遣う道だった。

*1:途中でスマホの電池が切れてしまったので、トータルでは150km以上は走っているはず。。

沖縄本島だいたい一周サイクリング

１１月の連休（２泊３日）を利用して沖縄本島で自転車（ロードバイク）を乗り回してきた。基本的なコース取りは「ツール・ド・おきなわ」の「本島一周サイクリング」コースを参考にした。
沖縄らしい食事は空港での「ミニラフテー丼＋ミニ沖縄そばセット 1080円」のみ、という脳死グルメっぷりだったが気にしない
www.tour-de-okinawa.jp

■１日目　那覇空港～恩納村

羽田空港まで自走して那覇空港へ。
まさかのStrava起動忘れ。だいたい40km程度だった。
空港着が18時だったので初めての沖縄ナイトライドとなったが、郊外部の街灯の少なさに精神を削られつつ北上した。（自称1200ルーメンの中華ライトとVOLT400の２灯でギリギリ行けそうと感じるレベル・終始「何か出てきそう」感があったので怖かった）

■２日目　恩納村～屋我地島～辺戸岬～東村～名護

宿からの１枚。沖縄の朝て感じ

本日の行程。この日は終日北風が吹きつけていたので、辺戸岬に向かうまでの平地が非常につらかった。。

屋我地島へ続く橋からの景色は素晴らしかった（※若干渋滞してたので写真なし）

本部循環線（R449・R505）で海沿いを北上。すでに風がっょぃ

■辺戸岬
辺戸岬。よくわからない石碑しかない…という感じだった。この時点で14時を回っていたので焦りつつ東村へ。ここから山(ジャングル)の中を走る。

■アダ・ガーデンホテル
圧倒的な御殿感があった。ここから東村までのアップダウンがきつい。

■カナンスローファーム
次のゆるふわライド(予定)で行きたい。東村に近づくにつれ「自販機がある！」「お店がある！」「タクシー走ってる！」と文明の発達を感じることができる

ここからわんさか大浦パーク前を抜けて名護へ…と思っていたのだが、釘ふみパンクしてしまった。昨日のナイトライドのトラウマもあり、国頭方面へ抜けて名護へ向かうショートカットをしこの日は終了。

■ヤンバルサイクル
チューブと補給食を購入。土日も20時まで開いていたので非常に助かった。

■３日目　名護～海中道路（海の家あやはし館）～ムーンテラス東崎～那覇空港

■海の駅あやはし館

闘牛がいた。小さい子が乗せてもらえるくらいおとなしかった。

フォトジェニック（言いたいだけ）

海中道路の追い風はすごく気持ちよかった。今度は伊計島まで行きたい。

３日目は１００ｋｍいかない程度だったので楽だった。
21時半に羽田に着いた後、家に帰るまでにスローパンクしたり自転車の検問があったり夜食を買い食いしたおかげで深夜１時に家に着いた。。

総括

・初めて1日で200km以上走れたのでとても満足
・沖縄の郊外でのナイトライドはちょっとすごく怖いので可能なら避けたい

JJUG CCC 2017 Fallメモ【Java SE 9の紹介: モジュール・システムを中心に #ccc_e4】

JJUG CCC 2017 Fallに参加した。
表題のセッションに参加したので、参加メモを書いておく。

■JJUG CCC 2017 Fall
JJUG CCC 2017 Fall
■SlideShare

Java SE 9の紹介: モジュール・システムを中心に from Taku Miyakawa

www.slideshare.net

【概要】

2017年9月にリリースされたJava SE 9では、言語組み込みのモジュール・システムが追加されました。また、標準ライブラリ・言語仕様に改善が加えられています。
本セッションでは、アプリケーション基盤の構成に大きなインパクトがあるモジュール・システムを中心に、Java SE 9の全体像をお伝えします。

【内容】

■JavaSEってなんだっけ？

・JavaSEは「Java処理系の規格」
・JavaEEは「アプリケーションサーバの規格」

■JavaSE9のモジュール・システム

・Java8までの課題
①JAR地獄(JAR HELL)
→JARの関係性が複雑化し、依存関係がカオスになる状態
　影響：下手にJARをクラスパスから外すと実行時例外が起こる　etc
②内部向けパッケージの存在
→内部向けパッケージ（Java内部で使用するAPIやアプリ基盤の資産等）は本来外部からの使用を想定していない。
　→Githubで「import sun.misc.Unsafe」をgrepすると58,233件ヒットする(！)
　→移植性の低下、(既存のコードに影響を出さないように)実装の改善が難しくなる

・Java9ではJARを名前付きのモジュールとしてカプセル化し上記の解決を図れる
①JAR地獄(JAR HELL)
→モジュール単位で依存関係を整理。「module-info.java」に記述する。
②内部向けパッケージの存在
→外部からの使用を制限

・「exports」「requires」命令で公開範囲をパッケージ単位で制御する
→java.lang、java.utilパッケージなどは「java.base」パッケージに含まれ、全てのパッケージに暗黙的にrequiresされる。

・問題点：非公開なメンバへのリフレクションは外部モジュールからは通常不可能となり、色々困る。
　例：DI先のフィールドは大抵privateなので、Injectできなくなってしまう　etc
→リフレクションさせたいときは「open/opens」命令を追加することで、外部からのリフレクションを許可できる。
→OracleJDKでは外部モジュールからのリフレクションが可能らしい…いいのか

・問題点：世の中の多くのJARファイルは「module-info.class」を含んでいない
→経過措置として下記２モジュールが導入された。
①無名モジュール：クラスパス上のクラスファイルは無名モジュールに追加される
②自動モジュール：モジュールパス上のJARファイルのうち、module-info.classを持たないものが自動モジュールとして追加される

両者ともすべてのモジュール/パッケージをrequires/exportsし、自動モジュールはすべてのパッケージをopensする。
→配布されたOSSのメソッドをリフレクションしたいときは自動モジュールとして追加する必要がありそう

・モジュール化する場合もしない場合も『JDK9への移行ガイド』は必読。
Java Platform, Standard Edition Oracle JDK 9 Migration Guide, Release 9

・モジュール内のクラスのテスト
→ホワイトボックステストの実行時、JUnitやJMockit等のパッケージをテスト対象の資産はrequiresしていないため問題となる。
【正攻法】
・モジュール定義を一時的に上書きする
・javac/javaコマンドにオプションを指定
→クラス名の指定が必要なので煩雑

【次善策】
・あきらめてクラスパスに追加してテストする

■JavaSE9のその他のアップデート

（※かけ足で解説された）
・try-with-resourcesの改善
→try句の()内にBufferedReaderのインスタンスを取得するコードを書く必要があったが、try句以前で定義できるようになった。

・個人的にはJEP273 Secure Randomのアルゴリズム追加が気になった
→「-Djava.security.egd=file:/dev/urandom」のおまじないが不要となる日が来るのだろうか
→API追加されるようなので、アプリ基盤側でLinux使用時はデフォルトでurandomを使用するようにできるかも…？

■モジュール化の参考図書

Bakker, Mak (2017)『Java 9 Modularity』
shop.oreilly.com

JJUG CCC 2017 Springメモ【AB6 Java8プログラミング ベストプラクティス & きしだが働いてるかどうかIDEのメモリ使用状況から機械学習で判定する】

JJUG CCC 2017 Springに参加した。
表題のセッションに参加したので、参加メモを書いておく。

■JJUG CCC 2017 Spring
JJUG CCC 2017 Spring
■Call for Papers
きしだが働いてるかどうかIDEのメモリ使用状況から機械学習で判定する
■SlideShare
Java8 コーディングベストプラクティス and NetBeansのメモリログから...

【概要】

最近は機械学習が流行しています。 しかし、Javaのメモリ使用状況のような波形データの分析は、そのままの形では単純な機械学習器に不向きです。 このセッションでは、このような波形データに対して、ウェーブレット変換で周波数解析してから機械学習を行う方法について紹介します。
…とのことだったが予定変更して機械学習部分はさわりの部分のみとして、大半はJava8のプログラミングで気を付けることを話されていた。
→スライドの内容はレビュワー／レビュイそれぞれがチェックシート的に使えそうと感じた(特にJava8の部分)

【内容】

■機械学習

・NetBeansのメモリ使用量をJMX経由で取得し、InfluxDB・Grafanaを通して可視化
・GCの場合、波形データとなるため単純な閾値での判定はできない
→「周波数解析」を行った。
・フーリエ変換→離散ウェーブレット変換
→NetBeansのデフォルトのスレッド数が32なのでそれを教師データにした(※入れているプラグインによっては増える)
・実は機械学習でなく近傍法などの障害検知手法でよかったのでは…というオチ

■Java8プログラミングベストプラクティス

１．一般的なこと
(1)変数に適当な初期値を入れない。
理由：(宣言部では宣言のみとすると)最適化がかかりやすい、コンパイルエラーへの期待(※Java8では実質的final扱いとなる)
NG例：Stringの変数の初期値にデフォルト値を入れておき、条件に応じて入れ替えるのはNG

(2)ImmutableList/Mapを使う
理由：値がどこで書き換えられるかをソースを追うのは辛い、並列処理で不具合が起きない
　　→for文に比べ性能が落ちる場面があるが、大抵の場合は問題にならない
NG例：for文の中でList内の値を書き換えて、同じListのインスタンスを別の処理で使いまわす
　　→ラムダ式が使えない場合はGuava等のライブラリを使うとよい

(3)論理式をうまく使う
　→条件式の片方がbooleanリテラルの条件式の場合は論理演算にするetc
理由：バグの元、複雑になる
NG例：※スライドを参照

(4)大事なものはインデントを浅く
理由：読む範囲を短くする。早期リターン。
NG例：if文内の処理が全部終わって処理を抜けた後でreturn null;とかするのはNG

(5)if文の中でbooleanを反転させない
理由：バグの元(※びっくりするようなコードは書かない)
NG例：メソッド内でOKの場合にfalseを返し、NGの場合にtrueを返す

(6)(コンストラクタ・メソッド共に)オーバーロードは下記の目的のためだけに使うべき。
1.引数の省略
2.処理の集約
OK例：引数が多いものから先にクラス内に書いていき、一度に読む処理量を減らす。

(7)メソッド内の処理が違う場合はメソッド名を変える
理由：バグの元
NG例：同じメソッド名で引数の型だけが違う

２．Java8
(1)Stream
・forEachのifはfilterにできる
・forEachの値変換はmapにできる
・forEachの入れ子はflatMapにできる
・count>0は使わない
【メリット】
・行われる操作が限定される
・変数の行く先を追わなくてよい
・結果、読みやすくなる
→ラムダ式の中で手続き処理的なコードを書かなければよさそう

(2)例外処理
→例外処理と関数型プログラミングは相性が悪いのであきらめる。
　→try-catchはgotoである。そのため、集合を扱う処理の中にポインタの考え方を持ち込むのはむつかしい。
　→stream・ラムダ式をあきらめるか、try-catchを書くか

(3)Optional
・ifPresentのifをfilterにできる
・ifPresentでの値変換はmapにできる
・ifPresentでの入れ子はflatMapにできる
・引数では使わない
→メソッド定義者がnullチェックを実装するべき
　→Optionalはserializableでないので色々問題になりそう
・orElseThrowにException::newを書かない
→Exception::newをしてしまうと例外発生時の情報が握りつぶされてしまうので、例外メッセージを含めて例外をthrowする

(4)FunctionalInterface
・ラムダ式を割り当てた変数は作らない。
→メソッドとして定義する
・むやみにAtomicInteger/Longを使わない
→finalから逃げる場合は配列を使えば解決できる

(5)Date and time
・Calendarクラスの時みたいに「3*24*60*60」とかしないで、Durationクラス等のメソッドを呼んで計算しよう

３．Java7以前
(1)LinkedListは使わない
→連結リストとしての動作を期待しても、内部実装がよくないためArrayListよりも処理時間がかかる場合がある
　→ArrayListと違いメモリ上に分散して領域確保するため、CPUのキャッシュに載らない可能性がある

(2)IOExceptionをRuntimeExceptionへ変換したいときはUncheckedIOExceptionというクラスがあるのでそちらを使おう