Chỉ báo Ultimate Oscillator

Ref: https://www.investopedia.com/terms/u/ultimateoscillator.asp

Chỉ báo này cho biết về:

  • thay đổi giá
  • tính toán tích luỹ và giá thay đổi trong ngắn hạn
  • thời điểm mua và bán

Case study: HSG

Nhận định:

  • Diễn biến của HSG chia làm 2 giai đoạn tăng điểm mạnh và 1 giai đoạn giảm nhẹ
  • Quá trình tăng điểm đều đặn ít sideway

Áp dụng UO:

  • Đầu gđ1 đầu tháng 4, ở đồ thị giá tiếp tục đi xuống, đồ thị UO xuống dưới 30 và đi ngược lên vượt qua đỉnh gần nhất của đồ thị UO => tín hiệu mua.
  • Cuối tháng 6, giá tiếp tục tăng, nhưng đồ thị UO đã giảm, hình thành đáy thấp hơn đáy trước.
  • Cuối tháng 7, hiện tượng tăng giá lặp lại: đồ thị UO xuống dưới 30 và vượt lên trên đỉnh UO trước đó.
  • Cuối đồ thị cho thấy tuy đã xuống dưới 30 nhưng chưa đủ điều kiện để mua vào

Nhận định:

  • Chỉ báo UO xác định xu hướng tăng chậm hơn các chỉ báo khác
  • Dự báo kém các đợt giảm giá
  • Dựa nhiều vào tình huống break-out của giá trong chu kỳ gần đây => dễ sai lầm

Xem thêm: http://chungkhoanphaisinh.org/chi-bao-ultimate-oscillator

Homework: dự báo về VNM

Chỉ báo Chaikin và MACD

Ref: https://www.investopedia.com/terms/c/chaikinoscillator.asp, https://www.investopedia.com/terms/m/macd.asp

Chỉ báo này cho biết về:

  • trend
  • tính toán tích luỹ và giá thay đổi trong ngắn hạn
  • thời điểm mua và bán

Lý do kết hợp 2 chỉ báo này là vì MACD đo lường xu hướng giá nhưng không tính tới dòng tiền (volume), trong khi Chaikin dựa trên MACD kết hợp với (volume) nên có tác dụng khẳng định lẫn nhau.

Case study: GEX

Nhận định:

  • Diễn biến của GEX chia làm 2 giai đoạn: gđ1 tăng đều trong 1 khoảng thời gian dài, và gđ2 giảm dần ở thời điểm cuối
  • Quá trình tăng đi kèm với nhiều đợt đổi chiều xen kẽ

Áp dụng Chaikin và MACD:

  • Đầu gđ1 đầu tháng 4, ở MACD ta thấy đường màu tím từ dưới đi lên cắt đường màu đỏ (signal line) ở mốc -1000 báo hiệu 1 xu hướng tăng giá nhẹ, khoảng cách giữa 2 đường bám sát nhau thể hiện xu hướng tăng đều chứ ko đột biến về giá. Cùng lúc này, đường Chaikin ở vị trí mấp mé đường trung bình (đường gạch đứt màu xanh).
  • Giữa tháng 5, hiện tượng trên tiếp tục xảy ra ở cả 2 chỉ báo cắt đường Signal Line, báo hiệu thời điểm mua.
  • Tuy nhiên, ở thời điểm đầu tháng 6, chỉ báo Chaikin đã ko dự đoán đc xu hướng giảm điểm của cp này. Đầu tháng 7, 2 chỉ báo đã đúng, nhưng giữa tháng 7 2 chỉ báo này lại tiếp tục thất bại trong đánh giá.
  • Thời điểm đầu tháng 9, 2 chỉ báo cho thấy thời điểm mua.
  • Gđ2 2 chỉ báo cho thấy 1 xu hướng giảm giá vào giữa tháng 9. Đến những ngày cuối cùng thì Chaikin dự báo 1 xu hướng tăng điểm mạnh trong khi MACD thì ko có gì.

Nhận định:

  • Chỉ báo MACD nhạy hơn Chaikin trong xác định xu hướng tăng
  • Dự báo kém các đợt giảm giá
  • Độ chính xác không cao

Homework: dự báo về DBC

Quảng cáo

Chỉ báo Historical Volatility

Ref: https://www.investopedia.com/terms/h/historicalvolatility.asp

Chỉ báo này cho biết về:

  • giá
  • cường độ biến động giá

Case study: Lộc Trời Group – LTG

Nhận định:

  • Diễn biến của LTG chia làm 2 giai đoạn: 1 – giảm dần đều, 2 – tăng nhanh
  • Gđ 2 có một số biến động bất thường

Áp dụng Historical Volatility:

  • Đường HV thể hiện sự thay đổi về giá diễn ra ổn định, dù là giá giảm giần
  • Gđ1 – sự biến động về giá có tính chu kỳ hàng năm
  • Gđ2 có sự biến động mạnh về giá do thông tin về tái cấu trúc doanh nghiệp, sau đó sự biến độ trở lại như cũ

Nhận định:

  • Không có tính dự báo tương lai
  • Hiệu quả kiểm tra dao động giá theo chu kỳ thời gian
  • Đánh giá tiềm năng lãi/lỗ của cổ phiếu
  • Thời gian cần đủ dài để nhận định hiệu quả nên không phù hợp với cp mới lên sàn

Đọc thêm: https://vietnambiz.vn/bien-dong-trong-qua-khu-historical-volatility-hv-la-gi-20200506222735859.htm

Homework: đánh giá về PNJ

Chỉ báo Klinger

Ref: https://www.investopedia.com/terms/k/klingeroscillator.asp

Chỉ báo này cho biết về:

  • trend
  • dài hạn
  • thời điểm đổi chiều

Case study: Thế giới di động – MWG

Nhận định:

  • Diễn biến của MWG chia làm 3 giai đoạn: 1 – giảm mạnh, 2 – tăng nhẹ và ổn định, 3 – tăng mạnh
  • Gđ 2 có những diễn biến tăng giảm thường xuyên

Áp dụng Klinger:

  • Đường màu xanh lá cây là đường đường tín hiệu (signal line), đường màu tím là đường Klinger, 2 đường này di chuyển quanh mốc 0 biểu thị cân bằng volume mua và bán
  • Đường Klinger cắt đường Signal line là dấu hiệu đổi chiều, nếu Klinger đi từ dưới lên cắt Signal Line và lên trên mốc 0 => uptrend, ngược lại thì là down trend. Điểm cắt càng xa mốc 0 thì trend càng dài.
  • Gđ 1 Klinger từ trên đi xuống cắt Signal Line và down trend, 2 đường di chuyển dưới 0.
  • Gđ 2 Klinger đi lên cắt Signal Line đồng thời vượt mốc 0 => xu hướng uptrend dài hạn. Cuối gđ 2 hiện tượng này lặp lại
  • Một số lần giao cắt khác xảy ra và đều ở cao hơn mức 0 khá xa => xu hướng đổi trend ngắn hạn.

Nhận định:

  • Khó phân biệt đc xu hướng thay đổi là ngắn hay dài hạn do các lần giao cắt khá thường xuyên
  • Độ chính xác không cao

Homework: dự báo về HPG

Chỉ báo Aroon

Ref: https://www.investopedia.com/terms/a/aroonoscillator.asp

Chỉ báo này cho biết về:

  • Trend
  • mạnh – yếu – lâu dài
  • thời điểm trend thay đổi (2 đường cắt nhau)

Case study: Thế giới di động – MWG

Nhận định:

  • Diễn biến của MWG chia làm 3 giai đoạn: 1 – giảm mạnh, 2 – tăng nhẹ và ổn định, 3 – tăng mạnh

Áp dụng Aroon:

  • Đầu gđ 1, 2 đường cắt nhau ở gần mốc 100, báo hiệu 1 pha đảo trend rất mạnh
  • Cuối gđ 1, 2 đường cắt nhau ở gần mốc 50 => đảo trend nhẹ
  • Giữa gđ 2 có những sóng nhỏ: đường đỏ nằm trên và sát xanh => tăng nhẹ trong ngắn hạn, và ngược lại, xanh nằm trên sát đỏ => giảm nhẹ trong ngắn hạn
  • Cuối gđ 2, đầu gđ 3 có 1 số giao cắt và tương ứng với những lần đổi chiều.

Hạn chế:

  • Chỉ báo dường như hơi trễ so với diễn biến thực tế
  • Ko dự báo đc các pha tăng/giảm bền vững

Đọc thêm: https://traderviet.com/threads/chi-bao-aroon-cong-cu-giup-trader-xac-dinh-cac-giai-doan-cua-thi-truong.6165/

Homework: thử dự báo con này xem

How to create a HTML5 Ad Banner

Screen Shot 2015-09-19 at 3.58.40 pm

Basic about HTML5 banner

What is HTML5 Banner? – they are pieces of HTML5 that display advertisements.

