Feed aggregator

We had already decided to cancel meetings for the rest of the month when we were informed that the room was going to be off limits until May because to the risk of public gatherings due to COVID-19.  That's a little longer that we had discussed cancelling things, but it's better to be safe than sorry, so until May there will be no meetings unless things change.

We will be back in May with some really good presentations that we already had lined up.

See you at the next meeting.   Stay healthy.

This month we'll be treated to PLUG's second Space themed night.

Space Night 2

Description:
Join PLUG for a space panel featuring members of the MASTCAM-Z team discussing the roles of Free Software and open standards in their projects and the open science they're investigating as part of their missions.

Based at ASU, the panel members have worked on projects such as the MASTCAM-Z and MASTCAM projects for Mars rovers, Lunar Reconnaissance Orbiter and the Psyche Mission.
av
Video from previous Space Night panel:

https://www.youtube.com/watch?v=bnxge96YO3A

Panelists:

Ernest Cisneros

Ernest received a Bachelor's of Science in Geology, from the University of Texas at El Paso (1989). After a stint in graduate school at Northern Arizona University, studying the metamorphic history of the Old Woman Mountains, he began a 27 year career combining his love of geology and computers. Ernest has worked at the USGS in Flagstaff, Duke University, Northwestern University and most recently at Arizona State University. Ernest has supported science and data processing for Clementine, MSI on NEAR, CRISM on MRO, MDIS on MESSENGER, Pancam on MER. His most recent work was developing the Science Operations Center for the Lunar Reconnaissance Orbiter, supporting multispectral data processing of MASTCAM images from MSL, developing the ground data system for MASTCAM-Z instrument on the Mars 2020 rover, and developing the Science Data Center for the Psyche Mission. During his career, Ernest has seen Linux grow from "just something we are playing with for SysAdmin stuff" into a mainstay in server rooms, desktops and at home, tackling a wide-variety of roles. He has used a variety of Linux flavors: Slackware (installed from floppies), Redhat, Debian, CentOS, SuSE, and Ubuntu (most recently), installed on everything from SBC (Raspberry Pi and Tinkerboards), Intel/AMD PC's, PowerPC, RISC and a variety of other architectures.

Kristen Paris

Kristen is the Down-link Operations Lead for the Mastcam-Z camera for the Mars2020 rover mission and previously worked with the Lunar Reconnaissance Orbiter Camera also at ASU. Kristen has been using Linux-based systems for NASA Instrument Operations for over 10 years. Usually she uses her Linux-y powers for good, but sometimes her powers have other (unintended) consequences. Kristen automated myself out of a job and enjoyed it! She has also brought a 200+node computing cluster to a screeching halt (know if 3rd-party software is secretly trying to be "helpful" and know how to disable these "helpful" features). Kristen loves Space, enjoys computers (when they do what she intends for them to do), and considers herself a Danger Linux Power User.

Corrine Rojas

Corrine is a NASA Mars 2020 Rover Mastcam-Z Instrument Operations Engineer based at Arizona State University (ASU). She is a science team collaborator for the Mars Science Laboratory, formerly at the Lunar Reconnaissance Orbiter Camera. Her specialty is spacecraft operations (orbiters and rovers), research in planetary geology, and creating all kinds of maps, particularly 3D terrain maps that are out of this world. She has a BSc in Geography and Geographic Information Science from ASU. She was born and raised in Phoenix, AZ to loving immigrant parents from Durango, Mexico. In college, she was a Shirley G. Schmitz Foundation Scholar for entrepreneurs; participated in an ASU-funded start-up DemocraSeed in which she mentored high school-aged kids in a rural AZ town about creative problem solving issues in their community using design thinking; and interned at Jet Propulsion Laboratory for the Curiosity rover mission operations team. She is currently on the board of the Society of Women in Space Exploration, and on the leadership council of Latinas in Earth and Planetary Sciences (Geolatinas). She does not consider herself a technical computer science person, though she is slowly coming to terms that her job is 80% bash scripting to manipulate a ton of data, and you kinda have to have a good idea of what you’re doing in order to spare your perfectly obedient hardware from being smashed by a 2x4.

