Hacker News new | past | comments | ask | show | jobs | submit | soonnow's comments login

I just want to point out you are saving 3 characters on the last one while making it a fair bit harder to understand. fileName is perfectly fine. fName could be firstName, fileName, finalName, foundName...

fn or fqpn should be well understood too given the context.

You are right!

We used a small embedded db in our desktop product only for durability and SQL semantics. After we got multiple database corruptions we switched to a small file based store written in Java with simple DB semantics.

Looking carefully at what happens when data is lost we found that it's basically all recoverable.

This lead to an amazing performance, as data is flushed only when necessary. We flush only every 10 seconds now or when the write through cache is full.

My lesson learned from that is to carefully think about the actual requirements when it comes to transactions and having loose constraints may be the quickest way to speed up performance.

For many applications even a second or two of lost data may not be a big issue.


I think AI is going to be the driving force behind technological innovation for at least the next 10 years. And the US has that market cornered expecially with the CHIPS act. I think that will drive growth in the US and be more relevant than the reserve currency status.


Can I just say that aside from the presented facts. I really liked the reporting. It clearly explained what the study showed and what the studies didn't show.

I think science reporting should be more like that. It's ok to have an article that says well we found a link but we are not clear yet on what's the exact cause, but we know what's not the cause

Aside from the clickbait-y headline of course.


It's because the publication is well funded from other sources. It's not dependent on drawing lowest common denominator people in to view ads.


Anders Puck Nielsen talks about this in his video https://www.youtube.com/watch?v=jabKKr3pstU According to him the hallmarks of a Russian Flag operation are

1. Bad production quality and a clear message

2. Intense media coverage in Russia

3. Positive message about the Russian state

Literally none of these points were apparent here. It shows a weak Russian state, was covered only as so far as necessary and what the message would be was completely unclear. Don't hire mercenaries?


I'm using C# and Java professionally. I've been using for a long time while I'm newish on C#. Also I'm on a older version of .net vs. a modern Java. Honestly to me the language doesn't feel that great. It always feels sluggish, to work with, like I'm fighting against the language. And then there is the ecosystem, Spring Boot is just such a breeze to get a web app running with all the integrations you could ever want being just there. Add in Lombok and Apache commons and it's a real pleasure to develop in Java for me.


But these executables are quite huge, are they not?


Could it be any worse than an Electron application?


It offers the benefits of bitcoin (as a money transfer mechanism) without it's downsides.

For example it reduces the costs of international transfers as well as the ease of doing them. Swift transfers are not fun and easy to get wrong and fairly expensive.

And with Bitcoin you'd end up with the currency exchange twice and then the gas or transfer fees.

Also payment in bitcoin fluctuates so you'd have to write the invoices in BTC, which is not that useful. But companies writing invoices in USD are common enough.


I agree tThenhis is the best plausible benefit, but the question arises, why not just improve swift?

We see with the Russia sanctions that the US wants to maintain control of the currency, so if this comes to be it's going to be hobbled as a crypto currency to do just that, and by that point you may aswell improve the existing infrastructure.

This is never going to be the electronic version of a dollar bill. Untraceable, irreversible. It's not going to get to the point where you can get rid of traditional banks. It's going to be a niche tool for niche applications. That's not bad as far as it goes, but I don't think it's what anyone is think of when they're discussing this.


Your comment is fascinating especially since I've been thinking about digital transformation and what it means for businesses a lot, lately.

I would like to make one point that I would highly recommend in respect to a lot of people unhappy with Agile methodologies.

I suggest picking a method, let's say Scrum and really implementing it as recommended. Get a coach if necessary. Try to experience it first before making changes. I think for example the self organizing team has to be experienced rather than read.

Only once you have done it, by the book, start making changes and improve the process.

Don't fall into the trap of reading about Scrum, thinking well I don't need retrospectives they are dumb and do your roll your own thing.

Understand what Agile is, rather than follow some cargo cult interpretation.

This will lead to dark agile, or agile in name only, where you do waterfall but with daily standups.

Which I think explains a lot of the unhappiness people experience with Scrum.


> Rather than giving some finger in the air estimate, you need to explain that until the precise requirements are known, solution devised, and backlog estimated, you can't give a precise estimate

You make a lot of good points but I disagree with this one. I understand the need for business to know how much a project will cost, but I don't think there is any other way than finger in the air. Or rather looking at a project of similar scope and going from there.

The core of agile, for businesses, in my opinion is to deliver business value in the shortest amount of time. Changing requirements are not a bug but a feature of Agile. But you can't estimate for the unknown.

Let's say you are building an app for a bank that allows customers to leave comments on merchants as an option, three menus down. Turns out your customers love that feature and the bank decides to promote that feature.

This business agility is at the core of digital transformation and it should not be discussed away as not being part of the original requirements. Rather it should be embraced.

But you can't estimate the unknown. And I have in my life never seen a project that didn't have wild changes in requirements along the way.

So in my opinion you may as well throw out a number based on experience. Deep estimation based on Excel sheets and task completion times are not gonna improve on the result.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: