Marcel Popescu

At work I have a few dozen (and will at some point get to hundreds) workflows with the same structure: [XmlSerializerFormat]   [ServiceContract(Namespace =  "http://schema.company.com/messages/" )]   public   interface  IBasicContract<TRequest, TResponse>     where TRequest :  class      where TResponse :  class    {     [XmlSerializerFormat]     [OperationContract(Name =  "GetReport" ,       Action =  "http://schema.company.com/messages/GetReport" ,       ReplyAction =  "http://schema.company.com/messages/GetReportResponse" )]     [ServiceKnownType( typeof  (Aggregate))]     TResponse GetReport(TRequest inquiry);        [XmlSerializerFormat]...

This is a reply to this question on stackoverflow . Many people "feel" that allocating a thread per socket is a bad idea. This might be true for 10,000 sockets, I don't know; however, for 300 threads which are idle most of the time, this is really not an issue - and hasn't been in Windows since at least Windows 2000. Here's how this would look on my system: I am going to put the code in the answer to the stackoverflow question; this is just a placeholder for the above image, mostly :)

From this comment : I seem to be known to many of those around me as an all around nice guy, a good guy even. But I'm an asshole, a self-absorbed prick. (...) I often find that I'm doing good things out of an awareness that I should want to do them, than because I actually feel that desire. This could have been written by me. Ouch.

Many times during the lifetime of a project I find myself writing something like this: method A(){ ... var something = B(); ... } method B(){ ... var somethingElse = C(); ... } It doesn't take long to realize that this could be written in a different way: method A(){ ... var somethingElse = C(); var something = B(somethingElse); ... } method B(somethingElse){ ... } The problem is - which way should I prefer? Which way is "better"? I have struggled with this for a while now. Today I just realized something: SRP (as applied to methods) says each method should only have one reason to change. (I was reading this article when I had this epiphany.) If something changes in C(), that effect will "ripple" to both B and A in the first case. In the second case, it is much more likely that it will only affect A. Which is fine - it is A's responsibility to "join together" the two other methods, so it's ok if it's affected by them....

1 Cor 6:12 "Everything is permissible for me" — but not everything is beneficial. "Everything is permissible for me" — but I will not be mastered by anything.

I worked on a crapload of small ASP.NET projects where I spent a lot of time on user management: add users, edit users, change roles, verify roles and so on. This includes tiny projects like a tiny website where the content of about 10 pages can be edited by the customer (mostly by adding news). They'll never have more than one person doing these edits, their primary business is totally unrelated to computers. Well, I was reading this article by Scott Hanselman and what do I see: Does it need an administrative console?, I ask. He says that'd be nice, but it wasn't spec'ed out. He figured this would be pretty low rent. The client even suggested (gasp) that they could just maintain a local XML file. How on Earth can I be so stupid? I always knew that ASP.NET had this feature... it just never crossed my mind to use it. Dammit.

Great article here . I hate the programmers dragging the certification bogey-man every time they have a problem with someone's code. Yeah, we really want to have the problems of the medical field. This article is a breath of fresh air.