Robert Kawecki
"Heap management"
2077-08-09
Robert Kawecki
"Hip management"
2087-08-09
Robert Kawecki
"Hype management"
(for real this time)
2017-08-09
The lifetime of a project
- Pick a framework/library
- Use said tool
- Find flaws (complexity/performance)
- ???
The cycle
All aboard the hype train!
- New solutions: simple, revolutionary, seemingly devoid of complexity
- Easy examples
- Do more with less
The early bird gets the bug
- Early adopter bugs in use cases beyond tests
- Poor actual API doc - tutorials only
Complexity
- Problem domain (natural) complexity
- Technical complexity
Microservices
- Better decoupling
- Separation of problem-specific environments
- Common calling convention
Mash-ups
- Combining data sources into one coherent GUI
- More flexibility in choosing back-ends
- More conceptual load on the front-end
Hexagonal architecture
- Layers: framework, application, core logic
- Interaction via specified interfaces - adapters
A good library / framework
- Allows encapsulation of logic
- Is API-documented
- Is maintained
A good database
- Defines storage semantics
- Has known failure modes
- Fits the problem
The right tool for the job
- Shape of the problem = shape of the solution
- Examples seldom reflect your use case
Tools: databases
- Problem: blog posts with multiple tags
- Solution: a DB that can index multi-values (MongoDB?)
- Problem: relational data
- Solution: RDBMS / graph DB (NOT MongoDB!)
Tools: front-end
- Problem: knowledge base
- Solution: static, indexable pages, 100% caching
- Problem: social network
- Solution: SPA (React/Angular?)
The value of MVP
- Testing the concept
- Testing the framework
The blame game
- Your code - your responsibility
- External dependencies - still your responsibility
Takeaway
- Realize sources of complexity
- Pick solutions for problems, not problems for solutions
Addendum: building code
- Extra layer of source mapping
- Harder testing/coverage/static analysis
- Don't rely on aliases