Notes from Front-end London March
How to Win Designers and Influence Developers - Adam Rogers
- Project Management
- People don't always do what you tell them
- To make great things, we have to work together and enjoy it!
- Happier teams build better products
- "You can delegate a task, but you can't delegate responsibility"
- Recommend: How to win friends and influence people
- When something goes wrong, don't criticise
- just try to fix the problem
- Work together to prevent it happening again
- Say "Thank you" and mean it
- Worry about what you can directly control
- Communicate needs
- Get feedback, talking is often the most productive way of solving problems
- Asking questions
- Helps avoid arguments
- Saves face
- Your team are smart. Use them!
- Don't be a jerk!
- Homework:
- next time something goes horribly wrong, give credit instead of criticism
- Help someone fix something, go through it with them
- Ask someone a question
Exploring CSS3's 3D space - Daniel Grant
Check out the highly impressive demonstrations Daniel put together, including a CSS Solar System
- The basics: transform
- translate
- rotate
- Make things 3D-er by adding
perspective
(distance away) - To create a 3D shape, you have to combine lots of flat shapes on different planes
transform-style: preserve-3d
to apply a transform to all children elementsbackface-visibility: hidden
to stop the back of a flipped object being showntransition
will show you the frames in between- Ooh, pretty thing is pretty!
- Is 3D CSS useful? Yeah, but as a learning tool
Can code quality be measured? - Tim Ruffles
- Sidekick.js a code quality tracker
- Code quality: Who does it anger?
- WTF is good code?
- To extent it depends on us, "Is this my kind of code?"
- Can we leave taste aside?
- OOP or functional or procedural
- What can we actually measure?
- Doing the same thing three ways
- I can't change anything
- This looks like Java
- It just works
- Quality
- Concise
- DRY (Don't Repeat Yourself)
- flay-js: structural duplication detection
- Single Point Of Truth
- Simple
- KISS, but nobody tries to write complicated code
- Does one thing, well
- Low detail, attempt to abstract everything
- As few responsibilities as possible
- Low difficulty
- Measuring local difficulty, how many paths through your code?
- How many variables, how many things do you have to keep in your head at once?
- Few dependencies
- The more interconnected the code, the harder it is to change
- Having a module system != Modularity
- Readable
- Avoid idioms and bringing other languages with you
- Good naming. Make it longer the more it's going to be around
- Variables and function names are better than bad comments
- Comment, when the intention isn't clear from the code
- Comments != documentation
- Doctest.is, unit tests from documentation
- Extendable / Changeable
- Try and keep things small
- Testable
- Test 0 - can you actually test your code?
- Code that isn't testable, generally isn't quality code
- Does measured = managed? Yes, so long as you use it responsibly
- Good conversation starter
- Nice wall-o-metrics
- Stay proud of your team's code
- Concise