I am one of those who have really hard time talking generalities. Mainly because lacking a frame of reference usually cause me to try to spin in all directions at once, and Depends is a really bad way to formulate an argument. More often than not, a concrete example, hopefully backed with a code sample that can be dissected, is much more valuable, simply because it focuses the discussion on the subject at hand, instead of scattering it over all the possibility matrix.
The other problem with just talking is that words are cheap, and it is fairly easy to speak in such general terms that the conversation will be meaningless. I got burned really bad on the real world with overly general discussions, and now I mostly tend to drive people crazy by asking more and more questions with regard to the implementation details.
Strangely enough, I don't have the issue of going from a mess of details to an overall view of how things are combined.
Scott Bellware has a post about Responsible SRP, he presents the Ruby's idiom of skinny controller & fat model vs. the .Net one of a service layer. He links to this post from Jamis Buck, which explains the Ruby concepts much better. This is also something that is annoying me about my current application, Rhino Igloo doesn't really provide the same level of separation that I consider essential, and as a result my controllers are doing way more than I wish them to. I probably should have broken at least some of them up to services.
I find myself troubled, because while I agree with all that Scott says in this post, and most certainly with Jamis about the overall direction, I can also see the scaling issues of this approach.
The problem is that when you have even a moderately large application and you keep pushing things to the model, it will go beyond fat, it will be obese. You can see some of the tricks to manage it here (I was surprised that I was able to follow them, actually, very neat), but this is most assuredly something that the RoR crowd has already reached.
Let us take the example of the User model, and assume that I would structure my application this way, I don't see it working. My IAuthorizationService has roughly 25 methods already (I am thinking of breaking it up, that is too much), and trying to put them, plus the IAuthenticationService and the various things that the User already does into the User model would create something that would be hard to follow. It certainly wouldn't be in keeping of SRP.
Another approach is to use mixins in Ruby to separate the functionality into different files and mixed it into the User model. I don't really like it, but that is perhaps a matter of taste.
Again, another matter of probably biased conceptions, but I truly like it much better when I can wire up another implementation rather than start modifying code when I need to make a change to the code. My ideal would be a lot of very small classes, all collaborating in order to get some result. This, to me, gives a lot of flexibly and power when I come to utilize them.
I would be interested in getting response from the Ruby community, what happens when the model get too big? How do you break it up then?
Leon is talking about the way Microsoft Regional Events are handled, interesting reading. We don't have those in Israel, and in the last Microsoft conference ( I took part in it ), we built our own talks, from our own experiences.
When you are thinking about investing the time in coming to an event, there is nothing quite as annoying by being shown something from marketing. That is a waste of time for most people.
The Israeli mind-set is such that 2,000 people can just leave the TechEd keynote talk if they feel that it is wasting their time. Marketing is a waste of time and it shows that your product is (a) lacking in concrete exciting features (b) you are not respecting the intelligence of the audience.
Soren seems to have detailed notes on a lot of the sessions, I already pointed out his coverage of my DSL talk, but he also covered the talks that Hamilton and I did.
Damn, but that is a good book. A different style than most of the other ones, with a lot more investment in characters than in actions, but very good nonetheless. Highly recommended.
Finished it in one sitting, and already want more, but that would be out in 2008 :-(
It came out four days ago, and I can't believe that I let four days pass by without getting that.
Yes, it is that good.
I was just getting ready to listen to Black Powder War, the third part of this series, but with changing times comes changing plans.
Now I intend to read the ebook, hopefully this will take up the rest of the night only, and then listen to Black Powder War and then to Empire of Ivory as an audio book.
I don't have Throne of Jade as an audio book, the story was masterfully told, but I didn't like all the PITA politics that went there, too realistic and far too close to stuff that I had to deal with in the past, so I am skipping that.
I really enjoyed His Majesty Dragon as both an ebook and an audio book, however. I usually don't re-read books at those intervals, but Naomi is a very talented writer. And I am looking forward to that.
Right now I have finished listening to We Few from David Weber again (started on the flight, actually), and I am really wishing that this story had more books in it, there are at least two that I can think of.
Now I just need to get through some Brail bugs before I can dedicate myself to truly masterful story telling...
Manuel Abadia has some criticism on NHibernate that I wanted to respond to. First things first, though, it seems that I have been hasty in my response to a problem that Manuel reported, NH-1123. I really don't like it when other people do it to me, and I would like to apologize to Manuel for treating him in a manner I don't wish to be treated.
As an aside, I have created a new bug on the JIRA, with a bit more focus on the underlying problem. This bug has now been fixed, and I would like to thank Manuel for (a) finding it, (b) persisting even after I wasn't as attentive as I should. Interesting bug, by the way.
He had several other things to say, which I want to respond to in details:
1) It is heavily tied to the java version (Hiberante), so a lot of the request and/or enhancements are ignored. If the java version is not going to add it, probably it will not be added to NHibernate.
I wouldn't say that, NHibernate is focused on bringing us up to par with Hibernate, but that is certainly not saying that we aren't going to add things that Hibernate doesn't have. Right now, MultiQuery and MultiCriteria are stuff that Hibernate doesn't have and we do, and there are others.
At the same time, if a feature request is something that we can either develop from scratch or port from Hibernate, we would rather bring it from Hibernate. The main reasons are to make it easier to use documentation, built on already fixed bugs, maintain knowledge, and more.
2) Hibernate was started in 2001, and was designed to overcome a lot of the ORM problems. During these years, it has solved a lot of those problems, but other still remain and they can’t be fixed without heavily changing its design.
There are certainly things that I would change with NHibernate/Hibernate if I were able. One of the things on the very top of the list would be to turn the entire internals to AST manipulation and delay the actual generation of SQL to just before executing the query / command. We are working on that, actually. And you are more than welcome to join in and help us do so. And yes, I do mean you, personally, dear reader.
I would be interested to learn what the other problems are, by the way.
3) Even if it is extensible, the IInterceptor interface does not expose all the events that can be interesting to capture (For example, events after loading, updating or deleting data). The only way to handle that at the moment is to implement the ILifecycle interface by the entity itself, losing entity transparency.
Fabio Maulo has been doing tremendous amount of work on this very topic, and NHibernate 2.0 will have the full power of events and listeners from Hibernate 3.0. Most of the world have been completed, and can be found on NHibernate trunk, it opens quite a bit of possibilities.
4) No paging support in some nontrivial scenarios.
As I said, the bug was fixed, but even without that, I would still say that this is not correct. There are quite a few ways that you can do paging in NHibernate, the default approach is not always the best one.
5) There is no support for retrieving all the data at once for hierarchical queries
Here is one example of how to do just that :-)
Okay, that was cheating, since it used native SQL, but that did worked through NHibernate, and you got live entities back from it. No, NHibernate has not native support for doing hierarchical queries, and to support them we have the prerequisite of AST based internal, most probably. (At least the way I think about them)
There is also multi queries, which is what I use to do hierarchies all over the place, mainly because they are far cheaper than a single hierarchical query in real world scenarios (7 tables representing hierarchy, in my case).
To surmise, I would like to mention that NHibernate is an open source project. By its very nature, you are able to go into the code and fix things yourself! NHibernate's codebase is fairly big, but it is also well partitioned, so you are going to find it much easier to work with it than you would expect by simple size estimates.
If you have a problem, by all means, please report it, but do give a try at fixing it, that is going to be easier than you imagine.
Usually when I start a system, I want to focus on the shortest scenario that would bring me a live system. That is usually the login page, since that is almost universally identical.
My approach to that is fairly simple, Login Controller that collaborate with an authentication service and an authorization service. The first to verify who the user is, the second to verify that the user even has the right to log in. I always use interfaces for those, so I would have IAuthorizationService and IAuthenticationService as the forth or fifth elements in my application.
Now, the reason for interfaces is actually not mocking, or anything of the like. If is simply because an interface allows me to create a strict separation between what is going on and how it works.
In order to complete the story, I may often need to write ActiveDirectoryAuthenticationService, but that is an implementation detail, I don't want to know about that. I want the interface to express just the required detailed for authentication, not to be involved with the details of actually handling the AD authentication.
In most projects I am going to have only one implementation of many of those types of interfaces, but the fact that I maintain this separation means that reading the code that makes use of those interfaces is far easier than it would have been otherwise. There is a wider line between the two collaborators, and far less chance of letting implementation semantics go through.
I was in place to try to extract those semantics out once or twice, and that is never pleasant or easy.
Wendy has a very good point here. Good practices, good design, are not there in order to facilitate some fad-of-the-day. The case she is giving is DI, SRP and SoC with regards to testing, and then taking the nuclear approach to testing, and deciding that since you can do just fake on the fly anything you need, you can test without DI, SRP and SoC, therefor, you don't need them any more.
That is a problem.
Consider for a moment the guide lines for writing good C programs. Short methods, clear naming, guard clauses, etc. Those still holds today. In fact, pretty much all of the good design rules are not tied down to a technology or a language, and I have very rarely seen a case where it was beneficial to ignore design guidelines.
I am extremely suspicious of anything that asserts that "because you are using XYZ, then the following guidelines no longer applies." Dependency Injection is a good tool, which I can live without if other methods are provided, but ignoring basic guide lines such as the Single Responsibility Principal or Separation of Concerns is going to bite you in the end, each and every time.
Something really bothered me in JAOO. A couple of the presenters had a slide that showed something like this:
The Relational / OO Divide
- DBA not familiar with OO design
- Developer not familiar with SQL
I asked around, and apparently there is this assumption on the Java world that developers are usually only vaguely familiar with SQL. I am not sure if this is the case in practice or not, but that just sounds insane to me.
I live in the .NET world, and here I expect all developers to have a fairly good grasp of SQL and how it works. Not to the DBA level, I wouldn't really expect a developer to be able to fully analyze a query or optimize it based on index scan patterns for Oracle 11.g with patch XYZ.B, but I would expect that they would know SQL as well as they know their programming language of choice.
In fact, thinking about it, in most of my recent projects, a developer is expected to know at least the following languages:
| || |
This isn't really from choice, this is simply because those are the stuff that we use fairly often. It seems odd to assume that you would limit that. That would severely limit your ability to actually do useful work.
Here is an observation, once a code base has reached a certain size, either in time or in size, it usually takes on a style and identity of its own. This is far more than just a coding style that I am talking about. I don't care where you put the braces. I am talking about the repeated patterns that you see over and over in side that code base.
An example would be Castle-inspired projects. You are far more likely to see things named SmartXYZ or IAbcAware, with the usual implications that there are there.
What are the styles that you have noticed?
When Hamilton and me gave the MonoRail talk to the Enterprise Application track, we asked how many people were .NET vs JAVA vs Ruby. The results where roughly 43%, 43% and 4%, respectively.
The interesting part was when I asked how many of the .NET guys used Web Forms, almost all of them said that they do. Then I asked how many enjoyed using Web Forms.
No one raised their hands.
It is not relevant because it is a thing of the past. Quite a few of the people that I met there, both speakers and attendees are taking agile and its practices as granted.
As in: Well, obviously this is how you build a software project, how can you do it any other way?
My company doesn't do agile development, lots of background here, and I am not going into it, and my own efforts seems both puny and diminishing values at some points, it was incredible to see people with that kind of mind set, and to know that this was basically everyone there.
Okay, I am finally home. After running into three late consecutive flights, slow bus, late train and one sweat car ride home. All in all, it was about 20 hours on the road (from the moment I left the hotel to the moment I reached home). I am suddenly reminded of all the reasons why I don't really like to travel. Couldn't sleep the whole trip, so I am acting very funny now, got a whole torrent of stuff out in one go when I got home, got pretty funny responses, as well.
I am going to crash soon...
We started with the MonoRail talk, which went fairly well. That wasn't recorded, but Hammett and I had recorded the rehearsal, so I think we will publish that.
The next session was about choosing a web framework, and the focus was on Java frameworks. Interesting to see the design decisions that they take, although I remain firm in my opinion that Java has too much XML involved.
The next session that I took part of (again, had to drop off because I was feeling very bad) was about the Guradian UK site, and how they manage to scale it up. Stateless, multi level caching and some very interesting smarts around fail over (stopping the cache from expiring anything in case of a downed DB, for instance). Something very interesting was to explore the scalability features of your DB, because too often people just ignore the perf benefits that the DB can do, and try to do everything in the application.
The Enterprise Application Panel was interesting, it was mostly focused on future directions, and the main conclustion is that we are in the end of a shakedown in terms of web frameworks and environments, at the end of which you are likely to have far clearer idea about what are the sweet spots for each framework / environment.
Flash and Silverlight were mentioned, as well as a 1MB JVM, but I am sceptical of those as a general purpose development platforms, simply because the constraints that they have are so severe. Flash doesn't handle Hebrew very well, and Silverlight doesn't support it at all (Justin is working on that, though). By the same token, it doesn't handle Arabic or Chienese very well. And limiting the programming environment means that you are left with very bad model to develop on.
I see a lot of value on building specific components or parts of the application in those technologies, but not doing it across the board, at least not in the kind of applications that I tend to write.
I'll have another post summrizing the entire conference in a while...
We had the wierd Eric Meijer keynote, and then me and Hamilton gave the Active Record talk. It went very well, I think, although we could have probably used twice the alloted time :-)
It was recorded, and should probably appear on InfoQ sometime soon.
Later we went to Eric Evans talk about Strategic Design. I read the blue book, and I thought I understood it, but just listening to Eric talk for an hour was quite an eye opener in many respects.
After that talk I basically crashed, I had a terrible cold that was a real PITA when we presented, so that was JAOO's second day for me.
At my house I have literally several boxes that they used to belong to my grandmother, before she passed away, and they contain an odd mix of junk and precious family history.
I am sure that this is not an uncommon story, and a lot of our history is composed of letters that were read after the sender / reciever were dead. A lot of the time this offers an unreplacable view of what really happened.
And if we try to look at less than the human history, then just having the possibility of going through the mail / documents of someone allows you to understand what is going on, and take actions with regards to it. (Such as paying the mortage)
I don't get any written letters anymore, excepts bills. Everything is done using emails. I am not unique. I keep a lot of what I do up in the cloud.
So, what happens when someone dies? To the best of my knowledge, there is no real process / precedant for that.
Even assuming that you have access to the passwords, would anyone would go through those emails in a hundred years? Would they be able to?
This talk was the keynote for yesterday, and I came out of it with a profound sense of shock. If this is where Microsoft is headed, then they are in a real problem.
Some of the things that really bothered me:
- Don't learn anything new, let Microsoft chew it up for you first.
- Let us compile our C# to JS (good) and then just make some of the calls a remote ajax calls (bad).
I would have thought that they would have learned from the DCOM debacle, if nothing else. Location Transperancy is a Bad Thing.
In general, Too Much Magic is a bad thing.
- SQL and JS are assembly language concepts, you should only work in C#, and let Microsot handle them.
That was so wierd, and so out of touch with reality...
To prove that, I need to write correct multi threaded code. I started to write parallel sort routine, Erlang fashion, in C#, but that is too complex for me when I am not under suspiction of being drunk.
So I wrote Hello World.
It is 400 lines of code and it has got five threads, so I guess that officially proves that I am not drunk.
Now all I need is to figure out why the code is all wavy and flowing.
I don't care about fluent interface or not, but I am pretty sure that Visual Studio doesn't have the "crawling ants" features...
The slides & code from my JAOO talk can be found here.
Started the day in a presentation from Robert C. Martin, which was very good, both in content and delivery. Moved on to give a talk about building DSL with Boo. It went well, as far as I can tell, but I was the one giving it.
After that I was at the Erlang talk, which is quite probably the best one that will be here. Joe has created the language and wrote the book about it, so he certainly knows his stuff, and he is a Character with a capital C. I am not sure if it is a show or not, but it was amazingly amusing.
From my point of view, the major advantage of Erlang oer anything else is the ability to wait without blocking an os thread. That is something that I don't think that we can do (externally) on .Net, which is a shame.
Bought the Erlang book, it is a weird language compare to those I know, but I really need to learn a new language this year, and Erlang gets me both functional and concurrent aspects for the "price" of one.
After that I sat in a couple of talks in the Ruby track, "Ruby in the Enterpise" and "Ruby and the art of building DSLs".
I like the ideas being evolved in Ruby, but I have reservation about doing development there. I know that I say this as a person who didn't do any real project there, but I have the feeling that Ruby isn't for me. Basically doesn't provide a significant advantage over what I already have in .Net
The reason that I say that it is not for me is because development is actually a small part of a software project, and there is a lot of other things that I don't think that Ruby does as well as other platforms (profiling, debugging, deployment, monitoring, etc).
To be rather more precise, I think that .Net has much better tooling surrounding it than those for Ruby. That, coupled with the fact that I don't see a Killer Feature of working on Ruby itself, means that I am not really interested in it as a platform.
I am very interested in Ruby as a place to harvest a lot of interesting and efficent approaches. It is certainly one of the fastest moving communities around, and it is rich in smart people.
Right now I am at the Spring.NET talk, wihch is interesting, not because of the technology concepts (I mostly know them), but because of the different design decisions that were made, and the different "culture" that afected it.
Allow me to divert a bit from the usual technical rambling of this blog. I have just arrived at JAOO, and I am still in awe of the Copenhagen's air port. Unlike Israel's or Frankfort's airports, which are industrial, commercial and ad-laden, the Copenhagen airport was a work of art.
It is not a really a good way to describe it, but the entire place is beautifully coordinated, and it feels like the stores there are there to complete it, not to shout at me. The entire thing is holistically whole.
The rest of the place is also quite amazing, from the most comfortable chairs in an airport that I have seen to really nice places for kids (from a toy garden to a lego playfield), etc. The attention for beauty goes across the entire (huge) airport, which means that it was really impressive.
Here is an image that I stole from flickr, it doesn't really do it justice, but it should give you the starting of an idea. You really have to be there to be impressed by it.
I am going to leave for JAOO in a few minutes, see you next in Denmark :-)