The Banner HTML5 Format is a standard in-page ad that works on every platform that supports HTML5 technology (PC, cellphone, tablet, etc.). It can contain video or audio.

Why do we need them? – in the past, most of advertisements are Flash, because they are small and animation rich. But Flash is no longer supported by major browsers and will soon become a dead technology. HTML5 banner emerges as a replacement.

What’s the differences between HTML5 banner and regular HTML webpage? – HTML5 banner, like Flash ad, is a standalone piece, which is running separately from its host pages with its own resources, while regular HTML webpage is a part of the site content and share the same resources with all other pages. Because of this characteristics, HTML5 banner can be deployed at any place as a self-contained media.

What makes up of a HTML5 banner? – No alien languages, they are just HTML5, CSS, Javascript. Anything fancy would be considered dangerous since some browsers may not support them. We want the ads to run at most places it can so the technologies must be simple enough and well-supported.

Specification of HTML5 Banner

The specification might be lengthy, fully described here. This document covers all best practices one should follow to develop a HTML5 banner piece that is up to industrial standard.

TL;DR – The deliverables of a HTML5 banner include:

  • ZIP file containing:
    • index.html main file
    • Javascript, CSS files used in it
    • External media files used in it (Images, videos, sounds, XML, etc.).
  • Backup image

The zip file size must not exceed 100kb, and for the backup image, it must not exceed 40kb. In fact, the size of the resources does not really matter since they can be ziped upon transport and cached. But there is an industrial requirement anyway.

Looks complicated enough, so how do you actually creat a HTML5 ad banner?

Create a HTml5 ad banner

A piece of HTML5 ad banner often consist of following:

  • A pre-defined size: 150×100, 300×250, 720×90, etc. they are standard.
  • A collection of images, videos, audios
  • A series of animation that needs to play from start to end

A file structure might look like below:
Screen Shot 2015-09-19 at 3.10.52 pm

This structure very well deals with the elements above:

  • app.css – specify dimension, position and other attributes of every element in the Ad. CSS for HTML5 banner does not need to be beautiful, it just needs to be concise and fast.
  • app.js – contains all the code to control the animations.
  • sizzle.min.js – the selector engine used by jQuery, you do not need the whole jQuery bundle due to lack of space.
  • TweenMax & TimelineMax – a robust library to perform animation, it is small, cross-browser and high performance

The first file we need to create is the index.html

<!DOCTYPE html> 
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
   <title>GSAP animation</title>
   <link rel="stylesheet" href="app.css"/>
   <script src="TweenLite.min.js"></script>
   <script src="TimelineMax.min.js"></script>
   <script src="easing/EasePack.min.js"></script>
   <script src="plugins/CSSPlugin.min.js"></script>
   <script src="sizzle.min.js"></script>
   <script src="share.js"></script>
   <script src="app.js"></script>
</head>
<body> 
   <a id="myAdLink" href="http://www.example.com"> 
      <div id="myAd">
        <div id="frame1" class="bn"></div>
        <div id="frame2" class="bn"></div>
        <div id="frame3" class="bn"></div>
        <div id="frame4" class="bn"></div>
        <div id="frame5" class="bn"></div>
        <div id="frame6" class="bn"></div>
      </div> 
   </a>
</body>
</html>

All elements are there but hidden from view. It is different from normal approach that generate DOM elements based on needed. HTML5 Ad Banner focuses on visual effects, not DOM efficiency. So everything is there we just need to manipulate them and ignore complexity of adding/removing elements.

We will specify visual attributes of the elements in CSS file as below:

a#myAdLink { display: inline-block; background-color: #2480d6; }
#myAd { width: 300px; height: 250px; background-color: #f28023; border: 1px solid #ccc; position: relative; overflow: hidden; }
#myAd img { position: absolute; top: -90px; }
.bn {
  position: absolute;
  left: 0;
  top: -250px;
  width: 300px;
  height: 250px;
  background-repeat: no-repeat;
  background-position: 0 0;
}
#frame1 {
  background-image: url('data:image/png;base64,iVBORw0KGgoAAAANS...SuQmCC');
}
#frame2 {
  background-image: url('data:image/png;base64,iVBORw0KGg...5CYII=');
}

As you may notice, the images are encoded into base64 string. Reason? Because of:

  • All resources must be local to the html file
  • Images are available immediately, it is bad if the animate starts but images aren’t fully loaded yet.

Now, it’s time to start manipulating the frames. We will start with #frame1 till the last frame.

