コミュニティに元手を支払って参加するという話

TL;DL

  • 金払ってイベントやオフ会に参加するだけじゃなくて、もっと積極的に運営とかに携わっていこうよ!
  • イベントの運営も参加者もコミュニティの一員なんだしフラットにいこうよ!

以下、ポエム

Twitterを見てると、月に数回はどこかしらでオフ会やイベントがありますよね。 かくいう自分も、月に2回以上はイベントやオフ会に行ってます。 主にアニクラアイマス関連オフ会か、プログラミング系のイベントかですが…

さて、イベントがあれば必ずそこにはコミュニティが存在します。 オフ会だって立派なコミュニティと言えると思います。 サシ飲みならそれはただの1:1ですが、3人以上で飲むならその時点で小さいながらもコミュニティと呼べる何かが存在すると思いますし、 10人とかになってくると立派なコミュニティです。 その10人がネットで知り合った人となると、結構な規模のオフ会と言えると思います。 ちなみに、自分が今まで行ったことのあるオフ会で一番参加人数が多かったのは13人でした。

コミュニティと何度も書きましたが、ここでちょっと意味を整理します。 https://dictionary.cambridge.orgでcommunityの意味を調べると、

the people living in one particular area or people who are considered as a unit because of their common interests, social group, or nationality

(勝手に意訳: 共通の嗜好や社会的背景から、ある一つの団体として扱われる人々)

と出てきました( community Meaning in the Cambridge English Dictionary ) ここでいう共通の嗜好や社会的背景は、自分の場合、アニソン好きだったりアイマスPだったりプログラマーだったりします。 つまり、(当たり前ですが)ここで言うコミュニティとは共通の嗜好を持った集団という意味ですね。 なので、営利目的の催しを中心として成り立つ集団はここで言うコミュニティとは違うので、このお話では全く無関係です。

コミュニティで何か楽しいことをしよう!となった時に、必ず資本が必要となります。 それは例えばお金という分かりやすいものかもしれませんし、例えば事前準備という労働力かもしれませんが、 なんにせよ何らかの資本が必要です。(元手なしに楽しいことできるのが一番ですけど、なかなか難しい) そして、そんな資本をもとに作られたコミュニティに参加するには、やはり何かしらを支払わなければなりません。 フリーライダーはだめですよね。

運営の方々や幹事さんは事前準備という形で労働力を元手にコミュニティに参加し、 それに対していわゆる参加者は主にお金を元手にコミュニティに参加します。 それらの元手をコミュニティに対して提供することで、楽しい時間をコミュニティから受け取ることが出来ます。 普通のイベントやオフ会は大体こんな感じですよね。

ここまでざっと書いてきたわけですが、要はコミュニティに参加するための元手はお金だけじゃないわけです。 運営や幹事(=労働力)が足りてないなら積極的に運営や幹事サイドに参加すべきですし、 さらに言うと運営や幹事と呼ばれる人たちはお金の代わりに労働力をコミュニティに提供しているだけで、 運営側と参加者側は、コミュニティに提供している元手の種類が違うだけで、そこに上下関係は存在しないと思ってます。

共通の趣味や嗜好のもとに集っただけでそこには上下関係はなく、形は違えどコミュニティに貢献した上で同じ楽しい時間を過ごしているだけ。 そんな楽しい時間や環境も、お金だけでなく時間と労力を提供してくれる人がいないと続かないですし、 せっかく好きなことで集まったんだから、ひりついた環境よりはみんなで楽しく遊んだり騒いだりしたいですよね。 ふと、そんなことを思いました。

輝きの向こう側から見えたもの 〜アイドルマスターシリーズ作品の楽曲の歌詞を解析〜

アイドルマスターシリーズは旧ナムコ(現バンダイナムコ)のアーケードゲームTHE IDOLM@STER』を元とする、一連のアイドル育成ゲーム又はメディアミックスシリーズの総称です
2005年から続いており、昨今の二次元アイドルブームの大元とも言える、10年以上続くロングセラータイトルです

