跳到主要內容

Nexus 5 鏡頭蓋破裂更換

N5 的相機鏡頭因為設計上是突出背殼
而我很喜歡裸機的感覺,也沒有使用保護的手機殼
所以不知不覺中,鏡頭蓋就裂掉了

剛開始裂掉也還好,感覺拍照沒有影響
但是後來又掉進馬桶以後
拍出來的照片就臭臭的(?
不對,是霧霧的.
可能是因為會慢慢有髒東西從裂縫跑進去...

雖然說我之前被淘寶詐騙了一次
天兵賣家寄錯地方卻不退錢
天貓店小二介入後說要退我錢卻遲遲沒有下文...
但是上網找了一下 N5 的零件,
果然強國的淘寶什麼都有,什麼都不奇怪.
於是我只好放下羞恥心
再去淘寶消費了.... 因為零件真的很便宜啊...被坑就認了....

N5 鏡頭蓋破掉的話,有在賣的零件組合有
鏡頭蓋
鏡頭蓋含鏡頭框
背板

因為我覺得要把破掉的鏡頭蓋從鏡框拿出來有點麻煩
所以就買了鏡頭蓋含鏡頭框
幸運的是,我的猜測是對的!
含鏡頭框的組合只要多幾十元
但是鏡頭片是裝好的~所以我不用再從舊的拆下來,

要更換背板上的鏡頭片
所需要的道具只有
塑膠拆機片 + 小十字螺絲起子

N5的背殼是用幾個卡榫扣住而已而已,
背板則是有六個小螺絲起子鎖住,轉開後
背板的左右兩側有稍微扣住,選一邊壓開後,就可以把背板拆下來.

鏡頭框則是卡在背板的洞上,
所以稍微彎折一下背板,就可以把鏡頭框整個推出來.

最後的結論是,要方便的話,
只要買鏡頭框+鏡頭蓋的組合就好了~

如果想挑戰手藝,則可以只買鏡頭片
背板應該是不需要買 (還是說有人覺得拆鏡頭框也是一種麻煩?)
我一次買兩組...因為想說可能過一陣子又會破了吧...哈哈..








留言

這個網誌中的熱門文章

3M UVA3000 更換濾芯紫外線燈匣

用了一年的3M濾水器提示說要換濾芯和燈匣 上 Youtube 想找教學的影片可是沒看到 UVA 3000 的 經過了一番奮戰後在這邊記錄一下 希望可以幫助後人,以免再重蹈覆轍。 Step 1. 拔掉插頭,把淨水器從牆上拿下來(基本上他是掛著而已),比較方便施工。 Step 2. 把前蓋往上拉,很容易就可以看到裡面的東西了。 Step 3. 打開後可以看到有兩個柱狀體,左邊的是燈匣,右邊的是濾芯。 Step 4. 這裡有個祕技是,這兩個柱狀體是可以往上 翻開30 度左右,這樣就可以有比較大的空間施工。 Step 4. 更換濾芯的話,柱狀體的瓶身上有箭頭,往左就是轉開,往右就是鎖緊。 Step 5. 更換燈匣的話比較麻煩一點,因為他底部是電源,頂部的右邊有個突出來的小方塊。對照淨水器上方連接處的話會有個弧形的凹槽,這是要 match 的.如果你只注意瓶身的箭頭往右鎖回去,就會造成漏水...Orz... Step 6. 把前蓋蓋回,機器掛回牆上,插插頭,開水,如果機器沒有告訴你有燈匣異常或漏水的話,就可以長按 C / UV  Reset 計數器了. 所以關鍵字就是,要往上翻 30 度,燈匣上面的小凸點要在右側,要看瓶身的 小箭頭. May it helps!

Access private API gateway from another account

最近在做一個 PoC 驗證說怎麼在現有的架構下,把一些 public API 移到 VPC 裡面,只讓特定網路的人可以存取。 當然最直覺的想法就是,建一個新的 VPC ,加上 execute-api VPC endpoint 然後這個 VPC 再跟特定網路做 Peering,建一個 Private API Gateway 在新的 VPC 裡面。 這樣新的 VPC 可以透過 VPC endpoint 去存取 API Gateway,然後再加一個 ALB ,裡面的 target group 指向 VPC endpoint 的 IP和 443 port,ALB 設定好 Domain Listener,API Gateway 也加上相同的 Custom Domain Name,這樣子 ALB 就可以當成特定網路 access 的 entry point,一但 Peering 完成後,從特定網路來的 request 就可以經由 ALB -> API GW 跨 VPC 存取原本環境的 backend resource。 但我一直在想,Peering 是必要的嗎? 沒想到隔天就看到這個教學  How can I access an API Gateway private REST API in another account using an interface VPC endpoint?  裡面的做法突破了原本我直覺上的盲點! 就是即使是 Internal API Gateway 似乎只要設定好了 resource policy 就可以允許其他 account 的 VPC endpoint 跨帳號存取! 所以例子裡面的 private API Gateway 是建立在 B 帳號裡面,A 帳號的 VPC 只是啟用了 VPC endpoint,一但 B 帳號的 private API Gateway 在 resource policy 設定好允許 A 帳號的 VPC endpoint 存取,即使兩個帳號之間沒有 peering 也是可以互通的! 雖然說這樣子要帶 hostname header or api-gw-id 但是 原本架構上的 ALB 也是為了 VPC endpoint 可以知道要 forward request 給哪個 API Gateway ...

Application Load Balancer lambda endpoint healthy check will be charged

AWS 還是有蠻多坑的... 如果 ALB 的 TargetGroup 使用 lambda endpoint 那麼為了避免 code start issue 可能會使用 provisioned concurrency 另外 lambda endpoint 在 update stack 的時候會出現 Load Balancer not able to stabilizied 的問題。AWS support 目前給的work around就是開啟 ALB healthy check 預設是每 35 秒會做一次 healthy check 然後如果 ALB 跨3個 AZ 的話,healthy check count 就 x3 .... 然後每次的 lambda execution 都是照 lambda function usage 來收費 另外ALB的 healthy check 不會有完整的 request header 如果你的 framework 不預期有這種不正常的 header 沒有去 handle 的話 可能會一直狂噴500... 如果你還沒有把預設的 lambda error retry 關掉的話...... 這樣子用 lambda endpoint 真的比較省嗎?....