1. 程式人生 > >CSDN博文週刊第一期 | 2018年總結:向死而生,為愛而活——憶程式設計青椒的戎馬歲月

CSDN博文週刊第一期 | 2018年總結:向死而生,為愛而活——憶程式設計青椒的戎馬歲月

CSDN每週都會產生大量的部落格文章,有一些優質的乾貨文章值得被更多人閱讀,分享。CSDN博文週刊會從過去一週博文中精心挑選一些優質文章來以饗讀者,陪伴大家度過一個愉快週末。

1、2018年總結:向死而生,為愛而活——憶程式設計青椒的戎馬歲月

悟以往已不見,知來者之可追。2018年就要這樣過去了,這已是我在CSDN寫下的第六篇年終總結。回首,2013年我感悟到《一萬年太久,只爭朝夕》;2014年本科畢業,我抒寫下《回憶大學四年的得與失》;2015年我放棄北上廣,選擇回到貴州,感嘆《無他,唯心向爾》和《再見北理工》;2016年我成為了一名大學青年教師(青椒),年終總結是《教書路的開啟,愛情味的初嘗》;2017年被借調到省發改委學習一年,我留下《人生百味,有你真好》。
2018年,我又寫點什麼呢?

孔子曾說“未知生焉知死”,古人亦云“置之死地而後生”,那我就寫一篇《向死而生,為愛而活——憶程式設計青椒的戎馬歲月》。這一年,依舊很辛苦,秀璋在困難和死寂中掙扎,數不清的加班,嘗不盡的酸甜;這一年,因為有愛,愛情、友情、親情、師生情,秀璋為愛而活,向陽而生,留下的片片精彩,都是屬於他和她的回憶。點此閱讀原文

2、大資料預測CSDN2018部落格之星評選結果

閒話不多說,我們直接用資料說話。(因為絕大多數同學都只是關心一下結果,後面再給大家演示資料是怎麼得到的)

按照CSDN的要求:

自薦方式如下:在評論中放上您的CSDN部落格地址、並進行簡要說明。
候選人自薦截止時間為2018年12月11日中午12點。則目前為止自薦參與人數807。

結果到底如何,點選檢視原文一探究竟

3、JetBrains開發者日見聞(一)之Kotlin/Native 嚐鮮篇

前段時間你們的熊貓小哥哥(也就是我),由於對Kotlin過度熱愛,一天偶然看到2018 JetBrains開發者日-Kotlin專場活動,腦袋一熱,瞬間心動了,馬上就買了門票和火車票去北京(第一次一個人去北京)參加活動了。因為看到有Kotlin中文社群兩位大佬(這兩位大佬是我一年多以前開始寫Kotlin的時候就關注了他們)的演講日程以及JetBrains資深佈道師Hali的演講,沒有過多思考直接買票,不要慫就是幹。最後順便和Kotlin社群的大佬們面個基啥的,謝謝大佬們的熱情款待。此次北京之行收穫挺多的,有時候知道一些最新技術方向和動態會比你埋頭閉門造車好的很多。

所以總結了一下結合自己實際的開發,給大家帶來以下幾篇文章。

1、Kotlin/Native1.0 Beta(嚐鮮篇)
2、Kotlin中1.3版本新特性都有哪些?
3、Kotlin中的Coroutine(協程)在Android上應用(協程學前班篇)
4、Ktor非同步框架初體驗(Ktor學前班篇)

點選檢視原文,獲取博主更多Kotlin乾貨

4、Golang-Scheduler原理解析

本文主要分析Golang裡面對於協程的排程原理,本文與Golang的memory allocation、channel、garbage collection這三個主題是緊密相關的,本文scheduler作為系列的第一篇文章。
文章大體上的思路是這樣的:
section1:主要圖示和文字介紹scheduler的原理;
section2:主要模型的角度介紹scheduler原理;
section3:從主要排程流程介紹scheduler原理;
section4:分析scheduler與memory allocation、channel、garbage collection關聯部分
基於原始碼 Go SDK 1.11

檢視更多Golang語言乾貨,點選作者部落格主頁學習

5、Person Re-ID相關知識點、資料集及評估指標總結

