Live data from Hacker News

Inkscape Cloud Architect

github.com

51–60 of 80 posts

Re: Inkscape Cloud Architect

#51
post #39

Earlier quoted context omitted.

I read this article and I'm left with the feeling that my entire application has no layer 3 i.e. the component layer. No single (useful) part of the application can be said to have a well defined interface or to be self contained. The strange thing is that I'm not actually that unhappy about that. I'm now sitting here thinking whether I should be more worried.

It kinda depends on the scale I guess? At some point in the growth of on application, pulling out the Big Tools can be helpful to get your application out of a local maximum. Not everything needs that level of design though. Just because architects do detailed FEM analyses for skyscraper design doesn't mean your garden shed needs the same level of attention.

This. So much this. I call it the-don't-put-a-golden-handle-on-an-outhouse-door principle.

Re: Inkscape Cloud Architect

#52

Earlier quoted context omitted.

From my experience what you are experiencing is a case of "the current architectural best practices disagree with what we are doing successfully" which many organizations and Senior Engineers interpret as reason enough to introduce change. You will probably receive comments along those lines, be in arguments around this. You could also actively ignore this for half a decade and see if the tides are changing again. I…

Just need a new name for monolith. “Partition Tolerant System Design” perhaps.

I assume the PTSD acronym was intentional?

Either way, it’s a genius name.

Re: Inkscape Cloud Architect

#53

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/

I read this article and I'm left with the feeling that my entire application has no layer 3 i.e. the component layer. No single (useful) part of the application can be said to have a well defined interface or to be self contained. The strange thing is that I'm not actually that unhappy about that. I'm now sitting here thinking whether I should be more worried.

Depends on your application - A game engine won't break down into this 4 layer model, but lots of enterprise applications (or ecosystems) will.

If an application continues to grow, and the team building it grows, it will eventually need to be broken apart into smaller independent blocks to make it practical for a large team to work on it and maintain it. In a smaller codebase with fewer engineers, you can make different choices.

Re: Inkscape Cloud Architect

#54
post #43

I use draw.io for these kind of diagrams. It has symbols for most of the cloud services built in. It also maintains the arrow connections when we move around the elements. Very handy!

The way most people use draw.io is using cloud storage integration like Google drive, hence versioning is not possible. So far I never seen people put the draw.io produced file to Git. I'm using PlantUML in some of my projects, it solved the versioning issue. However it's lacking of lots of draw.io or even inkscape editor capability.

I do. What I like the most is the ability to include the diagram source into PNG metadata. The viewers don't need any renderer, yet it can be readily edited.

Re: Inkscape Cloud Architect

#55
post #12

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/

What a useless crap. It’s an over engineered documentation framework focusing on all the wrong things so some agile consultant can sell more cool aid. I don’t trust anything that is designed someone who last did real projects in the 2000’s OOP Java enterprise craze.

It's 4 diagrams. You can't get much less engineered than that.

Whats your background that you have simpler alternatives?

Re: Inkscape Cloud Architect

#56

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/

I can't say using vendor specific icons is wrong, clearly a lot of people need just that, but I always miss more generic architectural components in these diagramming tools.

That's the problem I have with the `diagrams` Python package (https://pypi.org/project/diagrams/), I find it extremely useful, but the "Generic" section doesn't even include a "Queue" component, and the "OnPrem" section only includes specific queue products.

That Python package is exactly how I like to create diagrams, so I keep using it, but I always have to add my own badly-designed custom icons to it, which look so bad that I wouldn't dare send a PR to add them upstream.

Re: Inkscape Cloud Architect

#57

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/

I read this article and I'm left with the feeling that my entire application has no layer 3 i.e. the component layer. No single (useful) part of the application can be said to have a well defined interface or to be self contained. The strange thing is that I'm not actually that unhappy about that. I'm now sitting here thinking whether I should be more worried.

Honestly, this may be because you write procedural/functional code, aka simple code, and not enterprise (tm) (R) OOP "I've memorized all 150 design patterns" code.

A lot of these components are strongly linked, and will hold mutable references to each other, which is often pretty terrible.

In procedural code world, everything is connected to each other, but not strongly, and there are very few mutable references.

You may just have a solid codebase.

Re: Inkscape Cloud Architect

#58
post #12

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/

What a useless crap. It’s an over engineered documentation framework focusing on all the wrong things so some agile consultant can sell more cool aid. I don’t trust anything that is designed someone who last did real projects in the 2000’s OOP Java enterprise craze.

So so much agree with this. People who think in terms of OOP and design patterns (i.e. bandaids) will think "how else are you supposed to model solutions"?

But yes, this is fundamentally an OOP thing, and especially the component layer is very much just fantasy. In no real OOP software do these meat reusable components not have super strong binding to each other. Yeah you may have the SignIn controller and the ResetPassword controller both talking to the SecurityComponent, but in the end that's guaranteed to be implemented in such a way that you cant use any of them without all the others connected, and its likely that testing this means writing a mock for each of them that is so complex it may as well have its own tests.

They are thinking of their problem, and building their solution entirely out of blocks made from the words that make up the problem. "We need users to be able to sign in and reset their password" becomes SignIn component and ResetPassword component, when really this is just a matter of changing a hash and possibly some encryption keys, and could just be a handful of validate(), reset() et al functions on the security module.

Re: Inkscape Cloud Architect

#59

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/

I can't say using vendor specific icons is wrong, clearly a lot of people need just that, but I always miss more generic architectural components in these diagramming tools. That's the problem I have with the `diagrams` Python package ( https://pypi.org/project/diagrams/ ), I find it extremely useful, but the "Generic" section doesn't even include a "Queue" component, and the "OnPrem" section only includes specific q…

That Python library looks great! Thanks for sharing it.

Re: Inkscape Cloud Architect

#60
post #43

I use draw.io for these kind of diagrams. It has symbols for most of the cloud services built in. It also maintains the arrow connections when we move around the elements. Very handy!

The way most people use draw.io is using cloud storage integration like Google drive, hence versioning is not possible. So far I never seen people put the draw.io produced file to Git. I'm using PlantUML in some of my projects, it solved the versioning issue. However it's lacking of lots of draw.io or even inkscape editor capability.

There's a plugin for VSCode that brings draw.io editor for local .drawio files. IMO it's the best of both worlds: nice editor and git version control.

Also this plugin works fine in github.dev so it's like a better version of draw.io official site.

Post reply on HN