雖然一直對農業保持高度興趣，但我的農業的理解相當不足，於是在四月底到臺中區農業改良場上「農藝入門班」，希望透過這種入門級的課程，稍稍補足一些對於農業現場的瞭解。
在當時的課程中，講師有提到為因應日益缺水的問題及提高雜糧自給率，且稻米自給率超過 100%，因而鼓勵轉作旱作作物，這當中包含大豆。於是，上完課後，我一直覺得可以試著栽種食用黃豆，一來是進入農業現場，親自「體驗」農業的現況（我自認我得透過這種方法學習，速度才快）；二來是非基改黃豆是政府主推的經濟作物，也算符合轉作的要求，一樣可請領轉作補助；其三則是因為黃豆相關副產品眾，市場需求較高，較不用擔心日後的銷售問題。
為了接下來的大豆栽種計畫，我買了幾本農業改良場出版的專刊，分別是《大豆栽培管理技術》[PDF]與《大豆有機栽培》[PDF]。兩本書都各有談到栽培、管理的知識，但對於農業門外漢來說，還是搞不太懂究竟如何實際操作。舉例來說，在《大豆栽培管理技術》一書中有提到須整地作畦，所以我一直以為要作畦，因此一開始在跟家人討論時都是說要請人開農機進來整地作畦，也一直朝這個方向規劃。
平常已經習慣使用 Terminal + VIM 的工作方式，直接連線到遠端編輯檔案，對我來說，大概就是把 Terminal 環境設置好，以及使用 SSH Key 直接登入主機，就省去不少麻煩。雖然這樣的工作方式對我來說很方便，不過最近需要跟一位前端設計師合作套版，思索了一下，覺得這樣的工作方式應該會造成設計師困擾，因此就開始找尋可以直接在本地編輯檔案的方法。
當然，一般來說，用 FileZilla 或 WinSCP 這類工作就可以用透過 SSH 登入遠端主機，並把遠端檔案下載到本機，在編輯後再重新上傳到遠端主機，這樣的工作模式其實也沒什麼不好。但，考量到現在使用 Sass/SCSS 的前端開發環境大多需要結合 gulp 同時開 node.js 執行開發環境，以便讓開發者可以看到即時的 Sass 編譯結果，所以還是需要讓前端設計師開始學習新的協同合作模式。
Views 是架設 Druapl 網站必不可缺少的模組，此模組提供一個簡便的介面，讓我們可以自訂要從資料庫擷取哪些資料來呈現，以及用什麼方式來呈現。以往自行架設開發系統時，對於特定單元頁面，要從哪個資料表擷取資料、要顯示哪些欄位內容，都必須自行撰寫程式，而 Views 則簡化了前述的工作。
Views 除了可讓我們決定要呈現哪些資料欄位外，亦可設定要依哪種方式進行排序。通常我們會需要依內容標題排序，若內容是英文，排序結果會依字母排序，但如果內容是中文呢？很可惜，中文內容其實是依 UTF-8 的編碼來排序，所以並不是依筆畫順序排序，而是依該中文字在編碼表的順序來排的。
情境說明
Vuforia 是一套可用來開發 AR 擴增實境應用的 SDK，並且內建在 Unity 2017.2 之後的版本，算是易取得、易使用的開發工具。此次的專案是以 Unity + Vuforia 開發 AR 應用，但考量到使用者可能是在山區使用，因此規劃將所有需要的 3D 模型都直接封裝在 APK 裡面，造成 APK 超過 100MB。一旦 APK 超過 100MB，就必須拆成 APK 與 OBB（APK 擴充程式檔）。
當使用者從 Google Play 下載應用程式時，會同時下載 APK 與 OBB 檔，所以對終端使用者而言，操作上並沒有太大的差異。對以 Unity 做為遊戲開發工具的開發者而言，由於 Unity 內建支援將 APK 拆分封裝的功能，開發者只要在發佈前勾選「Split Application Binary」，Unity 會將主要的程式封裝成 APK，而把相關需要的資源（例如貼圖、模型、影片等）存成 OBB，所以這算是遊戲開發領域常用的技巧。
大約八、九年前，我曾經跟隨學術參訪團到上海。正因為「學術參訪」的特殊身分，除了拜訪幾所大學院校外，還見上幾位上海官員，聽聽他們對於中國發展的看法、以及上海的未來願景。
不過，這不是主題。
主題想談的是，在不同的文化框架下是如何看待與使用外來語，以及使用外來語的廣告標語該如何融入文化。
在文定宴之前，我傳一封簡訊給同學、朋友們。內容如下：
親愛的同學/朋友們：
我有一個夢想，就是想讓更多人重視「文化」，認知到「文化」的存在；雖然我到現在還是不知道怎麼做較好，但我一直試圖推廣文化，像是平常辦理旅遊活動，陪大家一起旅遊，也認識當地文化。
在我的婚禮當中，我心想既然辦個婚禮本來就要花這麼多資源（錢啦），何不好好利用呢？！所以我就把「推廣文化」當成是核心的主軸來設想其中的細節，例如挑選「米」來取代喜餅、請我爸刻了一個囍字章，以及其他當天會看到的小東西等，目的就是想讓你們各位能開心地參與婚宴、享受當下，甚至是透過這個整個呈現的結果來認識我和宜君的生活、幫助我們的朋友，因為有你們才有今天的我。也正是因為你們，所以我才有屬於我的文化。
我猜想，就算我請大家不要包禮金給我們，還是很多人在盤算，反正當天就是帶到現場，再找機會塞給我們就好。換成是我，我也會這樣子做。可是，我總是覺得婚宴的存在，只是讓各位朋友們能夠一同分享我的喜悅，對於大家除了遠道而來之外，還要外加一包禮金，實在是讓我覺得造成大家太多的負擔了；我甚至想說，遠道而來的朋友，就請你們以交通票據來取代禮金吧，那些心意我真的收到了。
近期在執行的電子商城網站，因有填寫地址的需求，因此稍微研究一下 Address Field 模組，並擴展其功能，寫了一個 Address Field Taiwan 的模組（目前還是 sandbox 階段）。
這模組主要功能就是將地址格式改成「縣市」、「鄉鎮市區」、「郵遞區號」、「地址」等熟悉填寫的格式，並且將前三者設為互相連動，也就是只要下拉選取縣市、鄉鎮市區後，就會自動填入對應的郵遞區號。
在台北定居那幾年，無論在職場還是社交場合，多數人似乎都習慣以英文名字相互稱呼；不過，我通常不會報上英文名字，說是習慣也可，說是刻意也行。這其實也不值一提，只是今天突然想起自己英文暱稱的演進，便想著要書寫一番。
最早的英文名字，是在小學參加英語補習時，那時的老師幫我取名為 Frances（有這麼少字母嗎？小時候怎麼覺得這名字落落長！）。為什麼是這個名字？我也不知道！反正，上英文課就習慣叫英文名字，我也需要有個英文名字，然後就剛好被指派這個，至於老師為何覺得我適合這個名字，我也不知道！
基於對英文的「不」喜愛，補了一段時間後就沒再繼續了。再次進補習班已經是國中的事情了，那時報出自己的英文名字，孰知當時的老師覺得太拗口，遂幫我改成 Frank，說是比較簡單、好記。這次的英文名字總算有原因了，有進步。
Pages
Recent comments