Archive for the ‘PC・技術’ Category

近頃、なぜか、大昔のPCやゲーム機のミニ版がもてはやされている。確かに懐かしいけど、僕は好きではないし、あまり価値を感じない。最も大きな理由は、そういうもの(元の製品)は工業製品であって芸術作品ではないからだ。僕にしてみれば、こういうコンピュータの類は、何を動かす・するかが重要で、物自体(特に外面)に大きな意味や価値はない。だから、(歴史的価値のある)本物を(実動状態で)博物館に展示するとかならいいが、その劣化コピー(しかも小さい)を手に入れて、何がおもしろいのだろうかと思う。

  • (当時の)BASICがやりたい? マジですか?w
  • (使えるか知らないが、)カセットやフロッピーやドットプリンタを使いたい? マジですか?w
  • 当時のゲームがやりたい? 最新の機器とかエミュレータでやればいいのに。できないのなら、僕だったら、そっちを何とかする方がおもしろい。

この流行の最初かどうかは分からないけど、僕が覚えているのは、FM-7のミニ版だった(→ 実際は2017年のMZ-80C他(ハル研究所 PasocomMini)だった)。確かに良く出来ていると思って感心はしたが、百円とか千円でなく、結構なまともな値段(→ MZ-80Cのミニは2万円近かったようだ)がしたので、「はて、どういう意味が?」と思った。中のハードはラズベリーパイだったと思うが、そこが大変安直でがっかりした。6809(CPU)や本物の基板をFPGAでエミュレートして、当時の本物のF-BASICや機械語(、そして周辺機器も)が動かせれば良かったが、そうではなかった。ARMでF-BASICを動かしていたかも知れないが、機械語はどうだったか(→ 上の記事から推測すると、独自のBASICのようだ。機械語は不明)。だったら、そのエミュレートするソフトだけ出せばいいじゃん!

こういうのは、個人が趣味でやるなら大いに楽しいしおもしろいけど、「企業が本気でやってもねえ・・・」と思う。

 

PS. 題は最初は、「ミニは*だけでいいよw」(*はご想像)とかいうのにしたかったが、余り下品になるのも良くないと、少し自制した。でも、どっちが下品かっていう疑問はあるw

  •   1
  •   0

下の部屋の親子の騒音などに嫌気がさして引越す気になった話が、思わぬ展開になった。もちろん、下に住むのはガサツな人種であることは間違いなく、足音だの物音を立てているのは間違いないし、一方で、その音量がそれほど大きくないのに僕が過敏になっている可能性もあるのだが、うるさい原因はそれだけでない可能性が出て来た。以下に、分かったことを列挙する。

  • 鉄筋コンクリート(RC)造だからといって、必ずしも静かではない。 → 引越して静かになる可能性は高くない。特に、家賃が安いところなら・・・ 逆に、今はまだマシなほうだ。賃貸だけでなく、大手の新築の分譲ですら、うるさいところが結構あるようだ。そして、ネットに書くような人は、みんな結構おかしくなってしまっている・・・
    • 鉄筋コンクリートマンションの騒音について (賃貸)
      • 2010/10/1 09:25の回答の「子供さんが出す音って、それが普通なんです。本当です。」には「そうか・・・」としか言いようがなく、反論できない。実際、自分もそうだったしね。あと、「深夜に音がしない分、本当に階下のご家族は常識的です。」も、ほぼそうなので、やっぱり「そうか・・・」としか言いようがない。
    • 大手新築マンションの酷い遮音性 (2000年頃の話のようだ)
      • 5千万円クラスでLL45でも駄目だったとのこと。この方も公団賃貸の遮音性は良かった、(今は)「太鼓の中に暮らしているよう」と書いている。
    • 振動音は壁を伝って響く (僕と似ている例: まさにこういう感じ。以下に引用する。)

      相変わらず、下の階の足音、何かものを落としたような「ドスン」という音は続いています。隣の部屋は足音こそ聞こえませんが、時々「ドスン」という音がします。一体どんなことをしたら、こんな音が出るのでしょうか?不思議でたまりません。

    • おそらくRCの賃貸と思われる、近頃の阿鼻叫喚な話 (元のツイート)
  • RC造の建物特有の、音に関する現象 → これだったらどうしようもない。逆に、ここは軽いほうだ。
    • 謎の騒音(「不思議音」 → 対策例: 「集合住宅における不思議音の発生と対策」)や音の伝わり方や響き方(例: 「太鼓現象」: 偶然だが、上の例と共に、前回書いた「常に下で大太鼓が鳴っている感じ」に符合していて妙だ)が関係しているのかも知れない。
    • 上下左右だけでなく、離れたところからの音が強く伝わることがある。 → 下だけでなく、実は隣とか斜め下などもうるさい可能性もある。
    • この建物は、正確にはRCでなく、PCa(プレキャストコンクリート)でできているようなので(想像: というのは形状が普通のRCぽくなくプレハブ的に外壁に継ぎ目があるので)、PCa特有の不思議音(コメント28に建設会社の資料あり)があるのかも知れない。そして、主に夜聞こえる、「ドンッ」(壁を拳で叩くような音)とか「ゴツッ」(石を硬い床(ベランダか玄関?)に落とすような音)という音はそれかと想像している。というのは、そういう音を故意に頻繁に出しているなら、壁や床がボコボコになってしまうからだ。

