動態網頁是下乙個要解決的難題。我們從資料庫中讀取資料，再用動態去渲染出乙個靜態頁面，並且快取伺服器來快取這個頁面。既然我們都可以用varnish、squid這樣的軟體來快取頁面——表明它們可以是靜態的，為什麼不考慮直接使用靜態網頁呢？作為乙個普通使用者，這是乙個很簡單的軟體。除了electron + node.js + react作了乙個140m左右的軟體，儘管打包完只有40m左右 ，但是還是會把使用者嚇跑的。不過作為乙個快速構建的原型已經很不錯了——構建速度很快、並且執行良好。
儘管這個介面看上去還是稍微複雜了一下，還在試著想辦法將鏈結名和日期去掉——問題是為什麼會有這兩個東西？
我們在我們資料庫中定義好了schema——對乙個資料庫的結構描述。在《編輯-發布-開發分離
》一文中我們說到了echeveria-content的乙個資料檔案如下所示：
我們都定義了這每篇文章的基本元素:
title
author
date
description
content
url即使我們使用nosql我們也很難逃離這種模式。我們定義這些資料，為了在使用的時候更方便。儲存這些資料只是這個過程中的一部分，下部分就是取出這些資料並對他們進行過濾，取出我們需要的資料。
儘管，我已經想了很多辦法去盡可能減少元素——在最開始的版本裡只有標題和內容。然而為了滿足我們在資料庫中定義的結構，不得不造出來這麼多對於一般使用者不友好的字段。如鏈結名是為了儲存的檔名而存在的，即這個鏈結名在最後會變成檔名：
repo.write('master', 'contents/' + data.url + '.json', stringifydata, 'robot: add article ' + data.title, options, function (err, data) );
that.refs.snackbar.show();
that.setstate();
}});
今天 ，仍然有很多人用word、excel來儲存資料。因為對於他們來說，這些軟體更為直接，他們簡單地操作一下就可以對資料進行排序、篩選。資料以怎樣的形式儲存並不重要，重要的是他們都以檔案的形式儲存著。
在控制台中執行一下man git你會得到下面的結果:
這個答案看起來很有意思——不過這看上去似乎無關主題。
不同的資料庫會以不同的形式儲存到檔案中去。blob是git中最為基本的儲存單位，我們的每個content都是乙個blob。redis可以以rdb檔案的形式儲存到檔案系統中。完成乙個cms，我們並不需要那麼多的查詢功能。
這些上千年的組織機構，只想讓人們知道他們想要說的東西。我們使用nosql是因為：
不使用關係模型
在集群中執行良好
開源無模式
資料交換格式
我想其中只有兩點對於我來說是比較重要的集群與資料格式。但是集群和資料格式都不是我們要考慮的問題。。。
我們也不存在資料格式的問題、開源的問題，什麼問題都沒有。。除了，我們之前說到的查詢——但是這是可以解決的問題，我們甚至可以返回不同的歷史版本的。在這一點上git做得很好，他不會像wordpress那樣儲存多個版本。
json檔案 + nginx就可以變成這樣乙個合理的api，甚至是執行方式。我們可以對其進行增、刪、改、查，儘管就當前來說查需要乙個額外的軟體來執行，但是為了實現乙個用得比較少的功能，而去花費大把的時間可能就是在浪費。
git的「api」提供了豐富的增、刪、改功能——你需要commit就可以了。我們所要做的就是:
git commit
git push
使用nginx前後端分離發布專案？
原理我就先不說了，直接上手 在右邊選擇download 我們選擇 nginx windows 1.14.1 然後會看到這樣乙個資料夾 我們可以用vscode開啟這個資料夾 然後開啟 conf nginx.conf檔案 找到server 把這server 裡的所有都注釋掉，然後新增這麼一段 如圖 li...
AE開發編輯功能
這個兄弟寫得太好了 資料編輯問題 在ae中資料的編輯是乙個重點，也是乙個難點。它包括的東西非常多，如 地物的新增，地物的修改，地物查詢，節點捕捉，地物的符號化等一系列的問題。熟練的使用地物編輯的功能，是開發乙個系統必須具備的條件。資料編輯問題解決得好壞直接決定著軟體是否操作方便。在這我只是寫一些相應...
開發程式 編輯編譯
作為乙個程式的開發者，首先在學習的過程中會接觸到的就是編輯 編譯兩大過程。對於這兩個過程，可以通過很多的方式實現 完成，因為現在來說 有很多的軟體就是針對這兩個過程來協助我們開發的。甚至有些的軟體還將這兩個過程的軟體整合，統一到乙個強大的軟體中供我們使用，但是本質上來說任何乙個程式的實現還是離不開編...