このBlogでは、現在、Hugo PaperModをテーマとして使用しています。現在、Hugo PaperModは結構いろいろなSNSに共有する機能がありますが、 残念ながらBlueskyへの共有はついていません。しかし、対応自体は可能です。 まず、共有はthemes/hugo-PaperMod/layouts/partials/share_icons.htmlに実体があります。 この中を見ていきます。 以下のようなものが見えてきます。 {{- if (or (cond ($custom) (in $ShareButtons "x") (true)) (cond ($custom) (in $ShareButtons "twitter") (true))) }} <li> <a target="_blank" rel="noopener noreferrer" aria-label="share {{ $title | plainify }} on x" href="https://x.com/intent/tweet/?text={{ $title }}&amp;url={{ $pageurl }}&amp;hashtags={{- $.Scratch.Get "tags" -}}"> <svg version="1.1" viewBox="0 0 512 512" xml:space="preserve" height="30px" width="30px" fill="currentColor"> <path d="M512 62.554 L 512 449.446 C 512 483.97 483.97 512 449.446 512 L 62.554 512 C 28.03 512 0 483.97 0 449.446 L 0 62.554 C 0 28.03 28.029 0 62.554 0 L 449.446 0 C 483.971 0 512 28.03 512 62.554 Z M 269.951 190.75 L 182.567 75.216 L 56 75.216 L 207.216 272.95 L 63.9 436.783 L 125.266 436.783 L 235.9 310.383 L 332.567 436.783 L 456 436.783 L 298.367 228.367 L 432.367 75.216 L 371.033 75.216 Z M 127.633 110 L 164.101 110 L 383.481 400.065 L 349.5 400.065 Z" /> </svg> </a> </li> {{- end }} これは、Twitter(X)への共有機能ですが、この前でも後ろでもに以下のようなものを挿入します。ただし、themes以下を直に変更すると面倒なので、ベストプラクティス通り、layouts/partialsに複製して変更します。 ...

もともとは、他のBLOGの記事をベースに書いていた記事があったのですが、 参考サイトがなくなってしまったため、すべてを書く必要が生じました。 そのため、前提条件を含めて記載します。なお、本記事はWindows環境下を前提にしています。 ※ なお、この記事はまだ作成を進めているので、予告なく変更されます。 レポジトリ構成 この記事では次のレポジトリ構成を想定しています。 BLOG用メインレポジトリ 記事公開用レポジトリ 記事公開用レポジトリはサブモジュールとして、BLOG用メインレポジトリに組み込みます。したがって、全体のディレクトリ構成は以下のようになります。 / - root | - archetypes | - content | - post | - layouts | - public | - static | - theme 記事公開用レポジトリはpublicに組み込みます。 テーマ管理用レポジトリはthemeの配下に組み込みます。 使用したツール 名称 Visual Studio Code cmd scoop 必要なツールの取得 scoopのインストール スタートからPowerShellを起動する PowerShellの設定変更 Set-ExecutionPolicy RemoteSigned -scope CurrentUser PowerShellからのScoopのインストール iex (new-object net.webclient).downloadstring('https://get.scoop.sh') gitのインストール scoop install git hugoのインストール scoop install hugo-extended テーマの準備 テーマは https://themes.gohugo.io/ から探されるといいと思います。 テーマに対する小幅な変更はlayouts以下に同構造でファイルを複製して修正することになります。これにより、themes以下を直接修正しなくても良くなります。 本アーティクルでは、hugo-PaperModの使用を前提として進めます。 BLOG用メインレポジトリの準備 を以下のコマンドで準備します。 hugo new site <my_site> BLOG用のディレクトリが出来たら git init後、github等適当なところにpushします。 テーマは適当にsubmodule addします。submodule addするポイントはthemes以下となります。 ...

