Test Double

วันนี้ได้อ่านบทความที่เกี่ยวกับการทำ test และได้รู้คำใหม่ๆ เช่น Test Double ที่ใช้เรียก class ที่ใช้ในการกันส่วนที่ไม่เกี่ยวข้องกับส่วนที่ต้องการทดสอบออกไป ซึ่ง Test Double มีหลายตัว คือ

Dummy <-- and="" fake="" mock="" p="" spy="" stub="">
ที่เขียนแบบนี้เพราะมีบทความจาก Robert C. Martin ที่บอกว่า Mock เป็นประเภทหนึ่งของ Spy และ Spy เป็นประเภทหนึ่งของ Stub และ Stub เป็นประเภทหนึ่งของ Dummy แต่ว่า Fake เป็นประเภทที่แตกต่างออกไป (ทั้งนี้ควรจะอ่านบทความควบคู่ไปด้วย เพื่อความเข้าใจมากขึั้น มิฉะนั้น อาจจะเข้าใจผิดได้ เช่น ถึงแม้ Stub จะเป็นประเภทหนึ่งของ Dummy แต่ว่าการใช้ในการทดสอบก็ต่างกัน เพราะว่า Dummy มักใช้เป็น parameter ในการส่งเข้า method แต่ว่า Stub เราใช้แทน class เพื่อให้ทำงานบางวัตถุประสงค์)

ทั้งนี้จากบทความเอง ก็ช่วยให้เรารู้ว่าโดยปกติการเขียน unit test เค้ามักจะใช้ Stub กับ Spy ส่วน Dummy ใช้น้อยมาก และจะใช้ Mock น้อยมากๆ เนื่องจาก syntax ในการเขียนที่ดูยุ่งๆ ของ Mocking Tools (ตามบทความนะจ๊ะ แต่เราก็รู้สึกแบบนั้น)

ก็ถือเป็นการเปิดหูเปิดตาในการทำ Unit Test อย่างมาก

Reference:
The Little Mocker

.Net Unit Test Framework

พอดีเพิ่งได้มีโอกาสมาลองศึกษา .Net และต้องศึกษาเฉพาะส่วน unit test โดยเฉพาะ และได้ลอง search ดู ซึ่งในเวป Microsoft ทำไว้ค่อยข้างดีทำตามได้เลย แต่ก็ขอสรุปสั้นๆ ให้เข้าใจดังนี้

1. การจะสร้าง Unit Test ใน .Net จะเป็นลักษณะสร้างเป็นโปรเจ็คต่างหากใน solution เดียวกัน โดยเลือก template เป็น Unit Test Project ซึ่งตัวอย่างของ Microsoft ก็จะสร้างเป็น C# แล้วเลือกไปเมนูที่ Test ตอนสร้างโปรเจ็ค (ซึ่งเข้าใจว่าไม่จำเป็นที่จะต้องแยกเป็นคนละโปรเจ็ค เพียงแต่จะต้องใส่ using Microsoft.VisualStudio.TestTools.UnitTesting; เพื่ออ้างอิงถึง library ที่ต้องใช้ในการทดสอบ แต่ที่แยกเป็นคนละโปรเจ็ค เพื่อแยกส่วนที่จะเป็นตัวโปรแกรมจริงๆ ออกจากส่วนทดสอบ)

2. แล้วเลือก Add Reference... เป็นโปรเจ็คที่ต้องการจะทดสอบ

3. สร้าง class ใหม่ สำหรับเป็น unit test ซึ่งจะต้องใส่ attribute [TestClass] และ [TestMethod] ไว้ที่ class และ method ที่ต้องการให้ run เพื่อทดสอบ

4. ส่วนการ run test ให้ใช้ Test Explorer ในการ run จากเมนู TEST > Windows > Test Explorer

ตัวอย่างของ class ที่ใช้ทดสอบ

// unit test code
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace BankTests
{
    [TestClass]
    public class BankAccountTests
    {
        [TestMethod]
        public void TestMethod1()
        {
        }
    }
}

นอกจากนั้นยังสามารถใส่ attribute อื่นๆ ได้อีก เช่น [ExpectedException(typeof(ArgumentOutOfRangeException))] ดังนี้

//unit test method
[TestMethod]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange()
{
    // arrange
    double beginningBalance = 11.99;
    double debitAmount = -100.00;
    BankAccount account = new BankAccount("Mr. Bryan Walton", beginningBalance);

    // act
    account.Debit(debitAmount);

    // assert is handled by ExpectedException
}