Nathan Cluff

Nathan is the Lead Systems Administrator for the Mastcam and Mastcam-Z cameras on the Mars Science Laboratory and Mars 2020 rovers in addition to supporting operations for various other missions such as the Luna Polar Hydrogen Mapper (LunaH-map) mission. Nathan has been involved in various Linux administrative positions for the last 18 years and has been in the School of Earth and Space Exploration at ASU for the last 4 years.

Freeman Dyson died last week at the age of 96 after injuring himself in a fall in the cafeteria at the Institute of Advanced Studies in Princeton, where he had continued to work right up to the end. I can’t resist adding to the outpouring of appreciation and love that has ensued. He has an outsized place in my mind and in my heart for someone whom I met in person fewer than a half-dozen times.

When I interviewed Freeman on stage at OSCON in 2004, along with his son George, the subject strayed to digital preservation. I lamented how much would be lost due to incompatible standards for information storage, and he said, “Oh no, forgetting is so important! It is what gives room for new ideas to come in.” This was such a typical Freeman moment: bringing a profoundly fresh perspective to any discussion. Perhaps the most famous example is the paper he wrote in 1949 at the age of 25 making the case that the visualizations of Richard Feynman were mathematically equivalent to the calculations of the more conventional physicists Julian Schwinger and Shin’ichirō Tomonaga, a paper that led to Feynman, Schwinger, and Tomonaga receiving the 1965 Nobel Prize in Physics for the theory of quantum electrodynamics.

This talent Freeman had for seeing to the heart of things was apparent even earlier, when he was working as a statistician in the operations research section of the Royal Air Force Bomber Command during World War II. As recounted in the first of his numerous volumes of autobiography, Disturbing the Universe, he had been asked to study the pattern of bullet holes on the bombers returning to Britain from their forays overseas with an eye to reinforcing the areas with the most anti-aircraft damage. No, no, Freeman argued, reinforcement may be more effective in areas that show little damage in returning planes, because hits to the most vital regions will have caused the planes to be lost! The essential information was to be found in what was missing.

After George sent an email to a group of friends about Freeman’s death, Danny Hillis replied with a story that seems to perfectly encapsulate this gift of Freeman’s for seeing things that others missed. “I visited him recently,” Danny wrote, “and we got into a conversation about self-organizing systems. After lunch we climbed up the long stairs to his office, and when we sat down he seemed a bit distracted. I asked him what was wrong. Well, he said, what seemed wrong was that self-gravitating systems have negative specific heat capacity. The thing to do, he said, was to figure out why that was right.” When the world doesn’t quite make sense, don’t brush the offending observations under the rug. Think harder.

My earliest memory of Freeman, from well before I met him, echoes the distracted air that Danny noticed. In Kenneth Brower’s book The Starship and the Canoe, about Freeman’s work on Project Orion and George’s work reconstructing early native American canoes in the Pacific Northwest, there was an account of the way Freeman would go so deep inside that he wouldn’t notice anyone around him—his interior world of thought was too vivid—and how sometimes, he would even break off in the middle of a conversation. Rude? No, he explained (as I recall it). Would someone think it rude if there were the sound of a car accident outside, and you broke off conversation to run to the window? Sometimes thoughts too are so compelling that you must immediately take notice. For those of us who are cursed (or gifted) with the experience that our interior world is sometimes more real than the outside, demanding all our concentration, this was a heady acknowledgement.

Another moment that I treasure was a fragment of an overheard conversation at the first Science Foo Camp in 2004. He and another physicist were discussing Michael Crichton’s novel Prey, in which the monster du jour was a swarm of nanoparticles. He said something like: isn’t it ridiculous how the nanoparticles are chasing people? Anyone knows that a particle moving in a viscous medium such as air moves at a velocity proportional to its length. (Or some such; I believe he offhandedly referenced a particular formula, which I don’t recall.) I was immediately struck by how differently the world appears to someone so deeply mathematical. We see the world through the lens of our received ideas, but for most of us, words predominate. Freeman had a gift for seeing with both words and numbers, and for throwing both away when needed, to see the world afresh.

