Armno

zsh syntax highlighter

2016-04-12T00:00:00+00:00

zsh-syntax-highlighting เป็น plugin ของ zsh ที่จะทำให้ command ที่เราพิมพ์ใน terminal มีสีสันขึ้นมาได้ เช่น จากแบบนี้

เป็นแบบนี้

หรือถ้าพิมพ์ command ไม่ถูก (ไม่มีใน $PATH) ก็จะเป็นตัวแดงๆ แบบนี้ (จริงๆ จะเป็นสีอะไรนั้นแล้วแต่ theme ของ iTerm อีกที)

ประโยชน์คือนอกจากจะสวยดีแล้ว ยังป้องกันการพิมพ์ command ผิดได้ดีมาก เพราะเราจะเห็นได้ทันทีตอนพิมพ์ถ้าหากเราพิมพ์ผิด จะได้แก้ก่อนกด enter ได้ทัน ส่วน subcommand จะไม่มี highlight ให้นะครับ

ใช้งานกับ `oh-my-zsh`

zsh-syntax-highlighter นั้น ผมใช้งานร่วมกับ oh-my-zsh โดยวิธีการติดตั้งนั้นก็ตาม install.md ใน repo ส่วนใครที่ไม่ได้ใช้ oh-my-zsh ก็ใช้งานได้เหมือนกันจ้า

ขั้นแรกก็ต้อง clone repo ของ zsh-syntax-highlighting มาไว้ใน oh-my-zsh ในเครื่องเราก่อน

$ git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

จากนั้นเพิ่มชื่อ zsh-syntax-highlighting ใน plugins ในไฟล์ ~/.zshrc

plugins=(git colorize sublime vi-mode zsh-syntax-highlighting)

สุดท้ายก็ source ไฟล์ ~/.zshrc ให้ config ใหม่นี้ทำงาน เป็นอันเสร็จพิธี

$ source ~/.zshrc

Happy Songkran จ้า

วิธีการทำงานของ web browser

2016-01-28T00:00:00+00:00

HTML, CSS กับ JavaScript เป็น 3 องค์ประกอบหลักของเว็บไซต์ทั่วๆ ไปที่เราเห็นกันอยู่ ส่วน web browser นั้นก็มีหน้าที่แปลง code ของทั้ง 3 ส่วนประกอบนั้น แสดงผลออกมาเป็นเว็บไซต์ให้เราได้ใช้งาน ในฐานะคนทำเว็บ การเข้าใจหลักการทำงานของ web browser นั้นช่วยให้เข้าใจถึงที่มาที่ไปของสิ่งที่ปรากฏบนหน้าจอ รวมถึงจะเป็นประโยชน์ในเรื่องการ optimize performance ของเว็บไซต์ด้วยครับ

#nerdalert โพสต์นี้มีคำศัพท์เฉพาะ และทับศัพท์ค่อนข้างเยอะ แต่ผมก็จะพยายามทำให้เข้าใจง่ายที่สุดเท่าที่จะทำได้ ถ้าอ่านตรงไหนตรงไหนแล้วงงๆ comment ไว้ได้เลยครับ

ในโพสต์นี้จะขอข้ามเรื่อง network connection ไป แต่จะเริ่มตั้งแต่การทำงานของ web browser หลังจากได้รับ response เป็น code จาก server ไปจนถึงขั้นตอนสุดท้ายคือตัวเว็บไปปรากฏบนหน้าจอ หรือพูดง่ายๆ ก็คือ ตั้งแต่ browser ได้รับ code <html><head></head>...</html> จนถึงขั้นตอนการ render เว็บจ้า

browser แต่ละตัวจะมีส่วนที่ทำหน้าที่แสดงผลเว็บไซต์ ที่เรียกว่า rendering engine หรือ layout engine เช่น

Blink (Chrome, Opera)
Gecko (Firefox)
WebKit (Safari)
EdgeHTML (Edge)
Trident (Internet Explorer)

rendering engine แต่ละตัวก็มีวิธีการแสดงผลที่แตกต่างกันในรายละเอียดเชิงลึก และคำศัพท์เฉพาะที่แต่ละ engine ใช้เรียกแต่ละขั้นตอน แต่ภาพรวมแล้วขั้นตอนจะคล้ายกัน เป็นไปตาม spec ของ W3C ซึ่งขั้นตอนหลักๆ มีอยู่ ดังนี้

1. การสร้าง DOM กับ CSSOM

DOM (Document Object Model) คือตัวแสดงคุณสมบัติและความสัมพันธ์ระหว่างแต่ละ object ในหน้าเว็บ (document) ซึ่งก็จะประกอบไปด้วย properties กับ methods ของแต่ละ object พร้อมกับความสัมพันธ์กับ object อื่นๆ เช่น object A เป็น parent ของ object B และขณะเดียวกันก็ทำให้ object B เป็น child ของ object A เช่นกัน

ส่วน CSSOM (CSS Object Model) นั้นก็เช่นเดียวกับ DOM แต่เป็นการสร้าง object model จาก CSS ของเว็บ ที่มีทั้ง properties ที่เราคุ้นเคยกันใน CSS พร้อมกับความสัมพันธ์กับ object อื่นๆ ซึ่งก็คือคุณสมบัติ cascading ของ CSS ครับ

การสร้าง object จาก code ที่ได้รับมาจาก server นั้น จะประกอบด้วย 2 ขั้นตอนย่อยคือ Tokenization กับ Parsing

Tokenization (Lexical Analysis)

Tokenization ในโลก DOM คือกระบวนการที่บอกว่า code แต่ละตัว หรือแต่ละช่วงนั้น มันคือส่วนประกอบใดของ element ตาม spec ของ W3C ตัวอย่างเช่น เรามี <button>Go</button> ซึ่งถือเป็น 1 element กระบวนการ tokenization คือการระบุว่า

<button> คือ tag เปิด
G คือ character
o คือ character
</button> คือ tag ปิดของ element นี้

นั่นคือการระบุแต่ละส่วนของ code ออกมาเป็น token แยกออกเป็นตามประเภท นั่นเอง

Parsing (Syntactic Analysis)

Parsing คือการนำ token แต่ละส่วนที่ได้จากขั้นตอน tokenization นำมาตรวจสอบกับ HTML syntax ว่ามีความหมายอย่างไร และต้องเป็น object ชนิดไหน จากนั้นจึงสร้างเป็น object ซึ่งในโลกเว็บก็คือ DOM node กับ CSSOM node นั่นเอง แต่ละ node ก็ประกอบด้วย property (attribute) กับ method ของ object นั้นๆ และ object ที่ได้เหล่านี้ก็จะถูกนำไปประกอบกับเป็น tree structure ขึ้นมา

DOM & CSSOM Tree construction

หลังจากที่เราได้ node แล้ว ก็มาถึงขั้นตอนการเชื่อมความสัมพันธ์ระหว่าง node นั่นคือการบอกว่า node ไหน เป็น parent/child ของ node ไหน ซึ่งพอเราเชื่อมทุก node เข้าด้วยกัน ก็จะได้โครงสร้างที่เป็น tree ของ node ขึ้นมา เรียกว่า DOM Tree กับ CSSOM Tree ครับ

สำหรับ DOM นั้นจะค่อนข้างชัดเจน อย่างที่เห็นใน code หรือ element inspector ใน DevTools

<html>
  <head>
    <title>Awesome</title>
  </head>
  <body>
    <h1>Hi</h1>
  </body>
</html>

DOM tree ก็จะออกมาแบบนี้

แต่ CSSOM นั้น ไม่มีโครงสร้างชัดเจนเหมือน DOM แต่ก็มีโครงสร้างเป็น tree เหมือนกัน นั่นก็เพราะว่า CSS มีคุณสมบัติ cascading ที่ style ของ element บางส่วนจะ inherit มาจาก parent element และทุก element ก็จะ inherit style ของ <body> และ <html> มาเช่นกัน

สมมุติว่าเรามี CSS แบบนี้

div { ... }
p { ... }
div p { ... }

CSSOM tree ก็จะออกมาประมาณนี้ครับ สังเกตว่าแท็ก <p> ปรากฎอยู่ใน CSSOM tree 2 ที่ด้วยกัน style ที่แท็ก <p> แต่ละตัวจะได้รับ ก็ต่างกันไปตามโครงสร้างของ CSSOM tree และจะถูกนำไปใช้ในขั้นตอนการ render ต่อไปครับ

หลังจากที่ได้ DOM Tree กับ CSSOM Tree แล้ว ก็จะถึงขั้นตอนต่อไปที่การสร้าง Render Tree

2. สร้าง Render Tree

Render tree ถูกสร้างขึ้นมาจาก DOM tree และ CSSOM tree โดยที่ render tree จะประกอบด้วย DOM element ที่จะถูก render บนหน้าจอ browser เท่านั้น ดังนั้นจะมีบาง element ที่อยู่ใน DOM tree แต่ไม่อยู่ใน render tree คือ:

element <head> และ element อื่นๆ ข้างใน
element <script>
element ที่มี style display: none กำหนดไว้อยู่

แต่ละ node ใน DOM tree ก็จะได้รับ style ต่างๆ จาก node ใน CSSOM tree ประกอบกันได้ render tree ขึ้นมาครับ

3. Layout

Layout หรือ Reflow คือการที่ browser คำนวนหาขนาดและที่อยู่ของ element ใน render tree ขนาดของ element ประกอบไปด้วย width กับ height ส่วนที่อยู่ตำแหน่งของ element นั้น เป็นระบบ coordinate (x,y) ว่าอยู่ตรงไหนเทียบกับหน้าจอ (viewport) ซึ่งเป็น root element ใน render tree ในขั้นตอนนี้ style ที่กำหนดตำแหน่งของ element จะถูกแปลงเป็นหน่วย absolute pixel เมื่อเทียบกับ viewport เช่น “<div id="logo"> อยู่ที่ตำแหน่ง 10px จากด้านซ้าย และ 5px ด้านบน เมื่อเทียบกับ viewport” เป็นต้น

ด้านล่างนี้เป็นวิดีโอจำลองการ reflow ของ Gecko engine ของ Firefox กับเพจ mozilla.org [ที่มา]

4. Paint

Paint คือการ render แต่ละ element ใน render tree ออกมาเป็นแต่ละ pixel ให้ไปปรากฎอยู่บนหน้าจอ browser ซึ่งขั้นตอนการใส่แต่ละ property ให้แต่ละ element ก็จะประกอบไปด้วยขั้นตอนยิบย่อยที่ browser ต้องทำอีกมากมาย ส่วนมากมักเป็นการ “วาด” ส่วนประกอบต่างๆ ออกมาบนหน้าจอ พอ render ครบทุก element ก็จะได้เป็นเว็บออกมาครับ

ขั้นตอนเหล่านี้ไม่เกิดขึ้นเพียงครั้งเดียวแล้วก็จบไป แต่อาจเกิดขึ้นได้หลายๆ ครั้ง เช่น กรณีที่ DOM ถูกอัพเดท หรือการแก้ไข CSS property บางอย่างของ DOM element ก็ทำให้เกิด Layou/Paint ได้ครับ ดูเพิ่มได้ที่ csstriggers.com ได้เลยจ้า

ทั้งหมดนี้ก็เป็นขั้นตอนคร่าวๆ ของวิธีการแสดงผลเว็บไซต์ของ web browser ที่เราใช้กันอยู่ในปัจจุบัน จะเห็นว่า web browser ที่ทำหน้าที่แสดงผลเว็บไซต์ นั้นจริงๆ แล้วมีขั้นตอนการทำงานที่ค่อนข้างซับซ้อนพอสมควร แต่การทำความเข้าใจเรื่องเกี่ยวกับ browser ก็ถือเป็นพื้นฐานที่สำคัญที่จะต่อยอดไปเรียนรู้เรื่องอื่นๆ ต่อได้ครับ

Sources / อ่านเพิ่ม

How Browsers Work: Behind the scenes of modern web browsers HTML5Rocks
How Browser Works (slides) by Arvind Ravulavaru
Life of a Button Element (video) by Alex Russell
An overview of Lexing and Parsing by Ron Savage

จัดโค้ด JSON ใน Vim

2016-01-25T00:00:00+00:00

การ format file JSON (จัดให้เป็นระเบียบ, uncompressed, prettify) ปกติเป็นงานที่ผมไม่ได้ทำใน Vim ต้องพึ่ง editor ตัวอื่น (เพราะไม่เคยรู้วิธีการ) แต่ด้วยความสงสัยก็เลยลองค้นหาวิธีในเน็ตดู ก็พบว่ามีหลายทางให้เลือก

สมมุติว่าผมมีไฟล์ JSON ที่ถูก compressed มาไว้แบบนี้

[{"model":"x-e1","brand":"fuji","type":"mirrorless"},{"model":"d60","brand":"nikon","type":"dslr"}]

ต้องการจะ expand/prettify มันออกด้วย Vim จะต้องทำยังไง

วิธีที่ 1: ใช้ `json.tool` ใน Python

ในเครื่องถ้าลง Python ไว้ก็จะมี module ที่ชื่อว่า json.tool ใช้ format JSON ผ่าน command line ได้

$ python -m json.tool <FILENAME>

# หรือ
$ cat <FILENAME> | pythone -m json.tool

ซึ่งใน Vim เราสามารถ execute command line ได้จาก Ex mode (กด : หรือ Q ใน Normal mode) ดูรายละเอียดของ command นี้ได้ที่ Pretty printing JSON in Vim ได้เลยจ้า

:%!python -m json.tool

ก็จะได้ JSON ที่ format แล้ว

[
    {
        "brand": "fuji",
        "model": "x-e1",
        "type": "mirrorless"
    },
    {
        "brand": "nikon",
        "model": "d60",
        "type": "dslr"
    }
]

แต่มีข้อสังเกตก็คือ

แต่ละ property ของ object ถูกเรียงใหม่ตามตัวอักษร ในไฟล์ตัวอย่างคือ property brand ถูกเลื่อนขึ้นมาอยู่ก่อน model
ไม่สามารถกำหนดจำนวน space ได้ จะเป็น 4 space ตลอด

ผมก็เลยลองหาวิธีอื่นดู เจอ Node module ที่ชื่อว่า json

วิธีที่ 2: ใช้ `json` Node module

ขั้นแรกต้องลง json Node module แบบ global ก่อน เพื่อให้เราสามารถใช้ command json ได้

$ npm install -g json

ใช้งานใน Vim จาก Ex mode เหมือนเดิม

:%!json

ก็ได้ JSON ที่ format แล้วแบบนี้

[
  {
    "model": "x-e1",
    "brand": "fuji",
    "type": "mirrorless"
  },
  {
    "model": "d60",
    "brand": "nikon",
    "type": "dslr"
  }
]

สังเกตว่าลำดับของแต่ละ property ยังเหมือนเดิม ส่วนจำนวน space เป็นค่า default คือ 2 space ในการ indent เราสามารถทำหนดได้ด้วยการส่ง argument ให้ json command

:%!json -2         # 2 spaces
:%!json -4         # 4 spaces
:%!json -o json-7  # 7 spaces, กรณีที่ไม่ใช่ 2 หรือ 4

3. ใช้ `sourcebeautify.vim`

sourcebeautify.vim เป็น plugin ของ Vim ใช้ format code อย่างอื่นนอกจาก JSON ได้ด้วย (HTML, JavaScript, CSS, JSON, XML, MySQL) แต่ผมยังไม่ได้ใช้เยอะขนาดนั้น เลยยังไม่ได้ลอง แต่ก็เป็นอีกทางเลือกนึงที่น่าจะใช้ได้ครับ

ใครมีวิธี format JSON ใน Vim วิธีอื่นๆ แนะนำกันได้นะ

Sources

ใช้งาน Atom

2015-09-25T00:00:00+00:00

Atom เป็น open source text editor จาก GitHub ที่หน้าตาและการใช้งานคล้ายกับ Sublime Text มาก เพิ่งจะเปิดตัวเวอร์ชั่น 1.0 ไปเมื่อไม่กี่เดือนก่อน ซึ่งผมเองได้ลองใช้มาตั้งแต่เวอร์ชั่นแรกๆ ตอนนั้นไม่ประทับใจเลย เพราะรู้สึกว่าช้ากว่า Sublime Text เยอะอยู่พอสมควร แต่ก็ได้แต่แอบส่องเป็นระยะๆ หวังลึกๆ ว่าวันหนึ่งจะมาแทน Sublime Text ได้

ช่วงนี้ได้มาทดลองใช้งานจริงจังอีกครั้ง พบว่าความเร็วนั้นถือว่าใช้งานได้อย่างไม่ติดขัดแล้ว ผมเลยถือโอกาสทดสอบต่อเลยว่า จะมีฟีเจอร์ที่ต้องการ ใช้งานจริงจังแทน Sublime Text เลยได้หรือไม่

1. พื้นฐาน

แทบจะไม่ต้องปรับตัวอะไรจาก Sublime Text เลยก็ว่าได้ครับ

⌘ + p (หรือ ⌘ + t) เปิดไฟล์
⌘ + Shift + p เปิด command palette
⌘ + k + b (หรือ ⌘ + \) เปิด/ปิด sidebar (tree view)
มี multiple cursor (Ctrl + click)

Atom มาพร้อมกับ apm หรือ Atom Package Manager ลักษณะคล้ายกับ Package Control ใน Sublime Text แต่ผ่าน command line ครับ (หรือจะใช้ผ่าน UI ตรง settings ก็ได้เหมือนกัน) เอาไว้เพิ่ม/ลบ/อัพเดท package ได้จากสะดวกเลยทีเดียว

เปิด atom จาก terminal ได้เลย

