Feed aggregator

Description:
Fear, Uncertainty, Doubt, and Disinformation exists around the modern computer processor. Revelations brought about from leaks has left the technology community concerned about what is being integrated into their hardware and what kind of vulnerabilities exist. This discussion will introduce concepts such as Active Management Technology, Trusted Execution Environments, and Out-Of-Band system access.

About Aaron:
Aaron is an experienced Linux user with several years of teaching experience. He works in the industry as a software developer while also providing consultancy on cyber security related topics. His discussions are AZ Post certified for training credit for law enforcement and he prides himself on providing quality educational material that is relevant and topical. He has a Masters Degree in Intelligence Analysis with a focus in Cyber Security, is a life long learner, and prides himself on staying up to date with the ever changing field of cyber security.

This month der.hans will present "ActivityPub: Decentralized Social Networking" for us.

Description:
ActivityPub is a decentralized social networking protocol for allowing various services to interact.
For instance, a long form blog engine can use an external microblogging service for comments.
ActivityPub is based on the ActivityStream 2.0 data format. It provides client to server APIs and server to server APIs for server to server federating.

Attendees will learn about:

• Why decentralized social networking is useful
• The history of ActivityPub
• The history of decentralized social networking
• Overview of some activities available through ActivityPub
• List of services implementing ActivityPub
• Now what?

Biography:
der.hans is a Free Software community veteran, presenter and author. He is the founder of the Free Software Stammtisch, BoF organizer for the Southern California Linux Expo (SCaLE) and chairman of the Phoenix Linux User Group (PLUG).
As a technology and entrepreneurial veteran, roles have included director of engineering, engineering manager, IS manager, system administrator, community college instructor, developer and DBA.
He presents regularly at large community-led conferences (SCaLE, SeaGL, LibrePlanet, LFNW, Tübix) and many local groups. 

Watch keynotes covering Jupyter's role in business, data science, higher education, open source, journalism, and other domains, from JupyterCon in New York 2018.

People from across the Jupyter community are coming together in New York for JupyterCon. Below you'll find links to keynotes from the event.

All the cool kids are doing it, maybe we should too? Jupyter, gravitational waves, and the LIGO and Virgo Scientific Collaborations

Will Farr offers lessons about the many advantages and few disadvantages of using Jupyter for global scientific collaborations.

• Watch "All the cool kids are doing it, maybe we should too? Jupyter, gravitational waves, and the LIGO and Virgo Scientific Collaborations."

Jupyter trends in 2018

Paco Nathan shares a few unexpected things that emerged in Jupyter in 2018.

• Watch "Jupyter trends in 2018."

Sustaining wonder: Jupyter and the knowledge commons

Carol Willing shows how Jupyter's challenges can be addressed by embracing complexity and trusting others.

• Watch "Sustaining wonder: Jupyter and the knowledge commons."

Jupyter in the enterprise

Luciano Resende explores some of the open source initiatives IBM is leading in the Jupyter ecosystem.

• Watch "Jupyter in the enterprise."

The reporter’s notebook

Mark Hansen explains how computation has forever changed the practice of journalism.

• Watch "The reporter’s notebook."

Why contribute to open source?

Julia Meinwald outlines effective ways to support the unseen labor maintaining a healthy open source ecosystem.

• Watch "Why contribute to open source?"

Machine learning and AI technologies and platforms at AWS

Dan Romuald Mbanga walks through the ecosystem around the machine learning platform and API services at AWS.

• Watch "Machine learning and AI technologies and platforms at AWS."

Democratizing data

Tracy Teal explains how to bring people to data and empower them to address their questions.

• Watch "Democratizing data."

The future of data-driven discovery in the cloud

Ryan Abernathey makes the case for the large-scale migration of scientific data and research to the cloud.

• Watch "The future of data-driven discovery in the cloud."

Keynote by Michelle Ufford

tk

• Watch "Keynote by Michelle Ufford."

Jupyter notebooks and the intersection of data science and data engineering

David Schaaf explains how data science and data engineering can work together to deliver results to decision makers.

• Watch "Jupyter notebooks and the intersection of data science and data engineering."

Disease prediction using the world's largest clinical lab dataset

tk.

• Watch "Disease prediction using the world's largest clinical lab dataset."

Data science as a catalyst for scientific discovery

Michelle Gill discusses how data science methods and tools can link information from different scientific fields and accelerate discovery.

• Watch "Data science as a catalyst for scientific discovery."

Sea change: What happens when Jupyter becomes pervasive at a university?

Fernando Perez talks about UC Berkeley's transition into an environment where many undergraduates use Jupyter and the open data ecosystem as naturally as they use email.

• Watch "Sea change: What happens when Jupyter becomes pervasive at a university?"

-->

Continue reading Highlights from JupyterCon in New York 2018.

Carol Willing shows how Jupyter's challenges can be addressed by embracing complexity and trusting others.

Continue reading Sustaining wonder: Jupyter and the knowledge commons.

Paco Nathan shares a few unexpected things that emerged in Jupyter in 2018.

Continue reading Jupyter trends in 2018.

Luciano Resende explores some of the open source initiatives IBM is leading in the Jupyter ecosystem.

Continue reading Jupyter in the enterprise.

Mark Hansen explains how computation has forever changed the practice of journalism.

Continue reading The reporter’s notebook.

Will Farr offers lessons about the many advantages and few disadvantages of using Jupyter for global scientific collaborations.

Continue reading All the cool kids are doing it, maybe we should too? Jupyter, gravitational waves, and the LIGO and Virgo Scientific Collaborations.

Julia Meinwald outlines effective ways to support the unseen labor maintaining a healthy open source ecosystem.

Continue reading Why contribute to open source?.

Dan Romuald Mbanga walks through the ecosystem around the machine learning platform and API services at AWS.

Continue reading Machine learning and AI technologies and platforms at AWS.

Scheduling Notebooks, Telepresence Parasite, Bite-Size ML Tutorials, and AI Data Sheets

