Sandi is a wonderful speaker. SOLID is a collection of really good ideas hidden in language so opaque that it's almost impossible to decipher. And yet Sandi not only manages to decipher them, she re-presents them in a way "we mere mortals" can understand!
Stable design principle, summarized in the likehood of change, is something that usually is not in the spotilight. Thanks for this awesome lesson, Sandi, you are an endless source of knowlodge.
This Is all the opposite of what Alan Kay was referring to and everything that a procedural C programmer would get confused by the bad C++ ideas And we all suffer
I don’t believe she’s right about interfaces. The question he asked was about doing dependency injection sanely . I have to say interfaced make a huge difference for this , as you’re defining what you expect . This is why strongly typed languages are better imo
You can define what you expect through other means, too, though (annotations, DSL). For example, you can use libraries which allow you to define types of parameters passed to the instantiation of an object (`active_interaction` is great for this). Still, I agree, strongly typed languages are better for this kind of thing, especially when combined with static type checking at compile time. In fact, I see that as an essential level of explicitness and cannot understand why you would guess types and expectations by name instead.
I think it was as much to show that following these principles can lead you to find that what seemed like a lot of very specific behaviour is actually only a little bit of very specific behaviour hiding in more generic behaviour, which makes it easier to extend your code. Like she said early on, feel free to walk away from any given implementation if the trade-off in refactoring isn't there.
The code smell is unencrypted passwords in your [likely versioned] source code! :D Little dated (hash opts in method arg instead of new named args), but still fantastic! Seen it a good few times.
As an unskilled Ruby developer I could easily maintain the original version, not so much the final result. I would've loved Sandi to prove her points with less esoteric and over-engineered code. Great talk in any case.
Francesc Rosas in the same boat, I see the value of abstraction, but if the whole codebase gets abstracted so strongly it becomes hard to read, and I am valueing readability highly
Shit code indeed. It's not your experience, your gut is right. I don't know any world class programmers who follow this OO cult cargo crap blindly. They think they are solving some deep singular problem with their overengineered overgeneralized code and next thing you know the machine is 20x slower and doesnt solve the problem at hand efficiently. This is why our processors are orders of magnitude faster and the enterprise software still sucks. These programmers don't understand their machines and treat code as some general prose. Garbage.
Maybe Twitter "Over time, we had also accrued significant technical debt in our Ruby code base, making it hard to add features and improve the reliability of our search engine." blog.twitter.com/2011/twitter-search-is-now-3x-faster Although I'm not sure "refactor" is the right word here.
Talk about over complicate things! Can you imagine someone with this way of thinking working on some of the early 8-bit hardware. Wouldn't stand a chance. Development and design does NOT need to be soooooo overdone! Waffle overload.
agreed. I can't believe the comments on this video. This is on par with some of the worst programming I seen. This wouldn't stand a chance in any serious programming. Cult cargo OO programmers overcomplicating things, slowing down our machines thinking they are solving the singularity with their overgeneralized solutions. Please, solve the goddamn problem at hand. I advise watching Unity's principal programmer Mike Acton talks or reading Ulrich paper on what programmers should know about memory.
Sandi is a wonderful speaker. SOLID is a collection of really good ideas hidden in language so opaque that it's almost impossible to decipher. And yet Sandi not only manages to decipher them, she re-presents them in a way "we mere mortals" can understand!
Very nice presentation. Sandi is highly skilled and very articulate. She's a real credit to our profession.
Stable design principle, summarized in the likehood of change, is something that usually is not in the spotilight.
Thanks for this awesome lesson, Sandi, you are an endless source of knowlodge.
Sandi has done Smalltalk for 10 years... no wonder her OOP is good
This is not oop
This principle leads you from an easy to understand specific app to a difficult to understand generic one
This Is all the opposite of what Alan Kay was referring to and everything that a procedural C programmer would get confused by the bad C++ ideas
And we all suffer
The slides are @ skmetz.home.mindspring.com/img28.html
I don’t believe she’s right about interfaces. The question he asked was about doing dependency injection sanely . I have to say interfaced make a huge difference for this , as you’re defining what you expect . This is why strongly typed languages are better imo
You can define what you expect through other means, too, though (annotations, DSL). For example, you can use libraries which allow you to define types of parameters passed to the instantiation of an object (`active_interaction` is great for this). Still, I agree, strongly typed languages are better for this kind of thing, especially when combined with static type checking at compile time. In fact, I see that as an essential level of explicitness and cannot understand why you would guess types and expectations by name instead.
Damien R yeah, upon reflection , I agree
Nice talk. One rub is that the Config class is too general. Its implementation might as well be a hash.
Definitely. Meta programming of config management meta configured in same file? Over engineering.
I think it was as much to show that following these principles can lead you to find that what seemed like a lot of very specific behaviour is actually only a little bit of very specific behaviour hiding in more generic behaviour, which makes it easier to extend your code. Like she said early on, feel free to walk away from any given implementation if the trade-off in refactoring isn't there.
Wow it's give me clear understanding about SOLID. Thx Sandi Metz!
This is all a confused mess
The code smell is unencrypted passwords in your [likely versioned] source code! :D Little dated (hash opts in method arg instead of new named args), but still fantastic! Seen it a good few times.
Who's the "well known website which had to refactor all the Ruby code" at 44:46 which Sandi mentions? :)
twitter, they moved out of ruby blaming ruby is slow.
Recompiling isn’t a problem tho lol 12:04
Does it Yahuda with was in camera?
10:58 the final goal is having maintainable code
The final goal is ease if change
Maintenance is due to design flaws not allowing ease of change
And this stuff just moves away from that goal
As an unskilled Ruby developer I could easily maintain the original version, not so much the final result. I would've loved Sandi to prove her points with less esoteric and over-engineered code. Great talk in any case.
Francesc Rosas in the same boat, I see the value of abstraction, but if the whole codebase gets abstracted so strongly it becomes hard to read, and I am valueing readability highly
Shit code indeed. It's not your experience, your gut is right. I don't know any world class programmers who follow this OO cult cargo crap blindly. They think they are solving some deep singular problem with their overengineered overgeneralized code and next thing you know the machine is 20x slower and doesnt solve the problem at hand efficiently. This is why our processors are orders of magnitude faster and the enterprise software still sucks. These programmers don't understand their machines and treat code as some general prose. Garbage.
What’s great about it
This all just confused things more
26:44 ugh totally procedural code here
No Alan Kay ideas anywhere
This is just C++ in Ruby, and confusing
Does anyone have a link to the code she references? The mindspring link doesn't seem to work for me.
She shows it in the slides. She talks about the shared link because some people in the room couldn´t see the slides.
17:29 it would be way easier to write this procedurally
Bad example
Amazing talk!
Why
Does anyone know which company Sandi is talking about at: ua-cam.com/video/v-2yFMzxqwU/v-deo.html
Maybe Twitter "Over time, we had also accrued significant technical debt in our Ruby code base, making it hard to add features and improve the reliability of our search engine." blog.twitter.com/2011/twitter-search-is-now-3x-faster
Although I'm not sure "refactor" is the right word here.
Hah right, more lile "replace"?
anyone has the source code of this talk? thanks
All these years I thought Sandy was a guy. I read her books in a male voice.
Talk about over complicate things! Can you imagine someone with this way of thinking working on some of the early 8-bit hardware. Wouldn't stand a chance. Development and design does NOT need to be soooooo overdone! Waffle overload.
agreed. I can't believe the comments on this video. This is on par with some of the worst programming I seen. This wouldn't stand a chance in any serious programming. Cult cargo OO programmers overcomplicating things, slowing down our machines thinking they are solving the singularity with their overgeneralized solutions. Please, solve the goddamn problem at hand. I advise watching Unity's principal programmer Mike Acton talks or reading Ulrich paper on what programmers should know about memory.
@@ThePandaGuitar - well said. It's about time more people spoke up about this stuff 👍.
“get off my lawn!"
what is the connection between solid design and 8 bit hardware?
@@alisunjaya main point is this is not solid design at all
Lol you can tell this woman is into some weird stuff in the bedroom
What, like refactoring?
@@jonathan4835lol
Confusing things to the point of irrelevance