Fanboi Channel

Database กับ datastructure ต่างกันตรงไหนวะ

กูผู้ชายนะ ไม่รู้ว่ากูคิดมากไปป่าว
แต่กูไม่ชอบ meme ที่เอารูปผู้หญิงที่เขียนโปรแกรมประมวลผลรูปหลุมดำ มาตัดต่อล้อว่าเค้าเขียนโปรแกรม hello world อะไรพวกนี้เลยว่ะ
มันยิ่งเป็นการโชว์ว่าวงการนี้แม่ง sexist อย่างที่คนเค้าด่ากันจริงๆ

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

>>914 ขก ทำงานนะ บางทีกุก็มีอารมณ์หมดแรง ทำงานไปวันๆเหมือนกัน

>>914 กูยังไม่ได้ทำงานว่ะ แต่มีอารมณ์แบบนี้ตอนทำงานโปรเจค ชอบทำเป็นงานอดิเรกมากกว่า

จบใหม่ควรเรียกเท่าไหร่วะ

ทุกวันนี้พวกมึงใช้ ภาษา / framework อะไรทำงานกันบ้างวะทุกคน

>>918 Java + Spring Framework เป็นงานหลัก นานๆทีมีต้องแก้หน้าบ้านก็ JS + JQuery แต่เป็นแค่ส่วน CMS ง่อยๆที่ใช้กันเองภายใน

ปกติพวกมึงรับ requirement ผ่าน SA กันป่ะ หรือรับจาก business แล้ว design เอง

เด็กจบใหม่จะหางาน python ได้ป่ะวะ กุยื่นไปกี่ที่ๆบอกว่ารับ java dev

>>921 หายากมาก จะเจอก็ไปซะชานเมืองหรือ ตจว. จ๋าๆไปเลย มึงต้องไปต่างประเทศเท่านั้นอ่ะถ้าจะหากินด้วยpython ไม่งั้นก็ pantip.com หวังว่าจะยังเปิดรับ บ้านเรายังดักดานกับแค่จาวาอยู่เพราะคอมมูนิตี้ในไทยใหญ่สุด มีตั้งแต่ฉลาดเป็นกรดกับไร้ปริญญาเหมือนSIRNมาทำงานในวงการนี้

>>922 กุว่าที่คอมมูนมันใหญ่เพราะบอสัดใช้เยอะด้วยว่ะ มึงไปดูโปรเจคเก่าๆที่เมนเทนกันมานานส่วนมากก็จาวา ละในเมื่อมันใช้ได้อยู่ บอสัดจะเปลี่ยนทำไมว่ะ

>>921 หาที่ทำ ai อะ จะได้ใช้ python

>>921 น้อย แต่มี กูเคยเห็นอยู่

>>923 เออ อันนี้ก็จริงส่วนนึง

>>923 อย่าว่าแต่ java เลย ทุกวันนี้ cobol แม่งก็ยังอยู่

>>927 แต่cobolดีหน่อยตรงที่คนแก่ๆแล้วทำงานกันซะมาก ไม่มีแรงเบียวหรือชุดความคิดวิปริตประหลาดๆแบบพวกjava แต่ถึงงั้นจะให้ไปทำงานภาษาcobolกูว่าคงไม่มีใครไปทำอ่ะ ขนาดป้ายรับสมัครงานทุกวันนี้ยังมีแต่พวกframeworkรัวๆเลย

ตอนนี้กุ outsource .net ปสก1 ปีครึ่ง ณ ตอนนั้น เงิน 35k + ค่านุ้นนี่นั่น = 38k
ตอนนี้ ปสก 2 ปีครึ่ง พวกมึงว่ากุจะเรียก 50k ได้ป่าววะ หรือถ้าที่เดิมไม่ให้ตามต้องการ ไปหาที่ใหม่มึงว่า โอกาสหายากง่ายแค่ไหน

ประสบการณ์จำนวณปี <> งานที่ทำได้

>>929 ก็ลองไปสัมดูดิ ได้อยู่ละ

ยังมองไม่ออกเลยว่า LibraBFT จะสเกลเพื่อรับ Transaction per second (tps) เพิ่มได้ยังไง #GeekAlert #ไม่ใช้ภาษามนุษย์นะโพสต์นี้ #เตือนละนะ
.
LibraBFT ถึงจะเป็น Consensus Protocol กลุ่ม BFT ที่พัฒนาขึ้นมาจากตัวแรก ๆ เยอะมาก แต่ก็ยังไม่ใช่ Perfect Solution อยู่ดี (อย่างน้อยก็ใน Approach ปัจจุบัน)
.
BFT ตัวที่โบราณหน่อยแต่ดังก็คือ PBFT (Practical Byzantine Fault Tolerance) เพราะมันง่ายสุด คือให้ทุก Validator คุยกันเลย ทำให้มีข้อความที่ต้องส่งถึงกันถึง n^2 ถึง n^4 แล้วแต่จะออกแบบ (n คือจำนวน Validator) สุดท้าย Big O เลยล่อไป O(n^3) โดยเฉลี่ย ทำให้เวลามี Validator เยอะ ๆ มันเลยอืดลงเรื่อย ๆ ไม่สามารถสเกลได้
.
ในคำว่า Scalability ของโลก Blockchain ไม่เหมือนกับ Scalability ในโลกของ Centralized Server ปกติเท่าไหร่ คือพวก Centralized Server เนี่ยยิ่งเพิ่มเครื่องจะยิ่งรับ Concurrency ได้มากขึ้น แต่สำหรับ Decentralized เนี่ย มันจะยิ่งหน่วงลงเรื่อย ๆ เพราะเครื่องต้องสื่อสารกันมากขึ้น*
.
(*แล้วแต่ออกแบบ แต่ส่วนใหญ่เป็นแบบนั้น หรือถ้าไม่ใช่ก็จะแลกมาด้วยอะไรบางอย่างเสมอ)
.
BFT ก็พัฒนามาเรื่อย ๆ เพื่อลด Big O ลง อย่าง Tendermint ก็ BFT ที่ O(n^2) และล่าสุด vmware ก็นำเสนอ BFT ที่ประสิทธิภาพดีที่สุดอย่าง Hot-Stuff ออกมา Big O อยู่ที่ O(n) เท่านั้น แปลว่าการเพิ่มเครื่องไม่ได้ทำให้หน่วงขึ้นมากเหมือนอันเก่า ๆ ทุกอย่างเป็น Linear
.
เบื้องหลังของ Hot-Stuff คือเป็น BFT แบบ "Leader-based" ก็คือแทนที่จะใช้วิธีคุยกันด้วยทุก Validator แบบ PBFT ก็เปลี่ยนเป็นให้ทุก Validator มาคุยกับ Leader ซึ่งมีตัวเดียวแทน ข้อความเลยส่งกันด้วย O(n) เท่านั้น
.
และความหมายใน Paper ที่บอกว่า LibraBFT สเกลได้ก็คือ "สเกลจำนวน Validator ได้" ไม่ได้แปลว่าจะเพิ่มจำนวน Transaction per second ได้แต่อย่างใด
.
และพอมองไปยาว ๆ ก็ยังไม่เห็นว่าการโตของจำนวน Validator จะทำให้ระบบมันทำงานได้เยอะขึ้นเลย มีแต่จะช้าลง ๆ ตะหาก
.
ข้อได้เปรียบของ LibraBFT (Hot-Stuff) คือ คิดว่าน่าจะรับได้หลายพัน tps ตั้งแต่แรกแหละ แค่เค้าลิมิตไว้ที่ 1,000 tps ก่อนด้วยเหตุผลหลายประการ แต่สุดท้ายถ้าปลดล็อคมันก็จะมีเพดานของมันอยู่ดี
.
และสเปคเครื่องที่จะรัน Validator Node ได้ก็ถือว่าโหดเหมือนกัน เพราะยิ่งต้องรับ tps ได้มากขึ้น พวก CPU, RAM ก็จะต้องยิ่งสูงขึ้นเร็วขึ้น Harddisk ก็จะยิ่งบวมเร็วขึ้น แปลว่าค่า Maintainance ของ Validator Node ก็จะสูงขึ้นเรื่อย ๆ ด้วย ไม่รู้จะถึงจุดที่คนรู้สึกเสียใจที่ตั้ง Validator Node มั้ย
.
เท่าที่พิจารณาดู ช่องทางที่เหมาะสมกับการสเกล tps ก็มีอยู่สอง Approach คือ
.
1) Sharding
.
2) Off-chain Solution
.
ซึ่งก็ยังไม่มีข้อมูลจากฝั่งไหนเลยว่าจะทำมั้ย แต่ก็มีโอกาสที่ Calibra จะทำ ในกรณีนั้นก็จะไม่มีปัญหาเรื่องสเกลละ ตัว Libra ก็คงให้อยู่ 1000 tps ต่อไปได้อีกนาน
.
ไว้รอดูกันต่อไปจ่ะ

