What I Learned Today

You may know that you can disable the “AI Overview” in a Google search for a single search by including “-ai” (minus ai) in your search text. But Google doesn’t give you a way to turn it off for all searches.

However, you can configure your browser’s built-in search shortcuts to do it for you. A regular Google search is something like

https://www.google.com/search?q=text

where “text” is the text you are searching for. But if you add an extra parameter (udm=14) to this search, it disables the AI overview:

https://www.google.com/search?q=text&udm=14

You can make this version your default search shortcut in Google Chrome as follows:

1. Open Settings.
2. Go to Search Engine -> Manage Search Engines.
3. Scroll down to the “Site Search” section and click “Add”.
4. Give this search a name (like “udm14”).
5. In the “URL with %s in place of query” box, paste this: {google:baseURL}search?q=%s&udm=14. It will look like this (mine says “Edit”; yours will say “Add”):
   
6. Click “Save”.
7. Under the three dots menu, select “Make default”.
8. Try a search and enjoy no AI overview!

I have not yet figured out how to do this in Safari.

This iconic image shows Margaret Hamilton standing next to a printout of the flight software that she and her team wrote to control the Apollo Guidance Computer. I recently discovered that the code has been made available via a scan of the printouts, later re-typed as code, and uploaded to GitHub. The code is written in assembly, which consists of individual instructions to load, calculate, and act on data values. Today we use compilers so we can write code in higher-level languages that are easily understandable by humans, but at the time compilers were still pretty new, and the available memory was so limited that they wanted humans to do the optimization at the individual instruction level. Wow!

Here’s an example excerpt from the code. Even if you don’t know AGC assembly (I don’t), it’s possible to follow along due to the excellent comments.

I’m in awe of how this massive software engineering project would have proceeded (How did they test it? And without modern version control… did they use periodic printouts in case they found a mistake and wanted to roll back?) What an inspiring project!

Browsing the open issues on the project, they seem dedicated to increasing the quality of the content by carefully proofreading it against the original scans of the code printouts. What a labor of love :) But what a wonderful piece of programming history!

This question lies at the heart of all computer science curriculum design efforts, and it resurfaces year after year after year. One reason that it can never be answered conclusively is that the range of options, and the kinds of programming needs that are out there, change over time. Another reason is that it’s a holy war. For some folks, you might as well be asking what their favorite text editor is. For those folks, don’t.

But it’s a question of more general interest, beyond the computer science classroom. Douglas Rushkoff argues that everyone should be programming-literate, for their own survival, and even less extreme views highlight the benefits of computational thinking.

I’m not going to tell you what language to learn first, because I don’t have (and I don’t think there is) a fully general best-possible recommendation.

Lifehacker took a stab at characterizing a few common languages to help newcomers make this decision. Their programming language menu goes like this:

C: Trains You to Write Efficient Code

Java: One of the Most Practical Languages to Learn

Python: Fun and Easy to Learn

JavaScript: For Jumping Right in and Building Websites

… which isn’t quite how I would have done it. And I’m not sure these characterizations are even useful.

I’m much more persuaded by this approach which points out that “learn a language” is not a single specific concept. It’s important to ask how *well* you want (or need) to learn the language.

I was immediately struck by the parallel with learning natural (human) languages. When I’m going to a foreign country for a week-long conference, I learn a smattering of useful/polite phrases to help me get around and not be That American while I’m there. If I were to move to that country, I’d be willing to invest orders of magnitude more effort to be functional in the language. I don’t agonize over which language to learn; I learn the one I’m going to need.

Likewise, the programming language you want to learn is the one you’ll need to have at your disposal. Work, school, implementation, or other constraints might dictate that to you. And if not — if you’re a hobbyist or just want to learn “programming” with no particular end goal — then does it matter? Pick a mainstream language (so that there are sufficient resources out there to aid your learning) and dive in!

What was the first thing you did with a computer?

If you first encountered computers in a programming class, you probably learned to write a simple mathematical program, like calculating digits of pi or computing the sum of a list of numbers.

Seymour Papert and Cynthia Solomon suggested that we think bigger. While computers can certainly perform mathematical calculations, they can do a lot more than that.

“In the real world computers are used in many different ways. Some are programmed to fly airplanes; not to tell a human pilot what to do, but to pull levers with their own electro-mechanical effectors and to read the altitudes, airspeeds and what-not with their own electronic sensing devices. Computers are programmed to generate music or condition dogs by ringing bells and delivering meat powder while the modern day Pavlov is happily asleep.”)

