🔍 搜尋結果:網頁

🔍 搜尋結果:網頁

挑戰串接CodeLove的API

成品連結:https://codingdark.github.io/program/2023/09/18/API-Test.html ##第一步 架部落格 最初看到站長的貼文,提供了本站的API 並且鼓勵大家自架部落格,來嘗試串API 看到文章的當下,覺得有點難度(沒用過github page,API也不熟) 不過看到站長提供的關鍵字`setup a personal blog with github pages` 最終還是決定先google看看 查了之後,發現近年的gitbub簡化了很多 都可以自動部署,根本就是一鍵架站 外加原始碼開源,很多東西都能自己改 所以光是部落格就玩了一天XD 因為本站為CodeLove 愛寫扣 我就創了一個CodingDark 闇寫扣 表示致敬本站 & 本人的中二風格 ##第二步 串API 因為不熟的關係,所以決定先隨便串 呼叫API之後,把data印在console.log 大致上看了一下資料格式 使用上其實就類似陣列,非常方便 沒有想像中的難 確認API可以正常呼叫後 陸續加入一些功能 比方說,用Table把文章列表排整齊、加上[Read more]按鈕 先讓json資料,轉換成網頁能呈現出來的[資訊] ##第三步 程式碼優化 到這邊為止,網頁的畫面已經差不多定型了 剩下的就是回頭檢視程式碼 考量到後續維護 盡可能把重複的程式碼,包裝成function 或是把一群散亂的變數,包裝成object 最後,為了方便擴充文章列表 將原本是寫死的HTML Dom 改成動態產生 目前的部落格頁面 點進去會撈出站長、Tony,以及我的文章列表 後續若想要列出其他使用者的文章 只需新增`setTable(userAccount)`即可 ##結尾 感謝站長提供有趣的API 讓大家可以有練習的機會 雖然目前我在工作上,沒接觸過API 但經過這次的練習,以後若是真的有需要用到 可以更快上手

主流商用軟體的 10 個開源選擇方案

