向上集團 2017 年會 當責不讓，全力以赴 心得

今天是向上集團第一次舉行年會，年會主題為「當責不讓，全力以赴」。
上午針對集團組織、產品介紹，下午針對「當責」這個主題進行課程。

關於「當責」，幸運地，去年在某種機緣下(當我這麼說的時候表示我不記得)，閱讀了一本「當責，從停止抱怨開始：克服被害者心態，才能交出成果、達成目標！」，所以對於相關的概念倒是蠻清楚的，課程的說明我認為反倒過於簡化。針對「當責」、「負責」的定義，反而降低了我個人對於「負責」所定義的標準。另外，也許這是「當責入門 101」課程，在影片中表現出來的案例中，個人的表現過於慘烈，反而失去討論「團隊當責」的機會，這部份令我覺得相當可惜。

在接下來的體驗式課程中，我非常幸運地在這次分配到擔任 A 角色。為什麼這麼說，因為這次的角色扮演讓我完全體認到「知道」跟「行動」是完全不同的事情。在之前課程的討論中，資訊透明度這點有被提出檢討，同時我也非常明白授權的重要性。然而，在這次的活動中我完全忽略這兩點的執行「資訊公開」及「授權」，事後回憶我當時的想法，原因不外乎兩點，第一點是直覺想到「這是一件很簡單的事情」，另外是有點饒舌的一句話「我不知道你不知道」。關於這個部份，非常值得細細回味。

另外在過程中，我也發現到一件事情，當事情越急，思考應該越慢，因為當時我第一個訊息發出去的時候，事實上是不夠完整的，五分鐘過去當我覺得事情不對勁的時候，我後續又發出了新的訊息，這時候馬上感受到資訊傳遞的混亂。

最後來個事後諸葛，身為角色 A，我覺得最好的行動是，將任務目標完整的授權給 B，如果想讓全團隊更了解任務，同時請 B 將任務目標讓其它成員知道。

在年會結束後，趁著高漲的情緒下，跟主管提了對產品的疑問及未來的方向，了解大致上的走向及發展。要謝謝 Sara 陪我吹了一段時間的冷風，今晚真的蠻冷的。

心得的最後，有一個我有記在筆記上的東西。
當台上講者說到「我們要導入這個機制到我們系統」時笑了出來。
因為我想到「豆腐乳」，
今晚真的蠻冷的。

大人學 別總是直球對決：人生難題的系統思考法 課後心得

從 Joe 的人生故事，敘述著人生中的領悟，因此發展的思維，值得借鏡。

在一連串的故事中，往往可以聯想到自己過去的生活經歷，有種「我們都是這樣過來的」感覺，讓自己的思維不再受限。

其中有 Joe 整理出的 30 個人生關鍵字，主要用來當作人生處境時的思維模式，幫助思考、規劃，完成自己的目標。

在過程中，回想自己小時候是個超聽話的孩子。想到學生時期的困局及生存方式。想到大學時考慮先工作還是先畢業的選擇。想到家庭、經濟跟同心圓理論。彷彿經過了一次時空旅行，回憶這一段的經歷。

本次的贈書也很有趣，弱者的生存策略，主要是講述生物中的各種生存現象，進一步可以其中體會到人生的策略為何，也連接講座的一個思維，人生不是線性思考。

#別總是直球對決
#大人學

Search Inside Yourself 搜尋內在關鍵字 相關資料收集

SIY 官方網站 (英)
https://siyli.org/

台灣官方網站
http://siy.mindfulnesscenter.tw/

台灣合作單位
台灣正念工坊
http://www.mindfulnesscenter.tw/

出版書籍 (英)
Search Inside Yourself: The Unexpected Path to Achieving Success, Happiness (and World Peace)
https://www.amazon.com/Search-Inside-Yourself-Unexpected-Achieving/dp/0062116932

出版書籍
搜尋你內心的關鍵字：Google最熱門的自我成長課程！幫助你創造健康、快樂、成功的人生，在工作、生活上脫胎換骨！
http://www.books.com.tw/products/0010586361

Google 最熱門課程 SIY (搜尋內在關鍵字) 首度來台開課
http://www.accupass.com/go/siy

