Open in app

Sign in

Write

Sign in

葉顆顆
Sudo Ninja
Published in
12 min readMay 9, 2016

--

ocowchun

1. Lambda 設定

使用 Terraform 來綁定 AWS Lambda與 CloudWatch Events 要記得設定 Lambda permission，不然你會看到 Rule 已經將 Lambda 加入 Target 了，可是 Lambda 卻沒有觸發的情況。

ref

2. Automating Our Infrastructure to Empower Engineers

我覺得當公司的規模與服務變大的時候，基礎建設常常是工程師最痛苦的地方，各種不同的環境(dev,staging,production),各式各樣的服務(Security Group,RDS,Route 53,ELB,API Gateway…)，光是用看的就眼花撩亂了，更何況是要確保這些服務按照正確的順序與設定被成功的建立起來，本文敘述了 Segment 如何透過一系列的工具來自動化建置基礎建設與改善開發流程。

Kalan

這個禮拜不談「新」東西，多數會是關於網頁開發的重新思考。算是回過頭來漸漸補齊自己的技術債吧！比起前幾個禮拜所談的新東西，這一篇文章可能相對枯燥一點，當然篇幅也會比較長，但我認為這是必要的。

這些東西在前端變化快速的時代下或許顯得不那麼重要，不過思考總是件好事。

Sexy Pull Request

目前會最常送pull request 的人就是我了吧

為了盡量減少科科不必要的麻煩（雖然目前還是 trouble maker），我最近找了一些有關於 pull request 的注意事項。以及我自己的心得。一個壞的 pull-request，壞的不是 reviewer 的時間，而是技術團隊所有人的時間。

  1. 解釋為什麼要這樣寫而不是這行 code 做了什麼
  2. 給 code reviewer 一個簡單的測試 guide。盡量以不超過 15 分鐘為主。如果超過，代表這個 pull request 的粒度較大。考慮是否要再分為不同的 pull request。(但這有分幾種情況，如果是要做比較複雜或比較大的功能，下面討論。)
  3. 但最重要的事情是盡量不寫爛code。
  4. 把自己想像成 deployer，然後想想自己希望看到怎樣的 pull request

Template

#### 標題：這隻 pull request 做了什麼
#### Test guide
#### 解釋為什麼 code 要這樣寫
#### 附上 trello card 的連結
#### 附上 screenshot
#### 提問題
#### 需要注意的部分

#### 感謝的話加上適當的 emoji

重新思考語義化這件事

會有這個想法，是看到 instant article 的 html 架構，他們規範 instant article 的架構必須符合他們的規範，而且結構的表達也很清楚。我在裡頭看到了好多我以前沒有注意過的 html tag。像是 address figure caption summary 。好奇之下查了一下文件等等。發現其實有很多語義化的標籤都已經支持目前主流的瀏覽器，spec 也寫得很清楚，但是目前主站多還是以 div + class 的方式做表達，雖然有些地方會套用 header，但我認為有更多適合的語義化標籤可以加入使用。除了減少不必要的 class 命名，也能夠提高 html 的易讀性跟 SEO，重點是，我們寫的是符合標準的 html。

而且 w3c 在 html5 致力推廣語義化的標籤，諸如 nav header dd dt 等等，並且將一些沒有意義的 tag 刪除或是不推薦使用如 b font center 等等。

對於 class 的思考

語義化 css

用了那麼久的 class，我回去找了找 spec，發現了 w3c 對 class 的描述。

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. -w3c

雖然 class 並沒有使用上的規定，但是鼓勵盡量將 class 用於表達元素內容而非描述元素的展現。也就是說那些 col-md-* 等表現性的 class 名稱其實在 w3c 的 spec 裡面是不符合規範的。但是會出現 unit class 的原因卻是因為我們沒有按照標準來而孵化出來的產物。雖然很多人擁護 unit class 的便利性跟節省開發的速度，但我認為比起開發上的時間節省，身為網頁開發人員，我們要注重的更應該是頁面的表達跟使用者的互動。

