วันนี้เป็นวันที่ 2 ของ 100 ใน Solidity Series
วันนี้ฉันได้เรียนรู้เกี่ยวกับความคิดเห็นและรูปแบบ NatSpec ในรูปแบบ Solidity

Solidity รองรับทั้งความคิดเห็นสไตล์ C และ C++ ดังนั้น −

• ข้อความใดๆ ระหว่าง a // และท้ายบรรทัดจะถือเป็นความคิดเห็น และ Solidity Compiler ละเว้น
• ข้อความใดๆ ระหว่างอักขระ / และ / ถือเป็นความคิดเห็น ซึ่งอาจครอบคลุมหลายบรรทัด

 // This is a Single Line Comment

 /* This is A Multi-Line Comment It can also Include Emojis 😃 */

รูปแบบ NatSpec

สัญญา Solidity สามารถใช้ความคิดเห็นในรูปแบบพิเศษเพื่อจัดเตรียมเอกสารที่สมบูรณ์สำหรับฟังก์ชัน ส่งคืนตัวแปร และอื่นๆ รูปแบบพิเศษนี้มีชื่อว่า Ethereum Natural Language Specification Format (NatSpec)

 /// This is NatSpec Single Line Comment /// @title This is a Title /// @author Author Name /// @dev Please use this in this way

 /** This is NatSpec Multi Line comment This is Line 2 And so on.... */

เพิ่มเติมเกี่ยวกับ NatSpec – ที่นี่

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

ข้อกำหนดเบื้องต้น

• รีมิกซ์

เริ่มต้น

รายละเอียดสัญญา

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

ดูตัวอย่างต่อไปนี้:

 // SPDX-License-Identifier: MIT pragma solidity ^ 0.8 . 13 ; contract Kill { constructor () payable {} fallback () external payable {} receive () external payable {} function kill () external { selfdestruct ( payable ( msg . sender )); } function testCall () external pure returns ( string memory ) { return "Tst called" ; } function contractBal () external view returns ( uint ) { return address ( this ). balance ; } function ownerBal () external view returns ( uint ) { return msg . sender . balance ; } } contract Helper { function getBalance () external view returns ( uint ) { return address ( this ). balance ; } function kill ( Kill _kill ) external { _kill . kill (); } }

การ ฆ่า สัญญาครั้งแรกมีฟังก์ชัน receive() และ fallback() ซึ่งทำให้สัญญาสามารถส่งและโอน ETH ไปยังที่อยู่อื่นได้ ฟังก์ชั่น kill() มี selfdestruct() ซึ่งจะ ‘ฆ่า’ สัญญา Kill ฟังก์ชัน testCall() , contractBal() และ ownerBal() ส่งคืนสตริง ยอดคงเหลือ ETH ของสัญญา และยอดคงเหลือ ETH ของเจ้าของตามลำดับ แต่ฟังก์ชันทั้งสามจะถูกยกเลิกหลังจาก kill() ถูกดำเนินการ

Helper สัญญาที่สองสามารถ ‘ฆ่า’ การ ฆ่า สัญญาโดยไม่ต้องมีฟังก์ชั่นสำรอง และ Helper จะได้รับยอดคงเหลือ ETH ของการฆ่าสัญญาหลังจากถูกยกเลิก

ทดสอบสัญญาโดยใช้ Remix

• 1. สัญญา ฆ่า

ก่อนที่ kill() จะถูกดำเนินการ:

หลังจาก kill() ถูกดำเนินการ:

• 2. ผู้ช่วย สัญญา

หลังจาก kill() ถูกดำเนินการ ยอดคงเหลือของสัญญา Kill จะถูกโอนไปยัง Helper :

ภาพถ่ายโดย Roman Synkevych 🇺🇦 บน Unsplash

การปรับปรุง DX (ประสบการณ์ของนักพัฒนา) เป็นการลงทุนที่ถูกกว่าในอาชีพการงานของคุณ คุณสามารถเขียนและค้นหาการปรับปรุงที่ดีขึ้นสำหรับสิ่งที่มีอยู่

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

