กูเกิลโอเพนซอร์ส Google Singleton Detector

กูเกิลโอเพนซอร์สเครื่องมือตัวใหม่เพื่อช่วยให้นักพัฒนาค้นหา Singleton Pattern ภายในโค้ดจาวา เพื่อเป็นเครื่องมือช่วยให้นักพัฒนารู้ตัวว่ากำลังทำงานอยู่กับ Singleton

Singleton เป็นหนึ่งใน design pattern ของ Gang of 4 ที่ถูกใช้กันอย่างผิดๆ และมากจนเกินเลย ข้อผิดพลาดส่วนใหญ่มาจากผู้ที่ไม่เข้าใจแนวคิด OOP อย่างดีพอ

Singleton จัดเป็น pattern ที่สร้างง่าย แต่มีอันตรายมาก ผู้ที่คุ้นเคยภาษาดั้งเดิมที่มีคอนเซปต์ตัวแปร global มักจะหลงรัก pattern นี้ได้ง่ายและใช้มันอย่างผิดวิสัยที่ GOF ตั้งใจ

หลายๆ ทีที่ Singleton มีผลร้ายมากกว่าผลเสีย และมักพบปัญหาตามมาที่หลัง เช่น

• ทำให้ในแต่ละหน่วยเสีย modularity ลง

• การ test โปรแกรมเกิดข้อผิดพลาดเนื่องจากไม่รู้ว่าภายในมีการเรียกใช้ Singleton ส่งผลให้แต่ละ unit test เกิดการขึ้นต่อกันอย่างไม่ได้ตั้งใจ (ซึ่งมันผิดหลักของ unit testing)

• ผู้ใช้ไม่สามารถหลีกเลี่ยงการ unit test โดยไม่ test Singleton ไปด้วย

• ใน Test Driven Development มองว่า Singleton เป็นสิ่งชั่วร้ายเลยด้วยซ้ำ

• ปัญหาการ subclass คลาส Singleton ที่จะไม่ใช่ Singleton อีกต่อไปสร้างปัญหาอย่างมาก เนื่องจากผิดเจตนารมณ์ของผู้สร้าง และเป็นกับดักที่ซ่อนตัวอย่างแนบเนียนซะด้วย

• Singleton สร้างปัญหาให้สถาปัตยกรรมยุ่งยากขึ้น เมื่อผู้ออกแบบเบื้องต้นไม่ได้คำนึงถึงจะมีการเรียกใช้ผ่านการทำ concurrent programming

ปัจจุบันโปรแกรมเมอร์ที่ดีมักจะผลักภาระนี้ไปให้ IoC Container ทั้งหลายเป็นผู้บริหารการแจกจ่าย Singleton object ให้กับผู้ที่ต้องการจริงๆ แทนที่จะ hard code ลงไปในสถาปัตยกรรม

ในโปรแกรมของคุณมี Singleton กันกี่ที่เอ่ย?

ที่มา – Google Code Blog

ใครว่า iPhone ไม่สนับสนุน Java?

แม้ Steve Jobs จะปากมอมไปหน่อยกับการออกมาให้สัมภาษณ์คราวนั้นว่า “Java’s not worth building in [to the iPhone].” แต่จากการงัดแงะเครื่อง iPhone ออกมาก็พบว่า แอปเปิ้ลใช้ซีพียูของ Samsung S3C6400 ซึ่งอยู่ในตระกูล ARM1176JZF เป็นฐาน

ประเด็นที่สำคัญคือซีพียูในตระกูลนี้ ARM ได้ใช้เทคโนโลยี Jazelle เป็น engine ฝังอยู่ข้างใน Jazelle เป็นเทคโนโลยีที่ทำให้ Java ทำงานได้ประสิทธิภาพสูงและกินทรัพยากรหน่วยความจำน้อยกว่าปกติถึง 8 เท่าและมีระบบ Mutitasking JVM ในตัว ที่น่าสนใจคือ Jazelle เป็นเทคโนโลยีเดียวกันที่อยู่ในตระกูล JavaFX Mobile โดยในสมัยนั้น ARM ได้ขายสัญญาอนุญาตให้ SavaJE ก่อนที่ภายหลังซันจะเข้าซื้อ SavaJE อย่างถาวร

จากข่าวที่ออกมา แม้แอปเปิ้ลอยากให้ 3rd-party ทั้งหลายผลิตโปรแกรมที่อยู่บนพื้นฐาน AJAX ซะมากกว่า แต่ภายในโปรแกรมของ iPhone เองอาจมีการเรียกใช้ความสามารถของ Java ที่อยู่เบื้องล่างก็ได้

ที่มา – Ed Burnette’s blog

Rod Johnson โดดร่วม JavaEE 6

