標籤

2018年12月11日 星期二

路線規劃APP

Date: 20181107
Version: 1

主要發想是來自於業務中,廠商使用Google Map來進行製作路線規劃,但其中有許多不太完善的地方,例如路線很奇怪,票價有問題...等,於是我就想說為什麼會這樣呢?難道很難嗎?於是上網查了Google Map API,詳細閱讀了文件後,覺得並沒有那麼困難,只是有很多參數需要加入,另外,在PTX中,也發現了正確的票價,使用以上工具可以解決我遇到的問題。

於是我就想做一個路線規劃的APP,但目前Android Studio還在學習當中,因此還是使用App Inventor 2來製作此APP。

  1. Google Map API,有12個月試用期,共300美元的額度可使用。
    • 會得到一組API KEY,呼叫API時使用。
    • 有JSON和XML兩種格式。
    • 有諸多參數可以設定,請查說明文件
  2. PTX,有分會員等級,但不成為會員還是可以用,只是額度更少
    • 會員有三種等級+未註冊,共4種等級,每一等級之權利義務不同。
    • 可提供預覽介面,可直接製作需要的API。
    • API中可輸入的功能很多,請查說明文件
    • 後來進行製作時發現,不成為會員的話,只能透過Swagger使用,無法在APP上使用,有權限管理,所以後來還是申請了會員。

製作過程:

  1. 需要先產生各路線對照表,包含place_id、代號、關鍵字、車站...等,並產生相對應的json object or array。
  2. 使用Google Map API及PTX API確認相關參數的使用狀況,決定後續要使用那些參數。
  3. 使用下拉式選單建立出路線和車站,提供路網圖給旅客查詢路線。
  4. Google Map API程式:
    1. 將車站轉出對應的place_id,並進行搜尋。
    2. 抓出連結資料。
    3. 將頭尾的步行刪除,因從車站出發。
    4. 抓出節點資料,利用關鍵字及路線校正,獲得正式名稱。
    5. 路線顯示。
  5. PTX程式:
    1. 找出同一家捷運公司的起迄站,並對應出各車站代碼。
    2. 利用代碼搜尋。
    3. 跟Google不太一樣,須建立header才行,請查說明文件
    4. 找出單程票票價。
    5. 將桃捷與北捷的票價加總,並顯示。
  6. 一開始使用圖片,但發現無法放大縮小,因此改為使用網頁瀏覽器,可以放大縮小,寫了個Html來展示台北捷運路網圖。
  7. 介面優化/程式優化,進行中。
    1. 介面優化:
      1. 步行圖示:🏃。
      2. 連接圖示:⬇。
      3. 端點站圖示:🌑。
      4. 轉乘節點圖示:🔘。
      5. 起訖站互換圖示:⇅。
      6. 路網圖圖示:🚇。
      7. 增加所有權聲明。
      8. 時間與票價介面優化。
      9. 時間與票價介面間距增加。
      10. 新增等待畫面。
      11. 新增第二頁面,顯示相關聲明、部落格及電子郵件。
      12. 修正A12、A13、A14a區間之文字訊息。
    2. 程式優化:
      1. 新增起訖站互換功能。
      2. 新增切換路網圖功能,及第一次無法切換設定。
      3. 新增端點站/轉乘站判斷功能。
      4. 新增焦點功能,每次查詢時,查詢結果可以置頂。
      5. 步行的顏色修正。
      6. 永春站的place_id修正。
      7. A18 高鐵桃園站的關鍵字修正。
      8. A13 機場第二航廈站的搜尋改善,使用fewer_transfers。
      9. 發現A12-A13之區間會有error,經查結果為google無論如何搜尋,都會跑出機場電車,該區間改成跳出文字訊息。
      10. BL 22 南港的關鍵字修正。
      11. 新增語音辨識功能,點選"起"或"迄"後,會出現google語音辨識起迄站,提高方便性。
  8. 製作APP的Icon [6]。
  9. 給公司的同事看過後,有人問到怎麼沒有台鐵和高鐵呢?若要達成台鐵及高鐵需要進行以下規劃及確認:
    1. 站點確認,台鐵太多站了,考量到此APP主要為桃捷及北捷,故預計規劃為北北桃生活區之區域,包含:
      1. 台鐵:五堵、汐止、汐科、南港、松山、台北、萬華、板橋、浮洲、樹林、南樹林、山佳、鶯歌、桃園、內壢、中壢、埔心、楊梅、富岡、新富,共19站。
      2. 高鐵:南港、台北、板橋、桃園,共4站。
      3. 已確認上述24站的place_id。
      4. 三鐵共構: 南港、台北、板橋,先使用同一組place_id。
    2. Google,確定參數"transit_mode=subway|train"適用於台鐵及高鐵。
    3. PTX,確認有台鐵及高鐵的票價資訊,已查車站代碼。
    4. 台鐵使用黑灰相間之格式,而高鐵則使用其網站主體配色(橘色)。
  10. 經過一個禮拜的努力,終於完成台鐵及高鐵的轉乘資料,由於不再是只有捷運,因此APP改名為「大眾轉乘」。
  11. 這幾天開始準備APP上架的相關事宜,開發APP到現在終於有第一個要上架的APP啊,超快,申請差不多一小時就過了,大家可以在Google Play上找到我的APP
  12. 成本估算如下,只要每日不超過1000人使用,應該就不需多付,當然我沒有開通付費功能,所以如果額度用完就沒了
    1. PTX:
      1. 免費。
      2. 呼叫次數:每日20,000次(一般會員),若每人一天兩次(上下班兩次),每次最多四種(北捷、機捷、台鐵、高鐵),20000/2/4,每日大約可供2500人使用。
      3. 參考資料:會員分級
    2. Google Map API:
      1. 每月有200美元的抵免額。
      2. 呼叫次數:每月40,000次(抵免額),若每人一天兩次(上下班兩次),每月22工作天,40000/22/2,每日大約可供909人使用。
      3. 參考資料:價目表
  13. 發佈後,有個朋友問是不是可以提供時刻表,回去查了一下PTX,桃捷、台鐵和高鐵可以提供時刻表,但北捷則因為班次較密集,使用時刻表意義不大,改成提供班次間距會比較好,只是這又是一個大工程了,而且是否要抓取整日的時刻表呢?還是提供查詢當下時間點之後的時刻表呢?有待商榷。
  14. 使用後第一個受惠的就是我,要去南京復興上課,平常都是做紅線轉綠線,使用了APP後發現,Google提供了一條,坐到松山火車站後,步行到松山捷運站,這樣的規劃非常不錯,去回程人少,而且都有位置坐,真的不錯,沒使用這個APP還不知道還可以這樣坐。
  15. 花了一兩個禮拜在這個APP上頭,是時候休息一下,看看書,等充完電後再來把時刻表補齊吧。
  16. 時刻表規劃:
    1. 北捷:提供班距說明。
    2. 桃捷:提供班距說明。
    3. 台鐵:提供起迄站時刻表。
    4. 高鐵:提供起迄站時刻表。

注意事項:

  1. header的使用須注意加密方式,時間格式為GMT,須扣除8小時,"x-date: "後面有空格,網址有時候用https會失敗,有時候會成功,目前使用http。
  2. 產生的json,可先用JSON Editor Online進行轉譯,比較容易了解。
  3. 如果不使用PTX,可使用Swagger將所有資料抓下來後,寫進資料庫也是可以,之前作法是將上傳到Firebase。
  4. 桃捷台北車站與北捷台北車站需步行,需多加留意程式撰寫。
  5. 上方的圖示是從Blogger中的"插入特殊字元"功能用出來的,可以搜尋關鍵字,找出你想要的特殊字元,就是上方的那些圖示,在網頁上呈現的結果,會與APP上呈現的結果不太一樣。
  6. 北捷的路網圖要跟北捷申請授權,也就是填一份授權申請書,回寄給北捷即可。
  7. 憑證keystore,自己包的APK使用的憑證,和從Google Play下載的APK憑證會不一樣,所以在Google Cloud Platform限制使用時,要特別注意其使用的SHA1會不一樣。
  8. 在Directions API中有一個參數為alternatives,若設定為true,則會像google map一樣顯示出多條替代路徑,而我沒有採用的原因有1)太多條,不知道哪一條才是我要的,還是用預設最符合我需求的那條即可,2)太多條,計算的量不一樣,API的價格也不一樣。
  9. 發現使用的憑證錯誤,會導致API設定後無法使用,將進行釐清到底要使用哪個憑證?
    1. 無:沒有限制,可使用,看來只能使用這個了,多加了API限制。
    2. 應用程式簽署憑證(google核發):經修改五分鐘後測試,無法使用。
    3. 上傳憑證(原app):經修改五分鐘後測試,無法使用。


改進事項:

  1. 抵達A13時,有時候會出現Error,因會出現到A12轉乘機場內的接駁車造成程式錯誤,轉乘錯誤: A13(fewer_transfers)、確認json資料(For input string: "ot")。
  2. A1-A5區間至A7的票價錯誤,因PTX未更正正確資料,已請同仁處理。
  3. 板南線任意站到南港展覽館站會出現錯誤。
  4. 起訖站互換功能錯誤。
  5. 目前使用上,若起訖站含有轉乘站(台北、桃園、板橋、南港、A1、A18),或地理位置鄰近(北門),會出現顯示不易理解之情況。
  6. ...
參考文獻:

  1. Developer Guide | Directions API | Google Developer
  2. Place ID Finder | Maps JavaScript API | Google Developer
  3. 入門指南‧PTX API Documentation
  4. MOTC Helper
  5. JSON Editor Online
  6. 台北捷運路網圖
  7. 3418 free SVG and PNG icons for your games and apps | Game-icons.net



2018年11月18日 星期日

ASUS AIO ZN242GDK 使用心得

Date: 20181118
Version: 1

我妹買了一台ASUS的AIO,家裡之前都是買桌機,沒買過這種的,所以上網找了一些資料,後來,我妹覺得很適合她,沒有主機,不占位子,就是一個螢幕,很方便。

所以上網看一下使用心得後,就決定買了,買回來後,幫她安裝一些必要軟體後,就讓她繼續摸索一下,並請她使用後一周,給我個使用心得。

ASUS AIO ZN242GDK規格:

  • 螢幕:23.8” FHD 1920X 1080 LED-backlit 
  • 觸碰功能:無 
  • 顏色:銀 
  • 處理器:Intel Core i7-8750H(2.2GHz, up to 4.1GHz) 
  • 記憶體:16G (8Gx2) DDR4 
  • 硬碟:1TB (5400RPM) 
  • 固態硬碟: 256G M.2 SSD 
  • 顯示介面:NVIDIA® GeForce® GTX1050獨顯 
  • 其他:802.11ac+Bluetooth 5.0 
  • 光碟機:無,請自行選購 
  • 作業系統:Windows 10 家用版(64bit) 
  • 其它:2合一讀卡機 
  • 配件:鍵鼠組 
  • 保固:3年保固, 到府收送 

超棒的規格,但我妹又不打電動,真的是非常可惜啊~~

