Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
okay hey it's really great to be here so I'm Piazza Utah my name is so rude because I come from clock off it's a beautiful city in Poland if you've never been to Poland it's real beautiful so I invite you to come we have some rubik conferences
as well with also beautiful mountains so it's a really nice country so really quickly about me on a ruby developer you can find some of my open source projects on github and follow me on Twitter I'm so linked everywhere so if you wanted to say you
had one job I actually don't I have three so I'm a part of a company called powwow at a Polish Norwegian consultancy I'm also working for victorious which is a good hosting platform that you can host yourself and by the way we were moving to docker
it's like eighty percent done I'm also working for a norwegian company called evo which is a chain of fitness clubs with a huge infrastructure built in rails so like before i start i wanted to talk a little bit about like my experience this ruby developer
so that you can know where I'm coming from with all this stuff so I started working as a ruby developer seven years ago and in 2007 we were mostly working on startups right so every project was greenfield everything was really great right we were using
rails we were writing a lot of Ruby code and everything was smooth and just beautiful right but at some point some of those startups actually succeeded right so suddenly we started working on huge a couple of years old Reyes apps and at some point it became
a problem right it started to be really difficult to maintain those projects and I started to think why is it so hard to maintain a big rails application right what's the cause of this problem and initially I thought that yeah maybe we could use different
patterns maybe we could just use different libraries but really what we've been doing for the last couple of years seems to me like not solving the problem but working around the problems that we have and what I realized is that the cause of this problem
is just complexity that we have and all the tools that we are using are extremely convenient so that we can move really fast but we don't think about the complexity that we pull in when we start depending on external product of the gems so when we create
a new race project even if you don't include any additional gems it's already a lot of complexity that we have without even writing any code so then we start to actually write some code so we build even more complexity on top of already existing complexity
right so it's something we don't think about on a daily basis so today I want to talk about convenience versus simplicity and even though the title of this talk may seem to be a little bit abstract I actually try to make it more concrete however I'm
going to start by some by explaining some of those abstract terms so convenience when you look at the definition in dictionary it says that convenience is the state of being able to proceed with something without difficulty right and when you think about it
it's exactly what happens when we use our convenient tools like rails and true to remember this one this is from screencast we're dhh showed how to build a block application in your rails in 15 minutes it's pretty famous you probably sell it so
this is this is it this is the convenience all the things that we're not doing all the things we're not thinking we're just preceding really quickly with our tasks we're accomplishing our goals really quickly without thinking much about the
problems that they're that we're actually dealing with because a lot of those problems are solved by the libraries and frameworks that we are using so on the other hand we have simplicity and again when you look at the definition it says simplicity
is the quality or condition of being easy to understand or do and it's a little bit tricky because we often say that something is convenient and like immediately connected with something that's simple and it might be a little bit confusing because
you see something that is simple your think okay that's convenient it's simple i can simply just use it and it works but you don't really think about what's inside right so what usually happens is that a lot of libraries and frameworks that
are super convenient and really simple to use come with a lot of internal complexity something that we just don't think about because we don't see it so it's not our problem right so when it comes to complexity and ways of dealing with the problem
of complexity what program is usually do is to focus on separation of concerns if we have a huge problem which is real difficult to solve we try to like split it into smaller pieces into smaller problems and solve them individually and what I've noticed
in the Ruby ecosystem that is probably inspired by by rails we often focus on convenience first we often focus on all the fancy dsl's and the convenience that that should come right from the start so when you look at for example active record right it's
a great example of a convenient library a library library that solves a lot of different problems the problems that are really hard to solve by the way so when you look at a basic model the basic active record model it's just an empty class right and you
might think that it's super simple right because it's just a class and you don't even have to write anything except defining the class to get a lot of functionality for free if you want to create something and persist it in the database it's
also very simple just one method called passing programs and you're done even wanna even if you want to do something more fancy like find something fetch something from the database loaded into memory and then do something with it and save it back to the
database it's still super simple you just call like three methods here right so you might think it's all so simple I don't need to learn a lot I'm I'm just reading API documentation for like three minutes and I know what to do so you think
yeah that's simple and really I don't think it's simple and the reason why it's not simple is that there are a lot of things going on under the hood and even though I don't see them they do exist and that's why I prefer to use the word
convenient because it is all very convenient but it is not simple there is no simplicity here there's a lot of internal complexity it's just we don't see it when it comes to separation of concerns if we look at this create method and think about
what's actually going on we will realize that we are dealing with things like data coercion which is a huge problem to solve by the way there are a lot of really nasty things that you need to deal with when you want to have coercion setting default values
this is also something that happens under the hood you might not think about it but it exists we do things like validation and validation is also a really big problem to solve and eventually we we do interact with the database and interacting with the data
is also a huge problem to solve right and this is like the basic stuff that that happens under the hood and if you're less lucky you could have things like business logic hidden in life cycle hooks all the before say before validate all this stuff this
is super complicated and we do that we also do things like handling nested data structures using except nested attributes for which is also super complicated thing to deal with we also do things like data normalization to custom attribute writers and plenty
of other stuff so this is a lot of complexity and we tend to hide it in one place but it's just not a good thing to do so when if we want to talk about separation of concerns in this context we might look at it in a way where we can use separate objects
[ ... ]
Nota: se han omitido las otras 3.968 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.