Same here.

That is not the problem here. I am having it do one page from one form. Yes, of course, I review and revise. I don't expect AI to produce complete, bullet-proof code. I don't have that much experience writing HTML and the byzantine world of CSS. Compared to WinForms (with a designer) and C# code, HTML/CSS (with no designer) is so backwards and unnecessarily convoluted, it saves me time. I have written HTML/CSS by hand like the cavemen did, but it takes less time to design the page in WinForms, then export it via AI (all within Visual Studio) than hand coding the HTML/CSS. I've known many web front end coders, and they all think they can write a fairly complex page quicker than a designer, but in real world projects, the WinForms folks have always finished well ahead of the hand coders. The trick is to realize I just want the WinForms to have the UI components and validation code (events in WinForms, things like onclick or mouseover), and let Copilot in Visual Studio generate the Blazor page file(s). From there, almost all of it is just C#. In short, just have AI do whatever takes me more time by hand. I keep it as simple as possible.

It occurred to me the other day that Chat GPT might be able to convert a C# WinForms form to HTML, or at least it would be interesting to try. ChatGPT 4o[^] seems to be a bit improved over ChatGPT 4. I would not be surprised others have tried the same. So, I created a simple Windows Form, with some labels, textboxes, a drop-down list, a checkbox and a button. I then uploaded the contents of the Form1.cs, Form1.designer.cs, and Form1.resx files to the chat, and asked it to return the code for an HTML page. I also asked it to return a Blazor razor component page. It did a pretty good job. Not perfect, but for trying to convert the UI portion of a WinForms application, it could save time from simply manually doing the conversion. I did not try anything complicated, and I would not expect it to translate the C# code to code for Blazor, but I plan to experiment further. Since this forum is not for programming questions, I am hesitant to provide files, but you should be able to replicate the process yourself. For those interested, it might make an interesting thread.

I have enough space already (between my ears). I wouldn’t know what to do with more.

Maybe it was a poor attempt at humor given this is the season in the US for students going back to school. Unless they meant the Scottish-English meaning of registering firearms. 🙂 It is the political season in the US, also.

I am almost 70, and still love working as a .NET/Azure developer full time. I keep up with changing technology (recently built my first production Blazor web app) so I don’t let age and experience get in the way of being proficient in current and coming technologies. I am sure the day is coming when I either can’t or don’t want to work full time. But that day is not here yet, nor knocking at the door (yet). To preview retirement, I work from home 100% remote. My wife and I worked out the issues of me being home with her 24x7. I have my room for daytime work with a refrigerator, bathroom nearby, and a small kitchen so I don’t get in her way. She comes down to visit and watch TV when she wants to during the day. If possible in the reader’s job, try a year or so of 100% remote before retiring. It sure helped us.

I’ve never (or, not yet) had an update mess up my machine or my apps, but I wouldn’t say it can never happen. Isn’t there a setting for updates that lets you postpone them (see if others get bricked in some way first) or only do them “on demand”?

Do you have any spare Borg nanoprobes laying around? 😆

My refrigerator and freezer both beep if left open too long.

I think you over-exaggerate the issue when it comes to hardware as the cause. I do agree there might be something that causes many current customers to shift back to using their own sites, though. Cloud vendors rely on the Internet and private telecommunication trunks being stable and nearly 24x7x365. All it takes is a determined, organized, enemy like the ChiComs, Russia, or Iran to use hidden terrorists to covertly and physically disrupt communication nexuses. That is low tech, easy in and out, and only needs to be in a varying set of remote locations. Inconsistent TCP/IP connections, or worse, high latency connections, would cause disruptions to business that would negatively affect revenue and/or net profit. Then they would look to bring their systems back in-house where access by the company users is a private, physically local, network. Just a few such low tech attacks on nodes where Internet communication lines have junctions or are exposed enough, primarily rural areas, would be enough to scare enough cloud customers away and significantly drop cloud revenue below what is necessary to sustain cloud operations profit. A wise cloud vendor should already have an internal project to package their cloud software for those wanting a private, collocated, cloud. Intelligent enough to discover what is there on the network, and prompt the installer on what they can install under the license. But are any cloud vendors smart enough to see that market now and over the next 10 years?

Your argument might be believable if Azure's hardware underlying the "cloud" were static. But, like any remote site, cloud or not, the hardware is upgraded as needed. That changes the calculation since newer hardware will improve in speed, reliability, and quantity, and as it has for decades, lower in capital cost. Since you did not mention that your definition of scalability has little to do with the commonly used definition, it is natural that readers will take the usual definition. You also overlook the competitive factor in keeping prices down. Price pressure generally results in a compensating rise in ingenuity that lowers costs. If you do not like the cloud providers, you might find a better argument than something this.

