カテゴリー
おすすめ

やはり俺の青春ラブコメはまちがっている。完

個人的には面白いのだが、シリーズ第3シーズンを観るためには第1・2シーズンを観ないでこのアニメを観ると、まったく内容が唐突すぎて理解できない作品と思う。
そういう意味では本来、第1・2シーズンの総集編のような尺を制作するなど、視聴者の理解を得る・取り込むには、もっと工夫をする必要があったと思うのだが、それができていないのは極めて残念。

大人の都合上、通しで制作できないのは理解できるが、それによって、本来の利益性が失われてしまうことをコンテンツ制作陣が理解できていない訳ではないとは思うのだが、どうなんだろ。
それとも、これもコロナの所為なのか? コロナなのか?

視点は変わるが、この原作でアニメ(ラノベ)にしとくのは、正直なところ、勿体ないレベルの作品のような気がする。

でもじゃあ、テレビとか実写でアニメを超えられる作品ができるかというと、それはそれで、おそらく今の役者・制作陣では難しい。
どんなにスゴい役者を起用しても、この原作と絵のバランスは超えることができない。
それぐらいアニメ(絵)と原作(シナリオ)の親和性が高くなってしまっている。

あとアニメ絵と声優によっても、観る側には更に強固なバイアスがかかってしまうご時世。
なんなら、原作とイラスト=ラノベという時点でも、バイアスは既に存在してると思う。

それに原作は文字である程度が補完できる表現があったとして、これをアニメでは辛うじて可能だったとしても、実写の場合は不自然になってしまうような表現も多分にある。
実写作品の場合、そのような表現を役者と制作陣が超えなくてはならないのだが、これが実際の話、かなり難しい。

作品自体は、とても面白いと思う。
でも客観的ながら、そんな事を少し感じさせてしまう作品。

前期(第2シーズン)までは、そこまで感じることはなかったんぽだが、今期は特に偏りがスゴいのは、何だろう。
おそらく結末を迎えるからなのかな。

カテゴリー
ブログ

練馬大泉から足柄までの車移動ルート

今年はコロナ禍という事で、実現見送りですが、行楽やら帰省やら仕事やらで運転するそのたびに、自宅のある練馬大泉から東名方面に向かう際のルート選択にいつも迷います。

そのため今回は理論的に整理すべく、ルートのメリット・デメリットを検証をしてみました。

その1、環八・東名ルート

97km(うち一般道15km)、所要1時間30~50分。

環八⇒東名東京ICという、最もスタンダードなルート。

メリット

ルートとして判りやすい。最短。

デメリット

環八でも最も混雑するルートを通るため、午前中を中心に渋滞にまきこまれる。

環八は交通量が多く、信号も多い。
「上高井戸1丁目」「三本杉陸橋」交通情報ラジオでお馴染みの渋滞ポイントなど、立体交差になっている箇所も合流部を中心に渋滞する。

このルートでは混雑時に東名入口まで1時間半もかかることは、よくある話。
それに東名に入ってからも、海老名JCTを超えるまでは「大和トンネル」など、有名な渋滞ポイントが複数存在する。

夜中など空いている時は利用するものの、混雑時は避けたいルート。

ちなみに、環八を利用しない方法として住宅街の道(生活道路)を抜ける方法があります。
ただし、都内の生活道路は一方通行や狭路がとても多く、事故のリスクがとても高いです。そのため非推奨の意味も踏まえて、今回のルート選択(時間や距離の検討)からは除外してます。

普段利用することのない生活道路を迂回ルートとして利用するのは、とても危険なのでやめましょう。
あえて犯罪者になるリスクを冒す必要はないですし、地元の生活者からしてみても、とても迷惑なので。

対して、環八ではなく環七、山手通り、首都高C2、明治通り、C1という感じで都心主要道に迂回するのは、選択肢として「アリ」です。

しかしながら練馬から東名方面に向かう場合、これら迂回先にも渋滞リスク、一般道経由の場合は右折が伴う点(=左折よりも時間がかかる)、迂回による距離増加になってしまい、時間の短縮はそれほど見込むことができません。
そのため非推奨ではありませんが、「あえて」今回のルート選択候補からは外しました。
ただし「東名・環八ルート」選択後、途中でこれらルートに切り替えるのは、ありかも知れません。

その2、中央道ルート

