mtone

I think low-code/no-code is misleading since it means vastly different things.

For example, Zapier is a flow automation tool in the broad RPA category - they automate triggers and steps between different existing applications. The "code" version of these things is usually data integration plumbing that be built as a FaaS in a few weeks.

This is completely different from say, Salesforce or Dynamics 365 apps, also low-code/no-code but where the platform's goal is to build applications tailored to your requirements using the platform's customizability, database included. The "code" version of these things are fully fledged web applications that take months or years to build. This is a much higher bar to meet for these platforms.

There's a relevant term called "DDD Trilemma" (I like it because it's easy to find back articles on it). It states that you can't have both a pure, complete and performant domain.

For example, I think what you describe is opting to inject a service to the domain that makes it indirectly talk to the database. In light of the "trilemma", we can imagine it sacrifices a little bit of purity (external dependency, stronger tie to the database schema) in order to keep things simpler -- and nothing wrong with that. In some cases performance could be affected too (ie. if the natural logic might want to update an entity twice during the course of a transaction).

But you still have "completeness" in that you can query your domain as one unit and handle logic within it.

I like that the "DDD Trilemma" acknowledges there is no universal, perfect solution for handling the object-relational mapping problem.

I don't have numbers but I thought the motivation is that they make more money by making it safe for people to use - it encourages use and nets them more transaction fees. It probably helped kick off online shopping.

On FF desktop it doesn't bother me too much, but on iPadOS Safari I was having quite a challenge editing a URL param due to selecting all on touch with no obvious way to switch to cursor mode (!).

My solution: touch to select all, touch again to reveal sliders, drag the (only visible) left slider to the right to reveal some unselected text, touch the unselected area to get a cursor, touch+hold to drag cursor to end of URL, edit URL, profit! I've seen easier puzzles in puzzle games!

As teenagers when they realize that you (or any family member with access to the server) can look at all their emails, they will most certainly never use it for anything personal and/or move away to gmail as that would massively improve their privacy situation!

It's not just idiomatic but pretty much standard in C# to have a single file per class so it's a fair criticism.

I also agree that relying on database schema is a show stopper.

First counterpoint: As long as data type information isn't completely messed up, I can dump excel spreadsheets in a database, or dump database CSVs in a data lake, and start querying them right away using SQL with complex joins using auto-completion from the dataset alone.

Second counterpoint (harder to communicate): I work with a SaaS database (MS Dynamics/Dataverse) which doesn't provide direct SQL access and is not supported by common ORMs. Some of the data APIs require relationship schema information which invariably put a needle in attempts to generalize functionality, or just consume.

In this context, creating a simple in-memory test database or serializing records between modules, cannot possibly function without also knowing schema information if queries are going to make use of it. So now you need to carry schema information for everything, and load it at run-time from generated code or a live database, in back-end and front-end, just to interact with data where simple SQL would have worked just fine.

Conclusion: I dislike the proposal -- even if not breaking backward compatibility, it brings database-configuration details to SQL. SQL is imperfect and is already hurt by database-implementation details (like date functions) but it remains a beautiful expression of relational algebra and set theory - a query given the same data should return the same output, regardless of context. SQL is lingua franca for a reason.

The proposal feels like a fairly specific developer-centric extension and isn't where SQL should be headed, in my opinion.

I'd say Microsoft already has this with Dataverse/Power platform? It runs on Azure SQL Server but it is not exposed directly nor uses SQL server's ACL. Instead, the available access points -- mainly its web API -- honor the permission system configured on the platform, whether it's coming from apps themselves, custom JS code or reporting tools like PowerBI. Users are of course AD users.

Model-driven apps on Dataverse are exactly how you'd imagine MS Access if rebuilt as a SaaS product, and they integrate with Office in various ways. One Azure tenant gets one Dataverse database-- it's certainly intended to host multiple apps sharing the database.

