Merge pull request #79 from wedinc/fix/design-modification

Modify design and add sidebar
wedinc · Jun 27, 2024 · 219db72 · 219db72
2 parents 627d261 + 85a8ac9
commit 219db72
Show file tree

Hide file tree

Showing 19 changed files with 206 additions and 78 deletions.
diff --git a/assets/images/link.svg b/assets/images/link.svg
diff --git a/assets/styles/tailwind-customs.css b/assets/styles/tailwind-customs.css
@@ -0,0 +1,7 @@
+.sidebar-title {
+  @apply mb-4 text-stone-600 text-xl font-semibold font-manrope;
+}
+
+.sidebar-link {
+  @apply mb-4 ml-1 text-stone-600 hover:text-stone-400 text-lg font-medium font-manrope;
+}
diff --git a/components/Card.vue b/components/Card.vue
@@ -1,28 +1,38 @@
 <template>
   <NuxtLink
-    class="flex flex-col items-center bg-white border border-gray-200 rounded-lg shadow md:flex-row hover:bg-gray-100 dark:border-gray-700 dark:bg-gray-800 dark:hover:bg-gray-700"
+    class="flex flex-col h-auto md:px-10 px-6 py-6 rounded-2xl hover:bg-stone-200 md:border-2 border border-stone-500 hover:border-stone-700"
     :to="props.path"
   >
-    <img
-      class="object-cover w-full rounded-t-lg h-96 md:h-auto md:w-48 md:rounded-none md:rounded-l-lg"
-      :src="props.image ? `thumbnails/${props.image}` : 'wed-logo.png'"
-      :alt="props.title"
-    />
-    <div class="p-4 w-full leading-normal">
+    <div>
+      <p class="text-sm font-medium text-stone-500">
+        <time :datetime="$dayjs(props.date).format('YYYY-MM-DD')">
+          {{ $dayjs(props.date).format('LL') }}
+        </time>
+      </p>
       <h5
-        class="mb-2 text-2xl font-bold tracking-tight text-gray-900 dark:text-white"
+        class="md:mt-2 md:mb-4 mb-3 my-2 md:text-2xl text-lg font-semibold tracking-tight text-stone-700 font-manrope"
       >
         {{ props.title }}
       </h5>
-      <p class="mb-3 font-normal text-gray-700 dark:text-gray-400">
-        {{ props.description }}
-      </p>
-      <p class="mb-3 font-normal text-gray-700 dark:text-gray-400">
-        <time :datetime="$dayjs(props.date).format('YYYY-MM-DD')">{{ $dayjs(props.date).format('LL') }}</time>
-      </p>
-      <p class="mb-3 font-normal text-gray-700 dark:text-gray-400">
-        {{ props.author }}
-      </p>
+    </div>
+    <div class="flex flex-col md:flex-row">
+      <img
+        class="md:w-1/5 md:mb-0 mb-4 object-contain md:aspect-video aspect-auto"
+        :src="
+          props.image
+            ? `${!props.image.startsWith('/') && '/'}thumbnails/${props.image}`
+            : '/thumbnails/dummy-image.jpg'
+        "
+        :alt="props.title"
+      />
+      <div class="md:pl-8">
+        <p class="mb-3 text-base font-normal text-stone-700 line-clamp-3">
+          {{ props.description }}
+        </p>
+        <p class="text-sm font-normal text-stone-600">
+          {{ props.author }}
+        </p>
+      </div>
     </div>
   </NuxtLink>
 </template>

diff --git a/components/content/ProseA.vue b/components/content/ProseA.vue
@@ -4,7 +4,7 @@
     <img
       src="@/assets/images/link.svg"
       alt="External link icon"
-      class="w-3 m-0 ml-1 mb-1.5 inline align-bottom"
+      class="w-3 m-0 ml-1 mb-1 inline align-bottom"
     />
   </NuxtLink>
 </template>

diff --git a/content/2018-19-tech-timeline.md b/content/2018-19-tech-timeline.md
@@ -6,7 +6,7 @@ date: 2021-09-13
 image: 2018-19-tech-timeline.png
 ---
 
-# はじめに
+## はじめに
 
 僕らはONEとZero、dim.の3つのプロダクトを作っています。2018年に1人目のエンジニアとして入社してから、これまでどういった技術を使って、どういった技術的意思決定をしてきたかについて紹介していきます。前提として、エンジニア数人のスタートアップなので、コスパが良い選択をすることを心がけてきました。
 