ในบล็อกโพสต์เล็กๆ นี้ มาเรียนรู้วิธีปรับปรุงประสบการณ์นักพัฒนาซอฟต์แวร์ของเราโดยการรวมนามแฝง git และ gh cli

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

และการใช้ git ทุกวันเป็นหนึ่งในนั้นสำหรับฉัน ดังนั้นถึงเวลาต้องปรับปรุง

บิตน้อยลงด้วยนามแฝง git
อันดับแรก ฉันเริ่มเขียนนามแฝง git สำหรับคำสั่งทั่วไปที่ฉันใช้อยู่ กิจวัตรของฉันคือ:

 git status git pull origin main git checkout -b branch/name git add file-name git commit -m "feat(commit): message" git push origin branch/name

• อัปเดตหลัก: git pull origin main
• เปิดสาขาใหม่: git checkout -b branch/name
• เพิ่มไฟล์ git add file-name
• เพิ่มข้อความยืนยัน git commit -m "feat(commit): message"
• ผลักดันการเปลี่ยนแปลงไปยัง repo git push origin branch/name
• ไปที่ฮับ git บนหน้าคำขอดึง
• เปิดคำขอดึงใหม่และรวม

รูทีนนี้มีบิตซ้ำหลายครั้งสำหรับทุกคำสั่งและในทุกคำขอดึงใหม่

ดังนั้นฉันจึงตัดสินใจสร้างนามแฝง git ของฉัน:

 co = checkout st = status cob = checkout -b cim = commit -m alias = ! git config --get-regexp ^alias. | sed -es/^alias.// -es/\ /\ =\ / pom = pull origin master poma = pull origin main

ตรวจสอบรายชื่อของฉันและวิธีการเพิ่มได้ที่นี่ https://gist.github.com/daniloab/04e45c7f4145ce185c7898a25e25892a

ด้วยการเปลี่ยนแปลงนี้ ขั้นตอนของการสร้างคำขอดึงใหม่เริ่มมีบิตน้อยลง แต่ยังมีพื้นที่สำหรับการปรับปรุง

 git st git cob branch/name git add --a git cim "feat(commit): message" gh pr create --fill

gh cli
แม้จะมีชื่อแทน git ใหม่ การดำเนินการเพื่อเปิดคำขอดึงใหม่ยังคงมีปัญหาในการไปที่ฮับ git และทำทุกอย่างเพื่อให้เปิดคำขอดึงใหม่ได้

สิ่งที่ยอดเยี่ยมที่นี่คือ git ที่ต้องเผชิญกับความเจ็บปวดเช่นเดียวกัน ดังนั้นพวกเขาจึงสร้าง gh cli ซึ่งเป็น cli เพื่อช่วยในการสั่ง git

เมื่อสร้างนามแฝงเสร็จแล้ว ฉันแค่ต้องแต่งด้วย gh cli มีคำสั่งมากมายในการเปิดที่เก็บใหม่ สาขา คอมมิต คำขอดึง ฯลฯ คำสั่งสำหรับสถานะ เปิดสาขา และเพิ่มการคอมมิตใหม่นั้นใช้ได้กับ git นามแฝง ฉันต้องการปรับปรุงส่วนของการสร้างคำขอดึงใหม่ และ git cli สามารถให้บริการสิ่งนี้กับฉันด้วย gh pr create

https://cli.github.com/manual/gh_pr_create พร้อมแฟล็กที่คุณต้องการ

จากนั้นฉันแค่ต้องเปิด pr ที่เติมด้วยข้อความยืนยัน คำสั่งสุดท้ายสำหรับการเปิดคำขอดึงคือ:

 git st git poma git cob branch/name git add --a git cim "feat(commit): message" gh pr create --fill

นามแฝงเทอร์มินัล
เราสามารถตกลงกันได้ว่ามีบิตน้อยกว่าคำสั่งเริ่มต้น แต่ gh cli สำหรับคำสั่งที่ใหญ่กว่า จากนั้นฉันเพิ่มลงในเทอร์มินัลนามแฝงที่เรียกว่า gcpf :

