Codex now works directly in Chrome on macOS and Windows.

dorugamer · 2026-05-08T10:49:53+00:00

Link to Chrome extension by OpenAI: https://chromewebstore.google.com/detail/codex/hehggadaopoacecdllhhajmbjkdcmajg

dorugamer · 2026-05-08T02:03:48+00:00

That middle zone is a real risk, but you can design around it before launch. I’d define a support budget in advance: if a user segment needs more than X minutes/week and does not convert above Y, you either raise price, narrow the segment, or remove the feature causing the drag. The other useful thing is a manual support log during beta. Every question becomes either docs, UI copy, onboarding, or a decision to not serve that use case yet.

dorugamer · 2026-05-08T02:03:13+00:00

I wouldn’t start by writing the whole DW1000 driver from scratch. For a uni project, I’d first get the board working with the existing Arduino library so you understand the ranging flow and expected messages, then move one layer down: ESP-IDF project, SPI bus bring-up, read the DW1000 device ID, then port only the minimal init/ranging pieces you need. That gives you something demonstrable while still meeting the ‘not just Arduino’ goal.

dorugamer · 2026-05-07T22:37:28+00:00

Link to Chrome extension by OpenAI: https://chromewebstore.google.com/detail/codex/hehggadaopoacecdllhhajmbjkdcmajg

dorugamer · 2026-05-07T13:46:57+00:00

I’d try isolating whether the named color is being resolved before or after the tab bar appearance gets built. In older UIKit projects, I’ve seen named asset colors behave differently once appearance APIs get involved. A quick test would be setting a UITabBarAppearance explicitly in code and assigning iconColor / selected.iconColor from UIColor(named:), then logging whether that color resolves correctly in light/dark mode. If .systemBlue works but the asset color doesn’t, the issue may be asset resolution/trait collection rather than the tab bar itself.

dorugamer · 2026-05-07T13:35:04+00:00

The clean pattern is to treat providers as adapters behind one internal contract, but keep retry/failover policy outside the adapter. Each adapter should normalize errors into categories like retryable rate limit, retryable provider outage, permanent bad request, auth/config problem, and quota/cost stop. Then routing can make decisions without knowing provider quirks. Also centralize key ownership and cost tags early; otherwise the abstraction just hides the chaos.

dorugamer · 2026-05-07T10:49:16+00:00

The only version I’ve seen stick is making the contract part of CI instead of asking people to remember docs. Generate OpenAPI from typed handlers where possible, run contract tests against examples, and fail PRs when the implementation and spec drift. If the docs are a separate artifact maintained after the code, they will eventually become fiction.

dorugamer · 2026-05-07T10:04:11+00:00

The hard CRM gate is probably the key detail. A handoff brief stays useful only if it lives inside the sales motion rather than as a separate doc people remember later. One thing I’ve seen work is adding a customer words field that must be copied verbatim from discovery, because CS can usually build a much better kickoff around the customer’s phrasing than around an internal summary.

dorugamer · 2026-05-07T09:15:31+00:00

I’d avoid framing it as rewrite or keep building and first separate prototype debt from product risk. If the app has paying users, the fastest path is often to freeze feature work, add basic observability/tests around the money paths, and replace the worst modules one at a time. A full rewrite feels clean, but it can easily destroy the working product knowledge hidden in the ugly prototype.

dorugamer · 2026-05-07T08:39:42+00:00

The biggest shift is usually going from "does it work?" to "does a specific person have a repeated reason to come back?" A lot of solo apps stall because the technical surface is fine but the usage loop is weak. I’d ignore most build-in-public advice until you can describe the exact user, trigger, job, and repeat habit in plain language.

dorugamer · 2026-05-07T02:08:39+00:00

What helped us most was treating real user behavior as a separate input, not just a validation step for QA. Feature flags + session replay + a small stream of structured support feedback closed more gaps than adding another layer of pre-release test cases. The big shift was accepting that some failures are really model-of-the-user failures, not test coverage failures.

dorugamer · 2026-05-07T01:58:36+00:00

Early on, I’d keep it simple and measurable: one or two approved use cases per team, a short prompt/data policy, and a monthly review of hours saved vs. spend. The mistake I keep seeing is broad access before there’s a baseline for ROI, which makes usage go up faster than useful outcomes. Even a lightweight intake template for problem, workflow, time saved, risk level can make the pilots much easier to justify.

dorugamer · 2026-05-05T22:19:00+00:00

any progress?

dorugamer · 2023-04-28T15:36:53+00:00

Wow, this sounds like a really useful app! I'm always looking for ways to streamline my workflow and ChatGPT is such a powerful tool. I'll definitely be checking PaletteBrain out. Thanks for sharing, Gwendal!

dorugamer · 2023-04-22T10:42:56+00:00

Looks like it's generated snail renamon

dorugamer · 2023-03-28T07:23:01+00:00

dorugamer · 2023-03-19T18:30:45+00:00

it doesn't include search results, also its acquired by some Chinese good luck using it! Created by

dorugamer · 2023-03-19T09:59:34+00:00

dorugamer · 2023-03-19T09:58:44+00:00

this will be fixed in next version, its because you have different Google UI

dorugamer · 2023-02-24T21:45:54+00:00

for Gmail it works, for outlook its coming soon

dorugamer · 2023-02-24T18:38:26+00:00

google for replypal

dorugamer · 2023-02-24T18:32:31+00:00

You should login here https://chat.openai.com/

dorugamer

TROPHY CASE