1 day ago

我們平時最開始學習寫 CSS 代碼的時候,我們都是這麼寫的:

.main-part .tabs {
  /*...*/
}

其實這樣的寫法是不好的,因為它過度的與頁面中的某一部分耦合了。我們在軟件工程的思想中追求的就是解耦。

BEM 風格不只一種

BEM 的命名規範不是死的,可以參考 bem-conventions

這裡有一些可供選擇的基於 BEM 命名約定的方案。

Two Dashes style(雙連字符風格)

block-name__elem-name--mod-name

  • 名字全部使用小寫。
  • BEM 實體的名稱中的每一個單詞使用一個連字符分隔。
  • 使用雙下划線(__)將元素的名稱和模塊的名稱分離開。
  • 使用雙連字符(--)分隔 Boolean 類型的修飾符。
  • 不使用 key-value 類型的修飾符
  • 重要提示!在注釋中,雙連字符被視為注釋的一部分,因此在文檔驗證時,雙破折號可能會引起錯誤。HTML5 Specification

CamelCase style(駝峰命名風格)

MyBlock__SomeElem_modName_modVla

這種風格的命名方案的不同點在於,在 BEM 實體中分隔單詞時使用駝峰命名法代替了一個連字符(-)。

"Sans underscore" style(無下划線風格)

blockName-elemName--modName--modVal

名稱使用駝峰命名法書寫。
元素名稱與模塊名稱使用一個連字符(-)分隔。
修飾符使用雙連字符(--)與模塊或元素分隔,
修飾符的名稱和值使用雙連字符(--)分隔。
重要提示!

在注釋中,雙連字符被視為注釋的一部分,因此在文檔驗證時,雙破折號可能會引起錯誤。HTML5 Specification

BEM 說明(這裡用 Two Dashes style(雙連字符風格))說明

在這邊使用 BEM 的命名規範,每行 CSS 代碼都只有一個選擇器

BEM代表 區塊(block),元素(element),修飾符(modifier)」,我們常用這三個實體開發組件。

在選擇器中,由以下三種符合來表示擴展的關係:

-   dash :僅作為連字符使用,表示某個塊或者某個子元素的多單詞之間的連接記號。
__  Two underline:雙下划線用來連接塊和塊的子元素
--  Two dash:雙減號用來描述一個塊或者塊的子元素的一種狀態

type-block__element--modifier

區塊(block)

一個區塊是設計或佈局的一部分,它有具體且唯一地意義 ,要麼是語義上的要麼是視覺上的。

在大多數情況下,任何獨立的頁面元素(或複雜或簡單)都可以被視作一個區塊。它的HTML容器會有一個唯一的CSS類名,也就是這個區塊的名字。

針對塊的CSS類名會加一些前綴( ui-),這些前綴在CSS中有類似 name space 的作用。

一個區塊的定義有下面三個基本原則:

  1. CSS中只能使用類名(不能是ID)。
  2. 每一個區塊名應該有一個命名空間(前綴)
  3. 每一條CSS規則必須屬於一個區塊。

例如:一個自定義列表 .product 是一個區塊,通常自定義列表是算在 mod 類別的,在這種情況下,一個 product 列表的block寫法應該為:

.product 

元素(element)

塊中的子元素是塊的子元素,並且子元素的子元素在 BEM 里也被認為是塊的直接子元素。一個塊中元素的類名必須用父級塊的名稱作為前綴。

如上面的例子,li.item 是列表的一個子元素,

.list{}
.list .item{}


.list{}
.list__item{}

這裡可以使用偽嵌套寫成

.list {
    &__item {}
}

修飾符(modifier)

一個「修飾符」可以理解為一個塊的特定狀態,標識著它持有一個特定的屬性。

用一個例子來解釋最好不過了。一個表示按鈕的塊默認有三個大小:小,中,大。為了避免創建三個不同的塊,最好是在塊上加修飾符。這個修飾符應該有個名字(比如:size )和值( smallnormal 或者 big )。

如上面的例子中,表示一個選中的列表,和一個激活的列表項

原本的寫法

.list {}
.list.select {}
.list .item {}
.list .item.active {}
    
用 BEM 的寫法

.list {}
.list--select {}
.list__item {}
.list__item--active {}

用偽嵌套優化之後為

.list {
  &--select {}
  &__item {
    &--active {}
  }
}

使用偽嵌套

使用 & 符號進行偽嵌套

.product {}
.product__item {}

等同於

.product {
    &__item {}
}

嵌套不得大於兩層

原則以 B + E + M 完成,不得使用 B + E + E + M,或是 B + B + E + M 之類的寫法

兩層是指從 sass compiler 後的 CSS 不得有超過兩層階層

.product {
  &__item {
    &--selected {}
  }
}

上面的 SASS 寫法這樣其實也才一層而已哦,因為 compiler 出來之後是

.product {}
.product__item {}
.product__item--selected {}

適當的使用 >

.list {
  &__item > a {}
}

這樣寫只會在 list__item 下一階層的第一個 a tag 會有效果而已,如果在這底下有兩個 a tag ,第二個會失效,這是特別要注意的點。

不要使用 Tag selector

BEM是不允許用 Tag selector 的

.menu li 能搞定的事情需要每個 li 都寫 .menu-item

優點:
就是避免 li 裡的 li 受影響
舉個例子,商品詳情頁是允許商家自定義標籤的,那麼商家展示區域標籤的祖先元素一旦用標籤選擇器定義了樣式,子子孫孫都要背負.

所以十分贊同在無法百分百確定不會嵌套同樣標籤的情況下不用 Tag selector

BEM 解決問題

組件之間的完全解耦,不會造成命名空間的污染,如: .mod-xxx ul li 的寫法帶來的潛在的嵌套風險。

性能

BEM 命名會使得 Class 類名變長,但經過 gzip 壓縮後這個帶寬開銷可以忽略不計

延伸閱讀 - 常用的CSS命名規則

  • 頭:header
  • 內容:content/container
  • 尾:footer
  • 導航:nav
  • 側欄:sidebar
  • 欄目:column
  • 頁面外圍控制整體佈局寬度:wrapper
  • 左右中:left right center
  • 登錄條:loginbar
  • 標誌:logo
  • 廣告:banner
  • 頁面主體:main
  • 熱點:hot
  • 新聞:news
  • 下載:download
  • 子導航:subnav
  • 菜單:menu
  • 子菜單:submenu
  • 搜索:search
  • 友情鏈接:friendlink
  • 頁腳:footer
  • 版權:copyright
  • 滾動:scroll
  • 內容:content
  • 標籤:tags
  • 文章列表:list
  • 提示信息:msg
  • 小技巧:tips
  • 欄目標題:title
  • 加入:joinus
  • 指南:guide
  • 服務:service
  • 註冊:regsiter
  • 狀態:status
  • 投票:vote
  • 合作夥伴:partner

