令人煩躁的 Context-Switch

心理學家發現一種「高度專心高生產力」的心智狀態,稱之為「心流」(Flow)。進入心流的狀態,需要約十五分鐘的時間,所以每一次的注意力轉移,都需要耗費「超過十五分鐘」才能回到之前的狀態。

Photo by Beth Jnr on Unsplash

「心流」(flow),如果用電腦的角度來比喻,就像 CPU進行 Context-Switch時的 Overhead。Context-Switch是一個儲存和重建 CPU的狀態,讓多個 Process可以分享單一 CPU 的過程。用在人身上去解讀,就是一心多用!

這也是為何大多的程式設計師,很難在白天上班時有「相對」高的生產力,而是選擇在晚上(或下班)寫程式。生活中,有許多大大小小的例行與非例行的事項,占據我們一天中大多數的時間,可能是一通廣告電話、一場沒有結論的無聊會議、甚至一句沒有意義的寒暄都或多或少都會讓你當下的工作產能降低。這些雜事會讓你放下正在進行的工作,而被中斷之後,要花很多時間重新再把破碎的思緒連接起來。

這種狀況,就像是電腦中的常駐程式,會中斷我們正在使用的重要程式、強占記憶體、跳出訊息,甚至讓電腦運作速度突然變得特別緩慢。這時候打開「工作管理員」(Task Manager)檢查許多莫名其妙的「常駐程式」同時在執行(更可能是中毒!)

因此,程式設計師並不是因為喜歡加班,而是在下班時間或晚上的干擾比白天少很多,所以相對產能比較高!所以下班後工作,是要盡可能將亂七八糟的事情摒除外,進一步創造能「專注」的環境,讓自己進入心流階段!

在 WFH的時候,Context-Switch的成本更加明顯,除了原本工作上的干擾外,又多了家庭上的紛擾。舉例來說,原本工作上只有五顆球在處理,WFH的時候,變成七、八顆球在亂,最後勉強接個幾個,到甚至一顆都接不住...,更慘的是球還會拚命一直來。

疫情尚未受到控制的當下,不管是在工作環境,還是個人的學習上,大部分的時間都會在固定的地方(客廳、書房、餐桌上),只能全面檢視一天中有哪些 Context-Switch,然後盡量避免。(如果我有找到好方法的話...)

在找到方法前,可以先:

下雨的迷思

「那一天,人類終於回想起曾經一度被下雨所支配的恐怖,還有囚禁於風雨中的那份屈辱...」

Photo by Rhendi Rukmana on Unsplash

自己每逢洗車後必下雨的神跡,屢屢應驗,但真的是如此嗎?首先,下雨是機率問題,台灣是個多雨的島嶼,不論春夏秋冬,每一個季節都一定或多或少有降雨機率(除了雨都基隆有超過 50%這種可怕機遇),實際上洗車後沒下雨的次數應是佔了多數,只是自己並不會特別注意好天氣,而是特別留意下雨的時節,於是就在潛意識烙下了「一洗車,就下雨」這種刻板印象。(還是我真是龍王轉世,冥冥之中似有神力!)

但,9.99999%的人們心裡還是有個疑問​:下雨天洗車真的是「白費功夫」嗎?

依照現在科學的說法,下雨天確實的洗車打蠟或是鍍膜,才是車漆隔絕雨水、杜絕髒污的好方式。

雨水中夾帶著灰塵與髒汙,尤其是車輛排氣中的硫化物氮化物,甚至是空氣中的落塵,遇水形成酸性物質。隨著下雨,上述的各類型髒污顆粒會停留在車漆上,逐漸造成水垢、水斑、水痕、乳牛斑等等問題,不僅顯髒而且難以清除,當然還會進一步侵蝕傷害車漆。

這也就是為何愛車的人為何都要經常性打蠟、鍍膜,就是因為這樣做能幫車漆多一防護層,避免直接接觸酸性雨水或髒汙,並減少雨水黏在車漆表面。洗車、打蠟和鍍膜其實不難,如果鳥屎、蟲屍、水垢、工業落塵久久不理,未來的處理才是真正費工又傷荷包!

各位親愛的車奴們,勤打蠟、上鍍膜才是真正的愛車之道!

洗車、打蠟、鍍膜前,你還要:

令人意外的 Derrick Rose MVP 選票

