unculture (u/unculture)

unculture commented on Architecture Patterns with Python cosmicpython.com/book/pre... · Posted by u/asicsp

pbronez · 5 months ago

Based on that, do you find SQLModel[0] to be an elegant integration of these ideas, or a horrid ball of spaghetti?

unculture · 5 months ago

SQLModel is supposed to be the best of both Pydantic and SQLAlchemy, but by design an SQLModel entity backed by a database table doesn't validate its fields on creation, which is the point of Pydantic.

https://github.com/fastapi/sqlmodel/issues/52#issuecomment-1...

unculture commented on Architecture Patterns with Python cosmicpython.com/book/pre... · Posted by u/asicsp

kelafoja · 5 months ago

Could you explain how repository pattern is a "huge overkill that adds complexity with very little benefit"? I find it a very light-weight pattern and would recommend to always use it when database access is needed, to clearly separate concerns.

In the end, it's just making sure that all database access for a specific entity all goes through one point (the repository for that entity). Inside the repository, you can do whatever you want (run queries yourself, use ORM, etc).

A lot of the stuff written in the article under the section Repository pattern has very little to do with the pattern, and much more to do with all sorts of Python, Django, and SQLAlchemy details.

unculture · 5 months ago

Repository pattern is useful if you really feel like you're going to need to switch out your database layer for something else at some point in the future, but I've literally never seen this happen in my career ever. Otherwise, it's just duplicate code you have to write.

unculture commented on Paris cycling numbers double in one year thanks to investment momentummag.com/paris-cyc... · Posted by u/Timothee

ryandrake · a year ago

I don’t get how you can make bicycling your only form of transportation, even if the bike travel infrastructure and parking is adequate. When I bicycle, even for a short amount of time like 15 minutes, I sweat, and end up a stinky wet mess at my destination. Especially in the summer. My shoes and pants get dirty from the road and my hair gets wet and messed up especially if it’s raining. So if I’m going anywhere with even a moderate expectation of personal hygiene, I need to 1. Make sure there is a shower at my destination, 2. Haul a change of clothes with me (necessitating a backpack or bag), 3. Hang on to my dirty sweaty clothes in that bag the whole time. Fine if I’m commuting to work where they have a shower and storage. What about going to a restaurant or business meeting or a museum or an appointment with a professional? I honestly don’t know but there are so many cities where people bike everywhere so there must be a solution.

EDIT: ok, ok, I guess e-bikes it is. Still there are cities like Copenhagen and Amsterdam where everyone bikes everywhere and they don’t all have e-bikes. Do they just bring multiple changes of clothes everywhere?

unculture · a year ago

It's quite cold a lot of the time in Northern Europe, and people who are cycling to commute there often really aren't going very fast so won't sweat much.

You can also get "moisture wicking" clothes, that might help with a certain amount of sweat.

There is quite a lot of e-bike use in Amsterdam and Copenhagen. Google "bakfiets" - it's a whole "suburban parents with a family size e-bike" cliche (but a good one!).

unculture commented on Apple Orders 'Neuromancer' Series variety.com/2024/tv/news/... · Posted by u/ortusdux

vidarh · 2 years ago

The Peripheral is already on Prime.

unculture · 2 years ago

It’s been cancelled, sadly.

unculture commented on Tailwind CSS marketing and misinformation engine nuejs.org/blog/tailwind-m... · Posted by u/todsacerdoti

JLehtinen · 2 years ago

I’ve worked on some large projects including refactors with Tailwind and my view is opposite. I can see how Tailwind would work on small projects, or ones where the designer never touches the styling inside the code. But on the other hand, avoiding naming because it’s hard isn’t how I approach organising design, and it doesn’t sound like a good approach to coding either. But I can see how there may be a need to bypass it in projects where there is no designer, or a design system.

unculture · 2 years ago

You don't avoid naming - you name the components and the styles live in the components. The key is to avoid the false separation of concerns of style and structure.

unculture commented on Tailwind CSS marketing and misinformation engine nuejs.org/blog/tailwind-m... · Posted by u/todsacerdoti

JLehtinen · 2 years ago

They are (encapsulated in reusable components). But when the project grows big, Tailwind's shortcomings become apparent, the biggest ones being the loss of context (cascading) – and of course the lack of separation of concerns, when the concerned parties are also separate (developers and designers).

When building a design system, there are a bunch of default styles, and then there are variations based on context. To put it in a real world example, imagine a newspaper heading style that varies depending on where the heading appears. Front page headings are bigger, sports pages might use a different style, and so on. Same with buttons, cards, tabs, what have you.

