ak39

Yip, this was impressive. Only a copy & paste into VSCode (Windows) revealed the rectangle around the "c" in the second line.

Impressive.

Thank you. Also, what database was in use?

Thanks for the easily understandable TLDR!

And here I thought Snowflake was for the data model!

Indeed. It's by no means "straightforward"

I didn't say we should ignore splits. To reiterate: most third-party data providers include splits by restating historical prices. This only works if you want to analyse performance at individual stock level by ignoring holdings. But if you want to do performance analysis for your own portfolio of stocks, relying on restated prices is incorrect.

Eg. If you bought say 10 stocks at the old price, you cannot take the restated historical price with your 10 stocks and you cannot take the units held of 10 stocks with the new prices. You have to account for this via transactions to increase your holdings (for splits) by leaving the prices historically the same.

Valuations are straightforward in a world without corporate actions like splits, consols, dividends etc.

Most (all?) data providers rerate historical prices after corporate actions that affect prices and this is not really the correct way to do continuous valuations using the restated prices.

ORMs and NoSQL were a direct result of the desire to have an object-oriented data worldview in a programming landscape dominated by OO languages. They were not introduced because programmers didn’t want to learn SQL (implying incompetence etc).

Node might not, but Javascript (even on the server) will mostly be.*

* assuming that the 100 years hyperbole is accepted

Please don't stop there! How did the conversation go? How did he convince you that you won't be double-crossed?

Terminating a bus factor 1 employee is not the problem. The real problem is not recreating BF1 reloaded with the new hire. Even a team of two is not completely ideal.

Many, mostly small, companies just cannot justify an IT department to mitigate Bf1/2 risks. Also, most times this bus factor problem manifests in non-IT jobs too: sales, contract law, accounting functions.

Small companies need to first become big companies to afford de-risking from BF1. Part of the growth story really.

Nice!

Finally: https://youglish.com/pronounce/been/english?

"Been" pronounced "bin" is slowly moving to "ben" (mostly in the US usage).

LOL. What did this comment (no pun!) do for your HN karma points?

SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that we have a single place for language-agnostic encapsulation of data procedures.

Paul MM Cooper's podcasts and video essays on YT are excellent. There's info on Mansa Musa in this episode: https://www.youtube.com/watch?v=GfUT6LhBBYs

A whole new generation of developers is learning what the previous generation termed "briefcase applications". When client-server applications were the thing late 90s and early 2Ks, internet speeds were a serious limitation. This forced many architectures to work with "local-first", disconnected dataset, eventually-synchronised desktop applications. Microsoft ADO famously touted the "disconnected dataset" for this after Borland's "client dataset" pioneered this concept for the Windows desktop. Eventually even Java got disconnected datasets. All these techs more than two decades ago had real practical problems they solved: one of them I worked on involved collecting water flow data from several thousands of rivers in Southern Africa. Hundreds of users had mobile laptops that fired up desktop apps with authentication and business rules. Users then came back to head office to synchronise or used a branch with network to upload.

They worked and they were necessary.

Things changed when internet connectivity eventually became cheap and ubiquitous and the complexity of developing such applications then didn't merit the effort.

Now, the swing back to "local-first" is mainly for user-experience reasons. The same theoretical complexities of "eventually synchronised" that existed for the "briefcase app" are still present.

Is the complexity worth it though?

Slightly off-topic:

The top Reddit response cites some good reasons why this may be so. The writer mentions they needed to move from Node to improve "throughput" (and .NET was suggested). In what way would .NET improve performance that Node can't satisfy. (Isn't Node's worker thread sufficiently close to ASP.NET, ISAPI multi-threaded scenarios?)

Does it handle stock splits, consolidations, dividends etc? Calculating returns (basically tracking growth) is a non-trivial problem.

Always use surrogate primary keys. Use alternate keys (AK) for your "natural keys". Modify the AK business rules as and when needed. There are several advantages to using meaningless random integers, sequential integers or UUIDs as your table's PK. The most important one is that if the PK participates (or is expected to participate) as a foreign key in other tables, it's crucial to us a design where you never ever have to change the PK!

I’ve never truly used DISTINCT and felt comfortable for using it. Always felt using it revealed a design smell in my query. (Been doing SQL for 30 years and still!)

2019?

"Probably the fundamental problem here was a sub-optimal schema, but sometimes you're just working with what you've got. Plus a commenter on Reddit pointed out that if we used pure SQL functions instead of PL/pgSQL, we'd also have seen better performance then."

So, would the better advice not have been to use simpler SQL instead of complex recursive statements, instead of taking a drastic approach to abandon ship (move logic to a completely new layer)?

Also, if you're doing string concats manually for your Json, this might cause some overhead for larger objects. ??

You can horizontally scale the database directly.

"2. Push all your application logic into Postgres functions and procedures"

Why are functions and procedures (an abstraction layer at db layer) considered harmful to performance when the same abstraction layer will be required at the application layer (introducing out of process overhead and possibly network traffic)? I don't agree with this advice. (Or I don't understand it.)

A few "give it time" replies is emblematic of the culture of "chalega" ("it will do") in Indian commerce. This is hardly what Apple will tolerate.

100%. My projects are DevExpress heavy.

Embarcadero insane pricing of Delphi is the reason I haven't continued beyond my old version Xe2. I guess they are making hay while the sun shines with the locked-in customers.

Not being snarky: what's the risk of using UUIDs for session tokens if they are created by the server/db and are always verified by server (db) (for authorisation etc)?

Same. Do you have any guess when this is likely going main branch?

“That’s one heck of a nurse” after hitting the Nuke button which was right next to the “Nurse” button.

Can you guess which music video that’s from?