professional programming

สารบัญ

• การเขียนโปรแกรมระดับมืออาชีพ - เกี่ยวกับรายการนี้
  • หลักการ
  • มีส่วนร่วมในรายการนี้
  • หนังสือที่ต้องอ่าน
  • บทความที่ต้องอ่าน
  • วัสดุทั่วไปและรายการทรัพยากรอื่น ๆ
    • รายการอื่น ๆ
    • หนังสือ
    • บทความ
    • สัจพจน์
    • หลักสูตร
  • หัวข้อ
    • อัลกอริทึมและโครงสร้างข้อมูล
    • การออกแบบและพัฒนา API
    • ทัศนคตินิสัยความคิด
      • การผัดวันประกันพรุ่ง
    • การรับรองความถูกต้อง/การอนุญาต
    • ระบบอัตโนมัติ
    • แนวทางปฏิบัติที่ดีที่สุด
    • นอกเหนือจากวิศวกรรมซอฟต์แวร์และการสุ่ม
    • อคติ
    • ธุรกิจ
    • แคช
    • การเติบโตของอาชีพ
      • การเลือกโอกาสครั้งต่อไป/ครั้งแรกของคุณ
      • ไปหาพนักงาน Eng
    • ชุดอักขระ
    • หมากรุก
    • เมฆ
    • บทวิจารณ์รหัส
    • คุณภาพการเขียนโค้ดและรหัส
    • การสื่อสาร
    • ผู้รวบรวม
    • การกำหนดค่า
    • การรวมอย่างต่อเนื่อง (CI)
    • ฐานข้อมูล
      • nosql
      • Postgres
    • รูปแบบข้อมูล
    • วิทยาศาสตร์ข้อมูล/วิศวกรรมข้อมูล
    • การดีบัก
    • การออกแบบ (Visual, UX, UI, Typography)
    • การออกแบบ (การสร้างแบบจำลอง OO, สถาปัตยกรรม, รูปแบบ, ต่อต้านรูปทรง ฯลฯ )
      • การออกแบบ: สคีมาฐานข้อมูล
      • การออกแบบ: รูปแบบ
      • การออกแบบ: ความเรียบง่าย
    • สภาพแวดล้อมและเครื่องมือ Dev
    • นักเทียบท่า
    • เอกสาร
    • dotfiles
    • บรรณาธิการและ IDE
      • vim
    • อีเมล
    • การจัดการวิศวกรรม
    • การออกกำลังกาย
    • การทดลอง
    • การเขียนโปรแกรมฟังก์ชั่น (FP)
    • การพัฒนาเกม
    • กราฟิก
    • ฮาร์ดแวร์
    • http
    • อารมณ์ขัน
    • การตอบสนองของเหตุการณ์ (ONCALL, แจ้งเตือน, ภาวะดับ, การดับเพลิง, หลังการตาย)
      • การชันสูตรศพ
    • อินเทอร์เน็ต
    • การสัมภาษณ์
    • Kubernetes
    • รูปแบบภาษาขนาดใหญ่ (LLM)
    • การเรียนรู้และการจดจำ
    • ใบอนุญาต (ถูกกฎหมาย)
    • Linux (การจัดการระบบ)
    • รหัสต่ำ/ไม่มีรหัส
    • แอสเซมบลีระดับต่ำ
    • การเรียนรู้ของเครื่อง/AI
    • คณิตศาสตร์
    • การตลาด
    • เครือข่าย
    • ความสามารถในการสังเกต (การตรวจสอบการบันทึกการจัดการข้อยกเว้น)
      • การตัดไม้
      • การจัดการข้อผิดพลาด/ข้อยกเว้น
      • ตัวชี้วัด
      • การตรวจ
    • โอเพ่นซอร์ส
    • ระบบปฏิบัติการ (OS)
    • การวิศวกรรมมากเกินไป
    • ผลงาน
    • การจัดการความรู้ส่วนบุคคล (PKM)
    • ผลผลิตส่วนบุคคล
    • ทัศนคติ
    • ความเป็นส่วนตัว
    • การแก้ปัญหา
    • การจัดการผลิตภัณฑ์สำหรับวิศวกรซอฟต์แวร์
    • การบริหารโครงการ
    • ภาษาการเขียนโปรแกรม
      • งูหลาม
      • จาวาสคริปต์
      • คอลเลกชันขยะ
    • กระบวนทัศน์การเขียนโปรแกรม
    • การพูดในที่สาธารณะ (นำเสนอ)
    • การอ่าน
    • การปรับแต่ง
    • regex
    • การปล่อยและปรับใช้
      • การกำหนดเวอร์ชัน
      • รายการตรวจสอบ
      • ฟีเจอร์ธง
      • การทดสอบในการผลิต
    • ความน่าเชื่อถือ
      • ความยืดหยุ่น
    • ค้นหา
    • ความปลอดภัย
    • เชลล์ (บรรทัดคำสั่ง)
    • SQL
    • การบริหารระบบ
    • สถาปัตยกรรมระบบ
      • รูปแบบสถาปัตยกรรม
      • Microservices/แยกเสาหิน
    • ความยืดหยุ่น
    • วิศวกรรมความน่าเชื่อถือของไซต์ (SRE)
    • หนี้ทางเทคนิค
    • การทดสอบ
    • เครื่องมือ
    • พิมพ์ระบบ
    • การพิมพ์
    • การควบคุมเวอร์ชัน (GIT)
    • จรรยาบรรณในการทำงานผลผลิตและความสมดุลในการทำงาน/ชีวิต
    • การพัฒนาเว็บ
    • การเขียน (การสื่อสารบล็อก)
  • ทรัพยากรและแรงบันดาลใจสำหรับงานนำเสนอ
  • รักษาความทันสมัย
  • แนวคิด
  • รายการอื่น ๆ ของฉัน

การเขียนโปรแกรมระดับมืออาชีพ - เกี่ยวกับรายการนี้

ให้ฉันหกชั่วโมงเพื่อตัดต้นไม้และฉันจะใช้เวลาสี่คนแรกที่คมชัดขวาน (อับราฮัมลินคอล์น)

คอลเลกชันของทรัพยากรเต็มรูปแบบสำหรับโปรแกรมเมอร์

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

หลักการ

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

รายการ:

• - : รายการทรัพยากร
• : หนังสือ
• - : วิดีโอ/ภาพยนตร์สารสกัด/ภาพยนตร์/พูดคุย
• - : สไลด์/การนำเสนอ
• ️: ต้องอ่าน
• - : กระดาษ

มีส่วนร่วมในรายการนี้

อย่าลังเลที่จะเปิดประชาสัมพันธ์เพื่อมีส่วนร่วม!

ฉันจะไม่เพิ่มทุกอย่าง: ตามที่ระบุไว้ข้างต้นฉันพยายามรักษารายการให้รัดกุม

หนังสือที่ต้องอ่าน

ฉันพบหนังสือเหล่านี้เป็นแรงบันดาลใจอย่างไม่น่าเชื่อ:

• โปรแกรมเมอร์ที่ใช้งานได้จริง: จาก Journeyman to Master: มือในหนังสือที่สร้างแรงบันดาลใจและมีประโยชน์มากที่สุดที่ฉันได้อ่านเกี่ยวกับการเขียนโปรแกรม
• Code Complete: คู่มือการสร้างซอฟต์แวร์ที่ใช้งานได้จริง: การเพิ่มที่ดีของโปรแกรมเมอร์ที่ใช้งานได้จริงช่วยให้คุณมีกรอบที่จำเป็นในการพูดคุยเกี่ยวกับรหัส
• ปล่อยมัน!: หนังสือเล่มนี้นอกเหนือจากรหัสและให้แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างซอฟต์แวร์พร้อมการผลิต มันจะให้ประสบการณ์ในโลกแห่งความเป็นจริงประมาณ 3 ปี
• กฎความสามารถในการปรับขนาด: 50 หลักการสำหรับการปรับสเกลเว็บไซต์
• อินเทอร์เฟซการเขียนโปรแกรม Linux: คู่มือการเขียนโปรแกรมระบบ Linux และ UNIX: นอกเหนือจากการสอนคุณเกือบทุกอย่างที่คุณจำเป็นต้องรู้เกี่ยวกับ Linux หนังสือเล่มนี้จะให้ข้อมูลเชิงลึกเกี่ยวกับวิธีการพัฒนาซอฟต์แวร์และคุณค่าของการมีอินเทอร์เฟซที่เรียบง่ายและสง่างาม
• โครงสร้างและการตีความโปรแกรมคอมพิวเตอร์ (ฟรี): หนึ่งในตำราที่มีอิทธิพลมากที่สุดในวิทยาศาสตร์คอมพิวเตอร์ (เขียนและใช้ที่ MIT) SICP มีอิทธิพลในการศึกษา CS BYTE แนะนำ SICP "สำหรับโปรแกรมเมอร์มืออาชีพที่มีความสนใจในอาชีพของพวกเขา"

มีหนังสือฟรีบางเล่มรวมถึง:

• การพัฒนาซอฟต์แวร์ระดับมืออาชีพ: ค่อนข้างสมบูรณ์และเป็นเพื่อนที่ดีในหน้านี้ บทฟรีส่วนใหญ่มุ่งเน้นไปที่กระบวนการพัฒนาซอฟต์แวร์: การออกแบบการทดสอบการเขียนโค้ด ฯลฯ - และไม่เกี่ยวกับเทคโนโลยีมากนัก
• - หนังสือ VHF/โปรแกรมฟรี
• - ebookfoundation/books โปรแกรมฟรี

บทความที่ต้องอ่าน

• คำแนะนำที่เป็นประโยชน์สำหรับวิศวกรซอฟต์แวร์ใหม่
• ในการเป็นวิศวกรอาวุโส
• บทเรียนที่ได้เรียนรู้ในการพัฒนาซอฟต์แวร์: หนึ่งในบทความที่ให้บทเรียนที่หายากมานานหลายปีทั้งหมดในบทความสั้น ๆ ต้องอ่าน
• สิ่งที่ฉันเรียนรู้วิธีที่ยากลำบาก
  • ข้อมูลจำเพาะก่อนจากนั้นรหัส
  • การทดสอบทำให้ APIs ดีขึ้น
  • การคิดในอนาคตคือการทิ้งขยะในอนาคต
  • เอกสารเป็นจดหมายรักต่อตัวคุณเองในอนาคต
  • บางครั้งก็เป็นการดีกว่าที่จะปล่อยให้แอปพลิเคชันล้มเหลว
  • เข้าใจและอยู่ห่างจากลัทธิสินค้า
  • "เครื่องมือที่เหมาะสมสำหรับงาน" เป็นเพียงการผลักดันวาระการประชุม
  • เรียนรู้พื้นฐานการเขียนโปรแกรมการทำงาน
  • ใช้เขตเวลาตามวันที่ของคุณเสมอ
  • ใช้ UTF-8 เสมอ
  • สร้างห้องสมุด
  • เรียนรู้ที่จะตรวจสอบ
  • ชัดเจนดีกว่าโดยปริยาย
  • บริษัท ต่าง ๆ มองหาผู้เชี่ยวชาญ แต่ทำให้ผู้คนทั่วไปอยู่ได้นานขึ้น
  • วิธีที่ปลอดภัยที่สุดในการจัดการกับข้อมูลผู้ใช้คือการไม่จับภาพ
  • เมื่อถึงเวลาหยุดก็ถึงเวลาหยุด
  • คุณต้องรับผิดชอบในการใช้รหัสของคุณ
  • อย่าบอกว่า "เสร็จแล้ว" เมื่อมันไม่ได้
  • ให้ความสนใจกับวิธีที่ผู้คนตอบสนองต่อคุณ
  • ระวังการก้าวร้าวขนาดเล็ก
  • เก็บรายการ "สิ่งที่ฉันไม่รู้"
• สัญญาณว่าคุณเป็นโปรแกรมเมอร์ที่ดี (ไม่ใช่ทุกอย่างในที่นี่ดีมาก - บางจุดเป็นสิ่งที่ต่อต้าน)
  • สัญชาตญาณในการทดลองก่อน
  • การปลดอารมณ์จากรหัสและการออกแบบ
  • กระตือรือร้นที่จะแก้ไขสิ่งที่ไม่เสีย
  • หลงใหลในผู้ที่เข้าใจยาก
  • บังคับให้สอน
  • ความอดทนที่ไม่ถูกต้อง
  • การแสวงหาความสมบูรณ์แบบทำลายล้าง
  • การจับสารานุกรมของแพลตฟอร์ม
  • คิดเป็นรหัส
  • เมื่ออยู่ในกรุงโรมเป็นชาวโรมันทำ
  • สร้างเครื่องมือของตัวเอง
  • ไม่แยแสกับลำดับชั้น
  • ตื่นเต้นกับความล้มเหลว
  • ไม่แยแสต่อสถานการณ์
  • ทดแทนแรงกระตุ้นสำหรับความมุ่งมั่น
  • ขับเคลื่อนด้วยประสบการณ์
• 7 ความจริงสัมบูรณ์ฉันไม่ได้เรียนรู้ในฐานะนักพัฒนาจูเนียร์
  • ในช่วงต้นอาชีพของคุณคุณสามารถเรียนรู้ได้อีก 10 เท่าในทีมสนับสนุนใน 1 ปีกว่าการเขียนโค้ดด้วยตัวเอง
  • ทุก บริษัท มีปัญหาทุก บริษัท มีหนี้ทางเทคนิค
  • การได้รับความเห็นมากเกินไปในหัวข้อที่คุณขาดประสบการณ์ในโลกแห่งความจริงนั้นค่อนข้างหยิ่ง
  • การประชุมหลายครั้งพูดถึงการพิสูจน์แนวคิดมากกว่าสถานการณ์ในโลกแห่งความเป็นจริง
  • การจัดการกับมรดกเป็นเรื่องปกติอย่างสมบูรณ์
  • สถาปัตยกรรมมีความสำคัญมากกว่า nitpicking
  • มุ่งเน้นไปที่ระบบอัตโนมัติผ่านเอกสารตามความเหมาะสม
  • การมีหนี้ทางเทคนิคบางอย่างมีสุขภาพดี
  • วิศวกรอาวุโสต้องพัฒนาทักษะมากมายนอกเหนือจากการเขียนโปรแกรม
  • เราทุกคนยังคงอยู่ในบางพื้นที่