注釋的寫法:

/* Header */
內容區
/* End Header */

Id的命名:

頁面結構
  • 容器: container
  • 頁頭:header
  • 內容:content/container
  • 頁面主體:main
  • 頁尾:footer
  • 導航:nav
  • 側欄:sidebar
  • 欄目:column
  • 頁面外圍控制整體佈局寬度:wrapper
  • 左右中:left right center
導航
  • 導航:nav
  • 主導航:mainnav
  • 子導航:subnav
  • 頂導航:topnav
  • 邊導航:sidebar
  • 左導航:leftsidebar
  • 右導航:rightsidebar
  • 菜單:menu
  • 子菜單:submenu
  • 標題: title
  • 摘要: summary
功能
  • 標誌:logo
  • 廣告:banner
  • 登陸:login
  • 登錄條:loginbar
  • 註冊:register
  • 搜索:search
  • 功能區:shop
  • 標題:title
  • 加入:joinus
  • 狀態:status
  • 按鈕:btn
  • 滾動:scroll
  • 標籤頁:tab
  • 文章列表:list
  • 提示信息:msg
  • 當前的: current
  • 小技巧:tips
  • 圖標: icon
  • 注釋:note
  • 指南:guild
  • 服務:service
  • 熱點:hot
  • 新聞:news
  • 下載:download
  • 投票:vote
  • 合作夥伴:partner
  • 友情鏈接:link
  • 版權:copyright

注意事項::

  1. 一律小寫;
  2. 盡量用英文;
  3. 盡量不縮寫,除非一看就明白的單詞。

CSS樣式表文件命名

  • 主要的 master.css
  • 模塊 module.css
  • 基本共用 base.css
  • 佈局、版面 layout.css
  • 主題 themes.css
  • 專欄 columns.css
  • 文字 font.css
  • 表單 forms.css
  • 補丁 mend.css
  • 打印 print.css
 
2 days ago

在這邊我們預計實現團隊中使用 sublime + Atom 的開發人員都能夠對 .scss 做自動縮進,並且效果必須一樣。

  • 縮進書寫規範:兩格空白

每個團隊或個人使用的 CSS 規範不盡相同,可以在細節部分自行調整,也可以參考一些CSS编码规范

有的人喜歡四格縮進,也有喜歡兩格的。

Atom

安裝 atom-beautify

command line 裡面輸入 apm install atom-beautify

安裝完畢之後,請完全關閉 Atom 後重新啟動。

接著嘗試打開 .scss 的檔案,按下 command + shift + p 並輸入 Beautify,選擇 run Beautify Editor。

你就會看到 SASS/SCSS 自動進行縮進排列。

如果要做到存檔自動 beautify ,請鍵入 cmd + ,,進入 package setting 的介面,找到 atom-beautify 點擊 settings,並往下拉找到 Sass 或是 Scss,將 Beautify On Save 打勾。

  • 將 Default Beautifier 換成 SassConvert
  • 打勾 Bautify on save (option,看個人,非必選)

那麼未來在開發 Sass 的時候,將在存檔(Command + S)的時候自動整理縮進。

Sublime

Install Package 安裝 SassBeautify

注意:正常來說不需任何設定就可以直接使用,預設自帶 4 格縮排,可以依照團隊規範調整,依此文章設定是兩格縮排,所以我們客製化內容如下

安裝開始

Preferences >> Package Settings >> SassBeautify >> Settings - User

將下面的內容複製上去

{
  // How many spaces to use for each level of indentation. "t" means use hard tabs.
  "indent": 2,
  // Convert underscores to dashes.
  "dasherize": false,
  // Output the old-style ":prop val" property syntax. Only meaningful when generating Sass.
  "old": false,
  // Custom environment PATH.
  "path": fasle,
  // Custom environment GEM_PATH.
  "gemPath": false,
  // Beautify the sass file after saving it?
  "beautifyOnSave": false,
  // Keep "inline" comments inline?
  "inlineComments": false,
  // Add a new line between selectors?
  "newlineBetweenSelectors": false,
  // Use single quotes everywhere
  "useSingleQuotes": false
}

這邊可以直接打開 .scss 檔案,用 command + shift + p 來搜尋 SassBeautify,按下 enter,就會自動縮排了

如果有跳 error ,應該是你的相依檔案路徑他找不到,可以依照官方的解法進行排除

Compatibility with RVM/rbenv

You need to specify the custom PATH and GEM_PATHvalues in your SassBeautify user settings.

Follow the steps below:

  1. Open up terminal
  2. Run: echo $PATH
  3. Copy the entire PATH into the 'path' setting
  4. Run: echo $GEM_PATH
  5. Copy the entire GEM_PATH into the 'gemPath' setting

Done.

後記心得

Atom 編輯器在使用 atom-beautify 插件後,可以選擇處理 sass 的 beautifier,預設是使用 pretty diff ,而且最坑的是下方的客製化選項 只支援pretty diff,簡單說,如果你想用 SassConvert,那你就無法調整預設 indent 為兩格的設置。

因為選項竟然都只支援 pretty diff...

偏偏 pretty diffSassConvert 整理出來的 SASS 又有些微不同

  • pretty diff 的註解與樣式中間不會有空一行
  • SassConvert 的註解與樣式中間會有空一行

所以如果團隊中用兩個不同的編輯器,只要 beautifier ,設定的不一樣,你就會看到 git commit 永遠一直在變動一大堆結構,這會使 PR 更難閱讀。

所以本文章實現了兩個不同編輯器卻能有同樣的自動化整理風格是退一步求其次,將原先的 SassConvert 自帶的四格縮進改為兩格,與 Atom 的 beautify 一樣,就可以排除這奇怪的問題了。

 
9 days ago

依照前一篇,在 在 Google platform 上架設 ShadowSocks(SS) + BBR,打造一台有 SS + BBR 提速的機器之後,接下來就是大家最關心的如何在 iphone 上面翻牆了。

不過基本上走到這一步都得花錢,花多花少而已,如果想要完全免費的話這篇文章可能幫不上你Q_Q

Surge(USD39.99 昂貴付費,但首推)

