Fanboi Channel

มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

Last posted

Total of 104 posts

58 Nameless Fanboi Posted ID:FCI1IDHtpb

จากประสบการณ์ของผม ที่เป็นมาหมดทั้งลูกจ้าง ไปยันผู้ประกอบการ ทำตั้งแต่ล่างสุดยันบนสุด ทำตั้งแต่ technical ยัน business และ Operation ทำให้เข้าใจมุมมองจากในทุกๆส่วน และทุกๆคนในทีม

เอาคร่าวๆ คือราวๆนี้

เส้นทางรับจ้าง
Programmer -> Project Leader -> Project Manager -> General Manager

เส้นทางเจ้าของธุรกิจ
COO, CTO - Software House
CEO, CTO - บริษัท Startup

4 Concept ที่อยากให้ทุกๆคนได้เรียนรู้ ถ้าอยากจะเจริญรอยมาเป็นเจ้าของบริษัทนะครับ คือ

1. Design thinking
2. Lean Startup
3. Agile
4. Growth Hacking

โดยควรจะเริ่มรู้ตั้งแต่ 3-> 2-> 1-> 4 ตามลำดับ ไม่ก็ 3-> 1-> 2 -> 4

อยากพูดคุยเล่นๆ ก่อนงานที่ผมสอนจะเริ่ม อยากแนะนำแบบตัวตัว หรือกลุ่มเล็กๆ หน่ะครับ

วันที่ 23 เมษายน นี้ เวลา 17.00-18.00 ที่งานนี้ https://aevent.in/archives/event/scrum-workshop

วันที่ 4 พฤษภาคม นี้ เวลา 17.00-18.00 ที่งานนี้ https://aevent.in/archives/event/lean-startup-101

สบใครสนใจในทุกๆเรื่อง สามารถมาพูดคุยแลกเปลี่ยนประสอบการได้ ในช่วงที่ระบุนะครับ

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

59 Nameless Fanboi Posted ID:N7ePXFFTG7

ตอนนี้เป็นยอดมนุษย์ Ultra man อยู่

BU อื่นเค้ามี BA ช่วย มี App sup ช่วย แต่ BU ที่ทำนี่ I am alone เลยตอนนี้ ทำเองทุกอย่าง ตั้งแต่ PM ยัน App sup อีกนิดก็จะเขียนโค้ดด้วยละ
การ์ด ก็ต้องเขียน ประชุมก็ต้องมี ไปประชุมจนจะเป็นพนักงานของบริษัทอื่นไปแล้ว คนที่ประชุมด้วยบอก นี่เราคุยกันมากกว่าที่เค้าคุยกับสามีอีกนะ 555
activity ก็ไม่ได้ขาด refinement , planning , review มีหมด
recruit , ทำตารางนัด, สัมภาษณ์เองอีก อาทิตย์ละ 6-7 คน
ประสานงานกับทีมอื่นๆอีกมากมายหลายอย่าง หลายเรื่อง

ถึง Office ตั้งแต่ 7.30 น. คิดดู บางคนยังไม่ตื่นเลย
มาถึงไม่ใช่ว่ามานั่งกินข้าวนะ (บางคนถึง 10 โมง ยังมานั่งกินข้าวอีก) คือมาถึงก็ทำสิ่งอันเป็นการเป็นงานเลย มื้อแรกคือ หลังเที่ยง (ทำ IF 16/8 อยู่)
นี่ไม่นับงานส่วนตัว ที่ก็ยังทำต่อเนื่องนอกเวลางานอีกนะ
และก็ยังต้องมีเวลาให้ครอบครัวอีกด้วย
เรื่องสุขภาพไม่ต้องห่วง จัดสรรเวลาไปออกกำลังกายอยู่เรื่อยๆ (แต่บางช่วงหนักจริงก็ผ่อนเรื่องออกกำลังกายเหมือนกัน)

เรียกได้ว่า ใช้ทุกนาทีให้คุ้มค่า ดันให้เกิด productivity สูงสุด

60 Nameless Fanboi Posted ID:5rxn/zkmiu

มีคน เสพติด Deadline Driven Development นะ และมักจะมองว่าคนที่ไม่เชื่อเหมือนเขา ไม่เข้าใจ ไม่อดทน ไม่ปรับตัว ... คำถาม จริงๆแล้วเขาก็ลืมไปหรือป่าวนะว่า เขาก็ไม่เคยเปลี่ยนเลย

#มิตรสหายท่านหนึ่ง

61 Nameless Fanboi Posted ID:9HdytddRrA

Go นี่ขึ้น Mainstream แล้ว ตัวชี้วัดที่ศูนย์มีของบน Production จริงมากมาย
ตัวชี้วัดแรกคือมีคนออกมาด่า
ตัวชี้วัดที่สองคือมีคนบินไปงาน Conference จำนวนมหาศาลจากหลายภาคส่วน
ตัวชี้วัดที่สามมี meetup ต่อเนื่อง
ตัวชี้วัดที่สี่มีคนเขียน blog ต่อเนื่องจากหลายภาคส่วน...
เลิกกังวลได้แล้วครับว่าจะหาคนเขียน Go ไม่ได้ ที่น่ากังวลกว่าคือพี่จะไม่เรียนรู้อะไรใหม่เลยหรอครับ :)

#มิตรสหายท่านหนึ่ง

62 Nameless Fanboi Posted ID:8aHt40gOVm

ก่อนพรุ่งนี้ในวันทำงาน เราควรมีเรื่องภูมิใจเล็กๆไม่สิเรื่องมาเล่าสู่กันฟัง ในสายงาน C Level ของผม

- เราไม่ได้รับงานโปรเจคต่อ เค้าต้องเอาคน 50-80 คนมาทำต่อเราเพื่อให้ productive เท่าเดิม แต่เราใช้แค่ 8-10 คน

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

- เราเสนอราคาและโซลูชั่นไป คิดว่าราคาสมเหตุสมผล เค้าหายไป 3 เดือนกลับมาหาเราคุยต่อ แต่เราคิวงานเต็มซ่ะแล้ว

- ปฏิเสธงานโปรเจคไปเกือบๆ 10 ล้านบาทแล้วใน Q1 นับเฉพาะที่บิตงานได้แล้ว เพราะว่าไม่บาล้านระหว่าง 3 อยู่ ทีมงาน(ทำได้สบายใจ) ลูกค้า(ได้ของดี,ให้ความสำคัญกับโปรเจค) และราคา(สมเหตุสมผล)

ผมนึกคำของบิลเกตได้ “ถ้าคิดราคาเขียนโค๊ดแบบนับจำนวนคนคูณชั่วโมง มันก็ไม่ต่างกับการคิดราคาการสร้างตึกด้วยการชั้งน้ำหนักของตึก”

อีกอันของผมคิดเอง
“ถ้า software ไม่ใช่จุดแข็ง ก็เป็นจุดอ่อน”

สุดท้าย
“บริษัทที่ยอมเสียเวลา เพื่อได้พัฒนา Software ราคาถูกเพียงอย่างเดียว บริษัทจะเสียทั้งสองอย่าง”

63 Nameless Fanboi Posted ID:qfI9HiwXHb