まとめると、足音でない騒音・物音(「ドンッ」とか「ゴツッ」)は、PCaによる不思議音の可能性がある。そして、上に挙げた経験談などを読むと、今の部屋はそこまでうるさくないので、実は防音性はそれほどひどくないのではないかとすら思える。例えば、少なくとも、隣の音はほとんど聞こえないし、下のTVや話し声(怒鳴り声や喚き声は除くw)もほとんど聞こえない。下がDQNなのは確かに問題だが※、そればかりではないかも知れないのだ。しかも、ありがたいことに、DQN度はまだ低い方だw それで、やみくもに引越すよりも、まずはどうにかして下(あるいは別の部屋もかも・・・)を静かにさせる(僕が気にしないようにするのも含む)のが、一番コストパフォーマンスが高く、リスクが低いような気がする*。

※DQNではあるのだが、悪気・悪意はないのは分かってきた。というのは、仮にその騒音が不思議音でなく、彼らが出しているとして、もし悪意でやっているなら、もっと攻撃的にするはずだからだ。今は、音はほとんど単発でしか起こらない。悪意とか故意にやっているなら、連続して出すだろう。だから、人が出しているにしても、不意に出てしまうとか、下の方の頭のネジが数本外れてしまっていて自制できない(それだったら、本当にどうしようもない・・・)のかと想像している。

*リスクを考えるなら、本当は、全国の賃貸マンション居住者(家賃別・構造別だと更にいい)の騒音問題アンケートのようなものを探すべきろうが、平均値(期待値)はともかく最悪値は分からない(→ 想像通りとして良い?)ので、自分で調べた・体験した中でのひどい例を想像するより仕方ない。あとは、一週間とか体験入居できるといいが、そういうのは見たことがないし、周囲の住人が入れ替わったら状況が変わる可能性があるから、それほど意味がない。

それから、引越したいもう一つの理由は、例の「2千万円問題」対策の支出削減だ。家賃はかなり効くのだ。例えば、家賃が今より2万円安いところに行けば、単純計算(引越し代や初期費用・諸経費は無視)で年に24万円、(年金受給できるかもね?までの)10年で240万円も浮く。2千万円には全く足りないが、車1台分くらいにはなる(更に、年金免除分を加えれば440万円くらいになりそうだ)。それで、今より2万円以上安くて(静かさが)同じレベルのところがあれば、引越したいと思ったのだ。が、そんないいことづくめの夢のような話はまずないwのは、今までの経験から確かだ。安いところに行ったら、絶対に質が落ちてうるさくなるはずだ。実際、ある綺麗で良さそうなマンションを所有・管理している会社に防音について聞いてみたら、(人によるが、)「生活音は聞こえる」、「上下の足音も聞こえる」という回答が来た(この会社は結構誠実そうだ。単に、リスクを取らないだけ?)。

「2千万円問題」を解決する一番いい方法は、就職である。試算ではすごく効くことが明らかだ。今は減る一方のお金が補充されるので、仮に給料を年に200万円貯金すれば10年で達成できる。が、その見返りにいろいろな苦痛があったり、そもそもしたい(おもしろい)仕事(会社)が見つからないので、なかなかすぐにはできない。

他の方法としては投資も考えられるが、僕はもう全くする気がしない。政府や金融業者の思うつぼ、「カモネギ」だw あと、もう一つの方法の自営は既に諦めた。あとは錬金術かねぇw

結局、支出削減と静かさとどちらが重要かという話になり、僕にはやっぱり静かさが重要だ。 (まあ、今はそこに他人由来の若干の問題があるからこうして悩んでいるのだが、「程度問題」なんだろうね・・・) なんか、自分で自分を丸め込んでいる気がしないでもないが、実際にいろいろ調べてみて、上記のような(可哀想な)事実が多かったので、誤魔化しではないように思える。

とはいえ、以前住んでいたURの(超古い)部屋は静かだった(でも、あの地震での揺れ(の結果)はすごかった)ので、そういうマトモなところもない訳ではないのだろうが、お金や運が必要だと諦観しつつある。。。