1. Scheduling Notebooks -- we’re currently in the process of migrating all 10,000 of the scheduled jobs running on the Netflix Data Platform to use notebook-based execution.
2. Fusion: A Collaborative Robotic Telepresence Parasite That Lives on Your Back -- I'm in favor of any telepresence system that lets me remotely punch people.
3. 100 Days of ML Code -- tutorials, open sourced.
4. Fact Sheet for AI (IBM) -- Fairness, safety, reliability, explainability, robustness, accountability—we all agree they are critical. Yet, to achieve trust in AI, making progress on these issues will not be enough; it must be accompanied by the ability to measure and communicate the performance levels of a system on each of these dimensions. One way to accomplish this would be to provide such information via SDoCs or factsheets for AI services.

Continue reading Four short links: 24 August 2018.

Lessons from hundreds of development practice assessments across the industry.

For more than 15 years, my colleagues and I at the Software Improvement Group (SIG) have been in the business of evaluating the quality of code, architecture, and development practices for our customers.

Recently, we dove into our assessment data to discover—and quantify—trends in software development, each time comparing 2016 to 2017. Below, we summarize our findings into five quantified trends, then discuss the developments that drive them. Spoiler alert: they are all about automation.

Trend 1: The percentage of teams that do not automate deployment shrank from 26% in 2016 to 11% in 2017

We measure the practice of deployment automation by looking at whether teams have a deployment process in place that is quick, repeatable, and (preferably) fully automated.

For example, a team that deploys each new release with a single push of a button would receive a perfect score on this practice, codified as fully applied. But a team that needs to go through a limited number of well-documented manual steps would be scored as partially applied.

Figure 1. More teams fully apply deployment automation (43%, up from 30%) and fewer teams do not apply deployment automation at all (11%, down from 26%). Image by Joost Visser. Trend 2: Teams that fully apply continuous integration (CI) now outnumber those that don’t (41% versus 32% in 2017; was 33% versus 39% in 2016)

The trend for continuous integration (automatic compilation and testing after each change) lags behind the trend for deployment automation, but overall, it shows a similar improvement.

Figure 2. Full or partial adoption of continuous integration (68% in 2017) has improved significantly but still lags compared to deployment automation (89% in 2017). Image by Joost Visser. Trend 3: The number of teams that apply continuous delivery (CD) is a small but growing minority (16% in 2017 versus 11% in 2016)

Especially for continuous delivery (automatic deployment after each change), the great majority of teams (and the organizations of which they are part) still have a long way to go. But their numbers are growing.

Figure 3. Most teams still do not apply continuous delivery, either fully (16%; was 11%) or partially (12%; was 6%). Image by Joost Visser. Trend 4: More teams are enforcing full quality control (31% in 2017, up from 23% in 2016)

To assess code quality control, we observe whether a team works with clear coding standards, systematically reviews code (against these standards and against principles of good design), and whether they perform automated code quality checks. Full adoption of code quality control has increased somewhat (31%, up from 23%), but 20% of teams are still producing code without adequate quality control in place.

Figure 4. Fewer teams are failing to enforce consistent code quality control (20%, down from 25%). Image by Joost Visser. Trend 5: The number of teams that change their code without proper regression testing is declining but was still a staggering 41% in 2017 (down from 48% in 2016)

To assess testing practices, we observe whether teams have an automated regression test suite that is being executed consistently after each change. Full adoption of this practice is increasing (33%, up from 29%). But changing code without proper regression testing is still uncannily common (41%; was 48%).

Figure 5. Fewer teams fail to run automated test at each commit (41%, down from 48%). Image by Joost Visser. So what do all of these numbers mean?

End-to-end automation of the software development process has gone mainstream. While automation of individual programming tasks (compilation, testing, documentation, etc.) has been part and parcel of our discipline for many years, we now see that all modern software development teams are striving to automate as much of the software development process as possible.

Automation helps to increase development speed, limit knowledge dissipation, and build quality into every step. If your team isn’t automating, now is the time to start.

If you’d like to learn where your team stands in terms of the above practices and trends, you can do a quick self-assessment by taking our survey.

This post is a collaboration between O'Reilly and SIG. See our statement of editorial independence.

Continue reading 5 automation trends in software development, quantified.

It’s only when you enable people to “do things” together that the real power of online social networks is unleashed.

I still remember the moment I saw a big piece of the future. It was mid-1999, and Dave Winer called to say there was something I had to see.

He showed me a web page. I don’t remember what the page contained except for one button. It said, "edit_this_page"—and, for me, nothing was ever the same again.

I clicked the button. Up popped a text box containing plain text and a small amount of HTML, the code that tells a browser how to display a given page. Inside the box I saw the words that had been on the page. I made a small change, clicked another button that said, “Save this page” and voilà, the page was saved with the changes....

Dave was a leader in a move that brought back to life the promise, too long unmet, that Tim Berners-Lee, inventor of the Web, had wanted from the start. Berners-Lee envisioned a read/write Web. But what had emerged in the 1990s was an essentially read-only Web on which you needed an account with an ISP to host your web site, special tools, and/or HTML expertise to create a decent site.

What Dave and the other early blog pioneers did was a breakthrough. They said the Web needed to be writeable, not just readable, and they were determined to make doing so dead simple.

Thus, the read/write Web was truly born again.

DAN GILLMOR, DAVE WINER: A TOAST, http://bit.ly/1gnjETA

Collaboration