alias gpcf="gh pr create --fill"

มีผลลัพธ์สุดท้ายเป็น:

 git st git poma git cob branch/name git add --a git cim "feat(commit): message" gpcf

gpcf + two เข้าไปพิมพ์คำสั่งและยืนยันการเปิด pull request ใหม่

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

ขั้นตอนต่อไปของฉันคือการรวมคำสั่งในการเปิดสาขา เพิ่มข้อความ git และเปิดคำขอดึงในคำสั่งเดียวเท่านั้น ไม่ยากและฉันแค่ตั้งเวลาไว้เล็กน้อยเพื่อทำสิ่งนี้

หากคุณมีแนวคิดสำหรับสิ่งนี้ แสดงความคิดเห็นด้านล่าง แบ่งปันกับเราถ้าคุณมี DX ที่ยอดเยี่ยมสำหรับรูทีน git

ติดตามฉันบน Twitter
ถ้าคุณชอบและต้องการสนับสนุนงาน ของฉัน มาเป็นผู้อุปถัมภ์ของฉัน
ดูเพิ่มเติมใน https://linktr.ee/daniloab

ปัญหาการพัฒนาซอฟต์แวร์ที่สำคัญที่เราไม่ได้พูดคุยกันที่ ClickPesa . อีกต่อไป

1. การทำงานกับปัญหาและตัวติดตามปัญหา
2. การทำงานกับสาขา Git แยกกันสำหรับทุกปัญหา
3. แบ่งประเด็นให้เล็กลง
4. ตัวแปรที่มีความหมายและชื่อการกำหนดค่า
5. ชื่อโครงการและที่เก็บที่มีความหมาย
6. ทำงานกับเครื่องมือที่ให้บริการคุณ
7. กระบวนการที่มีความหมายและกำหนดไว้
8. พูดออกไปและขอความช่วยเหลือโดยเร็ว
9. ข้อความยืนยันที่มีความหมาย
10. คำอธิบายปัญหาโดยละเอียด
11. แบบทดสอบ
12. รีวิวโค้ด
13. การนำโค้ดไปใช้นั้นหลังจากการวิจัยที่มีการจัดทำเป็นเอกสารอย่างดี

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

ติดตามบล็อกเทคโนโลยีของเรา ซึ่งทีมจะแบ่งปันเรื่องราวเกี่ยวกับเส้นทางการพัฒนากระบวนการพัฒนาของเรา และอีกมากมาย

ClickPesa ติดตาม

เรื่องราวเกี่ยวกับเทคโนโลยีจากการสร้างนินจา @ClickPesa และ @GetpaidAfrica

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

บทความนี้จะสรุปวิธีการจางในเฟรมเทอร์โบที่โหลดโดยไม่ต้องใช้ Javascript เพิ่มเติม

ข้อจำกัดความรับผิดชอบ – การตั้งค่ารวมถึงการกำหนดค่า Tailwind ซึ่งเป็น Javascript ในทางเทคนิค

ไอเดียและการตั้งค่า

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

วิธีการทั่วไปในการทำเช่นนี้คือการเพิ่มแอนิเมชั่นจาวาสคริปต์ โชคดีที่คุณสามารถเพิ่มเอฟเฟกต์แบบเดียวกันด้วย CSS เพียงอย่างเดียว 🥳

การเพิ่มภาพเคลื่อนไหว CSS ให้กับ Tailwind

การตั้งค่า Tailwind ค่อนข้างตรงไปตรงมา แนวคิดทั้งหมดคือการเพิ่มแอนิเมชั่น CSS ที่จะเปลี่ยนความทึบขององค์ประกอบจาก 0% เป็น 100%

 // tailwind.config.js module . exports = { // ... theme : { extend : { animation : { " fade-in " : " fadeIn 0.15s ease-in-out " }, keyframes : () => ({ fadeIn : { " 0% " : { opacity : 0 }, " 100% " : { opacity : 1 } } }) } } }

