星期二, 2月 11, 2020

Firebase functions 裡用 Admin SDK 時,怎麼去把設定跟程式切開?

一般來說,照文件來做,會要放兩個設定,第一個是 Service account credential,第二個是 Firebase config。
但其實在部署 functions 上去以後,這些設定都已經在執行環境裡了,所以不需要特別去放這些設定。而且,把這些設定放到程式裡,那程式會上到 git repository 啊,這樣設定就都曝光了。那不想把這些設定放到程式裡,本地端又要開發時該怎麼辦呢?我是找到這篇:Firebase: Separating configuration from code in Admin SDK
第一個,Service account credential 在下載以後,假設放到 /credentials/your_service_account.json,那麼在執行前,把這檔案路徑指定到 GOOGLE_APPLICATION_CREDENTIALS 這環境變數就可以,例如:
export GOOGLE_APPLICATION_CREDENTIALS=/credentials/your_servcice_account.json
第二個是 Firebase config,從 firebase console 取得以後,假設放到 /config/your_project_config.json ,裡面內容大致是
{
   apiKey: "your_api_key",
   authDomain: "your_project.firebaseapp.com",
   databaseURL: "https://your_project.firebaseio.com",
   projectId: "your_project-abcdef",
   storageBucket: "your_project.appspot.com",
   messagingSenderId: "00000000",
   appId: "1:00000000:web:000000000",
   measurementId: "G-11111111"
 };
接著一樣去設定環境變數 FIREBASE_CONFIG
export FIREBASE_CONFIG=/config/your_project_config.json
然後就可以使用 firebase serve 去模擬啦。

星期六, 2月 08, 2020

電影流水帳(2020/01/16~2020/02/5)

Shazam
  • Life (IMDB, Wikipedia),台譯:異星智慧。
  • Happy death day 2U (IMDB, Wikipedia),台譯:祝你忌日快樂。
  • Shazam! (IMDB, Wikipedia),台譯:沙贊!。
  • Lego DC Comics Super Heroes: The Flash (IMDB, Wikipedia),台譯:樂高DC超級英雄:閃電俠。

Life

蠻典型的密室恐怖片,結局有點驚悚,不過還沒到出人意料的程度。\
故事發生在環繞地球的太空站,裏面的太空人收到從火星運回來的土壤,在裏面發現了冬眠的細胞生物。然後很幸運的活化了這個細胞生物,開始培養。這個生物很驚奇的從小小的細胞長大到變成一個跟手一樣大小的生物,還取了名字「卡文」。對,你應該猜到了,這個生物有了攻擊性。它攻擊了培養他的生物學家,雖然生物實驗室有防火牆,但是這個生物還是逃了出去,接著就開始逃竄跟殺戮。
最後,剩下的兩人打算一個人帶著卡文往外太空,一個人回到地球告訴大家說,這生物有危險。結果陰錯陽差地,應該要回到地球告訴大家的人往外太空飄,帶著卡文的逃生艙卻到了地球。掉落到海上的逃生艙被附近的漁民發現,漁民基於人溺己溺的心去救援,試著打開艙門。逃生艙裡的人高喊不要開,然後眼看艙門就要打開了…

Happy death day 2U

原本以為只是一般的恐怖片,但看了開頭以後,發現挺有意思的,就接著看完了。女主角 Tree 蠻可愛、漂亮的,我覺得有點神似 Anna Faris,走的戲路也有點像,希望她未來能常常出現在大螢幕上。
Ryan 發現自己陷入了時間迴圈,在第二次還第三次的時候,就對著自己的室友跟他女友 Tree 說,好奇怪。Tree 顯然是有經驗的人,追問了詳細的情況之後,確信 Ryan 跟之前自己一樣,陷入了時間迴圈,後來找到原因才因此打破迴圈。Tree 再繼續追問 Ryan ,才知道這時間迴圈是因為 Ryan 發明的機器才產生的。Tree 直說不會吧,怎麼又再次陷入了時間迴圈。於是 Tree 為了打破時間迴圈,跟 Ryan 商量,Tree 努力在時間迴圈裡去跟 Ryan 研究、討論,並且把結果記到腦子裡,然後在下次時間迴圈裡告訴 Ryan ,看能不能幫助 Ryan ,讓他能夠完成物理實驗,以打破時間迴圈。在這過程裏面,他遇到已經死去的媽媽,才明白到有些事情的改變是有其意義存在的,無法強求。總之,在最後,Tree 跟 Ryan 弄好了機器,讓時間恢復正常,不再繼續迴圈。

Shazam!