[閱讀筆記] 搜尋你內心的關鍵字 - Google 最熱門的自我成長課程 (Search Inside Yourself)
http://murphymind.blogspot.tw/2015/07/google-search-inside-yourself.html

[讀書心得/書摘] 搜尋你內心的關鍵字 SEARCH INSIDE YOURSELF
http://www.melodyliao.com/2013/07/blog-post_22.html

快樂工程：由Google最受歡迎的自我探索課談起
http://dididadi.pixnet.net/blog/post/49897294

快樂工程：靜觀在 Google 的實踐與實效
http://dididadi.pixnet.net/blog/post/49644430

大人學 S003 尋找天賦與熱情的系統化做法 課後心得

這次主題太令人期待，所以事前收集大家的心得分享，對於內容有大致的了解。 因為如此，本來有點擔心會不會失去參加演講的意義，沒想到在現場反而更能體會到 Bryan 的演講魅力，而且透過即席體驗的方式更是感受到之前沒有發覺的想法，之前的預習好比挖礦前先做過地質勘查，一旦開挖，反而挖的更深。 有別於大部份人的情況，勉強工作只是為了生存，想要找到自己發光的所在。我算是(至少目前認為)走在天賦與熱情的工作上，這次的探索對於自己的連結主要在於「找回初衷」，自我思考。 分享一下本次贈書，Ken Robinson 有三本相關書籍： 「讓天賦自由」，主要分享為什麼人要尋找天賦與熱情 「發現天賦之旅」，主要介紹如何尋找天賦與熱情 「讓天賦發光」，主要說明傳統教育對於天賦熱情的傷害 另外我發現自己擁有一本跟天賦有很大關係的書 「發現我的天才」 本書介紹三十四種特質，強調找出你的天賦，並發揮所長， 此外隨書附贈蓋洛普「能力發現剖析測驗」，可以找出你在三十四種特質中的前五大主導特質為何。所以如果想作測驗記得買新書不要買二手書唷。 另外一本相關的書籍還沒有閱讀，一起分享一下，「做自己的生命設計師」。 一定要提一下，參加演講的額外好處是可以認識朋友，找到對於自我成長方面有興趣的族人是很重要的唷！這也呼應了演講中的「尋覓族人」。 最後，「系統化做法」標題對於強調邏輯思維的我實在是太對胃口了，看到就會忍不住想要了解吸收一下。 #千萬不要以後每個主題都加上系統化做法 #S003尋找天賦與熱情 #大人學

大人學 A101 職場大人學：職場人際關係與優勢策略 課後心得

職場上，人際關係的基礎在於合作，聽起來理所當然的一句話，卻是令我大大震撼。回想過去，總是自己埋頭苦幹，堅持做對的事情，卻忽略他人的需求，久而久之，雙方的關係便陷於死結，聽到這句話，無疑是當頭棒喝。

常常聽到一些故事，某甲總愛找我麻煩，是壞人，某乙常常有小動作，是壞人，某丙從來不做事卻受到表揚，是壞人，然後故事中的自己一定是好人。從小到大，我們總習慣把人分別好人壞人，影響了思維的判斷。

有些人心裡想著，這些小人雖然得意於一時，但是我相信，老闆的眼睛是雪亮的，總有一天壞人會被處罰，好人會得以平反，換言之，也就是期待著公平正義從天而降，王子與公主從此過著幸福快樂的日子。但那個是童話，這樣的想法太天真，事實上我們真正該做的，是主動找出改變的方法，解決問題。

再從另一個角度來說，雖然常常聽到，但是從來沒有想過，每個人的故事中自己都是好人，那些故事中的壞人到底哪裡來的呢？其實很簡單，大家都是好人，只是角色不同。公司是一個完整的生態圈，有各式各樣的角色，簡單來說，兔子吃草是很正常的現象，總不會因為草被吃掉，因此就說兔子壞壞吧？在職場上，雖然不會真的有誰被吃掉，但是不同角色發生衝突很平常，不需要把對方貼上壞人的標籤，而是去思考如何解決衝突。

