於IDE做同儕代碼審查

原文 : Peer Code Review from IDE      by Maria Khalusova
ESAST CO LTD嵌藝創研軟體科技為JetBrains台灣經銷, JetBrains授權翻譯

IDE 是大多數人習慣在上面處理編碼的環境,在上面做修改或瀏覽編碼基底。  但我們每天例行工作不只是編碼, 還要面對許多協作活動與任務。  一般來說我們會轉到另一個工具來處理這些事, 例如我們到事件追蹤工具討論瑕疵和功能。 基本上我們把編碼與討論分開。  但是–代碼審查–是這兩樣必須並行。  本質上這是團隊的協作實踐, 但在IDE外部來處理編碼修改會讓人覺得不是很順手甚至覺得有挫折感。    

這就是為什麼Upsource兼有IDE plugin, 讓你方便從你的IDE直接參與代碼審查並做討論.  今天我將帶大家一起看plugin的功能並從你喜愛的IDE來感受一下代碼審查的整個過程.  現在就開始吧!

建立 (Setup)

事前準備:

  • 你需要安裝Upsource的伺服器:請下載UpSource  。 (UpSource 10個帳號免費)
  • 你必須使用以下其中一樣 JetBrains IDE: IntelliJ IDEA、PhpStorm、WebStorm、PyCharm、 RubyMine、AppCode、CLion 或 DataGrip。

安裝 (Installation)

要安裝plugin,請到 Preferences | Plugins, 點選 Install JetBrains plugin 並找到 Upsource Integration plugin。

設定 (Configuration)

你唯一要做的是讓你的IDE知道你的Upsource 伺服器在哪裡。 到 Preferences | Tools | Upsource 連接並輸入伺服器的URL。

不需特定的憑證。 Upsource plugin大多情況下將自動比對專案並提交。

準備好囉 !

現在看看其他:

Upsource plugin 在你的IDE加了兩個很重要的面板: News Feed 和 Reviews。

News Feed (新進訊息)

你可由Switcher (Ctrl + Tab) 連到 News Feed。

News Feed 顯示專案正發生哪些事。 系統原始設定只展示與你相關的資訊。 如有人對你寫的程式碼給意見、 有人提到你、 指定你來審查變更碼…等。  如果你想要看所有的新訊息也可以, 或只看還沒讀的新訊息.

NewsFeed.png

你可以回覆意見並從News Feed直接去參與討論。

ReplyFromNewsFeed

當你需要更多的上下文(context), 在訊息通知上點選審查ID。 你將被帶到下一個 Upsource 面板叫做Reviews,在這裡你可以看到所有相關此審查的細節。   

Reviews(審查)

你可經由Switcher (Ctrl + Tab)Reviews 。

原始設定 Reviews 面板會顯示需要你照顧的代碼審查資訊。  你可採用下拉式篩選或搜尋箱來找到此專案的其他審查資訊。

ReviewsToolWindow

你也可以針對任何特定的代碼審查獲得更多資訊: 誰有參與?  加了哪些版本? 做了哪些修改? 有哪些正在進行的討論? ….等等。

ReviewDetails

現在讓我們來看簡單的代碼審查情境,了解你從IDE可以如何操作。

要求你的團隊夥伴審查你的變更

你剛剛解完一個bug, 正要交付你的變更。 這個時候,你可在交付的對話框要求你的同事審查你的變更。

CommitDialog

一旦變更被推上貯存庫(repository),一個代碼審查將被新增。

當你的同事寫下意見或更新審查, 你將馬上收到通知。

IDE-notification

點選通知後將跳到審查頁面(review)。  從這裡你將被導覽到編輯器上的或兩邊版本內容對照(side-by-side diff)的意見(comment)。

side-by-side-comment

如果你的同事已指出你需要注意的問題,你可如你開始這審查一樣將修改新增到一個審查(review)  – 交付修改時選擇“Attach to review” 。

審查別人的變更

如果有人指定你審查變更, 你將馬上收到通知。

invitation-to-review

點選此連結到審查(Reviews)的畫面, 你將看到所有需要的資訊和動作。

Upsource Integration plugin讓你可提出(check out)最近的版本(revisions),確認你審查的是相關的變更。

latestRevision

你可在編輯器或在版本差異(diff view)上留下意見 。

CommentsInADiff

當你完成審查, 請點選Accept (看過一切都沒問題) 或 提出你的問題 (當你發現有什麼問題, 或有些事不清楚需要釐清) , 讓你審查的代碼作者知悉你已經審查過他的變更。

Accept

你還能用plugin做什麼呢?

如果你安裝了 Upsource integration plugin, 你將很容易地把你任何一段代碼的連結分享給你的團隊夥伴。  請參考我們最近分享的另一篇文章 : The Ultimate Way of Sharing Code 。

你可以在還沒開始一個代碼審查前在代碼旁留下你的意見,也許你有個問題, 希望代碼的作者能釐清一兩點不清楚的地方, 或你發現問題、 或你偶然發現優雅的解法、或是想給這作者一個讚, 怎麼做呢? 選擇這段代碼(請注意這可任意選擇), 然後從此執行環境的選單(context menu)點選Upsource | Leave a comment.  Upsource將進一步回報你代碼的作者:

leaveComment

希望你覺得這篇很有用,學到新的好方法 !

Upsource Integration plugin 能配合任何 JetBrains IDE 。 如果你採用別的 IDEs  你仍可運用Upsource的 Web UI 享用代碼審查, 利用IDE等級的觀點洞察, 且在你喜歡的瀏覽器導覽。

你可能會有興趣

覺得這篇文章有用嗎?  將很感謝您的分享 !

Soft & Share日報-DevOps 資訊整理與感想

拜FaceBook演算法幫忙, 因為持續觀察一些技術主題, FB塗鴉牆總是會不斷出現相關技術開發的文章, 在FB上看到許多文章後, 也發現一個有趣的現象, 不知道大家是否會這樣做

  1. 看了標題, 先按讚再說
  2. 按了讚後, 再按分享
  3. 用FB的儲存功能, 晚點再看

在經營FB粉絲團前, 因為就發現這個現象, 於是乾脆建立一個粉絲團, 然後看到不錯的資源就貼到粉絲團, 再找時間消化. 不過這樣的整理有時候要檢討一下, 有幫助嗎? 還是只是會造成資訊焦慮症?

最近想做另一種嘗試, 如果最近透過不同管道(不一定是FB), 只要出現類似主題, 來做一個主題式的整理, 這樣可以提醒自己是否真的對這些技術文章真的有讀過, 可以內化成自己的經驗, 這個才是最重要的

近幾天連續分享一些主題都是跟DevOps有關, 我們來複習一下吧!

DevOps做好自動化, 遠離肝硬化

這篇文章的標題下的很好, 所以在FB上看到真的有網友說, 看到標題就按讚 😀 , 這篇文章講到一個很重要的DevOps濫觴, Flickr 公開他們內部是如何運作可以一天做10次的版本更新

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr 

看了一下, 那個年代他們還在用SVN , CI叫Hudson , 這個簡報有點歷史, 但是裡面不只講的是技術層次, 還包含有管理文化層次, Respect , Trust, Healthy  attitude about failure , Avoiding Blame , 推薦給您的團隊完整看一次

DevOps : 持續整合 & 持續交付 (Docker, Circle, AWS)

這篇應該是以DevOps實作面寫得很詳細的一篇, 但是重點要放在裡面的流程與精神, 因為您在公司也許不是用Node.js, 不是用GitHub , 也不是Deploy到AWS ,  很喜歡這篇的一個主要原因是它利用一個很簡單的nodejs程式當作起始點, 然後跑了一次完整的流程給你看, 你可以練習一下, 如果你是用PHP, Python, Java, 將裡面的工具換成真正實際開發的工具, 你會如何做? 這是一個很好的練習樣板

凍仁的筆記: 在OSX 10.11.4安裝Docker for Mac 

Docker在DevOps流程裡面也是扮演一個重要的角色, 小編對Docker坦白說對Docker一知半解, 但是這篇文章會是小編開始學習Docker一個動力的開始- Docker for Mac減少了安裝的門檻, 看了文章後去Docker網站申請, 兩天後收到下載通知.

Linux System Administrator/DevOps Interview Questions

Linux在DevOps扮演重要的角色 那麼如何面試一位稱職的Linux系統管理者?

[碎碎念] 軟體架構能否實現,真正的問題在成本。

DevOps有一部分也會跟您的軟體架構有關聯, 您的軟體架構會決定要如何做CI/CD , 對於這篇文章想下一個註解-小孩不要開大車, 如果你的產品的PMF(Product Market Fit)還不是很明顯, 就開始思考Growth, 架構要Scale, 那麼就會形成所謂的 ‘浪費’ , 所以工程師不要有樣學樣, DevOps也是同樣的道理. 花了很多時間做自動化, 但是回過頭來檢視, 這些自動化對目前公司的業務成長是否有意義?

[架構師觀點] .NET 開發人員該如何看待 Open Source Solutions?

