搜尋

搜尋結果

升級 Spring Boot WebClient SSL (Reactor Netty 1.2.6):重新配置 SSL 設定
科技新知
MacauYeah・2025-08-27

因為SSL provider 更新了的關係,好多 HttpClient / WebClient 設定SSL的部份都要重寫以免出現 deprecated 問題 reactor.netty.http.client.HttpClient 在 1.0.x, 中可以這樣自行設定SSL逾時的部份,但當中的spec.sslContext().defaultConfiguration 在新版本,例如1.1.x後就會出現 deprecated。 // deprecated version HttpClient.create() .secure(spec -> spec.sslContext(SslContextBuilder.forClient()) .defaultConfiguration(SslProvider.DefaultConfigurationType.TCP) .handshakeTimeout(Duration.ofSeconds(30)) .closeNotifyFlushTimeout(Duration.ofSeconds(10)) .closeNotifyReadTimeout(Duration.ofSeconds(10))); 觀看各大網站,都未有更新,唯有自行研究官方說明。 筆者撰寫本文的時候,netty 發行版本為 1.2.6, 1.3.0 還里程碑(M6)的階段。所有參考皆來自1.2.6版本,實際上我們要使用新的後綴為ContextSpec類,看Class名應該有分http 1.1, 2, 3的版本,筆者就試用最基本的http 1.1。Http11SslContextSpec, (有條件的朋友可以試用Http2SslContextSpec, Http3SslContextSpec) import reactor.netty.http.Http11SslContextSpec; import reactor.netty.http.client.HttpClient; import java.time.Duration; import org.springframework.web.reactive.function.client.WebClient; import org.springframework.http.client.reactive.ReactorClientHttpConnector; //... Http11SslContextSpec http11SslContextSpec = Http11SslContextSpec.forClient(); HttpClient httpClient = HttpClient.create() .secure(spec -> spec.sslContext(http11SslContextSpec) .handshakeTimeout(Duration.ofSeconds(30)) .closeNotifyFlushTimeout(Duration.ofSeconds(10)) .closeNotifyReadTimeout(Duration.ofSeconds(10))); WebClient webClient = WebClient.builder().clientConnector(new ReactorClientHttpConnector(httpClient)) .build(); //... 雖然這個寫法來看netty 1.2.6,但似乎1.1.x 通用。大家有需要可以交互測試一下。 Reference netty 1.2.6 http-client-timeout 的設定 netty 1.1.30 timeout-configuration 的設定 netty 1.2.6 java api doc netty release version 更多筆者的程式開發分享,見請 github

Swarm mode 上線 6 | OS升級前的準備
科技新知
MacauYeah・2025-04-08

如果大家一直有跟進安全更新,基本上每個一至兩個月,都會有OS kernel和Docker Engine Update。也許大家習慣還是以不變應萬變,但有些時候還是不可避免地遇到嚴重漏動,需要強制更新。那麼當我們在這個情況時,我們該如何做呢?在開始做之前,我們先測試一下Swarm的容錯率有多高。 官方就宣稱,只要swarm中,manager例下的數目沒有超過半數,就依然可以運行。這個部份,筆者相信大家一早就感受過。但筆者認為,在直正出意外的情況是,少於半數的manager倒下了,但其餘的manager又不幸要重啟,到底又些活著的manager,又可否成功重新啟動?所以下面就來做些測試。 測試1 測試REPO 初始化script initDockerCluster.sh 筆者在原本的教學中,就有一個3個manager node + 2 worker node的範例,我們只要安裝ubuntu OS, packer, 並使用 # run setupMultipassWithFixIP.sh will install multipass and config fix ip ./setupMultipassWithFixIP.sh # install packer, please refer to https://github.com/macauyeah/ubuntuPackerImage/blob/main/README.md packer init template.pkr.hcl packer build template.pkr.hcl # initialize docker cluster in multipass ./initDockerCluster.sh 在上述的環境中,node21, node22, node23是manager, node24, node25則是worker。在全關的情況下,只要正常啟動兩台manager,worker就可以成功復活。 測試2 測試REPO 初始化script initDockerClusterLoopJoin.sh 筆者寫了另一個起始方案,會有5個manager node,而且依賴順序如下 node22 => node21 node23 => node22 node24 => node23 node25 => node24 node21 => node22 # initialize docker cluster in multipass ./initDockerClusterLoopJoin.sh 在上述的環境中,5台機也是manager。 initDockerClusterLoopJoin 的前半部份,它會建立順序依賴,即每一台機器,都經前一台機器進行加入的動作。而後半部份會把node21刪掉,並經multipass用一個全新的guest os重起,重新加入到。 在全關的情況下,只要正常啟動三台manager,它們都可以繼續運行。 這個測試的例子表明,即使原本作為依賴的機器死了,只要群齊中其餘多數manager仍然存在,它們也是可以復活的。更重要的是,即使最初引領一切的node21死掉了,什至是被刪掉重來,也是相安無事的。 結論 更新時,最保守的做法,是先加入新的manager,再除去舊有的manager。但這個做法下,manager的IP就不可避免地被改變。若然DNS或者防火牆沒有相應的自動化幫忙,先加入再替換就變得很痛苦了。 而上述的測試,其實代表了我們可以先暫停或移除舊有的manager,更新完後再接回去,這樣部份IP就可以重用。我們只要維持多於原本半數的manager活著,然後逐一替換或升級原有的機器,也不會有問題。即使在升級途中,其他manager不幸地斷線,重啟後它們還是有條件自行修復。我們也不需要顧及更新順序,只需想好Virtual IP的分配策略就足夠,其餘就像是單機升級一樣。

