LM5102 と LM4102 の比較

Lee の 102 が好きで、いつもこれなんですが、数年前に買ったものが、ついに、お尻の辺りが薄くなってきて、このままではまずいなと。

アメ横の 610 のセールはもうすぐだった気がするけれども、待てそうにないので買うことにしました。おまけで、Lee のマグカップもらえて嬉しかったです。

今売っている 102 は、細かくいうと LM05102 というモデル。数年前に買ったのは LM4102。数字からしてアップデートされているのですが、LM04102 のお尻の生地が破れてしまう前に、両モデルを重ねてスタイルを比較してみました。

重ねてみると、ほとんど変わりません。膝の絞り込み、裾の広がり具合、レングス、同じです。宣伝見ると、生地が厚くなったのか？とも思っていましたが、それも変わりません。

大きく違うのは股上の長さ。LM05102 の方が断然長く、チャックの長さも 2cm 以上長いです。これは、履き心地にも大きな違いとして感じられます。履きやすさでいうと断然 LM5102 ですが、おそらく、履いた姿がカッコよく見えるのは LM04102 でしょうね。

あと、宣伝で見て知っていたのですが、ベルトループが 5 → 7 本に増えました。効果のほどは、んーー、ズボンに入れたシャツが出にくくなる？かもしれませんね、まだわかりません。

そのほか、Lee のレザータグがちょっと変わってます。色が少し濃くなってます。これは正直 LM04102 の方が良かったかな。ベルトするときは、中に通さないので、誰にも見えない部分ですから、実はどうでもよいことなのですが・・・また、見えないことですが、ジッパーのつまみの形状が変わりましたね。今までは真四角でしたが角がカットしてあり、全体的に大きくなっています。使い勝手がよくなった感じです。

ってことで、しばらく履き込んでみます。

CloudKit にマスターデータを登録するには・・・

CloudKit にマスターデータを登録するにはどうするのだろう。Dashboard をいくら探してもファイルをアップロードする仕組みはない。色々調べてみても、その辺りについて書いてある記述もない。まさかの、その仕組みナシ・・・という気がしてならない。

日本で観察できる野鳥 600 種類ぐらいなのでそれほど多くないこともあり、CoreData に登録済みのデータを for 文で回しながら一件ずつ CloudKIt に登録。すると、一件も登録されない。for 文の最後で break かけると 1 件だけ登録された。どうやら制限があって、あんまり高速にアップロードを繰り返すとキャンセルされるようだ。

ウエイトの掛け方：

        [NSThread sleepForTimeInterval:0.5f];

強制的にスリープを送りながら実行するとうまくいきました。ってか、600 件もあるので、5 分ぐらいかかるんですが・・・一回だけなので、ま、許す・・・

CloudKit: N から 1 のレコードを参照してみました

CloudKit で relation の定義の仕方がわかったので、今度は、N のテーブルから 1 のテーブルを参照する方法を試してみました。

Apple 謹製のドキュメントはすごく素性がよくて（当たり前？）、その通りに作ればその通りに動きました。ただ、これ、実装するとなるとかなりキツイね。理由は手順を追うとわかります。

1. まず、N テーブルのレコードを query して recordID を特定。
2. 次に、そのレコードに定義してある Referene 型のフィールドの値を得る。
3. それを手掛かりとして、1 のレコードが定まるので、フィールドの値を得る。

正直、CloudKit 使わないで、自 server に仕組みを素で書くのと、手間は大して変わりません。以前 4D 使ってプログラム書いている時とは雲泥の差。なんか、Python を CGI としてプログラムするのと大差ない。いや、SQLite3 なら、フィールドに色々制約をつけられるので、恩恵を受けられるけれども、CloudKit はそんな仕組みがないので、その面では厄介か。なんでこんなこと言うかといえば、CoreData の素晴らしさはどこ行ったんですか？と言うことを確認したい。

で、さらに、サーバーとやりとりする都合、1 で block を使い、さらに、3 のために block を使うという、block の中に block を書く形になるので、変態的な code になってしまう関係上、こんな仕組みやめて自 server で書いちゃった方がむしろ判読性？可読性？メンテナンス性？は高いんじゃないかと思いました。

と言いつつも、自 server を建てるとなると、それなりに費用がかかりますので、そんなお金はない当方としては、これを使うしかないなぁと。

あと、まだよくわかんないけど、簡単に重複したレコードを作れちゃうのは、そうならないような配慮も自分でしないとならないからなのでしょうか。RDB なら普通にある機能なんだけど、自分で実装するとなると・・・きついね。

ふぅぅぅぅ。

さて、次は、マスターにデータを一括して登録するにはどうするのか・・・ファイルアップロードして一括登録したかったんだけど、仕組みが・・・ない？　アプリから作る感じなのかなぁ・・・