這篇文章比較像是技術風向球, 而且是針對您想用MicroSoft解決方案的開發者. 這篇文章您搭配上一篇看, 就會比較清楚你要學習的優先順序會是什麼?

有了 Agile,為什麼還要有 DevOps?

很喜歡William Yeh的追本溯源精神, 如果您從上面一路看到這篇, 您應該會發現, 小編很認同William Yeh的一些想法, 大部分的開發者看熱門技術主題都是看樹不看林, 有些東西仔細去探究, 最後會發現根本不適合目前的公司, 前一陣子跟一位網友聊天, 他跟我說您可以將一些瑣碎的事寫成一個bot, 讓bot來幫您做就不用那麼累了, Yes, bot開發技術最近很紅, 小編也是技術出身對bot技術開發也是很有興趣, 但是仔細想一下, bot對公司目前的成長跟業務有關聯嗎 ? William Yeh這篇文章除了簡報, 還有錄影, 可以讓您好好思考一下DevOps對於公司的整體意義是什麼?

關於Soft & Share

Soft & Share 有代理Pragmatic的電子書, 並且使用團購的方式, 可以降低購買成本, 我們也希望這些參加團購的網友最後可以自主發起組織網路讀書會互相交流, 目前已經有8個網路讀書會進行中.  Soft & Share目前也是JetBrains, Framer在台灣的合作夥伴.

Soft & Share最近相關團購活動

DevOps in Practice

這本書是ThoughtWorks的首席顧問. ThoughtWorks幫助軟體公司採用DevOps和持續交付實踐(Continuous Delivery practices)減短從發想到實踐應用間的時程, 想要了解DevOps實務, 與得到業界專家的經驗, 這本書不可錯過 , 這本書第一梯次團購已經結束, 目前團購是第二梯次, 有興趣可以來參加, 要參加請先加入Soft & Share社團後,再到這個Facebook連結下方留言

JetBrains IDE 開發工具團購

開發者想必對JetBrains不會陌生, JetBrains上個月剛剛與Soft & Share簽約成為合作夥伴, 我們也在FB建立許多JetBrains相關開發工具的社團, 您可以使用FB search ‘JetBrains Taiwan’ 可以找到您在使用對應的JetBrains開發工具社團, 歡迎來加入一起交流JetBrains開發工具使用心得.

Soft & Share上週跟JetBrains爭取到一些福利:-) 目前推出以下JetBrains開發工具團購, 這個團購機會有限, 不是每個月都有 🙂 , 要好好把握

  1. IntelliJ IDEA Ultimate USD149 x 80% = USD119.2 
  2. PhpStorm USD89 x 80% = USD71.2
  3. All Products Pack USD249 x 80%=USD199.2

要參加請先加入Soft & Share社團後, 再到這個Facebook連結下方留言

喜歡我們做這樣的資訊整理與心得分享嗎? 喜歡就幫忙按個讚與分享給您的好朋友吧!

Soft & Share 日報-創意的產生與環境的衝擊

讀書會會對大腦產生一連串的衝擊, 後面我還會再提還有什麼事會對你產生一些衝擊, 我舉得例子, 昨天晚上的成長駭客讀書會, 我們讀到第三章跟第四章, 獲取用戶, 跟提高使用者活躍度(實際的內容這邊我就不重複了, 對成長駭客內容有興趣可以買一本來看看), 讀書會進行到尾聲, 同學Emily最後提到一個觀點跟我自己在閱讀時的觀感是一樣, 書上的範例只是範例, 不見得適合每個人目前手上在開發的產品, 大家還是自求多福吧! Emily在這個時間點就提了一個很好的問題

如果你是Waze這個App的產品經理, 你要如何解決Waze在台灣使用者活躍度不高的問題?

Waze 這個App我有裝過, 而且也有使用過, 當時是看了網路介紹描述這個App在國外很受歡迎, 原因是這個App的導航功能增加了社群的功能, 透過社群的協助使用者可以知道那個路段目前是塞車, 或是有交通事故, 使用者在導航的時候就可以選擇是否要繞道, 我是看了這樣的報導於是去下載安裝, 可是這件事在台灣並沒有發生, 用了幾次後我就再也沒有開過這個App.

我想了一下, 一下子要將自己的大腦模式切換到Waze的產品經理一點思緒都沒有, Emily問了另一位同學Allen, 他也是一下子無法回答, 於是我提議Emily將這個問題放到讀書會的Trello board的問題與反思, 大家有想到好的解法就到Trello board寫的comment當作是練習吧! 讀書會結束後, 我馬上開了手機打開Waze, 因為太久沒打開, 接下來就是一連串的下載更新, 結果一打開後介面還是簡體中文, 旁邊有個菜單可以跟Facebook做連結, 連結後看了一下Facebook的朋友只有一位最後使用時間是28天前, 其它的FB朋友都有4~5個月以上沒有打開這個App, Waze在台灣的使用者活躍度確實不高. 於是我很直覺的認為, 如果我是產品經理, 第一個要改善的應該是將簡體中文介面改成繁體中文介面 

沒多久Allen將他認為要改善的要素寫到Trello board, 讓我有點驚訝的是Allen是第一次安裝Waze, 他用使用者的角度寫下不少功能面的改善, 例如可以用語音輸入添加評論, 路況報導使用Google Map API整合, 等等功能.

看到Allen提的路況報導這件事, 我很好奇問了一下Allen, 他在使用Google Map導航時真的有用路況報導嗎? 因為我用了導航這麼久, 我幾乎沒在用路況報導這個功能, Allen告訴我在市區偶而會開, 上高速公路時也會看一下是否會塞車

我問了自己以下幾個問題?

我為何不會想到路況這個功能?

以使用衛星導航功能, 我會比較喜歡Garmin這種專為車用導航設計的車機, 這種車機不用一直開著4G, 而且圖資也會一直更新(但是更新過程有點麻煩), 人機界面設計上比用手機上的導航好很多, 因為螢幕比較大, 但是這種車機沒有4G所以我對實時的路況並沒有實際的使用者體驗.

沒有在用的原因是什麼?

沒有在用的原因有很多, 第一沒有實際的體驗會是一個很重要的因素, 即使開車上高速公路也很少開交通報導, 因為過去的體驗與經驗告訴我, 繞道最後花的時間跟塞車其實差不多, 但是我相信也是有使用者因為有了一次好的體驗, 就會持續用路況報導或是導航的路況報導功能.

第二個原因跟我的環境與工作有關, 我目前住在新竹縣, 出門會塞車的時間大概就是上班時間跟下班時間, 我目前自己在創業, 時間的自由度很高, 因此我會去避開塞車時間. 很自然就不會想去用路況報導的功能

如果你是產品經理, 你又沒有切身需求, 那麼要如何去發掘需求, 創造需求?

這就是我一路反思的問題, 所以我很感謝Emily昨天在讀書會提出了這個練習, 她沒有提出這個問題之前, 我的大腦不可能會生出這篇文章, 不可能會去問自己一連串的問題, 我為了Waze這個問題, 又去寫了下一個comment

如果我是Waze的產品經理, 想要解決台灣使用者活躍度的問題, 第一個應該要先取得使用者的信任, 因為我還有一個不想用的原因是Waze的圖資可靠嗎? 我從Waze的說明找不到它有跟任何台灣當地的圖資公司合作, 至少Apple Map我知道它在台灣是使用TomTom的圖資, TomTom自己也有在生產車機, Apple Map使用過幾次都有不錯的體驗(有導航到我設定的目的地) 所以我會繼續使用Apple Map的導航功能.

上面的其實都不是標準答案

今天早上大腦模式還是有延續這個思考, 我覺得解決問題有一部分很大的因素會是受限到我們所處的環境與過去的經驗, 如果你一直在用自身的經驗, 所處的環境去思考, 其實得到的答案都不會是好的答案, 如果你自己覺得是好的答案, 我只能說那叫做-自我感覺良好. 

要如何讓大腦產生衝擊與得到不同的回饋

  1. 想辦法多接觸不同環境, 不同年齡的人吧, 例如Emily的公司在做美食App, 我昨天給她的建議, 以我目前的年齡(46), 我需要的是記憶, 而不是獎勵, 當然每個App會有自己預設的TA, 也許我不是他們的TA, 但是因為Emily透過讀書會認識我, 她會接受到一個訊息-我這個年齡的人需要的是記憶 🙂 , 不同環境的人, 也許是外國人, 或是不同職業的人, 或是住在不同地區的人, 你的人脈曾經接觸這些人, 大腦自然會有更多的想法.
  2. 寫文章或是blog. 例如我寫了這篇blog, 透過社群, 很容易就會收集到一些新的想法.
  3. 看書 , 看電影, 也是讓自己多一些視野大腦產生衝擊的好方法.
  4. 旅行, 如果有預算, 應該多去一些不同的國家旅行, 我近幾年看到大部分周遭的朋友都跑去日本玩, 日本我自己曾經有幾年也很喜歡去, 但是去了幾次沒有新鮮感, 如果我有預算, 我會比較想去不同的國家, 而且那個旅行不會是以舒適為目的.

