さくらのVPSでのNginx+ティラノスクリプトでのリリース処理

はじめに

この記事は過去に書いた以下の記事のティラノスクリプトのゲームをさくらのVPSにリリースした時の覚書です。

gamelinks007.hatenablog.com

前提

さくらのVPSとNginxを使い、ティラノスクリプトのゲームをリリースする手順。 前提として標準OSのインストールでUbuntu18.04を選択してインストール済みであること

またLetsencryptを使ってSSL化するまでの処理も記載しておく

基本的にパッケージマネージャからNginxやLestsencryptをインストールので他のUbuntu(20.04とか)でも基本的にリリースできると思う

手順

まずは、さくらのVPSへとログインする。ログイン用のパスワードやアカウントはOSの標準インストール時に設定したユーザー名とパスワードでログイン

login: ubuntu
passowrd: hogehoge

ログイン後、まずはパッケージのアップデートをする

sudo apt update

アップデートが完了後、必要なパッケージをインストールしていく

sudo apt install -y nginx letsencrypt git

今回はGitHubで管理しているティラノスクリプトのゲームを使用するためgitをインストールしている

インストール完了後、ホームディレクトリ以下にティラノスクリプトのゲームをcloneしてくる

git clone https://github.com/username/tyrano_game_name.git

次に、Nginxの設定を編集する。編集する内容としてはNginxが静的なコンテンツを返している部分を編集するので/etc/nginx/sites-enabled/defaultviなどで開いて以下のようにする

server {
    listen 80;
    listen 80 [::]:80
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl default_server;
    listen 443 [::]:443 ssl default_server;
    
    root /home/ubuntu/tyrano_game_name/;
}

なお、ポートの80にアクセスした場合は強制的に443へとリダイレクトさせている。

次に、SSL証明書の設定を行う。

まずはNginxをいったん止める

sudo systemctl stop nginx

これはSSL証明書の発行時にエラーが発生するのを回避するため

次に、Letsencryptを使って証明書を発行する

sudo letsencrypt certonly --standalone -d domain

証明書発行後、証明書が格納されているディレクトリへのアクセス権限を付与

cd /etc/letsencrypt && sudo chmod 777 live && sudo chmod 777 domain

最後に、SSL証明書を使うようにNginxの設定を変更

server {
    listen 80;
    listen 80 [::]:80
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl default_server;
    listen 443 [::]:443 ssl default_server;
    ssl_certificate     /etc/letsencrypt/live/domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;
    
    root /home/ubuntu/tyrano_game_name/;
}

これで設定はOK!

あとは設定を再読み込みして、Nginxを動かせばリリースは完了

sudo systemctl reload nginx
sudo systemctl start nginx

注意点

SSL証明書ディレクトリへの権限はreadonlyにした方が良いかもしれないので変更しておくといいかも

あと、80にアクセスするときのリクエストは別にわたさなくてもいいかもしれない

【Ruby 3.0 Advent Calendar 2020】Ruby3.0で非推奨から廃止になるメソッドたち【4日目】

はじめに

Ruby 3.0 Advent Calendar 2020 4日目の記事になります。

昨日は、【Ruby 3.0 Advent Calendar 2020】Ruby3.0でRubyで実装されたメソッドたち【3日目】です。

gamelinks007.hatenablog.com


長らく非推奨だったメソッドを「Ruby3.0のリリースに合わせて廃止しようぜ」みたいな動きがあったりします(最近のruby-trunk-changesやGitHub上にあるRubyリポジトリとか見てると)

今日は長らく非推奨だったがRuby3.0で廃止されるメソッドについて一部紹介します。

廃止されるメソッド

ENV#index

github.com

1.9のあたりからdeprecatedの警告が表示されていたENV#indexを廃止しています。
引数に渡された値に対応するkeyを返すメソッドです。今後は代わりにENV#keyを使うことになりまね

IO周りのメソッドとARGF周りのメソッド

github.com

IO#linesIO#bytesIO#charsIO#codepoints
ARGF#linesARGF#bytesARGF#charsARGF#codepointsが廃止されています。

IO#linesARGF#linesは今後IO#each_lineARGF#each_lineを使うことになりです。
その他のメソッドも同様にeachがprefixについたメソッドを使うことになりそうです

リリースまでに廃止されそうなメソッド

github.com

このPRに記載されているメソッドなどはまとめて廃止されそうですね。
とはいえ、まだ議論中のようで廃止されるのは濃厚ですが、Ruby3.0で廃止されるかはまだわかりません。

また、こちらのTime#succもRuby3.0で廃止される可能性が高そうです。

github.com

おわりに

ここで紹介したメソッドは廃止されるため、使用されているgemなどを見かけたらコントリビューションチャンスかもしれませんね。
また廃止されるメソッドを知っておくことでRuby3.0へのバージョンアップ対応もスムーズに行けそうですね。

【Ruby 3.0 Advent Calendar 2020】Ruby3.0でRubyで実装されたメソッドたち【3日目】

はじめに

Ruby 3.0 Advent Calendar 2020 3日目の記事になります。

昨日は、【Ruby 3.0 Advent Calendar 2020】Ruby3.0に投げたPull Request【2日目】です。

gamelinks007.hatenablog.com

今日はRuby 2.7から対応されている一部メソッドがRubyで実装されていることに触れつつ、Ruby3.0でRubyで実装されたメソッドたちを一部紹介します。

RubyRubyを実装する

まずRubyRubyを実装するというのがいまいちピンとこない方もいると思いますので軽く説明します。

RubyRubyを実装するという提案はko1さんがRubyKaigi 2019で発表された内容を元に導入されました。

rubykaigi.org

youtu.be

発表されている内容をかいつまむと、組み込みメソッドでキーワード引数を受け取るメソッドやメソッドの内部で例外処理(Cのコードでrb_rescue()を使用しているケース)をしている場合などで高速化できるというものです。
ただし、キーワード引数周りで高速化する場合はキーワード引数を渡さず実行すると遅くなる可能性があります。

また最近ではInteger#to_iのような自分自身を返す組み込みメソッドなども高速化(またはCのコードで実装した場合と同程度の速度)ができることが分かっています。

実はRuby 2.7の段階で既に一部のメソッドはRuby(とC)で書かれていたりします。
具体的にはKernel#warnとかTracePoint#inspectとかですね。

今日はRuby3.0で新しくRuby(とC)で実装されたメソッドを一部ですが紹介していきます。

Rubyで実装されたメソッドたち

Arrayクラス

*** Array#shuffle! & Array#shuffle

github.com


github.com


Array#shuffle!Array#shuffleはキーワード引数としてramdomを指定でき、渡したRamdomオブジェクトを元に疑似乱数列を作ることができます。

キーワード引数を使っている組み込みメソッドなので高速化の一環としてRubyで実装されていると思われますね。

*** Array#sample

github.com


こちらも同様にキーワード引数としてramdomを指定できます。こちらは乱数ジェネレータとして使用されているようです。
同様に高速化の一環としてRubyで実装されていると思われます。

Dirクラス

*** Dir.open & Dir.new

github.com


github.com


引数に渡したpathを元にディレクトリストリームを開く特異メソッドです。
キーワード引数でディレクトリのエンコーディングを指定することができます。

なので、今後は少しディレクトリを開くのが速くなるかもしれませんね。

*** Dir.[] & Dir.glob

github.com

github.com


パターンにマッチするファイル名を文字列の配列として返す特異メソッドです。
basesortなどのキーワード引数でベースディレクトリの指定やソートなどが指定できます。

キーワード引数周りの高速化の一環として導入されているようです。
つまりRuby3.0では今までより少し速くディレクトリの走査ができそうですね!

Integerクラス

Integer#abs & Integer#magnitude


github.com

自分自身の絶対値を返すメソッドです。
このメソッドはキーワード引数などは使われていませんが、高速化出来ているものです。
また特徴的な点は、selfをCの関数に渡している点ですね。

