コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

GoogleAnalytics4にてどのイベントでどのディメンションが付与されるかはドキュメントがある

GoogleAnalytics4(以下GA4)をゴリゴリ設定していたのでそのときの備忘として

GA4におけるディメンションとは

GA4はすべての計測が「イベント」という単位で行われ、その発生したイベントにパラメータを持たせてイベントの種別をつけられるようにしている。詳しくは以下サイトの説明がまとまっているので以下を参照。

GA4のイベントの基本的な考え方 | アユダンテ株式会社

このイベントに対する「パラメータ」にあたるものがGA4のドキュメント上では「ディメンション」と呼ばれる。

GA4で予め想定されているイベントとディメンションについて

前身であるUniversalAnalyticsでは「イベントカテゴリ」と「イベントラベル」が設定できたので、自由記述できる情報は「名前」「カテゴリ」「ラベル」の3つだったのだが、GA4では等しくイベントに設定できる情報は名前である『イベント名」だけになっている。ではGA4でイベント独自の情報はどこで設定すべきかというと、ディメンションを使うようになっている。

また、GA4では設定すると自動で収集されるイベントがあり、それらのイベント名とディメンション名(パラメータ名)は決まっている。一覧は以下のページに有る。

[GA4] 自動収集イベント - アナリティクス ヘルプ

例えばページ内でのクリックで遷移するイベントは、イベント名が click であり、独自情報であるディメンションとして link_classeslink_domainlink_idlink_urloutbound が設定されて記録される

ディメンションとGA4のデータ検索

GA4では「データ探索」という機能で、発生したイベントの情報を閲覧することが可能となっている。この際にイベントに付加されたパラメータを判別するために「ディメンション」という概念がある。たとえば「ページ タイトル」「日付」などが該当し、表を作る際の「列や行の項目」の役割で使われる。このディメンションはイベントによって変わる。

前段で例として取り上げたイベント名 clicklink_domain というキーを持っているが、「データ探索」上ではどの値かはわからない。

データ検索上のどの値に当たるかはわからない

実際のGA4の画面、link_domainとしてわたってきた値はどこにあるかは雰囲気的にわかるが、確証がもてない

これらのイベント上のキー名が「データ探索」ページ上にどれに当たるかを下記のドキュメントを見ることである程度追うことができる。

[GA4] アナリティクスのディメンションと指標 - アナリティクス ヘルプ

たとえば link_domain に関してはデータ検索上では「リンクドメイン」ということが以下の表からわかる。

表を見るとlink_domainが日本語表記ではリンクドメインということがわかる

関連リンク

[GA4] 拡張計測機能のパラメータがデフォルトのディメンションとして使用可能に | アユダンテ株式会社

CSSの技術名で似ているものをすごくざっくり整理する

混乱するのでざっくりフレーズベースでまとめる

大枠としての技術を示すもの

WebComponents

WebComponentsはHTMLをコンポーネント化するための技術の総称。主に以下の3つの技術をつかって実現を目指している。

  • CustomElement
  • ShadowDOM
  • HTMLテンプレート

詳しくは以下のページを参照のこと。

CSS in JS

CSSのグローバルスコープを解決する手法の一つとして、Javascriptの記述に織り込む形でCSSを構成する考え方があり、それらを体現したライブラリのことがCSS in JSと呼ばれている。代表的なものとして CSS Modules,Styled Component,Emotionなどがある

CSS Modules

CSS ModulesはJavaScriptからCSSをインポートするような記述で連動させる仕組みの名前、詳しくは以下のブログにまとまっているので参照のこと。

Styled-Component

ReactのJSXの範疇の中でCSSのスタイルを閉じ込める仕組みの一つがStyled-Compnent。詳しい仕組みなどは以下のブログに紹介されているので参考のこと。

特定の仕様を示すもの

@layer

CSSカスケードに関してレイヤーを追加する提供予定の記述のこと。2024年時点ではまだ仕様策定中。カスケードレイヤーとも呼ばれることがある。詳しい仕様としては以下参照のこと。

@scope

CSSの適用範囲を決める記述のこと.2024年時点ではまだ仕様策定中。Scoped Styleと呼ばれることもある。仕様としては以下の内容を参照のこと。

CSS Scope

CSS自体の適用の範疇を示す言葉、WebComponentsでのShadowDOMでは別の切り口でスコープが区切られるため、それらの説明などのときに使われるフレーズ。(適用の話に関してはこちらを参照のこと)

MDNのドキュメントに登場するので、詳しくは以下を参照のこと。

Scoped CSS

Vue.jsのSFC(Single File Component=単一ファイルコンポーネント)が提供するCSSの適用範囲を狭める機能のこと。詳しくは以下のVue.jsの説明を参照のこと。

その他

ViewComponent

Rails用のgemの名称。部分的なHTMLを作成するためのフレームワーク。詳細は以下参照のこと。

関連リンク

チームが成長しているときに読み直してたい記事『スタートアップの熱狂と急成長を両立させる野望』