後面應該還有許多答案, 如果你有興趣, 有想到可以增加自己人生經驗增加創意的方法, 很歡迎你透過下方的意見回饋分享給我, 如果你有想到如何讓Waze在台灣更受歡迎的idea, 寫信給我my@esast.com, 我會回饋給讀書會的成員, 並再寫一篇blog跟大家分享我們最後討論出來的想法.

想要接觸更多的人得到更直接的回饋, 參加讀書會是一個很快的方便法門 ? Soft & Share 網路讀書會

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

 

 

 

 

轉載-前端設計師/工程師的職缺要如何寫?

最近常遇到求職者想找前端工作但被徵才內容嚇到不敢應徵,或是徵才廠商不曉得要如何寫職缺需求才不會引起誤會,所以分享一下個人的經驗: 

熟悉 JS Framework,jQuery、Vue、Angular、React尤佳

有些廠商可能剛接觸前端職業,不了解目前 JavaScript 趨勢,所以就熱門的全寫上,這樣很容易造成求職者的惶恐,就連我自己也只能說對 JQ、NG 算稍微精通,其他也頂多算是玩到建立個 todolist、寫些玩具的程度,根本還沒成熟到敢用在專案上。web 廠商要前端會 JavaScript Framework,主要也是希望會下面兩項技能:

  1. 設計網頁互動性動畫效果
  2. 串接 Ajax、Restful API,具系統性地規劃前端架構

那就建議廠商寫明工作任務,再從履歷、面試來去評斷他是否勝任就好,現在前端框架多到爆炸,我也認識不少純用 Native、冷門框架但強到爆炸,要記住框架只是工具,你就算有關刀,但不會耍也是白搭

工程師、設計師職稱傻傻分不清楚

我在輔導學生就業前端的時候,常常遇到職稱寫「前端工程師」,但去面試時卻要求需設計畫面(Mockup),這真的是比 HR 要找 JAVA 但卻找 JavaScript 工程師還要更雷!所以每次高雄前端社群聚會要結束時,我都會不厭其煩播這個影片:Watching: Front-end design主要希望讓會眾了解前端設計師、前端工程師的差異。所以這裡建議廠商,如果工作項目需要設計畫面,我自己是建議職稱加上「設計」,例如「網頁設計師」、「前端設計師」。如果完全不用設計畫面,那就加個「工程」,

例如「網頁工程師」、「前端工程師」。

至少能讓求職者有個基本判斷,點閱轉換率也比較高。 至於有些朋友提說如果只單純切版,不會接 Ajax、SPA 的職稱要叫什麼,我個人覺得叫「前端工程師」也沒什麼不妥,也有在104看過「網頁切版工程師」、「切版工程師」也OK的。

懂後端 Framework 尤佳

有幾次幫前端朋友討論職缺的時候,常發現對方濾掉些我認為他們可以勝任且薪水也給到位的公司,細問後才得知他們會對工作項目裡面有寫到「懂某某後端語言尤佳」的條件而卻步,儘管那是加分條件而不是必備條件。我問了幾次徵才廠商,實際狀況只是:

  1. 擔心與公司後端工程師合作不順 (佔80%)
  2. 只是現階段大案需要,未來「有可能」需要負責後端(佔20%)

老實講如果你是一個:

  1. 已經會 Template Language(jade、slim、ejs),了解 partial、Layout的觀念
  2. 曾經有跟後端工程師合作經驗

那其實就已經可以跟全部的後端工程師合作了,很多都是大同小異的,每次我跟不同後端工程師合作,只要了解 View 放在哪裡,CSS、JS 的路徑在哪就直接上工改 Code了。

不過會建議徵才廠商要和面試者主動表達要找的對象是哪種,有些廠商會希望先騙進來,等前端需求沒那麼高再誘導轉後端,不過為了建立長久關係,建議還是事先說清楚會比較好。

懂 UI/UX 尤佳

老實說除非是 UI Designer轉前端,或者本身對這塊領域有興趣,否則真的是有點強人所難。但經由我和許多徵才廠商詢問過後,他們要的大多是「能夠與美術、後端合作,提出可操作性的前端介面建議」,其實這才是徵才廠商為什麼要找前端工程師的最主要原因。

每當 UI Designer設計 Mockup 出來後,我都會提出四、五種可行性操作流程,同時瀏覽器兼容性也相當成熟的建議,彼此再激盪出更佳的使用者介面,所以 UI/UX 並非是 UI Designer的工作,我個人認為是全部團隊都該參與的事項,包含PM與後端,如果你看到徵才內容條件有「懂 UI/UX 尤佳」,我建議就自己腦補成「能夠與美術、後端合作,提出可操作性的前端介面建議」就好了哈哈。

其實還有相當多可以寫,但把大問題寫出來後面其實問題就比較小了,歡迎大家一起補充

本文獲得廖洧杰先生同意轉載, 原文出自這裡 如果大家有想要補充, 可到原文出處留言. 

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

 

Soft & Share 週報-13

這個星期有點忙碌, 因為參加了三個讀書會, 兩個Soft & Share的網路讀書會, 和Read for Action舉辦的實體讀書會, 讀的書是-創業維艱 , 這本書在3個月前已經看過一半, 所以就跑去報名, 最主要的目的除了想複習一下這本書, 一方面也想了解Read for Action讀書會召集人Jin Yao Kang的讀書會進行方式, 因為他在數週前寫了一篇文章-如何改善讀書會討論品質, 這篇文章給我了很大的啟發, 所以阿康邀我去參加這個讀書會, 我也很快就跑去報名.

Read for Action 讀書會的進行方式

在說明這個讀書會前, 先說一下我之前的參加過的讀書會經驗, 之前因緣際會跟一位在國科會上班的康博士成爲室友, 康博士退休後在東元醫院主持了一個讀書會, 我去參加了幾次, 這個讀書會的進行方式其實比較像是分享會, 每週都會邀請一些康博士的朋友來分享他們的一些經驗, 有時候是旅遊經驗, 有時候是個人的創作經驗, 這樣的讀書會參加的人很多, 所以互動的機會並不多. 後來又參加了一次康博士辦的讀書會, 那次的讀書會有導讀的人, 介紹了書的重點後, 就進行了分組討論. 那次的讀書會雖然我沒有讀過那本書, 經過導讀者的介紹與分組討論, 過了好幾年, 我對於討論的內容-親子教育, 卻還有一些印象, 這應該拜分組討論所賜.

阿康的Read for Action讀書會召開前, 阿康有特別交代至少要讀過前三章, 到了讀書會現場, 大家互相自我介紹後, 阿康接著就開始安排每個人要讀哪些章節, 現場來了總共9個人, 分配每個人要閱讀那些章節後後, 接著大家就進入了閱讀時間(大約 30~ 40分鐘), 這算是一個有趣的經驗, 因為我很少參加一個讀書會當場讀完進度還要報告重點, 有一點壓力, 對於 ‘專注’ 這件事卻很有幫助.

創業維艱, 我被安排到第8章, 剛開始看時有點緊張, 因為書裡面講到一個軟體維護合約的CA條款, 雖然我在軟體業待這麼久, 還是第一次聽到CA條款, CA條款有兩個狀況, 我重複讀了兩次, 才比較了解這兩種狀況, 但是對於會計審核這段, 其實我看不太懂 XD , 雖然瞭解這本書想要表達的情境, 但是心裡在想, 要是參加的同學問我什麼是CA條款? 為何會計審核有兩種不同的看法, 還好現場應該沒有在軟體業上班的同業, 這個問題也許再Google一下會得到比較好的解釋. 後面的3個小節還好讀起來很輕鬆, 而且跟自己的工作也有一些關聯, 不過為了在讀書會中的報告講話不要結巴與沒有講到重點, 我在讀書會做了一些重點整理.

unnamed

大家都把自己的閱讀進度都完成後, 接下來就進入每個人的報告時間, 每個人會摘要一下自己看到的重點, 然後大家也會針對這些重點進行一些討論. 剛開始的時候大家都還很陌生, 但是過了兩節的導讀後, 大家逐漸熟悉就聊開了, 讀書會從晚上7:30一直進行到10:30 討論的很熱烈, 這個狀況在我主持的網路讀書會也有這個現象. 但是阿康的實體讀書會大家都是第一次認識, 能聊的如此熱絡算是很成功的讀書會.

這樣讀書會的優點與缺點

優點: 對於忙碌的上班族, 這樣的讀書會是很有幫助的, 可以透過一次聚會解構一本書, 獲得不同業界人士閱讀不同的章節, 等於獲得不同的視野, 這部分如果有親身參與過, 是讀書會最令人著迷的部分.

