เปรียบเทียบค่าครองชีพระหว่าง Munich และ Singapore

ผมมีความคิดเรื่องการย้ายที่อยู่อาศัยในระยะยาวมาสักพักใหญ่ๆว่าที่ไหนดีที่น่าจะเหมาะกับเราและเราก็เหมาะกับที่นั่นมากที่สุด ทั้งในเรื่องของโอกาสการร่วมพัฒนาเมืองและพัฒนาตนเองรวมถึงการสร้างครอบครัว ระบบการศึกษา ระบบขนส่งมวลชนต่างๆ ที่เราไม่ต้องใช้รถก็เดินทางได้ (ผมมองว่ามันเป็นภาระ) และปัจจัยอื่นๆอีกนิดหน่อย เลยลองมาลิสเมืองที่เคยไปอยู่มาหลายๆที่ แล้วเริ่มทำการให้คะแนน ซึ่งจริงๆผมก็ได้ที่ที่อยากจะไปอย่างแน่นอนแล้ว เพราะรู้สึกชอบเมืองนี้มากๆ ผู้คนเป็นมิตร บรรยากาศดี และมันรู้สึกใช่ แล้วเลยลองมาดูในส่วนของค่าครองชีพสำหรับ 2 เมืองที่ดูไว้หลักๆ จากบัญชีรายรับรายจ่ายประจำวัน จากตอนแรกคิดไว้ว่าใช้ชีวิตอยู่ในเมือง München ที่ค่อนข้างถูกบังคับรูปแบบการใช้ชีวิตนิดหน่อยตรงที่ว่าห้าง ร้านค้า ปิดเร็วมาก และวันอาทิตย์ร้านค้าทั่วๆไปก็จะปิด เราก็จะไม่ได้ใช้จ่ายในวันนั้นๆเลย แต่ลองๆคิดดูแล้วมันก็หนักอยู่เมื่อเปรียบเทียบกับค่าเงินไทย แต่มันก็จะแฟร์มากถ้าเรารับเงินเดือนที่นั่น แต่หากสำหรับคนไทยที่จะเตรียมไปอยู่ ไปเรียน ไม่มีรายได้จากงาน full-time แล้วมาวางแผนดูว่าควรจะเตรียมเงินไว้ประมาณเท่าไหร่บ้าง อาจจะได้ประโยชน์จากโพสต์นี้ เดี๋ยวลองมาดูบัญชีผมคร่าวๆ
เพิ่มเติม: สำหรับประเทศในยุโรปประเทศอื่นๆก็พอจะสามารถใช้อ้างอิงจากที่ München ได้นะครับ เพราะตอนที่เคยไปอยู่ Madrid และ San Sebastían ที่สเปนมา ในระยะสั้นๆหากการใช้ชีวิตเป็นสไตล์ชอบซื้อของมาทำกินเอง รวมๆแล้วค่าครองชีพก็พอๆกันครับ

สกุลเงิน
สิงคโปร์ ใช้สกุล Dollar Singapore (SGD) S$ 1 เท่ากับประมาณ 25 บาท บวก/ลบ 2 โดยประมาณ
มิวนิค ใช้สกุลเงิน EURO โดย EUR 1 เท่ากับประมาณ 43 บาท บวก/ลบ 2 โดยประมาณ

ที่พัก
München: ค่าเช่าห้องพักประมาณ EUR 300~600 ต่อเดือน แล้วแต่โซนที่อยู่อาศัยและสภาพ แต่ range ก็จะประมาณนี้แหละครับ
Singapore: ค่าเช่าห้องก็ประมาณ SGD 600~800 ต่อเดือน แล้วแต่โซนและสภาพเช่นกัน

ค่ากิน
ผมว่าสำหรับค่ากินเนี่ย มันขึ้นอยู่กับจริตของคนเลยนะว่าจะถูกจะแพงยังไง สำหรับผมช่วงที่อยู่ยุโรปผมจะเน้นการซื้อของมาทำเองที่บ้าน มันจะถูกมาก ยกตัวอย่าง ทั้งวันกินปกติก็ไม่เกิน EUR 10 ครับ หรือบางทีก็แค่ EUR 5 ผมเฉลี่ยไว้ที่ EUR 7 ต่อวันแล้วกันครับ ไว้ลองมาดูบัญชีคร่าวๆครับ แล้วลองตีเป็นรายเดือนดู

บัญชีรายจ่ายของที่มิวนิคครับ

ส่วนหนึ่งของบัญชีรายจ่ายที่มิวนิค
ส่วนหนึ่งของบัญชีรายจ่ายที่มิวนิค

