I am an IT architect by trade but still a passionate developer. With over 30 years in the IT industry, I have been there and coded in it. From 'back in the day' COBOL, assembly language and C/C++ to modern C#, Java. JavaScript, HTML, CSS and all the frameworks, source control systems, fads, trends in between. Can you imagine writing and debugging a program by punching holes in cards and feeding them into a reader. Look how far we've come and be grateful you'll never know :D.
On this channel we'll discuss all things IT related. Frontend, backend, tutorials, advice. Anything that I consider will help a fellow developer in the trenches out.
So, if you're a developer in your day job, aspire to be one or just interested in technology, subscribe and come with me and explore weekly short tutorials on any IT related topics to fully functional real world IT solutions that might just help you in your IT understanding.
I am using Net8 and have carefully checked the basic setup. Maybe I am missing something, but when I run and execute the Yak script, it returns 404. Any assistance is greatly appreciated.
Ok, the default project for .net 8 does not include the Controllers directory and also does not contain WeatherForecast.CS (model.) All the code is run in the program.cs. I created the Controllers directory and added it to the Service1Controller. Also, when I copied the WeatherForecast from another site, I had to edit the datetime to dateonly type. One last note, I deleted all the WeatherForecast code from the program.cs. Works like a charm.
thanks for the video. I'm using vps with local container registry with docker, cost me 260$ for two years but I got 200GB storage and 16TB bandwidth so cost comes down to 0.36$ /day. However I have to manage security backups and authorization for which I'm looking into now.
Interesting take. I'm concerned if too many requests come in, and I have all these queues/threads (creation/disposal). I did something similar, but to avoid exhausting threads, I used a BlockingCollection... on startup, the BG service created as many worker threads from the available cores (16 in my server). In each thread, I attached to the blocking collection through its enumerator, and it managed dequeuing safely for, So at the end, I had 16 threads safely handling any request that came in. I tested it with K6 sending about 5000 requests at its peak. While the collection had to queue up, 16 requests were being processed in parallel. It beat the hell out of the server, but then I could easily scale it out to have more threads available -- haven't done this yet, but so far, the server in production has not caused me any issues.
THIS is the video you need if you need to run Linux containers on WSL. Setup Docker on Windows using the docker binaries, and setup docker inside of the default distro running on WSL. setup the json file on windows and place in c:\programdata\docker\config, and then point the IP address within it to the hostIP 127.0.0.X of the WSL-Ubuntu hostIP address... and then BAM you got yourself a Windows Docker daemon service pointing to a Linux Docker backend. My goal is to have a headless Windows 10 machine running my containers, automated so they start as soon as the computer turns back on from a restart without doing things like logging into a user account, or installing NSSM, or auto locking a user account after it logs in. THANK YOU for this video!! I'm about half way thru the video and I'll say this, this is as far as I've gotten on non-Windows server installing and running Docker on Windows without Docker Desktop.
Hi! I am not able to test the layout for the page. I have the exactly same setup but pageMeta is never called. Is this code still working with the latest vitest updates? Do you know what it could be?
I'd like to see/know if one can use this setup to do container-based sw dev with vscode (i.e. vscode client running in Windows and vscode server running in container), given the necessary vscode extensions are installed?
What is the actual architectural difference? Whatever you have shown it's present in Microsoft documentation also. But I am not getting what's the actual difference, what was the problem in in-process model which is going to be solved here ?
This solved a problem for Microsoft to allow the azure function management runtime to run on a different framework version than your azure function that you have written. In reality It means you can adopt the latest framework version earlier.
Instead of using a composable for the GTM, couldn't I just make a global plugin? Seems a bit wasteful that for example on something like a ProductCard I need to do a useGTM
Is it some kind of joke? "change 1 line of code" in tile, but in actual video "add hundreds of lines of cryptic XML spec". These custom policies are not documented and even Microsoft's support agents do not have resources to provide except some old GitHub repos full of 4-year old examples.
Once you'll try to customize look of the login page you will start to regret choosing Azure B2C. And you will make application admins miserable with Azure AD slowest possible loading times when there is a need to inspect user login audit logs just to see how these logs are incorrect and essentially useless. On top of "no SLA". I regret every day spent on fighting against Azure B2C, especially after learning how many good alternatives there are.
One of the best videos on custom claims. However, this does not work when the user is self-registering. This is because the first time the user registers, their data is not yet in the DB and so the Azure Function won't return any roles yet. To overcome the problem the user will have to log out and back in to refresh the claims which is not ideal. I could not find any solutions for this problem.
I'm not 100% understanding you scenario. First problem - What permissions will you give a new user? You can only give them some defaults unless in your signup you allow them to tell you what role/permissions they want. if you look here learn.microsoft.com/en-us/azure/active-directory-b2c/add-api-connector?pivots=b2c-user-flow You can see there are different types of API connector that get called at different points in the sign-up/in flow. So for signup could you use the 'before creating the user' connector to create the user. For signup and / or signin the 'before sending the token' will be called. So could you not use this connector to create the user with the default permissions if they dont exist in your db?
@@thepragmaticprogrammer Thanks for your reply, really appreciate it. I had a feeling I was not being clear. Here is my issue in details: 1. User visits the app and opens the login page (they're not the in the DB yet and so they have roles). 2. User is redirected to B2C page to log in/sign up. 3. User completes sign up in B2C. 4. Behind the scene: B2C calls Azure Function to grab the roles (they don't exist yet) 5. Behind the scene: B2C generates a token, it does not have any roles. 6. User is redirected back to my app (with the token) to fill out their profile information. 7. User is redirected to the Dashboard page. This page requires a role that is not present in the token. 8. User sees a NotAllowed page. The only way around this is to log the user out and ask them to log back in. When they do this the Azure Function will be able to load the roles. I'm going to see if I can resolve this by using your suggestions. Thanks
I developed a .NET MAUI application to consume a SOAP service. Testing this application on emulators on the same machine, connected to the SOAP provider via VPN, I am successful in the request when using the Windows Machine emulator and not successful when using the Android emulator. What am I doing wrong?
Its an interesting approach. That each request gets its own queue of items that are completed sequentially might be useful or convenient. On the other hand this may not be desirable or necessary. What happens in this approach if 300 requests each queue up a items? Do we really want the number of background tasks to also be 300? Might be ok, might not be it would depend on the type of workload, I/O bound load might be ok but CPU bound stuff would be a problem. Perhaps some further control is needed. The deal breaker, though, is the WaitAll. In a set of concurrent requests where one of them has created a queue workload significantly larger than others. The WaitAll will cause the item pump to stall whilst the large load is completed. Meanwhile new requests are busy adding items to their new queue buffers but nothing is being done while the code sits at WaitAll. The premise posed around 55secs into this video is that queue items from multiple requests are just getting queued behind each other and processed sequentially. A better design I think would be to drop the assumption that queue items are processed this way. Instead assume that a set of items can all be processed concurrently even items generated by the same request. Use a single channel (that never completes) and all items are written to that channel. Use `await foreach` to consume the channel `Reader.ReadAllAync` in the BackgoundService ExecuteAsync. IOW this is the infinite loop (because the channel never completes) and 500ms sleep not needed. inside the foreach dispatch a task but do not await it. Before executing the queue item this new task will first Wait on a Semaphore (use `SemaphoreSlim` as an instance field in the BackroundService) and ensure in a finally block that the semaphore is released. The Semaphore will control how many concurrent tasks can be dispatched. In this approach a queue item will immediately begin execution if we haven't saturated the Semaphore and if we have the next item will start immediately any currently running item completes. No Sleeps, no WaitAll. Multiple queues could be created, say one for CPU intensive tasks that has a small Semaphore and I/O bound queue which could have a large Semaphore.
This is exactly what i was hoping for, a good dialogue on the subject to highlight that background processing is not trivial matter. You have made some excellent points and described a very good alternative. Personally, I had a constraint that meant I could not concurrently process items in the same request. I needed the processed in the order that they were reached in the http request. This just highlights that you really need to understand your requirements and constraints when you design a solution. Many thanks for taking the time to respond.
The only place where this might be a problem is when the background service removes a WorkItemBuffer whilst the background service is still iterating over the WorkItemBuffers list. We want to keep WorkItemBuffer elements to a minimum, process and remove them as quickly as we can. This would minimise this scenario. I agree that a more robust implementation would be to have a lock on both the list iterator and the remove(WorkItemBuffer) - see: theburningmonk.com/2010/03/thread-safe-enumeration-in-csharp/
Masstransit is for distributed applications i.e. separate process. This is all in-process. This presents how to implement a fan-in fan-out pattern for background processing without tying up your http request.
@@thepragmaticprogrammer i think simple in memory queue do the job. But if you want proces tasks sequentially, right worker approach is ok. But queue could be configured in the way that it will behave as sync procesu.
Thanks for watching. Depends upon your use case and is perfectly valid. But using a queue as the conduit between your http requests and your background service only gives you a fan-in pattern i.e. all your workitems are pushed into a single queue. A List of queues allows for a fan-out to multiple threads in your background service.
Hi Thank you for the great video. I have joined your ko-fi page as a member and added my github username, but I don't see where I can access the source code.
What's the point of registration/login without email address? I like this playground overall, but I cannot see any use case for passkey-only workflow. Is it implied that you would ask for an email in the step following registration (making it a 2-step process)?
The username/email address of the user creating the passkey is hardcoded in this playground, in the 'User' object of the createCredentialOptions (see it here ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-tumEVnhgWO4.html). In the real world you would have your user login as normal with username and password, then give an option to create a passkey, thus when you create the passkey you know all the info about the user. From then on the user can opt to login using the passkey and post login your app would contain the same info about the logged in user. Hope this makes sense.
There are multiple issues with Passkeys and I don't believe the actual adoption will match the hype around them. For starters, privacy-focused browsers do not support them. Ok, let's assume devs usually optimize for whatever is most commonly used by regular users (Chrome/Android) - the initial workflow is convoluted, confusing, and usually not what users expect. Ok, ok, it can be said about every technology in early stages of adoption. My third issue is that users have very good alternatives - like built-in password manager in Chrome (that even suggests randomized passwords). From the devs perspective - we already have "passwordless" login with so called "magic links" and it is trivial to implement. Apps that would theoretically benefit from passkeys need users to have specific needs around cross-device access, otherwise it's just pointless to roll it instead of OAuth or SSO... I can go on and at the end... I like the concept but it is just so easy to doubt in claims of "it will be everywhere soon".
Thanks for your feedback and views on the subject. I agree its an emerging area and we need to monitor this to see how it pans out in terms of adoption
The POST endpoint, [HttpPost] [Produces("application/xml")] public IActionResult Post(SOAPRequestEnvelope env) doesn't read in the env param, so you don't have a "round trip". Don't want to be a downer but basically a waste of my time without demonstrating the serialization of the incoming SOAP xml request 😞
You can see it works for others below. There is most likely some mismatch between your SOAPRequestEnvelope (or nested classes) or namespaces and that of the XML you are sending in your request. If you can share a repo, I will try to assist if possible. As a real fallback you could also use [FromBody] XElement Envelope rather than SOAPRequestEnvelope and this will give you a raw XML document of the payload that you can work with (useful if you don't want to model the whole payload, but just do something like Xslt on it)
Try this in your program.cs. Uses middleware to manipulate the response body with a regex to remove those namespaces. app.Use(async (context, next) => { // Set the response stream to a Stream we can manipulate using (var buffer = new MemoryStream()) { var stream = context.Response.Body; context.Response.Body = buffer; // Carry on with the request pipeline await next.Invoke(context); //Read the response stream into a string buffer.Seek(0, SeekOrigin.Begin); var reader = new StreamReader(buffer); using (var bufferReader = new StreamReader(buffer)) { string body = await bufferReader.ReadToEndAsync(); //remove the XSI and XSD namespaces body = Regex.Replace(body, @"xmlns:(?:xsi|xsd)=""[a-zA-Z:\/\.0-9-]*""", ""); //create a new UTF8 encoded output stream var outputStream = new MemoryStream(Encoding.UTF8.GetBytes(body)); //set content Length and copy to HttpResponse Stream context.Response.ContentLength = outputStream.Length; await outputStream.CopyToAsync(stream); //reset response to original stream context.Response.Body = stream; } } }); app.MapControllers();
That gives you free reign over the payload to do what you want. Alternatively and maybe cleaner, you could, create your own XML Output Formatter: using System.Xml; using System.Xml.Serialization; namespace SOAP.Mvc.Formatters; public class XmlSerializerOutputFormatter : Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerOutputFormatter { protected override void Serialize(XmlSerializer xmlSerializer, XmlWriter xmlWriter, object? value) { XmlSerializerNamespaces ns = new XmlSerializerNamespaces(); ns.Add("", ""); xmlSerializer.Serialize(xmlWriter, value, ns); } } Then wire this in in program.cs builder.Services.AddControllers(options => { options.OutputFormatters.Insert(0, new SOAP.Mvc.Formatters.XmlSerializerOutputFormatter()); }) The addition of the blank prefix and namespace passed into the serializer is a well know 'feature' that removes the default namespaces.
