[Python] Hello world in VSCODE

 Python   Visual Studio Code   

▌Introduction

---

Let’s see how to get the VSCODE ready for developing Python.

▌Configuration

---

▋Install Python

Go to Python.org and install it.

▋Install Python packages

Pylint: source code analyzer

$ python –m pip install pylint

autopep8: formats Python code to conform to the PEP 8 style guide

$ python –m pip install autopep8

▋Install VSCODE extensions

Python

Code Runner

▌Implement

---

Create a *.py file and write some codes.

# Number

num1 = 10

num2 = 20

num1 += 5

num2 += 5

sum = num1 + num2

print("Total = " + str(sum))

# Array

list = []

list.append("JB")

list.append("Lily")

list.append("Leia")

list.append("Hachi")

list.remove("Hachi")

for value in list:

    print("Name : " + value)

We will see the coding error message from Pylint.

And use Shift+ALT+f to format the codes.

After the codes are done, press F1 and key in “run code” to run the codes.

(Or use hot keys as the following picture)

▋Result

[Running] python "e:\Works\Source control\Github\KarateJB\Python.Practice\src\helloworld.py"

Total = 40

Name : JB

Name : Lily

Name : Leia

[Done] exited with code=0 in 0.159 seconds

▌Reference

---

▋docs.python.org

▋Python on Visual Studio Code

[.Net Core] Run unit test in VSCODE

 .NET Core    Unit Test       Visual Studio Code   

▌Introduction

---

Here are some quick ways to run unit tests in VSCODE.

▌Walk thru

---

▋Create a UnitTest project

Take MS TEST project for example.

$ dotnet new mstest --name Test $ cd Test $ dotnet restore $ dotnet build

▋VSCODE extension: C#

Install the C# extension in VSCODE.

And you can run the unit test on code lens.

Or simply use the dotnet cli command.

$ dotnet test

▋VSCODE extension: .NET Core Test Explorer

Install the .NET Core Test Explorer extension in VSCODE.

We can specify the target unit-test project relative path by the following work space settings.

▋settings.json

{

    "dotnet-test-explorer.testProjectPath": "Test"

}

Now we can use the .NET TEST EXPLORER to run the unit tests.

[GIT] Rebase

 GIT    rebase  

▌What is rebase

---

We can use rebase to copy the commits from other branch to another.

And after rebasing, we can merge and remove the source branch in order to get the clean single branch with all the commits.

▌Practice

---

Let’s create a new branch: NewBranch, and push a commit: New branch commit.

While there are a new commit: Master commit, on master.

▋Rebase

Now we will rebase NewBranch to master.

$ git rebase master NewBranch

Or

$ git checkout NewBranch $ git rebase master

▋Resolve conflicts

During the rebase process, we may encounter several conflicts.
Notice that we have to resolve these conflicts for every commit in NewBranch.

Here are the three ways to deal with conflicts while rebasing.

1.  Skip this commit

$ git rebase --skip

2.  After resolving the conflict, continue rebasing

$ git rebase --continue

3.  Abort rebasing process

$ git rebase --abort

▋Merge

After resolving conflicts and continue the rebase process.
The git commit graph should be as following, the commit: “New branch commit” is on local

Let’s merge NewBranch to master for merging the commit history to master.

$ git checkout master $ git merge NewBranch $ git push

And delete the NewBranch for a clean commit history.

$ git push origin --delete NewBranch $ git branch –d NewBranch

Which will result in the clean master.

Take a look at the git log of master.

▌Reference

---

▋連猴子都能懂的Git入門指南

▋Git 分支 - 分支的衍合

[MS Project] Reschedule - 設定專案基準

 專案管理    Reschedule   Microsoft Project  

在專案Kickoff後，隨著專案的進行，有很大的機率會reschedule，或者是原本預估的工期以無法反映現實，所以我們需要重新調整我們的時程，這時候我們可以利用「設定比較基準」先將目前的時程記錄下來，做完修正後，再與專案基準(Baseline)做比較並做預估和實際落差的分析。

以下以一教育訓練之計畫為範例；

下圖為預估的時程，我們會開始進行reschedule。

進行調整前，進入【專案】→【設定比較基準】

 

選擇要記錄在哪一個比較基準，另外建議是以整個專案做儲存。

 

完成後，我們另外拉出以下欄位：

1.  比較基準開始時間

2.  比較基準完成時間

3.  工期1 : 用來客製欄，以放工期差異天數

我們先來完成差異工期的公式設定。

在【工期1】欄位選擇自訂欄位。

 

更改欄位名稱以方便識別。

調整該欄位公式為：工期 減去 比較基準工期， 也就是reschedule和baseline的工期差異。

 

 

完成之後，我們可以開始進行reschedule。

我們將調整以下兩個工作：

1.  建立操作環境

2.  準備教材

未調整前：

調整【開始時間】和【完成時間】或工期，可以看到【與基準差異工期】已變更，可初步做出以下分析：

1.  建立操作環境：延後三天開始，且預期執行時間過於樂觀 (實際執行3MD > 預期執行2MD)。

2.  準備教材：延後三天開始，但實際執行時間提早兩天完成。

跨部門的專案reschedule的機會非常大，我通常會在提供第一版時程後馬上建立baseline； 除了留下記錄可以對照，另一方面可以一目了然造成專案delay的工作和哪些工作項目已經提早完成； 但並非是為了指責或推責，而是正視問題、了解原因。

未來在其他專案評估上，這些都是非常寶貴的經驗。