缺點就是-時間太短, 但這個對忙碌的上班族而言也算是優點, 如果大家在讀書會後, 透過阿康準備的網路共筆持續交流, 這樣就可以彌補這個缺點. 還有負責墊底的導讀者最好已經先將整本書都讀過, 不然在別人報告的時候很容易分心, 我不知道是否其它參與者是否也有同樣的感覺, 但是因為我負責比較後面的章節,在聆聽同學的報告時, 腦子裡還在準備要如何報告重點.

對創業維艱這本書的簡單總結

今天看到一篇文章

黃子佼:在谷底更要有整理人生的能力

以下是我在我在FB對這篇文章的看法

裡面提到-我控制情緒的方式就是收集客觀資訊, 看清了局勢, 就不會一直往情緒偏, 會想要解決問題

黃子佼這種心智模式已經有CEO的視野, 星期五晚上參加的創業維艱這本書的讀書會, 我們討論到這本書的作者, 最讓我們感到佩服的是他在最危急的時候總是能去找出一條符合他最大利益的出路, 看路不看牆, 這不是靠運氣, 需要有成熟的心智與經驗才能去面對, 要如何訓練? 多看一些書, 多聽別人的經驗, 多交一些朋友, 還有事情不能總是挑簡單的來做, 來增加自己的視野, 自己的經驗. 當危機來臨的時候, 就是考驗自己心智是否足以承擔這一切的時候

黃子佼這句話其實已經反映了創業維艱-本·霍洛維茨的心境, 創業過程中會遇到許多不可預期的狀況, 你要如何選擇一條最佳途徑? 這其中有很大部分跟內心的情緒, 堅強, 智慧, 勇氣有關, 有些人可以熬的過去, 但是很多人熬不過去. 我自己也在面臨這樣的考驗. 創業維艱這本書教我的是, 冷靜下來, 分析每一步棋, 做出選擇, 然後Action, 其它的就交給老天安排吧!

想要加入Soft & Share的Slack社群? 加入Soft & Share Slack 

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

Soft & Share 週報-12

Soft & Share網路讀書會邁入了第四週, 到目前為止進行都算順利, 這週我也加入了另一班讀書會-Designing for Behavior Change, 參加這個讀書會主要目的一方面想自己扮演一下不同的角色, 一方面這本書的內容也很吸引我, 因為發現自己從以前到現在創業的題目都脫離不了這本書的範圍, 從賣研發團隊協同作業平台, 到開發App, 辦網路讀書會, 這些創業題目的問題核心都跟這本書有關, 這本書適合什麼樣的創業團隊的產品經理或是CEO讀呢? 如果您在開發的產品是人們本身就想要用的, 可以幫助人們的生活獲得提升, 可是這個產品卻又無法變成人們的生活必需品, 或是成為生活的一部份, 聽起來很抽象對不對? 如同我之前說過, 從我的創業題目可以找到一些蛛絲馬跡, 例如研發協同作業平台好了, 這個系統我幫很多客戶導入過, 但是有些客戶有導入成功, 有些卻失敗, 這件事背後的問題其實讓我無法找到一個正確答案, 曾經有一度認為是不是每一家公司的人員素質不同會產生不同的結果, 其中有一家客戶自己也是這麼認為, 其實這個議題深深被Designing for Behavior Change這本書所說的內容所牽引, 這些公司都有一個共同特色, 他們都認為這樣做是好的, 這樣做是對軟體開發流程, 甚至對整個公司的協同溝通是有幫助的, 而且他們也願意去這這件事. 但是他們真的有去落實嗎? 真的有去養成良好的習慣去使用系統嗎?(例如養成寫Wiki的習慣, 將重複發生的錯誤的解決方法變成一個可被重複調閱查看的知識文件) , 客戶都知道這樣做很好, 可是最後都做不好, 原因有很多, 我就不加詳述. 如果您目前在開發的產品, 或是目前在做的網路服務( 例如辦讀書會也是) 有這樣的現象, 那麼這本書非常適合您好好仔細閱讀. 至於如何讓網路讀書會變得更好, 讓更多人自願來組織, 來參加, 我目前還沒有答案, 也許再過幾週後, 這些答案會在我的大腦中越趨明顯.

Continue reading “Soft & Share 週報-12”

Soft & Share 週報-11

這是Soft & Share網路讀書會正式開辦以來的第三週, 目前正式在Soft & Share Slack上啟動的網路讀書會總共7班, 我自己帶了一班, 下週我自己預計也會加入另一班當同學, 因為我也想體驗參加一下不同領域的書籍讀書會, 我選擇的書籍是Designing for Behavior Change , 行為改變科學的實務設計.

網路讀書會啟動以來, 其實還有一班沒有啟動, 本來我有一些想法, 但是這週其實我接受一些外在的指教與讀書會班長的回饋讓我有一些新的想法.

網路讀書會應該是主動還是被動?

我先從一班讀書會組織後到目前為止都還沒開始講一下我的想法好了, 這週有一位參加讀書會的網友在slack上用private message問我, 為何他參加的讀書會都還沒開始? 我當下就跟他回覆說, 我幫你問一下班長, 於是我跟那位班長聯絡上了, 並且問他目前有多少網友沒有回你的信, 他告訴我有三位, 我跟他說如果今天他們都沒有回覆你, 那麼可以開始準備讀書會的會前會了. 我們就不等待那些都不回覆的網友, 但是過了三天還是沒動靜? 我不怪這位班長, 後續我會解釋我內心的變化.

星期一是Bing帶的讀書會”Designing for Behavior Change”會前會, 參加人數有8人, 星期一晚上因為我有固定要去社區大學上書法課, 不然Bing這班我原本想要協助她, 怕她會緊張 , 所以我下課後馬上問一下她的讀書會開的怎麼樣? 她很興奮地回答我, 網路讀書會太好玩了, 我當下的擔心馬上消失的一乾二淨, 跟她說阿伯很高興, 其實我也搞不清楚Bing到底多年輕, 年輕到她會叫我阿伯XD, 那天晚上應該也是我辦讀書會以來最高興的一天, 於是馬上用Zoom跟Bing聊一下她的想法, Bing告訴我, 這樣的聚會是有意義的, 因為可以認識不同公司的人,而且透過網路語音視訊打破了地域的界線, 大家除了交流讀書心得, 還可以交換一下工作經驗, 她覺得非常有趣, 這裡面還有一件事, 也是讓她很開心的是, 她的讀書會臨時插入了另一位常在FB社團-Read for Action開讀書會的阿康, 她非常感謝阿康的加入, 讓她的讀書會生色不少, 因為阿康的幫忙, 讓她有時候接不上話的時候, 阿康會在適當的時間接手. Bing對網路的讀書會前景相當看好, 並且認為創業公司更需要這樣的平台聚集組織網路讀書會. 除了經驗交流, 人脈擴展也增加了一些管道, 但是Bing跟我說了一句, 她以後不想當班長, 因為她是設計師, 不是PM, 要她用e-mail跟大家聯絡太痛苦了, 不過我事後有幫她想了一個方法, 她覺得很不錯, 以後有機會再跟大家分享

隔天星期二是我帶的讀書會”成長駭客“進行的也算是順暢, 當我在Slack上看到參加的網友開始利用Trello board寫下他讀書的重點, 並回答我在上面提問的問題, 我內心是感到欣慰的, 為何這樣說? 我在網路讀書會進行中有問這位同學一些問題, 也許他覺得讀書會中回答得不夠仔細, 所以事後他在Trello board寫下更多細節, 隔天早上我看到另一位讀書會同學也上來給他一些建議. 我也在讀書會提到我目前創業的問題, 很幸運我得到兩位同學給我不錯的建議.  雖然大家已經在網路語音視訊會議中熱烈討論過, 但經過一晚的沈思後, 又到Slack與Trello board寫下自己更多的看法. 這種回饋是很寶貴的.

星期三是Joy的網路讀書會, 於是我利用中午時間跟他分享一下我的一些想法, 並告訴她讀書會可以如何做會更好, 但是我得到了不一樣的回應,  Joy給我的回應是

“trello 我並沒有強制他們一定要上來寫或者什麼,它類似我們在上課時個黑板這樣 有個主要的畫面 讓大家在一個一個人提出自己看法的過程中,可以一邊聽一邊思考畢竟這是自發性活動,我們能扮演的是 一個起頭 後續要怎麼做我並不想干涉我的組員也許有些人是習慣直接貼書本的標籤也許有些人會使用trello, whatever 讀書應該是開心的 自己想讀的 自然會有自己記錄的方式. 我每一週都有導讀人,可以利用trello 來做重點, 我也會希望大家會後再把自己整個重點note.上去, 但我也只能請他們盡量這樣做不做我也覺得無所謂獲得多少 因人而異. “

Joy跟我說的話, 其實她並不是第一個人這樣說, 剛好前幾天, 也有一位網友也是這樣跟我說, 他們覺得一個讀書會為何搞得如此複雜, 需要學Slack, Trello 這些工具, 所以我聽到Joy的反應並不會覺的意外. 我告訴她我同意她的想法, 我們就讓它順其自然吧. 那天跟Joy的聊天, 很巧妙我得到另一種收穫, 因為Joy帶的讀書會也是”Designing for behavior change” , 我在跟她用Slack討論時, 我同時也到了Amazon上去看這本書的預覽版本, 裡面看到讓我很釋懷的一段話