2021年 NBA MVP票選,由金塊中鋒 Nikola Jokic獲得,亮點除了 Nikola Jokic是史上首位二輪選秀的 MVP得主。更令人意外的是,Derrick Rose竟拿到一張「第一名」選票!(與 Joel EmbiidGiannis Antetokounmpo並列)

Photo by LOGAN WEAVER on Unsplash

本來以為是某位極度欣賞 Derrick Rose的媒體人所投,畢竟今年 Derrick Rose從數據、戰績、甚至是對球隊貢獻、領導能力都是排不進聯盟前十的球員。(還是數據看錯年份?!拿到2010-2011年?)

但如此主觀的選票,其實是來自「球迷於官網線上加權累積投票」,並非媒體人投票。按 NBA票選規則,媒體佔一百張選票,而球迷投票結果則合計為一張選票

(自 2010年的 MVP票選,開放球迷可以參與票選活動;在球迷進行網路投票後,依照球員所得的票數高低,取前五名依序給予第一名到第五名的 MVP 選票一張,Derrick Rose便是因球迷投票獲得一張第一名選票。)

身為骨灰級球迷, 或許能窺看到那極度主觀且非理性所做出的票選心態。

看著 Derrick Rose從 2008年成為公牛隊選秀狀元,被期待成「那個人」的 The one,以二十二歲成為 NBA史上最年輕的 MVP,球技如他的綽號,他是「飆風玫瑰」,他是 Derrick Rose,在 23號退休後,準備要捧起那火炬的 The one。

2012年,那個令人沮喪的季後賽,首輪對七六人,Derrick Rose左膝十字韌帶撕裂(ACL),在這個傷勢後,Derrick Rose受無數的傷病所苦,全身上下,從膝半月板軟骨撕裂到腳踝扭傷都有!此時的 Derrick Rose已成為浪人,漂泊數支球隊,亦遲遲無法找回過往身手。

2018年,本以為會就此退休養老,高掛球鞋的 Derrick Rose,和教頭 Tom Thibodeau重新團聚在明尼蘇達灰狼,10月31日在對戰猶他爵士,奪下生涯單場最高的 50分,外加漂亮的再見阻攻。似乎,那個  2010年的飆風玫瑰在賽場上又重新綻放!

Derrick Rose:「我已付出全心全力,我的隊友在賽前跟我說,就做自己就好,今晚真的很瘋狂。」

比賽結束那那一剎,灰狼所有隊員都衝上前擁抱他、主場球迷們更是激動高喊「MVP」!

今天的第一名選票,就是給那久未綻放的玫瑰充滿自信的一票,為他經歷了屈指難數的嚴重傷勢怒吼、替他那一年復一年不被擊敗的精神給予最後的掌聲!

(不禁幻想著:如果早幾年有有輪休的概念,是不是 Derrick Rose還會繼續為公牛打球;如果早一點學會安全落地的方式,是不是就不會遭遇十字韌帶撕裂;如果早一點開始投三方球...;如果不要堅持切那一球...;如果...)

你可能還會想回味:

用 Active Arcade一起健身

防疫在家不知所措?沒辦法出走?沒關係,來試試 Active Arcade居家運動互動 App。

Photo by Alora Griffiths on Unsplash

隨著疫情的變化,三級警戒無法解除,不能去健身房,體重直線上升!別再繼續躺在沙發上追劇吃洋芋片,快下載 Active Arcade,靠手機/平板前鏡頭,就可以做到基本的健身運動。

Active Arcade共有十九款遊戲可供選擇,但陸續還在增加中,也不是所有遊戲都適合在室內玩,但無傷大雅,大人小孩都一定會喜歡。每款的運動時間為三十秒至一分鐘,Active Arcade會告訴依照活動度計算消耗卡路里,搭配 Apple Watch使用會更精準。

雖然是全英文介面,但從遊戲預覽圖以及展示影片,大概就能知道這遊戲會要求做什麼動作。簡單來說,就是遊戲畫面中,會不斷出現各式各樣的形狀/數字/英文,要用「手」、「腳」、或做其他要求的動作來碰觸,進而獲得分數。

唯一的缺憾,大概就是目前只有 iOS版,Android版還要等等。

MacBook Pro螢幕出現殘影

在 WTF的 WFH一週後,在即將下班的傍晚,服役多年的 MacBook Pro螢幕居然出現殘影,到底是怎麼回事?尤其在 WWDC 2021隔天發生,是 Apple另類黑科技?(趁機推一波 M1?)

Photo by Moritz Kindler on Unsplash

推敲自己這一個禮拜的使用行為,心在淌血大抵心裏上有個譜。

所謂的出現殘影,其實是「螢幕烙印(Burn-In)」,會發生的根本原因,就是長期讓螢幕畫面顯示在同畫面(同一個顯示位置呈現同樣內容),以至於那區塊的像素發光區老化。

根據官方資料,Mac及 iMac系列產品所搭載的 Retina顯示器,是採用橫向電場效應(IPS,In-Plane Switching)技術。因為 IPS能提供直逼水平線(178°)的超廣視角,色彩還原性也很出色,但也伴隨著缺陷,其液晶分子反應速度較慢,在高速轉換的動態圖像中(如:影片、遊戲)容易拖影,長時間停留在某個高對比的畫面,顯示器切換後也容易出現殘影

檢視這個禮拜的 WFH,就會發現 WTF,自己常不自覺將 MacBook Pro顯示器停留在某個高對比畫面...(對,是自己呆)。過去在家工作時,多時間是將 MacBook Pro放在大腿上使用,不可能一直將螢幕維持在某個高對比的靜態影像。

現在 WFH,MacBook Pro是另外接螢幕、鍵盤、滑鼠出來,MacBook Pro顯示器直接放生,爾爾再加上觸控面板的手勢,所以螢幕是長時間開啟,而且維持桌面(在某個高對比的靜態影像),結果...你知道的...,就是這樣!

另外,MacBook Pro擺放位置也有問題,當初書房格局設計,是讓書桌正對著陽台,擺放在書桌上的 MacBook Pro螢幕(背光模組)就會直接被陽光照射,更容易讓整個螢幕面板發熱。

本來以為是長期使用(使用三年以上)造成的老化效果,沒想到竟然踩到螢幕烙印(Burn-In)這個雷。幸運的是,發現得早,關閉電腦,讓它在冷氣風口下休息一個小時後,螢幕悠然恢復原狀,真是可喜可賀!(之後只有使用外接螢幕,MacBook Pro螢幕就休養一陣子吧。)

補充:後來的折衷做法是採用鏡射方式,這樣螢幕能持續變化而且能爾爾搭配使用觸控面板。

列出資料夾內所有的檔案

原本覺得這個是一個不可思議的動作,在一般行政工作上,怎會有這樣系統般的需求呢?

Photo by Annie Spratt on Unsplash

仔細了解、推敲一下,這樣的工作狀況其實還真不少。比如是:從過去舊有系統拿到員工照片,想比對名冊,看哪些新舊員工照片有遺缺,更單純的是,製作一份資料夾的清單,加備註檔案說明。

職場上,不論合理與否,遇上了總是要面對。

在 Windows上,要做這樣的動作很簡單,就是在該資料夾內容上

  1. 全選檔案 
  2. 按住 Shift鍵不放,再按下滑鼠右鍵
  3. 選擇「複製為路徑」

如此一來,資料夾內所有檔案路徑就會被複製下來。之後,就可以貼上 Excel欄位,再用取代的方式清除不必要的路徑,留下檔案名稱即可。

Picrew.me日系似顏繪

因為那討厭的疫情,有愈來愈多人到了「虛擬」世界開會,早期沉寂的似顏繪,又因此開始熱絡了起來。

Photo by Tengyart on Unsplash

不論是使用 Google MeetZoomTeam等視訊軟體,除了不想讓人看到自己家裡骯髒凌亂不堪的樣子,甚至連大叔本人都不想露臉。如果你像我一樣,害羞內斂、被動、不喜歡拋頭露臉,那麼就從 Picrew.me這個日本網站找到適合你自己的頭像來取代大頭照吧!

畢竟日本人是比較貼近我們,由許多日本插畫家所設計的似顏繪產生器,可讓你自由變換,不論是可愛 Q版、搞笑無厘頭 Kuso,還是正經八百的頭像,應有盡有。(不過,因為是不同插畫家設計,每一款可以變換的項目也略有不同)

每一款似顏繪是能夠免費個人使用,但是否可商用,或是允許加工後製,則端看每個日本插畫家各自規範。你剛好想閉關,不想露出廬山真面目?快快來「Picrew.me」幫自己做個新的頭像!

開發人員應該避免的十個壞習慣

