FullStack Developer

Roles & Responsibilities
  • Front-end experience such as HTML5, CSS3, Bootstrap, Vue, Nuxt, etc.
  • Develop API (Node.js or PHP) to meet both functional and non-functional requirements--including, but not limited to, quality, security, and performance within the committed time frame.
  • Designs, modify and supports all product-related technology and functionality, including software 
  • Produce appropriate documentation such as design discussion papers, coding comments, key decision register, and user documentation.
  • Provides guidance and assistance to the team in any aspect of program design, creation, unit testing, and documentation.
  • Collaborate with PO/PM and Quality Assurance (QA) to help in the definition of user stories, acceptance criteria, and test cases.
  • Writes unit tests and other forms of automated tests
 Basic Qualifications
  • At least Bachelor’s degree or higher in Computer Science, Engineering, Information Technology, or any related field
  • Understanding differences between multiple delivery platforms (such as mobile vs, desktop), and optimizing output to match the specific platform
  • Experienced in one or more of the following programming languages PHP, JavaScript (Node.js, Vue.js & Vuex)
  • Professional experience in Web technology (HTML, JavaScript, CSS, jQuery, BootStrap)
  • Experience development full-stack technologies 4-5years.
  • Experience in e-Commerce, experience in developing on marketplace platforms is highly preferred
  • Experienced in one or more database software such as MySQL, PostgreSQL, Elastic Search
  • Good knowledge of Git, relational databases, version control tools, and web services
  • Willing to learn, research, and adapt to new technologies
Preferred Qualifications
  • Through the understanding of the Software Development Lifecycle (e.g. Requirements, Design, Development, Testing) and exposure to Agile
  • Good communication skills (good command of English will be an advantage!)
  • Strong interpersonal skills and time management skills
  • Familiar with JIRA, Confluence
Apply Now

Other available positions

Senior Backend Developer

Roles & Responsibilities
  • Develop API to meet both functional and non-functional requirements--including, but not limited to, quality, security, and performance within a committed time frame.
  • Work closely with scrum masters and product owners to understand business goals and system requirements.
  • Analyze and provide suggestions to identify and improve backend performance and usability. Focus on building scalable backend solutions is a mandate.
  • Perform quality assurance in application testing, such as system, unit, regression, load, automated, and acceptance testingEstimate level of effort, evaluate new options of similar technology, and offer suggestions to improve processes provides recommendations for application and system improvementsใ
  • Participate in and manage professional quality system and application testing processes including web and native applications. The ability to execute complex multi-device testing scripts is required.
  • Design and execute scalability testing processes with both internal and vendor resources.
  • Ability to participate in the creation of test scripts and protocols
  • Provide weekly, monthly, quarterly, and annual status reports suitable for inclusion in divisional status & review meetings
  • Communicate constantly with product owners to understand and measure business requirements and the values of developed features.
  • Contribute ideas (technological and product) to enhance the overall service experience.
Required Skills and Qualifications
  • 3-5 years of experience in backend
  • Bachelor’s or Master’s Degree in Computer Engineering, Computer Sciences, Information System, or related fields.
  • Strong experience in Database design and performance tuning.
  • Strong experience in AWS cloud service platform.
  • Strong experience in backend technologies including PHP and Node.js
  • Strong knowledge of developing with MVC framework and OOP.
  • Fast Learner, Leadership, Communication, Analytical Thinking, and Service Minded
  • Good Attitude and able to work as part of a team.
Apply Now

Other available positions

Git flow FoodStory

เค้าวางโครงสร้างกันยังไงนะ

Story by nattapadtanasak kongpetsak

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

ก่อนจะเข้าเรื่อง Git flow ที่นี่ เรามาดูกันก่อนว่า Branch Model & Branch Strategy ทั้งหมดของที่นี่นั้น มีอะไรบ้าง

Master

  • คอยระบุสิ่งของที่ขึ้น production ไปแล้ว
  • จะ relate กับ release branch เป็นหลัก ยอมรับการ merge จาก release branch เท่านั้น
  • ของที่จะนำขึ้น production จะใช้ branch นี้ในการ deploy
  • เราสามารถมี pipelines สำหรับ branch นี้ในการนำขึ้น server production

Release

  • แหล่งพักรวมสิ่งของที่จะนำขึ้น production ใน version ถัดไป หรือ hotfix
  • รวบรวมสิ่งของที่การันตีว่า test ผ่านแล้ว

Hotfix

  • แตกมาจากจุดที่ level เดียวกับ master
  • ไว้แก้ไขงานประเภทเร่งด่วนและต้องการนำงานขึ้นทันทีวันนั้น
  • งานประเภทนี้ควรนำเข้า staging branch ด้วย เพื่อผ่านการ test

Staging

  • เราสามารถเรียกอีกชื่อนึงคือ test branch แหล่งรวบรวบสิ่งของที่ต้องการส่งเทส
  • ของทุกอย่างที่อยู่ใน staging ควรผ่านการ merge จาก pull request
  • ของที่นำขึ้น server staging (test) จะใช้ branch นี้ในการ deploy
  • เราสามารถมี pipelines สำหรับ branch นี้ในการนำขึ้น server sandbox

