Open Source Bridge

Learn 3D modelling with OpenSCAD through an hands-on tutorial for modelling Legos

To be successful in photography and API design, you must first understand the constraints of the medium, both technical and non-technical. Learning how to work within constraints and finding your own style are critical to being a successful photographer and API designer.

A modern application has a lot of passwords and keys floating around. Encryption keys, database passwords, and API credentials; often typed in to text files and forgotten. Fortunately a new wave of tools are emerging to help manage, update, and audit these secrets. Come learn how to avoid being the next TechCrunch headline.

A “black box” test sends input to your program and tests the output. But a networked application has I/O at two ends: the API and the network. A black box test can’t validate it, especially its error-handling. But a “black pipe” test can! Such a test talks to your code over the network at the same time as it tests the API. I’ll present a handy library for Black Pipe tests of MongoDB apps and advise you when to use it. I want you to write a library like it for your favorite DB, so we can all test our programs better!

Much of the interest in MindRider stemmed from Spencer Lowell's great photo in Wired UK. Since it came out, many people have sent me great comments, saying things along the lines of "Women represent!" or "POCs (People of Color) represent!" or "Filipinos represent!" This has meant a lot. Women and people of color are still underrepresented in both tech and cycling domains, and I've come to think of the MindRider photo, and the ensuing response, as a personal counterbalance to the aggressive, intolerant, exclusionary discourse that still plagues these domains, and especially plagues the startup sector that overlaps both. Some people call this "brogrammer talk." I've witnessed it in my time at MIT, and while I've noticed that most people don't talk or think this way, the loudness of the intolerant minority can have insidious, stressful effects on the rest of the community.

We will explore how we can utilize webvr to build amazing VR experience right into everyone's pocket, using their mobile phones they use right now. No need for expensive or closed source tools or solutions. Utilize the mobile phone with cardboard and uisng just javascript and html to build VR world. How using api's of webvr and Aframe we game developers and UI builders can build awesome experience.

Many people create projects with amazing technical prowess, only to see it fail to gain traction. We wonder "I thought this was clearly the best solution, why aren't people using it? Did I miss some bugs? Is it too slow? What went wrong?" The answer usually isn't technical, it's documentation or community related. This talk will teach you all the non-technical things your project needs to gain traction.

What makes companies with good intentions fail so miserably at open source? How can we (as engineers and managers) influence our bosses to "do the right thing"?

The free/open source software movement is over thirty years old, and has gone through a number of changes in that time, spawning projects large and small (including OpenConferenceWare, which runs this site!). If Free Software is the first generation, and Open Source is the second, current efforts toward creating an inclusive and sustainable world make up a third generation that we can start to form into a broader plan.

Despite the media attention given to the diversity in tech problem, many technology practitioners don't see how a lack of diversity affects their daily life. So, it is not surprising that they neither understand the magnitude of the problem nor how they can fix it. However, the principles and language of debugging, something technology practitioners understand well, can be used to help them understand diversity and their role in solving the problem. So, technologists already have a set of terms that they can use to tackle diversity. They just need to know how to apply those terms in order to effect positive change. These terms are expected behavior, tracing, refactoring, and sample code.

Long ago, in the early ages of computerdom, a language was formed from the primordial fires of Tartarus. The language would bind the spells of textual strings and forever control them: The Regular Expression. How about an interactive workshop for acolytes who wish to command this strong magic?

Good engineers write good code, but the best engineers raise the skills of their junior colleagues, too. If you're a senior engineer, you must learn to mentor new hires. Besides, great mentors are critical to the careers of women and minorities in tech. I have failed at mentoring, then succeeded. Learn from me and march to mentorship triumph.

Miscommunication, wasted time, hurt feelings: real dangers when communicating with strangers online. As FOSS maintainers and contributors, let's try documenting our communication guidelines the same way we document our code style guidelines.

Julia Nguyen leads if me, an app to share mental health experiences with loved ones. In doing so, she has explored her insecurities with mental illness, learned how to engage diverse contributors, and developed better software practices with Ruby on Rails and JavaScript. She’ll share the lessons she has learned from transforming a passion project into an open source project. Inclusion takes on many forms in an open source project, including supporting contributors from all types of backgrounds, being empathetic to their project goals, and trusting them to take lead. As a mental health project, if me must also accommodate its contributors who face their own mental health challenges. All open source projects should do the same. Managing people is just as important as managing technical contributions in software.

In many open source communities, privilege is rarely discussed. While it is not an easy topic to talk about, it is an important subject to explore if we want to make sure open source is truly open to everyone. After exploring sources of privilege and learning strategies to deal with it, we can all be better equipped to take action to improve our open source communities for the long run.

Money is a common worry, inside the open source community and out, but we often feel uncomfortable discussing it. We’ll talk about why that is and how our social norms around money impact who participates in open source and how they do so. The heart of this talk will be a series of case studies based on interviews with community members covering various economic models for open source, including worker co-ops, grant-funded and academic projects, for-profit business models, crowdfunding campaigns, and all-volunteer projects. We’ll explore the sustainability of each model as well as how they deal with the social pressures outlined in the first part of the talk.

We love Ruby for its elegance, its simplicity, its flexibility. But our favorite language perches atop a whole world of native code, and that other world occasionally intrudes.

Open source has moved from experimental to mainstream in the past 10 years, but has definitely changed the landscape in the last 15 years. Because of that, we have a few generations of people within the broader ecosystem, and they probably have no idea that all of these communities exist, much less the fact that there's a whole ocean of a open source technology industry out there.

When you run an online service, you always hope you won't have to deal with abuse. But it's inevitable, and many situations aren't clear-cut as you might wish. Some examples of abuse are obvious, but this talk explores the grey areas and messy questions: what content should you consider a violation of your Terms of Service, and how do you handle it when it's reported to you?

Like many young Muggles of the early 00's, I dreamed of receiving my Hogwarts letter. But re-reading the series with an eye toward learning lessons about creating a positive learning environment, it's clear that Hogwarts School of Witchcraft and Wizardry contains some unfortunate lessons in what NOT to do. When it comes to crafting an environment that encourages asking questions, fosters cooperation, and ensuring the success of its developers -- I mean, wizards -- we can learn a lot from the mistakes of the Hogwarts faculty. In this magical talk, you'll learn how to be a better mentor and help your workplace become a place where your junior developers can flourish.

Growing concerns of media preservation mean a surge of new digital libraries. However, digital preservation is more than just photos and video; it's also interactive software: art creating new art. We will explore the problem of preserving software; past, present, and future; and why it is hard.

I first knowingly witnessed the "Maker Movement" in 2010, heeded its siren call by joining the MIT Media Lab in 2011, and became disillusioned later that year. But I've been stubbornly making--and critiquing the notions of Making--ever since.

Many people identify their gender in many ways. So why do we build systems to capture accurate gender information with a dropdown that only lists “male” and “female”? This talk covers why you might want to consider alternative ways of selecting gender for your users, a brief overview of the current best practices, the case study of the decisions I made when creating my open source project Gender Amender (a library you can help work on right now!), and why more work needs to be done. I'd also like to facilitate a short discussion during the time slot, so that we can share varied perspectives on how to improve the entire process of gender collection, and articulate the lenses through which we can and should view gender (e.g. “what are some other data structures we could use to capture gender identity information?”).

This talk will cover the fascinating things happening in the open source diabetes tech (D Tech) space (think the Glucosio Project and Nightscout Project) and will emphasize the importance of open source in improving the health outcomes of people with diabetes.

What can you do when someone submits a bad patch to your project? To begin, we have to understand why people hunger to contribute code: they're fans. You hurt fans' feelings when you reject their patches, but you hurt your project if you accept them. You can get out of this bind! Give your fans other ways to be recognized. Showcase their plugins in your project’s wiki, or rewrite their patches while giving them credit, or feature their related projects on your site.

For those who want to do more than just code, this talk will show you 8 ways I have contributed without opening up Vim once.

Your Python program is too slow, and you need to optimize it. Where do you start? With the right tools, you can optimize your code where it counts. With the Python profiler “Yappi” we’ll learn how to find the maximum performance wins with minimum effort.

What are regular expressions, what are they useful for, and why are they so hard to read? We'll learn what regular expressions are good for, how to make our own regular expressions, and how to make our regular expressions friendly and readable (yes it's possible... sometimes).

Inspired by security and privacy research in operating systems, we'll be discussing possible ways to redesign privacy models so that all users can have fine-grained control over both visibility of their content and how others can interact with it.

The Supreme Court's ruling in the landmark Alice vs. CLS Bank case has finally given the lower courts some tools they could use to overturn obvious and vague patents, particularly frivolous patents on software. But we haven't won, because bogus patent suits are still being filed. This talk is for anyone who is wondering what the recent decisions mean for small and mid-size entities, how international treaties can impact local policy and what can be done to improve the situation.

Mental disorders are the largest contributor to disease burden in North America, but the developer community and those who employ us are afraid to face the problem head-on. In this talk, we'll examine the state of mental health awareness in the developer workplace, why most developers feel it isn't safe to talk about mental health, and what we can do to change the culture and save lives. Attendees will leave with 5 things they can do to make their workplace safer for those dealing with mental health disorders.

What if U.S. federal agencies decided to reuse and contribute to open source software projects built by other agencies, since agencies often have similar technology problems to solve? And what if they hired technical writers with open source community experience to write documentation for these projects? That would be pretty cool. Also, that’s my work. I'm part of 18F, a digital services consulting team within and for the federal government, and all of our work is open source.

Have you ever wondered where the perception that technology is a masculine pursuit comes from? Or why we have to explain that, "no really, women are interested in computers too"?

What if your next hire could make your team faster, help create a more inclusive and diverse environment, be easy to find, and be super excited to work with you? These people are not unicorns, they're junior developers. Most teams just don't know how to bring them on and get these benefits. Whether you're in a startup, consultancy, or a BigCo, with a few tips and processes, any team can learn how to grow new developers.

Think of a shibboleth as a proverbial line in the sand that determines who belongs and who is an outsider. There are a lot of arbitrary shibboleths in programming. Text editors (emacs vs. vim vs. sublime), paradigms (object-oriented vs. functional), languages (everyone vs Java), type systems, are all topics of… to put it lightly, “vigorous conversation.” In set theory terms, the developer community does not do enough to encourage seeing different developer groups as unions instead of intersections. To a newcomer, this situation sets up too much of a danger of alienation. If someone makes fun of the language that you use to learn how to code, then you’re less likely to want to keep learning.

What goes into making a helpful bug report, if you're not even given access to the repository? Why should you, the user, report bugs? How do you navigate a series of gatekeepers who don't want to acknowledge your bugs? How do you maintain a good relationship with people in charge of a project that's screwing up your whole life?

Lots of geeks have depression. Come talk about what helps you overcome your depression, and learn about bluehackers.org

Contribute with us! PyLadies PDX and OpenHatch are teaming up to host this drop-in session for those who want to contribute to open source, but don't know how to get started. Learn the basics and get set up with OpenHatch. Goal is to submit a patch by the end of the night!