117km(うち一般道12km)、所要1時間40分~2時間。

伏見通り・新武蔵境通り(都道7号、12号)⇒中央道調布IC⇒八王子JCT⇒圏央道⇒海老名JCT⇒東名という、少し遠回りなルート。

メリット

環八を回避できる。渋滞をストレスに感じる人にとっては、大きなメリット。

デメリット

環八ルート同様、中央道に入口までの一般道が混雑する。
新武蔵境通り(都道12号)の工事が終了し、西東京(保谷)から深大寺付近まで全線2車線となった。そのため以前より渋滞は短くなったものの、信号が多めなのが難点。
また深大寺の先から甲州街道交点となる「下石原」交差点は、片道1車線のため、渋滞しやすい。
環八ほどの混雑ではないが、「下石原」交差点は甲州街道や調布ICに抜ける最後の右折交差点。右折車も多く、道も狭い。そのため右折するまでに時間のかかることが多い。

ちなみに、これを回避するために途中の「野崎八幡前」交差点から東八道路に右折し、すぐ先の「天文台北」交差点から「天文台通り」に迂回するルートがある。

この「天文台通り」は武蔵境駅付近が起点で新武蔵境通りと並行しているので、より手前から迂回ルートとしての役割を担っている。
そしてこのルートは、最終的に「上石原」交差点で甲州街道に出ることができる。しかも交差点「左折」で中央道入口に入ることが可能。つまり「上石原」交差点「右折」よりも、より早く中央道にアプローチでき可能性がある。

しかしながら「天文台通り」は全線片道1車線。そのため朝夕ラッシュの時間帯は混雑すると思われるので、迂回するにしても注意する必要あり。

その先の中央道は、2車線なので交通量はやや多め。時間帯によっては渋滞する。
さらにその先の圏央道は、長大トンネルによって線形は比較的良いものの、こちらはいわゆる「トラック街道」。かつ全線2車線。海老名JCTなど東名合流を中心に渋滞しやすい。

その3、関越道ルート

147km、所要1時間50分~2時間10分。

関越道練馬IC⇒鶴ヶ島JCT⇒圏央道⇒海老名JCT⇒東名。大廻りルート。

メリット

一般道は地元の一部だけ、ほぼ高速。

デメリット

環八・東名ルート+50kmなので、さすがに遠回り。
そのぶん高速料金も高くなる。

でも一般道で1時間以上タイムロスがあるなら、選択肢に入れてもよいかも?

「中央道ルート」記載の圏央道のデメリットと、狭山PA付近、あきるのIC付近、海老名JCTなど、渋滞ポイントがさらに追加される。

ちなみに最近、逆ルートを走行したのだが、交通量が少ない時間帯の走行はかなり楽なものの、圏央道は物流街道らしく、トラックの通行が多い。そのため IC や PA の合流やトンネル内のサグ部や急カーブ、車幅も若干狭いので、注意が必要。
関越道は3車線なので、かなり運転は楽だが、大泉・練馬の起終点は外環道の工事の影響で、車線ルートの変更が頻繁に行われるので注意が必要。

ルート選択のポイント

個人的には利用する時間帯によって「環八・東名ルート」か「中央道ルート」を使い分けてます。

夜間・早朝(午前6時ごろ)までに環八ルートの半分以上を通過できる、1時間以内に東京 IC に着けるのであれば「環八・東名ルート」。それが難しい場合は「中央道ルート」という感じ。

ただし「環八・東名ルート」と「中央道ルート」の差は、結果的には「誤差の範囲内」であると思います。
工事や行楽シーズンなど、ある程度決定的な判断材料となる点もあるとは思いますが、事故などの突発的な状況が発生したりすると、あっと言う間に予想が外れてしまうので、あくまで参考程度といことで。

「関越道ルート」については、さすがに遠回りなので、あまり現実的ではないのかもしれません。
ただ中央道の集中工事が発生する場合、時間帯によっては選択肢になると思っています。

余談

個人的には外環の関越・東名区間が開通すれば、言わずもがな、このルート一択(本命)になると思ってます。
渋滞も予想されますが、厚木まで1時間あまりで到着できるのが現実的になるのかも。

余談その2

ちなみに実家が三重にありまして、今まで帰省には新幹線をよく使ってました。