(8/6 5:39 一部訂正, 10:21 加筆, 11:15 細かい修正)

 

PS. そして、なぜか、近頃は下がそれほどうるさくなくなった。ガキがどこか(別の家族のところ?)に行っている日が増えたのか、僕が音に慣れたのか、再就職の調査・検討に集中していてそれどころでなかったからか、それで疲れたからかは分からない。

PS2. 上記のように、大手の分譲ですらすごくうるさいことがあるのだから、今まで以上に家(部屋)を買うのは避けたいと思った。もちろん、面倒だから買いたくなどないし余力もないが、高齢になって部屋を貸してもらえなくなった時に備えて買うことも検討していたのだ。代わりに、歳を取ったら(ここにはなぜかURはないので、)県営とか市営の公的住宅が借りられないかと甘い期待をしている。ただ、高齢者は増えるばかりだから、抽選が厳しいかも知れないと心配している・・・

  •   0
  •   1

どういう根拠か知りたくもないけど、まあ、「鯨やイルカが可哀想」とか「毛皮反対」と似たようなレベルかと。

紙は木材から手間暇掛けて作るので、いろいろな点で結構高価だと思うのだが、それはいいのか? プラスティックも石油という天然資源から作るが、生産効率は紙よりずっと高いだろう。石油は有限だが、木材も種を蒔いてから数十年待たないと使えないから、有限に近い。紙の消費量が更に増えて、今でも問題になっている、発展途上国の山林が更にハゲ山になってもいいのだろうか? 全部間伐材で間に合うのならいいが。「人工木材」とか「人工紙」は当然ないよねw そして、プラ廃止派は以下のようなことをちゃんと比較したのだろうか。僕は、分解性以外は全部プラが勝っていると思うが。

  • 原材料のコスト・環境負荷
  • 作るためのコスト・環境負荷(電力、燃料、CO2など)
  • 重量、体積からの格納・運搬でのコスト・環境負荷
  • 耐久性・再利用の可能性からの環境負荷
  • 分解性による環境負荷

あと、紙だけじゃ使えなくて、表面をコーティングしたり強化処理する場合が多いだろうが、それはお咎めなし?w コーティング部分は自然には分解しにくそうだが。燃やすからいいの? でも、そもそもプラが散乱して良くないなら、まずはきちんと回収して燃やせばいいと思うのだが、それはしたくないのか。ダイオキシン? 今はすっかり忘れられているが、どうなったのかねw

それ以前に、そもそも、紙(あるいは他の材料)に置き換えられるプラ(今流行りのストロー、レジ袋)なんて、プラ全体の使用量(体積も質量も)からすればものすごく小さいはずで、それで本当に目指す効果があるのだろうか? 単なる自己満足ではないの?

PS. 個人的には、紙とか木は大好きだが、意識高い系のトレンディー()な押し付けはごめんだ。

PS2. そういえば、こういう人たちの衣類は全部天然素材(最悪でもレーヨン?)なのだろうか? 化学繊維だってプラと同様ではないのか? 少なくとも自然に分解はしなさそうだよ。是非、教えて欲しいw

  •   0
  •   0

いろいろな会社の募集を見て気付いたことがある。ソフトの設計までしかしない技術系社員の募集に、実装経験(例えば「C言語での開発経験」)が入っていることが多いのだ(ほぼ100%)※。

※実際に、「設計」の職種に特定言語での開発経験を条件として出していた大きなメーカーに聞いたら、本当に設計までしかせず、実装は外注するという答えだった。もしかして、特定言語での開発経験と言っても、その言語を使ったプロジェクトに携わったことがあるだけで良くて、自分で実装していなくてもOKなのだろうか??

以前書いた、設計までなのに「開発」と呼ぶことと合わせてどうしてかと思っていたのだが、 どうも、「プログラマーの上位はSE(= 設計までの人)」という、日本で一般的な階層構造(→ 参照: 中央辺りに多重下請け構造)を想定しているからのような気がして来た。

その他に、大企業だと、系列に実装を行う子会社(実際には、更に孫請けが居るかも知れない・・・)があって、そこに発注することも多い。これは、経済的な理由なのかそこに子会社があるから(全く本末転倒だが、お偉いさんの命令とか管理職の忖度があるのかもね・・・)なのか分からないが、そういう現実はある。上に書いたメーカーもそういう回答だった。

日本では、大手IT企業は設計までしかせず、実装や試験などの本当に手を動かす仕事は下請けに外注する(良く言えば「ソフト版ファブレスメーカー」みたいなものか)。これが「上位は設計まで」という意識になっている。あるいは、(中位・下位の)実装も行うIT企業でも、経験の少ない社員は下積み的に実装をし、経験を積むと出世してSEのような設計までの人になる。ここでも「上位は設計まで」になっている。

