一.匿名函數實現階乘
第一種寫法：
43 > F = fun(Func, 1) -> 1;
43 > (Func, N) -> N * Func(Func, N - 1) end.
#Fun < erl_eval.12.99386804 >
44 > F(F, 1).
1
45 > F(F, 2).
2
46 > F(F, 5).
120
第二種寫法：
52 > F = fun
52 > Fac(1) -> 1;
52 > Fac(N) -> N * Fac(N - 1) end.
#Fun < erl_eval.30.99386804 >
53 > F(5).
120
//--------------------------
function n(x) {
if (x < 2) {
return 1;
} else {
return x * n(x - 1);
}
}
//調用函數
alert(n(10))
二.js類與初始化
var Animate = function (dom) {
this.dom = dom;
this.startTime = 0;
this.startPos = 0;
this.endPos = 0;
this.propertyName = null;
this.easing = null;
this.duration = null;
}
三. let和const的區別
let與const都是只在聲明所在的塊級作用域內有效。
let聲明的變量可以改變,值和類型都可以改變,沒有限制.
const聲明的變量不得改變值,這意味着,const一旦聲明,就必須立即初始化,不能留到以后賦值.
四.優化圖片加載的方法
1.懶加載
2.在頁面載入的時候將頁面上的img標簽的src指向一個小圖片,把真實地址存放在一個自定義屬性中,可以data-src
如果為幻燈片、相冊等，可以使用圖片預加載技術，將當前展示圖片的前一張和后一張優先下載。
預加載，見下一章節
3. 如果圖片為css圖片，可以使用CSSsprite，SVGsprite，Iconfont、Base64等技術。
4. 如果圖片過大，可以使用特殊編碼的圖片，加載時會先加載一張壓縮的特別厲害的縮略圖，以提高用戶體驗。
5. 如果圖片展示區域小於圖片的真實大小，則因在服務器端根據業務需要先行進行圖片壓縮，圖片壓縮后大小與展示一致。
五.html5新特性
1.標簽語義化 如:hrader,footer nav section article aside detailes summary dialog
2.增強型表單 如:color date datetime datetime-local email month number range search tel time url week
3.視頻和音屏 如:audio video
4.Canvas繪圖 如:Canvas - 圖形 Canvas - 路徑 Canvas - 文本 Canvas - 漸變 Canvas - 圖像 SVG 與 Canvas兩者間的區別:
SVG 是一種使用 XML 描述 2D 圖形的語言。Canvas 通過 JavaScript 來繪制 2D 圖形。SVG 基於 XML，這意味着 SVG DOM 中的每個元素都是可用的。您可以為某個元素附加 JavaScript 事件處理器。
在 SVG 中，每個被繪制的圖形均被視為對象。如果 SVG 對象的屬性發生變化，那么瀏覽器能夠自動重現圖形。Canvas 是逐像素進行渲染的。在 canvas 中，一旦圖形被繪制完成，它就不會繼續得到瀏覽器的關注。
如果其位置發生變化，那么整個場景也需要重新繪制，包括任何或許已被圖形覆蓋的對象.
六.瀏覽器緩存
一、http緩存
1.http緩存是基於HTTP協議的瀏覽器文件級緩存機制。
即針對文件的重復請求情況下，瀏覽器可以根據協議頭判斷從服務器端請求文件還是從本地讀取文件，
chrome控制台下的Frames即展示的是瀏覽器的http文件級緩存
2.websql
websql這種方式只有較新的chrome瀏覽器支持，並以一個獨立規范形式出現，主要有以下特點
Web Sql 數據庫API 實際上不是HTML5規范的組成部分；
在HTML5之前就已經存在了，是單獨的規范；
它是將數據以數據庫的形式存儲在客戶端，根據需求去讀取；
跟Storage的區別是： Storage和Cookie都是以鍵值對的形式存在的；
3.openDatabase方法可以打開已經存在的數據庫，不存在則創建
var db = openDatabase('mydatabase', '2.0', my db', 2 * 1024);
openDatabasek中五個參數分別為：數據庫名、版本號、描述、數據庫大小
創建回調。創建回調沒有也可以創建數據庫。
4.indexDB
IndexedDB 是一個為了能夠在客戶端存儲可觀數量的結構化數據，
並且在這些數據上使用索引進行高性能檢索的 API。
雖然 DOM 存儲 對於存儲少量數據是非常有用的，
但是它對大量結構化數據的存儲就顯得力不從心了。
IndexedDB 則提供了這樣的一個解決方案。
IndexedDB 分別為同步和異步訪問提供了單獨的 API 。
同步 API 本來是要用於僅供 Web Workers 內部使用，
但是還沒有被任何瀏覽器所實現。異步 API 在 Web Workers 內部和外部都可以使用，
另外瀏覽器可能對indexDB有50M大小的限制，
一般用戶保存大量用戶數據並要求數據之間有搜索需要的場景。
5.cookie
Cookie（或者Cookies），指一般網站為了辨別用戶身份、
進行session跟蹤而儲存在用戶本地終端上的數據（通常經過加密）。
cookie一般通過http請求中在頭部一起發送到服務器端。
一條cookie記錄主要由鍵、值、域、過期時間、大小組成，一般用戶保存用戶的認證信息。
支持域名個數:
IE7以上
50個
4095B
Firefox
50個
4097B
Opera
30個
4096B
Safari/WebKit
無限制
4097B
6.localstorage
localStorage是html5的一種新的本地緩存方案，
目前用的比較多，一般用來存儲ajax返回的數據，加快下次頁面打開時的渲染速度。
7.sessionstorage
sessionStorage和localstorage類似，
但是瀏覽器關閉則會全部刪除，api和localstorage相同，實際項目中使用較少。
8.application cache
application cahce是將大部分圖片資源、js、css等靜態資源放在manifest文件配置中。
當頁面打開時通過manifest文件來讀取本地文件或是請求服務器文件。
離線訪問對基於網絡的應用而言越來越重要。
雖然所有瀏覽器都有緩存機制，但它們並不可靠，
也不一定總能起到預期的作用。HTML5 使用ApplicationCache
接口可以解決由離線帶來的部分難題。前提是你需要訪問的web頁面至少被在線訪問過一次。
使用緩存接口可為您的應用帶來以下三個優勢：
離線瀏覽 – 用戶可在離線時瀏覽您的完整網站
速度 – 緩存資源為本地資源，因此加載速度較快。
服務器負載更少 – 瀏覽器只會從發生了更改的服務器下載資源。
9. flash緩存
這種方式基本不用，
這一方法主要基於flash有讀寫瀏覽器端本地目錄的功能，
同時也可以向js提供調用的api，
則頁面可以通過js調用flash去讀寫特定的磁盤目錄，達到本地數據緩存的目的。
七.服務器主動推送信息到客戶端方式
1.Ajax輪詢所謂的Ajax輪詢，其實就是定時的通過Ajax查詢服務端，
客戶端按規定時間定時像服務端發送ajax請求，
服務器接到請求后馬上返回響應信息並關閉連接。
這種技術方式實現起來非常簡單，
但是這種方式會有非常嚴重的問題，
就是需要不斷的向服務器發送消息詢問，
這種方式會對服務器造成極大的性能浪費。
2.Comet Comet，基於 HTTP 長連接的 "服務器推" 技術，
能使服務器端主動以異步的方式向客戶端程序推送數據，
而不需要客戶端顯式的發出請求，目前有兩種實現方式：
1. 基於 AJAX 的長輪詢（long-polling）方式
2.基於 Iframe 及 htmlfile 的流（streaming）方式
iframe 是很早就存在的一種 HTML 標記， 通過在 HTML 頁面里嵌入一個隱蔵幀，
然后將這個隱蔵幀的 SRC 屬性設為對一個長連接的請求，
服務器端就能源源不斷地往客戶端輸入數據。
Comet實現框架:
CometD 目前實現 Comet 比較成熟， DWR 弱一些。
ICEfaces 更商業化，實現得很成熟。
Grizzly 是基於GlassFish ，也很成熟。CometD, DWR 開源性好。
3.websocket方式
WebSocket是HTML5開始提供的一種在單個 TCP 連接上進行全雙工通訊的協議。
WebSocket通訊協議於2011年被IETF定為標准RFC 6455，WebSocketAPI被W3C定為標准。
在WebSocket API中，瀏覽器和服務器只需要做一個握手的動作，
然后，瀏覽器和服務器之間就形成了一條快速通道。兩者之間就直接可以數據互相傳送。
八.git工作流程
1.分布式工作流程
同傳統的集中式版本控制系統（CVCS）不同，
Git 的分布式特性使得開發者間的協作變得更加靈活多樣。
在集中式系統中，每個開發者就像是連接在集線器上的節點，
彼此的工作方式大體相像。
而在 Git 中，每個開發者同時扮演着節點和集線器的角色——也就是說，
每個開發者既可以將自己的代碼貢獻到其他的倉庫中，同時也能維護自己的公開倉庫，
讓其他人可以在其基礎上工作並貢獻代碼。
由此，Git 的分布式協作可以為你的項目和團隊衍生出種種不同的工作流程，
接下來的章節會介紹幾種利用了 Git 的這種靈活性的常見應用方式。
我們將討論每種方式的優點以及可能的缺點；你可以選擇使用其中的某一種，
或者將它們的特性混合搭配使用。
2.集中式工作流
集中式系統中通常使用的是單點協作模型——集中式工作流。
一個中心集線器，或者說倉庫，可以接受代碼，
所有人將自己的工作與之同步。 若干個開發者則作為節點——也就是中心倉庫的消費者——並且與其進行同步。
集成管理者工作流:
(1).項目維護者推送到主倉庫。
(2).貢獻者克隆此倉庫，做出修改。
(3).貢獻者將數據推送到自己的公開倉庫。
(4).貢獻者給維護者發送郵件，請求拉取自己的更新。
(5).維護者在自己本地的倉庫中，將貢獻者的倉庫加為遠程倉庫並合並修改。
(6).維護者將合並后的修改推送到主倉庫。
3.司令官與副官工作流
這其實是多倉庫工作流程的變種。
一般擁有數百位協作開發者的超大型項目才會用到這樣的工作方式，例如著名的 Linux 內核項目。
被稱為副官（lieutenant）的各個集成管理者分別負責集成項目中的特定部分。
所有這些副官頭上還有一位稱為司令官（dictator）的總集成管理者負責統籌。 司令官維護的倉庫作為參考倉庫，
為所有協作者提供他們需要拉取的項目代碼。 整個流程看起來是這樣的(見 司令官與副官工作流。):
(1).普通開發者在自己的特性分支上工作，並根據 master 分支進行變基。 這里是司令官的`master`分支。
(2).副官將普通開發者的特性分支合並到自己的 master 分支中。
(3).司令官將所有副官的 master 分支並入自己的 master 分支中。
(4).司令官將集成后的 master 分支推送到參考倉庫中，以便所有其他開發者以此為基礎進行變基。
Figure 56. 司令官與副官工作流。
這種工作流程並不常用，只有當項目極為龐雜，或者需要多級別管理時，
才會體現出優勢。 利用這種方式，項目總負責人（即司令官）可以把大量分散的集成工作委托給不同的小組負責人分別處理，
然后在不同時刻將大塊的代碼子集統籌起來，用於之后的整合