anonymoussc

Smart Money Concept

Tue, 21 May 2024 22:08:00 +0000

The Smart Money Concept refers to the idea that professional and institutional traders, known as “smart money,” have a significant influence on the financial markets. These traders are often characterized by their deep knowledge, extensive resources, and access to market data that may not be readily available to individual retail traders.

The concept suggests that by closely monitoring the actions and patterns of smart money participants, retail traders may potentially gain insights and make more informed trading decisions. It assumes that smart money tends to enter or exit the market before major price movements occur and that tracking their activities can provide valuable indications of market direction.

Methods and indicators used to analyze and identify smart money behavior include:

Volume Analysis: Analyzing trading volume to identify periods of high activity and significant institutional involvement.
Price Action: Observing significant price movements or abnormal price patterns that may signal smart money activity.
Order Flow Analysis: Evaluating the flow of buy and sell orders to identify large-block trades or hidden accumulation or distribution of assets.
Commitment of Traders (COT) Reports: Reviewing the COT reports, which provide insights into the positioning of different market participants, including commercial traders who are often considered the smart money group.

It’s important to note that the Smart Money Concept is based on observations and analysis but does not guarantee profitable trading outcomes. Market dynamics are complex, and relying solely on tracking smart money can be challenging. It is recommended to use the concept as part of a comprehensive analysis, including other technical and fundamental factors, to make well-rounded trading decisions.

As always, it’s advisable to conduct thorough research, practice risk management, and consider seeking guidance from professional financial advisors before making any trading decisions.

Xtiusd Symbol

Tue, 21 May 2024 20:16:00 +0000

XTIUSD refers to the trading symbol for the crude oil market. In this trading symbol, XTI represents West Texas Intermediate (WTI) crude oil, which is a high-quality oil predominantly produced in the United States. USD represents the currency pair, indicating that the pricing is done in US dollars.

Crude oil is one of the most actively traded commodities in the world, and its price is influenced by various factors such as global supply and demand dynamics, geopolitical events, inventories, and economic indicators. Traders and investors often analyze the XTIUSD chart and market trends to make trading decisions or hedge against oil price fluctuations.

When trading XTIUSD, traders can speculate on the future price movements of crude oil and take positions accordingly. It is essential to conduct thorough market analysis and consider risk management strategies before trading any financial instrument, including XTIUSD.

Please note that trading commodities, including crude oil, carries risks, and it’s advisable to seek guidance from a professional financial advisor before engaging in such trading activities.

Sending and receiving messages with Spring Cloud Stream code example

Tue, 06 Oct 2020 06:17:00 +0000

Spring Cloud Stream provides a streaming abstraction over messaging, based on the publish and subscribe integration pattern. Spring Cloud Stream comes with out of the box support for Apache Kafka and RabbitMQ but can be extended to support other messaging brokers using custom binders.

The Message class