“Designing for behavior change doesn’t seek to persuade people to take action, for two reasons. First, it relies on the fact that people already want to act . Second, it’s foundamentally about action and not about beliefs or intentions; the goal is to help people do something physical in the real world . It’s in the real world of action where good intention often fail– 摘錄自Designing for Behavior Change”

最後面那一句講得很好, 真實的世界中出於善意的行為往往失敗. 我跟Joy打趣說, 妳果然學過Designing for Behavior Change , 你的讀書會精神有符合 Designing for Behavior Change. 

星期四是Jack帶的讀書會, 他那班剩下三人, 從10:00開到了晚上11:30 幾乎都快變成深夜讀書會, 每次的每班讀書會結束後我都會很關心讀書會進行如何, 我跟Jack聊一下我看了”Designing for Behavior Change”的想法, 並跟他表示, 我用讀書會班長去push大家來進行讀書會, 這樣的出發點也許是錯的, Jack的反應又是不同的回饋, 他認為讀書會太過鬆散也是組織不起來 ! , 其實這個問題我也想了好幾次, 如果這次沒有去動用班長組織讀書會, 目前會有幾班讀書會?

我們再回到剛剛提到那一班還沒啟動的讀書會, 為何我不怪那位班長? 我昨天跟那位跟我聯絡的網友說明了一下我的想法, 我跟他說讀書會的組織雖然有班長在當聯絡人, 但是我看到的回應其實有點冷淡, 如果參加的網友都很期待讀書會的進行, 大家應該會反過來push班長, 詢問班長哪時候要開始, 但是我從開辦網路讀書會看到的現象是班長去slack channel問大家意見, 只有少數人理班長, 設計心理學的班長甚至還使出填問券前三名還會送小禮物的方法讓大家來填問券喬讀書會時間. 這也是Bing跟我反應她下次不想當班長了, 因為聯絡人太辛苦了, 所以我跟那位網友說, 如果班長沒有反應, 你們也可以去push他, 如果是班長push你們, 你們沒反應, 那就是你們的問題了, 如果你們去push班長, 班長沒反應, 那就是班長的問題了, 這個平台讓大家聚在一起, 大家應該發揮互助精神體諒一下對方, 所以我決定在旁邊靜觀其變, 希望這班的同學可以自助的啟動讀書會

Soft & Share Slack與網路讀書會的未來想法

因為我目前也在看”Designing for Behavior Change”, 我對目前的網路讀書會的價值是抱持著正向的看法, 那位詢問為何他參加的讀書會沒有啟動的網友也開始關心我下一步是否會停辦網路讀書會? 因為到目前為止, 網路讀書會我們並沒有跟大家收費, 他倒是告訴我就算是收費, 他也願意參加. 讀書會是否會延續, 您從頭看到現在,  內心應該有了答案, 如果有網友自主來組織, 我只要幫一點小忙, 其實網路讀書會我相信是會一直延續下去.

我目前的計劃是還是維持這個網路讀書會是免費的, 而且我也計畫就讓這個平台是一個open的平台, 我在Soft & Share的Slack新增了一個Channel名稱是bookclub, 讓想組織讀書會的人參加這個channel, 發起讀書會, 我會協助想在我的Slack組織讀書會的網友準備好該有的平台與工具, private channel 或 public channel , Trello board, 甚至Github repository, 我也會教你如何使用Zoom來進行網路讀書會, 利用Trello board做記錄, Slack做討論. 這些工具組合雖然不是1oo分, 但是以網路讀書會的體驗, 我認為是目前最好的solution.

初步的商業模式

但是我有一件事需要組織讀書會的網友反過來幫忙我, 就是每次啟動讀書會, 我希望每個讀書會有自己的入口網頁(Landing page) 並且放在Soft & Share網站, 裡面可以放讀書會介紹, 組織讀會會班長的blog網址或是公司網頁連結, 如何加入Soft & Share Slack, 與Trello board的URL. 你可以利用這個入口網頁到其它社群宣傳你想組織的讀書會讓其他網友來加入, 並且讀書會結束後還可以回來透過讀書會入口網頁進入Trello board複習讀書會過程中的紀錄, 這個動作雖然也可以在Soft & Share的Slack上進行, 但是這樣做除了對Soft & Share的網站流量有幫助, 還有一個好處就是你可以找到不同業界的人來加入, Soft & Share的Slack社群遲早也會面臨裏面的網友同質性太高的問題, 讀書會我認為最寶貴的是組成的網友來自不同的產業, 或是同類型產業, 從事不同的Business model , 如果你看到我上面分享的讀書會經驗, 我相信你也感受到了, 參加讀書會的最大收穫就是從不同人的角度來檢視你目前的想法. 而不會讓你的想法侷限在某種領域走不出來, 這次組織讀書會, 我的收穫就很大, 我經常跟網友說Soft & Share其實還是在MVP階段, 在這段期間讓我可以透過Slack跟班長, 其他網友互相交流, 收穫很大, 因此我也很樂意將我的平台開放分享並教你如何來使用. 除了讓Soft & Share的流量增加可以增取到一些商業合作機會(例如刊登職缺服務, 工具代理採購), 增加流量也可以讓我們有機會尋找贊助廠商, 例如刊登廣告, 我們也會在每個讀書會下方設定捐款的帳號, 如果大家喜歡這樣的服務可以採用小額贊助的方式贊助我們的營運.

感謝

這三週下來, 有不少人主動出來幫助我們, 也有網友關心我們的營運, 幾乎每本書的團購都參加希望對我們的營收會有幫助, 我看了很感動, 但我也勸那位網友要量力而為, 確實以目前的網站營收並不足以支撐我們目前的支出. 但是大家並沒有義務來為我承擔這些, 我只有一個小希望, 參加讀書會的網友要主動些, 並珍惜每次聚會的時間. Soft & Share的Slack平台,我今天做了一個動作將自己的管理權限同時授權給了另外兩位對這個社群有幫助的網友. 因為有一天我出門差點出了意外, 我跟另外一位網友說, 如果我發生了意外, 這個Slack就交給你們來管理, 這個社群是屬於大家的, 我不希望因為我這邊發生意外讓這個社群瓦解並且重來,  這三週下來我的感受是很深的. 這個社群我只是扮演催生者的角色, 上面互動, 討論的你們才是主角. 社群沒有互動, 沒有活動, 沒有分享, 就沒有了活力. 所以為了社群可以延續, 我還是必須要做一些權力下放與切割. 很抱歉的是目前我還無法跟這一路走來協助我的人保證你們未來會得到什麼, 但是我也感受到您的協助不是為了什麼, 只是很單純喜歡這樣的網路讀書會idea. 如果大家有任何想法好的idea, 也歡迎透過slack跟我討論.

想要加入Soft & Share的Slack社群? 加入Soft & Share Slack 

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

 

 

Soft & Share 週報-10

這是成立Soft & Share 網路讀書會的第二週, 這週陸陸續續有4個網路讀書會啟動了, 這週也是我最緊張的一週,  我最擔心的網路語音/視訊部分會是這個讀書會是否可以開的下去的第一個關鍵, 因為我過去對於網路語音多方通話的體驗是很差的(使用Skype), 當時跟另一位朋友使用Skype邀請來賓錄製Podcast, 錄到一半斷線, 雜音的機率蠻高的, 但是當時真正去暸解一下原因不外乎其中有一個人在外面用Skype手機版, 或是Wifi訊號很差. 如果第一次的網路讀書會體驗很差, 開到一半斷線, 後面就完蛋了, 況且我這次是挑戰最多10個人來參加網路讀書會. Skype官方說法是最多25人, 但是我其實還不是很放心, 於是這段期間,  我也測試了Google HangOut , Zoom, 當作是備案, 如果Skype不行, 至少還有其他選擇.

開網路讀書會的一些心得

剛開始我是使用Hangout , 我自己是已經跟另一位讀書會班長演練過一次, 所以當時覺得應該就是用Hangout, 但是在讀書會一開始時就出了一些狀況, 我分享出去的Join meeting URL不是每個人都可以加入, 即使參加讀書會的成員都是使用gmail, 還好有Slack, 我馬上請他們將e-mail上到slack , 然後再一個個邀請, 最後總算所有人都可以加入, 這段體驗其實耗掉不少時間, 有些人已經Join就在旁邊等, 有一位同學也Join了, 可是他人在外面用手機上網, 結果產生很大的回音, 一直到他到一個網路比較穩的地方, 回音才消失. 我們這次總共有7個人一起使用Hangout , 其中有一位同學還是香港人, 這就是網路讀書會有趣的地方, 你不會受地域的限制.

Zoom

