security: กันก็อปปี้ไฟล์ลงธัมบ์ไดรฟ์?

สำหรับการปรับแต่ง Windows XP ไม่ให้สามารถก็อปปี้ไฟล์ผ่านทางพอร์ต USB ได้ จะใช้วิธีเดียวกันคือ เข้าไปแก้ที่ Registry แต่ในกรณีของ Windows XP อย่างน้อยจะต้องได้รับการติดตั้ง Service Pack 2 ขึ้นไปถึงจะทำได้ ขั้นแรกกดปุ่ม Windows +R (คลิ้กปุ่ม Start เลือก Run) พิมพ์คำสั่ง regedit แล้วกด Enter
หลังจากที่หน้าต่างโปรแกรม Registry Editor ปรากฎขึ้นมาแล้ว ในกรอบซ้ายมือให้คลิ้กเครื่องหมาย + หน้ารายการตามลำดับข้างล่างนี้

HKEY_LOCAL_Machine\System\CurrentControlSet\Control\StorageDevicePolicies

หาก คลิ้กเข้าไปถึง Contrl แล้วไม่พบคีย์ StorageDevicePolices ก็ อย่าเพิ่งตกใจไป เพราะคุณสามารถสร้างคีย์นี้ขึ้นมาได้ โดยคลิ้กขวาบนรายการ Contorl เลือกคำสั่ง New ตามด้วย Key แล้วตั้งชื่อคีย์ใหม่ภายใต้ Control ว่า StorageDevicePolicies



คลิ้ก เลือกรายการนี้ จะพบว่า ในกรอบด้านขวาจะไม่มีพารามิเตอร์ใดๆ เลย ให้คลิกขวาบนคีย์ StorageDevicePolicies แล้วเลือกคำสั่ง New ตามด้วย DWORD value ตั้งชื่อว่า WriteProtect แล้วกดปุ่ม Enter บนคีย์บอร์ด



ขั้นตอนสำคัญก็คือ การกำหนดค่าให้ WriteProtect ทำงาน โดยคลิกขวาเลือกคำสั่ง Modify แล้วเปลี่ยนค่าจาก 0 เป็น 1 แล้วคลิ้กปุ่ม OK



จาก นั้นปิดหน้าต่างโปรแกรม Registry Editor แล้วรีสตาร์ทคอมพิวเตอร์ใหม่ คราวนี้ ก็จะไม่มีใครสามารถก็อปปี้ไฟล์จากเครื่องคอมพ์ของคุณลงยูเอสบีไดรฟ์ได้อีก ต่อไปแล้ว ยกเว้นเขารู้พาสเวิร์ดแอดมิน และความลับของการป้องกันด้วยวิธีนี้ (สำหรับการแก้ไขกลับไปเป็นเหมือนเดิมก็แค่เปลี่ยนค่าของ WriteProtect จาก 1 ให้เป็น 0 แล้วรีสตาร์ทก็เป็นอันเรียบร้อยแล้ว)

ที่มา http://www.thaiadmin.org/board/index.php?topic=111993.0

เทคนิคการแก้ไข Stuck Pixel บนจอ LCD

หลายคนเซ็งเมื่อเห็น"จุดสีดำ"ที่เช็ดเท่าไหร่ก็ไม่ออกซะทีบนหน้าจอ แอลซีดีคู่ใจ วิกฤตจุดดำบนจอแอลซีดีถูกเรียกว่า “Dead Pixel” บ้าง “Stuck Pixel” บ้าง ต่อไปนี้คือวิธีแก้ไขเบื้องต้นที่อาจทำให้จุดดับบนจอหายไปโดยที่คุณไม่ต้อง ส่งซ่อมให้ยุ่งยาก

***เทคนิคการแก้ไข Stuck Pixel บนจอ LCD
บทความโดย นิตยสาร LCDSPEC (www.lcdspec.com)

ถึงแม้ว่าเทคโนโลยีการผลิตจอ LCD จะเดินทางมาไกลจนกระทั่งมี “วุฒิภาวะ” ในระดับหนึ่งแล้วก็ตาม และกระบวนการผลิต LCD Panel ในปัจจุบันก็มีความแม่นยำสูงมาก แต่ด้วยข้อเท็จจริงที่ว่าจอ LCD นั้นประกอบไปด้วยพิกเซลนับแสนหรือนับล้านจุด จึงเป็นไปได้ที่จุดพิกเซลจำนวนหนึ่ง (จากจุดนับล้านจุด) จะเสียหายจากการผลิต หรือเสื่อมไปก่อนเวลาอันควร ในขณะที่จุดพิกเซลที่เหลือยังคงทำงานได้ตามปกติ

คำว่า “พิกเซล” (Pixel) เป็นคำผสมที่เกิดจากคำว่า Pix (“pictures”) และ el (“element”) หมาย ถึงหน่วยเล็กที่สุดของภาพที่แสดงบนจอคอมพิวเตอร์ หรือบนกระดาษ หรือพูดง่ายๆ ว่าเป็นหนึ่งใน “จุด” เล็กๆ หลากสีที่เรียงชิดติดกันจนเป็นภาพที่เราสามารถรับรู้ได้นั่นเอง จอภาพที่เราใช้อยู่ในปัจจุบัน ไม่ว่าจะเป็นจอ CRT, LCD หรือ Plasma ต่างก็ประกอบไปด้วยจุด “พิกเซล” สีแดง น้ำเงิน และเขียว เรียงชิดติดกันเป็นจำนวนมหาศาลทั้งสิ้น และจุดต่างๆ เหล่านี้ก็จะดับและสว่างตามคำสั่งของวงจรควบคุม เพื่อเปล่งแสงสีต่างๆ ออกมา และเมื่อประกอบกับจุดสีต่างๆ ที่อยู่ในบริเวณใกล้เคียง ก็จะทำให้เกิดภาพที่เรามองเห็นได้บนจอแสดงผล
จุดพิกเซลอาจมีรูปร่างแตกต่างกันออกไป เช่น สี่เหลี่ยม หรือวงกลม ขึ้นอยู่กับประเภทของจอ
เจ้าของจอ LCD หลายคนเคยพบปัญหา Stuck Pixel หรือ Dead Pixel อาการของปัญหานี้มี 2 แบบ ได้แก่

อาการแบบที่ 1: เมื่อจอแสดงภาพสีดำสนิท จะสังเกตเห็นว่าจุดบางจุดบนจอสว่างอย่างถาวร โดยจุดที่สว่างอาจเป็นสีแดง น้ำเงิน หรือเขียว ก็ได้ และถึงแม้จอจะเปลี่ยนไปแสดงภาพสีอื่นๆ จุดสว่างดังกล่าวก็ยังสว่างค้างเป็นสีเดิมอยู่ เราเรียกอาการนี้ว่า “Stuck Pixel” แต่คนส่วนใหญ่มักเข้าใจว่า “Stuck Pixel” คือ “Dead Pixel” ซึ่งจริงๆ แล้วมันต่างกันอย่างสิ้นเชิง
อาการแบบที่ 2: จุดบางจุดบนจอดับสนิทอย่างถาวร ไม่ว่าจอจะแสดงภาพใดอยู่ก็ตาม ซึ่งเราเรียกพิกเซลที่มีอาการนี้ว่า “Dead Pixel” หรือพิกเซลที่ “ตาย” แล้วนั่นเอง บทความนี้จะนำเสนอวิธีการแก้ไข “Stuck Pixel” เท่านั้น แต่ไม่รวมถึงการแก้ไข “Dead Pixel”

วันนี้ LCDSPEC ขอนำเสนอเทคนิคต่างๆ ในการกำจัด Stuck Pixel ครับ แต่ ก่อนจะศึกษาเทคนิคการกำจัด Stuck Pixel คุณควรทำความเข้าใจเกี่ยวกับความเสี่ยงที่อาจเกิดขึ้นจากการปฏิบัติตามขั้น ตอนในบทความนี้เสียก่อน ได้แก่

- ถ้าผู้ผลิตจอ LCD ของคุณกำหนดเงื่อนไขการรับประกันที่ครอบคลุมถึง Stuck/Dead Pixel อยู่แล้ว เมื่อจอของคุณเกิด Stuck pixel ขึ้น คุณควรปรึกษาบริษัทผู้ผลิตเสียก่อน และไม่ควรซ่อม Stuck pixel ด้วยตนเอง

- เทคนิคการกำจัด Stuck Pixel เป็นเทคนิคที่รวบรวมมาจากแหล่งข้อมูลต่างๆ และเป็นเทคนิคที่ได้รับการพิสูจน์ว่าสามารถแก้ไขปัญหาได้ในหลายๆ กรณี LCDSPEC จะไม่รับผิดชอบใดๆ ต่อความเสียหายที่เกิดขึ้นกับจอ LCD จากการปฏิบัติตามขั้นตอนต่างๆ ในบทความนี้

- หลีกเลี่ยงการเปิดจอ LCD เพื่อดูอุปกรณ์ภายใน เพราะจะทำให้จอของคุณสิ้นสุดการประกันจากบริษัทผู้ผลิตโดยทันที

- หากคุณใช้เทคนิคที่ต้องใช้น้ำ กรุณาหลีกเลี่ยงการทำให้อุปกรณ์ต่างๆ ของจอ LCD และเครื่องคอมพิวเตอร์เปียกน้ำ

- หลายๆ คนกล่าวว่าการใช้แรงกดบนเม็ด Pixel ของจอ LCD แล้วจะทำให้จอ LCD เสียหายมากขึ้นกว่าเดิม (ถึงแม้ว่าจะเป็นคำกล่าวที่ไม่ได้รับการพิสูจน์ก็ตาม) หากคุณปฏิบัติตามวิธีในบทความนี้อย่างเคร่งครัด ก็จะสามารถหลีกเลี่ยงความเสียหายดังกล่าวได้

