Aplicando la arquitectura hexagonal de Cockburn a una aplicación Symfony2

Extracto de la transcripción automática del vídeo realizada por YouTube.

so i'm marcelo i work for a company called and vika sweet on my shirt this is a group that includes essential apps UK and sent a succession digital any Vika itself and i'm konstantine mostly known as ever sets on twitter and github and i am also proud

part of in weaker company ah and we're working with this crazy guy doing crazy things together yeah I get to walk in and see people like that every day so this talk is going to be about we have structured in and in three ways you're going to talk about

convenience it's an aspect of framework that's maybe how frameworks are sold in first place has a lot of convenience features i'm going to talk about that and contrast with other things i'm going to talk about choices yeah and there is there

is thing that people are getting into lately about the choices and design and how you how you make those choices in your project and we kind of get get busted without even thinking about it we're kind of starting to think about good and bad instead of

thinking about what matters and this part of talk will be the most important part of chocolate will kind of try to cover it yeah when told ever said that I want to talk about this and say yeah I want to talk about that too so what did she talk about that together

and then I'm gonna start hurt hearing his ideas is like five years ahead of me and said Wow okay so you do that you write that code for that limo thing and he did and that's the last bit of the visitation diffusion some ideas that he had that he's

gonna put in to be hot as well too I just do to try and keep up with our ideas make the tools help us with what I was trying to do so let's stop with the convenience the the carrot at the end of the stick right so you should use a framework because you

get this feature you get that feature get that feature and we fall into that promise we like it very much by the way let's just do here a disclaimer we love symphony it's not about removing symphony from your cause it's about leveraging it in the

best possible way and using it as best as possible it goes the wrong way yep and if you go what is same thing if you go to the documentation try to find out what it seems and you find that this coat is their framework is just one of the tools to help you develop

better and it's actually developed faster it is actually the quote from the commendation and I find it really fascinated because it once it's just just and there is also it's one of the tools so there is a lot of sketches there and in the official

documentation about the tool it already kind of puts you into the mindset where you don't need to think about this is the only thing in your project it's just one of those things just one of them it's really cool and if you have to develop out

what you want to do what what is important for you what kind of it's important what do you expect from a framework but you what kind of code you wrote you want to write I want a ride clink old man i want to write stuff that is really really cool I know

that this comes second w/e what about you know running code you know fast efficiently for your customer and writing code that you know we using framework that keeps your cold cleaner by the way its structure so this is a very nice way of putting focus on the

right thing right so when you look at the mentality of people when it said a writing code fast it's like even and some project manager think this is switch that it can turn down okay we have to deliver that on day 20 and how do you do that I don't

know why you do stop doing testers stop all the quality thing and then we can go faster this imaginary switch that it can turn down quality and by some magic reason you're going to go faster estimate elicit balls also known as Hacker News switch the hacking

usage so yeah so if you try that that that theory you find that it may find that doesn't work that there's something wrong with it it transistor their Uncle Bob boots is really well and say it's the only way to really go fast is to go well like

the code Rick if you really want to go fast it the right way from the beginning uncle bob's talks about this a lot but he uses this particular way of delivering message which most people don't get so we're trying to we will try to clarify this

a bit today so yeah so that it seems to be and two ways to look at frame works at tools and and what what is the components of these tools that make the code more a convenient or maintainable like two forces there and and if you look at that you know this

is all over the web relative cost of repair as you grow in your project will end I think it was a codes to these on yeah coops if you were upstairs he says as as you go further down on on your project it gets harder and harder to evolve your code the code

the complexity just grows and to fix anything to change anything becomes just more expensive all the time and and then he says that's not necessarily true because you can fall into a sustainable pace if you keep the inequality of the code right that is

it interesting so there's some qualities of the coated some colors that we can put around the way you write your you use a framework they can kind of reduce the explanation ality of this core make it easy for you to a vogel your cold later on so so that

there's a battle between convenient and maintainable so let's just have a look at that the battle yeah so there is another name for convenience nowadays and it's like we hear this a lot especially I had this a lot when we switch from Symphony 12

Symphony to another name for convenience is conventions and there is like there is this bottle where people believe that putting a lot more on conventions will give them ability to drive code faster and there is another comp of people that believe if they

do not follow conventions we'll put a lot more into architecture and design they will go slower but then they will get a benefit and there is this trade-off between those two that you need to make on every project and this trade-off is not necessarily

about being small or being big or changing project it is about how big you want to get rather than how big you are right now it is about do you want to evolve your project into something else later on the road or do you want it to be that small and if there

is always a trade-off and this trade-off could change every day on the project and this is kind of this thing that we're missing constantly so the magic is to get something that is convenient that can be converted into maintainable so if you can get something

like that it's convenient for you and then it can convert that into maintaining what is that how can you do that so that's bother us I've we want we wrote to the help people write tests and we like we want people to write tests and it go out we

can't why because the framework doesn't like me it's all too convenient and now because it's so convenient we can't write s it's quite opposite because like I wrote a tool that helps you to write us no matter how bad your name is yeah

and then when we switch to the inside layer and it actually cares about the quality and for Marcel is quite opposite because his tools I kya exposes the problems of the inner quality so we but it doesn't says that be God doesn't care about the quality

it does both of those they combine the quality of the product as jakub said during his talk so that's the fascinating thing so if you look at a convenient for the conferring work that is convenient or a framework is convenient when it makes choices for

[ ... ]

Nota: se han omitido las otras 3.850 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.