Spring Boot 08 - 多情境設置 maven profile 與 application.properties
科技新知
MacauYeah・2025-02-25

為何要有不同的建構 Profile Profile這一字,很難在IT技術文章中翻譯,它在Spring boot中的語意大概就是一個設定一個固定的運行環境參數合。例如我們做開發時,有些只想在開發環境中出現的設定,諸如測試用的資料庫、細緻一點的LOG層級,都寫在dev profile中。當換成正式環境時,我們也有一套全新的配置,而且會集中寫在prod profile中。把這些參數設定從程式碼邏輯中抽離,可以讓你的程式碼簡潔很多,也方便對比不同環境的設定。 application.properties Spring Boot (Spring Boot Starter) 就提供了 Profile 管理。我們可以為一個Spring Boot 模組設定多個不同的 application.properties src/main/resources/application.properties 為預設 (default profile) src/main/resources/application-uat.properties 為驗收環境專用 src/main/resources/application-prod.properties 為投產環境專用 src/main/resources/application-test.properties 為自動測試專用 在執行程式時,我們只要動改變啟動的參數spring.profiles.active,例如 mvn spring-boot:run -Dspring-boot.run.arguments="--spring.profiles.active=uat" # or mvn package && java -jar target/YOUR_JAR_NAME --spring.profiles.active=uat Spring Boot 就會指定載入 application-uat.properties 的內容,如果有些值沒有定義,它會再追溯到預設的 application.properties中。 在運行中改變啟動參數的情況可能不多,筆者更常用的情況是在編譯期間產生多個 Jar 檔,不同 Jar 檔指定不同的環境,方便系統管理員取用測試。想做到這個效果,我們需要在 application.properties 中,我們還需要加入一句spring.profiles.active=@active.profile@,並在編譯工具中加入這個變量,例如筆者常用的 maven pom.xml 中,就會有這一串設定 它在 maven clean compile package 時,就已經可以在JAR中填入固定spring.profiles.active。那麼每次執行時,都會是指定的profile。 mvn package -Puat java -jar target/YOUR_JAR_NAME 在這個例子中,JAR 中的 spring.profiles.active 就會固定是uat,我們不需要在啟動參數中加入字眼。 如果大家不會碰到混合Profile的話,其實上述的資訊已經足夠大家應付很多情境。 但當大家有追求,需要寫自動測試,有機會不同自動測試需要啟用不同的 Profile ,更有可能出現混合Profile的情況,這件事就變得很複雜。我們需要繼續深入了解一下 Spring Boot 的覆蓋機制,下面將會以測試方式導出結論。 如果真的對混合 Profile 沒有太多信心,我們也可以用單一 Profile 重組不同 properties 的方式,自行去模擬混合 Profile ,例如除了dev, uat, test之外,我們可以加入 dev-test, uat-test, default-test 作為驅分。這樣應該可以簡化測試的複雜度,不過 properties 檔案就可能會成幾何級成長。 但在某情特殊情況下,我們不可能簡單地重組 properties 等型式去做測試,例如針對部份uat-test的測試,只有部份可以執行,部份不可以,那麼我們還是需要用到混合 Profile ,限定某些測試需要執個某個 profile ,但其餘部份可以動態切換。 有條件的讀者,也可以先行試玩一下混合 profile 的特性,下期筆者再為不同情況作解紹。 混合Profile Source code spring boot profile

Spring Data Jpa 自動化的選擇 - Code First
科技新知
MacauYeah・2025-01-22