CloudKit で relation はどうやって定義するのか

CloudKit を使って、1 : N の relation はどうやって表現するのか、とりあえず、設計においてどうするのか、理解を深めるため、主に Apple の document を中心に熟読してみました。

CoreDate との比較になりますが、CloudKit の場合、N : N という CoreData で便利だった手法は使えません。変わって、1 : N ( : 1) の表現になるようです。relation を形容するための field type として、Reference 型というのが用意されています。これを果たして 1 と N でどちらに定義するものか悩ましかったんですが、Apple 謹製 document によると N 側に規定し、1 側のレコードを参照するのがよいとのことです。発展的には、1 : N : 1 の関係を規定した場合、Reference 型のフィールドは N のテーブル（Record Type）に、1 のテーブルそれぞれ分 2 つ定義することになります。RDB 屋としては、自然に理解できました。でも、CoreData を知ってしまった今は、ちょっと、懐古主義という言葉を思い出しました（一貫性がないと言いますか、ま、あまり深く考えず、そういうものだと理解しました）。

ついでながら、便利に思ったことも記載しますと、1 側のレコードを削除したら、N 側のレコードも芋づる式に削除可能だそうで、一貫性を保つための（最低限の）仕組みは用意されているようです。

後日談ですが、その恩恵を受けるにはレコード生成時にその指定を忘れるなと。action:CKReferenceActionNone はだめ。

document によると、Dashboard で指定ができると書いてあるけれども、よくよく読むと、それは 、1 レコードずつ指定する方法なので、実質意味がないぞと。

生成時には、action:CKReferenceActionDeleteSelf だと。

設計まででまだ実際に cording していませんので、試したらまた記載します。

CloudKit を使ってみた

アプリのユーザーが作ったデータを共有すると色々都合が良いので、BaaS はどれがいいのか調べていたら、Apple 謹製の CloudKit があった。ちょっと試してみたらかなり素直な印象。Apple の公式ドキュメントが一番使える印象。Objective-C で例示してあるのもいいね。

レコードの保存、Query まではうまくいきました。残り疑問点は、relation と データの削除。

relation はかなり難しそうね。

UITableView を配置すると、上部に謎の空白ができてしまう時の対処方法

いつの頃からか、UITableView を画面上に配置すると、謎の空白ができてしまう現象が発生。これ、見た目がすごく悪いので、解決方法がないのか色々調べたのですね。

結局のところ、StoryBoard で、UITableView の配置順を下げると解消するのですが、これが一番簡単な解決方法だと言うことが判明。adjust  scroll view insets の適用は、海藻の一番上のオブジェyくとなので、UITableView が一番上にあると意図せずこれが効いてしまうので効かないように順位を下げる、と言う長い長い説明終了。

愛宕吾国ハイキング縦走コース

脚がだいぶ仕上がってきたので、12 月にも行ったコースを走ってきました。

今日は気温が低く快晴で風も少なく走りやすい。R1 フーディの上にウインドブレーカーで丁度良い感じ。R1 フーディは走っている間とても快適でした。満点です。

岩間駅から 0740 に走り始めて福原駅に着いたのが 1025 だったので、3 時間を切ってゴール。相変わらず登りがきつすぎで走るのが困難。コースは 12 月に走ったのを随分覚えていて、地図なしでいけました。

次に行く時に備えて、2 つほど。1 つは、初めの展望台への登り斜面は、ぬかるんでいて滑りやすい。これは 12 月もそうだったのだけれど、ここのところ雨も降っていないと思うのになぜかぬるぬるで、転びそうになりました。「切り通し」（高尾山では「巻道」と言うが・・・）の矢印はないけれども、回り込んで走ったほうが安全か。

2 つ目は、吾国山を下山して、一般道に出て、前回 lost してしまったところ、今回は矢印を見落としませんでした。歩道を走っていると、つい、そのまま行ってしまいますが、左に矢印があり、車道を横切って曲がります。丁度カーブのところなので、何となく行ってみたい感じの道だから、次回はもう見落とさないだろう。

今回、タイムは良かったんですが、駅に着いたら、丁度、5 分前に電車が行ってしまい、30 分ほど待つことに・・・待っている間、汗を吸っている R1 は寒かったですね。

前回は宍戸駅前の踏切が工事中で遠回りして「いこいの家はなさと」に行ったのですが、今回は工事も終わっていて、普通にいけました。1.8km ほどなので、クールダウンには丁度よい距離でしょう。はなさとの食堂は美味しいものが多いと思いました。今回はカリカリたこ焼き食べました。お土産に買った「吉原殿中」というお菓子は甘すぎず、しつこくなく、すごく美味しかったです。