Applying monadic combinators to build simple parser

After reading this article, it dawned on me, how easy it might be to write parsers using internal dsl syntax. Looks a bit clumsy in C#, yet rather expressive.

I've used wonderful Magnum library built by Dru Sellers and Chris (creators of open source service bus MassTransit project) as a foundation, since it already contains a base for monadic parsers.

As an example, look how easy it is to write a parser for following simple grammar, describing file version structure:

<version> ::= <part>{<delim><part>|<part>}
<part> ::= <positive integer>+ | <letter>+
<delim> ::= “.” | “,” | “(” | “)” | “ “

And parser in mere 10 lines of code:



Good luck!

Dependency injection

Below is a presentation I've recently made for my colleagues.

My fellow java developer exclaimed: "But this is ridiculous to make presentations about DI! Everybody supposed to know it!" And this is a big difference between two worlds .Net & Java. In java even junior developers know benefits of DI, whereas you can find a senior developer having no knowledge of DI in .Net realm. I consider it to be a consequence of paying way to much attention to developers' tools by Microsoft. LightSwitch and WebMatrix are a justification to my words. Hey guys, do you really think we are that stupid? Why constantly lower the bar?

Nevertheles, if you are interested, check it out and browse for code examples that come with my presentation.

Dependency injection

Code as I promised.

Good luck!

Windsor Castle BuildUp

Good news, everyone! I've discovered a way to enhance a brilliant DI-container Castle Windsor with not so brilliant feature as BuildUp.

Saying that it is not that brilliant I mean that this feature is a beast, actually. It is an open door to violate DI principles, and there are more elegant ways to overcome a problem of having to resolve an external object through DI-container. After all, if Castle team considered this feature useful, they would roll it out long time ago, have no doubt!
However, in my case it is a matter of time, to have an opportunity of resolving existing object's dependencies through DI-container, built as fast as possible. That is why I turned to BuildUp feature that some other DI-frameworks have.

I was really amused with Windsor's degree of extendability and how trivial my solution appeared.

BuildUp functionality is closed up under ComponentActivator. Activators are called when LifetimeManager considers that a new object has to be created. And that logically brings us to restriction of this solution - it won't work with Singleton lifestyle. But it shouldn't actually! When you mark an object as a singleton - you effectively state that a container is going to be an owner of that object, thus it won't ever be built externally.



BuildUpComponentActivator extends DefaultComponentActivator and overrides a single method - Instantiate. This guy is a cheater, as you might guess, it never creates an object, but simply read it from context. All the dirty job of deriving dependencies is done by a parent class. Should BuildUpComponentActivator fail to find an object in context, it will simply delegate all work to parent, and a new object will be created. This is done to support resolving objects of the same type managed by container.

Context is a dictionary, created with BuildUp extension method:



In order to be able to build up an object, one have to modify it's registration and override ComponentActivator setting. CanBeBuiltUp is a neat extension method wrapping this call for Windsor fluent registration API.

There is only one shortcoming with this solution I came with - it doesn't provide you with any facilities to release this external object's dependencies. It has to be done manually somewhere.

Please note, that there are other solutions to this problem.

Good luck!

My two cents in OSS. Free VOIP .Net library.

Good news, everyone!

A brand new pure OOP VOIP open souce library has just entered the .Net realm - pjsip4net. This is my projection of plain "2D" procedural C library pjsip into "3D" world of objects. It is so trendy to go 3D nowadays that I just couldn't resist. =)

To be correct pjsip4net is a wrapper above high-level pjsua API. It provides you with readymade user agent capable to issue calls over SIP & (S)RTP protocols via UDP or TCP or even TLS from your .Net code.

Actually, this code is still under construction due to my constant need to improve. But keep your wig on, it is already usable and tested.

I have covered prety much everything in pjsua API, but still this is what you can do with it:

• register at SIP server;
• select a sound device;
• select and prioritize codecs;
• call another party;
• auto answer;
• auto conference (all calls will be marshalled to one big conference);
• NAT traversal (STUN, TURN, ICE);
  
• blah blah blah with other party.
  

Enter pjsip4net: http://code.google.com/p/pjsip4net/

Good luck!

ORM-style Identity generator or impossible is nothing.

What the hell?! Isn't it a bit like even odds? Everybody knows that it is impossible to prevent NHibernate from breaking Unit of Work semantics, when your primary keys are generated by SQL Server Identity facility. To justify that, please read the following: generators revealed, and follow on with this story.

In short, the major problem of Identity generator is that it is a post insert generator, that is to say it can't produce new Id value without INSERT statement being executed by database engine. Furthermore NHibernate can't persist entity without Id. That is why NHibernate will insert our object to the database the moment it was persisted without waiting for Flush() to be called. This causes huge problems should you try to implement long-running business transactions. The biggest trouble is that you won't be able to rollback changes made in business transaction.

In short, this is what I want to achieve:

• insert values into Identity fields on my own;
• acqiure correct Identity values that wouldn't cause troubles in database;

UPD: As it was fairly noticed, it looks like I work very hard to get something that is already in the box (HiLo). It really looks like that, but I have to prove that is not a waste of time. The point is that my case is constrained with existing database with defined schema. This database is filled with loads of records by other processes that I have no access to. That is why I can't use solutions like HiLo and have to invent my own.

In SQL Server one can disable autoincrement for Identity field and insert its own values. But how would he get a correct value? The easiest way is to insert a dummy row in a local transaction and then perform a rollback. After transaction was cancelled, Identity value won't be reverted. Thus, by changing a table and reverting all changes made, we produce a gap in an Identity sequence, and the gap value can be inserted manually afterwards.

Having said that, I've drawn a following sequence diagram:

The solution, as it comes from a diagram above, consists of 3 parts:

• Custom Id generator, which I've called ORMIdentityGenerator;
• PreInsert listener, to disable Identity field autoincrement;
• PostInsert listener, to enable Identity field autoincrement back;

ORMIdentityGenerator

This is an easiest possible implementation of what I was talking before. Agile principles say KISS - keep it simple, stupid! and that is what I do. This generator is merely an INSERT statement executor. One can configure it with the INSERT statement to perform safe (in terms of database integrity) operation that will change a table and force database to produce a new Identity value. This value will be returned with a next SELECT statement execution.

PreInsert


PostInsert


That's it. Now I can edit my persistent objects with Id field generated by Identity in a long-running session and rollback changes should I need it.

Good luck!