Main problem is that building meaningful LOB applications on this type of low code platform is difficult. Works well for a toy project, or ends up being engineered solutions maintained by IT -- neither hitting the sweet spot mark. I guess general purpose low code is hard.

So the 15" M1 laptop will let you custom boot if you manage to decipher its undocumented internals, but the 10" M1 tablet will actively shut down attempts on the next update. Great.

They did it on iOS countless times to prevent rooting the device. Not sure how that's supposed to be different as the tech converges, but I never owned a Mac so that's all I know of Apple.

Unsaved work should be a concern of the app, not the OS. The app should obey the commands of the OS, and handle auto-saving on its own to keep fulfilling its duties to the user.

Apps that let you risk losing work -- from not just shutdowns but crashes and power outages - are the ones I don't tolerate. It's one of the reason I use Sublime Text for taking notes for example.

Here our tests are written in BDD (behavior-driven development) style, mimicking user actions and data expectations. During development, these are run against mocks (either in-memory DB or a mock repository). Individual small scenarios are also combined into realistic long-running processes, for example cases from opened to closed taking various paths.

The suite runs in parallel fast and frequently alongside unit tests. Then occasionally like before PR merges, the same scenarios are run against a clone of the production environment to catch any mismatch with the run-time environment, also in parallel (connections) to simulate multi-user usage. Any technical issue prompts an improvement of the mocks and rarely resurfaces.

Running these as scripts also doubles as a fake data generator to play with for manual testing, reporting, etc. Last we proceed with some manual testing to validate new changes and pick-up UI-related issues - we don't do UI automation.

Not sure what % of motherboards support USB BIOS Flashback but I remember AMD in Ryzen 2 era shipping out "loaner cpus" exactly for that purpose -- so people could buy a CPU/AM4 motherboard combo that needed the BIOS upgrade to boot it.

In the JavaScript ecosystem, most the challenges with repos are not the code but the tooling. SOLID principles are not going to solve that.

In our monorepo, few changes are cross module. But its a grand day to reduce total package count by 20 by finally getting rid of some old project dependencies and being able to use a single test runner config and version across packages. I keep my sanity that way.

Meanwhile, our non-JS repos haven’t required as much attention in this area.

> By that logic any proprietary product that provides an interface with an open source tool is guilty.

In my view, the entire PaaS ecosystem modus operandi is building on top of open hardware & software, allowing and enticing people to move in easily (familiar tech/open source), and making locked-in products out of them. If that's not EEE I don't know what is.

Instead, just don't run executables from untrusted sources.

Torrents, email, mobile apps (like that fake banking iOS app that looks like the legit one) or otherwise. The transport method doesn't matter much.

I would think 2FA-in-masterdb still protects you against some website hacks, most browser exploits and phishing sites, using your password on other potentially compromised devices (public wi-fi, work, etc.) and probably some keylogger scenarios that would miss the database content.

And public sentiment is not the same everywhere - for instance, the US tends to be more suspicious of government than of (large, public) corporations whereas elsewhere it's the complete opposite.

I’d argue that in some cases it can be more testable than code. With a small, strict subset of a turing-complete language and constrained input choices, you can often auto generate test cases for any valid expression in a given context. Static analysis of code is much more difficult and broad.

One thing code versioning doesn’t do well either is executing multiple versions of the same logic. With rules as data, you can store them as timestamped versions and keep applying the correct historical rule against some older business object or view.

Xbox Game Bar is very limited. It only captures a single window not the actual desktop, so you won't see any other window, dialog or context menu.

I noticed it when I tried to record a demo of a git merge flow in an IDE. Fail!

I wish this was properly built-in on Windows, since the recording is otherwise excellent.

Connecting to a Microsoft Teams of Office work account from home gives you the fantastic "Use this account everywhere on your device".

It has 4 effective choices [0] with no clue about what's going to happen to your windows account and what data or remote control permissions will be sent to your organization.

[0]: https://engineering.purdue.edu/ECN/Support/KB/Docs/HomePCsud...