基本上這 APP 比較偏向開發者使用,過程會較繁瑣一些,操作也不是那麼平易近人,更令人不敢接近的一點就是付費昂貴,約 1500 NTD,不過這軟體對我來說,「付費就是撿便宜」,省了我很多麻煩,只要有連上網路的地方,都可以自動翻牆,並且智能的選擇路線,如果瀏覽大陸地區的資源,就不翻牆,眾多智能的功能,大概很符合我這種常常要用到網路的工程師了XD

還有,他不像以往的 VPN 什麼需要開開關關的,基本上我很少在開關他,通常都是我不想用,或者是手機重開機的時候吧!

先下載手機版

Surge Apple Store 載點

請先在電腦端下載 Nic 調整過的 SS file

這隻檔案可以正常使用 Line XDD

下載回來之後,請用編輯器打開他

編輯 [Proxy] 下方的 ##IP位置##, ##password## 請把他取代掉成你自己機器的
IP與密碼,至於 port 號和 加密方式我已經替你填寫好了

填好之後,請放入自己的 Apple iClound 裡面

接著打開手機的 Surge

依照下圖載入剛剛編輯過的檔案(如果找不到檔案,應該是你設備在同步中,請稍候幾分鐘)

P.S 如果你打開是英文版的,可以透過設定調整,這部份就不在贅述

點擊左上角的漢堡

從其他程序導入

點擊剛剛載入的檔案

基本上就完成了,可以回 Surger 首頁將通道開啟(最下排最左邊的開關 Tab)

順利翻牆 / 科學上網吧!

Shadowrocket(第二方案,約台幣九十元)

Shadowrocket Apple Store 載點

點開Add Configuration

依照上一篇架設的 SS server 的詳細資訊填入(在上一篇文章文末有教你怎麼看機器資訊)

第一次使用會有權限警示,點擇Allow即可。

只要之前設定的端口、密碼、加密方式等內容都正確的話,你就可以翻牆上網了。

電腦版呢?

這又是另一個故事了,電腦版也有 Surge ,不過又是另一個費用了,對你沒看錯,手機跟電腦版的付費竟然是分開的!!,不過我還是都買了,基本上會手機版的,電腦版的也差不多了XDD,這邊就不繼續教了

參考資源

 
10 days ago

建立 VPS

Google cloud platform 有免費 12 個月 300USD 的額度可以使用

  • 註冊 Google Clund Platform 服務
  • 點擊左上角三條線漢堡,下拉選單到 「Compute Engine」 -> 「VM 執行個體」

  • 點擊 「建立執行個體」

名稱:自定義,這是你的機器名稱
區域:請選 asia-east1-c 或是 asia-northeast1-b (亞洲區)
機器類型:由於做個人翻牆工具,可以只選「微型」就好,規格選越高錢扣越快
開機磁碟:請選作業系統 Ubuntu 14.04 LTS
防火牆:將「允許 HTTP 流量」和「允許 HTTPS 流量」皆設為開啟

建立後,用瀏覽器打開 SSH 並輸入以下指令

每筆指令輸入後記得按 Enter

先安裝 BBR 加速

BBR 是 Google 官方開源的擁塞算法來加速 TCP

也因為裝這個要重開機,所以先裝XD

依序輸入

wget –no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh

chmod +x bbr.sh

sudo ./bbr.sh

輸入任意鍵執行

過程會需要一些時間約三分鐘,最後他會問你要不要重啟機器(Do you want to reboot?)輸入 y 同意

之後會斷開連線,請在重複之前打開這個視窗的動作「SSH」-> 「在瀏覽器視窗中開啟」

輸入 sysctl net.ipv4.tcp_available_congestion_control

如果有出現 bbr 字眼,就是安裝成功了

安裝 ShadowSocks(SS)

sudo apt-get install python-pip -y

sudo pip install shadowsocks

重要!!! 以下指令中的 password 請務必改成自己要使用的

sudo ssserver -p 443 -k password -m aes-256-cfb --user nobody -d start

將服務停止

sudo ssserver -d stop

再次運行

sudo ssserver -p 443 -k password -m aes-256-cfb --user nobody -d start

大功告成,你已經有一台 SS + BBR 來做翻牆的機器了!

機器詳細資訊

  • IP 位置是你架設機器在上面寫的「外部 IP」
  • 密碼是剛剛你自行替換的「password」
  • 加密規則是 aes-256-cfb
  • port 通道 443

翻牆工具

我這邊是用 Surge ,不管手機跟電腦都是,要付費就是了,聽說也有免費的可以用,這部份就在另一篇教程: 在 iphone 上透過 Shadowsocks(SS) 在大陸翻牆講吧!

結果

這是用 surge 跑 benchmark 出來的結果,圖中的 GoogleTest 是邊敲本文章邊隨著架設的機器,可以看出速度還OK

Youtube 1080P Test

參考資源

 
12 days ago

最近常常在專案裡面看到令人很頭痛的 CSS,沒有設計模式,有大量不明白的階層跟命名,完全無法複用的元素XDD,心中是滿滿的 fuck。

於是我就開始對 Sass 產生好奇了,也從 BEM 的開發模式思考了一些命名和規則

BEM由Yandex團隊提出來的一種創新命名Class名稱的設計模式,BEM的意思是區塊(Block)、元素(Element)、修飾符(Modifier)

其中最好玩的就是,我們可以從瀏覽 class 名稱就能知道這些元素彼此之間的關係

讓我們來讀一下一般最常見到的結構吧

<div class="product">
  <ul class="menu">
      <li class="item active"><a href="#"></a></li>
      <li class="item"><a href="#"></a></li>
  </ul>
</div>

然後就會開始思考一些問題了

  • product 與 menu 的關聯? .product .menu
  • active 是否只侷限於 list 的範圍域?
  • menu 是可以獨立拆分出來的 Modular 嗎?還是其實是綁在 product 下面?

在使用 BEM 的命名原則之後

<div class="product">
    <div class="menu">
        <li class="menu__item menu__item--active"><a href="#"></a></li>
        <li class="menu__item"><a href="#"></a></li>
    </div>
</div>

別急,第一句你心理想的一定是一些髒話,這什麼鬼東西,這麼長?

我們了解了 BEM 的設計原則之後,你會發現這些東西一目了然,而且更具維護性與邏輯性,就像在 CSS style 裡面寫了 logic

.block{} //區塊 (Block)

.block__element{} //元素 (Element)

.block--modifier{}//修飾符(Modifier

區塊

