問題の譜面。
いろいろ試したんだけど、
やっぱり指をクロスさせるにはやりづらくって、
いや、指をクロスさせても問題無いのよ。
でも、指をクロスさせなくても、指がホールドのバーの中にあればコンボが繋がる事が分かりまして、
はるかに、こちらの方が簡単。
でも、こんなの最初見たときは戸惑うわな。

えぇ?
— 多岐川ノリ@ぼっち系プログラマー (@n2_taki) November 4, 2020
比較する必要ある??
買いとか、頭おかしくない??
【スペック比較】ラズパイ 400(Raspberry Pi 400) vs 普通のパソコン、使えるのはどっち? https://t.co/65XSlYlNhI
自分、ラズパイ4を使用しているが、この記事には唖然とした。
そりゃ、サイトとしてはラズパイを持ち上げざるを得ないかもしれないけどさぁ。
そもそも、CPUは他のPCと比べて遙かに劣っている。
ラズパイで動作しているOSやアプリケーションはラズパイ用に最適化・軽量化しているので、そんなマシンでPCが使用しているようなアプリがまともに動くわけがない。
Webツールも然りである。ブラウザ自体が軽量化されているので、まともにJSが動く保証はない。
それでもラズパイ4でだいぶマシになった方だけれども。
ただ、ラズパイ4で電子工作を行う場合としては、遙かに魅力的なマシンである事には間違いない。
簡単にできるんだね。
こちらのサイトを参考にしました。
nginxの設定でlistenにhttp2と書き足すだけで良いらしい。
Protocolがh2になっていれば、HTTP2を使用しています。
従来のHTTP1.1では、1リクエストに対して必ず1レスポンスを返す必要があります。
1ページの中に複数のコンテンツ(htmlとかjsとかcssとか)が合った場合、これらのファイルを一つずつダウンロードする必要がありました。
しかし、HTTP2では、多リクエスト、多レスポンスが可能になります。
これはどういうことかというと、送信中のリクエストの応答を待たずして次のリクエストを出せるのですね。
なので、複数のファイルを平行してダウンロード出来るようになります。
なので、その分ページの読み込みが早くなります。
今のブラウザはほとんどHTTP2に対応しているので、あとはサーバ側の設定を変えればHTTP2での通信になります。
あ、それと、HTTP2はデフォルトSSLによる暗号化通信なので、サーバ側に証明書が必要になりますよ。
HTTP2は元々Googleによって開発された通信プロトコルで、後に正式にHTTP2の規格に採用されました。
TCPより上位のプロトコルなので、簡単に双方向の通信を行うことができます。
おそらく、最近のスマホゲームのマルチプレイなんかは、この技術が使われていると思われます。
それ以前は、一つ下位のプロトコルである、TCPで通信していたと思われます。
でも、TCPって思った以上に扱いが難しんですよね。
今、スマホのSIMは、格安スマホのNifmoを利用しているのですが、
プロバイダーがBIGLOBEに変わったので、
格安SIMもBIGLOBEモバイルに乗り換えようか、と思いました。
回線をまとめた方が良いのかな、というざっくりとした考え。
ということで、料金プランを比較してみた。
今利用しているNifmo。
https://nifmo.nifty.com/sim/card_voice.htm
今7GBのプランを使用しているので、月2300円支払っています。
BIGLOBEモバイルの料金プランを見てみると、
https://join.biglobe.ne.jp/mobile/plan/?cl=head_mobile_plan
ギガの容量が違うので、細かい比較はできませんが、
例えば、ギガを6GBに落とせば少し安くなる計算ですわな。
では、今の利用状況を確認すると、
6GBじゃ足らんかったわ。
7GB越えて利用できているのは、先月の繰り越し分らしいです。
おそらく、位置ゲーとテザリングでの利用が大半だと思います。
家ではWiFiでゲームしているので。
うーん、乗り換えるメリットが無くなってきたぞ。
さらに、MNPを行うのに、Nifmoに手数料3000円必要になり、BIGLOBEのSIMを発行して貰うので、おそらく初期手数料3000円かかるでしょう。
うん、やめよう。
メリットがない。
今のギガが足りなくなって、大容量プランに切り替える場合にまた考える。
https://github.com/takishita2nd/HokkaidoWar
最初のプレイヤーの都市選択で確認ダイアログを出すようにしました。
あとは、最後までプレイできることも確認しました。
ただ、戦力差がありすぎると、バトルがワンパンで決着が付いてしまうのが、ちょっとよろしくないですね。
このやり方で設定できるはず。
ただしHTTPは動かさないので、その設定は省いている。
$ sudo iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
$ sudo iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$ sudo iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
$ sudo iptables -A INPUT -i lo -j ACCEPT
$ sudo iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ sudo iptables -P INPUT DROP
$ sudo iptables -P OUTPUT ACCEPT
さらにマインクラフトのポート番号を開ける。
$ sudo iptables -A INPUT -p tcp -m tcp --dport 25565 -j ACCEPT
$ sudo /etc/init.d/netfilter-persistent save
この状態でLANからサーバに接続できることを確認。
そしたら、ルータの設定を変えて、仮想PCに流れるようにしてみようか。
前回のままだと、クライアント側(ブラウザ)を撮影中に閉じてしまうと、動画撮影を終了する人がいなくなってしまいます。
これを防ぐためには、クライアントが生存していることを常に確認する処理が必要になります。
まぁ、今回はプレビュー画面で常にデータのやりとりを行っているので、これを利用しましょう。
def do_GET(self):
parsed = urlparse(self.path)
if parsed.path == '/Streaming':
global lasttime
lasttime = time.time()
enc = sys.getfilesystemencoding()
プレビュー画をリクエストがあったら、その時間を記憶しておきます。
def videoCapture():
global capture
global out
while capture:
nowtime = time.time()
if nowtime - lasttime > 10:
capture = False
out.release()
out = None
break
_, img = cap.read()
out.write(img)
ビデオキャプチャーの周期処理の中で、現在時刻と、プレビュー画要求時の時刻を比較します。
周期処理の時刻がキャプチャー時の時刻より10秒経過していたら撮影を終了します。
ブラウザを撮影途中で閉じた場合、プレビュー画要求時の時刻が更新されなくなりますので、こうすることで、ブラウザを閉じてから10秒後に撮影は終了します。
さて、カメラでやりたいことが終わってしまった・・・
次何しようかな。
特に特筆することはやっていないので、進捗報告だけ。
https://github.com/takishita2nd/diet-mng
とりあえず画面の表示だけ。
全チェック処理とか、テンプレートに移す処理とか、データを削除する処理とかは次回やります。
あと、管理者アカウントを別に作って、他の人がこのページにアクセスできないようにする必要もありますね。