當思維轉換到解決問題時，就是利用限制理論，來分析衝突的時候了。衝突往往來自於「錯誤的假設」，只要找出這些錯誤假設，解決方案往往就自動跑出來了，除非雙方完全沒有共識，否則多數的情況下都能解決衝突。

其它還有很多內容需要慢慢消化，這邊特別感謝 William Yeh，因為看到課後心得後，才讓我下定決心來上這門課程，果然超值得！

#A101職場大人學
#大人學

大人學 用遊戲思維規劃你的職涯策略 課後心得

「打電動這麼用心，如果你讀書有一半認真就好了」相信不少人聽過這句話。今天這堂課，藉由遊戲化思維套入職場，不只可以讓平常的工作變有趣，更可以讓自己勇於面對挑戰！

用遊戲的角度看待自己的職涯，可以發現需要找攻略，收集情報，制定自己的目標，確認自己的角色定位，不要明明是個補師，卻總是站在怪面前坦，也難怪別人給你白眼，自己還搞不清楚狀況。

短短三個小時，收獲滿滿，雖然當天台中台北來回跑，但是我要說，這真的很值得啊！

A101 心得拖稿中

期待下個月的天賦熱情

#遊戲思維與職涯策略

#職場玩家的生存攻略

#大人學

C++ Coding Style Guide

Coding Style

第一章：
一、以檔案為最小單位，維持一致的風格
二、以這份風格為目標改進，如果現況不是的話
三、對任何規則有疑慮請提出來討論

第二章：
以 Qt Coding Style 為主，下列例外
一、使用 int* p，不要用 int *p



總結

不要使用例外 (Exceptions)
不要使用 Run Time Type Information (RTTI)
明智的使用 Template，而不只是因為你會
使用 C++ 轉型，不要使用 C 形式的轉型

檔案名稱全小寫 myclass.h or myclass.cpp
(for linux 大小寫敏感，打錯時會找不到，所以一律小寫
Ex: KeepALive.h, Keepalive.h, KeepAlive.h...etc)

類別命名使用峰駝式命名大寫開頭 MyClass
函式命名使用峰駝式命名小寫開頭 myFunction()
變數命名使用峰駝式命名小寫開頭 widthOfBox
私有成員變數命名使用 m_ 開頭 m_widthOfBox
全域變數開頭加上 g 及底線 g_widthOfBox
常數變數使用峰駝式命名大寫開頭 WidthOfBox
列舉 (Enum) 使用峰駝式命名大寫開頭
宣告指標或參考時，在 * 或 & 後面加上空白，不要在前面加上空白

大括號應該 (未決定)

引用 (include) 標頭檔 (header file) 的順序如下
(Names and Order of Includes)
自己的標頭檔 (myclass.h)
專案內的標頭檔 (otherclassinproject.h)
自行開發的工具標頭檔 (mylibary.h)
非標準庫標頭檔 (qt...etc)
近乎標準庫標頭檔 (boost)
標準庫標頭檔 (stl 的 iostream)
系統標題檔

順序的目的是確保自我描述(定義)，
每個檔案都應該自行 include 需要的標頭檔。

Ex:
#include <string>
#include "otherclass.h"

可能會發生 otherclass.h 沒有 include <string> 但是編譯成功，
當其它地方使用 otherclass 的時候卻編譯失敗。

函式的參數順序及如何選擇使用指標 (pointers) 或參考 (references)
參數的順序是先輸入後輸出
輸入參數使用 const reference
輸出參數使用 non-const pointer


=== Code Style Tools ===
cpplint - automated checker to make sure a C++ file follows Google's C++ style
guide
https://github.com/google/styleguide/tree/gh-pages/cpplint

vera++ - verification, analysis and transformation of C++ source code
https://bitbucket.org/verateam/vera/wiki/Home

Indent - reformats C and C++ code in a user-defined indent style and coding style
http://www.gnu.org/software/indent/

Artistic Style 2.05 - Automatic Formatter
http://astyle.sourceforge.net/

Uncrustify - Code Beautifier
http://uncrustify.sourceforge.net/

clang - C language family frontend for LLVM
http://clang.llvm.org/