- จอ LCD ประกอบไปด้วยผลึกแก้วหลายๆ ชั้น (layer) ซึ่งมีความละเอียดและบอบบางเป็นอย่างมาก การใช้แรงกด หรือแตะ อาจทำให้ชิ้นส่วนบอบบางเหล่านั้นเกิดความเสียหายได้ คุณจึงต้องยอมรับความเสี่ยงดังกล่าวหากคุณต้องการปฏิบัติตามขั้นตอนที่นำเสนอในบทความนี้

หากคุณยอมรับทุกข้อที่กล่าวมา ต่อไปนี้คือ 4 เทคนิคเพื่อการกำจัด Stuck Pixel ที่คุณสามารถทำได้ด้วยตัวเอง ได้แก่ การใช้ซอฟต์แวร์ การใช้แรงกด การแตะหรือเคาะเบาๆ และการใช้ความร้อน

##เทคนิคการใช้ Software

เทคนิคนี้ตั้งอยู่บนสมมติฐานที่ว่า Stuck Pixel สามารถกลับเข้าสู่ภาวะปกติได้เมื่อมันถูกเปิด/ปิด ซ้ำๆ กันอย่างรวดเร็ว คุณควรลองใช้เทคนิคนี้ก่อนเป็นอันดับแรก และหากเทคนิคนี้ไม่สามารถแก้ปัญหาให้คุณได้ จึงค่อยเปลี่ยนไปปฏิบัติตามเทคนิคถัดไป เทคนิคการใช้ Software นี้ใช้ได้ดีกับ LCD Monitor แต่ก็ไม่ผิดกติกาอะไรหากคุณจะนำเครื่องคอมพิวเตอร์ไปต่อกับ LCD TV แล้วรัน Software เหล่านี้

คุณสามารถดาวน์โหลดโปรแกรมช่วยแก้ไข Stuck Pixel ได้จาก Website ต่อไปนี้:

JScreenFix – เว็บไซท์ที่ใช้ Java Applet ซึ่งเป็นโปรแกรมเล็กๆ ที่จะช่วยขจัด Stuck pixel โดยการเปิด/ปิด พิกเซลแต่ละจุดบนจอเป็นจำนวน 60 ครั้งต่อวินาที
JeffPatch.com blog – สำหรับคนที่ใช้เครื่อง Mac ที่ Blog นี้ก็มีวีดีโอภาพกระพริบจาก Sony ที่อาจช่วยแก้ไข Stuck Pixel ได้
DPT 2.20 – โปรแกรมบน Windows ที่สามารถช่วยให้คุณค้นหา Stuck pixel ได้ง่ายขึ้น และมี “Pixel Exerciser” ที่ช่วยให้ Pixel ที่เสียหายกลับมาทำงานได้อย่างเดิม
UDPixel 2.1 – ฟรีแวร์บน Windows ที่ช่วยคุณค้นหา และแก้ไข Stuck Pixel
LCD Scrub – Screensaver สำหรับเครื่อง Mac ที่แสดงภาพกระพริบบนจอ เพื่อช่วยแก้ไข Stuck Pixel และแก้ไขอาการ Burn-in
##เทคนิคการใช้แรงกด

1.ปิดจอ LCD ของคุณ
2.นำผ้านิ่มๆ ชุบน้ำหมาดๆ (ถ้าใช้น้ำอุ่นจะได้ผลดีขึ้น และห้ามใช้ผ้าเปียก) มาห่อบริเวณหัวปากกาลูกลื่น, ดินสอ, ไขควงเล็กๆ หรืออุปกรณ์อื่นๆ ที่มีลักษณะคล้ายกัน แต่ต้องเป็นอุปกรณ์ที่ไม่มีหัวแหลมคมที่จะทำให้จอ LCD เป็นรอยได้ เราขอแนะนำให้ใช้ปากกา Stylus ที่มากับเครื่อง PDA หรือ Smartphone สำหรับการนี้
3.ใช้ยาง หรือเชือกเส้นเล็กๆ มัดผ้าที่ห่อบริเวณหัวปากกาไว้ เพื่อไม่ให้ผ้าหลุดออกมาในขณะที่คุณนำปากกาไปกดบนจอ
4.นำ ปากกาที่เตรียมไว้ไปกดเบาๆ ที่ Stuck Pixel โดยพยายามกดให้ตรงกับจุด Pixel ที่เสียหายมากที่สุด การกดผิดพลาดอาจทำให้จุด Pixel ที่อยู่ข้างเคียงเสียหายตามไปด้วย
5.ระหว่างที่กด Stuck Pixel ให้กดปุ่ม Power ของจอ LCD เพื่อเปิดให้จอทำงาน
6.นำปากกาออกจากจอ แล้วตรวจสอบดูว่า Stuck Pixel หายเป็นปกติหรือไม่ หากยังไม่หายเป็นปกติ ให้ทำตามขั้นตอนข้อ 4 และ 5 อีกครั้ง โดยค่อยๆ เพิ่มแรงกดให้มากขึ้นทีละนิด