反正她爽就好。

使用心得(PDF)

2018年11月4日 星期日

追蹤開膛手傑克─DNA科學鑑識解密百年懸案(2)
                                                           羅素‧愛德華茲

Date: 20181104
Version: 1

這篇主要是因為之前玩過一款"白教堂"的桌遊,內容就是在講開膛手傑克,發現大家似乎都不知道開膛手傑克是誰,就想起之前讀過的這本書籍,於是就拿了出來,並做成一個簡要的說明。

為什麼會推這本呢?主要還是因為其內容使用了各種科學鑑定的方法來證明開膛手傑克是誰?

提供相關說明如下,有興趣的可以看一下:


2018年11月1日 星期四

Android Studio學習筆記

Date: 20181013
Version: 1

主要是用來記錄學習Android Studio的過程紀錄。

1. build.gradle

##
apply plugin: 'com.android.application'

android {
    compileSdkVersion 28 <= 這邊要注意,故SDK須要API 28
    buildToolsVersion "28.0.3" <= 這邊要注意
    defaultConfig {
        applicationId "com.blogspot.iamamu.first"
        minSdkVersion 22 <= 這邊要注意,故SDK須要API 22
        targetSdkVersion 28 <= 這邊要注意
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:appcompat-v7:28.0.0' <= 這邊要注意
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

##

2. ADM

使用API 22 x86 Google API 即可

3. 翻譯文字

使用locale zh TW即可,@strings/"字串"

4. 熱鍵

Ctrl + Alt + L:重新排版
Ctrl + F1:more 說明
Alt + Enter:檢查錯誤,並提供修正參考

5. 目前在寫按鈕按下後,呈顯會加一,寫完當下,Android Studio會先自檢,若有錯誤,則會跳出紅色折線,目前寫完是沒有出現這樣的狀況,但不知為何,每次運用模擬器時,都會當掉,下次我會用公司的電腦試試看,看到底哪裡出現了問題。

/*MainActivity.java
package com.wood.second;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    //宣告
    private Button button = findViewById(R.id.button);
    private TextView textView = findViewById(R.id.textView);
    private int count = 0;


    @Override

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        button.setOnClickListener(this);
    }

    @Override
    public void onClick(View v) {
        count++;
        textView.setText(count);
    }
}
*/

6. 在公司試了半天,終於找到原因了,也順利run起來了,要注意的點是

  1. 要先宣告,但不先不賦予值。
  2. 再來onclick內要有確認ID的動作。

/*
package com.wood.second;

import android.annotation.SuppressLint;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity implements View.OnClickListener {
    private Button btnplus, btnminus, btnreset, btnmulti, btndiv;
    private TextView txv;
    private int count = 0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        btnplus = findViewById(R.id.button);
        btnminus = findViewById(R.id.button2);
        btnreset = findViewById(R.id.button3);
        btnmulti = findViewById(R.id.button4);
        btndiv = findViewById(R.id.button5);
        //Button btnplus = findViewById(R.id.button);
        //Button btnminus = findViewById(R.id.button2);
        txv = findViewById(R.id.textView);
        //count = 0;
        btnplus.setOnClickListener(this);
        btnminus.setOnClickListener(this);
        btnreset.setOnClickListener(this);
        btnmulti.setOnClickListener(this);
        btndiv.setOnClickListener(this);
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.button:
                count++;
                break;
            case R.id.button2:
                count--;
                break;
            case R.id.button3:
                count = 0;
                break;
            case R.id.button4:
                count *= count;
                break;
            case R.id.button5:
                count /= count;
                break;
            default:
                break;
        }
        txv.setText(Integer.toString(count));
    }
}
*/

7. 如何解決setText會出現建議事項,提供參考網站,【Android寻坑之路】解决TextView.setText提示Do not concatenate text displayed with setText. Use resource string with placeholders.问题,文章中大約出現了4種轉字串的作法如下:

  1. @SuppressLint("SetTextI18n"); txv.setText(Integer.toString(count));
  2. txv.setText(String.valueOf(count)); <=詢問寫java的人,比較常用
  3. StringBuilder a = new StringBuilder(); txv.setText(a.append(count)); <=詢問寫java的人,比較常用
  4. android:text="@string/number" ==> <string name="number">%1$d</string> ==> txv.setText(String.format(getResources().getString(R.string.number),count));

8. 解決了按鈕的問題後,接下來要試試看下拉式選單,參考"GiveMePasS'S Android惡補筆記-如何使用Spinner(下拉式選單)"這一篇文章。再來是整體設計,會有一個按鈕,按下後會隨機取樣(1-10),這個數字就是下拉式選單中會有多少選項。

也順便學了java的相關函式:

  • Math.random()
  • ArrayList<> = new ArrayList<>();
  • ArrayAdapter<> = new ArrayAdapter<>();
  • ArrayList.add()
  • ArrayList.clear()
  • ArrayList.get()

整體來說,還不錯,再接再勵往專業邁進。

9. 下拉式選單完成後,我接著挑戰日期和時間,也一樣上網爬了文,DatePickerTimePicker,這兩篇對我幫助很大,後來也自行修改到可以記錄上一筆選擇的項目,不會每次點進去都是同一時間,也學了許多java函式:
  • Calendar = Calendar.getInstance()
  • Calendar.set()
  • Calendar.get()
  • Calendar.YEAR
  • Calendar.MONTH
  • Calendar.DAY_OF_MONTH
  • Calendar.DAY_OF_WEEK
  • Calendar.HOUR_OF_DAY
  • Calendar.MINUTE
  • String.format("%d...", ...)
  • Key-Value Pairs:
    • Map<> = new HashMap<>()
    • HashMap.put()
    • HashMap.get()

/*

import android.app.DatePickerDialog;
import android.app.DatePickerDialog.OnDateSetListener;
import android.app.TimePickerDialog;
import android.content.Context;
import android.renderscript.Int3;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.DatePicker;
import android.widget.EditText;
import android.widget.Spinner;
import android.widget.TextView;
import android.widget.TimePicker;
import android.widget.Toast;

import java.util.ArrayList;
import java.util.Calendar;
import java.util.HashMap;
import java.util.Map;

public class MainActivity extends AppCompatActivity implements OnClickListener, AdapterView.OnItemSelectedListener {
    private Button btnplus, btnminus, btnreset, btnmulti, btndiv, btnrand, btninput, btndate, btntime;
    private TextView txv, txv2, txv3;
    private Spinner spin;
    private int count = 0;
    ArrayList<String> randomList = new ArrayList<>();
    private EditText editxt;
    private Map<Integer, String> dayOfWeek = new HashMap<>();
    final Calendar time = Calendar.getInstance();
    private int myYear = time.get(Calendar.YEAR), myMonth = time.get(Calendar.MONTH), myDay = time.get(Calendar.DAY_OF_MONTH), myHour = time.get(Calendar.HOUR_OF_DAY), myMin = time.get(Calendar.MINUTE);

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        btnplus = findViewById(R.id.button);
        btnminus = findViewById(R.id.button2);
        btnreset = findViewById(R.id.button3);
        btnmulti = findViewById(R.id.button4);
        btndiv = findViewById(R.id.button5);
        btnrand = findViewById(R.id.button6);
        btninput = findViewById(R.id.button7);
        btndate = findViewById(R.id.button8);
        btntime = findViewById(R.id.button9);
        txv = findViewById(R.id.textView);
        txv2 = findViewById(R.id.textView2);
        txv3 = findViewById(R.id.textView3);
        txv.setText(String.valueOf(count));
        spin = findViewById(R.id.spinner);
        editxt = findViewById(R.id.editText);
        btnplus.setOnClickListener(this);
        btnminus.setOnClickListener(this);
        btnreset.setOnClickListener(this);
        btnmulti.setOnClickListener(this);
        btndiv.setOnClickListener(this);
        btnrand.setOnClickListener(this);
        spin.setOnItemSelectedListener(this);
        btninput.setOnClickListener(this);
        btndate.setOnClickListener(this);
        btntime.setOnClickListener(this);
        dayOfWeek.put(1, "日");
        dayOfWeek.put(2, "一");
        dayOfWeek.put(3, "二");
        dayOfWeek.put(4, "三");
        dayOfWeek.put(5, "四");
        dayOfWeek.put(6, "五");
        dayOfWeek.put(7, "六");
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.button:
                count++;
                break;
            case R.id.button2:
                count--;
                break;
            case R.id.button3:
                count = 0;
                break;
            case R.id.button4:
                count *= count;
                break;
            case R.id.button5:
                count /= count;
                break;
            case R.id.button7:
                count = (editxt.getText().length() == 0) ? 0 : Integer.valueOf(editxt.getText().toString());
                //count = Integer.valueOf(editxt.getText().toString());
                //txv.setText(editxt.getText().toString());
                break;
            case R.id.button6:
                int rand = (int) (Math.random() * 10 + 1);
                randomList.clear();
                for (int i = 1; i <= rand; i++) {
                    randomList.add(String.valueOf(i));
                }
                ArrayAdapter<String> randomAdapter = new ArrayAdapter<>(this, android.R.layout.simple_spinner_dropdown_item, randomList);
                spin.setAdapter(randomAdapter);
                break;
            case R.id.button8:
                //final Calendar time = Calendar.getInstance();
                //myYear = time.get(Calendar.YEAR);
                //myMonth = time.get(Calendar.MONTH);
                //myDay = time.get(Calendar.DAY_OF_MONTH);
                //myDate = time.get(Calendar.DAY_OF_WEEK);
                //txv2.setText(String.valueOf(myYear) + String.valueOf(myMonth + 1) + String.valueOf(myDay) + String.valueOf(myDate));
                new DatePickerDialog(this, new OnDateSetListener() {
                    @Override
                    public void onDateSet(DatePicker view, int year, int month, int dayOfMonth) {
                        time.set(year, month, dayOfMonth);
                        myYear = year;
                        myMonth = month;
                        myDay = dayOfMonth;
                        txv2.setText(String.format("%d-%d-%d (%s)", year, month + 1, dayOfMonth, dayOfWeek.get(time.get(Calendar.DAY_OF_WEEK))));
                        //txv2.setText(String.valueOf(year) + String.valueOf(month + 1) + String.valueOf(dayOfMonth) + " (" + dayOfWeek.get(time.get(Calendar.DAY_OF_WEEK)) + ")");
                    }
                }, myYear, myMonth, myDay).show();
                break;
            case R.id.button9:
                    //myHour = time.get(Calendar.HOUR_OF_DAY);
                    //myMin = time.get(Calendar.MINUTE);
                    new TimePickerDialog(this, new TimePickerDialog.OnTimeSetListener() {
                        @Override
                        public void onTimeSet(TimePicker view, int hourOfDay, int minute) {
                            time.set(myYear,myMonth,myDay,hourOfDay,minute);
                            myHour = hourOfDay;
                            myMin = minute;
                            txv3.setText(String.format("%d:%d", hourOfDay, minute));
                        }
                    }, myHour, myMin, true).show();
                break;
            default:
                break;
        }
        //txv.setText(Integer.toString(count));
        txv.setText(String.valueOf(count));
    }

    @Override
    public void onItemSelected(AdapterView<?> parent, View view, int position, long id) {
        count = Integer.valueOf(randomList.get(position));
        txv.setText(String.valueOf(count));
        //Toast.makeText(this, "The number is: " + randomList.get(position), Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onNothingSelected(AdapterView<?> parent) {

    }
}

*/


2018年10月26日 星期五

溯源探幽-熵的世界
            馮瑞 馮少彤

Date: 20181026
Version: 1

介紹熵的一本科普書籍,是一本簡體的書籍。

整體來說,可以提供給非專業的同仁來閱讀,並不算太深奧,應該是說雖然有很多公式,但都會以許多字句來輔助說明,並不會太艱深難懂。

整本從熱力學第一定律講到第三定律,從淺入深,一步一步帶我們進入熵的世界。

熵與能,我覺得是一種一體兩面的存在,兩者彼此影響,但總體來說,在這本書的進展從能慢慢轉移到熵,也慢慢地都注重在熵的發展,也看到熵如何影響物理學、化學、材料學...等科學領域上,非常推薦給非專業領域的同仁來看,可以一見熵的面貌。

雖然如此,但文中也有大量的公式,所以對我來看得有點慢,再加上最近這段時間很忙,回到家就只是想打個電腦休息一下而已。

最近玩了一個桌遊是白教堂,也就是開膛手傑克的故事,而我也在之前有介紹過一本書,說明科技如何找到傑克的故事,也發現好像很多人不了解這件事,所以之後可能以做一個懶人包為目標吧~~

追蹤開膛手傑克─DNA科學鑑識解密百年懸案


2018年10月13日 星期六

Google Android 程式實戰演練 - 使用 Android Studio 與 Android SDK 打造雲端商務應用程式

Date: 20181013
Version: 1

課程:Google Android 程式實戰演練 - 使用 Android Studio 與 Android SDK 打造雲端商務應用程式
公司:恆逸教育訓練中心
時間:2018-10-08至2018-10-12 每週一二四五 09:00~17:00
地點:台北市復興北路99號12F
價格:19,200元

課程的相關資訊如上所示,會寫這一篇的原因,主要是因為公司出錢,讓我去上關於Android開發的課程,之後,可能要自行開發公司用的相關app。

雖然是公司出錢,但是我先墊的,之後要寫一份心得,才能進行動支,錢才會匯回來,所以這篇也是順便寫的,不過有些內容就不適合放了,這次上課時間是10月10日,放假那一週,原本我是想要那週請長假,結果發現早在幾個月前就安排了課程,只好乖乖去上課了。

也剛好前一周,我進行採購案的估查驗,超忙的,也因為下一周我不在公司,所有的事都須要在那一周做完,真的是有夠累的,幾乎每天都要加班。

~~~

這次上課的內容,對我來說算是比較進階的課程,我之前只會少許的Java,而且之前製做APP的工具也不是Android Studio,所以整堂課下來,對我來說是有那麼一點困難。

課程的講義則是將各個單元的簡報印刷成一本,不太算特別,內容也有許多與目前實際內容有所出入,應該是沒有進版的關係吧!

上課中,老師補充了許多目前APP的發展有關的相關資訊,這也是上課才可能會聽到的東西,畢竟在公司只要把事情做好就好了,想要了解最新的資訊,就只能利用下班後的時間,但問題是如果你不知道有哪些新東西,你又要從哪裡去找你不知道的東西呢?

第一天上課的時候,大家都還能跟上自己動手作,但到了第二天,大家基本上都只能操寫老師的程式碼,複製完之後,再來自己慢慢看了,老師的進展真的是飛快,這也沒辦法,因為要在4天的課程中,將APP的相關程式介紹一遍,大概也只能用這樣的方式吧。

11月還有一次,不過是三天,希望課程內容可以再簡單一點,不然真的會吸收不上。

我的電腦規格:
CPU: Intel Core i5-3210M
RAM: 8GB
無SSD

~~~

其實在今年六月的時候,我就用我的電腦試過了,結果超慘的,連啟動都沒有辦法,但經過上課之後,了解比較多的細節後,會自己將缺少的部份加回去了,至少現在程式是可以啟動的,模擬器也是可以啟動的,之前一樣也不行,果然有上課是有差的,雖然程式可以啟動,但我還是不會寫程式,我連按按紐都寫不出來,雖然程式沒跳錯誤,但每次模擬器就是會當掉,把我寫的那一段刪掉後,又恢復正常,我還是要繼續研究才行。

但最讓人頭痛的是,我的電腦實在是跑太慢了,每一個動作都要等上一會兒才行,你輸入太多,電腦還會當掉,哀~~

來講一些題外話,在恆逸上課的感覺,我覺得還不錯,設備用起來都很順,每一個學員都有自己一套課堂用的抽取式OS,上課時,只要簽到就可拿到你的抽取式OS,放入電腦開機就可以了,比我之前去其他上的電腦課程好太多了,簽到的時候發現,上課的人有一半都是相關公營機關:北捷、桃捷、台灣菸酒…等的,看起來大家都是長期使用恆逸來上一些資訊相關的課程。

說真的上一週實在是有夠累的,這一週可以拋開公司大小事,專心上課也算是另類的放假吧,下周又要回去公司了,有超多事情在等著我吧,QQ~~

基本上我覺得恆逸上課還不錯,介紹給想要上相關課程的人,不過價格真的有點貴啊!

後續學習心得
1. Android Studio學習筆記

2018年9月30日 星期日

韓劇《Good Doctor 善良醫生》 VS. 美劇《The Good Doctor 良醫墨非》

Date: 20180930
Version: 1

最近在電視台上看到,由韓劇改編的美劇,善良醫生,其實早在幾年前看完韓劇時,就知道會被改編的消息,只是不知道甚麼時候才看得到,直到不久前才從電視廣告中得知。

所以就趕快跑去看了,第一季共13集,也在今年出了第二季,目前正在follow中。

看完第一季就來聊聊兩者的差異吧!會以條列式進行,以下相關內容是依照幾年前看的韓劇與最近看的美劇進行比較,可能會因時間久遠產生誤差。

以下劇透,不喜者勿入。
  1. 既然是美劇就一定會因地制宜的進行某種程度上的改編,這是給看完韓劇,想看看美劇的提醒,順便一提,這也有改編日劇,不過我沒看就是了,我就不對這部分進行討論。
  2. 第一集開頭差不多,一個在車站,一個在機場,非常合理,美國比韓國大,用機場進行移動也蠻符合實情,中間稍微不同的是在刀子的橋段,再來最讓人意外的是,在第一次董事會結束後,因新聞報導後,韓劇理所當然地在第二集中,就被聘為醫生,但美劇中出現了第二次董事會,而主角也發表了演說,也非常符合主角的狀況的一段台詞,也就是這一段,讓我覺得改編的真是好啊!讓我有想繼續看下去的動力,不然,我原本還以為就只是照翻而已。這點我真的要給個讚!!!
  3. 再來是醫生人數,在韓劇有一大間,很多位醫生,但在美劇中一開始也才5位醫生而已,再加上美國輿情,也就是會有個膚色的醫生出現,這也對劇情產生極大的不同。
  4. 再來是醫生的角色上也有很大的不一樣,在日韓劇中,常常就會有類似丑角的醫生存在,但在本劇中,並沒有這樣的存在,各個醫生都是非常傑出的,沒有這種搞笑的存在。
  5. 主治醫生的couple依然還在,但發展跟美劇上有很大的不一樣。
  6. 主角哥哥的死亡方式也是非常不同的。
  7. 因兩邊集數不相同,一個20,一個13,可能在劇情的進展會不太一樣,美劇的主角父母劇情尚未出現。
  8. 韓劇主角是與醫生產生愛情,但美劇中則是與局外人產生愛情,這點也會非常不一樣。
  9. 一樣有看到長的與哥哥一樣的臉孔出現。
  10. 監護人與主角間的劇情,沒有太多的回憶,基本上都是現在的時間點進行,這點也是非常不同。
  11. 或許一開始有點針對,但隨著主角能力不斷展現,其實整季下來,霸凌的事件幾乎沒有,主角很快就進入狀況,這或許跟美國的英雄主義有關吧,只要能力夠強,反觀韓劇中,幾乎都是霸凌直到後面幾集才挽回局勢,心情上當然是看美劇比較沒有壓力。
  12. 在韓劇中一開始很多壞人一搞事,但最後都被漂白了,但在美劇中反而沒有這樣的狀況,大家都是以自己的身分立場,做該做的事,沒有人是壞人,只有對的事或錯的事,僅此而已。
  13. 再來就是,片中的手術畫面真的是假到不行,也不知道會甚麼會這樣,很容易出戲,韓劇這部分就處理得不錯。
  14. 董事會成員各個都是高手,不像韓劇中的似乎就是來陪襯的。
  15. 韓劇主要是小兒外科醫生,但美劇中就是個外科醫生,也就是說在病人的呈現像略有不同。
  16. 院長真得換人了,這點在第二季中會有更不一樣的表現。
  17. 韓劇中通常是以主角為主線貫穿整集,但在美劇中通常是以兩條主線來進行,一組有主角,一組沒有主角,來看彼此角色的互動,韓劇比較注重在主角與其他角色的互動上,這或許也跟醫生人數有關吧。
  18. 美劇中,醫生角色進進出出,而韓劇中,一直都是那一群醫生,沒有不好,只是呈現的方式會有所不同。



2018年9月23日 星期日

短網址QR Code APP

Date: 20180923
Version: 1

會想要做這個原因在於,現在公司的短網址和QR Code都是使用goo.gl的服務產生,但該服務於明年就會結束了,所以才在想要如何繼續下去。

會分成兩塊,一個短網址,一個QR Code,有的單位需要短網址,但另一個單位需要QR Code,而需要QR Code的那個單位會需要先行產生後,等相關內容確定後才會放上去正稿,因此會使用官網伺服器進行跳轉的方式,來達成動態連結的效果。

雖然如此,後來想想雖然有的單位需要短網址,但如果是用我的方法話,不就每次都要在官網建立跳轉嗎?很明顯是個浪費人力的方法,但既然都做了,還是紀錄一下好了。

QR Code
比較簡單,因為先前那一個加密的APP已經做過了,這次只是再把方法寫出來一次。

短網址
使用的方法是方法一[1],因為方法二我看不懂,所以採用方法一,十進位轉為XX進位法,所以你需要兩個東西,十進位,XX進位,XX進位目前選用的是58進位法,格式為大寫小寫數字[2],刪除容易讓人搞混的大寫O和零0,以及大寫I和小寫l,這四個在APP上的呈現容易令人疑惑,故刪除。

而十進位的來源,需為主鍵[1],也就是不會重複的一串數字,而有甚麼數字是不會重複的呢?我選擇的是時間,年月日時分秒,六個節段,時間是唯一的,不會有時間重複到,因此進行的第一次轉換,轉換過程主要是將十進位/58得商和餘[3],保留餘數,繼續將商/58德商'和餘',直到最後商<58,無法再進行除法,將最後商及過程得到的餘數,由後往前進行轉換為58進位法,就會得到一串簡碼,也就是短網址。

但在進行的過程中,發現年月日時分不太會變化,導致最後出現的簡碼,前幾個字串都幾乎一樣,後來我將得到的時間字串反轉,由後往前排,這樣的話,整個時間就會很常變動,因為秒數常變,導致除法得到的結果都不盡相同,例如: 20180923173717-->71737132908102,這個技巧還可以用在製作隨機種子時可以使用。

最後就是將得到的短網址做成QR Code而已,但對於實際進行似乎沒甚麼幫助。

參考來源
1. 短網址(short URL)系統的原理及其實現
2. The Base16, Base32, and Base64 Data Encodings
3. 二、八、十與十六進位 (數字系統) 轉換教學


2018年9月22日 星期六

桃捷的中秋晚會

Date: 20180922
Version: 1

20180920星期四,這一天是非常特別的,因為這一天是桃捷的中秋晚會,其實這活動去年也辦過,今年一樣照常舉行。

介紹一下活動內容,活動從四點開始,主要是園遊會的形式,再接著是烤肉。

園遊會是會有約30家廠商來,今年的園遊券有200元,比去年的100元好多了,100元買個兩樣就吃完了,還要自己掏錢,不過200元就不一樣了,可以吃得還不錯呢!而且重點是今年攤商的種類比去年好太多了,去年一大推重複,根本沒啥好吃的,今年有超多好吃的東西呢!

園遊會的地點跟去年一樣,今年主要是舞台換到員餐前面,還搭建了舞台,比去年好太多了,而烤肉區則在舞台前的廣場,去年則是在馬路中,跟園遊會的人潮擠在一起,超多人的,今年設計的比較好,還滿舒適的。

去年花完100元就閃了,也因為那天是司機員剛下班,吃完就回家了,今年是第一次參加資訊組的烤肉,所以逛完園遊會後,就回到資訊組的位子,開始烤肉了。

今年有舞台,當然就有舞台表演,還不錯,因為去年沒有待很晚,所以也不知道去年有沒有活動,再來就是晚上有抽獎活動,可想而知,我沒抽中,跟尾牙一樣,哀~~

最後,鄭文燦還出現來幫忙抽個市長獎呢,晚會結束後,一堆人獎券沒用完,就跑去買個不鏽鋼的餐具或是黑糖糕,比較可以帶回去的東西。

整體來說,比去年好玩很多,相關設計都很不錯,感謝總務處的支持,希望明年後年每一年都會繼續辦,而且辦的一年比一年好,感謝桃捷。

2018年9月16日 星期日

桌遊設定-3

Date: 20180905
Version: 1

主要是最近想把以前大學研究所做的桌遊重新翻出,除核心概念不變外,其餘應該都要大修特修了。

核心概念為,有1-9數字牌,三條或同花就可以換一顆星,集滿5顆就算贏了,但每一張數字牌都有其能力,能力可以對牌局產生各種影響,因此,到底是湊成牌組,還是使用能力?你要如何抉擇呢?

共54張,因式分解一下為: 2*3*3*3,可能做法如下:

  1. 2(重複)*9(數字1-9)*3(類型)
  2. 2(類型)*9(數字1-9)*3(重複)
目前是採用做法1,另外關於重複數及連續數,目前有以下組合: 
  1. 三重複 = 四連續 (機率差約1.5倍)
  2. 三重複+一顆星 = 三連續 (機率差約6.7倍,但6.7倍是否可以抵銷多一個星呢?)
  3. 兩重複 = 三連續 (機率差約1.8倍)
經考慮,三重複+一顆星=兩顆星,也就是說當湊齊三重複,就可以換到兩顆星,這收益是否過高,所以目前先暫訂作法1。

也考慮到五張牌要似連續又有點難,故可能改為作法2,但改為抽一張牌取代一顆星。

9種2重複,共有18張牌,因式分解為=2*3*3,故可分為以下四種組合:

  1. 9種能力,2重複
  2. 6種能力,3重複
  3. 3種能力,6重複
  4. 2種能力,9重複

目前會先以作法2為主,若idea夠多的話,會升級為作法1,考慮到有3種類型,故作法1會有27種能力,作法2會有18種能力,考量到能力太多容易混雜,故最後還是只做法2為主要考量。

後來在設計的過程中,發現18種能力實在太多了,玩家要在一場遊戲中記下18種能力真的不太可能,所以限縮之下,改為作法3,應該會比較可行吧!

三種類型分別為:攻擊牌(劍)、防禦牌(盾)和輔助牌(藥水),可參考獵人-貪婪之島-咒語卡片。
  1. 攻擊:對牌局產生作用,不論好壞,可參考犯人在跳舞。
    1. 抽牌: 從牌堆抽取一張。
    2. 左顧: 從一位玩家手牌中隨機挑選一張交換。
    3. 右盼: 。
  2. 防禦:預防/阻止攻擊效果。
    1. 禁止: 可取消一次之動作。(被動)
    2. 反射: 將該次攻擊返回原攻擊者。(被動)
    3. 轉移: 將該次攻擊對象改變為其他玩家,不含原攻擊者。(被動)
    4. 否定: 取消一次攻擊。(主動)
    5. 歸零: 棄掉所有手牌,直至下一回合前,不受其他牌影響,至下一回合時,將手牌補至上限。(主動)
    6. 同盟: 
  3. 輔助:可須配合其他牌使用,可能造成虧牌,故須有獎勵補償,可參考POE輔助技能。
    1. 擴散: 將單體效果轉變為全體效果。(範圍、次)
    2. Double: 將效果變為兩倍。(效果、次)
    3. 回收: 可回收其他玩家使用的牌,將該牌取回至手牌。(其他、主)
    4. 攤牌: 指定一名玩家,於下一回合前須公開展示手牌。(範圍、主)
    5. 無效: 消除輔助效果。(效果、主)
    6. 複製: 可複製自己手牌中的牌。(其他、次)
得分和出牌合併為一個動作,故出牌需一次出三張,然後這三張能力都會發動。
故三種能力要簡單化。
如果無得分和出牌,則蓋牌,並不會受到任何正負面影響,直到下一回合。(無敵模式)
如果得分和出牌一起使用,則無防禦相關等機制,不然一擋三的情況,太容易虧牌了。
因為沒有防禦,故攻擊能力盡量為不影響他人的牌數之能力。
其實還是可以保留影響他人手牌的能力,但需提供制衡的手段,例如: 可出4張或5張的牌型來阻止前一人出的牌型,並禁止其發動效果和換分,但作為代價,可換分,但一樣無法發動效果。
這邊就牽扯到牌型的組合數,來決定彼此的優先順序:

  1. 5張(max.)
    1. 順子:38,880
    2. 同花:54
  2. 4張
    1. 順子:349,920
    2. 同花:6,480
  3. 3張(min.)
    1. 順子:1,539,000
    2. 同花:203,040
依上述計算結果得知:5同 > 4同 > 5順 > 3同 > 4順 > 3順口訣:同>順,543,中間互換

  1. 攻擊(6種):
    1. 抽牌(3種):
      1. 好運:◎{一位玩家}從牌堆抽取※{一張牌}。
      2. 盜取:指定◎{一位玩家},抽取※{一張手牌}。
      3. 交換:與◎{一位玩家}交換※{一張手牌}。
    2. 棄牌(2種):
      1. 丟棄:指定◎{一位玩家},抽取※{一張手牌}捨棄。
      2. 宣告:宣告※{一個數字(9種數字,共6張)及一種顏色(6種顏色,共9張)}及◎{一位玩家},捨棄符合之手牌。
    3. 出牌(1種):
      1. 無效:本次連鎖卡牌效果無效化。
  2. 輔助(3種):
    1. 擴散:◎全體玩家。
    2. 增強:※效果加一。
    3. 複製:複製數字或效果。
基本上,卡牌效果如上所示,接下來就要開始設計版型。
版型將參考卡牌烹飪塔-頂級紙牌遊戲,但會於中間圖示下方增加描述字句/卡牌名稱。

卡牌為9*6.5公分,左上角為數字,三種顏色,數字1-9,右上角則是類型標記,共兩款,劍與藥水,代表攻擊與輔助,在中間會友符合該卡牌效果的造型圖示,最下方為卡牌效果描述。

大致上已設計完畢,之後就去找印刷機,印個彩色出來,再來試試看,到底規則這樣行不行。


  1. 20180917,4人,5/4/4/3,第二輪(牌庫空了算一輪)結束。
    • 鼓勵蓋其他人牌之情況,可獲得前人的分數,前人則無法獲得。
    • 每回合開始抽兩張牌。
    • 若本回合未出牌,則於回合結束前抽一張牌。
    • 每次玩家出牌後,其餘玩家依序確認是否蓋牌。
    • 當被蓋牌時,由蓋牌玩家開始下一回合。
    • 先達成5分者贏。
  2. 20180918,3人,5/2/0,第一輪就結束了。
    • 很容易空場,某一回合大家都在抽三張牌。
    • 也真的有人很衰到連3順都湊不出來。
    • 蓋牌情況還是很少出現。
    • 出3張以上的狀況也很少。
    • 由蓋牌者開始下一回合,感覺有點強。



圖片來源:
https://game-icons.net/

2018年9月8日 星期六

伊藤潤二絕命逃走中特展臺灣站
時間:7/14~9/16
地點:新光三越台北信義新天地A9 9F宴會展演館 (台北市信義區松壽路9號)

Date: 20180908
Version: 1

伊藤潤二的鬼屋

總共有AB兩館,也就是兩個鬼屋可以玩,但需抽號碼牌,地點是在A9一樓旁的小木屋,換完號碼牌後,來到A9 9F,進場後工作人員會先請放置物品,有置物櫃,但很暗,請開手電筒使用,貴重物品請帶在身上。

接下來有AB兩館可以看,就看哪邊比較少人,工作人員就會幫你排哪邊,只是我覺得抽號碼牌沒啥意義,也沒看工作人員有在看,主要都是看票後,將票根還你。

接下來就是排隊進場了,我去的時候大約2點多,跟同學和學姊去,共三人,人其實還好,算了一下,每一館大約耗時30分鐘,所以其實還好,但當我們玩玩出來時,超多人了,那時大概34點吧,所以要玩得請早,比較不需要排隊。

接下來就準備進入正題,也就是鬼屋的部分,每次可進入10人,進入後會有一個小房間,要進行事前宣導與準備,10人倆倆一排,工作人員會發一條繩索,會請所有人在鬼屋中都要抓著,並且請勿攻擊工作人員...等宣導語句。

接著就開始進入了,兩邊鬼屋除內容不一樣外,其實本質沒有差太多,所以我就概略的講一下,進入後應該跟大部分鬼屋差不多,會有人突然跑出來嚇你,平均大概有5個嚇人的點左右,整場進行的節奏都是由第一個人來決定,所以AB館,有一組就走得很快,有一組就走得很慢,而且如果想被嚇的話,就請排第一個,最容易被嚇到的,像我們兩次就排在中間,所以中間以後,其實看不太到前面到底發生了甚麼事,只知道前面開始嚇人了,要注意一下,所以已經被預警了,就不太會被嚇到了,另外帶著理智去看,也不太會被嚇到,另外有一個點,因為AB館同一個場域不同路線,所以有時候是會被隔壁館的聲音嚇到。

當鬼屋走完後,繩子會收回去,會請一個人接著一個人進入,這時候大家都以為是個人鬼屋,其實就只是個走廊而已,會通道伊藤潤二的展覽區,會展示一些伊藤潤二漫畫中出現的物品,再接下來就是紀念品區了,這是每一個展覽都會有的,基本上以上就是整個伊藤潤二鬼屋的過程。

說一下心得,發現其他人為啥可以叫的這麼大聲,有這麼恐怖嗎?基本上你都知道這是假的,只要有做好心理建設,知道會有人突然出現嚇你,應該就還好吧,整體而言,鬼屋是滿好玩的,但其實伊藤潤二的東西沒有想像的那麼多,說實在的,我還是比較喜歡看展覽,就像上一次的伊藤潤二特展,希望下次可做成伊藤潤二解謎逃走的樣式,應該會更好玩吧。

2018年9月2日 星期日

白色力量4:光榮城市-柯文哲的進步價值
                                                           柯文哲

Date: 20180902
Version: 1

柯文哲的第四本書

出的時間是在選舉前出的,很明顯是要宣傳柯文哲這四年來的政績,這本書重頭到尾主要都是在講柯文哲四年來做過甚麼事情,就我個人而言,我還蠻喜歡柯文哲的,至少不向其他候選人會去抹黑別人,通常都是別人來抹黑。

對於柯文哲競選連任這一件事,也是對台北市民的一種考驗,對於第一次是因為反對而選擇了柯文哲,在經過四年後,其表現是否符合市民的期待,會讓市民認為不後悔四年前選了柯文哲呢?

個人對於柯文哲連任是蠻看好的,但來看看未來該怎麼進行呢?先不論是否連任,有人說之後可以出來選總統,我覺得言之過早,我反而認為柯文哲可以將台灣六都挑幾個來選舉,來看看究竟會發生甚麼事?北部已經有了,剩下在中南在各挑一個,希望柯文哲可以將其風氣帶給其他城市,再接下來的事更有趣的,回頭去選台北市長,看看經過其他黨派的市長的任期後,台北市政府的風氣會不會又變成之前的那種樣子呢?

接下來就來看看選舉結果吧!

延伸閱讀
  1. 白色力量
  2. 白色力量2:改變成真
  3. 白色力量3:柯P模式

2018年8月24日 星期五

小說背景設定-16

Date: 20180809
Version: 1

本篇為前篇「小說背景設定-12」之延伸。

但參考資料做了一些改變,採用教育部國語辭典公眾授權網中的《成語典》,跟上次資料不同的是,該網站提供了成語相關資料的下載,幫助我們更容易了解成語的來源與用法,降低了查找資料的時間。

首先介紹資料格式,相關欄位有編號、成語、注音、漢語拼音、釋義、典源、典故說明、書證、用法說明、近義、反義、辨識、參考語詞,共13項,針對主題進行篩選,不需要注音和漢語注音,典源與典故說明衝突,僅保留典故說明,書證內容不太需要,用法說明與釋義衝突,僅保留釋義,辨識為其他html檔案,不考慮,參考語詞為其他組成之成語,大多數皆不常使用,故最後僅保留6項,另外,為了加入成語能力的解析,故再加上兩個欄位「形」和「義」(文後再解釋),所以結果一共為8項。

該資料表共有5106筆,刪除大多數可義參的成語後,最後成語總數為1568筆,以上這些列述和欄位就是之後成語資料庫的組成。

接下來就是介紹如何使用這個成語資料庫,為了可以隨時隨地查看/更新成語資料,故作成一個APP是一個不錯的點子,而我使用的還是App Inventor 2,而之前常使用的資料庫,google的spreadsheet,只能讀取無法寫入,故這次選用了其他線上資料庫來儲存資料,有tinywebdb和Firebase兩種,上網查了一下,就決定使用Firebase,主要是因為操作簡單,不需要太多額外設定就可以達成,建立好Firebase相關資料後,就要開始匯入,Firebase使用的是json格式資料匯入,故需要將上述成語資料庫轉換成json格式後再上傳,請注意json格式編碼請使用utf-8,否則資料無法上傳。

Firebase json 格式如下:









有興趣的可以上網查一下,Firebase 的資料庫格視為NoSQL,主要是透過Key-Value進行配對,主要是使用物件來進行建置,當然用陣列也是可以。

前置作業完成後,接下來就是使用App Inventor 2 來製作成語APP了,中間過程就不贅述,直接放結果圖如下:


左1是點擊"GO!!"後,會隨機選去一組成語秀出,點擊"釋義、典故、近義、反義"後,會出現左2,會顯示其內容,如果長按"GO!!"的話,會出現左3,可輸入成語的編號,目前有填入相關資訊的是左4,分別在"形"和"義"鍵入相關資訊後,按下"儲存",即可將內容上傳到Firebase。

開發的過程中,花最久的時間反而是在版型的建置上,一開始是用下拉式選單,但發現效果不太好,形和義,本來是當選擇某一個另一個textbox會隱藏,但發現不太好用,最後就改成兩欄式,兩邊可以一起對照的打,再來說明一下的是,在讀取資料的時候,一開始設計是將該組成語所有資訊讀取下來後,在程式內進行檢索,但發現在某些編號的成語,會出現讀取錯誤,我也找不出原因來,最後,就改為每一個按鈕的是去跟Firebase進行讀取,這樣處理後,就沒有再發生讀取錯誤的問題了,再來就是Firebase(免費)有限制每月10GB的下載量,目前看起來很夠用了。

以上就是成語APP的製作過程,接下來就開始進入到正題,也就是本次小說背景設定的設定了。

這篇主要的就是形和義兩種,所謂的義,就是成語的真正意涵,而形則是就字面解釋成語,例如:「三人成虎」,並不是只有三個人變成虎,而是指...等,所以三個人變成虎就是形,而...則是義,也就是說在APP中,要將成語以這兩種角度來詮釋成語能力,希望有一天我可以完成全部1568筆成語的能力詮釋。

另外,該成語的能力也可修成反義,只不過就像法師一樣使用超魔技巧,需要多耗費一樣,使用者也需要提供更多能量。

20180902更新:

在後來使用上發現一點不太好用,就是如果對某個成語有靈感時,但以目前設計是無法找出那個成語的,因為是用隨機取號的方式,所以這次對程式進行了修正,增加了ListPicker的功能,可以在輸入編號的地方,也可以輸入關鍵字,之後程式會用關鍵字搜尋並用ListPicker將搜尋結果顯示出來,讓使用者進行挑選。

只增加了對輸入進行檢核,若是數字,則將該編號相對應的成語拉出,若不是數字,則比對所有成語,將含到該關鍵字的成語列出在ListPicker中,讓使用者挑選,完成後使用起來感覺還不錯。

參考文獻:
1. 教育部國語辭典公眾授權網

2018年8月23日 星期四

霹靂藝術科幻特展
時間: 0629-0924
地點: 中正紀念堂1展廳

Date: 20180818
Version: 1

霹靂第一次展覽,我是和學長一起去的,我看的布袋戲不多,但還是覺得霹靂可以做成這樣真的很厲害,甚至跟日本合作出了「東離劍遊記」。

今年是霹靂第二次展出了,所以我也準備要前往了,可惜的是學長遠居美國,今年沒辦法一起去了。

因此我就跟我妹去看了展覽,早上去看了大英博物館的,下午再看霹靂藝術科幻特展,比較遺憾的是,現場某個時間點有cosplay,可惜都錯過沒拍到照片。

這次比較特別的是,會需要下載APP來進行展場活動,掃描光碼,比較舊的手機沒辦法掃描光碼,就只能掃描QR Code,但這樣說真的,後續體驗就稍差了。

光碼的用途,是提供掃描各個人偶後,會提供該腳色的相關介紹,我認為主要的目的是,增加對各個人偶的認識,以及加深與展場的互動性,畢竟整場如果只是和人偶拍照,說實在的真的會很乾,就像第一次展覽,不是說第一次展覽不好,畢竟第一次本身就是亮點,其實不需要多太多其他的東西,而且也是因為第一次,沒有辦法預期民眾的接受度如何,當然也不會再增加成本。

有了這互動性,大家被留在場內的時間會明顯變長,但要說明的是,現場工作人員其實說明得很詳細,只說要對著人偶掃描,但其實是對著照向人偶的光線掃描,要讓攝像頭對著照向人偶的光線掃描,這樣才能掃描的到,被這個搞了超久的,最後抓到訣竅,馬上就掃到了,另外一個重點就是如果要保留相關內容,就不能刪除APP,另外場內有一區是掃描光碼獲得招式,有機會獲得折價券,有95%和90%,我只抽到95%的。

整場下來,我覺得比第一次好玩多了,互動性高,會讓人有再收集東西的感覺,我妹就玩得不亦樂乎,越是蒐集,就越不甘心有些沒蒐集到,人偶比第一次還要多,連場外都有大型Q版人偶,非常好玩,場內快結束時,有一個小型電影院,可以看到很久以前和現在的畫質,真的差超多的,另外片中還有一個爆點就是「素還真 2020 決戰 大螢幕」,如果真的出的話,一定支持,而且會找學長一起去看,希望那時候他有回國。

最後當然就是販賣店了,有超多公仔可以買,可惜沒錢,最後只買了兩個原聲帶,因為是清庫存,每份只要30元,還送許多明信片,到時候拿來當禮物送人吧。

整體下來,非常期待下次展覽又會有甚麼新花樣,以及2020的電影版,而且聽說「東離劍遊記2」也要出了,真的是非常期待!

有想看到現場照片的,可點擊下方連結進行下載,不確定甚麼時候會刪除檔案,不回補檔。
展覽照片下載

人類大歷史:也受到扮演上帝
                                        哈拉瑞

Date: 20180809
Version: 1

介紹人類歷史

人類歷史科普書籍

總體而言,是從古到今的介紹人類的歷史,每一小節都是在人類歷史中的一部份,所以讀起來不會很吃力,就像看一小篇一小篇的文章一樣,輕鬆有趣。

故事的發展,從物理、化學、哲學、文化、科學...等都與人類的歷史演進有關,讀者都可以從其中找到自己感興趣的一塊,其中,最讓我感興趣的是介紹金錢,金錢是建立在人類彼此之間「信任」,這是我從來沒想過的一點,再更進一步,金錢建立了經濟,或者是說「信任」建立了經濟,建立在彼此對於未來的展望。

因此,如果人們對於未來充滿前景,就會不斷地刺激經濟,反之,若對未來不看好,則經濟趨於萎縮。也由於經濟建立在信任之上,對於未來充滿著前景,經濟就像吹泡泡一樣,不斷地變大,直到有一天出現了戳破泡泡的那個針時,整個經濟就會垮了。

那為什麼經濟會不斷膨脹呢?考慮到經濟也是一種資訊集合體,也會帶有熵的特徵,整體而言,熵是會不斷地增加,不斷降低彼此的連結性,最後導致個體彼此分離,換句話說,這個泡泡遲早有一天會破掉的。

2018年8月18日 星期六

桃捷資訊組二三事

Date: 20180809
Version: 1

從去年12月到現在,我待在資訊組也超過半年以上,不久也將滿一年了,時間過得很快,事情做了許多,就來說說我這段時間的感想吧!!

在資訊組的前幾個月,都沒接觸甚麼程式,因為那時候人太少,每個人都接了一堆業務要進行,主要都是在開會及處理採購案,也都是等到這是上軌道之後,才慢慢地比較多的時間放在寫程式上。

在這段時間中,也發現與其他人溝通佔了業務上很重的百分比,如何有效的溝通,並且留給對方正面的形象,這真的很重要,己以善待人,人以善待己,尊重是互相的,這從我接了別人的業務後有的感慨,當然也不是說是前人的錯,只是每個人的行事作風不一樣,產生的效果也不太一樣。

在職場中,講別人怎樣怎樣是再平常不過的事了,但真的要與對方接觸,你才會知道實際狀況是怎樣,像我接手的案子,前人說誰誰誰怎樣怎樣,但實際與對方接觸過,我覺得對方是很認真的,並沒有想像中的那樣,所以許多事情都還是要眼見為憑。

當然在職場上,也不是一帆風順,也會遇到某些人,某些單位就是很難配合,或是態度強烈,這真的只能靠主管來幫忙,所以有沒有主管是很重要的事,有沒有好主管也是很重要的事。

配合公司政策,每月要回去司機員溫故訓一次,我覺得沒有甚麼不好,偶爾換換工作環境,放下手邊的事情,是可以稍稍放鬆一下,所以個人對於此政策保持正面的評價。

當然很多事情,最後還是會回到政治因素上,對於桃捷這種公營機關,更是如此,當然我們無法改變甚麼,就只能盡量配合公司政策執行。

在這段期間,我也算是蠻適應這種生活了,也知道當開會時,大家都不太會主動參與,這時候主席/主辦人就很重要,至少你要有對於未來的一定規劃,並在會議提出後,再請其他同仁發表意見,這會比甚麼都沒有就要開會,容易進行多了。

所以我認為如果想在桃捷繼續待下去,內部招考轉經管人員是一個不錯的選擇,畢竟輪班人員真的是非常的辛苦啊,我就是因為受不了夜班生活,才想趕快離開,也很幸運的內部招考面試上經管人員,而且也算是有一定的了解的工作,至少我還會繼續做下去。

說到這個,我妹就一直想離職,而不是換別的單位,這我也沒辦法阻止啊,如果年底有調整職位的話,或許明年會考慮搬出去住,畢竟通勤40分鐘實在太累了,希望可以找20分鐘以內都算合適了,大概會以中央為考慮吧。

待了這段時間,也經手許多採購案,這時候你就會發現,有些人明明做得比自己久,但為什麼事情處理起來會是這個樣子呢?真是令人不解,或許這就是古人所說的,以人為鏡,可以明得失的道理吧!當然這也是提醒我們自已不要也變成像文中的鏡子一樣。


2018年5月27日 星期日

從叢林到文明,人類身體的演化和疾病的產生
                                                       丹尼爾‧李伯曼

Date: 20180527
Version: 1

這裡想討論人類是否會演化或者是說進化呢?
第一點,時間刻度不一樣,要進行演化所需要的時間刻度遠遠大於現有人類的生活史,以至於無法反應出演化的事實。
第二點,在於演化是指在足夠多的變異之下,由大自然(環境)篩選出適合生存的一種結果,而變異並無好壞之分,只有適不適合而已,在這個情況下,有兩組變異數可以討論,分為外部變異數與內部變異數,而兩者數值都會很大,將兩者相乘後也就是演化的難易度,可見演化是具有一定的難度。
先說外部變異數,也就是大自然(環境)這一項,利用環境來進行篩選,但人類走向外部改變來適應環境,因此,人類不會因為冷就演化出皮厚毛多的物種,而是產生保暖的衣物來禦寒,因此外部變異數就會相對地減少許多,環境將不再是影響人類演化的變異數。
再來是內部變異數,又可以分成兩數相乘,一是基數,二是變異率,如果基數小但變異率高的話,相乘還是可以得到高變異數,若基數大而變異率低的話,還是可以得到高的變異數,先講基數,也就是人口數,在演化的條件下,在選擇下可以生存且可以產生後代的才算做是基數,目前估測為性成熟且有工作能力,約為20歲,而工作可以到65歲,65歲加上產生後代20歲為85歲,但65歲後無穩定收入,故可能無法生存,往前推算20歲為45歲,因此基數人口為20-45歲,而根據世界人口金字塔推算,從1950年到2100年,此基數人口不斷下降。再來是變異率,基本上會維持一個相對穩定的變異率,會有一個相對穩定的週期波型函數來代表,為固定不變的係數,因此,內部變異數為一個下降相乘一個固定係數,總的來說為下降。
綜合來說,外部與內部變異數皆為下降,兩者相乘後會更小,由此可得出對於現階段人類的演化(進化)是很難看到的。

這本書花了我許多時間,中間發生太多事情了,而且下班後還要看一些資訊的書籍,真的是忙不過來,不過這本書對於了解生物相關的人來說,前六章是可以直接跳過的,對我來說前六章都是在介紹演化在人類身上的演進為何?而這本書真正的目的要從第七章才開始,而本篇的重點在於演化失調,簡單來說就是,文化的演化速度快過人類的演化速度,為何不說環境呢?因為文化是人類與環境之間的交互作用的結果,並不只是單單環境可以決定的,是各種因素下產生的結果,即是文化,而文化演化的速度遠超過人體演化的速度,造成人類的身體無法承擔文化演化的結果,即造成現代各種相關疾病的產生,而綜觀整本書,作者最常提到的解決方式就是,適度運度與適量飲食,一樣是老話重談,但卻是至理名言,看完這本書真的是有起到警惕的作用,要隨時注意自己的運動與飲食習慣。







2018年4月16日 星期一

排班管理系統

Date: 20180415
Version: 1

用來取代副段人工排班可能造成同仁認為副段可能偏好某些人,那些人可以排到比較好的假或是比較好的班,造成人為因素的影響,故此排班管理系統其目的是為了公平公正公開而設計的。

剛好,今年的新人軟體開發訓練課程,剛好有機會請老師提供協助製作這樣的系統,雖然工作繁忙,沒有太多的時間可以進行開發,但可以先和其中一位新人一樣,先進行流程圖之規劃,並請老師提供建議,再加上本身是司機員,對於流程有一定程度的了解。

經過思考後,發現其實排班管理系統,有很大的部分很接近大學常用的選課系統,非常的類似,完全可以使用選課系統的邏輯,再加上車班實際運作的邏輯來完成這個系統流程設計。

資料庫
演算法
前台(司機員、副段)
後台(資訊管理者)

我對於如何製作這樣的系統很感興趣,而且還可以讓我多學一點東西,目前課程使用的是ASP.NET,我一點都不了解,希望有機會學到,但身上事情真的很多,希望之後可以少一點事情,讓我多專心於軟體開發上,除了排班管理系統,還有司機員班表APP要進行。

使用者(司機員)
審核者(副段)
管理者(資訊組)??

排班
交換
審核
公布

資料庫
演算法
前台(司機員)
前台(副段)
後台(資訊管理者)??

1070416今日完成流程圖,之後參考相關文件後,會試著作作看ER Model。

1070417已經利用流程圖的概念做了初版的ER圖,之後要將各實體彙整起來。

1070418今日已經將ER總表完成,等星期五與講師討論。


















2018年4月15日 星期日

桃捷公司內部招考

Date: 20171121
Version: 1

公司於九月時發佈了內部招考的消息,共有21個缺,一人最多報名兩個,使用面試的方式進行,一開始我看了招考的缺,想想我應該都不會上,也就沒有太在意,後來聽了學長說,面試就是看臉緣的,順眼就錄取了,而且報名又不用錢,不報白不報,那就報吧!

後來我選擇了企劃資訊組和人資兩個報名,資訊是因為我稍微會一些資訊的,而人資就單純是湊數的,聽我妹說人資的步調都比較慢,到了十月,面試通知來了,時間都是在十月,為什麼要特別強調十月呢?因為我十月是夜班啊!一個在早上,一個在下午,還好是不同天,不然我真是頭大。

先是人資的,我剛到時就發現有一堆人在外面等了,看來人資沒有門檻,所以有一堆人來,一開始我進去就先示弱,說我夜班剛下班精神不佳,之後就是一些面試的相關問題,另外我發現在場的所有人都沒有準備履歷,我有特地準備一下我的履歷,並更新了一下,確實有履歷的話,印像會比較好,因為有人資的主管在,他也說會幫我問問另一個職缺是否須要我,那個職缺是票務中心處理資訊的,不過要求比較高,要工程員或副段以上的人才能投,最後公告出來是從缺,好像沒有人來報名吧!

第二個是資訊組的,在一個小房間裡面試,一開始很直接地問最近寫過程式是什麼時後,我就回答這幾個禮拜內,因為我有在寫手機APP,我就開始展示我的APP給主管看,稍微介紹一下我的APP的功能,之後主管問了一些資訊相關的問題,我都不知道,畢竟我是生物資訊出來的不太了解資訊相關,之後主管也請我介紹一下生物資訊,我就提了一下NGS,之後問了生涯規劃,因為有很多人面試上後,因為考上其他更好的就離職,我就說如果可以有一份正常班的工作,我很樂意繼續待下去。

之後,11月放榜,我考上了資訊組,於12月1日報到,一堆學長姐跟我恭喜高升,不過其實是平調,薪水沒有升,不過大家都對可以在行政大樓工作感到嚮往,不用輪班就非常好了,也發通知制服要繳回,我也是問號滿頭?司機員的制服都是量身定制的,收回到底要幹麻?我問了學姐,學姐說就寫遺失填切結書就可以保留了。

11月是我最後一個月當司機了,雖然新工作一樣有三個月的考核,而且這算是我的第二份工作,還是我完全沒作過的,希望到時後可以一切順利,不用再輪班了,因為司機員的關係,我還有一天的國定假日還沒放,到時後去新單位再放,順便問問如果不忙的話,是不是兩天的特休也可以一起放,就可以12/27,28,29連放,再加上跨年的三天,就可以連放六天了,爽,不過還是要先問問主管。

接著,看看這期招考的結果,共21個缺,錄取了18名,我的工號是1200多號,前方還有30幾位的站務員,大概1250號後都是106期的新人,結果18名中只有3位是106期的新人,比例為16%左右,說明了新人想要考上真的有點難度,但也不是完全沒有機會,因為公司人員流動率算高,所以各部門都會有人離職,所以人員的調動上就會顯得有點頻繁,所以新人也還是有機會的,另外,最近也收到運務處的通知說要內部升遷,兩名都是行控的,而且薪水有一個不變,一個調降,至少資訊的薪水不變,感覺好一點。

前天又收到人資的第三次內部招考了,不過只有一個缺,人資的缺,真不知道為什麼上次不一起招呢?這效率真的是沒話說。另外,最近通過預計明年實施,就是特補休新制上路,為了鼓勵員工放特休,放越多天就會領到越多補助,而補休則是如果沒放完可以換成加班費,以上都是比照北高捷的做法,如此可見之前有多難過,不過也不能這麼說,畢竟桃捷今年才開始賺錢,所以明年開始有獎勵也還算不錯啦,但不知道是不是成立工會的後續影響,就讓我們繼續看下去吧!

之後等到了那邊,工作後再來寫那邊的工作到底是什麼?

工作一個禮拜了,其實也沒甚麼事,就做做一些雜事而已,被叫去參加教育訓練,其他都不算甚麼正式的事,等之後有正式的事再來寫吧。

12月到現在3月,也過了3個月試用期了,我覺得跟司機員的生活實在是南轅北轍的生活啊!可以說是非常的忙碌到爆,雖然是自願的,但偶爾還是很懷念當初司機員無憂無慮的生活啊!但也跟之前學長說的一樣,當了司機員,你就會慢慢缺失想要進一步的念頭,我認為主要是接收到的訊息非常的固定,沒有新的刺激,你就會慢慢地停滯在原地,這是司機員需要自我克服的地方,而在資訊組這裡,你不會有這樣的感覺,每天都有不斷地新的資訊進來,會不斷地推進你往前,因為你不往前,你就會死得很難看啊!雖然周休二日,正常上下班真的不錯啊!但每天真的會忙成像狗一樣啊!累累的~所以回到家後,如何處理自己的時間也是非常重要的。

今年的內部招考又要開始了,這次企劃處和運務處有超多名額的,不知道朋友們會不會考上呢?對了,當初106期南段有7位司機員,走了一個,調單位一個,6月左右還要走一個,目前預計剩4位,快要低於50%了。

2018年4月10日 星期二

桃捷資訊組的二三事

Date: 20180410
Version: 1

這篇主要會是紀錄對於資訊組的一些想法與心得。

目前對於資訊組總結出三個困難點,腦袋難、人際難和規則難。

人際難,並不是組內不合諧,而是要處理各部門單位之間的聯繫很難。

規則難,這大概算是公部門的缺點吧,有各式各樣的流程,而且不會有人教你怎麼做,沒有SOP可以照著做,能做的只能是跟前輩詢問、打電話詢問承辦單位。

腦袋難,是上述這些事情都需要不斷地運轉你的腦袋,不然事情沒辦法做下去,沒有一刻可以放鬆一下。

寫到這裡,總是很懷念當初當司機員的生活,雖然沒辦法按時放假,需要輪班,但工作內容單純,沒有太多惱人的事情(多少還是會有)。

2018年3月21日 星期三

桃捷時刻表(簡易版)

Date: 20180318
Version: 1

因為負責公司官網的時刻表功能,而接觸到了時刻表,剛好司機員APP也剛好告一段落,就想說是不是可以利用一下手邊的資源來做個桃捷時刻表APP呢?

這就分成兩部份了,後台資料處理,需要將OCC提供的時刻表轉成我之後APP方便處理的格式,這部分是用Perl完成的,並不難,難的地方是在邏輯思考的部分,這部分就想了快一天左右,想出來後之後都很簡單做。

資料處理好後,接下來是就是APP的設計了,既然要做時刻表APP,當然要參考一下業界的形式,而個人最常接觸的就是台鐵的時刻表如下:

http://twtraffic.tra.gov.tw/twrail/TW_Quicksearch.aspx

因此,我的APP設計版面都是參考台鐵而來的,畢竟台鐵的時刻表查詢理論上也是國人最常用的,因此,若介面相似的話,理論上旅客都會比較容易使用。

接下來就是選擇日期的部分,發現AI2的日期選擇不太好用,所以上網找了資料後,將資料改成中文後,以及國人常使用的日期顯示格式後,並參考家人的意見進行修改,好不容易日期選擇的部分終於完成了。

選項設定好後,接下來就是時刻表資料匯入,這部分也是搞了好幾天,推倒了好幾次,終於把資料匯入了,並且使用Scroll和html格式,讓時刻表可以滾動,並上網查資料如何讓新的資料輸出時可以回到最上頭,也參考別人的方法後,終於讓APP符合自身的預期。

看起來非常像有這麼一回事一樣,不過如果這個要推出的話,就要放到google play上了,不過這就是公司的問題了,因為google play是要收錢的,我個人是不會這樣做的,所以只能用公司的名義去做,另外就是,目前公司的APP招標開始了,我的想法是雖然開始招標,等到決標也是4月的事了,再等到功能要上架後,也差不多要4-6個月,這一段空窗期,是否可以提供一個簡易版的時刻表APP呢?當初的想法是這樣的,剩下就要看長官是否覺得可行?

不過這個版面大概就是這樣了,主要是提供旅客簡易的查詢時刻表APP,所以應該不會放太多精力在上面,主要就是簡易,這個只要2.7MB就可以了,非常快速,而且跟火車查詢很像啊。


























後來在測試的時候,發現datepicker在第一次使用會有bug出現,後來發現是因為第一次loading的時候,會比較久,所以造成timer讀取產生錯誤,解決方法就是在開起應用程式時,就進行載入,這樣後面使用datepicker時就不會造成讀取錯誤。



2018年3月18日 星期日

桃捷司機員APP

Date: 20180127
Version: 1

繼之前寫過一次APP後,最近又開始新的專題,目標是多人使用,之前有做過一次,可惜失敗了,直到現在公司長官覺得可以推推看後,就打算再試一次看看,如果我做不出來,那推也沒必要了,這一次就快了許多,畢竟有個人版可以參考修改,我只花了兩天就做出來了,後面三天主要還是在做優化的部分,整體來說,比上次進步許多,尤其是Perl的hash觀念幫忙我許多,不過因為資料庫處理的關係,顯示速度稍微比個人版的慢了一點,可以看下方關於顯示速度的優化,基本上功能都用好了,接下來就看看長官們到底買不買帳,畢竟APP的使用目的是有限的,例如:「看一個月內的班表、想看其他人的換班」,這些都只能回去看LINE上的圖片,再來是副段們修改是在電腦excel上,之後再轉成圖片放在LINE上,之後就看他們有甚麼要求吧,畢竟他們慣用的excel格式跟我使用的還是有所差距,另外總班表更換時,他們也要跟著更動,除非這些都是由我來負責的話就沒差了,單純就我這邊操作也是可以的,不過一旦我離職,這APP就會跟著GG了。

之後就會更新一些公司的狀況,看看這個APP之後的方向會是如何的呢?

小寫開頭為number or string
大寫開頭為array
中間有底線為hash
中間有@為database,為從google試算表中拉出的原始資料

today: 今天日期
year: 今天年份, from today
month: 今天月份, from today
day: 今天日期, from today
driver: 使用者工號

Type: 班型
Time:  當月日期
Start: 上班時間
End: 下班時間
Extra: 加班時間
Detail: 任務內容
AllDetail: 所有資訊

Type@Database: 所有班型資料,含班型、上班時間、下班時間、加班時間、任務內容。
Driver@Database: 司機員資料,含工號、當月班型。

Driver_Schedule: 司機員相對應之當月班型
Time_Type: 當月日期對應之班型
Weekday_Name: 星期幾的中文名稱
Month_DayNumber: 當月份之天數
Type_Start: 班型相對應之上班時間
Type_End: 班型相對應之下班時間
Type_Extra: 班型相對應之加班時間
Type_Detail: 班型相對應之任務內容
Type_AllDetail: 班型相對應之所有資訊

完成部分:(*未完成)
今日顯示
工號清單
日期清單
任務清單功能
資訊顯示
班型按鈕顯示
今日按鈕顯示
工號清單功能
日期清單功能
使用者系統(第1頁輸入-->第2頁呈現)*
使用者鎖定(第一次輸入使用者後,再開啟會鎖定使用者,故不需上方的使用者系統)
返回按鈕顯示
月曆模式

顯示速度優化測試:
個人版:舊版,0.567秒
多人版:初版,各資料顯示放於各資料庫讀取階段,故2階段需1.101秒
多人版-2:統一資料顯示時機後,0.868秒,加快20%顯示速度
多人版-3:司機員匯入數量增加(3->57),0.901秒,約慢了3%

自動化系統:(未完成,失敗,Net::Google::Spreadsheets安裝失敗,QQ)
修改完資料後,運用perl後會進行上傳至google試算表

Perl轉檔
perl會使用perl2exe轉成exe檔後,提供使用

特地去做了一個返回鍵的圖示,是用PowerPoint做的,效果還不錯,還蠻符合APP的色調。
以下為APP目前形式:

























後來,與中油的朋友討論時,發現中油也有輪班表APP,但他們只有4種班型,不會有個資的問題,所以他們的APP可以在Google Play上找到的,另外我也找到中鋼的APP,兩者的共通點都是只有4個班型,而且都是用月曆的模式來呈現,因此我也在思考是否可以做出動態的月曆出來,畢竟之前我是使用圖片的方式呈現。

經過一翻思考與設計後,月曆模式終於完成了,可以呈現出該月的班型狀況,使用三種顏色,藍色是當日,紅色是放假,灰色是上班,另本來打算是要在班型的地方改用按鈕方式呈現,但按鈕的效果不如預期,所以最後使用的是在月曆下方使用下拉是選單,來讀取班型內容,當然也有選擇使用者的功能。

























目前,大致上會有三種版本,1)日曆模式、2)月曆模式、3)日曆+月曆模式,中油和中鋼是2,之前個人版算是1+2的圖片,理論上應該會是使用3的版本提供大家使用,當然最後還是要看使用者的意見決定之。