何回か読み返したいタイミングがあったのでメモまで。

ブログ記事

スタートアップの熱狂と急成長を両立させる野望 - 株式会社ヘンリー エンジニアブログ

みどころ

スタートアップから成長していく過程で考えないといけないことに関して、筆者の経験や情報から書き上げられた記事。スタートアップという話を基軸に置かれているが、チームやプロダクトが成長しているときにも当てはまる部分は多くあるので、そういうシーンに遭遇したときに自分が見失っているものはないかというところの再点検につかえそうな記事でした。

関連リンク

Object-Oriented Conference 2024​​で『オブジェクト指向CSSが叶えたかったことと、CSSのいま』という登壇をしてきました

発表したスライド

speakerdeck.com

伝えたかったこと

  • オブジェクト指向CSSはどういう問題意識から生まれ発展したのか
  • その後の世界ではどうなったのか
  • いまだとどんな選択肢が取りうるのか
  • フロントエンドやっている人は知っている人が多いので、普段フロントをガッツリやらない人向けへの現状共有

補遺編

今回のプロポーザルを作ろうとした動機

直近ではRuby on Railsでバックエンドを書くことが多く、CSSには触れるものの自分から能動的に何かをするわけではありませんでした。

そんな中で改めてCSSを書き直す場合、どのようなアプローチがあるんだ?というところの知見がまったくなく、そのあたりの知識を仕入れたいというのがありました。

そんな中、4年ぶりのObject-Oriented Conferenceが開催されるというところで昔に読んだ下記の本のことを思い出します。

『Web制作者のためのCSS設計の教科書』を読み終わったよメモ - コード日進月歩

この本では命名規則ベースの設計手法が書かれているのですが、ここでオブジェクト指向CSSが紹介されていたので、ここからたどっていくことで色々と話が書けるのでは?ということでプロポーザルに応募しました。

登壇駆動知識インプットと紆余曲折したポイント

もともとバックエンドかつ業務も基本はバックエンドを書くことが主体なので、完全に個人の時間にいろいろと知識のインプットを進めました。

今回トピックとして

  • 命名規則ドリブンのCSS名付け
  • JavaScriptと共存しているCSS管理手法
  • 直近のCSS新仕様
    • このあたりは話の筋書き的にカットしたかったんですが、プロポーザルに書いてしまったので取り上げる必要がでてきてしまい…

あたりをいい感じに一つの話の流れとしてまとめる必要があったので、どうつなげていくとキレイかがかなり悩ましいポイントでした。

うんうん悩みながら整理していったのですが、悩んでる最中で色々なインプットと巡り合うことができ、なんとか着地させることができました。今回大きく助かったのは以下の3つです。

  1. CSS設計って最近こういう感じだと思うんですけどどうですか - Speaker Deck
  2. 次世代Webカンファレンス2023のCSSパート
  3. 書籍:Tailwind CSS実践入門

今回取り上げられなかったところ

CSSの影響範囲(いわゆるスコープ)の話に関してはShadow DOMの話もあったのですが、今回のテーマにはイマイチマッチしていなかったのでカットしてしまいました。ただDeclarative Shadow DOM が出てきたのでJSなしでできることで違う世界観が出てくるのかもなという感覚を感じています。

また、詳細度がらみの話はカットしてしまいましたが、ブログにはまとめてあります。

登壇後記

  • 本当にCSSの話だったので、全然お客さんいないのではないかと思ったらそこそこに人が入ってくれたので助かりました。
  • 前段で『非デザイナーのフロントエンドエンジニアがOOUIを考える』があったので、ちょっと地続きの話が聞けてよかったです。
  • めっちゃ喋りは失敗しており、最初最大化し忘れたりなどしつつ変な飛ばしはなかったかな…とか…色々振り返ると思います。
    • そうなってもいいように資料でよんだらちゃんとわかるようにはしたつもりなので傷は浅くありたい
  • 今回の資料整理でデザインシステムやデザイントークンの話は面白そうなトピックが多いので、そのあたりも含めてインプットはしていきたくなりました。
  • OOCというカンファレンスが色々な技術バックグラウンドを持つ人が多かったので、懇親会でも様々な話が聞けてとても勉強になりました!

privateのテストコードに関して説明するときに見たいスライド『privateメソッドのテストって書かない方がいいんだっけ?』

初学者にスッと出すと良さそうな記事なので記録です。

資料スライド

asumikam.com

みどころ

privateはしてはならない、ということに対して実体験をもとに苦しんでいったことが書かれている。世間的によしとされていないprivateのテストに関して辛かったポイントが記述されているので、追体験しやすく、知見がないメンバーに知ってもらうにはおすすめの資料でした

関連リンク

『「Tailwind CSS実践入門」出版記念イベント』に行ってきたよメモ

「Tailwind CSS実践入門」出版記念イベント - connpass』に参加してきたのでそのメモです、

各発表の感想

※資料スライドは見つけたら貼ります。


基調講演