สำหรับช่วงนี้เป็นช่วงที่กินแบบปกติจริงๆ แบบที่ไม่ได้เดินทางไปไหนเลยครับ ทำงาน-กลับบ้าน ซื้อของมากินจากร้านแถวๆบ้านแถวๆออฟฟิศแค่นั้น จะสังเกตว่าไม่มีค่าใช้จ่ายในการเดินทางเพราะผมเดินไป-กลับจากบ้านและออฟฟิศได้ ระยะทางห่างกันประมาณ 2 km ครับ เดินสบายๆ ที่เห็น Edeka Heinz นั่นคือชื่อร้านค้าครับ หลักๆผมจะซื้อพวกพาสต้า มักโรนี พิซซ่า กับน้ำผลไม้มากินที่บ้านครับ กินไม่เคยเบื่อเลย และก็ค่อนข้างประหยัดมากครับ

มาดูบัญชีรายจ่ายของที่สิงคโปร์บ้าง

ส่วนหนึ่งของบัญชีรายจ่ายที่สิงคโปร์
ส่วนหนึ่งของบัญชีรายจ่ายที่สิงคโปร์

สำหรับที่สิงคโปร์จะมีค่าเดินทางมาด้วย เพราะบ้านกับออฟฟิศไม่ได้ใกล้กัน แต่ก็ไม่ถือว่าไกลมากครับ ผมเช่าห้องไว้ที่ Tempines ส่วนออฟฟิศอยู่ใกล้ๆกับ Tai Seng MRT ก็จะต้องมีค่าเดินทางบ้าง แต่ก็ไม่เยอะ จะเห็นว่ารวมๆแล้วก็ดูจะไม่สูงครับ แต่มันแค่ช่วงนี้แหละครับ ผมเลือกมา
เพราะจริงๆแล้ววัฒนธรรมของคนสิงคโปร์ก็แนวๆคนเอเชียเรานี่แหละครับ มีนัดกินกันบ่อย ปาร์ตี้บ่อย พวกนี้จะทำให้มีรายจ่ายที่สูงขึ้นเกินกว่าปกติเข้ามา แต่ส่วนที่เยอรมันไม่ค่อยมีครับ ชีวิตแต่ละคนจะค่อนข้าง Individual มากกว่า จะมีไปปาร์ตี้กันบ้างแต่จำนวนน้อยกว่ามากครับ ที่ไปบ่อยๆก็มีนัดคนไทยด้วยกันนี่แหละครับ ;p

ลองมาคิดค่ากินกันคร่าวๆ
München: EUR 7 = ประมาณ 310 บาท (ราคานี้คือไม่เข้าร้านอาหารเลยนะครับ ทำกินเองทุกมื้อ)
Singapore: SGD 15 = ประมาณ 390 บาท (ราคาที่กินที่ร้านอาหารตามตึกออฟฟิศครับ)

ลองมาสรุปดูแบบคร่าวๆนะครับ

ค่าที่พัก (ต่อเดือน)
München: EUR 400 แปลงเป็นเงินไทยได้ประมาณ 17,900 บาท
Singapore: SGD 750 แปลงเป็นเงินไทยได้ประมาณ 19,540 บาท

ค่ากิน
München: EUR 7 * 30 = 210 แปลงเป็นเงินไทยได้ประมาณ 9,385 บาท
Singapore: SGD 15 * 30 = 450 แปลงเป็นเงินไทยได้ประมาณ 11,700 บาท

รวมค่าที่พักและค่ากินเป็นเงินไทย
München: 17,900 + 9,385 = 27,285 บาท
Singapore: 19,540 + 11,700 = 31,240 บาท

เหมือน München จะถูกกว่านะครับ
สำหรับค่ากินล้วนๆ
ใน München ต่ำสุด ผมใช้ไป EUR 180 ไม่รู้อยู่ไปได้ยังไง ฮาๆ ผมทดลองการใช้ชีวิตแบบสมถะที่สุดอยู่ 1 เดือนครับ ความบ้าส่วนตัว แต่โดยปกติ เดือนอื่นๆจะอยู่ราวๆ EUR 800~1100 ครับ แฮ่ๆ
ส่วนใน Singapore ต่ำสุด SGD 425 ครับ ไม่รู้อยู่ไปได้ยังไงอีกเหมือนกัน
ก็ดูจะเป็นไปตามการคำนวณคร่าวๆครับ แต่มันจะลำบากเกินไป ถ้าใช้ชีวิตปกติๆ ของสิงคโปร์จะอยู่ที่ประมาณ SGD 1,700 ครับ คือชิวๆ แบบรวมค่าที่พัก SGD 750 ไปแล้วด้วย