Reference:
Walkthrough: Creating and Running Unit Tests for Managed Code Using Microsoft.VisualStudio.TestTools.UnitTesting Members in Unit Tests
Using the Assert Classes
Anatomy of a Unit Test

การกำหนดรหัสผ่านสำหรับ Postgres ด้วยไฟล์

คงไม่ค่อยได้มีคนไทยใช้ Postgres มากนัก เพราะส่วนใหญ่คงใช้ MySQL กัน แต่ก็นานาจิตตัง เอาเป็นว่าใครใช้แล้วมีปัญหาต้องการใช้ password แบบไม่ต้องพิมพ์ เช่นต้องการใช้ pg_dump หรือคำสั่งอย่างอื่นผ่านทางโปรแกรม ทำเป็นระบบอัตโนมัติ แต่ไอ้คำส่งพวก psql หรือ pg_dump ดันจะต้องเด้งขึ้นมาให้ใส่ password ก็มีวิธีแก้กัน ก็คือกำหนด password ไว้ในไฟล์

โดย Windows กำหนดไว้ในไฟล์ %APPDATA%\postgresql\pgpass.conf โดยรูปแบบก็จะเป็น

hostname:port:database:username:password

ตัวอย่าง

localhost:5432:anydb:backupuser:password

ดูเหมือนไม่ค่อยมีอะไรเน้อะ แต่ไอ้ความไม่มีอะไรนี่แหละทำพิษ เพราะว่าในตอนท้ายบรรทัด คุณจะต้องใส่ enter ให้มันขึ้นบรรทัดใหม่ไปด้วย มิฉะนั้น มันจะไม่รับรู้ คือเหมือนหา password ไม่เจอซะดื้อๆ หาอยู่ครึ่งวัน จมน้ำครึ่งแข้ง เซ็ง

Reference
The Password File

Google Takeout

ใช้ผลิตภัณฑ์ของพี่ Google เค้าหลายตัว ก็เพิ่งจะรู้ว่า Google เค้ามี Takeout ด้วย ซึ่งเป็นตัว backup เนื้อหาหลายอย่างที่เราใส่เข้าไป ไม่ว่าจะเป็น Messenger, Hangout, Photos, Youtube หรือแม้กระทั่งหน้า Google+ เจ้าตัว Takeout ก็สามารถ backup ได้หมด แต่จะได้ฟอร์แมตไหนต้องลองไปศึกษากันดูนะค่ะ

ส่วนตัวรู้สึกว่าเอ่อ มันใช้งานง่ายดี ลอง backup รูปมาก็โอเคเลย แบบว่าวางใจเก็บ backup รูปไว้ที่ Google+ โดยไม่ต้องกังวล จะเอารูปเข้าก็ backup อัตโนมัติจากมือถือก็ได้ หรือว่าจะ ใช้ Google+ Auto Backup จากเดสต์ทอปก็ได้ ตอนจะเอาออกก็ใช้ตัว Takeout นี่แหละ ที่นี่ก็ไม่ต้องห่วงทั้ง import, export แล้วล่ะ

Agile: an Alternative Software Development

ไปอบรมมาค่ะ เรื่อง Agile: an Alternative Software Development ได้ความรู้อีกเยอะ และเคยเขียนถึง Agile ไว้น้อยนึงตอนที่ไปงาน Thailand SPIN 2012 แล้วก็ไม่ได้เคยเขียนถึงอีกเลย เพราะเห็นว่ามีอยู่เยอะแยะแล้วตามเน็ต ทั้ง Agile Manifesto ทั้ง 4 ข้อ และ Agile Principle 12 ข้อ

ซึ่งแม้หัวข้ออบรมจะเป็นเรื่อง Agile แต่ practice ที่ทำให้ workshop เป็น Scrum ก็เลยได้ Scrum มาด้วย จึงขอสรุป scrum แบบสั้นสุดๆ ไว้ เนื่องจากคงยังไม่มีโอกาสได้ใช้อีกนาน เอาไว้ระลึกในภายหลังละกันค่ะ

