JSConf 2014

Crea tus propios DSL (Domain Specific Languages) con JavaScript

Neil Green  · 




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

all right I'd like to say that kudos to the Microsoft guys because if I was at a Jay s comp I would never want to open with where the guys who made a E but the I'm sure the latest ID is awesome though how many people here ever develop for ie6 ends

up I wasn't those guys all right so I worked for ice we end up I'm a technical lead there I end up working on a lot of very complex business problems and at work I wrote a couple of dsls part of my job is to coach other engineers on how to do their

job and one of the things that I've wanted to speak on but I just hadn't had the time to pull the talk together I was writing custom dsls so when there was a call for speakers of jazz calm face admitted it got accepted and somehow it got to be the

first for this track thank you very much Jay Escom for accepting me and I'm honored to be to kick off this conference all right so we're gonna break up the talked into four sections the evolutionary history of dsls to give us all some context to how

we got there what a do cell is defining your DSL is grammar and implementing your DSL all right evolutionary history of DSL so for the history of programming we've always been trying to create a machine language that reads like a human language when we

first started out we said let's use punch cards fun fact turns out punch cards have been used since the 17th century for programming moons I didn't know that and they were used all the way up until the 80s until they invented monitors and keyboards

low level languages like assembly that basically read like gibble D Guk higher level languages where we started to see human words like if and else and end and do then we got even higher level languages that allowed you to express things that were again more

human and more natural and that led us up to object-oriented languages now object-oriented languages or the purpose of them is that you can use them to represent you know real world stuff but encode by creating computer models and domain modeling is the you

know the the methodology if you will of taking something that you see in the real world and making a computer model of it now the fact is that doesn't happen well my opinion nearly often enough but generally speaking we tend to just use you know models

when it comes to models we think of them as just data transfer objects if you look at just about any framework out there they're all saying you know here's how you use our models and this is our models and models and models and all there most times

all they're really saying is this is how you trance data back back and forth but when you actually do a domain model when you actually model your domain you end up with something that is much you know conceptually bigger and more important and the persistence

layer the database the presentation layer the user interface tend to be much simpler in comparison if you think of something like Bank of America and you you know or sorry any that's my bank if you look at any banking interface you know the the stuff you

see on the screen and the stuff that's going Oracle or whatnot pales in comparison to all of the business logic that's responsible for transfers and international monies and all the rest of that the clearing goes with it when we talk about the MVC

pattern the M in MVC is you know they use the word model for a reason they sort of want your m2 be your domain model so that it you know you that is where all of your business logic lives and then you've got these other ancillary things to make a domain

model and by the way that's that's one of the many things like cochon is just how to get an engineer to start thinking about how to make your own domain model I think it's relatively straightforward and simple but it's it's something that

requires a lot of practice until it becomes second nature understand your domain model your domain implement your domain understanding your domain is this process it starts off with speaking with your customer and developing a mutual language that is crazy

important and will be a theme for the rest of this talk the model begins with this idea of what is your domain so that I can understand it so that I can build it good model your domain in UML just need a UML sketch you don't need anything very complicated

when you come to implementing your domain you got a series of choices and I'm going to take you through one is you can sort of listen remember what you say go back to your desk and just start typing and hope to god that you remembered everything properly

a better way to do it is to write your test first then write your code to pass your test but when you do that when you invert the order with which you you code meaning testing testing first you've got two choices that you can make there for I just got

freaked out because there's a little green bar in my screen and then there's a little counter thing and they don't line up and I want them to so I'm gonna hold on all right I'm gonna keep going there we go so you have a choice of writing

tests by yourself or you have a choice of writing tests with the customer when you write your tests by yourself it's called test-driven development when you write them with the customer it's called behavior driven development there's an example

[ ... ]

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