2017 SoCal Code Camp
Code Camp Los Angeles
USC
December 2-3
Ways to Fail. Or Not.
Heather Barron
Synopsis
I have not failed. I've just found 10,000 ways that won't work. -- Thomas Edison
We are conflicted with failure in our society. We recognize that failure is an inevitable, necessary and vital component of success, and yet we lionize success and shame failure. Perhaps because of this shaming of failure we avoid talking about it, which ironically leads to yet more failure.
In this talk we'll crack the taboo around failure and take a good hard look at the reasons for failure, the types and ways to fail all with an eye to learning how to leverage failure to get to success.
Notes
Energy Levels
Understanding where people live and where they come from will help you to better relate to them
We are constantly moving between levels
Level Descriptions - Core Thought/Core Feeling/Action
Level 1 - Victim/Apathy/Lethargy
Weakest to make change
Level 2 - Conflict/Anger/Defence
Level 3 - Responsibility/Forgiveness/Cooperation
Level 4 - Concern/Compassion/Service
Servant leaders
May often take care of the team to the detriment of the self
Level 5 - Reconciliation//Peace/Acceptance
We're going to win, or we won't play
Structure the game so there are no losers
Level 6 - Synthesis/Joy/Wisdom
We always win
Level 7 - Non-judgement/Absolute Passion/Creation
Winning is an illusion
Effective/Ineffective teams:
Effective teams have:
High emotional intelligence
Good mix of introverts & extroverts
Shared goals, well understood
Time for fun
Proactive communication
Sprint retrospectives
Strong leadership
Positivity is contagious
Ineffective teams have:
Poor focus
Unequal members
Tragically, newbies are shut down
Newbies can contribute novel ideas
Negativity
This is also contagious
Lack of cohesion
Rudeness
Domination
How can you learn if you never listen?
Irresponsibility
You want those people who are excited for Mondays and can't wait to tackle problems
Keeping Perspective
Important thing isn't what's right, but what the team agrees to do
Subjective vs Objective
Ego, judgement
Biases in how someone's work productive evaluated can lead to emotionally triggering someone into a less efficient energy level
Good/Bad vs Healthy/Unhealthy
Right/Wrong vs Efficient/Inefficient
Composing a team with strengths and weaknesses in mind
Assess the need
Assess the team
Know the aspirations
None of us are static
Levers of motivation
Augment strengths
Cover weaknesses
Keep a road map
If you don't remember where you began or where you're going, you can't evaluate where you're at and your goals
Kinds of Failure
Abject
This is the really dark one. It marks you and you may not ever fully recover from it. People lose their lives, jobs, respect, or livelihoods.
Structural
It cuts - deeply - but it doesn't permanently cripple your identity or enterprise.
Glorious
Going out in a botched but beautiful blaze of glory - catastrophic but exhilerating.
Common
Everyday instances of screwing up that are not too difficult to recover from. The apology was invented for this category.
Version
Small failures that lead to incremental but meaningful improvements over time.
Predicted
Failure as an essential part of a process that allows you to see what it is you really need to do more clearly because of the shortcomings. Example: the prototype.
The Field of Fail: A spectrum of failure
Failing badly
Vicious cycles
No retrospectives
No lessons learned
No value recovered
No transparency
No team examination
No process examination
Failing well
Teaching the way out/around the holes
Capturing improvements
Planned failure
Failing quickly
Failing cheaply
Recovering value
Learning lessons
Improving processes
Teaching the team
If you're not failing every now and again, it's a sign you're not doing anything very innovative. -- Woody Allen
Not failing
Not failing is not the same as succeeding
Sometimes a good failure is better than a mediocre success
Avoiding all risk is not the way to success, even if it may be a way to minimize failure
Succeeding
On time
On budget
Meets requirements
Stable
Maintainable
Useful
Useable
Key: Make sure the definition of success is set at the beginning
Winning!
Virtuous cycle
Surprised & delighted stakeholders
Delivery in the face of the unexpected
Side benefits to organization
Product leadership
Enabled market penetration
Users are your cheerleaders
Culture of continuous improvement
People don't tolerate badly written code
Empowered team members
Commitment to excellence
New opportunities
Summary
Prevalence of failure
Economics of software
Reasons for failure
Team dynamics
Kinds of failure
Ways to fail
Final thoughts
Always assume you know less than you think you do
Be sure to capture lessons learned at the end of every project including how to leverage them, train them, internalize them. No shelfware!
Agile is a process that embraces failure, not avoids it
Consider your process (or lack thereof) and maturity
Consider the right tool for the job
i.e. methodologies: which flavor of Agile vs waterfall vs CMM
The Architectural Mindset
Jeremy Cameron
Thought leader
Practice leader at a Fortune 500 company (Assurant)
Hired 60 people this year
Platform architect
Synopsis
This session will provide an architectural framework that you can use when facing difficult and uncertain issues. It's a way of thinking about problems and solutions that can be applied to technology challenges, life challenges, and any situation with multiple paths. It will be presented from a technical point of view but non-technical people will also benefit from this talk.
Notes
Solving Problems
The right answer or the best answer?
Maturity Mindset
3 Stages
Can I do it?
Should I do it?
When should I do it?
Important and urgent matrix
Start with important and urgent quadrant
Move quickly to urgent but not important
Respond to them quickly
Delegate them out
Important but not urgent
These are your goals
These are the ones you want to work
These are the strategic things to work
Work Inward Out (Why? -> How? -> What?)
Start with Why
Architects often want to start with the solution first
Why = the purpose
What is your cause? What do you believe?
How = the process
Specific actions taken to realize the Why
What = the result
What do you do? The result of Why. Proof.
Effective Listening
Gaining key insights
Hear the other person completely
Most people do not listen with the intent to understand; they listen with the intent to reply. -- Stephen R. Covey
Toolsets
The right tool for the right job at the right time
Think about setting people for success
Build just enough; as little as you need
Ask: Do I really need this?
When all you have is a hammer, everything looks like a nail -- Aristotle
Problem Space
What problem are we trying to solve?
Toolbox
Words
Diagrams
Conceptual level
Problems modeled into a broken down way
Logical level
Physical
Pictures
It Depends
Creating Solutions
How do we solve this?
Get something down on paper
Get a strawman
Don't be afraid to throw away code
Refactoring is a good thing
Craft 3 viable options
This is ideal because with 2, it's either this or that. With 3, it's easier to think of things objectively
Weighted spreadsheet with selection criteria
Evaluated objectively
Suggests that a scale of 1(poor) to 5(ideal) is good
Helps mitigate scenarios where an option is chosen in search for a problem
Executing and Producing
Two jobs: Solve problems and add value
Solve problems every day, even if it's just a small problem
Work small
As a developer, less attachment to a couple-hours worth of code and more can more easily be thrown away
Fear of failing keeps developers from innovating
Fail fast
Learn always
Failure is not a bad thing if you learn from it
Continuous Learning
Magic is found every day when you look for it
MAGIC: My Actions Generate Internal Change
Always be learning something new
Defensiveness is a roadblock to learning
Career Path Transitions
Developer -> Architect
Be willing to understand
Understand the problem in full
Don't be afraid to iterate on ideas
Get something on paper
Come up with a solution, then figure out how to make it better
It can be a terrible solution, but it's better than paralysis by analysis
Indecision is often the wrong decision
Find a mentor
Make sure it's bi-directional relationship that is mutually valuable
Make sure you provide value to the person mentoring you
Be prepared at every meeting
Design purposefully up-front otherwise you'll be designing ad-hoc
Automated testing is very important to deliver quickly
Agile vs Waterfall
How do you want to embrace change?
Jeremy suggests that even in a waterfall process, he would set milestones in 2-3 week intervals to better track progress
Dream Team
Jeremy Cameron
Synopsis
What makes a great team? Why should you want to be involved with it? How do you pick the right team members? How do you pick the right team as a candidate when you have multiple opportunities? How do you set yourself up for both short term and long term success? What are the ingredients of a dream team?
Notes
Go fast? Go alone. Go far? Go together. -- Unattributed
What makes a "Dream Team"
Alignment
"Don't choose your next job but your next boss"
Value
If you're working for a company, you need to deliver business value
Make sure to add value every day
Continuous Learning
Experimentation: The catalyst of creativity
Don't be afraid to make mistakes
Don't be afraid to fail spectacularly
Sometimes you win, sometimes you learn, sometimes you're lucky to do both
Leadership
Not everyone is a leader
Characteristic of a leader is to be lead well
Motivators
It's all about the Benjamins????
Less than 2% correlation between pay and satisfaction
Examples:
Personal growth
Recognition
If you recognize yourself, you won't need to rely on anyone else for satisfaction
Family
Sex
Freedom
Fulfillment
Achievement
Influence
Success
Love
Money
Power
Don't need to treat everyone the same, but must treat them equally
Figure out your motivations and drive towards those things
Skills That Matter
Soft skills are twice as important as technical or functional skills
Carries Everywhere
Team Spirit
Be willing as a leader to accept a little more share of the blame and little less of the credit
Title only effects two things
HR salary considerations
Authority in a very structured organization
Self-Confidence
Don't say "you're just" a developer, but "I am" a developer. In fact say "I am" one of the best developers I know.
Trustworthiness
Assertiveness
Be willing to make a decision
"The road is full of dead squirrels who couldn't"
It's ok to change your mind, to learn, to grow
Communication
Empathy
Inquisitiveness & Creativity
Be willing to experiment; try, create, and explore new things
Emotional Intelligence
Be first the master of yourself
Awareness is the first step to change
Self-Awareness
Emotional self-awareness
Accurate self-assessment
Self-confidence
Social Awareness
Empathy
Organizational awareness
Service orientation
Relationship Management
Developing others
Inspirational leadership
Conflict management
Self-Management
Emotional self-control
Initiative
Optimism
Emotional Intelligence 2.0 - Travis Bradberry
Dream Team for you
Hello, is it me you're looking for?
Figure out what you like
What kind of culture is important to you?
What are your values?
Speaks to who you are
What is important in your core?
Don't compromise
Ask thoughtful questions
Interviews are bidirectional
Interviews are the first several months, not just the official interview
Be prepared with good, thoughtful questions
Airport test
If you had a layover at an airport, would you be ok having a conversation with the person?
Build That Great Team
Define your culture
Follow the money
Are you in a project where your company is going?
Don't compromise
Be fair
Be honest
Consider vendors as part of the team
Believe in your team
Have conversations with everyone on the team
Maintain an open door policy
You're not too big to help with the menial tasks
Be present with your team
Be engaged with your team
Secret Sauce
When looking at a resume
Tells a story
Read the summary
Dig into the most recent experience
Looking at the most recent couple of years
Look for inconsistencies
Discern personality from the resume
Technical skills are just table stakes
Look for compatibilities:
Team fit
Technical Fit
Ask open-ended questions
Skill fit
Culture fit
Sometimes put people in stressful situations in the interview to gauge how they will react in similar situations
Skills to develop
Business acumen
Delegation
Think from the next higher level
Rock Your Code Quality
David McCarter
dotnetdave@live.com
Microsoft MVP
Award Winning Developer
Architect
@realDotNetDave
Synopsis
Code quality starts with you, the developer. If you are writing your first app or have been through the battle field many times trying to improve code quality within your team, this session is for you. This fast paced session will discuss the core things you need to remember each and every day of your coding life along with real world examples and solutions. Other topics discussed will be Visual Studio add-ins to help you learn and practice good coding standard practices, architecture, performance, testing, security, the cloud and much more.
Notes
Opening Act
In the context of software engineering, software quality refers to two related but distinct notions that exist where quality is defined in a business context
Software Functional & Structural Quality
Reliability
Efficiency
Maintainability
Security
Size
Why do we need it?
There's really no such thing as a large-scale software dev project. All software is small chunks stuck together with chewing gum and string. -- Alan Cooper
Code quality, in one word
Clarity
Stable
Simple
Undervalued
Maintainable
Reliable
Tested
SOLID
Features sell software, not code quality
You must find ways to inject code quality
Observed Code Violations in just one code base Dave has worked
30 Critical Errors
869 Errors
49,463 Warnings
162 Critical Warnings
Single class has cyclomatic complexity of 7,290 & class coupling of 514
Number of paths that can be taken through one unit of code
Each of those require a unit test
Globalization > 6K
Spelling issues > 2K
2K CLS compliant issues
An indicator of reuse compatibility
The first thing that happens when bad code is encountered: We re-write it
The cost of fixing bugs
Requirements - baseline
Design - 5x
Code - 10x
Dev Testing - 20x
Acceptance Testing - 50x
Production - > 150x
How do we implement code quality easily?
Coding Standards & Best Practices
.NET Coding Standards by David McCarter
Architecture & Multi Layer Design
User Experience
Presentation Layer
UI Components
Identity
Communications Layer
Business Layer
Business workflow
Business components
Business entities
Data Layer
Object Oriented and Structured Programming
Encapsulation
Inheritance
Polymorphism
www.c-sharpcorner.com/blogs/make-encapsulation-easy-with-dotnettipsutility
Data
Database
databasehalth.com/download
Evaluates health of any SQL server
Files
Memory and Network
Likely the largest bottleneck encountered in software
Get your stuff out of memory sooner, rather than later
iDisposable
Telling the garbage collector you're done with the data
Release objects as soon as possible
Check network resources
pingis really cheap and fastWhy make a call to a network resource if it is not there?
Security
Cross-site scripting
Identity
SQL injection
Type checking
Use the right type for the job
Reuse!
Have the mindset that whatever you code will be reused
90% of all code should be in DLLs or assemblies
Must perform proper unit testing and validation
.NET standard libraries
Portable libraries
Type coupling
Tight coupling BAD
Loose coupling GOOD
Dependency injection
Generics
Make methods type agnostic
Complexity
Write code that most programmers can understand
Good programmers write code that humans can understand -- Martin Fowler
Refactor
All code needs to be Unit testable
If not possible, re-write the code
Performance
Chunky, not chatty, calls
The Internet is the biggest bottleneck
Don't go across the Internet until you have a bunch
Queuing
Dispatch lower-priority tasks to slower workers
Caching
Cloud
Easy way to improve performance without doing much
Datacenters may be closer to the user
Globalization
Languages (& translations)
Resources
Formatting
Error & Exception Handling
Try/Catch
Prevents exceptions
When something is caught, log everything everywhere
Log at least to two places, if not more
Don't write your own logging framework
Dave has an open-source one
Stackify logs, for free, to the cloud
Global trapping
Send to the cloud
Analysis
SQL Server
Database health monitor
SQL profiler
Often the single-point of failure for applications
Network
Monitor
Memory
Memory profiling is the only way to find dispose problems
Disk I/O
Testing
Performance testing
Unit testing
User acceptance
App testing
Documentation
Requirements
Design
Code comments / self documenting code
XML docs
ghostdoc from submain
Refactor
CodeRush from DevExpress
Workflow before submitting code
Run StyleCop
Run FXCop / Analyze
Unit Test
Code.It Right from SubMain
Memory profiler
memprofiler.com
Complete CI/CD Pipeline to Microsoft Azure with Docker using Jenkins
Jessica Deen
Jessica.Deen@Microsoft.com
www.jessicadeen.com
@jldeen
Channel 9 - https://channel9.msdn.com/Niners/jldeen
Cloud DevOps Advocate at Microsoft
Synopsis
We will first review what CD (continuous deployment/delivery) is and will briefly cover how it works. If you’re not familiar with CI/CD tools, I will demo how CD tools handle continuous deployment to Azure and how you can use them to stand up Docker infrastructure (or even Kubernetes) and pass Docker commands for your dev environments. This session will teach attendees how to push apps to Docker containers or Kubernetes Pods on Azure from a CI/CD pipeline. The code used to support Azure is highly scalable and can be applied to a host of CI/CD tools, such as Jenkins, Travis CI, Codeship, Codefresh, etc. If you’ve ever been curious about how to get started with continuous integration / continuous deployment and Docker containers, or even Microsoft Azure, this is the talk to attend! After this session, you will firmly understand how you can use CI/CD with Microsoft Azure and Docker to build images and run your applications in running containers. You will also learn how to create a non-interactive, command line based, login session to Microsoft Azure, a method you can use to scale with any developer environment.
Notes
Reveiw "DevOps," what it is, and why it matters
Going digital
1 million new devices per hour will be coming online
12 years average age of S&P 500 coporations by 2020
60% computing in the public cloud by 2025
DevOps
Aspects
People
Bring people together
Processes
Delivering value faster
Tools
Executing a devops strategy
Habits and practices
Automated testing
Continuous integration/deployment
Release management
Telemetry monitoring
Testing in production
Automated testing
Continous measurement
End-to-end DevOps
Plan + Track
Starts with an idea that can be turned into reality
Develop + Test
After the iteration starts, developers turn great ideas into features and functionality
Write code
Unit testing
Version control
Source code management
All your code is linked directly to the story, but, or task
Build
Build verification
Continuous Integration
Test management
Release
Release
When all tests pass, the build is deployed
Continous Deployment
Streamline and automate the workflow between development and IT ops and deliver higher quality software mrore frequently with less risk
Infrastructure as code
Value
Optimize resources
Accelerate delivery
Measure
Deployment rate
MTTR
Monitor + Learn
When all tests pass, the build is deployed to testing environments for each stage in the release process
Streamline and automate the workflow between development and IT ops and deliver higher quality software more frequently with less risk
DevOps Benefits
Strong IT Performance is a competitive advantage
Dploy code 30x faster
Have 60x fewer failures
Jenkins
Groovy pipeline?
Kubernetes
What is this?
The shift to DevOps
Old World -> New World
Focus on planning -> focus on delivering
compete -> collaborate to win
Static hierarchies -> fluent and flexible teams
Individual productivity -> Collective value creation
Efficiency of process -> Effectiveness of outcomes
Assumptions, not data -> experiment, learn, and respond
Recommended DevOps book: Phoenix Project
The Fundamental Laws of Software Development
Matthew Jones
Lead software developer for U-Haul International
Tech BLog: www.excetionnotfound.net
Reading Blog: www.readaloudcorner.com
Twitter: @ExceptionFound
SGOTI
Synopsis
There exists a set of fundamental maxims, quotes, and adages which guide how software is developed in the modern world. This is a fast, funny session in which we will explore many those ideas and explain how they apply to our everyday jobs. The maxims themselves might not have been developed for the software world, but they apply to our livelihood nonetheless.
Slides will be posted after the session.
Original blog post (does not contain all the laws discussed in this presentation):
Notes
What are the Fundamental Laws?
Universe
Tech-agnostic
Funny (sometimes)
True
Deal primarily with people, not code
The basics
Simpler is better
Kranzberg's First Law
Technology is neither good nor bad; nor is it neutral.
Occam's Razor
Among competing hypotheses, the one with the fewest assumptions should be selected. -- William of Ockham
The Pareto Principle
Formulated by Vilfredo Pareto
80% of the effects stem from 20% of the causes. -- Formulated by Joseph Juran
Remember which details you want
Hanlon's Razor
Never assume malice for what is adequately explained by stupidity.
Time Management
Parkinson's Law
Work exampls so as to fill the time available for its completion. -- C. Northrope Parkinson
Should not overestimate time as much as you can
The Ninety-Ninety Rule
The first 90% of the code takes the first 90% of development time. The last 10% of the code takes the other 90% of development time. -- Tom Cargill, Bell Labs
Hofstadter's Law
It always takes longer than you think, even when you take into account Hofstadter's Law.
Godel, Escher, Bach: an Eternal Golden Braid by Douglas R. Hofstadter
Design
Hick's Law
The time to make a decision is a function of the possible choices.
Reduce the number of choices for more efficient decision making
User's don't want to use your app, they want to accomplish a task
Software is a means to the end
The faster you can get out of your user's way, the more they like you
Remove choices that don't matter
Hoare's Maxim
There are two ways to construct a software design. One is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies. -- Sir C.A.R. "Tony" Hoare (inventor of quicksort)
The more simple you make it, the easier it is to explain it. It takes time to gain the expertise to make it simple
You will never actually make it perfect, but can get really really close
Code 8. Robustness Pricniple
Be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, Internet Pioner
Also known as Postel's Law
You want to do things once
Flon's Law
There is not now, nor will there ever be, a programming language in which it is the least bit difficult to write bad code.
Eagleson's Law
Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.
You are not your code
Code doesn't change, you do
Maintenance
All code needs work, some just need more than others
Chesterton's Fence
Reforms should not be made until the reasoning behind the current state of affairs is understood.
G. K. Chesterton wanted to tear down a fence because he imagined it was useless and obstructed the view. The city council's retort was that they may consider tearing it down if Chesterton could explain why it may be needed.
Linus's Law
Given enough eyeballs, all bugs are shallow.
Linus Torvalds noticed this while debugging
Example: stack overflow
Cunningham's Law
The fastest way to get an answer on the Internet is not to ask a question, it's to post the wrong answer.
Management 14. The Peter Principle
The selection of a candidate for a position is based on the candidate's performance in their current role, rather than on abilities relevant to the intended role -- Peter J. Cumming
You can't be judged on a job you haven't done
Advancement in position is based on the candidate's performance in his or her previous roles rather than performance in current role.
14.1. Peter Principle Redux
Employees tend to rise to their level of incompetence.
Brook's Law
Adding manpower to a late software project makes it later.
The Mythical Man-Month by Frederick P. Brooks, Jr.
Augustine's Law
Software development is not a factory
Software teams are much more akin to a film crew
Conway's Law
The architecture of a system is a copy of the architecture of the organization
If you are aware of this, you can influence the design of your architecture to compensate
Meetings 17. Parkinson's Law of Triviality
The time spent on any agenda item will be in inverse proportion to the sum of money involved. 18. Sayre's Law In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake. 19. Law of argumentative Comprehension The more people understand something, the more willing they are to argue about it, and the more vigorously they will do so.
Whoever is in charge of the meeting must take control and break this
Functional Principles in C#
Paul Verger
paulverger@gmail.com
Synopsis
Functional Principles are a group of coding practices designed to make applications easier to debug, maintain, and test. In this session you will learn how and when to use immutable classes, command-query separation, when to use exceptions, and how to use the “fail fast” principle. We will also cover lambdas and extension methods to make code more concise and readable. We will also discuss dependency injection and how to avoid “primitive obsession”.
Notes
Immutable classes
Command-query separation (CQS)
Single-responsibility principle
Exceptions
Only should be used for failures that shouldn't happen
Fail Fast Principle
When an error is detected, IMMEDIATELY stop processing the request and return an error indication
Syntactic Sugar
Lambdas
Make code more concise
=> is lambda operator
Translate => as "goes to"
Often used with Linq (System.Linq)
Disadvantages
Most useful for simple relations
Harder to read for complex algortihms
Hard to debug
Extension Methods
Can be invoked from an object even though they are not part of that object's class
Disadvantages
Having many makes them hard to keep track of them all
Hard to find all extension methods associated with a class
Can be dispersed through entire code base
Dependency Injection
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Constructor Injection
Using interfaces and abstract class as a parameter to the injection
Disadvantages
May make code harder to read
Warning: Only use dependency injection for parameters that could actually change!
Primitive Obsession
"Obsessively" converting class fields and properties to built-in types
Avoidance:
Don't convert class object property or field to a built-in ("primitive") data type
Use application calls to object property or field
Recommended References
Pluralsight Course; Applying Functional Principles in C# by Vladimir Korikov (April 8, 2016)
Pluralsight Course; Practical LINQ by Deborah Kurata (September 17, 2013)
The Art of Not Sucking At Technical Presentations
Nuri Halperin
@nurih
Synopsis
It might be about attaining perfection.
More likely, it's about trying not to suck.
Notes
Presenting can be thought of as an art form
There is also a certain amount of science to it
Education?
The Art of Enchantment, Guy Kawasaki
Slide building
Confessions of a Public Speaker, Scott Berkun
How to "perform"
Toastmasters
Good to cut filler sounds and get practice
Create an environment where the audience keeps their attention on the speaker and the material
"See through the system"
What is a presentation?
Think of the whole room
Choices of how to appear to the audience
Teacher
Informative only
Lecture
Informative
Storytelling
Story arch from a state of not knowing to understanding
What really matters is the audience, not how the presenter provides the information
The audience has one thing on their mind: "What's in it for me"?
The audience may have different levels of understanding of the material
Novices
Intermediate understanding wanting to learn something new
Introductions?
Don't do it; not useful to state name, reason for the talk, credentials, etc.
Use the time to give value to the audience rather than talk up yourself
Jokes?
Not appropriate for technical presentations
Difficult to do well
Sensibilities are wide and varied
What's in it for the audience? They're attending a technical presentation to learn something.
Humanizing yourself to make a connection with the audience may be the one exception
If it comes out naturally, go ahead and let it out, but don't spend time working on it
Don't stand and read the slides you created
You could have easily sent the slides out and not wasted the audience's time with a presentation
Memes
Wasn't clear what his recommendation was because of questions about what memes are
Graphics
Complex graphics that is information rich is distracting
The audience will want to read and understand it
If you must have complex graphics, pause and turn to the slide. Let the audience know they have permission to take in the material and has time and space to do it.
Should only be an aid to what you'll be saying
Give the essence of the concepts
Distill concepts to the very essences
If there are details to be disemminated
Provide it afterwards
Decompose to multiple slides
But I'm not an artist!
Small visuals
Use ubiquitous iconography
Bulleted lists
Visual is small and not distracting
Few amount text
Hire / buy someone to create your graphics
Example: Fiver.com
Unguided tour by a question from the audience
May not be of interest to the rest of the audience
May not contribute to the presented material
Respectfully say it can be discussed afterwards individually
Be Prepared!
T-5 minutes
Drink some water
Engage with the audience
T-1 Hour
Prepare computers for the presentation
T-1 Day
Make multiple copies of the presentation
Repeatedly practice the material
If demoing code, run through them from beginning to end
Starting from blank slate
You're not done until you're done
Define what is meant by done, but then be fastidiously strict about it
Practice!
Get up, don't sit
It's OK to go through pieces of it if there are parts that are still unrefined
A talk needs time to mature
The topic doesn't reveal itself in the first presentations
Incorporate discussions after each talk to refine what the presentation is getting across to the audience
Be genuine and intentional on providing value
Engage empathy with the audience to understand their needs and desires for the topic
Secret Fool Proof Method
Start with by outlining
Pick 4 things you absolutely need
Human brains are not good at tracking more than 4 items
Keep the amount of major points low
Create story
Make logical progressions
Ordering
Chronological
Make sure the points are scaffolding with each other, the next elaborating on the previous
Desire an arch that connects all the points
Refine
Add details
Can evaluate the outline by adding the details
Can evaluate what is actually relevant to the audience
Remove cruft
Respect the audience's time
Be calm and measured
Maybe you won't go into the gory details
It can be a topic of the next presentation!
Focus on something and make it succinct and make it stick
Refine the outline
Start over from scratch
Squirrel away the exciting parts for you personally
What occurred the first time was your ego, not about the audience
Imposter Syndrome
The main reason it's OK for you to speak is because you followed the magic formula and properly prepared
Rules of Thumb (Silly Little Tricks)
Making 4 points is better than giving a "deep dive"
Prefer a infographics over a data table
Develop story as opposed to giving a garden tour
Avoid tangents and come back to the main topic if you find yourself straying
Discussions are more engaging than telling the points of the topic
Intro to Xamarin
Mrinalini Sinha
Mrin-Aah-Lyn-Ee
Mob programmer @ Hunter Industries
@mrin_sin
Synopsis
Xamarin is a cross platform development tool that I learned and used during my internship. It makes cross platform development quick, clean and effectively cheaper by having the code built by one team rather than divided into teams of native developers. Quick intro to what Xamarin is and how to get started.
Notes
What is Xamarin?
C# & .NET to build native apps
Targeting 2+ platforms but don't know iOS or Android dev?
Targeting native app for 1 platform without knowing the associated language?
Xcode & Objective C
Java & Android Studio
In a Xamarin project
C# shared business logic
C# UI in Android, iOS, Windows Phone
Why Xamarin?
Leverages C# & .NET
Open source
Xamarin.Forms - iOS SDK & Android SDK
It's as if you developed in the native development environments
Windows phone - .NET
Visual Studio = nuget packages (eg. HTTP Client, Json.NET)
LINQ support
Lambda Functions
Async & await, tasks
Access to classes like Collections
Getting the UI right
Different platforms, different paradigms
Xamarin.Forms: a UI toolkit
A bit of shared UI code
Allows us to build with XAML
Layer of abstraction between projects
Xamarin vs Xamarin.Forms
Xamarin
.NET environment for iOS, Android, and macOS
Runtime, common classes, asynchronous
Xamarin.Forms
UI
Code Reusability
Xamarin app = native app, code in C#
Xamarin.Forms = native app, code in C#, UI in XAML
Target Platforms
Android, iOS <-> Mac (OSX)
Android, Windows <-> Windows
Mac build host will connect a Windows machine to a OSX machine to allow iOS, Android, and Windows phone
Xamarin.Forms
A UI toolkit
Provides a native UI abstraction
No real Xamarin label/button
At runtime, the Xamarin label is translated to the platform-native label
Underlying platform accessible
UI: XAML, controls data binding, event handling
Building the UI
Xamarin.Forms componentsL Views, Layouts, and Pages
Views
widgets/controls
Buttons
Entry fields
Labels
Date picker
etc.
Layouts
Structure to UI
Types
ContentPresenter
ContentView
ScrollView
Frame
TemplatedView
STackLayout
AbsoluteLayout
RelativeLayout
GridLayout
Pages
A place to hold views & layouts
ContentPage
MasterDetailPage
NavigationPage
Bar & back button
PushAsync(page)
PopAsync() (back button)
Navigational behavior
How to get started with Xamarin
Choose multi-platform app in Visual Studio
May or may not have to select Xamarin
Portable vs shared class library
Portable class library
More of a completed project
Shipped as an assembly across different platforms
Shared class library
Shared code is referenced from other projects and then built into the using project
Xamarin Test Cloud
Test your app on thousands of different devices
Automated UI tests running on each platform, each device
Screenshot of failures
Parting thoughts
Inevitable it will be necessary to learn the underlying platform
Cross platform development is always complex
No Xamarin.Forms designer yet
Communicating With Code -- Tests That Don't Suck
Chris Stead
@cm_stead
Synopsis
When we write tests around code, not only are we verifying that the underlying behaviors adhere to specifications, we are telling the next programmer about how our program works. We will move beyond simply verifying behavior and start communicating effectively about our program.
Notes
Why do we say we test?
Safe to change
Capture information about bugs
Verify correct behavior
Meet code coverage
Better reason to test: Communicate
Good tests should have:
Description text should declare intent
Named variables expose meaning better
Complex objects can be extracted away
Assertions should ensure full proper behavior
Give insight by making more clear what is being tested
Tests that communicate
Inform other developers of original intent
Important to be written close to the time the code was written
Ideally before the code was written
Exemplify API use
Show what it really means to use the API
Deepen understanding of code contracts
Expose criteria for correct behavior
Writing great code is like writing a great story
It never happens in a single pass
Where do we start?
Sometimes choosing the right place to start is the hardest thing you'll do all day
Here's what to do
Extract variables fist
Define and test with output type
Build factory for setup data
We don't care about the stuff in the setup data, but the types around it
This way we can say more about it
Update description
Introduce golden master test for completeness
Why go that way?
Extracting variables is fast and easy
Part of this is healthy refactoring
You possibly have a tool that helps do this
Good types are descriptive
Data factories remove noise
This is nontrivial
Declarative code leads us to better descriptions
Golden master tests are great, but harder to setup
Domain modeling for the fearless
Signet types allow for rich verification
Show that the output type is what we expect
Factories for fun and profit
Declarative test data with DataMother
Factory generates spec
A well-described test
Choice words make all the difference
All the way through the test leads back to what's right, wrong, how to correct wrongs
What is our contract and what do we adhere to
Bonus round: Verifying data for great justice
Using approvals to ensure data correctness
Golden Master framework
Fewer mocks, the better
If you have too many mocks, it becomes difficult to know if you're testing your code or the mocks
Mock not only stands in place for something, it also expectations
A stub doesn't care about the expectations as long as you adhere to the contract
It doesn't care if things are right or wrong, or how many times it's called
The takeaway
Tests should do more than exercise code
All good tests should facilitate communication
Documentation + tests is doubling your effort
Documentation should be able to be auto-generated from the tests
The right tools can ease testing turmoil
Programming Arduino Robots with Visuino
Boian Mitov
Mitov Software
mitov@mitov.com
Synopsis
Will demonstrate how easy it is to program your own Arduino based robots with Visuino to autonomous, or remote controlled:
Infrared Remote Control
PS2 Controller Remote
Reading sensors and remote control from computer or mobile device over Bluetooth
Navigate around obstacles on their own
Follow line
Notes
What is Arduino from a hardware point of view?
Low cost, open source hardware micro-controller board
Resilient, difficult to damage hardware
Huge number of clones and boards; new coming every day
Simple to use for hardware designs
Very good for real time tasks
What is Arduino from a software point of view
A uniform development environment and API for multitude of platforms
Supported by many non "Arduino" based devices such as Teensy, Edison, Galileo, Curie, Femto,IO, ESP8266, ESP32, FreeSoC2, Maple Mini, and many more...
Allows easy code sharing between different hardware platforms
Why use Arduino for Robotics?
Very low cost. Some devices as cheap as $2 or less
Large number of digital and analog channels
Large number of connectivity options over Ethernet, WiFi, Bluetooth, GSM/GPRS, and many others
Large variety of sizes starting with a small coin size to a palm size boards
Large amount of available peripherals, including sensors, driver motor boards and actuators
What are the Arduino challenges?
Very primitive and cumbersome development tools, difficult to learn and use
Requires relatively low level programming
most people have no problem connecting hardware to it, but they get lost in the programming side
Lack of easily available programming side
Lack of easily available debugging tools
When used for collecting data, there is no easy way to visualize it
Visuino comes to play
Graphical development environment for Arduino
Automatically generates Arduino code, and programs the boards
Built in data visualization
Direct mapping of software and hardware components
Provides uniform communication over serial, or socket based channels
Demo used Elegoo Smart Robot Car Kit V3.0
Last updated