分類: 未分類

Soft & Share 週報-6

以下是在FB社團這週分享的訊息, 這週Google的AlphaGo又打敗了人類, 天網真的來臨了嗎? 小編對人工智慧真的不懂, 所以沒有跟其它網站一起報導 😛 哈, 小編比較希望人工智慧可以自動幫小編出週報 :P, 祝大家週末愉快

C語言

  • Deep C 400多頁的簡報, 有耐心的看完, 可以測試一下你真的了解C語言嗎? 對於C語言已經很了解, 這個簡報應該只是複習, 這個簡報的 問答互動設計很不錯, 看簡報時不會覺得很無聊
  • Emscripten 有趣的OpenSource, 可以將C/C++編譯成JavaScript, Emscripten已經在商業化產品應用, 例如知名的Game engine Unity, 這個網頁還有兩個Demo, 在網頁上跑3D Game跑得很順
  • 高等c語言  週末分享一個Deep C的簡報, 分享人數跟按讚的人數相當多,62個分享, 100多的讚, 看起來目前在社團的網友還有很多人在工作上是用C語言, 今天看到陳教授分享的高等C語言, 對於已經是每天在用C語言開發的網友, 也是可以當作複習

 

DevOps

  • Jenkins 2.0 初體驗: Pipline的使用 Jenkins 2將groovy設為預載的套件, 真的是很方便, groovy基於JVM, 可以跟java交互使用, 所以利用groovy來做build workflow的script是不是很方便?
  • What’s in a Build Tool?  今天介紹了兩篇關於Jenkins的howto, 如果要學好Jenkins這種工具, 應該要好好來瞭解一下什麼是Build該有的功能? Build能做哪些事? 這邊有一篇文章剛好補了這個缺口, 他前面講的是比較概念性的知識, 後面就開始介紹目前熱門的Build script有哪些? 這些Build script也相對會對應到不同的程式語言與開發框架或是平台, 裡面沒有提到gradle, 沒關係請到本粉絲專頁, 往下捲你就會看到了 🙂
  • 在Docker Container裡應該避免的10件事  現在要學習Continue integration, 都會提到Docker, 所以來看Docker container要注意哪些事
  • 在Docker上運行Java程序? 你已經觸犯法律-開源中國社區 昨天才看到外國在報導, 對岸已經翻成中文了, 如果Docker只是拿來測試java web apps應該還好吧

Android

  • Tutorial : Android Runtime Permissions不同Android版本的runtime permission處理方式不太一樣, 這篇文章講得很清楚不同版本間的處理方法https://gist.github.com/dlew/2a21b06ee8715e0f7338 , 這裡收集了許多跟runtime permission相關的library
  • 用機械學習檢測Android惡意代碼 裡面有提到有將apk反組譯, 但是如果apk有保護? 裡面有提到一個免費的machine learning & data mining 工具Weka可以參考一下, Weka is a collection of machine learning algorithms for data mining tasks, 來自紐西蘭, 這個opensource還搭配一本書來學習machine learning & data mining
  • 不只自動化而且更敏捷的Android開發工具 gradle 在上一篇po文中介紹了Jenkins 2.0 對groovy的內建支援, 接續來看一下Jenkins如何幫助Android做Continue Integration, 裡面有講到一個重點Build number要在build的時候自動產生然後寫到Android app的設定檔, 這個小動作看似沒什麼, 但是當你將一切流程縫合起來, 你就會發現真是好用, Continue Integration後要做什麼? 測試->快速回饋Bug, 這個build number在回饋Bug時就派上用場了.. 這份簡報還提到很多, 值得詳細看一遍

iOS

  • Stevia 這個Opensource大幅簡化了使用coding的方式做autolayout, 它重新定義了iOS autolayout的語法(Auto Layout DSL), 如果你用程式去寫layout, 你會發現很冗長, 必須一邊run看結果然後再修正, 但是透過這個opensource定義的autolayout DSL, 在看程式碼時就知道layout會長成什麼樣, 裡面還介紹另一種很方便的開發工具-InjectionForXCode, 一邊修改code, 一邊可以看出UI的即時變化, 不用再re-compile and run

Swift

  • Swift Web framework 
    裡面增加一個連結, 示範如何將Swift Web apps部署到EC2, 作者示範將一個已經內建有Swift runtime environment的Docker image減肥(從326MB縮到88MB), 然後將這個Docker image部署到EC2, 裡面有一個使用Swift寫的To-Do Web app做Demo
    今天又看到另一個Swift web framework, 叫 Zewo
    Zewo 附有自己的HTTP/HTTPS server, 比較特別的是Zewo提供Go-Style同步機制, 不用使用callback, Zewo強調每次release都會附Docker Image, 可部署到AWS, DigitalOcean
  • BTree這是一個Swift的Opensource, 它使用in-memory B-Tree(去複習一下資料結構), 去實作了Map List, 這個opensource特別在作者花了很大篇幅解釋為何要使用B-Tree, 並得到多少效能改善(如果您的工作是經常要做效能改善, 就可以參考一下他是如何佐證與改善), 不過受限到目前的Swift compiler, 這個opensource可能無法發揮它的效用, 即使會, 會讓你的code很難維護, 作者說未來的swift compiler應該會支援 . 但是這個opensource還是值得關注看到這段話就會知道Swift compiler目前的限制, 因為這個opensource是自己實作自己的型別. 裡面作者有解釋因為compiler的限制讓這個opensource受限了The Swift compiler team, true to their nature, have come up with a remarkably nice, pragmatic solution to this problem: a future compiler version will likely support a new attribute (@_specialize) that will allow library developers like myself to explicitly list a set of types for which their public generics would be specialized in the compiled package.

PHP

  • Xdebug 有在開發PHP的網友應該知道這個工具, 看了一下它的文件, 功能很強, 不僅可以坐遠端Debug, 支援許多IDE, 還可以找出PHP的效能瓶頸, unit test coverage …

Agile

  • Lean Software Development的7個原則與管理觀念 今天分享許多continuous Integration的資訊, 其實是與Lean Software development也有關係的, 細節可以在這篇文章看完你就會有感覺做CI背後的目的, 這篇裡面有講到–沒有所謂的SOP, 只有how to constantly improve the way to get work done. 今天大家應該都有看到一篇文章在社群間傳遞標題是-凡事皆靠萬年 SOP 不願意動腦想，難怪台灣傳統企業轉型總是加倍困難, 如果你仔細將這篇中的7個原則與管理觀念看一次, 覺得企業轉型似乎要學習一下敏捷與Lean的精神
  • 外包應該怎麼做? 從App估價的最佳實作省思 無論您是做產品, 接案, 文中提到的幾個階段都值得好好考量, 這篇文章來自歐洲一家專門在接App的公司分享出來的, 國外也有同樣的問題, 月亮沒有比較圓, 但是這家公司採用了敏捷開發的手法, 最後他們的生意反而變好了, 而且也獲得客戶的信任. 希望這篇文章可以改善一下國內接案削價競爭, 亂壓期限的風氣. 如果您覺得這篇文章講有道理, 幫我們分享出去吧!
  • Scrum與Agile敏捷開發書單與學習資源 昨天分享的那篇文章 “外包該如何做, 從app估價的最佳實作省思” 得到很多網友的認同, 但是認同無法產生作用, 這篇收集目前台灣有在推導Agile開發流程的公司, 如果要改變, 要先從思維去改變
  • Scrum with Trello 如果已經熟悉Scrum流程, 想要使用工具來配合, Trello是不錯的選擇, 這篇教你如何使用Trello搭配Scrum流程