Code First vs Database First 在早期SQL資料庫盛行的年代,在設計要使用資料庫儲存資料時,很經常遇到一個策略選擇的問題*Code First* vs *Database First* 這兩個策略的差異可能越來越講不清,筆者也找了一些現時網路上的講法。 Code First: 先從寫程式的角度出發,設計數據模型,再使用工具把你程式碼中的數據模型類(Class),生成一個對應用SQL資料庫的表(Table),自動編做好對應的數據結構(Schema)。這樣你在設計時,以程式設計為主導,方便熟悉程式的人使用。這常見於第一手開發設計,因為資料都是第一次收集和儲存,考慮收集程式的運作最為實際。 Database First: 先從SQL資料庫的儲存、取用資料的方式出發,先用SQL成生Table及Schema,再轉變成為程式碼中的數據模型。這樣的資料庫在日後作分析用途時,比較簡單易懂,方便使用熟悉SQL的人去使用。這也常見於二次開發程式,因為這樣可以確保不會錯誤地破壞原有資料庫。 那麼筆者為何講這兩個差異越來越講不清?那是因為現在的資料庫不能單純地只考慮初次或二次開發問題,而是需要考慮多個系統協調運行的問題。 多系統共享協定 - Database First 因為隨著資料系統發展,有些資料會作為數據源出現或用作共享媒界,如果一定要對設計策略作分類,在多系統協調運作下,這些應該叫使Database First。不論它們是SQL還是NoSQL資料庫,我們的程式碼都要為這個預先定義好的數據結構作出妥協。不論使用工具,還是人為分析,都要把共享的數據結構轉換成自己程式中的數據模型。 即使不是多系統協調運作,有時候因為要移植系統,但同時又要令兩個系統版本相容。新系統也是被逼使用Database First的方式設計。 自動化考量 - Code First 前述我們講到,很多時候我們也是從Database First的方式思考。不過筆者就這個Database First,也弄到滿身傷痕。 首先,拋開工具轉換的誤差,我們人為的把共享數據轉化為數據模型,共享數據有時會有一些先天的缺陷,例如: 資料沒有設計Primay Key (主鍵,唯一鍵)、日期時間的定義不明確等。面對一些意義不明的數據來源,要整合確實很要命。而且二次開發中,不可能100%重用原有的資料庫結構,很多時都會加入新的欄位或更多表格去計數。一旦加入新欄位,在團隊多人開發中,那麼使用唯一的共享開發環境,就變很易有程式碼上的衝突。 若需要多人開發,各人有一個Code First的開發用資料庫,是很必要的。這也可以在系統正式升級前,對比開發中資料庫及舊資料庫的結構,觀看它們之間的差異,評估升級的風險。 也許Code First並不是重點,重點是可以隨時建立一個測試用的資料庫,這才方便合作開發。自動化的地方,不單只限於數據結構,範例資料也該是如此。如果有維繫一個初始範例資料,可以在有需要時自動生成,對於多變的環境一定有很幫助。 現時,筆者基本上都會人為檢視資料庫,人工對照編寫程式中的資料結構(即是人工的Database First),並確保那時程式再次經自動化生成的測試用資料庫,並沒有失真(即是Code First)。至於範例資料,初期筆者也只使用SQL生成,但後期因為資料結構開始複雜,筆者也暫暫使用程式碼生成,雖然工作量會多了,但對於資料庫升級、品牌更換,這是很有效的手段,程式碼升級測試也更順暢,絕比SQL生成更易維護。 Ref - Code First vs Database First https://builtin.com/articles/code-first-vs-database-first-approach

重入膠坑
手機‧電玩
MacauYeah・2024-10-21

上期講到,筆者因為機緣之下,認識到賢者模型工作室,也很感謝他們幫忙修復了筆者那斷椿的模型(斷樁是膠老永遠都要面對的難題) 不知道大家看了筆者的爛尾舊模之後,有沒有也心動想把自己的舊模拿出來再繼前緣?概然有這個麼好的地方,有人指路,何不帶著大家的模型或問題,去賢者問一問。筆者就在最近一個月,就乾脆一口氣做一隻新模,翻新一隻舊模。 筆者也來分享一下最近的素組+補色的制作心得 剪鉗 - 新模 如果大家有機會做新模,看大家有沒有打磨的需求。打磨是很花時間的,但成品通過打磨後,即使不上色,只噴保護漆,已經超級美觀的。但時間成本也真的很高。 為什麼明明標題講剪鉗,但開篇卻在講打磨。因為第一步把模型從流道剪下來的那一刻,就間接地影響了日後能不能打磨。也根據大家要求的打磨完美度,去決定剪鉗要買多貴。 不論大家想不想打磨,但買一把實用的剪鉗,不要在剪下來取件的一刻令水口位花了,是很重要的。雖然有時留了位置打磨,但若水口花了,有時還是會傷到零件本身,不論表面怎樣打磨,都救不了。那時不是使用補土,就是要打磨到缺肉。家裏環境不方便上色的話,補土的做法就不適合了,還是好好地選剪鉗吧。 完全不打磨,可以買薄刃單刃剪。薄刃單刃剪可以極大地讓水口切割平整,又讓水口細小,之後不想打磨,也不會大刺刺地看到。筆者有試過這個方案,筆者還有一些更奇妙的想法:一開始開心剪,先素組/假組再說,後期有機會再打磨。但這個不是賢者老闆的推薦方案,而筆者慢慢地也發現了一些問題,果然不聽老人言,吃虧在眼前。我們有機會實際操作再詳述。 進行打磨,可以買田宮的雙刃剪,雙刃剪也有薄刃的,但鋒利程度不單刃。賢者老闆比較推這款,因為價格宜人,也耐用。不過筆者都有聽一些其他朋友的建議,一把粗剪,一把薄刃,這樣薄刃剪比較耐用。因為薄刃剪不論多便宜,也要 MOP 200起跳。但壞處就是時間成本越來越多,所以到頭來,可能賢者老闆推薦的田宮的雙刃剪 + 自行打磨,才是長久的做法。 打磨 - 新舊模 若果大家選擇打磨的話,就需要不同號數的砂紙。筆者就直接買了老闆推薦的海棉砂紙套裝:400, 600, 1000, 1500, 3000。省心,好用。 不過對於有需求的朋友,可能要另外再散買800和1200號。另外400,600號,也要加構砂紙+打磨板的版本。因為400,600號切削力強,不分情況全用海棉的話,很易磨到出現曲面。800和1200則作為600、1000、1500之間的過渡。有時太粗心,部份地方沒有足夠用1000打磨,噴保護漆後,還是會有明顯的傷痕。 手塗補色 - 新舊模 不論大家有多痛恨Bandai的貼色,筆者都不建議大面積手塗補色。因為市面上手塗的marker筆,多為水性塗,附著力本來就低,沒有底色補土的情況下,水性塗很易刮塗。筆者之前不知道,刮了又塗,塗了又刮,惡夢。經向賢者請教之後,才放棄這一方向。 而中、細型面積的補色,軟頭的Marker補色筆,實在太好用。除了白色這類遮蓋力不強的顏色,其他遮蓋力強的顏色,例如藍色、紅色,在補土加成之下,筆者塗得很滿意,不過刮漆還是會有。

