A Software Carpentry lesson to learn how to use Make Make is a tool which can run commands to read files, process these files in some way, and write out the processed files. For example, in software development, Make is used to compile source code into executable programs or libraries, but Make can also be used to: run analysis scripts on raw data files to get data files that summarize the raw data; run visualization scripts on data files to produce plots; and to parse and combine text files and plots to create papers. Make is called a build tool - it builds data files, plots, papers, programs or libraries. It can also update existing files if desired. Make tracks the dependencies between the files it creates and the files used to create these. If one of the original files (e.g. a data file) is changed, then Make knows to recreate, or update, the files that depend upon this file (e.g. a plot). There are now many build tools available, all of which are based on the same concepts as Make.

Software Carpentry lesson that teaches how to use databases and SQL In the late 1920s and early 1930s, William Dyer, Frank Pabodie, and Valentina Roerich led expeditions to the Pole of Inaccessibility in the South Pacific, and then onward to Antarctica. Two years ago, their expeditions were found in a storage locker at Miskatonic University. We have scanned and OCR the data they contain, and we now want to store that information in a way that will make search and analysis easy. Three common options for storage are text files, spreadsheets, and databases. Text files are easiest to create, and work well with version control, but then we would have to build search and analysis tools ourselves. Spreadsheets are good for doing simple analyses, but they don’t handle large or complex data sets well. Databases, however, include powerful tools for search and analysis, and can handle large, complex data sets. These lessons will show how to use a database to explore the expeditions’ data.

Library Carpentry lesson: An introduction to Git. What We Will Try to Do Begin to understand and use Git/GitHub. You will not be an expert by the end of the class. You will probably not even feel very comfortable using Git. This is okay. We want to make a start but, as with any skill, using Git takes practice. Be Excellent to Each Other If you spot someone in the class who is struggling with something and you think you know how to help, please give them a hand. Try not to do the task for them: instead explain the steps they need to take and what these steps will achieve. Be Patient With The Instructor and Yourself This is a big group, with different levels of knowledge, different computer systems. This isn’t your instructor’s full-time job (though if someone wants to pay them to play with computers all day they’d probably accept). They will do their best to make this session useful. This is your session. If you feel we are going too fast, then please put up a pink sticky. We can decide as a group what to cover.

Product Design and Development is a project-based course that covers modern tools and methods for product design and development. The cornerstone is a project in which teams of management, engineering, and industrial design students conceive, design and prototype a physical product. Class sessions are conducted in workshop mode and employ cases and hands-on exercises to reinforce the key ideas. Topics include identifying customer needs, concept generation, product architecture, industrial design, and design-for-manufacturing.

In the fall of 2021, students in Pseudoscience courses started creating this open educational resource (OER), which has been built upon by subsequent classes. Our intention is to create a free textbook for this course that might also be used by students of critical thinking elsewhere and of all ages, whether in a classroom or not. Our growing, interactive textbook employs the Paul-Elder Model and other critical-thinking resources, and is freely available to all, learners and educators alike.

The topic of pseudoscience offers a rewarding way for students to learn the value of thinking critically, even as they get to argue things, like Flat Earth Theory and astrology, that may seem trivial at first. At a time when truth is understood as largely subjective, we have, not surprisingly, seen a resurgence in the popularity of pseudosciences and conspiracy theories, which many consider to hold significant truth value, just as valid as physical evidence. It is our aim here to demonstrate the reasoned analysis process — weighing truth, belief, opinion, and fact — so that others may be able to replicate this process and reason through their own questions about vaccines, extra-terrestrials, genetic modification, or the first people to arrive in the Americas.

Software Carpentry lesson on how to use the shell to navigate the filesystem and write simple loops and scripts. The Unix shell has been around longer than most of its users have been alive. It has survived so long because it’s a power tool that allows people to do complex things with just a few keystrokes. More importantly, it helps them combine existing programs in new ways and automate repetitive tasks so they aren’t typing the same things over and over again. Use of the shell is fundamental to using a wide range of other powerful tools and computing resources (including “high-performance computing” supercomputers). These lessons will start you on a path towards using these resources effectively.

This lesson is part of the Software Carpentry workshops that teach how to use version control with Git. Wolfman and Dracula have been hired by Universal Missions (a space services spinoff from Euphoric State University) to investigate if it is possible to send their next planetary lander to Mars. They want to be able to work on the plans at the same time, but they have run into problems doing this in the past. If they take turns, each one will spend a lot of time waiting for the other to finish, but if they work on their own copies and email changes back and forth things will be lost, overwritten, or duplicated. A colleague suggests using version control to manage their work. Version control is better than mailing files back and forth: Nothing that is committed to version control is ever lost, unless you work really, really hard at it. Since all old versions of files are saved, it’s always possible to go back in time to see exactly who wrote what on a particular day, or what version of a program was used to generate a particular set of results. As we have this record of who made what changes when, we know who to ask if we have questions later on, and, if needed, revert to a previous version, much like the “undo” feature in an editor. When several people collaborate in the same project, it’s possible to accidentally overlook or overwrite someone’s changes. The version control system automatically notifies users whenever there’s a conflict between one person’s work and another’s. Teams are not the only ones to benefit from version control: lone researchers can benefit immensely. Keeping a record of what was changed, when, and why is extremely useful for all researchers if they ever need to come back to the project later on (e.g., a year later, when memory has faded). Version control is the lab notebook of the digital world: it’s what professionals use to keep track of what they’ve done and to collaborate with other people. Every large software development project relies on it, and most programmers use it for their small jobs as well. And it isn’t just for software: books, papers, small data sets, and anything that changes over time or needs to be shared can and should be stored in a version control system.

In an Essay, Matthew Todd and colleagues discuss an open source approach to drug development. This Essay outlines how open source methods of working could be applied to the discovery and development of new medicines. There are many potential advantages of an open source approach, such as improved efficiency, the quality and relevance of the research, and wider participation by the scientific and patient communities; a blend of traditional and innovative financing mechanisms will have to be adopted. To evaluate properly the effectiveness of an open source methodology and its potential as an alternative model of drug discovery and development, we recommend that new projects be trialed and existing projects scaled up. Where we stand The scientific and medical community has discovered and developed many groundbreaking medicines that have had a major impact on public health. However, drug development is challenged by a widening gap between health needs and the pharmaceutical industry’s motives and business model, alongside a decrease in efficiency per research dollar spent in medicinal product research and development (R&D), a trend known colloquially as Eroom’s Law. Such fundamental challenges result in frequent high-level calls for new initiatives to develop therapeutics and bring them to market. These include market push and pull mechanisms such as priority review vouchers, advance market commitments, and public R&D funding. New organizational models have also emerged, including public–private partnerships (PPPs) and not-for-profit product development partnerships (PDPs) (for example, the Drugs for Neglected Diseases Initiative [DNDi], the Medicines for Malaria Venture [MMV], and the Global Alliance for Tuberculosis Drug Development [TB Alliance]) that often apply a full “de-linkage” model in which the price of medicines and the cost of R&D are uncoupled.