<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.3.4">Jekyll</generator><link href="https://teachla.uclaacm.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://teachla.uclaacm.com/" rel="alternate" type="text/html" /><updated>2026-05-12T01:45:31+00:00</updated><id>https://teachla.uclaacm.com/feed.xml</id><title type="html">ACM Teach LA</title><subtitle>ACM Teach LA is an non-profit outreach organization at UCLA dedicated to providing equal access to computer science education for all students in Los Angeles.</subtitle><entry><title type="html">‘26 Winter Quarter Review</title><link href="https://teachla.uclaacm.com/blog/quarter-review/2026/04/15/'26-winter-review/" rel="alternate" type="text/html" title="‘26 Winter Quarter Review" /><published>2026-04-15T05:00:00+00:00</published><updated>2026-04-15T05:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/quarter-review/2026/04/15/&apos;26-winter-review</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/quarter-review/2026/04/15/&apos;26-winter-review/"><![CDATA[<p>This Winter Quarter of 2026, Teach LA entered its WINTER ARC. Dev Team continued producing their superb educational programs, reaching new area topics designed for the needs of the contemporary youth, while Curriculum also chartered new courses. This quarter was not of complacency, but rather of reaching towards the STARS. The winter nights can get lonely, but with Teach LA by our sides, I think our members would agree the ostensibly difficult winter was a whole lot more fun.</p>

<ul>
  <li><a href="#bot-lab">Bot Lab</a> - Dev Team</li>
  <li><a href="#static-site">Static Site</a> - Dev Team</li>
  <li><a href="#algorithm-team">Algorithm Team</a> - Dev Team</li>
  <li><a href="#training-team">Interns</a> - Dev Team</li>
  <li><a href="#fairburn">Fairburn</a> - Curriculum Team</li>
  <li><a href="#beethoven">Beethoven</a> - Curriculum Team</li>
  <li><a href="#react">React</a> - Curriculum Team</li>
  <li><a href="#emerson">Emerson</a> - curriculum Team</li>
  <li><a href="#conclusion">Conclusion</a></li>
</ul>

<h2 id="bot-lab">Bot Lab</h2>

<p>We all know that feeling. You’re doomscrolling Reels (becuase we ALL do that), and suddenly you get a notification: someone has requested to follow you! You’re excited (who’s this new person interested in my life???) until you check the username and it’s juliaxxx29867. BOT ALERT!</p>

<p>That’s disappointing, but at least you can identify who the bot is. Young kids nowadays, though, may not have developed that crucial online literacy. To help with that, the Bot Lab Team has cooked up a NEW project, crafting a lot of new components from scratch. Part of this lab is two games: a maze game called the SLAM Gam, and an educational “Is This a Robot?” game. It’s all very cute, may I add.</p>

<p><img src="/img/posts/26-winter-quarter-review/bot lab.jpg" alt="Bot Lab Stage Preview" /></p>

<h2 id="static-site">Static Site</h2>

<p>This quarter, it was all about healing for Static Site. We redesigned our project page, added a schedule page, and even brought back our blogs! There was some obstacles, such as lower attendance, but nevertheless, we stuck the landing.</p>

<p><img src="/img/posts/26-winter-quarter-review/inception.png" alt="Static Site Page" /></p>

<h2 id="algorithm-team">Algorithm Team</h2>

<p>Do you want to be unemployed?</p>

<p>Everyone will answer “No,” but everyday you don’t do your LeetCode, you’re basically saying “Yes.” However, LeetCode and DSAs are kind of difficult to master. So why not start them young? This lab is meant to help young people learn DSA in a fun and creative way! SOme of the algorithms we cover (through games and fun activities) include BFS, merge sort, and binary search!</p>

<p><img src="/img/posts/26-winter-quarter-review/linear search.png" alt="Algo Page" /></p>

<h2 id="interns">Interns</h2>

<p>Our Dev Team Interns had some fascinating projects. From AI-powered college recommendations, to awesome Figma Designs (what the Figma?), to backend visualizations. Our interns were cooking like 5 star Michellin chefs. We were eating good.</p>

<p><img src="/img/posts/26-winter-quarter-review/figma.png" alt="Intern Page" /></p>

<h2 id="fairburn">Fairburn</h2>

<p>When our editor went down (it ultimately was revealed as an issue of unpaid subscriptions), our Fairbun team (Tiff and Neil) faced an interesting challenge. How would they continue teaching kids about Python loops and variables without an active IDE? However, being the intelligent teachers they are, they settled on using fun worksheets to continue educating their students. Hats off to them, may they have luck in the post-grad world!</p>

<p><img src="/img/posts/26-winter-quarter-review/fairburn.jpg" alt="Intern Page" /></p>

<h2 id="beethoven">Beethoven</h2>

<p>Clara, Anusha, and their team moved on from Python turtle to Python data structures! Their quarter was filled with arrays, lists, tuples, dictionaries, stacks, and queues! Their team also had some significant bonding by being involved in an Uber court case???</p>

<p><img src="/img/posts/26-winter-quarter-review/beethoven.jpg" alt="Beethoven Memory" /></p>

<h2 id="react">React</h2>

<p>Michael and Shayla tried finding a new school…AND THEY DID IT! Now, they’re going to be teaching at Whitman High School. That’s not all, folks, as they’ll be moving on from React to the Unity Game Engine! Only thing more awesome than this is Chainsaw Man!</p>

<h2 id="emerson">Emerson</h2>

<p>When the editor went down, Javier and Bhavesh were very concerned. They had switched from teaching Python Turtle to teaching Web Dev (specifically HTML and CSS). Yet, they found a workaround: using W3Schools to let the kids make their own website using HTML. Their plans were thrown a bit off course, but adaptation was possible. Oh, and the brainrot continued, duh.</p>

<p><img src="/img/posts/26-winter-quarter-review/emerson.jpg" alt="brain rot knowledge from emerson team" /></p>

<h2 id="conclusion">Conclusion</h2>

<p>All roads lead to Rome…and Teach LA! This quarter has had its ups and downs, from attendance to editor outages, but our teams have continued to strive in the midst of it all. Give a round of applause to our Teach LA teams! See y’all for the Spring recap!</p>]]></content><author><name>Javier</name></author><category term="quarter-review" /><category term="blog" /><category term="reflection" /><category term="quarter-review" /><summary type="html"><![CDATA[This Winter Quarter of 2026, Teach LA entered its WINTER ARC. Dev Team continued producing their superb educational programs, reaching new area topics designed for the needs of the contemporary youth, while Curriculum also chartered new courses. This quarter was not of complacency, but rather of reaching towards the STARS. The winter nights can get lonely, but with Teach LA by our sides, I think our members would agree the ostensibly difficult winter was a whole lot more fun.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/26-winter-quarter-review/cover.jpg" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/26-winter-quarter-review/cover.jpg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">‘25 Fall Quarter Review</title><link href="https://teachla.uclaacm.com/blog/quarter-review/2026/02/01/'25-fall-quarter-review/" rel="alternate" type="text/html" title="‘25 Fall Quarter Review" /><published>2026-02-01T05:00:00+00:00</published><updated>2026-02-01T05:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/quarter-review/2026/02/01/&apos;25-fall-quarter-review</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/quarter-review/2026/02/01/&apos;25-fall-quarter-review/"><![CDATA[<p>As the final autumn leaf drifted to the ground, the Fall Quarter of 2025 came to a close. Over these months, our teams created countless memories and meaningful accomplishments that we are excited to share with you, and that leads to our new quarter review blog!!! Every effort, challenge, and success played an important role in shaping our journey. So let’s begin!</p>

<ul>
  <li><a href="#cookie-jar">Cookie Jar</a> - Dev Team</li>
  <li><a href="#static-site">Static Site</a> - Dev Team</li>
  <li><a href="#bias-by-us">Bias By Us</a> - Dev Team</li>
  <li><a href="#training-team">Training Team</a> - Dev Team</li>
  <li><a href="#fairburn">Fairburn</a> - Curriculum Team</li>
  <li><a href="#beethoven">Beethoven</a> - Curriculum Team</li>
  <li><a href="#react">React</a> - Curriculum Team</li>
  <li><a href="#emerson">Emerson</a> - curriculum Team</li>
  <li><a href="#conclusion">Conclusion</a></li>
</ul>

<h2 id="cookie-jar">Cookie Jar</h2>

<p>Get ready! Our delicious cookies are fresh out of the oven! Cookie Jar is a playful yet educational project designed to teach students about the cookies they encounter every day while browsing the web. From helpful cookies such as session cookies—which improve efficiency and security—to harmful ones like zombie cookies that track and harvest user data, Cookie Jar helps students understand both sides of this digital technology.</p>

<p><img src="/img/posts/25-fall-quarter-review/cookie.png" alt="Cookie Jar Stage Preview" /></p>

<p>Throughout development, Mirabel and her team faced the challenge of building a full-stack website with user login and signup functionality all within a single quarter, but they have mastered the art of baking. The team successfully crafted 6–7 distinct game stages, implemented a reward system that allows players to purchase in-game cookies, and designed a charming, approachable interface. With winter approaching, now is the perfect time to visit Cookie Jar and explore some digital flavors you may have never encountered before.</p>

<h2 id="static-site">Static Site</h2>

<p>As our most important online platform, the Teach-LA Static Site continues to evolve and improve. This quarter, Static Site Director Jishan and his development team focused on refining the user experience and modernizing the website to reflect our current curriculum and organization.</p>

<p><img src="/img/posts/25-fall-quarter-review/site.png" alt="Event Page" /></p>

<p>Their work included fixing minor bugs, redesigning the Classes and About Us pages, revamping the Blog and Team pages to resolve formatting issues, and creating a brand-new Events page to showcase our past activities. Despite being a team of mostly new members, strong communication and an agile workflow allowed them to achieve their goals successfully. As Jishan proudly put it, “Agile to save the day.”</p>

<h2 id="bias-by-us">Bias By Us</h2>

<p>Our identities, shaped by background, family, religion, ethnicity, and experiences, make each of us unique. At the same time, they also influence our behavior, decisions, and perspectives, often without us realizing it. This is the central idea behind Bias By Us, a project developed by Manager Charlene and her team.</p>

<p><img src="/img/posts/25-fall-quarter-review/bias.png" alt="Bias Example" /></p>

<p>Through interactive sessions such as case studies, research analysis, and a survey-based game, students learn how bias can affect everyday choices, including something as simple as food preferences. By the end of the experience, students gain a deeper understanding of how bias shapes our viewpoints and why people may arrive at different decisions. Ultimately, the project encourages reflection, empathy, and self-awareness.</p>

<h2 id="training-team">Training Team</h2>

<p>Stories will be passed down, and so is knowledge! This quarter, Training Director Megan guided 14 students as they took their first steps into frontend development. Despite a shorter schedule due to breaks, the team covered the fundamentals of HTML, CSS, JavaScript, React, and Git.</p>

<p>Every one of them demonstrated strong progress, earning an impressive average score of 11 out of 12 on the knowledge assessment and completing a final mini-project. We are excited to see these students continue building their skills and look forward to welcoming even more learners in future quarters.</p>

<h2 id="fairburn">Fairburn</h2>

<p>In their very first quarter working with students, Lead Neil, Tiffanny, and their team focused on building strong connections—both with their students and within the team itself. Lessons were filled with fun and creativity, including activities like a candy cane drawing competition that helped foster engagement and creativity.</p>

<h2 id="beethoven">Beethoven</h2>

<p>Led by Clara and Anusha, the Beethoven team introduced students to Python Turtle fundamentals. Throughout the quarter, students learned basic turtle commands, loops, variables, and conditional statements. According to the team, the most meaningful moments came from getting to know each student’s personality and learning style.</p>

<p><img src="/img/posts/25-fall-quarter-review/beethoven.png" alt="Beethoven Memory" /></p>

<h2 id="react">React</h2>

<p>Due to scheduling conflicts with their partner high school, the React curriculum team temporarily paused instruction this quarter. However, School Lead Michael and Curriculum Lead Shayla are already working on finding a new school partner and look forward to resuming classes soon.</p>

<p><img src="/img/posts/25-fall-quarter-review/react.png" alt="School Search" /></p>

<h2 id="emerson">Emerson</h2>

<p>With many returning students from last year, School Lead Javier and Bhavesh reviews Python turtle concepts with a flash, the team creatively incorporated current internet humor and “brain-rot” references into lessons, making the material more relatable and enjoyable. Looking ahead, the team plans to transition into HTML and CSS, giving students an exciting new way to continue learning code.</p>

<p><img src="/img/posts/25-fall-quarter-review/emerson.png" alt="brain rot knowledge from emerson team" /></p>

<h2 id="conclusion">Conclusion</h2>

<p>As the blog comes to an end, we are incredibly proud of the dedication, creativity, and growth demonstrated across all teams. From innovative web projects to meaningful student interactions, this quarter was filled with fun, progress and purpose. With these experiences behind us, we will move into the next quarter with hope, ready to build even more impactful learning opportunities together!</p>

<p><img src="/img/posts/25-fall-quarter-review/group.jpg" alt="group picture" /></p>]]></content><author><name>Thomas</name></author><category term="quarter-review" /><category term="blog" /><category term="reflection" /><category term="quarter-review" /><summary type="html"><![CDATA[As the final autumn leaf drifted to the ground, the Fall Quarter of 2025 came to a close. Over these months, our teams created countless memories and meaningful accomplishments that we are excited to share with you, and that leads to our new quarter review blog!!! Every effort, challenge, and success played an important role in shaping our journey. So let’s begin!]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/25-fall-quarter-review/cover.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/25-fall-quarter-review/cover.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">‘21-‘22 Dev Board Reflections</title><link href="https://teachla.uclaacm.com/blog/reflection/2022/09/22/board-reflections/" rel="alternate" type="text/html" title="‘21-‘22 Dev Board Reflections" /><published>2022-09-22T05:00:00+00:00</published><updated>2022-09-22T05:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/reflection/2022/09/22/board-reflections</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/reflection/2022/09/22/board-reflections/"><![CDATA[<p>It’s been a hectic board cycle this year, going from a singular dev team president to eight different board members and restructuring midway through the term. These major changes, compounded with our growing number of members (90 members*, and 15+ projects over the year), made for a challenge as we navigated defining our roles together. With that, let’s see what our board thinks about their year!</p>

<ul>
  <li><a href="#top-links-for-the-year">Top Links</a></li>
  <li><a href="#archie">Archie</a> - Design Director</li>
  <li><a href="#jiin">Jiin</a> - Learning Labs Director</li>
  <li><a href="#matt">Matt</a> - Dev Team Training Director</li>
  <li><a href="#tim">Tim</a> - Editor Director</li>
  <li><a href="#regina">Regina</a> - Internal Dev President</li>
  <li><a href="#pictures">Pictures</a></li>
</ul>

<p><sub><sup><em><code class="language-plaintext highlighter-rouge">*</code> - defined as attending 1+ meetings outside of the intro meeting, or contributing to our development</em></sup></sub></p>

<h1 id="top-links-for-the-year">Top Links for the Year!</h1>

<ul>
  <li><a href="https://teachla.uclaacm.com/">Our Website!</a></li>
  <li><a href="https://github.com/uclaacm">Our Github</a>!</li>
  <li><a href="https://github.com/uclaacm/teach-la-dev-training">Our Training Repository!</a></li>
  <li><a href="https://docs.google.com/document/d/1N3GIkuhAfvubtdkt8KkNLHttMsohORV8vEqqw3u-wAQ/edit">Our Goals for the year!</a></li>
</ul>

<h2 id="archie">Archie</h2>

<p><em>Position: Design Director.</em></p>

<p>Allow me to set the scene of how my TeachLA journey began. It’s my freshman year and I had just gotten an interview for the dev intern position. It’s going great until I hear Matt say, “So I see that you’re experienced in HTML/CSS/JavaScript?” Crap. I forgot I had that on my resume. Well sure, I am. Only if you call scraping together a few header tags and changing the background color of an html file made in Notepad “experienced”.</p>

<p>As you can predict, dear reader, I did not do so great in that part of the interview. Nevertheless, I got the position! From there, I worked on Buffer Buffet and actually did learn about HTML and CSS. However, as I quickly found out I was very bad at what I was supposed to be doing (React) and very good at what I was not (design). And that’s how this position came to be! TeachLA has a lot of amazing developers (not me) but a severe lack of design infrastructure. As design director, my job was to be the point of contact for all things aesthetically pleasing.</p>

<p>The first project I worked on was BoolBots. I came into this project via a Slack message from a stranger and a very questionable set of robot illustrations. I came out of it with one of my best friends and a much less questionable set of robot illustrations. People always say that CSS is their least favorite part of web dev, but there was something so satisfying about seeing my vision come together on the screen from a pile of HTML tags.</p>

<p><img src="/img/posts/21-22-reflections/archieImg1.png" alt="Picture of BoolBots website" /></p>

<p>When the school year started, I was asked to work on a redesign for No Filter. I’ll be honest, this was the design I’m least proud of this year. It’s also the one I learned the most from. I spent so much time trying to come up with a creative design, that I didn’t think as much about how the design would fit the content and making sure it met accessibility standards. After this project, I learned to design for the content of the site instead of fighting it.</p>

<p><img src="/img/posts/21-22-reflections/archieImg2.png" alt="Picture of no filter website" /></p>

<p>The next project I worked on is my favorite. Many years ago, TeachLA had tabled a potential learning lab about hex codes because we didn’t have the people to work on it. When I heard about that, I was disappointed. It sounded like such a cool project and I wanted to work on it! Eventually, I realized that nothing was stopping me from just doing it. So I did. During winter break, I sat down and coded for days on end. As previously mentioned, I am very bad at React so this was quite a process. But after a lot of hard work, Color Lab was born. Color Lab was the first TeachLA learning lab made by one person (with some help from Matt and Nathan ty guys &lt;3). It was also probably the last to be made in this way. Nevertheless, I’m proud of creating this small piece of TeachLA history.</p>

<p><img src="/img/posts/21-22-reflections/archieImg3.png" alt="Picture of Color Lab website" /></p>

<p>Winter quarter rolled around, and I continued with the BoolBots team to work on IfBots. We were all adjusting to being back in school, so the progress was pretty slow at first. However, after a <em>fun</em> night (let’s just say that I truly lived the college experience), I decided I needed to prove that I could still code. Don’t ask about the logic behind that because there is none. Nevertheless, I ended up accidentally doing half the project, so I consider my point proven.</p>

<p><img src="/img/posts/21-22-reflections/archieImg4.png" alt="Picture of IfBots website" /></p>

<p>Finally, it was spring quarter. The dev board was buzzing with excitement during the process of finding new interns. We weren’t planning on getting a design intern, but I was still excited to see the TeachLA family grow. Then, one day I got a Slack message from Matt asking if I would be down to take on an intern. At first, I thought he had the wrong person. But no, there was a candidate who was interested in design! So, this quarter, I’ve been teaching my wonderful intern Angela all about Figma, CSS, and all things design. We’ve also been working on a new design for the TeachLA static site. Keep an eye out for it launching soon :)
Overall, I would like to thank everyone in TeachLA for being such talented developers and wonderful friends. I’m so excited to keep working with you next year as Outreach Director!</p>

<h2 id="jiin">Jiin</h2>

<p><em>Position: Learning Labs Director.</em></p>

