วันนี้ผมขออธิบายคำศัพท์ 2 คำที่เกี่ยวกับการ Copy Object ครับ Shallow copy Shallow copy คือ การ Copy Object โดยที่ข้อมูลยังมี Reference เชื่อมโยงกันในหน่วยความจำครับ ดังรูป Deep copy Deep copy การ Copy Object โดยสร้างอีก Object หนึ่งเลย โดยไม่มี Reference เชื่อมโยงกันในหน่วยความจำครับ ดังรูป สำหรับ Blog ในตอนต่อไปเป็นการแสดงตัวอย่างการ Copy Object ในภาษา Java และ C# ครับ สุดท้ายนี้ครับ เวลาเขียนโปรแกรม สิ่งที่เราต้องรู้…
หลายคนอาจจะมองว่า Open Source เป็นของฟรี ถูกครับ แต่ยังุถูกไม่หมดครับ เพราะมองง่ายๆ ว่าใช้ฟรี แต่ถ้าเอาไปพัฒนาต่อก็ต้องดูสัญญาตามนี้นะครับ โดยผมขอสรุปเท่าที่ผมรู้บางตัวนะครับ GPL-GNU (General Public License) LGPL (Lesser General Public License) BSD(Berkeley Software Distribution License),MIT(Massachusetts Institute of Technology License) Apache License หมายเหตุ: ถ้าเอา Library ในกลุ่มพวกนี้มาใช้ควรศึกษากฏให้ดีด้วยนะครับ โดยเฉพาะตัว GPL และที่สำคัญควรให้เกียรติกับทีมงานที่พัฒนา Library ที่เราเอามาใช้ด้วยการอ้างอิงไว้ด้วยนะครับ ที่ต่างประเทศพลาดที่นี้ฟ้องกันจนเจ๊งเลยนะครับ References
เขียน Code มา 2 ปี บางทีเราสงสัยว่า เรากำลังทำอะไร ทำให้เสร็จส่งลูกค้าพอหรือป่าว ทำไปปุ๊บหมดโปรเจคออกก็ทิ้งหนี้(พวก Spaghetti Code และอื่นๆบราๆ) ให้คนรุ่นหลัง วันนี้ผมอยากเสนอ keyword ในการพัฒนา Software 2 คำ ซึ่งมันต้องไปด้วยกันนะครับ ไม่ใช่เลือกอย่างใด อย่างหนึ่ง ดังนี้ Right Software (Validation) คือ เราทำ Software ได้ ตรงสิ่งที่คุณลูกค้าต้องการ Software Right (Verification) คือ เราทำ Software ที่มีพื้นฐานดี โดยเค้าพื้นฐานดี เราอาจจะมองว่าระบบของเรา ตรงสเปค…
ผ่านจากวันงานมาและ 5 วัน เพิ่งจะมาเขียน งานจัดวันที่ 9 พฤษภาคม 2558 ครับ (ด่าตัวเองไว้ก่อน ฮ่าๆ เพราะจะได้เขียนให้ตัวเองสรุปสิ่งได้ลง Blog ก่อนที่จะลืมมันไปครับ) โดยงานวันนี้เป็นงานที่ผมรอมา 2 ปี น่าจะใช่นะ ที่สามารถจองตั๋วทัน ฮ่าๆ โดยเมื่อมาถึงในงานผมขอสรุปงานในวันนั้นคร่าวๆ ดังนี้ครับ ช่วง 8.00 – 10.00 เป็นช่วงการลงทะเบียน และการนำเสนอ แบ่งปัน Idea ต่างๆครับ โดยช่วงก่อนเริ่มงาน มีการใช้ Speaker มาเสนอหัวข้อตัวเองครับ ว่ามีความน่าสนใจแค่ไหนครับ โดยงานนี้ เราจะไม่ได้เข้าฟังทุก Session ต้องเลือกหัวข้อที่สนใจครับ…
ในการทำระบบงานต่างๆ ไม่ว่าจะระบบเล็ก หรือเป็นระบบใหญ่ขึ้นมาสักระบบนึง แน่นอนเลยว่าข้อมูลย่อมมีมหาศาลมากมาย แต่เราจำเป็นไหม ? ว่าจะต้องทำหน้าจอขึ้นมา เพื่อจัดการกับข้อมูลเหล่านี้ คำตอบ คือ ไม่ครับ ในข้อมูลส่วนที่ไม่ต้องมีการแก้ไขบ่อยๆ เช่น ข้อมูลจังหวัด ข้อมูลประเทศ หรือ เป็นข้อมูลราคาหุ้นจากตลาด SET หรือ MAI ครับ ปัญหาถัดมา คือ เราทำอย่างไร เพื่อไม่ให้ข้อมูลเหล่านี้มันหายไป ตอน Migrate ระบบ หรือระหว่างการใช้งาน เพื่อไม่ให้ User มือบอนไปกดลบได้ครับ ? ทางเลือกนึงที่ใช้ คือ การกำหนด Flag ขึ้นมา หรือเพิ่มคอลัมน์ในฐานข้อมูลเราแหละครับ แต่ถ้ามองไปอีกที…
สำหรับบางคนที่เพิ่งเรียนเรียน Programming หรือ เพิ่มเริ่มทำงานใหม่ๆ อาจจะสงสัยว่าทำไมอาจารย์ หรือ พี่ที่ทำงานถึงมีข้อกำหนดในการเขียน Code ขึ้นมา ซึ่งบางข้ออาจจะดูไม่จำเป็นเลย เช่น หากเรามองแค่ผิวเผินแล้ว อาจจะคิดในใจว่าต้องการความเป็นระเบียบ ให้ Code สวยงาม เพื่อที่เรา หรือคนอื่นมาเขียนต่อภายหลังได้ง่าย แต่ถ้ามองลึกๆลงไป มันอาจจะเป็นกุศโลบายอย่างหนึ่งก็ได้ ซึ่งแฝงไปด้วยแนวคิด และทฤษฏีที่ซับซ้อน โดยผมจะอธิบาย แต่ละข้อเลยยะครับ ข้อแรก Method ที่เขียนขึ้นมาควรจะไม่เกิน 20 บรรทัด หรือ แสดงไม่เกินไม่เกิน 1 หน้าจอ หากเรามองลึกลงไป ทำไมต้องไม่เกิน 20 บรรทัด หรือ 1 หน้าจอ ซึ่งแนวคิดนี้จะลึกให้เราต้องกำหนดการทำงานของ…
อ่า Blog นี้ถูกเขียนมาตั้งแต่ปี 2014 ครับ วันนี้ได้เวลาดีมาเขียนให้จบซะที (ปล่อย Blog Public มาได้ 2 ปีและ) เพราะ ตัว App ที่เป็น Workshop ที่เตรียมไว้ ใช้งานกันแพร่หลายในที่ทำงานแล้วครับ ใช้มา ก็ 2 ปีกว่าและ มาเข้าเรื่องดีกว่า MVP ย่อมาจาก อะไร Most Valuable Player เป็น Boss ใน Game หรือป่าว ? – ไม่ใช่ครับ Minimum Viable…
ในชีวิตการทำงานจริง การพัฒนาออกแบบ Software ระบบหนึ่งขึ้นมา คงไม่ได้มีเพียง File เดียว หรือ Method Main อย่างเดียวแน่ๆ เหมือนตอนที่เรียนอยู่ในมหาวิทยาลัย โดยการทำงานจริงนั้น เราต้องแบบระบบงาน Software ที่ทำอยู่ออกมาเป็น Module หรือ Component ต่างๆ และท้ายที่สุดได้ Class Diagram แต่เมื่อออกแบบเสร็จแล้ว เราจะมั่นใจได้อย่างไรว่า Code ที่เราออกแบบนั้น ไม่มีการทำงานที่ซับซ้อน หรือมีโครงสร้างที่ซับซ้อนมากเกินไป จนทำให้ในอนาคตเมื่อมีการแก้ไข Code นั้นแล้วอาจจะทำให้กระทบไปทั้งระบบ แล้วเราจะมีวิธีจัดการอย่างไงให้สามารถลดความซับซ้อนของระบบได้ ผมขอแนะนำแนวคิด 2C ได้แก่ Cohesion และ Coupling (ลองดูรูป…
จากบทความที่แล้ว แสดงวิธีการเขียน Code กับโจทย์ปัญหา FizzBuzz โดยไม่ใช่ IF กันแล้วนะครับ แต่ผมยังทิ้งท้ายไว้อีกปัญหานึง คือ ถ้ามีเงื่อนไขเพิ่มขึ้นมาหละ โดยให้แสดง WOOF ้เพิ่ม ถ้าตัวเลขนั้นหาร 7 ได้ลงตัว (อ้างอิงจาก WIKI FIZZ BUZZ WOOF ) เราจะมีวิธีการแก้ปัญหาอย่างไรนะครับ โดยผมขอทวนวิธีการที่ใช้แก้ปัญหาใน Blog ตอนที่แล้วก่อนนะครับ
จากบทความที่แล้ว FizzBuzz Problem ไปนะครับ ต่อไปผมลอง Refactor Code อีกรอบ โดยมีเงื่อนไขว่าห้ามใช้ IF ในส่วนของ Logic Fizz และ Buzz ทำไมถึงต้องห้ามใช้ IF เพราะ การใช้ IF ส่งผลให้เกิดความมักง่ายของ Developer ทำให้เกิดปัญหาในการแก้ไข หรือพัฒนา Module เพิ่มเติม ต้องไปแก้ Code จนเกินความจำเป็น และทำให้เกิด Defect(ฺBug) เพิ่มขึ้นด้วย ซึ่งมีแนวคิดทางวิชาการมาสนันสนุนแนวคิดนี้อย่าง The Open Close Principle (OCP) และ High Coupling &…
