Goal Setting

There is a difference between dream and goal.

Benefits of setting an achievable goal:

1. Guiding decisions

2. Monitor progress

3. Communicating growth

                                                 Goal

                                               /        \

           Professional            Personal

Types of Goals

1. Performance – Raise your aim and take advantage of current abilities
2. Development – Expand abilities

Setting Goals

Objective component – eg: conduct interviews, submit a plan, write a report

Standards component – measures whether an objective has been met. eg: within 6 weeks, by 30%, less than 5 times

Conditions component – clarifies the objective. Limitation on how to achieve the goal

Strategic Thinking

1. Win collaboration

2. Assess the risk

3. Reduce wasted effort – Productivity

Assessing Risk

Risk -> Time/Effort

-          Classify goals in low risk and high risk

Type of change associated with high risk goals

-          Create a new condition

-          Eliminate an existing condition

Type of change associated with low risk goals

-          Preserve an existing condition

-          Avoid an unwanted condition

Beware of unstated goals

Collaborating on Goals

- Define the conflict

- Propose a collaboration

- Define roles for participants

Prioritizing Goals

Advantages:

1. You achieve your goals more quickly
2. You take action on imp and urgent goals first
3. you are better able to recognize when it’s time to let or choose an alternative goal.

- Personal importance

- Professional importance

- Resource availability

- Resource urgency

Plot a graph of importance vs availability

Setting Alternative Goals

Strategies:

1. Breaking out smaller objectives
2. Reassessing priorities
3. Seeking a different path to dest

Don’ts:

1. Relaxing standards
2. Extend deadline

Static Code Analysis

Static code analysis is the process of examining  and evaluating software without actually executing the code. Analyzing software when executing software is known as dynamic analysis. Static code analysis is all about moving the detection of critical security and quality problems upstream, ensuring they’re identified and fixed early in the development process.

This approach yields significant productivity gains across the entire process and leads to cleaner, more stable builds, more efficient testing, and of course, a higher quality product. Besides helping us find bugs that we’ve missed in unit testing, static code analysis has made all our engineers aware of security issues and helped us teach junior staff better coding techniques.


What’s Involved?
Static source code analysis tools are almost entirely automated. They’re like compilers, but instead of generating machine-executable code, they simply find bugs and issue warnings about security vulnerabilities, logic errors, implementation defects, concurrency violations, boundary conditions, and other glitches in the code. The tools provide a list of problems, each tied to a specific location in the source code. Detailed context is usually provided to explain how the tool arrived at the conclusion.

Static analysis tools use very sophisticated process flow and data flow analysis. The quality and security issues they identify are often complex and involve obscure logic problems, which is why these tools can be so valuable.

Static source code analysis tools analyze 100% of the source code, far more than any external test tools. For organizations that must comply with the Payment Card Industry Data Security Standard (PCI DSS) or Payment Application Data Security Standard (PCI PADSS), these tools fulfill code review requirement. They also produce valuable metrics, including kilo-lines of code (KLoCs), file counts, and “churn” — that is, the number of files that have changed between two regular builds.

Introducing static code analysis and the requisite tools into the development process isn’t always painless, however. For instance, static code analysis tools usually require careful integration into the project build process. For large software products, these builds are often somewhat of a black art,  involving the use of Make and Ant. There are many options and dependencies. All static code analysis tools offer powerful utilities to analyze the build process and insert themselves into the right places, but some manual tuning is usually required.

These tools also must be integrated into developers’ daily work. Again, tool makers offer both command-line versions of the tools as well as plugins for many of the popular integrated development environments such as Eclipse and Visual Studio.

The tools require that the code base have a subject matter expert (SME) who can also provide the same service for the tools. That person will answer questions not just about how the tool operates but also about the issues that the tool is finding — including identifying when the tool is generating a false positive. The SME will provide training and support to other developers, a fairly heavy workload for the first few weeks, until everyone is familiar with the  static analysis tool. After that, that part of the workload should settle down to several hours a week.