##เทคนิคการแตะ/เคาะเบาๆ ที่ Stuck Pixel

1.นำจอ LCD มาต่อเข้ากับเครื่องคอมพิวเตอร์ และเปิดจอ LCD และเครื่องคอมพิวเตอร์
2.ใช้โปรแกรมแต่งภาพสร้างภาพสีดำล้วน ที่มีขนาดเท่ากับจอ LCD ของคุณ เช่นหากคุณใช้จอ Full HD ก็ควรสร้างไฟล์ภาพสีดำที่มีขนาด 1,920 x 1,080 พิกเซล เป็นต้น แล้วนำภาพสีดำที่สร้างขึ้นมาแสดงแบบเต็มจอ ซึ่งการแสดงภาพสีดำนี้จะทำให้คุณสามารถมองเห็น Stuck pixel ได้อย่างชัดเจน
3.ใช้ ปากกาที่มีไม่มีหัวแหลมคม หรือใช้ Stylus ที่มากับเครื่อง PDA/Smartphone แตะเบาๆ ที่ Stuck Pixel ไม่ควรใช้แรงกดมากเกินไป แต่แรงกดนั้นจะต้องมากพอที่จะทำให้เม็ดพิกเซลที่ถูกแตะกระพริบแสงสีขาวๆ ในขณะที่ถูกแตะ หรือกล่าวได้ว่าหากเม็ดพิกเซลไม่กระพริบแสงสีขาว แสดงว่าคุณยังแตะมันไม่แรงพอนั่นเอง
4.พยายามแตะเป็นจังหวะอีก 5-10 ครั้ง โดยค่อยๆ เพิ่มแรงกดทีละนิด จนกว่าอาการ Stuck Pixel จะหายไป
5.นำไฟล์รูปภาพสีขาวล้วนแบบเต็มจอมาแสดง แล้วดูว่าอาการ Stuck Pixel หายไปหรือไม่ และตรวจสอบให้แน่ใจว่าคุณไม่ได้ทำให้ Pixel ข้างเคียงเกิดความเสียหาย

##เทคนิคการใช้ความร้อน

เทคนิคนี้มีประโยชน์ในกรณีที่เม็ด pixel กลายเป็นสีขาวหรือสีดำในบริเวณกว้าง และสามารถใช้ได้ดีกับเครื่องคอมพิวเตอร์โน๊ตบุ้ค (แต่ก็ใช้ได้กับจอ LCD ทั่วไปได้เช่นกัน) การ ใช้เทคนิคนี้มีความเสี่ยงที่จะทำให้อุปกรณ์อิเล็กทรอนิคภายในจอ หรือภายในเครื่องคอมพิวเตอร์โน๊คบุ้คเสียหายจากความร้อนได้ คุณจึงควร Backup ข้อมูลสำคัญไว้ก่อนจะลงมือปฏิบัติ และเทคนิคนี้อาจไม่ช่วยให้เม็ด Pixel ที่เสียหายเป็นบริเวณกว้างกลับมาเป็นปกติได้ทั้งหมด หรือถึงแม้จะแก้ไข Stuck Pixel ได้สำเร็จ จอของคุณก็อาจกลับมามีอาการเดิมอีกครั้ง

คุณสามารถแก้ไข Stuck Pixel โดยใช้ความร้อนตามขั้นตอนต่อไปนี้:

1.เทคนิคนี้จะต้องใช้เวลานานหลายชั่วโมง หรือเป็นวัน เราจึงแนะนำให้คุณเสียบปลั๊กเครื่องคอมพิวเตอร์โน๊ตบุ้คแทนการใช้พลังงานจาก แบตเตอรี่
2.ไปที่ Power Settings ใน Control Panel และตรวจสอบให้แน่ใจว่า Windows จะไม่ดับจอ LCD และจะไม่เข้าสู่โหมด Standby หรือ Hibernate เมื่อถึงเวลาที่กำหนดไว้ (ตรวจสอบให้แน่ใจว่าเครื่องและจอจะถูกเปิดและทำงานตลอดเวลานั่นเอง)
3.กดหน้าจอของโน๊ตบุ้กให้เข้ามาใกล้ keyboard เล็กน้อย แต่ต้องไม่ใกล้ถึงขนาดที่ทำให้เครื่องหยุดทำงาน หลังจากนั้นให้วางโน๊ตบุ้คไว้ในที่แคบๆ ที่อากาศและความร้อนถ่ายเทไม่สะดวก เช่นตู้เล็กๆ หรือลิ้นชัก
4.ปล่อย ให้โน๊ตบุ้คของคุณทำงานอยู่อย่างนั้นหลายๆ ชั่วโมง หรือหลายๆ วัน ควรหมั่นเข้าไปตรวจสอบบ่อยๆ ว่า Stuck Pixel หายไปหรือไม่ การใช้ความร้อนจะทำให้ของเหลวในผลึก LCD ไหลอยู่ในเม็ด Pixel ได้เต็มเม็ดเต็มหน่วยยิ่งขึ้นในบางพื้นที่ หลังจากที่ก่อนหน้านี้ของเหลวดังกล่าวอาจจะไม่ตอบสนองต่อคำสั่งของวงจรควบ คุม

