閱讀《開放資料大商機》

《開放資料大商機 - 當大數據全部免費！創新、創業、投資、行銷關鍵新趨勢》(時報出版)的原書名為〈OPEN DATA NOW: The Secret to Hot Startups, Smart Investing, Savvy Marketing, and Fast Innovation〉。

本文不是書推，而是分享一下自己對於本書的想法及閱讀策略。

原書名有比較明顯的指示：開放資料！中文書名則顯得被動地多：假設大數據都準備好了、又不用錢時…。

找到這本書之前，我有兩個疑問：

1. Open Data 有哪些運用了？
2. 除了政府單位外，還有哪些來源？
3. 驅動這些資料出現的真實力量為何？(我對施政單位的考量沒興趣，但是我想知道非公營單位會怎麼想？)
4. Open Data 和我們的未來有什麼關係？

找到這本書後，看了「書名」，會覺得有點…差。

首先，Open Data 不等於 Big Data。原書名可沒有 Big Data 的影子。
其次，誰會這麼好心幫創業家、行銷單位準備好這些資料？

然後，我再聯想到：開不開放，誰來決定的？不危險嗎？

本書分為兩個部分：

Part 1: 開放資料的力量 - 這個部分講的是「案例運用」。
Part 2: 商業環境 - 這個命名還挺爛的，至少我看不太出來這個詞要講什麼。

閱讀之前，我抱著上列種種疑問，期待得到答案。對我來說，想得到的是一個能說得通的 circle 生態。相對來說，我對於「案例運用」興趣較少。原因是：這些是國外的案例，對台灣來說不一定適用，我們的腳步要怎麼踏？這一點不一定要和國外一樣；此外，當我在閱讀這些案例時，一定又有其他案例被產生出來。所以一開始我的閱讀策略就是打算從 Part 2 開始。

Part 2 沒讓我失望，把 Open Data 的供需關係點出來了(雖然目錄裡每個章節的名稱取得有點沒重點)。

這裡只引其中一小段，分享給大家：

「達克．席爾斯 (Doc Searls) 指出，由廠商主會的「顧客關係管理」(Custom Relationship Management，簡稱 CRM)盛行已久，但很快就會出現由消費者主導的「廠商關係管理」(Vendor Relationship Management，簡稱 VRM)。」

閱讀 Part 2時，會提到 Part 1的一些案例，若有興趣，也可以進行交叉閱讀。

最後，本書中文譯者的譯作我應該看過不少本。不過，單就這本來說，我還是覺得通順不足，無法掃讀，佔用了我比較多時間。

為什麼用 Git？

這是一個有點舊的話題。不過，要找一個簡潔的答案似乎不太容易，所以就自己小小記錄一下。

這裡只針對 Git 的分散式架構來說明。(也可以說是「點對點」)

1. 因為不是 CS 架構，所以就少了SPOP (Single Point of Failure)的風險。
2. 每次檔案的增加、修改都「可以選擇是不是要 add」，讓程式碼的控制多了很多彈性。以往被 add 進 SVN 的檔案就是會被管理，除非自 SVN remove 檔案，使之喪失被 SVN 控管的能力。但是在 Git，則不需如此：檔案依然被控管，只需在必要時加入 commit 的行列就可以了。
3. 隨時commit！不受 Server 的網域影響，也不會和原始碼所有共有者衝突。
4. 第3點非常利於TDD及重構。
5. 承第4點，也利於 Agile 的實現。

簡言之，Git 對於實行 Agile 的貢獻非常顯著。

Remote Work 的執行要點

這篇文章是整理自《Remote: Office Not Required》一書。嚴格講起來，我看的是此書的日文版《強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」》。日文書名的翻譯大略為：厲害的團隊捨棄辦公室：37 Signals 所想的「工作術革命」。

