Yang Yang

你懂製程嗎？不不不…我懂CSS啦！！寫網頁的人，怎麼可以不懂CSS呢？什麼？你不懂CSS？下面一位～（Ｘ這次來跟大家分享的是，CSS從古至今的演化，儘管很多近代大家常用的技術，在早期其實很多人都已經提出來了。但是有價值的技術需要在適當的時機才能發揮它最大的價值。以下就來帶大家介紹分享一些CSS的知識吧！ 石器時期的CSS CSS reset在早期的CSS2.0的時期，Eric Meyer釋出了一個CSS Reset解決了不同瀏覽器擁有各自預設CSS樣式的問題。這是一個很簡短的CSS，但是初始化了大部分開發常用的tags。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748/* http://meyerweb.com/eric/tools/css/reset/ v2.0 | 20110126 License: none (public domain)*/html, body, div, span, applet, object, iframe,h1, h2 ...

最近拿Pixel手機去便利商店使用google pay之後，就發生開機鍵有事沒事就被按的狀況，之後一直瘋狂的重開機，去網路上查發現似乎很多人都有這樣的問題，最後找到方法解決了！ 我試過的方法發生事情後，我去網路上查資料，發現目前現有的資料都無法解決我的問題，包含進去安全模式, 手動關機, 手動重開機……。目前只要是中文的文章都無法解決，原本想說等電池用完再說，但是真的要很久的時候，於是繼續查資料。最後我是在國外的論壇查到別人分享的方法。 解決方法你只需要使用開機鍵，而且需要有節奏的按按鈕。請記住這個節奏： 按～ 按～ 等一下… 按～ 按～ 等一下… ……一直這樣無限循環的按，最後你會發現螢幕不會重開機了，停留在一開始的開機畫面等待輸入PIN。終於修好了～原本想說是不是要買新手機了，根本就還沒備份就遇到這種事 來看外國人怎麼說在此分享別人的分析，如果你想知道原因的話：Long story short, if your Pixel is stuck in a constant reboot then it looks like a possible cause is the pin on ...

可能很多人都會有過努力做一件事情的經歷，努力拼命去做一件事情絕對會有收穫的，但是為什麼同樣跟別人一樣努力，卻會得到不一樣的結果呢？以下就來跟大家談一下吧 努力並沒有錯大家時常會聽到努力是很重要的，但是並不是每個人努力過後，都能得到滿意的結果。你是否曾經這樣呢？甚至是努力到最後還是看不到結果，於是放棄了。努力並沒有錯，而是你所使用的方法不適合你。 過程的重要性大於結果有時候你看到身邊的人，怎麼幾乎不用做什麼事情就馬上一點就會了，可是自己再怎麼看就是不會。儘管你去請教了你認為厲害的人問題，但是對自己卻沒什麼幫助，因為你只是知道答案（結果），而不是方法（過程）為什麼有些人在成績上總是特別突出，但是在實際應用上卻總是無法突顯自己的能力？這就是重視結果大於過程的side effects。 情境故事舉例大家常態認為拿高薪才是人生勝利組。咖啡剛畢業進了百萬年薪的企業賺錢，但是做幾年後發現沒興趣想轉換跑道。奶茶年薪普普，知道自己未來就是想當一位設計師而努力充實自己。幾年過後，奶茶的作品出名且不斷的有很多通告。咖啡後來才發現，你努力擠進大企業不是自己真正的人生目標，人生還有更多值得去探索的，錢再多也換不 ...

大家在設計網頁的時候，時常會遇到一些時常忽略的問題，例如明明更新了值，網頁的畫面卻沒有改變。如果你遇到了這個問題，那麼你可能忽略了Immutable的重要性了。 認識ImmutableImmutable在OOP的design pattern中，時不時會提出來講，儘管嚴格來說，Immutable不算是設計樣式的一種，但是設計程式的好壞，往往影響程式涉及很廣的層面，以下就來認識吧。 為什麼需要它Immutable的設計概念，可以讓開發者更容易掌握資料。有時候程式語言的特性和蜜糖，讓開發者太仰賴其中的滋味，而讓程式碼變得越來越髒。例如：call by reference可以讓開發者經由傳遞指定的位置，直接修改內容。但是問題來了，你要怎麼掌握你的資料是舊的還是新的，已經更新過了呢？ 迷：資料再拿出來看就好了呀！ 可以這樣做沒錯，可是你要怎麼確定，就是這筆？時間點？ 迷：放個戳記就好了呀！ 每個Object都要放？不是瘋了嗎？ 因此，Immutable就出來了 特點在記憶體中，變數宣告之後，會賦予一個空間reference給變數我們無法馬上得知變數是否已經更動，但是我們卻可以馬上知道這個 ...

自從讀了研究所之後，就很少有機會可以到海線去回味了，這個月難得回母校參與講座，TED系列演講以前學生時期影響過我不少人生觀，知道母校最近有TEDx之後蠻開心，我還記得當時是幾年之前，那時候好像還在籌備中，後來開始舉辦了第一場TEDx演講，只可惜那時候我和預定的活動撞到，無法順利騰出時間出來聽，今年得知有新的主題之後，當然心想，我這次一定要請假參加！ 演講主題這次演講主題是起義 - Uprising，以下看官方的解釋： 122020年TEDxProvidenceUniversity以「起義」（Uprising）為年會主題與關鍵願景，「起義」是變革與更新的行動實踐，是這個不夠完美世界中的浪漫詩篇，總是可以為人們帶來正向的力量與堅持的勇氣。 其實參加完這個活動，我覺得起義會因為每個人的不同而有各自的解讀方式，我個人認為起義最好的解讀方式就是“全新的開始”。怎麼說呢？每個人的經歷都有好有壞。儘管很多人喜歡在大眾面前打扮得光鮮亮麗，但是只有自己最清楚那個多麽脆弱甚至遍體鱗傷的自己。每個人生活的經歷都不是那麼的完美，但是卻也創造與眾不同的自己。 議程 印象深刻的講者上半場講者 - 雷娜最有印象的 ...

在設計程式的時候，相信各位或多或少會突然寫出一些有點髒的程式碼，有時候是不經意的，有時候是一時想不出方法，不得已寫出的程式碼，這篇文章將會介紹兩個簡單的開發準則，讓各位在開發的時候可以避免寫出一些日後不易閱讀的程式碼。 認識DRY讓我們先來了解什麼是DRY，DRY分別是三個英文字的縮寫：Don’t Repeat Yourself 原因為什麼要避免重複的程式碼出現呢？ 重複的程式碼會讓整個scope變得很龐大 撰寫重複的程式碼，會消耗工程師較多的時間（時間成本） 重複量大的程式不易於日後閱讀與維護 優點 節省時間與精力 日後易於維護 減少Bug發生的可能性 認識KISS原則KISS原則代表的意思為：Keep It Simple and Stupid基本上的意思為，讓程式碼簡單, 清楚與容易理解。這個原則有點開發者體驗導向(Development Experience)，你可以想像一般人的記憶可能不會花太多時間在一坨程式碼上，而且人是有點惰性的生物，面對不易閱讀的東西，當然會懶得去看。 原則 每一個功能盡量不要撰寫過多的行數 每個方法只能解決一個小功能（Divide and Conq ...

無論是說話或是設計程式，都需要注意邏輯不能馬上定義得太明白，往後需要變更或是維護的時候才會比較方便。 定義讓我們看一下原文的定義： 12High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. 翻譯蒟蒻 高階模組不可以依賴於低階模組，兩者必須依賴抽象概念上。 抽象不可以依賴細節上，而是反過來依賴抽象上。 看完之後，你可能還會覺得這在說什麼…其實這個概念跟我們日常生活很像，你跟別人約定好的事情不能講太細節的事情不然到時候有什麼狀況發生，其實很難去應變 日常舉例今天如果老師跟你說：下次考試會考課本的第一章全部和第二章的第三小節結果下次考試老師跟大家說：不好意思…我忘記把題目加在裡面了，今天就先只考第一章。 你 ...

在設計功能的時候，有時候要注意這個功能到底適不適合在這個元件擁有，以下就來看看簡單的範例。 定義簡單來說就是，把不同功能的功能從介面中分離出來。 範例這裡有一個形狀的介面： 1234interface Shape { area(): number; radius(): number;} 眼尖的你有沒有發現radius放在Shape是一件很奇怪的事情呢？為什麼形狀會有半徑？頂多只有邊長才對，半徑的特性應該是圓才對。所以這邊必須要抽離出來： 12345678interface Shape { render(): void; area(): number;}interface Circle extends Shape { radius(): number;} 結束了，沒錯，就是這樣而已，很簡單吧！ 應用於前端不管在開發網頁時，是使用OOP或是FP，其實都可以適用這個概念在建構網頁容器。你只需要保持注意，某些資訊是否是屬於這個元件，不該放的就不要放在這裡，抽離到其他元件去額外使用即可。

在設計元件的時候，有時候會遇到元件擴充或是退回版本等…問題，這個時候如果把原件的彈性變大，將會大大的增加工程效率，之前有大概介紹什麼是Liskov原則，這裡將會進一步舉例介紹。 定義Liskov替換原則的定義請看如下： 1Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. 很好，相信你看過之後，還是不知道他到底想表達什麼，讓我們白話一點詮釋他。 換句話說在設計物件的時候，你必須考量到彼此的共通性才會進一步的設計彼此的繼承關係。程式中的物件應該是可以在不改變程式正確性的前提下被它的子類所替換的。簡單來說就是：當子類別替換父類別時，功能不會受到影響。換句話也可以說是：子類別必須能取代它的父類別。繼承的特性使得類別具備高耦合的特性，子類別如果需要Overriding, Overloading 必須遵照父類別的規則，才能符合類別的設計原則。因為具備高耦合的關係，如果沒有特別注意 ...

這樣要來介紹的是開關原則，其實以字面上來說會有點讓人誤解其中的意思，個人認為有點像是積木或是拼圖疊加的概念，但是概念上也是很簡單，只要熟悉觀念即可變成自己的設計心法，讓我們來看看吧。 開關原則在OOP的設計中，開關原則需要保持開放程式的擴充性質，並且關閉程式的修改。聽起來好像很奇怪？那麼我們來舉例吧！如果今天你是設計汽車的工程師，當有人拿車子要給你修理輪胎的時候，你一定只會把輪胎更換而已，並不會動到其他東西，例如：引擎, 座椅……。只需要把指定的元件更換，而不需要動到過多的東西。 換句話說以OOP的設計原則來說，開關原則可以讓程式保持DRY（Don’t Repeat Yourself） 實例展示讓我們來看以下的例子，我有一個訂單，裡面包含了飲品： 1234567891011App = () => { const drink = { name: 'milk', size: 1000, } return ( <div className="App"> <Order ...