一篇國外的熱門文章,關於一些開源選擇方案,翻譯出來給大家參考。 - Medusa vs. Shopify - Postman vs. Hopscotch - Slack vs. Rocket Chat - Google Chrome vs. Brave - n8n vs. Zapier - Webflow/Framer vs. Webiny - Bit.ly vs. Dub.co - Calendly vs. Cal.com - Airtable vs. NocoDB 原文出處:https://dev.to/rigdev/10-open-source-alternatives-to-proprietary-software-34lb --- ##Medusa:Shopify 的替代方案 ![Medusa:Shopify 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n0lsrwimibby8vpfqyjc.png) 您可能聽說過 Shopify,它是遊戲中的大玩家。但現在有一個新的競爭者:美杜莎。讓我們來分析一下這兩者的優點、缺點以及本質。 ###Medusa 與 Shopify 相比的優點: **按你的方式做**:Medusa 是開源的,這意味著您可以根據自己的喜好對其進行調整。想要一個霓虹粉紅結帳按鈕嗎?大膽試試吧! **保留您的現金**:與 Shopify 不同的是,除非您使用他們的支付系統,否則 Shopify 會奪走您的部分銷售額,而 Medusa 不會動用您的口袋。 **選擇你的家**:透過 Medusa,你可以決定在哪裡開設你的商店。這就像在租公寓還是建造自己的房子之間做出選擇。 **權力歸於人民**:美杜莎受到社區的愛戴。這意味著定期更新、酷炫的新功能以及一群隨時準備提供幫助的人。 **沒有秘密**:開源意味著您可以看到幕後發生的一切。 ###Medusa 與 Shopify 相比的缺點: **開箱即用**:Shopify 擁有大量內建功能和龐大的應用程式商店。美杜莎在這方面仍在迎頭趕上。 **減少 DIY**:使用 Shopify,許多技術問題都會為您處理。美杜莎?您坐在駕駛座上,但這意味著您也必須應對道路上的顛簸。 **名言**:每個人都知道 Shopify。美杜莎仍然是學校裡的新生。 ###結論: 在 Medusa 和 Shopify 之間進行選擇可以歸結為您的特定需求和技術專長。如果您重視靈活性、客製化和成本控制,Medusa 是令人信服的選擇。然而,如果您正在尋找一個擁有良好記錄、廣泛內建功能和強大支援的平台,Shopify 仍然是一個強大的競爭者。 ##Hopscotch:郵差的替代方案 ![跳房子:郵差替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/omls8xf9jd2jocktn1mp.png) 您可能聽過 Postman,它是 API 測試領域的大人物。但有一個開源挑戰者踏入了這個圈子:Hopscotch。 ###Hopscotch 與 Postman 相比的優點: **像鳥一樣自由**:作為開源軟體,Hopscotch 不會花費您一毛錢。對於關注預算的小型團隊或個人開發人員來說,這可能是一個巨大的勝利。 **社群氛圍**:像 Hopscotch 這樣的開源工具依靠社群的投入而蓬勃發展。這意味著您有一群充滿熱情的人不斷改進它並加入很酷的新功能。 **透明度**:對於 Hopscotch,不存在任何幕後謎團。您可以看到每一行程式碼,確保您確切知道發生了什麼。 **輕量級**:Hopscotch 往往比 Postman 更輕量級,如果您正在尋找資源密集程度較低的東西,這可能是一個優勢。 **豐富的客製化**:由於是開源的,如果缺少您需要的功能,您可以自行加入或召集社群來提供協助。 ###Hopscotch 與 Postman 相比的缺點: **功能豐富**:Postman 已經廣泛存在並擁有大量內建功能。它就像是 API 測試的瑞士軍刀。 **流暢的使用者介面**:Postman 的使用者介面精美且直觀,讓新手可以輕鬆上手。 **協作功能**:透過其團隊協作工具,Postman 讓團隊可以輕鬆地協同工作、共享集合並保持所有內容同步。 **廣泛的文件**:Postman 參與遊戲已經有一段時間了,因此他們建立了一個龐大的教程、指南和社區帖子庫來幫助您。 **整合生態系統**:Postman 提供與各種其他工具的集成,使其更容易融入現有工作流程。 如果您熱衷於開源,喜歡修補,並且正在尋找一個輕量級工具,那麼 Hopscotch 可能是您最好的新朋友。但如果您想要一個功能豐富且擁有良好記錄的環境,並且不介意花一些錢購買高級功能,那麼 Postman 仍然是一個不錯的選擇。像往常一樣,關鍵是找到適合您需求的工具。 ##Rocket Chat:Slack 替代方案 ![Rocket Chat:Slack 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jwewh09g82kg1ez8egay.png) 當談到團隊溝通工具時,Slack 一直是許多人的首選。但等一下,擂台上有個開源挑戰者:Rocket.Chat。讓我們透過簡單地了解 Rocket.Chat 與 Slack 相比的三個優缺點來分解這兩者的比較。 ###為什麼 Rocket.Chat 可能會震撼您的世界: **調整和調整**:Rocket.Chat 是開源的,這意味著如果有您不喜歡的東西或您認為可以更好的東西,您(或您的技術團隊)可以參與並自訂它。您的 Rocket.Chat 可以像您團隊最喜歡的內部笑話一樣獨特。 **錢包友好**:使用 Rocket.Chat,您可以避免 Slack 等高級版本專有軟體帶來的一些討厭的費用。此外,由於是自託管,您可以更好地控制未來潛在的價格上漲。 **您的資料,您的規則**:在您自己的伺服器上託管 Rocket.Chat 意味著您可以完全控制您的資料。無需擔心第三方存取或資料儲存位置。 ###Slack 仍可能佔上風的地方: **即插即用**:Slack 以其用戶友好的介面和易於設定而聞名。對於那些不懂科技的人來說,Slack 的簡單方法可能是一件幸事。 **整合**:Slack 一直處於領先地位,擁有龐大的應用程式整合庫。無論是 Trello、Google Drive,還是您的團隊離不開的小眾工具,Slack 都可能提供了整合。 **酷兒童俱樂部**:Slack 的受歡迎意味著許多人已經熟悉它。如果新團隊成員之前已經使用過 Slack,那麼新團隊成員的入職或與合作夥伴的協作可能會更順利。 ###結論: Rocket.Chat 提供了一個無與倫比的客製化、成本節約和資料控制的世界。但如果您正在尋找無憂無慮的設置、大量的整合以及廣泛的熟悉度,Slack 仍然可以滿足您的需求。一如既往,最好的選擇取決於您的團隊最重視的是什麼! ##Brave:Google Chrome 的替代品 ![勇敢:Google Chrome 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cg5kruse2v60hvr61dwo.png) 就網頁瀏覽器而言,Google瀏覽器在相當長一段時間內一直是衛冕冠軍。但有一個新的競爭者正在引起轟動:Brave。 Brave 建構於與 Chrome 相同的 Chromium 引擎之上,承諾提供不同類型的瀏覽體驗。 ###Brave 與 Google Chrome 相比的優點: **隱私第一**:Brave 非常重視隱私。它可以立即阻止第三方廣告和追蹤器,這意味著您不必擺弄設定或加入擴充功能來阻止公司在網路上追蹤您。 **速度惡魔**:由於其廣告攔截功能,Brave 通常加載頁面的速度比 Chrome 更快。更少的廣告和追蹤器意味著更少的下載資料,讓您的瀏覽體驗更快捷。 **衝浪獲得報酬**:Brave 有一個獨特的功能,稱為 Brave 獎勵。選擇尊重隱私的廣告,您可以獲得 BAT(基本注意力代幣),您可以將其保留或作為小費提供給您最喜歡的網站。 Chrome 不提供類似的功能。 ###Brave 與 Google Chrome 相比的缺點: **豐富的擴充功能**:Chrome 的網路應用程式商店是擴充功能和應用程式的寶庫。雖然 Brave 是基於 Chromium 引擎建置的,因此能夠安裝所有 Chrome 擴充程序,但由於某些擴充功能非常注重隱私和廣告攔截,因此可能會出現相容性問題。 **Google 生態系統**:如果您已經投資於 Google 領域(例如 Google 雲端硬碟、Google 照片、Google Meet),那麼 Chrome 可以與這些服務無縫整合。 Brave 可以存取它們,但不太順利。 **穩定可靠**:Chrome 已經存在多年,並且在穩定性和性能方面擁有良好的記錄。 Brave 比較新,雖然很強大,但還沒有足夠的時間來解決所有的問題。 ###結論: 如果您重視隱私,並且喜歡更快、更有價值的瀏覽體驗,那麼 Brave 可能會改變您的遊戲規則。但如果您是 Chrome 擴充功能的重度用戶或深入 Google 生態系統,那麼 Chrome 可能仍然是您的最佳選擇。 ##n8n 與 Zapier:自動化競技場 ![n8n vs. Zapier:自動化競技場](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/au3eybw4auja3m6kjipu.png) 在工作流程自動化領域,Zapier 長期以來一直是家喻戶曉的名字,它幫助企業和個人連接他們最喜歡的應用程式並自動化任務。進入 n8n,這是一個開源替代方案,以其獨特的方法而引人注目。讓我們深入了解 n8n 如何與 Zapier 進行比較。 ###n8n 與 Zapier 相比的優點: **客製化之王**:n8n 是開源的,提供無與倫比的客製化功能。如果您需要特定的功能或集成,您可以自行建立或利用社群來取得協助。這種程度的彈性是 Zapier 等專有平台無法比擬的。 **成本效益**:n8n 可以自架,這意味著您可以節省大量成本,尤其是在執行大量工作流程時。使用 Zapier,隨著您的需求成長,訂閱成本也會隨之增加。 **資料隱私**:透過 n8n 的自架選項,您可以完全控制您的資料。它保留在您的伺服器上,確保您確切知道它在哪裡以及誰有權存取。這與 Zapier 等基於雲端的解決方案形成鮮明對比,後者的資料是在外部伺服器上處理的。 ###n8n 與 Zapier 相比的缺點: **使用者友好**:Zapier 以其直覺的介面而聞名,即使是非技術人員也可以輕鬆設定和管理工作流程。 n8n 以其更面向開發人員的方法,對某些人來說可能有更陡峭的學習曲線。 **海量整合庫**:Zapier 擁有超過 3,000 個應用程式整合。雖然 n8n 的清單正在快速增長,但它尚未達到與 Zapier 一樣廣泛的開箱即用整合數量。 **可靠性和支援**:憑藉其成熟的影響力,Zapier 提供強大的可靠性和專門的支援團隊。雖然 n8n 擁有一個充滿熱情的社區,但它可能無法提供與 Zapier 這樣的成熟平台相同程度的即時、專業支援。 ###結論: n8n 提供了一個客製化、節省成本和資料控制的世界,對於那些習慣更實際操作方法的人來說,這是很難擊敗的。然而,如果您正在尋找一個具有大量即用型整合、用戶友好介面和專門支援的平台,Zapier 仍然是一個強大的選擇。您的理想選擇將取決於您的特定需求和技術舒適度。 ##Webiny:Webflow 和 Framer 的替代方案 ![Webiny:Webflow 和 Framer 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ihuqbo2d9cqmpvorr98.png) 在網頁設計和開發領域,Webflow 和 Framer 等工具因提供直覺的介面和強大的設計功能而聞名。但鎮上出現了一個新的開源玩家:Webiny。 ###Webiny 與 Webflow 和 Framer 相比的優點: **開源彈性**:Webiny 的開源性質意味著您可以根據自己的喜好進行自訂。如果您需要某種功能或集成,您將不會受到專有約束的限制。這種程度的適應性是像 Webflow 和 Framer 這樣的專有平台無法完全匹敵的。 **成本考量**:從長遠來看,Webiny 更具成本效益,特別是對於較大的專案或企業。雖然 Webflow 和 Framer 需要付費,但 Webiny 的開源模型可以節省大量成本,特別是在考慮自架網站時。 **完全控制資料**:透過 Webiny,您可以選擇自行託管,從而完全控制資料及其安全性。這與 Webflow 和 Framer 等基於雲端的解決方案形成鮮明對比,在這些解決方案中,您的資料駐留在外部伺服器上。 ###Webiny 與 Webflow 和 Framer 相比的缺點: **直覺的設計介面**:Webflow 和 Framer 都以其用戶友好的設計介面而聞名。它們提供拖放功能和視覺設計工具,使設計人員即使沒有深厚的編碼知識,也可以輕鬆地將他們的願景變為現實。 Webiny 雖然功能強大,但對於純粹的設計師來說可能有更陡峭的學習曲線。 **豐富的範本和元件庫**:Webflow 和 Framer 附帶豐富的範本、元件和動畫庫。這可以顯著加快設計過程。 Webiny 較新,可能無法提供同樣廣泛的即用型設計元素。 **社群與支援**:Webflow 和 Framer 擁有大型、成熟的社群和專門的支援團隊。這意味著有大量的教程、論壇和資源可供使用。 Webiny 是新出現的,仍在發展其社區和支援基礎設施。 ###結論 Webiny 提供了一個引人注目的開源替代方案,具有客製化功能、潛在的成本節約和資料控制。然而,對於優先考慮直覺設計介面、大量設計元素和成熟社群支援的人來說,Webflow 和 Framer 的綜合優勢仍然難以超越。 ##Penpot:Figma 的替代品 ![Penpot:Figma 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6qbwjeb3qobr4ji0oxpp.png) 在設計界,Figma 因其協作功能和時尚的介面而受到青睞。但有一個開源競爭者走進了聚光燈下:Penpot。 ###Penpot 與 Figma 相比的優點: **開源優勢**:Penpot 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化,而 Figma 等專有平台可能無法提供。 **無成本障礙**:Penpot 是開源的,可以免費使用。雖然 Figma 提供免費套餐,但高級功能和更大規模的團隊協作需要付費訂閱。使用 Penpot,您可以存取所有功能,而無需擔心訂閱費用。 **用於資料控制的自託管**:Penpot 使您可以選擇在自己的伺服器上託管。這意味著您可以完全控制資料、資料的安全性以及資料的儲存位置,這是 Figma 的純雲端模型所不具備的功能。 ###Penpot 與 Figma 相比的缺點: **成熟的生態系統**:Figma 存在的時間更長,並且擁有更成熟的生態系統。這包括一個龐大的插件庫、整合庫和社群貢獻的資源,可以增強設計過程。 **即時協作**:Figma 的突出功能之一是無縫即時協作。多個設計師可以同時處理一個專案並進行即時更新。雖然 Penpot 提供協作功能,但它可能不如 Figma 的那麼精緻。 **性能和可靠性**:Figma 的性能,尤其是複雜的設計和原型,是強大且可靠的。作為一種較新的工具,Penpot 仍在完善其性能並消除任何問題。 ###結論 Penpot 為設計工具領域提供了全新的開源視角,其成本效益和資料控制對許多人來說都很有吸引力。然而,對於那些看重龐大生態系統、即時協作和經過驗證的性能的人來說,Figma 仍然是一個強大的選擇。 ##Dub.co:Bit.ly 的替代方案 ![Dub.co:Bit.ly 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ye97eh00t801zuixzoe8.png) Bit.ly 已成為許多用戶的主要內容。然而,開源社群提出了另一種選擇:Dub.co。 ###Dub.co 與 Bit.ly 相比的優點: **開源彈性**:Dub.co 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化,而 Bit.ly 等專有平台可能無法提供。 **成本考慮**:Dub.co 是開源的,可以免費使用。雖然 Bit.ly 提供免費套餐,但其高級功能和分析功能價格昂貴。透過 Dub.co,您可以存取所有功能,而無需擔心訂閱費用。 **資料隱私和自架**:Dub.co 為您提供在自己的伺服器上託管的選項。這意味著您可以完全控制您的資料、資料的安全性以及資料的儲存位置,這是 Bit.ly 的純雲端模型所不具備的功能。 ###Dub.co 與 Bit.ly 相比的缺點: **已建立的聲譽**:Bit.ly 已經存在很長時間了,並在可靠性和性能方面建立了聲譽。這種長期存在意味著許多用戶信任並熟悉其服務。 **廣泛的集成選項**:Bit.ly 提供與其他平台和行銷工具的廣泛集成,使企業可以更輕鬆地將連結管理納入其現有工作流程。 **用戶友好的介面**:Bit.ly 以其直覺的介面而聞名,使用戶可以輕鬆建立、管理和分析其縮短的連結。雖然 Dub.co 提供了一個強大的平台,但新手可能會發現 Bit.ly 的介面更加簡單。 ###結論: Dub.co 為連結管理提供了全新的開源視角,提供客製化、成本效益和增強的資料控制。然而,對於那些重視具有大量整合和易於使用介面的久經考驗的平台的人來說,Bit.ly 仍然是一個不錯的選擇。您理想的工具將取決於您的特定需求以及您如何優先考慮功能。 ##Cal.com:日曆的替代方案 ![Cal.com:Calendly 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/utln9g2ijnenv4y9d8ub.png) 在安排會議和約會時,Calendly 一直是許多人的首選平台。但有一個新的開源替代方案引起了人們的注意:Cal.com。 ###Cal.com 與 Calendly 相比的優點: **開源彈性**:Cal.com 是開源的,這意味著您可以對其進行自訂以滿足您的特定需求。無論是加入獨特的功能還是與其他工具集成,您都可以自由地打造自己的功能。這是 Calendly 作為專有平台無法提供的。 **成本效益**:Cal.com 對個人免費,並且是開源的,您可以自行託管它以避免訂閱費用。另一方面,Calendly 有免費套餐,但僅限於一種活動類型,並且缺乏一些高級功能,除非您升級到付費計劃。 **資料隱私**:透過自行託管選項,Cal.com 讓您可以完全控制自己的資料。您確切地知道它的儲存位置以及誰可以存取它,而 Calendly 的基於雲端的模型則不然。 ###Cal.com 與 Calendly 相比的缺點: **使用者體驗**:Calendly 已經存在了一段時間,並且擁有精美、用戶友好的介面。即使對於那些不懂技術的人來說,設定和管理約會也很容易。 Cal.com 較新,可能有更陡峭的學習曲線。 **整合選項**:Calendly 提供與 Google 日曆、Office 365 和 Zoom 等流行平台的廣泛整合。雖然 Cal.com 正在努力擴展其整合選項,但尚未達到與 Calendly 相同的水平。 **社群與支援**:Calendly 擁有龐大的用戶群,並提供強大的客戶支持,包括豐富的教學和資源。 Cal.com 作為一個較新的開源平台,更依賴社群支持,但社群支持可能不那麼直接或廣泛。 ###結論: 如果您熱衷於嘗試新事物、喜歡優質的免費贈品並重視保持資料的私密性,請嘗試 Cal.com。但如果您想要一個久經考驗、易於使用且擁有可靠支援的工具,Calendly 仍然是一個不錯的選擇。 ##NocoDB:Airtable 替代方案 ![NocoDB:Airtable 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phokr8123e2qpxge9ix5.png) 您可能已經看過 Airtable,它具有豐富多彩的網格和簡單的拖放氛圍。但有一個新來者正在引起一些轟動:NocoDB。讓我們來分解一下這兩者是如何疊加的。 ###NocoDB 與 Airtable 相比的優點: **開源優點**:NocoDB 是開源的,這意味著您可以根據自己的喜好調整、扭曲和自訂它。另外,您還可以從不斷改進它的社區中受益。空中桌?這很酷,但它並沒有給你那種程度的自由。 **錢包友善**:使用 NocoDB,您可以透過自己託管來避免這些月費。 Airtable 有免費套餐,但如果您想要更多記錄、檢視或精美功能,則需要花費一些現金。 **您的資料,您的規則**:由於您可以自行託管 NocoDB,因此在資料方面您處於主導地位。您可以決定它的儲存位置以及誰可以查看它。使用 Airtable,您的資料將掛在他們的伺服器上。 ###NocoDB 與 Airtable 相比的缺點: **使用者友善的氛圍**:Airtable 超級直覺。它的介面很乾淨,設定基地感覺輕而易舉。 NocoDB 比較新,可能需要更多時間來適應。 **模板寶庫**:Airtable 有大量模板。無論您是計劃活動、追蹤庫存還是管理專案,都可能有一個模板。 NocoDB 仍在建立其集合。 **內建整合**:Airtable 與其他應用程式配合得很好,提供了一系列與流行應用程式的內建整合。雖然 NocoDB 正在擴展其整合遊戲,但尚未達到 Airtable 的水平。 如果您是開源愛好者,喜歡控制資料,並且希望節省一些錢,那麼 NocoDB 可能正合您的胃口。但是,如果您正在尋找超級用戶友好、具有豐富模板庫並且可以輕鬆與其他應用程式連接的工具,那麼 Airtable 仍然很強大。 ##大結論 在不斷發展的數位工具世界中,老牌巨頭和創新的新來者之間始終需要保持平衡。無論是設計平台、調度工具或資料庫系統,每個平台都有其獨特的優點和潛在的缺點。 Penpot、Cal.com、NocoDB 等開源替代方案帶來了無與倫比的客製化、成本節約和資料控制。另一方面,Figma、Calendly 和 Airtable 等老牌廠商提供用戶友好的介面、廣泛的整合選項以及隨著時間的推移和改進而帶來的可靠性。 ##誰說你必須選邊站隊? 當今技術生態系統的美妙之處在於您可以混合搭配。使用開源工具完成一項任務,使用專有工具完成另一項任務。這就像擁有一把瑞士軍刀和一個專門的工具包。您將獲得兩全其美的效果。 例如,您可能喜歡根據資料庫需求自訂 NocoDB,但更喜歡使用 Calendly 進行排程的無縫整合。或者也許 Penpot 的開源靈活性吸引了您的設計方,而 Slack 的可靠性則讓您的團隊溝通順暢。 關鍵是,你並沒有被歸類。這一切都是為了找到適合工作的工具,有時,這意味著將開源精神與專有軟體的精美體驗相結合。 因此,當您冒險進入科技領域時,請記住:這不是選擇立場的問題。它是為了找到讓您的數位生活更輕鬆、高效和愉快的完美工具。潛入、實驗並製作你獨特的科技馬賽克!

回答網友提問:雲科碩畢,上班中,考慮轉職軟體工程師,請問有建議嗎?

阿川收到網友提問如下: > 阿川你好: > 我的背景是雲科碩畢業,算是混上去的,現在打算轉職軟工,由於有在工作,所以打算先以自學為主3-6個月,看情況後決定是否報名資策會。 > 想請問一下,目前比較希望能夠走後端(網頁開發類),查了一些相關資訊,網頁似乎比較友善,未來有機會再往其他產業前進! > 搜尋了一下職務,網頁類的後端其實也需要html css js 前端三本柱。 > 我想問的是: > 1.是否直接開始學三本柱比較好?(反正前面的作品、入職也會需要)且 有了js基礎還能繼續學習node.js(後端)。 不過又礙於可能比較沒方向,會變成說學一學越來越往前端過去? > 2.先以門檻較低的前端入門、入職以後再好好思考想專精哪一端之類的 or 以c#為主學習,再慢慢學三本柱,資料庫等等 > 3.前端的切版技術等等,是否真的必要? 本人美感很差.. 兩個問題的考量的都是想說是否先以java,c#等後端去建立程式概念或許比較好。 > 文有點長,再麻煩您給我一些建議了,也想順便問一下,有看到您有提供免費html css 以及付費js課程,能在跟您要這方面的資訊嗎? 這些問題很好,我一樣公開回答,給類似狀況的人參考。 --- 簡單回答如下: 1、不論前後端 html 跟 css 都要會,所以這兩個可以先學。js 的話後端不用學精,稍微會寫就好,除非你是寫 node 至於最後會去前端或後端的職缺,都可以,先不用擔心這個,不然你就找全端的職缺也可以 2、後端需要學資料庫、基本伺服器管理,語言的話 C# 或 java 或 php 或 python 或 node 之類的都可以 3、前端做久了,因為常常跟設計師合作,會慢慢具備一點設計素養。如果對「UI 設計」有興趣是最好,沒有的話,倒也沒關係。美感可以慢慢訓練,先不用畫地自限 --- 總結來說,我建議你就先學 html 與 css,之後再看你用 html css 把網頁寫漂亮有沒有興趣,如果喜歡把畫面弄漂亮,就多學一點前端。如果只想做工程,就專心在後端吧。這些問題學了 html css 之後會更清楚,先不用太糾結。不然你就以全端為方向也可以,前後端都寫!你就先挑一個免費 or 便宜的線上課程,先開始寫寫看再說 先開始行動,會更清楚自己在做什麼,之後需要花大錢去報名補習班時,也會比較有把握 就算你一開始只寫前 or 後端,很多人上班之後,因為工作需求,還是慢慢有具備全端的技能 其實不用太排斥全端,都寫的話,一來在公司能做的事情變多、能應徵的機會變多,二來還可以自己用業餘時間寫 side project,因為一個人就能做完全部事情,所以會很好玩,也對職業生涯很有幫助 關於我設計的免費 html css 教材,請參考:https://codelove.tw/courses/frontend-beginner 另外,轉職過程會有諸多問題,可以加我們 LINE 群多跟大家討論:https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g --- 以上,簡單分享,希望對大家有幫助!