Non-scalable? How? I've had no problem scaling.

Writing your own access and encryption security algorithms from the ground up, requires a level of mathematics and security experience not usually found at most companies. However, extending existing security services/systems like OAuth2, Azure Active Directory (or whatever the current name is), Azure Front Door, etc. with additional steps to weed out unwanted access, is a good idea if you can identify specific areas of attack not already in those tools. Plus, from a business and liability view, using a third party access control system reduces overall cost, and shifts potential liability of a breach to that third party (e.g. Microsoft).

I see that in operation every day in software development. The primary cause comes from the trend where non-technical managers have decision-making power over the technical (development) team. They took QA out from under the development manager, so now a QA manager has authority to dictate to development how to manage the SDLC, even though QA rarely has the knowledge, skills, and abilities that software engineers do. Then, non-technical CxOs decided that the one(s) in charge of software engineering decisions (e.g. CTO, VP Software Development, etc.) did not need to have the depth of knowledge, skills, and abilities that the senior software engineers do. The end result is having non-technical people making poor and uninformed technology decisions based primarily on management techniques suited for manufacturing production lines. Hence, since meetings can be useful tools for non-technical business operations, they wrongly think they are productive for IT and software engineering. Lots of meetings (including daily standups) create great inefficiencies and lower productivity and quality. The intellectual rigor needed in software engineering and IT in general is easily derailed by too many meetings interrupting the day. I have seen the decline in code quality in several companies over the years from this non-technical business management approach. The decision making roles, that directly interface with the business end (sales, marketing, etc) of a company need to be currently proficient senior software engineers with a solid business understanding and the ability to translate “geek speak” into the language of business, so that non-technical business types can understand. The business side of a company should limit their involvement to defining requirements in a timely manner and leave the technology decisions (and costs within a budget) to those who fully understand the technology across the entire life cycle.

Those of us who are Navy Nucs deal with this topic a lot. The academic depth and rigor of Naval Nuclear Power School, combined with the “hands on” training in prototype, lends itself to whether we are/were “engineers”. When I worked as a control systems engineer with Barber-Colman, the PEs I associated with referred to me as an engineer, but not as a PE. They relied on me for the theoretical, analytical, and operational information related to control systems (particularly computerized ones), mechanical engineering, electrical engineering, and computer systems engineering, without any criticism of me not being a PE. I never represented myself to them as PE, explained I was a Navy Nuc with 2 years of college in chemistry and physics. Usually, they were sold at "Navy Nuc". From https://dictionary.cambridge.org/dictionary/english/engineer engineer, noun, en.dʒɪˈnɪr 1. a person whose job is to design or build machines, engines, or electrical equipment, or things such as roads, railways, or bridges, using scientific principles: - a civil engineer - a mechanical/structural engineer - a software engineer 2. a person whose job is to repair or control machines, engines, or electrical equipment: - a computer engineer - The engineer is coming to repair our phone tomorrow morning. 3. a train driver Professional Engineer from https://www.nspe.org/resources/licensure/what-pe To use the PE seal, engineers must complete several steps to ensure their competency. - Earn a four-year degree in engineering from an accredited engineering program - Pass the Fundamentals of Engineering (FE) exam - Complete four years of progressive engineering experience under a PE - Pass the Principles and Practice of Engineering (PE) exam Sticking to the actual meaning of the word “engineer”, those of us who design and build software using scientific principles are, indeed, engineers. There is a good argument to be given in the context of software, that coders are not software engineers. By being a “coder”, I do not mean a programmer who just mindlessly churns code out of some “stream of consciousness”. I mean it to primarily be one who thoughtfully writes code, uses design patterns and other “that’s how most everyone else does it” processes, rather than apply good engineering principles to develop according to a well-thought out plan that is flexible enough to accommodate changes along the way. Being a coder seems to be the most prevalent with traditional HTML/CSS/JavaScript programming where the

Sort of. The first several years I was in software development, I learned more and more, which helped me to improve code I had already written. It wasn't that my code was "stupid", but that I just learned newer and better ways. Second, as the language I use improves, it provides better ways to do things, but it is up to me to discern whether the "better way" is really better. Third, there are those team leads who are less knowledgeable and experienced, and make me rewrite code to how they think it should be done, even though I can make the clear case their way is not better. In those cases, I do what the lead says do, then inform him or her of the shortcomings it causes. In a lot of cases, they then agree (after a lot of wasted time) that I should do it the way I had it. Sometimes, though, pride gets in their way, and they make me put out the stupid code into production - problems and all.

