カテゴリー別アーカイブ: 雑記

伊勢神宮を参拝してきた

新年早々プログラムネタでもなく数学ネタでもなく教育ネタでもないただ単なる雑記です。しかも写真などもほぼ撮影していないのでただ単に参拝するところの紹介にしかなっていない記事です。

 

いろいろな場所にお社があるので考える必要あり

順序については「外宮」→「内宮」「御正宮」→「別宮」が習わしとされているようですので、御正宮の参道の近くにある別宮→少し離れたところにある別宮を考えると…

  1. 豊受大神宮(外宮)御正宮
  2. 豊受大神宮別宮(多賀宮、土宮、風宮)
  3. 豊受大神宮別宮(月夜見宮)
  4. 皇大神宮(内宮)御正宮
  5. 皇大神宮別宮(荒祭宮、風日祈宮)
  6. 皇大神宮別宮(月読宮、月読荒御魂宮、伊佐奈岐宮、伊佐奈弥宮)
  7. 皇大神宮別宮(倭姫宮)
  8. 皇大神宮別宮(伊雑宮、瀧原宮、瀧原竝宮)

という順序になる「かな~」というところです。曖昧な書き方になっているのは別宮が離れたところにある場合どのように参拝すると良いかが難しくなるからです。車の駐車場が簡単に確保できる日時なら良いのですが、そうではない場合、駐車してから車を動かさずに移動する必要があるため、歩いてそれほど距離がない月夜見宮ならまだいざ知らず、皇大神宮別宮は参道の近くにない神社ならそれなりの距離(例えば5→6なら1kmくらい)を歩く、もしくはバス移動となるのでちょっと厳しいのが弱点かな、と思います。

 

正月の規制で駐車&途中の移動をどうするかを考えるのが難しいことに

まずは外宮と内宮の移動がやっかいなんですね。外宮の駐車場なんてまともにあいている訳ではないですし、内宮の駐車場もさすがに厳しいところでした。一応パーク&バスライドが別の場所に設定されているのでそちらに止めてバス移動でもいいというのが今回はありがたかったところ。ただ、そうするとこのルートの場合パーク&バスライドの場合は直通なので3→4はOKですが、5→6→7の移動が一番厳しいことになるところです。ちなみに私はちゃんと歩きました。足がちょっとやばかったですが…。一応路線バスもあるのでそちらを使うことも考えて良いですが、その場合10分間隔くらいが目安なのでバスに乗り遅れると歩いた方が早いという結論に至ることも今回確認しました。路線バスでは交通系ICカードが使えるのでSuikaやICOCAあたりを用意しておけば小銭の心配もなく楽ですね。

 

そのほかの神社も参拝するとさらに大変に

例えば猿田彦神社とかですか。内宮からすぐの距離にあるので内宮を参拝した後で行く、というのもありだと思いますし、その他近場では二見浦の二見興玉神社に参拝してから外宮へ、という順番など突き詰めていくとなかなか大変な参拝になるよな~と言うところでした。

もう一つ大変だったことがお賽銭をどうするか、という問題です。別宮以外の社でも、となるとかなりの数になるので用意しておかないと簡単にそこをついてしまいます。補充したくても御札等、お土産等は大抵が100円単位なので人によっては微妙に感じることもありますし、こういう年末年始では細かいお賽銭を手に入れるために自動販売機で…と考えるパターンも多いようで周りの自動販売機は10円が釣り銭切れを起こす事態となっていましたし。いろいろと用意しておきましょう。

皆さんも初詣はどうでしょうか?

 

2019年は…

なんとか2018年も終わりを告げて2019年に入りました・・・

2018年はプログラマとしては全く動けなかった

プログラマ系統以外の仕事が忙しかったので全く動けませんでした・・・。WindowModePatchへの改良とか新しいゲームシステムの開発の種を作るとかいろいろとやりたかったことはあったのですが、それをするだけの時間が与えられませんでした。WindowModePatchの改良を望んでいる人から掲示板等に希望を書き込んでいただいたりされたのに希望に添えなくてすみませんでした。

2019年はかなり違う年になりそう

といっても今年度末まではあまり動きを見せることはできなさそうなのが残念なところ。年度が切り替わる前後からいよいよ本格的にプログラム系統の作業に着手する予定です。仕事として受け取ることもできる環境を整える予定でもありますし、プログラム系統の仕事ができなかった期間についていろいろと考えさせられる出来事も多かったので記事にできる内容であればそちらも記事にしてこのblogを復活させていこうかな、とも思っています。それで生活できるのか?といわれると?どうなのでしょうかね…。

2019年もどうぞよろしくお願いします。

この1ヶ月で何個OSを入れたことやら…

ということで愚痴ではないですがメインマシンやらサーバ環境が変わったためにいろんな部分にOSを入れ直していたら…という現象です。特にWindowsでゲームを作っている場合だと引っかかってしまう場合もあるようで、気をつけましょう、というお話。

 

Win10×2、Win8.1×1、Linux(Fedora)×1、…

いろいろなマシンの入れ替えをした結果がこれです。ちなみに今書いているのは私が個人的にインストールを行ったもので、この期間中に別の場所でもOSが動かないやらでヘルプをやっていた関係もあってこれ以上にOSの入れ直しに近いことをやっています。必要な部分では仕方がないのかもしれませんがそれ以外の部分で考えるとなんとも運が悪い状態というべきなのでは…

 

結局この1ヶ月でHDDが(最低でも)2台壊れたことに

1台は前の記事にも書いたとおりサーバ機のHDDで、一応0埋めはできましたし、非常時に一時的な記憶装置として使えそうなので保存しておくとして。問題はなんともう1台壊れた、ということです。2つ目のところは不幸中の幸いにもRAIDで保護をかけている領域だったので一時的に縮退運転に切り替えてまあなんとかしました。なんか転送速度がおかしいなあ~と思ってSMARTを見てみると怪しげなREAD ERRORとWRITE ERRORが記録されていて…。びっくりもいいところ。早めに気がついてよかったです。なんか以前の記事でも書いたような気はしますが、RAID領域でエラーが起こった場合はちゃんとメールを飛ばすようにしておいた方がいいですね。特に今回の問題発覚は定期的に行っているRAIDのチェック作業で引っかかったものですし、メールを飛ばす仕掛け(+受け取る仕掛け)があればチェック後すぐにわかったはずですからね。

 

Win8.1+VisualStudio2015(以降)のランタイムインストールは要注意

というのがこの記事の本題。VisualStudio2015以降のランタイムではUCRT(ユニバーサルCRT)というものができたらしく、それが使われるようになったと。このあたりはこの頃プログラムをいじっていないのと開発環境を更新していないために知らなかったことなのですが、問題はこのUCRTのランタイムを入れるためにはWin10では何も問題はないのですが、Win8.1ではとあるWindowsUpdateを適用しなけれならないという制約があるということです。今回、マシンを入れ替えた関係でWin81も新しくインストールしてアプリテスト用の領域に入れ直そうとしたのですが、これを知らなかったのでUCRTが入らず、プログラムの動作テストをしてみたところ一部の最新のプログラムが動かせない、という状態に陥ってしまいました。

自分の感覚ではOSを入れ終わるとドライバやら必要なランタイムを入れてからWindowsUpdateで最新の状態に持って行くのが正しいと思っていたのですが、今回はそうではなくOSのインストールが終わり、初期ドライバが設定できればWindowsUpdateを強制で何回か行い、WindowsUpdateが何も出ない状態にしてからインストールしたほうがよういのではないか?ということにいつの間にかなってしまったようです。VisualStudio2015のランタイムを入れさせるようなプログラムを作っているそこのあなた。まだすべてのユーザがWin10になったわけではないのでこういう点で動かない、といってくるユーザもいるかもしれませんので気をつけましょう。

 

やっと悪運が切り離せたかな

HDDの故障やらなんやらによる問題もなんとかなった、というところで悪運はすべて切り離せたかな、というところです。あとは自分にくるはずの金運やら仕事運やらを一気につかんでいきたいところだな、というところです。…ですよね?

Fedora28をインストールしてみた

ちょっとサーバのHDDになにやら怪しい気配が見えたことと、サーバのハードウェアを交換するタイミングになったのでこの記事を書いた時点での最新のFedoraであるFedora28をインストールしてみたわけですが…。これが違った意味で難産となってしまいました。

 

さすがゲーム用のマザーボード、WOLがないとは…

インストールする前にいくつか条件を調べているときにわかったこと。今回、サーバ機となるマザーボードは一応「ゲーム用」をうたっているものなので、確かにゲーム、特にネットワークゲームにおいては各種ユーティリティもありよかったのですが、その機能はほとんど生かされることなくサーバ機になってしまうとこんな問題が出てきてしまいました。一応内部サーバなので電源を入れたり切ったりを遠隔でやりたいのですが、なんとマザーボードの設定にもLinuxのEthToolsでもWakeOnLANの設定がでてこない、というなかなかな状態であることが発覚。皆さんもサーバをPCパーツから組み立てる場合は気にかけておいた方がよいかもしれない、という忠告でした。

 

どうもハードウェアとLinuxの相性が非常に悪いらしく…

今回引っかかったのはこの点。Fedora28のインストール自体は何事もなくできたのですが、その後起動したときに起こったのがこのメッセージ。例でいうなら

watchdog: BUG: soft lockup – CPU#0 stuck for 22s! [swapper/3:0]

というもの。一応いろいろと調べてみると、特にハードウェアとKernelの相性が悪いときに起こるらしく、これが起こるとCPUの処理速度が激減してしまい、まともな処理ができなくなる、という困りもの。一部のページにはKernelPanicではないから大丈夫、と書いてありましたが、しばらくするとKernelPanicになることもあるのでなんとかしないと大変な現象です。ちなみにFedora28だけで起こるものではないらしく、Fedora27でも起こっていましたし、試しにCentOS7をインストールしてみてもやっぱり起こったのでKernelのバージョンだけに依存するものではないらしいです。一応Debianでも試してみようかと思ったのですが、こちらはインストーラがうまく動作しないため諦めました。1CDLinux系ではなっていないように見えるのですが。

 

なお、今のところは

  • とりあえずプライベートなものなのですぐにダウンしなければまあどうにかなる
  • 起動した直後に負荷をかけた場合になりやすいので起動直後は安定するまで放置する方針で
  • この現象で問題となるプロセスが私の場合はswapperだけなので、swapperに関連する一部設定を書き換えることでどうにかなるのでは?(IO系の待機で出てくるらしいのでそのあたりの時間設定やメモリスワップに関する設定を変更すればなんとかなる?)

というところで一部の設定を書き換えてみてちょっと様子見したいと考えています。

 

SELinuxが相も変わらず大変

自分の記事にヒントが書いてあるのでSambaに関してはまあなんとかなるのですが、ほかのサービスになってくるとまた面倒な設定が必要ということで悪戦苦闘をしていました。例えばApacheでは、SSLの証明書を置いておく場所が/etc/httpd以下でないとき証明書を読み込めない(ファイルが存在しない、もしくは空と言われる)状態だったり、ファイルのアクセス権がおかしくなってhtmlファイルを読み込めなかったり、CGIが実行できなかったりと。こちらも必要になったときに再度実験をしてどうなるか確認してみる必要はありそうですね。

 

さて、無事に安定稼働までこぎ着けられるのか?

前のサーバ機のHDDが壊れかけの~だったのでデータ救出にえらい難儀しましたが、そこは根性でなんとかなったのでましでした。あとはこちらのマシンの安定稼働だけです。リモートから電源を入れるのは諦めるとしてもせめて数日くらいは普通に動いてほしいものですが…。

4Kモニタだと解像度がいろいろと大変なことに

C94の感想をとりあえず置いておいて、こっちの話題を書いてみたいと思います。今回、4Kモニタが大分安くなってきたのでメインPCのメインモニタを4Kのものに交換してみたわけです。今まで使っていたモニタはサブモニタとなり、なかなか豪華な構成になったのですが、モニタの物理的なサイズが大分小さいために・・・

 

4Kの素の状態だと文字が細かすぎてやばい

ブラウザとかに書いてある文字がほとんど読めない…という現象に。モニタ本体もそこまで大きいものではないので細かさが半端ないです。この状態で常用するのにはかなりの視力が必要となることは先に書いておきます。で、ここからがWindowModePatchも関わる問題なわけで…

 

ゲーム画面が小さすぎて見えない。しかも表示スケール処理で解像度設定が間違える

という問題が起こるようです。前者は簡単でモニタの物理的なサイズが2倍になったわけでもないに画面の解像度だけが長さ比で2倍以上になり、ゲーム画面がかなり小さくなってしまった訳です。もちろん、ここで出てくるのが拙作のWindowModePatch。こいつでゲーム画面のサイズを4K用に変更してやればうまく使えるゲームであれば解像度変換ができるので困ることではなかったのが幸い。

で、もう一つの問題が、「文字が細かすぎてやばい」にからんでいて、さすがに素の4Kでは文字が読めないのでWindows側の設定でスケーリング処理を行うわけですが、それをするとどうもプログラム本体に伝わる画面の「本来の」サイズがWindowModePatchの処理の時のように変換されて伝わる、という現象があるようです。これ自身は何も間違いはないのですが、この設定は

  • すべてのプログラムに対して同一の設定がかかってしまう
  • スケーリングに内部的に対応しているプログラムであればその制約を受けないようにできる(様子)
  • WindowModePatch側は現段階のプログラム(Ver0.70Alpha)ではこれを知らないのでスケーリング処理を受けた状態の解像度を指定しないとサイズが間違える(4Kの状態ではなくで4K÷スケーリング倍率の状態での解像度を指定する必要がある)

ということで、影響をもろに受けることが発覚してちょっと大変に。この処理については内部的にごまかさないとだめですね…。

 

スケーリング倍率が大きくなるとマウスの移動が大変に

これもどうにかする必要があるかな~と思い始めた課題。マウスカーソルの移動量はどのWindowsだろうと変わらないのでスケーリングにより移動量が減ってしまったように見える、という現象です。FullHDのモニタだったらトラックボールマウスということでボール半回転をさせると画面の端から端まで移動できた(つまり、約1800pxの移動)ですが、4Kモニタになると端から画面中央までしか来ないわけです。するとスケーリングにより2倍表示された状態を考えると移動量が半減したように感じる、というわけです。マウスの移動量を上げると今度はほかのプログラムで本来の移動量に準拠した移動ができなくなるので設定の変更はしたくないのだが…というところです。まあ、そうなるとWindowModePatchがかかっているプログラムだけマウスの移動量を何らかの方法で調節できるような設定がほしいな~というところとなっています。

 

改良点が見えてきた…かな?

4Kになってプログラムを作るときのように膨大な量のテキストを表示させると便利な状態ではうれしい画面の広さが手に入ったので、ここは対応ソフトを増やすとともにWindowModePatchの次回改良点として考えてみたいと考えています。…改良の時間はどうなって作れば?