「et cetera」カテゴリーアーカイブ

VirtualBox 6.0にUbuntu 18.04をインストールしたらエラーが気になる

今まで問題なく使用していたVirtualBox 5からVirtualBox 6.0.6に変更し、新規でUbuntu 18.04 LTSをインストールしました。
すると起動時にエラーが出ているのがチラチラ見えます。

直ぐに画面が切り替わりますし、運用上は特に問題なく使えています。
しかし、起動毎に2~3回この画面が出てくるのは気持ちいいものではありません。

*ERROR* Failed to send log

何か情報がないか検索してみましたが、今のところ有効な情報もなく諦め掛けていました。
そして全く別件でVirtualBoxの設定していたところ、このログが表示されることはなくなりました。

もしかしたら裏では出ていて見えなくなっているだけなのかもしれませんが、元々運用上の問題はなかったため解決でいいのではないかと(笑)
その設定が以下となります。

「設定」-「ディスプレイ」-「グラフィックスコントローラー」の設定をVSMVGAからVBoxVGAに変更します。

これだけなんですが、起動時にあのエラー表示は見えなくなりました。

雑所得の税金計算をする固定ページを作成

2019年度は雑所得が20万円を超えそうなので、追加の税金を別で取って置くために、確定申告をした際に必要になる税金を計算する固定ページを作成しました。
税率が変わる金額付近だと計算式も変わってしまい、思ったより計算が面倒だったので自分で使う用に作りました。
※計算結果に責任は負えませんのであくまでも参考程度にお考え下さい

雑所得の税金計算

話題のPayPayでヤフーマネー決済を使ってみた

色んな電子決済が出てきてますが、最近話題になっているPayPay

中国などで流行っているQRコードを利用した決済システムです。
このPayPayはソフトバンク株式会社、ヤフー株式会社が株主の企業です。
QRコード利用でお店のシステムコストが安いとのことですが、消費者側にはどうでもいい話です。
しかしお店のコストばかりでなく、利用者にも凄いメリットがありました。
(キャンペーンなので最初だけだとは思いますが)

なんと、今なら使った金額の20%がPayPayの残高として戻ってきます!
要は20%引きです。
(ソフトバンクユーザーなら1/10、Yahooプレミアム会員なら1/20、通常なら1/40の確率で全額戻ってきます)

まだまだ使えるお店が多くはありませんが、使えるお店が近くにあって、そこで買い物をする予定があるなら使わない手はありません。
ということで使ってみたのですが、始まったばかりで調べても色々と分からない点も多かったので、分かったことを書こうと思います。
※2018/12/07時点での情報ですので、今後変わる可能性があります

PayPayはチャージに使えるクレジットカードに制限があります。
※最後の方に書いていますが、正しくは「チャージできるクレジットカードはヤフーのクレカのみ」です
チャージに使える銀行にも制限があります。
これから増えていくということですが、今は誰もが使えるという状況ではないのは間違いありません。

そこで、対応しているクレジットカードを持っていなくても、対応する銀行口座がなくても使えるのがヤフーマネーとの連携決済です。
私はクレカも銀行も幸いなことに対応しているものを所持していますが、個人的な理由から支払先にしたくなかったので、ヤフーマネーと連携させることにしました。

しかしヤフーマネーでの支払いにも落とし穴がありました。
店員さんもまだしっかりと仕様を把握しておらず、一緒にトライアンドエラーで支払いをしました。
(Tsukumo福岡の店員さん、ありがとうございました)

今ならPayPayアプリを入れて登録するだけで500円分の残高がもらえるのですが、この500円分はヤフーマネーへのチャージ分と一緒に使えませんでした。
500円分の残高でバーコードを表示して500円を超えて支払おうとすると残高エラーになります。
支払いに十分な金額がヤフーマネーに入っていてもです。
そこから追加でチャージしか選択肢がなく、メニューの「お支払方法の管理」-「PayPay残高にチャージ」にて登録している銀行かYahooクレジットカードからのみのチャージになります。
つまりヤフーマネーに残高があっても、PayPayの残高とは合算して使えないということです。
なんという残念な仕様。

そしてやっとPayPayのサイトに記載してある下の画像の意味が分かりました。