<p>This past year was a very interesting period for Teach LA’s dev team as we went through a lot of new developments transitioning to an 8-person team and going back in-person/hybrid. We started off the year in spring 2021, when UCLA was still completely virtual. The main challenge for me this quarter was taking on the Learning Lab Director role and figuring out what exactly the role means, since it had not existed before. I received a lot of advice and guidance from Matt Wang, the previous Teach LA president who had kind of been doing the responsibilities of the “Learning Lab Director” (except he also had a lot of other responsibilities on his plate, which is why this new 8-person structure came to be). I ended up inheriting 6 project teams to manage: Dev Pathways, Cookie Jar, Selector Safari, Bias by Us (which I was PM-ing), No Filter, and Getting Mean about Error. Since I definitely was not familiar with all of these projects, I spent some time having one-on-one meetings with the PMs for each of these projects to understand where they are at and what kind of help they would need from me, their new go-to person.</p>

<p>As the quarter passed, I came to notice some common issues found within the Learning Lab teams. The three main issues were:</p>

<ol>
  <li>
    <p>PMs and team members were either losing interest in their project or becoming busy with other committments</p>
  </li>
  <li>
    <p>Learning labs were given to teams without enough ideation/information being fleshed out, leading to them not knowing what exactly to build</p>
  </li>
  <li>
    <p>Learning labs teams often lacked a Point of Contact to communicate with</p>
  </li>
</ol>

<p>I unfortunately wasn’t able to really resolve these issues within the quarter which led to most of the teams eventually falling through. Although this situation was pretty demoralizing, being able to recognize these problems helped me kickstart one of the dev team’s most successful projects: BoolBots.</p>

<p>BoolBots is a Python Boolean learning lab that was requested by Teach LA’s Python curriculum team. This is the first learning lab that was created during my time as the Learning Lab Director, so I really wanted to make sure that it would go well. The PM for the project was Nathan Endow, and he and I spent spring quarter preparing for the project to be built over the summer. I made sure that Nathan would get to communicate with Robert and Nikhil, the leaders of the Python class, and gather enough information from them about what they wanted from the Learning Lab. I also tried my best to relay quality advice to Nathan based on what I had learned from leading Bias by Us and being the Learning Labs Director. Throughout this process I ended up communicating a lot with Nathan and checking on his ideation work. Once Nathan got his team, it was smooth sailing from there – I checked in every once in a while to make sure things were going okay, but Nathan was such a natural at PMing that I really didn’t need to help much at all! The dev team is really lucky to have him :)</p>

<p>I also channeled what I had learned into the Learning Lab PM workshop, which was the first workshop I had ever hosted! I was pretty nervous but was happy to hear that many people appreciated it. I eventually ended up making a second, more improved version later on, which I’ll talk about later.</p>

<p>Whew I just wrote a ton about spring! Then came fall 2021, UCLA’s first quarter back in-person since a long while! This was definitely a challenging time for the dev team as a whole because we had to accommodate the insane amount of new people that joined the club on top of transitioning in person. To help with this I spent a decent chunk of the quarter helping Regina who was leading the React team, by finding and assigning tickets to people who already had React experience and answering any questions they had about code. As for Learning Labs, my main accomplishments this quarter were writing the Project Proposal document and Project request form (huge shoutout to Regina for helping on this), and helping Getty start the RNN lab and Nathan start IfBots (the 2nd Python learning lab after BoolBots).</p>

<p>Winter 2022 was a little less hectic as the dev team had settled into our in-person/hybrid format. This quarter I took on my own React Team! My team consisted of people who tended to have at least a little bit of experience with React but still wanted to practice. I spent a bit of time inheriting the Dev Pathways project from Einar, the previous PM, and then used that project to assign tickets to the people on my team. In addition to tickets I usually spent ~20 minutes in the beginning of the meeting teaching more advanced React concepts like useContext to the team. By the end of the quarter our team had gone through a lot of tickets, and I was super proud to showcase the enhancements we made during Demo Day:)</p>

<p>I also taught an updated version of the PM workshop from spring. I was especially proud of this one not only because of the great reception but also because the updates I made helped me reflect on just how much I learned about PM-ing and the general process of leading a team within the time I had been Learning Lab Director. I also led a Design workshop/critique session with Archie which ended up being a ton of fun! In terms of learning labs, I helped Prem kickstart the Turtle learning lab (now called Pen Pals) in a similar manner as I did with Nathan’s learning lab. I also continued helping the RNN lab, but this one eventually fell through in spring because of inherent issues with the learning lab topic, such as scope and complexity, that unfortunately didn’t really get sorted out in the beginning steps. This lead to a lot of back and forth within the ideation step, and it took two whole quarters to get the hi-fidelity mockup. Luckily Nikhil from AI was very responsive and collaborative, but despite this the team still went through a lot of bumps in the road.</p>

<p>In the end of winter, I ran for Dev President and got the position uncontested! My main goal coming into the position was to find an optimal structure/process that works best for the dev team. If this past year consisted of a lot of experimentation and trial and error, I now wanted to ensure that Teach LA goes on a more stable, solid track by figuring out what worked well and applying that. But before I could do this, I needed a new team! Thankfully I had Archie and Timothy with me again, except Archie would now be the Dev Outreach director instead of the Design Director. This was a new position that was created sort of in replacement for the previous Learning Labs Director position, since that role ended up having a lot of overlap with the Dev President’s role. The Outreach director role would focus on the deployment of new project teams, whereas the Dev President would focus on maintaining/managing the teams we have. Anyways, with Archie and Timothy there were still 5 more roles to fill. With the help of Matt Nieva, an ex-training director, the four of us interviewed 10 people over spring break, and by the beginning of the year I had my new team! Most of the new officers ended up being our interns from winter quarter, except for Nathan who had already been a solid contributor to the dev team. Despite this outcome, I would suggest the future Dev President to continue opening the officer roles to all members – we came across some very outstanding interviewees who were not interns.</p>

<p>I spent the spring quarter mainly settling in the new team and keeping the dev team afloat through the transition. I assigned people to new and old project teams with the help of the fellow officers, and hosted dev team meetings and board meetings in new rooms. In terms of projects, this quarter we kickstarted the Pointers lab, Linux lab in collaboration with ACM Cyber, the Python For Loops lab, and planned for a collaboration with ACM AI. I took the lead on helping Colbert and his Pointers lab team get started, along with communication with the AI dev team since I am also an AI officer, while Archie took the lead with the Cyber collaboration and For Loops lab.</p>

<p>And that’s a wrap! It’s truly been an eventful year and I’ve learned a ton from it. I truly hope that to engrain everything that we learned into the dev team’s operations, and I’m confident that the 2022-23 dev board will be able to have the Teach LA dev team flourish even more :)</p>

<h2 id="matt">Matt</h2>

<p><em>Position: Dev Team Training Director.</em></p>

<p>Overall, I’m pretty happy with the way this year turned out! It wasn’t just UCLA that had their first year fully in-person since the start of the pandemic, it was also mine and the other second-year’s first time being in college in person! Honestly, the first couple of weeks were a blur, getting to finally meet TeachLA homies who I’ve only “e-met” on Zoom, to meeting so many incredible people. However, we had our work cut out for us. For the first time ever in TLA history, we distributed the giant weight that the previous two pioneers of the dev team, Matt Wang and Leo Krashanoff, across 8 different team members all working to keep TLA going.</p>

<p>As a training director, working together with the other lovely training directors Regina and Ellie, the massive undertaking of both organizing the curriculum into three separate training tracks and creating took place:</p>

<ol>
  <li>Introduction to Web Dev and Static Websites</li>
  <li>Introduction to React and Dynamic Websites</li>
  <li>Introduction to Backend Principles</li>
  <li>(A bunch of miscellaneous topics like advanced React, deployment, etc)</li>
</ol>

<p>I’d like to say that this was a great tool that helped us standardize our training curriculum from year to year and that it’ll help lighten the burden for next year’s training directors as well. Something that we’ve been discussing ACM-wide is a way for us to push one of our many training resources as one to push as the de-facto ACM-backed guide to web development. I take great pride in the fact that we’re going to keep pushing the TeachLA dev-training repository and that I was able to be a part of the great team that helped make it a reality!</p>

<p>However, creating the training tools like the repository and actually teaching them to peeps in-person were two completely different beasts. So many things to keep in mind like:</p>

<ol>
  <li>How do you keep people engaged in-person?</li>
  <li>How do you handle hybrid situations?</li>
  <li>How does partner-coding or lecture-style presentations work in large classroom settings?</li>
</ol>

<p>The largest thing I learned was that it’s so much easier to connect with people in-person as opposed to teaching on Zoom! Being able to see people face-to-face is truly a blessing after COVID and for the next training directors: something that I wish I could do better is to take advantage of the in-person medium! Whether that be through engaging more with people during lessons or doing more bonding activities like socials, I feel like I could’ve done so much more in the social aspect of TLA!</p>

<p>As I move on to other aspects of ACM like working with the dev team, I still use a lot of tools that we’ve built up through TLA like our web-dev training curriculum in order to help make our centralized web dev training that’s used by all of the interns, and we based our Dev Team Project Outline based off of the TLA Project Outline doc that TLA made this yr! I love the great symbiotic relationship that the ACM committees have with each other and will def use things from TLA moving forward!</p>

<h2 id="tim">Tim</h2>

<p><em>Position: Editor Director.</em></p>

<p>This year the TeachLA dev team saw a lot of changes, both to the internal board structure as well as how we generally operated. It was also the first fully in-person year I had at UCLA. Although this was a good change of pace from the previous year, which was fully remote, it also came with its own host of challenges. For example, especially nearer the start of the year, there were often communication and productivity issues due to the hybrid format we were using.</p>

<p>In terms of board changes, this was the first term in which the dev team had a formal group of board members, which distributed the workload as the club and its operations expanded. When I first joined the dev team, basically everyone was working on the editor, with additional projects like the learning labs being pretty far out on the horizon. It’s been a real pleasure working with everyone, both old and new faces, and watching the club grow to its current state. I hope to continue to see the club grow over the next year, and also in the future after.</p>

<p>Over my past few years at UCLA, I have been working on the TeachLA Editor in various ways. The last couple of years saw me formally leading the editor team, and it was definitely an interesting experience for me. The work that I oversaw included both refactors to the Go backend, as well as incremental changes to the upcoming classes feature. This allowed me to both try out management, as well as hone my technical skills. I am very proud of everyone who was on my team, even if they did not stay the entire year.</p>

<h2 id="regina">Regina</h2>

<p><em>Position: Internal Dev President, Dev Team Training Director.</em></p>

<p>All in all, it’s been a great year. We’ve had a lot of work cut out for us as we navigated supporting around 90 members over the course of the year, and over 15 projects. In addition to that, we trailblazed going from one dev team president to coordinating with eight board members. I really couldn’t have asked for a better board to do it with. Before I start on the rundown of the year, I’ll get a bit sentimental. :’)</p>

<p>—
	Looking back on the time I had with Teach LA,  I remember all of the fun times, the chats, the hangouts, the camaraderie of being a team, the friends I made who I know have my back, the kickback, the late nights, the last minute grinds, the offering food when I wasn’t eating much, the real “let me know if there’s anything I can do to help”, and the follow throughs. Going from being really anxious and shy, and “everything is my job and problem” from Playnet all the way to where I am right now is honestly because of Teach LA and the opportunities I’ve had here. Being here has been an essential part of my college experience, and I definitely would not be who I am without it. I know I’m theoretically “helping others” by teaching React or reviewing resumes, or giving tips, or this and that, but to be quite honest, the community helped me even more. Thank you to the friends I made, to the people that I trust, and to everyone who I have ever worked with, truly. If there’s ever anything I can do to help, my door is always open :)
—</p>

<p><strong>Year Rundown!</strong></p>

<p>In spring, we started with a new structure on Zoom, where we had three training directors, each leading a training track individually. Ellie led a HTML/CSS track, introducing members to some basic information about web dev and HTML/CSS. I led a React track, which introduced slightly more experienced members to React, a well known frontend development library, and other web dev topics such as design, backend, and CI/CD (huge shoutout to Archie and Leo for helping out with those!). Matt led advanced React and related workshops, introducing advanced hooks and routing websites to experienced members who were working on learning labs (projects). Jiin also led a project management workshop, which introduced terms and good practices in leading projects.</p>

<p>Ellie, Matt, and I put in a lot of effort as we each created a curriculum for our hourly weekly meetings, with some help from a <a href="https://github.com/uclaacm/learning-lab-crash-course-su20">previous training repository</a>. To help engage with our peers’ learning, we held weekly office hours, created content videos for those who missed sessions, set up projects for them to do if they wanted, were readily available whenever members had questions, checked in on them regularly, and gave them important work to do (shoutout to Vivian and Tim for providing us with HTML/CSS and React tickets from <a href="https://teachla.uclaacm.com/">the static site</a> and <a href="https://editor.uclaacm.com/">the editor</a> respectively!). Besides this, with the increased board capacity, we also had the capacity to do individual one on ones with each of the new members to best place them on a training track.</p>

<p>Besides the training, Divya led the weekly dev team meetings and Vivian regularly communicated with the curriculum board regarding necessary updates to the static site. Near the end of the quarter, Matt and I had the idea to have a <a href="https://github.com/uclaacm/teach-la-ts-react-starter">new react starter template</a> that new projects could jump off from with typescript and yarn, based off of the newly finished and successful learning lab, <a href="https://github.com/uclaacm/Playnet">Playnet</a>, a collab between Creative Labs and Teach LA (shoutout to Bryan, Karen, Darren, Getty, and Trevor for working on that with me). We created the barebones template with typescript, React, yarn, effective linting, other CI/CD, and documentation with a lot of help from <a href="https://github.com/uclaacm/Playnet">the Playnet repository</a> (initialized by Bryan), and some help from the <a href="https://github.com/uclaacm/teach-la-react-starter-barebones">past javascript react template</a> plus Jiin, Archie, and Tim. 
Nathan started working on a new learning lab as well, and with Jiin’s project management help, Robert’s curriculum side insight, Archie’s design help, and some technical help from me, Nathan led a successful project, <a href="https://boolbots.uclaacm.com/">BoolBots</a>, regarding teaching booleans in python since students sometimes struggle grasping the concept. The learning lab went great – the code was clean and members working on it gained a lot of experience, and the game taught boolean concepts in an easily digestible way, and was used in our middle school classes as we taught Python. As Playnet winded down, and we taught over 90+ students about introduction concepts of how the internet works, Getty, along with Trevor and Darren, also kickstarted a LSTM Learning Lab project aimed towards making LSTMs easier to understand for the ACM AI Advanced Machine Learning Track students. A collaboration with ACM AI, Ava connected us to the right people, and Nikhil has been helping out consistently throughout to crank out that learning lab. Again with both of these, shoutout to Jiin for consistently providing PM support, and Archie for all her design support!</p>

<p>Finally, we also prepared for summer by creating a project allocation form and tried allocating members to learning labs. Unfortunately there weren’t enough learning labs for members to work on over summer, and some members who were on learning labs for the summer had nothing to work on since they weren’t ready to be worked on. This was an issue that we saw and worked to fix in the fall quarter. 
Over summer, we toned down what we worked on–Matt and I continued to host training sessions, and cleaning up videos and such for preparation for fall quarter, but that was about it.</p>

<p>Fall quarter was the most hectic quarter–with going in person, combined with covid concerns, most of the board never having been to any Teach LA meetings in person before, more structure changes, defining individual roles better, and recruiting interns as a team for the first time. Divya kickstarted the quarter with Sophie, the Teach LA curriculum board president, and we had tons of members join the first info session.</p>

<p>The quarter was starting off great, but the dev team president was a huge role fit for three people. The split to eight board members made organization and a vision even more important, and it was getting quite chaotic with so many ideas swirling around. Divya and I, with support from Sophie, decided to split the dev team president into two roles – External Dev Team President (EDP) and Internal Dev Team President (IDP). The EDP would handle the general members and the dev team meetings while the IDP would handle the internal workings, such as dev and curriculum board support and running the dev board meetings. Divya handled the EDP role, and I handled the IDP role. To handle the plethora of ideas and improvements that we could make, I created a goals document to realign all of us to a vision and we worked together to form goals together – that we wanted to improve project lead support and give dev team members a better experience, that we wanted to have a stronger alignment with curriculum, that we wanted to better define each of our roles, and that we wanted to improve board infrastructure for next year. (Shoutout to Matt Wang, Bryan, Biao, and several other leads of other organizations for giving advice!) See <a href="https://docs.google.com/document/d/1N3GIkuhAfvubtdkt8KkNLHttMsohORV8vEqqw3u-wAQ/edit?usp=sharing">our doc</a> for details.</p>

<p>To implement all of these took quite a bit of work and small changes, such as rebranding the React track to the React team and making a<a href="https://docs.google.com/document/d/13H1hAqdWyx-Sz-MVN0QUs3s4cY7aRujKLznCJAVaULc/edit?usp=sharing"> Learning Lab Project Proposal Template</a> for potential Project Leads and <a href="https://docs.google.com/forms/d/e/1FAIpQLSfkb-KbCPacsVSMxX_ayzf1hNYY5tpr-XhQAeOCzu2Xl4A-TA/viewform?usp=sf_link">Learning Lab Request Form</a> for people interested in having learning labs made for them, shoutout to Jiin for making these! Besides these structure changes, we worked together to define our own roles, sometimes stepping on each other’s toes while moving quickly to accommodate the time sensitive nature of the quarter system. It was only in fall that we finally all met each other in person, had a dev board social and one on ones, worked together to quickly solve problems, helped out board members who had too much on their plates–it was a great and collaborative environment where we all worked towards a common goal of giving dev team members a great first taste of practical software engineering and teaching them what they wanted to learn, along with creating useful products for curriculum and other organizations to teach with.</p>

<p>We also had to figure out how to select members and interview for gathering interns. We had a tight deadline of around a week from finding out who our 40 candidates even were, to laying out <a href="https://docs.google.com/document/d/16YxgDZoSdYqwbhXmQQnEe2ww8ye_e_ngOu2buvusTn8/edit">what intern roles we needed</a>, to making <a href="https://docs.google.com/document/d/1dNI_e26F_4Kz44QrmOGEUJgTvRyYYWvPI-xuTnONOe4/edit?usp=sharing">interview and application evaluations guidelines</a> (with huge inspiration from how the curriculum board does things and with a lot of help from Vivian), to interviewing around 8 candidates, to selecting 5 interns for winter quarter, to deciding on a timeline for internships.</p>

<p>Altogether, in fall quarter, when what we did was quite time sensitive, the dev board really came together and we were able to establish precedence for future years in terms of things such as roles, internships, and dev team support.</p>

<p>Between fall and winter quarter, Archie led a learning lab, Color Lab, which teaches students hex code as a standalone event or as a supplement to when we teach students Python Turtle so that they enjoy coding more as they choose their own colors.</p>

<p>Our final quarter together, winter, was a lot more well balanced and relaxed after the busy fall quarter. We had our six interns, Getty, Evan, Nick, Angela, Darlene, and Prem, and each intern had a mentor (Jiin, Ellie, me, Archie, Vivian, and me respectively), and we had weekly one on ones with our interns to align them to intern goals. Each intern had goals that we proposed ideas for, which we came up with in fall, such as PMing a project, working on static site redesign, or leading training workshops. We also worked with the curriculum team to have more relevant projects and so that they could meet more people–shoutout to Robert, Milo, Nikhil, and Advaith for being part of that! During the last board meeting, we had interns present their deliverables and takeaways.</p>