Eclipse

Sketch

  • AnimateMate  如果有在用Sketch做前端設計, 利用這個免費的Sketch plugin就可以做出動畫效果

其它

  • gprof2dot 上週分享一個Visualize Java program execution with Flow, 可以把javat程式flow展開, 有網友來問是否支援其他程式設計語言? 今天看到這個工具, gprof2dot, 它主要是在將profilers的output畫成call tree, 主要是在找出程式的效能瓶頸, 裡面列了好幾個profiler工具, 只要你的程式可以透過這些profiler產出一個output, 再搭配gprof2dot就可以了, java, python都有支援
  • Bring questions. Build answers. 這是Google軟體工程師維護的網站, 主要在講一些Google產品開發背後的故事, 例如Gmail, Google documents, 語音辨識, 建構更快的Youtube , 有一些開發經驗介紹的很仔細, 在講他們開發gmail的前端經驗, 這個網站也是Google用來招募軟體工程師的網站.
  • 心得-Automattic攻略心得 看看國外的軟體公司是如何找人才的, 這位作者分享他的求職經驗, 整整大概花了快一年, 看了他的分享, 小編覺得求職者很有心, 更有耐心的是Automattic這家公司(wordpress.com就是他們維護的), 他們的coding test真的很符合實際狀況, 發一個題目讓你做, 兩週內完成, 這中間必須要commit code到他們的vcs, 還有讓面試者參與一個真的專案, 還是有付薪水 US25/1 hour, 他們很信任參加面試的員工不怕員工找槍手, 最後一關CEO面談了5個鐘頭
  • 慕課網 最近看到幾個對岸做的網路服務, 也許你會說他們在複製美國的一些新創團隊的服務, 但是不得不說他們複製的很成功 tongue 表情符號 , 例如這個線上學習平台, 再給幾個案例, http://blog.nienyiho.com/…/%E5%BE%9E%E4%BD%BF%E7%94%A8%E8%…/, 這篇文章講得幾個線上服務都是對岸做的, 進去一看, 功能似曾相似, 但是前端介面都有自己的風格, 如果你有發現還有不錯的, 歡迎在底下留言, 跟大家分享一下
  • LockHeedMartin 這家公司看起來像不像科幻電影裡面專門在研發超乎你想像的夢幻武器的公司, 仔細看一下他們涵蓋的領域好廣, 從材料科學, 決策分析系統, 機器人, 人工智慧, 他們還是一家做國防武器系統的公司

Soft & Share網站服務

原型互動設計工具開賣了, 可以參考Framer

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

Soft & Share在Facebook有經營兩個粉絲團, 歡迎來加入

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

 

 

1

Soft & Share 週報-5

以下是我們這週的分享, 祝大家週末愉快

Soft & Share團購電子書

  • Seven Mobile Apps In Seven Weeks 最近MicroSoft併購了Xamarin, 跨平台開發這個話題最近又熱了起來, 好奇的是會有開發者願意使用C#來做跨Mobile OS開發嗎?, 介紹一本書, 這本書介紹7種Mobile App開發框架(也包含Xamarin), 而且也是跨平台技術
  • Secure Your Node.js Web Application 推薦一本專門針對Node.js開發者所寫的網路安全書籍, 讓你用node.js開始建構程式時就將網路安全考慮進去
  • Designed for Use 2nd Edition 這是一本關於互動設計的書 – 例如在手機上的apps如何運作、在車用GPS導航如何輸入目的地等,越來越重要. 您需要以是否容易使用為基礎的設計程序, 來找出不良的軟體設計並加以修改.您將學習如何設計不只讓人們容易使用, 也讓人們喜愛的應用程式和網頁
  • Beyond Legacy Code 您的團隊在維護老舊的程式碼有遇到問題嗎? 對於以產品開發為主的團隊應該都會遇到這樣的問題, 一邊要維護舊的程式碼一邊還要擴展新功能, 這本書教你9個實踐教你延續軟體產品的生命與價值, 這本書在Amazon的評價是5顆星
  • Real-World Kanban 您的團隊正承受很大的工作壓力-事情先後不清, 哪些工作正在進行中也不是很確定, 管理沒有發揮作用? 如果您的團隊正面臨如上所述的情況, 本書的四個案例研究將引導您成功完成專案. 您將知道如何運用看板大幅地改進上市進度並建立跨行銷、 IT與營運的專注合作機制. 每個案例研究都以看板、示意圖、圖表的說明來幫助您了解幕後的運作.
  • The Nature of Software Development 先介紹一下這本書的作者 Ron Jeffries 是終極程式軟體開發論的創始者之一, 他是Extreme Programming Installed and Extreme Programming Adventures in C#的作者. 他也是敏捷宣言17個原始簽署者之一.看了書的介紹, 作者非常強調Value, 裡面有提到7個核心觀念
    1. 從開始到結束保持專注在價值
    2. 將產品看成許多小型可以運作的軟體組成
    3. 組織周遭即將完成的工作, 和該完成工作的人
    4. 以產品功能(features)做規劃
    5. 以產品功能(features)做建構
    6. 將產品功能切成更薄
    7. 每天的建構產出是有品質的

開發經驗分享

  • Why we moved to React Instacart是一家在做生鮮蔬果派送的公司, 他們分享了一篇為何使用React.js開發Web前端, 他們剛開始是使用Backbone, jQuery, Underscore and Haml等技術, 如果您現在也是在使用這些技術開發Web App, 看一下他們的技術移轉經驗
  • A Journey Through How Zapier Automates Billions of Workflow Automation Tasks 很不錯的一篇開發經驗分享文章, Zapier是一家專門在做不同雲端服務之間的自動化流程整合雲端服務, 這篇文章分享他們的團隊編制, 前端開發, 後端開發用了哪些工具與技術, 還有資料庫與他們的部屬平台, 如果你是做系統架構, 或是Devops, 這篇文章值得參考

Git & Version Control

  • Git Commands and Best Practices Cheat Sheet 習慣在console下git 指令, 裡面有一張高解析度的圖列出常用的git指令, 與狀態圖, 很方便, cheat sheet在字典翻成作弊用的小抄, 也許我們稱這張圖為git備忘圖會比較貼切, 這篇文章底下還有開發者說他要將這張圖片下載並設成桌面背景圖案-good idea!
  • VCS版本控制圖解指引 翻出了好幾年前翻譯的一篇文章並重新校稿一遍, 想起了Subversion, CVS, Visual Source Safe, 這些應該都變成古董了吧!, 現在主流是DVCS-Git, 所以小編還再校稿DVCS的圖解指引, 剛剛在校稿這份文件時裡面是引用SVN,雖然有點老舊, 但是這份指引可以讓有些不了解為何要使用版本控制的新手明瞭版本控制系統到底要解決什麼問題? 小編相信還是很多人排斥版本控制系統
  • DVCS分散式的版本控制圖解說明 幾年前翻譯的文章, 裡面那幾張圖對於剛接觸DVCS會很容易了解跟VCS的不同, 現在還有人在用VCS嗎? DVCS Git應該已經變成了顯學, 不過這份文件當年在翻譯的時候DVCS有兩大主流, 一個是Git, 一個是Mercurial,裡面的範例是用Mercurial, 以目前來看Git應該是大獲全勝
  • diff so fancy 如果您習慣在console mode下操作git diff , 試試安裝這個套件, 它的diff輸出會讓你舒服很多

