Development ideas

How to initialize instances asyncronously

2017-06-20T22:39:00.002+01:00

Here is another problem I've been thinking about quite a while, before found a solution I like.
async/await keywords revolutionized the writing of asynchronous code in C#. It is as simple as marking a method with async keyword and using await in it to wait for asynchronous operations to complete in non-blocking manner.This gets trickier with async initialization methods. Think about a class, instances of which need to be initialized once only, before those can be used. In a non-async scenario one example would be to call the initialization method from the constructor, as follows:

public class SomeDirectory
{
  private Object state;

  public SomeDirectory()
  {
    this.Initialize();
  }

  // This method expects the state to be initialized before execution
  public void DoSomething()
  {
    // some logic
  }

  private void Initialize()
  {
    this.state = // state retrieval logic
  }
}

This gets complicated, when the initialization method becomes asynchronous. As constructors are non-async methods, the following transformation can lead to a situation, where instances of the SomeDirectory class aren't yet initialized after constructor, which can lead to some unexpected side-effects later, when the DoSomething method is called. The below sample code emphasizes the situation:

public class SomeDirectory
{
  private Object state;

  public SomeDirectory()
  {
    this.InitializeAsync();
  }

  // This method expects the state to be initialized before execution
  public async Task DoSomethingAsync()
  {
   // some logic
  }

  private async Task InitializeAsync()
  {
    this.state = // state retrieval logic
  }
}

A simple solution to this would be to force the constructor to wait for the initialization to complete:

  public SomeDirectory()
  {
    this.InitializeAsync().GetAwaiter().GetResult();
  }

This, however, is not a good technique, as it will introduce delay in the caller thread, which can harm in many situations (like in server code, where the actual DoSomethingAsync api is not being called immediately).

The third approach is calling initialization on every public API. Of course with a simple "run-only-once" optimization in it. Something like this:

public class SomeDirectory
{
  private readonly Object stateLock = new Object();
  private Object state;

  public SomeDirectory()
  {
  }

  // This method expects the state to be initialized before execution
  public async Task DoSomethingAsync()
  {
    await this.InitializeAsync();

   // some logic
  }
}

The problem with this approach is that it will slow down the very first call to DoSomethingAsync() method. Sometimes - it's something you don't want to have.
So here comes the final approach, which I'm using nowdays:

public class SomeDirectory
{
  private Object state;
  private readonly Task initializationTask;

  public SomeDirectory()
  {
    this.initializationTask = this.InitializeAsync();
  }

  // This method expects the state to be initialized before execution
  public async Task DoSomethingAsync()
  {
    await this.initializationTask;

   // some logic
  }

  private async Task InitializeAsync()
  {
    this.state = // state retrieval logic
  }
}

This approach will allow the execution of the initialization start as soon as the object is constructed. Yet, it won't loose the track of its execution.

Hope this will help some of you.

Unknown disposables: Disposing of non-disposable interface instances

2016-07-22T17:56:00.001+01:00

In coding, it's a good practice to use factory methods (or some other creational design pattern) to abstract away creation of class instances. In most of the cases, the "creator" would return not the actual type being created, but the abstraction - the interface.

To emphasize the problem, let's consider the below example:

For simplicity, let's assume that we're dealing with a factory method, and the interface the factory method returns is called "IContract". Note, that IContract does not implement IDisposable. There are two different implementations of IContract - Impl and DisposableImpl. So here comes the interesting part, the DisposableImpl implementation does implement IDisposable.

So now, if one uses the factory method "Create()" to instantiate IContract, it may get a disposable instance back, and won't ever even know about it:

public class ContractFactory
{
public IContract Create()
{

return new DisposableImpl();

}

Obviously, the responsibility of disposing of the disposable instance is on the caller. A lot of people won't even notice the problem and just use the IContract and never worry about freeing up resources as early as possible. Yes, GC will eventually take care of the unnecessary resources, but that'll happen later than the actual variable becomes unnecessary - during finalization.

So one pattern a client can use is the following:

{

IContract contract = null;

try {

contract = new ContractFactory().Create();

// all the usage of the contract instance happens here

}

finally
{

IDisposable disposableContract = contract as IDisposable;

if (disposableContract != null)
{

            disposableContract.Dispose();
        }
    }

}

This will ensure safety in case of both disposable and non-disposable implementations.

Another way to go, would be to have a wrapper class, encapsulating the disposal logic and being a disposable itself, as follows:

public sealed class DisposableInterface<T> : IDisposable where T : class
{
private readonly T interfaceInstance;

public T Instance
{

get { return this.interfaceInstance; }

}

public DisposableInterface(T instance)
{

if (instance == null)

{

throw new ArgumentNullException("instance");

}

this.interfaceInstance = instance;

}

// A better implementation would be the usage of the Dispose pattern here.

// Not doing that here to keep the sample simple.

public void Dispose()
{

IDisposable disposableInstance = this.Instance as IDisposable;

if (disposableInstance != null)
{

            disposableInstance.Dispose();
        }
    }

}

Now, the caller could use the IContract as follows:

{

using (DisposableInterface<IContract> contract = new DisposableInterface<IContract>(new ContractFactory().Create()))

{

IContract instance = contract.Instance;

// all the interaction now happens with the "instance" reference

}

As you can see, the second example is cleaner and nicer.

Now, as you're familiar with the problem, doesn't it raise a natural question: "should this become a pattern and be used all over the place with factory methods, as one can't know whether the actual implementation the factory methods returns will be disposable or not?"....

Think about this and leave any comments you may have.

"RunAs /NetOnly" functionality from C# code

2015-06-17T18:53:00.001+01:00

Only recently I've learnt about the "/netonly" flag availability for "runas" command. I was really happy to find it, but the issue came later.
It turns out that the runas.exe command can't be automated, as it accepts passwords only through a prompt. So there is no way to pass in credentials without the prompt.

That made me seek for a custom solution for the problem. What it turned out is that the .Net Process API doesn't expose any functionality to control the process creation the way, which "/netonly" flag would results in.

Long story short, I came up with the following solution:
The CreateProcessWithLogonW Win32 API, which is being called internally by runas.exe, has a number of parameters indicating how exactly the process should be created. One of these parameters is "dwLogonFlags". The set of values it can take has one called "LOGON_NETCREDENTIALS_ONLY". From MSDN documentation for that value: "Log on, but use the specified credentials on the network only. The new process uses the same token as the caller, but the system creates a new logon session within LSA, and the process uses the specified credentials as the default credentials.". This is exactly what I need. After few hours of unsuccessful search for a C# code sample, which would create a process with this flag, I ended up creating my own.
The sample code is available for download at: http://1drv.ms/1LeqKnD

Hope you find this useful !

The Compatibility Pattern: Designing adaptive classes

2015-04-09T17:30:00.003+01:00

Any non-deprecated system, soon or late, faces challenges. Some of these challenges are quite common. The two following items represent just a fraction of those:

existing file storage doesn't satisfy current/coming space requirements
the data model need to be modified/extended to comply with new requirements

Today I’m going to describe a design pattern, which can be applied in a variety of situations (including the two above) and eliminate the pain of code re-write.

So, for the sake of simplicity let’s concentrate on a single scenario. Let’s assume we have an existing system – which is operational. Let’s also assume that “EntityA” is an entity in the data model of the system, and the records of that entity are processed by some business logic: “LogicA”. So far the system used to operate just fine. Now – new requirements come in – which introduce changes to “EntityA” and the “LogicA” as well. Specifically, new “EntityA” records should be treated differently than the “old/current” records. For the sake of simplicity, let’s limit the changes in “EntityA” by just one new field “Field2”. So here what “EntityA” will look like:

where “Field1” is an existing field on the entity. Note, that I intentionally don’t mention the types here as its irrelevant in this context.

Also, let’s assume that “LogicA” is already encapsulated in a class with the same name, as follows:

Now, back to the new requirements, which affect “LogicA”. The simplest way to handle the change would be to modify the “LogicA.ProcessData” method. However that won’t be maintainable. Think about any future changes – affecting the same logic. After several such changes it’ll be really a mess and it won’t be easy to figure out how to change something to impact only specific version of entities. So the simplest and design-wise proper solution would be to introduce new LogicA_New handler for the new entities and put the decision logic of instantiating the proper logic in some factory class. The following diagram depicts that case:

Note, that the abstraction of the handling logic into separate classes is an implementation of the Strategy design pattern.

This model allows future expansion of the system by just defining a new strategy/logic and updating the factory method, to return the proper handler type. Handling logic deprecation is quite straight forward as well, and can be handled in the reverse order: the factory method is updated to remove the obsolete case and the appropriate logic handler is removed.

Hope this will save you some time in the future.

The interview process

2015-04-01T07:03:00.001+01:00

Looking back - there were many times I’ve went through an interview process for different software development positions in different companies. To be more precise – there were around 20 interviews I’ve went through. Frankly saying, it doesn’t matter what kind of company you’re interviewing for – 60% of the technical questions will be very similar (of course, there are rare exceptions to this rule). And if you’ve gone through at least 5 interview processes, you probably know what to look for - how to prepare for those questions.

Why ? Because most of those questions you’ll be asked will be just formality and well known mathematical problems. It’s just a matter of filling in a checkbox whether you’ve answered a question or not – and the chances you’d be ever dealing with that kind of problem during your day to day work – are almost 0! To answer these kind of questions you’d need to just have walked over any similar problem in the past. Most of those share very similar solutions.

These 60% are the bad part of the interview process and I call – THE INTERVIEW TAX. Because you have to learn those anyway even if you won’t be dealing with anything close to those questions.

Now, let’s talk about the other 40%. Those divide into three categories:

Thinking questions
Practice questions
Design questions

1. Thinking questions

These may easily be unsolvable mathematical problems as well. And the interviewer is asking you the question and also ask to think loudly. This is important as what he/she wants to observe – is how you think. Or – do you think at all. I know it’s funny, but I’ve seen people just having no ideas on how to solve a problem.

On the other hand, the problem can be really simple as well – very trivial – but the discussion around it will be like building a knowledge graph: you say something, you get another question on what you said, you answer again, and again get a new question – which slowly takes you away from the original topic. These discussions can take hours (luckily the interviewer will have a schedule).

2. Practice questions

The questions here are simple coding questions in your preferred programming language (unless the company has strict requirements about the coding language). In most of the cases – even a pseudo-code will be fine. These questions are aimed to verify your coding skills – like properly handling validation, corner cases. In the end you most probably will be given also a task to write unit-tests for your code. The interviewer may have noticed a mistake in the code, and sometimes want you to catch it – so be careful to do so. If you’ll write a code and the tests you’ll write won’t handle it – that’ll be reflected negatively for you.

3. Design questions

This is my preferred topic. Unfortunately these are quite rare questions during the interview process you get asked. I believe those are the most valuable ones as those will be giving answers on how well you’ll be doing your work – if you’ll be hired.

Anyway – here you may be given some real-world problems – and you’d have to solve it – by describing a system from a high level. The system can be very small or very big – depending on the responsibilities you’re being considered for. But even on the smallest systems (a simple example is an elevator or an alarm clock) some important skills can be seen.

I hope this writing will be a good overview for one who is looking forward for an interview and also for those who host interviews – to improve their existing processes, if they fall in the 60% category.

C# 6.0: The great changes

2015-01-10T06:00:00.001+00:00

It's now more than 10 years I'm writing code in C# and I enjoy every part of it. It gets better with every version, and there is no exception in the coming version: C# 6.0.
Everybody who had ever dealt with MVVM pattern, will be well familiar with the INotifyPropertyChange interface. The tedious part of the implementation were the constants (I used to have constants always) you had to define per each publicly exposed property - to store the name of the property.
I recently had a post about how to retrieve the property names dynamically using reflection (here), but still it's not everyone would consider a good option to go with. C# 6.0 mitigates this pain with a new keyword called "nameof".
To get the name of a property you'd simply write: nameof(PropName), and this would return "PropName". Really cool !

And now the other thing I am happy about. Remember the String.Format("Name: {0}", record.Name) way of doing things ? There were many issues I've seen where updating the format one forgets to add additional parameter, or adds one, but forgets to add the '{X}' placeholder for it - which would cause a runtime exception. C# 6.0 changes the mechanism completely - as now instead of the placeholders you'll just refer to the values within the format string. That's much more readable and safe:
String.Format("Name: \{record.Name}")

And there is much more...

WCF: Identifing late exceptions in the pipeline

2014-12-23T17:20:00.000+00:00

Hi.
Recently I’ve run into a strange WCF service issue. The logs in the service method were indicating a successful completion of the call, but the call was still failing and the clients were getting exceptions.
The exception message was: “An error occurred while receiving the HTTP response to <serviceEndpoint>. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down).“.
The service API which was called had a return type (not void), and the type was serializable. So the only explanation I could come up with was that something wrong goes with serialization. THAT WAS IT!
Luckily it’s possible to simulate the same serialization what WCF does behind the scene, and verify the assumptions. So I did it: created a test method within the unit-test project, called the API being called by the client to get properly built result object, and then tried to serialize it:

[TestMethod]
public void GetDataUsingDataContract_SerializesResults()
{ Service1 serviceInstance = new Service1();
CompositeType argument = new CompositeType();
CompositeType result = serviceInstance.GetDataUsingDataContract(argument);

using (MemoryStream stream = new MemoryStream())
{ DataContractSerializer serializer = new DataContractSerializer(typeof(CompositeType));
serializer.WriteObject(stream, result);
}
}

Note: you’ll need to add a reference to System.Runtime.Serialization.dll.

In my case the “serializer.WriteObject(stream, result);” call threw with the detailed exception.

You can download the full sample project: http://1drv.ms/1sJljCd

Hope this helps.

Windows Phone 8: The Map control

2014-09-06T07:14:00.001+01:00

Recently I've been hitting an issue with integrating the Map control from the Windows Phone Toolkit into the UI. The problem was related to centering map to the desired location. I was using MVVM pattern for the app, so I had a proper public property in the data context, which I was trying to set as a binding source for the Center property of the Map control.

As I was just interested in centering map based on the property value, and not vice-versa, I've had explicitly specified the Mode property for the binding to be "One Way". And that was the problem.
It turns out, that for the Center property to work properly, you have to have the binding mode set to "Two Way".

So the final property and the XAML should be similar to the following to work:

The following property is the one defined in the data context:
public GeoCoordinate MapCenterLocation
{
get
{
return this.mapCenterLocation;
}
set
  {
    if (value != this.mapCenterLocation)
    {
      this.NotifyPropertyChanging(MapCenterLocationPropertyName);
      this.mapCenterLocation = value;
      this.NotifyPropertyChanged(MapCenterLocationPropertyName);
    }
}
}

and the appropriate XAML for the map control should be:
<maps:Map x:Name="map"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch"
   Center="{Binding Path=MapCenterLocation, Mode=TwoWay}" />

As mentioned above - the "Mode=TwoWay" is critical for the Center property binding to work. Otherwise, the map will never be centered like the binding is not there.
Interestingly, you don't even get an error/warning for that.

Dynamic Reflection in C#

2014-04-10T17:51:00.000+01:00

Hi,

More and more I started to feel the need for dynamic reflection - reflection working not based on subject names (properties, methods, fields ,...) but delegates.
So got time to submit and idea on Microsoft Connect about it. The following sample shows what the idea is about:
internal class Sample
{
public int PropA { get; set; }
public void SomeMethod()
{
  PropertyInfo info = GetPropertyInfo(() => this.PropA);
  // Some other code, using the "info" variable
}

public static PropertyInfo GetPropertyInfo(Func<object> property)
{
  // This is the method I'm asking about.
}
}
If you like it, please go and vote for it at: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5755035-ability-to-get-propertyinfo-dynamically-passing-th

Update:
It turns out what I've asked in this post is possible using Expression trees. The following is the working example on how to achieve it:
    public static class PropertyExtensions
    {
        public static PropertyInfo GetPropertyInfo<TSource, TProperty>(this TSource instance, Expression<Func<TSource, TProperty>> propExtractor)
        {
            MemberExpression mexp = propExtractor.Body as MemberExpression;
            if (mexp == null)
            {
                throw new ArgumentException("Invalid");
            }
            PropertyInfo result = mexp.Member as PropertyInfo;
            if (result == null)
            {
                throw new ArgumentException("Invalid expression");
            }
            return result;
        }
    }

Breaking the debugger session like an exception was thrown

2014-03-11T23:52:00.001+00:00

Today I cam across a situation, which made me think about an new feature in Visual Studio Debugger.
But first about the scenario: I've been debugging a component test, and wanted to stop the debugger. But the same time - I couldn't do that, as that won't take the execution through the normal cleanup flow, defined in a finally block.
Then I thought about the feature I've started with, and here is the link to it: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5624050-stopping-debug-session-to-go-through-the-defined

So please read it and vote for it !

How I've fixed the periodic crashing IE problem

2014-02-20T06:44:00.004+00:00

Hi there,

Today I've finally managed to fix the crashing IE problem, under Windows 8.1. So decided to share my experience, hoping for some of you out there - this post will be in help.
But first, let me give you a bit of history.

Frankly saying, I'm a Microsoft fan. Yes, I do work in Microsoft as a software developer.
So you guessed already, that I do use Windows - I love it ! I have had a chance to play with other OS-s as well, so please - no comments about "you haven't seen others".
So, my machine was running Windows 7 for a while already. And one day - Microsoft announces the availability of Windows 8 Preview. Of course - I do install it (on a VM for now). I guess it took some time for me to get used to it, and eventually, I liked it as well. Then - the release, and, as expected, I'm upgrading my main OS to it immediately.
Let me tell you the truth - that was the best OS upgrade experience I've ever went through. No issues, no hassles - and everything works: everything except the most used product - the Internet Explorer, which keeps crashing periodically - about 50 times a day.
Well, I now realize, that my laziness was keeping me away from trying to look into the actual problem, and fix it. So I was just tolerating that, and using it again and again. By the way, the non-desktop version of IE was ok, no crashes, no issues. And I started using that one more and more.
And finally, the final crash made me so angry, that I've forgot about my laziness, and decided to dig deeper.
First thing was to open the Windows Event Log (Windows Logs \ Application), and look for most recent errors: luckily the only errors were from IE (those I've been hitting). And the error message was very similar to:

Faulting application name: IEXPLORE.EXE, version: 11.0.9600.16518, time stamp: 0x52f347b2
Faulting module name: <module name>, version: <module version>, time stamp: 0x513d9755
Exception code: 0xc0000005
Fault offset: 0x00046ce7
Faulting process id: 0x4280
Faulting application start time: 0x01cf2df55b897962
Faulting application path: C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE
Faulting module path: <the path to the failing module>
Report Id: 9aa55680-99e8-11e3-bf29-c48508058295
Faulting package full name:
Faulting package-relative application ID:

Looking to the "Faulting module path" I guess will give you a clear picture - of what is really failing. In my case that was a file download application. I've then just uninstalled that application, and it's already 4 hours (I would have about 15 crashes already) - no issues.
Hopefully you'll be able to handle this now.

Sorry for non development related post.

Regards,
Artak

Unit Testing DateTime.Now or DateTime.UtcNow

2013-10-17T23:25:00.001+01:00

TDD is a great methodology, and if you follow it properly and get fanatic about it, then you eventually look for time to refactor all your code to be properly designed - hence - testable.
Eventually, you'll come up to a code where you've used DateTime.Now or DateTime.UtcNow properties, and start to think, should you really need to test this minor bit? The answer will be "Absolutely YES". But then, does it worth it to refactor the code for this simple thing?
If you're lazy enough and would be happy to solve the problem with some minor risk, then the following technique will be for you.
Let's say you want to test the following code - the Save() method:

internal class SampleState
{
    public DateTime LastSaved {get; set;}

    public void Save()
    {
          this.LastSaved = DateTime.UtcNow;
    }
}

The proper way would be to mock out the date/time provider and refer to it in the code. Alternatively this simple technique will be helpful:

[TestMethod]
public void Save_SetsLastSavedTime()
{
    // Setup
    SampleState sut = new SampleState();
    DateTime beforeCall = DateTime.UtcNow;

    // Act
    sut.Save();

    DateTime afterCall = DateTime.UtcNow;

    // Validate
    Assert.IsTrue(sut.LastSaved >= beforeCall && sut.LastSaved <= afterCall);
}

The technique insures, that the time saved is within the test interval between the call started and ended. As mentioned before - this is not an explicit verification, but still - it gives high confidence that the proper time is being set.

Hope this will be useful !

The Dispose() method and the inheritance

2012-10-10T06:27:00.001+01:00

Today I am going to write about the IDisposable interface – it’s Dispose() method, and how this should be really implemented in derived classes. The simplest implementation of Dispose() method will be just introduction of the following code to the class, and that’s all:

public class A : IDisposable
{    public void Dispose()
    {        // Disposal logic here 
    }
}

and this seems to be fine, but it is not.

Let’s assume for now that everything is fine, and we ship a library with the above code in it. Somebody, who is using the library, can easily use it in the following way:
public class B : A
{    public new void Dispose()
    {        //Class B specific dispose logic in here
        //And the following call is essential here

        base.Dispose();
    }
}

This seems to be fine as well, unless someone else, or even the owner of class B will use it in the following way:

using (A item = new B())
{    // some logic here
}

In this case, when exiting from the using block, the Dispose() method of type A will be called, which is sitting in the method table in memory as a separate record, and has nothing related to the Dispose() method of type B. And this will become a possible reason for a memory leak – any unmanaged resources introduced in class B will not be cleaned up !

One solution, of course will be to cast item to type B and call it’s Dispose() method explicitly, but that’s just complicating things, because this will need to be done in a finally block.

So let’s now see what I meant saying “it is not” in the beginning of the article, when was defining class A.

The thing is the the implementer of a public type must take the responsibility of problems like the one described by implementing types the way, so the users will not need to worry about the usage.

And the solution is actually simple – in every case, when introducing a type which implements the IDisposable interface, the Dispose() method must be marked either virtual (and the derived classes should override that method), or whole the class must be marked as sealed.

So by defining class A as sealed we will explicitly restrict its usage the way it was described – the incorrect usage. Now let’s see what will change, if we’ll mark the Dispose() method in class A as virtual and in class B override it.

Remember, this will force a single method record for a derived type to appear in the method table, so no matter how you’ll reference an instance of type B (either through type A, or any other type in the hierarchy) the Dispose method will call the Dispose method of type B, which, assumable (if implemented correct – as in the example above) will call the parent type’s Dispose() method and this will go by chain until the top of the hierarchy, making sure that any resource in whole the hierarchy got disposed.

Good luck with development !

Synchronization: Working with synchronized resources

2012-08-02T18:02:00.001+01:00

Today I'm going to write again about the synchronization, but will mainly concentrate on the way of helping to avoid some code duplication, and will save some time.

In one of my previous posts I've described several ways of synchronizing access to the resource, and what we’ve pointed out there as a general (of course with exceptions) practice each synchronized resource in needs to have an associated object, used for synchronizing access to that resource only, and for nothing else.

Thinking about that I came up with the following class definition which I found very handy:

public class ConcurrentResource<T>

  private readonly Object syncRoot = new Object();

  public readonly T Resource;

  public ConcurrentResource(T argResource)

    if (argResource == null)

      throw new ArgumentNullException("argResource");

    this.Resource = argResource;

The ConcurrentResource type will encapsulate the object which to the access is going to be synchronized, and will also define internally a read-only property called syncRoot, which will be used for synchronizing the access.

Using that type I found it really handy but let me describe a bit more the use of it and what methods we can add to it to make it handier to work with.

So let's imagine we want to do some action with locking that resource. The following method will be really handy here, because it will encapsulate the locking mechanism in it as you can see:

public void HandleActionInSyncronizedContext(Action argAction)

  if(argAction == null)

    throw new ArgumentNullException("argAction");

  lock(this.syncRoot)

    argAction();

So the method internally will handle the locking mechanism and the caller will not need to use it directly in the code. One advantage of the abstraction, is that it will be very handy when we will need to switch from lock{…} to Monitor.Enter(…) call with timeout in one place, and get it working everywhere. There are bunch of interesting methods we can add to that type, and here are few of those:

public void WaitForPulse()

  Monitor.Wait(this.Resource);

public void Pulse()

  this.HandleActionInSyncronizedContext(()=>

    Monitor.PulseAll(this.Resource);

});

As a complete example of usage of the ConcurrentResource( of T) type you can take a look to the sources of ConsoleHoster project in here.

Delegates and Events

2012-07-22T00:46:00.000+01:00

Today I’d like to write about the events, but because I cannot talk about events without delegates, I’ll cover those as well in this post.

To make the article easier to understand (for new developers at least) let me describe a more real-world example so we’ll be able to model things from it. One such example can be the fire brigades' work – how they react to fires, how they being notified about fires and so on.
So thinking about it I assume that every fire brigade works for some kind of center, which control’s its work. And every such center has several brigades under its control. So let’s model that center as FireAlarmingCenter class described below:

public class FireAlarmingCenter
{
}

As we said earlier the FireAlarmingCenter will be one who notifies about fire alerts to the fire brigades. Before we will be able to add that notification capability to the FireAlarmingCenter class, we need to define what the notification will look like. and here where the delegates come in. To specify the details about the specifics of the notification we need to describe those through a delegate, which will define a signature of a method it can reference to, or a method, which can be used as a handler for an event of that delegate type.

public delegate void FireAlarmEventHandler(FireAlarmingCenter argCenter, AlarmDetails argDetails);

Now let’s add the event definition to the FireAlarmingCenter type as follows:

public event FireAlarmEventHandler FireAlarm;

Great, now we have the FireAlarmingCenter type, so let's see how this event is going to be consumed.
As we have said already, the consumers of FireAlarm event will be the fire brigades, which we can model like this:

public class FireBrigade
{
    public FireBrigade(FireAlarmingCenter argCenter)
    {
        if (argCenter == null)
            throw new ArgumentNullException("argCenter");

        this.Center = argCenter;
    }

    public FireAlarmingCenter Center
    {
        get;
        private set;
    }
}

Now we’ve created the base plumbing so the FireBrigade will have the reference to the FireAlarmingCenter it’s “working for”. But there is still a hole there – the FIreBrigade doesn’t somehow “listen” to the FireAlarm event of its center. To do so, we just need to aappend the following line to the FireBrigade class constructor:

this.Center.FireAlarm += new FireAlarmEventHandler(this.HandleFireAlarm);

Although the C# 4.0 language let’s the developers to skip the delegate type after += operation, when registering for events and specify only the method name, which is going to work as handler for that event, I like that style, so its really visible from code what type exactly the event is, so to the handler method signature is. So that line will assume that we’ve defined the “HandleFireAlarm” method already in the FireBrigade class, which will contain logic about what to do in case of a fire.
Now let's see how the FireAlarmingCenter will notify the FireBrigade-s about a fire. I’m not going to write or guess what the conditions are on when to notify it, but am really going to concentrate on how it will be fired. The most simple way to do that is as follows:

private void OnFireAlarm(AlarmDetails argDetails)
{
    if (this.FireAlarm != null)
    {
        this.FireAlarm(this, argDetails);
    }
}

Very nice and simple, it’s really not what we want. So let’s go and see what is happening behind those lines ?
So the first line in the method checks whether there are any listeners registered for the FireAlarm event or not. Next, if there are listeners to the FireAlarm event, the most important thing is going to happen – the event is going to be called. To answer the question – “what means an event is called?”, I’ll need to go back a bit to describe what the delegate is.
So the delegate is a reference of a method, but not only – it is actually a list of references to methods, which all are matching the signature of the delegate. Actually, the definition of the delegate we’ve created is being translated by the compiler to a class definition with the name of that delegate and deriving from an abstract class called “MulticastDelegate”:

public class FireAlarmEventHandler : MulticastDelegate
{
}

So now we can approach to an event as a field of a specified delegate type in a class it’s defined in. So when in the FireBrigade class’s constructor the += operation on the FireAlarm event is being called, it actually adds a new method reference (which is specified on the right from the += operator) to the delegate invocation list.
Now, when the event (in this case the FireAlarm) is being called, the following happens:An iterator is being created which iterates over all the registered methods to that delegate instance, and each element of that iterator (in this case a method reference) the method is being called with parameters passed in to the event call. But this seems to contain a problem.Imagine a situation when during the event listeneres execution (iterating over the list of handler methods) a new FireBrigade will be constructed for that FireAlarmingCenter – the invocation list will be modified so an exception will be thrown here.But don’t worry – there is a very handy way of handling this and I really like it. If we’ll modify the code like this:

private void OnFireAlarm(AlarmDetails argDetails)
{
    FireAlarmEventHandler tmpEvent = this.FireAlarm;
    if (tmpEvent != null)
    {
        tmpEvent(this, argDetails);
    }
}

on the first line in the method the invokation list of the delegate will be copied and the next operations will be working on the copied list including the invocation itself) so adding or removing any new handlers to the FireAlarm event won’t affect the invocation any more. This technique is usually referenced as “Event Invoke Pattern”.
Visual Studio has a very nice snippet for this: “invoke”. Just type invoke in VS.Net and hit Tab twice (Tab+Tab) and you’ll get the code automatically appear in your source.

So I think that’s all for this post. Good luck with your development.

The ConsoleHoster app

2012-07-15T16:36:00.001+01:00

Hi.

The recent 4-5 months I was working on a very interesting project which will most probably be a help for other developers. Feeling quite good about it I finally decided to make it open source.
So here is the link where it's published: http://consolehoster.codeplex.com/
Hope you'll like it, and please leave your feedback there and join me in developing it, if you're intersted.
In my future posts I'll try to cover it in more details.

Regards,
Artak

Regex: Identifying paths

2012-07-08T23:29:00.001+01:00

Hi again and thank you for visiting my blog.

It's already three months I'm working on a project which again, as many other projects I'm working/worked on, started from just an idea.
So one of the challenges I met in this project was to come up with a regular expression, which will identify whether the given part of the string is a path, part of it, or relative one.
Remember (or if you don't know try) the TAB support in windows command window - you can type in a relative or full path, then type some prefix and on each sequentiall hit of TAB button, the file/folder names, which are in the specified path and start with the typed prefix, will be placed like auto-completition feature one after another.
So I finally came up with the following regular expressoin:
"((((^\w:|\s\w:)|\.\.?)(\/|\\))?(([\w.]+( [\w.]+)?)(\/|\\))*)|((((^\w:|\s\w:)|\.\.?)(\/|\\))?(([\w.]+([\w.]+)?)(\/|\\))*))([\w\.]*)\t"
Because it's quite complex, the processing was really taking long. First I tried to compile that regular expression into a separate assembly and then use the compiled one, but unfortunately it affected the performance harder, than earlier. Eventually I understood that I don't need all the groups defined in the pattern, so I removed those (marked those not to be counted as groups using (?:...)), and it increased the performance really good. So here what I ended up with:

"(?:(?:(?:(^\w:|\s\w:)|\.\.?)(?:\/|\\))?(?:(?:[\w.]+(?: [\w.]+)?)(?:\/|\\))*)|(?:(?:(?:(^\w:|\s\w:)|\.\.?)(?:\/|\\))?(?:(?:[\w.]+(?:[\w.]+)?)(?:\/|\\))*))([\w\.]*)\t"Althought the compiled query execution time need to be shorter than the non compiled one, I haven't went into details why it was like that, but the fact is fact - that's true. I'm pretty sure that for shorter regular expressions that will work faster, but no in this case.

Hope the regex will be helpful.

Enjoy .Net Development !!!

Syncronization: deadlocks and how to identify those

2012-04-09T23:45:00.001+01:00

These days synchronization become very actual problem for any developer - nowdays its really hard to even imagine a single threaded application. Of course with this, some headache arises with deadlocks. Usually developers use lock(...) { } statement to synchronize access to some code block, and that is one possible reason of a deadlock. Don't get me wrong - I don't say that if you use lock statement, then you have a deadlock, but what I say, is that if you have a deadlock - then its definitely happening on one of the lock statements you've used in your code. So what to do to avoid those ? Or actually, which will be more correct to say, how to identify the lock statement where the thread blocks causing a deadlock forever ?
Fortunately, as almost always, there is a very handy option under the hand - The Monitor class. You probably know, that the lock (obj){...} statements translates to the following code:
try
{
    Monitor.Enter(obj);
    // ...
}
finally
{
    Montior.Exit(obj);
}
To make this code "deadlock-proof", you need to replace the Monitor.Enter method call as follows:
try
{
    if(!Monitor.TryEnter(obj, TimeSpan.FromSeconds(2))
    {
        // Log deadlock reason in here
        throw new Exception("Unable to take exclusive lock on the given object");
    }
    // ...
}
finally
{
    Montior.Exit(obj);
}

Here we are passing a TimeStamp parameter to the TryEnter method, specifying the amount of time to wait for the lock. So if during the specified time period it is impossible to take lock over the specified object, then the method will return false, and we'll be able to log something, which will tell us the place in code where the actual deadlock is happening. Of course it's not so convenient to use whole this construct in code, so this can be extracted to an extension method like the following:

public static void SyncronizeCallByLocking(this Action argAction, object argLock)
{
// Argument validation in here
  if (!Monitor.TryEnter(argLock, TimeSpan.FromSeconds(2000)))
  {
    // Log exception in here, if required
    throw new ApplicationException("Unable to lock the object");
  }

try
  {
    argAction();
  }
finally
{
    Monitor.Exit(argLock);
}
}

After this it's really easy to wrap the code block, which needs to be synchronized like this:

new Action(()=>

{

// Code which needs to be syncronized

}).SyncronizeCallByLocking(objectToLock);

By using this technique you will definitely not waste many hours of struggling by trying to find the deadlock reasons in your application, and guessing where those can arise from. Of course, if you want after fixing all the issues you're free to convert back to using the lock statement instead of what was described, but I won't bother about it, because you don't know what changes may come later, and how those may affect your application.

Good luck with your development.

Reading redirected output of the process: limitations and how to work around

2012-03-27T09:19:00.001+01:00

During last month I was working on a project built on top of the Console-windows. An interesting problem I was facing is the read of redirected output (asyncronous) from that process. It seems to be quite easy to handle such a task, and it is, unless you need to read "all the output".

Well, the simple approach of handling such a task is like the following:

1. Define a ProcessStartInfo with redirected output:

ProcessStartInfo tmpStartInfo = new ProcessStartInfo()

    {
        FileName = "consoleApp.exe",
        UseShellExecute = false,
        RedirectStandardOutput = true

}

2. Create a process and set the start info to alrelady defined one:

ProcessStartInfo tmpProcess = new Process()

tmpProcess.StartInfo = tmpStartInfo;

3. Define and register a handler for the OutputDataReceived event:

    private static void Process_OutputDataReceived(object sendingProcess, DataReceivedEventArgs outLine)
    {
        Console.WriteLine(outLine);

}

tmpProcess.OutputDataReceived += new DataReceivedEventHandler (Process_OutputDataReceived);

4. Start the process.

tmpProcess.Start();

Yes, it's simple, but there is an open issue left in here. The process won't redirect the output, until there is a new-line character in the stream, which means, that the Process will fire the OutputDataReceived event only as soon as a new line is available on the stream. So for me this was a big limitation, because if the process is writing something on a line and still waits for some input from the user on the same line, we will never receive that line, and won't even know that the process is waiting for user input there.

To fix this we need to observe the stream on our own, not awaiting the event to fire. So, here is the algorithm I came up with, to handle the behavior described:

private void ObserveStreamInBackground()

{

try

{

char? tmpStreamChar = null;

{

int tmpStatus = this.Stream.Peek();

if (tmpStatus == -1)

{

if (this.messageBuffer.Length > 0)

{

this.InformMessage();

}

tmpStreamChar = (char)this.Stream.Read();

}

char tmpCurrentChar = tmpStreamChar ?? (char)this.Stream.Read();

if (tmpStreamChar.HasValue)

{

tmpStreamChar = null;

}

this.messageBuffer.Append(tmpCurrentChar);

if (tmpCurrentChar == '\n')

{

this.InformMessage();

}

} while (true);

}

catch (ThreadAbortException ex)

{

}

private void InformMessage()

{

string tmpMessage = this.messageBuffer.ToString();

this.messageBuffer.Clear();

this.lastMessage = tmpMessage;

this.lastMessageReceivedAt = DateTime.Now;

this.OnMessageReceived(tmpMessage);

}

The InformMessage() method is there to just clear the current message buffer and fire the event with the message data in it.

That's all. Experiment with it and give me your feedback. Good Luck !

Reflection: working with generic types

2012-03-09T02:38:00.000+00:00

An interesting problem I was facing during last few days drives me to write this post. The problem was to create a generic type instance (let's say List), the type parameter for which is known only during runtime. Let's examine the following code fragment:

Type genericListOfInt = typeof(List<int>);
Type genericListOfString = typeof(List<string>);
bool sameType = genericListOfInt == genericListOfString;
//sameType is false here, so those Types are differenet

Both the variables seems to be instances of the same List (List of T) type, but because the T type parameter is different the compiler will generate two different classes for List and List so the variables will not be equal. But how to handle the problem we do face ?
Examining the System.Type class we will find out a very interesting method called:GetGenericTypeDefinition() method. This method returns a Type object, representing the generic type definition, from which the type, which for the method was called, was constructed, so actually the type, which can be used to construct other Generic types as well.
So modifying the code above will give us the following:

Type genericListOfInt = typeof(List<int>);
Type genericListOfString = typeof(List<string>);

bool sameType = genericListOfInt == genericListOfString;
//sameType variable is true now, so both variables are referencing the same Type instance

Apparently, the type, which is reffered by both genericListOfInt and genericListOfString variables can be accessed with the following variable as well:

Type genericList = typeof(List<>);

This makes it really handy, so we don't want the compiler to generate any classed which are actually useless just to get the reference to a generic type.
Now this type can be used to construct different Lists for different types dynamically (List<[any type you want here]>). So here is a simple code for constructing a list of the given type:

public static object CreateGenericList(Type ofType)
{
  Type genericListType = typeof(List<>);
  return Activator.CreateInstance(genericListType.MakeGenericType(new Type[]{ofType}));
}

Please note also, that the List type was taken for example only, so to access multi-type based generic type (like KeyValuePair<k,v>) you can easily use the same technique:

Type genericKVPair = typeof(KeyValuePair<,>);

Now, the last scenario left to discuss, is how to dynamically identify the generic type parameters a type has (string in case of List and (int, string) in case of KeyValuePair)? The Type class defines another interesting method called GetGenericArguments(), which returns an Array of Type objects. Combining this method with MakeGenericType will let us write the following code, which is used to build a KeyValuePair of Types, which are the switch from the original one by type parameter places (for KeyValuePair it will return KeyValuePair):

public object CreateInstnaceOfTheSameType(object original)
{
  if (original == null)
  {
    return null;
  }

  Type origType = original.GetType();
  if (!origType.IsGenericType || origType.GetGenericTypeDefinition() != typeof(KeyValuePair<,>)
  {
    throw new ArgumentException("KeyValuePairs expected");
  }

  Type[] typeArgs = origType.GetGenericArguments();
  Type typeToConstruct = origType.GetGenericTypeDefinition().MakeGenericType(new Type[] { typeArgs[1], typeArgs[0]});
  object[] constructorParams;
  // I'm skipping the code for constructorParams initialization, cause it's out of scope
  return Activator.CreateInstance(typeToConstruct, constructorParams);
}

Hope you will find this post helpful.

Regards...

Syncronization with lock() - bad habits

2012-02-18T23:22:00.001+00:00

Hi all.

Today I wanted to touch the lock statement in C#, and how many developers used to use it. There are a lot of books on C#, where authors bring examples like the following:

public class LibraryType
{
  public void X()
  {
    lock (this)
    {
      // some actions
    }
  }
}

I'd like to touch this because many developers are using the same technique of syncronizing access to a shared resource. There is nothing wrong in such a code, but there is a potential problem hidden in it.
What if somebody, who is going to use the library (which contains above written code) will decide to syncronize access to some shared resource using an instnace of a type, which contains above shown method X()?
In single threaded application there will be no problems at all, but in case of multithreaded applicaiton, the caller will face a deadlock. Take a look to the following code example:

// This code is in different assembly
internal class WrapperClass
{
  private LibraryType libTypeInstance = new LibraryType();

  private void XCaller()
  {
    lock(this.libTypeInstance)
    {
      Thread tmpThread = new Thread(new ThreadStart(()=>this.libTypeInstance.X()));
      tmpThread.Start();
      tmpThread.Join();
    }
  }
}

The thread which is calling the method XCaller() will lock the libTypeInstance object, and then will create another Thread inside, which will try to lock the same object instnace from the inner X() method. So that thread will wait untill the object is not unlocked, but for this to happen that thread should finish its job. So the application will halt here.
So the prefered technique in syncronization scenarios will be to keep a private instancec of an Object type and lock that instance, instead of locking the object (this). This will result in the following change in the code:

public class LibraryType
{
  private Object syncObject = new Object();

  public void X()
  {
    lock (this.syncObject)
    {
      // some actions
    }
  }
}

After the following change the above mentioned example will work with no problems.

Thanks for reading.

AppDomains - Why and How ?

2012-01-29T22:45:00.002+00:00

Finally I've found time for this post, which I was planning last year already.
So, where you may need an AppDomain in your application, how you'll treat it and what are the benefits of using it? I'll try to answer to those question. Read further.
Let's start from the theory: An Application Domain represents an isolated environment in a managed .net application process. Saying roughly those are sub-process layers, where the code will execute. The important features of Applicaiton Domains I'd like to mention here are the following:
1. An applicaiton domain has its own - isolated from others, memory
2. Those can be loaded and unloaded dynamically. Unloading an applicaiton domain will unload all the assemblies loaded in that applicaiton domain (there are still some cases when this is not true, although non-practical cases).
Now let's try to find a usage. Imagine a scenario, where the applicaiton needs to load a component from non-trusted source. There are several issues with this, and the most important for me are Security and Reliability.
Security: you never know what the code in that component is doing behind the scenes.
Reliability: the component can be non-well designed, leaving holes for exceptions to arise.
Let's first concentrate on the case, if we are going to handle such scenario without application domains. Of course for interaction with that third-party component there will be a well-defined interface, and every call of a method of that interface (actually an instnace of 3-rd party component, which I will call Component X further) will be wrapped in a try-catch block. But what if the component does something else behind the scenes ? For example it can has a background thread which does some other processing. In this case, your handlers won't be able to handle exceptions coming from that background processed code, because those are not on the stack of a thread you've just called a method in. So what will happen ? I won't go into details here, but will say that an exception coming out from such backgroun thread (which is not properly caught in Component X, will finally take your process down, and you'll have no chance to react, cause have no handlers at all.
Don't blame me here, cause I'm not going into some special cases here, like WinForms, where you can handle all the exceptions on the Application level by registering to ThreadException event.
On the reliability side - you don't know what the code is doing from data-accessing perspective. So there are limited choices for you to react here - limit your own application permissions to not allow the Component X to do something wrong. But still, you will share the same address space in memory with that component.
Ok, now let's jump to the usage of application domains for this scenario, and see how those will solve the above mentioned problems.
First, in FCL (Framework Class Library) there is a type called AppDomain, which is handling management and interaction with application domains. So let me from now on call application domains just AppDomain for the sake of simplicity only.
Well, the proper design for the above scenario will be the following:
1. Create an AppDomain



AppDomain tmpDomain = AppDomain.CreateDomain("ComponentX Domain");

2. Register for the UnhandledException event of that AppDomain



tmpDomain.UnhandledException += new UnhandledExceptionEventHandler(OnComponentDomain_UnhandledException);

3. Add proper permissions to that AppDomain (this is called sandboxing - limiting permissions)
// Leaving code for this section, because this is out of scope from this article
4. Load the Component X assembly into that AppDomain



Assembly tmpComponentAssembly = tmpDomain.Load(AssemblyName.GetAssemblyName("./ComponentX.dll"));

5. Create Component X instance in that AppDomain.
6. Create a proxy in our AppDomain to interact with Component X instance in the new-created domain(because the memory of each AppDomain is isolated, the process of passing data between AppDomain-s involves serialization and deserialization of that data, and whole the process is refered as Marshalling).



Type tmpComponentType = GetComponentTypeFromAssembly(tmpComponentAssembly, typeof(IComponentContract).Name);

IComponentContract tmpComponentProxy = tmpDomain.CreateInstanceAndUnwrap(tmpComponentAssembly.FullName, tmpComponentType.FullName) as IComponentContract;

7. After finishing working with Component X unload AppDomain of Component X to free up memory. This will also unload the assembly loaded in that AppDomain.



// This call is missing in the example solution attached to this article.

tmpDomain.Unload();

Great, this solves the security problem and what about the reliability? The AppDomain type (in Net Framework 4.0) defines an event called UnhandledException. Unfortunately there is no way to handle that exception and continue the normal flow of the application, but the good thing here is that you get your "last-chance" to save state, or log the exception, and even schedule a task in OS to start a new instance of your application. There are several important aspects you should be aware of regarding this event: "This event can be handled in any Applicaiton Domain, although its not necessarily raised in the application domain, where the exception occured. An exception is unhandled only if the entire stack for the thread has been unwound without finding an applicable exception handler, so the first place the event can be raised is in the application domain where the thread originated.
If the UnhandledException event is handled in the default application domain, it is raised there for any unhandled exception in any thread, no matter what application domain the thread started in. If the thread started in an application domain that has an event handler for UnhandledException, the event is raised in that application domain. If that application domain is not the default application domain, and there is also an event handler in the default application domain, the event is raised in both application domains." The quoted part I've taken from MSDN documentation cause it very well explains that event propogation. I still recommend you to read the MSDN page.
In the section above I've specified the exact version of Net Framework because in the earlier versions the behavior was slightly different. Here is another section from MSDN for earlier versions: "In the .NET Framework versions 1.0 and 1.1, an unhandled exception that occurs in a thread other than the main application thread is caught by the runtime and therefore does not cause the application to terminate. Thus, it is possible for the UnhandledException event to be raised without the application terminating. Starting with the .NET Framework version 2.0, this backstop for unhandled exceptions in child threads was removed, because the cumulative effect of such silent failures included performance degradation, corrupted data, and lockups, all of which were difficult to debug."
I've also created a small solution with code representing the scenario described in this article. Click here to download the example codes.

Comparing IPAddress-es

2012-01-27T15:56:00.002+00:00

Recently I was struggling with a LINQ expression, where I had a comparison of two ip addresses. Like used to - the comparison was done by the == operator, which was the cause of the headache.
NEVER USE == WITH IPAddress.
Seems IPAddress have no its own overrie for ==, and because it's a reference type that operator is just comparing two addresses(whether those point to the same location in memory or not). And I was getting false for equal ip address comparison.
You can just try to do the following:



    bool areEqual = IPAddress.Parse("150.148.1.54") == IPAddress.Parse("150.148.1.54");

    // the areEqual now is false

So the proper way to compare them is to use the Equals method, which IPAddress type has an override for:



    bool areEqual = IPAddress.Parse("150.148.1.54").Equals(IPAddress.Parse("150.148.1.54"));

    // and now the areEqual will be true

Good luck with your coding.

ASP.Net: Application Pools, Application Domains and/or processes

2011-11-21T08:42:00.001+00:00

Hi all.

Today I just wanted to bring some light on the way ASP.Net handles requests. So let's start from scratch.

What is ASP.Net itself from OS perspective ?
ASP.Net is just a process called aspnet_wp.exe. How in that case it's stable against application crashes - read further.

In the last question we've mentioned something called Application.What is that ? Ok, Application is an atomic unit of the ASP.Net process - it's the type of the objects, which are responsible for processing client requests. But there is a good and important trick here, which ASP.Net process takes care of - the Application Domains. In fact, for each application (which is represented by a vritual directory in IIS) ASP.Net creates a separate AppDomain, and everything related to specific application happens in the boundaries of that domain. This makes one Application be resistant against others' crashes.
So for each request coming from the client, ASP.Net "creates" (I will cover this a bit later) a separate Application type instance (Application object) to handle that request. Why I've quoted the creates word, is because that's not the case and there is a nice optimization done under the hood: as soon as the application being started (AppDomain for that application being created), ASP.Net creates a pool of up to 100 instances of Application classes to not spend time on heavy object-creation operation on each request. So, finally, what we get, is that for each request a "random" existing Application instance processes that request.
This brings us to one important point: Never keep state in Application instance, or even if you need to take into account the fact that the instnace you've written some state to most probably will be chosen to process request from other clients as well.
All this is great, but seems we're missing something: where do the Application Pools stand in whole this architecture ? Ok, time to change your understanding about Application Pools, because those are just number of settings, which can be applied to different applications. Applicaiton Pools are just a conveniet way to group important settings alltogether and then be able to apply them to any application you'd like to.

I think this is all for this post.
Good luck in your development.

Better Work Environment: Bigger Screens

2011-11-02T21:43:00.000+00:00

It's almost 5 years I used to work on two monitors, and now sometimes feel the need of the third one. Yes, it's very handy to work on several, but there is a drawback as well: you get used to it and its getting harder and harder to work on a single one at home.
Today, I had to spent some time on my WP7 game (which is in the Marketplace from february), and suddenly thought about moving from 22" Samsung (monitor) to 32" Samsung (TV). And you know what - that's amazing - clear picture, wide area to work and you can see every long line of your code (I'm not fan of splitting lines by enters).