寫作總是難產?比起能力,更可能是態度問題

寫作總是難產?比起能力,更可能是態度問題
Photo Credit: Depositphotos

我們想讓你知道的是

我們對於「寫作」通常都是又恨又怕。但或許,問題出在眾人根本搞錯了面對「寫作」時該有的態度。

中國作家古典曾說過:「寫作是你影響力傳播最快的方式;寫作也是影響力放大效應百倍的方式。」《內容電力公司》一書中也有類似的論述,而該書更相信透過寫作與部落客的經營,人人都能透過內容生產而打造屬於自己的事業。

我想應該不會有人否認寫作的重要性,但重點在於「實踐」層面的難度。雖然從小我們就被義務教育逼著學習寫作,但少有人真的在結束學校教育後仍應用此技巧。不論是學校教育的陰影,或是每次舉箸提筆下的糟糕印象,我們對於「寫作」通常都是又恨又怕。但或許,問題出在眾人根本搞錯了面對「寫作」時該有的態度。

自由書寫術:不批評、輕鬆試才是好點子源源不絕的秘方

自由書寫術》是一本談論關於「自由書寫」寫作技巧分享的書籍。簡單來說,自由書寫類似於自己一個人的腦力激盪。透過特定時間內不間斷的盡情書寫,逼迫自己在快速寫作的同時,沒有機會批判所寫出的文字,而讓可能成為好點子的想法不會再一出現時就被「編輯」腦給抹殺。

該書的作者相信人們的腦中都有「創作」腦與「編輯」腦,顧名思義「創作」腦主管點子的發想,但多數時候好點子在萌芽階段時,就會被標準過高的「編輯」腦扼殺而胎死腹中。上述情況造成我們對於寫作的印象總停留在「靈感枯竭」、「下不了筆」的痛苦狀態,久而久之當然對「寫作」一事敬而遠之。

自由書寫書就是想透過抑制「編輯」腦,讓人們在書寫時處於一種隨性、輕快的狀態,一來可以降低自己對於「寫作」時的心理負擔而減低抗拒心態,二來讓寫作變成一種自然而然的自我對話過程。以下為《自由書寫術》書中對於自由書寫所強調的6大秘訣:

  1. 輕鬆寫:讓腦中的編輯不要去限制任何想法。
  2. 快速寫、不停寫:與1是類似的道理,讓腦中的編輯來不及修改點子。
  3. 限時:讓人可以在看得見目的地的前提下創作(較能專注)。
  4. 思考的寫:用腦袋思考的方式來寫作,而先不要管邏輯與通順等「說話的寫」之議題。寫作的目的在於與自己的對話,只要自己看得懂就好。
  5. 隨著想法寫:讓想法帶領你的筆觸,有點像是在做白日夢的感覺,聯想到什麼就讓筆觸跟隨就對了,不用特別限制。
  6. 轉個彎再寫:遇到寫不出東西時,可以透過審視前面寫過的東西,利用提出來的問題、反問等方式,例如「我在這裡為什麼會這樣想?」「倘若這件事為非會是什麼情況?」等方式,換個思考方式再來進行創作。

其核心的概念在於限時內(如15~20分鐘內)不間斷的持續書寫,先別急著批判自己的文字,而是用開會討論時brain storming的方式來看待。提出一百個點子而非一個,強迫自己不要去追求量少的完美,而是嘗試從各種想法、角度來切入寫作的主題,多多益善。

創作出來的文字可能有用,也可能就只是一些言不及義的無病呻吟,但這也沒有關係;重點就是要讓人習慣文字持續不斷從指尖中產出的感覺。天知道這些雜亂無章的爛點子中,說不定就隱藏著下一篇曠世巨作的想法起源;真的不要那麼急著批判自己,嘗試著享受當下創作的感覺。

或許這些SOP也一樣適合你?寫作技巧的養成

筆者在閱讀了《自由書寫術》後,嘗試著施行書中的建議後獲益良多,也整理出了自己在寫作時個人所發展出的幾項SOP原則。野人獻曝下與讀者們分享討論,以期望找到某些有參考價值的做法:

一、點子庫:在平日搜集靈感時,可以適時借用一些線上工具的輔助,如Evernote或Trello,幫助自己能夠快速地將隨性的想法記錄下來。像筆者這類型愛書成痴者,習慣在閱讀每一本書時都開一個屬於該書筆記的欄位,以方便將書中重點或閱讀啟發記錄在欄位中。這樣一來,下次再複習該書或是尋找同類型主題靈感時,便可以很快地從中汲取。

而更進一步的「點子庫」應用,則可將每種特定類型或主題(例如關於「教育」、「創業」的主題)的點子或文字(《自由書寫術》書中稱其為「思緒片段」),分門別類的歸檔起來,使同一主題相似的思緒片段聚集在一塊。未來若想進行相關主題的文章撰寫時,便可從同主題中的思緒片段中擷取,以現成的文字與想法作為文章寫作的起點。

二、先從架構開始:人們在創作時常常會有種誤解,認為寫作該是「一氣呵成」的事情。雖然在少數文思泉湧的情況下這的確可能發生,但多半時間在創作時,人們無法仰賴可遇不可求的「靈感」降臨。

因此勢必須要有套可依循的重複準則,而筆者自己則特別喜歡以打草稿作為動筆的開始。先針對要撰寫的主題進行發想,或是從上述曾經累積的「點子庫」裡找尋創意的起點。拼拼湊湊找出至少三個重點,再把它們按照邏輯的順序以及閱讀起來通順的陳述方式排列,以簡單地列出文章的大綱;在編輯此步驟時,若有想到歸屬於該架構下精彩的舉例或案例,也可以順手加入到大綱中。

Depositphotos_86972850_xl-2015
Photo Credit: Depositephotos

完成後可以很快的預想一下文章寫出來的模樣會是什麼、中間會不會有什麼不順暢以及閱讀體驗脫序的問題,這個步驟筆者通常會在大綱研擬完後過一陣子,讓腦袋放鬆一下後才進行,以確保心智的確能夠客觀的判斷問題所在。

三、將「創作」與「編輯」分開:同時想處理「創作」與「編輯」,便像是開車時同時踩著油門與剎車,會使腦袋當機。兩個工作在全速前進時,活化的是大腦不同的部位,因此難以同時進行。適當的做法是先任由自己天馬行空的「創作」,把「編輯」的部分等到下一次或是休息過後再次開工時再來進行。

有些人總是過度苛求自己創作的節奏,總想要一氣呵成的完成文章;但這種心態下往往會讓人壓力過大,反而更拖慢了整體創作的步調。適當的方式是,認清一篇文章只有在透過好幾次的修改後才有可能圓滿完成,而不用太苛求自己在簡單幾次下筆後就要有所產出。在筆者自己的經驗中,透過這種心態的正確建立後,反而更可從每次「創作」與「編輯」兩種不同目的的寫作形態中,得到更多的靈感而讓整體創作更為順暢。

四、養成每天固定的寫作習慣:這點是筆者目前仍比較難持續進行的習慣。確切的方式可以是每天固定自由書寫10~15分鐘,養成自己梳理想法的步驟;或是每天逼迫自己一定要完成500~1000字以上的創作,讓人習慣固定產出量的感覺。後者聽說是知名作家海明威奉行不渝的法則之一。

會想要養成這樣的原因很簡單,除了是要讓自己常常有動筆的習慣外,「抗拒心魔」、避免拖延症發作也是箇中的重要因素。當一件事情已經變成習慣以後,身體會自然記住那種感覺;這麼一來,每次提筆起來要創作時,就不需要再花費那麼多的大腦精力來逼自己寫作了。

總結上述所言,對於「寫作」一事所該擁有的正確概念,應是保持對創作的輕鬆及良好的印象,讓動筆成為與自己對話的一種方式,而不是一個在處理完一整天上班辛勞的瑣事後,仍要面對的身心靈殘酷考驗。如此一來,才能確保在寫作這條路上能夠持續地往下走,同時真正體會到書寫的樂趣。

建議有興趣嘗試文章所提及寫作方法的讀者,皆可從《自由書寫術》一書中得到更多想法的啟發,也歡迎同為創作同好的讀者們一起討論指教。

本文經周詣授權刊登,原文刊載於此

責任編輯:朱家儀
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