StackOverflow answers are outdated. Every time I end up on that site these days, I find myself reading answers from 12 years ago that are no longer relevant.
There have been many times I have seen someone complain on the meta site about answers being old and outdated, and then they give specific examples, and I go check them out and they're actually still perfectly valid.
I've been using this unofficial client for years, so it's been a while since I tried the PWA version. In my use, this client brings 2 things missing from PWA: notification count in the tray area, and respecting default browser for opening links.
I thought I could get by without a tray icon, but it turned out to be too cumbersome to have to explicitly open the window and make sure no one messaged me while I was at lunch, or whatever.
I use firefox for my main browser; and teams doesn't work great there. So I have to use Edge or Chrome. But then, when someone sends a link in Teams, it opens in that browser. This unofficial client acts like an actual standalone app and opens links in my default browser. Now if they sent a link that lands on some other office365 thing, there is about a 15% chance that just won't work ;)
But yeah, if you are able to mostly avoid this POS, then those 2 things likely don't matter and PWA is fine.
For notifications, the Administrator needs to enable the NotificationsAllowedForURLs policy, which automatically allows notifications for Teams on the web:
I would have no problem with a company saying "We really like you, but we found a better match for role x. If you're interested we think you'd be great in role y and here are the details." If I don't like the compensation of role y, I'll simply decline.
Any time a relative asks me which printer they should buy, I tell them to get the cheapest Brother laser printer they can find without wifi. I mostly do this to save myself support calls, but it's also the printer I use in my own house.
I bought the cheapest Brother laser printer in the early 2010s because someone on a forum gave me this same advice. It has worked without issue ever since.
A few years ago I plugged it into a Raspberry Pi so that I could share it via CUPS to all the family's PCs. This has also worked almost without problems (the exception being it had to be reconfigured a few times on my wife's Apple laptop). A year or so later I realised that while connected to wifi I can print from my Android phone. The phone found the CUPS server and the printer without me doing anything at all and it has never gone wrong.
Some new HP printers lock scanning on the printer side unless you sign in with an account, any printer with an e at the end of the model number won't even let you print to 9100 without an account.
A (very) recent HP inkjet firmware update just broke all inkjet cartridges older than about 18 months. Including cartridges from HP.
Neither the on-device or OS mediated error messages explained this. I only figured it out from other angry users on reddit.
How was my mom supposed to have figured this out? She didn't know that her printer had updated itself a few days earlier. She doesn't even know what a firmware update is.
In a world of class action suites over batteries, chargers, keyboards, etc., why isn't HP being sued?
I kinda did this. Cheapest Brother printer, but with WiFi. Which is exclusively how we use it. Been flawless, printing from windows laptops, macbooks, iphones...
A few years ago this is what I did. Got the cheapest Brother laser printer. Happened to have wifi, but managed to disable it. It's been working solid via cables for years.
I've written C# code that deadlocked a webserver, C++ code that crashed a computer lab, JavaScript code that made the browser unresponsive, a SQL migration that accidentally deleted too much data. I don't really know what point you're trying to make, but bad code typically behaves badly.
The non-tech F500 I worked at several years ago is doing everything they can to abandon .NET/Java in favor of low-code tools. Their engineers are jumping ship and they're having a hard time finding replacements.
>in favor of low-code tools. Their engineers are jumping ship and they're having a hard time finding replacements.
I have a friend who works for a major low-code software company. They're doing quite well financially because of all the excitement around low-code. The product is good if you stay within the boundaries of what it can do. Some managers people think they can replace their enterprise Tableau/Spotfire/PowerBI license with low-code and they get bitten very badly.
Finding engineers for a low-code environment is a challenge. You need to understand software development well enough that you can build something because loops, conditional statements, all of those concepts are there. You also need to find somebody who is willing to possibly lock their career into a single tool and forgo the benefits of knowing a general purpose language like C#, Python, etc.
Some companies have success with finding technically minded business people or IT folks who don't enjoy coding and training them. They can thrive and build some nice apps. Lots of folks can't make the leap and fail. Software Engineers are probably the worst bunch to try an convince because the opportunity cost is too high.
My nonprofit works with a very talented Microsoft consultancy to help our transition from on-prem servers to Microsoft 365 cloud. My main contact there (Director of Biz Operations) says they have transitioned most of their custom development from .NET to Power Apps/Power Automate. It's not the only toolset they use, but he says it's the right tool for many small-medium biz CRUD needs.
This is the direction my current employer is headed. I was sent on a week long course to evaluate the viability of PowerApps. While there is certainly some cool stuff in there, it just doesn't feel like we should be moving all our development there wholesale. There is certainly a time and place, or at least that is how it seems to me.
Business / money making / crucial systems? No. Some random HR survey application? Maybe. Sadly Microsoft seems to have convinced a number of folks in our organization that this tool set is appropriate for all our development.
Interesting, there was some low code at the last F500 I worked with, but mostly for very small tolls not requiring much of any business logic.
Majority of the services were older .NET framework projects with some other stuff scattered around. They had a sizable mainframe team, but we’re trying to migrate away from that platform.
I-80 always comes to mind when these autonomous vehicle discussions occur. I'll believe in autonomous vehicles when I see them driving across Pennsylvania during a winter storm. There are days where I seriously doubt an autonomous vehicle would be able to navigate out of my driveway.
Teams is the absolute worst piece of software I have ever used. Simply logging in only works about 50% of the time. This wouldn't be a big deal if I wasn't randomly forced to the login screen every few days. I experience a different bug every other day. I can't be signed into multiple orgs at once (on desktop) meaning I have to fully sign out/sign in when I want to switch and it takes forever. Notifications are unreliable. I miss Slack so much.
My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.
I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-)
Just be glad Gradle hasn't entered the JS scene yet:
With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned.
With Gradle however I haven't seen two similar setups so far. Edit: I might have seen two similar setups.
Gradle is capable of very powerful things so on larger projects there is generally a project specific Gradle dialect in play and I can understand why this frustrates newcomers but it's an important capability for large projects and monorepos.
I would say most small projects (especially OSS) tend to stick to a simple subset of Gradle even if it's multiproject build etc.
The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff where all this complex stuff just makes sense.
I find working with Gradle infuriating. It's layers upon layers of magic. When something breaks, you get a baroque error message, a usually useless stack trace, and a suggestion to re-run the possibly very long build with -info or -debug. At that point, instead of not having enough output, you're usually drowned in megabytes of irrelevant messages.
This is what I was referring to the knowledge cliff.
Gradle is incomprehensible until it isn't. It has a very steep but short learning curve and understanding is completely binary. It's very unfortunate but it is how it is.
I still take it over the JS stuff but I do acknowledge it's shortcomings. I also don't do Android development so I don't know if it's particularly bad there.
The knowledge cliff doesn't end with Gradle because it's infinitely extensible. So you have to understand all the plugins as well. Because there is so much implied magic happening behind the DSL, when it breaks, you don't have a clue why. Reading the documentation is often insufficient, you have to track down the source code for the version of the plugin you're using.
In general, I find DSLs make my life harder, not easier.
Gradle is my least favorite build tool ever. It's just too much magic in too many places.
This is not an endorsement of the JS ecosystem either. It also sucks, but it has wasted less of my time than Gradle (again, in the context of Android).