普通の女の子/男の子たちが、プロデューサー(プレイヤー=あなたであり、同時に作中キャラクターでもある)のプロデュースによってステージで輝く存在に変わる
この過程で出会う仲間とライバル、成長と葛藤、そしてその先にある夢、目標
アイドルマスターの魅力はそこにあると、個人的に思っています

まぁこの記事を見ている人はそれくらい常識(?)と思いますが、自分はそんなアイドルマスターシリーズが大好きです
アニメ版アイドルマスター(いわゆるアニマス)と劇場版アイドルマスター(いわゆるムビマス)からプロデューサーを名乗らせてもらっています

そんな自分ですが、つい先日こんな記事を見つけました
プリパラは3年9か月、何を歌ってきたのか?~テキストマイニングによる分析~

この記事を読み、その深さと面白さに強い衝撃を受けました

普段何気なく聞いている曲の歌詞の中から「何を謳っているのか」「何を伝えたいのか」
それらを束ねて、そのシリーズは一体どんなストーリーを歌っているのかという情報をデータから数理的に拾う

「これは、アイマスPとしても情報を学ぶ学生としても、やらないといけない」
そう思い、アイドルマスターシリーズの楽曲の歌詞の解析を行うことにしました

なお、筆者は自然言語処理に関してはほぼ素人です(大学で少し触った程度)
ですので、一部不適切な処理/説明をしていることもあると思います
もしおかしな点があれば、ぜひコメントやGitHubのIssue(後述)で知らせてもらえると嬉しいです

以下、技術的な話が続きます
興味のない方は解析結果までジャンプしてください

前段階 (歌詞を集める)

まずは歌詞を集めないといけません

さいわい、上で紹介した記事に歌詞の集め方が載っていました

大量の歌詞を一度にテキスト化して保存する方法。

これを参考に、

の5つのシリーズと、
765AS、ミリオン組の全キャラクターとシンデレラで声が付いているキャラクター全員分の歌手検索を行い、ヒットした曲を全て取り込みました

しかし、一部キャラクターは検索がとてもむずかしかったので、手動でピックアップしています

  • ロコ(ミリオンライブ)
    • 伴田路子では当然ヒットしない
    • しかし、ロコだけだと無関係のものまでヒットする
    • 仕方がないので、『STEREOPHONIC ISOTONIC』と『IMPRESSION→LOCOMOTION!』(2曲ともロコのシングル)のみ抽出
  • ジュリア
    • 「ジュリア」だけだと、Juliaまでヒットして洋楽がたくさん入ってくる
    • 仕方ないので、『流星群』『プラリネ』『スタートリップ』(3曲ともジュリアのシングル)のみ抽出
  • 菊池真
    • なぜか菊池桃子さんの曲もヒットする
    • とはいえ、真が歌う曲はそこそこ多い(カバー曲含め、カバー曲に関しては後述)
    • 仕方ないので、手動で「singer:菊池真」となっている曲のみ抽出

また、カバー曲の扱いについてとても悩みました

  • カバー曲を弾くのは難しい
    • 歌手欄はアイマスオリジナル曲と一緒
    • 作詞/作曲で弾こうにも、種類が多すぎて無理
    • そもそも、自分自身が全てのアイマス関連曲を追いきれてないのでよく分からないところが多々ある
    • カバー曲はそのキャラクター自身と無関係ではない
      • 千早の『Shangri-La
      • 真の『アンバランスなKissをして』
      • 卯月の『気まぐれロマンティック』
      • などなど...

以上の理由から、カバー曲も含めています

他、「to D@nce to」等のremixシリーズや、『約束』『約束(TV ver)』『約束(M@ster Version)』等は全て一つの曲として手動で整理しました

結果、合計765曲(偶然)のデータをソースに解析を行いました

解析に使用したもの

自分はプログラムをある程度書けるので、Rubyでコードを書きました
ちなみに、上で引用した記事ではフリーソフトを使っているようです

ライブラリとして、CaboChaMeCabを使用しました
(MeCabはCaboCha内部で使用されている)

Rubyラッパーとして、cabocha-rubyを使用

コードはGitHubに上げました