เรื่อง MVC ต่อจากเมื่อวานหน่อย .... เห็นมีคนแชร์กันเยอะ

ลองมองว่า MVC ไม่ใช่ Design Pattern และไม่ใช่แค่ Architecture Pattern สำหรับอะไรอย่างใดอย่างหนึ่งโดยเฉพาะ

MVC มันเป็น "ปรัชญา" สำหรับ Separation of Concern

1. M = ตัวตนของสิ่งที่ "มัน" เป็น
2. V = ภาพที่ "มัน" ถูกมองเห็น ถูกใช้งาน
3. C = ตัวกลางระหว่าง M, V

สิ่งที่เรามองเห็น อาจจะไม่ใช่สิ่งที่มันเป็น .... สิ่งที่มันเป็นอาจจะไม่ใช่สิ่งที่เราใช้และต้องการ .... เราต้องแยกปัจจัยพวกนี้ให้ได้ ไม่ใช่ไปยึดติด

ถ้า M ยึดติดกับ V ก็ไม่ดี ... ถ้า V ยึดติดกับ M ก็ไม่ดี .... ก็ต้องแยกสองอย่างนี้ออกจาก ...

ทางเดียวที่ทำได้ ก็ต้องมี C มาเป็นตัวกลาง .....

อย่าไปยึดติดอะไรกับมันมากนัก ปรัชญาของมันทำให้เรางอก "MVC ภายใน MVC" ได้อีกเยอะแยะมากมาย

เอาหลักการนี้ไปจับกับอะไรก็ได้ทั้งนั้นแหละ ..... ลองดูนะ .... เช่น

1. ถ้าเราถือว่าข้อมูลใน DB เป็น "ตัวตน" และ Entity/Model ใน Application เป็นสิ่งที่มันถูกมองเห็น ถูกนำไปใช้ เราก็ใช้ SQL Query (และอาจจะ + ORM) เป็นตัวกลาง ..... เราก็จะไม่ยัด SQL ไปใน Entity/Model เพราะมันคือ View ของ Data ใน DB ... เราก็เขียน Persist layer มาจัดการ

2. ถ้าเราถือว่า Object ใน Application ของเราเป็น "ตัวตน" และ JSON ที่ถูกพ่นออกไปเป็นสิ่งที่มันถูกนำไปใช้ เราก็สร้าง JSON Presenter สำหรับมันในบริบทต่างๆ เป็น View และใช้ตัวกลางอะไรสักอย่างมา Map ไป

อะไรแบบนี้เป็นต้น

MVC มันห่วย ถ้าเรามองมันเป็นแค่ Fixed Architectural Implementation ในบริบทใดบริบทหนึ่ง และมันห่วยเสมอเมื่อบริบทมันไม่ใช่บริบทเดียวกับที่มันถูก Implement มา .....

แต่หลาย Architecture ที่เกิดขึ้น ที่คนบอกว่ามันเจ๋งมากมาย ต้องทำแบบนี้ถึงจะถูก ฯลฯ ก็คือการเอาความคิดแบบ MVC นี่แหละ ไป Refactor แต่ละ Layer ของ MVC .....

ที่เมื่อวานผมเขียน MVC ของ Enterprise มันอยู่ใน Presentation ของ 3-Tier แต่ MVC หลายตัวมันคือ 3-Tier ตรงๆ เลย .... มันก็อีแบบนี้แหละ .... พอ Presentation ของคุณมันใหญ่ มันก็ถูก Refactor ด้วยความคิดแบบ MVC .... แล้วเราก็เรียกมันว่า "MVC Architecture " .... จนกลายเป็นว่า MVC ของเรามันไม่เท่ากัน

ทั้งๆ ที่จริงๆ แล้วมันเป็นหลักการ เป็นปรัชญา .... และเป็น Recursive Pattern .... คือมันสามารถ apply ตัวมันเองลงไปใน layer ไหนก็ได้ของตัวเอง .... เพราะแต่ละ layer ของมัน เมื่อมันเริ่มโตขึ้น มันก็จะ self-similar แบบเดียวกับตัวมันเองน่ะแหละ .... นี่คือ Recursive pattern ชัดๆ .....

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

อีกครั้ง:

สิ่งที่เรามองเห็น อาจจะไม่ใช่สิ่งที่มันเป็น .... สิ่งที่มันเป็นอาจจะไม่ใช่สิ่งที่เราใช้และต้องการ .... เราต้องแยกปัจจัยพวกนี้ให้ได้ ไม่ใช่ไปยึดติด