โดยทฤษฎี Scrum จะทำให้เกิด
- Transparency ทำให้เกิดความโปร่งใส ไม่ใช่แค่ทำให้เกิดความยุติธรรมนะค่ะ ตามที่เราเข้าใจความโปร่งใสจะทำให้เกิดความคล่องตัว รู้ว่าใครทำอะไรอยู่ สถานะงานอยู่สถานะไหน ทำให้เกิดการแก้ไขความล่าช้า หรือปัญหาที่เกิดได้อย่างรวดเร็ว
- Inspection ทำให้มีการตรวจสอบงานกับเป้าหมายได้ง่าย เห็นว่างานที่ทำตรงกับเป้าหมายที่ลูกค้าต้องการหรือเปล่า มีการตรวจสอบปัญหา และอุปสรรคเป็นระยะๆ
- Adaptation ทำให้ทีมได้ปรับตัวได้รวดเร็ว ถ้ามีข้อผิดพลาด ก็จะผิดพลาดแค่เพียงเล็กน้อย สามารถแก้ไขได้รวดเร็ว

Scrum team ประกอบด้วย 3 กลุ่มบทบาท
1. Product owner 1 คน เป็นตัวแทนทางธุรกิจของสินค้านั้นๆ เป็นคนกำหนดว่าอะไรที่ทำให้เกิดกำไร อะไรสำคัญกว่าอะไร ซึ่งสิ่งที่ PO หรือ Product owner ทำกับ Product backlog โดยการจัดลำดับความสำคัญ, แบ่งขนาดของ item (หรือ user story), ประเมินขนาดของแต่ละ story เรียกว่า Backlog grooming
2. Development team 3 - 9 คน ถ้าน้อยไป อาจจะมีปัญหาเรื่องทักษะ, ความรู้ ในการทำงานให้สำเร็จ ถ้ามากไป จะทำให้เกิดปัญหาเรื่องการสื่อสารไม่ทั่วถึง และความซับซ้อนในการจัดการคน ลักษณะของคนในทีมมีดังนี้

Self-organizing team
Cross-functional team
No titles
No sub-team

3. Scrum master 1 คน เป็นคนดูแลให้มีการนำ Scrum มาใช้ตามวัตถุประสงค์ที่ถูกต้อง สร้างความเข้าใจในการทำกิจกรรมของ Scrum

Scrum Artifact
1. Product backlog

Feature - มาจาก Product owner
Technical work - เป็นงานดูแล Infrastructure ทั้งหมด งานส่วนนี้จะมาจาก Development team
Bug - มาจาก Product owner หรือ Development team
Knowledge acquisition - เป็นงานในการศึกษาหาความรู้ เพื่อให้สามารถทำงานให้สำเร็จ ซึ่งมาจาก Development team

2. Sprint backlog

เป็นส่วนหนึ่งของ Product backlog ที่จะต้องทำให้เสร็จในแต่ละรอบการทำงาน ซึ่งเป็นงานที่ มีรายละเอียดชัดเจนพอที่ Development team จะนำไปทำได้

Scrum Events
การทำงานในแบบ Scrum จะแบ่งออกเป็นรอบเล็กๆ เพื่อให้ได้งานที่เสร็จสมบูรณ์เป็นชิ้นเล็กๆ (Potentially shippable product) โดย 1 รอบจะเรียกว่า 1 Sprint ซึ่งในแต่ละ Sprint จะเป็นเวลาเท่าๆ กัน (time-box) เป็นการจำกัดเวลาในแต่ละรอบ และประกอบไปด้วยกิจกรรมต่างๆ ที่กำหนดเป็น time-box เช่นเดียวกัน ดังนี้
1. Sprint planning ใช้ 8 ชั่วโมงสำหรับ Sprint ที่ยาว 1 เดือน

Part 1 - What can be done this Sprint? ซึ่ง Development team จะประชุมร่วมกับ Product owner เป็นส่วนที่ต้องตกลงกันว่าอะไรควรจะต้องทำก่อน เพราะอะไร อะไรมีความสำคัญกว่าอะไร
Part 2 - How will the chosen work get done? เป็นการประชุมภายในของ Development team เพื่อทำ Work break down จากงานใน Part 1 ซึ่งมาจะสามารถประเมินงานแต่ละชิ้นได้หลายวิธี แต่จะต้องให้ทั้งทีมประเมินร่วมกัน และเห็นชอบร่วมกัน ซึ่งวิธีหนึ่งที่นิยมทำกันก็คือ Planning poker

2. Daily scrum เป็นการประชุมทุกวัน วันละ 15 นาที โดยหัวข้อการประชุมคือ

What did I do yesterday?
What will I do today?
Do I see any impediment?