2. `vim-mode` กับ `ex-mode`

vim-mode เป็น package ของ atom ที่จำลองเอา vim มาใส่ใน atom ซึ่งสำหรับผมถือว่าพอใช้งานได้ (ผมใช้งานเป็นแค่ฟีเจอร์พื้นฐานของ vim) แต่การที่ไม่มี visual block mode (ctrl+v) บางครั้งก็รู้สึกอืดอัดเหมือนกัน มีคนรู้สึกเหมือนกันเยอะ เลยมีคนทำ vim-mode-visual-block package มา ลงคู่กับ vim-mode ทำให้ใช้ Ctrl + v ใช้งาน visual block mode ได้ครับ

ส่วน ex-mode นั้นก็ส่วนเสริมของ vim-mode ที่ทำให้ใช้คีย์ : สำหรับ command mode ของ vim ได้

ตั้ง keymap เอง

จริงๆ ผม map แค่ตัวเดียวคือ , + e เป็น escape เพื่อออกจาก insert mode ไปหา command mode วิธีการตั้ง keymap เอง กด ⌘ + Shift + p แล้วหาคำว่า open your keymap แล้วก็ใส่แบบนี้

'body':
  ', e': 'vim-mode:activate-normal-mode'

3. UI Theme & Syntax Theme

ใช้เวลาหาอยู่นาน จนได้คู่ UI Theme ใช้ One Dark (ติดมากับ Atom) ส่วน Syntax Theme ใช้ Afterglow Monokai กับ Afterglow Plus สลับกันไป (จริงๆ ชอบ Afterglow Plus มากกว่า แต่เวลาใช้กับ One Dark UI แล้วมันมืดทึมๆ ไปหน่อย) Atom มันแปลกตรงที่ UI Theme กับ Syntax Theme สวยๆ บางอันก็ไม่ค่อยเข้ากันเท่าไหร่

Afterglow Monokai

Afterglow-Plus

ซ่อน Tab bar

ใน command palette (⌘ + Shift + p) ไม่มีคำสั่งสำหรับ toggle tab bar สำหรับซ่อน tab ทั้งหมดที่เปิดอยู่เหมือนใน Sublime Text ปกติผมไม่ได้ใช้งาน tab เลยก็จะปิดไว้ ส่วนใน Atom ต้องไปแก้ใน custom style ด้วย CSS เพื่อซ่อน tab bar เอาครับ

เปิด command palette แล้วเลือก open your stylesheet แล้วก็ใส่ CSS ให้ .tab-bar เป็น display: none

.tab-bar {
  display: none;
}

4. Packages

ผมไม่ได้ลงอะไรเยอะเท่าไหร่ แต่ package ที่จำเป็นสำหรับ Atom ที่สุดสำหรับผมน่าจะเป็น Project Manager ครับ ทำให้ save project และสลับไปมาระหว่าง project ได้เหมือน Ctrl + ⌘ + p ใน Sublime Text

พวกตระกูล Atom-linter ทั้งหลายก็แจ่มเลยทีเดียว แสดง error/warning แบบ inline ได้เลย

อื่นๆ ก็ตามนี้จ้า

$ apm list

/Users/armno/.atom/packages (17)
├── afterglow-monokai-syntax@1.3.3
├── afterglow-plus@1.6.0
├── chester-atom-syntax@0.1.1
├── editorconfig@1.2.0
├── emmet@2.3.12
├── ex-mode@0.7.0
├── highlight-line@0.11.0
├── highlight-selected@0.10.1
├── language-javascript-better@1.5.0
├── language-javascript-semantic@0.2.1
├── linter@1.6.0
├── linter-eslint@3.0.2
├── linter-jshint@1.2.0
├── project-manager@2.5.2
├── react@0.12.10
├── vim-mode@0.60.0
└── vim-mode-visual-block@0.2.13

ถ้าใครมี package อะไรเจ๋งๆ แนะนำกันหน่อยนะครับ :D

ภาษาไทย

การพิมพ์ภาษาไทยใน Atom นั้นสระไม่ลอยเหมือนใน Sublime Text ครับ เยี่ยมเลย

(ไม่ชอบใจ)

การทำงานกับ Atom Linter นั้นยังมีข้อจำกัด (อันใหญ่หลวง) คือไม่สามารถเลือก linter ของแต่ละเฉพาะ project ได้ เช่น project ที่ทำงานผมจะใช้ JSHint ส่วนที่บ้านจะใช้ ESLint แต่ Atom ไม่มีที่สำหรับตั้งค่า linter ของแต่ละ project นั่นก็คือถ้าลง JSHint มันก็จะใช้ lint กับทุก project หรือ ESLint ก็เช่นกัน (อ้างอิง linter/744)

วิธีแก้ของผมก็คือลงไว้ทั้ง 2 ตัว แล้วค่อยไป enable/disable package ใน settings ตอนสลับ project เอา ไม่สะดวกเท่าไหร่ครับ

อีกเรื่องก็คงเป็น startup time ที่ยังช้ากว่า Sublime Text อยู่พอสมควร ถ้าต้องสลับ project บ่อยๆ ก็ไม่สนุกครับ

ตอนนี้ก็พยายามใช้ Atom เป็นหลักอยู่ครับ ผมชอบตรงที่มัน open แล้วก็ release บ่อยดี พัฒนาฟีเจอร์ต่างๆ เร็วดี ส่วนใครมีเทคนิคเจ๋งๆ มาแนะนำกันหน่อยนะ Happy Coding ครับ

หูฟัง Audio-Technica ATH-M50x

2015-08-04T00:00:00+00:00

หลังจากใช้งาน Grado SR-80i มาได้ประมาณ 2 ปี ถึงเวลาที่ต้องเปลี่ยนหูฟังอันใหม่ ที่เปลี่ยนก็เพราะว่าย้ายที่นั่งกันที่ออฟฟิศ มีเสียงในที่ทำงานเยอะขึ้น แล้ว SR-80i นั้นมีเสียงลอดค่อนข้างมาก (โดยเฉพาะลอดเข้ามาตอนฟังเพลง) อีกอย่างนึงคือผมยังมีอาการเจ็บหูใบอยู่บ้างตอนใช้ SR-80i ซึ่งเป็นแบบ on ear ทับบนใบหูเป็นเวลานานๆ จนคิดว่าถึงเวลาต้องเปลี่ยนใหม่แล้วล่ะ

ลักษณะการใช้งานของผมคือฟังเพลงเป็นหลัก ฟังเกือบทุกแนวยกเว้นเพลง hip hop, แนวตึ๊บๆ กับลูกทุ่งก็ไม่ได้ฟัง .. แล้วก็มีใช้ทำเพลงใน Garageband กับอัดเสียงกีต้าร์เล่นๆ ที่บ้านด้วยครับ

หลังจากหาข้อมูลอยู่พักนึง ก็ได้หูฟัง Audio-Technica ATH-M50x เป็นหูฟังตัวล่าสุดที่ผมเลือกซื้อมาใช้ครับ ไม่เคยใช้ brand นี้มาก่อน แต่ดูจาก review ใน YouTube แล้วเสียงตอบรับค่อนข้างดี บางเจ้าถึงกับยกให้เป็นหูฟังที่ดีที่สุดในราคาไม่เกิน $200 (ประมาณ 7 พันบาท) กันเลยทีเดียว ผมเองก็ได้ไปลองฟังเสียงของ M50 (รุ่นก่อนหน้า) แล้วรู้สึกชอบด้วย ก็เลยเลือกตัวนี้ครับ

M50x ต่างจาก M50 ที่เห็นได้ชัดคือสายหูฟังให้มา 3 แบบ และถอดเปลี่ยนได้ นอกนั้นก็เป็นรายละเอียดเล็กๆ น้อยๆ

หูฟังตัวนี้ซื้อมาจากร้าน Munkonggadget.com ส่งตรงมาถึงเชียงใหม่ครับ

คุณภาพวัสดุ

Audio-Technica เป็นบริษัทสัญชาติญี่ปุ่น แต่ M50x นี้ผลิตที่ประเทศไต้หวันครับ งานประกอบดีมาก เนี้ยบดีตั้งแต่กล่องยันหูฟัง งานประกอบแน่นหนาดีมาก ไม่อยากจะอวยเลย แต่ชอบจริงๆ

ฟองน้ำครอบหูบุหนังดูดีเลยทีเดียว

สายหูฟัง 3 แบบที่ให้มานั้นก็มี

สายขด (coiled cable) ยาว 3 เมตร
สายตรง (straight cable) ยาว 3 เมตร
สายตรง ยาว 1.2 เมตร

ผมเก็บ coiled cable ไว้ใช้ที่บ้าน สายตรงยาว ไว้ใช้ประจำที่ออฟฟิศ ส่วนสายตรงสั้น เอาติดถุงไว้ เผื่อใช้กับโทรศัพท์หรือ laptop ครับ สายของ M50x มีตัวล็อกเฉพาะของ Audio-Technica เวลาใส่ต้องหมุนนิดนึงเพื่อให้เข้าล็อก ข้อดีของการหมุนล็อกนี้ก็คือไม่ต้องกลัวหลุดเวลาเสียบฟังอยู่ ส่วนข้อเสียก็คือจะใช้สายของยี่ห้ออื่นไม่ได้ครับ

ในกล่องมีตัวแปลงแจ็คจาก 3.5mm เป็น 6.3mm มาให้ด้วย ใช้ได้กับเฉพาะสายยาว 3 เมตร ส่วนสาย 1.2 เมตรนั้นใช้ไม่ได้ เพราะไม่มีเกลียวหมุน

ความสบายตอนสวมใส่

เทียบกับ SR-80i แล้วถือว่า M50x หนักกว่าพอสมควร ใส่ตอนแรกๆ ก็รู้สึกว่ามันหนัก ตอนนี้ก็เริ่มชินแล้วครับ ฟองน้ำบุหนังนั้นก็ถือว่านุ่มเลยทีเดียว ครอบหูได้ทั้งใบ (ส่วนเรื่องเจ็บใบหูนั้นหายไปเลย เพราะไม่กดหูแล้ว) ด้วยความที่เป็นหูฟังแบบปิด จะมีความร้อนสะสมบ้างเมื่อใส่นานๆ แต่ก็แค่อุ่นๆ ครับ ไม่ถึงกับร้อน พักแป๊ปเดียวก็หาย

M50x ไม่ใช่หูฟังประเภทตัดเสียงรบกวน (noise cancelling) แต่ก็สามารถป้องกันเสียงรบกวนจากภายนอกได้ค่อนข้างเยอะ (noise isolation ดีมาก) ถ้าใส่หูฟังเฉยๆ ไม่เปิดเสียงอะไรเลย จะรู้สึกเหมือนหูอื้อ เพราะว่าไม่ค่อยได้ยินเสียงตัวเอง แต่พอเปิดเพลงแล้วก็แทบจะไม่ได้ยินเสียงรบกวนจากภายนอกเลย ปกติผมก็จะเปิดเพลงไว้ตลอดเวลา ถึงแม้ไม่ได้ฟังก็ตาม เพราะถึงเวลาอยากปิดสวิตช์ noise รอบตัว ก็แค่หยิบหูฟังมาใส่หูได้เลย

เสียง

ตอนที่ซื้อ SR-80i ผม burn ก่อนใช้จริงนานมาก (500+ ชั่วโมง).. ส่วนตัวนี้ผมไม่ได้ burn ก่อนใช้งานเลย เพราะตอนออกจากล่องมา เสียงมันก็ค่อนข้างดีอยู่แล้ว .. (นี่เหมือนจะอวยอีกแล้วนะ) แกะกล่องออกมา เช็คของ แล้วก็ลองฟังเลย พบว่าเสียงมันไม่ต่างกับตัว M50 ที่ไปลองที่ร้านมาก ก็เลยไม่ burn ฟังมันทั้งยังงั้นแหละ

M50x เป็นหูฟังประเภท Studio Monitor ซึ่งหูฟังประเภทนี้มักใช้กันในห้องอัด หรือกับงานใน studio ที่ต้องการรายละเอียดของเสียง และความเที่ยงตรงเป็นหลัก ซึ่งผมชอบมากเพราะทำให้ได้ยินรายละเอียดของเครื่องดนตรีที่ไม่เคยได้ยินมาก่อนในเพลงที่ฟังอยู่ทุกวัน หรือทำให้ได้ยินดนตรีในแบบที่ใกล้เคียงกับที่นักดนตรีทำมาจริงๆ มากขึ้นกว่าเดิม

แนวเสียงจะเป็นโทนกลางๆ ไม่เน้นไปทางทุ้มหรือแหลม แต่ให้รายละเอียดเสียงดนตรี รวมไปถึงตำแหน่งการวางเครื่องดนตรีในเพลงได้ชัดเจนมาก ทำได้ดีกว่า SR-80i อยู่เยอะพอสมควร ถ้าใครชอบเสียงแนว Grado อยู่แล้ว ก็น่าจะชอบ M50x เหมือนกันครับ แต่ถ้าชอบฟังเพลงเฉพาะบางแนวเป็นพิเศษ เน้นเบส หรือเน้นเสียงแหลมอย่างใดอย่างหนึ่ง ก็ไม่แนะนำนะ

สรุป

ชอบ

วัสดุกับงานประกอบดีมาก ดูดี ที่สำคัญ แข็งแรง
ให้เสียงดนตรีกว้างอย่างแม่น้ำ amazon รายละเอียดดนตรีในเพลงมาเต็ม 7 ตู้คอนเทนเนอร์
ถอดสายได้ พับตัวหูฟังได้ เก็บในถุงง่าย
สวมใส่สบาย ใส่นานๆ ได้ ไม่เจ็บหูแล้ว

meh:

หนัก (หนักกว่า SR-80i เยอะพอสมควร)
สายหูฟังทั้ง 3 แบบ เส้นเล็กกว่า และไม่ถึกเท่าของ Grado
ขั้วล็อกสายกับหูฟังเป็นแบบเฉพาะ

ปล.

ใน YouTube มีรีวิว M50x อยู่ค่อนข้างเยอะ แต่รีวิวของ MKBHD ทำให้ผมตัดสินใจเลือก M50x ครับ
M50x มีรุ่น Limited Edition อีก 2 รุ่นคือสีน้ำตาล กับสีเขียวเข้ม สวยดี แต่แพงกว่ารุ่นปกติ
ในซีรีส์นี้ยังมีรุ่นอื่นๆ อีกตั้งแต่ M20x, M30x, M40x ไปถึง M70x ที่เพิ่งออกมาใหม่ คุณสมบัติกับราคาก็ไต่ไปตามระดับครับ

ใช้ Device Mode ใน Google Chrome ทำงานกับ Mobile Web/Hybrid App

2015-07-02T00:00:00+00:00

ใน Chrome Devtools จะมี Device Mode เป็นส่วนหนึ่งที่มีประโยชน์มากกับการทำ responsive website หรือ mobile web app หรือแม้กระทั่ง hybrid app อย่าง Cordova ก็ด้วยครับ โดยที่ Device Mode ใน Devtools ก็คือการจำลอง Google Chrome ให้เป็นเหมือน mobile device เครื่องหนึ่ง สิ่งที่จะได้ก็คือ

ขนาดหน้าจอ (ขนาด browser) ตาม device ที่เลือก
จำลอง device pixel ratio
user agent string ก็ตาม device ที่เลือก
จำลอง network condition (WiFi, 2G, 3G)
ตั้งค่า CSS Media แบบ manual ได้
จำลองค่า geolocation หรือ accelerometer ก็ได้

เท่าที่ได้ใช้งาน Device Mode มา รู้สึกได้ว่าเป็นอีกฟีเจอร์หนึ่งของ Devtools ที่ถูกให้ความสำคัญพอสมควร ได้เห็นฟีเจอร์ใหม่ของ Device Mode เพิ่มขึ้นมาเรื่อยๆ ครับ

ในโพสต์นี้ผมใช้งาน Device Mode บน Chrome Canary (45.0.2446.0) อาจจะมีหรือยังไม่มีบางฟีเจอร์ใน Chrome Beta หรือ Stable ก็ได้ครับผม

เริ่มใช้งาน Device Mode

เปิด Devtools ขึ้นมาใน Chrome (command + shift + I) แล้วคลิก icon รูปโทรศัพท์ อยู่ใกล้ๆ รูปแว่นขยาย

ก็จะได้เจอหน้าจอแบบนี้ครับ

เลือก mobile device

อันดับแรกเลย เราสามารถเลือก device จาก preset ที่มีอยู่แล้วได้ มี mobile device พื้นฐานมาให้ครบๆ ตามแต่ละ OS/platform แต่ละ device ก็จะมีขนาดหน้าจอ, device pixel ratio กับ user agent string ที่ต่างกันออกไป

นอกจากนี้เราก็ยังสามารถเพิ่ม device เข้าไปใน list ได้ด้วย โดยไปที่ Settings ใน Devtools (icon รูปเฟือง) > Devices > Add custom device …

(Canary) ถัดมาเป็นส่วน orientation ซึ่งใน canary มีตัวเลือกนี้เพิ่มเข้ามา ทำให้เราสามารถเลือกว่าจะให้ขนาดหน้าจอนั้นเป็นแนวตั้งหรือแนวนอน แถมยังเลือกได้ด้วยว่าจะให้เป็นแบบที่มี navigation bar (UI ของ browser) พร้อมทั้ง keyboard ติดมาด้วยหรือไม่ ทำให้เราเห็นภาพขนาดจริงๆ ของ viewport เวลาเว็บของเราไปอยู่บน browser ได้ด้วย

