第25個冬天

https://e.vnexpress.net/news/business/economy/vietnam-lags-far-behind-in-setting-healthy-work-hours-lawmakers-4001432.html 傳統標準工時定義 標準工時( 做一件要花多久時間) = 平均時間 x 評比 x (1 + 寬放率) (平均時間除非變異十分小不然可能會失真!) 通常   評比 x (1 + 寬放率) 有些工廠可能會合在一起 定義為  工分係數 不一定每佔標準工時都要套用同樣計算公式 通常 會針對有瓶頸的工作站 才需要代入評比以及寬放來計算 就業主老闆們角度會care的是人力成本(生產成本) 可以藉由工時去乘上工資率(160/hr)可以去評估相應人力成本 當然還涉及到後續的出貨時間預估 一個很緊湊的標準工時 , 通常你會被產線罵 一個很鬆的標準工時 , 通常會換成被老闆罵 在這當中夾心餅乾角色 IE工程師(Industrial engineer)  或者 生管(Production management) 平均時間 平均時間 也就是標準工人的平均時間 其實會因為有人是快手or慢手有很多變因 快慢是會有差異的而且差很多 此外也會涉及 樣本數太少 可能會導致抽樣計算出的平均時間基準失真 在者通常我們會藉由 多次量測 相同 產品取其平均時間的手法來計算 但事實上還是會出現相同產品實際的工時時間變異會很大的狀況發生 1.會不同的 因為在此站會有不同的作業行為產生 不同作業行為發生也就伴隨不同耗費時間 2.有可能包含等待時間(實際上不該包含) 評比 因此還會有所以 評比 快手評比>1 ，慢手評比<1 (可能會給定一個ratio 來作為快慢手的調整率) 通常生產線普騙情況 要馬是 人機互動個佔一半 或者 機器為主人為輔 因此評比當中還涉及到你是評人還是評機器 寬放率 外乘法計算方式 寬放率= 寬放時間 / 淨時間 * 100 標準工時 = 正常時間 * (1 + 寬放率/100) 內乘法計算方式 寬放率=寬放時間/(淨時間+寬放時間) * 100 標準工時 = 正常時間 * (100 / (100 - 寬放率) ) 寬放一詞可理解為生產線OP不可能無任何中斷，整天以相同速度完成工作。 類似 OP 是需要一...

  https://sendpulse.com/features/webpush 在不同載具(client-side)有各自不同的通知響應方式 以之前blog介紹過的 Web Notification(Push)_使用html5原生Notification桌面通知 我們來探討Server-Side技術設計 一些網站早期為了實作推送功能，多半是透過ajax輪詢 ajax polling可能每隔1秒就從client端browser發送HTTP請求，再由server回傳 最新資料，這類傳統模式很明顯會有的缺點就是浪費較多的頻寬資源。 https://www.researchgate.net/figure/a-Server-side-notifications-mechanisms-AJAX-polling_fig5_236145030 HTML5 定義了新的WebSocket協定可以帶來更好節省server資源與頻寬的即時雙向通訊機制。 WebSocket別於Http協定可以支援持久連接。 其提供了一種在TCP連接上實踐全雙工通訊的協定 WebSocket可以讓Server主動向client端發送資料，別於過往的被動等待機制。 只要完成了第一次handshake，client跟server兩端就可建立持久性連線並進行雙向資料傳輸。 再各大瀏覽器支援程度也可以說是具有一定的成熟性 Websocket 通訊在傳輸資料量大小和效率方面比 HTTP 協定來得更佳， 特別是對於傳輸量大的、重複的資訊。 在 HTTP 協定中，每次請求都需加送標頭(每個請求至少8KB) 在 WebSockets 上初始請求後每條傳輸最少 2 個Byte 透過.net core web api實作WebPush消息推送 websocket配置 新增好專案 先安裝 websocket套件 在 Program.cs 配置 WebSockets 中介軟體： app.UseWebSockets(); 程式碼 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 var builder = WebApplication.CreateBuilder(args...

  有一張table資料量累積十分龐大 跨年度累積量很可觀 那在耗時查詢上 程式碼: SET STATISTICS IO ON ; SET STATISTICS TIME ON ; dbcc dropcleanbuffers --clear buffer SELECT * FROM [AdventureWorks2014].[Sales].[SalesOrderHeader] SET STATISTICS IO OFF ; SET STATISTICS TIME OFF ; 經過時間 = 420 ms左右 當資料庫中某個table的資料量爆多，在查詢資料時候會明顯感覺到速度很慢 此時可以考慮分區表 分區表是自SQL Server2005以後出現的功能，這特性允許把邏輯層面的一個table 在物理層面可分為多個部分。 Partition Table可以就物理層面去將一個大表分成幾個小表，但從邏輯層面看，還是原先那個單一個大表。(換言之，你程式碼不會有需要改動。) 白話而言，資料會是分段的存儲，較常使用的技法是透過年分(建立的日期)，對於特定當年資料做CRUD的操作。而對於較舊資料幾乎不做寫入操作只進行唯讀查詢。 這類情境可能就適合Partition Table的功用。 若對於資料操作只涉及到一部分資料而不是全部資料情況可以考慮透過分區表，若一張資料表中的data經常不管年分之類的甚至很頻繁有增刪改查操作就建議最好不要分區。 通常隨著資料增長，只使用單一個資料庫文件存放的弊端就會慢慢浮上檯面。 因此若使用多個文件分布資料到多個硬碟中可以集大提高I/O效能 再來就是對於備份和復原等操作也會輕鬆一些，尤其針對資料量略大的DB。 分區表:就邏輯層面仍算同一個(同一個檔案組)和多個的(不同檔案組) 較為透明可見的 分表:物理上分區(clone出來,因此在邏輯層面看算多個,物理層也算多個) DB中分區其實分為 水平分表(Horizontal Partitioning):一張資料表的資料分成多個表(結構不變) 垂直分表(Vertical partitioning):將一張資料表按照欄位分成不同的表(結構發生改變) 大部分都優先推使用水平分區如此一來程式碼會比較不會有需要更動的地方 分區的意義在於去將大量資料從物理上切分為幾個互相獨立的小部分。 ...