Видео

I despise that multi line if statement for guard clauses. Often i have several if statements in a row, and that makes the multi line one unreadable

I've found that the information to noise ratio is crucial. So don't feel too bad about deleting excessive braces. I used to do it the standard Microsoft way during my junior years, but now I actually like the 2 line version best. In case ternary is possible I'd even use that over if statements. I have to admit though that I worked with Python a lot, so the braceless version feels a lot more natural to me.

I use all but the third one, bracket on same line. Honesty open your compiled libraries and you'll see all your efforts wasted as they will now all look the same.

Use an autoformatter and #1; the formatter will unindent the second statement, highlighting your mistake.

Since dotnet core, when hosted inside IIS, Hangfire goes down when app/api goes idle. Hence scheduled jobs are not executed on time. None of the solution worked for me ever and I moved to dotnet background workers (WS). Did anyone else faced similar issue, or was it only me doing something silly?

I like having the brackets on their own lines, so I can easily see the start and end of the block by just scanning the left side of the screen. But I also use the single line for short statements, like guard clauses at the start of a method.

C# and JS code is easily visible with free tools. If you care about keeping your code 'secret', that's a downside.

Have used Quartz, HF and Coravel and for me personally, choosing one over another depends on the environment and app requirements.

A valuable component !! Thanks

You've essentially recreated checked exceptions.

What a pointless addition to the language.

D

I also wonder why Blazor hasn't really taken off despite the fact it also a good front-end technology alternative to React or Angular.

How about securing dashboard (exposing it only to authenticated users) and splitting it from the project to a different domain?

Just finished a Tibero (oracle clone) connector for Hangfire. :)

I think people hate C# because it's not a beginner friendly language, people want to be seniors without making any effort to understand software engineering complex concepts, I encourage all the developers to take a look to C#/Java to understand and practice OOP at least!

I prefer Quartz. It's really reliable, simple and well established.

very buggy lib, this is a promotional video

Hello! I sometimes use one liners to code that is often the same. For example a null check in Equals override looks always the same one liner. There are important decisions, and even if the decision takes no longer than a "null check return", i will prefer the fourth. Years before when i started to learn programming i often resolved to break that one line into the second example. Even before that i learned java as one of my first programming languages, and i used the third example. Later on when i started to learn c#, our teacher was formatting it the java way in the class. In the class we often raced for the less lines of code not knowing we can just write everything after one another. Over time the fourth way grew on me because when i was using visual studio fresh "out of factory", it would be very convenient to press certain keys. Also i could see the scope immediately instead of searching for it these days (looking at java-like formatting for example). I have factored code in visual basic, and python, and those are very conveniently look similar to the c# way with the fourth example. Even before any of these i learned Comenius Logo with requiring one liners in console. I have got other console-like experience with one liners too

Thanks for skipping the part new people won't know. bye I'm back to save people time Go to the csproj file and add 3 lines to <PropertyGroup> <PackAsTool>True</PackAsTool> <ToolCommandName>Weather</ToolCommandName> <PackageOutputPath>./nupkg</PackageOutputPath> Then run the command 'dotnet pack' Then, to install it globally you type 'dotnet tool install --globally' if done locally also add to that command '--add-source ./nupkg' then give the proj name 'weather.cli'

I use the "brace-less multi-line" form for single statements, as long as the if statement is standing on its own. Which means no using it with 'else', and no using it where it might create ambiguity with nested ifs. If more statements need to be added, I add braces. If I reduce a multi-statement block to a single statement, I remove the braces. I don't buy the "stacked requests create ambiguity" argument, personally. Scope rules in C# are pretty darn consistent. It's not like C or JS where scope can be ambiguous or inconsistent at times. There's a limit to how idiot-proof it's worth making code before it starts actively becoming cumbersome to read through. Issues like the "double stacking" or placing multiple statements on a single lines aren't faults of whether or not braces are used; they're formatting issues of their own. If these are really becoming problematic for you, you're likely to have bigger issues already... I also use the inline 'using' syntax, but typically only when the enclosing scope is limited enough that including the extra braces is redundant, such as within an if block or a short method. That one has a bit more functional implication since it controls when the resource is disposed, so there are times when it makes more sense to want to have precise control over that.

What language does he speaks?

Would very much like more info on this! Looks really nice, especially since it's not a windows service!

If a developer knows all these, atleast the green one, he is the entire dev team !

Hangfire still executing everything (jobs, interacting with the storage) synchronously which is a big bummer. Everything will be a blocking call under the hood.

When I was a 30 years old developer I would have chosen Option #4, for the same reasons you explain in this video. Now that I am a 50 years old developer, I tend to choose option #2, if the statement inside is trivial and short for readability which is IMHO the most important criteria. If the statement is a bit complicated or long, I go for option #4, again for readability. I let you choose if it's selinity or wisdom :).

