ซันเปิดตัว Project SceneGraph

ซันประกาศโอเพนซอร์สโครงการ SceneGraph โดยมันจะถูกนำมาใช้เป็นเอนจิ้นการทำ scene-graph ใน JavaFX Script

ความสามารถการทำ scene-graph เป็นคุณสมบัติที่สำคัญในงานแสดงผลกราฟิก เรามักจะพบเห็นการประยุกต์ใช้ scene-graph ในเกมยุคใหม่หรือการทำงานร่วมกับรูปภาพเวกเตอร์อยู่ทั่วไป อธิบายพอสังเขป scene-graph เป็น data structure แบบหนึ่ง มักนำเสนอในรูปแบบต้นไม้ (Tree) จะมีโหนดต่างๆ ซ้อนอยู่ภายใน การกระทำที่เกิดขึ้นกับโหนดกราฟิกรูปภาพใดๆ จะส่งผลกระทบต่อโหนดลูกของมันเสมอ ยกตัวอย่างในทางปฏิบัติ การโปรแกรม Swing ถือว่าใช้เทคนิก scene graph แบบง่ายๆ ภายใน container จะมี component ลูกซ้อนอยู่ เมื่อกระทำอะไรกับ container (ขยาย, หด, เปิดปิดการแสดงผล) จะส่งผลกระทบต่อไปยัง component ที่เป็นโหนดลูกของตัวเองเสมอ (ขยาย ยืดหด แสดงผลตาม)

ประโยชน์ของการทำงานในมุมมอง scene-graph จะช่วยให้เราโปรแกรมในมุมมองระดับที่สูงกว่า (เช่น การเล่นกับเอฟเฟกต์ โดยบอกให้โหนดนั้นหมุนเอียง 45 องศา ภายใน 2 วินาที โดยมีความเร่งเท่ากับ 2 หน่วย แทนการกำกับการวาดภาพใหม่ทั้งหมดทีละขั้นตอน) การนำเทคนิก scene-graph มาใช้ไม่ใช่เรื่องใหม่แต่อย่างใด ใน Swing มีโปรเจกต์ Timing Framework ที่ถูกออกแบบมาให้ช่วยแก้ปัญหานี้กับ Swing component โดยเฉพาะ ส่วนโปรเจกต์ SceneGraph จะใช้หลักการเดียวกันแต่ (ปัจจุบัน) สามารถประยุกต์ใช้กับกราฟิก 2D รูปภาพ หรือข้อความอื่นๆ ได้ด้วย โดยไม่ต้องฝังเทคนิก scene-graph ลงในสถาปัตยกรรม (physically) เหมือน Swing แต่ใช้ในรูปแบบมุมมองการคิดตามตรรกะ (logically) เพื่อความยืดหยุ่นในการปรับมุมมองและการประยุกต์ใช้เทคนิกขั้นสูงอื่นๆ กับโหนดต่างๆ ได้ง่ายกว่า

ก่อนหน้านี้ JavaFX Script ภายในใช้ Jazz เป็น scene-graph เอนจิ้น แต่เนื่องจาก Jazz หยุดการพัฒนาไปแล้ว และทีมงานต้องการใช้ประโยชน์เต็มที่จากอุปกรณ์กราฟิกฮาร์ดแวร์ และคุณสมบัติพิเศษที่มีใน 3D เอนจิ้นที่อยู่เบื้องล่าง (Direct3D, OpenGL) เลยเป็นที่มาของการสร้าง SceneGraph ขึ้นมาเอง

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

ที่มา – Project SceneGraph

[update – จากที่พิจารณาอีกทีแล้วพบว่า Timing Framework แม้มันจะช่วยให้การสร้างเอฟเฟกต์ต่างๆ ง่ายขึ้นเยอะ (กำกับแต่เฉพาะว่าต้องการให้วาดอะไร ไม่ต้องบอกวิธีวาดอย่างไร) แต่ก็ยังไม่ได้โปรแกรมในมุมมองที่เป็น scene ยังคงวาดไปตรงๆ ซ้ำๆ ทุกครั้งที่ต้องการ ซึ่งถ้าเป็น scene-graph จริงๆ แล้วแต่ละ scene จะต้องถูกบันทึกไว้เป็นช็อตๆ แล้วเราโปรแกรมกับแต่ละ scene ได้ เท่าที่ไล่ดู API และตัวอย่างการใช้ SceneGraph แล้วพบว่ามันครอบ Timing Framework ไว้อีกชั้นนี่เอง เจ๋งมากๆ!!! ]

รวมของออกใหม่และเก็บตกของเก่า : NetBeans 6, Groovy 1.5, Spring 2.5, Volta

ผมขอเขียนแบบสั้นๆ นะครับ จริงๆ ข่าวยิบย่อยเยอะมาก แต่ขออภัยด้วยละกันครับไม่สะดวกจริงๆ

• NetBeans 6.0 ตัวเต็มออกแล้วนะครับ ความสามารถนำเสนอไปหลายทีแล้ว ตัวนี้ตั้งใจจะรีวิวยาวๆ ให้ดู (เขียนไม่ยอมเสร็จสักที) เพราะมีฟีเจอรเด็ดๆ ที่คนยังไม่รู้ไม่เป็นที่พูดถึงกันอยู่หลายจุดทีเดียว การออกครั้งนี้แถม NetBeans Magazine เล่มใหม่ด้วยแหะ
• Groovy 1.5 ตัวเต็มมาแล้ว จริงๆ แล้วมันคือ Groovy 1.1-rc เดิมๆ นี่แหละครับ แต่เปลี่ยนเลขให้สอดคล้องกับความสามารถใหม่ๆ ที่เพิ่มขึ้นมากมาย ตัวนี้ก็ตั้งใจว่าจะเขียนรีวิวเหมือนกัน เห็นแล้วชอบใจหลายๆ ฟีเจอร์ที่เพิ่มเข้ามาเป็นส่วนผสมระหว่าง Java กับ Ruby ที่เท่ดีครับ
• Spring 2.5 มาแนวเดียวกันครับ ออกมาสักพักแล้วแต่ไม่ว่างเขียนเหมือนกัน เดิมคือ Spring 2.1 แต่ด้วยฟีเจอร์ที่เพิ่มขึ้นเยอะเกินกว่าจะเรียก 2.1 เลยเปลี่ยนเลขเป็น 2.5 ให้ดูสอดคล้อง ฟีเจอร์ที่เพิ่มเข้ามาหลายส่วนทีเดียว ที่เด่นๆ จะเป็นเรื่องของการใช้ annotation แทน XML เหมือน Google Guice
• Volta นิยามของมันจะเรียกว่า GWT Clone จากฝั่ง Microsoft ก็ไม่น่าจะผิดมากนัก โดยมีฟีเจอร์เด่นๆ บางอย่างเพิ่มเข้ามา เช่นการโค้ดด้วยภาษา CLR อื่นๆ ได้ด้วย โปรเจกต์ยังไม่ค่อยสมบูรณ์ดีแต่เปิดตัวนักพัฒนาพรีวิวลองแล้ว ลองอ่านข่าว ZDNet ที่ไปสัมภาษณ์สถาปนิกซอฟต์แวร์ของ Microsoft เปรียบเทียบ GWT กับ Volta
• พูดถึง GWT ผมคิดว่า GWT รุ่นหน้า (1.5 ) น่าจะเป็นรุ่นที่มีนัยสำคัญพอจะฉุดกระแสให้คนหันมาใช้ GWT อย่างจริงจัง

Here Comes Another Bubble

ช่วงนี้ข่าวเยอะนะครับ แต่ผมไม่ว่างเอง ไว้ปีใหม่รอการเปลี่ยนแปลงครั้งยิ่งใหญ่ทีเดียวละกัน ตอนนี้เอา MV ไปดูพลางก่อน : )

โอเพนซอร์ส Java 6 บน Mac OS X เปิดเผย

ผ่านมาหนึ่งปีกับการประกาศโอเพนซอร์ส Java การวนครบรอบหนึ่งปีนี้จะเงียบเหงาไปเลยถ้าเมื่อวานไม่มีประกาศที่สำคัญนี้ออกมา อ่านหัวข้อคงเห็นแล้วนะครับว่า Java 6 บน Mac OS X Leopard รุ่นโอเพนซอร์สเปิดตัวแล้ว

เมื่อวันก่อนผมยังเกริ่นเรื่องนี้ไว้อยู่เลย วันนี้ Landon Fuller เจ้าเดิมประกาศออกมาอย่างเป็นทางการว่าสิ่งที่พยายามประสบความสำเร็จในระดับนึงแล้ว และพร้อมที่จะให้ผู้ใช้ที่สนใจเอาไปทดสอบดูได้ Fuller พอร์ตโค้ดมาจาก Java 6 บน *BSD ต่างๆ เค้าอ้างว่าฟังค์ชันการทำงานทั่วไปจนถึงเรื่องกราฟิก Swing (X11) นั้นใช้ได้แล้ว แต่เรื่องเสียงยังไม่เรียบร้อยดี

Fuller ให้ชื่อรุ่นนี้ว่า Developer Preview Release ซึ่งตอนนี้ยังทำงานได้เฉพาะบน Leopard ที่ฐานอยู่บนซีพียูอินเทลเท่านั้น ส่วน Tiger หรือเครื่องในตระกูล PowerPC ยังต้องรอไปก่อน ซอร์สโค้ดทั้งหมดอยู่ใน Mercurial แล้ว ผู้ใช้ที่สนใจสามารถดาวน์โหลด บิลต์ ทดสอบ หรือรายงานข้อมูลบั๊กได้ รายละเอียดพวกนี้รวมทั้งเรื่องสัญญาอนุญาตผมคิดว่าเข้าไปอ่านที่บล่อกของ Landon Fuller เองน่าจะดีกว่าครับ

คุยกันมาตลอดก่อนที่ Java จะโอเพนซอร์สซะอีกว่าน่าจะมีรุ่นสำหรับ OS X ที่เกิดจากชุมชนสักที กว่าจะสมบูรณ์คงใช้เวลาไม่น้อย ป่านนั้น Java 6 ที่ออกโดยแอปเปิ้ลเองคงจะออกมาแล้ว แต่อย่างน้อยผู้ใช้แมคก็มีทางเลือกอื่นนอกจากบ่นและรอ

ที่มา – Landon Fuller’s Blog

13949712720901ForOSX : เราต้องการ Java 6 บน Mac OS X

คงเห็นโค้ดตัวเลขข้างบน 13949712720901ForOSX แล้วนะครับ เรื่องมันมีที่มาที่ไปว่า Java 6 บน Mac OS X มันไม่ยอมออกซักทีแล้วแอปเปิ้ลก็ทำตัวลึกลับเงียบเป็นเป่าสากไม่ยอมให้ข่าวเรื่องนี้เลยจนคนบ่นแล้วบ่นเล่า นาย Henry Story แทนที่จะบล่อกบ่นธรรมดาๆ เหมือนคนทั่วไปไม่ เกิดอารมณ์บรรเจิดขึ้นมา ออกแคมเปญให้ใครก็ตามที่ต้องการแสดงจุดยืนเรื่องนี้ให้เขียนบล่อกประกาศเลขนี้ออกไปด้วย 13949712720901ForOSX เผื่อว่าคนของแอปเปิ้ลจะเข้ามาเห็นถึงความเดือดร้อนของพวกเราจะได้สำนึกผิดซะบ้าง (คนที่เล่น msn ประจำคงเคยเจอแคมเปญลักษณะนี้แต่ใช้ emoticon แทนมาบ้างแล้ว)

เลข 13949712720901 มันมีที่มาที่ไปน่าสนใจดี ถ้าเอาเลขนี้แปลงเป็นเลขฐาน 16 จะอ่านได้ว่า 0xCAFEBABE405 เจ้า CAFEBABE นี้เป็นเลขอารมณ์ดีที่วิศวกรตั้งไว้เป็น header ของไฟล์ระบบ Universal Binary เพื่อบ่งบอกไฟล์นั้นเป็น Fat Binary หรือเปล่า แล้วไฟล์ที่เป็น Java Class ก็แชร์เลขนี้ร่วมกันอย่างน่าประหลาด ส่วนเลข 405 ที่ต่อท้ายมาจาก HTTP 405 Response ซึ่งหมายความว่า “Method not available” 😛

การแปะเลขนี้มีข้อดีอย่างนึงคือทำให้เราสามารถใช้ search engine ค้นหาดูได้ง่ายไม่ขึ้นกับภาษาพูด ไอเดียนี้เคยถูกนำมาใช้กับการแสดงจุดยืนให้ส่งความช่วยเหลือเข้าไปในประเทศพม่า และไม่น่าเชื่อเพียงอาทิตย์เดียวยอดรวมของผู้สนับสนุนวิ่งไปถึง 17,000 เวบด้วยกัน

ถ้าคุณกำลังเผชิญปัญหาเดียวกันนี้อยู่ หรือต้องการช่วยสนับสนุนอีกแรงก็อย่าลืมเอาโค้ดนี้ไปแปะ เล่ารายละเอียด และชวนคนอื่นๆ ร่วมกันแสดงจุดยืนด้วยครับ ส่วนผมก็ไม่ได้เดือดร้อนอะไรหรอกครับเป็น population hierarchy ลำดับล่าง แต่กำลังอยากได้ MacBook สักเครื่องเหมือนกัน : )