Initial Analysis
The biggest challenges with static code analysis tools are problems in existing code. There’s an old programmer’s joke that says “God made the world in six days because he had no installed base.” This is certainly not the case for most businesses, which often have millions of lines of code.

The first time an existing codebase is analyzed, tens of thousands of issues will be found. Don’t panic. Remember, these issues have been there for awhile, and the software continues to function and provide users with what they need. At ACI Worldwide, all the issues from an initial build on existing code are immediately deferred and hidden from sight. That way developers don’t get overwhelmed and can stay focused on ensuring that new problems aren’t introduced into the code. At some point in the future, product planners and the senior development staff review the deferred issues, prioritize and group them, and decide when remediation can be factored into the planning for a future release. There’s no perfect approach, and businesses must always make hard decisions
about whether to counter a vulnerability or assume the risk.



Tips For Success
• Define an initial issue policy. You may decide to only deal with the most severe issues for the first project cycle.
• Get the global mechanics working. Many of the tools require license managers and centralized result servers.
• Attack one product at a time. Get it working with one group and then move on to the next.
• Identify SMEs. Every product needs at least one subject matter expert. Large products that are broken into major components will naturally need an SME for each one.
• Train SMEs. Make them designated experts.
• Work with SMEs. Help them to do build and tool integration for their product or component.
• Train developers. The SME should guide how the tool is integrated into the team’s development process.
• Perform initial analysis on existing code and defer all issues. Don’t discuss the large quantity of issues with the developers. If any ask, explain to them that they’ve been set aside and will be considered in a future product cycle.
• Deliver help from SMEs to developers as required. During the first days of the roll-out, the SME should monitor the developers’ work. Developers should be analyzing the code often, at least before they submit a completed unit of work into the product build. Just as a developer wouldn’t check in a unit of code that doesn’t compile, they won’t want to check in a unit that still has static code analysis issues.
• Run the build analysis often. If the developers are doing their job and addressing issues as they come up, then no issues should be found at this stage.
• Review deferred issues. After the process is running smoothly and the tool is a routine part of work, review deferred issues and plan whatever remediation is needed for future releases.

 

The Right Tool For You
There are numerous open source and commercially available static code analysis tools on the market. When choosing one, the place to start is with language support. Some tools support a single language. Other static code analysis tools support multiple languages.



Final Analysis
Overall, static code analysis has proven to be a valuable tool. For a reasonable cost per developer, we can find serious bugs more comprehensively and earlier in the development process.

The tools include extensive help files that refer developers having difficulty with an issue to a more experienced developer to get advice — always a valuable interaction.

Bottom line: Static code analysis tools help incorporate security and quality awareness into the fabric of the entire development organization. Finding bugs earlier and avoiding security breaches
is invaluable to any software development effort.









 
5 Queries for Choosing the Right Code Analysis Tool
1. Do you need a static or dynamic analysis tool?
2. What languages and platforms does it support?
3. How flexible is the reporting component?
4. How easy is it to add or update rules?
5. Does it integrate with your IDE?

Time Management

Areas:

A.      Environment

B.      Technology

C.      Time stealers

A. Controlling Environment:

1.      Paperwork

2.      Physical organization

3.      Meeting

A Technique for Managing Paperwork

Pass on – to be read by someone else, pass on to only one person avoid passing on multiple copies.
Read – read short docs immediately, long docs later
File – needed in future
Throw away – irrelevant doc

Physical organization

Comfort,

Structure,

Tidiness

Preparing to save time

1. Ask the right questions – necessity, contribution, action

B. Time and technology:

Benefits:

1. Communicate info very quickly over any distance.
2. Enables you to store and retrieve info extremely easily

Controlling emails

Strategy (In order):

1. Allocate specific time for addressing emails.
2. Minimize the no. of emails to be read
3. Prioritize actions as a result of email.
4. Minimize the time that each necessary reply requires.

-         Deactivate desktop alerts

Electronic organization systems

1. PC based system – large amt of data that doesn’t need to be shared
2. telephone based – small amount of data which is very portable
3. networked  - very large amount of data, shared access

