侏儸紀世界：伶盜龍 Velociraptor

伶盜龍 Velociraptor，

另一個中文名稱又稱為迅猛龍，

不管在侏儸紀公園還是侏儸紀世界，

都有其身影存在。

侏儸紀世界：伶盜龍 Velociraptor

伶盜龍存在於白堊紀晚期，

距今約 7500萬至7100萬年前，

與現在的猛禽類關係很相近，

其學名 Velociraptor，

意思為敏捷的盜賊，

身高約 0.5 公尺，

體重約 15 公斤。

伶盜龍具有高度智慧，

一般認為有群聚並一同狩獵的習性，

但在侏儸紀公園與侏儸紀世界中的伶盜龍體型與現實中是有出入的，

最早發現伶盜龍化石是在 1923年蒙古的戈壁沙漠，

其身高與體重並未像電影中這麼高大，

身形近似於狼，

可以說是侏儸紀世界中的"狼群"代表。

在之前介紹過的手遊： Jurassic World 適者生存 中，

同樣也有牠的一席之地。

其混種生物間的關係，

還是有符合原作的設計，

不管是帝王暴龍或者後來的帝王伶盜龍，

其基因都來自於伶盜龍。

至於抗性部分的話，

姑且算是遊戲中新創的屬性，

在電影中是沒有此種特性的，

當然，

出沒的地點也與現實的伶盜龍棲息地無關。

提到伶盜龍，

相信有看過侏儸紀世界的人都知道 Blue 這個名字，

由歐文訓練出來的小藍具有情感與高度智慧，

因為牠造就了侏儸紀世界兩集的混種生物，

帝王暴龍與帝王迅猛龍，

可說是侏儸紀世界系列明星中的明星，

在 2021 年的新作中不知道是否還有其戲份就讓大家拭目以待吧。

Django 自訂 USER Model 範例教學

在 Django 中預設有 User Model ，

內建有幾個基本的欄位

• username
• first_name
• last_name
• email
• password
• groups
• user_permissions
• is_staff
• is_active
• is_superuser
• last_login
• date_joined

若是這些欄位都不符合使用需求時，

就需要自訂 USER Model，

這就是今天要來教大家的

Django 自訂 USER Model 範例教學

 自訂 USER Model 有幾個方法，

最簡單的是直接以一對一關係新增相關的欄位，

直接以程式碼做為範例：

from django.contrib.auth.models import User
from django.db import models


class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE, verbose_name='帳號名稱')
    real_name = models.CharField(max_length=30, blank=True, verbose_name='真實姓名')

首先必須先到 models.py 

從 django.contrib.auth.models 匯入 User 

透過一對一關係

models.OneToOneField

將 USER Model 的欄位做個延伸，

底下再加入要新增的相關欄位即可，

在此範例中將真實姓名加入 UserProfile 中，

其他也可以加上手機號碼，公司電話等等相關欄位。

特別要注意的是，

在與 USER 欄位關聯時，必須加上

on_delete=models.CASCADE

在刪除 USER Model 的時候相對應的 UserProfile 才會跟著刪除，

避免不必要的錯誤發生。

使用上也很簡單，

def my_profile(request):
    target_item = UserProfile.objects.get(user=request.user)

先取得目前登入使用者的 profile，

就能直接使用新增的欄位 real_name

target_item.real_name

若網站已經上線一段時間，

原有的 USER Model 已經有許多資料，

為了新增額外的欄位以此種方式最為適合與簡單，

既不影響原有的資料，

又能根據需求新增相關欄位。

另一個方法則是使用 AbstractBaseUser / AbstractUser 直接自訂 USER Model 欄位，

相對地使用上較為複雜，

就不再此入門的範疇探討，

有機會再介紹此種方法。

CIDR 標記法 Classless Inter-Domain Routing

網路已成為目前生活上不可或缺的一部分，

每個在網路的電腦都有屬於自己的 IP，

這組 IP 由四個數字組成，

而這就是今天的重點，

