第25個冬天

第一週上「策略規劃」的課 剛好聽到老師分享關於論文題目選定和取名的眉角 論文題目愈長愈多設限愈好寫 1.題目就是「摘要中的摘要」 論文題目在於提供「論文內容的一個迷你化的描述」 可更白話講成是「比摘要還要摘要的訊息」，利於告知讀者，本篇論文實質內容為何。 2.題目通常包含變數 題目通常會包含「變數」像是 自變數、應變數、中介變數、干擾變數， 這邊所指的變數和我們寫程式那種比較沒關係。 若我們的論文可以很容易分成自變數與應變數、中介變數、干擾變數，一個簡單題目形式可能就會透過如下形式自行挖洞去填入，論文主題就是討論自變數對於應變述的影響，以及中介或干擾變數的影響，單純只要置換該句子題目就可自然而然產生了。 中文表達: 「自變數對於應變數的影響」 「自變數對於應變數的影響:中介變數的中介」 「自變數對於應變數的影響:干擾變數的干擾」 寫成英文 「The Influence of A on B:The Mediation of C」 「The Influence of A on B:The Moderate Effect of C」 透過"的影響" 後綴的論文題目就一堆 但大部分時候，自變數跟應變數可能不只一個會有兩個以上，則題目就會比較複雜了。 「The Influence of A1, A2 and A3 On B」 可看見一個問題，因為自變數太多論文題目會開始變超級長，這時候也有種作法就是把自變數改成用概括性的方式來表示，也就是可能用一個A來代替A1~A3。 比方用Psychological factor(心理層面因子)來取代Self-Esteem(自尊) , Narcissism(自戀) and Loneliness(孤獨)。 若無法找到抽象化的A來取代A1~A3，則可用Influence factors做取代，不要特別去具體陳述捨麼影響因素。 比方一些題目 一個自變數、一個應變數 The Influence of Narcissism on Facebook use. 有干擾變數 The Influence of Narcissism on Facebook use: The Moderate of Gender Difference. 多個自變數 The Influence of Self-Esteem, Narcissism and Lo...

  過去在架設ERP相關硬體跟軟體環境過程十分繁瑣 也會導致原先目的是為了學習使用的目的失焦 因此這次要來嘗試使用SAP ERP in the Cloud (Hana Cloud) 在搭建實務之前先稍微認識這產品吧 雲端方案的ERP讓我們，從採購資源到訂購到現金和財務, 製造都整合在一起， 都可以通過網際網路取得，而不必購買硬體或資料庫。 就像搬進公寓租屋一樣，你會有每月付款或租金, 然後你可以自行去客製化你所需資源方案, 以滿足您的需求，當然也有些許限制，不像在地端可以有一些打掉牆壁的彈性，不能改變雲端軟體的內在價值或結構｡ 最後, 當您的合約結束時, 您可以離開並帶走您的資料｡  這些資料就好比如你買的家具、家電、衣服可以自由攜帶、移轉。 https://www.leanix.net/fr/wiki/tech-transformation/options-de-deploiement-sap-s4hana HANA主打在充分利用SAP內存基礎中，資料庫效能和靈活性方面徹底有大幅度提升的改變。 此外， 通過預先配置的最佳實踐，您擁有一個內建的流程或模型來標準化公司的流程， 從而提高品質和生產力，標準化的流程大大縮短了實施新ERP的時間， 降低了成本和風險。 根據每種模型的不同消費者以及誰提供或管理資產，雲端運算通常分為三種廣泛的服務模型或類型。這三種模式分別是軟體即服務 (SaaS)、平台即服務 (PaaS) 和基礎設施即服務 (IaaS) SaaS 目標受眾:企業最終用戶 作為服務交付的軟體是針對該軟體面向業務的最終用戶。例如，SAP 的 Business ByDesign 是以即用即付方式為 SAP 最終使用者提供的軟體。 NetSuite 提供類似的 ERP 解決方案，而 Microsoft 和 Salesforce.com 則提供基於 SaaS 的客戶關係管理系統。 更白話來理解可將其視為雲端中預先建置的應用程式。雲端供應商託管、開發、管理應用程式並將其交付給企業的最終用戶；企業的IT部門在這方面完全沒有任何關係。 PaaS 目標受眾:應用程式開發人員 作為服務提供的平檯面向應用程式開發人員。開發人員使用外部管理的應用程式平台來建立和運作新型應用程式、服務和解決方案。PaaS 環境消除了與 IaaS等較低層級...

