 talk suggests this is kind of a weird it's kind of an amalgamation of several different things that I've been thinking about or working on for a while. I mean I spent some time talking about naked objects ever since Dave's keynote on the first morning I've kind of had to scale back some of my graphics in this section of the talk. And I'm going to talk about naked objects because I think it's an important idea that you know it kind of had some a moment of popularity for a couple of years and recently we've stopped hearing about it so much and I think it's worth revisiting. I'm going to talk about what I did for Why Day and my Why Day project was to start building a naked objects framework in Ruby that I called Pursuit and I'm going to talk a little bit about Rails. You're allowed to talk about Rails at RubyConf. You're just not allowed to pretend that it's the same thing as Ruby so I'm going to talk about Rails and especially active record and active model which I think fit very nicely into the naked objects idea and make it easy for someone who's interested in that. And I'm going to talk about the relational model and some things we can learn from that and maybe apply to the way we do domain modeling in Ruby. Some of you may at RailsConf or at some other regional conferences this year have seen me give this talk Real Software Engineering. Just as a word of warning if you're expecting something like that, don't. That talk is the product of about ten years of thinking and I think pretty well organized and coherent and tells a story that all fits together. This talk is kind of the opposite of that talk. This talk is a talk full of half-baked ideas that I've been thinking about for ten weeks and I don't think it all fits together nicely yet but that's not so bad because if you've read this wonderful book by Steven Johnson where good ideas come from. Good ideas come from half-baked ideas and different things colliding with each other in interesting milieus and ideas being taken out of one venue and used in another and hoping that this talk which I think is aptly described by this picture is the start of some good ideas. And in fact David his keynote on the first morning of RubyConf played kind of nicely into my hands because my goal for this talk was to do exactly the things that he challenged us to do. I want to inspire, I want to diversify and bring in some ideas from parts of our industry that might be a little bit unfamiliar and I'm definitely something new worse than has been done before. So let's talk about naked objects. I'll get into the history of it a little bit and the history is important and interesting but just first an overview of what it is. Naked objects is a model of building applications that provides a user interface that essentially allows the user to directly manipulate domain objects and directly manipulate the relationships between those objects. So here is an example of a naked objects interface. You can see that in one part of the screen there is a list of primary domain entities, expense claims and employees in this case and using those entity placeholders you can issue queries of various kinds and see groups of individual domain objects that match that query against a particular entity type and then from there you can get a hold of one or more entity objects and edit them directly and build relationships between them. We have an employee object there and you can edit fields of that object and a claim object which has multiple sub objects of expense items and those things. You can do a host of sort of universal actions on objects, create a new one, edit an existing one, duplicate an existing expense item and each kind of object has its own custom actions that it declares that you can directly act on the object and tell it to do things in essence call methods on it straight from this interface. This particular interface is a Windows graphical desktop user interface but the idea of naked objects is that programmers focus on building the domain modeling. You define your business objects, the relationships between them, what constitutes valid or invalid business rules, build the logic in there about how business objects act on each other and relate to each other and the user interface is generated for you. This user interface is a part of the .NET naked objects framework and the programmers who built this particular application didn't code on the user interface at all. That was generated for you as a wrapper around these objects. Hence the name naked objects. The framework gives you direct access to edit and manipulate and see business objects in the domain and nothing restricts you from having just a sort of desktop drag and drop user interface. The .NET naked objects framework also supplies a web-based user interface that runs in a web browser and the mechanisms and user interface style is a bit different but all the same pieces are there. You can see the list of entities, you can issue queries and get collections of a particular kind of entity, you can edit those entities directly, execute sort of universal actions on domain objects and execute custom actions that are particular to that kind of domain. Naked objects appeared in our field about the same time as Ruby's introduction in the West. The pickaxe book, the first edition of the pickaxe book, was introduced, was released 10 years ago last month at the UPSLA conference in Minneapolis in 2000, in the year 2000 and at that same conference was the first time that Richard Pauson, who invented this idea although building on a lot of other good ideas from the past, spoke about the naked objects idea and started trying to promote it and it actually goes back to a lot of earlier ideas. The small talk, the original small talk group at Xerox the park, one of the things they were trying to do with small talk for the purpose of building end user applications was to introduce direct manipulation. When we hear direct manipulation today, we tend to think of dragging and dropping things on a screen and that's one of the things they meant by that, but what they really meant was that the application should provide you with direct access to the objects in the domain that you were using and they may be in a drawing application, things like circles and squares and text blocks and things like that or in a business application something like this and that team at Xerox Park had t-shirts made that said don't mode me in. They wanted to get rid of modes and programmed workflows in computer applications and instead let them choose their own workflow based on direct access to the objects in the business domain. That idea has persisted in some ways and Paulson started trying to resurrect it in a very explicit way by introducing the idea of naked objects building a framework for that. So it's been around for about 10 years, the same time as most of us in this country have been aware of Ruby and there have been some other implementations of it. My friend Etan Suez did an alternative Java based naked objects framework called Jmatter. I'm not going to walk you through all the pieces of this interface but it has all the same ideas and it has the ability to provide alternative views of objects with particular kinds of characteristics and all these frameworks haven't come in the idea that you focus on building the domain objects and you may need to annotate those objects either internally or externally in some other ways to make the user interface be exactly what you want but the user interface is built for you. This idea should be kind of familiar to those of us in the Rails world because Rails has a couple of things that really borrow from this idea a lot. For example, smart scaffolding systems like ActiveScaffold can be viewed as a simple naked objects framework for Rails and ActiveRecord. The focus of ActiveScaffold is really more for a data administrator being able to look at the data and edit it and correct it and enter data easily not for somebody actually performing business tasks but nevertheless the idea is pretty much the same. Another ActiveScaffold screened editing an individual entity. In the original Java based naked objects framework they had a drag and drop swing based user interface which was pretty ugly and they talked about having pluggable different interfaces and a web based interface but they hadn't quite figured out what that should look like yet so as a proof of concept they developed a textual console based user interface wrapped around naked objects and as near as I can tell I haven't been able to find that recently and downloaded and run it but I don't have to to show you an example of what a textual naked objects framework, naked objects interface looks like because every Rails application has one. It's called the Rails console. You can see in this example I have a little application and you have to run the console in production mode for all these things to work so that it will preload all the classes but by asking ActiveRecord base for some classes I can find the list of domain objects in this domain and so there's room, session, speaker and talk. This is loosely based on the example that Atom uses in his Jmatter documentation and if I ask speaker to tell me about itself it tells me the various attributes that a speaker has and talk is the same way, a little more involved. There are some things in those lists that are more sort of ActiveRecord infrastructure attributes like ID and speaker ID but you can also ask an ActiveRecord object for its content columns and it will give you a list of columns and fields in that object that filters out the administrative stuff. And if you've never done this in a few but most of us who have worked in Rails have used the console and played around with objects and effectively you're using a textual interface to an object system. In this example a little farther that's the classes idea but you can also create new objects so there's me and there's Patrick Ewing speaking next door, create new objects, persist those in the database, interact with them directly and you can also create objects in established relationships. So here's my talk associated with me as a speaker and there's Patrick's talk associated with him as a speaker and we add the title to it, directly manipulate that, save it and then we can do queries and ask the set of related objects things about themselves and this is where I highlight the wonderful scheduling that Chad did. I love the fact that these two particular titles are running next to each other. So about half the room which is about what I expected. In 2003-2004 I started getting some little bit of popularity and then kind of faded and it's interesting to look at why that is. You might think well it faded from view because it's just a bad idea but the history of our field is full of great ideas that failed for the time because not that they were bad ideas but because it the time just wasn't right or things were were changing that made it not the best time or not the best fit or sometimes just because people didn't understand it. I think they can objects failed for a couple of reasons. One being that the initial frameworks weren't very good and the people who wrote them will cheerfully acknowledge that those frameworks weren't very good weren't very good. Another reason is the goal of Naked Objects. The goal of Naked Objects is to provide an interface for domain experts within their domain. A Naked Objects system would be an inappropriate interface to put in front of a novice user that did not understand the domain. The idea is that a novice user needs a little more guidance an understanding of what to do next and what's required and what's optional whereas a domain expert will know these things and can choose their own workflow through the system and the kind of workflow style or wizard style task-oriented interface that are so good for novice users are actually really frustrating for domain experts because sometimes you want to enter information or take actions in the order that the information becomes available to you and not in the order that's prescribed by the interface of the application but at about the same time that Naked Objects was first becoming popular we were starting to figure out how to really build interfaces on the web that would allow novice users to do things for themselves real effective self-serve shopping browsing search airline reservation booking systems and so the emphasis shifted from building interfaces for domain experts working say in an airline reservation center call center to building an interface that was more appropriate for novice users people going to American Airlines comm and booking their own reservations and things like that but again I don't think it's a bad idea I think it's a wonderful idea and for my quiet a project I started working on a Naked Objects framework in Ruby that I called pursuit and it's a funny name and it's a why-ish name and that's kind of why I chose it but it also reflects some of my opinions about Naked Objects and what's going on and this is the embarrassing part of the talk because I had hoped to well it's embarrassing for one reason because I just realized I never plugged my laptop in it's also embarrassing because I don't have really working code for her suit to show you yeah thank you dick so but the reason for that is partly because as usually happens you know things got busy and I didn't have the time I thought I'd have but it's also partly because my first attempt taught me a lot about Naked Objects and about active record and active model and the strengths and weaknesses of those tools for data modeling that caused me to kind of throw away my first attempt and start over and it's really those lessons that I wanted to talk to you about her suit is a Naked Objects framework and it's built on active record and active model and as I've shown you those tools already have much of what you need to be able to do a Naked Objects system and that's obvious because you can do it right from the rails console and effectively that is a text-based Naked Objects system based on active record and active model but I mentioned that while the focus of Naked Objects is to allow you to focus on the domain model and building your business logic and all that stuff that we do in the models directory and rails applications sometimes programmers do have to give hints to the Naked Objects user interface to get it to build an interface that really works right and nobody who's interested in Naked Objects is really happy with that idea and as I began building her suit I started thinking about the things that were missing from active record and active model and I initially started sort of building those in as annotations of the user interface layer but the more I thought about it and this was the lesson that caused me to throw that away and start over more I thought about it almost everything I realized I needed to do to give hints to the user interface were actually things that would be helpful as a part of the data model itself and this really isn't surprising because we take something like active record and active model and try to take it out of its context within rails certainly a lot of people have built custom applications that don't use rails and just use active record and active model if you take it out of there and try to build a new type of framework on top of it for other kinds of applications you learn things and the deficiencies of that initial tool active record and active model become more apparent in the new context and one of the things I learned was that a naked object isn't really naked it needs a different kind of clothing it needs adornment in particular it needs to be highly reflective and give information not about itself necessarily that's the naked one but also about its kind and constraints that it has and its behavior and so the original name that Richard Pauson used before he changed to naked objects because he thought it sounded snappier I suppose the original name he was using was expressive objects I think perhaps that's a better name in some ways and it gives us more insight into what's really going on an expressive object isn't truly naked it needs to have something wrapped around it that shows you how to interface with it and shows the interface what to do to build the right window on the front and the right interface and active record has some of those things but it doesn't have all of those things and so the third part of the talk is what it really means for an object to become naked what it really means for an object to reveal itself to a framework so that the framework can present it to a user in the appropriate way it's not really about becoming naked it's about having a different suit made for you for every application and the tailor needs to know the right information to make that suit and as I began trying to do that in active model I noticed some holes in the facilities that active record and active model give you for that purpose so let's talk about this Richard Pauson said in a note to me he noticed that I was giving this talk and contacted me and we had a little back and forth about it and he said time and time again we have found that the constraints imposed by naked objects user interface very often force you to do a much better job of the main model and I've seen that myself and furthermore so he started doing the work on the dot net naked object system fairly early in the life of C sharp as a programming language and had to build in a lot of custom declarations and things that you needed to add so that the UI could do the right thing but later some of that stuff was subsumed by that net itself so it's very rare indeed that the constraints of a naked objects UI force you to do something less than optimal in the main model and then the custom declarations that he built our annotations serve purposes much wider than the naked objects and other annotations have appeared from other quarters of the dot net community that turn out to serve our needs perfectly well and they've been able to deprecate most of the custom stuff that they originally built into the framework for annotating and describing your data model and are now using things that are standard part of the dot net persistence frame and those map very nicely to the declarations and annotations that we have in active record and active model objects so let's look at what classes give us in active record and I'm talking about active record and active model because there are things that a naked objects framework needs from both and I'm trying as much as I can as I build this to depend only on active model but nevertheless for persistence and some of the other things I need to deal with active record facilities as well so henceforth I'll just call it active model but you'll know that I'm talking about the blend of the two the classes can tell us about their attributes and that's really important for us to provide an interface to editing an object for domain expert and they can tell us about their associations and that's useful as well because we need to be able to provide an interface for a user to build associations between objects and the right kind of objects and things like that and or be able to query from an object to find its associated objects an object can tell us about its validations and that's useful because we might want to provide a different interface for different kinds of constraints on a variable and we do this by hand all the time in Rails applications think about the different interfaces you provide sometimes for phone numbers as opposed to just comment strings or something like that and that's based on although we don't do it automatically it's based on the validations and just before Rails 3 shipped the team finally made validations nicely reflectable associations have always been had a very good reflection support in Rails and now in Rails 3 validations have good reflection support so you can query an object about its validations and learn about those so that opens the door to being able to do some of those things automatically which is nice but I have an asterisk there and we'll talk about that a little bit later as validations occur in another place what active record objects don't tell us is very much about their actions the things you can do to them yes you can use Ruby to find out about the methods but for her suit I've needed to build a facility to declare in much the same way that we declare in Rails controllers which of these methods are kind of meant for public consumption and not just the kind of public protected private style thing that is consumption by other programmers but the things that end users are allowed to do additionally we need to for those actions provide information about the types of arguments and the types of things that you're likely to get back from those so that's something I'll be improving the prototype of that working not quite happy with it associations provide us the type of the object on the other side and they tell us whether there are one there's one object there or many objects there what would really be useful that they don't provide is some notion of the expected cardinality of that association if it's a one to many association or do we expect to have a few objects in that association tens hundreds thousands you can imagine that that information is necessary for choosing the right interface to let somebody for objects that are associated or browse them or add new ones whether you would have just a simple drop-down list or some kind of a fancy autocomplete search field or something like that this is obviously be useful for user interface can you think of places where it would be useful to actually have it represented in the data model I think it would be very handy to have objects know it might be useful for heuristics about how to prefetch associations if you were asked to do that whether to do it via join or by a separate query and this might not be a pure constraint that would be enforced but it would be a hint of we expect to have just a few of these things or maybe 20 or 30 something like the way we specified color depth on computer displays these days hundreds thousands or millions not attributes active model tells us about the type of attributes which is very useful for building the interface that we already have things in rails including scaffolding and facilities like formtastic that exploit that type to automatically provide the right kind of interface constraints which it gets from the database whether it's nullable or not for example and validations again the reason I have the asterisk around validations is that validations are now introspective and you can reflect on those and learn about the validations but they're not generative without building special code you can't learn what a validation means in terms of how to provide the right user interface for it or things like that it's merely okay you provide a value and I'll tell you whether it's good or not so it'd be nice if they had more descriptive or generative capability as well and I don't quite know how to achieve that but finally there's one more thing that I think active record and active model would benefit from that we need for naked objects and to build a good naked objects framework but I think would also benefit us in an ordinary rails application and the key to this I'll introduce by giving you a quote from a friend of mine Scott Davis and Scott is familiar with Ruby and rails and he's chosen to go another way he's a grails developer evangelist and one of the things he really doesn't like about rails is the leakiness of the active record abstraction and the way SQL leaks through and I'm not here to argue about that I'm actually kind of a fan of it but recently Scott said this anytime you require a developer to specify SQL before source code you're putting the car before the horse and I don't actually agree with that necessarily but while I think he's wrong he's not all that far wrong and the way I would describe how the leakiness of the active record abstraction really hurts us as developers using it whether in rails or not is this the domain model should not be unnecessarily constrained by the limitations of the database and in active record and active model today if what you have to represent is it maps nicely to one of the built-in database column types you're in a shape if it's not well if it works out nicely as an association you can define a separate table for that thing and a separate model class for it and you're in good shape there as well but if what you really want is a field in your in your record in your model object with a custom data type you're not out of luck but active record doesn't make it easy for you and there's this notion from the original original relational model of domains this was a part of the original proposal of the relational database model a domain was a custom data type for a column it would be formed from a base data type plus constraints on that and the idea of the domain when it was that it would exhaustively list or describe all of the valid values for that call in the database and in the original proposal there wasn't really any notion of composite data types that were formed for different based from different base data types some databases added that support later and the idea was that you would really never declare a column that was just an end or just a strength create a domain for what that meant in your database model and then create your column that way and that idea was never widely used because it was never really well supported by database implementations and because it was kind of heavyweight and I think because in the database schema is not really the right place for that but maybe the domain model is the right place for this kind of thing and so what do we do do we want to provide support for a field in active record or rather better support because this field that the support does exist better support in active record to be an instance of some custom Ruby class there are a couple of ways to do this in active record now either of them are widely used for good reasons they're kind of clumsy overkill just as a double check people are filing in am I over time or did another talk just let out okay I'm not over time so do we use classes to represent the idea of domains and have fields in our active record model objects that are instances of a custom Ruby class and put the the stuff we need there that might seem too heavy it also if the domain is a tight plus constraints then we really want the domain to be able to carry its own validations with it and that kind of seems like a clumsy idea having to define a class that is not necessarily an active record instance but has validations with it one of the facilities for doing this in active record today is aggregations and again it's not widely used it's kind of clumsy you can say that the slot attribute is composed of two other underlying attributes in your table in this case starts at and ends at and you can say represent that composite that aggregation as an instance of the class time interval how many of you have used this in active record work and that's about what I expected to probably about 10 percent it's not widely used and again validations are kind of clumsy in that case because the validations are on the the larger scale active record object and not on that individual class so places where you you use this you have to duplicate those validations there are several reasons why this doesn't work very well but yes question should use the now now rails three like validations are separate include and do just a rookie class and then include them in the rookie class yeah you can mix in mix in the validations yeah there there are ways you can do this they're a lot easier in rails three and that's kind of what I'm moving towards is a refinement of that idea so but you can see that there is a need for a better facility like this and as evidence of that I want to show you two widely used plugins that work in a similar way and may actually use this under the covers but have had to do a lot of extra stuff to do what they really want to accomplish and the first of those is money you declare a money price attribute using the money gem in your active record object and that assumes that there is a column in the database called price in cents and it wraps that in an implementation of the money class and or an instance of the money class and does nice things for you and you can override that default mapping and also define a second field that represents the particular currency that that money value is represented in and so this is sort of like a smarter composite the and again I don't know it might use composite or might use the composed of under the covers but it has to do a lot of other stuff to really make this work the other example that would benefit from a smarter sort of domain support in active record as a part of our modeling is paper collision so you say has attached file and you can you can override all this but essentially this expects you to have in your migrations these columns avatar file name content type file size updated at and paper clip sort of subsumes all four of those columns for you into one instance of whatever the class is that paper clap wraps those so that you can manipulate those four fields as a single entity and this is a great example of kind of rich domain support that I think we need and the right right implementation of domains in active record and active model would make much easier than the current implementation of money in paper clip so as I said I'm a little embarrassed not to have to be giving a talk that's half-baked ideas without working code but on the other hand that's kind of fitting for a project that began on white a so what I have been playing with and thrown out and not really been happy with yet is ideas like that so in an active record class you could describe a domain attribute that is slot this is very similar to the composed of example we saw earlier but instead of specifying a class you specify a domain this attribute is slot is of the domain time interval that time interval domain has been defined elsewhere and you can override the default mappings if you want to just like with composed of but I toyed with the idea of defining the domain as a class that's a subclass of a domain based class the default mapping is that it uses fields start and end that's what would be overridden by the the usage declaration of above it includes its own validations validates that the start and end attributes are present and it validates that end comes after start using a method that does that work and I tried this and wasn't exactly happy with it and the the latest implementation I have uses more of a declaration like this where you declare the domain time interval and then within a block there we describe the class name that implements this and and validates presence of validations and other things and I'm playing with where this should go and if it's appropriate and appropriate if there is an appropriate place for these domain declarations to go in the context of an application and if I don't find a place that feels right I may end up going back to the the class option but this is all ideas that are coming to me as I try to build a completely different kind of application framework around the base of active model and active record and that really doesn't surprise me at all when you take something out of its context and then try to generalize it in a different context the deficiencies become really stark things you might never notice before things we're happy to do manually in rails applications we need to do automatically in a naked objects framework and then the test is are these things that we need to add useful again back to the context of pure data modeling in in a rails application I don't know the answer to that yet I think though that I will end up writing gems or plugins that add this straight to active record or active model if that's the appropriate place for some of them and we can experiment with doing better data modeling and more thorough modeling of our data in rails applications and perhaps that will have the additional follow-on effect of allowing us to simplify controllers and views and do more automatically that we're now having to do manually and a quick conclusion when you take something you're familiar with and try to use it in a different setting deficiencies that you've never noticed before will become obvious so it's always a useful thing to do the past is really full of good ideas that failed they weren't bad ideas some of them were bad ideas but there are also a lot of good ideas that failed and knowing our industry's history and some of those ideas that failed can really suggest useful things that would solve problems that we face today and there are two two such cases here one is naked objects and one is the idea of domains as proposed in the relational model by EF Chi and then finally because Dave's keynote so nicely preempted the last things I was going to say you know what Dave said diversify yourself go outside of what's comfortable learn new things learn old things build new things or redo old things worse and find out why they are the way they are it's a fun exercise thanks very much