GetNoticed DEV#10: Updates in demo

Good evening!
Although the demo was presented in my previous post I have updated it slightly: I added a progress dialog. This is to report how many items have been processed and how many of them is yet to be processed. The progress dialog also ensures the user that the program isn’t hanging without checking that in Windows task manager. Links to source code and installer below. And here’s quick video to demonstrate that:


Future of SheetMetalArranger
This project was developed for purposes of GetNoticed contest. At this moment I can’t say if I’m going to do anything more with it. Maybe I will, maybe I won’t. But if I do here’s what could be added/improved:

  •  efficiency: this is the most important factor to asses this program. In on of my previous DEV posts I wrote that 82% is good enough. And for the purpose of the contest it is enough, but if Arranger is to really serve its purpose it needs to be more efficient. It could be achiever by improving merging. Now only boxes which are the same width or the same height and are adjacent on equal edge are merger.
  • project files: it would be useful if arrangements could be saved and reopened later, JSON or XML would do the job
  • export: the demo just demonstrates calculated arrangement in its UI, it also saves generated PNGs in ProgramData folder on C:/ drive. But it would be much useful if a user could click a button and save them in required location. Also export to DXF would be handy and brief look at DXF standard allows me to think that it is achievable.

GetNoticed – my conclusion
As this is my last post for the contest I allow myself to write few words of conclusion. First and foremost the contest was a great boost of motivation. For me personally this is the biggest advantage. I am aware that my project isn’t the best, maybe it’s not even good. But keep in mind that I am still a newbie but I’m excited about the path that’s in front of me.
Thanks for everyone who read even one of my post.

Regards, Michal

SheetMetalArranger on GitHub
ClickOnce installer

GetNoticed IT#10: Factory method

Good evening!
Post number TEN in my GetNoticed IT series! In my DEV#8 post I mentioned that most likely my next IT post will be about tabs in WPF/MVVM but as you’ve probably figured it out it won’t be about tabs. It’s going to be about factory method design pattern.
So, factory method allows to encapsulate object creation. For instance, you can bring all logic that decides which object to create into one class. Or another example. In my project I used some singletons (which is considered to be an anti-pattern). This could have been avoided by using factory method (and it will be). In this case wherever I wanted to use an instance of singleton I would call factory method that returns object of my singleton instead of static property Instance.

How it works
Basic construction of that pattern is that you create abstractions of your factory class and of your – call it – product. Then you can create multiple different factories that return concrete product. Depending on what logic you will include in your concrete factory. Once you have that concrete factory you inject that into your class and let your class use that factory to instantiate concrete objects. It is very well explained by Christopher Okhravi in his just recently posted video. I highly recommend his videos.

I prepared quick example for the purpose of this post. There are books and bookstore:

Pretty simple: book described by two properties and a method to display details; and a bookstore with a collection of books and a method to list all books in that collection.
Now, our books can be paper, ebooks or audiobooks:

All of the above can be stored in our bookstore. And we want to decide which one to create at run time. So, let’s introduce a factory. We’ll start with abstraction and then concrete factories for each type of book. Our factory will have only one method that returns an object which is abstracted by IBook interface:

Now, we need to update our BookStore class and equip it with factory property and allow a factory to be injected in the constructor.

What more you can notice in the code above Factory property is public therefore you can swap factories anytime you want.
And here’s how you can do that:

When an instance of BookStore is created in gets default factory injected through the constructor and then every time a book is about to be created the factory is replaced by another factory. The output of the above would be:

Notice that each book is of different type depending on which factory has been used to create the object.
So, that’s the basic use of factory method. To dig deeper I recommend the links below:

I hope that this post (as the rest of my IT posts) is in any way useful for you. That is my last post IT series post for Get Noticed contest. But I will continue blogging and reporting my learning progress so if you’ve been hoping for that post about tabs please come back later. You’ll get it, promise!
Thanks, Michal

GetNoticed DEV#9: Demo is alive!

Good evening!
Demo application is alive! Here’s quick video of how it operates:

You can set your own items or click button to randomly create 10 items. Panels can be defined by user or you may allow the application to create unlimited number of panels with size set by user. So feel free to test it.
Next step would be to refactor the code. It is nasty, nasty I say. I will probably continue to develop the project after the contest is finished so the code will get cleaner. I don’t know if the app will get any bigger but for me it will be finished when I am not ashamed to show off with the code 🙂
Thanks for today, check the links below and good luck!

SheetMetalArranger on GitHub
Zip file with ClickOnce installer


GetNoticed DEV#8: Demo app mockup

Good evening!
Just to let you know that the project isn’t dead. As planned I’m trying to prepare a working demo of my app. I’ve been working on it since last weekend and I’m at the stage where I can present how the application will look:

Of course the mock-up is not all that I have achieved so far. All panels are fully working and backed up by view model. The most time consuming for me was to figure out how to work DataGrids and make tabs to be stored in a collection inside view model (maybe my next IT post will be about it). Now I need to make the view model communicate with ArrangerLibrary which will be my model. I will also need to add a class to ArrangerLibrary which will be responsible for generating PNGs. After that is done, code of the demo app will need to be cleaned and reorganised a bit for clarity.
It’s short and quick today but consider it as a far far away beacon that gives me hope that the goal is achievable.
Thanks, Michal

Nice tutorial how to work with tab control:
SheetMetalArranger on GitHub

GetNoticed IT#9: User control with data grid and observable collection

Good morning!
It’s been 10 days since my last post so the time is high! Today I’m going to write how to bind an observable collection of custom objects to a data grid in a WPF user control. Some time ago I wrote a post about basic use of user controls (see here) so this post you are reading right now can be considered as extension of the first one.

Objects in collection
Let’s start with preparing a class which objects will be stored in our collection. I won’t look for anything bright, I will just use something for my project: the class will store information about rectangles: height, width, margin and if a rectangle can be rotated. Additionally the class will have a property that returns area of a rectangle.

That’s the basic implementation of our ListedItem class. Now, to use it with observable collection in a way that it is bound to datagrid in UI and all values are automatically refreshed it is necessary to implement INotifyPropertyChanged. At the same time it would be wise to tweak our class a little bit: properties Height and Width cannot be smaller than 1. Also, when implementing INotifyPropertyChanged it is necessary to notify about Area property changed when any of Height or Width changes.

The last step would be to add a parameterless constructor that assigns all properties with default values.

View model
Our observable collection will be stored in our view model.

In the constructor of MainViewModel class we initialize the collection and add first item. And that’s for the purpose of this post is sufficient.

User control
Out user control will consist only of data grid inside a group box therefore the XAML is very simple.

What’s important in the code above are two things marked above: 1) assigning name to the user control (“this”), 2) defining data grid and its binding to dependency property Source.
Now, let’s move on to the code-behind the user control where we define dependency property.

We need to set the property of type ObservableCollection<ListedItem>, owner type ItemsList (as the name of our user control class) and name Source.

Now the last thing: combining all together in view. First of all we need to add namespace that contains our user control to namespaces used by the UI, create an instance of view model that is going to be used be the UI and set it as data context of top level grid.

To add our user control to the UI and bind observable collection for view model:

In this case binding mode is set as TwoWay because I want changes made by user in data grid to be reflected in collection in view model. But you have complete freedom here, that depends only on your needs.

So, basically that’s it. Before I finish few notes about customising the data grid.

The implementation above will generate columns in data grid according to properties exposed by elements in collection. But that is not the only way. you can set up your own names, for instance when you’re building multi-language app. To do that you need first set AutoGenerateColumns property of your data grid to false, and second define the columns manually. In our case that would be:

Note, that you need to be careful to use correct column type and to set binding correctly. In our case Area property is generated automatically therefore user must not be able to put anything in that column. To achieve that I had to set binding mode for this column to OneWay.

User edits
Depending on particular needs you may want to disable editing your data grid. There are certain properties that allows you to customise access to your data grid. To disable any edits you must set IsReadOnly to true, to make more precise customisation you can use set of CanUser properties which are pretty self-explanatory so there’s no point in describing them here.

Thanks for today, I hope that it’s gonna be somehow useful for you.
Regards, Michal



GetNoticed DEV#7: 82% Not bad…

Hi there!
As promised in my previous dev post: I have performed series of test how efficient the algorithm is and the results are satisfactory – average of 82% utilisation.