それから、下請け会社も何段階にも階層化されていて、中抜きするだけのところも多い。一番最後(底辺)は、安い(ここに来るまでに安くなってしまった)お金と短い(ここに来るまでに短くなってしまった)期間で(→ 参照: 中間マージンについての例)実装させられる「どこかの」プログラマーとかコーダー(自分たちで「IT土方」と卑称してしまっている)なのだが、ここまで来ると伝言ゲームのようになっていて、本来の仕様(特に意図)はまともに伝わらないだろうし、実装上の疑問や確認事項があっても、まともに回答されない(できない)のではないか。そもそも、最底辺の人は、指示された機能の実装(コーディング)だけをし、仕様や設計の意図なんて全く気にしないだろう(そんなお金も時間ももらっていないし、気にして意見しても無駄だから・・・)。

募集条件の話に戻ると、設計(までの)技術者に求められるのは「いい物(製品・システム)を考える(設計する)」ことだから、その業務なりプロジェクトで使うと想定される言語の実装経験など不要なはずだ。まあ、実装経験があるということは「プログラミングの勘」がある(だろう)から、設計に役立つことは多いが、なまじっか詳しいために、外注に余計な指示をして(、それが必須条件のようになって)逆効果になる場合も多い。そうでなく、一番最初の考え(アイデア・構想)や仕様検討や設計のセンスなり経験を求めればいいはずなのだが、証明も確認もなかなかできない※。例えば、条件に「画期的なアイデアを出せる方」などと書いても難しいだろう(たまに、ちょっと危ない会社が書いているがw)。結局、求人側にIT業界の階層構造が染み付いていて、「ある程度の実装経験があれば(その「上位」の)設計もちゃんとできるだろう」といった考えで、そういう条件しか出せないのかも知れない(というか、単に前例に倣っただけかもw)。

※日本にはいろいろなIT関連の資格試験はあるが、条件に指定する会社は少なく、余り重視されていないようだ。それは、そういう資格に実効性がないのがバレているからかも知れないw そうであれば、代わりに今までの経験や実績を見ればいいと思うが、特に非IT系企業では、経歴とか作例を見ても理解・評価できないのかも知れない。

それに、以前も書いたが、設計の後を外注して いい/まともなものができる可能性は低い。いくら良く考えて仕様・設計を作っても漏れ(「想定外」ってやつ)や誤りはあるし、逆に、それを防ごうとして過剰になることもある。基本的な仕様や設計が誤っていたらやり直しになるから、時間とお金の無駄だ(予算超過を心配して、さまざまな無理を通す場合もある)。過剰な設計も無駄だ。そもそも、外注のプログラマーがそれを読んで適切に実装できるほど詳細な「設計書」を書くのなら、自分で実装した方が速いだろう。USなどの有名企業が日本のようなやり方をしていないのが、証拠だ(実際に見た訳ではないが、何かの記事で読んだ(→ 先日、Amazonの例紹介した))。

脱線: 大好きな音楽に例えれば、「天才的な作曲家は自分で譜面を書かないし、弾くこともない」みたいなものだろうか? 音符を書くなんて下等・面倒なことは弟子に任せて、ひたすら曲想を語って書かせる? 曲作りの途中でも完成しても、試奏もせず(というのは、脳内に生まれた段階で完璧なので)、専属のピアニストに弾かせて記譜誤りを確認する程度? なんか、これはこれで成り立つ気もするぞw (映画「アマデウス」の「レクイエム」のシーンより想像) でもまあ、すべてのソフト技術者(設計までの人)が天才ではないし、すべてのプログラマーが天才設計者の意図を正確に汲んで的確に実装できる訳でもないから、やっぱり無理なのだ。

こうして、技術者なのに、なぜか日々ワープロやスプレッドシートなどで(それが本当に必要なのかすら良く分からない)何かの書類を書き続け、顧客(上司・部下も?)対応や外注管理でひたすらイライラ・消耗するだけのつまらない仕事に就くことになり、更に、大金を投じても動かない・使えないシステム(例: どこかのペイ: 書いたあとで、9月で終わというニュースが・・・ 合掌)が増えてしまうのだ。いろいろもったいない。。。 この良くない構造は今まで何十年も続いて来て、いい加減得策でないのは明らかだと思うのだが、いったいいつまで続くのだろうか??

まあ、何もかもうまく行かなかった訳ではなかったから、前例(成功体験)を踏襲して続いているのだろうが、きっと、無駄な費用や顧客の減少(移動)や多くの人間破壊・崩壊などが隠れているはずだ。それがGAFAの台頭とか、近頃問題とされている日本の低い生産性にも関係しているかも知れないね(ここはテキトーw)。