3. Sprint review ใช้เวลา 4 ชั่วโมงสำหรับ Sprint ที่ยาว 1 เดือน ประชุมร่วมกันระหว่าง Development team, Product owner และ Stakeholders ทั้งหมด เพื่อนำเสนองานที่ได้ทำมา ตอบคำถามจาก Stakeholders รับฟังความเห็น แจ้งปัญหาและอุปสรรค แจ้งความต้องการความช่วยเหลือหรือสนับสนุน

4. Sprint retrospective ใช้เวลา 3 ชั่วโมงสำหรับ Sprint ที่ยาว 1 เดือน เป็นการให้โอกาส Development team ได้ตรวจสอบตัวเอง สร้างแผนในการพัฒนาทีม และเป็นการเพิ่มคุณภาพให้กับทีมโดยปรับข้อกำหนดของ "Done" (definition of "Done") โดยจะประชุมกันคือ Good, Bad, Try และผลของการประชุม ก็คือใน Sprint ถัดไป ทีมจะปรับปรุงอะไร

จากรูปน่าจะชัดเจนที่สุดนะค่ะ

Reference:
Agile Manifesto
Agile Principle
Art of Project Management
Scrum Guide

TPSE 2013

Thailand Practical Software Engineering เป็นอีกหนึ่งงานจากทาง SPIN ค่ะ งานนี้ไปโดยไม่ค่อยหวังอะไร เพราะดูจาก agenda แล้วคล้ายๆ กับ Thailand SPIN 2013 มากๆ ทั้ง speaker แล้วก็หัวข้อ แต่ก็คิดว่าลองไปฟัง keynote speaker จาก NASA ดู แต่ก็ได้อะไรกลับมาพอสมควร

โดยงานนี้ แบ่งเป็น 2 วัน วันแรก มี keynote speaker ที่น่าสนใจ คือ Firouz Naderi ซึ่งมาเล่าประสบการณ์จากการบริหารโครงการที่ NASA ให้ฟัง สรุปนะค่ะเค้ามีวิธี 3 ขั้นตอนในการทำให้โครงการประสบความสำเร็จ คือ

get best people, mold them in team เรื่องนี้เค้าให้ระวังเรื่อง "chemistry" ในทีมด้วย แม้ว่าจะได้คนเก่งมา แต่ถ้าไม่เข้ากับทีม ก็มีปัญหา แต่ PM จะต้องเป็นคนทำยังไงก็ได้เพื่อให้คนในทีมเข้ากันให้ได้
motivate team เค้าเน้นว่าเรื่องนี้สำคัญมาก เพราะเมื่อคนเราทำงานไประยะหนึ่งในโครงการก็จะมีช่วงจังหวะที่ล้า PM จะต้องเป็นคนที่ทำให้ทีมมีพลัง
share success ง่ายๆ ก็คือ "ไม่ได้เอาดีใส่ตัว เอาชั่วใส่คนที่เหลือ"

นอกจากนี้ก็ยังมีประเด็นอื่นๆ ด้วย แต่ที่จับใจความได้ (คือภาษาอังกฤษไม่แข็งแรงค่ะ) คือ don't afraid to fail. เพราะทุกโครงการมีความเสี่ยง และไม่เคยมีข้อมูลเพียงพอสำหรับการตัดสินใจ ณ.เวลานั้น อยู่ที่ PM เลยว่าจะตัดสินใจยังไง แต่ทั้งนี้ทั้งนั้นสิ่งที่เลวร้ายที่สุดก็คือการไม่ตัดสินใจอะไรเลย (The worst is not making decision. In complex project, there is no enough information to make the decision.)

หลังจากนั้นตอนบ่าย ก็ไปฟัง "Robot Framework: Generic test automation framework for acceptance testing and acceptance test-driven development (ATDD)" ซึ่ง"เป็นการพูดถึง tools ชื่อ Robot ซึ่งจะช่วยในการทำ automated test ซึ่งโดย concept แล้วดีทั้งนั้นค่ะ การที่มี TDD ก็ดีอยู่แล้ว ATDD ก็ยิ่งดีขึ้นไปอีก แต่ถ้าจะใช้จริงๆ คงต้องศึกษาเพิ่มเติมอีกเยอะเลย