C++ Style Checker Tool (Not Free)
http://www.semanticdesigns.com/Products/StyleChecker/CppStyleChecker.html

=== 資料來源 ===
Google C++ Style Guide
http://google.github.io/styleguide/cppguide.html

不要使用例外 (Exceptions)
如果是新專案的話，一開始就使用例外的好處應該會高於付出的成本，
但是存有專案的話，因為所有會被影響的部份要全面考慮，所以成本過高。

避免使用 Run Time Type Information (RTTI)
避免使用 typeid or dynamic_cast

避免複雜的 Template

使用 C++ 轉型，不要使用 C 形式的轉型
使用 static_cast, const_cast, reinterpret_cast
不要用 y = (int)x; 或 int y = int(x);

類別命名使用峰駝式命名大寫開頭 MyClass
函式命名使用峰駝式命名大寫開頭 MyFunction()
變數命名使用 width_of_box 或 widthofbox
私有成員變數命名最後加上底線 width_of_box_ 或 widthofbox_
全域變數開頭加上 g 及底線 g_width_of_box 或 g_widthofbox
常數變數開頭加上 k 且改用峰駝式命名 kWidthOfBox
列舉 (Enum) 使用峰駝式命名大寫開頭

宣告指標或參考時，在 * 或 & 前面加上一個空白，或者在在後面加上空白，
不要同時在前面都加上空白
char *x; or char* x;
NOT
char * x;

大括號應該在同一行
if (codec) {
} else {
}
class 宣告及函式實作時也不例外
class Foo {
}

Foo::Bar() {
}

引用 (include) 標頭檔 (header file) 的順序如下
(Names and Order of Includes)

自己的標頭檔
C 系統標題檔
C++ 系統標題檔
自行開發的工具標頭檔
專案內的標頭檔

函式的參數順序及如何選擇使用指標 (pointers) 或參考 (references)
參數的順序是先輸入後輸出
輸入參數使用 const reference
輸出參數使用 non-const pointer

在 C 要改變傳入參數只能使用指標，C++ 可以使用參考，
使用參考可以避免程式碼比較醜，像是 (*pval)++，
而且參考不像指標會出現空指標。



Function names in C++: Capitalize or not? [closed]
http://stackoverflow.com/questions/1776291/function-names-in-c-capitalize-or-not
此文很下面的回答中有提到 C++11 開始支援的 Range-based for loop 要求要使用的類別實作 begin() 及 end() 函式，所以函式名稱使用小寫比較適合。

另外一個回答有提到標準函式庫習慣使用 my_function 來命名，例如
<algorithm>
http://www.cplusplus.com/reference/algorithm/




QT Coding Conventions
This is an overview of the high-level coding conventions we use when writing Qt code.
https://wiki.qt.io/Coding_Conventions

Qt Coding Style
This is an overview of the low-level coding conventions we use when writing Qt code.

Qt Creator Coding Rules
https://doc-snapshots.qt.io/qtcreator-extending/coding-style.html

不要使用例外 (Exceptions)
不要使用 Run Time Type Information (RTTI)
明智的使用 Template，而不只是因為你會

類別命名使用峰駝式命名大寫開頭 MyClass
函式命名使用峰駝式命名小寫開頭 myFunction()
變數命名使用峰駝式命名小寫開頭 widthOfBox
私有成員變數命名使用 m_ 開頭 m_widthOfBox
列舉 (Enum) 使用峰駝式命名大寫開頭

宣告指標或參考時，在 * 或 & 前面加上一個空白，不要在後面加上空白
char *x;
NOT
char* x;

大括號應該在同一行
if (codec) {
} else {
}
class 宣告及函式實作時例外
class Foo
{
}
Foo::Bar()
{
}

引用 (include) 標頭檔 (header file) 的順序如下
(Including Headers)
自己的標頭檔
專案內的標頭檔
自行開發的工具標頭檔
Qt 標頭檔
STL 標頭檔
系統標題檔

目的是確保所有的標頭檔包含自己所需要的引用

在公開標頭檔引用 Qt 時候加上完整路徑
#include <QtCore/qwhatever.h>
這在 Mac OS X frameworks 是必須的，而且對於非 qmake 專案非常方便



