> For the complete documentation index, see [llms.txt](https://cctang.gitbook.io/softwarecrafting/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cctang.gitbook.io/softwarecrafting/seminars/2016-socal-code-camp.md). # 2016 SoCal Code Camp ## Agile Safety-Critical C++ ### Robin Rowe * Embedded Systems Design * Code design: think small, think fast * Avoid the heap after main() * Avoid termination, and therefore exceptions * If rebooting is feasible, use a Highlander for auto-restart * Avoid implicit initialization of static objects before main() * Initialize explicitly in main() * Avoid senseless optimizations, profile and test * Avoid risky coding practices * Use type-safety, encapsulation, be const correct * Heap considerations * Will want to limit usage * Failure consequece is null pointer or exception * Framgemtation possible * Memory leak possible * Casting * We don't want any, but sometimes we must * Casting is an indication of a design mistake * Exceptions * Return *false* instead of throwing exceptions for 10x performance boost * Traps * Infinite loop * Recursion * In critical-safety systems, the stack is often a limited resource and recursive functions have the possibility of blowing the stack * Casts * Wild pointers * Segfault, division by zero, FPE, fatal cache miss * Initiaiton before main() * Complexity and obfuscation * Cohesion spagheti code * Code hooked together and cannot be refactored * Agile Manifesto for Software Development * Individuals and interactions over processes and tools * Process Indicators * User stories * Sprints * Release early and often * Pair programming * Kanban boards * Meetings are forward-lookiing or retrospectives * Cloud-based project management * Trello * Github * TFS * Recommends using clang instead of gcc because it can catch more errors ## Functional Programming in Javascript ### Troy Miles * Links * * * * The Book * The Magical World of Functional Programming: Part 1: Thinking Functionally * By K Anand Kumar * Online resource: Paul Graham - Structured Interpretation of Software * Pure functions are super * Cacheable * Portable * Self-documenting * Testable * Reasonable * First-class functions * Treats functions as first class citizens * Assigned to variables & stored in arrays * Anonymous and nested functions * Higher-order functions * Higher-order functions * Takes one or more functions as arguments * Development process 1. Just make it work 2. Separate of concerns 3. ES5 array methods (map, filter, reduce, forEach) 4. Make it functional 5. Create function factory 6. Move to a higher level of abstraction 7. Composition & remove constants 8. 9. * Functional JS Libraries * underscorejs * lodash * ramdajs * eliperelman * Use Babel to compile the latest JavaScript back to any version since ES3 ## Agile Collaboration ### Tom Vignard * Common considerations for fostering collaboration * Shared Goals & Ownership * Big picture / vision * CLear requirements * Ownership * Innovation * Cool features * New technologies * Creative process * Growth * Learn, Growth * Brainstorming * Collaboration * Ownership * Brainstorming * "no blockers" * Results * Features delivery * KPIs * No defects * Agile 101 * Long development cycle vs Short iterations * Separated responsbility vs Shared ownership * Documentation vs Collaboration * Known requirements vs Unknown, changing environment * Development Cycle (Sprint): * Plan * Design * Build * Test * Review * Keys to Collaboration * Talk, don't email * Engage, connect, and trust * Ask questions * Always share you ideas * Help and mentor others * Important collaboration ideas to remember (from Tony Robbins) * Trade your ***expectations*** for ***appreciations*** * It is by ***doing more*** for others that you ***become more*** ## Programmer Productivity ### Philip Yurkchuk * Contact information * * ## Emergent Architecture ### Mike Vincent * Contact info * * [www.mvasoftware.net](http://www.mvasoftware.net) ## Applying Software Craftsmanship ### Dave Moore * How to apply software craftsmanship * You must make the personal decision * Apprentice under the tutelage of a mentor * Curate learning * Hands on experience * Focused period of learning * Read * *Clean Code* - Robert Martin * *eXtreme Programming Explained* - Kent Beck * *Working Effectively with Legacy Code* - Michael Feathers * *The Pragmatic Programmer* - Andrew Hunt & David Thomas * *Domain-Driven Design* - Eric Evans * *Release It!* - Michael Nygard * Watch * *The Reasonable Expectations of Your New CTO* - Robert Martin * *Practicalities of Productionizing Distributed Systems* - Jeff Hodges * *Boundaries* - Gary Bernhardt * *Simple Made Easy* - Rich Hickey * *Advanced Concepts in TDD* - Robert Martin * *How to Stop Hating Your Tests* - Justin Searls * Katas * Short exercise * Done repetitively * Consider which version was the best, and why * Gilded Rose * Roman Numeral * Pet Projects * Koans * A repository of a series of failing tests * Clone the repository and incrementally work the failing tests * Good way to learn new languages * Git Immersion Tutorial * SQL Zoo * Embrace best principles, patterns, and practices * Test Driven Development (TDD) * SOLID design principles * Single-responsibility * Pair programming * Agile methodologies * Continuous integration * Collective ownership * OO & Functional design patterns * Push to create a learning centric culture at your company/organization * Create a learning centric culture * Incorporate learning & teaching into performance reviews * Examples: * What have you taught your colleagues this year? * What did you learn this year? * Schedule time to learn * Example * Every Friday no one should be working production code, unless there's a production outage * 10% time * Structured using Trello * Possibly scheduled on the calendar, just like normal meetings * Examples * Book club * Open source * Round table * Workshops * Talks * Coding exercises * Lunch & learns * Conference budget * Craftsman swap * Library * Self-edification budget * Mastery cohort * Hire a well-respected master to lead workshops several times a year * Host meetups/conferences * Rally your local community around craftsmanship * Speak at meetups/conferences * Organize/host meetups/conferences * Blog * Make screencasts * Contribute to open source * Network and share your ideas * Mentor junior developers * Local meetups * LA Software Workshop * Fullstack * Software Craftsmanship North America ## Ship Better, Faster ### Paul Whitmer & Jim Counts #### * Continuous Integration / Continuous Deployment * go cd * * Teamcity * Jenkins * What is it? * Developer * Automated system where the last thing a developer needs to do is check into source control * Source control * Build server * Deployment * How to * Compile/prepare code on a build server * Getting code to the server - automatic * Build server monitors repository * Checks out code when it changes * Runs the build * Developer - checks in frequently * Get feedback more often * Find hidden assumptions in the build process * Optimize what is slow * Shallow pull using git on the build agent because it doesn't need the entire history * Run unit/integration/BDD test suites * Always run the tests that are fastest first * Build server is just a fancy way to run scripts * Usually very easy to run unit tests * Integration tests may require a little thought (package dependencies) * Acceptance tests should run against a deployed environment * Deploy to multiple environments * Identical environments for different purposes * Dev - QA - Production * Easy due to automation * Only deploy "binaries" after acceptance * When a server launches * Considerations * How does it find the code? * What set of firewall rules should apply? * What security groups should it be part of? * What network should it launch into? * Which access keys should be loaded onto it? * What happens? * Baseline instance * Pull zip from storage * Connect to load balancer (for example demo using AWS) * Baked in the boot (bash) script * Get the app * Download from storage * Unzip * Run * Add to load balancer * Wait to become healthy * Tell load blancer to remove older versions of the app * Setup tags * Wait for death * Baked in death script * Am I attached to laod balancer? * No - ask AWS to stop/terminate self * Yes - reschedule * Lessons * Remove human error * Don't wait for a human to kick off build/depolyment * Don't write custom scripts per environment, use templates * Don't rely on humans to clean up, allow resources to retire themselves * Go back to basics if you need to * Shiny tools promise magic but often come with their own learning curve * There is usually a way to customize automation for your specific needs * You can always bring back the high level tool once you understand your requirements better * Misc * Suggest exploring *git kraken* for a nice UI