Monday, 14 January 2019

Publish Vuejs to gitlab pages tutorial

Vue.js is a highly acknowledged web application development framework competing against Google Angular and Facebook React. Gitlab is a git-repository website like github. It has been doing a lot engineering work to make integration easier between repository and static pages deployment for startups and community since Microsoft acquired github in 2018.

In this tutorial, we will walk you through deploying compiled Vue.js file to gitlab pages. Vuejs 3.0 or above is used. Lower version also works but with different config file and option(s). Please refer to Vuejs documentation.

As for gitlab pages, we use project page instead of personal/organizational page. Gitlab supports third party domain name, so it really does not makes big difference from engineering perspective.

We are starting from gitlab repository setup as following steps. And for your information, the example git repository is shared to you here.

1): Create a gitlab repository. Assume you are "hawwah"(Eve). So your gitlab user name is it as well. and the your repository name is applegarden.

2):Create a new file .gitlab-ci.yml in this repository through gitlab web page. This is a simple tutorial, so we are not going to maintain more complex CI/CD script in this file and it will be in the list of ".gitignore".
# This file is a template, and might need editing before it works on your project.
# Full project:
    stage: deploy
    - mkdir .public
    - cp -r * .public
    - mv .public public
      - public
    - master

3): We now clone it locally as below.

Bourne Shell:
  git clone /path/to/localAppleGarden

4): Goto your Vue project directory and edit the package.json file
Bourne Shell:
  cd /path/to/vueproject
  nano package.json

Find section "script" and add a new line in it so as the section like below:
Javascript code:
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "publishGitlab": "vue-cli-service build --dest /path/to/localAppleGarden",
    "lint": "vue-cli-service lint",

Create a file in your Vue project directory with name "vue.config.js" which contain below source.
Javascript code:
  module.exports = {
    publicPath: "/applegarden"

5): Then you build the project by below command
Bourne Shell:

  npm run publishGitlab

6): Now we go to compiled source and push them to gitlab origin.

Bourne Shell:

  git add --all
  git commit -m "Blahblahblah"
  git push origin master

7): At last, we can goto and the CI/CD as below screen shot.

Click the running status link, below screen shot showing that gitlab is copying the files to the "pubic" directory of a docker machine. Also you can goto serveless or kubernetes in GCP and got $300 credit directly through the native integration with GCP Kubernetes engine. Fantastic job, gitlab!

Finally, we can check deployed pages at "".

That's all. And you can further customize the page URL to your own domain. Even accelerate by deploying to, free! But it is different topic we are going to cover it next blog. Then I will update here a link. Stay tune!

Saturday, 8 December 2018

Is the rule of applying Long Arm Jurisdiction Statue broken?

The case against Ms. Meng Wanzhou is an application of Long Arm Jurisdiction Statue(LAJS). According to the accusation from Eastern NewYork (EDNY) court, the alleged fact breaking US law happened in Hongkong and the defendent is not a US citizen.

According to multiple authoritative sources[1], In Asahi Metal Industry Co. v. Superior Court, 480 U.S. 102 (1987), the Supreme Court clarified that even when the defendant has a minimum contact, a court's asserting jurisdiction over the defendant may still be improper as it would be unfair to the defendant. LAJS applicability here can be a subject which shall be retrospected seriously.

1): The legal basis of the accusation is possibly be either US domestic or UN resolution. But Eastern Newyork court is a US legal branch and not likely to be authorized by UN, we can safely assume it is US domestic law. To verify the statement, the original EDNY record needs to be obtained. A PACER account could be helpful if you have a credit card.

2): Even if the legal basis is a UN resolution, EDNY needs to follow a UN process to issue a warrant and request Canadian's extradition. If such a process is there for EDNY is out the discussion scope, so the assumption that this is a US domestic legal action is legitimate and reasonable.

3): So the fundamental purpose of the legal action is the national interests of US, even if Huawei's business is considered as a critical threaten to national security. It is unavoidable that there are conflicts each other between different countries such as China and US. Many of us has a opinion that Human Rights is superior to national sovereignty. If such a domestic legal action is viewed as part of national sovereignty, at least it shall respect Human Rights when applying LAJS.
4): The accusation against Ms Meng is not likely delivered to her before the Warrant is requested to Canadian legal organization. At least, Ms Meng is not aware of the accusation before her being arrested. Then before the judgement, it might take days, months, even years for legal process. It is obviously unfair to Ms Meng.

 5): Canadian's extradition to US for LAJS rationality shall be specifically considered and carefully reviewed. Unfortunately, I am not a legal professional and is not able to obtain historical case details and not so much public discussion going around main stream public media.

LAJS is a common practice in international affairs resolution, special interests preference is human weakness. Governments are very strong enforcement existence. So the application of LAJS shall be escalated to international community to prevent the chaos to lead to breaking of peace and harm to  human rights.

Wednesday, 18 April 2018





Tuesday, 27 February 2018









Friday, 22 December 2017


















Wednesday, 22 November 2017

Is Swift 4 horrible?

The project team of Boochord iOS recently reached the first version milestone for iPhone and is publishing on iOS App store and preparing to utter the joys to sky.

It employs Swift language version 4 as the primary language and the tool of XCode, AppCode, Cocoapods etc. Many people know the "famous" incompatibility between Swift different version and the pet peeves about String processing performance, optional design etc. How does the project team go through all caves and traps to arrive the status today? I would like share some experiences with you.

First, optional design is a good one which helps junior person to avoid many "nil", aka, null dead end problems in java / c environment. But it does not mean nil bugs are fully eliminated since the enforced optional unwrapping is still some times unavoidable. And besides, best practices within a team could vary depends on third party used and member preferences etc. e.g., guard vs if statement. So agreement on early time is always important to avoid the code messing by many ifs.

Second, string processing is kind of pain for those with Java background. Since the indexing is not by integer but String.Index. And String can not be easily converted / processed in the form of charater Arrays. It would be easy to fall into the performance trap considering there are also big difference on low level String functions. String's UnicodeScalar view is indeed useful in some situation but they are always useful. However's by our experiences, a bad design and implementation could be 100 times slower than Android processing. We are using IPhone 7 plus comparing to kind of middle level 3 years aged android brand phone like Xiaomi etc.

Third, XCode is kind of robust but sometimes staggering and slow. The source code is compiled and running but it still shows there are some code error. Sometimes we have to delete the derived data of compilation to get a clean visual world. But the good side is that it is dead seldom while AppCode does although it does better and quicker refactoring job like renaming, moving etc. I cannot see it is a shame of jetbrain because it is performing much better as in Android Studio.

Fourth, Interface builder is the proud of Apple and has very precise and flexible control to place graphical components at right places. Its auto-layout has much better and clear intuitive presentation of constraints than Android GUI designer in my point of view. But be very careful to use XML source view to edit story board / nib file. It is reckless and rude change probably from Apple's point of view. Because you could fail to start Xcode unless you can fix the error by external tool like vi or other text editor.

Fifth, third party integration sometimes out of control. As many as 50 percent cocoapods did not function at first installation and needs some tweaks / work rounds. And Swift package managers is still in infant phase could not provide meaningful help. Manual import in XCode seems the final solution almost in all cases. But the method brings in potential manage risk on package management for many processes that requires automation such as testing, upgrading, merging etc.

Overall speaking, Swift is evolving to a mature language and the version of Boochord is reached in as short as 3 months and passed all the tests with few bugs. Considering it is has many complex components of intensive timer tasks, incorporated many Artifitial Intelligence generated data marks, and many members are junior or with different tech stack experiences and they are confident with Swift now, I would like to say Apple did a good job in last year to make Swift competitive.