CodeGrid12周年記念コンテンツ 記念動画ダイジェストとリアルパーティーレポート
2024年5月に公開した、CodeGrid12周年記念動画のダイジェストと12周年記念パーティーの様子をお届けします。
- カテゴリー
- CodeGridのこと
発行
はじめに
CodeGridは今年、2024年で12周年を迎えました。以前は周年記念に合わせてリアルイベントを開催していましたが、ここ数年はコロナ禍の影響もあり、お休みしていました。
しかし、今年は久しぶりに周年記念のリアルイベントを開催。イベントに合わせて12周年特別セッションを含む動画も作成し、YouTubeに公開しました。この記事では、その特別セッションのテキスト版としてダイジェストで紹介します。また、CodeGrid12周年記念パーティーの様子もお届けします。
12周年記念動画
CodeGridの12周年を記念してつくられた動画が、パーティー当日に公開されました。同時にYouTubeでも公開されています。
動画という媒体は大きなチャレンジでしたが、動画であれば、パーティー会場でも会話を遮ることなく視聴できます。また、パーティーにいらっしゃらない読者や、CodeGridに興味がある方にも、YouTube上で手軽に見ていただけるだろうと考えました。
動画編集はJamstackエンジニアの中野、サウンドはディレクターの高津戸が担当しました。
高津戸はプライベートで音楽をやっています。よろしければどうぞ！Takazudo | YouTube
お時間がある方はちょっと冒頭を再生してみてください。テトリスのように上からブロックが落ちてきて、CodeGridの文字が現れるオープニングは、フロントエンド・エンジニアの菅野が、動画編集ソフトなどを使わずに、RemotionというReactライブラリを利用してつくったもの。画像ではなくて、すべてJavaScriptで書かれています。興味のある方はソースコードを公開していますので、参照してください。
オープニングムービーの苦労あれこれ
Remotionは、Webの技術で動画を制作できることにロマンを感じて採用しましたが、CSSアニメーションなどのWebでのアニメーション技法をそのまま使えるわけではありません。次のようなRemotionの仕組みに沿ってアニメーションを制御する必要があり、計算式を組み立てる上でかなり頭を使いました。
useCurrentFrameフックで取得した現在のフレーム数を使って、動画の進行度合いに応じた表示を計算する- 位置や透明度などの値をアニメーションさせる場合は、
interpolate関数で値を補間計算する
Remotionに興味を持たれた方は、次の公式チュートリアルを読んでみると良いでしょう。「動き」をコンポーネント化して使いまわせる、というRemotionの利点も感じられるはずです。
また、今回のオープニングムービーでは、最終的に「CodeGrid」という文字が浮かび上がるように、テトリス風にブロックを落下させています。この画像は、ブロック配置を考えるために、Numbers（アップルの表計算ソフト）で作成した表です。CodeGridのロゴになるようなブロックの配置を考え、落下順や重なり順を考慮して全ブロックの座標をリスト化する工程が、もっとも骨の折れるものでした。（フロントエンド・エンジニア 菅野）
動画は大きく、CodeGridの紹介と、特別セッションに分かれています。
CodeGridはこれまで技術情報を提供してきましたが、これまでCodeGridという媒体自身の歴史については、あまり触れていませんでした。12周年を契機に、読者の方々と、まだCodeGridを知らない方々へ向けて、「CodeGridはこういう媒体で、こんな人々がお届けしています」という自己紹介をあらためてさせていただきたいという思いがありました。
特別セッションはCodeGridで取り上げるフロントエンド技術テーマを著者が解説しています。デザイン、代替テキスト、3Dグラフィックスを切り口に、CodeGridの技術に対する着眼点を自然と体験してもらえるようなセッションを目指しました。
動画全体は50分弱の大作ですが、気になるセッションだけを視聴してみるのもいいかもしれません。ここからは、テキスト版のダイジェストでご紹介します。
動画の字幕の苦労
今回の記念動画では、アクセシビリティ的に字幕のサイズや色などを見る側に委ねられる、日本語以外の言語でも視聴できる、などの利点を考慮し、YouTubeの字幕機能で字幕を入れることにこだわりました。
アップロードすれば、何もせずともある程度YouTube側が自動で字幕を当ててくれるのですが、「Figma」「three.js」「Rapier」などの固有名詞が正確に認識されるはずもなく、基本的に文章としてキリの悪いところで改行されたりもします。また、そもそも全体を通して誤字がないかの確認が必要で、結果的に40分越えの動画に、ほぼ手作業で字幕を入れることになっており、気づけば朝日が昇っていました。
YouTubeの機能なので、完成した動画をYouTubeにアップロードしてからの作業になるわけです。無意識に動画の完成で山場を越えたとホッとしていたところに、思わぬ重量の作業でした。（Jamstackエンジニア 中野）
セッション「伝わるデザインデータのはじめのいっぽ」
（発表：UIデザイナー 小原 司 YouTubeのチャプター箇所）
「伝わるデザイン」というと、上手に情報を伝達することをイメージする人が多いと思いますが、ここでは『伝わるデザイン「データ」』がテーマです。これはFigmaのデザインデータの意図や指定を、ウェブの実装工程の人にどう上手く伝達できるかという話です。
フォーカスしたのは、デザインデータファイルをまとめたページの部分です。そのポイントはデータの命名にあります。命名をエンジニアフレンドリーにすることで、より伝わりやすいデータになります。
その命名のコツをサンプルのFigmaデータを見ながら説明します。
Figmaデータの構成と命名
以下の説明はサンプルデータと合わせて読むとより理解しやすいです。セッション用につくられたFigmaデータは公開されています。ファイルの複製も自由にできます。データのつくりなどをじっくり見ることができるので、活用してみてください。
サンプルデータでは各セクションのデータを実際に見ることができます。
- Cover：カバーはデータの概要としてサムネールをつくることができる
- README：どのような用途でつくられたデータかの説明
- Design Tokens & Rules：規定値として設けられたデザイントークン、それらのデザインルールをまとめてある
- Components：あらゆるコンポーネントが置かれる。Componentsは次の3つに分かれる
- Primitive Components：いちばん小さな単位のコンポーネント。それ単体では意味を持たない（例：ボタンなど）
- Composite Components：プリミティブコンポーネントを組み合わせた、さらに具体的なコンポーネント（例：グローバルヘッダー）
- Layouts：アプリケーション全体やパネルなどのレイアウト
- Assets：アイコン、アバターイメージなど静的リソースが置かれる。実装の際には、この素材を書き出して使えるようになっている
- for Figma：実装には使わないもの。データの意図を伝える、メモやタイトルのテンプレートが置いてある。また、ブラウザーのUIなど、実装には使わないが、デザインをする際に必要なパーツもある
次のセクションではグローバルな共通機能や、ログイン画面、ホーム画面など具体的なページについてのデータが分かれて並びます。これはセッション用につくった架空のサイトなので、具体的なページの数は少ないですが、[global] 共通機能、[page] ログイン画面、[page] ホーム画面、[page] 異常系, 400系、500系に分けて、実際にデザインしています。
架空のサイトについて作られたデータですが、デザインパーツをどのように作っておき、実際のページデザインをどのようにしているか、実際のデータと突き合わせてみていただくとわかりやすいセッションです。
【視聴ポイント】リアルなデータをぜひ
以上、セッションで紹介されたデザインページを紹介しました。小原もセッションの最後で言及していましたが、ぜひ、セッションでも使われたFigmaのデザインデータを見てほしいと思いました。
セッションで小原が解説した内容は、冒頭に挙げたサンプルデータと突き合わせてみると、よりよくわかります。セッションで紹介されていたページタイトルと、その分類は、ピクセルグリッドで普段マークアップをしたり、プログラムを書いたりするエンジニアの思考に馴染みやすいものになっています。
小原が実案件でデザインするデータは、ずっと複雑になりますが、デザインの意図を伝えつつ、アプリやサイトのさまざまな「状態」を可能な限り網羅していることは、サンプルデータでもわかります。エンジニアから「こういうときは、どういうデザインになりますかね？」という質問を極力しないで済む、エンジニアに「よしなにやって」を要求しないようにつくられています。
デザイナーとエンジニアとのコミュニケーションが向上するためのヒントとして役立てていただけるといいなと思います。 （編集 外村）
セッション「CodeGridの記事中の代替テキスト」
（発表：フロントエンド・エンジニア 坂巻 翔大郎 YouTubeのチャプター箇所）
CodeGridでの代替テキストをテーマに話します。まずは、「代替テキストって重要なの？」というところが気になるかと思いますが、CodeGridでは「画像が表示されない」という状況が、とてもわかりやすく存在します。
ご存知のようにCodeGridはWeb版とテキストメール版で配信されています。テキストメール版では代替テキストが使用されています。
Web版だと記事の画像ブロックがあって、見出しのテキストと画像があります。Chromeだと画像のところに代替テキストが表示されます。これがテキストメール版になると、代替テキストと画像のURLで記載されます。
テキストメール版においては、代替テキストがないと画像のURLだけがあって、どんな画像なのかはまったくわかりません。
指針
CodeGridの代替テキストには6つくらい指針があります。それを順番に紹介します。
1. 代替テキストの基本フォーマットがある
代替テキストの基本フォーマットをつくっています。
基本フォーマット
alt="種別：内容"
alt="スクリーンショット：リニューアルしたピクセルグリッドウェブサイトのトップページ"代替テキストの対象となる画像がどんなコンテンツなのか、その種別を書きます。たとえば、「スクリーンショット」「写真」「図」などです。次に全角コロン（：）で区切って、実際の代替テキストが続きます。
2. 見たままを忠実に置き換える必要はなく、記事の文脈で必要なものに絞る
「画像で伝えたいこと」を代替テキストにしたい。そのためには、本文でその画像がどう扱われているかに注意をする必要があります。たとえば、本文に「次の画像を見てください」と書いてあるのに、画像側に代替テキストがないというのは避けたいです。
3. 長い代替テキストも許容する
図やフロー図の代替テキストはある程度長くなっても仕方ないです。たくさんの情報を入れた図であるので、それに比例してテキストが長くなるのはありうることです。ただ、できるのであれば、説明の役割をすべて画像に負わせてしまうのではなく、本文に書くことも検討したほうがいいと思います。
4. 代替テキストがない画像は基本的にはない
基本的にはすべての画像に代替テキストをつけます。ただし、例外的に単なる装飾的な意味しか持たない画像については代替テキストはなしでいいです。また、代替テキストは本文でどの程度その内容が言及されているかによって、どれだけ詳細に書くかや、どの部分を書くかは変えています。
たとえば、「次の画像にあるように、XXXXXXXX」とかなり細かく説明されていた場合、代替テキストは簡潔なものでいいでしょうし、逆にあまり説明されていない場合は、伝達したい内容を伴った長めの代替テキストが必要になります。
5. 客観的にする
たとえば、CodeGridのロゴの画像があったとして、"コードグリッドのかっこいいロゴ"と書いたとします。「かっこいい」というのは主観なので、私にとってはかっこいいけど、他の人はかっこいいとは思わないということが起こり得ます。その場合は、単に"コードグリッドのロゴ"というふうに、主観的な言葉は入れないことにしています。
6. 代替テキストにすべて書くのではなく、本文へ
代替テキストは簡潔にし、本文側に画像で言わんとするところをきちんと文章として書くことも大事です。本文ならテキストなので、画像よりは同質の情報が届きやすいです。あまりにも長い代替テキストになってしまったら、本文との関係を見直し本文とのバランスを見直してもよいでしょう。
このほか動画では、みなさんがご覧になっているCodeGridの代替テキストがどうなっているか、レビュー体制はどのように組まれているのか、代替テキストに悩んだときはどうしているのかなど、実際の取り組みも話されています。
代替テキストもコンテンツの一部で、どのサイトにも必要なものですが、書き方がわからなかったり、どういう役割分担でテキストを作成していったらいいか迷うことも多いと思います。まずは第一歩として、このセッションを参考に、代替テキストの整備に役立てていただければと思います。
【視聴ポイント】代替テキストで気づく、図版の役割過多
CodeGridでは編集者が代替テキストを考えることが多いです。セッションの中で紹介されていた方針、代替テキストがあまりにも長くなると、本文とのバランスを見直すというのは、編集が代替テキストで悩み、エンジニアに相談する日々のレビューの中で培われた視点です。
著者へ原稿を戻すときにも、情報を取りやすくするために、図版だけでなく、本文でも説明してほしいとお願いすると、そのように書き換えてくれることがほとんどです。若干、冗長に感じるかもしれませんが、情報の取りやすさは「適切にマークアップされたテキストが最強」かなあと思います。
現在配信される記事にはもれなく代替テキストがついていますが、過去の記事は整備中です（これはセッションの最後で坂巻も言っています）。がんばります（坂巻も言っています）。 （編集 外村）
セッション「three.jsとRapierでドライブゲームが3日でできた話」
（発表：フロントエンド・エンジニア 小山田 晃浩 YouTubeのチャプター箇所）
ピクセルグリッドには「開発合宿」があります。温泉宿に3日間宿泊して、好きなものを開発します。小山田は今回、車が道路を走り、マウスや指で操作することができるドライブゲームをつくりました。
道にはアップダウンがあり、上り坂はスピードが足りないと、うまく登れなかったり、さらにスピードが落ちてしまったりします。下り坂では物理法則に従って、加速度が出るので、ちょっとブレーキが効きにくくなったりします。
以下のリンクからもプレイできるので、まずちょっと動かしてみてください。
セッションでは、このゲームに使った技術背景が紹介されています。
技術スタック
3Dのゲームをつくる上では、3Dの表示と、物理シミュレーションを使うことになります。3Dの表示にはthree.jsとか、babylon.jsなどがあります。物理演算ライブラリも以前よりも選択肢が増えて、Rapier、Havok、JoltPysicsなどがあります。
今回は、次のライブラリを選択しました。
- three.js：制作者の小山田が使い慣れている。ベクトル、行列、クォータニオンなど数学の機能が充実している
- Rapier：Rustで開発されている物理演算ライブラリ。WASMによるJavaScript版も提供されている
Rustで書かれたものは変換される途中で型が自動生成されているので、TypeScriptとも相性がいいですし、自動車のシミュレーション機能が搭載されているので、それを使って行くことを考えました。
three.jsのメッシュ内のすべてのジオメトリーからコピーしたジオメトリーを破壊操作していきます。変換行列を頂点座標に焼き付けて、three.jsのジオメトリーの内容を取り出して、頂点配列からRapierの剛体をつくることができます。
さきほどRapierには自動車物理があると述べましたが、JavaScript版にはありませんでした。これは独自に開発している人がいて、その方が公開しているコードを流用しました。
描画と物理シミュレーション
さて、このゲームの「つくり方」ですが、その触りの部分をここでも少しご紹介します。
描画と物理シミュレーションの関係ですが、Reactなんかに例えると、stateとDOMという関係になります。stateが更新されると、DOMが切り替わる。これと同じで、物理シミュレーションで何かが起きると、それを3Dの世界に反映してあげます。こうすると、リアルな物理シミュレーションをゲームの表示に持ってこられます。
物理シミュレーションの設定と表示
// 物理シミュレーションの入れ物
const gravity = { x: 0, y: -9.81, z: 0 };
const world = new RAPIER.World( gravity );
// 表示
const width = window.innerWidth;
const height = window.innerHeight;
const clock = new Clock();
const scene = new Scene();
const camera = new PerspectiveCamera( 60, width / height, 0.01, 1000 );
camera.position.set( 0, 1, 6 );
camera.lookAt( 0, 0, 0 );
const renderer = new WebGLRenderer( { stencil: false } );
renderer.setSize( width, height );
document.body.appendChild( renderer.domElement );プログラムでは半径1のボールをつくり、物理シミュレーション側でも同様に同じ半径、同じ係数を使ってボールをつくります。
半径1の球体の表示とその剛体
const radius = 1;
// --表示部分--
// 半径1の球体
const ballMesh = new Mesh(
new SphereGeometry( radius, 16, 16 ),
new MeshNormalMaterial( { wireframe: true } )
);
// scene内に配置
scene.add( ballMesh );
// --物理演算部分--
const rigidBodyDesc = RAPIER.RigidBodyDesc.dynamic()
.setLinearDamping( 0.1 )
.setTranslation(0.0, 3.0, 0.0);
const rigidBody = world.createRigidBody(rigidBodyDesc);
// 半径1の球体の剛体
const colliderDesc = RAPIER.ColliderDesc.ball( radius )
.setFriction(0.1)
.setFrictionCombineRule( RAPIER.CoefficientCombineRule.Max )
.setRestitution(0.6)
.setRestitutionCombineRule( RAPIER.CoefficientCombineRule.Max );
// world内に配置
const collider = world.createCollider( colliderDesc, rigidBody );具体的なコードは以下を参考にしてください。
その他、動画では車の形状は有料で販売されているモデルを利用したり、ドライブゲームの作成過程が詳しく紹介されています。
「Webの技術で、ゲームの仕組みを知るのは楽しい」というなかなかマニアックなセッションです。CodeGridの特色の一つは「原則として、案件や個人プロジェクトで試した技術を紹介する」ところにありますが、その特色が極まったセッションでした。
【視聴ポイント】「なるほど、わからない！」
小山田は開発合宿では、three.jsを使った3D表現を追求していることが多いです。開発合宿の最後には、成果物の発表があり、今回のセッションのように、簡単なコードを使って仕組みを理解させ、成果物の説明に入ります。
が、普段、JavaScriptをガンガン書いているプログラマーでさえ、「なるほど、わからない！」と笑顔で答えるのを、私は知っています。もちろん、コードを見ていけば、何をしているかはわかるはずです。半分は冗談です。
three.js系の記事を企画するたび、「これは求めている人は少ないかもしれないけれど、求めている人にとっては、情報が少ない中での灯火になるはず」と考えています。でも、もちろん、長期連載は避けます（長期連載を求めている方、ごめんなさい）。ピリっとくる、スパイスのようなテーマなのです。 （編集 外村）
CodeGrid12thパーティーの様子
最後に、5月12日に開催されたCodeGrid12thパーティーの様子を少しお届けします。会場はピクセルグリッドのオフィスがある表参道で行いました。会場は広くもなく、狭くもなくといったちょうどいい雰囲気でした。
Welcomeボード代わりのメッセージボードには、付箋に来場者のヒトコト紹介カードがペタペタと貼り付けられていました。最近気になっている技術や好きなこと、困っていることなどを自由に書き込んでもらう方式です。写真は参加者の入場前で、ピクセルグリッドスタッフのカードが貼られたところです。
当日、参加者にはTシャツとネームカードとなっているNFCカードをお土産としてお渡ししました。NFCカードには事前におうかがいした自己紹介リンクのURLが書き込まれており、スマートフォンをかざすとそのURLが読み取れます。
パーティーでは、まずはスマートフォンでピッとスキャンしてからはじめるというスタイル。初対面の参加者同士でも、お話のきっかけになるかも？ ということを考えてでしたが、参加されたみなさんはいかがでしたでしょうか。
ピクセルグリッドのスタッフともお名前交換できます。スタッフとお名前交換した場合は「ゲットしたスタッフ」の一覧が表示でき、5名以上のスタッフをゲット（お名前交換）すると景品をプレゼント、という企画もありました。なお、ピクセルグリッドでは、このパーティーを機に、名刺を紙からNFCカードに切り替えました。その詳細については、ピクセルグリッドの仕事術シリーズの記事があるので、ぜひご覧ください。
会場ではフリードリンクとフリーフードで、気楽におしゃべりが基本だったのですが、ちょっと話のきっかけにと用意したジェンガが好評でした。参加者同士、その場でチームを組んでもらって、ジェンガを楽しんでもらいました。
ひとりでお食事をしていた方は、スタッフからジェンガに誘われる確率が高かったかもしれません（笑）。「ジェンガでスタッフと名刺交換する機会になった」と言ってくれる方もいました。パーティーの間はメンバーをチェンジして数回行われましたが、最後の回は、テーブルが手狭に感じるほど盛況でした。
まとめ
パーティーに参加しなかった方にも情報共有ができるように、パーティーの様子や、会場で上映されたムービーをダイジェストでお届けしました。
動画という初めての試みは手探りで進めたところもありましたが、いかがでしたでしょうか。また、パーティーの様子をごらんいただいて、次回の開催（いつかな!?）に参加してみたいと思っていただけたらうれしいです。
スタッフも、久しぶりのパーティー開催の中、読者の方々と直接お会いして話し、楽しい時間を過ごすことができました。編集スタッフとしては、いつもネットの向こうにいる読者に、ほんの一部とはいえ、お会いでき、「こんな人たちが読んでくださっているんだなあ！」とリアルに感じることができました。参加してくださった方々が、「楽しかった！ Webの人たちっていいよね！」と思っていただけるようなパーティーになっていたら、うれしいのですが。
動画を見た感想や、パーティーにご参加いただいた方の感想などをぜひお寄せください。これからもどうぞよろしくお願いいたします。