Develop

  • เราสามารถเรียกอีกชื่อนึงคือ dev branch จุดกำเนินของการเริ่มต้นการแตก branch เพื่อทำงาน
  • develop branch ควรอยู่ level เดียวกับ master & release เสมอ ทุกครั้งที่ master ถูก deploy
  • ใช้ในการสื่อสารว่าทุกคนที่ทำงานในโปรเจคนี้ร่วมกัน ควรจะเริ่มต้น dev จากจุดไหน

Feature

  • branch ที่แตกออกมาจากจุด develop เท่านั้น
  • ไว้เพื่อระบุถึง feature ใหม่หรืองานที่ต้องไปเพิ่มเติมของจากระบบเดิม
  • เป็น branch ที่ต้องเปิด Pull Request ทุกครั้ง

Bugfix

  • branch ที่แตกออกมาจากจุด develop เท่านั้น
  • ไว้แก้ไขงานประเภท bug ของระบบ
  • เป็น branch ที่ต้องเปิด Pull Request ทุกครั้ง

ทีนี้เรามาดูกันว่า Flow ของที่นี่เค้าวางการทำงานกันไว้ยังไงนะ

อธิบายภาพจากล่างขึ้นบน

1. ทุกๆ main branch ควรถูกแตกออกมาจาก master branch ใน level เดียวกันก่อนได้แก่ release, staging & develop

2. เริ่มต้นทำงานที่ develop branch ทุกครั้งและควรจะแตกออกมาเป็น feature หรือ bugfix ขึ้นอยู่กับงานที่ถือ

หาก feature หรือ bugfix มีการ commit มากกว่า 1 แนะนำให้รวม commit ด้วยการ git rebase -i เพื่อกำจัด commit ที่เป็นขยะ

3. เมื่อดำเนินการทำ feature หรือ bugfix ใดเสร็จแล้ว ดำเนินการ push origin ขึ้นไปยัง Bitbucket เพื่อทำการขอ Pull Request ต่อไป

4. ในกรณีผู้ Review กด Approve แล้วกด merge ให้ Source Code จะถูก merge เข้า staging branch ให้ด้วยการ git merge — squash

** merge — squash คือการนำ source code จาก commit ต้นจนถึงปลายทางมายัดลง branch ที่ต้องการจะ to merge โดยที่เส้นจะไม่ผสานเข้าหากัน

5. เมื่อของถูกนำเข้า staging branch ทุกครั้ง ให้ดำเนินการ deploy ได้ทันที เพื่อส่งเทสกับทีม QA บน Server Sandbox

6. เมื่อ feature/bugfix ไหนพร้อมขึ้นแล้ว ดำเนินการนำเข้าสู่ release branch ได้เลยด้วยการ git merge — no-ff หากมีหลาย feature/bugfix branch ที่จะ release อย่าลืมทำการอัพเดทของ feature/bugfix ตามด้วยการ git rebase release ทุกครั้งก่อนจะ merge

7. ดำเนินการ Tag Version แล้วเข้าสู่กระบวนการ Deploy ขึ้น Production ต่อไป ด้วยการอัพเดท master branch ให้เทียบเท่ากับ release branch โดยการ git rebase release จึงจะสามารถดำเนินการ Deploy งานจาก master branch ได้

8. เมื่อใดก็ตามที่ master branch มีการอัพเดทของแล้วนำขึ้น server production แล้ว ให้ทุก branch ที่อยู่ level ต่ำกว่า master branch ทำการอัพเดทความสามารถตาม master branch ทันที ด้วยการใช้คำสั่ง git rebase master ทั้ง staging, develop, feature, bugfix

9. ในกรณี hotfix คุณสามารถแตก branch จาก level เดียวกับ master branch ได้เลย หากดำเนินการแก้ไขเสร็จสามารถเปิด pull request เพื่อร้องขอ merge เข้า staging ในการส่งเทส แล้วถ้าเทสผ่านดำเนินการ merge — no-ff เข้า master branch ได้ทันที หลังจากนั้นทุก branch จะต้องอัพเดทของตาม master branch ด้วย

ข้อดีที่เจอใน Flow นี้

  • สามารถแบ่งแยกงานที่ตัวเองทำได้ชัดเจนจาก feature | bugfix
  • สามารถแยก feature | bugfix ที่ยังไม่ได้ release ได้ชัดเจน
  • สามารถตรวจสอบ conflict ระหว่างทางของ feature | bugfix ได้ กันการแก้ไข code ซ้อนกัน
  • ช่วง release งาน สามารถระบุงานที่จะต้องขึ้นได้ง่าย รวมถึงระบุงานที่ยังไม่ release ได้ง่าย
  • ไม่เกิด commit ขยะเกินไป
  • ux / ui ดี เพราะไม่เกิดเส้น git แบบขนานกันหลายเส้น

ข้อเสีย

  • ระบุ conflict ที่เกิดขึ้น ว่ามาจาก branch กับ branch ไหนได้ยาก
  • ใช้คำสั่ง git ค่อนข้างเยอะ learning curve ค่อนข้างสูง

ขอจบด้วยการอธิบายภาพการใช้งานจริงที่ผ่านมานะครับ

ทั้งนี้เราหวังว่าบทความนี้จะเป็นประโยชน์กับทุกคนที่เข้ามาอ่านกันนะครับ
ขอบคุณที่อ่านกันถึงตอนจบครับ 🙂

Continuous Delivery

Story by Tae Khunsong

หลายๆคนมักจะคิดว่าการทำ Application หรือ Software สักตัวหนึ่งขึ้นมาเพื่อนำเสนอ Product ของเรา และใน Application/Software นั้นๆ จะต้องมี Feature ต่างๆ มากมาย เพื่อให้ Application/Software ดูสมบูรณ์แบบมากขึ้น ซึ่งก็ไม่ใช่เป็นความคิดที่ผิดแต่อย่างใด

ต่อมาเมื่อพูดถึงการสร้างและพัฒนา Application/Software เหล่านั้นให้เกิดขึ้นจริง เรานั้นมักมีความคิดในแง่ดีมากไปในการ Estimation ของโปรเจคนั้นๆ บางครั้งประเมินไว้มากกว่าเวลาจริง บางทีก็ประเมินซะงานไม่เหลือคุณภาพในการส่งมอบ ตัดเวลา Develop ลดเวลา Test เพื่อให้งานนั้นออกมาในแบบที่ Business หรือ Product ต้องการในความสมบูรณ์แบบมากเกินไป (ในแง่ของจำนวน Features หรือ Flow ที่ทาง Business นั้นต้องการ)

ในส่วนตัวผมนั้น ชอบจะแบ่งการ Release Application/Software ให้ออกเป็นส่วนๆและหลายๆ Version เพื่อเป็นการไม่เอา Cost ของเวลางานและเงินลงทุนไปเสี่ยง

ในการส่งมอบงานใหญ่น้อยครั้ง วิธีการลดความเสี่ยงและทำให้ Project เหล่านั้นมีคุณภาพคือ การทยอยส่งมอบงานออกไป ทีละน้อยชิ้นและทยอยส่งออกอย่างต่อเนื่อง ที่สำคัญการส่งมอบงานและออกแบบงั้นนั้นในช่วงแรกควรจะทำให้ใช้งานและง่ายต่อการเข้าถึง ถ้าเปิดมาใน Application/Software มี UI มากมาย รับรองว่าเป็นเหตุผลหนึ่งทำให้ User รู้สึกใช้งานยาก อีกประการหนึ่งควรจะ Tracking Events เผื่อนำมาประเมินว่า Menu/Features ไหนควรจะได้ไปต่อ เมนูไหนให้หยุดซะเดี๋ยวนั้น ซึ่งเป็นการประหยัด Cost ของเวลาเมื่อสร้าง Feature ออกมาแล้วมีคนใช้มันน้อยมากหรือแทบจะไม่มีเลย

Lean Development

ตัวอย่างเช่นหากคุณตั้งใจทำ product สักตัว วาแผนจะให้มี Feature สัก 20 features ดังนั้นคุณไม่จำเป็นต้องทำทั้ง 20 ตัวให้เสร็จ มันมีข้อเสียงที่ product ของคุณอาจจะไม่จำเป็นต้องใช้ทั้ง 20 features ก็ได้ แต่สิ่งที่เราต้องคำนึงถึงคือ การปล่อยตัว Lean software management ออกไปก่อน อาจจะใช้ 5–10 features ก็ได้ มองการใช้งาน End to end เป็นอันดับแรก จากนั้นสิ่งมี่ต้องทำคือ การเอา 10 features ที่ released ไปมาวิเคราะห์และพัฒนาต่อยอด ใน phase 2 อาจจะไม่ใช่การพัฒนาต่อ 10 features ที่เหลือแต่เป็นการนำบาง features ใน 10 features released มา improvement และ หา insight หรือ source บางอย่างมาพัฒนาบาง features ใน 10 features ที่ยังไม่ได้ทำ

Software Quality

ที่สำคัญไปกว่านั้น Continuous Improvement ช่วยให้ทีม Product, Developer และ QA มีความมั่นใจในการสร้าง Quality ของผลงาน ทีมที่ทำ Quality สามารถตัด effort ที่จะต้องเทสไปเยอะและจำกัดการเทสอยู่ในวงแคบ ทั้ง Unit Test, API Test, Functional Testing, Regression Test, และที่สำคัญการทำ Automation Testing Scripts สามารถ build ได้ง่ายและรวดเร็วกว่าการทำเต็มรูปแบบทั้ง 20 featuresและ ฝ่ายวิเคราะห์สามารถนำไปต่อยอดได้อย่างต่อเนื่อง

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