และ session สุดท้ายของวันแรกที่เข้าฟัง ก็คือ "Practical UX First step" ซึ่งเปิดโลกของเราสำหรับ UX เลย เพราะว่าไม่เคยได้ศึกษา หรือว่าอ่านเรื่องนี้มาก่อน ไว้จะเขียนลงไว้อีกครั้งหนึ่งค่ะ

สำหรับวันที่สอง เนื่องด้วยสะดุดปัญหาหลายอย่าง เลยอดไปฟัง keynote speaker ตอนเช้าที่มาจาก ThoughtWorks และ session เช้าทั้งหมด ไปฟังอีกทีตอนบ่ายเลย ซึ่งเราก็เข้าไปฟัง "Agile in Enterprise: the missing pieces" ซึ่งทำให้ได้ความรู้ในอีกมุมของการใช้และปัญหาของ scrum สำหรับองค์กรใหญ่ๆ แต่อาจจะไม่ค่อยเข้ากับเราเท่าไร เพราะก็ยังไม่คิดว่าจะได้เป็นคนเอามาใช้ หรือผลักดันให้ใช้อ่ะนะ คือไม่ได้อยู่ใน position นั้น และ session สุดท้ายที่ได้ฟังก็คือ "Lean/Kanban – Going beyond Scrum" อันหลังจะเข้ากับจริตมากกว่า เพราะว่ากฎน้อย ทำตามได้ง่าย ยืดหยุ่นกว่า แต่กฎที่น้อยนี่เองก็จะอาจจะเป็นทั้งจุดอ่อนและจุดแข็งในคราวเดียวกัน สำหรับการนำมาปฏิบัตสำหรับคนทั้งกลุ่มที่ยังไม่เคยรู้จัก agile การมีกฎดูจะทำให้ทำตามได้ง่ายกว่า แต่เมื่อรู้และเข้าใจกฎแล้ว การใช้ Kanban ดูจะช่วยให้อะไรๆ ง่ายขึ้น และปรับแต่งให้เข้ากับแต่ละที่ และสถานะการณ์ได้ง่ายกว่า

Reference:
http://www.tpseconf.org
Lean/Kanban – Going beyond Scrum

First UX ใน mind

ที่เขียนหัวข้อแบบนี้ เพราะว่ายังไม่ได้ศึกษา UX สักเท่าไร เพียงแต่ได้ยินมาจากงาน TPSE ก็เลยอยากจะบันทึกไว้ เผื่อจะได้ประโยชน์ในภายหน้า ถูกผิดอย่างไรของรับไว้ผู้เดียว ไม่เกี่ยวกับ speaker ค่ะ

"Practical UX First step" เป็น session สุดท้ายของงาน TPSE ที่ได้ไปร่วมมา ซึ่งสำหรับเราถือเป็นการเปิดโลกของ UX เป็นครั้งแรก เพราะว่าเป็นครั้งแรกที่ได้ทำความเข้าใจกับ UX จริงๆ โดยมี workshop แสนสั้นมาให้ลองทำกัน อันแรกเป็นการพูดถึงซอฟต์แวร์ แต่ละประเภทว่าจะมีลักษณะใดตามรูป

โดยซอฟต์แวร์ที่อยู่ในแต่ละ quadrant จะมีลักษณะที่ต่างกัน

จริงจัง+เครื่องมือ เป็นซอฟต์แวร์ประเภทที่ผู้ใช้เข้ามาใช้งาน ต้องการทำงานให้เสร็จ เช่น Email ซอฟต์แวร์ประเภทนี้ไม่ต้องเน้นความสวย แต่ควรจะเน้นเรื่องประสิทธิภาพ ทำให้ผู้ใช้สามารถทำงานได้เสร็จได้โดยเร็ว
สนุกสนาน+เครื่องมือ จะเป็นพวก home use เช่นซอฟต์แวร์การจดค่าใช้จ่ายรายวัน ซอฟต์แวร์ประเภทนี้ควรจะต้องเน้นความสวยงาม เพราะผู้ใช้มีเวลาในการใช้งานมาก ไม่รีบ ไม่ต้องเน้นประสิทธิภาพ
สนุกสนาน+เครื่องเล่น เช่น ซอฟต์แวร์เกมส์
จริงจัง+เครื่องเล่น เช่น Youtube เอาไว้ดูกีฬา ผู้ใช้จะจริงจังกับ content ภายใน แต่ไม่ได้สนใจตัวซอฟต์แวร์ที่เป็นตัวผ่าน content ดังนั้นซอฟต์แวร์ประเภทนี้ไม่ต้องเน้นสวย แต่ควรจะทำให้ผู้ใช้สามารถเข้าถึง content ได้เร็วๆ
ผู้ช่วย หรือซอฟต์แวร์ประเภทที่อยู่ตรงกลาง คือมีลักษณะกลางๆ เช่น ซอฟต์แวร์หน้าเดียว เช่นไฟฉาย, รายงานอากาศ, พยากรณ์อากาศ, เข็มทิศ

โดยซอฟต์แวร์ตัวหนึ่งๆ อาจจะวางไว้ตรงไหนก็ได้อยู่ที่ผู้ผลิตซอฟต์แวร์อยากจะมองกลุ่มตลาดไหน

ส่วน workshop อีกอันหนึ่ง จะเป็นการให้ความสำคัญกับ non-functional เช่น high performance, responsive, elegant, attractive, easy to use, adaptive, compatible, mobile, accessibility กับซอฟต์แวร์แต่ละประเภท เช่น เกมส์, home use, business, ซอฟต์แวร์สำหรับเด็ก, อื่นๆ

ซึ่งทั้งนี้ในการออกแบบ UX จะขั้นตอนอยู่ โดยการทำ workshop ร่วมกัน เพื่อค้นหากลุ่มเป้าหมาย และ feature ของซอฟต์แวร์ที่ต้องการจริงๆ โดยมีการตั้งเป็น persona คือลักษณะที่ชัดเจนของกลุ่มเป้าหมาย เพื่อให้การพัฒนาซอฟต์แวร์ได้ออกมาตรงกับกลุ่มเป้าหมายจริงๆ โดยซอฟต์แวร์ที่ผลิตออกมาควรจะต้องทำให้ผู้ใช้ในกลุ่มร่วมของ first mover และ market target ใช้ให้ได้ แม้ว่าจะเป็นจำนวนน้อย แต่ถ้ามีผู้ใช้ในกลุ่มนี้เข้ามาใช้ ก็จะทำให้เกิดการบอกต่อ และขยายฐานผู้ใช้ของซอฟต์แวร์ออกไปได้

ที่ได้ฟังมาก็จับใจความได้เท่านี้ ด้วยปัญญาอันน้อยนิด ผิดถูกอย่างไร แล้วแต่ท่านจะพิจารณากันต่อไปค่ะ

.Net กับ Java

เนื่องจากเป็นคนที่มีพื้นฐานเดิมเป็น Java เวลาต้องมาเรียนภาษาใหม่ ก็เลยอดที่จะเทียบไม่ได้ เพื่อให้ตัวเองได้เรียนรู้และเข้าใจได้เร็วขึ้น และเลยอยากจะเขียนไว้เผื่อใครจะเจอสถานการณ์เดียวกันค่ะ