A good, but old and oft repeated question about JavaScript (JS). Most of those who make their living in the HTML/CSS/JS world span the spectrum of loving it to putting up with it in order to make a living. Like generations of developers before them, change is often resisted. There is nothing wrong with liking JS and wanting to stick with it. In past generations, FORTRAN, COBOL, QuickBasic, Visual Basic, Delphi/Pascal, etc. developers were in their "comfort zone", and did not want to learn new languages, frameworks, and newer ways to design software. What I write is not a criticism of those who like or want to stick with JS. It is an explanation of why many software engineers would like to move past JS to newer, better, technology. To answer the question, there are several reasons some software engineers do not want to use JS unless they absolutely have to. It is not so much a dislike, but a growing realization that JS is not as suited for 21st century software development as newer, OO, compiled, languages that are designed for broader functionality or extensible to take on new functionality. Many software engineers don't want to be locked into older, less flexible, languages like JS when they can choose from multiple newer, better suited languages. Here are a few of those reasons. - JS is not object oriented (OO). OO design and programming has a lot of advantages over procedural languages like JS. Tools like TypeScript try to overlay some OO techniques over JS, but in the end, what is emitted from TypeScript is still non-OO JS. - JS is a script language. It is not compiled but run by an interpreter. There are some tools that try to approach the benefits of compiling to machine code, or at least byte code for an intermediate just-in-time interpreter/compiler, but the execution speed of JS is slower than compiled languages, especially ahead-of-time compiled (to machine code) languages. - While JS is supported well in the browser (with inconsistencies between browsers), running JS as a server-side language is slow and not designed for that. Compiled, OO languages work much better server-side. - JS tends towards being cryptic, not as developer-friendly as modern compiled OO languages. - JS was never intended to do a lot of what it does. In 1995, the beginning of the dot-com boom, Netscape assigned a programmer, Brendon Eich, to create a language for the Netscape browser to allow dynamic behavior that had Java-like syntax (which is mostly C/C++ syntax), but not derived from Java. Brendan Eic

The best technique I have found is what I do before I have to merge. I create my working branch from whatever “main” branch is “gold”. Every morning, I merge that main branch into my working branch to pick up any changes others pushed up. At worst, there is an occasional small manual merge affecting a line or two. Then, when I create my pull request to merge my working branch into that main branch, I don’t have merge conflicts. A little preventive medicine goes a long way.

It isn't always because we don't know something about what we reject. Sometimes it is just a reasoned analysis after learning, to a degree, how to use something new. JavaScript (JS) intersecting with my own experience is a good example. I came from a background where, over the years, I had written programs in FORTAN, assembly, a proprietary Barber-Colman language for a specific industrial controller, COBOL, QuickBasic, Clipper/xBase, and Visual Basic. I knew C and C++ well enough to read and understand but did not write in it. When web development became more prevalent in the mid 90s and beyond, I looked at JS in the early 2000s (and again in the 2010s and today) since it was integral to websites (and superior to VBScript, its initial competitor). By the mid 90s, I was used to the benefits of object-oriented programming (OOP). As I started to learn JS and see code from its use in the real world, I looked at its productivity potential, its history, and how it is executed, I saw some drawbacks that I didn't care for. JS was not originally intended for the kind of interactive apps we see today. Neither was HTML and CSS. But over the years, necessity and technology improvements have resulted in kludges in JS to keep up. IMHO, the two hardest areas for JS is it running as script, and not compiled to the machine level, and a lack of OOP. When I convert older ASP.NET programs, heavy with JS, to WebAssembly using C# (though any supported OO language would yield the same analysis), I see the productivity gains, the performance gains, the flexibility, fewer (almost no) browser incompatibilities, and less code needed. For someone who has years of experience writing JS, they can be productive to a degree. Opening the frontend logic to OOP languages instead of JS opens the developer pool for organizations creating the websites to more of their programmers, lowering cost and shortening the development portion of the SDLC. JS is not bad, and it got us to a point where more was demanded of websites than JS could deliver and still be JS. Browser manufacturers adding the WebAssembly engine, based on meeting open source, standardized requirements, is where web app development is more economically delivered and maintained, performance is better, and OOP is integral. Just as the Single Page Application (SPA) was a revolution in bringing one of desktop apps' stateful advantages to web apps stateless limitations, WebAssembly is a revolution in web apps that is needed, however much it is resisted by the JS communit

I agree 100%. I have used the MS development IDE since they introduced it in Visual Basic in 1991, then forward into Visual Studio for .NET around 2000. The main thing VS needs is a visual designer functionally on par with the existing one for WinForms (which dates back to VB in the 90s and updated well over the years) to bring that same rapid application development (i.e. drag and drop UI building) to MAUI, WinUI3, and Blazor. Components like "Hot Reload" don't even come close to improving the productivity and quality of the UI like a visual designer does. Without visual designers, just how "Visual" is Visual Studio?