1. Zen Mind - Warrior Spirit
1.1. Warriors
1.1.1. Routine
1.1.1.1. Daily Standup
1.1.1.2. Sprints
1.1.1.3. Demo
1.1.2. Duty
1.1.2.1. Them
1.1.2.1.1. Defend - Property, Principles and People
1.1.2.2. Us
1.1.2.2.1. Defend Quality
1.1.3. Training
1.1.3.1. Mentor that correctos form and little things
1.1.3.1.1. Peer Reviews
1.1.4. Close Quarters
1.1.4.1. Makes people connect
1.1.4.2. Pairing at the same desk
1.1.5. Practice
1.1.5.1. Learn new skills
1.1.5.1.1. Code camp
1.1.5.2. Keep Skills Sharp
1.1.5.2.1. Code Katas
1.1.5.3. Learn Different Styles
1.1.5.3.1. Koans
1.1.6. Demos
1.1.6.1. Show off what you are capable of now
1.1.7. Varying Roles
1.1.7.1. Dev / Tester / BA
1.1.8. Discourage Carelessness
1.1.8.1. Punishment for breaking the build
1.1.9. Plan Collaborally
1.1.9.1. Work together
1.1.9.2. Come up with better solutions
1.1.10. Celebrate Success
1.1.11. Have Retrospectives
1.1.11.1. Discuss Surprises
1.1.11.2. What failed or didn't work?
1.1.11.3. Talk about successes
1.2. Warrior's Code
1.2.1. Love and Connection
1.2.1.1. Take ownership of your projects
1.2.1.2. Connect with your teammates
1.2.2. Project Code
1.2.2.1. Why?
1.2.2.2. Design
1.2.2.3. Tests
1.2.3. Must Do's
1.2.3.1. Write tests
1.2.3.2. Good names
1.2.4. Must Not Do's
1.2.4.1. Break the build
1.2.4.2. Skip testing
1.2.5. Agile Manifesto
1.3. Zen
1.3.1. Practice
1.3.1.1. They Meditation
1.3.1.1.1. Empty mind and be present
1.3.1.2. Teaches Disipline
1.3.1.2.1. TDD
1.3.1.2.2. Katas
1.3.1.3. Side projects
1.3.1.4. Blogging
1.3.2. Connectedness
1.3.2.1. All things affect each other
1.3.3. Rhythm and Pace
1.3.3.1. Focuses Intensity then relax
1.3.3.1.1. pomodoro technique
1.3.4. Beginners Mind
1.3.4.1. open minded
1.3.4.2. many options
1.3.5. Koans
1.3.5.1. cup of tea
1.3.5.1.1. be open to new ideas
1.3.5.2. polishing a tile
1.3.5.2.1. can't change something by just doing the same thing over and over
1.3.5.3. Blind Bob
1.3.5.3.1. warning systems don't help if they aren't monitored
1.3.6. Broad Journey
1.3.6.1. more than just developing
1.4. Books
1.4.1. Zen Mind Beginners Mind
1.4.2. Code of the Warrior
2. Code Reviews
2.1. Psychology of Computer Programming by Weinberg Gerald
2.2. 10 Commandments of Egoless Programming
2.2.1. Understand and accept that you will make mistakes
2.2.2. You are not your code
2.2.3. No matter how much you know, someone will know more
2.2.4. Don't rewrite without consultation
2.2.5. Treat People who know less than you with respect, deference and patience
2.2.6. The only constant is change
2.2.7. True authority stems from knowledge
2.2.8. Fight for what you believe, but gracefully accept defeat
2.2.9. Don't be the coder in the corner
2.2.10. Critique code, not the coder. Be kind to the coder, not the code
2.3. Tips
2.3.1. Must have concise coding standards
2.3.2. Run code through a static analysis tool (e.g. findbugs, checkstyles) before the peer review
2.3.3. Everyone's code should be reviewed
2.4. A Code Review Should Not Be ...
2.4.1. just something that you have to do
2.4.2. something to dread
2.4.3. a contest
2.4.4. a whichhunt
2.4.5. a way to make everyone code just like you
2.4.6. a place to enforce standards (use a tool for that)
2.5. A Code Review Should Provide ...
2.5.1. Education
2.5.1.1. Everyone can learn from everyone
2.5.2. Quality Improvement
2.5.2.1. Code should be easy to read and follow
2.5.3. Early issue prevention
2.6. Advice for Reviewers
2.6.1. Have a conversation, don't attack
2.6.2. Keep tone positive
2.6.3. Ask for description, thought process, etc.
2.6.4. Don't forget to praise
2.7. Advice for Reviewees
2.7.1. Check your code before the review
2.7.1.1. Run it through findbugs, checkstyles, sonar, etc.
2.7.2. Offer suggestions to add to the standards
2.7.3. Remember, it's only code
2.7.4. Give people time to do the review
2.8. Idea: Reviewer 1 focuses on tests, Reviewer 2 focuses on names (method, variable, etc.), Reviewer 3 focuses on functionality
3. 10 Practices Every Team Should Be Doing
3.1. Culture will trump unsupported practices
3.2. Have a Customer Focus
3.2.1. Who are they?
3.2.2. Understand what they want, and more importantly why they want it
3.2.3. Build a relationship
3.3. Be Value Driven
3.3.1. Deliver valuable, working software
3.3.2. What is the greater good?
3.3.3. Everything you do should produce something of value for the customer. If it doesn't rethink your need to do it.
3.4. Work in Small Increments
3.4.1. Create a small, tight closed feedback loop with your customer
3.4.2. Easier to keep on the right track and making progress
3.5. Have a Shared Vision
3.5.1. Collaborate with your team so you are all on the same page
3.6. Use Test Driven Development
3.6.1. During the recession he was able to find people jobs that did TDD with barely an interview.
3.7. Have Daily Standups
3.7.1. Tell "outsiders" to come to your standup when they have questions or needs from the team. It's more likely the right person for the discussion will be there and is less impactful to other tasks
3.7.2. Helps build trust among team members
3.7.2.1. Repeatedly making commitments and delivering leads to trust
3.8. Visual Management of Task
3.8.1. Make it easy to see so everyone knows what everyone else is doing
3.8.2. The team owns it
3.9. Big Visual Charts
3.9.1. Don't own it, it is what it is
3.9.2. Facts are friendly
3.9.3. Hard conversations have to had, the sooner they are had the sooner issues can start to be fixed
3.10. Have Demos
3.10.1. Have the business run the demo instead of the coders. Will make sure they know what is actually going on.
3.11. Have Retrospectives
3.11.1. We aren't victims. Retros are a chance to fix things. It's easy to try something for a couple weeks without the ship sinking.
4. Sniffing Out Success: Identifying Smells and Anti-Patterns in Your Code
4.1. This was a good interactive presentation.
4.2. Lots of good stuff here. I'll likely put together a brown bag on it sometime. Till then, read the PDF.
5. Scala Koans
5.1. What are koans?
5.1.1. A koan is a story, dialogue, question or statement used in Zen practice to provoke "great doubt" and test a student's progress in Zen practice
5.1.2. The Ruby community started using koans as a way to lead people toward Ruby enlightenment.
5.1.3. Lots of different languages and technologies have embraced the idea and have their own set of koans know.
5.1.4. In the software world, the kaons are a set of tests failing tests that lead you down the path of how to use the language, or technology. Since the tests are failing, you have to fix the tests in certain order so you can move on.
5.2. Some Available Koans
5.2.1. Spring
5.2.2. MongoDB
5.2.3. Groovy
5.2.4. javascript
5.2.5. Python
6. More Than Code
6.1. Evaluate Tradeoffs
6.1.1. What are the real requirements?
6.1.2. Consider Pros and Cons
6.1.3. Collaborate on solutions
6.2. Know the system
6.2.1. What actually matters?
6.2.2. Where are bottlenecks (potential and existing)?
6.2.2.1. Both in terms of performance and code modifications
6.3. Standards and Best Practices
6.3.1. Separation of Concerns
6.3.1.1. Do the right stuff in the right place (e.g. MVC)
6.3.2. Naming Conventions
6.4. Don't Reinvent the wheel
6.4.1. Reinventing means you have to learn a new domain
6.4.2. Know when to buy vs build
6.5. Solve Problems
6.5.1. Solve the right problem
6.5.2. What is the end goal?
6.5.3. Why are you solving the problem you are?
6.5.3.1. Answering this could show you are going down the wrong path
6.5.4. Create Hero Apps
6.5.4.1. Little apps that automate or simplify tasks (e.g. log miners)
6.6. Write Code
6.6.1. Sometimes you have to start coding instead of only thinking about possible solutions
6.6.1.1. Paradox of Choice by Barry Schwartz
7. Spring Batch
7.1. It's neat, check it out.
7.2. A lot of the descriptions of it would lead one to believe that it is used for only large batch processing. However, it would work well with pretty much anything that reads, then processes, then writes.
8. Silence of Agile
8.1. Why?
8.1.1. 50% More ideas are generated by individuals working separately then aggregated then as a group
8.1.2. Discussion of ideas leads to a better solution
8.1.3. the more charismatic the leader, the worse the group think is no one wants to contradict the leader
8.2. How?
8.2.1. Brainstorm individually, aggregate, group, then discuss as a group, vote silently
8.2.2. When brainstorming wait until about 20% are still working
8.2.3. Speed Boat Exercise
8.2.3.1. Draw a boat with a propellar
8.2.3.2. Get ideas on things that propel the team forward, anchor the team down, and what icebergs are ahead
8.2.4. Generating User Stories
8.2.4.1. Write a section (user, want or why) then pass it on to the next guy
8.2.4.2. write a section, but in reverse, then pass
8.3. Books
8.3.1. Thinking Fast and Slow
8.3.2. Collaboration Explained
8.4. Have a new pet peeve of leading questions
9. Object Oriented in the Wild
9.1. The presenter @jessitron was awesome, I'd go to one of her talks anyday.
9.2. Takeaways
9.2.1. Don't force the patterns of a language you know into a new language you are learning. Javascript isn't OO, don't try and make it be. It's much more functional, so learn functional programming to do it right.
9.2.2. Single Responsibility Principle is most important. DRY is secondary.
9.2.3. Interesting thought: Flip the 'older = better' paradigm on it's head. Make the new code and features you add less perfect. If they are kept, then clean them up. Your oldest code should be the cleanest.
10. Reinvent the Wheel
10.1. This was by far the worst presentation of the conference.
10.2. Why reinvent?
10.2.1. Understand the implementation
10.2.1.1. leads to make the better choice
10.2.2. Knowing how to use an API doesn't mean that you know the internals.
10.2.2.1. May lead to a less optimized solution
10.2.3. More prepared for job interviews
10.3. When to reinvent?
10.3.1. Him: Pretty much everything except for the circuits
10.3.2. Me: When it makes sense. If you end up with a bottleneck and you've knocked out all the big things from your code, then consider rewriting the API in a way that is efficient for your problem.
11. Open Sourcery: Using your powers for good
11.1. Programmers have super powers
11.1.1. Captain Planet
11.1.2. The Incredible Hulk
11.1.3. Daredevil