<p>Besides the internship developments, we started to passoff leadership and prepared for the next cycle of board by making slight improvements to the way the dev team was being run. Since in the quarter before, there were too many people on my React team for me to support each one well individually (around 20 members), this quarter we opted to prioritize quality of support over number of supports. To this end, we opened up a project application form which listed the different projects available and the time commitment and effort that the member was willing to put in. Throughout the quarter, we had 38 applications, 4 learning lab teams (s/o to Prem for leading <a href="https://github.com/uclaacm/pen-pals">Pen Pals</a>, Nathan for leading <a href="https://github.com/uclaacm/ifbots">ifBots</a>, Nick for leading <a href="https://github.com/uclaacm/selector-safari">Selector Safari</a>, Getty for leading <a href="https://www.figma.com/file/h1IaRmqb7YK3AW78pQL7mz/tLA-LSTM-Learning-Lab?node-id=444%3A20">LSTMs</a>), 3 React teams (s/o to Jiin for leading the experienced React team, Matt for leading the React team for those new to it, and I led the remaining React team, which also included 2 people from other schools), and 2 other teams (s/o to Vivian for leading <a href="https://github.com/uclaacm/teach-la-website">the static site</a> team and Tim for leading <a href="https://editor.uclaacm.com/">the editor</a> team!). It was a successful quarter in that every member on a team was well supported since each team was capped at maximum 7-8 members, and they were given the proper attention and support that they deserved from board members to have a great experience.</p>

<p>The quarter culminated in a Demo Day, which we kickstarted this quarter to give teams an opportunity to showcase to what they worked on this quarter, to show those interested in collaborating with us what we could make and what we had available, and to give teams a goal to come together to meet. We teamed up with the curriculum special events team to market and publicize the event, make a design request, create slides and come up with an event structure, and get food to provide at the event. The <a href="https://docs.google.com/presentation/d/1dMHeOzI3S4PczOJIPkky4LKt_m-CRdRp4VFfZVH-5Zs/edit?usp=sharing">event</a> went great and it was definitely a nice end to the quarter and our term.</p>

<p>Altogether, this year was great for the Teach LA Dev team. We worked on over 15 learning labs, including ongoing ones from previous years like <a href="https://github.com/uclaacm/bias-by-us">Bias by Us</a> and <a href="https://github.com/uclaacm/no-filter">No Filter</a>, see <a href="https://teachla.uclaacm.com/dev#projects">our website</a> for our full list, and affected around over 90 members. We supported the curriculum team in their work to bring computer science to the underserved K-12 communities and came together to form an inclusive and welcoming community. We overcame the growing pains of splitting from a single board member to 8 and were able to provide support to members in training them from the ground up. It’s really been a pleasure serving as Internal Dev President for Teach LA this hectic year, and I know that Jiin and future presidents will continue to improve Teach LA Dev even more!</p>

<h1 id="pictures">Pictures</h1>
<p><img src="/img/posts/21-22-reflections/sliderPic1.JPG" alt="Picture of a board kickback" />
<em>Board Kickback!</em></p>

<p><img src="/img/posts/21-22-reflections/sliderPic2.JPG" alt="Picture of Archie, Matt, and Jiin" />
<em>Archie, Matt, and Jiin</em></p>

<p><img src="/img/posts/21-22-reflections/sliderPic3.JPG" alt="Picture of a dev board picnic social" />
<em>Dev bord picnic social</em></p>

<p><img src="/img/posts/21-22-reflections/sliderPic4.JPG" alt="Picture of Teach LA Board and interns at ACM Banquet!" />
<em>ACM Banquet with Teach LA Board</em></p>

<p><img src="/img/posts/21-22-reflections/sliderPic5.JPG" alt="Picture of dev board going rooftop exploring!" />
<em>Rooftop exploring!</em></p>

