Skip to main content

Posts

[Raspberry pi] 陽台的老鼠偵測器

前言: 話說前陣子爸爸家陽台不斷出現米奇老鼠,立刻清理陽台所有東西,然後又跟市政部門反映問題,可是情況還沒有好轉,米老鼠來完一隻又一隻,我爸陽台在老鼠界應該是網紅打卡聖地(誤),要不然就是米奇老鼠版米奇林三星餐廳(?) 雖然我們抓到了三隻,到上兩個禮拜為止還有至少一隻一直抓不到,每天淩晨還會來吃事後煙留下老鼠屎,真_北。 這隻老鼠對傳統攻擊有抗性,有IT9朋友前陣子用Raspberry pi自製了一台electric mouse trap ,用pi的超聲波雷達放在鞋盒裡,鞋盒裡有一堆食物,底部佈了鐵網,偵測到有老鼠進去以後立即關門通9V電,通個1分鐘再放牠離開,大推我自己也造一台 (Youtube片搜尋一大堆,人類真變態啊,朋友好變態啊)。可是我覺得這樣又好像有點太殘忍,不如先偵測牠們什麼時候來,嚇嚇牠們看看有沒有效果再說吧。 目的: 用Raspberry pi及手上有的感測器弄一隻放陽台用來偵測和嚇嚇老鼠的東西,並把紀錄圖像化到雲端給老爸使用。 邏輯及設計: 當老鼠進入偵測範圍,Motion Sensor偵測到生物活動Raspberry pi 處理來自Motion Sensor的訊號,如果夠強的話開始準備作出回應 Raspberry pi在Angry cats sounds中隨機選出叫聲,再經由Speaker輸出貓叫聲 Raspberry pi指示強光元件發出強光束照射目標 把偵測計數上傳到雲端圖表 材料: Sensor 在網路上看了一些Raspberry pi wild animal camera ,很多也是用Motion Sensor先偵測動物再來,我用的是PIR Motion Sensor被動式紅外線感測器,有低耗電成本便宜的好處。[1],而且可手動調整靈敏度及反應時間。  PIR Motion Sensor就是下面這個 圖片來源: learn.adafruit.com 可手動調整敏感度還有反應時間,這個有點不好調,要試好多遍才找到最佳位置。 可以在Raspbian中輸入pinout查詢GPIO避免插錯 圖片來源: learn.adafruit.com . 一台Raspberry pi 這次使用較舊的Raspberry pi model B+ 萬一老鼠生氣被咬爛錢包也不太痛 . 一張
Recent posts

[Hyper-v] 在Windows 10中使用Hyper-v心得筆記

前言: 好久沒寫廢文了. 最近因為學Tensorflow, 想在家裡建一些VM, 反正VirtualBox用到熟透了想玩些新的, 所以這幾天下班回家就像中了降的研究Hyper-v(明明Tensorflow才是重點), 得出了一些經驗筆記總結一下. 1. Windows 10只要是Home版本以上本身就自帶了Hyper-v, 只要去Programs and Features加入Hyper-V就好[1]. 2. 爬文發現上年年底開始Hyper-v本身有提供常用的Guest OS Template, 並且已經最佳化不用再自己設了, Windows及Ubuntu都有. 雖然Hyper-V是Type 1的hypervisor[2], 不過無論是Windows或者Ubuntu, 都不是KVM(Kernal based virtual machine). 3. 跟Virtualbox一樣提供GPU的模擬介面(RemoteFX 3D Video Adapter). 要了解Host中的顯示卡那些可以被使用, 可以在Powershell中輸入Get-VMRemoteFXPhysicalVideoAdapter了解. [3] 4. 要Hyper-v的Guest OS抓得到顯示卡, 需要兩個步驟. 第一步是把顯示卡加到Hyper-v中,可以在Poweshell中輸入 Enable-VMRemoteFXPhysicalVideoAdapter指令; 第二步是把Hyper-v的顯示卡加到Guest OS中(VMRemoteFx3dVideoAdapter). 不過在WIndows 10 1803不知道為甚麼VMRemoteFx3dVideoAdapter就被刪除了, 幸好只是介面被刪除而已, 還是可以在Powershell中輸入Add-VMRemoteFx3dVideoAdapter -VMName [vm_name]把GPU加回去Guest OS. [3] 5. 未必所有顯示卡或者integrated graphics都可加到Hyper-v中, 例如我家裡用的是老舊的intel H67 Express晶片就不行了. 另外一張Radeon R9 200 Series倒是可以. 6. 使用了兩天的經驗是, 如果上面步驟沒錯, 又直接用Hyper-v的Guest OS T