C. Time stealers

Dealing with demands

1. Inner directed – minimizes time given to other person
2. Other directed – Gives much time to other person
3. Autonomous – focuses on own goals and that of other person simultaneously.

Avoiding reverse delegation:

1. Set boundaries
2. Offer information
3. Refuse extra work.

Beating Procrastination

- Results into fatigue and waste of time

Excuses:

1. I have lack of info – get relevant info from concerned ppl ASAP
2. I have plenty of time – identify exact amt of time required for the task and schedule each action
3. I don’t have any time – reprioritize

Underlying reasons:

1. anxious
2. low motivation

How to beat?

1. confront excuses
2. break the habit
3. identify the outcome
4. take the first step
5. learn from the past

Handling Interruptions

1.      Don’t either welcome or refuse an interruption

2.      Aim to use your time as well as possible

3.      Control what happens when you are interrupted.

1. Allocate time – Be specific on amt of time. Say : “I have X mins”
2. Control content
3. Control end – Say: “Unfortunately, I have another commitment now”
4. Learn to say NO

GDB Essential commands

Command	Abbr	Description
set args		set command args. Also can do: gdb --args command arg1 ...
break	b	set breakpoint (at function, line number, ...)
run	r	(re)start execution
continue	c	Continue execution
step	s	Next line
next	n	next line without recursing into functions
finish	fin	next line after this function returns
list	l	show source (for line, function, offset, ...)
backtrace	bt	Show the stack of functions. Add "full" to include local variables
up, down, frame	up, down, f	Move between current stack frames
watch	wa	break when variable changes value
display	disp	display expression each time program stops
info locals	i loc	display local variables
info threads	i thr	Display all threads
thread	thr	Switch to thread #
info breakpoints	i b	Display all breakpoints
Delete, enable, disable	d, en, dis	Delete, enable, disable breakpoint
help	h	display online help
focus next	fs n	switch window (allows cursor keys in CMD window for e.g.)
Ctrl-x a		Display code in another window
Ctrl-L		redraw the display (if program outputs for example)
print	p	Print value of expression
set variable	set v	Evaluate expression EXP and assign result to variable VAR
x/FMT	x/FMT	Examine memory

Sample .gdbinit file: 

# Set verbose printing of informational messages.
set verbose on
# Set printing of addresses
set print address on
# Set printing of object's derived type based on vtable info
set print object on
set print sym on
# Set prettyprinting of structures
#set print pretty off
# Set printing of C++ static members
set print static-members on
# Set demangling of encoded C++/ObjC names when displaying symbols
set print demangle on
# Unset printing of 8-bit characters in strings as \nnn
set print sevenbit-strings off
# Set prettyprinting of arrays
set print array on
# Set printing of array indexes
set print array-indexes
# Set printing of char arrays to stop at first null char
set print null-stop on
# Set printing of unions interior to structures
set print union on
# Set printing of C++ virtual function tables
set print vtbl on
# Set saving of the history record on exit
set history save on
# Set history expansion on command input
set history expansion on
# Set gdb's prompt
set prompt (onkar)

handle SIGCONT nostop

#### OTHER OPTIONAL SETTINGS ####
# Set a limit on how many elements of an array GDB will print. If GDB is printing a large array, it stops printing after it has printed the number of elements
# set by the set print elements command. This limit also applies to the display of strings. When GDB starts, this limit is set to 200. Setting number-of-elements
# to zero means that the printing is unlimited.
#set print elements number-of-elements


#source ~/stl-views-1.0.3.gdb

#set history filename     # TODO: enable this if reqd. Set the filename in which to record the command history

#catch throw

Useful commands:

Conditional breakpoint:

break main.cc:100 if i == 10

Repetitive commands:

b main()

(gdb) command 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>print i
>print j
>print k
>end

The directory command and setting source directory:

(gdb) directory ~/src/somepackage/src
Source directories searched: /home/nelhage/src/coreutils-7.4:$cdir:$cwd 

This requests gdb to search for source files in the given dir in addition to 

the existing directories.