ตอนนี้แอนิเมชั่นนี้จะพร้อมใช้งานโดยการเพิ่มคลาส animate-fade-in ให้กับองค์ประกอบ 💆

การใช้เฟดอินบน Turbo Frame

การใช้การเฟดเป็นการเพิ่มคลาสแอนิเม animate-fade-in เฟรมเทอร์โบ (หรือเนื้อหาที่อยู่ภายใน)

 <turbo-frame id= "loadable" class= "animate-fade-in" > <h3 class= "uppercase font-semibold" > Fading in </h3> </turbo-frame>

โว้ว!

ห่อ

เห็นได้ชัดว่าสามารถใช้การเฟดอินดังกล่าวนอกบริบทของ Hotwire หรือ Tailwind อย่างไรก็ตาม นี่ดูเหมือนจะเป็นกรณีการใช้งานที่ยอดเยี่ยมที่เชิญชวน UX ที่ดีกว่าและมีค่าใช้จ่ายเพียงเล็กน้อย

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

ความผิดหวังในการสร้างระบบคลาวด์ทำให้ฉันสร้างเครื่องมือพัฒนาแบ็กเอนด์ได้อย่างไร ฉันเชื่อว่าจะเปลี่ยนชีวิตของนักพัฒนา และประกาศว่าบริษัทของเราได้ระดมทุน 3 ล้านเหรียญสหรัฐฯ

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

ไม่กี่ปีต่อมา ฉันได้งานแรกเป็นนักพัฒนาซอฟต์แวร์และเข้าร่วม Spotify ซึ่งหมายความว่าฉันต้องเรียนรู้วิธีสร้างแอปพลิเคชันแบ็กเอนด์ใหม่ ฉันเคยชินกับการตั้งค่าง่ายๆ กับเซิร์ฟเวอร์หนึ่งหรือสองเซิร์ฟเวอร์ แต่ตอนนี้ เรากำลังสร้างระบบที่ปรับขนาดได้จำนวนมากสำหรับ The Cloud™ ความซับซ้อนของโครงสร้างพื้นฐานระบบคลาวด์เริ่มครอบงำงานของฉัน แทนที่จะสร้างผลิตภัณฑ์ที่ยอดเยี่ยม เราใช้เวลาทั้งหมดของเราในการจัดเตรียม จัดการ และจัดการบริการคลาวด์ มันเป็นเรื่องธรรมดาและซ้ำซาก และช้ากว่าและซับซ้อนกว่าร้อยเท่าเมื่อเทียบกับสมัยของเซิร์ฟเวอร์เดียว ไม่มีอะไรที่เหมือนกับกระบวนการสร้างสรรค์ที่ฉันเคยรักที่จะโตมา

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

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

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

ในปี 2560 ฉันเริ่มต้นด้วยการร่างแนวคิดเพื่อดูว่ามีอะไรอยู่ในนั้นหรือไม่ เมื่อฉันตระหนักว่ามันใช้งานได้มันก็กินเวลาชีวิตของฉัน รู้สึกตื่นเต้นและสำคัญมาก เป็นเวลาหลายปีที่ฉันกลับบ้านจากที่ทำงานเวลา 18.00 น. เริ่มแฮ็กข้อมูลและทันใดนั้นก็จะเป็น 4 โมงเช้า

ภายในต้นปี 2020 Encore ก็พร้อมสำหรับผู้ใช้ในช่วงต้น ดังนั้นฉันจึงออกจาก Spotify เพื่อทำงานเต็มเวลา เราเปิดแหล่งที่มาเมื่อปีที่แล้วและแผนกต้อนรับก็ทำให้เราผิดหวัง เราเปลี่ยนจากการมีผู้ใช้เพียงไม่กี่คนเป็นนักพัฒนาหลายพันคนที่ทดลองใช้งาน