• วิธีสร้างซอฟต์แวร์ที่ดี
  • บทสรุประดับสูงที่ดีของการปฏิบัติทางวิศวกรรมขั้นพื้นฐาน
  • สาเหตุที่แท้จริงของซอฟต์แวร์ที่ไม่ดีมีส่วนเกี่ยวข้องกับตัวเลือกทางวิศวกรรมที่เฉพาะเจาะจงและอื่น ๆ อีกมากมายเกี่ยวกับวิธีการจัดการโครงการพัฒนา
  • ไม่มีสิ่งใดที่เป็นวิศวกรรมที่ดี platonically: ขึ้นอยู่กับความต้องการของคุณและปัญหาการปฏิบัติที่คุณพบ
  • ซอฟต์แวร์ควรได้รับการปฏิบัติไม่ได้เป็นผลิตภัณฑ์แบบคงที่ แต่เป็นการรวมตัวกันของความเข้าใจโดยรวมของทีมพัฒนา
  • โครงการซอฟต์แวร์ไม่ค่อยล้มเหลวเพราะมีขนาดเล็กเกินไป พวกเขาล้มเหลวเพราะพวกเขาใหญ่เกินไป
  • ระวังเป้าหมายของระบบราชการที่ปลอมตัวเป็นคำแถลงปัญหา หากเป้าหมายสุดท้ายของเราคือการทำให้ชีวิตของพลเมืองดีขึ้นเราต้องยอมรับสิ่งต่าง ๆ ที่ทำให้ชีวิตของพวกเขาแย่ลงอย่างชัดเจน
  • การสร้างซอฟต์แวร์ไม่ได้เกี่ยวกับการหลีกเลี่ยงความล้มเหลว มันเกี่ยวกับความล้มเหลวเชิงกลยุทธ์ให้เร็วที่สุดเท่าที่จะทำได้เพื่อให้ได้ข้อมูลที่คุณต้องการในการสร้างสิ่งที่ดี
• วิธีการเป็นวิศวกร -10x
  • ลบล้างเอาต์พุตของวิศวกร 10 คน
  • ถือ 10 วิศวกรตัวประกันในการสนทนาทางเทคนิค
  • เสียค่าแรง 10 สัปดาห์สำหรับค่าใช้จ่ายคลาวด์
  • เสีย 400 ชั่วโมงของวิศวกรรมเกี่ยวกับสถาปัตยกรรมที่ไม่ดี
  • เกิดข้อผิดพลาด 400 ชั่วโมง

วัสดุทั่วไปและรายการทรัพยากรอื่น ๆ

รายการอื่น ๆ

• Liuchong/Awesome-Roadmaps: รายการ Roadmaps ที่รวบรวมไว้

หนังสือ

• คู่มือ imposter - $ 30 จากผู้แต่ง: "ไม่มีปริญญา CS ฉันไม่ได้ - นั่นคือเหตุผลที่ฉันเขียนหนังสือเล่มนี้"
• หนังสือวิทยาศาสตร์คอมพิวเตอร์

บทความ

• MR-MIG/ทุกโปรแกรม-รู้: คอลเลกชันของ (ส่วนใหญ่) สิ่งทางเทคนิคที่นักพัฒนาซอฟต์แวร์ทุกคนควรรู้
• กฎหมายการพัฒนาซอฟต์แวร์ที่มีชื่อเสียง
• ห้องสมุดของ Amazon Builders
  • มีรายการบทความที่ดีที่สุดในเธรด Twitter นี้
• Kdeldycke/Awesome-Falsehood: โปรแกรมเมอร์เท็จเชื่อใน
• Hellerve/Programming-Talks
• TechYaks: รายการการพูดคุย
• การพูดคุยที่เปลี่ยนวิธีคิดเกี่ยวกับการเขียนโปรแกรม
• สิ่งที่วิทยาศาสตร์คอมพิวเตอร์ทุกคนควรรู้
• Kamranahmedse/Developer-Roadmap
• MTDVIO/ทุกโปรแกรม-รู้: คอลเลกชันของ (ส่วนใหญ่) สิ่งทางเทคนิคที่นักพัฒนาซอฟต์แวร์ทุกคนควรรู้เกี่ยวกับ
• ความคาดหวังของ Mike Acton เกี่ยวกับวิศวกรซอฟต์แวร์มืออาชีพ
• สิ่งที่พวกเขาไม่ได้สอนคุณเกี่ยวกับวิศวกรรมซอฟต์แวร์
  • ความรู้โดเมนมีความสำคัญมากกว่าทักษะการเขียนโค้ดของคุณ
  • รหัสเป็นทุติยภูมิ มูลค่าทางธุรกิจเป็นอันดับแรก
  • คุณทำงานด้วยความไม่แน่นอนเกือบตลอดเวลา
• เราประเมินค่าความสามารถระยะสั้นของเราสูงเกินไป แต่ประเมินความสามารถระยะยาวของเราต่ำเกินไป
  • ความเชี่ยวชาญสำหรับแมลง
• ต้องการประโยชน์ที่ไม่เป็นธรรมในอาชีพเทคโนโลยีของคุณหรือไม่? บริโภคเนื้อหาที่มีความหมายสำหรับบทบาทอื่น ๆ
  • ความเข้าใจข้ามสายงานเป็นสิ่งสำคัญใน บริษัท เทคโนโลยีสมัยใหม่
  • ช่วยหลีกเลี่ยงการประเมินความสำคัญและความยากลำบากในบทบาทอื่น ๆ ต่ำเกินไป
  • ช่วยให้คุณมีกลยุทธ์ในการมีปฏิสัมพันธ์กับผู้คนในบทบาทนั้น
• สอนตัวเองในสิบปี

สัจพจน์

• ศีล - Urbit
  • ข้อมูลดีกว่ารหัส
  • ความถูกต้องมีความสำคัญมากกว่าประสิทธิภาพ
  • การกำหนดฮิวริสติก
  • ความเรียบง่ายหนึ่งร้อยบรรทัดดีกว่าความซับซ้อนยี่สิบบรรทัด
  • หากนามธรรมของคุณรั่วไหลมันไม่ได้เกิดจากกฎบางอย่างของจักรวาล คุณแค่ดูดที่นามธรรม โดยปกติคุณไม่ได้ระบุสิ่งที่เป็นนามธรรมให้แคบพอ
  • หากคุณหลีกเลี่ยงการเปลี่ยนส่วนของรหัสเพราะกลัวว่าจะตื่นขึ้นมาปีศาจในนั้นคุณกำลังอยู่ในความกลัว หากคุณอยู่ในขอบเขตที่สะดวกสบายของส่วนเล็ก ๆ ของรหัสที่คุณเขียนหรือรู้จักดีคุณจะไม่เขียนรหัสตำนาน รหัสทั้งหมดถูกเขียนโดยมนุษย์และสามารถควบคุมได้โดยมนุษย์
  • หากมีวิธีที่ถูกต้องในการทำอะไรและผิดวิธีให้ทำอย่างถูกวิธี การเข้ารหัสต้องมีวินัยที่เหลือเชื่อ
  • วิธีที่ดีที่สุดในการรับคำตอบที่ถูกต้องคือลองใช้วิธีที่ผิด
  • การฝึกบอกคุณว่าสิ่งที่ดีหรือไม่ดี ทฤษฎีบอกคุณว่าทำไม
  • ไม่มีคุณสมบัติที่จะแก้ปัญหาไม่มีเหตุผลที่จะไม่แก้ปัญหา
  • หากคุณไม่เข้าใจระบบที่คุณใช้คุณจะไม่ควบคุม หากไม่มีใครเข้าใจระบบระบบอยู่ในการควบคุม
• กฎฝังนิ้วโป้ง
• 50 ความคิดที่เปลี่ยนชีวิตของฉัน
• ภาพสะท้อนในการเขียนโปรแกรม 10,000 ชั่วโมง
• 20 สิ่งที่ฉันได้เรียนรู้ใน 20 ปีในฐานะวิศวกรซอฟต์แวร์

หลักสูตร

• คู่มือ Google Tech Dev
• ภาคเรียนที่ขาดหายไปจากการศึกษา CS ของคุณ MIT รวมถึงการบรรยายเกี่ยวกับเชลล์, บรรณาธิการ, การถกเถียงข้อมูล, GIT, การดีบักและการทำโปรไฟล์, การเขียนโปรแกรมเมตา, ความปลอดภัยและการเข้ารหัส
• คณิตศาสตร์สำหรับผู้เรียนรู้ด้วยตนเองผจญภัย Neil Sainsbury
• JWASHAM/CODING-Interview-University: แผนการศึกษาวิทยาศาสตร์คอมพิวเตอร์ที่สมบูรณ์เพื่อเป็นวิศวกรซอฟต์แวร์
• สอนวิชาคอมพิวเตอร์ด้วยตัวเอง: ชุดทรัพยากร CS ที่ดีที่สุด
• OSSU/วิทยาศาสตร์คอมพิวเตอร์: การศึกษาที่เรียนรู้ด้วยตนเองฟรีในวิทยาการคอมพิวเตอร์!

หัวข้อ

อัลกอริทึมและโครงสร้างข้อมูล

• อ่าน CLRS คุณสามารถดูและดาวน์โหลดหลักสูตรบน OCW - มีหลักสูตรใหม่กว่าเช่นกัน
• หรือคู่มือการออกแบบอัลกอริทึม
• ลองใช้อัลกอริทึมในออยเลอร์โครงการ
• CS 61b Spring 2023

ทรัพยากรอื่น ๆ :

• อัลกอริทึม Jeff Erickson

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

• อัลกอริธึม Grokking
• อัลกอริทึมที่จำเป็น
• การสร้างภาพโครงสร้างข้อมูล
• - 15 อัลกอริทึมการเรียงลำดับใน 6 นาที
• การแฮม
• การแสดงภาพอัลกอริทึม
• B-TREES และ DATABASE INDEXES

ตัวอย่างการใช้งาน:

• trekhleb/javascript-algorithms: อัลกอริทึมและโครงสร้างข้อมูลที่ใช้ใน JavaScript
• อัลกอริทึม

อัลกอริทึมในระบบกระจาย:

• อัลกอริทึมฉันทามติ

การออกแบบและพัฒนา API

เนื้อหาส่วนที่เหลือทั่วไป:

• รูปแบบสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่าย Roy Fielding (ผู้ประดิษฐ์ REST)
• คอลเลกชันของทรัพยากรที่มีประโยชน์สำหรับการสร้าง HTTP+JSON APIs
• แนวทางปฏิบัติที่ดีที่สุดสำหรับการออกแบบ REST API, Stack Overflow Blog
• ส่วนที่เหลือที่ไม่ถูกรบกวน: คำแนะนำในการออกแบบ API ที่สมบูรณ์แบบ: หนังสือที่สมบูรณ์มากเกี่ยวกับการออกแบบ API RESTFUL

ตัวอย่างแนวทาง:

• แนวทาง REST API ของ Microsoft
• Zalando RESTFUL API และแนวทางรูปแบบเหตุการณ์
• คู่มือการออกแบบ API ของ Google: คู่มือทั่วไปเกี่ยวกับการออกแบบ API เครือข่าย
• AIP-1: จุดประสงค์และแนวทางของ AIP
  • AIP ย่อมาจากข้อเสนอการปรับปรุง API ซึ่งเป็นเอกสารการออกแบบที่ให้เอกสารระดับสูงและกระชับสำหรับการพัฒนา API

หัวข้อเฉพาะเพิ่มเติม:

• ทำไมคุณควรใช้ลิงก์ไม่ใช่กุญแจเพื่อแสดงความสัมพันธ์ใน APIS, Martin Nally, Google
  • "การใช้ลิงก์แทนคีย์ต่างประเทศเพื่อแสดงความสัมพันธ์ใน APIs ช่วยลดจำนวนข้อมูลที่ลูกค้าจำเป็นต้องรู้เพื่อใช้ API และลดวิธีการที่ลูกค้าและเซิร์ฟเวอร์เชื่อมต่อกัน"
• ให้ฉัน /กิจกรรมไม่ใช่ webhooks
  • กิจกรรมสามารถปลดล็อกคุณสมบัติ webhook ที่จำเป็นมากเช่นการอนุญาตให้ผู้บริโภค webhook ของคุณเล่นซ้ำหรือรีเซ็ตตำแหน่งการสมัครสมาชิก webhook ของพวกเขา
• ปลดล็อกพลังของแพทช์ JSON

ทัศนคตินิสัยความคิด

• การเขียนโปรแกรมการเรียนรู้เคนต์เบ็ค
• ลักษณะของโปรแกรมเมอร์ที่มีความเชี่ยวชาญ
• TAO ของการเขียนโปรแกรม: ชุดคำอุปมาเกี่ยวกับการเขียนโปรแกรม
• การเป็นเจ้าของเป็นวิธีที่มีประสิทธิภาพที่สุดในการรับสิ่งที่คุณต้องการ
• หาเวลาในการเป็นนักพัฒนาที่ดีขึ้น
• สิบนาทีต่อวัน: วิธีที่ Alex Allain เขียนหนังสือในเวลาน้อยกว่า 200 ชั่วโมงโดยเขียน 10 นาที ทุก วัน
• การดูแลและให้อาหารวิศวกรซอฟต์แวร์ (หรือทำไมวิศวกรถึงไม่พอใจ)
  • ในซอฟต์แวร์ Triumvirate ผู้จัดการผลิตภัณฑ์นักออกแบบและวิศวกรซอฟต์แวร์มีเพียงวิศวกรเท่านั้นที่คาดว่าจะปิดใจสร้างสรรค์และผลิต
  • ทั้งวิศวกรและผู้จัดการผลิตภัณฑ์มักจะคิดอย่างไม่ถูกต้องข้อกำหนดหรือข้อกำหนดของผลิตภัณฑ์นั้นเทียบเท่ากับคู่มือเฟอร์นิเจอร์จาก IKEA
  • นี่คือหนึ่งในสิ่งที่ดีที่สุดที่ทำให้วิศวกรไม่พอใจ: ลำดับความสำคัญเปลี่ยนไปอย่างต่อเนื่อง
  • แม้ว่าวิศวกรหลายคนจะบ่นว่าผู้จัดการผลิตภัณฑ์เปลี่ยนใจ แต่ก็ไม่มีใครจะคิดในเวลาประมาณการของพวกเขา
  • โปรแกรมวิทยาศาสตร์คอมพิวเตอร์ไม่ได้เกี่ยวกับการเตรียมคุณสำหรับงานที่คุณต้องเผชิญในอุตสาหกรรม
  • เมื่อมีวิศวกรมากกว่าที่จะใช้เวลาวิศวกรรมจะจบลงจากการพัฒนาและไปสู่การวางแผนการซิงโครไนซ์และการประสานงาน
  • เกี่ยวข้องกับวิศวกรในกระบวนการสร้างสรรค์
  • เปิดโอกาสให้วิศวกรมีความคิดสร้างสรรค์
  • ส่งเสริมเวลาปิด
  • ให้รหัส em
  • แสดงความขอบคุณ