非同步 JS 訓練一:第1課 ── 認識 callback hell

## 課程目標 - 認識 callback hell ## 課程內容 在一般「同步程式設計語言」中,程式碼執行的順序,就是一行一行跑下來,很容易理解 但 JavaScript 是「非同步程式設計語言」,很多時候,執行順序不是一行一行跑下來 為了讓用戶能持續流暢操作瀏覽器介面,工程師需要在會用到「非同步」的地方使用特殊寫法 最原始、也最單純的做法是使用 callback function,也就是把要在非同步任務結束後才跑的任務,寫在 callback function 傳進去 以 jquery 最原始的 ajax 處理為例 ``` $.get(url, params, (data) => { // do something with data }) ``` 第三個參數,也就是箭頭函式的部份,就是所謂的 callback function --- 當年的前端工程師,在一開始覺得這樣寫沒問題,但是當網頁應用程式越來越複雜之後 發現在需要連續執行多個非同步任務時,會需要不斷傳 callback function 進去更深層 最後導致的結果,就是所謂的「callback hell」!這讓程式碼很難讀、很難維護! ``` $.get(url, params, (data) => { // do something with data to get params2 $.get(url2, params2, (data) => { // do something with data to get params3 $.get(url3, params3, (data) => { // do the final task with data }); }); }); ``` 這樣描述比較抽象,來跟著作業,試著用當年的方式開發看看吧! ## 課後作業 讓我們時光倒轉,回到 2000 年代,體驗一下當時的開發方式 請使用 https://jsfiddle.net/ 寫作業 請載入 jquery 套件,並且用 `jQuery.get()` 來處理 ajax ``` <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous"></script> ``` --- 假設你身為前端工程師,正在開發電商網站 今天,產品經理跟你說,為了提升 UX(用戶體驗) 希望能在網頁上顯示「最近一次的訂單內容」,就像這樣: ``` 尊貴的客戶您好,您上次的消費內容是: 訂單編號:XXX 訂單內容:XXX 訂單金額:XXX 希望這次也能有機會服務您! ``` --- 目前後端工程師提供了三組 API 給你使用 使用當年的 jquery 寫法會像是下面這樣: ### 取得當前登入用戶的資料 為了簡化起見,你不用實作「登入、驗證」等等功能 就當作用戶已經登入了,請直接呼叫這個 API 即可 ``` $.get("https://codelove.tw/fake-api/get-current-user", {}, (res) => { console.log('the current user id is:' + res.data.user.id) }); ``` ### 取得指定用戶的全部訂單 ``` $.get("https://codelove.tw/fake-api/get-orders", { user_id: 1 }, (res) => { console.log('get ' + res.data.orders.length + ' orders'); }); ``` ### 取得指定訂單的內容細節 ``` $.get("https://codelove.tw/fake-api/get-order-details", { order_id: 1 }, (res) => { console.log('the order id is #' + res.data.order.id); console.log('the order content is ' + res.data.order.content); console.log('the order amount is $' + res.data.order.amount); }); ``` - 請依序呼叫這三個 API,來完成這次需要的功能 - 把第一個 API 拿到的 user id 放進第二個 API 呼叫 - 把第二個 API 拿到的最後一個 order id 放進第三個 API 呼叫 - 把第三個 API 拿到的資料,顯示在網頁上 請注意,不要使用現代的非同步寫法,請使用 callback hell 的寫法,也就是: - 在第一個 API 的 callback function 裡面呼叫第二個 API - 在第二個 API 的 callback function 裡面呼叫第三個 API - 在第三個 API 的 callback function 裡面完成最終需要的功能 寫完之後,你應該會看到有三層深度的巢狀 callback 傳遞! 這就有一點悲慘了,有點 callback hell 的感覺! 做出以上功能,你就完成這次的課程目標了!

回答網友提問:38歲工業設計師,想轉職前端,有沒有什麼建議?

阿川收到網友提問如下: > 阿川您好 我是一位工業設計師,最近想轉職前端工程師,但年齡已38,有爬過一些文章大部分是說年齡確實會是就業一個限制但我想這在所有的行業大概都一樣,但同樣的能力和薪水要求如果企業可以用一個20幾歲的又何必用一個快40歲的人也是一個不爭的事實,想請問前輩的看法~ 非常感謝 > 我說明一下想轉職的原因, 1.評估一 下自己的人格特質 喜歡研究、解題(像是在工業設計需要3d建模,遇到建不出來的造型會不眠不休的找答案解出來並且從中得到成就感) 2.有設計美學基礎應該可以替成為前端工程師加分 3.軟體工程師遠端工作的機會較多,這樣找公司比較沒有地域限制 我在這邊寫一篇公開回答跟大家分享,給類似狀況的人參考。 --- 首先,我自己指導過年紀最大的,是31歲私立科大夜間部,原職餐飲服務業,之後順利轉前端。應該很少人比這背景更「非本科」 但我確實沒有指導過38歲的,所以我請這位網友先進我們 LINE 群組跟大家聊聊,裡面一堆工程師&正在轉職的新手 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 我看了一下對話,大家鼓勵、勸退的意見,大概各一半,下面分享我的看法 --- 首先,我認為設計師出身,來寫前端的話,做出來的介面一定「非常漂亮」 站在雇主角度,能雇用這種前端工程師,一定是很難得,何況還是付 junior 的薪水!根本賺到吧! 而且看這位網友的自我描述,感覺是喜歡研究、對細節在乎的人,這是滿適合工程師的特質 所以光論背景&態度,我覺得滿適合轉職前端的,可能上班會被公司凹同時做設計師&工程師 但一開始如果真的找不到工作,就給人家凹個半年一年,可能忍耐一下吧,畢竟有工作經驗&作品集,之後工作會更好找 --- 接著,關於年齡的問題 這不是一個非黑即白的二元問題,沒有說超過30或35就一定不行、來不及之類的 本來就是程度問題,年齡越大就越有挑戰性,我是覺得38還好呀,還是有公司缺人 何況接案公司之類的,甚至本來就流動率高一點,又不是終生雇傭制,只是雇用你工作幾年而已,不會不合適呀 我期許這位兄弟,在新手練習階段,就做一些「超漂亮」並且「設計完成度遠超過一般轉職者」的網頁 這樣絕對會讓面試官印象深刻,這也是你的優勢所在 --- 再來,談一下花費的問題 很多人半路出家,是未滿30歲,拿政府補助去全職補習班 那些補習班自費的話,大概要十萬元 既然你沒有政府補助可以用,請先大量找免費或便宜的教材,先吸收,多試幾份,真的卡關了,再開始挑補習班 我本人就有設計一套「練功作業包」,我鼓勵所有正在轉職者,拿去搭配、練習 https://codelove.tw/courses 我有一些讀者根本沒去補習,光是寫這份作業包,就直接去面試&開始上班了 --- 最後,這位網友在最開始有提到兩件事,我順便說明一下 ### 有設計美學基礎應該可以替成為前端工程師加分 -> Yes,加分,加爆了,這是很棒的技能組合 ### 軟體工程師遠端工作的機會較多,這樣找公司比較沒有地域限制 -> Yes,的確比一般職缺,WFH 的機會多很多,但是,就我觀察,在台灣,遠端彈性大到可以允許你「跨縣市」的公司,沒那麼多喔 通常是混合辦公居多,也就是一星期幾天在家、幾天進公司。所以,這方面不能太天真,請多多打開人力銀行 or 相關 FB 社團,多觀察為主 以上,簡單幾點分享,希望對你有幫助,祝各位轉職順利!