I am fine with all. One really need to stack another line of indented code to argue number 1 is bad. Even then, everybody knows that braceless syntax mean only the next line is considered. Never forget that as much as silence is an important part of music, spacing is an important part of formatting code. So to me such syntax means an empty line after. I however saw something in the production code of a professional project that's pretty bold. Braceless if followed by a foreach or it was something of that kind. I would never though about it myself. And probably many would be horrified, but it is understandable. (But I would refactor it should I have any subject in that part of code). This codebase was also the 1st time I met using without braces. Didn't knew it was possible. Took me a few minutes to understand but eventually got it. I had quite a bad time in a team where everyone was coding their own way. Changes just because one person have another code style set in VS... Boring as hell. I never had the occasion yet, but it seems we can force settings with editor config.

I've been using this one for a while now and it has everything I need. Great recommendation

Please make a video to show all possible things we can do with Hangfire. I love your content so much.

I dunno if I'm missing something here as I fail to see what this achieves. Reflection is cool because it lets you do things you otherwise cannot do, but with this Unsafe stuff, it's practically the same as calling a method directly. I can see that it's a hack to access a private method but there's probably a reason why it's private. If you don't think it should be private, in most cases, you can modify the library from source instead of relying on Nuget. This is far safer than introducing this Unsafe accessor that could just break when you update the dependent library because they changed something that they didn't expose.

The first language I learned was C# when I was 14 and I'm glad coz it pays off a lot. Anyone who teaches JavaScript as a first language should be in hell. JavaScript is a broken and messy language, and makes it difficult to transition to another (better) language.

I live in two worlds: I do C99/C++ and C# programming. For C#, i always use the preferred version of microsoft with curly braces on a new line. However, for single line statements i always remove the curly braces and leave the statement on the second line, because its much more easy to read and i can debug it much easier. In the C world, i always use the first version of the reddit post - moving the starting curly braces at the end of the condition. This also saves a bit of space, which is important for me because my libraries i write are massive in code lines due to its single-header-file-style - so i dont have to scroll that much. Regard the keyword "using" -> I do the same thing, i intentionally use the scoped version instead of the shorter one - because i want to see the code flow.

Is it next possible ? - have web API with Hangfire as described in the video but only for job registrations - have a separate service (several may be) on different host\hosts connected to the same Hangfire database but actually processed registered by API jobs.

Why tho ? Why try to reinvent the wheel with no real benefit other than obscuring what the code is actually doing behind various symbols ?

Can you do a video about whether at this time RestSharp is still relevant compared to the actual encarnation of the native .Net HttpClient? Tks in advance.

how about compiring hangfire to Coravel ??

This is not the video i have searched for, Google

Why just do not use a message broker with default dotnet background worker (hosted service)?

If you are writing the repository pattern just to abstract away the database "because it might change" tomorrow, stop. That was just a poor example people used to explain it. Real power of Repository pattern comes in abstracting the data retrieval and storage logic. When you write the function in a way which this linkedin post doesn't recommend (which is a bad advice of course), you say that those functions are what people using the repository MUST use and they SHOULD NOT think about internal logic of how repository does it. Why? Because that is internal code and when people are not passing stupid things like predicates, you have freedom to change, optimize and do whatever INSIDE the repository and not affect anything outside of the repository. THAT is the real power it. Now to be fair, there is a compromise solution for the linked in post. Instead of passing a predicate, require the user to pass an object of filters, a class where each public property is optional (unless you require some) and nulled by default. Then in the implementation you use that filter object to decide how YOU want to build that query. In other words, you turn the database into kind of a REST API with requests and responses except way more simpler. You get the best of both worlds. :)

Thank you for making this video which made me understand how to start with Hangfire. I had a look at it and it is really interesting. At my work we use Quartz especially for recurring jobs. I had a deeper look at Hangfire for this feature and saw that Hangfire cron expressions do not support seconds whereas Quartz do. I find it really deal breaker for Hangfire because all the other features are really cool especially the ability to not run all the jobs concurrently which is not supported by Quartz. Quartz is only able to avoid two identical jobs run concurrently but not two different jobs whereas Hangfire can do it.

Hopefully integration with Aspire will become available soon.

I had to dump hangfire for quartz net because hangfire retry policyfor schedule jobs doesn't work as expected, and it does not allow me to run jobs in parallel.

HF just works and fairly simple and easy to setup

I introduced Hangfire into the last company I worked at, and at first it was amazing. Once we started using some of the more advanced features, it started annoying us more and more. It would frequently lose logs. Jobs would die and the exception details would not be captured. We put it on the SQL Server instance for the rest of our app, and it would frequently kill the performance for our users just because it was checking the status of various jobs. I'm happy to hear everyone else in the comments have had good experiences with it, but I will never touch it again

What if the prod user is iis don't have permission of create table?

Really interesting, I'd love to see more in-depth preview, especially since I've been looking at Microsoft's Durable Functions, but also been wanting to move away from requiring MSSQL (esp since they don't support an ARM64 Docker container atm).

Hangfire is great to do background job but the dashboard becomes really slow after some time because of past data.

there is so much ways to create background threads, I would not use this lib at all. Only if I had to

Hangfire is terrible. I’ve had cases where I’ve disabled schedules and they still run. The database has a fully qualified namespace to a method that will run and it invokes them when it shouldn’t.

I've never heard anything bad about hangfire so I started using it recently and... I ran into problems with it, particularly with long-running tasks. I'm guessing it's because I should have been using background jobs instead of regular(?) jobs