Architecture Code Diary Entries

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job.

• Add instrumentation around critical functionality
• All methods on one object but organized in many files
• Basics of laravel style inversion of control
• Basics of presenter objects
• Booking system takeaways
• Centralize environmentally dependent config in ENV files
• Checklist of things to consider when translating web apps
• CQRS overview
• Create a separate thread to handle user input
• Difference between API and SDK
• Do not call external apis etc through active record objects
• Do not make config dependent on DB ids
• Functionality critical to test should not be locked away in private methods
• If pulling data is hard try pushing it
• In the global file call the local file to prevent overriding
• Instead of booting longrunning services run log tailers
• Jobs that loop work should create sub jobs for each iteration lest one fail
• Never put email sending code in your data model callbacks
• Prefer errors at boottime to errors at runtime
• Prefer server side work even if more http calls
• Pros and cons of microservices
• PSA closures do not copy data
• Pub sub system pros and cons
• Raise an exception instead of commenting TODO
• Rescuing exceptions in normal flow is actually fine
• Respect the semantics of folder names
• Seeds should contain realistic not minimal data
• Separate presentational strings from logical keys
• Serverless notes
• Stay with the defaults
• Textfiles are the simplest way to store state across program runs
• The difference between lexical vs dynamic scope
• Thoughts on rails concerns
• Thoughts on the decorator pattern
• Wrap all side effects code in exception catchers