<p><img src="/img/posts/21-22-reflections/sliderPic6.png" alt="Picture of Teach LA board at ACM All Hands!" />
<em>ACM All Hands</em></p>]]></content><author><name>Archie, Jiin, Matt, Tim, and Regina</name></author><category term="reflection" /><category term="blog" /><category term="reflection" /><summary type="html"><![CDATA[It’s been a hectic board cycle this year, going from a singular dev team president to eight different board members and restructuring midway through the term. These major changes, compounded with our growing number of members (90 members*, and 15+ projects over the year), made for a challenge as we navigated defining our roles together. With that, let’s see what our board thinks about their year!]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/21-22-reflections/cover.JPG" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/21-22-reflections/cover.JPG" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">‘20-‘21 Board Reflections</title><link href="https://teachla.uclaacm.com/blog/reflection/2021/03/28/board-reflections/" rel="alternate" type="text/html" title="‘20-‘21 Board Reflections" /><published>2021-03-28T04:00:00+00:00</published><updated>2021-03-28T04:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/reflection/2021/03/28/board-reflections</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/reflection/2021/03/28/board-reflections/"><![CDATA[<p>We’re just in the process of transitioning to our new board, and we wanted to take some time to reflect on this past year! It’s been an unexpected set of challenges in some unprecedented time, but we’re also so proud of all the work that we’ve done. Here are some thoughts from our wonderful board members!</p>

<ul>
  <li><a href="#chase">Chase</a> - React Native Lead</li>
  <li><a href="#helia">Helia</a> - Python Videos Lead, JEDI</li>
  <li><a href="#kaitlyn">Kaitlyn</a> - Special Events Director</li>
  <li><a href="#leo">Leo</a> - Dev Team Director</li>
  <li><a href="#nina">Nina</a> - Special Events Director</li>
  <li><a href="#regina">Regina</a> - Special Events Director</li>
  <li><a href="#robert">Robert</a> - Emerson Lead</li>
  <li><a href="#sophie">Sophie</a> - Logistics Director, JEDI</li>
  <li><a href="#matt">Matt</a> - President</li>
</ul>

<h2 id="chase">Chase</h2>

<p><em>Position: React Native Lead.</em></p>

<p>Uncertainty is scary, but from that uncertainty comes incredible experiences that simply could not have been planned. I seemingly accepted the React Lead position on a whim; I barely knew it and had no idea how I’d teach it, let alone teach others how to teach it. I guess I just wanted the opportunity to contribute, and I felt like the chance to develop and lead a completely new class was something there was no way I could pass up. Even though I was sorely lacking in experience and knowledge, I was wholly confident that my motivation to make technology accessible to the next generation of diverse engineers would be more than enough to make the class a success. I embraced the uncertainty.</p>

<p>Myself and our president, Matt, got to work almost immediately. We built a roadmap, started writing lesson plans, and began to recruit instructors to teach in the Fall. Our outreach team (lead by Chloe) worked tirelessly to find schools that we’d be able to teach at. We met with Facebook engineers to develop a deep understanding of the fundamentals of React. We emerged from that summer with a splendid plan, something that we were proud of and something that would empower us to reach a lot of kids who wouldn’t necessarily have access to technology education otherwise. But the best-laid plans…</p>

<p>The pandemic wasn’t getting better. We didn’t even know if we could find a school that would be able to support remote learning. We didn’t know how we’d be able to teach from home, we didn’t know how we’d coordinate lesson plans, and we didn’t know how we could even get feedback from our students. We were going in completely blind. We eventually did find a school, North Hollywood High School, and we did figure out how to connect remotely (a <strong><em>lot</em></strong> of zoom). The first few iterations of the class were pretty rough. I and a lot of our instructors weren’t completely comfortable teaching, especially over zoom, and it was hard to know how the kids were doing, since they were mostly muted with their cameras off. On the fly, we came up with solutions like using google forms and kahoots for feedback, and using that feedback we began to improve the class, and as we became more comfortable with teaching we started to get into a groove. But of course, such a peace could not last.</p>

<p>Remote learning hit everyone hard, including our instructors. Being full time students, it was hard to make this class a priority, so we ended up having a lot of turnover. Being the leader of volunteers presents a unique challenge: <em>delegating work is a balancing act, you need to get things done, but burning out your team is dangerously counterproductive</em>. With that in mind, getting to know my team was extremely important to me, so I could understand which team members could handle what, when. I definitely wasn’t perfect at this, but I was blessed with a group of individuals who were extremely motivated, bright, and passionate about our mission, and I have no doubt that without them, this class wouldn’t have been possible. Even the people who contributed sporadically were integral to making sure that we could teach every week.</p>

<p>We’re entering our third quarter teaching this class, and honestly I’m still not exactly sure how we’re going to do it. Our time slots are still unpredictable, our students are sometimes there, sometimes not, and we’ll still have to wrestle teaching this class with our full time class schedules. But despite all of those hurdles, we’re still going to do it. Flexible we’ve been, and flexible we will remain. We’re unified by our passion for making technology accessible, and together we’ll see this insane year through. Even though we could wish for this year to have gone smoother, the bumps in teaching this course will make it that much better when next we can teach in person. That I am sure of.</p>

<h2 id="helia">Helia</h2>

<p><em>Position: Python Video Lead, JEDI.</em></p>

<p>I joined Teach LA winter quarter of my freshman year. As a then-CS student, I realized I probably should be involved in some kind of CS extracurricular by that time, and I chose Teach LA specifically because it worked with kids. Not because I liked kids, but because when I was a kid I always thought college students were so cool, and now that I was a college student myself I wanted to fan my ego and bask in the admiration of today’s children. I still wasn’t super involved then, though, and was even less involved the following quarter. It was the beginning of the pandemic and I was having a hard time doing anything other than gaining weight and reading my favorite childhood novels until 4 AM. But also, I hate having responsibilities. I usually either psych myself out of taking them, or force myself to take them and then flake out. This is why I live in constant fear of the looming inevitability of succumbing to capitalism and finding a job, and why I didn’t get that involved, and didn’t plan to ever join Teach LA’s board or lead an entire team to make videos on Python. But then there was this shiny new thing called JEDI as we neared fall, and I was very interested in it. Justice, equity, diversity, inclusion. There was a visible lack of it within ACM and the CS community at UCLA, and people wanted to change that. It aligned nicely with my interests; the reason I wanted to study CS in the first place, after the job security and pressure to pursue a STEM degree, was to fight the culture of prejudice and exclusion that permeates the field. So I said I wanted to become a JEDI. And they put me on the board. I had a really valuable time as a JEDI. The other JEDIs of Teach LA—Ashley, Chloe, and Sophie—and I, with help from Arjun and Matt, worked on things like accessibility in teaching, impostor syndrome, and community building within our committee.</p>

<p>As for the Python videos, I got asked to manage the breakout room for videos and I was like, I don’t know Python but yeah okay. I ended up taking on more responsibility than I expected—they made this new position for me, the “Python Video Lead”—but I knew things were going to be okay because in our first meeting, one guy made an active effort to talk to me and another laughed at everything I said. In the following weeks, we grew to eight members total, and we’ve had a really good time since. In addition to creating an entire series of videos about basic Python concepts for kids, we’ve had lengthy discussions on important topics like the legendary Harry Potter fanfiction My Immortal and whether haircut syncing with boys is anything like period syncing. Not to get emo in a blog post for a computer science organization, but personally, the past few months— especially fall quarter—have been a very uncool time. The Python video team is special to me not only because we had so much fun together, but also because it was pretty much the one place where I was never sad during the fall. It’s also where I learned I wasn’t all that bad at being a leader, after sitting on the sidelines for most of my life. So, thanks to everyone on the team: Props King Advaith for consistently being on top of everything, Ashley for being everyone’s biggest supporter, Austin for educating us on Armie Hammer, Drew for bringing Bike-short-for-Bichael to life, Einar for selling his soul to Final Cut, Seongbin for juggling video work with intern work and a weird neck rash and food poisoning and a different timezone, and Stephen for shaving his head like Avatar—among many, many other things. Each person brought an amazing energy to the group and I’m really proud of how much we bonded. Also thanks to Jun for randomly popping into the breakout room or joining us after 8:30 when we’re the only ones left in the meeting (thanks Sophie and Matt for that too, and occasionally other people), and thanks to Arjun for being such a great and supportive and cool JEDI lead. Lastly, thanks to Matt for running this year’s Teach LA and for his tireless work on everything from the icebreakers at every board meeting to the socials. It’s probably the first time I’ve ever felt so supported and comfortable at school, and that had a big influence on how well I was able to carry out my JEDI and Python video responsibilities. Every area of Teach LA this year has a bit of Matt in it, I think—not only because he was actually involved in everything and talked to everyone, but also because how he interacted with us as leads carried on to how we interacted with the members of our respective teams. So I’m really grateful for that, and I know everyone else is too.</p>

<h2 id="kaitlyn">Kaitlyn</h2>

<p><em>Position: Special Events Director.</em></p>

<p>To kick off the year, over the summer, our special events and dev teams collaborated with CityLab and ACM Cyber to organize Cyber Day - our first virtual event! Although the transition to online instruction was challenging, the two gorgeous learning labs (Passworks and Cipher Salad) created by our dev team really pulled the event together. Overall, the collaboration was a great introduction to not only what goes into planning an event, but also to the types of roadblocks we would have to anticipate when approaching remote teaching later in the year.</p>

<p>In late fall and winter quarter, we collaborated with BEAM to create a programming/robotics course using Makeblock’s mBots. This collab definitely had its own unique set of difficulties, even with the experience with remote instruction we had gained at this point. Sadly, physical, real-life equipment rarely performs exactly in the way you’d expect, and the issues that cropped up were even harder to diagnose and debug over video call. On the bright side, I’m still amazed that the robots were distributed to our students so smoothly! Massive props to Laurel and the BEAM logistics team, and especially to Matt for assembling like 30+ robots by himself in one night (whew).</p>

<p>As with all of Teach LA’s projects this year, conducting this class virtually required a lot of flexibility, whether it be in communicating with our school, handling surprise changes to our timeline, or working out issues with our robots. Thankfully our instructors and students were all very accommodating as we ironed out the wrinkles in our curriculum. Luckily for us, a class like this is honestly pretty fun by nature. Just having a robot to play with in person made things pretty exciting for the kids! (Even if the robots weren’t always working 100% of the time) Given what we’ve learned from the first iteration of this course, there’ll be plenty to consider as we begin restructuring and streamlining the curriculum for its next run in the spring.</p>

<p>This year has been uniquely challenging for everyone - for us, the instructors, for the teachers that so kindly give us time with their classes each week, and especially for our students. Not all of our plans worked out perfectly, and not all of our lessons were as clearly understood as we hoped. However, ultimately what was most important is whether our students felt comfortable and welcomed in our classes - and hopefully that our time together was enjoyable to them. CS is absolutely an intimidating and confusing field to begin to explore. It doesn’t take much to feel discouraged in the face of such a monolith. But on the other hand, a single fond memory may help spark a lifelong interest in the end.</p>

<h2 id="leo">Leo</h2>

<p><em>Position: Dev Team Director, Editor Team Lead.</em></p>

<p>How do you go about reengineering a backend? Well, like any project, you’d start by tearing down the excess, coordinating with the rest of your team… But what about a dev team? These two questions were at the crux of this term in a completely digital academic year for Teach LA’s editor subteam and the dev team at large.</p>

<p>Things were going strong in our first online quarter as Teach LA joined forces with ACM Cyber and CityLab for our first major completely-online event, which brought the basics of cybersecurity to schools throughout LA. However, as the reality of quarantine started to sink in for the dev team, a few issues started to rear their heads.</p>

<p>Teach LA’s dev team has always maintained a policy of being open to new members as an entry for students of all levels into computer science. Even online and catapulting into appreciable growth over the prior year, we didn’t want to change this. However, the growth was nothing what we anticipated. I think that to call the growth of Teach LA’s dev team astronomical would be an understatement.</p>

<p>The dev team grew from ~20 members to well over 40 as of this writing. The interest form garnered some 75+ responses, and the first meeting of the quarter saw almost one hundred attendees. It was a lot. Far more than I think Teach LA was prepared to handle, and certainly far more than I personally was prepared to handle.</p>

<p>Luckily, our president, Matt, was able to step in to help the dev team adjust to the growth, and restructure its management. The internal changes to the dev team that were carried out this year will completely redefine its direction going forward. Instead of the monolithic precedent of prior years, the dev team has been organized into each arm of its surprising scale: learning labs, editor, and static site teams all have their own lead dev now. I directed the editor subteam this year, hence reengineering the backend, from the start of this blurb.</p>

<p>The editor team’s primary goal for the first half of the year was to switch from our unmaintained JavaScript backend to a brand new one written in <a href="https://golang.org/">Go</a>. To this end, we succeeded. The editor team was also able to initiate a few new exciting projects with our collaborative coding initiative, and continue progressing along longstanding projects like classes. Read more about the projects on <a href="https://teachla.uclaacm.com/dev">our dev page</a>!</p>

<p>All in all, it has been a tumultuous year for everyone. In the face of these odds, our dev team has expanded in both scope and size, adapted to its new conditions, and started up ambitious new inter- and intra-committee projects. I can’t wait to see what happens next for our organization going forward.</p>

<h2 id="nina">Nina</h2>

<p><em>Position: Special Events Director.</em></p>

<p>I joined Teach LA last year because of its mission to provide something that I consider myself quite lucky to have before coming to college as a CS major: prior exposure to and experience with CS. Computer science can be hard to grasp at first; from my own experiences in high school at least, there’s a certain intuitive leap needed for things to click, and it doesn’t really start making sense until that point. College is an entirely different beast from high school, with professors providing less direct guidance to students. As such, learning CS without any prior experience can be a much more frustrating and daunting endeavor. I wanted to help connect with other students so that should they wish to pursue CS in college and as a future career path, they would have a foundation to build upon.</p>

<p>Teaching was certainly an interesting and rewarding experience. I was mostly involved with the Python class at Emerson, and it was an enjoyable challenge to develop lessons every week and adjust our methods and the material we were going over based on how the students were responding and what was and wasn’t working. After all, isn’t it said that the best way to attain mastery of a subject is to be able to teach it to others? In the end, though, it was the flexibility, both for instructors and for students, and the variety of the speaker series and similar one-off events that really appealed to me, and so I became an intern to get more involved with them.</p>

<p>This was when the cybersecurity-themed collaboration with science educational outreach organization CityLab was just starting, and Regina, Kaitlyn, and I were invited to observe one of their event days to see how they operated. I really liked seeing how another organization approached teaching, how they incorporated a fun storyline into the day’s activities and pop culture themes into their workshops, all of which we could potentially take inspiration from for our own activities and events. After we became Special Events Directors, we planned to move forward with the collaboration, but then the pandemic hit and everyone had to transition to working remotely. Although the CityLab collaboration transitioned to a virtual platform, it still managed to go on in the end, which was in no small part due to the enthusiasm and dedication of everyone involved in the project. Major props to Alyssa, Leo, and the rest of the dev team for creating the amazing technical modules while we researched and designed the nontechnical module, and to our president Matt for providing the overall guidance for working together with CityLab. Getting to see the collaboration through to the end was very rewarding, especially since it was the first event I’d coordinated as Special Events Director.</p>

<p>It’s honestly been inspiring and humbling to see Teach LA making it through the transition to virtual learning and working remotely through the year so smoothly. The collaboration with BEAM and working with ACM-W on the upcoming Day of Code have all taken place in the middle of the pandemic. This year has not been easy, and I commend everyone for their dedication and passion. I have no doubt that Teach LA will accomplish even greater things moving forward, and I look forward to seeing it happen.</p>

<h2 id="regina">Regina</h2>

<p><em>Position: Special Events Director.</em></p>

<p>When I applied to be a special events director, I just wanted to expose underprivileged students to computer science and give them the opportunity to find their interest in it. As for roles, I didn’t know much of what to expect, and looking back it’s been a very rewarding experience. It was also a lot of fun collabing with other clubs and making curriculum with Kaitlyn and Nina, my special events co-directors.</p>

<p>Starting off, we collabed with CityLab to put together a curriculum for a Cyber Day. To be honest, this was the first time I’ve ever worked to set up something with another group, so I was quite lost on how to approach it and how to really get the collab going. S/o to Matt for providing guidance with that and being a great role model for how it should be done, in addition to Leo and the rest of the dev team for creating the super cute modules which we provided to CityLab. It was a great opportunity to teach the kids about cybersecurity and a great training ground for learning how to collab on a shared goal!</p>

<p>After that, in fall, Nina, Kaitlyn, and I coordinated a collab with BEAM for teaching the kids robotics. Though there were a lot of technical difficulties because it was online and it was robotics, it was a great experience. The kids were bound to have some sort of technical difficulties like how some of the kids’ cords didn’t work, or the code just wouldn’t upload to the robot, or just logistical difficulties with delivering robots. While there were a lot of issues involved and last minute changes in curriculum plans, I think at the end of the day, it went really well! The kids were really excited and happy, the collab went well, and even though the documents might’ve been a bit confusing, we laid a really great groundwork for a reusable curriculum for BEAM in the future. We also met Laurel and all the other BEAM people and are probably going to continue working with them, standardizing the curriculum for use in the future.</p>

<p>Continuing on, close to winter break, when ESUC reached out to our organization, I wanted to lead a booth for eWeek Kid’s Day by creating a learning lab website for it. It was rather last minute and Matt was able to help me quickly put together a solid team of 3 TLA dev members, s/o to Darren, Getty, and Trevor for doing some great work, and set up a collab with Creative Labs, in addition to pulling in Karen, our amazing designer who literally designed the whole website. In terms of Creative Labs, special s/o to Bryan and Arjun for being amazing and guiding the dev side of things, and Maggie for giving us great UI/UX feedback. We couldn’t have done it without Karen or Creative Labs, and I really appreciate all their help. Also in terms of brainstorming and curriculum, s/o to Nina and Kaitlyn for always being down to bounce ideas and having my back when I needed anything.</p>

<p>Going into leading this learning lab as a PM, it was challenging and scary and, looking back, I definitely could’ve been better at communicating, among a lot of other things. I helped the new devs out, even though I wasn’t necessarily qualified, and learned about design and accessibility with Figma. It’s been a very rewarding experience, and even though it was quite stressful at times, with everything planned out finally—the beta test being next week, the event a day after, and the second event in a couple weeks after that—I’m really proud of us for making such a polished Learning Lab. Most of all, I’m excited for the kids to learn how the web works and be amazed by it!</p>

<p>Overall, it’s been a great year with TeachLA. Surprisingly, even with this remote setting, the kids were all super excited to learn more, and I also learned so much about tons of different things. Even though I joined TeachLA two years ago to just have an opportunity to expose students to computer science, TeachLA has really grown to be more than that. It’s definitely been a good time and I’m excited to see what TeachLA will become in the future!</p>

<h2 id="robert">Robert</h2>

<p><em>Position: Emerson School Lead.</em></p>

<p>As a college student, getting up at 8AM is difficult for me. However, it’s been well worth it to do so for our weekly Tuesday class, because being a School Lead has been such a rewarding experience! Our team of instructors has had a wonderful time designing innovative curriculum materials and working with kids on some fun code. Although the virtual format for teaching posed some challenges for engagement, I’m proud of how we’ve been able to creatively problem solve and continually reflect on our teaching to give our students the best experience possible. Here’s a couple lessons I’ve learned leading a team of eleven amazing instructors (shoutout to Celebi, Dominic, Joshua, Jun, Lauren, Nico, Oscar, Remas, Samantha, and William!).</p>

<h3 id="keep-your-plans-flexible">Keep your plans flexible</h3>

<p>I’m the type of person that loves detailed plans—I remember I once planned a family vacation down to the hour when I was nine. However, I’ve learned that things almost never go exactly the way you planned them. For our Winter quarter, we originally envisioned teaching an ambitious curriculum that covered all the fundamentals of Python. Although parts of this curriculum plan worked in previous quarters, we quickly realized that our class would benefit from additional reinforcement of key concepts and focusing even more on project-based learning. We had to change our plans two to three times throughout the quarter as we continually gauged where the class was at. Despite the many changes, everything worked out great! Things don’t always need to be planned extensively to be done right.</p>

<h3 id="you-get-what-you-put-into-your-class">You get what you put into your class</h3>

<p>We’ve all had great teachers in our lives that have inspired us to learn. However, we often don’t think much about how much work it takes for them to prepare lessons that stick with us for years. The more time and effort that you spend making the curriculum exciting and interesting, the more engaged your students will be. During our Winter 2021 quarter, we were lucky to have a fantastic team of instructors that continually raised the bar on our curriculum materials. They created innovative ways to present our curriculum, from creating a “choose-your-own-adventure” booleans storyboard to making an interactive game of Jeopardy to close off our quarter. When we presented these fun and innovative activities, we noticed that the students were much more engaged in the material and were excited to dive into the coding. Of course, it is always a pleasure to teach students that love the material as much as you do.</p>

<h3 id="have-fun-with-everything-you-do">Have fun with everything you do!</h3>

<p>If you think the material is boring, so will your students—simple as that. If there’s any material that you feel is not interesting or not applicable, don’t be afraid to cut it out from the curriculum. We spent a lot of time refining and simplifying our curriculum to make sure that we taught just the essentials for our students to jump into coding. Our goal is always to increase exposure and awareness to computer science, not to lecture students about the semantics of programming. We also integrated lots of cool demos on other aspects of the tech field, such as machine learning and brain-computer interfaces, to show how exciting technology is. All of this helped immensely in making our class a more enjoyable experience for both our students and instructors.</p>

<p>I’m so grateful to have worked with such a great team of instructors. We do impactful work and make sure to have lots of fun while doing so. Can’t wait for what’s next!</p>

<h2 id="sophie">Sophie</h2>

<p><em>Position: Logistics Director, JEDI.</em></p>

<p>I joined Teach LA a little over a year ago after months of struggling to find a student organization on campus that I connected with. Thanks to its welcoming atmosphere and its incredible mission, I quickly became more involved by helping out with the Scratch class at Brockton Ave Elementary (shoutout to Pragati, Helia, and everyone else who I met on the Brockton team!). When board applications were released at the start of Spring Quarter, I wasn’t sure if I had a shot at becoming Assistant Logistics Director given my lack of experience and limited computer science knowledge, but I applied anyway. As cliche as it sounds, this may have been one of the best decisions I’ve ever made; I met some amazing people along the way, and I’m so proud of everything we’ve accomplished.</p>

<p>Following the transition to virtual learning, reimbursement requests and many of the other responsibilities typically associated with the Logistics Director role were no longer necessary. As a result, I spent most of my time planning virtual recruitment and took on the responsibility of creating pedagogy activities for the start of weekly curriculum meetings. Recruiting new members in traditional ways proved to be a more difficult task than I expected given that virtual club fairs do not typically have good attendance. Nevertheless, Teach LA grew exponentially at the beginning of the 2020-2021 school year, likely as a result of incoming freshmen searching for a sense of community in the face of pandemic isolation. Since many of these new members lacked teaching experience, I began to create weekly activities that took a similar format to the “Um Game” I remembered Matt introducing during one of the first Teach LA meetings I ever attended. Although some of these activities may not have been a success, I think many of our members appreciated the opportunity to learn more about pedagogy while simultaneously connecting with fellow instructors. Shoutout to Matt for all of his help with these weekly curriculum activities and to Nikhil for letting me hijack the first 15 minutes of his meetings!</p>

<p>Another important aspect of my involvement in Teach LA this past year has been the JEDI program. So many communities are excluded from tech and made to feel unwelcome in computer science and other STEM fields, so I want to do everything in my power to make Teach LA, and ACM in general, as accessible as possible to UCLA students of all backgrounds. The OCD + ADHD Allyship Space I hosted with Arjun may be one of my proudest accomplishments of college thus far. Getting an opportunity to share my experiences while discussing with and learning from others was unforgettable, and I want to thank Arjun and Sharvani for all of their hard work and dedication to the JEDI Program!</p>

<p>I’m so excited to take on a new role within Teach LA and can’t wait to see all of the incredible things we continue to accomplish this coming year (hopefully in person)!</p>

<h2 id="matt">Matt</h2>

<p><em>Position: President.</em></p>

<p>Wow, this has been an insane year. I didn’t expect for us to stay remote for all of it, but I’m so proud of how our entire team managed this transition. We shifted almost all of our classes to remote instruction over Zoom, and experimented with virtual Kahoots, take-home worksheets, demos-over-video-call, and all sorts of teaching methods. We even started a Python videos team, led by our own wonderful Helia! While we had some rough patches - especially struggling with engagement and attendance - I’m so proud of everything that our teaching team did. Shoutouts to our returning school leads: Nikhil &amp; Malak for Python, Arjun for AI &amp; ML; and our new school leads for our existing programs: Milo &amp; Eden for Scratch, and Robert for Python!</p>

<p>We also did quite a few new things on top of the virtual transition, and I’m grateful I had the chance to participate. We kickstarted our brand-new React Native class targeted towards high schoolers, supported by a team over at Facebook. I led the first few meetings, fleshed out the curriculum, and taught the first few lessons, but I want to give hats off to Chase for taking over as a school lead and dealing with all sorts of unexpected hiccups. We also collaborated with CityLab and BEAM to teach cybersecurity and robotics with Scratch respectively; huge shoutouts to Regina, Nina, and Kaitlyn for managing these new virtual collabs!</p>

<p>Under the amazing leadership of Arjun and Sharvani, Teach LA joined the brand-new JEDI program! Our superstar JEDIs - Ashley, Chloe, Helia, and Sophie - made great steps to make Teach LA a more inclusive community. They incorporated accessible content into our pedagogy trainings, ran a discussion-focused event on impostor syndrome, and overall took steps to make Teach LA a welcoming place to be! I loved supporting them, attending their meetings, and listening to them plan and discuss at brainstorms!</p>

<p>We also completely revamped the internship program this year! Working with our sage advisor Bonnie, we focused on three sets of key changes: a clearer and more inclusive application process, formalizing the training process, and creating practical hands-on projects. We did a lot to standardize our application process, including clear asks on desired skills, making sure that every application was reviewed and interviewed by at least three different people, and standardizing scoring. You can read more about our process in our <a href="/blog/internship/2020/12/16/internship-retrospective/">internship blog post</a>.</p>

<p>On top of those changes, we were much more involved in the winter quarter internship training process. We formed three cohorts - teaching, events, and dev - and paired interns with existing officers in the role. Cohorts met weekly or biweekly to work towards a final project, and worked on practical skills throughout the quarter! I specifically led the dev cohort, where Teach LA’s dev team ran <a href="https://github.com/uclaacm/tla-dev-intern-training-w21">a set of structured lessons</a> on topics ranging from React to CI/CD to intros for PM, design, and backend! Special thanks to Leo for helping out with a few of the training sessions, and Rucha + Karen for being guest speakers!</p>

<p>And finally, this reflection wouldn’t be complete without discussing our dev team. Due to some unforeseen circumstances, I stepped in as the interim Dev Team Director for Fall ‘20 and Winter ‘21. I had the pleasure of onboarding over 20 new developers over two quarters - which was equally tough as it was rewarding! Over the summer, Leo and I recorded our 18-video <a href="https://github.com/uclaacm/learning-lab-crash-course-su20">Learning Labs Crash Course</a>, which was a great learning resource and a step towards standardizing dev training. I led <a href="https://github.com/mattxwang/qwerhacks-21-workshops">our collaboration with QWER Hacks</a>, where I wrote, produced, and edited videos on React, Firestore, using them together, and the education track - which was so much fun! And, I ran our projects meetings, trying all sorts of new dev training techniques: from long-winded walkthroughs, to Kahoots with cash prizes, to quick code and tooling demos, and continual feedback in the process.</p>

<p>I also had the chance to kickstart some new projects! In fall, we started three new learning labs: <a href="https://github.com/uclaacm/cookie-jar">Cookie Jar</a> (on internet cookies) and <a href="https://github.com/uclaacm/selector-safari">Selector Safari</a> (on CSS selectors) run by Teach LA veterans Alyssa/Rachel and Lisha/Janis respectively; and <a href="https://github.com/uclaacm/bias-by-us">Bias By Us</a>, a learning-lab spearheaded by three first-years before the quarter even started (shoutout Jiin, Nareh, and Matthew). In the winter, Regina led our first collab with Creative Labs: <a href="https://github.com/uclaacm/Playnet">Playnet</a>, a tech demo/walkthrough of how the internet works designed for virtual fairs/booths. On short notice, we also scrambled together a team for <a href="https://github.com/uclaacm/dev-pathways">Dev Pathways</a>, an internal tool for ACM to consolidate its dev training resources; shoutout Einar, Christine, Nathan, and Nicole! Our static site ballooned in features, from more class pages to a blog and internal reports to a dev page. And, I wouldn’t be doing learning labs justice without introducing <a href="https://github.com/uclaacm/buffer-buffet">Buffer Buffet</a>, the dev intern project focused on addressing problems in CS33; special shoutout to Jamie and Alyssa for sticking with me on this one.</p>

<p>And of course, there is so much more I want to talk about, and so many more people I want to thank; but at the same time, you’ve probably got other things to do. All in all, I am so, so proud to have worked with all these amazing people to continue Teach LA’s mission: making CS education more accessible. If you see any of them, give them some props - they definitely deserve it. I’m definitely going to miss our graduating seniors: to Arjun, Bonnie, and Malak, thank you for sticking through with us until the end.</p>

<p>I’m also equally optimistic about our future. The new officers, interns, and president are leaps and bounds more mature and ready than I ever was. I’m excited to see Teach LA reach new heights; I hope you’re ready!</p>]]></content><author><name>Chase, Helia, Kaitlyn, Leo, Nina, Regina, Robert, Sophie, and Matt</name></author><category term="reflection" /><category term="blog" /><category term="reflection" /><summary type="html"><![CDATA[We’re just in the process of transitioning to our new board, and we wanted to take some time to reflect on this past year! It’s been an unexpected set of challenges in some unprecedented time, but we’re also so proud of all the work that we’ve done. Here are some thoughts from our wonderful board members!]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/20-21-reflections/cover.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/20-21-reflections/cover.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">New Year, New Blog</title><link href="https://teachla.uclaacm.com/blog/dev/2021/01/04/new_year_new_blog/" rel="alternate" type="text/html" title="New Year, New Blog" /><published>2021-01-04T04:00:00+00:00</published><updated>2021-01-04T04:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/dev/2021/01/04/new_year_new_blog</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/dev/2021/01/04/new_year_new_blog/"><![CDATA[<p>This past quarter, we finished implementing several new and exciting features for the Teach LA Blog! As new members of the Dev Team, this was our first experience working on a large codebase with many contributors. Because of this, there was some nervousness with committing changes that we feared would break everything. But alas, we did not break everything and we hope that these new features will be useful to our readers.</p>

<hr />
<h2 id="related-posts-and-post-images">Related Posts and Post Images</h2>
<p>One of the first things we decided to implement was a feature to encourage readers to look into more blog posts by recommending other posts for them. This is a tried-and-tested method to keep guests engaged with the page, as anyone who has fallen into a YouTube spiral can tell you. The recommended posts are shown as cards at the bottom of each blog post, highlighting other posts that might interest them. On our end, each post has a corresponding file that contains the text of the article along with other useful information such as the author, publishing date, categories, and more. As the site generates the recommendations, it looks through these different bits of information to determine which posts are most relevant to the current user. In its first iteration it recommends based on the most posts. However, it can be changed and updated to recommend posts with similar tags or authors in order to improve the relevancy of the recommendations. This algorithm is implemented using Liquid, which allows for processes like for loops and if else statements. Once the algorithm could pick out good posts, we ensured the card visuals matched the style of the rest of the page with CSS. Once we saw the completed recommendation cards we realized one important thing was missing: a thumbnail.</p>

<p><img src="/img/posts/new_blog_features/ytrecommend.png" alt="YouTube video recommendations" /></p>

<p>When you scroll through any large content site such as YouTube or a news site, each article or video shows an image with its title and other information. This is very important as it breaks up what would otherwise be a large wall of text, improving readability and making the site more visually interesting. We realized that the addition of images would benefit both the post recommendations as well as the main blog page. First, we had to change the way images were stored in the file structure for each post to make it easy to find the posts’ respective images. The path to the image is stored in the post file along with it’s alternative text, making it easy to access them along with other information like the title or author. Once this system was in place we updated each location the posts are shown to render the images along with the title and author. After a couple of suggestions and changes to the formatting (thanks Matt!), the images feature was done!</p>

<hr />
<h2 id="blog-categories">Blog Categories</h2>
<p>Another classic blog feature is the ability to look for posts based on their categories to quickly find more about specific topics. With this feature, you can click on a category label on a post and be directed to a page listing all the blog posts with the same category. From there, you can easily filter the posts with the topic you’re interested in. In addition, you can also head to the categories home page to see a list of all the topics in the blog.</p>

<p>For this feature, one important aspect was that we wanted category pages to be automatically generated so that we wouldn’t need to manually create new category pages each time a new category was added. To help solve this issue, we created a new template layout for a generic category page, and connected this with a Jekyll plugin that would dynamically generate new category pages from the sample layout. Another tricky aspect was figuring out how to set up the pages to generate with the correct urls, so we consulted the documentation to define a folder for each of the category pages to be located. Finally, to future-proof the category pages, we implemented pagination to limit the number of posts per page so that when the blog eventually grows to hold 100s or even 1000s of posts a user won’t have to scroll forever.</p>

<hr />
<h2 id="social-media-buttons">Social Media Buttons</h2>
<p>If a reader enjoyed a post and wanted to share it with others, they would have to copy the post’s URL and then paste it wherever they wanted to share it. We wanted readers to be able to share their favorite posts directly from the post so their reading sesh wouldn’t be interrupted. So we decided to add social media buttons to every post which allows for quick sharing directly from the post.</p>

<p>Before implementing the share buttons, we had to read up on some of the APIs released by Twitter and Facebook to understand how the buttons would be implemented on each page. In the blog post layout, we had to insert a couple of scripts which would render the Facebook and Twitter buttons. Displaying them on the page was the easiest part of the implementation. Getting them to share the correct website required us to utilize Liquid. Without Liquid, we would have been forced to hardcode each button’s redirect URL for every post.</p>

<p><img src="/img/posts/new_blog_features/twitterpreview.png" alt="Twitter share preview" /></p>

<p>When you share a website on social media, you tend to see a related image, the website’s title, and a short description. After getting the buttons to share the correct link, we noticed that there would be a blank preview image in the post. A preview image would give people who see the post an idea of what the article is about. This is where we had to dig into OpenGraph and Jekyll’s SEO Tag (a plugin to help with adding metadata tags). OpenGraph is an Internet protocol for sharing content on sites like Facebook, Twitter, Linkedin, etc. Jekyll’s SEO Tag helps with adding tags for OpenGraph through Jekyll’s front-matter. We were able to take advantage of the post image for the image preview. With a few tweaks, the SEO Tag took the post image and used it in the link preview.</p>

<p>The most painful part of implementing the social media buttons wasn’t programming the code itself. It was debugging. What made debugging a lot harder was the fact that the link previews would use the current ACM TeachLA website. The current website didn’t have the metatags which meant the image previews would be blank. Luckily, there was a way to get around this by committing the code we had written and using Netlify’s preview website. However, this meant we had to change the code and commit very frequently to test the image preview. While it was an exhaustive process, we finally got the previews to display on both Facebook and Twitter.</p>

<hr />
<h2 id="final-thoughts">Final Thoughts</h2>
<p>Through lessons with Matt as well as some healthy trial and error, we learned a lot about the fundamentals of the git workflow as well as building with HTML and CSS. In addition to building our technical skills, we increased our confidence in making meaningful contributions to a large project such as the Teach LA website.</p>

<p>We hope you enjoy using these new features the next time you visit the blog!</p>]]></content><author><name>Trevor, Shounak, and Getty V</name></author><category term="dev" /><category term="blog" /><category term="dev team" /><summary type="html"><![CDATA[This past quarter, we finished implementing several new and exciting features for the Teach LA Blog! As new members of the Dev Team, this was our first experience working on a large codebase with many contributors. Because of this, there was some nervousness with committing changes that we feared would break everything. But alas, we did not break everything and we hope that these new features will be useful to our readers.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/new_blog_features/default.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/new_blog_features/default.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">Introducing Our New Curriculum Pages!</title><link href="https://teachla.uclaacm.com/blog/dev/2021/01/04/introducing-our-new-curriculum-pages/" rel="alternate" type="text/html" title="Introducing Our New Curriculum Pages!" /><published>2021-01-04T01:00:00+00:00</published><updated>2021-01-04T01:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/dev/2021/01/04/introducing-our-new-curriculum%20pages</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/dev/2021/01/04/introducing-our-new-curriculum-pages/"><![CDATA[<p>Our <a href="https://teachla.uclaacm.com/classes">Classes &amp; Curriculum</a> page hosts content dedicated to all of our classes, from our introductory Python course to our mobile/web app development courses. As stated on the page, having a place where anyone can access material from our classes is integral to Teach LA’s mission. It’s our hope that by making our classes as accessible as possible, we can begin to reach an even wider audience and, hopefully, a more diverse demographic!</p>

<p>Prior to Winter 2021, however, most of the content was hosted on third party sites such as Google Docs or Github, which was not an ideal solution. The end goal was to host all class content directly on the website, and potentially make it more interactive by adding problems that check for understanding. We’re proud to say that, although there is still much room for improvement, we are very close to accomplishing this mission! We have now implemented both the <a href="https://teachla.uclaacm.com/classes/py1">Python</a> and <a href="https://teachla.uclaacm.com/classes/rnative">React Native</a> curriculum pages in addition to the <a href="https://teachla.uclaacm.com/classes/ml">Intro AI</a> class that was already finished. In this blog post we’ll be covering how we decided to implement each section, the challenges we faced during development, and our ideas on how to streamline development of new curriculum pages in the future.</p>

<h2 id="python-curriculum-page">Python Curriculum Page</h2>

<p>This page was implemented by Einar and Jun, with Jun working on implementing the curriculum page itself and Einar working on the lesson pages’ design and implementation. We both came into this project with relatively little web development knowledge, so it was a great learning experience for us!</p>

<h3 id="features">Features</h3>

<p>Before even getting started implementing anything, we knew we had to plan out exactly what we wanted to feature on the page and decide ahead of time what the best way to present it would be. Luckily, the <a href="https://www.figma.com/file/1DtxLV71aK4NKKIg0MpxbI/Learning-Pathways-Draft?node-id=0%3A1">design</a> of the Python curriculum page had been completed a few weeks prior, so there was already a great guide for us to follow! Based on the design, we initially decided we wanted the following in the curriculum page:</p>
<ul>
  <li>section organization</li>
  <li>lesson titles, agendas, and lengths</li>
  <li>clear links to slides, videos, and worksheets</li>
  <li>assignments at the end of each section</li>
</ul>

<p>Some specific features of the design, like sectioning and projects, are not yet implemented as of the writing of this blog post, but they will be in the coming weeks! Check out <a href="https://github.com/uclaacm/teach-la-website/issues/198">this</a> GitHub issue if you’re interested in seeing our future plans.</p>

<p>On the other hand, the design of each lesson page was up to us to figure out. One option was to simply follow the same template as the preexisting AI/ML lesson pages. However, we decided not to do this for two reasons: we knew there would be a lot more content to show on the Python lesson pages than on the AI/Ml pages since our Python curriculum is far more developed, and we wanted to improve the interactivity of the page by providing practice problems extending beyond worksheets. So we decided to create a new <a href="https://www.figma.com/file/Mu6CcdWCAI1RVG9mEiJwdI/Teach-La-Python-Lesson-Page">design</a>. We kept the following features in mind during the design process:</p>
<ul>
  <li>lesson name, description, and agenda</li>
  <li>links to slides and worksheets</li>
  <li>lesson length</li>
  <li>links to go back to the curriculum page or to the next lesson</li>
  <li>a video from the python video team (aka the coolest team at Teach LA)</li>
  <li>practice problems complete with solutions</li>
</ul>

<p>We kept all of these features in mind while designing the Jekyll collection for the lesson pages. Speaking of Jekyll…</p>

<h3 id="technologies">Technologies</h3>
<p>As you may or may not know, the Teach LA website is built using <a href="https://jekyllrb.com/docs/liquid/">Jekyll</a>, a static site creation tool that utilizes Shopify’s Liquid templating language. Jekyll is very powerful in that it allows for the creation of Collections. Collections are markdown files that contain all of the data necessary (communicated using YAML) to populate a template, also known as a layout. We also utilized <a href="https://sass-lang.com/">SASS</a> mixins in order to consolidate our styling and reduce redundancies, which we struggled with early on.
Our collection for the lessons more or less followed our desired list of features.</p>

<p>Here’s a look at it:</p>

<div class="language-md highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nn">---</span>
<span class="na">title</span><span class="pi">:</span> <span class="s">The name of the lesson</span>
<span class="na">next_lesson</span><span class="pi">:</span> <span class="s">title of next lesson</span>
<span class="na">next_link</span><span class="pi">:</span> <span class="s">link to next lesson</span>
<span class="na">group</span><span class="pi">:</span> <span class="s">the group of the lesson i.e. fundamentals or control flow etc.</span>
<span class="na">num</span><span class="pi">:</span> <span class="s">lesson number indicates recommended order of completion</span>
<span class="na">length</span><span class="pi">:</span> <span class="s">time required to watch video and complete associated problems</span>
<span class="na">agenda</span><span class="pi">:</span> <span class="s">an array of agenda items</span>
<span class="na">assignment</span><span class="pi">:</span> <span class="s">only include if the lesson is an assignment; for now a link to the problem</span>
<span class="na">practice</span><span class="pi">:</span> <span class="s">an array of problems</span>
  <span class="s">- problem</span>
    <span class="s">num</span><span class="err">:</span> <span class="s">problem number</span>
    <span class="s">question</span><span class="err">:</span> <span class="s">written in markdown</span>
    <span class="s">solution</span><span class="err">:</span> <span class="s">written in markdown</span>
<span class="nn">---</span> 
Content: long description of lesson to show on lesson page
</code></pre></div></div>

<p>The Collection went through a couple iterations including a few where we hardcoded a maximum of three practice problems. After some closer consideration, we realized this was unnecessary and removed the arbitrary limit. As mentioned, we were both very new to Jekyll so we had to do a lot of learning to find the best way to implement certain things.</p>

<h3 id="challenges">Challenges</h3>

<h4 id="einar">Einar</h4>

<p>Designing the collection was by far the easiest part. What was really challenging was actually linking it to the layout for the lesson pages that we had created. As an inexperienced Jekyll developer, it just wasn’t at all clear how the two could be linked. It honestly seemed like magic how other collection-utilizing pages (such as the team page and AI/ML lesson pages) worked. After a solid 5 hours of documentation reading and searching through the website’s large codebase, I finally discovered the elusive <code class="language-plaintext highlighter-rouge">_config.yml</code> file (insert Hallelujah music here) and successfully linked the data in the collections to the templates.</p>

<p>But yeah, 5 hours. That’s what I get for jumping into a big project like this with no experience. I’m glad I did it, though! It was genuinely a great learning experience and there are a ton of skills that I will be sure to apply to my next project and throughout my career as a developer!</p>

<p>Additionally, I made the mistake of not reading any of Jun’s CSS code that he had written for the Python curriculum page (nor any of the website’s CSS in general), so I made quite a few duplicate/unnecessary classes. I also realize now that I followed a fairly poor design ideology of styling each component on its own rather than creating more general classes that can be reused anywhere in the site. Oh well, live and learn! We can definitely go back later and refactor some of the bad CSS that I wrote.</p>

<h4 id="jun">Jun</h4>

<p>Getting started on the project was daunting, so I was really glad when Einar was assigned to work on this with me. We divided up the work early so each of us had a clear focus.</p>

<p>I realized I had poor organization only much later on. Initially, I was ambitious about recreating the design sketch as is, and spent too much time fine-tuning each small element on the page. (Overriding user agent stylesheet rules turned out to be very important to controlling the look of the page.) To that end, I thought I would learn Liquid after I finished all (!) the styling for the page. In my head, the magic script was going to make everything fall into place and generate all the HTML content I need, so if I finished the CSS, the one last step would just complete the whole thing. This was a mistake. If I had focused on the content structure before style – in fact, I thought I did when I wrote some stub HTML by hand to style, but no – I would’ve seen that the design of the elements makes use of much repetition, and much time and frustration could’ve been saved. I decided early when typing out the sample HTML that each lesson card would have three rows: a title, a body, and an action bar. This division remained, but the CSS rules now fortunately look more cohesive than the ones I spent too much time tweaking. Never again shall I miss the forest for the trees!</p>

<p>The big picture aside, everything else was a learning experience. Toward the end, I was able to lay down starter CSS rules by heart much faster (“border – margin – padding – color – text,” I would chant). Letting go of the impulse to recreate the sketch exactly also freed up time to make new decisions. For example, once I let go of the strong wish to stick to the button layout on the sketch when it didn’t adapt well to viewport width changes, I just decided they should be in a column sometimes to avoid taking up too much horizontal space, and I ended up liking this look. It did surprise me most of my learning is psychological and about ‘heart’ decisions rather than just ‘code’ decisions. I found myself thinking a few times “Would the viewer like this?” or “How do I make this look easier on the eyes?” Being new with little experience taking on a big (not so anymore!) project probably caused this anxiety, but all of that has now turned into confidence in tackling the next one.</p>

<h2 id="react-native-curriculum-page">React Native Curriculum Page</h2>

<p>This page was created by Alex and Prateek. Prateek was in charge of implementing the infrastructure of the course collection, while Alex took care of filling in all of the content and cleaning up the design of the page.</p>

<h3 id="features-1">Features</h3>

<p>Programming is often seen as very inaccessible and can be perceived as impossible to learn. With these lessons, we try to make coding more accessible. A really nice class to teach is one to build websites, webapps, or mobile apps. Since everyone uses them on a daily basis, it is a very nice gateway into programming to teach someone how to build their very own version.</p>

<p>This class is created to help teach students to build their own mobile app through React Native. It includes class lessons with content teaching the fundamentals of computer science, the ideas behind how/why things are done the way they are done, and introductions to HTML, CSS, Javascript, and more, all of which are critical in building apps. 
Within each lesson we can see multiple things. These include github links to the lessons on github or the code referenced within the lesson. These are particularly useful in helping students build off this code, use it as an example, or learn from these samples. All of which could help the student better understand the material behind the lesson. Each lesson also includes some sort of activity for the student to do. The content is also written in a way that provides more of an engaging experience rather than just a manual on how certains things affect others. This makes the learning much more welcoming.</p>

<h3 id="technologies-1">Technologies</h3>

<p>In each individual lesson page, we wanted to render the accompanying lesson guide from the React Native course GitHub. These guides were written as markdown files, and we had to convert them into raw HTML. We used <a href="https://marked.js.org/">Marked</a>, a 3rd-party markdown compiler to do the job for us. We then sanitized the converted HTML using <a href="https://github.com/cure53/DOMPurify">DOMPurify</a> to ensure that there wasn’t any malicious code!</p>

<p>Since we used the same design as the AI/ML course pages, we realized that there was a lot of code duplication of the AI/ML course pages, especially with our CSS. In order to clean this all up, we used SASS and its mixin functionality to cut out all of the repeated code. <a href="https://sass-lang.com/">SASS</a> is a scripting language that gets converted into regular CSS files when we compile our webpage, and it is useful for us because it allows us to use variables in our CSS. We can also use mixins, which give us the ability to pass in arguments into our styles. Much like functions, we can pass in specific variables dynamically so that we can reuse styles that are very similar. In our case, a lot of the styling for the AI/Ml pages and the React Native pages only differed in the specific class color, so mixins were a great tool to cut down on code duplication!</p>

<h3 id="challenges-1">Challenges</h3>

<h4 id="alex">Alex</h4>

<p>The biggest challenge that I had was dealing with images that were in the lesson guide markdown files. Since these guides were initially written to be read in the GitHub repository, the images were linked with local paths. When we convert the markdown files, the site would read these paths as local to the lesson page, not the original lesson guide page. To fix this, I had to parse the entire markdown for the image paths in the <code class="language-plaintext highlighter-rouge">![]()</code> tags, and save these paths. I used <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions">regular expressions</a> to parse through the file. Now that I had the path of each image, I just appended it to the appropriate GitHub link and inserted them into the markdown file.</p>

<h4 id="prateek">Prateek</h4>

<p>I faced a few challenges when dealing with this project. Primarily, this was the first larger scale project I had worked on. The other things I had done with HTML/CSS/Javascript were much smaller and created by scratch. Orienting myself to the codebase took some time and taught me lessons on how to methodically explore pre existing code to find the material I needed. Furthermore, when coming to the construction of the actual website a tricky portion was some of the css styling. At the time, I was fairly new to css and therefore properly lining up the material and making sure it looked proper was a bit tricky. I had first approached this by trying to rewrite the CSS but this was not effective for two reasons. First, there already were Sass files that existed for the AI/ML pages that I could use similarly. Second, the CSS was fairly intricate so it would be a lot of unnecessary code. Once I realized this, I just adjusted some of the variables such as color and reused the same code.</p>

<h2 id="reflection">Reflection</h2>

<p>Looking back on the development of both of these curriculum pages, it’s clear that it would be possible to streamline it one significant way. Both teams (Einar and Jun, Prateek and Alex) were basically developing in a vacuum, completely isolated from each other. This is because, as it stands, in order to add a curriculum page a team needs to get together and develop a whole new layout and collection that fits the course’s features.</p>

<p>We could streamline this by unifying each curriculum page into a single layout and collection. (Note from Einar: I’m fairly new to Jekyll so I’m not entirely sure if this is possible, but if it is, it’s definitely something we should consider!) This would make it far easier to add new curriculum pages in the future should we ever start teaching new topics. It may limit the flexibility of the design of each curriculum page, but that may actually do more good than bad. It would essentially force consistency between each curriculum page. However, the individuality of the Python page definitely makes it stand out! (At least Jun thinks so.)</p>

<p>Overall, this was definitely a great experience for all of us. <a href="https://www.youtube.com/watch?v=d1EnW4kn1kg">And although our web dev skills are great, we have a lot to learn before we’re ready to create again. But I believe we can make the perfect website.</a></p>]]></content><author><name>Einar, Jun, Alex, and Prateek</name></author><category term="dev" /><category term="curriculum" /><category term="dev team" /><summary type="html"><![CDATA[Our Classes &amp; Curriculum page hosts content dedicated to all of our classes, from our introductory Python course to our mobile/web app development courses. As stated on the page, having a place where anyone can access material from our classes is integral to Teach LA’s mission. It’s our hope that by making our classes as accessible as possible, we can begin to reach an even wider audience and, hopefully, a more diverse demographic!]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/new_curriculum_2021/curr-icons.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/new_curriculum_2021/curr-icons.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">Teach LA’s Intern Search Experience</title><link href="https://teachla.uclaacm.com/blog/internship/2020/12/16/internship-retrospective/" rel="alternate" type="text/html" title="Teach LA’s Intern Search Experience" /><published>2020-12-16T04:00:00+00:00</published><updated>2020-12-16T04:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/internship/2020/12/16/internship-retrospective</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/internship/2020/12/16/internship-retrospective/"><![CDATA[<p>We just wrapped up Teach LA’s internship recruitment process for 2020, and are welcoming twelve wonderful interns to our team! In this post, we aim to be as transparent as possible and reflect on our process.</p>

<h2 id="acm-internship-program-overview">ACM Internship Program Overview</h2>

<p>Applicants apply through the general ACM internship program application, where they can indicate which committees and positions they are interested in. The application itself has three parts: general background questions, general ACM questions, and committee-specific questions. This program is led by our wonderful ACM internship directors Sagloria (Sahen and Gloria), and this was the first year Teach LA accepted interns through this process. So you’re probably wondering …</p>

<h3 id="what-do-teach-la-interns-do">What do Teach LA interns do?</h3>

<p>Interns work closely with our board on a wide variety of projects to level the CS education playing field. We divide our interns into cohorts that focus on similar goals/projects (e.g., curriculum, logistics &amp; outreach, dev team, etc.). Above all, we want to help interns grow (as a teacher, developer, and person)!</p>

<h3 id="what-is-the-difference-between-a-teach-la-general-member-and-a-teach-la-intern">What is the difference between a Teach LA general member and a Teach LA intern?</h3>

<p><em>General members</em> can teach as an instructor, develop curriculum, or join the dev team. They attend curriculum/dev team meetings.</p>

<p><em>Interns</em> help lead curriculum meetings, make sure Teach LA runs smoothly, or lead projects on the dev team, depending on their role. They are included in both ACM officer/intern events and general curriculum/dev team meetings.</p>

<h2 id="the-written-application-review-process">The Written Application Review Process</h2>

<p>This year, ACM gave each committee the option of reviewing internship applications blind, removing all identifying information that would make it possible to assign scores based on demographic information, rather than merit. Teach LA ultimately made the decision to review each application three times: once blind, once non-blind, and once (non-blind) by Matt, our amazing club president who spent six hours looking over all 71 written applications in one sitting. (Please don’t hesitate to check in with Matt about his horrible sleep schedule at any time; he loves getting negative feedback about his unhealthy habits!) By assessing the difference in blind vs. non-blind scores, we were able to give each candidate a fair chance while simultaneously assessing the effectiveness of the blind procedure for future use.</p>

<p>In terms of the information omitted when reviewing applications blind, we were not given access to the applicant’s name, gender, sexuality, work authorization, address, email, or phone and were also prevented from accessing links to their github/portfolio/socials. We could, however, review their activities, hobbies/interests, GPA, and high school.</p>

<p>The blind vs. non-blind application review procedures were ultimately put into place to prevent inherent bias. For a bit more background, studies have shown that when identical resumes are submitted to job postings, one with a traditionally white name and one with a traditionally black name, the resume with the “white-sounding” name is significantly more likely to be chosen. In fact, a black applicant is about as likely to be chosen as a white applicant with a criminal record when the resumes are otherwise identical. Although we trust that our board members who reviewed each application would not favor applicants based on demographic information, Teach LA is committed to equity, diversity, and inclusion (EDI), so we collectively agreed to test out this new application review procedure, thereby ensuring that each applicant was given a fair shot.</p>

<p>Each written application was given a score in several categories, each of which was weighted differently. Overall, we were looking for applicants who demonstrated clear passion for Teach LA’s mission (providing CS education to all students) and also took into account teaching and leadership experience, as well as commitment to EDI. The exact score breakdown is as follows:</p>

<ul>
  <li>Passion + Effort (10 points)</li>
  <li>Interest + Experience (10 points)</li>
  <li>Diligence + Commitment (8 points)</li>
  <li>Leadership (5 points)</li>
  <li>EDI (2 points)</li>
</ul>

<p>As previously mentioned, each candidate was scored by three reviewers: a blind reviewer, a not-blind reviewer, and Matt. To account for internal consistency within each reviewer, we normalized the scores that each reviewer gave. We noticed that there was a slight (but not overtly) symmetric bimodal nature to the scores for each reviewer; to test the rigidity of our hypothesis, we examined two different normalizing measures:</p>

<ol>
  <li>(current point - mean)/standard deviation</li>
  <li>(current point - min)/(max - min)</li>
</ol>

<p>Interestingly, the top 21 candidates did not differ regardless of the normalizing measure that we used. Thus, to extend the offer to interview for our final 21 candidates, we simply picked the candidates with the top 21 total scores. We equally weighted the individual score given by each reviewer.</p>

<p>After looking at the entire written application process, there were several interesting results:</p>

<ul>
  <li>
    <p>There was a correlation between written application score and final acceptances, in particular with the applicants with significantly higher written application scores (&gt; 1 stdev) - we offered all of these candidates final offers.</p>
  </li>
  <li>
    <p>There is a correlation between being involved in Teach LA prior to the application process, and a higher written score. Out of the 21 interview applicants, 11 (52%) of them were already involved in Teach LA in some capacity; in contrast, less than 20 of the remaining 50 applicants (40%) had interacted with Teach LA at all.</p>
  </li>
  <li>
    <p>In general, there was not much disagreement between blind and not-blind reviewers. In particular, each reviewer’s subset of the top 21 candidates was at most two candidates off from their internal top 10 list.</p>
  </li>
  <li>
    <p>Matt was the only reviewer who reviewed every application. In general, Matt agreed with his other reviewers; the 21 interview candidates were within his top 24 candidates in total.</p>
  </li>
  <li>
    <p>We were unable to collect demographic data about our applicants due to a logistical error. Unfortunately, this discounts our ability to evaluate if our written application scoring particularly favoured a specific group of applicants.</p>
  </li>
</ul>

<p>Given the relatively small sample size of reviewers, it is tricky to make definitive conclusions from our data. And, of course, we need to recall that correlation does not imply causation. Still, we value reflection and introspection for our process, and look to make it better next year!</p>

<h3 id="the-interview-process">The Interview Process</h3>

<p>After reviewing all 71 written applications, we moved onto the interview stage of the internship search process, scheduling 15-minute interviews with 21 candidates. Though the written application questions were quite general, the interviews consisted of both introductory questions and position-specific ones: interviewers were given a list of intern positions and descriptions, and were asked to come prepared with the one they wanted to apply for. Although there was a very limited period of time during which we were able to schedule interviews, the time constraints of such short meetings admittedly made it quite difficult to get to know some of our more shy candidates especially.</p>

<h3 id="tips-for-future-applicants">Tips for Future Applicants</h3>

<p>If you’re considering applying next year, we’d love to have you join our team! Here are some tips:</p>

<ol>
  <li><strong>Don’t be afraid to let your personality come across in your written application and interview!</strong> You obviously want to make applications for jobs, internships, etc. as professional as possible, but whoever is reviewing your application is a person too. The applications I found the most memorable were not necessarily the ones that showcased the most technical experience or the ones with the longest answers. Just make sure your answer reflects some sort of quality that would make other people want to work with you.</li>
  <li><strong>Be as thorough as possible when answering interview questions.</strong> One-word or single-sentence answers do not give your interviewers a great sense of your personality, and if you were able to get to the interview stage, you definitely have a lot of great experience they would love to hear about! When answering a question, think about why it was asked. For example, “Describe a time you had conflict when working in a group.” is being asked to determine how you communicate with others and deal with obstacles. When answering, you should not only describe the conflict, but also talk about what you did and how you demonstrated qualities that are desirable in the role for which you are interviewing.</li>
  <li><strong>If your interviewer(s) can tell that you are nervous, they don’t hold this against you!</strong> We all know that the ability to answer a ton of super-specific questions about yourself and your experience is not always the best indicator of how good you are going to be in the role to which you are applying. If you feel bad about an interview experience because of how nervous you were at the time, remember all of the amazing information you were still able to provide, especially when you also submitted a resume/written application!</li>
  <li><strong>If you are applying for a leadership position in an organization that meets regularly and is open to the public, attend general meetings if you can!</strong> We loved to see familiar faces among our applicants, and I also noticed how much more comfortable people were during interviews when we had already spoken to/worked with them previously. You’ll also be able to get to know members and the ~vibe~ of an organization before applying, which is very important too!</li>
</ol>

<h3 id="what-we-learned">What We Learned</h3>

<p>As an organization, we learned a lot throughout our internship search. The following is a list of ways in which we can improve upon this process in the future:</p>

<ol>
  <li><strong>Ask at least one specific question about each applicant’s commitment to EDI in the written application.</strong> We gave each written applicant a score assessing their commitment to EDI (for more information, see the section “The Written Application Review Process) without asking any specific questions about equity, diversity, and inclusion in the application itself. It is a bit unfair to assess candidates in a category of which they were not even aware.</li>
  <li><strong>Get a better sense of our applicants’ experiences and personalities during our interviews.</strong> The most obvious answer would be to cut down the number of interview invitations we send out, but we can also address this issue by making our interviewees feel more at ease from the start. We asked each candidate about their passions at the beginning of every interview, which gave us an opportunity to get a sense of their personality, but some people felt pressured to make their answer academic or computer science-related. In the future, I think we should ask people about hobbies/passions beyond CS or come up with another question to make our applicants more comfortable and willing to open up.</li>
  <li><strong>Ask about positions of interest in the written application.</strong> We decided that interns would have defined positions (e.g. “curriculum intern,” as opposed to the more general role of “Teach LA intern”) but failed to make this choice clear to our applicants. The decision to omit this information from the application was intentional, as we did not want to discourage passionate people from applying just because they didn’t find a role that fit them. However, this made the deliberation process difficult, especially when scheduling interviews. Although we wanted to make sure we had appropriate interviewers for each interview (e.g. someone with technical expertise for dev team roles, the logistics director for a logistics intern role, etc.), it was hard to match people given that we didn’t know what specific role(s) each applicant was interested in until their interview.</li>
  <li><strong>Clearly define the Teach LA intern role.</strong> When answering “Why do you want to join Teach LA?”, a lot of applicants said they wanted to teach or build technical skills, which could be done by joining as an instructor or dev team member. To avoid this misunderstanding in the future, we could work on clearly defining the Teach LA intern role (both in the application and in general) and make it clear that anyone can be a part of Teach LA without applying.</li>
  <li><strong>Consider a more distinct dev team application process.</strong> The classes, curriculum, and events team within Teach LA require a significantly different skill set than our dev team; in particular, teaching experience and event planning is vastly different from software development. In this written application cycle, we did not discuss this difference at length or spend a significant amount of time evaluating our dev team interns for technical ability. We believe that making this distinction more clear may increase the number of applicants for both dev and non-dev roles, as it makes it clearer to applicants what types of skills that they may need.</li>
</ol>

<h2 id="conclusion">Conclusion</h2>

<p>Thank you for reading this post! We hope this provided more insight for the inner workings of our internship program.</p>

<p>Got any feedback? Feel free to reach out to us, we’d love to hear what you have to say!</p>

<p>If you’re interested in joining Teach LA, <strong>you don’t have to be an intern!!</strong> See our <a href="/join">join us page</a> to get started!</p>]]></content><author><name>Bonnie and Sophie</name></author><category term="internship" /><category term="internal" /><category term="reflection" /><summary type="html"><![CDATA[We just wrapped up Teach LA’s internship recruitment process for 2020, and are welcoming twelve wonderful interns to our team! In this post, we aim to be as transparent as possible and reflect on our process.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/internship/intern-social-20.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/internship/intern-social-20.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">Ingredients of “Cipher Salad”</title><link href="https://teachla.uclaacm.com/blog/dev/2020/10/13/ingredients-of-cipher-salad/" rel="alternate" type="text/html" title="Ingredients of “Cipher Salad”" /><published>2020-10-13T04:00:00+00:00</published><updated>2020-10-13T04:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/dev/2020/10/13/ingredients-of-cipher-salad</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/dev/2020/10/13/ingredients-of-cipher-salad/"><![CDATA[<p>We prepared <a href="https://ciphersalad.uclaacm.com/">Cipher Salad</a> in collaboration with <a href="https://acmcyber.com/">ACM Cyber</a> and <a href="https://www.facebook.com/citylabatucla/">CityLab at UCLA</a> as an introductory cryptography mini lesson for students of all ages. Cryptography is one of those subjects that can intimidate even a college CS student (ourselves included!), but it’s an important part of CS, and we wanted to make it accessible to as many people as possible.</p>

<p>Particularly, we wanted to ease students into cryptography in a fun and engaging way so that anyone without a CS or math background could benefit. Creating an interactive mini web app allowed us to not only get creative in the way we presented the material, but also enable students to learn CS regardless of our ability to physically be there with them. With the consequences of COVID-19, this has been especially important. In fact, at the conclusion of the project, CityLab at UCLA used Cipher Salad in a <a href="https://teachla.uclaacm.com/citylab-cyber">virtual cyber day</a> for high schoolers!</p>

<p>Cipher Salad is a combination of many cipher modules combined with a game at the end where users can share and crack ciphers with their friends. We covered three types of ciphers and other simplified cryptography concepts, and included graphics and animations to keep students of all ages engaged. The Caesar cipher, also known as the shift cipher, is one of the simplest and most widely known encryption techniques. The Atbash cipher reverses every letter in the alphabet, and lastly, there’s the Vigenere cipher, which is a little more advanced, for kids to further explore the fun of cryptography.</p>

<p><img src="/img/posts/cipher_salad/caesar-cipher.png" alt="caesar cipher" class="post-img" /></p>

<p>Alyssa, Teach LA’s dev and cybersecurity extraordinaire, was the ~key~ to the content creation and presentation (and she coded quite a few features!). She developed the lesson from scratch and created mock-ups using Figma, an online design prototyping tool. This enabled our developers to focus on the development side of things. Those of us who consider ourselves to be design challenged (aka Lisha) particularly appreciated this. Alyssa also taught much of the content to the developers, who, as it turns out, were also cryptographically challenged and weren’t familiar with some basic ciphers. This is a great example of Teach LA’s motto, learn what you teach, teach what you learn!</p>

<p>On the development side, we used <a href="https://reactjs.org/">React</a> as the main framework to create Cipher Salad. To aid in styling the user interface, we incorporated the <a href="https://bulma.io/">Bulma framework</a> for built-in CSS classes. We also included other npm packages (such as <a href="https://alain.xyz/libraries/react-anime">React Anime</a>, a React binding for <a href="https://animejs.com/">Anime.js</a>, and <a href="https://github.com/mattboldt/typed.js/">Typed.js</a> to add animations and improve the visual presentation of the overall site. Additionally, we connected the share cipher module, which includes the functionality to create and crack ciphers, to a <a href="https://firebase.google.com/">Firebase</a> backend for storing and retrieving. Finally, we included a floating vertical navbar to provide users with a sense of progress through the module. This proved to be more complicated than anticipated.</p>

<p>You see, to create a scrollbar tracking progress throughout the page, your React component has to have knowledge of all the other elements on your webpage so that it can detect when the user scrolls by one. In the world of React, this isn’t ideal, since we would be violating the core assumption that React apps are divided up into discrete components. However, to achieve the functionality we desired, there aren’t many other options.</p>

<p>So the question then became “how should we best break React’s rules?” To ease this process, we used a small react component <a href="https://www.npmjs.com/package/react-scrollspy">react-scrollspy</a>, which allowed us to construct a simple wrapper around the component that did the heavy lifting of spying on the user’s scrolling, then update our little key icons every time a user scrolled by. In retrospect, one could construct a dependency free version of this component by using <a href="https://reactjs.org/docs/react-dom.html">React DOM</a> to instead track the user’s scrolling directly. This would offer the developer more control over the finer details of the “scroll spying” behavior while sacrificing a negligible amount of code readability.</p>

<p>We encountered several other difficulties throughout development. One of the major obstacles was our lack of experience in web development – at the start of the project, we hardly knew any HTML and CSS. Before we were able to make any substantial progress, we needed to become comfortable with HTML, CSS, JavaScript, and React. With the help of our stellar dev leaders Matt and Leo, various online tutorials, and lots of time struggling, we finally overcame the learning curve. A particularly helpful resource was the <a href="https://github.com/uclaacm/learning-lab-crash-course-su20">Learning Lab Crash Course</a> conducted by Matt and Leo over the summer.</p>

<p>Once we got the hang of things, it was time to dive into building the module. One portion we found tricky to implement was the decoding section that gives users an encoded message, options for decoding it, and demonstrates the correct decoding. One of the hard parts was getting used to React Anime. Although React Anime and Anime.js seem rather straightforward in hindsight, we initially found them unintuitive, partly because we weren’t familiar with some of the underlying concepts such as keyframes, which is a CSS styling property for smooth transitions and animation effects. Keyframes define the starting and ending points of the “frames” and other properties such as frame opacities and animation direction. We also used transition effects throughout the cipher salad to make individual sections more engaging. In addition, while React Anime often makes animations with React easy to implement, it led to an issue with certain animations. The problem was that the animations done with React Anime components would replay every time the component containing them was rerendered (since that causes the enclosed Anime components to be redrawn). In most cases, we only wanted those animations to play once. Fixing this required some extra logic with state that determined whether to render the animated element or the static element. Unfortunately, this meant that we could no longer rely on using React Anime’s <code class="language-plaintext highlighter-rouge">delay</code> prop for staggering animations – doing so would result in each animation being replayed every time the component renders. Instead, each animation had to be triggered by a state change, which meant that staggering animations required staggering state changes using callback functions. As a result, the rendering logic for the entire component was more complicated than we expected, and writing it made our brains hurt a little.</p>

<p>Another issue we encountered was making sure our app looked good on all screen sizes. This was important to us since we couldn’t make any assumptions about what devices students might use to access our site. To ensure a quality experience whether students view it on double monitors or a small tablet, we made sure to test the site on different viewports throughout development. However, we had a lot of trouble with the layout of the blackbox example. Initially, pixel measurements were used to position elements and animated icons elegantly, but we had trouble making everything look aligned on different viewport sizes, as absolute measurements don’t adapt to various sizes. As a result, we switched to relative units, and we made extensive use of CSS media queries to ensure that certain elements wouldn’t overlap on smaller viewports.</p>

<p><img src="/img/posts/cipher_salad/black-box.gif" alt="black box example finished product" class="post-img" /></p>

<p>In the process, we were able to learn from our mistakes, make adjustments, and be open to suggestions from other people. Finally, through trials and errors, we resolved the problems and finalized an intuitive and presentable site.</p>

<p>Creating Cipher Salad has been a tremendous learning opportunity for all of us. Throughout the development cycle, we learned new technologies and tools to help us further our skills in web development. We also practiced our ability in creating content that’s understandable, well designed, and engaging for all ages. We hope everyone can enjoy our tasty Cipher Salad, and we’re always open to new suggestions for improvements. Cheers!</p>]]></content><author><name>Rachel, Leo, Janis, and Lisha</name></author><category term="dev" /><category term="learning labs" /><category term="dev team" /><summary type="html"><![CDATA[We prepared Cipher Salad in collaboration with ACM Cyber and CityLab at UCLA as an introductory cryptography mini lesson for students of all ages. Cryptography is one of those subjects that can intimidate even a college CS student (ourselves included!), but it’s an important part of CS, and we wanted to make it accessible to as many people as possible.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/cipher_salad/default.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/cipher_salad/default.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">The Making of “Passworks”</title><link href="https://teachla.uclaacm.com/blog/dev/2020/09/23/the-making-of-passworks/" rel="alternate" type="text/html" title="The Making of “Passworks”" /><published>2020-09-23T04:00:00+00:00</published><updated>2020-09-23T04:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/dev/2020/09/23/the-making-of-passworks</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/dev/2020/09/23/the-making-of-passworks/"><![CDATA[<p>In this post, I’ll discuss the process of building <a href="https://passworks.uclaacm.com">Passworks</a>, an educational module consisting of several activities designed to teach password security concepts.</p>

<p><img src="/img/posts/passworks/home.png" alt="passworks homepage" class="post-img" /></p>

<p>The activities demonstrate the importance of password length, using a variety of different character types in a password, having a unique password, and being aware of social engineering attacks. Throughout this post, I’ll talk about the logistics of the development process, how I made certain technical design decisions, content presentation, problems I had to debug, and some other (hopefully) fun and interesting things I encountered during development.</p>

<hr />

<h2 id="logistics">Logistics</h2>

<p>Overall, the project’s development consisted of these stages: proposal, content development, and a loop of coding, testing, and review/feedback.</p>

<p>The project spanned approximately one quarter, with most of the development occuring in the span of a month. The project was first proposed by a member of <a href="https://acmcyber.com/">ACM Cyber</a>, Alyssa, and was intended to be a series of educational activities designed to introduce password security concepts. She fleshed out some intial ideas of which particular topics to cover and some ideas on how to present them as fun activities (rather than lectures). The folks over at <a href="https://citylabatucla.wixsite.com/citylab">CityLab at UCLA</a> were also interested in the idea for an event they were hosting, and become involved in the curriculum development. They were able to provide some details on the target audience of the project (high school students) and provided feedback throughout the development process on course content.</p>

<p>In general, the communication between Teach LA and CityLabs was pretty smooth. My outreach team members (particularly Leo and Matt) did an amazing job of communicating with the CityLabs team and breaking their thoughts down for me, so I had a pretty fair idea of what needed to be done at any given time. Though I occasionally felt a bit pressed for time due to the project deadline, the clear communication was really helpful in managing tasks and work to be done for the project.</p>

<p>I was also fortunate enough to have frequent code reviews and design/content feedback from the Teach LA team and testers, which was very useful during the development and iteration process.</p>

<hr />

<h2 id="tech-stack">Tech Stack</h2>

<p>Like all other Teach LA learning lab modules to date, this project is a web app. I decided that it wouldn’t require persistent storage of user information, and thus does not require a backend or database. I chose to use <a href="https://reactjs.org/">React</a> because I had prior experience with it and for its component reusability. I also decided to use <a href="https://material-ui.com/">Material-UI</a>, which I had less experience working with at the time, in order to leverage their quality prebuilt UI components.</p>

<hr />

<h2 id="targeting-our-audience">Targeting Our Audience</h2>

<p>As the app was intended for an audience of high-schoolers, it was important that the contents and presentation of the material reflected that.</p>

<p>On the side of content development, we made sure to think of activities that allowed the users to make choices (like which password to input), and more interactive or relatable activities like the Social Engineering Activity with a mock Instagram. In addition, I made use of animations in various parts of the app to make it more visually appealing and interesting. I also made it a priority to present the lesson contents in an engaging and conversational tone. Notably, each topic is introduced through a scripted mini-conversation between the user and a “Hackerman” friend.</p>

<p>Another important consideration during development was how to handle swear words and inappropriate content during the Common Passwords Activity. For this section, I made sure to only output whether the user’s input was in the list or not, and not repeat what the user input was. For example, I didn’t want the app to say “The password you input, ****, was in the top 10,000 most common passwords!” In the later section displaying the Most Common Passwords, it was necessary for us to manually go through the list of passwords and curate the appropriate ones (shout out to <a href="https://matthewwang.me/">Matt</a>!).</p>

<hr />

<h2 id="design-decisions-during-development">Design Decisions During Development</h2>

<p>To be honest, I was pretty daunted by the task at hand when I was initially presented with the project proposal and the content planned. I worked off of this <a href="https://www.figma.com/file/QFjZGNz7ZXqrdnHf0XTbmP/Passworks?node-id=34%3A0">initial design</a>, created by Alyssa, to get a sense of the general structure of the project. However, I was afforded a lot of flexibility in the details of the implementation and what exactly to present. After looking through the Figma, I spent some time planning to figure out each stage of the various activities, and the basic layout and shared components each activity would need to use. From there, I started building up components and getting a small version of the app working. In this section, I’ll discuss some of the more significant design decisions I made, and my reasoning behind them.</p>

<hr />

<h3 id="the-lesson-framework">The Lesson Framework</h3>

<p>Probably one of the biggest decisions during the building of the app was how I would store the lessons/activities in the app. As I was fleshing out some details in the activities, I noticed that each “slide” of a lesson would consist largely of the same elements, in particular, some descriptive text and some content on the phone (see poorly drawn example below).</p>

<p><img src="/img/posts/passworks/layout.png" alt="sample text on a phone screen" class="post-img" /></p>

<p>In addition, there were many instances where two different activities would be able to reuse previous components. For example, the first two activities both feature a password input and password generator. I realized that I could create a declarative framework, where each lesson is defined by an array of JavaScript objects. For example, the block of code below represents a single slide in a lesson:</p>

<div class="language-jsx highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">[</span>
  <span class="c1">// ...</span>
  <span class="p">{</span>
    <span class="na">slide</span><span class="p">:</span> <span class="p">(</span>
      <span class="p">&lt;</span><span class="nc">Typography</span><span class="p">&gt;</span>
        Type a 4-digit password (or press Randomize to generate one
        automatically), and press Submit!
      <span class="p">&lt;/</span><span class="nc">Typography</span><span class="p">&gt;</span>
    <span class="p">),</span>
    <span class="na">input</span><span class="p">:</span> <span class="kc">true</span><span class="p">,</span>
    <span class="na">inputNum</span><span class="p">:</span> <span class="mi">1</span><span class="p">,</span>
    <span class="na">inputType</span><span class="p">:</span> <span class="dl">"</span><span class="s2">num</span><span class="dl">"</span><span class="p">,</span>
    <span class="na">inputDesc</span><span class="p">:</span> <span class="dl">"</span><span class="s2">4 digits</span><span class="dl">"</span><span class="p">,</span>
    <span class="na">inputLength</span><span class="p">:</span> <span class="mi">4</span><span class="p">,</span>
    <span class="na">checkInput</span><span class="p">:</span> <span class="p">(</span><span class="nx">str</span><span class="p">)</span> <span class="o">=&gt;</span> <span class="sr">/^</span><span class="se">\d{4}</span><span class="sr">$/</span><span class="p">.</span><span class="nf">test</span><span class="p">(</span><span class="nx">str</span><span class="p">),</span>
    <span class="na">defaultInput</span><span class="p">:</span> <span class="p">()</span> <span class="o">=&gt;</span> <span class="nf">getRandom</span><span class="p">(</span><span class="dl">"</span><span class="s2">0123456789</span><span class="dl">"</span><span class="p">,</span> <span class="mi">4</span><span class="p">),</span>
    <span class="na">phoneContent</span><span class="p">:</span> <span class="nx">inputForm</span><span class="p">,</span>
  <span class="p">},</span>
  <span class="c1">// ...</span>
<span class="p">]</span>
</code></pre></div></div>

<p>The slide looks like this when rendered:</p>

<p><img src="/img/posts/passworks/example_slide.png" alt="rendered phone and game" class="post-img" /></p>

<p>Using such a format allows the app to process the information in each slide of an activity, and use the information to decide what to show on the webpage. This framework also has the added benefit of making the lessons easily extensible, since additional lessons or lesson slides can be easily added by adding more objects to the list (rather than needing to write a bunch of actual code).</p>

<p>The framework was built up very incrementally. When I first implemented the framework and the app only had a few core features, the lesson slide objects had a limited number of properties. For example, in <a href="https://github.com/uclaacm/passworks/blob/26330fc42bf3d2bc040076095d53c63f00791bd5/src/constants/lessons.js">this very initial version</a> of the app, only the <code class="language-plaintext highlighter-rouge">slide</code>, <code class="language-plaintext highlighter-rouge">input</code>, <code class="language-plaintext highlighter-rouge">usesInput</code>, <code class="language-plaintext highlighter-rouge">inputType</code>, and <code class="language-plaintext highlighter-rouge">inputLength</code> properties existed. As more activities were developed, and more requests made for features in activities, the number of possible keys and options grew, making the structures more complex.</p>

<p>This incremental approach when coupled with the inherent complexity of the phone screen admittedly resulted in some less-than-perfect code, as I had to do some workarounds to get certain features working. <a href="https://github.com/uclaacm/passworks/blob/a2496efddccc0e11a9bf4e693fee5696bb96f70c/src/components/Main/Main.js#L208">This whole chunk of code</a> is responsible for rendering various different items on the mock phone screen in the app, and is not the prettiest to look at. This is largely because the phone screen component is generic and must be able to contain a wide variety of different components (the password guesser, chat messages, input forms, etc.), each with different required props. It’s possible that figuring out every aspect of the app before starting development would have made some code much cleaner, but a lot of the activities were being iterated on during development. Pre-planning the entire lesson framework might have then resulted in unnecessary complexity or dead code in the app by the app’s completion.</p>

<p>You can check out the overall lesson structure <a href="https://github.com/uclaacm/passworks/blob/a2496efddccc0e11a9bf4e693fee5696bb96f70c/src/constants/lessons.js#L198">here</a>.</p>

<hr />

<h3 id="making-things-generic">Making Things Generic</h3>

<p>If you checked out the lesson structure, you may have noticed that there were quite a few <code class="language-plaintext highlighter-rouge">Chat</code> components, which are rendered as mock text-message conversations on the phone screen like so:</p>

<p><img src="/img/posts/passworks/chat_component.png" alt="mock imessage conversation" class="post-img" /></p>

<p>However, it wasn’t always this way. Initially, only the final activity of Social Engineering was going to have the chat messages, so I hard-coded an array of messages for the <code class="language-plaintext highlighter-rouge">Chat</code> component to render. The chat bubbles turned out to be quite popular with our beta testers, who encouraged me to use it for the other lessons as well. So, I made the <code class="language-plaintext highlighter-rouge">Chat</code> component generic by allowing it to accept a list of chat messages as a prop. You can check out the commit where I did so <a href="https://github.com/uclaacm/passworks/commit/3fb37813787699898899d1baf62d44b1b6523bbb">here</a>.</p>

<p>This process is also how I made a number of other components generic and re-usable in an incremental fashion. I first used a set of mock data to get a working version of the feature, and then extended the component to be generic and able to accept different sets of data. I feel that this approach of making specific cases work and then generalizing reflects good software engineering practices, as it speeds up development and makes it easier to see how a feature (like the <code class="language-plaintext highlighter-rouge">Chat</code> component) might fit into an overall project before writing a bunch of code to include it.</p>

<hr />

<h3 id="custom-vs-prebuilt">Custom vs. Prebuilt</h3>

<p>There were several occasions during the app when I had to decide whether to use a prebuilt component or library, or create a custom component to accomplish something. On one hand, I wanted to use tools that were tailor-made for my requirements. At the same time, I wanted to avoid falling into the trap of trying to reinvent the wheel. I’ll give a couple examples of these decisions, and give some insight on how I made them.</p>

<p>One example of a prebuilt component I used is <a href="https://github.com/glennreyes/react-countup"><code class="language-plaintext highlighter-rouge">react-countup</code></a>, which, in its most basic form, renders a simple animated counter to a number of your choice. It turns out that implementing such a component from scratch can be quite difficult, as there are a number of things to consider such as screen’s refresh rate and how to prevent <a href="https://developers.google.com/web/fundamentals/performance/rendering">jank</a>. In addition, the <code class="language-plaintext highlighter-rouge">react-countup</code> module turned out to be surprisingly flexible for a wide range of use cases, making it quite suitable for the app. I’ll discuss more about how I used the module <a href="#counting-up-to-strings">later in this post</a>, but here’s a quick preview of how it looks in the app:</p>

<p><img src="/img/posts/passworks/countup_example.gif" alt="enumerating passwords with react-countup" class="post-img" /></p>

<p>In other places, I chose not to use prebuilt components. For example, I decided not to go with a prebuilt router library for activity navigation. The router for the activities did not need to be very flexible, since the format of the activities was quite rigid (each activity having some number of slides). Existing router libraries are generic and overly powerful, so customizing them for my own use case would likely require some sort of middle layer anyway. As a result, I decided to write my own simple router.</p>

<p>If you looked through the source code of the app, you might be wondering: “But wait a second, I looked at the <a href="https://github.com/uclaacm/passworks/blob/master/src/App.js"><code class="language-plaintext highlighter-rouge">App.js</code></a> file and React Router is used?” Initially, the app consisted only of the activities, but was later extended to include other sections like the “Most Common Passwords” and “Password Games”. We ended up needing to modify the app to use a prebuilt router in order to handle this increase in scope, so now we use React Router for the overall app, as well as a custom router for nagivating through the activities.</p>

<hr />

<h2 id="bugs-encountered">Bugs Encountered</h2>

<p>While it’d be impossible for me to create a comprehensive list of every bug I encountered during development, here are a few notable or particularly interesting ones and how I solved them.</p>

<h3 id="text-animations">Text Animations</h3>

<p>I encountered some interesting behavior with the animated text messages, where the animation did not refresh if the user navigated to a new activity. So, if I was on the first activity and two messages had been animated on the screen, and then I navigated to the second activity, there would already be two messages on the screen. The desired behavior, of course, would be to have the animation start anew once I clicked to the second lesson.</p>

<p>After some digging, I found out that the problem involves the way that React manipulates the <a href="https://css-tricks.com/dom/">DOM</a>, which is basically a representation of the content on the page. Essentially, React changes the DOM in order to change what is shown on the page, and this can be computationally expensive. For performance benefits, React will sometimes attempt to reuse components to avoid re-rendering content that doesn’t need to be re-rendered. However, since these reused components are not newly created, the browser does not know that it should animate them. To force React to remount the <code class="language-plaintext highlighter-rouge">Chat</code> component, I decided to leverage React’s <a href="https://kentcdodds.com/blog/understanding-reacts-key-prop/"><code class="language-plaintext highlighter-rouge">key</code> prop</a>, which is used to identify a component and control its reuse.</p>

<p>Finally, to ensure a unique <code class="language-plaintext highlighter-rouge">key</code> for each <code class="language-plaintext highlighter-rouge">Chat</code> component, I adopted a singleton pattern:</p>

<div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">let</span> <span class="nx">chatKey</span> <span class="o">=</span> <span class="mi">0</span>

<span class="kd">const</span> <span class="nx">getChatKey</span> <span class="o">=</span> <span class="p">()</span> <span class="o">=&gt;</span> <span class="p">{</span>
  <span class="nx">chatKey</span> <span class="o">+=</span> <span class="mi">1</span>
  <span class="k">return</span> <span class="nx">chatKey</span>
<span class="p">}</span>
</code></pre></div></div>

<p>In each <code class="language-plaintext highlighter-rouge">Chat</code> component, I passed in <code class="language-plaintext highlighter-rouge">key={getChatKey()}</code> to generate a unique key for each copmonent. What this does is ensures that React does not reuse a previous <code class="language-plaintext highlighter-rouge">Chat</code> component, and instead creates and renders a new <code class="language-plaintext highlighter-rouge">Chat</code> component when the screen changes. As a result, the animation starts from the beginning each time we switch between activities.</p>

<hr />

<h3 id="react-countup-bug">react-countup Bug</h3>

<p>I encountered a strange bug after deciding to print the counter’s output to the console (while debugging a different issue). I had set a 10 second delay for the counter to automatically start, and I discovered that the counter would start after waiting out this delay even if I navigated to the next slide, where the counter shouldn’t exist. It appeared that the <code class="language-plaintext highlighter-rouge">useCountUp</code> hook wasn’t unmounted properly when it should have.</p>

<p>One workaround I tried out was setting the <code class="language-plaintext highlighter-rouge">delay</code> prop to be a really high number, effectively high enough that the countup wouldn’t start until after the user finished using the app and closed it.</p>

<p>This bug and the workaround I implemented were quite unsettling, so I investigated the source code of the <code class="language-plaintext highlighter-rouge">useCountUp</code> hook that I was using. I found the following code snippet from <a href="https://github.com/RideReport/react-countup/blob/a8a505d073deef5cc6211dfaed5f963374e9285e/src/useCountUp.js">this file</a>:</p>

<div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nf">useEffect</span><span class="p">(()</span> <span class="o">=&gt;</span> <span class="p">{</span>
  <span class="kd">const</span> <span class="p">{</span> <span class="nx">delay</span><span class="p">,</span> <span class="nx">onStart</span><span class="p">,</span> <span class="nx">onEnd</span><span class="p">,</span> <span class="nx">startOnMount</span> <span class="p">}</span> <span class="o">=</span> <span class="nx">_props</span><span class="p">;</span>
  <span class="k">if </span><span class="p">(</span><span class="nx">startOnMount</span><span class="p">)</span> <span class="p">{</span>
    <span class="kd">const</span> <span class="nx">timeout</span> <span class="o">=</span> <span class="nf">setTimeout</span><span class="p">(()</span> <span class="o">=&gt;</span> <span class="p">{</span>
      <span class="nf">onStart</span><span class="p">({</span> <span class="nx">pauseResume</span><span class="p">,</span> <span class="nx">reset</span><span class="p">,</span> <span class="nx">update</span> <span class="p">});</span>
      <span class="nf">getCountUp</span><span class="p">().</span><span class="nf">start</span><span class="p">(()</span> <span class="o">=&gt;</span> <span class="p">{</span>
        <span class="nf">clearTimeout</span><span class="p">(</span><span class="nx">timeout</span><span class="p">);</span>
        <span class="nf">onEnd</span><span class="p">({</span> <span class="nx">pauseResume</span><span class="p">,</span> <span class="nx">reset</span><span class="p">,</span> <span class="na">start</span><span class="p">:</span> <span class="nx">restart</span><span class="p">,</span> <span class="nx">update</span> <span class="p">});</span>
      <span class="p">});</span>
    <span class="p">},</span> <span class="nx">delay</span> <span class="o">*</span> <span class="mi">1000</span><span class="p">);</span>
  <span class="p">}</span>
  <span class="k">return</span> <span class="nx">reset</span><span class="p">;</span>
<span class="p">},</span> <span class="p">[]);</span>
</code></pre></div></div>

<p>React’s <a href="https://reactjs.org/docs/hooks-effect.html">Effect Hook</a> provides a way to initiate operations with side effects in a component. In order for the hook to clean up resources when the component gets unmounted, the <code class="language-plaintext highlighter-rouge">useEffect</code> callback can optionally return a clean-up function. That’s exactly what happens here with the <code class="language-plaintext highlighter-rouge">return reset</code> statement, which would correctly delete a started counter upon unmount. However, note that in the <code class="language-plaintext highlighter-rouge">if</code>-block there is a <code class="language-plaintext highlighter-rouge">setTimeout()</code> that doesn’t get cleared in the cleanup section, which can cause the counter to start even if the component has been unmounted!</p>

<p>Since having the counter automatically start after mounting was not necessary in this case, I simply <a href="https://github.com/uclaacm/passworks/blob/00cfbbd88302df15f46789c9e8e6edf46999469c/src/components/PasswordGuesser/GuesserAndTimer/GuesserAndTimer.js#L48">set the <code class="language-plaintext highlighter-rouge">startOnMount</code> prop to be <code class="language-plaintext highlighter-rouge">false</code></a>. This meant that <code class="language-plaintext highlighter-rouge">setTimeout</code> was never called, and thus wasn’t an issue any longer. However, this fix wouldn’t work for cases where starting on mount is desired.</p>

<p>Fortunately, someone else caught the same bug and <a href="https://github.com/glennreyes/react-countup/pull/375">filed a PR</a> to fix the issue by clearing the timeout. One more commit was required to actually fix the bug (due to scope issues with the timeout reference), and can be seen <a href="https://github.com/glennreyes/react-countup/commit/94df4e775d65f7bb118a35af656e9eb3b3a29ff8#diff-0875b99271d5068886b72d77f0b9e812">here</a>.</p>

<h2 id="components-vs-hooks">Components vs. Hooks</h2>

<p>This is not so much a bug as it was something I noticed or learned throughout the development process, especially working with the <code class="language-plaintext highlighter-rouge">react-countup</code> module. Initially, I had a lot of difficulties implementing the timer portion of the password-guessing slide, since both of them used the component form of the <code class="language-plaintext highlighter-rouge">react-countup</code> module and I didn’t know how to connect them to the same start button. I believe a lot of this can be attributed to confusion with components and the fact that composing two CountUp components is non-trivial. I ended up switching from the component implementation of <code class="language-plaintext highlighter-rouge">CountUp</code> to the <code class="language-plaintext highlighter-rouge">useCountUp</code> hook, and things became much more simple.</p>

<p><a href="https://github.com/uclaacm/passworks/commit/eaaf2527cae3cdb232a93335640a248e57f262a8">This commit</a> contains most of the work I had to do while transitioning from components to hooks, and provides a decent illustration of the gains from fully switching to hooks. In particular, compare the following code snippets: the first using the <code class="language-plaintext highlighter-rouge">CountUp</code> component and the second using the equivalent hook:</p>

<div class="language-jsx highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">return </span><span class="p">(</span>
  <span class="p">&lt;</span><span class="nc">CountUp</span>
    <span class="na">start</span><span class="p">=</span><span class="si">{</span><span class="mi">0</span><span class="si">}</span>
    <span class="na">end</span><span class="p">=</span><span class="si">{</span><span class="mi">100</span><span class="si">}</span>
  <span class="p">&gt;</span>
    <span class="si">{</span><span class="p">({</span> <span class="na">countUpRef</span><span class="p">:</span> <span class="nx">ref1</span><span class="p">,</span> <span class="na">start</span><span class="p">:</span> <span class="nx">start1</span> <span class="p">})</span> <span class="o">=&gt;</span> <span class="p">(</span>
      <span class="p">&lt;</span><span class="nc">CountUp</span>
        <span class="na">start</span><span class="p">=</span><span class="si">{</span><span class="mi">0</span><span class="si">}</span>
        <span class="na">end</span><span class="p">=</span><span class="si">{</span><span class="mi">100</span><span class="si">}</span>
      <span class="p">&gt;</span>
        <span class="si">{</span><span class="p">({</span> <span class="na">countUpRef</span><span class="p">:</span> <span class="nx">ref2</span><span class="p">,</span> <span class="na">start</span><span class="p">:</span> <span class="nx">start2</span> <span class="p">})</span> <span class="o">=&gt;</span> <span class="p">(</span>
          <span class="p">&lt;</span><span class="nc">Box</span><span class="p">&gt;</span>
            <span class="p">&lt;</span><span class="nt">span</span> <span class="na">ref</span><span class="p">=</span><span class="si">{</span><span class="nx">ref1</span><span class="si">}</span> <span class="p">/&gt;</span>
            <span class="p">&lt;</span><span class="nt">span</span> <span class="na">ref</span><span class="p">=</span><span class="si">{</span><span class="nx">ref2</span><span class="si">}</span> <span class="p">/&gt;</span>
            <span class="p">&lt;</span><span class="nc">Button</span> <span class="na">onClick</span><span class="p">=</span><span class="si">{</span><span class="p">()</span> <span class="o">=&gt;</span> <span class="p">{</span> <span class="nf">start1</span><span class="p">();</span> <span class="nf">start2</span><span class="p">();</span> <span class="p">}</span><span class="si">}</span><span class="p">&gt;</span>Start<span class="p">&lt;/</span><span class="nc">Button</span><span class="p">&gt;</span>
          <span class="p">&lt;/</span><span class="nc">Box</span><span class="p">&gt;</span>
        <span class="p">)</span>
      <span class="o">&lt;</span><span class="sr">/CountUp</span><span class="err">&gt;
</span>    <span class="p">)</span><span class="si">}</span>
  <span class="p">&lt;/</span><span class="nc">CountUp</span><span class="p">&gt;</span>
<span class="p">);</span>
</code></pre></div></div>
<div class="language-jsx highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">const</span> <span class="p">{</span> <span class="na">countUp</span><span class="p">:</span> <span class="nx">countUp1</span><span class="p">,</span> <span class="na">start</span><span class="p">:</span> <span class="nx">start1</span> <span class="p">}</span> <span class="o">=</span> <span class="nf">useCountUp</span><span class="p">({</span> <span class="na">start</span><span class="p">:</span> <span class="mi">0</span><span class="p">,</span> <span class="na">end</span><span class="p">:</span> <span class="mi">100</span> <span class="p">});</span>
<span class="kd">const</span> <span class="p">{</span> <span class="na">countUp</span><span class="p">:</span> <span class="nx">countUp2</span><span class="p">,</span> <span class="na">start</span><span class="p">:</span> <span class="nx">start2</span> <span class="p">}</span> <span class="o">=</span> <span class="nf">useCountUp</span><span class="p">({</span> <span class="na">start</span><span class="p">:</span> <span class="mi">0</span><span class="p">,</span> <span class="na">end</span><span class="p">:</span> <span class="mi">100</span> <span class="p">});</span>
<span class="k">return </span><span class="p">(</span>
  <span class="p">&lt;</span><span class="nc">Box</span><span class="p">&gt;</span>
    <span class="p">&lt;</span><span class="nt">span</span><span class="p">&gt;</span><span class="si">{</span><span class="nx">countUp1</span><span class="si">}</span><span class="p">&lt;/</span><span class="nt">span</span><span class="p">&gt;</span>
    <span class="p">&lt;</span><span class="nt">span</span><span class="p">&gt;</span><span class="si">{</span><span class="nx">countUp2</span><span class="si">}</span><span class="p">&lt;/</span><span class="nt">span</span><span class="p">&gt;</span>
    <span class="p">&lt;</span><span class="nc">Button</span> <span class="na">onClick</span><span class="p">=</span><span class="si">{</span><span class="p">()</span> <span class="o">=&gt;</span> <span class="p">{</span> <span class="nf">start1</span><span class="p">();</span> <span class="nf">start2</span><span class="p">();</span> <span class="p">}</span><span class="si">}</span><span class="p">&gt;</span>Start<span class="p">&lt;/</span><span class="nc">Button</span><span class="p">&gt;</span>
  <span class="p">&lt;/</span><span class="nc">Box</span><span class="p">&gt;</span>
<span class="p">);</span>
</code></pre></div></div>

<p>Some advantages of the hook approach compared to the component approach can be seen in these snippets:</p>
<ul>
  <li><code class="language-plaintext highlighter-rouge">&lt;CountUp /&gt;</code> version is more verbose</li>
  <li><code class="language-plaintext highlighter-rouge">&lt;CountUp /&gt;</code> version has unclear data flow: where do <code class="language-plaintext highlighter-rouge">countUpRef</code> and <code class="language-plaintext highlighter-rouge">start</code> come from?</li>
  <li><code class="language-plaintext highlighter-rouge">&lt;CountUp /&gt;</code> version has greater nesting; <code class="language-plaintext highlighter-rouge">useCountUp</code> provides idiomatic straight-line code</li>
  <li><code class="language-plaintext highlighter-rouge">&lt;CountUp /&gt;</code> version requires knowledge of advanced React features, like <a href="https://reactjs.org/docs/refs-and-the-dom.html">refs</a></li>
  <li>The opaqueness of the <code class="language-plaintext highlighter-rouge">&lt;CountUp /&gt;</code> version leads to <a href="https://en.wikipedia.org/wiki/Cargo_cult_programming">cargo culting</a>. Certainly in my case, I did not fully understand how the component version worked, and the code I wrote was heavily based on samples provided by the module’s documentation.</li>
</ul>

<p>Overall, I had a much better experience working with hooks in this case, and I’ve gained an appreciation for their flexibility and how intuitive it is to use them.</p>

<hr />

<h2 id="some-more-fun-things">Some More Fun Things</h2>

<p>Some aspects of this project were really fun to work on and figure out, so in this section I will discuss a few of those.</p>

<hr />

<h3 id="randomize-button">Randomize Button</h3>

<p>For the first two activities, the user is able to input passwords of their own choice (within the limitations of the activity). However, they can also press the “Randomize” button to have the input be automatically populated by a valid password for the section.</p>

<p>I implemented this button using a few utility functions, which can be found <a href="https://github.com/uclaacm/passworks/blob/a2496efddccc0e11a9bf4e693fee5696bb96f70c/src/constants/lessons.js#L153">here</a>. I implemented a simple <code class="language-plaintext highlighter-rouge">randomInt(min, max)</code> function to randomly pick the an integer inclusively between <code class="language-plaintext highlighter-rouge">min</code> and <code class="language-plaintext highlighter-rouge">max</code>. I also implemented the <code class="language-plaintext highlighter-rouge">getRandom(str, n)</code> function to randomly select <code class="language-plaintext highlighter-rouge">n</code> of characters from an alphabet consisting of the letters in <code class="language-plaintext highlighter-rouge">str</code>. Finally, I implemented a <code class="language-plaintext highlighter-rouge">shuffleString(str)</code> function to shuffle a string of characters.</p>

<p>The most interesting case I used these functions for was the mixed-case password. I first randomly picked the number of uppercase characters, then generated the appropriate-length strings of lowercase characters and uppercase characters, and finally combined and shuffled them using <code class="language-plaintext highlighter-rouge">shuffleString</code>.</p>

<p>Though the algorithms are not the most complex, they were fun for me to implement and test!</p>

<hr />

<h3 id="regular-expressions">Regular Expressions</h3>

<p>I used regular expressions to validate user inputs by writing callbacks that tested the user’s input against hard-coded regular expressions. They weren’t particularly advanced, but it was a reminder of how cool and powerful regular expressions can be (and provided me some much-needed practice).</p>

<hr />

<h3 id="counting-up-to-strings">Counting Up to Strings</h3>

<p>As previously promised, I’ll discuss how I took advantage of the <code class="language-plaintext highlighter-rouge">react-countup</code> module’s flexibility. While it was relatively straightforward to implement a brute-force password generator for numbers by using this module, I needed some way to use the module to generate strings in a similar fashion. A look into the API of the <code class="language-plaintext highlighter-rouge">react-countup</code> module revealed a <a href="https://www.npmjs.com/package/react-countup#formattingfn-value-number--string"><code class="language-plaintext highlighter-rouge">formattingFn</code> prop</a>, which accepts a function that accepts a number and returns a string.</p>

<p>I wanted to be able to use the <code class="language-plaintext highlighter-rouge">react-countup</code> module to display the password generation for strings of letters. Thus, I needed a way to convert a user’s input string of letters to an integer value, something that the <code class="language-plaintext highlighter-rouge">useCountUp</code> hook could use as an end value. I also needed a way to convert the number output back to a string of letters for the user to see.</p>

<p>I came up with the following utility functions, the source file of which you can <a href="https://github.com/uclaacm/passworks/blob/master/src/util/password.js">see here</a>.</p>

<div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">function</span> <span class="nf">toLetters</span><span class="p">(</span><span class="nx">num</span><span class="p">,</span> <span class="nx">alphabet</span><span class="p">)</span> <span class="p">{</span>
  <span class="kd">const</span> <span class="nx">mod</span> <span class="o">=</span> <span class="nx">num</span> <span class="o">%</span> <span class="nx">alphabet</span><span class="p">.</span><span class="nx">length</span>
  <span class="kd">const</span> <span class="nx">pow</span> <span class="o">=</span> <span class="nb">Math</span><span class="p">.</span><span class="nf">floor</span><span class="p">(</span><span class="nx">num</span> <span class="o">/</span> <span class="nx">alphabet</span><span class="p">.</span><span class="nx">length</span><span class="p">)</span>
  <span class="kd">const</span> <span class="nx">out</span> <span class="o">=</span> <span class="nx">alphabet</span><span class="p">[</span><span class="nx">mod</span><span class="p">]</span>
  <span class="k">return</span> <span class="nx">pow</span> <span class="p">?</span> <span class="nf">toLetters</span><span class="p">(</span><span class="nx">pow</span><span class="p">,</span> <span class="nx">alphabet</span><span class="p">)</span> <span class="o">+</span> <span class="nx">out</span> <span class="p">:</span> <span class="nx">out</span>
<span class="p">}</span>

<span class="kd">function</span> <span class="nf">fromLetters</span><span class="p">(</span><span class="nx">str</span><span class="p">,</span> <span class="nx">alphabet</span><span class="p">)</span> <span class="p">{</span>
  <span class="k">if </span><span class="p">(</span><span class="nx">str</span><span class="p">.</span><span class="nx">length</span> <span class="o">===</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
    <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
  <span class="p">}</span>
  <span class="kd">const</span> <span class="nx">out</span> <span class="o">=</span> <span class="nx">str</span><span class="p">[</span><span class="nx">str</span><span class="p">.</span><span class="nx">length</span> <span class="o">-</span> <span class="mi">1</span><span class="p">]</span>
  <span class="kd">const</span> <span class="nx">pow</span> <span class="o">=</span> <span class="nf">fromLetters</span><span class="p">(</span><span class="nx">str</span><span class="p">.</span><span class="nf">slice</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="o">-</span><span class="mi">1</span><span class="p">),</span> <span class="nx">alphabet</span><span class="p">)</span>
  <span class="kd">const</span> <span class="nx">mod</span> <span class="o">=</span> <span class="nx">alphabet</span><span class="p">.</span><span class="nf">indexOf</span><span class="p">(</span><span class="nx">out</span><span class="p">)</span>
  <span class="k">return</span> <span class="nx">pow</span> <span class="o">*</span> <span class="nx">alphabet</span><span class="p">.</span><span class="nx">length</span> <span class="o">+</span> <span class="nx">mod</span>
<span class="p">}</span>
</code></pre></div></div>

