《約耳續談軟體：探究軟體經營的根本實學》觀後感（After reading of more Joel on software）

基於現任軟體PM的角色，同時也自己下海寫一些東西，對於軟體的切入角度，有了許多不同的認識跟想法，剛好同事有天提到了《約耳續談軟體：探究軟體經營的根本實學》(已絕版)，就跟同事借來，每天抽點時間把它啃完之後，也留下一些自己的心得跟記錄，也許再過一段時間回頭來看，也可以知道自己實證了多少。

無法標準化的職務 ( Unable standardization duties -- PM)

以工作來說，每個人或多或少都會希望能夠依循著特定的SOP來執行任務，如此一來，除了降低自己的風險外，同時也能以最短的時間讓自己能夠融入工作群體當中，但是，有一個工作職務，很多人有興趣，但是也有人不願為之的工作，那就是 ─ 人見人愛(哀?)的PM吧？現在就回頭來看看這份工作為什麼很難有SOP吧？

其實PM這個詞經常會被混用，先不論是產品或是專案的管理，基本上只有戰線長短的問題，要處理的面向不會因為產品或專案有太大的差異，除非是既有的成熟產品，同時接近它產品周期的尾聲時，才有可能只剩下維護的既有工作，對於PM來說，第一件要認清的事就是，這個專案(產品)究竟是從何而來？表面及背後的實質目的為何，如果這點沒有先認清的話，基本上PM之路應該會走的很艱辛。

產品定位的取捨(Making Product Position Trade-offs)

從以前的工作經歷，直到如今的工作崗位，經常會看見一個產品從發想、勾勒、草創、堆疊、驗證、測試、推出市場或夭折......，時間一久，反而印象大多是中間的過程、摩擦、協調、消弭認知上的差距，直到產品漸漸地成形，最後看見成品時，反而沒有太大的驚喜及衝擊，或許也是因為自己對於產品本身已經熟到不能再熟了。

經過了這些時日的體會(折磨？)，愈來愈能夠理解為什麼產品一定要先推出市場，因為無論你是採取那種方法開發出這個產品，直到推出那刻之前，你永遠都無法預期目標族群的喜好，雖然可以透過很多前期的調研報告、媒體曝光來努力地嗅出一絲機會，縱使如此，也要看你最終推出的產品的成本、價格、功能及市場成熟度及消費者喜好而定。

盲目追求新技術的風險 (Risks of Pursuit the New Technology)

因為自身工作內容的轉換（不務正業？），所以對於一些系統架構和最適性的選擇有些感觸，所以才衍生了這篇文章，不過，這邊我絕不是要評論技術的優劣與否（我自論也沒有這個能耐）只是單純在風險評估上，進行一種論述，當然，這也包括了很多不同面向的選擇，或許下次當你也遇到類似的問題時，也能夠認真地想想是否該這麼做！？（前提是......你得是個有評估能力的決策者）

Update Linux Server Notes

最近自己常用的Linux Server的OS（ CentOS 6 ）又更新了！每次更新都會自己測試一下，是否自己所管的Server也能夠安穩的升級上去，或者，是有那些東西要特別注意呢？

有些Server可能是不能整體更新的狀態（單純指不能全系統更新，若是遇到有重大漏洞的弱點更新，不管怎樣還是非得更新不可），所以就簡單整理了一下在Linux Server上更新時的注意事項，一方面做個記錄，另一方面也提醒自己一下。

架設網站的硬體評估（Evaluate a website hardware required）

近年來行動通訊大行其道，想當然PC產(傪)業（Desktop、Notebook）最近也陷入了一片低迷，雖然說它們均有行動通訊上其不可取代之處，甚至在很多行動痛訊的應用上，其背地裡還是靠著傳統PC產業在支撐，不然雲端是能夠雲到那兒去呢？再怎麼樣還是在某地的一處機房裡存在。

但是對於整個產業來說，也很難不緊張，畢竟少了消費端的支持似乎還是很難支撐的下去，不然就是轉型成服務業？這問題應該再過些時日就會看出端倪，不過，我們還是回頭來看看，若是想要自己架個網站，在硬體和網路頻寬的部分可以怎麼評估吧？尤其實在這個似乎人人都可透過網路創業的時代（其實門檻沒有那麼低吧？)