日文的書名比英文原版的激進一點。若說「不需要辦公室」，可能代表「有也不錯」的弦外之音，甚至是「有當然更好」。不過，日文版的書名並非為了行銷炒作，讀了書的內文後，會發現內容真的是在強調沒辦公室的好處。日文版的書名，以這點來看，說不定反而更為傳神。

整理如下：

如果大家不在辦公室工作，壞處是什麼？

1. 溝通不易，甚至產生障礙。

2. 員工向心力不足。

誤解是什麼？

1. 可以節省固定成本。

解決方式是什麼？

1. 不論團隊有多分散，每天至少要有四小時的重疊工作時間。

2. 使用能輔助遠距工作的工具。這類的工具需要具備幾項功能：資訊公享(軟體團隊則另需要程式碼共有的機制）、共有透明的行事曆、工作記錄、任務分配、進度檢視、語音及影像即時傳遞。其中，影像的部分不是指看到對方的臉，而是要有一個像電子白板的介面讓彼此能針對議題進行討論。

3. 習慣後，和坐在同一間辦公室的感覺幾乎沒有差異。

4. 最好有一個線上頻道可以讓大家工作累了可以互相哈啦一下。(和知識管理領域裡提的「茶水間對話」是相通的)

5. 每個星期一次和團隊見面，即使只是交流一下最近的生活、興趣也可以。

6. 以上作法，若要實施，請至少認真地持續三個月，而非只抱著估且一試的心態。

最後，我們來看看 Remote Work 的好處：

1. 可以吸納各地良才，不在受地域及時域的限制。(不過若時域差距太大，其實是有影響的。)

2. 有一半以上是只有自己工作的時間，反而比較彈性、能保持專心。畢竟每個人的狀況不同，能依其狀況適度利用時間，遠比固定場所和時間的被盯哨來得好。

3. 減少不必要會議及討論發生的可能。很多經理人習慣以增加會議的方式來推行工作。但是加入會議的人或主席都不一定能真正在準備好的情形下進行會議。這種浪費幾乎是每位上班都要經歷的痛楚。雖然經理人和會議都是必要存在的，但是多了就有害。

3-2. 會議的前後都會破壞人的注意力。這個就是豐田的七種浪費中最常發生的「動作的浪費」。因為等一下要開會，所以什麼事不要現在做；因為剛開完成，剛才什麼事做到一半？原本是打算怎麼做的？要花時間回想。

4. 成果導向。比起是否準時上班？休息時間是否過長？為什麼看 Facebook？最重要的還是工作的成果。Remote Work 看的是貢獻、功勞，而不是苦勞或疲勞。

5. 降低 SPOP (Single Point of Failure) 的可能。公司停電或網路不通等狀況都可能對業務帶來影響。但是 Remote Work 則可以避免這種所有雞蛋被放在同個籃子裡的危險。

6. 減少經理人無故增加無益的工作量的可能。

我的結論：

其實遠距工作學問還挺多的。不過以工作效率的角度來說，我個人觀察，一般員工一天中完全燃燒的時段很有限，很多好想法、解法，也很常不是在辦公室想到的。有些人最有效能的時段是自己在家的時候，因為不會被人打擾。

工作環境是很有學問的。我個人也很常在辦公室腦子一片空白，尤其是對面一群沒表情的人、過於冷白的牆壁的時候。這還算好的，有些人的工作態度還會影響團隊士氣，而不是每個主管都會管這個的。

只要能結合工作目標和個人目標，方法是可變的，執行的結果還是看個人。習於被限制才能做出事情的人也在所多有，所以也不是每個人都合適 Remote Work。要 Remote Work 還得看個人強度…。要有讓一切都更好的覺悟才行。

一眼認識 HomeKit

整理了一下 HomeKit 的 static overview。

分享給大家。

【敏捷迭代式開發中的測試】第三篇：有哪些測試？

這篇文章只是摘錄 《 Software-Testing-And-Continuous-Quality-Improvement-Third-Edition》
Page 43 ~ 50 。


table 3.1 testing technique Categories

Technique	Manual	Automated	Static	Dynamic	Functional	Structural
Acceptance testing	x	x		x	x
Ad hoc testing	x				x
Alpha testing	x			x	x
Basis path testing		x		x		x
Beta testing	x			x	x
Black-box testing		x		x	x
Bottom-up testing		x		x		x
Boundary value testing		x		x	x
Branch coverage testing		x		x		x
Branch/condition coverage		x		x		x
Cause–effect graphing		x		x	x
Comparison testing	x	x		x	x	x
Compatibility testing	x	x				x
Condition coverage testing		x		x		x
CRUD (create, read, update, and delete) testing		x		x	x
Database testing		x		x		x
Decision tables		x		x	x
Desk checking	x			x		x
End-to-end testing	x	x			x
Equivalence partitioning		x		x
Exception testing		x		x	x
Exploratory testing	x			x	x
Free-form testing		x		x	x
Gray-box testing		x		x	x	x
Histograms	x				x
Incremental integration testing	x	x		x	x
Inspections	x		x		x	x
Integration testing	x	x		x	x
JADs (joint application designs)	x				x	x
Load testing	x	x		x		x
Mutation testing	x	x		x	x

© 2009 by Taylor & Francis Group, LLC

Continued

44 ◾ Software Testing and Continuous Quality Improvement table 3.1 testing technique Categories (Continued)

Technique	Manual	Automated	Static	Dynamic	Functional	Structural
Orthogonal array testing	x		x		x
Pareto analysis	x				x
Performance testing	x	x		x	x	x
Positive and negative testing		x		x	x
Prior defect history testing	x		x		x
Prototyping		x		x	x
Random testing		x		x	x
Range testing		x		x	x
Recovery testing	x	x		x		x
Regression testing				x	x
Risk-based testing	x		x		x
Run charts	x		x		x
Sandwich testing		x		x		x
Sanity testing	x	x		x	x
Security testing	x	x				x
State transition testing		x		x	x
Statement coverage testing		x		x		x
Statistical profile testing	x		x		x
Stress testing	x	x		x
Structured walkthroughs	x			x	x	x
Syntax testing		x	x	x	x
System testing	x	x		x	x
Table testing		x		x		x
Thread testing		x		x		x
Top-down testing		x		x	x	x
Unit testing	x	x	x			x
Usability testing	x	x		x	x
User acceptance testing	x	x		x	x
White-box testing		x		x		x

© 2009 by Taylor & Francis Group, LLC

Overview of Testing Techniques ◾ 45 table 3.2 testing technique descriptions

Technique	Brief Description
Acceptance testing	Final testing based on the end-user/customer specifications, or based on use by end users/ customers over a defined period of time
Ad hoc testing	Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it
Alpha testing	Testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end users or others, not by programmers or testers
Basis path testing	Identifying tests based on flow and paths of a program or system
Beta testing	Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end users or others, not by programmers or testers
Black-box testing	Testing cases generated based on the system’s functionality
Bottom-up testing	Integrating modules or programs starting from the bottom
Boundary value testing	Testing cases generated from boundary values of equivalence classes
Branch coverage testing	Verifying that each branch has true and false outcomes at least once
Branch/condition coverage testing	Verifying that each condition in a decision takes on all possible outcomes at least once
Cause–effect graphing	Mapping multiple simultaneous inputs that may affect others, to identify their conditions to test
Comparison testing	Comparing software weaknesses and strengths to competing products

© 2009 by Taylor & Francis Group, LLC

Continued

46 ◾ Software Testing and Continuous Quality Improvement table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Compatibility testing	Testing how well software performs in a particular hardware/software/operating system/network environment
Condition coverage testing	Verifying that each condition in a decision takes on all possible outcomes at least once
CRUD testing	Building a CRUD matrix and testing all object creations, reads, updates, and deletions
Database testing	Checking the integrity of database field values
Decision tables	Table showing the decision criteria and the respective actions
Desk checking	Developer reviews code for accuracy
End-to-end testing	Similar to system testing; the “macro” end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate
Equivalence partitioning	Each input condition is partitioned into two or more groups. Test cases are generated from representative valid and invalid classes
Exception testing	Identifying error messages and exception- handling processes and conditions that trigger them
Exploratory testing	Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it
Free-form testing	Ad hoc or brainstorming using intuition to define test cases
Gray-box testing	A combination of black-box and white-box testing to take advantage of both
Histograms	A graphical representation of measured values organized according to the frequency of occurrence; used to pinpoint hot spots

© 2009 by Taylor & Francis Group, LLC

Overview of Testing Techniques ◾ 47 table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Incremental integration testing	Continuous testing of an application as new functionality is added; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers
Inspections	Formal peer review that uses checklists, entry criteria, and exit criteria
Integration testing	Testing of combined parts of an application to determine if they function together correctly. The “parts” can be code modules, individual applications, or client/server applications on a network. This type of testing is especially relevant to client/server and distributed systems
JADs	Technique that brings users and developers together to jointly design systems in facilitated sessions
Load testing	Testing an application under heavy loads, such as testing of a Web site under a range of loads to determine at what point the system’s response time degrades or fails
Mutation testing	A method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (“bugs”) and retesting with the original test data/cases to determine if the bugs are detected. Proper implementation requires large computational resources
Orthogonal array testing	Mathematical technique to determine which variations of parameters need to be tested
Pareto analysis	Analyze defect patterns to identify causes and sources
Performance testing	Term often used interchangeably with stress and load testing. Ideally, performance testing (and any other type of testing) is defined in requirements documentation or QA or Test Plans

© 2009 by Taylor & Francis Group, LLC

Continued

48 ◾ Software Testing and Continuous Quality Improvement table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Positive and negative testing	Testing the positive and negative values for all inputs
Prior defect history testing	Test cases are created or rerun for every defect found in prior tests of the system
Prototyping	General approach to gather data from users by building and demonstrating to them some part of a potential application
Random testing	Technique involving random selection from a specific set of input values where any value is as likely as any other
Range testing	For each input, identifies the range over which the system behavior should be the same
Recovery testing	Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems
Regression testing	Testing a system in light of changes made during a development spiral, debugging, maintenance, or the development of a new release
Risk-based testing	Measures the degree of business risk in a system to improve testing
Run charts	A graphical representation of how a quality characteristic varies with time
Sandwich testing	Integrating modules or programs from the top and bottom simultaneously
Sanity testing	Typically, an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every five minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a “sane” enough condition to warrant further testing in its current state
Security testing	Testing how well the system protects against unauthorized internal or external access, willful damage, etc.; may require sophisticated testing techniques

© 2009 by Taylor & Francis Group, LLC

Overview of Testing Techniques ◾ 49 table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
State transition testing	Technique in which the states of a system are first identified, and then test cases written to test the triggers causing a transition from one state to another
Statement coverage testing	Every statement in a program is executed at least once
Statistical profile testing	Statistical techniques are used to develop a usage profile of the system that helps define transaction paths, conditions, functions, and data tables
Stress testing	Term often used interchangeably with load and performance testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, or large complex queries to a database system
Structured walkthroughs	A technique for conducting a meeting at which project participants examine a work product for errors
Syntax testing	Data-driven technique to test combinations of input syntax
System testing	Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system
Table testing	Testing access, security, and data integrity of table entries
Thread testing	Combining individual units into threads of functionality that together accomplish a function or set of functions
Top-down testing	Integrating modules or programs starting from the top

© 2009 by Taylor & Francis Group, LLC

Continued

50 ◾ Software Testing and Continuous Quality Improvement table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Unit testing	The most “micro” scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses
Usability testing	Testing for “user-friendliness.” Clearly, this is subjective, and will depend on the targeted end user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers
User acceptance testing	Determining if software is satisfactory to an end user or customer
White-box testing	Test cases are defined by examining the logic paths of a system