[技術文章] 一篇文章馬上帶你學會JQuery!

## 前情提要 還在問說要不要學JQUERY?別問了,學就對了,沒人說學了一定要用好嗎。 以下讓我們先看一段純純的JS,就跟國中生的戀愛一樣, 牽牽小手,超純。 ## JS純 ``` // 純 JavaScript 選取元素清單 let list = document.querySelectorAll(".navigation li"); function activeLink(event) { // 使用 forEach 迴圈移除所有元素的 "hovered" 類別 list.forEach((item) => { item.classList.remove("hovered"); }); // 在滑鼠移過的元素上新增 "hovered" 類別 event.target.classList.add("hovered"); } // 使用 forEach 迴圈為每個元素加上滑鼠移過事件的監聽器 list.forEach((item) => { item.addEventListener("mouseover", activeLink); }); ``` ## 轉大人 接下來我們要轉大人了。 ### 選擇器 關於querySelectorAll這種querySelector很簡單,JQ都是用$這個字符來選取。 ## 修改class item.classList.remove("hovered"); event.target.classList.add("hovered"); 這兩個的話JQ有寫出兩隻API: removeClass addClass 所以很方便很好用 ## 事件監聽 addEventListener的話JQ則是用on來表達,這個看過幾次就能夠理解了唷! ## JQ的寫法寫出來 ``` // 使用 jQuery 選取元素清單 let list = $(".navigation li"); function activeLink() { // 移除所有元素的 "hovered" 類別 list.removeClass("hovered"); // 在滑鼠移過的元素上新增 "hovered" 類別 $(this).addClass("hovered"); } // 使用 jQuery 的 each 方法為每個元素加上滑鼠移過事件的監聽器 list.each(function () { $(this).on("mouseover", activeLink); }); ``` ## 心得 JQ到底有沒有被拋棄或是需不需要學習,其實都是假議題,一堆人嘴上用JQ,然後嘴砲JQ 我們身為學習者其實就是花個一小時 就能學起來的東西,沒必要故意閉著眼睛不去了解。 以上,一篇文章馬上帶你學會JQuery! 比較想要玩切版可以看這個: https://ithelp.ithome.com.tw/articles/10312922 [【前端動手玩創意】置頂按鈕,老梗經典|帶你的網頁搭電梯](https://ithelp.ithome.com.tw/articles/10312922)

【前端動手玩創意】動態生成的藝術|小心,亂改DOM你可能會被打臉。

## 目錄 ##### [【前端動手玩創意】等待的轉圈圈效果 (1)](https://ithelp.ithome.com.tw/articles/10311621) ##### [【前端動手玩創意】google五星評分的星星(2)](https://ithelp.ithome.com.tw/articles/10311643) ##### [【前端動手玩創意】CSS-3D卡片翻轉效果(3) (今天難度頗高,想挑戰再進來!)](https://ithelp.ithome.com.tw/articles/10311672) ##### [【前端動手玩創意】一句CSS做出好看的hero section!(4)](https://ithelp.ithome.com.tw/articles/10311691) ##### [【前端動手玩創意】創造一個Skill bar(5)](https://ithelp.ithome.com.tw/articles/10311756) ##### [【前端動手玩創意】遮蔽廣告(D卡未登入)腳本、自定義新增名單(6)](https://ithelp.ithome.com.tw/articles/10311999) ##### [【前端動手玩創意】前端canvas截圖的招式!竟然有三招,可存成SVG或PNG (7)](https://ithelp.ithome.com.tw/articles/10312001) ##### [【前端動手玩創意】讓你的PDF檔案更難被抓取(8)](https://ithelp.ithome.com.tw/articles/10312046) ##### [【前端動手玩創意】哇操!你敢信?花式寫todo-list,body裡面一行都沒有也能搞?(9)](https://ithelp.ithome.com.tw/articles/10312056) ##### [【前端動手玩創意】卡片製作,才不是!是卡片製作器!(10)](https://ithelp.ithome.com.tw/articles/10312066) ##### [【前端動手玩創意】太屌了吧!?用Class(類)製作Jquery的效果!(11)](https://ithelp.ithome.com.tw/articles/10312114) ##### [ 【前端動手玩創意】置頂按鈕,老梗經典|帶你的網頁搭電梯(12)](https://ithelp.ithome.com.tw/articles/10312922) ## 前情提要 一陣子沒寫前端動手玩創意了 今天要來點好料的 我們談談關於藝術 對 就算是寫程式我們也是可以有藝術氣息的 別這麼驚訝XD 假設我有一組資料 一般人來說 最直覺的就是把html裡面的元素寫出來寫死 直覺菜鳥就是寫出來啊 ``` <div id="items_list"> <li class="buy_item">1.紅茶 <div class="price">10</div> <div class="del_btn">X</div> </li> <li class="buy_item">2.奶茶 <div class="price">15</div> <div class="del_btn">X </div> </li> <li class="buy_item">3.綠茶 <div class="price">30</div> <div class="del_btn">X</div> </li> </div> ``` 要更新則是就去更改DOM就好了 反正我都學會JS了 有什麼大不了(? 但是現在已經進入大前端時代了就算你寫原生 也會有data model的概念 這部分可以參考站長阿川寫過的好文 裡面的文筆跟邏輯 不誇張 是我見過「華文圈寫得最好的前端教學」 尤其就是這篇 關於data model的介紹 切入點非常的有趣也很有道理 有興趣的自己去花心思讀看看 [認識 data model 與 render function](https://codelove.tw/@howtomakeaturn/post/9xLo5q) 稍微有點料的前端學習者 本身就會寫一寫 想說:既然有一隻API是createElement 那是不是我可以整個html都用js寫出來(? 這是個超級有趣的觀點 ## 關於data render的概念: 「是不是我可以整個html都用js寫出來」 相傳牛頓提出三大定律以後 認為地球和八大行星一開始的慣性力叫「上帝的第一推動力」 實際上這個: 「整個html都用js寫出來」 也是推動前端往框架邁進的思考第一步 可以說是前端慣性的上帝推力了 當然如果你有打籃球 也可以比喻成上籃的第零步XD ## 觀念筆記 ### html程式碼 ``` <div id="buylist"> <h1>myBuylist 購物清單</h1> <div class="buyitem"> <label>產品名</label> <input/> <label>價錢</label> <input/><span class="addbtn">+新增</span> </div> <div id="items_list">這邊準備用JS插入東西所以這段只是說明文字</div> </div> ``` 把整個頁面的元素寫出來 但是資料的區塊保留著 因為等等我們要用JS的API去動態生成 未來直接data render 方便更新與管理 ### JS程式碼 ``` var shoplist = {}; shoplist.name = "購物清單"; shoplist.list = [ { name: "吹風機", price: "300" }, { name: "麥克筆", price: "20" }, { name: "筆記型電腦", price: "29300" }, { name: "Iphone 9", price: "5200" }, { name: "神奇海螺", price: "1000" }, ]; var item_html = "<li id={{id}} class='buy_item'>{{name}}<div class='price'>{{price}}</div><div class='del_btn'>X</div></li>"; var total_html = "<li class='buy_item total'>總價<div class='price'>{{price}}</div><div class='del_btn'>X</div></li>"; var total_price = 0; for (var i=0; i < shoplist.list.length; i++) { var item = shoplist.list[i]; total_price += item.price; var current_item_html = item_html.replace("{{num}}", i + 1) .replace("{{name}}", item.name) .replace("{{id}}", "buyitem_" + i) .replace("{{price}}", item.price); $("#items_list").append(current_item_html); } ``` 這邊值得關注的一點是資料的處理 也就是數據結構上使用物件與陣列去儲存資料 為什麼要學 陣列 為什麼要學物件 這兩個都是抽象的名詞 他們都是為了來處理資料所規劃的兩種不同內容 ## 關於物件與陣列 物件就像是RPG角色 會有很多的屬性 魔法 敏捷 力量 血量 這些屬性都是被附加在person上面 所以person.blood是一個資料 person.power是一個資料 person.magic是一個資料 最後都存在person裡面 這個person就是一個含有很多屬性的物件 感覺就是有血有肉很3D 而陣列就比較平面化 就是很多數字排成一列而已 其實沒什麼特別需要關注的 這兩個也不會不好區分 只要稍微做個比喻 都很好理解 以我們的code來講解 shoplist就是一個物件 含有一些屬性 包含名字與清單 因為清單很多 所以清單用一個陣列儲存 陣列裡面放很多個物件 這些物件就是每一個清單包含的那些購買項目 其實不用太在意誰是誰因為用看的就很清楚 最後我們用迴圈去把shoplist裡面的每一筆資料都丟進去 中途replace是文字處理 把我們設置的{{name}}這種花括號的東西換成真實資料 這部分有點樣板語言的感覺XD 其實非常有趣 很值得玩味 ## 心得 這次比較多實在的JS程式碼 就不只是玩玩切版了 算是有點靠近框架的部分(◉3◉) 動手玩創意這個系列其實靈魂之處就在於「有趣」兩個字 坊間把前端描繪成為了找工作的銅臭味 以及把切版講成無聊的工匠苦力活 我認為都是錯誤的解讀 我認為 只要是有趣的地方就是前端最有價值的地方 而不是誰學了那個框架 誰又認為哪個東西比較厲害 哪個語言比較屌 那都是很無聊的文字遊戲罷了 如果你喜歡這樣子的前端 請跟著這個系列繼續走(→ܫ←) 我們才只是在桃花源外的小溪旁玩水而已呢! 未來會往天空飛翔哦XD

