#尛外電 做迷因也能出頭天 企業開缺！重金禮聘迷因社群經理
----------------------------
Artist: 閒魚XianYu
----------------------------
國外一家專門獎掖人們投入開源軟體之開發的平台Gitcoin，先前在Cryptocurrency Jobs上發布了一則有趣的職缺。

Gitcoin公開表示要招聘「迷因藝術家／廢文專家暨社群經理」，酬勞為8萬美金（約新台幣222.5萬元）到12萬美金（約新台幣333.8萬元）不等。

Gitcoin平台是用來贊助一些程式開發或是區塊鏈技術的平台，隸屬於原始碼代管服務平台GitHub旗下。

除了贊助、融資與教學之外，Gitcoin也能用來進行貨幣空投活動，或以分發貨幣的方式讓用戶來替產品做宣傳。

註冊Gitcoin後，使用者可在上面發佈自己的開發進程，進而獲得其他人的資助（使用虛擬貨幣），當然也有人拿它來炒幣。

前來應徵Gitcoin迷因藝術家的人，除了需熟悉平台的運作模式，還要能管理旗下的多個社交平台帳號，依照不同需求發布相應的迷因時事梗，並開發一些可活絡社群的新點子。

雖然這聽起來跟小編的工作蠻像的，但差別在於迷因藝術家對程式編寫或區塊練的相關專業知識有更深入的了解，並能時刻掌握流行趨勢，搭配良好的管理手段，才能將333萬收入囊中。

如果大家對迷因藝術家這個職缺有興趣，請洽：founders@gitcoin.co

投遞時記得附上自己的推特或GitHub主頁連結，管理過Discord社群的相關經驗，以及你手頭上最優的迷因。

尛評：掌握迷因，掌握商機。
#加密貨幣加上迷因 #賺爛了賺爛了 #海編

--
Source: WORLD OF BUZZ, Cryptocurrency Jobs

➤ 我們的IG https://reurl.cc/A848rK
➤ 你知道尛？ https://reurl.cc/4mjkGD
➤ 我們的MeWe https://mewe.com/p/ani3small/
➤ 我們的YT https://www.youtube.com/c/Ani3small

#阿尼尛 #圖文 #迷因藝術家 #廢文專家 #gitcoin #github

📜 [專欄新文章] ZKP 與智能合約的開發入門

✍️ Johnson

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

這篇文章將以程式碼範例，說明 Zero Knowledge Proofs 與智能合約的結合，能夠為以太坊的生態系帶來什麼創新的應用。

本文為 Tornado Cash 研究系列的 Part 2，本系列以 tornado-core 為教材，學習開發 ZKP 的應用，另兩篇為：

Part 1：Merkle Tree in JavaScript

Part 3：Tornado Cash 實例解析

Special thanks to C.C. Liang for review and enlightenment.

近十年來最強大的密碼學科技可能就是零知識證明，或稱 zk-SNARKs (zero knowledge succinct arguments of knowledge)。

zk-SNARKs 可以將某個能得出特定結果 (output) 的計算過程 (computation)，產出一個證明，而儘管計算過程可能非常耗時，這個證明卻可以快速的被驗證。

此外，零知識證明的額外特色是：你可以在不告訴對方輸入值 (input) 的情況下，證明你確實經過了某個計算過程並得到了結果。

上述來自 Vitalik’s An approximate introduction to how zk-SNARKs are possible 文章的首段，該文說是給具有 “medium level” 數學程度的人解釋 zk-SNARKs 的運作原理。（可惜我還是看不懂 QQ）

本文則是從零知識證明 (ZKP) 應用開發的角度，結合電路 (circuit) 與智能合約的程式碼來說明 ZKP 可以為既有的以太坊智能合約帶來什麼創新的突破。

基本上可以謹記兩點 ZKP 帶來的效果：

1. 擴容：鏈下計算的功能。
2. 隱私：隱藏秘密的功能。

WithoutZK.sol

首先，讓我們先來看一段沒有任何 ZKP 的智能合約：

這份合約的主軸在 process()，我們向它輸入一個秘密值 secret，經過一段計算過程後會與 answer 比對，如果驗證成功就會改寫變數 greeting 為 “answer to the ultimate question of life, the universe, and everything”。

Computation

而計算過程是一個簡單的函式：f(x) = x**2 + 6。

我們可以輕易推出秘密就是 42。

這個計算過程有很多可能的輸入值 (input) 與輸出值 (output)：
f(2) = 10
f(3) = 15
f(4) = 22
…