ที่มา – Henry Story’s blog

ส่วนใครที่รอแอปเปิ้ลไม่ไหว อ่านข่าวถัดไปเลยครับ

วิเคราะห์ iPhone, Android กับ Java

ผมห่างหายจากการวิเคราะห์ข่าวไปพอสมควร คราวนี้ขอกลับมาวิเคราะห์ประเด็นมือถือที่เป็นที่พูดกันของทุกคน ผมขอจับไปที่มุมมอง Java บน iPhone และ Android นะครับ

เป็นที่รู้กันว่า ณ ปัจจุบัน iPhone ยังเป็นระบบปิดที่ไม่อนุญาตให้นักพัฒนาอิสระเขียนโปรแกรมให้ทำงานบน iPhone ได้ ด้วยเหตนี้เองเชื่อกันว่าเป็นผลให้หลายคนตัดสินใจรอดูท่าที่ก่อนจะซื้อผลิตภัณฑ์ชิ้นนี้ แต่เมื่อไม่นานทางแอปเปิ้ลได้ออกมาประกาศแล้วว่าต้นปีหน้านักพัฒนาจะมี iPhone SDK ให้ใช้กันแน่

การมาของ iPhone SDK ทำให้หลายคนจับตามองว่าแอปเปิ้ลจะเปิดให้ SDK ลงลึกถึงระดับไหนกัน เพราะการเปิดตัว Android ของกูเกิลโดยเอาเงิน $10 ล้านล่อใจนักพัฒนานับว่าประสบความสำเร็จอย่างสูงในการสร้างกระแสความฮือฮาในหมู่นักพัฒนาทั่วโลกเลยทีเดียว ด้วยเหตนี้ผมคิดว่าแอปเปิ้ลเองจำเป็นต้องเรียกคะแนนคืนบ้าง ไม่ทางใดก็ทางหนึ่ง ข้อได้เปรียบอย่างนึงของ iPhone ที่มีเหนือกว่า Android คือ ณ วันนี้มันมีสิ่งที่จับต้องได้ให้นักพัฒนาลองเล่นได้ทันที นักพัฒนาสามารถพัฒนา ติดตั้งทดสอบ และขายโปรแกรมของตัวเองที่พัฒนาเพื่อ iPhone ได้ก่อนที่ Android จะมีโทรศัพท์จริงๆ ให้ใช้กันแน่ๆ ข้อแตกต่างของเวลาอย่างน้อย 1-2 ปีนี้ถือเป็นช่องว่างเวลาที่ทำให้ได้เปรียบอยู่พอสมควร อย่างน้อยก็น่าจะทำให้ iPhone กลายเป็นผู้นำทางด้านนี้ได้หากแอปเปิ้ลต้องการ

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

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

ตลาดมือถือภายใน 2-3 ปีข้างหน้าจะเกิดการก้าวกระโดดอย่างแน่นอน เทคโนโลยี นวัตกรรมและแนวคิดจะเปลี่ยนไปอย่างที่ไม่เคยเป็นมาก่อน เริ่มจากปีหน้ายังมีสิ่งที่หลายคนจับตามองอีกอย่างนั่นคือ JavaFX Mobile เราน่าจะได้เห็นผลผลิตในตลาดของมันออกมา ถ้าเอา Android จับเทียบน้ำหนักเทียบรุ่นกับ JavaFX Mobile แล้ว นับว่าเป็นมวยที่เอาไปซัดกันได้พอดิบพอดี หลายคนจับตามองว่าการที่กูเกิลประกาศ Android ออกไปนั้นเป็นการประกาศศึกกับซันหรือไม่ แต่ความเห็นส่วนตัวคิดว่ากูเกิลไม่ใช่บริษัทที่จะทำอย่างนั้น ที่ผ่านมากูเกิลเป็นหนึ่งในองค์กรที่โปร Java อย่างหนักบริษัทนึงก็ว่าได้และวางตัวเป็นพันธมิตรที่ดีเสมอมา หลายคนคาดว่าเป็นเพราะกูเกิลวางกำหนดการนี้มาก่อนหน้าซันจะประกาศ JavaFX ด้วยซ้ำ กอปรเรื่องสัญญาอนุญาตและเรื่องขั้นตอนกระบวนการที่ต้องทำผ่าน JCP นั้นกินเวลานานเกินไปเลยทำให้ Android ต้องออกตัวมาในสภาพที่หลายคนสงสัย การออกตัวก่อนของ โจนาธาน สจ๊วตส์ เป็นความพยายามยืนยันสัมพันธ์ที่ดีระหว่างทั้งสองบริษัทก่อนที่ใครจะคิดไปไกล ตราบใดที่ยังไม่มีเครื่องมือถือออกมาเป็นเรื่องเป็นราว เรื่องนี้ยังมีเวลามากพอให้ทั้งคู่จับเข่านั่งคุยกันถึงความเป็นได้เพื่อให้ทั้งสองฝ่ายมีความสุขทันอยู่

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

