上篇《博客系统知多少：揭秘那些不为人知的学问（三）》介绍了博客协议或标准。本篇终章介绍设计博客系统有哪些知识点。
目次目次
記事が長いため、この記事は以下の4つの記事に分かれています。
- “ブログ”の前世
- 私のブログストーリー。
- ブログの聴衆は誰ですか？
- ブログの基本機能設計のポイント
- 4.1ポスト（Post）
- 4.2コメントComment
- 4.3カテゴリ
- 4.4タグTag
- 4.5アーカイブArchive
- 4.6ページPage
- 4.7 Subscribe
- 4.8バージョン管理
- 4.9テーマと個性
- 4.10ユーザーと権限
- 4.11プラグイン
- 4.12写真と添付ファイルの処理
- 4.13汚い言葉のフィルタリングとコメントのレビュー
- 4.14スタティック化
- 4.15通知システム
- ブログのプロトコルまたは標準
- 5.1 RSS
- 5.2 ATOM
- 5.3 OPML
- 5.4 APML
- 5.5 FOAF
- 5.6 BlogML
- 5.7 Open Search
- 5.8 Pingback
- 5.9 Trackback
- 5.10 MetaWeblog
- 5.11 RSD
- 5.12 Reader Viewビュー
- ブログシステムの設計とは？
- 6.1タイムゾーンは本当にUTCですか？
- 6.2 HTMLとMarkdown
- 6.3 MVCまたはSPA
- 6.4安全性は
- 結びの言葉
6.1 |タイムゾーンは本当にUTCですか？
UTCを使用した時間の保存は2020 年にはすでに一般的な慣行になるはずです。ブログシステムも同様です。私のブログのすべての時間データは最終的にUTCで保存されています。しかし、ブログには特別な点があります。読者のタイムゾーンでUTC時間を変換するのではなく、ブロガーのタイムゾーンで時刻を表示する必要があります。
これは技術的な理由ではありません。読者のタイムゾーンによって時間を表示してもコード爆発がありません。なぜなら、ブログの誕生の当初の意図は、個性を強調することであり、ブロガーがインターネット上で独自の表示スペースを持つことができるようにするためです。ブロガー自身の属性を強調することは非常に重要です。ブロガーのタイムゾーンは読者がブロガーの属性を理解できるようにするものです。したがって、本物のブログシステムはタイムゾーン設定オプションを与え、表示としてUTC時間を変換します。Word Pressと私のMoongladeブログシステムも同じです。ブログシステムは自動的に読者のタイムゾーンの時間を変換しません。これはあまり知られていないデザインですが、尊重されなければなりません。
興味深いことに、検索エンジンはブログ記事のタイミングをどのように理解するのでしょうか？UTC時刻を検索エンジンに伝えるだけで、ユーザーには表示されません。HTML 5のtimeタグのdatetime属性を使用するのは簡単です。HTML 5標準の普及後、検索エンジンはタグ内のコンテンツから意味を推測するのではなく、タグの種類を見てコンテンツの意味を判断することを好みます。
C#では、ToString“u”はUniversal sortable date/time patterを意味する。
<time datetime="@Model.PostModel.PubDateUtc.ToString("u")" title="GMT @Model.PostModel.PubDateUtc">@DateTimeResolver.GetDateTimeWithUserTZone(Model.PostModel.PubDateUtc).ToString("MM/dd/yyyy")</time>
上記の記事では、時間のHTMLは次のようになります。
<time datetime="2020-04-29 11:41:02Z" title="GMT 4/29/2020 11:41:02 AM"
>04/29/2020</time
>
6.2 HTMLとMarkdown
多くの技術者はブログシステムを書くときにMarkdownをエディタとして使用するのが好きですが、技術ブログだけであれば問題はありません。しかし、他の人のためのブログシステムを書いているなら、誰もがプログラマーではなく、誰もがMarkdownを愛するわけでもないことを覚えておいてください。
このような場合、WSIWYG HTMLエディタ（TinyMCEなど）が良い選択であり、HTMLエディタはMarkdownよりも高度な組版をサポートしています。MoongladeはHTMLエディタとMarkdownエディタの両方をサポートする。
保存文章内容到数据库时，Markdown 格式需要选择原始内容，而非生成的 HTML，因为还需要支持后续编辑。HTML 格式现在也不建议 encoding 存储，毕竟都已经 2020 年了，市面上的主流数据库都可以正确支持各种神奇的 Unicode，比如文章中突然出现个 emoji😂，而如果你使用了 encoding，就会像我的博客一样面临一些福报：https://github.com/EdiWang/Moonglade/issues/280。并且 encoding 和 decoding 的过程会影响性能。我的 Moonglade 博客系统也刚刚完成了去除 encoding 的改造。
6.3 MVCまたはSPA。
ブログシステムを書くコミュニティの多くのプログラマは、ブログを構築するためにSPAアーキテクチャを使用することを好み、MVCを軽蔑し、後進的だと感じています。飛行機はなぜまっすぐ飛ばないのか、航空会社は計画しないのか。これについては、以前のブログ記事“. NET Coreブログでのパフォーマンス最適化の教訓”で書きました。
2014 年以降、SPAの台頭により、Angularなどのフレームワークがフロントエンド開発の主流になりつつある。フロントエンドの応答性を向上させ、Webアプリケーションをネイティブアプリケーションのエクスペリエンスにできるだけ近づけるという問題を解決します。私は多くの友人から質問を受けました：なぜあなたのブログをAngularで書かないのですか？あなたが苦手ですか？
実はそんなに簡単ではない。実際には、私の仕事の主な内容はAngularを書くことです。. NET FrameworkのバックグラウンドのブログもAngularjsとAngular 2を使用しています。一連の練習の後、私のブログなどのコンテンツステーションはAngularの収益を使用していません。
当然のことながら、フレームワークを盲目的に選択する前に前提条件に注意する必要があります。SPAフレームワークはWebアプリケーションをターゲットとしています。アプリケーションは、Azure PortalやOutlookメールボックスのように、Webページをアプリケーションとして開発することを意味し、SPAはユーザーエクスペリエンスを向上させるだけでなく、開発コストを削減することができます。しかし、ブログはアプリケーションではなく、コンテンツベースのウェブサイトに属し、アプリケーションと言えば、ブログのバックグラウンド管理はアプリケーションであることができます。ブログのフロントデスクでのやりとりはコメントや検索だけなので、SPAはそのような仕事には向いていません。野菜を買いに行くようなもので、戦車を運転するより自転車に乗る方が便利です。
マイクロソフトの公式ドキュメントには、SPAを選択するときと従来のウェブサイトを選択するときの同じリファレンスがあります。
ブログのフロントデスクはまだMVCを選択しているもう一つの理由は、この記事の冒頭に“ブログの読者は誰ですか？”を思い出してください。私は10年間ブログを運営しています。統計によると、ほぼすべてのユーザーは検索エンジンから来ており、記事を見るためにクリックしてウェブページを閉じます。考えてみてくださいSPAが解決した最大の問題の1つは何ですか？ローカルのみをリフレッシュすることでフロントエンドのパフォーマンス（応答性）を向上させますか？検索エンジンからのユーザーは、ページを閉じる記事だけを見て、本当にSPAを使用してローカルな利点を更新するだけですか？ユーザーは記事を見るだけですSPAフレームワークを使用しますユーザーはナビゲーションやインタラクションなどの機能を含むフレームワーク自体のファイルの束をロードする必要がありますユーザーの99%は他の場所に行くことはありませんのでユーザーの1%だけのために巨大なフレームワークをロードする価値があります性能は向上したのか低下したのか？
MVCフレームワークは毎回サーバーサイドでレンダリングされた完全なHTMLを出力しますが、99%のユーザーが記事を読むだけでウェブページを閉じるため、99%のユーザーにとっては、SPAのセットよりもはるかに少ないリソースをロードする必要があり、より速く、よりSEOに優しいです。SPAは、フロントオフィスではなく、ブログのバックグラウンドでポータルを管理するのに最適です。
6.4安全にして
Operations Blogの長年にわたるバックグラウンド監視データによると、最も一般的な攻撃は完全自動の脆弱性スキャンツールです。彼らはdata.zip、wp-admin.php、gitディレクトリなどの一般的なセキュリティ侵害を要求したり、特定のブログシステムの既知の脆弱性を悪用したりします。目的は、サーバーを制御することです。ブログページにユーザーに対する悪意のあるコード（ランサムウェア、マイニングなど）を追加し、サーバー自体をマイナーに変えることもあります。
设计博客系统时，常用的安全对策可参考 OWASP（https://owasp.org/），但同时保留灵活性。例如，加入 JavaScript 的 CSP 时，请考虑正常博客用户可能需要添加三方统计插件（如 Azure Application Insights，国内的 CNZZ 等），请设计一定的黑、白名单或功能开关。
ほとんどのデザイナーは、ユーザー入力、すなわちブログの読者から保護することを知っており、入力の入り口は通常コメントと検索機能だけです。しかし、ブログのバックグラウンド管理におけるブロガーの入力も、必ずしもブロガー自身が操作しているわけではないので、予防する必要があります。例えば、ブロガーのアカウントが盗まれ、ハッカーがバックグラウンドでナビゲーションバーをハッカーのサーバーやlocal hostに用意されている素晴らしい機関にリンクさせると（はい、local hostが正常な人のコンピュータで動作しないとは思わないでください）、読者は深刻な影響を受けます。
バックグラウンドログインの認証に関しては、成熟したSSOを使用できるものはSSOを優先します。例えば、MoongladeはAzure Active Directory認証をサポートしているため、Microsoftなどのプロフェッショナルサービスを使用して認証を管理でき、アカウントのセキュリティ問題を最小限に抑えます。ユーザーがSSO環境を持っていない場合、ローカルアカウント認証にフォールバックします。3つのサービスを使用してセキュリティを書かないと思わないでください、誰もあなたが書いたロジックはハッキングされないと感じてください、あなたが世界のトップ牛でない限り、あなたが書いたシステムは3つのサービスよりもはるかに暗いです。
他の攻撃は通常、敵対的な陣営の退屈なプログラマーによって開始されます。例えば、スクリプトやツールを使用してブログシステムのURLを継続的に要求し、DDOSのようにサーバーを爆破しようとします。この退屈なブラシパーティーのために、ブログシステム設計者はURLエンドポイントのレート制限を追加するだけです。実際のDDoS攻撃では、クラウドアンチDDoSサービスまたはハードウェアDDoSファイアウォールのみが対処できます。
最后别忘了 OWASP 里没有的东西，博客的协议也会有设计缺陷，例如 pingback 可以用来 DDOS（https://www.imperva.com/blog/wordpress-security-alert-pingback-ddos/），也能扫描服务器端口（https://www.avsecurity.in/wordpress-xml-rpc-pingback-vulnerability/）
結びの言葉
優れたブログシステムを設計すると、細部は考慮する価値があります。これらのデザインは最初から正しく行うことはできませんが、長期的なブログ運営のデータに基づいて発見し、考える必要があります。市場は変化し、ユーザーの行動は変化し、標準は時代遅れになり、発明されるため、システムは進化する必要があります。
一見単純に見えるシステムでも、普通の通りでも、その背後には見えない完全なシステムがあります。電子商取引、テイクアウト、金融清算システムはより複雑であり、表面的に見たものから始めないでください。飛行機を作るように、紙飛行機と本物の飛行機は同じではありません。
技術者は何を使用する必要があるかを考えないでください、優れた製品はファッショナブルな技術で作られていませんが、最初にユーザーがどのように製品を使用しているかを分析し、最も適切な選択を行う必要があります。何かを成功させたい場合は、アイデアはテクノロジー自体に限定されず、市場、ユーザー行動を分析し、テクノロジーをより正確に選択し、適用することを学びます。
ここを読んでくれた読者に感謝し、質問や議論があれば、メッセージ交換を歓迎します。
** 次の記事は、主にブログシステムの設計知識ポイントを紹介します **