public class MyMessage {
    private String attributeFirst = null;
    private String attributeSecond = null;
    ...

Spring Cloud Stream comes with default input and output channels, Sink and Source.

To publish a message

import org.springframework.cloud.stream.messaging.Source;

@EnableBinding(Source.class)
public class MyPublisher {

@Autowired private Source source;

public String processMessage(MyMessage message) {
    source.output().send(MessageBuilder.withPayload(message).build());
    ...

To receive messages

import org.springframework.cloud.stream.messaging.Sink;

@EnableBinding(Sink.class)
public class MySubscriber {

@StreamListener(target = Sink.INPUT)
public void receive(MyMessage message) {
    LOG.info("Received: {}",message);
    ...

To bind to RabbitMQ, include in build.gradle

    implementation('org.springframework.cloud:spring-cloud-starter-streamrabbit')

The configuration for the publisher

spring.cloud.stream:
    default.contentType: application/json
    bindings.output.destination: mydestination

The configuration for the subscriber

spring.cloud.stream:
    default.contentType: application/json
    bindings.input.destination: mydestination

We’re surrounded by distractions. Whether it’s emails, phone calls, text messages, social media notifications, or people entering and leaving your workspace, those distractions end up eating a good portion of your time. - John Rampton

The twelve-factor app

Tue, 06 Oct 2020 04:07:00 +0000

The twelve-factor app is a methodology for building software-as-a-service apps that:

Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

For more details please check here

The most essential factor is persistence - the determination never to allow your energy or enthusiasm to be dampened by the discouragement that must inevitably come. - James Whitcomb Riley

The 8 fallacies of distributed computing

Thu, 01 Oct 2020 16:56:00 +0000

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences:

The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn’t change
There is one administrator
Transport cost is zero
The network is homogeneous

Peter Deutsch, 1994

For more details please check fallacies.pdf.

Science is simply common sense at its best, that is, rigidly accurate in observation, and merciless to fallacy in logic. - Thomas Huxley

Set, unset and get git global http.proxy configuration

Sun, 10 May 2020 16:56:00 +0000

Set

git config --global http.proxy http://proxyusr:proxypwd@proxy.server.com:80

Unset

git config --global --unset http.proxy

Get

git config --global --get http.proxy

Good, better, best. Never let it rest. ‘Til your good is better and your better is best. - St. Jerome

NSIS or MSI installer type install to custom directory in Windows

Sun, 26 May 2019 08:12:00 +0000

NSIS

-ia "'/D=D:\usr\Program Install\Name'"

MSI

INSTALLDIR=""D:\usr\Program Install\Name""

Good, better, best. Never let it rest. ‘Til your good is better and your better is best. - St. Jerome

Syntax highlighting support by GitHub flavored markdown

Sat, 25 May 2019 04:58:00 +0000

Github uses Linguist to perform language detection and syntax highlighting. See full list in Linguist - languages.yml.

actionscript3
apache
applescript
asp
brainfuck
c
cfm
clojure
cmake
coffee-script, coffeescript, coffee
cpp - C++
cs
csharp
css
csv
bash
diff
elixir
erb - HTML + Embedded Ruby
go
haml
http
java
javascript
json
jsx
less
lolcode
make - Makefile
markdown
matlab
nginx
objectivec
pascal
PHP
Perl
python
profile - python profiler output
rust
salt, saltstate - Salt
shell, sh, zsh, bash - Shell scripting
sql
scss
sql
svg
swift
rb, jruby, ruby - Ruby
smalltalk
vim, viml - Vim Script
volt
vhdl
vue
xml - XML and also used for HTML with inline CSS and Javascript
yaml

Good, better, best. Never let it rest. ‘Til your good is better and your better is best. - St. Jerome

Commit message format

Mon, 14 Jan 2019 03:57:00 +0000

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, an optional scope (when applicable) and a subject:

Without scope

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

With scope

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 100 characters. This allows the message to be easier to read on GitHub as well as in various git tools.

Footer should contain a closing reference to an issue if any.

Samples:

docs(changelog): update change log to alpha.9

fix(release): need to depend on package

The version in our package.json gets copied to the one we publish, and users need the latest of these.

Revert

If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Type

Must be one of the following: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test

build: Changes that affect the build system or external dependencies (example scopes: gulp, npm, webpack)
chore: Other changes that don’t modify src or test file
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, etc)
docs: Documentation only changes
feat: A new feature
fix: A bug fix
perf: A code change that improves performance
refactor: A code change that neither fixes a bug nor adds a feature
revert: Reverts a previous commit
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
test: Adding missing tests or correcting existing tests

Subject

The subject contains succinct description of the change:

use the imperative, present tense: “change” not “changed” nor “changes”
don’t capitalize first letter
no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: “change” not “changed” nor “changes”. The body should include the motivation for the change and contrast this with previous behavior.

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Good, better, best. Never let it rest. ‘Til your good is better and your better is best. - St. Jerome

Html symbol for celsius and fahrenheit

Tue, 18 Dec 2018 22:46:00 +0000

Celsius :

&#8451

Fahrenheit :

&#8457

Good, better, best. Never let it rest. ‘Til your good is better and your better is best. - St. Jerome