NetBeans RC1, JBoss Tools 2.0 RC1, Seam 2.0 ออกแล้ว

ไม่ได้เขียนถึง NetBeans มาสักพักใหญ่ๆ เพราะแต่ละ phase การพัฒนาทำกันเร็วมาก การขยับหลักไมล์แต่ละอันทิ้งช่วงห่างกันไม่นาน ยิ่งช่วงใกล้ออกเต็มแก่แบบนี้แต่ละรุ่นมีอายุห่างกันไม่เกิน 2-3 อาทิตย์ คาดว่าปลายเดือนนี้เราจะได้เห็น NetBeans 6.0 ตัวเต็มออกมาสักที

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

ไหนๆ ก็พูดถึง IDE แล้วขอพูดถึงอีกฟากบ้าง ฝั่ง Eclipse ถ้าทำงานเกี่ยวกับ server-side แล้วละก็ JBoss Tools เป็นหนึ่งในปลั๊กอินที่ควรหามาลงอย่างยิ่ง จากที่ได้ลองใช้ JBoss Tools รุ่น Beta มาแล้วผมพบว่ามันทำให้ Eclipse อืดไปเลย หวังว่ารุ่นนี้จะปรับปรุงเรื่องนี้ให้ดีขึ้น แต่ฟีเจอร์หลักของ JBoss Tools 2.0 อีกอย่างคือการสนับสนุน Seam 2.0 ที่เพิ่งออกไปได้ไม่นานนี้

สำหรับผม ผมคิดว่า Seam เป็นกุญแจสำคัญที่ทำให้ EJB 3.0 มีความน่าสนใจและเป็นสิ่งดีๆ ในชีวิตที่พอจะต่อกรกับ Spring ได้ ถ้าใช้ EJB 3.0 แล้วไม่ได้ใช้ Seam ผมว่าความน่าใช้มันตกหวบเลยเหมือนกัน ใน Seam 2.0 มีฟีเจอร์ใหม่ๆ เพิ่มขึ้นมาพอสมควร หนึ่งในนั้นคือการที่เราจะใช้เวบเฟรมเวิร์กอื่นนอกจาก JSF ได้ ที่เห็นในเดโมแล้วก็มีการใช้ Seam ร่วมกับ GWT ส่วน Wicket นั้นได้ยินข่าวมาเหมือนกันว่ากำลังทำกันอยู่ Seam gen ใช้ Maven 2 แทน Ant และสนับสนุนการใช้ Groovy สร้าง Seam คอมโพเนนต์ ฟีเจอร์เต็มๆ อ่านได้ที่นี่ครับ

Seam ในอนาคตจะกลายเป็นแรงบันดาลใจให้กับมาตรฐาน JSR ตัวใหม่ที่ชื่อ Web Bean ศึกษาไว้ก็ไม่เสียหายครับ

ที่มา – NetBeans, JBoss Tools, In Releation to Everyone

การ์ตูน Android ขำๆ

อันสืบเนื่องจากวลีเด็ดในครั้งนั้น …

ปล. กันคนเข้าใจผิด : Java ที่ใช้ใน Android เอา core library มาจาก Apache Harmony นะครับ แล้วก็มี API เหมือน Java ME มากเพียงแต่ต้องเลี่ยงชื่อเพราะเรื่องไม่ compatible 100% ลองเปรียบเทียบ Java ME CDC กับ Android SDK กันเอง (ดูเฉพาะส่วน core library ของจาวา) Android จะออกเป็นลูกผสมนิดๆ ระหว่าง Java ME กับเสี้ยวๆ Java SE บางส่วน

การตูนขำๆ มาจาก Eric Burke เจ้าเดิมครับ : )

Android เปิดเผยตัวเองแล้ว

