Skip to content

2012 in review


The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

The new Boeing 787 Dreamliner can carry about 250 passengers. This blog was viewed about 1,000 times in 2012. If it were a Dreamliner, it would take about 4 trips to carry that many people.

Click here to see the complete report.

0041: New commit (rev. 72)


Hi all,

I’d like to inform that new code commit (revision 72) has just arrived :)
You can browse the code here.

This version has many changes, as I haven’t commited code for a long time. Most important is (I think so), that I’ve added classes responsible for creating large test database.
The database contains above 50k records (books only) with almost all fields filled up (even with covers, which are not really covers but just random images :)). Working with
such a big data bank is difficult and challenging, so I think that in the near future I will try to define, locate and fix performance issues.

If someone would like to get familiar with the new code, feel free – in case of any questions I will be glad to answer.
Best regards,
Paweł

0040: Plan for the next few weeks


Hi future Paweł!

This note is a kind of letter to the future me and all my minions :)
I worked out a plan of new features and procedures that should be implemented. Don’t proceed further before you take care of stuff listed below.

Before check in current changes:

  1. Correct/complete comments for the classes/methods.
  2. Create new tab in the Main Menu – Test Tools.
  3. Put CollectionManager/Create Settings File/Create Huge Test Db into TestTools tab.

After code’s checked in:

  1. Check all TODOs and fix/remove them.
  2. Take care of the performance related with huge database.
  3. Check the code with FX Cop.
  4. Take care of proper branching in the SVN. I think that we should create new branch – “developer’s branch” and do check ins on it only. Main branch should exist parallelly and be updated only when some important, stable functionality is added.
  5. All strings must be moved to resources!

New procedures to be considered:

  1. Comments to the procedure/class should be added right after item was created.
  2. All TODOs should be fixed/removed before check in.
  3. Before every check in all strings must be moved to resources.
  4. Before every check in unused/commented code must be removed.
  5. Some kind of “road map” should be created(?)

When something will dawn on me, I will certainly update this post.
Best regards
old Paweł

0037: ProgressManager using Observer (and Composite) pattern


-Hi, everybody!
-Hi dr. Nick :)

Some time ago I changed my work team and I moved under Andrzej’s wings:) It was a good change, because since I started work with C# I’ve learned quite much about technical aspects of programming, but not so much about designing of the applications. Of course, during my career I designed and implemented
few applications, but they were rather small – nothing as spectacular as, for example, OLGAtherer :) Joke of course. Anyway, this change let me start to learn from, in my opinion,
very skillful analytic/designer that all the time teaches me new approach to the coding (I removed rest of the sentences that glorified Andrzej).

So, today I’d like to tell about ProgressManager which I found in the application that I work with (I’m a support developer that helps Andrzej to maintain and develop quite large application).
ProgressManager has a form of class with static methods. This class is visible for all parts of the application. When some process start, this has to be done:

  1. Start Process
  2. Create new instance of ProgressManager Window (form)
  3. Set it up
  4. Proceed with computations in background worker
  5. During processing, usually in “foreach” loops, invoke ProgressManger static method that updates previously shown window with progress data.
  6. If Cancel button has been pressed, process won’t stop until it goes back to the specific point (technical restrictions that weren’t overcome, but left as they were)

Above tells us, that this solution sucks. So Andrzej proposed that we should change this:

  1. First stage consists of about one day of checking application, it’s coupling, connections, and so on
  2. After this excessive searching we were able to determine how the process works now (I know, this situation may look unbelieveable, but this happens when there is no planning at the beginning and strange persons develop code…)
  3. In the third stage I had to clean and reorganize the code (background workers mostly), that it would be able to get major changes
  4. Fourth stage will be described in details below. In short, here we had to design new Progress Manager. We did it successfully.
  5. Then I had to implement it in exemplary project and test it in dummy process.
  6. When we were ready to proceed to the next stage, our manager told us to stop. LOL – this is probably the main problem in our work – crappy manager :)))) All the work for nothing:)

OK, this beginning was definitely too long. Now I will tell you about our new ProgressManager.

New ProgressManager is based on Observer pattern. In short, this pattern consists of Observer(s) that observes objects :) Objects know that there is observer (or observers) and when something important happens, they notifies observers about it. To implement it, we had to create new interface: IObserver:

///<summary> 
/// Implemented by class that will observe IObservable object(s).
/// </summary>
public interface IObserver
{
   ///<summary>
   /// Invoked by IObservable, notifies the observer about change of its state.
   /// </summary>
   void Update(IObservable sender, StageState state);
}

This interface contains only one method. This method accepts StageStage object that contains progress data and instance of sender. The instance isn’t necessary in all cases, but we will use it in the Manager.
Now IObservable:

///<summary> 
/// Implemented by class which state will be observable by one or more observers.
/// </summary>
public interface IObservable
{
   ///<summary>
   /// Adds Observer.
   /// </summary>
   void RegisterClient(IObserver client);

   ///<summary>
   /// Removes Observer.
   /// </summary>
   void UnregisterClient(IObserver client);

   ///<summary>
   /// Notifies all observers.
   /// </summary>
   void UpdateClients();

   ///<summary> 
   /// Stops work.
   /// </summary>
   void Stop();

   ///<summary>
   /// Informs about the object's speed.
   /// </summary>
   ClassSpeed Speed { get; }
}

As you can see, every observable object must implement the IObservable. This interface contains two method to add/remove observers, one method to notify clients (observers) and one property that I
very like – ClassSpeed enumeration looks like this:

///<summary>
/// Defines speed that object works with. Maximum value equals 100.
/// </summary>
public enum ClassSpeed
{
   VeryFast = 20,
   Fast = 40,
   Normal = 60,
   Slow = 80,
   VerySlow = 100,
}

It describes how fast is the process relatively. This will allow us to make progress bar changing not with the same speed – I will describe this later.

OK, now the ProgressManager class:

///<summary> 
/// Represents stage of the process or set of the stages, and notifies Observer(s) when the state is being changed.
/// </summary>
public class ProgressManager : IObserver, IObservable
{
#region Data

///<summary> 
/// Observed subprocesses. Generic list of IObservable.
/// </summary>
private List m_ObservedStages = new List();

///<summary> 
/// Registered Observers. Generic list of IObserver.
/// </summary>
private List m_RegisteredListeners = new List();

///<summary> 
/// List of doubles that describes estimated distibution of the times necessary to do the whole job.
/// First item on this list matches with first item on the m_ObservedStages list and indicates how long this stage could be.
/// </summary>
private List m_PercentageDistribution = new List();

///<summary> 
/// Last stage sent to the clients.
/// </summary>
private StageState m_StageState;

///<summary> 
/// Name of the process described by this Manager.
/// </summary>
private string m_ProcessName = string.Empty;

///<summary> 
/// Currently running stage.
/// </summary>
private IObservable m_CurrentObservable;

///
<summary> /// Estimated speed of this Process.
/// </summary>

public ClassSpeed Speed
{
   get{
       double speed = 0;
       m_ObservedStages.ForEach(x =&gt; speed += (int)x.Speed);
       speed /= (m_ObservedStages.Count * 20);
       speed = Math.Round(speed, 0, MidpointRounding.AwayFromZero | MidpointRounding.ToEven);
       return (ClassSpeed)(speed * 20);
       }
}

#endregion Data

#region Ctor

///<summary> 
/// Standard Ctor.
/// </summary>
public ProgressManager(string processName, List stagesToObserve)
{
   m_ProcessName = processName;
   m_ObservedStages = stagesToObserve;
   Subscribe();
   ComputePercentageDistribution();
}

///<summary> 
/// If this Ctor is used, user should ensure that ConfigureManager method will be invoked before Process starts.
/// </summary>
public ProgressManager()
{
}

#endregion Ctor

#region Methods

#region IObservable Members

///<summary> 
/// Adds Observer.
/// </summary>
public void RegisterClient(IObserver client)
{
   m_RegisteredListeners.Add(client);
}

///<summary> 
/// Removes Observer.
/// </summary>
public void UnregisterClient(IObserver client)
{
   m_RegisteredListeners.Remove(client);
}

///<summary> 
/// Notifies all observers.
/// </summary>
public void UpdateClients()
{
   foreach (IObserver client in m_RegisteredListeners)
      client.Update(this, m_StageState);
}

///<summary> 
/// Stops work.
/// </summary>
public void Stop()
{
   m_CurrentObservable.Stop();
}

#endregion IObservable Members

#region IObserver Members

///<summary> 
/// Invoked by IObservable, notifies the observer about change of its state.
/// </summary>
public void Update(IObservable sender, StageState state)
{
   m_CurrentObservable = sender;
   m_StageState = ProcessState(sender, state);
   UpdateClients();
}

#endregion IObserver Members

///<summary> 
/// Configures Manager before Process starts.
/// </summary>
public void ConfigureManager(string processName, List stagesToObserve)
{
   m_ProcessName = processName;
   m_ObservedStages = stagesToObserve;
   Subscribe();
   ComputePercentageDistribution();
}

///<summary> 
/// Registers this Observer to the stages.
/// </summary>
private void Subscribe()
{
   foreach (IObservable stage in m_ObservedStages)
      stage.RegisterClient(this);
}

///<summary> 
/// Computes time that stages will take.
/// </summary>
private void ComputePercentageDistribution()
{
   int totalSpeed = 0;
   m_ObservedStages.ForEach(x =&gt; totalSpeed += (int)x.Speed);
   m_ObservedStages.ForEach(x =&gt; m_PercentageDistribution.Add((int)x.Speed * (double)100 / totalSpeed));
}

///<summary> 
/// Processes state received from Observable and modifies it to the form that will be send to Observers.
/// </summary>
private StageState ProcessState(IObservable sender, StageState state)
{
   int percendageDone = ComputePercentageDone(sender, state);
   StageState newState = new StageState(m_ProcessName, new List()
   {
      new ProgressBarStatus(state.ProcessName, percendageDone, m_ObservedStages.IndexOf(sender), m_ObservedStages.Count),
      state.MainProgressBar,
      state.SecondaryProgressBar
    });
   return newState;
}

///<summary> 
/// Computes overall percentage of the process.
/// </summary>
private int ComputePercentageDone(IObservable sender, StageState state)
{
   int senderIndex = m_ObservedStages.IndexOf(sender);
   double percentage = 0;
   for (int i = 0; i &lt; senderIndex; i++) { percentage += m_PercentageDistribution[i]; } if(state.MainProgressBar.PercentageDone != 0) percentage += (m_PercentageDistribution[senderIndex] *      state.MainProgressBar.PercentageDone / 100); return percentage &gt; 100 ? 100 : (int)percentage;
}

#endregion Methods

HUH. Large piece of code.
First of all you can see that ProgressManager implements IObserver AND IObservable. First we wanted to make him only an Observer, but then we thought that we could imagine situation like this:

(When I created the picture above Andrzej realized me that ProgressManager is rather wrong name. This class should be rather called ProcessManager. Why? Please rotate image above for 90 degrees right. Do you see it? This structure doesn’t only utilizes Observer pattern. There is also Composite that I described here – please notice that drawing here is very similar to the color graphic attached to that post.)

What is also nice here, that the manager is quite “smart”. Depending on observed objects’ speed, it calculates percentage that one subprocess should take. So if we have, for example two subprocesses that are very fast (ClassSpeed = 20) and one subprocess very slow (ClassSpeed = 100), then three subprocesses will take 140 units, and first one will take 20/140 of the overall time, second one the same, and last one will take 100/140 (about 70 percent) of the overall process time. So this would be silly to split progress bar for three parts of the same length – instead of that, ProgressManager will compute percentage distribution and will take care of proper updating of progress bar.

OK, so we have process, subprocesses and ProgressManager(s). How ProgressManager reports to the user? This should be obvious :) We create new form:

public partial class ProgressManagerView : Form, IObserver

Smart, isn’t it? :) Our endpoint is Observer too. It subscribes to the progress manager (only one at the time!), and its main method is:

///<summary>
/// Receives state from observed object and fills controls with its properties.
/// </summary>
public void Update(IObservable sender, StageState state)
{
   SetProgressBarValue(progBarMain, state.MainProgressBar.PercentageDone);
   SetProgressBarValue(progBarSecond, state.SecondaryProgressBar.PercentageDone);
   SetProgressBarValue(progBarThird, state.ThirdProgressBar.PercentageDone);

   SetLabelText(lblCurrentFileName, state.ThirdProgressBar.Title);
   SetLabelText(lblCurrentStageName, state.SecondaryProgressBar.Title);
   SetLabelText(lblProcessName, state.ProcessName);
}

Reading method above you can see that form consists of three progress bars and three labels that are updated not straightforward but via helper methods. Exemplary code of one of these methods:

///<summary> 
/// Helper method preventing from CrossThreadExceptions.
/// Sets label's text.
/// </summary>
private void SetLabelText(Label label, string text)
{
   if (label.InvokeRequired)
   {
      LabelDelegate = new SetTextDelegate(SetLabelText);
      this.Invoke(LabelDelegate, label, text);
   }
   else
      label.Text = text;
}

As you can see, we have to check whether desired control requires to be invoked. If so, we attach this method to delegate and call Invoke method on the form. This technique prevents from exception CrossThreadExceptions when one thread tries to access control created in the other thread. This is described in details here.
Picture below shows endpoint form:

As you can see, there are three changeable labels and three progress bars. Top bar/label describes currently processed file (package), middle bar/label is responsible for displaying
progress of the subprocess, and lower bar/label shows total progress of the whole process. Of course, we can show/hide these components as we want.

This should be all. ProgressManager (ProcessManager?) is almost finished. You’re free to use it (in case of getting this code over, please notice receiver that it was downloaded from this site) – you can download solution here. In case of any questions, feel free to ask.
Best regards
Paweł

0036: Interfaces: how and when.


Hi,

I’ve been doing programmer work for about 2.5 years. When I was starting I hardly understood concepts of classes and methods – let’s say: objective programming. So I started to learn – I was reading books, portals, blogs, and almost
everything that might help me to become better programmer (or just programmer :)) Now, when I can look back on my long hard road out of no-programmer-hell :) I can tell that most troublesome and hard to understand thing was conception
of the Interface. When I discuss with younger programmers I see that they don’t understand it well too.
I’d like to, in short post, try to explain general idea of what interface is and how it can be used.

As we know, “An interface contains only the signatures of methods, delegates or events. The implementation of the methods is done in the class that implements the interface”.

OK, one can say, so interface is a crippled abstract class that cannot contain method bodies? Yes, if we want to look from this point. Interface only defines what the class does, not how it handles it.

In C++, as there inheritance from multiple base classes is allowed, one can use abstract classes (classes with methods declared, but not implemented) to emulate interface. In C# and other more objective languages (I know that C++ zealots
will try to crucify me) class can inherit only from one base class, BUT it can IMPLEMENT (not inherit) many interfaces. So, for example, we can have something like in OLGAtherer:

public class Book : IEntity, IPrintable, INotifyPropertyChanged

Assume that IPrintable contains only one method: void Print(), and we have entities like: Book, Comic, Ebook, Journal that implement IPrintable, but don’t inherit from common base class. We add button Print in our UI and attach it to the method:

void Print(object itemToPrint)

How would body of this method look if our classes wouldn’t implement IPrintable?

{
	if(itemToPrint is Book)
		(itemToPrint as Book).Print();
	else if(itemToPrint is Comic)
		(itemToPrint as Comic).Print();
	.
	.
	.
	.
	else
		.....		
	
	
}

Here you can read why switch statement isn’t implemented in .NET.

What, when interface comes to play?

void Print(IPrintable itemToPrint)
{
	itemToPrint.Print();
}

Surprise, surprise :)
Interface defines contract that given object is able to fulfill. Client is sure that when he works with object that implements specific interface, he can demand specific actions from him. He doesn’t care HOW the actions will be done.
He only knows that they WILL be done.

So, two main (in my opinion) purposes of using interfaces:

  • One class is able to implement many interfaces (instead of inherit from only one base class)
  • Different kind of classes not connected by inheritance may be treated in one way

Today we’ve just finished – I wrote this short and incomplete notice (interfaces have many hidden “catches”) only to make a background to further posts that will describe design patterns. These posts will also extend this one, because
will show in examples how the interfaces are used in production. You can also check my previous posts that describe techniques based on interface usage

Best regards,
Paweł

0035: Composite Pattern in CollectionManager


Hi,

In the last entry I mentioned that I’d managed to implement CollectionManager. This is a additional module that for now allows only browsing through the collections, but
in the future I will try to enhance it to full manager that will allow browsing, deleting, merging, copying and moving elements on different abstraction levels. What does it mean?

Let me explain:

Data structure in OLGAtherer consists of folder that consists of databases that consist of repositories that consist of entities :) As you can see, there is at least four
levels that I call “abstraction level”. In the inner application structures, all four levels are represent by classes/objects: DBContainer (folder(s)), DB (databases), EntityCollection
and IEntity interface that is implemented by any collection collection item (Book, Comic, Wine, etc.).

All of them differ in any detail, but we want to treat them in one, consistent way. And here comes the Composite pattern :) What is it?

I don’t want to provide detail description of whole pattern, because English isn’t my native language – here we can read about it: http://www.dofactory.com/Patterns/PatternComposite.aspx :)

In short, we can create common interface that will be implemented by all classes in the structure tree (three classes and one interface mentioned above). I’d like to show you how I did it.

In the beginning, I thought about actions that composite may take. As I said, I’d like it to be copied, moved, deleted, listed and so on – so I created interface IManagedComposite that contained method
signatures such as DeleteChild(IManagedComposite child),…, List GetChildren() and property bool HasChildren.

When I tried to implement it, I found it quite difficult and painful, due to lack of detailed plan – how the manager has to be like. This issue (tough implementation process) is widely described
in books about Objective Programming. They states that programmer shouldn’t write excessive code for the future, possible use, but rather write less code that is needed right now.
This was my situation – I started to think about it once again and figured out that I need only methods that will allow user to list the composites in one, consistent way.
Now the job started to be easy and fun. Look at the interface:

public interface IManagedComposite
{
    Dictionary GetChildren();
    string Name { get; }
    bool HasChildren { get; }
}

This is sensible – we want composite item to identify itself by giving name, and to provide us with its children. Name is sufficient to find the composite at the certain level, so
we will be able to find the desired object and change it in the future (when new actions will be needed). So, next I had to implement interface in 3 classes. Property HasChildren
is trivial ({return this.children.Count != 0;}), but I will show you an implementation of the other members in different classes:

DBContainer class that represents folder containing database files:

public Dictionary GetChildren()
{
    //collect children only if the dictionary is empty. This is a performance fix.
    if (this.children.Count == 0)
       foreach (string fileName in Directory.GetFiles(this.folderPath))  //go through all db files in the directory and collect their names
       {
          IManagedComposite db = new DB(fileName);
          if ((db as DB).IsValidDb)
             this.children.Add(db.Name, db);
       }

    return this.children;
}

public string Name
{
    get { return Path.GetDirectoryName(this.folderPath); } //returns directory name
}

DB class that represents one database:

public Dictionary GetChildren()
{
    if (this.children.Count == 0)
       foreach (CollectionData value in GetCollectionDataCollection().Read()) //go through all collections in database
       {
           this.children.Add(value.FriendlyCollectionName, GetBookCollection(value.IdNo));
       }

    return this.children;
}

public string Name
{
    get { return this.name; } //returns DB name
}

EntityCollection:

public Dictionary GetChildren()
{
   if (this.children.Count == 0)
      foreach (T item in this.items)  //go through all entities in the collection
         this.children.Add(item.ToString(), item);

   return this.children;
}

public string Name
{
    get { return this.friendlyName; }  //this is potential issue
}

And IEntity that inherits from IManagedComposite now, so for example, class Book : IEntity implements IManagedComposite in the same time:

public Dictionary GetChildren()
{
    return null; //no children
}

public string Name
{
    get { return this.ToString(); } //overriden ToString() method.
}

As you can see, every one class implements the GetChildren() method in different way. From listing files, through reading from inside of DB, to return null in case of leaves (entities have no children).
One can see in the code above at least one potential issue – returning friendlyName by EntityCollection can cause problems, because this name isn’t unique at the Collection level. But I see this
possibility and will try to fix it.
Anyway, how can we now list all of the composites? Very easy:

I needed to create form with two ListBoxes – lbxLeft and lbxRight. I’ve created CustomControl called CompositeListBox that aggregates ListBox and Stack that stores currently processed
composite. Then, only one method is actually relevant:

private void DisplayCompositesOnList()
{
	//Get children from currentComposite (displayedComposite field)
   Dictionary displayedCompositeGetChildren = this.displayedComposite.GetChildren();
   if (displayedCompositeGetChildren == null)
      return;

	//Clear items from listbox
   this.lbxMain.Items.Clear();
   //Add ... in the first line
   this.lbxMain.Items.Add(Return_Symbol);
   //Fill rest of the lines with childrens' names
   foreach (KeyValuePair displayedComposite in displayedCompositeGetChildren)
      this.lbxMain.Items.Add(displayedComposite.Key);
}

When we want to go deeper into the structure, just doubleclick on desired component. Then selected item becomes currentComposite, and is being put on the stack.
When we want to go back, just pop item from the stack… Nice and easy :)

In the future, any changes would be easy due to this approach – it’s another time when design patterns appeared to be very handy and worth to use. Composite pattern
handles the issue with easiness and lets me modify all different components in common way, so I think that implementing copy/move functionality will require adding two
methods to the interface, and implementing them in the classes. Objective architecture of the Model library assures that this won’t take too long time and effort. Hopefully.
:)

I know that this entry may be quite difficult to read, but I hope that you’ve made it and you found this article helpful in any way…
Best regards
Paweł

0034: Quick announce


Hi again,

Recently I worked on the OLGAtherer Collection Manager for .Net :) project for a while and I found few things very interesting.
One of them is SQLite DB size, second – Composite pattern, third – Observer pattern (I came across latter problem during my regular work, and Andrzej helped me out with this).
I have no time (as always), but I will try to write few short articles about problems described above. I will start with Composite, then proceed to Observer and, at last, to SQLite size (because I haven’t explored this issue yet deep enough to tell something about it).
I hope you will find it helpful/interesting.

I read one interesting book too, maybe I will find some time to tell about it.

0033: CollectionManager reached new level.


Yellou!

I know that since last year I don’t write much. Almost nothing, to be honest. This depends on my workload, that is pretty hi. Additionally we’ve bought an apartment and we have to decorate it. Last, but not least, my little daughter, Olga, is constantly growing up and requires more and more time. It’s rather obvious that I prefer to play with her than working on this application :)

But fear not :) Even though this site is quite and cold, OLGAtherer is not. I’ve just finished first stage of the CollectionManager that would be an application module similar to Total Commander and will allow user to managing collection in simple manner.

I think that now I will upgrade class responsible for test DBs creation and put new version of the OLGAtherer on the Sourceforge. So please be patient and check this site from time to time.

Best regards,
Paweł

0032: New release of OLGAtherer


Hello

Today I sent new version of OLGAtherer to the SourceForge.net server. You can download it here.
Previous release has been downloaded about 50 times and unfortunately I have obtained no feedback. This version is provided with more features and is better overall. Of course it has also more bugs…

Please download new archive, read readme.txt file and, if you would be so kind, give me feedback/suggestions that would help me to develop the OLGAtherer.

Best regards

Paweł

0031: Still alive


Greetings

This short note’s only purpose is to inform you that OLGAtherer is still alive – people who played Portal knows what I am talking about :) New functionality is being added even right now so in measurable time you should be able to download new test version of the application :)

Enjoy!

Follow

Get every new post delivered to your Inbox.