Studying computer science is a journey: people start at different times, travel at different paces, and pause along the way. In this experience report, we describe a peer-led, year-long program designed to welcome students to Computer Science and Engineering as a discipline, department, and academic program. We detail the logistical, curricular, and personnel structures of this program, highlighting design choices we made to (a) open multiple ways to join the program all year, (b) de-emphasize "getting ahead", (c) prioritize reflection, and (d) connect students to existing resources. Throughout, we emphasize the critical role of peer mentors in leading and shaping this space. We share our own lessons learned, as well as reflections from students and mentors on the value of this learning community outside of formal classroom structures.

Now that students in our introductory object-oriented programming course are more familiar with Zoom and screen sharing, we consider novel assessments that leverage these tools. We developed a style of assessment where students submit a recorded screencast of them tracing a submitted program. We describe the design of the assessment and tracing prompts, and we report on an analysis of 59 submitted student videos. Our findings include common mistakes and aspects of student understanding that were expressed in the video but not in the text and code submitted by students. For example, we observed different strategies that yielded the same correct trace of a loop, as well as incorrect traces of students' own correct recursive programs. These guide us towards ways to refine the assessment and prompts in future iterations.

At our large U.S. research-intensive university, Chicano/Latino and Black/African-American students have been disproportionately leaving the Computer Science and Engineering (CSE) majors at a higher rate than students without these identities. To uncover possible reasons for this, we invited students in these majors who identify as Chicano/Latino and Black/African-American to participate in focus groups. Twelve students, all identifying as Latinx/Hispanic, partici- pated in the focus groups. We identify several themes related to challenging aspects of the student experience, spanning physical campus environment, department curriculum and policies, and connections between students. We triangulate these findings with results from a survey measuring sense of belonging, confidence, and obstacles for thousands of students across eight introductory CSE courses. We discuss how these themes relate to actions that departments can take to address these challenges.

We propose that secondary-school data-science curricula should be based on four key ingredients: two are technical (programming and statistics, with visualization sitting at their intersection), while two are human-facing (meaningful domains, and civic responsibility). We describe their relationship and argue for their importance.

Integrating computing into other subjects promises to address many challenges to offering standalone CS courses in K-12 contexts. Integrated curricula must be designed carefully, however, to both meet learning objectives of the host discipline and to gain traction with teachers. We describe the multi-year evolution of Bootstrap, a curriculum for integrating computing into middle- and high-school mathematics. We discuss the initial design and the various modifications we have made over the years to better support math instruction, leading to our goal of using integrated curricula to cover standards in both math and CS. We provide advice for others aiming for integration and raise questions for CS educators about how we might better support learning in other disciplines.

Scores of compilers produce JavaScript, enabling programmers to use many languages on the Web, reuse existing code, and even use Web IDEs. Unfortunately, most compilers inherit the browser's compromised execution model, so long-running programs freeze the browser tab, infinite loops crash IDEs, and so on. The few compilers that avoid these problems suffer poor performance and are difficult to engineer.

Data Science is at the center of many current curricular efforts. It is emerging as an integrated field that has far-reaching and important applications, from news media to policy making to business. While these applications can provide compelling uses of computer science techniques, an introduction to one is not an introduction to the other. How do topics like data structures and program design emerge from data science applications? How do we transition from data science applications to computer science topics? How can data science be integrated into other contexts with little overhead? This workshop presents assignments and curricula designed to answer these questions, and tools that support them.

In in-flow peer review, students provide feedback to one another on intermediate artifacts on their way to a final submission. Prior work has studied examples and tests as a potentially useful initial artifact for review. Unfortunately, large test suites are onerous to produce and especially to review. We instead propose the notion of a sweep, an artificially constrained set of tests that illustrates common and interesting behavior. We present experimental data across several courses that show that sweeps have reasonable quality, and are also a good target for peer review; for example, students usually (over half the time) suggest new tests to one another in a review.

Test-first development and peer review have been studied independently in computing courses, but their combination has not. We report on an experiment in which students in two courses conducted peer review of test suites while assignments were in progress. We find strong correlation between review ratings and staff-assessed work quality, as well as evidence that test suites improved during the review process. Student feedback suggests that reviewing had some causal impact on these improvements. We describe several lessons learned about administering and assessing peer-review within test-first development.

Peer review is effective for teaching students to evaluate approaches to problems, fostering collaboration, and assessing other students' work. Peer review often happens after assignments are turned in, on complete artifacts that other students have created. We've been experimenting with a different style of peer review, which we call in-flow reviewing, in which programming assignments are broken into reviewable stages. After students complete each stage they review one anothers' work, allowing for feedback early on in the assignment. We've built a system, dubbed Captain Teach, for exploring in-flow reviewing for both programming and written assignments. In our demonstration and tutorial, we will show what the student experience looks like for a Captain Teach assignment, explain the interface that instructors have for creating assignments in Captain Teach, outline some of the mechanisms for anonymously assigning reviews and distributing feedback, and discuss future directions for the tool.

Computing educators have used peer review in various ways in courses at many levels. Few of these efforts have applied peer review to multiple deliverables (such as specifications, tests, and code) within the same programming problem, or to assignments that are still in progress (as opposed to completed). This paper describes CaptainTeach, a programming environment enhanced with peer-review capabilities at multiple stages within assignments in progress. Multi-stage, in-flow peer review raises many logistical and pedagogical issues. This paper describes CaptainTeach and our experience using it in two undergraduate courses (one first-year and one upper-level); our analysis emphasizes issues that arise from the conjunction of multiple stages and in-flow reviewing, rather than peer review in general.

Web pages routinely incorporate JavaScript code from third-party sources. However, all code in a page runs in the same security context, regardless of provenance. When Web pages incorporate third-party JavaScript without any checks, as many do, they open themselves to attack. A third-party can triv ially inject malicious JavaScript into such a page, causing all manner of harm. Several such attacks have occurred in the wild on prominent, commercial Web sites. A Web sandbox mitigates the threat of malicious JavaScript. Several Web sandboxes employ closely related language-based techniques to maintain backward-compatibility with old browsers and to provide fine-grained control. Unfortunately, due to the size and complexity of the Web platform and several subtleties of JavaScript, language-based sandboxing is hard and the Web sandboxes currently deployed on major Web sites do not come with any formal guarantees. Instead, they are routinely affected by bugs that violate their intended sandboxing properties. This article presents a type-based approach to verifying Web sandboxes, using a JavaScript type-checker to encode and verify sandboxing properties. We demonstrate our approach by applying it to the ADsafe Web sandbox. Specifically, we verify several key properties of ADsafe, falsify one intended property, and find and fix several vulnerabilities, ultimately providing a proof of ADsafe's safety.

JavaScript programs vary widely in functionality, complexity, and use, and analyses of these programs must accommodate such variations. Type-based analyses are typically the simplest such analyses, but due to the language's subtle idioms and many application-specific needs---such as ensuring general-purpose type correctness, security properties, or proper library usage---we have found that a single type system does not suffice for all purposes. However, these varied uses still share many reusable common elements.

We present a small-step operational semantics for the Python programming language. We present both a core language for Python, suitable for tools and proofs, and a translation process for converting Python source to this core. We have tested the composition of translation and evaluation of the core for conformance with the primary Python implementation, thereby giving confidence in the fidelity of the semantics. We briefly report on the engineering of these components. Finally, we examine subtle aspects of the language, identifying scope as a pervasive concern that even impacts features that might be considered orthogonal.

We present S5, a semantics for the strict mode of the ECMAScript 5.1 (JavaScript) programming language. S5 shrinks the large source language into a manageable core through an implemented transformation. The resulting specification has been tested against real-world conformance suites for the language. This paper focuses on two aspects of S5: accessors (getters and setters) and eval. Since these features are complex and subtle in JavaScript, they warrant special study. Variations on both features are found in several other programming languages, so their study is likely to have broad applicability.