Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Cron

deno.com

Post reply on HN
Print view View original

141–150 of 190 posts

Re: Deno Cron

#141

Post by camgunz »

vvpan wrote: post #86
mike_d wrote: post #43

Earlier quoted context omitted.

It is really disappointing to me when I hear takes like this. As an industry we are splitting the roles of programmers and engineers so that programmers can just throw spaghetti at the wall and it is the engineers problem to happily run it. We need more well rounded people that also fundamentally understand how their code is executing on the backend so performance and cost can be optimized.

It does not matter if you are "well rounded". If you can schedule something with a line of code then that is objectively faster to develop and maintain than to (for GCP for example): - setup cloud cron job - setup pubsub channel - create pubsub subscription - add environment variables specifying the subscription - make all that work in terraform and run migrations And that process is different for every cloud provide…

I had exactly this problem, and honestly the easiest thing to do was set up a $12/mo VPS and use actual cron. I evaluated the cloud scheduled function you laid out there and was like "...nah".

Re: Deno Cron

#143

Post by marcosdumay »

everforward wrote: post #91
marcosdumay wrote: post #76

Earlier quoted context omitted.

> the amount of bullshit it takes to make the spaghetti stick to the wall is dictated by how it was made I really don't know where the bullshit coming from. Often it looks like every single person is fighting for their lives against it, and yet it keeps growing. But it's mostly dictated by overarching decisions that constrain both how it runs and how it's made (AKA, outside somewhere). Of course, there exist people o…

