No it's not. Actively managed funds will in most cases not beat an index fund. Investorers have learned this and has chosen passive funds. This together with more people investing in funds has increased the size of passive ETFs in the market.
They don't beat index funds because the market is completely unpredictable, and active investors are just delusional and think they can predict it. They can't.
Their EU region was down for 8 hours last November and it took 2 hours before they were aware of it so submitting a ticket is definitively worth while. I'm suspecting their monitoring is not good enough.
They are definitely aware of it, although the status page is having trouble loading, you should get it eventually.
If their triage system is good than overwhelming them with duplicate non-specific "things are wonky" error reports might not hurt, but it def doesn't help.
Usually, you can find contacts instead of writing to random admins in abuse or security info. Helps them make money, so most should know low-hanging fruit like this.
5xx indicates an error in the server, 4xx indicates a client error. So it's quite common for clients to handle them differently like retrying 5xx but not 4xx.
Sure, but if the server is returning 418 by an error it is likely that it would return some other 4xx error instead of 5xx. 418 is irrelevant here, the server is rogue.
In practice performance problems are a nonissue. Your API should consist of start time and duration because that is how people think about appointments and meetings. (An hour long meeting starting at noon) It's a pain to write a UI that updates two pieces of information when one piece of information changes. If you are truly worried about query performance you can denormalize the data before saving by storing start/end times as a datetime range field, but it still makes no sense to expose that in your API.
How would your code generate all the appointments for a given day?
Requirement: Must be able to handle appointments that span a day, i.e. show all Sunday appointments when there's a party appointment that starts at 8PM Saturday and ends at 2AM Sunday, or in your data model, Saturday 20:00 for six hours.
Showing duration is helpful but so is the exact end time. Visually as a user I would like to see the exact time when the appointment ends instead of calculating it in my head. While it is not that hard to process when an appointment with a duration of 4:15 ends after starting at 2:30 but still.
As for API it makes a lot of sense to expose end time. If you for example are creating a calendar widget then it has start and end datetime for all events. With only duration available in the API output you know how to calculate the end time. More lines of codes for you.
Fetching from the API you would in most cases limit it to certain dates, for example next week. So now you suddenly do have to deal with start and end time. Not having it otherwise makes no sense.
Never had any developers ask for outputting duration in our scheduling API. It would be useful to include it but since no one have asked about it then I think having end time is more critical. https://developer.makeplans.com/#attributes-1
> > you can tell it was designed before XML/JSON were "hot
> or you can tell it was designed by people who care more about performance.
I doubt parsing iCal is significantly more performant than JSON for most use cases. In fact I can image it being less so in more cases than it is more so, and as close to the same as makes no odds in the vast majority of cases.
Parsing iCal was far more performant than parsing JSON as your parser could simply start at the first byte, and follow the spec — whereas a JSON parser would first need to wait for ten years before JSON was invented.
The original comment implied that parsing JSON was less efficient (either in terms of coding required, or the resulting CPU use) than parsing iCal.
While it is true that dealing with json by hand is going to be more work than just importing an iCal library, I'm comparing apples to apples and suggesting dealing with json "by hand" is no more faff than dealing with iCal "by hand", and that dealing with either via a good library equally gives no benefit to iCal.
Most data formats used in high performant scenarios, for example in finance, are very basic for a reason. You also get the benefit of being able to start processing the file immediately line by line, instead of having to read and parse the entire file.
That's not very accurate.