ただ、新幹線は確かに速いのですが、練馬⇒東京、名古屋⇒三重の在来線の移動と乗り換えに時間がかかるため、結果的に4時間以上かかってしまいます。

対して、ここ数年の新東名・新名神開通や、新東名の静岡区間の一部120km/h化の整備などによって、車でもノンストップであれば、理論上は5時間台で帰れることが判明しました。
実際には途中休憩や食事などを挟むため、早くても8時間ぐらいの余裕を見て帰ることになりますが。

運転手は確かに疲れます。ただ新東名の場合、東名に比べると線形が圧倒的に良く、走行時のストレスは軽減されます。

あと個人的にはクルーズコントロール(ACC)とレーンアシスト(LKAS)搭載車両を使用しています。
安全面や車線変更の必要性などから、ハンドル操作やブレーキ操作は必要ですが、巡航と車線維持のためのアクセルやハンドル操作が不要なのと、高速道路でも特に線形の良い新東名は、かなり楽に運転できるので、休憩回数も減らすこともできるのではないかと。
ただし楽に走れるぶん、眠気には注意が必要。寝不足や体調が悪い時などはとても危険です。

それを考えると、子連れで、大きな荷物を持って鉄道移動するのよりは、途中で気軽に観光地へ立ち寄ることが可能な、車での帰省は選択肢として十分ありです。

カテゴリー
ブログ

フリーのIT技術者とコロナ禍

あくまで個人的なケースなので、参考程度で。

自分はIT技術者として25年以上、フリー(個人事業主)になってからそろそろ10年が経とうとしています。

個人的にはリーマンショックを中心として不景気、東日本大震災に続く、大規模な社会現象ではないかと捉えています。

ところが個人的には意外にも焦っていない自分がいるのです。
その理由を考えてみました。

景気が萎んでいない

確かに社会的には、企業決算や各種経済指数が軒並み厳しい数字や予想を叩き出しているのは事実です。でもなぜか現時点での商取引はふだんとほぼ変わりない状況、というのが個人的にな感想です。
というのも、確かに自分の一部の取引先で、かなり厳しい状況に陥っている方もいるのですが、ビクともしていない取引先が大半なんです。

この状況、個人的には東日本大震災のような一時的な災害に近い経済状況なのかなと思っています。

確かに飲食店や各種サービス業など様々な業種をはじめ、様々な方が影響を被ってます。

それに戦争や未曾有な自然災害、経済的なショートが発生すると、もっと長期的な不景気感が一気に襲ってくるはずなんですが、それがまったくないんですよね。

「情報サービス業」ありきの社会になった

以前といいますか、2000年位までは情報サービス業というのは、ビジネス産業の中では、情報通信業(電話や携帯などの物理的な産業)や、その他の生産業の副産物のような位置づけだったんだと思います。

それがここ10~20年で「情報サービス業」が存在し、それを使って各種産業が成り立っているという、まったく逆の構造になってしまいました。

これによってIT技術者は、スキルと経験を適切に習得すれば、ニーズのある職人であるだけの位置づけになり、収入も得ることができます。

それに現在は、マッチングビジネスやエンジニアをビジネスと繋ぐ事業者も存在するため、スキルとビジネスセンスさえ守れば、収入に困ることはないと思います。

資産・貯蓄

他の業種、特に飲食店などのサービス業については、予想以上に自転車操業となっているのに驚きました。

たしかに気の毒ではあるのですが、ここまで「補償!補償!補償!」と言われるぐらい、脆弱なビジネスを営んでいる方が多いとは、思ってませんでした。

確かに日本の飲食店産業は、家賃・労働保険など固定費部分高額なうえ、設備などの「借入金」、人件費などを考えると、貯蓄は困難なのかも知れません。

でも、それにしてもです。固定費と借入金の返済だけで貯蓄などの「予備費」の部分が一切ない状態でビジネスを営むのは、正直リスクが高すぎると思います。

幸いな事に、フリーのIT技術者は、一時的にパソコンなどの経費はかかりますが、自身のスキルベースだけでも可能なビジネスです。
「予備費」つまり、何かあったときの貯蓄や資産形成の敷居が低い分野の職業であったのも、このコロナ禍でも余裕を生んだ要因だったのではないかと思います。

「新しい生活様式」に向けて