ความสุขนำพา ทำงาน 7 วันต่อสัปดาห์ก็ยังรู้สึกดี
.
นิยามความสุขของแต่ละคนคงต่างกันไป บางคนคือการไปเที่ยว บางคนคือการเดินทาง บางคนคือการมีใครสักคน แต่สำหรับเรา ความสุขเกิดจาก "การได้พัฒนาตัวเองให้เก่งขึ้น" และได้สร้าง "ผลงาน" ที่สร้างอิมแพคต่อวงกว้างออกมา
.
มาอยู่นี่โชคดีมากที่ได้ทำสิ่งที่ว่ามานี้หมดเลย
.
ช่วงสองเดือนที่ผ่านมางานหนักมาก แต่ไม่ได้หนักในทางไม่ดี ตรงกันข้าม มันท้าทายและสนุกมาก ต้องทำอะไรที่แข่งกับเวลา ศาสตร์ที่ต้องทำก็เป็นงานด้าน Software Engineer ที่ครบเลย ไม่ว่าจะอัลกอเอย Math เอย Optimization เอย Hacking ก็มี ได้เรียนรู้อะไรใหม่ ๆ ตลอดทางเยอะมาก
.
ได้ทำของสนุก ๆ ก็มีความสุขแล้ว แต่โชคดีชั้นสองคืองานที่ทำมีคนเอาไปใช้งานเยอะมาก ๆ อีกด้วย
.
ช่วงที่ผ่านมาเลยทำงานทุกวันตลอดเวลาจริง ๆ ไม่ใช่เพราะ Deadline อะไรทั้งสิ้น บริษัทก็ให้ทำแค่ 5 วัน แต่นี่อยากทำเอง ตื่นมาก็ทำ ๆ ๆ ๆ ๆ เพราะรู้สึกตื่นเต้นกับความรู้ที่ได้รับเพิ่ม แล้วก็ตื่นเต้นกับผลลัพธ์ที่ได้
.
อย่างวันก่อนนั่งใช้เวลาค่อนวันปรับอัลกอโค้ดจาก O(n^2) ให้เหลือ O(log n) จน Optimize โค้ดให้รันเร็วขึ้น 10 เท่าได้ (แปลว่า Cost ของ Server ก็ลดลง 10 เท่าด้วยเช่นกัน) เหมือนเป็นเรื่องเล็ก ๆ แต่ผลลัพธ์ที่ได้ทำให้รู้สึกว่าเราใช้เวลาไปอย่างมีค่า อยากทำอีก อยากทำเรื่อย ๆ บอกไม่ถูกว่าสุขขนาดไหน เอาเป็นว่าแฮปปี้มากละกัน 555
.
หรือสัปดาห์ก่อนตอน Facebook ประกาศว่าเปิดให้คนโพสต์ 3D Photo ผ่านคอมพ์ได้แล้วนะ นี่ก็ใช้เวลาคืนนั้นเขียน MVP แล้วเปิดให้คนใช้เช้าวันถัดไปเลย ตอนนี้คนเข้ามาใช้เยอะมาก ๆ รู้สึกแฮปปี้กับ Impact ที่สร้างสุด ๆ
.
ผลงานที่สร้างให้ลูกค้าใช้ก็รู้สึกอยากทำให้มันดีขึ้นตลอดเวลา อยากให้ลูกค้าเห็นการปรับปรุง เห็นประสิทธิภาพที่ดีขึ้นและแฮปปี้กับมันยิ่ง ๆ ขึ้นไป แค่นึกถึงหน้าลูกค้าตอนได้เจอของดีที่ดีขึ้นแล้วทำให้ไม่อยากหยุดทำงานเลย
.
ความสำเร็จไม่มีวันหยุดราชการ อย่าปล่อยให้เวลาผ่านไปอย่างไร้ค่ากันเลย หากยังเกลียดวันจันทร์อยู่อาจต้องหาสาเหตุกันละนะว่าทำไม หาคำตอบให้ตัวเองให้ได้ว่าความสุขคืออะไร ปรับตัวเข้าหามันให้ได้ ชีวิตคนเราสั้นเกินกว่าจะนั่งทำสิ่งที่ตัวเองไม่ชอบไปวัน ๆ
.
อย่างที่คนเค้าว่ากันแหละ ถ้าได้ทำงานที่รัก ... คุณจะไม่ได้หยุดพักอีกเลย
.
เค้าว่ากันงี้เปล่านะ จำไม่ค่อยได้

64 Nameless Fanboi Posted ID:qfI9HiwXHb

ช่วงบ่น

Object oriented เริ่มมาจาก Alan Kay

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."

คือประเด็นของเขา เขาอยากซ่อน State processing

คือระบบสมัยนั้นมันมี Spaghetti code เยอะ State มันพันกัน ก็เลยบอกว่า เราแยกเป็นส่วนๆ Subsystem แล้วคุยกันผ่าน Message ได้มั้ย มันจะได้การันตีได้ว่า State ตรงนี้ไม่โดนใครกระทบ (นอกจาก Interface ของส่วนนั้น)

ถ้าพูดให้เห็นภาพคือ จากโค้ดสปาเก็ตตี้ก้อนใหญ่ เราได้สปาเก็ตตี้ก้อนเล็กๆ หลายๆ ก้อน ที่การันตีว่า มันไม่พันข้ามกัน ทีนี้เวลาเราจะแก้ไขจะ Debug มันก็รู้แล้วว่ากระทบแค่ไหน ไม่เหมือนเมื่อก่อนที่มีโอกาสกระทบหมด

อันนี้คือ Essence คือ Priority อันแรก และมีผลทาง Practical ด้วย คือแก้โค้ดตรงนี้เราบอกได้ว่ามันกระทบแค่ไหน ไม่ใช่นั่งพารานอยด์ว่าจะโดนนั่นมั้ยโดนนี่มั้ย มันจำกัดจุดระวังได้ ไม่ใช่พันกันจนแค่จะแก้ Bug เล็กๆ ต้องมานั่ง QA ระบบทั้งเดือน อะไรเงี้ย

ทีนี้คือบางทีเคยไปเห็นโค้ดที่มี 2 Object ที่ Share state กันบน Global singleton โดยบอกว่าต้องแยกเป็น Object เล็กๆ ตาม Single responsibility principle แล้วแบบ แถมคุยกันแบบใช้ Design pattern อย่างหรู เราก็ได้แต่เอิ่ม.......

คือสุดท้ายคุณสร้าง Object ใหญ่กว่านี้หน่อยแต่ไม่ต้องประกาศ Global singleton แล้วมันลิมิตว่าแก้โค้ดแล้วจะกระทบแค่นี้จะดีกว่าเยอะเลยนะ ดันไปเชื่อว่าออบเจ๊กต์ต้องเล็กแล้วเอามันมามี Priority อยู่เหนือกว่า Practical implication โค้ดก็พันกันแก้ยากอ่ะครับ

คือผมว่า บางที OOP Industry มันมาไกลจนลืมแก่นบางอย่างและลืมไปว่าเราใช้มันแต่แรกเพราะอะไร

ปัญหาที่ทำให้คนคิด Coding pattern กับ Programming paradigm มีแค่นี้

"โค้ดพันกัน เพื่อนหาไม่เจอว่าโค้ดอยู่ไหน มี Bug ดูแถวไหนดี แล้วพอผ่านไปซักพักผมไม่รู้ว่าแก้ตรงนี้จะกระทบโดนเท่าที่มันควรกระทบมั้ย ทำไงดี"

ทั้งหมดมันมาตอบคำถามนี้แหละ ซึ่งใครตอบคำถามนี้ได้อย่างหมดจด ทีมคุณจะ Productive มากๆ จนมี Unfair advantage เลยแหละ

65 Nameless Fanboi Posted ID:XyRw/B5NAD

นับว่าเป็นเรื่องปฏิวัติวงการ hacker และวิธีการป้องกันการถูกแฮกเลยทีเดียว เมื่อกองทัพอิสราเอล ตรวจพบว่าอาคารแห่งนึงในฉนวนกาซา เป็นฐานทัพนักรบไซเบอร์ ของกลุ่มฮะมาส (ฝั่งตรงข้าม) จึงสั่งการเอาเครื่องบินกองทัพอากาศ บินทิ้งระเบิดใส่แฮกเกอร์ซะเลย เพื่อป้องกันการถูกแฮก! 😂😂😂 ตำรา computer security ต้องจารึกเหตุการณ์นี้จริง ๆ เป็น การจัดการความเสี่ยงด้านความปลอดภัยทางกายภาพ ไม่ต้องซื้อ Firewall กันเลยทีเดียว

ทวิตเตอร์ของกองทัพอิสราเอลทิ้งท้ายไว้ว่า "HamasCyberHQ.exe has been removed." พี่ดุไปนะ น้องเริ่มไม่ไหว 😂

ที่มา: https://twitter.com/IDF/status/1125066395010699264

66 Nameless Fanboi Posted ID:OP0+mxhv7m

