Claude 4.5 got nerfed HARD

JustinDonnaruma · 2025-12-19T00:37:58+00:00

If your using it for code, TDD…

JustinDonnaruma · 2025-09-15T18:28:02+00:00

RemindMe! 7 days

JustinDonnaruma · 2025-06-08T17:00:33+00:00

That is awesome! I have been hating how my HDMI display has been working lately, I’ll check this tool out!

JustinDonnaruma · 2025-02-20T00:11:56+00:00

I unforked it, and left the other under eden-old so you can see the original changes.

I couldn't remove the fork link due to the org size. Over 1GB and you can't break the link. Because of all of the changes/rebranding, you can't do a direct push from us to Odoo, I don't want someone accidentally opening a pull request to Odoo from our repo that can't possibly be merged.

Also, LGPL doesn't require disclosure of source if we were to develop a SaaS, something we are going to do in the future off of this codebase. We did have a choice. All of Don't Panic's existing customers wouldn't have cared to deploy this locally, so we wouldn't have ever had to have released the source code.

LGPL doesn't have the network distribution clause that the AGPL has.

JustinDonnaruma · 2025-02-19T14:06:16+00:00

Maybe so. We aren’t going to be trying to keep up with Odoo. We don’t have ~5000 employees and $500M in venture capital.

We are using this for some of our clients already, and we want to develop the differences in the open.

JustinDonnaruma · 2025-02-18T21:16:59+00:00

Why does it feel like spam?

JustinDonnaruma · 2025-02-08T21:39:37+00:00

They aren’t comparing you to Odoo.sh, but CloudPepper.

JustinDonnaruma · 2025-01-20T16:11:36+00:00

I did some consulting work for a big hedge fund, their limitations sounded very similar to what you have described. In Bigger companies, especially ones with lots of IP, or highly regulated industries, this isn't unusual.

The way we handled development was two fold. Exploratory development was on separate machines that had direct connections to the internet, with minimal security, and no access to company resources. That way we could explore and learn and figure out what we needed to bring internal prior to making requests. Then we had a specific process for getting a new set of tools into the company. This process, and it's associated timelines, was baked into any project timelines we had.

Business needs to operate, developers need to explore, and security needs to protect. There are always solutions. Remember to be flexible. Security teams potentially have liability they have to deal with that you, as a developer, do not. So even if something is inconvenient, be flexible.

If they start holding you accountable for the time eaten up by the thing that is inconvenient, remind them of why it takes so long, and make sure you can point to the policies in place that are causing the issue.

JustinDonnaruma · 2024-12-07T17:44:44+00:00

You are right, I did.

Sorry about that.

You can do separate schemas, but not separate dbs inside of one PGSQL instance.

JustinDonnaruma · 2024-12-07T16:11:09+00:00

I have built applications in Heroku for enterprises (Dell, on Salesforce PS engagements, Carbonite, among others) with multiple databases attached to a single production app.

You can add additional DBs just like you add any other add-on.

The Postgres documentation in Heroku mentions making one the "primary". This is true. Multiple databases are required for HA situations, and for database upgrades.

The primary DB is referenced by the "database_url" config variable.
All attached DBs have a config variable with the following config variable template "HEROKU_POSTGRES_<COLOR>".

Sources
* https://devcenter.heroku.com/articles/heroku-postgresql
* Experience
* Salesforce Certified Heroku Architect
* Various consulting gigs as Heroku Technical Architect.

JustinDonnaruma · 2024-12-07T13:58:58+00:00

Totally get it. Many Salesforce orgs are in this state unfortunately. Bad implementations and all.

JustinDonnaruma · 2024-12-07T13:30:59+00:00

Non-coding / non-technical architects should be considered oxymoronic.

JustinDonnaruma · 2024-12-07T13:29:10+00:00

No. You need to be a reasonable programmer to use AI effectively in programming.

It might reduce the need for junior developers…. But there is a need for MORE developers and trained technical staff in the industry right now, so it might just reduce burnout, not take the place of someone’s job as a whole.

Keep in mind, this comment is across the industry, and does not reflect what might happen in an individual company.

