Technical vs. Fundamental Analysis: A Quick Distinction

Strictly technical traders focus on price history, chart patterns, and mathematical indicators rather than factors such as earnings, competitive positioning, or management quality. The goal is to identify trends and short-term price fluctuations that can be acted on quickly. Because these traders often hold positions for short periods, they pay close attention to support and resistance levels—price points where a stock has historically bounced or reversed.

Ichimoku Cloud: Span A vs. Span B

The Ichimoku Kinko Hyo (often shortened to Ichimoku Cloud) is a comprehensive indicator that plots several lines on a price chart. Two of the most watched are Span A and Span B, which together form the “cloud” (also called the Kumo).

• Span A is the midpoint of the Conversion Line and the Base Line, plotted 26 periods ahead.
• Span B is the midpoint of the highest high and lowest low over the past 52 periods, also plotted 26 periods ahead.

When Span A is above Span B, the cloud is colored green, which many traders interpret as a bullish signal—suggesting that upward momentum may be building. When Span B is above Span A, the cloud turns red, indicating a potentially bearish environment. Price trading above the cloud is generally considered bullish; price below the cloud is considered bearish.

Commodity Channel Index (CCI)

The Commodity Channel Index was originally developed by Donald Lambert for commodity markets but has since become a popular equity indicator. The CCI measures the difference between an asset’s current price and its historical average price, normalized by mean deviation.

Key interpretation guidelines:

• The indicator oscillates above and below a zero line.
• Readings typically stay within a range of -100 to +100 during normal market conditions.
• A reading above +100 may signal overbought conditions.
• A reading below -100 may indicate oversold territory.
• Readings between -100 and +100 are generally considered neutral.

Traders often combine CCI readings with trend direction to decide whether an extreme reading represents a reversal opportunity or simply a continuation of a strong trend.

Relative Strength Index (RSI)

The RSI is a momentum oscillator created by J. Welles Wilder, first introduced in his 1978 book New Concepts in Technical Trading Systems. It measures the speed and magnitude of recent price changes to evaluate whether an asset is overbought or oversold.

RSI ranges from 0 to 100:

• Readings above 70 are commonly interpreted as overbought.
• Readings below 30 are commonly interpreted as oversold.
• A reading near 50 suggests roughly balanced momentum.

The 14-period RSI is the most widely used setting, but traders also monitor shorter periods such as 3-day and 7-day RSI for near-term momentum shifts. Shorter RSI periods are more sensitive to recent price changes and will signal overbought or oversold conditions more frequently, while longer periods smooth out the data and generate fewer signals.

The RSI is calculated based on the average gain versus average loss over the chosen period, using closing prices. It is displayed as a line chart beneath the main price chart, making it easy to spot divergences—situations where the RSI moves in the opposite direction of price, which can sometimes foreshadow a reversal.

Moving Averages: 50-Day and 200-Day

Moving averages smooth price data to reveal the underlying trend direction. Two of the most commonly watched are the 50-day moving average (MA) and the 200-day MA.

• The 200-day MA is used to assess the long-term trend. Price consistently above the 200-day MA is generally considered a bullish sign.
• The 50-day MA provides a medium-term view and is often used alongside the 200-day to identify crossover signals.
• A Golden Cross—when the 50-day MA crosses above the 200-day MA—is widely considered a bullish signal.
• A Death Cross—when the 50-day MA crosses below the 200-day MA—is generally interpreted as bearish.

Traders may also watch the 20-day MA for shorter-term trend insights, particularly in fast-moving markets.

Average Directional Index (ADX)

Also developed by J. Welles Wilder, the ADX measures the strength of a trend—not its direction. It is plotted as a single line ranging from 0 to 100.

• Below 20: Suggests no discernible trend; the market may be ranging.
• 20–25: A borderline zone; the trend signal is not yet clear.
• Above 25: Generally indicates a strong trend is in place.
• Above 40–50: Indicates a very strong or extreme trend.

A rising ADX line means the existing trend—whether up or down—is gaining strength. A falling ADX line suggests the trend is weakening. The ADX itself does not indicate whether the trend is bullish or bearish; it must be read alongside directional indicators (the +DI and -DI lines) for that information.

Williams %R

Developed by Larry Williams, Williams %R is a momentum indicator that compares a closing price to the high-low range over a specified period (commonly 14 days). It is designed to identify when a security may be approaching an overbought or oversold extreme and could be due for a reversal.

Williams %R oscillates between 0 and -100:

