HN user

dpc_pw

1,827 karma
Posts9
Comments600
View on HN

It's easy to do things slowly, by the book, taking all the time in the world, while the world is waiting. It's part of the skill and mastery to know which corners to cut and which things are essential and which can be fixed later, and judge the effort to result ratio accurately.

LN situation is not perfect, but improved greatly last year.

With wallets like Breeze & Phoenix initial onboarding of new users to LN is quite painless because they offer in-flight inbound channel creation (for a tiny fee). So you can install and accept payment right away. Strike mobile app allows to easily fund your LN wallets with smallish amounts of money ($1-$1000) very quickly - just plug in your debit card.

I have been kicking tires paying for my coffee in LN-accepting Palo Alto coffee shop before the lockdown and it worked OK. But in other situations LN payments did have some problems (usually lack of receiving liquidity on the receiver end).

Another road to Bitcoin scaling for payments is using sidechains like Liquid. I haven't tried it myself yet.

But generally I agree that payments on Bitcoin are not critical right now, as it is becoming a trust-less collateral and saving device for bigger institutions for who $10 tx fees are irrelevant. It might however force smaller investors to try out sidechains/LN for casual payments.

Not sure what to you mean by 'fork&clone&submit&pr including 3rd party submodules'.

Sometimes a 3rd party library needs a fix, and you want to fork it, add your changes, and run with it like that until your changes land in the upstream.

Last time I had to deal with it was a PITA, because libraries were fully qualified, and now I wanted to make an override. In Rust I would use https://doc.rust-lang.org/cargo/reference/overriding-depende...

Seconded. Especially for Go, because it's mostly a lowest common denominator of language features it's not hard to write the code itself. The problem is that the module system is different and had plenty of changes along the years, What I would really like is an up to date "learn how to handle Go project in 30 minutes" tutorial (initialize new project with all best practices, add modules, publish, fork&clone&submit&pr including 3rd party submodules, test, CI, profile, debug).

Your laptop manufacturer doesn't care so it's buggy.

Buy a Thinkpad, Zenbook, Dell XPS, System76 laptop or some model known to have good Linux support next time.

Can't remember any problems like this in the last decade, but I always, always research Linux compatibility before buying any hardware.

Then when you gut the HTML for UI overhaul, if the functionality hasn’t changed,

How often website redesigns are only about html? Usually everything changes. New flows, new dialogs, new toolbars, new frameworks.

Often the web UI gets and Android UI and iOS UI siblings. Gets replaced altogether by a completely different UI, developed by a different team.

APIs change much less often, and can be shared between many UIs. You can also version them. How are you going to version a web UI? Like reddit with "turn back on classic look"? How long can you keep the old UI around just because you have 1000s tests around that use it.

but the idea that the tests are inherently brittle is wrong

I don't think so. Tests are great calcifyiers (check my blogpost about it if you want). If you test though your UI, you're calcifying your UI. The more you test though it, the more you calcifying it. No way around it.

https://dpc.pw/be-warned-tests-are-great-calcifiers

Around 2 thousands people die every day from heart diseases in the US, every day (635k annually). Not in extreme temporary conditions. That's a standard baseline, year after year like that.

I wonder how many lives would been saved if we had mandatory 30 minutes jogging sessions, fastfood lockdowns and vegetable subsidies.

I very dislike Cypress as well.

This even model is sooo confusing, clumsy and error-prone that writing any non-trivial test is a challenge. Whole product uses async/await or Promises and suddenly you have to switch to this baroque model just to write a test. Reusing logic between production code and tests is pretty much impossible.

Dynamic pages etc. often confuse cypress. I'm actually not a frontend developer, so I don't have a lot of insight while exactly that is, but I just know that it has been a huge drag.

Other than that, it would be OKish. Being able to test the UI is great, but I would advice everyone not to base the whole testing strategy on it. It's just too heavy, slow and unreliable. It doesn't not scale even moderately with the product growing.

e2e testing is better done on API level, IMO. You'll want redesigns, changes of UX, and suddenly your changes will require updating tests, which otherwise (if done on the API level) would require no modifications.