PayPayのアプリの説明画面(下の画像)に赤い字と矢印で書きましたが、要は残高・ヤフーマネー・クレジットカードと3種類の支払い方法から選ぶのであって、残高の不足分をクレカやヤフーマネーと合算して支払うということはできないということです。
(ヤフーのクレカだけは残高のチャージに使えます)

せめてヤフーマネーやヤフークレカ以外のクレジットカードから残高へチャージができれば、普通にチャージして合算して支払えるのですが、現状ではそれができません。

分かりやすく書くと以下の3つの支払い方法のどれかを選べということです。
1.残高払い(残高へのチャージは登録した銀行口座かヤフーのクレカでのみ可能)
2.ヤフーマネー払い(コンビニからもチャージできます)
3.クレカ払い(VISA、MASTER、JCBはヤフーのクレカのみ)

個人的には表示するバーコードは1つだけにしてもらって、予め決めた支払いの優先順位に従い、不足分は自動でそこから補えるような仕様にして欲しい。
もしくは残高に対してヤフーマネー・クレカからでもチャージできるように。

ちなみにヤフーマネーへのコンビニからのチャージは1,000円~49,999円までしか行えませんが、1日1回という制限はないようなので、同じ日に2回コンビニからチャージすることで5万を超えるチャージも可能です。
ヤフーマネーへのチャージはローソンでコンビニ払いしましたが、支払いから2~3分でヤフーマネーにチャージされました。
支払いから実際のチャージまでは結構早いです。

ただ、今のままではPayPay残高との合算ができず、ヤフーマネー払いの使い勝手が悪いので、ジャパンネットバンクの申し込みをしました。
(こうやって保持する銀行口座やクレカ・電子マネーが増えていく…)

Tsukumoでの買い物とは別に、ファミマで残高を使った決済をしてみましたが、ストレスなく支払いが完了しました。
(予めスマホでPayPayの画面を開いておいて、支払う直前にバーコードを表示するという動作は必要になりますが)
今後、使い勝手が良くなればもっと普及していくとは思います。
なんといっても支払いの20%、総額100億円の残高へのバックの威力は凄まじいので、急速にユーザーは増えると思われます。
ユーザーが増えれば対応する銀行やクレカ、使えるお店も自然と増えて行きますので今後に期待してます。

2018/12/09 追記
iOS用のアプリが更新されてバーコードの選択がなくなって1つになってました。
残高が不足した場合はヤフーマネー、それでも不足していればクレジットカードでの決済と書かれていたので「やっと改善されたか!」と思いビックカメラに行って決済してみました。

残高が180円、ヤフーマネーが0円、クレカの登録ありで数千円の決済をしてみました。
更新前の時のように残高不足のエラーメッセージも出ずに決済が終了。
その時は使いやすくなったな~と思い帰宅。
家でアプリを見てみると残高180円…
残高を使って不足分をクレカで決済するのではなく、残高で不足してれば全額クレジットカードで決済するんですね…
ということは9万円の残高があって9万1円のものを購入すれば、全額分の9万1円がクレジットカードで決済されると。
頼むから残高を使い切ってからヤフーマネーやクレカで不足分を決済するようにしてください。

Debian 9 (Stretch)のanacronについて

以前、サーバーとしてdebianを運用していた環境ではanacronは動いてませんでした。
基本的に電源を落とすことがないのでcronのみで大丈夫だったからです。

cronはタスクを定期実行するためのサービスです。
anacronはcronと同じように定期実行のサービスですが、常時電源が入っていることを想定していないPCのために、電源ONの際に本来実行すべきだったタスクを実行してくれます。

cronとanacronは別物ですが、cronからanacronを呼んだり、anacronからcron.dailyを呼んだりと切り離せない関係にあります。

ノートPCにdebianを普通にインストールしたらanacronも入っていたのですが、電源入れっぱなしだとcron.dailyが日付変更直後に動きました。
crontabの指定時刻は全然別の時間なのにです。
そこでanacronの仕組みを調査してみました。

まず/etc/crontabを確認してみると以下のようになっていました(一部のみ抜粋)

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 3 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

上の行はcron.hourlyは毎時17分に実行されるとなっており、これは特に問題ありません。
下の行は3時25分に/usr/sbin/anacronを実行し、失敗だった場合は/etc/cron.dailyを実行するとなっており、こちらも問題なさそうに見えます。

