good 寫得不錯 整體配色＆設計美感也不錯 繼續保持
very good
1. 通常來說 前後端會一起先討論出 api 的內容 有了規格之後 前後端就可以分別各自開發 最後再串起來就好 2. 或者是後端直接先設計好 api 把文件交給前端 接著前後端就可各自開發 3. 比較需要前後端共同確認設計細節的 api 可以開個 hackmd 或者 google doc 同步編輯 都看過之後再各自開發 4. 更多人協作的場景 可以考慮用 Swagger 之類的工具 先產生文件與 fake api 串接 5. 如果有足夠經驗 使用 GraphQL 技術也會很好 文件、測試面板 都會同步自動生成 6. 其實 你的狀況 聽起來是團隊彼此是否互相尊重的文化問題：後端成員普遍懶得理前端人員 懶得管你工作方不方便。因此 你需要讓技術主管知道這個情況 並且協助改善工作流程 不然的話 很沒效率 7. 如果團隊真的有互相卸責的文化 那麼在你發現有 api 缺漏之類的狀況時 請用 email CC 多人的方式 或是在聊天群組 @多人的方式 留下紀錄 證明時程的延誤不是你的問題。並且 出包的當事人 之後也許會自動改善合作態度 8. 大家都是專業人士 將心比心的話 其實通常不會讓人有難合作、溝通沒效率的感覺。不過 你也要盡量反應狀況 讓人知道你遇到問題或者有某些需求 否則 說不定大家都很滿意 只有你覺得有問題 9. 如果已經回報狀況 但是技術主管拒絕協助改善 那麼這個團隊的工作效率低落 並且主管沒有能力改善 可以考慮離職 --- 以上 參考看看
1. 工作上有混亂很正常 2. 不用離職，繼續在工作上學習即可 3. 對公司來說，一團混亂之後，還是有點進度即可 4. 對你來說，一團混亂之後，還是有學到點東西、薪水正常領即可 5. 你是經過面試流程入職的，如果在職位上無法順利工作，公司負擔50%責任，不用想太多
很好的提問 簡單寫一篇分享我的觀點 https://codelove.tw/@howtomakeaturn/post/837jVx
我在論壇上看到有人發問：免費提供網頁 對方賺得網站 我賺得經驗 這套流程可行嗎？ https://codelove.tw/@JsLover0018/post/n3VdEq 我認為很多年輕的工程師可能都曾有過類似念頭 今天分享幾點個人看法 --- 先講結論，我認為這是一個餿主意，基本上是在浪費時間 只有在很少的情況下可以考慮。大多數情況下，絕不應該免費提供你的專業 ## 免費背後釋放的訊息 從原文的案例來看，網站會是這些店家的重要門面、品牌的一部份、甚至影響銷售流程 所以這件事影響很大，並且後續可能需要定期更新、維護 我舉個比較生活化的例子 你今天對自己的牙齒排列不滿意，想找人矯正 有位無牌照的素人來跟你推銷：牙齒矯正這塊我有在自學，技術我大概都了解，我免費幫你矯正，你讓我賺得經驗，好嗎？ 我認為 99% 的人都會拒絕，寧可花10-30萬找人矯正。但明明是免費，為什麼拒絕？ 因為這會對個人外表有巨大影響，而且需要後續維護，誰敢這樣把案子給你？ 免費，背後同時也釋放一個訊息：我沒把握、我沒自信、我缺經驗、我缺案子、並且後續要不要維護全看我心情、並且你永遠不能說我有誠信問題、也不能告我，因為我沒收錢，而且我一開始就講清楚了 釋放這樣的訊息，導致大多數接觸的客戶都興趣缺缺，並不意外。 你可能想說，我不一樣，我真的願意不收錢、並且把事情做好 那麼你願意簽合約嗎？「甲方支付費用0元。如果乙方後續產出，不符合下列規格要求，乙方賠20萬元。之後每年維護費用也是0元，如果不符合下列條件要求的更新頻率，每年乙方再賠3萬元」 這樣的合約太欺負人，不可能有人簽。老實講，在民法上能不能這樣簽我都很懷疑 ## 消費心理學 vs 經濟學 再講一個，普通人比較難想像的東西 絕大多數人現在思考買賣，會依靠他們在公民課、或者經濟學課上學到的東西 供需關係決定價格、價格越低銷量越好、價格越高銷量越差 然而，一個實際做過銷售、做過生意的人會發現，根本不是這樣 完全一模一樣的產品或服務，在其餘條件都不變的情況下，你把價格從原本的 $299 改成 $99 你用經濟學思考會以為：價格變低、銷量變好，相乘之後，總體銷售額可能更大或更小 但實際上很可能銷量反而更差，總體銷售額就是變差而已 同理，你把價格從原本的 $299 改成 $499 你用經濟學思考會以為：價格變高、銷量變差，相乘之後，總體銷售額可能更大或更小 但實際上很可能銷量完全沒減少，甚至提高，總體銷售額就是更賺錢而已 為什麼？這就是消費心理學、消費行為 對於任何業務、銷售的從業人員，可能都不會意外 但是大多數普通人可能比較難想像、遇到了會深感訝異 定價的設定、如果再加上相關服務內容項目、用字遣詞的調整，影響程度會更大 ## 結論 如果是有親戚朋友、或者熟悉的同事介紹，真的有人沒預算、但又有網站需求 我認為是可以免費幫人做一些簡單的網站，累積一些經驗、作品集這樣 但如果要用免費為主打，去主動業務開發 我認為不太可行 那到底如何銷售？如何經營個人品牌？如何進步到有自信去標準收費、標準服務？ 這些都需要慢慢研究，這也是做生意有趣、有挑戰性的地方 請記住，做生意就是，慢慢去弄清楚市場需要什麼、顧客在想什麼的過程 你自己以為怎樣，或者以為什麼對客戶有價值，那都是你以為而已，你的想法並不重要 這是一個需要放下自尊，視野要清晰、需要時間的過程 像原 po 這樣花時間跟多組客戶嘗試，然後失敗的經驗很好，就是學習的一個過程 持續改善銷售能力就對了，做 sales 跟做 coding 說起來也是一樣，trial and error 以上，簡單分享，祝你很快開始接到幾個案子！
這篇作者強烈偏好 promise 並排斥寫 async/await https://uniqname.medium.com/why-i-avoid-async-await-7be98014b73e 留言區有清楚的相反論點 不用對這議題有特定立場，但就是要知道注意事項： **即使語法看起來像同步 code，也要知道背後是非同步 code，不然遲早會出問題**
歡迎最近新註冊的用戶 @id3p6688 @katiewilson8210 @linejkf552 @tws9666 @8945689 @swotoutty @leemotseng @bear645 @jf76501 @assdee @kk00336 @Adjutle @imxp978 @jeff858484 @ytb0315 @Iven10252158 @AppleLily @wmw588ss52 @Weboai @1891722 @react @cian1223 @dd2d2d41 @vincentchen0606 @slinexm594 @sunmoonsky @reelvetut @4000889 @HansChang83 @wsx1688 @zc235475 @jensen @idziq888 @s1s2s4s5h @Imardaxia @vidmateApk @Skylar0628 @z2837777 @pikashowsapk1 @instaproapps @Vidmateapp @pon0620 @PikaShow23 @Excarrath @tenkai0812 @ScottX8 @Hannahdrorn @Learn20240303 @simon5537 @arielh1004 @hhkwe1 @line771554 @kinemasters @kgi-design-team @doochulk @pdmod @Cartinson @futemaxapk @av0988 @kinemastersapk @Taulinip @rectvindir @rhwang @Chengyi-Lin @nfc851026 @lanni0619 @max002215 @lline966757 @Luckypatcher1s @gary880306 @zzliou @hdstreamzapk03 @PinoyLambingan @aaronzhan0906 @lu4707xeop @Mia1314echooo @TsuPeiHo @roynitisha29 @ovallyfef @qun18009 @nozomi @Aaron @Filmy4WapAPK1 @lu10510 @joeyoldbar @prochini @Yutai @sherry860722 @hzf9Nf5P @yunie0216st @pikashowshd @Kuo-TingKai @alexwu @chelsea22222 @zoetanghk852 @MagicBenson @xd890872680 @Nehaambore01 @Note @shabazsayyed @1084926 @kenni1107 @0711kps @Shuntw6096 @capcutt @TopFollowAPK @YICHI1018 @kaede1904 @HxVfHNMpK @universitykart0101 @pikashowapks @ishad1 @GustavoFringgg @skrbomb @Luckypatcherapk @wwertytrd3 @av9397 @Asn66 @MarioooooLin @snapptube891 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
之前推出的春節全面鼓勵自學活動，今天告一段落囉！ https://codelove.tw/@howtomakeaturn/post/rqED0a 希望有幫助到一些朋友，認識到 web 開發的樂趣！ 也歡迎還沒寫完的朋友，把一些沒寫完的組合包，購買起來、繼續寫完！ 祝大家新年一切順利、Happy Coding！
收到 FreeCodeCamp 電子報 大吃一驚 豐富內容 而且免費 ## Learn Generative AI in 30 Hours https://www.freecodecamp.org/news/learn-generative-ai-in/ ## Google Gemini Course for Beginners https://www.freecodecamp.org/news/google-gemini-course-for-beginners/ ## Azure AI Fundamentals Certification (AI-900) 2024 UPDATE – Pass the Exam With This Free 4 Hour Course https://www.freecodecamp.org/news/azure-data-fundamentals-certification-ai-900-pass-the-exam-with-this-free-4-hour-course/ 真是相當佩服背後經營的團隊，太佛心 改天想更了解生成式 AI，一定要讀一讀
這文章很有趣 https://mp.weixin.qq.com/s/vL5NSp3W-974Szn32uhvsA C++ 社群遭點名不安全，社群也出面辯解
今天在 reddit 看到一則貼文 https://www.reddit.com/r/webdev/comments/1b14bty/netlify_just_sent_me_a_104k_bill_for_a_simple/ 某工程師做了一個小網站放在 Netlify 收到帳單 要收一萬美元，因為被 DDOS 他非常不爽，所以貼文問大家意見 大家叫他貼到 Hacker News https://news.ycombinator.com/item?id=39520776 馬上驚動 CEO 出來回覆，把帳單取消 很有趣的故事，被大企業坑的時候，小小的救濟手段
https://www.futurepedia.io/ https://theresanaiforthat.com/ 這兩個網站 分類整理大量ＡＩ工具 對ＡＩ有興趣的話可以慢慢逛 看看目前ＡＩ走到哪裡了
簡易的指南 很有幫助 https://drive.google.com/file/d/1_grQXLHV_SQUmGMdi6dacBZI7seMCzcL/view 可以學一下
最近太多人交作業啦 站長留言通知爆炸，沒空一個一個 review 你們可以單獨發一篇作業文嗎？ 參考以下連結： https://codelove.tw/search?q=%E4%BD%9C%E6%A5%AD%E5%88%86%E4%BA%AB 一來方便自己日後翻找 二來可以一次整理，讓大家一起看看成果～
所謂年後離職潮，應該很多人年後會換工作吧 祝各位跳槽順利 😁 然後很多新人應該工作不到一年，這次是以工程師身份第一次放年假 歡迎分享菜鳥工程師工作心得 😁 祝各位新年快樂 😁😁
歡迎最近新註冊的用戶 @skytsai3321 @eriksun0310 @luumii694 @ertclee @aelgy @FlameOfDeepSea @Berlin @alan880227 @apingbping @yu11 @YouKlike @balduran @joyho @Irene907 @ScottZhuang @imgeorgechou @sdgm00 @YZRay @102-Funny @Trillion6880 @yii016999 @kevin262666 @wjhprince @pon541998 @vvvaty @ioriayaka @Julixku @AspiringYouth @tree @hlajungo @timmy @lenaiou @a27589485 @JUstin0908 @Yif18 @kwks @ht5268 @wzxc02765 @jou924 @ericwalker @zhuolaoda1106 @chloe1026 @Trista @tyty10251 @StevenMa @mesak @fayee1130 @keasdaz1dar8 @XiaoYu @k886279 @a1097562 @h86130 @shih @rjpvtpnmkf @Castella @wq41422827 @sleeppig8 @uyuy989842 @Eason860502 @s80010090 @james81061916 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
過年快到了！相信很多人會趁著過年的空檔，用力自學、進修、變強！ 站長來給大家發放一些練習包！ 即日起～2/24（元宵節），共三週，免費開放全站所有付費內容！ 大量練習包在此 -> https://codelove.tw/courses/frontend-beginner 大家可以在這段時間，挑一些有興趣的章節、自學包，寫一寫作業練習、加強觀念！ 祝大家春節愉快、Happy Coding！
使用 macbook 開發，用 vitest 寫元件測試 在 CI 環境不能跑，出現以下訊息： ``` Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory. ``` 建議做法是刪掉 `package-lock.json` 檔，重新安裝一次 這樣其實失去 lock 檔用來在不同環境維持一致性的初衷了 希望 npm 團隊能早日修理好吧～ refs: https://github.com/vitejs/vite/discussions/15532 https://github.com/npm/cli/issues/4828
查了一下，看到一張圖表 https://npmtrends.com/vite-vs-webpack webpack 快被 vite 幹掉了～ 花時間學 vite 一定值得～
老話一句，站長還是覺得花10幾萬去補習班，風險很高，因為有進度跟不上、老師課太多、過勞的問題 但是完全自學又有點沒方向，還是要有業界人士幫忙、能討論比較好 新的一年，站長決定推出一個新的教練服務 https://codelove.tw/coaching 大家參考看看
我應該在許多地方說過 我會在業餘時間 不斷開發一些 side project 有些是有小獲利的 當然這相當困難，應該說是非常非常困難，有機會再多跟大家聊聊 --- 這邊分享幾個國外社群，裡面都是由工程師獨立開發小產品的一些故事分享 - https://www.producthunt.com/?filters=soloMaker - https://www.indiehackers.com/group/success-story - https://www.reddit.com/r/SideProject/top/?t=month 這些都是我這幾年逛下來，覺得價值最高的社群，分類我也都幫大家挑好了 我鼓勵大家沒事就看看這些老外在做什麼產品 很多都是小小產品，看看人家的文案、靈感、服務內容、還有收入狀況 如果有合適的，模仿一款中文版 or 把領域改一下，做點微創新，也是很不錯的 當然有一些就是唬爛嘴 在賣產品而已 這個大家要自己判斷一下 有機會多交流吧，發文或留言之類的，我都在～ 最好直接到 CodeLove 找我，我回覆比較快～ --- 補充：更多靈感來源 - https://acquire.com/ - https://flippa.com/
看到國外在討論 https://www.framer.com/ 這款做 UI 設計是不是不錯呀？ 台灣有流行嗎？
最近我留意到一件事，在我們工程師閒聊群組 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 常常會出現感情方面的困擾＆討論，令我非常吃驚，因為這是討論 coding 的群組 但是這個話題出現的頻率相當高，我發現這似乎是「年輕單身男性軟體工程師」相當關心的一個話題 站長畢竟年紀稍大一些，比群組內很多人多活了幾年，是有一些建議，雖然跟 coding 無關，但還是跟各位開發者簡單分享 ## 姿態永遠不要放太低 這點就跟業務在做銷售時一樣，你心裡再怎麼想成交，也絕對不能用超低姿態、苦苦哀求拜託對方成交 過低的姿態會釋放「很缺」的訊號，任何人都會心想「這產品很沒價值，所以業務才姿態這麼低，千萬不能買」 同理，「年輕單身男性軟體工程師」似乎在感情上有成為「舔狗」的傾向，請避免這樣做，絕對只有壞處、沒有好處 如果你真的很想疼女生、找一個女生對她好，我建議你多帶你媽出門走走，週五下班幫你媽多買一份點心、宵夜、禮物，有空多陪你媽聊天即可，就不用擔心都沒有女生陪你聊天 ## 注意力放在自己身上 下一個問題是，姿態很低，背後是源自於缺乏自信 這點我們先談一件事，在網路創業圈，有一句話叫做「Attention Is The New Currency」，注意力就是網路世界的現金 你把注意力放在社群網站，這些網站企業就更有錢；你把注意力放在 IG 網美，這些 IG 網美就更有錢 你把注意力放在哪，會決定誰將過得越來越好 所以，建議把注意力放在自己身上，你就會越來越優質 簡單建議，分三個層面 **知識層面** 工程師應該很擅長吸收新知，這點不難。學有趣知識、學習投資、專精工作、更有智慧、賺更多，都不是壞事 **肉體層面** 叫大家都進健身房，很難、又花錢，不切實際。所以我建議各位路過公園就去拉一下單槓，一週兩次，一次20分鐘就可，免費 上網找一些分難度的教學即可，例如這個 https://www.youtube.com/watch?v=kxdNy86hG5I 你就拉個三個月，工程師打電腦的駝背、姿態、儀態，都會改善，然後你會變強壯 **精神層面** 現代人普遍忽略這點，不過，如果你掌握「發呆」的技術、藝術，也就是所謂的「冥想」、「靜坐」 其實在冷靜程度、自信程度、鎮定程度，會有顯著變化，這比較宗教、靈性，需要一些年紀體會 隨便找一個適合你的靈性練習、或宗教，都可以。如果沒頭緒，我建議逛一逛這個印度阿北的頻道 https://www.youtube.com/@sadhgurutraditionalchinese ## 面對挫折感 人生不如意，十之八九，不要太玻璃心 被拒絕了、丟臉了、意想不到情況發生了，就認了，慢慢消化 回家休息，繼續做你該做的事情就好 千萬不要糾纏、不要挽回、不要當恐怖情人 瀟灑一點，繼續做上面三個層面談到的事情就是了 ## trial and error，你就多練習 這跟工程師學新語言、新套件的情況一樣 出錯很正常，多練習就是，你想在什麼方面進步呢？那就 trial and error，你就多練習 想改善穿搭，多逛街、消費就是。簡單從黑灰白開始配色就是，跟前端 css 色彩配色技巧一樣 想改善談吐，在一些小聚、適合的大眾場合、甚至咖啡廳酒吧，你就去搭訕兩句，尬聊兩句 大多數情況下就是被拒絕、很丟臉，別擔心，不要搞到「讓對方感到害怕」的程度即可，丟人現眼 OK 的，被婉拒就禮貌離開即可 我留意到近幾年有一些昂貴的課程在賺這種錢，其實錢省下來買電玩比較爽，不要被商人隨意利用你的焦慮感 反正就是練習交新朋友、networking 而已，臉皮厚一點，越練習臉皮越厚，然後目的性不需要總是那麼強 熟能生巧，上手了社交技巧，在職場也很有用 ## 關於打電動＆看動漫 爽爽打電動，爽爽看動漫，一點問題都沒有，都是很健康的興趣 不要越打越沒自信、越看越空虛就好，要找到真正喜歡的電玩、動漫並且投入 有人傳訊息你就不要理，專心打電動＆看動漫，有空再回就好，享受你的興趣就對了 呼應到前面幾點，這種人，會讓很多人覺得「好像是一個很忙的人」，然後，不知怎的，就是比較有魅力 （雖然根本不知道你只是看動畫懶得回而已） ## 結論 這些也是我比較年輕時候，身為「年輕單身男性軟體工程師」的一些觀察＆經驗談 簡單分享，希望對大家有幫助
2024 年 鼓勵更多工程師加入論壇討論 現在支援 Github 登入 歡迎邀請工程師朋友一起來加入～
正在寫元件測試 很多個元件有用到 pinia 測試的時候，我是希望能提供 initial state、然後可以用 cypress.intercept 替換掉 ajax 回應 根據官方文件，我使用 ``` createTestingPinia({ stubActions: false, }) ``` 結果 action 一直沒有呼叫，研究了好幾個小時 最後發現是，需要提供一個 dummy spy object 才可以 ``` const spy = (action) => action; createTestingPinia({ stubActions: false, createSpy: (action) => spy(action), }) ``` 筆記一下，因為國內外都沒有文章提過，這應該要放在官網說明才對
承接前面幾篇 > 開發人員平台現在需要商家驗證才能取得進階存取權限 https://developers.facebook.com/blog/post/2023/02/01/developer-platform-requiring-business-verification-for-advanced-access/ > 針對今天之後建立的應用程式（在 developers.facebook.com 上建立的應用程式），我們會開始逐步在新應用程式要求進階存取權限時，實施此規定。從 2023 年 5 月 1 日開始（除非需要提前要求此程序），在今天（2023 年 2 月 1 日）之前建立且具有進階存取權限的應用程式，必須連結至已驗證的商家。為了管理初期大量的商家驗證要求，我們將在 2023 年針對我們平台上現有的應用程式逐步實施此規定。從 2023 年 7 月 1 日開始，現有的開發人員將會收到開發人員重要通知，告知其應用程式何時可以進行商家驗證程序；收到通知後，開發人員有至少 30 天的時間可以提交商家驗證要求。屆時應用程式若未連結到已驗證的商家或等待驗證的商家，將會被撤銷進階存取權限。如果您已經有經過驗證的商家，強烈建議您確認所有現有的應用程式都已連結到該商家，以免存取時遭到中斷。另請注意，商家驗證程序完成後，將不再允許存取個別驗證。 所以是進階權限才要公司登記？ --- https://developers.facebook.com/docs/graph-api/overview/access-levels/ > 針對 2021 年 2 月 16 日之前建立的商家和遊戲應用程式，其 email 和 public_profile 權限，以及通過應用程式審查批准的任何權限或功能（若有使用），都會自動獲准進階存取權限。 所以我工程師做 side project，只要 email 跟用戶大頭貼，應該不用登記公司囉？ > 進階存取權限現在需要商家驗證 > 自 2023 年 2 月 1 日起，要求進階存取權限的應用程式「可能」必須連結已驗證的商家。詳情請參閱此部落格文章。 「可能」要？到底要還是不要？ --- https://developers.facebook.com/docs/permissions > App Review is required for all permissions except for email and public_profile if your app needs access to data that you do not own or manage > Business Verification is required for all apps making requests for Advanced Access Only select permissions that your app needs to function as intended. Selecting unneeded permissions is a common reason for rejection during app review 到底在寫什麼？誰看得懂？ 所以我工程師 side project 會通過 app review 但無法拿到 business verification 然後還是會被撤銷「FB 登入」功能？ 如果是我誤會了，那為啥我會收到 FB 緊急停權通知？ > REMINDER: Business verification Urgent > Here’s what a person with full control of your Business Account needs to do for Meme 梗圖倉庫 by 2023年12月24日 to maintain access: > Connect the app to a Business Account, if you haven't already. > Complete business verification for the Business Account. > If business verification isn't completed, this app will lose access data from users (for some apps this means permissions and features will be switched to standard access). > 11月20日 --- 一般權限，是只有ＡＰＰ開發者自己可以登入，那這ＡＰＰ跟本就不能用啊！ 只要做ＦＢ登入功能，就需要進階權限，那到底有沒有包含 email 跟用戶大頭貼？ 寫一大堆文章，怎麼還是不清不楚？ 一堆冗言贅詞、「可能」、「必須」、「進階」、「一般」、反面表達，到底在寫什麼？ 我認了，不能去賭我ＡＰＰ被關掉、用戶無法登入的風險 我直接去登記公司了 大家串接 FB API 要小心，不要跟我一樣，變成傻瓜
承接上一篇，FB 對待合作開發人員，立場越踩越硬 https://codelove.tw/@howtomakeaturn/post/NxNy0q 畢竟我們工程師串 FB API 沒在付錢，如果像詐騙集團他們有持續付 FB 廣告費 那 FB 就很樂意持續幫忙投放詐騙廣告，這是台灣用戶人盡皆知的 來聊一聊，這次被 FB 惡搞之後，我個人的額外虧損 --- 我有一個搞笑網站，流量不錯，跟廣告聯播網合作，每月我可賺 25,000 元，算是 side project 很好的成績 年收入用 30 萬來算，我是合法報稅喔，因為廣告聯播網要報支出，所以我沒法逃稅，會進個人綜合所得稅 被 FB 這樣一搞，我需要去登記公司，媽的一開始以為還好，實際跑起來很麻煩 找代辦要付大概 1 萬元左右，這就算了 每年額外費用如下，這是我找到很省錢的解決方式了喔，不然還會更貴 - 31500(商務中心租金) - 22400(事務所記帳，不然公司負責人自行申報的話，那政府 UX 很悲劇 ) - 12000(我本來在職業工會，變成公司負責人額外健保費用，是更多出來的費用) - 15000(營業稅用5%計算) 加起來是 $80,900 元，每年都要支出！ --- ## 結論 建議 大學生、工程師業餘做 side project，請避免使用「FB 登入」功能 就算要做 也要讓用戶登入之後 規定要輸入密碼，保留密碼的登入方式，社交登入只是方便而已 不然你網站、ＡＰＰ，某天就不能用了，要去做公司登記，跟我一樣，side project 沒賺多少，一大部份拿去付公司費用 如果 FB 要求付費投放廣告之前，也像對待 developer 的 side project 這麼硬、要出示政府核准公司文件，那台灣詐騙廣告還會那麼猖獗嗎？
大概從 2012 年開始，幾乎大大小小的網站、APP 都會有「FB 登入」功能吧 就是去 FB 後台 註冊 申請一下即可 一堆資工系大學生、工程師業餘 side project 幾乎都玩過 但是相關政策一直在改變 就在今年 2023 改成 一定要有註冊公司 才能使用 https://developers.facebook.com/blog/post/2023/02/01/developer-platform-requiring-business-verification-for-advanced-access/ FB 寫了很多篇 曖昧不明的文章 創造一堆專有名詞 你看半天也看不懂 我講結論：反正就是 會隨機抽查 開始抓 app 只要沒有「政府核准文件」的 app 就會砍掉 FB 登入權限 要政府核准函 或是 有公司名稱＆地址的水電帳單 很硬喔 我研究過了 沒有取巧、迴避的方法 --- 就算你是經營不錯的公司 還是會被這種政策搞到 例如 財報狗 今年有一段時間 無法ＦＢ登入 https://www.facebook.com/statementdog/posts/pfbid0v7sYjy3HLvMaqSWvd11hMt32xQL8Mgi7iNdeZoP7UrYPCo3o9fMNruNgeoaKfQNGl?__cft__[0]=AZXS4AqmqXa1jGrsqKEihimrD8KttxyEbzqcF52n8AAJ0c4JICCpx14TPPPyH4IWB85zhmRZn5BizOXycj_EYAQOj74rHtI262e2fsU2WOvMWzhTnCT3sPxTLTB9igX2tB96p2B5okinh_N-Dss5QBSz&__tn__=%2CO%2CP-R --- 這件事在台灣沒人討論 在國外已經議論紛紛 > Ask HN: Is “sign in with Facebook” dead for indie developers? https://news.ycombinator.com/item?id=37349924 --- 建議 大學生、工程師業餘做 side project，請避免使用「FB 登入」功能 就算要做 也要讓用戶登入之後 規定要輸入密碼，保留密碼的登入方式，社交登入只是方便而已 也就是讓社交登入變成註冊流程的一個環節，而不是直接就註冊完成 不然你網站，某天就不能用了，要去做公司登記 額外成本會變多少呢？我另寫一篇說明 https://codelove.tw/@howtomakeaturn/post/l3jOpa
看到一篇滿好的文章 https://jiongks.name/blog/introducing-zhlint 作者親自寫了一個工具 值得學習
看到一則廣告 https://sites.google.com/view/202201kittencoding-teacher/main 有人去試過嗎 需要賺外快的朋友們可以參考看看喔！
我有一個資料表 大概 15 萬筆資料 其實也沒很多 before ``` $posts = Post::inRandomOrder() ->limit(1000) ->get(); ``` 這樣寫，結果跑起來超慢，然後我改寫 after ``` $posts = Post::orderBy('id', 'desc') ->where('id', '<', rand(1, \DB::table('posts')->max('id'))) ->limit(1000) ->get(); ``` 雖然，這樣就沒有很隨機了，而是從隨機中間點，抽 1000 筆出來 但因為我在產生 sitemap 而已，所以其實可接受 算是 laravel 小小地雷
處理大量資料，會去用 chunk 如果先用 limit 限制數量，再用 chunk 結果 limit 好像會無作用 https://github.com/laravel/ideas/issues/103 https://github.com/laravel/framework/issues/9649
轉職前端系列，我發現完成系列一～九就差不多了，後面非必要 為避免誤解，我乾脆把原本的十、十一移到現役前端系列 並且改名為 `後端 JS 訓練（一）` 與 `後端 JS 訓練（二）` 另外，因為現役前端系列，目前內容不多 我就先把現役前端系列的內容，都先設為免費 以上更新，簡單公告～
家裡有一台 2018 年的 asus 舊筆電 硬碟大概有 100GB 的閒置空間 剛好最近家裡 中華電信網路升級，想說來用出租硬碟 挖挖看 storj 幣 --- https://www.storj.io/host-a-node 跟著步驟跑 在 `Generate node identity` 這步驟 發現他會狂跑ＣＰＵ 直到算出一個難度為 36 以上的 key 為止 我筆電大概算到 33 就算不出來了，後面算很久都還是 33 要算到 36 恐怕要一星期吧 --- 上網查了一下報酬 https://www.reddit.com/r/storj/comments/17uk8er/is_it_worth_starting/ 看起來大家都是用 10 - 40 TB 左右的硬碟出租，每個月報酬 10 - 30 美元左右 這個報酬顯然很不划算，可能連電費都付不了？ 我就中止嘗試了 分散式的硬碟雲端儲存，所謂的 web3 應用，還要再等等
最近幫客戶研究 ab testing，目前找到最適合的服務是 GrowthBook 在研究這服務的時候，找到介紹文章 https://news.ycombinator.com/item?id=30515940 > Developers often launch a feature without understanding the impact it has on their users and business. This is a big deal, because only 1/3 of product launches actually improve the desired metrics. Of the rest, 1/3 have no effect, and the last 1/3 actually hurt [1]. The best way to measure this is to use feature flags and controlled experiments (A/B tests). 翻譯起來就是 > 開發人員經常在不了解其對用戶和業務的影響的情況下推出一項功能。這是一件大事，因為只有1/3 的產品發布實際上改善了所需的指標。其餘的1/3 沒有效果，而最後 1/3 實際上會造成傷害 [1]。衡量這一點的最佳方法是使用功能標誌和受控實驗（A/B 測試）。 最近覺得這確實滿重要的，如果可以很方便地導入 ab 測試，容易使用、容易查看，那的確值得多多觀察、輔助決策 我也許會找時間寫一款基本的 ab 測試套件，給 laravel 社群使用～
在上一篇文章，我簡單介紹了 GraphQL 的好處，以及如何在 laravel 中實作 這一篇文章，接著介紹一下如何在前端使用 React 進行整合 # 實務範例與 API 線上試玩 上一篇文章我用 graphql + laravel 實作了簡單的電商後台 api https://graphql-laravel-example.tw/graphiql 這次我用 Next.js 開發了簡單的電商前端 web app https://graphql-react-example.vercel.app/ 歡迎試玩看看！可以瀏覽商品、輸入信箱訂閱電子報 --- 在前端發送 query 的程式碼，可以參考 https://github.com/howtomakeaturn/graphql-react-example/blob/main/app/page.js 在前端發送 mutation 的程式碼，可以參考 https://github.com/howtomakeaturn/graphql-react-example/blob/main/app/newsletter.js 我使用原生的 fetch 函數呼叫 graphql api，所以您用任何一款 http 函式庫也都可以做到 狀態管理我用 Next.js 社群的 swr 當作範例，您完全可以自由使用任何 state manager # 優點介紹 我認為前端可以自主決定，要撈取哪些資料，是 graphql 最強大的功能！ 後端設計好各種 type 之後，前端就可以自行根據 playground 試玩 api！ https://graphql-laravel-example.tw/graphiql 可以彈性、自由撈取資料，連關聯資料都可以巢狀撈取！ ``` const gql = `query { products { id name description featured_image price comments { content user { name } } }, }`; ``` 大幅減低後端開發時間、前後端溝通時間、以及處理不同情境需要新增多組類似 api 的時間！ # 完整程式碼 前端完整程式碼請參考 https://github.com/howtomakeaturn/graphql-react-example 上次的後端 graphql 試玩 https://graphql-laravel-example.tw/ 後端完整程式碼 https://github.com/howtomakeaturn/graphql-laravel-example # 結論 上面 graphql + laravel + react 的範例 我認為原始碼非常單純、易讀，容易開發、也容易維護 您應該可以根據我提供的範例，在專案中試著導入使用 我在替客戶導入 graphql + laravel + react 的時候，發現網路上教學雖然很多，但是缺少範例 所以我製作這些 sample project 方便大家參考＆入門 大家有機會的話一定要試試看 graphql 的威力！ （此為系列文章，更多內容會在近期發佈） --- # 系列文章 - [Laravel + GraphQL 接案心得＆範例分享 Part 1：強大優點、API 線上試玩、工具介紹](https://codelove.tw/@howtomakeaturn/post/yx08mx) - [Laravel + GraphQL 接案心得＆範例分享 Part 2：前端 Query/Mutation 與 React 串接範例](https://codelove.tw/@howtomakeaturn/post/2an0Gx)
看到一篇文章 提到 trunk based development 以及 feature flag 的使用 我在想 好像還可以搭配 ab testing 進行 https://koenvangilst.nl/blog/trunkbased-development 分享跟大家參考
客戶最近有把舊 laravel 專案改寫為 SPA 的需求，需要前後端分離 為了方便前後端溝通、改善開發者體驗，我建議＆協助他們導入 GraphQL 技術到 laravel 專案中！ 實際導入＆開發半年之後，成效非常不錯！前端工程師、後端工程師都用得很開心！ 今天跟大家分享一些心得＆範例程式碼！ ## 破除迷思 > 很多公司聽到 GraphQL 會有點卻步，覺得太新、不成熟 其實，這技術面世八年了，在國外已經被許多公司廣泛採用，不算很新了！ > 很多公司會以為這是給大公司用的技術，小公司不適合使用 其實，我自己的使用經驗是，就算團隊只有兩個工程師，這技術也很好用，會讓開發速度更快，不會更慢！ > laravel 社群會以為這技術在 node 社群、或其他社群比較常見 其實，laravel 社群也有很好用的套件，導入也很方便！ 所以這技術非常值得學習、使用，至少了解一下！ ## 優點介紹 我認為最大的優點就是，大幅降低了前後端溝通的成本！ 傳統開發，後端寫完 API，要另外寫文件告訴前端網址是多少、回傳的資料格式 然後前端需要用 postman 之類的工具，方便測試、開發 使用 graphql 的話，後端寫完程式碼，就同時自動生成文件＆測試工具了！ 為了方便讀者「親自試玩」以上描述，我準備了一個範例專案給大家！ 這個專案模擬電商網站，API 可以撈 products 與 comments 兩種資料！ 然後可以訂閱商家的電子報，也就是新增 subscriber 這種資料！ ## 實務範例與 API 線上試玩 我先分享範例專案給大家！ https://graphql-laravel-example.tw/ 原始碼也已公開 https://github.com/howtomakeaturn/graphql-laravel-example --- 以往 RESTful 的設計，「讀取資料」這種動作，在 graphql 稱之為 query https://github.com/howtomakeaturn/graphql-laravel-example/tree/main/app/GraphQL/Queries 會去「更新資料庫」的動作，在 graphql 稱之為 mutation https://github.com/howtomakeaturn/graphql-laravel-example/tree/main/app/GraphQL/Mutations 以上兩個資料夾可以翻閱一下，每支 api 會是一個檔案，所以很好管理 接著使用 graphql 社群的強大工具：graphiql，就同時得到文件＆測試工具了！ https://graphql-laravel-example.tw/graphiql 我安裝了一份 graphiql 給大家，點進去玩玩看吧！ 把他當成是技術規格文件與 Postman 測試工具，身兼兩種用途！ 有了這個工具，大幅減少了前後端需要溝通的事項，對於前後端合作有「巨大幫助」！ （請注意，實務上 graphiql 建議在本機執行，不要這樣線上公開，會有資安疑慮） ## 套件介紹 在 graphql 社群，有兩種開發 api 的哲學 分別是 schema-first 與 code-first 兩種方法 laravel 社群最知名的 schema-first 套件是這款 https://github.com/nuwave/lighthouse laravel 社群最知名的 code-first 套件是這款 https://github.com/rebing/graphql-laravel schema-first 與 code-first 的差異與優缺點我先不細談 總之，我個人比較喜歡 code-first，我覺得比較直觀、簡單、好導入 所以我的範例是用 https://github.com/rebing/graphql-laravel 這套件 您的 laravel 版本建議至少要是 8.0 以上版本，太舊的可能會有問題 順帶一提，兩個套件背後都是使用 https://github.com/webonyx/graphql-php 所以底層元件一樣，兩者有很多通用的觀念，不用太擔心 --- graphiql 是 graphql 官方的重要工具 laravel 社群已經有人寫好懶人安裝套件了 https://github.com/mll-lab/laravel-graphiql 按照說明安裝即可得到超好用的自動文件＆測試工具面板！ ## 結論 有了以上兩個套件，按照說明分別安裝 然後參考我提供的範例程式碼 https://github.com/howtomakeaturn/graphql-laravel-example 您應該就可以在專案之中導入 graphql 基礎架構，並且開始用 graphql 寫出您的第一支 api 我在替客戶導入的時候，發現網路上 graphql 的教學、說明雖然很多 但是剛開始寫還是很困難，很少範例 所以我製作這份 open source 方便大家參考＆入門 並且直接把 graphiql 面板公開部署上線，方便大家體驗！ （此為系列文章，更多內容會在近期發佈） --- # 系列文章 - [Laravel + GraphQL 接案心得＆範例分享 Part 1：強大優點、API 線上試玩、工具介紹](https://codelove.tw/@howtomakeaturn/post/yx08mx) - [Laravel + GraphQL 接案心得＆範例分享 Part 2：前端 Query/Mutation 與 React 串接範例](https://codelove.tw/@howtomakeaturn/post/2an0Gx)
來，讓我們特別關心轉職成功、上班大約半年的 @birdie2019 @JoeyLai 最近有學到新東西？ 是否變得越來越有自信？ 該不會想要跳槽去別間公司了吧？ 隨時歡迎上來分享工作筆記 or 上來發問卡關問題～
正在評估幫一組開發團隊導入新工具 方便寫技術文件 管理技術債 也進行內部知識管理 我發現三大 git hosting 都有 pages 功能 其中 github 跟 gitlab 的 pages 可以限定權限瀏覽 https://docs.github.com/en/enterprise-cloud@latest/pages/getting-started-with-github-pages/changing-the-visibility-of-your-github-pages-site https://docs.gitlab.com/ee/user/project/pages/pages_access_control.html 可是 bitbucket 就沒有這個功能 https://jira.atlassian.com/browse/BCLOUD-9491 真的覺得 bitbucket 在這方面還是有點落後 --- 除此之外 gitbook 也是不錯的選擇 不過團隊版要另外付錢 https://www.gitbook.com/solutions/internal-knowledge-base
遇到一個有趣的問題 我開發的某組 API 多位用戶回報不能使用 使用 `fetch()` 可以執行 但使用 `axios.get()` 就不能執行 會被 CloudFlare 報 403 錯誤擋住 我估計是發出的 http request headers 內容有差異 暫時不研究差異何在 # 解決方法如下 Security -> WAF -> Custome rules -> Create rule If incoming requests match… `URI Path` 在 value 輸入 API 相對網址 WAF components to skip 只要勾選 `All Super Bot Fight Mode Rules` Deploy 之後問題就解決了！
最近跟一些年輕的工程師合作，發現系統上線之後 bug 有點多 這當然很正常，不過，如果適度的留意自己的當下的「寫作風格」 其實可以減少很多 bug，或者是可以減少 debug 的時間 這些年工作下來，我發現在開發不同元件的時候，我基本上會在兩種風格中選擇，簡單跟大家分享 # 嚴格風 在寫一些基礎重要元件、或者呼叫第三方 API 時，我認為把「可能的狀態」通通清楚列出來比較好 也就是像這樣 ``` function doTask($arg1) { if ($arg1 === 'val1') { // ... } else if ($arg1 === 'val2') { // ... } else if ($arg1 === 'val3') { // ... } else { throw new Exception("Impossible state."); } } ``` 只要出現預期之外的值，就直接丟出例外，這樣可以大幅改善 developer experience 也就是在當下就提醒同事：「我這元件當初設計不是這樣用的，請檢查」 很多人不會把「可能的狀態」寫完，而是放在 else 底下，比如說 ``` function doTask($arg1) { if ($arg1 === 'val1') { // ... } else if ($arg1 === 'val2') { // ... } else { // handle `val3` here } } ``` 雖然程式課本都是這樣教的，但實務上這會導致很多可能的 bug 比方說有同事在使用這元件時，參數傳入 `val4` 結果程式繼續運行 這會導致一些錯誤的理解、讓錯誤的假設在團隊中持續蔓延 所以，在重要的元件，比如金流相關時，採用這種「嚴格風」去寫會比較好 也就是強迫大家搞清楚這個元件的用法，不准許憑感覺隨意呼叫 # 隨興風 在一些寬鬆的元件，通常是 search 相關的元件、抓資料相關的元件時，可以預期，呼叫方會隨意嘗試各種參數 甚至會有一些參數傳都不傳，覺得元件要有預設才合理 這種元件，就寫得盡量寬鬆、盡量多給預設值，會比較好 也就是呼叫方，參數要傳不傳，都可以，傳錯的時候，就當作是跟沒傳一樣，就用預設值就好 這種元件就是用起來很寬鬆，主要目的是希望不要因為這些小事，讓程式爛掉、故障在那邊 寫起來就是多檢查變數有沒有存在，沒有就給預設值 然後 if else 的時候也比較隨興，基本上不會丟例外，不管怎麼傳都盡量讓你跑 --- 不同的元件，適合採用不同的風格來寫 雖然這是一個主觀的問題，但適當的分辨當下應該採用哪種風格 會讓你的同事非常喜歡跟你工作，覺得你寫的元件「總是很好用」、「用錯的時候都會提醒」、「在不需要拘泥小節的時候，也不會囉唆」 話雖如此，要能知道當下適用的風格，其實需要許多年的經驗累積。 嚴格風、隨興風，只是一個概念，實際上的 coding style 有很多寫法，大家可以慢慢實驗＆嘗試 簡單給個方向，跟大家簡單分享
歡迎最近新註冊的用戶 @fanjunran @hygge54812 @prince811009 @frog0708 @wiyoy24437 @nieh099 @sindy1280 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
我發現大家在 LINE 群的發問討論很踴躍 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 可是因為是聊天室的形式，討論串很容易被洗掉 我有看到有些人的發問，還沒有人回答 就被聊天訊息洗掉了 我建議大家，如果訊息被洗掉，可以直接到論壇這邊 PO 文喔 方便大家查看＆回答
歡迎最近新註冊的用戶 @Kenjiwuuu @ck1040308 @cony991 @MollyLin @sungcowcow @kelo @macweather 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
為了提升系統穩定性，最近替某電商客戶的專案寫單元測試 有一部份核心功能會用到第三方 API，這讓測試變很難寫，因為沒有本地的狀態變化可以比較 想到 laravel 有一個關於 mail 的測試功能，有類似情況 簡單來說就是在 phpunit 中這樣啟動之後 ``` Mail::fake(); ``` 就可以這樣來檢查是否有執行某 api ``` Mail::assertSent(OrderShipped::class); ``` 能否用同樣原理，處理我面對的情況呢？ 決定來看一下原始碼！ --- 首先是 fake 會直接換掉 Mailer 的實體 `framework/src/Illuminate/Support/Facades/Mail.php` ``` public static function fake() { $actualMailManager = static::isFake() ? static::getFacadeRoot()->manager : static::getFacadeRoot(); return tap(new MailFake($actualMailManager), function ($fake) { static::swap($fake); }); } ``` 可見是實作同樣 interface 的測試專用類別！ `framework/src/Illuminate/Support/Testing/Fakes/MailFake.php` 然後寄信就改成，把變數存進陣列即可 ``` public function send($view, array $data = [], $callback = null) { if (! $view instanceof Mailable) { return; } $view->mailer($this->currentMailer); if ($view instanceof ShouldQueue) { return $this->queue($view, $data); } $this->currentMailer = null; $this->mailables[] = $view; } ``` 然後 assertSent 那些就檢查陣列內容，比對一下即可 ``` public function assertSent($mailable, $callback = null) { [$mailable, $callback] = $this->prepareMailableAndCallback($mailable, $callback); if (is_numeric($callback)) { return $this->assertSentTimes($mailable, $callback); } $message = "The expected [{$mailable}] mailable was not sent."; if (count($this->queuedMailables) > 0) { $message .= ' Did you mean to use assertQueued() instead?'; } PHPUnit::assertTrue( $this->sent($mailable, $callback)->count() > 0, $message ); } ``` inside of the `sent` function ``` return $this->mailablesOf($mailable)->filter(fn ($mailable) => $callback($mailable)); ``` --- 所以，目前這樣看起來，在需要測試跟「第三方 API」有關的功能時，可以使用同樣原理 使用 laravel 提供的 mock 功能，把會用到的第三方套件 mock 掉，套件的核心 function 就存個變數或陣列之類的 然後多寫個類似 `assertSent` 這樣的方法，應該就可以做到不錯的測試效果～！ 簡單來說，就是設法做出「本地的狀態變化可以比較」就是了 我來往這方向寫寫看，有心得再補充分享～
阿川收到網友提問如下： > 阿川你好： > 我的背景是雲科碩畢業，算是混上去的，現在打算轉職軟工，由於有在工作，所以打算先以自學為主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 --- 以上，簡單分享，希望對大家有幫助！
阿川收到網友提問如下： ``` 站長阿川您好 我是一名App工程師 從2013年第一份工作到現在近10年 這十年我從工程師到資深工程師到管理職位都有相關經驗 一共經歷四份工作 離開公司原因大多是與人理念不合 今年邁入40歲 目前在一間外商工作 年薪約200左右 最近又再找尋新機會 但是相關職位看到我的經歷常常被拒絕 因為該職位不想要這麼資深的 不然就是年薪必須砍半 最近有一個機會可以加入幾個創業家所組成的公司 缺點是薪資可能只剩下現有的1/3 優點是可以接觸相關人士學到創業可能所需的技能 也可以藉由這樣機會建立屬於自己的產品一步步養活自己 在網路上看到您的文章彷彿醍醐灌頂 也對於長年職涯生命握在別人手上感到非常不適應 但是我明白產品可能不是自身想像那麼容易打造 不過我仍想試試看 不知道您這邊是否有什麼想法可以對我未來要走的路提供一些建議 非常感謝您撥空看完 ``` 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享一下 --- 首先，這位朋友目前的工作狀況，外商、200萬年薪，如果工作壓力不大、下班時間正常，辦公室氣氛融洽 這麼好的條件，如果放棄這份工作，實在相當可惜！ 有沒有考慮利用下班＆週末的時間，寫一些自己的作品、app，試試看？ 一人獨立開發，或者找朋友一起經營，都可以，做完之後，到相關的 FB 社團、批踢踢看板，宣傳一下 會學到很多商業、經營、行銷的技能，會很好玩 也或許，你會發現要做的事情太多、太雜、太難，你會滿不適應的，那樣的話，你會重新看見現職公司的美好 --- 再來，如果目前的公司實在很煩，除了高薪之外，工時、工作內容、環境壓力，你根本通通都不喜歡、鐵了心想要離職 那麼眼前的選項就是 - 找類似工作，薪水變二分之一 - 前往新創嘗試，薪水變三分之一 這樣的話，我有一個小原則跟你分享 # 職涯判斷技巧：Ctrl+Z 不心痛原則 這是我發明給自己，在面臨重大決定會用的一個原則 Ctrl+Z 是工程師每天會用到的快捷鍵：「恢復上一動」 在面臨選項的時候，可以去想想：「恢復上一動」的成本會很高嗎？ ### 「我該先做哪一個決定，到時反悔的話，可以 Ctrl+Z 不心痛呢？」 舉例來說，社會新鮮人有點想考公務員 vs 想去業界上班看看 如果先考公務員，工作之後迷惘，想辭職去業界，這時「Ctrl+Z」的成本就非常高，因為當初花了數個月準備國考 如果先去業界上班，工作之後迷惘，想去考公務員，這時「Ctrl+Z」的成本就低很多，因為當初就是花一些時間面試而已 所以迷惘的社會新鮮人，我都是建議先去業界面試看看，再去考公務員 --- 再舉一個例子，年輕工程師想去大公司面試 vs 想去新創面試 大公司面試流程很多、面試成本很高，去新創通常聊一個下午就錄取了 所以迷惘的年輕工程師，我都是建議先去新創工作看看，如果之後再去大公司上班，心態就會很穩，因為你知道新創時髦的外表底下，其實愚蠢的地方也不少，你會比別人更看見大公司的美好 如果到了大公司才嚮往新創，到時再次反悔、重新面試大公司的成本就高很多、這樣很浪費時間 --- 我認為現代人，不管做什麼選擇，一定都會覺得迷惘、好奇當初沒做的那個選擇、常常會有遺憾 所以重點不是「如何第一次就做出正確決定」，因為做不到 重點是「**我該先做哪一個決定，到時反悔的話，可以 Ctrl+Z 不心痛呢？**」 這種路徑，比較不留遺憾，因為各種路都走過了，並且算是一種逐漸認識自己的過程 這樣做決定，會容易許多吧！我自己都是這樣做的～ --- 以這位網友面臨的狀況： - 降薪50%去類似環境的大公司上班，然後繼續迷惘新創公司是什麼樣子 - 降薪66%去新創公司看看，然後可能很喜歡、也可能發現是在浪費時間 如果選後者，去工作半年一年，真的不喜歡，頂多就是回去找大公司面試，這樣「Ctrl+Z」的成本也不高吧？ 我會覺得就去新創看看也沒關係，因為之後反悔的成本也沒多高，而且這種事就是體驗過才知道 # 結論 其實創新、創業，極度困難、要做的事情也很雜亂 在我跟各種新創公司合作的經驗來說，很多時候其實也是浪費時間、有點像在幫老闆圓個人夢想，產品本身很爛。當然我也跟很多優秀新創合作過、學到很多寶貴技能 總之去新創不一定好玩，也不一定學得到東西 但我認為有策略性地、管理好各種職涯選擇的成本、在過程中認識自己、增廣見聞、降低迷惘，是很重要的 這位網友如果本身有房貸、車貸、家庭孩子要養，那麼這個抉擇確實非常困難 另一方面，職業生涯不是只有充實金錢＆地位，能夠充實人生經驗＆體驗，也是很有意義的，不是嗎？ 建議靜下心，好好的幫自己分析一下、聽聽看內心的聲音，新選項真的讓你有「義無反顧」的感覺嗎？ --- 我另外還有一些幫助工程師觀察「眼前這位迷人的創業者，有沒有可能是個地雷」的技巧，有機會再跟大家分享吧～！ 以上，簡單幾點分享，希望對大家有幫助，祝各位都有滿意、幸福的職業生涯！
工作了很多年，還是搞不太懂 promise、async/await 是什麼嗎？用這份作業包一次搞定觀念！ https://codelove.tw/@howtomakeaturn/course/d3obxP --- 另外，練功作業包現在分成「轉職前端」、「現役前端」兩種專區 因為是針對兩種背景，所以分開來方便學員挑選～
今天早上，在我們新手寫程式 LINE 群組，有幾個工程師＆新手在討論，工程師與創業的話題 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 其中一段 cue 到我： > 這裡的版大不就是創業嗎 lol > 對欸！站長是創業的 > 創業重點是人脈 業務很重要 > 工程師很缺業務朋友 有業務朋友要創業會簡單很多 > 不過我覺得站長這種創業模式是餓不死 應該沒有到達財富自由賺大錢 這個主題非常好，我來跟大家分享一些想法！ --- # 站長阿川會餓死嗎？ 先直接談最「害羞」的事情，阿川的網站每個月賺多少錢？ 我在之前幾篇文章有談過我的工作方式，其實並不是傳統定義上那種 100% 創業 https://codelove.tw/@howtomakeaturn/post/2anz0a 我現在手上的六、七個網站，通通加總起來，扣掉租用主機的成本 每個月的利潤大概是 . . . . . . 跟基本工資一樣，月薪26,400元～ 所以 LINE 群大家的猜測非常準確，像我這樣做一些小網站經營，完全無法「財富自由賺大錢」 但我這種經營方式有幾個好處： 1. 我的幾個小網站，開發很花時間，但經營不太花時間，所以我還有時間接案、有 freelancer 的身份 2. 沒有跟政府 or 銀行借錢，身上沒有負債壓力，經營小網站就是這樣 3. 連跟政府申請任何創業補助、補貼，都沒有，也沒有外部投資人，愛做不做新功能，都是隨便我 # 創業做網站，每個月利潤只有基本工資，那不是搞笑嗎？ 首先，台灣的工程師如果希望快速累積財富，我認為最穩健的方式，還是去科技業、半導體產業 有些事情我 20 多歲的時候不相信、看不懂，現在 30 多歲，稍微有點看懂了 我們政府，基本上是圍繞這些產業做資源分配、政策設計（比如水費、電費、匯率、土地），進這些產業「分果實」當然最快 你應該聽過很多科技業的工程師，年薪動輒超過數百萬，但是台灣純軟產業的工程師，你很少聽到年薪 200 萬的 相反的，如果選擇創業，除了五年內 99% 的陣亡率（經濟部中小企業處的官方數據！） 少數能持續經營的公司，有很多的小小公司老闆，收入可能跟我差不了多少，基本上是做得開心、但沒賺到錢 再來，如果外語能力允許的話，出國到其他有軟體產業的國家，也是更好賺錢的軟體工程師生涯 # 傳統的軟體創業 vs 獨立的軟體創業 我看到 LINE 群大家聊到，「工程師很缺業務朋友 有業務朋友要創業會簡單很多」 就我個人觀察，我認為這是真的！「工程師 + 業務」算是創業的黃金雙人組合 一個負責把產品研發好、一個負責把產品賣出去，這完全是兩種人、兩種互補技能 傳統的軟體創業基本上就是：黃金組合 + 申請創業貸款 + 尋找投資人 + 尋找政府創業補助 順利的話，幾年後可以賺到大錢，大家所謂的財富自由 但是，你用想也知道這樣做壓力很大，有夥伴的壓力、投資人的壓力、負債的壓力、應付政府的壓力 所以我選擇的是另一種，一個人兼職做各種小小 side project 的創業方式 # 結論 工程師想要快速存錢，不要想太多，就去半導體，不然就出國 如果不願意，又有點想創業，但又跟我一樣膽小的話，就可以參考我 side project 的創業方式 目前我是覺得還算好玩，收入的話再慢慢想辦法增加這樣，其實利潤 2 萬元我是覺得也不錯呀～我還有多餘時間可以接案欸 以上，簡單心得，跟大家分享一下，未來有更多數據＆心得再跟大家分享！
歡迎最近新註冊的用戶 @a41522001 @hill654 @ru042l41j4 @Road @stanly123 @r567tw @cssf998811 @thes80140 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
昨天在我們新手寫程式 LINE 群組，有幾個工程師＆想轉職的新手在討論： > 各位前輩們好，小弟是自學轉職的前端工程師，目前有兩個 offer，一個是接案公司；一個是自有產品，自有產品的那間目前只有一個junior前端，進去有問題可能沒人可以問，但看網路上好像都不太推接案公司。猶豫了很久選不出來想聽聽各位前輩的看法。 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享 --- 阿川幫大家從幾個角度來分析比較一下 # 學習的深度、廣度 接案公司通常是使用類似的技術，接不同的客戶專案 好處是可以接觸很多不同的客戶，認識許多不同產業 壞處是做久了可能會開始有「重複感」，也就是好像一直在做類似的事情，有點學不到東西 產品公司通常是長期深入研發自家產品、技術 所以會在同一領域鑽研，通常可以玩得比較深入、學得比較深入 壞處是可能長期只能使用同一技術、框架，沒機會玩別款的 接案公司有時需要面對不同技術需求的客戶，有機會玩玩不同款的語言、框架、技術 # 工作的時程壓力 接案公司的時程壓力來自於「客戶」，通常已經由老闆、PM 跟對方承諾某個時間，甚至已經寫在合約上 如果同時在開發多個專案的話，有時候工程師會感到相當的壓力 通常是忙一陣、閒一陣這樣 產品公司沒有這樣的壓力，壓力通常來自於「公司沒有在賺錢」 如果公司經營穩定、產品前景看好、主管有肩膀好說話 那像這樣的時程壓力，通常會小很多 # 技術債 稍微資深的工程師，在不同公司面試時，一定會問的問題是：入職之後，需要維護 legacy（老舊）專案嗎？ 維護老舊專案、負擔技術債，是一件很悲慘的事情，也是開發者的主要離職原因之一 你會被迫用已經過時的工具、語法在開發，並且要把設計拙劣的系統架構「硬搬進自己腦子裡」才能消化開發 這過程能學到東西嗎？我認為不多，基本上是在糟蹋生命 接案公司來說，如果主要負責一些新客戶，那麼經常在重啟新專案，技術債問題或許不大 如果手上負責很多「超舊的專案與客戶」，那麼可能會遇到技術債的問題 自有產品的公司，則是走向另一個極端 如果是持續有在更新版本、升級套件的熱情公司，那麼技術債問題不大 如果是有年紀、穩定的系統，那麼版本問題、系統架構的技術債問題，可能很大 嚴重起來會比接案公司更慘，因為就只有一個專案在跑 # 進去有問題可能沒人可以問 大家都希望團隊能有一個又強、人又好、又願意幫忙自己的好同事 不過這可遇不可求，身為正職工程師，你需要能夠獨立解決問題 畢竟人家也面試過了，應該就是合格了，如果真的丟一些無法解決的問題給你，那也不全是你的錯 另一方面，沒人可以問，代表你獨立做決定的空間很大，這未必是壞事 # 結論 剛轉職的新手上班，我是覺得去接案公司上班也可以 通常接案公司很缺人，也比較願意給半路出家者機會 而且開始工作的前 1-2 年，不管去什麼公司，通常都能學到很多東西 待了 2-3 年之後，覺得無聊了，再找新工作也不遲 所以回到原 po 的問題：我認為兩間公司都可以，沒有說接案公司一定比較不好 畢竟，就算是自有產品的公司，如果產品本身超爛，根本永遠不會賺錢、沒人想用 那就只是一大群人在「陪老闆追逐他的個人夢想」，那其實也是相當浪費時間的，不如在接案公司專心滿足客戶，比較充實 --- 我建議閣下不妨從「人和」的角度來觀察一下：你喜歡面試時看到的那些人嗎？ 老闆、主管、同事，你喜歡跟他們相處嗎？還是你有點畏懼他們、覺得他們有點冷漠、城府、可怕？ 如果實在不知怎麼選，就選你喜歡的那群人吧！跟合得來的人一起工作，總是不會太不舒服！ 以上，簡單分享，給各位參考！也歡迎大家多多在留言區補充經驗、意見！
工作了很多年，還是搞不太懂 promise、async/await 是什麼嗎？用這份作業包一次搞定觀念！ https://codelove.tw/@howtomakeaturn/course/Pam6qL @hung @birdie2019 @superyngo 找時間來寫寫看～
上一篇文章談了「同時上班＆接案＆創業」的簡單策略 我發現滿多人對於接案這塊比較感興趣，提了很多問題 我簡單分享一些心得＆建議 --- > 請問原po，在準備接案有想過：我的能力已經足夠接案，這種類似的想法嗎？ 這幾年因為 freelancer 的身份，在一些活動、場合會遇到各種領域的 freelancer 每次遇到這些新朋友，我都會問：你是如何開始的呢？ 我發現有 90% 的機率，得到的故事都是以下這樣： 「我工作幾年之後，在 XX 年的時候離職，想說休息一下，看看之後要幹嘛。這時候有前同事來問：他那邊有人在問誰能接案，能否幫忙？」 「我就先接下來，想說那做完這筆，之後再看要不要找工作。結果做完之後再休息一下，這時又有朋友來問，能不能接某個案子。」 「我就又接一個，然後再休息一下，反正不急著找新工作。就這樣加減接案，做一陣、度假一陣。過了幾個月、幾年之後，有一天發現：我好像可以一直這樣下去。」 所以根據我個人經驗＆觀察：根本沒有人會下決心說，我要從此離職，轉身變成一個全職 freelancer 都是工作轉換的空檔，自然發生的。如果案子沒了，那就開始找工作上班，幾年之後離職休息，上面的故事會再重複一次。 所以重點是：為什麼這些人在轉換的空檔，會有人來問？ 其實就是 1. 在工作上的表現不錯，同事、主管、合作廠商、親朋好友都覺得你值得信賴 2. 有稍微經營個人品牌，身邊的人稍微知道你是做什麼的，然後根據互動經驗覺得你「溝通能力」不錯，會讓人想合作 3. 你稍微有一點勇氣，能夠接受這種「休息一下，想想看之後要幹嘛」的狀態長達數個月之久，很多人在這狀態會很緊張，急著找新工作 然後一些有趣的事情，可能就會自然發生。當然你需要有一點點積極、願意擁抱未知，大概是這樣 --- > 我其實不清楚到底要做到什麼程度？業界常用的必備工具有沒有掌握？發生問題解決辦法能不能處理？ 不論是工作、接案，基本上就是養成「挑戰能力範圍之外一點點」的習慣 不要超出能力太多，會被壓力擊倒、會開天窗、你誠信會出問題 不要完全做已經熟悉的事情，這樣沒有進步，久了會有點無聊 就做超出能力一點點的事情，常常這樣的話，久了自然會有把握＆經驗 這需要時間累積，沒有捷徑、沒有秘訣 --- > 哥有推薦接案的案源嗎 根據我的經驗，你在台灣註冊任何接案平台，或者去 FB 社團搶案子之類的，案件內容＆報酬都會「有點悲劇」 這沒辦法，平台化的東西，大家就是殺價競爭、紅海市場廝殺，比誰更樂意壓榨自己 你就算用英文搜尋，找國外接案平台，狀況也差不多，沒有好到哪去 所以我不推薦任何案源，我推薦你經營個人品牌。雖然有點丟臉，好像讓親朋好友看到你在老王賣瓜 但是行銷就是這樣，你多少要推銷自己一點，不然看起來一點自信都沒有，誰又能放心付個高價錢給你做案子呢？ 那怎麼經營個人品牌？參考我後面的回答 --- > 希望能分享關於案源品質管控的部分（怎麼避開爛專案）🙏 如果你很外向、具有那種油條的業務性格，那你就多多跟各種客戶談生意，多多談判，累積經驗就行 如果你很內向、不具有那種談判性格，實在很怕踩雷，那我建議你：只跟你喜歡的人合作 在 LINE 上打字、Email 往來的時候，感覺對方連話都講不清楚嗎？那你們實在溝通方式有差，建議婉轉拒絕吧 用 LINE 語音，或者視訊軟體開會，感覺對方有點城府，你有一點怕他嗎？那你們做人處事原則大概很不一樣，建議婉轉拒絕吧 實在很想避開爛專案，那就只跟你覺得「跟這個人當朋友好像也沒問題」的案主合作吧！ 當然工作機會，會減少很多，但是，你跟案主互相折磨、互相為難、互告上法院的機率也會減少很多 --- > 想問有建議其他職業的做法嗎？ 抱歉我比較熟悉寫程式領域 但其他職業的話，我覺得經營個人品牌總是不會錯 我滿建議大家 1. 部落格 2. Podcast 3. YouTube 4. 短影片 選擇一種格式來創作，分享一些東西，目標不用高，就花幾年時間，試著經營出 1,000 粉絲就好 分享什麼？結合你的興趣 or 專業，弄點「好笑的有趣的」或「有知識技術含量的」或「能幫讀者省錢或避免踩雷或有利益可圖的」內容，就這些即可，總是會有讀者，因為看到根本賺到 這過程會學到行銷、推銷、品牌、定位，很多很多商業基本知識，零收入沒關係，就是一種商業練習 千萬不要眼高手低、整天空想、整天焦慮沒完沒了，想要搞很大，過了好幾年還是 100 粉絲都沒有 慢慢來吧，但務必要有點進度、養成進步的習慣 以上，簡單幾點分享，希望對你有幫助
歡迎最近新註冊的用戶 @529MS @annie8278 @yukai @evanke183 @cvbn111222333g @yuamando @sophiaJ @qw820301 @jdps40734 @mutemute1127 @chihuahua48763 @Jonas @boson159456 @dj680628 @r4forth @yoitshenry 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
阿川收到網友提問如下： > 您可以分享您的軟體工程師職崖規劃嗎?再次感謝 我個人的職涯規劃其實比較偏激，是同時做「上班＆接案＆創業」這三件事 我簡單說明一下爲什麼我會這樣做，給大家參考 --- 我是 79 年次，2013 年退伍的，大學資管系畢業 出社會第一個月我就發現，我滿不喜歡上班的，但是我沒有能力、也沒有錢創業 於是我設計了一個我稱之為「三把梯子」的方法論，作為長期生涯指引 # 三把梯子理論 第一把梯子是上班：成為資深工程師、跳槽更大公司、賺更多薪水，這樣不斷往上爬 第二把梯子是接案：接親戚朋友介紹的案子、累積個人品牌、得到更多的客源，開公司接案，這樣不斷往上爬 第三把梯子是創業：研發軟體產品，從 side project 開始，從 open source 開始，學習行銷，學賺錢、寫更多產品、開公司創業，這樣不斷往上爬 基本上就是上班族、自由工作者、創業者三種職業生涯 --- 我給自己的三把梯子指引是：先從第一把梯子開始往上爬，稍微爬一段，就往旁邊的第二把梯子踩過去，接著爬 接著在第二把梯子慢慢往上爬，稍微爬一段，準備好了就往第三把梯子爬過去，慢慢往上爬 在這個過程中，只要覺得腳步沒踩穩、會摔死，就往回踩過去，爬前一把梯子 你可能覺得很離譜：想要同時兼顧三件事，不就會變成通通都搞砸嗎？ 其實，你只要... # 做同時對兩三把梯子有幫助的事情 職涯的大方向有了，接著就是付諸行動，要做一些能「同時對兩三把梯子有幫助」的事情 ## 部落格 我在 2013 年想到的事情是「寫部落格」，我非常勤奮地寫了兩三年，很多文章都還找得到 - https://blog.turn.tw/ - https://startup.turn.tw/ - https://dev.turn.tw/ 寫部落格、並且試著得到流量，會同時學到寫作、銷售、溝通能力，對三把梯子都會有幫助 我在寫到多篇文章都有數十萬瀏覽量之後，我就大致知道自己掌握這項技能了 ## 研討會 接著我想到的事情是「參與 conference 分享」 其實這沒有大家以為的那麼難，算是寫作的延伸加強版而已，拿原創的文章去一些小聚、研討會發表 我在成為 PHPConf Taiwan 2015 以及 LaravelConf Taiwan 2018 的講者之後，我就大致知道自己掌握這項技能了了 ## 做專案 再來是「寫 side project」以及做「open source」 一開始可以先做好玩為主，但之後要稍微從一些商業野心出發，才能學習 `monetization` （賺錢）這件事 我做了一些專案，在國內外論壇到處分享，成績馬馬虎虎，但我也學到很多 --- 上面這三件事情，會同時對「前兩把梯子」有巨大幫助，在找工作、或者接案的時候，很多人會更信賴你，對第三把梯子也會有點幫助 當然，像這樣同時爬三把梯子，沒辦法跟「專心爬一把梯子」的人比，這是一定的，而且要付出的時間相當龐大 但是，這讓我獲得足夠的安全感，避免一次做太高風險的事情，而且也有後路可退 # 我目前的三把梯子的進度 第一把：我現在去投履歷、找工作，在各種大小的公司都還是有面試機會，也有很多業界的朋友可以幫忙介紹，要上班沒問題 第二把：在完全不主動去找案子的情況下，很多朋友會幫忙轉介紹案子給我 我也是美國接案平台的簽約工程師 https://www.toptal.com/resume/chuan-hao-you 有時會接一些歐美的案子，所以要接案沒問題 第三把：我大概做了70個左右的 side project 目前正在經營的有這幾個 梗圖工具 https://memes.tw/ 每月60萬不重複使用者 咖啡廳資料 https://cafenomad.tw/ 每月3萬不重複使用者 活動平台 https://yii.tw/ 每月2萬不重複使用者 工程師交流 https://codelove.tw/ 您目前正在看的網站 另外還有 房地產 https://landchart.tw/ 書評網 https://wenwen.life/ 美女圖 https://beautyhunt.tw/ 批踢踢閒逛 https://www.ptt.best/ 這些網站，其中有幾個，是有一些收入的，所以第三把創業的梯子也還可以 目前這三把梯子，其實我都還正在爬，並沒有最後一定會待在哪一把梯子上面 # 結論 這邊簡單分享我替自己設計的職業生涯，「三把梯子」算是一種很偏激的職業生涯 業界像這樣做的工程師應該非常少數，最大缺點就是要花費的時間非常多，優點就是，其實樂趣不少 其實，學無止盡，這就只是同時在「技術」跟「商業」兩方面花時間學習而已 能分享的事情還有很多，大家有興趣就多多按讚吧，也許我再多寫一些這方面的文章！ 也歡迎大家多多發表文章，這個 CodeLove 就是我做來給工程師們互相交流的地方！ 以上簡單分享，希望對你有幫助～！
某種角度來說，我認為當工程師是很幸運的，能有兩種角度去經營個人品牌：菁英路線 vs 社群路線 --- # 菁英路線 菁英路線就是想辦法得到頂尖軟體公司的認可，比如說 Google Facebook Microsoft IBM 或者台灣本土一些知名軟體公司 或者矽谷一些設點在台灣的軟體公司 這種通常要刷 LeetCode、做大量面試準備、可能大學學歷也要很好看 這種履歷表一但有了一間，後面一間一間換，整個履歷表看起來就很漂亮 薪水好 社會地位高 大家都覺得你超猛 但這路線只適合少數人 # 社群路線 社群路線我覺得簡單、好玩很多 就是每當你的實力有所成長，就找機會大方分享 不論是寫網誌、報名 conference 分享、報名小聚分享 或者參與 open source 討論、發 PR、在 stackoverflow 問答 都是很好的貢獻方式！重要的是，這些貢獻最好能量化、有相關網址連結，在投履歷的時候可以附上 也可以在個人檔案頁面附上，這樣才能越累積越多、讓人一目瞭然 如果是在聊天室參與討論、在 FB 社團參與討論，就很可惜，相關貢獻沒辦法變成單獨網址、附上履歷表 這種路線經營一陣子後，在業界的工作機會、接案機會、合作機會，也會多很多 --- 第一條路線是面對少數人，爭取他們的認同，也就是其他精英、以及公司面試官的認同 第二條路線是面對社群，爭取他們的認同，也就是面對社群五花八門的意見、各類不同族群 就我個人來說，我是走第二條路線，這跟個性有關 --- 身為軟體工程師，我認為至少要在其中一種路線，稍微有所經營 職業生涯上，才會有點安全感，不然會常常有被淘汰的擔憂、面臨社會新鮮人競爭的擔憂
最近在幫客戶專案寫 e2e 測試，發現幾個常見錯誤 首先，e2e 跑起來很慢，會拖慢 CI 速度，應該不是多多益善，而是要挑高價值的來寫 很多基本狀況、訊息提示、UI 表現，應該要用 unit test 來處理，vue 與 react 應該都有對應的 `component test` 工具可以寫 --- 再來，e2e 處理的情境要怎麼切分？這是典型的程式邊界（boundary）問題，也是 `抽象化` 問題的一種 網路上四處找範例，沒找到比較好用的設計方法，我試著自己設計 目前思考出幾個參考原則，要同時符合以下條件，才放進 e2e 測試 - 高價值原則：如果用戶處在這個情境，然後測試跑失敗了，老闆會很緊張，工程師就算在週末也需要緊急修理 - 變動頻繁原則：相關程式碼經常變動，所以每次在 CI 都跑測試會很有幫助 - 最後手段原則：這裡提供的安全感，沒辦法用 unit test 或 integration test 取代 --- # Refs - https://filiphric.com/how-to-structure-a-big-project-in-cypress - https://sendgrid.com/blog/ideas-for-configuring-organizing-and-consolidating-your-cypress-tests-frontendtwiliosendgrid/ - https://www.linkedin.com/pulse/organizing-maintaining-your-cypress-test-suite-best-kate-serebryakova/ - https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests
想玩一下 stable diffusion 在 macbook 嘗試了一下 不太好安裝 拿出家中的老舊筆電 2018 年買的 asus zenbook 上面有雙系統 ubuntu 18.04 不過顯卡一直沒有順利啟用 不管了先用 cpu 硬跑 https://github.com/AUTOMATIC1111/stable-diffusion-webui 按照 repo 指令照做 然後我有參考這篇文章 亂跑一些 pip 安裝指令之類的 反正亂裝一通 https://zhuanlan.zhihu.com/p/628058158 在執行這個時 會遇到很多錯誤訊息 ``` ./webui.sh ``` 在 terminal 先設定一些環境變數 好像是關閉搜尋顯卡吧 ``` export COMMANDLINE_ARGS="--skip-torch-cuda-test --precision full --no-half" ``` 就可以了 實際跑起來，產生一張圖，大概要 5 分鐘左右
阿川收到網友提問如下： > 阿川您好 我是一位工業設計師，最近想轉職前端工程師，但年齡已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 社團，多觀察為主 以上，簡單幾點分享，希望對你有幫助，祝各位轉職順利！
租用了新的雲端主機，有一天發現全部線上網站都掛了 經檢查發現是硬碟被吃光了，但是我應該沒有存那麼多資料＆圖片才對 使用指令慢慢檢查根目錄，在查到 var 時 ``` du -sh /var ``` 發現是 var 資料夾佔用了 125 GB，顯然問題就在這裡 接著使用 ``` du -h /var ``` 發現疑似是 mysql 資料夾，佔用大量硬碟空間 繼續使用指令確認 ``` du -sh /var/lib/mysql ``` 以及查看細節 ``` du -h /var/lib/mysql ``` 發現就是這個資料夾沒錯，cd 進去 ls 看一下，看到大量的 binlog 檔案，命名類似這樣 ``` ... binlog.000738 binlog.000739 binlog.000740 ... ``` 經研究，是 mysql 某種備份機制，暫時不深入研究，我目前不想使用這個備份功能 --- 輸入以下 SQL 緊急移除這些備份 ``` PURGE BINARY LOGS BEFORE NOW(); ``` 硬碟緊急狀況排除！ --- 接著要避免之後再出現這個問題 參考這篇做法 https://askubuntu.com/questions/1322041/how-to-solve-increasing-size-of-mysql-binlog-files-problem 建立獨立檔案，方便日後維護 ``` touch /etc/mysql/mysql.conf.d/howtomakeaturn.cnf ``` 放入以下內容 ``` # Added by howtomakeaturn at 2023-08-15 because of 100% disk usage issue. [mysqld] log_bin = # turn off binlog_expire_logs_seconds = 86400 # 1 day max_binlog_size = 104857600 # 100M ``` 完成之後重啟資料庫 ``` service mysql restart ``` 大功告成！應該大致關閉 binlog 功能了，持續觀察幾天看看！
大家好，我是站長阿川 我留意到 LINE 群組的討論非常踴躍 很多迷惘、想轉職的新手，各種發問，都有業界工程師幫忙回答，非常熱心！ 各位很多的回答「非常詳細」，完整到我覺得：只有群組內的新手看到，也太可惜！ 應該讓網路上更多人都能看到，這樣更造福眾生、未來有人 google 搜尋也能夠找到！ 繁體中文社群，需要知識不斷累積。如果一直在 FB 等等聊天室討論，然後被洗掉，有點可惜！ 這也是我建立 CodeLove 網站的初衷！所以我設計了一個新計畫，跟大家分享一下！ # CodeLove 前輩分享寫作計畫：VIP 審核限定 我鼓勵大家，在回答新手之餘，如果覺得 LINE 訊息文字篇幅不夠，或是 LINE 程式碼排版不易 請直接在 CodeLove 寫一篇完整文章，然後再貼到 LINE 群組內！ 舉例來說，我自己就有這樣回答 LINE 群組新手的習慣： [轉職軟體工程師的方法很多，到底該如何選擇：實體補習班、線上補習班、不花錢自學？](https://codelove.tw/@howtomakeaturn/post/NxN2Kx) [回答網友提問：如果前端要銜接後端的話，是不是學 node.js 比較快？](https://codelove.tw/@howtomakeaturn/post/2anP0x) [回應網友提問：我是新手前端，公司叫我學一點 php + laravel 串 API，該從哪邊學起呢？](https://codelove.tw/@howtomakeaturn/post/Zq4Ona) # 如何成為這個計畫的 VIP？ 原則上只接受「業界工程師」加入，也就是有工作經驗者加入！ 就算只有一年工作經驗，也是正在轉職的新手的前輩，所以也歡迎！ 越資深的話越好，因為您有大量的知識＆經驗可以分享！真的是大前輩！ **請在 CodeLove 網站上，任意發表一篇技術文章 or 工作心得，完成之後，點擊下方 LINE 群組加入：** https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 經過我審核之後，您就加入這個 VIP 群組了！ （例外情況：您是學生，但明顯有極大分享熱情＆知識，也會允許加入） # 身為這個群組的 VIP，可以幹嘛？ 首先，我希望您寶貴的文章，能被儘量多的讀者看到！ 您只要負責寫作就好，我會幫您「製造精美封面圖片」以及「行銷宣傳您的文章」！ 凡是 VIP 前輩發文，我都會在有超過三百人的群組「愛寫扣論壇：發問&交流&討論群」轉貼，並且「設定為公告置頂至少24小時」！ 再來，VIP 群組內都是「樂於分享、經驗豐富、寫作能力出色」的業界人士，大家可以在小群組內交流，我認為互相交換情報，也很有價值！ 最後，如果我覺得您的文章實在應該被「成千上萬的更多讀者看到」，我會直接到各大論壇，到處轉貼宣傳您的文章，類似下面這樣： - https://www.dcard.tw/f/softwareengineer/p/252600314 - https://www.dcard.tw/f/f2e/p/252598230 - https://forum.gamer.com.tw/C.php?bsn=60076&snA=7835159 - https://forum.gamer.com.tw/C.php?bsn=60292&snA=8421 我會確保您的文章被數千、數萬人閱讀！身為寫作者，通常文章四處發表，會到處被不同工程師嘴砲、開嗆，沒關係，這很正常，我會擋在砲火最前面！您不用被這些負面訊息轟炸，我只會回報有意義的正面留言給您！ 如果有很棒的留言或 feedback，我會貼回 VIP 群組內通知您！ # 我想加入，但我沒什麼寫作靈感，怎麼辦？ 首先，如果您有想發表的技術文章，當然可以直接當成寫技術部落格，寫一篇發表！ 再來，您可以在 LINE 群組，看看新手們都在問些什麼，然後就當作在回答他們，直接公開寫一篇完整回答！ 最後，也可以是您近期的一些技術筆記、工作隨筆，稍微整理之後發表，這種筆記也常常對後人很有價值！ # 結論 我真的覺得繁體中文世界，需要有一個優質的討論區、寫作園區，知識才能有效累積，這個國家的軟體產業才能進步、發達 另外，這個 CodeLove 論壇是有 [文章 API](https://codelove.tw/@howtomakeaturn/post/jqeDka) 功能的 您可以在這邊大量寫作，之後呼叫 API 串接到自己的部落格，markdown 格式與 html 格式的轉換我都已經幫您做好了 以上，各位熱心的工程師，誠摯歡迎您加入「CodeLove 前輩分享寫作計畫」！一起造福眾生吧！ https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 有問題歡迎直接留言與我討論！
現在內文出現 youtube 網址的話 會自動偵測＆轉為 iframe 方便顯示 --- 謝謝 @JsLover0018 的建議
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆剛轉職的新手在討論： 公司有實施 WFH 在家工作制度，但沒人可以詢問、經常怕自己漏看訊息、整天感覺更焦慮了，怎麼辦？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享 --- 首先，我認為 WFH 是一種「團隊技能」，也就是説：這不是一個人就能做好的事情，需要整個團隊的合作 再來，因為是技能，這不是每個人一入職就會的東西，需要經過訓練 總體來說，我認為要習慣「新的四種溝通方式」，分別說明如下 # 批次溝通 在辦公室大家可以隨時找同事討論、發問，也可以臨時團隊開會之類的。 遠端工作很難這樣做。因為人與人溝通的頻率被迫降低了，所以每次溝通的內容量要提昇。 建議養成批次溝通的習慣。也就是一次詢問多個問題、一次安排多個工作事項。 舉例來說，大家早上團隊視訊/語音開會的時候，不要只是每個人安排一天的工作量，最好把一整週的工作事項都先預排好。 這樣一來，當你手上的任務卡住，需要詢問別人問題、等待答覆、等待別人工作先做完時，可以先改做其他待辦任務。 這會讓負責安排工作任務的主管，工作難度提高不少。但習慣一下會發現效果很不錯。 發問的時候也是一樣。可以拿筆記本、或是在電腦開個檔案，整個早上陸續遇到、想到的問題，都記錄下來。 下次終於有機會跟同事通話時，一口氣問清楚。 就算只是用聊天室也一樣。 我常常一口氣丟出好幾個不同事項的不同問題。反正同事有空再逐一回答即可。 # 過度溝通 遠端工作絕對要避免這個狀況：因為溝通誤會，導致做了整天的白工。 絕對不可讓這種情況發生。平常在辦公室，隨時都能知道同事在幹嘛、有疑問也可隨時跟主管確認。在家工作可不行。 所以要養成過度溝通的習慣。我自己習慣是剛剛視訊時已經講過的事情，結束前我會再統整一遍、然後每件事描述確認一次。 結束之後，還會把我剛剛確認的事情打成幾個待辦，貼到聊天室讓對方再看一次。等於每件事我都跟對方確認2-3次。 我甚至會把同樣幾件事情，換個方式、換個角度再重新描述幾次，讓相關人都同意，我才放心沒有做錯方向。 有留紀錄的話，事後出問題也比較容易討論責任歸屬。 總之，在家默默工作幾天，然後才發現通通在做白工，是絕對不可以發生的。 如果你發現在家工作之後，自己會一直跟同事確認事情，或是同事會多次重複確認同樣的事情，好像大家變得有點神經質？ 別擔心，這不但是很正常的現象，還是很鼓勵的現象。 # 被動溝通 拍同事的肩膀問問題、叫他過來開會、打電話給他…等等，屬於主動式溝通：以發問的人優先，被問的人配合發問的人的時間。 貼便條紙給同事、張貼事項在公告欄…等等，屬於被動式溝通：以被問的人優先，發問的人配合被問的人的時間。 被動式溝通以被問的人、接收訊息的人為主，有空時才答覆、做出反應。 遠程工作的團隊一定要習慣被動式溝通，否則遠程工作就沒有意義，也沒有效率，會變成很痛苦的事情。 網路時代讓被動式溝通輕鬆許多，只要採取多層次溝通就行了。 # 多層次溝通 多層次溝通指的是依照主動/被動程度的不同，分成至少3-4層溝通工具。舉例來說： 即時溝通：見面、手機/Skype/Hangouts/Zoom 通話 通訊軟體：Skype、Line、Facebook Messenger 工作聊天室：Slack 任務管理軟體：Bitbucket/Github、Trello 即時溝通是最主動的一種，碰面開會、打電話等等都算。在很多情況下，還是需要用這種方式討論、腦力激盪。最好每天約個固定時間線上通話一下。 通訊軟體則是次之的溝通方式，但因為訊息通知會一直跳出來，還是有點干擾。 工作聊天室是最常發生溝通的地方。這類工具的特色在於，忙著工作的人，可以直接把聊天室關掉，就不會被打擾。有空時再打開來看看有什麼需要回答的、討論的。 任務管理軟體是大家一起紀錄工作待辦事項的地方。需要日後方便翻閱的東西都記在這裡。 其它工具軟體像是 Google Docs、Google Sheets、hackmd 也都非常好用。 --- 以上是四種 WFH 個溝通方式，另外有兩點補充 # 被動式溝通優先，非必要不使用主動式溝通 上面提到的多層次溝通模型，越上面是越主動，越下面是越被動的溝通方式。團隊成員要慢慢習慣，非必要別使用主動式溝通。沒那麼急著得到答覆、急著需要處理的事情，就盡量用被動的手段溝通。 話雖如此，每天慣例性地在固定時段通話一次，可以大幅增加團隊的安全感。 # 每次開會都做線上筆記，所有檔案都對所有人公開 因為大家沒待在一起，開會完忘記會議細節的話，會需要一直詢問同事，很浪費時間也很煩。 所以開會時建議使用 Google 文件、hackmd 或是其他可以共同編輯的軟體，開會的時候一邊做線上筆記。 然後這些文件最好公開給整個團隊的人看到，讓全部資訊同步到全部人腦中。 這些技巧熟練之後，團隊成員不但可以專心工作，溝通能力也會全部上升。 像是跟客戶、合作廠商溝通這種本來就需要遠端溝通的任務，remote 工作者也比一般的工作者更知道怎麼溝通、避免溝通誤會。 # 結論 這些工作方式有點違反一般的工作直覺，所以容易被忽略。 但只要習慣一下，一定會發現遠端工作的好處，工作效率甚至比在辦公室更高。
在我們新手寫程式 LINE 群組，有幾個業界工程師＆想要轉職的新手在討論： 非本科轉職，到底要學什麼語言？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這個問題在群組中，重複出現快十次了！ 我決定設計一個量化指數，給大家參考，一次回答這個「大哉問」！ --- # CodeLove 程式語言新手友善指數 - 簡介 我設計的這個指數，我命名為「CodeLove 程式語言新手友善指數」 因為每次有人問我，我都是請對方報名補習班之前，先打開人力銀行，親眼看一下那些職缺＆產業是否喜歡！ 如果歡迎新手的職缺很少，那這個語言不管多強大、多好學，在台灣都不能算是適合新手！畢竟大家轉職就是想儘快找到工作！ 指數公式是這樣： - 打開 104 人力銀行，搜尋「某某程式語言」、只搜尋職務名稱、經歷要求1年以下，得到歡迎新手的職缺數 X - 打開 1111 人力銀行，搜尋「某某程式語言」、僅搜尋職缺名稱、工作經驗選無經驗，得到歡迎新手的職缺數 Y - 把 X + Y = 最終結果 這個最終數字，大概就是你今天去找工作，市場上歡迎你這種非本科、無經驗的職缺數量！ 不論你是補習班畢業或者自學結束，請參考這些數字：願意給你機會的職缺大概是這麼多！ --- # CodeLove 程式語言新手友善指數 - 2023年8月份排行榜 - `#1` Java (267) - `#2` C# (241) - `#3` PHP (167) - `#4` Python (87) - `#5` Golang (32) - `#6` Ruby (3) - `#7` Rust (2) # 結論 非本科轉職，到底要選什麼程式語言？ 你當然要綜合考量： - 有沒有喜歡的補習班開課 - 程式語言本身的學習難度 - 身邊熟識的工程師是專精哪個 - 相關的免費、付費線上自學資源多寡 我知道，上面這個指數，公式過度簡化，但至少有個參考數字！ 我有留意到，有些人，因為煩惱這個問題，重複研究了很久，遲遲做不了決定，很害怕選錯 實務上，有些職缺會貼在 FB 社團、或其他人力資源網站、有些職缺沒把語言寫在「職務名稱」上，所以真正的職缺其實更多！ 我個人認為，1 ~ 4 光看數字就知道還不錯！有心動的課程就去報名吧，別一直胡思亂想嚇自己！ 5 你就再多多評估、研究一下！應該也還行！ 6 7 這種數字，我只是想說明，如果你有認識的工程師，推薦你非本科去學 Ruby 或 Rust，那你可能要同時請他推薦職缺了！因為幾乎沒有願意給你機會的職缺！ 以上，簡單分享，希望對你有幫助！ 可以留言：你想看的程式語言，我找時間做一份更新、涵蓋更多語言的！
歡迎最近新註冊的用戶 @q30030110 @snow @a23455116 @john76391 @ayakaka201 @codenoob2023 @phil 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
手上有多個網站 都是 Laravel 5.8，放在一台 Ubuntu 18.04 的機器上（租用 Linode 機器） 四、五年了，一直沒去更新，最近終於下定決心來更新 首先把 Laravel 5 -> 6 -> 7 分多次升級，然後部署 都還算順利，官方的 upgrade guide 很清楚，簡單照做就完成 但是無法升到 laravel 8 因為需要 php 8 我那台 ubuntu 18.04 安裝 php 8 一直失敗 直接升級 OS 也失敗，一堆問題會出現 最後決定，在 Linode 租一台新的 Ubuntu 22.04 然後把專案通通搬過去 --- 因為專案中很多「用戶上傳的圖片」放在 local，所以都需要一起搬運 最後是用 scp 硬搬檔案 然後用 mysqldump 搬運資料 才終於順利升級到 laravel 8.83 了 詳細用到的指令大概像這樣 ``` scp -r [email protected]:/{PATH}/{FOLDER} /{PATH} scp -r [email protected]:/etc/apache2/sites-available/{CONF_FILE} /etc/apache2/sites-available/ a2ensite service apache2 reload create mysql user & database with phpmyadmin mysqldump --column-statistics=0 --default-character-set=utf8mb4 -h xxx.xxx.xxx.xxx -u {USER} --single-transaction -p{PASSWORD} {DATABASE} > /home/dump.sql; mysql -u root -p{PASSWORD} {DATABASE} < /home/dump.sql artisan down legacy site composer install -> new site is now online ``` --- 簡單筆記分享一下，希望能幫到一些人～ # Refs - https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-22-04#how-to-find-your-server-s-public-ip-address - https://itslinuxfoss.com/install-laravel-ubuntu-22-04-lts/ - https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04 - phpmyadmin password left blank, so it's random now - https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-phpmyadmin-on-ubuntu-22-04 - skip the whole Step 2 — Adjusting User Authentication and Privileges - `ssh-keygen` because I need a public key
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆新手在討論： 如果前端要銜接後端的話，是不是學 node.js 比較快？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情 --- 首先，我很推薦新手前端也去學一點後端，這樣對整體概念會更清楚 這位網友提到的 node.js 很不錯，但是我更推薦去學 php，簡單幾個原因說明如下 # 無框架開發 常見的後端語言，在寫網站時，都需要套件＆框架才能開發 - python 需要 django - ruby 需要 rails - java 需要 spring - node 需要 express 我建議你直接寫 php 做好玩的小網站，不要用框架 php 雖然現在都用 laravel 框架，但古早時代大家都寫純 php 如果現在只是自己做個小專案，當然寫純 php 也是夠用的 學框架沒什麼不好，但是，在新手一開始的階段，我更推薦從單純的東西開始學起 一來上手很快，二來等於是紮穩馬步，三來之後學框架可以去思考：如何用純 php 語言寫出框架元件 如果自己想補充後端知識，就試試純 php 吧！先別學 laravel，晚點再去學就好 # 後端先避免非同步程式設計 這件事比較 tricky，javascript 語言本身支援非同步，這在前端 UI 處理很好用 也就是常用的 async/await，`.then().then().then()` 或者到處傳 callback function 那些的 但是！我認為在寫後端的時候，這個語言特色會讓後端開發時，顯得有點囉唆 以後端讀取檔案內容來說，絕大多數情況下，你就是要現在就讀取好檔案、讀取完才讓程式接著繼續跑，才有意義 幾乎不存在「非同步去讀取檔案，不等結果，先直接去處理別的任務」這種情況 於是 node 後端程式碼就需要去傳 callback function 或者 async/await 我認為這有點囉唆，這些情境實在沒必要用「非同步程式設計」處理！ node 社群自己也知道，所以除了 `fs.readFile` 之外，還有提供 `fs.readFileSync` 函式 作為一個教育者，我很不喜歡跟新手解釋，為甚麼會有這兩種函式，差異在哪 我認為新手後端，多去學非同步程式設計的觀念與技巧，是徒增挫折 用 python/php/ruby/java 寫後端，都不會遇到這個困擾 新手後端就學好 http 協定，GET 跟 POST 參數是怎麼傳遞的，怎麼使用 session，怎麼連接資料庫就好了 不要多被一個 asynchronous programming 困擾 # 多學一個程式語言 本身是前端工程師，再去學後端想用 node 繼續寫 javascript 當然很合理 不過，長遠來說，多學幾種程式語言，對職業生涯比較健康 首先，你會更有自信一點，並且，能夠開始比較各種程式語言的差異與哲學 很多在 A 語言理所當然的事情，在 B 語言是很罕見的 很多在 A 語言社群大家都說「對」的事情，在 B 語言社群大家都說「錯」 長遠職業生涯來說，你需要至少寫過多種程式語言，才會發現大多數事情都只是「不同社群」的「主觀偏好」 你會發現網路上多數講的斬釘截鐵的對錯觀念，都只是一種偏執。你的觀點會更全面 # 結論 以這位網友的狀況來說，本身是前端，其實，學 nodejs 或 php 都不錯啦 我個人是偏好 php > nodejs 一點，這樣 以上，簡單分享，希望對類似狀況的朋友有幫助！
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆剛轉職的新手在討論： 我是新手前端，公司叫我學一點 php + laravel 串 API，該從哪邊學起呢？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情 --- 我猜你面臨的情況，老闆不是真的叫你從無到有寫後端，應該是去硬改現成的後端專案 因為是公司馬上需要的，先求速成為主，背後細節就先別管了 就分幾個步驟來做吧 # Step 1 laravel 官網 `Installation` 章節讀一讀，然後看你用什麼作業系統，網路上 laravel 安裝教學找幾份試試看 先想辦法把環境跑起來，讓目前專案可以在電腦上跑 然後找一款有 GUI（圖形化介面）的資料庫管理軟體，在 UI 上點一點，準備好資料庫 # Step 2 `Routing` `Controllers` `Requests` `Responses` 這幾個章節讀一讀 至少稍微看懂，後端是哪些地方在接收參數、回應參數 # Step 3 把 `Eloquent ORM` 章節讀一讀，這個類別提供很多神奇的方法，很輕易就能做到 CRUD 至少稍微看懂，後端是哪些地方在跟資料庫互動，自己有辦法新增資料、更新資料、刪除資料這樣 --- 除此之外，上網找幾份 laravel 的簡易 CRUD 範例教學，不太懂背後原理沒關係，按照指示，做個部落格之類的 然後就去硬改公司現成的後端專案，頂著用，不然短期內也沒辦法真的學精 laravel，就先這樣吧！先能滿足公司需求就好！ 其實，以上所說，真的是很混的學習方法：ORM 背後的觀念、資料庫的 SQL 觀念，幾乎都沒學到 長遠來說，如果是真的要學 php + laravel 後端，我都是建議先從「純 php + mysql」開始學起 也就是我鼓勵新手用純 php 寫一個部落格網站，寫純 SQL 去連接資料庫，先搞懂這種最純粹的寫法 然後再開始學 laravel 以及 ORM 等等好用套件工具 不然的話，我知道很多人直接從 laravel 開始寫起，半知半解，工作很久了，卻連哪些功能是 php 提供的，哪些是 laravel 提供的都分不出來 然後在需要換框架 比如 CodeIgniter 或者 Yii 的時候，很多觀念無法融會貫通，長遠來說，根本事半功倍 --- 話說回來，如果老闆不是叫你硬改現成的後端專案，而是叫你從無到有寫後端 那這工作內容實在不太合理，除非你一開始應徵的就是「全端工程師」的職缺＆薪資 以上，簡單幾個方向分享，希望對你有點幫助！
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆想要轉職的新手在討論： 實體補習班、線上補習班、不花錢自學，推薦哪種方法？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 看完大家的討論，我決定整理大家的討論內容，寫一篇指南 --- 我認為半路出家者，經濟壓力很大，要兼顧成本＆時間，以下是我推薦給大家的判斷方法 首先，先教大家怎麼挑選程式語言，你可能在考慮 PHP JavaScript Python 之類的 各種程式語言，通常會跟產業類型相關，不同產業偏好不同程式語言 請打開人力資源網站，看看各語言有哪些職缺、以及職缺數量，看看這些公司是不是你有興趣的 然後看看這些職缺「無經驗可」的比例如何，很多的話表示歡迎半路出家者 還是通通都要求「一年以上工作經驗」，那就表示不歡迎半路出家者＆新手 很多台灣的程式語言 FB 社團也可以先加，裡面很多職缺資訊，就一起看看 先鎖定幾個你覺得可行的程式語言，接下來進入以下流程： # 先問自己第一個問題：我身邊有沒有可以請教的工程師？ 兄弟姐妹、或是很熟的朋友、同學，都可以，要是一個你「極度信賴」的人 這樣他幫你推薦大方向時，你不用擔心他在敷衍你 他不用像保母一樣每天在你旁邊陪你、幫你解答問題（這樣是在凹他） 但在你卡關的時候，至少可以跟他請教解決的方向 然後他最好可以協助你找「技術書籍」、「免費/便宜影音課程」 如果這題的答案是 YES，你有機會在極少花費之下，就轉職成功 如果答案是 No，請往線上補習班的方向查詢，進入下一個問題 # 第二個問題：這間線上補習班有沒有導師、助教制度？ 這類課程收費大概數萬元，通常會幫你排進學期內，安排導師、助教，自己在家看影片 我推薦這方向，是因為在教室上課，你可能跟不上，會很悲劇 在家看影片，可以按照自己節奏、可以重複觀看 因為你付了數萬元，卡關時，趕快請教導師、助教 我認為這方向不錯，費用也合理，缺點是，線上補習班的選擇不多，你想要的程式語言，可能沒有業者在開課 如果這題的答案是 YES，多查一下學員心得分享、確認一下學員就業成功率，就上吧 如果答案是 No，請往實體補習班的方向查詢，進入下一個問題 # 第三個問題：有沒有政府補助可以申請 這類課程大概要求你全職上課半年左右，收費十萬元以上 我聽過太多進教室之後跟不上進度，花費半年、十幾萬元，最後轉職失敗的慘痛案例 職訓局、勞工局、勞動部，有時會有一些補助可申請 如果政府出錢，那就去吧，至少風險少很多 --- 如果以上問題答案通通都是 No 那就是要自己出錢、花半年去教室上課了 請務必貨比三家、謹慎再謹慎、多查詢學員心得分享、確認就業成功率 值得一提的是，有些小班制的業者，老師極度有經驗＆教學熱情，你會看到超多推薦心得文 如果查資料過程中，發現這種老師，那就沒問題，他將會是你的貴人 如果是大品牌、大班制，你拼一波就報名了，我真的覺得很像在賭博，賭你會遇到好老師、賭課程安排你吸收得了 就我的觀察，這些大品牌，很多課程內容，實在太包山包海了，我看了很不喜歡，我覺得90%學員會吸收不良，什麼作業跟專案，簡直就是助教在幫你寫，只是貼一貼改一改，跑得動就畢業了，學員自己心裡都很不踏實 多花點時間查畢業學員評價吧，也多跟業者詢問、聊聊，真的心動了，就衝吧，也沒其他方法了 以上，簡單幾個問題，希望對你找方向有點幫助！
除了幾間知名的人力銀行網站之外 有些ＦＢ社團也常常有職缺資訊，可以逛一下 https://www.facebook.com/groups/javascript.tw https://www.facebook.com/groups/javascript.html.css.node https://www.facebook.com/groups/f2e.tw 還有像這種 github 頁面也有職缺 https://github.com/f2etw/jobs/issues 加油囉各位！
阿川收到網友提問如下： ``` 我最近有在看前端的一些基礎課程，想問問如果32歲想轉職工程師是不是不吃香😅畢竟我也不是本科的 ``` 看過很多人提出類似問題，寫一篇公開回答跟大家分享，給類似狀況的人參考。 --- 首先我自己親自指導過轉職的，年齡最大的是31歲、非本科、私立科大夜間部，原本在餐飲業 在網路上搜尋「30歲轉職工程師」、「40歲轉職工程師」、「50歲轉職工程師」 會發現30歲相關文章很多，大家議論紛紛 40歲相關文章比較少，持鼓勵、正面意見的佔少數 50歲相關文章，一篇心得分享都沒有 我建議把幾歲轉職當成是一個「漸層問題」，不是非黑即白的「二元問題」 也就是年紀越大越難，但沒有過了幾歲就一定不行這種事 --- 再來我認為要務實一點，不論自學或上課，半路出家至少也需要2個月～6個月的時間 請減少生活開銷，然後原本工作可以的話，先別辭掉，利用晚上＆週末的時間進修，壓力也小一點 不然壓力大到睡不著覺的話，精神不佳，學習效果怎麼會好呢？ 然後建議多找幾種學習方法試試看，如果一種不行，就換另一種方法試試 別太快覺得「自己不行」，說不定是「老師不行」，或只是方法不適合你 我建議先大量找免費或便宜的教材，先吸收，多試幾份，真的卡關了，再開始挑補習班 先直接找一些作業跟專案寫寫看，從免費 -> 便宜的 -> 稍貴的，這樣一點一點花錢，風險比較小 更認識自身需求之後，再去比較市面上的各種補習班，最後再把這錢花下去，比較保險 --- 最後我必須說，2023 全球軟體業狀況比較嚴峻，目前職缺好像比較緊縮，不知道何時會恢復 這跟 2008 年金融海嘯出社會的新鮮人狀況一樣，就是比較倒霉 反正轉職過程中，記得早點開人力銀行等等網站，看看職缺狀況，心裡有個底，知道一下要面臨多少競爭 順帶一提，我也有設計免費的 html&css 教材，還有優惠的 javascript 教材，內含「大量練習專案」，不論你最後選擇哪種學習方式，我都推薦搭配拿去學習、練習，稍有難度，但不少人全做完之後就順利面試上班了 以上，祝各位轉職順利！
大家來加 LINE 討論群組 方便交流 方便提問 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 加吧！
# Understanding Asynchronous JavaScript https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff 解釋 js 底層的 call stack、event loop、message queue 以及 Promise 用到的 Job Queue/ Micro-Task queue 是如何運作 比較硬核，讀了會更認識 js 底層機制 --- # The Best Explanation of JavaScript Reactivity 🎆 https://medium.com/vue-mastery/the-best-explanation-of-javascript-reactivity-fea6112dd80d 現在眾多前端框架普遍會自帶 Reactivity 效果 這對開發 UI 很有幫助，很方便 文章介紹多種實作方案、優缺點比較，以及最終方案 --- 兩篇很棒的文章
歡迎最近新註冊的用戶 @m0617ICO @JimmyOmg @wimp9487 @yamak @ablaze 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
阿川近期收到網友私訊詢問，簡單來說，就是他報名了某補習班，需要進教室上課四個月 從設計軟體 figma 到後端 php 到前端 vue 通通都教，最後要分組做一個完整專案 結果吸收不良，感覺什麼都碰、什麼都沒學好，現在糊裡糊塗在搞專案，就算弄出來也感覺很不踏實，怎麼辦？ --- 阿川從過去幾年指導朋友半路出家的經驗、幫朋友找補習班的經驗，一聽就知道，這種安排，90%的學員會吸收不良 原因主要有兩個 第一，每位學員的積極程度、理解速度，通通不一樣。大家一起進教室聽老師一堂一堂講，一定有人嫌慢，一定有人嫌快 嫌慢就算了，至少該學的都有學到。嫌快就慘了，花了大錢結果跟不上進度，之後還要每週到教室報到，這很折磨人，學習效率也差 第二，半路出家，通常就找「無經驗可，後端」或者「無經驗可，前端」的職缺，先入行，賺點薪水，慢慢累積經驗＆自信就對了 去補習班挑戰四個月學習全端？就算是 full time 上課，我認為還是太硬了，90%的人都會吸收不良，學習效果不好 --- 就我這幾年的觀察，只有兩種人在這環境能順利學習、成長、轉職 第一種，畢業於台大ＸＸ系，在ＹＹ領域工作數年之後，毅然決然辭職，報名轉職軟體工程師成功 這種是學習能力本來就很好，學歷通常就是台清交、只是非本科 第二種，學歷不佳，工作幾年之後遇到重大挫折，有強烈經濟壓力，破釜沈舟之下，抱著巨大的決心、壓力，全心投入補習＆學習 這種是壓力逼迫人成長，在自己給自己高壓＆痛苦之下惡補成功轉職 我認為90%的人，不符合以上狀況，會變成花大錢、花超多時間，最後還效果不理想 最糟糕的是，學習應該是要能逐漸建立興趣＆信心的 這種學習成果，就算最後開始去幾間公司面試，也會超心虛，覺得自己好像來騙的，專案根本自己也沒搞懂幾行程式碼，拼拼湊湊不知道在幹嘛 --- 我在多篇文章提到過，我建議就是先找「便宜、有口碑的線上課程」 至少可以按自己步調學習，至少不會花那麼多錢 然後先專心在前端或後端就好了，可以稍微花點時間碰全端，有一點概念，也很好，但不要嘗試直接專精兩者 學過、有更了解之後，再花錢去補習班。不要一開始就用「賭賭看」的心態進教室，你的時間＆金錢很寶貴 何況很多人就用線上資源學一學，就順利去上班了，有些根本是用國外「免費」資源，一毛錢沒花 --- 最後，對很多人來說，看到這篇文章，時間已經花下去了，錢已經花下去了，怎麼辦？ 阿川還是有些建議可以給大家 第一，全課程這樣上完，雖然吸收不佳，但至少有稍微留個印象 請拿出筆記本，多多做筆記「這邊沒聽懂 但好像很有趣」、「這邊沒聽懂 但老師剛有提到幾個關鍵字」，找時間自己多 google 一下 還有「這邊沒聽懂 但感覺好古板啊 這東西業界真的有用？」，找時間去社團或論壇發問，請教一下業界人士 總之，挑能吸收的部份 加減吸收一點 自主練習時，卡關了，至少還知道點方向 第二，不要太快失去信心 「如何學習」本身就是一輩子的技能，有時是學習方法問題、或節奏問題、或方向問題，先別急著放棄 課堂上的作業，找時間自己重看一次：如果有哪行程式碼不懂，就多 google 或發問，慢慢弄懂，慢慢補回自信 --- 最後，我再補充一個觀念給大家，半路出家不容易，我鼓勵大家把學習想成是一個「逐漸清晰」的過程 看過電腦讀取大張高清圖片的樣子嗎？先是模模糊糊的馬賽克，接著一塊一塊慢慢變清晰，最後才是變成完整的美麗圖片 學習會有點類似這樣，一開始到處模模糊糊的沒關係，保持耐心，逐步提高各處的解析度即可 只要先有一整張模糊的圖片即可。不需要執著在圖片一個角落，覺得這塊不清楚，就不能往下走 更千萬不要因為圖片模糊，就覺得「我果然不適合寫程式，放棄好了」，這絕對是搞錯重點 以上，簡單建議分享，希望對你有幫助！
https://codelove.tw/@howtomakeaturn/course/bap2xj 歡迎寫寫看作業～ 可加強 js 基本功～ 因為，學一點點後端，會讓「前端觀念更清楚」 也就是「基本功比普通前端工程師更強」 並且為更多 js 進階內容打下基礎～ --- @hung @birdie2019 @superyngo 找時間來寫寫看～
這兩家服務好像不錯 https://vercel.com/ https://render.com/ 基本上研究服務，首先點進「Pricing」頁面看看收費，有沒有免費方案，就對了 這兩款，好像點幾下按鈕，就可以從 github 直接把專案部署了，還不錯呀
上次的（十）是純 CLI 應用 先幫大家脫離 ` js 一定是網頁、一定是 html/css 相關` 的刻板印象 接著再回來碰 backend programming 開發，銜接回來 web 領域 這樣才順暢，才不會一直搞混在一起 教材研發中，近期上線，敬請期待～
來，讓我們特別關心轉職成功、上班超過一個月的 @birdie2019 @JoeyLai 是否已掌握公司狀況？ 是否變得越來越有自信？ 最近有學到新東西？ 隨時歡迎上來分享工作筆記 or 上來發問卡關問題～
歡迎最近新註冊的用戶 @pollochang @yydsAwA @learningGG @dyvincent @ian052199 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
收到網友提問如下： ``` 這是最近跟一個朋友聊天聊到的 朋友是寫 .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 等等，就算好幾個月不碰工具，還是能輕鬆解釋，根本不是死記硬背的，這全都是經驗＆融會貫通的結果 但是過猶不及，不顧公司需求，自顧自地研究技術細節也不好 該花多少時間研究背後機制？這是一個需要權衡的問題 請從公司需求的角度，以及個人長期職涯的角度，視情況判斷 以上，簡單分享
收到網友提問如下： ``` 我不知道自己想做前或後端，怎麼辦？ ``` 其實很多人都是這樣，阿川建議「就先都學」！ 如果急著上班賺錢，可以先側重「前端」，然後找個新手友善的職缺就先衝了 因為後端的技術有很多，一開始也不知怎麼挑選 以阿川目前觀察身邊同年紀33歲左右工程師 那些很強的前端或後端，雖然有專精的部份，但其實，同時也是「全端」工程師 同時對前後端保持興趣，有很大的好處 首先，同時學習前後端，會對網路技術生態系，有更深、更廣的了解 再來，是在求職的時候，可以應徵前端的機會，也可以應徵後端的機會 以我自己本人來說，面試上班、或者接案的時候，有時會負責前端，有時會負責後端，工作機會就多很多 最後，擁有全端技能，就算都是初階經驗，也可以在業餘時間做 side-project 甚至是跟朋友一起創業當副業 總之不用一開始就強迫自己一定要選好前端或後端 迷惘、探索、好奇的狀態，本來就是人生的常態 有時間的話，就都學吧！急著賺錢的話，可以先從前端開始～！ 以上，簡單分享
歡迎最近新註冊的用戶 @lrchi1001 @a30870734 @shrdi @sos54610 @nanshiou @dfg312546 @t90920012 @Cloud200407 @tony05060165 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
阿川收到網友提問如下： ``` 哈囉站長你好 我目前有在看蓬蓬的自學影片跟寫你分享的練習題 有件事想詢問一下我目前快26之前的工作經歷跟軟體一點關係都沒有 高職畢業 目前在自學一些程式語言的技能 如果未來要朝這個方向走建議我先去讀個二技相關科系補學歷嗎？ 還是直接找線上課程或補習班轉職謝謝 原本的打算是想說上二技假日進修補個學歷順便幫自己打底 因為網路上看到蠻多分享是上完課後基礎理論不好 想順便詢問一下沒有學歷的話對未來的工作發展影響大嗎？ 還是學歷只是初期比較看待後面看能力這樣子 ``` 寫一篇完整、公開回答跟大家分享，給類似狀況的人參考： # 不建議回學校補學歷 回學校補學歷真的太花時間了，動輒數年以上 何況入學之後還未必喜歡學校、未必喜歡寫程式 業界很多人也是「學歷普普且無經驗」自學4-9個月後，半路出家轉職成功 不論是金錢 or 時間成本來說，都應該先這樣試試看比較保險吧 # 很多人半路出家之後覺得自己底子不好 本科＆非本科，基礎一定有差 但是現在網路資源、書本資源很多 寫網站不是什麼需要博士學位的「太空火箭科學」 工作上缺哪方面，就往哪方面慢慢自己補充，且戰且走也還夠用的 這行業根據職位狀況，難度可深可淺，一開始先負責較簡單的網頁工作也行 發現自己底子不好，趕快花業餘時間，大力自修一下呀 甚至先入行之後，週末再去學校進修，都比較保險吧 # 學歷對未來工作影響大嗎 學歷好看的話，當然在職場上有優勢 但如果態度不專業、工作多年還是沒什麼作品集，那也很難當工程師吧？ 反過來說，學經歷不強的話 如果態度積極，作品集擺開在那邊，就算不是「超猛」的作品，也讓人知道這工程師有基本的「戰鬥力」呀 更不用說，如果積極貢獻社群、Github 專案有一堆星星，這種時候誰會管這工程師的學歷？ 所以這題的答案是：學歷出色還是很吃香，但也還好啦！畢竟軟體工程這行，偏向「實力主義」，很難靠「關係」或者當「花瓶」或者「辦公室政治」就能混得出色 # 不建議直接跳進去補習班 另外我也不建議直接跑去需「全職上課」半年左右，學費十萬以上那種實體補習班 首先，班上同學程度不一，如果你稍微沒跟上進度，後面老師在講什麼就聽不懂，這樣花了大錢、時間，學習效果也不怎麼樣呀 我建議先大量找免費或便宜的教材，先吸收，多試幾份，真的卡關了，再開始挑補習班 先直接找一些作業跟專案寫寫看，從免費 -> 便宜的 -> 稍貴的，這樣一點一點花錢，風險比較小 更認識自身需求之後，再去比較市面上的各種補習班，最後再把這錢花下去，比較保險 事實上，也有很多人，最後根本沒去補習班，只靠著免費＆便宜的一些資源，就直接順利轉職的呢！ # 結論 這行學無止盡，就算台大畢業，工作十年經驗，還是一直在不斷自學寫程式的奇妙＆精益求精 另外，我也有設計免費的 html&css 教材，還有便宜的 javascript 教材，內含「大量練習專案」，不論你最後選擇哪種學習方式，我都推薦搭配拿去學習、練習，稍有難度，但不少人全做完之後就順利面試上班了 以上，簡單分享個人看法
歡迎最近新註冊的用戶 @ymcheung @ricky0302 @yuyu15 @kose9876 @YangGuan 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
歡迎最近新註冊的用戶 @Housekeeping @zhuzhiwei1107 @zxzx115003 @thomas @raymayday4 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
來，讓我們特別關心剛轉職開始上班的 @birdie2019 @JoeyLai 本週是否有學到新東西？ 是否有遇到什麼地方卡關？ 隨時歡迎上來分享工作筆記 or 上來發問卡關問題～
# !important 的正確使用時機 !important 會強制打斷正常的 css 修改邏輯權重 在我十年的工作經驗中，只有兩種情況會這樣用 第一個是寫 utility css class 的時候 例如 `.text-center` `.text-right` 這種輔助功能性的 css class 比方說參考 bootstrap 的相關文件 https://getbootstrap.com/docs/5.3/utilities/api/ 這些 css class 看命名就知道有一種「這元素就是要這樣式」的感覺 所以加上去會蓋過其他所有 css class，但是這沒問題，不會造成維護的困擾 別人一看就知道是 utility class 在作用 --- 第二個情況是，當你確認自己在對某元素進行「最終維護」的時候 也就是幾乎結束的專案，最後一次幫客戶修改，你很確定有些元素之後不會再擴充、再修改了 這時有些樣式會偷懶 !important 亂加一通 改完就不想管了 # 當同事濫用導致 code 難以維護 實務上來說，除了上述兩種情況之外，使用 !important 都是「完全不可接受的」！ 當專案內出現大量 !important 時，會讓 css 難以維護，甚至是無法維護！ 就我個人經驗來說，這情況非常慘，是一種「重大技術債」 也就是代價很高，會開始不斷支付利息，然後很沒效率 # 現階段的務實處理 這個情況的出現，代表圖隊內有人「經驗不足」或者是「缺乏責任感」 需要適當反應、溝通，避免未來再出現這情況 第一種辦法是 相關樣式通通重寫！這個成本很高，但專案若還需要長期維護很久，可能必須這樣 第二種辦法是，讓相關 PM 與資深工程師知道這個情況的存在 他們會可以理解：相關 code 修改起來的時間，難以預期、難以估計！分配安排上，要考量到這點，甚至避免相關樣式的改動 總而言之，這情況，算是相當「雷」了 工作上，千萬別當濫用 !important 的人 # 最後補充 在程式設計領域，各種套件、協定、API 在設計的時候，有些功能會提供給大家用，但希望大家盡量少用 這種時候，通常會讓函式名稱、變數名稱、或者是相關命名「長得很奇怪」 比方說突然有一個「全英文大寫的命名」、「很冗長的函式命名」、「用奇怪的底線前後包住的命名」、「使用奇怪的特殊符號的命名」 這些就是「知道你可能必要時刻會需要用，但是非常不鼓勵使用」的 API，所以故意讓你打字累一點、而且會察覺到自己在幹嘛 !important 就是屬於這類東西，打起來很怪很累，所以當然不應該濫用 --- 以上，簡單分享
如題 個人頁面額外顯示：貼文總共瀏覽次數 方便大家知道，自己的文章造福了多少人～
歡迎最近新註冊的用戶 @johnson0471 @fenasot @ningqung @victoria304040 @Elaine123 @mini505550 @ryan1690 @unicorn44739 @UrMomSoPretty @a8566012 @z2953808 @simonitc @max3807max @webber777 @ponian @shouldwecode @hung19091 @yao1997 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
給新手工程師的建議：每天工作都在查 ChatGPT 會不會很糟？ 看到滿多年輕工程師提問：工作時經常查 ChatGPT，感覺不太踏實，沒關係嗎？ 讓我簡單談論一下這件事 --- 首先，讓我們把時間倒回 2000 年代 google 剛出來的時候 當時一定也是這樣，年輕工程師遇到問題狂查 google 資深工程師則覺得 google 可有可無，真的有問題，桌上的工具書大概要翻到第幾頁他也都知道，翻一下不用 10 秒就有答案 時間快轉到今天，年輕工程師遇到問題狂問 ChatGPT 資深工程師則覺得 ChatGPT 可有可無，真的有問題，google 關鍵字怎麼組合、stackoverflow or reddit or 某某技術論壇，找一下不用 10 秒就有答案 --- 新科技的出現，讓一些「死背類型」的任務變得「毫無意義」 比方說現在沒人會去背歷史事件的年份了，因為要用時 google 一下就有 同理，現在的工程師，所用程式語言的某些語法、函式名稱、API 用法，沒背起來，根本沒關係 （不信的話，問問看用 Linux 的工程師，怎麼解壓縮檔案，看看有幾個人可以不查 google 打出指令） ``` tar -xzvf 壓縮檔名稱.tar.gz ``` 所以 AI 的出現，如果讓很多以往工程師視為 knowhow、design pattern、convention 的東西，降格為「死背類型」 那麼這些東西當然不用靠肌肉記憶去記住了，每次遇到就去問 AI 即可 --- 我認為工程師這行業的重點在於，你知道「某些問題在技術上可不可能被解決」、「解決方案的大方向是什麼」、「不同解決方案的成本跟考量分別是什麼」 如果你都知道大方向，但是細節語法常常忘記，那習慣性問 AI 當然沒問題 但如果每次查完，你都是把一大堆你自己根本不知道在幹嘛的程式碼複製貼上，那就很有問題 簡單講，這些新科技「可以減少打字的時間、減少查詢的時間、減少翻閱的時間」 但是「無法減少你學習的時間」 # 結論 所以，用 ChatGPT 沒問題，但是你要知道自己拿到的程式碼，到底實際上在做什麼 這樣用了之後，出問題才能除錯、必要時才能擴充、才能加功能 以上，簡單分享，大家有什麼問題，可以多多提問，我盡量回答
上次的說明了PHP套件管理的歷史與社群提出的解決之道，本篇文章接著談類別管理的進階議題。 # 當類別名稱一樣... 當專案大了起來，有時候會有類別名稱重複的問題。 假設今天要撰寫一個論壇模組，提供討論區與留言板功能。 你一定很想將討論區的文章與留言板的文章都命名類別為Article： ``` // BoardArticle.php <?php class Article{ //... } ?> // ForumArticle.php <?php class Article{ //... } ?> ``` 當然了，這麼做會得到一個結果： ``` Fatal error: Cannot redeclare class Article ``` 這種問題有一個簡單的解決辦法，就是加上前綴字。 類別分別命名為ForumArticle與BoardArticle就可以了。 *Q1: 等一下！這個解法好陽春！我看到至少4個問題：* 1. 類別名稱容易變得冗長。 2. 有些類別一開始你以為不會跟人重複，結果之後真的重複了。難道永遠替類別加前綴字？ 3. 類別名稱寫Article俐落多了！文章就是概念上的文章，不要逼我告訴你是討論區還是留言板！如果專案用到兩種留言板模組，分別由以前的兩個前輩寫好，難道還要逼我把作者名稱寫進去？ ``` class TonyBoardArticle{ //... } class JackBoardArticle{ //... } ``` 4. 如果我在打造框架(framework)呢？幾乎會把所有常見名詞用過一次(像是Request、Loader、Response、Controller、Model等類別)！難道前面全部前綴？ 看看 Codeigniter 的原始碼，全部用CI_當作前綴。超醜的。 # 命名空間(namespace)登場 於是PHP從5.3版之後支援了命名空間(namespace)。 所以可以用Article替類別定義了： ``` // BoardArticle.php <?php namespace Board; class Article{ //... } ?> // ForumArticle.php <?php namespace Forum; class Article{ //... } ?> ``` 使用類別時只要加上命名空間即可： ``` //index.php <?php include 'BoardArticle.php'; include 'ForumArticle.php'; $article = new Forum\Article(); $post = new Board\Article(); ``` 如果當前的php檔只用到其中一個Article類別，可以指定當前的php檔只用哪個命名空間+類別的組合： ``` <?php include 'BoardArticle.php'; include 'ForumArticle.php'; use Forum\Article; $article = new Article(); $fArticle = new Forum\Article(); $bArticle = new Board\Article(); ``` 如此一來，當php找不到Article類別時，便會去使用use關鍵字宣告的組合。 當然了，就算用use指定過，原本的宣告方式還是可以用的。(如最下方兩行所示) # 當東西多了起來... OK，可以繼續完成我們的論壇模組了！ 討論區跟留言板有各自的文章，再來還需要「推文」： ``` <?php namespace Board; class Comment{ // ... } ?> <?php namespace Forum; class Comment{ // ... } ?> ``` 使用剛剛學到的命名空間去載入他們： ``` <?php // index.php include 'BoardArticle.php'; include 'ForumArticle.php'; include 'BoardComment.php'; include 'ForumComment.php'; $article = new Forum\Article(); $comment = new Forum\Comment(); // ... ``` 果然是漂亮的各種命名阿！ *Q2: include有好多行！上次提到了Composer可以解決這種問題，當引入命名空間之後，Composer也能發揮作用嗎？* **是的。** # Composer登場 跟上次初學Composer一樣，建立一個composer.json檔： ``` { "autoload": { "files": [ "ForumArticle.php", "ForumComment.php", "BoardArticle.php", "BoardComment.php" ] } } ``` 注意，上次我們用"classmap"指定資料夾、把資料夾內檔案全掃一次，這次我們用"files"分別設定各個檔案。 再來，在terminal輸入 ``` composer install ``` 執行完畢之後，跟上次一樣，只要載入一個檔案： ``` <?php require 'vendor/autoload.php'; $article = new Forum\Article(); $comment = new Forum\Comment(); ``` 就可以使用各個類別囉！ *Q3: 等一下！看起來跟沒有命名空間的時候差不多啊！一樣是把php檔自動require進去而已？* 對啊，你最上面的原始寫法，也只是手動載入好幾個檔案，在載入的時候本來就沒有特別之處： ``` <?php // index.php include 'BoardArticle.php'; include 'ForumArticle.php'; include 'BoardComment.php'; include 'ForumComment.php'; $article = new Forum\Article(); $comment = new Forum\Comment(); // ... ``` 載入php檔就只是載入，跟命名空間是兩回事。 *Q4: 還是不太對啊！上次我用classmap一次把好幾個資料夾內容掃過，這次我用files分別指定每個檔案幹嘛？Composer不是厲害在能指定資料夾去自動掃過？* ......你說的沒錯。 開個my_lib資料夾，把4個php檔都丟進去吧。composer.json這樣寫就好了： ``` { "autoload": { "classmap": [ "my_lib" ] } } ``` 再來，在terminal輸入 ``` composer install ``` 這樣就搞定了！ 其實我只是想示範，除了用classmap設定資料夾之外，也可以用files直接指定檔案。 *Q5: OK，原諒你。不過，我必須說，我今天什麼都沒學到。最後還是在composer.json寫classmap而已，跟上次一模一樣。* 是的...我剛說了，載入php檔就只是載入，跟命名空間是兩回事。 我今天介紹的namespace功能是PHP本身提供的。而Composer只是協助你載入的工具、當然不可能改變程式語言本身。 Composer只是幫助你少打那一串require而已。 *Q6: ㄟ等等...有個地方我覺得很醜。我們現在的my_lib資料夾裏面有4個檔案，檔名很醜：* ``` "ForumArticle.php" "ForumComment.php" "BoardArticle.php" "BoardComment.php" ``` 類別名稱本身都是俐落的Article跟Comment了，檔案名稱還是有前綴字。但也不可能有兩個Article.php、兩個Comment.php。你有沒有辦法解決這個美感問題？ 這個問題簡單，把那個my_lib資料夾刪掉，開一個Forum資料夾、一個Board資料夾。本來的ForumArticle.php改成Article.php丟進Forum資料夾、本來的BoardArticle.php改成Article.php丟進Board資料夾。composer.json改寫成這樣： ``` { "autoload": { "classmap": [ "Board", "Forum" ] } } ``` 再來，在terminal輸入 ``` composer install ``` 這招不錯吧！檔案名稱就是類別名稱，乾淨俐落！ 而且資料夾的名字本身就是namespace的名稱！ 以後都這樣做啦！一用到命名空間就開個同名資料夾把檔案丟進去！ *Q7: 這招我覺得還好耶...。本來檔案都放在my_lib，我在composer.json只要填my_lib一行就好，現在變成要填兩行。要是我這個論壇模組有一大堆類別、用了一大堆命名空間呢？那我classmap底下不就要填入好幾行？那我寧可全部丟進my_lib，只填my_lib一行！* 唔，這樣說也是有道理。那重新建立my_lib資料夾，把Board跟Forum資料夾丟進my_lib資料夾。 composer.json改回這樣寫： ``` { "autoload": { "classmap": [ "my_lib" ] } } ``` 再來，在terminal輸入 ``` composer install ``` classmap不只是告訴Composer去載入哪幾個資料夾內的檔案，還會把資料夾內的資料夾也全部掃過一次。 怎麼樣，Composer夠神吧。 *Q8: 原來classmap底下會遞迴掃描下去...。我決定了，我的Forum跟Board都是在提供線上討論功能，我決定替我這個模組命名為Discussion。我要在my_lib底下開Discussion資料夾，然後把原本的Forum跟Board資料夾都丟進去。你覺得這個想法如何？* 還不錯。一個Discussion資料夾就是你的整個Discussion模組。 提供了討論區、留言板功能的Discussion模組，我喜歡。 *Q9: 好像忘了什麼...。啊，剛剛說命名空間跟檔案結構符合會最漂亮。那我要把那4個檔案的namespace改成這樣：* ``` <?php namespace Dicussion/Forum; class Article{ //... } ``` 剛剛說了，載入檔案就只是載入檔案，跟命名空間無關。 現在檔案結構沒變，所以我應該不用重新輸入composer install。 讓我試試...。 靠！怎麼噴error了！你騙我？ ``` Fatal error: Class 'Discussion\Forum\Comment' not found ``` 呃...，我前面的說法確實有點誤導。 PHP自動載入的基本函式長這樣： ``` void __autoload ( string $class ) ``` 如你所見，PHP至少需要Composer提供資訊指出$class該去哪個檔案找。 namespace改變之後，PHP會找不到對應的$class在哪。 所以還是輸入一下composer install吧！Composer會把需要的資訊整理好的。 *Q10: OKOK，我知道了，我駕馭這一切了。我覺得這個Dicsussion模組真的超屌的，不但命名空間漂亮，連檔案結構都漂亮。我要把這個Discussion資料夾整個丟給我朋友，他們公司最近需要論壇模組。* 讓我打電話給他...。 「什麼？你們已經做好半個論壇模組了？你只需要我模組的其中幾個功能？你們的模組也是放在Discussion資料夾？」 糟糕，資料夾名稱重複了！所以我的模組拿給別人還是有不相容的可能，怎麼辦？ 沒有錯..還記得你Q1提到的第3個狀況嗎？確實有把作者名稱加進去的必要！ 別怕，我教你。你開一個Tony資料夾，把整個Discussion資料夾丟進去。 接著所有檔案namespace改成像這樣： ``` <?php namespace Tony/Dicussion/Forum; class Article{ //... } ``` 要用的時候就這樣喔： ``` <?php require 'vendor/autoload.php'; $article = new Tony\Discussion\Forum\Article(); $comment = new Tony\Discussion\Forum\Comment(); ``` 是變得有點長啦。 但這下搞定了吧！作者名稱再撞到的話，就改個獨特的名稱就是了！ # 終於。讓我們談談PSR-0 你一定常聽到PSR-0對吧！ PSR-0是PHP跨框架相容性統一標準組織訂出來的自動載入慣例。 來談談PSR-0幾個最重要的要求吧！ * 命名空間加上類別名稱一定要長這樣： ``` {vendor name}\{namespace}\{class name} ``` * 前面一定要是作者名稱 * 中間可以有任意層次的命名空間、最後是類別名稱。 * 中間任意層次的命名空間直接對應到檔案結構。 發現了嗎？在剛剛Q1~Q10的過程中，其實你已經把PSR-0學完了，連設計原理都一起搞懂了。 懂這些之後，你也可以做好自己的模組、發佈到 Packagist 給全世界透過composer下載、使用了！ 最後，如果遵守psr-0的話，composer.json可以這樣寫： ``` { "autoload": { "psr-0": { "Tony\\Discussion\\": "my_lib/" } } } ``` 注意，雙引號、兩次反斜線並沒有特別意思，只是 json 規定的格式。 跟classmap一樣都可以完成任務。兩者其實是有差別的...，我們下次再談。 # 結語 Composer工具以及PHP-FIG組織的出現，讓一直以來散落各地的PHP社群開始有集中的趨勢。 換句話說，各社群終於能共享彼此的library了。 然而，如你所見，psr-0不但導致檔案結構容易變得深層，還要求檔案結構必須配合程式碼，這也招致了不少批評。 https://r.je/php-psr-0-pretty-shortsighted-really.html 除此之外，composer autoload內的classmap跟psr-0到底如何分工？效能差異又為何？這些問題也都還在爭論與驗證當中。 http://stackoverflow.com/questions/22803419/why-use-a-psr-0-or-psr-4-autoload-in-composer-if-classmap-is-actually-faster 不過，PSR-0在各框架已被廣泛支援，因此建議你還是需要有所瞭解。 # 最後... 現在已經出現psr-0的替代方案，稱為psr-4。 PSR-0從2014-10-21開始被註明為不建議使用。 至於PSR-4..我們下次再談。
相信有在用PHP的朋友近年來常聽到composer這個套件管理工具。 它到底是做什麼用的？又是為了解決什麼問題而存在呢？ 要瞭解這個，得先從歷史開始說起...。 # PHP最早讀取套件的方法 初學PHP時，最早會面對的問題之一就是require與include差別何在？ require_once與include_once又是什麼？ 弄懂這些問題之後，如果不使用framework，直接開發，便常出現類似這樣的code： ``` // whatever.php // 這檔案需要用到幾個類別 require 'xxx_class.php'; require 'yyy_class.php'; require 'zzz_class.php'; // ... ``` 然後在其他檔案會出現： ``` // another.php // 這檔案需要用到幾個類別 require 'yyy_class.php'; require 'zzz_class.php'; // ... ``` 這樣的結果，會產生至少兩個問題： 1. 許多檔案用到同樣幾個class，於是在不同地方都需要載入一次。 2. 當類別多了起來，會顯得很亂、忘記載入時還會出現error。 那麼，不如試試一種懶惰的作法？ 寫一個php，負責載入所有類別： ``` // load_everything.php require 'xxx_class.php'; require 'yyy_class.php'; require 'zzz_class.php'; require 'aaa_class.php'; require 'bbb_class.php'; require 'ccc_class.php'; ``` 然後在其他檔案都載入這支檔案即可： ``` require 'load_everything.php' ``` 結果新問題又來了：當類別很多的時候，隨便一個web page都會載入一堆code，吃爆記憶體，怎麼辦呢？ # __autoload 為了解決這個問題，PHP 5開始提供__autoload這種俗稱「magic method」的函式。 當你要使用的類別PHP找不到時，它會將類別名稱當成字串丟進這個函式，在PHP噴error投降之前，做最後的嘗試： ```// autoload.php function __autoload($classname) { if ($classname === 'xxx.php'){ $filename = "./". $classname .".php"; include_once($filename); } else if ($classname === 'yyy.php'){ $filename = "./other_library/". $classname .".php"; include_once($filename); } else if ($classname === 'zzz.php'){ $filename = "./my_library/". $classname .".php"; include_once($filename); } // blah } ``` 也因為PHP這種「投降前最後一次嘗試」的行為，有時會讓沒注意到的人困惑「奇怪我的code怎麼跑得動？我根本沒有require啊..」，所以被稱為「magic method」。 如此一來，問題似乎解決了？ 可惜還是有小缺點..，就是這個__autoload函式內容會變得很巨大。以上面的例子來說，一下會去根目錄找、一下會去other_library資料夾、一下會去my_library資料夾尋找。在整理檔案的時候，顯得有些混亂。 # spl_autoload_register 於是PHP從5.1.2開始，多提供了一個函式。 可以多寫幾個autoload函式，然後註冊起來，效果跟直接使用__autoload相同。 現在可以針對不同用途的類別，分批autoload了。 ```spl_autoload_register('my_library_loader'); spl_autoload_register('other_library_loader'); spl_autoload_register('basic_loader'); function my_library_loader($classname) { $filename = "./my_library/". $classname .".php"; include_once($filename); } function other_library_loader($classname) { $filename = "./other_library/". $classname .".php"; include_once($filename); } function basic_loader($classname) { $filename = "./". $classname .".php"; include_once($filename); } ``` 每個loader內容可以做很多變化。可以多寫判斷式讓它更智慧、可以進行字串處理...。 自動載入類別的問題終於解決了...。 *但是光上面的code也有15行，而且在每個project一定都會寫類似的東西。有沒有辦法自動產生這15行呢？ 我的願望很簡單，我告訴你，反正我有my_library資料夾跟other_library資料夾，你自己進去看到什麼類別就全部載入好不好...？* *阿不對，全部載入剛又說效能不好，那你進去看到什麼就全部想辦法用spl_autoload_register記起來好不好...？* *我懶得打15行了，我只想打這幾個字：* ``` $please_autoload = array( 'my_library', 'other_library'); ``` *可不可以發明一個工具，去吃$please_autoload這個變數，然後自己想辦法載入一切啊...？* *ㄟ等等，我連php程式碼都懶得打了，在web領域JSON格式更簡潔。允許我這樣打，好嗎？* ``` { "autoload": [ "my_library", "other_library" ] } ``` *然後誰來個工具幫我產生一大串autoload相關的php程式碼吧...，可以嗎？* **可以。** # Composer登場 首先，裝好composer(本文不介紹如何安裝。) 再來，建立一個composer.json檔，裏面輸入這些： ``` { "autoload": { "classmap": [ "my_library", "other_library" ] } } ``` 比原本希望的多打了一些字，不過差不多。 再來，在terminal輸入 ``` composer install ``` 執行成功之後，你會看到一個vendor資料夾，內含一個autoload.php。 沒錯，跟你夢想的一樣。你只要載入這個檔案： ``` require 'vendor/autoload.php'; ``` 你需要的所有類別，都會在適當的時候、以適當的方式自動載入。 php再也不會噴error說你「類別尚未定義」了！ 這vendor資料夾裏面的一切，都只是php code而已，並沒有特別神奇的地方。只要去看autoload.php的原始碼，就能知道composer到底寫了哪些php code給你。 *ㄟ等等，我寫的類別都放在my_library裏面了，other_library都是網路上copy下來的現成類別。我想要用Google API的Client類別、Doctrine資料庫管理抽象層類別、還有guzzlehttp的發送request類別。* *我連去下載這些檔案、然後丟進這個資料夾都懶得做了，我根本不想手動建立other_library這個資料夾。composer真那麼神...不如連下載都幫我自動下載？可以嗎？* **可以。** 查詢一下那幾個套件在 https://packagist.org/ 的名稱、還有你需要的版本號。 把剛剛的composer.json改成這樣： ``` { "require": { "google/apiclient": "1.0.*@beta", "guzzlehttp/guzzle": "~4.0", "doctrine/dbal": "~2.4" }, "autoload": { "classmap": [ "my_library" ] } } ``` 然後'composer install'指令除了自動載入你的類別之外、還會自動下載你需要的類別、然後自動載入它們。 一樣require 'vendor/autoload.php'就可以了。composer實在是太棒了。 其實composer解決的問題不只這樣。 類別多了起來之後，各種程式語言都提供namespace功能協助分類。 在有namespace的情況下，PHP社群與composer是如何解決自動載入的問題呢？ 這些比較進階的內容，下回分曉。
我後端是用 php + laravel 我會開始轉貼一些 php 的技術文章～大部份是我以前寫的文章 未來也考慮推出 php 自學教材～ 評估中～
首先我們來看 google trend  https://trends.google.com.tw/trends/explore?date=all&geo=TW&q=dreamweaver&hl=zh-TW 如你所見 這是一個過時的技術、正在被人們拋棄 接著請到 google 搜尋 `dreamweaver 職缺` 會發現其實 還是有些職缺要求要會 dreamweaver 這些職缺的待遇、工作內容 都在各大人力資源網站 你可以自行判斷：這些是不是你求職的目標職缺、理想職缺 --- 再來是我個人經驗，我這十年職場所見所聞，沒有遇過公司在用 Dreamweaver 我在社群認識各類工程師，也沒聽過有人在用這工具 不得不說 這實在是一個很老派的工具 唯一有次在業界遇到 好像有人在用的情境 是一間接案公司 以快速、便宜為主打 他們當時需要有人能用低價、快速的方式 把大量網頁切出來 後來找到的配合的人 好像就是用 Dreamweaver 在切版 --- 如果對 Dreamweaver 有興趣、好奇 我覺得多學一個工具 也不是壞事 對於之後再學其它工具 也是會有幫助 但是 應該沒必要花時間「專精」或者「鑽研」這樣一個老舊的工具 如果課程要求 或是有證照需求 那評估一下需要花費的時間 如果證照沒那麼難考 那花點時間 拿個證照 也滿好的 還能培養一些自信 如果履歷表還沒什麼東西能放 那放個證照也不錯 但如果考那證照很花錢、很花時間 那請審慎思考一下這投資值不值得 我是不推薦 我感覺只是培養快速、低成本切版網頁的能力 這能力頂多在接案公司會有幫助 而且還不會是很精緻的接案公司 不如花時間深入研究 JavaScript 基本功，對前端職涯更有幫助，而不只是專精於切版而已 --- 以上 簡單個人觀點分享
首先恭喜，本站的最早一批學員之一 @birdie2019 順利找到工作上班啦～ 趁這機會，順便簡單分享幾個給新入行者的建議 ## 建議積極衝刺 9 - 18 個月 剛開始上班一定是手忙腳亂又緊張，建議前三個月拼一點，拿出「讓人印象深刻」的表現，先站穩職場，自己也比較有安全感 雖然一開始會覺得自己實在很弱，但是，利用業餘時間多讀技術文章，持續 9 -18 個月，會有巨大成長，到時回頭來看，連自己都會吃驚可以進步這麼多 新手工程師，前 3 - 5 年的薪水通常會快速成長，因為能力也會快速成長 除非公司真的很凹人、待遇真的很不滿意，否則剛入行，就先拼一下吧 ## 大小問題，多多上來發問 目前這論壇上的發問、討論內容，還是偏少 大家可以多多發問，我也需要這些提問，來當成寫作的靈感 不然我常常也不太知道大家想看什麼，我要寫哪些文章 就貼文發問吧！ ## 養成筆記的習慣 可以用自己筆記本、部落格、或直接在這邊定期發文 有整理出一些東西、觀念，都可當成隨手筆記貼在這，未來要翻閱的時候，比較容易找到 心有餘力的話，定期寫學習心得分享，更好 這個習慣的重點在於：**溝通能力的訓練** 軟體工程師需要「極強的溝通能力」，寫作可以訓練這點 現在遠端工作越來越普及，「強大的寫作能力」也會對職涯很有幫助 所以要多多找機會寫作，本站的內容也都可透過 API 撈出來建立獨立的個人網誌 --- 以上，簡單分享，我希望能盡快看到第二、第三位順利轉職的同學出現喔～
https://codelove.tw/@howtomakeaturn/course/8aAWxW 歡迎寫寫看作業～ 可加強 js 基本功～ 開始認識 node～ 並且為更多 js 進階內容打下基礎～
不論是在學生、正在轉職、或是剛開始上班 不少人常常有這念頭：我好像不太適合走這條路，怎麼辦？ 讓我簡單分享幾個觀點 # 關於天份與熱情 很多人對於社會上各種工作抱有「資格論」的傾象 我抱持相反觀點，我認為你在各行各業，沒有天份、沒有熱情也沒有關係 詳細理由我不贅述，請參考我之前的文章：寫程式不需要天份，也不需要熱情 https://codelove.tw/@howtomakeaturn/post/2anXlx # 我在工作上總是做得很慢 這點跟生產力＆考績有直接關係，所以是比較重要沒錯 但是，所謂做得很慢，也可能是公司的要求不合理，或者身處團隊實在太強，同事實在太猛 所以，在職場經常有落後同事的感覺，這比較像一個人與團隊的節奏感的問題 如果你雖不優秀，但主管對你的表現其實尚可接受，你的程式碼 bug 很少、品質也還行，甚至你在各間公司其實也沒真的被開除過，那做得慢一點也還好吧 如果幸運遇到「知道怎麼分配適合任務給你」的專業主管，也許這問題，會更顯得微不足道 # 我還是很經常會懷疑自己 ... 很擔心 ... 有沒有可以參考的大原則、大方向？ 有，我建議你留意一件事就好了：「我有沒有在進步」 第一個原因是，寫程式這個行業，日新月異，發展實在太快，開發者需要不斷進步，才能維持競爭力 這種進步可快可慢，有自己的節奏沒關係，但每過幾個月回頭看，要有「我確實有變強一些」的感覺才行 有個很簡單的檢測方法，就是維護自己半年前寫的程式碼時，要有「好垃圾的程式碼，我寫得還真爛」的感覺。這代表你進步很多，否則不就是原地踏步？ 第二個原因是，我認識很多所謂學得快、做得也快的工程師，在職業生涯的前幾年，進步非常快 但是，大概在三十歲左右，大家難免速度會慢下來，更希望把重心關注在其他事情，比如生活品味上，這之後的技術能力就進步沒那麼快了 我想說的是，這很像是經典的「龜兔賽跑」的故事，你雖是烏龜，但能走多遠其實也不一定，長久下來未必是落後的，所以關注在自身的進步、成長、學習，準沒錯 # 結論 如果寫程式令你痛苦不堪、同事主管讓你壓力很大、待遇根本遠低預期、一直以來你也根本不覺得自己有在成長進步，那麼是有點慘，或許是該考慮轉行 但如果狀況沒那麼糟，我建議你關注在自己的成長狀態即可 定期寫筆記，記錄自己近期到底學了什麼，通常會發現進步得比想像中得還多 關於程式設計，慢慢研究、慢慢學，或許也能有不錯的發展 --- 以上，簡單看法分享
這是我 2015 年寫的文章，當時在學界、業界評價兩極，也引起很多人痛罵 多年後回頭看，我的觀點不變。文章滿適合這個論壇的，我順手轉發一下 --- 從來沒有一個技能，曾經被神化到這個程度： 「你不但要有天份，還要有熱情，才適合寫程式。」 那些寫程式的人，好像「從小就立定志向，決定未來要寫程式了」。 缺乏其一的話，你要嘛是個假貨，要嘛走不遠，總之就是不適合。 這種深植人心的刻板印象不但大錯特錯，同時還是有害的。 隨便找幾個工程師都能證明這點。 # Jacob Kaplan-Moss（Django創造者） Jacob Kaplan-Moss的這份簡報提到： [一個平庸工程師的自白](http://www.inside.com.tw/2015/06/12/i-am-a-mediocre-programmer) > 這種關於「程式天才」的神話非常有害，一方面它把行業門檻設置得特別高，令很多人望而卻步，另一方面它也在折磨產業內的人，因為你如果不能 rocks ，就會變成 sucks ，所以不得不用一切時間來努力學習和工作，導致影響生活。…（略）…我們應該改變這種態度，寫程式只是一些技能，並不需要太多天分，它是可以學習的，而且做一個平庸的工程師不丟人， 他本人在[Twitter的自介](https://twitter.com/jacobian)直接寫「不是真的程式設計師（not a real programmer）」， 透漏著他對這種迷思的不耐煩。 # Jacob Thornton（Bootstrap作者） 在Github擁有八萬顆星的Bootstrap作者， 前Twitter、現任Medium工程師Jacob Thornton的一篇採訪也是這種迷思的反例： [Jacob Thornton痛恨電腦（Jacob Thornton Hates Computers）](https://medium.com/@verbagetruck/jacob-thornton-hates-computers-5c64f164ee07) > 當他說「我痛恨電腦」的時候，並不完全在開玩笑。…（略）…他說「我本來要去唸社會學的」 接著描述了他第一份工作的情況： > 我拿到了一個遠超我能力的工作。每一天都可能被開除。所以我非常努力工作，想搞懂JavaScript，因為我不懂它到底在幹嘛。 > 我一生中最現實的一刻到了。整間公司的人圍在我身邊，要我做一個XHR request。我根本沒做過，我只稍微聽過而已。於是我開始打字、重新整理瀏覽器，然後什麼都沒出來。我反覆做了幾次，知道自己完蛋了，他們發現我是假貨了。接著我突然發現自己忘記加「.send()」。我加了之後再次重新整理瀏覽器，畫面成功顯示。整個團隊感覺像在說「喔，酷。」然後就各自回辦公桌了。 > 我在那裡坐了15分鐘。心想，就這樣。我搞定了。我不會被開除了。 這段描述一點也不像「程式天才」在職場的表現。 至於支持他一路走來的動機是什麼呢？他說： > 我是一個高度在乎同儕的人，我做前端的朋友總是會告訴我哪個地方做很醜或是在哪個瀏覽器上壞掉。感覺真的很棒。我真的只想跟朋友一起寫程式，一起工作。 [他本人的Twitter](https://twitter.com/fat)自介寫「computer loser」， 置頂推文是「公司裡第一爛的工程師，但是第三酷」。 這種態度跟刻板印象完全相反。 # Rasmus Lerdorf（PHP之父） Rasmus Lerdorf的[言論](https://en.wikiquote.org/wiki/Rasmus_Lerdorf)常常引起廣泛爭議： - 我其實很討厭寫程式，不過我喜歡解決問題。 - 有些人熱愛寫程式。我不懂他們為何會這樣。 - 我不是一個真的工程師。我把東西弄一弄，弄到能跑之後就不管了。真的工程師會說「這段程式能跑，但記憶體沒管理好，我們來修好它」。我只會說，一直重新開機不就好了。 從他的言論，很難看出他對電腦本身有多少熱情。 他也跟Jacob Kaplan-Moss以及Jacob Thornton一樣，懶得對寫程式的迷思多做解釋， 乾脆直接說自己是loser、假工程師了。 # David Heinemeier Hansson（Rails之父） DHH在接受[Big Think訪問](http://bigthink.com/videos/big-think-interview-with-david-heinemeier-hansson)時提到： > 說來有點好笑。我以前寫PHP跟Java的時候，常常花時間去摸其他程式語言。到處摸看看其他程式語言…隨便什麼都好。寫PHP跟Java實在太悶了，我需要用這種方式讓自己暫時抽離。 > 我以前寫PHP跟Java的時候，完全不覺得自己之後會當程式設計師。 整段看起來都不像是一個「電腦天才」的自我介紹。 最後讓他愛上的不是電腦本身，而是Ruby程式語言的優雅性。 如果Ruby沒有被發明，DHH現在也許會做完全不同的事情。 --- 這一類可以說明刻板印象大錯特錯的文章實在太多了， 看看工程師們最愛的幾個玩笑：[關於工程師 59 條搞笑但卻真實無比的語錄](http://www.inside.com.tw/2013/12/20/59-hilarious-but-true-programming-quotes-for-software-developers) - 一個人寫的爛軟體將會給另一個人帶來一份全職工作。 - 傻瓜都能寫出電腦能理解的程式，優秀的工程師寫出的是人類能讀懂的程式。 - 開發軟體和建造教堂非常相似——完工之後我們就開始祈禱。 如果工程師都很有天份跟熱情，這些笑話又怎會受歡迎呢。 再看看Medium上很受歡迎的學習系列文章：[資深開發者給後輩的七個 Coding 學習心得](http://buzzorange.com/techorange/2013/11/29/wish-someone-had-told-me-when-learn-coding/) 其中的幾個建議 - 也許常常有人說你是錯的 - 也許常常會有人跟你說「你並不是個 Coder」 - 不要在意外表，能力才是一切 無非就是想打破這類寫程式的迷思、無意義的資格論神話。 下次又有人學到一半，開始反省自己適不適合、夠不夠資格的時候， 我只想跟他說：你就多找幾種方式學學看吧，不要抱持那種奇怪的資格論。 很多時候其實只是[搞錯方法](http://blog.turn.tw/?p=1283)、[搞錯心態](http://blog.turn.tw/?p=2568)而已。 真的完全學不懂再放棄吧。 寫程式不需要天份，也不需要熱情。 (Photo via Sano Rin, CC licensed.)
最近看到滿多年輕學生、考慮轉職者提問：未來 ChatGPT 會取代軟體工程師嗎？ 看來這個議題已經造成不少 IT 領域學生的焦慮，我非常驚訝，讓我簡單談論一下這件事 # 個人經驗回顧 我在畢業前全心學習 web 前端與後端開發，2012 年畢業時，正逢智慧型手機快速發展，所有公司都在思考如何開發手機 app 來創造新機會，當時媒體的主要論述是：「web 已死！web 工程師都將失業，未來是 mobile app 的世界！」 當時年輕的我，看到這些媒體這樣分析，也是有點焦慮，但同時又有點不服氣，所以依然 100% 心思在研究 web 開發，不管媒體怎麼看衰。現在，10 年過去了，請問 web 職缺消失了嗎？ # 媒體的習慣、網紅 YTer 的習慣 想像你住在一個非常小的島嶼國家上，往外走一下就看到海，國家全年365天基本沒什麼大事，每天就是太陽升起、太陽落下。如果你是島上的「新聞從業人員」，請問你每天能做什麼？你當然只能誇大你看到的每件事情。 看到海水漲潮，發新聞：「海水異常上漲！恐有釀禍危機！全國一半人口恐有水災、死亡風險！」 看到海水退潮，發新聞：「近三年最低點！海水不斷消退、國家水資源流失、重大警訊！我國恐成大型沙漠！」 世界上大多數事情本就「帶有波動性」，一下狀況好一下狀況壞，潮起又潮落，正如月有陰晴圓缺，這相當正常。 媒體、網紅，基本上需要吸引人們關注來過活，他總不能每天發新聞：「今天海水正常漲潮，沒什麼特別的。」、「今天海水退潮了，這很自然，不太重要。」 身為現代公民，你要有能力透過媒體吸收新知，但同時也要有能力保持冷靜、自行判斷，不要隨意被影響。你要能看出各種觀點背後相關的利益。 # AI 對職缺的影響 AI 當然對各行各業會有重大衝擊，但是目前也僅止於改善工作效率、優化流程而已。 AI 因為可以加強專業人員的生產力，所以會造成職缺變少一點，但要到「軟體工程師通通失業」、「就靠機器人寫完所有程式」這種程度，實在太誇大了 最後，程式設計已經是各種工作領域之中，最難被機器取代的職缺之一，如果真的被高階人工智能取代，那社會上已經沒有多少工作適合人做，大概會是「無條件基本收入」制度之類的社會 --- # 結論 太廢的技能、感覺問 google 或問 ChatGPT 就有的東西，可以不用學了，像死背課文一樣的任務再也不用做了 除此之外，該學什麼學什麼，不用想太多 上個時代，懂得善用 google 與網際網路的專業人士 vs 不懂得善用的專業人士，生產力有巨大差別 下個時代，懂得善用 AI 的專業人士 vs 不懂得善用的專業人士，生產力有巨大差別 除此之外，跟案主溝通、釐清功能規格、分析各種技術選擇、認識領域知識並設計軟體，是極度複雜的工作，你真的覺得一個機器人放在面前聊天幾分鐘，它就能通通做完給你？ --- 以上，簡單看法分享
歡迎最近新註冊的用戶 @ken30204 @shuuuouo @Qa7899603 @c3d1997 @matt8899076 @hsuweizte @maozi20017 @eric60305 @lehcaR 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
看到有人提問：學習寫程式，閱讀文章好？觀看影片好？ 其實，重點是：「動手做有趣東西」 不論是到教室上課、還是線上學習，不管是讀文章或是影片，都差不多 重點是要動手做，而且要做有趣的東西 很多課程設計，在練習作業的地方，會出一些很無聊的作業 比如說什麼模擬螞蟻走路，走幾步路，什麼超無聊的小程式 寫完根本不知道在幹嘛，一輩子根本也不會實際需要寫什麼模擬螞蟻走路 要寫有趣、感覺實務上真的會用到的小程式才有趣，才有吸收的感覺 --- 第二個重點是，作業不能提示太多，否則大家會下意識一直複製貼上、複製貼上 東西最後寫出來，也沒有任何成就感，什麼也沒學到 --- 如果你正在學習的課程，沒有設計這種作業，那就要花點心力，自己想想看： 根據這課學到的內容，我能不能試著做點什麼小東西？ 然後在嘗試的過程中，卡關、試著解決、卡關、試著解決，這樣下去，才會有慢慢吸收、累積的感覺 --- 以上，簡單建議分享
對於轉職寫程式、或是業界情況好奇、擔心的人很多 簡單分享一些看法＆建議 # 前端好像很氾濫，現在適合轉職前端嗎？ 過去幾年，我指導過很多非本科的朋友入行，幾乎都是從前端入行（也有少數是從 iphone 開發、網站後端、資料科學入行） 我都分別問過這些朋友 轉職前的薪資 說真的 在台灣 有很多產業、領域 薪水對年輕人真的很不友善 寫程式這一行 前端雖說門檻低、就業者越來越多 這些都是事實 但是 跟很多行業比起來 薪水還是有比較好 而且進步空間很多（台北的工作機會又會更多一些） 所以 如果受不了原本產業的低薪 考慮寫程式 就試試看吧 先找書 或是便宜的線上課程試試就對了 （真的要花數萬～十幾萬找補習班之前，切記要多打聽，多比較） # 2023景氣好像很差，很多軟體公司裁員，業界很慘嗎？ 新聞上看到的 矽谷各大科技公司裁員幾千幾萬人 都是真的 但是台灣的軟體業還沒出現這情況 主要原因是 北美的公司本來就比較多「創業投資人」的資源＆募資 台灣的軟體業本來就沒拿到多少投資人的錢 😂 簡單講就是窮習慣了 現在全球資金緊縮 台灣業界本來就不是特別高薪的地方 所以衝擊反而還好 😂😂 （不過，很多靠過去幾年ABC輪募資撐下來的新創公司 現在都有危機 這是鐵定的） 我有在兼職接案北美的案子 目前北美的案件報酬大概打6折左右 非常慘 什麼時候會回溫不知道 不過，身在台灣，打開徵才網站，很多公司還是有在徵才，篩選條件選「無經驗可」就可找到「可接受半路出家」的職缺 所以，大環境沒辦法預測，想入行的話，還是先學就對了，還是有不少機會 # 我想轉職寫程式，未來也許可以接案子、賺外快，對嗎？ 工作3-5年之後，基本上多少會有親戚朋友，想找人接案寫程式 這種機會有是有，但，有幾件事還是要分享一下 要常態獲得接案收入、甚至全職接案的話，是滿困難的 首先，自由工作者需要有兩個特質，第一個是談判者特質，也就是樂於談判，拉高價碼、限制住案主規格，這樣才能有較好利潤 第二個是銷售者特質，也就是樂於老王賣瓜，自賣自誇，這樣才能被人看見，有更多機會 我認為大多數人並不會喜歡做這兩件事，我自己也不太擅長、也不太喜歡做這兩件事，所以，接案這條路，偶爾賺一點可以，要經營得好，並不容易 最後要說的是，台灣的發案報酬，常常會比你想像的還要「低很多」，有人拿幾千元就希望你架一個網站給他，或者各種離譜的情況，很多 這些都要花時間處理，很多時候綜合比較下來，直接在一間不錯的軟體公司上班、學習，還比較好 以上，簡單分享，大家有什麼問題，可以多多提問，我盡量回答
在後端設計 API 的時候 以電商網站來說，跟產品相關的 API，最早以前，最直覺的做法，就是像這樣設計： HTTP GET ``` /get-product ``` HTTP POST ``` /create-product /update-product /delete-product ``` 參數的話，跟在網址後面，或者用 form submit 都可以 --- 久而久之，業界開始有很多人發現，其實 HTTP method 本身，已經具有一些意義，不需通通用網址命名來表達： 取得商品資料 HTTP GET ``` /product ``` --- 建立商品資料 HTTP POST ``` /product ``` --- 更新商品資料 HTTP PUT ``` /product ``` --- 刪除商品資料 HTTP DELETE ``` /product ``` --- RESTful 實際上的慣例、實務做法，有很多細節 總之，就是一種設計 API 的慣例而已 設計 API 時可以參考 RESTful 慣例，也可以完全不參考，通通憑自己喜好去寫，自己有把握就可以了 --- 以上，簡單說明 RESTful 的意義，有沒有不清楚的地方？
https://codelove.tw/@howtomakeaturn/course/lqOvap 歡迎寫寫看作業～ 可打下 git 基本功～
各位同學 為了幫大家更有效率的進步、學習 我要繼續來寫一些新教材囉！ 近期會先研發「GIT 入門」的教材 歡迎大家到時來寫作業～
DHH，本名David Heinemeier Hansson，Basecamp合夥人、Google 2005年度駭客、業餘賽車手，他最知名的身份是網路開發框架Ruby on Rails的發明者。 DHH曾在部落格發表他學寫程式的心得： https://signalvnoise.com/posts/2582-how-do-i-learn-to-program 看過之後覺得獲益良多，特此翻譯出來和大家分享。 --- ## 我怎麼學會寫程式的？ 我花了二十幾年才真的學會怎麼寫程式。不是因為我嘗試的不夠，而是因為我一直用錯誤的方法。我以前都看著那些教材、範本照做，寫出一些我根本沒興趣繼續往下寫的東西。這是為了學習而學習。 我知道這方法對有些人管用，這些人就是很樂意學習新東西。我真羨慕你們。但這對我不管用，而且我知道很多人也沒辦法用這種方式學習。 為了解決鳥事而寫程式———對我來說這才管用。寫程式是因為非這麼做不可。寫程式是因為我他媽的在乎自己所寫的東西，而且我希望它越快完成越好。 這就是我學寫Ruby的方法。我把目標定為，用Ruby把Basecamp寫出來。當你因為一個目標而去學習，每件事的先後順序就變得非常清楚。我到底該做什麼才能讓這幾個訊息順利在Ruby執行？哦，我需要在這裡加一個迴圈。哦，我需要在哪裡抓些資料庫的資料出來。 決定目標的當下，你的點子就完成一半了、而且你還知道了該怎麼做。 簡單來說，就是從一些確實的東西開始做起，接著讓時鐘發出「滴」聲，然後讓它發出「答」聲。
我是web工程師，從剛開始學MVC就深感困惑： - 怎麼每個地方說的MVC都不太一樣？ - 有些文章講的MVC，跟我正在用的MVC，怎麼像完全不同的東西？ Model、Controller、View三者到底如何互動？真是一個定義不明、含糊不清的名詞。 這讓我研究了很久。最後，發覺它是一個嚴重的誤會。 這個誤會導致了學習和溝通上的代價，請聽我娓娓道來。 # 哪些是MVC？ web領域，不論前端(client-side)、後端(server-side)、不論什麼程式語言，幾乎所有framework都自稱、或被認為是「MVC」。 有哪些呢？ 前端：Backbone.js、AngularJS、Ember.js… 後端：Ruby on Rails、CodeIgniter、Laravel、Django… 真的是這樣嗎？它們全都是MVC嗎？ # MVC是什麼？ 該怎麼定義MVC呢？ 我們先來看看維基百科怎麼說： > MVC模式（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、檢視（View）和控制器（Controller）。 嗯，跟大家說的一樣。我們繼續往下看： > 模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 看起來有些陌生，整段描述跟你的web開發經驗完全不同，對嗎？ 最大的疑問來自這句： > 那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 後面直接叫你去看觀察者模式(observer pattern)。 問題來了：你有在view跟model之間實作observer pattern嗎？ 也就是說，你的Model在資料改變之後，能主動通知View嗎？ 沒有的話，就根本不符合MVC的定義。 # 全都不是MVC？ 我們現在發現MVC有observer pattern這個必要條件了。 事情嚴重了起來。 client-side framework或許能夠符合這個條件。 以Backbone.js官網範例來說，我們可以這樣在Model上註冊： ``` book.on({ "change:title": titleView.update, "change:author": authorPane.update, "destroy": bookView.remove }); ``` 它的確實作了observer pattern。 但server-side framework呢？ 你的Model如何能在發生改變之後去「主動通知」View？ 你平常開發web哪有用到server push的技術？ 所有server-side framework，從Ruby的Rails；PHP的CodeIgniter、Laravel；到Python的Django，他們全都不是MVC。 它們實作的，是昇陽電腦在1998年提出的「Model 2」。 # 什麼是Model 2？ Model 2名氣不大，在維基百科連中文條目都沒有。我們看看英文條目怎麼講： > Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. > In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. 它針對web而設計，讓controller進行必要的程序之後，將資料塞進view去呈現。 正是我們server-side框架在做的事情。 也就是說，server-side目前只能實作Model 2；client-side可以實作Model 2，也可以實作MVC。 # 巨大的代價 web工程師最常碰的就是client-side跟server-side框架。結果整個業界把MVC跟Model 2混為一談，都說成MVC。 這帶來了什麼後果呢？ MVC變成一個從初學者到業界工程師，永遠說不清楚、下不了定義的名詞。 這件事對於學習和討論，造成了非常巨大的成本。（參考下方的Q1和Q2） # 那該怎麼辦？ 下次有初學者詢問「什麼是MVC」的時候，怎麼回答才不會害他回家之後「越查資料越混亂」？ [Rails is not MVC](http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html)的作者提出了三種解決方法： > 第一個方法是聲稱MVC已經從原始意義改變了，Model 2也可以稱為MVC。如此一來，我們可以用「傳統MVC」或「真MVC」來描述原始的MVC。這是現在普遍的作法，但我不認為改變定義是一個好主意。這幾乎是越搞越亂。 > 第二個方法是到處推廣Rails其實是Model 2，MVC就留給…MVC吧。這很困難，但至少能保持定義不變。 > 第三個是直接忽略這些混亂。管它那麼多？ 我個人覺得MVC這個詞已經沒救了，不管怎麼解釋都會帶給別人混亂。 當對方同時學習client-side跟server-side時，混亂更強烈。 我選擇這樣回答： 「MVC有分很多種喔！網路上全部沒寫清楚，你一定看不懂。 沒關係，你只要知道View可以抽出來就好。 C跟M先別管，你先隨便瞎搞吧。」 --- # Q&A ## Q1: 怎麼可能各大server-side framework都搞錯？ 確實有人腦袋清醒得很，它就是Python的Django。 Django的官方文件內根本沒有「Controller」這個名詞。 看看Django官網的常見問題： > Q: Django似乎是一個MVC框架，但你們把Controller命名為「View」，把View命名為「Template」。你們幹嘛不用標準命名啊？ > A: （前略）…如果你真的很想要一個縮寫，你就說Django是一個MTV框架吧。Model、Template、View。這樣分比較有道理些。 Django不想變成搞亂MVC的幫凶，只好委屈地又發明了一個名詞「MTV」。 ## Q2: 那client-side框架有受影響嗎？ 有。client-side框架也必須為MVC巨大誤會浪費一堆時間解釋。 看看Backbone.js官網的常見問答： > Backbone跟「傳統MVC」的關聯何在？ > …我們來比較一下Backbone跟像是Rails這種server-side MVC框架的差別… Backbone實作了「傳統MVC」，卻被迫用「傳統MVC」來描述server-side的Model 2，然後花一堆篇幅解釋。 ## Q3: 知道Model 2的存在又如何？我現在依然一片混亂！ 沒錯，Model 2跟MVC都用到Model、Controller、View三個名詞，所以看起來類似。 但是，我們不應該再把時間花在思考「MVC怎麼如此難懂」。 我們討論的重點，應該是「如何分辨MVC與Model 2」、「在server-side如何實作Model 2才漂亮」、「在client-side實作MVC跟Model 2的優劣分別何在」。 ## Q4: 好，那你現在回答我，「如何分辨MVC與Model 2」？ OK，就讓我拋磚引玉一下。 分別談談Model、View、Controller吧： ### View - Model 2: 不具有行為，只是等別人塞資料進去的模板（template）。 - MVC: 具有監視Model的行為，並以此去改變呈現（presentation）。 兩種View有沒有很像？跟張飛、岳飛一樣像。 看看Backbone.js官網的View範例。你server-side的View哪是長這樣？ ``` var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, initialize: function() { this.listenTo(this.model, "change", this.render); }, render: function() { ... } }); ``` ### Controller - Model 2: 接收請求與參數，轉交給Model處理，再把結果（最新的資料）塞進View。 - MVC: 接收請求與參數，轉交給Model處理。沒其他事了。 兩種Controller有沒有很像？跟小狗、熱狗一樣像。 MVC的View跟Model 2的Controller可能還比較像一點。（隨便說說，千萬別這樣類比。） ### Model - Model 2: 接收Controller傳來的參數，回傳結果。 - MVC: 接收Controller傳來的參數，將結果通知View。 Model倒是有些類似。 總之，Model 2跟MVC除了三個部份的名字一樣之外，沒什麼關聯了。 ## Q5: 我決定徹底鑽研MVC跟Model 2的定義了。給我一些延伸閱讀？ http://www.ithome.com.tw/node/77330 http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html https://docs.djangoproject.com/en/1.7/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names http://backbonejs.org/#FAQ-mvc https://r.je/views-are-not-templates.html --- ##一些社群的看法（2015-2-28） 附上幾個社群的連結，裡面有許多很棒的討論。 https://www.facebook.com/groups/javascript.tw/permalink/600136880087654/ https://www.facebook.com/groups/199493136812961/permalink/759391387489797/ https://www.facebook.com/groups/pythontw/permalink/10153760201638438/ https://www.facebook.com/mosky.liu/posts/10203964969186383 http://www.ithome.com.tw/voice/94877
歡迎最近新註冊的用戶 @jojo @KaKakaka @Eav188 @Suit9uy @coolhao @ginnychen19 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ ### 歡迎各位加入這個技術成長社群！
發佈貼文時，多了封面圖片網址（選填）欄位 方便創作技術文章、需要有封面圖片、分享到 FB 等地方時，可以使用 有提供的話，就會進入到「技術文章」專區
初學者接觸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就是「資料跟行為在一起」加個但書： 要以方便理解程式為前提，將資料和行為放在一起。
各位新用戶、新同學 歡迎歡迎 👋 這裡是 CodeLove 愛寫扣論壇 👋👋 一個方便寫作、方便討論 陪伴你職業生涯不斷成長的地方 👋👋👋 --- 歡迎最近新註冊的用戶 @ga2006135619 @Neko0xff @weihsiang120 @Paul @Svetlvjl @shnny 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
04/28 週五 本週閒聊串 一週又要結束囉～ 各位本週有學到什麼新東西？有遇到什麼問題？技術觀念想不通？職涯有迷惘？ 歡迎留言分享 😁😁😁 --- 特別要 cue 三位完成 JS 九系列的同學 @birdie2019 @hung @superyngo git / npm / vue 3 這些相關技能有開始找資料了嗎？ 是否有地方卡關？ 稍微準備一下，儘早開始投履歷面試看看吧 😁😁😁
為了促進討論方便 開發了 @用戶網址 功能，方便通知相關用戶，邀請別人參與討論～ 目前要把用戶網址每個字母都打對，未來有空再開發 auto-complete 功能～ 舉個例 可以這樣 cue 目前寫作分享最多的 @JsLover0018 希望他繼續分享更多用心的文章！ 再舉個例 可以這樣 cue 目前完成九份 JS 系列的同學 @birdie2019 @hung @superyngo 這三位的 JS 能力 已經超過 90% 坊間速成 JS 班的畢業生～ 補充一些周邊技能，可以直接開始面試了～ --- 以上，歡迎多多使用這功能～
有幾位同學已經寫完系列一～九的全部作業了 整體能力已經可以準備開始面試前端工程師的職缺了 這邊寫一篇簡單說明 # 需要補充的技能 前端技能中最困難的部份已經有相當基礎了 剩下有些東西沒那麼難，但要學一下，上班會用到 這些東西我未來可能會寫教材，但我最近很忙，近期無法寫新教材 ## git 程式碼版本管理工具，找書或者上網找文章學一下，至少要會 add commit push pull 這些指令 ## npm 作業都是用線上環境，實際開發都是在本機為主，需要知道 javascript 套件管理工具 npm 怎麼用 ## create-vue https://github.com/vuejs/create-vue 要能在本機架起來 vue 開發環境，這款至少要知道一下 ## vue 3 教材安排是學 vue 2，但現在很多公司都已經轉用 vue 3 語法了 背景知識大同小異，但語法差異不少，要知道一下怎麼轉成 vue 3 寫法 --- 老樣子，學的時候有點一知半解沒關係，大概會用就好，畢竟是面試 junior developer 的職缺，公司通常會有工程師同事，技術長＆他們會協助你實務上的細節 # 投履歷的公司篩選 在找工作的時候，投那種「無經驗可」的職缺 很多公司會寫「一年以上工作經驗」，這種就是不歡迎半路出家剛學完者 因為很多人從補習班畢業之後，連 hello world 都寫不出來，公司想要避免遇到這種人 就先投「無經驗可」的職缺就好 公司類型基本上有分「接案公司」、「做自己公司產品」兩種 第一份工作沒差，去接案公司練功、去做自家產品慢慢打磨產品，都可以，待個半年，先進入業界再說，都可以學到很多 長期來講，我之後再寫文章說明差異 # 履歷表的寫法 基本上你照自己習慣寫，簡潔有力即可，這行業基本上是實力主義，唬爛幫助不大 但有幾個東西務必要寫進去 ``` 學習的過程中，為了瞭解網頁的基礎，而不只是當個框架的使用者，我有用純 html/javascript 練習多個元件 [附上第三課全部作業] 並且有找一些看起來很紅的業界套件，練習導入使用 [附上第四課全部作業] 然後我有用 vue 寫了多個應用程式練習 [附上第八課全部作業] 還有試著拿 vue 生態系的元件庫做範例，模仿做了幾個元件 [附上第九課全部作業] ``` 我認為履歷表附上這些東西，會讓99%的面試官印象深刻，覺得你幾乎是「即戰力」，對你更有信心 # 結語 以上，如果你寫完系列一～九全部內容了，那我認為你離上班已經很接近了 如果正在準備轉職，準備一下，試著投一些履歷試試看，試試水溫 不用急著辭職，因為今年全球景氣充滿不確定性，但就試試看能收到多少面試邀請，等於秤秤自己的斤兩，比較有個底 順利上班之後記得來寫文章分享心得 然後最好養成習慣寫技術部落格，直接在這邊寫即可 求職過程有疑問，一樣多多來這邊發問即可 求職卡關、面試不順、薪資待遇有疑慮、業界實務有困惑，都上來發問即可 我會視情況公開 or 私下回答 以上，有打算轉職的同學，祝大家早日上班囉～
如題，大家加油～ 再次提醒 1. 有問題多多到討論區發問 2. 網路上找到有趣資源、優質連結，多多分享到討論區 3. 有心得、小筆記，請把討論區當成部落格，多多分享技術筆記 加油～
https://codelove.tw/courses/contents 列出全部系列的每一課標題 方便大家複習翻閱
經營這網站主要是想做新手友善論壇 本想隨手寫2-3份入門教材，簡單給新手一些方向 結果居然寫了8份，而且我發現後面還有滿多要教的東西 所以我打算把自學教材改成「付費教材」，我乾脆長期研發新教材好了 - JavaScript 系列前兩課免費 - 每個系列售價$199 - 現有會員不受影響（今天之前註冊的會員，所有教材維持免費） 以上規劃跟大家分享，希望中長期來說，可以變成最優質、最便宜的前端系列教材 然後就可以跟討論區功能相輔相成，讓新手有個持續進修的好地方
文章 API 測試上線啦！ 用戶文章列表 - https://codelove.tw/api/posts?username=howtomakeaturn&per_page=5&page=1 單篇文章資料 - https://codelove.tw/api/post/vx8Y23 - https://codelove.tw/api/post/Rqzpb3 - https://codelove.tw/api/post/AqJR1q 以上範例是我的帳號＆文章，試試看，把 `username` 改掉就可以了 歡迎大家玩玩看這組 API，最好可以架出自己的部落格！ 可以先架在 GitHub Pages 試試看！
正在發想一個新功能，未來應該會開發 就是大家發表的文章，會有 API 這樣大家可以在 CodeLove 寫文章，然後自己另外架部落格，撈自己文章的 API 比方說 `https://codelove.tw/api/@howtomakeaturn/posts` 類似這樣 就拿到 JSON 格式的一串文章資料，這樣大家就能把 CodeLove 當文章資料庫、自己另外架喜歡的部落格了～ 大家覺得如何，還不錯吧～
在個人頁面，可以點開「全部留言」 方便大家看到自己＆別人的全部留言 --- 點擊留言的「時間」，會打開留言專屬網址 方便讓留言有獨立網址，可以被分享、轉載出去 --- 並且，新增「資料統計」小區塊 方便查看目前已發表多少資料 --- 網站功能持續強化中 歡迎多多發表文章、多多參與討論 對您的開發者生涯，絕對有「巨大的正面影響」
網站上的文章開始變多了 需要回頭找文章、查一些關鍵字的時候，可以使用
可以對貼文、留言，按讚了 歡迎大家看到不錯的貼文、留言，多多按讚，給別人鼓勵 也歡迎大家多多在討論區發問、討論，這些發問＆回答，也都可以累積讚數 之後會開發「讚數的個人統計功能」，讓累積讚數，顯示在個人檔案
很多朋友轉職寫程式，在補習班或者線上課程，告一段落之後，開始找工作之前，會整理作品集 關於作品集，簡單給大家一些建議 ## 作品集有用嗎？ 公司在徵人的時候，其實來應徵的人五花八門 滿多人看起來，根本不會寫程式，連最基本的小網頁或者小程式都寫不出來 連基本技能都沒有準備好，感覺是到處碰碰運氣、履歷亂誇大就到處丟。公司面試時，最怕遇到這種狀況 作品集，至少代表，你寫得出基本東西。很多人根本寫都不會寫，就去應徵了，作品集至少可以讓公司避免踩雷 話說回來，如果你的作品集，只是補習班的幾個分組專案，糊裡糊塗地完成了，就跟在學校敷衍交報告一樣，你對細節其實不了解，那這種作品集，當然幫助不大，對你的信心也沒有多少幫助 ## 要做什麼作品？ 所以該做什麼作品呢？ 最好做一些你真的需要的「應用程式」，寫起來才有動力、才好玩，內容也才扎實 簡單舉例，如果你在受訓的過程是這些： ### 前端工程師 做個待辦事項清單工具吧！按照自己的喜好設計，做完之後找地方上線 在找工作的這幾個星期，實際拿這個工具來做紀錄，投履歷時、面試時，很自然可以分享你的心得跟小熱情 對面試官來說，看到面試者有即戰力（即便是有一點點）、對自己的程式有熱情（即便只有一點點），都會加分不少 請參考 https://todomvc.com/ 這是各種前端工具寫的 todo list 應用程式，你還可以比較自己的程式碼，與社群所寫的差異 ### 後端工程師 我鼓勵後端的入行者，寫一個「個人專屬部落格」 這個部落格要有以下功能 - 首頁列出文章清單 - 能簡單單篇文章瀏覽 - 自己可以登入後台 - 在後台可以新增、編輯、刪除文章 有餘力的話，還可以加個留言功能 這種部落格，會實際做完資料的 CRUD 基本功能，還有簡易的註冊、登入、驗證 找地方把這個部落格上線，或者買網址、租主機，實際上線 在找工作的這幾個星期，實際拿這個部落格，來寫文章、技術筆記、經驗分享 面試官絕對會覺得你是積極的人、有備而來 （錄取之後就停止寫網誌的習慣也沒關係） ### 全端工程師 我鼓勵全端的入行者，寫一個「個人行事曆工具」並且是 single page application (SPA) 這個行事曆要有以下功能 - 有一個行事曆頁面 - 有個按鈕可以新增活動 - 點擊行事曆內的活動，可以編輯、刪除 - 有一個清單業面，可以用條列式顯示全部活動 - 全程使用 ajax，不能整個刷新頁面 這種行事曆，會實際做完資料的 CRUD 基本功能，還有基本的 SPA routing 在找工作的這幾個星期，實際拿這個行事曆，紀錄生活是像、活動 面試時分享，面試官絕對會覺得你是積極的人、是個即戰力 ## 結論 除此之外，做個人履歷表的網頁也不錯 可以搜尋 'Portfolio website examples' 看看各種漂亮設計 實際把履歷做成網頁，也可稍微證明自己能力 在工程師生涯，不斷地做自己的 side project 是一個有趣、進步的好習慣 甚至有一天，你做的某個 side project 大受歡迎，還可能變成一個獨立的小產品呢 有空可以逛逛 https://www.producthunt.com/ 看看大家都在做什麼 side project 或許模仿其中一些，做個簡易版本，你會學到很多的～！ --- 您有沒有什麼好的點子、推薦的 side project 點子給初心者呢？ 歡迎留言分享！
身邊很多朋友工作幾年之後，從非本科轉職寫程式 主要方法大概三種：報名實體課程、報名線上課程、買線上課程自學 ## 報名實體課程 資策會、程式補習班，都屬於此類 需要本人實際到教室，由老師上課 這種課程通常需要耗時數個月，費用會在新台幣十萬上下 好處是有同學一起、有同儕壓力、有問題可以當面問老師、厲害的老師可以現場掌握全班學習狀況 壞處是每個人學習速度不同，有人跟不上、有人覺得教太慢 這種學習法，需要碰運氣，如果遇到優秀的老師，學習氛圍、效果，都會非常好 但是，就我觀察課表，以「全端工程」為主打的課程，進度通常非常倉促，能真正消化的學生非常少數 多數人只是糊裡糊塗把功課、專案做完，畢業後其實還是很沒信心、一頭霧水 （只專注在特定領域開發的課程，狀況比較好一點） 主因是基礎知識還不夠熟，就開始大量學習工具用法 我建議這種狀況，不要對自己起太多懷疑，保持耐心，養成做紀錄的習慣 覺得一知半解的地方就把問題記錄一下，每天都整理出一些問題 整理出一張問題清單，找時間請教別人、或是上網慢慢研究 多數回答，聽完之後應該還是聽不懂，沒關係，先放著 有搞懂的問題就劃掉，一段時間之後，會更清楚程式設計整體觀念，也會更有信心 重點是要知道自己具體是哪些細節不了解、一知半解，才有補充＆複習＆研究的方向 ## 報名線上課程 坊間許多業者提供這類服務，會有大量教學影片，個人自己找時間看完即可 並且會幫大家分組、需要一起做專案、會有助教指導 好處是每個人可以自行抓節奏，並且費用便宜許多，通常不到實體課程四分之一 如果是組合式的課程商品，就更好了，可以先購買一些基礎課程，滿意才買更多 壞處是需要紀律，督促自己去學習，需要積極、主動一點 通常我是推薦朋友，去買這種課程，因為財務、時間風險，比實體課程小很多 真的找不到相關業者提供課程、有找到政府補助、有找到特別優秀的實體課程名師，才去找實體課程 ## 買線上課程自學 不分學期、沒有分組專案、沒有助教 基本上就是找一些影片自己來看 這種課程國外比較多，需要英文能力好 好處是費用非常便宜，通常幾百元～幾千元就有很不錯的內容 甚至有 freeCodeCamp 這種完全免費的課程 壞處是需要英文能力，並且很多只是小課程，不是完整的一套多課程規劃，會不確定自己的進度到哪了 如果有親戚朋友是業界軟體工程師，比較好，因為可以跟他請教、確認自身進度、以及確認自己求職條件如何 ## 結論 半路出家不容易，我鼓勵大家把學習想成是一個「逐漸清晰」的過程 看過電腦讀取大張高清圖片的樣子嗎？先是模模糊糊的馬賽克，接著一塊一塊慢慢變清晰，最後才是變成完整的美麗圖片 學習會有點類似這樣，一開始到處模模糊糊的沒關係，保持耐心，逐步提高各處的解析度即可 只要先有一整張模糊的圖片即可。不需要執著在圖片一個角落，覺得這塊不清楚，就不能往下走 更千萬不要因為圖片模糊，就覺得「我果然不適合寫程式，放棄好了」，這絕對是搞錯重點 以上，簡單建議分享，希望對你有幫助！ --- 您在坊間補習班的學習經驗如何呢？歡迎在留言處跟大家分享您的個人學習經驗！
每週做一些紀錄，一段時間之後，才會明確知道自己到底有沒有成長、以及到底學會了哪些東西。 來留言吧！ 說說看最近在學什麼技術＆覺得什麼部份特別難！ 大家也可以針對大家的留言，分別回覆一些建議＆指引方向！ 留言吧！養成紀錄的習慣，絕對是一個好習慣！
大家好，歡迎加入愛寫扣論壇！我是站長阿川！ 我在工作上同時是前端＆後端工程師，大約有十年的工作經驗！ 前端常用 JavaScript/React，後端常用 PHP/Laravel。 詳細技能樹：https://www.toptal.com/resume/chuan-hao-you 所以相關問題，我通通都可以回答。 --- 我注意到台灣的軟體開發討論環境，對新手實在不太友善！ 所以我開始建立＆經營這個討論區！ 歡迎大家多多發問＆討論，我本人會盡量親自回答！ 如果發問踴躍的話，我會開始找身邊的業界資深工程師，一起來參與討論！ 以上，祝您在本站能有很多收穫＆成長！
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