ว่าด้วยการ "สเกล AI"
.
ต้องยอมรับว่า AI นี่พลิกวงการโปรแกรมมิ่งจริง ๆ อะไรที่ทำไม่เคยได้ตอนนี้ทำได้สบาย ๆ เลย
.
แต่ในแง่ของ Architecture เบื้องหลังที่เป็น Neural Network การจะทำให้รันได้เร็วก็ต้องใช้ GPU คราวนี้ถ้าเกิดทำงานบน Server Side ก็ต้องเปิด Instance ที่มี GPU เอาไว้ ซึ่ง ... แพงสาสสสส (ถูกสุด $225 ต่อเดิอน)
.
ช่วงที่ผ่านมามี Deploy AI ขึ้นโปรดักส์ชันอยู่สามตัว ใช้ GPU หมด บิลแต่ละเดือนมานี่น้ำตานอง ไม่บอกว่าเท่าไหร่ แต่นองคือนองจริง ๆ
.
ปัญหาเรื่องแพงก็เรื่องนึง แต่ที่แย่สุดคือ "สเกลไม่ได้" เพราะถ้าจะสเกลก็ต้องจ่ายเพิ่มอีก Concurrent ละ $225 คือมันไม่ Practical สุด ๆ ถ้าคนเข้ามาเยอะขึ้น 10 เท่านี่ไม่หมดตัวกันเลยหรอ
.
หลังจากรันมาหลายเดือน Demand เริ่มเยอะขึ้น แต่การสเกลมันมีข้อจำกัด เมื่อคืนเลยทนไม่ไหว ยอมเอาส่วนการคำนวณที่ต้องใช้ GPU ออกหมดและเลือกรันด้วย CPU ล้วน ๆ เอาแทน ตอนจะสเกลก็สเกล CPU เอา (ราคา Concurrent ละ $24 เท่านั้น)

ซึ่งผลจากการเปลี่ยน GPU เป็น CPU คือมันช้าลงแต่แค่ 0.5-3 เท่าตัวเท่านั้น ยอมรับได้กับราคาที่เซฟไป ตอนนี้จะขยายขึ้น 10 เท่าก็ไม่หวั่นละ พร้อม !
.
สุดท้าย AI คืออนาคตจริงแต่ต้องหาวิถี Optimize Cost ให้ได้ ไม่งั้นก็ทำธุรกิจยากอยู่ดี ที่ทำมาก็
.
- โยกไป CPU
.
- เอาไปรันด้วย ML Engine (ซึ่งก็แพงถ้าเทียบกับพวก CPU Based อย่าง App Engine หรือ Cloud Run)
.
- ทำ Model ให้เล็กจนรันบน Client Side ได้
.
ก็เป็น Key Takeaway นึงเผื่อใครจะทำ AI Based ก็คำนึงถึงค่า Server กันด้วยนะ !

67 Nameless Fanboi Posted ID:U.OOM/4Wi.

เป็นคำถามที่ดี ที่คิดได้
และคำตอบ นั่นล่ะคือชีวิตจริง

เคยเล่าไปแล้วว่าเด็กรุ่นใหม่มักกระหาย new tech และพยายามจะใช้ของใหม่ที่สุด ซึ่งสุดท้ายมันนำไปสู่สิ่งที่คิดกันไม่ถึง ไม่ว่าจะเป็น

- knowledge มีน้อย
- ไม่มี support ที่ดีพอ
- เพื่อนร่วมทางน้อย ถามใครก็ยาก
- หาคนคุยด้วยได้ยาก ต่อยอดเองก็ไม่ได้
- เปลี่ยนมือแล้วต้องรื้อระบบ เพราะคนส่วนใหญ่ไม่ใช่สิ่งนี้กันหาคนมาต่อช่วงไม่ได้
- user ได้รับ impact เพราะพฤติกรรมบางอย่างในการใช้งานมันเปลี่ยนไป (มากน้อยเป็นอีกเรื่อง)
- งานอาจจะใช้เวลาเยอะกว่าปกติ เพราะต้อง reseach และงมปัญหามากกว่าปกติ
- business ต่อยอดไปไม่ได้ เพราะวนไปที่เรื่อง technical limitation
- เสี่ยงต่อการถูกทิ้งกลางทาง เพราะ technology นั้นไม่ต่อยอดหรือมีตัวอื่นที่ดีกว่าออกมาแทนที่ และ incompatibility กัน(อันนี้เจ็บกันเยอะ)​

สุดท้าย developer คิดว่าตัวเอง cool เพราะได้ใช้ของเจ๋ง แต่ business ยัน user ไม่มีใครคิดอย่างนั้นเลย

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

เรื่องนี้เคยเจ็บปวด และโดนด่ามาตั้งแต่ประมาณ 10ปีที่แล้วได้ ตอนนั้นจำได้เลย เขียน marketing campaign ยุคแรกๆของ jQuery ต่อมา prototype หรือ backbone นี่แหล่ะออกมา ก็เลยเปลี่ยนไปใช้ แล้วปรากฏว่ามันพังบน internet explorer 6 ซึ่งแก้ไม่ได้เพราะมันติดตั้งแต่ระดับ lib เลย แล้วไม่มีเวลาแก้แล้ว เพราะงาน marketing campaign พวกนี้ประมาณว่าสั่งวันนี้ แต่จะเอางานตั้งแต่เมื่อวานนะได้มั้ย อะไรแบบนี้ เลยโดนด่า เพราะปกติไม่เคย deliver งานพังๆออกมา และต้องขอเลื่อนอีกสองวันเพื่อรื้อกลับไปใช้ jQuery เหมือนเดิม เลยได้เรียนรู้ตั้งแต่นั้นเป็นต้นมา

ของใหม่ แต่ทำแล้วใช้ไม่ได้ ก็ไม่ได้มีค่าอะไรเลย

68 Nameless Fanboi Posted ID:U.OOM/4Wi.

เพราะระบบ ATM มีมาตั้งแต่ก่อนพวก embedded แบบ Pi จะเกิด

ส่วนที่ถามว่า Windows 7 หมด support แล้วจะเปลี่ยนได้ไหม ?
ทางทฤษฎีก็เปลี่ยนได้ แต่ทางปฏิบัติมันไม่คุ้มที่จะเปลี่ยน เพราะ impact เยอะมาก
เพราะถ้าจะใช้ Pi ก็ต้องเขียนใหม่ --> test ใหม่ทั้งหมด ทั้งด้าน functional และ non-functional
แถมไม่มีอะไรการันตีอีกว่า test เข้มข้นแล้วจะยังมีเคสไหนหลุดไปอีก

ในขณะนี่ทางเลือก Windows upgrade แค่ทำ compatibility check แล้วก็แก้บัคเล็กน้อยเท่านั้นพอ

ความเสี่ยงมันต่างกันเยอะครับ
ไหนจะความเชี่ยวชาญของ Resources ในธนาคาร
การ Support จากเจ้าของ OS (MS vs. Open source)
ที่ MS มีให้คือความแน่นอนและการันตีเวลาทำงาน มี SLA กำหนดตามระดับของ support ที่ซื้อ
ต่างจาก Pi ที่ต้องคุ้ยหาคำตอบตาม forum/community เอาเอง แถมไม่รู้ว่าจะหาคำตอบได้ไหมอีก

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

69 Nameless Fanboi Posted ID:x5+xgIq1dp

>>67 ปัญหาที่ว่านั่นกูโดนมาหมดแล้ว แต่เกิดจากใช้เทคโนโลยีเก่าล้วนๆเลย 555

70 Nameless Fanboi Posted ID:Gyel1m2w6m

เจอผู้บริหารจบนอก
สายโปรเแกรมมิ่งเหมือนกันคุยกันเทคนิค เทคโนโลยี vuejs, react, angular, nodejs, golang, .net core, mssql, postgres ยาวมาก

เล่าให้ฟังว่า ทำงานได้รับยอมรับจากบริษัทระดับโลก หน่วยงานภายนอกให้การยอมรับ เก่งระดับหาบักโปรดักระดับโลกได้จนเขาต้องจ่ายเงินให้
กลับมาดูแลกิจการโรงงานระดับพันล้านของครอบครัว

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

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

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

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

คนจะฐานะยากดีมีจนยังงัยก็เจอปัญหาและความทุกข์คนละแบบแหะ
ฟังแล้วก็ปลง ทำอะไรง่ายๆ ระบบง่ายๆ โง่ๆก็พอละเรา

71 Nameless Fanboi Posted ID:.DPs84KvzA

ถ้าเขียน program ว่ายากแล้ว เชื่อเถอะ ว่าการเขียน API technical document ให้ถูกต้อง 100% นั้นยาก และเสียเวลา ยิ่งกว่าเขียน program มาก ที่สำคัญ มันผิดง่ายมากๆด้วย

เพราะเขียน program เราเขียนให้มันทำงานตาม logic ที่กำหนด

เขียน api document เราต้องเขียนให้คนอื่นอ่าน เราต้องทำตัวเหมือนเข้าไปนั่งในความคิดเค้า ว่า ถ้าเค้าอ่านบรรทัดนี้เค้าจะคิดว่าอย่างไร ความเป็นไปได้ของแต่ละตัวแปรมันจะเป็นอะไรได้บ้าง อะไรพวกนี้

ถ้าเราเขียนผิดนิดเดียว มันอาจจะส่งผลให้ระบบที่เอาไปใช้งานต่อ ถึงกับทำงานต่อไม่ได้เลยก็เป็นได้

72 Nameless Fanboi Posted ID:haJF8PNd2z

ทำไมต้องเก็บข้อมูลแบบ Granularity แบบ Hit Level?

การเก็บข้อมูลบน Google Analytics Standard Version (Free) จะได้ข้อมูลที่เรียกว่า Aggregated Data หรือการที่ทาง Google ประมวลผลและรวมข้อมูลให้เราแล้ว ซึ่งเราจะเห็นแค่ว่า User ทำ Interact อะไรไปแบบรวมข้อมูลแล้วไม่สามารถเห็นเป็น Individual Event ได้ ซึ่งจะทำให้เราเสียโอกาสที่จะทำวิเคราะห์ User Behavior ในเชิงลึกที่จะสามารถทำ Prediction หรือต่อยอดในการทำ Machine Learning ได้

หากเราใช้ Google Analytics 360 เราจะได้ข้อมูลที่เป็น Hit Level ที่เชื่อมต่อกับ Google BigQuery ที่เราสามารถไปต่อยอดในการทำ Machine Learning ต่อไปได้ ยกตัวอย่าง Use Cases เช่นทำ Recommendation, ทำ K-Means Clustering เพื่อทำ Segmentation

หากใครอยากเรียนรู้การใช้ Google Analytics 360 และ BigQuery ลอง Apply มาเป็น Data Analyst ที่ Predictive ได้เลยครับ ช่วงนี้ขยายทีม Analytics เพื่อรองรับความต้องการของตลาด ลูกค้าของเรามีทั้งในไทยและต่างประเทศ จะได้ทำลูกค้าที่เป็นระดับ Enterprise หลากหลายอุตสาหกรรมตั้งแต่ Financial Services, Telco, Retail, Media, Automobile, Travel & Hospitality, Real Estate

สนใจส่ง CV ได้ที่ info@predictive.co.th ขอบคุณครับ

73 Nameless Fanboi Posted ID:xpuUu7c0lU

Understanding your target audience (domain). A mediocre “Programmer” who can understand exactly what the customer/user wants and how it impacts them will outproduce a wiz programmer who concentrates on making the algorithms “perfect”.

If what the audience wants is a way to made 3=2 then writing an algorithm that shows that 3<>2 in under 2 seconds is going to be worse than an algorithm that makes 3=2 even if it takes 20 years.

Many times programmers forget the reason they program. I always look at it this way.
1. We write programs for end users. The end game is to make a program that the end user will use. It doesn’t matter to them usually if a function call takes .0003 sec or .0002 sec. Knowing what the end user wants and being able to put it out is 10X more important (and profitable) than knowing how to code quickly.
2. We write Code for other programmers (and ourselves). The code we write has to be able to be available to other programmers or ourselves months or years later. That means that no matter how efficient a control table with a 256byte ascii translation key is, knowing what the heck it is doing by looking at the code 6 months from now is likely to be a problem, so unless it’s necessary to get #1 above done (maybe it’s happening in a loop and you need the performance) it’s an inefficient choice.

75 Nameless Fanboi Posted ID:2RvbwO7VDR

ผมว่าเดฟใช้ ReactNative นี่เห็นแก่..นิดๆ เพราะว่าสร้าง app โง่ๆเริ่มที่ 1 หน้า Build เสร็จขนาดเริ่มต้น 60MB ในขณะที่ Native จะมีขนาดประมาณ 1-2 MB

76 Nameless Fanboi Posted ID:3ASTSb8gvA

เร็วช้าหนักเบา Cr: พี่ต่อ
อันนี้ฟังมาแล้วเข้าใจประมาณนี้

#Agile เร็วและเบา(คล่องตัว) ให้ใช้กับ
งานที่ไม่เคยทำ งานใหม่ ลองผิด ลองถูก ไม่มีประสบการณ์
ทีมต้องตัดสินใจเองได้ ไม่ขึ้นอยู่กับ Policy กฎระเบียบที่ยุ่งยากซับซ้อน เพราะจะไม่ได้ความคล่องตัว บริการนั้นก็จะไม่ออกมาให้ใช้ได้สักที ช้าเกินไปก็อาจจะออกมาในเวลาที่ไม่เหมาะสม
งานที่ใช้ Agile เมื่อพบว่าไปผิดทาง ไม่ได้ผล ก็ยกเลิกได้ ไม่มีผลกระทบมากมายในธุรกิจ ถ้าได้ผลดีก็ค่อยๆเริ่มปรับให้มีมาตรฐานเพื่อกลายเป็น Norm และควบคุมได้ ไม่ผิดกฎ มีคุณภาพและค่อยๆ transform ออกไปเป็น waterfall

#Waterfall ช้าและหนัก ให้ใช้กับ
งานที่เคยทำ มีความรู้ มีประสบการณ์ มี Standard เป็น Routine ได้ มี Normal Sense ของทีมอยู่แล้ว เช่น ขั้นตอนในการ Take off , landing ของเครื่องบิน ต้องทำอะไรบ้างในทุก Flight แผนการบิน เช็คความพร้อมเครื่องบิน ความพร้อมเส้นทาง ฯลฯ
งานฝากถอนเงินต้องมีขั้นตอนอะไรบ้าง ต้องมีความปลอดภัยแค่ไหน มีอะไรที่ต้องคอนโทรลบ้าง ไม่ใช่เรื่องใหม่ที่คนต้องคิดออกนอกกรอบ ถ้าต้องคิดใหม่นอกกรอบ ให้ย้อนกลับไปลองด้วย Agile

77 Nameless Fanboi Posted ID:cp5l.Emb7M

อีช่อ ล้มเจ้า !! อีช่อ ล้มเจ้า !! อีช่อ ล้มเจ้า !! อีช่อ ล้มเจ้า !! อีช่อ ล้มเจ้า !!

พรรคอนาคตใหม่ ล้มเจ้า !! พรรคอนาคตใหม่ ล้มเจ้า !! พรรคอนาคตใหม่ ล้มเจ้า !!

คนเลือกพรรคอนาคตใหม่ คือพวกล้มเจ้า !! คนเลือกพรรคอนาคตใหม่ คือพวกล้มเจ้า !!

78 Nameless Fanboi Posted ID:rux7VDTWVY

>>75 เพราะกุเขียน native ไม่เป็น อส

79 Nameless Fanboi Posted ID:MEhBCfmZoa

>>77 อีควายอีโง่อีเวรอีเหี้ยอีสัสอีอักบัรผัดเผ็ดเย็ดอัลเลาะห์

80 Nameless Fanboi Posted ID:2WkhgF4r0w

>>79 อัลเลาะห์​ไม่เยสครับเพราะอัลเลาะห์​ชอบเด็กๆ

