henvic

> Obtaining that number without authorization is already a crime. Accessing computers illegally to exfiltrate data is already a crime. Breaking into a physical safe in order to obtain a paper key is already a crime.

Sure thing. Hence, the importance of analyzing each case individually. If unauthorized computer access is used, sure thing a crime was committed. If someone created a wallet using a stupid wallet generator which used this website to "create" private keys, and someone else also had this silly idea, and someone deposited Bitcoin on a wallet created by this mean and and someone else took it, then no crime was committed.

Get real. You're not getting anyone's property if you discover a private key by accident that that a distributed blockchain with no owner accepts to transfer a token in a virtual wallet like that. We're talking about something non-fungible and not scarce.

Bitcoin's supposedly scarcity is a joke that doesn't make any sense whatsoever.

Except that they aren't taking anything from anyone. It's information. They might be copying it. And you might argue things like privacy count, and I'd be willing to hear your reasoning, but this shouldn't be like magic.

Yeah, someone was silly to pay hard earned money in exchange from useless tokens. It was a gamble. If the useless tokens get stolen, I'm sorry to say, but whoever paid for BTC already lost their wealth in the first place when they converted whatever they had before for it.

No. You're not stealing from anyone. It's decentralized and bits have no owner. If you say 'hey, here is my Bitcoin transaction' and others accept, and you just had luck to find a valid address, it is not the same as stealing. Bitcoin has no value.

Why a thief? Bitcoin is a silly idea based on scarcity that doesn't exist. If someone generated the right numbers by chance and had luck, I wouldn't say they'd be doing anything wrong getting whatever is there. It's not the same as stealing data, and is not the same as hacking into a banking system. It's decentralized, and there isn't the concept of real scarcity. It's not even hacking.

https://henvic.dev/posts/bitcoin/

Okay, now tell us you're a fiction writer for the next Fast and Furious! haha

Source?

my 50 cents:

I'd rather just use go vet + staticcheck. Way simpler, no complex configuration, and no license concerns :)

and then you can create a file like the following and add whatever analyzer provides value for your specific case (including this exhaustive), easily. Example: https://github.com/FiloSottile/mkcert/blob/master/analysis.g...

One of the reasons why I bought an Amazon Ring + its monitoring subscription is to have a redundancy if something goes wrong at home. It's just easier to sleep feeling safer knowing I can reach to its panic button in the control pad and get in touch with someone, in case of an emergency (the alarm system has internal battery and has redundancy using cellular data).

If your desk is on a slight slope fix your desk. LOL

I bet Objective-C developers would love the long lines of using it set to 22 degrees, though :)

They could've called it AWS Infinidash Mobile.

So you say your current position is to be rather carefully around anything by/from Google, but you trust Internet randos to build the binary of the browser you use?

Okay.

Fooled by randomness.

I never understood the love for them.

I recently posted this about my experience in migrating to PostgreSQL without anything of the sort of ORM... https://henvic.dev/posts/go-postgres/

We achieved a really great result doing so. In comparison, at my previous workplace, I was forced to use ORM, and everything was slower, awful, and hard to maintain for no benefit whatsoever. I'm not saying that it's 100% fault of ORMs, but at least 60%, for sure it was.

2. This is why I'm pushing so hard to keep things with plain SQL at work. So far, another team has experimental with squirrel (a SQL query builder) and it looks sane, but I myself wouldn't introduce not even this.

In my previous company, I was forced to use an outdated forked version of gorm. I'd just do my best to do anything else other than leading with databases there. Running the test suite took minutes, and to run way fewer test cases. It was a nightmare.

If you search the issues, you're going to find its maintainer saying he himself was using pgx now, as it was more capable.

I read your article and it has good points. I've added a section pointing to it just after I talked about interfaces, so other people can read it too.

It wasn't for testing. I wanted to expose only a limited set of *pgx.Pool that was "safe" to be used from any place. For example, without the Close() function that might be called during gracefully shutdown. I wanted to avoid exposing such things as kind of verification process, and that's a little bit silly.

oh, I also have defined database.PGX (https://github.com/henvic/pgxtutorial/blob/main/internal/dat...), which is a little more scarier. I'll get back about that too, but this one is perhaps even more useless, and there might be a better way to solve the issue I want to try to avoid with it.

Fair criticism. I'm the author, and I hate using interfaces like this, but didn't comment on it probably because I got used to it for this kind of thing.

The only reason why I defined inventory.DB (https://github.com/henvic/pgxtutorial/blob/main/internal/inv...) is to be able to test. Otherwise, I'd have skipped it.

I haven't read your article yet, but will do so later and get back to this subject and tell my opinion by the end of the day (on vacation, and need to hurry to catch the train!).

Thank you. I'll take a look in the upcoming weeks. It seems promising!

The rough edges I've faced are either edge case bugs or using more obscure APIs. Nothing too much worrisome.

I dislike this because you're assuming I've Docker on my system and you also have to deal with the startup time of the container.

I'd rather manage the database separately, and just have it configured for my tests to use them. This is why I kind of pushed towards a solution that didn't involve Docker.

Someone might think: "oh, but what [web] developer doesn't have Docker installed?" Well, I dod, but I always have problems with it, so I barely use it. I also prefer to run my database on a homelab server (https://henvic.dev/posts/homelab/) instead of on my laptop, especially because I also need OpenSearch or Elasticsearch running, and it's better if I just offload the performance|battery hit.

Funny is that when I joined the company back in February I was asked what computer I'd like to receive, and I really wanted a 13" MacBook with the new M1 processor, so I asked for it, but in the end I decided to go with Intel as I imagined using Docker would be very important.

It turns out that the M1 would work just as fine for the type of work I've been doing since then, with some minor exceptions.

Thanks! I love the concept of sqlc, but their support for pgx with its native PostgreSQL interface was quite limited when I checked. I imagine it's better nowadays, and will try again soon!

Yes. I'm barely using mocks. Most of the tests are integration tests against a real database.

I don't know the state of drivers for other ecosystems, but even though pgx has a few rough edges, the quality of the driver is quite good and the maintainer (jackc) is also super responsive and helpful.

I've had a positive experience with the project.

Yes! This is why I made sure to comment about SQLite briefly, and link to this page: https://sqlite.org/whentouse.html

Interesting. Thanks for the reference.

Thank you for the insight!

Interesting. I wonder if this can also be [ab]used to, say, deliver deltas of programs, so that you can have faster updates, but maybe it doesn't make sense.

https://en.wikipedia.org/wiki/Binary_delta_compression