人臉識別技術目前已發展的較為成熟,在很多場景與產品中都已有落地的應用,但人臉識別技術只能用到人體的人臉資訊,而人體的其他重要資訊得不到充分的利用,例如:衣著、姿態、行為等。另外在應用時必須要有清晰的人臉正面照片,但在很多場景下無法滿足要求,例如低頭、背影、模糊身形、帽子遮擋等等。

行人重識別(Person Re-ID)技術正好能夠彌補人臉識別的這些不足之處,行Person Re-ID能夠根據行人的穿著、體態等資訊認知行人,對行人目標進行跨攝像頭跟蹤。這將AI的認知水平提高到一個新的階段,現在Person Re-ID已成為AI領域的重要研究方向。點選閱讀原文

6、Tensorflow資料讀取機制及tfrecords高效讀取資料

假設我們的硬碟中有一個圖片資料集0001.jpg,0002.jpg,0003.jpg……我們只需要把它們讀取到記憶體中,然後提供給GPU或是CPU進行計算就可以了。這聽起來很容易,但事實遠沒有那麼簡單。事實上,我們必須要把資料先讀入後才能進行計算,假設讀入用時0.1s,計算用時0.9s,那麼就意味著每過1s,GPU都會有0.1s無事可做,這就大大降低了運算的效率。

如何解決這個問題?方法就是將讀入資料和計算分別放在兩個執行緒中,將資料讀入記憶體的一個佇列,如下圖所示:
在這裡插入圖片描述

讀取執行緒源源不斷地將檔案系統中的圖片讀入到記憶體佇列中,而負責計算的是另一個執行緒,計算需要資料時,直接從記憶體佇列中取就可以了。這樣就可以解決GPU因為IO而空閒的問題!點選閱讀原文

7、Android官方架構元件ViewModel:從前世今生到追本溯源

2017年的Google I/O大會上,Google推出了一系列譬如 Lifecycle、ViewModel、LiveData等一系列 更適合用於MVVM模式開發 的架構元件。

本文的主角就是 ViewModel ,也許有朋友會提出質疑:

ViewModel 這麼簡單的東西,從API的使用到原始碼分析,相關內容都爛大街了,你這篇文章還能翻出什麼花來?

我無法反駁,事實上,閱讀本文的您可能對MVVM的程式碼已經 駕輕就熟,甚至是經歷了完整專案的洗禮,但我依然想做一次大膽地寫作嘗試—— 即使對於MVVM模式的思想噗之以鼻,或者已經熟練使用MVVM,本文也儘量讓您有所收穫,至少閱讀體驗不那麼枯燥。點此閱讀全文

8、從原始碼角度分析android事件分發處理機制

和攔截處理機制詳解一樣,為了系統的研究Android對事件的處理,我寫了一個小demo對不同的情況進行測試並結合原始碼分析(多說一句,其實看原始碼確實很枯燥,有時候因為水平有限有的部分看不懂而查閱大量資料,笨人有笨法:結合demo測試驗證和理解,雖然效率低但是效果不錯),可以得出如下的結論(至於結論的由來,下面會說明):

1)android對事件分發的順序為:Activity–>PhoneWindow->DecorView->yourView;

2)android控制元件對事件處理的優先順序:onTouch>onTouchEvent>onClick

點選閱讀原文

9、Flutter專案結構及demo程式碼詳解

在之前的部落格中我們搭建了Flutter的開發環境,並且建立了一專案,專案預設就生成了一些程式碼,學習任何語言第一步一般都是從入口函式著手,然後一步一步往下走。
本篇部落格我們就以預設生成的專案為準,著重的介紹一下Flutter專案的目錄結構及程式碼詳解。點此閱讀原文

10、React Native Android混合開發實用教程

在React Native的應用場景中,有時候一個APP只有部分頁面是由React Native實現的,比如:我們常用的攜程App,它的首頁下的很多模組都是由React Native實現的,這種開發模式被稱為混合開發。

作者部落格裡還有一篇 React Native iOS混合開發實用教程,一併分享給大家。

11、讓你可以裝逼的演算法技巧總結

今天和大家講講,在做演算法題時常用的一些技巧。對於平時沒用過這些技巧的人,或許你可以考慮試著去看看在實踐中能否用的上這些技巧來優化問題的解。

程式設計師學點演算法總是好的,快速前往檢視原文