วันนี้ฉันตื่นเต้นที่จะประกาศว่าเรากำลังเปิดตัว Encore v1.0 ฉันเชื่อว่า Encore จะเปลี่ยนชีวิตของนักพัฒนา งานของเราจะสนุกสนานและสร้างสรรค์มากขึ้น แทนที่จะเป็น 80% เกี่ยวกับการกำหนดค่าเครื่องมือและบริการที่ได้รับการกำหนดค่าใหม่นับพันครั้งก่อนหน้านี้ เราจะใช้เวลาวันของเราในการสร้างผลิตภัณฑ์ใหม่ที่มีผลกระทบอย่างแท้จริง และนั่นอาจเป็นประโยชน์อย่างมากต่อสังคม ลองนึกภาพนวัตกรรมที่น่าตื่นเต้นถ้านักพัฒนากว่า 25 ล้านคนทั่วโลกมีอิสระในการทำงานมากขึ้นถึง 5 เท่า!

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

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

จับคุณในเมฆ
อังเดร

เผยแพร่ครั้งแรกในบล็อก Encore วันที่ 19/04/22

สวัสดี! 👋

โพสต์นี้เป็นภาคที่ 2 ของซีรีส์ “Roast the Code” ของฉัน ซึ่งฉันจะแชร์โค้ดบางส่วน และให้คุณย่างและ/หรือปรับปรุงมัน ไม่มีอะไรมากไปกว่านี้ แค่สุภาพและสร้างสรรค์

คราวนี้เป็นเกมเรือกวาดทุ่นระเบิดที่เรียกว่า Bugsweeper ซึ่งเขียนด้วยภาษา Dart และ UI ที่สร้างโดยใช้ Flutter โครงการสนุกเล็กๆ น้อยๆ ที่ฉันเขียนเมื่อวันเสาร์ที่แล้ว

คุณสามารถตรวจสอบได้ ที่นี่ ( โปรดทราบว่าไซต์อาจโหลดช้า ฉันจะเขียนโพสต์ที่เกี่ยวข้องกับสิ่งนี้ในอนาคตอันใกล้ )

บันทึก

• โฟกัสของฉันอยู่ที่ตรรกะของเกม UI ต้องการการทำงานเล็กน้อย แต่ก็สามารถเล่นได้

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

ตอนนี้ ตรงไปที่ repo และย่างให้แรงที่สุด!

การใช้ Cloudflare Access เพื่อล็อคเครื่องมือภายในที่เราโฮสต์เอง

ที่ ente เราโฮสต์เครื่องมือโอเพ่นซอร์สมากมาย แม้ว่าเราจะต้องใช้ความพยายามเล็กน้อยในการตั้งค่าและบำรุงรักษาสิ่งเหล่านี้ แต่ก็ช่วยลดปริมาณข้อมูลที่เราแบ่งปันกับบุคคลที่สาม เราใช้ Sentry สำหรับการรายงานข้อผิดพลาด Grafana สำหรับการตรวจสอบ และ Metabase สำหรับการวัดผลิตภัณฑ์ (เพื่อช่วยคนอย่างฉันที่ไม่พูด SQL)

แม้ว่าเราจะมีระบบเพื่อรักษาความปลอดภัยข้อมูลประจำตัวสำหรับบริการเหล่านี้ เราต้องการแนะนำอุปสรรคเพิ่มเติมในการเข้า คำตอบที่ชัดเจนคือการจำกัดการมองเห็นบริการเหล่านี้ไว้ที่เครือข่ายภายใน แต่การดู หน้า Landing Page ของ Wireguard ทำให้ฉันรู้ว่าเราต้องการเจ้าหน้าที่พัฒนาแบบเต็มเวลาเพื่อลงเส้นทางนั้น

ฉันเริ่มสงสัยว่า “Cloudflare ยังไม่แก้ปัญหานี้ได้อย่างไร” และตัดสินใจขูดเว็บไซต์เขาวงกตของพวกเขา และพวกเขาได้แก้ปัญหานี้ไปแล้วจริงๆ

ขอแนะนำ Cloudflare – Zero Trust Access

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