[Objective C]日期轉換成字串的錯誤筆記

沒想到2019年年初就飽吃驚風散,這次是發生在iOS的Issue。 2019上班第一天有user通報由公司內部使用的iOS app上傳的資料日期有問題,我們的date field是string,紀錄顯示2018/12/31號的數據全變成了2019/12/31號,影響範圍暫不清楚,2019第一天就立即要bug fix,真是可喜又可賀。 先評估一下受波及的數據: 發覺就只有2018/12/31號那天變成了2019/12/31,然後2019/01/01開始又好像自動變回正常了。 發覺只有年份不對,月份跟日期沒有問題。 再看看程式團隊開發的程式碼: NSDate * localDate = [ NSDate date ] ; NSDateFormatter * dateFormatter = [ [ NSDateFormatter alloc ] init ] ; dateFormatter.dateFormat = @ "YYYY/MM/dd" ; NSString * dateString = [ dateFormatter stringFromDate : localDate ] ;   感覺也沒有太大問題,一直在抓頭的時候找到 一篇文章 ,問題就出現在formatter中“YYYY/MM/dd”的那個大寫“Y”字。原來Unicode Locale Data Markup Language的說明,大寫Y意思是說 “Year (in "Week of Year" based calendars). This year designation is used in ISO year-week calendar as defined by ISO 8601, but can be used in non-Gregorian based calendar systems where week date processing is desired. May not always be the same value as calendar year. ”就是把一年第一個星期一開始到最後一個星期天之前的日子才算為“本年”,2018年的12/31號是最後一個星期日的第二天,所

[SQL Server] Availability Group 無法正常運作復原筆記 (連案例測試)

案例分析: 前幾天公司一台SQL Server突然掛點導致大停工,筆記一下這一次的經驗及研究。 SQL Server軟體部分由 兩台Replicas 及 一個Share File Witness 所組成,硬體部分兩組Replicas分別位於兩台完全沒有關連的伺服器上。 用Ping確認兩台伺服器 生存 情況,發現Secondary Replica沒有回應,到伺服器房間發現Secondary Replica硬體發生故障 連呼吸燈都沒了 ,可是好奇Secondary Replica當掉為什麼整個服務會死,進入Primary Replica看看情況。 在Primary Replica中: AlwaysOn Dashboard已經沒有回應,並且錯誤,如下: 在Object Explorer中,AlwaysOn的目錄發現Availiability Groups狀態為Resolving。Primary Replicas同樣顯示為Resolving,如下。 再進入Windows的FailOver Cluster manager,發現整個node的選項都不見了,只剩下Cluster Events可以讀取,打開來看,發現Cluster整個掛了 背脊涼涼的 ,並且出現去不到File Share Witness的情況。 解決流程: 由於Cluster已經沒有功能 已經有壯士斷臂的決心 ,以儘快救回服務為前題。 在Primary的伺服器上進入Services,把Cluster Service Disable掉。 然後進去Failover Cluster manager,嘗試 Force Cluster start without a Quorum,成功之後在Quorum Configuration中出現"Cluster is running in ForceQuorum state. brabrabra.." 資料庫還是不能連接。 按照此篇 文章 的設定,手動設定node weight, 全國最大的線上 資料庫上線啦。 重新測試AG設計: 事情發生後我在測試環境模擬了各種情況,結果如下: 總結: 這次經驗令我重新review了AG的技術,得出了以下的結論: AlwaysOn技術真的是Always

[Raspberry Pi] Raspberry Pi 溫濕度監測

前言: 前年跟朋友一起入手了一隻Raspberry Pi 2 Model B, 其中一隻拿來當了備份用的NAS(不要期望當真的NAS, 因為存取很慢), 另外一隻閒置了一年變成上一年的to-do side project,最後也來得及在2017最後一天 拖延症康復了所以 完成了這個project。把難搞到事記筆記一下。 需求: 任何地方打開網頁就可以隨時監控家裡溫濕度變化。 硬體準備: 1. 1張灌好作業系統的16GB micro sd card。 我使用的是 Raspbian with Desktop 。 2. 溫濕度監測器,我使用的是用Arduino弄好的DHT11 Sensor。使用它的原因主要是超便宜,溫度感測是還可以,濕度的話...用來看Delta還是可以啦。 3. 把DHTsensor插到正確的腳位上,如圖 安裝: 我是參考 Jeffery大大的文 章. 先開啟SSH。Raspbian雖然有圖型化介面,但是Model B跑起來實在太慢了,用SSH進入好太太太(回音)太太太多了。開啟教學在 這裡 。 利用SSH進入設備。 安裝python。 根據Jeffery大大文中所說安裝PIGPIO library。 sudo pigpiod 起動daemon。 測試一下剛剛接的sensor是否正確,進入到PIGPIO目錄下,sudo python跑一下dht11.py,有回傳數值代表可以了。 去ubidots註冊一個帳號,使用它的原因是少量sensor是免費的而且介面好用。然後建立一個Data Resource,在Resource中建立Temperature跟Humidity兩項參數。並且取得它們的API Key。API Key是用來上傳資料到ubidots用的。詳細建立的方法在 這裡 。 取得API Key以後,回到SSH介面,因為沒有豪華的Visual Studio,所以我是用sudo nano dht11.py開啟檔案,根據Jeffery大大的修改方式把它修改成可以上傳到ubidots的方式。重點是API Key不要填錯。 修改完以後執行sudo python dht11.py &,如果沒有出現錯誤的話,在ubidots頁面大概會開始看到數據了,大概像這樣, 你沒看錯,濕度真的是很不準... 最後,設

[ASP.NET] 使用Entity Framework Code First 筆記

前言: 前陣前幫公司開發專案打算使用Code First建立資料庫遇到了不少問題,現在終於有點時間在公司好好 再摸魚 認真研究一下,順便記錄起來。關於如何在專案中使用Code First Entity Framework很多神人已經有詳細的教學,我是看 Kevin大的這篇 還有 軟體主廚大的這篇  ,很快已經可以弄出來。 建立資料庫之前最好先設定資料庫名稱,可以在web.config中修改。 第一次使用Code first database先要在 "Package Manager Console" 輸入enable-migrations,如果不止一個DbContext的話要加入參數 –ContextTypeName 指定Db才能繼續進行。建立好Model以後可以輸入add-migration把model加入到pending model,然後輸入update-database -Verbose (Verbose參數令Console直接看到產生出來的SQL)。建立資料庫後如要修改Model也沒有問題,可以在修改後重覆上面步驟更新資料庫,流程如下: update-database -Verbose 可以把整個資料庫重構,這在測試環境當然是沒有問題,可是當在production環境就不行了。上面大大的文章提到可以使用update-database -Script -Verbose自動產生跟資料庫上面diff版本SQL交給DBA去更新,可是怎樣找出跟production環境的diff呢? 我自己是直接改Context檔案裡面的:base("name=Connectionstringname"),然後再輸入一次update-database -script -Verbose就可以得到跟production環境的diff SQL了。 總結: 之前的專案因為有兩個測試環境和production環境,在資料庫結構不停修改的那段時間同步不同環境簡直是場災難,使用自動產生的diff SQL至少可以減少錯誤,而且可以keep track每次修改的History,是個不錯的工具;另外CodeFirst這種開發方式剛開始的時候是有些不習慣,會因為設計不好經常出現錯誤,不過由於資料結構都變成strongly type,在開發上比較

[tensorflow] 在 Ubuntu 16.04 LTS中安裝tensorflow