• Readings between 0 and -20 are generally considered overbought.
• Readings below -80 are generally considered oversold.
• The further the reading is from the center, the more extreme the condition—and potentially the more likely a reversal could occur.

Like all oscillators, Williams %R works best in ranging markets. In strongly trending markets, overbought and oversold readings can persist for extended periods without producing a reversal, so traders typically use it in combination with a trend indicator such as ADX.

Combining Indicators: A Practical Approach

No single indicator tells the complete story. Experienced technical traders typically combine multiple signals to improve the reliability of their entries and exits:

• Use ADX to confirm whether a trend is strong enough to trade directionally.
• Use moving averages to determine overall trend direction.
• Use RSI or CCI to identify momentum and potential turning points within the trend.
• Use Williams %R to spot short-term overbought or oversold extremes.
• Use Ichimoku Span A/B for a multi-dimensional view of support, resistance, and trend bias.

Beginners are generally advised to master two or three indicators before adding more. A crowded chart with conflicting signals can create more confusion than clarity. Starting with a trend indicator and a momentum oscillator is a common and practical approach.

Final Thoughts

Technical indicators are tools, not guarantees. Each of the indicators covered here—Ichimoku Spans, CCI, RSI, ADX, and Williams %R—offers a different perspective on price behavior. Understanding the theory behind each indicator, including its strengths and limitations, helps traders apply them more effectively and avoid over-relying on any single signal. As with any trading methodology, risk management and position sizing remain critical regardless of how compelling the technical setup appears.

Overview

Continuous Integration (CI) for Salesforce metadata differs from traditional software CI because deployments target a cloud platform rather than a compiled binary. The Salesforce Metadata API, exposed through the ANT Migration Toolkit, is the standard mechanism for scripted deployments. By combining TFS (or its cloud-hosted equivalent, Visual Studio Team Services) with Apache ANT, teams can trigger automated retrieve-and-deploy cycles on every code commit or on a schedule.

This guide uses the cloud-hosted version of TFS (Visual Studio Team Services) to avoid the overhead of maintaining a local TFS installation, but the same build definition steps apply to an on-premises TFS server.

Prerequisites

• A Microsoft account (used to sign in to Visual Studio Team Services)
• Apache ANT installed on your local machine for local testing
• The Salesforce ANT Migration Toolkit (ant-salesforce.jar), downloaded from your Salesforce org’s Setup page
• A Git client (for example, TortoiseGit) for pushing code to TFS
• Credentials for the source and target Salesforce orgs

Step 1: Create a Developer Account on Visual Studio Team Services

Navigate to https://www.visualstudio.com/ and choose Get Started for free under the Visual Studio Team Services section. If you do not already have a Microsoft developer account, you will be prompted to create one during sign-up. Once registered, you will land in the VSTS dashboard where you can create your first Team Project.

Step 2: Create a TFS Git Repository for Your Salesforce Metadata

One advantage TFS has over Jenkins-based CI setups is that source control is built in — you do not need a separate GitHub or Bitbucket account. After logging in, use the New Project wizard to create a project. The wizard is straightforward: provide a project name, choose a version control type (select Git), and choose a process template.

Once the project exists, clone the repository to your local machine using any Git client. For authentication you can use your VSTS username and password, or generate an SSH key pair and register the public key in your VSTS profile under Security > SSH public keys. SSH key authentication is recommended for CI agents because it avoids storing plain-text passwords.

Step 3: Create and Test the ANT Deployment Script Locally

Before wiring ANT into TFS, verify that the scripts work correctly on your local workstation. You need two files in the root of your repository: build.properties (credentials and environment URLs) and build.xml (the ANT targets).

build.properties

This file stores environment-specific values. Keep it in version control for non-sensitive settings, but consider externalising passwords as TFS build variables or secrets so that plain-text credentials are never committed to source control.

# build.properties

# Server URLs
sfSandbox.serverurl = https://test.salesforce.com
sfPRO.serverurl    = https://login.salesforce.com

# Source org (retrieve)
sfdc.cb.df14.username        = your-source-org@example.com
sfdc.cb.df14.password        = yourPasswordPlusSecurityToken
sfdc.cb.df14.retrieveTarget  = src
sfdc.cb.df14.unpackaged      = src/package.xml
sfdc.cb.df14.retrieveMessage = Retrieve metadata from source Salesforce org

# Target org (deploy)
sfdc.cb.df15.username        = your-target-org@example.com
sfdc.cb.df15.password        = yourPasswordPlusSecurityToken
sfdc.cb.df15.retrieveTarget  = src
sfdc.cb.df15.unpackaged      = src/package.xml
sfdc.cb.df15.retrieveMessage = Deploy metadata to target Salesforce org