それではどうしたらいいかを考えると、以前も書いたように、全部自社で作る(実装する)べきだとは言わないが、日本的階層構造でフェーズごとに組織や担当を(あるいは、組織ごとにフェーズや担当を)きっちり区切るのを止めるといいのではないか。例えば試作(コンセプトを実証するもの)は内製して充分に練り、仕上げ(本物(製品)にする)を外注するとか、社員と外注の実装する人たちが渾然一体となって作る(今もSESであるだろうが、単に同じ場所に居るだけで、やっぱり線引きされていてうまくなさそうな感じだ)とかがいいように思う。オープンソースプロジェクトのように、社員も外注の人もみんなで分担してプログラムを書く・使う・問題を報告して修正・改良するってのがいいかも知れない(余りにも牧歌的だと言われそうだが・・・)。まあ、少なくとも僕は、そういうふうに仕事がしたい。

  •   0
  •   0

以前作って廃止した仕事用サイト、もしかしたら再就職活動の足し(例: 経歴に書く時の元ネタ、Webやアプリのサンプル)に使えるかと思ってちょっと見たくなったのだが、なかなか問屋が卸してくれなかった。WordPressでは画像などの添付ファイル以外のコンテンツはDBに入っているので、HTMLのようにブラウザで簡単には開けないのだ。そこで、一式を手元のデスクトップPCに移して、最小限でもいいから表示できるようにしようとした。

実は、サイトが生きていた時には定期的にPDFで保存していたのだが、(良くあるパターンで、)欲しいところを取ってなかったのでw、この作業をする羽目になった。

要は、WordPressのサーバ移行にからむ作業である。最初から面倒なことは分かっていたが、やる気(時間)はあった。

いろいろな作業が要るが、一番面倒なのは、文中の自サイト(自サーバ)へのリンクや画像のURLを書き換えることである。それらは大抵絶対パスのように格納されていて(例: "https://blog.piulento.net/archives/94939")、例えば新しいサーバのドメイン名やポート番号が違っていたら、問答無用で無効になってしまう。そして、WordPressは何も対処してくれない(何が正しいか分からないので、不可能だ)。

おそらく、自サイトへのリンクを付ける時に、ドメイン名などを外して相対パスのように(例: "/archives/94939")すればいいのだが、そういうサポートがないので、すぐに忘れてしまう。更に、画像のリンクは自動で付くので無理だ。

対処にはいくつかの方法があるが、コンテンツ(DB)を書き換える方法と、表示時に書き換える方法があるだろう。前者はまあ簡単だろう(置換するプラグインがあるだろうし、インポート機能でできるのかも知れない)が、移転のたびに手間が掛かるうえに、そのうちおかしくなってしまう(しかも、気付かない)可能性がある。そこで、僕は後者の、コンテンツやDBはそのままにして、表示時に変換する方式(オンザフライ)で対処したいと思った。

今気付いたが、コンテンツ中のローカルURLを相対パスのように置換すれば、オンザフライでの変換も不要になっていいかも知れない。ただ、上にも書いたように、WordPressにはそういうサポートがないので、投稿が増えるたびにそういう処理が要るだろう。

このサーバでは、(別な「小手先対処」のために)URLの書き換えをRewriteというプラグインでしているので、今回もそれが使えると思ったのだが、URL中のパスの部分だけしか変換できないようで(サーバからWordPressに来る時にそうなってしまうのか)、ポート番号は変更できかった。それで他を探したら、Real-Time Find and Replaceでできた。

なお、Rewriteは古過ぎるせいか、最新のWordPressではエラーになったので、修正が必要だった(今まで知らずに使えていたので、設定だけの問題かも知れない)。ご入用の方はお知らせ下さい。

今回は、ドメイン名は変えずに(ドメインは廃止するので、ホストテーブル(/etc/hosts)に書いて誤魔化すことにした)、スキーム("https"を"http"に)とポート番号(下例では80を9999に)を変えたので、以下のようなルールで変換するようにした。