Mobile Development

  • Swift for C# Developers 如果您本身已經有C#的基礎想要學Swift, 這篇文章可以參考看看, 從C#來看Swift這樣也會很快上手, 這篇是IBM出的, 小編上周有發一篇Blog IBM擁抱Swift https://goo.gl/2xW9lc , 裡面就大膽預測IBM未來應該也會推出Swift for Android的解決方案, 結果前天就在github看到swift opensource專案的pull request for android, 其實再想一想今天為何IBM會發這篇文章? 不就跟昨天的新聞MicroSoft併購Xamarin有關係, MicroSoft也是想吃企業end-to-end這塊市場, 行動端軟體兵家必爭之地就是iOS & Android了, IBM力拱Swift, 這兩家已經是呈現短兵相接的狀態,未來會是誰勝出呢?
  • MicroSoft scraps Android Windows 10 bridge, but say yes to Objective-C compilerMicroSoft原本有計劃讓Android跟iOS的開發者很容易將既有的source code porting到Windows 10 Mobile, 但是MicroSoft放棄了Android to Windows 10這個計畫, 但是繼續支援Objective-C(Why not Swift ??) 裡面有解釋這兩個專案的目標一樣可是在技術實作上不太一樣, Android是採用類似模擬器的技術, ObjectiveC比較像是轉譯器, 為何放棄Android? 裡面沒有講太多, 可能會踩到Oracle的Java專利吧!這篇也提到MicroSoft目前的策略不再將Android/iOS視為競爭對手, 這種感覺好像當年Steve Jobs回到Apple的策略一樣, 專心做自己, MicroSoft將Windows 10 Mobile定位在商務使用的Mobile OS.
  • Building Android Apps – 30 things that experience made me learn the hard way 開發Android App的35個建議, 雖然title寫30 things, 但是內文是列出了35點經驗分享, 例如建議用RxJava解決非同步的問題, 要盡量使用CI但是不要自己維護CI server(這點建議應該是針對獨立開發者), 這篇對於無論是新手或是已經有經驗的老手都是很不錯的經驗參考
  • Introduction to iOS Core Data with Swift-Udemy 免費的iOS線上教育訓練課程, Core Data是iOS官方內建資料庫引擎, 如果你的App有需要資料庫功能可以來看看Core Data的用法, 如果你的App要考慮跨平台, 也許你會考慮使用SQLite
  • Google Play開發者條款更新 您有認真將Google開發者必須尊守的條款看過一次嗎? 這次Google更新它的Android開發者條款頁面, 裡面提供更多的圖示與範例, 讓你很容易的瀏覽不要去踩到雷, 聽說被下架又要重新申請很麻煩的
  • Android 6 Tutorial  這本Android電子書到5/3前下載都是免費

UX

  • 用戶體驗設計的0到1,與1到1億 作者提到: 當產品可以免費地輕易取得，被替換的成本與代價之低，靠的就是用戶体驗與競爭者一較高下！最近在看KK的必然這本書, 裡面提到免費的商業模式裏要如何凸顯你的商業價值, 他講到8種模式Immediacy
    Personalization
    Interpretation
    Authenticity
    Accessibility
    Embodiment
    patronage
    Discoverability
    就是沒有提到使用者體驗這一塊, 今天看到這位作者的分享, 確實當市場充斥一堆免費商品時, 使用者體驗也是一個決勝點

Mobile Publish

  • AMP vs Responsive Web Design 這篇文章主要在解釋AMP與RWD的差異, 簡單的說AMP是Google主導的行動端網頁加速技術, 主要目的就是制定一個技術規格讓內容發表商去遵循, 如果網頁有支援AMP除了得到載入加快的好處, Google Search也有比較好的排名, 聽起來有一種被Google綁架的感覺, 如果你有寫blog而且是hosting在wordpress.com, wordpress.com就已經支援了AMP, 如果不是, 那網頁就要去修改成符合AMP的規範.小編上週就有寫一篇blog https://goo.gl/FI27gv , 裡面還有提到Facebook Instant Articles 也在幹同樣的事, 其實小編覺得Facebook的Instant Articles對內容出版商比較省事一些, 只要提供網站的RSS feed給Facebook, 剩下交給Facebook, 細節可以看小編的blog, 裡面有一些link可以參考

JavaScript

Java

  • Kotlin for Java Developers: 10 features you will Love About Kotlin Kotlin是由Jetbrains這家公司基於JVM所開發的一種程式設計語言, 而且支援Android App開發, 乍看之下有一種似曾相識的感覺, 這篇文中講的Kotlin特性有沒有很像swift?
  • 這個工具很神奇, 它可以視覺化你的java source code執行流程, 包含web應用程式, 裡面的影片也示範可以使用錄製模式來追蹤某段程式的執行流程, 這對於拿到source code後想要快速瞭解程式的架構很方便

 

Python

  • Table of Contents for Full Stack Python  免費的Python線上電子書, 涵蓋的主題很廣, 從Python程式開發語言, Web前端設計, 資料庫, Web開發框架, Deployment, Testing, 這本看完後Python功力大增

Unix

  • 雖然現在最熱門的作業系統是Linux( Android核心也是Linux), 但是現在許多作業系統的技術都是奠基於Unix, 想了解作業系統的發展歷史嗎? 這段影片收集了許多資料製作而成, 很用心的影片值得跟大家分享

工具

  • Awesome stars-Github Awesome系列好幫手 前一陣子在FB可能大家都有看到許多朋友在瘋傳Github Awesome系列(小編也是始作俑者之一),這個Awesome系列, 宛如opensource嚴選大全, 但是多到令人有點眼花撩亂, 來看看這個輔助工具, 讓你一眼望過去就知道哪些專案是Awesome系列中的熱門開放源碼專案
  • Google 開放了Cloud Vision API給所有開發者 在這篇文章中補上了一個使用Java呼叫Cloud Vision API的範例程式鏈結, 這個範例展示了Vision API辨識照片中有幾張人臉, 有一張圖很有趣包含了一隻猴子, Vision API沒有漏氣不會將猴子當作是人臉
  • Smartmockups- 這個雲端服務很方便, 可以省下你在做App各種情境下的顯示畫面

線上教育訓練

 

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

 

Soft & Share在Facebook有經營兩個粉絲團, 歡迎來加入

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

0

DVCS分散式的版本控制圖解說明

這篇DVCS(Distributed Version Control System)的文章, 深入淺出, 已徵得原文作者的同意, 在此將他的文章翻譯為中文.

distributed_logo

傳統的版本控制輔助檔案的備份,追蹤與同步. 分散式的版本控制讓變更的分享簡單容易. 如果你做的對, 你可以魚與熊掌兼得: 簡單的合併同時並可以集中版本發佈.

要分散式的嗎? 一般的版本控制到底發生什麼問題?

沒有問題 — 如果你想快速回憶的話請參考VCS版本控制視覺指引 . 當然, 有些人可能會嘲笑你還在用”古老”的系統. 但在我看來仍然是OK的: 對於任何專案來說有用版本控制系統總是正向的一步.

集中的版本控制系統在1970年代出現, 當初程式設計者有了精簡型終端機(thin clients)但同時也羨慕又大又貴又快速的”big iron” mainframes（誰能不被當時風行的大小通吃8bits到1 byte的機器吸引呢?)