但是能通過驗證的只有當輸出值和我們存放在合約的資料 answer 一樣時，才會驗證成功，並執行 process 的動作。

可以看到有一個 calculate 函式，說明這份合約在鏈上進行的計算，以及 process 需要輸入參數 _secret，而我們知道合約上所有交易都是公開的，所以這個 _secret 可以輕易在 etherscan 上被看到。

從這個簡單的合約中我們看到 ZKP 可以解決的兩個痛點：鏈下計算與隱藏秘密。

Circuits

接下來我們就改寫這份合約，加入 ZKP 的電路語言 circom，使用者就能用他的 secret 在鏈下進行計算後產生一個 proof，這 proof 就不會揭露有關 secret 的資訊，同時證明了當 secret 丟入 f(x) = x**2 + 6 的計算過程後會得出 1770 的結果 (output)，把這個 proof 丟入 process 的參數中，經過 Verifier 的驗證即可執行 process 的內容。

有關電路 circuits 的環境配置，可以參考 ZKP Hello World，這裡我們就先跳過去，直接來看 circom 的程式碼：

template Square() { signal input in; signal output out; out <== in * in;}template Add() { signal input in; signal output out; out <== in + 6;}template Calculator() { signal private input secret; signal output out; component square = Square(); component add = Add(); square.in <== secret; add.in <== square.out; out <== add.out;}component main = Calculator();

這段就是 f(x) = x**2 + 6 在 circom 上的寫法，可能需要時間去感受一下。

ZK.sol

circom 寫好後，可以產生一個 Verifier.sol 的合約，這個合約會有一個函式 verifyProof，於是我們把上方的合約改寫成使用 ZKP 的樣子：

我們可以發現 ZK 合約少了 calculate 函式，顯然 f(x) = x**2 + 6 已經被我們寫到電路上了。

snarkjs

產生證明的程式碼以 javascript 寫成如下：

let { proof, publicSignals } = await groth16.fullProve(input, wasmPath, zkeyPath);

於是提交 proof 給合約，完成驗證，達到所謂鏈下計算的功能。

最後讓我們完整看一段 javascript 的單元測試，使用 snarkjs 來產生證明，對合約的 process 進行測試：

對合約來說， secret = 42 是完全不知情的，因此隱藏了秘密。

publicSignals

之前不太清楚 publicSignals 的用意，因此在這裡特別說明一下。

基本上在產生證明的同時，也會隨帶產生這個 circom 所有的 public 值，也就是 publicSignals，如下：

let { proof, publicSignals } = await groth16.fullProve(input, wasmPath, zkeyPath);

在我們的例子中 publicSignals 只有一個，就是 1770。

而 verifyProof 要輸入的參數除了 proof 之外，也要填入 public 值，簡單來說會是：

const isValid = verifyProof(proof, publicSignals);

問題來了，我們在設計應用邏輯時，當使用者要提交參數進行驗證的時候，publicSignals 會是由「使用者」填入嗎？或者是說，儘管是使用者填入，那它需不需要先經過檢查，才可以填入 verifyProof？

關鍵在於我們的合約上存有一筆資料：answer = 1770

回頭看合約上的 process 在進行 verifyProof 之前，必須要檢查 isAnswer(publicSignals[0])：

想想要是沒有檢查 isAnswer，這份合約會發生什麼事情？

我們的應用邏輯就會變得毫無意義，因為少了要驗證的答案，就只是完成計算 f(42) = 1770，那麼不論是 f(1) = 7 或 f(2) = 10，使用者都可以自己產生證明與結果，自己把 proof 和 publicSignals 填入 verifyProof 的參數中，都會通過驗證。

至此可以看出，ZKP 只有把「計算過程」抽離到鏈下的電路，計算後的結果仍需要與鏈上既有的資料進行比對與確認後，才能算是有效的應用 ZKP。

應用邏輯的開發

本文主要談到的是 zk-SNARKs 上層應用邏輯的開發，關於 ZKP 的底層邏輯如上述使用的 groth16 或其他如 plonk 是本文打算忽略掉的部分。

從上述的例子可以看到，即使我們努力用 circom 實作藏住 secret，但由於計算過程太過簡單，只有 f(x) = x**2+6，輕易就能從 answer 反推出我們的 secret 是 42，因此在應用邏輯的開發上，也必須注意 circom 的設計可能出了問題，導致私密訊息容易外洩，那儘管使用再強的 ZKP 底層邏輯，在應用邏輯上有漏洞，也沒辦法達到隱藏秘密的效果。

