ตอนที่เริ่มเปิดเบตาสาธารณะเมื่อ 5 ปีก่อนก็เคยลงเป็นข่าวไว้ แล้วผู้ร่วมก่อตั้งก็มาคอมเมนต์ทิ้งไว้ด้วย ช่วงนั้นจนถึงตอนนี้เติบโตขึ้นมากจริงๆ
เริ่มเปิดเบตาสาธารณะของ Supabase - ทางเลือกโอเพนซอร์สแทน Firebase

อ๋อ ผมไม่ได้มีเจตนาจะดูแคลนวิสัยทัศน์อนาคตของ OpenAI หรือการพัฒนาเชิงนวัตกรรมของ Browser+AI แต่อย่างใด
สิ่งที่ผมอยากจะบอกก็คือ หาก OpenAI จะลองเดินไปในทิศทางนั้น ด้วยความที่เบราว์เซอร์หลักอย่าง Chromium หรือ Firefox เปิดเผยซอร์สอยู่แล้ว ผมจึงคิดว่าในแง่การพัฒนาไม่ได้อยู่ในสถานการณ์ที่จำเป็นต้องเข้าซื้อกิจการแยกต่างหาก

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

ถ้าเพียงแค่ออกเบราว์เซอร์ใหม่ที่สร้างบนพื้นฐาน Chromium ก็อาจไม่ได้มีแรงดึงดูดมากนักสำหรับผู้ใช้ที่ไม่ได้คิดจะย้ายออกจาก Chrome แต่ถ้าเข้าซื้อ Chrome ก็จะสามารถทำให้ผู้ใช้ที่ครองอยู่ 70% ของตลาดเบราว์เซอร์ได้ลองใช้บริการโมเดล AI ของบริษัทอย่างเป็นทางการผ่านการอัปเดตได้ อุปสรรคในการขยายบริการใหม่จะลดลงอย่างมาก

อย่างที่คุณพูด ปรากฏการณ์ที่ Edge ก็ไม่ได้ขยายตัวนั้นก็ดูจะอยู่ในบริบทคล้ายกัน ตลาดเบราว์เซอร์เป็นตลาดที่อนุรักษนิยมมากจริงๆ ผมคิดว่า OpenAI ก็น่าจะพิจารณาจุดนี้ด้วยจึงมองเรื่องการเข้าซื้อ Chrome ดังนั้นคำว่า OpenAI จะเปิด "AI-driven web browsing" นั้น ในมุมมองผม อิทธิพลของตลาด Chrome มีน้ำหนักมากกว่าศักยภาพของ OpenAI เอง

ผมใช้งานกับโปรเจกต์ส่วนตัวได้ดีมากจริง ๆ

จู่ ๆ ก็ Godot งั้นเหรอ..?!

Supabase เหมาะกับระบบที่อิง CRUD เป็นหลัก โดยมีจุดเด่นคือสามารถทำ CRUD จากฝั่งฟรอนต์เอนด์ได้แม้ไม่ต้องพัฒนา/ดูแล API server จึงช่วยลดภาระการพัฒนาแบ็กเอนด์ได้มาก นักพัฒนาฟรอนต์เอนด์และแบ็กเอนด์สื่อสารกันด้วยการกำหนดตารางแทนสัญญา API และฟีเจอร์ที่ใช้งานหลัก ๆ คือเว็บคอนโซล การยืนยันตัวตน และ object storage

เนื่องจากฟรอนต์เอนด์พึ่งพาตาราง DB, view และการกำหนดฟังก์ชัน จึงต้องใส่ใจกับการติดตามการเปลี่ยนแปลงข้อมูลพอสมควร หากต้องใช้ตรรกะฝั่งเซิร์ฟเวอร์ ผมคิดว่าการแยกสร้าง WAS/REST API ต่างหากจะเหมาะกว่า

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

เป็นบริการที่ผมชอบมากครับ สามารถสร้างบริการได้ด้วยฝั่งฟรอนต์อย่างเดียวโดยไม่ต้องตั้งค่าแบ็กเอนด์/DB ที่ซับซ้อน
ตอนนี้ก็กำลังใช้งานอย่างจริงจังเพื่อจะนำไปใช้กับบริการจริงอยู่ และสำหรับผมประสบการณ์นักพัฒนาก็ดีกว่า Firebase เสียอีก
มีรีเจียนในเกาหลีด้วย และมี free tier ที่ค่อนข้างใจกว้างให้ใช้งาน เลยดีมากครับ รวมถึงทำ self-hosting ก็ได้ด้วย
ได้ระดมทุน Series D ถือเป็นข่าวดีนะครับ! แต่ก็อย่างที่มีการพูดถึงกันในคอมเมนต์อยู่เรื่อย ๆ ว่าก็อดกังวลไม่ได้เหมือนกันว่าจะเป็นธุรกิจที่ยั่งยืนหรือไม่

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

คำว่า “อยากได้กล้วย แต่กลับยกทั้งป่ามาให้” นี่ตลกมากเลยนะ

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

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

มีปัญหาที่เกิดขึ้นจากการที่ขอบเขตงานที่คนคนหนึ่งต้องรับผิดชอบกว้างขึ้นจากเมื่อก่อน

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

ไม่จำเป็นต้องเอามาเปรียบเทียบกันเลย

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

นั่นเป็นคนละตัวอย่างกันเลยไม่ใช่เหรอ? บอกว่าแค่ rollback ก็จบเหรอ? ประสบการณ์ของคุณไม่ใช่ทั้งหมดนะครับ/คะ ไม่เคยทำงานขนาดใหญ่บ้างเหรอ

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

•การนำไปเปรียบเทียบกับอุตสาหกรรมการผลิตโดยตรงมีความหมายมากแค่ไหน? หากมองจากมุมที่ว่าอุตสาหกรรมนี้ยังไม่ได้พัฒนาไปสู่ความซับซ้อนอย่างเพียงพอ สิ่งที่ถูกนำมาเทียบก็ดูจะเป็นภาคการผลิต แต่ถ้าพยายามทำความเข้าใจงานซอฟต์แวร์ด้วยกรอบคิดแบบอุตสาหกรรมการผลิต มันอาจดูเหมือนงานหัตถกรรมหรือการพัฒนาแบบงานอดิเรก ทว่าในอีกด้านหนึ่ง ผมคิดว่าสิ่งเหล่านี้เองที่สร้างวัฒนธรรมอันยืดหยุ่นและสร้างสรรค์เฉพาะของการพัฒนาซอฟต์แวร์ และเป็นฐานให้มันเติบโตขึ้น

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

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

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

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

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

ตอนพัฒนา Spring หนึ่งในเรื่องที่ยากที่สุดน่าจะเป็นการวนลูปของ dependency..
ความอึดอัดของการที่มัน initializе กันไปมาไม่รู้จบจนพังเพราะ memory leak...

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

+11111