🏠 首頁

🏠 首頁

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

不論是在學生、正在轉職、或是剛開始上班 不少人常常有這念頭:我好像不太適合走這條路,怎麼辦? 讓我簡單分享幾個觀點 # 關於天份與熱情 很多人對於社會上各種工作抱有「資格論」的傾象 我抱持相反觀點,我認為你在各行各業,沒有天份、沒有熱情也沒有關係 詳細理由我不贅述,請參考我之前的文章:寫程式不需要天份,也不需要熱情 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年之後,基本上多少會有親戚朋友,想找人接案寫程式 這種機會有是有,但,有幾件事還是要分享一下 要常態獲得接案收入、甚至全職接案的話,是滿困難的 首先,自由工作者需要有兩個特質,第一個是談判者特質,也就是樂於談判,拉高價碼、限制住案主規格,這樣才能有較好利潤 第二個是銷售者特質,也就是樂於老王賣瓜,自賣自誇,這樣才能被人看見,有更多機會 我認為大多數人並不會喜歡做這兩件事,我自己也不太擅長、也不太喜歡做這兩件事,所以,接案這條路,偶爾賺一點可以,要經營得好,並不容易 最後要說的是,台灣的發案報酬,常常會比你想像的還要「低很多」,有人拿幾千元就希望你架一個網站給他,或者各種離譜的情況,很多 這些都要花時間處理,很多時候綜合比較下來,直接在一間不錯的軟體公司上班、學習,還比較好 以上,簡單分享,大家有什麼問題,可以多多提問,我盡量回答

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

[好文分享] 太屌了吧!?用Class(類)製作Jquery的效果!

## 目錄 ##### [【前端動手玩創意】等待的轉圈圈效果 (1)](https://ithelp.ithome.com.tw/articles/10311621) ##### [【前端動手玩創意】google五星評分的星星(2)](https://ithelp.ithome.com.tw/articles/10311643) ##### [【前端動手玩創意】CSS-3D卡片翻轉效果(3) (今天難度頗高,想挑戰再進來!)](https://ithelp.ithome.com.tw/articles/10311672) ##### [【前端動手玩創意】一句CSS做出好看的hero section!(4)](https://ithelp.ithome.com.tw/articles/10311691) ##### [【前端動手玩創意】創造一個Skill bar(5)](https://ithelp.ithome.com.tw/articles/10311756) ##### [【前端動手玩創意】遮蔽廣告(D卡未登入)腳本、自定義新增名單(6)](https://ithelp.ithome.com.tw/articles/10311999) ##### [【前端動手玩創意】前端canvas截圖的招式!竟然有三招,可存成SVG或PNG (7)](https://ithelp.ithome.com.tw/articles/10312001) ##### [【前端動手玩創意】讓你的PDF檔案更難被抓取(8)](https://ithelp.ithome.com.tw/articles/10312046) ##### [【前端動手玩創意】哇操!你敢信?花式寫todo-list,body裡面一行都沒有也能搞?(9)](https://ithelp.ithome.com.tw/articles/10312056) ##### [【前端動手玩創意】卡片製作,才不是!是卡片製作器!(10)](https://ithelp.ithome.com.tw/articles/10312066) ## 前情提要 各位知道jquery,這個JS的函式庫提供我們非常多實用的方法,包裝好給我們用。 其中底層邏輯都還是跑不出js原生的概念, 今天就讓我們用原生JS的類來創造一些Jquery幫我們打包好的方法吧! 來掀開它的奧秘底牌。 ## 程式碼內容 假設我們要創造一個叫做Dquery的東西,該怎麼做呢: ``` class Dquery { constructor(selector) { this.elements = document.querySelectorAll(selector); //噴出DOM來 } css(property, value) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].style[property] = value; } return this; //修改style } addClass(className) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].classList.add(className); } return this; //增加class } removeClass(className) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].classList.remove(className); } return this; } on(eventType, callback) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].addEventListener(eventType, callback); } return this; //監聽事件的運作 } html(htmlString) { if (typeof htmlString === 'undefined') { return this.elements[0].innerHTML; } else { for (let i = 0; i < this.elements.length; i++) { this.elements[i].innerHTML = htmlString; } return this; } } } function $(selector) { return new Dquery(selector); } ``` ## 觀念筆記 其實概念就是先把底層邏輯刷過一遍 最後return this 就達成jquery的效果了唷。 ## 心得 Jquery曾經非常流行,儘管後來式微了,卻還是有一批死忠的粉絲鍾愛著它的簡便, 事實上它就是JS,所以討人喜歡也是正常的, 這次學會了用ES6類的概念,會讓我們在前端的功力大幅提升唷!!

HTML新標籤dialog簡化modal實作

看youtube看到的 新的<dialog></dialog>標籤內建開關api 範例: ``` const dialog = document.querySelector("dialog") dialog.show() // 打開dialog(原先位置) dialog.showModal() // 打開dialog(置中且屏蔽背景) dialog.close() // 關閉dialog ``` 幾個重點: 1.不用再用CSS display開關 2.用showModal()自動置中且屏蔽背景 3.modal設定css背景方式: ``` dialog::backdrop { background-color: hsl(250, 100%, 50%, 0.25); } ``` 4.可結合form使用,form提供新的method="dialog",或是form裡面的button設定formmethod="dialog"來關閉 ``` <dialog> <form method="dialog"> <input type="text" /> <button type="submit">Submit</button><!-- 不會submit--> <button formmethod="dialog" type="submit">Cancel</button><!-- 不會submit--> </form> </dialog> ``` 5.如果想要點擊dialog以外的地方自動關閉可用下列程式碼: ``` dialog.addEventListener("click", e => { const dialogDimensions = dialog.getBoundingClientRect() if ( e.clientX < dialogDimensions.left || e.clientX > dialogDimensions.right || e.clientY < dialogDimensions.top || e.clientY > dialogDimensions.bottom ) { dialog.close() } }) ``` 6.dialog.close()方法可以傳值到Dialog.returnValue ``` Dialog.close(valueToPass) const getValue=Dialog.returnValue ``` 參考資料: [Modals Will Never Be The Same - HTML dialog Element](https://blog.webdevsimplified.com/2023-04/html-dialog/) [影片 The New dialog HTML Element Changes Modals Forever ](https://www.youtube.com/watch?v=ywtkJkxJsdg&t=620s)

[心態分享] 新手學前端應該具備的心態:絕對不是謙虛,假謙虛的心態:做作又噁心!

## 前情提要 最近在網上想找一些學習前端的夥伴,發現要組個討論會非常的難。 是因為沒有人學前端嗎?不是,與事實相反,非常多人學。那麼是因為大家程度太差嗎? 也不是,其實自學的人吸收能力都不錯。 那到底是因為什麼,其實是源自於一個魯蛇心態:「貶低自己、迂迴溝通」 ## 觀念解說 什麼意思?貶低自己?沒錯,很多前端新手當要進行自我介紹或是參加討論, 都因為自尊心太高,要幫自己打上一堆預防針:「我還是菜鳥,我什麼都不會。」 當人家問你說寫過什麼,就說:「都只是一些人家的作業,我沒有做什麼耶」 你以為謙虛是一種美德,事實上這種噁心的做作,只是降低大家討論進步的溝通效率, 要人家稱讚你老半天說:「不會啦!很棒,有東西就拿出來」 你才願意把你自己的作品連結丟出來。 事實上你明明就有自己嘗試做過一些東西,一定要迂迴老半天才願意拿出來,真的太假掰。 ## 健康的心態 那麼前端的新手應該具備什麼心態呢?我們要培養的不是假裝謙虛:「我什麼都不會啦,只是照著做」 「就看網路課程而已,我只是剛摸過js」 「對框架沒概念耶,只是看過VUE的課程。」 就省去這些假掰的噁心詞彙,你學過什麼就說出來,把自己會的東西講出來, 明明學過,又不願意老實講,真的很糟糕。 這不僅是對自己的尊重也是尊重別人。 別人沒有義務必須要每一次的對話都要先稱讚你,才有辦法跟你討論正事。 格局多大,完全建立在你自己的心態健康不健康之上。 做過什麼作品,就算是抄課程上的那就拿出來講,表達出來才有辦法討論。 不是明明你也想要找學習夥伴討論、交流,真的要互相討論的時候才拿出來當作藉口。 那你到底是想要進步,還是你只是想要人家安慰? ## 總結心得 我不知道這是源自於人格上的自卑,又或是東方文化容易被打擊所培養的自我防禦意識。 但在前端程式的交流,真的要練習培養大方的態度, 實事求是,不需要你把自己包裝的多厲害,只要不要你裝模作樣說自己什麼都不會、 什麼都沒寫過, 問了老半天才要把你明明偷偷嘗試過的五種作品拿出來,才發現你bs5也碰過、VUE也學了, 那講了老半天的預防針到底有什麼意義? 請培養健康正確的心態,不要看不起自己,也請尊重別人跟你溝通的對談成本。 真的沒有人有義務一路上安慰你,想要討論交流,你必須擁有正確大方地表達、人格態度。