現時点での社会をみるかぎりでは、人々はかなり楽観的というか、どちらかと言えば「諦め感」が漂ってます。まだまだ明るい展望が見えない感じではあります。
こんなコロナ禍を(できるのかはさておき)駆逐するのか、共存する社会になるのかは、まだ判りません。

でも個人的には「転機」だと思っているので、何らかの成果が見出せるとよいなぁと思ってます。

その結果は、10年後ぐらいに記事にできるといいなぁと思ってます。

カテゴリー
ブログ

ピンハネ 中抜き

「中間マージン」と言えば聞こえはいいですが、要は「ピンハネ」「中抜き」「中間搾取」ですよね。

つい数年前までは、人材派遣業の代名詞みたいな言葉でしたが、建設業の孫請けとか、情報サービス業などの技術者でも、この多層構造が横行していました。

現在は法律により「ある程度」規制されましたが、それら法律ですら、業界各社のロビー活動や献金活動により骨抜きにされていたり、法の合間を縫うようなグレー(つまり法律的には問題ないけど、倫理的にアウト)な手法を用いて、事実上のピンハネ構造は、未だに横行しているのが現状だと思います。

確かに派遣関連については、現在は法令によってマージン率の公開が義務付けられています。よって派遣労働者も「見かけ上」は、保護されていることになってます。
ところが実際には、派遣労働者の見えないところで「キックバック」のような「会社間だけの取引」が未だに組織間で存在してたりして、実際には中間業者がよりズル賢くなっただけなのです。

もちろん、法令が骨抜きになったことも原因の一因ではあります。でも日本のビジネスは、これらの監視するための、独立した組織構造が、そもそも手薄です。

消費者センター? 公正取引委員会? 労働基準監督署? 警察などの司法機関? どれも違います。厚生労働省「本体」しかないんです。

少し余談になりますが、もともと日本のビジネス構造は、近代以前の歴史的にも役人と小作人の間をつなぐ位置づけとして「庄屋」や「町や村の名主」というものが存在していました。
この「庄屋」や「名主」という「中間組織」が、江戸時代という長きに渡る天下太平の時代の中で育まれ、その中で利益を得るための手法として、ピンハネという構造が社会システム上「当たり前」のものとして認知されたんだと思います。
もちろん「小作人共の代表・名主格」として、本来の適切な運営をした庄屋も、中にはいました。でも、それに対してピンハネをするような庄屋だって沢山いた筈です。
このようなピンハネのビジネス構造は、古くから存在するため、もしかしたら、日本人の遺伝子として擦り込まれてしまっていて、

もしかしたら、この構造は日本だけではなく、ビジネス社会においても一般的なものなのかも知れません。

それに個人的には幸いなことに、この商構造に則っても、収入を不満を感じない程度のスキルを身に付けていれば、目を瞑ることはできると思います。

でもやっぱり、この商構造がとても嫌いです。反吐が出ます。

これを何とかできないかと思っていましたが、昨今の IoT の普及や流通構造の変化によって、各種プラットフォーマやマッチングビジネスによって、ビジネス界内部である程度の自浄が見えてきました。
つまり、今までの「中間組織」のような事業者は淘汰される可能性が出てきています。

ところが、今度はプラットフォーマやマッチングビジネスの事業者そのものが、新たな「中間業者」になる危険性があります。

これらを防ぐ手立てはないのでしょうか。
そこに本来「行政」があるべきだと自分は思います。

  • 行政(監視監督)
  • 中間業者
  • 作業者

この三者構造があって然るべきだと思うのですが、現状このバランスを考えると、中間業者の「力」があまりにも偏っているとしか思えないのが現状ではないかと。

カテゴリー
技術メモ

python2.x の csv.open() は、文字コードの対応が壊滅的

よくよく調べてみると、どうやら ASCII コード文字以外は対応していないらしい。

ということで、python3.x のインストールやり直し確定。

まぁ codec.open() 使って、あとで頑張ってパースするのもいいんですが、3.x 系で対応してるなら、わざわざ無駄な労力払わないくても、それ使えばいいじゃないですか。

どうりで、さくらのレンタルサーバだとpython 2.x系が標準で提供されてるのにもかかわらず、python 3.x 系をわざわざインストールしてる人と(いうか記事)が多いなぁと思ったら、こういうことだったのか。
2.x 系と 3.x 系の間には、文字コード関係をはじめ、かなり大きな進化点があるんですね。

