mvoto · June 15, 2018 17:24 · Jun 15, 2018 · Jun 14, 2018 · Apr 18, 2018 · Apr 16, 2018
diff --git a/daily_guideline.md b/daily_guideline.md
@@ -58,4 +58,6 @@ On Tmux, to adjust split screen sizes to be exac same:
 
 `Ctrl A + Alt 5`
 
-(Ctrl A is leader)
+(Ctrl A is leader)
+
+Avoid customizing it too much, otherwise when editing things on a server you will find it hard.
diff --git a/daily_guideline.md b/daily_guideline.md
@@ -46,4 +46,16 @@ bin/rspec $(find ./spec | grep spec_files_preffix.*spec.rb$)
 * Log all SQL stuff on console:
 ```
 ActiveRecord::Base.logger = Logger.new(STDOUT)
-```
+```
+
+### Vim and Tmux stuff
+
+On Vim, to adjust split screen sizes to be exac same:
+
+`Ctrl + w =`
+
+On Tmux, to adjust split screen sizes to be exac same:
+
+`Ctrl A + Alt 5`
+
+(Ctrl A is leader)
diff --git a/daily_guideline.md b/daily_guideline.md
@@ -42,4 +42,8 @@ bin/rspec $(find ./spec | grep spec_files_preffix.*spec.rb$)
 * Hash received or default value set:
 ```
 (config[:pool] && config[:pool].to_i) || 1
+```
+* Log all SQL stuff on console:
+```
+ActiveRecord::Base.logger = Logger.new(STDOUT)
 ```
diff --git a/daily_guideline.md b/daily_guideline.md
@@ -30,6 +30,8 @@ Delivery
 
 7. PR and ask for code review if all good
 
+---
+
 Protips
 ===
 

diff --git a/daily_guideline.md b/daily_guideline.md
@@ -28,4 +28,16 @@ Delivery
 
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review
 
-7. PR and ask for code review if all good
+7. PR and ask for code review if all good
+
+Protips
+===
+
+* Running rspec on specific file names:
+```
+bin/rspec $(find ./spec | grep spec_files_preffix.*spec.rb$)
+```
+* Hash received or default value set:
+```
+(config[:pool] && config[:pool].to_i) || 1
+```
diff --git a/development_process.md → daily_guideline.md b/development_process.md → daily_guideline.md
diff --git a/development_process.md b/development_process.md
@@ -1,17 +1,29 @@
+Estimation
+===
+
 1. Understand the problem as much as you can(if not, ask someone for clarification)
 
 1.1. Break the task as much as possible in order to have an accurate estimation
 
 1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
 
+Planning
+===
+
 2. Analyze code base to check if there's something similar already done(and reusable)
 
+Development
+===
+
 3. Try to separate the task from 2 different perspectives:
   * The developer who has a better understanding of the task
   * The test writer(which is possibly the consumer) and knows almost nothing about the task
 
 4. Get it done
 
+Delivery
+===
+
 5. Make real tests on it(if possible)
 
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review

diff --git a/development_process.md b/development_process.md
@@ -1,11 +1,19 @@
-1. Understand the problem as much as I can(if not, ask someone for clarification)
+1. Understand the problem as much as you can(if not, ask someone for clarification)
+
 1.1. Break the task as much as possible in order to have an accurate estimation
+
 1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
+
 2. Analyze code base to check if there's something similar already done(and reusable)
+
 3. Try to separate the task from 2 different perspectives:
   * The developer who has a better understanding of the task
   * The test writer(which is possibly the consumer) and knows almost nothing about the task
+
 4. Get it done
+
 5. Make real tests on it(if possible)
+
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review
+
 7. PR and ask for code review if all good
diff --git a/development_process.md b/development_process.md
@@ -3,8 +3,8 @@
 1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
 2. Analyze code base to check if there's something similar already done(and reusable)
 3. Try to separate the task from 2 different perspectives:
-  * a. The developer who has a better understanding of the task
-  * b. The test writer(which is possibly the consumer) and knows almost nothing about the task
+  * The developer who has a better understanding of the task
+  * The test writer(which is possibly the consumer) and knows almost nothing about the task
 4. Get it done
 5. Make real tests on it(if possible)
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review

diff --git a/development_process.md b/development_process.md
@@ -3,8 +3,8 @@
 1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
 2. Analyze code base to check if there's something similar already done(and reusable)
 3. Try to separate the task from 2 different perspectives:
-  > a. The developer who has a better understanding of the task
-  > b. The test writer(which is possibly the consumer) and knows almost nothing about the task
+  * a. The developer who has a better understanding of the task
+  * b. The test writer(which is possibly the consumer) and knows almost nothing about the task
 4. Get it done
 5. Make real tests on it(if possible)
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review

diff --git a/development_process.md b/development_process.md
@@ -3,8 +3,8 @@
 1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
 2. Analyze code base to check if there's something similar already done(and reusable)
 3. Try to separate the task from 2 different perspectives:
-  * The developer who has a better understanding of the task
-  * The test writer(which is possibly the consumer) and knows almost nothing about the task
+  > a. The developer who has a better understanding of the task
+  > b. The test writer(which is possibly the consumer) and knows almost nothing about the task
 4. Get it done
 5. Make real tests on it(if possible)
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review

diff --git a/development_process.md b/development_process.md
@@ -3,8 +3,8 @@
 1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
 2. Analyze code base to check if there's something similar already done(and reusable)
 3. Try to separate the task from 2 different perspectives:
-  a. The developer who has a better understanding of the task
-  b. The test writer(which is possibly the consumer) and knows almost nothing about the task
+  * The developer who has a better understanding of the task
+  * The test writer(which is possibly the consumer) and knows almost nothing about the task
 4. Get it done
 5. Make real tests on it(if possible)
 6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review

diff --git a/development_process.md b/development_process.md
@@ -1,11 +1,11 @@
-1 - Understand the problem as much as I can(if not, ask someone for clarification)
-1.1 - Break the task as much as possible in order to have an accurate estimation
-1.2 - Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
-2 - Analyze code base to check if there's something similar already done(and reusable)
-3 - Try to separate the task from 2 different perspectives:
-  a - The developer who has a better understanding of the task
-  b - The test writer(which is possibly the consumer) and knows almost nothing about the task
-4 - Get it done
-5 - Make real tests on it(if possible)
-6 - Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review
-7 - PR and ask for code review if all good
+1. Understand the problem as much as I can(if not, ask someone for clarification)
+1.1. Break the task as much as possible in order to have an accurate estimation
+1.2. Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
+2. Analyze code base to check if there's something similar already done(and reusable)
+3. Try to separate the task from 2 different perspectives:
+  a. The developer who has a better understanding of the task
+  b. The test writer(which is possibly the consumer) and knows almost nothing about the task
+4. Get it done
+5. Make real tests on it(if possible)
+6. Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review
+7. PR and ask for code review if all good
diff --git a/development_process.md b/development_process.md
@@ -0,0 +1,11 @@
+1 - Understand the problem as much as I can(if not, ask someone for clarification)
+1.1 - Break the task as much as possible in order to have an accurate estimation
+1.2 - Think about edge cases(this is tricky) but it's a good exercise to try to decrease scope
+2 - Analyze code base to check if there's something similar already done(and reusable)
+3 - Try to separate the task from 2 different perspectives:
+  a - The developer who has a better understanding of the task
+  b - The test writer(which is possibly the consumer) and knows almost nothing about the task
+4 - Get it done
+5 - Make real tests on it(if possible)
+6 - Review the code and tests(if everything makes sense, quality and if there's any typos) before asking someone else's code review
+7 - PR and ask for code review if all good
No results found