ถ้า M ยึดติดกับ V ก็ไม่ดี ... ถ้า V ยึดติดกับ M ก็ไม่ดี .... ก็ต้องแยกสองอย่างนี้ออกจาก ...

อย่าไปยึดติดอะไรกับมันนักเลย ลองมองให้ลึกกว่าเปลือกที่แต่ละ Framework หรือแต่ละ Implementation บ้างก็ดี

ทุกวันนี้ Hacker มีเทคนิคที่สุดยอดมากกก
มากซะจนผมคิดว่า app และ web 50%
สามารถ hack ได้ในทางใดทางหนึ่ง
ส่วนหนึ่งน่าจะเป็นเพราะว่า
Developer ไม่รู้ว่าจะ Secure API อย่างไร
.
.
Security ของ API เป็นตัวชี้ชะตาของ app
ถ้า app ไม่ดังก็ไม่เท่าไหร่
แต่ถ้าเกิดดังขึ้นมา มีคนเล่นเยอะหน่อย
มันก็จะมีคนมาลองแฮ็คระบบ
ยิ่งถ้ามีของรางวัลล่อใจ ยิ่งลองของกันสนุกสนาน
ทำโปรแกรมเมอร์หมดอนาคตเลยนะบางที
.
.
โพสต์นี้จะสอนการออกแบบ security ของ API 6 ข้อ
ไม่ได้ strong ขนาด hack ไม่ได้ 100%
แต่ก็ไม่อ่อนขนาด ใครๆก็ hack ได้
และถ้า system ถูก hack ก็ต้องจำกัดความเสียหายได้
และเตือนไว้ก่อนเลยว่า post นี้ยาววววว
.
.
การออกแบบ API ให้คิดไว้เลยว่า โดนแน่ๆ
โดยเฉพาะ API ที่ใช้ร่วมกันระหว่าง mobile และ web app
ยิ่งต้องออกแบบอย่างเข้าใจธรรมชาติของ platform ที่ต่างกัน
.
.
เริ่มจากข้อ 1 สำคัญสุด ให้ใช้ https ทั้งหมดทุก request
เพื่อป้องกันคนเข้ามาแก้ข้อมูล request ระหว่างทาง
ถ้าเรียกมาเป็น http ให้ server reject request เลย
.
.
ข้อ 2 ใช้การ Authen ด้วย accessToken
การสร้าง accessToken ผมจะใช้ JWT ในการสร้าง
JWT = JSON Web Token
ถ้าสนใจ ผมแนะให้เพิ่ม shuffle key ซ้อนเข้าไปอีกชั้น
เพื่อทำให้ไม่สามารถดูข้อมูลใน JWT payload ได้ง่าย
เพราะ spec ของ JWT ใช้ base64encode
ซึ่งสามารถแกะห่อดูได้ง่ายเกิ๊นน
.
.
ใน accessToken ให้เก็บเฉพาะ UID อย่างเดียว
และ UID อย่าเอา ID ของ user มาใช้ตรงๆ
ให้ encrypt ID ให้กลายเป็น string ยาวๆก่อน
อย่าให้ hacker เดา UID คนอื่นได้
อ่านที่ผมเขียนดีๆ encrypt นะ ไม่ใช่ encode
เกิด hacker สามารถปลอม accessToken ได้
ก็ไม่รู้จะปลอมเป็นใครอยู่ดี
เพราะ UID มันเดาไม่ได้ ความน่าจะเป็นสูงเกิน
.
.
JWT จะยังเชื่อถือได้อยู่ถ้ายังไม่โดนโขมย secret key
เมื่อไหร่ก็ตามที่ key โดนโขมย
hacker จะปลอม token ได้ทันที
ให้คิดในแง่ร้ายที่สุดไว้ก่อนว่า มันอาจจะโดนโขมยได้
ต้องมี plan B เอาไว้จัดการเมื่อ key โดนโขมยไปแล้ว
.
.
ถ้า key JWT โดนโขมย จะต้องเปลี่ยน key ที่ฝั่ง server
สิ่งที่เกิดขึ้นคือ api ทั้งหมดจะส่งค่ากลับว่ายังไม่ได้ login
ทำให้ user ทุกคนถูก logout auto และต้อง login ใหม่หมด
.
.

ข้อ 3 การเรียก api จาก app จะต้องมี signature ส่งไปด้วย
signature = SHA256(
accessToken = (userId::clientId) = ใครทำ
endpoint = ทำอะไร
parameters = ทำอย่างไร
nonce = ทำเมื่อไหร่
appId = เรียกจาก app ไหน
==============================
secret = token ลับ
)
.
.
nonce คือเวลาปัจจุบันของ client
ซึ่งจะต้องส่งไปที่ server พร้อมกับ parameter อื่นๆ
ฝั่ง server ตรวจสอบ ถ้า current_time() - GMT(nonce) > 2 นาที
request จะถูก reject เพื่อกัน replay attack
.
.
secret มีประโยชน์ ถึงแม้จะใช้ https ก็ตาม
ถ้า hacker ดักเอา accessToken คนอื่นมาได้
ก็จะปลอมเป็นคนอื่นไม่ได้ถ้าไม่รู้ secret
.
secret จะไม่ส่งทาง network เด็ดขาด
จะฝังไว้ใน app เมื่อ compile แต่ละ version
ถ้า secret ถูกโขมยไปได้จะต้อง update app ใน store
โดย app version เดิมทั้งหมด จะใช้ไม่ได้
ก็ต้องยอม ก็ดันโดนโขมย secret นี่นา
เห็นมั้ยว่าต้องคิดในทางเลวร้ายที่สุดเผื่อไว้ด้วย
.
.
การเรียก api จาก mobile app จะมีข้อดีกว่า web
คือไม่สามารถปลอม request ได้เลย
ถึงแม้จะใช้ accessToken ของตัวเองในการยิง api
เนื่องจากไม่รู้ secret ที่ฝังไว้ใน app
.
.
อย่างไรก็ตาม server ห้ามเชื่อใน request โดยไม่ตรวจค่าอื่นๆ
เนื่องจาก web app สามารถยิง api ได้ด้วย accessToken
โดยไม่ต้องมี secret ลับ
เพราะ web app จะไม่มี secret และถึงอยากมี secret ก็มีไม่ได้
มีไปก็ถูก copy เอาไปใช้อยู่ดี เพราะใช้ javascript เปลือยๆ
.
.
ข้อ 4 เมื่อเรียก api จาก web app จะต้องใส่ accessToken ใน header
อย่าริอาจเอา accessToken ใส่ไว้ใน URL
เนื่องจาก accessToken มันก็คือรหัสผ่านดีๆนี่เอง
URL บางทีก็โดน history ไว้ใน browser
URL บางทีก็โดน copy ส่งให้เพื่อน
และทุกครั้ง URL ก็จะโดน log ไว้เป็น file ไว้ใน server
รอเวลา hacker แหกด่าน server เข้ามาเจอ log เข้าสักวัน
.
.
ข้อ 5 จะต้องมี CSRF_token ใน cookie
ซึ่งต้องถูก generate ใส่เอาไว้มาจากฝั่ง server
CSRF_token อันนี้สำคัญมาก ถ้าไม่มีนี่โจมตีง่าย
แต่ผลกระทบของ CSRF attack นี่รุนแรง
มีไว้เอามาใช้ทำอะไรไปดูที่ข้อ 6
.
.
ข้อ 6 การเรียก api จาก web app จะต้องมี signature ส่งไปด้วย
signature = SHA256(
accessToken = (userId::clientId) = ใครทำ
endpoint = ทำอะไร
parameters = ทำอย่างไร
nonce = ทำเมื่อไหร่
appId = web
================================
secret = CSRF_token
)
signature ต่างกับ mobile app ตรงที่ appId = web เสมอ
และ secret ก็คือ CSRF_token
เอาไว้กัน Cross Site Request Forgery
แปลเป็นไทยคือ web อื่นจะมายิง api ของเว็บเราไม่ได้
เพราะว่า web อื่นจะมองไม่เห็น cookie ของเว็บเรา
ดังนั้นถึงปลอม parameters ได้ แต่ก็ปลอม signature ไม่ได้
เพราะต้องใช้ CSRF_token ในการสร้าง
.
.
ยังมีอีกเยอะที่ต้องทำ แต่ 6 ข้อนี้เป็นจุดเริ่มต้นของทุกสิ่ง

สมัย ป. ตรี เรียน optimization theory ผมจำสมการทั้งหมดไม่ได้นะเยอะมากและเป็นวิชาที่ยาก ประกอบกับตอนนั้นติดเกม เข้าเรียนน้อย

แต่ takeaway ที่ใช้ได้จนทุกวันนี้คือ
1. เรา optimize (maximize, minimize) สอง variable พร้อมกันไม่ได้ ในโลกจริงผมพบว่าใช่ เพราะถ้าบอกว่าต้องปรับปรุงของสองอย่างพร้อมกันแล้วของสองอย่างมี correlation ระหว่างกัน หรือมี constraint ที่ใช้ร่วมกัน คนทำงานจะสับสนมาก แล้วพังไม่ได้อะไรเสมอ และมักเป็นสาเหตุของ office politic
2. เรา optimize ได้ก็ต่อเมื่อมี constraint บางอย่างกำกับเท่านั้น

โม่ง กูถามหน่อย ไอหนูเนยที่มันชอบเขียนblog ลงทำmediumนี่ืใช่ที่มันเคยเปิดคอร์สกั๊กๆเนื้อหาในudemyป้ะ?

>>937 ไม่รู้ว่าจะเรียกกั๊กดีไม้ คือมันมันทำได้แค่นั้น แต่เดิมอีนี่พื้นฐานการสอนมันสอนแบบโรงเรียนกวดวิชา ที่ต้องทำชั่วโมงให้คนเรียนรู้สึกคุ้ม ถ้ามึงไปเทียบคอร์สฝรั่ง แบบแงะ library โมโน่นโมนี่คงสู้ไม่ได้

>>937 หนูเนยสอนดีนะ ขอปกป้อง

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

ปกติ outsource .net หมดสัญญาต่อใหม่ อัพเงินกันเท่าไหร่วะ ที่เก่ากุบอกว่า จะเพิ่มให้ไม่ถึง 10,000 เดี๋ยวจะบอกว่าเท่าไหร่งี้อ่ะ
ปล. เงินกุยังไม่ถึง 40k

ไอ้ เควนทิน เบ็ค (Mystertio) ที่ทำตัวเป็นคนดีตอนแรกๆ แม่งจริงๆแล้วเป็นตัวโกง อดีตลูกน้องโทนี่

ตอนมันตาย แม่งยังเฉลยออกทีวี อีกว่า สไปเดอร์แมน คือ Peter Parker โคตรเหี้ย

แถมนิค ฟิวรี่ ในเรื่อง ดันเป็น ทาลอส (สครัล ในเรื่องกัปตันมาร์เวล) ปลอมตัวมา ไม่ใช่นิคจริงๆ อึ้งสัสๆ โคตรเนียน

เพื่อนๆโม่งต้องไปดู Spiderman Far From Home ให้ได้นะครับ

>>942 มึงจะสปอยทำแมวไร ดีนะกุไปดูมาแล้ว แม่ง 555555

>>939 แต่หนูเนยมันกากนะ

หนูเนยคือคนที่แม่งเคยอวยคริปโตชิบหายหลอกคนไปลงทุนตอนนี้เจ๊งไปละ กากสัสๆ

>>945 กูก็ไม่ได้ชอบหนูเนยนะ แต่มันพูดตลอดว่าของพวกนี้มีความเสี่ยงสูง ไม่เคยเห็นมันพูดออกสื่อชวนใครมาซื้อเลย

>>946 เขียน blog เป็นเรื่องเป็นราวยาวแสรดเหรียนที่มันมีเอี่ยวเป็นที่ปรึกษา แล้วมีเขียนแปะไว้ท้ายนิดนึงว่าความเสี่ยงสูงเนี่ยนะ

อาจารย์เดฟจะเปิดสอนคลาส Math for programmer แล้วนะ ตั้งหน้าตั้งตากดกันให้ดีครับ

>>948 ใครวะ...

>>949 Dave Rawitat Pulam

>>948 กุโง่คณิตอยู่เลย แปลกใจมาเป็นโปรแกรมเมอร์ได้ไงวะ 5555

มึงเคยได้ยินลูกค้าพูดเรื่องเงินเดือนเราในออฟฟิศกันไหม กุนึกว่าเค้าจะไม่รุ้เงินเดือนกุละ กุเป็น contract จะออก
แล้วกุเรียกบริษัท head ไป ลูกค้ากุที่ on site นั่งคุยกับแผนกอื่นแบบเบาๆ แล้วบอกว่า เนี่ย กุจะออกแล้วหมดสัญญา แผนกอื่นก็ถาม เงินเดือนเท่าไหร่ ปรากฏว่าลูกค้า onsite กูรุ้เว้ย ว่ากุเงินเท่าไหร่ เค้าก็คุยกันไปเบาๆ กุก้แกล้งไม่ได้ยินเพราะคุยกับอีกคนอยู่ แล้วเค้าก็ถามกันว่ากุขอขึ้นเงินเท่าไหร่ ปรากฏอีกว่า รุ้เรทเงินกุด้วยว่ากุขอขึ้นเท่าไหร่(ตอนกุขอขึ้นกุไปขอกับ head นะ ไม่ใช้บริษัทลูกค้า) ประเด็นคือพูดกลางที่ทำงาน ใครอยุ่ตรงนั้นแม้มรู้หมด 55555