The first thing I ever posted on the Web was person: a story (http://ezone.org/no/bird.html). The next thing I produced and posted was collaborative: a magazine (http://ezone.org). This was 1994. We knew we wanted to engage newcomers more fully than the traditional letters to the editor, and many of the letters (and email messages) we received at the time were submissions. People wanted to work with us and we wanted to work with them, and they came from all over the world. We managed for four years with no system in place besides a series of personal understandings, but any form of collaboration requires some form of orchestration, and our ad hoc approach didn’t scale.

In the earliest days of online social-networking applications (think SixDegrees and Friendster), there eventually came the “so what” problem: you could make an account, register your name, find people, connect to them, and then... what? There was no there there. You might be able to form groups and discuss things, but of course you could already do that through a lot of other interfaces (such as email lists and Usenet, for Pete’s sake), even if they weren’t explicitly noted as social.

No, it’s only when you begin enabling people to “do things” together that the real power of online social networks kicks in.

Today, it’s possible to orchestrate collaborative groups through a series of time-tested, well-proven design patterns. These patterns provide people with a shared space, give them a way to invite others, provide the means for managing tasks, employ version control, and look after people’s rights.

Wiki projects, such as the omnipresent Wikipedia; open source software development using tools such as Sourceforge, Collabnet, and Github; Yahoo! Groups; and charismatically driven groups of people such as Ze Frank’s (http://zefrank.com) fanbase, which you can see in Figure 1-1, have all demonstrated the power that can be unleashed when you give people interfaces for working together on their shared concerns.

Figure 1-1. Ze Frank’s “If the earth were a sandwich” challenge recruited numerous participants into attempting to place slices of bread at antipodes, to turn the planet into a sandwich.Manage Project What

When people get together and form groups, they often discover a shared desire to accomplish something tangible or complex, frequently something with a real-world (offline) impact (see Figure 1-2).

Figure 1-2. You can use most social interfaces to organize projects by sheer force of effort, but it’s easier if you’ve got at least the fundamentals of project management available, such as tasks, calendars, file upload, and collaborative editing.

This pattern is also known as a “Workspace” pattern.

Use when

Use this pattern when you have enabled group formation and wish to host and support group project activities. If you don’t have the bandwidth (literally or figuratively) to support this, consider supporting third-party services.

How

• Support your members’ ability to orchestrate projects by coordinating goals, tasks, and deadlines among multiple participants with varying degrees of commitment and availability.

• Provide a workspace for connecting all the facets of the project (people, tasks, dates, collateral) and, if possible, offer a summarized dashboard view linking to more detailed inventories by facet. This makes asynchronous communication possible across disconnected geographies.

• Provide a mechanism for the creator of the project or a participant to bring in collaborators with Send Invitation, and possibly to assign varying rights by individual or group, as shown in Figure 1-3.

  Figure 1-3. With Basecamp, you can add an entire company (team) to your project or invite individuals by adding them to an existing company.

• Support task management with the ability to assign tasks, accept tasks, and distribute processes among multiple participants by breaking them down into individual tasks. Optionally support the ability to declare that one task is dependent on another and possibly calculate the critical path to the end goal.

• Provide a calendar on which deadline and milestone dates can be scheduled and then verified.

• Offer the ability to send messages to project participants, as well as reminders and notifications.

• Provide a means for collaborative editing of documents or source code, including version control (Figure 1-4).

  Figure 1-4. At GitHub, I can make my own clone of the YUI 3.0 codebase, fork it, and then have it merged back into the main trunk.

• Include a way for project participants to make and keep track of decisions.

• Optionally provide an interface for project blogging or statuscasting so that project participants can report on their progress and anyone can see at a glance what has been happening lately on the project. Or, provide a timeline view on the dashboard to roll up all recent events in chronological order.

Why

Giving your community members the tools to work together or comanage their own efforts increases the utility of your service and the culture of the social environment. However, your users can often do this effectively via email and phone and perhaps a filesharing system. Do you have anything more to offer? Do you need to?

Related patterns

Calendaring

Face-to-Face Meeting

Group Conversation

Open APIs

Send Invitation

Activity Streams

As seen on

Asana

Confluence

Basecamp (http://basecamphq.com)

Bugzilla (http://bugzilla.org)

Github (http://github.com)

Groove (http://office.microsoft.com/groove/)

SharePoint (http://www.microsoft.com/sharepoint/)

Traction (http://tractionsoftware.com)

Voting What

To make decisions, the members or stakeholders of a group need a way to give their opinions, and project leaders need to know which options have the most support from the participating community, as illustrated in Figure 1-5.

Figure 1-5. Polls are one way to gather directed input from collaborators.

This pattern is also known as “Polls” or “Surveys.”

Use when

Use this pattern to collect the opinion of a group of people around a topic (with facets).

This pattern works best when groups are large enough that only a core subgroup is doing most of the collaboration, to provide a voice to the less fully engaged members of the group.

Voting can be in an enterprise or workgroup context. It also can integrate equally well in a consumer context, in which a group of people freely associating with one another need ways to discern their preferences and make collective decisions.

How

Provide a form by which a group moderator or participant can suggest a question or topic to be voted on, and then facilitate a series of possible votes (anything from “yes” or “no” to a multiple-choice option).

Optionally, provide configuration choices governing such issues as how long the voting will remain open, whether users can change their vote, whether votes are anonymous or open, whether a person is restricted to vote for a single choice or can vote for more than one, or whether a ranking of choices is preferred, as demonstrated in Figure 1-6.

Figure 1-6. Yahoo! Groups makes it easy to create an instant poll and invite the members of the group to vote in it, including the ability to change their vote up to a deadline.Why

Voting and surveys provide a means of soliciting feedback about specific questions from a wider participating community.

Note that it’s possible for some users to game voting systems, especially if no fixed identity is required or authenticated before voting; voting can provide perverse incentives in much the way that a leaderboard can; and there are many competing voting algorithms out there, each with its own pros and cons.

Related patterns

Ratings (Stars or 1–5)

Reputation Influences Behavior

Thumbs Up/Down Ratings

Vote to Promote

As seen on

Evite (http://evite.com)

SurveyMonkey (http://surveymonkey.com)

Yahoo! Groups (http://groups.yahoo.com)

Collaborative Editing What

People like to be able to work together on documents, encyclopedias, and software codebases, as depicted in Figure 1-7.

Figure 1-7. With asynchronous editing, multiple people can work on the same document.Use when

Use this pattern when you want your members to be able to work together to curate their collective wisdom or document their shared knowledge.

How

• Provide a repository for hosting documents with version control. Give users a way to bring in additional collaborators with an invitation to participate, as in Figure 1-8.

  Figure 1-8. You can use the “Invite to Participate” pattern to invite collaborators to work together on a document.

• Provide an Edit This Page link (see Edit This Page) directly on the document to be edited, or give users the means to upload incrementally updated versions of a stored document.

• For direct editing, provide an edit box, similar to a blog or comment interface, such as that shown in Figure 1-9.

  Figure 1-9. It doesn’t get more meta than this: here I am editing this very pattern in the collaborative wiki where it lives outside of the book.

• Optionally, give contributors mechanisms for tracking changes, whether via notifications or with RSS feeds.

Why

Collaborative editing is better suited to the online (web or cloud) contexts than the alternative: sending documents via email to multiple participants and then orchestrating the proliferating multiple, asynchronous updated copies of a document, with aspirational filenames ending in “finalFinalfinal,” as painfully demonstrated in Figure 1-10.

Figure 1-10. Collaborative editing does away with multiple copies of files, unreconciled changes, and email overload.Related patterns

Comments

As seen on

Drupal (http://drupal.org/handbook/modules/book)

Google Docs (http://docs.google.com)

Mediawiki (http://mediawiki.org)

SocialText (http://socialtext.com)

SubEthaEdit (http://www.codingmonkeys.de/subethaedit/)

Twiki (http://www.twiki.org)

Wikipedia (http://wikipedia.org)

Writeboard (http://writeboard.com)

Numerous FAQ documents that accompany active Usenet newsgroups

Suggestions

Also known as suggested edits, proposed changes, tracked changes, or “track changes,” or pull request.

What

People like to be able to ask for help with a document without always wanting to give direct editing control over the content itself. Other people feel more comfortable proposing changes and allowing the owner of document to accept or reject the changes, as shown in Figure 1-11.

Figure 1-11. Medium enables readers (and invited reviewers prepublication) to add comments in the margin of any paragraph, which remain unpublished until the author has a chance to review and either make the comment public or delete it.

This same model applies outside of documents as well—for example, when a Git user makes a pull request, proposing that a change be added to the core.

Use when

Use this pattern when more fine-grained control over editing permissions or review flow will help people be more productive.

How

Define a role or a mode in which edits or comments are not accepted or made public automatically but are instead left in a pending state for review by the document owner, who can choose to accept or implement the suggestion, or reject or ignore it.

There are two forms of this pattern, which can be used individually or mixed together:

• Pending edits (as with the Track Changes feature in Microsoft Word or the suggestion feature offered by Google Docs), in which a proposed edit is entered directly into the document and then either implemented or rejected.

• Pending comments (as with Medium), in which a suggestion is made in the context around the document and not directly in the form of its content. The suggestion is then either made public or left hidden or removed.

Why

A layer of pending or proposed changes around a document makes room for discussion and deliberation and gives the owner of the document clarity about the final result.

As seen on

• Medium

• Google Docs

• Git

Edit This Page What

The more difficult it is to edit a shared document, the fewer will be the number of people who will bother to do so. Even forcing people to switch contexts (to an “editing mode”) will create a barrier to participation for a significant fraction of potential contributors (see Figure 1-12).

Figure 1-12. A button or link inviting the reader to edit this page encourages collaboration (and lowers the threshold for making improvements by reducing the friction involved in offering edits).

This pattern is also known as “Edit This, “Universal Edit Button,” “Inline Editing,” “Read-Write Web,” or “Two-Way Web.”

Use when

Use this pattern in interfaces for editing shared or personal documents. You can use this for contexts in which universal editing, anonymous editing, or registered, authenticated, and privileged editing is permitted.

How

• Provide a button or link on any editable content that links directly to an edit box for the content, preferably without even loading a new page, as illustrated in Figure 1-13.

  Figure 1-13. If you can display an edit box directly in the reader’s original context, the experience of making and saving an edit and then resuming reading is smoother than if the editing must be done in a separate context.

• Optionally, when restricting editing only to privileged groups, hide the button from anyone who has not been authenticated as a contributor.

• Consider providing a WYSIWYG editing environment. This will reduce one of the barriers to participation for the majority of people who are not comfortable using abbreviated markup languages to format and style text.

Special cases

When trying to cultivate a culture of collaborative editing, community moderators might need to make an extra effort to recruit, campaign, and encourage contributions. By default, many people are passive, even when invited to edit content, because they are afraid to break something or give offense to a preceding editor. The interface should be as inviting as possible, but be prepared to challenge incumbent behavioral patterns.

Offer a “sandbox” area for beginners (see Figure 1-14), in which they can practice editing safely without worrying about damaging anything or exposing themselves to criticism.

Figure 1-14. Giving your collaborators a sandbox in which to practice their editing skills can ease the slope of the learning curve and take some of the fear out of inline editing.Why

The great promise of the Web draws in part from its facilitation of two-way communication and collaboration across geographical and other boundaries. An interface element that invites the reader to become an author goes beyond the “second-class” forms of participation, such as giving feedback and ratings. The easier you make it to edit content, the more likely people will take the time to do so, and potentially spur one another on to build knowledge stores and other projects that otherwise might never have come into being.

As seen on

Wikipedia (http://www.wikipedia.org)

Just about every wiki, everywhere

The Wiki Way What

Collaborative editing can become bogged down in conversational mode. Moreover, when contributors become too attached to their own individual contributions, this can impede the development of the collaborative document (see Figure 1-15).

Figure 1-15. Many of the principles underpinning Ward Cunningham’s original wiki (created to house the Portland Pattern Repository) should be kept in mind when you’re trying to facilitate effective collaborative editing in a community setting.Use when

Use this pattern when providing an interface for collaborative editing.

How

Encourage anonymous editing, use version control, and enable refactoring of document content by contributors.

Here are the original principles Ward Cunningham cited when recalling the design principles that underpinned the first wiki:

Open

Should a page be found to be incomplete or poorly organized, any reader can edit it as he sees fit.

Incremental

Pages can cite other pages, including pages that have not been written yet.

Organic

The structure and text content of the product are open to editing and evolution.

Mundane

A small number of (irregular) text conventions will provide access to the most useful page markup.

Universal

The mechanisms of editing and organizing are the same as those of writing; thus, any writer is automatically an editor and organizer.

Overt

The formatted (and printed) output will suggest the input required to reproduce it.

Unified

Page names will be drawn from a flat space so that no additional context is required to interpret them.

Precise

Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.

Tolerant

Interpretable (even if undesirable) behavior is preferred to error messages.

Observable

Activity within the product can be watched and reviewed by any other visitor.

Convergent

Duplication can be discouraged or removed by finding and citing similar or related content.

There are many wiki authors and implementers. Here are some additional principles that guide them, but were not of primary concern to me:

Trust

This is the most important thing in a wiki. Trust the people, trust the process, foster trust-building. Everyone controls and checks the content. Wiki relies on the assumption that most readers have good intentions (but assume that there are limitations to good faith).

Fun

Everybody can contribute, but nobody has to.

Sharing

The dissemination of information, knowledge, experience, ideas, views, and so on is paramount.

Why

The wiki approach has unleashed a torrent of creativity on the Web and seems to have captured in its principles the fundamental grain of digital, electronic, web-enabled collaboration.

Related patterns

Learn from Games

Passive Sharing

Chapter 17: Corporations Are People, My Friend

As seen on

WikiWikiWeb (http://c2.com/cgi/wiki)

Crowdsourcing What

Some jobs are too big for the immediate group of engaged collaborators to manage on by itself. The community will benefit if the interface provides a way to break a large project into smaller pieces and engage and give incentives to a wider group of people (or “crowd”) to tackle those smaller pieces, as shown in Figure 1-16.

Figure 1-16. Amazon’s Mechanical Turk plays matchmaker to people looking for distributed help in solving problems or answering questions, and other people willing to do work such as this for a fee.Use when

Use this pattern when you want your active core community members to engage with the wider set of people participating in your social environment and get their help accomplishing ambitious projects that would not be possible with fewer people.

How

• Provide a method for splitting up a project into individual tasks so that each task can be advertised individually. Also, provide a venue for announcing crowdsourced projects.

• Give community members a way to “shop for,” review, and claim individual tasks for the project.

• Provide an upload interface or submission form with which participants can contribute their completed work (assuming the work isn’t accomplished directly in your interface).

• Keep track of tasks that have been claimed but not completed by their deadline so that they can be returned to the general pool and reassigned.

• Ideally, offer a dashboard view for management of the project.

• Where appropriate, incorporate a mechanism for compensation for the participants.

Why

Crowdsourcing breaks large jobs into pieces that can be tackled with a much lower commitment threshold, taking advantage of the loose ties in social networks.

As seen on

Amazon Mechanical Turk (http://www.mturk.com/mturk/welcome)

Assignment Zero (http://zero.newassignment.net/)

The ESP Game (http://www.cs.cmu.edu/~biglou/ESP.pdf)

iStockphoto (http://istockphoto.com)

ReCAPTCHA (http://recaptcha.net/)

SETI@home (http://setiathome.ssl.berkeley.edu/)

Threadless (http://threadless.com)

Further Reading

1. “Berners-Lee on the read/write web.” BBC News, August 9, 2005. http://bbc.in/1gnkIGQ

2. Cross Cultural Collaboration. http://bit.ly/1gnkQWS

3. Marjanovic, Olivera, Hala Skaf-Molli, Pascal Molli, and Claude Godart. “Deriving Process-driven Collaborative Editing Pattern from Collaborative Learning Flow Patterns.” http://www.ifets.info/journals/10_1/12.pdf

4. Winer, Dave. Edit This Page. http://bit.ly/1gnlJ1F

5. Edit This Page PHP. http://bit.ly/1gnlO5F

6. Paylancers blog. http://paylancers.blogspot.com/

7. The Power of Many. http://thepowerofmany.com

8. Regulating Prominence: A Design Pattern for Co-Located Collaboration. http://bit.ly/1gnlQub

9. Howe, Jeff. “The Rise of Crowdsourcing.” Wired, 14.06. http://wrd.cm/1I2vKdB

10. Venners, Bill. “The Simplest Thing That Could Possibly Work.” http://www.artima.com/intv/simplest.html

11. Universal Edit Button. http://bit.ly/1I2vM5c

12. Wiki Design Principles. http://bit.ly/1I2vMlN

13. Udell, Jon The Wiki Way. http://bit.ly/1N4lsuI

14. Wired Crowdsourcing blog. http://crowdsourcing.typepad.com

Continue reading Design patterns for orchestrating collaborative groups.

Visualizing Toxicity, Rubrics, Mozilla Fellows, and Open Source

1. Visualizing Toxicity in Twitter Conversations -- The project started with an initial design discussion in which we all agreed it would be cool to somehow visualize Twitter conversations as natural-looking trees, where replies form branches and the more toxic the reply, the more withered the branch would look. At this point, I had no idea how I’d even approach rendering a withered tree, but it sounded like a fun experiment, so I said I’d look into it and do my best.
2. Rubrics for Engineering Role -- I love rubrics and ladders, and this combination would make me very happy.
3. Mozilla's New Openness, Science, and Tech Policy Fellows -- interesting mix of projects and people.
4. The Commons Clause Will Destroy Open Source -- the Commons Clause doesn’t present a solution for supporting open source software. It presents a framework for turning open source software into proprietary software. My take: open source is most valuable when it's free. Limiting freedom (including freedom to sell) limits the usefulness of the software. Create more value than you capture!

Continue reading Four short links: 23 August 2018.

Software Licenses, Crowdsourced Laws, USB Power Over Ethernet, and ML Fairness

1. Commons Clause -- a condition added to existing open source software licenses to create a new, combined software license.
2. vTaiwan (MIT TR) -- the simple but ingenious system Taiwan uses to crowdsource its laws.
3. Power USB Devices Over Ethernet -- cute!
4. Fairness Without Demographics (Paper a Day) -- After showing that representation disparity and disparity amplification are serious issues with the current status quo, the authors go on to introduce a method based on distributionally robust optimization (DRO) which can can control the worst-case risk.

Continue reading Four short links: 22 August 2018.

Why hiring a team diverse in perspective and background leads to a great culture.

Continue reading Great products begin with great cultures.

A conversation with Paul Taylor, chief architect in Watson Data and AI, and IBM fellow.

Machine learning researchers often prototype new ideas using Jupyter, Scala, or R Studio notebooks, which is a great way for individuals to experiment and share their results. But in an enterprise setting, individuals cannot work in isolation—many developers, perhaps from different departments, need to collaborate on projects simultaneously, and securely. I recently spoke with IBM’s Paul Taylor to find out how IBM Watson Studio is scaling machine learning to enterprise-level, collaborative projects.

First, a bit of background about Taylor. He has enjoyed a distinguished career at IBM over the past 17 years, where he started off working on Db2 and Informix, and working with big data and unstructured data well before those fields exploded. He has held many titles working in different technology areas as a distinguished engineer, chief architect, master inventor, CTO, and this year was appointed as an IBM Fellow.

Today, Taylor leads the technology of IBM Watson data and AI components, where he is exploring the convergence of data, AI, and public cloud with IBM Watson Studio. Watson Studio provides a suite of tools for data scientists, application developers, and subject matter experts to collaborate and work with data to conduct analytics and data science, and to build, train, and deploy models at scale.

Frank Kane: Why is better collaboration in data science important? What sorts of opportunities do you see it creating for real-world developers and businesses?

Paul Taylor: A lot of times I go in to talk to C-suite folks who are running the data science teams. They're in a real challenge because, traditionally, many of those clients and the scientists are using their own little tools, and they may be very sophisticated tools, or they may be very naïve ones. They're all working in silos, and they're using their own tools in their own way.

A lot of times what I've seen is that these enterprises are really trying to figure out how to consolidate that a little bit because it's really hard for those teams to work together and share the same data. That's the beauty of Watson Studio. You can have these different teams, even if they use different technologies. Some people want to just program themselves, and they're going to use notebooks and they're going to use some custom libraries they get from some place.

Other people know the data science algorithms and statistics and so forth, but they're not really hard-core programmers. A lot of times those individuals want to work together as part of a team for a specific project. These companies, until we showed up, were thinking they were going to have to procure several different tools that would live in isolation and be used by different groups.

They actually got really excited by this notion of, "Wow, if we could actually bring these communities together, still knowing that they can use the special technologies they prefer, but not have to then copy the data, to be able to see each other's work, and see the comments, and be able to annotate it and collaborate on it, and maybe invite other people into their projects. And do that in a secure way and a very easy way."

I think that's what really opens people's eyes, particularly in an enterprise setting or place where collaboration really needs to happen. Not only the collaboration, but how do these companies learn from their expertise? By having the notion of projects and being able to have different people working on the projects, that sort of shared tribal knowledge starts to get consolidated in a common set of tools and practices.

FK: I've seen people try to just put a Jupyter Notebook, like an .ipynb file, on GitHub somewhere and call it collaboration. Obviously that is fraught with problems.

PT: Yes, that's exactly it. We're not saying don't put those things in certain places, but we're saying that if you can put it in the context of Watson Studio, then you have all of that other ecosystem around it, which lets you share with different users and different people. You can also control the security around that through these access control lists of who has access and what role [they have] within the project.

FK: Right. So it sounds like Jupyter Notebooks are just one of the things you can share across teams in Watson Studio. Are there more systems that surround those notebooks?

PT: That's a really great question because anybody who's used notebooks themselves realizes there are still opportunities. When you give a notebook to somebody else, it doesn't mean that you can actually capture all the interaction that you want between two people who are collaborating.

At the same time, you don't customize the notebook so much that it's no longer the same thing they picked up out of open source and it becomes too dissimilar. So, one of the key things we tried to do was use the open source and preserve the integrity of that, but then put some framing around it.

You can have comments, and everybody can comment because it's in the context of a project. You can put security around the project itself—who gets added, who's allowed to access it, that kind of thing.

And then, of course, inside the project you have the framing of “Where is the data coming from?” So you can control more of the environment if you like through Watson Studio, which is above and beyond what you can do in a Jupyter Notebook, but at the same time you're preserving the integrity of what people expect out of a Jupyter Notebook and having it run in a way that's consistent with that.

FK: Are there any specific organizational challenges involved in having different teams collaborating on the same notebook or project within Watson Studio?

PT: The traditional issue that crops up anytime you're dealing with very sensitive enterprise data is that people want to know how it is managed. If you have sensitive data in there, where is it and how would you know that, and how are you managing that?

So you get into those kinds of questions. I think this starts with the security of the collaborators, their identities, groups, and roles. For example, in a Jupyter Notebook, you can certainly write code that exposes credentials, for example, which is another type of risk when dealing with enterprise data.

We're introducing capabilities to minimize that, so that those credentials can be shielded from people. That minimizes the threat of other accidental exposure, of exposing credentials that somebody could then use in a way that wasn't intended.

FK: Do you find this broader sharing makes the technology more accessible to a large organization and spreads a deeper understanding of what's going on internally?

PT: Yes, definitely. You can do a lot more. I think that's what people like in the notebooks—you can put comments in and images and other things, so they can be really expressive.

We've even had, inside a project, links to what you'd call a community—where samples are, where there are tutorials, and so forth. That really helps build teams as well, right? You may have somebody who's a really good data scientist, but there are junior members or interns on the project. Sometimes they need some help.

You can link to those sources directly inside the project, and say, "Here's a tutorial on how to connect to a Spark system." Or, "Here's a tutorial on how to use this type of an algorithm." You can put that right in the project.

FK: I imagine just having the entire organization on a single, unified platform has a lot of advantages, too. You don't have to worry about what version of notebooks you're using and nonsense like that, right?

PT: Yes, absolutely. And the fact that it's on the cloud means we're delivering changes—pretty much every day in some cases—into that system. That's the whole agility aspect of the cloud and a fully managed service, which is really powerful because they keep getting more capabilities and we can see what people are doing and what they're asking for. Even inside the tooling itself you can ask for help.

If you think back a few years ago, it was unheard of to have software updates applied continuously every day without any downtime and not have to involve a lot of IT skills to keep it all running and current. This notion of self service is really huge. You're able to create a project yourself. You don’t have to ask somebody's permission for that. You can start to do things that you previously had to go through various approvals to procure. I think that's another major theme when you start to couple open source technologies, but put in a cloud context, so now you can provision and also put in a context where everybody can access it.

There are other interesting use cases where you're working with partners. You need to work across organizations at that point. Having Watson Studio in the cloud makes it easier to do that type of collaboration with projects and catalogs, where you've got these hand-offs between different organizations.

FK: Being in the cloud makes it much more scalable as well. You don't have to worry about somebody's notebook server on their desktop not being up and things like that.

PT: Yes, it's actually a lot of the operational aspects, right? Not having to worry about the project being available, online, reliable. Ensuring all the latest security and updates are in place, having all the various industry compliance certifications, backups, monitoring, etc.

Not just the elasticity, but is it being kept up? As you mentioned earlier, how are the upgrades happening? All those kinds of things they don't have to worry about anymore.

FK: I want to congratulate you on being named an IBM fellow this year. It’s a very exclusive club. Tell us what that means for someone outside of IBM.

PT: It's a big honor and responsibility. Essentially the role there and what it means is obviously a lot of deep technical expertise. It's really that combined with having proven delivery of products and technologies that have helped companies and helped enterprises really adopt the technology that is being worked on and actually deploying it.

Then the third part is around the technical mentoring and building teams, and all the teamwork that goes with it. So it's a combination of leadership, the technical expertise across many projects that I've done and the ones I'm currently engaged in, and then around actually having a real business impact.

It's for real impact across all of those dimensions, concurrently. That's what IBM fellows are all about, the combination of those three things and applying them broadly. Not just inside the company, but across the industry and across the ecosystem of partners and system integrators as well.

FK: Where does Watson Studio go from here?

PT: “Where does this go” is a natural question. We’ve got these really powerful tools. I think what you'll see more of us doing is taking this to the next level on production use and productive use for the enterprise, even beyond what we have. Our approach to enterprise includes an intelligent catalog that assists in finding and recommending relevant assets to use in a project, and applies active policy management on the assets so collaborators in a project automatically stay within enterprise policies. In addition, we have applied a lot of energy to three major themes: first, learning from “small data”—many enterprises don’t have as much data as some people imagine, particularly relative to the largest social media sites, yet the data they have is very valued. So we have developed techniques and strategies to quickly learn with less data, yet still retain high quality, and remove potential bias from that data. Second, being able to explain the reasoning behind the results, providing complete transparency and traceability. Third, being able to really scale the whole environment in an enterprise context. This tool is now really powerful, and people are asking us, "Okay, how do I really blow this out in my enterprise applications? How do I easily create these intelligent applications, AI-infused applications, into my key business processes with efficiency in all the languages, regions, and data centers I operate in?"

Part of that gets into more of the run time and operations side of the house. There are a lot of things coming that I think are very interesting here.

FK: It feels very much like day one again in the field of AI, and it's an exciting time to be in.

PT: I think it's really interesting because in the 80s, I realized that AI was very enticing, but it just simply wasn't practical. Now, it's turned around completely opposite. It's actually not practical to build applications without AI.

This post is a collaboration between O'Reilly and IBM. See our statement of editorial independence.

Continue reading Enabling reliable, secure collaboration on data science and machine learning projects.

Betting Market, Megaprojects, Object Detection, and Declining Research

1. Intro to Augur -- an open source, decentralized betting marketplace. Anyone can create markets and allow others to bet for or against it. The outcome is then verified by impartial observers who get a slice of the winnings. This can't possibly go wrong. (Narrator: everything will go wrong)
2. What You Should Know About Megaprojects -- the "iron law of megaprojects" is laid out and documented: over budget, over time, over and over again. Moreover, the "break-fix model" of megaproject management is introduced as an explanation of the iron law. [...] Sixth, it is shown how megaprojects are systematically subject to "survival of the unfittest," explaining why the worst projects get built instead of the best. (via Dan Hon)
3. Toward In-baggage Suspicious Object Detection Using Commodity WiFi -- Extensive experiments are conducted with 15 metal and liquid objects and six types of bags in a six-month period. The results show that our system can detect over 95% of suspicious objects in different types of bags and successfully identify 90% of dangerous material types. In addition, our system can achieve the average errors of 16ml and 0.5cm when estimating the volume of liquid and shape (i.e., width and height) of metal objects, respectively.
4. Winner's Curse -- we observe that the rate of empirical advancement may not have been matched by consistent increase in the level of empirical rigor across the field [of ML] as a whole. This short position paper highlights examples where progress has actually been slowed as a result, offers thoughts on incentive structures currently at play, and gives suggestions as seeds for discussions on productive change.

Continue reading Four short links: 21 August 2018.

Skepticism, Aphorisms, Acceptance, and Back to Blogging

1. Keynote Speakers Make Bad Life Decisions and Are Poor Role Models (James Mickens) -- I feel like, as computer scientists, we have forgotten the value of skepticism. Entertaining and on-point keynote at Usenix Security Symposium.
2. My Favorite Sayings -- John Ousterhout's collection. My favorite of his favorites: Use your intuition to ask questions, not to answer them. Let that one sit for a while.
3. Staking Your Self-Worth on Social Acceptance -- people who believed they needed to be socially accepted in order to have worth as a person were at higher risk of using Facebook in compulsive and maladaptive way. [...] An initial survey of 337 participants with an active Facebook account found that social acceptance contingencies were positively related to Facebook addiction symptoms.
4. Social Media (Simon Willison) -- How about if, instead of ditching Twitter for Mastodon, we all start blogging and subscribing to each other's Atom feeds again instead? The original distributed social network could still work pretty well if we actually start using it.

Continue reading Four short links: 20 August 2018.

Chatbots are just the first step in the journey to achieve true AI assistants and autonomous organizations.

TL;DR: Chatbots are the first step toward autonomous organizations: companies whose operations are largely run by many different AI assistants. Analogous to autonomous cars, there are five levels of sophistication for AI assistants. Currently, basic level two AI assistants are mainstream, and Google just showed the world what a level three assistant looks like. Achieving true level five capabilities for AI assistants will result in a significant shift for society, with many implications for businesses and their customers.

The recent backlash about chatbots is both absolutely correct and completely misses the point. Yes, most chatbots we’ve seen since F8 2016 are bad. Most have failed to add value to the end user when compared to existing websites or apps.

However, chatbots are not the end game. We know from working with Fortune 500 companies there are powerful examples showing that state of the art chatbots can work and actually do help companies generate additional revenue or save costs. Our mission is to work toward true AI assistants that make it possible for customers to express what they want, in their own terms, without a human on the other end.

AI assistants can be applied both for direct customer service and within the operations of an organization. AI that understands customers, context, and that can be proactive will lead to automation of many repetitive tasks.

Five levels of AI assistants: From notification assistants to autonomous organizations Figure 1. There are five levels of AI assistants—from dumb to super smart. Currently, level two is mainstream. Image by Alan Nichol.

Much has been written about the five levels of autonomous driving. Based on the chatbots and assistants that have been built in the last years, we see five levels of AI assistant intelligence emerging:

• Level 1: Notification Assistants—This is what we know; simple notifications on your phone, but they show up in a messaging app like WhatsApp instead.
• Level 2: FAQ Assistants—By far the most common type of assistants at the moment, allows the user to ask a simple question and get a response, which is a slight improvement from commonly known FAQ pages with a search bar. The only difference is that it is sometimes enhanced with one to two follow up questions.
• Level 3: Contextual Assistants—As most bot developers could tell you, giving end users a box to type in rarely ends up being just a simple question and answer. That’s why context matters: what the user has said before, when / where / how she said it, and so on. Considering context also means being capable of understanding and responding to different and unexpected inputs.
• Level 4: Personalized Assistants—As you might expect from a human that gets to know you over time, AI assistants will start to do the same. For example, an AI assistant will learn when it’s a good time to get in touch and proactively reach out based on this context. It will remember your preferences and give you the ultimate, personalized interface.
• Level 5: Autonomous Organization of Assistants—Eventually, there will be a group of AI assistants that know every customer personally and eventually run large parts of company operations—from lead generation over marketing, sales, HR, or finance. This is a major leap forward that will take many years, but this is a vision we see as reality.

FAQ assistants are mainstream and mostly feel dumb

We see most assistants at level two at the moment, with the majority of our open source community actively seeking and working toward expanding their AI assistant capabilities into near-level three and beyond. The key is context. Without context, many use cases don’t work.

For example, recently we learned that merely 2% of the consumers who own the 50 million Alexa-enabled devices have used the voice assistant to make a purchase. Buying something via a conversation involves a lot of context and, thus, gets complex very quickly. It’s clear this is not yet satisfactory when compared to the rich context of browsers and apps

Level three is on the horizon. The closest we’ve seen so far is Google Duplex, which showed what a level three assistant could look like with a specific use case in a specific context, and the world has been impressed. However, Google put a lot of brainpower into making it work for just one use case, and we know that adding additional ones takes a lot of more. That’s why these near-level three assistants are currently niche products. The current approach doesn’t scale.

Taking contextual assistants mainstream: AI that can generalize

Let's look at how humans understand context and expand to new “use cases.” For example, if we train a salesperson to sell car insurance, we would consider that person to be “intelligent” if they can use those newly acquired skills to sell another type of insurance, such as home insurance. Humans are able to generalize and apply understanding across different references and contexts.

AI assistants should actually be able to achieve the same result even if not specifically trained. Otherwise, they’re not scalable. So what does this imply to reach level three? Generalization here means that an assistant can handle conversations about new (similar) use cases without explicitly pre-programming every rule for all possible edge cases explicitly in advance.

Figure 2. Both examples show “uncooperative” behaviour from the user as they deviate from the happy path with the same question—”How is the weather there”—but in a different context. Level three AI assistants should be able to re-use the knowledge they learned in Example 1 and apply it to Example 2. Image by Alan Nichol.

This analogy shows how smarter assistants are developed faster with fewer resources and training data. At Rasa, we’re working on solving this exact problem, aiming to make this technology available to all makers so that level three assistants go mainstream.

The path to autonomous organizations

A question we get a lot from executives is: “will there be one killer bot for everything?” For us, the answer is no because you also don’t have one employee who does everything in your company. There are teams, there are departments, there are subsidiaries, and I don’t think AI will allow us to completely get rid of that structure. Structure is actually a key to efficiency.

What we do believe is that teams, departments, and full organizations can be replaced by a group of AI assistants and leave a handful of humans to do interesting work. Shai Wininger, the founder and CEO of Lemonade, calls this the “autonomous organization.”

This will lead to true level five capabilities for AI assistants and to a significant shift for society, with many implications for businesses and their customers. Leadership who can see this future and understand its importance—and ensure that intelligence isn’t outsourced in return for short-term profit—will be crucial for success.

Related content:

• “Bots: What you need to know”
• “Using machine learning to monitor and optimize chatbots”
• "Commercial speech recognition systems in the age of big data and deep learning": Yishay Carmiel on applications of deep learning in text and speech
• “Deep learning revolutionizes conversational AI”
• "Topic models—past, present, and future": David Blei discusses the origins and applications of topic models.
• “Natural language analysis using Hierarchical Temporal Memory”

Continue reading The next generation of AI assistants in enterprise.