這裡想提出這樣子的想法跟大家討論。

為什麼要符合標準？

  1. 標準規範是由一大堆科學家研究過後、大量的討論過後所制定出來的規範，給大家遵守以便達到統一性。
  2. 通常這些規範是 best practice。
  3. 為什麼我們要為了節省開發時間而寫出不符標準的網頁本末倒置？
  4. 一套完整的標準是推動生態發展的條件
  5. html 更容易讀，而且可以套用在多種設備及分析上

unit class

對 unit class 難道沒有其他辦法解決嗎？我自己非常喜歡語義化的 class，而且很討厭 row col text-center，每次寫起來都會有罪惡感…。

但是 grid system 是個很棒的東西耶！

我承認 grid system 的確是個非常好用的模式，在實際場景也會遇到 layout 無法用語義化來表示的問題，但根據語義化的定義，為了寫出更好看的 HTML 跟易讀性，我們或許總有一天還是要把 grid system 拔掉。這會是個大工程，但在目前主站說大不大，說小不小的架構上，還是越早開始越好吧！目前也有一些我認為還不錯的解法。

  • 使用 susy
  • 搭配 mixin function 使用
@import 'susy';
$susy: (
  container: auto,
  columns: 12
)
.container {
  @include container;
  .content {
    @include span(8);
  }
  .sidebar {
    @include span(4);
  }
}

看看這幾行 code，應該可以很容易知道他的展現為何，而且非常非常乾淨。html 可以這樣寫： html <div class=”container”> <div class=”content”></div> <div class=”sidebar”></div> </div>

SASS

在只能使用 sass 的情況下，我們目前遇到的問題不外乎有：

  1. 沒有統一的規範，變數的命名及存放雜亂
  2. css 的全域變數亂噴，容易被覆蓋
  3. colors 的使用
  4. font 的管理沒有統一的階層。
  5. 單一 class 的大量 rule 造成閱讀困難
  6. 巢狀的 class 與 id 結合，不僅架構難看，而且權重覆蓋的問題無法輕易解決。（層層疊加）

重新思考架構

無可厚非的是網站開發初期，我們往往是要快速的 deliver 產品，而非把 code tune 到好。當你把 code tune 到好通常使用者也已經跑光光了。 但，技術債總是要還的，當架構趨於龐大，就不能再用以前的方式開發，而是要停下來思考，是否有更好的方式解決問題。

沒有統一的規範，變數命名及存放雜亂

css html js 是互通的語言，缺一不可。也就是當前端在開發的時候，必須同時兼顧這三個語言的交互作用。 目前主流的規範方式有 BEM OOMACSS。

這個問題的解法不外乎是將變數統一存放在某個資料夾裡：

/* ./variables/_colors.scss */
/* before */
$main_color
$content_color
$heading_color

/* after */
$colors:(
  main: green,
  content: red,
  highlight: gray,
  heading: white
);

注意到這邊我們使用了 sass 的 map來做管理。而不是只用變數存放而已。

map 有點像是 js 的 object，用 key-value 的方式來存放變數。

這樣做有什麼好處呢？

  • 解決了變數重複命名或多餘的前綴。
  • sass 提供幾個好用的 map function 操作map-get map-has-key
  • 可以用 @each 迴圈操作

所以之後，如果我們需要取用屬性，可以這樣寫：

.content {
  color: map-get(color, content); 
}

當然，我們還可以搭配 sass 的 function 將它包裝起來：

@function get($map, $key) {
  @if map-has-key($map) {
    @return map-get($map);
  }
  @else {
    @warn "message";
  }
}

.class {
  color: get(color, content);
  background-color: get(color, bg);
  font-size: get(font, medium);
}

比起之前的命名，我覺得更直覺也更方便。因為變數的名稱常常忘記，但 map 裡的 key 值只要命名合理，通常不會太難記，省略前綴之後也變得更加簡潔，不用怕命名空間互撞。當然這樣子的管理方式除了在 font color 之外也可以套用在其他地方。不過礙於篇幅，這邊就不多著墨了。