CIDR 標記法 Classless Inter-Domain Routing

早期 IP 的使用上，

粗略地將其分為 Class A、B、C ，

• Class A 使用最前面一組數字做為字首，其他三組數字為主機位址
• Class B 使用最前面兩組數字做為字首，其他兩組數字為主機位址
• Class C 使用最前面三組數字做為字首，其他一組數字為主機位址

若使用此種方式做為分類，

主機的字首僅能使用 8、16、24 位元，

可分配最小數量為 256 ，(2的8次方)

高一級的數量直接跳上 65536 ，(2的16次方)

這導致了許多未使用 IP 的浪費，

更造成大量 Class C 類的網路產生，

CIDR (Classless Inter-Domain Routing) 就是此問題的解決方案。

CIDR 標記法

是由字首與一個0~32的數字組成，

例如： 192.168.1.0 / 24

24 表示字首為24位元，

同時也是子網路遮罩的1的位元數量。

這樣的分配法使得 IP 可分配最小主機數量為 1(2的0次方) ，2，4......

何時會用到 CIDR 標記法呢？

除了一般的分配 IP 以外，

最廣泛的用途在於防火牆設定，

如之前提到過 GCP 防火牆設定的 IP 範圍，

就是以 CIDR 標記法來實行。

以 IP 140.134.130.99 為範例，

如果將來源 IP 範圍設定為140.134.130.99 / 32 ，

就表示僅有此台 IP 能夠通過防火牆。

( 將來源 IP 與 網路遮罩做 AND 運算，若符合設定的字首防火牆就放行 )

暗黑破壞神3 - 第 22 賽季 涅法雷姆之影

經過數個年頭，

賽季循環已成為例行公事，

雖說如此，

還是必須想些變化避免無趣，

暗黑破壞神3 - 第 22 賽季 涅法雷姆之影

既然是當季的活動，

一進入遊戲就是要打下廣告吸引玩家轉生，

本季最主要的的兩個重點為：

昔日之影：

觸發聖壇或秘壇，

將會產生暗影化身，

暗影分身的力量會隨角色而變化，

並可持續存在 1 分鐘或是直到死亡為止

第二個重點則是卡奈魔方會多出一個格子讓玩家選擇，

也就是說一共有四個欄位可選擇，

當然這能力是不能重複的

本季各職業的海德格贈禮分別為：

• 野蠻人 - 九十蠻夷 
• 聖教軍 - 英勇聖禦 
• 惡魔獵人 - 恐懼之地機鎧 
• 武僧 - 正義楷模 
• 巫醫 - 蒙杜奴古戰裝 
• 秘術師 - 堤豐罩衣 
• 死靈法師 - 燃燒狂歡節舞會裝束

其他物品的更新與修正，

請參照官方更新檔說明

以 Google 為範例設定 Open edX 第三方登入

第三方登入又稱 social authentication ，

簡單明瞭一些的就是使用社群帳號來登入網站，

可以少記一組帳號密碼，

Open edX 當然也支援此種方式登入：

以 Google 為範例設定 Open edX 第三方登入

之前也提到過使用 Facebook 的第三方登入，

其實作法大同小異，

主要的不同點主要在 Google 端的申請，

前往 Google API console

在憑證部分新增一個 OAuth 用戶端 ID，

填好或選取各項資料：

• 應用程式類型：網頁應用程式
• 名稱：
• 已授權的重新導向 URI： [your edx domain]/auth/complete/google-oauth2/

申請完畢後可以取得一組用戶端 ID與用戶端密碼

前往

[your edx domain]/admin/third_party_auth/

進入 oauth2providerconfig 並新增一個設定( ADD PROVIDER CONFIGURATION )

填好或選取下列各項目：

• enable：勾選
• icon class： fa-google-plus (新版本 Juniper 改為藍底)
• Name： Google
• Slug： google-oauth2
• Site： [ your edx domain ]
• Visible：勾選
• 信件驗證的話可選可不選
• Backend name: google-oauth2
• Client ID: 就是上述在 Google 申請的用戶端 ID
• Client Secret: 上述申請的用戶端密碼

其中 Client Secret 也可以填寫在 /edx/app/edxapp/lms.auth.json中，

“SOCIAL_AUTH_OAUTH_SECRETS”: {       

        “google-oauth2”: “Client Secret” 

}

儲存跳出回到 Open edX 的登入畫面，

就能看到多出一個 Google 的登入選項，

要使用第三方登入，

必須先以平台帳號登入後，

在 帳號設定 的 已連結的帳號 中，

進行綁定才能正常使用。

 

GCP 錯誤 Connection via Cloud Identity-Aware Proxy Failed

Google Cloud Platform 提供了許多服務，

Compute Engine 也是其中的一種，

透過 VM 執行個體可建立各種不同的系統，

透過 Chrome 新開視窗以 ssh 登入有可能出現錯誤，

GCP 錯誤 Connection via Cloud Identity-Aware Proxy Failed

不知道是否為 Google 漏掉設定該項的緣故，

連續開兩台 VM 都在安裝軟體後重新連線時出現此問題，

原因為防火牆擋掉該服務，

前往 Google Cloud Platform 的安全性，

找到 identity Aware Proxy 將其開啟，

點選前往 IDENTITY AWARE PROXY 按鈕，

選擇 SSH 和 TCP 資源，

可看到目前通道資源，點選警告鏈結後，

系統會告知需要新增防火牆設定。

點選按鈕編輯防火牆，

於上方工具列新增防火牆規則

依照底下設定

Name: allow-from-iap

方向: 輸入

Target: 網路中的所有執行個體

來源篩選器: IP 範圍

來源IP範圍: 35.235.240.0/20  (以上圖範例中的 IP 為準 )

指定的通訊協定和通訊埠：選擇 全部允許

儲存後重啟 VM 即可使用 Chrome 新開視窗以 SSH 登入

diablo3 暗黑破壞神 秘術師 維爾的神妙奧秘 套裝實測

 之前介紹過了秘術師的

堤豐罩衣 

不死鳥的華服 

塔拉夏的法理套裝

德瑟雷的至高傑作套裝實測

最後的套裝當然也不能錯過：

diablo3 暗黑破壞神 秘術師 維爾的神妙奧秘 套裝實測

作為法系職業的秘術師，

變身御法者後，

渾身黑漆漆的充滿神秘感，

今天就來實測維爾的神妙奧秘這套專屬御法者的套裝。

除了御法者的變身技能外，

此處選擇的技能都是部分是為了拖時間的，

畢竟不會每次都將冷卻時間降低到無縫接軌，

被動技能選擇以殘影與盱衡戰局來減少受到的傷害，

喚法可減少冷卻時間 20 %，

無畏用來增加傷害 30%

卡奈魔方的武器則梅希斯密特之劫掠者來減少冷卻時間，

使用天鷹胸鎧降低受到傷害 50 %

元素嘉年華搭配喬丹之石可大幅提高傷害

御法者的傷害可隨著堆疊效果增加，

除了攻擊速度也加快以外，

同時也能提高護甲值與抗性，

故選用法祖拉的不可信之鍊。

搭配迦陀朵的決心套裝，

可讓御法者每秒發出一道毀滅浪潮

在等待冷卻時間時候擊中敵人可推疊增傷至毀滅浪潮，

最高疊加 20 次的 4000% 武器傷害

最後再以阿鈕的項鍊再度增傷最高 100 %，

並使用團結戒指讓秘術師不要太容易就躺地上休息。

鑲嵌寶石的選用部分，

除了選擇非物理減傷的奧幻之石與近戰減傷的毀傷之禦之外，

挑選迅捷勾玉提高攻速與閃躲機率外，

每堆疊一層迅捷還能減少冷卻時間 1 %。

最後附上大秘境 80 層的實測畫面：

湯姆克蘭西：全境封鎖 遠征 肯利地鐵站

全境封鎖是一款第三人稱射擊角色扮演遊戲，

玩家扮演國土安全局的特工，

進行各式各樣的任務，

除了主線劇情以外，

其他還有許多不同的支線任務，

也有時間限定的遠征任務，

今天的主題就是遠征之一：

湯姆克蘭西：全境封鎖 遠征 肯利地鐵站

肯利地鐵站主要有三個任務，

調查已部署的土製炸藥、調查已部署的軍用伺服器以及調查化學儲存槽等。

調查已部署的土製炸藥，

主要目標必須找到並阻止土製炸藥爆炸，

而化學儲存槽有 A B兩個，

玩家必須找到並摧毀它們，

調查軍用伺服器的話不難，

主要難在玩家必須尋找正確的閥門來降低水壓，

有兩種方法可以找到正確的順序，

一種是觀看上方的黃色管子，

如果有彎下連接的就是釋放水壓的閥門，

另一種則是判別是否有黃黑相間的標誌，

最後影片範例是以第一種方式解決，

除了釋放水壓外，

岐管的摧毀是有時效性的，

必須要在限定的時間內將其摧毀，

當然要順手解決妨礙任務的敵人，

時間稍微短了些，

故要多注意時間否則就會任務失敗。

如果在特定時間內將肯利地鐵站或其他的遠征任務通關，

就能得到精通解鎖。

肯利地鐵站這個任務主要會卡關的地點在於釋放水壓部分，

其餘只需要注意在時間內完成任務即可，

最後就以精華篇影片做為結束。

 

Google OAuth 申請範例教學

第三方登入帶來的對使用者的便利，

也能夠讓使用者直接以目前現有的帳號登入，

不需要再多記一組帳號密碼，

今天就以 Google 作為例子教大家如何申請：

Google OAuth 申請範例教學

首先要到 Google API Console ，

在左方工具列的憑證中選擇建立憑證，

找到 OAuth 用戶端ID，

設定要使用此憑證的應用程式，

若為網站的話，

此處選擇網頁應用程式，

設定名稱與已授權的重新導向 URI 即可，

系統就會給一組用戶端ID與用戶端密碼。

在特定條件下，

申請 OAuth API 的應用程式是需要經過 Google 的驗證的

• 使用任何敏感範圍或受限範圍來請求Google用戶數據。
• 應用程式在OAuth同意畫面上顯示圖示或顯示名稱，而不是重定向URL域。
• 應用程式的授權域數超過了專案的域數限制。
• 改變了已驗證的 OAuth同意畫面

若發生上述情形，

應用程式就必須經過驗證，

系統會詢問應用的資源類型，

接著詳細填寫應用程式資料，

包含應用程式名稱、支援的電子郵件信箱、應用程式的 Icon，

以及應用程式網域的相關資訊，

如：首頁、隱私權政策、開發人員聯絡資訊等等

接著設定應用程式需要用戶同意或提供的資訊，

也就是應用程式能夠取得使用者資料的詳細程度，

一般的公開資料屬於非機密範圍

第三步則是提供選填資料，

提供 Google 審查人員更多關於應用程式的詳細資料，

全部填寫完畢後，

送出給 Google 審查即可。

[Django]The model User is already registered 問題解決方案

Django 後台提供了方便的管理介面，

方便使用者管理 model

USER model 預設就已經設定好，

當然也能夠客製化希望顯示的介面，

這就今天的主題所在：

[Django]The model User is already registered 問題解決方案

如果直接在 admin.py 定義的話，

就會遇到 The model User is already registered ，

原因是因為 Django 預設就已經幫使用者定義此 model ，

解決方法很簡單，

將其 unregister 後，

重新將自訂的頁面註冊即可：

admin.site.unregister(User)
admin.site.register(User, UserAdmin)

設定换行字元 CRLF LF CR

在不同的平台上，

文件的換行字元各有不同，

CRLF - > Windows

LF - > Unix / Linux

CR - > Mac 

若始終在同個平台上設計開發的話，

使用何種格式都無妨，

若在不同平台上開發最好能夠統一格式，

避免不可預期的問題發生或者產生混淆。

以 Git 為範例，

使用 CRLF 與 LF 就會判別文件有相異處，

這在軟體開發與版本控制中不是什麼嚴重的問題，

但卻會讓人誤以為程式有修改變更。

解決方法很簡單，

執行：

$ git config --global core.autocrlf true      

即可。

core.autocrlf  可以三個數值，

true, inout, false      

使用 true 的話，

git 會自動將 CRLF 文件轉換為 LF。

若是使用如 Pycharm 之類的 IDE 軟體，

可從上方工具列的 File - > Settings 中

找到 Code Style 頁面，

在 General 分頁中，

找到 Line Separator 並將其設定為

Unix and macOS ( \ n )

這樣一來，

在協同開發中，

由於換行符號造成的差異與誤解就得到解決。

為應用程式與網站資源啟用 Google 信號

之前介紹了 Google Analytics 4 的安裝流程，

當然僅使用預設功能已經足以應付大多數的使用情境，

若是需要更進一步的分析，

就必須透過今天的主題來達成了：

為應用程式與網站資源啟用 Google 信號

簡單的講其實就是對 Google 服務龐大的資源進行整合，

Google 發展至今與各位的生活已緊密結合，

舉凡由 YouTube 、Gmail、Chrome、匿名的定位紀錄等等，

造就了 Google 擁有著龐大的數據資料，

對於 Google Analytics 來說開啟 Google 信號就是連結上這些數據的樞紐。

開啟的方法也很簡單，

只有兩個步驟，

開啟後 Google Analytics就能對數據資料提供更精準的分析，

從行銷的角度來看，

當今天瀏覽網站的使用者，

透過 Google Analytics 的分析後，

對於使用者的喜好與興趣，

推送與其較為相關性的廣告，

在成交或者點擊方面，

勢必會有較高的機率。

比起過去的亂槍打鳥，

有數據基礎的推測與行銷，

成功交易的機率相對來說是相當高的。

 

新版 Google Analytics 4 設定流程

隨著時代變遷，

軟體更新也是不斷在進行中，

在舊版本的 GA (Google Analytics)中，

主要以網站上的行為分析為主，

Google 為新一代的 Google Analytics 則強調跨裝置追蹤，

可將來自 app 與 網站的行為分析放在同個資源中來比較分析，

至於新版本設定方式也很簡單，

就直接開始今天的主題，

新版 Google Analytics 4 設定流程

前往 Google Analytics 預設會使用新版本的頁面，

還沒升級 GA4 系統會自動導入舊版本首頁，

前往 GA 的管理頁面，

有三個頁面依序為帳戶、資源、資料檢視，

未升級新版本在資源頁面會有升級至 GA4的選項，

直接點選該選項，

並選擇

我需要建立新的 Google Analytics (分析) 4 資源

按下開始使用的按鈕後，

設定精靈會告知原有資源不會受到任何影響，

且系統已啟用加強型評估

與舊版本相同，

要收集資料來進行行為分析需要透過代碼，

點選導入代碼，

在資料串流中選擇網頁串流，

點進要導入的資料串流中，

可找到全域網站代碼，

將該程式碼複製到每個頁面的 HEADER 中，

就能夠正確收集資料。

資料設定部分，

精靈會自動導入舊有資料，

有誤的話自行點入編輯即可。

回到 GA 首頁後，

可看到新版本的分析畫面，

系統也有一個陽春的導覽教學。

上面的導覽其實就是教大家如何來自訂報表，

設定完畢後就會出現在首頁的分頁工具列中，

下次直接點選就能進入自訂報表中觀看想要分析的資料。

下圖為新舊版本，

導覽工具列呈現的不同畫面，

左側為舊版本，

有側為新版本 GA4 ，

下次若有機會再詳細介紹各個功能的使用方式。