特にチェックポイントはないのですが、近くの牛角に予約を取っていたので、ついでに行ってきました。
ここは敷地が全て野外の博物館の様になっていて、北海道開拓時代の建造物がこのエリアに移設、復元されています。
明治・大正時代の建物ばかりなので、かなりレトロな雰囲気を体験することができます。
建物自体は未だにしっかりしているので、冷暖房さえ完備すれば住めそう。
こういう所でキャンプしてみたいな。
なんかおった。
出口にリンゴと大根の無人販売がありました。
大根50円。
大根の美味しい食べ方を検索中。
お疲れ様でした。
簡単にできるんだね。
こちらのサイトを参考にしました。
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円かかるでしょう。
うん、やめよう。
メリットがない。
今のギガが足りなくなって、大容量プランに切り替える場合にまた考える。
モデムの設定を変更して、グローバルIPに接続すれば内部の仮想PCに繋がるようにして見たんだけど。
ダメだった🤔。
グローバルIPにpingを送っても応答がない。
いや、正確には、自分のPCからpingを送ると応答があるが、
外部のpingツールサイトを使用すると応答がないのである。
そして、今朝、もう一度確認してみると、
外部からの接続を可能にする設定が消えていた。
※後で分かったんだけど、昨日から今日までの間に、IPv6に切り替わったらしい。おそらく設定項目が変わったのはその影響じゃ無いかと
でも、外部に公開する手段が無くなってしまったので。
頓挫しました。
しゅーりょー。
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
とりあえず画面の表示だけ。
全チェック処理とか、テンプレートに移す処理とか、データを削除する処理とかは次回やります。
あと、管理者アカウントを別に作って、他の人がこのページにアクセスできないようにする必要もありますね。
10/29まで行われたイベントなんですが。
このデッキ、ちょっと訳ありでして。
属性ボーナスとキャラボーナスが一致していてレアリティも全員☆4でスキルレベルも全員レベル5という、このときのために育ててきたのです。
結果はこうなりました。
いやー思ったよりしんどかった。
マジで精神的に修行でした。
心を無にしてパッドを叩き続けてました。
それでも、最終日に簡単に抜かされるという。
何が足りない？
スキルに強いスコアアップが無かったからか？
まぁ、このイベントで1万円とかしたので、しばらく貧乏暮らしです。
TOP100行きたかったなぁ。
マインクラフトサーバプログラムをダウンロードして、
/opt/minecraft-server/配下に設置。
rootがアクセス出来る所ならどこでも良いが、慣例的に/opt配下にディレクトリを作って配置するのが一般的らしい。
こちらの記事を参考にしてserviceファイルを作成。
これを、/etc/systemd/system配下にコピー。
そのあと、パーミッションをRead Onlyに変える。
$ sudo chmod 444 minecraft-server.serviceサービス開始
$ sudo systemctl start minecraft-server.serviceサービス登録
$ sudo systemctl enable minecraft-server.service初回起動時はeula.txtの中身がeula=falseになっているので、これをtrueに書き換えてサービスを再起動。
$ sudo systemctl restart minecraft-server.serviceこの状態でクライアントから接続できることを確認。
OK。