發佈Docker Swarm App的選擇 - CI/CD系統的參與
科技新知
MacauYeah・2023-08-25

一段時間前,筆者就討論了一些Docker打包的程式的文章,也討論了一些Docker Cluster環境下的選擇。現在也是時候,可以分享一些對於發佈環境的可選空間。 CI/CD系統 CI/CD 全稱是continuous integration (CI) 和 continuous delivery (CD),字面上代表的持續地集成和發佈,實體上就是某台伺服器自動發佈APP。因為使用到Docker Cluster,不論前述什麼選擇 (前文連結 請點這裏),都會有多個node(節點)的出現。要發佈App,總不能一個個node逐個登入設定。所以我們需要一些CI/CD工具,把這個過程都自動化。 在筆者的認知上,CI/CD系統,由兩個部份組成,一個是取得Source Code(程式原始碼)的過程,一個是編譯或發佈Source Code的過程。Gitlab,Github,BitBucket等大型的代碼庫供應商,它們天生為了保存Source Code而提供服務的。不少CI/CD系統都可以跟它們整合,它們提供了存取Source Code的部份,剩下你只要能提供編譯或發佈的伺服器就好。 如果作為小型開發團隊,很少會有意願去自己花錢養一個編譯或發佈的伺服器。(極端地,如果我就是一人團隊,我用自己電腦編譯和發佈就好,伺服器能做的,我自己也能做。)好消息的是,Github提供了一個叫Github Action的CI/CD系統,即使你沒有自己的編譯專用的伺服器,Github Action也可以用Docker Image,提供一個臨時的編譯程序,用完就刪掉。詳細功能還請各位先查看官方教學,筆者也暫時只能零星使用經驗,無法給出有意思的架構。 如果對智慧財產權有高度重視,Source Code不能存放在公開的伺服器,那麼Gitlab Enterprise Edtion則是一個好選擇。運用Gitlab ee,你可以用自己的機器,造一個純本地的庫存伺服器。更強的是,它內建也有CI/CD系統,只要你有間置的伺服器,就可以作為編譯使用。筆者也是從這個方向著手,架設了自己的Gitlab Runner(Gitlab CI/CD系統)。在這裏,就分享一下與Docker Swarm整理的概念。 對於前述兩種選擇,GitLab Runner都可以做得到 底層程式打包成Image並運行在Swarm mode上,每次發佈的是App Binary(執行檔或核心檔案)。 把App直接打包成Image,並運行在Swarm mode上,每次發佈的是App Image。 CI/CD - 打包底層程式成為Image 在這個選擇下,其實就跟傳統自動化發佈的做法類似,只是發佈時,要多個node報行更新指令。如果你使用的底層程式原本就有支援多版本並行,這樣更新時就不用太操心rollback(回滾?)等操作。若系統不支援多版本並行,為求簡化,若遇到要rollback的情況,重跑過去舊的CI/CD操作也是一個做法。當然,我們也可以經過一些備份的操作,來保存被代替的程式,若在發佈過程中出問題,也可以手動重來,不過整件事就越來越複雜。 筆者發佈的基本思路是 使用docker image,編譯和打包App Binary。 使docker image做編譯的好處是,你可以比較放心地假設每次編譯時,你的編譯環境都是乾淨的。 傳送上述的結果至生產環境可以取用的地方。 跳入生產環境執行更新指令 這裏有些隱藏的管理成本,如果你生產環境中有多個node,最後那幾行指令就要多抄幾次。 CI/CD - 打包App成為Image 在這個選擇下,對比傳統自動化發佈的做法,現在要多做一步,就是要包裝自己的Image。不過好處是docker swarm有提供監測工具,在發佈過程每個分身會逐個更新,前一個分身更新成功後才會到下一個分身更新。而且 rollback等的操作,你可以靠docker做到。即是要手動rollback,也可以透過更正docker tags來達到,所以整體上來說沒有比傳統的麻煩。 筆者發佈的基本思路是 編譯App Binary。 打包成docker image。 經docker上傳image。 跳入生產環境執行更新指令。 對比傳統自動化發佈的做法,最後的更新指令,只要執行一次就可以。當然,原本在Docker Swarm中要管理的事還是要好好管理。 CI/CD - 備註事項 雖然CI/CD可以幫忙簡化更新的過程,但實際操作會比上述的例子複雜一些。因為通常對非技術型的外界用戶來說,一個Web App會包含很多不同的功能。上述的例仔,在實際情況下可能需要拆解成很多微服務來進行。所以對管理上還是有相當的挑戰。

【在家系列】在家工作很容易!你不可不知道的Google辦公室工具介紹
手機‧電玩
Lifemagtechie・2020-02-11