小結：我們同時解決了 1.2.3.4 的問題

大量 Unit Class 造成閱讀上的困難

首先讓我們了解一下為什麼要有 unit class 的出現？ 主要是為了開發上的快速，我們將常用的屬性做最小的單元分割，這樣我可以一看 html 就知道他大概會長怎麼樣子。不需要再去看所謂的 css 怎麼寫。而且這樣一來要更動也會比較容易，而不是綁在 class 裡面牽一髮而動全身。

<div class="col-md-2 col-xs-12 padding-tb-20 margin-lr-20 text-center">
  <div class="col-md-6 col-xs-12">
    <p class="margin-20 body14 bold">
      
    </p>
  </div>
  <div class="col-md-6 col-xs-12">
    <p class="margin-20 body14">
      
    </p>
  </div>
</div>

以上

Henry

1. JSX 超級懶人語法

在 React JSX，我們常常使用以下語法去分發 props：

<Component alpha={alpha} beta={beta} gamma={gamma} />

但我忘記在哪裡發現了一個超級懶人寫法，由於使用到 ES6 的 object destructuring，前提是 你的 property name 必須跟 variable name 相同：

<Component {...{ alpha, beta, gamma }} />

夠懶夠簡潔。

2. .gitignore 與 LICENSE 產生器

以前曾經在 JetBrains 系列產品使用過類似的 plugin，把自己現在使用的工具或語言勾起來 .gitignore 就幫你產生好了，非常方便，沒想到有 web application 版本，回傳值還是 plain text，非常適合跟 curl 整合成 command line 工具。

既然有人提供自動生成 .gitignore 的工具，舉一反三是否有人提供自動生成 LICENSE 的工具呢？還真的有，而且直接幫你整合成 command line 工具了。透過 homebrew 就可以安裝使用。

3. Docker 安全建議書

最近心血來潮，想研究 Docker 安全性設定，google 才發現 Docker 官方已經 release 出一套自己開發的安全性檢測工具 Docker Bench for Security。這一套工具非常簡單，第一步在你的 docker machine 上把它 git clone 下來，第二步 sudo docker-bench-security.sh 它就會產生一張安全性建議的清單給你。

至於 Docker Bench for Security 遵循的安全標準，都定義在 CIS Docker 1.11 Benchmark 這份文件中。

Peter

CSS HTML 版面的實踐

關於 CSS 與 HTML layout 上的實踐。 有時候看到 Mock up 之後要開始刻寫版面，我找到以前看到的一篇文章「Styling for change with rules and exceptions」， 作者提出了一個非常簡單的想法，就是把 element 與 container 看成房間（room）與家具（furniture）。 用房間形容 container，element 比作家具其實是非常貼切的， 因為 container 不會一直換，但是 element 會因為未來的規劃而有所變動， 房間不會常常打掉重練，但家具總是會換嘛！

所以心中常存這個想法， 在實作 mock up 之前一定要先弄清楚 mock up 上的元件哪些是 家具，而哪個是房間。

在未來的擴充上，協作團隊在新增 element 到 container 基本上就不需要擔心房間的問題。

Atomic Design

這個也不是新的文章，也是在探討 HTML CSS 的實踐問題。 作者將網頁上的元件看成原子、分子之間的關係， 最小最小的元件是原子（例如：input、label、button），基本上獨立存在沒有什麼功用。 原子組成分子，一個表單（由 input、label、button組成），就會成為一個有功能的物件。 分子再組合會成為有機物，例如：有連結與 logo 的 navbar。 許多有機物可以排列成 template，之後還會有 pages（就是 template 填入資料後，真實的完成品）

在實踐的時候心中常存這兩個概念， 就會比較清楚要怎麼建構 HTML 與 CSS。

JavaScript
CSS
DevOps

--

--

葉顆顆
Sudo Ninja

Written by 葉顆顆

63 Followers
Editor for

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams