Showing posts with label Austin tech scene. Show all posts
Showing posts with label Austin tech scene. Show all posts

Tuesday, December 25, 2018

Natural Language Processing hackathon, or don't judge the wine by the shape of the bottle

In April of 2018 I went to a Natural Language Processing hackathon. Organized by Women in Data Science Austin, it took place at Dell, where one of the organizers worked. This was not the kind of hackathon where you hack for the whole weekend straight, crashing on a beanbag to catch a few winks in the breakroom of some hipster startup. No, this was a hackathon with work-life balance. It lasted from 10 am to 3 pm on a Saturday, which is just enough time for you to get deeply enough immersed in a subject to fire up your appetite for it, but not get sick of it. There were no minimal viable products produced, and no prizes, but I got to sink my teeth into the basics of Natural Language Processing.

A data scientist named Becky, who does Natural Language Processing for an Austin company, introduced us to the three cornerstone approaches of NLP -- summarization, topic modeling, and sentiment analysis.

Data scientist Becky talks about topic modeling
Data scientist Becky talks about topic modeling.

Sentiment analysis quantifies the subjective emotion in a text, e. g. did the majority of reviewers like or didn't like a particular wine? Data scientists don't take into account just the words, but also such nonverbal information as capitalization (a word in all caps is likely to mean the author feels strongly about it), and emoji. Topic modeling finds abstract concepts that occur in a body of texts, a. k. a. corpus. For exaple, if it finds the words milk, meow, and kitten, it might decide one of the topic of this text is cat. If it finds the words bone, bark, and puppy, it might decide one of the topics is dog.

Summarization reduces a text to several key phrases or a representative sentence. Summarization can be extractive or abstractive. Extractive summarization selects a few representative sentences from the text, while abstractive summarization creates a summary of the text.

As an example, Becky gave a phrase: "The Army Corps of Engineers, rushing to meet President Bush's promise to protect New Orleans by the start of the 2006 hurricane season, installed defective flood-control pumps last year despite warnings from its own expert that the equipment would fail during the storm, according to documents obtained by the Associated Press."

Extractive summarization would extract such phrases from it as:

  • Army Corps of Engineers
  • President Bush
  • New Orleans
  • defective flood-control pumps

In contrast, abstractive summarization would generate such phrases as:

  • government agency
  • presidential orders
  • defective equipment
  • storm preparation
  • hurricane Katrina
Natural Language Processing hackathon hosted by Women in Data Science Austin
As many of the hackathon attendees as could fit in the picture.

I can't quite put my finger on it, but it seems that extractive summarization extracts names of specific entities, but not much information as to what happened to those entities or what did they do. But abstractive summarization seems to "understand" what those entities actually represent and what they do, and thereby extracts more "gist" from the paragraph. I could be wrong about it, of course.

According to Becky, extractive summarization is a mostly solved problem by now. TextRank algorithm takes care of it. But abstractive summarization is a very difficult, unsolved problem, though knowledge graphs help.

At the organizers' suggestion, the attendees arranged themselves into three teams, each focusing on one of those three pillars. The organizers brought with them the corpora, a. k. a. texts to be analyzed. Specifically, they brought wine reviews, lots and lots of them. I suppose that's the second best to bringing the actual wine.

Summarizing wine reviews means extracting an "essence" of what the bulk of the reviewers said about a particular wine. It means identifying certain qualities that most reviewers noticed in a given wine. Sentiment analysis meant identifying whether the reviewers thought mostly positively or mostly negatively about the wine.

I ended up in the summarization team. Lead by Randi, who is a data scientist at a big company, we analyzed the wine reviews. By that I mean we called a bunch of functions from pandas, textacy, sumy and other relevant Python packages. The results were mixed. For example, sumy summarized reviews of Moscato in two sentences, but we had no way to tell whether this summarization is good, i.e. whether those were the most representatives sentences from the reviews. It's funny how this is the kind of problem that one has no way of verifying -- at least none that I learned in my 5 hours of NLP bootcamp. Sure, you could read hundreds of reviews and try to get a "feel" whether those sentences were the most representative, but your "feel" would be subjective.

It makes Natural Language Processing feel like black box, and almost like magic -- until you notice that when you ask for 5-sentence summary, the summary includes duplicates for first two sentences. That looks odd, so you take a closer look at the texts and notice that there are duplicate sentences in the document itself. For all its magic, sumy can't figure that out.

Within sumy, you can choose which summarizer to use. First we used LexRank, and it turned out to be very slow. Then we tried another, LuhnSummarizer, and it was much faster, but the results not nearly as accurate. But how would you decide how accurate a summarization is, given that there are no exact criteria for accuracy that I know of? Well, the first summary described mouthfeel and acidity of Moscato. The second included things like the shape and color of the bottle. It left me with the same feeling one often gets interacting with artificial intelligence, that it's both very smart and very stupid at the same time.

Tuesday, March 20, 2018

Introduction to Natural Language Processing with Women Who Code

In 2016 Women Who Code Austin hosted a series of five presentations on Natural Language Processing. The presenter was our member Diana, who has a Ph.D. in linguistics and has worked in the area of computational linguistics for many years. She did demos of some basic text analysis one can do with the Python Natural Language Toolkit, or in short, NLTK.

She presented all this as a Python notebook. A Python notebook is software that lets you combine text, code, and output of that code on one page. You can run a code snippet right there in the notebook, and the resuls will get updated automatically. So equipped, Diana introduced us to the basics of what computational linguists do. Or if that sounds too ambitious, let's just say she showed some simple things one can do with NLTK.

For example:

  • read in the text,
  • tokenize,
  • tag,
  • remove punctuation,
  • remove stopwords...
  • build a frequency hash table from the rest of words.
The first Austin Women Who Code meeting on natural language processing, with our instructor Diana standing in the center
The first Austin Women Who Code meeting on natural language processing, with our instructor Diana standing in the center

She introduced such concepts as collocations and bigrams. Bigrams are pairs of words that are next to each other in a text. Collocations are pairs of words that naturally occur in the language together, i. e., a chance of them occuring together is greater than random. An example of a bigram that's not a collocation is Trump's usage of a phrase "Liar Ted" (this was the spring of 2016, the height of the Republican strife for a presidential nomination). If a bigram is not a collocation, but occurs more often than randomly in a text, that can help to identify who the author is / who the speaker is, and some such qualities. It can be a fingerpint of sorts.

The aforementioned tagging is something we do after tokenizing (roughly speakinng, breaking the text up into words). Tagging assigns a 2-letter tag to each word, marking it as a part of speech, such as noun, adverb, etc. "You can use a big list of tags, or a simplified one. Using a simplified list of tags can help with speed of analysis of your corpus," said Diana.

Here Diana noted that tagging words as parts of speech has inherent ambiguity in it -- exactly the kind of thing that makes language and its computational processing so interesting. Here is an example of parts-of-speech ambiguity in a sentence: "They refuse to permit us to obtain the refuse permit". Still, the Python Natural Language Processing Toolkit correctly tags the first "refuse" and "permit" as verb (VBP) and the second instance of each as noun (NN).

NLTK correctly identifies parts of speech in the sentence 'They refuse to permit us to obtain the refuse permit'
This slide shows how NLTK correctly identifies parts of speech in the sentence above. The first instances of "permit" and "refuse" are "VB" -- verbs, whereas the second ones are "NN" -- nouns.

At the second meeting we did all those actions with a corpus of -- wait for it -- Hillary Clinton's emails. Her emails were available for download from the Kaggle site. This was still the spring of 2016, and we did not yet know how sad the implications of those emails will turn out to be, so the choice of the subject wasn't as... emotionally loaded as it would have been just half a year later. And to say "we" did this is an exaggeration, because it was actually Diana that did all the processing and presented the code and the results to us in a Python notebook.

Here was the complete agenda of the meeting:

  • Getting data: Hillary Clinton's emails;
  • Reading files;
  • Using Pandas to create a Dataframe in Python;
  • Cleaning data: eliminating punctuation, eliminating stopwords, normalizing data: converting to lower case, tokenizing words
  • Visualizing data.

All of this pre-processing of data was done in the Python Natural Language Processing Toolkit (NLTK).

I must say I would have preferred it if Diana had set up this mini-course as a series of exercises for us to do in class and write some code calling NLTK methods ourselves. But if we had done that, we would not have been able to cover even half as much in those four meetups. So I appreciate what Diana did. At least she showed us what kind of beast NLTK is and which fork to eat it with. In the process learned some basic NLP lingo, such as:

  • corpus -- a body of text, plural corpora; it's what you process to extract words and do computations with them;
  • lexicon -- words and their meanings; example: English dictionary.
  • However, you need to consider that different fields will have different lexicons. For example: to a financial investor, the first meaning of the word "bull" is someone who is confident about the market, as compared with the common English lexicon, where the first meaning of the word "bull" is an animal. As such, there is a special lexicon for the financial investors, doctors, mechanics, and so on.

  • token -- each "entity" that is a part of whatever was split up based on rules. For example, each word is a token when a sentence is "tokenized" into words. Each sentence can also be a token, if you tokenized the sentences out of a paragraph.
  • frequency distribution. The frequency distribution method of NLTK counts the frequency of each vocabulary item in the text. It helps identify the most informative words in a corpus.

So overall I got a little familiar with what are the very basics of what natural language scientists do. But somehow, during those four meetings I was still hoping that we'll get past collecting the statistics about words, and get to some mysterious insights about how language works, evolves, and transforms our thoughts, that only computer analysis of language can provide. Of course, my expectations were unrealistically inflated for a set of introductory lessons.

Going back to Hillary Clinton's emails, here is how you would analyze them. This is an "Exploratory Analysis: Getting and Cleaning Data" slide. Here you see the metadata fields that were extracted from the emails. There are quite a few of them.

Python dataframe with the metadata fields extracted from Hilary Clinton's emails
Python dataframe with the metadata fields extracted from Hilary Clinton's emails. Python dataframe with the metadata extracted from Hilary Clinton's emails
This slide, "Slicing dataframe to extract subject", shows Python method calls that you would use to extract the email subjects from the dataframe shown in the previous image. Presented in a Python notebook, it alternates code with results of that code. The results can be updated on the fly if you make changes to the code. The MetaDataSubject and MetaDataTo fields contain some familiar names and topics that made the news...

The next slide shows the use of the NLTK method "concordance". It produces a list of the words used in the text, with the passages where they are used. So if you want all occurrences of the word "surprise" in Jane Austen's "Emma", with snippets of context, you can call

emmaText.concordance("surprize")

