The use case that immediately came to mind for me was to use dbt charts as a rendering method for an MCP App.
You don't really want to give a LLM client code execution environment like Observable Framework does. dbt charts appear to validate the entire yaml input including the SQL being sent to the data source.
So I'm getting: a data vis layer that can be dynamically defined and rendered via LLM/MCP client without the headache of sandboxing a JS Runtime environment.
I personally filled out this form, under duress, because there was ZERO communication from any regulating body of the requirement.
And yes it was a felony to not register by, IIRC, December 31st of the same year the measure was passed or some other very accelerated timeline.
There was no email, letter, or notification received. The data collected included enough information for someone to effectively takeover my business record for my state if the government dataset ever got leaked.
I'm glad they are forcing the erasure of the data.
It was a felony to refuse to register. They gave you notices and warnings before it got that far.
Of course you wouldn't get an email. If you hadn't filed the paperwork you would have gotten a written warning. But you did it on time, so that never happened.
The data collected was less than what was on your license or passport. What data fields do you think would have allowed anyone to commit identity theft or takeover your business.
While I agree with the spirit of your statement "people are afraid to run their own software", I feel like this assumes that people are the ones choosing the software they run. I wish my teams could run more things ourselves, but are told no by our systems and infrastructure staff.
Any self hosted service in an enterprise means that you're dealing with all the headaches that come with that including: backups, user/role creation and mapping maintenance, infrastructure scaling needs, OTEL or other monitoring, etc.
It's an easier decision for VPs to pay GitHub anything less than the man hours required to execute the above tasks because it's a "not our problem" fee.
I'm late to the game on this thread, but I am a lead SWE at a medium size logistics company. Been in logistics SWE since 2015. I'd be interested to hear how your company fits into the industry, who your service provider is, which no code platform you're using, etc and at the very least give you a sounding board based on my experience. Shoot me a DM if you're interested!
I'm genuinely not sure how other companies do this.... But how is your team handling SOX controls WITHOUT at least one DevOps person?
I work at a medium size publicly traded company and our SOX compliance controls would take literal months to generate and/or prove to auditors without our CI/CD pipelines. It's just an extract from GH Actions with a report of who modified, who approved, and who actually pushed to main. All of these actions must be siloed (if you can commit to repo, you cannot push to main)
Potentially this is a consequence of micro service infra, my team alone manages nearly 25 separate git repositories.
Fully automatic ones do exist, but its generally not done to not risk damage to the books. And without ocr of page numbers you always risked missing pages.
This is set to change, but right now iPhones only support the most basic form of text messaging with android phones. Texting between iPhones just works better. The images are higher quality, reacting to messages works right you can can reply to people, where as soon as you try to include an android number all of that drops away
The distinction between iMessage (blue bubbles) and regular SMS/MMS (green bubbles) on iPhones matters because iMessage offers additional features like read receipts, typing indicators, higher-quality media sharing, and seamless syncing across Apple devices. While the color of the bubble itself may not be significant, the functionality and experience differ between the two, impacting communication capabilities.
Your telco/carrier can (and do) "read"* your SMS chats.
* Capture, store, share with various authorities and data services, and sometimes advertise against, as well as make available to other people on your account and carrier support.
Thanks for your reply. When I describe "the business" I am referring to Product teams that manage SOP, help prioritize new offerings, etc. Here's an example of a feature request from the business:
"I want to allow customers to run scheduled reports from our portal and receive them via email."
Development then designs and executes, delivering a scheduled reporting suite for testing. Business will come back with feedback such as:
"I don't like how I have to select the time for every report. Can't you just default it?" or "Only some users from the customer's account should be able to create/edit scheduled reports. Please add this by Tuesday so I can demo." or even "This is great, but my customer has special holidays that they don't want emails to be sent on. We should have a yearly calendar that prevents reports from getting sent."
There is a large gap between feature request "requirements" and the expectations of the business. Thus, we request specific feature request requirement documents to be turned in prior to development starting work.
It sounds like there's a step missing from that flow - who makes requirements? Saying "I want something" is not a requirement, it's a user need. Not trying to be pedantic, but it might be the lack of definition around what a requirement actually is, that's causing the confusion and rework cycle.
A requirement is typically of the syntax, "{X} system shall {verb} {functionality}". For example, "The brakes subsystem shall convert kinetic energy of the bicycle into heat in the brake pads".
A feature request "requirement" is not a thing. The product team can request features, and someone (an engineer, or a PM typically) needs to create requirement(s) to capture the feature. As part of that process, there should be a back and forth between engineering and the product team to figure out what exactly is desired.
Can someone, anyone, explain to me how this passes SOX scrutiny?
I have issues with business/product team even commenting on PRs because auditors have said that access to GitHub=Access to Codebase.
There are a select few people I would consider granting access to code within our product teams, but without "segregation of duties" clearly defined, I don't think it would fly.
You don't really want to give a LLM client code execution environment like Observable Framework does. dbt charts appear to validate the entire yaml input including the SQL being sent to the data source.
So I'm getting: a data vis layer that can be dynamically defined and rendered via LLM/MCP client without the headache of sandboxing a JS Runtime environment.
reply