This isn't impossible to build with Tailwind by adding, say, react logic, but it becomes a mess quickly. If you have a well-built design system, class naming shouldn't be that hard to figure out and communicate to developers. But deciding on a coding logic to account for these context changes and sticking to it seems not as easy, especially when developers come and go.

unculture · 2 years ago

If you're making a wholesale design change, you should expect a wholesale code change. If you're making a small change to a component that's the same every everywhere you should ideally expect to make that change in a single place. If you don't have that, that's a problem, but it's not Tailwind's fault.

Global defaults are a separate matter. As are prose styles / styles for UGC text because you don't know the HTML structure ahead of time - by all means use the cascade here, but for almost but for everything else you have two maintainable options:

1) Some CSS naming system or scoping system, e.g. BEM where you enforce proper naming and selector complexity limits (except in rare circumstances). This is extremely hard to do in the long term on a big project.

2) Leverage the component system / template system of whatever system you're using to make reusable components and use utility styles.

Using the cascade extensively on a long running project is a recipe for maintainability disaster - you will face a wild goose chase for the file you want every time you want to make a change, and then another wild goose chase for unexpected changes because your selectors weren't specific enough.

I'm also pretty strongly of the opinion nowadays that separation of concerns of CSS and HTML is a false separation - the single concern is how a thing looks on the page.

unculture commented on Tailwind CSS marketing and misinformation engine nuejs.org/blog/tailwind-m... · Posted by u/todsacerdoti

tipiirai · 2 years ago

I can also see how Tailwind can help teams that just want to move forward by copy/pasting ready-made components without ever looking "under the hood".

However, I wrote this article for the love of CSS, web standards, and the web in general. I think Tailwind's dishonest marketing tactics aren't doing good for the development community. Especially for young developers who are suddenly told that things like separation of concerns and good naming practises are a bad thing.

unculture · 2 years ago

You really need to cut out these accusations of dishonesty - it’s a bad look.

He’s not saying “separation of concerns and good naming practices” are bad things, he’s saying that separation of concerns between HTML and CSS is mostly a false separation (it’s the same concern - making the UI look right) and that good naming practices are hard - best just do that in one place, the component that address the concern with both style and structure.

unculture commented on Tailwind CSS marketing and misinformation engine nuejs.org/blog/tailwind-m... · Posted by u/todsacerdoti

orangepanda · 2 years ago

Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation.

This works great for marketing or landing pages, or other use cases where it’s not you who maintains it after deployment; the next sucker will want to rewrite it all anyway.

unculture · 2 years ago

This is just demonstrably not true.

unculture commented on Tailwind CSS marketing and misinformation engine nuejs.org/blog/tailwind-m... · Posted by u/todsacerdoti

tipiirai · 2 years ago

And you still need 60+ lines to create a button like that?

unculture · 2 years ago

Come on - your turn. Come back with your version of that Catalyst button that does everything that’s being done by those Tailwind styles.

unculture commented on Tailwind CSS marketing and misinformation engine nuejs.org/blog/tailwind-m... · Posted by u/todsacerdoti

unculture · 2 years ago

Option 1: Find a visual error, open devtools, find the nearest most descriptive class or id (.primary? Oh no…), open IDE, global search in styles folder structure (most likely but not the only place to find CSS) for “.primary”. 40 files returned. After 15 minutes find a file that looks like it might be the right one. 10 minutes to understand the CSS (lots of advanced CSS in here…). Find the cause of the visual error, make the 1 line change. 30 minutes - job done.

Option 2: Find a visual error, open e.g. React Devtools, find the component name, open the IDE, find the component source file, find the HTML, change the utility style class, job done - 5 minutes.

These are not contrived examples. I had a one liner take 40 minutes to find in a codebase a couple of weeks ago. Not an exaggeration.

I really used to believe in separation of concerns but I don’t any more, because of all the time I’ve had to spend fighting with “option 1” codebases over the years. Pretty much any big codebase with normal CSS is going to be an “option 1” eventually unless it’s the work of a single good CSS developer (rare skill), or a team where someone who’s a good leader also cares about CSS enough to enforce a convention like BEM in perpetuity (even rarer skill).

Anyone building anything complex these days is using some component abstraction - whether it’s client side or not - to manage complexity. May as well make use of it for styles if it’s already there.

The reason that there’s a backlash against separation of concerns, the cascade, and (low) specificity is that each of these things is a complete disaster for maintainability in the long run.

One note in making an example of that Catalyst button. If you wrote out all the styles required to do the amount of work that button is doing it would also be extremely difficult to understand, and what’s more, it’d be in a completely different file to the single thing that gives it any meaning - the HTML.