弦而時習之

用 Redux 跟 GraphQL 玩 Rails 5.1

上週五在處理網址續費的時候,發現幫老爸公司管理的網址已經多到一個程度。所以就決定把手邊可以轉移的服務都往 Gandi 丟過去。畢竟粗略估算可以達到 Grid B 的費率(實際上只有九五折)不過考量到有 API 能夠管理,以及一些自動化的手段,雖然相對還是稍微貴了一點,但是省去後續不少麻煩確實是有利的。

也因為這樣,就打算以串 Gandi 的 API 來練手一下,原本是想做完管理 Domain 的部分,不過沒想到在實作一些技術面上的東西花了不少時間,只做完簡單的價格查詢。

可維護的 CSS

這週的 CSS Weekly 以及幾個前端相關的電子報都提到了叫做 Maintainable CSS 的專案,乍看之下還以為是討論可維護 CSS 專案的文章,沒想到是一種 CSS 框架。

幾年前 Responsive Web Design 和 Single Web Application 開始熱門起來的時候,大家也注意到網站使用的 CSS 逐漸複雜。所以開始有像是 OOCSS、SMACSS、BEM 等等理論出現,綜合來看這些技巧對於維護網站的樣式上都是很有幫助的。

會寫這篇文章是因為 Maintainable CSS 在很多地方上跟我自己使用的方式類似,而我目前採用的則是 SMACSS 跟 BEM 的混合版本,所以就打算來分享一下自己的經驗和技巧。

Afte PHPConf 2016

PHPConf 是退伍後參加的第三個研討會。雖然現在已經沒有什麼在寫 PHP 了,不過寫了好幾年的語言還是會想關注一下最近的狀況。

今年其實沒有聽到很多議程,只聽了三場議程而已。 大部分的時間都用在跟講師聊天,不過另一方面也感受到這幾年很多活動都已經不是以前認識的人去參加。這大概就是對我們這群人來說,一個研討會的內容能帶給我們的東西已經不夠了。

雖然以前會覺得自己還能夠一直參加,不過實際上當研討會分享的東西大多能靠自己學會跟吸收的時候,就沒有那麼重要。有機會的話,去做分享也是繼續參與的一個階段,能力可及的話我也會盡可能多做分享。

在 RubyKaigi 2016 後的新視野

八月份退伍後,馬上就加入了五倍紅寶石。而隨之而來的,剛好是在九月份為期九天的員工旅遊,一個非常充實的員工旅遊。

實際上,我們只有三天左右在日本遊玩。原本的行程會穿插著與日本 Ruby 社群的交流,以及三天的 RubyKaigi 行程。

這次的旅遊算是增長了不少見識,讓我想到高中快畢業時第一次知道了 COSCUP 之後瘋狂地參加各種語言的研討會,幾乎一年每個月都在跑研討會。印象沒錯的話,大概是 2013 年才參與到 RubyConf 也因為參加了 RubyConf 的活動,退伍前後蠻多工作機會都是來自 Ruby 圈的,算是整個程式經歷中給我幫助最多的社群了吧。

使用 GitLab CI 整合 SonarQube

之前都在偷懶沒有寫網誌,剛好這次端午連假比較長。 所以想做測試跟實驗的部分都做完了,就來寫一篇關於 GitLab CI 整合的經驗分享。

文章中大致上會涵蓋這些部分:

  • GitLab CI 基本使用
  • Rancher建置環境
  • SonarQube 基本使用
  • GitLab CI 整合環境

文章會以我在建構 CI 環境的過程中來講解,一些安裝跟配置的部分會直接跳過。

從入伍後讀的一些書

入伍之後一直擔心自己的技術會退步,所以其實有好幾個月的時間都很焦慮。 不過運氣不錯的是,所處的單位算是不錯的,現在的區隊長管理方式也讓我有不少時間可以充分利用。

這邊就簡單介紹一下到目前約八個月多所讀的書,大部分時間都是利用睡前跟午睡時間去讀的,一次大約十到二十分鐘,反而因為軍隊規律的生活變成每天讀書的習慣,意外讀了不少。

Deis 架構分析(二)

延續上一篇的內容,這篇文章要先來討論比較好懂的 Router 部分。

首先,在 Deis 的設計裡面,基本上所有的服務都是包成一個 Image 作為 Continaer 在 CoreOS 運行的。就這點來看,其實是非常符合 Mircoservice 架構的設計。同時我們也可以很輕鬆地將這些服務獨立出來使用,這篇文章討論的 Router 除了原本的用途外,也很適合用來學習透過 etcd 部署自動化更新設定檔的環境。

Deis 的原始碼都放在一起,其中 Router 部分是裡面的一個子目錄,那麼就讓我們開始了解運行的架構吧!

微妙的 Unreal Engine 4 語言偵測機制

最近因為我們團隊將遠古神話上架到 Steam 上面的關係,收到不少歐美玩家表示需要英文語言的支援。 其實這方面也是當初考慮不周的問題,也剛好碰到了國軍的過年年假有比較多的時間可以處理。

原本預期是一天之內就解決這個問題,不過現實上倒是花了不少額外的功夫去處理。 這也是我們使用 Unreal Engine 4 一直以來的問題,雖然承襲了 UDK 眾多強大的功能,但是卻還未完全的成熟。 從約兩到三個月就會改版一次,而且加入大量功能的情況來看,還有許多需要解決的問題。

過去 Epic Games 自己使用也許沒什麼問題,但是當發布成一個工具的時候,就多了非常多細節要處理。

Deis 架構分析(一)

最近隨著 Container 技術的成熟,以及 CoreOS 等工具的出現。開始有一些 PaaS 的工具出現,而 Deis 就是其中一個。

Deis 本身是受到 Heroku 所啟發的開源 PaaS 專案,透過 Deis 可以輕鬆的建構 Heroku-like 的 PaaS 環境,若是有能夠管理伺服器的人員,其實可以考慮以這種方式部屬網站。相對 Heroku 來說,基本的 CoreOS Cluster 只要三台機器,以 Linode 2GB 的方案來看,甚至還比 Heroku 單個 2x dyno 還便宜呢!

關於 Deis 的架構,在官方的文件已經有做出說明,所以這系列的文章著重在閱讀原始碼以及探討關於 Deis 是如何實踐 Heroku-like 的 PaaS 環境。

我本身是 Heroku 的重度使用者,因為透過 git 管理以及豐富的 Addon 在開發時其實是非常方便的。 不過有時候還是會受到一些限制,這時候 Deis 就提供了很大的幫助。不過這類 PaaS 工具其實還不能說非常成熟,使用上還是會有不少問題,透過了解底層的機制來建構一個自己的版本,在某些情境反而更加容易控制跟維護。