• วิศวกรซอฟต์แวร์ที่มีใจเดียวกัน Gergely Orosz
  • วิศวกรผลิตภัณฑ์ที่ยอดเยี่ยมรู้ว่าผลิตภัณฑ์ที่น่ารักขั้นต่ำต้องการความลึกที่เหมาะสม
  • วิศวกรที่มีใจรักผลิตภัณฑ์แมปเคสขอบอย่างรวดเร็วและคิดวิธีลดการทำงานให้กับพวกเขา: มักจะนำโซลูชันที่ไม่ต้องทำงานด้านวิศวกรรม
  • มีส่วนร่วมในการวิจัยผู้ใช้และการสนับสนุนลูกค้า
  • นำคำแนะนำผลิตภัณฑ์ที่ได้รับการสนับสนุนมาสู่ตาราง
  • เสนอการแลกเปลี่ยนผลิตภัณฑ์/วิศวกรรม
• 40 บทเรียนจาก 40 ปี Steve Schlafman
  • หากคุณต้องการก้าวหน้าในสิ่งที่สำคัญที่สุดคุณต้องตัดสินใจว่าคุณจะผิดหวังใคร มันหลีกเลี่ยงไม่ได้
  • การลงทุนที่ดีที่สุดที่คุณสามารถทำได้คือการศึกษาของคุณเอง อย่าหยุดเรียนรู้ การลงทุนที่ดีที่สุดอันดับสองที่คุณสามารถทำได้คือการสร้างเครือข่ายของคุณผ่านการโต้ตอบที่แท้จริงและมีความหมาย มันคือสิ่งที่คุณรู้และใครรู้
  • คุณจะไม่ได้รับสิ่งที่คุณไม่ขอหรือค้นหาอย่างแข็งขัน ไปเลย!
  • มันไม่เกี่ยวกับแสงที่ปลายอุโมงค์ มันคืออุโมงค์ ปรากฏตัวทุกวันและสนุกกับกระบวนการ
  • เพื่อนร่วมทีมที่ยอดเยี่ยมมักจะทำให้องค์กรและจุดประสงค์ของมันนำหน้าความสนใจของตนเอง
  • เลือกจุดของคุณ เรามีเวลา จำกัด และสมองของเราสามารถประมวลผลได้มากเท่านั้น โฟกัสเป็นกุญแจสำคัญ เลือกอย่างชาญฉลาด
  • ทุกคนมีแนวโน้มที่จะดิ้นรนกับบางสิ่งบางอย่าง เป็นคนใจดี เป็นประโยชน์
• เกี่ยวกับการเข้ารหัสอัตตาและความสนใจ
  • จิตใจของผู้เริ่มต้นยอมรับความจริงที่ว่าความรู้ที่แน่นอนนั้นไม่มีที่สิ้นสุดและทำให้คะแนนเสียเวลา
  • ความเชี่ยวชาญเป็นเพียงการสะสมของโมเมนตัมไม่ใช่การสะสมของความรู้
  • การจัดการกับความฟุ้งซ่านของอัตตาได้สอนให้ฉันรักกระบวนการแก้ปัญหา มันสอนให้ฉันรักและเคารพกระบวนการเรียนรู้ เป็นผลให้ฉันมีประสิทธิผลมากขึ้น ฉันกังวลน้อยลง ฉันเป็นเพื่อนร่วมทีมที่ดีกว่า ฉันเป็นเพื่อนที่ดีกว่าและเป็นนักคิดที่ดีกว่า
• คงที่เทียบกับการเติบโต: ความคิดพื้นฐานทั้งสองที่กำหนดชีวิตของเรา
• วิศวกรซอฟต์แวร์ที่ยอดเยี่ยมมีลักษณะอย่างไร
• นอนหลับสบายการเรียนรู้ดีชีวิตที่ดี
• - Steve Jobs: ถ้าคุณไม่ขอความช่วยเหลือคุณจะไม่ไปไกลมาก
• คำพูดการเขียนโปรแกรม
• ใจดี
  • การเป็นคนใจดีนั้นเป็นพื้นฐานเกี่ยวกับการรับผิดชอบต่อผลกระทบที่มีต่อผู้คนรอบตัวคุณ
  • มันต้องการให้คุณคำนึงถึงความรู้สึกของพวกเขาและคำนึงถึงวิธีที่การปรากฏตัวของคุณมีผลต่อพวกเขา
• Warren Buffett กล่าวว่านิสัยง่าย ๆ 1 เรื่องนี้แยกคนที่ประสบความสำเร็จออกจากคนอื่น ๆ
  • ความแตกต่างระหว่างคนที่ประสบความสำเร็จและคนที่ประสบความสำเร็จจริงๆคือคนที่ประสบความสำเร็จจริงๆว่าไม่เกือบทุกอย่าง
• จะโชคดีได้อย่างไร?
• โปรแกรมเมอร์ควรหยุดการเฉลิมฉลองการไร้ความสามารถ DHH
  • ความมหัศจรรย์ของการเขียนโปรแกรมส่วนใหญ่เป็นเพียงสิ่งที่คุณยังไม่รู้
  • ไม่เป็นไรที่จะคิดว่าคุณไม่ควรอยู่บนเส้นทางสู่ความเชี่ยวชาญหากคุณตั้งใจจะทำรายการอาชีพของคุณ
• ไม่มีขีด จำกัด ความเร็ว
• อย่ารอแรงจูงใจทำหน้าที่กระตุ้น
  • เริ่มต้นด้วยงานเล็ก ๆ จากนั้นขี่โมเมนตัม
• นิสัยการเข้ารหัสที่สำคัญที่สุด
  • นิสัยการเข้ารหัสที่สำคัญที่สุด
  • การยืดทุกวัน
  • หยุดพักเป็นประจำ
  • อย่ารหัสตอนดึก
  • ปรับปรุงสภาพแวดล้อมการเข้ารหัสของคุณ
• คำแนะนำสำหรับซอฟต์แวร์ใหม่ที่ได้อ่านเรียงความคำแนะนำอื่น ๆ ทั้งหมดเหล่านั้นทั้งหมด
• Microservices ไม่ใช่ปัญหา คนที่ไร้ความสามารถคือ

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

Dan Heller สร้างอาชีพในซอฟต์แวร์

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

• นักพัฒนาที่ได้รับความช่วยเหลือจาก Brawing: นิสัยของโปรแกรมเมอร์ที่ตระหนักถึงตนเอง เช่นเดียวกับเต่าของการเขียนโปรแกรมสไตล์ที่แตกต่างกัน

การตัดสินที่ดีมาจากประสบการณ์ ประสบการณ์มาจากการตัดสินที่ไม่ดี

การผัดวันประกันพรุ่ง

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

การรับรองความถูกต้อง/การอนุญาต

• การอนุญาตในโลกแห่งไมโครเซิร์ต
• ตรรกะการอนุญาต: กฎยากเพราะพวกเขาพัฒนาไปตามกาลเวลา
• หนังสือโคเปนเฮเกนให้แนวทางทั่วไปเกี่ยวกับการใช้การรับรองความถูกต้องในเว็บแอปพลิเคชัน

ระบบอัตโนมัติ

• ระบบอัตโนมัติควรเป็นเหมือน Iron Man ไม่ใช่ Ultron

แนวทางปฏิบัติที่ดีที่สุด

• แนวทางปฏิบัติด้านวิศวกรรมซอฟต์แวร์

นอกเหนือจากวิศวกรรมซอฟต์แวร์และการสุ่ม

• ทำไมวิศวกรซอฟต์แวร์ถึงงานไม้

อคติ

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

• แผ่นโกงอคติทางปัญญา #การทำเงิน

ธุรกิจ

• การชำระเงิน 101 สำหรับนักพัฒนา
• 4 ปัญหาที่ใหญ่ที่สุดเกี่ยวกับระบบการเรียกเก็บเงินแบบโฮมเมด
• - 14 ความเจ็บปวดในการสร้างระบบการเรียกเก็บเงินของคุณเอง

แคช

• ความท้าทายและกลยุทธ์การแคช, ห้องสมุด Amazon Builders

การเติบโตของอาชีพ

• รูปสามเหลี่ยมที่มีความทรงจำของการพัฒนาระดับอาวุโสมองหาวิธีกำหนดวิศวกรอาวุโส
• สิบหลักการสำหรับการเติบโตในฐานะวิศวกรแดนเฮลเลอร์
• อย่าเรียกตัวเองว่าเป็นโปรแกรมเมอร์ Patrick McKenzie
• เกี่ยวกับการเป็นผู้จัดการฝ่ายวิศวกรรม
• คำแนะนำด้านอาชีพที่ฉันหวังว่าฉันจะมีเมื่ออายุ 25 ปี
  • อาชีพคือการวิ่งมาราธอนไม่ใช่การวิ่ง
  • ความสำเร็จส่วนใหญ่มาจากการทำซ้ำไม่ใช่เรื่องใหม่
  • ถ้างานนั้นยอดเยี่ยมมากทุกคนที่ร่ำรวยจะมีงานทำ
  • การจัดการเป็นเรื่องเกี่ยวกับผู้คนไม่ใช่ของ
  • ฟังผู้อื่นอย่างแท้จริง
  • รับรู้ว่าพนักงานเป็นคนที่มีความสามารถทางอารมณ์ จำกัด
  • อย่าเพียงแค่สร้างเครือข่ายกับผู้คนอายุของคุณเอง
  • อย่าเสียสละจริยธรรมส่วนบุคคลด้วยเหตุผลในการทำงาน
  • ตระหนักว่าความล้มเหลวคือการเรียนรู้
• คำแนะนำด้านอาชีพฉันหวังว่าฉันจะได้รับเมื่อฉันยังเด็ก
  • อย่ามุ่งเน้นไปที่แผนระยะยาวมากเกินไป
  • ค้นหานักคิดที่ดีและโทรหาคนที่คุณชื่นชมมากที่สุด
  • กำหนดมูลค่าสูงให้กับผลผลิตตลอดอายุการใช้งานทั้งหมดของคุณ
  • อย่าทำสิ่งที่ไม่เหมาะสมที่ไม่ได้ให้ความสำคัญกับคุณ
  • อ่านมากและอ่านสิ่งที่คนรอบข้างไม่ได้อ่าน
  • ไตร่ตรองอย่างจริงจังเกี่ยวกับปัญหาที่จะจัดลำดับความสำคัญการแก้ปัญหา
  • อ่านประวัติเพิ่มเติม
• เหตุใดนักพัฒนาที่ดีจึงได้รับการเลื่อนตำแหน่งให้เป็น Rob Walling หรือทำไมการจัดการอาจไม่เหมาะกับคุณ
• คำแนะนำในการใช้อาชีพของคุณเพื่อช่วยแก้ปัญหาเร่งด่วนที่สุดในโลก
• งานของวิศวกรอาวุโสคืออะไร? คุณต้องเป็นมากกว่าแค่ผู้สนับสนุนรายบุคคล
• ตั้งแต่การเข้ารหัสบัณฑิต Bootcamp ไปจนถึงการสร้างฐานข้อมูลแบบกระจาย
  • อ่านหนังสือ (และเอกสาร) ไม่ใช่บล็อกโพสต์
  • รับผิดชอบวิถีอาชีพของคุณ
• - วิศวกรโค้งมนที่ดีมีคำแนะนำหนังสือที่ยอดเยี่ยมมากมาย
  • Paradigm Polyglot (เรียนรู้ภาษาและกระบวนทัศน์ที่แตกต่างกัน)
  • Polyglot ฐานข้อมูล
  • โปรโตคอล Polyglot (ควรใช้ TCP/IP และ HTTP)
  • ความสามารถด้วยการสร้างเครื่องมือบรรจุภัณฑ์และการจัดจำหน่าย
  • การดีบักการสังเกต
  • การติดตั้งอินฟาและ DevOps
  • สถาปัตยกรรมซอฟต์แวร์และการปรับขนาด
  • ความสามารถในการเขียนคอมไพเลอร์ของเล่นล่ามและตัวแยกวิเคราะห์
  • ความสามารถในการเขียนเกมของเล่น
  • ความสามารถในการเข้าใจการวิเคราะห์อัลกอริทึม
• คำแนะนำด้านอาชีพบางอย่างจะ Larson
  • คำแนะนำที่คุณได้รับคือความพยายามของใครบางคนในการสังเคราะห์ประสบการณ์ของพวกเขาไม่ใช่คำพูดที่ถูกต้องเกี่ยวกับวิธีการทำงานของโลก
  • สร้างอ่างเก็บน้ำแห่งศักดิ์ศรี
  • บางคนเก่งในสิ่งที่พวกเขาจบลงด้วยการไม่สามารถถูกแทนที่ในบทบาทปัจจุบันของพวกเขาซึ่งทำให้พวกเขาติดอยู่ในบทบาทของพวกเขาแม้ว่าพวกเขาจะเป็นผู้สมัครที่ดีสำหรับคนที่น่าสนใจมากขึ้น
  • ความสัมพันธ์ที่ดีจะติดตามคุณทุกที่ที่คุณไป คนเลวด้วย
  • ในช่วงต้นอาชีพของคุณพยายามที่จะทำงานกับ บริษัท หลายประเภทและในแนวดิ่งของผลิตภัณฑ์ที่แตกต่างกันเท่าที่จะทำได้