後來也仿照其他APP的功能,多做了一個關於的功能,放一些資訊,可供長官們發揮的區塊,另外還學習如何使用Email的功能,App Inventor 2的功能真是越來越厲害了,不過還是有許多地方還可以再改進。

經過一段時間後,Mail的功能已經做好了,並且也與車務中心開了兩次會議,中心主任甚至認為這個APP推出後,其他場域的人都會想用,不過最重要的是希望可以與公司的ERP系統介接,這樣資訊都會是最新最完整的,關於這部分,我剛好在看一些APP的作品有用到json的格式來達到類似的目標,所以如果可以將ERP的資料用json的格式丟出的話,理論上我這邊的APP應該是可以做到的,再來就是json資料的資安規範,要如何規劃,畢竟要接到我的APP一定是要透過外網來使用,所以外網的資訊安全就格外重要,目前公司這邊還在處理ERP資料拋出的部分,所以這部分就要等ERP部分處理好後,才會接下去,到時候可能就會再開一個新的文章了。

2018年1月12日 星期五

Unity小試身手-警察抓小偷

Date: 20180112
Version: 1

主要內容為在一個棋盤格式的地圖中,警察要在棋格上移動,找出小偷躲藏的地方。












規格:
Unity: Unity 2017.3.0f3 (64-bit)
Asset: Fungus
Android SDK:Android 6.0 API 23, Android Tool 25.0.0
JDK:jdk-8u77-windows-x64 (jdk1.8.0_77)

