เหตุใดฉันจึงเลือก Angular เพื่อสร้างตัวย่อ URL

URL Shorteners เป็นเครื่องมือที่เราใช้ในการทำให้ลิงก์สั้นกว่าที่เป็นจริง ด้วยเครื่องมือย่อ URL คุณสามารถเปลี่ยนลิงก์ยาว (อาจเป็นสำหรับแบบฟอร์มการลงทะเบียนหรือบทความ) เป็นเวอร์ชันที่สั้นกว่า

เบื้องหลัง ลิงก์ที่ระบุเวอร์ชันยาวและสั้นได้รับการจัดเก็บไว้ในฐานข้อมูลบางส่วน จากนั้นเมื่อผู้ใช้เข้าชมลิงก์แบบสั้นในเบราว์เซอร์ URL Shortener จะเปลี่ยนเส้นทางผู้ใช้ไปยังลิงก์เวอร์ชันยาว (ซึ่งพบเนื้อหาจริง)

ลิงก์แบบย่อจากตัวย่อ URL มักใช้เมื่อลิงก์เหล่านั้นในเวอร์ชันยาวจะยาวเกินกว่าจะใช้ได้ การแชร์ลิงก์บนโซเชียลมีเดียหรือเมื่อออกแบบใบปลิวและโฆษณาคือการใช้ตัวย่อ URL ที่ได้รับความนิยม

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

ในการสร้างลิงก์ ฉันต้องใช้คอนโซล Firebase นี่ไม่ใช่ปัญหา แต่มันยุ่งยากสำหรับการแก้ไขลิงก์ที่มีความถี่สูง ประสบการณ์ผู้ใช้ (UX) ไม่เหมาะ ตอนนี้ฉันประสบปัญหา ฉันจะสร้าง แก้ไข และลบลิงก์ได้อย่างไร ฉันต้องการสร้างส่วนหน้าสำหรับตัวย่อ URL ฉันต้องการเว็บไซต์สำหรับสิ่งนี้

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

คำชี้แจงปัญหา

ข้อกำหนดของโครงการคือ:

• แพลตฟอร์ม/สถาปัตยกรรม. วิศวกรรมและโครงสร้างของกระบวนการเข้ารหัส
• ชุดเครื่องมือ UI. ส่วนประกอบที่ใช้สำหรับส่วนต่างๆ ของ UI
• ความสะดวกสบาย. การสร้างแบ็กเอนด์ไม่ใช่เรื่องยาก ดังนั้นส่วนหน้านี้จึงไม่ควรเป็นเช่นนั้น ฉันต้องการโค้ดที่สะอาดและการพัฒนาที่รวดเร็ว

ตัวเลือกการตัดสินใจครั้งแรก: Angular

แนวคิดมากมายเกิดขึ้นในใจเมื่อเริ่มต้นสร้างส่วนหน้า ในความหมายกว้างๆ เราสามารถจัดหมวดหมู่ตัวเลือกการสร้างส่วนหน้าเป็น 3 แพลตฟอร์ม:

1. เครื่องมือสร้างเว็บไซต์ – เช่น WordPress, Wix, Squarespace เป็นต้น
2. อาคารวานิลลา – ใช้ HTML, CSS และ JavaScript ธรรมดา
3. JavaScript Framework – เช่น React, Vue, Angular เป็นต้น

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

การใช้รูปแบบที่ไม่มีกรอบหรือวานิลลาน่าจะเป็นไปได้ อย่างไรก็ตาม ปัจจัยในการตัดสินใจที่ทำให้ผมเลือกเส้นทางวานิลลาแท้ไม่ได้ก็คือ Firebase JavaScript SDK เวอร์ชันล่าสุดที่ไม่ใช่ CDN (เวอร์ชัน 9) ออกแบบพร้อมติดตั้งผ่าน npm or yarn และการรวมโมดูลไว้ในใจ

กรอบงาน JavaScript จัดการส่วนหลักของส่วนหน้า (เช่น การกำหนดเส้นทาง การเชื่อมโยงส่วนหลัง ฯลฯ) เพื่อลดความพยายามของนักพัฒนา มีมากมายและการเลือกที่จะใช้ดูเหมือนจะเป็นทางเลือกที่ยากกว่า

มีกรอบงาน JavaScript มากมายสำหรับการพัฒนาส่วนหน้า ตัวอย่าง ได้แก่ Angular, React, Vue เป็นต้น

จากเฟรมเวิร์กที่มีอยู่ ฉันคุ้นเคยกับ Angular มากที่สุด นี่เป็นเพราะฉันเคยใช้ในโครงการก่อนหน้านี้เช่น:

• แบบทดสอบนักร้องประสานเสียง: พอร์ทัลที่ผู้เข้าร่วม Quiz แข่งขันกันในสองรอบออนไลน์ของคำถามแบบเลือกตอบตามกำหนดเวลาในบทพระคัมภีร์ที่เลือก
• ชุมชน Genesys AE-FUNAI: แบบฟอร์มที่กำหนดเองซึ่งสมาชิกของ Genesys Campus Club AE-FUNAI (ชุมชนของฉัน) รายงานความคืบหน้าและแบ่งปันความสำเร็จของพวกเขา
• ระบบการจัดการการสอน: แดชบอร์ดการจัดการเซสชั่นอย่างง่ายระหว่างนักเรียนและผู้สอน

ความคุ้นเคยนี้ทำให้ฉันสร้าง Angular ได้อย่างรวดเร็ว ไม่ควรมองข้ามความสามารถในการสร้างอย่างรวดเร็ว

ฉันเลือก Angular เนื่องจากความสามารถในการเขียนโปรแกรมเชิงวัตถุ (OOP) OOP เป็นกระบวนทัศน์การเขียนโปรแกรมที่เน้นที่คลาส ข้อมูล หรือสถานะที่ได้รับการจัดการมากกว่าที่ตรรกะที่ควบคุมข้อมูล เช่นเดียวกับกรณีของการเขียนโปรแกรมเชิงฟังก์ชัน การแยกข้อกังวลเป็นข้อดีอย่างหนึ่งของการใช้ OOP กล่าวอีกนัยหนึ่ง OOP อนุญาตการห่อหุ้ม อนุญาตให้คุณกำหนดขอบเขตแง่มุมต่างๆ ของโปรแกรมไปยังโดเมนหรือคลาสเฉพาะ

ใน Angular ส่วนประกอบ (และวิธีการวงจรชีวิต) ถูกกำหนดขอบเขตเป็นคลาส TypeScript สิ่งนี้ทำให้คุณคิดแบบ OOP ข้อได้เปรียบของ OOP สะท้อนให้เห็นว่าส่วนประกอบเชิงมุมทำหน้าที่เป็นหน่วย UI ที่นำกลับมาใช้ใหม่ในกรอบงานเชิงมุมได้อย่างไร ด้วยวิธีนี้คุณจะเห็นองค์ประกอบเชิงมุมเป็นเอนทิตีแบบพอเพียงบางส่วนที่ยังเป็นส่วนหนึ่งของทั้งหมด สิ่งนี้ทำให้การพัฒนาส่วนหน้าทำได้ง่าย เนื่องจากส่วนต่างๆ ของแอพส่วนหน้าสามารถกำหนดขอบเขตเป็นส่วนประกอบ และด้วยเหตุนี้จึงสามารถใช้เมื่อจำเป็น

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

อันเป็นผลมาจากระบบประเภท TypeScript ช่วยลดเวลาที่ใช้ในการดีบักแอป Angular มันให้ประสบการณ์ของนักพัฒนาเนื่องจากนักพัฒนาจะมีเวลามากขึ้นในการสร้างแอพส่วนหน้า การดีบักยังกลายเป็นเรื่องง่ายสำหรับนักพัฒนา

หมายเหตุ นี่คือข้อมูลเพิ่มเติมเกี่ยวกับการเขียนโปรแกรมเชิงวัตถุด้วย TypeScript

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

บริการ Angular คือสิ่งที่ Angular ใช้ในการกำหนดค่าการฉีดพึ่งพา พูดง่ายๆ ก็คือ การฉีดการพึ่งพาคือการจัดเตรียมแอปพลิเคชันที่มีสิ่งที่จำเป็นต้องทำงาน (การพึ่งพา) โดยที่แอปพลิเคชันไม่ต้องดูแลว่าการพึ่งพาได้รับมาอย่างไร ฉันยังเลือก Angular เนื่องจากการจัดการบริการที่พร้อมใช้งานทันที ตัวอย่างเช่น Firebase จะถูกจัดเตรียมโดยอัตโนมัติให้กับส่วนประกอบ Angular ทั้งหมดที่ต้องการโดยไม่มีการกำหนดค่าเพิ่มเติม

ประโยชน์ของการเขียนโปรแกรมเชิงวัตถุ, TypeScript และการฉีดพึ่งพาทำให้ Angular เป็นเป้าหมายในการพัฒนาส่วนหน้า เมื่อรวมกับความจริงที่ว่าฉันคุ้นเคยกับ Angular แล้ว Angular ก็สะดวกกว่าสำหรับโครงการย่อ URL นี้

บทความเชิงมุมเกี่ยวกับ CSS-Tricks ก็เป็นส่วนหนึ่งของเรื่องราวเช่นกัน พวกเขาทำให้ฉันมั่นใจมากขึ้นในการใช้ Angular

ตัวเลือกการตัดสินใจที่สอง: การออกแบบวัสดุ

หลังจากเลือก Angular งานต่อไปของฉันคือพิจารณาว่าฉันจะจัดการกับส่วนต่อประสานผู้ใช้ (UI) อย่างไร

ฉันสามารถเพิกเฉยและทำ vanilla CSS แทนได้ แต่ทำไมต้องสร้างวงล้อขึ้นมาใหม่? ท้ายที่สุด สิ่งนี้จะเอาชนะเหตุผลในการใช้เฟรมเวิร์ก JavaScript – ความสะดวก

ด้วยการเลือกชุดเครื่องมือ UI ดูเหมือนว่าจะมีตัวเลือกมากมาย ตัวอย่างเช่น คุณสามารถใช้ Bootstrap, Bulma, Semantic UI, Tailwind เป็นต้น ชุดเครื่องมือแต่ละชุดมีข้อกำหนดและแรงจูงใจในตัวเอง

สำหรับกรณีการใช้งานของโปรเจ็กต์ของฉัน Material Design เป็นผู้นำกลุ่มนี้

ปัจจัยที่สำคัญที่สุดประการหนึ่งคือการรองรับการออกแบบเชิงมุมและวัสดุ มีข้อกำหนดเชิงมุมเท่านั้นสำหรับ Material on material.angular.io (นั่นคือโดเมนย่อยของ Angular docs เอง)

ฉันเลือก Material Design เพราะเน้นที่ส่วนประกอบ ไม่เหมือนกับเฟรมเวิร์ก CSS อื่นๆ เนื่องจากไม่มีคลาสยูทิลิตี้ CSS ไม่เป็นไรเพราะฉันต้องการแค่ชุดส่วนประกอบบางอย่าง (ปุ่ม ไอคอน อินพุต แถบด้านข้าง สแน็คบาร์ ฯลฯ) วัสดุยังเพิ่มแอนิเมชัน ระลอกคลื่น และเอฟเฟกต์เงาด้วยตัวมันเอง ทำให้สะดวกกว่าห้องสมุดอื่นๆ

นอกจากนี้ Angular Material ยังมีการสนับสนุนธีมแบบสำเร็จรูป เมื่อเริ่มต้น Angular Material คุณมีตัวเลือกในการเลือกธีมที่กำหนดไว้ล่วงหน้าสำหรับแอป Angular ทั้งหมดหรือสร้างธีมที่กำหนดเอง

เพื่อความสะดวก ฉันเลือกธีมสีเข้มขณะตั้งค่า Angular Material

ตัวเลือกการตัดสินใจที่สาม: แบบฟอร์มปฏิกิริยา

เมื่อตัดสินใจเลือกกรอบงานและชุดเครื่องมือแล้ว ฉันจึงหันมาสนใจคุณลักษณะที่สำคัญที่สุดอย่างหนึ่งของตัวย่อ URL แกนหลักของส่วนหน้าของตัวย่อ URL คือแบบฟอร์มสำหรับการสร้างและอัปเดตลิงก์

เรียกแบบฟอร์มนี้ว่าตัวแก้ไขลิงก์ แบบฟอร์มแก้ไขลิงก์มีเพียงสองอินพุต หนึ่งสำหรับเวอร์ชันสั้นของลิงก์ และอีกรายการสำหรับ URL แบบเต็มที่เวอร์ชันสั้นจะเปลี่ยนเส้นทางไป

สำหรับการจัดการแบบฟอร์ม Angular มีสองกลไก ดังนั้น แทนที่จะสร้างฟอร์มและจัดการการตรวจสอบและการส่งแบบเดียวกับที่ทำใน vanilla HTML และ JavaScript คุณต้องใช้วิธีใดวิธีหนึ่งจากสองวิธีที่ Angular จัดเตรียมให้ สองวิธีคือ:

1. แบบฟอร์มที่ขับเคลื่อนด้วยเทมเพลต
2. รูปแบบปฏิกิริยา

