I saw some previous post about this but i still don't understand. I have Three pages and i need to add all the user input IE car1, car2 , car3, and on the third page display a message of the totals. I would greatly appreciate any assistance. So to Recap i would need to add both values from the input on the two pages and display the total on the third.
The only way out it seems is using IsolatedStorage to store those values in the textboxes. Since there is not a huge amount of data you need to store, you can have a look at that. You can read up about it over here and about its usage over here
Related
I'm developing a map which loads 100 location pinpoints. To do so, I want to save double array of 100 rows and 2 column, which saves 100 locations.(latitude/longitude)
I am considering CMS or GraphQL-filesystem, but I don't know which to use. I want to to prioritize webpage load time, but if possible, it'd be nice to conceal my data.
Where should I store my data? Please give me advise. Other options are also welcome Thank you.
100 locations with latitude and longitude is still only a few KB of data. You do not need sophisticated data storage solutions for this.
The easiest way is to use your local filesystem i.e. an array and store it in a javascript file inside your project.
The next easiest way is to use any external solution that Gatsby allows. Take a look at their possible external sources.
I have a Google Spreadsheets containing about 50 rows, each of which has values in the first four cells of the row. I'd like to build something where I can click a button (or a cell?) and have it return one of these rows, selected randomly. I had assumed that this would be fairly simple in Google Sheets, but lots of searching online hasn't yielded anything useful.
I'm open to building something different (simple web app?) that will still do what I'm looking for.
Does anyone know how to do this, or even know some different language that I should be using as search terms?
If you insert a new ColumnA and populate it with:
=randbetween(1,100)
you might then use a formula like:
=query(Sheet1!A1:E50,"select B,C,D,E order by A limit 1")
and even have this update itself every minute or hour by selecting Recalculation in Spreadsheet settings..., otherwise on command with Ctrl+R.
HOWEVER, the result is effectively provisional until the sheet has saved.
You can use Google Apps Script, which will allow you to add the functionality you require into your spreadsheet. It uses JavaScript and the link I have given above will lead to some easy to follow examples. If you get stuck, then the Web Applications Stack Exchange site has many Q & A's on scripting Google's web apps.
If you reach the limits of Google Apps Script at some point, you may write your own application which interacts with your Google Sheet via their API. The APIs support multiple scripting and programming languages and searching Github will yield many open source libraries helpful for using Google Sheets and other Google Apps.
An alternative is with a relatively recent feature (Randomize range) under Data.
Assuming your data starts in A1, say name your "about 50 rows" by four columns and apply a formula such as:
=ArrayFormula(A1:D1)
The select your named range and click on Randomise range.
I am crating updated Gowalla application for windows phone mango. In that, in a particular area i need to populate around more than 1000 list items in a list. The minimum item count need to populate is 200. So i tried the ordinary implementation(list populating as a response of RX web request response ). Here the count of memory is mounting like Everest. How i can implement the same effectively. Will lazy loading would be a solution for this. If yes is the answer how i can implement this lazy loading in windows phone mango..
I think you really need to reconsider the design of the app, rather than tryign to solve this perf issue.
For a user to find an item by scrolling amongst 1000 others on a small screen is typically a very bad way of enabling the user to make the selection.
Other approaches which may be more suitable include: jump lists, paging, search, sub-dividing or grouping items.
The bottom line is that you're probably trying to solve the wrong problem in terms of creating the best app for the people actually using it.
I have a web app that uses Guids as the PK in the DB for an Employee object and an Association object.
One page in my app returns a large amount of data showing all Associations all Employees may be a part of.
So right now, I am sending to the client essentially a bunch of objects that look like:
{assocation_id: guid, employees: [guid1, guid2, ..., guidN]}
It turns out that many employees belong to many associations, so I am sending down the same Guids for those employees over and over again in these different objects. For example, it is possible that I am sending down 30,000 total guids across all associations in some cases, of which there are only 500 unique employees.
I am wondering if it is worth me building some kind of lookup index that I also send to the client like
{ 1: Guid1, 2: Guid2 ... }
and replacing all of the Guids in the objects I send down with those ints,
or if simply gzipping the response will compress it enough that this extra effort is not worth it?
Note: please don't get caught up in the details of if I should be sending down 30,000 pieces of data or not -- this is not my choice and there is nothing I can do about it (and I also can't change Guids to ints or longs in the DB).
Your wrote at the end of your question the following
Note: please don't get caught up in the details of if I should be
sending down 30,000 pieces of data or not -- this is not my choice and
there is nothing I can do about it (and I also can't change Guids to
ints or longs in the DB).
I think it's your main problem. If you don't solve the main problem you will be able to reduce the size of transferred data to 10 times for example, but you still don't solve the main problem. Let us we think about the question: Why so many data should be sent to the client (to the web browser)?
The data on the client side are needed to display some information to the user. The monitor is not so large to show 30,000 total on one page. No user are able to grasp so much information. So I am sure that you display only small part of the information. In the case you should send only the small part of information which you display.
You don't describe how the guids will be used on the client side. If you need the information during row editing for example. You can transfer the data only when the user start editing. In the case you need transfer the data only for one association.
If you need display the guids directly, then you can't display all the information at once. So you can send the information for one page only. If the user start to scroll or start "next page" button you can send the next portion of data. In the way you can really dramatically reduce the size of transferred data.
If you do have no possibility to redesign the part of application you can implement your original suggestion: by replacing of GUID "{7EDBB957-5255-4b83-A4C4-0DF664905735}" or "7EDBB95752554b83A4C40DF664905735" to the number like 123 you reduce the size of GUID from 34 characters to 3. If you will send additionally array of "guid mapping" elements like
123:"7EDBB95752554b83A4C40DF664905735",
you can reduce the original size of data 30000*34 = 1020000 (1 MB) to 300*39 + 30000*3 = 11700+90000 = 101700 (100 KB). So you can reduce the size of data in 10 times. The usage of compression of dynamic data on the web server can reduce the size of data additionally.
In any way you should examine why your page is so slowly. If the program works in LAN, then the transferring of even 1MB of data can be quick enough. Probably the page is slowly during placing of the data on the web page. I mean the following. If you modify some element on the page the position of all existing elements have to be recalculated. If you would be work with disconnected DOM objects first and then place the whole portion of data on the page you can improve the performance dramatically. You don't posted in the question which technology you use in you web application so I don't include any examples. If you use jQuery for example I could give some example which clear more what I mean.
The lookup index you propose is nothing else than a "custom" compression scheme. As amdmax stated, this will increase your performance if you have a lot of the same GUIDs, but so will gzip.
IMHO, the extra effort of writing the custom coding will not be worth it.
Oleg states correctly, that it might be worth fetching the data only when the user needs it. But this of course depends on your specific requirements.
if simply gzipping the response will compress it enough that this extra effort is not worth it?
The answer is: Yes, it will.
Compressing the data will remove redundant parts as good as possible (depending on the algorithm) until decompression.
To get sure, just send/generate the data uncompressed and compressed and compare the results. You can count the duplicate GUIDs to calculate how big your data block would be with the dictionary compression method. But I guess gzip will be better because it can also compress the syntactic elements like braces, colons, etc. inside your data object.
So what you are trying to accomplish is Dictionary compression, right?
http://en.wikibooks.org/wiki/Data_Compression/Dictionary_compression
What you will get instead of Guids which are 16 bytes long is int which is 4 bytes long. And you will get a dictionary full of key value pairs that will associate each guid to some int value, right?
It will decrease your transfer time when there're many objects with the same id used. But will spend CPU time before transfer to compress and after transfer to decompress. So what is the amount of data you transfer? Is it mb / gb / tb? And is there any good reason to compress it before sending?
I do not know how dynamic is your data, but I would
on a first call send two directories/dictionaries mapping short ids to long GUIDS, one for your associations and on for your employees e.g. {1: AssoGUID1, 2: AssoGUID2,...} and {1: EmpGUID1, 2:EmpGUID2,...}. These directories may also contain additional information on the Associations and Employees instances; I suspect you do not simply display GUIDs
on subsequent calls just send the index of Employees per Association { 1: [2,4,5], 3:[2,4], ...}, the key being the association short id and the ids in the array value, the short ids of the employees. Given your description building the reverse index: Employee to Associations may give better result size wise (but higher processing)
Then its all down to associative arrays manipulations which is straightforward in JS.
Again, if your data is (very) dynamic server side, the two directories will soon be obsolete and maintaining synchronization may cost you a lot.
I would start by answering the following questions:
What are the performance requirements? Are there size requirements? Speed requirements? What is the minimum performance that is truly needed?
What are the current performance metrics? How far are you from the requirements?
You characterized the data as possibly being mostly repeats. Is that the normal case? If not, what is?
The 2 options you listed above sound reasonable and trivial to implement. Try creating a look-up table and see what performance gains you get on actual queries. Try zipping the results (with look-ups and without), and see what gains you get.
In my experience if you're not TOO far from the goal, performance requirements are often trial and error.
If those options don't get you close to the requirements, I would take a step back and see if the requirements are reasonable in the time you have to solve the problem.
What you do next depends on which performance goals are lacking. If it is size, you're starting to be limited if you're required to send the entire association list ever time. Is that truly a requirement? Can you send the entire list once, and then just updates?
For context: this is an HTML app, with little or no browser side JavaScript. I can't easily change that so need to do this on the server.
CouchDB is built to not have side effects. This is fair enough. But there seems to be no method that i can conceive of with shows, views, lists to change what is shown to a user with subsequent requests, or based on user objects, without writing data.
And can a get request for document result in the creation of a new record? Im guessing not as that would be a side effect.
But if you can, you could just create a log and then have a view that picks an advert firm a set of documents describing adverts which is affected by the change in the log when a previous ad was shown.
I'm not actually going to show adverts on my site, I'm going to have tips, and article summaries and minor features that vary from page load to page load.
Any suggestions appreciated.
I've wrapped my head around how to work with the grain for the rest of the functionality I need, but this bit seems contrary to the way couchdb works.
I think you're going to need a list function that receives a set of documents from the view and then chooses only one to return, either at random or some other method. However, because you're inside a list function you gain access to the user's request details, including cookies (which you can also set, btw.) That sounds more like what you want.
In addition, you could specify different Views for the list function to use at query-time. This means you could, say, have only random articles show up on the homepage, but any type of content show up on all others.
Note: You can't get access to the request in a map/reduce function and you'll run into problems if you do something like Math.random() inside a map function.
So a list function is the way to go.
http://guide.couchdb.org/draft/transforming.html
Look into the various methods of selecting a random document from a view. That should enable you to choose a random document (presumably representing an ad, tip, etc.) to display.