學習平台:
1. fungus詢問平台
https://muut.com/fungus#!/

2. 陳間時光 youtube
https://www.youtube.com/channel/UCXWxqnjzo4q6NhQiLhQFk7g


學習記錄:
collider -> clickable -> flowchart(can use object click action)
rigibody->collider->other.trigger(script needed)

Scripting > execute lua
-----------------------------------------------
local thief = getvar(flowchart, "Thief")
if (thief.value == 1)
then
thief.value = 2
--print(thief.value)
--return(thief.value)
end
----------------------------------------------
說明:
--註解
getvar 取得在flowchart中的fungus變數名稱"Thief"
local 只給fungus使用
thief.value = 2 將thief物件中的數值value改為2,此時fungus中的Thief會變為2
print(thief.value) 會在debug.log列印出來,除錯用
return(thief.value) 將thief.value回傳給Return Variable
Return Variable 要回傳的fungus變數,可為<None>
有return(...),Return(<None>),沒有回傳變數,故回傳值回傳後就不見了,程式正常
有return(...),Return(...),將回傳值回傳給回傳變數,程式正常
沒有return(...),Return(<None>),沒有回傳值,也沒有回傳變數,程式正常
沒有return(...),Return(...),沒有回傳值,有回傳變數,回傳失敗,程式error
lua if 結構式為: if () then {} elseif () then {} else {} end
lua 且(and )、或(or),不是&&或是||



