大人學 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

gitignore 範本及多個 gitignore 檔案實踐方法

Git 用了一段時間，常常遇到要調整 .gitignore 忽略自動產生的檔案，
當專案多了之後就會覺得不知道有沒有什麼範本可以使用，
馬上發現 GitHub 有個 gitignore 專案專門收集各種 .gitignore 範本。
https://github.com/github/gitignore

接下來想到的問題是，雖然一開始可以用範本，但是之後修修改改又不一致了？
有沒有什麼好的方法呢？直覺是能不能分開成多個 gitignore 檔案呢，
可惜，Git 不支援也不建議。
還好在 StackOverFlow 有網友提出合併檔案的方法，這樣就可以實踐了！

在 git 根目錄下建立一個 gitignore 目錄，然後將範本放進去，像是 VisualStudio.gitignore、C++.gitignore、Qt.gitignore
接著將專案的設定放在 Project.gitignore，最後用一個批次檔來產生 .gitignore。

cat Project.gitignore VisualStudio.gitignore C++.gitignore Qt.gitignore > ../.gitignore

這麼一來 gitignore 既方便使用也好維護 ！



資料來源：
gitignore - A collection of useful .gitignore templates
https://github.com/github/gitignore

Best practice for using multiple .gitignore files
http://stackoverflow.com/questions/10274424/best-practice-for-using-multiple-gitignore-files

Bootstrap SB Admin 2 整合 AngularJS 遇到 metisMenu 問題

使用 Bootstrap SB Admin 2 (Live Preview) 樣版 ，
整合 AngularJS 遇到了幾個關於 metisMenu  (Live Demo) 的問題，

第一個問題是如果 menu 在 ng-include 裡面的話，
並不會正常運作，而是處於完全展開的情況。
原因是原本在 sb-admin-2.js 的程式碼：

$(function() {
    $('#side-menu').metisMenu();
});

在第一次載入頁面時已執行完畢，
當 angular app 載入 ng-include 之後，並沒有做任何的動作。
解決辦法就是在 ng-include 加入 onload 函式，
在 controller 加入下列程式碼後解決：

$scope.loaded = function() {
    $('#side-menu').metisMenu();
}

完整的 Plunker 範例



第二個問題是 metisMenu 的 active 功能沒有正常運作，
原因一樣是因為原本的設計是頁面載入完成後執行程式碼：

var url = window.location;
var element = $('ul.nav a').filter(function() {
    return this.href == url;
}).addClass('active').parent().parent().addClass('in').parent();
 if (element.is('li')) {
    element.addClass('active');
}

然而使用 Angular 實作 Single Page Application 之後，
切換頁面並不會重新載入 js，所以沒有觸發這個動作。
解決辦法是當頁面改變後執行這個動作，如下列程式碼：

.run(['$rootScope', function ($rootScope) {
    $rootScope.$on('$viewContentLoaded', function (event) {
        $('ul.nav a').removeClass('active');

        var url = window.location;
        var element = $('ul.nav a').filter(function () {
            return this.href == url || url.href.indexOf(this.href) == 0;
        }).addClass('active').parent().parent().addClass('in').parent();

        if (element.is('li')) {
            element.addClass('active');
        }
    });
}]);



jquery metisMenu not working inside ng-include
http://stackoverflow.com/questions/26335696/jquery-metismenu-not-working-inside-ng-include

Finished Loading of ng-include in angular js
http://stackoverflow.com/questions/27576643/finished-loading-of-ng-include-in-angular-js

Install Qt5.7 binary on Ubuntu 16.04

Use Ubuntu Server 16.04 for Example

For C++ need build-essential, OpenGL need libgl1-mesa-dev
and install Qt 5.7 binary from PPA

sudo add-apt-repository -y ppa:beineri/opt-qt57-xenial
sudo apt update
sudo apt install -y build-essential libgl1-mesa-dev qt-latest
. "/opt/qt57/bin/qt57-env.sh"

For env setting, add bashrc command
echo . "/opt/qt57/bin/qt57-env.sh" >> .bashrc

=== Ref
Install Qt 5 on Ubuntu
https://wiki.qt.io/Install_Qt_5_on_Ubuntu

Stephan Binner
https://launchpad.net/~beineri

開發團隊 - We are Not Scrum

目前在開發團隊中，進行每日「例」會、利用便條貼整理需求，造成有人經過時會以為團隊正在進行敏捷開發，或者說我們在跑 Scrum。這時候我一定會回答，不，不是的，We are Not Scrum。

先說說目前的情況，
一、每日例會
進行於下午四點半，雖然幾乎是全員站立的，其實不是強制性，時間大概是 20~45 分鐘，目標會希望在 30 分鐘內結束，主要目的是同步資訊，無論是市場變動、系統維運狀態、需求或時程變更、系統架構說明、個人任務說明……等等。

其實上述同時也說明為什麼會進行每日例會，為了解決下例情況
# 開發成員對市場狀況不明白，不懂為何而戰
# 系統可能永遠在某些情況當掉，但是開發人員不知道
# 需求變動可能只有部份開發人員收到通知
# 新進工程師、維運、測試人員對系統不了解 (可能沒機會了解)
# 每個角色遇到的問題也許其它人可以協助，像是維運或測試人員需要工具支援

二、便條貼需求
目前的需求會寫成便條紙，單純是因為需求的優先序變化太快了，白板改來改去太累人，所以才改用便條紙的。另一方面是將除了需求之外，維運及優化問題也都寫上去，方便團隊成員全盤了解產品的狀態。

同樣整理一下便條紙需求解決什麼問題
# 需求優先序變化時，不用擦掉重寫 (尤其是字寫很醜的時候
# 將維運及優化項目列上去，可以讓成員明白有哪些技術債需償還 (尤其是主管或 PO
# 成員想到什麼想法時，可以隨手寫張便利貼上去

為什麼會說不是 Scrum (敏捷開發)
一、真的不是
# 每日「例」會，不是每日「立」會，站立不是重點，想快點結束會議才是共識
# 時間不會限制在十五分鐘內結束，需要討論的事情講完了自然會結束，沒有人喜歡開會
# 主要是資訊分享，鼓勵發言，但是不會強制每個人說三件事
# 便利貼是為了便利，不會特別貼成 Todo, In Progress, Done

二、條件不滿足
# 沒有固定 Sprint 週期，DeadLine 沒有彈性
# 開發人員所作決定得到認可，像是決定實作哪些需求、品質、上線時間

三、避免誤用
# 把 Scrum 的點數當作工時，把預估時程當作承諾
# 誤以為都不用寫文件

最後，要說明我不是在反對 Scrum，Scrum 是個好的方法，但是就好像吃藥一樣，正確的服用才能有好的成果。要先明白要解決的問題，才決定用什麼方法。我也不是反對敏捷，相反的，敏捷正是團隊的目標之一，當宣稱不是使用敏捷開發時，只是避免別人誤以為我們正在進行「某種」工作流程。



資料來源：
敏捷開發
http://wiki.mbalib.com/zh-tw/敏捷开发

敏捷軟體開發
https://zh.wikipedia.org/wiki/敏捷軟體開發

Scrum
https://zh.wikipedia.org/wiki/Scrum