81 Nameless Fanboi Posted ID:X09ul2xe7M

ถ้ามองดีๆ การจัดการงานชิ้นนึงในองค์กรก็เป็น distributed system แบบหนึ่ง เพราะคุณต้องสื่อสารข้อมูล และมี agent ที่คอย deliver solution based on information หลายโหนดที่ต้อง sync ข้อมูลปัญหาของลูกค้าซึ่งกันและกัน ดังนั้น trade-off ชิ้นแรกที่สามารถพูดได้ทันทีเวลาแบ่ง role ย่อยๆ ในองค์กร คือ apply CAP theorem คุณเลือก c,a,p มากกว่ากันตอนแบ่ง role

และถ้าทำ information sharding ดีๆ ทีมจำนวนมากก็จะทำงานได้แบบ async โดยไม่ติดขัดเหมือน distribution system นั่น และเช่นกัน ถ้าไม่ดีคุณก็ต้องเสียสละ consistency, availability รวมถึง processing power และ network cost มหาศาล

และ มันมี trade-off เสมอ!!!! ไม่มี best practice

82 Nameless Fanboi Posted ID:QFiE9r59bZ

เรื่องที่พูดวันนี้ meaning มันลึกมากกว่าที่จะอธิบายได้หมดทุกหัวข้อเลย หวังว่าจะสื่อได้ซักครึ่งนึงของภูเขาน้ำแข็งนะ

Culture ดึงคนที่ใช่กับผลักคนที่ไม่ใช่ อะไรคือใช่ เราก็กำหนดเอง เรากำหนดไม่ดี ก็รับผลเอง

เพราะทางเลือกที่ว่าถ้าไม่กำหนด ก็คือ culture happen by random ขนาดกำหนดเขียนยังเอาไม่ค่อยอยู่เลย ไม่เขียนนี่ random แน่นอน

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

เพราะทางเลือกอื่นมีอะไรบ้าง?

ไม่กำหนดและให้มันเป็น random ก็แย่กว่าแน่ๆ

กำหนดสิ่งที่เราไม่เชื่อจากใจ แต่เอาตาม best practice ถ้ามันไม่ดีขึ้นมาก็ “โห รู้งี้ไม่น่าเลย” แล้วเราก็ไม่ได้โตขึ้น ดีไม่ดีเรากลายเป็นตัวปัญหาในทีมเองอีก เพราะเลือกสิ่งที่เราอยู่ไม่ได้

“กำหนด culture ที่เชื่อจากใจ” นี่ก่อนจะมาบอกว่ามันง่ายแค่นี้ ผมผ่านการลองทางเลือกอื่นมาหลายทาง จนพบว่าสุดท้ายนี่แหละมัน simple but true ก่อนจะสรุปว่าทุก other complicated way มัน bullshit หมด คือลองมาแล้ว

ถ้าเราเชื่อจากใจแล้วโดนโลกความเป็นจริงตีว่าที่เอ็งเชื่อมันผิด มันโลกสวย มันใช้งานจริงไม่ได้ เราจะโตและ move on ได้ ถึงแม้จะเจ็บหนักมากๆ ก็เถอะ (ซึ่งผมก็ผ่านมาก่อน) แต่มันเจ็บแล้วจบ ไม่เลิกกับความเชื่อตัวเองแบบค้างๆ คาๆ

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

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

ปล. เห็นมั้ยว่าผมยึด prioritization over completeness เป็นสรณะจริงๆ

83 Nameless Fanboi Posted ID:gXx56gzJo5

ซักวัน หวังว่าโปรแกรมเมอร์ไทยจะเชื่อและเห็นเหมือนเรา เข้าใจและเชื่อจากเบื้องลึกจริงๆ ว่า “เขียนเทสทำให้เขียนโปรแกรมเร็วขึ้น”

ซึ่งผมไม่ได้ล้อเล่นนะ ผมเชื่อแล้วเห็นมันแล้วจริงๆ

จะเปลี่ยนความคิดจาก “เทสเสียเวลา แต่ก็ต้องทำเพื่อคุณภาพ” เป็น “เทสช่วยให้งานง่าย เขียนโปรแกรมเร็วและสนุก” ซักวัน

84 Nameless Fanboi Posted ID:87bX2qgLXf

พอแวะมา Techsauce Global Summit 2019 แล้วคิดว่าตัวเองคิดถูกที่เป็น Developer มากๆ

ในขณะที่คนสายอื่นๆ คุยกันผ่านข่าวลือ ผ่านผู้เชี่ยวชาญ ผ่านเพรส เรากลับคุยกันด้วย source code ด้วย packet capture ด้วยการ decompile ออกมาดู เป็นหลักฐานเชิงประจักษ์ ไม่ใช่จากแหล่งข่าว

ในขณะที่คนอื่นบอกว่าอันนี้กำลังมาแรง ถกเถียงกันว่าจะดีไหม เรา clone repo มาอ่านโค้ด มาลองแก้แล้วคุยกันบนพื้นฐานของระบบจริงๆ ไม่ชอบอะไรก็ส่ง PR ไปแก้เลย

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

ในขณะที่กลุ่ม Developer กำลังจะจัด First Meetup มาลงโค้ดสำหรับเทคโนโลยีที่เพิ่งมาได้วันเดียวแล้ว กำลังจะลองสร้างสิ่งต่างๆ กันดูแล้ว

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

หลายๆ คนมอง Developer ว่าเป็นทรัพยากร เป็น resource แบบหนี่ง หน้าที่คือเป็นคนทำให้มันเกิดอย่างเดียว เค้าก็เลย offload งานจริงๆ ให้เราทำ

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

ทั้งๆ ที่เราเข้าใจได้ทั้ง technical และ business perspective อยู่แล้ว dev ส่วนใหญ่ก็คิดไอเดียกันเก่งด้วย แต่ไม่ค่อยกล้ากัน หลายๆ คนโดน stereotype ของสังคม ทำให้เราคิดว่าเราต้องก้มหน้าก้มตาโค้ดอย่างเดียว

คนจากสายอื่นๆ ที่บ่นว่าอยากได้ dev น้อยคนที่ไปคุยกับ developer community leader หรือ researcher เองด้วยซ้ำอ่ะ หลายๆ คนยังไม่เข้าใจบริบทของเทคโนโลยีเลยว่าจริงๆ มันคืออะไร

เจ้าของโปรดักต์หลายๆ คน ก็โตมาจากสาย Engineer เพราะเขาเห็นภาพที่มันเป็น เห็นความเป็นไปได้จากหลักฐานเชิงประจักษ์ ตรรกะและเหตุผล

หลายๆ คนที่บอกว่าต่อไป dev จะตกงาน คนจะไม่ต้องเขียนโค้ดอีกต่อไป หรือ AI จะมาแทนที่ dev ทั้งหมด หลายๆ คนยังไม่เข้าใจด้วยซ้ำว่าการเขียนโปรแกรมจริงๆ คืออะไร ภาพมันถูก abstract away ไปเยอะมากๆ

While everyone else were dreaming the possibilities, we are already building the goddamn thing.

It's a great time to be a developer.

#TSGS19

85 Nameless Fanboi Posted ID:87bX2qgLXf

โลกของการพัฒนาแอพกำลังจะเปลี่ยนเพราะ Huawei

ก่อนอื่นออกตัวก่อนว่าไม่ได้เป็นติ่งหัวเหว่ย เขียนถึงเพราะมันเป็น paradigm shift ที่มันต้องเกิดขึ้นซักวัน แต่มันเกิดเร็วกว่าที่คาดเพราะหัวเหว่ยจนตรอกนี่แหละ และมันก็ไม่เกี่ยวกับดราม่าโลกจะแตกหากไม่มี Google App ใช้

Android App ใช้ JVM มาตั้งแต่แรก เพราะ business model ต้องการความหลากหลายของเครื่อง ทั้ง cpu, memory, features สารพัดจะแตกต่าง android รับได้หมด