一般網頁設計師在設計網站的時候,會把比較大的部分切出來,是一整個區塊,比方說

  • 搜尋欄的 search block
  • 用戶登入的 auth block
  • 網頁 logo 的 logo block
  • 導航欄的 menu block

然後包住以上所有的 block 的大區塊, head block

元素

在區塊下的元素,如果說這些 element 是綁定在這個 block 下方,在這個設計原則規範裡面就會用雙下底線來標記他是元素,例如 menu__item

修飾符

當元素或是區塊的狀態改變了,比方說我們最常見的 active ,在設計原則裡我們會用 double dash 來連接,例如 menu__item--active

所以當一個 menu item 發生狀態變化後,他的 class 會是這樣的

<div class="menu__item menu__item--active">

這樣一來雖然看起來很冗長(但又不是你在看XD,是瀏覽器啊啊),不過卻可以清楚知道這個 active 是修飾符,同時依賴在 menu__item 這個元素下層

如此一來我們只要透過 double 底線,或是 double dash 就可以知道這個 class 裡面擁有什麼行為或階層上的邏輯

然而修飾符能夠使用的時機並不少,除了狀態更動以外,也可以用在樣式設計上

比方說原本滿版的 post 在這個頁面變成 1/3 就可以這樣寫 post post--1of3

看看範例

<form class="site-search  site-search--full">
    <input type="text" class="site-search__field">
    <input type="Submit" class="site-search__button" value ="Search" >
</form>

耶,知道 BEM 設計原則後,我能透過這個例子知道

  • 一個區塊 site-search
  • 兩個元素 site-search__fieldsite-search__button
  • 一個修飾符 site-search--full

Jesus Fuck !! 怎麼這麼明瞭

那麼再來一個例子

<div class="media">
    <img src="logo.png" alt="Foo Corp logo" class="img-rev">
    <div class="body">
        <h3 class="alpha">Welcome to Foo Corp</h3>
        <p class="lede">Foo Corp is the best, seriously!</p>
    </div>
</div>

嗯我不知道誰與誰有關聯,可能要去讀 source code,也不知道什麼可以複用

然我將同樣的 code 套上了 BEM 設計原則就會如下

<div class="media">
    <img src="logo.png" alt="Foo Corp logo" class="media__img--rev">
    <div class="media__body">
        <h3 class="alpha">Welcome to Foo Corp</h3>
        <p class="lede">Foo Corp is the best, seriously!</p>
    </div>
</div>

Jesus Fuck again !!!

我馬上又清楚了

  • 有一個 .media 區塊
  • 有一個元素 media__body
  • 有修飾符 media__img--rev
  • h3, p 裡面的 class 是獨立可以複用的

什麼時機不會需要用到BEM

  • 可以獨立且具高複用性

例如常見的

  • 置左 .pull-left
  • 置右 .pull-light
  • 清除浮動 .clearfix
  • 文字置中 text-center

因為使用率很高,而且可以用在不同的 tag 上,所以會建議把他獨立成一個 class

SASS 3.3 支援 BEM 設計模式

嗯...最令人頭疼的可能就是在 naming 部分,我必須先想到第一個 class name 在「區塊」上才有辦法繼續寫下去我的「元素」「修飾符」

而且在以往的設計模式會打非常多的字

.media{}

.media--full{}

.media__submit{}

.media__img{}

.media__img--border{}

但 sass 3.3 之後支援使用 &字符連接後,完美的提升 BEM 的實用性啊,針對以上的例子你只需要寫成

.media{

  &--full {}

  &__submit {}

  &__img {

    &--border {}

  }

}

如此一來,就不用打一堆字卻又能夠完美實現 BEM 設計原則了!!

在這裡我曾經好奇過 & 連接符,我原本以為

.father {

}

.son {

}

.father {

  &.son {

  }

}

會是一樣的結果,不過如果要做出更好維護且不打架的命名,用連接字符的差別很明顯就能夠顯現,我們舉個例子

如果你的 son 要能夠搭配不同的 father ,比方說 father-US(爸爸是美國人), father-TW(爸爸是台灣人)

那就可以先把 son 與 father 先模組化起來,然後用 BEM 的設計原則來達到客製化各種國家的爸爸與兒子產生出不撞名又好懂得 naming(也不用額外想一些奇怪的命名)

.us-father {

    .us-father__son {  # 這裡是為了易讀,其實可以直接寫 &__son

      這爸爸底下兒子會有的屬性

    }

}



.son {

  基本做兒子該有的屬性

}

也因為 son 模組化了,所以我們可以寫出這樣的 html code

<div class="us-father">
    <div class="son us-father__son"></div>
</div>

這樣的架構打好了,就有最基本的 son 可以使用,也可以再去利用各別客製化不同國家的 son ,也沒有所謂奇怪命名來達到世界和平,雖然會讓 class 命名更長,不過也將 _- 發揮到極致,變成有高度可讀性及維護性的標誌

針對 & 連接字符有更詳細的說明請至 痞客邦 Jimmy 的初探Sass,秒懂文章裡學習哦

小結

BEM 這個設計原則並沒有一定要使用,不過裡面有很多可以值得學習的地方,這些命名原則都是能夠讓團隊有更好的協作默契,不會有一堆狗屎要整理,或是根本整理不動也不敢刪,變成你要去讀懂他的個人 style ,所以可以嘗試精讀這樣的內容,來規劃出能夠複用也能讓同事一目了然的 CSS 架構唄

參考來源

 
12 days ago

常見的情境有,搜索用戶資料、搜尋文章等等

而在 Rails 裡面有一個做基礎搜尋功能的 gem 他叫 Ransack,之所以會說只能做基本搜尋是因為,他是在下搜尋關鍵字的時候,從 database 裡面做模糊搜索,使用 like 去做 query

例如我們要搜尋 User 的 first name,名叫 Nic 的資料

在 ransack 裡面的寫法是

User.ransack(first_name_cont: 'Nic')

而他轉成 SQL 就會變成

SELECT "users".* FROM "users" WHERE ("users"."first_name" LIKE '%Nic%')

除了「模糊搜索」以外,需要更精準的搜索就需要用到「全文搜索」了

這部份就可以參考全文搜索的引擎(需要額外架設)

  • solr
  • elasticsearch

不過這篇就只說使用 ransack 在 Rails App 裡面實作搜尋吧

設計目標

  • 單獨的 Search Controller
  • 漂亮的路徑 example.com/search?#{search_key_word}

安裝 ransack

Gemfile
gem 'ransack'

設定 controller 與 routes

創建 search controller

rails g controller search

routes.rb
get "/search" => "search#index", :as => "search"

