數碼時代的效率生活

0. 引言

目前,有太多的信息都以電子資料的形式存在,也有太多的工做和生活被綁定在線上。在這個連貨幣都立刻要數字化的時代裏,如何打理好本身的數字生活,保護好本身的數字資產,很重要。git

1. 需求分析

做爲一個非典型程序員和深度學習煉丹師,日常又會逛逛論壇,寫寫BLog,代碼文檔是最常要處理的兩類數字資料。
此外,業餘還喜歡拍照,大量的照片也須要妥善保管。程序員

總結核心需求以下:github

  • 資料在必要時較易實現本地化安全

  • 資料在必要時較易實現跨平臺遷移;服務器

  • 對於不一樣類型的資料,分場景進行保存和備份;markdown

  • 儘可能提升資料保存和備份的自動化程度。hexo

1.1 本地化

本地化的意思是指,我能夠把原始格式的資料拉取到本地磁盤上。這也是針對於雲服務愈來愈盛行的現狀所說。編輯器

在合理的場景中,在線化、上雲是大勢所趨,我也是擁護者和受益者。工做中,在須要協做的場景下,我已經不止一次地去推進如騰訊文檔、禪道等工具的使用,來取代老舊的Office式項目管理模式。工具

但對於須要積累和沉澱的資料,所有在線化,我是心懷擔心的。學習

我不怕被雲端綁定,但我怕被雲端綁架。

我但願可以享受雲端的便利,但在最壞的時刻,還有一個託底方案,可以把全部的原始資料掌握在本身手中。

1.2 跨平臺遷移

既然我不但願個人資料被雲服務器綁架,相似地,我也不但願個人資料被某一款軟件或系統所綁架。

舉例來講,我自認是一個喜歡整理和總結的人,但對於《印象筆記》這款號稱第二大腦的筆記軟件,我一直是採起迴避的態度。

它太封閉了,除非用一些黑科技手段,你很難把你存儲在裏面的資料原封不動地搬運出來。你使用得越多,你就被套牢越深。假若有一天它的系統崩潰,或公司倒閉,對你來講就是滅頂之災。這種頭懸利劍的感覺很很差。

再好比,一款經常使用的生產力工具,若是是某操做系統獨佔(MacOS,說的就是你),那我通常不會選擇用它,我會優先選擇Win/Linux/Mac跨平臺兼容的軟件。

目前,我在辦公室的工做終端是Win10,還有一臺Linux的遠程服務器,在家的電腦是Ubuntu。爲了保證單位和家之間的工做狀態無縫切換,工具的跨平臺兼容性很重要。

1.3 分類和自動化

代碼,文檔,數據,程序文件,照片等不一樣資料的存儲要求有很是大的差別。這主要從修改的頻率和資料自己的大小兩方面體現。

所以也就須要選擇不一樣的方案。我主要會從Git託管,網盤,NAS和移動硬盤四個方面去考慮。

自動化的需求主要是爲了對抗人的思惟惰性,若是一切都依靠繁瑣的手動操做,那麼極可能堅持不了多久。

2. 實現思路

2.1 我的知識庫

前面說過,我對於把本身稱爲「第二大腦」類型的軟件是迴避的。

但對於這種理念,我是十分贊同的,收集-整理-輸出,完整經歷這一過程,知識才能被更好地掌握。

只不過我願意多花費一點點時間和操做,本身來掌控這個流程。來實現前述的「本地化」,「跨平臺」等原則。

2.2 資料分類

通過分析,將資料按以下類別進行分類:

類別 特色
代碼/筆記/文檔 重要性高,修改頻繁,文本化
其餘文檔資料 多樣化,零碎
大致積數據 修改少,持久保存
  • 代碼、筆記、文檔:全部靠本身碼出來的文本類資料,含金量最高。全部特性都指向了一種最合適的保存方式,那就是Git。有保密要求的,託管在公司內網Git;無保密要求的,我會在Github/Coding等多個平臺同步託管。

  • 其餘文檔資料:工做/生活中有大量這類文檔,好比下載的各類論文/電子書,工做中的各類PDF/WORD/EXCEL,文件增刪較爲頻繁,但文件內容自己修改頻率並不高,這種時候,最合適的應該是同步盤工具。

  • 大致積數據:好比照片/視頻,大量的樣本數據,下載的視頻課程,一些須要保留的程序安裝文件等,基本沒有修改的需求,但須要持久保存,並方便隨時讀取。我置辦了一個小型的NAS,主要用於這類需求。只要能聯網,手機和電腦就能夠隨時隨地接入看網課或者翻看之前拍攝的照片和視頻。此外,每隔一段時間,我還會將整理過的照片/視頻在網盤上備份一次。

  • 最後,大概以每個月一次的頻率,我會將全部類型的資料在移動硬盤上備份一次,做爲最後的保險。

