跳到主要內容

發表文章

【程式設計基礎知識】宣告式 V.S 指令式

  圖片來源 相信身為軟體工程師的朋友們應該常常聽到宣告式及命令式兩種不同的名詞吧! 想當初剛入行的阿Han,對於這兩個名詞根本就是覺得文字天書,怎麼也看不懂,但在業界混了幾年之後終於有了一些領悟,也希望透過簡單說明的方式讓大家理解共同學習。 指令式程式設計(Imperative Programming) 圖片來源 這種方式是我們早期所使用的設計模式,先把需要的素材準備好,然後一步一腳印的打造出處理流程,最終產生成果的一種模式,這種模式很詳細沒錯,但是太多雜訊了,對於未來進入維護的新人來說會造成不易閱讀的門檻,以一個簡單的例子如下: --------------------------------------------------------------------------------- function imperative(elements: number[], threshold: number): number[] { // 準備素材 let results: number[] = []; // 一步一腳印的處理過程 for (let i = 0; i < elements.length; i++) { if (elements[i] >= threshold) { results.push(elements[i]); } } // 最終產生成果 return results; } --------------------------------------------------------------------------------- 宣告式程式設計(Declarative Programming) 圖片來源 這種方式屬於先設計在實作,以終為始,腦袋中先醞釀最終期望的成果,過程中逐步使用已封裝完成的功能,並告知每一個功能我所期望的結果,產生出最終結果,以一個簡單的例子說明如下: --------------------------------------------------------------------------------- function decla...

【資訊軟體知識】 Message Queue的傳輸協定 - AMQP

  對於軟體世界中Message Queue有興趣的朋友可以先閱讀這一篇「 【資訊軟體知識】井然有序的處理機制 - Message Queue 」建立基礎知識之後,再來看看這一篇會更容易進入情境唷! 上一篇我們有談論到Message Queue的架構之下,使用到通訊協定之一的「 【資訊軟體知識】 Message Queue的傳輸協定 - MQTT 」,主要追求速度,但另一個傳輸協定AMQP也就是今天的主題,著重於可靠性、豐富性,非常適合用於穩定的銀行體系。 AMQP協議 Advanced Message Queuing Portocol(高級訊息佇列協議) 圖片來源 ● Producer: 生產者, 負責生產訊息並送到交換機。 ● Broker: Message Queue的服務器(RabbitMQ...之類的產品) ● Exchange: 交換器, 它指定訊息按照什麼樣的規則送到哪個Queue。 ● Binding: 綁定規則, 後面會介紹幾種常用的MQ模式。 ● Queue: 消息隊列, 每條訊息都會被送到一個或多個Queue。 ● Consumer: 消費者, 負責接收與處理訊息。 特點 ● 金融業發展出來用於交易所訊息交換的協定。 ● 發布者、交換機、隊列、消費者都可以有多個。因為AMQP是一種網路協議, 所以過程中的發布者、消費者、代理都能分佈在不同的設備上。 ● 發布消息時可以帶上消息屬性(Message Meta), 有些屬性可以被消息代理(Brokers)使用, 有些則為不透明的, 只能被消費者使用。 ● 由於必須假設網路是不可靠的, 因此可能某個消費者處理訊息的過程中可能掛掉, 基於此原因AMQP協議就包含了消息確認(Message Acknowledgements)機制, 確保收到來自消費者的訊息後才將該筆訊息從Queue中刪除。 Exchange交換機 為什麼需要Exchange而不是直接將訊息發送到Queue呢? AMQP的核心思想就是讓生產者與消費者之間解耦, 因此生產者只需要一直生產消息並不需要知道這條消息會被送到哪個Queue, 而送到哪個Queue的工作就是交換機的事情了, 如此一來生產者與消費者的工作就更加單純。 以下是三種主要的交換機類型: 直連交換機(Direct Exchange) 圖片來源...

【Web微知識系列】如何維持溝通不斷訊? 關於HTTP Keep-Alive

  今天來聊聊我們常常使用的網頁,背後怎麼讓我們用的更順暢的一門傳輸方式,HTTP Keep-Alive,透過一點點的小改變,讓傳輸效率提升,減少非必要的浪費。 圖片來源 當我們溝通的過程中沒有KeepAlive的狀況下,會有多次往來的狀況,這樣對雙方來說開銷成本是非常大的,因此為了改善這個現象,加入了一個機制,就是當前期的握手協議建立之後,就可以不斷的發送請求跟回應,其實就跟通訊軟體一樣,當我們與對方建立關係之後,就能與對方不斷往來進行聊天,但是當今天我們帳號不斷的切換,那麼每次都要先打招呼,打完招呼之後等對方同意才有機會聊天。 與TCP的Keep Alive相同嗎? 一樣都是Keep Alive,看上去非常相似,但實際上是完全不同的兩個面向,由於HTTP是基於TCP之上的,因此對於TCP本身來說也應該要有Keep Alive的機制,不然的話就算我們的HTTP那一層做的在完美,TCP沒有長連接的機制也是枉然,而本篇不會提到TCP的Keep Alive的機制,目的僅在說明這樣的機制大概是什麼樣的概念,幫助建立比較基礎的知識。 HTTP Keep-Alive具備哪些優點? ● 減少用戶端與伺服端的負擔,不用頻繁請求,定期確保與對方沒有斷線即可。 ● 提升傳輸效率。 ● 確保與對方持續連線。 -------------------------------------------------------------------------------- 喜歡撰寫文章的你,不妨來了解一下: Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼要加入? 歡迎加入一起練習寫作,賺取知識,累積財富!

【Web微知識系列】關於網頁上的多工技術Web Workers

  越來越多的應用都在網頁上完成了,猶如過往的Excel、Word,現在都能直接用網頁來編輯使用,但我們想過嗎? 所有的運算,除了伺服器以外,網頁是不是也會有一些複雜的計算呢? 那對於這些複雜的計算,如果讓整個網頁卡住,勢必會影響到使用者的體驗,因此系統運算中的多工技術也被搬移到網頁端了,讓使用者一邊可以正常使用,背後將多餘的資源拿來進行較為複雜的計算。 但網頁端主要使用的語言是Javascript,原本的主要目的是簡單的互動,因此設計為單執行序,但隨著時代的演進,越來越多的功能都依賴這樣的程式進行運算,詳細我們將逐一說明。 為什麼javascript要設計為單執行緒? javascript主要功能是與user操作頁面互動及操作dom,試想若使用多執行緒的概念,那麼一個動作是新增至某個dom節點,另一個動作則是修改該dom節點,此時瀏覽器應該使用哪個動作為準? 所以為了避免複雜性才設計為單執行緒。 理解javascript非同步的概念 單執行緒就表示說所有任務都需要排隊處理,相對的效率較低落,IO或Network request通常需要等待較長的時間,如果前端頁面常常因為這些動作發生堵塞則user看到的畫面就是整個鎖死的,因此javascript使用了一些機制來避免這個問題,主要將任務分為兩種: ● 同步任務: 主執行緒上排隊執行的任務。 ● 異步任務: 不進入主執行緒,而是進入任務佇列等待執行。 上圖的執行機制 1. 主程序會先從stack中執行function 2. 執行過程中遇到setTimeout這類的非同步API呼叫,會透過事件委託的機制掛一個callback到setTimeout之類的Web API,執行完畢後會將該callback傳入上圖的callback queue等待。 3. 執行堆棧空閒時才從callback queue中取出任務執行。 4. 因此我們才會使用setTimeout的技巧讓一些需要長時間計算的任務排到任務佇列中等待,然而主執行緒就不會因為這個任務發生阻塞現象,可以先執行觸發loading動畫的事件後才處理這些耗時的任務,讓user感覺到畫面並非被鎖死。 上面的技巧雖然解決了畫面被鎖死的問題,但實際上執行的時間並沒有減少,因此發展出了Web Worker的機制,讓我們在web上也能有多執行緒的功能,最大化的利用系統資源,但是仍...

【資訊軟體知識】Proxy是什麼?關於代理/反向代理的大小事

  企業常常有代理人機制, 當我們有重要的事情需要請假時, 就會有代理人幫我們處理公司事務, 相當於「我們授權代理人處理什麼事情」,而這樣的代理機制在軟體世界也是常見的一種機制, 尤其是在分散式運算的架構下。 那代理能為我們帶來什麼好處呢? 又為什麼非用不可? 這也是我們今天著重探討的主題。 其實代理就是你跟我之間隔著一層, 彼此不知道對方, 只知道往哪邊遞送資料, 從而解決雙方的依賴, 尤其伺服器端如果是一群機器在服務, 撇開代理, 用戶端勢必得自己管控要送到哪一台機器去處理, 那刪減及增加機器時怎麼辦? 對於用戶端不就得常常停機,更新這些機器的位置, 這對於應用上來講就大打折扣了,因此有了代理之後,這樣的問題就迎刃而解了。 另外我們可能也聽過反向代理這個詞, 後面也會進行介紹,說明一下什麼是正向代理,什麼又是反向代理。 使用代理帶來哪些好處? 快取 由於Server與Client之間隔著一層Proxy Server,因此該台機器就可以加入緩存機制,當資料未發生變化時,每次Client的存取所看到的結果都會是一樣的,因此我們就可以將緩存的資料直接送往Client端,而不用往伺服器發送,減緩伺服器的壓力。 匿名性 透過Proxy的轉發,Client端並不知道真正處理請求的機器到底是哪一台,只知道要把這個請求送給Proxy請它代理處理。 流量控制 有了Proxy做為中間人,在這裡就能夠掌握流量,並且依序負荷程度進行適當的調配,避免阻塞。 稽核日誌 由於所有請求都會經過Proxy,因此在這裡非常容易掌控來源與目的,想當然也就更容易達到稽核的目的了。 先來搞懂正向代理與反向代理吧! 正向代理 其實正向代理就是以Client端為出發點,Proxy的角色就是中間人,中間人可以為Client進行服務,代為向伺服端發送對應的請求,那麼相對的以這個角度來說,應該站在Client的立場進行服務,包括匿名、翻牆…都是正向代理的服務範疇。 反向代理 而反向代理就不一樣囉,以服務端為出發點,替他們站在最前線,阻擋非必要的需求,就很像PM跟PG的角色,PM站在最前線釐清需求後,再往後派工。 反向代理能夠帶來什麼好處? 負載平衡: 由於運算量比較大的負擔會在伺服器端,因此在最前線的Proxy自然可以做到分散負擔的任務,才不至於太多的請求...

【資訊軟體知識】什麼是Business Analyst?BA在公司扮演什麼樣的角色呢?

  Business Analyst簡稱BA,即業務分析師,在軟體開發職位打滾了幾年也是最近才聽到這個名詞,好奇心所趨之下來了解BA到底是什麼? 主要的工作內容是什麼? 在公司裡又是扮演什麼樣的角色? 我們可能會想說BA不就只是每天與客戶溝通而已,寫寫使用者故事,主持主持會議,有時候又做為夾心餅,不斷的在客戶與開發團隊之間忙得不可開交,常常被挑戰不合理的需求怎麼開發,被質疑這種需求應該要能夠做到,為什麼不行,我想這對於外行來說常常看到的就是這樣的表面吧! 但其實BA並非我們想像的那麼簡單,最終目標就是「用對方聽得懂的話去告訴對方不懂的事」,因此邏輯能力與溝通能力非常重要,當我們越具備這種能力,所能發揮的影響力也越大,在公司的地位相對的也越高。 尤其是現在任何商機都是講求數據的時代,若身為一個商業分析師能夠掌握數據、分析數據,相信用數據說話能夠引領公司做好一個重大的決策。 扮演著什麼樣的角色? 如何計劃一個專案? 制定商業目標: 找出客戶的痛點,制定藥方研發計畫。 蒐集商業需求: 探訪客戶痛點的過程中想方設法蒐集更多需求,並思考如何將這些需求轉化為專案目標。 分配資源: 需要什麼樣的工程團隊? 工程、數據、…,需要什麼樣的內部資源?這些都是需要思考的範疇,並找出這些資源進行分配。 扮演利害關係人與工程團隊的橋樑。 蒐集客戶的反饋: 做為持續優化的養分。 建立報告: 透過專業技能將資料分析為有用的報表,並以報告方式呈現。 成果發表。 需要哪些專業技能? BA不只是簡單的溝通而已,更重要的是手上掌握了許多資料,如何使用專業技能將這些資料有效的分析,並提供給老闆、客戶、工程團隊進行有效溝通,減少隔閡,而不是單純著扮演著橋梁的角色,別人提供什麼輸入就原封不動的進行輸出,反而是要轉化、分析、以對方聽得懂的語言去進行溝通才能發揮最大的價值。 具有哪些責任? 解決企業內部遇到的挑戰。 分析數據,從資料中挖金,探嗅商業機會。 為客戶制定策略與解決方案。 做為公司各部門與客戶間重要的核心橋梁。 改善流程、策略制定。 結語 數位化的時代之下,軟體的需求也越發重要,複雜性也越來越高,我們常常發現需求與理解的過程會不斷的發生矛盾,而面對這樣的矛盾就需要有一個橋樑去化解,因此軟體開發不只是硬技能重要,軟技能也是不可或缺的能力之一,...

【Web微知識系列】HTTP的演進帶來了什麼改變? 未來的起手式HTTP/3的QUIC又是什麼?

  超文本傳輸協定(HyperText Transfer Protocol,縮寫: HTTP),主要做為數據通訊的基礎協定,舉凡我們上網的網頁、圖片…,都是由HTTP協定為基底標準,讓服務端與用戶端可以相互通訊,達到互動、傳遞資訊的作用,而從最初版的單向傳輸也隨著時代的演進,應用漸趨複雜的趨勢下慢慢優化到雙向互動,而大數據的時代下,龐大的數據量也凸顯了傳輸效率的問題,因而也對這部分進行改善,讓傳輸更加順暢,就讓我們一起來看看HTTP的演進史吧! HTTP 1.0的遠古時代 每一次都需要建立連線,並且只能有一次的請求。 HTTP 1.1 做了些改進 HTTP1.1版本之下,在一個請求中可以夾帶多個請求,並回傳,以此來減少多次連線的開銷,以此來改善HTTP1.0多次連線的問題。 到了HTTP/2的現代又有什麼大躍進? 在HTTP1的時代雖然做了很多連線上的改進,但是隨著用來越多應用都搬移到網路上,雙向溝通的需求也越趨明顯,而1.x版的架構下並沒有支援Server端主動通知Client端的機制,在HTTP 2也都加入了這些特性。 在傳輸上也將原本整包資料的傳送方式切碎成小包小包, 並給予每一包一個編號, 送到目的地之後再重組, 如此一來就可以傳送多批資料也不會有等待一批資料過於久的現象。 幾個優點如下: Header壓縮,減少傳輸成本。 支援Server Push,由伺服器推送資料到瀏覽器。 連線重複使用,減少開銷。 下一個未來發展的重點「HTTP/3」 我們在簡介說明的部分有稍微提到,未來隨著數據量以及更多的需求轉移到互聯網時,為了避免堵塞造成使用體驗不佳,因而在傳書上持續的演化,而HTTP/2之前仍然是追求可靠性傳輸的TCP協定,在HTTP/3大膽的引進了UDP不可靠傳輸的概念,但也並非完全不可靠,而是基於UDP做了一些改良,這個協定稱為QUIC: 由上圖,很明顯的看到我們原本三次的傳輸來確認雙方可以進行通訊的過程,改良到只要一次就完成,更何況TCP + TLS更多次確認的過程,這邊其實QUIC的過程已經包含TLS了,只是未將詳細過程羅列,有興趣者請參考Wiki。 但我們的心中一定充滿著幾個疑問: 為什麼QUIC能保證可靠性呢? ⇒ 因為加入了RAID5的演算機制,一次的傳送多個封包中,會加入一包檢驗的加總,並且...