《精益創業》一書對 MVP 和迭代思維有比較好的講解，可以看看。
PS：有篇老外寫的關於 MVP 的文章不錯，其中的配圖被到處使用。可能需要翻牆：Making sense of MVP (Minimum Viable Product) - and why I prefer Earliest Testable/Usable/Lovable
Apache Flink 零基礎入門教程
https://mp.weixin.qq.com/s?__biz=MzAwNjM1ODkxNQ==&mid=2650891022&idx=1&sn=d6be0689f00c5d048b5d1764726488ce&chksm=80fb51e2b78cd8f4cc4676ea2ee84b330fb8893103fce617a5573e4d5f71e0b5b21c8b8299e8&scene=21#wechat_redirect
Ambari——大數據平臺的搭建利器
https://www.ibm.com/developerworks/cn/opensource/os-cn-bigdata-ambari/index.html
https://www.ibm.com/developerworks/cn/opensource/os-cn-bigdata-ambari2/
如何參與一個 GitHub 開源項目？
參與開源項目的最佳辦法就是加入到你正在使用的已有項目上來。
# 找項目
我們推薦你從已正在使用的或感興趣的項目開始。這裏有幾個很棒的地方供你參考：
GitHub Explore: 受歡迎和熱門的項目。
GitHub Stars: 被其他人star過的項目（指的是你自己庫的項目）。
GitHub Showcases: 一個能搜索相關庫的方法。
LayerVault News: .前端和設計相關的項目。
# 貢獻於一個項目
如果你發現了你正在使用的項目中的一個bug（但是你不知道怎麼去修復它），或對文檔有不解或對項目有疑問 — 那麼創建一個話題吧！
創建話題專業提示
1.在建話題之前檢查已有的話題：話題重複對雙方都無利，所以搜索整個正開放和已關閉的話題以檢查你遇到的問題是否已經有人解決了。
2.務必對自己的問題有清晰的認識：期望的結果是什麼？然而卻發生了什麼？ 詳細描述其他人如何重現該問題。
3.在像JSFiddle 或CodePen類似的平臺上重現該問題並給出問題demo的鏈接。
4.包含一些系統相關的細節，比如用的什麼瀏覽器、庫或操作系統及版本號。
5.在你的話題或在Gist裏貼出你的錯誤輸出或日誌。如果在話題裏貼出來，請用三個反引號``` 包圍起來使得能夠良好的呈現給大家。
# GITHUB深度之旅
learn-github-from-zero.pdf 百度網盤。ended
Git的最佳資料，關於 Git 看這幾份資料足夠了：
1. ProGit中文版：
https://git-scm.com/book/zh/v2
2. 廖雪峯的Git教程：
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
3. Git簡易指南：
http://rogerdudler.github.io/git-guide/index.zh.html
爲什麼阿里要禁用Executors創建線程池？
通過線程池複用線程有以下幾點優點：
-
減少資源創建 => 減少內存開銷，創建線程佔用內存
-
降低系統開銷 => 創建線程需要時間，會延遲處理的請求
-
提高穩定穩定性 => 避免無限創建線程引起的OutOfMemoryError【簡稱OOM】
ThreadPoolExecutor的構造函數共有四個，但最終調用的都是同一個：
public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime,TimeUnit unit,BlockingQueue<Runnable> workQueue,ThreadFactory threadFactory,RejectedExecutionHandler handler)
線程池執行任務邏輯和線程池參數的關係
# 總結：
-
FixedThreadPool和SingleThreadExecutor => 允許的請求隊列長度爲Integer.MAX_VALUE，可能會堆積大量的請求，從而引起OOM異常
-
CachedThreadPool => 允許創建的線程數爲Integer.MAX_VALUE，可能會創建大量的線程，從而引起OOM異常
這就是爲什麼禁止使用Executors去創建線程池，而是推薦自己去創建ThreadPoolExecutor的原因
CPU密集型 => 線程池的大小推薦爲CPU數量 + 1，CPU數量可以根據Runtime.availableProcessors方法獲取
IO密集型 => CPU數量 * CPU利用率 * (1 + 線程等待時間/線程CPU時間)
混合型 => 將任務分爲CPU密集型和IO密集型，然後分別使用不同的線程池去處理，從而使每個線程池可以根據各自的工作負載來調整
阻塞隊列 => 推薦使用有界隊列，有界隊列有助於避免資源耗盡的情況發生
拒絕策略 => 默認採用的是AbortPolicy拒絕策略，直接在程序中拋出RejectedExecutionException異常【因爲是運行時異常，不強制catch】，這種處理方式不夠優雅。處理拒絕策略有以下幾種比較推薦：
-
在程序中捕獲RejectedExecutionException異常，在捕獲異常中對任務進行處理。針對默認拒絕策略
-
使用CallerRunsPolicy拒絕策略，該策略會將任務交給調用execute的線程執行【一般爲主線程】，此時主線程將在一段時間內不能提交任何任務，從而使工作線程處理正在執行的任務。此時提交的線程將被保存在TCP隊列中，TCP隊列滿將會影響客戶端，這是一種平緩的性能降低
-
自定義拒絕策略，只需要實現RejectedExecutionHandler接口即可
-
如果任務不是特別重要，使用DiscardPolicy和DiscardOldestPolicy拒絕策略將任務丟棄也是可以的
如果使用Executors的靜態方法創建ThreadPoolExecutor對象，可以通過使用Semaphore對任務的執行進行限流也可以避免出現OOM異常
Java 8 Stream性能牛逼，你能給我舉例說明一下嗎？
Stream API的性能到底如何呢，代碼整潔的背後是否意味着性能的損耗呢？
# 結論
1、對於簡單操作，比如最簡單的遍歷，Stream串行API性能明顯差於顯示迭代，但並行的Stream API能夠發揮多核特性。
2、對於複雜操作，Stream串行API性能可以和手動實現的效果匹敵，在並行執行時Stream API效果遠超手動實現。
所以，如果出於性能考慮
1、對於簡單操作推薦使用外部迭代手動實現
2、對於複雜操作，推薦使用Stream API
3、在多核情況下，推薦使用並行Stream API來發揮多核優勢，
4、單核情況下不建議使用並行Stream API。
如果出於代碼簡潔性考慮，使用Stream API能夠寫出更短的代碼。即使是從性能方面說，儘可能的使用Stream API也另外一個優勢，那就是隻要Java Stream類庫做了升級優化，代碼不用做任何修改就能享受到升級帶來的好處。
簡潔又快速地處理集合——Java8 Stream（上）
https://www.jianshu.com/p/0bb4daf6c800?from=groupmessage
什麼時候計算
Stream 和集合的其中一個差異在於什麼時候進行計算。
一個集合，它會包含當前數據結構中所有的值，你可以隨時增刪，但是集合裏面的元素毫無疑問地都是已經計算好了的。
流則是按需計算，按照使用者的需要計算數據，你可以想象我們通過搜索引擎進行搜索，搜索出來的條目並不是全部呈現出來的，而且先顯示最符合的前 10 條或者前 20 條，只有在點擊 “下一頁” 的時候，纔會再輸出新的 10 條。
再比方在線觀看電影和你硬盤裏面的電影，也是差不多的道理。
外部迭代和內部迭代
Stream 和集合的另一個差異在於迭代。
我們可以把集合比作一個工廠的倉庫，一開始工廠比較落後，要對貨物作什麼修改，只能工人親自走進倉庫對貨物進行處理，有時候還要將處理後的貨物放到一個新的倉庫裏面。在這個時期，我們需要親自去做迭代，一個個地找到需要的貨物，並進行處理，這叫做外部迭代。
後來工廠發展了起來，配備了流水線作業，只要根據需求設計出相應的流水線，然後工人只要把貨物放到流水線上，就可以等着接收成果了，而且流水線還可以根據要求直接把貨物輸送到相應的倉庫。這就叫做內部迭代，流水線已經幫你把迭代給完成了，你只需要說要幹什麼就可以了（即設計出合理的流水線）。
Java 8 引入 Stream 很大程度是因爲，流的內部迭代可以自動選擇一種合適你硬件的數據表示和並行實現；而以往程序員自己進行 foreach 之類的時候，則需要自己去管理並行等問題。
一次性的流
流和迭代器類似，只能迭代一次。
如何理解Java8 Stream
lambda表達式
lambda表達式是Stream API的基石。
我們常常會看到這樣的代碼
Arrays.sort(new Integer[]{1, 8, 7, 4}, new Comparator<Integer>() {
@Override
public int compare(Integer first, Integer second) {
return first.compareTo(second);
}
});
上面這種寫法就是使用了匿名類，我們經常會使用匿名類的方式，因爲我們只運行一次，不想它一直存在。
上面的代碼寫着麻煩，但是轉換成下面這樣的呢？
Arrays.sort(new Integer[]{1, 8, 7, 4},
(first,second) -> first.compareTo(second));
把一些不必要的細節都屏蔽。對於這種只包含一個抽象方法的接口，你可以通過lambda接口來創建該接口的對象，這種接口被稱爲函數式接口。
lambda表達式引入了一個新的操作符：->,它把lambda表達式分爲了2部分
(n) -> n*n
左側指定表達式所需的參數，如果不需要參數，也可以爲空。右側是lambda代碼塊,它指定lambda表達式的動作。
需要注意的是如果方法中只有一個返回的時候不用聲明，默認會返回。如果有分支返回的時候需要都進行聲明。
(n) -> {
if( n <= 10)
return n*n;
return n * 10;
}
方法引用以及構造器引用
方法引用
有些時候，先要傳遞給其他代碼的操作已經有實現的方法了。比如GUI中先要在按鈕被點擊時打印event對象，那麼可以這樣調用
button.setOnAction(event -> System.out.println(event));
這個時候我想偷懶，我不想寫event參數，因爲只有一個參數，jvm不能幫幫我嗎?下面是修改好的代碼
button.setOnAction(System.out::println);
表達式System.out::println是一個方法引用，等同於lambda表達式x -> System.out.println(x)。::操作符將方法名和對象或類的名字分割開來，以下是三種主要的使用情況:
- 對象::實例方法
- 類::靜態方法
- 類::實例方法
前兩種情況，方法引用等同於提供方法參數的lambda表達式。比如Math::pow ==== (x,y) -> Math.pow(x,y)。
第三種情況，第一個參數會稱爲執行方法的對象。比如String::compareToIgnoreCase ==== (x,y) -> x.compareToIgnoreCase(y)。
還有this::equals ==== x -> this.equals(x),super::equals ==== super.equals(x)。
構造器引用
List<String> strList = Arrays.asList("1","2","3");
Stream<Integer> stream = strList.stream().map(Integer::new);
上面代碼的Integer::new就是構造器引用，不同的是在構造器引用中方法名是new。如果存在多個構造器，編譯器會從上下文推斷並找出合適的那一個。
Stream的特性
- Stream不是數據結構，不會保存數據。它自己不會存儲元素,元素可能被存儲在底層集合中，或者被生產出來。
- Stream操作符不會改變源對象,相反，他們會返回一個持有新對象的stream
- Stream操作符是延遲執行的，可能會等到需要結果的時候纔去執行。
一些網站，工具和資料
知識星球
Google Chrome
IntelliJ IDEA
插件推薦
|
Alibaba Java Coding Guidelines |
《阿里巴巴Java開發規約》掃描插件，讓你的編碼規範起來 |
github 教程： learn-github-from-zero，作者 stormzhang
一個高質量的技術社區
簡單來說就是一個刷題網站，裏面有各種類型的算法題目，每天做那麼一點，既能加強算法，也能保持編碼手感以及訓練寫白板代碼。
一個方便快捷的雲存儲平臺，可以用作些小項目的雲存儲，同時它爲所有用戶提供了免費的額度，是一個很適合個人使用的雲存儲平臺。
一個很好用的在線作圖網站，支持流程圖、思維導圖、原型圖、UML、網絡拓撲圖等，不過呢，免費版每個賬號只能新建 9 個文件，當然，如果不想花這個錢的話，作完一張圖之後保存到本地，然後重新作圖也是可以的。
有道雲筆記
代碼託管服務和工具：
國內服務：
- coding.net
- csdn
- 開源中國
國外服務：
- bitbucket（免費支持私有）
- gitlab
- github
成功大數據項目的路線圖
成功大數據的路線圖分爲六步：
第一步：確定對企業業務有重大影響的大數據用例和創新方向。
第二步：我們要制定基於大數據項目的詳盡的產品服務創新規劃。
第三步：要詳細瞭解大數據項目所需要的業務功能要求和選擇與之相匹配的技術。
第四步：就大數據項目帶來的商業利益在企業內部達成共識。
第五步：我們要選擇容易實現的目標入手，快速迭代研發、試錯、穩步推進。也就是說不要剛開始就要搞高大上、大而全的項目，因爲失敗的機率幾乎是百分之百，非常容易失敗，因爲預算太大，選的工具太複雜，調動的資源很多，很難一下子實現所有的目標，所以通常我們從一個曉得目標，容易實現的目標開始，這樣可以鼓勵士氣，錯誤犯在研發的初期，而不是在中期和最後，這個最重要。
第六步：做大數據項目和產品一定要挖掘和實現大數據能給我們帶來的特殊價值，這是其它的方法或者是其它類的數據做不到的，只有實現了這種特殊的價值，我們才能實現業務所需要的具體功能，不管是擴展市場的份額，或者是更精準的瞭解你的客戶需求，還是說你要增加邊際利潤率，或者是提高產品上市的速度，縮短研發週期，這些都是大數據可以做的。另外就是跨界創新，傳統企業可以通過大數據這個紐帶跟其他企業的業務結合起來。
十二個各個領域都包含的項目案列，小編都有搭建與設計視頻，有一定大數據基礎與工作經驗的朋友是可以根據視頻內容完成整個項目的搭建的。非常的實用！需要視頻的朋友，加入小編的java與大數據交流圈子615997810找羣主獲取視頻學習這些項目的搭建。下面就來給大家介紹一下這十二個項目主要的內容與領域的權重值：
1，離線數據處理：項目內容爲通過對網站訪問日誌的採集和清洗，結合數據庫中的結構化用戶數據，統計並展示網站的PV、UV情況，以對網站的運行情況進行監控。通過此項目，回顧並串聯前面講述的離線數據處理相關技術，如：FIune、Sqoop、Hive、Spark等，瞭解和掌握PB級數據離線處理的一般過程和架構。
2，流式數據處理：項目內容爲通過對數據庫交易數據修改的實時同步，監控網站實時交易情況，以提高網站交易情況監控的時效性，降低網站運行的風險。 通過此項目，回顧並串聯前面講述的實時數據處理相關技術，如：kafka、Spark、Streaning和HBase等，瞭解和掌握實時數據處理的一般過程和架構。
3，推薦系統：項目內容，基於公開數據庫的商品推薦，某大型互金公司產品推薦系統剖析， 通過對公司實際推薦項目的剖析和根據真實數據搭建推薦系統的實操演練，瞭解推薦系統的一般架構和常用算法。
4，搜索系統：項目內容，通過網站爬蟲爬取網站數據，然後基於KlastlcSeard和Klbana搭建一個完整的搜索系統。
5，系統運行情況儀表盤： 通過對網站訪問日誌的採集和清洗，結合數據庫中的結構化用戶數據，統計並展示網站的PV，UV情況，以對網站的運行情況進行監控。通過此項目，回顧並串聯前面講述的離線數據處理相關技術，如Flume，Sqoop，Hive，Spark等，掌握PB級數據離線處理的一般過程和架構。
6， 實時交易監控系統 ： 過對數據庫交易數據修改的實時同步，監控網站實時交易情況，以提高網站交易情況監控的時效性，降低網站運行的風險。通過此項目，回顧並串聯前面講述的實時數據處理相關技術，如Kafka，Spark Streaming和HBase等，掌握實時數據處理的一般過程和架構。
7，推薦系統理論與實戰： 講解推薦系統的相關背景，常用算法及通用架構；基於公開數據集從零構建一個電影推薦系統。通過對公司實際推薦項目的剖析和根據真實數據搭建推薦系統的實操演練，瞭解推薦系統的一般架構和常用算法
8，數據倉庫搭建理論與實戰： 講解數據倉庫搭建的方法論，常用建模理論；以互金公司數據倉庫搭建場景作爲切入，實例演示數據倉庫搭建過程及技術架構。
9，分佈式業務監控系統： 講解業務監控系統需求背景，基於大數據的技術方案；通過實例代碼搭建完整的業務監控系統
10，基於ES的日誌系統 ： 基於Flume，ElasticSearch等技術搭建系統日誌收集與查詢系統。
11，信貸需求預測系統： 以京東信貸需求預測競賽爲背景，實例講解數據挖掘項目中如何設計特徵，模型基礎，建模以及調參等。
12，用戶畫像系統 ： 講解用戶畫像系統的需求背景，基於大數據技術的解決方案；通過實例代碼演示用戶畫像系統的搭建。
已讀書目：
《數據產品設計》艾達。關注目錄即可。
《數據資產管理——盤活大數據時代的隱形財富》高偉
數據資產治理的三全：全景（場景）、全生命週期（時間）、全流程（空間）
開放組體系架構框架TOGAF。
當數據分析成爲一種搜索：
搜索式的數據分析能力，把數據分析的過程，變成尋求不同答案的過程，基於對現有數據的認識，通過一系列的假設、關聯、驗證，最終找到一個相對可靠的答案。
數據應用商店：交易數據產品、數據算法。
