- เมื่อทำเว็บไซต์ส่วนตัวให้เป็น ไบนารีเดียว คนคนเดียวก็สามารถเข้าใจโครงสร้างทั้งหมดและดูแลรักษาเองได้ ทำให้ภาระการพึ่งพาชุดเครื่องมือแบบ SSG·โฮสติ้งเดิมลดลง
- ชุดอย่าง Hugo กับ GitHub Pages ตั้งอยู่บนสมมติฐานของ เงื่อนไขภายนอก หลายอย่าง เช่น ความต่อเนื่องของบริการ การดูแลโปรเจกต์ ระบบนิเวศปลั๊กอิน วิธี deploy และ Go
- การแก้ HTML ด้วยมือเรียบง่ายและเสถียร แต่จัดการฟีเจอร์ร่วมซ้ำ ๆ ได้ยาก และ workflow ทำให้เหนื่อย จึงต้องการวิธีที่ปรับแต่งได้สนุกกว่า
- เว็บไซต์ไดนามิกที่ใช้ Go สามารถจัดการงานที่ยุ่งยากบนเว็บสแตติก เช่น การแสดง IP หรือการอัปเดต RSS feed ด้วยโค้ดฝั่งเซิร์ฟเวอร์ และส่งคืน HTML ที่สมบูรณ์ให้กับ เครื่องมือที่ไม่ใช่เบราว์เซอร์ ด้วย
- เว็บไซต์ส่วนตัวควรเริ่มจากเล็ก ๆ แล้วค่อยเติบโตด้วย standard library และเครื่องมือเรียบง่ายจึงจะอยู่ได้นาน หากเริ่มด้วย framework ขนาดใหญ่จะตามให้ทันภายในเวลาส่วนตัวได้ยาก
เหตุผลที่เครื่องมือทำเว็บไซต์เดิมไม่เหมาะ
- เคยลองหลายวิธีตั้งแต่ Ghost, Hugo, Jekyll, sr.ht กับ tarball ไปจนถึงการแก้ HTML ด้วยมือ แต่ไม่ตรงกับเกณฑ์ส่วนตัว และไม่ได้ให้ ความน่าสนใจ ด้วย
- เกณฑ์ที่สำคัญที่สุดคือระบบที่คนคนเดียวสามารถเข้าใจได้ตั้งแต่ต้นจนจบ และดูแลรักษาได้ง่าย
- โค้ดอ่านง่าย
- feedback loop รวดเร็ว
- มีความสนุกและความฉลาด
- โครงสร้างที่เมื่อพังแล้วสามารถขุดลงไปตรวจเองได้
- Static Site Generator (SSG) อย่าง Hugo รับ template และ Markdown เป็น input เพื่อสร้าง HTML และมักใช้ร่วมกับแพลตฟอร์มโฮสติ้ง
- ชุด Hugo กับ GitHub Pages มีเงื่อนไขการดูแลรักษาหลายอย่างตามมา
- บริการ GitHub Pages ต้องทำงานต่อไป
- ผลิตภัณฑ์ GitHub Pages ต้องได้รับการดูแลต่อไป
- โปรเจกต์ Hugo และเอกสารชุมชนต้องได้รับการดูแลต่อไป
- อาจต้องพึ่งพาระบบนิเวศปลั๊กอิน
- ไบนารี Hugo ต้องสร้าง HTML ด้วยวิธีที่แทบเหมือนเดิมแม้เวลาจะผ่านไป
- กลไก deploy ของ GitHub Pages ต้องทำงานต่อไป
- ต้องใช้ Go
- แม้จะมีวิธี pin Hugo ไว้ที่เวอร์ชันใดเวอร์ชันหนึ่ง แต่ในทางปฏิบัติอาจมีกรณีที่ต้องอัปเกรดเพราะบั๊ก
ข้อดีและข้อจำกัดของการแก้ HTML ด้วยมือ
- เลือกวิธีโฮสต์เว็บไซต์บนเครื่องที่ควบคุมเอง และ แก้ HTML ด้วยมือ ผ่าน Vim ด้วย
- j3s.sh เวอร์ชันแรกสร้างด้วยวิธีนี้ และไอเดีย layout ในปัจจุบันจำนวนมากก็มาจากตรงนี้
- เมื่อเขียน HTML ด้วยมือ จะรู้สึกเหมือนงานหัตถกรรมที่หนักหน่วง จนนำไปสู่มินิมัลลิสม์สุดขั้ว
- ใส่ style ลงใน HTML โดยตรง
- ลดฟีเจอร์ร่วมทั่วทั้งไซต์ให้น้อยที่สุด
- หลีกเลี่ยง styling จำนวนมาก
- วิธีนี้เรียบง่าย เสถียร และดูแลรักษาง่าย
- HTML ที่เขียนไว้สามารถนำกลับมาใช้ใหม่ได้โดยไม่ต้องแก้ไข
- ไม่มี dependency ภายนอก
- ให้ความมั่นใจว่าไซต์จะคงอยู่ได้นาน
- อย่างไรก็ตาม อยากจัดการการ ทำเป็น template ของฟีเจอร์ร่วมให้มีประสิทธิภาพกว่าเดิม และต้องการวิธีที่ปรับแต่งได้สนุกโดยไม่ใช้ framework เดิม ๆ
เว็บไซต์ Go แบบไบนารีเดียว
- หากเขียนเว็บไซต์ทั้งหมดด้วยภาษาเดียว ก็สามารถบรรจุผลลัพธ์ไว้ในไบนารีเดียวเพื่อ deploy ได้
- Go เป็นตัวเลือกที่เหมาะกับการดูแลรักษาส่วนตัวและการ deploy ที่เรียบง่าย
- คนคนเดียวดูแลรักษาได้ง่าย
- เน้นแนวทางการใช้ dependency ให้น้อย
- ภาษาค่อนข้างเรียบง่าย
- มี การรับประกัน backward compatibility
- สร้างไบนารีแบบ static compile ได้ง่าย
- ส่วนใหญ่คอมไพล์เสร็จในไม่ถึง 10 วินาที
- standard library พัฒนามาดี
- ผลลัพธ์คือ j3s.sh กลายเป็น ไบนารีเดียว ที่ serve เว็บไซต์
ความเรียบง่ายที่เว็บไซต์ไดนามิกมอบให้
- ในบางกรณี เว็บไซต์ที่สร้างแบบไดนามิกอาจเรียบง่ายกว่าเว็บไซต์ที่ generate แบบสแตติก
- ไม่ต้องคิด workaround เพื่อสร้างคอนเทนต์
- สร้างสิ่งที่ต้องการได้ทันที
- ฟีเจอร์แสดง IP address ของผู้เข้าชมสามารถทำได้ง่ายด้วย
http.HandlerFuncของ Go- อ่าน header
X-Forwarded-For - ผูก handler เข้ากับ path
/ip - เรียกใช้ฟังก์ชันเดียวกันได้ในจุดที่ต้องการ
- อ่าน header
- หากจะทำฟีเจอร์เดียวกันบนเว็บสแตติก อาจต้องใช้ dependency ภายนอกอย่าง JavaScript และต้องคำนึงถึงกรณีที่ไม่มี JavaScript ด้วย
- ผู้อ่านบางส่วนปฏิเสธการรัน JavaScript
- หากเซิร์ฟเวอร์ส่งคืน HTML ที่มี IP address อยู่แล้ว แม้ client จะไม่เข้าใจ JavaScript ก็ยังได้รับ response ที่ถูกต้อง
- ใช้ได้แบบเดียวกันกับเครื่องมือที่ไม่ใช่เบราว์เซอร์
- RSS feed ของหน้าแรกถูกสร้างเมื่อเว็บไซต์เริ่มทำงาน
- สามารถดึงบทความล่าสุดของเพื่อน ๆ มาใหม่ได้
- มองว่า RSS feed fetcher ที่ทำเองจะทำงานได้นานโดยแทบไม่ต้องดูแลรักษา
- เข้าใจการทำงานภายในอย่างแม่นยำ
การ deploy และวิธีเริ่มต้น
- การ deploy จัดการด้วย เชลล์สคริปต์ สั้น ๆ
- ดึง Git repository มา
- หาก local branch ตามหลังอยู่ ให้รัน
git merge origin/main - build ด้วย
go build - ย้ายไบนารีไปที่
/usr/local/bin/j3s.sh - รีสตาร์ตบริการด้วย
service j3s.sh restart
- สคริปต์นี้ถูกรันทุกนาทีด้วย cronjob ดังนั้นเมื่อ repository ถูกอัปเดต เว็บไซต์จะถูก build ใหม่
- เมื่อทดสอบบนเครื่องตัวเองแล้วอัปโหลด ก็จะสะท้อนบนไซต์สาธารณะภายใน 1 นาที
- เรียบง่ายจนหากรู้ shell นิดหน่อยก็เข้าใจได้ภายใน 10 วินาที
- เว็บไซต์ส่วนตัวให้ความรู้สึกโดดเด่นในเว็บยุคนี้ และสามารถสะท้อนสิ่งที่ผู้ดูแลให้ความสำคัญได้อย่างลึกซึ้ง
- หากเว็บไซต์สแตติกเหมาะกับใครก็ใช้ต่อไปได้ แต่สำหรับคนที่มีค่านิยมคล้ายกัน การลองทำ เว็บไซต์ไดนามิก อาจเข้ากันได้ดี
- เริ่มเล็ก ๆ ได้
- เพิ่มไอเดียสนุก ๆ ซ้ำไปซ้ำมาได้
- เป็นไซต์ของตัวเอง จึง hardcode ได้
- สร้างด้วยภาษาที่ชอบได้ เช่น Rust, Perl, Python
- จุดเริ่มต้นควรเล็ก
- ก่อนอื่นสร้าง
index.htmlแล้วโฟกัสกับการ serve มันด้วยภาษาที่เลือก - RSS หรือ Markdown ค่อยเพิ่มภายหลังเมื่อจำเป็น
- หากเป็นไปได้ ให้ใช้เครื่องมือที่เรียบง่ายและดูแลรักษาได้มากที่สุด เช่น standard library
- ใน Ruby อาจพิจารณาตัวเลือกที่เล็กกว่าอย่าง Sinatra แทน Rails และใน Python อาจพิจารณา Gin แทน Flask
- อาจลองดูก่อนด้วยว่าสามารถทำเองโดยใช้ library 0 ตัวได้หรือไม่
- ก่อนอื่นสร้าง
- หากเริ่มด้วย framework ขนาดใหญ่หรือโปรเจกต์ที่มี breaking change ต่อเนื่อง จะตามให้ทันภายในเวลาส่วนตัวได้ยากและอาจหมดแรงเร็ว
- เว็บต้องการความแปลก ความตื่นเต้น และตัวตนให้มากขึ้น และสนับสนุนให้ลองสร้างเว็บไซต์ไดนามิกดู
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
บนมือถือ ความกว้างของเว็บไซต์ คำนวณไม่ถูกต้อง ทำให้ต้องเลื่อนซ้ายขวาเพื่ออ่านบทความ
พอดีก่อนหน้านั้นเพิ่งอ่านประโยคว่า “ผมมีมาตรฐานที่สูงและแปลกมาก” เลยบอกตรง ๆ ว่าขำอยู่หน่อย ๆ :)
preเลยดูเหมือนย่อหน้าขนาดยักษ์ย่อหน้าเดียวเท่านั้น ¯_(ツ)_/¯เคยเห็นการจัดรูปแบบแปลก ๆ บ่อยแล้ว แต่เพิ่งเคยเห็นแบบไม่มีการจัดรูปแบบเลยเป็นครั้งแรก
แต่ถึงอย่างนั้นความประทับใจแรกก็ไม่ดี
ไม่เข้าใจเลย
เจ้าตัวจะภูมิใจก็เป็นเรื่องดี แต่ผมเลือกที่จะไม่อ่านก็แล้วกัน
แก่นสำคัญคือ “ทำให้เรียบง่ายไว้” หมายถึงอะไรกันแน่ และ “เข้าใจได้” คืออะไร
บทความแบบนี้มักข้ามประเด็นถกเถียงที่น่าสนใจไป แล้วตั้งสมมติฐานเอาเองว่าแนวทางของตนนั้นเรียบง่ายและเป้าหมายคือความเรียบง่าย
เมื่อสามารถเลือกใช้ abstraction เช่นไลบรารีหรือเฟรมเวิร์ก บริการ หรือ API ได้ การใช้มันเรียบง่ายกว่า หรือการไม่ใช้เรียบง่ายกว่ากัน?
ถ้าไม่ใช้แล้วสร้างเอง ก็จะรู้ดีกว่าว่าระบบทั้งหมดทำงานอย่างไร ในความหมายหนึ่งจึงเรียบง่ายกว่า
แต่ความซับซ้อนก็ยังเกิดขึ้นอยู่ดี และบางกรณีก็ต้องสร้างชั้น abstraction เองด้วย
ในทางกลับกัน ถ้าใช้มันก็เป็นการซ่อนความซับซ้อน ดังนั้นในเส้นทางปกติอาจมองได้ว่าระบบเรียบง่ายกว่า แต่ความซับซ้อนนั้นยังคงมีอยู่และถูกซ่อนไว้ ทำให้เราไม่เข้าใจมัน
ทั้งสองวิธีต่างก็ดูเรียบง่ายอย่างชัดเจนจากบางมุมมอง แต่ต้องมองให้พ้นความชัดเจนนั้นจึงจะเห็น trade-off
โดยทั่วไปก็ซื้อวัตถุดิบกับเครื่องมือ แล้วอบในเตาอบที่มีอยู่แล้ว
แต่ถ้าจะทำพายแอปเปิลตั้งแต่ต้นจริง ๆ ก่อนอื่นต้องสร้าง จักรวาล ขึ้นมาก่อน และก็คงจะสร้างจักรวาลที่เรียบง่ายที่สุดซึ่งรองรับพายแอปเปิลได้
สแต็กทั้งหมดอาจเรียบง่ายกว่า แต่ขั้นตอนสุดท้ายคือการทำพายจริง ๆ อาจซับซ้อนขึ้น และรสชาติก็อาจไม่ดีที่สุด
แต่แลกกับการได้พายที่เข้าใจอย่างสมบูรณ์ตั้งแต่ first principles
คุณอาจชอบบรรยายนี้ของ Rich Hickey: https://paulrcook.com/blog/simple-made-easy
เราอาจเพิ่มฟีเจอร์เพื่อทำให้บางอย่างสร้างหรือ deploy ได้ง่ายขึ้น แต่การเพิ่มนั้นทำให้ภาพรวมซับซ้อนขึ้น และทำให้เข้าใจหรือไล่หาปัญหาได้ยากขึ้น
ผู้เขียนบอกชัดมากตอนท้ายว่าให้แต่ละคนทำในแบบของตัวเอง
แถมยังบอกด้วยว่าเขาไม่พอใจกับการใช้ระบบที่ตัวเองเข้าใจยากหรือรู้สึกเป็นภาระ
น่าจะลองอ่านต่อจากย่อหน้าแรกด้วย
เจ๋งมาก!
แต่ผมไม่เห็นด้วยอย่างยิ่งกับ “ทุกคนก็ควรทำแบบนี้!” :)
ความสามารถในการดูแลรักษาเป็นหนึ่งในคุณค่าหลักของผม ดังนั้นผมก็ซ่อมบำรุงจักรยานเองเหมือนคุณ
แต่สำหรับผมมันไม่ได้เป็นอันดับหนึ่งถึงขนาดนั้น ตัวเลือกแบบนี้เลยไม่สมเหตุสมผลสำหรับผม
โน้ตบุ๊ก Framework เป็นจุดที่แสดงความต่างของเราได้ดี
คุณดันคะแนนฝั่ง DIY ได้ 9 เต็มตลอด แต่ผมสร้างความยืดหยุ่นด้วยการมี ThinkPad สำรองอายุ 10 ปี ที่พร้อมรัน Linux กับ Neovim แบบฉุกเฉินได้ทุกเมื่อ และถ้ามันพังไปอีก ผมก็เชื่อว่าในอนาคตยังจะมี ThinkPad ราคาไม่ถึง 100 ดอลลาร์ให้ซื้ออีกมาก
ผมพกความรู้ด้านวิทยาการคอมพิวเตอร์และคณิตศาสตร์มากพอที่จะเขียน parser แปลง Markdown เป็น HTML ด้วย Haskell combinator แบบช้า ๆ ไม่เป็นทางการ และบั๊กเยอะได้ หากวันหนึ่งจำเป็นต้องทำ
แต่ก็ไม่คิดว่าวันแบบนั้นจะมาถึงเร็ว ๆ นี้
ถ้าเป็นไปได้ ผมอยากจ้างคุณ
คุณน่าจะเป็น ตัวถ่วงดุล ที่สมบูรณ์แบบสำหรับผู้คนจำนวนมากที่เอนเอียงไปทางตรงข้าม
ผมอ่านบทความนี้อย่างสนุกมาก
ผู้เขียนซื่อตรงต่อตัวเองและจริงจังกับผู้อ่าน
เขาเป็นตัวของตัวเองโดยไม่แก้ตัว และพยายามบรรลุเป้าหมายด้วยวิธีที่สอดคล้องกับคุณค่าของตนและทำให้ตนมีความสุข
ถ้าคุณค่าเหล่านั้นไม่ตรงกับคุณก็ไม่เป็นไร และจริง ๆ แล้วเป็นเรื่องงดงามด้วยซ้ำ
ตอนนี้คุณก็ได้เบาะแสเกี่ยวกับเส้นทางที่คุณอาจสำรวจต่อแล้ว
บทความนี้เป็นมิตร ถ่อมตัว จริงใจ และผมคิดว่าผู้เขียนกับบทความทำให้โลกดีขึ้นเล็กน้อย
เรื่องถ่อมตัวก็เช่นกัน
ทั้งบทความใกล้เคียงกับ การชมตัวเอง และระหว่างทางก็เห็นชิ้นส่วนแบบ /r/confidentlyincorrect อยู่บ้าง
ผู้อ่านเป็นเพียงกลุ่มรอง ดังนั้นไม่ว่าประสบการณ์ของผู้อ่านจะสปาร์ตันแค่ไหนก็ไม่ใช่ประเด็นหลัก ประสบการณ์ของผู้เขียนต่างหากที่เป็นแก่น
ดูเหมือนคนจำนวนมากที่มาจากแพลตฟอร์มมือถือจะเลิกอ่านเร็วเกินไป
ผมลองกวาดตาดูคร่าว ๆ แล้ว คนนี้แทบจะแน่นอนว่ากำลังปั่นพวกเราอยู่
เว็บไซต์บอกว่าใช้ “plain HTML” ตามตัวอักษร แต่จริง ๆ แล้วเป็น plain text
ที่นี่ไม่มี HTML สำหรับจัดรูปแบบเลย
ไม่มีหัวเรื่อง ไม่มีย่อหน้า ไม่มีรายการ และแม้แต่แท็ก a ก็ไม่มี
HTML กับ CSS ที่มีอยู่นิดหน่อยกลับทำให้ไซต์เรนเดอร์แย่ลงด้วยซ้ำ
คนเขียนเป็น troll
บอกว่า “ผมมีมาตรฐานที่สูงมากและแปลกประหลาด” พร้อมเสริมว่า “สคริปต์นี้รันทุกนาทีด้วย cronjob และถ้า git repository ถูกอัปเดต ก็จะ build เว็บไซต์ใหม่”
เท่ากับว่าไปดึง repository ที่อาจมี commit แค่ไม่กี่ครั้งต่อปีถึง 525,600 ครั้งต่อปี
พอเข้าใจแล้วว่าทำไมถึงใช้คำว่า “แปลกประหลาด”
git fetchก็แทบจะใกล้เคียงกับการเปรียบเทียบสตริงหนึ่งครั้งเท่านั้น [0] ดังนั้นผมมองว่าไม่ได้เป็นงานที่มีต้นทุนสูงเท่าที่พูดกัน[0] https://stackoverflow.com/a/44476803
ไม่ควรถาม แต่ควรบอกให้รู้
git repository ของผมทั้งหมดอยู่บนเซิร์ฟเวอร์เดียวกับที่โฮสต์เว็บไซต์
git ไม่ได้ทำ remote fetch แต่ทำ local fetch จึงแทบจะเสร็จทันที
ต่อให้เป็น remote fetch ก็ยังไม่เป็นไรอยู่ดี
HTTP request 525,600 ครั้งต่อปียังสิ้นเปลืองน้อยกว่า heartbeat ของ NetworkManager
บน Arch ค่าเริ่มต้นคือ heartbeat request 1 ครั้งทุก 30 วินาที
อ้างอิงไว้ว่าเซิร์ฟเวอร์ nginx พื้นฐานที่มี CPU 8 ตัวสามารถรับ HTTP request ได้มากกว่า 500,000 ครั้งต่อวินาที
ถึง OP:
ผมเห็นข้อความวิจารณ์แรง ๆ เยอะมากในนี้
พูดอย่างสุภาพคือ… อย่าไปสนใจเลย
คำวิจารณ์อาจถูกก็ได้ แต่ทั้งวงการกำลังไหลตาม “ต้องทำ” และ “ควรจะเป็นอย่างนั้น” แบบหมู่คณะ แล้วมุ่งหน้าอย่างรวดเร็วไปสู่ ความโง่เขลาขนาดใหญ่
ส่วนมากในนั้น ณ ตอนนี้มีความสมเหตุสมผลแค่ระดับตำนานเมืองเท่านั้น
สิ่งที่ทุกวันนี้เรียกว่า “engineering” คงเป็นเรื่องน่าหัวเราะถ้าเราไม่ได้กำลังสร้างอนาคตทับอยู่บนนั้นอย่างจริงจัง
พ่อผมเคยเป็นวิศวกรการบินและอวกาศ และถ้าเห็นสิ่งที่ถูกเรียกว่า engineering ในการพัฒนาซอฟต์แวร์สมัยใหม่ ท่านคงดิ้นอยู่ในหลุมแน่
นี่เป็นช่องคอมเมนต์ ใคร ๆ ก็มีเสรีภาพที่จะพูด แต่โดยส่วนตัวแล้ว ผมใช้เวลา 25 ปีในวงการกว่าจะเริ่มเมินเสียงจ้อกแจ้กเหล่านั้น และทำสิ่งที่ผมรู้สึกว่ามีเหตุผลเมื่อมีโอกาสอันหาได้ยาก
ยิ่งถ้าเป็นเว็บส่วนตัวด้วยแล้ว ยิ่งไม่ต้องพูดถึงเลยไม่ใช่หรือ?
วลีเก่า ๆ ในโฆษณา Apple ที่ว่า “แด่คนบ้า” ตอนนี้ฟังดูห่างไกลจากความจริงมาก
ไม่น่าแปลกใจเลยที่อินเทอร์เน็ตกลายเป็นแบบนี้ และเหล่าบริษัทที่ครั้งหนึ่งเคยเป็นสตาร์ทอัป ตอนนี้กลายเป็นอสูรองค์กรที่ใหญ่ที่สุดบนภูมิประเทศไปแล้ว
คำพูดของ Theodore Roosevelt เรื่อง “คนในสนามแข่ง” ทุกวันนี้ช่างตรงจริง ๆ
ทำต่อไปนะ OP ทำต่อไป…
เว็บไซต์ของผมไม่ใช่ไซต์ที่ optimize อย่างสมบูรณ์แบบ แต่เป็น สนามเด็กเล่นศักดิ์สิทธิ์และไม่เหมือนใคร ของผมเอง
ทุกอย่างผมเขียนเองและค่อย ๆ วิวัฒน์ไปตามเวลา
แน่นอนว่าสไตล์ของผมอาจขัดหูขัดตาคนอื่นบ้าง และผมก็คุ้นกับคำวิจารณ์แบบนั้นแล้ว
บางครั้งผมตัดสินใจแปลก ๆ เพื่อดัดเนื้อหาให้เข้ารูปแบบที่ผมชอบ แต่ผมคิดว่านั่นแหละที่ทำให้เนื้อหาของผมน่ารัก
เพราะมันไม่เหมือนอย่างอื่นข้างนอก
อาจมีเหลี่ยมคมอยู่บ้าง แต่เมื่อสำรวจ “รูปแบบส่วนตัว” ไปเรื่อย ๆ มันก็คงจะดีขึ้น :)
สำหรับผม เว็บไซต์เหมือน โปรเจกต์ศิลปะ ระยะยาว
มันควรสะท้อนผู้เขียน และในกรณีของผม เว็บไซต์ของผมก็สะท้อนตัวผมอย่างภาคภูมิ
ไหน ๆ ของคุณก็ออกมาแล้ว ผมขอโชว์ของผมบ้าง
เว็บไซต์ของผม, game engine และเว็บเซิร์ฟเวอร์เป็น ไบนารีเดียว
ซอร์สเป็นโค้ด C 1000 บรรทัด และไบนารีมีขนาด 164KB
ไม่รู้เหมือนกันว่าทำไมมันถึงใหญ่บ้าบอขนาดนี้
ผมรวมเว็บเซิร์ฟเวอร์เข้าไปเองด้วย
เซิร์ฟเวอร์ที่มีอยู่เดิมเพิ่มความซับซ้อนที่ซ่อนอยู่มากเกินไป
เกม interactive fiction ภาษาเยอรมันที่เป็นผลลัพธ์ดูได้ที่นี่: http://vmd34232.contaboserver.net/
ไม่มีการติดตาม ไม่มีโฆษณา ไม่มีวัตถุประสงค์เชิงพาณิชย์
ลองบีบอัดไฟล์ executable ด้วย upx ได้ https://upx.github.io/
https://toldby.ai/
ของผมไม่ใช่ไบนารีเดียว แต่เป็น asp.net
ผมเห็นด้วยอย่างเต็มที่กับทุกประเด็นที่บทความยกขึ้นมา แต่เว็บไซต์นี้ไม่ค่อยเหมาะเป็นตัวอย่างเท่าไร
บอกว่าเว็บไซต์เป็น “ไบนารีเดียว” แต่กลยุทธ์การ deploy กลับรวมการคอมไพล์แทนที่จะรัน binary artifact
บอกว่าจะไม่พึ่ง github pages แต่กลับพึ่ง resource ภายนอกจาก openlibrary.org
บอกว่าถ้าทำเองจะใช้ประโยชน์จากมาตรฐานเปิดได้ แต่ไฟล์
.htmlในthoughts/เป็นโครงสร้าง plain text ที่ติดนามสกุลปลอมเวลาคนเลือกทางนี้ ปกติมักพยายามยัดทุกอย่างเข้าไปในการโหลดหน้าแรก แต่ที่นี่มีไฟล์สแตติกหลายไฟล์ที่ถูกเสิร์ฟแบบไดนามิก
โค้ด Golang ไม่ cache response ใด ๆ และไม่ได้เก็บ template ไว้ในหน่วยความจำ
ในไฟล์
go.modมี dependency หลายตัว ซึ่งดูเหมือนจะไม่ได้ใช้ทั้งหมดที่สำคัญที่สุดคือ ไม่มีการพูดถึงว่า จิตวิญญาณแบบไบนารีเดียว มีข้อได้เปรียบเชิงเทคนิคอะไรเมื่อเทียบกับโครงสร้างพื้นฐานสมัยใหม่
โดยส่วนตัวผมคิดว่าเป็นไอเดียที่ดี แต่นี่เป็นตัวอย่างที่แย่
แต่เป็นไบนารีเดียวที่ทำงานร่วมกับ filesystem
เนื้อหาทั้งหมดอยู่ใน filesystem
“ไบนารีเดียว” คือ เว็บเซิร์ฟเวอร์ Golang น้ำหนักเบาที่เสิร์ฟเนื้อหาจาก filesystem
“มาตรฐานที่สูงมากและแปลกประหลาด” งั้นหรือ แปลกประหลาดน่ะใช่ แต่ดีไซน์เว็บไซต์ที่ออกมาห่วยมากจนแสดงข้อความให้พอดีกับหน้าจอไม่ได้ด้วยซ้ำ ดังนั้นมาตรฐานกลับ ต่ำมาก