https://github.com/poteto/e4e-2015
Notes from the engineers4engineers conference
https://github.com/poteto/e4e-2015
Last synced: 5 months ago
JSON representation
Notes from the engineers4engineers conference
- Host: GitHub
- URL: https://github.com/poteto/e4e-2015
- Owner: poteto
- Created: 2015-09-18T13:20:58.000Z (over 10 years ago)
- Default Branch: master
- Last Pushed: 2015-09-18T19:52:21.000Z (over 10 years ago)
- Last Synced: 2025-05-19T09:49:20.584Z (about 1 year ago)
- Homepage: http://www.engineers4engineers.org/
- Size: 121 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
## Keynote - Better Work Through Better Feedback
Keavy McMinn @keavy
### Asking for feedback
- What exactly do you want feedback on? Be explicit.
- When do you want feedback? Is your PR WIP (are you on the right direction?) or ready for review?
- Who do you want feedback from? Whose knowledge, expertise and point of view would you like?
### Giving feedback
When commenting on PRs, and giving feedback in general:
- Wait a few minutes, especially if you disagree
- Ask, don't tell (critique, not criticize)
- Be humble
- Explain reasons for changes to give context
- Use positive language over neutral, as it can be seen as negative
- Use emojis!!!
- Disapproval Matrix - Ann Friedman
- Empathize
## Functional JavaScript
Ben Anderson @ben_anderson
### The future has to be functional
- DOM is stateful & imperative
- UI layer should be pure – same output for a given input
- Immutable.js provides immutable collections for JS
- Immutable.record as an immutable model for your domain instead
- Services and queries take data and transform it, without mutating the original data
- Your app is a pipeline that processes data, and should be deterministic
- Redux is predictable and behaves consistently, and has a time traveling debugger (!)
## How to Study Design Patterns
Colin Williams, TripAdvisor
- It is not studying design patterns by thinking all you have to do is learn the pattern
- Every decision made in a design pattern is the best choice (for that situation), so it is important to know the reason why that pattern is the best for the problem
- Design patterns are always best on a local scale, but can sometimes be the worst in relation to the surrounding code
### Observer Pattern
- Should the Subject be able to serialize and send its state to its Observers? Depends on the broader context, for example, in a micro-service architecture.
### Mediator Pattern
- The Observer Pattern can lead to deep complexity, when Subjects can also be Observers themselves
- The Mediator Pattern takes the logic that is generalized, and consolidates them into one place so that they can interop.
## Automate Your Site's Front-End Performance
Kitt Hodsden @kitt
[Slides](https://kitt.hodsden.org/_/e4e2015-khodsden-automate-front-end-performance.pdf)
Performance is everyone's problem.
1. Determine key metrics
1. Establish a baseline
1. Make a change
1. Measure effects
Check out https://lafikl.github.io/perfBar/