อย่างในรูปนี้ ส่วนที่เป็นขอบดำด้านบนและล่าง ก็คือ UI ของ Safari บน iOS เทียบกับ iOS Simulator แล้วถือว่า Devtools ทำได้ใกล้เคียงของจริงมาก

Network Throttling

ถือว่าเป็นอีกหนึ่ง killer feature เลยก็ว่าได้ ทำให้เราสามารถจำลองความเร็วอินเตอร์เน็ตหลายๆ แบบได้ มีประโยชน์กับการ optimize performance มากๆ เพราะทำให้ developer เห็นภาพชัดขึ้นว่า ถ้าเว็บของเราถูกโหลดผ่านความเร็วอินเตอร์เน็ตที่แตกต่างกัน สิ่งที่ user จะเห็นนั้นจะช้าหรือเร็วยังไง

สิ่งที่ผมชอบก็คือ นอกจากจะจำลองความเร็วเน็ตได้แล้ว ยังจำลอง network latency ให้ด้วย ซึ่งตรงกับสถานการณ์ที่ mobile internet นั้นมี latency สูงกว่าเน็ตธรรมดาอยู่เยอะพอสมควร

Media Queries Indicator

ถ้าในไฟล์ CSS ของเรามี media queries @media อยู่ด้วย ก็จะเห็นแถบสีสำหรับแบ่ง breakpoint ใน CSS ตามที่เราเขียนได้ด้วย

`@media` override

Device Mode ยังมีตัวเลือกอื่นๆ ให้เล่นกันอีก เช่น บางครั้งต้องเขียน CSS ให้ @media print Devtools ก็มีตัวเลือกให้ Chrome แปลงร่างเป็น printer ได้ CSS ที่มี @media print กำกับอยู่ก็จะทำงาน (เมื่อก่อนต้องกด print preview แล้วก็เดาเอา)

Sensors

ใน tab Sensors เราสามารถจำลอง touch event, geolocation กับ accelerometer ได้ ผมเองไม่ค่อยได้ใช้ส่วนนี้มาก แต่คิดว่าถ้าใครได้ทำเว็บที่ใช้ API พวกนี้บ่อยๆ น่าจะมีประโยชน์พอสมควรครับ

นั่นแหละครับท่านผู้ชม สำหรับผมแล้ว Device Mode ใน Devtools ถือว่าเป็น tool ที่ช่วยทำ responseive web/hybrid app ได้ง่ายขึ้นอีกเยอะเลย (ลดการยืดๆ หดๆ หน้าจอลงไปได้เยอะ) แต่ก็ยังมีส่วนที่ขาดหายไปอยู่ เช่น

การจำลอง CPU/GPU performance ของ mobile device นั้นยังไม่มี (mobile device นั้นช้ากว่า pc พอสมควร)
การ render font นั้นก็จะต่างจาก mobile browser อยู่แบบพอสังเกตได้ ดังนั้นจะ test แบบ pixel perfect ใน Chrome ก็คงจะไม่ได้นะ

ลองไปเล่นกันดูครับผม ใครเจอเทคนิคอะไรใน Devtools แวะมาบอกด้วยนะ

Case study: เปลี่ยนวิธีโหลด CSS เพื่อให้เว็บ render ไวขึ้น

2015-05-04T00:00:00+00:00

ผมเพิ่งเปลี่ยนธีมของ blog จาก Hyde มาเป็น Type (บังเอิญชื่อคล้ายกันด้วย) หลังจากปรับแต่งเก็บรายละเอียดแล้ว ก็ลองเช็ค performance ของ blog ดูผ่าน PageSpeed Insights ก่อน optimize score จะอยู่ที่ 73 ในหน้าแรก

ส่วนผลจาก webpagetest.org สังเกตตรง first byte อยู่ที่ 0.8 วินาที และ start render ที่ประมาณ 2 วินาที

ซึ่งยังมีส่วนให้ปรับปรุงได้อยู่ ก็เลยจับมาเป็นหนูทดลองซะเลย

สิ่งที่ PageSpeed แนะนำว่าควรปรับปรุงก็คือ มี render-blocking resources อยู่ 3 ไฟล์ ที่ถูกโหลดใน <head>

ฟอนต์ Source Sans Pro จาก Google Fonts (ผ่าน tag <link>)
FontAwesome จาก MaxCDN เพื่อใช้งาน icon font
main.css CSS หลักของธีม

Render-blocking resources?

Render-block resources คือไฟล์ JavaScript หรือ CSS ที่ browser จะต้องรอให้โหลดเสร็จก่อน ถึงจะเริ่ม render ได้ ที่เป็นแบบนี้ก็เพราะว่า ก่อนที่ browser จะสามารถ render หน้าเพจได้นั้น ก็ต่อเมื่อมันรู้ว่า

ในหน้าเพจประกอบด้วย element อะไรบ้าง (HTML, DOM construction)
และแต่ละ element มีลักษณะหน้าตายังไง วางอยู่ตรงไหนของหน้าเพจ (CSS, CSSOM construction)

อ่านเรื่อง “วิธีการทำงานของ browser” ได้จ้า

browser ทำทั้ง 2 ขั้นตอนไปพร้อมๆ กัน แต่ทั้ง 2 ขั้นตอนต้องเสร็จสมบูรณ์ก่อน ถึงจะเริ่ม render เพจได้ นั่นหมายความว่า ยิ่ง HTML หรือ CSS มีความซับซ้อนมากขึ้นเท่าไหร่ (หรือมีขนาดใหญ่ขึ้น) ก็จะทำให้เริ่ม render ได้ช้าลงไปตามนั้น

ทำไมต้องเริ่ม render เร็วๆ?

การเริ่ม render หมายถึงการที่ user เริ่มเห็นอะไรบนหน้าเพจหลังจากหน้าจอขาวๆ ธรรมดา user เห็น content ได้เร็วขึ้น ซึ่งอาจจะไม่สมบูรณ์ก็ตาม แต่อย่างน้อยการได้เห็น “อะไรบางอย่าง” บนหน้าเพจ ย่อมทำให้ user รู้สึกดีกว่าการเห็นหน้าจอขาวๆ โล่งๆ .. ไม่มีใครชอบเว็บที่โหลดช้าๆ จริงไหม

Render-blocking resource ในเคสของผมก็คือ ไฟล์ CSS ทั้ง 3 ไฟล์นั้น (ไม่มี JavaScript เพราะ ใน tag <head> ไม่มี tag <script> อยู่เลย)

1. จัดการ FontAwesome

FontAwesome เป็นชุด icon font ที่มี icon เยอะมากๆ (ณ ตอนที่เขียนนี้มี 519 icon) ธีม Type นี้ดึง FontAwesome มาจาก CDN ทั้ง set ทำให้ไฟล์มีขนาดใหญ่เกินตัว (6.5KB CSS + 55KB font) ซึ่งจริงๆ แล้ว ผมใช้แค่ประมาณ 10 icon เอง ดังนั้นผมเลยเลือกใช้ custom icon font แทนชุดเต็ม

IcoMoon เป็นเว็บแอพที่ทำให้เราสามารถ generate custom icon font ได้ ด้วยการเลือกเฉพาะ icon ที่ ต้องการ แล้วมันจะสร้าง font ที่มีเฉพาะ icon ที่เราต้องการ ทำให้ font ที่ได้มีขนาดเล็กลงมากครับ ที่สำคัญ เรายังสามารถเลือกสร้าง font จากชุด icon หลายๆ ชุดมาปนๆ กันได้ เจ๋งดี

ซึ่งแทนที่จะโหลดไฟล์ CSS ของ FontAwesome ผ่าน CDN ก็เปลี่ยนเป็นรวมไฟล์ CSS ของ icon font ไว้ในไฟล์ main.css ได้เลย (เปลี่ยนไฟล์ .css เป็น .scss แล้วไป import ในไฟล์ main.scss ของธีม)

☺ จำนวน http request ลดลง 1 request
☺ ขนาดไฟล์ของ icon font ลดลงจาก 55KB เหลือ 4.2KB (woff)

2. โหลด Google Fonts แบบ asynchronous

แทนที่การใช้ tag <link> เพื่อโหลดไฟล์ CSS จาก Google Fonts ด้วยการใช้ Web Font Loader ซึ่งใช้ JavaScript แทน ข้อดีก็คือไฟล์จะถูกโหลดเข้ามาแบบ asynchronous ทำให้ไม่ไป block การ render ของเพจ (non-blocking) ส่วนข้อเสียก็คือ ต้องมี request webfont.js เพิ่มเข้ามา อีกประมาณ 6.3KB ครับ

แทนที่ (ใน tag <head>)

<link href='http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

ด้วย

<script>
  WebFontConfig = {
    google: {
      families: [
        'Source+Sans+Pro:400,700,400italic,700italic:latin'
      ]
    }
  };
  (function() {
    var wf = document.createElement('script');
    wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
      '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
    wf.type = 'text/javascript';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
  })();
</script>

(ในหน้า quick use ของ Google Fonts มี code ข้างบนให้ครับ)

