Minor grammatical changes

This commit is contained in:
Simon Brooke 2020-02-28 12:41:05 +00:00
parent 63ebaa28d0
commit 13440b616f
No known key found for this signature in database
GPG key ID: A7A4F18D1D4DF987

View file

@ -8,7 +8,7 @@ So there were clear routes to several of the parts of this problem:
2. If you want a spreadsheet that is live on the Internet, [Google Sheets](https://developers.google.com/sheets) are a very good way to go; 2. If you want a spreadsheet that is live on the Internet, [Google Sheets](https://developers.google.com/sheets) are a very good way to go;
3. Google Sheets allows export as Comma-Separated Values, and CSV is a very easy format to parse. 3. Google Sheets allows export as Comma-Separated Values, and CSV is a very easy format to parse.
I needed to do this quickly, so I started in my comfort zone, using Dmitri Sotnikov's [Luminus](framework) and mixing in the [Day8 re-frame](https://github.com/day8/re-frame) framework, in order to have a lot of built-in functionality client side. The joy of the [Clojure](https://clojure.org/) development tools is that getting a working system is as easy as typing I needed to do this quickly, so I started in my comfort zone, using Dmitri Sotnikov's [Luminus framework](https://luminusweb.com/) and mixing in the [Day8 re-frame](https://github.com/day8/re-frame) framework, in order to have a lot of built-in functionality client side. The joy of the [Clojure](https://clojure.org/) development tools is that getting a working system is as easy as typing
lein new luminus geocsv +re-frame lein new luminus geocsv +re-frame
@ -50,6 +50,6 @@ All three variants have merits. The first pulls the data directly from Google Sh
## One more time with feeling ## One more time with feeling
One of the reasons why I get hammering at this problem was that I felt it would make a really useful extension for my wiki engine, [Smeagol](https://github.com/journeyman-cc/smeagol). I've integrated the JavaScript version, geocsv-js, and in doing that I've solved a number of problems. Firstly, the look and feel and content of Smeagol pages is flexible and easily configurable by the user, so it doesn't take a geek to set up a page with the content you want and a map of the data you want to show. Secondly, the Smeagol engine, because it sits server side, can pull data from remote sites, and because it doesn't interpret that data, there's no significant risk in doing that. Thirdly, again because it sits server side, it can deal with the issue of unknown images - and, because it's a wiki engine targeting less technical users, I've deliberately made it very graceful about how it does this. One of the reasons why I kept on hammering at this problem was that I felt it would make a really useful extension for my wiki engine, [Smeagol](https://github.com/journeyman-cc/smeagol). I've integrated the JavaScript version, geocsv-js, and in doing that I've solved a number of problems. Firstly, the look and feel and content of Smeagol pages is flexible and easily configurable by the user, so it doesn't take a geek to set up a page with the content you want and a map of the data you want to show. Secondly, the Smeagol engine, because it sits server side, can pull data from remote sites, and because it doesn't interpret that data, there's no significant risk in doing that. Thirdly, again because it sits server side, it can deal with the issue of unknown images - and, because it's a wiki engine targeting less technical users, I've deliberately made it very graceful about how it does this.
So now, instead of just a map on a web page, you get a whole, richly editable website, with existing extensions to integrate sophisticated data visualisation and photograph galleries as well as maps. And the cost of this? Surprisingly little more. A Smeagol page with one map uses exactly the same memory on the client as a geocsv-js page with one map, because Smeagol now only loads JavaScript for extensions actually being used in the page, and almost all of its own functionality runs server side. But even server side, the cost is not very much greater than for the full fat geocsv implementation - the deliverable jar file, which offers far more functionality than geocsv, is only 88 megabytes. Considering how much more usability and flexibility this offers, this is the version of geocsv I'd now offer, if someone came to me with the same problem. So now, instead of just a map on a web page, you get a whole, richly editable website, with existing extensions to integrate sophisticated data visualisation and photograph galleries as well as maps. And the cost of this? Surprisingly little more. A Smeagol page with one map uses exactly the same memory on the client as a geocsv-js page with one map, because Smeagol now only loads JavaScript for extensions actually being used in the page, and almost all of its own functionality runs server side. But even server side, the cost is not very much greater than for the full fat geocsv implementation - the deliverable jar file, which offers far more functionality than geocsv, is only 88 megabytes. Considering how much more usability and flexibility this offers, this is the version of geocsv I'd now offer, if someone came to me with the same problem.