投稿者: かず

  • 大阪まで船移動を考えてみた

    東京から大阪まで「往路は楽に車移動できないか、子連れだし」と、フェリーでの移動を考えてみた。

    ところが

    現在、東京ー関西を直通する一般向けフェリーはない。
    そのためオーシャン東九フェリーで四国・徳島まで向かい、そこから神戸淡路鳴門道を経由して大阪に向かうことになる。

    ちなみに今回は用事での移動。レジャーじゃないので、弾丸。
    土曜午後出発、日曜日中着、月曜早朝までに戻り。

    タイムスケジュールとおおよその料金

    • 土曜
      • 15:00発、レンタカー貸出、W-A、29,040円
      • 16:00発、自宅出発、関越、首都高
      • 17:30着、東京有明埠頭
      • 19:00発、オーシャン東九フェリー
        運賃12,730円/人、2名個室10,000円/室、自動車航送(<5m)34,700円/台、計44,700円。
        (船中泊)
    • 日曜
      • 13:20着、徳島沖洲桟橋
      • 14:00発、徳島道、大鳴門橋、阪神高速
      • 16:30着、大阪目的地着
      • 18:00発、阪神高速、名神、新名神、伊勢湾岸道、新東名、東名(高速代10,250円)
    • 月曜
      • 2:00着、自宅到着

    自力で陸送した場合

    高速代10,250円、燃料代5,000円。計15,250円。
    しかも土曜日中に出発すれば、夜には着いてしまう。
    日曜までのホテル泊したとしても、コロナ禍の影響で宿代は1万位で泊まれる。そうなると往路総額で2.5万。

    結論、断念

    これ、良案だと思ったものの、差額を考えてプラン断念。残念。

  • Redmineと別サーバの git リポジトリを連携する

    ここでは概念的な話のみ。
    実際の設定方法等については、各自でググッてください。

    あと、これは昔話です。Redmine のバージョンは若干古いです。
    最新の Redmine や Git では状況が異なる可能性あり。

    「Redmine や Git には余計な手を加えず、Redmine や Git の標準機能だけで連携を実現する方法を導き出したらこうなった」というお話です。

    下調べ

    もしかしたら最新の Redmine は、こんな面倒なことしなくても、標準機能だけで別サーバの Git リポジトリを直接参照できるかもしれない。
    でも、自分が環境構築した当時、調べてみた限りではこんな状態だった。

    プラグインでの連携

    そのプラグイン自体が最新だか何だかよく判らなかったし、情報が少ないし、よくわかんなかった。
    プラグインがメンテされる可能性も未知数。

    トリッキーな方法で連携

    Redmine のプログラムソース弄ってなんたらとか、ディレクトリをマウントしてどうたらとか。
    文字通りトリッキーな方法すぎて、正直メンド臭そうだった。

    制約

    あと、命題を実現するうえでの制約が以下。

    Redmine の制約

    標準的なパッケージ(プラグインとか入れない状態)では、 Redmine と同一のサーバ上にある Git リポジトリとしか連携できない。

    前述の通り、絶対にできないわけではない。
    プラグインの利用とか色々細々と弄れば、異なるサーバ間でも連携できるかも知れない。
    あくまで、Git と Redmine 本体が提供している標準的な機能だけで可能な設定では実現できないという話

    当方の運用上の制約

    Git リポジトリを管理しているサーバは、Redmine とは別のサーバ

    Redmine 搭載のサーバと Git リポジトリを管理しているサーバは、それぞれ公開の場所も、管理上のポリシーも異なる。
    そのため Redmine サーバを、Git リポジトリとして一緒して運用する(開発者などに公開して操作させる)ことができない。

    でも Redmine は、システム開発の基幹。何とかしてこれらを連携させたい。

    そこで出た妙案

    Git リポジトリには hook(フック)機能がある。

    これを使う。具体的には以下。

    • Git ベアリポジトリに push されたら
      1. ssh で Redmine サーバにログイン。
      2. Redmine サーバ側にある Git ノンベアリポジトリから、Git サーバのベアリポジトリの内容を fetch。

    これによって、以下のメリット。

    • Git ベアリポジトリの管理は、Redmine と別サーバ。
    • でも Redmine サーバ自らの Git ノンベアリポジトリ(クローン)にも、その内容が常時同期される。
    • Redmine は、同一サーバ上の、同期された Git ノンベアリポジトリの内容と連携することで、あたかも Git リポジトリの本体と連携しているように見える。

    余談

    そんなの GitHub とか GitLab 使えば、Redmine とか要らなくね?

    その通り。
    GitHub, GitLab で世界が完結できている幸せな方々については、Redmine なんか必要ない。
    ぜひともこの話はなかったことにしてほしい。

    でも世の中 Redmine をポータルにして運用している組織は沢山いるような気がしたので、記事にした次第。

  • 私的高速移動考(下り線)

    東京起点、東名-新東名の話。
    まぁ、たまに使うので。

    トラック事情

    東京というか東京近郊発の物流路線便は、20~23時を中心に配送センターや営業所を出発する。

    これは宅配関連であれば、日中集荷した荷物を拠点で仕分けし、長距離便のトラックに乗せるため、この時間となる。
    また、工場などでの製造した品についてのチャーター便の場合も、概ね翌午前中着を目標としていることが多い。そのため、やはり20時以降に出発する事が多いと思う。

    京阪神までの物流距離であれば、概ねこのスケジュール感で動いているのではないかと。

    なので概ね以下の時間帯が混雑しているような感じ。

    東京~御殿場⇒20~23時
    御殿場~富士⇒21~00時

    ちなみに、0~5時頃まで、富士~豊田までの間もトラックはそれなりに走ってる状況。
    さすが幹線。

    走り難いか?

    指定速度以上の速さを出したい「スピード至上主義者」みたいな方々には、トラックの多い新東名は走りにくいと思う。
    トラック同士の追越はとても遅いので、それに焦れる普通車は多いのではないかと。
    でも巡航してるトラックもそれなりにいるので、ACC使って「流れ」に乗って走るのは楽。

    個人的な走り方

    深夜時間帯については、第1、第2走行車線はトラックが多く、走りにくいので、結果的に普通車は第2走行車線、はたまた追越車線をずっと走ることになる場面が多い。
    というか、それが「暗黙の了解」のような気がする。

    走行提案

    以降は個人的な意見妄想・戯言です。
    あまり気にしないでください(笑)

    できれば、こう言った走りをしてほしい。

    トラック

    過積載・ローリーなどの80km遵守車は第1走行車線必須として、巡航は基本、第1・第2走行車線。
    追い越したいときだけ、第2走行・追越車線を走る。

    普通車

    巡航は第2走行車線、追越用途で追越車線を走る。
    追越車線走行中、自分より速度の速い車両が続行してきたら、すぐ第2走行車線に戻る。

    IC・JCT・SA・PAなどで流出するとき

    流出の3kmほど手前(混雑時は5km手前)から、第1走行車線に移動することを思考する。出口の予告標識に差し掛かる頃までには、第1走行車線に移動。

    この時、前方に特大車など低速車がいても焦れないことが大事。

    一番危険なのは

    雨の中、トラックが混雑している時間帯

    これが1番危ないです。あと、トラック同士の追越中とか。
    このような状態では危険なので、頻繁な追越はせず、第2走行車線を巡航するようにしています。

    浜松いなさ、岡崎SA間

    この区間は2車線。
    しかも勾配の抑えられている新東名の中でも、周辺景色と2車線の所為か、それなりのアップダウンがあるように見えてしまう区間。
    なので、交通量の多い時間帯の追越には気を付けている。

  • 実家弾丸見舞い(練馬⇔三重)

    お馴染みの「机上の空論」。
    といいますか、検討した備忘録。折角考えたので記事にしてみた。

    はじめに

    トヨタレンタリースには「片道GO!」プランという激安プランがある。
    この利用を考えたスケジュール設定を検討してみた。

    ちなみに、元々はワンウェイ利用された車両の回送を、自社や代行業者の自腹でやっていた。(今もそれで回送してる車両もあるはず。)
    それを、おそらく「激安料金で貸し出したほうがコスト下がるんじゃね?」という事で始まったのが、このプランなんだと思う

    正直なところ、急ぐなら夜行バスでも新幹線でも使うのが良いのだが、荷物牽いて道中移動とか交通費とか時間の融通とかロマンとかなどを鑑みて、レンタカーにしてみた。

    ちなみに同様のサービスは、ニッポンレンタカーも開始してる。
    それ以外のレンタカー屋さんもやってるかも。

    行程

    • 1日目
      • 12:00、トヨタモビリティサービス(往路指定店舗)、往路貸出
      • 14:00、自宅着
      • 22:00、自宅出発、東京IC-東名-新東名-伊勢湾岸道-新名神
    • 2日目
      • 4:00、鈴鹿PA/SIC着、仮眠4h
      • 8:00、出発
      • 9:00、実家着、昼食・買物
      • 13:00、病院着、見舞・買物
      • 16:00、実家戻り、伊勢湾岸道-名古屋高速
      • 19:00、トヨタレンタリース名古屋(復路貸出指定店)、往路返却-復路貸出、名古屋高速-名神-中央
      • 23:00、小黒川PA着、仮眠6h
    • 3日目
      • 5:00、出発、中央-調布IC
      • 10:00、自宅着
      • 12:00、トヨタモビリティサービス(自宅最寄店)、復路返却

    【往路】
    鈴鹿PA/SICだと行き過ぎるので、本当な長島PAで休憩したいところだが、四日市市内通過の際、確実に渋滞へ巻き込まれる。

    【復路】
    中央道経由にしたのは、到着時の都心渋滞を避けつつ、ゆっくり帰るため。寄り道設定も可能。
    急いで帰る場合は、みえ川越IC-伊勢湾岸道-新東名-東名が一直線ルートだし速い。

    メリット

    • 通常レンタカーを借りた場合、コンパクトカークラスで1.2万円なのに対し、「片道GO!」を利用した場合は「往路+現地移動4.4千円(48h)、復路2.2千円(24h)、合計6.6千円」と、およそ半額で済む。
    • 返却店は管轄地域の営業所であれば、どこでも返却オッケー。

    本当は往路も24h貸にしたところだが、そうすると現地移動で利用する時間が不足してしまう(別途、移動の足と調達必要が生じる)ため、ここだけ48h貸にしている。

    デメリット

    • 貸出店が選べない。指定店舗まで出向く必要あり。
    • 燃料代は自腹。
      そのため特にハイエースなど大型車を利用した場合、コンパクトカーよりも燃料費がかかるので、レンタカー代が半値で済んでも、燃料代でメリットが削がれる可能あり。
    • レンタカーマイルは利用不可だし、付与もされない。
    • 電話予約のみ。
      そのためトヨタレンタカーメンバーとして(ゴールドメンバーになるため)のカウントも対象外。(だったはず?)
    • 延長・装備オプションは一切できない。
      特に指定場所以外の返却や遅延した場合、正規料金での精算になる。
    • レンタカーのゴールド会員だと、最初から20%引。
      「特割GO!」の「直前割」の場合、最大で40%引の場合もある。
      こうなると、50%引との差額や片道返却などの手間を考えると、正直微妙な気もする。
    • 足かけ3日間なので、確実に疲れる。
      (新幹線利用で日帰りできることを比較して)

  • 駿河屋通信買取のポイント

    追補記事として「駿河屋通信買取のポイント(2024年現在の追補・訂正)」を追加しました。

    一部誤解している点あるかも。。。

    駿河屋の通信買取の場合、「あんしん買取」の場合は3千円以上の買取、「かんたん買取」の場合は商品点数が30点以上であれば送料無料。
    ただし、いくつか守るべきルールがある。

    「ゆうパック」の「着払い」で送る

    ヤマトや佐川急便など「ゆうパック」以外で送付した場合、送料無料にはならない。

    また、元払い(発送人が送料を支払った状態)で発送しても、送料の買取時精算はしてくれない。

    100サイズ以上で送る

    「あんしん買取」かつ3千円買取がほぼ確実な場合であれば、100サイズ以下で送付しても問題はない。

    必ず「1箱あたり3千円を余裕で超える額」を目安に送ること。

    よく誤解されがちだが、「あんしん買取」の場合は「3千円以上の見積であれば、すべて送料無料になる」わけでではない。
    品物の状態によっては買取額が「減額」されることだって十分にあり得る。
    そして最終的に買取額が3千円に満たない場合になってしまった場合、送料が買取額から「天引き」されるおそれがある。

    さらに「送付の際に適当な箱がなかったから」などの理由で複数口で送ってしまった場合にも、買取額が「1箱あたり1,500円」に満たない場合は、逆に送料が請求されてしまうので、注意。

    大量の物品を送るときは注意

    種類によっては、1回あたりの買取数を制限している場合がある。
    よく確認すること。

    個人的な心構え

    気長にやる

    「査定が遅い」「連絡がない」とかいうツイートなどをたまに見かけるが、こう言った短気または文句の多い方々には、心身によろしくないので、通信買取はお勧めしない。

    買取依頼する品物の種類の量、繁忙期(コミケなどの大規模同人誌即売会の開催日前後)などにおける買取依頼の場合、見積提示が遅れたり、買取依頼(送付)してから、査定・買取額確定までに時間がかかることは、よくある話。
    自分の場合、見積り依頼⇒買取完了まで最大1ヶ月近くかかった事もある。

    個人的には通信買取は「忘れてても別にいいや」ぐらいの気長な感覚でやるのをお勧めする。

    あまり高額買取に拘らない

    中古買取全般で言える事だが、「自分の感覚よりも65%ぐらい低い査定になる」と思っていたほうが、心のストレスになりにくいかと。

    実際のところ、ニッチ。希少な品物であれば買い取り価格は高くなるが、駿河屋で取り扱っているマンガ・アニメ・ゲーム・同人という分野は、たとえニッチな品物であっても、需給が成り立たないような品物については、二束三文の買取になる。

    それ以外にも、流通量が多いもの(たとえば同人の場合、大手サークルなど発行部数が多い作品など)や、紙製品の多い分野なので、品物の状態(劣化具合)など、場合によっては買取価格が付かないこともある。

    基本的に中古買取に利益性は、ほぼ皆無

    中には利益をあげるような「プロ」も確かにいると思うが、そういう特殊な人達の事を考えるのは時間の無駄。
    あくまで「不要品を上手に処分する」程度で考えるのが良いかと思う。

    買取ルールは絶対に守る

    これは鉄則

    たとえば駿河屋で買取していない一般の生活雑貨や衣料品は送らないとか、買取依頼の書類は適切に準備する、適切な整理・荷造りを行う、などといった決まり事は必ず守るべき。
    相手との商取引の効率を重視・尊重する点からも最も重要。

    これは一般的な商取引でもそうなのだが、客は店よりも立場は上ではない。この点をはき違えている人は、商取引だけでなく、人とのコミュニケーションの在り方など、基本的な部分から考えを改めるべき。

    あとこれもよく誤解されているが、買取を依頼するのは「個人」であるのに対し、買取店は会社であり「組織」である。
    「個人」は小回りが効くし自由度は高いけど、会社や企業という「組織」は、ルールに則って運営されているものなので、個人に比べて自由度は低いもの。
    よく自身の都合とか、自分が有利だったり、自分の効率を優先する形で物事を進める方がいるが、これらは往々にして迷惑なことが多い。相手の都合に配慮して取引をすることが必要。

    まぁ「心象」だけでビジネスは成立してはいないけど、「心象」はビジネス上において重要なポイント。

    「店頭買取」「通信買取」どちらを選ぶ?

    正直なところ、何とも言えない。
    なので以下は、あくまで個人の推測。

    商業作品の場合であれば、買取相場をオンラインで確認することも可能だと思う。ところが同人作品のように、バーコードや商品コードのないような物品の場合、いちいちオンラインでは査定していないのではないかと思う。

    そうなってくると、店頭の買取担当者の「目利き」に一存することになってくる。
    別に店頭買取担当者の「目利き」を疑っているわけではないが、担当者だって人間である。個人差として習熟度や得意不得意はあるはず。

    これは、おそらく通信買取でも同様の状況が生じているとは思う。
    ただし通信買取の場合、「目効き」のスタッフが複数人いる場所での査定を行っているはず。
    その場合、たとえ習熟度が低かったり、不得意分野のスタッフが査定にあたっていても、熟練・得意分野のスタッフに確認しやすいと思うのは、邪推だろうか。

    確かに送料の問題はあるが、その点を考えると、通信買取のほうが高額になる可能性は高いかと。

    自分なりのベストプラクティス

    「あんしん買取」に「かんたん買取」を追加して通信買取する

    駿河屋には「あんしん買取」という買取額の事前見積するシステムがある。
    これは買取を依頼する側(つまり我々自身)が、駿河屋の買取Webを使って検索し、買取依頼する品物の査定額を調べてから、その内容に沿って送るというもの。
    (ただしこの時点での査定額、あくまで買取予定額。実際の買取額は、品物を送付して状態を査定してから決定となる。状態が悪いなどの理由で実際の買取額が減額されることはある
    これを使えば、買取最低額はクリアできるし、現実の買取相場も把握できる。
    (幻想を抱かずに済むという意味も、多分にある。)。

    その点を利用して「あんしん買取」でおよそ1万円分の品物を準備。残りは「追加分」として、それ以外の品物と一緒に箱詰めして送っている。

    しかしながら「同人作品」などをはじめとして、品物にJANコードや商品型番などが付属していない品物もある。
    それに「そもそも検索するという『手間』」も含め、買取検索の利用には「限界」がある。
    なので、自分の場合は、1回の発送(1箱分)あたり5千~1万円前後を目処に「あんしん買取」の品物を設定している

    「あんしん買取」には「追加分」として「かんたん買取」依頼品を同梱することが可能

    個人的には、上記「あんしん買取」の買取金額を目処に買取を依頼。
    実際に送付する際には「かんたん買取」の「追加分」を含めて大きめなダンボール箱に同梱して、発送している。

    通常「かんたん買取」のみで発送した場合、30点以上の買取であることと、買取金額が1,500円未満だと、送料が請求されてしまう恐れがある。
    しかも「かんたん買取」は、事前に買取金額が判らないからので、発送時点で送料がかかるかどうかも不明。

    これを回避するため「あんしん買取」で送料無料となる3千円をクリアし、そこに「かんたん買取」分を追加することで、なるべく多くの品を一度に発送できるようにしているというからくり。

    若干面倒なように見えるが、同人グッズなどをはじめとする買取価格を検索しても見つからないような品物については、この「追加分」として同梱することで手間を省略し、なるべく多くの品物を一度に送って買取を依頼することができる。

    ちなみに「買取検索」でヒットしないものは、個別に問い合わせて買取金額を確認することができる。
    だが、同人グッズのような品物を個々に問い合わせて金額を確認することは現実的ではないし、往々にして「現物確認しないと査定できない」「0円買取」と言われるのがオチなので、手間を考えると、とっとと送ってしまうのが良いと思う。

    箱は最大100サイズ超ぐらい、重量 20kg 前後を目標

    若干大きめではあるが、容積や箱の運搬などを踏まえると、これ位のサイズが最も現実的ではないかと思っている。
    自分の場合、近所の小さな郵便局に持ち込んで発送しているのだが、窓口や保管場所が大きくないし、ほぼ女性職員で占めるため、検量などで手持ち可能な限界として、このサイズ・重量に配慮して送っている。

    発送物によっては、このサイズ・重量にならない場合もある。あくまで目安。

    ゆうパックは30kgまで遅れるのだが、20kg超えると、いよいよ1人では持ち運べなくなってくる。それぐらいの重量。

    ちなみに小学1年生手前の平均体重が20kg。成長面において「だっこ」の限界ライン。
    (20kgだって結構な重さがあるし、個人差によって持ち上げられないとは思うが。。。)

    同じ品物は送らない

    単なる「記憶違い」や、同人の場合は「共同購入などのミス」によって、品物をダブって購入所持している場合がある。
    この場合、同じ品物を送らないように配慮すること。

    複数個の同一品を買取依頼した場合、店からしてみれば「不良在庫」に繋がるリスクが生じる可能性だってあるわけで。
    その点から買取金額が下がったり、場合によっては買取不可となる可能性もあるので注意。

    「あんしん買取」の見積依頼は月金土日曜日に出す、祝日にも注意

    見積依頼を出してから見積金額が表示されるまで、概ね2日~4日ほどかかる。

    あくまで経験からの「およそ日数」。
    買取窓口が繁忙なタイミングによっては、それ以上かかることもある。

    あとこれが大事なのですが、見積金額が提示されてからは5日以内に荷物を必着させないと、見積金額での買取が保証されなくなる。
    しかも最終的に提示される買取金額も、個々の買取金額ではなく、総額表示のみになってしまう場合あり。

    この辺を加味すると、火水木曜日あたりに見積依頼した場合、回答が週末に掛かってくる可能性が生じる。
    そうなると郵便局が休業日のため月曜日まで発送を待つ必要が出てくる。
    結果、その影響により「5日以内の必着」に遅延するリスクが発生する。

    なので、この曜日のタイミングにも十分注意すること。
    同じ理由で年末年始やゴールデンウイークなどのタイミングにも十分注意。(自分は連休に見積依頼することは避けている)

    でも、たとえ5日以内の必着から遅れたからと言って、経験上「1日程度」であれば、総額表示の買取にはなってしまうものの、ほぼ買取金額に近い金額での買取になると思う。
    (こんな「つまらない事」で客と揉める気は、店にはない思う。。。)

    ただし、相場が日々変化するような品物、例えばコミケ直後の同人誌や、入手困難な最新ゲーム機器など、「転売ヤー」の餌食になりそうな品物の買取の場合は別の話。
    タイミングに左右される品物の買取において遅延して、買取価格が安くなってしまうのは、買取を依頼する側の自己責任。

  • NVR500 の共有フォルダでハマったはなし

    SMB の話です。

    どうやら最近の Windows10 では SMBv2, SMBv3 で繋ぐみたいで。しかも SMBv3.1 つまり最新バージョン優先のようで。
    SMBv1に至っては、設定しないと接続できない状況にまで成り下がったらしく。

    調べてみると、SMBv1 はランサムウェアの餌食になったらしく、その影響で、Windows10 の途中で SMBv1 での接続が既定では無効にされたみたい。

    その影響で、NVR500 の共有ディスクは参照できないのだと思い至ったので、以下のサイトなどを参考に SMBv1 で接続できるように設定してみた。

    ところが

    いくら設定をしても「¥¥xxxxxxxx~」ではネットワーク接続できない。
    IPアドレスでもドメイン名を入力しても、だ。

    でも windows7 環境で接続を試みたところ、あっさり繋がった(共有フォルダが参照できた)。

    なので今度は試しに「ネットワークドライブの割り当て」で確認してみたところ、こちらも駄目。
    ホスト名・IPアドレス、いずれの方法でもサーバが見つからない。

    でも ping を打てば返ってくるし、そもそもルータからクライアントの IP アドレスは払い出されてる(ルータのDHCPサーバ機能は動いてる)し、そもそも Windows10 マシンからインターネットには繋がってる。ネットワーク的には問題ない。

    ここまでやって気付いたのだが、もしかしたら認証まわりか、ポリシーまわりの設定がおそらく影響している可能性を疑っている。

    断念

    とまぁ、ここまで色々なことをやってきたのだが、これ以上を色々と調べて試すとなると、今度はレジストリとかポリシーまわりの設定まで弄る必要が出てきそう。

    でも、それはそれで煩わしい(トリッキーだ)し、いよいよ本当にPC本体のセキュリティを危険に晒すリスクもありそうだし。
    そもそもそこまでして、繋ぎ込むメリットもないだろう、という気分になってきた。

    というわけで、ここで調査打ち切り。

    有効活用の模索 ⇒ 断念

    ここで方針を変えて、レガシーな共有ドライブを、ownCloud 経由でディスクとして利用できないかを検討してみた。

    …とまぁ、ここまで図を作ってみたのだが、これも結局は断念することにした。

    理由は以下。

    そこまでしてSMBv1 しか使えない機材を、ずっと使い続ける必要はのか? メリットは?

    この点に尽きる。

    いくらネットワーク上のルールを厳格にしたとしても、今のご時世、ここまでしてわざわざトリッキーなネットワーク環境を構築するだけの、自身が納得できるメリットにはならなかった。

    それにゴチャゴチャ難しい環境を構築したとしても、機材は老朽化する。
    そんな機材を無理矢理使ったとして、「それが壊れたら」と思うと、今度は復旧そのものが難しくなってしまう可能性が高い。

    それぐらいであれば、最新の機材を準備して快適な環境を手に入れたほうが、カネはかかるが、精神衛生上よろしい。
    いや、たとえ今すぐに手に入れなくても、故障したときの事を考えて、スムーズにリプレースできるような環境を維持しておいたほうが良いのではないかと、考え至った次第。

    気がついたら、機材・環境は老朽化

    スマホなど端末の進化は著しいものがあるが、それはサーバとかネットワークも一緒。
    いつの間にか(というか「あっ」と言う間に)機材はポンコツになり、ネットワークプロトコルなどの規約も進化してる。

    そう考えると、ルータやサーバの類も、それらが作られた時代のものを頑なに利用するのは、セキュリティや故障のリスクを考えると、良い手段とは言えない。

    先人の教えに「大事に使え」というような考え方もあるし、それが可能なものもある。
    しかしながらモノによっては、長く使うことが、最終的に大きな不利益を被る危険性があることも、認識しておく必要がある。

    とはいえ、カネかかるなぁ。(溜息)

    余談1、DroboFS は何故か繋がってる。

    ちなみに同じ状況(SMBv1 しか対応していないの)は、我が家で所有している DroboFS でも発生している、はず。

    そころが、なぜかこちらは、SMBv1 で接続しているにも拘わらず、普通に参照できる。読み書きも正常。何故?

    確かに DroboFS には、個々のユーザIDとパスワードを設定しており、フォルダ毎にそれぞれびアクセス権も設定している。
    対して NVR500 には、元々、代表的なユーザIDとパスワードは設定できるものの、個々のユーザを設定することはできない。

    その辺りの「違い」が今回の原因なのか?

    余談2、リプレースを考えている。

    色々と考えた結果。やはり SMBv3 に対応しているNASへのリプレースを考えている。
    そうした場合 Synology などが割とリーズナブル、かつシェアも高そうなのだが、個人的なポリシーとして NETGEAR の ReadyNAS を採用するつもり。

    ちなみに、我が家にはオンプレサーバが何台かあるので、これらの資源を有効活用すべく、フリーのNAS用OSとか ownCluod を利用することも検討した。ところが、色々調べてみて結果的に不採用。メーカーのサーバを利用したほうが安全そう。

    不採用1:フリーのNAS用OS

    FreeNAS など、いくつか代表的なOSが開発されているが、いかんせん「安定性に欠ける」というような記事が散見される。

    確かに「どんなマシンでも動くようにする」ためには、それだけ「汎用的なプログラムが必要になる」のは当たり前。
    それに対してメーカー製のNASは、製品に特化したOSを構成することになるし、それだけ「余計な部分」が削ぎ落とされている。
    つまり、安定稼働の追求力が、フリーに比べて桁違い。

    しかも最近は AWS (S3 ストレージ)などのクラウドを使ったバックアップの連携まで考えられているとなると、メーカー製NASは、その「手厚さ」も桁違い。

    それにアプリケーションサーバのOSをフリーで選定するのとは訳が違う。
    NASのOSは「ストレージデータ」というかなり大事な資産を管理している。
    これを破損することは勿論の事、サーバそのものの安定稼働やバックアップにまで考慮すると以下略。

    不採用2:フリーのオンラインストレージソフトウェア

    要するに ownCloud の事。商用に例えると DropBox が近い。

    こちらも検討したものの、やはり FreeNAS と同じで安定性やサポートに一抹の不安が残った。

    それともう1点。

    ownCloud 上で管理するファイルは、あくまでローカルファイルとの「同期による共有」となる。
    つまり、原則としては、実体ファイルはローカルにも存在することになるため、ローカルディスクの容量を逼迫してしまう。

    まぁ厳密にはクラウド(サーバ)上にのみデータを保存する形にして、必要に応じてデータをダウンロードする形での運用も可能だが、その場合は運用や設定に手間が生じることになる。

    ちなみに「その1」:商用NASとしては、Drobo も採用候補だった

    ところが、そもそもNAS製品については主力製品ではないようで、該当製品が2つしかない。
    しかも米国サイトのサポートをページを見た限りでは、SMBv2 のサポートに留まっている(SMBv3 にまだ対応していない)模様だったのと、国内シェアやクラウド連携など機能面で弱そうだったので、今回は採用を見送った次第。

    ちなみに「その2」:「個人的な理由」とは

    こちらは「続きを読む」参照。

    (さらに…)
  • 「@nifty @homepage」利用者だった人のための「@nifty ホームページサービス」について

    【2021/05/10】
    「標準モジュール」に関する記事について、認識の違いがあったので修正。

    いつも「ホームページの仕様、どんなんだったっけ?」ってなるんで、備忘録。

    経緯

    元「@nifty @homepage」利用者は、「@nifty ホームページサービス」への移行案内の際、適切に手続きをしていれば、「@niftyホームページサービス(ミニ)」というプランで移行されている。

    これは @nifty を2016年以前から契約利用し、かつ当時無料にて提供されていた「@nifty @homepage」を利用していた人向けの、言わば「救済」プラン。

    プラン毎の違い

    ちなみに「@nifty ホームページサービス」には、以下の3つのプランがある。

    • LaCoocan ライト(1G。CGIなど色々不可)
    • LaCoocan スタンダード(4G。CGI、DB利用可)
    • LaCoocan スタンダードプラス(10G。スタンダードの大容量版)

    「ミニ」プランから「LaCookan スタンダード」「LaCookan スタンダード」のプランに変更することは可能。ただし変更後は、再度「ミニ」「ライト」プランに戻すことができない。

    「@nifty ホームページサービス」既存の各種プランと違うところ

    • ディスク容量が2GB(ライトは1GB、スタンダード4GB、スタンダードプラス10GB)
    • CGI は Perl のみ利用可(ライトは利用不可)
    • CGI 定期実行が利用可(ライトは利用不可)

    機能の違い

    「@nifty ホームページサービス」への移行によって変わった機能

    プライベートパック

    アクセス制限機能(.htaccess、.htpasswd)による BASIC 認証に変わる(利用には再設定が必要)。

    SSLも未提供。

    URL

    別物のサービスなので、URLも変わる。

    FTP

    サービス自体が別物扱いなので、すべて再設定が必要。
    接続先ホスト名・アカウント名などが変更になる。

    CGI

    ホームページアドレスとCGI環境のアドレスが統合され、すべてホームページアドレス内で動作するようになった。
    つまり cgi-bin ディレクトリがなくなり、すべて homepage ディレクトリ配下で、HTML ファイルと同じ場所にCGIの実行ファイルを設置し、そのファイルに実行権を与えれば動作するようになる。

    「@niftyホームページサービス」では提供されなくなった機能

    • アクセスカウンター
      (自前CGIで実現可能。だが今時のコンテンツにおいてアクセスカウンターは流行らないし機能不足。解析用途であれば、Google Analytics などを導入するほうがよいと思う。)
    • サクサクかきあげ君
    • 簡単マイページ設定
    • 公開停止・再開機能(アクセス制限機能で代用可能)
    • 素材集(巷のWebコンテンツから拾えばよい)

    「@nifty ホームページサービス」から提供される新機能

    • CGI 定期実行(LaCoocanライトを除く)
    • .htaccess(アクセス制限)
    • 独自ドメインの利用(ドメイン取得や維持は別料金)
    • カスタムエラーページ

    LaCoocanスタンダード(プラス)にアップグレードすることで提供される新機能

    • sendmail
    • アクセスログ解析
    • 簡単インストーラー(WordPress などが導入可能、らしい)
    • データベース(MySQL、SQLite)

    Perl(CGI)について

    Perl 5 標準モジュールが一部欠けている

    @homepage 時代と同じ。
    ちなみに、perl 5.8.7(2021年3月時点)

    ちなみに公式的には標準モジュールは提供しないとしているが、実際のところ、一部は利用可能。
    しかしながら、例えば「DB_File」や「DateTime」モジュールが利用できない等、便利なモジュールが一部省かれている。
    それに、今は使えているモジュールが今後使えなくなる可能性だってある。
    なので、意味合いとしては標準モジュール提供は保証しないという形で捉えるのが妥当。

    その影響により、ファイルアクセスだろうが、データアクセスだろうが、何をするにしても、原始的なレベルの作り込みが必要になる場合がある。

    よって「@nifty ホームページサービス」における Perl は、かなり単純な機能のみを提供するようにしないと、開発・保守の両面からコストが発生することを念頭に置く必要あり。

    自分の場合も、バックオフィスは別プロバイダで提供されている PHP と MySQL などで実装し、「@nifty ホームページサービス」はフロントエンドに徹し、Webコンテンツの稼働に必要なデータ類を、可能なかぎり構築してから転送している。

    具体的には、バックオフィスにて tsv 形式のデータファイルなど、フロントエンド用のWebコンテンツ動作に必要なデータを構築・管理。
    フロントエンド側では、バックエンド側からアップロードされたデータファイルなどを Perl を用いた CGI で動作させている程度に留めている。

    ちなみに自分で必要な Perl モジュール(パッケージ・ライブラリなど)を設置することで「@nifty ホームページサービス」上で高度なWebコンテンツを構築することができる可能性はある。

    ただ個人的には、今のご時世、小手先でゴチャゴチャ調整するのは時間がかかるし、ライブラリのアップデート時などの追従性やセキュリティ面も考えると不安。
    もしそのようなコンテンツを実現したいのであれば、コスト面も踏まえると、もっと別の自由度の高いプロバイダーのサービスを使うと思う。

    そもそも「@nifty ホームページサービス」が、いつまで CGI のサービス(というかホームページサービスそのもの)を提供してくれるかも不明。
    (昨今ISPのホームページサービスは、契約者の利用率も右肩下がりなうえ、システムアップデートの追従やセキュリティなどの観点からコストに見合わず、提供終了されつつある。)

    ここまで考えると、他のプロバイダーサービスを利用するほうが良いのではないかと。

    use strict; use warnings; は役立たず。

    とは言っても「外せ」という意味ではなく。

    「@nifty ホームページサービス」は、(@homepage サービスの時代と同じく)ブラウザ上では全部500エラーが表示されるだけ。
    また管理画面等からエラーログを確認するための手段もない。そのためエラーが発生しても、原因を掴むことは至難。

    実際には、デバック文を挿入したり、変数を表示させるなどの手法で動作確認したり、ソース全体を、

    eval {
      ...(CGIソース本体)...
    };
    if ($@) {
        print "Content-type: text/html\n\n";
        print "<title>error</title>\n";
        print "$@\n";
    }

    で囲い込んで、無理矢理エラーを表示させることも可能かもだが、正直微妙。

    自分の場合はエラーを追跡するため「だけ」に、標準モジュールの存在しない開発・動作確認用のサーバを別途建てて、それから「@nifty ホームページサービス」にデプロイしています。

    この環境を構築するのが一番面倒、という話もある。

    【参考】使い道

    これらサービスの制約下でも、当方では無駄なく使っている。
    以下参考まで。

    ちなみにいずれのコンテンツも、管理機能はWebプログラミングが可能な別サイトに構築。

    期間限定の共有フォルダ

    URLを知っていればアクセスできるようなファイルを置く場所。
    期間超過のファイルは、「CGI定期実行」機能によって削除。

    ただし前述の通りSSLが使えないため、盗聴されると可能性あり。そのため、そのリスクを負っても問題ないようなファイルしか扱えない。

    画像アルバム

    風景写真とか。素材写真とか。
    こちらも当方(撮影・作成者)で権利関係の弊害がなさそうな画像を公開するために作った。

    郵便番号⇒住所変換

    文字通りのツール。
    そもそも tsv 形式のデータの抽出速度がどれ位かかるのかを調べるため、実験的に作ったもの。
    現実的な速度で提供できるように試行錯誤しながら提供中。

  • 車に求めるもの

    以下、あくまで個人的な意見です。
    個人によって考え方には差があるはずなので、その点ご了承ください。

    個人的に自車は所有せず、カーシェアとかレンタカーがライフスタイルに組み込んでいるので、様々な車種に乗ることが多いのだが、今回初めてトヨタ C-HR というコンパクト SUV なる物を運転してみたので、その感想まわりとか。

    「SUV」と「コンパクト」を併せ持つのって、何だか本末転倒というか相反するというか。。

    コンパクト SUV

    乗用車の総合的な利便性は、コンパクトカーよりも劣る。
    SUV 並みのゴツい足回りにはなってるし、外装がカッコもよくて、フロント席のラグジュアリー感も確保してるけど、逆に言えばそこに徹底してるだけ。

    フロントガラスは狭いし、サイドなど車両全体が丸みを帯びているため、とにかく視認性が悪い。

    後席がとにかく狭い。クーペ並みに足下が狭い。
    カップルとか単身者が乗るならまだしも、ファミリーにはお勧めできない。

    T-CONNECT

    carrozzeria (Pioneer) に慣れてしまっている自分としては、どうにも機能不足。
    直感的操作の際、違和感を感じる。

    あと個々の機能についても洗練差がある。

    たとえばマップ表示中にマップボタンを再度押しても、ユーザが設定した縮尺のマップにならないとか、ナビとは関係ない部分、ラジオのエリアプリセットひとつにおいても、練馬だと埼玉のプリセットが表示されたり、ワイドFM帯が表示されなかったりとか、重箱の隅的な。

    クルーズコントロール

    トヨタ車のコントローラーは、ウインカースイッチ(バー)の下部に、別途、コントロールバーが設置されていて、それで制御するんだけど、これがイマイチ使いにくい。

    ホンダ車のように、ステアリング上にコントローラを設置してほしい。

    居住感と容量

    SUVにはどうも高級車のようなラグジュアリー感を求めている人がいるようで、それが各所に詰め込まれているが、個人的にはそこまでラグジュアリー感を全面に出す必要はないと思う。
    それなりの居住感については確保してほしいとは思うけど。

    背丈体格の違いがあっても、疲れにくい運転ポジションが確保できるとか、フロントやハンドルの位置や視認性、疲れにくいブレーキやアクセルのポジションなど、人間の五感がどうしても頼る必要が車にある以上、その部分に対しての洗練化を伸ばしてほしい。

    荷室容量は、それなりに確保してほしい。

    リア席を潰せば、それなりの荷室空間を確保できるのは判ったから、普通に荷室サイズを確保してほしい。

    まとめると

    とまぁ小型SUVの評価としては、

    コンパクト SUV に乗るぐらいなら、
    普通(3ナンバー車)の SUV を無理して買え。

    こんなところでしょうか。

    余談

    個人的な会社別車両評価。

    独断と偏見に満ち満ちてるので、読む方は自己責任で。
    意見は求めてません。

    トヨタ

    ザ・大衆車。良くも悪くもスタンダード。
    普段の街乗りから長距離まで一番普通に乗り回せるから、どうしてもこれが第一選択(基準点)になってしまう。

    ホンダ

    5ナンバー車の出来は良い。スピードの伸び・バランスが良いし、車内の広さに拘りがあるようで、居住性が上々。
    個人的にはACCがステアリングに組み込まれている点がお気に入り。
    ただトヨタにちょっと及ばない部分があるような。重箱の隅的な。

    マツダ

    コンパクトカーでも速度重視な感じ?
    スピードの伸び・バランスはホンダ車以上。でも車内の広さが、どの車種も気になってしまう。

    ニッサン

    昔は良かった。ある意味、トヨタ以上の標準な車だったし。
    今のニッサンはどこに行きたいのか、正直良くわかんない。
    EV専業になるなら、それもいいんでない?
    会社もゴタゴタしてるし。

    スバル

    多分、一度も運転したことがないので、態度保留。
    最近ゲンキな会社なので、気にはなってるんですけど。

    三菱

    以下同上。
    てか、もはや「何の車種作ってるんだっけ?」のレベル。

    スズキ

    全体的にアクセルがフニャフニャ感が気になる。アクセル踏んだときとスピードの「伸び」に独特な感じがするのは気のせい?
    二輪も含めてスズキはスズキ。

    ダイハツ

    ザ、軽自動車。

  • フォトアルバムを設置する

    こちらの記事は、今後のシステム開発で経過に応じて、随時編集・追記します。

    プロバイダーのホームページ領域を有効活用するため、フォトアルバムでも設置しようかと考えている。

    まぁ「フリーのCGIとかプログラムを導入すれば、いいんじゃね」というレベルの、とてもありがちなシステムをつもりなんだが、それら「吊るし」のシステムだと、自分が契約している Web サーバ領域を有効利用するためには、仕様・環境などの条件がイマイチ合致しない。

    特に問題となるのがこれ。

    @nifty ホームページサービス ミニプラン

    そう。
    公開ページの設置を予定しているこのWeb領域が、曲者。
    もともとは、老舗の「@nifty @homepege」の後継で、先代で提供されていた機能を、最低限継承した代物。

    なので、Perl は使えたりするものの、5.8.7 と古かったりとか、一部の標準モジュールが使えなかったりする。
    PHP も、このプランでは使えない。

    別の記事でも書いたが、上位プランに変更することにより、PHP やデータベースが利用できるようになるのだが、料金や自由度を考えると、別会社のプランを検討する。

    確かに巷の Perl CGI を探してきて、それを改造して無理矢理動かすというのも一案。
    しかしながら、それだと楽しくないし、そもそも巷の Perl CGI も、かなり前に作られたものが多く、レガシーな作り物が多い。

    そんなこんなの理由で、昨今のスタンダードな Web システムの実装とレガシーなサーバ環境の共存を研究する目的で、フルスクラッチしてみることにした。

    システム構成

    ありがちな「公開系」と「管理系」の2構成。

    フロントエンド(公開系)

    サーバは「@nifty ホームページサービス」
    Web コンテンツは「Perl (CGI) + Vue.js (CDN)」で実装。

    こちらは「見せるだけ」の機能に特化して、複雑な処理は走らせない。
    というか、制限付き CGI (Perl 旧バージョン+標準モジュール一部欠け)をゴリゴリ開発する気は、更々ない。

    Vue.js を利用するものの、フレームワークというよりは、結果セットのフィルタリングやソート時のエフェクト用途で利用する感じ。
    ほぼ「受け身」のシステムなので、この程度の簡単な環境で構築。

    バックオフィス(管理系)

    サーバは「さくらの VPS」
    Web コンテンツは「Laravel (PHP) + Vue.js(Laravel のUI として利用)」

    こちらは管理機能を実装するため、Web システムとしてはガチ。
    とはいえ、昨今の Web システムでは、割とスタンダードな環境。

    ちなみに Laravel が Ver.5.x までであれば、Vue.js は内包されていたため、「さくらのレンタルサーバ」でも構築できた。

    しかしながら Laravel Ver.6 以降、Vue.js はコマンドで追加インストールするようなスタイルになった。
    しかもこのコマンド、中で npm を使用するのだが、この npm が「さくらのレンタルサーバ」がインストールされていない。

    調べた限りでは「さくらのレンタルサーバ」に npm を力業でインストールするような猛者もいたようだが、当然ながらトリッキーなため、この時点で「さくらのレンタルサーバ」も採用外とし、「さくらのVPS」への実装とした。

    個人的には、今後のシステム開発において「さくらのレンタルサーバ」は、パッケージ不足等で、いよいよ「使えない」という時代がやってきた事を感じてしまった瞬間であった。

    公開系と管理系、「さくらの VPS」で構築すれば楽じゃね?

    確かにそうなんだけども。
    でも、元々「さくらの VPS」は、非公開系のサーバとして運用しているという個人的な事情と、公開系と管理系を同居させることによるセキュリティ面の配慮で分けた次第。
    また「レガシーな Web 領域(=@nifty ホームページサービス)を有効利用する」という命題に応えるため、このような環境にした次第。

    重要な考慮すべき部分

    バックオフィス⇒フロントエンドの同期

    データの追加・更新・削除の都度、キューを作成し、それを非同期バッチにて処理する事によってデータの内容をフロント側に反映することで同期する。

    クラッシュ対策(バックアップ)

    システム基盤(プログラムソース)については、別途バックアップする(というか、Git に保管しておく)のが前提。
    ここで言うのは、データの話。

    ちなみに、この Git リポジトリ。PostHook で別サーバに Fetch してるので、リポジトリ自体も複数保存している。

    公開系

    もともとデータはすべて「管理系」に保持していて、そこから抽出・アップロードされるため、クラッシュしても、データは「管理系」のほうから再度抽出することでリカバリ可能とする。

    管理系

    データについては、日毎のバックアップをバッチ処理し、バックアップサーバ(ストレージ)に転送する。

    考えていること

    データ連携

    最初はこんな感じで考えていたのだが、もしかしたら Perl の簡易データベース(dbmopen など)が使える可能性があるので、利用可能であれば、その形式に寄せるつもり。

    画像

    閲覧用画像データには、コピーライトの埋め込みで、以下の候補を検討中。(TBD)

    • ウォーターマーク ⇒ ImageMagic で可能だが、簡単に消せる。
    • 電子透かし ⇒ できればこっちを考えている。
      ステガノグラフィーが主流だと思うけど、技術的に標準化されてないので、できれば標準的なのが使いたい。
  • 談合坂SICを利用する場合、鳥沢駅側からのアプローチは危険

    大月から談合坂 SIC を利用する際の話。

    まぁ素直に大月 IC から中央道に入るのが正しいとは思うが、今回は猿橋寄りでの用事だったのと、真夜中だったので、このまま R20 を進んでも良いかなぁと思ったのです。

    ただ、深夜の R20 をほぼ制限速度で走っていたこともあり、後ろから大型トラックに煽られてた感もある中、鳥橋駅界隈を通過したところで偶然「談合坂 SIC、←」みたいな標識を見てしまい、何も考えずに、そちらに入っていってしまった。

    これが良くなかった。

    地図を見ていただければ判るのですが、実は凄い山道(急勾配・ブラインドカーブ多数)を超えることになります。
    こんな山道を走るのなら、上野原 IC まで R20 を普通に進んだほうが速い気もします。

    集落内など一部狭路の箇所はあるものの、SIC 設置の効果か、かなりの部分が2車線(片道1車線)に拡幅されてます。
    しかしながら無理矢理拡幅した感じは否めず、急カーブが連続。
    普通車でもセンターラインを超えず、車線を維持するのは困難な箇所が多数。それにあまり路肩に寄り過ぎると、今度はフタのない側溝に落ちる恐れもあるような道。
    しかも急カーブだけでなく急勾配も凄い。下り坂でもだと1速とかエンジンブレーキ全開にしないと、すぐスピードが上がってしまうような道でした。
    正直お勧めできません。

    しかも深夜はかなり真っ暗。街灯は点在してるものの、お世辞にも整備されているとは言えない状態。
    さすがにこの時期(3月上旬)は遭遇しませんでしたが、暖かくなるとケモノが出そうな空間を通り抜けます。

    この道(山梨県道 30 号大月上野原線、r30)は、扇山の麓付近にある旧甲州街道になぞられた道で、途中恋塚(一里塚)や犬目宿(宿場)を通過します。その旧道そのもの、または旧道に沿って整備されているため、勾配やカーブがキツいのです。

    ちなみに現在の国道(R20)やJR中央本線は、もっと下にある桂川流域に沿っており、中央道はそれよりも山間部を通過するものの、トンネルと橋で通過しています。

    また地図を眺めたかぎりでは「コモアしおつ」ニュータウンのある四方津駅の方、山梨県道 507 号野田尻四方津停車場線(r507)からであれば、急坂・若干の狭路(1.5 車線)ではありそうなものの、まだ利用し易い気がします。
    とはいえ、四方津の方々は上野原IC・大月ICをそれぞれ利用してる気もするのですが。どうなんでしょうかね。。。

    夜景
    上野原市犬目(旧甲州街道犬目宿の東側)に設置された
    大野展望台(見晴し台)から中央道上り線、談合坂SAの夜景

    余談

    この SIC、整備目的の一つとして「コモアしおつ」ニュータウンから下り線方面の利用効果を謳ってますが、正直どの程度の利用数があるのか疑問が残ります。
    たしかに利用者皆無ではないとは思いますし、R20が事故や災害等で利用できない場合の効果の可能性は否定しませんが、整備をペイする程の効果があるとは、正直疑問。

    しかもハーフインターチェンジではなく、フルインターチェンジ。
    さらに言うと、構造上、下り線は談合坂サービスエリアは利用できないのに、上り線はわざわざ談合坂サービスエリアも利用できるよう、市道までガッツリ整備されている。

    ちなみに、この周辺にはゴルフ場が3つもある。特にうち1箇所は中々のお値段。

    正直、勘ぐってしまうのですが。