Difference between revisions of "Tech Tips"
From kemiko
(13 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
'''Trouble Shooting''': | '''Trouble Shooting''': | ||
− | + | <ul> | |
− | + | <li> | |
− | + | Start with the basics...like power, network, etc. | |
− | + | </li> | |
− | + | </ul> | |
'''General''': | '''General''': | ||
− | + | <ul> | |
− | + | <li> | |
− | + | Know the animal before trying to tame. | |
− | + | </li> | |
− | + | <li> | |
− | + | Some vendors use MB/GB (decimal...in goups of 1000) and some use MiB/GiB (binary...in groups of 1024). | |
− | + | </li> | |
− | + | <li> | |
− | + | Always query before running modification command(s) whether using the OS, database or apps. | |
− | + | </li> | |
− | + | <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> |
− | + | <li> | |
− | + | Learn all available debugging tool...it can save a ton of time | |
− | </li> | + | </li> |
− | </ul> | + | <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''': | ||
Line 51: | Line 77: | ||
</li> | </li> | ||
<li> | <li> | ||
− | Name using noun first then verb. ex: logCreate, logList, etc. | + | Name using noun first then verb. ex: logCreate, logList, dateStart, dateEnd, etc. |
</li> | </li> | ||
</ul> | </ul> | ||
Line 62: | Line 88: | ||
<ul> | <ul> | ||
<li> | <li> | ||
− | Top-down | + | Top-down vs bottom-up design |
</li> | </li> | ||
<li> | <li> | ||
− | Always add comments | + | Always add comments...you may not remember what you did days, months, years from now |
</li> | </li> | ||
<li> | <li> | ||
Line 77: | Line 103: | ||
</li> | </li> | ||
<li> | <li> | ||
− | Pick a style and stay consistent | + | Pick a style and stay consistent...this sometime means following someone else's style when modifying existing code |
</li> | </li> | ||
<li> | <li> | ||
Line 83: | Line 109: | ||
</li> | </li> | ||
<li> | <li> | ||
− | Give some thought to designing your log files. | + | Give some thought to designing your log files... |
<ul> | <ul> | ||
<li> | <li> | ||
Line 102: | Line 128: | ||
'''*nix''': | '''*nix''': | ||
− | + | <ul> | |
− | + | <li> | |
− | + | Type "env" and/or "set" in the shell to display all the environment variables | |
− | + | </li> | |
− | + | <li> | |
− | + | Use "set -x" to debug shell scripts ("set +x" turns debugging off) | |
− | + | </li> | |
− | + | <li> | |
− | + | Use "set -o vi" to use vi to navigate/modify shell commands ("set +o" turns vi off) | |
− | </li> | + | </li> |
+ | <li> | ||
+ | crontab | ||
+ | <ul> | ||
+ | <li> | ||
+ | Put number in 09 format to make easier to read, parse and sort (multiple spaces are fine...fields are space delimited) | ||
+ | </li> | ||
+ | <li> | ||
+ | Always redirect command output somewhere, log file, /dev/null, etc. Otherwise output will be sent to the user's email | ||
+ | </li> | ||
+ | <li> | ||
+ | Command must be one line. 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> | ||
+ | </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