標籤:

寫不一樣的內容

過去的幾個月里我寫作的主題越發偏向技術性的內容,這使得一些公眾號的老讀者感到不是很舒服,原本閑適時隨手翻看一眼的內容,變作需伏在案幾,細細琢磨的東西,甚至不寫上幾行代碼,運行斟酌一下,都搞不明白我在講什麼。每周發表文章那日,訂閱和取消訂閱數量便開始急劇波動,有時一篇文章在不少新讀者那裡討到了好彩頭,卻惹惱了更多的老讀者,一進一出,反倒掉了不少關注。我記得公眾號關注數量上萬的時候,後台給出的女性讀者的比例大概接近30%,如果未知性別的讀者有一半是女性,那這個比例應該超過30%,昨日我看了一下後台的數據,這比例已經降到了不到20%,可見波動之劇烈。

寫公眾號已經有一年多半,起初只是想寫點什麼,順便給自己的連載『途客圈創業記』尋個好去處,便開創了這個公眾號,所以文字雜而不精,涉及的內容五花八門,創業,管理,產品分析,技術,讀書,雞湯,無所不包,所幸讀者錯愛,知乎謬讚,上了幾次日報後,關注度便扶搖直上。在我飄飄然自我感覺良好之際熱心讀者點了句「知者不博,博者不知」,頓時惶恐。

文章貴專精,我開始學習捨得,收縮自己的寫作陣線。

雖然親手熬制的雞湯卻能捕獲大量的讀者,讀書/創業也是人民群眾喜聞樂見的專題,但我決定慢慢從這些內容中抽身而去,一來聊這些專題的作者實在太多,我即便視角再獨到(大言不慚),也很難脫穎而出;二來我期待通過寫作,能夠 learning by teaching,而這些專題我並非邊學邊教,所以對我自己的裨益並不很大。

捨棄了大部分內容方向,留下的就是管理,產品分析以及技術。泛泛地介紹一個產品,我做不過engadget,techrunch,36kr,所以對於產品分析這個方向,我將其和技術融合在一起,即便是介紹一個產品,我也會嘗試著分析其背後的技術,以技術為主。至於管理,雖然如今我並非身處管理崗位,但技術管理依然是我修習的方向,我也有大量的知識和經驗需要學習,所以這個主題我依然會寫。

一舍一留之下,「程序人生」的主力文章的方向便放在了技術和管理之上,而且,以技術為主,管理為輔,這樣讀者的定位也更加明確:他們是和我一樣的對技術和管理孜孜以求的程序員們。服務好了這樣的讀者,才對得起「程序人生」這個名稱。至於絕對的訂閱數量的多寡,我雖依舊關心,但並不刻意追求,所謂:寵辱不驚,閑看庭前花開花落;去留無意,漫隨天外雲捲雲舒。

前一段借著公眾號支持語音素材的東風,我嘗試做了六期的「圖窮匕見」的podcast,佔用時間不少,效果一般(閱讀量均遠低於同期的文章),況且與我聚焦的方向有所出入,所以這個內容無限期暫停,將來我也許會換一種形式重新做文字以外的探索(也許是MOOC,呵呵)。

接下來在寫作上我會更加聚焦,話題收得更攏一些,每隔一段時間會列個提綱發表出來,督促自己按照提綱內容撰寫文章。提綱所列內容一般是開放的主題 —— 它們並非全是我已經深入了解的內容,很多都是我一知半解,亟待進階的內容。其實讀過我近期es6系列,reactiveX系列文章的讀者應該能夠感覺到,那些文字是我在一邊學,一邊練的過程中總結出來的。

正巧10月份參加 aws re:invent 2015 時結識了 InfoQ 的 Mikey,他建議我在 InfoQ 開設專欄,這和我的想法不謀而合,某種程度上還能促使我在內容上少一分隨心所欲(隨波逐流),多一份嚴謹和認真。於是,接下來的多篇文章,在撰寫完成後,我會先發於 InfoQ,再轉載到公眾號與知乎專欄上。計劃中的內容分兩大部分:

技術

最近會先寫一系列AWS相關的文章,提綱如下:

  • 深入了解IAM和訪問控制:介紹IAM,並從IAM中感悟訪問控制之道。
  • 客戶端身份驗證的安全解決方案:介紹cognito。這是個我並不熟悉的領域,需要花時間學習。
  • Infrastructure as a code: CloudFormation:互聯網軟體的代碼和其運行環境是密不可分的,運行環境不該是一條條命令行,一次次滑鼠點擊構建出來的,而應該是受到版本控制的一行行代碼描繪出來的:它們可以被代碼創建,可以被代碼銷毀,可以被一次性創建出多個相同的運行環境,部署不同的版本。
  • 使用API gateway 和 lambda構建REST API:這個話題我雖然聊過,但還可以深入下去,以一個實際的application來探討其中的優劣。
  • S3:不僅僅是存儲:這是我正在撰寫的一篇文章,估計下周會發。等不及的讀者可以關注我尚未完成的 github repo: tyrchen/aws-team-dropbox。在這篇文章里,我會嘗試用 S3 創建公司內部的文件伺服器,保存員工私人/共享文件,並以類似dropbox的方式雙向同步。
  • 使用Kinesis流式處理實時數據:以一個實際的application來介紹如何使用Kinesis處理實時數據。
  • Dynamodb深度體驗:DynamoDB看似簡單,用起來則相當麻煩。本文將探討如何進行DynamoDB的資料庫(表)設計,如何使用 hash key / range key 使得查詢更方便快捷?如何緩衝對DynamoDB的突發讀寫,如何自動scale up / scale down。
  • 使用AWS CLI操作資源和自動化:AWS CLI是一個強大的工具,這篇文章會嘗試讓你放棄AWS mangement console這樣的GUI,而轉至AWS CLI進行絕大多數的資源配置和自動化工作。
  • 在AWS上進行Continuously Delivery:這是一個相當開放的命題,我也依然在探索之中。
  • 在AWS上運行團隊的IT系統:這篇文章會深入探討一個團隊如何在AWS上搭建完整的IT系統,從網路規劃,到AWS內部服務的搭建(directory service,WorkMail,WorkDocs,CodeCommit,CodeDeploy),再到各種第三方的IT服務的搭建(vpn,bug tracking,project management tool,wiki,CI/CD)等。構建好這些工具,一個互聯網創業團隊應該能夠正常運作了。(這篇文章可能會篇幅過長而不得不拆分成幾篇)
  • 日誌,監控以及可視化:介紹AWS對日誌,監控和可視化的支持工具,並且詳述第三方工具如何同CloudTrail一同協作。

這些文章並無前後依賴的關係,每篇都自成一體,因而我文章發出的順序和上述提綱的順序會有所出入。建議讀者若要跟隨文章來學習AWS,應該至少註冊了一個AWS賬號,事先閱讀過當期所介紹服務的簡介,並在AWS management console中嘗試使用過該服務。否則,閱讀的效果不會太好。

管理

在矽谷的日子裡,我時不時參加一些meetup,參加一些聚會,這些聚會有時會有工程師介紹他們團隊的文化和處世之道;我也會經常看各種有關創業團隊文化的文章/視頻,來充實自己的管理思想。以下是一些我打算撰寫的主題:

  • 持續改進(continuously improvement):敏捷的核心思想之一是持續改進,本文探討團隊如何進行持續改進,以及可用於持續改進的工具(思想)。
  • 深入解析Retrospective:retrospective是持續改進的一個重要工具。本文講述retrospective的主要流程,以及一個成功的retrospective所具備的要素。
  • 在公司內部推行開源項目開發模式:本文探討為何鬆散的開源軟體項目對開發者的吸引力有時候會大於公司內部的項目,以及如何在公司內部創建一種開源軟體開發的模式,提高軟體開發的效率和效能。
  • 構建experiment-friendly的公司文化:創新是需要不斷摸索的,一個公司的文化越有利於員工的探索,就會越有利於創新。本文介紹experiment-friendly的公司文化的意義,以及如何實施這樣的公司文化。
  • 技術領導者的職責:如題,不解釋。

上述技術文章和管理文章會穿插進行,如若能按照提綱寫滿 80% 的命題,相信對我自己,對讀者都是不錯的學習素材。

寫了許久,改了許久,抱歉發晚了。

以上。

如果您覺得這篇文章不錯,請點贊。多謝!

歡迎訂閱公眾號『程序人生』(搜索微信號 programmer_life)。每篇文章都力求原汁原味,北京時間中午12點左右,美西時間下午8點左右與您相會。


推薦閱讀:

創新不是運動,而是文化

TAG:迷思 |