現代社會講究工作高效化,利用網絡資源除了更加便利之外,合適的運用不同工具更可以令工作提高效能!作為網絡巨頭Google就創作了不少工具,無論在辦公室還是在家工作,都非常適合使用。 日常工作類: Google Docs 包含了辦公室基本軟件的Word, Excel和Slide堪稱”辦公室三寶”,基本上可以處理日常文書,結算和簡報設計。除此之外,Google Doc還可以同時支持多人共同編輯、不同帳戶評論建議、開放權限及指定用戶查看、系統自動儲存所有變更及查看舊版本。而且更有非常多的外掛功能安裝使用,像圖片編輯或是翻譯的功能,滿足一切編輯所需。Google文件更可以和Microsoft完美轉換檔案格式,非常便利! 了解更多:https://www.google.com/docs/about/ Google Drive 只要你是Google用戶,即可擁有15 GB 的免費儲存空間。而Google Drive更可以安全存放任何煩型的文件,方便用戶可以輕鬆存取所有內容,同時也可以邀請其他用戶共同編輯或開放部份資料夾共同享用。Google Drive更可以選取過去30日內的檔案,即使誤刪或恢愎舊版本的檔易都很簡單。 了解更多:https://www.google.com/intl/zh-TW_ALL/drive/using-drive/ Gmail Gmail是一個非常專業的電子郵件服務,除了可以快速收查郵件及收取大量郵件外,更有精準的搜索功能能快速找到關鍵字郵件,同時更可以設定不同標簽分類郵件以及按等級排序,多種強大的功能令不少人熱愛! 了解更多:https://gsuite.google.com/intl/zh-TW/products/gmail/ 工作規劃類: Google Calendar Google日曆除了可以輕鬆記錄自己個人日程外,更加是工作團隊中必不可少的工具。它可以設立不同的日曆並給指定用戶分享,工作時可以輕鬆安排會議時間或員工放假安排,也可以選擇建立活動並加入活動詳情。而且支持電腦及手機同步,令你隨時掌握每一天的行程。 了解更多:https://gsuite.google.com/intl/zh-TW/products/calendar/ Google Keep Google Keep是一個記事和清單的功能,乍看下去它就像一個便利貼一樣,而且使用上也如外表一般簡單易操作。它可以作為臨時筆記使用,並可以隨意移動清單到想要的位置中,更可以設立不同的顏色代表不同的分類,視覺上更易分辨。除此之外,它更可以建立清單樣式,方便勾選已完成的工作,更可以設置時間和地點功能,更有"提醒"的服務通知,也可以與他人共用,令工作變得更井井有條。 了解更多:https://gsuite.google.com/intl/zh-TW/products/keep/ Hangouts Meet Hangouts Meet是Google新推出的視像會議功能,最有特色的功能是受邀請的成員不需要安裝任何軟件,只要點擊連結就可以加入會議,更能容納最多25人同時加入,如前文所述在Google日曆中可以建立活動開會,這邊也可以同步到日曆上並邀請用戶加入Hangouts Meet 會議。此外,會議中用戶更可以分享螢幕畫面,方便開會時使用簡報或展示文件,非常方便! 了解更多:https://gsuite.google.com/intl/zh-TW/products/hangouts-meet-hardware/ Google提供的功能非常多樣,基本可以滿足日常及工作所需,強大及便利的功能符合工作的期望。大部分的功能適用不同裝置,無論是電腦還是手機都可以保持同步,而且更可多人共同協作及修改,既節省時間也可以有效運用提升工作效率,發揮最佳的能力! 作者:Dororo

為攝影而生的手機:HUAWEI P9 Plus X Leica 完美結合
手機‧電玩
Cheers!・2016-08-30