หากจะสรุปฟันธงไปเลย ถ้าใช้ชีวิตไม่พิศดารไปมาก
อยู่ München ควรจะต้องมีเงินอย่างต่ำๆ 40,000 บาท ต่อเดือน ถึงจะพอดิ้นได้ครับ
ส่วนถ้าอยู่ Singapore ควรจะมีเงินอย่างต่ำประมาณ 40,000 บาท ต่อเดือนเท่ากัน เอ๊ะยังไง ฮาๆ คือมันอย่างต่ำอ่ะครับ แบบนี้คือแทบจะไม่เหลือเงินเก็บ และใช้จ่ายต้องคิดนิดหน่อย แต่ถ้าสบายๆก็ควรจะ 60,000 บาท ต่อเดือนขึ้นไปก็จะอยู่ในสถานะชิวแล้วครับ

Note เอาไว้หน่อยนะครับ หากอยู่ในยุโรป สำหรับผมค่าใช้จ่ายส่วนมากที่เด้งๆออกมาเลยจะเป็นค่าการท่องเที่ยวครับ มันเดินไปไปไหนมาไหนได้ง่าย สะดวก นั่งรถไฟข้ามประเทศกันสบายๆ อยากไปสวิซ ออสเตรีย ฮังการี บลาๆๆ ก็นั่งเครื่องบิน นั่งรถไฟ ไปเที่ยวได้ใกล้ๆ ผมชอบ Backpack ครับ จะหมดกับค่าพวกนี้ไปเยอะ แต่ส่วนสิงคโปร์ก็.. นึกอะไรไม่ออกก็บินกลับมาเที่ยวไทยครับ

: )

จัดการงานเร่งด่วนด้วย MVP #leanstartup

Minimum Viable Product (MVP) อาจจะคุ้นๆกันหากใครได้อ่านหนังสือเกี่ยวกับ Lean Startup

TheLeanStartup

TheStartupOwner

เรื่องอื่นอย่างหลักการพื้นฐาน พวก loop “Build -> Measure -> Learn” อะไรพวกนี้ไม่ขอพูดถึงเลยนะครับ ในโพสต์นี้จะเน้นไปที่ MVP ที่โดนมากๆเลยในตอนนี้ ทำให้นึกถึงบีม ที่เคย Hangout แก๊งๆเราพูดเกี่ยวกับ Lean Startup

ในตอนนี้ทีมของเรา (Treebuild) ได้เริ่มรับงานมาแล้วและมันก็เริ่มมากขึ้นเรื่อยๆ ทำให้ช่วงนี้งานมันมีมากกว่า 1 ไปเยอะ และเรายังต้องพัฒนาโปรดักซ์ตัวหลักของเราอยู่ด้วย สำหรับการทำงานในฝั่งที่เป็น Outsource สิ่งที่ดูจะ Lean ที่สุดแล้วคิดว่าเวิร์คมากที่สุดคงหนีเรื่อง MVP และ CD/CI ไม่พ้น

Minimum Viable Product และ Continuous Deployment เป็นสิ่งสำคัญมาก เพราะมันเป็นการเช็คว่าเราเข้าใจกับสิ่งที่เขาต้องการไหม กับตัว Product Owner (PO) ก็จะได้รู้ว่าที่เขาต้องการมันเป็นแบบนี้หรือเปล่า เราก็พยายามที่จะผสมพวก Scrum, Agile มาใช้บ้างให้เหมาะสมที่สุด ซึ่งในตอนนี้เราคิดว่าเราทำได้ค่อนข้างดีแล้ว และจะดีขึ้นไปเรื่อยๆ (รวมถึงพยายามลดงานด้าน Outsource ไปและผุดโปรเจกต์ Saas ขึ้นมา ฮาๆๆ)

MVP

Lo-Fidelity ผมสรุปเอาง่ายๆมันเหมือนกับการสร้าง Rapid Prototype ซึ่งใช้เวลาไม่นาน ยกตัวอย่างถ้าเป็นการทำเว็บไซต์ ก็เหมือนการขึ้น Mockup มาก่อน ให้เห็นหน้าตาในแต่ละหน้า ว่าจะมี I/O ยังไงบ้าง เพื่อมาตรวจสอบความถูกต้องกับ PO ได้อย่างสม่ำเสมอ เมื่อผ่านทั้งหมดแล้วถึงขยับไปทำ Hi-Fidelity ต่อ การทำแบบนี้จะช่วยลดระยะเวลาจากเปลี่ยนแปลงที่อาจจะเกิดขึ้นได้ เพราะโอกาสในการแก้ ปรับเปลี่ยนจะน้อยลง (การแก้ไขในช่วงที่ยังเป็น Mockup หรือยังเป็นแค่ View มันย่อมดีกว่าช่วงที่ลงไปในระดับที่มีการทำฝั่ง Model กบ Controller อยู่แล้ว)

