Comments

You must log in or register to comment.

Eluvatar_the_second t1_ir40zyh wrote

Not sure what's so interactive about this, maybe it's because I'm on mobile but couldn't this have just been done with pictures?

169

itjy t1_ir4el2h wrote

You can click a link, very interactive!

161

DamagedFreight t1_ir42fiq wrote

I thought the same thing too. I think it’s purposely a tiny bit more difficult to glance at so you feel like you have to read it before going back to see the next one.

I think it does work but meh.

24

trekhleb OP t1_ir4ve77 wrote

Yes, that's true that going back and forth not always convenient. I was trying to find this balance between "Staying focused on one principle at a time" and "Having all info be easily accessible at glance". Probably I didn't find the perfect balance yet :D

But, there is also the extensibility aspect. With the current approach, I may add more details to each letter in the future while keeping the entry page still readable. Technically it is possible to even add more nested sub-sketches to each letter if needed

13

i_got_skrimps t1_ir5axyw wrote

I like it. I think people are getting hung up on interpretation and semantics here. It's a great site.

6

29979245T t1_ir4f3y2 wrote

It might be referring to the fact that the pictures are made in some kind of cute drawing engine that records every shape and penstrokes and allows them to be manipulated in a pretty intuitive way. So you could easily redraw part of one if you thought it was a bad explanation, for example...except they're locked in readonly mode and I don't even see a way to make a copy to play with.

8

trekhleb OP t1_ir4vocd wrote

Thanks for the feedback. Yes, currently the okso.app Showcase examples are served in a read-only mode. But this is a good idea to have the possibility to clone the current showcase and play with it locally in the browser. I've added it to the roadmap https://feedback.okso.app/

3

trekhleb OP t1_ir4uskq wrote

Yeah, the interactivity is pretty minimal, but it is still there in form of "Click to go deeper to the nested image with further details".

You're also right that all illustrations could be put on one page. But with the current approach, there is a possibility to add more details to the nested pages (to each S O L I D letter separately) without making the entry page bulky.

−4

jobe_br t1_ir3gb60 wrote

Cool, but they got SRP wrong (as many do) -

> The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.

See https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html for more.

Edited: removed “you” - not sure if this is OP’s site.

69

Beretta_errata t1_ir3nrbq wrote

Posted in 25 subreddits, probably his/her site.

52

trekhleb OP t1_ir4w3jq wrote

Yes, you got me :D

−10

Beretta_errata t1_ir4xba6 wrote

I am surprised this account is not a bot.

7

trekhleb OP t1_ir4xj7s wrote

Nah, this is just my, probably perverted, way of sharing the info

8

Beretta_errata t1_ir50ifk wrote

Busy, busy, busy, is what we Bokononists whisper whenever we think of how complicated and unpredictable the machinery of life really is.

14

RockstarArtisan t1_ir3wddm wrote

It does speak volumes about the quality of Martin's advice if many people get it wrong, don't you think?

20

Ok-Farmer-2695 t1_ir482m8 wrote

… no?

4

RockstarArtisan t1_ir52lwr wrote

This is not a programming subreddit, but I assume you're familiar with the subject.

The job of a book author and advice merchant is to convey their advice in a manner that people can follow. People who are bad at this shouldn't be selling the advice. In this case, the problem isn't the writing style, it's just that there's nothing behind it.

