2018-05-05

[分享] CODER、PROGRAMMER、DEVELOPER、ENGINNER這些名詞有什麼差異?

前言

常常有人說I'm coder、I'm programmer、I'm developer、I'm engineer,
但不確定這些名詞的差異,因此在Qoura搜尋一下發現也有類似的問題,參考連結整理如下:

Coder

純粹把程式寫出來可以正常運作,但程式碼也許不是這麼漂亮、或者可能有bug與效能不佳的問題。通常比較適用於程式初學者。 (不確定這邊是否有貶義)

Programmer

比Coder能夠熟悉某一種程式語言開發,並且有能力可以完成工作上交付的任務(Task), 但是需要有人去引導要用什麼樣的方式完成任務,若下次遇到同樣的問題之後便可以自己去解決。

Developer

可以寫出健全有彈性程式,同時能聯繫、解決客人對於產品特定的程式需求。

Enginner

通常是指可以用不同程式語言設計和建構出從無到有的程式產品,還可以針對現有的問題提出改善的方法,思考程式設計的觀點也比較全面。

總結

  • 這幾個腳色似乎有些部分是會重疊在一起的。
  • 團隊裡面會有人同時扮演多種腳色,或者與其他腳色互補。
  • 這邊自己想法是,可以透過產品的開發需求來定位自己的所扮演的腳色。例如今天我負責開發產品某一小部分的功能,並且只能用狹隘的觀點來看待此產品,那我的定位比較趨向Programmer;但我今天如果可以針對現有產品重要的功能可以設計出高彈性並且可重複利用的,定位就會比較趨向Developer。
GJ 2018/05/05 in Taipei

2018-05-01

[心得] 如何IT寫作? 讓自己的知識穩紮穩打

# 前言

---

可以讓自己的知識share出來提供給別人參考是一件不錯的事,因此我寫IT文章的習慣,會先想好以下三個要點:


  • 為什麼我要寫這篇文章
  • 這篇文章能解決什麼問題
  • 讀者可能有其他的疑問


## 為什麼我要寫這篇文章
通常我們對於自己腦袋中的知識深信不疑,很容易陷入一種迷思,覺得自己知識是完全正確但實際上是漏洞百出的,殊不知等到請你解說你的知識時,才發現描述的不夠實在、正確。舉例如下:

Q: 解釋 process 與 thread 的不同?
A: process所需要建立的資源成本較高,但是它對於資料獨立性保護較佳;而thread所需要的建立成本較低但是資料獨立性保護較差。

以上的舉例就很容易透露出我對process與thread差異根本不是很熟,因為我不能進一步描述這兩者間的差異性。假如今天面試官進一步詢問建立process與thread注意事項,我百分之百無法應對。

因此為自己撰寫一篇知識文章,既可以確保自己知識是有系統化的,也比較不怕被別人挑戰。而文章是自己寫的,就像老師自己編教材一樣,才能胸有成竹地去教學生。

~更重要的是方便日後查詢!~



## 這篇文章能解決什麼問題
既然花了時間寫文章,就要提出優點來,才能說服別人看到文章標題時,讓他產生一種想法: 這篇文章也許可以解決我目前的問題...

因此在撰寫文章前,要在文章開頭特別註明你的文章是解決什麼樣的問題? 例如我今天要寫一篇對於:process與thread差異

那我就會特別說,這篇文章可以提供process與thread差異之外,還可以:

  1. 在撰寫程式的時候可以考量到底是要用process還是thread
  2. 可以回答面試官的問題XD (通常面試官常問此類型問題)
  3. 可以了解process與thread創建過程
適時提出優點可增加閱讀文章的動力,畢竟要顯現優點才有被閱讀的價值。



## 讀者可能有其他的疑問
很多人在寫文章時,通常會犯了一個錯誤,例如今天撰寫一篇文章叫做:
How to create & use Dynamic Shared Objects
這邊就拿我最近的文章當例子How to create & use Dynamic Shared Objects

在某個小節,其中介紹編譯dynamic shared object 指令如下:

gcc -shared -o lib_addition.so lib_addition.c
在寫這個指令的時候,重點要告訴讀者這樣做就會產生lib_addition.so就可以了,

請不要一個個詳細解釋-shared 與 -o 還是其他指令的意義,因為我們今天文章的標題叫做:
How to create & use Dynamic Shared Objects
而不是
Explanation of gcc command parameters
因此我習慣把指令參數的意義放在Q&A就可以了,這樣才不會讓文章失焦。

---

# Conclusion
說到底我本來就不太相信大腦記憶,因此要有系統地去整理自己的知識,並寫出來公布在網路上,因為網友們也許會發現文章不足的地方而提供建議。另外也可以給自己一個壓力:
貼出來的東西是不能誤人子弟的
才能確保自己的知識是完整且無懈可擊。

GJ 2018/05/01 in Taipei


2018-03-10

[Tips] checking for C compiler default output file name fail

checking whether the C compiler works... no
configure: error: in `/home/gj/git/ambarella/apps/lighttpd/lighttpd-1.4.31':
configure: error: C compiler cannot create executables
See `config.log' for more details


you can refer config.log and find out that LDFLAGS may doesn't include necessary LIBRARY.

...libmcu.so: undefined reference to `
...libmcu.so: undefined reference to `



So, the configure message will said C compiler cannot create executables

2018-02-18

[TDD} TDD的好處

1. TDD不是銀彈,你交付的軟件依然會有缺陷,所以照樣需要許多其他的測試,
但是TDD會讓你發布的代碼包含非常少的缺陷

2. TDD易於理解。對於編寫不好的代碼,每個人都需要花費大量的時間去理解,
TDD可以讓你安全的重組組織代碼以提高可讀性。

3. TDD易於修改,通常容易修改的代碼意味著高質量設計。
TDD使你可以持續修改,以保持設計的高質量

2018-01-30

[觀念] 效能量測要注意三件事

簡單講
效能量測要注意三件事
1.  準確度。精確度(每一次測量數據各自都很相近)、真實度(每一次測量數據都很接近平均數據)
準確度(如果精準度與真實度都有達到條件)
2.  量測時間長短。都是在算週期性變化,主要被影響會有兩件事:
a). random    (射箭時候有風吹變化,不可控制的變因;老爺鐘擺在空氣中壓力與灰塵)
b). systematic (弓箭手姿勢,可控制的變因;時鐘所插的交流電: 50Hz or 60Hz)
3. 解析度。量測時間單位大小,就跟標靶第一圈與第二圈的相對距離意思一樣

2018-01-27

[書評] SCRUM:用一半的時間做兩倍的事

SCRUM:用一半的時間做兩倍的事

http://www.books.com.tw/products/0010673295

目前簡單寫下:

產品負責人:
-> 把客戶需求轉為生產清單,把生產結果轉為客戶價值。

Scrum大師: 
-> 安排Scrum流程,糾正Scrum錯誤,排除Scrum一切萬難。

書中有多個貼近生活的舉例,如果此書當作是一個非軟體相關工作者的Scrum入門磚,個人覺得非常適合,看完之後再進一步去看比較實務的Scrum之書籍。

2018-01-24

[筆記] Socket programing I/O Model 類比介紹

### Blocking I/O Model:

User application requests Kernel for UDP datagram by using recvfrom.

The UDP datagram to user application just has two status: ready or not ready.

PS. system call這邊是採用recvfrom



1. System call

小明(User application)拿著他的盤子(Uesr application buffer),

請求(system call) 煎檯的廚師(Kernel) 給他牛肉(datagram)。



2. Application is blocking

由於餐廳規定小明跟廚師要牛肉必須要在煎檯前面等不能走開 (the file descriptor is blocking),

因此小明(User application)只能等待廚師回應(return status),不能走開(blocking)



3. Wait for data

而廚師(Kernel)的煎檯(Kernel buffer)尚未放置牛肉(no datagram ready),

因此需要等待上游廠商牛肉送過來(wait for data)



4. Copy datagram

當上游廠商牛肉到達(data arrival)至廚師(Kernel)的煎檯(Kernel buffer),

因此煎檯(Kernel buffer)上的牛肉已經準備好了(datagram ready)



5. Copy data from kernel to user

過一會廚師(Kernel)再把牛肉(datagram)放置(copy datagram)給小明的盤子(Uesr application buffer)。



6. Copy complete

放置完成(copy complete)之後,廚師(Kernel)就會跟小明(User application)說OK (return status is OK)

,小明可以不用等了。



7. Process datagram

爾後小明就可以從煎檯離開,開始享用牛肉(Process datagram)





###  Non-Blocking  I/O Model

1. System call

小明(User application)拿著他的盤子(Uesr application buffer),

請求(system call) 煎檯的廚師(Kernel) 給他牛肉(datagram)。



2. Application is non-blocking

由於餐廳規定小明可以不用在煎台等(the file descriptor is non-blocking),

因此小明(User application) 可以先離開煎檯,隔一段時間再回來,可不斷詢問(polling)可以問廚師說牛排(datagram ready)好了沒?

這時候會有兩種case:

a. 廚師(Kernel)的煎檯(Kernel buffer)尚未放置牛肉(no datagram ready),
廚師回應(return status) 還沒,小明可以走開,晚點再詢問。

b. 廚師(Kernel)的煎檯(Kernel buffer)已放置牛肉(datagram ready),
廚師回應(return status) 好了,廚師(Kernel)再把牛肉(datagram)放置(copy datagram)給小明的盤子(Uesr application buffer),
小明可以走開。


## 同步跟非同步
這兩者差別不在於小明詢問廚師牛排好了沒,也就是不管前面是否會被阻塞(blocking)的動作。

而是以下這個動作:

廚師(Kernel)再把牛肉(datagram)放置(copy datagram)給小明的盤子(Uesr application buffer),

- 同步的話就是,廚師(Kernel)把小明(User application)叫住(blocking),還是要把牛肉(datagram)放置(copy datagram)給小明的盤子(Uesr application buffer),
小明才可以走開。

- 非同步,也就是異步,廚師可以偷偷在小明不知情的情況下把牛肉放置到小明的盤子上,然後才告訴小明說你的牛肉好了,
小明可以直接享用,在這過程中小明完全不會被廚師攔下來。

也就是說小明可能在拿著盤子在走路,廚師像忍者一樣,不急不徐地偷偷把肉放在小明盤子,放完之後跟小明講你牛肉好了。

# 結論
阻塞跟不阻塞,談的是user application 請求 kernel 的資料方式,要嘛問完就等著(blocking);要嘛問完就離開(non-blocking)。
同步跟非同步,談的是kernel 要用什麼方式把資料放在user application的盤子上。要嘛廚師把你抓住慢慢放完肉在你盤子上才讓你走(同步),要嘛在你邊走路情況下,直接把肉偷偷放在你盤子上(非同步)


2018-01-23

[分享] 下班自修比公司work重要


有帶電腦,不過我只有偶爾覺得重要時候才會碰公司的work,其他時候我就正常上班時候再弄,下班自修比公司work重要 


因為我自己印證,下班自修得到的知識,可以改善公司的work,因為公司不會教你新東西。


因此我就盡可能在非上班時間不要碰公司的work,除非剛好我在自修的內容與公司work重疊,互相驗證