Okay, I'm currently uninstalling the
210 build of ReSharper. And for the first time, it's not because it is
unusable. The memory it consume is huge, and I really can't afford to dedicate
300 – 400 MB of RAM just to the IDE. Performance improvement should start
next week, so I expect to see a severe drop in the memory it needs.
In the meantime, I'm hitting the download
page every day or so, just to see if a newer build is out.
The last blog entry was written in
Outlook 12, and I took advantage of some of the nicest stuff it has to offer,
easy visual selection. I was wondering how it would transfer this to the web.
Now I know.
It simply took the text box with the
code and generated an image for it. Nice for making sure that things looks the
same, I guess. Not so nice when you're sending to a blog. I'm going to keep it
as a memento.
Unfortunately, I just run into this
"issue", check this out. In the context of an ASP.Net page, put this
code;
This code run for a couple of
minutes before I noticed something wrong. Suddenly my machine was very
slow an unresponsive. At first I suspected the devenv.exe process, which is
getting pretty heavy lately (mainly because of ReSharper, to be honest.) When I
managed to load the TaskManager, I found the aspnet wp.exe process was
consuming over 700Mb of memory, and was swapping like mad. It had over a
million page faults, and was advancing fast to oblivion. The machine has 1Gb
memory, and it used 1.8Gb, just to give you an idea about the pain this machine
had suffered.
This tiny piece of code managed to:
Eat 100% CPU.
Push all other memories
from memory.
Push itself out
of memory, so each loop iteration caused several page faults.
Clear the pre fetched
cache, so any new applications that I load will load much slower.
Pretty impressive, all in all. And
all I forgot is a single line of code that would advance the current time.
Some random facts that Google has to say about the readers of my site:
Apparently I'd a glaring typo in my blog
title.
I can usually get away with that,
but this time the typo was in my own name*.
Big thanks for Gunnlaugur for finding it out and
letting me know.
*well, nickname, you know the story.
It seems like the spammers are getting deperate, I started to get Spam Bug Reports!
Will it never end?
It's one of those situations, where
the very fabric of reality itself is wrapped. I'm feeling smart, because a prediction
of mine (see the footnotes) came true, but my prediction was
that I would feel like an idiot. I compromise by feeling stupid. I've wasted days
trying to find out a problem in one of my ASP.Net pages. I just found it, and
it was in a moment of enlightenment: "Oh, so that was it?"
I'm going to go over the scenario,
so you can appreciate just how stupid the whole thing was:
·
The page has user control that is being loaded dynamically.
The choice of which user control to display is controlled via a drop down list.
·
On the OnInit Event, I create the current control, and add
it to the page.
·
The page has also grid view that display a list of rules
·
.When a row in the grid view is selected, a user control is
created and added to the page (the previous control is removed), and the
current control value is set to the new value.
·
The problem occurred only when updating information (a row
was selected, the UI displayed correctly, but when posting back, the values
were never there.).
If you're an ASP.Net guru, you may have
already realized where I did wrong. If you're not a guru, let me give you a
brief overview of what was happening, one step at the time:
The user select a row,
the page is post back with the new value.
The OnInit method is
executed and the user control X is added to the page. It gets a default name of
c00.
ViewState magic
happens.
The select event handler
for the gird view is run, and the first user control is removed, and user
control Y is added. It gets a default name of c01.
The page is sent to
the user, who update the page and save.
The OnInit method is
executed and the user control Y is added to the page. It gets a default name
c00.
The postback data for
the control had the ID of c01, and there is no such control in the page now.
The view state contains
data belonging to control with id c00, which exist on the page.
Ayende go raving mad
trying to find why the control doesn't get the proper values.
No wonder that I couldn't reproduce the
problem. It has to happen in exactly the right way for it to appear. The
solution to it was to add one line to the base user control constructor, giving
it a fixed name.
This post started out its life as a scathing rant after spending way too many hours chasing after a very silly bug (which I still didn't fix, and have no idea how to). I spoke with a friend about it, and he managed to put me in perspective, so this should be a more balanced post.
It's about ASP.Net and the model that it gives the developers who develop with it. Let's go re-iterate a few well known facts here:
Those simple facts are the basic reason that we've a complex architecture for ASP.Net. It attempts to bring state into the web. It mainly does so with ViewState and a few other tricks. One of the things that ASP.Net does very well is to give you a framework where you can build web sites very easily, by using self contained components that present a very nice interface to the developer, and a nice UI for the users.
The declerative approach allows ASP.Net to get rid of a lot of needless code (at the expense of increased compile times). I really like some of the stuff that I can do there. And 3rd party components can save you weeks or months of programming. For the most part, it works quite well. There are some problems with it, of course, view state bloat is a common one, but it is the less serious one.
The more serious problem is that you no longer work on the web. You are working on ASP.Net, and the web is abstracted away from you. And you know, if it was a 99% proof abstraction, I would love it. But it's not. It can't be. So I get into problems that I can't get out of because ASP.Net tries to do clever stuff behind my back.
A recent problem that I had was with a control getting the value of another contorl. The issue turned out to be an optimization for the ASP.Net engine, where viewstate seeks where done via indexes, and my controller was at the wrong index, at the wrong time. There is a (simple) solution for this problem, but finding out what the problem was took me over a day.
To be fair, most of the issues I'm running into seems to be on the edges of what should be happening (loading a dynamic control defined in a page from the master page, if the control has initial values, it ignores all other posts and maintain its initial values). This doesn't comport me very much, since I do not walk the straight and narrow. Not often, at least. Nor do I intend to. It's incredibly frustrating to see the problem, to know what is wrong, but to be unable to find out why.
A lot of the design choices made for ASP.Net make it much easier to develop for the web without needing to think about form variables, and query strings and cookies and all the rest of the fluff that interrupt our work when we want to add some business value (or just a cool feature) to an application.
I literally can't remember the time when I run into an HTTP level bug. In any platform, in any environment. The rules are very simple, and you need to do a lot by yourself. I like that. I can control everything from the HTTP stack upward. But this force me to handle variables myself, and to keep state between request, and to handle a lot of stuff that is simply time consuming and not really productive. At the end, I'll probably roll my own version of maintaining state between request. And I'm pretty sure that it, too, will be based on a hidden field.
But rolling my own means that I can go there and figure out what is wrong. I'm a member in the Castle Project, and that means that I am familiar with MonoRail on intimate level. MonoRail doesn't offer a state management out of the box, nor does it offer a rich toolbox full of ready-made components that you can use to create rich UIs by merely dropping item into the designer surface.
I'm going to completely ignore the design and maintainbility benefits of using MonoRail, and concentrate on a totally different aspects of it. First, it's keep me very close to the stateless model of the web. Which mean that I'm not deluding myself thinking that I can build winforms applications for the web. It means that nothing much is going on that I can't predict. There is a lot of magic in MonoRail, make no mistake. But it's a magic that is carefully trimmed to make sure it doesn't evolve into the Evil Witch of the West. The second part is that I have the source (and so can you). If something is going on that I don't understand, I can dig in and find it.
Problems like the ones that have been chasing me for the last few weeks would simply go away if I used MonoRail, since I would be able to control everything from the top down. But this control come with a cost. For instance, Infragistics has some nice looking controls, which I couldn't use if I used MonoRail*. If I wanted similar functionality, I would've to write it myself.
My thoughts on that? So what? I'm not going to implement each and every features of a pack such as Infragistics. MonoRail has some really nice ways to package common functionality. How long will it take to implement a basic grid, for instance (which MonoRail already has, btw). I mean, seriously, how hard it is to spit out an HTML table? Oh, you want in place editing? That isn't that hard either.
Yes, for the first application that I would write, I may need to write components that already exists for ASP.Net, but web components are usually simple. And when they are not simple, they are specialized. One of the reasons that ASP.Net components can be complex is that they try to be both simple and extensible and the same time, and sometimes it just breaks. They are either simple or extensible. Sometimes they are neither. For the second application (or after a couple of weeks have passed with the first one)? I already have those components. I can write the HTML to display just about anything you can imagine. And from there it's a simple matter to create a reusable MonoRail component.
To wrap things up, I think that it's pretty obvious where my stance is. The time that is saved using ASP.Net productivity features isn't higher than when using MonoRail. In fact, I would argue that it's the other way around. Certainly such problems as I've run into** recently caused me to lose time rather than gain it. You've to realize that I signed today and wished to be programming in VBScript using ASP 3.0, because at least then there was nothing much between me and what was happening. This is how frustrated I've became.
One thing that I liked in both MonoRail and ASP.Net is the level of support that I can get. In MonoRail I can talk to the people who wrote the code that is giving me trouble. In ASP.Net, I can (usually) do the same***.
Note: I purposefully left Ajax out of the picture, I'm not using Ajax in my current project, so I don't want to talk about things that I don't know.
*I'm pretty sure that this is a point in favor of MonoRail, but that is just in the case of Infragistics.
**Yes, I realize that at least in part it comes from not being completely knowledgable about ASP.Net 2.0.
***And Microsoft has been very helpful. I expect to get a response from them in the morning, probably a three line answer that explains what is wrong and how to fix it****.
**** I also expect to feel like an idiot in the morning. ("Oh, so that was what was causing it?)
I knew that I would appear somehwere in Eric's post about Super Programmers & Villians. I'm the zealot, take a look at my code, it has so many design patterns I can't really count them all. And just wait until you'll see what I'm doing with generics, anonymous methods and iterators in C# 2.0.
Hahahah!*
*Evil Laugher fading into the distance...
I created an annonated class diagram for Rhino Mocks.
It's quite big, but here is the small version:
I created this using Visual Studio 2005. Click on the image to see the large version.
The diagram describe Rhino Mocks 2.5.2, released yesterday.
No future posts left, oh my!
+972 52-548-6969
