samtc

Fly.io is not built on top of AWS. see https://fly.io/docs/reference/regions/

thttpd (http://acme.com/software/thttpd/), mini_httpd (http://acme.com/software/mini_httpd/) and micro_httpd (http://acme.com/software/micro_httpd/) from acme software worth taking a look at.

Is XBRL any good? I see more filings on EDGAR/SEDAR using that.

When you have remote hands and need to tell, over the phone, what to edit in BIOS of a specific Lenovo PC?

You can still access com.zone [1], you have to fill a form and have a phone call with verisign and you get access to a good old FTP with a daily dump.

Some other TLDs gives access through Centralized Zone Data Service [2]. Some deny access, like ca.zone.

But I get what you mean, it was really publicly available.

[1] https://www.verisign.com/en_US/channel-resources/domain-regi...

[2] https://czds.icann.org/en

It's a simple redis list containing JSON task. We have a custom Scrapy Spider hooked to next_request and item_scraped [1]. It check (lpop) for update/discovery tasks in the list and build a Request [2]. We only crawl max ~1 request per second, so performance is not an issue.

For every website we crawl we implement a custom discovery/update logic.

Discovery can be, for example, crawl a specific date range, seq number, postal code.... We usually seed discovery based on the actual data we have, like highest_company_number + 1000, so we get the newly registered companies.

Update is to update a single document. Like crawl document for company number 1234. We generate a Request [2] to crawl only that document.

[1] https://doc.scrapy.org/en/latest/topics/signals.html

[2] https://doc.scrapy.org/en/latest/topics/request-response.htm...

We monitor exceptions with Sentry. We store raw data so we don't have to hurry to fix the ETL, we only have to fix navigation logic and we keep crawling.

I maintain ~30 different crawlers. Most of them are using Scrapy. Some are using PhantomJS/CasperJS but they are called from Scrapy via a simple web service.

All data (zip files, pdf, html, xml, json) we collect are stored as-is (/path/to/<dataset name>/<unique key>/<timestamp>) and processed later using a Spark pipeline. lxml.html is WAY faster than beautifulsoup and less prone to exception.

We have cronjob (cron + jenkins) that trigger dataset update and discovery. For example, we scrape corporate registry, so everyday we update the 20k oldest companies version. We also implement "discovery" logic in all of our crawlers so they can find new data (ex.: newly registered company). We use Redis to send task (update / discovery) to our crawlers.

What's wrong about billing hourly? Sometimes a client ask me to check something that's not working as expected, it could take less than 10mins, I won't do it for free nor bill a week, I'll bill an hour. I'm happy and he is. If it takes longer I go with half-day, full-day increment.

I do document parsing/data grooming so it's a lot of tweaking/fix as the client do the Q&A on the data.

Actually I overbook myself and offload some work to reliable part-time employees (the client is happy to known that not only me but other people are working on the project).