To measure the efficiency I ran 10 iterations of randomly generated set of rectangles. The size of the panel was fixed to 1500×3000 as this is standard size of sheet and most commonly used – at least that is my experience. Exact size of items was generated randomly, however there were some constraints to make the test more life-like. The list below illustrates that:

  • 15 items of size 50 to 60% panel size
  • 20 items of size 30 to 40% panel size
  • 30 items of size 20 to 30% panel size
  • 50 items of size 5 to 20% panel size

The number of panels was limited to 10 – this is to avoid having last panel filled only in quarter or half; the test is to check how densely the algorithm can pack items. In real application it is common to that the last panel is used only in fraction.

To perform the test I used xUnit. I wrote a unit test which doesn’t assert anything, just print the output string.

As written at the very beginning the average utilisation is around 82%. I find that value satisfactory. Here’s quick extract from the report with most important figures:
Overall average utilisation: 0.8226
Overall max utilisation: 0.838
Overall min utilisation: 0.807
Single panel max utilisation: 0.911
Single panel min utilisation: 0.694

The algorithm performs sufficiently well. At this point I won’t look for further improvements.

Thanks, Michal

Report in xlsx
SheetMetalArranger on GitHub


GetNoticed IT#8: Singleton

Hello there!
The infamous singleton – a pattern and an anti-pattern. Despite it’s bad reputation I decided to use it in my project for GetNoticed contest. I explained it why in one of my posts: my singletons consist of methods only and they’re sealed.

Thread safety
The most dubious concern in singletons is their thread safety. This can be fixed by using locks (examples here) or by including private and static constructors. Private constructor makes it impossible to create an instance of a singleton class anywhere in the code. Static constructor will be executed only once: when first instance of the class is created or when a static member of a class is referenced.

Whenever I need (and so far I have used them only once) a singleton I follow fourth template proposed by C# in depth. The template consist of private and static constructors, private static readonly instance field and public static property that gets instance.

Most sources I have encountered so far point out 4 main reasons to consider it as an anti-pattern.

  • accessible as a global instance and thus hiding dependencies
  • violation of SRP: singleton class is responsible for its business purpose and for its life cycle
  • tight coupling and weaker testability due to use of concrete singleton implementation
  • singleton carries its state as long as the program runs

These disadvantages are properly described (and discussed) by Scott Densmore and Johannes Rudolph. I recommend to read their posts.

To conclude I would say that I will be extremely careful next time I think about using singletons and will probably think of other solution for more complicated things than simple implementations of IComparer<T>.

Thanks, Michal


GetNoticed DEV#6: ArrangerLibrary seems to be completed

Let me start with one general conclusion after this weekend: in my case it’s better to have coding sessions rarely but for longer time rather that having short sessions more often. I have accomplished more in today’s afternoon and yesterday’s evening that in last two or three weeks. But that’s just my case, not saying that’s a general rule.
Having the above said, let’s get back to real business: the ArrangerLibrary seems to be more or less completed. Of course some additions are still required (for instance a class that would generate a PNG image for calculated arrangement) but it’s core functionality (which is to calculate best arrangement of items) is finished. I haven’t thoroughly tested it yet but I am hoping to do that next week. After that, the next step would be to build a quickie demo with UI. Unfortunately, the risk is high that I will not have finished full application before GetNoticed contest is ended.
In my previous post I wrote that merging of adjacent boxes in panel had been implemented. The most important thing in this update is that now the algorithm, while placing an item into a box, looks for all possible assignments and create a separate branch in results tree for each possible assignment. Having that done at the end the algorithm can return all possible arrangements or just one which is most effective. Maybe I will change that so a new branch is created only if there are two equally good placements (utilisation-wise). I need to do a bit of testing before I make final decision.
Another important update is that now it is possible to set a margin for every item and decide if an item can be rotated.

Here are screenshots of results of two test cases:
1) Panel size is 8 units high and 14 units wide2) Panel size is 1500 units high and 3000 units wide
As you can see results look acceptable but these test cannot be considered as reliable, next week I’ll try to conduct more test with inputs from real life (or at least more plausible) but I don’t expect the results to worsen or get significantly better. We’ll see…
Thanks, Michal