การยืนยันอีเมลด้วย “PIN แบบใช้ครั้งเดียว” มีให้ในกล่อง ซึ่งสามารถใช้ร่วมกับกฎเฉพาะโดเมนเพื่อใช้เป็นจุดเริ่มต้นได้

ในกรณีของเรา การเพิ่ม Github เป็นเวกเตอร์การรับรองความถูกต้องด้วยกฎที่ตรวจสอบการมีอยู่ของผู้ใช้ภายในองค์กรของเรานั้นสมเหตุสมผล

เราเดินหน้าและวางเครื่องมือภายในทั้งหมดไว้เบื้องหลัง Access และทุกอย่างก็ดูน่าเบื่อหน่าย

จนกระทั่ง.

เราพบว่าสิ่งนี้ทำให้การรายงานข้อผิดพลาดกับ Sentry เสียหาย คำขอ POST ทั้งหมดจากไคลเอนต์เพื่อรายงานข้อผิดพลาดเริ่มล้มเหลวเนื่องจากข้อกำหนดการตรวจสอบสิทธิ์ที่บังคับใช้ใหม่

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

เราพบว่า Zero Trust Access เป็นวิธีง่ายๆ ในการปกป้องปลายทางภายใน ต่อมาเราได้เรียนรู้ว่า Google ก็อยู่ในเกมนี้ด้วย Beyond Corp มาระยะหนึ่งแล้ว

หากคุณมีข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับสิ่งที่เราสามารถทำได้ดีกว่านี้ โปรดแจ้งให้เราทราบโดยเขียนไปที่ [email protected] หากคุณเพียงต้องการติดตามการทดลองของเราด้วย dev-ops ติดตามเราบน Twitter หรือมาทักทายบน Discord

ประสบการณ์ของเราในการสร้างเทมเพลตอีเมล HTML

แม้จะเป็นผู้ออกแบบ UI/UX แต่ความหลงใหลของฉันคือการพัฒนามาตลอด ดังนั้นเมื่อทีม Getpaid กำลังทำงานในส่วนการแจ้งเตือนของแพลตฟอร์ม ฉันจึงขอให้หัวหน้าฝ่ายเทคโนโลยีอนุญาตให้ฉันทำงานกับเทมเพลตอีเมล HTML ทันที

ฉันจำได้ว่าคิดว่า “นี่ HTML ฉันใช้ HTML ได้ดี ฉันทำได้” ฉันไม่รู้เลยว่ามันสามารถสร้างเทมเพลตอีเมลฝันร้ายได้มากแค่ไหน แต่ฉันผ่านมันไปได้ ค้นคว้ามากมาย และเรียนรู้สิ่งต่างๆ มากมายเกี่ยวกับวิธีสร้างเทมเพลต HTML และสิ่งที่ต้องพิจารณาขณะสร้างเทมเพลต HTML

สิ่งที่ต้องพิจารณาขณะสร้างเทมเพลต HTML

1. ความเข้ากันได้ระหว่างไคลเอนต์อีเมลรายใหญ่

ตาม Litmus.com มีไคลเอนต์อีเมลที่แตกต่างกันประมาณ 10 ตัวที่ใช้ตลาดไคลเอนต์อีเมลทั่วโลกและไคลเอนต์อีเมลทั้งหมดเหล่านี้รองรับหรือไม่รองรับแท็ก HTML และกฎ CSS บางอย่าง

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

2. การตอบสนอง

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

3. โหมดมืด/สว่าง

จากข้อมูล ของแอป Nighteye พบ ว่า 81.9% ของผู้คนใช้โหมดมืดบนโทรศัพท์ของตน 82.7% ของผู้ตอบแบบสำรวจกล่าวว่าพวกเขาใช้โหมดมืดของระบบปฏิบัติการ และผู้ตอบแบบสอบถาม 64.6% คาดว่าไซต์จะใช้ธีมสีเข้มโดยอัตโนมัติ

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

การดำเนินการ

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

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

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

นี่คือลิงค์ไปยัง เทมเพลตอีเมล แบบเต็มหากคุณสนใจที่จะดู