Open Lauviah0622 opened 4 years ago
後來發現 week11 好像作業寫的漏東漏西的
今天在咖啡廳遇到一位後端工程師(你要知道在宜蘭遇到寫 code 的人有多困難),不過是外國人,就用破英文聊了很長一陣子(真的很長,大概是 10:30 到 14:30)。聊了真的是蠻多的,自己都嚇到怎麼可以聊這麼久。對方之前似乎在新加坡創業,但是因為武漢肺炎就失敗了,聊的內容從目前網頁開發技術的趨勢、如何增進自已的技術、要用甚麼態度去應徵工作、什麼樣的工程師、還有真的是很多很多。
有一個有趣的看法是他覺得 side project 並不是有效增進技術的方法,自己埋頭寫反而不會增進 code 的品質。反而是去看別人的 code ,然後搞懂別人是怎麼做的會進步得更快,在 code 上面留下 comment,甚至還可以 PR 回去。自己想想覺得是蠻有道理的,如果你不在公司,那能接觸到的專案會很有限,這時後 github 上面星系等級的專案就是很好的練習目標,因為他們的 code 一定有良好的架構(至少有一定水準),comment 可以理解他們的架構,久了久之下來也會內化成自己的東西。
還有聊到有提到說自己目前還在猶豫要不要做打工還是借錢來專心上課,結果得到一個超意外的答案,他認為我可以去應徵工作,當下就想說根本沒有公司會收一個做四個月就要當兵的人吧。不過他的看法是,我們會覺得是比起公司,求職者更加需要一份工作。但其實相反,是公司更加需要一個人來處理公司的事情,因為他們會有進度、有股東的壓力。就算是處理小事情也好,如果有可以用的人也會想要應徵,即使是短期或者是實力比較差,但也是一個戰力。而且很多職位要求西瓜刀,但實際工作只用到美工刀,所以可以多試試去應徵看看有沒有短期的實習。
還有很多很多啦,真的太多了,可能明天在分享。
如果偶然看到小弟昨天的報告會知道說小弟昨天和一位外國的後端工程師聊天(應該是不會有人看吧),讓我蠻驚訝的是,他已經 40 歲了,當時遇到他的時候她正在學 Java,他之前是用 Python 做後端的,雖然沒有問他為什麼要學,但是 40 歲還有動力去學習新的東西,甚至是一個新的語言真的是真心覺得超厲害,其實也有點激勵到自己,還有這讓我知道說寫程式是一個可以做到老的事情(不過學習也是宿命就是了)。原本學 Python 然後學 Java 會很困難嗎?他的看法,雖然是不同語言,但基本上都是利用不同的語言處理一樣後端的事情,其實在後端來說 API 是大同小異的,所以需要學習的是 Python 的語法、還有了解一下 Python 後端的情況還有架構,並不會到太困難。
因為最近碰到的 PHP 就有同感,剛學 JS 的時候都不太會知道有哪些東西可以用,像是因為剛學,所以不知道說 array 會有 push, pull, 或者是怎麼去遍歷整個 array;但是接觸第二門語言(嚴格來說也不算第二門)就不一樣了,不管甚麼語言的 array 一定都會有 push,而且也一定會有一種資料類型可以儲存 key value pair(應該是吧,其實沒有很確定)。印象很深的是在寫 PHP 的時候有需要用到類似JS object 的儲存方式,其實就是上面的 key value pair 拉,雖然沒學過,但是就是很肯定 PHP 一定會有一個語法可以處理這種事情,事實上就是 Associative Arrays。就像那位後端工程師他會覺得後端的 API 都很像,當學過一個語言之後其實每個語言都一定會有一些基本功能,只是可能底層的細節還有實現的邏輯還有架構會不同,那在學習一個新的語言時就應該更專注於這些部分。
還有聊到說,為什麼他會 prefer 後端,先講聊完之後自己的看法好了。其實聊完之後讓我自己也開始回想為什麼開始接觸前端,一開始是因為先接觸網頁設計,然後才開始接觸前端的。原本以為是因為自己會比較 prefer 看的到的東西,不過現在也會開始欣賞程式背後的邏輯,看的到東西好像越來越少了,初衷是不是已經忘光光了(而且最近在做作業的時候還越來越排斥切版了XD)。不過對於非本科系而言本來前端就是最容易接觸到的東西吧,畢竟看的到操作的到,如果不是相關的真的會很難理解說後端、資料庫、甚至到深度學習、演算法之類的東西在幹嘛,這些東西的門檻真的是太高了。
那位 prefer 後端的原因是因為他覺得後端很酷,可以做一個東西給很多不同的人用,像是 app, web 都會要跟後端串資料,而且不管怎麼趨勢怎麼改變一定會有後端的工作,因為處理資料這些是最基本的業務,先不管說他的論述有沒有道理,但是聽到這樣的理由是覺得蠻酷的,就是個蠻特別的理由。
不知道可以講這位後端可以講多久,感覺真的蠻多東西可以說的,明天再聊好了。
今天在做 hw1 的時候忽然領悟到說 react 的可貴之處(只學過 React,至少 React 是啦),或者說現在為什麼需要前端框架。如果現在還要自己處理 dom 然後去對 dom 操作增增減減,真的是太 累 人 了,而且還要盡量減少 DOM 的操作,所以就要比較說原本的 DOM 跟 新的 DOM 有甚麼差異,然後再做更新。每一個操作都要去比較 DOM ,還要去呼叫 API 去做不同的操作像是改 innertext, 改 class, 增減 element 甚麼的,如果只用 browser 提供的 API 去做真的是會崩潰。
還有要同步 UI 跟 state 也很麻煩,如果只有一點點資料還好,但是狀態一多起來真的超級麻煩,而且資料的增減也需要做比較,然後再對上 DOM 的狀態,後來想想這些可能就是現在前端框架必要的地方吧。
一個好的產品應該做好一種功能
不然會沒有時間維護
而且沒辦法帶來利潤
美國人對產品的Ux很注重 如果複雜就直接砍了
台灣人似乎比較能容忍?
還有 App 用 iOS 跟 Java 來寫跟用類似 react native 這種框架來寫有什麼差別
React native 就是讓 react 可以寫 native 才叫 react native
Js 太自由了 所已有很多爛 code Python易學 Php... 可以學框架 純的還是..
進度還在不錯的範圍,可能是 week12 的作業作得比較快吧,感覺這禮拜應該可以趕上進度。
.webpack.config.js
設定檔前幾個禮拜寫 PHP 寫到有點疲勞,覺得一樣的事情作的蠻多,不過到現在如果要用 SQL 還是會需要查一下...,回頭想想 PHP 的部分也持續的大概快要一個月了,雖然會嘲笑說 PHP 是世界上最棒的語言帶梗,但是 PHP 學起來真的是非常之快,而且也的確是不用學到很深入就可以處理很大部分的事情這點倒是無庸置疑的,這也跟 PHP 的發展歷史有關係吧,但是 PHP 可是造就了 Facebook 這樣的大公司(準確來說 Facebook 內部寫的也不全然是純 PHP,是用 Hack 寫的)。
可能之後開發不太會用到 PHP 吧,但是小規模開發用 PHP 好像也沒什麼不好,算是蠻直觀的,而且快快速速就可以作出一個簡單的 API,會一點後端就可以變出很多東西了,像是這次作業的留言板,之後如果用 Lavaeral 的框架來處理就更厲害了。而且這幾個禮拜的關係讓自己蠻期待後面 express.js 的部分,能用自己浸淫已久的 JS 來寫後端不知道有多爽。
week12 的 bootstrap 跟 Jquery 雖然會說稍微懂就好,不過可能還是有不少公司用這兩套吧(我記得很多後台都會用到 bootstrap),我覺得這兩個東西這個課程中更大的價值是怎麼去使用第三方的 library,這兩個 library 的 docs 都寫得蠻平易近人的,而且 bootatrap 這種 UI 相關的 library 之後會常常用到,這種 UI 類型的庫感覺都蠻像的(當然每個庫都會有不太一樣的核心理念拉,不過使用方式就大同小異),Component 可以讓你複製、還有一些 Layout 等等的東西,然後自己也會有一個架構,之後工作如何快速地去熟悉一套庫應該也是工作上面很重要的一環,所以覺得碰看看感覺其實不賴。
Huli 的課程覺得有一個蠻重要的理念貫串在裡面:遵循脈絡的理解,之前有先碰過一點 React 了,現在更能體會現在這些內容的珍貴。為了找工作然後學完基本的 JS 就去上 React,一開始完全看不懂那是尛,即使你可用 React 寫出一點東西,你還是不知道 React 到底做了啥(尤其是在 create-react-app 幫你把東西包成全家桶之後),你只要 npm run build
就好像擁有了全世界,但是你卻不知道自己腳踏了甚麼東西。但是這幾週先作了 MPA 再作 SPA,自己開了 API,然後也理解說 webpack 到底幹了啥,自己之前超級不能理解為什麼 React 可以 import 圖片還有 CSS 的,反正就是 Maaaaaagic,不過當你把一切都覺得是 Magic 的時候會感覺不太好,總覺得活得很 Fake(這是演哪一部?),上完課慢慢 real 了起來,有點像馬力歐跳關發現自己莫名其妙救到了公主,然後回去補劇情才發現原來公主根本是自己的青梅竹馬的概念。
接下來又是偶遇的後端工程師的故事了,總覺得要給他一個名子,不然總是叫他「咖啡店遇到的外國後端工程師」,而且一直叫人家外國人也蠻怪的(他老婆住在宜蘭的東澳,這樣算台灣人了吧),就稱呼他為 Brook 吧,事實上這也是他的名子啦。
Brook 他提到一個關於:怎麼樣成為一個有價值的工程師?。有時候我們會覺得工程師的價值就是 Coding 還有技術,不過不全然是這樣,除了生產力之外,還有很重要一點是要怎麼讓自己的老闆(金主、Shareholder)安心,也就是消除不安全感。他提到說很多 CTO 不太懂得表達,技術的確是強到沒朋友沒錯(搞不好是真的沒朋友),但是沒辦法向普通人表達這些技術的價值在哪裡。
當沒辦法表達這些技術的價值,老闆就不知道你在幹嘛,不知道為什麼你要花一個月的時間然後介面跟一開始完全沒有差別。能夠好好的解釋技術的價值,甚至用白話文去解釋技術本身能夠讓自己的金主安心很多。有時候會覺得說為什麼要和這些麻瓜解釋那麼多,反正到時作給老闆看不就好了。但是忽略一點是,對這些金主而言,技術是未知的,而未知會產生恐懼以及不安,不安就會帶來胡思亂想,當老闆發現說他一個月花了 40k 聘請你可是每次經過你的辦公桌時都發現你在看影片(即使你可能在看 Huli 的教學 與公司技術相關的內容),想想老闆作何感想?而解釋技術本身就能夠解決這些未知。
除了生產力,跟表達及解釋的能力,Brook 另一個很有趣的是改變氣氛的能力,工程師可能比較木訥,一個開朗的人可以帶給團隊比較活潑的氣氛,讓工作的氛圍不會死氣沉沉的;就像之前會去圖書館跟課(免費的冷氣),但是圖書館真的太安靜太容易睡覺了,現在改去咖啡廳雖然比較吵,但整個氣氛比較不會那麼沉重,反而每天的進度比之前更好(還有一個原因是在咖啡廳睡覺覺得太恥了...)。而且活潑的氣氛多少可以避免團隊成員之間的猜忌還有摩擦,讓整個團隊互相更加開放。看起來好像沒啥,但是其實能大大的提升團隊的生產力,也不是說每個人都要成為這樣的人,但是團隊如果有這樣的人物可以讓整個團隊運作更加順利。
竟然有了主角的名子了,該不會要連載了吧今天打太長了,明天再繼續好了
突然有點怕自己以後不會接觸新的技術 現在都會接觸新的東西 不過之後不知道還有沒有這股熱忱勒
今天狀況一個急轉直下...
每個禮拜總會有個幾天有點懶惰,今天可能就是那一天吧。
昨天看了 Huli 的直播,講到說前端工程師的優點是什麼,有一點我覺得可能比想像的還要來的有價值:薪資會跟著能力成長。。工程師(這裡指網頁工程師,其他不知道)這份工作(如果是工程師創業就另當別論)覺得其他產業相比,算是比較不需要伯樂還有運氣的一種吧,雖然同樣也會碰到天花板,但是對台灣大部分工作而言算是蠻高了,其實蠻想做個調查說,當初想要踏入前端這領域有多少人主要是因為經濟因素XD(不過這樣問也是有點奇怪就是了,單純說因為 pay 好就踏進來不太可能吧)。
又是 Brook 的時間了。之前有提到說 Brook 本身曾經在新加坡創業過,所以對創業也有自己的一些看法。他提到說:產品應該專注於少數幾項主要的功能。當他提到這個我腦中第一個浮現的就是 IG 了,說穿了,IG 主要功能也就是分享照片文字,還有限時動態這兩個而已(IG TV 也是一個拉,不過不知道使用度高不高),但是卻有超高的黏著度。
為什麼應該專注於少數幾個功能的原因有兩個面向,第一個是現在的行動裝置使用習慣就是一個功能一個 APP,即使你的公司有很多個服務,那也應該拆成不同的 APP 來做。像是 GOOGLE 算是最明顯的例子了吧?講到這個自己稍微思考一下自己的使用習慣。Android 以及 ios 找所有 app 的方式不太一樣,ios 直接放在桌面,但是 Android 就需要執行一次操作後才能呼叫全部的 app(看實際 os 的不同,可能是上滑或點擊之類的,不過也有和 ios 一樣放在桌面的)。但是不管哪一個,在操作 所有 app 的頁面時,我們都會下意識地把他看成是一個工具箱,而且我們會期待說工具箱裡面的東西是一個一個的工具:而且每個工具就只有一個功能。就像螺絲起子就是轉螺絲,而且一字螺絲起子就是轉一字的螺絲,所以我們在工具箱裡面會放很多把工具來因應不同的需求 —— 縱使有很多不同的羅賴把,很多不同的板手、很多不同的篇幾,但這些工具都只有一個特定的功能。如果有一把很多功能的工具會怎麼樣?就像瑞士刀?想想好像就不會放在工具箱裡面。
這好像跟UX 比較有關係,我們會下意識地把 app 看成是一個工具,並期待他能解決特定的需求,而並不是像是瑞士刀一樣,不管甚麼情形掏出來就可以解決。雖然不知道為什麼會導致使用者這樣的心理模型,不過也因為這樣,在設計 app 功能的時應該少數主要功能為主。工程師的思維真的跟常人不一樣,擁有技術卻不懂使用者真的會一不小心就設計出古靈精怪槍(奇怪的使用方式)或者是要你命 3000(各種功能集合一塊真方便)。
另外一個原因明天在說好了ㄏㄏ
今天一直在思考 Promise
還有非同步的本質,非同步的本質很簡單,就是避免卡在一些需要等待的事情(像是發 request 後收 Response),所以先預先安排好規劃,等處理完後時候就照著原本的的規劃走。但是後來我們發現說,非同步常常需要攜帶著資料,而且這些處理的事項有成功以及失敗兩種狀況,所以要安排成功的狀況以及失敗的狀況。上面的功能整理一下大概是這樣
看完上面之後來看一下通常的 Promise 會長怎樣
new Promise((resolve, reject) => {
// 執行需要等待的程序
if (rejectCondition) { // 定義成功以及失敗
reject(error) // 用 reject(error) 把這個 Promise 設定成失敗,error 是要傳遞的錯誤訊息
}
resolve(result) // 用 resilve(result) 把這個 Promise 設定成失敗,result 是要傳遞的資料
}).then(
result => { // 成功傳過來的資料
// 執行成功的對應操作
}, error => { // 失敗傳過來的錯誤訊息
// 執行錯誤的對應操作
})
大概是這樣吧,但是覺得想上面那樣一定超級難理解,想要想個方法好好解釋這點,會想說要直接講核心的觀念還是用比喻的會比較好理解,就這樣今天打了一長串又刪掉一長串,然後就抵銷了。
我覺得難理解的點有幾個,一個是從 request 的兩種不同方式:XHR 到 Promise 轉換並不會很困難,難理解的是 Promise 裡面到底幹了啥,因為這兩個 API 把 "執行需要等待的程序", "定義成功以及失敗", "傳遞資料" 這三件事情檯面下都做好了,導致說回來理解 Promise 不知道在幹嘛,而且如果說要提 Promise 的狀態,從非同步的本質上來看,其實成功與失敗是因應與 server 溝通的產物,和非同步本身我覺得沒有太大的關係(發下豪語!但是不太確定理解有沒有錯)。
再來是 then 本身 return 的東西為什麼可以繼續接下去也讓人蠻困擾的,要知道說傳遞甚麼樣的值會 return 甚麼狀態的 Promise。最後是 Catch 這個東西。如果說 then 是做出兩條路可以讓你走(then 有第二個參數可以放進去 error Promise 的 handler) ,catch 就是一個大臉盆,只要 Promise chain 有什麼錯誤就會全部接著,所以才通常會接最後面。
Promise 我會覺得就像是一個 T 字型的水管,但是我們可以決定說要往上還是往下。then 就是幫往上和往下接水管
至於 Promise.resolve() 跟 Promise.reject() 就是直接給你一個已經 resolve/reject 好的 Promise。
應該是這樣吧,不知道有沒有理解錯,今天想的有點累就沒有 Brook 的聊天內容了QQ
跟 Brook 聊到一件事情覺得蠻酷的,因為他本身有 app 的創業經驗,所以在聊到 app 時候他提到說:如果要做 APP 的服務,他會選擇聘請一個 android 的工程師和一位 ios 的工程師,而不是聘請會使用像是 reactNative 或者是 Flutter 這類的東西(應該就是指一些 app 的雙平台框架吧?)。
原因是 Java 或者是 swift 是直接操作 android 或者是 ios 的 API ,但是 reactNative, Flutter 這類的東西則是透過編譯轉成 Java 或者是 swift 來操作的(不過實際我不是很清楚就是了),這樣會有兩個問題,第一個是速度,其實我沒有很清楚這方面的事情,不知道說這些可以雙平台框架背後最後是被轉成各個平台的語言,還是依然運用原本的框架,但是最後使用轉化過的 API。如果是前者的話效能應該不是太大的問題吧?就只是開發過程的語言不一樣,還有 build 的時候可能會花時間。但是如果是後者的話效能可能就會大大降低。
除了速度之外,還有框架的維護問題,應該說這才是主要原因,如果 ios 或 android 更新,但是框架卻沒有更新,如果用戶更新到了最新版本,但是框架卻沒有更新,用戶就會出問題,開發也會出問題。這的確是蠻嚴重的,框架的更新不太可能馬上跟上系統的版本更新,一定要經過一段時間才有辦法,然後每次有更新,部分的使用者還是會選擇新的版本,這就可能造成一些使用框架開發的 APP 沒辦法支援。後面還有聊到 hybird app 跟 native app 的問題,不知道說現在 hybird app 的狀況怎麼樣?自己是不太常用,最有名的就是 notion 吧, notion 的 native app 真的是慘不忍睹,但是 hybird app 做的蠻好的。不過自己用 hybird app 還是不太習慣... 目前好像只有 chrome 才支持 hybird app?自己手機上就不是用 chrome ,每次操作起來就有點麻煩就是。
Big guy is John,已經忘記跟 Brook 的聊天是第幾篇了XD
不對阿...異世界第15 關在晚上 12 點至 1 點是不是沒辦法解阿...
還蠻期待下禮拜 week14 的,可以跟朋友炫耀的時刻終於到拉拉拉拉。
看到這週的隨意聊才發現到說:啊,原來課程過一半了。自己也跟課跟了第三個月多一點點了呢,時間也真的是過得挺快的。有時候會想到課程的建議,不過事後會想到說:不對,自己是已經有些基礎的人。重新這樣想過之後就覺得提出來的建議好像不太 OK,設計不適用自己但是卻比較適合原本這個課程的目標-初次接觸程式的人。
雖然還沒上完課程,不過如果形容一下未來那個跟完課程的自己,應該會說:
自己不是甚麼都會,但對於學習需要的內容有一定的自信
幹,剛剛有一隻他媽的 30 公分長的蜈蚣從我旁邊爬過。嚇到想不出東西了,手還在抖。
本週進度
個人進度
可以的話把 re: 的測驗做完...
作業