ข้อเสียคือมันช้า โคดช้า จนถึงช้าที่สุด เมื่อเทียบกับ iOS ที่คอมไพล์ native ตรงๆ ไม่มี VM ซึ่ง Google ก็ปรับปรุงเรื่อยมา เช่น มี JIT (Just in time) compiler เร็วขึ้นแต่ยังต้องรันหลายๆรอบถึงจะเร็วขึ้น และต่อมาก็มี ART ซึ่งคอมไพล์ตอนติดตั้ง แลกเอาติดตั้งช้าหน่อย แต่วิ่งเร็วขึ้น เครื่อง Android มีปัญหาอีกอย่างคือ Java มี Garbage Collector ที่คอยทำงานไม่เป็นเวล่ำเวลา ทำให้เครื่อกระตุกตลอด

Apple ได้เปรียบ เพราะเป็น OS สำหรับ เครื่องจากบริษัทเดียว คุมได้ตลอด เปลี่ยน OS ที คนเปลี่ยนเหยียบ 80-90% ในเวลาไม่กี่เดือน ในขณะที่ Android คนเปลี่ยนช้ากว่ามาก เครื่องร้อยพ่อพันแม่ ทำให้ต้องใช้หลักการบนพื้นฐาน JVM ที่ compile ตามเครื่องที่รัน (Dynamic Compiler) ตามที่บอกข้างต้น

ทีนี้เมื่อโลกบีบหัวเหว่ย ทำให้หัวเหว่ยต้องออก OS ออกมา และจะขายออก ก็ต้องมีอะไรๆที่ดีกว่าแอนดรอยด์ หนึ่งในนั้นก็คือ ความเร็วของแอพ พี่แกก็เลยออก ARK Compiler ออกมา ประกาศว่าเป็น Open source ด้วย เป็น static compiler คอมไพล์ code ส่วนใหญ่เป็น native ไปเลย ไหนๆก็ไหนๆ ไม่มีอะไรต้องแคร์ เพราะรันบนเครื่องกรูเครื่องเดียว กับ CPU Kirin ซึ่งยังถือใบอนุญาตจาก ARM แบบตลอดชีวิตอยู่

ไม่ต้องมานั่งกังวลแบบ Google ที่ต้องทำ compiler ให้ซัพพอร์ตเครื่องหลากหลายรุ่นแบบมหาศาล

ตอนนี้รอดูว่ารูปแบบ apk จะออกมายังไง การ launch โปรแกรมต้องเปลี่ยนแน่ เพราะน่าจะไม่มี ART แล้ว (Android Run-Time) หรือจะมียังไง รูปแบบไหน

Developer ได้แต่ทำตาปริบๆ แค่ต้อง คอมไพล์ iOS, Android บวก Windows, Mac, Linux ก็แย่แล้ว ท่าทางจะมีเพิ่มอีก...

86 Nameless Fanboi Posted ID:87bX2qgLXf

วิธีในการทำงานของผม
1. หลีกเลี่ยงเครื่องมือ และ ไลบรารี่ภายนอก อันนี้เป็นจุดใหญ่ใจความเลย ถ้าอันไหนผมเขียนได้ ผมจะเขียนเองทั้งหมด ข้อดีของมันคือเราคุมได้ ว่าเราต้องการผลลัพท์แบบไหน การดัดแปลงก็ง่าย เพราะเรารู้ทุกบรรทัดที่เราเขียน ข้อเสียคือ เสียเวลา แต่การเสียเวลาผมว่าคุ้ม เพราะเราเสียเวลาแค่ครั้งแรกเท่านั้น เพราะเราจะได้ทั้งความรู้ และการต่อยอดในภายหลัง ซึ่งอาจใช้เวลาน้อยกว่า การศึกษาคู่มือของคนอื่น และ ความพยายามในการดัดแปลงซะอีก
2. ใช้เทคโนโลยีพื้นฐานให้มากที่สุด จริงๆ เทคโนโลยีมันถูกพัฒนาตลอดเวลาแหละ และของใหม่มักจะดีกว่าของเก่า ไม่ทางใดก็ทางหนึ่ง แต่ข้อเสียของ ของใหม่ที่สำคัญคือ มันมักจะถูกจำกัดให้ใช้กับคนที่มีความสามารถพอ เช่น docker ซึ่งหลายๆอย่าง มันเป็นของใหม่ และคนส่วนใหญ่ ยังไม่ได้ใช้มัน การทำงานกับคนส่วนใหญ่ จึงไม่จำเป็นต้องใช้ แต่ถ้าคุณทำงานในกลุ่มแคบๆ เช่นในองค์กร คุณจะใช้เครืองมืออะไร ก็สามารถเลือกได้ตามสบาย เพราะคุณสามารถควบคุมเทคโนโลยีที่จำเป็นของตัวเองได้
3. ทำมาเพื่อใช้ โค้ดทุกบรรทัด ต้องใช้ได้จริง งานทุกชิ้นต้องใช้ได้ จริงๆ ถ้าเราทำงานมาแล้วไม่มีคนใช้ มันเจ็บใจกว่าไม่ได้ทำมันขึ้นมาซะอีก จริงๆ ข้อนี้เป็นความลำบากอย่างหนึ่งในวิธีการทำงานของผม เพราะการออกแบบให้คนจำนวนมากสามารถใช้งานได้ มันยากกว่าทำให้ตัวเองใช้ หรือ ใช้ในกลุ่มแคบๆ การมีเจ้าภาพในการทำงาน มันมีข้อดีที่ requirement มันจะเป็นของเจ้าภาพ เราจะมีสโคป ชัดเจน งานจะง่าย ในขณะที่การทำงานกับคนในวงกว้าง requirement จะต้องสามารถทำงานได้กับคนที่มีความแตกต่างกันสูงๆด้วย (แต่ละคนอาจมี requirement ที่ไม่ตรงกัน)
4. เริ่มใหม่ได้เสมอ เปลี่ยนวิธีคิดได้ตลอดเวลา ้ถ้าเจออะไรใหม่ๆ หรือถึงทางตัน ผมไม่ซีเรียสนะ ถ้าผมต้องกลับไปเริ่มต้นจาก 0 ใหม่ พร้อมกับเปลี่ยนวิธีคิด อันนี้ผมว่าเป็นข้อดีของผมเลยทีเดียว หลายๆครั้งเวลาเราเจอปัญหา เรามักจะแก้ไขมันไม่ได้ เพราะ สมองเรามันมักจะคิดว่า เรามาถูกทางแล้ว แต่คงทำอะไรผิดซักอย่าง เป็นลูปซ้ำๆเดิม ซึ่งจริงๆ ถ้ามันผิดตั้งแตวิธีคิด แต่เรายังคงวนในลูปเดิมๆ แน่นอนว่า เราไม่มีทางประสบความสำเร็จภายใต้ลูปนั้นๆ ทางออกคือ เราต้องออกจากลูป แล้วเริ่มต้นใหม่ ซึ่งผมมักจะทำได้ง่ายมาก
จริงๆ คนอายุขนาดผม มันต้องมีวิธีคิดเป็นของตัวเองได้แล้วแหละ ไม่จำเป็นต้องคิดตามคนอื่น หรือ คิดแบบองค์กร เพราะ ประสบการณ์ที่ผ่านมา มันน่าจะสอนอะไรเรามาได้พอสมควร ทำให้ผมสามารถเลือกทางที่เหมาะสมกับตัวเองได้ แต่ไม่ได้หมายความว่าผมแนะนำให้ต่อต้านเทคโนโลยี หรืออะไรนะครับ มันยังคงจำเป็น สำหรับการเรียนรู้ โดยเฉพาะคนรุ่นใหม่ ยังจำเป็นต้องเรียนรู้และแสวงหาอยู่ เพราะเทคโนโลยีใหม่ในวันนี้ จะเป็นเทคโนโลยีเก่าในวันข้างหน้า เทคโนโลยีใหม่กว่าจะถูกนำมาแทนที่ และ เทคโนโลยีใหม่ในวันนี้ อาจเป็นมาตรฐานในอนาคตก็ได้ ใครจะไปรู้

87 Nameless Fanboi Posted ID:8PbR5Zo8i8

>>86 >หลีกเลี่ยงเครื่องมือ และ ไลบรารี่ภายนอก
ดีหรอวะ...

88 Nameless Fanboi Posted ID:cYthLejNDU

>>87 ครับ เพราะงั้นเลิกใช้ reactjs ซะนะครับ ถถถ

89 Nameless Fanboi Posted ID:hUku7/xmt6

วันนั้นในสมาคมโปรแกรมเมอร์ มีคนถามไว้ว่า ใน mvc เอา business logic ไว้ที่ไหนดี หลายคนตอบ model หลายคนตอบ controller
.
.
ส่วนผมไปตอบไว้สั้นๆว่า mvc มันไม่แคร์ว่า business logic มาจากไหน เพราะมันอยู่นอก scope ของปัญหาที่มันพยายามแก้
.
.
.
มีคนไปตีความว่า เอาไว้ตรงไหนก็ได้ ซึ่งก็ยิ่งออกประเด็นไปไกลใหญ่

สิ่งที่พยายามสื่อแต่ล้มเหลว คือ ถ้าโลกของคุณมีแค่ฆ้อนคุณจะเห็นทุกอย่างเป็นตะปูไปหมด เช่นเดียวกัน ถ้าโลกของคุณมีแค่ mvc คุณก็จะเห็นทุกอย่างเป็น mvc ไปหมดจนปิดกั้นจินตนาการอื่นๆ
.
.
pattern มันขอ scope ตัวเองเฉพาะเรื่องการแสดงผล คุณจะไปเอา data มาจากไหนก็ได้​ โยนให้ model มัน ที่เหลือมันจัดการให้

เราจะเอา logic ไปขียนไว้ใน hexagonal architecture ที่ pure มาก หรือจะเขียน logic ไว้ใน controller แบบไม่ต้องมี abstraction ใดๆ เลยก็ได้ หรือจะสร้าง rich domain model แล้วบอกว่า rich model นั่นแหละคือ presentation model เดียวกันใน mvc ก็แล้วแต่เลย
.
.
จะวาง architecture ยังไง มันขึ้นกับว่าคุณอยากสร้าง abstraction มากน้อยแค่ไหนเพื่อมาจัดการความซับซ้อนของ domain problem ของคุณเอง
.
.
.

อย่าเอา mvc เป็นตัวตั้ง แล้วหมุนตามมัน แต่ให้มันหมุนตามเรา ให้เราใช้มันเพราะเข้าใจ ไม่ใช่ให้มันมาใช้เราโดยเราไม่เข้าใจ

90 Nameless Fanboi Posted ID:6W0rNdk6+J

>>86 ตอแหลตั้งแต่ข้อ 1

91 Nameless Fanboi Posted ID:UsxMEB8/uV

>>86 ข้ออื่นขอไม่คอมเม้นต์ ขอแค่ข้อแรกถ้าเป็นทีมกู ใครกระแดะเป็นแบบนี้กูด่าเลยนะ กูเห็นหลายคนเลยที่มันพยายามเขียนเอง มีข้ออ้างแบบนี้เลย เพราะมันใช้ไลบรารีทั่วๆไปไม่เป็น ใช้ไม่คล่อง ขี้เกียจอ่าน doc เลยต้องเขียนเอง สุดท้ายก็มีปัญหา compatible แถมใช้ไปซักพักก็ obsolete นี่ยังไม่รวม bug ต่างๆตอนขึ้น production อีกให้ทำ doc ก็ไม่ค่อยอยากทำ ทำมาลวกๆลำบากคนอื่นที่จะเอาไปใช้ เพราะถ้าติดอะไรมันไม่มีคอมมูที่คอยช่วย ต้องโทรถามมันคนเดียว

92 Nameless Fanboi Posted ID:IjjebZaxps

เรื่อง Business Logic ใน Model และ MVC

"ทำไมถึงมีคนบอกว่าเก็บ Business Logic ใน Model? ทั้งๆ ที่ MVC มัน concern กับ UI?"

ผมสรุปสั้นๆ แบบนี้ละกัน ว่า "Model" สำหรับบริบทนี้ มันไม่ได้เป็น Model ตัวเดียวกับ Model ใน MVC​ ซะทีเดียว

แต่เป็น "Model" ในลักษณะเดียวกับคำว่า Model ใน Mathematical Model, Business Model, Computation Model หรือว่า "ธรรมศาสตร์โมเดล" ตอนน้ำท่วม 54 อะไรแบบนี้

ขยายความยาวๆ ก็:

มันเป็นสิ่งที่ encapsulate สิ่งที่เราคิด หรือพูดอีกอย่างก็คือ model ของความคิดเราเองว่าคืออะไร ทำงานยังไง เปลี่ยนแปลงยังไง ฯลฯ

ในขณะที่ MVC ของ ​MVC Architecture Pattern มันไม่ได้สนใจตรงนั้น (คือ มันไม่ได้บอกว่า "ต้อง" อยู่ที่ไหน มันไม่มี concern เรื่องนี้เลย)

ซึ่ง Pattern แบบนี้ใช้เยอะในพวก Enterprise เพราะว่ามันมักจะมีระบบ ERP/Backend ที่ทำงานกับพวก Business Logic อะไรพวกนี้อยู่แล้ว แต่หน้าที่คนคือทำ UI ให้ทำงานกับข้อมูลนี้ในหน้าจอต่างๆ กัน

ทีนี้ มันมีประเด็นที่ทำให้คนสับสนอยู่ตรงนี้แหละ

คือ Framework หลายตัวในปัจจุบัน ที่ไม่ได้โตขึ้นมาจากทางฝั่ง Enterprise เค้าค่อนข้าง encourage ให้ใช้ "Model" (in general) สำหรับการทำ "Model" ใน MVC ไปเลย ยกตัวอย่างเช่น Ruby on Rails เป็นต้น

ซึ่งมันก็ make sense สำหรับงานที่ scale ยังไม่ใหญ่เท่าไหร่

ทีนี้เวลาที่งานมันเริ่มโตขึ้นมา เราเริ่มต้องการ "Representation ของ Data จาก Model เดียวกันในหลายแบบมากขึ้น" (เช่น JSON คนละแบบ) เราก็ควรจะ "งอก Layer ขึ้นมาใหม่ มาจัดการ concern ตรงนั้น"

ซึ่งตรงนี้จะเรียกอะไรก็เรียกไป หลายคนก็เรียกว่า VM (ViewModel) หลายคนก็เรียกว่า Presenter ... (สำหรับคนที่ใช้ Model in general ใน MVC) ... หลายคนก็เรียกว่า Model (สำหรับคนที่ Model คือ Model ใน MVC ตั้งแต่ต้น)

แต่ในขณะที่ Framework หลายตัว encourage แบบนี้ .... Framework อีกหลายตัว โดยเฉพาะที่โตมาจากฝั่ง Enterprise นี่คิดตรงข้ามเลย คือให้ Model เป็น Model จ๋าๆ ใน Presentation Tier ของ 3-tier อะไรแบบนี้ .... เอาไปใช้ใน UI Domain อย่างเดียวเลย

มันก็เลยสับสนกันง่าย

สำหรับหลายคน (หลาย community/culture/framework) แล้ว MVC มันคือ 3-Tier ตรงๆ เลย แต่สำหรับอีกหลายๆ คน (หลาย community/culture/framework) แล้วมัน concern อยู่แค่ใน Presentation tier

ผมเป็นคนหนึ่งที่บอกว่า Business Logic ควรอยู่ใน Model .... แต่ Model ของผมมันไม่ได้หมายถึง Model ใน MVC .... แค่ในบางกรณีมันเอาไปใช้ได้ตรงๆ

แต่นั่นมันหมายถึงว่า Business Logic ผมจะไม่กระจัดกระจายอยู่ใน Controller บ้าง Model บ้าง DB บ้าง View บ้าง ... มันจะไปกองที่เดียวคือ Model Layer