github.com

  • word_type_analysis.rbは、特定の品詞の単語のみを抽出する処理
  • link_to_from.rbは、特定の単語と係り受け関係のある単語を抽出する処理
  • sort.rbは、上の2つの処理の出力結果を頻度順にソートして、末尾に合計を出力する処理

となっています

解析した結果はresultフォルダ以下に置いてあります

「こんなふうに解析したんだ―」って雰囲気が伝わればいいな

解析の結果、見えてきたもの

まず、どんな単語がよく出てくるのか(type_analysis.rb)を解析した結果

名詞

結果

「私」「あなた」「みんな」といったワードや、「夢」「心」「未来」「世界」といったアイドルマスターシリーズ特有とも言えるワードが上位に入っています
他には「男気」というワードが結構出ていたりと、なかなかおもしろい結果となっています

また、頻度上位の単語だけでなく、下位の方の数回しか出ていない単語を見ていると

  • シロツメクサ
  • 秩序、理論、不可思議
  • ホップステップジャンピング
  • ラブラブジュテーム
  • ア・ン・キ・モ
  • ブレイズアップ
  • コレガニッポンノハルデス
  • グリモワール
  • デネブ、アルタイル、ベガ
  • ジェットマシーン
  • イルミルミルミ
  • ストロベリー・キユーピッド
  • ウサミンキュンキュン
  • 錬金術、He、Li、F、Ne、Mg、Al、Si、Cl、Ar、Ca
  • カーテンコール

といった「あ、これはあの曲だな!」という単語がいくつかあって面白いです

動詞

結果

今度は動詞です

「する」「なる」「いる」「ある」といった単語が圧倒的多数出ていますが、これは仕方ないとして、 「見る」「知る」という知覚系の動詞2つがトップに並んでいます

また、「輝く」「信じる」「変わる」「なれる」「夢見る」「踏み出す」「憧れる」「つかむ」あたりは、アイドルマスター特有の『成長、夢、目標』と関連がありそうです
しかし、「迷う」「泣く」というワードもあるとおり、常に前向きではなく『壁にぶつかって悩み、時には立ち止まることもある』という面も見えてきます

また、頻度下位の単語も特定の歌を連想させる動詞がちらほら見え面白い結果となっています

形容詞

結果

次は形容詞です

これも「ない」「いい」というノイズ的な単語が2トップですが、その下に「強い」という単語に意外性を感じます
おそらく、「強く〜」という形でよく出てくるからでしょうか?

他には「楽しい」「優しい」というポジティブな単語が並んでいたり、「切ない」「怖い」「弱い」というネガティブな単語が並んでいます

また、「熱い」「恋しい」「愛しい」「欲しい」といった、情熱的な単語もいくつか上位に見えます

これらから、アイドルマスターには「切ない楽曲」「情熱的な楽曲」「楽しい楽曲」と幅広い層の曲があることが読みとれます

頻度下位の単語ですが、形容詞はあくまで「何かを飾る」「何かの状態を表す」という副次的要素が強いので、単一では特定の楽曲を連想しづらいと感じました

感動詞

結果

感動詞は「それ単体で独立している」「活用がなく、その単語単体で文になる」といった特徴を持ちます
歌詞の勢いをつけたり、単体でその曲の特徴とも言えるフレーズとなったりと、他の品詞とはまた違った扱い方をされることが多いです

そんな感嘆詞を見てみると「さぁ」「ほら」「ねぇ」といった話し言葉によく見られる単語が3トップで並んでいます

そして、その次に「ありがとう」
これはアイドルマスター特有の単語として現れていると思われます
実際に、上位5つ(「さあ」と「さぁ」は別でカウントされているため)を足し合わせると724となり、これは全歌詞中の感嘆詞(1467個)のほぼ半分を占めています
「ありがとう」という単語は、アイドルマスターではとても大切であると読みとれます

また、感嘆詞はその性質から特徴的なものが多いので、特定の曲を連想させる単語が多数見えます

  • 「メリークリスマス」って13回も出てるけど、クリスマス曲...?
  • 「Kiss」は9回、これもいくつかピンとくる曲がいくつかありますね
  • 「オー」は掛け声的なもの...?
  • 「嗚呼」はあえて「あぁ/ああ」と書かないあたり、これもいくつかピンと来る曲が...

感嘆詞だけに注目して考察してみても、いろんなことが連想できて面白いですね

係り受け解析

最後に、いくつか気になった単語に関して係り受け関係にある単語を抽出した結果をまとめました

resultフォルダ以下の「◯◯_link_analysis_result」というファイルが結果ファイルです

いくつかの単語について係り受け解析を行いましたが、その中でもいくつかをピックアップしたいと思います

輝く

結果

輝くという単語に対して、「世界」「場所」「ステージ」「キラキラ」「夢」といった単語が並んでいます

これはまさに「アイドルとして輝きたい」という願いそのものの現れであり、とてもアイドルマスターらしい傾向だと解釈できます

他には、「キラキラ」「星」「Shine」「照らす」といった「星/太陽/空」に関連して「輝く」という単語が出てくることが多いと読みとれます

結果

これは「私」「あたし」「自分」「僕」「俺」といった、自分に関する単語の係り受け関連を解析した結果です

結果のトップに「なる」「いる」「する」という単語が並んでいることから、 自分の意思で「何かになる」「何かをする」というフレーズや、「自分はここにいる」という存在を示すフレーズを連想できます

他には「信じる」「知る」「新しい」「なれる」といった自分を信じる自分(の可能性や新たな一面)を知る新しい自分自分は〜になれるという、非常に前向きなフレーズも連想できます

まさに「アイドルとして/人間としての成長を描く」、アイドルマスター特有のフレーズをたくさん連想することができますね

信じる

結果

一番上に「自分」という単語が来ていて、その次に「!(感嘆符)」が来ていることから、自分を(強く)信じるというフレーズが連想できます

他には「力」「絆」「届く」「ずっと」「道」「未来」「叶える」「明日」という、「信じる」と組み合わせるとポジティブで非常にアイドルマスターらしいフレーズを連想できる単語が並んでいます

まとめ、そしてこれからのアイドルマスター

いかがでしたでしょうか?

歌詞の解析を行うことで、普段はなんとなくでしか意識していなかったフレーズやテーマを、数理的に解析することでとても面白い結果が見えました
GitHubリポジトリも気が向いたら更新していくつもりです

「歌」という「輝き」の向こう側を解析して、そこから得られたデータはまさに、「アイドルマスターとは」という漠然とした問い対しての一つの解と言えます

アイドルは輝くステージ/世界の存在であり、そこに向かって努力し、時には悩み喧嘩し、それでも仲間や自分を信じ、精一杯に夢や希望に向かって進んでいく
アイドルマスターはまさに夢に向かって頑張るストーリーであり、その過程であり、だからこそ我々プロデューサーはアイドルマスターという一つの「お話」に惹かれるのかもしれません

Rancherを使ってWebからコンテナ管理をできるようにした感想

以前書いた記事の環境でサーバを管理してたんですが、さすがに1つのcomposeファイルで管理するのはきつくなってきました。 そこで、ちゃんとコンテナオーケストレーションができるツールを入れようと考えるようになりました。

有名なのはk8sですが、そもそも本格運用したい訳ではなくて、単に「簡単に管理がしたい」という点で、rancher-serverからブラウザで管理ができるRancherを使うことに決定。

Rancher(日本語)

Rancherの動かし方等はggったら出てくるので、実際に動かしてどんな風に感じたかを書くことにします。 (なお、個人の趣味的なサーバなので、仕事で実際にやるのとは違います)

ざっくりとした感想

とにかく楽ができます。

  • ブラウザからポチポチして操作できる(これはRancherというより、rancher-serverの機能)
  • 土日にアクセスが少し集中する時間帯等に、スマホのブラウザからポチポチするだけでいい感じにスケールしてくれる
    • 個人の趣味でやってるサーバなのでやってないですが、複数ホスト間でいい感じにスケールしたりできるみたいです
  • コミュニティの方が用意してくれているテンプレート等があるので、そこからgitlabやlet's encryptなんかをすぐに展開できる