Forgetting may be important, but so is remembering and honoring. Freeman was good at that, too. One of my favorite pieces of his writing is his foreword to a collection of Richard Feynman’s essays, The Pleasure of Finding Things Out. It is so good that over the years, I’ve managed to get only about halfway through the book, since each time I pick it up, I first re-read Freeman’s foreword. His account of how he came to write his seminal paper on quantum electrodynamics is the most glorious appreciation of another human being that I have ever read, and shows Freeman at his best: curious, deep, original, humble, kind, thoughtful, and remarkably literary. You can read about Freeman’s life and career in one of the many obituaries, like the one in the New York Times last week, but if you want to experience the man himself, you still can, through the many books and articles he left behind. This is as good a place as any to start:

“I did love the man this side idolatry as much as any,” wrote Elizabethan dramatist Ben Jonson. “The man” was Jonson’s friend and mentor, William Shakespeare. Jonson and Shakespeare were both successful playwrights. Jonson was learned and scholarly, Shakespeare was slapdash and a genius. There was no jealousy between them. Shakespeare was nine years older, already filling the London stage with masterpieces before Jonson began to write. Shakespeare was, as Jonson said, “honest and of an open and free nature,” and gave his young friend practical help as well as encouragement. The most important help that Shakespeare gave was to act one of the leading roles in Jonson’s first play, “Every Man in His Humour,” when it was performed in 1598. The play was a resounding success and launched Jonson’s professional career. Jonson was then aged 25, Shakespeare 34. After 1598, Jonson continued to write poems and plays, and many of his plays were performed by Shakespeare’s company. Jonson became famous in his own right as a poet and scholar, and at the end of his life he was honored with burial in Westminster Abbey. But he never forgot his debt to his old friend. When Shakespeare died, Jonson wrote a poem, “To the Memory of My Beloved Master, William Shakespeare,” containing the well-known lines: “He was not of an age, but for all time.” …

What have Jonson and Shakespeare to do with Richard Feynman? Simply this. I can say as Jonson said, “I did love this man this side idolatry as much as any.” Fate gave me the tremendous luck to have Feynman as a mentor. I was the learned and scholarly student who came from England to Cornell University in 1947 and was immediately entranced by the slapdash genius of Feynman. With the arrogance of youth, I decided that I could play Jonson to Feynman’s Shakespeare. I had not expected to meet Shakespeare on American soil, but I had no difficulty in recognizing him when I saw him.

Before I met Feynman, I had published a number of mathematical papers, full of clever tricks but totally lacking in importance. When I met Feynman, I knew at once that I had entered another world. He was not interested in publishing pretty papers. He was struggling, more intensely than I had ever seen anyone struggle, to understand the workings of nature by rebuilding physics from the bottom up….I seized every opportunity to listen to Feynman talk, to learn to swim in the deluge of his ideas. He loved to talk, and he welcomed me as a listener. So we became friends for life.

For a year I watched as Feynman perfected his way of describing nature with pictures and diagrams, until he had tied down the loose ends and removed the inconsistencies. Then he began to calculate numbers, using his diagrams as a guide. With astonishing speed he was able to calculate physical quantities that could be compared directly with experiment. The experiments agreed with his numbers. In the summer of 1948 we could see Jonson’s words coming true: “Nature herself was proud of his designs, and joyed to wear the dressing of his lines.” During the same year when I was walking and talking with Feynman, I was also studying the work of the physicists Schwinger and Tomonaga, who were following more conventional paths and arriving at similar results. Schwinger and Tomonaga had independently succeeded, using more laborious and complicated methods, in calculating the same quantities that Feynman could derive directly from his diagrams. Schwinger and Tomonaga did not rebuild physics. They took physics as they found it, and only introduced new mathematical methods to extract numbers from the physics. When it became clear that the results of their calculations agreed with Feynman, I knew that I had been given a unique opportunity to bring the three theories together…. My paper was published in the Physical Review in 1949, and launched my professional career as decisively as “Every Man in His Humour” launched Jonson’s. I was then, like Jonson, 25 years old. Feynman was 31, three years younger than Shakespeare had been in 1598. I was careful to treat my three protagonists with equal dignity and respect, but I knew in my heart that Feynman was the greatest of the three and that the main purpose of my paper was to make his revolutionary ideas accessible to physicists around the world. Feynman actively encouraged me to publish his ideas, and never once complained that I was stealing his thunder. He was the chief actor in my play.

