👉 身份:資深全端工程師、指導過無數人半路出家轉職 👉 使命:打造 CodeLove 成為優質新手村,讓非本科也有地方自學&討論

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

阿川收到網友提問如下: > 阿川你好: > 我的背景是雲科碩畢業,算是混上去的,現在打算轉職軟工,由於有在工作,所以打算先以自學為主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 --- 以上,簡單分享,希望對大家有幫助!

回答網友提問:40歲外商高薪工程師,有點想降薪去新創公司試試看,怎麼辦?

阿川收到網友提問如下: ``` 站長阿川您好 我是一名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」的成本也不高吧? 我會覺得就去新創看看也沒關係,因為之後反悔的成本也沒多高,而且這種事就是體驗過才知道 # 結論 其實創新、創業,極度困難、要做的事情也很雜亂 在我跟各種新創公司合作的經驗來說,很多時候其實也是浪費時間、有點像在幫老闆圓個人夢想,產品本身很爛。當然我也跟很多優秀新創合作過、學到很多寶貴技能 總之去新創不一定好玩,也不一定學得到東西 但我認為有策略性地、管理好各種職涯選擇的成本、在過程中認識自己、增廣見聞、降低迷惘,是很重要的 這位網友如果本身有房貸、車貸、家庭孩子要養,那麼這個抉擇確實非常困難 另一方面,職業生涯不是只有充實金錢&地位,能夠充實人生經驗&體驗,也是很有意義的,不是嗎? 建議靜下心,好好的幫自己分析一下、聽聽看內心的聲音,新選項真的讓你有「義無反顧」的感覺嗎? --- 我另外還有一些幫助工程師觀察「眼前這位迷人的創業者,有沒有可能是個地雷」的技巧,有機會再跟大家分享吧~! 以上,簡單幾點分享,希望對大家有幫助,祝各位都有滿意、幸福的職業生涯!

回應網友提問:像站長這樣子創業,會不會餓死呢?

今天早上,在我們新手寫程式 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 萬元我是覺得也不錯呀~我還有多餘時間可以接案欸 以上,簡單心得,跟大家分享一下,未來有更多數據&心得再跟大家分享!

回答網友提問:新手去上班,該選接案公司好?還是自有產品的公司好?

昨天在我們新手寫程式 LINE 群組,有幾個工程師&想轉職的新手在討論: > 各位前輩們好,小弟是自學轉職的前端工程師,目前有兩個 offer,一個是接案公司;一個是自有產品,自有產品的那間目前只有一個junior前端,進去有問題可能沒人可以問,但看網路上好像都不太推接案公司。猶豫了很久選不出來想聽聽各位前輩的看法。 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好,我決定單獨寫一篇文章討論這件事情,跟大家分享 --- 阿川幫大家從幾個角度來分析比較一下 # 學習的深度、廣度 接案公司通常是使用類似的技術,接不同的客戶專案 好處是可以接觸很多不同的客戶,認識許多不同產業 壞處是做久了可能會開始有「重複感」,也就是好像一直在做類似的事情,有點學不到東西 產品公司通常是長期深入研發自家產品、技術 所以會在同一領域鑽研,通常可以玩得比較深入、學得比較深入 壞處是可能長期只能使用同一技術、框架,沒機會玩別款的 接案公司有時需要面對不同技術需求的客戶,有機會玩玩不同款的語言、框架、技術 # 工作的時程壓力 接案公司的時程壓力來自於「客戶」,通常已經由老闆、PM 跟對方承諾某個時間,甚至已經寫在合約上 如果同時在開發多個專案的話,有時候工程師會感到相當的壓力 通常是忙一陣、閒一陣這樣 產品公司沒有這樣的壓力,壓力通常來自於「公司沒有在賺錢」 如果公司經營穩定、產品前景看好、主管有肩膀好說話 那像這樣的時程壓力,通常會小很多 # 技術債 稍微資深的工程師,在不同公司面試時,一定會問的問題是:入職之後,需要維護 legacy(老舊)專案嗎? 維護老舊專案、負擔技術債,是一件很悲慘的事情,也是開發者的主要離職原因之一 你會被迫用已經過時的工具、語法在開發,並且要把設計拙劣的系統架構「硬搬進自己腦子裡」才能消化開發 這過程能學到東西嗎?我認為不多,基本上是在糟蹋生命 接案公司來說,如果主要負責一些新客戶,那麼經常在重啟新專案,技術債問題或許不大 如果手上負責很多「超舊的專案與客戶」,那麼可能會遇到技術債的問題 自有產品的公司,則是走向另一個極端 如果是持續有在更新版本、升級套件的熱情公司,那麼技術債問題不大 如果是有年紀、穩定的系統,那麼版本問題、系統架構的技術債問題,可能很大 嚴重起來會比接案公司更慘,因為就只有一個專案在跑 # 進去有問題可能沒人可以問 大家都希望團隊能有一個又強、人又好、又願意幫忙自己的好同事 不過這可遇不可求,身為正職工程師,你需要能夠獨立解決問題 畢竟人家也面試過了,應該就是合格了,如果真的丟一些無法解決的問題給你,那也不全是你的錯 另一方面,沒人可以問,代表你獨立做決定的空間很大,這未必是壞事 # 結論 剛轉職的新手上班,我是覺得去接案公司上班也可以 通常接案公司很缺人,也比較願意給半路出家者機會 而且開始工作的前 1-2 年,不管去什麼公司,通常都能學到很多東西 待了 2-3 年之後,覺得無聊了,再找新工作也不遲 所以回到原 po 的問題:我認為兩間公司都可以,沒有說接案公司一定比較不好 畢竟,就算是自有產品的公司,如果產品本身超爛,根本永遠不會賺錢、沒人想用 那就只是一大群人在「陪老闆追逐他的個人夢想」,那其實也是相當浪費時間的,不如在接案公司專心滿足客戶,比較充實 --- 我建議閣下不妨從「人和」的角度來觀察一下:你喜歡面試時看到的那些人嗎? 老闆、主管、同事,你喜歡跟他們相處嗎?還是你有點畏懼他們、覺得他們有點冷漠、城府、可怕? 如果實在不知怎麼選,就選你喜歡的那群人吧!跟合得來的人一起工作,總是不會太不舒服! 以上,簡單分享,給各位參考!也歡迎大家多多在留言區補充經驗、意見!

給想成為自由工作者、接案工作的一些簡單建議

上一篇文章談了「同時上班&接案&創業」的簡單策略 我發現滿多人對於接案這塊比較感興趣,提了很多問題 我簡單分享一些心得&建議 --- > 請問原po,在準備接案有想過:我的能力已經足夠接案,這種類似的想法嗎? 這幾年因為 freelancer 的身份,在一些活動、場合會遇到各種領域的 freelancer 每次遇到這些新朋友,我都會問:你是如何開始的呢? 我發現有 90% 的機率,得到的故事都是以下這樣: 「我工作幾年之後,在 XX 年的時候離職,想說休息一下,看看之後要幹嘛。這時候有前同事來問:他那邊有人在問誰能接案,能否幫忙?」 「我就先接下來,想說那做完這筆,之後再看要不要找工作。結果做完之後再休息一下,這時又有朋友來問,能不能接某個案子。」 「我就又接一個,然後再休息一下,反正不急著找新工作。就這樣加減接案,做一陣、度假一陣。過了幾個月、幾年之後,有一天發現:我好像可以一直這樣下去。」 所以根據我個人經驗&觀察:根本沒有人會下決心說,我要從此離職,轉身變成一個全職 freelancer 都是工作轉換的空檔,自然發生的。如果案子沒了,那就開始找工作上班,幾年之後離職休息,上面的故事會再重複一次。 所以重點是:為什麼這些人在轉換的空檔,會有人來問? 其實就是 1. 在工作上的表現不錯,同事、主管、合作廠商、親朋好友都覺得你值得信賴 2. 有稍微經營個人品牌,身邊的人稍微知道你是做什麼的,然後根據互動經驗覺得你「溝通能力」不錯,會讓人想合作 3. 你稍微有一點勇氣,能夠接受這種「休息一下,想想看之後要幹嘛」的狀態長達數個月之久,很多人在這狀態會很緊張,急著找新工作 然後一些有趣的事情,可能就會自然發生。當然你需要有一點點積極、願意擁抱未知,大概是這樣 --- > 我其實不清楚到底要做到什麼程度?業界常用的必備工具有沒有掌握?發生問題解決辦法能不能處理? 不論是工作、接案,基本上就是養成「挑戰能力範圍之外一點點」的習慣 不要超出能力太多,會被壓力擊倒、會開天窗、你誠信會出問題 不要完全做已經熟悉的事情,這樣沒有進步,久了會有點無聊 就做超出能力一點點的事情,常常這樣的話,久了自然會有把握&經驗 這需要時間累積,沒有捷徑、沒有秘訣 --- > 哥有推薦接案的案源嗎 根據我的經驗,你在台灣註冊任何接案平台,或者去 FB 社團搶案子之類的,案件內容&報酬都會「有點悲劇」 這沒辦法,平台化的東西,大家就是殺價競爭、紅海市場廝殺,比誰更樂意壓榨自己 你就算用英文搜尋,找國外接案平台,狀況也差不多,沒有好到哪去 所以我不推薦任何案源,我推薦你經營個人品牌。雖然有點丟臉,好像讓親朋好友看到你在老王賣瓜 但是行銷就是這樣,你多少要推銷自己一點,不然看起來一點自信都沒有,誰又能放心付個高價錢給你做案子呢? 那怎麼經營個人品牌?參考我後面的回答 --- > 希望能分享關於案源品質管控的部分(怎麼避開爛專案)🙏 如果你很外向、具有那種油條的業務性格,那你就多多跟各種客戶談生意,多多談判,累積經驗就行 如果你很內向、不具有那種談判性格,實在很怕踩雷,那我建議你:只跟你喜歡的人合作 在 LINE 上打字、Email 往來的時候,感覺對方連話都講不清楚嗎?那你們實在溝通方式有差,建議婉轉拒絕吧 用 LINE 語音,或者視訊軟體開會,感覺對方有點城府,你有一點怕他嗎?那你們做人處事原則大概很不一樣,建議婉轉拒絕吧 實在很想避開爛專案,那就只跟你覺得「跟這個人當朋友好像也沒問題」的案主合作吧! 當然工作機會,會減少很多,但是,你跟案主互相折磨、互相為難、互告上法院的機率也會減少很多 --- > 想問有建議其他職業的做法嗎? 抱歉我比較熟悉寫程式領域 但其他職業的話,我覺得經營個人品牌總是不會錯 我滿建議大家 1. 部落格 2. Podcast 3. YouTube 4. 短影片 選擇一種格式來創作,分享一些東西,目標不用高,就花幾年時間,試著經營出 1,000 粉絲就好 分享什麼?結合你的興趣 or 專業,弄點「好笑的有趣的」或「有知識技術含量的」或「能幫讀者省錢或避免踩雷或有利益可圖的」內容,就這些即可,總是會有讀者,因為看到根本賺到 這過程會學到行銷、推銷、品牌、定位,很多很多商業基本知識,零收入沒關係,就是一種商業練習 千萬不要眼高手低、整天空想、整天焦慮沒完沒了,想要搞很大,過了好幾年還是 100 粉絲都沒有 慢慢來吧,但務必要有點進度、養成進步的習慣 以上,簡單幾點分享,希望對你有幫助

阿川的軟體工程師生涯規劃:同時上班&接案&創業~!

阿川收到網友提問如下: > 您可以分享您的軟體工程師職崖規劃嗎?再次感謝 我個人的職涯規劃其實比較偏激,是同時做「上班&接案&創業」這三件事 我簡單說明一下爲什麼我會這樣做,給大家參考 --- 我是 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 社群路線

某種角度來說,我認為當工程師是很幸運的,能有兩種角度去經營個人品牌:菁英路線 vs 社群路線 --- # 菁英路線 菁英路線就是想辦法得到頂尖軟體公司的認可,比如說 Google Facebook Microsoft IBM 或者台灣本土一些知名軟體公司 或者矽谷一些設點在台灣的軟體公司 這種通常要刷 LeetCode、做大量面試準備、可能大學學歷也要很好看 這種履歷表一但有了一間,後面一間一間換,整個履歷表看起來就很漂亮 薪水好 社會地位高 大家都覺得你超猛 但這路線只適合少數人 # 社群路線 社群路線我覺得簡單、好玩很多 就是每當你的實力有所成長,就找機會大方分享 不論是寫網誌、報名 conference 分享、報名小聚分享 或者參與 open source 討論、發 PR、在 stackoverflow 問答 都是很好的貢獻方式!重要的是,這些貢獻最好能量化、有相關網址連結,在投履歷的時候可以附上 也可以在個人檔案頁面附上,這樣才能越累積越多、讓人一目瞭然 如果是在聊天室參與討論、在 FB 社團參與討論,就很可惜,相關貢獻沒辦法變成單獨網址、附上履歷表 這種路線經營一陣子後,在業界的工作機會、接案機會、合作機會,也會多很多 --- 第一條路線是面對少數人,爭取他們的認同,也就是其他精英、以及公司面試官的認同 第二條路線是面對社群,爭取他們的認同,也就是面對社群五花八門的意見、各類不同族群 就我個人來說,我是走第二條路線,這跟個性有關 --- 身為軟體工程師,我認為至少要在其中一種路線,稍微有所經營 職業生涯上,才會有點安全感,不然會常常有被淘汰的擔憂、面臨社會新鮮人競爭的擔憂

關於 e2e 測試的一些筆記

最近在幫客戶專案寫 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

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

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

主機硬碟被 mysql 的 binlog 吃光的狀況處理

租用了新的雲端主機,有一天發現全部線上網站都掛了 經檢查發現是硬碟被吃光了,但是我應該沒有存那麼多資料&圖片才對 使用指令慢慢檢查根目錄,在查到 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 功能了,持續觀察幾天看看!

CodeLove 前輩分享寫作計畫:VIP 審核限定

大家好,我是站長阿川 我留意到 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 有問題歡迎直接留言與我討論!

在家上班 WFH 反而壓力變很大?分享四個溝通技巧!

昨天在我們新手寫程式 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 工作者也比一般的工作者更知道怎麼溝通、避免溝通誤會。 # 結論 這些工作方式有點違反一般的工作直覺,所以容易被忽略。 但只要習慣一下,一定會發現遠端工作的好處,工作效率甚至比在辦公室更高。

非本科轉職,到底要學什麼語言?請參考:CodeLove 程式語言新手友善指數

在我們新手寫程式 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,那你可能要同時請他推薦職缺了!因為幾乎沒有願意給你機會的職缺! 以上,簡單分享,希望對你有幫助! 可以留言:你想看的程式語言,我找時間做一份更新、涵蓋更多語言的!

Laravel 5.8 升級到 8.83 版本心得&筆記分享

手上有多個網站 都是 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

回答網友提問:如果前端要銜接後端的話,是不是學 node.js 比較快?

昨天在我們新手寫程式 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 一點,這樣 以上,簡單分享,希望對類似狀況的朋友有幫助!

回應網友提問:我是新手前端,公司叫我學一點 php + laravel 串 API,該從哪邊學起呢?

昨天在我們新手寫程式 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%學員會吸收不良,什麼作業跟專案,簡直就是助教在幫你寫,只是貼一貼改一改,跑得動就畢業了,學員自己心裡都很不踏實 多花點時間查畢業學員評價吧,也多跟業者詢問、聊聊,真的心動了,就衝吧,也沒其他方法了 以上,簡單幾個問題,希望對你找方向有點幫助!

回答網友提問:32歲非本科考慮轉職工程師,壓力很大,怎麼辦?

阿川收到網友提問如下: ``` 我最近有在看前端的一些基礎課程,想問問如果32歲想轉職工程師是不是不吃香😅畢竟我也不是本科的 ``` 看過很多人提出類似問題,寫一篇公開回答跟大家分享,給類似狀況的人參考。 --- 首先我自己親自指導過轉職的,年齡最大的是31歲、非本科、私立科大夜間部,原本在餐飲業 在網路上搜尋「30歲轉職工程師」、「40歲轉職工程師」、「50歲轉職工程師」 會發現30歲相關文章很多,大家議論紛紛 40歲相關文章比較少,持鼓勵、正面意見的佔少數 50歲相關文章,一篇心得分享都沒有 我建議把幾歲轉職當成是一個「漸層問題」,不是非黑即白的「二元問題」 也就是年紀越大越難,但沒有過了幾歲就一定不行這種事 --- 再來我認為要務實一點,不論自學或上課,半路出家至少也需要2個月~6個月的時間 請減少生活開銷,然後原本工作可以的話,先別辭掉,利用晚上&週末的時間進修,壓力也小一點 不然壓力大到睡不著覺的話,精神不佳,學習效果怎麼會好呢? 然後建議多找幾種學習方法試試看,如果一種不行,就換另一種方法試試 別太快覺得「自己不行」,說不定是「老師不行」,或只是方法不適合你 我建議先大量找免費或便宜的教材,先吸收,多試幾份,真的卡關了,再開始挑補習班 先直接找一些作業跟專案寫寫看,從免費 -> 便宜的 -> 稍貴的,這樣一點一點花錢,風險比較小 更認識自身需求之後,再去比較市面上的各種補習班,最後再把這錢花下去,比較保險 --- 最後我必須說,2023 全球軟體業狀況比較嚴峻,目前職缺好像比較緊縮,不知道何時會恢復 這跟 2008 年金融海嘯出社會的新鮮人狀況一樣,就是比較倒霉 反正轉職過程中,記得早點開人力銀行等等網站,看看職缺狀況,心裡有個底,知道一下要面臨多少競爭 順帶一提,我也有設計免費的 html&css 教材,還有優惠的 javascript 教材,內含「大量練習專案」,不論你最後選擇哪種學習方式,我都推薦搭配拿去學習、練習,稍有難度,但不少人全做完之後就順利面試上班了 以上,祝各位轉職順利!

去補習班進教室學全端開發,有90%的機率你會吸收不良

阿川近期收到網友私訊詢問,簡單來說,就是他報名了某補習班,需要進教室上課四個月 從設計軟體 figma 到後端 php 到前端 vue 通通都教,最後要分組做一個完整專案 結果吸收不良,感覺什麼都碰、什麼都沒學好,現在糊裡糊塗在搞專案,就算弄出來也感覺很不踏實,怎麼辦? --- 阿川從過去幾年指導朋友半路出家的經驗、幫朋友找補習班的經驗,一聽就知道,這種安排,90%的學員會吸收不良 原因主要有兩個 第一,每位學員的積極程度、理解速度,通通不一樣。大家一起進教室聽老師一堂一堂講,一定有人嫌慢,一定有人嫌快 嫌慢就算了,至少該學的都有學到。嫌快就慘了,花了大錢結果跟不上進度,之後還要每週到教室報到,這很折磨人,學習效率也差 第二,半路出家,通常就找「無經驗可,後端」或者「無經驗可,前端」的職缺,先入行,賺點薪水,慢慢累積經驗&自信就對了 去補習班挑戰四個月學習全端?就算是 full time 上課,我認為還是太硬了,90%的人都會吸收不良,學習效果不好 --- 就我這幾年的觀察,只有兩種人在這環境能順利學習、成長、轉職 第一種,畢業於台大XX系,在YY領域工作數年之後,毅然決然辭職,報名轉職軟體工程師成功 這種是學習能力本來就很好,學歷通常就是台清交、只是非本科 第二種,學歷不佳,工作幾年之後遇到重大挫折,有強烈經濟壓力,破釜沈舟之下,抱著巨大的決心、壓力,全心投入補習&學習 這種是壓力逼迫人成長,在自己給自己高壓&痛苦之下惡補成功轉職 我認為90%的人,不符合以上狀況,會變成花大錢、花超多時間,最後還效果不理想 最糟糕的是,學習應該是要能逐漸建立興趣&信心的 這種學習成果,就算最後開始去幾間公司面試,也會超心虛,覺得自己好像來騙的,專案根本自己也沒搞懂幾行程式碼,拼拼湊湊不知道在幹嘛 --- 我在多篇文章提到過,我建議就是先找「便宜、有口碑的線上課程」 至少可以按自己步調學習,至少不會花那麼多錢 然後先專心在前端或後端就好了,可以稍微花點時間碰全端,有一點概念,也很好,但不要嘗試直接專精兩者 學過、有更了解之後,再花錢去補習班。不要一開始就用「賭賭看」的心態進教室,你的時間&金錢很寶貴 何況很多人就用線上資源學一學,就順利去上班了,有些根本是用國外「免費」資源,一毛錢沒花 --- 最後,對很多人來說,看到這篇文章,時間已經花下去了,錢已經花下去了,怎麼辦? 阿川還是有些建議可以給大家 第一,全課程這樣上完,雖然吸收不佳,但至少有稍微留個印象 請拿出筆記本,多多做筆記「這邊沒聽懂 但好像很有趣」、「這邊沒聽懂 但老師剛有提到幾個關鍵字」,找時間自己多 google 一下 還有「這邊沒聽懂 但感覺好古板啊 這東西業界真的有用?」,找時間去社團或論壇發問,請教一下業界人士 總之,挑能吸收的部份 加減吸收一點 自主練習時,卡關了,至少還知道點方向 第二,不要太快失去信心 「如何學習」本身就是一輩子的技能,有時是學習方法問題、或節奏問題、或方向問題,先別急著放棄 課堂上的作業,找時間自己重看一次:如果有哪行程式碼不懂,就多 google 或發問,慢慢弄懂,慢慢補回自信 --- 最後,我再補充一個觀念給大家,半路出家不容易,我鼓勵大家把學習想成是一個「逐漸清晰」的過程 看過電腦讀取大張高清圖片的樣子嗎?先是模模糊糊的馬賽克,接著一塊一塊慢慢變清晰,最後才是變成完整的美麗圖片 學習會有點類似這樣,一開始到處模模糊糊的沒關係,保持耐心,逐步提高各處的解析度即可 只要先有一整張模糊的圖片即可。不需要執著在圖片一個角落,覺得這塊不清楚,就不能往下走 更千萬不要因為圖片模糊,就覺得「我果然不適合寫程式,放棄好了」,這絕對是搞錯重點 以上,簡單建議分享,希望對你有幫助!

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

收到網友提問如下: ``` 這是最近跟一個朋友聊天聊到的 朋友是寫 .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 甚至是跟朋友一起創業當副業 總之不用一開始就強迫自己一定要選好前端或後端 迷惘、探索、好奇的狀態,本來就是人生的常態 有時間的話,就都學吧!急著賺錢的話,可以先從前端開始~! 以上,簡單分享

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

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