この実装が入る少し前にRuby側の変数をCの関数に渡すことができるようになるコミットが入っています(ただし、組み込みメソッドの実装でのみですね)
これを使って実装されているため速度向上などが図れたと思われます。

Kernelモジュール

Kernel#clone

github.com

オブジェクトの複製を返すメソッドです。キーワード引数を使うことでfreezeされたオブジェクトを返すこともできます。
これもキーワード引数周りの高速化で導入されたものですね。

ちなみにこれは僕がPR出したやつだったりします。

Kernel#Float

github.com

引数に渡されたものをFloatへと変換を試みるメソッドです。
キーワード引数で例外を返すかどうかを選ぶことができます。

これも僕がPR出したもので結構速くなってます。

おわりに

ここで紹介したメソッドたちはRubyで実装されたメソッドの中の一部です。
これ以外にもいくつかのメソッドがRubyで実装されています。

また現在、僕が投げている提案ではTrueClassのいくつかのメソッドをRubyで書いて高速化できるんじゃないかと考えています。

bugs.ruby-lang.org

このようにRubyを書くことでRuby本体の性能向上に一役買うことも今後できるかもしれません
「Cは書けないけど、Rubyなら書ける」という方も今後コントリビューションできるようになるかもしれないので夢が広がりそうですね

【Ruby 3.0 Advent Calendar 2020】Ruby3.0に投げたPull Request【2日目】

はじめに

Ruby 3.0 Advent Calendar 2020 2日目の記事になります。

昨日は、【Ruby 3.0 Advent Calendar 2020】Ruby に右代入がやってくる【1日目】です。
secret-garden.hatenablog.com

右代入、このまま何事もなく入るといいなぁ……

この記事では、僕が投げたPull Requestで何をやっているかを書いています。

ちなみに

これまでマージされたPull Requestの数を数えてみたんですが、26個みたいです(以下のリンクから確認できます)

github.com

テスト修正関係

基本的には`make test-all`を複数回動かす際のテスト修正になっています。

github.com

これはdid_you_meanのテストでBook::Coverが二回目のテストで定義済みのため落ちていたのを修正しています。
当初はBook.send(:remove_const, :Cover)するだけで対応できそうかと思ったんですが、別の個所でCoverageが期待される挙動となってしまったので、Book::Spineへとリネームしています。

そのうえで既に定数として定義済みであればそれを削除するようにしています。

github.com

これは二回目以降のテスト時にAWESOMEが既に定義済みである警告を無くす対応です。
先ほど同様remove_constで削除しています。

github.com

こちらも同様に二回目以降のテストで警告が出ていたので、定義済みの定数MyBookStructremove_constで削除しています。

github.com

で、先ほどの修正で漏れていた箇所(シンボルで渡していなかったの)を修正したものです

github.com

複数回テストを回す際にdid_you_meanで使用するフォーマッタの初期化がされていなかったため意図しない挙動になっていたのを修正しています。
setupDidYouMean.formatter = DidYouMean::VerboseFormatter.newしているだけの対応ですが、原因が上手くつかめず苦労した覚えがありますね……

github.com

二回目以降のテストでwebrickserver[:DocumentRootOptions][:NondisclosureName]が初期化されていないため失敗していたのを修正しています。
具体的にはserver[:DocumentRootOptions][:NondisclosureName] = []のように初期化しています。

github.com

make test-all TESTS="--repeat-count="50""のように実行すると時々テストが落ちるという問題に対応したものです。
原因としてはReadline.special_prefixesなどの区切り文字の設定周りが初期化されていないことでテストが落ちていました。

そこでteardownにそのあたりを初期化するように修正しています。

CI修正関係

github.com

RubyではWindows用のCIとしてAppVeyorを使っているんですが、これが時々なぜか落ちるという現象がありました。
調べてみたところshallow_clone: trueと設定している場合でうまくソースコードをcloneできないということがあるとわかりました。

github.com

そこで、cloneする深さをclone_depth: 10のように設定して落ちないようにしています。
正直落ちるかどうか不安でたまらなかった覚えがあります……。

