From the article, it seems the information was flowing _from_ the reporter:
> The feds allege that Peltz used disposable “burner” phones and encrypted apps to communicate with a journalist, and that the reporter provided “material nonpublic information about forthcoming articles” which Peltz used to trade in the market “just prior to publication of an article about each company written by the reporter.”
Trying to wrap my head around what you are trying to say. Let's use some example. If you would know that Tesla's delivery numbers were a disaster (they weren't). Knowing that before everybody else would give you a chance to sell at a significantly better price than others.
Could an insider trader get information, not act on it, write an article about his scoop, and then make trades after the article's published? If the publication he writes on is obscure and not followed, is the information still considered public?
Sure, but that doesn't mean it "loses its value unless it is published immediately".
Basically, the info has a certain amount of value, that doesn't really go down. If you pair that information with the knowledge of when it will be published, it goes up in value.
> Basically, the info has a certain amount of value, that doesn't really go down.
I was thinking of the value of the news to Bloomberg, which was mentioned in the article:
At Bloomberg, scoops about deals are highly valued, because beating competitors like Reuters or Dow Jones helps to justify the high price of a terminal, which carries rich veins of data along with news, at a reported cost of around $24,000 a year. The terminals constitute the company’s core business.
If the information is deemed important, then, as soon as Bloomberg is confident in the information's accuracy, it will publish. Once Peltz had a record of giving reliable tips, that would likely happen quickly.
I am not taking a position here on the proposition that Peltz needed to know when the information would be published in order to profit. I am pointing out that, even without being explicitly told by the journalist, he could be reasonably sure that publication would occur quickly, if at all. He could also be reasonably confident that it would be published, given that it is valuable information, and that Bloomberg had demonstrated its confidence in his leaks by publising earlier ones.
The feds may well, of course, have independent non-circumstantial evidence of the journalist informing Peltz about when the information would be published.
I've worked in finance technology for eight years now, in various domains.
As a broad generalization, if you are latency bound (milliseconds or less) then everything is done in code and the DB is never in the main loop.
At the other end, if you are throughput bound - think end of day/month activities - then stored procedures all the way.
For everything in between, prefer to have the logic in code due to the maintenance benefits that come with it.
> Do you have an API on top of DB that enforces the rules?
In general, a database is owned by the app it is associated with and the app mediates all access to that data. The usual enterprise integration patterns (esb, messaging, web services, file dumps) are used to share data with other systems.
> Is the security/data validation also done in the API/app layer?
Largely yes. There's some level of security (like app access control and encryption at rest) that's handled in the DB tier but authorization is largely an app level concern.
Similarly, some constraints are imposed in the DB schema but those are quite basic. Most validation is done in the app tier.
> And those guys hardly ever ship any code due to how encumbered developers typically are in those places and release maybe once every 6 months to a year perhaps.
I've worked in places where some teams ship with this three or six month frequency. They consider it completely normal and find ideas like continuously delivery or even weekly deployments as not just abnormal but risky and irresponsible! This is the very point OP is trying to make, the _normalization of deviance_.
I agree with you plenty that this shouldn't be acceptable, but most of the people I've seen that are against modern practices of decent software teams are not so much examples of the points in this article as much as stereotypical examples of one's grandparents or parents trying to tell you how your job doesn't matter because software isn't "real work" and that their principles work just fine today as it did in the 70s. Or they expect that continuous delivery / CI is a product or feature of something else they bought for 9+ figures and that it's something that you bundle in with services and a license cost because that's literally all they know as how to make anything happen. Doing software projects with people that have more experience in medieval architecture would be probably more pleasant and productive than dealing with leadership that have decades of experience doing nothing but big company projects with more resources spent on planning software than on engineering talent.
If a company is hell-bent on focusing for development and new features over stability / security, that's something that can be fixed by leadership - I've worked with plenty of companies that turned themselves around and have wise leaders that know that it's time to spend the resources to do spring cleaning while trying to keep existing employees excited by feature development happy.
I wrote a short book recently [1] and went through a similar process. Started writing using Markdown & Pandoc but soon realized that Markdown isn't a very good fit for longer technical documents. As an example, support for asides aka admonition blocks is nonexistent. I switched to Asciidoc + Asciidoctor and the process was much more productive.
If I understand correctly, the gitbook toolchain isn't freely available. Nor does gitbook address any of the limitations of Markdown that prompted me to switch to Asciidoc.
This looks like a great idea! Some feedback: for a site named 'solr start', I was hoping the first thing I see would be something named 'start here' which explains what solr is, what to use it for, how to get started, etc. Instead, the 1st thing is something arcane called 'UpdateRequestProcessors'!
> The feds allege that Peltz used disposable “burner” phones and encrypted apps to communicate with a journalist, and that the reporter provided “material nonpublic information about forthcoming articles” which Peltz used to trade in the market “just prior to publication of an article about each company written by the reporter.”