> But it's mostly dictated by overarching decisions that constrain both how it runs and how it's made (AKA, outside somewhere). While annoying, there's often a good reason behind those if you can drill down to the engineers that asked for that rule. Just as an example, it's easy to provide a single HA solution at the infrastructure tier... provided the infra people can make a few assumptions about your app (stateless…

Oh, but we have been doing HA everywhere since the turn of the century. It adds some complexity, but absolutely can't explain it constantly creeping in.

There's some complexity coming from better usability requirements, but again, it only explains a small part of it. There's something from the even-driven nature of the web never actually making inroads into our toolset (any toolset people actually use), that's a larger one, but again, it was 20-and-many years ago, it can't explain a constant creep-in.

Instead, since the 10's all the large innovations on software development seem to be about standardizing the complexity, and separating it so you can offshore. And yet, every time one of those gets adopted, the complexity creeps in.

Re: Deno Cron

#144

Post by pseudosavant »

phoe-krk wrote: post #87

The AI-generated imagery at https://deno.com/blog/cron/cover.png is actually painful the longer you look at it. The multiple watch hands might be an artistic effect, but the clock lacks the tenth hour and has two elevenths, the dinosaur's legs make absolutely no sense, and the water reflections show a different pattern on the dinosaur legs and a completely different set of clock hands than what is visible above. I kn…

Yes, by all means, make sure that the dinosaur wearing a clock around his neck looks believable. I'd hate to see something ridiculous.

Re: Deno Cron

#145

Post by dmix »

cantSpellSober wrote: post #122
handsaway wrote: post #99

Earlier quoted context omitted.

It's hard to ignore when it takes up my entire screen and I have to scroll to see anything else. AI artwork is popping up everywhere and I don't think it looks as cool as people seem to think. It comes off incredibly tacky.

Perhaps bad AI art will go down as a tacky nostalgia, the "'under construction' gif" of their time

No, we'll just wait for it to get better... all of those critiques are solvable by future iterations of AI tooling, at least for generic blogpost headers, where the alternative is usually some other generic stock photo or nothing at all. Rarely is human ever involved in creating it new.

Re: Deno Cron

#146

Post by toastercat »

kaishiro wrote: post #133
iteratethis wrote: post #131

Earlier quoted context omitted.

You're wrong. App/mobile and web developers are stretched beyond belief as it comes to skills expected of them. This handbook gives a reasonable overview of the scope of a front-end developer: https://thoughtworksinc.github.io/front-end-handbook/en/ Yet it's still incomplete, most of the cloud stuff isn't even included. We're over-asking people. Take Spotify. Has an army of quite decent engineers. They had to actuall…

I’d urge you to not so flatly dismiss someone’s opinion as wrong. The situation is obviously (I would think) more nuanced than that. I’d also argue that if a senior developer does not have control over their VCS, they should rethink their title. These are tools in a toolbox - you don’t need to be an expert in all of them, but seniority requires, at a minimum, proficiency.

Not to dismiss your opinion, but for someone arguing in favor of nuance, your perspective on seniority is surprisingly... un-nuanced. So a senior is not a senior if they are not proficient at Git? How do you even measure that proficiency?

EDIT: FWIW, I don't value titles like "senior" and never took them to be meaningful.

Re: Deno Cron

#147

Post by no_wizard »

vvpan wrote: post #37

I am a lead on a small startup team and one of the biggest pain points is dealing with infrastructure. We have no dedicated devops person and much of that work falls on me and other people who would be better writing code. I think the cloud paradigm is experiencing a shift. Few of us want to deal with cloud infrastructure (whether clicking around or via Terraform or equivalent) to execute a function every X minutes -…

I think this is where modern PHP (8.0+) has its strengths.

Its well known how to deploy. Its easy to deploy. The footguns are vigorously and thoroughly documented. The frameworks (Symfony, Laravel) are good. They all have a solution for X (be it queues, async work, cron jobs etc) and they have turn key deploy solutions favored by their respective communities.

Its honestly one of the easiest languages to deploy with nowadays, in my estimation. Rivaled only by C# / F# or platforms like Deno Deploy or Cloudflare workers. Sometimes the most boring / mature thing is the best thing.

Re: Deno Cron

#148

Post by hu3 »

ilaksh wrote: post #117

Great, but do they really have to leave the cron schedule format as the only option for specifying? It seems like a great idea if it's 1975 and you are dealing with limitations of that time. And I think it's good to keep it as an option. But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code? Maybe someone has a package already that can wrap this or ou…

This is something I like about in Laravel:

    $schedule->call(new DeleteRecentUsers)->daily();

    $schedule->job(new Heartbeat)->everyFiveMinutes();

    $schedule->exec('node /home/forge/script.js')->lastDayOfMonth('15:00');

    $schedule->command('foo')
       ->weekdays()
       ->hourly()
       ->timezone('America/Chicago')
       ->between('8:00', '17:00');

    $schedule->command('emails:send')
       ->hourly()
       ->days([Schedule::SUNDAY, Schedule::WEDNESDAY]);
https://laravel.com/docs/10.x/scheduling

Re: Deno Cron

#149

Post by rafram »

nightpool wrote: post #101
rafram wrote: post #80

Earlier quoted context omitted.

Or even a crontab! You know, the thing that this is named after.

I think there are sensible reasons people don't like using unlabeled, whitespace-delimited formats that require an ascii-art diagram to explain in the modern day.

I mean this is just that same format but wrapped in a JavaScript method call, so I don’t see a huge difference.

Re: Deno Cron

#150

Post by kaishiro »

toastercat wrote: post #146
kaishiro wrote: post #133

Earlier quoted context omitted.

I’d urge you to not so flatly dismiss someone’s opinion as wrong. The situation is obviously (I would think) more nuanced than that. I’d also argue that if a senior developer does not have control over their VCS, they should rethink their title. These are tools in a toolbox - you don’t need to be an expert in all of them, but seniority requires, at a minimum, proficiency.

Not to dismiss your opinion, but for someone arguing in favor of nuance, your perspective on seniority is surprisingly... un-nuanced. So a senior is not a senior if they are not proficient at Git? How do you even measure that proficiency? EDIT: FWIW, I don't value titles like "senior" and never took them to be meaningful.

> So a senior is not a senior if they are not proficient at Git?

In my opinion (for whatever that's worth!), no (although I would say VCS in general, not git specifically). I personally consider being able to properly version control your code to be a critical skill when it comes to development - regardless of your place on the stack. YMMV.

> FWIW, I don't value titles like "senior" and never took them to be meaningful.

I don't necessarily disagree with regard to the current state of the industry, however as a proponent of development having more professional standards I still believe that we should be attempting to find some common ground on the standards of proficiency and mentorship.

Post reply on HN