สุภาษิตฝรั่งว่าไว้ว่า “If you can’t kill it, join it” แปลว่า ถ้ารู้ว่าฆ่าทิ้งไม่ได้ ก็จับเป็นพวกซะเลย สุภาษิตนี้กำลังถูกใช้โดย Rod Johnson ผู้ก่อตั้ง Interface21 บางคนอาจจะยังนึกไม่ออกว่าเป็นใคร บางคนอาจจะยังสงสัยว่าเป็นญาติอะไรกับ Network21 หรือเปล่า แต่ถ้าเอ่ยชื่อ Spring Framework แล้วละก็ น่าจะร้องอ๋อกันซักที

Rod Johnson เป็นผู้ก่อตั้ง Spring Framework ขึ้นมา โดยเริ่มจากเป็นตัวอย่างในหนังสือ “J2EE without EJB” ที่เค้าประพันธ์ ต่อมา Spring ประสบความสำเร็จอย่างสูงอันเนื่องจาก EJB2.x สมัยนั้นมีความซับซ้อนและยุ่งยากมากจนเกินไป

แม้วันนี้ EJB 3.0 จะออกมาจากยุคมืดตรงนั้นได้และได้รับอิทธิพลอย่างสูงจาก Spring แต่คนจาก Spring เองกลับไม่มีส่วนร่วมในร่าง JSR ฉบับนั้นเท่าไหร่ จนพักหลังเกิดการถกเถียงกันมากมายในการเลือกใช้เทคโนโลยีระหว่างฝ่ายสนับสนุนทั้งสอง

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

ภาพเทคโนโลยีที่ประสบความสำเร็จและกลับเข้าร่วมมาตรฐานถือเป็นสิ่งที่น่ายินดี เมื่อสิ่งที่ได้รับการพิสูจน์แล้วและสมควรถูกตอบแทนอย่างสมน้ำสมเนื้อ ผมหวังว่าจะได้เห็นภาพประวัติศาสตร์นี้เกิดขึ้นซ้ำอีกกับเทคโนโลยีอื่นๆ โดยเฉพาะกรณี OSGi กับ Java Module ที่มีรูปแบบปัญหาคล้ายกัน

ที่มา – infoQ, JSR-316

JavaFX Compiler เปิดตัว

ค้างข่าวไว้เยอะและเห็นเรียกร้องกันมาก เลยเอาข่าว JavaFX ขึ้นก่อน ตอนนี้ที่ดังสุดก็เจ้าตัว compiler ที่จะใช้คอมไพล JavaFX Script ไปเป็น java byte code นั่นเอง

ปัจจุบันตามที่เคยบอกไป JavaFX Script ยังใช้หลักการ interpret ตรงๆ ทำให้ไม่ได้ใช้ประโยชน์จาก HotSpot เลย ซึ่งก็เป็นไปตามธรรมชาติของการพัฒนาโปรแกรมที่อยู่ในขั้นแรกเริ่ม super alpha ที่ยังไม่ถึงเวลาจะสนใจประเด็นเรื่องการปรับแต่ง performance เท่าไหร่นัก ผลของการ benchmark เทียบกับคู่แข่งที่ออกตัวก่อนอย่าง Silverlight และ Flex เลยสู้ไม่ได้

JavaFX Compiler เพิ่งอยู่ในขั้นฟักไข่ไม่ต่างกัน แต่ Chris Oliver ก็ได้ทดลอง benchmark เล็กๆ โดยเปรียบเทียบฟังค์ชันทาเคชิ เพื่อทดสอบประสิทธิภาพ ผลออกมา JavaFX ที่ผ่านการคอมไพล์เร็วกว่าเดิม 54x

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

ที่มา – Chris Oliver’s Blog, OpenJFX

NJUG#3 ประสบความสำเร็จ

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

Sun Developer Days 2007 + NJUG pre-meeting

วันจันทร์ที่ผ่านมามีงาน SDD 2007 – Thailand ช่วงบ่ายจนถึงเย็น ซึ่งทาง NJUG ก็ถือโอกาสการรวมตัวครั้งนี้จัด pre-meeting หลังเลิกงานกันเลย

เรื่องงาน SDD 2007 ผมไม่มีเรื่องจะ comment เท่าไหร่ เนื้อหาก็เบาบางมาก ซึ่งก็เป็นไปตามคาดเลยไม่รู้สึกผิดหวังเท่าไหร่ แต่ก็มีเรื่องอื่นให้ผิดหวังอยู่ 2 เรื่อง

home sweet home

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

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

วันจันทร์นี้จะมีงาน sun developer day แล้วตอนเย็นจะมี meeting จากกลุ่ม NJUG ด้วย คิดว่าคงไปแหละครับ แล้วเจอกันในงาน