Just like we can’t search for LinkedIn headlines within LinkedIn or by X-Raying, we can’t search for Github Bios – either within Github or by X-Raying. However, we can search for LinkedIn headlines with Custom Search Engines (CSEs). It turns out that we similarly can search for Github Bios with CSEs!
We will be searching using Github X-Ray CSE. I will start off providing sample search strings to look within Bios, then, will give some explanations.
Here you go. “GitHub Bio contains”:
You can change the arguments, add keywords, and combine with other Google’s and Custom Search Engine operators specific to Github. As you may have noticed, you can use the asterisk * for ANDs and comma , for ORs in the special operators.
You Can Stop Reading Now and Go Enjoy the Searches 🔎🔎🔎
But wait, I also want to tell you that our tool Social List uses CSE operators in the background, and you won’t need to write any operators – just enter your terms and collect results. Here is what a search looks like:
Check it out if you haven’t.
Now, if you are wondering how I came up with the horrible-looking operator more:p:metatags-og_description: (and what is behind the search algorithm in Social List), read on.
CSE – Special Advanced Syntax
Special CSE operators depend on the website and structure of its pages. More specifically, operators depend on what Schema.org, Microformats, and other objects and values are (invisibly) included in the pages’ source code.
The general CSE search operator format is this:
– where data-field-name is an object like Person, data-value is a value, such as “org” (i .e. organization, a Person’s employer), and value is a string like “IBM”– finds pages containing the object Person with a matching “org” value.
Alternative syntax uses just p instead of pagemap:
Google.com doesn’t “understand” the more:… search syntax, but any Google Custom Search Engine does.
Objects and Values to Query
Objects (like Person of schema.org) and values (like employer=”IBM”) are invisibly included in web pages’ source code, in its part called “PageMap”. The big deal is – you can search within objects and their values using CSE operators. PageMap includes data following a variety of standards: Schema.org, Microformats, and others, and also a part called “Metatags”.
In our particular case, a GitHub Bio is stored in Metatags under the tag “og:description” (and is also duplicated under “twitter:description”). I found it by examining the JSON output from a CSE API call:
“twitter:title”: “garris – Overview”,
“twitter:description”: “Works at LinkedIn. Lives in Berkeley. Likes a nice hike. – garris”,
“og:title”: “garris – Overview”,
“og:description”: “Works at LinkedIn. Lives in Berkeley. Likes a nice hike. – garris”,
“dimension1”: “Logged Out”,
One last step and you will catch up with me on the subject. I am going to tell you how I obtained the JSON sample pasted above.
Running CSE API Calls
The APIs query CSEs from software code. It’s also possible to run an API call from your browser address bar.
Using the APIs requires obtaining a KEY (long coded string) from Google, available here. Input for an API call is a KEY, a CSE ID (a value you can copy from the Control Panel), a query string, and (optional) parameters.
You can run an API query from your browser in the following fashion:
– it will look like this:
An API call produces a JSON-formatted output page that you can browse to figure out the operator formats.
While you can examine a page’s structure with various tools (including CSEs themselves), these API JSON outputs provide “the” most accurate information for assembling CSE operators.
Querying structured info on the web is incredibly powerful. It may seem “too technical”, but that is mostly due to odd-looking strings of parameters that create that impression. (But you don’t need to “read” parameters, you just need to copy and paste.) Maybe one day, Google (or someone) will attach a friendly UI to Google CSEs’ structured web search. In the meantime, follow the links to search in Github Bios and definitely try Social List.