window.onload = function(){
    var f1 = $('#frame1'),
        f2 = $('#frame2'),
        f3 = $('#frame3'),
        f4 = $('#frame4'),
        f5 = $('#frame5'),
        f6 = $('#frame6');

    var tl = new TimelineMax();
    // Copy drops from top down and bounce, stays for 2 seconds then disappear
    tl.to(f1, 2, { y: 250, opacity: 1, ease: Bounce.easeOut }) 
      .stay(f1)
      .to(f1, 0.5, { y: -250, opacity: 0, ease: Power1.easeIn });

    // Copy drops from top down, stays for 2 seconds and ease out
    tl.to(f2, 2, { y: 250, opacity: 1, ease: Bounce.easeOut })
      .stay(f2)
      .to(f2, 0.5, { y: -250, opacity: 0, ease: Power1.easeIn });
....

Regarding the animation, there will be a lot of animation libraries out there to choose from. Greensock was chosen here because it is small, animation packed and solid. If you want to display your Ad on Canvas, perhaps you should choose something like Raphael.

After all hard work done, you can open your ad from index.html in any browswer and enjoy the result!

P.S: alternatively you can use online services like html5maker to produce the ads, but you won’t have full control over the code and it is easy to get stucked.

thethanghn 🙂

How to link to your local nodejs module from your Javascript project

It is not always not obvious to do this, that’s why there is this note:

1. Build your local module

Go to the root folder of your module (where the file package.json is) and run this:

$ npm run-script build-npm

This command will push your files into output folders, which can be referenced by comsuming project.

2. Update your project package.json

It is similar to Rails, you can refer to local module as well as Git module, like below:

{
  "name": "myproject",
  "version": "0.2.0",
  ...
  "dependencies": {
    "@thethanghn/react-bootstrap-datetimepicker": "file:/Users/justin/react-bootstrap-datetimepicker",
    ...
  }
}

You may notice I used a scoped name, because this module is forked from already published module on Npm.

3. Install the module

Now, everything is ready to go, we can install the module specifically:

$ npm install @thethanghn/react-bootstrap-datetimepicker

Notice that we install the module along with its scope, since it is not the original module. With this, we can update our module over and over to make sure everything works well, then we can go to the next step.

4. Publish your module if you want

Publishing our work could be coool! But it also to allow other people to use the module, or allow server to download it. You will need to publish the module to npm to allow online access.

$ npm publish

Then, we are ready to use the online version instead of our local one:

{
  "dependencies": {
    "@thethanghn/react-bootstrap-datetimepicker": "^0.0.21",
    ...
  }
}

That’s it!

Introduction about Mocha.js

Mocha

Mocha is a feature-rich JavaScript test framework running on Node.js and the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.

Test case example

It is a full-featured test frameworks, i.e. it covers everything that a test framwork should have. It may be lengthy and unnecessary to describe its features, so let’s have a look at this test file:

describe('Array', function() {
    before(function() {
      // ...
    });

    describe('#indexOf()', function() {
      context('when not present', function() {
        it('should not throw an error', function() {
          (function() {
            [1,2,3].indexOf(4);
          }).should.not.throw();
        });
        it('should return -1', function() {
          [1,2,3].indexOf(4).should.equal(-1);
        });
      });
      context('when present', function() {
        it('should return the index where the element first appears in the array', function() {
          [1,2,3].indexOf(3).should.equal(2);
        });
      });
    });
  });

A sample output:

Ajax & promise handling

Mocha makes it easy to write test spec for these operations.

Asynchronous callback

describe('User', function() {
  describe('#save()', function() {
    it('should save without error', function(done) {
      var user = new User('Luna');
      user.save(done);
    });
  });
});

`done` is a special callback provided by Mocha so that it knows when the test case finishes.

Promise

`promise` is a new convention for asynchronous operation, it simplifies the way to handle output of the operation, therefore it grows fast in popularity.

beforeEach(function() {
  return db.clear()
    .then(function() {
      return db.save([tobi, loki, jane]);
    });
});

describe('#find()', function() {
  it('respond with matching records', function() {
    return db.find({ type: 'User' }).should.eventually.have.length(3);
  });
});

Assertions

One thing to note that Mocha does not provide an assertion library, it rathers use node’s assert module or following:

  • should.js BDD style shown throughout these docs
  • expect.js expect() style assertions
  • chai expect(), assert() and should style assertions
  • better-assert c-style self-documenting assert()

They all are capable of performing necessary assertions so the decision pretty much depends on your coding style.

In conclusion, Mocha is a feature-rich test framework with very simple setup and you can immediately put it into use. It supports various coding styles so that if you are already familiar with one of famous testing frameworks you may find yourself at home when you use Mocha.

🙂

Introduction about Karma.js

We have known about Webpack, let’s explore another great tool: Karma (a great name!)

Karma is essentially a tool which spawns a web server that executes source code against test code for each of the browsers connected. The results for each test against each browser are examined and displayed via the command line to the developer such that they can see which browsers and tests passed or failed.

What is good about Karma?

Well then Karma can do following things for you:

  • Starts a web server
  • Executes test AGAIN for every connected browser
  • Shows test result out put in console

To be able to launch a browser is important, because it allows us to access real DOM and take screenshots.

Samples

Let’s have a look at a simple Karma configuration file:

module.exports = function(config) {
 config.set({
   basePath: 'js',

   files: [
     'vendor/jquery/jquery.min.js',
     'vendor/handlebars/handlebars.js',
     'vendor/ember/ember.js',
     'app.js',
     'tests/*.js',
     'templates/*.handlebars'
   ],

   browsers: ['PhantomJS'],
   singleRun: true,
   autoWatch: false,

   frameworks: ['qunit'],

   plugins: [
     'karma-qunit',
     'karma-ember-preprocessor',
     'karma-phantomjs-launcher'
   ],

   preprocessors: {
     '**/*.handlebars': 'ember'
   }
 });
};

Or we can even make a combination with Webpack:

module.exports = function(config) {
  config.set({
    frameworks: ['mocha', "chai"],
    files: [
      'src/spec/**/*.spec.*'
    ],
    webpack: {
      module: {
        loaders: [{
          test: /\.jsx$|\.js$/,
          loaders: ['babel']
        }]
      }
    },
    preprocessors: {
      'src/spec/**/*.spec.js': ['webpack']
    },
    plugins: [
      require('karma-webpack'),
      require('karma-chai'),
      require('karma-mocha')
    ]
  });
};

As you can see from the 2nd example, with the power of webpack, we don’t need to include so many files in at files section.

Why should we use Karma?

In general, Karma has similar features like Webpack: preprocessors, plugins, loaders, etc. (maybe they learnt from each other) The strength of Karma lies in its abilities to run test code on different browsers and gives out output. This output can subsequently be used in reporting service like: Travis CI, Jenkins CI, etc. it also supports famous test frameworks like Mocha and Qunit. With Karma running in background, you are confident to write quality code 🙂

Introduction about Webpack.js

Since the emergence of Nodejs, JavaScript tools have moved from merely client helper libraries into a totally new territory called server side. That’s why there is a boom of javascript tools lately and we are going to look into some of them. First begin with Webpack.

Webpack

// webpack is a module bundler
// This means webpack takes modules with dependencies
// and emits static assets representing those modules.

For example, in .NET, when we press `publish`, the source code gets compiled and moved to another folder, ready for us to deploy it to production server. It is exactly the job that Webpack does.

Something like this can only appear when server-side javascript becomes available, back then, it was handled by other server-side languages like C#, Ruby, etc. now we got it right in Javascript.

Here is a diagram illustrating how it works:

Why Webpack is useful?

Webpack does not merely copy things around, it does following things for us in the process:

  • Bundles everything into a single file
  • Compiles different file types into vanilla JavaScript, e.g. coffee to js
  • Auto-handle library dependencies
  • Supports various optimazation
  • Shipped with a small `webpack-dev-server` for us to run the bundle immediately

So, we can say that with Webpack, we have more freedom to write the code without having to think so much about optimizing file structure.

Some other cool things about Webpack you should know

Get Started
Webpack is very easy to get started with, following this tutorial, you can easily transform your page into an application.

Loaders

Loader is the tool for Webpack to know about a file type and the way to process it, i.e. for each file type there will be a respective loader. Without loaders, Webpack cannot know how to compile CoffeeScript or TypeScript into JavaScript. The list of loaders is very long, but it supports all the major stuff, for example: handlerbars and jsx.

Dependencies

Handling dependencies is one of important reasons to choose Webpack, we expect that after going through bundling process, everything still work smoothly. Webpack can work with Requirejs, CommonJs, or even inine javascript inclusion.

Code Splitting

Bundles everything into a single javascript file is not always a good thing, such as in very big application. Thus, Webpack supports Code Splitting that is to split the bundle into smaller chunks which can be loaded separately or on demand. Well, it is … useful in some certain scenarios.

Plugins

Plugins are for intercepting with bundling process and inject your own commands, so you can freely control the output at every step.

Webpack is a huge tool and there are still a lot more things we can talk about, but let’s try to use it and you will find how convenient it is for project deployment.

🙂