2013-08-28

陪你讀冊 | 當責,從停止抱怨開始



奧茲法則

當責(Accountability)一詞,是今年過年父親給我的一本管理教科書看到的,但當時書籍內容過於偏向理論、教條式解說,個人就沒仔細閱讀。而這次筆記書籍則是用全球著名小說綠野仙蹤桃樂絲的故事做為破題,舉了許多實際案例,採取引導式發問、問卷自我檢視等實作面向說明如何做好當責這件事情,以下是重點的心得筆記。

一、個人當責
[當責秘笈]如何辨識自己落在水平線下,落入水平線下被害者循環的18個警訊
  1. 感到自己為際遇所困。
  2. 覺得無法控制現況。
  3. 當別人告訴你可以更努力更出色的完成結果時,卻是一場忠言逆耳。
  4. 發覺自己在怪罪他人。
  5. 討論問題時,越來越集中在自己做不到的事情,而非自己能做的事。
  6. 無法面對艱難的問題。
  7. 發現自己成為某些人的取暖對象,這些人告訴你,別人這回又對你如何不仁不義。
  8. 發現自己不願提出深入的問題,以了解自己是否有能力當責。
  9. 認為自己遭受不公平待遇,而且無能為力。
  10. 不斷發現自己採取防禦的姿態。
  11. 花許多時間談論無法改變的事情(例如:職場、股東、政府、景氣)
  12. 發覺自己茫然失措,但

2013-07-26

如何不用root就可以擷取android手機銀幕畫面



從iPhone陣營跳回Android後,一直有個問題困擾某人,就是Android手機竟然不能擷取銀幕畫面啊,莫大的杯具。尋尋覓覓,大概有六種方式可以擷取手機銀幕,但基本上要能支援擷取功能都要被root過,也就是會喪失保固,以下提供不用root擷取手機銀幕畫面到個人電腦PC的方法

自動傳送簡訊抽獎懶人法


圖片來源:hifree


Bill Gates曾說:"他只雇用最懶的工程師,因為懶,就會懂得用腦筋想方設法找出最好的方法來做事情"

相信大家一定有收過類似的活動抽獎簡訊,內容大概是"XX邀您於O/O前輸入數字回覆本簡訊完成闖關就抽機皇"

但一封封回傳浪費的已經不只是金錢,更還有時間。如果,這裡是說如果,你跟某人一樣電信月租費預設較高,每個月都還打不完,可以考慮多寄送這些抽獎簡訊來增加中獎機會。


懶人做法如下,以Android平台為例:

2013-07-18

[埃及、約旦] 流浪隨筆 - 金字塔 Pyramids



金字塔 Pyramids - 堪稱人類文明史上最不可思議建築之最,即使以今日文明仍無法精確了解其建造目的、建築方法。

眾說紛紜,最廣泛的大眾認知金字塔是法老王的陵墓,很合理,就像秦始皇也搞了一個地下陵墓;但人類的幻想總是喜歡加值未知事物,就有學者發現,金字塔高度乘上十億倍剛好是地球到太陽的距離,是一份早在古埃及時代(距今七千年)古埃及人就能精準計算出地球到太陽距離的證據

為了讓自己更快速融入古文明,某人出發前還去買了本《築夢金字塔》,內容主要講述吉薩金字塔群的法老王歷史、詳細介紹、觀測現象、建築方法推論,而其主推的建築方法是外部、內部坡道建築理論,簡單的說,作者認為石塊搬移的方式是由坡道搬運,如此才可能把偌大的石塊從低處搬到高處,並且放置在合適的位置,至於托運的方式根據石塊落點則分別採用內部坡道或是外部坡道兩種方式。有興趣的朋友歡迎借閱。

埃及人一定覺得其他國家的人有毛病,這麼大老遠風塵僕僕、頂著大太陽只為了看那個大土堆,因為如果天氣許可,在開羅市區的任何角落都可以直接看到金字塔建築物,這樣敘述就可以了解這個土堆有多大了吧!

回到旅遊話題

2013-07-11

[埃及、約旦] 流浪隨筆 - 旅之初





 實際走訪埃及後,發現真正令人神往的不是那封存已久的不可能建築古文明,而是那熱情的沙漠民族精神


最近埃及動亂頻繁,不少朋友問過曾去過該地背包旅行的在下,現在去自助旅行到底安不安全?一句話:"'放心吧!",剩下的故事,聽小的娓娓到來。


所有行程:



2013-05-23

[troubleshooting] HTC Butterfly 音樂app滑動檔案清單直接跳出

Question:用HTC Butterfly發生一個狀況,在進入原生官方app "音樂",進行瀏覽檔案的時候,直接因不明原因馬上跳出app.

Answer:砍掉擴充SD卡裡Download目錄下的檔案即可。

原因研判:

  • 下載的檔案裡可能有些格式損毀,因為某人喜歡抓到一半懶得等就不抓了
  • 檔案太多,超過index索引範圍

2013-05-20

網路爬蟲實作與原始碼分享 Web Crawler implementation & sharing

心血來潮將之前寫的網路爬蟲Web Crawler稍微重構後開源到Github上,以下是簡單的設計介紹及使用說明。

Github:https://github.com/A-Ho/Crawler