12、手把手教你如何玩轉Shiro(專案實踐落實)

shiro框架是一個許可權管理開源框架,也是非常容易整合的。在之前的博文中,我對許可權管理,shiro基本知識,spring整合shiro等相關處理都進行了非常詳細的講解。點選閱讀原文

13、從一個簡單需求學習微服務思想

從一個案例來看,如何在做架構設計時利用微服務的思想來幫我們解決問題。公司對產品服務的管理目前還停留在物理機的那種理念,雖然阿里雲、AWS、騰訊雲、OpenStack等雲平臺用的不亦樂乎,但仍然停留在針對hostname和ip的管理上。如果想釋出一個新版本,需要將設計到的所有機器的ip整理到一起,然後藉助Ansible將產品更新上去。點選閱讀原文

14、搭建Elasitc stack叢集需要注意的日誌問題

搭建Elasitc stack叢集時,我們往往把大部分注意力放在叢集的搭建,索引的優化,分片的設定上等具體的調優引數上,很少有人會去關心Elasitc stack的日誌配置的問題,大概是覺得,日誌應該是一個公共的問題,預設的配置應該已經為我們處理好了。但很不幸,在不同的機器配置或者不同的運營策略下,如果採用預設的配置,會給我們帶來麻煩。點選閱讀原文。

15、如何通過 Matplotlib 繪製動畫及儲存 GIF 圖片?

在自學機器學習或者是深度學習的過程中,有的時候總想把執行過程或者執行結果顯示出來,所以就想到了動畫。好在用 Python 實現動畫有許多中方式,而大家熟知的 Matplotlib 庫就可以實現。

本文的目的是對 Matplotlib 的動畫實現手段做一個簡單的說明。點選閱讀原文

16、華為KubeEdge在邊緣計算的實踐

在本文中,我們為Edge-cloud通訊和執行環境引入了Edge基礎架構(KubeEdge),我們將其視為雲基礎架構的擴充套件。此邊緣基礎架構允許Edge採用現有云服務和雲開發模型,並提供邊緣和雲之間的無縫通訊。KubeEdge包括一個名為KubeBus的網路協議棧,一個分散式邊緣元資料儲存/同步服務和一個應用程式編排服務。KubeBus旨在擁有自己的OSI第2/3/4層協議實現,支援將雲端的邊緣節點和虛擬機器連線為一個VPN,併為不同租戶的邊緣叢集提供通用的多租戶管理/資料平面。在Cloud和Edge中執行的服務在KubeBus之上相互通訊,具有容錯性和高可用性。KubeEdge中的Edge元資料服務提供邊緣元資料儲存和服務,以在雲和Edge之間同步元資料,以支援邊緣節點離線方案。KubeEdge包括Kubernetes 擴充套件,以便Kubernetes可以管理Edge Nodes以及Cloud中的VM,並部署/管理Edge Nodes的應用程式。點選閱讀原文

17、React Native JSBundle拆包之原理篇

RN作為一款非常優秀的移動端跨平臺開發框架,在近幾年得到眾多開發者的認可。縱觀現在接入RN的大廠,如qq音樂、菜鳥、去哪兒,無疑不是將RN作為重點技術棧進行研發。

不過,熟悉RN的開發者也知道,早期的RN版本中打出來的包都只有一個jsbundle,而這個jsbundle裡面包含了所有程式碼(RN原始碼、第三方庫程式碼和自己的業務程式碼)。如果是純RN程式碼倒沒什麼關係,但大部分的大廠都是在原生應用內接入RN的,而且一個RN中又包含許多不同的業務,這些不同的業務很可能是不同部門開發的,這樣一個庫中就有許許多多的重複的RN程式碼和第三方庫程式碼。

所以,一般做法都是將重複的RN程式碼和第三方庫打包成一個基礎包,然後各個業務在基礎包的基礎上進行開發,這樣做的好處是可以降低對記憶體的佔用,減少載入時間,減少熱更新時流量頻寬等,在優化方面起到了非常大的作用。點選閱讀原文


更多精彩博文,歡迎訪問[CSDN博文主頁](https://blog.csdn.net/),如果您的博文思路清晰、內容乾貨十足或者是分享程式趣事,職場有料等,歡迎投稿。

在這裡插入圖片描述