(Scale8 is a web analytics and tag management software like google analytics)
Just in case anybody else is in the same boat you can change the url in the code to the new one yourself.
simgle zip file is really the easiest solution for cases when the file must absolutely be compressed
Eg, http://nginx.org/en/docs/http/ngx_http_gunzip_module.html
even a big old russet only has, what, like 32 bites?
For some, if you slice them, you might even end up with only 16 bits.
If I'm not missing the point here, this was, and still is, about offering the simplest, most reliable solution over a long period. This is a near perfect example of how to do exactly that. No changing formats, no moving requirements, no big swings in frameworks, apis, or even standards. And most importantly, no breaking your customers business workflows.
No emergency change requests from the outage team that has to be impacted by other areas and fit into the infrastructure's teams maintenance windows and their capacity to address that.
No rebalancing of workloads because Jane had to implement (or schedule the task and monitor it) that change, Joe had to check and verify that the external availability tests passed, and Annick had to sign off on the change complete, and now everyone isn't available for another OT window for the week.
Or something.
At least one of us is confused about history here; are you really saying that circa 2008, HTTP compression would have been considered immature or unstable?
1 - save on cpu usage, compress once, serve many
2 - with zip you can have some rudimentary data integrity checks (unzip -t)
Nginx does this: https://docs.nginx.com/nginx/admin-guide/web-server/compress...
Last entry: the directive is `gzip_static on;`
Just guessing. I have no idea :-)
I used to work for a large, old company whose products you have all bought and buy (and which shall remain nameless) about 15 years ago. I worked on data interchange between the systems used for record keeping of said products and various other downstream or parallel systems (same purpose, separate system because left over from merger/acquisition).
So basically bulk data import and export. The product was 15 years old at that point. Data interchange was via various fixed width or delimited (CSV but the C might be some other character or character sequence) files transferred to and from various SFTP servers.
It's been a while but there were probably like 20 or 30 different such data sources or exports going in and out. Worked like a charm. I bet they're still used without much change. The frontend was being rewritten at the time (old one was in Smalltalk).
But we didn't stop there: this SaaS for our open source browser product is entirely built like this^0: behind the scenes it's a collection of bash scripts that implement and execute the business operation of the SaaS.
So basically, it's a command-line interface to the SaaS. Think of it this way, say I didn't have a website, with login, and "click a button to open a browser", but instead people would write me letters, send me cheques, or call me on the phone. Then I can serve their requests manually, at the command line.
The reason I made it like this was:
- clear separation between thin web front-end and actual business logic
- nice command-line interface (options, usage, help, clear error messages) to business logic for maintenance and support to jump on and fix things
- inheritance of operating system permissions and user process isolation
- highly testable implementation
Maybe this is dumb, but I really like it. To me it's an architecture and approach that makes sense.
I'm sure this is not new, and I think a lot of good quality operations must be built via this way. I highly align with the author's stance of the composition of a few simple command line tools to get the job done.
Perhaps we can call this "unix driven development", or "unix-philosophy backend engineering"
0: https://github.com/dosyago/BrowserBoxPro (saas coming soonish)
You're being a jerk, someone shared something they were proud of that's relevant to the discussion. What's the problem?
sure, a lot of the criticisms of CSV are true, but given the above constraints it's really hard to beat them.
Architects would complain ZIP isn’t a format conform to their specs for this purpose. Compliance would complain there needs to be a check that no private informatie leaked. Risk that I should prevent bad actors from downloading the file. Web people that I need an approved change to add stuff to the site.
Perfect usecase for bittorrent protocol imho. Funny thing is you can serve files with bittorrent protocol from Amazon S3 without any additional complexity or charges I think.
IIRC it was by far the most downloaded file on the ECB website. Tons of people, including many financial institutions, downloaded it daily, and used it to update their own systems.
IIRC #2 in the minutes immediately after the daily scheduled time for publishing this file, there was a massive traffic spike.
It was a conscious decision to make it a simple CSV file (once unzipped): it made it possible to serve the file reliably, fast, and with little resources needed.
The small team responsible at the time for the ECB’S public website was inordinately proud of the technical decisions made to serve this data in a single static file. And rightly so.