しかし実際には/etc/cron.dailyにあるタスクは0:05など日付が変わって少しして実行されるのです。
(logwatchのレポートが0時過ぎに届くので気付きました)

本来、負荷分散させるためにcronのdailyやweekly、monthlyは夜中から明方のランダムな時間にセットされます。
が、anacronが入っていると0時過ぎにdailyやweekly、monthlyが動き始め、負荷分散の意味がありません。
(サーバーはanacron使うなということでしょうが、調べ始めたので最後まで行きますw)

次にanacronの設定である/etc/anacrontabを覗いてみました。

# These replace cron’s entries
1 5 cron.daily run-parts --report /etc/cron.daily
7 10 cron.weekly run-parts --report /etc/cron.weekly
@monthly 15 cron.monthly run-parts --report /etc/cron.monthly

一番左の数字は何日おきに実行するか。
上から1日、7日、1カ月という風になっており、後ろのdaily weekl monthlyとも一致しています。
左から2番目の数字は遅延時間です。
例えば一番上だと5分遅延という設定になっています。
この遅延時間は5分後に実行されるということではなく、0秒~5分の間でランダムな時間で遅延するというものです。

ここまで見てanacronには実行時間の概念がないことに気付きました…
だから0時過ぎに/etc/cron.dailyが実行されるのか。

ちなみにanacronが実行されると/var/spool/anacron以下の
cron.daily、cron.weekly、cron.monthlyというファイルにそれぞれ実行した日付が書き込まれます。
その日付を参照して同じ日に2回、同じ週に2回など重複して実行されないようになっています。
(逆にいえば、この日付を変更して再起動すれば、即時実行させることも可能です)

anacronには実行時間の設定がないのか?と調べたところSTART_HOURS_RANGEという設定があることが分かりました。
早速/etc/anacrontabに設定してみることに。

START_HOURS_RANGE=3-22

これで3-22の間しかanacronは実行されないはず!
ですが、また0時過ぎに実行されてしまう事態に。

更に詳しく調べたら、debian、ubuntuなどではこの設定は効果がないとのこと…

困りました。
そもそもanacronはどこで実行されているのかを調べました。

どうもsystemdがtimerで行しているようです。
/etc/systemd/system/timers.target.wants/anacron.timer

上記のパスはシンボリックリンクで、実際のパスは以下になります。
/lib/systemd/system/anacron.timer

中身を見てみると以下のようになっています。
[Unit]
Description=Trigger anacron every hour

[Timer]
OnCalendar=hourly
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/anacron.serviceが毎時ランダムの最大5分遅延で実行されるということです。
Persistent=trueはPCが起動した直後に実行するかどうかです。

なるほど、ではこのタイマー自体を指定時刻内でしか動かないようにすればいいのではないか、と思ったわけです。
調べると指定時間の設定をどう書けばいいのかが書いてありました。
systemd.time

書き方がちょっとわかりにくいですが「..」でレンジ指定、カンマ区切りで複数指定が出来そうです。
もちろんアスタリスクでワイルドカード指定も可能です。
レンジ指定はなんか上手く動かなかったので、最終的にカンマ区切りで指定することに。
朝の6時~23時まで毎時実行(それ以外の時間はanacronはタイマーで動かない)が以下の設定です。
(起動時即時実行は残しているので、対象外の時間でも起動したり再起動すれば実行されます)

[Timer]
#OnCalendar=hourly
OnCalendar=*-*-* 6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23:00
RandomizedDelaySec=5m
Persistent=true

但し、cronはcrontabに書いた時刻に実行され、そこからanacronが呼び出されるようになっています。
なのでanacronが23:00~6:00まで動かなくても、crontabに書いてある時間にanacron経由でcron.dailyのタスクは実行されます。
仕組みを知れば理解できますが、何も知らないと非常に複雑です。

crontabからanacronが呼び出されてると思いますが、anacronの動作対象外の時間だとcron.dailyは動きませんでした。
タイマーの設定がここまで影響しないとは思うので、何か他で影響が出てるのではないかと思います。

やはりサーバー運用の場合はanacronを止めた方が分かりやすい気がします(笑)

Surface Arc Mouse

タブレット(2in1)にてMicrosoftのArc Touch Mouse (アーク タッチ マウス)を使用していましたが、新型が発売されたので買ってみました。