簡介:
  • 採link by link的方式大量截取網頁資訊至用戶端
  • 可自行設定探勘深度
  • 支援多線程(multi-thread)
  • 資訊存取方式以Cobweb.java作為abstract class,分別以memory、DB、disk三種資料存取來實作。(後來才知道用到了template method pattern)
  • 支援單獨檔案下載

2013-05-15

不要再Cost Cutting,創新就隱藏在細節裡


偶然機會,跟一個原本在做NB的代工大廠(對!就是俗稱的毛三利四),而現在努力想切入伺服器市場(後PC時代來臨,NB市場已經徹底萎縮)的台灣硬體廠商有交流機會。過程中他們介紹未來要推出的伺服器,雖然個人是很純的軟體RD背景,完全非硬體出身,但聽介紹、看了機器採用外部廠商的基礎元件和整體產出,倒是對所謂的業界俗稱ODM/OEM有更深一層的了解,也了解為什麼毛利率為什麼老是這麼低(雖然台灣軟體業好像也沒好到哪去)。

2013-05-11

Perfect chasing needs streetwise-leadership

我相信在追求完美的道路上是永遠沒有止盡的,但完美的達成需要團隊的完美配合。

如果領導人無法有願景的看到目標、甚至無法體會或理解路途上會歷經的坎坷,那注定無法成功。

2013-05-06

公有雲,易上手?!

2010年起,中國大陸的IaaS多到令人詫異,讓人不禁懷疑所謂的雲計算真的有這麼容易實踐嗎? 提供幾個思考方向:

名詞解釋:
1.主機代管: 資訊服務商將自備機放到IDC,由IDC業者提供機櫃空間、電力、頻寬。
2.主機租用: 資訊服務商為節省成本,不自備機器,向IDC業者租用。
3.VPS: Virtual Private Server。一般來說,對外提供資訊服務的主機,機器使用率往往不會滿載。所以大概在五六年前開始有了這個概念,透過虛擬化技術,在單一主機上虛擬多台作業系統,如此可將機器使用率最大化,IDC業者也可透過這樣的方式以最精簡的機器提供相同給相同數目的資訊服務商。
4.雲主機: 也就是IaaS,上述三種方式都是透過單一主機提供資源,所謂雲計算就是將運算能力、儲存空間、網絡頻寬等等所能想到的原生硬體整合成一個資源池,再由雲平台去做統籌分配,統籌分配管理的雲管理系統業界稱其為CloudOS。

發展現況:
基於以上幾種業務再去分析,中國大陸這麼多的IaaS基本上都有一個共同的特點,就是他們原先就是IDC業者,且早已同時提供了1~3項的服務。基於這樣的企業基礎,加上雲計算又這麼熱門的市場,當然所有業者都開始往第4項IaaS靠攏。

問題是,IaaS有這麼好實作嗎?

2013-05-01

[Weinberg - Quality Software Management][Book 1][Ch 7]

書名:溫柏格的軟體管理學,第一卷,第七章
Title:把穩軟體的方向

概要
軟工發展多年,已有許多方法論可協助軟體開發,例如waterfull process model,或是近年很流行的WBS、agile,無論如何,這些都只是方法,最重要是執行專案的是人,而不是方法;所以首先我們要了解純然規律性的方法不能完全適用這個道理,更糟糕的是方法論往往為扼殺創意,當然,保守的作法也往往比較安全。

方法論講了好幾頁,都不作者要表達的重點,最後他點出人為決定才是對專案造成關鍵干預且會脫離方法論造成多種不可見狀態。所謂不可見狀態,舉例說明如下:
  • 寫出來的程式有大量難以修正的錯誤
  • 專案成員對不該有自信的事情卻充滿了自信

2013-04-24

[Google App Engine] 建置與部署教學


Google App Engine(以下簡稱GAE)簡介
想建置自己的網站系統卻苦無賜服器跟頻寬嗎?GAE提供一個 java/python framework 的 run time environment,於 google 端配置有container,只要確保你的開發程式符合container規範及配置檔案即可即時運行於internet上。

難易度
適合有使用過 Eclipse + Java + Jsp + Servlet 等技術,建構過網頁系統人員。

Step 1. 建置開發環境
厲害一點的人其實不需要IDE就可以做事情,但工欲善其事,必先利其器,時間就是金錢,個人還是搭配一套坊間最知名的Eclipse作為開發工具。
個人整體作業環境是Windows 7 64bits + Eclipse Classic 4.2.2 (JUNO) + jdk1.6.0_43,細節怎麼安裝不贅述,重點是GAE。

2013-04-11

問出技術深度

會問自己到底做對了沒有才是重點:
1. 你的目標客戶在哪?
2. 你的產品到底優勢在哪?為什麼客戶要選用你的產品?
3. 你的技術強度到底夠不夠?競爭對手要用多少時間可以超越?
4. 你的產品到底賣多少錢了?要多久時間可以回本?
5. 你的客戶數現在有多少?你自己公司的員工有在用嗎?他們自己願意花錢購買嗎?

要如何了解您所帶的技術團隊強度,不要隨便就被幾個技術名詞忽悠,導致一個其實很簡單的技術被過度強化。嘗試問以下問題: