Kasidit Wansudon

Full-stack Developer in Bangkok — building web & mobile systems end-to-end.

Accomplished Full-stack developer with expertise in Flutter, Node.js, and Laravel. Passionate about creating cross-platform applications and web-based systems. Fast learner who never stops exploring new technologies.

Bangkok, Thailand0637902362kasidit.wans@gmail.com
อ่านบทความดู Resumeฝากข้อความCascade / MCP

Around the internet

ประสบการณ์

4+ ปี

สร้างระบบ production

โฟกัส

Flutter, Node.js

เน้น Flutter, Node.js, Laravel, Vue.js

องค์กรปัจจุบัน

Pos Sefi Group Co., Ltd. (OPPO)

Full Stack Programmer

ภาษา

Thai · English

พร้อมสื่อสารกับทีม

Selected work

Projects & impact

ดูทั้งหมด
Apr 2024 - PresentThailand

Full Stack Programmer

Pos Sefi Group Co., Ltd. (OPPO)

1 year 9 months · Vue.js, Zend, Laravel, Flutter

  • Developed and maintained Sellin, Sellout, HR, and AppHR systems
  • Improved system performance, designed, and managed databases
  • Acted as a consultant for Flutter and JavaScript applications, providing guidance on OOP principles
Jun 2023 - Apr 2024Thailand

Flutter Programmer

Rainbow Solution

10 months · Flutter, MQTT, Google Maps API, JavaScript

  • Created cross-platform applications running on Linux, Windows, Web, and macOS
  • Developed web-based POS systems with restaurant management, payment processing, and reporting
  • Implemented real-time technology for fast and efficient user experiences

Core skills

Tech stack & tools

ชุดทักษะที่ใช้จริงใน production และงาน consult

Flutter

expert

Mobile · 3+ yrs

Laravel

expert

Backend · 3+ yrs

Node.js

expert

Backend · 3+ yrs

Vue.js

expert

Frontend · 2+ yrs

Git

advanced

DevOps · 4+ yrs

HTML/CSS

advanced

Frontend · 4+ yrs

Latest work

Personal blog & guestbook

แพลตฟอร์มเดียวที่เล่า process การพัฒนา, เก็บโน้ตเทคนิค และให้คนฝากคอมเมนต์ได้แบบ real-time โดยเชื่อม Next.js 14, Supabase และ Cloudflare Pages เข้าด้วยกัน

Next.js 14SupabaseCloudflare PagesTypeScriptTailwind

MCP stack

Tools & workflows I automate

สรุป server ที่ใช้งานจริง (gdrive, brave-search, deepwiki, memory) พร้อมวิธีทำงานร่วมกับทีม

เปิดเอกสารเต็ม

MCP (Model Context Protocol) — สรุปข้อดี/ข้อเสีย + ตัวอย่างการทำงานร่วมกัน

ครอบคลุม MCP ที่มีในเครื่องคุณตอนนี้: gdrive, brave-search, deepwiki, memory

ภาพรวม MCP

แนวคิดหลัก: Tooling แบบปลั๊กอิน
MCP คืออะไร
มาตรฐานการเชื่อม “AI Assistant” กับ “เครื่องมือ/ข้อมูลภายนอก” ผ่านชุด tool ที่เรียกใช้ได้ (เช่น search, drive, wiki, memory)
ทำไมถึงดี
แยกความรับผิดชอบชัดเจน: AI ทำ reasoning/ตัดสินใจ ส่วน MCP ทำงานเฉพาะทาง (ค้นหาไฟล์, ดึงข้อมูล repo, ค้นเว็บ, เก็บความจำ)

สถานะจากการทดสอบล่าสุด

สรุปเร็ว
  • gdrive: ใช้งานได้
  • deepwiki: ใช้งานได้
  • memory: ใช้งานได้
  • brave-search: web search ใช้ได้ แต่ local search โดน rate limit
หมายเหตุ: บาง server ไม่รองรับ resources เป็นเรื่องปกติ (ไม่ได้แปลว่าเสีย)

ข้อดี/ข้อเสีย (แยกตาม MCP)

gdrive

เหมาะกับ “ค้น/อ่านไฟล์งาน”
ข้อดี
  • ค้นหาไฟล์/โฟลเดอร์ได้เร็ว (เหมาะกับงานเอกสาร)
  • ได้ตัวระบุ resource (เช่น gdrive:///...) เพื่ออ้างอิงไฟล์ ได้แม่น
  • เหมาะกับ workflow: หาไฟล์ → สรุป → แชร์ลิงก์/ชื่อไฟล์ให้ทีม
ข้อเสีย/ข้อจำกัด
  • ต้อง auth ก่อน และสิทธิ์ไฟล์ขึ้นอยู่กับ account ที่ล็อกอิน
  • รูปแบบ query อาจไม่รองรับแบบ Drive API 100% (ควรใช้ query สไตล์ search box เช่น type:folder)
  • การไล่ “ไฟล์ในโฟลเดอร์” มักต้องมี folderId/URI ที่ชัดเจน

brave-search

เหมาะกับ “ข้อมูลใหม่/อ้างอิงภายนอก”
ข้อดี
  • ดึงข้อมูลจากเว็บแบบหลากหลาย เหมาะกับ best practices, ข่าว, docs
  • ช่วยทำ “การอ้างอิง” ให้คำแนะนำมีหลักฐานจากภายนอก
ข้อเสีย/ข้อจำกัด
  • เสี่ยงโดน rate limit (เจอแล้วใน local search)
  • ผลค้นหาอาจผันผวนตามเวลา/ภูมิภาค
  • ต้องระวังเรื่องข้อมูลส่วนตัว/ความลับขององค์กรเวลาใช้ค้นเว็บ

deepwiki

เหมาะกับ “ถามโครงสร้าง repo / ทำความเข้าใจระบบ”
ข้อดี
  • ตอบคำถามเชิงโครงสร้างของ repo ได้ดี (เช่น architecture / modules)
  • ช่วย onboarding ทีม/ทำความเข้าใจ dependency ได้ไว
ข้อเสีย/ข้อจำกัด
  • จำกัดเฉพาะ repo ที่รองรับ (โดยมากคือ GitHub) และไม่ใช่ข้อมูล runtime ของระบบคุณ
  • อาจไม่ทัน commit ล่าสุดเสมอ (ขึ้นกับแหล่งข้อมูล)

memory

เหมาะกับ “เก็บบริบทระยะยาว/กติกาโปรเจกต์”
ข้อดี
  • เก็บความรู้ที่ใช้ซ้ำได้ เช่น business rules, flow, mapping, checklist
  • ลดการถามซ้ำ/ลดโอกาสทำผิดมาตรฐานทีม
ข้อเสีย/ข้อจำกัด
  • ถ้าไม่ดูแล อาจ “เก่า/ผิด” ได้ ต้องมีการ update/ลบเมื่อ rule เปลี่ยน
  • ควรหลีกเลี่ยงการเก็บความลับสำคัญลง memory ถ้าไม่จำเป็น

ตัวอย่างการทำงานร่วมกัน (Workflow Demo)

Scenario: “หาเอกสารงานใน Drive แล้วหาข้อมูลอ้างอิง + เก็บความจำสำหรับรอบถัดไป”

gdrive + brave-search + deepwiki + memory
*เดโมนี้เป็น “ตัวอย่างการทำงานร่วมกัน” แบบอธิบายขั้นตอน (หน้าเว็บไม่ได้เรียก MCP จริงจาก browser)
เริ่ม workflow: MEX leave approve flow

[1] gdrive.search: ค้นหาเอกสาร/โฟลเดอร์จากคำค้น
    query = 'MEX leave approve flow'
    -> (ตัวอย่าง) ได้ไฟล์ที่เกี่ยวข้อง + gdrive:///... URI

[2] memory: บันทึกว่าไฟล์นี้คือแหล่งข้อมูลหลัก
    remember(key='primary_doc', value='gdrive:///...')

[3] brave-search: หาอ้างอิงภายนอก/วิธีทำงาน/แนวปฏิบัติ
    web_search('MEX leave approve flow best practices')
    -> (หมายเหตุ) ถ้า local_search โดน rate limit ให้ใช้ web_search แทน

[4] deepwiki: ถ้าต้องอ่านโครงสร้าง repo เพื่อทำความเข้าใจระบบ
    read_wiki_structure(repo='facebook/react') (ตัวอย่าง)

[5] สรุปผล: ส่งชื่อไฟล์/ลิงก์/ข้อเสนอแนะที่อ้างอิงได้ให้ทีม

ตัวอย่างผลที่เคยเจอจริง (จากการทดสอบใน session นี้)

ตัวอย่าง
gdrive resource ตัวอย่าง:
- gdrive:///11oU31ECPqWilxLrbA8yzbU02sSgEU6AI (folk_project_catcare)
- gdrive:///1OJwb1csvqpZzuOjTwpTT-TB8kJb26yrvRwc9KiStw2g (Track MEX leave approve flow)

deepwiki ตัวอย่าง:
- facebook/react: อ่านโครงสร้างเอกสารได้

brave-search ตัวอย่าง:
- web_search: ใช้ได้
- local_search: rate limit exceeded (ต้องรอ/ลดความถี่)

Pseudo-calls (มองเป็นท่อเดียวกัน)

1) gdrive: ค้นหาไฟล์งาน
   search("MEX leave approve flow")
   -> ได้ไฟล์ spreadsheet ที่เกี่ยวข้อง + URI

2) memory: จำว่าไฟล์/โฟลเดอร์ไหนคือแหล่งข้อมูลหลัก
   remember({ key: "leave_flow_sheet", value: "gdrive:///..." })

3) brave-search: หา best practice/อ้างอิงภายนอก (ถ้าจำเป็น)
   web_search("dingtalk approval flow best practices")

4) deepwiki: ถ้าต้องอ่านโครงสร้าง repo library หรือ framework
   ask_question(repo="...")

5) สรุปผลให้ทีม/ทำ action ต่อ (เช่น สร้าง PR, ปรับ flow, ทำ checklist)

ข้อควรระวังเวลาใช้หลาย MCP ร่วมกัน

การจัดการสิทธิ์/ข้อมูล

  • อย่าเอาข้อมูลลับ (token/keys/ข้อมูลส่วนบุคคล) ไปค้นเว็บ
  • gdrive เห็นได้เท่ากับสิทธิ์ของ account ที่ auth
  • memory ควรเก็บเฉพาะ rule/ความรู้ที่จำเป็นและไม่ sensitive

ความเสถียร/ข้อจำกัด

  • brave-search อาจโดน rate limit: ลดความถี่, แคชผล, ใช้ web_search แทน local_search
  • query ของ gdrive ควรใช้แบบ search box (เช่น type:folder) ถ้าแบบ API ไม่ติด
  • deepwiki เป็นเอกสาร repo ไม่ใช่ runtime state ของระบบ