# Salesforce ANT JAR — path relative to repository root
sfdcJarFile = ant-salesforce.jar

build.xml

The build.xml file defines two ANT targets: df14 retrieves metadata from the source org, and deploy pushes that metadata to the target org. Notice that classpath points to ${sfdcJarFile}, which resolves to a path relative to the repository root. This is essential for cloud CI agents that have no pre-installed copy of the Salesforce JAR, so the JAR must be committed to the repository alongside the build scripts.

<project name="Deployment Scripts" default="deploy" basedir="." xmlns:sf="antlib:com.salesforce">

    <property file="build.properties"/>

    <!-- Retrieve metadata from source org -->
    <target name="df14">
        <taskdef resource="com/salesforce/antlib.xml"
                 uri="antlib:com.salesforce"
                 classpath="${sfdcJarFile}"/>

        <echo message="Retrieving as: ${sfdc.cb.df14.username}"/>

        <sf:retrieve
            username="${sfdc.cb.df14.username}"
            password="${sfdc.cb.df14.password}"
            serverurl="${sfPRO.serverurl}"
            retrieveTarget="${sfdc.cb.df14.retrieveTarget}"
            unpackaged="${sfdc.cb.df14.unpackaged}"/>
    </target>

    <!-- Deploy metadata to target org -->
    <target name="deploy">
        <taskdef resource="com/salesforce/antlib.xml"
                 uri="antlib:com.salesforce"
                 classpath="${sfdcJarFile}"/>

        <sf:deploy
            username="${sfdc.cb.df15.username}"
            password="${sfdc.cb.df15.password}"
            serverurl="${sfPRO.serverurl}"
            deployRoot="src"
            maxPoll="1000"
            testLevel="NoTestRun"
            checkOnly="false"
            pollWaitMillis="10000"
            rollbackOnError="true"/>
    </target>

</project>

To test locally, run the following command from the repository root:

ant df14 deploy

The df14 target retrieves metadata from the source Salesforce instance; the deploy target then pushes that retrieved metadata to the target instance. Confirm that both targets complete without errors before moving to the TFS build definition.

Files to commit to the repository

• build.xml
• build.properties (with passwords replaced by TFS build variables in production)
• ant-salesforce.jar — the Salesforce Migration Toolkit JAR, committed so the TFS cloud agent can find it
• src/package.xml — your metadata manifest
• src/ — the retrieved metadata directory

Step 4: Create a New Build Definition in Team Foundation Server

With the scripts in the repository, you can now tell TFS how to run them automatically.

In the VSTS portal, navigate to Build & Release → Builds → New definition and select the ANT template.

Select the repository and branch

On the repository selection screen, choose your TFS-hosted Git repository. You can also connect to GitHub, a remote Git server, or SVN if your code lives elsewhere. Select the branch you want this build definition to monitor. TFS supports multiple build definitions per project, so you can configure, for example, a nightly build on main and a triggered build on a develop branch independently.

Configure the ANT build step

In the build steps editor, configure the ANT task:

• ANT build file: build.xml
• Options: specify the targets to run, for example df14 deploy, or leave blank to use the default target defined in build.xml
• JDK version: ensure a compatible JDK is selected on the build agent

Save the build definition. You can trigger it manually the first time using the Queue build button to confirm everything works end to end before enabling a continuous integration trigger.

Security Considerations

Storing Salesforce credentials in build.properties and committing that file to source control is convenient for demonstration purposes but is a security risk in production. Instead:

• Define Salesforce usernames and passwords as TFS/VSTS build variables marked as secret. Reference them in build.xml using ANT property overrides passed via the build options field (e.g., -Dsfdc.cb.df15.password=$(SF_PASSWORD)).
• Use a connected app with OAuth and a session ID instead of username/password where your tooling supports it.
• Consider whether committing ant-salesforce.jar to Git is appropriate for your organisation; an alternative is to download it as an artifact during the build using a script step.

Summary

Setting up Salesforce CI with TFS involves four main steps: creating a VSTS account and project, pushing your Salesforce metadata and ANT scripts (including the Salesforce JAR) to the built-in Git repository, validating the ANT script locally, and then creating an ANT build definition in TFS that executes the same script on every commit or on a schedule. The integrated source control in TFS/VSTS reduces the number of third-party tools required compared to a Jenkins-based approach, making it a practical choice for teams already in the Microsoft ecosystem.

Original source: jitendrazaa.com