元: @(http)(s)?:(//AAAA\.BBB)(/blog)(/.*)?@
置換後: $1:$3:9999$4$5

見ても「は??」であろうが、正規表現というもので、ワイルドカードの千倍以上便利だw 上で、"AAAA\.BBB"は元のドメイン名("AAAA.BBB")、"9999"は新しいポート番号である。例えば、元々のURL: "https://AAAA.BBB/blog/94939"(httpsはhttpでも可)は"http://AAAA.BBB:9999/blog/94939"に変換される。

なお、公開サイトで使うなどの場合のように「ちゃんと」(完全に)変換するにはいろいろな例外条件への配慮が要るが、今回は自分で見るだけなので、手を抜いた。

 

(7/31 21:40 一部の誤りを取り消し, 8/1 15:31 補足・修正)

  •   0
  •   1

全焼してしまった会社のサーバから無事にデータが回収できたそうで何よりだが、今更ながらではあるが、オンラインバックアップしておけばもっと楽に確実に残せたと思う。料金だって、例えば、僕が使っているところは格納だけならUSD0.005/(GB・月)だから、仮に10TBとしてもUSD50(約6千円)/月で、企業にしてみればすごく安いだろう。実は動画が大量にあってデータ量が膨大(1000TBとか?)だから断念したのだろうか? でも、仮に高くても、全部消失するよりはいいだろう。

それから、バックアップに使うソフトにもよるが、変更履歴も保存できるから、マルウェアによる被害(例: ランサムウェアによる暗号化)にもある程度は耐えるだろう。

「次」はないことを祈るが、是非、この機会に導入した方がいいと思う。と、聞かれてもいないのに余計なお世話を書いた。

  •   0
  •   1

非接触決済の話。先日、勝手にポイント還元率を半分にしたうえに関連会社が論外のセキュリティ意識を晒したnanacoに見切りを付けて、簡単に使い始められて年会費無料で使えるGoogle PayのSuicaにしたのだが、今更ながら、QUICPayは更に便利そうなことに気付いた(楽天カード(だったか)がGoogle PayのQUICPayに対応したという記事で、検討する気になった)。ただ、僕のクレジットカードはまだGoogle PayのQUICPayには対応しておらず、カード会社に申し込む必要があるなど使い出すのが面倒なので、一旦は止めたのだが、調べてみたら、Suicaに比べて以下のようなメリットがあることが分かった。

  • チャージ不要 (ただし、1回の使用額の上限は2万円)
  • クレジットカードのポイントが付く
  • 紛失や盗難による不正使用の補償がある。 (条件は要確認)

更に、良く考えたら、元々僕が欲しかったもの(非接触のクレジットカード、しかも、スマフォでも使える(→ 財布からカードを出さずに使える))そのものだったので、使ってみることにした。

今日届いたばかりなので、まだ初期設定しただけだ。アプリでも使える(初期設定できる)はずだが、カード会社はwebでの初期設定・操作を指示していたので、(余計なことをしていろいろな問題が起こるのは嫌だったので、)素直にそっちにした。Chromeでしか使えず(ページはOperaでも開くが、リンクを押すとChromeになってしまう)、UIがしょぼくて少しがっかりしたが、(チャージ不要なので)あまり使うこともないから、まあいい。

残念なのは、最寄りのスーパーなどが対応していないので、そこでは相変わらずクレジットカードを引っ張り出すしかないことだが、まあ仕方ない。コンビニでは(残額を気にせず)便利に使えるから良しとする。

(7/31 15:16追記) 今日、コンビニで試して無事に使えた。決済の時に「クイックペイ」という音(声)がするのは(Suicaで何も音がしない場合があるので、それに比べれば)分かりやすくていいけど、微妙に鬱陶しいような気も・・・ とりあえずSuicaを使い切ろう。Google PayのSuicaはチャージもしやすいから、それで問題ない。

 

PS. タイミングの悪いことに、今日、QUICPayの案内が届く前にSuicaにチャージしてしまったのだが、適宜使って残額を0にするか都会に行った時に使おう。田舎と違って、電車や駅では便利だw あと、カードのSuicaと違って、数か月使わなかった時に駅員さんに使えるようにしてもらう必要がなさそうなのもいい(要確認)。

PS2. 僕は、Google PayのSuicaとかQUICPayとかの構造というのか、それらがどういう関係なのか良く分かっていない(分かろうともしていないw)。きっと、Googleが(Appleに対抗したくて、)そういう企業に話を付けて、スマフォ(のFeliCaやNFC機能)とGoogleの決済システムで手軽に使えるようにしたのだろうと想像している。まあ、手軽ならなんでもいいと思う。実際、通常のモバイルSuicaは指定のクレジットカードでないと年会費が掛かるのに、こちらは無料なのはいい(正確には「モバイル」Suicaではないため)。あと、Apple Payはスマフォの電池がないと駄目らしいが、こっちは(原始的だからか)大丈夫らしいのもいい。

PS3. クレジットカードで払う時に、以前は「カードで」と言えば済んでいたのだが、近頃はいろいろな「カード」があるようなので、わざわざ「クレジットカードで」と言っているのだが、この点は不便になったw でも、まだ「カードで」で通じるのかな? クレジットカードを出して(見せて)言えばいいのか。

PS4. 僕がいち早く退会した7&iは、今日、何をトチ狂ったか、7iD全会員のパスワードをリセットしたそうだ。馬鹿だねえ。そんなことしたって単なる一時しのぎなのに。誰が被害を受けたか、正確には分からないのだろうか? やるならサービス停止でしょ。こっちはもう関係ないから高みの見物だw これについては、少しは先見の明があったと胸を張れそうだ。 (7/30 18:19)

  •   1
  •   0

岡村孝子の「夢をあきらめないで」(1987)のコメントが大変なことになっていたw

ほとんどはブログから転載したものだが、こんなに書いた人・演奏は他にあるかなぁ?

(7/29 6:41) すぐに調べられた。DB(SQLite)の条件式を自分で指定できるメリットだ。(自分で書いた)コメントの長さ第1位はルガンスキーのラフマニノフのピアノ協奏曲 第2番 (第1楽章, 2005)だった。確かに彼は大好きだ。そして、堂々の第2位がお姉さんだった。

SQLのWHERE句の後を以下のようにして、コメント(カラム名: "comment")の長さ順にソートして、上位15個を出力できる。

ORDER BY length(comment) DESC LIMIT 0,15

  •   0
  •   0

動画サイトに載っている、ビデオテープ(VHSなど)を取り込んだ、色がちょっとおかしく、画素が荒く、時々トラッキングがずれて画面が歪むようなビデオ(昔のCMなど)を見ると、結構ひかれることがある。そして、今、レコード・カセットが再び好かれているのは、それと似たようなものなのかと思った

のだが、その後、そうではなくて、(僕は)当時の中身・作り方・撮り方にひかれるのではないかと思った。(空想とかシャレが通じない石頭が増えたせいでPCやコンプライアンスなどの点で、)今では通用しなくなったものも多い。そういうのが、「来る」気がした。だから、僕は、実際には画質よりも中身にひかれているのではないかと思う。要はノスタルジーで、今の作品よりも当時のものに親しみがあるせいだろう。そして、結果的に、そういう作品の当時の映像は画質が悪い(だから、画質が悪いからといって、常にいいと思う訳ではない)。逆に、「スター・ウォーズ」のように、クリアになったリストア版も歓迎だ。一方、現代の作品をホームビデオ風の画質にしたって、単に画質が悪いと思うだけで、いいとは思わないだろう。その証拠に、たまに、セピア色にしたりノイズを入れたりして、安直に昔風に加工した映像があるが、まず好きになれない(と書きつつ、このブログ右上の優作の写真はセピアにしているw それは、優作への思いを表現したとか、余り綺麗でない背景をうまくごまかそうとしたのである・・・)。

各自いろいろな思いはあるだろうが、レコードやカセットがいいと言う多くの人は、中身でなく「音質」が好きなのだろう。その証拠に「温かみのある音」とか言われているし、最新作のアナログ盤(版)ですらもてはやされる。今や、レコードやカセット、それからインスタント写真といったレトロなメディアは一種のフィルタやエフェクタになっていて、(聴く・撮る・観る人の好みに合わせて調整するデバイスという位置付けで、)それはそれでありなのだろう。

ただ、それにしては、VHSのビデオやNTSCのテレビが一向に復活しないのはなぜだろう?? 映画は全然詳しくないが、「スター・ウォーズ」最新作のアナログ(VHS)版とかは需要がないのだろうか? 微妙に時代が近いせいか。ホームビデオで録画したものと違って、プロが制作したものは画質が良過ぎておもしろくないのか。

が、何度も書いているが、僕はそういうのには共感できない。表現として必要ならいいが、同じ内容で単に派生メディアとして出すのでは意味がないと思う。そのうえ、「高音質レコード」とか言われた日には、何を目指しているのか謎だ・・・ 昔、散々、アナログ機器の特性の悪さや雑音や使い勝手の悪さに苦しめられたトラウマなのだろう。その点、今の人は幸せだw

(17:08 わずかに加筆・修正)

  •   0
  •   1

YouTubeの再生履歴を自作音楽ログMlhiに記録する件。昨日はちょっと頑張ればできると思っていたのだが、意外に手強くて、考えた方法はほとんど使えないことが分かった。昨日考えた案と試した結果を以下に示す。

  • Scrobblerを改造し、再生したYouTubeのIDを記録サーバに送信するようにする。
    • Firefoxのアドオンは「署名」(Mozillaの承認が要る)しないとインストールできない(一時的には可能)し、変更のたびに署名が要るので、気軽にちょっと改造したものを使い続けるのは難しい。
  • PCのホストテーブル(/etc/hosts)やDNSを変更してscrobblerのデータ送信先のホストを自分の記録サーバにすげ替える。
    • すげ替えたサーバが使うTLS(SSL)の証明書をちゃんと作り、ブラウザにも設定しないと、エラーになってしまう。
    • 記録サーバはLast.fmのscrobbleサーバの動作を模擬しないといけない。
    • 後述のように、scrobblerはYouTubeのIDを送信しないので、そのままでは使えない。
  • HTTPSのプロキシを使い、YouTubeへのアクセス時にYouTubeのIDを記録サーバに送信する。
    • 上と同じく、TLS(SSL)の証明書の問題がある。
    • プロキシで、HTTPSの暗号化されたメッセージを一旦復号してYouTubeのIDを抽出し、再度暗号化する("MITM"や「インターセプト」と呼ぶようだ)ため、セキュリティ上のリスクがあるし、負荷が増大する可能性もある。
      • そのため、YouTubeへのアクセスだけにプロキシを適用するような設定が要る(これはアドオンでできそう)。
  • ブラウザのリクエストログ中からYouTubeへのアクセスを抽出して、YouTubeのIDを記録サーバに送信する。
    • ブラウザのすべてのアクセスのログを記録するのは、負荷が増大し、ログのサイズも大きくなるので、得策でない。また、セキュリティ上のリスクになる。
    • アクセスをフィルタリングして記録できるようなアドオンは見つからなかった。

試している途中で浮かんだアイデアは、scrobblerはそのまま使ってLast.fmに送り、Last.fmから履歴を取ることである。これだと、YouTubeだけでなく、スマフォを含むSpotifyの履歴も取れる。ただし、それぞれの元サービス(YouTube/Spotify)が分からず、各サービス固有のトラックIDも取得できないので、そのままでは不便だ(履歴に入っているトラックが「何」なのか特定できない)。

Scrobbler(試したのはWeb scrobbler)はそれほど多くの情報をLast.fmに送信せず、送信する情報を追加することもできない。特に、YouTubeのIDを送信しないので、そのままでは使えない。改造して送信するにしても、Last.fmにはそういう追加情報を格納する領域はない(いろいろ試したところ、アルバム名にIDを追加するのが良さそうだった)。また、アドオンを改造すると署名の問題があるので、これも今ひとつだった。

他に、力技でYouTubeの再生履歴ページをスクレイピングすれば履歴を取れそうだが、スクレイピングプログラムでGoogleの認証をパスする必要があり、それを容易にすること(「アプリパスワード」でできそうだ)は、僕のGoogleアカウントのセキュリティ上のリスクになりそうだ。それを許容しても、Googleがページレイアウトを変えらるたびにスクレイピングの修正が要るので、得策でない(やってられない)。 → ちょっと試したら、これもできなかった。やっぱり意地の悪いことに、本文(履歴)が別のファイル(すぐには分からない)に入っているようで、スクレイピングの前段階のデータ取得すらできない。なんでこんな下らないことするかな。連中は余程暇なのか、アフォなのか、意地でも履歴を渡したくないのか・・・ (20:19)

結局、何とかできそうなのはプロキシを使ってHTTPSを傍受する方法しかなさそうなことが分かり、面倒なので力尽きた。APIが使えれば、本当に「ちょっと」やればできることなのに、Googleの意地悪のためにすごく迷惑している。。。

(7/22 18:54) HTTPSのMITM対応のプロキシを使う方法で何とかできそうだ。いろいろなプロキシソフトがあるのだが、mitmproxyが一番楽だった。これは、他のソフト(受信用と送信用にプロセスが2個要る)と違って、1つのプロセスだけでHTTPSなどを傍受することができる。ブラウザへの証明書のインストールもリンクのクリックでできるので楽だった。また、同梱のmitmwebはwebで表示・操作できるので手軽だ。

試行錯誤して(→ 参考1, 参考2: これらのページのおかげでmitmproxyが使えるようになった)、とりあえず、YouTubeの再生開始要求をキャプチャできることが分かった。

再生開始要求は以下のようなパターンで抽出できそうだ(XXXXXXXXはYouTubeの動画ID)。

GET https://www.youtube.com/watch?v=XXXXXXXX&...

なお、セキュリティリスクの低減と負荷を下げるため、Firefoxのプロキシ設定アドオンSwitchyOmegaで特定ホスト(この場合はYouTube)のみプロキシを通すようにした。なお、SwitchyOmegaに設定するプロキシのプロトコルは"HTTP"にする必要があった。mitmproxyの設定でも変えられるのだろうが、"HTTPS"や"SOCKS4"などでは正常に動かなかった。また、同様な方法で動画データも取れそうだが、それにはもっと簡単な方法があるし、どうでもいいw

あとは、mitmproxyのスクリプト機能(Pythonで書く)を使って、再生開始要求中のYouTubeのIDなどを抽出し、動画情報(タイトルなど)をYouTubeから取得して、日時とともにMlhiに記録するようにすれば良さそうだ。まだやることは結構あるが、峠を越えた感がある。 ← 今ココw

  •   0
  •   0