Multiple indexes in XPath in Google Sheets importxml - xpath

I'm using some data from Bloomberg into a Google spreadsheet, two of the lines read as:
=importxml("https://www.bloomberg.com/quote/ELIPCAM:BZ";"(//span)[28]")
=importxml("https://www.bloomberg.com/quote/ELIPCAM:BZ";"(//span)[31]")
However, there is a large number of importxml and importhtml over all, and many of them querying the same web page. As a result, too many cells are in eternal "Loading..." state. Google even presents the message:
"Loading data may take a while because of the large number of requests. Try to reduce the amount of IMPORTHTML, IMPORTDATA, IMPORTFEED or IMPORTXML functions across spreadsheets you've created."
So, is there any way to merge requests as above? For sure I could open a new tab and import everything (i.e. use only "(//span)" for the query), but other than being messy, I'm afraid I'd still be querying more than I need. ideally, there should be some query for multiple numbered nodes, something like "(//span)[28,31]", but this obviously returns an error.

Try it this way and see if it works:
=importxml("https://www.bloomberg.com/quote/ELIPCAM:BZ","(//span)[position()=28 or position()=31]")

use | between your XPaths like:
=IMPORTXML("https://www.bloomberg.com/quote/ELIPCAM:BZ",
"(//span)[28] | (//span)[31]")

Related

Optimization of Google Sheets loading speed

Maybe someone can shed any light, personal experience or reference to official documentation.
Suppose, I have a Google Spreadsheet, which I connected to other Spreadsheets by using IMPORTRANGE. I noticed that my receiving Spreadsheet started loading slower than normal. Are there any tricks for optimizing the loading speed? For example, does it make any difference if I:
Use IMPORTRANGE less frequently by loading the data (let's say, once) to a separate tab, and then query that tab internally from within the same spreadsheet?
or
Use IMPORTRANGE frequently in multiple cells and run Query for each cell individually, and avoid having a large dedicated tab that gets all the info first?
Use IMPORTRANGE less frequently by loading the data (let's say, once) to a separate tab, and then query that tab internally from within the same spreadsheet?
definitely the right approach to gain performance speed

Showing multiple metrics with conditions and calculation in visualize tool in Kibana

I want to create a table in the Visualize tool in Kibana where I show several metrics with condition and calculcation. I have created a generic example in excel, see below. I know the basics. On how to produce the first two columns, be the other ones are harder. I tried looking into adding JSON input with adding another Count and adding a script, but i dont get it to work unfortunately. Any ideas?

Google Script Performance and Speed Comparison with Google Sheet Formula

I have one thousand Google Form Responses spreadsheets. These are students answer sheets. I built a spreadsheet and pull data (TimeStamps and scores) for each student by using Google Spreadsheet formulas (INDEX MATCH and IMPORTDATA). Each student has different pages. But, it takes too many times and sometimes causes some source sheets being unresponsive (I think because of heavy formula usage). My questions;
Is it possible to do the same thing (pulling data if matches student's name from one thousand spreadsheets) by using Google Script?
If possible, which ones (Google Spreadsheets with formulas or Google Script) performance is better?
By looking your answers I will decide to begin learning Google Script or not.
Thanks in advance.
Is it possible to do the same thing (pulling data if matches student's name from one thousand spreadsheets) by using Google Script?
Yes, it's possible.
NOTE: Bear in mind that Google Sheets has a 5 million cell limit, so if your data exceeds this limit, you should consider to use another data repository.
If possible, which ones (Google Spreadsheets with formulas or Google Script) performance is better?
Since most Google Sheets formulas are recalculated every time that a change is made in the spreadsheet that holds them, it's very likely that Google Apps Script will be better when using Google Sheets/Google Apps Script as database management system because we could have more control over when the database transactions will be made.
Related
Measurement of execution time of built-in functions for Spreadsheet
Why do we use SpreadsheetApp.flush();?
Both does the same thing. Both will be as intensive on your computer. My advice would be to upgrade your PC!

Combining Twitter JSONs in Ruby

I'm trying to create a feed to display the combined results of 3 queries to the Twitter API, since there seems to be no way to get what I want with one API call (2 user timelines and 1 search result for a hashtag). I want the results to be sorted by date so that the most recent appears at the start (just like when I get a result back from the Twitter API).
How can I combine these 3 JSONs (from the Twitter API), whilst maintaining the date order?
Thanks
there are several ways of doing this. i would probably persist all the stuff in a database.
that comes with several benefits:
first of all, caching is super easy, you can fetch the data from your own database until it gets stale.
secondly, databases are reaaaaaaaaaaaaaaaaly good at sorting and all this date shizzle. it's hard doing this manually and usually slow. i tend to mess it up all the time, so i let the database do the job for me.

Grid - When should you switch from html to server side table processing?

,This question is likely subjective, but a lot of "grid" Javascript plugins have come out to help paginate and sort tables. They usually work in 2 ways, the first and simplest is that it takes an existing HTML <table> and converts it into a sortable and searchable information. The second is that it passes info to the server and has the server select info from the database to be displayed.
My question is this: At what point (size wise) is it more efficient to use server-side processing vs displaying all the data and have the "grid plugin" convert it to a sortable/searchable table client-side?
Using datatables as an example, I have to execute at least 3 queries to get total rows in the table, total filtered results for pagination, and the filtered results to be displayed for the specific selected page. Then every time I sort, I am querying again. Every time I move to another page, or search in the table, more queries.
If I was to pull the data once when the client visits the page, I would be executing a single query, and then formatting and pushing the results to the client all at once. This increases the page size, and possibly delays loading of the page once it gets too big. The upside is there will only one query, and all the sorting, searching, and pagination is handled by the plugin, so no waiting for a response and no more queries.
If I was to have just a few rows, I imagine just pushing the formatted table data to the client at the page load would be the fastest. But with thousands of rows, switching to server-side would be the most efficient way.
Where is the tipping point? Is there a tipping point, or is server-side or client-side the way to go 100% of the time?
The answer on your question can be only subjective. So I explain how I personally understand the problem and give me recommendation.
In my opinion the data with 2-3 row and 3-4 column can be displayed in HTML table without usage any plugin. The data you display for the user the more important will be that the user will be able to grasp the information which will be displayed. So I think that the information for example have to be good formatted and marked with colors and icons for example. This with help to grasp information from probably 10 rows of data, but not much more. If you just display table with 100 rows or more then you overtax the user. The user will have to analyse the data to get any helpful information from the table. Scrolling of the data makes this not easier.
So I think that one should give the user comfortable or at least convenient interface to sort and to filter the data from the table. The exact interface is mostly the matter of taste. For example the grid can have an additional filter bar
For filtering and even for sorting of the data it's important to have not pure strings, but to be able to distinguish the data types like integer (10 should be after 9 and not between 1 and 2), numbers (correct interpret '.' and ',' inside of numbers), dates (3/20/2012 should be grater as 4/15/2010) and so on. If you just convert HTML table to some grid you will have problems with correct filtering or sorting. Even if you use pure local JavaScript data to display in grid it would be important to have datasource which has some kind of type information and then to create the grid based in the data. In the case you can gives date as JavaScript Date or as ISO 8601 string "2012-03-20" and in the grid display the data corresponds the specified formatter as 3/20/2012 or 20-Mar-2012.
Whether you implement filtering, sorting and paging on the server side or on the client side is not really important for the user who open the page. It's important only that all works quickly enough. The exact choose of the grid plugin, the filtering (with filter toolbar or external controls) and styling of the grid depend on your taste and the project requirements.

Resources