加強WordPress的安全設定 （To Strengthen the Security Settings of WordPress）

自從最近發生了有關Wordpress的安全性疑慮之後，其中包括暴力破解法猜測管理者密碼（或許可以透過登入錯誤延時的外掛來阻擋一下，例：Limit Login Attempts），外掛：Super Cache和W3TC的弱點，應該相當多有使用它的使用者，無論是主動或被動地都得進行一些安全性的防護設定，畢竟這個免費的BSP平台，早已擄獲了很多使用者的心，甚至很多商業團體的網站，也是透過這個平台來進行架設，所以，一發生安全性的疑慮，大家無不繃緊神經嚴陣以待。

其實在WordPress的官方也有提供一些有關安全性的建議，或是許多外掛（Plugin）中，應該也有許多外掛是與網站平台安全相關的功能，我們就可以藉此瞭解到有那些項目是我們應該注意的重點，甚至透過它來擴大檢視手上其它網站的安全性是否足夠，雖然說不同平台的架構也有所不同，但是對於安全性的觀念，仍有許多共通之處。

修改網路連線及使用者群組（How to Modify the Network Connection and User Groups）

對現在大多數的使用者來說，早已都習慣一開機就能夠連上網路，對於家用使用者來說，依架構不同，也有其不同的連線方式，要不就是透過IP分享器（或是直接進入Modem中改成硬體撥接）、或是在電腦中設定一開機即進行撥號連線（PPPoE)，若是使用Cable Modem的使用者可能一開機就是直接透過DHCP的方式來連接上網際網路，除非你是固定制的網路使用者，不然，應該也很少會去設定什麼IP相關的內容。

不過，對於企業網路，或是特定型態的網路架構之下，或許就會看見DHCP和固定IP混用的狀況（通常在企業端或是小型工作室較常見），這時候對於網路管理者來說，若是沒有中央控管的環境(如AD或辦公區跨不同樓層)，這時候若是因為某些特定需求（例：將使用者改去特定線路，為了分流或是封鎖特定服務），這時候若是想要在最省力的狀況下，進行大規模的網路連線方式修改，或是使用者群組的設定時（通常是降權），就需要透過一些小小技巧。

封鎖特定服務的方法及必要性（Block Specific Services and Necessary）

你正在倒數計時嗎？想想今天應該是相當具紀念價值的一日，因為在2013/04/08這一天MSN（Windows Live Messenger)即將走入歷史，很多平日需要以它做為溝通的工具的人，應該都已經進行了替代方案的解決方式了吧！無論是你是選用整合進Skype之中、雙開Skype、放棄它（回到電子郵件的時代、朋友已不上線）或是直接透過其它的即時通訊軟體（例：Line、Facebook......等）。

基本上只要能夠與原先的聯絡人進行即時的互動和溝通，找到自己適用的即可，畢竟這些工具是我們使用它，而不是讓它來喧賓奪主，不然，經常都會發生被特定軟體所制約狀況。

面對個資法的各項挑戰（The challenges of the Personal Information Protection Act）

我想最近IT人最常聽到的議題，不外乎就是個資法的相關議題，自從去年（2012）10月實施以來，我想除了特定行業之外，對於很多同業來說，似乎還沒有這麼切身的感覺吧！？不過，一旦開始瞭解它所包含的內容之廣，就真的很難一派輕鬆的模樣，尤其是現在如果真的出了什麼狀況，舉證責任可是落到了企業本身，並非是自身權益（可能）遭受侵害的一般個人，光是這一點就夠讓人頭大。

企業端若是想證明已善盡保管之責，進一步來降低自己的風險，其實也沒這麼容易，因為要面對的問題有很多，從內部的反彈、流程的合理性、實際執行面的彈性，甚至還會造成時效上的延宕，但是又不得不正視個資法的限制，畢竟現在是於法有據，更何況在預算有限的條件限制之下，或許最有效的是從「人」下手，不過這似乎又會牽扯到企業文化、權責限縮，甚至會造成更多不必要的內耗產生，或許要在兩者之間取得一個平衡點，也不是這麼容易之事。

這或許就是IT人今年不得不面對的現實，這篇就來談談面對個資法時，可能會遇到的各種挑戰吧！或許你會有更好的因應方式？

資料處理的技巧（Skills Of Data Mining）

自從接手了各式不同的工作之後，畢竟時間是有限的，勢必會壓縮到某些原本關注的內容，但是對於很多事情的處理方式，仍舊是充滿興趣，尤其是當自己開始經手各式各樣不同的需求及解決方案之後，漸漸地就會發覺一件事：「雖然人工（工人？）智慧可以解決大多數的問題，但是以現今的時空背景之下，空有資料、數據，基本上並不能幫你看見契機（危機），甚至對於某些人來說，反而就會變成裹足不前的藉口。」

此話怎說呢？基本上資料的處理方式有很多種，最常見的就是進、出而已，對於某些分工更細的體系來說，甚至只有進或出，不過當資料累積到一定數量或者它是屬於那種會自然成長的資料（log、進銷存資料......等），這時候對於大多數的公司來說，就會開始採購軟體（用Excel也算）或各式系統（例：ERP、CRM...等）來進行管理與整合，希望能夠透過它，協助人們來快速地整合某些已知型態的資料內容。

但是問題往往沒這麼單純，如果你想得到未知的資料型態呢？你會怎麼做？

電子產品的採購要領（How to purchase electronic products）

又到了年終除舊換新的日子，縱使大環境的時機不是太好（從很多數據上都可以看出端倪），不過最近在各通路或電子平台上，應該都有不錯的銷售成績，對於廣大的消費族群（宅宅？）來說，基本上也很難逃離各大品牌鋪天蓋地的行銷和文宣（其實是想在最後一季，拉一下今年低迷的業績），所以大多數的消費應該還是會落在行動設備（智慧型手機、平板）、電腦（桌機、筆電）或其它電子產品（娛樂裝置、影音家電）上。

去年，其實也曾經討論過《採購、議價與潛在因素》，當時主要是站在企業或公司的角度來談論這個話題，現在，我們就回到一般個人的角度來看待這個問題，消費性電子的市場其複雜程度絕對不是商用市場可比擬的，因為出發點和基本條件就有極大的不同，更何況，消費性的電子產品，改朝換代的速度之快，也絕非商用市場追趕得上。

相對起來商用市場的採購似乎相對單純許多，甚至也有很多廠商會主動提供協助。大家回頭想想，如果你想要買個新出的電子產品，除了廣告、文宣或是上網查評測或單純比價之外，基本上也只能夠聽現場銷售業務的一面之詞來判斷吧！？一有不慎應該又會掉入衝動消費的懊悔當中，所以，我們就來談談，對個人來說，究竟要怎麼樣來採購電子產品呢？

數字管理的盲點（The blind spot of managing by numbers）

還記得以前學生時代做報告，每次都得要想著怎麼樣把數字變成表格？怎麼呈現？才不會讓它們看起來很亂，或者是讓他們能夠藉此表達出一個較為具體的意義（當然也有可能是各自解讀、表述），當然，當時的數字可能是實驗數據、公開的統計數字，甚至有可能是自己市調的結果，直到出了社會之後，才發現到原來很多數字，重點不是怎麼呈現，而是要去瞭解它背後所隱含的意義，甚至很多人都是藉此來闡述著一些他們不願多說的事情（真相）。

其實，這就像是這幾年曾經吵得風風雨雨的KPI一樣，不過，我沒這麼利害能夠說出什麼大道理，只是針對自己的一些個人觀察跟想法分享，同時也警惕自己不要成為被數字操控的人。

產品開發的門檻 ─ III（The threshold of the product development / Target groups）

在談過產品型態和產品定位之後，對於產品最後的去處，也是為什麼我們要開發這個產品的最終目的，就是將它推給需要的人，或者是能夠達到更高層次的需求、被需要的人發現（雖然這一點在新產品充斥的現在，有著相當的難度就是），甚至是創造出需求，其實這對於每個商業經營者來說，都是一樣棘手的課題。