遊戲步驟:決策 > 移動

決策說明:(三者擇一)
1. 調查:可得知與之相連的棋格是否有小偷,return 有無小偷。
2. 部署:在原地點佈下警力,小偷不會進入此區域,但有持續時間/次數之限制。
2. 技能:可使用角色技能。

移動說明:選擇與之相連的棋格進行移動,return 有無小偷。
1. 有小偷:逮捕,遊戲結束,按照步數進行獎懲。
2. 無小偷:進行循環。

初始:
設定警察、小偷位置
1. 設定警察位置,九宮格共9個位置(set police.random = 1-9)
2. 設定小偷位置,不能與警察同格(set thief.random = 1-9,  while (thief == police){set thief.random = 1-9})

流程:
警察(決策>移動) > 判斷(抓住與否) > 小偷(移動)

決策:
調查:
1. 警察四周可移動之位置,確認是否有小偷,若有則回傳對話框saydialog,if (police == thief or police == thief ){},使用lua撰寫。

部署:
1. 鎖定位置,讓小偷無法進入,但不影響警察進出。

警察移動:
1. 判斷自身位置(九種位置)(if police == 1-9)(9種){依照自身位置給出方向(角2、邊3、心4,上下左右(menudialog)}(24種)
    1-1. 判斷周遭狀況(部署)
2. 連至相對應的block(move to 1-9)(step++)(set police = 1-9)

判斷:
1. 若警察和小偷的位置一樣,則跳出對話後,給出兩種選擇"重新開始"、"結束遊戲"。

小偷移動:
1. 判斷警察和小偷位置後,使用if功能,確認出小偷可以移動之方向,若距離一樣,則使用隨機給出方向。
2. 使用lua。

目前會暫停這項計畫,發覺這遊戲好像沒這麼好玩,需要重新思考一下,可能會繼續卡牌遊戲的設計吧!

2018年1月1日 星期一

桌遊設定-2

Date: 20180101
Version: 1

主要還是延續桌遊設定-1的主題內容,但時間已隔許久,所以決定重開一章來繼續撰寫。

出生開始就邁入死亡 = 結構化-->失序化 = 不斷熵增的過程,而唯一的出入就是進化 = 就在讓自身再次結構化 = 達到熵減的結果。

所以遊戲剛開始有一個固定熵值,隨著遊戲時間進行,熵值會不斷增加,最後到達閾值,遊戲結束,因此,遊戲目的就是讓對方熵增加快(熵值增加,隨遊戲時間進行、讓對方受傷),讓自身熵減(熵值降低,結構化=創造招喚物)。

利用招怪的方式,降低熵值,換句話說,也就是用熵值來進行招喚,故招喚物死亡後,也就是失序化,熵增。

熵值等於能量,能量可轉換為攻擊力、防禦力、效果、生命值,這四種是卡牌遊戲共有的,但四種太多了,困難度提高,因此需要降低複雜度,也就是說,需要把好幾種變為一種,以降低複雜度。

防禦力用來抵銷攻擊力,可以併入效果或生命值,剩攻擊力、效果、生命值,效果無法併入其他,剩攻擊力和生命值,兩者是否可以合併?生命值也就是體質,體質越好所蘊含的生命力更高,那是否體質越好的人,其攻擊能力越強呢?體質越好的人,其支撐這個身體的能量需要越多,來包括維持血液循環、神經反應、肌肉強度、肺活量...等,根據E=mc^2,能量越高,質量(體質)越高,再經由F=ma,也就是力(攻擊力)越高,因此,得出攻擊力和生命值是可以相容的,同理,當受傷時,生命值下降,體質降低,攻擊力也會跟著下滑,故兩者為正比。

最後結果為,能量 = 效果+ (攻擊力 = 生命值),之後也會按照此規則進行設計。

遊戲背景設定:
在各種的計算之下,唯一得到的答案都是宇宙寂滅,所有的一切都將在宇宙大磨盤前化為虛無,於是乎在這樣的情境下,各種族不斷的嘗試各種超脫之路,期望自身可以擺脫那永恆的夢靨。
在各種超脫之路上,各種族專研各種降低熵值的方法,來達到永恆超脫的境界,而玩家扮演的就是各個種族,每個種族都有其專研的超脫之路,正所謂死道友,不死貧道,不需要跑第一,只要跑得比別人快就行了,各玩家就是在比拚誰能活到最後,誰擁有最多的時間來完善和專研超脫之路。

遊戲模式採類似「魔幻卡牌」的遊戲機制,完全不考慮牌運,也就是說一開始就可以使用所有的卡片,也因此卡片數量因展示空間有限,目前考慮為極數9來做一個規範,所以一個種族有9張牌可以使用。

再來是戰鬥部分,根據牛頓第三運動定律「作用力與反作用力」,攻擊別人時,力也會同時作用到自己身上,所以決不會有這回合我打你一拳,然後計算傷害,下回合你再打我一拳,然後再計算傷害,傷害是同時的。

而傷害結算就是,(攻擊力=生命值)互減,即A.attack-B.attack和B.attack-A.attack,戰鬥是同時發生的,不會有我先打在換你打的狀況發生,雙方攻擊力互減後,若攻擊力<=0,則滅亡,熵值則回復。再來是abs(A.attack-B.attack)的值是否要加到被消滅方的熵值上呢?這就要考慮到熵值的定義了,到底是個體熵值,還是種族熵值?若是個體熵值,則玩家本身就是個體,個體不會在招喚其他個體;若是種族熵值,則種族會招喚出個體,期望個體當中會有一個可以達成超脫,因而帶動整個種族達成超脫。

從上述得知,故熵值為種族熵值,因此,個體進行戰鬥損傷後產生abs(A.attack-B.attack)值,並不會影響到種族的發展。種族熵值預設為100,起始為50。

每一回後結束後,熵值會自動上升X值(5 or 10),如同生命隨著時間慢慢步向死亡一般。

再來就是攻擊對象,有兩種可以選擇,1)可以自由選擇攻擊對象,例如遊戲王,2)只能攻擊對格怪獸,例如魔幻卡牌。(尚未決定)