github.com

で、治ったみたいだったんですが、PR時のCIチェックが別のエラーを出してきたので直したのがこれです。
原因としてはソースコードをcloneしてくるときにGitのユーザーなどが設定されていないのでエラーになっていました。

で、とりあえず初期設定でユーザーなどを設定したんですが、あまりいい直し方ではなかった感じですね……。

ドキュメント関係

github.com

最近のRubyではRubyRuby自身(と一部のCコード)で組み込みメソッドを書くと高速化するケースがあります。
そういったケースでRuby内部のRubyソースコード上にドキュメント用のコメントが記載されてます。

github.com


それらのコメントは.documentに追記することでビルド時によしなにドキュメント生成を行ってくれます。
で、array.rbが無かったのでそれを追加しているPRですね。

github.com

これはHash#deleteのドキュメントで矢印になっていないのを修正したものですね。

github.com

これはドキュメント内のリンクがOracleのドキュメントにリダイレクトされたのでわかった修正ですね。
リダイレクト先のURLに変更しています。

github.com

これはrb_class_realの挙動についてのドキュメントでtypoしてそうと思って投げたPRですね。
実際にはドキュメントが違ってた模様(typoではなかった)

またこの一件でコードの修正とかもされてます(詳しくは下記を参照)

github.com


ruby-trunk-changes.hatenablog.com



github.com

これはアクセス先のURLがhttpsに変更されていたので修正しています。

性能向上関係

github.com

ko1さんがRubyKaigi2019で発表されていた「RubyRubyを実装して高速化する」件をPRにしたものですね。
今回はKernel#cloneでそれを行っています。

github.com

こちらはKernel#Floatのバージョンですね。

コードの修正関係

github.com

これはrb_str_clearが宣言されているが使われていないのでそれを削除しています。
多分、以前は使うこともあって残っていたんだろうなぁというコードですね。

github.com

これはstaticを付けてもよさそうな関数だったので付けた方がいいのではと投げたPRですね。

github.com

これも同様にstaticを付けてます。

github.com

hash.c内でいくつかの関数にstaticを付けています。

github.com

こちらも同様にstaticを付けています。

github.com

こちらはrb_int_ceilrb_int_floorにstaticを付けています。

github.com

int_even_prb_int_odd_pで現在では使われてなさそうな処理を削除しています。

github.com

flo_prevflo_nextの処理がほとんど同じだったのでまとめています。

バグ修正関係

github.com

Time#strftimeの引数にTimezoneを渡した時に表示される出力結果がおかしいのを修正しています。
直近で似たような修正をnobuさんがされていたのでそれを参考に修正したやつですね。

github.com

Time#to_aでも同じようにTimezoneを渡した時の出力がおかしいのを修正しています。

雑感

そこそこ色々と投げれているなぁと感慨深くなりました。

自分が投げたパッチが取り込まれてるRuby3.0がリリースされるのが楽しみですね

社会人になってからプログラマーになった話

はじめに

少し前にFediverseのTLで「別業種とかからプログラマーになった話があるとよさそう」と盛り上がってた。

僕自身は社会人になってからプログラマーとして仕事してるので、その辺の経験とか経緯を記事にしてみると需要がありそうかなと思い、書いてみた。

 

プログラマーになるまでの経緯

学生時代

学生時代は特にプログラミングをしていたわけではなく、せいぜいHTMLとかCSSでWebサイトを作ってそれをFTPとか使ってサーバーにあげたりしてるくらいの日々でした。

 

あとはM.U.G.E.Nという自作のキャラで格ゲーができるゲームで自作のキャラを作るなどはしてました。

ja.wikipedia.org

 

まあ、ほとんどコードの意味とかは分からなくてコピペして「おお、動いた動いた」とかしてた。

 

大学ではCやC++でのゲーム制作(主にDXライブラリでの)とかに興味を持ってましたが、特に熱中してやることもなくそのまま卒業(なお、大学では民俗学とか行政関係の法律とかを学んでたので、今の仕事には全然活かせてない感じ……)