ちょっと不満な点

rancherのイメージがなかなかでかい

  • rancher-serverとrancher-hostを動かすだけで、アイドル時1Gくらいのメモリを持っていかれる
    • 個人運用のサーバはこれが致命的(今回のサーバはそもそも2Gしかメモリがない)
  • Rancher組み込みのLBに柔軟性がない
    • SSL周り等を簡略化できるけど、HTTP/2に対応してなかったり、LBだけでリダイレクトできなかったりと機能不足と感じた
  • 情報が(k8sとかと比べて)少ない
    • あっても英語(ここでモチベと気力が結構持ってかれる)

まとめ

こまごましたところで不満は感じますが、それと引き換えに圧倒的に楽ができるというイメージです。

メモリに関しては、仕事ならそんなに気にならないと思いますが、個人でやってる身からすれば死活問題です。 もっとも、そもそも2Gというのがなかなかつらいので、そろそろ一つ上の4Gコースに変えようかなぁ...

GMT、UTC、UnixTimeって何が違うの?

この世界には時間が流れています

過ぎ去った過去は戻ってきませんし、すべての存在に等しく時は流れます

人の叡智は、そんな偉大で悠久の時をほぼ正確に刻む術を手に入れました。(水晶とか、原子とか、素粒子とか、光とか)

時のズレを検知して、地球上どこでも位置を測定することができるGPSは、時計測技術の極致とも言えます

時差

前置きはおいておいて...

この地球は時差が存在します

つまり、日本で朝9時でも、英国では真夜中の0時だったり…

要するに、日本で23時としても、英国ではアフタヌーンティーの真っ最中だったりする訳です

(グリニッジ標準時日本標準時から-9時間)

高度なリアルタイム通信網が地球全土を埋め尽くしている昨今、この時差はとても面倒です

なにせ、オンラインミーティングを15時からしようと決めていたのに、サンディエゴの同僚に電話したら「今何時だと思ってるんだ!」と、トラブルが起きるでしょう

(アメリカ太平洋標準時は日本標準時から-17時間)

それでは困るので、世界で統一的な基準となる時間という決まりが存在します

GMT

歴史的に海洋帝国として栄えていた大英帝国は、18世紀からその国内法でグリニッジ天文台で太陽が南中する時刻を基準として標準時として扱う」と定められており、船乗りたちはそれをもとに生活をしていました

(流石に遠隔地では現地時間に合わせた生活をしていたようですが)

19世紀末には、電信等を使用する際の標準時として、グリニッジ標準時を基準として扱うことが国際的に決定します

つまり、

GMT = 「グリニッジ天文台で太陽が南中する時刻を基準にした時間」

と言えます

UTC

さて、それから技術は更に進歩し、原子にマイクロ波を浴びせたときに生じる振動を利用したり、光の波動によって作成された格子の中に原子を閉じ込めたりすることによって生じる振動などを利用したり、光の速度は常に一定という定理から「光が進む距離」を利用したりするなど、今では1京分の1秒の精度で時を測ることが可能になりました。

「じゃあ、それらを世界の時間の基準にすれば...」

確かに、微妙に観測しづらい南中時間より圧倒的に正確なんですが、少し困ったことに、地球の時点速度は地殻変動潮汐力によって変動します

つまり、地球における1日という時間は、実は毎日微妙に違うという困ったことが分かってきました。

(実際に、大規模な地震で自転軸がずれて1日の長さが変わったり潮汐力によって潮の満ち引きが起こることは有名です)

「これでは困る…けど、原子時計の正確さも欲しい…」

ということで、セシウム原子を利用した原子時計を基準として、自転速度の変動によって起こる実際の南中時刻とのズレを、うるう秒を挿入することにより誤差±0.9秒以内に保つ」という決まりのもと協定世界時(UTC)が決められました

UnixTime

GMTUTCは時刻ですが、一方でUnixTimeはコンピューター内部での時刻表現の一種です

現在ではコンピュータは必要不可欠で、コンピュータのない世界はもう想像できません