再來是場上怪獸數量為3。

下怪的方式,因平常的遊戲是你一回合我一回合,是輪流放怪出來,所以後放的會看到先放的怪獸資訊,因而選擇相對應的怪獸,那是否需要當雙方都按下確認後,雙方才能看到對方選擇的怪獸。(尚未決定)(資訊透明的程度)

攻擊階段,是否可以選擇不攻擊?因攻擊後,勝利方生命值減少,下回合一定會被打死,如此循環,結果就會是第一個戰敗的會輸,但雙方都選擇不攻擊,這遊戲就不好玩了,沒有積極度。

再來是如果雙方同時進行攻擊,若其中一方有兩隻怪,一方只有一隻的情況下,要同時進行攻擊,A方,選擇A.1打B.1,因B.1血較少,而B方,選擇B.2打A.1,這樣B.2會活下來,對方會空場,且B.1可以直接攻擊玩家(先不論可不可以攻擊玩家),這樣的情況下,雙方的選擇步一樣時該如何處理?若換成一方動完換另一方動,就不會有上述的狀況發生。

在上述的討論中,發現就牛頓第三運動定律而言,真正重要的是攻擊別人即是攻擊自己,因此,重點要放在攻擊對手後自己也同時會受到傷害,與互相輪流放置攻擊或同時放置攻擊並無相關,是屬於另一個議題,再來是受到傷害的來源是 1)對象的攻擊力,還是 2)自身的攻擊力。