社会人になってからプログラミングを始めるまで

就職後、特にプログラミングに接する機会はない生活でした。あったとしてもせいぜいExcelとかでマクロ組んだりとかぐらい。

 

本格的にプログラミングをやり始めたのは社会人一年目もそろそろ終わりそうな時期でした。

 

契機は、自作のゲームを作りたくなったことでした。

 

大学時代、クトゥルフTRPGとかでゲームシナリオ書いたりしてよく遊んでて、ゲームを作る楽しさに触れてました。社会人になってからもちょくちょくシナリオを書いては気心知れた人たちと遊んでましたねー。

 

で、そんな中「やっぱりPCとかで動くゲームを作りたい……‼」という気持ちが高まってきてて、「よし、ちょっと頑張ってやってみようか!」となりゲームを作りはじめました。と同時にゲームリンクスというゲームを作るサークルも立ち上げたり(これがブログの名前の由来だったり)

ゲームをはじめたころ

とりあえずノベルゲームくらいなら作れるだろうと思い、手始めにティラノスクリプトとかジョーカースクリプトを触りましたね。

 

tyrano.jp

 

jokerscript.jp

 

確か一番最初に作ったゲームはジョーカースクリプトで作ったやつじゃなかったかな……?

 

まあ、素材の読み込みとかタグの理解とかかなりてこずりながら作ってたように思います。

その分、完成した時の達成感は何とも言えないものがありました。

 

しばらくはジョーカースクリプトとティラノスクリプトを使ってゲーム制作をしてたんですが、だんだんと開発スピードが遅くなってきてたんですね。

 

背景には、プログラマーが一人(僕だけ)に対してシナリオを書く人間が4人くらいいたことがあります。

ゲームにする際の人的リソースが圧倒的に足りなかったんですよね……。

「このままだと体がいくつあっても時間がない……より能率的にノベルゲーム作るものないかなぁ……」とか考えてた。

 

で、どうするかなぁと思ってたところに天啓が

 

「能率的にノベルゲーム作れるエンジンがないなら、自分で作ればいいじゃない」と

 

ここで僕のプログラミング学習が本格的にはじまりました。

 

最初に学んだ言語はCだった

とりあえず大学時代にDXライブラリについて調べていたこともあり、DXライブラリ + C言語で簡易なノベルゲームエンジンを作ることにしました。

 

確か当時は「猫でもわかるC言語」とかをよみながらC言語の文法とか学びつつ、試作でノベルゲームっぽいものを動かしてたと思います。

当時のソースコードはまあ酷いもので、タグを処理する関数が1000行とか超えてました……。

 

ただ、当時はそういうコードがよくないコードだとは思わず、動くようになるのが楽しくて仕方がなかったのをよく覚えています。

 

で、だいたい三か月くらいでファーストリリースできるくらいのものはできました。

かなり簡単なタグの処理(立ち絵とかBGMとか)とセーブとロードくらいしかない簡単なものでしたが、リリースできた時の感動はいまだに忘れられないです。

 

その後、一年くらい細かなアップデートを繰り返しながらノベルゲームをだいたい7~10本くらいリリースしてましたね。

 

Rubyとの出会い

そんな感じでC言語でのゲーム制作を楽しんでいましたが、だんだんつらいところも出てきました。たとえば、(自分が書いたコードながら)コードが長くて読みにくくなってきましたし、何よりC言語の書かなければならないコード量が煩わしく感じるようになってきました。

 

そんな時、Rubyと出会いました。たしかDXRubyというゲームライブラリを知って、そこからRubyをはじめたと思います。

 

Cよりもかなり短くコードが書けることに感動しつつ、Rubyを書くようになっていきました(といっても比重は相変わらずC言語のほうが多い日々でしたが)

 

これがOSS活動を知ったきっかけでした。

 

OSS活動との接点

OSS活動について知り、「僕もOSSみたくソースコードを公開してみたい」と思うようになってたんですが「何を公開するかなぁ」というのが当時の悩みでした。

 

当時の僕が持ってるプロダクトといえば自作のノベルゲームエンジンだけで、コードもきれいとはいいがたいものでした。

 

とはいえ他に公開できるようなものもないですし、僕の書いたコードをわざわざ見る人もそうそう居ないだろうと思い最終的にはGitHubで公開しました。

 

で、公開したところコードを読んだ方がおられまして、「これはよくないコードだ」とご指摘いただいたんですよね。

で、その方から「Cで書くよりはC++で書いたほうがいいんじゃないか?」と言われたことがきっかけで今度はC++をはじめることになったんですよね。

 

C++との出会い

まあ、Cに比べて覚えることも多く苦労した覚えがあります。特にコードの指摘をしてくださった方がC++にかなり詳しい方だったのでダメ出しとかももらいながら書いていた日々でした。

 

でも、Cよりもできることの幅が広がっている感じもあり、楽しい日々でもありましたね。

 

ちょうど、この頃にC++関係でいろいろ本を読んでいたんですが、だいたいの本が古くて(C++03とか下手したらC++98とか)つらかったですね。

 

まあ、そのおかげでプログラミング言語にもバージョン(や仕様)が年代ごとにあるということをよく理解できたので良かったと思います。

 

RubyKaigiに参加

で、そんなころ隣の県の広島でRubyKaigiをするという情報が入り単身乗り込むということをしてました。

rubykaigi.org

 

多分、はじめて参加した大きなカンファレンスだったんじゃないかな?

 

参加したことで、Rubyコミュニティの圧倒的Rubyへの情熱を浴び、気づいたら熱狂的なRubyistへと変貌していきましたね……。

結局、RubyKaigiへは毎年参加するようになってました(翌年は仙台、翌々年は福岡)。このころくらいからだいぶアクティブにコードを書いたりするようになったと思いますね。

 

本格的にプログラミングにのめりこむ

このころにはC言語はあまり書かず、だいたいRubyC++で何かしらコードを書くようになってました。

特にRailsでサークルのWebサイト作ったりとかしてた頃ですね。

 

で、そんなころにMastodonのブームがやってきました。

 

Mastodon(分散SNSとの出会い)

はじめ、Mastodonが登場した時は「へー、そういうのが出たんだ」くらいにしか思ってませんでした。

 

その後、Mastodon(というか分散SNSの特徴)を知っていくうちに「僕もサーバーを立ててみよう」となり、Creatodonを立てました。

 

gamelinks007.net

 

当時はCreatodonという名前でもなく一時創作系のサーバーと銘打ってました。

 

ただまあ、ほかの大規模なサーバーに比べて知名度とかもなかったので基本的に僕が使っているだけな感じになってました(しかし、それも仕事が忙しかったりすると使うのを忘れたり……)

 

しばらくアップデートとかもできない日々が続いてて重い腰を上げでアップデートを始めたのがその年の九月ぐらいでした。

 

 

gamelinks007.hatenablog.com

 

ちょうどこの頃からMastodonの使用率がTwitterを超えだしたので、TwitterをやめてMastodonへ引っ越ししたりもしましたね。

 

あと、Mastodonでログインできるアプリとか、PleromaとかHivewayとか立ててみたりとかしてましたね。

 

ちなみにこの辺の活動を見ていた方からお誘いいただき、松江Ruby会議でMastodon他分散SNSについて話す機会をもらったりもしました。

 

OSSへの初コントリビューション

アプリを作ってGitHubで公開とかそういう意味でのOSS活動はしてたんですが、大きなOSSプロジェクトにコントリビューションすることはない日々を過ごしていました。

 

そんな時、Redmineのドキュメント関係でコントリビューションチャンスが来たんですよね。

 

gamelinks007.hatenablog.com

 

HerokuでのRedmineのデプロイ手順が少し情報が古く、うまくいかなかったんですよ。

で、そんなことをMastodonでつぶやいていたところフォロワーさんからフィードバックをもらってうまいことデプロイできたと。

 

ちょうどその時の手順もメモしていたのでRedmineの公式ドキュメントを編集するといいんじゃないかとなり、OSSに初コントリビュートとなりました。

 

転職

この頃には、そこそこコードを書くようになってきていたんですが、相変わらず仕事ではコードを書くような場面はありませんでした。

 

そんな時、現職の会社へと転職するチャンスが来たんですよね。で、これまで作ってきたものとかを紹介して転職することができました。

ほかの人と違ってすでにあれこれやっていたのでポートフォリオを作るのに困ったりとかそういうのは無かったですね。

 

プログラマーになってから

転職後

転職後は、初学者向けにプログラミングを教えたりしながら教材を作ったりしてました。

最近は開発もやるようになってきたので「スキルが身についてきたなぁ……」とか思ってます。

 

転職後のOSS活動

転職後もちょっとしたアプリを作って公開したりはしてました。がRedmineのドキュメント編集した時のような大きなOSSへのコントリビューションはあまりありませんでした(あってもBoostjpのドキュメントにPR送ったりとかぐらいなじゃいかなぁ……)

 

で、そんな中Ruby自体の実装に興味を持ち始め「いつかRubyにコントリビューションできるといいなぁ」とか思ってました。

 

そんな時、ruby-jpでコミッターの方から「テストの修正してくれる人いませんか?」という話が出たんですよね。

で、さっそく飛びついて「やりたいです!」といい、テストの修正に取り掛かりました。

 

その後、テストの挙動の把握など苦労しながらも修正PRを出せたんですよね

ちなみに初めてマージされたのはこれ。

 

github.com

 

まあ、マージされたのがうれしくて小躍りしましたね!

 

で、このPRがマージされたのがうれしくてどんどんRubyの実装を読むようになっていきました。

その後、builtin対応とかCの関数の修正(使われていないifの分岐を削除とか)してPRを投げはじめましたね。

 

そして、最終的にはこういうイベントもはじめたり……

 

hamadarb.connpass.com

 

 

おわりに

これがこれからプログラマー(ITエンジニアのほうが近いか?)になりたい人に参考になるかはわかりませんが、こういう道順を経た人もいるんだよと知っていただければ幸いです。

 

ちなみにC言語学びだしてからRubyに初コントリビューションするまでで5年くらいだったということに記事をまとめながら気づいてびっくりしましたね。

なんと遠くまで来たんだなぁと感慨深いです。

 

 

Google Cloud Run + Nginx でティラノスクリプトのゲームをPWAでリリース

はじめに

そこそこ規模の大きいティラノスクリプトで作られたゲームをPWAでリリースしようとした際に起きた現象とその対策について書いた記事です。
内容としてはPWAでリリースすることを考えている人向けの記事になります。

またDockerなどを使っているので、どちらかといえばプログラマー向けの内容になっています。

起きたこと

とある大学から「学生の学習用にティラノスクリプトを使ったゲームを作りたい」と話がありました。
ちなみに、既にある程度の実装などは済んでいて、追加で実装してほしいとのこと。

逐一修正したものをZIP形式でやり取りするのも億劫なので、Netlifyなどのホスティングサービスを使うことにました。
Netilfyとか使えば、GitHubから自動的に最新のアプリをリリースできるので

ただ、実際に動作させると

  • 効果音がずれる
  • 処理がもっさりする

などの問題が発覚。

で、どうしたもんかなぁと考えてました。

原因

原因としては使用しているホスティングサービスのサーバーとの物理的距離の問題とサーバーのスペックの問題のようでした。
ちなみにリロードしてブラウザで表示されるまで15000msとかかかってた……

またブラウザへ表示するまでのレンダリング時間がかなりかかっていることからキャッシュか静的コンテンツを高速に配信することができれば大幅な改善が期待できそうでした。

対策検討

とりあえず処理が重いのはサーバーのスペックと物理的距離のようなので、それらをまず変更することを検討。
また、静的コンテンツを高速に配信してくれると評判のNginxを間にかますことで改善されると考えました。

できればリリースなどはコマンドでサクッとしたいですし、なおかつ使用するときだけ料金が発生するのがいいと考えました。
で、大阪リージョンがあるし、かつコマンドでリリースが楽にできるGoogle Cloud Run がよさそうと思い、そちらを使うことしました。

やったこと

まずは、ティラノスクリプトで作ったゲームのソースコードにDockerfileを以下のように追加します。

FROM nginx:alpine
COPY . /usr/share/nginx/html
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf

EXPOSE $PORT

CMD ["nginx", "-g", "daemon off;"]

COPY . /usr/share/nginx/htmlはティラノスクリプトの静的コンテンツをNginxで処理するディレクトリにコピーしています。

またGoogle Cloud Runで使用するポートが8888固定なのでEXPOSE $PORTで使用するポートをよしなにできるようにしています。
またNginxの設定ファイルもCOPY ./nginx/default.conf /etc/nginx/conf.d/default.confでコピーし、Google Cloud Runで動作するようにしています。

次に、nginxディレクトリをソースコード内に作成します。
nginxディレクトリにdefault.confを以下のように作成します。

server {
    listen       8080;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

使用しているポートを変更しているだけですね。

あとはGoogle Cloud Run で使用するコンテナをビルドしてデプロイすればOKです。

# コンテナのビルド
gcloud builds submit --tag gcr.io/<PROJECT-ID>/tyrano

# コンテナをデプロイ
gcloud run deploy --image gcr.io/<PROJECT-ID>/tyrano

これでリリースができました。

結果

Netlifyを使っていた時にリロードしてブラウザで表示されるまで15000msとかかかっていたのが、大体700msくらいまでに抑えることができました!

かなり快適になったので良い感じです。

GitHub Pages + PWAでティラノスクリプトのゲームをスマホで動かしてみた

はじめに

ティラノスクリプトで作ったゲームをPWAにしたい人でGitHub Pagesを使いたい人向けの記事です。

動機

以前、この記事を読んでティラノスクリプトでもPWA対応ができることは知っていたんですが試したことがなかったのでやってみた。

qiita.com

で、PWA対応ができているかを確認するのにいちいちレンタルサーバー借りたりするのも面倒臭かったのでGitHub Pagesで代用してみました。

やったこと

まずはGitHubに適当な名前でリポジトリを作ります。
リポジトリ名はあとで使うので控えておいてください。

次にティラノスクリプトの公式サイトからサンプルのゲームをダウンロードします。
今回は数多くのゲームがリリースされていることを鑑みてv4系列を使用しました。

tyrano.jp

また、PWA対応なのでスタンダードパッケージを使っています。

ダウンロードしてきたサンプルを適当なディレクトリに入れてから git initします。

あとは、manifest.jsonを記事を参考に以下のように作成します。
追加する箇所はindex.htmlと同じ階層です。

{
    "short_name": "SHORTNAME",
    "name": "GAME_TITLE",
    "icons": [
        {
            "src": "link.png",
            "sizes": "144x144",
            "type": "image/png"
        },
        {
            "src": "link_02.png",
            "sizes": "192x192",
            "type": "image/png"
        }
    ],
    "start_url": "/<作成したリポジトリ名>/",
    "display": "fullscreen",
    "background_color": "#000",
    "theme_color": "#fff",
    "orientation": "landscape"
}

一つ注意が必要なのはstart_urlの項目です。

GitHub Pagesでは作成したリポジトリ名でドメインの階層が作られています。
なので/にするとファイルが見つからないことになります。

あとはgit commitとかして、git pushリポジトリにpushすればOKです。

最後に、作成したリポジトリの設定からGitHub Pagesを使うようにすればOKです。

ちなみに実際に作ったものがこちら

リポジトリ:
github.com

PWA対応したゲーム:
s-h-gamelinks.github.io

おわりに

やってみて、GitHub Pagesを使うことで「開発しながらリリース処理もできるのでかなり良いんじゃないかなぁ」と思いました。
特にチームで開発してて、かつ皆Gitを使えるとかであればかなり恩恵はありそう(Issue管理とかやりやすそう)