0%

錢不是萬能,但是沒錢卻是萬萬不能:沒錢時思考於如何運用現有的資源做出最有效益的事情而不是等待,有錢時則思考錢所做不到的事情,剩下來的就是用錢就可以處理的事情,所以說”錢能解決的事情是小事“這句話也不無道理,讓我們聚焦於錢所不能解決的大事,創造金錢無法取代的價值。

失敗為成功之母,說白話一點應該是指”失敗是邁向成功的過程“,既使計畫再周嚴縝密,在執行過程都無可避免發生問題,而失敗就是指這些意外的問題,當所有問題都被解決時那就是成功的時候,所以成功是指事情的結果,執行的終點。

“我沒有失敗過”這也意味著我沒有成功過”,害怕失敗就會原地踏步。

「失敗」比「成功」更具有啟發性。
Failures are infinitely more instructive than successes.
美國知名演員 - 喬治.克隆尼

我因為不斷的、不斷的、不斷的失敗,所以才有今天的成功。
I’ve failed over and over and over again in my life. And that is why I succeed.
美國籃球明星 - 麥可.喬丹

一個人從未犯錯,是因為他不曾試過新的事物。
Anyone who has never made a mistake has never tried anything new.
相對論之父 - 亞伯特.愛因斯坦

前言

上一篇 易學難精:Git 簡單的部分(一) 我們說明了 git 基本指令的運作原理,HEAD、commit、tree、blob 也會有如下的階層樹的關係:
img
下層的內容異動間接影響上層的雜湊值,這也是為什麼每次 Commit 都會產生新的 雜湊值(Commit Id) 的原因。
img

我們可以把 Repository 想像成一個圖書館,而 Commit 可以想像成書。
img
每一次 Commit 都會產生一本書,每一本書都會被賦予唯一的 ISBN(國際標準書號),也就是 Commit Id,Tree 就好像段落章節,Blob 則是章節的內容,HEAD (Branch) 則是書名。
img
所以 Commit 除了產生一本書之外,還會把目前的書名剪下來貼到新書封面上。
img
而 Commit 會紀錄由哪一本書(Commit)延續下來的,最後就像長篇小說一樣變成系列作品(Commit History),只是差別在於小說是不斷延伸新的內容,而 git 則是在同一個主題內不斷調整內容。
img

閱讀全文 »

img

前言

說到 git 就很容易聯想到 SVN(Subversion 簡稱),因為同樣都是在做版本控制,所以也常常被拿來比較,同時聯想到的就是錯綜複雜的時間線圖。
img
接著我們就像物流中心的調度員一樣開始監控每台配送車的”配送路線”,當然不令人意外的客戶需要的”貨品”常常有出入,買A貨給B貨、東西少了(功能)、東西多了(Bug),最重要的是哪個環節出錯不知道。
img
查詢維基百科就可以發現它把 git 定位在”軟體”,而把 SVN 定位在”系統”,所以 SVN 無庸置疑的應該比 git 強大很多,但是現今 git 似乎快成為版控的唯一代名詞了(問了周遭朋友幾乎都只想到 git)。
img
網路上其實已經有很多專業的教學文章,例如:官網文件30 天精通 Git 版本控管,所以我們不在此討論如何使用 git,而是研究一下 git 在做什麼?

閱讀全文 »

前言

上一篇 用 Docker 建立不同 Angular CLI 版本的開發環境 我們利用 Docker 將 Angular CLI 封裝在容器(Container)內,其實筆者一開始是想透過 Docker 來執行資料庫,因為我們可能因應客戶環境不同系統後端所對應的資料庫也不同,因此常常需要安裝不同類型的資料庫以便系統開發,不過如果本機端安裝多套資料庫除了增加 CPU 效能及記憶體的負擔外,相容性也是個問題,以往比較快速的做法就是安裝虛擬機(Virtual Machine),針對每個專案來建置對應的開發環境,不過,在測試過程在 Windows 環境遇到一些問題,所以就先擱置了。

閱讀全文 »

前言

因為 Docker 熱潮越來越紅,那種炒熱的氛圍感覺好像如果不會就跟不會寫程式一樣,所以就花幾天的時間玩了一下,雖然不盡理解但是大概也能略懂大家在講什麼,最重要的就是了解自己程式是否能在容器(Container) 內執行,在這邊就不班門弄斧說明 Docker 原理,而著重在實際建置。

閱讀全文 »

Markdown

用筆記也可以管理專案(一):PlantUML 中我們利用了 PlantUML 來協助產生 UML 模型,接著文字說明的部分則採用 Markdown 文件格式(.md 檔),讓我們可以在純文字的描述中,透過一些簡單的語法來協助我們排版,VS Code 內建也已經支援 Markdown,同時也提供預覽功能。
img

Markdown 其實是吸收了 HTML 的排版特性,它是利用一些較不影響既有內容可讀性的語法,將我們的純文字轉換成 HTML 並一它的語法結構添入適當的 HTML Tag 來讓版面美觀,上手難度並不高。相關語法可以查閱 Markdown 語法說明

閱讀全文 »

img

前言

對於資源充足的公司來說專案管理可以說是稀鬆平常的事,但是對於資源有限的公司來說比起它的效益來說所帶來的成本更是可怕,在有限的人力下,往往是邊跟客戶討論邊開發系統,而文件其實也常常在驗收後或請款前才由工程師自己”補上”,因為如果每次變更都要撰寫文件讓客戶確認後才做修改,那專案鐵定會延遲,更不用說這是”額外”的人力成本。

省略文件其實一種高風險的行為,尤其是需求變更卻沒有任何佐證資料時,當變更有效益時是皆大歡喜,但是當變更不但沒有效益反變成不可行的流程那就是一種災難,因為它會變成一個羅生門的需求,沒有人會承認這個需求是他提出的。

沒有文件是一種可怕的災難,但是多了文件又是一種資源的浪費,這是一種充滿矛盾的問題,因此
什麼是必要的文件?如何縮短文件撰寫時間? 便是我們的重點。

閱讀全文 »