Production-grade web scraping & AI research, written by someone who ships it.
I'm Aleksei. I build Apify actors and write code-heavy tutorials about web scraping, data extraction, and AI workflows. Every article includes runnable Python and real benchmarks. Currently 31 published actors (78 total in portfolio) with real users.
Recent posts
-
A Check You've Never Seen Go Red Isn't a Check — 6 Ways Mine Lied
At 18:31:38Z I asked one platform the same question over two routes. One said my newest post was from 19 August. The other said 17 minutes ago. Both 200, both valid JSON. Six measured ways a check lies about the world, four of them green and two of them red, plus a 103-line runner that makes every check fail a fixture before you trust its success.
-
Crash Recovery Is One Ordered Read, Not 24 Lookups
A worker died holding 24 queued writes and a journal with 2 lines in it. Asking the remote API about each of the 24 is the wrong shape of question: one ordered read of your own writes, diffed against your intents, answers all of them. Includes the run where my own high-water mark rule was wrong, and the arithmetic that caught it.
-
The DEV API Said My New Post Didn't Exist. It Was 15 Hours Stale.
A publish returned 201, the read-back said the post was missing, and the read-back was wrong: a shared cache served an answer older than the write. Read the Age header.
-
GitHub API Rate Limits: an Unauthenticated 304 Still Costs You a Request
The advice that a 304 Not Modified does not count against your GitHub API rate limit turns up in community answers and in my own earlier writing, and GitHub's own documentation states it five times on one page. Only two of those five sentences carry the condition GitHub attaches to it: the request has to be made while authenticated, and only one of the two names the Authorization header. Measured without a token on July 29, 2026, across four runs from one IP, and re-measured on August 19, 2026: three If-None-Match requests returned 304, 304, 304 with zero bytes of body, and x-ratelimit-remaining dropped by exactly 3, with x-ratelimit-used advancing one per response and no gaps. The ETag saved 5,996 bytes of JSON, roughly 1.4 kB on the wire once gzip is allowed (measured 1,423 bytes in July and 1,428 in August), and none of the quota. Also measured in the same runs: GET /rate_limit costs nothing, a plain GET costs 1, a 404 costs 1, and the search endpoints spend a separate bucket, documented at 10 per minute, rather than the core 60 per hour. One run of the probe costs 6 requests, 5 of them core; the July 29 investigation was four runs, and by the meter's own count that evening spent 33 of that hour's 60 core requests, plus one confirming run three weeks later. The authenticated case, the status code at exhaustion, the shape of the window and secondary limits were deliberately not measured.
Need a custom scraper or research solution?
Pilot pricing: $100 for 1 article or $150 for a 3-article series. Email spinov001@gmail.com with the topic and I'll reply within 24 hours.