• เคล็ดลับชั่วร้าย: หลีกเลี่ยงสิ่งที่ "ง่าย"
• รหัสที่ดีที่สุด kata
• ลักษณะของวิศวกรซอฟต์แวร์อาวุโส: ผลกระทบ, การรับรู้, การมองเห็น, อิทธิพล, การให้คำปรึกษา
• วิศวกรรมซอฟต์แวร์ - ชิ้นส่วนที่อ่อนนุ่ม
  • คิดอย่างมีวิจารณญาณและกำหนดข้อโต้แย้งที่มีเหตุผลอย่างดี
  • เป็นหลักพื้นฐาน
  • มุ่งเน้นไปที่ผู้ใช้และสิ่งอื่น ๆ จะตามมา
  • เรียนรู้วิธีการเรียนรู้
• วิธีการเป็นเจ้าของการเติบโตของคุณในฐานะวิศวกรซอฟต์แวร์
• โปรแกรมเมอร์สี่สิบปี
  • ยิ่งคุณได้รับดีเท่าไหร่คุณก็ยิ่งดูเหมือนคนอื่นน้อยลงเท่านั้น
  • คุณเรียนรู้หลักการลึกโดยการทำพื้นฐาน
  • มองไปที่สาขาอื่นเรียนรู้จากสาขาอื่น ๆ
  • ระวังเกี่ยวกับเคล็ดลับการผลิต
• วิศวกรอาวุโสอาศัยอยู่ในอนาคต
• แผนที่อาชีพของคุณจะเป็นอย่างไร?
• จะประสบความสำเร็จได้อย่างไรที่ Amazon (หรือ บริษัท ขนาดใหญ่อื่น ๆ สำหรับเรื่องนั้น)

เกี่ยวกับวิศวกรอาวุโส:

• นักพัฒนาจูเนียร์เท็จเชื่อเกี่ยวกับการเป็นรุ่นพี่

การเลือกโอกาสครั้งต่อไป/ครั้งแรกของคุณ

• การตัดสินใจอาชีพ - โดย Elad Gil - Elad Blog

ไปหาพนักงาน Eng

• ฉันกลายเป็นวิศวกรพนักงาน FAANG ใน 5 ปี นี่คือ 14 บทเรียนที่ฉันเรียนรู้ไปพร้อมกัน
  • วิศวกรรมซอฟต์แวร์ไม่ได้เป็นเพียงแค่การเข้ารหัส ที่จริงแล้วการเข้ารหัสเป็นส่วนเล็ก ๆ ของมัน
  • ไปป์ไลน์งานของคุณ
  • เปิดรับข้อเสนอแนะและฟัง ชอบฟังอย่างจริงจัง
  • ข้อเสนอแนะที่ยอดเยี่ยมหายาก สมบัติ
  • จับตาดูขอบฟ้า (แต่ไม่ใช่ทั้งคู่)
  • คิดออกว่าอะไรสำคัญและปล่อยให้ส่วนที่เหลือไป
  • การเปรียบเทียบจริงๆคือขโมยแห่งความสุข
  • การให้คำปรึกษาเป็นสิ่งที่สวยงาม
  • โดยทั่วไปวันที่ดีอย่าเพิ่ง“ เกิดขึ้น”
  • คำแนะนำและคำแนะนำเป็นเพียงแค่นั้น พวกเขาไม่ใช่กฎ
• คู่มือสำหรับการเข้าถึงบทบาททางวิศวกรรมของพนักงานบวก Will Larson
  • มองเห็นได้
  • ทรัพยากรเพิ่มเติมเกี่ยวกับวิศวกรรมพนักงานบวก

ชุดอักขระ

• ขั้นต่ำสุดขั้นต่ำนักพัฒนาซอฟต์แวร์ทุกคนอย่างแน่นอนต้องรู้เกี่ยวกับชุด Unicode และชุดอักขระ (ไม่มีข้อแก้ตัว!)
• ขั้นต่ำสุดขั้นต่ำนักพัฒนาซอฟต์แวร์ทุกคนต้องรู้เกี่ยวกับ Unicode ในปี 2023 (ยังไม่มีข้อแก้ตัว!)

หมากรุก

(ใช่ - หมากรุกได้รับส่วนของตัวเอง :)

• Wiki Chessprogramming
• การบีบอัดหมากรุกเคลื่อนไหว

เมฆ

• Open-Guide/OG-AWS: คู่มือที่ใช้งานได้จริงสำหรับ AWS

บทวิจารณ์รหัส

• วิธีการตรวจสอบรหัสเอกสารการปฏิบัติทางวิศวกรรมของ Google
• บทวิจารณ์หลังการรีวิว: แนวคิดที่น่าสนใจในการเพิ่มความเร็วของนักพัฒนา (มีข้อแม้บางอย่าง)
• วิธีทำให้ผู้ตรวจสอบรหัสของคุณตกหลุมรักคุณ
  • ตรวจสอบรหัสของคุณเองก่อน
  • เขียนคำอธิบายการเปลี่ยนแปลงที่ชัดเจน
  • ทำให้สิ่งง่าย ๆ เป็นไปโดยอัตโนมัติ
  • ตอบคำถามด้วยรหัสเอง
  • การเปลี่ยนแปลงขอบเขตแคบ ๆ
  • แยกการเปลี่ยนแปลงการทำงานและไม่ใช้งาน
  • ตอบโต้การวิพากษ์วิจารณ์อย่างสง่างาม
  • เรียกร้องข้อมูลที่ขาดหายไปอย่างมีศิลปะ
  • มอบความสัมพันธ์ทั้งหมดให้กับผู้ตรวจสอบของคุณ
  • ลดความล่าช้าระหว่างรอบการตรวจสอบ
• วิธีทำรีวิวรหัสเช่นมนุษย์
• ถาม HN: คุณจะตรวจสอบรหัสได้อย่างไร: การสนทนาที่ยอดเยี่ยมเกี่ยวกับ HackerNews เต็มไปด้วยแนวคิดที่น่าสนใจ
• พีระมิดของ Maslow บทวิจารณ์รหัส
  • อีกหนึ่งในหัวข้อเดียวกัน: การตรวจสอบรหัสพีระมิด
• การตรวจสอบรหัสในทีมระยะไกล: ชุดกฎที่สมบูรณ์มาก
• ไม่มีการตรวจสอบรหัสตามค่าเริ่มต้น
  • ความรับผิดชอบเหนืออนุสัญญา

คุณภาพการเขียนโค้ดและรหัส

• เขียนรหัสที่ง่ายต่อการลบไม่ใช่เรื่องง่ายที่จะขยาย
• บัญญัติสิบประการของการเขียนโปรแกรม Egoless
• Clean Code: คู่มือของงานฝีมือซอฟต์แวร์ Agile, Robert C. Martin อธิบายแนวทางปฏิบัติที่ดีที่สุดที่มีประโยชน์มากมาย ยาวไปหน่อย นอกจากนี้ยังมีรหัสโกงรหัสที่สะอาด
• งานฝีมือซอฟต์แวร์อะไรเกี่ยวกับ
  • เราเบื่อที่จะเขียนอึ
  • เราจะไม่ยอมรับคำโกหกที่โง่เขลาเกี่ยวกับการทำความสะอาดในภายหลัง
  • เราจะไม่เชื่อว่าการอ้างสิทธิ์อย่างรวดเร็วหมายถึงสกปรก
  • เราจะไม่อนุญาตให้ใครบังคับให้เราทำตัวไม่เป็นมืออาชีพ
• เคล็ดลับในการตั้งชื่อตัวแปรบูลีน
  • มีการประชุมตัวแปรบูลีนนำหน้าและชื่อฟังก์ชันที่มี "คือ" หรือ "มี"
  • พยายามใช้เสมอคือแม้กระทั่งสำหรับ plurals ( isEachUserLoggedIn ดีกว่า areUsersLoggedIn หรือ isUsersLoggedIn )
  • หลีกเลี่ยงคำนำหน้าแบบกำหนดเอง ( isPaidFor ดีกว่า wasPaidFor )
  • หลีกเลี่ยงเชิงลบ ( isEnabled ดีกว่า isDisabled )
• วิธีการเขียนรหัสที่ไม่สามารถแก้ไขได้
• Kettanaito/Naming-Cheatsheet :: แนวทางภาษาที่ครอบคลุมเกี่ยวกับการตั้งชื่อตัวแปร บ้านของรูปแบบ A/HC/LC
• - คู่มือวิศวกรรมคุณภาพ

การสื่อสาร

ดูส่วนการเขียนด้วย

• วิธีการสื่อสารอย่างมีประสิทธิภาพในฐานะนักพัฒนา
  • คำแนะนำและตัวอย่างที่เป็นรูปธรรมมากมายสำหรับการเขียนระยะสั้นปานกลางและยาว
• คุณเห็นภาพอะไรในขณะที่การเขียนโปรแกรม?

ผู้รวบรวม

• หน้าทรัพยากรผู้เขียนคอมไพเลอร์
• Kanaka/Mal: Mal - Make a Lisp

การกำหนดค่า

• ข้อเสียของ JSON สำหรับไฟล์ config, Martin Tournoij
  • ไม่สามารถเพิ่มความคิดเห็นได้
  • ใบเสนอราคาและเสียงไวยากรณ์ที่มากเกินไป
  • การใช้ DC (การกำหนดค่าประกาศ) เพื่อควบคุมตรรกะมักไม่ใช่ความคิดที่ดี
• การกำหนดค่าของคุณดูด? ลองใช้ภาษาการเขียนโปรแกรมที่แท้จริง
  • รูปแบบการกำหนดค่าที่ทันสมัยที่สุดดูด
  • ใช้ภาษาการเขียนโปรแกรมจริง

การรวมอย่างต่อเนื่อง (CI)

• การบูรณาการอย่างต่อเนื่อง martinfowler.com

ฐานข้อมูล

ดูส่วน SQL

• บทนำภาษาอังกฤษธรรมดาเกี่ยวกับทฤษฎีบทหมวก
• ทฤษฎีบท Pacelc: "ในกรณีของการแบ่งพาร์ติชันเครือข่าย (P) ในระบบคอมพิวเตอร์แบบกระจายเราต้องเลือกระหว่างความพร้อมใช้งาน (a) และความสอดคล้อง (c) (ตามทฤษฎีบทหมวก) แต่อื่น ๆ (e) แม้ในขณะที่ระบบ กำลังทำงานตามปกติในกรณีที่ไม่มีพาร์ทิชันเราต้องเลือกระหว่างเวลาแฝง (L) และความสอดคล้อง (C) "
• การโยกย้ายฐานข้อมูลการหยุดทำงานเป็นศูนย์ (ตัวอย่างรหัสกำลังใช้ราง แต่ใช้งานได้ดีสำหรับภาษาการเขียนโปรแกรมใด ๆ )
• อัลกอริทึมที่อยู่เบื้องหลังระบบจัดเก็บข้อมูลที่ทันสมัย ​​ACM คิวคิว
• มาสร้างฐานข้อมูลอย่างง่าย
• การอ่านในระบบฐานข้อมูลรุ่นที่ 5
• การเปรียบเทียบประเภทฐานข้อมูล: ประเภทฐานข้อมูลพัฒนาเพื่อตอบสนองความต้องการที่แตกต่างกันอย่างไร
• ฐานข้อมูลเชิงสัมพันธ์ทำงานอย่างไร
• ใช้ดัชนีลุค
• บทนำหลักสูตร - MySQL สำหรับนักพัฒนา PlanetScale
• เครื่องยนต์แบบสอบถามทำงานอย่างไร
• ทำไมคุณถึงควรใช้ sqlite | Epic Web Dev

nosql

• รูปแบบ NOSQL
• ฐานข้อมูล NOSQL: การสำรวจและคำแนะนำการตัดสินใจ
• เอกสาร DynamoDB มีหน้ายอดเยี่ยม:
  • อ่านความสม่ำเสมอ
  • จาก SQL ถึง NOSQL
  • การออกแบบ NOSQL สำหรับ DynamoDB
• Redis อธิบาย

Postgres

• การดำเนินงานที่ปลอดภัยสำหรับ PostgreSQL ที่มีปริมาณสูง (นี่คือ PostgreSQL แต่ใช้งานได้ดีสำหรับ DBS อื่น ๆ เช่นกัน)
• การแยกธุรกรรมใน postgres อธิบาย
• แบบฝึกหัด PostgreSQL
• Postgres Operations Cheat Sheet
• เพียงแค่ใช้ postgres
• Postgres เพียงพอ
• Postgres: อย่าทำเช่นนี้
• PostgreSQL และ UUID เป็นคีย์หลัก

รูปแบบข้อมูล

• โปรแกรมเมอร์เท็จเชื่อเกี่ยวกับหมายเลขโทรศัพท์ libphonenumber ของ Google
• กฎสำหรับการเติมข้อความอัตโนมัติ: ข้อมูลจำเพาะคร่าวๆสำหรับฟิลด์การเติมข้อความอัตโนมัติ
• โปรแกรมเมอร์เท็จเชื่อเกี่ยวกับที่อยู่
• โปรแกรมเมอร์เท็จเชื่อเกี่ยวกับชื่อ
• Kdeldycke/Awesome-Falsehood: โปรแกรมเมอร์เท็จเชื่อใน
• ทำความเข้าใจกับ uuids, ulids และการเป็นตัวแทนสตริง
• โปรแกรมเมอร์เท็จเชื่อเกี่ยวกับรายการเท็จ
• ออสเตรเลีย/Lord_Howe เป็นเขตเวลาที่แปลกประหลาดที่สุด

วิทยาศาสตร์ข้อมูล/วิศวกรรมข้อมูล

