January 11th, 2019
Today was the final day at CodeMash. I went to several sessions, including: "Real Pirates Seek the C!", "Hardware is from Mars, Software is from Venus", "Autonomous Microservices", and "Building an AppSec Program". I also jumped in a session where they discussed agile practices.
I'm going to make some quick notes about what I learned and what I found to be surprising.
Real Pirates Seek the C!, presented by Clay Dowling:
C is probably best known as a procedural language but it supports functional and object oriented programming. It's a language that seems to have a very close relationship to the operating system. Consequently, some concepts you'd have to consider include memory allotment and default state.
Some surprising things about C:
Hardware is from Mars, Software is from Venus, presented by Kimberly Clavin and Clay Dowling:
In the industry, software and hardware teams should work together, but, more often than not, they don't. To start the session, Kimberly and Clay asked the audience: You are starting a project...should it be software driven or hardware driven? They followed up by asking which was more important between performance, agility, and cost. It's interesting to consider which side leads the project by default, which ends up receiving more lead time, and why unplanned costs occur. Rather, the challenge is how these two sides communicate with each other initially and as requirements change. Cross communication needs to happen early and often. A lack of communication will lead to higher costs (either manufacturing or development costs). Given the complexities of issues and knowledge gaps across teams (all of which will impact the work of each area), at the very least, I would recommend that there be an advocate that has knowledge of both domains that can advocate for each area and help these teams work together. This advocate would have to value knowledge sharing and communication. I think this would prevent conflict and manage costs associated with timeframes and knowledge gaps. However, Kimberly and Clay concluded that projects should be systems driven, not hardware or software driven. A systems driven process calls for design and iteration integration across both domains.
Some surprising things about the relationship between hardware and software:
Autonomous Microservices: This session was sponsored and presented by Couchbase.
A monolith system functions as a single autonomous unit. When the application needs to be scaled or when some functions need to be modified, the entire application needs to be rebuilt. A microservice architecture is a solution for scaling and maintaining application functions with ease. Instead of a monolith system, modular units make up a system. These units are microservices. They can be written in different languages or use different database storage techniques. The system is more flexible in terms of scalability and deployment. Matthew Groves from Couchbase described some principles to deal with distributed systems, asynchronous communication, and databases.
Some surprising things about microservices:
Building an AppSec Program from the Ground -- An Honest Retrospective, presented by John Melton:
In this session, John shared his experience building an AppSec program from scratch. He discussed his proposed quarterly deliverables, results, and lessons learned. He joined an acquired startup where there were no people that purely focused on security. His tasks included updating HR and tech training programs, addressing security gaps, and preparing the team for compliance. He approached his journey by embedding himself in the culture and environment. During his first quarter, he took time to learn about the team and its existing tools and processes. He made a point about not coming into a new place and suggesting changes right away, but instead investing time in learning about the environment. He also completed static, dynamic, and dependency analysis. He said that starting with metrics was important especially when you're in an environment where your recommended processes are not currently in place. He took application inventory to show deployment states, testing history, and server information. After evaluating the lack of processes and cleaning up credential storage, he focused on updating the SDLC, completing threat modeling-sessions, and tracking attack surface. Throughout his journey, he found value in forming relationships with key stakeholders, making security part of the developer culture instead of something seen as needing to be separately integrated, and developing methods to rank and communicate vulnerabilities.
Some surprising things about his journey:
The staff did a great job hosting the multifaceted conference. There was a robust selection of session topics geared towards various skill levels and interests. The sponsors and staff were all welcoming and passionate about software. I'm excited about next year's conference!