elixir version control

https://elixir-lang.org/install.html#compiling-with-version-managers

Surfing tutorial video & tips

覺得講得不錯

https://surfsimply.com/surf-simply-tutorials/


## Tips


初學：
Pop up 的速度來自於 gravity

追浪的兩個重點：板的位置和速度
板的位置：追浪時盡量身體重心向前才有重力，通常 nose dive 是因為速度不夠快而不是太向前（盡可能前，找到適合的位置）
速度：Last 5 power paddle before waves get you, 提早建立速度，等浪來時速度就夠了。當尾被抬起時，再 3 extra power paddle。
起乘時會有往下的恐懼，千萬不可以把手放在板前面穩定版，應該要把手放在臀部跟腰間附近，想辦法 pop up
pop up 時只看向想要去的地方，不要看下面



中級：

當 Hunter, not hunted
往外一點，先加速再到 Spot X
遇到大浪一律往外滑，先不想怎麼越過，先想怎麼衝到這道浪，邊往外滑邊想
找 Spot X
斜著起乘會翻是因為板子不平，不是因為角度
靠起乘的最後三下 power paddle 改變板頭角度，面向想要往前的方向，而不是靠把板弄斜轉向
保持在浪的上半部

進階：
當衝到浪但是卻遇到前面有break了，與其往下走繞過去，應該要往上繞過 break，這樣才有足夠的速度繞過 break

常問的面試問題

目的是找出適合團隊的人，不是找牛人，所以我面試的時候會看溝通能力、合作能力大於技術能力，技術只需要達標就好，通常技術是否達標可以從討論 general tech concept 的時候就知道，最簡單的方法就是看對方對之前做的 project 的技術理解程度，我通常會問的問題列在下方：

## General:

之前團隊的組成
你擔任什麼角色
跟 XXX (designer、產品、後端) 有沒有過意見不合的時候，怎麼解決？
過去經驗中印象最深刻的事情
過去經驗中做過最有成就感的事
現在回想起來，在過去經驗中做錯的事。重新一次會怎樣 Approach？
你的職涯發展規劃是什麼？為什麼會想換工作？
你怎麼確保你照著自己的規劃走？
未來兩年在我們公司想做到什麼？
你理想中的團隊長怎樣？
最近有什麼感興趣的東西？


## Project specific:

我看到你前一份 Project 是要做 XXX，可以說說看這個 Project 嗎？
請問裡面的 OOO 功能是怎麼做到的？
有什麼其他的作法？
為什麼選擇之前的做法？
重來一次會怎麼選擇？
如果是使用 3rd party 供應商，背後的原理是什麼？
最困難的地方是什麼？
根據你之前的 approach，Bottle neck 是什麼？
我想到另一個作法，是 XXXXXX，你覺得呢？
（視情況再看要不要繼續鑽每個問題裡的技術細節）

My hiring strategy

很多 startup 都會說「我們只找最好的人」，我覺得這根本是屁話，哪有所謂最好的人，只有「在這個時間範圍內我能夠遇到的最適合團隊的人」而已，很繞口對吧？ＸＤ

讓我拆解並解釋一下這句話：

1. 首先是「在這個時間範圍內」，因為招人是有時間限制的，你只能遇到在這個時間範圍內有求職慾望的人
2. 再來是「我能夠遇到的」，因為招人的管道、地區、公司所處行業、公司知名度、厲害的人的 availability....等等的無限多的變數，公司能夠遇到的人相較於整個市場是很少的 %，所以並需要再加上這個 scope
3. 最後是最重要的「最適合團隊的人」這句話，之所以把「最好的人」改成「最適合團隊的人」原因是所謂的最好根本沒辦法定義，我們假設 DHH 是 Rails 最強的人、Martz 是 Ruby 最強的人（雖然我們都知道不是），難道我們就要找 DHH 和 Martz 進來嗎？他們也許根本就不適合團隊，那麼進來只會變成災難。所以沒有所謂最好的人，只有最適合團隊的人。

在多數的團隊中，找到一個 team player 比找到一個技術大神重要多了，以面試技術人員來說，首先技術能力能夠解決公司目前遇到的問題就是 60 分，代表及格可以 hire（但不代表你就要 hire 他），然後我們可以把所有及格可以 hire 的候選人聚集在一起比較，找出最適合的人，我個人主要看重的特點是：

- 合作能力 > 單打獨鬥的能力
- 潛力 > 現在的能力
- 喜歡做產品 > 喜歡鑽研技術 （for Startup）
- 謙虛但有自信 > 自大


大概是這樣

How to do a 1on1

## General Tips:

- 提早約時間，盡量按照 schedule ，給對方準備時間
- 1 on 1 前先問券問重點問題
- 多問問題, 不要過早下定論 (judge)
- 結束時要有結論（如果可以有可量化的 task 最好）


## SOP:

0. 提早看問卷的回覆，試著找出癥結點
1. 閒聊，問問生活上的近況 -> Building trust (Emotional Savings Account)
2. 開放性問題，問工作的近況和職涯規劃 -> onboarding
3. 進入 questions cycle

## Questions cycle:

1. Choose a question
2. Ask why
3. Dig deeper by asking more why
4. Receiving & Giving feedback (你覺得我可以怎麼做 & 我覺得你可以怎麼做)
5. Set a do-able action

## How to choose questions

depends on 團隊以及個人狀況，我認為問題分兩大類，個人以及工作

所謂個人問題並不是指日常生活的問題例如「哪間餐廳好吃」之類的，而是脫去工作的外殼，從個人角度出發的問題，例如「3 年後的職涯發展目標」、「最近在什麼事情上感到特別有成就感」之類的，而工作相關問題則是「最近的工作狀態給自己幾分」、「你認為現在團隊有沒有什麼可以改進的地方」這類直接跟工作場景連結再一起的問題。

我認為一個好的 1on1 至少要 4:6，無論是個人 4 或是工作 4 都可以，depends on 每個人的情況，但不可以只偏向其中一種，要有平衡。


https://getlighthouse.com/blog/one-on-one-meeting-questions-great-managers-ask/

Rails schema 到底怎麼保持乾淨

在不能 access production database 的情況下：

1. 怎麼保持 local database schema 是乾淨的
2. 如果髒了，怎麼恢復成乾淨的而且不影響現在 local 有的資料（乾淨的資料恢復，不乾淨的就丟掉）


## Idea 1:

Rails 內建的一些方法

要把 db 弄乾淨最簡單就是

db:drop, db:create, db:schema:load

直接 db:schema:load 的話不會刪掉多的 table

https://stackoverflow.com/questions/10301794/difference-between-rake-dbmigrate-dbreset-and-dbschemaload

問題：

1. db 資料會被清空
2. 必須仰賴 db:seed 保持乾淨並 up to date


## Idea 2:

dump db 出來，在 restore 的時候選擇性的 restore

pg_dump test-docker_development -c > tmp/dirty_dump.sql


問題：

1. schema_migration 的 table 會是錯的，不好改
2. pg_restroe 會暴力的把 table 內的資料結構改掉（如果不一樣），可能會造成 table 跟schema 不符合的問題



## Idea 3:

有一台只跟 production 跑一樣環境的機器，從上面要資料

問題：

1. 若 production 跑 task，這台機器也要跟著跑，不然資料一樣是錯的


## Conclusion

db:seed 檔就是為此而生的，但之所以會沒有人更新的原因是大家並沒有很常需要用到 seed 檔案，例如 deploy 到 staging 測試時 staging 本來就會有測試的舊資料（雖然很髒），所以不需要跑 seed，對 developer 而言也就不會 care 這麼多，反正這次我可以測就好，下次有人有問題再說。

所以問題就變成「要讓 seed 檔案在開發以及測試過程中扮演重要角色，這樣才有可能維護一個乾淨的 local 開發 schema & data」


要做到提升 seed 重要性就要改 Staging 測試的方式，例如讓 staging 用類似 docker container 的技術每次測試的時候都跑一個新的 App 並執行 seed，這樣就會強迫 developer 更新 seed 而且保持開發和測試效率

How to keep forked git repo up to dated?

### 1. Clone your fork:

    git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git

### 2. Add remote from original repository in your forked repository:

    cd into/cloned/fork-repo
    git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
    git fetch upstream

### 3. Updating your fork from original repo to keep up with their changes:

    git pull upstream master


https://gist.github.com/CristinaSolana/1885435