1)對象的攻擊力
考慮到作用力與反作用力,故當自身攻擊時,就會受到對方攻擊力的攻擊力,因此兩者相減小於等於零時死亡,這也符合攻擊力=生命值的設定,再來就是當攻擊對方後,傷害溢出值abs(A.attack-B.attack),因前項考慮後為個體損傷不影響種族,故傷害溢出值無實際作用,除非種族特色/效果所致,接著是攻擊結果,A為己方,B為對方時,共會有XX種狀況如下:
若A.attack > B.attack,A.attack=A.attack-B.attack>0,A存活,B.attack-A.attack<0,B死亡。
若A.attack = B.attack,A.attack-B.attack=0,A死亡,B.attack-A.attack=0,B死亡。
若A.attack < B.attack,A.attack-B.attack<0,A死亡,B.attack=B.attack-A.attack>0,B存活。

2)自身的攻擊力
考慮到作用力與反作用力,故當自身攻擊時,就會受到等同自身攻擊力的攻擊力,因此兩者相減為零,自身會死亡,這也符合攻擊力=生命值的設定,再來就是當攻擊對方後,傷害溢出值abs(A.attack-B.attack),因前項考慮後為個體損傷不影響種族,故傷害溢出值無實際作用,除非種族特色/效果所致,接著是攻擊結果,A為己方,B為對方時,共會有兩種狀況如下:
若A.attack >= B.attack,A死亡,B死亡。
若A.attack < B.attack,A死亡,B存活且B.attack  = B.attack-A.attack。

會產生自身若攻擊比對方低,就不會攻擊對方的現象,所以是否強制雙方進行攻擊,但這樣子就會產生強弱強弱的循環,所以這時種族特色/效果的點就會出現,如何突破輪迴,就是要依靠種族特色/效果。


種族特色: