In January 2016 SpaceX made history by landing the first stage of a rocket that they have just launched. I know, Blue Origin did it first, but SpaceX rockets are designed for GEO orbits, while Bezos' reusable rocket is for LEO, so different animals. However, they have tried doing the same three times, last time just yesterday, only landing on a special barge at sea. Each time this have failed. But let's watch the three attempts, see what's going on.
First time, a year ago, January 2015, you can see that something was wrong with the way the stage came down, it was already angled and the horizontal speeds were really high.
Second time, three months later in April 2015, it almost got it right:
Third time, yesterday, 18 December 2016, it actually landed, then a landing leg gave out:
But what happened? Each time the stage reached the landing spot, each time in a vertical position and with low vertical speeds. Every time the engine exploded it did when the stage tried to stop and fell over. Wouldn't a specialized grabbing mechanism have prevented some of these accidents? Maybe even the first one!
Now, I understand that the purpose of SpaceX is to have a first stage that can land anywhere, and so they must rely on their device only, assuming nothing of the landing site, but once they go through the engineering issues, just catch it in a net, intersect three metal cables to support the upper part of the stage, do something. Look of those things, slowly falling down: you want to jump and catch them, like you would a drunken friend. Make your rocket understand it's not alone, Elon, that it's got our support! :)
Seriously now, I can't even imagine what would happen if the wind started blowing harder while the rocket tried to land on the barge. Since you have a specialized landing vehicle, make it better. The rocketry is fine, it is time to work on the support infrastructure with just as much aplomb and creativity.
So I've finally created a Facebook account. Yes, it won. I also accessed the Twitter one I created a few good years before and never used. These new social accounts will probably be used to publish what I post here, but anyway, I've updated the blog layout with my Facebook and Twitter accounts (see the icons top right).
It seems that for a very long time, since Blogger implemented the ugly system that changes the blog domain to a local domain, my blog was inaccessible for people in the UK and other places where the domain country had more segments, like co.in, co.uk, com.au, etc. due to a bug in my solution for it. I need to apologize for that. I fixed the problem now, but damn it is a long standing bug, a full three years.
Some of you may have heard of C# 6, the new version of the Microsoft .NET programming language, but what I am not certain about is that you know you can use it right now. I had expected that a new version of the language will be usable from the brand new upcoming fifth version of the .NET runtime, but actually no, you can use it right now in your projects, because the new features have been implemented in the compiler, in Visual Studio and, you have no idea how cool it is until you try, in ReSharper.
One might say: "Hell, I've seen these syntactic sugar thingies before, they are nothing but a layer over existing functionality. New version, my ass, I stick with what I know!", but you run the risk of doing as one of my junior developer colleagues did once, all red faced and angry, accusing me that I have replaced their code with question marks. I had used the null-coalescing operator to replace five line blocks like if (something == null) { ....
Let me give you some examples of these cool features, features that I have discovered not by assiduously learning them from Microsoft release documents, by but installing ReSharper - only the coolest software ever - who recommends me the changes in existing code. Let's see what it does.
Example 1: properties with getters and no setters
Classic example:
publicint Count { get { return _innerList.Count; } }
Same thing using C# 6 features?
publicint Count => _innerList.Count;
Cool or what?
Example 2: null checking in a property chain
Classic example:
if (Granddaddy!=null) { if (Daddy!=null) { if (Child!=null) { return Grandaddy.Daddy.Child.SomeStupidProperty; } } }
publicint Number { get { return _number; } set { if (_number!=value) { _number=value; OnPropertyChanged("Number"); //with some custom code you could have used a better, but slower version: //OnPropertyChanged(()=>Number); } } }
C# 6 version?
publicint Number { get { return _number; } set { if (_number!=value) { _number=value; OnPropertyChanged(nameof(Number)); // this assumes that we have a base class with a method called OnPropertyChaged, but we can already to things inline: PropertyChanged?.Invoke(this,newnew PropertyChangedEventArgs(nameof(Number)) } } }
Example 4: overriding or implementing simple methods
I don't particularly like this, but it can simplify some code when used right. Classic example:
return degrees*Math.PI/180;
C# 6 way:
//somewhere above: usingstatic System.Math;
return degrees*PI/180;
There are other more complex features as well, like special index initializers for Dictionary objects, await in catch and finally blocks, Auto-property initializers and Primary Constructors for structs. You can use all these features in any .NET version 4 and above. All you need is the new Roslyn compiler.
There are a lot of people asking around what is the difference between BindingList<T> and ObservableCollection<T> and therefore, there are a lot of answers. I am writing this entry so that next time I look it up, I save StackOverflow some bandwidth. Also, because my blog is cooler :)
So, the first difference between BindingList and ObservableCollection is that BindingList implements cascading notifications of change. If any of the items in the list implements INotifyPropertyChanged, it will accept any change from those items and expose it as a list changed event, including the index of the item that initiated the change. ObservableCollection does not do that. So BindingList is better, right?
Wrong. BindingList is not "properly supported" by WPF, say some. Why is that? Well, because BindingList, as its MSDN page says, is just "an alternative to implementing the complete IBindingList interface". Yes, you've got it. BindingList is a lazy, thin, ineffective implementation of the interface. The Missing Docs blog has a very good explanation of this. Do keep in mind that BindingList was created during the time of Windows Forms and is being used by WPF only as an afterthought.
So let's use ObservableCollection then! No. The functionalities implemented by BindingList are far superior to that of ObservableCollection. Just thinking that you must somehow handle changes of every object in the list is killing the idea.
A subtle recommendation on the same MSDN page goes like this: "the typical solutions programmer will use a class that provides data binding functionality, such as BindingSource, instead of directly using BindingList". Well, what does that mean? It means using System.Windows.Forms.BindingSource, which does about everything, since it implements IBindingListView, IBindingList, IList, ICollection, IEnumerable, ITypedList, ICancelAddNew, ISupportInitializeNotification, ISupportInitialize, ICurrencyManagerProvider and is also a subclass of Component. A bit heavy, though, isn't it?
There is more. The BindingListCollectionView page says "Specifically, IBindingList is required for BindingListCollectionView, and IBindingListView is an optional interface that gives additional sorting and filtering support.", which indicates that IBindingListView is also useful when getting a collection view for your object.
To recap: the best solution seems to be an ObservableCollection<T> that also implements IBindingListView (which itself implements IBindingList). The implementation must be scalable (getting the index of an object that causes a change in an efficient manner), though and I wonder, if I am implementing IBindingList, why should I even bother with inheriting from ObservableCollection? The same StackOverflow user seems interested only in the INotifyCollectionChanged interface for the ObservableCollection which is also implemented by IBindingListView!
Therefore, let's implement a class that explicitly implements IBindingListView and IList<T>, then publish the members we actually use! What could possibly go wrong? My idea is to store the index of an item next to the item, therefore removing the need to search for it. It seems that I must first implement an advanced List<T>, with a fast and efficient IndexOf method, then I can basically just copy paste the BindingList code and use this class of mine as the base. Unfortunately, BindingList uses Collection<T> as the base class, which itself implements IList<T>, IList, IReadOnlyList<T>. It seems I will have to implement all.
Immediately I have hit a snag. IBindingView is very difficult to implement, since it tries to filter using a string that is interpreted as a sort of DSL, so I would use a lot of reflection and weird conditions. Sorting is not much better. This is an interface invented when .NET did not support Predicates and lambda expressions, which would make sorting and filtering trivial and the subject of another post. So I go back to implementing a scalable BindingList, and just implement INotifyCollectionChanged over it.
For an implementation of IBindingView, check this out: BindingListView
Code time.
I've decided to implement the IndexOf caching as a dictionary with the objects as keys. The values are lists of integers representing all indexes of that value or object. Frankly I never realized that IndexOf for lists was not taking a start parameter, so it only returns the first occurrence of an item in the list.
There are three classes: AdvancedCollection is a fast IndexOf implementation of Collection. AdvancedBindingList is the copy pasted code of BindingList, with the base class changed from Collection to AdvancedCollection and with INotifyCollectionChanged implemented over it. SecurityUtils is only needed for the AddNew method of IBindingList and is again copy pasted from the Microsoft code. Enjoy!
I am a .NET programmer living and working in Bucharest, Romania.
Posts are divided into programming and misc.
Check out the icons above on how to contact or chat with me.
Unless otherwise specified, all code or any type of work you find on this blog is under MIT license. While I welcome attribution, I don't require it. Just use anything in any way you see fit. Consider it completely and utterly shared for the lulz.