ต้องขอบคุณบีมครับ ที่ช่วยมาเน้นย้ำเรื่อง Lean ให้ในคืนนั้นของพวกเรา Hahahaha

อะไรคือ MDS Process ที่กิน CPU ราบเรียบบน Mac OS

วันนี้ผมรู้สึกแปลกใจว่าทำไมอยู่ๆเครื่องก็ช้าจนทำงานทำการอะไรไม่ได้เลย ลาก cursor ยังกระตุก
สงสัยเลยเปิดดู Activity Monitor เลยได้คำตอบว่า Process ไหนคือตัวปัญหา

mds, mds_stores, mds_worker
mds, mds_stores, mds_worker

เลยต้องมาหาต่อว่า mds_stores นี่มันคืออะไร
ทราบมาได้ว่า MDS ย่อมาจาก “Metadata Server” ครับ และ MDS นี่เป็น Process หนึ่งของ Spotlight บน Mac OS ที่มีไว้ค้นหาข้อมูล, ไฟล์ บนเครื่อง Mac OS นั่นเอง
และการ Process นี้ของ MDS คือการทำ Indexing ครับ ซึ่งหากไปกดที่รูปแว่นขยาย (Spotlight) บนมุมขวาบนของจอขณะที่ทำ Indexing อยู่ จะแสดงระยะเวลาการ Process ครับ ว่าจะใช้เวลาอีกประมาณเท่าไหร่

MDS Indexing Process
MDS Indexing Process

ซึ่งการทำ Indexing ข้อมูลในเครื่องเราแบบนี้ไม่ใช่เรื่องผิดปกติอะไร ไม่มีอะไรต้องตกใจครับ (เพียงแต่ว่าวันนี้มันมาทำผิดเวลาไปหน่อย งานกำลังเร่ง)
ถ้าหากว่าเราต้องการให้หยุด Process สามารถทำได้ที่ Activity Monitor แล้วกด “Quit Process” ได้เลยครับ
แล้วถ้าต้องการให้ทำ Index ต่อสามารถเปิด Terminal แล้วใช้คำสั่ง
sudo mdutil -E /

แต่ถ้าหากว่าไม่ได้ใช้งาน Spotlight เลยสามารถที่จะปิดการทำงานหรือ Disable ได้โดยเปิด Terminal และใช้คำสั่ง
sudo mdutil -a -i off
แต่ถ้าต้องการจะเปิดคืนก็ใช้คำสั่งเดิม แต่เปลี่ยนจาก off เป็น on คือ
sudo mdutil -a -i on

โดยระยะเวลาของการทำ Indexing ก็ขึ้นอยู่กับขนาดของไฟล์ในเครื่องของเราครับ ระยะเวลาประมาณ 15-45 นาทีโดยประมาณครับ

สัมผัสผิวกาย HAML ครั้งแรก | HAML 1st Time

ช่วงนี้กำลังคลั่งไคล้การ Optimization การทำให้ประสิทธิภาพของเว็บดีที่สุดเท่าที่จะเป็นไปได้ และการทำงานยังไงให้มันได้เร็วที่สุดด้วย
สำหรับ CSS เราก็มี CSS Preprocessor ไม่ว่าจะเป็น LESS หรือ SASS มาช่วยแล้ว ซึ่งมันก็สามารถคอมไพล์และ config บอกมันให้ออกมาในรูปแบบ Compressed เลยได้ และรูปแบบการเขียนก็ง่าย สะดวกขึ้นมาก ส่วน JavaScript ก็มี CoffeeScript เข้ามาย่อยได้ (แต่เรายังไม่ได้ใช้)
แล้วกับ HTML ล่ะ?

เราคิดอยู่นานว่าจะยังคงรักษารูปแบบการเขียนเว็บให้เป็นไปตามมาตรฐานตาม W3C ไหม เพราะทีมของเราเคยคิดกันอยู่ว่าจะไปเขียน CoffeeScript แทนการเขียน JavaScript ปกติไหม แต่ก็ยับยั้งกันว่าไว้ว่ารอเขียน JavaScript จนรู้สึกว่าอยู่ในระดับเทวดาแล้วถึงค่อยไป CoffeeScript กัน เพราะหากยังไม่แน่นจริงเราก็เกรงว่าจะเสีย Syntax แบบเดิมไป