2.3 文檔/筆記

工程代碼和對應的文檔是工做產出要求,而在此之外的文檔和筆記,則是我的持續積累和提高的關鍵,這邊專門談一談。

對於我的文檔/筆記,我採用的是一種去中心化的方案。

說得更直白一點,我更傾向於用最傳統的本地文件夾方式來組織和管理,同時利用Git這樣的版本管理工具,實現文件的多端同步。

對於如今也很流行的標籤式管理體系,暫時沒有領會其精髓,在實際操做上每每也須要與系統或軟件強綁定。若是將來有第三方的工具可以進行這方面的加強,我可能會嘗試一下。

在遵循Git基本規範,操做得當的狀況下,全部的文檔會在我全部的電腦和多個遠程託管平臺上保持同步更新,以此達到:

  • 極高的標準化,一處編寫,多處使用;

  • 極高的安全性,由於同時損壞或丟失的狀況幾乎不可能發生。

3. 工具推薦

合理而順手的工具能夠大大提升工做效率和工做時的幸福感。我也很喜歡嘗試和折騰一些效率/生產力類型的工具。

爲了配合前面提到的全部指導原則和實施思路,下面推薦一些我用過或正在使用的工具。

3.1 Markdown及相應編輯器

大部分程序員應該都很熟悉Markdown。

不Coding可是有碼字需求的人,也強烈推薦嘗試一下。

這是一個用事後就再也回不去的神器。如非必要,我如今毫不會主動打開MS-Office,由於Markdown太好用了。

Markdown的優勢,我總結主要有如下幾點:

  • 純文本,簡單快速;

  • 兼容性高,格式統一;

  • 可以被git diff所識別。

缺點可能就是對於複雜的排版支持不夠。

歸納地說,就是方便寫文,特別是技術類文檔,但不方便寫書。

雖然說任何文本編輯器均可以用來寫Markdown,可是一個順手的寫做工具仍是可以提升效率和溫馨度。專門支持Markdown寫做的工具軟件有不少,這邊推薦三款。

3.1.1 VSCode

官方網址

同類型的還有Atom和SublimeText,它們本質上都是代碼編輯器,自身或者經過插件擴展,能夠實現Markdown的編輯功能。

但使用體驗來講,VSCode是最好的,而微軟官方的Remote系列插件,則完美符合個人使用需求,只此一項就秒殺了另外兩款。

做爲一個Vim盲的我,調試代碼時不再用本地編輯後,手動用SFTP上傳服務器運行了。

VSCode能夠兼容編碼和簡單的Markdown編輯需求,但體驗上跟專門的Markdown編輯器仍是有些差距,最主要體如今快捷鍵的支持範圍,以及插入圖片等附件時的便利性。若是想要真正體驗飛通常的輸入快感,你須要下一款。

3.1.2 Typora

官方網址

這個軟件在網上的口碑很是好,我本身使用的體驗也很棒,目前是個人主力編輯器。

將Markdown這種標記語言的特性和所見即所得的功能整合起來是它的特點。而對於插入圖片的操做優化,特別符合人的使用直覺,進一步下降了學習成本。

3.1.3 Mark Text

官方網址

Typora雖然目前無償使用,但它屬於閉源軟件,等正式版推出,估計會收費。若是軟件足夠好,我也是願意付費的,但本着保險起見的原則,我又搜尋到這樣一款開源軟件,幾乎完美實現了Typora的全部優勢。

Mark Text在一些細節上可能還須要打磨,但已經足堪大任。我目前在本身的Ubuntu系統中,就是使用的Mark Text。

3.2 Git及託管服務

3.2.1 Git

Git幾乎可算是現代程序員的必備技能。但用來作文檔的同步管理也是很是棒的,若是隻是我的用來管理文檔,不涉及分支和協做的話,Git其實很簡單,只須要用到很是有限的操做,並且目前也有足夠多的可視化工具能夠輔助。

3.2.2 Git託管服務

關於Git託管服務,公司內網的本地部署採用的是Gitea的方案。

公網的話,Github是繞不過去的。但鑑於某些緣由,Github的登陸不是很穩定,傳輸速度也很是感人,所以,我還會同時託管在CodingGitee上,鏈接穩定快速多了。

3.3 同步盤/網盤

3.3.1 堅果雲