และ Model Layer ของผม มันไม่ได้มีแต่ "Data Model" แต่มันมีอะไรเยอะแยะอยู่ (คือมันมี Sublayer อยู่เยอะแหละ ก็งอกมาตามบริบาท เช่น ผมอาจจะมี BookPersist, BookEntity, BookUseCase, BookDataRule เฉพาะของ "Book" ก็ได้ ....)

พูดง่ายๆ แต่ว่าละไฟล์มันก็ไม่ได้เกิน 300 บรรทัดหรอก และเราก็แยก concern ในแต่ละเรื่องใน Model Layer อีกทีอยู่แล้ว :P

TLDR:

ถ้าถามว่า "Business Logic *ต้อง* อยู่ไหนใน MVC" คำตอบคือ "มันไม่มี concern เรื่องนี้ ไปคิดเอาเองว่าจะเอาไว้ไหน"

แต่ถ้าถามว่า "คนที่บอกว่า 'เก็บใน Model' นี่คิดอะไรอยู่" คำตอบก็จะเป็นประมาณนี้ ว่า Model ใน conceptual ของเขา มันคือ Object Model ที่มันใหญ่กว่า Model ใน MVC และมันรวม Model ใน MVC ไว้แล้ว น่ะแหละ ....

ซึ่งบังเอิญพอคิดแบบนี้แล้ว มันก็เลยกลายเป็นว่า "ไหนๆ ก็ต้องคิดเองเรื่อง Business Logic อยู่ไหนใน MVC แล้ว .... ก็ใน Model ไง มันก็ควรอยู่ตรงนั้นอยู่แล้ว"

และ "Model" ตรงนี้ หมายถึง Group ของ Objects/Classes ใน Model Layer ซึ่งอาจจะเต็มไปด้วย Design Pattern และ Architecture Pattern ... ไม่ได้หมายถึง Single Class ที่ยัดทุกอย่างไปรวมกันหมด

TLDR of TLDR:

Business Logic เก็บไว้ใน Model ครับ แต่มันคือ Model in General

ส่วนคุณจะใช้ Model ตัวนี้ใน MVC แบบไหน/ขนาดไหน ... มันเรื่องของคุณ ... เพราะตัว M ใน MVC มันไม่แคร์เรื่องนี้

อีกรอบ: สำหรับหลายคน (หลาย community/culture/framework) แล้ว MVC มันคือ 3-Tier ตรงๆ เลย แต่สำหรับอีกหลายๆ คน (หลาย community/culture/framework) แล้วมัน concern อยู่แค่ใน Presentation tier

93 Nameless Fanboi Posted ID:JXwk6QyFRg

>>86 ข้อ 1 นี่ถ้าจะคิดแบบนั้นมึงไม่เขียนภาษาใหม่ สร้าง hardware ใหม่ ใช้เองไปเลยล่ะจะได้รู้ทุกอย่าง แหม่
การเขียนโปรแกรมทุกวันนี้มันสร้างบนฐานของของเก่าที่มึงไม่มีทางรู้หมดทุกอย่างทั้งนั้นแหละ

94 Nameless Fanboi Posted ID:4HDNoqXWxG

เสร็จแล้วหว่ะ
#DeepNude version minimal รันด้วย python ได้เลย ไม่มี qt ui หรือ exe ไฟล์
```
python main.py test.jpg
```
แล้วจะปล่อยยังไงดี แอบหวั่น 555
ปล. ไม่ได้ทำเองนะครับ ผมเอาของเขามาแก้
https://github.com/open-deepnude/open-deepnude

https://imgur.com/a/DyI8hzx

95 Nameless Fanboi Posted ID:FqRfX4./wD

>>94 ไม่มีแสกนละควย ไม่ผ่านค่ะ

96 Nameless Fanboi Posted ID:yXV+iHDFeK

>>95 ยังไง

97 Nameless Fanboi Posted ID:rQo.uqZrWM

>>94 ลง PyQt5 แล้วทำไมมันหา QtImagecropper ไม่เจออ่ะ
end user เฉยๆ ของ่ายๆ โง่ๆ ด้วย

98 Nameless Fanboi Posted ID:mIegSqGUjM

ไอ้ เควนทิน เบ็ค (Mystertio) ที่ทำตัวเป็นคนดีตอนแรกๆ แม่งจริงๆแล้วเป็นตัวโกง อดีตลูกน้องโทนี่

ตอนมันตาย แม่งยังเฉลยออกทีวี อีกว่า สไปเดอร์แมน คือ Peter Parker โคตรเหี้ย

แถมนิค ฟิวรี่ ในเรื่อง ดันเป็น ทาลอส (สครัล ในเรื่องกัปตันมาร์เวล) ปลอมตัวมา ไม่ใช่นิคจริงๆ อึ้งสัสๆ โคตรเนียน

เพื่อนๆโม่งต้องไปดู Spiderman Far From Home ให้ได้นะครับ

99 Nameless Fanboi Posted ID:dUKBYmc+9r

https://github.com/open-deepnude/deepnude_official แบบ Official

100 Nameless Fanboi Posted ID:4eLKcrpoAe

>>96 ควาย อีโง่ ก็แค่มันใช้กับ ผช.ไม่ได้ไงไองั่งปัญญาอ่อน

101 Nameless Fanboi Posted ID:dzR5msFIQm

ผมใช้ไมไ่ด้อะครับ มันขาด module QtImageCropper

102 Nameless Fanboi Posted ID:4Q4IOnswrC

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

เช่นกัน การแบ่งเลเยอร์ การเลือกใช้ชื่อในแต่ละบริบท การแบ่งไฟล์ หรือแม้แต่การเคาะ enter ก็มีผลที่แตกต่าง

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

โปรแกรมมิ่งก็เช่นกัน รู้ design pattern น่ะดี แต่งานเขียนจริงจะแค่เขียนตาม pattern แล้วบอกว่าสวยแล้วก็คงไม่ใช่

Programming มันมีส่วนที่เป็นศิลป์เยอะทีเดียวล่ะ

นักเขียนทำไง เขาเขียน อ่านเอง ให้คนอ่าน เก็บ feedback มาปรับปรุง แค่นั้นแหละ

103 Nameless Fanboi Posted ID:4Q4IOnswrC

>>101 QtImageCropper ใช้แค่รีวิวภาพ ไม่มีผลกับการประมวลผลหลัก คอมเมนท์โค้ดทิ้งได้เลย

104 Nameless Fanboi Posted ID:P0IDNoGSn2

ปัญหาด้านเทคโนโลยีใหญ่และสะสมมานมนานในองค์กร หาคนมาทำงานว่ายากแล้ว สิ่งที่ยากกว่าและส่วนใหญ่ไม่ให้ความสำคัญมากพอก็คือกระบวนการจัดการองค์ความรู้ ความรู้ส่วนใหญ่เก็บไว้ที่ตัวบุคคล เมื่อคนเก่งเหล่านั้นออกไป คนใหม่มาก็ใช่ว่ามาถึงแล้วจะทำงานได้เลย ไม่มีคนสอนงานเก่า งมเองกว่าจะได้เท่าคนเดิมส่วนใหญ่ก็เจ็บและเจอปัญหาจนออกไปก่อน ทำให้การทำงานและธุรกิจสะดุด ไม่เกิดการพัฒนาอย่างต่อเนื่อง ต้องทำใหม่ตลอด
แนวทางที่องค์กรที่บริหารจัดการเรื่องนี้สำเร็จก็มี
1. หาพาร์ทเนอร์มาดูแลแทน ก็มาความเสี่ยง ช่วงแรกก็ต้องเรียนรู้ ว่าเวิร์คหรือไม่ ระยะยาวความรู้จะไปอยู่กับพาร์ตเนอร์หมด
2. ต่างประเทศ เอกชน จะลงทุนสนับสนุนมหาวิทยาลัย สถาบันวิจัย เป็นคนเก็บและพัฒนาองค์ความรู้ เอกชนจะเก็บแค่ส่วนต่างเฉพาะที่เป็นความลับไม่ต้องการเผยแพร่
3. เปิด opensource ให้ชุมชน ช่วยดูแล
4. เปิดหน่วยงานสถาบันเพื่อดูแลเรื่องนี้เอง