• โหลสกปรก: ข้อผิดพลาดการตีความการวัดทั่วไปสิบสองข้อผิดพลาดในการทดลองควบคุมออนไลน์
• DataStackTV/Data-Engineer-Roadmap: Roadmap เพื่อเป็นวิศวกรข้อมูล
• เส้นทางการเรียนรู้วิศวกรรมข้อมูลที่ยอดเยี่ยม
• สถาปัตยกรรมที่เกิดขึ้นใหม่สำหรับโครงสร้างพื้นฐานข้อมูลที่ทันสมัย
• วิธีการย้ายเกินทะเลสาบข้อมูลเสาหินไปยังตาข่ายข้อมูลแบบกระจาย
  • แพลตฟอร์มข้อมูลตามสถาปัตยกรรม Data Lake มีโหมดความล้มเหลวทั่วไปที่นำไปสู่สัญญาที่ไม่ได้ผล
  • เราจำเป็นต้องพิจารณาโดเมนเป็นข้อกังวลชั้นหนึ่งใช้การคิดแพลตฟอร์มเพื่อสร้างโครงสร้างพื้นฐานข้อมูลแบบบริการตนเองและปฏิบัติต่อข้อมูลเป็นผลิตภัณฑ์
• Mlops
• แพลตฟอร์มข้อมูลขนาดใหญ่ของ Uber: 100+ petabytes พร้อมเวลาแฝงนาที
• SQL ควรเป็นตัวเลือกเริ่มต้นสำหรับตรรกะการแปลงข้อมูล

การดีบัก

ดูส่วนการตอบสนองเหตุการณ์ในเอกสารนี้ด้วย

• การแก้ปัญหาเป็ดยาง
• เป็ดยาง
• ห้า Whys
• การวิเคราะห์การโกหกทั้งห้า
  • ปัญหาที่แท้จริงเปิดเผยตัวเองเมื่อเทคนิคกลายเป็นส่วนหนึ่งของเทมเพลต
  • รายการการดำเนินการอาจอยู่ห่างไกลจากสาเหตุของราก
• วิธีที่ไม่มีที่สิ้นสุดได้วิพากษ์วิจารณ์วิธีการทั้งห้าและผู้สนับสนุนสำหรับชุดคำถามที่แตกต่างกันเพื่อเรียนรู้จากเหตุการณ์ที่เกิดขึ้นมากที่สุด
  • ดูเพิ่มเติมที่: ข้อผิดพลาดของมนุษย์: แบบจำลองและการจัดการ
  • "ปัญหาเกี่ยวกับห้า whys คือมันเป็นคำอธิบายเชิงเส้นเป็นคำอธิบายเชิงเส้นและง่ายเกี่ยวกับวิธีการทำงานและเหตุการณ์ที่เกิดขึ้น"
  • "ความผิดพลาดของมนุษย์กลายเป็นจุดเริ่มต้นไม่ใช่ข้อสรุป" (Dekker, 2009)
  • "เมื่อเราถามว่า 'อย่างไร' เรากำลังขอเรื่องเล่า"
  • "เมื่อพูดถึงการตัดสินใจและการกระทำเราต้องการทราบว่ามันสมเหตุสมผลสำหรับใครบางคนที่จะทำสิ่งที่พวกเขาทำ"
  • ในแต่ละขั้นตอน "ทำไม" จะเลือกคำตอบเดียวเท่านั้นสำหรับการสอบสวนเพิ่มเติม ถามว่า "วิธีการ" ส่งเสริมการสำรวจที่กว้างขึ้น
  • "ในการสอบสวนอุบัติเหตุเช่นเดียวกับความพยายามของมนุษย์ส่วนใหญ่เราตกเป็นเหยื่อของสิ่งที่คุณมองหามา-คุณ-ค้นหาหรือหลักการของ Wylfiwyf นี่คือการรับรู้อย่างง่าย การไปดู (สิ่งที่คุณมอง) ในระดับใหญ่จะเป็นตัวกำหนดสิ่งที่เราพบจริง (สิ่งที่คุณค้นหา) " (Hollnagel, 2009, p. 85) (see illustration of WYLFIWYF)
  • "A final reason why a 'root cause' may be selected is that it is politically acceptable as the identified cause. Other events or explanations may be excluded or not examined in depth because they raise issues that are embarrassing to the organization or its contractors or are politically unacceptable." (Nancy Leveson, Engineering a Safer World, p. 20)
  • Bounded rationality: rational individuals will select a decision that is satisfactory rather than optimal
  • The article provide concrete ways and questions to solicit stories from people, which will yield better insights.
    • What were you expecting to happen?
    • If you had to describe the situation to your colleague at that point, what would you have told?
    • Did this situation fit a standard scenario?
    • What were you trying to achieve?Were there multiple goals at the same time?Was there time pressure or other limitations on what you could do?
    • See template here
• Linux Performance Analysis in 60,000 Milliseconds
• Post-Mortems at HubSpot: What I Learned From 250 Whys
• Debugging zine, Julian Evans
• If you understand a bug, you can fix it
• The Thirty Minute Rule: if anyone gets stuck on something for more than 30 minutes, they should ask for help
• How to create a Minimal, Reproducible Example , Stack Overflow
• Some ways to get better at debugging, Julia Evans
  • Learn the codebase
  • Learn the system (eg, HTTP stack, database transactions)
  • Learn your tools (eg, strace , tcpdump )
  • Learn strategies (eg, writing code to reproduce, adding logging, taking a break)
  • Get experience: according to a study, "experts simply formed more correct hypotheses and were more efficient at finding the fault."
• What exactly is the 'Saff Squeeze' method of finding a bug?
  • A systematic technique for deleting both test code and non-test code from a failing test until the test and code are small enough to understand.
• tcpdump is amazing, Julia Evans
• What we talk about when we talk about 'root cause'

Design (visual, UX, UI, typography)

I highly recommend reading The Non-Designer's Design Book. This is a pretty short book that will give you some very actionable design advices.

• If you're working on data, Edward Tufte's The Visual Display of Quantitative Information is considered a classic.
• The Universal Principles of Design will give you enough vocabulary and concepts to describe design challenges into words.
• Book recommendations from HackerNews
• ?Design for Non-Designers

Articles :

• 10 Usability Heuristics Every Designer Should Know
  • Visibility of System Status
  • The Match Between The System And The Real World
  • Every system should have a clear emergency exit
  • Don't forget that people spend 90% of their time interacting with other apps
  • Recognition Rather Than Recall (recognition = shallow form of retrieval from memory, eg a familiar person, recall = deeper retrieval)
  • ”Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery
  • Help Users Recognize, Diagnose, And Recover From Errors
• How to pick more beautiful colors for your data visualizations
• Visual design rules you can safely follow every time

Typograhy: see "Typography" section

ทรัพยากร:

• - bradtraversy/design-resources-for-developers: design and UI resources from stock photos, web templates, CSS frameworks, UI libraries, tools...

Design (OO modeling, architecture, patterns, anti-patterns, etc.)

Here's a list of good books:

• Design Patterns: Elements of Reusable Object-Oriented Software: dubbed "the gang of four", this is almost a required reading for any developer. A lot of those are a bit overkill for Python (because everything is an object, and dynamic typing), but the main idea (composition is better than inheritance) definitely is a good philosophy.
  • And their nefarious nemesis Resign Patterns
• Patterns of Enterprise Application Architecture: learn about how database are used in real world applications. Mike Bayer's SQLAlchemy has been heavily influenced by this book.
• Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans
• Clean Architecture, Robert C. Martin. Uncle Bob proposes an architecture that leverages the Single Responsibility Principle to its fullest. A great way to start a new codebase. Also checkout the clean architecture cheatsheet and this article.
• Game Programming Patterns: a book about design, sequencing, behavioral patterns and much more by Robert Nystrom explained through the medium of game programming. The book is also free to read online here.

One of the absolute references on architecture is Martin Fowler: checkout his Software Architecture Guide.

Articles:

• O'Reilly's How to make mistakes in Python
• Education of a Programmer: a developer's thoughts after 35 years in the industry. There's a particularly good section about design & complexity (see "the end to end argument", "layering and componentization").
• Domain-driven design, Wikipedia.
• On the Spectrum of Abstraction ?, Cheng Lou
• The “Bug-O” Notation, Dan Abramov
• Antipatterns
• Inheritance vs. composition: a concrete example in Python. Another slightly longer one here. One last one, in Python 3.
• Composition Instead Of Inheritance
• Complexity and Strategy: interesting perspective on complexity and flexibility with really good examples (eg Google Apps Suite vs. Microsoft Office).
• The Architecture of Open Source Applications
• The Robustness Principle Reconsidered
  • Jon Postel: "Be conservative in what you do, be liberal in what you accept from others." (RFC 793)
  • Two general problem areas are impacted by the Robustness Principle: orderly interoperability and security.
• Basics of the Unix Philosophy, Eric S Raymond
• Eight Habits of Expert Software Designers: An Illustrated Guide

You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)

ทรัพยากร:

• - Design Principles

Design: database schema

• A humble guide to database schema design, Mike Alche
  • Use at least third normal form
  • Create a last line of defense with constraints
  • Never store full addresses in a single field
  • Never store firstname and lastname in the same field
  • Establish conventions for table and field names.

Design: patterns

• KeystoneInterface, Martin Fowler.
  • Build all the back-end code, integrate, but don't build the user-interface
• 101 Design Patterns & Tips for Developers
• Python Design Patterns: For Sleek And Fashionable Code: a pretty simple introduction to common design patterns (Facade, Adapter, Decorator). A more complete list of design patterns implementation in Python on Github.
• SourceMaking's Design Patterns seems to be a good web resource too.
• Anti-If: The missing patterns

Design: simplicity

• Simple Made Easy ?, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.

Dev environment & tools

• - Awesome Dev Env

เครื่องมือ

• Glances: An eye on your system
• HTTPie: a CLI, cURL-like tool for humans
• jq: command-line JSON processor
• tmux: terminal multiplexer
• htop: an interactive process viewer for Linux
• htop explained
• socat
• Visual guide to SSH tunnels
• casey/just: a command runner written in Rust (claims to be better than Makefile)
• Gazr: an opinionated way to define your Makefile

Article about tools:

• The return of fancy tools
  • Simple tools make you think a little more
  • Drucker: "I'm not writing it down to remember it later, I'm writing it down to remember it now."
  • Frictionless note-taking produces notes, but it doesn't produce memory.

นักเทียบท่า

See also the Python-specific section in charlax/python-education.

• Best Practices Around Production Ready Web Apps with Docker Compose
  • Avoiding 2 Compose Files for Dev and Prod with an Override File
  • Reducing Service Duplication with Aliases and Anchors
  • Defining your HEALTHCHECK in Docker Compose not your Dockerfile
  • Making the most of environment variables
  • Using Multi-stage builds to optimize image size
  • Running your container as a non-root user
• Docker Best Practices for Python Developers
  • Use multi-stage builds
  • Pay close attention to the order of your Dockerfile commands to leverage layer caching
  • Smaller Docker images are more modular and secure (watch out for Alpine though)
  • Minimize the number of layers ( RUN , COPY , ADD )
  • Use unprivileged containers
  • Prefer COPY over ADD
  • Cache python packages to the docker host
  • Prefer array over string syntax
  • Understand the difference between ENTRYPOINT and CMD
  • Include a HEALTHCHECK instruction
  • Whenever possible, avoid using the latest tag.
  • Don't store secrets in images
  • Use a .dockerignore file (include **/.git , etc.)
  • Lint and Scan Your Dockerfiles and Images (eg with hadolint )
  • Log to stdout or stderr
• Docker Containers Security

เอกสาร

• Documentation-Driven Development
• Writing automated tests for your documentation: this should be required, IMO. Testing code samples in your documentation ensures they never get outdated.
• - Documentation is king, Kenneth Reitz
• Keep a Changelog
• Architectural Decision Records (ADR): a way to document architecture decision.
• Documenting Architecture Decisions
• joelparkerhenderson/architecture-decision-record: examples and templates for ADR.
  • And a CLI tool: npryce/adr-tools
• The documentation system
• Checklist for checklists
• Best practices for writing code comments
• Always be quitting
  • Document your knowledge
  • Train your replacement
  • Delegate
  • By being disposable, you free yourself to work on high-impact projects.
• Write documentation first. Then build.
• Diátaxis: a systematic approach to technical documentation authoring
  • There are four modes: tutorials, how-to guides, technical reference and explanation
  • The docs goes into a lot of details about each model.
• ARCHITECTURE.md
• Two open source projects with great documentation (esbuild and redis)

The palest ink is more reliable than the most powerful memory. -- Chinese proverb

Dotfiles

• - Awesome dotfiles: lots of great dotfiles.
• My dotfiles

บทความ

• Setting Up a Mac Dev Machine From Zero to Hero With Dotfiles

Editors & IDE

• Sublime Text essential plugins and resources
• Bram Moolenaar (Vim author), Seven habits of effective text editing (presentation). This is about Vim but it contains good lessons about why investing time in learning how to be productive with your text editors pays off.
• VScode is one of the most popular text editors as of writing.
  • Visual Studio Code Can Do That?, Smashing Magazine.
• Coding with Character

Vim

• - vim-awesome
• - Vimcasts
• ️ Is Vim Really Not For You? A Beginner Guide
  • The first part of a series of 6 articles with lots of detailed and practical tips for using Vim efficiently.
  • A Vim Guide for Advanced Users: more advanced shortcuts and commands
• Learning the vi and Vim Editors
• Practical Vim, Drew Neil
• Learn Vimscript the Hard Way
• VimGolf: nice challenges to learn Vim
• Vim anti-patterns
• Learn Vim For the Last Time: A Tutorial and Primer
• Vim Cheat Sheet & Quick Reference
• History and effective use of Vim
• Moving Blazingly Fast With The Core Vim Motions
• micahkepe/vimtutor-sequel: Vimtutor Sequel - Advanced Vim Tutor Lessons
• Vim Racer - An Online Game for VIM Navigation

Feel free to check my vim configuration and my vim cheatsheet.

Other editors:

• Use GNU Emacs

อีเมล

• Email explained from first principles
• - Transactional Email Best Practices

Engineering management

Checkout my list of management resources.

Exercises

The best way to learn is to learn by doing.

