You lose information when DST kicks in - which is not great. It is trivial to convert to any timezone so there is little point in logging in anything but UTC and keeps everything consistent. Especially when comparing dates from servers in different timezones.

So, if you just use the system API, then this means logging with syslog(3). Learn how to use it.

This is old advice. These days just log to stdout, no need for your process to understand syslog, systemd, containers and modern systems just capture stdout and forward that where it needs to do. Then all applications can be simple and it us up to the system to handle them in a consistent way.

NOTICE level: this will certainly be the level at which the program will run when in production

I have never see anyone use this log level ever. Most use or default to Info or Warn. Even the author later says

I run my server code at level INFO usually, but my desktop programs run at level DEBUG.

If your message uses a special charset or even UTF-8, it might not render correctly at the end, but worst it could be corrupted in transit and become unreadable.

I don’t know if this is true anymore. UTF-8 is ubiquitous these days and I would be surprised if any logging system could not handle it, or at least any modern one. I am very tempted to start adding some emoji to my logs to find out though.

User 54543 successfully registered e-mail user@domain.com

Now that is a big no no. Never ever log PII data if you don’t want a world of hurt later on.

2013-01-12 17:49:37,656 [T1] INFO c.d.g.UserRequest User plays {‘user’:1334563, ‘card’:‘4 of spade’, ‘game’:23425656}

I do not like that at all. The message should not contain json. Most logging libraries let you add context in a consistent way and can output the whole log line in Json. Having escaped json in json because you decided to add json manually is a pain, just use the tools you are given properly.

Add timestamps either in UTC or local time plus offset

Never log in local time. DST fucks shit up when you do that. Use UTC for everything and convert when displayed if needed, but always store dates in UTC.

Think of Your Audience

Very much this. I have seen far too many error message that give fuck all context to the problem and require diving through source code to figure out the hell went wrong. Think about how logs will be read without the context of the source code at hand.

I think their though process is more along the line of:

Hey, Microsoft is getting all the bad attention ATM, let’s see how much shit we can sneak in while people are distracted.

They do mention it on that page:

However, if presented with a valid order from a Swiss court involving a case of criminal activity that is against Swiss law, Proton Mail can be compelled to share account metadata (but not message contents or attachments) with law enforcement.

The only ever claim to encrypt message contents and attachments. And explicitly call out account meta data here as something they can hand over if requested by law enforcement. They also mention they are not good vs targeted and governmental level attacks:

There are, however, some risks for users facing a strong adversary, such as a government focusing all its resources on a very specific target.

And explicitly mention they might be compelled to log and give up information like ip adresses:

if you are breaking Swiss law, a law-abiding company such as Proton Mail can be legally compelled to log your IP address.

Whatever language you chose you might want to also look at the htmx JS library. It lets you write in your html snippets better interactivity without actually needing to write JS. It basically lets you do things like when you click on an element, it can make a request to your server and replace some other element with the contents your server responds with - all with attributes on HTML tags instead of writing JS. This lets you keep all the state on the backend and lets you write more backend logic without only relying on full page refreshes to update small sections of the page.

For a backend language I would use rust as that is what I am most familiar with now and enjoy using the most. Most languages are adequate at serving backend code though so it is hard to go wrong with anything that you enjoy using. Though with rust I tend to find I have fewer issues when I deploy something as appose to other languages which can cause all sorts of runtime errors as they let you ignore the error paths by default.

Well, Redhat is owned by IBM now so basically spot on

Yup, and that is because people only ever lean DRY coding by its name. It is never really what it originally meant, when to use it and more importantly when not to use it. So loads of people apply it religiously and over use it. This is true of all the popular catchy named methodologies/principals etc.

Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle).

Even that gets overused and abused. My big problem with it is what is a single responsibility. It is poorly defined and leads to people thinking that the smallest possible thing is one responsibility. But when people think like that they create thousands of one to three line functions which just ends up losing the what the program is trying to do. Following logic through deeply nested function calls IMO is just as bad if not worst than having everything in a single function.

There is a nice middle ground where SRP makes sense but like all patterns they never talk about where that line is. Overuse of any pattern, methodology or principle is a bad thing and it is very easy to do if you don’t think about what it is trying to achieve and when applying it no longer fits that goal.

Basically, everything in moderation and never lean on a single thing.

Refactoring should not be a separate task that a boss can deny. You need to do feature X, feature X benefits from reworking some abstraction a bit, then you rework that abstraction before starting on feature X. And then maybe refactor a bit more after feature X now you know what it looks like. None of that should take substantially longer, and saves vast amounts of time later on if you don’t include it as part of the feature work.

