Finally available. This is the JAOO presentation that Ayende and I gave last year.
Archive for the ‘ActiveRecord’ Category
June 3rd, 2008
January 20th, 2008
October 4th, 2007
First of all, if you know AR and MR then I don’t think you’ll see anything new on these screencasts. They were recorded on a Denmark hotel, by Ayende and me as rehearse for our presentations at JAOO. I’m making the files available as they are (ie. no encoding tweaking).
Expect some glitches there. There was a power outage in the hotel during the recording session, just a little disturbing in the middle of a demo.
I was really tired on this one, so there are sentences there that even I can’t make any sense of. Ayende was almost down with the flu, and it was about midnight when we record this one. So bear with us!
By the way, this is Ayende during one of the recording sessions.
Update: published them on mininova. Let me know if that works
September 25th, 2007
It went perfectly well. Based on our questions to the audience we had 80% of java people, 18% of exclusive .net developers and then 2% of rails developers. And guess what Mr Fowler and Mark Pollack (from Spring.net) were on the audience.
Two things: Ayende and I recorded this presentation (a rehearse) last night in the hotel and we’re thinking in publishing it. However there was a camera and a camera man on our presentation for some reason… not sure if they are going to make it available. If they don’t, we will publish the screencast.
Now, tomorrow is going to be the MR/Castle stack presentation which is big and is going to be challenging.
Btw, I attended to Eric Evans “Strategic design” presentation: it was awesome!
March 18th, 2007
As Castle, a more than two years old project, is getting some deserved buzz, it’s a good thing to come on public and say “hey, it’s not perfect”. And I think I might be the best person to let you know what is wrong or missing with it. The good thing about OSS compared to commercial products is that nothing stop us from saying the limitations and problems. I’ll leave the comparison with other company’s strategies as an exercise to the reader.
First, what Castle Project is all about? To fully explain that, I have to give you some more information about my life.
A long long time ago, in a distant galaxy
Back to 2003 when I was a member of the Apache Avalon project I had my view of what could be a close-to-perfection IoC container. In my view it should be minimalist and yet be so easily extensible that it could handle situation we would never anticipate. That is far different from what Avalon, Hivemind and Spring tries to be. Around that time I read The Pragmatic Programmer and the orthogonality concept made a lot of sense to me, that was the almost mathematical design that should be applied to this new container.
Apache Avalon was closed due to a very disruptive community, I’ve sadly resigned from it, and a new project was started: Apache Excalibur. Again I was excited, but the community settled to be a supportive community instead of riding the tide and provide a killer IoC container to the Java community, we had the brains, we had the vote of confidence from Apache. I engaged into endless discussion about this new direction, but I can’t change the world, can I?
September of 2004 I went to London to study english and had an interview at ThoughtWorks. Met some great guys on Geek Nights, some of them I still in touch today. Was reject from ThoughtWorks because I used “final” on my variables (something that was on the guideline for Apache’s projects) and couldn’t agree that my interviewer refactorings made the code flow better (and I still can’t). So if you’re applying for TW remember to swallow your opinion and just nod, there are some very inflated egos there.
Back in Brazil, October of 2004, I was zen. Decided to sell my car and work and study on what I wanted. My passions haven’t changed since then. AI, compilers, transaction management and IoC containers. Founded Castle to provide this IoC container I have been writing for almost two years. In the meantime I was also introduced to Ruby on Rails and decided to create something for real using it. It was distant from 1.0 at the time, and I had a large amount of problems. .Net provided a much richer API than Ruby. While there was Ruby projects to fill the gap, they weren’t mature, and making everything work wasn’t easy, especially on Windows. The performance wasn’t something thrilling too. Nevertheless the simplicity offered by RoR could not be ignored.
I’ve written a book on ASP.Net WebForms, so it was hard to admit that it didn’t work as nicely as RoR. Relying on WebForms in a real, complex system led to major headaches. At this point I decided to broad Castle’s ambitious and provide a complete development stack. The major goal was to simplify our life. That was the itchy I tried to scratch: simplification.
Due to my experience on Apache Avalon I also knew what not to do to create a healthy community. Though I’ve made a lot of mistakes, I can be proud of the community fostered around Castle.
IoC and the .net camp
Though my article on Castle was well received, I understood that the .net camp wasn’t ready for IoC containers. It was wrong to push it if people are not prepared to see the benefits, and just see it as a burden (damn, I have to register components, what is that for?). I can still remember the angry reviews on blogs and blogs comments all around.
The MicroKernel (and Windsor) are the projects I most proud of, and still the projects that receive less attention. Some things that were there since the first SVN commit received some attention last week (ie interceptors support). Seems that MS has to push something to have people realizing what IoC containers are for, what interceptors could do. Having to wait for this MS pushes is kind of depressing.
Castle and the Stronghold
After being requested for consulting a few times, I decided to open a business to offer Castle related support, development and consulting. We received so many requests that shortly I had to start rejecting development and consulting requests. The good thing is that developing for so different project scenarios bring to the surface many weakness on Castle, which were fixed to proceed with the development.
That’s how the validation support came to the surface, many view components and bug fixes. The current documentation state was created in a way that we could use it, instead of always checking the source code. While this is an improvement I admit that it still lacking documents.
Offering a ‘throat to choke’ is also a good way to lowering the barriers for adoption. We know that some companies won’t embrace anything unless there’s an entity behind it that can be sued in the event of any problems.
What is missing
OSS projects have a different life cycle compared to commercial or products. On Castle we make a release and then start to implement all crazy ideas that were voiced. Stabilize the code and repeat.
Some things, in my perception, stop us from releasing a 1.0. As you will see there aren’t many, and I’m trying do decide if we should work on them now and release a 1.0, or release another Candidate and continue to work on the missing pieces.
The Component Burden, on the MicroKernel
This is somewhat difficult to explain, but stay with me. Every time you request a component from the container it might have dependencies on components with different lifestyles. For example, you might request a component that is transient, and depends on transient and pooled instances.
Today you can release the transient (root) instance, but the dependencies won’t be properly released. This is a major limitation, but fortunately 99% of scenarios do not depend on this. Anyway this is not an excuse to not implement this support.
Btw, when I say properly release, what I mean is the decommission steps won’t run and the component will not be returned to the lifecycle manager. For pooled components that means that it wont returned to the pool. Components that implement IDisposable wont have the Dispose being invoked by the container. But rest assured that the container will not hold instances creating a memory leak.
Another complex usage of containers and very useful for complex situations were components (and possibly business logic) can vary depending on some external factor. The idea is to create an hierarchy of containers. The top level container contains the invariant components, or the system core. Lower in the hierarchy you’ll find container specifically set for a client, or for a host name, or for anything that indicates the necessity of a different set up.
While I’m involved with at least three projects that will require this support at some point, I still don’t have enough use cases to implement it right. Bill Pierce has implemented almost everything required, though, but there are some issues on the backlog to be resolved.
Validator component and ActiveRecord validation infrastructure
We have to drop AR validation infrastructure in favor of the new validation component. No point in maintaining two.
While AR can make you map your database in no time, it also leads to a Domain Model that is tightly coupled with your entities on the database. Sometimes this is a big problem, so careful when adopting it on an app that will ask for a richer domain model.
MonoRail’s controller testability
The TestSupport component offered by MonoRail is totally flawed. It is useful for us, as we can use it to test how MonoRail is correctly integrated with the ASP.Net API, but it useless for any enterprise project.
The approach Aaron explains on his blog is a good way to test controllers, and I think MonoRail should offer something like that out of the box. I tried to refactor it last night to accomplish that. I gave up.
I should have used TDD to code MonoRail. Using that small time window (getting home after work, dining in front of the computer while coding changes) unsurprisingly does not create the best design. That is something I can only fix on MonoRail 2.0, or with a heavy refactoring. I’m still thinking about it…
NVelocity and Brail view engines could be better
We could work on a pre-processor that could translate more pleasant constructions into method calls or directives.
I for one dislike the usage of view components from NVelocity, but there isn’t another way to integrate it with their AST. A new view engine is being considering for a long time. IronPython view engine is also on the backlog.
View component parameters bindings
Grabbing and converting data from the ComponentParams dictionary is boring. We need a way to wire this data directly to view component’s properties.
While we have a project generator, it is not enough. Creating complex html forms is repetitive. If you have the object the form should fill, we can have the computer generating the form. You can make a change here and there, and this is something I’m working on. Marc-Andre has created a Rails-like generator, and we would like to merge it with the VS.Net add in generator. Not an easy task, though.
ActiveWriter solves the ActiveRecord generation and in a divine way.
Support for .net 1.1
This is something that was requested and with some heat, but the way DynamicProxy 2 was coded makes it an almost impossible task. I’m considering dropping this support, even if that will turn some users into enemies. :-(
We tried to do it last Friday, gave up. I tried yesterday and got sick..
As you see, lots of issues to take care of, and it’s always an opportunity to consider getting involved with Castle. Rest assured it’s an experience where everyone learns a lot.
February 14th, 2007
This is Castle crossing language boundaries! ;-)
January 24th, 2007
Dan explains how TDD works for web projects using Selenium. I like Selenium’s methods, but I still think that Watin/Watir are simpler options (no java server required).