>>952 ส่วนมากก็รู้นะ ของกุเวลาจ้าง contract ก็รู้ว่าจ้างเท่าไร บัดเจ็ดมันมาเท่าไหน อีกฝั่งเรียกเท่าไร ถึงบอกว่าจ่ายหัวมึง แต่หัวมึงก็บอกว่าค่าตัวมึงเท่าไรอยู่ดี แต่ที่ไม่ควรคือเอาไปพูดกับคนอื่น แค่นี้แหละ

>>951 โปรแกรมเมอร์ทั่วๆไปถ้าไม่ได้ทำงานเฉพาะทางบางด้านกูว่าก็ไม่ได้ต้องเก่งคณิตนะ
คณิตบางเรื่องที่แฝงมากับการเขียนโปรแกรมพื้นฐานมันก็ถูกใช้งานในอีกรูปแบบนึง

>>952 กูไม่เคยโดนเอง แต่เคยได้ยินลูกค้ากระซิบคุยกันเรื่องนี้ของคนอื่นในทีม เค้าคงเห็นกูใส่หูฟังอยู่เลคิดว่ากูไม่ได้ยินมั้ง
ประมาณว่าคนนี้ทำงานมาหลายเดือนแล้ว ปสก. หลายปี บริษัทต้นสังกัดก็โม้ไว้เยอะ ค่าตัวไม่ถูก แต่ทำงานไม่ค่อยดี เค้าเลยคุยๆกันรื่องนี้
กูเข้าใจว่าเค้าไม่ได้เห็นเงินเดือนโดยตรงนะ เค้ารู้แค่ว่าค่าตัวที่บรษัทต้นสังกัดเก็บเงินเท่าไหร่ จะให้เงินเดือนพนักงานเท่าไหร่ก็อีกเรื่อง

ถ้าเก่งชีวะน่ะรุ่งทุกคน

>>955 เกี่ยวไรกับชีวะว่ะ ไปเป็นนักวิทยาศาสตรืเหรอ

>>956 เท่าี่รู้มา เด็กชีวะ เมืองนอกต้องฝึกเขียนโปรแกรมกันเยอะมาก

เดี๋ยวนี้อะไรๆ แม่งก็ big data ไงมึง
data จากงานวิจัยทางชีวะมันก็ใหญ่ขึ้น การจัดการ/วิเคราะห์ ต้องปรับตาม
ถ้าไม่เอาเด็กชีวะมาเรียนคอม ก็เอาเด็กคอมมาเรียนชีวะ ซักอย่างล่ะวะ

เพื่อนกูไปทำทาง neuroscience ช่วยแพทยสมองทำวิจัย
เงินเดือน 350 k ละ

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

>>961 เงินไม่ใช่ประเด็นนะ ควรพิจารณาตัวเองก่อนว่าเป็นอย่างที่เขาบอกจริงไหมแล้วปรับปรุงตัวซะ เห็นหลายคนละหัวไม่ได้แต่มาเขียนโปรแกรม แทนที่งานจะไวขึ้นก็กลายเป็นตัวถ่วงทีม แถมทำให้งานช้าลงอีก

นั่งอ่าน FB feed พบว่าคนในสังคมรอบตัวผมส่วนมาก เข้าว่า การ Coding โดยไม่ใช้คอมพิวเตอร์นั้นเป็นอย่างไร ดีอย่างไร และดีกว่าการสอน Coding โดยเริ่มจากการ "เขียนโค้ดในคอมพิวเตอร์" อย่างไร

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

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

แต่จริงๆ แล้วไม่ใช่เลย

พวกนี้เข้าใจว่า Coding คือ Algorithmic Problem Solving ... และการเริ่มที่การเขียนโค้ดในคอมพิวเตอร์ นี่อาจจะเป็นอุปสรรคเสียด้วยซ้ำ ....

ในมหาวิทยาลัย วิชาสำคัญอย่าง Data Structures, Algorithms หรือวิชาอย่าง Problem Complexity Analysis ตลอดไปจน Theory of Computation นั้นไม่ถูกให้ความสำคัญ ทั้งคนเปิดสอนและคนเรียน

คนสอน ถึงอยากจะเปิดสอนก็เปิดสอนไม่ค่อยได้ เพราะไม่ค่อยมีคนเรียนหรอก ... ถ้าเป็นวิชาบังคับก็รอดไป แต่ถ้าเป็นวิชาเลือกนี่ ..... ผมเคยเปิดนะ มีคนลง 3 คน ... ปีต่อๆ มาก็เปิดไม่ได้ ... เพื่อนผมบางคนที่เก่งระดับสากล จะเปิดวิขานี้ก็ยังไม่มึคนลงเลย

จะไปเปิดวิชาพวกนี้ไปทำไมกัน ไปเปิดวิชาพวกสอน Syntax ภาษาโปรแกรมดีกว่า .... เด็กลงเยอะดี คิดว่าเอาไปทำงานได้เลย

จริงๆ แล้วจะเรียนภาษาโปรแกรมอะไรมา จะรู้ library แค่ไหน แต่ถ้าเรื่อง Algorithmic Problem Solving อ่อนแอแล้วล่ะก็ ....​ สุดท้ายก็ทำได้แต่งานระดับพื้นๆ

มันเหมือนกับเรียนภาษาไทย แต่ไม่เคยเรียนเรื่องโครงสร้างของการแต่งวรรณกรรม มันเหมือนกับเรียนกดคีย์เปียโน แต่ไม่เคยเรียนดนตรี ..... อาจจะเรียนเล่นดนตรี แต่ไม่เคยเรียนศาสตร์ของดนตรี หรือการสื่อสารด้วยดนตรี

อาจจะอ่านหนังสือได้ อาจจะฟังเพลงได้ อาจจะเขียนหนังสือลอกหนังสือเล่มอื่นได้ อาจจะเล่นเพลงได้ .....

แต่แต่งวรรณกรรมล่ะ? แต่แต่งเพลงล่ะ?

แล้วคิดว่าจริงๆ แล้ว Value มันอยู่ตรงไหนได้บ้าง? ..... เขียนโค้ดโปรแกรมแบบเดิมๆ ตลอดไปแค่เปลี่ยนภาษา? .... แค่ Maintain โปรแกรมที่คนอื่น (ต่างชาติ) เขียนมาแล้วตลอดไป?

หรือว่าจะทำ Innovation ใหม่ๆ ได้เพราะว่าเราแก้ปัญหาเป็นระบบ?

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