Evidenceを理解する上でのポイントとして、静的サイトジェネレータを箸休めとして説明します。 まず、静的サイトと動的サイトの区別からです。静的サイトとは、コンテンツがファイルとして固定され、サーバはリクエストに基づきただ配信するだけのものです。初期のホームページと言われたもののスタイルです。 次に動的サイト、これはリクエストに応じて何らかのコードがサーバ上で実行され、動的にレスポンスが生成され、それがクライアントに返されるものです。WordpressなどのBLOGサービスなどはこの形態です。 静的サイトとは Wordpressなどではコンテンツはデータベースに格納されたものがベースで、同じようにテーマなどの情報がデータベースに格納され、それがユーザのリクエストによって組み立てられて返答されるという構造です。 静的サイトと動的サイトの差異 これだけで「静的サイトジェネレーター」のすべてがわかりますを参考にすれば以下のように纏められます。 動的サイト 静的サイト 表示されるページ ユーザーに応じて表示するページを変更できる 全員に同じページを表示する スピード 遅い 速い ページが生成される時 アクセスされた時 ビルド時 Wordpressなどが動的サイトとして構成されたのは、データベースにコンテンツ、テーマを格納しそれをリクエスト時に構築するという構造が都合が良かったためです。 静的サイトが再度注目された理由 しかし、今、再度、静的サイトジェネレータが注目された理由があります。まず、宿命的に表示されるコンテンツをユーザに合わせてというのは苦手ですが、通常のBlogサービスであれば、読者は通常ログインなどの手続きをしないため、ユーザに合わせては要件から除外できます。そうすると、動的サイトのメリットはかなり減ります。恐らく、GUIでのWebベースでのコンテンツメインテナンスなどのこの表に書かれていないモノになるでしょう。 そして、「全員に同じページを表示する」であれば、コンテンツへのテーマなどの適用はアクセス時にこだわる必要性はないになります。よって、バッチ的にサイトをコンテンツから生成する静的サイトジェネレータとなるわけです。 静的サイトジェネレータを支える要素 静的サイトジェネレータが注目された理由はそれだけではありません。一つはクライアント端末の性能向上です。例えば、昔の携帯電話のパフォーマンスと今のスマートフォンのパフォーマンスを比べてください。昔の携帯電話、フィーチャーフォン向けに開発された、CHTMLなどはかなりの仕様を削減していました、当然、クライアント側でのコード実行などは考えてすらいませんでした。しかし、今のスマートフォンはクライアント側でのモバイルコードの実行には十分であり、ECMA Script、WebAssemblyなどの支援もあります。故にコードの実行をWebサーバからクライアントに移すことも可能になりました。 故に、無理に、サーバ側で全てのコンテンツをレンダリングする必要はなくなりました、また、動的コンテンツを残すとしても、インラインフレームなどで組み込みむ手段もあります。従って、メインのコンテンツを動的に生成することは必ずしも必要なくなくなりました。 静的サイトジェネレータの限界 とはいえ、最初に上げた、「全員に同じページを表示する」という特性は無くなることはありません。 従って、静的サイトジェネレータを基盤とするBIツールであるEvidenceでは例えば、ユーザを認識してコンテンツを変えるなどは苦手です。例えば、厳密に、Need-to-Knowを実現するのは困難です。サイト自体に認証などは出来るにしても、コンテンツをユーザに合わせてレンダリングするのは困難です。 この辺のポイントを理解するのが、Evidenceを有効活用する道になります。