此外，在看 circom 的程式碼時，可以關注最後一個 template 的 private 與 public 值分別是什麼。以本文的 Calculator 為例，private 值有 secret，public 值有 out。

另外補充：

如果有個 signal input 但它不是 private input，就會被歸類為 public。

一個 circuit 至少會有一個 public，因為計算過程一定會有一個結果。

最後，在開發的過程中我會用 javascript 先實作計算過程，也可以順便產出 input.json，然後再用 circom 語言把計算過程實現，產生 proof 和 public 後，再去對照所有 public 值和 private 值，確認是不是符合電路計算後所要的結果，也就是比較 javascript 算出來的和 circom 算出來的一不一樣，如果不一樣就能確定程式碼是有 bug 的。

參考範例：https://github.com/chnejohnson/circom-playground

總結

本文的程式碼展現 ZKP 可以做到鏈下計算與隱藏秘密的功能，在真實專案中，可想而知電路的計算過程不會這麼單純。

會出現在真實專案中的計算像是 hash function，複雜一點會加入 Merkle Tree，或是電子簽章 EdDSA，於是就能產生更完整的應用如 Layer 2 擴容方案之一的 ZK Rollup，或是做到匿名交易的 Tornado Cash。

本文原始碼：https://github.com/chnejohnson/mini-zkp

下篇文章就來分享 Tornado Cash 是如何利用 ZKP 達成匿名交易的！

參考資料

概念介紹

Cryptography Playground

zk-SNARKs-Explainer

神奇的零知識證明！既能保守秘密，又讓別人信你！

認識零知識證明 — COSCUP 2019 | Youtube

應用零知識證明 — COSCUP 2020 | Youtube

ZK Rollup

動手實做零知識 — circom — Kimi

ZK-Rollup 开发经验分享 Part I — Fluidex

ZkRollup Tutorial

ZK Rollup & Optimistic Rollup — Kimi Wu | Medium

Circom

circom/TUTORIAL.md at master · iden3/circom · GitHub

ZKP Hello World

其他

深入瞭解 zk-SNARKs

瞭解神秘的 ZK-STARKs

zk-SNARKs和zk-STARKs解釋 | Binance Academy

[ZKP 讀書會] MACI

Semaphore

Zero-knowledge Virtual Machines, the Polaris License, and Vendor Lock-in | by Koh Wei Jie

Introduction & Evolution of ZK Ecosystem — YouTube

The Limitations of Privacy — Barry Whitehat — YouTube

Introduction to Zero Knowledge Proofs — Elena Nadolinski

ZKP 與智能合約的開發入門 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] 來聊聊MEV之亂

✍️ Anton Cheng

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

MEVA vs Fair Ordering.

Credit: MP頭條

前言

最近這幾個月來，以太坊上面的MEV(Miner Extractable Value)的話題越來越紅，對於該如何解決這之中的不公平性，社群中展開了很大的爭論。由於最近剛好看到一篇很棒的Tweet統整了這半年來的一些好文章，就試這整理一下這幾篇的主要論點。（如果對MEV已經有基本概念的人，也可以直接follow這個thread就好xD）

— @benjaminsimon97

由於主要辯論的雙方剛好是目前做Optimistic Rollup最有名的兩大團隊：Optimism 和 Arbitrum，因此我們也可以透過這次辯論看出兩個團隊未來的開發走向。

前情提要: 什麼是MEV (Miner Extractable Value)

在Ethereum現有設計中，Miner有著選擇交易收入區塊(Tx Inclusion)，和決定交易先後順序(Tx Ordering)的權力。MEV指的就是礦工透過掌握這兩個權力所能提取的總價值。

雖然名詞定義上為礦工的可抽取價值，但是除了礦工之外，很多Front running 機器人在做的事情也是一樣的：透過觀察mempool裡面的交易，當發現front run機會的時候，透過付錢更高手續來讓自己的交易先被執行，這之中所抽取的價值，也是所謂的MEV，因此在後面會提到的很多文章中，大家直接用Front Run這個詞來代表了擷取MEV的行為。@danrobinson 在他經典的文章 Ethereum is a Dark Forest 中很好的闡述了如此的現況，也正式把這個問題帶進更多人的視野。

在那之後，一個名為FlashBots的組織現身，開始進行公開的MEV 相關研究與開發，旨在改善EVM帶來的負面影響，例如：front running 造成手續費提高、 MEV太高對以太坊安全性的影響。非常推薦大家Follow他們的進展。