集中管理是簡單的概念, 很自然是第一步想到的：讓每個人到同一個地方簽入簽出, 就像集中到某個圖書館的書本上註記一樣.

如此的做法對於備份,復原和同步行得通, 不過對變更的合併與分支卻不太行. 當專案成長時, 通常會想將功能切割, 獨立開發與測試, 再逐步將變更併入主開發線. 實際做時, 分支就很麻煩, 新的功能可能要做龐大的簽入, 如果中間有任何差錯, 變更變得很難管理也很難做問題排解. 當然, 集中控管的系統也總有”可能”做合併, 但並不容易: 你需要親自確實追蹤合併的動作與內容, 以避免同樣的變更被做兩次. 分散式的版本控制系統讓分支與合併無痛執行, 因為這是此類系統的長處. (譯註: SVN支援Merge Tracking後就可以避免同樣的變更會合併兩次以上的問題)

請看一些示意圖

別的教學多是嚴肅的命令列指令, 在此提供您視覺化的說明. 讓你回想一下運用典型集中控管的版本庫的狀況:

centralized_example

每個人與主開發線同步也將檔案簽入主開發線: Sue加入soup, Joe加入juice, Eve加入eggs. Sue的變更必須先簽入主開發線才會被其他人看到. 的確, 理論上, Sue可以另開一個新的分支讓其他人測試她的變更, 可是在一般的版本控制系統(VCS)如此做很麻煩.

分散式版本控制系統(DVCS)

依分散式模式, 每位開發者有他們自己的版本庫. Sue的變動存在她的工作電腦的版本庫,她可以決定是否要跟Joe或Eve分享:

distributed_example