• build-your-own-x: compilation of well-written, step-by-step guides for re-creating our favorite technologies from scratch
  • Richard Feynman: "what I cannot create, I do not understand"
• The elevator programming game
• Challenging projects every programmer should try, Austin Z. Henley
• Challenging projects every programmer should try: text editor, space invaders, compiler (Tiny Basic), mini OS, spreadsheet, video game console emulator.
• More challenging projects every programmer should try: ray tracer, key-value store web API, web browser, stock trading bot.
• Let's Build a Regex Engine
• Write a time-series database engine from scratch
• 7 GUIs to build to learn fundamental UI programming skills
• A list of programming playgrounds, Julia Evans
• Write more "useless" software

ฝึกฝน:

• CodinGame
• Codewars
• การออกกำลังกาย

Experimentation

• 8 annoying A/B testing mistakes every engineer should know

Functional programming (FP)

• Goodbye, Object Oriented Programming
• Functional Programming & Haskell ?: some good reasons to learn FP!
• Functional Programming Fundamentals: short introduction to FP and its advantages.
• OO vs FP, Robert C. Martin, The Clean Code Blog. A pretty interesting take on the differences between OOP and FP from an expert in OOP.
  • OO is not about state. Objects are bags of functions, not bags of data.
  • Functional Programs, like OO Programs, are composed of functions that operate on data.
  • FP imposes discipline upon assignment.
  • OO imposes discipline on function pointers.
  • The principles of software design still apply, regardless of your programming style. The fact that you've decided to use a language that doesn't have an assignment operator does not mean that you can ignore the Single Responsibility Principle.
• Parse, don't validate
  • Use a data structure that makes illegal states unrepresentable
  • Push the burden of proof upward as far as possible, but no further
  • Let your datatypes inform your code, don't let your code control your datatypes
  • Don't be afraid to parse data in multiple passes
  • Avoid denormalized representations of data, especially if it's mutable
  • Use abstract datatypes to make validators “look like” parsers
• - การเขียนโปรแกรมฟังก์ชั่น
• Monads in 15 minutes
• hemanth/functional-programming-jargon: jargon from the functional programming world in simple terms
• The definitive guide to learning functional programming, Exercism

Games development

• Introduction · Joys of Small Game Development

กราฟิก

• Text Rendering Hates You

ฮาร์ดแวร์

• NandGame: build a computer from scratch.
• What Every Programmer Should Know About SSDs
• How To Make A CPU - A Simple Picture Based Explanation

http

• Choosing an HTTP Status Code — Stop Making It Hard
• HTTPWTF
• 10 Surprising Things You Didn't Know About HTTP
• The HTTP crash course nobody asked for

อารมณ์ขัน

• The Jeff Dean Facts
  • Compilers don't warn Jeff Dean. Jeff Dean warns compilers.
  • Unsatisfied with constant time, Jeff Dean created the world's first O(1/N) algorithm.
  • Jeff Dean mines bitcoins. In his head.
• The Daily WTF: Curious Perversions in Information Technology

Incident response (oncall, alerting, outages, firefighting, postmortem)

Also see this section on my list of management resources, "Incident response".

Also see the Debugging section in this doc.

• Incident Response at Heroku
  • Described the Incident Commander role, inspired by natural disaster incident response.
  • Also in presentation: Incident Response Patterns: What we have learned at PagerDuty - Speaker Deck
• The Google SRE book's chapter about oncall
• Writing Runbook Documentation When You're An SRE
  • Playbooks “reduce stress, the mean time to repair (MTTR), and the risk of human error.”
  • Using a template can be beneficial because starting from a blank document is incredibly hard.
  • The Curse of Knowledge is a cognitive bias that occurs when someone is communicating with others and unknowingly assumes the level of knowledge of the people they are communicating with.
  • Make your content easy to glance over.
  • If a script is longer than a single line, treat it like code, and check it into a repository to be source control and potentially tested.
• Incident Review and Postmortem Best Practices, Gergely Orosz
• Computer Security Incident Handling Guide, NIST
• Incident Management Resources, Carnegie Mellon University
• Sterile flight deck rule, Wikipedia
• Shamir Secret Sharing It's 3am.
• Site Reliability Engineering and the Art of Improvisation has lots of good training ideas
  • Walkthroughs of observability toolsets
  • Decision requirements table building
  • Team knowledge elicitation
  • Asking the question, “Why do we have on-call?”
  • Spin the Wheel of Expertise!

Alerting:

• My Philosophy On Alerting
  • Pages should be urgent, important, actionable, and real.
  • Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
  • Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
  • Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
  • The further up your serving stack you go, the more distinct problems you catch in a single rule. But don't go so far you can't sufficiently distinguish what's going on.
  • If you want a quiet oncall rotation, it's imperative to have a system for dealing with things that need timely response, but are not imminently critical.
  • This classical article has now become a chapter in Google's SRE book.
• - The Paradox of Alerts: why deleting 90% of your paging alerts can make your systems better, and how to craft an on-call rotation that engineers are happy to join.

Postmortem

• A great example of a postmortem from Gitlab (01/31/2017) for an outage during which an engineer's action caused the irremediable loss of 6 hours of data.
• Blameless PostMortems and a Just Culture
• A list of postmortems on Github
• Google's SRE book, Postmortem chapter is excellent and includes many examples.
• Human error models and management
  • High reliability organisations — which have less than their fair share of accidents — recognise that human variability is a force to harness in averting errors, but they work hard to focus that variability and are constantly preoccupied with the possibility of failure

"Let's plan for a future where we're all as stupid as we are today."

– Dan Milstein

Example outline for a postmortem:

• Executive Summary
  • ผลกระทบ
  • Root cause
• ผลกระทบ
  • Number of impacted users
  • Lost revenue
  • ระยะเวลา
  • Team impact
• Timeline
  • Detection
  • ปณิธาน
• Root cause analysis
  • Eg with 5 whys method
• Lessons learned
  • Things that went well
  • Things that went poorly
• Action items (include direct links to task tracking tool)
  • Tasks to improve prevention (including training)
  • Tasks to improve detection (including monitoring and alerting)
  • Tasks to improve mitigation (including emergency response)

อินเทอร์เน็ต

• How Does the Internet Work?
• How the web works
• Advice to young web developers

Interviewing

Note: this is about you as an interviewee, not as an interviewer. To check out my list of resources for interviewers, go to my engineering-management repository.

• System design interview for IT company
• Technical Interview Megarepo: study materials for SE/CS technical interviews
• How to Win the Coding Interview
• I spent 3 months applying to jobs after a coding bootcamp. Here's what I learned.
• Top 10 algorithms in Interview Questions
• Interactive Python coding interview challenges
• Tech Interview Handbook
• A complete computer science study plan to become a software engineer
• Interview advice that got me offers from Google, Microsoft, and Stripe
• A framework for grading your performance on programming interview problems
• Preparing for the Systems Design and Coding Interview, Gergely Orosz
• What I Learned from Doing 60+ Technical Interviews in 30 Days
• System Design Interview Guide for Senior Engineers, interviewing.io

Questions you should ask:

• Questions to ask your interviewer
• Questions to ask the company during your interview
• Interviewing the Interviewer: Questions to Uncover a Company's True Culture
• Twipped/InterviewThis: questions to ask prospective employers
• tBaxter/questions-for-employers: A big collection of useful questions to ask potential employers.

ประวัติย่อ:

• The Red Flags on Your Resume
• What we look for in a resume
  • We look for demonstrated expertise, not keywords
  • We look for people who get things done
  • We look for unique perspectives
  • We care about impact, not meaningless metrics
• Why you shouldn't list certifications on LinkedIn

See also the exercises section in this document.

Kubernetes

• OWASP/www-project-kubernetes-top-ten
• Kubernetes Tutorial for Beginners: Basic Concepts

Large Language Model (LLM)

• What Is ChatGPT Doing… and Why Does It Work?, Stephen Wolfram
• Embeddings: What they are and why they matter

Learning & memorizing

Learn how to learn!

• How I Rewired My Brain to Become Fluent in Math: subtitled the building blocks of understanding are memorization and repetition .
• One Sure-Fire Way to Improve Your Coding: reading code!
• Tips for learning programming
• You can increase your intelligence: 5 ways to maximize your cognitive potential: forgive the clickbait title, it's actually a good article.
• How to ask good questions, Julia Evans.
• Stop Learning Frameworks
• Learning How to Learn: powerful mental tools to help you master tough subjects
• Why books don't work, Andy Matuschak.
  • "As a medium, books are surprisingly bad at conveying knowledge, and readers mostly don't realize it."
  • "In learning sciences, we call this model “transmissionism.” It's the notion that knowledge can be directly transmitted from teacher to student, like transcribing text from one page onto another. If only!"
  • "By re-testing yourself on material you've learned over expanding intervals, you can cheaply and reliably commit huge volumes of information to long-term memory."
• Strategies, Tips, and Tricks for Anki: those advices work for any tool actually
  • Add images. Our brains are wired visually, so this helps retention.
  • Don't add things you don't understand.
  • Don't add cards memorizing entire lists.
  • Write it out. For wrong answers, I'll write it on paper. The act of writing is meditative. I really enjoy this.
  • Keep on asking yourself why? why does this work? why does it work this way? Force yourself to understand the root of a topic.
  • Cornell Method: when reading a topic, write out questions on the margins to quiz yourself.
  • Pretend you have to teach it
  • Use mnemonics phrases like PEMDAS for lists and other hard-to-remember topics.
  • Delete cards that don't make sense or you don't want to remember anymore.
• Effective learning: Twenty rules of formulating knowledge
  • Build upon the basics
  • Stick to the minimum information principle: the material you learn must be formulated in as simple way as it is
  • Cloze deletion is easy and effective: Kaleida's mission was to create a ... It finally produced one, called Script X. But it took three years
  • Graphic deletion is as good as cloze deletion
  • Avoid sets
  • Avoid enumerations
  • Combat interference - even the simplest items can be completely intractable if they are similar to other items. Use examples, context cues, vivid illustrations, refer to emotions, and to your personal life
  • Personalize and provide examples - personalization might be the most effective way of building upon other memories. Your personal life is a gold mine of facts and events to refer to. As long as you build a collection for yourself, use personalization richly to build upon well established memories
  • Provide sources - sources help you manage the learning process, updating your knowledge, judging its reliability, or importance
  • Prioritize - effective learning is all about prioritizing.
• How to Remember Anything You Really Want to Remember, Backed by Science
  • Quiz yourself
  • Summarize and share with someone else.
  • Connect what you just learned to experiences you previously had.
• How To Remember Anything Forever-ish: a comic about learning
• Get better at programming by learning how things work
• How to teach yourself hard things
• Building Your Own Personal Learning Curriculum
• Always do Extra
  • Extra is finishing those two screens, but then researching a new library for form validation that might reduce the boilerplate code.
  • Extra must be balanced against Normal Work.
  • Extra must be aligned with your Normal Work.
• Against 3X Speed
  • Lectures are most effective when they're only a component of the classroom experience
  • Learning is about spaced repetition, not binge-reading books
• The Problems with Deliberate Practice
• Why Tacit Knowledge is More Important Than Deliberate Practice
• In Praise of Memorization
  • You can't reason accurately without knowledge
  • Memorizing organized your knowledge
  • It stays with you
• Celebrate tiny learning milestones, Julia Evans.
  • Keep a brag document
  • You can do a lot "by accident"
  • Fixing a bug can be milestone
• Why writing by hand is still the best way to retain information, StackOverflow
• - Making Badass Developers - Kathy Sierra (Serious Pony) keynote
• How to study (with lots of cartoons from Calvin & Hobbes!)
  • Manage your time
  • Take notes in class & rewrite them at home
  • Study hard subjects first & study in a quiet place
  • Read actively & slowly, before & after class
  • Do your homework
  • Study for exams
  • Take Exams
  • Do research & write essays
  • Do I really have to do all this?
  • Are there other websites that give study hints?
• 10 Things Software Developers Should Learn about Learning
• - Things I Learned the Hard Way, Bryan Cantrill

About flashcards:

• Augmenting Long-term Memory
• How to write good prompts: using spaced repetition to create understanding - also includes lots of insightful research papers.
• Effective learning: Twenty rules of formulating knowledge
• Rules for Designing Precise Anki Cards
• Fernando Borretti, Effective Spaced Repetition
• Anki-fy Your Life gets into why it makes sense to invest in your memory.

About Zettelkasten and PKM (personal knowledge management): see Personal knowledge management

Richard Feynman's Learning Strategy:

1. Step 1: Continually ask "Why?”
2. Step 2: When you learn something, learn it to where you can explain it to a child.
3. Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.

Most people overestimate what they can do in 1 year and underestimate what they can do in a decade. – Bill Gates

Frankly, though, I think most people can learn a lot more than they think they can. They sell themselves short without trying. One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the details/leaves or there is nothing for them to hang on ถึง. — Elon Musk

"Experience is something you don't get until just after you need it." ― Steven Wright

Tell me and I forget. Teach me and I remember. Involve me and I learn. – Benjamin Franklin

Education is the kindling of a flame, not the filling of a vessel. – Socrates

That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. – Ralph Waldo Emerson

A wise man can learn more from a foolish question than a fool can learn from a wise answer. – Bruce Lee

A lecture has been well described as the process whereby the notes of the teacher become the notes of the student without passing through the mind of either. — Mortimer Adler

Fools learn from experience. I prefer to learn from the experience of others. — Bismark

Licenses (legal)

• Software Licenses in Plain English

Linux (system management)

• Welcome to Linux command line for you and me!
• Linux Performance, Brendan Gregg

Low-code/no-code

• How Levels.fyi scaled to millions of users with Google Sheets as a backend

Low-level, assembly

• Back to Basics, Joel Spolsky. Explains why learning low level programming is important.
  • I think that some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels.
• What's in a Linux executable?
• The Elements of Computing Systems: building a modern computer from first principles (nand2tetris).
• Old pattern powering modern tech
• Demystifying bitwise operations, a gentle C tutorial
• Understanding the Power of Bitwise Operators. No math needed
• Memory Allocation (an interactive article)
• Why does 0.1 + 0.2 = 0.30000000000000004?, Julia Evans (about floating point)
• Putting the "You" in CPU
• x86-64 Assembly Language Programming with Ubuntu