Freeman undersells himself. He too was a genius. We will all miss him.

Freeman Dyson at his 90th birthday celebration at the Institute for Advanced Studies in 2013. I was honored to be invited but my photos were from a far greater distance. This photo was taken by George Dyson, and is used courtesy of the Dyson family.

1. tota11y — an [open source] accessibility visualization toolkit from Khan Academy.
2. DOS Pi — a DOS computer in a keyboard.
3. Simple Systems Have Less Downtime — Why? (1) Proficiency takes less time; (2) Troubleshooting takes less time; (3) More alternative solutions.
4. Cybersecurity Law, Policy, and Infrastructure — This is the full text of my interdisciplinary “eCasebook” designed from the ground up to reflect the intertwined nature of the legal and policy questions associated with cybersecurity. My aim is to help the reader understand the nature and functions of the various government and private-sector actors associated with cybersecurity in the United States, the policy goals they pursue, the issues and challenges they face, and the legal environment in which all of this takes place. It is designed to be accessible for beginners from any disciplinary background, yet useful to experienced audiences, too.

1. Facebook’s Incomplete Download Your Data (Privacy International) — Despite Facebook claim, “Download Your Information” doesn’t provide users with a list of all advertisers who uploaded a list with their personal data. As a user, this means you can’t exercise your rights under GDPR because you don’t know which companies have uploaded data to Facebook. Information provided about the advertisers is also very limited (just a name and no contact details), preventing users from effectively exercising their rights. Recently announced Off-Facebook feature comes with similar issues, giving little insight into how advertisers collect your personal data and how to prevent such data collection. (via Bruce Schneier)
2. Proxy Verifier — an HTTP replay tool designed to verify the behavior of HTTP proxies. It builds a verifier-client binary and a verifier-server binary which each read a set of YAML or JSON files that specify the HTTP traffic for the two to exchange. Open source from Yahoo.
3. Stripe’s Covid-19 Company Plan — great time to be a remote working consultant, although I’m sure nobody with entrenched on-site culture wants to hear what’s involved to enable long-term sustainable useful remote work (i.e., change your crappy practices that favor in-office staff, move comms to a slower channel for people who aren’t online all at once because they’re visiting the doctor, etc.).
4. Google’s Tech-Writing Course — This collection of courses and learning resources aims to improve your technical documentation. Learn how to plan and author technical documents.

I read an article on the death of Agile. It’s not the first article I’ve seen claiming that Agile is dead, and I’m sure it won’t be the last.

The problem with the claim that Agile is “dead” is that, as Eben Hewitt said to me in a conversation, “no movement has succeeded until it has become a parody of itself.” This is a brilliant point that applies perfectly to Agile. What is modern Agile? Fetishizing standups. Fetishizing pair programming. Fetishizing unit testing. Scrum fetishizes working in short, intense bursts. (In the 80s, I worked for a company that had a lot of practices that anticipated Scrum. All I can say is that they were extremely unhealthy. Buy me a beer and I may tell you more.) None of these are bad in and of themselves, but they all miss the point, particularly when they become a ritual. (Standup meetings that are over an hour long? Yep, been invited to those. Refused to attend after the first one.) More often than not, the result of fetishization is—nothing at all. A few existing practices are re-named, a few new rituals are created, and work goes on exactly as it did before—but now it’s “agile.” That kind of Agile needs to die. I won’t be among the mourners.

