Actions

Difference between revisions of "Tech Tips"

From kemiko

 
(23 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
'''Trouble Shooting''':
 
'''Trouble Shooting''':
  
<ul>
+
<ul>
  <li>
+
<li>
  Start with the basics...like power, network, etc.
+
  Start with the basics...like power, network, etc.
  </li>
+
</li>
</ul>
+
</ul>
  
 
'''General''':
 
'''General''':
  
  <ul>
+
<ul>
   <li>
+
  <li>
  Always query before running modification command(s)
+
   Know the animal before trying to tame.
  </li>
+
</li>
  <li>
+
<li>
  Backup or already have a backup before modifying files
+
  Some vendors use MB/GB (decimal...in goups of 1000) and some use MiB/GiB (binary...in groups of 1024).
  </li>
+
</li>
  <li>
+
<li>
  Learn your edit well...it's function can save a lot of time
+
  Always query before running modification command(s) whether using the OS, database or apps.
   </li>
+
</li>
  </ul>
+
<li>
 +
  Backup or already have a backup before modifying files, database, apps.
 +
</li>
 +
<li>
 +
  Learn your editor(s) well...its functionality can save a ton of time
 +
</li>
 +
<li>
 +
  Learn all available debugging tool...it can save a ton of time
 +
</li>
 +
<li>
 +
  Always use logging
 +
  <ul>
 +
  <li>
 +
    Check logs often or write smart alerts that scan logs
 +
  </li>
 +
  <li>
 +
    Rotate logs to keep them manageable
 +
  </li>
 +
  <li>
 +
    tail -f error logs when developing
 +
  </li>
 +
  <li>
 +
    Good pairing words: staring/finished, source/target, etc.
 +
  </li>
 +
  </ul>
 +
</li>
 +
<li>
 +
   Always learn the background workings.  That means learn and use the command line and script NOT just the GUI tools
 +
</li>
 +
  <li>
 +
  Always check your work!  Even when making a simply change...if done wrong can cause large issues.
 +
</li>
 +
<li>
 +
  Automate tasks.  Automating tasks take a very good understanding of the software and intended goal.
 +
</li>
 +
</ul>
  
 
'''Development''':
 
'''Development''':
 
<ul>
 
<ul>
  Naming
+
  <li>
<ul>
+
  Naming
  <li>
+
  <ul>
  Avoid spaces.
+
  <li>
  </li>
+
    Avoid spaces.
  <li>
+
  </li>
  Use camelCase.
+
  <li>
  </li>
+
    Use camelCase.
  <li>
+
  </li>
  Name common items with the common word starting each item.
+
  <li>
  </li>
+
    Name common items with the common word starting each item.
  <li>
+
  </li>
  Name same item, but numbered with enough padding to sort correctly.  ex: if going to at least 10 use 01-10 instead of 1-10.
+
  <li>
  </li>
+
    Name same item, but numbered with enough padding to sort correctly.  ex: if going to at least 10 use 01-10 instead of 1-10.
  <li>
+
  </li>
  Name date by number not name and most general to specific.  So they sort correctly.  ex: 20161231 instead of Dec31-2016, etc.
+
  <li>
  </li>
+
    Name date by number not name and most general to specific.  So they sort correctly.  ex: 20161231 instead of Dec31-2016, etc.
  <li>
+
  </li>
  Name using noun first then verb.  ex: logCreate, logList, etc.
+
  <li>
   </li>
+
    Name using noun first then verb.  ex: logCreate, logList, dateStart, dateEnd, etc.
  </ul>
+
  </li>
 +
   </ul>
 +
</li>
 +
</ul>
 +
 
 +
<ul>
 +
  <li>
 +
  Coding
 +
  <ul>
 +
  <li>
 +
    Top-down vs bottom-up design
 +
  </li>
 +
  <li>
 +
    Always add comments...you may not remember what you did days, months, years from now
 +
  </li>
 +
  <li>
 +
    Line block brackets up vertically
 +
  </li>
 +
  <li>
 +
    Happy balance between elegance/complexity and readability/maintainability
 +
  </li>
 +
  <li>
 +
    Happy balance between too long and too short variable naming
 +
  </li>
 +
  <li>
 +
    Pick a style and stay consistent...this sometime means following someone else's style when modifying existing code
 +
  </li>
 +
  <li>
 +
    Learn your debugging tool(s)...they can save a ton of time
 +
  </li>
 +
  <li>
 +
    Give some thought to designing your log files...
 +
    <ul>
 +
    <li>
 +
      Put the date and time in each record
 +
    </li>
 +
    <li>
 +
      Format well...XML, JSON, delimited, etc.
 +
    </li>
 +
    <li>
 +
      Make sure enough data is included to be helpful
 +
    </li>
 +
    </ul>
 +
  </li>
 +
  </ul>
 +
</li>
 
</ul>
 
</ul>
 +
 +
'''*nix''':
  
 
<ul>
 
<ul>
  Coding
+
  <li>
  <ul>
+
  Type "env" and/or "set" in the shell to display all the environment variables
   <li>
+
</li>
  Always add comments
+
  <li>
   </li>
+
   Use "set -x" to debug shell scripts ("set +x" turns debugging off)
  <li>
+
</li>
  Line block brackets up vertically
+
<li>
   </li>
+
   Use "set -o vi" to use vi to navigate/modify shell commands ("set +o" turns vi off)
  <li>
+
</li>
  Happy balance between complexity and readability
+
<li>
  </li>
+
  crontab
  <li>
+
   <ul>
   Happy balance between too long and too short variable naming
+
  <li>
  </li>
+
    Put number in 09 format to make easier to read, parse and sort (multiple spaces are fine...fields are space delimited)
  <li>
+
  </li>
   Pick a style and stay consistent
+
  <li>
  </li>
+
    Always redirect command output somewhere, log file, /dev/null, etc.&nbsp;&nbsp;Otherwise output will be sent to the user's email
  <li>
+
   </li>
  Learn your debugging tool...they can save a ton of time
+
  <li>
  </li>
+
    Command must be one line.&nbsp;&nbsp;Semicolons are okay to execute mulitple commands
 +
   </li>
 +
  <li>
 +
    The modulus operator can be used to run commands. "*/5" in the minute field will run the command every 5 minutes
 +
  </li>
 
  </ul>
 
  </ul>
 +
</li>
 
</ul>
 
</ul>
 +
 +
 +
'''SQL''':
 +
 +
<ul>
 +
<li>
 +
  In general use a where clause even if selecting everything..."where 1" or "where 1 = 1".  This reminds someone editing the code that this query is operating on EVERYTHING.  Remove the where clause can sometimes greatly optimize code.  Make a comment to note there is NO where clause.
 +
</li>
 +
<li>
 +
  Comments are handy even in SQL for debugging and understanding.  "--comments" is universal, but also /* comments */ in MySQL, {comments} in Informix, etc.
 +
</li>
 +
<li>
 +
  Always comment out a drop statement right after executing, so it is not accidentally run again
 +
</li>
 +
<li>
 +
  Indexes are very important to the performance of a database
 +
</li>
 +
<ul>

Latest revision as of 09:59, 15 October 2017

Trouble Shooting:

  • Start with the basics...like power, network, etc.

General:

  • Know the animal before trying to tame.
  • Some vendors use MB/GB (decimal...in goups of 1000) and some use MiB/GiB (binary...in groups of 1024).
  • Always query before running modification command(s) whether using the OS, database or apps.
  • Backup or already have a backup before modifying files, database, apps.
  • Learn your editor(s) well...its functionality can save a ton of time
  • Learn all available debugging tool...it can save a ton of time
  • Always use logging
    • Check logs often or write smart alerts that scan logs
    • Rotate logs to keep them manageable
    • tail -f error logs when developing
    • Good pairing words: staring/finished, source/target, etc.
  • Always learn the background workings. That means learn and use the command line and script NOT just the GUI tools
  • Always check your work! Even when making a simply change...if done wrong can cause large issues.
  • Automate tasks. Automating tasks take a very good understanding of the software and intended goal.

Development:

  • Naming
    • Avoid spaces.
    • Use camelCase.
    • Name common items with the common word starting each item.
    • Name same item, but numbered with enough padding to sort correctly. ex: if going to at least 10 use 01-10 instead of 1-10.
    • Name date by number not name and most general to specific. So they sort correctly. ex: 20161231 instead of Dec31-2016, etc.
    • Name using noun first then verb. ex: logCreate, logList, dateStart, dateEnd, etc.
  • Coding
    • Top-down vs bottom-up design
    • Always add comments...you may not remember what you did days, months, years from now
    • Line block brackets up vertically
    • Happy balance between elegance/complexity and readability/maintainability
    • Happy balance between too long and too short variable naming
    • Pick a style and stay consistent...this sometime means following someone else's style when modifying existing code
    • Learn your debugging tool(s)...they can save a ton of time
    • Give some thought to designing your log files...
      • Put the date and time in each record
      • Format well...XML, JSON, delimited, etc.
      • Make sure enough data is included to be helpful

*nix:

  • Type "env" and/or "set" in the shell to display all the environment variables
  • Use "set -x" to debug shell scripts ("set +x" turns debugging off)
  • Use "set -o vi" to use vi to navigate/modify shell commands ("set +o" turns vi off)
  • crontab
    • Put number in 09 format to make easier to read, parse and sort (multiple spaces are fine...fields are space delimited)
    • Always redirect command output somewhere, log file, /dev/null, etc.  Otherwise output will be sent to the user's email
    • Command must be one line.  Semicolons are okay to execute mulitple commands
    • The modulus operator can be used to run commands. "*/5" in the minute field will run the command every 5 minutes


SQL:

  • In general use a where clause even if selecting everything..."where 1" or "where 1 = 1". This reminds someone editing the code that this query is operating on EVERYTHING. Remove the where clause can sometimes greatly optimize code. Make a comment to note there is NO where clause.
  • Comments are handy even in SQL for debugging and understanding. "--comments" is universal, but also /* comments */ in MySQL, {comments} in Informix, etc.
  • Always comment out a drop statement right after executing, so it is not accidentally run again
  • Indexes are very important to the performance of a database