なんだか 昔の Perl を思い出したよ。
jcode.pl, jcode.pm とか、懐かしいな。。。

カテゴリー
ブログ

Eclipse よ、今までありがとう

およそ10年弱の今まで、Windows の IDE として使ってきたけれども、そろそろお別れの時がきたよ。

今思えば、キミとの付き合いは紆余曲折の連続だった。

私がサラリーマンの頃、まず出社してやることは、パソコンの起動、そして次に Eclipse。そう、キミの起動だ。
会社から支給されたパソコンはとても非力で、キミの起動には数分の時間を要したのをよく覚えているよ。そのお陰で、起動操作ののち、僕はトイレやコンビニに行って、朝の優雅な時間を過ごすことができた。

でもそんな怠惰な生活に嫌気がさして、NetBeans に一度浮気したこともあったね。
その Netbeans も、一時オラクル社に浮気したお陰で(?)、バージョンアップがパッタリ止まったりしたことがあって、そんな浮気騒動も一度きり、僕は目が醒めて戻ってきてしまったけど、君は文句も言わず、相変わらずの怠惰な起動で優しく出迎えてくれた。
そんな出来事も含めて、いい想い出だ。

でも僕は、新たな旅に出たいと思う。そう、いよいよ戻らない、新たな旅に。

今までありがとう、Eclipse。
きっと君のことは忘れないよ。(多分?)

…というわけで、Visual Studio Code(VSCode)に鞍替えです。
だって起動が速いし、Extentions も沢山そろってるし、PHP の各種フレームワークバリエーションにも対応してるみたいだし。
それに C/C++、Java、Python、Perl、Ruby など、仕事柄、多言語を使用する立場として、各言語対応なのは、とても有り難い。

UI も Windows ライクなのも良い。
Visual Studio ライクな感じで、本家の血筋なのも良い。

要するにミーハーなだけなんですが。
でも使い勝手が良ければ、それを利用するに越したことはないかと。

カテゴリー
ブログ

買ったばかりのOAチェアが壊れたので、部品交換

事の始まり

コロナが本格的に流行する直前、2月頃に仕事で利用してたOAチェアが壊れました。

結論としては、普及品のOAチェアには必ずついてる、支柱のシリンダー破損です。
実は、一般的にレバーと自重で調整できるタイプのOAチェアにはほぼ必ず使用されている、このシリンダー部品。世間に出回っているものは、わりと「規格品」のようです。というのも軸のサイズ等がほぼ同じ。
そのせいか、Amazon などの通販サイトでシリンダー部品だけを単体で購入して、自前で交換することだって、実は可能だったりします。(ただし実際には割と大変です。)

ただ自分の使ってたOAチェアは購入してから20年ぐらいは使ってる代物で、背もたれと座面裏を停めているボルトが、長年の重量(経年劣化?)で何本か折れていたり、座面のマットもかなり汚れていたので、これを機に新調することに。

またもや破損

そして2月末に新調したハイバックタイプのOAチェア。5月末にまたシリンダーが破損。。。

さすがに購入してから3ヶ月だったので、メーカーに部品交換を要求したところ、あっさり成立。
まぁ全交換を要求することも可能だったのかも知れないが、ハイバックタイプの割と重くてデカいOAチェア、仕事場である家の2階から降ろし、梱包して発送することを考えると、ちょっと気が遠くなったので、シリンダーのみ交換を依頼することに。

じつはこれがまた大変だった。

シリンダーを外すには

購入時の取扱い説明書を確認したところ、シリンダーまわりの部品組み立ては、手順のほぼ初期段階。
原則として分解の場合、組み立ての逆を辿る必要があり、つまり初期段階まで椅子をすべて分解する必要がある。

実際にはショートカットできるかも知れないが、肘掛けとか背もたれが付いたまま、シリンダーを外すにはかなり大変だし、余計なキズを付ける可能性だってある。

しかもこのシリンダー、実は組み立ての過程で、車輪のある台座の部品枠と座面の部品枠の間に人間の自重を以て挿入、固定されるように作られている。
よってこの3つの部品を分解するためには、力業で引っこ抜く必要がある。

この手順を Web で色々と調べてみたところ、潤滑油と部品のキズ防止のための「あて板」や養生など利用し、ハンマーなどで、接合部の部品を引っぱたくというのが、やはりオーソドックスみたい。