☺ CSS ของ web font ถูกโหลดเข้ามาแบบ non-blocking
☹ ต้องใช้ JavaScript

3. ใช้ `loadCss` เพื่อโหลด CSS แบบ asynchronous

หลักการเดียวกันกับ web font load คือใช้ JavaScript เพื่อดึงไฟล์ CSS เข้ามาในเพจแทนการใช้ tag <link> ด้วยการใช้ loadCss ซึ่งเป็น function ในการโหลดไฟล์ CSS แบบ asynchronous ครับ

วิธีการใช้งานก็แค่ copy & paste function loadCss ไว้ใน tag <head> ของเราเลย ขนาดของ function loadCss เล็กมากจนใส่แบบ inline ไปในเพจเลยก็ยังได้ (minify แล้วเหลือประมาณ 0.5KB)

<!-- ใน <head> -->
<script>
  function loadCSS(e,n,o,t){"use strict";var d=window.document.createElement("link"),i=n||window.document.getElementsByTagName("script")[0],s=window.document.styleSheets;return d.rel="stylesheet",d.href=e,d.media="only x",t&&(d.onload=t),i.parentNode.insertBefore(d,i),d.onloadcssdefined=function(n){for(var o,t=0;t<s.length;t++)s[t].href&&s[t].href.indexOf(e)>-1&&(o=!0);o?n():setTimeout(function(){d.onloadcssdefined(n)})},d.onloadcssdefined(function(){d.media=o||"all"}),d}
</script>

แล้วเรียก function loadCss กับไฟล์ CSS ของเรา ซึ่งก็ควรมี tag <noscript> เป็น fallback สำหรับ user ที่ไม่มี JavaScript (หรือปิดไว้) เพื่อโหลดไฟล์ CSS ด้วย tag <link> ตามปกติครับ

<!-- ใน <head> -->
<script>
  loadCSS('/css/main.css');
</script>
<noscript>
  <link rel="stylesheet" href="/css/main.css" media="all">
</noscript>

☺ CSS ถูกโหลดเข้ามาแบบ non-blocking (asynchronous)
☹ ต้องใช้ JavaScript

เท่ากับว่า ถึงตอนนี้ในเพจไม่มี render-block resource เหลืออยู่เลย เพราะทุกอย่างถูกโหลดแบบ asynchronous ซะหมด

แต่เดี๋ยวก่อน!

เนื่องจากไฟล์ main.css ถูกโหลดเข้ามาด้วย JavaScript ดังนั้นจะมีเวลาเสี้ยววินาทีที่ function loadCss ยัง ไม่ทำงาน แต่ browser เริ่ม render ไปแล้ว ทำให้เพจดูเละๆ (เพราะ ณ ตอนนั้นยังไม่มี CSS เลย) เพียงชั่วครู่ ก่อนจะถูก paint ทับด้วย CSS เมื่อ loadCss ทำงานเสร็จ เรียกเหตุการณ์นี้ว่า FOUC หรือ Flash of Unstyled Content แม้จะเพียงเสี้ยววินาที แต่ก็สังเกตเห็นได้ และดูไม่ค่อยดีต่อ user ครับ

แก้ไขได้โดยการแยกเอา CSS เฉพาะส่วนที่จำเป็นจริงๆ กับการ render ออกจากไฟล์ CSS หลัก แล้ว inline เข้าไปในเพจครับ ซึ่ง CSS ส่วนนี้เราเรียกว่าเป็น CSS ใน Critical Rendering Path จ้า

Critical Rendering Path ?

โดยปกติแล้ว content ส่วนแรกที่ user จะมองเห็นเป็นสิ่งแรกก็คือ content ที่อยู่เหนือขอบล่างของ browser เป็น content ที่มองเห็นได้โดยไม่ต้อง scroll ลงมา เราเรียก content ส่วนนี้ว่า initial view หรือ above the fold content ครับ หรือพูดง่ายๆ ก็คือ content ที่อยู่ใน viewport แรกนั่นเอง

Critial Rendering Path ตามความหมายแล้วคือ ส่วนประกอบต่างๆ ที่จำเป็นที่สุดสำหรับการ render initial view

ถ้าเป็น HTML ก็นับเฉพาะ element ที่อยู่ใน initial view
ถ้าเป็น CSS ก็นับเฉพาะ property ของ element ที่อยู่ใน initial view
ส่วน JavaScript ก็เหมือนกัน เฉพาะที่เกี่ยวข้องกับ content ใน initial view

ขนาดของ initial view นั้นก็แปรไปตามขนาดของ browser หรือ viewport ดังนั้น critical rendering path ของแต่ละ browser/viewport/device ก็ต่างกันออกไปครับ

แล้วเราจะรู้ได้ยังไงว่า CSS ส่วนไหนบ้างที่จำเป็นสำหรับ render initial view? คำตอบก็คือ ใช้ tool ช่วย generate critical CSS ออกมาจากไฟล์ CSS เต็มครับ มีตัวเลือกมากมายหลายตัวเลย

Penthouse ใช้ง่านผ่าน node module/Grunt/Gulp สามารถระบุขนาดของ viewport ที่ต้องการเอา Critical CSS ออกมาได้
Devtools Snippet รันใน Chrome Devtools ระบุขนาด viewport ไม่ได้ จะใช้ขนาด viewport ปัจจุบัน
Critical Path CSS Generator ใช้บนเว็บได้เลย ผมเลือกใช้ตัวนี้เพราะง่ายที่สุดครับ แต่ก็ระบุขนาด viewport ไม่ได้นะ

วิธีการใช้งานก็ตามที่บอกในเว็บเลย ใส่ URL ของหน้าเพจที่ต้องการ generate critical CSS พร้อมกับใส่ content ของ CSS ฉบับเต็มๆ ลงไป เจ้าเว็บนั้นก็จะดึงเอามาเฉพาะ critical CSS ให้ครับ (อย่าง CSS ของผม 9KB generate critical CSS แล้วได้ออกมา 3KB)

Critical CSS ที่ได้ออกมานั้น ก็จับใส่ tag <style> ใส่ไว้ใน <head> ของเพจเลยครับ นั่นหมายความว่า ไฟล์ HTML จะมีขนาดใหญ่ขึ้น และ CSS ที่เราใส่ไว้ใน <head> ก็จะไม่ถูก cache ไว้โดย browser เพราะฉะนั้นต้องระวังไม่ให้ critical CSS มีขนาดใหญ่เกินไปด้วยครับ

ไม่มี tool ตัวไหนที่แม่นยำ 100% ต้องลองดูหลายตัว/หลายครั้ง แล้วเปรียบเทียบผลลัพธ์ดูครับ

ผลลัพธ์

PageSpeed score เพิ่มขึ้นมาจาก 73 เป็น 94

ทดสอบกับ webpagetest.org: ถึงแม้เวลา first byte จะช้ากว่า (1 วินาที) แต่เวลาที่ start render นั้นไวกว่าก่อน optimize อยู่ที่ประมาณ 1.5 วินาที

ทดสอบกับ YSlow

ที่สำคัญคือลองโหลดเพจแล้วรู้สึกว่าเร็วขึ้นอย่างสัมผัสได้! (ถ้าไม่ได้คิดไปเองนะ) .. ถ้าใช้งานกับเว็บที่ scale ใหญ่กว่านี้ น่าจะเห็นความแตกต่างได้มากกว่านี้ด้วยครับ ลองเล่นกันดูได้ ทำง่ายๆ ได้ที่บ้าน ไม่เสียเวลาเยอะอย่างที่คิด :P

อ่านเพิ่มเติม

ลองใช้ Prezto กับ zsh

2015-03-24T00:00:00+00:00

สวัสดีชาวเนิร์ด

ปกติผมใช้ zsh คู่กับ oh-my-zsh เพื่อสร้างความบันเทิงในการใช้งาน terminal ก็ใช้งานได้ดีปกติ ไม่มีปัญหาอะไร แต่แล้ววันหนึ่งอากาศแจ่มใส ไม่รู้มีอะไรดลให้ Prezto ผ่านมาให้พบเจอ

เลยต้องลองเสียหน่อย