不過，對於每個新產品的初期發想，最初應該都是由老闆、專案經理或是特定人士從自身需求轉化出來的，當然也有不少是經由觀察得到的靈感，不過這其實也是危險的開端，因為他們真的是這產品的目標族群嗎？或是以為自己目標族群？像自己的目標族群有多少人呢？這些其實還是需要經過一定程度的驗證，當然，有人曾說過：「你只要能夠滿足1%的人，就足以支撐你這個產品」，但是你真的能夠抓到那1%的使用者嗎？還有，你真的知道你的目標族群是所有人的1%？還是極為小眾的1%呢？否則產品再好，或許也很難看出它實際的價值，這就是目標族群的一場戰爭。

產品開發的門檻 ─ II（The threshold of the product development / Product Positioning）

前篇提到產品開發時的產品型態，接著就來談談產品定位的差別吧？雖然先前提到產品開發最難突破的有三點，其實它們之間有著密不可分的一體三面，仔細推敲一下就知道，想想你在購買虛擬商品跟實際存在的商品時，習慣購買的金額大小一樣嗎？購買的產品類型相同嗎？這其實也就決定了一個新產品的定位及價值，一般來說，新產品的定位可以有很多不同的切入角度，例：產品差異性、價格帶、使用者定位（這一點與消費族群有關）或是操作方式......等，其實有相當多不同的定位方法。

無論你從那個角度切入，都有它存在的參考價值，但是針對產品本身來說，如果你沒有辦法抓住一個重點來發揮，後續挨打的機會可能就大得多，這就如同有人說過：「交往的時候，你可以忘記一年當中的360天，但是，絕不能夠忘記最重要的五個特別日一樣」（當然有人可能會比較貪心一點就是），其實說穿了，對於產品定位來說，也是相同的道理，與其找出它的千百個好處，還不如找到一個消費者願意掏錢購買它的理由，您說是嗎？

產品開發的門檻 ─ I（The threshold of the product development / Product type ）

基於身份的轉變，漸漸地對於很多事情也有了不同的想法，不過，原本要負責的事情也沒有少過就是，只是從原本只需要單純地對某些技術和流程的專注，改變成為對於新產品的開發，其實自己也是邊做邊學，畢竟站在旁邊觀察跟實際下場操作是截然不同的一種體驗。

更何況有更多細節需要處理，尤其是在資源、人力、產品定位都尚未齊全之前（基本上應該永遠都不會有那一天），你就得要花費相當的心力、時間去瞭解一個，可能是你從來未曾思考過的產品，當你以為這些事都如自己所想的時候，其實一切都還未開始，因為自己可能僅是在自己劃出的甜蜜圈裡打轉而已。

所謂的產品開發，絕大部分都不會是「新產品」的創新，往往都是在原有的商品中，找出其中的差異及切入點，甚至還包括了自身所具備的技術、資源和內容的整合，以及非得和時間賽跑的集合體，當然，對於產品開發本身，也有可能是嶄新且從未有人涉獵的產品，但是那大多僅存在於學術領域，畢竟現有的商業體來說，這類的商品往往都是在創造一個未來（夢想）的需求，對於產品本身來說，只要主事者的心隨境轉，往往就會落得四不像的局面居多。

中毒與檔案搜尋技巧（Infected file search skills）

現在因為電腦化相當深，所以人人幾乎都是聞「毒」色變（重點是：如果有發覺的話！），先不論自己有沒有發現，但是在系統管理上，每次遇到這種棘手的問題時，往往解決的速度就會決定你被釘在牆上的時間，以Windows來說，絕大多數的工作環境裡，應該都有商用版的防毒軟體可以撐著，原則上應該也不會遭受到多大的破壞，除非有自作聰明的使用者，或是不受控制的某某人，不然，除了0-day攻擊之外，應該都還是可以有一定的能力可抵擋。