Surface Arc Mouseにはバーガンディ、グレー、コバルト ブルーの3色しか用意されておらず、ブラックという選択肢がありません。
但し、法人用に黒が用意されているようで、Microsoftストアからであれば個人でも黒を購入することができます。

名前もSurface Arc MouseではなくMicrosoft Arc Mouseとなっています。

グレーは汚れが目立ってくるので、今回はブラックを購入しました。

形は台形から長方形へと変わっています。
個人的には握りやすさはあまり変わっていないと思いますが、手の大きさによっては感じ方が違うかもしれません。

Microsoft Arc Mouse (ブラック) 比較1

インジケーターはより小さく、目立たなくなっています。
旧Arc Touch Mouseとは違い光っていなければそのにインジケーターがあること自体がパッとは分かりません。

Microsoft Arc Mouse (ブラック) 比較2

Microsoft Arc Mouse (ブラック) 比較3

裏側は波打った形状ではなくなり、伸ばしても折ってもシワがない構造となりました。

Microsoft Arc Mouse (ブラック) 比較4

折り曲げた上での比較です。

Microsoft Arc Mouse (ブラック) 比較5

若干違いますが、持った感じはあまり違いは感じません。

最後に実際に使った感想です。

クリック感は全く問題ないです。
Logitechの薄型マウス「Touch Mouse T630」も持っているのですが、T360は上面全体が沈み込む感じでクリックとなり、個人的に好きになれないクリック感でした。
しかし新型Arc Mouseは通常のクリック感で全く違和感がありません。
カチッと他のマウスよりは少し大きめの音はしますが、個人的には音もあまり気になりません。
ちょっと気になるのはクリックが旧Arc Touch Mouseよりも少し硬めです。
ただ旧Arc Touch Mouseは指の根元の方をクリックしようとしてもクリックできませんでしたが、新型は割と根元の方を持ってもクリックが出来ます。
もう少しクリックを軽くしてもよかった気はします。

縦スクロールは旧Arc Touch Mouseのカリカリカリという振動と音が気に入っていましたが、新型は無音です。
ここは少し残念ではあります。

今回から追加となった横スクロールは、微妙に使い辛いです。
縦スクロールと横スクロールのスクロール量が個別に設定できないので、個人的には横スクロールが使い難いです。
とはいえ、横スクロールがない旧Arc Touch Mouseよりは全然マシではありますが…

MACのMagic Mouseのように斜めに滑らかには動きません。
またピンチイン・ピンチアウトなどのジェスチャーも使えません。

総合的に見れば、旧Arc Touch Mouseから買い換える価値はあると思います。

MGSV TPP(PC版)のフレームレート60Hz上限のロック解除

MGSV(メタルギアソリッドV) TPP (ファントムペイン)のPC版ですが
MGSV GZと同じくフレームレートの上限が60Hzに制限されています。

GTX970 x2のSLI+144Hz駆動のモニターを使っていますが
MGS5 TPPでは上限の60Hzに張り付いた状態で非常にもったいない・・・

そこで上限のアンロックをすることに。

MGSV GZではバイナリファイルを書き換える必要がありましたが
今回のTPPでは同じファイルが見当たりません。

どうにか出来ないかと調べていたら設定ファイルらしきものを発見!
(インストール環境によってパスが変わる可能性はありますが、TPP_GRAPHICS_CONFIGで検索すれば見つかるかと思います)
ちなみにNVIDIA GeForce Experienceから設定変更してもこのファイルが書き換わります。
なので、手動で書き換えたからといって問題はないと思いますが
何らかの方法で書き換えをチェックされ、アカウント停止になっても保証は出来ませんので
あくまでも自己責任で変更してください。

C:\Program Files (x86)\Steam\userdata\251750583\287700\local\TPP_GRAPHICS_CONFIG

設定ファイルを発見したものの、どう設定を書き換えればいいのか分からず。

で、調べてみると既に解除した外国人の方が!(早い)

TPP_GRAPHICS_CONFIG 内の以下の項目を書き換えればいいようです。

変更前
“framerate_control” : “Auto”,

変更後
“framerate_control” : “Variable”,

AutoをVariableに書き換える、やることはこれだけです。
グラフィック設定をゲーム内などから更新するとAutoに戻ってしまいますので
その都度手動での書き換えが必要となります。

尚、GTX970 SLIでも全ての設定が最高品質だと144Hzまでは上がりません。