小編身為一個偽文青,除了平時一書在手之外,一部神之手機真的少不得。而且小編平日也喜歡 Selfie,最喜歡孭著「微單反」去旅行。但當發現相機裝備重,購物令行李越多,就會想一部手機走天涯。但要相片質素高,又想機身輕巧就更難。而小編最近就留意到上架沒多久的華為 P9 Plus 手機,正正可以滿足到小編的要求。 HUAWEI P9 Plus 色彩飽和度達 108%,對比度達 1:1.8M,畫面極致,備有金、灰兩色選擇。(圖片來自 : http://consumer.huawei.com/) 神之 Leica 鏡 無與倫比 每當假期旺季,被朋友的旅行Selfie及風景相,在面書瘋狂洗版,都令小編都好羨慕。剛好見到華為X Leica 推出了夢幻手機,令小編想即時入手,帶埋手機去影出更高層次的旅行照。何解?因為這部手機具備 Leica雙鏡頭,當影相時兩個鏡頭會同時 operate;彩色鏡頭負責捕捉顏色,飽滿色彩;黑白鏡頭負責捕捉景物細緻,令影像更清晰。合成後的相片清晰度、對比度更極致,更有層次感。要在草地上拍出韓風小清新照片,要文青的浪漫的都無難度啦! 自動對焦 自拍出色 文青自拍講求相片氛圍,影出仙氣來。正所謂「你的樣子如何,你的日子也必如何。」影到一張有氣質的Selfie 相,勝過千言萬語。而華為 P9 Plus 具備F/1.9 大光圈、800 像素自動對焦前置鏡頭,無論是手持或使用自拍桿 Selfie,甚至於低光環境下,都可以自動對焦,捕捉最清晰、最moody的面容。有靚靚照片,followers 自然多到要排隊啦!另外,手機也支援國內 3G/4G 網絡,如果去開中港旅行,要即時 share 靚相,只要以這部手機 join 埋 CTM 「中港澳連城計劃」,就可以隨時隨地去到邊、影到邊,即時同朋友開心「些牙」。 一手輕易操作 細節一目了然 想單手拎著咖啡享受 C’est la vie,又想同時上網,這部可單手輕易操作的 HUAWEI P9 Plus 便是不二之選。5.5 吋全高清 AMOLED 屏幕配備超窄邊框,單手就可以輕易操控,手感更實在,視覺更震撼。影完張 IG profile picture,以 user friendly的Press Touch設計,單指按壓便可即時預覽相片及放大相片局部欣賞,每個細節都一目了然,非常方便,甚至當鏡用都得啦! (圖片來自 : http://consumer.huawei.com/) 強大電量 Chill 梳乎之選 想摺埋自己,舒舒服服 Chill下,享受一部好戲,就可利用這手機配備的 3,400mAh 高電量電池,再配合 CTM 4G+ 計劃,就可以連續 14 小時享受高清影片、9 小時 4G 上網。要即時入手,體驗至 chill 的華為 P9 Plus,就要捉緊 CTM 最新的上台優惠。4G+ 上台價更低至 $0及免按金,而CTM「尊壹會」會員更可以淨機優惠 $4,480(原價$5,040)購買。 機邊及機背均是採用金屬物料製造,手感好又有型,最襯至 chill 文青。(圖片來自 : http://consumer.huawei.com/) HUAWEI P9 Plus 規格: 屏幕:5.5 吋全高清 AMOLED 壓力感應屏幕,1,920 x 1,080, 401ppi 平台:Android 6.0(Marshmallow)+ HUAWEI EMUI 4.1 鏡頭像素:Leica Summarit 系列 1,200 萬像素雙主鏡頭(彩色+黑白)/800 萬像素 BSI 前置自動對焦鏡頭 尺寸/重量:152.3 x 75.3 x 6.98 毫米,約 162 克 顏色:金、灰色

Projection Oscillator判斷重拾升勢的股票
創富坊
程式交易 www.quants.hk (導師: 財經書藉作家: 麥振威)・2015-05-20

收到有學員問,Amibroker是否有Projection Oscillator這個指標? 這個是炒外匯的常用的指標,Amibroker的內置指標中是沒有的,不過已強調過任何指標也可以自己寫出來,而且並不困難。 1)開啟formula editor (按圖可放大) 2)將以下copy到formula editor n = Param(“Periods",12,5,50,1);av = Param(“Average",5,2,20,1); n = Optimize(“Periods",n,5,50,1);av = Optimize(“Average",av,2,20,1); function ProjOsc(n) { // Slope of High {n period regression line of High)}SlopeHigh = ((n * (Sum( Cum(1) * High, n))) – (Sum( Cum(1),n) * (Sum(High, n)))) / ((n * Sum( Cum(1) ^ 2 , n)) – (Sum(Cum(1),n) ^2)); //Slope of Low {n period regression line of Low}SlopeLow = ((n * (Sum( Cum(1) * Low, n))) – (Sum( Cum(1), n) * (Sum(Low, n)))) / ((n * Sum( Cum(1)^ 2, n)) – ( Sum(Cum(1),n) ^2)); //Upper Projection BandUpProjBand = 0;for (i=0; i<n-1; i++){UpProjBand =Max(Max(Ref(High,-i)+i*slopehigh,Ref(High,-i-1)+(i+1)*slopehigh),UpProjBand);} //Lower Projection BandLoProjBand = 10000;for (i=0; i<n-1; i++){LoProjBand =Min(Min(Ref(Low,-i)+i*slopelow,Ref(Low,-i-1)+(i+1)*slopelow),LoProjBand);} //Projection OscillatorProOsc = 100 * (Close – LoProjBand) / (UpProjBand – LoProjBand); return ProOsc; }aa= ProjOsc(n);bb= MA(ProjOsc(n),av); Plot(aa,"Projection Osc",colorblack,styleLine);Plot(bb,"MA ProjOsc",colorgreen,styleLine); 3) 儲存在custom的file 4) right click 指標按insert 便能將指標放在圖表上分析 Projection Oscillator由Dr. Mel Widner研創,與其他不同的指標一樣,傳統的用法也是超買/超賣,背馳,突破等,不少人利用此指標來交易外匯。傳統的參數是12及5,但若應用在港股上,將參數設定為50及10會更好。分析股票時,初步看,每當由50以下重回至50以上有機會是股價重拾升勢的時間,值得留意,不過有關的方法仍有待詳細測試。 不過還是那一句,多一個指標作參考及分析箇然是好,但世上沒有無敵指標的,並非用了那個指標進行程式交易便能必勝,要明白指標的原理及優點,將其融入你個人的交易策略做分析,看看是否能提高回報,這才是正確的做法!

AMIBROKER速成教學 從網上免費下載港股數據
創富坊
程式交易 www.quants.hk (導師: 財經書藉作家: 麥振威)・2015-03-25

Amibroker是可以每天自行將股票的數據下載至程式中使用及分析,而且完全免費的。 匯入數據到AmiBroker的方法有很多,以下3個方法則最為簡單易用。 使用AmiQuote 使用Import wizard Interactive Broker plugin 使用AmiQuote AmiQuote是一隻可以從各大data網站包括Yahoo, Google, MSN 下載盤後數據的軟體,並且能與AmiBroker整合,下載的數據馬上就可以在AmiBroker的圖表分析視窗顯示。 1.開啟記事本 2.每一行打上你想做研究並下載historical data的股票代號(請注意,以香港股票為例,代號開頭以四位數字組成,後加.HK,詳細股票代號請參閱Yahoo 財經) 3.完成後按檔案->另存新檔,存檔類型揀選所有檔案,存檔路徑請選揀選AmiQuote安裝的folder,例如 C:\Program Files (x86)\AmiBroker\AmiQuote,並輸入新檔案名稱(例如HSIcomponents.tls),檔案名稱必須以.tls結 尾,最後按存檔。 4.開啟AmiBroker→ File → New → Database,以開啟一個新的資料庫。 5.開一個新的Database 資料夾,如C:\Program Files (x86)\AmiBroker\AmiQuoteExample,然後按Create,再按OK。 6.Tools → Auto-update quotes (AmiQuote) 7.按停止制 (因為AmiQuote預設自動下載某些美國股票的historical data) 8.按File→Open,搜尋位置請揀選剛儲存檔案的位置,然後揀選該檔案,再按開啟。 9.Source請揀選Yahoo Historical,並揀選你想download 那一段時期的Historical Data,例如由1/1/2007至3/8/2013,再按綠色三角形制開始下載。 10.完成後按右上角關閉制離開AmiQuote的頁面,你會在Symbol的視窗看到你下載的Symbol資料。 11.Double Click其中一個Symbol,你便會看到該Symbol的價格及成交資料。

【匈牙利。布達佩斯】※景點※ Mátyás Templom 加冕教堂 (馬加什教堂 / 馬提亞斯教堂)
走遍世界
80後愛旅行✈️・2021-08-26

今天一下飛機後就坐車去加冕教堂(馬加什教堂)和漁夫堡, 第一次踏足布達佩斯, 在車上一直拍著沿途風光 這是鏈橋, 是一座橫跨多瑙河連接布達和佩斯的古橋。 終於要到達整個行程的第一個景點 - 加冕教堂 (馬加什教堂) 和 漁夫堡(漁人堡) 馬加什教堂又名加冕教堂是因為歷代的匈牙利國王都在這裡進行加冕, 所以又稱為加冕教堂。 加冕教堂 (馬加什教堂 / 馬提亞斯教堂)位於布達城堡區的心臟, 就緊緊的相鄰著漁夫堡(漁人堡), 這兩個景點一般都會一起遊覽的~ 下車後直直的走過一條街道, 就會看到加冕教堂 (馬加什教堂 / 馬提亞斯教堂) 第一天來到布達佩斯天氣真的很好!! 街道的兩旁都有很多賣特色紀念品的店~ 要看到加冕教堂(馬加什教堂 / 馬提亞斯教堂)了~ 高高的塔尖讓整間教堂看起來更加宏偉! 在加冕教堂 (馬加什教堂 / 馬提亞斯教堂)旁邊的是聖三一廣場, 廣場中間的柱子是聖父聖子聖神三為一體的聖三一。 柱子上凡雕刻非常精緻。 加冕教堂 (馬加什教堂 / 馬提亞斯教堂)的塔尖非常高, 好不容易才拍到整間教堂呢 走到加冕教堂 (馬加什教堂 / 馬提亞斯教堂)前地, 有一個教堂範圍的模型。 加冕教堂 (馬加什教堂 / 馬提亞斯教堂)是採用歌德式建築, 外牆所有的雕刻都非常精美! 根本就是一件藝術品!! 走到加冕教堂 (馬加什教堂 / 馬提亞斯教堂)旁邊, 歌德式的建築物就連門框上的雕刻都弄得這麼美 教堂的側面建築 在教堂的旁邊、漁夫堡前面有一個騎著馬的雕像, 他就是匈牙利的立國君主史蒂芬國王。 在聖史蒂芬像後面的就是漁夫堡(漁人堡), 這兩個景點真的緊緊相連的。 Mátyás Templom 加冕教堂 (馬加什教堂 / 馬提亞斯教堂) Mátyás Templom 加冕教堂 (馬加什教堂 / 馬提亞斯教堂): Budapest, Szentháromság tér 2, 1014 匈牙利 http://www.matyas-templom.hu/ 檢視較大的地圖

藥物不同於食物,讓食物成為藥物
其他
皓芯・2022-07-01

在日常生活中,進食不僅意味着為身體補充營養,身為消費者的我們,進食行為還會對經濟、自然環境等產生重要的影響。 近年來,越來越多的人為了健康選擇植物性飲食,是因為有大量科學研究認證,植物性飲食更有利於健康。但同時人們對素食仍存在很多疑惑,如長期素食會否導致蛋白質、鈣等營養素的缺乏,會否因缺鐵而患上貧血症等。 本書作者徐嘉博士,美國責任醫師協會(PCRM)營養學專家,美國約翰․霍普金斯大學醫學院生理學博士。2012年起通過微博,開始了在中國傳播植物性飲食的好處,積極推廣「21天健康挑戰」;自2014年起,健康公益講座足跡遍及中國、香港、台灣、新加坡、馬來西亞、和美國等全球超過150個城市900多場,影響了數百萬人;2017年底,徐嘉博士在公眾號上開始健康飲食傳播之路。 本書將嚴謹的營養學理論,引用了各種科學圖表及研究數據,講結合大量真實案例,讓我們了解適合以食“蔬、果、豆、谷”為主的健康飲食(素食)基本原則,及各種常見疑問。純素(Vegan)植物性飲食者、孕婦、兒童、長者、運動員、環保及宗教人士等各類人群,都能從書中找到適合自己的飲食建議。 本書圖文並茂,分析植物性與動物性食物提供的營養,是一本受眾很廣、可以解答關於健康飲食90%的問題的科普書。作者在書末補充了參考文獻二維碼,掃描後可以看到書中部分文章的具體引文。 日益豐富的物質生活,也被日益增長的健康問題困擾。病從口入,控制飲食就是控制疾病,食物是我們每天要吃的。葷素搭配是大家的首選,書中介紹了健康素食與各種疾病的關係,素食雖不能治療任何疾病,素食只是停止了一切肉蛋奶我們的傷害。 大家在感嘆生活發生翻天覆地變化的同時,新冠肺炎疫情讓人們更深入認識到免疫力的重要作用。免疫力與健康關係密切,讓我們從自己做起,人人享有健康生活,希望大家都身體健康。 《非藥而愈:一場席捲全球的餐桌革命》(簡體字書) 作者: 徐嘉 著 出版社: 江西科学技术出版社 出版日期:2018-12-01 ISBN: 9787539065243 訂購地點: 一書齋 圖片來源:博客來

營養師教你享「瘦」新美食 -- 糕篇
生活在我城
My nutridiary・2020-01-19

每逢新年都會出現很多賀年食品,例如年糕,寓意步步高昇;瓜子,寓意搲銀;也會在家中擺放全盒,寓意十全十美。 美食當前,正在進行體重控制的你,在新年期間點先可以享「瘦」美食?記住營養師給你的小貼士啦! 每款糕點以1件50克 (約1副撲克牌大小) 計算,以煎年糕的熱量最高,2件約等於1碗飯的熱量。 以糖份來比較,馬蹄糕及年糕在製作過來中會加入砂糖或片糖,因此糖份較高,每件約含2粒方糖的量。 芋頭糕及蘿蔔糕在製作過程中雖然沒有加糖,但會加入蝦米,蠟肉等而使其含鈉量高,每件的含鈉量約佔每日建議量的13%。 營養師教你進食小貼士: 建議食用前先了解其換算量。糕點屬於五穀類,因此,食用時,應以其取代米飯,麵條等主食,即以一件蘿蔔取代1/4碗白飯的量。糕點的建議每次食用量為兩件。 以蒸代替煎,減少油脂及熱量攝取。如真的想有香口的味道,可改用易潔鑊煎煮,減少用油量。 可以自製糕點。如製作蘿蔔糕時,以冬菇,乾瑤柱等少鈉味鮮的食材代替蝦米,蠟肉等高鈉食材,減少糕點的含鈉量。 因應自己的自身情況選擇合適的糕點。馬蹄糕及年糕含有大量砂糖,且年糕用糯米粉製作而成,升糖指數高,關注血糖的人士需注意;芋頭糕及蘿蔔糕含鈉量高,關注血壓的人士需注意攝取量,并可在其他食物的烹調上減少用鹽;至於體重控制人士,建議選擇用蒸的烹調方式煮食,并留意糕點的換算量,以逹到更好的熱量控制。 更多資訊請讚好FB專頁: https://www.facebook.com/mynutrinotes

大笑姑婆的誕生
其他
活該快樂 // Carmen Lo・2018-03-23

我那經常口痕的先生,三不五時就說些無聊的笑話。當我笑到快要斷氣,忙著擦眼淚的時候,他就會反著白眼說:「這個如此old school的笑話,有必要笑成這樣嗎?」 其實,小時候的我,是一個嚴重古肅、不愛笑的孩子,非常斯文,一副典型文靜好學生的樣子,不會說笑,也不會笑。 看到其他小孩子在玩得瘋,我只會站在一旁看,就算看到好笑的事情,我也只會抿著嘴微笑。而且為了保持我一身乾淨的、媽媽親手造的衣裙,我從不跟他們一起坐在地上玩。親戚們常誇言說,每次家庭聚會,離開的時候,所有小朋友都玩得瘋了,頭髮亂、衣服髒,唯有我走時跟來時沒兩樣,還是一個小公主(他們通常都會附加一句:可惜樣子長得不漂亮。)。 你不能想像面前這個經常笑得不可收拾、忽然就大剌剌地坐在地上、山頭和車站到處睡得香甜、常常弄得滿手滿屁股泥巴的我,小時候竟然是這樣子的! 第一次發現笑的重要,是我念小學的時候,一天媽媽接我放學,不經意地對我說:「啊!走在前面的不是XXX嗎?嗯,她人長得不比你漂亮,但X校長、X主任都疼她,因為她愛笑,她的笑容很好看。」XXX是我的同班女同學,話說當時我在班上每次都考第一(講這個要大聲一點!),而她每次都屈居第二或第三。可是,老師們並不因為我成績較好而較疼我,反而與XXX老友一點,會送小禮物給她、借她圖書、請她喝汽水。 是這個原因嗎? 這句話,我到數十年後的今天還記得那麼清楚,可想而知我當時是多麼的介意,而且反覆深思了多少次。 現在想起來,原來當時年紀小小的我,已經有「人生在我手」的潛在信念。我開始嘗試多咧開嘴巴,經常提醒自己要多擺出笑臉。 一開始是不服輸的心態:「哼!我也可以得到老師的歡心!」 後來,因為在意地改變表情,不經意地連性格也改變了,不知道甚麼時候開始,我變成了一個愛笑的人,也變得越來越開心,有甚麼沒甚麼、新奇的、有趣的、搞笑的、搞事的、無奈的、無賴的、累的、怪的,反正甚麼都好,不知道應該說甚麼的時候,用笑去表達就沒錯了;而且笑點也調低了,就是同一個笑話,聽了多少次也會捧腹大笑。 到了今天,大概我先生是最大的受益者--他講的笑話,永遠不會乾塘啊!