แต่ HTML นี่เราคบกับเขามานานจนคุ้นเคยมากแล้ว แค่มองตาก็รู้ใจ แล้วเราจะทำยังไงกับเขาดี เพราะ CSS เราก็เลือกใช้ SASS ไปแล้ว
เมื่อคืนผมเลยให้เวลาออกเดทกับ HAML ดู
เราใช้เวลาจ้องตากันประมาณ 10 นาที ก็รู้สึกว่าเราเริ่มคุ้นเคยกันแล้ว เลยชวนเขาเข้ามาบ้าน

เริ่มจาก

gem install haml

ปรากฏว่าเกิดปัญหา ลงไม่ได้ เหมือนว่าหา Package ไม่เจอหรืออะไร รู้แต่หัวผมมันมึนๆเช้าใกล้สว่าง เลยจัดให้เอาด้วย

ruby -S gem install haml
ruby -S gem install haml
ruby -S gem install haml

พอเช็ค

gem list

ดูแล้วมีของมาแน่ๆแล้วเลยเริ่มต้นถูกเนื้อต้องตัวกันจริงๆ อ่ะแจ๊ะ อ่ะแจ๊ะ

HAML FIRST TIME
หลังจากได้ทำการติดตั้ง HAML มาแล้ว เราก็มาดู Option ที่ HAML ให้มาว่ามีอะไรบ้าง
โดยใช้คำสั่ง -h หรือ --help

haml -h

ถ้ากดดูก็จะเห็นว่า มี options มากมายให้ใช้กัน
สำหรับผมที่ได้ใช้บ่อยๆคงจะเป็น -t ugly ที่จะช่วยเอา Whitespace ออกให้
ส่วนการ Compile ปกติจะใช้คำสั่งแบบนี้ครับ

haml input.haml output.html

จะเขียน HAML ยังไงวะ ใช้คำฟุ่มเฟือยอยู่ได้?!

วิธีง่ายๆ เรามาลองเปรียบเทียบ HTML กับ HAML กันก่อน
ตามธรรมเนียมที่ใครไม่รู้เป็นคนเริ่ม เรามาดู Hello World นี้กัน

HTML

<strong class="code" id="message">Hello, World!</strong>

HAML

%strong{:class => "code", :id => "message"} Hello, World!

พอเห็นความแตกต่างคร่าวๆไหมครับ?
ใน HAML จะใช้เครื่องหมาย Percent (%) นำหน้าชื่อ tag เพื่อเป็นการประกาศ tag ครับ เช่น %strong, %div, %body, %html แบบนี้ครับ สะดวกและง่ายดายใช่ไหมครับ?
ส่วนสำหรับการประกาศ Class และ ID ดูแบบนั้นอาจจะดูพิมพ์เยอะเกินไป มีวิธีที่สั้นกว่านั้นอีกครับ คือ

HAML

%strong.code#message Hello, World!

สามารถเขียนต่อกันแบบนี้ได้เลย
และถ้าอยากสั้นกว่านั้นอีก โดยที่ tag นั้นคือ div หรือที่ควรประกาศว่า %div ก็สามารถละทิ้งมันไปได้เลยครับ เพราะทางผู้พัฒนา HAML นี้เห็นว่า tag div นี่มัน common มากๆ เราก็จะสามารถเขียนแบบนี้ได้เลย

HAML

.content Hello, World!

เขียน Class ลงไปดื้อๆแบบนี้ ไม่รู้จะสั้นไปไหน
แล้วทีนี้เรามาลองดู code ตัวอย่างที่มันยาวกว่านั้นอีกหน่อย

HAML

!!! 5 
/ Comment
.container
  %header.haeder-container
    %h1 Hassadee Pimsuwan
  %section.section-container
    %h2 Section
  %footer.footer-container
    %p Copyright 2014 Hassadee Pimsuwan

เมื่อคอมไพล์ออกมา ผลลัพธ์ที่ได้คือ

HTML

<!DOCTYPE html>
<!-- Comment -->
<div class='container'>
  <header class='haeder-container'>
    <h1>Hassadee Pimsuwan</h1>
  </header>
  <section class='section-container'>
    <h2>Section</h2>
  </section>
  <footer class='footer-container'>
    <p>Copyright 2014 Hassadee Pimsuwan</p>
  </footer>
