深入探索R tibble包

tibble包其實就是將原本dpylr裡面tbl_df S3 class提取出來完善,而讓dpylr包更專注在data.fram資料的挪移操作。而tbl_df class 以S3的形式把data.frame包起來,以提供更好的展示能力和資料操作的方便性。
我們可以由三個方面來理解tibble包:
  1. tibble中有什麼function可以操作、tbl_df中有哪些method。
  2. 如何創建一個tibble data structure或是從傳統data.frame轉換
  3. 其操作上跟data.frame有什麼差別

tibble包中有什麼?

在tbl_df class其主要有四個base method,其實就是基於data.frame的基本操作,如[,[[,$等subsetting的操作,還有print的顯示改善。
而tibble包中提供很多function來操作變化tbl_df的資料結構。
  • add_row:直接新增資料到原有的數據中
  • all_equal:辨別兩個tbl_df是否相同
  • as_tibble:將data.frame轉換為tbl_df/tibble
  • enflame:      將atomic轉換成tbl_df
  • frame_data:使用row-wise的方式建立tbl_df,適合資料量小的操作
  • glimpse:       展示資料中的變數
  • has_name:展示資料中的名稱
  • is.tibble:   判定資料是否為tbl_df格式
  • tibble:          建立tbf_df資料格式

 

如何使用tibble

創建

創建的方式,跟使用data.frame類似,在資料量小時,也可以使用frame_data的方式來創建,可以格外的直覺。
screenshot.png

screenshot.png

 

轉換

基本上,就很像使用as.data.frame一樣,as_data_frame為as_tibble的別稱(alias),所以基本上是相同的。

screenshot.png

跟data.frame最大的差別

在操作tbl_df格式的資料和操作傳統data.frame最大的差別在於subsetting和printing上。tbl_df的邏輯其實就是要讓資料呈現簡單,另外,subset造成的資料格式轉化能消失,讓人盡量使用dplyr裡頭的方式。

tbl_df的subsetting還是個tbl_df,這點跟純data.frame不同,要小心。
screenshot.png

 

tbl_df的printing預設只呈現10行,但可以使用options來調整。
screenshot.png

 

 

閱讀參考 link

Docker指令筆記

Docker技術,在近年來逐漸被應用在建立很多生物資訊的環境上,Docker可以提供很好的環境隔離,很多生物資訊的軟件其dependency不同,常常會造成衝突問題,而Docker的出現剛好可以解決這樣得問題。尤其最近雲端計算領域的興起,造就docker的狂潮。

Docker官網裡面的documentation非常清楚,這邊簡單整理常用的幾個。

docker基本指令

 

screenshot.png

 

  • Docker環境訊息:info , version
  • 容器生命週期管理:create, exec, kill, pause, restart, rm, run, start, stop, unpause
  • 鏡像倉庫命令:login, logout, pull, push ,search
  • 鏡像管理:build, images, import, load, rmi, save ,tag, commit
  • 容器運維操作:attach, export, inspect, port, ps, rename , stats, top, wait, cp, diff
  • 系統日誌管理:events, history, logs

[閱讀筆記]從小工到專家 第二章 注重實效的途徑

原文:程序員修煉之道-從小工到專家

這時代很多領域都開始需要會寫程式來幫助其提高工作效率,已經不限於本科“計算機科學”的人了,而寫程式過了第一關基本語法的學習後,後多時候就是要培養好的思惟架構和技巧,如何讓自己在寫程式這件事情上事半功倍,絕對很重要。

這章提到如何提升編成效率的原則可以由下面的這句話總結:

“假如你做了,那麼你往後的效率會越來越好,因為…你沒有留給自己爛攤子,並且為自己的未來打造好的工具。”

兩個提升編成效率的要點分別是:

1. 不要重複 Don’t Repeat Yourself幫未來的自己打造好工具

2. 代碼的正交性(沒有給自己留爛攤子)

第一個提升自己編成效能的重點:不要重複
由不同脈絡下的重複行為來分類:

DRY:Don’t repeat yourself

a. 強加的重複 Imposed duplication

多多利用Snippet
常常我們在撰寫代碼或是分析時候,都會編著一些基本架構,像是日期、誰編的、分類等等,重複性的敘述,這邊往往可以藉由編寫簡單的過濾器、或是代碼生成器就可以解決。
           另外,編譯器都可以設定snippet等,第一手解決很多重複撰寫的問題。

文檔與代碼
          代碼的註解能精簡就精簡,不要註解很“簡單”的代碼。

b. 無意的重複 Inadvertent duplication

這邊指得是代碼撰寫時“設計”不良,所造成的重複,或是data model設計不好,造成後續引用或是修改時候會重複的緩存數據。
c. 無奈的重複 Impatient duplication

“欲速則不達時”我們就會把很多該參數化的代碼混過去,這樣造成後面無法簡單的去引用。
d. 開發者之間的重複 Interdeveloper duplication

在團隊合作開發時,要是沒有很好的策劃,容易重複開發“功能一樣”的模塊,這時候就會浪費時間。

第二個提升自己編成效能的要點:考慮代碼間的正交性

Eliminate effects between unrelated things

這點蠻好理解的,要撰寫的模塊之間彼此獨立,優點可以提高“往後”的生產效率,和降低開發風險,有一些小細節是可以注意的:

  1. 從一開始的設計就要抱持者layer by layer的概念
  2. 謹慎地挑選要引入的技術或是工具
  3. 讓代碼解離
  4. 避免全局數據的使用
  5. 模塊測試
  6. 文檔的撰寫(當你為代碼模塊撰寫文檔,要是這些文檔能輕易的單獨閱讀,當然代表這些代碼模塊之間是獨立的)

 

 

 

[閱讀筆記]從小工到專家:第一章 注重實效的哲學

原文書: 程序員修煉之道-從小工到專家

第一章的重點大概分成三個:
1. 軟件的熵
2. 細心地規劃自己的知識資產
3. 積極的交流

第一個重點便是要自律性的規劃自己要撰寫的軟件,可以套用在個人或是團體,在團體中更為重要,不然當專案越來越大的時候,“坑”也會越來越多,書裡面的提示蠻生動的:

Don’t Live with Broken Window!            ——提示四

 可能代表….你在代碼裡留了個“坑”,當別人要跟你的代碼相接的時候,就代表得往你的窗戶丟東西惹!

 

第二個重點將知識當作投資

雖然這道理很簡單,但要認真的態度去實現卻是困難的,可是在變化越快速的領域,似乎知識價值的漲跌也如同股票一樣,要小心配置規劃。最好要:

  • 定期投資
  • 多元化
  • 管理風險
  • 低買高賣
  • 重新評估和平衡

這幾點似乎可以當作一個循環來操作,定期的投資代表要適時規劃時間在做“學習”,而多元化則代表廣而淺的接觸,管理風險則是決定自己要學習什麼樣的東西,低買高賣的概念則是盡量讓自己所學的可以被“看到”,不管是自己想一個小計劃來實現,或是實際使用新學的東西在工作上,最後則是一段時間就重新評估一下整體的配置。所以想要成為專家,就要不停的“學到老活到老”。

第三個重點交流

我相信,被打量比被忽略要好   —–Mar West, Belle of the Nineties, 1934

裡頭的重點其實第一步是心態,要抱持者上面這句話的精神,不要龜縮,而實現上則是要注重溝通的技巧,裡頭提供一個很棒的小口訣WISDOM

W:你想讓他們知道什麼?讓他們學到什麼?
I:他們對什麼感興趣?
S:他們本身經驗多豐富?能否聽懂你說的話?
D:要透露多少細節?或是他們想知道多深?
O:對方適合知道這些嗎?
M:你如何讓他們想聽你說話

當然除了對交流對象事先了解很重要外,選擇對的時機對的溝通方式讓對方參與傾聽和回覆都是重要的技巧。