不過，若是換成非Windows系統的架構呢？我相信大多數非Windows系統的主機上，都沒有安裝類似我們在Windows上的防毒軟體，縱使有，應該絕大多數也是針對特定服務，例：電子郵件系統，除此之外，若是其它的服務遭受攻擊，往往都會是別人先通知你居多，如果是租用虛擬主機，一般來說，主機商會收到使用者或特定監控機構的回報，然後，你就會發現自己被主機商給關了，接著就是一連串的郵件往返和緊急處置，這時候搜尋技巧很有可能就會救你一命，尤其是在追蹤感染的檔案，或是藉此找出中毒發病的主因躲在那兒。

協同作業的重要性（The Importance of Collaboration）

最近吵得很兇的科技（雲端？）新聞，就是 Google 弄了一個看似要跟 Dropbox 抗衡的 Google Drive，其實其它廠商也早有類似的服務，例：Microsoft 的Microsoft SkyDrive 和 Apple 的iCloud，這邊有個簡單的容量與價格的比較表可以參考。

不過，這種雲端的儲存空間有什麼好處呢？對於個人的多點作業來說，的確非常方便，尤其，若是那天自己的電腦突然罷工、裝死給你看，自己重要的工作資料還沒備份時，就會發現到它的實用價值（不過，也得視實際內容而定，若是你的工作是處理動輒數GB以上的多媒體檔，我想這種儲存方式也不適用，因為台灣的龜速上傳......）

只是，最近討論的部分不是在容量、功能或價格，而是在隱私或智財權的部分，其中牽扯的太廣，還是留給專家們來討論吧！這篇主要是要來探討協同作業的重要性，其實這種架構應該是較適用於協同作業，但是又有其個人特質的差異存在，接著我們就來看看協同作業究竟簡單不簡單吧！（某些看法或許不適用於特定專業人士，僅為實務的真實感受分享）

採購、議價與潛在因素（Purchase, Negotiated Price and BSA）

年底到了，無論是採用預算制，或是需求制，對於資訊軟、硬體的採購來說，至少每年都得檢視一次是無可避免的，甚至只要有人員變動，就得重新查驗各種軟體的授權，這也是為什麼用人之際，軟體或是看不見的隱性成本，常常被輕忽的主因，若是你有實際算過，你就會知道那些硬體成本，相對是小了許多。

不信的話，你可以把一個新人進公司後，可能要耗費的相關成本攤到檯面上，例：軟體授權的費用：作業系統、文書軟體、特定軟體(美編、程式，或相關應用），訓練所耗費的人力、時間，以及辦公室租金的單位成本，甚至提撥的退休金及最近一直在增加的相關保險，或許這也是為什麼有很多公司寧可委託人力派遣公司來召募員工的主因，更別說有多少人找不到工作（雖然也有不少工作找不到人），上述這些零零總總的費用，跟一次性的硬體費用相比，就可以很明顯地看出差別，所以怎麼在採購、議價上，取得優勢，其實有很多潛規則存在，甚至還有些不可抗力的部分。

文件撰寫的重要性（The Advantage of Keeping Records）

對於IT人來說，看文件、學技術，或者是透過別人的經驗分享，快速找到問題的解決方式，我想應該已經是家常便飯，不過從別的角度來看，其實對於技術人員來說，寫文件也是一件相當重要的事情，因為技術人員通常也都是技術本位，往往會讓開發出來的東西變得比較不人性（說得好聽叫：「技術本位」，說得比較糟就會變成：「難搞、自以為是」的產品開發），其實先前在看一本源自對岸的《走出軟件作坊》的繁中版《走出軟體工場》時，裡面對於文件撰寫的描述，其實也點明了其重要性，我想不僅僅是軟體本身，就算是一個簡單的網路服務，我想撰寫文件其實都可以讓技術人員發現更多自己的盲點，或者是平常在開發時沒有想到的事情。

但是，話說回來，其實文件撰寫或許還是交給專業的人來執行，寫出來的東西比較能夠簡單易懂，至於工程師是否得要親力親為，其實也沒有一定的限制，不過以時下精簡的工作環境來看，其實每個IT的技術人員或多或少都會得要自己撰寫一些文件，小到某個功能的解說，大至整個架構或是產品開發的一些門檻，只是在這其中還是有很多值得反覆咀嚼的東西存在。