皆さんごきげんよう、KMC7回生のKMCid:tronです。学生でなくなってしまいました。
さて、本日5月5日よりBoothにて音楽作品集「KMC Music Collection Vol.5」の販売を開始しました。
試聴は上記販売ページ、および以下の試聴動画より可能です。
収録曲には歌詞がついているものもあります。歌詞は付属のPDFでご確認ください。
KMCではパソコンで何かしたい人々を常時募集しています！！個人的にはDTMに興味がある人を特に募集したいです！！！ (※もちろんDTM以外に興味のある人や現在特に何か興味があるわけではない人も歓迎します！！) www.kmc.gr.jp
おはもに～。
id:utgwkk です。最近の京都は夏のような日もあって、計算機にはつらい季節になりつつありますね。
今日は、部員向けWebサービスを部内Kubernetes (以下、k8s) クラスタに移設した話をします。
KMCでは、サークルの部内サーバーでk8sクラスタを運用しています。KMCの部員であれば誰でも自由にアプリケーションをk8sクラスタ上で稼動させることができます。k8sクラスタを構築した経緯や技術的な詳細については、以下の記事をごらんください。
今回移設したWebサービスは、部員向けのイラスト投稿サービス (通称 God Illust Uploader、以下では神ロダと呼びます) です。KMCでは毎年お絵描きプロジェクトという勉強会・練習会を開催しており、課題を提出する場所や、描いたイラストを部員向けにアピールしたりする場所として神ロダが使われています。
移設前の神ロダの構成は以下のようになっています。
全てのソースコードやデータベースは部内のNFS上に設置されており、nginxとPassengerを経由してアプリケーションにリクエストが届く、という構成になっていました。また、部員だけが閲覧できるように前段には部内共通の認証機構が設置されていました*1。
モデルの関係は以下のようになっています。ありていに言えば簡単なpixivみたいなイメージです。
神ロダはしばらく前節のような構成で稼動していましたが、いくつかの課題を抱えていました。
神ロダの以前のデプロイ方法は以下のような流れでした。
git pull するこのうち最後の手順は make コマンドだけで完結するようにしてありますが、それでも自動化がされておらず手間でした。今からCapistranoに入門するのか？ できることならmainブランチの変更を自動でデプロイしてほしい！ と思いつつ月日が過ぎていきます。
言語処理系 (Python) のバージョンを上げるにあたって考慮すべきことがいろいろあります。
以下のような手順書を書いてバージョンアップを実施しましたが、やることが多い!! 異なるバージョンの依存ライブラリをそのまま使えるとは限らないのでvirtualenvを作りなおす必要があるとか、なぜかpoetryが壊れていたので直す*2とか、単にアップデートするだけでは終わらないのが大変です。また、この方法だとダウンタイムが出てしまうので、深夜にこっそりバージョンアップ作業をやっていました。
コンテナ化していたら、言語処理系のバージョンを上げるのはbase imageのtagを書き換えてデプロイするだけで*3完了するはずです。
ここでの依存モジュールとはPythonのライブラリのことではなく、imagemagickやWebP、ネイティブの依存ライブラリなどを指しています。言語処理系のバージョンもとくに管理していない*4ので、ちょっと sudo apt upgrade をかけたら壊れてた、ということもあるかもしれません。半分ぐらいは構成管理をサボっていただけなのですが……。
SQLiteは、MySQLやPostgreSQLなどのRDBMSに比べるとスキーマ変更の制約が強いです。具体的には、インデックスや外部キー制約を追加したあとに ALTER TABLE 句で削除することができません*5。単純な ALTER TABLE 句では実現できないスキーマ変更を反映するには、一度テーブルをコピーして作り直す必要があります。
使っているO/Rマッパー (SQLAlchemy) はSQLite向けのバッチでのマイグレーションに対応していますが、考慮することが増えるのでできるだけシンプルに済ませたいです。部内サービスだから気楽にやってよいはずなのですが、DBスキーマのリファクタリングが気軽にできないとなると困ります。
ここまで述べた課題を抱えつつ神ロダを開発・運用していたのですが、ある日やっていきが発生したので、やっていくことにしました。
まずは移行作戦について考えていきます。
何はともあれ、アプリケーションサーバーが動くDockerイメージがないとk8sクラスタにデプロイできません。したがってDockerfileを書く必要があります。
データベースはこの機にMySQLに移行できるとよいと考えましたが、いったんNFS上のSQLiteのデータベースファイルをマウントした状態で移行して、後からMySQLに差し替える作戦を取りました。一気にいろいろやると切り分けが困難になるので、区切りをつけてからやっていきます。
フロントエンドはいったんNFS上にデプロイする方針で考えていました。ただし後述するように、結局フロントエンド用のDockerイメージを用意する方針に切り替えることになります。振り返ってみると、NFS上にデプロイするためのスクリプトを整える必要がある・フロントエンド用のDockerfileを書くのとどちらが手間か・自動化しやすいか、という点ではDockerイメージを作る方針でよかったと思っています。
まずはアプリケーションが動くDockerfileを用意しました。これはそんなに難しいこともなく、淡々とDockerfileを書いて調整する、を繰り返すだけです。あわせて、Docker Composeを使ってアプリケーションを1コマンドで立ち上げられるように調整しました。
この時点ではアプリケーションサーバーだけなので単なるコマンドラッパーのような感じでしたが、MySQL化するにあたって環境構築をやりやすくしておくのがよいと考えてサクッとやりました。また、早いうちからDocker上で動くアプリケーションを用意しておくことで、Docker環境と手元環境との差異を潰していくことができます。
アプリケーションの設定 (DSNやシークレットなど) は元から環境変数で差し込めるようにしていたので、とくに手間にはなりませんでした。
Dockerfileができたので、ビルドパイプラインを整えていきましょう。GitHub Actionsでのdocker buildにはdocker/build-push-actionを使うのが便利です。push先のコンテナレジストリはGitHub Container Registryを使っています。
Dockerイメージのタグは、FluxCDのImage Update Automationとの兼ね合いから {commit hash}-{ビルド日時} という形式にしています。commitにバージョンのタグを付けたときだけビルドする、という方式も取れますが、そんなにセマンティックにやらなくてもよかろう、ということで楽な方法に倒しました。
- name: Extract metadata (tags, labels) for Docker id: meta uses: docker/metadata-action@v3.6.2 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} tags: | type=raw,value={{sha}}-{{date 'YYYYMMDDHHmmss'}}
アプリケーションサーバーのDockerイメージができたので、デプロイを試せるようになりました。ここからk8s (kustomize) のYAMLをゴリゴリ書いていくことになります。
k8sの公式ドキュメントや部内wikiにYAMLの例があるのですが、イチから書くのは初めてなのでかなり 
id:nonylene さんにレビューしてもらいながらYAMLを整えていきました。最初はお試し用のnamespaceで作って、あとからdefault namespaceに移動する方針にしました。
kustomize自体はk8sのYAMLを生成するツールという感じで、生成されたYAMLが妥当かどうかはデプロイしてみないと分からない場合も多く、何度か書き直してはデプロイし直す、を繰り返しました。id:nonylene さんにk8s-lintというlinterを導入してもらってからは前もってエラーに気づきやすくなったと思います。
こうして試行錯誤して、いろいろなエラーを読み解きまくって、ついにアプリケーションサーバーをk8sクラスタ上にデプロイすることができました。よかったですね。
次はMySQL移行をやっていきます。
手元の開発環境をDocker化してdocker-compose.ymlを書いてあるので、開発環境にDBを追加するのは一瞬です。アプリケーションの実装を精査して、MySQLに移行できるように修正していきます。意図せず自分自身のカラムに外部キー制約を貼ってある*6のを発見して直す、などの地道な活動が行われました……。
いよいよMySQL化の準備ができたので、SQLiteのデータをdumpしてMySQL向けに修正したあと流し込んでいきます。移行手順は SQLite3のデータをdumpしてMySQLに移行する - Qiita を参考にしました。
実際にデータを流し込んでみると、いくつかのタグがユニーク制約違反でINSERTできませんでした。SQLiteでは COLLATION nocase (大文字小文字を区別しない) になっていたカラムが、MySQLでは COLLATION utf8mb4_0900_ai_ci になっており、記号などより多くの文字列の大文字小文字が同一視されるようになっていたためです。ところで「パパ」と「ハハ」が同一視されるのはどう考えてもおかしいと思うのですが、我々はMySQL上で大文字小文字とどのように向き合えばいいのか……。
INSERTできなかったデータは数件だったので、目視確認して既存の別のタグに貼り替えるなどの対応を行いました。
MySQLをk8sクラスタ上にデプロイしたあと、安全のためにk8s上のMySQLからバックアップ (mysqldump) をNFS上に保存するCronJobを書きました。crontab的なものもk8sにあって便利ですね。試運転してみて確かにバックアップができていることを見届けました。
ところで MYSQL_PASSWORD 環境変数の値はsecretに入っており、かつ同じ値をアプリケーションサーバーとDBで流用することを考えました。が、アプリケーションサーバーではDBの接続先をURL形式で指定する必要があるので MYSQL_PASSWORD 環境変数のままだと都合がよくありません。以下のように環境変数を設定してexecするラッパースクリプトを用意しました。
#!/bin/sh
set -e
export DB_URL=mysql+mysqlconnector://${MYSQL_USER}:${MYSQL_PASSWORD}@${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}
exec "$@"
他の環境変数をもとに環境変数の値を組み立ててセットする、みたいな機能があるとよいのですが、あるんでしょうか？ 誰か教えてください。
お試し用のnamespaceにひと通りデプロイできたので、default namespaceに移動します。基本的にはnamespaceを変えて回ればよいはず……と思ったらSealedSecretが復元できなくなってハマりました。
しばらく悩んでいたのですが、これはSealedSecretのスコープがkustomizeのnamePrefixを考慮したものになっていなかった*7のが原因でした。スコープを namespace-wide に変えたら復元できるようになりました。
namespaceを移動したことでMySQL向けのPersistent Volumeが作り直されてしまい、データがまっさらになりましたが、前段階でDBのバックアップを取っていたのでそれを流し込むだけで済みました。バックアップって便利ですね。
当初はフロントエンドをNFS上にデプロイすることを考えていましたが、ここまでくると全部Docker化してしまうとシンプルになるのでは？？ ということでやりました。
神ロダのフロントエンドはシングルページアプリケーションなので、nginxイメージにnginx.confを書いて、フロントエンドのビルド成果物をCOPYして配信すればOKでした。アプリケーションサーバーに比べるとかなりシンプルに済みました。
GitHub ActionsでDockerイメージをビルドする環境を整えたついでに、テストも走らせるようにしました。PRに対してテストが自動で走ると安心感が段違いですね。
docker-compose.ymlを用意しているのでCIでもそのまま使えばよい気もしますが、せっかくなのでGitHub Actions側にDB用のコンテナを用意します。GitHub Actionsのワークフローで使い捨てのMySQLを利用する（サービスコンテナ） | のりおが思考停止するブログ にあるような手順で用意すればよいですが、コンテナの準備完了を待たずにテストの直前でwait-for-it.shを走らせることで投機実行感を高めました。
このようにして部内k8sクラスタに部員向けWebサービスを移設し、ついでに開発環境やCI/CDパイプラインを整えることができました。部員向けWebサービスとしては初めてのk8s移行だったので、いろいろ調べたり教えてもらったり、足りない設定を整備していったりしつつの作業でなかなか大変でしたが、完成してgit pushするだけで全てがデプロイされる体験はライフチェンジングでした。
また、アプリケーションをコンテナ環境でも動くように実装を修正したり、異なるRDBMS間でデータを移行したりするのはたぶん初めてのことだったので、いろいろ罠を踏み抜くことができたのはよかったと思います。
KMCでは、部内k8sクラスタに部員向けサービスをデプロイしたい部員の方を募集しています。また、今年の新入生プロジェクトにはWebサービスの作り方を学べる勉強会があるようです。気になりますね～。
興味のある方は、以下の入部案内を参考にメールやTwitterのDMなどでいつでもご連絡ください。お待ちしております！
はむはー！最近計算機には嬉しい気温になってきました。みなさん計算機はいかがお過ごしですか？
先月 Kubernetes クラスタを部内サーバーに構築したので、その話をします。
きっかけは部内 OpenStack クラスタが崩壊したことです。OpenStack かぁ〜立て直すのめんどくさいね〜、って話しているうちに何故か Kubernetes を立てる話が盛り上がり、Kubernetes クラスタを立てることになりました *1。
Kubernetes を立てると一言で言っても、 Node の立て方や使うコンポーネント、YAML の管理方法など決めなければいけないことは多岐に渡ります。
まずは要検討事項をまとめた Issue を作りました。
大量です。ここから一つ一つ検討していきました。
Node を立てる、すなわち kubelet のインストールをどうするか、という問題です。
kubelet を自分で入れて Hard way する（腕力派）、kubeadm を使う（公式ドキュメント派）、Rancher を使う（マネージド派）、OpenShift を使う（赤帽派）がありましたが、机上で検討した結果 kubeadm を使うことにしました*2。
Kubernetes では YAML を使ってリソースの定義を行いますが、その定義を何のツールを使って行うか、またどのようにデプロイするかを考える必要があります。
Kustomize と cdk8s を検討し、Kustomize にしました。
Kustomize を使って構築していると色々機能が欲しくなって高い表現力を持つ cdk8s に手を出してみたのですが、cdk8s は
といったデメリットがあり、シンプルな Kustomize で我慢やっていくことにしました*3。
なお、ingress-nginx など Helm で入れれるものは後述の GitOps ツールを通じて Helm でインストールしています。
レポジトリから実際のクラスタにデプロイする GitOps ツールとして、 FluxCD と ArgoCD を検討しました。
実際に使ってみた結果、FluxCD は全ての設定を Kubernetes Object として管理できて筋が良いこと、また ArgoCD よりもコンポーネントが少なく軽量で分かりやすいことから FluxCD を使うことにしました。
多人数で Kubernetes クラスタを触るので、ユーザー管理は必須です。KMC では部員一人一人に UNIX アカウントが発行されているので、それと連携できるようにしました。
Kubernetes には OIDC を通じて認証を行うことができる機能があります。部内に OIDC provider として dex を立ててバックエンドを部内の LDAP に向けるようにし、Kubernetes と連携しました。各々の kubectl が JWT を取得するための設定には kube-login を使っています。
Kubernetes 上の Event の通知には kubernetes-event-exporter を使っています。柔軟な通知のフィルタリングやルーティングができること、また投稿する JSON も自分で設定できることが Good point でした。
下のような設定で Slack に投稿しています。全て手書き！
receivers: - name: "slack" webhook: endpoint: "${SLACK_WEBHOOK_URL}" layout: channel: "#sysop" attachments: # Type is either Normal or Warning - color: '{{ if eq .Type "Normal" }}#326ce5{{ else }}#f4bd0b{{ end }}' blocks: - type: section text: type: mrkdwn # *[{Kind}] {namespace}/{resource}*\n{message} text: "*{{ with .InvolvedObject.Kind }}[{{ . }}] {{ end }}{{ .Namespace }}{{ with .InvolvedObject.Name }}/{{ . }}{{ end }}*\n{{ .Message }}" - type: context elements: - type: mrkdwn text: "*Type:* {{ .Type }} " - type: mrkdwn text: "*Reason:* {{ .Reason }}" - type: mrkdwn text: "*Count:* {{ .Count }}"
多くのクラウドでは Persistent Volume としてブロックストレージが提供されますが、部内サーバーにはそのような環境はありません。ただ、そのために Rook・Ceph といった分散ストレージシステムを管理するのは大変で、もっと気軽な選択肢を探すことになりました。
NFS を Persistent Volume として使うのも、オンプレミス環境ではよく聞きます。KMC にも NFS サーバーがあるので検討しましたが、KMC の NFS は HDD で構成されており読み書きが遅かったり、MySQL といった大量に fs に読み書きするプログラムで NFS を使うのはなぁ…となったりでイマイチでした。
そこで、Node に直接 Persitent Volume を置くようなシンプルなものを探した結果、TopoLVM を使うことにしました*4。TopoLVM は Node 上で Logical Volume を切り出し、それを Persistent Volume として提供してくれるものです。本当にシンプルな Logical Volume なので、何が起こっているか分かりやすく、管理もしやすい！
Node 間の Persistent Volume の移動が面倒*5ですが、Node の置き換えはそう起こらないということもあり、妥協することにしました。軽い読み書きやバックアップには既存の NFS を使ってもらうようにしています。
この他にも約2ヶ月に渡る様々な検討と構築を経て、クラウドと比べても不便なく使えるような Kubernetes クラスタを立てることができました :tada:。今の所 Node の突然死といったトラブルもなく平穏に動いています。
コンテナをバンバン立てたい・部内 Kubernetes クラスタを管理したい方はぜひ KMC に入部してください。ばいきゅー！
皆さんごきげんよう、KMC6回生のKMCid:tronです。
本日10月3日よりBoothにて音楽作品集「KMC Music Collection Vol.4」の販売を開始しました。
試聴は上記販売ページより可能です。
収録曲には歌詞がついているものもあります。歌詞はBoothの商品画像をご覧ください。
KMCではパソコンで何かしたい人々を常時募集しています！！個人的にはDTMに興味がある人を特に募集したいです！！！ (※もちろんDTM以外に興味のある人や現在特に何か興味があるわけではない人も歓迎します！！) www.kmc.gr.jp
先日株式会社obniz (オブナイズ)が主催する『obniz IoT コンテスト 2021』が開催されました。 elchika.com このコンテストに参加すると obniz Board 1Y を手に入れられるという情報が部内で拡散し、KMCからも6人が参加することになりました。以下では各々が投稿した記事の概要をまとめてみたいと思います。
elchika.com 時間になったら開くカーテンを作ったようですね。既設のカーテンレールにベルトを取り付けてうまく活用しています。モーターを駆動するモータードライバーが焼けるのではないかと心配されていましたが、トラブルなく順調に動作しているようです。本人曰く、このおかげで朝起きられるようになったとのことで、「早起きの会」を主宰されていました。
elchika.com 抵抗歪みゲージという力を検出するセンサをベッドに組み込んで、起床・就寝を mastodon に報告してくれるサービスを作ったようです。ほんの僅かな抵抗の変化を検知するため、ホイーストンブリッジを応用したそうです。polaris さんは現在電子工作勉強会を主催されていて、多数の部員が聴講しています。講座終了後には洗脳された部員たちが組み込み Rust で遊ぶ姿がきっと見られることでしょう。
elchika.com ドットマトリックス LED をダイナミック点灯させて文字を表示しようとしたようです。遅延があって上手くいかなかったそうです。io.animationという api はネットワーク経由であっても高速・正確な IO の操作が行なえるそうで、それを使えば良かったかもしれません。投稿の締め切りを守るのも良いかと思われます。
elchika.com MH-Z19BというCO2センサを使って室内のCO2濃度を測定したようです。CO2センサは今だと秋月電子でMH-Z19Cが販売されていて気軽に購入できますが、ほんの少し前まではもっと高額な部品しか流通しておらず、MH-Z19Bも海外から調達する人が多かったようです。長時間自宅で活動せざるを得ない昨今、部屋の CO2 濃度が高いかモニタ出来ると良さそうです。
elchika.com SHT31-Dという湿度センサを利用した自作の湿度測定モジュールを、格安のUSB加湿器に組み合わせてフィードバック制御したようです。USB端子の1ピンと4ピンが電源用のピンなのを利用してうまく工作されています。今回多数の部員がこのコンテストに参加したのは strelka さんが部内で情報を共有してくれたのがきっかけでした。strelkaさんはこの記事以外にもモーターやマイクロ波レーダーを利用した記事を紹介されているのでご覧ください。
elchika.com 最後に私の作品を紹介します。Slackのwebhooksを利用して、KMC部員なら誰でも自分の部屋のエアコンを操作できるようにしました。半分ネタです。JavaScriptを書くのは初めてだったので結構苦労しました。部員用Slack上でサービスを開発すると、他の部員がサービスに対して破壊的な入力を試みてくるため、デバッグに便利です。
KMCでは電子工作に興味がある部員を募集しています。興味のある方は是非下のリンクからどうぞ!! www.kmc.gr.jp
初めまして、競技プログラミング練習会2021 Normalの担当(の1人)のid:Flkanjin(KMCID: flkanjin)と申します。つい先日までGWでしたが、いかがお過ごしでしょうか? 昨年の前期はずっと自宅で授業で、今年は最初の2週間は対面授業も実施されましたが、殆どの科目が京大内の対応レベルの引き上げによりリモート授業となりました。私はというと、実験科目があるので、毎週大学に行っているのですが、定期を買った方が良いのか、ICチャージさせた方が良いのか...という感じで迷っています。
KMCの先輩と話しているときに「このブログ更新してみない?(意訳)」と言われましたので、活動ブログとして、今年のこれまでの競プロ練習会や、そもそも競プロとは何ぞやについて書きたいなと思います。
競技プログラミングとは与えられた問題について、それを解くための適切なアルゴリズムを速く正確に書くことを競う競技です。競技プログラミングという名前は少し長いのでよく競プロと呼ばれます。数学やパズルのような要素があり、そのようなものが好きな競プロerは多いですが、そうでない競プロerもたくさんいます。
また、数学などの試験のような形式だけでなく、長時間(ものによっては1ヶ月など)でおこなうマラソンという形式のコンテストも存在します。こちらは与えられた問題に対してなるべく良い解をとれるようなぷトグラムを作り、その点数を競うものです。こちらの記事のゲームAI系と近いものがあります。
KMCでは競プロ練習会としてNormal(未経験、初心者向け)とAdvanced(上級者向け)の二種類が開催されています。
Normalでは主に初めての方向けにC++というプログラミング言語やアルゴリズムの基礎についての講座を行い、その内容に関する(バーチャル)コンテストを行います。初心者向けというのもあって質問対応なども丁寧に行っているつもりです。Advancedの方では毎回コンテストを行い、いくつかの解では講座も行っているようです。
去年から続くコロナ禍のため、例年の通りの部室での活動ができないため、Discordを用いてオンラインで行っています。今年は講座の担当を奇数回は私(KMCID:flkanjin)が、偶数回はKMCID:replica君が担当しています。コンテストは基本的にはAtCoderの過去問やAOJに存在する問題を用いて開催しています。
初回であったため、簡単に競プロとは何かということを話し、いくつかのオンラインコンパイラを紹介、自前での環境構築について少し触れたのち、C++の基礎(コメント、変数、入出力、if, while, for)についての講座を行いました。
コンテストでは今回の講座の内容だけで解くことのできるAからD問題(ただし、CDは難易度高め)と経験者向けのEからK問題を出題しました。難易度的には後半の問題は特に難しいものを集めていたので、解ける人いるだろうか、みたいにドキドキしていていたところはあります。
2回目は1回目に引き続きC++の基礎(型についての詳しい説明、配列(vector)、関数(再帰も))についてやったのち、競プロにおいて重要な概念である計算量と一番単純なアルゴリズムである貪欲法について学びました。コンテストは少し難易度が高めでABでWA(不正解)などを出している人が結構いたなという印象でした(AもBもペナルティなしで正解した人が1人ずつでした)。この回からコンテストの内容は講座の内容にリンクしたものになっています。
この回のテーマは累積和で、派生してimos法や尺取り法も取り扱いました。今回からのアルゴリズムは基本的に高速化するためのもので、コンテストも素直な実装では間に合わないという問題が多くなっていますが、殆どの参加者か解け形るようで安心しました。
ソートや二分探索、そしてSTLのデータ構造についての講座でした。pairのソートについて少し複雑だったかもしれません。二分探索について慣れていってほしいなと感じました。
今回は全探索回でした。線形、順列、DFS、BFS、bit全探索(とそれに必要なbit演算)についても勉強しました。ちょっと講座部分が長かったかもしれないです。線形探索や順列探索は単純なものでしたがその他のものは少し複雑でとっつきにくいものだったかもしれません。分かり易い説明を考えないとなぁと感じさせられました。
人に何かを教えるというのは難しいなぁ、と感じさせられます。特にリモートで行っていると顔が見えなかったり、どこで困っているのかが見えにくく、早く部室でできるようになってほしいなと思います。
翌週の05/14(金)に競プロ練習会Normal第6回を行います。この記事を読んで興味を持った方やこの春に何かしら新しいことを始めたいと思った方など、奮ってご参加ください。
KMCではパソコンでゲームを作ったり、音楽を書いたり、お絵描きしたり、競プロをしたりしています。興味のある方は是非下のリンクからどうぞ!! www.kmc.gr.jp
こんにちは！！！！KMC4回生のkmcid:bu4です。
これはKMC Advent Calendar 2020の3日目の記事になります。昨日の記事はkmcid:prime(id:PrimeNumber)さんによる「フラグメントシェーダを用いて、VRChatのワールドで計算機を作る」でした。昨日は技術記事でしたが、今日はDTM？関連のお話となります。
第二回おかし会を開催しました。
おかし会ってなんやねんってお話ですが、KMCのDTMerたちが集って歌詞についてあーだこーだ言ったり言わなかったりする会のことです。第二回とありますが実は第一回は昨年度に行っていました。
第二回はオンラインでの実施となりました。
最近KMCのDTMerでは歌ものがアツいです。それはもう。今まで書いていなかった人でも歌ものを書き連ねております。
さて、歌ものを書く際に必須となる作詞スキル。今までKMCではあまり歌ものの動きはそこまで活発でなかったので作詞の知見が枯渇していました。KMCのDTMがさらに幅広くなっていっているのが感じられます。嬉しいね。
今回は参加者それぞれに歌詞についてお話をしていただきました。
例えば、kmcid:naka6さんは、歌詞だけでなくオケとも併せて世界観を作ることや、「テーマ」の重要性等々のお話を語ってくれました。
他にも、各自のメイキングを交えながら、情報量の調節、抽象と具体の使い分け、etc…、様々な知見や意見を聞くことができました。話せば話すほど作詞の難しさが感じられます。
これからの制作に活かしていきたいとモチベーションも上がりまくりです。みなさんも音楽を作っていきましょう。
明日のアドベントカレンダーはkmcid:nosさんによる記事になります。
また、今年度も並行してお絵描きAdventCalendarが行われています。こちらもご覧ください。
そして、KMCでは作詞だけでなく、作曲、競技プログラミング、webサービス製作、お絵描き、ゲーム製作等も行っています！！！！！PCを使って何かしたい人々を募集しております。
