evolve-maz

8 日前議論

That's because the assumption is the new product can already do what their current product can, so the things customers ask for is the extras. It's really easy to forget that a lot of work went into "baseline" features which are assumed to be standard (in this case the not burning part).

evolve-maz

先月議論

If I flag every line in your PR as a potential security bug then I have 100% recall.

Obviously you need a mixture of high recall and low false positive rate. If 7/8 flagged items are fine its much more likely people will ignore the warnings, much like they would any security tool with a 90% false positive rate. That is not optimized for the customer.

evolve-maz

2 か月前議論

My advice would be to only use HTMX for data state related operations. For something like an intelligent back button, unless it depends on resource state do not use the backend to calculate it.

The recommended htmx way would be to hook up an onclick button to inline js or if you dislike that, a function called goBackOrInbox. It can then be something like:

function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }

And if you use that pattern a lot then you can parameterise the function with whatever the route should be.

evolve-maz

2 か月前議論

All the talking points and techniques are those which were used when pushing outsourcing: give better specs, write detailed tests, accept bad code because it works so who cares, we can just rewrite from scratch later, and my favorite "they will get better with more exposure to your code base". None of these takes is wrong, but what they neglect is doing all that work is way more effort than if I wrote the original code myself.

Using an LLM to one shot a small function (something i would do with a very specific search on Google or SO) is handy. Giving it a harness and free access to a code base leads to some terrible code, and doubling down with more instructions and agents in the loop means more time writing the rube Goldberg orchestration rather than just opening up an editor and writing code.

evolve-maz

3 か月前議論

Nice write-up. Did you try the problem out against a MIP method?

evolve-maz

3 か月前議論

Presentation of data and a story is a very important part of the service. That's why we have a mix of pictures, tables, paragraphs, etc. It's why UX is so important in general.

evolve-maz

4 か月前議論

[dead]

evolve-maz

5 か月前議論

Expertise isn't there because people are outsourcing that sort of work to companies. I didn't know how to do much of anything, until I had to do it for work. Then learning everything became way easier.

evolve-maz

5 か月前議論

Htmx has events you can listen to like htmx after response. You can think of it almost like a middleware. After the response comes in, your callback is triggered and you can make the callback look up some attribute given the calling parents attribute that you might call hx-json-key.

Yes you have to add this yourself, but you only need to add one js function once and be done with it.

I've used the callback pattern for custom error handling for all hx responses.

evolve-maz

6 か月前議論

FYI I had a similar problem to yours in terms of having jobs I wanted to run on a schedule. I also had an extra layer where I wanted to let users to define jobs with their own special parameters etc. Maybe what I did is helpful for you:

- Form submission in front-end admin panel for users, for "new scheduled job"

- Form allows defining a job name, job type (while I let users define jobs, I limit it to a subset of python functions that I trust but are still general enough), job parameters (just a json blob for kwargs for the python func), frequency, and timeout.

- For the whitelisting of functions it's easiest to have a directory in your src which has the different python functions that are usable, and when you do a "get" for the form you populate the dropdown with the scripts from that directory / some metadata.

- The backend (fastAPI) saves the details in a DB and creates a CRON file for the job, to add to the crontab. I basically have a template bash statement with the timeout built in and logging hooked up to it. And when python functions are called I have a helper which grabs the JSON kwargs from the DB or a filecache (if remote DB and I don't want to hit it every minute or something) to avoid cmd line injection.

- Also have an "edit scheduled job" which opens the same form view but with items pre-populated, and the submit going to a patch endpoint instead of a post.

It's stupid simple but lets users define a range of jobs. Things like having daily backups, where to send the backups, pulling things from / pushing things to an API frequently, etc.

コメント