Zr40
Location: Netherlands
Remote: Yes (occasional travel is OK)
Willing to relocate: Unlikely
Technologies: Python, Rust, PostgreSQL, can work with most other tech
CV: See LinkedIn
Email: [email protected]
LinkedIn: https://www.linkedin.com/in/~zr40/
I'm an experienced Python backend developer and PostgreSQL DBA with a bit of SRE on the side. Looking to move into Rust development professionally (please, no Blockchain/Web3), although Python is acceptable too.I tend to gain an excellent understanding of the systems I work on. This enables me to execute complex tech projects successfully, such as:
* migrating a large Python 2 project to Python 3
* implementing strong type checking across the entire project, while fixing pre-existing typing issues
* tracking down weird bugs, performance problems, and memory leaks, and fixing their root causes
* removing technical debt
* increasing productivity for entire teams
* rapid incident analysis and response
I strongly prefer written communication due to spectrum issues. If you require frequent verbal/in-person communication, I will not be a good match. Brief status calls are fine.Deregistration[1] has been supported since November 2014.
Same for me. It is accessible from my home network (AS206238) and from public transport wifi (AS202189), but not from any other network I can currently access (AS201975, AS50266).
> * I want to call my friend in Germany. What time is it for her? I guess I'm UTC-7 and she's UTC+1, so she's 8 hours ahead of me. I know that everybody around the world typically wakes up between 6 and 9 AM and goes to sleep between 8 PM and midnight, and she's an early bird, so she should be awake.
> Without timezones:
> * I want to call my friend in Germany. It's the same time here as there. It rises at 13:00 here, but she's a quarter of the way way around the world. I have to look up their typical waking hours. She's an early bird, so is she on the early side of that, likely. What time does the sun rise there? How much does that change over the seasons?
This is actually the same thing. In both cases you have to know or look up that there's an 8 hour difference between the two of you.
The bits about the seasons and being an early bird apply equally to both cases, so it's not really relevant to the comparison.
> In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, password_verify() function may accept some invalid Blowfish hashes as valid. If such invalid hash ever ends up in the password database, it may lead to an application allowing any password for this entry as valid.
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0567
Money isn't stored in other assets. It's transferred from the buyer of an asset to the seller. It doesn't cease to exist simply because you traded it for stocks (or gold or anything else). Now the seller has to deal with the consequences of holding the money you previously held. A rational trader factors in the costs of money when they price assets, therefore one doesn't avoid those costs by trading money for other assets.
Apple has always clearly stated that this is perfectly fine on websites, just not in apps.
> Employs a passively managed, full-replication strategy.
[1]: https://advisors.vanguard.com/VGApp/iip/site/advisor/investm...
Not that this matters here; the top level comment measured requests per second, not bytes per second. If anything, the smaller response for http would give http an advantage in this comparison.
When measuring on one of my servers that exposes both HTTP and HTTPS, there doesn't appear to be any significant difference.
HTTP:
% wrk http://hostname
Running 10s test @ http://hostname
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.11ms 5.42ms 62.85ms 96.08%
Req/Sec 1.10k 224.03 1.31k 87.04%
17703 requests in 10.01s, 6.89MB read
Requests/sec: 1768.57
Transfer/sec: 704.58KB
HTTPS: % wrk https://hostname
Running 10s test @ https://hostname
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.75ms 4.09ms 50.37ms 96.48%
Req/Sec 1.10k 228.86 1.34k 79.35%
17014 requests in 10.01s, 8.39MB read
Requests/sec: 1700.32
Transfer/sec: 858.38KB