Covid-19のダッシュボードの作成を例にしています。イメージとしては、表形式でデータが見えるようにして、時系列で合計値がチャートして見えるようにして、カレンダーヒートマップで曜日ごとの動きが見えるようにするというのを考えてみます。仮説としては人の動きに感染者は依存しているのではないかと言う仮説です。だとすれば、曜日ごとに特徴があるのではないかと言う仮説です。 流れとしては、以下のような順番になります。 プロジェクトの作成 データのインポート クエリとビジュアリゼーションコンポーネントの配置 クエリとビジュアリゼーションコンポーネントの配置は主にMarkdownのドキュメントで行います。 プロジェクトの作成 まず、プロジェクトを作成するところから始めます。プロジェクトの作成はVisual Studio Codeから作成します。 プロジェクトの作成(1/5) プロジェクトの作成(2/5) プロジェクトの作成(3/5) プロジェクトの作成(4/5) プロジェクトの作成(5/5) Evidenceのウェルカム画面 プロジェクトを作成すると、Evidenceのサーバを起動可能になります。Evidenceのサーバを起動すると通常はポート1313で待ち受け状態になります。そうすると、Webブラウザで開けるようになります。ウェルカム画面は以下のようになります。 Evidenceサーバの起動 Evidenceサーバの起動はVisual Studio Codeから行います。コマンドパレットから起動できます。 データのインポート https://www.mhlw.go.jp/stf/covid-19/open-data.html から取得した、新規陽性者数の推移（日別）のデータをプロジェクトフォルダのsourcesにcovid19というディレクトリを作成して 配置します。新規陽性者数の推移（日別）のデータはnewly_confirmed_cases_daily.csvというファイル名なので、newly_confirmed_cases_dailyというテーブルとして識別されます。 データのインポートはEvidenceのサーバからやると、設定ファイルなどを簡単に作成できます。 データのインポート データのインポート (1/4) Evidenceのサーバのインポート画面ではインポート可能なデータ形式の確認ができます。 Evidenceでインポート可能なデータについてはEvidenceのWeb画面を起動したときのSettingsの中の画面で確認できる。 データのインポート (2/4) データのインポート (3/4) データのインポート (4/4) 現在Evidenceでインポート可能なもの BigQuery CSV Databricks DuckDB Microsoft SQL Server PostgreSQL Redshift JavaScript Snowflake SQLite Trino MotherDuck 最初のコンテンツの作成 最初のコンテンツの作成 (1/2) 次に、プロジェクトフォルダのpages/index.mdを編集します。index.mdはEvidenceのサーバに接続してデフォルトで表示されるページになります。ここのコンテンツを以下のようにします。 --- title: Welcome to Evidence --- ## Covid19 のCSV確認 ```sql covid19_10 select * from covid19.newly_confirmed_cases_daily limit 10 ``` <DataTable data={covid19_10}/> 最初のコンテンツの作成 (2/2) これにより、covid19.newly_confirmed_cases_dailyから10行取り出して表として出力されます。 ...

目的と対象読者 このドキュメントは、Windows環境を前提にEvidenceの利用方法について記述しています。Evidenceは様々な環境で稼働しますが、執筆時点での環境および設定を基準としています。 対象読者 Evidenceをはじめて利用する方 Windows環境でのセットアップ利用方法に関心のある方 前提条件 インストール済みのソフトウェア Visual Studio Code Git Node.js npm Node.jsのインストール方法 Scoopを利用し、執筆時点のLTSを利用しています。 Evidenceのバージョン バージョン 40.1.1をターゲットにしています。 Evidenceとはなにか 「Evidence」とは、Markdownで管理できるオープンソースのBI（ビジネスインテリジェンス）ツールです。 具体的には、レポート、意思決定支援ツール、埋め込みダッシュボードなどのデータプロダクトを構築するための オープンソースのフレームワークと説明されています。 Evidenceの主な特徴は以下の通りです。 コード駆動型BIツール:ドラッグ＆ドロップ式のBIツールとは異なり、コード（主にSQLとMarkdown）を使用してデータプロダクトを構築します。 Markdownで管理: Markdownファイル内でSQLクエリを記述し、コンテンツやレイアウトを管理します。 多様なデータソースに対応: データウェアハウス、フラットファイル（例：CSV）、非SQLデータソースなど、さまざまな種類のデータソースを扱うことができます。 SQLクエリの実行と結果の可視化: Markdownページに記載されたSQLステートメントに基づいてデータソースに対してクエリを実行し、その結果をグラフや表としてウェブサイトに出力できます。Markdown内で使用されるSQLはDuckDBのSQLです。 静的サイトの生成 出力は静的なウェブサイトとして生成されるため、デプロイや共有が容易です。npm run buildコマンドで静的サイトを生成し、S3などのホスティングサービスに格納して簡単に共有できます。 豊富なコンポーネント: クエリ結果に基づいて、さまざまなチャート（棒グラフなど）、表（DataTable）、大きな単一の値（BigValue）などのコンポーネントをレンダリングできます。 高度な機能: テンプレートページによる複数ページの生成、表示内容の制御のためのループやIf/Else文、クエリ結果のフィルタリング機能（Query Functions）なども備わっています。 Evidenceの適する用途 アーキテクチャなどを踏まえての説明は次回以降になりますが、Evidenceは様々な用途に利用可能です。基本的にはOn the flyのクエリーは困難なので、IoTなどの機器からのリアルタイムなダッシュボードには向きません。どちらかと言うと、日次・月次でしめるような処理が適します。従って、売り上げなどの分析が適すると思われます。