2018年快樂! 新的一年身為程序猿當然要學學現在最夯的深度學習技術, 不然很快就被 新鮮的肝 淘汰了. 選擇Tensorflow試水溫的原因, 主要是Tensorflow的社群在2017年 最活躍 , 感覺有問題問現場觀眾也比較容易啊. 在Ubuntu 16.04 LTS安裝Tensorflow遇到的問題: 基本上安裝Tensorflow只要跟著 官方教學 安裝就好, 我使用的是native pip, 不使用GPU, 所以要先安裝python dev. 然後pip install tensorflow, 看到successfully. 好像很簡單吧, 打開python, 輸入 import tensorflow as tf , 果然出狀況了, 出現' tensorflow is not defined '的錯誤. 所以再看看教學, 把Optional的部分也裝一下, 再出現錯誤, 這次是 ' tensorflow-1.4.1-cp27-none-linux_x86_64.whl is not a supported wheel on this platform.'   有想過不如giveup去打PS4好了. 爬文以後發現原來要把教學的 sudo pip install --upgrade xxxx 改成  sudo python2.7 -m pip install --upgrade  https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.4.1-cp27-none-linux_x86_64.whl   # Python 2.7 , 簡單來說就是在pip前面加上 python<version> -m 然後就順利安裝了, 出現 'Successfully installed backports.weakref-1.0.post1 bleach-1.5.0 enum34-1.1.6 funcsigs-1.0.2 futures-3.2.0 html5lib-0.9999999 markdown-2.6.11 mock-2.0.0 numpy-1.13.3 pbr-3.1.1 protobuf-3.5.1 se

Popular posts from this blog

[SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗

背景: 公司最近把一套每天有相對大量交易 (之前公司更大很多很多倍) 的系統轉移到SQL Server去,不到一個月交易檔(ldf)已經貼近數據檔(mdf)的size,真的好可怕啊。 身為SQL Server的DBA當然  要替月行道,警惡懲奸  不能讓這種情況繼續下去。 解決方案選擇: 第一個我想到的方法是把Database的Recovery model設成Simple,簡單來說就是不需要交易記錄,對於Insert Delete Update 很少的系統勉強還說得過去,不過對於交易量大的系統來說就不行了,沒有交易記錄萬一資料庫突然往生,總不能用full backup還原然後要User重新輸入一天的交易吧。 第二個方法是定時進行備份。為什麼log大小跟備份有關係呢? 簡單來說,資料庫的ldf檔就是用來儲存Full Backup後所發生的所有交易。如果你從今天從來沒有為資料庫進行過備份, 理論上ldf檔會無限的膨脹下去 ,而且利用Shrink指令也無法把交易檔壓縮。因為沒備份的話就等於ldf檔裡面的東西統統有用,當然沒辦法壓縮了。所以要保持交易檔案的size就是要持續保持備份,在每次備份完了以後自動把交易檔Truncate成初始大小,這樣可以長期保持相對小的交易檔。 所以,最後我選擇了方案二。 實作流程考慮因素: SQL Server的backup model一定要一份full backup再塔配其他備份檔一起使用( SQL Server的備份model解釋在此 ),要達到控制ldf檔案大小的目的,備份可以每天只是Full Backup,也可以是Full->T-log,也可以是最複雜Full->Diff->T-log,我考慮使用那一種的因素主要有以下: 資料庫本身只是約55GB不是太大; 每天交易量不多,每分鐘約10筆交易; 使用者允許少量的data loss,一天Data loss肯定不行; 資料庫只是辦公時間才會用。 我個人認為Backup Plan越簡單越好,發生狀況的時候已經很緊張,複雜的Backup只會令事情更糟。反正今天硬碟實在是太便宜,天天備份幾次也無所謂,因此在儘量簡化備份流程的前題之下,小弟傾向 每天Full BackUp一次,每小時備份一次T-log ,就是Full->

[Windows7] 跨距磁碟區, 等量磁碟區, 鏡像磁碟區之區別

話說前兩天用來備份的USB硬碟無緣無故去領便當了. 大幸的是我一直有好好備份, 資料至少存在兩顆硬碟上, 所以備份硬碟掛了損失也不大(錢包除外). 所以昨天下班以後趕緊去買一顆seagate的2TB內置硬碟回家(感覺USB硬碟還是不太安全), 裝好以後突然想到一個問題: 現在我桌機總共有5顆硬碟, 首先是剛買回來的2TB, 1顆80G SSD, 1顆640G, 1顆320G, 1顆160G. (真多舊硬碟囧), 關於硬碟的部分Windows 7比XP多了一些選項, 應該選那個才對? 讓我自己先分析一下: 那麼零碎的硬碟應該選擇合拼方案為主 關於合拼的方案Windows7有三大選項, 分別是 跨距磁碟區 ;  等量磁碟區;  鏡像磁碟區三種, 應該怎樣選呢? 說穿了那三種其實就是軟體的RAID方案, 硬要改一些好像很簡單又不簡單的中文字 . 其實: 跨距磁碟區 = JOBD,  就是簡單把幾顆硬碟變成一顆大的邏輯硬碟,  資料的存放機制是由第一顆硬碟開始依序往後存放,即作業系統看到的是一個大硬碟(由許多小硬碟組成的)。但如果硬碟損毀,則該顆硬碟上的所有資料將無法救回。若第一顆硬碟損壞,通常無法作救援(因為大部分檔案系統將磁碟分割表(partition table)‎存在磁碟前端,即第一顆)[1] 等量磁碟區 = RAID 0 把資料分散在幾顆硬碟, 存取的速度比較快, 不過壞一顆又是全部壞掉. 鏡像磁碟區 = RAID 1 顧明思義有兩份data, 超安全, 不過由於write的時候也要write兩份, 所以速度會慢. 更詳細的解釋 這裡 [2] 魚仔大有好好的解釋說明三種功能, 小弟就再不說了. 總結: 那我要怎麼辦? 最後我選擇的是.... 什麼都不做 , 80G的SSD留給OS及程式專用, 640G的用來放照片/動畫/影片/影像檔, 320G的用來放文件還有裝一些不重要的應用程式(遊戲啦,遊戲啦,還有一些遊戲之類的), 160G的用來裝音樂還有.......你懂的. 至於2TB的那顆就是當成上面所有硬碟的mirror, 用sync工具即時備份. 為 什 麼 ? 因為JORB不是不好, 不過把那幾顆舊硬碟變一顆有很大的風險, 因為那幾顆碟使用的時間不同品牌也不同,

[SQL SERVER] 找出LOCK方法懶人包

話說休假回公司才不到兩天SQL SERVER就出狀況 Orz 昨天同事跟我說文件系統不能存取ID, 第一件事當然想到是存放ID的資料表LOCK住了. 要查出LOCK方法其實有很多, 以下是小弟歸納的網路資源, 希望幫到大家 什麼是LOCK? 德瑞克大的解釋很詳細:  http://sharedderrick.blogspot.com/2007/12/blocked-lock-connectoin.html sp_lock: 使你對系統中發生的LOCK有深入的了解。它會從master資料庫中的syslockinfo中截取與LOCK相關的大量訊息[1]. 不過我認為由於這個功能的資訊太多, 而且資料沒有好好的做sorting, 所以在危急關頭未必有閒去慢慢看. 在sp_lock會看到spid、dbid、objid、indid、type、resource、mode和status共八個欄位[2]. spid: 連線ID. 可配塔sp_who找出用那些用戶和該連線(spid)有關連. dbid: 資料庫的唯一編號 Objid: 資料表的唯一編號, 可用 select object_id('<table name>') 找到資料表相關Objid 其他的欄位可以在 這裡 找到相關意思. sp_who2 sp_who的加強版本. sp_who主要提供 Microsoft SQL Server Database Engine 執行個體中有關目前使用者、工作階段和處理序的資訊[3]。而sp_who2比較像是sp_who的view, 把sp_who的資料整理得比較好. 小弟經常用它來找出那台PC的發出的process產生了LOCK.  然後毆飛那個user 列出最初導致一連串其它處理序被鎖住的起始源頭(Blocking locks) 很多時候LOCK住的原因是其他的LOCK引發的, 要找出這種關係可以用下面網址的SQL 列出最初導致一連串其它處理序被鎖住的起始源頭 http://www.dotblogs.com.tw/karen0416/archive/2011/11/18/58623.aspx 或者是德瑞克大寫得好好用的SQL http://sharedderrick.blogspot.com