@@ -16,7 +16,7 @@ image: 2018-19-tech-timeline.png
 
 [https://wow.one/app/](https://wow.one/app/)
 
-# 2018年
+## 2018年
 
 まずはONEリリース時（6/12）の技術スタックです。
 
@@ -44,7 +44,7 @@ Infra: Heroku
 
 metabaseでダッシュボードを作り、各々がSQLを書いて数字を見る文化がONEのリリース当初からありました。この文化は今も続いており、簡単なクエリなら自分で書ける人の方が多い組織になっています。
 
-# 2019年
+## 2019年
 
 ### 前半
 
@@ -93,7 +93,7 @@ Infra: GCP, Terraform, Fastly
 
 </aside>
 
-# 2020年
+## 2020年
 
 続きはこちらです。
 

diff --git a/content/2020-tech-timeline.md b/content/2020-tech-timeline.md
@@ -6,11 +6,11 @@ date: 2021-09-14
 image: 2020-tech-timeline.png
 ---
 
-# はじめに
+## はじめに
 
 [2018 - 19 WEDの技術のタイムライン](2018-19-tech-timeline.md) の続きになります。
 
-# 2020年
+## 2020年
 
 ### BigQueryでのデータウェアハウスの構築
 
@@ -69,6 +69,6 @@ ONEで利用しているOCRのマイクロサービスもONEに影響がでな
 
 </aside>
 
-# 最後に
+## 最後に
 
 2021年はSwift UIでの新しいプロダクトdim.を作ったり、Zeroの管理画面をリリースしたり、TV放映が増えたことでのリクエスト数の急激な増加に耐える対策などをしていっています。詳しくは別の投稿で書いていこうと思います。
diff --git a/content/20231116-log-analytics-using-ai.md b/content/20231116-log-analytics-using-ai.md
@@ -8,7 +8,7 @@ date: '2023-11-23'
 私は、「生成 AI によるユーザーの行動解析について」を聴講しました。
 行動データと生成AI、続いて生成AIから行動 Embeddings を作る、の内容でした。
 
-# 行動データと生成AI
+## 行動データと生成AI
 
 [Plaid](https://plaid.co.jp/) の [KARTE](https://karte.io/) では、訪問者の行動や感情をリアルタイムに解析し、一人ひとりに合わせたCXを実現するサービスを提供しています。
 その実現に、どのように生成 AI を組み込んでいくかの説明でした。
@@ -22,7 +22,7 @@ date: '2023-11-23'
 Plaid では、リアルタイムに行動データを分析し、適切なアクションを提供しています。
 この際、生成AIに対して、ユーザのコンテキストデータを提供することで、ユーザ行動分析の可能性を広げています。
 
-# 生成AIで行動 Embeddings を作る
+## 生成AIで行動 Embeddings を作る
 
 生成 AI でユーザ行動 Embeddings を生成、ベクトル演算を可能にしさまざまな分析・アウトプットにつなげます。
 
@@ -36,6 +36,6 @@ KARTE では、まず運営側で、基本的なユーザーの行動をプロ
 次に、ユーザーの行動をプロント化し、生成 AI を使って行動 Embeddings 化します。
 その結果、エンドユーザーの様々な Web 行動をイベントとして計測し、Context を抽出、検知した Context に応じて接客することが可能になりました。
 
-# 感想
+## 感想
 
 ONE でもユーザーからレシートを買い取っており、一連の購買情報から Content を作成し、そこから行動解析にもつなげられそうだなあ、と思いました。
diff --git a/content/android-ios-life-cycle.md b/content/android-ios-life-cycle.md
@@ -6,7 +6,7 @@ date: 2022-06-30
 image: android-ios-life-cycle.jpeg
 ---
 
-# はじめに
+## はじめに
 
 こんにちは。Android / iOS エンジニアの原田です。
 
@@ -17,119 +17,118 @@ image: android-ios-life-cycle.jpeg
 
 本記事は、そんなネイティブアプリの開発を学ぶ上で、一番基盤となるライフサイクルについて OS ごとに簡単にまとめてました。ぜひ、畑の違うプラットフォームについての翻訳書として、参考いただければと思います。
 
-# 対象者
+## 対象者
 
 - iOS のコードを読む Android 開発者
 - Android のコードを読む iOS 開発者
 
-# 前提
+## 前提
 
 - Android 側の解説は、 Activity よりも頻出であると考えられる Fragment を用います。
 - iOS 側の解説は、UIViewController を用います。
 - 執筆時点の環境は下記です。
     - Android 12
     - iOS 15
 
-# Fragment Lifecycle
+## Fragment Lifecycle
 
 Fragment の Lifecycle は下記のようになります。プロダクトの設計や実装方針によって気にするべき状態は変わってきますが、どういう状況であっても知っていた方がいいと考えるのは赤枠で囲んだ6つです。
 
 ![Blank board - Page 1 (5).png](<content/android-ios-life-cycle/Blank_board_-_Page_1_(5).png>)
 
-## onCreate()
+### onCreate()
 
 Fragment が生成された時に一度だけ呼び出されます。
 
 以降、Fragment が生存している限りは2回目が呼ばれることはありません。
 
-## onCreateView()
+### onCreateView()
 
 Fragment に表示する View を生成する時に呼び出されます。返り値として、表示する View のインスタンスを返却する必要があります。
 
 バックグラウンドからアプリを復帰させたり、別の画面へ遷移してからバックキーで戻ってきた場合など、画面を再表示するたびに呼び出されます。
 
-## onViewCreated()
+### onViewCreated()
 
 View が生成された後に呼び出されます。
 
 引数として、 `onCreateView` で返却した View が渡ってくるため、ここで View の表示内容や制御等の初期化を行うことが多いです。
 
 iOS 開発者に注意する点があるとするなら、**この時点では View のサイズが決定していない**ため、View のサイズを使って座標を計算したりすることはできません。もっと言うなら、Android には`viewWillLayoutSubViews()` のような状態はありません。実際に描画されるまで View のサイズを取得することができないので、状況によっては `ViewTreeObserver` などを使って描画を監視する必要があります。
 
-## onResume()
+### onResume()
 
 Fragment が表示されて、アクティブな状態になった時に呼び出されます。
 
 特に何か推奨される処理がある訳ではないですが、強いて言うなら画面が表示されたタイミングでしたいことがあればここで処理します。
 
-## onDestroyView()
+### onDestroyView()
 
 `onCreateView()` で生成した View が破棄される時に呼び出されます。
 
 具体的には、別の画面へ遷移した場合や、アプリをバックグラウンドにした時など、画面が見えなくなった時に都度呼び出されます。
 
-## onDestroy()
+### onDestroy()
 
 Fragment が破棄される時に1度だけ呼び出されます。
 
 Fragment が居なくなってしまうため、ここで任意の処理をさせたいと考えた場合、本当に必要な処理か、あるいは適切なタイミングか精査した方がよい印象です。
 
-# UIViewController Lifecycle
+## UIViewController Lifecycle
 
 UIViewController の Lifecycle は下記のようになります。こちらについても、採用する技術について気にするべき状態が大きく変わります。本記事では扱いませんが、xml で View を構築することが多い Android と比べて、iOS 開発では  Interface Builder や Swift UI と選択肢があるため、状況に応じて実装の作法が変わることがあります。
 
 とは言え、基本的な部分は一緒ではあるため、その中で理解しておいたほうがいいと考える状態は赤枠で囲んだ6つです。
 
 ![Blank board - Page 1 (7).png](<content/>android-ios-life-cycle/Blank_board_-_Page_1_(7).png>)
 
-## viewDidLoad()
+### viewDidLoad()
 
 View の階層構造が読み込まれた時に1度だけ呼ばれます。
 
 View に対する追加の初期化処理や、Xib ファイルの読み込み、AutoLayout(Android で近い概念は ConstraintLayout) での制約の指定はここで行われます。
 
-## viewWillAppear()
+### viewWillAppear()
 
 画面が表示される前に1度だけ呼ばれます。
 
 ここでは、View の表示に関わる追加の処理を実行します。[公式 Docs](https://developer.apple.com/documentation/uikit/uiviewcontroller/1621510-viewwillappear) に具体例が載っているので、ここではそのまま引用しておきます。
 
 > For example, you might use this method to change the orientation or style of the status bar to coordinate with the orientation or style of the view being presented.
-> 
 
-## viewWillLayoutSubViews()
+### viewWillLayoutSubViews()
 
 ViewController に表示する SubViews をレイアウトを決定する前に呼び出されます。
 
 画面のレイアウト処理に対して、もっともよく確認する部分です。AutoLayout で制約をつけられている場合はその限りではないですが、何かしらレイアウトに関する座標やサイズの計算をして配置する必要がある場合、必ずここで処理します。
 
-## viewDidLayoutSubViews()
+### viewDidLayoutSubViews()
 
 SubViews をレイアウトが決定した時に呼び出されます。
 
 もしも、レイアウトした SubViews に対して何か変更をしたい場合はここで処理することになります。
 
 代表的な例 かつ Android 開発者向けの注意点として、iPhone X 以降で導入された **safeArea はここ以降でないと取得できない**ため、マージン調整の処理をすることがあります。
 
-## viewDidAppear()
+### viewDidAppear()
 
  実際に画面が描画されて表示された時に呼び出されます。
 
 Android の `onResume()` と同様に、実際に画面が表示された時にしたいことがあればここで処理します。
 
-## viewDidDisappear()
+### viewDidDisappear()
 
 View が破棄された時に呼び出されます。
 
 こちらも Android の `onDestroyView()` に似ていて、別の画面へ遷移した場合や、アプリをバックグラウンドにした時など、画面が見えなくなった時に都度呼び出されます。
 
-# 最後に
+## 最後に
 
 今回は Android の Fragment 及び iOS の UIViewController それぞれで簡単にライフサイクルの紹介をしました。
 
 もっと細かい話をすれば、Android は Fragment と Activity の関係、iOS では ViewController と SubViews のレイアウトの順序など説明すべきことは沢山あるのですが、まずはそれぞれのプラットフォームを学ぶためのとっかかりとして活用していただければと思います。
 
-# 参考
+## 参考
 
 [https://developer.android.com/guide/fragments/lifecycle](https://developer.android.com/guide/fragments/lifecycle)
 

diff --git a/content/clean-architecture-completely-understood.md b/content/clean-architecture-completely-understood.md
@@ -110,7 +110,7 @@ SOLID の目的は
 
 どんなに優れたレンガを使っても組み立て方が悪いと、でたらめな家が出来上がってしまうので、その**組み立て方**に関する原則となる。
 
-# コンポーネントの原則 (Ⅳ部)
+## コンポーネントの原則 (Ⅳ部)
 
 ここで示す、コンポーネントとは、デプロイ単位のことである。
 
@@ -175,7 +175,7 @@ SRPをコンポーネントように言い換えたもの。
 
 システムには、いい依存と悪い依存がある。つまり、依存することが悪いというわけではなく、依存することで得られるメリットとのトレードオフを考える必要がある。
 
-# アーキテクチャ (Ⅴ部)
+## アーキテクチャ (Ⅴ部)
 
 アーキテクチャの目的は、システムのライフサイクルをサポートするもの
 

diff --git a/content/dynamic-view-test-tips.md b/content/dynamic-view-test-tips.md
@@ -10,23 +10,23 @@ image: dynamic-view-test-tips.jpeg
 
 今回は Android ONE で実際に実行している Espresso を使った UI テストの Tips を紹介しようと思います。
 
-# はじめに
+## はじめに
 
 Espresso は簡潔に UI テストを書ける非常に強力なライブラリです。しかし、実際に稼働しているプロダクトは非同期 かつ 動的に UI が変わるのが普通です。公式 Docs を読んだだけでは挙動が複雑な View に対して、どのようにテストを書けばいいか戸惑うことも多いかと思います。
 
 今回はそういったエンジニアに向けて、Espresso の Tips をまとめてみました。
 
-# 対象者
+## 対象者
 
 動的に表示内容が変わる View の Espresso テストを書くエンジニア 
 
 [https://developer.android.com/training/testing/espresso/basics](https://developer.android.com/training/testing/espresso/basics)
 
-# 実行環境
+## 実行環境
 
 Android Studio Chipmunk | 2021.2.1 patch 1
 
-# Test Libraries
+## Test Libraries
 
 2022/6/30時点の Stable Releaseを採用
 
@@ -36,7 +36,7 @@ Android Studio Chipmunk | 2021.2.1 patch 1
 
 [https://developer.android.com/jetpack/androidx/releases/test](https://developer.android.com/jetpack/androidx/releases/test)
 
-# Tips of Espresso Test
+## Tips of Espresso Test
 
 ## 1. 非同期に更新される View の場合