You can occasionally squeeze in a feature without reworking things first if time for something is tight, but you will run into problems if you do this too often and start thinking refactoring is a separate task to feature work.

“Best practices” might help you to avoid writing worse code.

TBH I am not sure about this. I have seen many “Best practices” make code worst not better. Not because the rules themselves are bad but people take them as religious gospel and apply them to every situation in hopes of making their code better without actually looking at if it is making their code better.

For instance I see this a lot in DRY code. While the rules themselves are useful to know and apply they are too easily over applied removing any benefit they originally gave and result in overly abstract code. The number of times I have added duplication back into code to remove a layer of abstraction that was not working only to maybe reapply it in a different way, often keeping some duplication.

Suddenly requirements change and now it’s bad code.

This only leads to bad code when people get to afraid to refactor things in light of the new requirements.Which sadly happens far to often. People seem to like to keep what was there already and follow existing patterns even well after they are no longer suitable. I have made quite a lot of bad code better by just ripping out the old patterns and putting back something that better fits the current requirements - quite often in code I have written before and others have added to over time.

Never seen anyone change it for the mouse, but I think for a joystick and especially gyro it is more common to have them different. Same basic principal applies to all three inputs though.

In first person games the distance you need to move horizontally is often far more then the distance you need to move vertically, quite often only needing to look up/down a small amount. So you can get better accuracy in the vertical direction by turning down the sensitivity without sacrificing the ability to move quickly up and down. But in the horizontal direction being able to move quickly is generally more important than better accuracy.

Not sure how important the difference is for the mouse though, likely why people don’t use it. But it is an easy setting to split up for the developers so why not give players control over it and set it however they like? Would be nice if you could lock them together, but that is a little more complex and requires more thought to do. And I don’t see game devs giving that much thought about the minor user experience improvements in their games settings when they have a load of gameplay still to worry about.

How do we know these are the AI chatbots instructions and not just instructions it made up? They make things up all the time, why do we trust it in this instance?

There is no real technical challenge in displaying ads that are based on the page content. But ads based on tracking users is much more profitable. Plus they can sell the data collected to anyone else that is interested.

The license is MIT, so should be fine for most things

“We had relied and started to rely too much this year on self-checkout in our stores,” Vasos told investors. “We should be using self-checkout as a secondary checkout vehicle, not a primary.”

That is the key point here. Use them to replace the express lanes but dont replace all checkout points with them.

they actually increase labor costs thanks to employees who get taken away from their other duties to help customers deal with the confusing and error prone kiosks

Now that is bullshit… how can it cost more to have someone spend part of their time to help a customer when they have a problem vs having an extra person help them full time during checkout.

Still, 60% of consumers said they prefer self-checkout as of 2021, presumably because they’ve never seen Terminator (wake up sheeple).

WTH… I really don’t understand why this person hates them so much. Seems to have some hidden agenda but I cannot for the life of me tell what it is.

Not all phones need to play games and gaming phones don’t need to use this type of technology. I would love a phone that I don’t need to charge and most people could benefit from one. And for the select few that like to play intensive games on it then they can get ones that would need to be charged.

Though I doubt this technology will be the answer to that want though.

Sorry, clicked reply on the wrong comment :)

Theoretically you could build a male to male contraption from multiple adapters and a cable.

You already can as these exist:

letting you plug in any existing USB A to mini cables together to get a male to male device - nothing unsafe about that though. So this is not a very good reason to not allow USB C to mini adapters.

Also you could be providing too much current to a device, however this is specific to the combination of adapter, cable and power supply you use.

Current is pulled by the device - you cannot supply too much current. Devices take just as much current as they need or as much as the adapter can supply. The only way a device would take more than that is by badly designed or faulty - but that is a problem with the device, if the power supply can supply the power there is no issues on that side.

Also USB C connectors can and do by default operate with USB 2 power - supplying 5V and limiting the current to the USB 2 standards and so any existing charger with USB A or mini connectors on. Thus any USB 2 device will only have access to the power given by the spec. You would require a handshake from newer USB protocols to get access to more voltage/current that some USB C chargers can supply.

There is nothing unsafe about any other this baring faulty devices - but if we worried about faulty devices then we would not allow any electronics devices to exist as any of them could be faulty. USB C to USB mini does not dramatically increase any risk of fire or devices exploding no more so than any device using USB mini or USB C alone.

The real reason is there is likely just not much of a market for them so they are harder to find - but they do exist.

How? Anything with a mini will be USB 2 at most and USB c defaults to lower power of USB 2 without any handshakes with the device which one with USB mini won’t do.

deleted by creator