接下來我們要處理透過 form 送進來的 params,濾掉一些不必要的字符,這部份可以在 controller 裡面做 validation

def validate_search_key
  @query_string = params[:q].gsub(/\\|\'|\/|\?/, "") if params[:q].present?

  @search_criteria = search_criteria(@query_string)
end

然後告訴 controller 我們要搜尋的範圍

def search_criteria(query_string)
  { :title_or_description_cont => query_string } 
end

title_or_description_cont 是ransack提供的方法 意思是說,搜尋這個 model 裡面的 title 或是 description 欄位

接下來我們完成 index action

def index
  if @query_string.present?
    @search = Topic.search(@search_criteria).result(:distinct => true)  
  end
end

接下來只要將其搜尋結果,用 view 呈現出來,搜尋功能就完成了。

在這邊我們看到的 web url 會是

http://example.com/search?utf8=✓&q=test

其中的 q=test 就是我們從 form 送進去的搜尋內容

utf8=✓ 則是為了符合古老的瀏覽器 ie6, Rails 在 form 裡面幫我們自帶的 attribute

附上最後拼湊完成的 Search Controller

search_controller.rb
class SearchController < ApplicationController
  before_action :validate_search_key

  def index
    if @query_string.present?
      @search = Topic.search(@search_criteria).result(:distinct => true)  
    end
  end
  
  protected
  
  def validate_search_key
    @query_string = params[:q].gsub(/\\|\'|\/|\?/, "") if params[:q].present?
    @search_criteria = search_criteria(@query_string)
  end

  def search_criteria(query_string)
    { :title_or_content_cont => query_string }
  end

end
 
16 days ago

new or edit path helper? We can creating easy more path!

我們可能常常會需要在 view 裡面寫到 edit or new 的 link,這是我們在常見不過的一段判斷式了

some_project.html.erb
<% if @project.presnet? %>
    <%= link_to 'edit', edit_project_path(@project) %>
<% else %>
    <%= link_to 'new', new_project_path %>
<% end %>

然而我們認為更棒的作法,就是把這判斷式放進 helper 裡面,只為了讓 view 看起來更簡單一些,也許可以參照這篇 StackOverFlow

例如

some_helper.rb
def render_new_or_edit_project_path(project)
    if project.present?
      link_to 'edit', edit_project_path(project)
    else
      link_to 'new', new_project_path
    end
end

然後我們在頁面只要載入這個 helper 就好了,對吧?

some_project.html.erb
<%= render_new_or_edit_project_path(@project) %>

看起來一切完美,將 view 做了個 Refactor

but...轉折處就在這個 but

如果你未來繼續使用這樣的 Refactor 的方式,那麼 helper 裡面就會出現一堆

render_new_or_edit_xxxxxx_path 的這種鬼東西

或許你會認為可以把他用動態(dynamic)的方式生成,但得考慮到

  1. 如果遇到有 namespace 的 routes ?
  2. evalsend,是不是有 security issue 的問題? ,也許你會說使用 public_send,但畢竟這都是 ruby 的 meta-programming,對未來維護的時候,或許不是這麼好找尋?

那麼這個 helper 看起來又不是這麼好用了,變成只專門 for 某個頁面的方法,這樣真的是 refactor 嗎?

更好的方法

面對 new or edit 這個方法,我認為有更好的選擇

  • 使用 simple_form
  • 將 new or edit 交給 object 決定

我們可以統一把 path 交給某個 action 處理,個人偏好使用 newedit (如果你有更好的作法可以試試看自己設置的 action )

所以我們不需要花時間在判斷上面,只要連結一律導向 new_project_path

然後在 controller 裡面寫

def new
 @project = Project.find_by_id(params[:id]) || Project.new
end

如此一來,在你的 simple_form_for 裡面

some_form.html.erb
<% simple_form_for @project do |f| %>
...
<% end %>

他就能在 submit 時,自動選擇「new(新建)」或是「update(更新)」行為

因為這個自動選擇,是取決於你的 Object, Simple Form 會在將 object 傳送進來時,決定你的 action 以及 method

我們在 simple form 傳進去的 object ,在這裡定義為 record

form_helper.rb
action = record.respond_to?(:persisted?) && record.persisted? ? :edit : :new

也因為在這裡就做好選擇,所以一切是這麼智能,如果你想更了解,請詳見 simple form 的 source code 是如何因 object 決定行為

補充一下,如何知道這個 object 是已經存在?或是剛 new 出來的?

Project.new.new_record? # true

Project.new.persisted? # false


# 假定數據id為1的 project 存在的情況


Project.find(1).new_record? # false

Project.find(1).persisted? # true

如此一來,就不用寫這麼多的 new_or_edit_path 的 helper 啦!

 
19 days ago

精進C群

A組組長 MengjunGuo - 精进练习一个月总结

历时一个月的精进练习已经落下帷幕,感觉这个月的投入精力、时间和注意力比之前正式学习时要多很多。精进一个月比最开始的三个月更主动、积极和自觉,自己所感受到的深度也完全不一样。

匆匆忙忙一个月,总算是赶在最后一天把所有布置的任务都完成了。

B組組長 叶同學 - [学习笔记]一个月的精进让我充实许多

在精进的这一个月时间里,让自己的生活更加充实,编程已经逐渐纳入到自己的日常生活之中,甚至已经有了一种依赖心理,如果哪天发现没有敲代码会觉得这一天不够完美,哪怕自己Github上今天只推一个commit有了很浅的“小绿点”也会让自己心里舒服一些。

精進B群

小組長 李同學 - 精进群总结

其实参加全栈营真的收获了很多编程以外的东西,三言两语也还说不清。

在精进群中其实最大的收获就是让自己保持学习的习惯吧,毕竟学习能力是很重要的竞争力。

参加魔改大赛、精进群,其实都是给自己动力去学习,但两三个月的时间是远远不够的。在这之后一定要保持住学习的劲头、习惯,甚至成为一个终身学习者。

楊同學 yangxiaodan - 精进,向前进

这一个月来,沉浸在代码的世界里,一步一步地拾阶而上,已然成了一种习惯。Nic老师说,“代码需要时间来浸。”我晓得时间的力量,所有头顶光环的大神都不是一蹴而就的。

如果没有沉浸在这样的学习群里一个人闭门造车,效果必然是大打折扣的。偷懒是人的天性,大多数人都需要外在环境的激励。在精进班里,看着优秀小伙伴们一个劲地往前冲,被消磨的斗志又重新被点燃了。

周同學 ZSMHY - 精进一月的总结

在精进群小组学习的这一个月时间里,我感受到了小伙伴们的强大而充满热情的学习氛围。群里每天都固定提交学习进度和成果,既是压力也是学习动力,还有小组组长无形之中的督促。两位组长除了每天自己的作业练习,还细致认真的把每个小伙伴的练习进度进行表格登记,记录了大家整体的学习情况,方便大家复盘,真的非常感谢他们。

李同學 - 精進群一個月的心得

本來覺得兩個星期,這樣好像沒學到什麼東西,但這樣強迫自己回想這兩個禮拜做了什麼,原來在不知不覺地練習中,學會了不少知識和框架(雖然現在要我自己提取還是做不到)
是對成為可以被使用的工程師還有一段很長的路要走,我也沒有什麼很大的願望,只是希望在學了這全棧營以後,能像Nic助教一樣,能用寫程式來幫助周圍的人,解決他們遇到的問題,像是做出訂午餐9453或是區鍊塊貨幣的錢包之類的工具,這讓我當初在直播前面聽到很興奮,不是虛無縹緲的東西,是實際上可以幫助到人的東西

何同學 Smilingjun - 精进群心得

进群后开始进行把jdstore重新做一遍就让我收获很大,也可以说因为这件事情,我成为了一个会主动去把以前做过的东西再做一次的人,后来听到(忘记谁了囧)不断重新优化与构建自己代码的过程就是一个成长的过程。通过这次回顾,收获颇丰。

邱同學 qiuchengxiao - 精进总结

为期一个月的精进营就要结束了,突然觉得时间真的过的好快,想到要和自己奋斗一个月的小伙伴们分离真的是很舍不得,因为这已变成了我的习惯。在这一个月里自己又成长了不少,编程也精进了不少,真的很感谢你们,全栈营,插袋老师,nic 老师,各位助教,当然还有营里勤劳的叶达明队长和可爱的战友们。

马同學 maxiaojing - 我在精进群里一个月的收获总结

进了精进群之后,大家就好像一个大家庭似的,有组长和组员们共同督促练习,知道自己并不是孤独的一个人在奋斗,出了错有组员们帮助,集思广益。
对于现在的我而言,虽然还是不能脱离教材做输出练习,但我还会再继续复盘以前做过的章节,反复练习,出了错可以在谷歌上或者论坛里找答案,像拼图一样,一步一步的继续走,不会放弃。

郭同學 - 精进4周总结

四周的时间很快就结束了。在这四周里与同学们一起打卡,学作业,真的很有趣。比自己写作业有趣多了,让我想起了笑来老师说的学习就是社交。
其实并不是自己一个就不愿意学习,在平时自己也会认真学习相关的知识,但是总是觉得只有自己一个人。做的事情就没有那么有趣了。
加入精进组之后,每天看见有很多与我一样的同学,每天都在打卡,写作业。这时终于觉得不是一个人在战斗了。
当然,在这四周里,成长最多的,还是对于编程的理解。可以明显的感觉到,自己知道的变多了。

曾同學 kinglinxinsen - 一个月精进总结

时间过得好快,一个月的精进学习已经结束,通过这一个月的学习,虽然个人进度还是没跟上,但总体上还是有很大的收获。

周同學 kingzhoujin - 精进替代懒惰

希望精进营形式能够举办下去,并且可以授权各地学习小组进行,最好由全栈营官方出具精进营训练的官方指引,将组织权限下放到各地meetup小组,举行线下meetup精进,这样效果应该会更好,全栈营助教只需监控各地进度并给予指导就好。
虽然精进营结束,之后我也还是会坚持继续精进,一切才刚刚开始。

梁同學 精进群心得

这次参加精进群最大的收获是目标设立和拆解。这在构建反馈方面有很大的作用。反观之前自己做练习的时候,根本没有这个概念。虽然教材上面明明写着“建议完成时间”,却一直不当一回事。你看,这又是一个活生生的没有放下傲慢的例子。
精进的小套路是:设立目标,分解目标,看反馈再做调整,一直重复到效率提升为之前的100%!

精进群已告一段落,路还要继续走,精进不能停。

孟同學 - 精进群心得

精进组已经结业,但是成长还会继续。自己因为精进群发生的实质性小改变
1⃣️自己设定目标,并达成目标这样的任务行动模式。
2⃣️会主动的去在要求之外把知识进行重复。
3⃣️让我对加入社群产生出刚需。

陈同學 - 一个月精进总结

其实很庆幸自己参加了精进练习,没有在比赛之后就完全放弃学习了,新课程能学到的知识真的不亚于大赛能学到的,现在觉得自己以前那种比赛结束了全栈营的学习就结束了的想法大错特错,后续还是要继续课程的学习,反复刻意练习。

吕同學 - 精进,重在坚(上)持(瘾)

一个月的精进群训练今天结束了。回顾这一个月,发现自己的练习量比大赛期间还要多!在全栈营之后还能保有这份对编程的热情,想想还是挺开心的!

身边很多全栈营朋友在大赛结束后就停止编程学习了。很高兴,我是仍在前行的那一个。感谢精进群的老师、组长和小伙伴们的督促和鼓励,也感谢自己坚持每天提交作业,坚持对各种小功能做提取练习,坚持每一个作业都在新的专案中作迁移。虽然也有很多做得不好的地方,但这个月自己的进步还是很大的。精进训练结束,但编程学习仍在继续。希望,在今年年底全栈营全部课程结束之时,我是能跑到终点的那一个。

丁同學 - 精进群一个月总结

希望下一期精进群的同学,好好做以下,里面的内容如果能好好理解运用的话,真的会收益匪浅,自己也是因为时间原因,这块的教材练的还不够,还满可惜的。

叶同學 - [学习笔记]一个月的精进让我充实许多

在精进的这一个月时间里,让自己的生活更加充实,编程已经逐渐纳入到自己的日常生活之中,甚至已经有了一种依赖心理,如果哪天发现没有敲代码会觉得这一天不够完美,哪怕自己Github上今天只推一个commit有了很浅的“小绿点”也会让自己心里舒服一些。

舒同學 - 精进学习总结

精进学习已经一个月了,时间过的飞快,收获也是很大的,前两周共完成Joblisting 及JDStore,rails百宝箱第二集,第三集部分的练习。后两周完成了rails百宝箱第三集,SQL入门,rails百宝箱第四集,自动化测试,编程语言第一集以及我自己项目的用户故事,landinpage和onborading

吕同學 - 精进群 ORID

不管多忙,基础学习的时间不能停.

赵同學 - 精进营总结

由于正式的课程已经结束,感觉大家多少有点放松,很难想象一个月做这么多等东西。通过复盘招聘网站和购物网站,进一步理解了其中等深层内涵,有些我们以前做的时候不懂等东西,通过这次等练习也基本都弄懂了。

姜同學 - 精进组一月总结

这一个月的持续学习,本来自己一个人是很不容易做到。每天保证四个小时以上,并且持续的做下去的。是因为群里的小伙伴们,每天都汇报着自己的进度,并且互相鼓励着,有了问题在一起讨论形成的氛围,激励着自己要按时的做完今天的进度。比起前几个月自己一个人做的感觉好的太多了。因为多了一个监督自己的地方,让自己可以不但可以内激励,还有外部的监督。保证了自己每天都在练习编程,投入时间持续的学习。

颜同學 - 精进群结业总结

如果不加入精进群,我可能会拖延症好久才回进行提取练习,因为真的让大脑反向提取内容在刚开始是非常困难的,但是作业要求再加上同学们的分享,我逼迫自己把功能分开提取会议,试着替换一些数据,不完全按照教材提取,发现会更加直观的感受各个功能的实际意义。这些东西如果不自己提取是无法体会的。

李同學 - 知识创造财富——精进群30天总结

精进群使我可以用正确的方法去做正确的事情,光光这一点就已经是很大的收获了。

总体来说,这次参加精进群,让我找到了全职在家应有的学习状态,让我离用编程解决重复性劳动这个终极目标又进了一步,也消除了我在独自成长上的孤独感。所以其他同学们,心动不如行动,赶紧报名下一批吧。我们要相信,知识是可以创造财富的!

周同學 - 学习,就要对自己狠点

这个月以来,面对精进群布置的任务确实比较高难度,但是,复盘是不能跳过的坎,如果畏惧,看到这样大的任务就吓到了,不正视不去做,那么很难由小白跳出来,很难“破局”。

petersngg - 7月小结

当投入到一件事中,时间流逝的特别快。7月就过得特别快。

一个月前,我加入ROR精进群,跟12位队友持续学习,相互监督,相互对比。现在想起来,当初若不是加入这个群,7月份也不会取得下面这么多的成绩。

张同學 - 精进c群一个月总结

一个月前的今天7月1日加入了精进c群,回顾这一个月。当初参加,踌躇满志,现在心里空落落。究其原因,就是这一个月没有按照群要求完成作业。

 
22 days ago

唐同學 - 全栈营求职群收获总结

Nic老师用自己经过实战的宝贵经验,建设了一个贴近实战的模拟环境。有的放矢的用“套路”锻炼了我们,尽可能地引领我们,少走了很多弯路。

来到求职群的初衷就是求虐求鞭策的,一个月下来,无论从心态和自驱力上都得到了一次改进。

最大的收获就是注意力的收敛和专注度的提高。外面的世界诚然精彩,但既然选择了程序这条道路,那么在还没有成长到一定阶段时,就要果断放弃很多占用注意力的事物,好钢用在刀刃上。

不仅跟进了群内的作业,还因为通过作业认识到了自己的不足之处,激励并提高了每日课程学习的时间占比。

江同學 - 求职群第十一次作业心得体会

我深深地感到参加这次求职群达到了我预想的目的,NIC老师全方位地从个人简历的准备,面试的自我介绍,面试题的准备到笔试题的练习实作,对应聘公司的产品观察及建议,到更多实作项目的要求,设计了重重关卡,可以说如果这些关都能够轻松闯过的同学我觉得现在就能找到工作。

这次的求职群指导,极大地锻炼了我们的求职能力,虽然我现在的水平自己还很不满意,但我知道接下来应该主要补全哪些方面的知识,这个非常重要。更为关键的是确实要开始行动了,要开始准备发简历,光靠在屋里闭门造车肯定 不行,必须要有行动,要勇敢地去接受面试笔试的挑战!

衷心祝愿在求职群的27个同学(包括我自己)都能找到自己想要的编程工作,祝我们走过的每一步都算数!

黃同學 - 求职群心得总结

我以前从没写过简历,说到求职面试,就感觉是一道自己跨不过的坎,这一个月的求职面试群经历真的让我感觉收获很多,在nic老师的帮助下,我写了第一份简历,并经过两次修改和一次口语表述,感觉写简历其实并没有自己想的那么恐怖,按着套路来,参考优秀的个人简历,然后把自己的个人经历套上去,再一步步完善。

祁同學 - 在求职的道路上,一切才刚刚开始

我发现Nic老师的这个作业也非常好,可以通过对专案的二次梳理,总结出自己学到了什么内容,学到新功能,需要补充的知识点,对模糊的内容进一步的探究,达到做这个专案的经验值。

李同學 - 全栈求职群月结

Nic老师每期任务完成后都会把大家的答案公布在群里,大家可以互相浏览、学习,发现群里的小伙伴们的作业质量都非常高,对我启发也很大,比如对面试公司产品提建议的那次印象很深,其实这是要打破固有思维、用更客观的角度去看待产品才能提出更高质量建议的题目

張同學 - 我在求职群的精进之路

参加求职群之前,我自己写的简历就是简单粗暴的罗列所有个人信息,毫无重点,真的可以直接放进简历黑客里当反面教材。而我在nic老师的指导,并使用过简历黑客的服务后,才认识到原来可以用套路来完成简历的。

nic老师很nice的给每一位小伙伴提出了各自简历中的建议。我可以从里面好的方面借鉴学习,同时避免那些不是特别合适的简历方式,这样的学习方式特别的高效。

陳同學 - 对于求职群一个月经历的总结

在我之前的认识里,简历的撰写并没有什么技巧可寻。不就是从网上下载一个模板,然后把自己的情况填进去,有什么写什么,就可以了。
看了求职指南以及老师给的简历范本之后,才意识到原来这里面还有这么多技巧。各个内容板块的顺序侧重点如果安排不当,很可能就被刷掉。

吉同學 - 我在求职群一个月的收获总结

自我介绍录音这个作业相当有趣,一直以为,自我介绍,就是随便两句就搞定,甚至一度觉得面试官如果在拿着你的简历的时候,还要你做自我介绍,那这个面试官就是SB.... 也是在看了一些帖子,又去询问了有人资经历的朋友,才知道,这个环节是有它存在的意义的

再着,自己给自己录音,由于我想要尽量模拟还原面试的场景,所以,选择先背下来,不背不知道,还是,很要下点功夫,也是在这个过程中,让我突然感觉,简历、面试,的准备工作真的是很多很细,并不想以前以为的那样随意、简单。

劉同學 - 全栈营Nic老师求职群心得

Nic老师的求职群目标明确,层次感强。难度逐渐增加,不断的实作面试实战中的各个环节。
自己之前对简历的撰写存在一些恐惧,因为只有目前的自学经验,不会的太多太多,求职群里,Nic老师给大家比较明确的套路

荷同學 - 我在求职群一个月的收获总结

我知道这是一个和大家一起学习与互动的难得机会!而且我也很欣赏Nic助教的沟通方式。总是很正向温暖的鼓励同学们。也慷慨地与同学们分享自己所知所学。当Nic助教一建立完成求职群组,我就確信这个七月我会过的非常扎实有收获!
七月已经到了尾声,我要再次感谢持续用心经营求职群的尼克助教,以及各位努力的同学们,我相信在程序员的这条路途上持續奮鬥著.
就像是尼克助教所说的:一切才刚开始。

邢同學 - 我在求职群一个月的收获总结

令我始料未及的是,在求职群中一个月的锻炼,自己的技术、认知和心态都有了很大的改变。

楊同學 - 找工作的正确姿势——求职群ORID总结与实录

一句话总结,你把时间撒在这里了,就会有收获!!!

所以能看到,找工作就是:技能占大一部分,拿出完整的作品的能力,但只是一大部分,还有对目标公司的了解,对目标公司的重视程度,写简历,改简历,准备自我介绍,给人讲故事,体现自己都做了什么,不断重复重复再重复,直到成功。

沙同學 - 求职营总结

一转眼一个月的时间匆匆而逝,在这一个月的时间里,辛亏有了 Nick 老师的帮助,自己才能在紧张的做research 的同时,也没有完全将 ror 扔下。

孔同學 - 20170731_ORID日志

改变了我对“求职”这件事的认知。

王同學 - 我在求职群一个月的收获总结

这样看来这个月我还真做了不少事呢!我最大的收获就是思维上的转变,因为Nic老师想让我们学习到的,肯定不是做一个任务就能获得的,他的思路方式、如何解决问题的方式和练习方法是最重要的,在接下来的练习和实践中,我都会采用Nic老师教的方法,不记得就回头复习,再出发,再复习,如此往复!幸运的是我们的求职群永远不会解散,并且以后还可以在群里分享自己的面试经验和提出困惑。我在墙上一直贴着笑来老师的话:用正确的方法做正确的事情,你一定会变得更好!若长期持续用正确的方法做正确的事情,你的未来一定会很伟大!

费同學 - 7月总结

其实一切才刚刚开始,只有通过不断的实际面试才能学到新的技术、改变错误的观念和想法。

熊同學 - 求职群收获总结

通过这几个作业让自己看到了很多非科班出身的全栈小伙伴的一个弱点(通病),在进行正式的面试前,建议大家都夯实下自己的编程基础知识,这是最容易拿分同时有最容易忽略的部分。

陳同學 - 我在求职群修炼一个月的收获总结

面试其实是个查缺补漏的过程,可以发现自己以前遗漏的知识点,为下一次面试做准备

罗同學 - 求职营感想

不知不觉中一个月过去了,全栈营的求职群也到了最后一次作业。想当初刚进群的时候带着茫然,带着焦虑,带着对未来的不确定加入的求职群,到现在的虽然仍然不确定,但是心中却不像原来那么的焦虑和无助。谢谢大家的陪伴,在这一个月里我才对于简历对于求职有了清楚的了解。

忽同學 - 求职群心得

知易行难,贵在坚持,通过这一次的求职群的一系列任务,我们通过设定一个任务目标,而去进行各种各样的尝试,完成各式各样的任务。

王同學 - 求职群中的一个月

反反复复的一个月,也很充实的一个月,在求职群中的这一个月,完成了十个与众不同的任务。从简单到困难,做出了一些很有趣的小玩具,同时也在帮单位做一些小项目,学以致用的感觉还是挺好的,毕竟没有白费功夫去学习。
其实我感觉最好的学习在于总结,老师们一直要求我们写心得,也是在培养一种学习方式。在这最热的一个月,我完成了求职群中的作业,以后也不知道有没有机会会有老师留作业,然后在每个接近临近交作业的晚上,拼命做作业不想被拉下,生活不易,且行且珍惜,愿在这个群中我们还是可以一起讨论问题,虽然在不同地方,但我们学过同样的东西。

凌同學 - 我的全栈求职群复盘

转眼在求职群已经学习了一个多月的时间,在nic的带领下,完成了十次作业,掌握了很多求职的技巧。

王同學 - 求职,在路上

一个月的求职学习算是告一段落了,没有nic大神的任务布置,接下来的就是自己见招拆招,必要的时候也可以在群里讨论,请教nic老师和其他大神、同学们。
我很幸运参加了这次培训,感谢全栈营,感谢nic老师。

張同學 - 在求职群收获的一些原则

时间总是在回顾的时候,才显得飞快。这是全栈营的最后倒数第二次作业了(最后一次我觉得应该是在10/1前获得offer),下面是我在求职群一个月时间的收获,我把学到的正确的做事方法,总结成了一些原则。

肖同學 - 7/30 我在求职群一个月的收获总结

在做求职群的作业的时候越来越不怕换工作了一样,一切都可以学一切都可以通过训练得到提高,不会的就学就好了。

思同學 - 求职群一月总结

 
23 days ago

製作微信 GIF 貼圖吧

限制

微信GIF要注意只能上傳 1MB 的圖檔

Step 1 :素材準備

  • 五至七秒左右的影片,不宜過長
  • 想一個可以加在影片上的文字

Step 2 :剪輯影片

這邊我是使用 Mac OSX 自帶的 imovie 剪輯,加上字幕
手機或移動端推薦「小影」APP

Step 3 :將影片轉存至GIF(video to gif)

這邊我使用這套網站進行出圖XD

https://ezgif.com/video-to-gif

因為他可以把畫質跟格數調至最低(不調低很難達到 1MB 以下的限制)

上傳影片後,如圖所示設定

如果還是超過 1MB 最後的絕招就是進行 GIF 壓縮

Step 4 :壓縮GIF圖檔

推薦使用 compressor.io

實測壓縮能力最好,基本上到這邊都能壓到 1 MB 以下,如果真的還是超過,基本上就是影片畫質太好或時間太長,需要回到第一步將影片在降低畫質跟時間

Step 5 :上傳


新增為貼圖吧!