The OP is a long posts explaining how other people don't deserve their right to free speech and how that made them stop working on IPFS, and somehow you twist my frustration phrased as "just spare us" as saying I am trying to censor OP.

Yeah, whatever.

Fantastic. The pace of introducing such a change speaks loudly how good the engineering around teams and product involved must be.

I keep calling LinkedId "the saddest social network".

Create an account to list yourself in a CV catalog. Add connection with people you worked with to build credibility. Otherwise only ever open it when you're looking for a job. Otherwise you're risking getting cancer from looking at all that shameless self-promotion and posturing.

Main reason is - you're already proficient with Rust and enjoy using it.

I don't think there's much borrow checker issues in data analysis code. You `.clone()` everywhere, and it's still going to fly fast.

Some benefits:

* static typing niceness: language server, typo catching, some types preventing human error here and there etc. * expressing some ideas in a much more robust way * best in class tooling like package manager, rustdoc * hitting some unexpected not strictly data-analysis requirement is never a blocker * you can reuse your code, compile to WASM and embed in a page * performance of auxiliary code is never an issue * unlike Python, you can send it to another person and expect it to work just like it did for you * if it turns out that the "one-off" has to become more complex and serious, you don't have to throw away everything and start rewriting it "in more serious way"

Obviously (thought it seems not to you) free speech advocates like myself have no problems with different opinions being expressed. It doesn't mean other people have to agree with them. They can express they opposition and critique. And they don't even have to endure reading it.

In a way, I can't even understand how could you have confused the two (critique vs censorship).

One can work or not on something for whatever reason they want. Just spare us the long description of how other people are lesser human beings that should have their rights restricted for their own good, and how it's better this way.

Each address ownership has to be tracked in the PKI database, so there's a big pressure to limit their number.

Users don't have to use a self-owned addresses (planets). They can use moons which are delegated by the planets that issued them. The only limitation is that they are not fully independent (can't be resold, can be "canceled" by their planet) - just like an account on the website (just being run independently).

not to mention the 8-year-old daughters or 12-year-old daughters or 16-year-old daughters who need conditions on their digital freedom.

Nothing is really stopping them from using a moon issued by their school, university, a random website offering such an account, other family member or a friend etc.

Right now most of the world is using identities issues by Facebook, Twitter, Github etc. and not many people seems to mind. Also most people have their devices behind a NAT and also don't mind. That's exactly what using a moon would mean.

Having a planet is for more serious usage: where one wants to guarantee independence: proper identity that can't be canceled and so on. Akin to owning a root DNS name for your personal server. So 4 billion is probably even way more than we are going to need, even if world population grows x10.

If you have troubles getting into Hoon, the Hoon for Regular Programmers https://hackmd.io/IYd4RkpBQVqQTehmJeoxRw I made might be a good start to break the initial novelty barrier.

Yes, some aspects of Urbit are obscure, and the post is more aspirational than stating the current state of Urbit's codebase. But it is real, it works, it keeps getting better and is fun to use.

We weren't "rejecting most of candidates from Google" - I never said that. We were trying to pouch some really good people from them. The standards weren't the problem because we were hiring a lot of SWEs. Literally hundreds in few years. And companies like Amazon, Google, Facebook, etc. do have a large pool of above average pool of engineers. But it's not like just because someone works there makes them necessarily a hire. Same with schools.

Very similar experiences here. And I was interviewing people we've tried to pouch from best paying companies like Google, and had stream of newgrads from the top-notch schools. So I'm assuming candidates I've been dealing with were far above the average.

From what I can tell, there's a sea of people who can barely do anything with some hand-holding, then each level of knowledge, competence and experience you want to go higher, you have to slice the pool by 100. By the time you get to level where people can competently drive non-trivial projects, there's a severe shortage.

Hardware storage got really fast and cheap, but on the cloud it seems still super-slow and expensive. AWS's gp2 offers 3 IOPS/GB, and upgrading to something like io2 bleeds money really fast.

exceptions are the most convenient way of handling errors.

No, thank you. I'll keep my Result even if it was 200% slower.

Btw. Is there anything that prevents compiler from compiling error handling code the way exception throwing would be?