เราหวังว่าเทคนิคนี้จะเป็น ประโยชน์ต่อผู้ที่ประสบปัญหา Stuck Pixel ได้ไม่มากก็น้อย สำหรับบทความ และเทคนิคอื่นๆ ในการเลือกซื้อและใช้งาน HDTV คุณสามารถติดตามได้จากเว็บไซต์ www.lcdspec.com ครับ

ทำไมระหว่างที่จอหนังในโรงภาพยนตร์จะต้องมีตัวเลขขีดๆขึ้นมาด้วย

สงสัยกันมั้ยว่าเวลาเราดูหนัง จะมีตัวเลขแปลกๆ เกิดขึ้นเสมอ เวลาดูในโรง

ผมสงสัยมานานมากๆ ละ วันนี้ได้คําตอบซักที มาดูกันเลยครับ





พี่ ตัวเลขที่คุณเห็นนั่นคือรหัสลับที่เขียนลงบนฟิล์มซึ่งแต่ละ copy จะแตกต่างกันโดยเจ้าของหนังให้ทางฟิล์มแลปเป็นคนทำรหัสลับนั้นขึ้นเพื่อตรวจ ได้ในกรณีที่มีการละเมิดลิขสิทธิ์เอาหนังไปทำแผ่นผี วีซีดีเถื่อนครับ ขยายความอีกหน่อยนะครับ คือ การละเมิดลิขสิทธิ์หนังเนี่ยมีหลายวิธีที่จะได้ตัวหนังมาหนึ่งในวิธีที่นิยม เพราะจะได้แผ่นผีออกเร็วมาก คือ การแอบเอากล้อง หรือโทรศัพท์ไปถ่ายจากหนังที่กำลังฉายในโรงหนังในกรณีที่มีการแอบถ่ายแบบนี้ เมื่อเป็นแผ่นผีซีดีเถื่อนมันก็จะมีตัวเลขรหัสลับนั้นปรากฎอยู่ในหนังแผ่นผี นั้นเมื่อเจ้าของหนังได้เห็นแผ่นผีก็จะมีการเช็คว่าตัวเลขรหัสลับที่มีตรง กับฟิล์มที่ส่งไปให้โรงหนังโรงใดจากนั้นจะได้ดำเนินการสืบว่าใครเป็นผู้แอบ ถ่าย หรือจะได้จัดการดำเนินการกับโรงหนังที่ปล่อยให้มีการแอบถ่ายหนังเรื่องนั้น เป็นผู้รับผิดชอบต่อความเสียหายที่เกิดขึ้น ในอดีต สมัย คุณ สมศักดิ์(เสี่ยเจียง) เป็นนายกสมาพันธ์มีการกำหนดบทลงโทษไว้แรงถึงขั้นสูงสุด คือถ้าโรงหนังใดปล่อยให้มีการแอบถ่ายในโรงตัวเองบ่อยๆจะให้สมาชิกสมาพันธ์ ทั้งหมด Anti ไม่ส่งหนังให้โรงนั้นฉายอีกเลยแต่ปัจจุบันไม่แน่ใจว่ามีการลงโทษใดๆ หรือไม่


ที่มา : http://movie.mthai.com/movie-guru/48497.html

มาดูความเร็วของ internet แต่ละประเทศกันครับ

สังเกต ประเทศไทยนะครับ ^^

Top Countries by Download Speed

1. 20.88 Mb/s Korea, Republic of
2. 15.75 Mb/s Japan
3. 14.59 Mb/s Aland Islands
4. 13.08 Mb/s Lithuania
5. 12.94 Mb/s Sweden
6. 12.68 Mb/s Latvia
7. 12.40 Mb/s Romania
8. 11.67 Mb/s Bulgaria
9. 11.53 Mb/s Netherlands
10. 9.54 Mb/s Moldova, Republic of
11. 9.16 Mb/s Hong Kong
12. 8.56 Mb/s Slovakia
13. 8.37 Mb/s Germany
14. 8.20 Mb/s Russian Federation

65. 2.79 Mb/s Thailand

Top Countries by Upload Speed

1. 8.83 Mb/s Lithuania
2. 7.05 Mb/s Japan
3. 5.48 Mb/s Bulgaria
4. 5.17 Mb/s Aland Islands
5. 5.06 Mb/s Latvia
6. 4.88 Mb/s Romania
7. 4.86 Mb/s Hong Kong
8. 4.64 Mb/s Russian Federation
9. 4.55 Mb/s Sweden
10. 4.37 Mb/s Slovenia
11. 3.64 Mb/s Andorra
12. 3.56 Mb/s Moldova, Republic of
13. 3.10 Mb/s Netherlands
14. 3.02 Mb/s Asia/Pacific Region

56. 0.69 Mb/s Thailand

ที่มา http://www.speedtest.net/global.php

