敗入人生第一支鋼筆-Lamy AL-Star 恆星系列

這幾日突然很想買一支鋼筆來練字,然後就在「PTT 文具板」查找關於適合鋼筆新手入門的敗家資訊。嗯嗯,大多數版友推薦大約1千元上下、Lamy 系列的鋼筆最適合新手入門練字。

記得小時候對鋼筆的印象就是白金牌,上百元一支就已經覺得超級貴。然後總覺得筆尖蠻尖銳的,用力寫在紙上甚至會刮紙,當然,這也是因為拿筆姿勢不正確的關係啦。然後印象中,如果按著吸墨器想把墨水吸上來,總會濺得手與紙沾上墨水,反正好像那種精巧細緻的寫字功夫很不適合我。 !^^

不過真的就是很想要買支鋼筆,要靜下心來好好寫字。且爬網作了功課後,我可以說最聽網友們敗家的意見了,所以前兩日就到位於北市瑞安街的「小品雅集」買了 Lamy Al-Star 號稱「恆星」的鋼筆。
Lamy A-Star 恆星系列鋼筆

繼續閱讀 »

食記&筆記-瑞安街的龍門客棧&小品雅集

今天近中午時,開車到位於瑞安街的「小品雅集」打算選購我人生中的第一支鋼筆。不過還沒吃飯,所以就在位於瑞安街安東市場旁的「龍門客棧」吃個水餃滷味。
龍門客棧@瑞安街

雅品小集@瑞安街

繼續閱讀 »

2016_4.14-15_彰化軟件兩日教學行

因為農曆年後彰化某國際鞋業代工大廠購買了 EA UML 工具數百套,同時也針對 RUP (Rational Unified Process)所提出的 4+1 View 請我們規劃三天的軟體教育暨工具使用的課程。

我負責前兩日的課程,授課日期就在上星期四、五 (14/15)。因為一大早就要上課,所以乾脆前一晚就開車下彰化,並先於彰化市區—福泰商務飯店訂房住宿。

軟體教學@寶成鞋業國際

上個星期幾乎全是下雨天,尤其星期三傍晚當我開車到新竹路段時,那個暴風雨下得超級大,加上天色已暗,有夠難開。所以大約開了兩個多小時晚上7:30才到了彰化市區,馬上就入住飯店內。下圖是隔天白天時拍照的。
彰化市福泰商務飯店

繼續閱讀 »

簡單開箱-Dyson V6 Fluffy Absolute 無線吸塵器

前年購買的-Electrolux Z1860 Lite II HEPA 吸塵器,只是洗一下集塵盒後,竟然就裝不回去 (無法密合),導致整個吸力大降,還會排出熱風。因為一時找不到保證書 (應已過保),想說維修也要不少錢,所以這次乾脆就購買貴森森的 Dyson 系列吸塵器,一次攻頂。

作了功課,爬網參考了不少的開箱文,決定就買去年中旬推出的 V6 Fluffy 無線吸塵器。我是買露天拍賣這家-V6 Fluffy SV09 Absolute +過敏組 8支吸頭 雙主吸頭,再加買了收納袋等,價錢共約2萬3千元。沒想到賣家就住我家附近啦,而公司也在永和中正路一處豪宅內,直接去取貨付現比較方便。
Dyson V6 Absolute 無線吸塵器

我買這一款型號為 V6 Absolute Fluffy,其實是美國的水貨,但店家有保固一年。而台灣的公司貨一般型號稱為 SV09,大概價差有3千元,而且還只附一個主吸頭。呼,Dyson 的吸頭超貴的,單買動輒兩、三千元以上,所以乾脆一次就買齊常用的吸頭。
Dyson V6 Absolute 無線吸塵器

繼續閱讀 »

[文摘] 工程師12年工作經驗-能解決問題的不是工具而是思考

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

這一篇關於軟體工程師綜合了12年的工作實務經驗,有感而發所自省整理出的12條工作經驗。

他寫的每一條教訓與體會,正是個人在這個軟體業界全都碰過,但卻少有人真正能像該位工程師這般得以內省而後想改變自己的。

嗯,業界的通病大概是這樣的情境:

  • 管理者想要找工具或方法來解決軟體開發的問題,但卻不從根本做起。
  • 開發人員總會說,我想要進步,但公司文化與環境不允許,所以我只能自艾自憐。 (其實自己本身早已同化而不自知)

記得啊~ 以下12條教訓不是口號,而是確實要從過程中實踐與體會。「獨善其身後,才得以兼善天下。」

  1. 工具不能代替思考。
  2. 除非管理小組能夠真正懂得敏捷「轉變」的價值,否則它就不能發揮作用。
  3. 學習需要一個安全的環境。
  4. 每個人都可以成為領導者。
  5. 架構師去寫代碼往往能作出最佳決策。
  6. 改變需要勇氣。
  7. 建立信任的關鍵是言行一致。
  8. 成功的結對程式設計與良好的協作相關。
  9. 多模式思維促進更強大的結果。
  10. 認識到每個人都有不同的優勢。
  11. 終身制學習。
  12. 積極的影響迸發幸福感。
案例研討-關於客戶單位維修作業流程的系統分析

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

這是月初的授課—「系統需求分析與整理」,其中一位上課學員拿他們的實際案例提供參考的。

先來瞧瞧這張看似很複雜的作業流程圖,主要是要描述當客戶單位提出報修需求時,維修單位的報價與維修的相關作業活動。

圖、原稿—客戶維修報價作業流程

圖、原稿—客戶維修報價作業流程

這是一張典型 SA 所繪製的業務流程 (business process)圖,是否使用 UML 語法來表示,那並不重要。最主要的問題是,大多單位往往都認為這類業務流程的表達,必須要描述得很「精確」,才可以轉移到實作的階段。所以為了要能取得「精確」的結果,就需要不斷地開會與確認 (還含時常爭執各據的論點),秏上個把個月才能有產出,然後再轉移到實作階段。

但是無論再如何精細,我發現到有一個相當有趣的現象,在這類環境下的 Programmer,往往都還是覺得不夠精細。

越是想表達得精確,Programmer 越會嫌不夠精確!

這就是典型的瀑布式 (waterfall)系統分析。這類所謂「精確」的業務流程圖,耗費太多在需求分析的時間,且由於描述了太多細節,反而讓實作寫碼不容易抓到適切的焦點,因而導致 Programmer 不知道如何寫出較具「彈性」可包容變動細節的程式碼,當然相對日久也就會把不精確的細節當成是一種無法 Coding 的藉口。

所以,上述如此好像「鉅細靡遺」的設計圖,主要的問題在哪裡? 其實簡單的說,它早已違背了軟體設計至高無上的原則—封裝 (encapsulation)。

  • 把資料細節呈現出來 (資料導向的思維)。
  • 設計圖內描述了企業邏輯 (business logic)。
  • 過早把資訊系統角色帶入。

繼續閱讀 »

第 11 頁 / 共 243 頁« 第一頁...67891011121314151617...304050...最後一頁 »