</div>

เริ่มรู้สึกว่ามันง่ายขึ้นแล้วใช่ไหมครับ ถ้าไม่ก็.. ตอบๆไปเองว่าง่ายเถอะ 5555
สำหรับ Tutorial เริ่มต้นของทาง HAML เลยสามารถเข้าไปได้ที่: HAML Tutorial
และ Reference Document ของ HAML สามารถเข้าไปได้ที่: HAML Reference Document

การเขียน CSS สำหรับเว็บที่เขียนด้วย HTML5 (CSS Standards v.2)

สำหรับ Basic CSS Standards ที่เคยเขียนไปใน CSS Coding Standards (ภาษาไทย) เป็นแบบขั้นพื้นฐานจริงๆที่กล่าวถึงในเรื่องการเขียน CSS ยังไงให้อ่านง่าย (Readability), สื่อความหมาย (Semantics) ซึ่งมีผลกับเรื่องการทำ SEO ด้วย, รวมถึงในเรื่องของการนำกลับมาใช้ใหม่ (Reusability) ส่วนสำหรับโพสต์นี้เราจะมาเข้าเรื่องพื้นฐานอีกเหมือนกัน แต่รวมถึงการใช้ CSS สำหรับ HTML5 ด้วย ซึ่งอาจมีความเข้าใจที่ไม่ค่อยถูกต้องนักอยู่จากที่เคยได้ยินมาจากเพื่อนๆมา และจากการอ่าน Writing the best CSS when building with HTML5 ที่เขียนโดย Todd Motto เลยคิดว่าเราควรจะมาเขียนสรุปให้ลึกลงไปมากกว่าเรื่อง Standard อีกหน่อย

เริ่มกันที่ HTML แบบธรรมดาเดิมๆก่อน
หลักการใช้ HTML กับ CSS หลักๆคือการทำให้มันไม่มีเงื่อนไขมากนักครับ อย่างเช่นเรื่อง Nested การทำให้มันไม่ไปติดเงื่อนไขกับการใช้ HTML เดี๋ยวเรามาลองดูตัวอย่างของการเขียนโครงสร้าง HTML ที่พอจะมีโอกาสเขียน CSS เป็นแบบ Nested กันได้มากๆเลยคือ Ordered list และ Unordered list

<ul>
    <li>
        <a href="#">Link</a>
    </li>
    <li>
        <a href="#">Link</a>
    </li>
</ul>

แล้วเวลาเราจะเขียน CSS เราจะทำยังไงครับ? มันมีโอกาสที่จะมีการเขียนเป็นแบบใช้ HTML element เป็น selector ได้ อย่างเช่น

ul {}
ul li {}
ul li a {}

การเขียนแบบนี้ จะทำให้เรายึดรูปแบบตาม HTML แบบนี้ไปโดยสิ้นเชิงและที่สำคัญคือสไตล์นี้มันจะเหมือนกันหมดทั้ง Document และเปลี่ยนรูปแบบไปจากนี้ไม่ได้

ซึ่งที่ควรทำคือการใช้ Class แทนครับ

<ul class="nav">
    <li class="nav-item">
        <a href="#">Link</a>
    </li>
    <li class="nav-item">
        <a href="#">Link</a>
    </li>
</ul>

พอเป็นรูปแบบนี้ เราก็จะสามารถเขียน CSS แบบที่สามารถ Reuse ได้แล้ว

.nav {}
.nav-item {}
.nav-item a {}

ลองนึกภาพดูนะครับ ถ้าเขียน CSS selector ที่ชี้ไปที่ Class แล้ว ถ้าเราอยากใส่ Style แบบ Class นั้นๆที่ไหนเราก็สามารถเขียนชื่อ Class นั้นลงไปใน HTML element ที่ต้องการได้เลย ตอนนี้มันมี Reuseability มากขึ้น และหลีกเลี่ยงรูปแบบ Nested มาได้ในระดับดีแล้วครับ

HTML5
มาถึงเรื่อง HTML5 และ Elements ใหม่ๆที่มีมาให้ใช้ ซึ่งอาจเกิดความเข้าใจผิดในการใช้งานมันได้ เท่าที่ผมเคยได้ยินมาคือมีบาง Blog เขียนไปว่า "เราไม่ต้องมาประกาศ Div เยอะๆเหมือนเดิมแล้วและเวลาเขียน CSS ก็ไม่ต้องเขียน Class หรือ ID ไปใส่ใน Div จำนวนมากแล้ว ชี้ไปที่ Header, Section, Footer, ... ได้เลย" ซึ่งมันไม่ใช่วิธีที่ดีเท่าไหร่นักน่ะครับ จะว่าไม่ควรเลยก็ได้ครับ เพราะมันก็ไปชี้ที่ Elements อยู่ดี ยกตัวอย่างเช่น