同事寫 css 大量使用 !important 導致很難維護,怎麼辦?

# !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 就是屬於這類東西,打起來很怪很累,所以當然不應該濫用 --- 以上,簡單分享

給新手工程師的建議:每天工作都在查 ChatGPT 會不會很糟?

給新手工程師的建議:每天工作都在查 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 沒問題,但是你要知道自己拿到的程式碼,到底實際上在做什麼 這樣用了之後,出問題才能除錯、必要時才能擴充、才能加功能 以上,簡單分享,大家有什麼問題,可以多多提問,我盡量回答

Composer 進階原理:PHP命名空間與PSR-0

上次的說明了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..我們下次再談。

COMPOSER 設計原理與基本用法

相信有在用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是如何解決自動載入的問題呢? 這些比較進階的內容,下回分曉。

西元 2023 年了,還值得花時間學 Dreamweaver 嗎?簡單分享幾個觀點

首先我們來看 google trend ![](https://i.imgur.com/GwTUmvo.png) https://trends.google.com.tw/trends/explore?date=all&geo=TW&q=dreamweaver&hl=zh-TW 如你所見 這是一個過時的技術、正在被人們拋棄 接著請到 google 搜尋 `dreamweaver 職缺` 會發現其實 還是有些職缺要求要會 dreamweaver 這些職缺的待遇、工作內容 都在各大人力資源網站 你可以自行判斷:這些是不是你求職的目標職缺、理想職缺 --- 再來是我個人經驗,我這十年職場所見所聞,沒有遇過公司在用 Dreamweaver 我在社群認識各類工程師,也沒聽過有人在用這工具 不得不說 這實在是一個很老派的工具 唯一有次在業界遇到 好像有人在用的情境 是一間接案公司 以快速、便宜為主打 他們當時需要有人能用低價、快速的方式 把大量網頁切出來 後來找到的配合的人 好像就是用 Dreamweaver 在切版 --- 如果對 Dreamweaver 有興趣、好奇 我覺得多學一個工具 也不是壞事 對於之後再學其它工具 也是會有幫助 但是 應該沒必要花時間「專精」或者「鑽研」這樣一個老舊的工具 如果課程要求 或是有證照需求 那評估一下需要花費的時間 如果證照沒那麼難考 那花點時間 拿個證照 也滿好的 還能培養一些自信 如果履歷表還沒什麼東西能放 那放個證照也不錯 但如果考那證照很花錢、很花時間 那請審慎思考一下這投資值不值得 我是不推薦 我感覺只是培養快速、低成本切版網頁的能力 這能力頂多在接案公司會有幫助 而且還不會是很精緻的接案公司 不如花時間深入研究 JavaScript 基本功,對前端職涯更有幫助,而不只是專精於切版而已 --- 以上 簡單個人觀點分享

🎉🎉🎉 恭喜 birdie 順利轉職&給新入行者的簡單建議 🎉🎉🎉

首先恭喜,本站的最早一批學員之一 @birdie2019 順利找到工作上班啦~ 趁這機會,順便簡單分享幾個給新入行者的建議 ## 建議積極衝刺 9 - 18 個月 剛開始上班一定是手忙腳亂又緊張,建議前三個月拼一點,拿出「讓人印象深刻」的表現,先站穩職場,自己也比較有安全感 雖然一開始會覺得自己實在很弱,但是,利用業餘時間多讀技術文章,持續 9 -18 個月,會有巨大成長,到時回頭來看,連自己都會吃驚可以進步這麼多 新手工程師,前 3 - 5 年的薪水通常會快速成長,因為能力也會快速成長 除非公司真的很凹人、待遇真的很不滿意,否則剛入行,就先拼一下吧 ## 大小問題,多多上來發問 目前這論壇上的發問、討論內容,還是偏少 大家可以多多發問,我也需要這些提問,來當成寫作的靈感 不然我常常也不太知道大家想看什麼,我要寫哪些文章 就貼文發問吧! ## 養成筆記的習慣 可以用自己筆記本、部落格、或直接在這邊定期發文 有整理出一些東西、觀念,都可當成隨手筆記貼在這,未來要翻閱的時候,比較容易找到 心有餘力的話,定期寫學習心得分享,更好 這個習慣的重點在於:**溝通能力的訓練** 軟體工程師需要「極強的溝通能力」,寫作可以訓練這點 現在遠端工作越來越普及,「強大的寫作能力」也會對職涯很有幫助 所以要多多找機會寫作,本站的內容也都可透過 API 撈出來建立獨立的個人網誌 --- 以上,簡單分享,我希望能盡快看到第二、第三位順利轉職的同學出現喔~

常常懷疑自己該不該繼續走程式設計?簡單分享幾個觀點

不論是在學生、正在轉職、或是剛開始上班 不少人常常有這念頭:我好像不太適合走這條路,怎麼辦? 讓我簡單分享幾個觀點 # 關於天份與熱情 很多人對於社會上各種工作抱有「資格論」的傾象 我抱持相反觀點,我認為你在各行各業,沒有天份、沒有熱情也沒有關係 詳細理由我不贅述,請參考我之前的文章:寫程式不需要天份,也不需要熱情 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 會取代軟體工程師嗎?你完全不需要擔心這個

最近看到滿多年輕學生、考慮轉職者提問:未來 ChatGPT 會取代軟體工程師嗎? 看來這個議題已經造成不少 IT 領域學生的焦慮,我非常驚訝,讓我簡單談論一下這件事 # 個人經驗回顧 我在畢業前全心學習 web 前端與後端開發,2012 年畢業時,正逢智慧型手機快速發展,所有公司都在思考如何開發手機 app 來創造新機會,當時媒體的主要論述是:「web 已死!web 工程師都將失業,未來是 mobile app 的世界!」 當時年輕的我,看到這些媒體這樣分析,也是有點焦慮,但同時又有點不服氣,所以依然 100% 心思在研究 web 開發,不管媒體怎麼看衰。現在,10 年過去了,請問 web 職缺消失了嗎? # 媒體的習慣、網紅 YTer 的習慣 想像你住在一個非常小的島嶼國家上,往外走一下就看到海,國家全年365天基本沒什麼大事,每天就是太陽升起、太陽落下。如果你是島上的「新聞從業人員」,請問你每天能做什麼?你當然只能誇大你看到的每件事情。 看到海水漲潮,發新聞:「海水異常上漲!恐有釀禍危機!全國一半人口恐有水災、死亡風險!」 看到海水退潮,發新聞:「近三年最低點!海水不斷消退、國家水資源流失、重大警訊!我國恐成大型沙漠!」 世界上大多數事情本就「帶有波動性」,一下狀況好一下狀況壞,潮起又潮落,正如月有陰晴圓缺,這相當正常。 媒體、網紅,基本上需要吸引人們關注來過活,他總不能每天發新聞:「今天海水正常漲潮,沒什麼特別的。」、「今天海水退潮了,這很自然,不太重要。」 身為現代公民,你要有能力透過媒體吸收新知,但同時也要有能力保持冷靜、自行判斷,不要隨意被影響。你要能看出各種觀點背後相關的利益。 # AI 對職缺的影響 AI 當然對各行各業會有重大衝擊,但是目前也僅止於改善工作效率、優化流程而已。 AI 因為可以加強專業人員的生產力,所以會造成職缺變少一點,但要到「軟體工程師通通失業」、「就靠機器人寫完所有程式」這種程度,實在太誇大了 最後,程式設計已經是各種工作領域之中,最難被機器取代的職缺之一,如果真的被高階人工智能取代,那社會上已經沒有多少工作適合人做,大概會是「無條件基本收入」制度之類的社會 --- # 結論 太廢的技能、感覺問 google 或問 ChatGPT 就有的東西,可以不用學了,像死背課文一樣的任務再也不用做了 除此之外,該學什麼學什麼,不用想太多 上個時代,懂得善用 google 與網際網路的專業人士 vs 不懂得善用的專業人士,生產力有巨大差別 下個時代,懂得善用 AI 的專業人士 vs 不懂得善用的專業人士,生產力有巨大差別 除此之外,跟案主溝通、釐清功能規格、分析各種技術選擇、認識領域知識並設計軟體,是極度複雜的工作,你真的覺得一個機器人放在面前聊天幾分鐘,它就能通通做完給你? --- 以上,簡單看法分享

學習寫程式,閱讀文章好?觀看影片好?其實,重點是...

看到有人提問:學習寫程式,閱讀文章好?觀看影片好? 其實,重點是:「動手做有趣東西」 不論是到教室上課、還是線上學習,不管是讀文章或是影片,都差不多 重點是要動手做,而且要做有趣的東西 很多課程設計,在練習作業的地方,會出一些很無聊的作業 比如說什麼模擬螞蟻走路,走幾步路,什麼超無聊的小程式 寫完根本不知道在幹嘛,一輩子根本也不會實際需要寫什麼模擬螞蟻走路 要寫有趣、感覺實務上真的會用到的小程式才有趣,才有吸收的感覺 --- 第二個重點是,作業不能提示太多,否則大家會下意識一直複製貼上、複製貼上 東西最後寫出來,也沒有任何成就感,什麼也沒學到 --- 如果你正在學習的課程,沒有設計這種作業,那就要花點心力,自己想想看: 根據這課學到的內容,我能不能試著做點什麼小東西? 然後在嘗試的過程中,卡關、試著解決、卡關、試著解決,這樣下去,才會有慢慢吸收、累積的感覺 --- 以上,簡單建議分享

寫程式工作10年之後,對於2023的一些看法&建議分享

對於轉職寫程式、或是業界情況好奇、擔心的人很多 簡單分享一些看法&建議 # 前端好像很氾濫,現在適合轉職前端嗎? 過去幾年,我指導過很多非本科的朋友入行,幾乎都是從前端入行(也有少數是從 iphone 開發、網站後端、資料科學入行) 我都分別問過這些朋友 轉職前的薪資 說真的 在台灣 有很多產業、領域 薪水對年輕人真的很不友善 寫程式這一行 前端雖說門檻低、就業者越來越多 這些都是事實 但是 跟很多行業比起來 薪水還是有比較好 而且進步空間很多(台北的工作機會又會更多一些) 所以 如果受不了原本產業的低薪 考慮寫程式 就試試看吧 先找書 或是便宜的線上課程試試就對了 (真的要花數萬~十幾萬找補習班之前,切記要多打聽,多比較) # 2023景氣好像很差,很多軟體公司裁員,業界很慘嗎? 新聞上看到的 矽谷各大科技公司裁員幾千幾萬人 都是真的 但是台灣的軟體業還沒出現這情況 主要原因是 北美的公司本來就比較多「創業投資人」的資源&募資 台灣的軟體業本來就沒拿到多少投資人的錢 😂 簡單講就是窮習慣了 現在全球資金緊縮 台灣業界本來就不是特別高薪的地方 所以衝擊反而還好 😂😂 (不過,很多靠過去幾年ABC輪募資撐下來的新創公司 現在都有危機 這是鐵定的) 我有在兼職接案北美的案子 目前北美的案件報酬大概打6折左右 非常慘 什麼時候會回溫不知道 不過,身在台灣,打開徵才網站,很多公司還是有在徵才,篩選條件選「無經驗可」就可找到「可接受半路出家」的職缺 所以,大環境沒辦法預測,想入行的話,還是先學就對了,還是有不少機會 # 我想轉職寫程式,未來也許可以接案子、賺外快,對嗎? 工作3-5年之後,基本上多少會有親戚朋友,想找人接案寫程式 這種機會有是有,但,有幾件事還是要分享一下 要常態獲得接案收入、甚至全職接案的話,是滿困難的 首先,自由工作者需要有兩個特質,第一個是談判者特質,也就是樂於談判,拉高價碼、限制住案主規格,這樣才能有較好利潤 第二個是銷售者特質,也就是樂於老王賣瓜,自賣自誇,這樣才能被人看見,有更多機會 我認為大多數人並不會喜歡做這兩件事,我自己也不太擅長、也不太喜歡做這兩件事,所以,接案這條路,偶爾賺一點可以,要經營得好,並不容易 最後要說的是,台灣的發案報酬,常常會比你想像的還要「低很多」,有人拿幾千元就希望你架一個網站給他,或者各種離譜的情況,很多 這些都要花時間處理,很多時候綜合比較下來,直接在一間不錯的軟體公司上班、學習,還比較好 以上,簡單分享,大家有什麼問題,可以多多提問,我盡量回答

簡單說明什麼是 RESTful

在後端設計 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 的意義,有沒有不清楚的地方?

Ruby on Rails 之父:我怎麼學會寫程式的?

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執行?哦,我需要在這裡加一個迴圈。哦,我需要在哪裡抓些資料庫的資料出來。 決定目標的當下,你的點子就完成一半了、而且你還知道了該怎麼做。 簡單來說,就是從一些確實的東西開始做起,接著讓時鐘發出「滴」聲,然後讓它發出「答」聲。

MVC是一個巨大誤會

我是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

給OOP初學者的建議:先搞懂「資料跟行為在一起」就好,其它的慢慢來

初學者接觸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就是「資料跟行為在一起」加個但書: 要以方便理解程式為前提,將資料和行為放在一起。

給寫完 JavaScript 系列九的同學們:求職前的準備&簡易指南

有幾位同學已經寫完系列一~九的全部作業了 整體能力已經可以準備開始面試前端工程師的職缺了 這邊寫一篇簡單說明 # 需要補充的技能 前端技能中最困難的部份已經有相當基礎了 剩下有些東西沒那麼難,但要學一下,上班會用到 這些東西我未來可能會寫教材,但我最近很忙,近期無法寫新教材 ## 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 私下回答 以上,有打算轉職的同學,祝大家早日上班囉~

初次轉職寫程式:作品集有用嗎?要做什麼作品?面試官會看嗎?

很多朋友轉職寫程式,在補習班或者線上課程,告一段落之後,開始找工作之前,會整理作品集 關於作品集,簡單給大家一些建議 ## 作品集有用嗎? 公司在徵人的時候,其實來應徵的人五花八門 滿多人看起來,根本不會寫程式,連最基本的小網頁或者小程式都寫不出來 連基本技能都沒有準備好,感覺是到處碰碰運氣、履歷亂誇大就到處丟。公司面試時,最怕遇到這種狀況 作品集,至少代表,你寫得出基本東西。很多人根本寫都不會寫,就去應徵了,作品集至少可以讓公司避免踩雷 話說回來,如果你的作品集,只是補習班的幾個分組專案,糊裡糊塗地完成了,就跟在學校敷衍交報告一樣,你對細節其實不了解,那這種作品集,當然幫助不大,對你的信心也沒有多少幫助 ## 要做什麼作品? 所以該做什麼作品呢? 最好做一些你真的需要的「應用程式」,寫起來才有動力、才好玩,內容也才扎實 簡單舉例,如果你在受訓的過程是這些: ### 前端工程師 做個待辦事項清單工具吧!按照自己的喜好設計,做完之後找地方上線 在找工作的這幾個星期,實際拿這個工具來做紀錄,投履歷時、面試時,很自然可以分享你的心得跟小熱情 對面試官來說,看到面試者有即戰力(即便是有一點點)、對自己的程式有熱情(即便只有一點點),都會加分不少 請參考 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 這種完全免費的課程 壞處是需要英文能力,並且很多只是小課程,不是完整的一套多課程規劃,會不確定自己的進度到哪了 如果有親戚朋友是業界軟體工程師,比較好,因為可以跟他請教、確認自身進度、以及確認自己求職條件如何 ## 結論 半路出家不容易,我鼓勵大家把學習想成是一個「逐漸清晰」的過程 看過電腦讀取大張高清圖片的樣子嗎?先是模模糊糊的馬賽克,接著一塊一塊慢慢變清晰,最後才是變成完整的美麗圖片 學習會有點類似這樣,一開始到處模模糊糊的沒關係,保持耐心,逐步提高各處的解析度即可 只要先有一整張模糊的圖片即可。不需要執著在圖片一個角落,覺得這塊不清楚,就不能往下走 更千萬不要因為圖片模糊,就覺得「我果然不適合寫程式,放棄好了」,這絕對是搞錯重點 以上,簡單建議分享,希望對你有幫助! --- 您在坊間補習班的學習經驗如何呢?歡迎在留言處跟大家分享您的個人學習經驗!