เอาจริงๆ แล้วทุกวันนี้ ผม "Coding​ โดยไม่ใช้คอมพิวเตอร์" นะ .... ผมใช้กระดานกับชอล์ค กระดาษกับปากกา ...​ และผมไม่ได้เขียนโค้ดแบบเดียวกับที่ผมเขียนโปรแกรม แต่ผมเขียนโครงสร้างของปัญหา เขียนนิยามของปัญหาต่างๆ และกลไกในการแก้ปัญหาพวกนี้อย่างเป็นระบบ .... และถ้าเป็นไปได้ ผมจะพิสูจน์ correctness ของมัน และเงื่อนไขต่างๆ ของพวกมันเสมอ ...

ทีมงานผมต้องสื่อสารกับผมแบบนี้รู้เรื่อง ต้องอ่าน Mathematical Models และ Computational Structures ต่างๆ ออก

อีกครั้ง การโฟกัสไปที่ "การเขียนโปรแกรมในคอมพิวเตอร์" เป็นอุปสรรคกับการสร้างคนในวงการนี้ด้วยซ้ำไปครับ

อย่าเอาสองเรื่องนี้ไปเท่ากันเลยครับ

ขอบคุณเพื่อนๆ ทุกคนที่ช่วยกันชี้แจงคนละไม้คนละมือครับ

แถมภาพ น้องในทีม Product Owners ของผม กำลังอธิบายแบบจำลองของปัญหาบางอย่าง และการแก้ปัญหา ให้ทีมงานฟัง

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

อ่ะ กลับมาโลกความเป็นจริงกัน ......

ปัญหาของการเรียน Algorithmic Thinking หรือ Algorithmic Problem Solving ของบ้านเรา มันก็จะเป็นเรื่องเดียวกับการเรียนการสอนคณิตศาสตร์ครับ

คณิตศาสตร์ ..... กลายเป็นวิชาท่องสูตร วิชาคำนวน วิชาที่เราจะต้อง execute การคำนวนตามลำดับของการคำนวนอะไรบางอย่างโดยที่ไม่รู้ไม่เข้าใจว่าทำไมต้องคำนวนแบบนั้น .... กลายเป็นการท่องจำ execution sequence มากกว่าเข้าใจ logical chain of reason และการสร้างแบบจำลองทางคณิตศาสตร์

(แบบจำลองทางคณิตศาสตร์ นี่ฟังดูยาก แต่จริงๆ แล้วเราอยู่กับเรื่องพวกนี้มาตั้งแต่เริ่มเรียนนะครับ เริ่มจาก "จำนวนและตัวเลข" ครับ ... ตัวเลขมันคือ abstraction/model ของจำนวน .... ดังนั้นเราหาเหตุผลกับตัวเลข มันก็จะนำไปใช้กับจำนวนของสิ่งต่างๆ จริงๆ ได้)

เราไม่สนใจ Language of Mathematics เลย ...... เราไม่เคยรู้ว่ามันมีด้วยซ้ำ .....

เหมือนกับเรียนดนตรีด้วยการท่องจำตัวโน๊ตทั้งเพลง หรือเรียนดนตรีด้วยการฝึกแต่เทคนิคการเล่นเครื่องดนตรีต่างๆ โดยไม่เรียน "ความเป็นดนตรี" เลย .....

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

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

ผมได้แต่หวังอย่าให้การเรียน Algorithmic Problem Solving กลายเป็นการท่องจำวิธีการแก้ปัญหา กลายเป็นการท่องจำ Sequence of Instructions ตายตัว โดยไม่เข้าใจแบบจำลองของปัญหาต่างๆ ... ไม่ว่าจะใช้หรือไม่ใช้คอมพิวเตอร์ก็ตาม

สิ่งที่ทำให้ผมพอจะหวังในแง่ positive กับเรื่องนี้ได้ ก็คือ จริงๆ แล้วภาคการศึกษาของเราตื่นตัวพอสมควรในเรื่องนี้ คนที่เข้าใจมันจริงๆ ช่วยกันหลายคนอยู่ในการสอนคนที่จะต้องไปสอน (ครู) ในภาคส่วนต่างๆ ช่วยกันอบรมช่วยกันอะไรหลายอย่าง ......

สุดท้ายมันคงไม่กลายเป็นประวัติศาสตร์ที่ซ้ำรอยกับคณิตศาสตร์

แถมครับ หนังสือดีๆ เล่มเล็กๆ อ่านคืนเดียวจบ ..... ลองอ่านหน้าแรกได้ครับ

เรียนโค้ดดิ้งโดยไม่ต้องมีคอมพ์ได้มั้ย ?
.
ส่วนตัวตอนสมัยยังเด็ก ที่บ้านไม่ค่อยมีเงิน จะซื้อคอมพ์ใช้นี่ไม่ต้องหวัง แต่ตัวเองก็อยากเขียนโปรแกรมเป็นมาก ก็เลยต้องใช้วิธีออกแบบโปรแกรมลงกระดาษ แล้วค่อยไปลงโค้ดที่ห้องคอมพ์โรงเรียน
.
และก็ได้รู้ตอนนั้นว่าที่เขียนลงกระดาษกับที่เขียนลงตีพิมพ์มันคนละศาสตร์กัน
.
เรื่องแรกที่อาจต้องแยกให้ออกก่อนเลยคือ "Coding" กับ "Problem Solving" มันเป็นคนละศาสตร์กันโดยสิ้นเชิง
.
ศาสตร์ของการแก้ปัญหา (Problem Solving) เป็นเรื่องของการคิด การวางแผน การวิเคราะห์ ตรรกศาสตร์ ฯลฯ ส่วน Coding เป็นการลงมือเขียนโค้ดเพื่อให้เห็นผลลัพธ์ออกมา
.
Problem Solving ไม่จำเป็นต้องใช้คอมพ์ มีวิชาที่ใช้สอนกันมาตั้งแต่สมัยชาติปางก่อนอย่าง Flow Chart สมัยนี้ก็ยังถือว่ามีประสิทธิภาพอยู่ ช่วยสอนวิธีการคิดเป็นขั้นเป็นตอนได้เป็นอย่างดี เขียนบนกระดานได้เลย สอบด้วยกระดาษก็ได้ อันนี้เห็นด้วย
.
แต่พอมาเรื่อง Coding ... มันเป็นเรื่องของการใส่โค้ดเข้าไปเพื่อดูผลลัพธ์ ไม่ต้องแก้ปัญหาอะไรก็ได้ โปรแกรมแรกที่เราเขียนคือเอาโปรแกรมภาษาเต่ามาวาดรูปกังหันลมบนจอคอมพ์ หมุนไปหมุนมา ไม่ได้ใช้ตรรกศาสตร์อะไรทั้งสิ้น แต่ที่ต้องใช้คือ ... คอมพ์
.
ถ้าให้เทียบกับการเย็บผ้า ก็เหมือนว่าเรียนเย็บผ้าแต่ไม่มีเข็มกับด้ายนั่นแหละ บอกให้เขียนการเย็บในกระดาษเอานะ ก็เรียนได้นะ แต่ไม่มีประโยชน์อะไรเลย
.
แต่ถ้าเปลี่ยนไปสอนเรื่องการด้นถอยหลังมีวิธีคิดยังไง การเย็บแบบซ่อนตะเข็บทำได้ยังไง อันนี้โอเค สอนในกระดาษได้ เอาไปคิดต่อได้
.
ดังนั้นคงต้องไปแยกแยะให้ได้ก่อนว่าตกลงอยากจะสอนโค้ดดิ้งหรือสอนการคิดแก้ปัญหากันแน่ คนละเรื่อง คนละศาสตร์ คนละเทคนิค
.
แต่ถ้าสุดท้ายจะสอนโค้ดดิ้งจริง ๆ แล้ว การไม่มีคอมพ์มันสอนแล้วหวังผลอะไรไม่ได้หรอกครับ
.
จะว่าไปราคาเรือดำน้ำลำนึงนี่ซื้อคอมพ์แจกโรงเรียนทั่วประเทศได้เป็นล้านเครื่องเลยนะ
.
อันนี้สอนในกระดาษกันได้อยู่ครับ ไม่ต้องใช้คอมพ์

ทำไมมึงไม่ไปโพสใน >>>/tech/6362/

>>966 ขอโทษที เมากระทู้

ไอ้พวก ไอพี เขารู้ได้ไงว่าบ้านที่ไหน
อย่างไอ้ 192.168.1.1

>>958 โดนอยู่ เจอให้ทำชีวะ นั่งน้ำลายยืดเลย

>>968 นั้น ip วงแลน แต่ isp รู้ว่าเราเล่นจากที่ไหนจริงๆ ส่วนเว็บเช็คมันไม่ค่อยตรง

https://www.facebook.com/groups/647718825333067/permalink/2121722874599314/

มีคนหมิ่นโค้ดสตาร์ของเราครับ

พวกมึง Outsource .net ปสก 2 ปีครึ่ง ฝีมือทั่วไป เงินเดือนเท่าไหร่กันแล้ววะ กุ 45k มากหรือน้อย

>>972 น้อย 80k ปกติอย่างต่ำ

>>973 โคตรเยอะ

>>973 มึงนึกว่าที่นี่เป็นซิลิก้อนวัลเล่เหรอวะ

>>972 ถ้าพูดได้แต่ไทยก็ประมานนั้นแหละถ้า eng ได้ก็ทำ 80k ได้

เพื่อนโม่ง​ ตอนนี้สายวิศวะคอม​ หรือ​ It สายไหนน่าเรียนกว่ากัน​ มีงานรองรับมากกว่า

>>977 ไม่เทพชีวะก็ตกงานหมดล่ะสมัยนี้

>>978 ยังไงวะ?

>>978 ยิ่งเทพ neuro นะ ยิ่งหางานสบาย รายได้กระฉูด

พวกมึง
เวลาเขียนหน้าเว็บพวก html ต้องไม่ควร bind script หรือชื่อ function ต่างๆ ไปตรงๆ ใช่ไหมวะ กุเห็นเว็บใหญ่ๆดังๆ เคยกด f12 ไปดู เหมือนเค้าเขียน class ไว้ แล้วไปเขียนการทำงานใน class script อีกที กุเข้าใจถูกป่าว แล้วชื่อ class แม่งก็เขียนแบบชื่อไม่สื่ออ่ะ แบบไม่รู้เรื่อง แต่โปรแกรมเมอร์เค้ามี doc เรื่องชื่อแปลกๆ กันเอง (ชื่อแปลกเอาไว้ให้คนอื่นอ่านไม่ค่อยออกเวลามาแกะเว็บ) กุเข้าใจถูกป่าววะ ตอนนี้กุเขียนเว็บแม่งใส่ชื่อ function แล้ว bind กับ html ไปตรงๆ เกือบทุกอันเลย คือเวลาแกะดูแล้วเปลี่ยน html นุ้นนี่นั่น เว็บมันทำงานแปลกๆ หรือกรณีนี้ควรไปเช็คฝั่ง backend
อย่างบางเว็บของ google กุเหนเค้าใส่ html ประมาณนี้อ่ะ <span class="VfPpkd-Q0XOV"><div class="VVsfQ"></div></span>
กุควรเปลี่ยนวิธีดีไหม

เพราะมึงมันโง่ไม่ยอมเรียนกับโค้ดสตาร์

ทำไมพวกมึงต้องไปแขวะโค้ดสตาร์อะไรนี้วะ กูไม่รู้บอกกูที

>>983 เพราะมันลงโฆษณาว่าเรียนจบแล้วออกไปหางานเงินเดือน 30k+ กุก็เห้นมันโฆษณามานานตั้งแต่กุเริ่มทำงานใหม่ๆ แล้วนะ นี่ก็หลายปีแล้ว กุก้อไม่เคยเข้าไปดูหรอก แต่เห็นคนชอบแขวะประจำ

>>983 เพราะมึงไม่เข้าถึงความเป็นโค้ดสตาร์ไง

เห็นคนแชร์เรื่องสัมภาษณ์งานในสมาคมอะไรซักอย่าง ทำให้อยากเขียนสิ่งนี้ขึ้นมาเลย

ชีวิตนี้ ผมสัมภาษณ์งานไม่ผ่านเยอะมากเลยนะ น่าจะเยอะกว่าที่หลายคนคิดไว้

แต่สุดท้าย เวลามันใช่ มันใช่ของมันเอง

ตอนที่ผมเข้า Taskworld ใหม่ๆ ใช้ Git เป็นงูๆ ปลาๆ มาก Javascript build รวมกันยังไงก็ไม่รู้ คนอื่นเขา Grunt เขา Webpack ของเราที่ทำมาตลอดยังแค่ใช้ script มารวมๆ กันอยู่เลย เขียน React ก็ไม่เคย ตอนนั้นได้งานทำ SPA มาคือเขียน Framework SPA เล็กๆ เอง เพราะไม่รู้จัก React

ที่อื่นจะไม่รับก็ไม่แปลก จะบอกว่าไม่เชี่ยวชาญพอก็เถียงไม่ได้แหละ

แล้วสุดท้าย ก็น่าประหลาดใจที่มันเป็นที่ๆ เหมาะกับตัวเองในช่วงชีวิตตอนนั้นมากๆ มันมีเคมีที่เข้ากัน และทั้งผมทั้งบริษัทก็ได้เติบโตจากกันและกันมากมายมหาศาล

=============================

ถ้าเรามองจากมุมของคนที่ออกแบบสัมภาษณ์ ไม่แปลกเลยที่จะหาวิธีการพัฒนาให้มันแฟร์ขึ้น แม่นยำขึ้น ดีขึ้น

แต่ถ้าเราเป็นคนสัมภาษณ์ ก็อยากจะให้มองมันอย่างเข้าใจ

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

บางทีมันไม่มีใครผิดใครถูกหรอก หรือเปล่าประโยชน์ที่จะไปหา

มันก็แค่ไม่ใช่เวลาไม่ใช่โอกาส ก็แค่นั้น

=============================

ผมเชื่ออย่างหนึ่งว่า กฎแรงดึงดูดมีจริงนะ

ผมเป็นคนที่ออกความเห็นเยอะ เขียนอะไรเยอะ

คนชอบก็มี คนไม่ชอบก็มี พูดมากขนาดนี้ คนหมั่นไส้ก็คงมีเยอะแน่ๆ

บางคนมาเห็นความเห็นแล้วจะตัดโอกาสของเราไม่อยากร่วมงานกับเรา ไม่อยากให้โอกาส คิดว่าแบบแนวคิดของเราไร้สาระ ตัดโอกาสทิ้ง เกิดขึ้นได้มั้ย ก็คิดว่าเกิดขึ้นได้

แต่ชีวิตมันกินทุกโอกาสไม่ได้

และการที่เราเลือกที่จะเป็นตัวเอง แสดงความเป็นตัวตน ก็จะนำพาโอกาสที่ใช่เข้ามาหา และผลักโอกาสที่ไม่ใช่ออกไป

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

โอกาสที่ไม่ใช่ จะไม่ยอมรับความเป็นตัวเรา จะรู้สึกว่าตัวตนของเราไม่เหมาะกับเขา จะอึดอัดกับความเป็นตัวตนของเรา

มันเป็นธรรมดาของโลกนี้ ไม่ได้มีใครผิดใครถูก มันแค่เข้ากันไม่ได้

สัมภาษณ์งานก็เหมือนกัน ถ้ามันไม่เหมาะ เวลามันไม่ใช่ โอกาสไม่ใช่ มันก็ไม่ได้ ก็แค่นั้นแหละ

=============================

อยากให้กำลังใจน้องๆ หรือเพื่อนๆ พี่ๆ ที่อาจจะกำลังย้ายงาน

วันนี้เราสัมภาษณ์ไม่ผ่าน เราอาจจะคิดว่า มันต้องมีใครผิด ไม่ฉันผิด ก็อีกคนผิด ไม่ฉันแย่ ก็บริษัทแย่ พยายามอธิบายด้วยแนวคิดผิดถูก

ความผิดหวังเป็นเรื่องธรรมดา ผมผ่านมาเยอะนะ

แต่จริงๆ โลกมันซับซ้อนกว่านั้น เป็นสีเทามากกว่านั้น

อยากให้เชื่อมั่นว่าสุดท้ายโลกจะหาสิ่งที่ใช่เข้ามาหาเรา ผลักสิ่งที่ไม่ใช่ออกไปจากเรา

กฎแรงดึงดูดมีจริงเสมอ ผมเชื่อ และก็ผ่านมาแล้ว

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

แต่กฎแรงดึงดูดจะทำงานได้ดี เราต้องมั่นคง ต้องมี Integrity คอยพัฒนาตัวเองในแนวทางที่ตัวเองเป็นอยู่สม่ำเสมอ จนความเป็นตัวตนชัดเจนขึ้น

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

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

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

ชีวิตช่วงไหนที่ผมสับสนกับตัวเองมากๆ โอกาสต่างๆ ที่เข้ามาก็จะสับสนมาก พอๆ กับความสับสนภายในจิตใจ

ผมถึงเชื่อในกฎแรงดึงดูด

และก็อยากเตือนด้วย

ถึงแม้จะเชียร์ว่า ให้เป็นตัวตนของตัวเอง แต่ก็อย่าให้ความเป็นตัวเรามันไม่ได้ไปบดบังคนอื่น Abuse คนอื่น

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

มันผลักโอกาสต่างๆ ออกไปนะ มันจะดึงดูดคนที่คิดว่า "การกดคนอื่นเพื่อให้ตัวเองเด่นเป็นธรรมดาโลก" เข้ามาในชีวิตนะ

แสดงความเป็นตัวตนในกาลเทศะและเวลาที่เหมาะสม ไม่กดคนอื่นลงเพียงเพื่ออยากขับเน้นตัวเองให้เด่นขึ้น

ทั้งให้กำลังใจและก็เตือนสตินะ

Bloc pattern เป็นไงบ้าง ดีไหม

Stack overflow ลุกเป็นไฟ
ไอ้ห่า genderpolitic ไปถึงไหน พังถึงนั่น

>>988 ไหน

ใครเป็นแฟนขับอาจารย์
กบถาวร แห่ง ชวาไทยแลนด์บ้าง

ชมรมโปรแกรมเมอร์ใสๆไม่กินมาม่าหายไปไหน

>>991 ยังอยู่นี่

>>990 จานกบแกเน้นขาย pos นะเว้ย รวยเปนล้าน 555555

>>991 ของกูหายไปแล้วอ่ะโม่ง กรุ๊ปมันปรับค่าใหม่เหรอวะ?

ใครเคยทำ dtac มั่งวะ โบนัสเค้าได้กันกี่เดือน

แต่กุเหนป้ายโฆษณา เหมือนเค้าตัดโบนัสเปน ไตรมาส รึป่าววะ แล้วได้เยอะไหมแต่ละไตรมาส

>>995 บริษัทนี้รับโปรแกรมเมอร์เป้นพนักงานประจำแล้วหรอวะ แต่ก่อนเห็นใช้วิธีจ้าง outsource อย่างเดียว

>>996 ตอนนี้ก็ยัง outsource อยู่

โค้ดสตาร์ทำให้เน็ตเหี้ย

ควยถอกเย็ดแม่แอดมินกะเทยควายควยโค้ดสตาร์

เย็ดแม่แอดมิน หัวยควย แอดมินเย็ดกะเทยหัวควย

หัวควยกาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
หี
หี
หั
หี
หี
หี
หี
หี
หี
หี
หี
หรี
กะหรี่หน่อแต่ดหัวควยอิเล็กทรอนิกส์

ควยถอกเย็ดแม่แอดมินกะเทยควายควยโค้ดสตาร์

เย็ดแม่แอดมิน หัวยควย แอดมินเย็ดกะเทยหัวควย

หัวควยกาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
กาพี้
หี
หี
หั
หี
หี
หี
หี
หี
หี
หี
หี
หรี
กะหรี่หน่อแต่ดหัวควยอิเล็กทรอนิกส์