雖然這篇merge軟體鄉民發文沒有被收入到精華區：在merge軟體這個話題中，我們另外找到其它相關的精選爆讚文章
在 merge軟體產品中有12篇Facebook貼文，粉絲數超過4,674的網紅小金魚的人生實驗室，也在其Facebook貼文中提到， #一群人一起做華爾街日報的主題研究到底有什麼樂趣 #或許不能凡事只看樂趣 上週六結束了第三次的 #雙週華爾街日報導讀，我覺得我有幾個非常感動的點，我想要寫出來跟大家分享。我想要分成三個部分： 一、我的before and after 二、我對華爾街日報導讀讀書會的觀察 三、商業觀察舉...
同時也有2部Youtube影片，追蹤數超過2萬的網紅奮game王紫楓，也在其Youtube影片中提到，#軟體工程師 👍歡迎訂閱!! 🔔🔔按下小鈴鐺，就可以一有新影片就搶先看！ [軟體工程師雜談] 輕鬆搞懂演算法:合併排序(merge sort) |IT鐵人賽: 從零開始搞懂寫程式，資工系4年最重要的學科，資料結構，演算法，物件導向 課程滿意度問卷調查:https://forms.gle/g47...
-
merge軟體 在 奮game王紫楓 Youtube 的最讚貼文
2020-09-25 00:33:39#軟體工程師
👍歡迎訂閱!! 🔔🔔按下小鈴鐺，就可以一有新影片就搶先看！
[軟體工程師雜談] 輕鬆搞懂演算法:合併排序(merge sort) |IT鐵人賽: 從零開始搞懂寫程式，資工系4年最重要的學科，資料結構，演算法，物件導向
課程滿意度問卷調查:https://forms.gle/g478ZPC1nwX3AEBWA
IT鐵人賽網址:https://ithelp.ithome.com.tw/users/20128489/ironman/3093
程式新手學習發問區，問都給問!!: https://www.facebook.com/groups/914880435669061
紫楓FB專頁: https://www.facebook.com/tbpfs2/
紫楓blog: https://tbpfs1.blogspot.com/
斗內專線: https://pse.is/KUYMP
部分圖片來源: http://l.ovoy.click/vc97y![post-title]()
-
merge軟體 在 網頁設計x廣告行銷 Youtube 的最佳貼文
2020-06-09 08:00:00❤免費訂閱Free subscribe❤
https://pse.is/submytube
❤聯絡我們 Contact Us❤
https://pse.is/forums_op
---------
✪✪✪FYR 補充資料如下✪✪✪
影音剪輯軟體 Premiere Pro教學#07 | 多序列合併剪輯| Mutiple squence edit and merge
■商業行銷&設計資訊相關討論區
https://freeday.cc/forum/index.php?p=...
■網站主機代租管理服務 wordpress/opencart/moodle/forum■
https://pse.is/forums_op
■Wordpress免費架網站教學
https://www.youtube.com/playlist?list...
❤小額贊助頻道 Donate us a cup coffee❤
https://www.paypal.me/178yo
簡介
我們從2015年以來開始從事數位設計及網站架設的工作，我們擅長CMS系統架構 像是 php、wordpress、woocommerce、opencart、forum論壇討論區、數位課程moodle等系統開源軟件。
從模組設計和專屬客製化修改、到線上電商的金流物流功能，相信我們都能滿足您的期待。
在網站開發完成的後期，不論主機系統維護以及seo、 google ads廣告行銷、影片設計、平面媒體設計我們也能協助您。
至今目前所服務的客戶群產業有：
政府學校機關、教育機構、房地產業、旅行業、旅館飯店、線上電商、中小企業形象網站…
同時我們也期盼透過這個頻道可以幫助到有需要的人，協助自行建立數位的行銷系統及網頁在有限的預算內。
■聯絡我們 Contact Us
https://pse.is/forums_op
#網頁設計x廣告行銷![post-title]()
merge軟體 在 小金魚的人生實驗室 Facebook 的精選貼文
#一群人一起做華爾街日報的主題研究到底有什麼樂趣 #或許不能凡事只看樂趣
上週六結束了第三次的 #雙週華爾街日報導讀，我覺得我有幾個非常感動的點，我想要寫出來跟大家分享。我想要分成三個部分：
一、我的before and after
二、我對華爾街日報導讀讀書會的觀察
三、商業觀察舉例
▌一、我的before and after
這是一個為自己而讀的讀書會，因此我想要從自身出發。
#我的自我成長小觀察
華爾街日報導讀進行了三次了，我發現自己有三個很大的變化。
1. #我變得更好奇而且看新聞很仔細
以前看這些新聞會覺得「這跟我有關係嗎？」，就直接隨便看過了。但其實，只要我們仔細的觀察就會發現：當然跟我有關係阿，只是很近的關係，還是很遠的關係，但是一定是有關係的。因為世界的趨勢總有一天會影響到你，只是你有沒有發現而已。
2. #我不排斥看最原始的資料了
以前，都想看別人整理好的，覺得原始的新聞稿、資料好無聊、好長、不知道重點在哪裡，但是從第一次藉由主題是IPO而第一次看到了IPO公開資料發現根本是寶庫之後，就開始了一系列的驚奇，大家看下面我的舉例就會知道：我竟然從一個日本Yahoo與LINE的合併參透了前公司之前為什麼會受到政府的阻擋。如果你可以懂得更多，你會從「單純直覺」到「理性判斷」，這會幫助你最更多、更複雜的決定。
3. 勇於承認自己真的不會
因為題目太多元化，從IPO到晶圓到電動車到線上支付，我不可能每個都懂，而且最有可能的事情是：我都不懂。但是透過第一點以及第二點，我發現「這其實沒有什麼大不了」，我甚至是會在其他人分享的時候舉手說「這個我不懂，可以多說一點嗎？」，因為你承認你不懂，有人解釋，你就懂了。
我一直相信：真正的強者並非一開始什麼都懂，而是知道自己不懂的地方是什麼，並且加速跟上，在需要的時候懂，那就足夠了。
▌二、我對華爾街日報導讀讀書會的觀察
聚集一群願意努力而且又是各個產業人才的結果是什麼？就是我每一次雙週華爾街日報導讀前壓力都很大（不騙人），為什麼？
1. #所有的人都精心準備
我怎麼知道？因為就11個人阿，大家手上的資料很厚，畫心智圖的人有不同的圖、連結、文字敘述，我可以感受到大家儘管不一定全部都了解，可是是嘗試努力了解（因為每次主題差異非常大），可是就像萬維鋼說的，#通才就是在不同的議題當中都嘗試與這個世界的理解同步。
2. #沒有人遲到早退缺席
週六早上10:00 - 12:30，這時間真的不是在開玩笑的，是真的早阿～～～畢竟是週六，而且，我必須說，我們每次都有一個同學從彰化上來。（因為我們地點義無反顧在北車的小樹屋）你的學習、你的成長是自己掌握的，我們沒有逼迫任何一個人，你需要為你自己而讀。
3. #所有人樂於回饋他人
我非常非常喜歡每次有人分享完，就會有同學舉手說「我想要回饋剛剛的分享者」，真的，我每次都覺得很快樂，說了很多我平常絕對不可能知道的事情、公司、歷史淵源，甚至是暗黑秘辛。每次都忍不住又嚴肅又大笑。
學習是痛苦的嗎？是。
但是，如果你可以找到一群人，#那你會痛苦的快樂著。
#我覺得我找到了。
▌三、商業觀察舉例
如果說華爾街日報導讀還有一個加分的點，就是我們連在自己的小型line群組都可以隨時討論起不同的議題，例如今天的議題就是：
#日本雅虎母公司ZHD與通訊軟體LINE正式合併完成
#成為日本最大的資訊科技公司
我首先注意到的是這段話：
「ZHD的母公司是日本行動電話大廠軟體銀行公司（SB），SB的母公司是軟體銀行集團（SBG），由孫正義擔任董事長兼社長。LINE將成為ZHD的子公司。」（請參閱相關連結①）
這個關係簡直是跟連續劇沒有什麼兩樣，就是一個複雜的關係圖。
這時候有人提出一個疑問：
「這樣台灣LINE會有影響嗎？雖然是隸屬於韓國NAVER。」
欸等等，LINE是韓國的！？
我一查詢才知道，首先LINE真的是韓國NAVER創立的，只是它在日本創立，其因為331大地震，我們又愛又恨的「已讀」功能就是在地震的時候，因為訊號不穩定，已讀至少讓對方知道我看到了。
為什麼叫做「LINE」呢？起因於當時排隊打電話的人潮一直很多，一長條的線「LINE」，於是取名LINE。
LINE在台灣、日本、泰國都是主要的通訊軟體，但在韓國不是XDDD
有了這個基本的概念後，我又看到了一篇報導寫：
「日本雅虎（Yahoo Japan）與 LINE 的聯姻，在台灣也得通過競爭審查這關，公平會於昨（29）日審議這起日韓二大外商集團結合案，考慮兩造現行專精領域差異、未來大數據潛力等因素，判斷不會有害本土市場競爭，全案通過。」（請見相關連結②）
於是我有一個疑問：請問，人家要合併，為什麼我們要審查啊～～～
這時候群組的人找出了一篇說明文章，我看了才知道，原來是因為「公平交易法」。（請參閱相關連結③、詳細資料規則請參閱相關連結⑤）
既然是政府的決定，我找到了一個公開的公平會新聞稿。
我覺得看這類型的分析文，跟我之前看91APP的IPO公開文件一樣有趣，你可以知道人家是怎麼在看這件事情的。（請參相關連結④）
有幾個我看到的重點：
1. 首先參與了這次的結合案總共有三方：SB、NAVER、LINE、日本Yahoo，於是在公平會看的就是當這四方有結合的時候，對台灣的影響為何。（也是整篇新聞稿的重點）
2. 我訝異的是，SBG在台灣是有庶務的，而且還有兩個。分別是Arm Limited之「微處理器及系統之研發與授權」及Brightstar Re, Ltd.之「再保險、智慧型手機回購及換購」，雖然我不是很懂，可是至少知道原來SBG是跟我們有關係的。
3. 因為結合案是LINE與日本Yahoo結合，也就是說，不排除未來日本Yahoo可以藉由LINE銷售，因此，有疑慮可以切入台灣的市場。
在這裡，看到公平會的邏輯是：
（1）若是真的發生，那麼台灣消費者需要負擔較國內網購平臺更高之運費，並忍受更長之運送時間。
（2）台灣的網購平臺多屬綜合性零售商，並非只銷售來自特定區域或特定品類之商品，故即使結合後日本Yahoo以LINE作為入口切入我國電子商務市場，其取代之對象較有可能是日本商品之國內代理商或供應商，而非一般綜合性網購平臺。
（我其實在這一段突然懂了之前淘寶進入台灣的時候，政府查核的思考邏輯是什麼了XDDD 果然商業的世界很複雜，是需要一步一步來理解的。）
除了這個之外，我還自己畫了一張關係圖，結果發現，公平會的新聞稿中早就畫好了一張，而且還標示出股份所有權佔比。（我自己畫的以及公平會提供的我都放在留言）
我想，這是我在商業討論裡覺得有趣的，也是我訓練自己的，未必每一次都可以得到很多的收穫，但是，商業無所不在，每次練習一點點，就是很好的練習。
▌結論
華爾街日報導讀的起源只是我跟 Sandy's Recruitment note去年臨時起意的一個挑戰，起因於Sandy是風傳媒華爾街日報的代言人，而我們又想要讓自己更精進。
於是我們跟自己承諾了雙週六來執行，為了品質，這是一個封閉式討論。
這麼拉哩拉雜的寫出整的過程，是想鼓勵大家，研究商業不是一蹴可幾，但也不是窒礙難行，我們可以從小地方開始，帶著好奇心，歡迎你們也自己組隊來體驗這麼有趣的世界：）
► 相關連結
① 雅虎日本與LINE合併 成日本最大IT企業（新聞來源：中央通訊社）：
https://www.cna.com.tw/news/firstnews/202103010231.aspx
② 日本 Yahoo 合併 LINE 一案，台灣公平會也審查過關！（文章來源：INSIDE）：
https://www.inside.com.tw/article/20519-yahoo-japan-line-merge
③ 日本雅虎與 LINE 結合案，公平會准了（新聞來源：TechNews）：
https://technews.tw/2020/07/29/japan-yahoo-line-ffc/
④ 不禁止有關SoftBank Corporation、Z Holdings Corporation與NAVER Corporation、LINE Corporation結合（新聞來源：公平交易委員會）：
https://www.ftc.gov.tw/internet/main/doc/docDetail.aspx?uid=126&docid=16384
⑤ 是否所有的事業結合都要向公平會申報？（資料來源：公平交易委員會）：https://www.ftc.gov.tw/internet/main/doc/docDetail.aspx?uid=1206&docid=14284
merge軟體 在 91 敏捷開發之路 Facebook 的最讚貼文
【code review V.S. pair programming】
網頁好讀版：https://tdd.best/blog/code-review-vs-pair-programming/
昨天大女兒早上去學校、下午去上美語、晚上去游泳，回來已經很累很晚了，一直猛打哈欠。在去游泳之前，已經讓她把學校作業先寫完了。
睡覺前收拾書包，太太檢查她新的國字（硬體字筆畫）作業寫得怎樣，因為是第一次練，當時寫作業又蠻趕時間的，又沒大人在旁一起看，所以蠻多內容寫得只是有形狀，但很多細節都不對。
我癱在按摩椅上，聽著太太跟女兒隔著餐桌坐在對面的對話。
—
太太：「你覺得你寫得跟上面的字有一樣嗎？」
女兒：「一樣啊！」
太太：「有嗎？你仔細看看」
女兒：「一樣啊...」
太太：「你那個字最後那邊勾了起來，上面的字有勾起來嗎？」
女兒：「我沒有勾起來啊...」
聽著這段對話，讓我想到一些軟體開發過程常見的場景....所以我正瞅著何時去摻一腳。
接著大概連續10次，女兒寫了字，太太只說著問題在哪，女兒擦掉，再寫一次，還是一樣的問題，不斷 repeat。
她一直在打哈欠，因為一天上三種課，從早到晚真的很累，之前有約定過要避免這樣上課，為了避免她在根本不知道怎麼寫才會「對」的無限循環中崩潰，我決定起身。
「將她們從 code review 的形式改成 pair programming」
—
我：「怎麼啦，唷，你開始練習寫國字啦」
女兒：（嘟著嘴巴，含著眼淚，沒力氣跟心情多說一句話，繼續把她寫的字擦掉）
我走到她的身後，伸出兩隻手環著她。
我：「我來看看是哪個字，哇，這筆畫也太特別了點，你這後面好像往上翹了」（我刻意不用勾的字眼，因為他們剛剛才吵過這件事）
我：「要不爸爸幫你用橡皮擦，你再寫一次我看看會不會就好了。」
擦掉之後，她再寫了一次，還是歪歪的。
我問她：「嗯，這邊還是有點問題，你覺得呢？要不要爸爸再幫你擦掉？」
她仍然沒講話的點點頭。（她處女座的完美主義）
我再擦掉之後，跟她說，爸爸握著你的手一起寫。
接著我就在後面握著她的手，告訴她另一隻手壓著本子，我們一起寫了那個字。（估計此時對面的老婆應該要很羨慕嫉妒渴望才是，但我無暇理會她的眼神，我現在要專心跟女兒寫作業）
結果我們一起寫的字還是歪七扭八。
我告訴她：「這真的不簡單，要不換爸爸試試寫寫看。」
我把字擦掉，寫了一遍。醜醜的，再擦掉，再寫一遍，還是不到位。我笑了笑：「這真的要寫漂亮沒那麼容易。」
女兒聽了，說著她要自己練習寫。我幫她擦掉之後，她照著上面的字描了一遍，再到格子裡練習一遍，終於通過媽媽的標準了。
昨晚的例子就到這邊終了。
—
很多目前軟體產品開發還蠻上軌道的客戶，他們現在的瓶頸都是在 code review. 要嘛 review 容易變成瓶頸、要嘛因為瓶頸導致時間緊迫而淪為橡皮圖章的形式，又或者只是看看 code diff 之間的差異、寫法有沒問題，只能指出寫得好不好，而無法確認寫得對不對。
「先落實 code review, 形成瓶頸之後 試著用 pair programming 解決」我經常這樣建議那些覺得該 code review 但覺得 pair 不實際或是有抗拒的團隊。
code review 就像稽核，常見有幾個特點：
1）稽核沒過，代表沒完成，不給過關的。
2）稽核人員跟開發人員的目標不完全一致，稽核人員更偏重於把關，尤其是品質。而開發人員最大壓力來自於時程。
3）稽核是落後指標，發現問題時間點越晚，修復成本越高。加上責任落在要扛時程的開發人員，往往來來回回壓力會越來越重，要嘛心情受影響，要嘛放掉品質受影響。
4）離線（非面對面）斷點式的往返（context switch)，大部分工程師傾向在線上留下 review comments, 而不是坐在一起面對面溝通，哪邊寫法有問題，了解作者的考量是什麼，我們怎麼達成一致的共識後交付。
對雙方來說，這樣多次斷點式往返，只依賴 comments 上的文字描述，會有許多誤解、中斷、等待的浪費。
這很像甲乙方的驗收方式，只是都是團隊內的工程師罷了。
我們整體最終目標（也該是共同目標）應該是：「在時程內有品質地交付我們兩有共識的程式碼。」
所以建議大家從這種傳統的線上 code diff review, 線上 comments, 來來回回後允許 merge 的形式，改成 reviewer 要 review 時跟作者約個時間，帶著電腦坐在一起，照著 reviewer 對需求的瞭解，以及他自己的思路，去看跟作者設計、寫法不一致的地方（經過了共同的 refinement, 驗收情境, planning part2，再從 test case 出發來看整體產品程式碼的設計），進行瞭解與討論，雙方持續有共識地一起修改調整，最後兩人一起完成這段 feature final commit，merge 回 trunk。
By the way, 我通常建議 reviewer 主導這個過程，用她的思路往下推進，而不是讓作者自己先描述作法跟思路，一來避免錨定效應，二來實務上看code的人不會聽到作者解釋和說明，得試著在沒有作者解說下，讀者能用最短時間、最少腦力、正確地理解程式碼的意圖。
兩人一起承擔時間、品質、對程式碼有共同理解的責任，只是這次擔任的角色不同而已。當下雙方都專心的完成這個共同的任務與目標。
先從 review 練習 pair, 熟悉了之後他們就會覺得那一開始就pair不就可以更早發現問題了嗎？
再搭配 scrum 那種非派工而是value-first 領工作的方式，再配合 #向上pair 的原則，團隊內 pair programming 是一件再正常不過的事了，通常也是效果最好，產出最高，但也最累的開發方式。
更別說 as a team 學習型組織，互補、增加公車指數、避免破窗、共同制定/調整規範、避免盲點、避免過度設計等等好處。
code 只要是一個人寫，沒別人看，永遠都是自己會改的那種 #養code自重 的形式，裡面真的會比「長麵筋」還藏污納垢的....
搞產品的只要那種永遠特定模組都只有特定人維護，基本上死期不遠，腐敗發臭速度超乎想像，拖越久越沒辦法，慎之慎之。
#敏捷人生
merge軟體 在 愛流浪的小風 Facebook 的最佳解答
這週的分享來跟大家聊聊一些軟體建設的基礎，因為常常在和朋友聊天的時候，談到一些公司導入敏捷開發，但執行起來卻不是很順暢的情境，所以想趁這個機會和大家聊聊我的一些想法。
使用敏捷方法進行開發最大的好處是能夠盡快的交付價值，並且收集反餽，作為快速疊代的基礎。但往往敏捷失敗最大的原因，是忽略了先建立好能夠支持敏捷方法的基礎建設，舉例來說，如果今天沒有足夠的單元測試、自動化測試，那怎麼可能保證在快速交付的同時，維持產品的品質呢？
舉一個很實際的例子，假設今天我們是一個 ”成熟” 的敏捷開發團隊，每一個 Sprint (兩週) 固定可以完成 20 個 User story，而目前團隊已經完成 100 個 User story 功能上線，我們每一個 Sprint 的目標是，在盡可能交付新的 User story 的同時，要確保原本既有的功能使用正常，這樣才能夠對客戶帶來最良好的使用者體驗。這樣的情境假設應該是每一個敏捷團隊希望達成的目標，甚至是希望能夠透過持續改進的方式，讓團隊和產品成長的同時，交付速度越來越快，但是由於團隊希望可以專注在 「交付價值」（注意這邊這個交付價值的定義），所以一切都以 ”開發” 功能為優先，在 Merge PR 或是上線前再多做一些測試確保功能正常。這一切聽起來都非常的合理，大家專注在交付價值，但是在幾個 Sprint 之後，卻發現使用者抱怨系統問題的頻率變高了？
這個情境其實是一個很常見的誤區，由於想要趕快先交付價值，讓系統上線，所以打算等有空的時候再補測試，或是先用手動測試，但卻忽略了功能成長時測試案例增加的速度，如果原本團隊已經有 100 User story，每週可以穩定交付 20 個新的 User story，那麼只要 5 個 Sprint，需要驗證的功能數量就會變成一開始的 2 倍，只要經過一年，測試的工作量就會將近變成 7 倍，通常到最後都會變成，只測試覺得有被修改的部分，或是感覺需要測試的部分，剩下大部分的功能都不會被測試到，自然而然產品就會越來越多小問題，也越來越不敢隨意修改，反而導致開發速度大幅度下降，甚至是因為不敢大幅度的修改，失去了重構的機會，然而讓程式碼更難維護，然後又發生越來越多的問題，進入了一個惡性的循環！
所以從一開始定義正確價值交付就是一個很重要的議題，在定義產出的時候，就必須要把維持產品品質最低限度的標準都包含進去，例如是否有經過 Linter 確保程式碼風格一致，所有產出的 Feature 都包含單元測試、自動化測試甚至是安全測試或壓力測試等等，讓這些成為產出的標準，自然而然就可以在持續疊代的同時，維持產品的品質，甚至是持續優化交付的速度！所以當進行敏捷開發時，必須要時時刻刻的檢視自己是否有把「品質」當作一個重要的指標，能夠很好的了解自己的產品價值所在，注重軟體開發的本質，才能夠更進一步的有穩定的疊代產出！
基本功是無論如何還是很重要的啊，如果沒有好好的打好基礎，不管用的方法工具再先進，都是跑不快的！