感想

  • CSSを普段遣い死ている人がなぜtailwindを選択したかという話には納得感があった。チームでどう使えるかの大事さ。
  • CSSのコードレビューの真剣さというのもそのとおりだなという気になってしまったので、もっと本質的なレビューをしたいというときにはたしかに良いのかもという気持ちに。
  • ユーティリティファーストの話もそうだが、書籍として歴史の部分に重きをおいているのを改めてしれてよかった。

関連リンク


CharcoalとTailwind

スライドは見つけたら貼ります

感想

  • pixivで開発しているOSSデザインシステムCharcoalとtailwindの話。
  • @charcoal-ui/tailwind-config でtailwindの細かな設定を利用でき、@charcoal-ui/react を使うとpixivっぽいUIも再現できる
  • 基調講演の話でもReactではない環境でも使えるデザインシステムを…という話だったので実例として見ることできてよかった。

関連リンク


Iconify for Tailwind CSSのすすめ

感想

  • すべてのIconファイルを使うためのIconifyのtailwind用のプラグインの話
  • tailwindに限らずこのような仕組みがあることを知らなかったので学びが多かった
  • ライブラリが複数ある場合の勘所みたいなのは難しいな…と思いながら聞いてました。

関連リンク


引数のあるmixinのような仕組みをプラグインとして用意する

感想

  • mixinみたいなところをtailwindで実現するための話
  • tailwind側の実装実例を交えながら記述の説明をされていた

関連リンク


トークセッション

著者の @f_subal さんと @harukasan の対談

内容メモ

書籍ではtailwindCSSの思想の話が多かったが、ここがよかったなという話があれば

デザインシステムを作るうえでテーマの制約ができること、たとえばスペーシングを使うのがカスタマイズできるしそれをpureCSSに近い技術でできるところ。 2020年当時だとそれが一番できるのはCSS in JSが主流だったが、それに近いメリットが得られるのが大きかった 利用としているところが全てがReactとは限らない、たとえばRailsのテンプレートエンジンなどもあるので、Reactでしかつかえないデザインシステムは避けたい、というところでもよかった。

実践入門といいながら、入門者を対応していない書籍のように思えるがなんでこういう書き方になったか?

著者観点としては具体特定のユースケースをなぞる形式の本よりも、原則などを教えてくれる本のほうが、自分だったらどうするかの置き換えコストが低いから。 本としてもそれは意識されており、実践的にな部分は後半の8章、9章。 また特定のユースケースだとCSSフレームワーク部分以外(ReactなどのJS)の選択に迷うのでそういう部分もあってこの書き方になった。

6章のコンポーネントの話について

tailwindはコンポーネントを作るときには苦手な部分がある。 tailwindはtailwind.configにあるクラスしかつかえないので、依存せずポータブルなものをつくるときにはCSS in JSのほうがよい。

pixiv社ではどう使っているか?

複数のプロダクトで利用している、プロダクトごとのprimary colorは異なるが、ほかはだいたい同じなのでブランドカラーのサポートなども難しい話ではない。

実際に使っていることについての話

「ここはなんでAribitaryValueなんですか?」みたいなやり取りが増えた。また9章で取り扱っている話は実態件を元にした話が多い。 また、デザイナーがあんまり協力的ではない状態で採用してもデザインシステムの構築は難しいと考えているので、一緒に考えられる人がいるときに使うと良いと思っている。

バックエンドエンジニアも読んでほしい部分に関しては、昔だったらCSS in JSなどしか受けられない恩恵がtailwindでも受けられる テーマに準拠する、動的にスタイル分岐をさせるなどは良いポイント。

Bootstrapの二の舞いにならないために

addComponentsを使ってcardのようなものを準備するとBootstrapのようになってしまう。 どちらかというと書籍「Every Layout」にあるようなデザインパターンをaddUtilitiesで使うようにした方が良い。

感想

  • 書籍の内容を掘り下げつつ、tailwindの苦手な部分の話などが聞けた。
  • なかでもCSS in JSとの対比はいくつかあったので、tailwindの得手不得手みたいなところは学びがあった。

関連リンク


全体を通しての感想

  • 書籍がとてもよかったので話を聞きに行ったが、pixivでの利用事例などが聞けてよかった。
  • 基調講演のスライドにもあったが、考え方の本ではあったのでクロストークでその根源が聞けてよかった
  • バックエンドを普段やっている身としてはスタイリング技術選定の助けになる部分が多かった
  • 時間の関係でトークセッション後には会場を後にしたが、もっと話についていける知識を身に付けられればな…と感じさせられる場だった

関連リンク

実況の中で以下のやり取りが非常にためになったのでメモ

かっこの英語表記をざっくりまとめる

あまり聞き慣れないのでメモとして

一覧

記号 日本語での呼び方 英語表記
( ) 丸括弧、小括弧 parenthesis
[ ] 角括弧  bracket / square bracket
【 】 隅付き括弧 lenticular brackets
「 」 カギ括弧 quotation marks
{ } 波括弧 / 中括弧 braces / curl

関連リンク