Now that I can easily see what searches bring people to my site, it gets... interesting.

Here are some of the more... unusual searches:

• earth mother clothings
• RED DRAGON SYMBOL
•  racing frogs password
• she made him admit that girls are stronger boys

To be fair, I did post some of my old fanfic a while ago, and that seems to confuse the search engines, as those stories doesn't fit the pattern of writing I've now.

As part of my upgrade of the site, I upgraded my blog to dasBlog 1.7, so far it's been too busy jumping up and down calling "Horray" to take the time to post about it.

It's as if someone sat and made a list of all the things that I wanted in my blog, and then made them happen. (BTW, the upgrade was really smooth for dasBlog, the reason for the downtime was that I messed up the Cuyahoga's installation really bad. I really should've known better.)

I'm not talking about just good featuers, each and every one of them is something I wanted as one time or another. Really wanted.

I'm talking about things like:

• Named posts - so you don't get a GUID in your url - and it work for old posts as well.
•  Captcha for comments if you want it and additional spammers features (which thankfully I don't have to use for now.)
• Refferal lists that I can make head & tails from (searches, aggerators, etc).
• RSS channel image.
• Full WYSIWYG post editing in FireFox.
• Many more features that I'd yet to explore.

I'm reading some PR blogs recently, they've a lot of advice on how to write blogs.

Here is a particulary good one: How To Write Killer Blog Posts And More Compelling Comments

Sign here to let google know that it's an anti feature.

I've been trying to use NQA to track down some problem in Cuyahoga (old database version doesn't support sub-quries, sadly).

It has been very difficult to get it to work. In ten minutes of work I added nearly 11 bugs and I'd to walk on the straight and narrow to get it to work.

Sorry for that, the moment I'll fix those NQA will be much more usable.

After writing the last post, Peer Review Systems: Proposal, I started thinking about what a developer needs to check right now before he can start coding (this is especially relevant when access a part of the code that he didn't touch for a long time / ever).

• Documentation (Which in itself may have anything from manife
• Bugs History
• Peer Review System  :-)
• Strange mystical ambiance about the code that only those who wrote it can disperse.
• The code history - from the SCM.
• The current code.

What I want is to have some way of brining it all together, so I can look at a module and see everything that went into it in one place.

Are you aware of any such thing?

Scott Baldwin ask about how to setup peer review systems that would work with the developers (check often, review early).

The crux of the matter is that it should be as easy as possible to check in the code, and as hard as possible to ship code that wasn't reviewed. Two factors are working against each other here, if you allow the developers to check often, you will end up with a reviewer that need to read quite a bit of code. On the other hand, requiring that everything that goes into the repository will be reviewed cause either dead-locks (a developer can't continue until he's reviewed) or developers working on code without the benefit of source control. What is worse, it can get to the point where you still get a big pile of code, but now it isn't even on the repository, and you can't track how it changed. That is assuming that the reviewer won't just glance at this, see that the idention is right (about the only thing you can spot right away with reams of code) and approve it.

My propsal is (like everything this days) use rss in conjuction with the source control tags. You need to have two tags, un-reviewed & reviewed. Developers check their code as un-reviewed and then  each reviewer subscribe to the code he's responsible to watch over, (either by module, by person that did the check in, phase of the moon, whatever) and then he can watch the changes. The advantage in that is that the reviewer need only to digest small ammount of code each time (hopefully, they won't neglect this, because then they would again need to face that big pile of code :-D ).

The code that the reviewer will see will be properly displayed (i.e, not diff unless they want them.) proper change viewing can be accomplished with css today, so that shouldn't be too much of a problem (or they can just use the normal tools for code they always use). You would also get the log from the source control as a heading, telling you what this is about. The advantage here is that the developers are now encouraged to write logs that explain why things are happening, rather than what is happening ("added hbm editor" is not very helpful when I gives you ~3,000 LOC, "Compiled the Hbm schema using xsd.exe and added ui with reflection" - is a little better, but what would happen is that you get stuff like: "Compiled hbm schema using xsd.exe and added ui by reflecting on ... ").

I think that this would encourage people to write more why and how than the what.

Furthermore, we can take advantage of the rss pattern usage and have a conversation about the reviewed code. For example, if the reviewer ]didn't understand / like / has a better way/etc] he could use comment this piece asking for clarifications. The developer would need to answer those concerns before the reviewer would approve the code.

When the review decides that he approves the code, he tell it to the system, and it is moved to the reviewed tag.

Advantages of this proposal:

• Encourage better documentation for checkins and for the reasoning behind the code by encouraging developer to explain in writing what they thought they were doing.
• Expose concerns and the thought process of the developer.
• Allow to explore the reasoning behind decisions and what are the possible gotchas.
  ("We can do that for now, but we'll need to change that to Foo when we'll get to 1.2 because of Bar")
• This put the conversation between the reviewer and the developer, which would otherwise have been lost, as a first class citizen. As important as documentation or e-mails.
• Useful for teams that works in multiply sites or has complex check-in/approval process.
• Formalize a best practice in a way that is harder to ignore.
• Uses RSS, so that answers the current rage :-D

Disadvantages of this proposal:

• Add process to something that may be as simple as: "John, come and take a look at this" (But on the other hand, if it's as simple as that, it's not a formal code review.)
• Yet another place to check (Documentation, Bug Tracking System, Peer Review System, etc) before you can touch code.

Well, at least now the upgrade seems to have been completed successfully :-)

Most of the problems were because of a flaky FTP connection, though.
I'd to babysit it so it would trasfer all the files.

And then I copied the files to the wrong directory and sc`rewed it all over again ;-) Anyway, I know now that I can have a CMS as the root of my site. I don't have any time left now, so I'll finish it later.

Anyway, to save you the gory details, I screwed up and the server was down, sorry.

It should be working now.

It's about time that I did this. NHibernate Query Analyzer is now officially in beta status with the release of 0.7.

Let's cut to the chase, the project page is at: http://developer.berlios.de/projects/nqa/

The subversion repository is at: svn co svn://svn.berliod.de/nqa

But, the most important thing, of course, is the pretty long Flash Demo! 

In this release:

• Functional hbm.xml editor with full UI integration!
  Including:
  • On the fly verification of the schema and error reporting,
  • Customized menus for each element, so you can't make mistakes.
  • NHibernate QUery Analyzer will also tells you which elements and attributes are missing and then suggest ways to fix it.
• Many small bug fixes and improvements.

Next release:

• See this post and that one for details.

Known problems:

• The cfg.xml editor is not very stable and will be replaced soon.
• You can't edit elemet's inner text - no particular reason, I forgot about it until it was too late.
• Tree view names doesn't update when you change an element name.
• There is little, if any, error recovery.

Request:

• If someone with some graphical talent reads this, I need help making the UI more attractive. The current UI works, but....
• Please send any problems you've to [email protected], I can't promise to fix everything, but I can promise to try.

Thanks:

• For NHibernate itself, for making databases a breeze and XML & GUI a nightmare :-D
• To  Pierre Henri, for several good ideas and new challanges creating them.
• To xsd.exe, because of all the work it saved me.

P.S.

• The whole thing with the matching version numbers is a pure coincidence.

I just spent about three hours sweating on some code to ident text :-)

I hope to finish the integration part in an hour or so and then you'll see what this is all about.

Yes, I'm a tease... :-S