接下來我們就來看看，一個重要的Proposal已經圍繞它而生的一些辯論。

MEVA (MEV Auction)

MEV Auction 是由 Karl Floersch 、Vitalik 、Philip Daian等人，於2020年一月共同提出的解決方法，字面上的翻譯就是透過一個拍賣(Auction)機制，讓MEV可以被更公平的分配。Karl 同時也是Optimism的CTO，也可能是因此設計出了這個能夠完美契合Layer2的架構。

更精準一點來說，這個拍賣要拍賣的是礦工的兩個權力中的「排序權」：它礦工未來只負責「選擇交易進入區塊」，而不再控制區塊內交易順序的排列，而把此權交給另外一個叫做Sequencer的角色來進行。至於Sequencer的選擇方式，就會是一個簡單的拍賣競標。在競標中獲勝的Sequencer將可以拿到未來一段時間的區塊排序權。至於整個協議競標中得來的錢，可以作為提供公共財的資金(fund public goods)。

為什麼說這個提案契合Layer2，是因為在L2原本的設計中，就是由一個Sequencer收取所有用戶的L2交易，在L2的鏈上執行，最後把執行結果以及所有交易資料Publish到L1上。換言之，這個排序者角色其實已經存在L2的架構中。若是L2層先實做看看這個拍賣機制，就可以在不改變以太核心協議的情況下，測試一下其可行性、參數等等。

對MEVA的質疑

在MEVA概念被提出之後，Ed Felton (Arbitrum 背後公司 Official Lab 的創辦人兼普林斯頓的教授)，對此提出了諸多的質疑。

1. 用戶最終體驗是否變差

Ed Felton最先寫了一篇名為「MEV auctions considered harmful」的文章，其中質疑了這個設計會讓使用者體驗更糟：這個Ordering權力的競標，無異於將「Front Running」這個行為專業化，因為理論上最會front run的人，將能夠一直出最高價得標。這在使得「Tx Ordering」這個權力中心化的同時，更變向鼓勵了大家開發厲害的front running程式，最終的受害者仍是的以太坊一般用戶，因為所有的MEV其實都是從用戶的身上抽出來的。

MEV auctions considered harmful

Vitalik 對Ed的看法提出了反駁：他認為「MEV來自用戶」這件事是一個已知且不可避免的事實，這個機制主要的重點，在於分離MEV的收入與礦工的收入，藉由把這個金流轉給Sequencer這個非礦工的角色，可以去除礦工中心化等危及Layer1 安全的疑慮。一個簡單的例子就是：若是有一個MEV很高的區塊（假設礦工可以透過re-ordering拿到100個ETH），那麼礦工就有動機在這個區塊高度進行fork（希望最終自己的挖到區塊被網路接受）。這個例子讓我們看到，考慮MEV會使得礦工的行為比起「單純領block reward」更難預測，這將危及到Layer1的安全。

Vitalik也表示，專業化帶來的「中心化tx ordering」並不見得是件壞事，儘管它對於使用者體驗是有害的，但無論如何MEV是有個上限的，Sequencer並沒有權力從使用者口袋偷錢，而且用戶可以在任何時候決定不使用這種比較容易被Front-run的合約。

2. 沒有MEV Auction的話，L1真的會變得更中心化嗎

Ed 接著寫了一篇名為「Front Running as a service」的文章，簡單回應了中心化tx ordering的問題，也挑戰了另一個MEV Auction的假設：「MEV將使得L1 Mining power趨於中心化」。

這個假設背後的理由很簡單，假如有一個礦池特別會front run，它將能夠獲得比其他礦池更高的收入，這會吸引所有礦工轉到這個礦池。

Ed 提出的反駁理論也十分有趣：假設現在有兩個礦工：A與B，其中兩者都有一定的算力，但A有較好的MEV程式，因此能夠透過排列交易獲得更高的收益。在任何時間點，只要B還存在，A礦工就有動機把這個MEV程式「賣給」B，因為本來B也有機會挖到一些區塊，在這些區塊中A的收益為0。若是能夠達成一個互惠的條件：B將使用A的程式多賺的收入分一部分給A，那麼這筆交易對於礦工A與B而言都是有益的，因此這筆交易必定會發生。

Front-Running as a Service

其衍伸意義為：身為MEV專家的礦工，其實有動機提供「Front Running as a service」，所以最終這個Service會自然被分離出來，並且形成一個自己的市場，本質上跟MEVA是類似的，並不會導致L1算力中心化。