Machine learning/AI

• Transformers from Scratch

คณิตศาสตร์

• - Statistics for Hackers

Marketing

• goabstract/Marketing-for-Engineers

เครือข่าย

• The Great Confusion About URIs
  • A URI is a string of characters that identifies a resource. Its syntax is <scheme>:<authority><path>?<query>#<fragment> , where only <scheme> and <path> are mandatory. URL and URN are URIs.
  • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. Eg mailto:[email protected] .
  • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn:<namespace identifier>:<namespace specific string> . Eg urn:isbn:9780062301239
• Everything you need to know about DNS
• Examples of Great URL Design
• Four Cool URLs - Alex Pounds' Blog

Observability (monitoring, logging, exception handling)

See also: Site Reliability Engineering (SRE)

การตัดไม้

• Do not log dwells on some logging antipatterns.
  • Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
  • Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
  • Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
• Lies My Parents Told Me (About Logs)
  • Logs are cheap
  • I can run it better myself
  • Leveled logging is a great way to separate information
  • Logs are basically the same as events
  • A standard logging format is good enough
• Logging - OWASP Cheat Sheet Series
• The Audit Log Wall of Shame: list of vendors that don't prioritize high-quality, widely-available audit logs for security and operations teams.
• Guide on Structured Logs

Error/exception handling

• Error handling antipatterns in this repo.
• Writing Helpful Error Messages, Google Developers' course on Technical Writing
  • Explain the problem
  • Explain the solution
  • Write clearly

Metrics

• Meaningful availability
  • A good availability metric should be meaningful, proportional, and actionable. By "meaningful" we mean that it should capture what users experience. By "proportional" we mean that a change in the metric should be proportional to the change in user-perceived availability. By "actionable" we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfy these requirements…
• - Meaningful Availability paper.
  • This paper presents and evaluates a novel availability metric: windowed user-uptime

การตรวจ

• Google, Site Reliability Engineering, Monitoring Distributed Systems
  • Alerting on SLOs
• PagerDuty, Monitoring Business Metrics and Refining Outage Response
• - crazy-canux/awesome-monitoring: monitoring tools for operations.
• Monitoring in the time of Cloud Native
• How to Monitor the SRE Golden Signals
  • From the Google SRE book: Latency, Traffic, Errors, and Saturation
  • USE Method (from Brendan Gregg): Utilization, Saturation, and Errors
  • RED Method (from Tom Wilkie): Rate, Errors, and Duration
