# Software Engineering Building software from start to finish. Step-by-step guides covering everything from understanding requirements to deploying applications. Focuses on full-stack development with Python (FastAPI, SQLAlchemy), modern JavaScript frameworks (SvelteKit), and production deployment patterns. ## Highlights Most referenced resources in this collection: - [[Django]] (26 unique files) - Full-stack Python web framework - [[React.js]] (22 unique files) - JavaScript UI library - [[PostgreSQL and Alembic Setup]] (9 unique files) - Database infrastructure - [[Heroku]] (9 unique files) - Cloud platform deployment - [[Django Models]] (8 unique files) - Database modeling - [[Choosing a Web Framework]] (8 unique files) - Framework selection guide - [[Integrating Django & React.js]] (7 unique files) - Full-stack integration - [[Containerize]] (7 unique files) - Container-based deployment - [[Django's Object-Relational Mapping (ORM)]] (7 unique files) - Database abstraction layer - [[CRUD Operations]] (6 unique files) - Database operations - [[How Host Svelte Server]] (6 unique files) - Svelte deployment - [[HTTP Methods]] (6 unique files) - HTTP verbs and usage - [[Design, Develop, & Deploy a Python Application]] (6 unique files) - Comprehensive development guide - [[API endpoints]] (6 unique files) - Endpoint design - [[Starting Svelte Dev Server]] (6 unique files) - Development environment ## Development Workflow Step-by-step guides for building applications: 1. [[0. Choose a Project Management Methodology]] - Project planning approaches 2. [[1. Understand the Problem]] - Problem definition and scope 3. [[2. Gather App Requirements]] - Requirements gathering 4. [[3. Design the App & Choose a Tech Stack]] - Architecture and tech stack selection 5. [[4. Develop, Test, & Refactor the App]] - Implementation phase 6. [[5. Document the App]] - Documentation practices 7. [[6. Deploy & Maintain the App]] - Deployment and operations 8. [[7. Test & Manage App Releases]] - Release management ## Comprehensive Guides - [[Design, Develop, & Deploy a Python Application]] - End-to-end Python development ## Web Development ### Backend Frameworks - [[Django]] (25 unique files) - Full-stack Python web framework - [[Django Models]] - Database modeling - [[Django's Object-Relational Mapping (ORM)]] - Database abstraction layer - [[Django Rest Framework (DRF)]] - API development toolkit - [[DRF Views]] - DRF view classes - [[DRF ViewSets]] - DRF viewset patterns - [[DRF Serializers]] - Data serialization in DRF - [[Choosing a Web Framework]] - Framework selection guide - [[Web Frameworks]] - Framework comparison and selection - [[Backend Web Frameworks]] - Backend framework overview ### Frontend - [[React.js]] (21 unique files) - JavaScript UI library - [[Integrating Django & React.js]] - Full-stack integration - [[Frontend]] - Frontend development overview ### APIs & Web Services - [[RESTful APIs]] - REST architecture principles - [[API endpoints]] - Endpoint design - [[HTTP Methods]] - HTTP verbs and usage - [[HTTP Requests]] - HTTP request fundamentals - [[Web APIs]] - Web API design and patterns - [[GDELT Doc API]] - GDELT documentation API - [[ChatGPT Reasoning and Web Animations]] - Advanced web features ### Server & Hosting - [[How Host Svelte Server]] - Svelte deployment - [[Starting Svelte Dev Server]] - Development environment - [[Svelte App Notes]] - Svelte application development notes - [[Heroku]] (8 refs) - Cloud platform deployment ## Infrastructure & DevOps - [[PostgreSQL and Alembic Setup]] (8 unique files) - Database setup and migrations - [[Python Data Management Workflow with PostgreSQL, SQLAlchemy (ORM Model), and Alembic]] - Complete data workflow - [[Containerize]] (6 unique files) - Container-based deployment - [[Docker]] - Containerization platform - [[VMs vs Containers]] - Virtualization comparison - [[Serverless Architecture]] - Serverless computing patterns - [[Cloud Computing Service Types]] - IaaS, PaaS, SaaS overview - [[How to Develop for the Cloud]] - Cloud-native development - [[Continuous Integration and Deployment (CI-CD)]] - CI/CD pipelines - [[GitHub Actions]] - GitHub automation workflows - [[CRUD Operations]] - Create, Read, Update, Delete operations - [[Git Workflow]] - Version control workflows ## Testing - [[User Testing Period Stages]] - Testing methodologies - [[Testing Technologies]] - Testing tools and frameworks - [[Types of Testing]] - Unit, integration, e2e testing ## Software Design & Architecture - [[Domain-Driven Design (DDD)]] - Strategic software design methodology ## Principles & Best Practices - [[Best Practices]] - General engineering best practices - [[Be Discipline and Resourcful]] - Development mindset - [[Development Methodologies]] - Agile, Scrum, Waterfall, etc. - [[Single Responsibility Principle (SRP)]] - SOLID principle for class design ## Development Tools - [[Pycharm not Indexing]] - IDE troubleshooting ## Specialized Topics - [[Learn ML]] - Machine learning fundamentals - [[ISO is an Optical Disc File Format]] - File format documentation - [[TILDEV2]] - Development notes and learnings ## External Resources - https://roadmap.sh/ - Developer roadmaps - https://www.ml.school/ - ML education - https://docs.python-guide.org/ - Python best practices ## Philosophy ![[Pasted image 20240905172338.png]] > There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We _should_ forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. > > Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only _after_ that code has been identified. It is often a mistake to make a priori judgements about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. After working with such tools for seven years, I've become convinced that all compilers written from now on should be designed to provide all programmers with feedback indicating what parts of their programs are costing the most; indeed, this feedback should be supplied automatically unless it has been specifically turned off. Donald Knuth, Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.