SheetMetalArranger on GitHub
Design sheet (*.xlsx)


GetNoticed DEV #5: Slowly but forward

Good evening!
Slowly, but still – the project is moving forward. I’ve been rewriting my DLL following the plan (or as modern politician would say – road map). And of course during the process the plan has been amended. Most changes are cosmetic, the biggest change is that I introduced a sub-class inside Panel class – its responsibility is merging boxes in the panel. It is highly possible that available space would become highly fragmented during the execution of the Guillotine algorithm and some of the free boxes could be merged. The below picture illustrates the most simple case.

This is what Merger class will do. It is a sub-class within Panel class because I don’t see any other place where it may be useful.

Another thing that is worth mentioning is presence of singleton classes. I am aware of the fact that it may be considered as an anti-pattern but here I use them deliberately. The reason for that is my singleton classes don’t have any fields or properties, only methods therefore I do not fear any loss of data, unwanted instances or inheritance. I tried to implement that in most simple and safest way possible. I will probably write a general post about advantages and disadvantages of singleton, but here and now is no time and place for this.
Cheers, Michal

SheetMetalArranger on GitHub
Design sheet (*.xlsx)


GetNoticed IT#7: S-O-L-Interface Segregation Principle-D

Hello there!
Today the last ‘episode’ of my SOLID series. The only only that is left for today is Interface Segregation Principle.

Clients should not be forced to depend upon interfaces that they do not use. [see here, page 5]

In practice, this means that implementing an interface should force a class to implement only those features that the class actually uses. Nice example is give by Piotr Zieliński here after But let me add a pinch of my own imagination here. Let’s think about workers. A worker is someone who does some work and gets paid for it.

Nice and clear. No problems. But we live in 21st century, a brave new world! We can use robots to do some work. But the problem is that a robot doesn’t need to get paid. So, you either throw an exception or leave implementation of this method blank. But that’s not a right approach.

Chris Klug even brought up an example of MembershipProvider (which is an abstract class not an interface to be precise, but that depicts a problem with complex interfaces in a pretty good way.) in where it was almost impossible to implement all features!

So, the  general rule is smaller but more rather than complex and few. Benefits we get from following that approach are multiple. First of all, if we break code to smaller pieces it is easier to get it, it keeps the code clean. Secondly, you don’t need to worry about something you don’t need, you don’t have to write empty methods or build properties your class will never ever use.
Let’s update and expand our example little bit to follow the principle. I’m going to split IWorker interface into three separate interfaces: ICanWork, IHuman, and IRobot. Additionaly IRobot will get PowerConsumption property.

That seems to be written better than the initial code, doesn’t it? But now, our factory needs to keep track of how a robot is performing. In order to do that we need to log all the work it is doing and count its total power consumption. That leads to a problem. First thought is to write a new class and inject a RoboWorker. But that would result in the Dependency Inversion Principle broken. We could do that or inject RoboWorker twice: first as IRobot and second as ICanWork; or else inject it once and then use “ICanWork as IRobot” statement.

But that is terrible, terrible idea as there is no way to be sure that object you will inject into PowerCounter implements IRobot interface. So, don’t even think about it as there is a better way – some call it super-interface. You simply create another interface which inherit all required interfaces and make our RoboWorker class implement that interface instead of two separated. In our case it’s going to be ICanWork and IRobot.

[edited 24-04-17]
I have been thinking about that solution given above and I couldn’t get rid of this feeling that it’s not the best way. And in fact it isn’t. First and foremost, in our example we had first written our class RoboWorker so it implemented two interfaces and then we replaced them with one interface that combines the former two, and that is violation of Open/Closed Principle – once a class is done it’s done. So better solution for PowerCounter needed here – generics to the rescue. PowerCounter will take generic-type parameter T which implements both interfaces implemented by RoboWorker.

In the above code PowerCounter class has one T type field which holds reference to an object supplied in the constructor. Usage of this would be as follows:

Now, it is nice and clean.

That’s it. Seems that I have now covered all SOLID principles. Hope you enjoyed!
Cheers, Michal

896isp.pdf by Robert Martin

Me about SOLID:
Single Responsiblity Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle