雖然一直對農業保持高度興趣,但我的農業的理解相當不足,於是在四月底到臺中區農業改良場上「農藝入門班」,希望透過這種入門級的課程,稍稍補足一些對於農業現場的瞭解。
在當時的課程中,講師有提到為因應日益缺水的問題及提高雜糧自給率,且稻米自給率超過 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