<header>
    <!-- Content -->
</header>

และลองมาดูถึงหลักการใช้งานของ HTML5 เมื่อศึกษาจาก HTML5 Reference และ HTML5 Structural Elements อย่างเป็นทางการของ World Wide Web Consortium (W3C) แล้ว จะทราบว่า Header, Section, Article, Nav, Footer elements ทั้งหลายเหล่านี้ สามารถใช้ซ้ำใน document เดียวกันได้ เพราะฉะนั้นแล้ว การเขียน CSS ที่ชี้ไปยังตัว HTML element เลยนั้น เป็นสิ่งที่ไม่ควรจะทำครับ เพื่อรักษาคุณสมบัติในเรื่อง reusability ของ CSS ไว้ อย่างการเขียน CSS แบบนี้ ไม่ควรทำครับ

header {}
section {}
footer {}

ควรหลีกเลี่ยงการใช้ HTML element เป็น CSS selector ครับ เรียกได้ว่าเป็นสิ่งที่ควรระลึกถึงตอนเขียน CSS เป็นหลักเลย
ควรใช้ class มาแทนเหมือนตัวอย่างก่อนหน้านี้ครับ เพราะ header นั้นสามารถอยู่ใน article ก็ได้ อยู่ใน section ก็ได้ หรือรวมถึงอยู่นอกสุด เป็น header ของหน้าเว็บนั้นก็ได้ สิ่งที่เขียนใน CSS ก็จะแตกต่างกันออกไปครับ ควรใช้ class แทนจะดีกว่าครับ

หลีกเลี่ยงการสร้าง Selector แบบมีเงื่อนไข
อย่างเช่น

ul.nav
div#logo
footer.footer-container

สิ่งเหล่านี้มันจะลด scalability ของเราไปครับ รวมถึงมีผลทำให้ performance ต่ำลงไปด้วยเนื่องจากทำให้เบราว์เซอร์ต้องตรวจสอบเงื่อนไขก่อนจากที่ตรวจสอบเพียง class เฉยๆ

และจากตัวอย่างข้างบน จะเห็นว่ามีการใช้ ID ชื่อ logo หรือ #logo ใน CSS นั้น กล่าวคือ มันไม่ได้ผิดอะไรที่จะเขียน CSS โดยใช้ selector เป็น ID ครับ แต่เราจะใช้มันอีกไม่ได้เลยในหน้าเดียวกัน เพราะ document หนึ่งๆจะสามารถมี ID ที่ชื่อนั้นๆได้เพียง 1 ที่เท่านั้น ความเห็นส่วนตัวผมเลยคือไม่แนะนำครับ ถึงมันจะเฉพาะเจาะจงอย่างไรก็ตาม สไตล์การเขียนของผมคือใน CSS จะใช้ class เท่านั้น และใช้ ID เท่าที่จำเป็น ส่วนใหญ่แล้วจะใช้ ID กับ JavaScript ครับ แต่ก็แล้วแต่ผู้เขียนจะเห็นสมควรครับว่าจะใช้มันอย่างไร

สรุป
เมื่อรวมเรื่อง CSS Coding Standards (ภาษาไทย) กับโพสต์นี้เข้าไปจะสังเกตได้ว่าเรื่องที่เน้นคือ