แพทเทิร์น Agile - ปิงปองโปรแกรมมิ่ง

Agile สนับสนุนความคิดที่ว่าสองหัวดีกว่าหัวเดียว การเขียนโปรแกรมสองคนโดยใช้คอมเครื่องเดียวหรือที่เรียกว่า Pair Programming ไม่ได้ระบุว่าจะแบ่งกันเขียนโปรแกรมอย่างไร การแบ่งให้คนนึงเขียนเทสต์ อีกคนเขียนโค้ด แล้วคนเขียนโค้ดเสร็จกลับไปเขียนเทสต์ ให้อีกคนเขียนโค้ดสลับไปมาเหมือนตีปิงปอง จะทำให้งานท้าทาย ไม่น่าเบื่อ และมีประสิทธิผลมากขึ้น

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

ดังนั้น

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

ข้อดี
- แต่ละฝ่ายได้มีโอกาสเขียนทั้งเทสต์และโค้ด ทำให้เพิ่มประสบการณ์ในการพัฒนากว้างขึ้น
- การสลับให้แต่ละฝ่ายจับคีย์บอร์ด จะทำให้เพิ่มความมั่นใจ และมีความเป็นเจ้าของโค้ดทีตนเขียนมากขึ้น
- การให้สองคนทำเรื่องเดียวกัน ทำให้โค้ดทุกส่วนมีแบ๊กอัพ ที่ผ่านตาอย่างน้อยสองคน ทำให้ลดปัญหาที่เกิดจากการหาคนทำแทนไม่ได้
- การมีคนช่วยคิดอยู่ข้างๆ ช่วยลดความผิดพลาด และโอกาสที่เสียเวลานานๆกับการติดปัญหาที่เขียนโปรแกรมคนเดียวมักมองไม่ออก
- การสลับคู่เขียนโปรแกรมในทีม ทำให้ทุกคนในทีมมีโอกาสทำงานร่วมกัน และทำให้แต่ละคนได้มีโอกาสเรียนรู้งาน เห็นภาพรวมของทั้งระบบ จะมีส่วนช่วยให้เข้าใจจุดประสงค์ของการเขียนงานส่วนย่อยแต่ละส่วนมากขึ้น
- การใช้หลักปิงปอง ทำให้รู้สึกสนุกขึ้น ต่างฝ่ายต่างพยายามท้าทายอีกฝ่าย
- ใช้หลักนี้ ในการอบรมนักพัฒนาที่มีประสบการณ์น้อยกว่าได้ โดยคนที่มีประสบการณ์มากกว่าสามารถเขียนโค้ดและอธิบายสิ่งที่ตนทำ ในขณะเดียวกันคนที่มีประสบการณ์น้อยกว่าก็สามารถลองหัดโดยมีพี่เลี้ยงคอยแนะ เพิ่ม
- ลดความเหนื่อยล้าจากการทำอะไรอย่างใดอย่างหนึ่งติดกันนานมากๆ เมื่อฝ่ายใดฝ่ายหนึ่งที่ถือคีย์บอร์ดเริ่มหมดสมาธิ ก็สามารถสลับให้อีกฝ่ายทำต่อ
- ในระหว่างที่คนหนึ่งเขียนโปรแกรม อีกฝ่ายสามารถคิดวิธี refactor โค้ดให้กระทัดรัด อ่านง่าย และสื่อความหมายดีขึ้น ทำให้เราสามารถปรับปรุงคุณภาพโค้ดให้ดีขึ้นได้ทันที

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

เทคนิคในทางปฏิบัติ
การ เขียนโปรแกรมแบบปิงปอง จะได้ผลดีเมื่อเราใช้แนวการพัฒนาโปรแกรมโดยการเขียนเทสต์ก่อน (test driven design) โดยคนหนึ่งเขียนเทสต์ให้อีกคนเขียนโค้ดเพื่อรันเทสต์ให้ผ่าน การเขียนเทสต์เหมือนกับการกำหนดอินเตอร์เฟซว่าเราจะต้อง Implement อะไรบ้าง และเป็นการทำให้รู้ว่าควรเขียนโค้ดอย่างไรให้รันเทสต์ผ่าน ไม่ควรเขียนโค้ดเผื่อสิ่งที่ไม่ได้เขียนเทสต์ครอบคลุมไว้ และพยายาม refactor โค้ดเมื่อเห็นโอกาส

การเขียนโปรแกรมสองคน ทุกคนควรมีโอกาสเขียนร่วมกับคนอื่นๆในทีม โดยอาจกำหนดตารางทำงานสลับคู่ทุกวัน อย่าง pairing matrix หรือ pairing calendar เพื่อให้ทุกคนมีโอกาสทำงานร่วมกันคนอื่น มีโอกาสเรียนรู้งานส่วนอื่นๆ และทำให้ทีมมีความสัมพันธ์ดีขึ้น บางองค์กรอาจเขียนโปรแกรมสองคนตลอดทั้งวันและทุกๆวัน ในขณะที่บางองค์กรอาจแบ่งเวลาครึ่งวันเขียนโปรแกรมร่วมกัน และอีกครึ่งวันแยกเขียนตามปกติ เพื่อจะได้มีเวลาเช็คอีเมล์หรือเคลียร์งานด้านอื่นๆ