I just use FTP.

I still use it to sync folders to my iPad (from Documents Readdle). Since walled gardens don't leave much options open, it's basically either that or a cloud provider -- and no free cloud plan has enough space to store these folders.

So FTP wins easily this one. It's free with unlimited storage, always has been, always will be.

Indeed, they will perform the same or very close (the query plan might differ a bit due to the different orderings). Not sure where the author got that from. I'm complaining about the docs only.

> This syntax is not as commonly used as the one above

This is going to need some sources. Is it true today? And why did they put parentheses in the ON condition?

Worth nothing that there were variants of the WHERE syntax to support left joins using vendor-specific operators such as A += B, A = B (+) -- those are clearly deprecated today. [1] [2]

I have a really hard time finding any source on the internet that recommends using the WHERE style joins. So by extension, I wouldn't expect to be used much anymore except for legacy projects. MS SQL Server docs docs mention ON syntax being "preferred" [3], and MySQL says "Generally, the ON clause serves for conditions that specify how to join tables, and the WHERE clause restricts which rows to include in the result set." [4]

The PostgreSQL docs seem misleading and outdated to me.

[1] https://docs.microsoft.com/en-us/archive/blogs/wardpond/depr...

[2] https://docs.oracle.com/cd/B19306_01/server.102/b14200/queri...

[3] https://docs.microsoft.com/en-us/sql/relational-databases/pe...

[4] https://dev.mysql.com/doc/refman/5.7/en/join.html

My iPad Air 1 is aging, slow, and I loved it but I simply won't replace a machine where a publicly-funded news/docs store app in particular gets laden with unskippable ads.

Half a thousand bucks for this frustration, no thanks! No amount of content/entertainment is worth this.

I've asked a few times my team whether they see value in our daily meetings, mentioning that it can easily disrupt flow, might have less value than ad-hoc focused meetings or chats on particular topics, and worse of all for me - might be counterproductive when we tend to wait the next day to address something and then opt to discuss it further separately.

Response is always the same: during lockdown/WFH, it is one of the few times -- sometimes the only one -- we get to talk and hear other people so they'd like to keep it.

So instead I'm trying to move away from it being a traditional scrum round-table and try to move towards chit-chat, show and tell, general updates, group quizzes, etc. All more useful probably.

What worries me is the testability. Too many variables, especially external unpredictable ones injected by browsers and user stylesheets, means accessibility testing combinations explode further than they already are.

Full-page zoom - something I imagine was less common in the past for performance reason - is much more in line with "how the site was made, intended to layout as, and tested for."

It's nice that the HN header bar doesn't grow on font-zoom, but it's hardly a killer feature (edit: and isn't even supported on my iPad where I'd want it). I always full-page zoom and was never bothered by it or even noticed it. But clearly half the web is broken for font zoom. I'd say don't fix it, leave it behind instead. Just like 14px doesn't really mean 14px anymore and that's ok.

What is the use case for font-only zooming?

I just tried it on a few sites and it either doesn't change much/anything or breaks stuff -- either by overlapping text, or not increase the width of text zones so you end up with few words per line in the middle of the screen which was particularly bad on a newspaper site (along the ridiculously undersized article photo).

I thought it could save some space in headers and such if they don't zoom those, but if they used ems everywhere as might be best practice then there's no win to have.

So it's either the same or worse than full-page zooming in every test so far. This is not only a now-obscure feature, it should be considered deprecated imo -- zooming (or changing default) font size feels like hijacking a responsive web page source and hoping for the best.

Assuming we're talking about VMs (2021 etc.), for a SME is there any downside to giving 2TB of space to your discs and let dynamic allocation do the work?

Perhaps consolidate/defrag once a year. Even monitoring total usage more often than that is probably not worth the effort - just buy ample cheap storage.

Also, there was a tradition to split drives into OS, DB, DB Logs. That was mostly a rust performance thing and these days is probably just voluntary management overhead.

RAM is another story.