(Here, emmaText is the variable that holds the text of the Jane Austen's novel "Emma".) From this example you can also see that NLTK has corpora of texts from the Gutenberg project, which is pretty handy.

Concordamce: all the places in Jane Austen 'Emma' where the word 'surprize' is used
Concordamce: all the places in Jane Austen 'Emma' where the word 'surprize' is used, obtained by calling a 'concordance' method of NLTK.

Venturing ddeper into natural language processing

The easiest texts to analyze are the news, Diana said. News have very good structure. Sentences tend to be short, and tend to have classical structure: subject, verb, object, etc. Medication instructions are also easy to analyze, since they are required to have readability scores high enough to be suitable for 9-12 year olds. But in literature the sentences are often not conventional and much harder to parse.

At the last meetup we talked a little bit about analyzing texts "for real". And by that I mean a little deeper analysis than just breaking up sentences into parts of speech and gathering statistics about it.

One example where computational linguistics is used is to grade student essays. If you have so many essays that hiring human graders would be cost-prohibitive, natural language processing can help. For example, if an essay is supposed to be on the US Declaration of Independence, the script would check to see if certain words are present in it in a certain way, and will conclude that that student might have a certain level understanding of the topic. (Yes, I know, this raises lots of questions about creativity versus cliche'd, cookie-cutter texts: the latter would be more likely to hit all the points that a grading program is looking for, whereas the former might be difficult for a program to discern. But we didn't cover such questions at the meeting, since it's an uncharted territory.)

We touched upon sentiment analysis, which helps determine how customers feel about an experience they had with a brand or a company. Companies like HomeAway use it to analyze customer reviews of their rental properties. And they discover unexpected things that way. For example, analysis of customer reviews of B&B-type places showed that the greatest predictor of customer satisfaction is whether a house has pots and pans.

Sentiment analysis also shows that, for example, if you try to infer customer satisfaction from the reviews by searching for wait times, you'll get inconsistent results. 15 minutes would be bad for a restaurant, but lightning-fast for an emergency room.

And this is where people try to determine degrees and ways of relatedness or similarity between concepts.

For that, they can use ontologies.

What is Ontology?

A consensus is now established about the definition and the role of an ontology in konwledge engineering: "An ontology is a formal, explicit, specification of a shared conceptualization".

It is used in cognitive modeling.

More about Ontologies

An ontology is a schema (model) describing the types (and possibly some individuals) in a domain, the relationships that may exist between types and individuals, and constraints on the way individuals and properties may be combined.

Here are some examples of ontologies

  • Classes: Project, Person, ProjectManager. ProjectManager is a subclass of Person. People and Projects are disjoint.
  • Relationships: worksOn, manages. Manages is a sub-property of worksOn.
  • Constraints: People work on Projects, not the other way around. Only ProjectManagers can manage Projects.

This simple example enables machine inferences, e.g. if X manages Y, then we can infer that Y is Project, and X is a ProjectManager and therefore a Person.

Onthologies allow people to create trees representing relationships between concepts, like this:

A tree that expresses relationships between conecpts in the academia (Student, Employee, Faculty, etc)
This is an example of a tree that expresses relationships between conecpts in the academia (Student, Employee, Faculty, etc.)

Some people propose ways to neasure the similarity of concepts by some graph metrics, such as the shortest path between two nodes.

Measure of similarity between two concepts in a graph, expressed in terms of a shortest path between two concepts.
Measure of similarity between two concepts in a graph, expressed in terms of a shortest path between two concepts.

More pictures from the Women Who Code Austin meetup series on Natural Language Processing are in my photo gallery.

Sunday, October 29, 2017

Scott Aaronson at the Austin Quantum Computing meetup

We have heard that quantum computers are supposed to be much faster than classical ones. But what exactly does that mean, and why can't computers based on some other exotic physical models of computation be as fast? Scott Aaronson examined other models of computation and dispelled some popular myths about quantum computing at the Austin Quantum Computing meetup in May of 2017.

His talk might not have had a whole lot of new stuff for those who read his blog. It was a tour-de-fource of the topics he often addresses on his blog, and a synopsis of what a layperson needs to know about quantum computing. It was about what makes quantum computing so fascinating, but also how to keep your expectations of it realistic.

Scott started his talk with a look at some hypothetical alternative forms of computing. What physical models of computation would be alternative enough to violate the Extended Church-Turing thesis?

Church-Turing Thesis is closely related to the definition of computability: it says that all the computable functions are those and only those that could be computed by the Turing machine. Extended Church-Turing Thesis says that a Turing machine can simulate all other computers with at most a polynomial overhead. Are there forms of computing that challenge the extended Church-Turing thesis? On what kind of physics could a computer possibly be based to overturn it? Scott examined hypothetical computers based on exotic conditions where everyday laws of physics break down.

Relativity Computer

Scott's first example was a relativity computer. How come no one talks about relativity computer, he asks. The idea is simple: you start your computer working on some really hard problem, maybe NP-hard problem, and leave it on Earth, while you take off into space. From the computer's perspective, billions years have passed, the civilization has collapsed. But from your perspective, thanks to the relativistic time dilation, only ~ 20 years have passed. You come back and miraculously find your computer in the rubble, still connected to a power source, and you can read out an answer to your hard computational problem. So why hasn't anyone tried it? If you're worried that your friends will be dead in the distant future, just bring them on the spaceship with you.

Humor aside, the question is, would such a "relativity computer" (well, in this case the computer is ordinary, it's you travelling at a relativistic speed that makes the answer appear quickly) provide a fast solution to NP-complete problems? Would the problem be solved in polynomial time from your perspective?

The answer to that, Scott says, has to do with the amount of energy that would take to accelerate to relativistic speed. If you want to get an exponential speedup in only polynomial amount of time as experienced by you, you would have to accelerate so close to the speed of light that would take exponential amount of energy. So before your spaceship takes off, just fuelling it up would take exponential time.

It can sometimes seem like you could achieve exponential speedup for some problems by exploiting certain physical processes, but to really evaluate any such possibility you have to look at everything we know about physics, such as the energy involved in such a calculation.

Zeno's computer

Zeno's computer is a hypothetical computer in which each operation would take only half the time that it took for the previous operation. This scenario could occur at the so-called Omega Point. Omega Point is a theological notion, but according to some physicists, it could occur under some highly debatable conditions. (I don't think Scott mentioned Omega Point in his speech, I just remembered this trope because it seemed fitting.) For example, the founder of quantum computing, David Deutsch, envisions Omega Point happening near the time of the Big Crunch, as the universe oscilates faster and faster. By the time the universe collapses, the computations have achieved nearly infinite speed, and if you simulate the whole universe on the computational power of those oscillations, the world will never end for you. The closer the real thing comes towards the end, the faster the oscillations will go, the longer "subjective" time you'll be able to simulate. Here is a quote from the David Deutsch book "Fabric of Reality" where he discusses Omega Point. Scroll down to the paragraph "The key discovery in the omega-point theory...".

On the Omega Point computational substrate you would be able to solve NP-hard problems fast. But according to our best cosmological models, the universe is not going to end in the Big Crunch. Even aside from this particular scenario, Scott points out a fundamental problem with Zeno's computer. Zeno's computer relies on infinite amount of computational capacity, but any space-time region has only a finite number of information storage capacity. He says so in his own comment on his blog:

"Rahul #50:

Does Nature (or an existing proof) prevent undecidability in statements involving finite times / spaces / lattices & precision?

Mathematically, if we know that a problem only requires enumerating a finite list of possibilities, then essentially by definition that problem is computable. This is why, any time you see a new problem that's been proved at least as hard as the halting problem, that problem will always involve some element that goes to infinity (if the title and abstract aren't forthcoming about this, read the main text and see! ?? ).

Physically, it's conceivable that we could have lived in a universe where an infinite amount of stuff could get done in finite time (e.g., by what I call the "Zeno Computer," that does one step in 1 second, the next in 1/2 second, the next in 1/4 second, and so on). In such a universe, of course the halting problem could be solvable in finite time.

But the current conjecture in theoretical physics -- primarily because of the work of Jakob Bekenstein on black hole thermodynamics, which I blogged about before -- is that we don't live in such a universe. Rather, we seem to live in a universe that can be modeled as a quantum computer where each finite region of space stores at most ~1069 qubits per square meter of enclosing surface area (with the bound saturated only by black holes), and where those qubits are operated on at most ~1043 times per second. In such a universe, of course the halting problem would not be solvable."

Also, he says in an excerpt of his talk Big Numbers

:

While no one has tested this directly, it appears from current physics that there is a fundamental limit to speed, and that it's about 1043 operations per second, or one operation per Planck time. Likewise, it appears that there's a fundamental limit to the density with which information can be stored, and that it's about 1069 bits per square meter, or one bit per Planck area. (Surprisingly, the latter limit scales only with the surface area of a region, not with its volume.)

What would happen if you tried to build a faster computer than that, or a denser hard drive? The answer is: cycling through that many different states per second, or storing that many bits, would involve concentrating so much energy in so small a region, that the region would exceed what's called its Schwarzschild radius. If you don't know what that means, it's just a fancy way of saying that your computer would collapse to a black hole. I've always liked that as Nature's way of telling you not to do something!

One of the few things about quantum gravity that everybody agrees on, says Scott Aaronson, is that it places fundamental limits on how much computation you place in a bounded region.

Other models of computation based on physical world

Sometimes people suggest that soap bubbles could solve NP-hard problems in polynomial time just by finding the minimum surface when they are connected. Finding the minimum surface for connected soap bubbles is an NP-hard problem, but humans have observed that soap bubbles form a minimum surface very quickly, thus prompting the idea that a polynomial-time algorithm for finding the minimum surface does exist. And if we could encode an NP-hard problem as a soap bubble problem -- in effect "feeding" it to a soap bubble computer -- then we could solve them in polynomial time.

Scott Aaaronson giving a presentation at the Austin Quantum Computing meetup
Scott Aaaronson giving a presentation at the Austin Quantum Computing meetup

The problem with it is that bubbles do get stuck in local optima, says Scott. In other words, the surface they settle into is not guaranteed to be the absolute minimum but some kind of local minimum. Scott talks about it in more detail in his paper "NP-complete Problems and Physical Reality" (PDF).

In his teens, Scott experimented with the surfaces soap bubbles form. That was the closest in his life that he had ever been to an experimentalist. And in his experimments the bubbles got stuck in local optima. "But I haven't tried every possible brand of soap," Scott quipped.

Same is true about using protein folding for solving NP-complete problems. Finding optimal configuration for a protein can be modelled as NP-complete problem, and yet every cell in our bodies does it every second. Despite having been under enormous selection pressure to not get trapped in local optima, proteins still sometimes do that, and that can lead to prion- and amyloid-related illnesses.

That's the basic problem with all physics-based computations: systems in nature do get stuck in local optima. "This may sound silly," says Scott, "but every few months I get calls from popular science writers and they ask me, what about this? This violates Church-Turing thesis! But the things they suggest usually have the problems I mentioned."

When Scott Aaronson first heard about quantum computing as a teenager, he was similarly skeptical. He thought some physicist didn't understand Church-Turing thesis. So he had to find out about quantum mechanics for himself.

Does quantum computing bypass Extended Church-Turing thesis?

Does it? Skipping ahead, the smart people of the internet think it very likely does.

But back to Scott Aaronson's story. Setting out to learn quantum mechanics, Scott found out that quantum mechanics is not as hard to learn as it is commonly assumed. As he says, Quantum Mechanics turns out to be incredibly simple once you take the physics out of it. And no, he doesn't mean in a woo-woo New Agey sense. He adds: "The way I see it, it's a level below physics. It's an operating system that the rest of physics runs on as application. And what that OS is is probability theory with minus signs."

Scott Aaaronson's slide on quantum mechanics as probability with minus signs
Scott Aaaronson's slide on quantum mechanics as probability with minus signs. It shows the double slit experiment with a smiley-faced photon going through two slits and interfering with itself.

Probabilities with minus signs" is the concept of probability amplitude, which Scott has written about in more detail in this Quantum Computing Since Democritus series article. Here, Scott shows how the concept of probability amplitude (which is an entity that can be negative) explains the phenomenon of quantum interference. Interference is what causes some "paths" that lead to an observed outcome (e.g. photon going through either slit in the famous double-slit experiment) to cancel each other, because one has a plus sign, and the other has a minus sign.

"Probabilities as complex numbers come up in the double slit experiment," says Scott. "If I close off one of the slits, the photon appears in places where it doesn't want to appear before. By decreasing the number of choices, I can increase the likehood of an event. Physicists were eventually forced to say: the photon has some amplitude for going through the first slit, and some amplitude for going through the second slit. And amplitudes are complex numbers. You have to add the amplitudes of all the slots, and then take a square. That's a positive number."

This approach to quantum mechanics leads you to learning enough quantum mechanics from the "right angle" to understand quantum computing -- and you don't need differential equations and Schrodinger's wave equation to understand it. The latter is the traditional approach to teaching quantum mechanics, and, according to Scott, it scares people away from it. "Richard Feynman in his book "QED" doesn't even mention complex numbers. He says that each path has an arrow attached, and to compute how likely that path was, you stack those arrows together. So that's a perfect example how to boil it down to a bare minimum but not lower than that," says Scott. "I've given talks about this stuff at high schools. The smarter high school students can understand a lot of it without much difficulty, part of it because there is less they have to unlearn. To get into this field you don't have to take years and years of physics, you don't have to known how to do integrals or solve differential equations. But you have to understand vectors and matrices and complex numbers. So that's the bare minimum. But that bare minimum is accessible to a much larger population of people than the people that had been traditionally thought of as being able to understand quantum mechanics."

(To be fair, not all quantum physicists agree that quantum mechanics can be taught as "probability theory with minus signs" without first introducing the wave equation and such. Here is a discussion on Quora about what is lost when you approach it that way. -- E.)

Understanding interference will also inoculate you against the biggest fallacy that's being thrown around in the popular press when explaining quantum computing. A quantum computer does not "try every answer in parallel" to arrive at the right answer. If there is one thing Scott would like you to take away from this or any of his quantum computing presentations, it is this. The quantum computer does not try every answer in parallel. It's not a massively parallel classical computer.

It is interference that lets you get the right answer out of a quantum computer. You rely on the fact that amplitudes behave not like probabilities because they can cancel each other. For every wrong answer, you hope that each path leading to the answer to have equal positive and negative amplitudes, so they could cancel each other. For the right answer we want all the paths leading to it to have either all positive or all negative amplitudes. We need to to do something to boost the probability of the right answer, and quantum interference does that. That's one new tool quantum mechanics puts in our toolbox.

This is also his bare minimum standard for popular science articles explaining quantum computing, also known as the minus sign test. The article needs to mention interference.

Applications of quantum computing

Though we are used to thinking about quantum computers as something that would let us solve hard problems fast, the first application of quantum computing that its pioneers conceived wasn't that at all. Their initial reason for building quantum computers was to simulate quantum systems. "In the 1980s, Feynman, Deutsch, and others noticed that a system of n qubits seems to take ~ 2^n steps to simulate on a classical computer, because of the phenomenon of entanglement between the qubits. They had the amazing idea of building a quantum computer to overcome that problem," Scott says. And now, decades after Deutsch proposed that idea, Scott Aaronson still thinks that quantum simulation is a major, perhaps the biggest and most promising, application for quantum computing. It could have huge applications for energy.

For Scott personally, the number one application is to disprove people who come to his blog and argue that quantum computing is impossible.

What about cryptography?

When people say "quantum cryptography", they typically mean one of two things: (1) Quantum Key Distribution (QKD) -- a process that lets two parties exchange cryptographic keys while guaranteeing that the keys won't be intercepted by an attacker in transit, or (2) quantum-safe cryptography, that is to say, classical encryption algorithms that can't be broken by quantum computers any faster than they could be broken by classical computers. I'm not sure which one Scott meant when he said that quantum cryptography already exists today, but there is almost no market for it, because it's a problem that's already solved by private key encryption.

As far as public-private key encryption, it relies on computational difficulty of factoring large numbers, and that is actually vulnerable to Shor's factorization algorithm, but there are many symmetric encryption algorithms (that use the same key for encryption and decryption) that don't rely on factorization and thus can't be cracked by quantum computers.

(Here is a more detailed overview of quantum-safe encryption algorithms and QKD.)

But when it comes to using quantum computing to solve any kind of problems faster, as anyone who reads Scott's blog already knows, he is very doubtful that there will be real, practical applications for quantum computing in that respect. At least not soon.

Can quantum computers actually achieve exponential speedup? What about any other kind of significant speedup?

"If we were physicists, we would have declared P != NP to be a law of nature," Scott says. "But we use different terminology. Where physics have laws, we have conjectures."

Popular press sometimes states that quantum computers can solve NP-complete problems in polynomial time, but anyone who reads Scott's blog knows that's not true. The integer factorization problem that Shor's algorithm solves is not known to be NP-complete, and is suspected not to be. But can quantum computers do it at some point?

Scott Aaaronson's slide of the BQP problem class
Scott Aaaronson's slide of the BQP problem class

There is a complexity class called BQP, or bounded-error quantum polynomial time. Those are problems for which exists a bounded-error polynomial time algorithm for quantum computers. "Bounded error" means that the algorithm will give a wrong answer no more than a certain percentage of times -- that percentage probably being sufficiently low, or can be brought down to be sufficiently low for practical purposes. This class of problems is bigger than P, the class of polynomially-solvable problems, but it definitely does not include the NP-complete problems -- at least nobody at present thinks that it does, and there is a lot of evidence that it doesn't. So most likely polynomial-time algorithms for NP-complete problems, even on quantum computers, don't exist.

But it's not known yet where the boundaries of BQP lie. While it includes some problems in the intermediate zone of NP problems that are not known to be P, but not known to be NP-complete either, some of these problems are very special problems. We don't even know if BQP is contained in NP. So there may be problems that quantum computer can efficiently solve, but a classical computer might not even be able to verify the answer. For that you would need another quantum computer.

What about D-Wave's claims of exponential speedup?

D-Wave is a company that builds adiabatic quantum computers and that has claimed to achieve quantum supremacy, that is, made a quantum computer that achieves significant speedup over a classical computer for some type of problem. Scott has long been skeptical of their claims. Even if you were able to build a perfect adiabatics quantum computer, we don't know how well it would do. The quantum adiabatic algorithm was described in a 2000 paper by Farhi and other authors, and the general idea is shown in this slide by Scott. Farhi suggested that maybe it solves NP-complete problems in polynomial time, which would put NP in BQP. The iffy part is that the amount of time you need to run adiabatic algorithm depends on something called eigenvalue gap. As you vary the Hamiltonian, what is is the smallest gap between its first and second eigenvalues? If that gap becomes exponentially small, you need to run it for an exponential time. "And some people were able to construct problems for which this gap becomes exponentially small," says Scott.

"After you've seen problems with NP-completeness, you are tempted to elevated [computational] hardness as a fundamental physics problem. You would ask, what implication it would have for physics? And now we know some examples: for example, in condensed matter systems spectral gaps would have to become exponentially small," says Scott Aaraonson.

For the last some number of years D-Wave has been trying to find problems for which adiabatic algorithm would be exponentially faster than a classical algorithm. Scott is quite skeptical that they have found any. In the previous quantum computing meetup, though, Brian La Cour from UT Austin said he thought it wasn't so clear-cut, because the recent D-Wave advancements make it less apparent that there is a classical algorithm that would do just as well. But it's not that Scott is skeptical about adiabatic algorithms altogether. "We may not understand the potential of adiabatic algorithm until we have a real quantum computer," he says.

Scott Aaronson's areas of research

Scott's own research area is quantum supremacy, that is, finding quantum algorithms that for some types of problems provide a definite speedup over any classical algorithm. And by the way, he got a lot of comedic mileage out of that phrase during the Trump campaign year.

A year ago Scott wrote this paper connecting quantum computation to the black hole firewall problem. He briefly mentioned it and said that there wasn't enough time to discuss it at this presentation. This left me and some other people in the audience with a cliffhanger feeling. Just when we got to hearing something we had not heard about before, the lecture was over! Some of us asked Scott about that paper later after the talk, and he pointed us to more information about the paper on his blog.

Questions from the audience

Unfortunately, the questions were nearly impossible to hear, because the audience members didn't have a microphone. So I could only guess the general topic they asked about.

Q1. About quantum entanglement.

Scott Aaronson. I didn't say much about entanglement in this talk. In quantum mechanics entanglement is not a separate rule you have to postulate. It's just something that's there for a ride. It's just that entanglement means that in QM you can't write a state of a qubits as a product state.

If qubits are not entangled, you don't have a quantum computer. You can simulate it easily with a classical computer. Entanglement is a necessary but insufficient condition for QM.

Q2. About decoherence, the problem that makes quantum computing so hard to implement in practical terms.

Scott Aaronson. A crucial discovery from the nineties was that you don't have to get your decoherence rate down to 0. You just need to get it down to very very low rate. So even if some small number of qubits will leak out into environment, the quantum information that you care about is still there.

Q3. About machine learning and quantum computing.

Scott acknowledged that quantum computing might seem like a natural fit for quantum computing. "In a way, machine learning is all about linear algebra in high-dimensional spaces, and so is quantum computing. But you always have to ask, if someone can simulate a quantum machine learning algorithm with a classical approach, would they really a get a speedup from the quantum computing algorithm?"

Thursday, May 25, 2017

Advances in quantum computing: presentation by Dr. Brian La Cour

Dr. Brian La Cour from University of Texas at Austin gave a presentation on the latest state of quantum computing to Austin's Quantum Computing meetup in March of 2017. Here are some prominent points from it.

Several big companies are getting into quantum computing now: Google, Microsoft, IBM. There are significant differences between their approaches.

Google plans to solve a problem with 49 qubits, a problem that would demonstrate quantum supremacy (getting a clear speedup with a quantum algorithm over a classical algorithm), but is completely useless in real life. The problem with that is that when you progress to the quantum supremacy frontier, you can no longer check the answer with a regular device. Or it would take a very long time. So Google's argument will probably be based on asymptotic trend, with how they are doing with more qubits. But overall this problem of how to check the results will be more difficult in the future.

Brian La Cour talks at the Austin Quantum Computing meetup
Brian La Cour talks about Google's race to quantum supremacy at the Austin Quantum Computing meetup

We are a long way from solving Shor's algorithm and breaking internet's encryption. But quantum simulation is a near term application. It goes back to Richard Feynman's discussions of quantum computing. We can simulate things on a digital computer, but it's not very efficient. When you want to add another spin, another atom, you have to double the memory. What better thing to simulate a quantum system than a quantum system?

There is a difference between gate-based quantum computing (like what IBM and partially Google does) and quantum annealing, like what D-Wave does, and partially Google.

Gate-based device (that operates on gates, similar to classical gates) is a universal quantum computer. D-Wave's computer is specialized, it is only useful for certain optimization problems. And so far those problems have been pretty contrived, not necessarily corresponding to anything in real life. Even so there is no definitive evidence that the D-Wave's computer is advantageous for solving specific practical problems, as compared to classical solvers. There is a professor somewhere who, every time when D-Wave claimed that their quantum computer was solving some problems more efficiently, took it as a challenge to find a classical algorithm that would beat it. And so far he has been successful. But lately this has become less clear, because he has been, in Brian's words "exploiting what he knows about the problem". (Mathematicians and computer scientists can make it sound like it's a bad thing. But perhaps he means that while the professor is exploiting special knowledge about a problem, the quantum annealing computer can't make use of that knowledge, thus he is not comparing apples to apples? -- E.)

IARPA -- funding agency for intelligence community, analogy of DARPA -- is focused on developing next-generation quantum annealing, a universal quantum annealer. Their goal is, can you take benchmark projects and scale them to the thousands of qubits that D-Wave has?

Microsoft is looking at high-level languages for quantum computing. They are designing high-level languages that optimize what low-level languages do. They also do their own research into topological quantum computing, which is a very different approach than the qubit-based QC, but Brian thinks that's technologically so far away it's probably never going to happen.

This brings us to another Brian La Cour point, which is that now is a good time even for ordinary software developers to get involved in quantum computing, and you don't have to be a researcher to do it. There are people who are building interfaces in conventional programming languages to QASM, IBM's Quantum assembly language. This is where you as an individual can make a contribution: figure out how to do things in QASM and implement an interface to it in your favorite language. Also, individuals can play around with the IBM's Quantum Experience, a web interface to the IBM's quantum computer, and familiarity with it could put you in a position to get a job at some company that does quantum computing (not that there are many of those currently -- E.).

According to Brian, quantum gamification is also a trend. However, he used the word "gamification" not the way it is typically used (to incentivize certain user behaviors by making them seem like a game). He meant it more literally in the sense of games that teach you something about quantum mechanics. In some of those games people perform actions that help quantum researchers. Here are some examples:

  • www.scienceathome.org
  • qCraft -- a "mod" to the popular Minecraft game. It uses "quantum blocks" to teach superposition, observation, and entanglement.
  • There are even games that have been programmed on IBM Quantum Experience, such as Quantum Battleship.
  • Decodoku was developed to help researchers with quantum error correction. You are protecting researchers from errors.
  • cat-paper-scissors game (I could not find it by googling -- E.)
  • Quantum Cats from University of Waterloo, Canada. It's like angry birds, except cats can be in superpositions.

Brian La Cour noted that not only quantum computing research is strong in Canada, Canadian QC scientists also do a lot of educational outreach. US scientists don't do nearly as much, but they should.

As always, the least predictable part of any presentation is the audience's questions, and Brian got a few of those.

Audience member. Have you heard of neuromorphic computing?

Brian replied that he has heard about it, but that there wasn't any connection there to quantum computing. It was just another unconventional way to compute. Apropos of unconventional computing, quantum computing in a way is a throwback to analog computing: encoding information in continuous variables, except what comes out is still digital.

Audience member. Can quantum computing be used to mine bitcoins?

Aside from currently existing quantum computers being nowhere near powerful enough to mine bitcoins, Brian also noted that the value of bitcoin is based on the fact that bitcoins are computationally difficult to find. So if you find an algorithm to mine them fast and reliably, it will devalue them.

Audience member. How big a leap is it to go from classical programming to quantum programming? Is it a totally different beast?

Brian. It is a totally different beast. If you try to do things like conditionals and loops, you are doing it wrong. Instead of conditionals you have control gates, where value of one qubit controls what happens to another qubit. Which is sort of like conditional, but linear. A qubit in a superposition of 0/1 controls another qubit which is also in superposition.

The way you think about quantum computing is taking your entire data space, or state space, and think about it all at once.

You initialize all to 0 and apply Hadamard gates all at once. It puts them in superposition of all possible states, and then you do operation on them. You are looking at the whole haystack and apply operations to the whole haystack until you find a needle. You don't examine each value and look whether it's a needle.

Wednesday, February 15, 2017

Stumbling into BodyHackingCon on the last day

You walk into the BodyHackingCon on an early Sunday afternoon, and you are not sure if it's really still going on. You expect it to have a bigger, or at least flashier presence: shouldn't there be people with highly visible body modifications milling about? Instead, you see people in business casual whose name tags say "superintendent", and the hallways are plastered with signs for Texas School Boards convention. But you persist and walk around a corner, and then down a city-block-long corridor around another corner (that's Austin Convention Center for you), and you are finally rewarded by a hand-scrawled sign pointing towards an open door of a huge, warehouse-style expo room. But this is the last day of a 3-day convention, so naturally most of the vendors are gone.

Neosensory vest that is supposed to let you perceive words as vibrations on your skin, seen at BodyHackingCon 2017 in Austin
Neosensory vest that is supposed to let you perceive words as vibrations on your skin

There is still a thing or two happening; at one of the booths a visitor is trying to pull together the edges of a peculiar-looking vest around his torso; it clearly is not going to happen, since the vest is 3-4 sizes too small. "I'm sorry. We are planning to have larger sizes in the future," says a vendor at the booth, even though the guy is merely average size. But apparently the vest does not need to close to work. It is studded with small metal circles that make up some kind of haptic language interface. That's only my guess based on what I could glean from the snippets of conversation. Because who needs to ask how it works when you can speculate?

"Whip. Angle," says the booth guy. "Whip. Angle." Then he turns a phone screen to the guy who's trying out the vest. There are two circles on it, and he asks the guy to pick one to tap on. Apparently the booth guy made the dots convey some kind of haptic stimulation (e.g. buzzing?) -- and asked the wearer to recognize the word encoded in it. He praises the wearer for answering correctly. "So you see, it's not just the length of the word," he says. I guess he was saying that the vest made it possible, with some minimal training, to distinguish the actual word pattern, not just a longer word from a shorter word?

A jacket with a ribcage headpiece (?) from BodyHackingCon
A jacket with a ribcage headpiece? This would make a splash at a science fiction convention.

Then you look around some more, and even with most vendors gone and large patches of the expo hall square footage reverting to its post-convention beige bleakness, you still see something unusual. At another exhibitor's booth, flanking it on both sides, two women are lying on the tables, looking for all the world like wax statues. Their eyes are covered with something that could be a sleep mask or a VR headset. You glance at the vendor's name -- bio- or healing-something -- and think it's more likely to be a mask. By the way, the name matches a definite pattern: half of the exhibitors' names here have "bio", or "quantum", or something vaguely medical in a New Agey way. Which is fitting, given that half of them sell nothing more than nutrition drinks and supplements.

You stumble upon exhibits of clothes that wouldn't be out of place a goth or punk store, except they have patches with wires sticking out, like something that's placed on you right before a surgery. Some also light up. Many would make a stunning costume at a science fiction convention, if you could spawn off a third or fourth alter ego to explore your mild interest in costuming. Overall, this is the bodyhacking you could get behind -- the kind that stays entirely outside the body.

Most of those clothes are art projects. One dress claims to simulate dark matter: "Dark Matter inflates and deflates against your body to simulate the universe expanding against you, and the buzzing sculptural universal necklace, "Dark Energy", buzzes against your skin to simulate movement through the universe in time in accordance with events happening in VR". But you have read enough science fiction and imagined the vast cosmic space enough times that you know if you put on that dress (not that it's an option) the experience would fall very short of feeling at the center of the expanding universe.

A cape that goes over some sensor with wires that's placed on your chest, seen at BodyHackingCon 2017 in Austin
A cape that goes over some sensor with wires that's placed on your chest, resembling uncannily of surgical preparations.

Some of the clothes have VR content associated with it accessible through your phone; and perhaps you could spend some interesting minutes with it, but just downloading the app would take some time, and the WiFi connection in this building is iffy, and the event is winding down and you are sure vendors are anxious to pack up and leave.

Finally on the way out you get a glimpse of a more radical kind of bodyhacking: a guy you pass in the hallway has small, but prominent devil's horns under the skin of his bald forehead.

Tuesday, March 03, 2015

Build Something Awesome… but what?

"Build Something Awesome with OpenStack and the Open Cloud" hackathon could have lived up to its name, if only someone knew what kindof awesome things one could build with OpenStack. Or could explain it to developers. But I'm getting ahead of myself.

Maddy (left), our unofficial team lead and Python expert, and Anna
Maddy (left), our unofficial team lead and Python expert, and Anna. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

The September 14th, 2013 OpenStack hackathon was the first hackathon I ever attended. It was organized and sponsored by Rackspace, creator of the OpenStack project. I didn't know much about it, so I assumed that it was just yet another API that lets you build applications. The hackathon event page did not hint at what kinds of applications you could build with it. So I was surprised when it turned out that for the kind of application my team wanted to build, OpenStack kind of… got in the way.

The hackathon started with a 2-hour presentation by Rackspace's developer advocate. He guided us through a tutorial on how to create a DevStack server on Rackspace. DevStack, by the way, he said, is not the same as OpenStack, but the distinction was lost on me. This was by far not the most subtle point that was lost on me.

Left to right: Paige, Jess, Maddy (our unofficial team lead and Python expert), and Christine
Left to right: Paige, Jess, Maddy (our unofficial team lead and Python expert), and Christine. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

After the presentation our team of five, all female developers, rolled up our sleeves to start building the application proposed by one of our members. I investigated the server created during the walkthrough, looking for the directory where Apache keeps HTML files and web scripts. That's where I thought I would place a web application (at the beginning, just a Python script) that we were writing. I saw there was an index.html in the /var/www directory, but its contents were not the one that were displayed when you pointed your browser to this server's root URL. So I went to the presenter and asked why that was. He said, better don't try to use Apache on that devstack server; it's configured in a special way, and if you want to run an ordinary Apache web server, you'd be fighting it all the way. You should create a basic Linux server on Rackspace, not a Devstack server, and install Apache on it. I tried asking him what could we do with this Devstack server, if not write web applications. He said it was mostly for learning. Learning OpenStack. Well, that still didn't answer my question what I could do with OpenStack, but oh well, maybe I should have found out beforehand? It's not like it was any secret that this hackathon was for building things with OpenStack: it was in the name of the hackathon. But I wasn't the only person who went there with assumptions that I could build web applications with it.

Other lessons from this hackathon were more interesting, and came from my attempt to find out what can be accomplished during a hackathon. More about it in the next blog post.

Tuesday, July 01, 2014

What can go wrong at a hackathon, or Jekyll and Mr. Hyde

The application I worked on at SheHacksATX was called Groove. It is a fertility tracking app that's primarily mobile, but its owner Jennifer wanted a few features to be added to the Groove website. One of the features was an image with clickable parts, each of which produced a different text explanation; another was a rotating image slider with captions for each slide, that would pause when a mouse hovers over it, and resume when the mouse is moved off of it. I took the task of creating the slider, and the other developer in our team took the image. Of course, I didn't create the slider completely on my own: similar Javascript widgets already exist out there on the web. I found one on Github, and adapted it to our application's needs. But even that wasn't trivial. I had to find ways to customize the layout of the captions, and to implement the pause-on-mouseover / resume-on-mouseout functionality. It may sound like a piece of cake to you front-end gurus, but I'm a backend developer after all. I have to spend precious minutes or hours brushing the rust off of such bits of knowledge like how do I make two <div> tags to appear side-by-side, or to climb out of the rabbit hole of nested callbacks in asynchronous function calls.

But programming challenges wasn't what posed a threat to our team's chance of accomplishing our tasks. It was development environment incompatibilities. It turned out that certain technologies are difficult to get working on Windows. I'm looking at you, Jekyll. Jekyll, a website generator, lets you write HTML pages using a certain system of shorthand tags, as opposed to actual HTML tags; Jekyll runs on the server, parses those template files and turns them into HTML.

Well, it turns out that Jekyll on Windows is more like Mr. Hyde. Trying to run it I got an uninformative error, and a cursory Google search made me think that perhaps I need to run it on a higher version of Ruby than the one on my laptop. (Jekyll is written in Ruby.) Jennifer was running Jekyll on her machine with Ruby 2.0, whereas I had Ruby 1.9. So I decided to see if upgrading Ruby fixes the problem. Except there turned out to be no quick way to upgrade Ruby on a Windows machine. On a UNIX-based operating system you would do it with various package managers; on Windows, Google suggested to use this package manager or that, some of which were reported to work on Windows with a few tweaks; just trying to install those package managers caused a cascade of incomprehensible errors. I could see that if I continued down this route, I would spend all day just trying to upgrade Ruby on Windows.

I consulted with Jennifer (Groove founder), and the other developer, and we decided that I won't try to run Jekyll. Indeed, all that Jekyll did in this application was to insert some common HTML sections into HTML pages. I could simply insert those sections myself. So I did. I made a copy of the original file for myself, and replaced Jekyll tags with HTML that was generated from them.

The Groove team at work: Jennifer (left), the founder of the Groove app, and the other developer in our team
The Groove team at work: Jennifer (left), the founder of the Groove app, and the other developer in our team. More pictures from SheHacksATX are in my photo gallery.

At the end of the day we, the two developers, finished our parts. There came the moment of truth when we each had to push our code to the Groove Github repository. I copy-and-pasted my code changes into the original page (the one with Jekyll tags), and pushed it to Github. My push triggered a build, which Jennifer had set up on Github to run automatically when new code is committed. That's when Mr. Hyde struck again. It said the build failed because the file I committed wasn't in the right encoding. It was already 6 pm in the evening, only 1-1.5 hours until the demos where all the hackathon teams were supposed to demonstrate what they had accomplished, and way too late to figure out why it was complaining about encoding. (I suspected that it was the Windows-style line endings in my file, while Jekyll might have expected Unix-style line endings, but I really don't know.) What to do?

So I committed my code "by proxy", i.e. via the other developer's laptop. She had a Mac, a Unix-based system, and I was pretty sure that a file committed by her would not be corrupted. I emailed her my files, she copied-and-pasted the changes into her file, and pushed it to Github. That's cutting a long story short. The long version of this story involves dancing the Github "dance" two people have to do when the other person's Git branch has fallen one or more commits behind the Github repository. It was also complicated by the fact that the other developer had made her own code changes to the same files. But after just an hour of copy-pasting and white-knuckled Githubbing, we fixed the build, and successfully pushed our changes to the repository. The day was saved, just in time to the pre-demo sushi and cheese snacks.

I have been primarily a Windows developer for a long time, and never understood why someone would need a Mac, except people who find Windows computers too difficult to use -- but surely that's not the case with developers. But this hackathon made me seriously consider that if I want to program outside of Windows stack, I need a Unix-based system. Ruby and Jekyll were just two examples; my earlier failure of getting Python to interoperate with Heroku toolbelt on Windows was another. Yes, I know, I can run UNIX on a virtual machine, but my Windows computer is already too slow even with what few programs I'm running on it. It's food for thought for the future.

But yes. This last part yet again highlights the importance of preparing for a hackathon -- at least setting up development environment for your project ahead of time, and testing it. But that's not possible not knowing what project you'll be working on. Perhaps it would be better if team / project assignments were determined at least a day or two before the hackathon, although that's not practical for every hackathon. I don't know of a good solution that would both preserve spontaneity, and allow people to prepare. Myself, I would err on the side of preparedness, because your day as a developer could be otherwise completely ruined if you waste it to find workarounds for configuration problems instead of coding.

It's a good thing that my years of programming experience enabled me to find those workarounds. Which brings me to my final observation. It's been observed time and time again, and this hackathon was no exception, that many women developers underestimate their skills. Some women who have been programming in the industry for 2+ years had wanted to sign up as beginners (the hackathon had separate pools of beginner coder and experienced coder tickets, so that every team could have a balance of both), but signed up as experienced because the newbie ticket pool drained faster. And that turned out to be the appropriate designation for them. At the end Girls Guild founder Diana remarked: many of you ladies signed up as newbies, but you are not new!

Monday, June 09, 2014

SheHacksATX: a hackathon done right

Hackathons can be a good change of pace for us developers because they force us to experience software development in a different way. At our day jobs we often work on a feature for weeks, because it needs to meet complex requirements that are often subject to many unknowns and last minute changes. But a hackathon can make it possible to implement not just one feature, but an entire prototype, or minimal viable product, in a day. It depends on how the hackathon is run, and just as much on preparation of the teams.

If your team has the right skills, or at least has researched in advance how to implement various moving pieces (for example, OAuth authentication using your chosen programming language), then a hackathon can give you a concentrated dose of accomplishment you often don't get at work. But if you approach a hackathon unprepared, and have to research those technologies as you're trying to use them, you will just spin your wheels. You might waste that day just scratching the surface of technologies you may or may not ever use. (I doubt that most projects started at hackathons ever get worked on again.)

Developers socialize in the morning before the coding starts. Left to right: Kathy, Stephanie, Ruby, Dallas, Nari
Developers socialize in the morning before the coding starts. Left to right: Kathy, Stephanie, Ruby, Dallas, Nari. More pictures from SheHacksATX are in my photo gallery.

At SheHackATX, a women-only hackathon that took place on April 26, 2014, teams had not been formed upfront. Developers were matched with projects at the beginning of the hackathon. Each project was a woman-run startup (most of them local to Austin) that needed programming help, such as to add some features to their app or website. In the morning, developers wrote down their preferences of apps to work on, and the owners picked programmers they wanted on their team. Hopefully everybody got at least their 2nd or 3rd wish.

Since the teams were formed on the spot, they could not coordinate and learn complementary skills in advance. So it was all the more impressive that half of the teams were able to accomplish the tasks that startup founders wanted in the the time provided (from around 12 to 7 pm of one day). Those startups were Girls Guild, Groove, Yoga Recipe, and Bound Round. In my opinion, they were successful because their founders were able to correctly estimate tasks that might take about a day, and went with small'ish, manageable enhancements for their applications; nothing grandiose.

An example of that would be Girls Guild, a website that matches girls who want to learn hands-on skills (e.g. chocolate making, jewelry making, leather working or photography) via apprenticeship, with "makers", i.e. experts in that area. Both the makers and the apprentices are girls or women. One of the features Girls Guild founders wanted to have added to their app had something to do with being able to delay a payment until another event occurs (the details escape me). They also wanted ability for a maker to schedule interviews with a prospective apprentice through the website, as opposed to a manually emailing back-and-forth. The Girls Guild team succeeded in implementing both features.

Girls Guild and Hearth teams at work
Girls Guild and Hearth teams at work. Sitting at the table, left-to-right: Bethany (developer), Diana and Cheyenne (Girls Guild founders). Standing behind them, the Hearth team: Nari and Monisha (developers) and Florence (founder). More pictures from SheHacksATX are in my photo gallery.

Bound Round coders didn't have time to implement a 3D spinning globe (in Javascript, I guess) that the owner wanted, but they implemented a zoomable map that shows different levels of info depending on the level of zoom. Quite impressive for such a short time. Yoga Recipe wanted to integrate their website with Facebook, Twitter, and Instagram; "integration" meant ability for yoga instructors to share the "recipes" (sets of instructions for yoga classes) on social media. They succeeded with Facebook and Twitter. They also implemented ability for yoga teachers to put together playlists for their classes using Spotify.

My team also did well with our application, Groove. More about it in the next blog post, where I'll talk about what we did and how we did it, highlighting the obstacles that a programmer might experience during a hackathon.

Some other startups set their deliverable for this hackathon to be not code, but ideas. The founders of Our Desired Future and Hearth came here with just some ideas for their websites -- some better hashed-out than others -- and asked for technical advice on how to best implement them. Our Desired Future wanted to put together a series of multimedia presentations to tell interactive stories about water usage and water resources of Texas; in case of Hearth, what the owner really needed was to winnow down a number of her eclectic ideas about promoting volunteering through gamification, to something that could serve as minimum viable product. The result of her brainstorming with her team was a landing page for the website. In the process, one of the people on her team concluded that her calling in life was product management. So in these two last cases the product wasn't tangible; the real product was refinement of initial notions into more concrete ideas.

Friday, November 29, 2013

SXSW 2013: blending bendy materials and bendy life

A talk by Ping Fu at SXSW 2013 blended, in an odd way, self-help advice and 3D-printing technology. The only thing in common between the two may be her own personality, which, like those raw materials shaped into an infinite collection of shapes, succeeded by flexibility and adaptability.

Ping Fu at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.

The title of her speech, "Digital Reality: Life in Two Worlds" ostensibly refers to the merge of physical and digital reality. She reviewed exciting things happening in three-dimensional scanning and printing technologies -- and her company, Geomagic, is among the players in the field. Standing on the stage in 3D-printed platform wedge shoes, she said you may be able to walk into a Nike store tomorrow, have their feet scanned, and pick up custom-made shoes tomorrow. You may also have custom-made prosthetics that would let artificial limbs look like real ones, "because currently they look like airplane landing gear". You just have to scan a soccer player's "good" leg, and print an artificial one based on that model. 3D-printing can produce filling for dental cavities, and repair tiles on NASA space shuttle -- two technologies that surprisingly (or not), are related. Preservation of historical artifacts is also a big application for 3D-scanning. Mount Rushmore took a hell of a long time to scan, but it was eventually done, and US Parks and Wildlife has a scan, said Ping Fu.

Ping Fu's 3D-printed shoes she wore at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.
Ping Fu's 3D-printed shoes she wore at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

On the other hand, life in two worlds can be a metaphor for Ping Fu's own life, that has certainly spanned two vastly different worlds. As a young child she was taken from her loving family in Shanghai during the Cultural Revolution, and raised in a camp. She was put through communist brainwashing, being forced to go up on stage and scream "I am nobody!" So she has no stage fright, she jokes. If anything saved her, it was her father's advice to be like a bamboo, that bends but does not break in the wind. She even made it the title of her book, "Bend, not Break".

A soccer player's 3D-printed prostethic leg: a slide from Ping Fu SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.
A soccer player's 3D-printed prostethic leg. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

Looking up this book on amazon.com, I saw that many reviewers accuse her of fabricating her life story. They claim her actual life was not nearly as horrible as described in the book, and that she might not have lived in a labor camp. I have no way to verify the claims of either side, though there is no doubt that the horrors of Chinese labor camps, where middle class children were sent for "re-education", actually existed. There is also no doubt that Ping Fu at some point immigrated into the US, and went from a person who knew just 3 English words, to a tech entrepreneur. And though she chose a technical field, she credits her love of language for her design skills. She may have known little of English, but she had a love of language all her life.

In China, she went to graduate school for journalism around the time when China's one-child policy started. It made not just subsequent-child births, but also pregnancies, illegal. When Ping Fu heard rumors that baby girls were being killed in the countryside, she went there as a journalist to investigate. There she witnessed "abortions" done via C-section in 8th or 9th month of pregnancy. For writing publicly about these atrocities she was put in jail, and was certain she would die there. Luckily, Cultural Revolution soon ended -- this was a few years before the Tiananmen Square -- and Ping Fu was released. (Again, I have no way of verifying how much of it is true.) Then the government gave her a choice: quietly leave the country, or be exiled to a remote corner of China. She chose to go to America, and took a crash course in English on the plane. By the time she landed in San Francisco, en route to the University of New Mexico, she already knew a few English words. Not enough to be accepted into comparative literature program, which was her first choice, but enough for computer science.

Mobile 3D-printer demonstrated during Ping Fu SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.
Mobile 3D-printer. This guy and another one with a similar printer walked up and down the aisles to let the audience take a look at the printers. They, however, did not demonstrate how it works. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

Myself, as someone who had a love for languages all my life, but didn't go into linguistics because I didn't think there were any jobs in it beyond school teacher, felt vindicated. There are not many people (or perhaps we're just not visible) who come into computer science not because of fascination with technology, but because we enjoy teasing out complex logical structures from the code as we do from human languages. And so when Ping Fu said that somebody back in the day suggested to her that she check out this new field, computer science, because it's a "language" that lets you make stuff, I thought that it was the same kind of thing that attracted me to the field of computing. Her life tale of a foreign student turned tech entrepreneur also has a special resonance to me because I, too, initially came to the US to go to graduate school. She, however, did not think she was a good programmer, because she lacked a science background, so she became a designer and project manager. Her secret to working with programmers is to ply them with Coke to keep their juices flowing. It must have worked, because at some point she hired Marc Andreesen, who developed Mosaic, and eventually licensed it to Microsoft to become Internet Explorer.

For a long time she didn't consider becoming entrepreneur, and when she finally started her company, Geomagic, people were still skeptical. Of the first seven employees all but her had PhDs, and 4 of them were mathematicians. People said you can't start a company with a bunch of mathematicians, as math doesn't make money. But Ping Fu replied that she liked to do impossible things, so she did it. A win for language nerds and foreign students everywhere!

Thursday, October 10, 2013

Some hackathons result in demos, some in questions

After finding out that the Devstack server we created during the walkthrough is not suitable for hosting web applications, I created a "plain" Rackspace server, installed Apache on it, and we proceeded to create a barebones web application. One of my goals was to get a clear idea how much progress a group of people could make on an application in a hackathon. The answer is, since we only got started after lunch (the first half of the day was taken up by the Devstack tutorial), and had until 4 pm to go: not much. But we got a little done.

Rackspace's Dana Bauer, Developer and Community Advocate at Rackspace

Dana Bauer, Developer and Community Advocate at Rackspace, one of the organizers of the hackathon. She and another Rackspace employee helped us greatly with the registration glitches. At the end she encouraged people to give demos, or, lacking a demo, to stand up and speak about what they did, accomplished, or learned during the hackathon. Though Dana gave people Legos for speaking, very few people (including two from our team) came up to speak. Only one person (Kesten, see below) gave a demo. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

I am no front-end developer, but nobody else in our team clamored for that role. In a strange coincidence, the other 4 women on our team came either from PyLadies (Python was their language of choice) or from scientific computing background, or the intersection of both. So I assigned the front-end developer role to myself, fully realizing that a web-page hand-coded by me would look rather... homemade. I needed some HTML and CSS templates that would make my creation look at least somewhat professional. Specifically, I needed a web form. I spent a good couple of hours looking for HTML/CSS templates for forms, and most sites were misleading: either they promised free templates, but every template you picked required you to sign up for a fee; some websites promised form templates, but instead of providing the HTML/CSS code they let you create and host a form in their domain, which wasn't what I wanted. After a long search I was able to find a form where I could tease out its HTML/CSS code. Interestingly, throughout my numerous Google searches, Bootstrap didn't show up even once. But when I mentioned my predicament to the people at the hackathon and on Facebook, two of them recommended Bootstrap. Indeed, Bootstrap has form templates. Face-to-face interaction can still be more useful than Google.

Kesten Broughton gives a demo of Picycles

The one and only product demo at the hackathon was given by Kesten Broughton, who created a 2D altitude chart as an addon for Google Maps "get directions" service using the Python beta API. His program was called Picycle, and was intended as a service for bicyclists who want to choose an optimal route, either minimizing or maximizing (if they want a good workout) the hills along the route. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

It took me 3 hours to put together a basic -- extremely basic -- front end to our application. There was no even a question of hooking it up to the backend. There was no time to write even a primitive web service that the front-end could call and display some results. One person in our group, more experienced with Python, finally got Twitter authentication to work in Python. This allowed her to query Twitter API programmatically by making requests from her Python code. Other of our members were just starting out with programming in general (in some cases switching from other professions), so I don't know what they did during that time. Perhaps they were going through Codecademy courses.

To our credit, other teams did not seem to fare better. Only one of the hackathon attendees had even a minimal product at the end to give a demo of, and he admitted he had been working on that product for 2 weeks already. His name was Kesten Broughton, and he created a 2D altitude chart as an addon for Google Maps "get directions" service using the Python beta API. His program was called picycle, and was intended as a service for bicyclists who want to choose an optimal route, either minimizing or maximizing (if they want a good workout) the hills along the route.

The lesson to be learned here is that to participate meaningfully in a hackathon requires quite a bit of preparation. If All Girl Hack Night is going to have a hackathon (I've been threatening to organize one, but always felt woefully unprepared), we would need to prepare in advance. For example, some us will have to be team leads who will have studied the API's of our choice (the APIs will also have to be decided ahead of time), and will be able to guide the teams so they could make tangible progress. That's the main lesson. Lots of advance decisions, planning what to implement, what programming languages and APIs to use, and a critical number of people who are familiar with those technologies and can guide others.

Sunday, June 30, 2013

Making sense of criteria for making sense of Javascript frameworks

How do you select the right parts from a talk about how to select the right technology? Especially if you haven't spent a whole lot of time working with any of the development tools that are being compared? Perhaps you just listen to what resonates. And so I did at the All Girl Hack Night presentation on how to select a Javascript framework that's right for you, by Justin Lowery from Cerebral Ideas. Justin compared Angular JS, his team's favorite, with two other popular Javascript frameworks, Backbone and Ember. So while an experienced web developer might be nodding their head sagely at the criteria Justin gave (which I put at the bottom of the page), I just pondered how web development today is still oddly plagued by the same problems as when I did it in 1999.

When you just can't separate presentation from business layer...

Justin Lowery (the presenter).
Justin Lowery (the presenter).

Back in 1999, when we wrote cutting edge web applications with (ahem) CGI and Perl, separating business logic from presentation seemed a distant dream, which my team at the time quickly gave up on. We wrote spagetti code where HTML was generated in a deeply nested tangle of Perl's ifs and fors. It's 2013, and it sounds like HTML still can't be made completely independent of business logic. And some people say you might as well embrace that, and pick a Javascript framework that lets you hook up Javascript to backend-generated HTML easily. According to Justin, that's one of big advantages of AngularJS.

Those Javascript-hating backend developers

This will let backend developers generate chunks HTML without ever touching Javascript. In Justin's observation, backend developers hate Javascript, but are much more friendly with HTML. Why they hate Javascript more than HTML is anyone's guess. Perhaps it's because backend developers are used to "proper" object-oriented languages, whereas Javascript kind of has objects without actually being object-oriented. It has this strange prototype inheritance, which is not like the "classical" inheritance that backend developers are used to. But I have been a backend developer for a long time, and I'm not averse to Javascript: I've been learning it eagerly in recent months, and I'm fascinated by some of its features like closures.

Freeform HTML versus generating the whole page from Javascript

Then again, there exist Javascript frameworks that not just let, but force you separate presentation from business logic; it's another question if those solutions cause bigger problems than they solve. I am talking specifically about ExtJS. ExtJS expects all the data from the backend to be returned as JSON objects via service calls. I'm not sure you could make it accept custom HTML even if you tried. At least that would be very hard, and it would violate another of framework selection commandments: "Choose a framework designed by someone who thinks like you, otherwise you'd be fighting it all the way". It would be hard to stick any custom HTML into an ExtJS application, because ExtJS does not "hook" into your existing HTML: it generates it all from scratch, from Javascript alone. Some pople don't like that. I suspect our presenter didn't either, because he considers it an advantage if a framework lets you write free-form HTML, like Angular does.

This ties into our next criterion.

Page load time: the "no blank page" criterion

Left to right: Annine, Yim, Angelina, Katie, and unidentified woman.
Left to right: All Girl Hack Night members Annine, Yim, Angelina, and Kate at the Angular JS presentation.

Allowing static HTML versus generating it all from Javascript is tied to another criterion: how fast the framework is. Mainly it means page loading time. Justin observed that a perception of loading time is not the same as the loading time itself. This criterion can also be summed up as "No blank page prior to JS parsing". If your application renders some HTML elements before it executes all the Javascript and populates fields with data, some HTML elements are already on the page even though some fields are initially blank. Even if loading the data into those fields takes 2 seconds, the user will still perceive this page as loading faster than a page that stays blank until it generates all the content, though that might take 1 second. In this case Angular obeys "no blank page" rule, whereas ExtJS -- you guessed it -- doesn't.

Opinionatedness: what does it mean?

The most mysterious criterion is probably "opinionatedness" of the framework. Perhaps you have to be an experienced front end developer to fully understand this concept, and I'm not. A Google search did not give me a crystal-clear understanding of what it means. Apparently, opinionated APIs are on the opposite end of a "scale" than REST APIs. Unlike REST, opinionated APIs don't treat URLs as resources. They are more like function calls that URLs: save(collection, key, value) versus http:///collection/{collection}/variable/{key} (this example is from an article Opinionated (RPC) APIs vs RESTful APIs). But from what I read, experts seemed to think that REST APIs are more intuitive than opinionated ones.

Clockwise from the left: Bridget, Patty, Ashley, Maryam, Simi, an IT guy from the company that hosts All Girl Hack Night; Justin Lowery (the presenter), Neelima, unidentified woman, Annine, and Yim.
Clockwise from the left: Bridget, Patty, Ashley, Maryam, Simi, an IT guy from the company that hosts All Girl Hack Night; Justin Lowery (the presenter), Neelima, unidentified woman, Annine, and Yim.

Opinionatedness of the framework figures into its learning curve. Justin said that Angular JS becomes harder to learn as the API becomes less opinionated. This seemed counterintuitive to me. Why would it be harder to program using RESTful API than one that consists of commands? Googling more about it, I found that AngularJS is called opinionated because it forces you to give your application a certain structure. If so, that can influence the learning curve in two ways.

Again, let's take ExtJS as an example. If you are writing an application that resembles the "Hello World" tutorial, it's easy to use this framework. You follow the steps, and the widgets on the page magically materialize and get populated by the data from the backend. So the learning curve does not seem too steep. But then you find out that a real-world application does not match the confines of the tutorial, and its logic often does not conform to the structure the framework imposes on you. That's when the learning curve becomes steep, as you have to find various backdoors and workarounds around the framework's assumptions. From that perspective, I'd say ExtJS is very opinionated, and this can make it hard to write real-world applications. This framework gives you prefabricated houses instead of individual bricks. But if it gave you just the bricks, a beginner wouldn't know how to stack them into an architecturally sound house.

A meta lesson is that it may be hard to know what concepts are and are not too vague for an overview talk (assuming that overview talks are introductory in nature). All Girl Hack Night has developers from all walks of life, from device driver writers to front-end, and I don't know that many non-front-end developers are familiar with the concept of opinionatedness. I will have to keep that in mind when creating my own presentations.

What kind of philosophy / methodology does the framework use to solve problems?
  • How is it architected?
  • Is the framework authoritarian or egalitarian?
  • Are all problems solved with Javascript?
  • Are problems solved with a bigger, more aggressive API?
How does the framework solve common problems of development?
  • Templating?
  • Data binding?
  • Routing?
  • Bootstrapping?
  • Data management?

How active are the creators in the community?

  • Do they have an active forum with many users?
  • Do they have stale pull requests or issues list?
  • Are they active in the community?
HTML-centric philosophy
  • HTML is intuitive for those that are non-Javascripters.
  • Strong separation of concerns.
  • Event binding is much easier.
  • Backend devs that hate JS have limited exposure to it.
  • Views are compatible with other frameworks, especially backend technologies.