[自修資源] 還在六角學院?誰跟你說學程式,一定要花錢買課?

## 前情提要 本文跟六角學院沒有任何關係XD ## 文章開始 今天要討論自學,關於線上課程,我認為買一些課是好的,但別傻傻看了促銷就買。 誰跟你說學程式一定要花錢? 告訴我,誰跟你講的?就是賣你課的人啊傻子。 . . . 我今天這篇文章要教你怎麼免錢學程式,而且是有系統的學,不是自己在那邊維基百科或谷歌一百年那種。 答案是:爬文。 . . 好啦我知道你們這些伸手牌就是懶得爬文所以才會想要花錢了事,今天我爬完了。 ## 好料放送(一) 把免費資源直接丟給你吧。 [「Python 網路爬蟲與資料分析入門實戰」範例程式碼](https://github.com/jwlin/py-scraping-analysis-book) ![](https://i.imgur.com/8tT3GaY.png) 裡面包含 ``` 網頁爬蟲範例實戰 3-1 PTT 八卦板今日熱門文章 3-2 Yahoo 奇摩電影本週新片 3-3 兩大報當日焦點新聞 3-4 Google 搜尋股價資訊 3-5 Dcard 今日熱門文章 ``` 所有書本裡面的程式碼作者都直接公開了,我也不知道為什麼,反正就是免費給你。 現在你也不用自己google研究,直接複製丟到GPT那邊寫一個教學文章給你, 你就等於能夠免費讀到這本書。而且不用手打程式,你最愛的那種。 ## 好料放送(二) ![](https://i.imgur.com/MTppdAD.png) [hahow 線上課程: Python 網頁爬蟲入門實戰](https://github.com/jwlin/web-crawler-tutorial/tree/master) . 同一個作者丟出來的,總之既然人家想放github那就看啊! 用法也是一樣,人家有個lecture可以看看課綱與大致上的說明自己去配上GPT以及谷歌, 然後不需要自己打扣,直接有現成範例可以拿去跑看看,年代問題導致的錯誤還可以當作功課自己改。 . . . ## 總結 還在靠北沒資源或是一直問要怎麼自學?現在告訴你了, 這樣的教材原本他起碼都賣幾千塊,你可以免費學幹嘛不學? 別問我怎麼知道的,我也是爬文爬到的,只是我人很好分享給你們知道而已。 . . 謝謝,別那麼感動。 . . 我也只是一個很愛免費白嫖的爬文仔而已。

後端 JS 訓練二:第5課 ── 處理 url 參數

## 課程目標 - 使用 node 與 express 處理 url 參數 ## 課程內容 在瀏覽網站的時候,點擊不同頁面時,有時需要透過 url(網址)附帶一些參數 這課來學習如何用 node 處理 url 參數 替這課建立 lesson5 資料夾,內容跟 lesson4 一樣即可 在 index.js 加入這段程式碼 ``` app.get('/view', (req, res) => { const data = fs.readFileSync('./lesson5/users.json'); const users = JSON.parse(data); const index = req.query.index; const user = users[index]; res.send('<h1>' + user.name + '同學,你好!</h1>'); }); ``` 然後把 hello.ejs 的內容修改成 ``` <div> <% for(var i = 0; i < users.length; i++) { %> <p> <%= users[i].name %>同學,你好! <a href="/view?index=<%= i %>">單獨打招呼頁面</a> </p> <% } %> </div> ``` 然後去終端機輸入 ``` node lesson5/index.js ``` 接著打開瀏覽器,在網址輸入 ``` http://localhost:3000/ ``` 你會看到每段訊息旁邊,多了一個單獨連結,點下去,就會到單獨打招呼頁面! 操作看看吧!試試看「透過網址傳參數」的感覺! --- 在 http 協定中,網址中出現問號 `?` 代表後面的部份是參數,參數的值應該可以單獨被抓出來 前面說過 `(req, res)` ,很多人會寫 `(request, response)`,兩者意思一樣,就是在 express 中代表請求&回應的物件 這邊是我們第一次使用「請求」物件!我們在請求物件中,使用 `req.query.index` 找出名為 `index` 的參數 然後在首頁,透過迴圈,加上每個單獨頁面的連結,通通使用 `index` 作為參數傳遞 --- 實務上,開發後端應用時,只要是 http get request,有時會透過網址本身代表參數,例如 ``` /view/1 /view/2 /view/3 ``` 有時會透過 url parameter 傳遞參數,例如 ``` /view?id=1 /view?id=2 /view?id=3 ``` 這是一個主觀偏好問題,其實都可以!效果也差不多 這兩種寫法,在各種程式語言中,處理起來有點不一樣 本課就以 url parameter 作為示範,先照做即可,別擔心! ## 課後作業 這次要開發「閱讀單篇文章」的功能 並且練習 url 參數的傳遞&取得 請把 hw4 的內容複製到 hw5,然後增加 view.ejs 檔案 ``` /repo /hw5 /index.js /homepage.ejs /view.ejs /posts.json /public /style.css ``` 修改部落格首頁,替每篇文章加上 <a> 超連結,點擊之後會前往單篇文章的網址 舉例來說,第一篇文章的網址會是 ``` <a href="/view?index=0"> ``` 第二篇的網址會是 ``` <a href="/view?index=1"> ``` 第三篇的網址會是 ``` <a href="/view?index=2"> ``` 接著修改主程式 index.js 的內容,讓網站能夠回應 `/view` 這種網址 然後根據從網址取得的索引參數,找出 posts.json 中對應的文章資料 接著把資料放進 view.ejs 模板中,回應顯示為網頁 請自行設計 view.ejs 的內容,簡單顯示一篇文章內容即可 請稍微加上一點樣式,弄得漂亮一點! 完成以上任務,你就完成這次的課程目標了!

後端 JS 訓練二:第4課 ── 提供靜態檔案