堅果雲大概是目前國內惟一一款,免費用戶也能用得比較舒心的同步盤產品。

Win/Linux/Mac/Android/iOS/Web全平臺兼容。

平常辦公涉及的文檔資料,我都是經過堅果雲實現自動同步。只要注意一下不要把特別大的文件放到同步地址下,每月免費的上傳下載額度基本足夠使用了。

也有一些別的軟件支持同步盤,但功能都有些缺陷,好比不支持多個終端的同步,不能自由設置多個同步地址等,堅果雲仍是最好用的。

3.3.2 百度網盤

雖然不充會員就特別慢,可是彷佛也沒有其餘更通用的選擇了。聽說阿里雲也要出我的網盤了,但願能帶給咱們更多選擇。

3.4 NAS

目前用的不算標準NAS,是聯想出的一款我的雲存儲。當時買它主要是看中了便宜,首發期間有很大優惠,幾乎等於買機械硬盤送NAS。但也知足基本需求了。

後邊若是要升級的話,可能會考慮威聯通或者羣暉的產品。硬件方面的動手能力很弱,就不考慮DIY方案了。

3.5 其餘

再推薦一個本身用得比較順手,以爲頗有價值的工具。

3.5.1 Teambition

這本來是一個團隊項目管理工具,但其實用來作我的任務管理和平常生活的協做都很好。

還有一些其餘相似的在線工具,好比Trello,Worktile,Tower等能夠選擇。

(1)用於我的

我會把Teambition當作一個便籤和TODO-List來使用,用項目的方式分類管理起來。

好比把閱讀清單做爲一個項目,分爲「在讀/已讀/待讀」三個任務列表,每本書做爲一個任務,任務詳情中能夠記錄一些簡單的閱讀狀況。甚至看到一些精彩或有用的段落,經過截屏或拍照的方式,把圖片上傳在備註中,留待後期的進一步整理。把書看完後就能夠把任務置爲完成。

再好比把Blog寫做做爲一個項目,想到一個可寫的主題就列爲一個任務做爲備選,任務詳情中能夠隨時記錄一些點子和零散的資料。這樣,就能夠累積起很多素材。寫完成篇後就能夠把任務置爲完成。

自從用了這種方式,讀書的效率提升了很多,特別是把一本書讀完的機率提升了很多;而Blog的產出效率也提升了。

(2)用於家庭協做

家庭生活中,一些重大的事項其實也能夠看做一個個項目,我跟老婆通過一段時間的嘗試,也摸索出一種用項目管理的理念來提升生活條理性和規劃度的模式。

以前咱們還用過微軟的ToDo,簡單的協做也很不錯,好比購物清單,快遞備忘等,可是更復雜更長時間跨度的協做管理就感受有些力不從心了。目前ToDo還在使用中,但僅限於這些短平快的備忘性質任務。

好比把家庭出遊當作一個項目,分爲「待出行/構想中/已出行」三個任務列表,每一次出遊做爲一個任務,任務詳情中能夠記錄出遊的各項細節狀況,好比目的地、住宿預訂、車票機票預訂、景點門票預訂等,還能夠把攻略和參考連接附上。回來後,在項目Wiki裏,還能夠寫遊記。

之後回顧起來很是清晰明瞭,甚至系統自動的統計報表功能,能夠幫你完成出遊的數據統計。

其餘好比買房/裝修,娃上學擇校等,均可以列爲項目,進行更有條理的規劃。

4. 關於寫做

看到過有人說,程序員都應該學會寫做,都應該去寫博客。話雖然說得絕對,但我以爲有道理。

代碼是一種語言,平常用語也是一種語言,只不過一個是要讓機器讀懂,一個是要讓人讀懂。而把語言和邏輯組織好,並表述清楚的能力,實際上是相通的。

而且,在必定規模的團隊協做項目中,使代碼可以讓人看懂,可能比讓機器看懂更重要。讓人看不懂的代碼,就算當時寫得再精巧再完善,沒法維護始終是致命傷,不說其餘人接手,就算做者本身,可能過一段時間也回憶不起來當時的解決思路。

以前折騰過一段時間的靜態博客工具Hexo,利用Github和Coding的Pages服務去生成我的博客網站。後來又玩過Hugo,也是一個相似的工具。如今回頭想一想,只是爲了知足本身動手摺騰的好奇心。像我這樣在社交媒體上的隱形人,自建站約等於零流量。不如迴歸一些較爲主流的平臺,省去維護的精力,用這個時間多寫幾篇帖子。

相關文章
相關標籤/搜索