1. Readability:
เรื่องนี้ควรจะทำกับทุก programming language ครับ เคยมีอาจารย์ท่านหนึ่งบอกกับผมว่า เวลาเราเขียนโปรแกรมคนเดียว จะมีเพียง 2 คนที่รู้โค้ดเราว่ามันทำงานยังไง แต่พอนานๆวันเข้าจะเหลือเพียงคนเดียว คือ พระเจ้า ฮ่าๆๆ คือเราเองก็อาจจะลืมโค้ดที่เราเขียนไปได้ครับ ทำอย่างไรให้อ่านง่ายที่สุด มีการ comment ไว้ว่า บรรทัดนี้, function นี้, ตัวแปรนี้ หรืออื่นๆที่จำเป็นนั้น มันทำงานอย่างไร
และในเรื่องการเขียนให้มันเป็น Multiple-line สำหรับ CSS ในโพสต์ v.1 บางท่านอาจจะกังวลว่า comment ยาวๆ เขียนโค้ดเคาะบรรทัดไป มันจะทำให้ไฟล์ใหญ่ขึ้น โหลดได้ช้าลง เรื่องพวกนี้จะหมดกังวลไป เนื่องจากเราสามารถ compile และ minify มันได้ครับ สำหรับ CSS สามารถใช้ CSS Pre-processor อย่าง LESS หรือ SASS ในการทำงานนี้ได้ ซึ่งจะกล่าวถึงถัดไปอีกในโพสต์ต่อไปครับ ถ้ายังไม่ทราบว่ามันคืออะไรและอยากรู้เลย ผมแนะนำให้ศึกษา SASS ได้เลยครับ มันมีตัวช่วยให้เราเขียน CSS ได้สะดวกขึ้นมาก แต่เรื่อง Standard ของมันเราควรจะเข้าใจก่อนนะครับ เหมือนเขียน JavaScript แล้วจะไปเขียน Coffee Script ถ้ายังไม่เข้าใจ JavaScript เพียงพอ ผมก็จะยังไม่แนะนำให้ไปเขียน Coffee Script เลย

2. Semantics:
เหมือนกับ Readability ครับ ทำให้มันสื่อความหมาย class นี่คืออะไร, ตัวแปรนี้ชื่ออะไร ทำอะไร ไม่ต้องใช้อะไรประหลาดมากจนตัวเองไม่เข้าใจว่ามันคืออะไรครับ

3. Reusability:
เรื่องนี้ถือเป็นจุดเด่นเลยที่ถ้าทำได้ ออกแบบดีดีแล้ว มันจะทำให้ performance ดีมาก ไฟล์เบาลง และมี Scalability ที่ดีครับ

4. Nested:
หลีกเลี่ยงการเขียน CSS selector ที่เป็น nested ลากต่อกันยาวๆ และหลีกเลี่ยงการใช้เงื่อนไขและรูปแบบที่ strict กับ CSS ครับ มันจะทำให้ใช้งานยากขึ้น

5. ท่าไม้ตายที่ไว้หักล้างทุกสิ่ง !important Rule ฮ่าๆๆๆ (เสียงตัวโกง):
!important; ท่านี้ถ้าเคยเขียน CSS คงเข้าใจครับ มันมีระดับ priority สูงที่สุดของ CSS แล้ว ระดับ priority ไล่ตามลำดับตามนี้
!important > Inline CSS > Internal CSS > External CSS และ
ID selector > Class selector > Attribute selector
และลำดับความสำคัญจะมากขึ้นตามความซ้อนกันของ Selector ยกตัวอย่างเช่น

.header {
    font-size: 18px;
}
.header p {
    font-size: 20px;
}

ในรูปแบบนี้ขนาดฟอนต์ที่อยู่ใน header Class จะมีขนาด 18px แต่ถ้าอยู่ใน p ที่อยู่ใน header Class ขนาดฟอนต์ของ p นั้นจะมีขนาด 20px ครับ อะไรประมาณนี้ ว่าง่ายๆคือถ้ามันยิ่งชี้เฉพาะมากขึ้น ค่า priority ตัวนั้นๆก็จะสูงมากขึ้น และมันก็จะซับซ้อนมากขึ้น ถึงได้กล่าวไปว่าควรหลีกเลี่ยงรูปแบบ Nested และเงื่อนไข เพราะงานมันจะยากขึ้นและ maintenance ได้ยากขึ้นด้วย

แต่ส่วน !important Rule นี่เขาป๋าสุด ถ้าเจอเข้าไปนี่ Value ใน Property ของ Selector นั้นๆจะเป็นค่าของตาม !important นั้นทันที สรุปหลีกเลี่ยงการใช้มันให้มากที่สุดครับ ไม่งั้นอาจเกิดปัญหาภายหลังได้ ยิ่งถ้างานใหญ่ๆและนักพัฒนาหลายคนแล้วอาจปวดหัวได้ครับ อันนี้ประสบการณ์ตรงเลย สำหรับการใช้งาน !important คือ
1. เอาไว้แก้งานด่วน
2. การทดสอบอะไรบางอย่าง ยกตัวอย่างเช่น JavaScript หลายๆตัวชอบไปใส่ Style แบบ Inline Style ใน HTML elements เลย ที่เห็นบ่อยๆจะเป็นพวกทำ Slide เนี่ย เราอาจจะใช้ !important มาช่วยตอนทดลองได้ครับ
แค่จำไว้ว่ามัน Overide ทุกอย่าง จงใช้อย่างระมัดระวังและเก็บให้พ้นมือเด็กครับ ;p