จากข่าวเก่าๆ ทั้งหลายที่ลือนั้นเป็นอันว่าก็จริงทั้งหมด สรุปอีกรอบโดยลักษณะภาพรวมสถาปัตยกรรมค่อนข้างเหมือนกับ JavaFX Mobile ที่เป็นแพลตฟอร์มครบชุดตั้งแต่ข้างบนลงข้างล่าง ไล่มาจากข้างบน Android จะมี

• โปรแกรมพื้นฐานที่สำคัญมาให้แล้วเช่น โปรแกรมรับส่ง email และ SMS ระบบปฏิทิน ระบบแผนที่ ระบบสมุดรายชื่อ เวบบราวเซอร์ ฯลฯ โปรแกรมสำเร็จรูปพวกนี้จะคุยกับ
• แอพลิเคชันเฟรมเวิร์กข้างล่างที่ทำหน้าที่ประสานกับไลบรารีและตัว Android รันไทมอีกทีหนึ่ง
• ถ้ามองเฉพาะตัวรันไทม API ก็เทียบได้กับ Java ME ชนิด CDC ที่ตัดชุดแสดงผลออกไปแล้วเสริม GUI toolkit ของ Android เองเข้าไป ส่วนตัว VM นั้นเป็น Dalvik VM ที่ออกแบบมาพิเศษเพื่อให้แอพลิเคชันแต่ละตัวทำงานบน VM ของตัวเองอย่างมีประสิทธิภาพ กินหน่วยความจำน้อย โดยจาวาคลาสเมื่อถูกคอมไพล์แล้วจะถูกแปลงเป็นไฟล์ .dex ที่ DVM อ่านรู้เรื่อง
• ส่วนไลบรารีเพิ่มความสามารถอื่นๆ มีหลายตัวน่าสนใจทีเดียว
  • WebKit โอเพนซอร์สเวบบราวเซอร์เอนจิ้น
  • OpenCORE ของ PacketVideo สำหรับเล่นไฟล์มัลติมีเดียหลากหลายฟอร์แมตทั้งภาพนิ่ง เสียง และไฟล์วิดีโอ
  • SGL ตัว vector-based กราฟิก 2D เอนจิ้นที่กูเกิลได้มาจากการเข้าซื้อ Skia
  • ตัว 3D ไลบรารีไม่รู้เหมือนกันว่ามาจากไหนเพราะในหน้าแนะนำไม่ได้เขียนเอาไว้ บอกแค่เพียงว่ามันเป็น implementation ของ OpenGL ES 1.0 API
  • FreeType ไลบรารีจัดการเรื่องฟอนต์
  • SQLite ฐานข้อมูลขนาดเล็กอันเป็นที่นิยม
• Linux Kernel รุ่นที่ใช้คือรุ่น 2.6 ทำหน้าที่เป็นเลเยอร์ขั้นเพื่อเชื่อมโลกซอฟต์แวร์กับฮาร์ดแวร์เข้าด้วยกัน

นอกจากตัว Android SDK ที่กูเกิลปล่อยออกมา ยังมีชุดพัฒนาที่อยู่ในรูป Eclipse plugin ออกมาพร้อมกันอีกด้วย ซึ่งเครื่องมือนี้ทำตัว emulator เพื่อจำลองการแสดงผล และช่วยในการ debug โปรแกรม

หลังเปิดตัวกูเกิลก็เริ่มแคมเปญประชาสัมพันธ์ทันทีโดยตั้งประกวดการแข่งพัฒนาซอฟต์แวร์บน Android แพลตฟอร์มชิงรางวัลรวม 10 ล้านดอลลาร์ กติกาตรงไปตรงมาการสมัครแบ่งเป็นสองรอบ รอบแรกเริ่มต้นปีหน้าถึงต้นเดือนมีนาคม 50 ทีมที่ผ่านรอบแรกรับไปเลยทันที $25,000 เป็นทุนในการพัฒนา 50 ทีมนี้จะมี 10 ทีมที่ได้รับรางวัลมูลค่า $275,000 ต่อทีม และ 10 ทีมต่อมาจะได้รับรางวัลมูลค่ารวม $100,000 ต่อทีม งานนี้ประกาศผู้ชนะเลิศปลายเดือนเมษายน ส่วนการประกวดรอบสองจะเริ่มหลังจากแอพลิเคชันในรอบแรกเปิดให้ใช้งานได้แล้วในครึ่งปีหลัง

เห็นเงินแล้วตาโตเหมือนกัน ขอติดสัก 50 ทีมแรกก็หรูแล้วละ : )

ที่มา – Android, Android Challenge

MV : Mac or PC

Vodpod videos no longer available.