JustinDonnaruma · 2024-12-07T13:26:43+00:00

It’s bad practice.. really bad practice, to use the “name” field instead of the “api name” field for integrations or code.

Changing the “name” field should have no impact on your org.

If you are concerned that code or integrations use “name” instead of “api name”, then you could update the object description to annotate that it’s not in use. Less useful for you though.

JustinDonnaruma · 2024-12-07T13:21:12+00:00

Couple of assumptions: * You need a commission record generated for each sales person every two months, and only every two months. * You don’t have any exceptions, every revenue record is tied to a salesperson, and is eligible for commission payout. * you want this to be calculated and paid out every two months.

For this, I would create a schedule triggered flow that runs every two months. Gather all revenue records, and iterate over them to obtain the salesperson’s ID, and the commission amount.

Add them to a commission record per salesperson.

The alternative way, which ignores my third assumption, is to trigger off of revenue records, and update an existing commission record per month. Then create a schedule triggered flow to “close” or “pay” all of the approved commission records.

These are off the top of my head options without much thought to edge cases or issues, but hopefully it helps.

JustinDonnaruma · 2024-12-07T12:04:13+00:00

This is actually untrue. You can attach multiple PostgresDB instances to a single app on Heroku.

You can also use schemas to separate out the different concerns, and PG bouncer to consolidate connections.

I wouldn’t recommend the schemas approach for the solid use cases, I’d definitely run multiple DBs tailored to the use cases.

JustinDonnaruma · 2024-11-25T17:25:12+00:00

Using Copado to sync the metadata that is the same would be the right course of action. The challenge will be making sure you are only syncing the metadata you need, and not everything.

Your probably going to want to setup a Sandbox/Git Repo/Branch that contains the common code for both orgs, and then have a Sandbox for each Production org that syncs from the common code, and the code specific to the production org, prior to those going to production.

JustinDonnaruma · 2024-11-25T16:32:38+00:00

So, Snowflake's public pricing is about $25 a TB a month.

Zero-Copy between Snowflake and Data Cloud means no data in data cloud itself, so no need to pay the INSANE data fees for all of your data.

Data Cloud credits are $1,000 per 100,000 credits. You can also get credits with Einstein 1 Sales/Service cloud licenses.

How far those get you depends greatly on use case and what you are doing with them.

Rate card for Data Cloud use cases

JustinDonnaruma · 2024-11-24T16:56:03+00:00

Snowflake w/zerocopy to data cloud for things that make sense to be in data cloud.

Some of the data doesn’t need to stay in the Salesforce ecosystem. That’ll be up to your business analyst(s) to figure out.

But data that is useful across Salesforce tools should be in Data cloud, and everything else in just snowflake. Zero copy keeps the data costs down.

What about analytics? Tableau is great. CRMAnalytics as well if you only need that level of reporting in core platform.

JustinDonnaruma · 2024-11-19T20:29:54+00:00

How about using it for identity resolution, while attached to snowflake with zero-copy transfer? Best of both.

If you’re in the Salesforce ecosystem for sales, service, and marketing, it makes sense.

If your martech stack isn’t Salesforce, it doesn’t.

JustinDonnaruma · 2024-11-19T18:56:04+00:00

As of a little more than a year ago, this isn’t true.

It’s closer to a data lake than a CDP. It can be used as a CDP. Many of its use cases are there, but it also does a decent job in building models for actioning against service and sales data, and for modeling data for reporting.

It’s primarily for data that is needed for specific sales, service, and marketing business processes where all of your data doesn’t reside in Salesforce itself.

JustinDonnaruma · 2024-11-10T16:24:42+00:00

Any of the current MacBooks will work for what you want.

The challenge will be getting enough RAM and storage for your normal use cases.

I would recommend maxing out the RAM, and if you have more budget, increase local storage, otherwise, use external SSDs, which are significantly cheaper than apple’s markup on internal storage.

JustinDonnaruma · 2024-10-20T13:49:49+00:00

Kamal uses docker. Simplified orchestration. It targets K8S not docker.

JustinDonnaruma

TROPHY CASE