## 課程目標 - 使用 node 與 express 提供靜態檔案 ## 課程內容 目前為止的網頁,都是純 html,太陽春了! 這一課來學習,如何用 node 來提供 css 或圖片之類的「靜態檔案」! 替這課建立 lesson4 資料夾,內容跟 lesson3 同樣之外,再建立一個 public 資料夾,裡面新增 style.css 檔案 ``` /repo /lesson4 /index.js /hello.ejs /users.json /public /style.css ``` 在 index.js 裡面多加一行程式碼 ``` app.use(express.static('./lesson4/public')); ``` 在 style.css 裡面加入一些樣式 ``` p { color: green; } ``` 接著在 hello.ejs 加入樣式連結 ``` <link rel="stylesheet" href="/style.css"> ``` 然後去終端機輸入 ``` node lesson4/index.js ``` 接著打開瀏覽器,在網址輸入 ``` http://localhost:3000/ ``` 你會看到原本的打招呼訊息,文字變成了綠色! --- 後端程式設計,不論何種程式語言,在提供圖片、css 這種靜態檔案的時候,通常會開一個獨立的 public 資料夾來放檔案 所以本課使用的 `app.use(express.static('./lesson4/public'));` 程式碼 就只是設定一下,請 express 從某個資料夾提供靜態檔案,就這樣而已! ## 課後作業 這次要練習用 node 回應靜態檔案 請把 hw3 的內容複製到 hw4,然後增加 public 資料夾與 style.css 檔案 ``` /repo /hw4 /index.js /homepage.ejs /posts.json /public /style.css ``` 請在 style.css 中,稍微替你的日記首頁加一些樣式,弄得漂亮一點! 完成以上任務,你就完成這次的課程目標了!

後端 JS 訓練二:第2課 ── 使用 ejs 模板渲染出 html

## 課程目標 - 使用 ejs 模板渲染出 html ## 課程內容 上一課我們成功讓後端回應 html 給瀏覽器了,很棒 可是每次都讓 res.send 回應一大串 html,就太奇怪了 至少要讓 html 內容放在單獨一個檔案,才有寫網頁的感覺吧! 這課來學習如何做到這點吧! --- 來安裝一款新套件,請在終端機輸入 ``` npm install ejs-locals ``` 替這課建立一個資料夾,然後建立一個 index.js 檔案與一個 hello.ejs 檔案 此時資料夾會長類似這樣 ``` repo ├── package.json ├── package-lock.json ├── node_modules ├── lesson1 │   └── index.js └── lesson2 ├── hello.ejs    └── index.js ``` 在 hello.ejs 放入以下內容 ``` <h1>恭喜您,成功囉!</h1> <h2>您真的做得很棒!</h2> <p>繼續學習,不斷進步吧!</p> ``` 然後在 index.js 放入以下內容 ``` const express = require('express'); const app = express(); const engine = require('ejs-locals'); app.engine('ejs', engine); app.set('views', './lesson2'); app.set('view engine', 'ejs'); app.get('/', function(req, res){ res.render('hello') }); app.listen(3000); ``` 然後去終端機輸入 ``` node lesson2/index.js ``` 接著打開瀏覽器,在網址輸入 ``` http://localhost:3000/ ``` 你會看到一段打招呼訊息! --- ejs 是 javascript 社群常用的一款「模板引擎」套件 我們不是直接安裝 ejs 套件,而是安裝 ejs-locals 套件,這是一款把 ejs 整合進 express 的方便套件! 在載入 ejs-locals 之後,接著用 app.engine 告訴 express 我們要設定模板引擎 然後用 app.set 告訴 express 要去哪邊找到 `模板檔案` 最後,處理 http 請求的地方,把原本的 res.send 改成 res.render 並放進模板檔案名稱,就可以囉! 多看幾眼這段程式,這就是後端開發,用 node、express 來讀取一段 html,並且回應給瀏覽器的方式,不難吧! ## 課後作業 這次要練習使用 ejs 模板 請新建立 hw2 資料夾,採用以下結構 ``` /repo /hw2 /index.js /homepage.ejs ``` 並開發一個 app,打開首頁 `http://localhost:3000/` 會顯示 homepage.ejs 的內容作為部落格首頁,homepage.ejs 的內容先放這些 html 就好: ``` <h1>我的個人日記 APP</h1> <div> <h2>第一篇日記</h2> <div>今天天氣很好,夏天太陽很大,讓我心情很好</div> </div> <div> <h2>第二篇日記</h2> <div>早起出門運動,回家沖個澡,整天心情很好</div> </div> <div> <h2>第三篇日記</h2> <div>下大雨一整天,整天在家追劇,滿舒服的</div> </div> ``` 完成以上任務,你就完成這次的課程目標了! --- 請更新你的 github 專案內容,此時應該變成這樣 ``` /repo /hw1 /index.js /hw2 /index.js /homepage.ejs ``` 依此類推,之後就這樣交作業!

回答網友提問:需要在意框架背後幫你做了哪些事情嗎?可以永遠不去管嗎?

收到網友提問如下: ``` 這是最近跟一個朋友聊天聊到的 朋友是寫 .net Framework 的 我剛碰Vue的時候,跟他說我看不懂Vue在背後是怎麼運作的、為什麼這樣寫會變成這樣的結果? 他跟我說,不用去在意框架背後幫你做了哪些事情 反正就是做那些制式的動作,把功能實現就好 不然工程師哪有那麼多腦力去記住程式底層都做了什麼 這樣真的是好的嗎? 工程師的等級差距並不在於是否知其所以而不知其所以然嗎? ``` 這應該是每個年輕工程師都有的疑問,寫一篇完整、公開回答跟大家分享,給類似狀況的人參考。 我先講結論:這取決於你想不想越變越強、不斷提升競爭力,還是只想混口飯吃 如果只想混口飯吃,什麼工具都是學個用法,懶得研究,然後東西做出來交差了事,那可以永遠不去管工具背後原理 不過,這種心態,職涯成長、薪水成長空間會很有限,然後在 40 多歲的時候會有「中年危機」,會很慘、壓力很大 因為屆時新工具你跟年輕人一樣不太會用,舊有的經驗又幫不上忙,因為你從來不肯學背後通用的觀念 回到問題本身,我認為有兩件事情值得分享,有兩個觀點你需要去權衡,我們先談談「抽象」 # Abstraction 抽象 軟體工程師的主要工作就是「抽象化」,把各種邏輯分不同層次「封裝為抽象」 這樣才有重用性,別人才能基於你的成果,進一步開發更豐富的東西 網路的七層架構,各種協定,程式語言,語言上面的工具、套件、框架,都是抽象 # The Law of Leaky Abstractions,抽象滲漏法則:除非無關緊要,否則所有抽象都或多或少會滲漏 這是在軟體圈知名的一個理論,稍微資深的開發者都應該要知道這篇文章 https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ 我簡單說明一下,抽象滲漏法則就是在說:所有抽象都一定會在某些情境下失效,此時便是滲漏。 你只要工作時間夠久就會知道,長遠來說,你還是要花時間去研究它抽象背後的東西。 你本以為只是前端隨便寫一寫交差,卻發現有一天需要認真去看 HTTP 協定、CORS 在講什麼,否則無法處理資安問題 你本以為只是後端 CRUD 隨便寫一寫交差,卻發現有一天需要認真去看 database 索引機制、記憶體管理,否則無法處理效能問題 結論:「抽象」幫助我們省下一些工作的時間,但關於技術細節的學習時間,無法省下來。 # 你的生產力要對公司商業產值有幫助 我認為工程師常常在另一個方面犯錯,就是鑽研自己喜歡的細節,不去管對於公司的商業產值與個人生產力 我曾遇過公司要求協助更換一張網頁圖片,某工程師居然兩個星期還沒更換完成 問他原因,原來是他看圖片尺寸不順眼,在研究分割、壓縮、整個網頁的整合機制,以及相關工具的導入 問題是,那個網頁跟圖片並不重要,此時專案還沒進到效能優化的階段,此功能應該盡快上線,視情況決定下一步 這完全是沒搞清楚優先順序,只顧著研究自己爽的東西,也沒跟相關人士確認任務目標 # 結論 回到原 po 的描述 ``` 不然工程師哪有那麼多腦力去記住程式底層都做了什麼 ``` 這是大錯特錯,隨便找一個優秀的資深工程師,從 Vue 到 React 到各種工具,背後原理、相關機制,都能深入淺出跟你說明 什麼 shadow DOM / virtual DOM / pure function / fiber tree / proxy / immutable 等等,就算好幾個月不碰工具,還是能輕鬆解釋,根本不是死記硬背的,這全都是經驗&融會貫通的結果 但是過猶不及,不顧公司需求,自顧自地研究技術細節也不好 該花多少時間研究背後機制?這是一個需要權衡的問題 請從公司需求的角度,以及個人長期職涯的角度,視情況判斷 以上,簡單分享

