如果你錯過了，Node 的建立者 Ryan Dahl 的新 Javascript 和 Typescript runtime[已發布](https://deno.land/)！它有一些非常酷的功能，可供公眾使用！讓我們來看看一些簡潔的功能，並開始建立一個簡單的 hello world！ ## 什麼是 Deno？ Deno 是 Typescript（和 Javascript）的新runtime，主要用 Rust 寫。它有一些[偉大的目標](https://deno.land/manual.html#goals)和一些非常有趣的“非目標”，例如不使用`npm`並且沒有package.json。 ## 安裝 安裝 deno 就像執行以下命令一樣簡單： `curl -fsSL https://deno.land/x/install/install.sh |噓` 然後複製“export”行並將其新增至“~/bashrc”或“~/bash_profile”中。 打開一個新終端並執行“deno”。您應該會收到“>”提示。輸入“exit”，讓我們深入研究一些功能！ ## Deno 中的酷功能 ### 預設打字稿 預設情況下，整合 Deno 來執行 Typescript 檔案。它基本上使 Javascript 中的類型成為一等公民。不再需要透過 Babel 編譯來在伺服器端 Javascript 中使用 Typescript。 ### 從 URL 導入 Deno 允許您從網頁匯入，就像在瀏覽器中一樣。只需在您通常命名模組的位置新增一個 URL： ``` import { bgBlue, red, bold } from "https://deno.land/std/colors/mod.ts"; ``` ### 標準庫 此外，Deno 有一個易於導入和使用的標準函式庫。有些模組可以執行多種不同的操作，例如 HTTP 處理、日期時間工作和檔案系統工作。您可以在[此處](https://github.com/denoland/deno_std)查看。 ### 使用 ES 模組 最後，Deno 僅支援 ES 模組語法，這表示不再需要 `require()` 語句，只需良好的 ole' `import x from "y"`。 ## 你好世界範例 讓我們快速看一下 Hello World，其中重點介紹了其中一些功能！ 將其複製到“hello-world.ts”檔案中。 ``` import { bgBlue, red, bold } from "https://deno.land/std/colors/mod.ts"; const sayHello = (name: string = "world") => { console.log(bgBlue(red(bold(`Hello ${name}!`)))); } sayHello(); sayHello("Conlin"); ``` 現在您可以使用“deno hello-world.ts”執行它，它應該會列印出一些內容。 將“sayHello”呼叫之一更改為“sayHello(15);”並重新執行它。您應該看到類型錯誤，因為 15 不是字串！太酷了！ 您還會注意到如何從 URL 導入 - 它從標準庫中獲取一些控制台顏色內容！ # 最後的想法 Deno 還沒有完全準備好用於生產 - 有幾個 [bug](https://deno.land/benchmarks.html#req-per-sec)，但開發正在快速推進！這絕對是一個很酷的新開源專案，值得關注！ --- 原文出處：https://dev.to/wuz/getting-started-with-deno-e1m
## 簡介 透過這份備忘清單深入了解 Python，其中包含任何 Pythonista 都需要了解的唯一函式庫。 從資料操作到機器學習和建立 Web 應用程式，這些程式庫在您的 Python 編碼之旅中至關重要。  --- ## 網路應用程式  ### 1. [太皮](https://github.com/Avaiga/taipy) Taipy 是這個街區的新來者。 它專為輕鬆開發前端 (GUI) 和 ML/資料管道而設計。 建立您夢想的應用程式得益於： - 完整的客製化和互動 - 多頁和多用戶應用程式 - 管道圖形編輯器 - 還有更多！ ---  您的支持意義重大🌱，並且在許多方面為我們帶來了很大的幫助，例如寫文章！ 🙏 --- ### 2. [Streamlit](https://github.com/streamlit/streamlit) Streamlit 是一個完善的函式庫，可用於為飛行員快速建立 Web 應用程式。非常容易使用！ --- ## 要點  ### 3. [熊貓](https://github.com/pandas-dev/pandas) 該庫帶來了兩個核心概念：資料幀和系列，使資料清理和準備成為一個輕鬆的過程。 ### 4. [Numpy](https://github.com/numpy/numpy) Pandas 有資料框，而 Numpy 有陣列。 它們以允許快速資料操作而聞名，使 Numpy 成為科學計算的重要工具。 ### 5. [請求](https://github.com/psf/requests) 該程式庫使處理 HTTPS 請求變得輕而易舉。 Requests 提供與 Web API 互動和管理 HTTP 回應的功能。 ### 6. [Scipy](https://github.com/scipy/scipy) Scipy 基於 Numpy，核心功能專注於數學計算，具有最佳化、訊號處理和插值等功能。 --- ## 約會時間  ### 7. [日期時間](https://docs.python.org/3/library/datetime.html) DateTime 是一個標準的 Python 函式庫，對於處理任何 DateTime 格式都是必不可少的。 ### 8. [擺](https://github.com/sdispater/pendulum) Pendulum 具有更高級的日期和時間處理所需的附加功能。 他們有更好的時區支援以及更好的格式選項。 --- ## 機器學習  ### 9. [Scikit-Learn](https://github.com/scikit-learn/scikit-learn) 這個庫不再需要介紹了，這是理所當然的。 Scikit Learn 是機器學習的參考，包含從聚類到分類的演算法。 它還包括從資料驗證到資料選擇的所有功能。 ### 10. [XGboost](https://github.com/dmlc/xgboost) 該庫以其回歸和分類演算法的高效結果而聞名。 ### 11. [Catboost](https://github.com/catboost/catboost) Catboost 是一個機器學習庫，專門設計用於處理主要顯示分類資料的資料集。 --- ## 深度學習  ### 12. [TensorFlow](https://github.com/tensorflow/tensorflow) TensorFlow 是一個成熟的深度學習庫，專門從事自然語言處理和影像分類。 ### 13. [PyTorch](https://github.com/pytorch/pytorch) Pytorch 還是 TensorFlow，這就是問題所在。 最終，您可以選擇自己的團隊，但 PyTorch 的與眾不同之處在於它更注重自然語言處理，並且更具 Python 風格，從而減少了眾所周知的 TensorFlow 陡峭的學習曲線。 ### 14. [Keras](https://github.com/keras-team/keras) Keras 是開始深度學習的好方法，因為它在 TensorFlow 之上執行，但實作過程得到簡化。 ### 15. [OpenCV](https://github.com/opencv/opencv) OpenCV 提供了各種圍繞即時電腦視覺的演算法。 您可以處理多種格式，包括物件、人類，甚至手寫體。 --- ## 自然語言處理  ### 16. [NLTK](https://github.com/nltk/nltk) NLTK 是自然語言處理的首選函式庫。 NLTK 的主要功能包括：處理和操作文本（標記化、詞幹提取等）以及使用 NLP 任務進行分類以進行情緒分析。 ### 17. [SpaCy](https://github.com/explosion/spaCy) 是這個領域的新人，專注於讓 NLP 更容易存取和用戶友好。 該圖書館優化了流程，以確保更高的速度和效率。 --- ## 測試  ### 18. [Pytest](https://github.com/pytest-dev/pytest) Pytest 是一個簡化測試編寫和執行的框架。它的語法簡潔，使用者友善。 ### 19. [Unitest](https://docs.python.org/3/library/unittest.html) Unistest 是 Python 內建的測試框架。 其主要功能是：測試發現、夾具支援、輕鬆組織和測試套件管理。 --- ## 聲音的  ### 20. [AudioFlux](https://github.com/libAudioFlux/audioFlux) Python 中用於音訊訊號處理的首選庫，但很簡單。 AudioFlux 具有大量功能，包括聲音分析，可用於深度學習訓練。 ### 21. [Librosa](https://github.com/librosa/librosa) 此 Python 程式庫允許從音訊來源中分析和提取特徵。 --- ## 程式碼分析  ### 22.[黑色](https://github.com/psf/black) 它是一個自動程式碼格式化程式。 它將自動格式化您的程式碼，以在整個專案中保持一致的風格。 ### 23. [Pylint](https://github.com/pylint-dev/pylint) 顧名思義，Pylint 是一個 linter。 它是一個靜態程式碼分析工具，用於檢查程式碼品質和錯誤。 ### 24. [Flake8](https://github.com/PyCQA/flake8) 這是另一個 linting 函式庫，可以根據 PEP8 編碼約定檢查您的程式碼。 ### 25. [Ruff](https://github.com/astral-sh/ruff) Ruff 是等效 linter 的最快選擇。 它提高了效率和速度，使流程加快了十倍。 --- ## 分散式計算  ### 26. [Dask](https://github.com/dask/dask) Dask 是一個流行的分散式運算 Python 包，因為它在處理大型資料集時特別有用。 Dask 整合了 Pandas、Numpy 和 Scikit-learn API，因此易於使用。 ### 27. [PySpark](https://github.com/apache/spark/tree/master) 顧名思義，PySpark 是 Apache Spark 的 Python API，讓我們可以直接在 Python 中利用 Spark 的功能。 ### 28. [極地](https://github.com/pola-rs/polars) Polars 是一個為處理大型資料集而建立的 DataFrame 函式庫。 它的靈感來自蟒蛇皇室 - 熊貓，但有一個（快速）扭曲，它的速度快了 10 到 100 倍。 --- ## 文件  ### 29. [Mkdocs](https://github.com/mkdocs/mkdocs) Mkdocs 是產生簡單文件的最易於存取的庫。 適合較小的專案，幾乎沒有學習曲線。 ### 30. [獅身人面像](https://github.com/sphinx-doc/sphinx) Sphinx 通常是大型專案的首選。 它包括對多種格式的支援並允許特定的自訂。 ### 31. [Pydoc](https://docs.python.org/3/library/pydoc.html) Pydoc 已整合到 Python 生態系統中。它直接從您的模組產生文件。 --- ## 地理資料  ### 32. [Geopy](https://github.com/geopy/geopy) Geopys 的主要功能是：距離計算、地理編碼和反向地理編碼。 ### 33. [表](https://github.com/python-visualization/sheet) 該庫允許您使用 Python 建立互動式地圖。改變遊戲規則的人。 ### 34. [Geopandas](https://github.com/geopandas/geopandas) 當您擁有地理空間資料時，您應該採取的方法。 如標題所述，Geopandas 是 Pandas，但用於地理空間資料。該庫具有輕鬆操作和分析地理資料的功能。 --- ## 遊戲  ### 35. [Pygame](https://github.com/pygame/pygame) Pygame 是首選、簡單的函式庫，可以輕鬆使用 Python 建立 2D 和互動式視訊遊戲。 ### 36. [街機](https://github.com/pythonarcade/arcade) 就像 PyGame 一樣，Arcade 使 Python 中建立影片遊戲成為一個有趣的過程。 它們對經典 Pygame 進行了更現代的改造，因此選擇實際上取決於個人喜好。 --- ## 網頁抓取  ### 37. [Scrapy](https://github.com/scrapy/scrapy) Scrapy 是一個成熟的函式庫，以網頁抓取而聞名。 一些關鍵功能包括：支援非同步/同步操作、HTTPS 請求處理等。 它具有廣泛的功能，這可能證明該庫具有陡峭的學習曲線。 ### 38. [美麗湯](https://www.crummy.com/software/BeautifulSoup/#Download) Beautiful Soup 是您處理從 XML 和 HTML 檔案中提取資料所需的一切。 由於其 Python 風格，它受到了開發人員的讚賞。 --- ## 視覺化  ### 39. [Matplotlib](https://github.com/matplotlib/matplotlib) Matplotlib 是 Python 中主要的元件庫，這是有充分理由的。 Matplotlib 允許使用多種圖表類型繪製 2D 圖形，並且還允許進行大量自訂。 元素的細粒度控制是該庫的真正優勢。 ### 40. [散景](https://github.com/bokeh/bokeh) 與 Matplotlib 相反，Bokeh 專注於互動式圖表。 ### 41. [Seaborn](https://github.com/mwaskom/seaborn) Seaborn 建構在 Matplotlib 之上。 雖然 Matplolib 強調精確性和簡單性，但 Seaborn 在建立複雜的統計視覺化的同時，其時尚的視覺效果具有真正的附加價值。 ### 42. [Vizzu](https://github.com/vizzuhq/vizzu-lib) Vizzu 在視覺化領域找到了自己的定位，並且做得非常好。 他們將講故事和圖表與高度動畫的視覺化融為一體，這是一種獲得更多動態圖表的好方法。 --- ## 結論 無論您是高級 Python 專家還是正在嘗試 Python，有了這份不可或缺的函式庫列表，您將能夠應對任何挑戰。祝你編碼愉快！ --- 我是一名新手作家，歡迎任何改進建議！  如果您有任何疑問，請隨時與我們聯繫。 --- 原文出處：https://dev.to/taipy/top-42-python-libraries-you-need-to-know-1omo
碰巧有些 Linux 終端機命令很難記住，將它們作為備忘單保存在電腦或紙上是一個很好的做法。此列表並不詳盡，但包含最常用的命令。請隨意在下面的評論中加入您最常用的命令並分享此列表✌️。 ## 用戶 - **Id** – 有關使用者的詳細資訊（uid、gid 和群組）。 - **last** – 列出有關最近登入的訊息，包括時間、使用者名稱、IP 位址和會話持續時間。 - **who** – 顯示授權使用者。 - **groupadd "testgroup"** – 建立一個名為「testgroup」的群組。 - **adduser NewUser** – 新增名為「NewUser」的使用者。 - **userdel NewUser** – 刪除名為「NewUser」的使用者。 - **usermod NewUser** – 修改使用者「NewUser」的資訊。 ## 目錄導航 - **cd /**- 導覽至根目錄。 - **cd** - 導航到主目錄（使用 $HOME 變數）。 - **cd /root** - 導覽至 /root 目錄。 - **cd ..** - 向上移動一級。 - **cd /root/.ssh** - 導航到隱藏資料夾 .ssh。 ## 使用文件 - **ls -al** – 顯示目前資料夾中的檔案和目錄。 - **pwd** – 顯示目前工作目錄。 - **mkdir NewFolder** – 建立一個名為「NewFolder」的新目錄。 - **rm NewFile** – 刪除名為「NewFile」的檔案。 - **rm -f NewFile** – 強制刪除名為「NewFile」的檔案。 - **rm -r NewFolder** – 遞歸刪除名為「NewFolder」的目錄。 - **rm -rf NewFolder** – 強制遞歸刪除名為「NewFolder」的目錄。 - **cp oldfile1 newfile2** – 將「oldfile1」的內容複製到「newfile2」。 - **cp -r olddir1 newdir2** – 遞歸地將目錄「olddir1」複製到「newdir2」。如果 Dir2 不存在，則會建立它。 - **mv oldfile1 newfile2** – 將「oldfile1」重新命名為「newfile2」。 - **ln -s /etc/log/file logfile** – 建立到檔案的符號連結。 - **touch newfile** – 建立一個名為「newfile」的空白檔案。 - **cat > newfile** – 取得 STDIN 並將其放入「newfile」中。 - **head newfile** – 輸出檔案「newfile」的前 10 行。 - **tail newfile** – 輸出「newfile」的最後 10 行。 - **gpg -c newfile** – 使用密碼以 gpg 格式加密「newfile」並將其儲存在同一目錄中。 - **gpg newfile.gpg** – 解密 gpg 檔案。 - **wc newfile** – 顯示新檔案中的位元組數、字數和行數。 ## 檔案/目錄權限 - **chmod 777 /root/ssh** – 為有權存取伺服器的每個人（擁有者、群組、其他人）設定讀取、寫入和執行權限。 - **chmod 755 /root/ssh** – 將擁有者的權限配置為 rwx，將群組和其他人的權限配置為 r_x。 - **chmod 766 /root/ssh** – 設定擁有者的 rwx 以及群組和其他人的 rw。 - **chown newuser newfile** – 將 newfile 的擁有者改為 newuser。 - **chown newuser:newgroup newfile** – 將 newfile 的擁有者和群組擁有者變更為 newuser 和 newgroup。 - **chown newuser:newgroup newfolder** – 將目錄 newfolder 的擁有者和群組擁有者變更為 newuser 和 newgroup。 - **stat -c “%U %G” newfile** – 顯示 newfile 的使用者和群組擁有者。 ## 搜尋 - **grep searchargument newfile** – 在 newfile 中搜尋 searchargument。 - **grep -r searchargument newfolder** – 遞歸搜尋 newfolder 中所有檔案中的 searchargument。 - **定位新檔案** – 顯示新檔案的所有位置。 - **find /etc/ -name "searchargument"** – 在 /etc 目錄中尋找名稱以 searchargument 開頭的檔案。 - **find /etc/ -size +50000k** – 在 /etc 目錄中尋找大小大於 50000k 的檔案。 ## 檔案 - **tar -cf archive.tar newfile** – 從檔案「newfile」建立檔案「archive.tar」。 - **tar -xf archive.tar** – 提取檔案「archive.tar」的內容。 - **tar -zcvf archive.tar.gz /var/log/** – 從 /var/log/ 目錄建立檔案並使用 gzip 對其進行壓縮。 - **gzip newfile** – 壓縮新檔案（副檔名為 .gz）。 ## 從套件中安裝程式 - **rpm -i pkg_program.rpm** – 在 CentOS、RHEL 等上安裝 RPM 軟體包。 - **rpm -e pkg_name** – 刪除 CentOS、RHEL 等上的 RPM 軟體包。 - **dnf install pkg_name** – 在 CentOS、RHEL 等上使用 DNF 從儲存庫安裝軟體包。以前使用 YUM，但最近已被 DNF 取代。 - **dpkg -i pkg_name** – 從 Debian、Ubuntu、Mint 等上的 DEB 軟體包安裝。 - **dpkg -r pkg_name** – 刪除 Debian、Ubuntu、Mint 等上的 DEB 軟體包。 - **apt install pkg_name** – 在 Debian、Ubuntu、Mint 等上從儲存庫安裝軟體套件。 - **apt remove pkg_name** – 移除 Debian、Ubuntu、Mint 等上的軟體套件。 - **apt update && apt update** – 更新系統中的軟體包（Debian、Ubuntu、Mint 等）並更新儲存庫。 ## 流程 - **ps** – 顯示目前正在執行的進程。 - **ps aux | grep 'bash'** – 尋找 'bash' 的程序 ID (PID)。 - **pmap -x 11** – 在進程記憶體中映射 PID 11 的進程。 - **top** – 顯示所有正在執行的進程。 - **kill pid** – 透過 PID 終止進程。 - **killall process** – 終止名為「process」的所有程序。 - **pkill process-name** – 按名稱向程序發送訊號。 - **bg** – 將掛起的程序傳送到背景。 - **fg** – 將正在執行的進程帶到前台。 - **fg process** – 將名為「process」的進程帶到前台。 - **lsof** – 列出進程開啟的檔案。 - **renice 19 PID** – 設定進程的最低優先權。 - **pgrep bash** – 尋找「bash」的進程 ID。 - **pstree** – 顯示進程的樹狀表示。 ## 系統 - **uname** – 顯示系統資訊。 - **uname -r** – 顯示有關 Linux 核心的資訊。 - **hostname** – 顯示主機名稱。 - **hostname -i** – 顯示主機的 IP 位址。 - **date** – 顯示日期和時間。 - **timedatectl** – 輸出和修改日期和時間設定。 - **cal** – 顯示日曆。 - **w** – 顯示目前登入的使用者。 - **whoami** – 顯示您的使用者名稱。 - **finger root** – 顯示有關 root 使用者（需要使用「apt-get install Finger」的資訊進行安裝）。 ## 硬體指令 - **dmesg** – 在啟動期間顯示系統訊息。 - **cat /proc/cpuinfo** – 顯示有關處理器的資訊。 - **cat /proc/meminfo** – 顯示有關記憶體的資訊。 - **lshw** – 顯示有關裝置的詳細資訊。 - **lsblk** – 顯示有關區塊裝置的資訊。 - **free -m** – 釋放記憶體：RAM 和交換（切換 -m 表示 MB）。 - **lspci -tv** – 在樹狀圖視圖中顯示 PCI 裝置資訊。 - **lsusb -tv** – 在樹狀圖視圖中顯示 USB 裝置。 - **dmidecode** – 顯示有關 BIOS 設備的資訊。 - **hdparm -i /dev/xda** – 顯示有關磁碟的資訊。 - **hdparm -tT /dev/xda** – 顯示 xda 的讀寫速度。 - **badblocks -s /dev/xda** – 執行壞扇區測試。 ## 光碟管理指令 - **df -h** – 顯示已安裝分割區上的可用空間（以位元組為單位）。 - **df -i** – 顯示檔案系統中的空閒 inode。 - **fdisk -l** – 提供有關磁碟、分割區和檔案系統的資訊。 - **du -sh** – 顯示已安裝分割區上的未分配空間（以 MB、GB、TB 為單位）。 - **findmnt** – 顯示所有安裝點。 - **mount /dev/sdb1 /mnt** – 將 sdb 磁碟的分割區 1 掛載到 /mnt 目錄。 ## 網絡 - **ip addr show** – 顯示所有可用網路介面的 IP 位址。 - **ip address add 192.168.0.1/24 dev eth0** – 將位址 192.168.0.1 指派給 eth0 介面。 - **ifconfig** – 顯示所有可用網路介面的 IP 位址。 - **ping 192.168.0.1** – 發送 ICMP 協定請求以連接到 192.168.0.1 處的節點。 - **whois 網域** – 顯示有關網域的資訊。 - **dig 網域 **– 檢索有關網域的 DNS 資訊。 - **dig -x 192.168.0.1 ** – 執行反向 DNS 解析。 - **host serverspace.us** – 解析主機位址。 - **hostname -I ** – 顯示本機位址。 - **wget file_name（連結到檔案）** – 下載檔案。 - **netstat -pnltu ** – 顯示主機上正在偵聽的所有連接埠（需要「apt-get install net-tools」）。 ## 遠端連線 - **ssh root@host** – 以 root 使用者身分透過 ssh 連線到遠端主機。 - **ssh -p port_number user@host** – 使用非預設 ssh 連接埠連接到遠端主機，指定使用者。 - **ssh host** – 使用目前使用者的預設連線。 - **telnet host** – 使用 telnet 連線（連接埠 23）。 --- 原文出處：https://dev.to/serverspace/linux-commands-cheat-sheet-aif
嘿嘿👋 在您作為開發人員的旅程中，賺錢的常見方法是**獲得全職工作**。 然而，您可能還沒有找到工作（_又名您仍在學習_），或者您已經開始工作，但您正在尋找賺取額外現金的方法。 現在，您可以嘗試透過多種方式賺取副收入。 “有些比其他更現實。” 在本文中，我們將了解您今天就可以開始的**_可實現的_副業收入工作**。 深吸一口氣，讓我們用這些新知識洗滌我們的靈魂。 🧎  **_免責聲明：_** 我沒有嘗試清單中的每個選項。如果您認為應該在清單中加入一些內容或您想分享個人經歷，請在下面發表評論（我很樂意聽取您的意見！）。 🙇♂️ --- ## ⚔️ 創作者任務 在 Quine，我們目前正在為開發人員提供一種將其技能貨幣化的方法。 _Creator Quests_ 是每兩週發生一次的開源挑戰。 **這就像一場 24/7 的黑客馬拉松，獎勵開發者建立酷炫的應用程式**以及使用未來的開發者工具。 🚀 社區透過對他們喜歡的專案給予榮譽來決定獲勝者。獲得最多榮譽的專案將獲得最多的收益。 🤑 **下一次挑戰將於 12 月 19 日星期二開始。** 要參加，請註冊 [Quine](https://quine.sh/?utm_source=devto&utm_campaign=monetising_dev_skills) 並前往 _Quests_。 PS：測試期間，100%有效參賽者均獲得獎勵💸 目前的獎金池為 1024 美元，隨著更多參與者的加入，獎金池將會增加！點擊下面的並試試看！ ⬇️ [](https://quine.sh/?utm_source=devto&utm_campaign=monetising_dev_skills --- # 💃 MaaS - 我即服務 **自由工作者很難開始。** 然而，每個人都可以**實現並獲得**。 我在資料分析方面有一些自由職業經驗。如果我必須重做一次，我會採取以下方法： **1️⃣ 選擇平台：** 了解[Fiverr](https://www. Fiverr.com/)、[Upwork](https://www.upwork.com/en-gb/nx/job)之間的區別-post/instant/welcome) 和 [自由工作者](https://www.freelancer.co.uk/)。選擇一個您喜歡的平台並專注於此。我發現 [Malt](https://www.malt.com/) 是一個有趣的平台，但如果你認為自己非常優秀，你可以隨時關注 [TopTal](https://www.toptal.com) / ）。 **2️⃣ 不要成為萬事通先生/女士：** 圍繞非常具體的服務建置配置文件，例如_我專門從事Python 抓取工具的編碼並使用MongoDB 建置資料庫，最終通過Plotly 顯示儀表板_（不完全是這樣）但你明白了🙃）。 **3️⃣ 為您的第一個客戶不收取任何費用：** 獲得您的第一個客戶非常困難，因此請聯繫招聘訊息並說明您很樂意**免費這樣做。** 如果他們對這份工作感到滿意，請詢問他們提供良好的評級。 **4️⃣ 獲得您的第一筆薪水：** 開始為您的工作收費 - 仍然以較低的費率 - 並建立您的聲譽。 **5️⃣ 提高定價：** 一旦您在平台上擁有更強大的地位，您就可以決定提高定價。 我的最後評論是，雖然我相信每個人都可以透過自由工作開始賺錢，但**我不認為每個人都應該這樣做。** 有很多缺點不符合你喜歡的工作方式（難纏的客戶、截止日期） 、平台依賴性等）。 **💁 特別提示：** 在倫敦，我發現了一個吸引一些客戶的小技巧。您可以聯繫一些相關的諮詢/招聘機構，他們可以幫助您找到客戶。如果您在起步時遇到困難，請考慮這樣的機構。 --- ## 🧪 測試一下。獲得報酬。 作為開發人員，您了解網頁或應用程式背後的技術細節。 這意味著您有能力執行出色的品質檢查。 根據您關注的平台，您可以花 10 到 60 分鐘以上嘗試應用程式或網站。 市面上有各種平台，但您可以查看的 3 個已知網站是： - [Trymata](https://trymata.com/) - [使用者測試](https://www.usertesting.com/) - [UserLytics](https://www.userlytics.com/user-experience-research/paid-ux-testing/) PS：還有一個完整的調查選項，在我看來，花費很少。如果您仍然好奇，可以查看[Wynter](https://wynter.com/participants/join)或[SwagBucks](https://www.swagbucks.com/g/paid-surveys)。 --- # 🐛 蟲子獵人 如果您對細節有敏銳的洞察力並且喜歡網路安全，那麼您可以透過這項技能獲利。 如果你有好奇心並且有良好的程式設計技能，你就可以在那裡賺錢。 🥂 一開始你可能會得到 20 美元的報酬，但獎勵可能會增加到天文數字，例如 10 萬英鎊以上。 我要強調的是，這不是你成為百萬富翁的方式。有一些不錯的競爭，你可能不會賺到很高的錢。 您仍然應該嘗試一下，看看它是否適合您。 最知名的平台是： - [HackerOne](https://www.hackerone.com/) - [BugCrowd](https://www.bugcrowd.com/) 如果你在這方面變得擅長，你可以考慮大公司，因為這往往是大公司的地方。 您可以從 [Microsoft](https://www.microsoft.com/en-us/msrc/bounty)、[Apple](https://security.apple.com/bounty/) 和 [Google](https: //bughunters.google.com/about/rules/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules)。 **最後提示：** 如果您發現自己喜歡使用的網站有漏洞，向他們索取賠償總沒有壞處。 🙃 --- ## 🧑🏫 你學到了什麼嗎？教它回來 輔導是我個人最喜歡的「副業」。 對於某些人來說，這可能看起來“乏味”，但它是非常可以實現的，並且它**增強您圍繞特定主題的知識，同時賺大錢**。 此外，您不一定需要成為專家。 這是正確的！ 只要您在特定領域更有知識，您就可以收取教授該知識的服務費用。 您可以透過 3 種方法來解決此問題： ### 📜 老學校方式 1️⃣ **確定合適的學校**：在學校/學院周圍張貼實體廣告，並附上您的課程和聯絡方式。 2️⃣ **辨識社群：** 尋找並參與相關的 Discord、Facebook 和 Linkedin 群組。以尊重的方式讓相關社區了解您的服務。 3️⃣ **不要太貪心：** 以較低的價格開始您的第一堂課，讓一切順利進行。經過一些經驗後，考慮提高價格。 ### 👶 新學校方式 查看以下平台： - [Codementor](https://www.codementor.io/freelance) - [Superprof](https://www.superprof.co.uk/lessons/computer-programming/united-kingdom/) - [導師](https://tutorhouse.co.uk/a/coding) 註冊成為導師並以低於市場價格的價格開始招募您的第一批學生。 ### 📦 數位內容 您可以考慮建立一些視訊課程。 我個人最喜歡的是一個名為 [Stan Store](https://www.stan.store/?ref=bap&utm_source=stan-store-link&utm_medium=redirect&utm_campaign=storefront) 的新工具。 這是數位創作者的全能工具包，不僅僅是建立影片內容。 > 我個人使用這個平台賺了幾百美元。 或者，您可以查看更傳統的平台，例如 [SkillShare](https://www.skillshare.com/en/search?query=Coding) 或 [Udemy](https://www.udemy.com/)。 --- ## 較不容易實現的路徑（但值得一提）👇 <br> <br> - **🚧 黑客馬拉松**：一些黑客馬拉松提供豐厚的現金獎勵。缺點是通常存在相當多的競爭。要尋找合適的黑客馬拉松，迄今為止最好的網站是 [DevPost](https://devpost.com/)。 <br> - **🏷️ 銷售鍋爐模板：** 您可以根據自己的知識建立鍋爐模板。在這種情況下，「稍微少一點」的是你能賺多少錢（至少在最初）。這是因為它需要大量的追隨者（或大量的行銷）。如果你想嘗試一下，可以看看 [Gum Road](https://gumroad.com/) 和 [AppSumo](https://appsumo.com/)。 --- 我希望您喜歡這篇文章，它可以幫助您了解如何利用您的開發技能來從事副業。 上述演出並不是試圖描繪出你將一夜致富的景象。然而，它們是副業，獲得報酬的機會很高。只要保持一定的一致性，隨著時間的推移，您可以期望獲得更多的收入。 🚀 這篇文章的靈感來自 @lissy93 寫的一篇很棒的文章。 如果您有興趣了解將您的開發技能貨幣化的其他方法（特別是如果您更有經驗），請查看他們的[文章](https://dev.to/lissy93/50-ways-to-bring -in- extra-cash-as-a-developer-19b6) 並給它一些愛。 下週見， 您的開發夥伴💚 巴普 --- 如果您想加入開源中自稱「最酷」的伺服器😝，您應該加入我們的[discord伺服器](https://discord.com/invite/ChAuP3SC5H/?utm_source=devto&utm_campaign=9_deep_learning)。我們隨時為您的開源之旅提供協助。 🫶 {% 嵌入 [https://dev.to/quine](https://dev.to/quine) %} --- 原文出處：https://dev.to/quine/5-achievable-side-hustles-for-developers-4bcg
 在過去的十年裡，我一直是一名全端開發人員，建置了像[gitup](https://gitup.dev/) 這樣的較小專案和像[crosspublic](https://github.com/github-20k/) 這樣的更大專案跨公共）。 多年來，我測試了不同的工具： 1. 提高工作效率 2. bug 更少 3. 少寫程式碼 我整理了一系列庫來幫助您開發我每天使用的優秀 NextJS 東西，並解釋了您可以用它們做什麼。 **讓我們深入了解一下。**  --- # 1. [Trigger.dev](https://github.com/triggerdotdev/trigger.dev) 使用 NextJS，我總是需要幫助來處理與後台作業相關的所有事情。 它可以是在背景執行的 cron 作業，用於傳送電子郵件或處理系統中的新使用者管道。 這導致我執行另一台伺服器來處理這些作業，無論是外部 EC2 伺服器還是帶有事件橋的無伺服器功能。 這會導致我支付額外的服務費用（管理更多服務）並自行管理水平擴展（在某些時候）。 [Trigger.dev](http://Trigger.dev) 改變了這一點，在 NextJS（以及許多其他）之上提供後台作業。 他們也知道如何解決 NextJS 無伺服器逾時限制來處理長時間執行的作業。  --- ## 2. [Prisma](https://www.prisma.io) Prisma 不是 NextJS 特有的。它是一個與資料庫一起使用的 ORM。 ORM 是資料庫查詢的統一包裝器。 它保持良好的結構，並允許您在不同的資料庫提供者之間快速更改。 雖然您可以使用很多 ORM，但 Prisma 的獨特之處在於為您的查詢提供 Typescript 支持，使一切速度提高 100 倍。 NextJS 在預設配置中使用了 typescript，使其成為完美的匹配。  --- ## 3. [NextAuth.js](https://next-auth.js.org) 假設您要實現任何服務提供者身份驗證，例如 Facebook / Google / GitHub (oAuth)。 在這種情況下，您必須為每個提供者建立實作或使用外部服務，例如 [Auth0](https://auth0.com/) 或 [Clerk](https://clerk.com/)。 如果您打算自行執行此操作，NextAuth 提供了豐富的實現，以便您只需提供正確的金鑰即可輕鬆新增它們。 一旦您登錄，他們也會處理授權。 *Next.JS auth 可以與 Prisma 開箱即用。*  --- ## 4. [下一個網站地圖](https://github.com/iamvishnusankar/next-sitemap) 在伺服器上部署 NextJS 後，您需要協助 google 索引所有頁面。 如果您可以告訴 Google 您網站上的所有頁面，那就更好了。 為此，您可以建立一個列出所有頁面的 sitemap.xml 檔案。 您可以輕鬆地使用 Next-Sitemap 來實現這一點。  --- ## 5. [下一步 SEO](https://github.com/garmeeh/next-seo) SEO 是透過向您的網站預覽提供關鍵字、描述和圖像，使您的網站出現在 Google Feed 上以進行不同查詢的過程。 如果您使用新的 NextJS 應用程式路由器，則可能不需要使用它。 您可以使用他們的“導出元資料”方法或“生成元資料”， 但如果您使用舊的應用程式路由器，這是為您的網站加入 SEO 的最佳方式。  --- ## 6. [Zod](https://github.com/colinhacks/zod) Zod 是一個物件驗證器（伺服器和客戶端）。 您可以在物件上放置不同的規則並稍後對其進行驗證，例如使用者名稱和密碼，或更複雜的內容（例如陣列長度或其他鍵上的條件）。 *Zod 不是 NextJS 特定的。* 多年來，我看過很多物件驗證器，例如 [Yup](https://github.com/jquense/yup) 和 [class-validator](https://github.com/typestack/class-validator)。 是的，它看起來不像 Zod 那樣維護，並且在使用 NestJS 之類的東西時，類驗證器非常強大 - 所以你最好使用 Zod。  --- ## 7. [React-hook-form](https://github.com/react-hook-form/react-hook-form) 雖然 Zod 可以驗證物件，但如果沒有自訂邏輯，它不會影響您的用戶端和後端。 React-hook-form 是優秀的用戶端驗證專案（顯示輸入錯誤、管理輸入狀態和提交）。 當然，您可以使用 Zod 作為 React-hook-form 的驗證器。  --- ## 8. [tRPC](https://github.com/trpc/trpc) 我承認我以前從未使用過 tRPC，但今天它似乎吸引了許多人的目光。 它與 Prisma 有類似的概念；它們為您的請求和回應產生一個接口，因此當您使用前端呼叫時，您會獲得自動完成功能。 這很好，因為它減少了錯誤的機會 - 假設您修改了後端路由，您將無法編譯專案 - 客戶端將返回不存在的參數或回應鍵的錯誤。  --- ## 9. [SWR](https://swr.vercel.app) 和 [React-Query](https://github.com/TanStack/query) 多年來我一直使用 Axios 和 fetch 作為發送請求的基礎庫。 SWR 和 React-Query 增強了這些函式庫並提供鉤子、快取、轉換等。 強烈推薦用於每個專案。請注意，這些庫適用於客戶端元件（“使用客戶端”），而不是伺服器元件。  --- ## 10. [lodash](https://lodash.com) 這不是 NextJS 特定的函式庫。 它是一個用於改變資料的函式庫，雖然這些年來 JavaScript 憑藉像 flatMap 這樣優秀的原生函數取得了很大的進步，但仍然缺少一些東西，例如按鍵或分塊和陣列的唯一陣列。 我發現自己幾乎在所有專案中都使用 lodash。  --- ## 11. [dayjs](https://day.js.org/) day.js 是一個包含與日期、格式、時區等相關的所有內容的函式庫。 我可能會因為那件事而被烤。我多年來一直在使用“moment.js”。 現在它不再維護了，dayjs 是一個不錯的選擇。 有些人喜歡新的 JS 函數來處理日期，但我仍然覺得 dayjs 選項和原生 JS 日期函數之間存在很大的差距。  --- ## 12. [jsdom](https://github.com/jsdom/jsdom) 這不是必須的，但我最近在許多專案中都使用它作為 [cheerio](https://github.com/cheeriojs/cheerio) 的替代品。 您可以取得整個頁面內容(`<html><body>....</html>)` 並將其轉換為稍後可以使用「本機」javascript dom 函數`querySelector`、`innerHTML` 等來操作的物件… 非常適合需要一些刮擦的專案。  --- 我們在 X 上連接嗎？ :) [我在這裡](https://twitter.com/nevodavid) 您是否為 NextJS 使用其他一些很酷的程式庫？ 請在評論中讓我了解它們:) --- 原文出處：https://dev.to/nevodavid/top-12-libraries-for-your-nextjs-project-1oob
想像一下，您的任務是在您正在開發的產品中實現一項重要的新功能。這就是您一直在等待的機會 - 每個人都會看到您是多麼出色的 10 倍開發人員！你打開一個你想要嘗試的最酷的新庫和設計模式的列表，然後直接進入它，完整的“地下室”模式。一週後，你勝利地出現並提出了你完美的拉取請求！ **但是，團隊中的高級開發人員立即拒絕了** - ***「太複雜了，你應該簡單地使用庫 X 並重用 Y。」***。什麼！？顯然，他們不明白你的解決方案有多天才，很快，你就會看到關於你的 PR 的 100 條評論以及接下來幾天的重構。 如果有一種方法可以在實施一切之前了解 X 和 Y 就好了。是的，它就是 RFC！  我們將透過[關於在 Wasp 中實現身份驗證的 RFC](https://www.notion.so/RFC-Auth-without-user-define-entities-6d2925439627456ab01b74ff4b4cd087?pvs=21) 的範例來了解它。 **[Wasp](https://kdta.io/github-wasp-lang-wasp_4) 是一個建置在 React、Node.js 和 Prisma 之上的全棧框架，提供了大量開箱即用的功能這是建置和部署應用程式的最快方法**。它還附帶一個免費的 GPT 支援的程式碼庫產生器 [MAGE](https://usemage.ai/)，已用於建立超過 30,000 個應用程式。 讓我們深入了解一下！ ## 支持我們！ 🙏⭐️  如果您覺得這篇文章有幫助，請[考慮在 Github 上給我們一顆星](https://github.com/wasp-lang/wasp)！我們在 Wasp 所做的一切都是開源的，您的支援幫助我們使 Web 開發變得更容易，並激勵我們撰寫更多這樣的文章。  ## 那麼，什麼是 RFC？  RFC 代表 *Request For Comments*，簡單地表示 **「**提議更改程式碼庫以解決特定問題的文件。」。 **其主要目的是在實施開始之前找到解決問題的最佳方法。** RFC 最初由開源社群採用，但如今，它們幾乎被用於任何類型的開發者組織。 您在業界可能會遇到此類文件的其他名稱，例如 TDD（*技術設計文件*）或 SDD（*軟體設計文件*）。有些人會爭論它們之間的區別，但我們不會。 **有趣的事實**：RFC 是由 IETF（*網路工程任務組*）發明的，該組織是我們今天使用的一些最重要的網路標準和協議背後的工程組織！不算太寒酸吧？ ## 什麼時候該寫 RFC，什麼時候可以跳過？  那麼，為什麼要費勁去寫你最終將要編碼的內容，而不是節省時間並簡單地去做呢？ **如果您正在處理錯誤或相對簡單的功能，非常清楚必須做什麼並且不會影響專案結構，那麼就不需要 RFC - 啟動 IDE 並開始破解！** 但是，如果您要引入一個全新的概念（例如，引入基於角色的權限系統）或更改專案的架構（例如，新增對執行後台作業的支援），那麼您可能需要在輸入「git」之前退一步checkout -b my-new-feature` 並深入到那個甜蜜的編碼區域。 綜上所述，有時很難確定是否應該編寫該 RFC。也許這是一個更突出的功能，但你以前做過類似的事情，並且你已經在頭腦中規劃好了一切，而且幾乎沒有任何疑問。為了解決這個問題，我喜歡使用以下一個簡單的啟發式方法：**是否有不只一種明顯的方法來實現此功能？我們是否必須選擇一個新的庫/服務？** 如果這兩個問題的答案都是“否”，那麼您可能不需要 RFC。否則，需要進行討論，而 RFC 是解決問題的方法。做吧。  ## 這對我有什麼好處？ 我們已經確定瞭如何決定「何時」編寫 RFC，但這也是您應該這樣做的「原因」： - **你將整理你的想法並變得清晰**。如果您決定編寫 RFC，則表示您正在處理一個不平凡的開放式問題。把事情寫下來將有助於提煉你的想法並客觀地看待它們。 - **與剛開始編碼相比，你會學到更多**。你會給自己空間去探索不同的方法，常常會發現一些你原本沒有想到的東西。 - **您將眾包團隊的知識。** 透過向您的團隊尋求回饋（因此請求評論），您將全面了解您正在解決的問題並填補任何剩餘的空白。 - **您將增進團隊對程式碼庫的理解。** 透過在 RFC 上進行協作，團隊中的每個人都會了解您正在做什麼以及最終是如何做到的。這意味著下次有人必須接觸那部分程式碼時，他們將需要問你更少的問題（===更多不間斷的程式碼時間！）。 - **公關審查將會*更*順利**。還記得本文開頭的情況嗎？當你的 PR 因為「太複雜」而被拒絕時？這是因為審閱者忽略了上下文，並且您在沒有獲得團隊其他成員事先支持的情況下進行了相當大的更改。透過先編寫 RFC，您將永遠不會再遇到這種情況。 - **您的文件已經完成了 50%！** 需要明確的是，RFC 不是最終文件，您不能簡單地指出它，但您可以重複使用很多內容 - 圖像、圖表、段落等。 哇，這聽起來太棒了，我現在就想提出一個新功能，這樣我就可以為其編寫 RFC！開個玩笑，首先瀏覽 RFC 會讓編碼部分變得更加有趣 - 你確切地知道你需要做什麼，並且你不需要質疑你的方法以及建立 PR 後將如何接收它。 ## 好吧，好吧，我被賣了！那麼，我該如何寫一篇呢？ 很高興你問了！使用了許多不同的格式，或多或少是正式的，但我更喜歡保持簡單。我們在 Wasp 編寫的 RFC 不遵循嚴格的格式，但有一些共同的部分： - **元資料** - 標題、日期、審稿人等… - **問題/目標** - 你要解決什麼 - **建議的解決方案**（或更多） - **實施概述** - **評論/開放式問題** 這幾乎就是它的要點！其中每一個都可以進一步細分和細化，但這是您可以開始的基本輪廓。 ## 元資料 ⌗  這是非常不言自明的 - 您可能想要追蹤有關 RFC 的一些基本資訊 - 狀態、建立日期等。 一些模板還明確列出了審查者以及他們對RFC 的「批准」狀態- 我們沒有它，因為我們是一個溝通速度很快的小團隊，但對於不是每個人都認識每個人的大型團隊來說，它可以很方便，並且您希望有更多的流程（例如，在指導初級開發人員時）。  ## 問題🤔 這就是事情變得有趣的地方。 **您對問題或需要實現的目標/功能以及為什麼需要這樣做的定義越好，以下所有步驟就會越容易**。因此，即使在開始編寫 RFC 之前，這也是值得投資的事情 - 確保與所有相關方（例如產品所有者、其他開發人員，甚至用戶）進行交談，以加深您對要解決的問題的理解。 透過這樣做，您也很可能獲得有關可能解決方案的初步提示和指示，並對您所處的問題空間有一個粗略的認識。  以下是上面範例中的一些提示： - **從高級摘要開始** - 這樣，讀者可以快速決定這是否與他們相關以及是否應該繼續閱讀。 - **提供一些背景** - 解釋一下世界的現狀。這可以是單一句子或整個章節，這取決於目標受眾。 - **清楚地陳述問題/目標** - 解釋為什麼會出現問題並將其與用戶/公司的痛苦聯繫起來，以便動機明確。 - **如果可能的話，提供額外的細節** - 圖表、程式碼範例… → 任何可以幫助讀者更快到達「頓悟」時刻的內容。使用可折疊部分的額外要點是，RFC 的中心部分保持可消化的長度。 如果您完成了所有這些，那麼您已經踏上了通往優秀 RFC 的道路！由於明確定義問題至關重要，所以不要害怕加入更多問題並進一步分解問題。 ### 非目標🛑 這是“問題”的子部分，有時非常有價值。在此程式碼庫變更中編寫我們不想要或不會做的事情可以幫助設定期望並更好地定義其範圍。 例如，如果我們正在努力為我們的應用程式加入基於角色的身份驗證系統，人們可能會認為我們還將為其建立某種管理面板來管理使用者和新增/刪除角色。透過明確聲明不會完成（並簡要解釋原因 - 不需要，這會花費太長時間，...），審查者將更好地理解您的目標是什麼，並且您將跳過不必要的討論。 ## 解決方案與實作🛠️ 一旦我們知道我們想做什麼，我們就必須找出最好的方法！您可能已經在“問題”部分暗示了可能的解決方案，但現在是更深入研究的時候了 - 研究不同的方法，評估它們的優缺點，並概述它們如何適合現有系統。 這一部分可能是最自由的形式 - 因為它很大程度上取決於您正在做的事情的性質，所以在這裡施加許多限制是沒有意義的。您可能希望停留在更高的水平，例如係統架構，或者您可能需要深入研究程式碼並開始編寫您需要的部分程式碼。因此，我沒有一個確切的格式供您遵循，而是一組指南： ### 寫偽程式碼 RFC 的目的是傳達想法和原則，而不是編譯和涵蓋所有邊緣情況的生產級程式碼。隨意發明/想像/草繪任何您需要的東西（例如，想像您已經有一個發送電子郵件的功能並使用它，即使您沒有），並且不要用實現細節來妨礙您自己或讀者（除非這正是RFC 的內容）。 最好從較高的級別開始，然後當您意識到需要它或其中一位審閱者建議時再深入。 ### 了解其他人是如何做到的  根據您正在開發的產品類型，您發現這一點的方式可能會有所不同，但幾乎總是有一種方法可以做到這一點。如果您正在開發像 [Wasp](https://github.com/wasp-lang/wasp) 這樣的開源工具，您可以簡單地查看其他流行的解決方案（也是開源的）並了解它們是如何做到的它。如果您正在開發 SaaS，並且需要弄清楚是否使用 cookie 還是 JWT 進行身份驗證，您可能有一些朋友以前這樣做過，您可以詢問他們。最後，只需 Google/GPT 即可。 為什麼這麼有幫助？ **原因是它讓您（和審閱者）對您的解決方案充滿信心。如果其他人以這種方式成功做到了，這可能是一個有前途的方向。**它還可能幫助您發現以前沒有想到的方法，或者作為您可以建置的基礎。當然，永遠不要認為任何事情都是理所當然的，並考慮到您情況的具體需要，而一定要利用他人的知識和專業知識。 ### 留下未完成的事情並保持骯髒 RFC 的要點是「C」部分，因此協作（是的，我知道它實際上代表「_comments_」）。這不是一個你必須獲得滿分並且不問任何問題的測試 - 如果發生這種情況，你可能一開始就不應該編寫 RFC。 解決問題需要團隊的努力，而你只是第一個嘗試解決問題並推動事情向前發展的人。您的任務是盡可能合理地奠定基礎（完善問題，探索解決問題的多種方法，辨識發現的新子問題），以便審閱者可以快速掌握狀態並提供有效的反饋，指導需要的地方最多。 **RFC 的主要工作是確定最重要的問題並將審閱者的注意力引導到這些問題上，而不是解決它們。** 您正在編寫的 RFC 應該被視為一個討論區和一個正在進行的工作，而不是一件在展示在觀眾面前之前必須完善的藝術品。 ## 評論和開放式問題 🎯 在文件的最後一部分中，您可以總結主要思想並突出顯示最大的未決問題。在瀏覽所有內容之後，提醒讀者他的注意力在哪裡最有價值可能會有所幫助。 ## 現在我知道何時以及如何寫 RFC！您有任何我可以用作起點的模板嗎？ 當然！如前所述，我們的格式非常輕量級，但請隨意查看[我們用作示例的 RFC](https://wasp-lang.notion.site/RFC-Auth-without-user-define-entities-6d2925439627456ab01b74ff4b4cd087?pvs=4) 獲得靈感。您的公司也可能已經有他們推薦的現成範本。 以下是您可以使用和/或適應您的需求的一些內容： - [Squarespace RFC 範本](https://engineering.squarespace.com/s/Squarespace-RFC-Template.pdf) - _您有推薦的範本嗎？我很高興將其列在這裡！_ ## 我應該使用什麼工具來寫 RFC？有這麼多選擇！ 您使用的確切工具可能是 RFC 中最不重要的部分，但它仍然很重要，因為它圍繞它設置了工作流程。如果您的公司已經選擇了一種工具，那麼當然要堅持使用。如果沒有，以下是我遇到的最常見的選擇，以及快速評論： - **Google 文件** - 經典選擇。超級容易對文件的任何部分進行評論，這是最重要的功能。 - **概念** - 也非常適合協作，此外還提供一些 Markdown 元件，例如可折疊和表格，這可以使您的 RFC 更具可讀性。 - **Github 問題/PR** - 有時會使用它，特別是對於 OSS 專案。缺點是很難對文件的特定部分進行註釋（只能對整行進行註釋），而且插入圖表也相當笨拙。優點是所有內容（程式碼和 RFC）都保留在同一個平台上 我們目前使用 Notion，但以上任何一個都可以是不錯的選擇。 ## 概括  正如在 RFC 末尾編寫摘要是最佳實踐一樣，我們也會在這裡做同樣的事情！這篇文章比我預期的要長，但是有很多東西要提到 - 我希望你會發現它有用！ 最後，**能夠清楚地表達你的想法，提出問題，並根據團隊的反饋客觀地分析可能的解決方案，這將幫助你開發正確的東西，這是最終的生產力黑客**。 這就是您成為真正的 10 倍工程師的方法。感謝您的閱讀，下次再見！ --- 原文出處：https://dev.to/wasp/develop-the-right-thing-every-time-and-become-a-10x-engineer-the-art-of-writing-rfcs-2mc6
--- 標題：我如何教 Git 發表：真實 描述： 標籤： git, 學習 canonical_url：https://blog.ltgt.net/teaching-git/ 封面圖片：https://marklodato.github.io/visual-git-guide/conventions.svg.png # 使用 100:42 的比例以獲得最佳效果。 # 發佈時間: 2023-11-26 19:17 +0000 --- 我使用 Git 已經十幾年了。八年前，我必須為一家即將建立開源專案的合作夥伴公司舉辦有關 Git（和 GitHub）的培訓課程，我將在這裡向您介紹我的教學方式。順便說一句，從那時起，我們在工作中建立了使用相同（或類似）方法的內部培訓課程。話雖如此，我並沒有發明任何東西：這很大程度上受到了其他人之前寫的內容的啟發，包括[the <cite>Pro Git</cite> book](https://git-scm. com/book/)，儘管順序不同，但 <abbr title="in my view">IMO</abbr> 可以有所作為。 我寫這篇文章的原因是，多年來，我不斷看到人們實際上使用 Git，但沒有真正理解他們在做什麼；他們正在使用 Git。他們要么被鎖定在一個非常具體的工作流程中，他們被告知要遵循，並且無法適應另一個開源專案正在使用的工作流程（這也適用於開源維護人員並不真正了解外部貢獻者如何使用 Git） ），或者如果任何事情沒有按照他們想像的方式執行，或者他們在呼叫Git 命令時犯了錯誤，他們就會完全迷失。我受到 [Julia Evans](https://jvns.ca) 對 Git 的（更新）興趣的啟發而寫下來，因為她有時會在社交網絡上徵求評論。 我的目標不是真正教你有關 Git 的知識，而是更多地分享我教授 Git 的方法，以便其他可能會教導的人從中獲得靈感。因此，如果您正在學習 Git，那麼這篇文章並不是專門為您而寫的（抱歉），因此可能不是自給自足的，但希望其他學習資源的連結足以填補空白，使其成為也是有用的學習資源。如果您是視覺學習者，這些外部學習資源都是有插圖的，甚至是視覺學習的。 ## 心理模型 一旦我們清楚了為什麼我們使用VCS（版本控制系統）來記錄_commits_ 中的更改（或者換句話說，我們_將我們的更改_提交到歷史記錄；我假設你對這個術語有一定的熟悉），讓我們多了解一下Git具體來說。 我認為理解 Git 至關重要的一件事是獲得其背後概念的準確心理模型。 首先，這並不是很重要，但Git 實際上並沒有記錄_changes_，而是記錄我們文件的_snapshots_（至少在概念上是這樣；它將使用_packfiles_ 來有效地儲存內容，並且在某些情況下方實際上會儲存_changes_ –diffs–），並且會按需產生差異。不過，這有時會顯示在某些命令的結果中（例如為什麼某些命令顯示一個檔案被刪除而另一個檔案被加入，而其他命令顯示一個檔案被重新命名）。 現在讓我們深入探討一些 Git 概念，或是 Git 如何實現一些常見的 VCS 概念。 ### 犯罪 Git _commit_ 是： * 一個或多個父親提交，或第一次提交沒有父親提交 (_root_) * 提交訊息 * 作者和作者日期（實際上是帶有時區偏移的時間戳） * 提交者和提交日期 * 和我們的檔案：相對於儲存庫根的路徑名、_mode_（UNIX 檔案系統權限）及其內容 每次提交都會獲得一個標識符，該標識符是透過計算該資訊的 SHA1 雜湊值確定的：更改逗號，您將獲得不同的 SHA1，即不同的_提交物件_。 (<abbr title="For What it's value">Fwiw</abbr>，Git 正在慢慢[轉向 SHA-256](https://git-scm.com/docs/hash-function-transition) 作為哈希功能）。 #### 旁白：SHA1 是如何計算的？ Git 的儲存是_內容尋址_，這表示每個_物件_都使用直接從其內容派生的名稱進行存儲，並採用 SHA1 雜湊的形式。 從歷史上看，Git 將所有內容儲存在文件中，我們仍然可以這樣推理。文件的內容儲存為 _blob_，目錄儲存為 _tree_（一個文字文件，列出目錄中的文件及其名稱、模式和表示其內容的 _blob_ 的 SHA1，以及其子目錄及其名稱和 SHA1他們的_樹_） 如果您想了解詳細訊息，Julia Evans（再次）寫了一篇令人驚嘆的[博客文章](https://jvns.ca/blog/2023/09/14/in-a-git-repository-- where-do-your-檔案-即時-/);或者您可以[從 <cite>Pro Git</cite> 書中閱讀](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)。 <圖> <img src=https://git-scm.com/book/en/v2/images/commit-and-tree.png width=800 height=443 alt='包含5 個框的圖表，分為3 列，每個框標有 5 位 SHA1 前綴；左邊的子標籤為“commit”，包含元資料“tree”，中間是框的 SHA1，“author”和“committer”的值均為“Scott”，文字為“The initial commit of我的專案”;中間的框被子標記為“tree”，包括三行，每行標記為“blob”，其餘 3 個框的 SHA1 以及看起來像文件名的內容：“README”、“LICENSE”和“test.rb” ”;最後 3 個框，在右側垂直對齊，都是子標籤為「blob」的內容，包含看起來像是 README、LICENSE 和 Ruby 原始檔內容開頭的內容；有箭頭連結框：提交指向樹，樹指向 blob。'> <figcaption>提交及其樹（來源：<a src=https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell><cite>Pro Git</引用></a>）</figcaption> </圖> _commit_ 中的_父親提交_ 建立一個代表我們歷史的[有向無環圖](https://en.wikipedia.org/wiki/Directed_acirclic_graph)：_有向無環圖_ 由連結的節點（我們的提交）組成與有向邊一起（每個提交連結到其父提交，有一個方向，因此_directed_）並且不能有循環/循環（提交永遠不會是它自己的祖先，它的祖先提交都不會連結到它作為父提交）。 <圖> <img src=https://git-scm.com/book/en/v2/images/commits-and-parents.png width=800 height=265 alt='包含 6 個框排列成 2 行 3 列的圖表;第一行的每個框都標有 5 位 SHA1 前綴，子標籤為“commit”，元資料“tree”和“parent”均帶有 5 位 SHA1 前綴（每次都不同）、“author”和“ committer」的值都是“Scott”，以及一些代表提交訊息的文字；左邊的盒子沒有「父」值，另外兩個盒子將左邊的盒子的 SHA1 作為「父」；這些框之間有一個箭頭，指向代表「父」的左側；順便說一句，左邊的框與上圖中的提交框具有相同的 SHA1 和相同的內容；最後，每個提交框也指向其下方的一個框，每個框都標記為「快照 A」、「快照 B」等，並且可能代表從每個提交連結的「樹」物件。'> <figcaption>提交及其父級（來源：<a src=https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell><cite>Pro Git</ cite ></a>)</figcaption> </圖> ### 參考文獻、分支和標籤 現在 SHA1 哈希對於人類來說是不切實際的，雖然 Git 允許我們使用唯一的 SHA1 前綴而不是完整的 SHA1 哈希，但我們需要更簡單的名稱來引用我們的提交：輸入 _references_。這些是我們選擇的提交的_標籤_（而不是 Git）。 有幾種_參考_： * _branches_ 是_moving_ 引用（請注意，`main` 或`master` 並不特殊，它們的名稱只是一個約定） *_標籤_是_不可變_引用 * `HEAD` 是一個特殊的引用，指向_當前提交_。它通常指向一個分支而不是直接指向一個提交（稍後我們會看到原因）。當一個引用指向另一個引用時，這稱為[_符號引用_](https://blog.ltgt.net/confusing-git-terminology/#reference-symbolic-reference)。 * Git 會在某些操作期間為您設定其他特殊參考（`FETCH_HEAD`、`ORIG_HEAD` 等） <圖> <img src=https://git-scm.com/book/en/v2/images/branch-and-history.png width=800 height=430 alt='帶有 9 個框的圖； 6 個盒子的排列方式與上圖相同，並且標記相同（三個提交及其 3 個樹）；最右邊（最新）提交上方的兩個框，箭頭指向它，分別標記為“v1.0”和“master”；最後一個框位於“master”框上方，有一個箭頭指向它，並標記為“HEAD”。'> <figcaption>分支及其提交歷史記錄（來源：<a src=https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell><cite>Pro Git< /引用></a>）</figcaption> </圖> ### 三個狀態 當您在 Git 儲存庫中工作時，您在 Git 歷史記錄中操作和記錄的檔案位於您的_工作目錄_中。要建立提交，您需要在 [_index_](https://blog.ltgt.net/confusing-git-terminology/#index-staged-cached) 或_暫存區域_中_暫存_檔案。完成後，您附加一則提交訊息並將您的_staged_檔案移至_history_。 為了關閉循環，_工作目錄_是根據_歷史記錄_中的給定提交進行初始化的。 <圖> <img src=https://git-scm.com/book/en/v2/images/areas.png width=800 height=441 alt='包含3 位參與者的序列圖：「工作目錄」、「暫存區域」和「.git directpry（儲存庫）」；有一條“簽出專案”訊息從“.git 目錄”到“工作目錄”，然後從“工作目錄”到“暫存區域”進行“階段修復”，最後從“暫存區域”進行“提交”區域」到「.git 目錄」。'> <figcaption>工作樹、暫存區域和 Git 目錄（來源：<a href="https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#_the_third_states" ><cite>Pro Git</cite></a>）</figcaption> </圖> ### 旁白：忽略文件 並非所有檔案都需要_追蹤_歷史記錄：由建置系統（如果有）產生的檔案、特定於您的編輯器的檔案以及特定於您的作業系統或其他工作環境的檔案。 Git 允許定義要忽略的檔案或目錄的命名模式。這實際上並不意味著Git 會忽略它們並且無法_跟踪_，但如果不跟踪它們，多個Git 操作將不會向您顯示它們或操縱它們（但您可以手動將它們加入到歷史記錄中，並且從那時起，他們將不再被_忽略_）。 忽略檔案是透過將路徑名稱（可能使用 glob）放入忽略檔案中來完成的： * 儲存庫中任何位置的 `.gitignore` 檔案定義了包含目錄的忽略模式；這些忽略文件會在歷史記錄中被跟踪，作為開發人員之間共享它們的一種方式；在這裡，您將忽略建置系統產生的那些檔案（Gradle 專案的“build/”，Eleventy 網站的“_site/”等） * `.git/info/excludes` 是您機器上的本機儲存庫；很少使用，但有時很有用，所以很高興了解一下 * 最後 `~/.config/git/ignore` 對機器來說是全域的（對你的使用者）；在這裡，您將忽略特定於您的電腦的文件，例如特定於您使用的編輯器的文件，或特定於您的作業系統的文件（例如macOS 上的“.DS_Store”或Windows 上的“Thumbs. db”） ） ### 加起來 這是所有這些概念的另一種表示： <圖> <img src=https://marklodato.github.io/visual-git-guide/conventions.svg width=907 height=529 alt='有 10 個框的圖； 5 個框在中心排成一行，標有 5 位 SHA1 前綴，它們之間有從右向左指向的箭頭；一條註釋將它們描述為“提交物件，由 SHA-1 哈希標識”，另一條註釋將其中一個箭頭描述為“子項指向父項”；一對框（看起來像一個水平分割成兩個框的單一框）位於最右邊（最新）提交的上方，有一個向下指向它的箭頭，該對的上面的框被標記為“HEAD”並描述為“引用當前分支”；下面的框被標記為“main”並被描述為“目前分支”；第七個框位於另一個提交上方，有一個向下指向它的箭頭；它被標記為“穩定”並被描述為“另一個分支”；最後兩個框位於提交歷史記錄下，一個在另一個之上；最底部的框標記為“工作目錄”並描述為“您'看到'的文件”，它和提交歷史記錄之間的另一個框標記為“階段（索引）”並描述為“要存取的文件”在下次提交中”。'> <figcaption>提交、引用和區域（來源：<a href=https://marklodato.github.io/visual-git-guide/index-en.html#conventions><cite>可視化 Git 參考</cite >< /a>，馬克‧洛達托）</figcaption> </圖> ## 基本操作 這就是我們開始討論 Git 指令以及它們如何與圖表互動的地方： * `git init` 初始化一個新的儲存庫 * `git status` 取得檔案狀態的摘要 * `git diff` 顯示任意兩個工作目錄、索引、`HEAD` 之間的更改，或實際上任何提交之間的更改 * `git log` 顯示並搜尋您的歷史記錄 * 建立提交 * `git add` 將檔案加入_index_ * `git commit` 將_index_ 轉換為_commit_ （帶有新增的_commit 訊息_） * `git add -p` 以互動方式將檔案新增至 _index_：選擇要新增的變更以及僅將哪些變更保留在工作目錄中，逐一檔案、逐個部分（稱為 _hunk_） * 管理分支機構 * `gitbranch` 顯示分支，或建立分支 *`git switch`（也稱為`git checkout`）將分支（或任何提交，實際上是任何_樹_）簽出到您的工作目錄 * `git switch -b` （也稱為 `git checkout -b`）作為 `gitbranch` 和 `gitswitch` 的捷徑 * `git grep` 搜尋您的工作目錄、索引或任何提交；這是一種增強的“grep -R”，它支援 Git * `gitblame` 來了解更改給定文件每一行的最後一次提交（因此，誰應該為錯誤負責） * `git stash` 將未提交的更改放在一邊（這包括_staged_文件，以及工作目錄中的_tracked_文件），然後_unstash_它們。 ### 提交、分支切換和 HEAD 當您建立提交（使用「git commit」）時，Git 不僅建立_提交物件_，還移動「HEAD」以指向它。如果「HEAD」實際上指向一個分支（通常是這種情況），Git 會將該分支移動到新的提交（並且「HEAD」將繼續指向該分支）。每當當前分支是另一個分支的祖先（該分支指向的提交也是另一個分支的一部分）時，提交將使“HEAD”移動相同，並且分支將_發散_。 當您切換到另一個分支（使用“git switch”或“git checkout”）時，“HEAD”會移至新的目前分支，並且您的工作目錄和索引將設定為重新組合該提交的狀態（未提交的更改將暫時保留；如果 Git 無法做到這一點，它將拒絕切換）。 如需更多詳細資訊和視覺表示，請參閱[commit](https://marklodato.github.io/visual-git-guide/index-en.html#commit) 和[checkout](https://marklodato. github .io/visual-git-guide/index-en.html#checkout）Mark Lotato 的<cite>可視化Git 參考</cite>的部分（請注意，該參考是幾年前寫的，當時`git switch ` 和 ` git Restore` 不存在，而 `git checkout` 是我們所擁有的一切；因此 _checkout_ 部分涵蓋的內容比 `git switch` 多一點）。 當然，<cite>Pro Git</cite> 這本書也是一個很好的視覺表示參考； [<cite>Branches in a Nutshell</cite> 子章節](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) 涵蓋了所有內容的很大一部分上述的。 ### 旁白：Git 是保守的 正如我們在上面所看到的，由於其_內容尋址存儲_，對提交的任何“更改”（例如使用“git commit --amend”）實際上都會導致不同的提交（不同的 SHA1）。 _舊提交_不會立即消失：Git 使用_垃圾收集_最終刪除無法從任何_引用_存取的提交。這意味著，如果您設法找回提交SHA1，則可以恢復許多錯誤（“git reflog”可以在此處提供幫助，或者符號“<branch-name>@{<n>}”，例如“main@{ 1}”） ` main` 在更改之前指向的最後一次提交）。 ### 使用分支機構 我們在上面已經看到了分支是如何發散的。 但分歧要求最終_合併_變回來（使用“git merge”）。 Git 在這方面非常擅長（我們稍後會看到）。 合併的一個特殊情況是目前分支是要合併到的分支的祖先。在這種情況下，Git 可以執行 [_fast-forward merge_](https://blog.ltgt.net/confusing-git-terminology/#can-be-fast-forwarded)。 由於兩個分支之間的操作可能始終針對同一對分支，因此 Git 允許您設定一個分支來追蹤另一個分支。另一個分支被稱為_追蹤_它的分支的_上游_。例如，設定時，「git status」將告訴您兩個分支彼此之間有多少分歧：目前分支是[_最新_](https://blog.ltgt.net/confusing-git-terminology /#your- branch-is-up-to-date-with-originmain) 及其上游分支，_後面_和[可以快轉](https://blog.ltgt.net/confusing-git-terminology/ #can-be- fast-forwarded），_超前_許多提交，或它們有分歧，每個提交都有一定數量。其他命令將使用該資訊為參數提供良好的預設值，以便可以省略它們。 要整合來自另一個分支的更改，而不是合併，另一種選擇是_cherry-pick_（使用同名命令）單一提交，而不包含其歷史記錄：Git 將計算該提交帶來的更改並將相同的更改應用於當前分支，建立一個與原始分支類似的新提交（如果您想了解更多有關Git 實際操作方式的訊息，請參閱Julia Evans 的[<cite>如何gitcherry-pick 和revert 使用3 路合併< /cite> ](https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/))。 最後，工具帶中的另一個指令是「rebase」。 您可以將其視為一次進行許多選擇的方法，但它實際上更強大（正如我們將在下面看到的）。但在其基本用途中，它只是這樣：您給它一系列提交（在作為起點的任何提交和作為終點的現有分支之間，預設為當前分支）和一個目標，並且它會挑選所有這些提交位於目標之上，並最終更新用作終點的分支。這裡的指令的形式是`git rebase --onto=<target> <start> <end>`。與許多 Git 命令一樣，參數可以省略，並且具有預設值和/或特定含義：因此，`git rebase` 是 `git rebase --fork-point upper` 的簡寫，其中 `upstream` 是 [upstream]當前分支的（https://blog.ltgt.net/confusing-git-terminology/#untracked-files-remote-tracking-branch-track-remote-branch）（我會忽略`--fork-point`這裡，它的作用很微妙，在日常使用上並不那麼重要），它本身就是`git rebase upper HEAD` 的簡寫（其中`HEAD` 必須指向一個分支），它本身就是`git rebase 的簡寫-- on=upstream uploaded `，`git rebase --onto=upstream $(git merge-baseupstream HEAD) HEAD` 的簡寫，並將rebase `upstream` 的最後一個共同祖先與當前分支之間的所有提交另一方面，手和當前分支（即自從它們分歧以來的所有提交），並將它們重新應用到“上游”之上，然後更新當前分支以指向新的提交。明確使用`--onto` （其值與起始點不同）實際上很少見，請參閱[我之前的文章](https://blog.ltgt.net/confusing-git-terminology/#git- rebase- --onto) 對於一個用例。 我們無法在沒有互動式變體「git rebase -i」的情況下呈現「git rebase」：它以與非互動式變體完全相同的行為開始，但在計算需要完成的操作之後，它將允許您對其進行編輯（作為編輯器中的文字文件，每行一個操作）。預設情況下，所有選定的提交都是精心挑選的，但您可以對它們重新排序，跳過某些提交，甚至將某些提交合併到單一提交中。實際上，您可以挑選最初未選擇的提交，甚至建立合併提交，從而完全重寫整個歷史記錄！最後，您還可以停止對其進行編輯（然後使用“git commit --amend”，和/或可能在繼續變基之前建立新的提交），和/或在兩次提交之間執行給定的命令。最後一個選項非常有用（例如，驗證您沒有在歷史記錄的每個點上破壞您的專案），您可以在`--exec` 選項中傳遞該命令，Git 將在每個重新基底提交之間執行它（這也適用於非互動式變基；在互動模式下，當能夠編輯變基場景時，您將看到在每個櫻桃選擇行之間插入執行行）。 更多詳細資訊和視覺表示，請參閱[merge](https://marklodato.github.io/visual-git-guide/index-en.html#merge)、[cherry pick](https://marklodato . github.io/visual-git-guide/index-en.html#cherry-pick) 和 [rebase](https://marklodato.github.io/visual-git-guide/index-en.html#rebase) Mark Lodato 的<cite>視覺化Git 參考</cite> 部分，以及[<cite>基本分支和合併</cite>](https://git-scm.com/book/en/v2/Git-分支-基本-分支和合併），[<cite>變基</cite>]（https://git-scm.com/book/en/v2/Git-Branching-Rebasing）和[<cite>重寫歷史< /cite>](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) <cite>Pro Git</cite> 書的子章節。 您也可以查看 David Drysdale 的 [<cite>Git Visual Reference</cite>](https://lurklurk.org/gitpix/gitpix.html) 中的「分支和合併」圖。 ## 與他人合作 目前，我們只在我們的儲存庫中進行本地工作。 但 Git 是專門為與他人合作而建構的。 讓我介紹一下_遙控器_。 ### 遙控器 當您_複製_儲存庫時，該儲存庫將成為本機儲存庫的_遠端_，名為「origin」（就像「main」分支一樣，這只是預設值，名稱本身沒有什麼特別的，除了有時用作省略命令參數時的預設值）。然後，您將開始工作，建立本地提交和分支（因此從遠端_forking_），同時遠端可能會從其作者那裡獲得更多提交和分支。因此，您需要將這些遠端變更同步到本機儲存庫，並希望快速了解與遠端相比您在本機所做的變更。 Git 處理這個問題的方式是在一個特殊的命名空間中記錄它所知道的遠端（主要是分支）的狀態：「refs/remote/」。這些被稱為[_遠端追蹤分支_](https://blog.ltgt.net/confusing-git-terminology/#untracked-files-remote-tracking-branch-track-remote-branch)。 Fwiw，本機分支儲存在「refs/heads/」命名空間中，標籤儲存在「refs/tags/」中（來自遠端的標籤通常直接「匯入」到「refs/tags/」中，因此例如您會遺失位置資訊他們來自）。您可以根據需要擁有任意多個遙控器，每個遙控器都有一個名稱。 （請注意，遙控器不一定位於其他電腦上，它們實際上可以位於同一台電腦上，直接從檔案系統存取，因此您無需進行任何設定即可使用遙控器。） ### 取得 每當你從遠端 _fetch_ 時（使用 `git fetch`、`git pull` 或 `git Remote update`），Git 都會與它對話以下載它還不知道的提交，並更新 _remote-tracking遠端分支_ 。要取得的確切引用集以及取得它們的位置將傳遞給 `git fetch` 命令（如 [refspecs](https://blog.ltgt.net/confusing-git-terminology/#refspecs) ）以及儲存庫的` .git/config` 中定義的預設值，預設由`git clone` 或`git remote add` 配置以取得所有分支（遠端上的`refs/heads/` 中的所有內容）並放置它們位於` refs/remote/<remote>` 中（因此`origin` 遙控器的`refs/remote/origin/` ）具有相同的名稱（因此遙控器上的`refs/heads/main` 變成`refs/remote / origin/main` 本地）。 <圖> <img src=https://git-scm.com/book/en/v2/images/remote-branches-5.png width=800 height=577 alt='帶有3 個大方框的圖表，代表機器或儲存庫，包含代表提交歷史的較小框和箭頭；一個框標記為“git.outcompany.com”，子標記為“origin”，並包含名為“master”的分支中的提交；另一個框標記為“git.team1.outcompany.com”，子標記為“teamone”，並包含名為“master”的分支中的提交； 「origin」和「teamone」中的提交 SHA1 雜湊值相同，除了「origin」在其「master」分支上多了一個提交，即「teamone」在「後面」；第三個框標記為“我的電腦”，它包含與其他兩個框相同的提交，但這次分支被命名為“origin/master”和“teamone/master”；它還在名為“master”的分支中包含另外兩個提交，與遠端分支的較早點不同。'> <figcaption>遠端和遠端追蹤分支（來源：<a href=https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches><cite>Pro Git</cite>< / a>)</figcaption> </圖> 然後，您將使用與分支相關的命令來獲取從_遠端追蹤分支_到本地分支的更改（“git merge”或“git rebase”），或“git pull”，這只不過是“git fetch”的簡寫` 後面跟著 `git merge` 或 `git rebase`。 <abbr title="By the way">順便說一句</abbr>，在很多情況下，當你建立本地分支時，Git 會自動將_遠端追蹤分支_設定為本地分支的_上游_（它會告訴你相關資訊）當這種情況發生時）。 ### 推 要與其他人共用您的更改，他們可以將您的儲存庫新增為遠端儲存庫並從中_pull_（意味著透過網路存取您的電腦），或者您可以_push_到遠端儲存庫。 （如果您要求某人從您的遙控器中提取更改，這稱為..._拉請求_，您可能在 GitHub 或類似服務中聽說過這個術語。） 推送與提取類似，相反：您將提交發送到遠端並更新其分支以指向新提交。作為安全措施，Git 只允許遠端分支_快速轉送_；如果您想推送以非快轉方式更新遠端分支的更改，則必須使用「git push --force-with-lease」（或「git push --force」）_force_它，但要小心：`-- force-with-lease`將首先確保您的_遠端追蹤分支_與遠端分支是最新的，以確保自上次_fetched_以來沒有人將變更推送到分支；` --force` 不會執行該檢查，而是按照您的指示執行操作，風險由您自己承擔）。 與「git fetch」一樣，您可以將要更新的分支傳遞給「git push」命令，但如果您不這樣做，Git 會提供良好的預設行為。如果你不指定任何東西，Git 會從目前分支的上游推斷遠程，所以大多數時候 `git push` 相當於 `git push origin`。這實際上是“git Push origin main”的簡寫（假設當前分支是“main”），它本身是“git Push origin main:main”的簡寫，是“git Push origin refs/heads/main:refs/”的簡寫heads/main`，意思是將本地的`refs/heads/main`推送到`origin`遠端的`refs/heads/main`。有關使用不同來源和目標指定 _refspecs_ 的一些用例，請參閱[我之前的文章](https://blog.ltgt.net/confusing-git-terminology/#refspecs)。 <圖> <img src=https://lurklurk.org/gitpix/push2.svg width=1052 height=744 alt='代表「git push」指令的圖表，有四個 git 圖表（點，有些有標籤，用線連接) 排列成兩行兩列；列之間的箭頭表示左列是「之前」狀態，右列是「之後」狀態；上面一行中的圖位於雲內部，代表遠端儲存庫，並且有兩個分支，“master”和“other”，它們偏離了共同的祖先；左下圖與上面的圖形狀相同，只是標籤更改為“origin/master”和“origin/other”，並且每個分支有更多提交：與“origin”分支相比，“master”分支有兩個額外的提交/master”，而“other”比“origin/other”多了一個提交；與左上圖相比，右上圖在其「master」分支中多了兩次提交；右下圖與左下圖相同，除了「origin/master」現在指向與「master」相同的提交；換句話說，在「之前」狀態下，遠端缺少三個提交，而在「git Push」之後，本地「master」分支的兩個提交被複製到遠端，而「其他」保持不變。'> <figcaption><code>git Push</code>（資料來源：<a href=https://lurklurk.org/gitpix/gitpix.html><cite>Git 視覺參考</cite></a>，David Drysdale ）</圖標題> </圖> 更多詳細資訊和視覺表示，請參閱[<cite>遠端分支</cite>](https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches)，[< cite >使用遙控器</cite>](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)，以及[<cite>為專案做出貢獻</ cite> ](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) <cite>Pro Git</cite> 書的子章節，以及「處理遠程來自David Drysdale 的[<cite>Git Visual Reference</cite>](https://lurklurk.org/gitpix/gitpix.html) 的「儲存庫」圖表。 <cite>Pro Git</cite> 的<cite>為專案做出貢獻</cite>一章也涉及在GitHub 等平台上為開源專案做出貢獻，您必須先_fork_儲存庫，然後透過_pull requests_進行貢獻（或_合併請求_）。 ## 最佳實踐 這些是針對初學者的，希望不會引起太多爭議。 嘗試保留_clean_歷史記錄： * 明智地使用合併提交 * 清晰且高品質的提交訊息（請參閱[<cite>提交指南</cite>](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project #_commit_guidelines）在<cite>Pro Git</cite> 中） * make _atomic_ commits：每個提交應該獨立於歷史記錄中跟隨它的提交進行編譯和執行 這僅適用於您與他人分享的歷史記錄。 在本地，想怎麼做就怎麼做。對於初學者，我會給以下建議： * 不要直接在“main”（或“master”，或您在遠端上沒有專門擁有的任何分支）上工作，而是建立本機分支；它有助於解耦不同任務的工作：即將開始處理另一個錯誤或功能，同時等待有關當前任務的說明的更多詳細資訊？切換到另一個分支，稍後您可以透過切換回來回到該分支；它還使從遠端更新變得更容易，因為如果您的本地分支只是同名遠端分支的副本，沒有任何本地更改（除非您想推送這些更改），您確信不會發生衝突到該分支） * 毫不猶豫地重寫你的提交歷史記錄（`git commit --amend` 和/或 `git rebase -i`），但不要太早這樣做；在工作時堆疊許多小提交是完全可以的，並且只在共享之前重寫/清理歷史記錄 * 同樣，請毫不猶豫地重新調整本機分支以整合上游變更（直到您共用該分支，此時您將遵循專案的分支工作流程） 如果出現任何問題並且您迷路了，我的建議是使用 `gitk` 或 `gitk HEAD @{1}`，也可能使用 `gitk --all` （我在這裡使用 `gitk` 但使用任何工具你喜歡），可視化你的Git 歷史並嘗試了解發生了什麼。由此，您可以回滾到先前的狀態（`git reset @{1}`）或嘗試修復問題（擇優選擇提交等）。合併失敗，您可以使用“git rebase --abort”或“git merge - -abort」等命令中止並回滾到先前的狀態。 為了讓事情變得更簡單，請不要猶豫，在任何可能具有破壞性的命令（`git rebase`）之前，建立一個分支或標籤作為“書籤”，如果事情沒有按預期進行，您可以輕鬆重置。當然，在執行這樣的命令後，請檢查歷史記錄和文件，以確保結果是您所期望的。 ## 進階概念 這只是其中的一小部分，還有更多值得探索！ * 分離的「HEAD」：[`git checkout` 手冊頁](https://git-scm.com/docs/git-checkout#_detached_head) 有一個關於該主題的很好的部分，另請參閱[我之前的帖子](https ://blog.ltgt.net/confusing-git-terminology/#detached-head-state），要獲得良好的視覺表示，請參閱[<cite>使用分離的HEAD 進行提交</ cite>](https:// /marklodato.github.io/visual-git-guide/index-en.html#detached) Mark Lodato 的 <cite>視覺化 Git 參考</cite> 部分。 * Hooks：這些是可執行檔（大多數情況下是 shell 腳本），Git 將執行它們來回應儲存庫上的操作；人們使用它們在每次提交之前檢查程式碼（如果失敗則中止提交），產生或後處理提交訊息，或在有人推送到儲存庫後觸發伺服器上的操作（觸發建置和/或部署）。 * 一些很少需要的命令可以在您真正需要時節省您的時間： * `git bisect`：一個進階命令，透過測試多個提交（手動或透過腳本）來幫助您找出哪個提交引入了錯誤；對於線性歷史，這是使用二分法並且可以手動完成，但是一旦您有許多合併提交，這就會變得更加複雜，並且最好讓 git bisect 來完成繁重的工作。 * `git filter-repo`：實際上是一個[第三方命令](https://github.com/newren/git-filter-repo)，作為Git 自己的`filter-branch` 的替代品，它允許重寫儲存庫的整個歷史記錄，以刪除錯誤新增的文件，或協助將儲存庫的一部分提取到另一個儲存庫。 我們完成了。 有了這些知識，人們應該能夠將任何 Git 命令映射到如何修改提交的_有向無環圖_，並了解如何修復錯誤（在錯誤的分支上執行合併？基於錯誤的分支重新建置？）並不是說理解這些事情會很容易，但至少應該是可能的。 --- 原文出處：https://dev.to/tbroyer/how-i-teach-git-3nj3
## **簡介** 在這篇文章中，我將介紹 11 個我玩得很開心並想與您分享的函式庫。  --- ## 1. [Taipy](https://github.com/Avaiga/taipy) Taipy 是一個開源程式庫，旨在輕鬆開發前端 (GUI) 和 ML/資料管道。 不需要其他知識（不需要 CSS，不需要 JS，什麼都不需要！）。 建立您夢想的應用程式得益於： - 完整的客製化和互動 - 多頁和多用戶 - 管道圖形編輯器 - ...還有更多。 您甚至可以將以下所有庫與 Taipy 一起使用，並使其更加有趣。 你的想像力是極限！  ---  https://github.com/Avaiga/taipy 我們已經快有 1000 顆星了，沒有你就無法做到這一點🙏 --- ## 2.[Asciimatics](https://github.com/peterbrittain/asciimatics) Asciimatics 是一個可讓您建立全螢幕文字 UI 的程式庫。這個圖書館是出於對 80 年代的懷舊之情而建造的。 以下是它們的一些主要功能： - 彩色/樣式文字 - 遊標定位 - 鍵盤輸入（無阻塞或迴聲）  --- ## 3.[Arcade](https://github.com/pythonarcade/arcade) 沒有遊戲，樂趣怎麼可能有意義呢？正如庫名稱所暗示的，它允許建立 2D 影片遊戲。是的，這看起來確實很難，但 Arcade 讓它變得容易。因此，「pip install arcade」並開始遊戲或從一些[現有遊戲](https://api.arcade.academy/en/latest/sample_games.html)中汲取靈感！  --- ## 4.[Rich](https://github.com/Textualize/rich) Rich 將為您的生活增添色彩！ Rich 在您的終端機中寫入豐富的文字（顏色+樣式），因此它們最終可以反映您是誰。 豐富包括： - 不同的風格 - 降價 - 進度條 - 亞洲語言支持 - ... 和更多！  --- ## 5.[PyEphem](https://github.com/brandon-rhodes/pyephem) PyEphem 是一個在天空中迷失的好工具。該庫允許進行天文學計算；以下是一些有趣的用例： - 尋找行星在天空中的位置 - 確定春分和至日的日期 - 計算月相的日期 - ... 還有很多！ 這個圖書館一定會激發您的好奇心。  --- ## 6.[tqdm](https://github.com/tqdm/tqdm) 光是這個圖書館的名字就已經很有趣了。 Tqdm 表示兩件事： - 是西班牙文「我非常愛你」的縮寫 (*te quiero demasiado)* - 源自阿拉伯語單字“*taqaddum* ()”，意思是進步，這實際上是對該庫所做工作的一個很好的介紹。 Tqdm 是任何循環的包裝器，它將透過進度條追蹤進度。您可以自訂它，讓等待任務完成不再那麼無聊！  --- ## 7. [Pygame](https://github.com/pygame/pygame) Pygame 讓編寫視訊遊戲變得容易。該庫將使您可以存取多種多媒體元素，例如： - 圖形 - 聲音 - 輸入設備 現在，發揮您的創造力，建立您自己的 2D 互動遊戲或探索一些[可用遊戲](https://www.pygame.org/tags/all)。  --- ## 8.[Turtle](https://docs.python.org/3/library/turtle.html) 這個函式庫有所不同，因為它是 Python 語言的一部分，因此不需要 *pip install*。 Turtle 是為了教育目的而建立的，幫助新程式設計師透過在畫布上設計圖形來使用 Python 進行編碼。一種進入 Python 或享受一點創意樂趣的有趣方式。  --- ## 9.[MoviePy](https://github.com/Zulko/moviepy) MoviePy 是用 Python 編輯影片的便利工具。其功能包括： - 切割 - 連接 - 過濾 - 和轉變。 您可以閱讀許多不同的格式，包括 GIF。  --- ## 10. [Emoji](https://github.com/carpedm20/emoji) 透過此庫在 Python 程式中使用表情符號。它只是使用 *emojize()* 函數將 unicode 表情符號轉換為表情符號名稱。其他功能包括加入表情符號、計算表情符號等…  --- ## 11.[Pyjokes](https://github.com/pyjokes/pyjokes) 有了 pyjokes，您只需安裝一點就能獲得點播笑聲。這個圖書館會給你一些俏皮的笑話；您甚至可以選擇語言和類別。 玩得開心！  --- 希望您喜歡這篇文章！ 我是一名新手作家，歡迎任何改進建議！  如果您有任何疑問，請隨時與我們聯繫。 --- 原文出處：https://dev.to/taipy/11-fun-python-libraries-to-make-your-day-better-4gpc
在本文中，您將學習如何建立 **GitHub 星數監視器** 來檢查您幾個月內的星數以及每天獲得的星數。 - 使用 GitHub API 取得目前每天收到的星星數量。 - 在螢幕上每天繪製美麗的星星圖表。 - 創造一個工作來每天收集新星星。  --- ## 你的後台工作平台🔌 [Trigger.dev](https://trigger.dev/) 是一個開源程式庫，可讓您使用 NextJS、Remix、Astro 等為您的應用程式建立和監控長時間執行的作業！ [](https://github.com/triggerdotdev/trigger.dev) 請幫我們一顆星🥹。 這將幫助我們建立更多這樣的文章💖 https://github.com/triggerdotdev/trigger.dev --- ## 這是你需要知道的 😻 取得 GitHub 上星星數量的大部分工作將透過 GitHub API 完成。 GitHub API 有一些限制： - 每個請求最多 100 名觀星者 - 最多 100 個同時請求 - 每小時最多 60 個請求 [TriggerDev](https://github.com/triggerdotdev/trigger.dev) 儲存庫擁有超過 5000 顆星，實際上不可能在合理的時間內（即時）計算所有星數。 因此，我們將採用與 [GitHub Stars History](https://star-history.com/) 相同的技巧。 - 取得星星總數 (**5,715**) 除以每頁 **100** 結果 = **58 頁** - 設定我們想要的最大請求量（**20 頁最大**）除以 **58 頁** = 跳過 3 頁。 - 從這些頁面中獲取星星**（2000 顆星）**，然後獲取剩餘的星星，我們將按比例加入到其他日期（**3715 顆星**）。 它會為我們繪製一個漂亮的圖表，並在需要的地方用星星凸起。 當我們每天獲取新數量的星星時，事情就會變得容易得多。 我們將用目前擁有的星星總數減去 GitHub 上的新星星數量。 **我們不再需要迭代觀星者。** --- ## 讓我們來設定一下 🔥 我們的申請將包含一頁： - 新增您想要監控的儲存庫。 - 查看儲存庫清單及其 GitHub 星圖。 - 刪除那些你不再想要的。  > 💡 我們將使用 NextJS 新的應用程式路由器，在安裝專案之前請確保您的節點版本為 18+。 > 使用 NextJS 設定一個新專案 ``` npx create-next-app@latest ``` 我們必須將所有星星保存到我們的資料庫中！ 在我們的示範中，我們將使用 SQLite 和 `Prisma`。 它非常容易安裝，但可以隨意使用任何其他資料庫。 ``` npm install prisma @prisma/client --save ``` 在我們的專案中安裝 Prisma ``` npx prisma init --datasource-provider sqlite ``` 轉到“prisma/schema.prisma”並將其替換為以下模式： ``` generator client { provider = "prisma-client-js" } datasource db { provider = "sqlite" url = env("DATABASE_URL") } model Repository { id String @id @default(uuid()) month Int year Int day Int name String stars Int @@unique([name, day, month, year]) } ``` 然後執行 ``` npx prisma db push ``` 我們基本上已經在 SQLite 資料庫中建立了一個名為「Repository」的新表： - 「月」、「年」、「日」是日期。 - `name` 儲存庫的名稱 - 「星星」以及該特定日期的星星數量。 你還可以看到我們在底部加入了一個`@@unique`，這意味著我們可以將`name`，`month`，`year`，`day`一起重複記錄。它會拋出一個錯誤。 讓我們新增 Prisma 客戶端。 建立一個名為「helper」的新資料夾，並新增一個名為「prisma.ts」的新文件，並在其中新增以下程式碼： ``` import {PrismaClient} from '@prisma/client'; export const prisma = new PrismaClient(); ``` 我們稍後可以使用該「prisma」變數來查詢我們的資料庫。 --- ## 應用程式 UI 骨架 💀 我們需要一些函式庫來完成本教學： - **Axios** - 向伺服器發送請求（如果您覺得更舒服，可以隨意使用 fetch） - **Dayjs -** 很棒的處理日期的函式庫。它是 moment.js 的替代品，但不再完全維護。 - **Lodash -** 很酷的資料結構庫。 - **react-hook-form -** 處理表單的最佳函式庫（驗證/值/等） - **chart.js** - 我選擇繪製 GitHub 星圖的函式庫。 讓我們安裝它們： ``` npm install axios dayjs lodash @types/lodash chart.js react-hook-form react-chartjs-2 --save ``` 建立一個名為“components”的新資料夾並新增一個名為“main.tsx”的新文件 新增以下程式碼： ``` "use client"; import {useForm} from "react-hook-form"; import axios from "axios"; import {Repository} from "@prisma/client"; import {useCallback, useState} from "react"; export default function Main() { const [repositoryState, setRepositoryState] = useState([]); const {register, handleSubmit} = useForm(); const submit = useCallback(async (data: any) => { const {data: repositoryResponse} = await axios.post('/api/repository', {todo: 'add', repository: data.name}); setRepositoryState([...repositoryState, ...repositoryResponse]); }, [repositoryState]) const deleteFromList = useCallback((val: List) => () => { axios.post('/api/repository', {todo: 'delete', repository: `https://github.com/${val.name}`}); setRepositoryState(repositoryState.filter(v => v.name !== val.name)); }, [repositoryState]) return ( <div className="w-full max-w-2xl mx-auto p-6 space-y-12"> <form className="flex items-center space-x-4" onSubmit={handleSubmit(submit)}> <input className="flex-grow p-3 border border-black/20 rounded-xl" placeholder="Add Git repository" type="text" {...register('name', {required: 'true'})} /> <button className="flex-shrink p-3 border border-black/20 rounded-xl" type="submit"> Add </button> </form> <div className="divide-y-2 divide-gray-300"> {repositoryState.map(val => ( <div key={val.name} className="space-y-4"> <div className="flex justify-between items-center py-10"> <h2 className="text-xl font-bold">{val.name}</h2> <button className="p-3 border border-black/20 rounded-xl bg-red-400" onClick={deleteFromList(val)}>Delete</button> </div> <div className="bg-white rounded-lg border p-10"> <div className="h-[300px]]"> {/* Charts Component */} </div> </div> </div> ))} </div> </div> ) } ``` **超簡單的React元件** - 允許我們新增新的 GitHub 庫並將其發送到伺服器 POST 的表單 - `/api/repository` `{todo: 'add'}` - 刪除我們不需要 POST 的儲存庫 - `/api/repository` `{todo: 'delete'}` - 所有新增的庫及其圖表的清單。 讓我們轉到本文的複雜部分，新增儲存庫。 --- ## 數星星  在「helper」內部建立一個名為「all.stars.ts」的新檔案並新增以下程式碼： ``` import axios from "axios"; import dayjs from "dayjs"; import utc from 'dayjs/plugin/utc'; dayjs.extend(utc); const requestAmount = 20; export const getAllGithubStars = async (owner: string, name: string) => { // Get the amount of stars from GitHub const totalStars = (await axios.get(`https://api.github.com/repos/${owner}/${name}`)).data.stargazers_count; // get total pages const totalPages = Math.ceil(totalStars / 100); // How many pages to skip? We don't want to spam requests const pageSkips = totalPages < requestAmount ? requestAmount : Math.ceil(totalPages / requestAmount); // Send all the requests at the same time const starsDates = (await Promise.all([...new Array(requestAmount)].map(async (_, index) => { const getPage = (index * pageSkips) || 1; return (await axios.get(`https://api.github.com/repos/${owner}/${name}/stargazers?per_page=100&page=${getPage}`, { headers: { Accept: "application/vnd.github.v3.star+json", }, })).data; }))).flatMap(p => p).reduce((acc: any, stars: any) => { const yearMonth = stars.starred_at.split('T')[0]; acc[yearMonth] = (acc[yearMonth] || 0) + 1; return acc; }, {}); // how many stars did we find from a total of `requestAmount` requests? const foundStars = Object.keys(starsDates).reduce((all, current) => all + starsDates[current], 0); // Find the earliest date const lowestMonthYear = Object.keys(starsDates).reduce((lowest, current) => { if (lowest.isAfter(dayjs.utc(current.split('T')[0]))) { return dayjs.utc(current.split('T')[0]); } return lowest; }, dayjs.utc()); // Count dates until today const splitDate = dayjs.utc().diff(lowestMonthYear, 'day') + 1; // Create an array with the amount of stars we didn't find const array = [...new Array(totalStars - foundStars)]; // Set the amount of value to add proportionally for each day let splitStars: any[][] = []; for (let i = splitDate; i > 0; i--) { splitStars.push(array.splice(0, Math.ceil(array.length / i))); } // Calculate the amount of stars for each day return [...new Array(splitDate)].map((_, index, arr) => { const yearMonthDay = lowestMonthYear.add(index, 'day').format('YYYY-MM-DD'); const value = starsDates[yearMonthDay] || 0; return { stars: value + splitStars[index].length, date: { month: +dayjs.utc(yearMonthDay).format('M'), year: +dayjs.utc(yearMonthDay).format('YYYY'), day: +dayjs.utc(yearMonthDay).format('D'), } }; }); } ``` 那麼這裡發生了什麼事： - `totalStars` - 我們計算圖書館擁有的星星總數。 - `totalPages` - 我們計算頁數 **（每頁 100 筆記錄）** - `pageSkips` - 由於我們最多需要 20 個請求，因此我們檢查每次必須跳過多少頁。 - `starsDates` - 我們填充每個日期的星星數量。 - `foundStars` - 由於我們跳過日期，我們需要計算實際找到的星星總數。 - `lowestMonthYear` - 尋找我們擁有的恆星的最早日期。 - `splitDate` - 最早的日期和今天之間有多少個日期？ - `array` - 一個包含 `splitDate` 專案數量的空陣列。 - `splitStars` - 我們缺少的星星數量，需要按比例加入每個日期。 - 最終返回 - 新陣列包含自開始以來每天的星星數量。 所以，我們已經成功建立了一個每天可以給我們星星的函數。 我嘗試過這樣顯示，結果很混亂。 您可能想要顯示每個月的星星數量。 此外，您可能想要累積星星**而不是：** - 二月 - 300 顆星 - 三月 - 200 顆星 - 四月 - 400 顆星 **如果有這樣的就更好了：** - 二月 - 300 顆星 - 三月 - 500 顆星 - 四月 - 900 顆星 兩個選項都有效。 **這取決於你想展示什麼！** 因此，讓我們轉到 helper 資料夾並建立一個名為「get.list.ts」的新檔案。 這是文件的內容： ``` import {prisma} from "./prisma"; import {groupBy, sortBy} from "lodash"; import {Repository} from "@prisma/client"; function fixStars (arr: any[]): Array<{name: string, stars: number, month: number, year: number}> { return arr.map((current, index) => { return { ...current, stars: current.stars + arr.slice(index + 1, arr.length).reduce((acc, current) => acc + current.stars, 0), } }).reverse(); } export const getList = async (data?: Repository[]) => { const repo = data || await prisma.repository.findMany(); const uniqMonth = Object.values( groupBy( sortBy( Object.values( groupBy(repo, (p) => p.name + '-' + p.year + '-' + p.month)) .map(current => { const stars = current.reduce((acc, current) => acc + current.stars, 0); return { name: current[0].name, stars, month: current[0].month, year: current[0].year } }), [(p: any) => -p.year, (p: any) => -p.month] ),p => p.name) ); const fixMonthDesc = uniqMonth.map(p => fixStars(p)); return fixMonthDesc.map(p => ({ name: p[0].name, list: p })); } ``` 首先，它將所有按日的星星轉換為按月的星星。 稍後我們會累積每個月的星星數量。 這裡要注意的一件主要事情是 `data?: Repository[]` 是可選的。 我們制定了一個簡單的邏輯：如果我們不傳遞資料，它將為我們資料庫中的所有儲存庫傳遞資料。 如果我們傳遞資料，它只會對其起作用。 為什麼問？ - 當我們建立一個新的儲存庫時，我們需要在將其新增至資料庫後處理特定的儲存庫資料。 - 當我們重新載入頁面時，我們需要取得所有資料。 現在，讓我們來處理我們的星星建立/刪除路線。 轉到“src/app/api”並建立一個名為“repository”的新資料夾。在該資料夾中，建立一個名為「route.tsx」的新檔案。 在那裡加入以下程式碼： ``` import {getAllGithubStars} from "../../../../helper/all.stars"; import {prisma} from "../../../../helper/prisma"; import {Repository} from "@prisma/client"; import {getList} from "../../../../helper/get.list"; export async function POST(request: Request) { const body = await request.json(); if (!body.repository) { return new Response(JSON.stringify({error: 'Repository is required'}), {status: 400}); } const {owner, name} = body.repository.match(/github.com\/(?<owner>.*)\/(?<name>.*)/).groups; if (!owner || !name) { return new Response(JSON.stringify({error: 'Repository is invalid'}), {status: 400}); } if (body.todo === 'delete') { await prisma.repository.deleteMany({ where: { name: `${owner}/${name}` } }); return new Response(JSON.stringify({deleted: true}), {status: 200}); } const starsMonth = await getAllGithubStars(owner, name); const repo: Repository[] = []; for (const stars of starsMonth) { repo.push( await prisma.repository.upsert({ where: { name_day_month_year: { name: `${owner}/${name}`, month: stars.date.month, year: stars.date.year, day: stars.date.day, }, }, update: { stars: stars.stars, }, create: { name: `${owner}/${name}`, month: stars.date.month, year: stars.date.year, day: stars.date.day, stars: stars.stars, } }) ); } return new Response(JSON.stringify(await getList(repo)), {status: 200}); } ``` 我們共享 DELETE 和 CREATE 路由，這些路由通常不應在生產中使用，但我們在本文中這樣做是為了讓您更輕鬆。 我們從請求中取得 JSON，檢查「repository」欄位是否存在，並且它是 GitHub 儲存庫的有效路徑。 如果是刪除請求，我們使用 prisma 根據儲存庫名稱從資料庫中刪除儲存庫並傳回請求。 如果是建立，我們使用 getAllGithubStars 來獲取資料以保存到我們的資料庫中。 > 💡 由於我們已經在 `name`、`month`、`year` 和 `day` 上放置了唯一索引，如果記錄已經存在，我們可以使用 `prisma` `upsert` 來更新資料 最後，我們將新累積的資料回傳給客戶端。 最困難的部分完成了🍾 --- ## 主頁人口 💽 我們還沒有建立我們的主頁元件。 **我們開始做吧。** 前往“app”資料夾建立或編輯“page.tsx”並新增以下程式碼： ``` "use server"; import Main from "@/components/main"; import {getList} from "../../helper/get.list"; export default async function Home() { const list: any[] = await getList(); return ( <Main list={list} /> ) } ``` 我們使用與 getList 相同的函數來取得累積的所有儲存庫的所有資料。 我們還修改主要元件以支援它。 編輯 `components/main.tsx` 並將其替換為： ``` "use client"; import {useForm} from "react-hook-form"; import axios from "axios"; import {Repository} from "@prisma/client"; import {useCallback, useState} from "react"; interface List { name: string, list: Repository[] } export default function Main({list}: {list: List[]}) { const [repositoryState, setRepositoryState] = useState(list); const {register, handleSubmit} = useForm(); const submit = useCallback(async (data: any) => { const {data: repositoryResponse} = await axios.post('/api/repository', {todo: 'add', repository: data.name}); setRepositoryState([...repositoryState, ...repositoryResponse]); }, [repositoryState]) const deleteFromList = useCallback((val: List) => () => { axios.post('/api/repository', {todo: 'delete', repository: `https://github.com/${val.name}`}); setRepositoryState(repositoryState.filter(v => v.name !== val.name)); }, [repositoryState]) return ( <div className="w-full max-w-2xl mx-auto p-6 space-y-12"> <form className="flex items-center space-x-4" onSubmit={handleSubmit(submit)}> <input className="flex-grow p-3 border border-black/20 rounded-xl" placeholder="Add Git repository" type="text" {...register('name', {required: 'true'})} /> <button className="flex-shrink p-3 border border-black/20 rounded-xl" type="submit"> Add </button> </form> <div className="divide-y-2 divide-gray-300"> {repositoryState.map(val => ( <div key={val.name} className="space-y-4"> <div className="flex justify-between items-center py-10"> <h2 className="text-xl font-bold">{val.name}</h2> <button className="p-3 border border-black/20 rounded-xl bg-red-400" onClick={deleteFromList(val)}>Delete</button> </div> <div className="bg-white rounded-lg border p-10"> <div className="h-[300px]]"> {/* Charts Components */} </div> </div> </div> ))} </div> </div> ) } ``` --- ## 顯示圖表！ 📈 前往“components”資料夾並新增一個名為“chart.tsx”的新檔案。 新增以下程式碼： ``` "use client"; import {Repository} from "@prisma/client"; import {useMemo} from "react"; import React from 'react'; import { Chart as ChartJS, CategoryScale, LinearScale, PointElement, LineElement, Title, Tooltip, Legend, } from 'chart.js'; import { Line } from 'react-chartjs-2'; ChartJS.register( CategoryScale, LinearScale, PointElement, LineElement, Title, Tooltip, Legend ); export default function ChartComponent({repository}: {repository: Repository[]}) { const labels = useMemo(() => { return repository.map(r => `${r.year}/${r.month}`); }, [repository]); const data = useMemo(() => ({ labels, datasets: [ { label: repository[0].name, data: repository.map(p => p.stars), borderColor: 'rgb(255, 99, 132)', backgroundColor: 'rgba(255, 99, 132, 0.5)', tension: 0.2, }, ], }), [repository]); return ( <Line options={{ responsive: true, }} data={data} /> ); } ``` 我們使用“chart.js”函式庫來繪製“Line”類型的圖表。 這非常簡單，因為我們在伺服器端完成了所有資料結構。 這裡需要注意的一件大事是我們「匯出預設值」我們的 ChartComponent。那是因為它使用了「Canvas」。這在伺服器端不可用，我們需要延遲載入該元件。 讓我們修改“main.tsx”： ``` "use client"; import {useForm} from "react-hook-form"; import axios from "axios"; import {Repository} from "@prisma/client"; import dynamic from "next/dynamic"; import {useCallback, useState} from "react"; const ChartComponent = dynamic(() => import('@/components/chart'), { ssr: false, }) interface List { name: string, list: Repository[] } export default function Main({list}: {list: List[]}) { const [repositoryState, setRepositoryState] = useState(list); const {register, handleSubmit} = useForm(); const submit = useCallback(async (data: any) => { const {data: repositoryResponse} = await axios.post('/api/repository', {todo: 'add', repository: data.name}); setRepositoryState([...repositoryState, ...repositoryResponse]); }, [repositoryState]) const deleteFromList = useCallback((val: List) => () => { axios.post('/api/repository', {todo: 'delete', repository: `https://github.com/${val.name}`}); setRepositoryState(repositoryState.filter(v => v.name !== val.name)); }, [repositoryState]) return ( <div className="w-full max-w-2xl mx-auto p-6 space-y-12"> <form className="flex items-center space-x-4" onSubmit={handleSubmit(submit)}> <input className="flex-grow p-3 border border-black/20 rounded-xl" placeholder="Add Git repository" type="text" {...register('name', {required: 'true'})} /> <button className="flex-shrink p-3 border border-black/20 rounded-xl" type="submit"> Add </button> </form> <div className="divide-y-2 divide-gray-300"> {repositoryState.map(val => ( <div key={val.name} className="space-y-4"> <div className="flex justify-between items-center py-10"> <h2 className="text-xl font-bold">{val.name}</h2> <button className="p-3 border border-black/20 rounded-xl bg-red-400" onClick={deleteFromList(val)}>Delete</button> </div> <div className="bg-white rounded-lg border p-10"> <div className="h-[300px]]"> <ChartComponent repository={val.list} /> </div> </div> </div> ))} </div> </div> ) } ``` 您可以看到我們使用“nextjs/dynamic”來延遲載入元件。 我希望將來 NextJS 能為客戶端元件加入類似「使用延遲載入」的內容 😺 --- ## 但是新星呢？來認識一下 Trigger.Dev！ 每天加入新星星的最佳方法是執行 cron 請求來檢查新加入的星星並將其加入到我們的資料庫中。 不要使用 Vercel cron / GitHub 操作，或（上帝禁止）為此建立一個新伺服器。 我們可以使用 [Trigger.DEV](http://Trigger.DEV) 直接與我們的 NextJS 應用程式搭配使用。 那麼就讓我們來設定一下吧！ 註冊 [Trigger.dev 帳號](https://trigger.dev/)。 註冊後，建立一個組織並為您的工作選擇一個專案名稱。  選擇 Next.js 作為您的框架，並按照將 Trigger.dev 新增至現有 Next.js 專案的流程進行操作。  否則，請點選專案儀表板側邊欄選單上的「環境和 API 金鑰」。  複製您的 DEV 伺服器 API 金鑰並執行下面的程式碼片段以安裝 Trigger.dev。 仔細按照說明進行操作。 ``` npx @trigger.dev/cli@latest init ``` 在另一個終端中執行以下程式碼片段，在 Trigger.dev 和您的 Next.js 專案之間建立隧道。 ``` npx @trigger.dev/cli@latest dev ``` 讓我們建立 TriggerDev 作業！ 您將看到一個新建立的資料夾，名為“jobs”。 在那裡建立一個名為“sync.stars.ts”的新文件 新增以下程式碼： ``` import { cronTrigger, invokeTrigger } from "@trigger.dev/sdk"; import { client } from "@/trigger"; import { prisma } from "../../helper/prisma"; import axios from "axios"; import { z } from "zod"; // Your first job // This Job will be triggered by an event, log a joke to the console, and then wait 5 seconds before logging the punchline. client.defineJob({ id: "sync-stars", name: "Sync Stars Daily", version: "0.0.1", // Run a cron every day at 23:00 AM trigger: cronTrigger({ cron: "0 23 * * *", }), run: async (payload, io, ctx) => { const repos = await io.runTask("get-stars", async () => { // get all libraries and current amount of stars return await prisma.repository.groupBy({ by: ["name"], _sum: { stars: true, }, }); }); //loop through all repos and invoke the Job that gets the latest stars for (const repo of repos) { getStars.invoke(repo.name, { name: repo.name, previousStarCount: repo?._sum?.stars || 0, }); } }, }); const getStars = client.defineJob({ id: "get-latest-stars", name: "Get latest stars", version: "0.0.1", // Run a cron every day at 23:00 AM trigger: invokeTrigger({ schema: z.object({ name: z.string(), previousStarCount: z.number(), }), }), run: async (payload, io, ctx) => { const stargazers_count = await io.runTask("get-stars", async () => { const { data } = await axios.get( `https://api.github.com/repos/${payload.name}`, { headers: { authorization: `token ${process.env.TOKEN}`, }, } ); return data.stargazers_count as number; }); await prisma.repository.upsert({ where: { name_day_month_year: { name: payload.name, month: new Date().getMonth() + 1, year: new Date().getFullYear(), day: new Date().getDate(), }, }, update: { stars: stargazers_count - payload.previousStarCount, }, create: { name: payload.name, stars: stargazers_count - payload.previousStarCount, month: new Date().getMonth() + 1, year: new Date().getFullYear(), day: new Date().getDate(), }, }); }, }); ``` 我們建立了一個名為“Sync Stars Daily”的新作業，該作業將在每天下午 23:00 執行 - 它在 cron 文本中的表示為：`0 23 * * *` 我們在資料庫中取得所有目前儲存庫，按名稱將它們分組，並對星星進行求和。 由於一切都在 Vercel 無伺服器上執行，因此我們可能會在檢查所有儲存庫時遇到逾時。 為此，我們將每個儲存庫傳送到不同的作業。 我們使用“invoke”建立新作業，然後在“獲取最新的星星”中處理它們 我們迭代所有新儲存庫並獲取當前的星星數量。 我們用舊的星星數量去除新的星星數量，得到今天的星星數量。 我們使用“prisma”將其新增至資料庫。沒有比這更簡單的了！ 最後一件事是編輯“jobs/index.ts”並將內容替換為： ``` export * from "./sync.stars"; ``` 你就完成了🥳 --- ## 讓我們聯絡吧！ 🔌 作為開源開發者，我們邀請您加入我們的[社群](https://discord.gg/nkqV9xBYWy)，以做出貢獻並與維護者互動。請隨時造訪我們的 [GitHub 儲存庫](https://github.com/triggerdotdev/trigger.dev)，貢獻並建立與 Trigger.dev 相關的問題。 本教學的源程式碼可在此處取得： [https://github.com/triggerdotdev/blog/tree/main/stars-monitor](https://github.com/triggerdotdev/blog/tree/main/stars-monitor) 感謝您的閱讀！ --- 原文出處：https://dev.to/triggerdotdev/take-nextjs-to-the-next-level-create-a-github-stars-monitor-130a
您是否想過如何使用 python 測試您的 API？在本文中，我們將學習如何使用 Python 和 pytest 框架來測試我們的 API。 對於本教程，您需要安裝 python，您可以在[此處](https://www.python.org/downloads/)下載它 --- ### 簡介： - [什麼是 Python 和 Pytest 框架](#what-is-python-and-pytest-framework) - [我們專案的設定](#configuration-of-our-project) - [使用python建立虛擬環境](#creation-of-virtual-environment-with-python) - [測試的依賴關係設定](#setup-of-dependency-for-the-tests) - [建立我們的第一個測試](#creating-our-first-test) - [將被測試的 API 的定義](#definition-of-the-api-that-will-be-tested) - [建立我們的測試](#creating-our-test) - [重建我們的測試](#refactoring-our-tests) - [產生 html 報告結果](#generate-html-report-result) - [結論](#conclusion) --- ## 什麼是 Python 和 Pytest 框架 「Python」是一種高級通用程式語言，以其簡單性和可讀性而聞名。它由 Guido van Rossum 建立，於 1991 年首次發布。 Python 的設計易於學習，並且具有乾淨簡潔的語法，這使其成為初學者和經驗豐富的程式設計師的流行選擇。 「pytest」框架可以輕鬆編寫小型、可讀的測試，並且可以擴展以支援應用程式和程式庫的複雜功能測試。 --- ## 我們專案的配置 ### 用python建立虛擬環境 在開始建立之前，我們先來了解一下什麼是Python上的虛擬環境。 Python 中的虛擬環境是一個獨立的目錄或資料夾，可讓您為專案建立和管理隔離的 Python 環境。透過環境，您可以輕鬆管理依賴項，避免與不同版本的 python 發生衝突。 虛擬環境（除其他外）是： - 用於包含支援專案（庫或應用程式）所需的特定 Python 解釋器以及軟體庫和二進位檔案。預設情況下，它們與其他虛擬環境中的軟體以及作業系統中安裝的 Python 解釋器和庫隔離。 - 包含在專案目錄中的目錄中，通常名為“venv”或“.venv”，或在許多虛擬環境的容器目錄下，例如“~/.virtualenvs”。 - 未簽入原始碼控制系統（例如 Git）。 - 被認為是一次性的 - 應該很容易刪除並從頭開始重新建立它。您沒有在環境中放置任何專案程式碼 - 不被視為可移動或可複製 - 您只需在目標位置重新建立相同的環境。 您可以在[此處](https://docs.python.org/3/library/venv.html#venv-def)閱讀有關 python 環境的更多資訊。 #### 視窗 首先，為您的專案建立一個資料夾，然後打開 cmd 並使用命令 cd 導航到該資料夾： ``` cd tests_with_python ``` 如果您不知道資料夾在哪裡，可以執行命令“ls”，您將看到資料夾列表，並且可以瀏覽它們。在我們的專案資料夾中，執行以下命令： ``` python -m venv name_of_environment ``` 您的環境名稱可以是任何人，只需記住python 區分大小寫，請查看[PEP 8 風格指南](https://peps.python.org/pep-0008/) 以了解有關Python 約定的更多資訊. 要啟動我們的環境，我們使用以下命令： ``` name_of_environment\Scripts\Activate ``` 如果一切正確，您的環境將被激活，並且在 cmd 上您將看到如下所示： ``` (name_of_environment) C:\User\tests ``` 要停用您的環境，只需執行： ``` deactivate ``` #### Linux 或 MacOS 為您的專案建立一個資料夾，然後打開 cmd 並使用命令 cd 導航到該資料夾： ``` cd tests_with_python ``` 要啟動我們的環境，我們使用以下命令： ``` source name_of_environment/bin/activate ``` 如果一切正確，您的環境將被激活，並且在 cmd 上您將看到如下所示： ``` (name_of_environment) your_user_name tests % ``` 要停用您的環境，只需執行： ``` deactivate ``` ### 設定測試的依賴關係 當我們要測試 API 時，我們需要安裝依賴項來幫助我們進行測試，首先我們將安裝「requests」函式庫來幫助我們發出請求： PS：在執行此命令之前請確保您的環境已激活 ``` pip install requests ``` 為了進行測試，我們將安裝「pytests」框架： ``` pip install pytest ``` --- ## 建立我們的第一個測試 ### 將要測試的 API 的定義 在本教程中，我們將使用返回小行星列表的 Nasa API：[Asteroids - NeoWs](https://api.nasa.gov/#donkiGST)，我們將測試檢索基於小行星列表的端點在他們最接近地球的日期。 關於API： - 基本網址：`https://api.nasa.gov/neo/rest/v1/feed` - 查詢參數： |參數|類型|預設|描述| | --------|---------|--------|--------------------| |start_date|YYYY-MM-DD|無|小行星搜尋的開始日期| |end_date|YYYY-MM-DD|start_date後7天|小行星搜尋的結束日期| |api_key|字串|DEMO_KEY|用於擴展用途的 api.nasa.gov 密鑰| 在本教程中，我們將重點放在三種類型的測試： - 合約：如果 API 能夠驗證傳送的查詢參數 - 狀態：狀態程式碼是否正確 - 身份驗證：即使這個API不需要令牌，我們也可以用它來做測試 我們的場景： |方法|測試|預期結果 | | --------|--------|--------------------| |獲取 |搜尋成功 | - 傳回狀態程式碼 200<br/> 正文回應包含小行星清單| |獲取 |無需任何查詢參數即可搜尋 | - 返回狀態碼403<br/>| |獲取 |僅搜尋開始日期| - 傳回狀態程式碼 200 <br/> 主體回應包含小行星清單| |獲取 |僅搜尋結束日期| - 傳回狀態程式碼 200 <br/> 主體回應包含小行星清單| |獲取 |在有效日期範圍內搜尋| - 傳回狀態碼 200<br/> - 正文回應包含所有非空白欄位| |獲取 |當開始日期大於結束日期時進行搜尋| - 傳回狀態程式碼 400 <br/>| |獲取 |使用無效的 API 令牌進行搜尋| - 傳回狀態程式碼 403 <br/> 主體回應包含小行星清單| ### 建立我們的測試 首先，我們將建立一個名為「tests.py」的文件，我們將在該文件中編寫測試。為了幫助我們使用良好的實踐並編寫良好的自動化測試，讓我們使用 [TDD（測試驅動開發）](https://www.browserstack.com/guide/what-is-test-driven-development?psafe_param=1?keyword=&campaignid=&adgroupid=&adid=8784011037660164696&utm_source=google&utm_medium=cpc&utm_platform=paidads&utm_content=602353912717&utm_campapaidads&utm_content=602353912717&utm_campa.utm_term=+&gad_source=1&gclid=CjwKCAiAxreqBhAxEiwAfGfndN8P705lwnkvEFnCz_lueR2hnhmZXgboBQEtKTaCIRbhcb1SXOxBYhoC-WoQAD_BwwE)技術。 該技術包括： - 紅色 - 進行失敗的測試 - 綠色 - 使此測試通過 - 重構 - 重構所做的事情，刪除重複的內容 為了編寫一套好的測試，我們將使用 3A 技術： - 安排：準備上下文。 - 行動：執行我們想要示範的行動。 - 斷言：表明我們預期的結果確實發生了。 從紅色開始，使用 3A 技術，我們將編寫第一個測試「成功搜尋小行星」： ``` import pytest def test_search_asteroids_with_sucess(): # Arrange: api_key = "DEMO_KEY" #Act: response = make_request(api_key) #Assertion: assert response.status_code == 200 # Validation of status code data = response.json() # Assertion of body response content: assert len(data) > 0 assert data["element_count"] > 0 ``` - 安排：我們建立一個變數來插入 api_key，在此步驟中，您可以插入執行測試所需的任何資料。通常，在這一步驟我們會建立模擬資料。 - Act：在這一步驟中我們呼叫了負責發出請求的方法 - 斷言：我們驗證回應 `方法或類別的名稱應以 test 開頭` 若要執行我們的測試，請在命令提示字元中執行： ``` pytest test.py ``` 我們將收到一個錯誤，因為我們沒有建立執行請求的方法： ``` test.py F [100%] ====================================================================== FAILURES ====================================================================== _________________________________________________________ test_search_asteroids_with_sucess __________________________________________________________ def test_search_asteroids_with_sucess(): > response = make_request() E NameError: name 'make_request' is not defined test.py:5: NameError ============================================================== short test summary info =============================================================== FAILED test.py::test_search_asteroids_with_sucess - NameError: name 'make_request' is not defined ================================================================= 1 failed in 0.01s ================================================================== ``` 現在，讓我們建立方法來執行請求： ``` import requests def make_request(api_key): base_url = "https://api.nasa.gov/neo/rest/v1/feed/" response = requests.get(f'{base_url}?api_key={api_key}') return response ``` 現在，再次執行我們的測試： ``` ================================================================ test session starts ================================================================= platform darwin -- Python 3.11.5, pytest-7.4.3, pluggy-1.3.0 rootdir: /Users/Documents/tests_python collected 1 item test.py . [100%] ================================================================= 1 passed in 20.22s ================================================================= ``` --- ## 重構我們的測試 現在我們已經了解如何使用 pytest 建立測試以及如何建立請求，我們可以編寫其他測試並開始重構測試。我們要做的第一個重構是從測試文件中刪除請求方法。我們將建立一個名為「make_requests.py」的新文件，其中將包含我們的請求，並將我們所做的請求移至此文件： ``` import requests def make_request(api_key): base_url = "https://api.nasa.gov/neo/rest/v1/feed/" response = requests.get(f'{base_url}?api_key={api_key}') return response ``` 現在，我們需要考慮在其他測試中重複使用此方法，因為我們需要為不同的測試傳遞不同的參數。我們可以透過很多方法來做到這一點，在本教程中，我們將參數的名稱從“api_key”更改為“query_parameters”。我們這樣做是為了讓我們的方法更加靈活，我們可以一次傳遞參數進行測試： ``` import requests def make_request(query_parameters): base_url = "https://api.nasa.gov/neo/rest/v1/feed/" response = requests.get(f'{base_url}?{query_parameters}') return response ``` 之後，我們需要更改我們的測試文件。我們將導入我們建立的這個方法： ``` from make_requests import make_request ``` 為了以更好的方式組織我們的測試，並遵循 pytest 文件的建議，我們將測試移至類別「TestClass」： 再次執行我們的測試： ``` ============================= test session starts ============================== collecting ... collected 7 items test.py::TestClass::test_search_asteroids_with_sucess test.py::TestClass::test_search_asteroids_with_query_parameters_empty test.py::TestClass::test_search_asteroids_with_start_date test.py::TestClass::test_search_asteroids_with_end_date test.py::TestClass::test_search_asteroids_in_valid_range test.py::TestClass::test_search_asteroids_in_invalid_range test.py::TestClass::test_search_asteroids_in_invalid_token ============================== 7 passed in 5.85s =============================== PASSED [ 14%]PASSED [ 28%]PASSED [ 42%]PASSED [ 57%]PASSED [ 71%]PASSED [ 85%]PASSED [100%] Process finished with exit code 0 ``` ### 產生 html 報告結果 為了更好地視覺化您的測試結果，我們可以使用 pytest-html-reporter 庫產生報告 html，為此，我們首先需要安裝該套件： ``` pip install pytest-html ``` 若要產生報告，請在執行測試時新增： ``` pytest test.py --html-report=./report/report.html ``` 將產生一個包含測試結果的 .html 文件，如下所示：  ## 結論 本文是一篇教程，介紹如何開始使用 python 和 pytest 框架為 API 編寫自動化測試以及如何產生一個報告 html。 您可以在[此處](https://github.com/aliciamarianne1507/tests_python)存取本教學中使用的專案。 我希望這些內容對您有用。 如果您有任何疑問，請隨時與我聯繫！ 親親，下週見💅🏼 --- 原文出處：https://dev.to/m4rri4nne/automating-your-api-tests-using-python-and-pytest-23cc
原文出處：https://dev.to/lofiandcode/git-and-github-how-to-revert-a-single-file-dha ##介紹 一旦您開始與其他開發人員合作，了解如何將單一檔案還原到某個提交就變得很重要。出現這種需求是因為您有時需要更改與拉取請求無關的文件以測試您正在開發的功能。但是，手動將這些文件中的每一行程式碼變更回原始狀態並進行新的提交可能會導致提交歷史記錄混亂。恢復檔案是一種更清晰的處理方式。 ##找到提交ID 首先，您需要前往 GitHub 上的共用儲存庫並找到要復原的檔案。導航到該文件後，您應該在文件上方看到以下內容：  在右側，您可以看到 7 位數的提交 ID 和日期。這是修改該文件的最近一次提交的提交 ID。記下此提交 ID，或將其複製到剪貼簿。 ##找到檔案路徑 接下來您需要的是工作目錄中的檔案路徑。這部分很簡單，因為文件的路徑位於您找到文件的提交 ID 的相同 GitHub 畫面上。  在上面您可以看到與之前相同的螢幕截圖，但這次我在文件路徑下劃線了。請注意，我只在路徑的一部分下劃線了。列出的第一個目錄是工作目錄名稱，並且將是您使用此檔案路徑時所在的目錄。因此，您只需要下劃線部分。 ##恢復檔案。 剩下的就是恢復檔案了。打開終端並變更為工作目錄後，您可以使用“git checkout”來還原檔案。 git 指令的格式如下圖所示： `git checkout [提交 ID] -- 路徑/到/檔案` 如果我要恢復上面螢幕截圖中的文件，則將如下所示：  ##提交更改 我知道你在想什麼，“等一下，我認為重點是不建立新的提交？”嗯，這說對了一半。我們不想對我們恢復的文件進行新的提交。但是一旦我們恢復文件，我們就需要提交該更改。在這種情況下，更改是單一檔案的恢復。這是使用標準提交命令完成的： `git commit -m '提交訊息'` 然後，您可以將該提交推送到遠端，以便 GitHub 上的分支版本與您的本機版本相符。 ##總結 若要將單一檔案還原至特定版本，請執行下列操作： * 尋找要還原到的檔案版本的提交 ID。 * 找到要從工作目錄復原的檔案的路徑。 * 在終端機中，將目錄變更為工作目錄。 * 輸入 `git checkout [commit ID] -- path/to/file` 並按 Enter 鍵。 * 將更改提交到恢復的文件。 ##參考 [封面圖片](https://ih0.redbubble.net/image.591029586.5228/flat,550x550,075,f.jpg) [如何將檔案重設或還原到特定版本？ - Stackoverflow](https://stackoverflow.com/questions/215718/how-can-i-reset-or-revert-a-file-to-a-specific-revision)
原文出處：https://dev.to/turculaurentiu91/why-you-should-choose-htmx-for-your-next-project-o7j 在本文中，我們將旨在了解為什麼您下次為 Web 應用程式選擇技術堆疊時應該考慮 HTMX 作為 React 的替代品。我們將研究傳統 HTTP JSON API + React 帶來的複雜性和挑戰，以及如何透過使用 HTMX 輕鬆避免它們。 **注意**：在本文中，我將討論 React，但它可以替換為任何其他前端框架，如 Angular、Vue、Svelte 或 Solid，但我談論 React 是因為它是大多數 Web 的預設技術開發人員預設為。 ### HTMX 到底是什麼 如果您還不知道，[HTMX](https://htmx.org/) 是一個小型瀏覽器 (JS) 庫，它使用一些屬性擴展了 HTML，允許您使用來自伺服器。它還使 HTML 能夠對所有動詞發出 HTTP 請求，而不僅僅是 GET 和 POST。 ## React 解決了什麼問題 React 是一個 JavaScript 程式庫，可協助您透過保持使用者介面與狀態同步來編寫高度互動的應用程式。您告訴它如何渲染給定的狀態，每次更新狀態時，它都會重新渲染（盡可能有效率）UI 以反映狀態變更。 每次狀態發生變化時，您都會通知庫它發生了變化，並提供新的狀態，它將處理 UI 更新。 需要本地記憶體狀態的高互動應用程式的範例可以是您可以在網路上找到的各種文字編輯器（VSCode）之一、拖放看板（如 Trello 或 JIRA）、視訊播放器或聊天室。 什麼不是此類應用程式的範例？您正在建立的待辦事項清單、您正在閱讀的新聞網站、您發布的部落格以及周圍的大多數網站。如果我們看一下 [80/20 規則](https://en.wikipedia.org/wiki/Pareto_principle) >80% 的結果來自 20% 的原因，80% 的結果來自 20% 的努力。 你可以說 80% 使用 React 的 Web 應用程式不需要本地狀態。對於那 20% 需要它的人來說，你可以說它只是應用程式的一小部分（大約 20%），其餘部分只能用 HTML 來表達。 **這些數字是編造的，我沒有任何研究來支持這一點** ## React 也解決了哪些問題，使其被現代網站廣泛採用 HTML 已經過時了。使用 HTML 製作應用程式的舊方法涉及頁面、連結和表單的集合，這些頁面、連結和表單向使用者描述給定資源的當前狀態以及他們可以執行哪些操作來更改它。 每次使用者與資源互動時，應用程式只能重新載入整個頁面以顯示資源的新狀態。 幾年後，FaceBook 推出了 React，這是一個 JS 程式庫，可讓開發人員建立單頁應用程式 (SPA)。導航時不再需要重新加載整個頁面，狀態更新的酷過渡、對用戶的有趣反饋以及其他使 Web 開發人員在其網站中採用 SPA 框架的細節。 ## 複雜性問題  如果你不理解上面的架構，不用擔心，沒有什麼好理解的。我要求 ChantGPT 為我生成它，由於它過於複雜且沒有任何意義，它完美地反映了現代 Web 應用程式目前的預設基礎架構。 一個很酷的程式設計原則是**KISS**，它代表“保持簡單，愚蠢”，或者有些人可能喜歡開玩笑，“保持簡單，愚蠢！” 現代開發人員預設建立 Web 應用程式的當前基礎設施和技術堆疊極其複雜，做了很多不必要的事情，只是因為它很酷！ 當您自己建立第一個 POC 時，效果很好，但下一刻您加入了更多團隊成員，並且使用多次迭代和「擁抱」更改的敏捷方式，它有點崩潰，原因是我們將往下看一下。 ## 傳統 HTTP JSON API + React 的狀態管理問題 在 Web 應用程式中，您經常要做的就是從資料庫中獲取資源的狀態並將其呈現給使用者。讓我們以任務管理應用程式為例。使用者有一個任務列表，每個任務都有一個狀態： - 任務的標題 - 說明 - 任務完成時的標誌 - 截止日期（可選） 我們通常將此狀態儲存在資料庫中，並將此資訊呈現給用戶，您必須： - 從使用者有權存取的資料庫中取得所有任務。 - 可以選擇轉換資料（也許您儲存完成的日期並從中計算「is_completed」標誌）。 - 將資料序列化為 JSON。 - 透過 HTTP 請求取得資料。 - （可選但通常）根據模式驗證資料，可能使用 YUP 或 ZOD。 - 使用 Redux、Zustand、react-query 或其他狀態管理庫將 JSON 轉換為狀態並將其儲存在快取中。 - 轉換 HTML 中的狀態，通常會決定使用者可以使用資料做什麼。 簡而言之，我們正在描述如何在 JavaScript 中渲染所有資源的所有可能狀態，在瀏覽器中下載所述 JavaScript，然後 JavaScript 下載一堆 JSON 格式的資料並將其渲染（如果它知道如何）瀏覽器顯示為HTML！ 向使用者顯示任務清單需要做大量工作，特別是當任務僅在使用者變更時才更改時，應用程式必須將應用程式置於載入狀態，發出另一個 HTTP 請求（以PUT 或PATCH 或DELETE）使快取值（狀態）無效並重新獲取它以顯示更改的任務。 或者更糟的是，當用戶更改某些任務時，樂觀地更新本地狀態並立即顯示更改，並在幕後執行更新請求，僅在他們成功更新後通知用戶更新失敗。 這是非常容易出錯的。對於這個待辦事項應用程式來說，它可能會很有效，因為您是唯一的開發人員，並且該應用程式足夠大，您可以在腦海中保留正在發生的所有事情的地圖。但是當你的團隊規模更大時，尤其是當你將團隊分成前端和後端時，溝通不良可能會導致很多問題。 後端可能使用“is_completed”標誌，而前端可能需要“is_active”標誌。後端可能會將經過 Markdown 處理的「描述」傳送到 HTML，而前端可能希望它不被處理。後端可能會將“描述”設為可選，以允許使用者在前端不同步時保存草稿，並且您會看到許多“未捕獲的類型錯誤：無法讀取未定義的屬性（讀取“toLowerCase” ）” 另一方面，在 HTMX 上，您可以直接在範本上呈現 HTML，只要後端語言允許，就可以確保類型安全。您僅向瀏覽器發送相關訊息，向使用者提供對資源的適當控制，並指示瀏覽器或 HTMX 如何解釋使用者操作以及後端對這些操作的回應。所有應用程式狀態都是 HTML，這個概念稱為 [HATEOAS](https://htmx.org/essays/hateoas/) ## 傳統 HTTP JSON API + React 對文件的需求 為了讓兩個團隊（後端和前端）獨立工作並透過 HTTP JSON API 進行通信，您需要擁有適當的 API 文件。您還需要記錄如何計算使用者可以對給定資源執行哪些操作以顯示控制項。 大多數此類文件寫起來都很痛苦，特別是因為通常需要在實作之前編寫，而開發人員尚未完全理解問題的範圍，因此前端可以並行開發。這通常會在開發過程中進行許多更新，以適應開發過程中出現的問題，並可能導致團隊之間的版本不一致。 您還需要對 API 進行版本控制，並注意不要在非主要版本變更中引入重大變更。您無法再在不變更主要版本的情況下變更欄位名稱。您還需要保持 API 的多個版本運作或強制前端團隊進行調整。 大多數時候，文件已經過時了。有些必須緊急修復，有些新要求是在發布前一天提出的，現在您的文件已經過時，即使在很短的時間內。而且您必須記住更新它，或者更糟的是，您建立了一張票來記住它，而其他人拿起它，但沒有完整的圖片並記錄了錯誤！ ## 重複的邏輯問題 對於每個資源，您必須實施授權策略。您必須確定目前使用者是否可以將任務 **46234** 標記為已完成。您必須在後端程式碼的某個位置編寫此檢查。否則，您的應用程式將開放給_不安全的直接物件參考_，或任何使用 Postman 的人都可以將您的任務標記為已完成。 您還必須在前端實現相同的邏輯，僅當用戶有權標記已完成時才顯示標記按鈕（讓我們假設您可以與其他用戶共享您的任務，但只有您可以更改它們）。 現在每次這個邏輯改變時，你都必須在兩個應用程式中實作它，並同時發布它或擁有多個版本的API。 ## 效能問題 為了使用 React 在瀏覽器中呈現網站，您需要將佔用大量內存和解析/處理影響的 React 程式碼、狀態管理庫程式碼、腳趾 UI 庫程式碼、CSS-IN- 捆綁在一起。JS 庫程式碼、應用程式程式碼以及我們透過NPM 安裝和使用的任何js 程式庫（我們並不羞於安裝新套件，請參閱[leftpad 問題](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/))。這通常會導致透過網路傳送大塊的 JavaScript 資源。當然，您可以在瀏覽器中緩存，但在現代敏捷開發中，每個衝刺至少部署一次，因此這無法解決任何問題。這會消耗網路流量和電池，這對行動裝置來說是一個經常被忽視的問題。 上述JavaScript需要由瀏覽器來解釋，消耗處理能力和電池。 JavaScript，尤其是 ReactDOM，需要追蹤 DOM 的鏡像。在其之上加入普通 DOM 和本地狀態緩存，以及所有渲染函數，以及所有“useMemo”、“useCallback”和“useState”。也要加入需要在記憶體中保存所有上下文變數的所有閉包。 JavaScript 引擎並不以其記憶體效率而聞名！您會聽到人們抱怨瀏覽器消耗了多少內存，但他們低估了他們存取的網站所消耗的內存量。 所有這些加起來，最終會耗盡用戶的電池和記憶體。當然，您可以付出努力並優化所有這些，或使用其他程式庫（如 Svelte），但所有這些努力都可以用於為您的用戶提供更有意義的功能。 ## 服務端渲染的需要 近年來，我們播種了伺服器端渲染專用框架（如「Next.js」）的興起。它們的流行凸顯了對以 HTML 格式交付內容的需求，特別是出於可存取性優化、效能和搜尋引擎優化的原因。 你不想等待瀏覽器下載 JavaScript 來渲染頁面，然後等待 JavaScript 發出 HTTP 請求來獲取內容然後渲染它，你希望它立即渲染，特別是對於上面的情況折疊內容。 這又增加了一層複雜性，包括： - 基礎設施，現在您還需要另一台伺服器用於前端應用程式 - 程式碼更複雜，包括什麼程式碼在伺服器上執行以及什麼在瀏覽器上執行的思維導圖 - 部署管道現在更加複雜 - 測試基礎設施現在更加複雜 - 現在解決問題變得更加困難，您需要了解問題是在瀏覽器上、在客戶端應用程式伺服器上還是在 API 伺服器上 ## 解決這些問題 Web 開發社群各自使用自己的語言或開發技術，以不同的方式解決這些問題： - Next.js（以及 Nuxt 等） - 反應伺服器元件 - 拉維爾 - 慣性.JS - 活線 - 點網 - Blazor 頁面 - 靈藥 - 鳳凰即時查看 - 鐵鏽 - 樂浦伺服器功能 還有許多我忘記或從未聽說過的其他解決方案！ 無論如何，此類解決方案的存在和流行證明了這些問題是有效的並且在 Web 開發人員的日常生活中遇到過。否則他們不會不遺餘力地解決這些問題，尤其是以開源的方式！ 還有 [Turbo](https://turbo.hotwired.dev/) 以及採用它們的框架、Ruby on Rails、PHP Symphony 以及其他可能以與 HTMX 相同的方式解決相同問題的框架。選擇 HTMX 只是個人喜好，但你絕對應該了解這一點，這和 HTMX 一樣酷！ 在所有這些中，HTMX 脫穎而出，不僅因為它不會將您鎖定到特定技術，您可以透過對模板進行微小更改來從 PHP 切換到 Rust，而且還因為它完全消除了對有狀態元件的需求，或者需要追蹤與資源無關的應用程式的某種狀態。 例如，讓我們採用確認對話方塊模式。您通常最終要做的是，您有一個本地記憶體狀態（如果它是開啟的），並根據該狀態將其顯示給使用者。在 HTMX 中，狀態 **IS THE HTML** 意味著當您按一下開啟模式時，您 **GET** `tasks/{taskId}/confirm-delete` 並將回應 HTML 嵌入到 DOM 中。當它被刪除時，您就完全刪除了模式和任務！這以一種獨特且極其簡單的方式解決了上述所有問題，您不需要： - 追蹤狀態 - 知道如何渲染對話框 - 記錄API - 檢查使用者是否可以刪除任務（在前端） - 您的後端應用程式始終負責 - 您可以獲得更好的安全性，因為您不會向瀏覽器發送不相關的資料並竊取敏感資訊 - 你會得到更好的表現 __*最重要的是，您可以讓您的應用程式保持簡單，只有在解決使用者問題時才允許複雜性！*__ 您只需指示 HTMX 從何處獲取對話框以及將其放置在何處，一切就完成了！ ``` <!-- the delete button --> @if ($chirp->user->is(auth()->user())) <form> @csrf @method('delete') <x-dropdown-link :component="'button'" type="submit" hx-get="{{ route('chirps.confirm-destroy', $chirp) }}" hx-swap="beforeend" hx-target="closest .chirp" > {{ __('Delete') }} </x-dropdown-link> </form> @endif <!-- the dialog template --> <div class="modal fixed z-10 inset-0 overflow-y-auto flex justify-center items-center bg-black bg-opacity-50" style="backdrop-filter: blur(14px);"> <div class="bg-white rounded p-6"> <h2 class="text-xl border-b pb-2 mb-2">Confirm Action</h2> <p>Are you sure you want to delete this chirp?</p> <div class="flex justify-end mt-4 gap-4"> <x-secondary-button _="on click remove closest .modal" > Cancel </x-secondary-button> <form> @csrf <x-danger-button hx-delete="{{route('chirps.destroy', $chirp)}}" hx-target="closest .chirp" hx-swap="delete"> Delete </x-danger-button> </form> </div> </div> </div> ``` _這個範例來自我的 [HTMX with Laravel] 教學（https://dev.to/turculaurentiu91/laravel-htmx--g0n) ，請看！_ 就像這樣，當我們單擊刪除按鈕時，我們指示 HTMX 對 `chirps/{chirp}/confirm-destroy` 執行 **GET** 請求，並將結果 HTML 放在最接近的父級 `< 之前div class="chirp">` 結束（在底部）。在刪除對話方塊中，當使用者確認時，我們指示 HTMX 對 `chirps/{chirp}` 端點執行 **DELETE** 請求，成功後，我們刪除具有 `chirp` 類別的最接近的父級。 ## 結論 在不斷發展的 Web 開發領域，看到 HTMX 等倡導簡單性和回歸基礎的工具令人耳目一新。透過利用 HTML 和 HTTP 的強大功能，HTMX 允許開發人員建立動態 Web 應用程式，而無需傳統 JavaScript 框架的複雜性和開銷。 因此，下次您開始新專案或考慮重構現有專案時，請嘗試 HTMX。您可能會驚訝於用這麼少的錢就能取得如此大的成就。
原文出處：https://dev.to/nathan_tarbert/7-repositories-that-will-make-you-90-smarter-2jb3 在熙熙攘攘的科技世界中，人們很容易陷入大牌明星的炒作之中。 不要讓公司的規模欺騙了你。一些最具創新性和影響力的技術來自較小的公司或新創公司  這裡有七家這樣的新創公司，每家都擁有獨特的產品，可以改變您的專案，並在此過程中讓您變得更聰明： ___ ## [1] [BoxyHQ](https://github.com/boxyhq/jackson) [](https://github.com/boxyhq/jackson) BoxyHQ 擁有一套用於安全和隱私的 API，旨在幫助工程團隊更快地建立和發布合規的雲端應用程式。 它提供企業 SSO、目錄同步、審核日誌和用於保護敏感資料的隱私庫等功能。 如果您是一家企業或正在建立新的 SaaS 應用程式，BoxyHQ 可能會成為遊戲規則的改變者，從頭開始確保安全性和合規性。 - 管理應用程式中的使用者身份驗證 - 確保用戶註冊和登入安全且合規 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/boxyhq/jackson ___ ## [2] [Cal.com](https://github.com/calcom/cal.com) [](https://github.com/calcom/cal.com) Cal.com 是一款高效的日程安排工具，旨在消除安排會議的麻煩，有效消除冗長的電子郵件交流的需要。 如果您的專案涉及安排團隊會議或管理約會，Cal.com 可以簡化您的日程安排流程，最終節省您寶貴的時間。 - 直接在您的應用程式中輕鬆安排會議或約會 - 有效安排團隊會議、專案里程碑和截止日期 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/calcom/cal.com ___ ## [3] [Flagsmith](https://www.flagsmith.com/) [](https://www.flagsmith.com/) Flagsmith 是一個功能標誌管理平台，可讓您控制發布應用程式功能的方式。 您可以使用功能標誌的安全網解耦部署和發布並將程式碼推送到生產環境。 _這些策略在複雜的專案場景中非常有益，可以實現更有效率的開發和更順利的推出：_ - 逐步發布和測試功能的不同版本 - 在全面部署之前評估並完善多個功能版本 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/Flagsmith/flagsmith ___ ## [4] [配音](https://github.com/steven-tey/dub) [](https://github.com/steven-tey/dub) Dub 是一款多功能開源連結縮短器和管理工具，專為當今充滿活力的行銷團隊精心打造。 該平台使用戶能夠無縫生成、分發和監控縮短的連結。 - 利用您自己的自訂網域自訂您的連結，讓您保持品牌一致性 - 簡化連結管理，確保高效率、有效的行銷活動 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/steven-tey/dub --- ## [5] [Formbricks](https://github.com/formbricks/formbricks) [](https://github.com/formbricks/formbricks) Formbricks 是您實施產品內微觀調查的終極資源，這將徹底改變您的產品體驗。 這些不引人注目的調查是收集用戶見解和增強應用程式功能的強大工具。 豐富您產品的使用者體驗，並為應用程式開發做出基於資料的決策。 - 利用微觀調查在正確的時間精確地接觸到正確的用戶，提高用戶參與度和滿意度，而不會讓他們被煩人的調查淹沒 - 直接在您的應用程式中輕鬆收集有價值的調查資料，簡化收集用戶回饋並發現改進機會的過程 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/formbricks/formbricks ___ ## [6] [漩渦](https://github.com/swirlai/swirl-search) [](https://github.com/swirlai/swirl-search) Swirl 是一個開源搜尋平台，可以同時搜尋多個內容來源並返回人工智慧排名的結果。 您也可以使用生成式 AI 模型根據您的資料取得答案。 開始根據您的資料發現和開發您需要的答案。 - 連接到各種資料來源，例如： - 資料庫（SQL 與 NoSQL、Google BigQuery） - 公共資料服務（Google 可程式搜尋、Arxiv.org 等） - 企業來源（Microsoft 365、Jira、Miro 等） - 利用人工智慧和法學碩士（如 ChatGPT）產生見解 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/swirlai/swirl-search --- ## [7] [Clickvote](https://github.com/clickvote/clickvote) [](https://github.com/clickvote/clickvote) 在任何上下文中加入按讚、按讚和留言。 功能齊全的 React / Angular / Vue / Svelte 來管理您的所有產品反應。 - 了解您的用戶並深入了解不同的功能 - 讓使用者互相互動 **請為此 GitHub 儲存庫加註星標 ** 👇 https://github.com/clickvote/clickvote ___ ## 要點 這些開源新創公司提供了一系列工具和服務，可以大大增強您的專案，並且您會在過程中變得更加聰明。 列出的所有專案都是開源的，歡迎所有貢獻者，您可以立即採取的一項行動是為每個儲存庫加註星標。
一直寫 todo list 很無聊吧！ ✨ TODO 應用程式以外的 5 個 JavaScript 專案想法。 這些專案將挑戰您走出舒適區，學習新知識。 試試看吧！ - 原文網址：https://dev.to/swastikyadav/5-javascript-project-ideas-beyond-todo-apps-h9h ## **1️⃣ 時間軸滾動** 開發一個記錄一系列歷史事件的網路應用程式。理想情況下，日期均勻分開並利用無限滾動。 例如，滾動回 20 世紀 80 年代很快，但滾動回恐龍時代就要很久。 ## **2️⃣ 文章導航器** 提供一個瀏覽器擴充程序，用於概述文章並顯示具有滾動功能的頁面小地圖。 始終顯示目錄在旁邊，並且無需滾動即可快速查看頁面結構。 ## **3️⃣ 數位名片** 開發一個相當於名片的單頁應用程式。 提供您的聯絡資訊、社交媒體連結以及您所做工作的簡短描述。 讓用戶決定公開分享還是僅與選定的人分享。 ## **4️⃣ 文章編修檢查器** 顯示兩個 `textarea` 或兩個檔案之間的相似性，並提供一個分數來說明它們的相似程度。 顯示 2 個檔案的差異比較，就像在 GitHub 上進行 `compare` 一樣。 ## **5️⃣ 迷因平台** 使用 Giphy API 建立您自己的迷因搜尋平台。 --- 希望有幫助！
- 原文出處：https://dev.to/surajondev/top-7-things-that-kill-developer-productivity-ef9 ## 1. 會議  無效的會議是最不必要的因素之一，它會導致開發人員的生產力下降。寫程式需要專注。進入專注模式平均需要大約 30 分鐘。但由於多次會議，這種專注被打破，開發人員必須重新開始。 還有時間消耗，因為有時 10 分鐘的會議會延長到一個小時。此外，某些會議也需要不必要的出席。如果會議不直接涉及開發人員的專業知識，通常根本不需要他們出席。 --- ## 2. 技術債（晚點再修）  技術債務可以簡單地定義為“晚點再修”的心態。 最初，我們嘗試使該功能正常工作，並將優化留到以後進行。這可能在短期內有效，因為它可以加快專案速度，並且您可能會按時完成任務。但一次又一次地這樣做將會留下大量的工作要做。從而使得維護、擴展和改進軟體變得更加困難 技術債務會在很多方面阻礙開發人員的生產力。其中一些是： - 程式碼審查的瓶頸：當技術債務增加時，會導致程式碼審查時間的增加。 - 更多錯誤：由於最初的動機是速度而不是優化，這將導致引入隱藏的和未被注意到的錯誤。 - 程式碼質量下降：只希望「能跑就好」，會導致程式碼質量差、程式碼審查隨意、甚至沒有程式碼註釋、程式碼複雜等等。 上述所有要點都需要額外的時間來解決。從而拉長了專案時間。 --- ## 3. 程式碼審查  程式碼審查需要時間，如果審查過程太慢或過於官僚，可能會延遲新程式碼的整合並減慢整個開發過程。有時開發人員提出 PR，但程式碼審查人員沒有時間審查。從而增加了開發人員處理下一個任務的時間。 對於程式碼審查，開發人員可能必須參加多次會議，從而導致開發人員的工作效率下降。通常，對程式碼的不明確或複雜的反饋可能需要更長的時間才能解決問題，因為需要進一步的對話才能理解。程式碼審查很重要，但以錯誤的方式進行只會導致生產力的降低。 --- ## 4.微管理（缺乏自主權）  微管理是一種主管密切觀察和管理下屬工作的管理方式。當經理試圖控制開發人員的編碼方式時，就會發生這種情況。這可能會導致開發人員對其程式碼、流程、決策和創造力的控制力減弱。 它可能會以多種方式導致開發人員生產力缺乏。其中一些可以是： - 缺乏動力：微管理可以表明組織對開發人員能力的信任度較低。這樣，開發人員很容易感到失去動力。 - 創造力較少：開發軟體是一項創造性的任務，您需要集中精力探索創造性的解決方案。但微管理會導致對程式碼的控制減少，甚至阻礙開發人員的創造力。 - 決策緩慢：開發人員必須從經理那裡得到簡單決策的確認，在此過程中浪費了大量時間。 在所有這些情況下，開發人員的生產力都會下降。 --- ## 5.倦怠  倦怠是開發人員最關心的問題之一。在緊迫的期限內處理複雜且具有挑戰性的專案，以及交付高質量程式碼的持續壓力可能會導致倦怠。它最終會導致開發人員的生產力下降，因為它會降低開發人員的注意力和專注於編碼和建置的能力。 它還會導致開發人員的創造力和解決問題的能力下降。它最終將導致開發週期變慢。 --- ## 6. 糟糕的文件  文件對於開發人員來說至關重要，因為它傳達了有關程式碼、專案和流程的關鍵訊息。糟糕的文件可能會導致開發週期的嚴重延遲，因為開發人員將花費更多時間來嘗試理解程式碼庫、專案和流程。從而導致開發人員的生產力降低。 在開發人員入職時，提供糟糕的文件將導致開發人員花費更多的時間在任務上，例如設置專案、管理環境、理解程式碼和其他相關的事情。如果沒有明確的文件，維護和修改現有程式碼就會變得困難。由於擔心破壞功能，開發人員可能會猶豫重構或進行更改。因此，開發人員的生產力將被浪費在非核心任務上。 --- ## 7. 不切實際的最後期限  截止日期是讓開發人員失去動力的因素之一。當你被要求在短時間進行大量工作時，你會很容易感到沮喪。它會導致倦怠、程式碼質量差、程式碼審查疏忽等，這會導致技術債務的積累。從而導致開發人員的生產率下降。 截止日期很重要，但設定不切實際的截止日期給開發人員施加壓力，會給他們帶來壓力。在壓力下，整體生產力和程式碼質量都會下降。 ## 結論 有些小工具，可以克服這些挑戰，以在開發人員的健康和生產力之間建立平衡。 以下是一些可以幫助您提高生產力的工具： - [FocusGuard](https://chrome.google.com/webstore/detail/focusguard-block-site-foc/ifdepgnnjpnbkcgempionjablajancjc)：它是一個 Chrome 擴展程序，可以通過阻止網站來幫助您建立焦點。 - [Code Time](https://marketplace.visualstudio.com/items?itemName=softwaredotcom.swdc-vscode)：它是一個 VS Code 擴展，用於跟踪您的編碼時間和活動編碼時間。 - [JavaScript Booster](https://marketplace.visualstudio.com/items?itemName=sburg.vscode-javascript-booster)：此 VS Code 擴展可以提供程式碼重建置議。您也可以找到其他編程語言的此類擴展。 - [Hatica](https://www.hatica.io/?utm_source=dev.to&utm_medium=referral&utm_campaign=surajondev)：雖然上述工具僅限於一項任務並且專注於編碼，但 Hatica 負責大部分工作。它通過改進工作流程、辨識瓶頸和跟踪進度來幫助工程團隊提高開發人員的工作效率。通過這樣做，它可以釋放開發人員大量的時間。了解有關此工程管理平台的更多訊息[此處](https://www.hatica.io/blog/engineering-analytics-for-well-being/?utm_source=dev.to&utm_medium=referral&utm_campaign=surajondev)。 我希望這篇文章能夠幫助您了解開發人員生產力下降的原因。感謝您閱讀這篇文章。
人工智能遍地開花，隨處可見一些新的人工智能工具。在 [ChatGPT](https://openai.com/blog/chatgpt)、[AutoGPT](https://autogpt.net/)、[Midjourney](https://www.midjourney.com/home/) 之間， [Dall-E](https://openai.com/dall-e-2) 和 [GitHub Copilot](https://github.com/features/copilot)，您可以建置、編碼、獲取答案，以及創造美麗的藝術品……至少我們中的一些人可以。 為什麼有些人在使用生成式 AI 時比其他人獲得更好的結果？為什麼有些人製作的藝術品配得上盧浮宮，而另一些人卻得到了接近狗屁的東西？ 這一切都取決於您使用的輸入。此輸入稱為“提示”。提示是您提出的問題，或者您用來建立內容的詞語。那些“製作”提示或對輸入有策略的人將其稱為“提示工程”。 原文出處：https://dev.to/github/prompt-engineering-for-ai-what-is-prompt-engineering-and-how-to-get-good-results-from-ai-engines-5ch6 ## 什麼是提示工程？ 提示工程是指專門設計提示，以便從 AI 獲得更好的結果。 [OpenAI](https://openai.com/)、[Google](https://bard.google.com/) 等人工智能係統的建立者甚至聘請“快速工程師”來幫助訓練他們的模型。一些“創作者”甚至在 Etsy 等平台上出售他們的 Midjourney 提示。 簡而言之，人工智能系統就像資料：輸入垃圾，輸出垃圾。如果輸入錯誤，可能會得到錯誤的結果。提示工程在很大程度上受上下文影響。 ## 人工智能的背景 當涉及到我們得到的結果時，上下文是最大的問題之一。例如，如果我用谷歌搜尋“donut”（或“doughnut”:doughnut:），我可以獲得一整套結果；從甜甜圈食譜到甜甜圈圖片，或者在哪裡可以買到這種美味的甜點。這是因為我沒有給搜尋引擎任何其他上下文。當然，Google 會使用我之前的搜尋歷史記錄和我的位置等訊息來幫助確定結果，但僅此而已。  _搜尋引擎中的術語“甜甜圈”可以指任何形狀、Slack 插件、應用程式，或者 GitHub Universe 2022 上提供的這些美味的 GitHub 甜甜圈_ 例如，如果我想找到一個關於在 Blender 中建立甜甜圈 3D 模型的教程，那麼如果我只輸入“甜甜圈”，搜尋結果可能不會顯示。我需要更具體。諸如“甜甜圈 Blender3D 教程”之類的東西會為我提供更準確的結果。 人工智能也是如此。您需要為 AI 提供足夠的上下文，以便根據您的需要獲得更好的結果。 ## 聊天應用的提示工程 許多人向我們展示了來自 ChatGPT 的一些瘋狂結果。雖然它們並不總是準確的，但 ChatGPT 確實擅長一件事：散文。寫出優美、結構合理、流暢的句子真是令人難以置信。結果很容易閱讀，聽起來真的很棒。但獲得準確的回應完全是另一回事。例如，人們厭倦了使用 ChatGPT 撰寫歷史文章，雖然文章可能讀起來不錯，但在歷史上可能並不准確。比如你讓ChatGPT“寫一篇關於中國的淪陷的2000字的文章”，它就會給你寫一篇關於中國的淪陷的2000字的文章。但它不一定是事實正確的。  _雖然某些內容可能讀起來不錯，但實際上可能不正確。提示：我沒有博士學位_ :wink: 這是因為 ChatGPT 從各種來源獲取訊息並將它們融合在一起。這些來源本身可能並不准確。 ChatGPT 也不知道您指的是中國的_哪個_秋天。因此它很容易錯誤地交叉引用日期。通過以對話方式向 ChatGPT 提供訊息，然後要求它寫一篇 2000 字的文章，您將獲得更好的結果。 那到底是什麼意思？有些人認為 ChatGPT 是一種單向的、對話式的、單一輸入的獲取訊息的方法。但事實並非如此。它被稱為“聊天”是有原因的。進行對話，完善您的問題，為您的回答提供背景訊息。 例如，如果我想要一段關於“NDC 會議”的旅行報告，我不會以“給我寫一段 NDC 旅行報告”來開始我的 ChatGPT。相反，我會首先弄清楚 ChatGPT 對 NDC 了解多少，並在此過程中提供上下文。您提供的輸入在很大程度上決定了輸出。這就是為什麼有些人能夠獲得非常好的結果，而其他人則不能。  _沒有任何上下文，ChatGPT 不知道我指的是什麼 NDC_ 另一個例子：如果你要去參加工作面試，你想要一些提示，讓 ChatGPT“給我一些準備工作面試的提示”，會給你一些很好的回應，但它遠非具體。相反，諸如“我要去一家 AI 初創公司面試軟體開發人員的職位。你能給我一些準備面試的提示嗎？”將為您提供更加量身定制的個性化結果。這就好比你讓台上的專家給觀眾中的 1000 個人一個答案，他們可能會提供一些通用的東西，這樣每個人都有一個外賣訊息。但如果你一對一地問同一個人，他們可能會問你一些後續問題以了解你的情況，因此會提供更個性化、更具體的答案。 ## 藝術應用的提示工程 您可能已經看到一些人使用穩定的傳播應用程式創作的一些精美藝術品。然後是看起來“錯誤”的藝術品。其中很多都歸結為上下文。例如，如果我使用 [Night Café](https://nightcafe.studio/)（我最喜歡的生成器之一），然後輸入“dog”這個詞，這就是我得到的：  _使用 Night Café 生成的圖像，以及提示符“dog”_ 有一些隨機的“狗”字寫成一個標誌，前景中有一隻看起來很奇怪的狗，而且它的顏色非常奇怪。現在，如果我想像成年德國牧羊犬在陽光明媚的日子裡在公園裡的照片般的圖像，那可能不是我要得到的。人工智能沒有那種背景。它無法讀懂我的想法（還沒有！）。當你想創作藝術品時，你需要描述你在腦海中想像的圖像。您提供的細節越多，輸出就越好。這就是它變得棘手的地方。許多穩定的擴散應用程式都有有限的字符數。因此，您需要對如何製作提示具有意義和戰略性。 與 ChatGPT 類似，您需要不斷地重新製作提示並完善它們。然而，基於聊天的 AI 的優勢在於，您可以繼續對話並不斷向 AI 提供更多訊息和不同的問題，以獲得良好的回應。雖然一些藝術生成器允許您“重新混合”您的輸出，但它仍然依賴於新的提示。因此，您一直在等待輸出，查看未加入的內容，然後發送經過調整的新提示。一些用戶在 Midjourney 上花費數小時，接收輸出並重新製作他們的提示以產生一些驚人的作品。這都是練習的問題。這就是為什麼一些創作者在 Etsy 上出售他們的提示！  _我的朋友 Jean 使用 Midjourney 製作的藝術品_ 有一件事是肯定的，如果你想製作一些高質量的藝術品，不要指望花幾秒鐘寫一個提示，點擊“建立”按鈕然後看到莫內。沒有！相反，您需要投入時間（和金錢）來創作數百件藝術品，在每次迭代中重新處理您的提示以製作您的傑作。 ## 提示工程程式碼 我不會花大量時間談論如何為 [GitHub Copilot](https://github.com/features/copilot) 之類的東西製作好的提示。我的同事 [Rizel](https://twitter.com/blackgirlbytes/) 寫了一篇精彩的博文，深入探討了 GitHub Copilot 的提示工程： https://dev.to/github/a-beginners-guide-to-prompt-engineering-with-github-copilot-3ibp 我要說的是——類似於 ChatGPT——GitHub Copilot 依賴於上下文。存儲庫中還編寫了哪些其他程式碼？文件的擴展名（以及語言）是什麼？ GitHub Copilot 還為您打造了什麼？您在程式碼中加入了哪些註釋？所有這些都將幫助 GitHub Copilot 為您合成更準確的程式碼。 可以這樣想：如果您寫了一條評論，說明您想要建立一個使用後端資料並解決特定問題的複雜函數，那麼您可能不會僅僅通過一條評論就得到很好的回應。就像你的程式碼——至少它應該是——被分解成許多函數，（希望）有很多有用的評論，當你分解東西時，GitHub Copilot 工作得更好。 而不是要求 GitHub Copilot： `//反轉句子`（使用 JavaScript） 想想如何從邏輯上分解問題。例如，如果有人給我一張紙，上面寫著一句話，讓我把它倒過來，我會怎麼做？像這樣寫評論會更有益。如果您這樣做，GitHub Copilot 將擁有更多的上下文並更好地理解您想要什麼。 與 ChatGPT 之類的東西相比，GitHub Copilot 的另一個區別是 GitHub Copilot 考慮了你擁有的_所有_上下文。我上面提到的所有事情： - 什麼是文件擴展名 - 專案中還有哪些其他文件 - 你是怎麼寫其他評論的 - 其他程式碼是如何建置的 - 您輸入的評論是什麼 - 您輸入的程式碼是什麼 ChatGPT 和其他聊天應用程式會更加重視您對聊天所做的最後評論； 也就是，您加入到對話中的最後一條訊息。但是，GitHub Copilot 始終會考慮上下文以生成更好的程式碼結果。 ## 更好的提示工程 歸根結底，從任何類型的生成式 AI 中獲得好的結果都在你身上——你提供輸入的人。正如我一開始所說：垃圾進，垃圾出。因此，在製作提示時請考慮以下重要提示： - 提供良好的**上下文**；提供有關您要實現的目標的示例和訊息 - 請明確點**;如果它是針對特定觀眾的，那麼就說 - **分解**問題 - **清楚**你如何提問。如果返回的內容聽起來不對，請澄清 - 根據您的提示**改寫**和**精煉** 最後，始終，始終驗證您從 AI 收到的訊息。對於藝術品生成器而言，這不太重要，但如果您查看程式碼和訊息，它就很重要。檢查您收到的程式碼是否按照您的預期工作。驗證提供給您的書面訊息的準確性。 請記住，無論發生什麼，您仍然是飛行員。您仍然是負責人，您對使用和共享哪些藝術作品、哪些程式碼片段以及哪些訊息有最終決定權。
感謝站長關懷～ 是的，這禮拜確實有遇到一些之前有稍微碰過卻不太熟悉的東西，也有之前沒有碰過的東西，是有些小崩潰...，但還是可以稍微跟大家分享與請教一下： 這裡有一些前期提要：公司目前的前端開發並不使用現在的主流前端框架，也沒有使用打包整合工具...（像是Webpack、Parcel這類的)，ＪＳ使用JQuery，並且將ＪＳ檔案一個一個的引入網頁中。 ## 遇到的問題1 ：CSS樣式問題 過去在自學的時候其開發方法是：在本機開發，然後在處理樣式與ＲＷＤ時就是開啟Chrome 的 Dev Tools來做調整，但也有遇過在Chrome的Dev Tools中看起來將樣式都調整好了之後，部署到網路上之後換手機來查看頁面時卻發生了一些差異，這些差異可能包含滿版、間距等等，這部分我自己理解的差異可能會是有些手機會有瀏海的緣故以及Chrome與Safari之間的小差異．到新公司後發現在更多的裝置上，例如安卓手機，則存在的差異更多，包含顏色、日期時間選取器等等的樣式，因為型號真的太多了． ###到這裡可以跟大家分享的以及向各位請教的： 這裡我自己有想到幾個解決的方式，第一個是最懶的方法我最想用但是我有些不知道該如何整合給其他人使用的方法，例如透過Vue cli直接在npm下載PostCSS以及Autoprefixer這樣的工具來使用，一次解決主流瀏覽器的差異，但目前我不太曉得如何在公司的開發方法下，不透過整合工具來完成這個流程． 另一個我想到的方法是加入CSS Normalize來減少各個瀏覽器在不同樣式的預設值差異，過去我們可能都有寫過非常簡易CSS reset 例如： ```css= *{ padding: 0; margin:0; box-sizing:border-box; } ``` 但這樣如果把每一個樣式的預設值全部強制歸零，可能會導致有些樣式到後來要重新寫，或許Ｎormalize可以只是單純地減少差異（也是因為網路上有人已經整理好了ＸＤ）． ## 遇到的問題2 ：API串接 過去我自己練習串接API的方式實在是相當簡易，我拿的是中央氣象局開放資料平台的API，所以之前很簡單的一行fetch就拿到資料了，毫無難度哈哈哈，但第一天公司需要我去切幾個版面並且串接運輸資料ＴＤＸ的資料，恩...我一開始不知道要如何在ＪＳ中塞入登入資料並且拿回Token的方式．以及我要查詢的數值該如何發出． ###到這裡可以跟大家分享的以及向各位請教的： 這中間我摸索了fetch的一些選項設定，這應該也適用其他的非同步請求方法，例如ajax、axios(這兩個我還沒用過，後續應該會來摸索一下axios），包含請求方法（method)，header與body中的內容設定等等． 至於API該如何塞入a頁面填入查詢參數並且跳轉到b頁面顯示查詢解果，在沒有前端框架全域狀態管理的支援下，這邊則是摸索了encodeURIComponent以及decodeURIComponent這樣的函式，將要查詢的參數在a頁面進行編碼並丟入到ＵＲＬ中，跳轉到b頁面後再進行解碼．並fetch我要的資料．最後是有成功的，只是覺得自己像薪水小偷哈哈哈，效率並不高． 這個方法感覺並不建議應用在需要輸入有個人資料的內容中，因為編碼的方式是雙向的，資料可以編碼也可以解碼，所以....像個資這類的內容就應該不建議塞在ＵＲＬ中用這種方式傳輸．至於要用什麼方法，這也是我想知道的． ## 遇到的問題3：不同裝置的問題 這個並非第一個樣式的問題，而是我目前覺得還沒有解的問題，就是我在網頁中需要獲取使用者的位置，因此用了navigator.geolocation 這個API，但神奇的是，在本機中都可以抓得到資料，打開Dev Tools檢查回傳的狀態碼與經緯度也都是沒有問題，但是在手機中雖然會顯示是否能夠取得使用者位置的提示，但按了同意後卻一直無法獲取資料，而且尷尬的是，我無法在手機中打開Dev Tools，所以我也不知道問題發生在哪....，過去有使用過navigator.geolocation 好像也沒有碰過這樣的問題 想跟各位請教的是，有什麼方式可以查看手機上的問題嗎？ ## 遇到的問題4：不同的開發方式 這個是我自己很好奇的，雖然說我知道Vue是漸進式框架，但我卻不知道該如何漸進．我理解的漸進式是，有些頁面或元件可以自行選擇要不要使用Vue開發，還是這個漸進式的意思是可以自行選擇要使用多少Vue的套件工具呢（像是要不要使用Vue Router or Vuex)． 會這樣問是因爲，假如現在有一份專案一共是十個頁面，我被分到了其中五頁，另外的同事則是負責另外五頁，誠如開頭所說，假如公司既定的開發方式並不使用框架與其他整合工具，我有可能使用框架進行開發並與之合作嗎？還是我這是一個很奇怪的問題，本來就應該要統一一個開發方式？ --- 感謝看到這邊的各位，以上有些觀念上是我這位小菜雞自己摸索的，是可能不是正確的（例如有些函式、工具的用途或使用情境），因此歡迎大家指教與討論，這是我這禮拜可以跟大家分享的啦． 謝謝～～ --- ＰＳ：我自學八個月的時間有摸了原生JS、ＣＳＳ、Vue.js、Tailwind、SCSS這樣的工具，本來我是很想要在第一份工作多了解與強化上述工具以及多人開發GitHub的部分，我了解這些終究只是工具且我自己也沒有到非常熟，只要可以完成專案目的即可，我的實力在哪裡我也知道，但以目前公司的開發模式來說，我需要考量沒有踏上趨勢的這個問題嗎？還是我多慮呢了？
[VS Code](https://code.visualstudio.com/) 是一款免費、跨平台、開源的程式碼編輯器，近年來成為開發者最熱門的選擇。 在本文中，我整理了一些最有用的外掛，您可以使用它們來提高工作效率。 原文出處：https://dev.to/madza/19-vs-code-extensions-to-boost-your-productivity-4npo --- ### 1\. [Swimm](https://go.swimm.io/ide-plugin?utm_source=Hashnode&utm_medium=paid_influencer&utm_campaign=launch_may&utm_content=madza_dev) 使用 Swimm 的富文本編輯器建立文件。記錄跨越多個文件和存儲庫的複雜流程，其中包含與程式碼交互並在您進行更改時自動更新的豐富內容。 在本地驗證和更新文件，並將其作為 CI 工作流的一部分，自動修復簡單的錯誤，並且僅在發生重大更改時提醒您。 在正確的時間找到正確的文件——就在相關程式碼旁邊。當您看到一個 wave 時，這意味著存在與該特定程式碼部分相關的文件。  ### 2\. [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) 借助 GitLens，開發人員可以通過提供有關 Git 存儲庫的高級可視化和訊息，更好地了解其程式碼庫的歷史、作者身份和更改。 GitLens 還提供了一組豐富的自定義選項，以及內聯責備註釋、提交和差異詳細訊息，甚至無需離開編輯器即可查看和編輯提交訊息的能力。  ### 3\. [Thunder Client](https://marketplace.visualstudio.com/items?itemName=rangav.vscode-thunder-client) Thunder Client 是用於 Visual Studio Code 的輕量級 Rest API 客戶端擴展，具有簡單易用的 UI。 支持集合和環境變數和 GraphQL 查詢，以及使用基於 GUI 的界面進行無腳本測試。 所有請求的資料都本地保存在您的設備上。  ### 4\. [Tabnine](https://marketplace.visualstudio.com/items?itemName=TabNine.tabnine-vscode) Tabnine 是一個 AI 程式碼助手，可以通過在所有最流行的編碼語言和 IDE 中實時完成程式碼來提高您的開發速度。 Tabnine 由多種語言專用的機器學習模型提供支持，這些模型是在程式碼上從頭開始進行預訓練的。  ### 5\. [Remote-SSH](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh) Remote - SSH 擴展允許您使用任何帶有 SSH 伺服器的遠程機器作為您的開發環境。 無需在本地計算機上安裝源程式碼即可獲得這些好處，因為該擴展程序直接在遠程計算機上執行命令和其他擴展程序。 您可以打開遠程計算機上的任何文件夾並使用它，就像文件夾在您的計算機上一樣。  ### 6\. [Docker](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker) Docker 擴展使從 Visual Studio Code 建置、管理和部署容器化應用程式變得容易。 它還提供了對容器內 Node.js、Python 和 .NET 的一鍵式除錯。  ### 7\. [Git History](https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory) 使用此擴展，用戶可以輕鬆瀏覽提交歷史記錄、檢查文件更改並比較程式碼的不同版本。 該擴展提供了一個 GUI，可以在時間軸中顯示提交歷史記錄。每個提交都與其提交訊息、作者、日期和時間一起顯示。 用戶還可以查看與每個提交關聯的分支和標籤名稱。  ### 8\. [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) 對於在 VS Code 中使用大量 Markdown 的任何人來說，這是一個有用的工具。它使建立和編輯 Markdown 文件變得更加容易和快速，幫助您提高生產力和效率。 這些功能包括語法突出顯示、程式碼塊格式化、目錄、預覽模式、表情符號支持、鍵盤快捷鍵等等。  ### 9\. [Regex Previewer](https://marketplace.visualstudio.com/items?itemName=chrmarti.regex) 該擴展在並排文件中顯示當前正則表達式的匹配項。這可以使用 Ctrl+Alt+M 打開/關閉。 可以通過狀態欄條目加入全局選項和多行選項，以便使用並排文件進行評估。當並排文件有多個匹配示例時，這會很有用。  ### 10\. [Better Comments](https://marketplace.visualstudio.com/items?itemName=aaron-bond.better-comments) 使用此擴展，您將能夠將註釋分類為提醒、查詢、TODO、突出顯示等。 註釋掉的程式碼也可以設置樣式以明確程式碼不應該存在。您可以在設置中指定您想要的任何其他評論樣式。  ### 11\. [Bookmarks](https://marketplace.visualstudio.com/items?itemName=alefragnani.Bookmarks) 書籤擴展可幫助您導航程式碼，輕鬆快速地在重要位置之間移動。 不再需要搜尋程式碼。它還支持一組選擇命令，允許您選擇書籤行和書籤行之間的區域。它對日誌文件分析非常有用。  ### 12\. [Project Manager](https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager) 專案管理器可幫助您輕鬆存取您的專案，無論它們位於何處。不要再錯過那些重要的專案了。 您可以定義您的專案（也稱為收藏夾），或選擇自動檢測 Git、Mercurial 或 SVN 存儲庫、VS 程式碼文件夾或任何其他文件夾。 此外，您還可以使用標籤來組織您的專案。  ### 13\. [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) 一個基本的拼寫檢查器，適用於程式碼和文件。 這個拼寫檢查器的目標是幫助捕獲常見的拼寫錯誤，同時保持較低的誤報率。  ### 14\. [Image Optimizer](https://marketplace.visualstudio.com/items?itemName=MadsKristensen.ImageOptimizer) 向解決方案資源管理器中的任何文件夾和圖像加入右鍵單擊菜單，使您可以自動優化該文件夾中的所有 PNG、GIF 和 JPEG 文件。 只需右鍵單擊任何包含圖像的文件或文件夾，然後單擊其中一個圖像優化按鈕。  ### 15\. [CSS Peek](https://marketplace.visualstudio.com/items?itemName=pranaygp.vscode-css-peek) 該擴展支持符號定義跟踪的所有正常功能，但它適用於 CSS 選擇器（類、ID 和 HTML 標記）。 您可以內聯加載 CSS 文件並在此處進行快速編輯，直接跳轉到 CSS 文件或在新編輯器中打開它或在懸停時顯示定義。  ### 16\. [Placeholder Images](https://marketplace.visualstudio.com/items?itemName=JakeWilson.vscode-placeholder-images) 使用各種第 3 方服務（如 Unsplash、LoremFlickr 等）在 Visual Studio Code 中生成佔位符圖像並將其插入到 HTML 中。 您可以選擇圖像寬度、高度、文本和顏色，將生成的 IMG 標籤插入到您的 HTML 中或將其複製到剪貼板，或者將圖像 URL 插入到您的 HTML 中，複製到剪貼板，或在您的瀏覽器中打開它。  ### 17\. [Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) 具有實時瀏覽器重新加載功能的快速開發實時伺服器。從狀態欄單擊即可啟動或停止伺服器。 允許用戶建立可自定義的端口號，設置伺服器根目錄，並在設置中提供默認的瀏覽器配置選項。  ### 18\. [Peacock](https://marketplace.visualstudio.com/items?itemName=johnpapa.vscode-peacock) 使用 Peacock，您可以巧妙地更改 VS Code 工作區的顏色。 當你有多個 VS Code 實例、使用 VS Live Share 或使用 VS Code 的遠程功能，並且你想快速辨識你的編輯器時，這是理想選擇。  ### 19\. [Polacode](https://marketplace.visualstudio.com/items?itemName=pnp.polacode) Polacode 是 VS Code 的擴展，它可以對你的程式碼進行截圖。 該擴展生成一個與源具有相同風格和主題的螢幕截圖。  --- 以上簡單分享，希望對您有幫助～
初學者接觸OOP，幾乎都會有以下疑惑： 我到底為什麼要學OOP？OOP解決了什麼問題？書上這些範例就算不用OOP也寫得出來吧？ 然後覺得「繼承」、「多型」、「介面」、「抽象類別」等等的名詞很難，覺得OOP很難。 其實這些名詞雖然重要，但對新手來說，本來就很難在一開始就搞懂。 建議先搞懂「資料跟行為在一起」是什麼，以及它的好處在哪，就可以了，其它的慢慢來。 # 什麼叫做「資料跟行為在一起」？ 假設我們在開發一個「中英文互助學習網」，鼓勵中文人士與英語人士登入討論。 這個系統的貼文、留言功能會顯示「發文日期」。 發文日期要根據使用者的註冊身份（台灣人、英語人士）顯示不同格式（台灣格式、西方格式）。 下面就以這個日期格式的功能舉例說明「資料跟行為在一起」是什麼意思。 ## 作法一：直接硬寫（不OOP、資料跟行為混在一起） 初學者通常會用最簡單、也最直覺的作法，直接硬寫出來，像這樣： ``` <?php $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 if (/* 判斷是否顯示台灣格式 */) { # 轉換成這樣 2016.6.2 $arr = explode('-', $postDate); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; echo "$year.$month.$day"; } else { // 西方格式 # 轉換成這樣 6/2/2016 $arr = explode('-', $postDate); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; echo "$month/$day/$year"; } ``` 這種寫法的資料（日期）跟行為（轉換成各種格式）混在一起。 它的優點是寫起來很簡單，缺點則有兩個： * 日期格式的邏輯會重複出現在很多地方，整段code會到處重複出現 * 整段code大概會塞在 `div` 或是 `span` 的裡面，導致它跟HTML混在一起，很亂 ## 作法二：自訂函數（不OOP、資料跟行為沒混在一起） 為了解決作法一遇到的問題，聰明的初學者很快就想到可以用「自訂函數」！就像這樣： ``` <?php function localFormat($date) { $arr = explode('-', $date); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; return "$year.$month.$day"; } function englishFormat($date) { $arr = explode('-', $date); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; return "$month/$day/$year"; } $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 if (/* 判斷是否為台灣人身份 */) { echo localFormat($postDate); } else { // 英語人士身份 echo englishFormat($postDate); } ``` 這種寫法將行為（轉換成各種格式）用自訂函數給獨立出來，也大幅改善了作法一遇到的問題。 對小型的網頁程式來說，這招非常好用，不但開發快速、簡單，還漂亮地將資料跟行為拆開。 但是程式規模變大之後，為了將各種行為拆出來，會寫出很多自訂函數，類似這樣： ``` ?php function localFormat($param) { // blah blah ... } function englishFormat($param) { // blah blah ... } function someTask($param) { // blah blah ... } function anotherTask($param) { // blah blah ... } function otherTask($param) { // blah blah ... } //... ``` 於是又衍生出三個問題： 1. 像localFormat、englishFormat這樣的函數名稱意義模糊，看不出是處理日期、人名，還是什麼東西的格式 2. 這些自訂函數各有不同的行為，全部放在一起顯得很亂，應該要想辦法分類、整理這些函數 3. 像localFormat、englishFormat這樣的函數，只吃特定格式的參數，最好能跟某種資料的形式綁在一起，以後要改程式時，能讓相關的資料跟行為一起被看到 問題1很好解決，只要替函數名稱加前綴字變成dateLocalFormat、dateEnglishFormat就行了。 問題2也很好解決，只要多開幾個檔案，把相關的函數放進同一個檔案就行了。 問題3就很棘手，資料跟行為拆開之後，如何在概念上又找方法整理在一起？ ## 作法三：使用class（OOP、資料跟行為在一起） 正是這些處理資料、整理行為的問題，導致了OOP的誕生： ``` <?php class Date { public $year; public $month; public $day; public function __construct($date) { $arr = explode('-', $date); $this->year = $arr[0]; $this->month = $arr[1]; $this->day = $arr[2]; } public function localFormat() { return $this->year . '.' .$this->month . '.' . $this->day; } public function englishFormat() { return $this->month . '/' .$this->day . '/' . $this->year; } } $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 $date = new Date($postDate); if (/* 判斷是否為台灣人身份 */) { echo $date->localFormat(); } else { // 英語人士身份 echo $date->englishFormat(); } ``` OOP的寫法，一次解決了前述三個問題： 問題1 => 現在從類別名稱就可以知道底下方法的意義了 問題2 => 現在相關的函數都整理進同一個類別底下成為方法了 問題3 => 現在資料的形式都統一在constructor處理一次，之後不管新增多少方法都不用處理資料了 這就是所謂的「資料跟行為在一起」，也正是OOP的核心概念。 利用這種方式整理程式碼、寫出一個又一個的類別，可以大幅提昇程式碼的品質。 # 結論 上述的作法一跟作法二並沒那麼糟糕，但確實會帶來一些問題。 對於小型的網頁程式來說，可能還算夠用。 但是隨著程式規模變大，如果將概念上相關的資料跟行為整理在一起，會很有幫助。 實務上也可以先從作法二開始寫起，直到發現某些資料跟行為關係密切，再拉出來整理成類別即可。 至於很多OOP教學會提到的「繼承」、「多型」、「介面」、「抽象類別」等等名詞，一時搞不懂沒有關係，你可能實務上也暫時用不到。之後找時間慢慢搞懂它們的用途就好。 光是知道「將資料跟行為放在一起」的技巧，就能夠開始寫OOP程式碼了。 （註：本篇文章的程式碼純屬教學用途。實務上PHP已經有DateTime類別可以使用，或是用更漂亮的Carbon類別。） ## Q&A Q1：我常常設計一些類別，只有資料沒有行為，聽起來OK嗎? 不OK，這很不OOP，而且沒意義。 乾脆直接用關聯式陣列去表示那些資料就好。 Q2：我常常設計一些類別，只有行為沒有資料，聽起來OK嗎? 這個要看情況，不一定。 但唯一可以確定的是，這種作法很不OOP。 因為OOP的核心是「資料跟行為在一起」。 這也是為什麼你會看到有人明明寫了類別、用了物件，別人卻說「這不夠OOP」。 然後你又會看到像JavaScript這樣連「類別」關鍵字都沒有（ES5以前），卻能夠寫出很OOP程式碼的關係。 判定的標準都是一樣的，而且也就只有這麼一個標準：資料跟行為有沒有在一起。 Q3：一個類別包含的概念是越大越好，還是越小越好？ 不一定。不過我們從作法一到作法三的過程，有一個明確目的：希望讓程式碼更好懂。 如果聲稱一個類別包含的概念很大（例：設計LanguageHelpWebsite類別，用來代表「中英文互助學習網」需要的所有功能），那會把幾乎整個網站的所有行為跟資料都放進去，成為所謂的God object。它可沒有讓程式碼更好懂。 相反地，如果聲稱一個類別包含的概念很小（例：分別設計LocalDate、EnglishDate類別），雖然意義可能更精準了，但用一整個Date類別的概念去思考，程式碼會更容易理解，也就是所謂的內聚性（Cohesion）更高。 所以要替OOP就是「資料跟行為在一起」加個但書： 要以方便理解程式為前提，將資料和行為放在一起。
## 課程目標 - 能夠寫出體重追蹤應用程式 ## 課程內容 找套件時，如果官方沒有提供特定框架的版本，通常會有開發者，自行包裝一個，分享給大家使用 搜尋 `how to use 套件名稱 in 框架名稱` 大概就找得到相關資源了 舉例來說，這款圖表套件，官方沒有提供框架版本 https://www.chartjs.org/ 但是社群就有人做好了 https://vue-chartjs.org/ --- 介紹一個網站 https://dribbble.com/ 業界設計師，經常在上面搜尋別人的成品、找靈感、分享靈感 除了在 google 搜尋關鍵字，也可以常常到 Dribbble 搜尋 --- 這一課來寫體重追蹤應用程式 關鍵字 `weight tracking` ## 課後作業 請使用 https://replit.com/ 來寫作業 這次作業的規格如下： - 這種程式應該要讓人註冊登入使用，需要後端配合，但我們簡化吧：免登入、把資料存在 local storage 就好 - 此程式能夠新增一筆體重資料，input 欄位有「體重」、「日期」 - 有清單列表顯示每一筆輸入的資料，按照日期排序。每筆資料旁邊有刪除按鈕 - 使用 Chart.js 將體重的走勢，用折線圖（Line Chart）呈現 - 請「不要」使用社群包裝的版本（vue-chartjs），學著自己在框架內導入套件 --- 提示：vue 跟 chart.js 整合的時候，有一個地雷！會導致 `RangeError: Maximum call stack size exceeded ` 要解決這個地雷，請參閱這邊的討論 https://codelove.tw/@birdie2019/post/Ja69K3 --- 做出以上功能，你就完成這次的課程目標了！
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