The one thing I don’t see, and the one thing that more than anything else captures the value in Agile, is the ongoing conversation between the customer (however that’s conceived) and the developer. This is important. Agile is not, and never was, about getting developers to write software faster. (Scrum might have been…) Agile is about getting developers in touch with the people who are the actual users and customers, regularly and repeatedly, so that the project doesn’t inevitably wander off course and produce something (in the words of Douglas Adams) “almost, but not quite, entirely unlike tea.”

I’m not an Agile fundamentalist, or even a serious Agile evangelist. But it’s worth some time thinking about the Agile Manifesto and what it means, maybe even meditating on it. If you were involved with professional programming in the 80s and 90s, you may remember how radical it was (and, in many shops, still is) to put software developers in touch with users and customers. Neckbeards? Geeks and nerds? They might tell the customer that some feature they want is impossible! They might tell the truth! Then what would sales do?

Well, it turns out if you want software to work, the developers have to talk to the people who need that software to work. You can’t leave that to sales people or marketers. You can’t create a “product owner” and say that’s their job—especially since, more often than not, “product owners” don’t have meaningful contact with customers themselves. (True story: at a former company, a salesperson made a major sale based on a feature that not only couldn’t possibly be implemented, it didn’t even make sense. We were very lucky not to be sued.) When a project is going off track because some requirement wasn’t understood properly, you need to fix that as soon as possible—not after a year-long development process. If Agile’s first principle is frequent interaction with the customer, its second (and a close corollary) is frequent mid-course corrections. Those mid-course corrections are always less painful than getting to the end and finding that you’ve built the wrong thing. And that’s a big clue about what the word “Agile” means. It’s not about getting software developers to write code faster. It’s about learning when you need to change direction, and then doing it. It’s about correcting small mistakes before they become big ones, before they’re amplified by a multi-year, multi-million dollar budget.

So I really don’t want to hear that Agile doesn’t work for large projects and so on. I don’t care what you call it, but large projects (a) are rarely successful, regardless of the methodology, because they (b) get overloaded with a lot of features that nobody needs but that sound good, and (c) forget what the customer or user really needs or wants. Large projects are necessary, but they have a momentum that tends to drive them off course. Once a project starts going in the wrong direction, it tends to keep going in the wrong direction. That was true before Agile (didn’t Isaac Newton say that?), and will remain true after Agile. Agile provides the tools to keep those projects on track; whether those tools are used, or only get lip service, isn’t the fault of the methodology.

Twenty or so years after the Agile Manifesto was written, Agile faces a number of challenges. The most important is discovering how to work with data science and artificial intelligence projects. Development timelines for these projects aren’t as predictable as traditional software; they stretch the meaning of “testing” in strange ways; they aren’t deterministic. Progress in developing software tends to be slow, incremental, and fairly well understood. It’s reasonable to have something to demo in two weeks (or whatever interval you choose). With AI, you can easily spend months searching for a model—and showing up to one standup meeting after another saying “ran more experiments, didn’t make progress,” until one day it works. (Perhaps the appropriate yardstick for AI projects is the experiment itself, not the code committed to git.)

Can Agile work for large teams? Large teams present their own problems, but it’s ironic to see writers scorning the “two pizza group” concept because it can’t possibly work for large organizations. Do they know where the concept came from? I don’t know how many lines of code support Amazon’s core business, or how many software developers work on them, but I am sure that those are very large numbers. But again: value interactions over documentation. Make those interactions possible by dividing the project and keeping the groups small. And you can keep the principle of constant contact with the customer; you just have to be careful about understanding who your customer is, and what they mean. (This has to do with the concept of bounded context from Domain Driven Design.)

