筆者曾任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
說真的，有些指令先存起來放，必要時是能救命的 (認真) ，大家可以先把這篇存起來留個印象，真的遇到時可以當作錦囊掏出來用 (笑)。
廢話不多說，開始教學！
不管什麼原因，總之你用了 git push -f 蓋掉了遠端的 branch。
❶ git reflog show remotes/ur_upstream/ur_branch
請把 ur_upstream 改成你自己設定的 remote origin 名稱，然後把 ur_branch 換成你的 branch 名字，執行完畢後你會看到 …
筆者曾任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
「這個年代，工程師誰不多少學點 AWS ?」
這次我讀的是旗標出版社的新書《AWS 職場實戰手冊》。
認識旗標出版社是在我大學的時候，系上學長們推薦我看的。當時我翻他們家的書，第一印象是：「字和圖都好大！」排版看得很舒爽。小朋友學閱讀從看大字大圖的童書開始，當年從旗標的書看起，也減輕了許多我初學程式的恐懼與不安，在當時網路學習資源不豐富的年代，真心地謝謝他們出版了這些好書。想當年我的 JSP (是 JavaServer Pages，不是呷尚寶早餐店) 就是看他們家的書學的。因此，在我今年六月收到旗標出版社的《AWS 職場實戰手冊》書評邀約，二話不說就答應了。
筆者曾任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
最近看到許多相關的新聞，沒有第三方 Cookie 之後，用戶隱私會更有保障嗎？整個廣告環境會變得更好嗎？ 在禁用之後，大型廣告商的護城河會提高，用戶email 會變成主要的追蹤手段，有能力做追蹤的大型廣告商依然不受影響。
為什麼會這樣說呢？其實跟技術的實作有關。
簡單來說，在技術上的解法，是在收集用戶行為的網頁裡面(e.g. 商品頁)，埋一段JavaScript ，把用戶的「識別資料」用 JavaScript 轉發出來。通常識別資料是拿用戶的 email 做匿名化編碼後的結果，廣告商透過這個識別資料來分析用戶行為並投放廣告給用戶。
匿名化可以想像成買東西時領號碼牌，號碼牌就代表你，你本人被「匿名化」編碼成號碼牌的號碼，只有店家能「識別」這個號碼並投放對應的商品給你，就跟廣告商透過匿名化的 email 投放廣告一樣。在後第三方 Cookie 時代，大部分的廣告廠商都是這樣做的，不論是 Yahoo 推出的 ConnectID 或是 The Trade Desk 推出的 Unified ID 都是採用類似的做法。
但這樣做有什麼影響呢？
❶ Email 識別資料對小型網站不友善，很難做再行銷
識別資料大多是基於 email ，小型網站需要在用戶登入的情況下，取得 email 再把用戶的行為資料發送到廣告商那裡，廣告商知道用戶逛過哪些商品，才可以投放廣告給用戶。然而，以小型電商網站舉例，用戶在瀏覽時通常不會登入，只有在結帳時才會登入。也就是說，在結帳時才發送 email 訊號給廣告商，但這麼做的意義並不大，因為你都買了，廣告商只能投放相關商品給你，精準度不見得好，例如：你已經買了相機，廣告商才收到你買相機的訊號，投放一堆相機商品或配件給你．你不見得想買。以 email 為主體的識別資料，在用戶閒逛期間不登入的情況下，小型網站會失去大量用戶的行為資料，也會很難收集足夠的資料做「再行銷」(Retargeting)。
❷ 廣告商大者恆大
大型的廣告商 (e.g. Google, Yahoo, The Trade Desk 等等) 可以只透過用戶 email 識別資料，分析出適合的廣告版位做投放。這是因為大型的廣告商本來就有第三方 Cookie 時代收集的大量用戶行為資料，只要將用戶 email 識別資料跟以前收集的用戶資料做匹配就可以投放精準的廣告了。然而，新進的廣告商並沒有這些用戶資料做匹配。沒有資料做匹配的下場，就是廣告會投放得很不準，例如：我不養狗，卻投放給我狗飼料的廣告等等，新進的廣告商會愈來愈難生存。
除此之外，對大型廣告商來說，因為以前的用戶資料累積夠多，還能做到「不透過用戶 email 識別資料」。舉例來說，在不知道 email 的情況下，把用戶瀏覽商品頁的「內容」用 JavaScript 送出，廣告商根據這個人瀏覽網頁的情境 (Contextual) 來反查這個人是誰，進而投放廣告。這些都是新進廣告商不具備的優勢。
❸ 技術整合變困難
如果網站要整合廣告功能，為了配合不同廣告商的標準，要把用戶 email 交給不同的廣告商做匿名化，以前可能只要埋一段 JavaScript 就搞定，現在還要配合後端吐出用戶 email 做整合。
在了解這些技術原理之後，下次在新聞看到什麼「不使用 Cookie」 (其實是改用 JavaScript 發送用戶資訊) 或是可以根據情境做廣告信號判別 (其實是大廣告商可以從情境反查使用者)，或是採用「某某 ID」 的技術 (其實 ID 背後是用戶 email)，就可以大致知道背後是什麼原理運作的，讀出其中況味 :)
所以，沒有第三方 Cookie 之後，用戶隱私會更有保障嗎？整個廣告環境會變得更好嗎？我個人是抱持著懷疑的態度，就如前面所說的，大型廣告商的護城河會提高，用戶email 會變成主要的追蹤手段，有能力做追蹤的大型廣告商依然不受影響。與其高舉著保護用戶隱私的牌坊，還不如直白地當個真小人。與廣告共生，也許是這個年代，我們使用這麼多免費網路服務不得不付出的代價吧！
若是喜歡我分享的內容，可以訂閱我的粉絲團《程式猿吃香蕉🍌》，在軟體開發的路上，一起分享交流，一起成長。
筆者曾任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
前陣子受邀直播課程的關係，接觸了許多初入軟體產業的新鮮人，在 Q&A 時間，我被問到最多的問題便是：
「我該如何在職涯裡持續地成長？」
針對這個主題，我們可以向知名 NBA 球星 Kobe Bryant 學習，以下將分享一段 Kobe Bryant 的訪談，從影片裡我們可以看到一個世界級頂尖球員，是怎麼持續成長、發光發熱。然而，籃球的經驗與做法要怎麼套用在軟體開發職涯上呢？這是這篇文章想要分享給你的 :)
切合本篇的題目：你什麼時候才要變強？Kobe 的答案是：把握時間在實戰比賽中，刻意鍛練自己的弱項，使弱項最終能變成你的強項。
這是什麼意思呢？ Kobe 舉例，他 13 歲時，打籃球不擅長使用左手、不擅長後仰跳投、 也不擅長低位技巧，但他卻在比賽中強迫自己使用不擅長的進攻方式，用自己的弱項來打比賽 (Play to my weakness)，因為，Kobe 看的不是短期的比賽勝負，而是長期的球技成長。
I played the longer game, because my game wasn’t about being better than you at 13.
— Kobe Bryant
簡單來說，Kobe 的目標並不是在 13 歲就贏過對手，而是將目標放在未來。反觀他高中的同儕對手，著眼於當下的勝負，只使用自己熟悉的打法贏球，等到 17 歲時，Kobe 的左手進攻、後仰跳投、以及低位技巧，經實戰的磨練，有了大幅進步，成為一位技巧全面 (well-rounded) 的選手，而同儕的球技卻停留在了 13 歲。
Kobe 的經驗看似與軟體開發一點關係也沒有，但仔細想想，這些作法能給我們什麼啟示呢？以下幾點進行討論：
小時候，矇矇懂懂地聽數學老師說：數學不是「用看的」，要親自去算。長大後才深切體會到，實作跟理論總是存在差距，而這樣的差距只能靠實戰來弭平。
以軟體開發來說，如果我們看書學了函數式編程(Functional programing)、領域驅動設計(Domain Driven Design)、測試驅動開發 (Test Driven Development) 等等高大尚的理論，卻沒有勇氣拿這些新技能來解決實際的問題。這就像是 Kobe 高中時的同儕，一直用自己習慣的方式打球，認為：
「這樣打就能贏球了啊」
「這樣寫程式就能交差了啊」
日復一日地，讓理論永遠是理論，自己的弱項永遠是弱項。你什麼時候才要變強？也成為了內心不敢直面的拷問。
另外，也有另一種的想法是：「書先唸起來放」等到用的時候再說。然而，沒有小規模的實戰過，到真實的戰場上你真的敢用嗎？就像 Kobe 招牌的後仰跳投，絕對不是先練著不用，而是從小到大，在每一次實打實的比賽中愈戰愈強。
在軟體開發實務中，使用新方法實作，甚至是刻意安排的。
雖然難免會犯錯，但只要縮小範圍，控制損失，這些實戰經驗都會讓你成長得更好。以我自己的例子來說，在樂天市場有機會在 React 剛推出時，使用在正式專案中，在 Yahoo 嘗試新的報表做法時，成為 Apache Druid 這項技術的早期使用者。這些刻意安排、跌跌撞撞的實戰經驗，都是成長的養分。
下一次，當發覺自己成長受限時，也許可以問問自己，是不是像 Kobe 的同儕一樣，使用自己熟悉的打球方式太久了？
在金融領域，以長期策略對抗短期波動是很常見的做法。有趣的是， Kobe 在打籃球這件事情上，竟也採用了同樣的做法。這裡的短期波動是指高中賽事的勝負，而長期策略是 Kobe 自我球技的提升。而這項策略同樣也可以套用在軟體開發領域。
在軟體開發領域，短期波動對個人來說，指的也許是一次開發任務、也許是一季的考績，如果我們只在意每次開發任務都要表現完美，不敢挑戰新的領域，例如：每次都開發同樣的模組、撰寫同樣的程式語言、只做主管關注的專案，雖然短期可能會得到不錯的考績，但長期下來技能反而受限了。
簡單來說就是：我們被「短期波動」的利益給綁架了。等到模組進入維護階段、程式語言過時、或是主管對專案的關注度消退，那麼技能上的短板便會一覽無遺。Kobe 高中時的同儕便是被短期的球賽勝負給綁架，而錯失了長期的發展。有句俗語可以說得很好：
不要在意一城一地的得失，學會盯著終點看
乍聽之下，用自己的「弱項」來競技，很違反常理，但其中卻隱含深刻的智慧，包含怎麼刻意練習在實戰中成長，以及用長期的策略對抗短期的波動。
Kobe 是籃球界的頂尖人物，看似和軟體開發毫無關係，然而，跨領域概念間的借鑑是我很喜歡做的事情，從中可以迸發出許多有趣的思考，文末附上訪談的完整影片，希望看了也能對你有所啟發。
若是喜歡我分享的內容，可以訂閱我的粉絲團《程式猿吃香蕉🍌》，在軟體開發的路上，一起分享交流，一起變得更強。
筆者曾任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
現今軟體開發團隊時常以跨職能團隊的形式組成，先前我有撰寫一篇文章討論：跨職能團隊是什麼？有興趣的讀者可以參考一併閱讀：
這篇文章將進一步討論跨職能團隊的優點以在常見的誤區。
本篇內容：
✔ 跨職能團隊的優點
✔ 常見的錯誤觀念與問題：七大誤區將不同職能的人放在一個緊密溝通的團隊當中，會更能理解彼此的想法，進而建立同理心 (Empathy) ，相較於傳統的流水線般的工作流程，大家僅是專注把自己的工作完成，而忽略了專案中其他的觀點。
此外，根據 Google 近年對於高效率團隊的研究，同理心是一個高效率團隊成功的重要因素。
跨職能團隊可以將專案的里程碑 (Milestone) 視覺化，各部門可以知道整個專案目前有哪些任務正在進行當中，以及彼此會不會互相影響。如下圖所示，灰色的橫軸是時間軸，將各個部門的專案的里程碑以時間軸展開，促成更有效的溝通。此外，在實務的經驗上，將任務視覺化也有促進對話的效果。
筆者任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
跨職能團隊 (Cross functional team) 是軟體業近年來非常流行的組織形式，由 PM 與設計師和工程師等不同職能的人一起設計與開發軟體，團隊中甚至是能包括公司外部的人，聽起來很不可思議，不同職能的人怎麼一起工作？這是這篇文章所要討論的。
本篇內容：
✔ 為什麼會有跨職能團隊？
✔ 跨職能團隊的定義與特色
✔ 跨職能團隊和傳統職能分工的差異跨職能團隊的出現，跟軟體開發方式的改變有很大的關係。
因為要能夠快速地回應市場變化，軟體開發的方式改變了，人們開始以更短的週期來開發軟體，舉例來說：
以做網站為例，在過去的開發方式下，我們會先作完整的規劃，再以較長的週期進行開發 (如下圖的上方列所示)，等到長長的周期 (黃色長箭頭所示) 結束之後，我們才會知道軟體的成果長什麼樣子，因為時間較長，所以當軟體釋出的時候，很有可能我們做出來的產品已經不符合市場的需要。