แบบฟอร์มที่ขับเคลื่อนด้วยเทมเพลต ตามชื่อที่สื่อถึง เกี่ยวข้องกับโค้ด HTML (เทมเพลต) ที่ควบคุมส่วนใหญ่ของรูปแบบเชิงมุม วิธีนี้เหมาะกว่าเมื่อแบบฟอร์มของคุณไม่ได้ช่วยอะไรมากหรือใช้เพียงครั้งเดียว

รูปแบบปฏิกิริยาในทางกลับกัน ให้แนวทางที่ขับเคลื่อนด้วยแบบจำลองเพื่อจัดการกับอินพุตของฟอร์มที่มีค่าเปลี่ยนแปลงตลอดเวลา ฉันต้องการแบบฟอร์มตอบโต้เนื่องจากเป็นแบบฟอร์มเดียวกับที่ฉันจะใช้แก้ไขลิงก์ต่างๆ ในเวลาใดก็ได้

หมายเหตุ ต่อไปนี้เป็นเนื้อหาเพิ่มเติมเกี่ยวกับการใช้แบบฟอร์มปฏิกิริยา

เมื่อมาถึงจุดนี้ ประโยชน์ของตัวเลือกก่อนหน้าเริ่มแสดงออกมา วัสดุเชิงมุมมี form-field ส่วนประกอบ ดิ form-field ล้อมอินพุตเป็นส่วนประกอบและจัดเตรียมภาพเคลื่อนไหว เอฟเฟกต์ระลอกคลื่น และข้อความแสดงข้อผิดพลาดหากจำเป็น

ดังนั้นฉันจึงใช้มันสำหรับอินพุตสองตัวของแบบฟอร์มตัวแก้ไข

ตัวเลือกการตัดสินใจที่สี่: แผ่นและลิ้นชักด้านล่างวัสดุเชิงมุม

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

หากผู้ใช้ไม่ต้องการแบบฟอร์มตัวแก้ไขลิงก์ ย่อมเหมาะสมที่ฟอร์มตัวแก้ไขลิงก์จะไม่อยู่ในมุมมองเสมอ สิ่งนี้จะเพิ่มพื้นที่ว่างบน UI สำหรับองค์ประกอบอื่นๆ

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

A แผ่นงานด้านล่างเป็นองค์ประกอบ UI ที่เปิดขึ้นจากด้านล่างของหน้าจอ ตามชื่อที่สื่อถึง มีเนื้อหาแบบโต้ตอบที่ผู้ใช้สามารถใช้งานได้ มันซ้อนทับมุมมองปัจจุบันของหน้าจอมือถือ (แต่ไม่ได้ปิดกั้นอย่างสมบูรณ์)

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

ลิ้นชัก เปิดข้าง. การใช้ Drawer เพื่อเปิดแบบฟอร์มตัวแก้ไขลิงก์บนหน้าจอกว้างคือตัวเลือกที่ใช้ได้ ลิ้นชักจะไม่เหมาะกับตัวแก้ไขบนหน้าจอมือถือ ความกว้างของหน้าจอจะค่อนข้างเล็ก และลิ้นชักอาจปิดกั้นหน้าจอทั้งหมด (ซึ่งไม่ใช่ UX ที่พึงประสงค์)

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

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

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

การบำรุงรักษา การพิสูจน์อนาคต การเผยแพร่ในอนาคต

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

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

ถ้าฉันต้องทำซ้ำอีกครั้ง ฉันคิดว่าฉันจะลองใช้วิธีวานิลลา สร้างทั้งหมดโดยไม่มีผู้ช่วย เช่น ส่วนประกอบ Angular วัสดุ หรือ UI ฉันจะลองสร้างจากศูนย์ใน HTML, CSS และ JavaScript และดูว่าฉันไม่เสียความสะดวกอย่างที่คิดหรือไม่

สรุป

คุณสามารถเข้าถึงโค้ด Angular สุดท้ายได้ที่นี่บน GitHub

นี่เป็นการทบทวนตัวเลือกหลักบางอย่างที่ฉันทำเมื่อพัฒนาโครงการ แน่นอนว่ายังมีอีกมากในการสร้างส่วนหน้าของตัวย่อ URL แต่สำหรับการเริ่มต้น ส่วนประกอบ UI เหล่านี้ทำให้กระบวนการสร้างสะดวกขึ้น พวกเขาทำให้รูปแบบตัวแก้ไขลิงก์ตอบสนองและอาจมีประโยชน์คล้ายกับคุณในโครงการของคุณ (ไม่จำเป็นต้องเป็นตัวย่อ URL)

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

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

ไชโย!