HackerTrans
TopNewTrendsCommentsPastAskShowJobs

keule

no profile record

comments

keule
·3 ปีที่แล้ว·discuss
Ah thank you. I remember now. Still weird that this can also happen (and is allowed to happen) in an energy market.
keule
·3 ปีที่แล้ว·discuss
I understand put options and short selling, but how on earth can the price of a commodity sink below zero? How can you make a „sell“ order that is negative? Can someone explain please?
keule
·3 ปีที่แล้ว·discuss
To be clear: With short-term I meant the mentioned 6 hours of the article. They use those 6 hours to create forecasts for up to 10 days. I would think that the initial predictors for a phenomenon (like a hurricane) are well inside that timespan. With long-term, I meant way beyond a 14-day window.
keule
·3 ปีที่แล้ว·discuss
IMO a chaotic system will not allow for long-term forecast, but if there is any type of pattern to recognize (and I would assume there are plenty), an AI/ML model should be able to create short-term prediction with high accuracy.
keule
·4 ปีที่แล้ว·discuss
Thank you for sharing the unforeseen depths of a monolith :D
keule
·4 ปีที่แล้ว·discuss
> As in, "we have a PHP monolith used by all of 12 people in the accounting department, and for some reason we've been tasked with making it run on multiple machines ("for redundancy" or something) by next month.

Usually, your monolith has these components: a web server (apache/nginx + php), a database, and other custom tooling.

> Where would someone start ?

I think a first step is to move the database to something managed, like AWS RDS or Azure Managed Databases. Herein lies the basis for scaling out your web tier later. And here you will find the most pain because there are likely: custom backup scripts, cron jobs, and other tools that access the DB in unforeseen ways.

If you get over that hump you have done your first big step towards a more robust model. Your DB will have automated backups, managed updates, rollover, read replicas etc. You may or may not see a performance increase, because you effectively split your workload across two machines.

_THEN_ you can front your web tier with a load balancer, i.e. you load balance to one machine. This gives you: better networking, custom error pages, support for sticky sessions (you likely need them later), and better/more monitoring.

From thereon you can start working on removing those custom scripts of the web tier machine and start splitting this into an _actual_ load-balanced infrastructure, going to two web-tier machines, where traffic is routed using sticky-sessions.

Depending on the application design you can start introducing containers.

Now, this approach will not give you a _cloud-native awesome microservice architecture_ with CI/CD and devops. But it will be enough to have higher availability and more robust handling of the (predictable) load in the near future. And on the way, you will remove bad patterns that eventually allow you to go to a better approach.

I would be interested in hearing if more people face this challenge. I don't know if guides exist around this on the webs.
keule
·4 ปีที่แล้ว·discuss
You reminded me of the HikariCP library and it’s documentation: Clear and simple with references to other libraries trying to accomplish the same thing. It is not in the clojure space though.

https://github.com/brettwooldridge/HikariCP