Downloads

Original project is here

Modified binaries: IIS_LogAnalyzer_Bin.rar (360.01 kb)

Patch file : Indihiang_LogAnalyzer_FTPSupport.patch (170.94 kb)

Screen Shots

Note for Vista Users

Modified version creates a TempDir under the application installation folder and downloads files there. Vista does not allow regular user to create directories under Program files so if you install the application under Program Files , right click on the Indihiang.exe, click Properties and check "Run this program as an administrator" option found in Compatibility page.

For a while I'm trying to align a technology toolset for Web 2.0 development. Recently I decided to go with Microsoft .NET technologies and JQuery.

Here are the tools I'm provisioning to utilize

• ASP.NET MVC and JQuery
• ADO.NET Entity Framework
• WCF
• May be ADO.NET Data Services and ADO.NET Dynamic Data

Why?

Some time ago while I was working on a project, that was a top secret project so can not give more details ,  I realized that I've produced some sort of weird code that checks if an interval (Start,Stop integer value pair) intersects with another interval. Right after unit testing and commiting the code I felt like there is something wrong wih me. Here are the details

Nothing Fancy

Here is the code of my Interval structure. There is nothing fancy about this structure it is used to hold two integer values and performs range checking in the constructor to guarantee that start value is always smaller or equal to stop value.

public struct Interval
{ 
  private int _startValue;
  public int StartValue
  {
      get { return _startValue; }
      private set { _startValue = value; }
    }
   
    private int _stopValue;
    public int StopValue
    {
      get { return _stopValue; }
      private set { _stopValue = value; }
    }

    public Interval(int startValue, int stopValue)
    {
      if (startValue > stopValue)
        throw new TypeInitializationException("Interval",
          new Exception("Provided start value is greater than the provided stop value."));

      _startValue = startValue;
      _stopValue = stopValue;
    }

    public bool IntersectsWith(Interval interval)
    {
      //TODO: Check if this intersects with the provided interval
    }
}

Conventional Way

Conventional way of implementing that IntersectsWith method is to 1) write some if/else blocks or 2) to combine a single return statement  to cover all of the cases illustrated on the following image

My Problem

But somehow I did not choose the conventional implementation and I decided, in fact by reflex, to re-model Interval objects as rectangles with 1px in height , place them on xy coordinate system and check if two rectangles intersect or are tangent to each other. Here is my weird IntersectsWith implementation

public bool IntersectsWith(Interval interval)
{
  Rectangle r1 = new Rectangle(StartValue, 0, StopValue - StartValue, 1);
  Rectangle r2 = new Rectangle(interval.StartValue, 0, interval.StopValue - interval.StartValue, 1);

  return r1.IntersectsWith(r2) || (r1.X + r1.Width == r2.X) || (r2.X + r2.Width == r1.X);
 }

Questions to myself

• Is this weird implementation is a result of too much analytical thinking?
• Is this weird implementation is a result of too much abstract modeling I have to do to perform my job well?
• Shall I see a therapist?
• Is this weirdness a common pattern among developers?
• Shall I ask this as an interview question? And what shall I do with people implementing this method like me and not like me?
• How will my colleagues feel when they have to read my wierd IntersectsWith implementation?
• Shall I be ashamed of myself? 

Code

WeirdIntersectsWith.rar (23.00 kb)

CodeProject

Implicitly typed local variables introduced in C# 3.0 specification is very cool. Those who used VB and some other scripting languages are familiar with untyped variables and other who used VC++ and Delphi will remember the Variant type. But implicitly typed variables are different in C# 3.0. For example in VB actual type is determined at runtime and that is true for the Variant type too,but the actual type of the implicitly typed local variables are determined during compile time which eliminates lots of headache. C# 3.0 specification introduces "var" keyword to define an implicitly typed local variable. For example

C#-Code:

 


public void SomeMethod()

{

    //int x = 12;

    var x = 12;

    //double y = 12.0;

    var y = 12.0;

    //string z = "Sample string";

    var z = "Sample string";

    //int[] k = new int[]{1,2,3,4};

    var k = new [] {1,2,3,4};

} 

Returning back to the original issue, using implicitly typed local variables saves lots of coding time and may be considered as a must for LINQ powered C# code. But do not forget that every piece of code may be debugged or reviewed by another person and by you some time later which brings code quality issues into scene. Readability is one important sign of the code quality and in some cases and depending on your coding practices using implicitly typed local variables may decrease your code quality as a result of difficult to read/review code. The key point here is how we review a piece of text as an average human. From my personal experience I can say that

• We tend to anchor to the headings and try to understand the details backreferencing the heading
• We may need short descriptions or walk throughs before we start understanding a complex issue
• Not to get lost in a long text we tend to summarize what we have understood so far
• When we finish practicing the text we try to infer a result from what we have highlighted in previous steps
• After inferring a result we can start to invent our own understanding of the subject

I think that scheme is applicable to debugging and code review practice. Knowing these we, as software developers, should avoid practices which may turn our code to a nightmare for other developers. I think if you

• Use meaningfull names for your classes, methods and variables. Every code entity, be it a class, a varible or a method ,  should mimic its purpose of existence by its name if possible.
• Write atomic methods. I mean writing methods that perform only a single well defined task.
• Comment your code well (Some developers tend to write more comments than the actual code, if you do this I suggest you to review your code you might be doing something wrong or incomplete)
• Keep the level of method chaining in a reasonable level

you shall use implicitly typed local variables without hesitation. But if you have readability problems with your code be carefull while using implicitly typed local variables, that will bring more complexity to your already hard to grasp code.

For a while I am thinking about the Microsoft's support to open source projects. Some news that attracted my attention to this issue were

• Foundation of CodePlex, open source project hosting web site of Microsoft
• Ms-PL license developed by Microsoft  
• Release of .NET Framework libraries  source code . Read more
• Release of ASP .NET MVC source code. Read more

Heritage

Microsoft has developed very successfull technologies through history. COM/ActiveX formed a good baseline for MS platforms and related runtimes like MTS, COM+ and DCOM were a must for enterprise level application development targeted at MS platforms. VB was a fantastic programming language, even I've never written single line of VB code I remember how my co-workers rocked with VB, ASP was not perfect but it was, actually it still is, productive and easy to learn and VC++ powered with MFC was the programming language of choice for lower level software development. All these runtimes, frameworks and languages were not perfect, but they did succeeded in helping software developers to produce valuable software. However some of these technologies required software developers to have some sort of geek talent. For example it was very difficult for a regular software developer to write some sort of event sink COM code or programmatically configure the DCOM environment. I think Microsoft has learned more than we expected from the history I briefly tried to explain. Now we are at the age of .NET and related technologies and personally I expect less hesitation than the previous experiences we all ran through.
More...

Some PragmaSQL users were notifying me about a strange but deadly serious error caused after recovering from a server connection transport-level error. To reproduce the error follow these steps:

1- Open PragmaSQL Editor and choose a connection from Saved Connections list to connect. I will assume that Default Database of the selected connection is DatabaseA 

2- In the opened script editor change database to DatabaseB

3- Open to Microsoft Sql Server Management Studio and from Management node select Activity Monitor. Find the process for DatabaseB created by PragmaSQL application and kill that process.

4- Return to PragmaSQL editor and try to execute the select statement for the selected database, that is DatabaseB.

5- You will get transport-level error after trying to execute the statement for the first time.

6- Try to execute the statement again and this time you will succeed. But the statement was executed on the initial database, that is DatabaseA not in DatabaseB (selected one ). This error may cause very serious problems if you were trying to modify data you would simply modify the data in wrong database.

The problem is actually with database change code inside PragmaSQL which is not really a bug but misusage of SqlConnection class's ChangeDatabase method. While I was coding the change database logic I did not realy realised that ChangeDatabase method does not modify the Initial Catalog property of the ConnectionString, actually there is no way to modify the ConnectionString property of the SqlConnection object once it is opened. SqlConnection object in the script editor is created and opened only after the user changes the selected server, database changes does not cause a new SqlConnection object to be created and opened, we simply change the database property of the existing SqlConnection object and that is it. I did not considered SqlConnection object's error recovery scnearios (transport-level error for example) at all. The fact is that SqlConnection class recovers from transport-level error very well but uses the ConnectionString property to reopen the connection, no matter what was the database before the error SqlConnection object always restores connection to Initial Catalog property specified in the ConnectionString.

Very ugly bug, but I am happy to resolve that one. Upcoming 1.0.0.34 version will include solution for this issue.