แพทเทิร์นที่เกี่ยวข้อง
Agile แบ่งงานออกเป็นเรื่องๆ (User story) ที่มีขอบเขตเนื้อหาสำหรับเขียนไม่มากนัก เช่นใช้เวลาในหน่วยวันสองวัน การใช้โปรแกรมมิ่งแบบปิงปองเป็นรูปแบบหนึ่งของการเขียนโปรแกรมทีละสองคน และสนับสนุนให้เขียนโปรแกรมโดยการเขียนเทสต์ก่อน การเขียนเทสต์ควรใช้ไลบรารี่อย่าง unit testing, mock objects ร่วมกับ continuous integration tool การเขียนโค้ดควรต้องมี IDE ที่สนับสนุน Refactoring, version control

ที่มา http://www.thaidev.org/?p=70

แพทเทิร์น Agile – ยืนประชุมประจำวัน

"คนเรายืนนานๆแล้วเมื่อย ถ้าต้องยืนประชุมจะได้ไม่เยิ่นเยื้อ หาข้อสรุปได้เร็วๆไม่เสียเวลาทุกคน"

Agile เน้นการสื่อสารบ่อยๆ นั่นหมายถึงแต่ละวันสมาชิกในทีมควรมีเวลาเล่าให้คนอื่นฟังถึงความคืบหน้าและ ปัญหาที่ติดที่คนอื่นอาจช่วยได้ ให้ทุกคนฟัง แต่ทำยังไงให้ประชุมไม่ยืดเยื้อ จนเสียเวลาทำงาน หรือนานจนหมดสมาธิ

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

ดังนั้น

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

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

เทคนิคในทางปฏิบัติ

Agile พยายามหลีกเลี่ยงอะไรที่เป็นทางการ แต่ในขณะเดียวกันวิธีนี้จะประสบความสำเร็จเมื่อทุกคนต้องมีวินัยมีความรับ ผิดชอบสูง การประชุมที่ใช้เวลาสั้นๆจึงสำคัญมากที่ทุกคนต้องตรงเวลา การยืนประชุมครั้งแรก อาจต้องมีคนแนะนำถึงขั้นตอน ส่วนใหญ่สมาชิกจะยืนล้อมเป็นวงในพื้นที่ว่างๆที่ใกล้จุดที่สมาชิกส่วนใหญ่ทำ งาน ไม่จำเป็นต้องจัดในห้องประชุม เพื่อลดความเป็นทางการลง ถ้าทีมมีการใช้ฝาผนังเก็บข้อมูลโครงการ เช่น story card, burnup chart ก็ควรประชุมใกล้ๆฝาผนังเพื่อจะได้ง่ายต่อการอ้างอิงถึงข้อมูลบนฝาผนัง ถ้าการประชุมนอกห้องประชุมส่งเสียงดังรบกวนทีมอื่นจริงๆ ค่อยย้ายไปที่ห้องประชุม

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

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

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

แพทเทิร์นที่เกี่ยวข้อง
การยืนประชุมเป็นส่วนหนึ่งของกิจกรรมสำคัญของทีม Agile โดยเล่าถึงความคืบหน้าจากแผนที่่วางจาก การประชุมการวางแผนระดับ Iteration โดยแต่ละคนจะรายงานถึงความคืบหน้าของ Story card ที่ตนทำอยู่

ที่มา http://www.thaidev.org/?p=68

ความแตกต่างระหว่าง Software Engineer กับ SA

นึกสนใจก็เลยลองเสาะหาข้อมูลมาซะหน่อย

ถ้ามอง ปัจจัยในการ พัฒนา Software เป็นหลักนะครับ
SA ==> System Analyst จะเป็น ผู้ที่ทำการวิเคราะระบบเป็นหลัก ซึ่งจะ Abstarct มากๆ ก่อน
SE ==> System Engineer นำสิ่งที่ SA วิเคราะห์มา ในเชิง Realize ขึ้น คือเริ่มมองเห็นรูปร่างของ Software นั่นเองครับ
SAt ==> System architecture เป็นคนออกแบบโครงสร้างของระบบทั้งหมดในเชิง Software คือ ระบุได้ว่า ส่วนไหนพัฒนางานโดยอะไร (Framwork ใด) รูปแบบไหน


Software Engineer จะดูแลเรื่อง Detail Design เช่น การ Design Class Diagram และ Sequence Diagram นอกจากนี้ถ้าเป็น SE ระดับ Senior หน่อยก็เป็นพวก Project Management ครับ ส่วน System Analyst จะดูเรื่องการเก็บ Requirement ทำพวก Input และ Output ที่ User ต้องการ รวมถึง Business Process ต่างๆ ส่วน System Architect จะดูและภาพรวมของระบบ Environment ของระบบ การ Integrate เข้ากับระบบอื่น