自分はDIYの経験が多少あるのと、力業についてもあまり躊躇なかったので、Web でみた手順そのままで対応しました。

考察

メーカーとのコミュニケーション

最近よく「メーカーが対応してくれない」とか色々たまに耳にしますが、少し思ったのは「ちゃんと状況を説明できていないから」じゃないかなぁと思いました。

確かに購入者からしてみれば面倒な事かもしれませんが、人とコミュニケーションを適切に取る事は、人間社会にとって基本中の基本です。
「とにかくよくわからんけど、壊れたから直せ」とか「交換しろ」では話になりません。クレーマーと同じレベル。

自分に落ち度がないのであれば、それを証明するために、購入日の情報やレシート等の準備、商品の型番、壊れた状況・部品の確認など、メーカーに対して必要な情報を開示する。
そもそも応対する際は、挨拶など適切なマナーや節度を用いて対応するのが、人として、人間社会的な対応ってものではないかと。

これができないから、メーカーと適切に対応してもらえないのではないかと。

今回の場合、とてもスムーズに対応いただけたと思います。

ただまぁ、中には変なメーカーやその窓口もあるので、一概には言えませんが。。。

初期不良の見極め

今回の場合、購入してから3ヶ月で破損ということで、部品の無償交換もスムーズだったのですが、自分の場合、もしも客先で作業に出てしまった場合、保証期間内での故障には辿り着けなかった可能性もあります。
それに椅子の場合は利用頻度や重量など、個人の状況や利用環境に差が大幅にでやすいので。

そこで、ちょっと今回の経験で思った点を最後に。

というのも。今思えば組み立て直後の段階から、シリンダーの動きがすこし悪かったような気がします。というのも、座面の上下昇降時に、スムーズに上がらなかったり。

あと「ギシギシ」音もあったと思います。以前は少し体重移動しただけで異音がしてましたが、部品交換したら、異音はしなくなりました。
もちろん異音はシリンダーだけでなく、座面と背もたれなどの部品などからも生じることがあるため、一概には言えませんが。
今回の場合、今思えば部品提供の段階で、シリンダーに何らかの問題があった可能性があります。

カテゴリー
ブログ

Python と git と Redmine

最近、色々な場面で Python がプログラム言語として仕事や話題に上がってくる事が増えたので、ちょっとこのタイミングで勉強しようかと。

丁度、ChatWork から Slack への引越データが公式が提供するインポート/エクスポート機能だけでは上手く移転できないのと、引越のついでにデータの中身(添付ファイルのリンク先とか)を少しイジりたかったので、これらの変換プログラムを Python でやってみることに。
(プログラム自体は多分使い捨て。ゴミプロになる予定。)

さらに「ついで」として、プロジェクト管理で使用している Redmine。こいつも git と繋ぎ込みできるため、その環境も整備する方向で。

ちなみに今のトレンドだと、GitHub とか GitLab とか使うんだろうけど、以下の点から見送り。

  • Redmine でプロジェクト管理を網羅的運用してる。
  • 基本的にプライベートリポジトリ(非公開のプログラム)しか作らない。
  • 便利な機能色々あるだろうけど、今回は「リモートリポジトリ置き場」以上の機能は不要。
  • 英語をはじめ、外野からどうこう言われたり、対応するのは面倒。

…そのうち気が変わって、使い始めるかもしれませんが、現状はこんな感じで。

でもってリモートリポジトリは、Redmine のサーバとは異なるサーバで運用している。
このような場合、Redmine サーバまわりで若干トリッキーな構築が必要になるので、これも併せてやってしまう。

・・・なんだか「大盛り」にしすぎですかね。。。

カテゴリー
ブログ

昨今の中国「叩き」

別にトランプ某氏の肩を持つわけではありませんが。

最近というか、以前から情報ネットワーク・半導体・電子機器分野において、中国の「動き」が変なことは、もはや周知の事実。

電子機器に変な(ハッキング可能な)チップを乗せたり、不正アクセスなどを、こんなに頻繁に繰り返している国はとても限られている。

その中でも、突出して多いのは「中国」と「アメリカ」だ。

ただアメリカの場合、ハードウェア分野における不正行為は皆無に等しいが、中国の場合は、半導体といった電子回路にまで不正を盛り込んでくる。

不正アクセスにおいても「アメリカ」からのアクセスは、散発的というか、衝動的というか、チームワークの感触がまったく感じられない。(勿論「例外」はあるとは思うが、その例外行為が、対して一般的な民間起業を狙うことは、ほぼ皆無。)
それに対して中国の場合は、人海戦術というか、とにかくあらゆる手段を講じて、頻繁に攻撃してくる。

中国大陸から直接だけでなく、上海や深圳に籍のある ISP 企業の香港のゲートウェイを使って不正アクセスしてくるとか。

中国政府は定型文的に、不正行為について、常に否定しているし、日本のインターネットサーバは、極めて「ユルユル」なものも多いので、狙いやすいのも確かにあると思う。
国によって技術力や人口の差はあるだろうし、隣国である点も加味したとしても、さすがにこれだけ中国からの不正アクセスの偏りが大きいと、国家が否定するのはさすがに限界があると思う。いくら「アメリカが中国のサーバを使って不正アクセスしてるんだ」と言っても、だ。もしアメリカの所為なら、なぜ中国は、お家芸の人海戦術をもって、中国国内の不正アクセスを調査摘発しないんだ? 彼らの技術力と機動力があれば、簡単な事だと思うのだが。

それに、だ。
昨今の電子機器や情報技術における中国だけへの大きな依存は、安全保障だけでなく、一般的な製造分野においても大きなリスクであることは、今回のコロナ禍で露呈した。

値段や機動力では、たしかに太刀打ちできないかもしれない。だがそこを技術力や、適切な保護施策でカバーしたり、アイデアを絞らないと、経済不況や今回のウイルス禍、(あってほしくはないが)大戦などの有事発生時、地球単位の事象において、常に被害を被ることになるのだが。

カテゴリー
お知らせ・更新情報

「おすすめ」記事のアマゾン商品リンクについて

今まで「おすすめ」記事で紹介したコンテンツについては、Amazon で取り扱われているコンテンツ商品の広告を併せて貼り付けてました。

これは「広告収入」という目的もありますが、「コンテンツパッケージの紹介」の意味もあります

しかしながら、以下の3点が、昨今の状況変化により問題となりました。

PA-API 5.0

Amazon アソシエイトの1サービスと提供されていた「PA-API」がバージョンアップされるとともに、提供サービス基準が変更されました。

これにより「当サイトのような零細コンテンツ」には、PA-APIの利用が困難になりました。

商品リンクするためには、Amazon アソシエイトのサイトに行って当該コンテンツの商品を探し、リンクを生成しコピペするという、とても原始的な作業を行わざるを得なくなってます。
結果的には広告作成する際の過程が、とても面倒になりました。

WordPress バージョンアップ

ブロックエディタで標準的に記事の編集ができるようになったことは、記憶に新しいと思います。これにより、投稿時のストレスは大幅に削減されました。

しかしながら広告作成するためのプラグインが、ブロックエディタでは制限がある等の問題が生じました。

Amazon アソシエイトで商品リンク URL を生成したものを直接ブロックエディタに貼り付けることも可能ですが、現在の WordPress バージョンでは、なぜか Kindle 埋め込みコンテンツといて認識・展開されてしまいます。
これでは、当サイト閲覧者の誤解を招くことになります。

今後の方針

そもそも、コンテンツ紹介の在り方に際して、これら広告を流用する点も(解りやすいのですが)若干の疑問も生じてたのも事実です。

そこで、今回思い切って、当該コンテンツに含まれる広告を今後すべて削除することにしました。

当面の間「おすすめ」記事にあるコンテンツの紹介は、永続的な情報掲載が比較的見込まれる「ウィキペディア」のリンクを原則とします。
ただし一部のゲームコンテンツの場合は、例外的に制作元のコンテンツをリンク掲載したり、コンテンツ公式サイトが存在する場合は、そのサイトをリンクする方向にします。

ちなみに、本当はマンガや小説などの書籍についても、出版社や作者のサイトをリンクしたいのですが、意外と出版社の URL が合併やレーベル再編などによって頻繁に変わることがあったり、閉鎖されることも多いため、断念しました。

よって Amazon 商品リンクについては、今後整理の過程で全面削除します。

ちなみにこれとは別件ですが、Google 社の広告を、今後純粋な「広告」として別途する予定です。