# Intro 在 JavaScript 中的日期時間是個當初沒有定義出良好設計的東西
這裡先舉幾個常見的問題
日期格式問題 日期呈現的語系問題 時區問題 12 小時 24 小時問題 … 以原生的 API 在處理日期時間大多得自己額外做許多事情或是套用一些第三方 libary 來協助達成目的
# 時區問題 這次主要是討論關於時區的問題
在早期只能用 getTimezoneOffset() 的方法搭配時區表去換算各地時區
現在倒是可以使用 Intl.DateTimeFormat
refer - Date.prototype.getTimezoneOffset()
refer - Intl.DateTimeFormat
其實上述的問題, 在使用 Intl.DateTimeFormat 基本上都可以解決掉
詳細方式可以參以下文件
refer - Intl.DateTimeFormat() constructor
在時區中又有一個常常被忽視的的問題就是夏令時間(daylight savings time) 這個在夏季時就得把時間提前一小時的問題
如果自己處理時區就得記得處理這問題
使用 Intl.DateTimeFormat 的話系統已經自動處理了
# Intl.DateTimeFormat 這邊簡單介紹一下 Intl.DateTimeFormat 的一些用法與注意事項
new Intl.DateTimeFormat(navigator.language, { timeZone: 'America/Los_Angeles', dateStyle: 'full', timeStyle: 'full' }).format(new Date()) 這個範例就表示了當前洛杉磯的時間
第一個參數是語系, 採用 BCP 47 標準, 基本上建議使用 navigator.
...
# 前言 距離上次使用 YouTube Player API 已經是 2014 年的事了
不知不覺也過了超久了
剛好最近公司有相關的需求需要在 App 中能夠播放 YouTube 的影片
原本想說 App 應該和我沒關係了
所以這次準備躺平(誤
結果還是被牽扯進來了…
# 2022 年當前如何使用 YouTube player SDK 沒想到不看還好, 一看就準備 GG
一開始把文件丟給 Android 和 iOS
Android 那邊說無法用
我當下????
文件都寫得好好的, 為何說無法用
和 Android 一起討論了一下, 才確認了一件事
原來 Android 為了統一 libary, 在 2018 年開始推行 Androidx 要取代 android.support
最大的改變是 namespace 的變動, 雖然官方有工具可以對第三方 lib 做轉換, 但也會是一個大換血, 而且對比較老舊的套件還會需要處理 activity 和 fragment 的處理, 因為現今大多的 Android 都以 fragment 實作 UI 了
...
最近添加了一個小功能要來測試成效
就是因為 PM 有看到一些服務的連結在 iOS Messages 上呈現並非常見的圖片而是影片
PM 說好像是 iOS 15 以上支援(我自己是沒找到相關的資料證明這件事)
不過應該沒支援的話就呈現圖片
查了一下文件, 其實也不難
基本上就是定義 open graph
多定義
<meta property="og:video" content="http://www.example.com/sample.mp4" /> <meta property="og:video:type" content="video/mp4" /> <meta property="og:video:width" content="1280" /> <meta property="og:video:height" content="720" /> 這邊有個要注意的點是
原來是產出 1:1 的影片, 但發現會上下截掉
所以最後採用 16:9 的比例
# demo Your browser does not support the video tag. Refer - Best Practices for Link Previews in Messages
...
mobile web 會在點擊 a link 的時候 highlight 那個部分
原意是為了讓使用者更能夠直觀地知道是否有點擊了那個東西
但是有時這個樣式會和整體 web 的設計不合
所以會想辦法改變或關掉這個 highlight
那就得使用一個 CSS 屬性 -webkit-tap-highlight-color
如果要關掉, 那就改成透明的
-webkit-tap-highlight-color: transparent; 如果要改成別的顏色就設定顏色即可
-webkit-tap-highlight-color: red; -webkit-tap-highlight-color MDN
...
# 前言 現在在開發與線上環境常常會遇到不同 CPU 架構的問題
不同 CPU 架構底層的指令集也不一樣
最常見的影響就是在其中一個平台編譯出來的程式會無法在另一個平台執行
這情況尤其是會在接近底層的程式上見到
現在普遍來說會發現在 ARM 架構底下有些程式執行起來效率更高
所以有部分公司的服務也會在線上環境的機器選用 ARM 架構的機器
# 情境 雖然以前公司的情況是開發在 x86-64 上
線上是 ARM 的情況
但現在自己在試驗的情況是反過來的 XD
現在 Macbook 是 M1 晶片了, M 系列是 ARM 架構
我在 GCP 開的機器是 x86-64 架構
所以在 Mac 上面 build 的 docker image 是沒法在 GCP 開的機器運行
只要執行 docker run 就會出現錯誤提示說架構不同無法執行
# 解決方案 docker 有提供可以建構不同平台的 image 的指令
只要多一個 buildx 和 --platform 的指令與參數
docker buildx build --platform=linux/amd64,linux/arm64 .
...
# 前言 最近注意到 Safari 設定 100vh
在未滿內容的情況還是出現滑動的卷軸
這導致了體驗不佳
研究了一下發現是因為在 Safari 上有 url bar 的關係(iOS 15 以下還有 function bar)
100vh 的大小其實是這些 bar 隱藏時的大小(iOS Safari 滑動時這些 bar 會隱藏起來)
這邊試了幾種方式
# 改成 100% 可以改成用 100% 來取代 100vh
不過這得依情況來使用
# 使用 -webkit-fill-available -webkit-fill-available 目前只有 iOS 支援
所以可以用 useragent 來處理樣式來對應使用這個 CSS 屬性
範例
# 結論 我自己測試了一下會偏好使用 100%
個人會希望能夠簡單處理方式就用簡單的方式處理
...
# Usage docker hub
In Apple M1
no-official image
amd64/mysql
MySQL 5.7
docker pull amd64/mysql:5.7 # Run docker in local Sample for M1(different of image name)
docker run --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -d amd64/mysql:latest Container run in 0.0.0.0
mysql --default-character-set=utf8mb4 -u root -h 0.0.0.0 -P 3306 -p -A
...
# Intro 在很多實務上的需求, 需要了解 client 過來的請求是來自哪裡或來自哪個國家
最常見的方式就是依靠來源的 IP 判斷(這裡排除 proxy, VPN 或造假來源的因素)
而在 HTTP protocol 中, 會把 IP 附在 header(至於帶在哪個 header 與支援哪些 header 主要取決於各個語言對 HTTP 的實作)
header Sample
上述範例只是取幾個比較常見的會帶上去的 header
至於更加詳細的 header 支援與取得 IP 時需要注意哪些事情可以參考以下文章
Refer - 如何正確的取得使用者 IP？
而為何可以用 IP 能夠確認出是在哪個地區國家甚至城市呢?
主要是因為有 IANA(Internet Assigned Numbers Authority) 進行了 IP 網段的分配
又有細分 ABCDE 級網段
這裡先大略講一下
相關資訊可以去看網路概論等相關的資料
Refer - 各國IPv4位址分配列表
Refer - 已分配的/8 IPv4位址網段列表
# 方法 現在有幾種方法可以處理這件事情
但是經有上述的介紹可以知道其實最主要的基本判斷就是得知道哪些 IP 段對應哪些國家
那接下來就是有哪些方法可以來做這件事了
...
# Intro 又是久違的寫爬蟲…
這次是接手大大們的 code
寫的是 PHP 版本
研究了一下寫法
才發現現在可以不使用第三方套件就可以處理了
所以這裡紀錄一下
# 取得 HTML 內容 使用 curl 使用 file_get_contents curl 是我常用的方式 看了大大們的 code 才知道原來 file_get_contents 也可以取 http/https 內容…
這邊簡單貼一下兩種作法的範例
## curl function httpGet($url) { $ch = curl_init(); curl_setopt($ch,CURLOPT_URL,$url); curl_setopt($ch,CURLOPT_RETURNTRANSFER,true); curl_setopt($ch,CURLOPT_HEADER, [ 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36' ]); $output=curl_exec($ch); curl_close($ch); return $output; } ## file_get_contents function htmlContentGet($url) { $opts = [ "http" => [ "method" => "GET", "header" => "User-Agent: Mozilla/5.
...
# 前言 在 web 的世界中有一個需要處理的是文字排版的呈現
因為從電腦到整個計算機科學的領域都是在拉丁語系為主宗的國家發展的
所以在介面的文字排版上自然以從左到右為主
但是在這世界上的文字排版有從左到右, 上到下, 右到左等呈現方式
所以需要依照需求或不同語系的文字上有相對應的處理, 尤其是在多語系的情況下
上到下的排版大多是書面用的排版, 相對在資訊領域比較少呈現, 且因為上到下的排版方式也大多是亞洲地區的國家, 在標準化的話語權不高
但也漸漸在 web 領域中有開始支援上到下的排版(writing-mode)
且在資訊領域也大多是用左到右的呈現, 所以影響相對小
額外補充一下大部分的方塊文字像是中文、日文、韓文等其實左到右、右到左、上到下都可以書寫與呈現
但在部份語系像是
阿拉伯文 烏爾都文 庫德文 波斯文 希伯來文 上述文字排版就固定都是從右到左
除了希伯來文以外都是從阿拉伯文字延伸的, 就像是英文、德文、法文都是拉丁文延伸出來一樣
至於為何在世界各地的文字排版會有差異其實主要是起源於早期該文字書寫的方式與被書寫在什麼材質上面為主
右到左主要起源於早期是文字是刻在石板上面, 左手拿鑿子, 右手拿錘子, 這樣從右到左是相對順手的
中文早期大多從上到下從右到左的排列主要起源於以前是在竹片上捲成冊的(竹簡)
在單片竹片上面書寫自然是上到下, 那捲成冊之後在閱讀時為了方便持握, 會是左手拿著竹簡, 右手打開來看內容, 自然就變成了右到左來閱讀
不過現在大多也因為資訊科學的發展後在電子載體上就沿用左到右的排版(前面提到電腦乃至資訊科學都是在拉丁語系的國家發展出來的)
不過在亞洲地區的國家部分書面印刷還是有保留上到下右到左的排版
不過有點扯遠了
# 實作 RTL(Right To Left) 的方式 這次主要是要處理 RTL 的問題
但其實在實作上也很好解
HTML tag 有個屬性是 dir 只要設定是 rtl 或是 ltr 就可以了
那麼要在什麼情況下設定這個東西?
大致上會在兩種情況設定
## 1. 多語系且有右到左語系 網站是多語系的網站且有右到左語系提供切換呈現
...