3. MEV Auction是否真的能分離Tx Inclusion 與 Tx Ordering

Ed 還寫了另外一篇「MEVA(What is it good for?)」的文章，用經濟學解釋為什麼這個Auction最終會失效。

MEVA (What is it good for?)

簡而言之，不管我們如何想要分離這兩個權力，最厲害的front-runner若是能夠同時掌握Tx Inclusion的權力，它必定能夠提高自己的收入。這也表示，最厲害的Sequencer會想要自己成立一個礦池，因為當他同時掌握Tx Inclusion和Tx Ordering 兩個權力時，他能夠提供最高的報酬。因此一個理性的Sequencer會願意透過提高給礦工們更高的獎勵，來壟斷Tx Inclusion + Tx Ordering的權力（這是一個在現實商業世界中非常常見的壟斷策略）。這會使得最後這個模式會變得跟現在一模一樣：由單一角色決定Tx Inclusion和Tx Ordering的權力。

Fair Sequencing

不難看出，Ed所有的論點都圍繞一個重點：MEV Auction最終並沒有辦法解決任何問題，而且這個拍賣還會為社群帶來更多問題：例如一次拍賣24小時的交易排序權力，會讓這個權力過度中心化。

那麼Ed所在的Official Lab有提出什麼解法嗎？其實有：他們認為真正解決這個問題的方法並不是在鼓勵專業化Front Run並且拍賣這個權力，而是從根本上消除Front Run的機會，也就是說，應該要設計一個機制「避免」任何人任意排列交易順序。也就是所謂的Fair Sequencing問題。

在Arbitrum目前的計畫中，在未來他們會在Arbitrum Layer2中引入一個這樣的「公平排序」。實際的細節還沒有太明朗，他們計劃在幾個月內上線的第一個Rollup 版本也不會包含這些功能，所以其實他們的Mainnet Launch會類似Optimism，由單一Sequencer決定所有交易排序。但還是很期待他們未來能不能夠真的實作出更好的方法。

Chainlink Labs: Fair Sequencing Service

另一位Chainlink Labs 研究員(身兼康乃爾的教授) Ari Juels，也因為最近在CoinDesk發表了一篇類似的文章質疑MEVA，讓這個問題加溫不少。在這篇文章中，用了一個非常極端的譬喻：把Front Run這種惡意行為比喻為犯罪，若是一個城市充滿了罪犯，一個政府該做的事情並不是拍賣大家入室盜竊的權力、再將這些拍賣所得拿來回饋人民。反之，政府應該想辦法阻止犯罪。

這篇文章透過這樣的比喻，來表達對於MEVA機制的不認同，同時譴責Flashbots這類的社群專案是在系統化的傷害使用者，並指出「如何解決MEV應該成為以太社群的研究重點」。

Opinion: Miners, Front-Running-as-a-Service Is Theft - CoinDesk

文末的結論跟Ed Felton 相同，都是認為Fair Sequencing 才是此問題真正的解決之道。這其實是呼應自己Chainlink Labs幾個月前發佈的一個 Fair Sequencing Service。簡而言之，就是透過Chainlink 最擅長的預言機（Oracle network）來投票、避免讓一個中心化Sequencer角色單獨掌握這個權力。

其實這個Fair Sequencing 問題是一個非常大的研究領域、除了Chainlink labs提出的Oracle解決方法以外，還有許多包括ZKP的其他解決方法。我會盡量多Follow一些，以後有機會再來做更多介紹。

社群中其他的聲音

對於這個MEVA vs Fair Ordering的爭論，除了理論派以外，也有不少其他的聲音讓我們可以更全面地看看的整個局勢。其中一則Tweet表示：MEV Auction在實作上比Fair Ordering單純許多、也不需要牽扯一些複雜的密碼學：

— @tarunchitra

最後一定要提一下的是另一個以太坊大佬 Hudson 對於Ari這篇文章的回應。他認為MEV問題在短期內將會持續困擾使用者，Flashbots這種公開透明的開發流程能夠吸引更多社群關注，並且能夠讓MEV更公平的分配給更多角色、而非只是少部分的玩家。同時他也指出，以太坊核心開發者目前有更重要的2.0開發工作要做，面對這個議題，大家應該更踴躍參與以太坊公開的研究流程，而不是把所有的責任丟到所謂的「Core Devs」身上。

— @hudsonjameson