測試Hangout時, 其實我有點緊張, 而且有點六神無主, 因為我已經很久沒有跟一群人說話, 也很久沒有跟一群人開會, 那種感覺很像我在前一家公司上班時第一天當經理的囧樣, 還有我對Hangout其實不算熟悉, 根本無法掌握誰是否還在線上, 有人說一句話也不知道那是誰, 心裡開始緊張了, 這樣讀書會怎麼開的下去, Anyway就是一團亂. 於是我靈機一動, 問大家是否願意開視訊, 大部分的人都同意了, 只有一位同學說他穿睡衣不方便 XD , 果然大家把視訊打開後, 我的緊張情緒漸漸鬆緩下來了, 我說話的時候可以看到大家的臉部表情, 即時他們不吭聲, 我也知道他們還在線上. Hangout測完後,  我緊接的測試Zoom , Zoom剛開始的體驗好很多, 將分享的URL分享到Slack後, 大家都很順利的加入視訊會議, 只有一位同學我忽略了, 原來他剛剛裝Zoom的軟體, 在手機上按了URL不知如何加入, 我測試Zoom完後才發現有位同學怎麼不見了, 趕緊再利用Slack跟他測試了一次, 避免下次狀況連連. 經過我比較Hangout與Zoom後, 我會比較想要用Zoom, 除了第一因素的邀請外, Zoom開視訊會議時每個人的頭像是顯示在視窗的上方, 而且每個人的頭像顯示比較大, 也比較清晰. 缺點只有一個, 免費版只能使用40分鐘, 但是如果大家聊得很開心, 我是想到一個idea, 也許可以先下課5分鐘, 讓另外的同學再開一個新的會議, 其他人再Join就好了, 也許下次可以試看看.

也許不用開視訊.

其實我自己也不是很喜歡在網路上露臉, 我發現Zoom下方有一個按鈕, 按下去後即使不開視訊, 可以看到每個人說話的訊號, 還有Zoom有舉手打訊號的功能, 如果不喜歡露臉的網友可以不用開視訊, 如果要加入討論, 可以先舉手. 這樣讀書會班長就可以在讀書會進行中做一個很好的協調.

在這個讀書會的會前會, 我主要的目的只有兩個, 讓大家熟悉網路視訊, 還有為了確保大家都知道工具如何使用, 我跟大家解釋一次Trello board要如何跟讀書會整合, 我讓他們進去Trello board每個人寫個簡單的筆記, 設定member為自己, 寫個comment, 這樣我確認他們都會操作Trello board後就不用再一個個叮嚀了.

回饋與反應

這次我帶的讀書會只是先暖身, 我們下週才會開始正式討論, 我開完後蠻高興的, 因為我可以感覺到大家的回饋都不錯, 也都很期待下一次的網路聚會. 而且透過Trello board的輔助, 讓大家知道大家有共同的目標, 這樣的網路讀書會要開成, 除了平台, 工具準備, 還需要一個人從中調度聯絡, 要在網路隨機找到不同公司, 甚至產業, 地域的人湊在一起真的很難得, 我希望未來的8週可以很順利的讀完一本書, 與同學一起激盪出一些書本上學不到的東西.

肯定

HPX_讀書會

感謝Jeff Wu對Soft & Share網路讀書會的肯定,  我必須要將這些讚美也分享給我的班長團隊, 沒有班長很努力的在從中協調, 光靠我一個人根本做不起來, 在這邊跟我的班長合作夥伴說一聲-感謝你們無償的付出, 這幾週讓我最感動的一件事就是我不認識你們, 我們都是在網路上隨機相遇, 但是你們願意幫我來組織讀書會, 我真的很感動(淚…) .

Jeff Wu的這篇po文, 也讓我認識了Jin Yao Kang也在做類似的事, 他寫了一篇文章-如何改善讀書會討論品質, 有些理念跟我的讀書會有點類似, Soft & Share網路讀書會算是剛開始, 這篇文章剛好是我可以拿來檢視Soft & Share的讀書會品質. 有件事要交代一下就是這週我們沒有很積極地去找班長, 因為我們要控制一下讀書會的品質, Soft & Share的平台, 工具, 流程都整理得差不多了, 但是我自己腦海有一些聲音告訴我, 先慢一點, 等目前的讀書會很穩定的運作後,  做一些改善, 再來啟動新的讀書會.

台北有很多不錯的小型聚會, 開發者, 讀書會都有, 我自己有一陣子也都會專程到台北去參加一些開發者聚會, 寫到這裡發現好像自己有好一陣子沒去參加cocoaheads的聚會. 我住在竹北, 其實到台北不算遠, 但是加上搭捷運, 等車時間也會耗上不少時間, 所以就這樣我離開開發者聚會有好長的時間了, 更不用說實體的讀書會, 之前參加的讀書會也都是在新竹居多, 但是那個比較像是讀書後心得分享會, 跟我想像的讀書會不太一樣. Soft & Share這次辦網路讀書會似乎有解決到某些人的需求, 尤其是中南部的網友, 有幾位網友跟我說, 他們期待這個網路讀書會可以辦的起來, 這樣就不用專門跑那麼遠的地方去參加聚會. 我自己也很期待, 如果可以在家開遠距讀書會, 真的很方便. 今天還有一件事讓我也很開心, 有一位網友在FB跟我問候了一下, 他告訴我 Soft & Share 的 Slack 是一個很酷的idea

其實講到Soft & Share是一個很酷的idea, 我有點不好意思, 怎麼說? 其實這件事我8年前做過, 細節我就不多說了, 當時那家公司的大概有200多人, 我在他們的協同平台擔任類似我目前在Slack做的工作, 就是幫他們推導工具, 線上回答問題, 並在他們的平台寫一些教育訓練文件, 那是一次蠻成功的經驗, 因為改變了一個團隊的工作習慣, 最後他們因為資訊安全理由將我的帳號停權. 一直到多年後, 我才發現我是在擔任佈道師的工作, 我第一次聽到佈道師這個名詞是有一次到大陸出差, 去參加當地的開發者聚會, 在會場上看到蔡學鏞的演講, 當時他在大會的講師介紹說他是創新工場的佈道師(要是我沒記錯的話), 我當時對佈道師這個名詞感覺比較像是Technical Sales, 就是在跟你推銷一些新技術產品, 最近在看一本書 Driving Technical Change , 才發現, 原來我自己也在做佈道師的工作. 一個系統除了要有系統管理者, 最好還要搭配一個佈道師, 這個系統才有機會run起來甚至run的更好, 這是我到目前為止一個初步的感想, 如果不對, 你可以到底下留言來糾正我. 因為我幫不少公司推過系統, 有些公司運作得很好, 有些公司就是run不起來. 我最近又開始利用Slack建置一個社群, 似乎找到了一些答案.

下週除了這週的4個讀書會, 下週又有一個新的讀書會要啟動了, 再跟班長說一聲感謝, 還有參加讀書會的網友, 班長在slack上跟大家喊話時,  要記得回一下收到 :-), 這樣班長的工作才會輕鬆.

想要加入Soft & Share的Slack社群? 加入Soft & Share Slack 

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

 

Soft & Share 週報-9

這次的週報可能跟以往不太一樣, 過去的8週週報比較像是在做剪報重點整理. 上週看了這篇文章-小端血淚史:你我如何被臉書算法改變? , 這篇文章讓我省思了好久, 裡面有提到一件是如果有經營過技術類的FB粉絲團或是社團的人最近都會有感受的-貼文的觸及率不斷在下滑, 除非付費做FB廣告, 文中講的我大概都有試過, 只有一件事沒做, 每半個小時去發文 🙂 今年確實也花了一點錢去試看看FB的廣告效果, 因為FB不斷提醒我, 增加廣告預算可以增加文章的觸及率, 昨天更好玩的是收到FB的通知告訴我第二次的廣告互動率不好, 我必須再追加預算, 這樣廣告效果才會好. 坦白說, 對於追求按讚次數, 然後增加觸及率這件事, 內心已經有點感到疲倦. 加上最近看一本書-成長駭客, 裡面有提到Facebook跟MySpace剛開始的時候, MySpace的會員數與流量都是勝過Facebook, 但是Facebook對於互動率的關注勝過流量與會員數, 最後Facebook還是取得社群的龍頭.

改變

