undefined | Better HN

0 pointsmajkinetor4y ago0 comments

Meh...

Here is the exact case you mention, just WAY worst. This is something I did for chocolatey community:

https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...

This page is report of the PowerShell framework I developed mostly in first year of development (https://github.com/majkinetor/au) that checks ~250 web sites for updates on various software. Today it has 6 errors and usually never much more. On my own location I keep ~60 packages and I I tackle errors maybe once a year. Stuff just work, and you rarely have to visit, otherwise I would be involved entire day into this and I am not, while those packages have many millions of users.

Now I spend almost 0 time maintaining packages and I am one of the top choco package owners.

Check out the options used, some of which make it so robust:

https://github.com/chocolatey-community/chocolatey-packages/...

> It’s sources keep changing frequently, robust automation here is probably a research project and simple automation is orders of magnitude more bang for buck.

Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that. By automating you learn something new, so it pays more for your experience. Manually working every day the same thing (that may move around) doesn't involve complex thinking and is just waste of time.

0 comments

kqr4y ago

> Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that.

Now I think we can get somewhere! Is this an admission that automation is not worth it when the processes or inputs change too often?

If so, then this frequency (which you have given as daily) depend entirely on the business needs in question.

Often, there's no business case to run an automated process daily.

Weekly or even monthly are very common intervals for processes in business. For a process that needs to run monthly, you only get twelve executions in a year. If the inputs change every six months, do you still think spending 60+ commits (as in your settings example) is worth it every six months, when there are cheaper ways to do it with limited human intervention?

majkinetorOP4y ago

> Often, there's no business case to run an automated process daily.

Almost 100% of the cases I have run daily, hourly and even less (5,10,20,30 minutes schedule are common). I even had one recently that executed millions of requests to some REST API daily, running every few seconds. I call those "app supporting scripts", and I offload specific features of the main app to those.

Must be architectural thing I guess, I work as principal architect and I design most of my services so that they rely heavily on automation support.

> Is this an admission that automation is not worth it when the processes or inputs change too often?

I don't work in a vacuum. For me there are no rules about anything, context is most important (patterns, best practices etc. are for newbies). That case does lean to the manual side on first thought, but it all depends on other factors.

kqr4y ago

Then I suspect we are in violent agreement only working on processes at different timescales in our day-to-day!

j / k navigate · click thread line to collapse

0 comments

kqr4y ago

> Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that.

Now I think we can get somewhere! Is this an admission that automation is not worth it when the processes or inputs change too often?

If so, then this frequency (which you have given as daily) depend entirely on the business needs in question.

Often, there's no business case to run an automated process daily.

majkinetorOP4y ago

> Often, there's no business case to run an automated process daily.

Must be architectural thing I guess, I work as principal architect and I design most of my services so that they rely heavily on automation support.

> Is this an admission that automation is not worth it when the processes or inputs change too often?

kqr4y ago

Then I suspect we are in violent agreement only working on processes at different timescales in our day-to-day!

j / k navigate · click thread line to collapse