https://www.cnblogs.com/cdaniu/p/16709716.html 資料庫存常見的方式 ODBC(Open DataBase COnnectivity)開放資料庫連接 提供應用程式介面，使得任一DB都能藉由ODBC驅動與指定的DBMS相連。 早期的程式設計師在程式中要連接資料庫是非常困難的，每種DBMS產生的資料庫檔案的格式都不一樣，程式設計師要對他們存取的DBMS的底層API有相當程度的了解，透過API來存取特定的DBMS。這就產生了一個問題，當使用的DBMS改變後，或是使用者習慣使用的DBMS與開發程式使用DBMS的不符合時，應用軟體便無法正常存取DBMS。因此，能處理各種資料檔的API便產生了，這就是大家都知道的ODBC。 ODBC是透過API的早期產物，是根據SQL 的，以此作為存取資料的標準。這時大多數DBMS提供了一個根據ODBC的驅動程序，遵從了這個標準的DBMS被稱為ODBC相容的DBMS。 ODBC相容的資料庫包括Access, MS-SQL Server, Oracle, Informix等。 用戶程式能藉由呼叫ODBC驅動管理器中相應的驅動程式去存取或管理資料庫。 當程式要去訪問DB時候是交由ODBC管理器將應用程序的資料庫訪問請求傳遞給相應資料庫驅動程序，該driver再去執行SQL完成任務。 DAO(Data Access Objects)資料庫訪問物件 使用微軟的Jet提供資料庫訪問物件集合做存取DBMS，據說性能比ODBC更好。 OLE DB  微軟發明的，想用來淘汰掉ODBC的。OLE DB不光可連接各種DB，還能達到連接類似AD、OS文件目錄各種不同DB資料源，當然也需要分別使用不同的driver。 其實定位跟ODBC差不多，差異在於有COM標準支援(底層用C++ API)，ODBC則是根據C  API。 當ODBC成為資料庫介面的標準之後，大多數關聯式資料庫都提供了根據ODBC的驅動程序，使得該類型的資料庫檔案可以被ODBC存取。前面說過，ODBC只可以存取任何支援SQL語言的關聯式資料庫，而OLEDB可以存取各種類型的資料來源，包括關聯式資料庫，所以說，符合ODBC 標準的資料來源是符合OLE DB標準的資料來源的子集。 那麼，OLEDB是否可以取代ODBC呢？不會。 符合ODBC的資...

  證書頒發機構(CA:Certification Authority) CA信任-兩種類不同用途的證書 1.用於建立信任關係的證書 2.用於建立通訊過程中資料加密、簽名，確保資料安全的證書 使用者或網站之間使用到的公鑰與私鑰是如何生成的? a.在申請證書時，需要輸入姓名、地址、email等資訊，這些資料會發送到 一個稱作CSP的程序(Cryptographic Service Provider)。 CSP是微軟公司的使用者在windows平台上提供第三方加密模組的介面標準。 此程序已經被安裝在申請者的電腦內。 b.CSP會自動建立一對密鑰(一公一私)。CSP會將私鑰儲存到申請者的電腦 註冊表中，然後將證書申請資料與公鑰一併發送給CA，CA檢查這些資料無誤後， 會利用CA自己的私鑰將鑰發放的證書進行簽名，然後發放此證書。 申請者收到證書後，將證書安裝到其電腦內。 c.證書內包含了證書頒發的對象、證書有效期、頒發此憑證的CA與CA的數位簽名。 以及申請者的相關資訊(姓名、地址、email)和公鑰資訊。 AD CS 的CA種類(Active Directory Certificate Service) 1.企業根CA(Enterprise Root CA) 1-1.需要AD環境，可安裝到Domain控制器或是Domain成員伺服器上 1-2.頒發證書的對象僅限Domain用戶 1-3.主要工作應該是用來頒發證書給從屬CA，發放證書的具體工作交給從屬CA來負責。 2.企業從屬CA(Enterprise Subordinate CA) 2-1.也需要AD環境 2-2.適合用來證書的具體管理與發放工作 2-3.從屬CA必須向其Parent CA取得證書後，才能正常運作。 2-4.從屬CA也可頒發證書給下一層的從屬CA 3.獨立根CA(Standalone Root CA) 3-1.類似企業根CA，差別在於不需要AD環境 3-2.扮演獨立根CA角色的電腦可以是獨立的伺服器、成員伺服器或Domain控制器 3-3.無論是否為Domain用戶皆可向獨立根CA申請證書。 4.獨立從屬CA(Standalone Subordinate CA) 4-1.類似企業從屬CA，差別在於不需要AD環境 4-2.扮演獨立從屬CA角色的電腦可以是獨立的伺服器、成員伺服器或Domain控制器 ...

  每一天的累積都是未來的一大步... 在歷史故事或小說中，特別是在傳統的武俠小說中，常常有類似於到特定地點修行或學習以獲得特定武功技能的情節，就好比在不同公司工作可以學到不同的技能和經驗。 比方金庸的武俠小說《射雕英雄傳》中的主角郭靖先後歷經了 江南七怪傳授的基礎武功，跟洪七公學到降龍十八掌。 從黃蓉那裡間接學到了九陰真經。 在絕情谷中從老頑童周伯通那裡學到的空明拳。 隨後還有陸續跟丐幫接觸到打狗棒法等武術，每一位師傅教他不同的技巧。 基本上每一天工作不管學到捨麼程式語法技能， 每次在實際工作中施展出來就很像使用了某一招武功秘笈。 也可以讓工作過程保有一點儀式感跟熱忱，就很像打電動發出特殊絕招。 接續之前篇章-原先的前七篇篇章(水晶報表七日成蝶) 基本上因為在之前公司接觸到的水晶報表設計開發模式 都是針對visual studio 針對C#/vb.net搭配的開發設計情境 講白話一點就是你可能要在runtime時候都出一個類似DataTable等datasource元件之類透過程式碼方式回填到報表中。 Crystal Report報表開發(一)_專案配置 Crystal Report報表開發(二)_基礎操作排版對齊_基本組成部分介紹 Crystal Report報表開發(三)_綁定資料庫資料源_動態參數傳入 Crystal Report報表開發(四)_報表欄位的自動換行與自動編號 Crystal Report報表開發(五)_每張報表表頭表尾顯示差別_調整區段自動縮放技巧 Crystal Report報表開發(六)_每頁限制細目顯示資料列數 Crystal Report報表開發(七)_缺列補空白_Runtime參數設置_公式設置_避免多浪費空白頁的後端程式修正 看起來七日好像還不太能成蝶XDD Crystal Report其實已經有段時間了也是滿多公司在用的 當然也有些公司若用.net (C#,vb.net)會藉由類似像 pdfsharp 或是 iTextSharp 匯出pdf報表方式 或透過 RDLC  ，若是node.js開發者則可能藉由 pdfkit 。 上述都是在之前篇章有介紹過的常見pdf報表匯出功能solution 不過不得不承認 水晶報表功能真的是滿強大 在後續的篇章中(由於近期公司用到的報表開發模式比較不一樣) 要下載獨立一套c...

一般大宗的出口銷貨作業流程示意圖如下 通常當接收到國外客戶的訂單並且已備齊貨後，出口商就會開始找尋合適報關行(broker)。 委託報關行幫忙辦理出口報關以及租船訂艙事宜。 接下來報關行就會再去協助找尋船公司/空運公司(forwarder)租訂艙位。 待艙位確定後，就會通知出口商於裝船前24小時內將貨物運送至指定的貨櫃點，方便海關查驗及後續裝船，於此同時報關行還要向海關申請報關，之後海關到貨櫃站查驗貨物確認沒問題後，再通知報關行貨物放行，此時也會藉由海關電腦資訊系統同步通知給forwarder，報關行再回復給出口商貨物已經通知允許放行，最後船公司/空運公司就可進行貨物裝運啟航，貨物就正式出口，之後出口商就能通知進口商貨物已經裝船出海的消息，方便其做後續入關報驗的準備。 貨權轉移 細分為如下兩種不同系統流程 「直接銷貨」、「暫出貨轉銷貨」 直接銷貨 假設出口交易條件:FOB 起運點交貨，換言之，當賣方在貨物運輸過程所有權就已移轉給買方(算交易完成)，此時就可認列收入。 常規程序 送交給報關行的所需單據有Invoice,Packing list等資料 暫出貨轉銷貨 假設出口交易條件:DDU，換言之，由賣方負責將貨物運輸至目的地直到交由買方處置為止才算交易完成，運輸過程還不能認列收入。

外貿Payment Term 付款條件(方式)常見的英文縮寫與定義 信用狀(Letter of Credit,簡稱L/C) 開狀銀行依開狀申請人(進口商)的請求、指示，向第三人(出口商) 所簽發的一種文據或函件，是一種直接而且獨立的保證， 開狀銀行直接對出口商負責，只要出口商依規定將貨物裝船交出，開狀銀行一定要付款。 該文據or函件中，銀行向第三人承諾，如第三人能履行L/C所 規定之條件，將予以付款。 信用狀雙重保證: L/C是以銀行之擔保取代進口商信用，但未排除其責任，若開狀銀行倒閉，進口商仍 要履行付款。 以出口商層面好處 1.獲得信用保證 2.獲得資金融通便利 3.確定交易契約 以進口商層面好處 1.資金融通便利 有關信用狀(Letter of Credit, LC)的資料表，會包含多個表格以及相應的欄位來儲存和管理信用狀相關的資訊。以下是一些可能包含的表格和它們可能的欄位： 信用狀主表（LC Master Table） LC編號（LC Number）：唯一識別信用狀的編號。 開狀銀行（Issuing Bank）：開立信用狀的銀行名稱。 受益人（Beneficiary）：信用狀的受益人，通常是賣方。 申請人（Applicant）：申請信用狀的一方，通常是買方。 金額（Amount）：信用狀的金額。 貨幣（Currency）：交易使用的貨幣。 開狀日期（Issue Date）：信用狀的開立日期。 到期日（Expiry Date）：信用狀的到期日。 貨物描述（Goods Description）：信用狀所涉及的貨物描述。 條件（Terms and Conditions）：信用狀的條款和條件。 文件清單表（Document List Table） 文件編號（Document Number）：文件的識別編號。 LC編號（LC Number）：相關聯的信用狀編號。 文件類型（Document Type）：如提單、發票等。 提交日期（Submission Date）：文件提交日期。 支付紀錄表（Payment Record Table） 支付編號（Payment Number）：支付交易的唯一編號。 LC編號（LC Number）：相關聯的信用狀編號。 金額（Amount）：支付金額。 日期（Date）：支付日期。 支付狀態（Status）：支付的狀態，如已支付、未支付。...