省思之後就要做一些改變, 大約三週前, 我為了Soft & Share的電子書團購設定了Slack, 因為有參加團購的網友希望我們辦團購之外還能辦讀書會, 第一時間我是在FB申請了社團, 然後讓有參加電子書團購的網友去加入, 然後利用FB社群能做一些交流, 但是我們團購的書籍有跟專案管理有關, 有跟設計有關, 也有跟Node.js有關, 將這些網友聚集在同一個FB社群其實是有一點怪, 但是如果為每一本書建立一個社群這有超出我們的工作負擔. 一直到有一天我在FB的邏輯思維社群看到社群的版主說他想成立邏輯思維的Slack做線上討論, 想加入的就將e-mail給他, 其實我在公眾社群是不太喜歡將自己的e-mail就這樣貼在上面, 因為可能會收到不少垃圾郵件. 但是基於對Slack的好奇心, 我將e-mail交給他們, 沒多久我就收到一封slack的邀請信, 就這樣加入了slack, 其實早在一年多前我就申請了slack帳號, 因為slack很紅想要了解為何這樣的聊天室軟體會這麼紅. 但是裝起來後有點失望-不就是聊天室, 我相信應該不少人跟我有同樣的想法, 為何一個聊天室軟體可以稱做企業協同溝通軟體? 這樣一個簡單的idea在矽谷是紅翻天, Slack很多功能其實都必須要靠外掛才能稱得上是企業協同作業平台, 因為過去我賣了企業研發團隊協同作業軟體賣了10年. 我對這塊市場相當熟悉, 光靠聊天室要賣到企業, 又要走SaaS的模式在台灣很難做, 在台灣做企業軟體都要包山包海, 還要送一些東西, 客戶才會覺得划得來. 於是我當時申請後就沒有繼續用下去一直到我進去了邏輯思維的Slack.

使用Slack建立讀書會

於是我也如法炮製, 3/12在社團宣布我要將FB社團搬到Slack, 那個週末包括有參加電子書團購的客戶大概將近300位網友加入, 於是我開始經營起了Slack, 但是我對Slack的管理相當陌生, 只會建立Channel, 邀請網友加入. 但是我相當幸運, 我遇到幾位網友, 他們對Slack很熟開始在線上教我如何設定Slack , 安裝Bot. 這種經驗其實很妙, 這是我在過去剛開始經營Facebook粉絲團從來沒有的體驗, 在Slack中的網友的互動變得很密切, 在Facebook的互動感受最快的就是看到按讚的次數很少有網友來留言, 即使我經營的粉絲頁人數已經達1萬人, 但是在Slack很直接, 因為每個人一進去就會講幾句話, 主客的界線沒有那麼遠. 這應該跟Slack的本質有關-它本質就是聊天室, 一進去就是很自然看到人就會哈拉幾句.

使用Slack做線上讀書會效果好嗎?

剛使用Slack時除了以上說的互動變得很頻繁, 還有就是我可以為每本書建立一個Channel, 有買那本書的網友就自己去加入那個Channel, 然後他們就可以在那個Channel討論書的內容, 哈, 這是我原本的構想, 可是效果很差. 剛開始可能是新鮮, 但是每本書的Channel建立好後沒多久互動就冷了下來. 這個我大概觀察了2週. 雖然把人帶進了Slack, 但是沒有互動的社群就像沒有朝氣一樣. 人數多並沒有太大的意義.

開始思考讀書會應該怎麼辦?

我為這個問題想了很久, 一直到有一天看到蔡志浩老師的文章, 那篇文章很有趣, 是蔡志浩老師將他過去在twitter寫的隻字片語收集起來變成一篇blog, 沒多久我又看到另一篇蔡志浩老師的另一篇文章, 他最近在看運動營養學, 於是他把每一章的重點摘要像twitter一樣寫下來整理成一篇讀書心得. 其實這件事我也常在做, 但是我並沒有將我畫的重點收集成一篇讀書心得. 但是蔡志浩老師的這兩篇文章卻給了我很大的啟發. 如果讀書會是讓每個人畫重點, 分享重點, 這應該不會很難吧?

開始實驗

這期間我在FB的po文, 無論是分享別人的文章, 或是自己的文章, 我都會在下方放一個Link, 表示我準備了一個Slack, 可以用來開讀書會. 但是這個舉動只是引來流量, 對於開讀書會這件事並沒有幫助, 就像我剛開始講的Facebook跟MySpace案例一樣, 最後是強調使用者互動的Facebook勝出, 流量一點意義也沒有. 一直到有一天早上, 我在Node.js社群看到一位網友polo說他想辦NodeJS的讀書會, 於是我跟他接洽問他是否願意在我的Slack辦讀書會, 我可以幫他宣傳, 他很爽快就答應了, 那一天我幫他宣傳有NodeJS的讀書會並且是在Slack上辦,當天Slack人數從300多人成長到400人左右. 但是這還是沒有解決我心中的問題, 讀書會該如何在Slack上進行? 要如何讓Slack上的網友互動起來? 雖然人數很多, 但是問題跟之前一樣. 大家進來表示要學NodeJS, 第二天就冷下來了, 不過這個讀書會後來在polo的帶領下, 辦得很成功, 後來人數太多還拆成了4組.

讀書會該如何進行?

上週六, 這天是一個很大的轉變, 我一早起床腦海裡大概有一個讀書會的藍圖, 人數不可超過10人(這個經驗跟我以前當過技術經理有關), 每個人都要分享重點, 每個讀書會都要有一個班長負責-因為我們的人力資源與時間有限. 那天早上我還是如法炮製, 去其他社團分享文章順便宣傳我這邊可以辦線上讀書會. 當天的人數不斷的攀升, 我覺得有點妙, 因為那個社團是比較像是UI/UX設計師的社團, 我分享了一篇文章, 內容是UI/UX設計師必讀的好書, 每位網友一進來就開始自我介紹, 並表示他/她對UI/UX很有興趣, 想要參加讀書會學習UI/UX. 隨著人數不斷攀升, 我心裡想, 這誤會可大了, 他們該不會以為我要辦跟UI/UX有關的讀書會? 所以跑進這個社團. 過沒多久另一位網友跑到general channel來問這邊有沒有人在研究growth hacking? 很巧, 我當時就在看這本書, 於是隨手拍了一張照片回她說: 妳是在問這本書嗎? 我心念一轉, 既然我自己在讀這本書, 何不將自己心中讀書會的藍圖來實現看看, 於是我跟她說, 我們來辦這本書的讀書會吧!, 我來當班長. 後來這本書的讀書會包括我那班一共辦了三班, 而且是不同的班長帶領.

有了第一本書的讀書會, 我開始找讀書會班長的適當人選, 其實我並沒有特別去挑, 只要願意, 我就會跟班長講一下我的概念, 設計心理學這班的班長就是這樣找來的, 她一進Slack就到#self-introduction自我介紹, 我就主動過去跟她打招呼, 並問她是否有意願來組讀書會? 我很幸運, 第一次這樣的邀約就得到Yes的回答, 這給我很大的信心, 於是陸陸續續我找到了5位班長. 每位班長都有自己的特色, 這是一個很有趣的過程.

這一週下來我一共組了6個讀書會, 每班都是額滿狀況. 我覺得我很幸運隨機挑到的班長都很活潑也很盡責, 如果你有加入他們的讀書會應該可以感受得到他們的熱情, 他們都是以當義工的方式來當班長, 我並沒有支付薪水給他們. 希望你能給他們多一些鼓勵與掌聲. 如果這5個讀書會可以辦得起來, 這也是我過去從來沒有的經驗.

目前進行中的讀書會

可以參考這裡 列出了目前進行中的讀書會, 裡面也有描述我們會如何進行讀書會, 目前每班都是額滿, 但是我有寫如何加入候補, 與如何申請班長.

未來會再辦下去嗎?

目前我對外的回答就是-如果有人自願出來當班長, 我就會辦下去:-) 所以就隨緣了!

FB的社團跟粉絲團還會繼續經營?

短期內不會收起來, 但是我們應該會放比較多的心力在Slack線上社群與讀書會經營.

想要加入Soft & Share的Slack線上討論群組與讀書會嗎? 加入Soft & Share Slack 

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

Soft & Share 週報-7

這週末又是陰雨綿綿, 沒事在家看看週報, 看看書到Soft & Share的Slack聊天室跟大家分享讀書心得也不錯, 祝大家週末愉快!

Soft & Share 服務介紹

  • 職缺刊登免費刊登職缺服務就到3/16截止了, 分享一下這一個月來幫客戶刊登職缺的經驗, 我先說明一下我們服務跟其他公司不一樣的地方
    1. 目前市面上所有刊登職缺服務的公司是不會幫您校稿的, 校稿不是錯別字而已, 公司代表圖, 職缺內容說明, 我們都會給一些建議, 因為我們想幫公司找到對的人, 如果職缺介紹都寫的2266, 怎麼找到對的人? 不要懷疑, 我們已經因為這樣回絕兩家公司來刊登了, 你應該不會聽過刊登求職網站會退客戶的稿.
    2. 我們的版面雖然不是最炫, 但是在各種裝置上看, 都很美觀, 上週一位客戶很高興我們提供優美的版面幫他們刊登.
    3. 如果一個職缺經過仔細介紹說明, 還有一張代表公司產品, 文化的圖, 經過實驗, 點閱率跟一般只有文字敘述效果會差很多. 當然一家企業文化的描述還是最重要的.

    3/16後我們就開始收費了, 一個職缺NT199, 如果您看了我們還幫客戶校稿, 給建議, 上傳輸入, 幫客戶宣傳, 划算吧! 已經有兩家客戶給予我們正面的評價.

好書推薦

  • Driving Technical Change  推薦一本好書, 你會發現這是你我都會遇到問題的書, 舉個例來說, 你有沒有發現前端開發技術的演變非常快, 而你剛好是熱衷改變的熱血前端開發工程師, 你發現使用ReactJS開發前端會比較好, javascript該採用ES6了, 可是你的團隊中就是有些討厭的傢伙不願意配合,甚至跟你唱反調, 這時候你該怎麼辦?, 這本書就是在教你解決這個問題.
  • The FINTECH Book 這本書是Soft & Share網友主動發起的讀書會, 最近有個名詞很熱門FinTech, 這本書目前在國外似乎很熱門, 而且採用預購的方式, 如果對FinTech這個主題有興趣, 歡迎加入Soft & Share的Slack讀書會.

 

AI

  • AI人工智慧是? 為何要有它? 對我們有何影響? AI為何存在?帶來的影響是?最近最熱門的話題莫過於AlphaGo, 有一大部分的探討都是圍繞在AI未來將取代人類的工作, 但是卻比較少談到AI怎麼幫助人類解決問題, 看一下這個台灣的新創團隊, 他們嘗試用AI來解決什麼問題

App行銷

Android

  • Bottom navigation Google向iOS致敬? Android以後也支援Bottom navigation, 其實這樣不錯, 以後UX設計階段就不用顧慮平台的差異性, 這對UX設計者是一大福音, 不過對於那些開發跨平台的framework公司也是, 例如 React Native.

C/C++語言

  • /Collections-C  寫C語言如果要實現Link list, Hash, queue都要自己去實現, 這個opensource則幫你都寫好了. 以前面試工程師都會考一下如何利用C語言實現資料結構, 現在的程式設計語言幾乎都內建, 直接拿來用就好了

  • /easyLambda  最近發c/c++相關的opensource好像都特別受歡迎, 根據上一篇分享統計使用C/C++的programmer都是老頭子XD , 難道這個社群有老化的現象 ? 分享一個C++ library, Lambda這個名詞如果你是用Java 8應該不陌生, Javascript也不陌生, 當代語言都有Lambda的支援, 但是C++? 看一下這個opensource描述, 如果你是用c++在做資料處理, machine learning, 要實現map and reduce, 可以參考這個opensource是如何實作的甚至直接拿來用, 小編必須坦白說, 以上說了這麼多名詞看似很懂, 小編還是big data, machine learning的外行人

Git

  • Git 的安全性問題 自己架設Git Server又開放在公眾網路上存取, 要注意一下版本是否有更新

iOS開發

Java

  • 12 Tips write secure java code 幾週前辦了一本書的團購Secure Your Node.js Web Applicationhttps://goo.gl/eoGynK , 這本書所有團購書中反應最熱烈的, 可見寫程式是一回事, 寫出安全的程式碼又是另一回事, 這篇文章是跟java有關, 12個關於寫出安全的java程式設計技巧

JavaScript

  • hotjs 收集Javascript與Web前端開發資源有關的網站

Python

  • /DeepLearningFlappyBird 好酷的專案, 雖然2年前已經有看過國外的開發者做過http://goo.gl/rIiLQz , 這次這位台灣者使用TensorFlow, 想學這些背後的原理, 裡面有說明他是參考哪些文件跟論文. 覺得他做得很棒, 進去幫他按一下星星吧

  • PYTHON REGULAR EXPRESSIONS 如果您有使用Python開發網頁爬蟲, 應該會常用Regular expression, 這篇詳細介紹了regular expression在python的用法

  • regexper.com延續今天分享的Python regular expression的那篇文章, 小編覺得regular expression在程式設計中實現並不難, 因為現在許多程式設計語言都有現成的library or api可以呼叫, 難在怎麼去設計regular expression, 還有看懂現成的regular expression也是一個問題, 例如你看得懂這串regular expression在做什麼嗎?/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/發現一個網站 https://regexper.com/ 可以將regular expression視覺化, 對於學習看懂別人的regular expression多多少少也有幫助
    Regexper

 

OpenSource

  • GitHub News: Discover the top trending repos 想要追蹤現在最熱門的Github專案嗎? 到這個網站用e-mai訂閱就可以了

  • Open Source: Top 100 Influencers and Brands  前一百大具有影響力的opensource和品牌

  • 從「下町火箭」談開放原始碼 在軟體業有一個說法不要重新發明一個輪子, 但是如果您要做技術創新, 很抱歉, 就是要不斷的發明輪子, 這是一篇很不錯的省思文章, 裡面還有提到國外大廠的opensource策略, 包括上週分享的那篇 Java在Docker上違法的問題

  • 经验:如何正确的使用开源项目  這邊常介紹一些opensource, 看一下這篇講得如何正確使用opensource, 根據小編的經驗, 用opensource有幾種類別, 第一個是end-user, 這類別的人, 小編通常建議他們最好還是要花錢買商業支援, opensource不代表免費, 支援一下那些辛苦奉獻的開發者也是功德一件, 第二種人, 拿opensource來開發的人, 小編會建議, 如果你拿opensource來當作產品的基石, 最好看一下別人的code是如何寫的, 發現問題最好修好後也回饋給原作者, 但是小編經常發現台灣的公司發現opensource的bug, 或是自己加了一些功能後就沾沾自喜, 甚至還想拿這個修改後的opensource出來開公司 XD , 這是真實案例. 第三種人當然就是大家稱的 ‘神人’ 他們不僅用opensource而且本身就是opensource的貢獻者 , 最後當然是要注意一下opensource的授權問題.
  • Open-Source API Management and Microservice Management  有在開發RESTful API可以參考一下

 

UX/UI

  • git-sketch-plugin Sketch應該是現在最熱門做App的前端設計工具, 但是要如何做版本控制呢? 這邊有一個免費的Sketch Plugin就可以整合Git, 甚至可以讓你比對不同版本的差異.
  • Sketch 的整份文件換色 好強大的Sketch外掛, 介紹給你合作的設計師, 也許她/他會請你喝咖啡

  • 【高效率App開發術】Wireframe、Mockup、Prototype 傻傻分不清楚!? 這三個名詞, 你有分清楚嗎? 沒看這篇文章前, 小編一直以為這三個名詞指的是同一件事

  • InVision acquires Silver Flows, a tool for prototyping inside Sketch 這應該是昨天很大的新聞, 製作Prototype的工具競爭真的很激烈, 前一陣子買Flinto送Sketch, 未來在Sketch中就可以做Prototype, 那誰要用Flinto呢? 所以Flinto早就知道這個Silver Flows會對它產生殺傷力? 這個新聞還有一個爆點, Silver Flows這家公司在台北新莊, Founder還是一位老外 https://goo.gl/IAij62

  • App UI 設計師該不該學寫程式  App UI 設計師該不該學寫程式? 小編真的很佩服會寫程式的設計師, 基本上他們根本在搶攻城獅的飯碗啊 tongue 表情符號, 這篇文章後面講到重點了, 其實程式設計師建議應該也要學會一點設計流程, 兩個不同領域的人要一起co-work, 最好的方法就是懂一些對方的工作, 讓彼此的合作更順暢,其實設計師可以不用學寫程式我認為互相了解對方的想法,比起義無反顧的去學寫程式來得重要。例如:工程師讓設計師了解,iOS 對於元件樣式修改的限制在哪,哪些地方可以換顏色,哪些地方可以改大小,排版又是怎樣的邏輯與規則…。設計師也讓工程師了解,設計師所使用的顏色、樣式、格線…的 Design Style Guide,讓工程師可以快速製作,不用再算座標,不用再查色碼…。可以加速開發,或者讓溝通更順暢。

  • Framer & Sketch: An Intentional Workflow  這篇是由Facebook的Product designer分享的文章, 他介紹了他使用Framer & Sketch的設計流程與經驗分享, 這篇文章底下他還將文章的範例Framer的source code & sketch檔案放在github讓您參考, 小編建議程式設計師應該也要學習一下設計師使用的工具和流程, 小編發現目前設計師社群有一個聲音, 程式設計師無法達到他們要的視覺效果. 於是他們也興起學習程式設計想知道問題出在哪裡? 視覺設計與程式設計中間確實有一個gap, 這個gap要消除只有靠彼此互相學習,對Framer有興趣, 歡迎參考
    https://goo.gl/3OctTw 這邊有整理一些跟Framer相關的資源

  • How To Integrate Motion Design In The UX Workflow  以前聽過很多案例說客戶無論如何每個畫面切換一定要動畫, 以UX觀點, 為何要做動畫?, 何時該採用動畫效果? 這篇講解的很清楚, 後面也整理了許多做Prototype的工具, 後面有一段話值得注意, 這也是最近很熱門的一個話題, Designer需要會coding嗎?A UX designer who is comfortable rolling up their sleeves and digging into the code will be more in control of the details. They’ll also stay grounded in reality. This requires a comfort level with HTML and CSS and sometimes JavaScript.

開發者統計

其它

  對於加入Soft & Share線上討論群組有興趣嗎?   加入Soft & Share Slack 

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

由 WordPress.com 建置.

Up ↑