不過是否有可能像群龍無首一樣? 不會的, 如果想要的話, 每個人可以將他的變動上傳(push)給同一個版本庫, 令人感到執疑地, 這不就跟上面講的集中式版本控制管理一樣. 這個版本庫(包含了Sue, Joe和Eve的變動.

我希望分散式版本控制DVC(distributed version control)可以有不同的名稱, 如 “獨立的(independent)”, “聯合的(federated)” 或 “點對點的(peer-to-peer)”. 此字 “分散”讓人聯想到分散式運算, 工作被分派給一群機器(如尋找外星智慧訊號的 SETI@home {可參考SETI@home台灣網站} 或做 蛋白質摺疊分析Protein folding).

而DVCS並不像Seti@home: 每一端(node)是各自獨立的且是否分享由各工作端自我決定(在Seti, 你必須回覆你的結果)

5分鐘說明主要觀念

此給你基本概念; 如果你有興趣, 可參考相關patch theory的說明書 .

核心概念

  • 集中式版本控制聚焦於同步,追溯(tracking), 和備份檔案.
  • 分散式版本控制聚焦於變動分享; 每一變更有其 全域唯一辨識碼(guid-global unique id)或unique id.
  • 記錄/下載以及採用一個變更被視為分別的步驟 (在集中式系統, 此三者同時發生).
  • 分散式系統沒有強制的架構. 你可以建立”中央管理”區或讓個人保持在自己的工作端運作.

新術語

  • 推(push): 將變更送給其他的版本庫 (也許需要權限)
  • 拉(pull): 從另一版本庫下載同步檔案變更

主要的優點

  • 每個人都有自己的沙盒(local sandbox). 你可以在自己的工作電腦上修改或回覆前版, 不需要大量的簽入. 你自己的工作記錄都累積存在自己的版本庫.
  • 可離線工作. 你只有當你想分享變更時才需要上線. 否則你可隨你高興一直在自己的工作電腦上獨立作業, 簽入或復原, 沒有所謂”伺服器”當掉或在飛機上無法上網的問題.(譯者註: 現在有些國際線的飛機上付費後可以上網)
  • 速度很快. 差異(diff), 提交源碼與變更回復都在本地端即可完成. 沒有因網路或伺服器不穩而必須要求使用一年前舊版本的問題. (譯者註: 作者應該是指伺服器OS版本與版本控制版本匹配的問題)
  • 可妥善做變動的處理. DVCS針對分享的變更做建置. 每個變更都有其獨一無二的辨識碼(GUID)以方便追蹤.
  • 分支與合併很容易. 因為每一開發人員”有自己的分支”, 每一分享的變動就像交換整合(reverse integration). 但獨一無二的辨識碼(GUID)讓自動合併變更與避免重複合併動作變的簡單容易.
  • 較少的管理. DVCS很容易部署; 不需要安裝“一直運作的”伺服器軟體. 此外, DVCS也不太需要你去”加”新的使用者; 你只是去選擇你想從那裡拉(pull)版本庫的URLs. 這樣可以避免大型專案中令人頭痛的政治性問題.

主要的缺點

  • 仍需要備份. 有個說法是你的“備份”就是其他人有你變更資料的終端機資訊. 我無法認同—如果這些其他人終端機資料並沒有採用你所有的變更呢? 或是當你變更的時候他們都不在線上? 用DVCS, 你仍希望可以有台機器讓你push所有的變更到他那裡保存“以防萬一”. (在Subversion, 你有一台隨時待命的機器做主要的資料貯存庫, 建議您在DVCS也做一樣的事).
  • 沒有所謂的“最近的版本”存在. 如果沒有集中地, 你無法馬上知道是否要到Sue, Joe或Eve那取得最近變更的版本(version). 再者, 一個中央集中的檔案庫才可幫助大家清處地知道最近的”穩定版本”為何.
  • 沒有真正的修訂版號碼(revision numbers). 每一版本庫有依變更做出的修訂版號碼. 和傳統的集中式版本庫不同的做法是人們依變更的修訂號碼做溝通: “請問你有變更號碼 fa33e7b? ” (這個變更號碼GUID 似乎長的不太好看). 還好, 你可以用有意義的名稱標示你發佈的版本.

Mercurial 快速上手(Quickstart)

Mercurial速度很快,是個簡易的DVCS. 暱稱是hg, 就像水銀(Mercury)元素一樣.
cd project
hg init                                (create repo here)
hg add list.txt                        (start tracking file)
hg commit -m "Added file"              (check file into local repo)
hg log                                 (see history; notice guid)

changeset:   0:55bbcb7a4c24
user:        Kalid@kazad-laptop
date:        Sun Oct 14 21:36:18 2007 -0400
summary:     Added file

[edit file]

hg revert list.txt (revert to previous version) hg tag v1.0 (tag this version)

[edit file]

hg update -C v1.0 (“update” to the older tagged version; -C forces overwrite of local copy)

2011-12-08_1513
一旦Mercurial已經初始化一個目錄, 看起來將如下:
distributed_repo_layout

你將有:

  • 一個工作拷貝(working copy). 你正在編輯的檔案群.
  • 一個版本庫. 一個目錄(Mercurial的.hg)包含所有的補釘(patches)以及可演譯資料(metadat:comments, guids, dates, etc.). 因為沒有集中的伺服器, 所以這些資料都放在你這裡.
在我們的分散式案例, Sue, Joe和Eve有他們各自的版本庫, 儲存他們不相干的修訂版歷史資料(revision histories).

 

理解更新(Updates)與合併(Merging)

在研究DVCS時有幾項讓我有些混淆. 第一, 有幾步將造成更新(updates)

  • 取得變更到版本庫：推(pushing) 或 拉(pulling)
  • 採用變更到檔案中：更新(update) 或 合併(merging)
  • 儲存新版：簽入/提交源碼(commit)

第二, 依據變更, 你可以更新或合併:

  • 當無模糊地帶時,更新(Updates)發生. 譬如, 我將變更拉(pull)到一直以來都是你在編輯的檔案. 因沒有重疊的變更,檔案將跳到最近的修訂版(revision).
  • 當我們的變更發生衝突時,就有必要合併(Merge). 如果我們兩個都去編輯檔案,最後會變成兩個”分支”, 類似平行宇宙(alternate universes-多種假設同時發展的各個故事)的樣子. 有個我修改的世界, 也有個你修改的世界. 在此例, 我們可能想要合併成一個單一的宇宙.
我仍在整理DVCS到底可多容易的產生分支與摺疊分支:
distributed_merge

在此案,因為 (+Soup) 和 (+Juice) 為同一個母項(parent-僅一個 “Milk”的列表)的變更, 有必要做合併(merge). 經過Joe合併檔案後, Sue可以做一般的 “pull和update” 即可獲得Joe已合併的結果. 她不需要親自做合併的動作. .

在Mercuril, 你可如下執行:

hg incoming ../another-dir  (see pending changes)
hg pull ../another-dir      (download changes)

hg update                   (actually apply changes...)
hg merge                    (... or merge if needed)

hg commit                   (check in merged file; unite branches)
2011-12-08_1529

是的, “pull-merge-commit” 周期蠻長的. 幸運地, Mercurial有整合多指令(commands)為單一的捷徑. 雖說看起來好像蠻複雜的, 但仍比在Subversion手動合併簡單多了.

大多數的合併是自動完成的. 當發生衝突時, 一般可以很快被解決. Mercurial持續追蹤每一變更的母/子關係(我們的合併列表有兩個母項), 與”最新版(heads)”或每一分支的最近變動. 在合併前我們有兩個heads;之後, 一個.

組織一分散式專案

此為一種組織方式:

distributed_push_pull

Sue, Joe和Eve將變更加入一共同的分支. 他們可以跟任一人交易補丁(patches)來做”兄弟建置(buddy builds)”：嘿 老兄, 請問要試試這些補丁嗎? 在推給實驗分支(experimental branch)前,我需要看看此是否可行.

然後, 經維護守門員在看過,將實驗分支的變更拉到穩定的分支(stable branch), 此有最近的版本. 分散式的版本控制系統(DCVS)幫助每一變更獨立進行, 但也提供集中系統所有的”單一來源(single source)”. 有多種開發的模式可用, 如”pull only”,此只有維護守門員決定是否要從別人拿取變更資料, Linux的開發採用此種,或”shared push”, 此和集中管理的系統作業模式很類似. DVCS讓您彈性選擇要採用哪種方法來維護您的專案.

練習和嚴厲批評以臻至善

我是DVCS新手,但很高興分享我目前已瞭解的. 我覺得SVN很好用, 但覺得去了解如何可以讓合併簡單容易也有趣. 我的建議是你可以從Subversion起步, 感受一下什麼是團隊協同作業,再實驗分散式的模式. 如果你適當的籌劃, DVCS可以達到集中控管系統的效果, 你也同時可享有簡易合併的好處.

線上資源

從Linus演說影片節錄:

  • “How many have done a branch and merged it? How many of you enjoyed it?”
  • “When you do a merge, you plan ahead for a week, then set aside a day to do it.”
  • “Some people have 5, 10, 15 branches”. One branch is experimental. One branch is maintenance, etc.
  • “CVS — you don’t commit. You make changes without committing. You never commit until it passes a giant test suite. People make 1-liner changes, knowing it can’t possibly break.”

所以呢…. 祝好運囉, 密切注意聖戰狀況…

Soft & Share在Facebook有經營兩個粉絲團, 歡迎來加入

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

2

Awesome stars-Github Awesome系列好幫手

在FB社團看到開發者Heng-Yi Wu寫了一個Chrome extension叫Awesome stars, 剛看到這名字馬上聯想到前一陣子在FB上大家在瘋傳的Github Awesome系列, 有Awesome PHP, Awesome Swift , Awesome Node.js , 這一系列利用Github整理出大家關注的熱門開發技術相關開源專案, 然後整理成一個個的主題專案, 有一個開發者更乾脆就建了一個專案叫Awesome , 將Github裡面的所有以Awesome系列為名的專案有系統地收集起來變成Awesome入口專案, 但是看到那麼多的Awesome開放原始碼專案, 要如何評估哪一個才是最熱門的或是被大多數開發者所肯定的專案? 雖然Github有評分機制並顯示星星的數量代表這個專案熱門與否, 但是每個專案必須點進去才看得到, 於是Awesome starts就派上用場了, 安裝了Awesome Stars後, 進入每個Awesome專案頁面, 就可以馬上知道每個專案的熱門程度, 真的還蠻好用的, 它顯示出來的結果如下圖所示, 是不是很方便呢?

awesomestars

安裝與設定

先到Chrome web store安裝Awesome stars

chrome-store-available

安裝後必須要設定Github的API access token才可以使用

sindresorhus_awesome-nodejs__A_curated_list_of_delightful_Node_js_packages_and_resources__和_編輯文章_‹_Soft___Share_—_WordPress_com

AWESOME_STARS

填寫這個token的用途說明, 例如Awesome Stars, 作者有交代不用選任何Scope, 因為這關係到你的github帳號安全問題

New_personal_access_token

按了Generate token, 會看到Github幫你產生token字串, 將這個字串copy到剛剛Awesome stars的設定畫面中的Access token欄位, 然後按Save就可以開始使用了

 

到Awesome, 選一個你感興趣的技術主題, 例如Awesome Node.js , 接著你應該會看到跟我一樣的畫面

nodeawesome

 

感想

現在的opensource真的是又多又豐富, 看到這麼多Awesome的開源專案一時真的不知道要看哪一個, 所以先從熱門的開源專案先看可以省下不少時間, 感謝Heng-Yi Wu幫我們開發一個這麼省時省力的工具, 而且Awesome stars也是開源專案, 如果大家覺得他做的很棒(應該也是Awesome等級的), 記得幫他的專案去按個星星

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

Soft & Share在Facebook有經營兩個粉絲團, 歡迎來加入

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

1

VCS版本控制圖解指引

以下為我們翻譯的”VCS(Version Control System)的圖解說明”所參考的說明版本控制文章, 這篇文章採用圖解說明,清楚且容易了解,徵得作者的同意,在此將他的文章翻譯為中文, 原文的網址為

http://betterexplained.com/articles/a-visual-guide-to-version-control/

version_control_intro_small

版本控制(又稱Revision Control或Source Control) 讓您隨時追蹤檔案的內容變動. 為什麼你要關心這檔事? 這樣當你搞砸時可以很簡單的回復前一工作版本.
你也許自己DIY了如下的版本控制系統, 卻沒發現這些命名看起來很怪異. 你有類似這樣的檔案嗎? (但願..你沒有完全和下面相同的…..)

  • KalidAzadResumeOct2006.doc
  • KalidAzadResumeMar2007.doc
  • instacalc-logo3.png
  • instacalc-logo4.png
  • logo-old.png

這就是為什麼我們存擋的時候後都會用“另存新檔”. 你想要舊的檔案不被新的檔案覆蓋掉. 這是常常發生的問題, 為了避免這種問題, 我們經常會這樣來解決:

  • 將舊檔做個獨立備份拷貝 例如:Document.old.txt.
  • 如果我們夠聰明, 我們加個版本號碼或日期: 例如:Document_V1.txt, DocumentMarch2007.txt
  • 我們甚至會用共享目錄, 這樣其他人可以不用e-mail傳檔即可看到或編輯檔案. 希望他們記得加版本編號到新檔案的檔案名稱中再存回去.

所以呢…為什麼我們需要版本控制系統 (VCS)?

運用分享的目錄並遵循共同的版本命名規則, 對於典型的專案或是一次性完成的論文還可以. 可是對於軟體開發的專案呢? 這是不可行的…
你可以想像在分享的檔案夾中的Windows source code像“Windows2007-Latest-UPDATED!!”給大家來編輯嗎? 那麼每位程式設計師只會在各自的子檔案夾工作? 行得通嗎?
因此大型的、同時多人參與編輯、快速變更的專案需要一個版本控制系統(Version Control System ), 換個專業說法就是 “檔案資料庫(file database)”, 來追蹤所有的變更以避免混亂.

一個好的版本控制系統(VCS)應該可以滿足以下的需求:

  • 備份與復原. 檔案在編輯時被儲存, 你可以恢復之前每段時間所編輯的版本. 如果你需要回溯到2007年2月23日編輯的檔案…沒問題.
  • 同步. 讓大家分享檔案且隨時可取得最新的版本.
  • 短期的版本回復. 隨意修改檔案或搞砸時? (你就是有可能如此, 不是嗎?). 就把所做的變更扔掉吧, 並回到版本庫(repository)中所知道的”好”版本.
  • 長期的版本回復. 有時我們真的搞得太糟了. 假設你是在一年前做了這個不良的修改,產生了bug. 這系統應能幫你跳到那個版本, 並了解當時做了什麼變動.
  • 追蹤變動. 當更新檔案時, 你可以留下為何變更的紀錄(此變更紀錄要存在版本控制系統,不是在檔案裡). 這樣可以容易的看出這個檔案隨著時間的演進與修改原因.
  • 追蹤負責人. 版本控制系統可以標出每個變更的人名,以示負責.
  • 沙盒(SandBoxing)-建立避免搞砸工作成果的工作區域. 在做大幅的變動嗎? 你可以暫時到獨立的區域做此變動、測試、解決問題, 然後才提交(check in)你的變更.
  • 分支與合併. 更大的沙盒(sandbox). 你可將你的程式碼拷貝一份分支(branch)到獨立的區域做修改, 並獨立追蹤在上面的變更. 過些時候, 再將你的工作成果合併到主要共同開發的區域.
分享的目錄雖然快又簡單, 但無法做到以上所說的這些功能.

學習相關用語

大多數的版本控制系統牽涉以下的觀念, 有可能用詞有點不同.

基本設定

  • 版本庫(Repository or repo): 儲存檔案的資料庫.
  • 伺服器: 版本庫所在的電腦.
  • 局端(Client): 與版本庫連線的電腦.
  • 工作組合或工作備份(Working Set/Working Copy): 你工作電腦上的檔案目錄-你工作編輯變更的地方.
  • 主開發線(Trunk/Main): 在版本庫裡存放程式碼的主要地方. 將程式碼想像為一個族譜(family tree)–”trunk”即為主線.

基本動作

  • 新增: 將一個檔案第一次放進版本庫, 也就是說開始用版本控制來追蹤此檔案
  • 修訂版本(Revision): 一個檔案位於哪個版本 (v1, v2, v3, etc.).
  • 版頭(Head): 存在版本庫的最新版本.
  • 簽出(Check out): 從版本庫下載一個檔案.
  • 簽入/提交(Check in): 如檔案內容變動時,將檔案上傳到版本庫. 此檔案將獲得新的版本號碼, 別人將可簽出(check out)最近的版本.
  • 簽入/提交說明: 說明做了什麼變更的簡短訊息.
  • 變更歷史紀錄: 從一個檔案成立起所經歷的所有變更列表.
  • 更新/同步: 將你工作電腦中的檔案與版本庫的最新變更做同步. 此可讓您擷取到所有最新的檔案.
  • 回復(Revert): 拋棄你工作電腦上的變更並叫出上次從版本庫簽出最新的檔案版本.

進階動作

  • 分支(Branch): 製作分開的檔案/檔案夾備份以便獨立運作(解bug, 測試等等). 分支可說是動詞(分支源始碼)也可說是名詞(在哪一個”分支”?).
  • 差異分析(Diff)/變更/差異部分(Delta): 找出兩的檔案的差異. 可幫忙看出版本間的變動內容.
  • 合併/補釘(Merge/Patch): 將一個檔案的變更合併到另一個檔案, 使其為最新內容. 譬如, 你可以合併一個分支到另一個分支或是主開發線做功能的整合. （在Microsoft, 此稱為 Reverse Integrate and Forward Integrate)
  • 衝突(Conflict): 當一個檔案的變更與其他變更發生衝突時, 兩者無法同時採用各自的變更.
  • 解決(Resolve): 解決變更的衝突問題並簽入(check in)正確版本
  • 上鎖(Locking): 取得此檔案的編輯控制權(Lock), 直到完成編輯後才釋放編輯控制權(Unlock), 其他人才可以編輯.  有的版本控制系統有這樣的功能以避免同一檔案中變更的衝突.
  • 強力解鎖(Breaking the lock): 強迫解鎖某一個檔案以便編輯. 這個功能也許在某人把哪個檔案鎖起來後度假去了(或當Halo 3遊戲發行那天”請病假”).
  • 簽出編輯: 簽出(Checking out)一檔案的“可編輯”版本. 有些版本控制系統原始設定簽出後即可開始編輯,有的需要下明確的指令才可開始編輯.