回答網友提問:26歲無經驗、高職畢,先去讀個二技 vs 直接補習轉職?

阿川收到網友提問如下: ``` 哈囉站長你好 我目前有在看蓬蓬的自學影片跟寫你分享的練習題 有件事想詢問一下我目前快26之前的工作經歷跟軟體一點關係都沒有 高職畢業 目前在自學一些程式語言的技能 如果未來要朝這個方向走建議我先去讀個二技相關科系補學歷嗎? 還是直接找線上課程或補習班轉職謝謝 原本的打算是想說上二技假日進修補個學歷順便幫自己打底 因為網路上看到蠻多分享是上完課後基礎理論不好 想順便詢問一下沒有學歷的話對未來的工作發展影響大嗎? 還是學歷只是初期比較看待後面看能力這樣子 ``` 寫一篇完整、公開回答跟大家分享,給類似狀況的人參考: # 不建議回學校補學歷 回學校補學歷真的太花時間了,動輒數年以上 何況入學之後還未必喜歡學校、未必喜歡寫程式 業界很多人也是「學歷普普且無經驗」自學4-9個月後,半路出家轉職成功 不論是金錢 or 時間成本來說,都應該先這樣試試看比較保險吧 # 很多人半路出家之後覺得自己底子不好 本科&非本科,基礎一定有差 但是現在網路資源、書本資源很多 寫網站不是什麼需要博士學位的「太空火箭科學」 工作上缺哪方面,就往哪方面慢慢自己補充,且戰且走也還夠用的 這行業根據職位狀況,難度可深可淺,一開始先負責較簡單的網頁工作也行 發現自己底子不好,趕快花業餘時間,大力自修一下呀 甚至先入行之後,週末再去學校進修,都比較保險吧 # 學歷對未來工作影響大嗎 學歷好看的話,當然在職場上有優勢 但如果態度不專業、工作多年還是沒什麼作品集,那也很難當工程師吧? 反過來說,學經歷不強的話 如果態度積極,作品集擺開在那邊,就算不是「超猛」的作品,也讓人知道這工程師有基本的「戰鬥力」呀 更不用說,如果積極貢獻社群、Github 專案有一堆星星,這種時候誰會管這工程師的學歷? 所以這題的答案是:學歷出色還是很吃香,但也還好啦!畢竟軟體工程這行,偏向「實力主義」,很難靠「關係」或者當「花瓶」或者「辦公室政治」就能混得出色 # 不建議直接跳進去補習班 另外我也不建議直接跑去需「全職上課」半年左右,學費十萬以上那種實體補習班 首先,班上同學程度不一,如果你稍微沒跟上進度,後面老師在講什麼就聽不懂,這樣花了大錢、時間,學習效果也不怎麼樣呀 我建議先大量找免費或便宜的教材,先吸收,多試幾份,真的卡關了,再開始挑補習班 先直接找一些作業跟專案寫寫看,從免費 -> 便宜的 -> 稍貴的,這樣一點一點花錢,風險比較小 更認識自身需求之後,再去比較市面上的各種補習班,最後再把這錢花下去,比較保險 事實上,也有很多人,最後根本沒去補習班,只靠著免費&便宜的一些資源,就直接順利轉職的呢! # 結論 這行學無止盡,就算台大畢業,工作十年經驗,還是一直在不斷自學寫程式的奇妙&精益求精 另外,我也有設計免費的 html&css 教材,還有便宜的 javascript 教材,內含「大量練習專案」,不論你最後選擇哪種學習方式,我都推薦搭配拿去學習、練習,稍有難度,但不少人全做完之後就順利面試上班了 以上,簡單分享個人看法

分享職場小菜雞所遇到的狀況

感謝站長關懷~ 是的,這禮拜確實有遇到一些之前有稍微碰過卻不太熟悉的東西,也有之前沒有碰過的東西,是有些小崩潰...,但還是可以稍微跟大家分享與請教一下: 這裡有一些前期提要:公司目前的前端開發並不使用現在的主流前端框架,也沒有使用打包整合工具...(像是Webpack、Parcel這類的),JS使用JQuery,並且將JS檔案一個一個的引入網頁中。 ## 遇到的問題1 :CSS樣式問題 過去在自學的時候其開發方法是:在本機開發,然後在處理樣式與RWD時就是開啟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; } ``` 但這樣如果把每一個樣式的預設值全部強制歸零,可能會導致有些樣式到後來要重新寫,或許Normalize可以只是單純地減少差異(也是因為網路上有人已經整理好了XD). ## 遇到的問題2 :API串接 過去我自己練習串接API的方式實在是相當簡易,我拿的是中央氣象局開放資料平台的API,所以之前很簡單的一行fetch就拿到資料了,毫無難度哈哈哈,但第一天公司需要我去切幾個版面並且串接運輸資料TDX的資料,恩...我一開始不知道要如何在JS中塞入登入資料並且拿回Token的方式.以及我要查詢的數值該如何發出. ###到這裡可以跟大家分享的以及向各位請教的: 這中間我摸索了fetch的一些選項設定,這應該也適用其他的非同步請求方法,例如ajax、axios(這兩個我還沒用過,後續應該會來摸索一下axios),包含請求方法(method),header與body中的內容設定等等. 至於API該如何塞入a頁面填入查詢參數並且跳轉到b頁面顯示查詢解果,在沒有前端框架全域狀態管理的支援下,這邊則是摸索了encodeURIComponent以及decodeURIComponent這樣的函式,將要查詢的參數在a頁面進行編碼並丟入到URL中,跳轉到b頁面後再進行解碼.並fetch我要的資料.最後是有成功的,只是覺得自己像薪水小偷哈哈哈,效率並不高. 這個方法感覺並不建議應用在需要輸入有個人資料的內容中,因為編碼的方式是雙向的,資料可以編碼也可以解碼,所以....像個資這類的內容就應該不建議塞在URL中用這種方式傳輸.至於要用什麼方法,這也是我想知道的. ## 遇到的問題3:不同裝置的問題 這個並非第一個樣式的問題,而是我目前覺得還沒有解的問題,就是我在網頁中需要獲取使用者的位置,因此用了navigator.geolocation 這個API,但神奇的是,在本機中都可以抓得到資料,打開Dev Tools檢查回傳的狀態碼與經緯度也都是沒有問題,但是在手機中雖然會顯示是否能夠取得使用者位置的提示,但按了同意後卻一直無法獲取資料,而且尷尬的是,我無法在手機中打開Dev Tools,所以我也不知道問題發生在哪....,過去有使用過navigator.geolocation 好像也沒有碰過這樣的問題 想跟各位請教的是,有什麼方式可以查看手機上的問題嗎? ## 遇到的問題4:不同的開發方式 這個是我自己很好奇的,雖然說我知道Vue是漸進式框架,但我卻不知道該如何漸進.我理解的漸進式是,有些頁面或元件可以自行選擇要不要使用Vue開發,還是這個漸進式的意思是可以自行選擇要使用多少Vue的套件工具呢(像是要不要使用Vue Router or Vuex). 會這樣問是因爲,假如現在有一份專案一共是十個頁面,我被分到了其中五頁,另外的同事則是負責另外五頁,誠如開頭所說,假如公司既定的開發方式並不使用框架與其他整合工具,我有可能使用框架進行開發並與之合作嗎?還是我這是一個很奇怪的問題,本來就應該要統一一個開發方式? --- 感謝看到這邊的各位,以上有些觀念上是我這位小菜雞自己摸索的,是可能不是正確的(例如有些函式、工具的用途或使用情境),因此歡迎大家指教與討論,這是我這禮拜可以跟大家分享的啦. 謝謝~~ --- PS:我自學八個月的時間有摸了原生JS、CSS、Vue.js、Tailwind、SCSS這樣的工具,本來我是很想要在第一份工作多了解與強化上述工具以及多人開發GitHub的部分,我了解這些終究只是工具且我自己也沒有到非常熟,只要可以完成專案目的即可,我的實力在哪裡我也知道,但以目前公司的開發模式來說,我需要考量沒有踏上趨勢的這個問題嗎?還是我多慮呢了?