Home

A puzzle solver/developer passionate about integrating cybersecurity best practices throughout the development lifecycle. My work prioritizes both user experience and data protection, creating technologies that foster positive, transparent, and trustworthy relationships between humans and technology.

I'm Annie Schalnat,

Designed, developed, deployed, and continuously maintain an ecommerce website for ProTec Accessories, leveraging Stripe for secure payments and Tailwind CSS for responsive design.

> <div style="text-align: center"><https://protec-accessories.netlify.app></div>



Collaborated with a team to create a restaurant review app designed specifically to support small businesses, personally contributing the backend models and server-side development utilizing a MERN stack. Authorization using JWT

<div style="text-align: center">[*https://good-eats.onrender.com/*](https://good-eats.onrender.com/)</div>



Team Development

Freelance Development

Developed a brewery locator app that retrieves and displays nearby breweries within a user-defined distance radius, leveraging Bulma CSS for responsive design and Node.js for server-side logic.

Team Project

Projects

Over September 11-12, I was fortunate to attend SBOM-a-rama, a critically important conference hosted by CISA, America’s Cyber Defense Agency. CISA exists to mitigate risks in the cyberspace ecosystem and manage critical infrastructure of the United States, but represents just one sector of many that are molding and evolving the future of cybersecurity globally.

## Day 1

With speakers and participants from multiple countries and many industries, including \~ but not limited to \~ government, healthcare, software development, and supply-chain security. The agenda for the day was strategically set to maximize presentations while permitting time for questions and discussion. As the ballroom fills, the excitement is palpable as people connect with long-distance coworkers and colleagues, some of whom they communicate with weekly but are just now meeting in the flesh. Participants take their seats and at 9am sharp the convention begins. Across technical and legal divides, there is a unitary, glimmering goal of industry wide collaboration. Specifically, there is a call to action from many for global data normalization, standardization of naming conventions and component identification. The working goal is to reach a single SBOM approach that is compatible with distinct and extensible use cases.

This is where the solidarity fractures. Specifically, to what extent is disclosure necessary in order to secure vulnerabilities and enhance technological trust and transparency? Documentation outlining the minimum requirements for a Software Bill of Materials (SBOM) exists, but as experts from across the globe exchange views on the current problems in cybersecurity, it is evident that these regulations require further deliberation. There is a consensus from many that sharing data is the way forward. But this solution presents complications in data ownership, legal sovereignty, and the real world implications of a global data lake, from storage to privacy and protection.

As the discussion progresses it is apparent that there must be a proprietary distinction between internally shared SBOM data and readily available SBOM data. Interconnectivity between security and development teams is a must, so how do we foster communication flow inside and outside of an organization?

### Day 2

Beyond the future of SBOM generation, vulnerability tracking, and risk management sits a team whose goal is to determine a standard for transparency and trust in AI models. Of the many Tiger Teams that tackle various issues, the AIBOM team may have the largest challenge. In a field as largely unregulated as Artificial Intelligence, standards for trust and transparency are critically important. But what can &/or should be disclosed? 

In between the hustle and bustle of the tech solutions showcase, the AIBOM team gathers with other brilliant minds in cybersecurity and software development to discuss and debate the standards for transparency. While most support the inclusion of training data and model weights in this proposed AI Bill of Materials, experts point out that it can take years to refine the model weights and that level of detail should not be open source or available. 



Reflecting On SBOM-a-rama 2024

My experience in ASU's FullStack Development bootcamp has rewired the way I code, and entrenched my love of learning. I will never know everything; rather, I can learn *anything.* This blog post does not seek to teach coding principles, but to share a few brief examples of the things I learned that are shaping me.

##### Finding a style: Experimenting with Workflows

Coming from coding as a hobby, my workflow was scattered and dependent upon my level of interest in the project; I could spend 5-10 hours a week, or invest 60 hours in 4 days. There are zillions of workflows for every brain, but I found consistency and success working with agile methodologies. With an iterative approach, I could be responsive to unexpected changes instead of frustrated. Branching off main to experiment with alternate options and new features saves the hurt of breaking working code. I am a perfectionist, so focusing on generating a MVP (minimum viable product) for each project allowed me to use excess time to add my stretch goals. By prioritizing the user & interactions over processes & tools, the processes or logic came naturally.

Well not entirely natural - there was a lot of drawing diagrams and flows, daydreaming of the final product, and thinking through each step from file organization to integrating APIs and more. In my workflow, each file starts with comments of *what* I am trying to do. As I code, when I think of other features or functionality I would like to add I update my kanban board for the project on GitHub. With columns for every stage of development, it is easy to keep track of how much needs to be done.

##### Conceptualizing Goals

By thinking through the logic needed to accomplish said goal, I am priming my brain with the concepts needed to code in any language. Just as humans across the globe speak a multitude of languages to convey the human experience, the meaning matters more than the exact syntax or dialect in which one speaks it. By deepening my understanding of programming concepts, I am better prepared to code in any language. Regardless of the syntax, concepts and best practices apply.

Of all the best practices taught, the one I repeatedly use everyday happens to be **DRY**: Do Not Repeat Yourself. Functions are intended to execute one specific *function,* so it follows that the code to execute that specific task only needs to appear once. When working with React or other languages/libraries, code reusability saves time, space, and creates a seamless template for rending any kind of data. As my professor taught us, if you have to type the function twice in the project, could it be imported? Additionally, ternary operators and ways of condensing logic from long, drawn out if...else and switch case statements help keep code clean and concise.

##### Team Communication

With 3 group projects across the 24 weeks of bootcamp, I learned rapidly that communication isn't just important - it will save you hours. From the first group project where tension built up because no one understood each other or their code, to the last where we reached our MVP in 3 days, the night and day difference is a direct product of better group communication. By establishing a communication flow in a groupchat on Slack and repeatedly updating the team on my work, the rest of the team joined in and contributed updates, questions, and resources. As a result, we avoided working on the same features, solved bugs much faster, and were able to go for our stretch goals with 10 days left until the project deadline.

Overall, I am grateful for this opportunity and developing the ability to *read* code, rather than just assemble it.


Bootcamp Takeaways

Recent posts

It is 2023, and robotic baristas are beginning to fill the role of the friendly face serving consumers their morning coffee. Algorithms and artificial intelligence recommend us new products, playlists, and services; we have come to rely on these powerful computers that fit in our pockets. As humans continue to invent ways to make life more convenient, technological assistants are becoming routine.  Many popular AI interfaces such as Siri and Alexa, as well as physical robots like Zora are designed with anthropomorphic cues to mimic human interactions. Whether intentionally for comfortability, or unintentional, anthropomorphism greatly influences the way researchers and engineers design robots. By centering human-like qualities such as bipedalism, complex language use, and human social cues as “best," developers overlook the opportunity to build a new kind of relationship with robotic and virtual assistants.

Humanoid social robots, or HSRs, are man-made machines that “learn” from a given data set, appear in physical and virtual forms, and are designed to interact with and mimic humans to various degrees. By definition, describing a robot as humanoid in its appearance cues implies that the robot is designed to be perceived similarly to people. Humans are capable of generating hundreds of thousands of nonverbal behaviors and expressions, a range beyond technology’s current capabilities… but the future is coming, and what then? Robots of today can demonstrate form anthropomorphism via sensory cues like voice and/or physical appearance, but even the most advanced are distinguishable from their human counterparts due to a lack of behavioral anthropomorphism. As humanity continues to integrate technology into nearly every aspect of our lives, research is necessary to inform fabrication and marketing decisions. 

## Key Questions

1.  Are existing theories about interpersonal, human-human communication applicable to studying human-machine communication? 

2.  Are there differences in communicative scripts between human-human and human-robot interactions?

3.  Should the goal of robotic designers’ be to mimic humans?

In human interpersonal connections, social exchange theory makes sense. Relying on the fundamental assumptions that humans require resources for survival, social exchange theory says we attain resources via exchange with other humans, and humans inherently seek to maximize benefits or rewards while minimizing costs. Resources can be tangible, such as food/water/shelter, or abstract like status or self-image. In this context, humanoid social robots fall under the category tangible goods category, restricting the ability for humans to form relationships comparable to human-human interactions. As a product, the robot is fundamentally designed to be of service to humans, to be owned rather than own resources that could be exchanged socially as this theory posits. Created to be servile, there is a permanent inequity as HSRs are inherently designed to maximize benefits for humans, leading the autonomous human actor to make unilateral decisions based on one self-serving principle: maximize human benefits and never mind the robot.

Forming interpersonal relationships is analogous to peeling an onion, as relationships evolve over time through the process of mutual self-disclosure. As humans bond and comfortability increases, the layers of the “onion” or the individual’s life experiences are shared. These layers are characterized by breadth, or the range of information shared, and depth, which involves core beliefs, ideals, and values the individual relates to their self-concept. Frequency of communicative interactions between humans increases the breadth and depth of conversational topics, deepening human-human relationships. 

In contrast, HSRs are limited in their capacity to distinguish between users, and the breadth and depth of their experience is limited to the training data set. While there are convincing arguments that humans can form meaningful relationships with robots like in “The Jessica Simulation” by journalist Jason Fagone, predominant interpersonal communication theories about relationship formation and development are not applicable to human-robot interactions. As interpersonal research continues to seek explanations for human mannerisms, a distinction must be made between human-human communication and human-machine communication. Furthermore, research must expand on interpersonal communication models, adjusting for the assumption that both interactants have human status. To truly understand human-machine communicative scripts, longitudinal research is needed to assess relational development and account for technological experience levels.

As humans continue to integrate artificial intelligence into so many aspects of our daily lives, it is of critical importance that we understand human-robot interactions. From a theoretical perspective, communication constitutes reality; without communication, there would be no organizations or societal structure. Ultimately, existing interpersonal theories stand as a Turing test, a basis of comparison for how human-like a HSR can be, but models must be adapted and created to conceptualize human-robot interactions.



Citations:

Schalnat, A.E.(2023). *Applying Interpersonal Theories to Humanoid Robots.* Arizona State University.

Fagone, J.(2021). *The Jessica simulation: Love and loss in the age of A.I.* San Francisco Chronicle. <https://www.sfchronicle.com/projects/2021/jessica-simulation-artificial-intelligence/>