取自 Medium Brad Traversy,拍手數超過 8.5K,如果你是資深工程師一定會非常有感。

Photo by Alex Kotliarskyi on Unsplash

Every developer “develops” some bad habits throughout their career or even their learning experience. In this article we’ll take a look at some of the common bad habits that I have experienced myself and/or have seen over and over. My hope is that if your just starting out, you can avoid this stuff and if you are having these habits, your aware and you can start to work on changing them.

#1 Not Taking Enough Breaks (沒有足夠的休息)

So the first one, I’m sure many or all of you are guilty of. I’m still guilty of it and that’s not taking breaks or not taking enough breaks. I’ve had periods of time where I’ve sat down at 6am and maybe only got up for lunch around 1 and then gone until 6 or 7 at night, and this was common, almost every day. I've done much more ridiculous things when I was on a time crunch. I think we we all have had those rare occasions when we need something done the very next day, that is not really what I’m talking about, I’m talking about your everyday habits.

I would suggest that each day you try and take frequent breaks. I can’t say a specific plan for everyone cause everyone's different, but in a general sense I’d say around every hour get up and stretch your legs walk around, get a coffee, get something to eat. A lot of times, if your stuck and you take a break and come back to it the solution will come easier after giving your brain a rest. So figure out what works for you. Even if you don’t think you need breaks, just try it, you may find that your more productive.

#2 Refusing To Ask For Help (拒絕尋求幫助)

Number 2 applies to both learning and in the actual workplace. Many of us don’t ask for help. It could be for a number of reasons but I think a big one is pride and the fear of looking like you don’t know what your doing. Many of us have impostor syndrome where we don’t feel fully qualified in our positions. I’ve felt like this both in a company setting and dealing directly with clients. And even doing courses and tutorials. So asking for help just re-affirms that feeling. But in reality, its wasting a lot of time and hindering your growth. Other real developers are just as much of a resource as a video or book. I’d say even better than that stuff. They can directly answer your question and help you really understand it. The only people that would criticize you for asking for help would be a complete asshole and Id try to avoid those people anyway. If you don’t wanna ask for help because you want the experience of finding the answer on your own that’s fine, but give yourself a time limit. Don’t go days searching for a solution when you have peer right next to you that may know or can at least help you out

#3 When You Stop Being A Student (拒絕學習,停止成長)

I don’t care if you’ve been a senior developer for 20 years, you should always think of yourself as a student. More so than most professions because this one is always changing. No developer knows everything about anything. The minute they do, something changes and they still have to learn more. If you get complacent and you stop reading and learning, you'll fall behind. Even if you have a job that doesn't require you to learn anything new, like lets say you build the same type of projects with the same software, same version and everything, if you loose that job which is always a possibility, your gonna be way behind. So even with a job like that, id still suggest learning new stuff on the side. Stay up to date with whatever language, frameworks, libraries that your into. There are a lot of jobs like I just explained and its understandable because many team leaders at companies figure if it ain’t broke don’t fix it. So you still see teams using outdated and unsupported technologies because it seems to be working. If your learning new stuff on the side and you can show your team that its possible to make your projects faster and more efficient and easier, you may be able to sway them into updating their technology and bettering the company.

#4 Dirty Code (雜亂的程式)

This is more of a technical habit and this could be a lot of things. You want to write your code in a way where its visually clean, efficient and secure. This is really hard when your self taught because a lot of the times in tutorials and courses, your not learning the best way to do something because the instructor is trying to make it easy to understand the core concept. So you have to kind of do some extra research and figure out the best way possible to clean up your code. Id definitely suggest always using the DRY principle which is don’t repeat yourself. If you see common blocks of code, create some kind of class or function to consolidate that piece of functionality rather than just repeating it. It makes it much cleaner, saves a bunch of lines and its easier for others to work with. You also wanna pay attention to performance. Do things like compress images, minify JavaScript and CSS. You can use a task runner like gulp or many other tools to do this automatically or if its a small project you can even do it manually with something like minifier.org. Also don’t make unnecessary api calls, structure your full stack app in a way where you can make as little requests as possible and still get the functionality you need. Also testing..This is one I’m a huge culprit of. I don’t do enough testing. As much as I know things like unit testing helps build a more robust app and saves you on potential issues, I just frigging hate it. Its probably one of my worst habits and something I need to work on to be a better developer. Sometimes we cut corners to save time but in reality, were making the application less performant, less efficient, less readable and it will probably cause more of a headache in the future than if you just did it the right way do begin with. So try and keep that in mind.

#5 Bad Work/Life Balance (工作與生活無法平衡)

This is really important, especially if we have families at home and that’s work/life balance. Being a programmer of any kind takes up loads of time. There’s many reasons for this, things are always changing, we run into issues that can hold us up, we need to research and the list goes on. In turn, a lot of the time, we have to work late, work early, work on the weekends or all 3. This takes time away from everything else in your life including spending time with your loved ones as well as anything else you like to do. You may like sports, hiking, going out to eat, whatever it is, and if you’re constantly working you aren’t doing anything else that makes you happy. This is an area I have a lot of experience with. I have a wife and 2 kids, one with autism and I don’t spend the amount of time with them that I’d like to. I have kind of a double whammy because I have all of the issues of dealing with coding as well as the issues of a content creator and having to constantly come up with new ideas and recording and quality and so on. And if any of you guys are freelancers and work for yourself, you know your livelihood depends on getting work done. You only get paid if your getting shit done. As rewarding as working for yourself can be, it’s a constant worry about keeping up and getting things done. It’s really easy to fall off and I think that weighs on us and pushes other things out of our lives. Not to say that people that work for companies don’t go through this but its a whole new level when everything falls on you. So I really empathize with those of you that have your own businesses. But even with that said, you can’t let it control your life. You have to make time for your family and friends and quite frankly, for yourself. Life shouldn’t be just about writing lines of code. Do things you enjoy that bring a good balance to your life.

#6 Bad Office Politics (糟糕的工作氛圍)

This next one is for those of you working at a company. You work with other people which in turn can cause conflict, disagreement, arguments and so on. Many developers are arrogant and always wanna be right. Even if they know they made a mistake and they’re wrong, some of them would never admit it. I’m not saying that’s most developers but I think we’ve all met at least one of these guys. I hear from a lot of people that their team is great and they all get along and that’s really good but it’s not always the case. Many times you’re gonna clash on ideas and solutions. Try and be diplomatic and respectful but at the same time, don’t be a pushover, especially if you feel strong about whatever it is you’re proposing. Don’t resort to yelling or name calling or any of that. It doesn’t get you anywhere. If they start doing that to you, just walk away and be the bigger person. Unfortunately, if you have someone on your team that is just a complete dick and won’t listen to reason, there’s really nothing you can do aside from try to avoid them. There may be some cases where you have to talk to someone that is higher up. I would always suggest talking to the person first though.

#7 Not Learning From Mistakes (不能從錯誤中學習)

So being a developer, you’re going to make a ton of mistakes. It’s inevitable and there’s nothing wrong with that. There is a problem if you keep making the same mistakes and you don’t learn from them. The process I would suggest when you make a mistake is to figure out what the ultimate cause of the mistake was, figure out if there could a process be put in place to prevent it from happening again and then figure out if the mistake had been found sooner could you have prevented the consequences? If you think about these 3 things when you make a fairly big mistake, chances are it won’t happen again or at least you’ll catch it sooner. Also, don’t be too hard on yourself for making mistakes. It happens to the best of us.

#8 Giving Up Too Soon (放棄不是一種超能力)

Frustration is a huge part of programming. I’ve made a couple videos on frustration and dealing with some of the issues that arise in both projects and learning. I’ve seen many people give up too soon in both specific projects and on programming in general due to frustration. Some projects are really difficult and it seems once you fix something it causes another thing to break and it just keeps happening. You may start to think you’re in over your head, you could be doing something else, you’re loosing money and many other negative thoughts. If you give up to soon though and you scrap the project or you quit your job, then everything you put into that project or job was for nothing. I’m not saying there aren’t projects that should be given up on but I’ve seen it many times where people have given up and from an outsiders point of view I could tell if they stuck with it for just a little longer, it probably would have been successful. So before you give up on anything, make sure you’ve exhausted all routes. You've searched up and down, asked for help, started over trying something different, maybe using a different technology, taken a long break to get your thoughts back in order, maybe even putting it to the side for a bit if possible. You want to do absolutely everything you can before quitting. If you still are failing, then maybe it is time to move on, but all avenues should be taken before that happens. Success could be right around the corner and it would be a shame if you gave up just before that turn.

#9 Being A Know It All (當一個什麼都懂的人)

So I talked a little about arrogant developers earlier and I think what makes many of them arrogant is that they think they know it all. They don’t listen to other developers because why would they, they already have all the answers. Being this way sucks for the people that are around you and it also hurts yourself because if you think you know it all, your not actively learning more and bettering yourself and I guarantee you’ll have a horrible wake up call someday when something goes really wrong because you failed to listen to anyone else and or do your research. Most of these guys are the trolls on Stack Overflow that will make fun of a new developer asking a question or make fun of someone else’s answer, down voting every chance they get. I have a deep annoyance for these people. I think many of them got picked on in school and they use their knowledge to now pick on other developers that may be having issues or aren’t getting something. They seem to forget how it felt for them to be picked on and want revenge. I could be wrong but that’s my theory. Regardless of why they do it, I think that if they were more open minded and welcomed in the ideas of others and respected others, they would be much happier than just always trying to be right. They could be the smartest person on a team but also the worst person on the team, because nobody wants to work with them and there’s no good communication going on. For a team to be successful, there needs to be communication and unity and being a know it all, just destroys that. So if this is you, try and take the stick out of your ass and be a bit more open minded and more respectful, you’ll go further in life.

#10 Not Taking Constructive Criticism (不接受建設性批評)

Ok, so number 10 is sort of related to the last one and it’s not being able to take constructive criticism. There’s a big difference between a know it all troll and someone that is genuinely trying to help you. Sometimes it’s hard to see the difference because having someone point something out to you that you did wrong or you could’ve done better, doesn’t feel good and may feel like an attack but a lot of the time it’s not, it’s just someone that is showing you a better way or just sharing an opinion. It took me a while as a content creator to figure out the difference of who is trolling and who is helping. At first I found myself being defensive to anyone that said anything about how I did something. But I realized that many of these people are legitimately just trying to help. If they aren’t being disrespectful or just nit picky over something that doesn’t really matter and is just preference, then I need to take it as something that can benefit me and my knowledge on whatever it is. Constructive criticism is a fantastic resource for learning, and the reason for that is because it’s targeted. It’s something that you are directly having issues with and someone is offering a specific solution. That’s invaluable. In fact code reviews are great because you get other peoples suggestions and influence on your code and how you can improve it and better yourself. So don’t take things personal unless you are actually being attacked or intentionally made fun of and disrespected. It’s hard to hear that you were wrong or you could do better but ultimately it’s going to make you a better developer.

I hope this advice helps some of you who are both new to development as well as seasoned developers.

如果你已經有了超果三年的工作經驗或,或又待過幾間公司,那麼這十點你應該會有更有感覺。EAA SERIES有依照其理解把文章的重點稍作翻譯加上心得,若不想練習英文就看看 EAA SERIES版本。

十點中最有感的,莫過於「拒絕尋求幫助」、「糟糕的工作氛圍」這兩項。

「拒絕尋求幫助」是我自己個人最大的問題之一,遇到問題時,自己幾乎都不會去尋求幫助。多半是因為自尊心作祟、或是怕問了別人,會被誤以為什麼都不會。總之,就是想太多。這篇文章說得很好,一樣是去自己找答案,但要設定一個時限,時間到了就快去找出口!

「糟糕的工作氛圍」是現在另一個問題,雖然我想好好保持團隊氣氛,持續的良好溝通與交流,但企業文化有時壓得我喘不過氣。

如果是新鮮人,見到上述十點可能有些會嗤之以鼻,但至少可先看看,有哪些壞工作習慣是可以避免的。

如果是資歷深、待過幾間公司(體驗過不同公司文化)的職場老鳥,你會對這十點有更深刻的理解!

如果你想再多了解一點:

拒絕公式

我自己是一個不擅於拒絕別人的,婉拒他人都會讓我有罪惡感。另一方面,也會覺得「拒絕會容易產生摩擦,面對衝突實在很難!」

Unsplash:Coffee Image

今天看到來自書籍最高學以致用法的「拒絕公式」,希望透過公式,幫助自己降低罪惡感,避免衝突地拒絕對方。在這裡,拒絕公式指的是「道歉(感謝)+理由+拒絕+替代方法

舉例來說:假設今天下班前,被主管留下要求加班,或許可以試著這麼說:

『真的很抱歉(道歉),謝謝你如此肯定我,讓我有機會一展長才(感謝)

不過,今天我得接送孩子去補習班(理由),所以沒辦法留下來加班(拒絕)

看起來有點難度,但是我會在家先思考好做法,隔天應該可以在中午之前完成,這樣的話可以嗎?(替代方法)』

通過『道歉(感謝)+理由+拒絕+替代方法』這樣有一天也許會發現,練習拒絕並不壞。相反地,正因為有界限,別人才會覺得「我」值得被尊重。

你還可以進一步試著:

Reverse Proxy Server 應用

通常,大家都使用過代理伺服器(Proxy Server),基本上是讓 Client端存取網路時,透過 Proxy Server來降低網路頻寬消耗,更進階的,則是管制網路流量,進而提供分析報表。

Photo by Nikita rud on Unsplash

前陣子在工作上,遇到一個較少接觸的應用服務,但其實也不算新東西。這個應用與 Proxy Server有類似的功能,只是與 Proxy Server的功能剛好為反向,有點像 ARPRARP的關係,這個服務名稱叫反向代理伺服器(Reverse Proxy Server)。

Proxy Server的應用是一般很常見的做法,而 Reverse Proxy Server則是在資安問題頻傳時,企業最常搭配使用的架構。

企業的主機服務採用二階層模式,實際的主機配置內部 IP(TRUST區),而主機前端對應建置一台或多台的 Reverse Proxy Server在 DMZ區。當外部使用者連到主機時,是利用 Reverse Proxy Server做為呈現的代理主機,因此 Client是不能直接連到內部主機。

如果用一般地情境來解釋的話:
  • 代理:老爸(Client)之前欠銀行錢,半毛都沒有還,所以沒辦法再跟銀行(Server)貸款。但是家中急需用錢呀!於是老爸跟女兒(Proxy)借了身份證、印章與法定代理人文件來貸款。銀行只知道錢借給信用紀錄良好的女兒,而不知道實際上拿到錢的那個沒還錢的老爸。
  • 反向代理:DHL每天都會有成千上百個人去寄貨,但寄貨者(Client)只知道他跟 DHL窗口接洽(Reverse Proxy),卻不知道是 DHL的哪位員工看到了他的寄件單並且去做後續處理,而寄貨者(Client)實際上也不在乎是誰看到他的,只要貨有順利寄出就好。
總結:「代理隐藏真實 Client,反向代理隱藏真實 Server

現今,網路應用設備更廣泛,再加上網路設備的逐漸平價化,有些企業會採用負載平衡設備( Load Balance Device)來取代Reverse Proxy Server,也可以利用 NAT方式將主機隱藏於該設備之後。(甚至可以做入侵防範與網路辨識來源的功能)

此外,你還會想要去了解:

Google Meet視訊背景更換

隨著疫情的惡化,幾乎都是待在家裡。幸運的是,還是要正常上班(WFH)/上課。像我會因為工作需求,每週固定在家開會,若是開視訊的時候,房間整個亂七八糟(或是有不該出現的東西?!),真是蠻尷尬的!(雖然說我開視訊的機會不高)

のび太の部屋

不過,現在有很多視訊軟體都可以更換「虛擬背景」,稍微「調整」原本家裡的樣子。

比如是:知名的瑞典品牌 IKEA,它推出多款虛擬背景,提供各種住家空間情境(書櫃牆、鄉村風客廳、工業風書房)下載,用這樣的方式來無痛裝潢,也是一種小確幸呢!(每天住新家的意思?!)

除了 IKEA,其實像是吉卜力工作室迪士尼皮克斯寶可夢 Pokemon甚至是霍格華滋魔法學院等等各式各樣單位,都有虛擬背景圖可以下載,而我,則是最喜歡「哆啦A夢」那熟悉的大雄房間(のび太の部屋)。

在疫情穩定之前,快選一個喜歡的背景當作自己的家吧!(或是學學紙板工藝創作者 @kenpon_g自己做一個)

你還會需要了解:

「專業」就是連麻瓜都聽得懂的話術

 『 麻瓜 (英語:Muggle),在J·K·羅琳的《哈利波特》系列小說及電影中是泛指沒有任何魔法能力的人,也不是出生於魔法家庭的人。麻瓜也可以被描述為體內沒有任何魔法血統的人。』 Photo by Vitolda Klein on Unsplash 「你不是工程師,我很難跟你...

最近三十天熱門文章