個人覺得Hudson這一段回應其實很值得大家更多思考，除了在學術上的辯論以外，真正實質上的社群參與也是很重要的。

小結

整個MEV議題到目前為止還是一個ongoing debate，在接下來幾天會不會愈演愈烈、會不會有人提出新的觀點，都是非常值得大家關注的問題。就像文章開頭低一篇Tweet所說的，這是非常高學術性良性辯論，我這裡只簡單的收錄了一部分，由於是順著Official Lab的脈絡撰寫、難免有些偏頗，希望大家可以到Flashbots的Github了解更多，會對於目前Optimism + Flashbot那一派目前所在做的事情有更多的了解。

如果還沒有follow Philip Daian這個人，非常建議大家Follow他。他除了是Flashbots目前最主要的推手之一，更有趣的是，他現在還在Cornell 念PHD，並且是Ari的學生。這場師生大戰讓整個辯論更加戲劇性，但卻不失其高質量的本質。對於接下來還會有什麼發展，讓我們一起期待吧。

— @phildaian

來聊聊MEV之亂 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

經常面試是學習及瞭解自己價值的捷徑，然而這些面試的所累積的經驗，直到我換了一個視角

成為了軟體工程師的面試官時，才發現面試大概十分鐘左右，基本上就會決定這個求職者有沒有下一步了

這支影片和你分享我成為面試官之後，一路找人的心得以及如何讓自己成為更好的面試官

因為每個人想法不同，每間公司的團隊文化和做法也不同，有些我在乎的點不一定是其他面試官也在乎的，但主要的關鍵核心不會偏離一個好的面試者應該如何表現

影片章節:
00:00 成為面試官後
01:23 什麼樣的求職者會被拒絕
02:01 履歷或對話沒有線頭
05:22 對徵才方的公司一無所知
06:45 只在乎自己能拿到什麼
07:21 總是沒有問題
11:08 成為好的面試官
12:31 先看履歷
13:00 先看專案
13:19 針對專案可以討論的點
13:29 設計面試題
13:49 討論人格特質
14:00 三明治鼓勵法
15:03 總結

影片中提到:
履歷撰寫文章: https://blog.niclin.tw/categories/%e5%b1%a5%e6%ad%b7%e6%92%b0%e5%af%ab/
從被問到問人，那些我常問的面試問題
https://blog.niclin.tw/2020/01/07/interview-tips/

喜歡影片的話！可以幫忙點個喜歡以及分享、訂閱唷！😘

━━━━━━━━━━━━━━━━
🎬 觀看我的生活廢片頻道: https://bit.ly/2Ldfp1B
⭐ instagram (生活日常): https://www.instagram.com/niclin_tw/
⭐ Facebook (資訊分享): https://www.facebook.com/niclin.dev
⭐ Blog (技術筆記): https://blog.niclin.tw
⭐ Linkedin (個人履歷): https://www.linkedin.com/in/nic-lin
⭐ 蝦皮賣場: https://shopee.tw/bboyceo
⭐ Github: https://github.com/niclin
⭐ Podcast: https://anchor.fm/niclin
━━━━━━━━━━━━━━━━
✉️ 合作邀約信箱: niclin0226@gmail.com

#面試 #工程師 #前端 #後端

2020 年回顧，雖然是個疫情擾亂的一年，但仔細回顧還是做了滿多事情的，第一次拍影片和大家分享，剛好那天有夠冷的，打噴嚏打了很久，看起來有點眼睛腫加疲倦，還請多包涵 XD

然後我會在這支影片下方的留言處蒐集 Q&A，如果你有任何問題想問，請依照影片最後的參加方式填寫，將會優先於下期影片做回覆啦

喜歡影片的話！可以幫忙點個喜歡以及分享、訂閱唷！😘

━━━━━━━━━━━━━━━━
🎬 觀看我的生活廢片頻道: https://bit.ly/2Ldfp1B
⭐ instagram (生活日常): https://www.instagram.com/niclin_tw/
⭐ Facebook (資訊分享): https://www.facebook.com/niclin.dev
⭐ Blog (技術筆記): https://blog.niclin.tw
⭐ Linkedin (個人履歷): https://www.linkedin.com/in/nic-lin
⭐ 蝦皮賣場: https://shopee.tw/bboyceo
⭐ Github: https://github.com/niclin
⭐ Podcast: https://anchor.fm/niclin
━━━━━━━━━━━━━━━━
✉️ 合作邀約信箱: niclin0226@gmail.com

#工程師 #前端 #後端 #成長