ซึ่ง ถ้าเคยเรียน Software Engineering จะเห็นได้ว่าวิชาจะเน้นหนักไปที่ Software Lifecycle, Project Management , Software Quality และ Design Pattern

System Analysis จะเน้นพวกการเก็บ Requirement การกำหนด Input Output การ Design Process Flow

System Architect ซึ่งยังไม่ค่อยมีเปิดสอน จะเน้นพวก System Integration และความรู้ด้าน Data Communication ครับผม

SA ที่หมายถึง System Analyst ยังสามารถแบ่งออกเป็น 2 ประเภทอะครับ (อ้างอิงจากที่เคยเรียนอะนะ)

1.) System Analyst
2.) Bussiness Analyst

ถ้า เป็นลักษณะที่ 1. ก็รู้ Business และเข้าใจ Requirement ในระดับที่สามารถออกแบบระบบ หรือ ส่วนใหญ่กระบวนทางธุรกิจก็มักจะหมายถึง Table ใน Database รวมไปถึงสามารถอธิบาย Business Flow ให้พวก Developer ทำโปรแกรมออกมาให้ตาม Requirement ของลูกค้า
เข้าใจว่างานหลักๆคือเน้น การสร้างระบบจึงต้องมีความรู้ด้าน Program ด้วย ไม่อย่างนั้นจะคุยกะโปรแกรมเมอร์ไม่ค่อยรู้เรื่องเหมือนพูดกันคนละภาษา
แต่คนพวกนี้จึงอาจโดนเกณฑ์ไป coding ถ้าโปรเจคไม่เสร็จ

ถ้า เป็นลักษณะที่ 2. เข้าใจว่าต้องเป็นพวกที่มีประสบการณ์ด้าน Business สูง สามารถวิเคราะห์ข้อมูลหรือ Requirement จากลูกค้าได้ พวกนี้อาจจะต้องหนักด้านการติดต่อกับลูกค้าเป็นหลัก , design table , หน้าจอ เข้าใจ flow งานทั้งหมดแต่อาจจะไม่ต้อง Programming เป็นเลยก็ได้

แต่ ในโลกตวามจริง โปรเจคอาจจะไม่จำเป็นต้องจ้าง SA ที่เป็น 2 แบบนี้พร้อมกันเพราะทำให้ต้นทุนสูงก็เลยจ้างมาคนเดียวแล้วก็รับหน้าที่ทั้ง 2 เรื่องนี้ไปพร้อมๆกัน เพราะ Phase Design มันไม่ได้ต้องทำกันตลอดทั้ง Project และเมื่อ SA วางระบบเสร็จแล้ว ขั้นตอนในการ implement หรือ tuning ระบบให้เข้ากับความต้องการ SA ก็ไม่ต้องทำงานหนักแล้วดังนั้นความรับผิดชอบก็จะตกอยู่ที่การไปคุยกับลูกค้า ว่าระบบโ
อเคไม๊มมากกว่า

อีกอย่างนึงที่มักจะเห็น SA ชอบทำตกไปคือ การให้ความเข้าใจกับลูกค้า SA ควรจะ minimize scope ของงานให้ได้ตาม requirement แต่ไม่ได้ทำให้งานไปตกอยู่ที่ Programmer ทั้งหมด ดังนั้นในขั้นตอนการ design จึงเป็นเรื่องสำคัญว่าจะทำอย่างไรให้ระบบทำงานได้ครบตามความต้องการ และ งานไม่ใหญ่มากนักเพื่อให้ส่งมอบงานได้ตรงเวลาอะครับ (ไม่งั้นอาจเห็น Programmer กับ SA ทะเลาะกันแน่ๆ)


ส่วน SA ที่เป็น Software/System Architect

เน้นหนักไปที่การ design software / system ให้มี Quality หรือ Best Performance มากกว่าอะครับ แช่นทำอย่างไรโปรแกรมจะทำงานได้เร็ว , โปรแกรมไม่ Error บ่อย , ปรับระบบให้รองรับต่อการเปลี่ยนแปลง ต้องเข้าใจก่อนนะครับว่าในส่วนของ Architect นี้ไม่ได้เกี่ยวข้องกับ Requirement เพราะ Analyst เป็นคน design ให้ตรงกับ Requirement
ดัง นั้นคิดว่าคนเป็น Architect ควรจะมีความรู้ด้าน Design Pattern , Framework เป็นอย่างดี และสามารถประยุกต์เข้ากับระบบที่ Analyst design มา

Requirement แบ่งออกเป็น 2 ส่วน คือ

functional requirement : Analyst ต้องรับตรงนี้ไปหละว่าจะ design กันยังไง

non-function requirement : ตรงนี้ Architect ต้องดูแล

หากความรู้อันน้อยนิดที่ผมกล่าวนั้นบกพร่องก็ขออภัยด้วยนะครับ และก็ขอให้ผู้รู้วานช่วยแก้ไขด้วยละกันครับ

ที่มา http://www.narisa.com/forums/index.php?showtopic=3968