I don’t think Agile is “perfect”; I don’t even know what “perfect” would mean in this context. I do think that Agile, as described in the Manifesto, points to a number of problems that persist in software development, and offers plausible solutions. Sadly, these solutions are more honored in the breach than in the observance; and Eben was right when he said that no methodology has succeeded until it has become a parody of itself. But if Eben is right, then the solution isn’t looking beyond Agile, but becoming self-aware and critical of our own actions. Why, when things change do they remain the same? What are the power struggles, the rewards and punishments, that lie behind the old and new methodologies? When processes change, who wins, who loses, and why? In any organization, answering those questions will say a lot about how Agile becomes self-parody.

But really, do you know what it would mean for Agile to succeed? We’d forget about it. We’d just do it. Frequent contact with customers, good in-person communications between team members, along with practices like source control and testing, would just be in the air, like our Wi-Fi networks. We wouldn’t agonize over those practices, or create rituals and ceremonies around them. They’d simply be what we do. — Mike Loukides

Radar data points: Recent research and analysis

In “5 key areas for tech leaders to watch in 2020,” we examined search and usage data from the O’Reilly online learning platform. This data contains notable signals about the trends, topics, and issues tech leaders need to watch and explore.

Findings include:

• Python is preeminent. It’s the single most popular programming language on O’Reilly, and it accounts for 10% of all usage. This year’s growth in Python usage was buoyed by its increasing popularity among data scientists and machine learning (ML) and artificial intelligence (AI) engineers.
• Software architecture, infrastructure, and operations are each changing rapidly. The shift to cloud native design is transforming both software architecture and infrastructure and operations. Also: infrastructure and operations is trending up, while DevOps is trending down. Coincidence? Probably not, but only time will tell.
• ML + AI are up, but passions have cooled. Up until 2017, the ML+AI topic had been amongst the fastest growing topics on the platform. Growth is still strong for such a large topic, but usage slowed in 2018 (+13%) and cooled significantly in 2019, growing by just 7%. Within the data topic, however, ML+AI has gone from 22% of all usage to 26%.
• Still cloud-y, but with a possibility of migration. Strong usage in cloud platforms (+16%) accounted for most cloud-specific growth. But sustained interest in cloud migrations—usage was up almost 10% in 2019, on top of 30% in 2018—gets at another important emerging trend.
• Security is surging. Aggregate security usage spiked 26% last year, driven by increased usage for two security certifications: CompTIA Security (+50%) and CompTIA CySA+ (+59%). There’s plenty of security risks for business executives, sysadmins, DBAs, developers, etc., to be wary of.

We also recently conducted a survey looking at the state of data quality. As we suspected, the topic was brimming with interest—we quickly received more than 1,900 responses to our survey request.

Key survey results:

• The C-suite is engaged with data quality. CxOs, vice presidents, and directors account for 20% of all survey respondents. Data scientists and analysts, data engineers, and the people who manage them comprise 40% of the audience; developers and their managers, about 22%.
• Data quality might get worse before it gets better. Comparatively few organizations have created dedicated data quality teams. Just 20% of organizations publish data provenance and data lineage. Most of those who don’t say they have no plans to start.
• Adopting AI can help data quality. Almost half (48%) of respondents say they use data analysis, machine learning, or AI tools to address data quality issues. Those respondents are more likely to surface and address latent data quality problems. Can AI be a catalyst for improved data quality?
• Organizations are dealing with multiple, simultaneous data quality issues. They have too many different data sources and too much inconsistent data. They don’t have the resources they need to clean up data quality problems. And that’s just the beginning.
• The building blocks of data governance are often lacking within organizations. These include the basics, such as metadata creation and management, data provenance, data lineage, and other essentials.

Be sure to check out our archive of Radar research and analysis.

Upcoming events

O’Reilly conferences combine expert insights from industry leaders with hands-on guidance about today’s most important technology topics.

We hope you’ll join us at our upcoming events:

O’Reilly Strata Data & AI Conference, San Jose, March 15-18

Smart Cities & Mobility Ecosystems Conference, Phoenix, April 15-16

O’Reilly Infrastructure & Ops Conference, Santa Clara, June 15-18

1. Gandalf: An Intelligent, End-to-end Analytics Service for Safe Deployment in Cloud-scale Infrastructure — a paper on Azure’s rollout-monitoring software that analyzes more than 20TB of data per day: 270K platform events on average (770K peak), 600 million API calls, with data on over 2,000 different fault types. If Gandalf doesn’t like what that data is telling it, it will pause a rollout and send an alert to the development team. (That’s from Morning Paper, which has a readable summary of the paper)
2. Quarantine Cooking (New Yorker) — we tend to think of the Chinese internet as just a battleground—activists and censors locked in an endless conflict. But, to many it is also homey and comforting, parts of it as familiar as a cozy kitchen. Quarantine cooking captures their boredom, their loneliness, their creativity, and their desire for connection amid anxiety and panic. The street will find a way.
3. Draft of the fast.ai Book — These draft notebooks cover an introduction to deep learning, fast.ai, and PyTorch.
4. p5.js 1.0 — the celebratory Medium post summarizes what’s gone into the release, but it’s everything from tooling to I18N, libraries, and docs.

1. Mapping Coronavirus Responsibly (ESRI) — Let’s take a look at how maps can help shape the narrative and, as concern (fear?) grows, how to map the data responsibly.
2. Don’t Use Low-fidelity Prototypes to Test Desirability — One of my favorite techniques for testing desirability of brand new products is the mock screencast: after creating realistic-looking pages using Web Inspector or your favorite design tool, you can then record your screen while “navigating” through the site by tabbing through mockups and narrating the value proposition.
3. Data Center Power (Jess Frazelle) — fascinating deep dive into power concerns in data centers, talking about what the “hyperscalers” (MSFT, GOOG, etc.) do versus what you’re likely to find in a typical colocation center.
4. Wildcard: Spreadsheet-driven Customization of Web Applications — In this paper, we present spreadsheet-driven customization, a technique that enables end users to customize software without doing any traditional programming. The idea is to augment an application’s UI with a spreadsheet that is synchronized with the application’s data. When the user manipulates the spreadsheet, the underlying data is modified and the changes are propagated to the UI, and vice versa.

1. BellTopo Sans — typeface and free font inspired by the sans serif in old maps. (via Flowing Data)
2. YC’s Guide to Raising Series A — This guide is a distillation of everything we know about successfully raising an A. It includes insights learned from watching hundreds of founders succeed in raising, and in watching dozens fail.
3. Information Disorders (Renee DiResta) — survey proposed regulatory approaches to addressing the range of challenges in the information environment, looking at regulatory proposals around ads, antitrust, and privacy, and how these proposed laws impact the privacy-security-free expression balance. (via Fast.ai)
4. Issues — Issues come in many flavors, for example feature requests, bug reports, customer complaints, security alerts, team retrospectives, etc.; this page describes how our team uses issues, and how we communicate about them.

This is a keynote highlight from the O’Reilly Software Architecture Conference in New York 2020. Watch the full version of this keynote on the O’Reilly online learning platform.

You can also see other highlights from the event.

This is a keynote highlight from the O’Reilly Software Architecture Conference in New York 2020. Watch the full version of this keynote on the O’Reilly online learning platform.

You can also see other highlights from the event.

This is a keynote highlight from the O’Reilly Software Architecture Conference in New York 2020. Watch the full version of this keynote on the O’Reilly online learning platform.

You can also see other highlights from the event.

People from across the software architecture world came together in New York for the O’Reilly Software Architecture Conference. Below you’ll find links to highlights from the event.

The elephant in the architecture

Martin Fowler reveals, discusses, and vents about a very common and widely neglected architectural attribute.

• Watch “The elephant in the architecture“

Where do great architectures come from?

Mary Poppendieck looks at the history of dramatic architectural changes and what triggered them.

• Watch “Where do great architectures come from?“

Architecture.Next: Invalidating old axioms

Mark Richards challenges the tried-and-true axioms in software architecture and shows you how to manage the changing state of the space.

• Watch “Architecture.Next: Invalidating old axioms“

Sometimes I draw

Kai Holnes walks you through the nebulous world of creative outlets and why maybe, just maybe, that journey is worth it.

• Watch “Sometimes I draw“

Intellectual control

George Fairbanks considers whether today’s complex software has eclipsed our intellectual control.

• Watch “Intellectual control“

From the trenches: Rachel Laycock

Neal Ford interviews Rachel Laycock about her career path and her work as an architect.

• Watch “From the trenches: Rachel Laycock“

1. kernel-wasm — Safely run WebAssembly in the Linux kernel, with faster-than-native performance..
2. Smithsonian Open Access — images, 3d models, and more. The ultimate goal is digitizing their whole collection. (via Smithsonian Magazine)
3. Systems that Defy Understanding — In such systems, we must resort to empirical methods. Instead of reasoning about the system and reading the source to answer questions, we find ways to ask questions about the running system. We can perform such queries by looking at existing logs and metrics, or by adding new instrumentation.
4. TextFooler — a model for natural language attack on text classification and inference.

This is a keynote highlight from the O’Reilly Software Architecture Conference in New York 2020. Watch the full version of this keynote on the O’Reilly online learning platform.

You can also see other highlights from the event.

This is a keynote highlight from the O’Reilly Software Architecture Conference in New York 2020. Watch the full version of this keynote on the O’Reilly online learning platform.

You can also see other highlights from the event.

This is a keynote highlight from the O’Reilly Software Architecture Conference in New York 2020. Watch the full version of this keynote on the O’Reilly online learning platform.

You can also see other highlights from the event.

1. Dispatch — Netflix’s incident management framework. (via Netflix Tech Blog)
2. Text-to-Text Transformer (Google) — In “Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer,” we present a large-scale empirical survey to determine which transfer learning techniques work best and apply these insights at scale to create a new model that we call the Text-To-Text Transfer Transformer (T5). We also introduce a new open source pre-training dataset called the Colossal Clean Crawled Corpus (C4). The T5 model, pre-trained on C4, achieves state-of-the-art results on many NLP benchmarks while being flexible enough to be fine-tuned to a variety of important downstream tasks. With code, notebook, and pre-trained models.
3. Antifragile Ideas — a 2015 John Carmack internal talk at Facebook.
4. fastpages — fast.ai’s blogging system designed to publish research outputs. SWEET. (via fast.ai)

1. YOLO Creator Leaves Computer Vision — Joseph Redmon, creator of YOLO (You Only Look Once) has stopped doing computer vision because of its uses. But basically all facial recognition work would not get published if we took Broader Impacts sections seriously. There is almost no upside and enormous downside risk.
2. schema — tool to infer and instantiate schemas and translate between data formats. Supports JSON, GraphQL, YAML, TOML, and XML.
3. Overtone — an open source audio environment designed to explore new musical ideas from synthesis and sampling to instrument building, live-coding, and collaborative jamming. We combine the powerful SuperCollider audio engine with Clojure, a state of-the-art lisp, to create an intoxicating interactive sonic experience.
4. An Architectural Risk Analysis of Machine Learning Systems — a comprehensive approach to identifying different types of risk in each component and process of a generic machine learning system.

1. Teachable Machine — Google’s codeless ML training.
2. Google AI No Longer Uses Binary Gender Tags on People (Input Mag) — the change is already in effect. Credited to their new AI Principles.
3. VP of Something (Matt Webb) — It’s pretty clear to me that in 10 years time, sustainability will have to be a VP role, if not a C-level role, and “circular transformation” (I just made that up; you can have it) will be a phrase for the 2020s, just as “digital transformation” was the business mantra for the 2010s.
4. DeepSqueak — Developed by researchers Russell Marx and Kevin Coffey at the University of Washington School of Medicine, the software uses sophisticated deep learning algorithms (hence the name “DeepSqueak”) to automatically pick rodent calls out of raw audio, compare them to calls with similar characteristics, and even look for patterns in the squeaks’ order. Not much is currently known about what all those squeaks mean, but Coffey hopes that once enough biologists compile enough calls, a sort of murine “Rosetta Stone” will emerge.