Have you seen how "principled" this principle is? The author struggles to come up with the description himself. In his videos he says stuff like "Single responsibility principle is actually not about single responsibility, it's about a single reason for change" (I guess he did change his blog to say it's both now). This is the vaguest shit possible. Basically, Martin is a boomer consultant, who makes up acronyms to sell his shit. He needed some rules to make a nice acronym, so he picked 5 things arbitrarily, one of these happened to be "make stuff simple, not complicated". This is clearly meaningless padding, so he needed to convert this rule to be something that people will think is insightful - he came up with "single responsibility" which is the same non-advice, just with more plausible deniability.

I'm tired of having to write the same shit over and over again whenever another person get's caught up in this and posts on the programming subreddits about it so here's my latest brief description: https://old.reddit.com/r/programming/comments/xvu3gc/solid_principles_sketches/ir3uhyx/

7

Cogadh t1_ir4663c wrote

You're not wrong to ask it, but how many people are just as guilty of "skimming"? None of us ever have enough time, but patience to read thoroughly directly impacts comprehension

0

RockstarArtisan t1_ir53gm6 wrote

No, there's just no insight in the principle whatshowever (see my other comment in this thread). This is engineering, not bible studies, if you need to repeat the wording exactly for it to sound convincing, there's probably an issue with the advice.

7

TheGerk t1_ir5sa78 wrote

Yeah. Maybe I just have a bone to pick, but I've always thought solid was pretty awful programming. There's some good ideas in there, but largely I've seen this make code bases worse.

3

daedalus91 t1_ir4ij0a wrote

I've read the article. Can you elaborate on why is OP's example wrong?

So according to the article, it's all about the people requesting the changes. Spoon users try to use that spoork, and they realize it's not deep enough to spoon a soup. The developer redesigns it, makes the spoork deeper to enable it to spoon a larger amount of soup. Then the fork people try to stick their vegetables onto their spoork, but now due to the increased curvature of the spoork, it isn't straight enough, and the vegetables will fall apart and won't stick onto the spoork.

If you create a separate spoon and a fork, each user has their perfect tool.

9

jobe_br t1_ir5rts1 wrote

The analogy is gonna be strained, but the real problem is the way SRP is stated as “only one potential change in the software’s specification” - this is not person centric. The way OP started this is more the way SRP was initially misinterpreted as a module should do one thing and only one thing. That’s actually more the Unix cli philosophy of “do one thing and one thing well” — but it’s not SRP.

Internally, we don’t try to pre-determine if a module follows SRP, we use actual changes being made to the system to identify modules that are changing as a result of different actors/people. We then refactor a module to split it so that it once again is aligned to one axis of change.

2

Cogadh t1_ir45y9u wrote

This was a great read, thank you! Separation of concerns, or rather lack thereof, has been the downfall of way too many orgs. Hurts thinking about all the times I've seen "unintended consequences"

5

P12oooF t1_ir4qlou wrote

Great chapter in half life... which got me into computers in the 90s. Now I program.... MeTa!

1

TheBeardofGilgamesh t1_ir5bvia wrote

Ah yes uncle Bob a guy who has not done any software development in decades is the perfect person to listen to.

5

jobe_br t1_ir5ssti wrote

I’m not gonna defend Uncle Bob, but I’d advise against attacking his technical mettle, personally.

−1

TheBeardofGilgamesh t1_ir7227x wrote

It’s less his technical ability that I question, it’s his advice for designing maintainable code bases. How can someone who has not worked on large code bases or large teams have the experience of trail and error know how well his methods work in practice. It’s like if a person wrote a book on commanding an aircraft carrier yet has no experience in the navy.

3

jobe_br t1_ir7jihx wrote

Tell me you don’t know his work history without telling me you don’t …

Once you’ve written as much code as he has, check back.

2

trekhleb OP t1_ir4w2ls wrote

I guess the illustration with the "Spoon" + "Fork" instead of the "Spoork" still works, doesn't it? I mean if you want to change the "Spoon" functionality you just change the "Spoon" but not touching the "Fork", whereas the "Spoork" is going to be changed for two different reasons: when we want to change either the "Spoon" functionality or the "Fork" one.

3

jobe_br t1_ir5slha wrote

You’re going to have a strained analogy either way, but you might be able to come up with something that is more person centric. Your analogy focuses on the functionality of the spoon, fork, and spork, not the person’s needs - I could argue that a single person’s concerns are encapsulated by the spork, and as such it doesn’t need to be split up. Realistically, the existence of the spork gives credence to this - it wouldn’t exist if a separate spoon and fork were superior for all user needs.

Definitely change the text, though, either way.

1

klesus t1_ir5kc37 wrote

So if there's more than one reason to change a module then you shouldn't change it?

2

jobe_br t1_ir5t5df wrote

You’ll want to read the article I linked in full.

−3

polarphantom t1_ir4bvdm wrote

Shame that mobile responsiveness wasn't a principle for this site

35

trekhleb OP t1_ir4wr7e wrote

If you mean the "Fit to screen" zooming feature it is there (bottom right corner).

But if you're talking not only about scaling but also about re-arranging the sketch elements based on the screen size (in a classing web-app manner), then yes, it doesn't work.

This is a bit challenging to do for the free-hand drawing of absolutely-positioned and scaled elements since the app might not have enough context of how to re-arrange. I.e. there is a free-form arrow that goes from the exact word of the sentence to the exact Attachment of the Mixer (it is not clear how to redraw it from horizontal to vertical form-factor).

−3

Rwagstaff84 t1_ir4th5x wrote

Long time software developer and I get all these solid concepts but …. it doesn’t really change how I write code. I just write what I think is best based on experience. I never stop and think “does this meet the liskov substitution principle” or any of the other SOLID principles. Why is this brought up as the gold standard so much? Just seems like a way to claim you are a good coder because you “understand” solid. Is that just me? coding is so much more than just 5 generic concepts that you probably do almost always by default by following good patterns.

24

Lampshader t1_ir4x3tr wrote

> 5 generic concepts that you probably do almost always by default

You probably do. I assure you that not everyone does, and giving these concepts names and descriptions is a good way to teach those who don't just intuitively "get it"

12

ghostryder333 t1_ir6d7b7 wrote

I don't want to come off as offensive, but I believe if you don't just "get it" intuitively when writing code you're not gonna be able to work in the industry.

After all you still want to be able to read your code as it grows. You codebase will become more complex with each passing day, and if you don't actually get an intuitive grasp on how to structure things you'll become unable to maintain your code pretty soon.

−3

Lampshader t1_ir7dvlc wrote

It's definitely possible to learn and internalize new things.

2

TheBeardofGilgamesh t1_ir5c9yr wrote

Worst code based I have ever encountered where people with a Clean Code book on their desks. Uncle Bob has no real experience in software development he just does the conference circuit and gives lectures.

9

mouse_8b t1_ir6q00h wrote

If it's your only book, yeah it's lacking. It doesn't teach how to be a good developer. But as a self-taught coder, having a reference like that was useful to increase my code quality and readability.

1

TuringC0mplete t1_ir752yi wrote

I preach SOLID pretty hard, but I think after a certain point it just becomes second nature and a "Yeah, that's just how you do it" kind of mindset. Not all of these principles are applicable to every scenario, but for the most part they're a good guide to writing clean code. Some languages don't even have interfaces to do a lot of SOLID things with (looking at you, python -.-)

But I agree that just because you understand the concepts doesn't mean you know how to affectively apply them. Hell, even for preaching them so much, the architect on my team explained to me a few months ago how I was using LSP completely wrong.

Ultimately to me, it's a great teaching tool; but you definitely need to know when to apply it.

1

ghostella t1_ir4zcxk wrote

Weird that it appears that you can click on the various images but then it just displays an attached "open" button that you then have to click on again. Seems like it's made for the person designing vs the consumer.

20

trekhleb OP t1_ir50p7e wrote

Yes, that “double-click” not user-friendly. I need to change that 👌🏻

4

IsntDoingScience t1_ir3wjjq wrote

As someone still in my first year of being a professional computer hammer, this is helpful to look at.

8

MikeCampo t1_ir4x1vj wrote

SOLID is a bunch of bs.

4

Ok-Butterscotch-6829 t1_ir572rd wrote

How so? Seems like it makes sense to me.

1

RockstarArtisan t1_ir57u2i wrote

There're reasons why this got upvoted in a nonprogramming subreddit and downvoted in r/programming :P

11

Ok-Butterscotch-6829 t1_ir5c4cc wrote

Why was it downvoted there? I thought SOLID was accepted as good practice in OOP?

0

RockstarArtisan t1_ir5q7om wrote

Well, it is widely known and established, but many people disagree about being good. Some of the advice is applicable in the context of a framework, but the author insists it should be used everywhere which results in bloated designs that people hate. The popularity of this in the Java community is mostly what's responsible for all the hate Java gets online - bloat, overabstraction, complicated designs exemplified by the most SOLID frameworks of them all - Spring - with it's AbstractSingletonProxyFactoryBean https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

7

billwoo t1_ir6e306 wrote

Well we can ignore what the author insists on, and just use them as handy short hands for describing architecture decisions. All the principles are sound architectural advice without further context, but software design is mostly striking a balance between pragmatism and "perfect" architecture (extensibility, generality, low coupling etc.). That some Java libraries get that wrong isn't really evidence that "SOLID is a bunch of bs".

Only things that nobody uses don't get complained about.

1

ImTheTechn0mancer t1_ir7nrku wrote

>good practice in OOP

A vacuous statement because OOP is not a good practice.

3

Ok-Butterscotch-6829 t1_ir9wbvh wrote

Well, I kept seeing SOLID come up for interviews and what not but it sounds like many programmers dislike it.

1

ImTheTechn0mancer t1_ir9xyp1 wrote

Of course! Companies love acronyms and buzzwords. SOLID! CRUD! Synergy! Bobody!

They make the business-oriented folks feel like they know what they're talking about with the senior devs.

2

Adverpol t1_ir7d6pw wrote

The thing is that if you focus on solid it's easy to forget that often you shouldn't have had inheritance in the first place, that's my problem with it anyway. OOP is a tool that should be used when appropriate, which for me means when you actually need polymorphism e.g. store a list of different types of entities in a list.

2

PoorlyAttired t1_ir4d44q wrote

That's useful, though the example for interface segregation could be tweaked because I appreciate that both my laptop and phone are charged by USB-C.

3

NerdFoundryGaming t1_ir7dsj8 wrote

I found this UI to be very difficult to navigate.

It'd be better off as a proper slideshow. Literally no reason to have a weird breadcrumb navigation with movable entities on screen that serves no purpose other than to confuse the user as to what is even going on. Also, really hated the font used.

But the content was simple and decent.

2

Ok-Butterscotch-6829 t1_ir56t5n wrote

This is actually really helpful. I’m starting to interview again and want to be able to intelligently answer using SOLID principles.

1

billwoo t1_ir6d8tw wrote

Don't overdo it. I guess it depends what sort of company you are applying to, but describing every answer in terms of SOLID will make it sound like you just discovered SOLID and think its the answer to everything.

3

Ok-Butterscotch-6829 t1_ir6ds9t wrote

There’s so much conflicting advice in programming I don’t know who and what to believe anymore. 🤷‍♂️ It seems to me that much of the time it’s just programmer’s own opinions. 🤷‍♂️

1

billwoo t1_ir6expy wrote

Experience is the only thing that will really make you a good programmer. Until you get it, don't over commit to principles. There IS no golden bullet, or perfect paradigm.

3

mouse_8b t1_ir6qkll wrote

You figured it out. There are so many aspects of software to balance, that it depends on what you are focused on as to what the best way forward is. And in many cases it's not the best, just good enough.

1

feinerSenf t1_ir789ad wrote

Hi what library are you using for the free drawing implementation?

1

trekhleb OP t1_ir78nkf wrote

It is here https://github.com/steveruizok/perfect-freehand

2

feinerSenf t1_ir91koi wrote

Nice i was trying to get this to work a while back but I did not manage to finalize. Did you create an react app in the end?

1

caeptn2te t1_ir49t8i wrote

I find the idea of presentation is great! It helps organizing the stuff in my brain.

0