典型的劇情可發展如下:
Alice 新增一個檔案(list.txt)到版本庫. 她將此檔案簽出,做了些變動(把 “milk”放到列表中),然後將此簽入/提交, 同時寫簽入的說明 (”加入需要的項目.”). 隔天早上, Bob 更新 他電腦的工作備份, 看到最新list.txt的版本, 其中含有“milk”. 他可以瀏覽變更歷史紀錄或是做差異比對-看到Alice在前一天加了 “milk” .

 

視覺化案例

這裏從高階的觀念來解釋:大多數的教學指引都給你一堆文字指令. 讓我們以高階觀念來探討,不在指令語法上打轉( Subversion手冊 永遠都在那裡, 不用擔心). 有時去試探到底有什麼可能性總是不錯的.

簽入/提交(Checkins)

最簡單的情境是簽入一個檔案(list.txt)且花時間去修改它.

basic_checkin

每次我們簽入一個檔案的新版, 我們就會得到一個新修訂版(new revision-每個revision的內容含多個檔案at different version) (r1, r2, r3, etc.). 在Subversion你將會做:

svn add list.txt
(modify the file)
svn ci list.txt -m "Changed the list"

此 -m 旗標(flag) 使用來做此簽入的說明.

簽出與編輯

實作上, 你有可能不是一直簽入檔案. 你應該是簽出, 編輯再簽入. 這樣的周期看起來如下:

checkout_edit

如果你不喜歡你做的變更, 想重頭來的話, 你可以回復到前一版本再重新來過(或就此停止). 當簽出時, 原始設定讓你取得最近的修訂版本(revision). 如果你想要的話, 你可以指定所要的修訂版(revision). 在Subversion, 執行:

svn co list.txt (get latest version)
...edit file...
svn revert list.txt (throw away changes)

svn co -r2 list.txt (check out particular version)

差異(Diffs)

主開發線(trunk)有檔案變更的歷史紀錄. 差異是你編輯(editing)的變更內容 : 想像你可以 “分離” 他們然後將他們放入一個檔案:basic_diffs

例如, 從 r1 到 r2, 我們加入eggs (+Eggs). 想像分出紅標然後將其放入r1, 以變成r2.
又如要從 r2到 r3, 我們加入 Juice (+Juice). 由 r3 到 r4, 我們去掉 Juice 並加入 Soup (-Juice, +Soup).

大多數的版本控制系統 儲存差異(DIffs)而非 所有檔案的內容. 如此可以省磁碟空間: 4個版本並非指有 4個複製; 我們有1個複製和4個小小的差異. 很簡潔, 是吧?

在SVN, 我們如下做兩個修訂版(revisions)的差異:

svn diff -r3:4 list.txt

差異幫助我們看到變更內容(”你如何再次修正bug?”) 甚至用到一個branch和其他的比較.
加碼問題: r1 到 r4的差異(diff)是?

+Eggs
+Soup

請注意“Juice”甚至完全沒出現 — 若直接從 r1 跳到 r4 根部不需要此變更, 因為 Juice 被Soup蓋掉了.

分支(Branching)

分支讓我們拷貝程式碼到一個獨立的檔案夾隨意修改運用:

first_branch

譬如, 我們可以開一個分支來實驗新想法: 瘋狂的事情像加入Rice和 Eggo waffles. 要看你用的是什麼版本控制系統,有的系統在你開分支時會變動版本的號碼. 好了, 現在我們有一個分支, 我們可以變更我們的程式碼並實驗我們的怪怪想法. (“嗯..waffles? 我不知道老闆會怎麼想. 打賭用Rice應該安全才對) 由於我們是在分開的分支上工作, 我們可以獨立修改或測試, 看看這些修改會不會傷害其他的部份. 且在分支裡的修改都有版本控管的歷史紀錄.

在Subversion,你可以很簡單地將一個目錄做個copy另取名字, 就可以開一個branch了.

svn copy http://path/to/trunk http://path/to/branch

如此分支不是個太艱深的觀念: 假裝你已拷貝你的程式碼到另一個目錄. 你有可能已將學校的專案的程式碼做了分支, 確保你有一個安全的環境嘗試失敗版本以便如果搞砸了可以回復沒問題的版本.

合併(Merging)

分支聽起來很簡單,對吧? 不過, 不見得喔 — 解決如何將一個分支的變更合併到另一個可以說很傷腦筋.

讓我們假設要將 “Rice” 從我們實驗性的分支併入主開發線(mainline). 我們要如何做呢? 做 r6 和 r7的差異分析(diff)然後將差異併到主線?

錯錯錯. 我們只想取用在分支上做的變動. 意思是我們做 r5和r6的diff, 然後將diff送到主開發線 (main trunk):

merging

如果你做r6 和 r7的差異分析, 我們將漏掉 “Bread” (譯者註:因為r6和r7的diff將為-Bread, +Rice, 將這個diff加到r7, r8將少了Bread),而”Bread”應該在主開發線上. 這是精巧之處 — 想像從實驗性branch“分離”的變更(+Rice)並加進去主線. 主線上也許有別的變更, 如此做就沒問題了-我們只是插入Rice功能.

在Subversion, 合併和差異分析非常相近. 請在主線上, 執行以下指令 :

svn merge -r5:6 http://path/to/branch

此在實驗性的分支上所做的指令diffs r5-r6並將此diff加到目前所在. 不幸地, Subversion並沒有簡單的方法來追蹤已做過那些合併,如果你不小心, 有可能會重併同樣的變更. merge tracking為SVN改善計畫中的功能, 目前我們勸你做好變更記錄,提醒自己”r5-r6變動已合併到主開發線了”. (譯者註:SVN1.5後已經開始支援merge tracking功能）

衝突(Conflicts)

大部分的版本控制系統可以自動合併一個檔案不同地方的變更. 當有些變更顯然無法併入時衝突就出現了: Joe想要去掉eggs以cheese替代(-eggs, +cheese), 而Sue 想要以hot dog 替代eggs(-eggs, +hot dog).

vcs_conflict

此時競賽產生: 若 Joe 先簽入, 系統可自然接受此變更 (而後Sue就無法做她要的變更了).

當變更的地方相同且有像這樣的衝突時, 版本控制系統將可能呈報衝突訊息(conflict)而不讓你簽入— 此時如果你是Sue, 你可以決定是否要簽入一個解決(resolves)兩難的新版本. 處理方法可為:

  • 重新導入你的變更. 先同步到最近的版本(r4)然後再到此最新版做你要的變更: 到此已經有cheese的列表加入hot dog.
  • 以你的變更去覆蓋別人的變更. 將最新的版本(r4)簽出,將你的版本內容拷貝過去 , 再簽入. 結果, 這將把cheese換成hot dog.

雖然衝突不會常常發生, 但蠻惱人的. 通常我採用先同步到最近版本再將我的變更加進去.

標籤(Tagging)

誰曾想過版本控制系統竟然有Web 2.0的觀念? 很多系統讓你在任一想要的版本貼標籤tag(label)以方便參考. 如此你可以說參考”“Release 1.0″而不用指出在系統內特有的建置號碼(build number):

tagging

在Subversion, 標籤跟分支編輯方法類似,只要你想要做即可執行; 此功能存在乃為了清楚之後所有版本的發展, 所以你可以完全清楚看出在 version 1.0的發佈版本中內容為何. 且且就終止於此. 沒有別的地方可去了. (譯註: 也就是說標籤具有”凍結”的作用, 不會看到不相干的資訊)

(in trunk)
svn copy http://path/to/revision http://path/to/tag

實作的案例: 管理Windows開發程式

我們猜想Windows開發可運用其自己的分享檔案夾來管理它的開發程式, 不過事實並非如此. 那麼, 它是如何做的呢?

  • 有個主開發線, 此處存有穩定建置的Windows.
  • 每一個功能群組(網路, 使用者介面, 多媒體播放器, 等等.) 有他們自己的分支發展他們各自的功能. 相較於主開發線這些分支為正在開發中且較不穩定的發展內容.

你在新功能的分支開發,然後用“Reverse Integrate (RI)” 併回主線. 之後, 你 “Forward Integrate(FI)”且從主線拿到最近的變更併入你的分支:

windows

假設我們在 Media Player 10 和 IE 6. Media Player 團隊在他們的分支做了version 11. 當其完成並通過測試, 產生從10到11的patch, 此被主線採用 (就像 “Rice” 的例子, 不過複雜些 ). 此為reverse integration, 從branch到trunk. IE團隊也可同樣執行.

之後, Media Player 團隊可以取得其他團隊最近更新的程式碼, 如IE的. 如此, Media Player forward integrates 並從主線獲得最近的patches整合回他們的branch. 這有點像之前的例子去拉主線的”Bread”到實驗性的branch, 但, 也是比較複雜.

所以這就是所謂的RI(Reverse Integrate)和FI(Forward Integrate). 哼哼, 這樣的安排可以讓變更先在分支互相協調, 也同時讓新的程式碼不干擾主線的穩定度. 酷吧 ?

事實上, 可以有很多層次的分支和副分支, 配合品管度量來決定你何時要做RI. 不過要知道: 分支幫助您處理複雜度. 現在你知道一個大型的軟體專案基本上是如何組織了吧.

重點提示

我的目標是分享有關版本控管系統的高階想法. 以下為基礎要點: :

  • 使用版本控制. 認真告訴你,這是個好東西,就算你不是寫OS那麼大的東西. 就算單人用也值得.
  • 從小處著手(Take it slow). 我也是現在才開始為我的專案了解如何做分支和合併. 才開始要運用這樣的功能來管理. 如果你的專案還小, 分支和合併可能不是個問題. 維護大專案的人應該對分支和補丁的追蹤很有經驗了.
  • 保持學習. 可以參考很多指引: SVN, CVS, RCS, Git, Perforce 或更多你正在使用的系統資料. 重要的是把觀念搞清楚並意識到每個系統有它自己的行話和哲理. 也建議參考Eric Sink的 detailed version control guide.

以上是基礎資料 — 隨著時間我將分享我從做my projects學到的東西. 現在你已了解一般的版本控制系統(VCS),也可以看看 an illustrated guide to distributed version control （DVCS分散式版本控制系統圖解說明).

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

Soft & Share在Facebook有經營兩個粉絲團, 歡迎來加入

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

 

2

Soft & Share 週報-4

又是一週的結束, 這週過的充實嗎? 現在來回顧一下Soft & Share跟大家分享了哪些訊息

雲端服務

Continue reading “Soft & Share 週報-4” →

0

Swift 30天實作30個iOS範例

上週分享一篇學習Swift的100天, 才過一週就出現了Swift 30天實作30個iOS範例 -> https://github.com/allenwong/30DaysofSwift, 點進去看作者還將他30天的範例opensource, 觀摩他人的學習範例也是增進自己技術能力的方法, 這個分享跟學習Swift的100天比較不一樣的是作者沒有分享他的學習歷程, 學習Swift的100天的作者在進入iOS開發領域前工作是做網頁設計師, 所以他的分享等於鼓舞了非程式設計背景的設計師如何跨入iOS程式設計師的經驗分享, 小編建議如果您本身沒有程式設計經驗可以先看學習Swift的100天那位作者的學習經驗, 然後再來觀摩一下Swift30天的30個範例程式.

你可能會有興趣

  1. 完整的 iOS 10 開發者線上課程– 建立 21 個 App

  2. Swift 3 從入門到精通 中文課程
  3. iOS Apps with REST Apis 現在開發 iOS App 大概脫離不了與雲端服務做整合，這本書以實際的案例給你指引。

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

 

1

Soft & Share 週報-3

以下為這週2/13-2/19在FB軟體開發團隊工具心得分享粉絲團所分享的內容 , Soft & Share 這週開放刊登職缺與找工作服務, 歡迎大家來使用這個服務. 小編在努力分享時, 也在幫大家媒合優質的工作, 希望大家幫忙推薦一下這個服務給您認識的朋友 🙂

電子書/書籍介紹

BaaS

HTTP/2

  • Chrome Will Drop SPDY Support On May 15 從5月15後, Chrome不再支援SPDY HTTP/2要成為主流了, IT演進真快, 還沒搞清楚SPDY就要退場了 tongue 表情符號, 看起來影響比較大是Web server端要升級.
  • bagder/http2-explained 從5月15後, Chrome不再支援SPDY HTTP/2要成為主流了, 那HTTP/2有什麼特色呢? 這裡有詳細的文件解說, 裡面有被翻成許多國語言, 例如en英文zh簡中
  • Go 1.6把HTTP/2變成預設支援的功能 有使用 ‪#‎go‬ 程式開發雲端應用與注意HTTP/2發展可以注意一下這個新的release

演講

    • Bill Joy : What’s I’m worried about, what I’m excited about-BSD UNIX之父Bill Joy的演說, 這是一個自省的演說, 科技是帶來毀滅還是人類的幸褔? Bill Joy對於目前所謂的高科技有什麼憂慮?

趨勢

Python

雲端開發技術

  • 仙人掌世界:使用TOTP與Google Authenticator實作Two-Factor authentication 這篇文章有點舊, 不過現在這個技術確很實用而且不會退流行, 如果您用細心觀察, 近幾年的雲端服務開始流行起帳號雙重認證, 主要為了保護使用者的帳號安全不被盜用, 例如你用帳號密碼登入一個雲端服務後, 這個雲端服務如果有支援雙重認證, 它會要求你再輸入一個token, 目前小編看到這個token有兩種主流, 一個是用手機簡訊發出, 一個是由Google Authenticator這個App產生, 用意在確認這個登入動作確實是你本人, 這篇文章就是在教你如果你是在做雲端服務開發, 你要如何在伺服器端實現這個功能?
  • 使用Stacks/BuildWith來檢視雲端背後的技術與工具 之前有介紹過Stacks, 今天又發現另一個類似的服務叫BuildWith, BuildWith更可以將網站用了哪些javascript libraries列出來
  • 研發者的虛擬機寶典 這門課內容很棒啊!, 開發者在還沒開發程式前往往要先設開發環境, 如果軟體的版本變更了, 既有的軟體要重現當時的開發環境, 這堂課應該也幫得上忙, 還有做伺服器端的開發者也有類似問題, 小編跟這家公司沒有商業關係, 只是覺得這堂課對大家很有幫助, 所以推薦給大家, 這堂課線上課程是要付費的, 現在買有早鳥價
  • Diagnose problems in your production apps faster with Google Cloud Debugger Google針對它的Cloud platform推出Cloud Debugger, 這個Cloud Debugger目前支援 Java App engine, Python App engine, Go App engine, Node.js App engine , 這個工具可以安裝在 IntelliJ IDEA( Jetbrain 所開發的IDE, Android Studio就是基於IntelliJ IDEA所開發)

機械學習

UX

  • 歐付寶尋寶記-他們真的有設計UX嗎? 過年期間為了參加100萬元抽獎, 所以去下載了這個App , 用完了之後, 有了一個感想, 歐付寶設計這個活動是要取得更多的真的會將信用卡綁定的用戶還是要趕走更多的潛在用戶? ‪

JavaScript

Android開發經驗

影像演算法

程式設計語言

iOS

職場

  • 男性軟體工程師承認吧! 女生的程式碼設計功力比男生更好! 覺得這是個假議題, 女性在資訊行業的人數比例跟男性比例也要考慮進去才對, 還有在資訊業0與1是分明的, 如果女性在軟體專案可以產生優質的程式碼, 她的上司或是專案的leader應該很高興才對, 怎麼會有性別歧視問題?
  • 免費課程-如何學習困難科目的實用思維方法 會不會覺得總是趕不上資訊每隔幾年就會不斷地推陳出新, 在資訊業學習這件事是永不停止的, 如何讓我們更有效率的學習? 讓大腦更有創意, 無意中發現了這堂課, 可以找到你要的答案, 課程雖然是英文, 可是講師刻意講得很慢, 就是要你聽懂, 很棒的一堂課, 報名期限快到了.

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

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

0

由 WordPress.com 建置.

Up ↑