搬家公告

現在 Gelis 新的文章會以點部落的為主，下面為新的網址：
http://www.dotblogs.com.tw/gelis/
兩處新舊文章都歡迎各位能夠多多支持。感謝各位啦 :)

留言

張貼留言

這個網誌中的熱門文章

再談XAML與WPF

圖片
撰文：吳俊毅 時間：2009/6/11 在筆者先前討論過XBAP應用程式後再一次回到WPF的主題，在這個章節中筆者要說明XAML與WPF之間的關係，讀者先往下看幾個主題。 1. 再談XAML 什麼是XAML呢，XAML是(eXtensible Application Markup Language)的簡稱，XAML發音為”zammel”，而XAML為一種標籤語言，關於這個部分市面上許多書籍都已經講過太多了筆者快速的帶過就好，簡單的說XAML承襲XML的Well-Format文件的所有特性，在這裡微軟透過XAML描述並呈現WPF應用程式的外觀，它可以設置.cs的後置檔，程式的事件與運算邏輯可由後置檔案完成，WPF可在<Window>標籤內的x:Class=”命名空間.類別名稱” 如下： <Window x:Class="WpfHelloWorldApp.Window1"> </Window> 當然XAML檔案不一定要有後置檔，如上程式若去除掉x:Class=”WpfHelloWorldApp.Window1” 的敘述即表示沒有後置檔案，而通常沒有後置檔的XAML程式碼通常稱為loose XAML(鬆散的XAML)，這種檔案通常只是將XAML當做文件來使用，如XPS Document或WF的Flow Document文檔等，而XAML檔案執行時會預先被編譯成BAML(Binary Application Markup Language)的二進位直接檔案，但它是一個副檔名為.g.cs的檔案，在使用正式版本的Visual Studio IDE工具後您通常無法在檔案總管中察覺這個檔案的存在，若您在InitializeComponent()點選右鍵a”移至定義”所看到的程式內容便是IDE工具(auto-generated)自動產生的BAML內容，它會在obj\Debug 下產生，而同樣是一個繼承Window的類別，只是會多實作IComponentConnector介面，在InitializeComponent() 中會透過System.Windows.Application.LoadComponent()方法將XAML的內容讀取進來，筆者擷取一段BAML範例內容如下： public partial class Window...
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容

占空間的Google Chrome暫存檔

圖片
在一次使用CCleaner清除系統的垃圾的時候發現，怎麼Google Chrome怎麼有220M的網際網路快取資料？ 這時突然意會到，平時都只記得清除IE的Temporary Internet Files，卻忘了Google Chrome也是瀏覽器，一樣會產生暫存檔案，還有Google Earth產生的暫存檔居然更高達688M… Orz 因此突然間也非常好奇這些暫存的資料夾的路徑到底在哪裡呢？因為我們知道在Windows Vista/7 之後使用者資料已改在c:\Users 的下面，由於IE的是在"C:\Users\gelis\AppData\Local\Microsoft\Windows\Temporary Internet Files" 、所以我想應該也在這裡附近。果然讓我找到了！ Google Chrome : C:\Users\gelis\AppData\Local\Google\Chrome\User Data\Default\Cache Google Earth : C:\Users\gelis\AppData\Local\Google\GoogleEarth\models 可是突然間又發現Google Earth的資料夾居然是空的！這讓我很疑惑，明明掃出688M，究竟這些檔案是在哪裡呢？筆者的求知慾又非常強烈，每當發現問題如果不找出來是不罷休！因此常常熬夜只是為了找一個問題… 後來上Google才發現，原來我找錯位置，Google Earth的暫存資料是存在LocalLow的下面！不是Local的下面，所以路徑應該是如下： C:\Users\gelis\AppData\LocalLow\Google\GoogleEarth 而且是單一檔案"dbCache.dat"，總算解了疑惑 ^_^
閱讀完整內容