TehPers

Storing UI assets in a database is unusual because assets aren’t data, they are part of your UI. This is of course assuming a website - an application may choose to save assets in a local sqlite database or similar for convenience.

It’s the same reason I wouldn’t store static images in a database though - there’s no reason to do so. Databases provide no additional value over just storing the images next to the code, and same with localizations.

User-generated content changes things because that data is now dynamically generated, not static assets for a frontend.

I know I probably sound like an ass but it really is that bad

Nah I work in shitty codebases on a regular basis, and the less I need to touch them, the happier I am.

With regards to other localization changes, it’s not important to localize everything perfectly, but it’s good to be aware of what you can improve and what might cause some users to be less comfortable with the interface. That way you’re informed and can properly justify a sacrifice (like “it’d cost us a lot of time to support RTL interfaces but only 0.1% of users would use them”) rather than be surprised that there even is one being made.

Also, user-generated content explains why these are in a DB, and now it makes a lot more sense to me. User-generated translations used as-is makes more sense than trying to force Project Fluent (or other similar tools) into it.

Localization is a hard problem, but storing your translations in the DB is a bit unusual unless you’re trying to translate user data or something.

I’d recommend looking into tools like Project Fluent or similar that are designed around translating.

As for the schema you have, if you’re sticking with it, I would change the language into an IETF language tag or similar instead. The important part is that it separates language variants. For example, US English and British (or international) English have differences, Brazilian Portuguese and Portugal Portuguese have differences, Mexican Spanish and Spain Spanish have differences, etc.

Using an ID instead of the text content itself as part of the PK should be a no-brainer. Languages evolve over time, and translations change. PKs should not. Your choice of PK = (TextContentId, Language) is the most reasonable to me, though I still think that translations should live as assets to your application instead to better integrate with existing localization tools.

One last thing: people tend to believe that translating is enough to localize. It is not. For example, RTL languages often swap the entire UI direction to RTL, not just the text direction. Also, different cultures sometimes use different colors and icons than each other.

it is the same code as you produce manually.

LLMs do not create the same code that I would, nor do they produce code at the same level that I would. Additionally, LLMs are not deterministic (normally - there are ways to manually seed some but it’s rare). Determinism has a very specific meaning. Compilers supporting reproducible builds are deterministic. LLMs producing a different output each time are not.

it is a task of a programmer to review it before publishing it.

Tell that to my coworkers. It’s honestly insulting the code I have to review and contribute to. Having used these tools myself, I’m better off writing the code myself.

Currently everything on the Internet is assumed to be free.

This isn’t true at all. Content on websites is protected by copyright laws as well.

It’s not open source? The repository doesn’t seem to include the Rust source code.

Being closed source, I have no reason to believe it isn’t malicious. Open source means auditable. Closed source means “trust me bro”.

Edit: nevermind, I think I found the right repo. The package links to another one. Might want to fix that. Also, your profile on GH says it’s still closed source.

Mentioned this to the other commenter, but this doesn’t use the type system to enforce the mutual exclusivity constraint. In Rust, the main way to do that via the type system is through enums.

This doesn’t represent the mutual exclusivity through the type system (which is what the article is all about).

I love clap and I use it a lot, but the only way to represent the exclusivity through the type system in Rust is through an enum.

I like the concept, and it’s great in TS. Unfortunately, not as doable in other languages.

I’m a bit curious if it’s possible to extend clap to do this in Rust though (specifically mutually-exclusive arg groups).

Next.js is a highly opinionated framework. “Our way or the highway” is what should be expected going in. Good luck if your requirements change later on, and I hope your code is transferrable to a new framework if needed.

Unfortunately, I have never need to follow “our way” because my projects are more complex than whatever basic blog setup they document. I always end up just building my own stack around Vite. I’m also not much of a fan of fighting against my tools when what I need isn’t something the tool devs already thought of.

This. It’s just like “this dude is cool” and some fun Q&A and circlejerking, which is fine, but he probably should not be used as a credible source for understanding younger stuff.

Nah I ignored that because responding with just a number is boring and leads to no real discussion. A poll would have been better if that’s what was needed.

For programming languages? I don’t need many features as long as what exists is enough to do everything I need. In fact, the less, the better (or you end up with C++'s regex/Python’s urllibN/etc).

I guess that means that I’d end up more on the documentation side, though my reason isn’t because I want the most documented language of all time, but because I want the fewest built-in features.

This is why I mostly write Rust when given the option. I write a lot of Python, but I hate the standard library so much. There’s the urllib stuff, plus there’s a bunch of deprecated stuff in the base64 module, plus I can’t stand Python’s implementation of async (coroutines are cool but asyncio is miserable to use imo).

Edit: Oh, and nobody’s giving integers only when nuanced answers are more interesting to discuss.

conda isn’t much of an alternative to pip. It’s more of an alternative to venv. Unless you’re referring to conda’s dependency management, which I’ve admittedly never used.

And until pip uninstall foo uninstalls unused transitive dependencies too, you’ll have to drag me back.

uv is love. uv is life.

I’m still trying to get people at work to use it. It’s one of the few tools out there that takes Python from intolerable spaghetti to readable and maintainable.

It would be convenient to be able to clone the task management repository alongside the code repository, too.

FYI it’s entirely possible to track multiple branches with unrelated histories in git. Both the task management and code can live in the same repository.

You could theoretically even give each task an ID, then tag commits in the code that complete those tasks with those task IDs.

This gives me some ideas for how it could be done that might be fun to explore. It comes with the benefit of not being platform-specific (GitHub/GitLab/etc). Merge conflicts might be annoying, but maybe there’s a way to take advantage of Git’s tree to represent relationships between tasks, and have one “HEAD” commit (or branch or other ref) per task? Not sure how this will work honestly.

Having worked with a no-code product for a family member who ran for a local position, you can get pretty far with them. The issues are usually when you want to go outside their happy path and do your own thing, and unfortunately a large part of campaigning is branding. The tool we used let us write our own HTML though, so that’s where I came in to bring some custom CSS so that the website could look a bit more unique.

In general, for a small campaign, I agree with the author’s decision to go no-code. Writing a site from scratch is doable and maybe not that hard, but hooking up stuff for campaign donations, emails, etc was way too much for me to try to do on my own in my free time. Better funded campaigns can probably go further, though not sure if it’s even common there to go custom or just use one of these tools.

They probably just need to renew it. I’d raise it with the devs if it’s not resolved sometime in the next day.

Though in some contexts, I might prefer a name like employeeToRole for a Map<Employee, Role> over the article’s employeeRoles.

Following the article, the former describes the type (a map from employees to roles) while the latter describes the relationship (these are the employees’ roles).

At the same time, I’m not pedantic enough to care in practice. Both are fine, and I’ll get the point when I read either of those.

I agree with the author here that names don’t need to be so verbose, but I also think there needs to be a balance. out or req or res are clear with context, but output, request, and response are always clear and not bad to write. http_response adds extra unnecessary info (unless there’s another response variable in scope).

It also helps when languages support local variable shadowing. For example:

let response = foo();
let response = validate_response(response);

Both of these are responses, and fundamentally the same thing being passed around while being mutated. The types are (potentially) different. You won’t use the first variable ever again (and in Rust, likely can’t). Just reuse the name.

A pretty good way to get a code review is to post the code on GitHub and make a post advertising it as a tool everyone needs. People will be quick to review it.

As far as LLMs go, they tend to be too quick to please you. It might be better to ask it to generate code that does something similar to what you’re doing, then compare the two to see if you learn anything from it or if it does something in a better way than how your code does it.