<p>These functions convert between numbers and strings based on a particular alphabet, which dictates the character set available. They implement a special case of <a href="https://en.wikipedia.org/wiki/Radix">base conversion</a>, but rather than using 0–9 (base 10), they use a–z (base 26) or any ordered set of characters.</p>

<p>The <code class="language-plaintext highlighter-rouge">toLetters</code> function converts a number to the corresponding string. It computes the modulus as well as the quotient of the input number with the alphabet length. The modulus is used in order to obtain the current letter, and the quotient is decremented before being used in a recursive call to compute the rest of the string. The <code class="language-plaintext highlighter-rouge">fromLetters</code> function converts a string to the corresponding numeric value. It recursively processes each character starting from the last one in the string, and performs the reverse operations done in <code class="language-plaintext highlighter-rouge">toLetters</code>.</p>

<div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nf">fromLetters</span><span class="p">(</span><span class="dl">"</span><span class="s2">bb</span><span class="dl">"</span><span class="p">,</span> <span class="dl">"</span><span class="s2">abc</span><span class="dl">"</span><span class="p">)</span>
<span class="nf">toLetters</span><span class="p">(</span><span class="mi">5</span><span class="p">,</span> <span class="dl">"</span><span class="s2">abc</span><span class="dl">"</span><span class="p">)</span>
</code></pre></div></div>

<p>An interesting thing about this algorithm is that all strings including only the first character in the alphabet are mapped to 0 when converted to numbers. The reason behind this is that the first character is treated as a padding character. In the app, the users are required to input a 6-character password consisting of only a subset of letters from the alphabet. Count up from the 6-letter password “aaaaaa” is thus analogous to counting up from “000000” in the numeric case.</p>

<p>Below is a list of entries that show the conversion between numbers and letters for the alphabet consisting of characters a–z:</p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>   0 "aaaaaa"     26 "aaaaba"     650 "aaaaza"
   1 "aaaaab"     27 "aaaabb"         ...
   2 "aaaaac"         ...         675 "aaaazz"
      ...         51 "aaaabz"     676 "aaabaa"
  25 "aaaaaz"         ...             ...
</code></pre></div></div>

<hr />

<h2 id="final-thoughts">Final Thoughts</h2>

<p>Overall I had a great experience and got to experiment with a lot of cool new things. Though this was a small app, I was able to experience a lot of things that happen in the process of software engineering:</p>
<ul>
  <li>how changes in user requirements can lead to changes in technologies used</li>
  <li>how developing incrementally increases <a href="https://en.wikipedia.org/wiki/Velocity_(software_development)">velocity</a></li>
  <li>working with and debugging previously unfamiliar technologies</li>
</ul>

<p>I also want to give a huge shout out to <a href="https://undraw.co/">unDraw</a>, which was the source for all the beautiful visuals in the app.</p>

<p>If you made it all the way to the end of this post, thank you for bearing with me. I hope you enjoyed, and please reach out to me if you have any questions or comments! :)</p>]]></content><author><name>Jamie</name></author><category term="dev" /><category term="learning labs" /><category term="dev team" /><summary type="html"><![CDATA[In this post, I’ll discuss the process of building Passworks, an educational module consisting of several activities designed to teach password security concepts.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/passworks/default.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/passworks/default.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">How We Made “Getting Mean About Error”</title><link href="https://teachla.uclaacm.com/blog/dev/2020/09/19/how-we-made-getting-mean-about-error/" rel="alternate" type="text/html" title="How We Made “Getting Mean About Error”" /><published>2020-09-19T00:00:00+00:00</published><updated>2020-09-19T00:00:00+00:00</updated><id>https://teachla.uclaacm.com/blog/dev/2020/09/19/how-we-made-getting-mean-about-error</id><content type="html" xml:base="https://teachla.uclaacm.com/blog/dev/2020/09/19/how-we-made-getting-mean-about-error/"><![CDATA[<p>The <a href="https://uclaacm.github.io/getting-mean-about-error/">“Getting Mean About Error” module</a> was a two-quarter-long project that we dove into with a negligible background in web development. Along the way, we picked up a few skills and upgraded our web-dev background from beginner to slightly-less-beginner.</p>

<p>The primary aim of this project is to introduce the statistical concept of Mean Squared Error (MSE) in a beginner-friendly way. That is, we wanted to build a readable and interactive module to kickstart high-school level students’ understanding of machine learning without hurting their heads. We have unbelievably short attention spans ourselves, so we aimed to prioritize simplicity while retaining the integrity of the concept. This was done by using not-so-difficult vocabulary, a larger font, step-by-step animations, and graph examples.</p>

<p>The process of development consisted of content creation, development, testing, and review. First, we received information from <a href="https://uclaacmai.github.io/">ACM AI</a> about the target audience (high school students), the topic of the module (Mean Squared Error), and general sections that the module should include. As developers, we were given the freedom to design the details of the website. This brought us to the planning stage, where we sat down together and decided on content flow, color scheme, supporting graphs, and other structural details. Then, of course, we had to put in the actual work to code all the features on the website. Once we launched our first draft on GitHub, we entered a cycle of testing and review where we would receive weekly feedback on how to improve the website, and go back to development to reflect those ideas and criticisms. We probably learned the most in this stage, and we’re very thankful to our enormous-brained leaders Leo and Matt, and our equally knowledgeable friend Arjun from ACM AI Outreach for their suggestions on how to word certain parts of the lesson, what features should be included, and how the website could best be laid out.</p>

<p>Getting into the technical details, this static web lesson is built off of HTML, CSS, and Javascript. To achieve an elegant page-by-page layout, we used the <a href="https://bulma.io/">Bulma framework</a> for CSS styling. We also used several Javascript libraries for further functionalities, which are <a href="https://mauriciopoppe.github.io/function-plot/">FunctionPlot</a> (an extension of the popular <a href="https://d3js.org/">d3 graphing library</a>) for graphing, <a href="https://mathjs.org/">Math.js</a> for math-parsing, <a href="https://www.mathjax.org/">MathJax</a> for math syntax generation, and <a href="https://animejs.com/">anime.js</a> for basic animation. All these frameworks and libraries were very new to us, but we managed to incorporate them cleanly with the help of online documentation and feedback from our peers.</p>

<p>Most of the obstacles we faced came from the limitations of the libraries we were using, most notably FunctionPlot, our graphing library. Looking back, we definitely could have considered other graphing libraries; it was an oversight on our part not to spend enough time thinking about what functionalities we would want from our graphing library. For example, having the points on the graph labeled with their coordinates would have been very helpful, but is not possible (as far as we can tell) using FunctionPlot. The big selling point of FunctionPlot is its extreme precision, but for our purposes, it could have been worth sacrificing anyway. We really only needed points and lines, and a nice, big font. Like, look at this. We don’t need this.</p>

<p><img src="/img/posts/mean_about_error/function-plot-absurd.png" alt="An image of a very complicated chart, that we definitely didn't need!" /></p>

<p>Thanks for reading our short post! If you have any questions or feedback on our project, we’d love to talk to you. Stay safe!</p>

<p><em>Note: this post was originally finished in June, but went through a few iterations as we implemented the blogs feature. Many thanks to Miles &amp; Michelle for their patience!</em></p>]]></content><author><name>Miles and Michelle</name></author><category term="dev" /><category term="learning labs" /><category term="dev team" /><summary type="html"><![CDATA[The “Getting Mean About Error” module was a two-quarter-long project that we dove into with a negligible background in web development. Along the way, we picked up a few skills and upgraded our web-dev background from beginner to slightly-less-beginner.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://teachla.uclaacm.com/img/posts/mean_about_error/default.png" /><media:content medium="image" url="https://teachla.uclaacm.com/img/posts/mean_about_error/default.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>