DC 的超級英雄片,跟蟻人一樣,打的是家庭溫馨路線。
Billy 是個孤兒,在寄養家庭間遊走,他始終想著要找到自己的生母。這一次,Victor 跟 Rosa 收養了他,而且家裡還有其他五個也是被收養的孩子。Billy 很快的跟多話的 Freddy 熟悉起來,好吧,或者該說是反過來。後來,Billy 得到了意外的力量,變成了 Shazam。跟 Freddy 商量以後,他們慢慢發現了自己的能力所在。話說,能得到這個能力是有原因的,這個能力是由一個巫師所賦予的,自古以來,他跟其他六位巫師看守著七大罪,但隨著時間過去,只剩下他一人。他一直尋找著接班人,某次他找到了 Sivana,Sivana 並不適任,但 Sivana 卻念念不忘七大罪的誘惑。經過了幾年過去,他找到了回去的方法,並且解放了七大罪。衰弱的巫師不得已,找到了 Billy ,並且把力量交給他。得到七大罪力量的 Sivana 想要更強大,所以他試著找到 Billy,想得到巫師給他的力量。
Billy 後來透過寄養家庭給的線索,找到了生母,生母坦言當初沒去找他的原因,未婚生子,然後年輕又沒有生活能力,只能棄養。Billy 心裡很受傷,他知道沒辦法回去了,寄養家庭的 Victor 跟 Rosa 還好的多。但 Sivana 已經追上了門,Billy 就跟 Freddy 還有其他孩子們一同對抗  Sivana。經過一番抵抗,Billy 即使變了身,也打不贏 Sivana。就在要把力量交給 Sivana 時,Billy 突然領悟了巫師交給他力量時所說的話,於是將其他孩子叫了過來,並把力量分了出去。對,孩子們也跟 Billy 一樣有了 Shazam 的力量,然後一同對抗 Sivana ,並且重新囚禁了七大罪。之後,Billy 就安份地待在寄養家庭裡啦。
最後把力量分出去的這個點真的讓我有驚奇感,有那種「原來是這樣子啊」的感覺,我滿喜歡這樣的結局。 故事挺不錯的,節奏也掌握的不錯,可是我覺得 Billy 跟變身後的 Shazam 個性有一點反差過大,有種不協調感,如果可以更稍微接近一些會更好點。

Lego DC Comics Super Heroes: The Flash

好巧,這個也是時間迴圈的故事。
Flash 因為 Reverse Flash 的詭計掉入了時間迴圈,然後在迴圈裡被 Reverse Flash 激怒而失去了神速力。後來 Flash 還被其他超級英雄趕走,透過 Atom ,他意外找了命運博士幫忙,命運博士帶他到神速力界,Flash 通過重重考驗後,終於到了終點,要取得 Nexus,可是這就是 Reverse Flash 的陰謀,他尾隨 Flash 通過考驗,然後搶走了 Nexus。Flash 沒有灰心,他利用有神速力的積木回到人間,然後跟其他的超級英雄會合。這時蝙蝠俠才說,他跟 Atom 已經知道是 Reverse Flash 搞的鬼,他是故意演出這場戲把 Flash 趕走,才能讓背後的真兇出現的。Flash 跟超級英雄們接著開始商議看要怎麼對付 Reverse Flash,超級英雄們利用有神速力的積木,讓 Reverse Flash 分身乏術,並進而讓 Flash 能有機會重新取回 Nexus。Flash 取回 Nexus 之後,以其治人之道,還治其人之身,激怒 Reverse Flash,讓他筋疲力竭,並把他逮住。最後 Flash 歸還 Nexus ,一個快樂的大結局。

星期六, 2月 01, 2020

筆記:Lessons learnt (the hard way) using Firebase RealTime Database

主要是看這篇 Lessons learnt (the hard way) using Firebase RealTime Database 所摘要下來的重點。
TL;DR:作者用了 realtime database,然後意外收到 1000 EUR 的帳單。
作者做的是交通運輸類的 app ,realtime database 存的是使用者的最愛站牌、路線等。主要用了 Firebase 的這兩項功能:
  • Firebase authentication
  • Realtime database
使用人數約 400K+ ,主要就是 updated / authenticated 等等的。這樣帳單約 1000 EUR
他們檢討以後,發現有幾個關鍵點:
  1. keepSync ,這個不要設成 true,firebase SDK的行為沒有預期中聰明,他會在每次使用者開啟app時就下載一次!
    1. database.getReference(getUserFavoritesPath(getCurrentUid())).keepSynced(true)
  2. key 的名稱不要太長,只要這個弄短,無形中可以省掉非常多。
接著針對這兩個點,做了處理
  1. 最佳化存在資料庫的資料,改用 GSON ,以及縮短 key 的長度。
  2. 關掉 keepSync
  3. 在 app 端實作了 memory cache ,以避免無謂的去 firebase 撈資料。
作者學到的事情:
  1. 人數很多時,realtime database 可能會是很花錢的項目,特別是結構跟讀取資料邏輯沒有最佳化的時候。
  2. 要將存在雲端上的資料最小化,使用較短長度的 key ,可以幫你省掉不少錢。
  3. Firebase persistence 啟用時,firebase 只會在沒網路的時候使用本地的 cache,其他的狀況他不管資料有沒有改都會存取雲端。
  4. 不要用 keepSync(true) 
  5. 實作本地端的 cache ,以避免重複跟 firebase 索取資料。

星期四, 1月 16, 2020

電影流水帳(2020/01/01~2020/01/15)

Spider-Man: Far From Home

我覺得這集的節奏比較鬆散,沒那麼緊湊,沒上一集來的好看。但特效跟該加的梗還是很有誠意,該有的都有了。
前面簡單交代了因為彈指消失而回來的學生的處境,然後 Peter 就跟同學們去歐洲玩。這次 Peter 去歐洲玩,有件很重要的事情,就是跟 MJ 告白,為了告白,他計劃了好久。總之,一行人就出發了。
正所謂,無心插柳柳橙汁,Peter 的好友,Ned 反而莫名其妙的跟隔壁座的女同學熱戀起來了。Peter 旅途不是很順利,不時遇到奇怪的元素眾,神盾局局長也來亂,請他跟 Mysterio 一起處理元素眾的事情。
邊處理元素眾的過程裡,Peter 跟 Mysterio 熟悉起來,進而 Peter 有了想把 Tony 給他的智慧眼鏡交給 Mysterio 的想法,然後就真的交給他了。Peter 交給 Mysterio 以後,也準備跟 MJ 告白。在跟 MJ 告白時,才發現是表錯情,MJ 一直想說的是,「你就是蜘蛛人吧」,而 Peter 一直以為是 MJ 對他有意思,
總之,在表錯情的最後,MJ 拿出一個投射器,照出了之前元素眾的樣子,Peter 意識到自己可能犯了大錯。於是,Peter 跟 MJ 試著去彌補這件事情,過程中才揭露出 Mysterio 是之前史塔克企業的員工,自己的全息投影被 Tony 講的一文不值,他很怒,才聯合之前史塔克企業的員工們一起策畫出這起事件,讓自己能夠成為超級英雄,從而取得利益。最後,Peter 跟 Mysterio 展開一場激戰,取回 Tony 的智慧眼鏡,並且揭露了 Mysterio。

信長協奏曲

電影是日劇的總結跟延伸,所以在一些劇情交代上就簡單的帶過去,不多做著墨。
三郎從現代回到日本戰國時代,遇到了織田信長,信長發現三郎跟自己長的非常相似,就請託他代替體弱多病的自己。想不到,織田家因為信長(三郎)的活躍,而有了一統日本的機會。
故事大致是從第三次信長包圍網開始,一邊交代信長目前的困境,一邊交代人物之間的關係。明智光秀是織田信長本人;秀吉小時候因為幼時信長而家破人亡,對信長有一份怨恨。而三郎的人格特質卻讓原本有反心的明智光秀以及眾家臣們信服。
接著就交代為什麼明智光秀要反信長,簡單的說,就是秀吉掌握了光秀的痛處,要脅光秀殺死在本能寺的信長。光秀不得已放火燒本能寺,但卻讓信長(三郎)快走,趕來的秀吉跟光秀(真信長)說明了自己的怨忿之後,光秀非常驚訝也感到非常抱歉,跟秀吉談判說,請讓信長能統一日本,讓日本能和平,但秀吉不聽,殺了光秀。秀吉聲稱光秀逃了出去,光秀的面孔跟信長一模一樣,所以逃走的三郎只能頂替光秀的身份。三郎和勢弱的光秀軍隊,名義上又不能用信長的名字,跟秀吉一戰的結果,三郎戰敗,被秀吉逮了。三郎在秀吉面前高喊著不要忘了要讓日本和平之後就被斬首。不過三郎並沒有死,而是回到了現在。之後,有點嘴炮的說三郎的理想影響了當時追隨信長的人,然後讓日本安然的到現在。
看完去查了漫畫的資料,發現漫畫好像還沒收尾耶,不過電影這樣收尾算是不錯的了。小栗旬真的很有他個人魅力,一人分飾兩角,都能夠恰如其分;然後飾演秀吉的山田孝之也很厲害,把那種陰沉跟冷酷表現的很好;這兩個人是我印象比較深刻的。

星期三, 1月 08, 2020

Django開發者常犯的7個錯誤

從這篇 7 common mistakes that django developers make 整理出來的
  • Reinventing the wheel
    • 儘量找人家已經寫好的 package 來用,不要沒事自己在那邊重新刻
  • Monolith application structure
    • 要切 app ,該切就切。
    • 我自己目前有比較 confuse 的是,有用到其他 app 的東西時,該怎麼降低耦合度,又能使用方便,這中間去找到一個平衡點。這邊要等以後再來慢慢想怎麼做會更好了。
  • Writing fat representations and thin models
    • View 不要寫太多邏輯
    • 把邏輯抽到 module 或是 model 裡,讓邏輯統一,才能儘量重複使用。
  • Too many queries per view, or unoptimized queries
    • 一個 view 有太多資料庫查詢或是沒有將查詢最佳化,這個會導致速度變慢。
    • 我建議這邊同時可以考慮儘量使用 cache ,來減輕資料庫負擔。
  • Redundant model fields
    • 思考是不是要有真實的資料庫欄位,思考是不是可以使用 property 來做到同樣的事情。
  • Not adding indexes on models
    • 常用來查詢的欄位 (放在 filter 裡的) 記得加 index :db_index=True,該加就加。
  • Inconsistent data validation
    • model 的檢查跟 form 的檢查要一致。

您或許對這些文章有興趣

Related Posts Plugin for WordPress, Blogger...