ジジイが挑戦する初めてのZenn
この記事でわかること
ここに佇んでいる高齢者
- 1958生まれの健忘症と戦うジジイです。
- 昨日初めてZenn に登録しました。
- github は、git clone した経験はありますが、リポジトリ作成は初めてです。
- "AI は茶飲み友達になれるのか?"をドヨ~ンと考察しています。
- エンジニアでもないのに、勝手にお邪魔しています。
- よろしくお願いします。
Zenn登録に新しいGoogle account を用意すべきか?
日ごろCursor でお世話になっているClaude 3.5さんに聞いてみました。
> Claude さんの答え
- 技術的な内容を主に共有し、プロフェッショナルなブランディングを重視する場合は、新しいアカウントを作成することをお勧めします。
- 個人的な使用と専門的な使用を明確に分けたい場合も、新しいアカウントが適しています。
- しかし、アカウント管理の簡便さを重視する場合や、既存のアカウントが十分にプロフェッショナルな内容であれば、既存のアカウントを使用しても問題ありません。
- Google Voiceなどの仮想電話番号サービスを利用して、異なる電話番号を取得してください。
> Claude さんの答え
- 二段階認証: SMSの代わりに、認証アプリ(Google AuthenticatorやAuthy等)を使用することで、セキュリティを向上させつつ、電話番号の重複使用を避けることができます。
- 既存のアカウントを使用し、必要に応じてメールの振り分けや二段階認証の方法を工夫することで、プライバシーとセキュリティのバランスを取りましょう。
> ジジイの挙動
面倒です。好きにします。
なぜZenn はmarkdown ? HTMLの直打ちはできないのか?
> Claude さんの答え
- Zennがmarkdownを採用しているのは、その簡潔性、可読性、汎用性のバランスが技術記事の執筆に適しているためです。
- HTMLの直接入力を制限することで、セキュリティリスクを軽減し、コンテンツの一貫性を保っています。
- Markdownの制限はあるものの、Zenn独自の拡張機能によって多くの課題が解決されており、技術記事のプラットフォームとして最適な選択となっています。
> ジジイの挙動
承知いたしました。Markdown 勉強します。
非エンジニアにとって、github連携は敷居が高いのでは?
> Claude さんの答え
- GitHub連携は多くのメリットがありますが、非エンジニアにとっては確かに高いハードルとなる可能性があります。Zennとしては、これらの課題を認識し、より分かりやすいガイドやツールの提供、段階的な学習パスの設計などを通じて、非エンジニアのユーザーもGitHub連携のメリットを享受できるよう支援しています。
- 同時に、ウェブエディタなどの代替手段も提供し、ユーザーが自身のニーズと技術レベルに応じて最適な方法を選択できるようにしています。
a. Git の基本的な構造と関係性を示すダイアグラム
このダイアグラムは以下の概念を示しています:
- ローカルリポジトリ:あなたのコンピュータ上にある作業ディレクトリ
- リモートリポジトリ:GitHub上にあるプロジェクトの保管場所
- Push:ローカルの変更をGitHubにアップロード
- Pull:GitHubの最新の変更をローカルに取り込む
- Commit:ローカルでの変更を記録
b. Git の基本的な作業フローを示すシーケンス
最低限理解しておくべき用語と作業:
- リポジトリ(Repository):プロジェクトのファイルとその変更履歴を保存する場所
- クローン(Clone):リモートリポジトリのコピーをローカルに作成
- コミット(Commit):変更を記録する作業
- プッシュ(Push):ローカルの変更をリモートリポジトリに送信
- プル(Pull):リモートの変更をローカルリポジトリに取り込む
c. Git のmainブランチについて
- mainブランチ(または masterブランチ)は、プロジェクトの主要な履歴を表すデフォルトのブランチです。
- ローカルとリモート両方のリポジトリに存在し、通常、最新の安定版のコードや記事が含まれます。
この簡略化されたgitグラフは、mainブランチ上での連続したコミットを示しています。各コミットは記事の変更や追加を表します。
GitHub連携の基本的な流れ:
- ローカル環境で記事を作成または編集する
- 変更をステージングエリアに追加する(git add)
- 変更をコミットする(git commit)
- コミットをGitHubにプッシュする(git push)
- GitHubからZennに自動で同期される
この流れを理解し、繰り返し実践することで、GitHub連携を使用したZennでの記事管理の基本を習得できます。
> ジジイの挙動
まだ雲をつかむような話ですが、github も鋭意勉強します。
Github 連携は、Cursor でプレビュー画面を見ながらできるか?
> Claude さんの答え
以下の設定でCursor にZenn_CLIを導入し、ローカルでプレビュー画面を見ながら記事を執筆できます。
> ジジイの挙動
何とか記事作成(この記事)までたどり着けました。
いつものように手取り足取りありがとう。
AI アシストCursor、 本当にスゴイわ。
GitHubリポジトリとZennの記事機構を連結する手順は?
> Claude さんの答え
注: Zennのログインページ URL: https://Zenn.dev/
> ジジイの挙動
たぶんできたと思う。
実際に記事を公開したら成否がわかる?
記事編集でZenn_CLIを用いたgithub連携と、webエディタを併用するリスクは?
> Claude さんの答え
- コンフリクトについて:
- 記事AとBは、異なる方法で作成されていますが、Zennのarticlesディレクトリ内で共存します。
- 通常、ファイル名(スラッグ)が異なれば、直接的なコンフリクトは発生しません。
- タイトルが同じ場合:
- タイトルが同じでも、スラッグ(ファイル名)が異なれば技術的には問題ありません。
- ただし、ユーザー体験の観点から混乱を招く可能性があるため、避けるべきです。
- 記事Aの編集:
- GitHub経由では編集できません。WebエディタでのみAを編集できます。
- 記事Bの編集:
- ZennのWebエディタでも編集可能です。
- GitHub経由でも編集可能です。
- 記事BをWebエディタで編集後の再編集:
- Cursorで再編集したい場合、必ずしも再度git cloneする必要はありません。
- 代わりに、ローカルリポジトリでgit pullを実行して最新の変更を取得します。
- 注意点:
- WebエディタとGitHub経由の編集を混在させると、変更の競合リスクが高まります。
- 常に最新の状態を保つために、編集前に同期(pull/push)することが重要です。
- 可能な限り、一つの編集方法(GitHubまたはWebエディタ)に統一することをお勧めします。
> ジジイの挙動
内容の理解はイマイチですが、リスクがあることは承知しました。
Github連携で統一します。
Zenn_CLIを用いたgithub連携と、Cursorによる記事編集が非常に小気味よいですが、いくつか質問があります。
1. 記事タイトルとスラッグについて
> Claude さんの答え
Cursorに表示されているファイル名がハッシュ値のような形式であることは、記事管理の観点から問題があります。Cursorでの記事管理と編集において、Zenn Editorのプレビューを活用する方法が最も効率的な方法の一つです。次のような、対処方法を提案します。
> ジジイの挙動
了解です。
本来は、Zenn Editor で編集できれば、、
2. Zenn における画像の取り扱い、削除とリンク切れ
> Claude さんの答え
画像を削除できない仕様は、Zennプラットフォームの設計思想を反映しています。ユーザーは、この制限を理解した上で、画像の扱いに注意を払う必要があります。重要な変更や削除が必要な場合は、Zennのサポートに直接問い合わせることが推奨されます。
- 理由:
- コンテンツの整合性維持:
公開された記事の画像リンクが切れるのを防ぐ。 - システムの簡素化:
削除機能の実装や管理の複雑さを避ける。 - ストレージ管理の簡略化:
一度アップロードされた画像を永続的に保存することで、バックアップや復元プロセスを簡素化。
- 影響:
- 不要な画像が残る:
誤ってアップロードした画像や、使用しなくなった画像が残り続ける。 - トレージ使用量の増加:
長期的には、ユーザーごとのストレージ使用量が増加する可能性がある。
- 対策:
- 慎重な画像選択:
アップロードする前に、画像の必要性と適切性を十分に確認する。 - 外部ホスティングの利用:
重要でない画像や頻繁に変更が必要な画像は、外部の画像ホスティングサービスを利用する。
- ユーザーへの影響:
- 画像管理の慎重さが求められる。
- 一度アップロードした画像の差し替えには新規アップロードが必要。
> ジジイの挙動
了解です。
画像は慎重に、、
3. 画像に関する外部ホスティングの利用
> Claude さんの答え
外部ホスティングで画像を自己管理する方法は確かに有効な選択肢です。無料のオプションも含めて、画像の外部ホスティング方法をまとめます。
- GitHub:
- Issues: プライベートリポジトリで非公開利用可能。
- GitHub Pages: 公開リポジトリで静的サイトとして画像をホスト。
- レンタルサーバー:
- 既存のサーバーを活用でき、完全な管理が可能。
- 無料クラウドサービス:
- Google Cloud Storage: 5GB まで無料。
- Amazon S3: 12ヶ月間5GB無料(Free Tier)。
- Cloudinary: 基本プランで月間25クレジット(約2.5GB)無料。
- 専門画像ホスティングサービス:
- Imgur: 無料で使用可能、ただし公開設定に注意。
- ImageShack: 30日間無料トライアル後は有料。
- 推奨される方法:
- 少量の非公開画像: GitHub Issues
- 大量の画像、高度な管理: Google Cloud StorageやAmazon S3
- 簡単に始めたい場合: Cloudinary
- 既存のサーバーがある場合: レンタルサーバー
- 注意点:
- 外部サービスを使用する場合、サービスの継続性に依存します。
- 定期的なバックアップを取ることをお勧めします。
- 画像の最適化(圧縮、リサイズ)を行い、ストレージとバンド幅を節約しましょう。
これらのオプションを比較検討し、ご自身のニーズに最も適した方法を選択することをお勧めします。
> ジジイの挙動
了解です。
画像は著作権や肖像権など微妙なところがあるし、こまめにマネージメントできたほうがよいかも、、
まとめ
ジジイの記事は冗長でくどくなりましたが、Zenn の簡潔さは好感です。Zenn_CLI のサクサク感も良いです。昨日から触ってここまでできました。WP ではこうはいかないと思います。
Discussion