Python pdf2docx 轉換工具介紹。簡單把PDF轉成Word DOCX

相信大家都會跟我一樣有個困擾要怎麼樣才能修改 PDF 檔案, 但頻率又不是多到要買 Acrobat Pro. 我來跟大家分享一個 Python 小工具可以幾乎完美的把 PDF 檔轉換成 Word docx 檔的小工具。 先決要件, 你要先安裝 Python3 在你的作業系統裡。以下的例子是在我 Windows 10 上完成的。

別用平均值(Average)或中間值(Median)來評價服務器反應效能,應該用百分位數(Percentile)

別用平均值(Average)或中間值(Median)來評價服務器反應效能,應該用百分位數(Percentile)

在打合約或工作聲明中。對於伺服器或雲端服務的反應時間 (response time) 和延遲 (latency),以前都會用平均值 (average) 或中間數 (median) 來評量。但是只用平均值或中間數來看,會無法完整的看出整理的延遲反應。 就拿以下的圖表為例,當一個專業的網管,單純的看延遲反應,在下午一點五十一分左右,系統出現了不穩定。延遲衝到了800毫秒。一連持續到約二點零七分左右。直覺可能是其中一個服務器掛掉了。但又自我修復好了。 所幸暴衝不是一直持續,所以可能不以為意。 毫秒 圖一:系統3小時的反應時間 如果是早期的服務水平,這時候會調出平均服務圖表來確認整體的服務是不是有被影響到。一般的服務水平都會訂在 99% 的情況下,服務水平會在 200 或 250 毫秒以下。以平均表來看,在反應最慢的時候也都還在 160 毫秒內。所以看起來也是沒什麼異狀。  圖二:系統3小時的平均反應時間 但是如果是使用 90 百分位數的圖表來看,那可就不同了。90 百分等級是一種描述統計指標。意思是指,在百分之九十位數 (90th percentile) 的正常狀況之下,服務狀況還是可以持續在 200 毫秒內嗎?  圖三:系統3小時的90百分等級時間 圖三指出在十二點三十三分時,百分之九十的正常服務就己經飇高了。一直攀昇到一點五十一分到最高峯約 500 毫秒,之後才開始穩定下來直到約二點零三才恢復過來。那其實不穩定的時間比相象中更久,快要 90 分鐘系統的穩定性一直都是在服務平均水平之外的。 所以結論就是在管理系統時,不能只單看平均服務的數據來確定服務水平是否有達標。利用百分位數的圖表可以更了解系統淺在表現狀況。主統雲端服務都有提供百分位數的監控(如 AWS),請大家多加利用。 參考文獻: 1. https://www.elastic.co/blog/averages-can-dangerous-use-percentile 2. https://azure.microsoft.com/zh-tw/support/legal/sla/cloud-services/v1_5/ 3. https://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles

Javascript 取得 radio button 內容的做法

前陣子好奇怎麼從 HTML 表單裡截取 radio button 選擇的內容。以下提供簡單的程式碼。 HTML 的部份 <form name=”userInputForm”> <h1> Please enter your option among rock, paper or scissors </h1> <input name=”userInput” type=”radio” value=”rock”> Rock<br> <input name=”userInput” type=”radio” value=”paper”> Paper<br> <input name=”userInput” type=”radio” value=”scissors”> Scissors <input type=”Submit” onclick=”getUserInput()”> </form> Javascript 的部份 function getUserInput() { var userInput = document.querySelector(‘input[name=”userInput”]:checked’).value; document.write(“Your result: ” + userInput +…

Sling Media, Inc.

Sling Media, Inc.

Sling Media, Inc. 簡介 Sling Media 是2004年有一對兄弟 Blake Krikorian 和 Jason Krikorian 創立在加州。二位都是死忠的舊金山巨人球迷。在美國球賽轉播有地域限制,在地球隊的比賽只能在當地域轉播。比如舊金山巨人隊的比賽只能在北加州收看,在南加是道奇的市場就無法收看。當然這是在還有 MLB.tv 還沒有成立之前。這對兄弟想在出差時還可以看自家球隊的比賽,決定自己研發一個可以把自家第四台訊號透過 Internet 來收看的裝置。一年後打造出Slingbox,成為早期IP (Internet Protocol) 影音串流的先鋒。Slingbox 更在2007獲得 Technology Emmy Award (科技艾美奬)。在2010年趕上 iPhone 和 Android 的潮流釋出 Slingbox Apps 在二大智慧手機陣營,讓使用者可以在行動裝置上觀賞自己專有的影音媒體。 Slingbox 有二個重要的技術,除了在機上盒的硬體技術之外。我簡單的在下面介紹一下。 Place Shifting (地點轉換) 當然就是影音訊號可以不再限制於定點。只要透過網路,就可以達成串流。串流的技術有分 IP point-to-point (IP 點對點), UDP (User Datagram Protocol) point-to-point 還有 cloud relay (雲端中繼轉播)。當然我們都知道防火牆和網路提供商會阻擋一些通訊協定。還有一些埠口也不會全部支援。理想的影音串流是通過 UDP 來達到快又穩定的結果。但是 UDP 不容易支援,所以如果UDP連線無法建立,就會切換到用…