C#.Net	Java
namespace	package
using ซึ่งสามารถเขียนเป็น alias ได้ด้วย using MessageSource = Microsoft.CSharp.Introduction.HelloMessage;	import
is	instanceof
base	super
สามารถ pass value-type parameter (หรือ primitive type ใน Java) by reference ได้ using System; class Test { static void Swap(ref int a, ref int b) { int t = a; a = b; b = t; } static void Main() { int x = 1; int y = 2; Console.WriteLine("pre: x = {0}, y = {1}", x, y); Swap(ref x, ref y); Console.WriteLine("post: x = {0}, y = {1}", x, y); } }	ไม่มีการ pass primitive type by reference
มีการรับ output ทาง parameter ซึ่งสามารถมีได้มากกว่า 1 ตัว (ซึ่งจะคล้ายๆ กับการ pass parameter by reference เพียงแต่ไม่จำเป็นต้อง initialize ค่าตัวแปรที่เป็น output static void Divide(int a, int b, out int result, out int remainder) { result = a / b; remainder = a % b; }	เนื่องจากไม่มีการ pass primitive type parameter by reference ดังนั้นการส่งค่า output ทำได้ทางเดียวคือ return ค่ากลับมาซึ่งส่งได้ตัวเดียว การ return กลับมาสามารถส่งกลับมาเป็น Object ก็ได้
สร้าง modifier ที่ต่างกันสำหรับ get กับ set ไม่ได้ เช่น public get กับ private set ไม่ได้ private string caption; public string Caption { get { return caption; } set { caption = value; } }	private string caption; public string getCaption() { return caption; } private void setCaption(String caption) { this.caption = caption; }
การ override จะต้องกำหนดเป็น virtual method ก่อน และ overriding method จะต้องใส่ override ไว้ด้วย มิฉะนั้นจะถือว่าเป็น method ใหม่ที่ไม่ได้ override ของเดิมมา แต่ในกรณีนี้ compiler จะขึ้น warning แต่ถ้าไม่อยากให้ขึ้น warning และเป็น method ใหม่ที่ไม่ได้ override มา จะต้องใส่ new แทน override class Class1 { public virtual void Test() { Console.WriteLine("test in class1"); } } class Class2 : Class1 { public override void Test() { Console.WriteLine("test from class2"); } }	class Class1 { public void test() { System.out.println("test in class1"); } } class Class2 extends Class1 { public void test() { System.out.println("test in class2");
การแปลง String เป็น Enum public enum CarBrand { TOYOTA, BENZ } public static void main() { CarBrand car = (CarBrand) Enum.Parse(typeof(CarBrand), "BENZ"); }	public enum CarBrand { TOYOTA, BENZ } public static void main() { CarBrand c = CarBrand.valueOf("BENZ"); }
สร้าง operator ใหม่ได้ public static Digit operator+(Digit a, Digit b) { return new Digit(a.value + b.value); }	ต้องเขียนเป็น method
static constructor static Employee() { Console.WriteLine("Do in initialize class"); }	static block static { System.out.println("Do in static block"); }
Destructors ~CName() { Console.WriteLine("Destructed {0}", this); }	finalize ซึ่งไม่แนะนำ @Override protected void finalize() throws Throwable { System.out.println("do finalize"); super.finalize(); }
สามารถสร้าง class ให้เป็น indexer ได้ public object this[int index] { get { return ...; } set { ... } }	ไม่มี indexer
มี struct ซึ่งคล้ายกับ class แต่ว่าเป็น value type (pass by value) ซึ่งมีข้อดีในเรื่องประสิทธิภาพของระบบในบางกรณี (แต่บางกรณีก็อาจจะทำให้ช้าลง) struct Point { public int x, y; public Point(int x, int y) { this.x = x; this.y = y; } }	ไม่มี struct
สามารถซ่อน method ที่ implement จาก interface ได้ (แต่ยังนึกไม่ออกว่ามีจุดประสงค์เพื่ออะไร) interface IControl { void Paint(); } public class EditBox: IControl, IDataBound { void IControl.Paint() {...} } class Test { static void Main() { EditBox editbox = new EditBox(); // editbox.Paint(); // error: no such method IControl control = editbox; control.Paint(); // calls EditBox's Paint implementation } }	method จากการ implement interface จะเป็น public เสมอ
มี Delegate ซึ่งทำหน้าที่เหมือนกับ function pointer และเป็นพื้นฐานของการเขียน Event delegate void SimpleDelegate(); class Test { static void F() { System.Console.WriteLine("Test.F"); } static void Main() { SimpleDelegate d = new SimpleDelegate(F); d(); } }	ไม่มี Delegate ถ้าต้องการเขียน Event อาจจะต้องเขียนเองโดยใช้ Observer Pattern
มี attribute [AttributeUsage(AttributeTargets.All)] class HelpAttribute: Attribute { public string Topic = null; private string url; public HelpAttribute(string url) { this.url = url; } public string Url { get { return url; } } } [Help("http://www.microsoft.com/.../Class1.htm")] public class Class1 { } public static void main() { Type type = typeof(Example.Attributes.Class1); object[] arr = type.GetCustomAttributes(typeof(HelpAttribute), true); HelpAttribute ha = (HelpAttribute)arr[0]; Console.WriteLine("Url = {0}, Topic = {1}", ha.Url, ha.Topic); }	คล้ายกับ annotation
สามารถ compile เป็น library (.dll) หรือว่า .exe ได้เลย csc /target:library HelloLibrary.cs csc /reference:HelloLibrary.dll HelloApp.cs	compile เป็น .jar อย่างเดียว ต้องทำงานผ่าน java (จาก jvm) javac -classpath .:/home/avh/classes:/usr/local/java/classes example.java

Class ที่ควรรู้ Environment, Enum, DateTime, Color, Font

Reference:

Introduction C# Language Specification

.Net Naming Convention

Microsoft จะแบ่งการตั้งชื่อเป็น 2 แบบคือ

Pascal Casing คือขึ้นต้นด้วยตัวใหม่แล้วตามด้วยตัวเล็ก และคำถัดไปก็ขึ้นต้นด้วยตัวใหญ่อีกครั้ง เช่น PascalCase
Camel Casing คือขึ้นด้นด้วยตัวเล็กและตามด้วยตัวเล็กคำแรก และคำถัดไปขึ้นด้นด้วยตัวใหญ่ เช่น camelCase

สำหรับอักษรย่อ (Acronym) ที่มี 2 ตัว และจะใช้เป็นตัวแรกแบบ Pascal จะใช้เป็นตัวใหญ่ทั้งหมด เช่น IO

สำหรับอักษาย่อที่มี 2 ตัว และใช้แบบ Camel คำแรกจะใช้เป็นตัวเล็กทั้งหมด เช่น dbRate

สำหรับตัวย่อ (Abbreviation ซึ่งจะต่างจาก Acronym เพราะจะย่อแค่คำเดียว เช่น id เป็นตัวย่อของ identifier ส่วน Acronym เช่น HTML ซึ่งย่อมาจาก Hypertext Markup Language) ไม่ควรใช้สำหรับการตั้งชื่อ ยกเว้น ID และ OK

โดยทั่วไปการตั้งชื่อไม่ว่าชื่อ class, method, อื่นๆ จะต้องใช้เป็นแบบ Pascal ยกเว้น parameter เท่านั้นที่จะใช้เป็นแบบ Camel

Reference:

.Net Naming Guidelines
C# Coding Conventions
XML Documentation Comments

23 GOF Design Pattern

Creation Patterns

Factory Method pattern
Abstract Factory pattern
Builder pattern
Singleton pattern
Prototype pattern จะคล้ายกับ Singleton แต่ว่าสามารถสร้างได้หลายตัว สำหรับ Java คือการใช้ .clone()

Structural Patterns

Adapter pattern
Bridge pattern
Composite pattern
Decorator pattern
Facade pattern
Proxy pattern
Flyweight pattern ก็คือการเก็บข้อมูลลง cache หรือ buffer สำหรับข้อมูลน้อยๆ แต่ใช้บ่อยๆ ซึ่งจะเกี่ยวข้องกับ Singleton และ Factory pattern เพื่อ Performance, Scalability, Stability

Behavioral Patterns

Chain of Responsibility pattern
Command pattern - Encapsulate requests for service form and object inside other objects, thereby letting you manipulate the requests in various ways.
Interpreter pattern
State pattern
Memento pattern มันจะใช้ร่วมกับ State pattern โดย Memento เป็น storage ที่เราเอา State เข้าไปเก็บ
Iterator pattern เป็นการเข้าไปหยิบข้อมูลจาก Memento
Mediator pattern
Observer pattern
Strategy pattern
Template Method pattern
Visitor pattern

Reference:

Design Patterns

Visitor Pattern

เป็นส่วนที่ไปทำงานบนระบบอื่น เพื่อให้ระบบอื่นเรียกใช้

Mediator Pattern

Interpreter Pattern

เป็นการแปลงข้อมูลจาก format หนึ่งไปยังอีก format หนึ่ง หรือการ convert ข้อมูล

ตัวอย่างของ Interpreter pattern เช่น parser, XML parser

Builder Pattern

Bridge Pattern

Bridge pattern will decouple an abstraction from its implementation so that the two can vary independently

แต่จะทำให้ระบบมีความซับซ้อนขึ้น และมี performance ต่ำลง แต่ว่าจะช่วยให้ระบบมีความยืดหยุ่นมากขึ้น

State Pattern

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

Proxy Pattern

โดยเมื่อก่อนใช้คำว่า Stub โดยมี Skeleton เป็น implementation หรือ object เป็นตัวที่ตรงกันข้ามกับ Facade คือเป็นตัวกั้นทางออก กั้น request จากภายในระบบกับระบบภายนอก

Observer Pattern

The Observer Pattern defines a one-to-many dependency between objects so theat when one object changes state, all of its dependents are notified and updated automatically.

Observer เช่น เรา subscribe blog เอาไว้ เมื่อมีการ publish subject ใหม่ ก็จะส่ง subject นั้นๆ มาให้ เป็นลักษณะเดียวกับ Event-base system, Event-driven system หรือที่ใช้กันใน Listener
ข้อเสียคือถ้ามี hacker เข้ามา hacker ก็จะเห็นข้อมูลเหมือนกับ observer

Observer มีอยู่ 2 แบบ