Bjarne Stroustrup's C++ Style and Technique FAQ

Should I use call-by-value or call-by-reference?
http://www.stroustrup.com/bs_faq2.html#call-by-reference

當你想要改變參數時，使用參考或指標，f(X&) or f(X*)
當你不想改變參數時而且物件很大時，使用常數參考 (const reference)，f(const X&)
其它情況，使用傳值(call by value)，f(X)

Is ``int* p;'' right or is ``int *p;'' right?
C 程式設計師較常強調 int *p, *p 是一個 int。
C++ 程式設計師較常強調 int* p，p 是一個 int pointer 型別。



The GNU C++ Library
https://gcc.gnu.org/onlinedocs/libstdc++/

The GNU C++ Library - Coding Style
https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html

類別命名使用小寫，以底線分段，my_class
函式命名使用小寫，以底線分段，my_function()
變數命名使用兩個底線開頭，__width_of_box
私有變數命名使用 _M_ 開頭，_M_width_of_box
私有函式命名使用 _M_ 開頭，_M_width_of_box()
常數變數使用 _S_ 開頭，_S_widthOfBox
列舉 (Enum) 使用 _S_ 開頭，_S_widthOfBox

宣告指標或參考時，在 * 或 & 後面加上空白，不要在前面加上空白
char* x;
NOT
char *x;

呼叫成員函式時，使用 this 指標，this->foo();


Boost Library Requirements and Guidelines
http://www.boost.org/development/requirements.html
(還沒看過)

GNU Coding Standards
http://www.gnu.org/prep/standards/standards.html
(還沒看過)

GCC Coding Conventions
https://gcc.gnu.org/codingconventions.html
(還沒看過)

Why Google Style Guide for C++ is a deal-breaker
https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker




C/C++ include file order/best practices [closed]
http://stackoverflow.com/questions/2762568/c-c-include-file-order-best-practices

h file corresponding to this cpp file (if applicable)
headers from the same component,
headers from other components,
system headers.


The prototype/interface header for this implementation (ie, the .h/.hh file that corresponds to this .cpp/.cc file).
Other headers from the same project, as needed.
Headers from other non-standard, non-system libraries (eg, Qt, Eigen, etc).
Headers from other "almost-standard" libraries (eg, Boost)
Standard C++ headers (eg, iostream, functional, etc)
Standard C headers (eg, cstdint, dirent.h, etc)




#include "filename" or <filename> ?
"filename" 表示先找專案內的檔案名稱，找不到再找 include 路徑下
<filename> 表示直接找 include 路徑下


#include <filename.h> or <filename> ?
filename.h 跟 filename 是兩個不同的檔案，
filename.h 是 C 的實作，filename 是 C++ 的實作，
在現代 C++ 標準，C 的實作已經改為 cfilename。
另外，沒有副檔名的用法只存在於標準函式庫，一般標頭檔還是有副檔名。



header file is .h / .hh / .hpp

使用 .h / .hh 的分別在於區分 C / CPP
一、C 實作，CPP Warp 時，會有相同的檔案名稱，使用不同的副檔名可以區別。
二、C / CPP 使用不同的 Coding Style 時，工具可以區別

使用 .hpp 是 boost 約定 CPP 的 header file 副檔名 (代替上面的 .hh)

另一種用法，.hpp 是代表此檔案包含完整實作，例如 template，這時候沒有 .cpp 檔案。



When can you omit the file extension in an #include directive?
http://stackoverflow.com/questions/441568/when-can-you-omit-the-file-extension-in-an-include-directive

When to use .hpp files
http://stackoverflow.com/questions/20023610/when-to-use-hpp-files

*.h or *.hpp for your class definitions
http://stackoverflow.com/questions/152555/h-or-hpp-for-your-class-definitions

C++: Reason why using “.hh” as extension for C++ header files [closed]
http://stackoverflow.com/questions/10354321/c-reason-why-using-hh-as-extension-for-c-header-files

Is having C++ header files without extension a good practice?
http://programmers.stackexchange.com/questions/135683/is-having-c-header-files-without-extension-a-good-practice