• Simple Anomaly Detection Using Plain SQL
• How percentile approximation works (and why it's more useful than averages)
• Implementing health checks
• IETF RFC Health Check Response Format for HTTP APIs

Open source

• Non-code contributions are the secret to open source success

Operating system (OS)

• The Linux Programming Interface: A Linux and UNIX System Programming Handbook: already mentioned above.
• Modern Operating Systems, Andrew Tanenbaum, Herbert Bos (not read)
• Operating Systems: Three Easy Pieces (free book, not read)
• Linux Kernel Development, Robert Love. A very complete introduction to developing within the Linux Kernel.
• The 10 Operating System Concepts Software Developers Need to Remember
• Play with xv6 on MIT 6.828
• macOS Internals

Over-engineering

• 10 modern software over-engineering mistakes
• A good example of over-engineering: the Juicero press (April 2017)
• You Are Not Google: the UNPHAT method to avoid cargo cult.
  • Don't even start considering solutions until you Understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
  • eNumerate multiple candidate solutions. Don't just start prodding at your favorite!
• Overthinking
  • 1st poison: education.
  • 2nd poison: marketing.
  • 3rd poison: ego
  • Solution: Stop trying to connect all the dots ahead of time. Embrace uncertainty and start doing.
• Don't Let Architecture Astronauts Scare You, Joel
  • Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
  • Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away.

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

— John Gall, General systemantics, an essay on how systems work, and especially how they fail..., 1975 (this quote is sometime referred as "Galls' law")

"Software engineering is what happens to programming when you add time and other programmers."

— Rob Pike, Go at Google: Language Design in the Service of Software Engineering

You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

— Steve Jobs

ผลงาน

• Numbers Everyone Should Know
• Latency numbers every programmer should know
• Rob Pike's 5 Rules of Programming
  • You can't tell where a program is going to spend its time.
  • วัด
  • Fancy algorithms are slow when n is small, and n is usually small.
  • Fancy algorithms are buggier than simple ones
  • Data dominates.
• Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust: a great way to learn about measuring performance.
• The Mathematical Hacker
• Four Kinds of Optimisation

Personal knowledge management (PKM)

• Zettelkasten Method
• How to build a second brain as a software developer
• Notes Against Note-Taking Systems
  • An interesting contrarian take!
  • I am waiting for any evidence that our most provocative thinkers and writers are those who rely on elaborate, systematic note-taking systems.
  • I am seeing evidence that people taught knowledge management for its own sake produce unexciting work.
• MaggieAppleton/digital-gardeners
• Notes apps are where ideas go to die. And that's good.

Personal productivity

Check out this section on my list of management resources, "Personal productivity".

ทัศนคติ

• At 31, I have just weeks to live. Here's what I want to pass on
  • First, the importance of gratitude.
  • Second, a life, if lived well, is long enough.
  • Third, it's important to let yourself be vulnerable and connect to others.
  • Fourth, do something for others.
  • Fifth, protect the planet.
• Life Is Not Short
  • "The most surprising thing is that you wouldn't let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable." — Seneca

ความเป็นส่วนตัว

• Privacy Enhancing Technologies: An Introduction for Technologists, Katharine Jarmul, MartinFowler.com

Problem solving

• Dealing with Hard Problems
• Invert, always, invert
  • Define the problem - what is it that you're trying to achieve?
  • Invert it - what would guarantee the failure to achieve this outcome?
  • Finally, consider solutions to avoid this failure
• - Hammock Driven Development, Rick Hickey
  • A classic talk on problem solving.

Product management for software engineers

See the Product management section on my entrepreneurship-resources list of resources.

• Checkout this newsletter produced by Posthog: Product for Engineers

Project management

See the Project management section on my engineering-management list of resources.

Programming languages

I would recommend learning:

• JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and fastest to write for interviews. JavaScript is ubiquitous.
• A compiled language (Java, C, C++...).
  • Learn c in Y Minutes
• A more recent language to see where the industry is going (as of writing, Go, Swift, Rust, Elixir...).
• A language that has first-class support for functional programming (Haskell, Scala, Clojure...).

A bit more reading:

• A brief, incomplete, mostly wrong history of programming languages
• ประเภท
• Resources To Help You To Create Programming Languages
• Effective Programs - 10 Years of Clojure ?, Rich Hickey. The author of Clojure reflects on his programming experience and explains the rationale behind some of Clojure's key design decisions.
• Learn more programming languages, even if you won't use them, Thorsten Ball
  • These new perspectives, these ideas and patterns — they linger, they stay with you, even if you end up in another language. And that is powerful enough to keep on learning new languages, because one of the best things that can happen to you when you're trying to solve a problem is a change of perspective.
• Programming Language Checklist: a fun take on "so you want to build your own language?"
• Static vs. dynamic languages: a literature review
• Polyglot Programming and the Benefits of Mastering Several Languages
• It's not what programming languages do, it's what they shepherd you to
• Ask HN: What do you code when learning a new language/framework?
• The seven programming ur-languages: ALGOL, Lisp, ML, Self, Forth, APL, Prolog
• Lua: The Little Language That Could
• The Montréal Effect: Why Programming Languages Need a Style Czar
• TodePond/DreamBerd: a perfect programming language

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

-- Bjarne Stroustrup (C++ creator)

List of resources:

• Great Works in Programming Languages

Python

For Python check out my professional Python education repository.

จาวาสคริปต์

In this repository: check ./training/front-end/

JavaScript is such a pervasive language that it's almost required learning.

• mbeaudru/modern-js-cheatsheet: cheatsheet for the JavaScript knowledge you will frequently encounter in modern projects.
• javascript-tutorial: comprehensive JavaScript guide with simple but detailed explanantions. Available in several languages.
• 30 Days of JavaScript: 30 days of JavaScript programming challenge is a step-by-step guide to learn JavaScript programming language in 30 days.
• Unleash JavaScript's Potential with Functional Programming

Garbage collection

• A Guide to the Go Garbage Collector: a very insightful guide about Go's GC

Programming paradigm

• Imperative vs Declarative Programming, Tyler McGinnis.
  • I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it's untraceable while the pattern is being executed.
• - Imperative vs Declarative Programming

Public speaking (presenting)

• Speaking for hackers

การอ่าน

• Papers we love: papers from the computer science community to read and discuss. Can be a good source of inspiration of solving your design problems.
• The morning paper: one CS research paper explained every morning.
• The Complete Guide to Effective Reading
• The benefits of note-taking by hand
• The Art of Reading More Effectively and Efficiently
• You should be reading academic computer science papers, Stack Overflow Blog
• How to Remember What You Read
  • Take notes
  • Stay focused
  • Mark up the book
  • Make mental links
  • Quit books
• Writing summaries is more important than reading more books
  • In 1-2 sentences, what is the book about as a whole?
  • What are the 3-4 central questions it tries to answer?
  • Summarize the answers in one paragraph each.
  • What are the most important things you have learned personally?
  • There was an interesting contrarian take in the Hacker News thread: "Once I relaxed and decided, 'If the stuff in this book is good enough, my brain will keep it FOR me' both my satisfaction AND utility of books increased dramatically."
• You Are What You Read, Even If You Don't Always Remember It
  • "I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.", Ralp Waldo Emerson

Refactoring

• The Rule of Three, Coding Horror
  • Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived.
  • It is three times as difficult to build reusable components as single use components.
  • A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
• Refactor vs. Rewrite
• Tripping over the potholes in too many libraries

regex

• The Best Regex Trick
• regex101: build, test, and debug regex

Releasing & deploying

• How we release so frequently
• How to deploy software, Zach Holman
• BlueGreenDeployment, Martin Fowler
• Move fast and break nothing, Zach Holman
• - Move fast and don't break things, Google
• Shipping to Production, The Pragmatic Programmer

การกำหนดเวอร์ชัน

• SemVer - Semantic Versioning
• CalVer - Calendar Versioning
• Semantic Versioning Will Not Save You
• Version numbers: how to use them?

Checklists

• Production Readiness Checklist, Gruntwork
• Checklist: what had to be done before deploying microservices to production
• Things end users care about but programmers don't: includes colors, formatting, themes, integrations, UX, compatibility, operations.

ฟีเจอร์ธง

• Flipping out, Flickr. One of the first articles about feature flags.
• Feature Flags, Toggles, Controls, a website documenting feature flags, from Launch Darkly.
• Feature Toggles (aka Feature Flags), Pete Hodgson, martinFowler.com. Comprehensive article on the topic.
  • Deliver new functionality to users rapidly but safely
  • Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
  • Experiment Toggles are used to perform multivariate or A/B testing.
  • Ops Toggles control operational aspects of our system's behavior.
  • Permissioning Toggles change the features or product experience that certain users receive.
  • Static vs dynamic toggles
  • Long-lived toggles vs transient toggles
  • Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.
• Feature Flags Best Practices: Release Management, LaunchDarkly
• How we ship code faster and safer with feature flags, Github.
• Flipr: Making Changes Quickly and Safely at Scale, Uber
• Feature flags are ruining your codebase

Testing in production

• Why We Leverage Multi-tenancy in Uber's Microservice Architecture
• Developing in Production
  • Complex systems have emergent behavior, producing epiphenomenon that only appears with sufficient scale.
  • Wood's theorem: As the complexity of a system increases, the accuracy of any single agent's own model of that system decreases rapidly.
  • The more tools and code that you add to create elements in a system, the harder it is to replicate an environment encompassing those tools and code.
  • At the core of testing in production is the idea of splitting deployments (of artifacts) from releases (of features).
• Testing in Production: the hard parts, Cindy Sridharan
  • The whole point of [actual] distributed systems engineering is you assume you're going to fail at some point in time and you design the system in such a way that the damage, at each point is minimized, that recovery is quick, and that the risk is acceptably balanced with cost.
  • How can you cut the blast radius for a similar event in half?
    • Differentiate between deployment (0 risk) and release
    • Build a deploy-observe-release pipeline
    • Make incremental rollouts the norm (canaries, %-based rollouts, etc.)
    • Test configuration changes just like you test code
    • Default to roll back, avoid fixing forward (slow!)
    • Eliminate gray failures - prefer crashing to degrading in certain cases
    • Prefer loosely coupled services at the expense of latency or correctness
    • Use poison tasters (isolate handling of client input)
    • Implement per-request-class backpressure
    • Have proper visibility from a client/end-user standpoint (client-side metrics)
• Testing in Production, the safe way
• Multi-Tenancy in a Microservice Architecture

Reliability

See also System architecture

Books:

• Site Reliability Engineering
  • Written by members of Google's SRE team, with a comprehensive analysis of the entire software lifecycle - how to build, deploy, monitor, and maintain large scale systems.

Quotes:

Quality is a snapshot at the start of life and reliability is a motion picture of the day-by-day operation. – NIST

Reliability is the one feature every customer users. -- An auth0 SRE.

Articles:

• I already mentioned the book Release it! ข้างบน. There's also a presentation from the author.
• Service Recovery: Rolling Back vs. Forward Fixing
• How Complex Systems Fail
  • Catastrophe requires multiple failures – single point failures are not enough.
  • Complex systems contain changing mixtures of failures latent within them.
  • Post-accident attribution to a 'root cause' is fundamentally wrong.
  • Hindsight biases post-accident assessments of human performance.
  • Safety is a characteristic of systems and not of their components
  • Failure free operations require experience with failure.
• Systems that defy detailed understanding
  • Focus effort on systems-level failure, instead of the individual component failure.
  • Invest in sophisticated observability tools, aiming to increase the number of questions we can ask without deploying custom code
• Operating a Large, Distributed System in a Reliable Way: Practices I Learned, Gergely Orosz.
  • A good summary of processes to implement.
• Production Oriented Development
  • Code in production is the only code that matters
  • Engineers are the subject matter experts for the code they write and should be responsible for operating it in production.
  • Buy Almost Always Beats Build
  • Make Deploys Easy
  • Trust the People Closest to the Knives
  • QA Gates Make Quality Worse
  • Boring Technology is Great.
  • Non-Production Environments Have Diminishing Returns
  • Things Will Always Break
• - High Reliability Infrastructure migrations, Julia Evans.
• Appendix F: Personal Observations on the Reliability of the Shuttle, Richard Feynman
• Lessons learned from two decades of Site Reliability Engineering

ทรัพยากร:

• - dastergon/awesome-sre
• - upgundecha/howtheysre: a curated collection of publicly available resources on SRE at technology and tech-savvy organizations

Resiliency

• - The Walking Dead - A Survival Guide to Resilient Applications
• - Defensive Programming & Resilient systems in Real World (TM)
• - Full Stack Fest: Architectural Patterns of Resilient Distributed Systems
• - The 7 quests of resilient software design
• - Resilience engineering papers: comprehensive list of resources on resilience engineering
• MTTR is more important than MTBF (for most types of F) (also as a presentation)

ค้นหา

• What every software engineer should know about search

ความปลอดภัย

• Penetration Testing: A Hands-On Introduction to Hacking, Georgia Weidman
• Penetration Testing Tools Cheat Sheet
• A practical guide to securing macOS
• Web Application Security Guide/Checklist
• Reckon you've seen some stupid security things?: everything not to do.
• Checklist of the most important security countermeasures when designing, testing, and releasing your API
• OWASP Cheat Sheet Series: a series of cheat sheets about various security topics.
  • Docker Security
  • How to improve your Docker containers security
• Secure by Design, a book review by Henrik Warne.
  • There is a big overlap between secure code and good software design
  • Every domain value should instead be represented by a domain primitive.
  • External input needs to be validated before it is used in the system, in the following order: origin, size, lexical content, syntax, semantics.
  • Entities should be consistent at creation, have limited operation, shouldn't be sharing mutable objects.
  • Three Rs to do every few hours: rotate secrets automatically, repave servers and applications (redeploy on clean footprint), repair vulnerable.
  • Don't use exceptions for the control flow.
• OWASP Top Ten Web Application Security Risks
  • How to start an AppSec program with the OWASP Top 10
• ukncsc/zero-trust-architecture: Principles to help you design and deploy a zero trust architecture
• - Minimum Viable Security
• The Open Software Assurance Maturity Model
• Security by Obscurity is Underrated
• Don't Wanna Pay Ransom Gangs? Test Your Backups, Krebs on Security
• The Beginner's Guide to Passwords
• The Password Game
• Learnings from 5 years of tech startup code audits
• API Tokens: A Tedious Survey: don't use JWT.
• The Six Dumbest Ideas in Computer Security

Training for developers:

• Hacksplaining
• Codebashing
• OWASP Security Knowledge Framework
• PagerDuty Security Training
• Gruyere: Web Application Exploits and Defenses

List of resources:

• - meirwah/awesome-incident-response: tools for incident response
• - Starting Up Security
• - decalage2/awesome-security-hardening: security hardening guides, tools and other resources

Shell (command line)

• The case for bash
• - alebcay/awesome-shell
• - dylanaraps/pure-bash-bible: pure bash alternatives to external processes.
• The Bash Hackers Wiki provides a gentler way to learn about bash than its manages.
• Awk in 20 Minutes
• - Linux Productivity Tools
• jlevy/the-art-of-command-line: master the command line, in one page must read
• Minimal safe Bash script template
• Command Line Interface Guidelines
• The Linux Commands Handbook
• How to write idempotent Bash scripts
• Learn bash by playing an adventure
• Effective Shell
• Computing from the Command Line
• What helps people get comfortable on the command line?, Julia Evans
• 6 Techniques I Use to Create a Great User Experience for Shell Scripts

SQL

• SQL styleguide
• Best practices for writing SQL queries
• Practical SQL for Data Analysis
• Reasons why SELECT * is bad for SQL performance
• Animate SQL
• Lost at SQL, an SQL learning game
• Joins 13 Ways
• spandanb/learndb-py: learn database internals by implementing it from scratch.
• SQL for the Weary

System administration

• - kahun/awesome-sysadmin: a curated list of amazingly awesome open source sysadmin resources

System architecture

See also Reliability, Scalability

Reading lists:

• - donnemartin/system-design-primer: learn how to design large scale systems. Prep for the system design interview.
• - A Distributed Systems Reading List
• - Foundational distributed systems papers
• - Services Engineering Reading List
• - System Design Cheatsheet
• karanpratapsingh/system-design: learn how to design systems at scale and prepare for system design interviews
• A Distributed Systems Reading List

Blogs:

• High Scalability: great blog about system architecture, its weekly review article are packed with numerous insights and interesting technology reviews. Checkout the all-times favorites.

Books:

• Building Microservices, Sam Newman (quite complete discussion of microservices)
• Designing Data-Intensive Applications

Articles:

• 6 Rules of thumb to build blazing fast web server applications

• The twelve-factor app

• Introduction to architecting systems for scale

• The Log: What every software engineer should know about real-time data's unifying abstraction: one of those classical articles that everyone should read.

• Turning the database outside-out with Apache Samza

• Fallacies of distributed computing, Wikipedia

• The biggest thing Amazon got right: the platform

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Monitoring and QA are the same thing.

• Building Services at Airbnb, part 3

  • Resilience is a Requirement, Not a Feature

• Building Services at Airbnb, part 4

  • Building Schema Based Testing Infrastructure for service development

• Patterns of Distributed Systems, MartinFowler.com

• ConwaysLaw, MartinFowler.com (regarding organization, check out my engineering-management list).

• The C4 model for visualising software architecture

• If Architects had to work like Programmers

Architecture patterns

• BFF (backend for frontend)
  • Backends For Frontends
• Circuit breaker
• Rate limiter algorithms (and their implementation)
• Load Balancing: a visual exploration of load balancing algos
• Good Retry, Bad Retry: An Incident Story: insightful, well-written story about retries, circuit breakers, deadline, etc.

Microservices/splitting a monolith

• Service oriented architecture: scaling the Uber engineering codebase as we grow
• Don't start with microservices in production – monoliths are your friend
• Deep lessons from Google And EBay on building ecosystems of microservices
• Introducing domain-oriented microservice architecture, Uber
  • Instead of orienting around single microservices, we oriented around collections of related microservices. We call these domains.
  • In small organizations, the operational benefit likely does not offset the increase in architectural complexity.
• Best Practices for Building a Microservice Architecture
• - Avoid Building a Distributed Monolith
• - Breaking down the monolith
• Monoliths are the future
  • "We're gonna break it up and somehow find the engineering discipline we never had in the first place."
• 12 Ways to Prepare your Monolith Before Transitioning to Microservices
• Death by a thousand microservices
  • Microservices

ความยืดหยุ่น

See also: Reliability, System architecture

• Scalable web architecture and distributed systems
• Scalability Rules: 50 Principles for Scaling Web Sites (presentation)
• Scaling to 100k Users, Alex Pareto. The basics of getting from 1 to 100k users.

Site Reliability Engineering (SRE)

See: Reliability

Technical debt

• TechnicalDebt, Martin Fowler.
• Fixing Technical Debt with an Engineering Allocation Framework
  • You don't need to stop shipping features to fix technical debt
  • Communicate the business value
• Ur-Technical Debt
  • Today, any code that a developer dislikes is branded as technical debt.
  • Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
  • Ur-technical debt is generally not detectable by static analysis.

การทดสอบ

• ️ Testing strategies in a microservices architecture (Martin Fowler) is an awesome resources explaining how to test a service properly.
• - Testing Distributed Systems

Why test:

• Why bother writing tests at all?, Dave Cheney. A good intro to the topic.
  • Even if you don't, someone will test your software
  • The majority of testing should be performed by development teams
  • Manual testing should not be the majority of your testing because manual testing is O(n)
  • Tests are the critical component that ensure you can always ship your master branch
  • Tests lock in behaviour
  • Tests give you confidence to change someone else's code

How to test:

• A quick puzzle to test your problem solving... and a great way to learn about confirmation bias and why you're mostly writing positive test cases.
• Testing is not for beginners: why learning to test is hard. This shouldn't demotivate you though!
• Arrange-act-assert: a pattern for writing good tests
• Test smarter, not harder

Test pyramid:

• The test pyramid, Martin Fowler
• Eradicating non-determinism in tests, Martin Fowler
• The practical test pyramid, MartinFowler.com
  • Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test.
  • Every single test in your test suite is additional baggage and doesn't come for free.
  • Test code is as important as production code.
• Software testing anti-patterns, Kostis Kapelonis.
• Write tests. Not too many. Mostly integration. for a contrarian take about unit testing
• - Unit test 2, Integration test: 0
• Testing in the Twenties
• Google Testing Blog: Test Sizes
• Pyramid or Crab? Find a testing strategy that fits, web.dev

End-to-end tests:

• Just say no to more end-to-end tests, Google Testing Blog
• End-to-end testing considered harmful

เครื่องมือ

• DevDocs API Documentation: a repository for multiple API docs (see also Dash for macOS).
• DevChecklist: a collaborative space for sharing checklists that help ensure software quality
• - Free for developers: list of free tiers for developments tools and services
• Choose Boring Technology
• Ask HN: Best dev tool pitches of all time?
• A list of /uses pages detailing developer setups, gear, software and configs

The future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age — Lindy's Law

Type system

• Counterexamples in Type Systems: a library of runtime issues that weren't caught by the type system

Typography

• Butterick's Practical Typography
• Typography for Lawyers
• Quick guide to web typography for developers · OlegWock
• Features of your font you had no idea about

Version control (Git)

Learning Git, courses and books:

• Git Book
• Git from the inside out
• Git Tutorials and Training, Atlassian
• Git Immersion
• A Visual Git Reference (a bit more advanced)
• Think Like (a) Git
• Git's database internals I: packed object store: an insightful deep dive from Github
• Oh My Git!: a game to learn git

Cheat sheets:

• Git Cheat Sheet
• git-tips
• Oh Shit, Git!?!

More specific topics:

• Conventional Commits
• Git Merge vs. Rebase: What's the Diff?
• - Story-telling with Git rebase
• - Git Rebase vs. Merge
• - 10 Git Anti Patterns You Should be Aware of
• Learn Git Branching: an interactive game
• Fix conflicts only once with git rerere
• Monorepo Explained
• How to Write a Git Commit Message
• git-worktree: manage multiple working trees attached to the same repository.

Work ethics, productivity & work/life balance

Check out this section on my list of engineering-management resources, "Personal productivity".

Web development

In this repository: check training/web-dev/ and ./training/front-end/

Learning guide and resources:

• grab/front-end-guide: a study guide and introduction to the modern front end stack.
• Front-End Developer Handbook 2019, Cody Lindley
• A Directory of design and front-end resources
• - codingknite/frontend-development: a list of resources for frontend development

Topics:

• 136 facts every web dev should know
• Maintainable CSS
• Things you forgot (or never knew) because of React
• Checklist - The A11Y Project for accessibility
• DevTools Tips
• 67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
• Client-Side Architecture Basics
• Web Browser Engineering: this book explains how to build a basic but complete web browser, from networking to JavaScript, in a couple thousand lines of Python.

Writing (communication, blogging)

➡️ See also my engineering-management list

• Undervalued Software Engineering Skills: Writing Well
  • From the HN discussion: "Writing a couple of pages of design docs or an Amazon-style 6 pager or whatever might take a few days of work, but can save weeks or more of wasted implementation time when you realise your system design was flawed or it doesn't address any real user needs."
• Sell Yourself Sell Your Work
  • If you've done great work, if you've produced superb software or fixed a fault with an aeroplane or investigated a problem, without telling anyone you may as well not have bothered.
• The Writing Well Handbook
  • Ideas — Identify what to write about
  • First Drafts — Generate insights on your topic
  • Rewriting — Rewrite for clarity, intrigue, and succinctness
  • Style — Rewrite for style and flow
  • Practicing — Improve as a writer
• Write Simply, Paul Graham
• Writing is Thinking: Learning to Write with Confidence
• It's time to start writing explains why Jeff Bezos banned PowerPoint at Amazon.
  • The reason writing a good 4 page memo is harder than "writing" a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what, and how things are related.
  • Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.
• Programming and Writing, Antirez
• Writing one sentence per line
• Ask HN: How to level up your technical writing?. Lots of great resources.
• Patterns in confusing explanations, Julia Evans
• Technical Writing for Developers
• Some blogging myths, Julia Evans
• George Orwell's Six Rules for Writing
  • Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  • Never use a long word where a short one will do.
  • If it is possible to cut a word out, always cut it out.
  • Never use the passive where you can use the active.
  • Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  • Break any of these rules sooner than say anything outright barbarous.
• Blog Writing for Developers

Guides & classes about technical writing:

• Documentation Guide — Write the Docs
  • หลักการ
  • Style guides
  • Docs as code
  • Markup languages
  • เครื่องมือ
• Technical Writing One introduction, Google
  • ไวยากรณ์
  • Active voice
  • Clear & short sentences

If you're overthinking, write. If you're underthinking, read. – @AlexAndBooks_

Resources & inspiration for presentations

• https://twitter.com/devops_borat
• https://speakerdeck.com/
• Dilbert
• Calvin & Hobbes (search engine)
• https://twitter.com/_workchronicles

Keeping up-to-date

Website and RSS feeds (I use Feedly):

• Hacker News ️
• VentureBeat
• High Scalability: see above

ความปลอดภัย:

• Schneier on Security
• Krebs on Security
• The Hacker News

Newsletters:

• Bytes (JavaScript)
• PyCoders (Python)
• Posthog

Blogs:

• kilimchoi/engineering-blogs

Concepts

Glossary

• BDD
• CAP theorem
• DDD
• แห้ง
• EAV
• เข้าใจ
• จูบ
• Make it run, make it right, make it fast
• OOP
• แข็ง
• TDD
• Two Generals' Problem
• YAGNI

My other lists

• engineering-management
• entrepreneurship-resources
• professional-programming
• python-education