And they wrote this in 1972 (!).

In their paper, Twenty Things to Do with a Computer, they suggested an alternative approach to using computers for education.

“Why then should computers in schools be confined to computing the sum of the squares of the first twenty odd numbers and similar so-called “problem-solving” uses? Why not use them to produce some action?”

The twenty things they suggest include making the computer draw pictures (they invented the Logo language, something I remember fondly from sixth grade), play video games, generate music, operate an Erector set, write poetry, control puppets, and more. This philosophy is very much in line with the motivation behind maker spaces and programs that encourage learning by doing, motivated by concrete goals and activities.

While not every school has realized Papert and Solomon’s vision, there are great programs out there today, such as the FIRST Robotics Competition, that do encourage kids to learn to program and operate robots using computers. Introductory programming courses are being revamped to move away from math exercise type problems to those that put programming in a real context, like working with multimedia or addressing social issues.

Going beyond what projects or applications computers can help us tackle, we can even use computers to learn new ways to think. I’m a big fan of the movement to teach people computational thinking skills. This doesn’t mean “think like a computer” in some derogatory, robotic way. It means learning how to come up with solutions that are efficient, repeatable, and generalizable. Jeannette Wing’s paper on Computational Thinking provides a great introduction to the idea, and it makes the case for why these skills are useful to everyone, not just computer programmers.

In today’s world of cell phones and tablets and smart watches and embedded devices, the power and ubiquity of computers in everyday life is obvious. In fact, these items are so ubiquitous that we don’t even think of them as computers any more. We use them all the time as, well, users. These ideas from pedagogy invite us to use them as creators, inventors, and problem solvers.

Cybersecurity is a serious issue not just for computers on Earth, but also for those in space.

Last month, JAXA (Japan’s space agency) announced that hackers had broken in to gain access to information about the Kibo Space Station module. The information consisted of Kibo “operation preparations” and mailing lists. In September, a 16-year-old was sentenced to six months in jail for hacking into NASA (and other) computers. In early 2012, NASA’s Inspector General Paul Martin testified to Congress about the state of NASA’s cybersecurity defenses and woes. “In 2010 and 2011, NASA reported 5,408 computer security incidents that resulted in the installation of malicious software on or unauthorized access to its systems,” he said. This goes beyond hacking into an employee’s PC: “The March 2011 theft of an unencrypted NASA notebook computer resulted in the loss of the algorithms used to command and control the International Space Station.”

Naturally, the same concerns apply for our rovers on Mars.

On Tuesday, I attended a talk titled “MSL Cyber-security implementation status report” by Bryan Johnson and Glen Elliott of JPL. You can view the slides from a similar conference talk. They reported on the long list of actions the team has taken to increase the security of operations and commanding for the Mars Science Laboratory (MSL) rover. These include the implementation of Two-Factor Authentication for access to mission systems and applications, consolidating computers into a single virtual LAN, implementing and testing an “incident response process,” and taking obvious (but time-consuming and easy-to-overlook) steps like pruning the list of people with access to the MSL network.

These steps all aim to improve security here on the ground. I asked whether they would discuss measures being taken to prevent unauthorized access to the rover itself, such as encryption or authentication prior to the rover accepting commands. Unfortunately, they declined to discuss it, but the unofficial word is that there is little or no security on the rover side. Conceivably, anyone with a powerful enough antenna and the right pointing information could send the same kind of signals currently being transmitted by the Deep Space Network to all of our remote assets (rovers, orbiters, and other spacecraft). And as we know, security through obscurity only gets you so far. MSL has had a sufficiently high profile that a rumor began circulating last August that the hacker group Anonymous was trying to gain access to the rover:

MarsCuriosity: “Anyone in Madrid, Spain or Canbarra who can help isolate the huge control signal used for the Mars Odyssey / Curiosity system please? The cypher and hopping is a standard mode, just need base frequency and recordings/feed of the huge signal going out. (yes we can spoof it both directions!)”

A group dedicated to “Space Asset Protection” is looking into this side of the problem. Unfortunately, there is some reluctance to adopt encryption, which carries its own overhead in complexity and bandwidth consumption for the often severely limited data links available for spacecraft communication.

And as for authentication, there’s always the chance that the rover might suddenly say, “I’m sorry, Dave, I’m afraid I can’t do that.”