Prezto เป็น configuration framework ของ zsh เช่นเดียวกับ oh-my-zsh ครับ ทำให้เราเพิ่มความสามารถ/ลูกเล่นให้กับ zsh ได้มาก ไม่ว่าจะเป็น theme ของ prompt หรือ plugin (ใน Prezto จะเรียกว่า module) ซึ่งดูแล้วมากจะเป็นพวก alias มากกว่า แรกเริ่มเดิมทีนั้น Prezto นั้นเป็น fork ของ oh-my-zsh แต่เนื่องจากแนวคิดไปคนละทางกับ oh-my-zsh เลยถูก rewrite ใหม่ซะเลย (อ่านเรื่องต้นทางได้ที่ oh-my-zsh#377 ยาวมาก)

พอสรุปได้ว่า oh-my-zsh นั้นเน้นที่ความง่ายในการใช้งาน ไม่ต้อง config มากมาย เซ็ตมาให้ก่อนแล้ว ส่วน Prezto มีฟีเจอร์คล้ายๆ กับ oh-my-zsh แต่ส่วนมากจะถูก disable ไว้แล้วให้ user ไป enable เอาเองตามที่ต้องการ เรื่องความเร็วผมรู้สึกว่า Prezto เร็วกว่านิดหน่อย ทั้งตอน startup และตอนที่ autocomplete ขึ้นมาจากการกด tab

เปลี่ยนจาก oh-my-zsh ไปหา Prezto

Jerome Dalbert เขียนโพสต์ Migrate From Oh-my-zsh to Prezto ลองตามไปอ่านกันได้ครับ สำหรับผมต้องลบไฟล์ ~/.zshrc ก่อนลง Prezto ด้วย ไม่งั้น Prezto ไม่ยอมทำ symlink ให้ครับ ส่วนใครที่ยังไม่เคยลง oh-my-zsh ก็ข้ามไปลง Prezto ได้เลยครับ Installation Guide

ในขั้นตอนการลบ oh-my-zsh ออกนั้น ไม่มีอะไรพังเลย (แปลกใจอยู่เหมือนกัน) แต่ทางที่ดี backup ไว้ก่อนดีกว่าครับ (อุตส่าห์ทำใจไว้แล้วเชียวว่ามันต้องมีอะไรสักอย่างพัง และต้องซ่อมแน่ๆ แต่ไม่มีเลย)

เกี่ยวกับ Prezto

มีโครงสร้างและหลักการทำงานคล้ายๆ oh-my-zsh คือมี theme/module เก็บไว้ที่ directory ~/.zprezto
ไฟล์ config หลักของ Prezto คือ ~/.zpreztorc ลองเปิดอ่านดูได้ครับ มี comment กำกับไว้ค่อนข้างดี
Prezto ตัวมันเองก็ถูกเรียกผ่าน ~/.zshrc อีกที ในไฟล์ ~/.zshrc ก็จะเจอ code ประมาณนี้

# Source Prezto.
if [[ -s "${ZDOTDIR:-$HOME}/.zprezto/init.zsh" ]]; then
  source "${ZDOTDIR:-$HOME}/.zprezto/init.zsh"
fi

theme/module

เราสามารถใช้ command $ prompt -l เพื่อดูรายชื่อ shell theme ทั้งหมดที่ Prezto มีอยู่ได้

และยัง preview ก่อนได้ด้วย $ promt -p <theme name> ตรงนี้เจ๋งดี

เมื่อเลือก theme ได้แล้ว ก็ไปเซ็ตที่ไฟล์ ~/.zpreztorc หาคำว่า theme แล้วใส่ชื่อ theme ที่จะใช้ลงไป

# Set the prompt theme to load.
# Setting it to 'random' loads a random theme.
# Auto set to 'off' on dumb terminals.
zstyle ':prezto:module:prompt' theme 'cloud'

ส่วน module (plugin) นั้น มี default มาให้บ้างแล้ว (ในไฟล์ ~/.zpreztorc อีกเช่นกัน) ซึ่งลำดับในการเรียก module นั้นสำคัญ ถ้าเรียงผิด module นั้นก็อาจจะไม่ทำงานได้ module ที่ผมเพิ่มเข้าไปมีอีก 2 อันคือ syntax-highlighting กับ history-substring-search

`syntax-highlighting`

ตามภาพเลยครับ ทำให้มี shell command เป็นสีๆ คล้าย fish shell

`history-substring-search`

ใน terminal เราใช้ลูกศรขึ้น-ลงเพื่อเลื่อนหา command ใน history ที่เคยพิมพ์ไว้ได้ แต่ module ตัวนี้ทำให้ scope ของ history ของ command เหลือเฉพาะ keyword ที่เราพิมพ์ได้

อย่างเช่น ผมพิมพ์ vi แล้วกด ขึ้น ไปเรื่อยๆ ก็จะมี history ขึ้นมาเฉพาะ command ที่มี vi อยู่ข้างใน พร้อมกับ highlight ให้ด้วย ดีครับดี

จากที่ใช้ Prezto แทน oh-my-zsh มา ก็ยังไม่พบปัญหาอะไร และก็คงจะใช้เรื่อยๆ ไปก่อน ลองเล่นกันดูได้ครับ

ปล. zsh framework อีกตัวนึงที่น่าสนใจคือ Antigen ครับผม

Setting up Vim : Part II

2015-02-26T00:00:00+00:00

เคยเขียน Setting up Vim ตอนแรกไปแล้ว พอใช้งานไปเรื่อยๆ ผมว่ามีอะไรหลายๆ อย่างที่ปรับเปลี่ยนไปตามการใช้งาน เลยขอรวมรวม plugin/setup ที่เปลี่ยนไปจากตอนแรกมาดูครับ

ใช้งานบน OSX 10.10 เป็นหลัก เวอร์ชั่นอื่นอาจทำงานได้เหมือนกัน แต่ไม่รับประกันนะ

Pathogen → Vundle

ก่อนหน้านี้ผมใช้ Pathogen เป็นตัวจัดการ plugin ของ Vim ซึ่งปัญหาที่ผมตามมาก็คือ ตอนย้ายเครื่องไปทำงานที่เครื่องอื่น ย้าย plugin ที่ติดตั้งผ่าน Pathogen ไปด้วยยาก (Pathogen ใช้ git submodules ซึ่งไม่ค่อยสะดวกเท่าไหร่) (ความจริงคือผมไม่ค่อยเข้าใจ git submodule) ส่วนการจะ update plugin ก็ต้อง update ผ่าน submodules เช่นกัน .. เอาเป็นว่าผมแพ้ git submodules

เลยลองเปลี่ยนมาใช้ Vundle แทน Vundle ทำให้สามารถเก็บรายชื่อ plugin ไว้ในไฟล์ .vimrc ได้เลย จะเพิ่ม/ลบ/update plugin นั้นจะง่ายกว่า Pathogen มาก ทำได้ใน vim เลย

:PluginInstall
:PluginUpdate
:PluginClean

วิธีติดตั้งแบบละเอียด ดูได้จาก Quick start guide ของ Vundle ได้เลยครับ

link Vim config กับ dotfiles

ผมมี repo dotfiles ไว้เก็บ configuration ของโปรแกรมต่างๆ รวมถึง Vim ด้วย มีไฟล์ .vimrc กับโฟลเดอร์ .vim ทำให้แชร์ config ของ Vim ได้จากการทำ symlink มาที่ repo dotfiles

$ git clone https://github.com/armno/dotfiles.git ~/dotfiles
$ ln -s ~/dotfiles/.vimrc ~/.vimrc
$ ln -s ~/dotfiles/.vim ~/.vim

เวลาอัพเดท config ใน .vimrc ก็สามารถ push ไปที่ repo dotfiles เพื่ออัพเดท vim config ในเครื่องอื่นๆ ได้ด้วย

CtrlP + The Silver Searcher

CtrlP เป็น plugin ของ vim ที่ทำงานได้คล้ายกับ cmd+p (หรือ cmd+t) ใน Sublime Text ใช้เพื่อเปิดไฟล์ในโปรเจ็ค หรือจาก buffer ที่กำลังใช้อยู่ ผ่าน fuzzy search จาก path ได้ (พิมพ์แค่บางส่วนของ path) ใช้ CtrlP นั้นทำให้หา และเปิดไฟล์ได้เร็วกว่า file explorer (NERDTree) ได้เยอะเลย

แต่ fuzzy search ที่ติดมากับ CtrlP นั้น บางทีก็ช้าอยู่บ้างกับโปรเจ็คใหญ่ๆ โชคดีที่ CtrlP เราสามารถใช้ “custom command” ในการ search หาไฟล์ได้ ผมใช้ The Silver Searcher ซึ่งเร็วกว่าพอสมควร

# ในไฟล์ .vimrc
let g:ctrlp_user_command = 'ag %s -l --nocolor -g ""'

แทนที่ Powerline ด้วย Vim-airline

vim-airline เป็น plugin ที่เราเซ็ต status bar แบบฉูดฉาดเหมือน powerline ได้ แต่โหลดเร็วกว่า (และไม่ต้องลง python ด้วย) แถมยังทำงานร่วมกับ plugin ตัวอื่นๆ ของ vim ได้ดีอีกด้วย

นอกจากนี้ก็เป็น plugin อื่นๆ ที่เกี่ยวกับแต่ละภาษาที่เขียน list เต็มๆ ของผมอยู่ในไฟล์ .vimrc ครับ

ปล. ทุกวันนี้ก็ยังใช้ vim กับ sublime text สลับกันไปมา แล้วแต่ลักษณะงานครับ

git stash & git patched commit

2014-10-14T00:00:00+00:00

(สถานการณ์จำลอง)

A: (coding อย่างขะมักเขม้น)
B: “แก้ bug ตรงนี้ให้หน่อย แป๊ปเดียว” / “เพิ่ม feature นี้หน่อย ลูกค้าอยากได้”
B: เอาตอนนี้เลย
A: …

(สถานการณ์จำลอง 2)

A: (coding อย่างขะมักเขม้น)
C: (เป็น dev ด้วยกัน) “pull branch X ไป review code/run หน่อย เพิ่ง push ไป”
A: …

การมี git นั้นทำให้เราสามารถทำ snapshot ของงานส่วนที่เรากำลังทำอยู่ได้ โดยไม่ไปทำของคนอื่นพัง และงานเราไม่หายด้วย ปกติผมจะใช้ 2 command นี้ครับ

1. `git stash`

git stash ถ้าแปลตรงตัวก็แปลว่า “ซ่อน” code ของเราไว้ก่อน โดย code ที่เราซ่อนไว้จะถูกเก็บใน stash stack และทำให้ repo ของเรา clean เมื่อ stash ไว้แล้วครับ

ตัวอย่างเช่น ใน repo ของเรามี dirty file จาก git status (ข้างขวาเป็น output ของ git diff)

เราอยากซ่อน changes ของทั้ง 2 file นี้ไว้ ก็ใช้คำสั่ง git stash

$ git stash

repo ของเราก็จะกลับมา clean เหมือนเดิม โดยคำสั่ง stash จะบอก HEAD commit hash ว่า repo ของเราถูก revert ไปที่ commit ใด (ปกติก็เป็น commit ล่าสุดก่อนที่มันจะ dirty แหละ)

ถ้าเราแก้ code ไปแล้ว อยาก stash อีก ก็ทำได้ โดยที่ stash ครั้งต่อๆ ไปจะถูกเก็บใน stack เรียกดูได้จาก command git stash list

$ git stash list

เอา code ที่ stash ไว้ ออกมาจาก stack เพื่อทำงานต่อ ใช้ command git stash pop

และเนื่องจากมันเป็น stack เวลา pop มันเลยเอา stash ล่าสุดออกมาก่อน ซึ่งพอ pop ออกมาแล้ว stash นั้นก็จะหายไปจาก list ครับ (ถ้าอยาก pop แบบไม่ให้มันหาย ใช้ command git stash apply แทน)

`git stash` กับ untracked file

ปกติแล้ว git stash จะไม่เก็บไฟล์ที่ untracked ไปด้วย (ไฟล์ที่ยังไม่ได้ add ใน git)

ต้องเพิ่ม parameter -u เข้าไปด้วย ให้มัน stash ไฟล์ที่ untracked ไปด้วยครับ

พอ pop ออกมา ไฟล์ที่เป็น untracked file ก็ยังอยู่ครบเหมือนเดิม

workflow คร่าวๆ ก็คือ stash งานของเราไว้ก่อน > ทำส่วนอื่นให้เสร็จ > push งานใหม่ไป > pop stash ออกมาทำต่อ ประมาณนี้ครับ

2. `git add/commit -p`

--patch หรือ -p เป็น parameter ของ command git add และ git commit ทำให้เราสามารถเลือก add หรือ commit เฉพาะบางส่วนของ code ที่เราแก้ไขไปแล้ว โดย code ส่วนที่เหลือ ก็ยังคงเป็นสถานะ modified (unstaged) อยู่

ตัวอย่างเช่น ผมมีไฟล์ index.html ที่อัพเดท code ไปบางส่วนแล้ว รัน git diff แล้วได้ออกมาแบบนี้

รัน git add -p index.html git จะแบ่ง code ออกเป็นส่วนย่อยๆ (hunks) แล้วให้เรารีวิวว่า จะเลือกทำอะไรกับ hunk นั้นๆ รูปข้างล่างนี้จะเห็นว่ามี prompt ให้มาให้เราเลือก ซึ่งตัวเลือกก็มี y n q a d / j J g e และก็ ? ซึ่งเราสามารถเลือก ? แล้วกด enter เพื่อดูความหมายของแต่ละตัวเลือกได้ (ผมเองก็ไม่เคยจะจำได้เหมือนกัน)

ที่ผมใช้บ่อยๆ ก็จะมี

y หรือ yes เพื่อ add hunk นี้เข้า staged zone
n หรือ no ยังไม่ add hunk นี้
q หรือ quit ออกจาก interactive mode (หยุดการทำงานของ git add -p)
s หรือ split ซอย hunk นี้ให้เล็กลงกว่าเดิม

ตัวเลือก s นั้นมีประโยชน์มาก เนื่องจากปกติแล้ว git จะแบ่ง code ออกเป็น hunk ให้เอง โดยที่ code ที่อยู่ใกล้ๆ กันรวมเป็น hunk เดียวกัน ซึ่งจริงๆ แล้ว code ที่อยู่ใกล้กันนั้นอาจจะเป็นคนละส่วนกันก็ได้ (จริงๆ แล้ววิธีการแบ่ง hunk ของ git นั้นมีหลักเกณฑ์มากกว่านี้ แต่ขอข้ามไปละกันครับ ผมเองไม่ได้เข้าใจทั้งหมดเหมือนกัน)

อย่างตอนนี้ผม add เฉพาะ hunk แรก พอรัน git status ก็จะเห็นสถานะทั้ง staged และ modified (unstaged) จากไฟล์เดียวกัน

ซึ่งพอ commit ไปแล้ว code ส่วนยังเหลือ ก็ยังอยู่ในสถานะ modified (unstaged) เหมือนเดิม

สรุป

git stash เอาไว้ซ่อน modified code และทำให้ repo ของเรากลับมา clean เทียบจาก commit ล่าสุด
git stash pop เรียก code ที่ stash ไว้ล่าสุดออกมา
git add(commit) -p add หรือ commit ทีละส่วนของ code แบบ interactive

ในชีวิตประจำวัน ผมจะใช้ git add -p เกือบทุกครั้ง หลักๆ เพื่อเลือก add/commit เฉพาะเท่าที่จำเป็น กรองเอา code ขยะออก และได้โบนัสเป็นการ review code ที่ตัวเองเขียนไปในตัวด้วย ส่วน git stash นั้น นานๆ จะได้ใช้ทีนึงครับ

Armno

zsh syntax highlighter

ใช้งานกับ oh-my-zsh

วิธีการทำงานของ web browser

1. การสร้าง DOM กับ CSSOM

Tokenization (Lexical Analysis)

Parsing (Syntactic Analysis)

DOM & CSSOM Tree construction

2. สร้าง Render Tree

3. Layout

4. Paint

Sources / อ่านเพิ่ม

จัดโค้ด JSON ใน Vim

วิธีที่ 1: ใช้ json.tool ใน Python

วิธีที่ 2: ใช้ json Node module

3. ใช้ sourcebeautify.vim

Sources

ใช้งาน Atom

1. พื้นฐาน

2. vim-mode กับ ex-mode

ตั้ง keymap เอง

3. UI Theme & Syntax Theme

ซ่อน Tab bar

4. Packages

ภาษาไทย

(ไม่ชอบใจ)

หูฟัง Audio-Technica ATH-M50x

คุณภาพวัสดุ

ความสบายตอนสวมใส่

เสียง

สรุป

ใช้ Device Mode ใน Google Chrome ทำงานกับ Mobile Web/Hybrid App

เริ่มใช้งาน Device Mode

เลือก mobile device

Network Throttling

Media Queries Indicator

@media override

Sensors

Case study: เปลี่ยนวิธีโหลด CSS เพื่อให้เว็บ render ไวขึ้น

Render-blocking resources?

ทำไมต้องเริ่ม render เร็วๆ?

1. จัดการ FontAwesome

2. โหลด Google Fonts แบบ asynchronous

3. ใช้ loadCss เพื่อโหลด CSS แบบ asynchronous

Critical Rendering Path ?

ผลลัพธ์

อ่านเพิ่มเติม

ลองใช้ Prezto กับ zsh

เปลี่ยนจาก oh-my-zsh ไปหา Prezto

เกี่ยวกับ Prezto

theme/module

syntax-highlighting

history-substring-search

Setting up Vim : Part II

Pathogen → Vundle

link Vim config กับ dotfiles

CtrlP + The Silver Searcher

แทนที่ Powerline ด้วย Vim-airline

git stash & git patched commit

1. git stash

git stash กับ untracked file

2. git add/commit -p

สรุป

ใช้งานกับ `oh-my-zsh`

วิธีที่ 1: ใช้ `json.tool` ใน Python

วิธีที่ 2: ใช้ `json` Node module

3. ใช้ `sourcebeautify.vim`

2. `vim-mode` กับ `ex-mode`

`@media` override

3. ใช้ `loadCss` เพื่อโหลด CSS แบบ asynchronous

`syntax-highlighting`

`history-substring-search`

1. `git stash`

`git stash` กับ untracked file

2. `git add/commit -p`