今日広く普及しているオペレーションシステムは、大体はUnixというオペレーションシステムの影響をとても強く受けています

このUnixは1970年頃に世に広く普及したのですが、Unix内部では協定世界時の1970年1月1日0時0分0秒からの累計秒」で現在の時刻を保持する仕組みになっていて、これがUnixTime(または、Unix Epoch)と呼ばれる時刻表現の一種の決まりになっています

ここで重要なのが「協定世界時の」1970年1月1日0時0分0秒からの累計秒であるという点で、うるう秒等が差し込まれるとうるう秒の間だけUnixTimeの1秒は世界協定時の2秒になるという点

つまり、1998年の大晦日に差し込まれたうるう秒を例に上げると

世界協定時 1998年12月31日 23:59:59 → UnixTime 915148799

世界協定時 1998年12月31日 23:59:60 → UnixTime 915148800

世界協定時 1999年01月01日 00:00:00 → UnixTime 915148800

世界協定時 1999年01月01日 00:00:01 → UnixTime 915148801

ということになります

※UnixTimeはUTCGMTと違い、条約や協定は存在しないため、システムによって実装が異なります

まとめ

時という一見計測しにくいものを、凄まじい精度で計測できるって、人間はすごい

白衣サーバーの構成

自分は白衣サーバというサーバーをConoHa VPS上で持ってますが、その構成についてちょっとメモ

スペック等

  • ConoHa VPSの2Gコース(2,000円/月くらい)のプラン
  • Fedora25
  • ミドルウェア等は基本的にDocker Composeでまとめて設定/管理

docker-composer.yml

version: "2"
services:
        nginx:
                image: nginx:alpine
                container_name: nginx
                ports:
                        - "80:80"
                        - "443:443"
                volumes:
                        - "/home/kiridaruma/http/:/web/"
                        - "./nginx/nginx.conf:/etc/nginx/nginx.conf"
                        - "./nginx/conf.d/:/etc/nginx/conf.d"
                        - "/etc/letsencrypt/:/cert/"
                links:
                        - php-fpm
                        - git
                        - bcdice-api
                restart: always

        php-fpm:
                image: php:7.1-fpm
                container_name: php-fpm
                volumes:
                        - "/home/kiridaruma/http/:/web/"
                        - "./php-fpm/php.ini:/usr/local/etc/php/php.ini"
                        - "./php-fpm/www.conf:/etc/php-fpm.d/www.conf"
                links:
                        - db
                restart: always

        db:
                image: postgres:alpine
                container_name: postgres
                volumes:
                        - "./postgres/:/var/lib/postgresql/data"
                ports:
                        - "5432:5432"
                environment:
                        POSTGRES_PASSWORD: SECRET_PASSWORD
                restart: always

        git:
                image: gitea/gitea
                container_name: git
                volumes:
                        - "./git/:/data/"
                restart: always

        bcdice-api:
                image: ruby
                container_name: bcdice-api
                volumes:
                        - "/home/kiridaruma/http/bcdice-api/:/bcdice-api/"
                restart: always
                working_dir: "/bcdice-api/"
                command: sh -c "bundle install && bundle exec rackup"
                environment:
                        - RACK_ENV=release

各コンテナごとメモ

どうコンテナを組み合わせるのが良いのかは試行錯誤している最中なのでまだわからない。 ただ、今の所この構成が一番しっくりくる。

ミドルウェアのconfig等はdocker-compose.ymlの直下に専用のフォルダを作って、それをvolumesでマウントさせるようにしいてる。

全体的なポイントとして、イメージはできる限り軽量なもの(alpine版など)を選ぶようにしている。

versionはよくわからない。 3まであるらしいけど、バージョンが上がると何が変わるんだろう? とりあえず、今は2を使っている。

あと、restart: alwaysは大事。 (dnf updateを自動でする設定にしていて、Dockerの更新がかかって1週間ほどサーバが止まってたことがある)

Nginx

HTTPサーバ周りの軸になっている。 そのため、linksvolumesがちょっと肥大化しつつある。(もうちょっとスッキリさせたいけど、仕方ないのかなと思いつつある)

他に特徴的なことといえば、TLS証明書はLet's Encryptで発行しているのでvolumesにその設定が入ってるくらい...?

PHP-FPM

本当はunixドメインソケットでNginxとのやり取りをさせたかったけど、何故かうまく動かない(おそらく、ソケットファイルの権限の問題)ので仕方なくtcpでやっている。 なんでも、unixドメインソケットのほうが効率が良いらしい。

ただ、各コンテナごとに環境が独立しているのでポート番号重複は全く考えなくて良いので少し楽。

DB(PostgreSQL)

自分はMySQL(MariaDB)しか使ったことがなかったけど、色々便利な機能が入ってるのでPostgreSQLにした。

今のところは使ってないけど、今後いろいろやる予定なので、それを見越して追加。

Git(Gitea)

外に出すのはマズイようなプロジェクト用。 個人でプライベートなGit(Githubライクな)サーバを持ってると、なかなか便利。

Gitサーバは

  • バイナリファイル1つですぐ動かせるもの
  • DBが必要ないもの
  • 動作が軽めのもの

を考えて、GogsGiteaか迷ったけど、Giteaを採用。

正直GogsとGiteaはほとんど同じだけど、何故かGiteaに(理由は覚えてない)。

BCDice-API(Ruby)

BCDice-APIは、TRPG用ダイスロールプログラム(ライブラリ)のBone&CarsをWebAPIとして動くようにしたもので、自分が開発しているOnset!用に使用している。

BCDice-APIRuby製でSinatraで動いているみたい。

もともとimageはalpine版のRubyで動かそうとしていたが、bundle installでライブラリが足りなくてコケたので通常版(おそらくDebian)を使用。

ポートは9292で動いてるけど、どこで変えられるのか分からない。 とりあえず支障がないので9292で動かしている。

全体的なまとめ

Dockerは各コンテナごとに独立した環境があるのと、yamlでサーバの構成を書けるのでとても簡単で楽しい。

試行錯誤するときも、さっと試して動かなかったりエラーが出たりしたら直ぐに修正できるのもすごく楽。

ただ、journaldに大量のログが吐かれるので、そこでリソースを結構食われている。 逆に言うと、それ以外はそこまでリソースを食ってない。 メモリ2GBのサーバとしては結構うまく回せていると思う。

今後の改善点として

  • 細々とした謎挙動の解決(unixドメインでNginxとPHP-FPMが繋がらない、BCDice-APIのポート設定等)
  • 省メモリ化(各種configの調整)
  • DockerやDocker-Composeの理解

を頑張りたいなぁと思っている。

このサーバーは仕事とかではなく、単純に趣味なので落ちても問題ないし挑戦できるのでとても楽しい。 メモリ2GBでこれだけやれるし、少ないメモリでいかに回すかを考えると結構面白い。

あなたも、VPSでサーバーを建てたいときはConoHaでどうですか?

ConoHa VPS

ブログ移設について

今まで自前でWordpressを使ってブログをやってました。 が、サーバの移行をした際に何かが起こったらしく、ログインできなくなりました。 ということで、はてなブログに移行しました。

どうしてはてなブログ

という「なんとなく」で決めました。

実際に蓋を開けてみると、

というオチでした。

Wordpressになぜログインできなくなったか

もともと、WordpressSQLite Integration というものを使用して、MySQLでなくSQLiteで稼働させてました。

ところが、サーバ移行(VPSのOS変更とDocker環境への移行)の際にSQLiteプラグインの設定が壊れたらしく、DBエラーでログインできなくなりました。 コードを読んでもよくわからず、ggっても特に何もわからない(というか特殊ケースすぎて情報が出てこない)ので、思い切ってはてなブログに移行しました。

一応、ブログのシステムを自作しようとは考えたんですが、面倒なんで断念 (nodeでkoaを使ってゴニョゴニョしようと考えていた)

今後

今思えば、前のブログはほとんど更新してなかったなぁと思いつつ、

  • Qiitaでは技術的なこと
  • はてなではその他のいろんなこと
  • Twitterでは日常のどうでも良いこと

を書いて行こうかなと思ってます。