I just finished setting a nice new ESXi 5.0.0 U1 server and wanted to start playing around with it. This is when things got complicated. VMWare offers an i386 installer for Player 4.0.2 but contrary to what you’d think, this installer is not supported on a 32 bit CPU. this installer is available for those who install i386 arch onto a 64 bit CPU. If you, like me, don’t have a 64 bit CPU then you have to live with 3.1.5 (VMware-Player-3.1.5-491717.i386.bundle at the time of posting, sorry i can’t find a live link). This installs as you would expect, by running sudo sh VMware-Player-3.1.5-491717.i386.bundle and following the GUI installer. You may remember from earlier vmware installs that you need to compile kernel modules in order for things to work “smooth” and this install is no different. Where this install differs is when you are using a 3.x linux kernel, such as the one that comes with Oneiric. For whatever reason, vmware assumes that nobody upgrades their linux kernel regularly and left us to patch the module sources ourselves. Fortunately, someone has done the heavy work for everyone already (my source for this info is here: http://ved-antani.com/2011/10/vmplayer-not-compiling-for-latest-linux-kernel/ ) so that you can quickly build the modules manually.

the instructions at the original source are not quite perfect, so here is what i did to compile my modules.
# you need to do this stuff as root
sudo su

# after the build is finished the modules will be installed

So anyways, i got fed up with rewriting nearly all the ArrayAdapter code every time i wanted to have a custom adapter, i decided to just sack up and write a GOOD ArrayAdapter, which I am calling the DynamicArrayAdapter. This new adapter handles changes much more efficiently and MASSIVELY simplifies any customizations of the adapter. If you compare it with the original ArrayAdapter, you’ll see that it is not very different at all, but the differences MAKE THE DIFFERENCE. So here is some code: http://pastebin.com/4mxtEC5e

Here is a sample implementation (for a sample Bluetooth app I wrote): http://pastebin.com/Quwsgkbm

I fully expect to never use ArrayAdapter again.

Recently, our province enacted Bill 26, which dropped the legal limit for consuming alcohol and driving your vehicle to 0.05 BAC, from the previous limit of 0.08 BAC. Proponents claim that the intent of this bill is not to criminalize the public who has a glass of wine with dinner, and furthermore (appear to) harshly criticize those who oppose such action by calling said people supporters of impaired drivers (ugh!). Let me first make it abundantly clear that I in no way support impaired driving. With that said, I cannot support the enactment of this bill either. I recognize the effort and the good intentions that went into this bill, but it has been pushed through for the sole purpose of this government to look like they are getting tough on impaired drivers. Now for some truths… Lowering the legal limit does not automatically make you tough on impaired drivers; it only makes it more common for a driver to be impaired. These are two very different statements, though they do look very similar on the surface. While statistics may show that “we are catching more impaired drivers” they do not show that more dangerously impaired drivers are being caught.

Let’s analyze this for a moment. By lowering the limit we are spreading our law enforcement thinner by having them cast a wider net to target more drivers. By doing this we are spending more time and resources on dealing with those who before would have been under the limit. Without proportionally increasing the number of resources to the statistical number of people who are now effectively driving impaired (lowering the limit by 0.03 includes a LOT more people in this problem) our law enforcement cannot spend the necessary time tracking down and removing those truly dangerous impaired drivers on the road. Now the proponents of this bill will say that everyone gets caught eventually, so it makes no difference, just more people get caught now. They are correct, partially. Everyone does get caught eventually, but that “eventually” time frame just widened. So if we have a statistical average number of impaired “road trips” before a death is involved, and a statistical average number of days before someone is eventually caught, then we also have a statistical average number of deaths per impaired driver. By widening that time frame we are actually increasing that number of deaths because more dangerous impaired drivers have more time to cause that statistical death. Don’t read too much into the statistics because statistics lie. But they do offer a window into real life data that is collected, the can inform us of trends and they can help us project. They cannot, however, tell us the future and guarantee results. So my very brief analysis above is just to help describe the logic that suggests that lowering the limit could have the opposite effect that is desired.

So you may ask if I don’t support this bill then what do I suggest we do instead. Well my suggestion is simple; the status quo was working but was improperly implemented. Let’s get something straight, the majority of people do not want to criminalize themselves intentionally. Some don’t care enough, but most would do the right thing if given the choice. The problem right now is that the choice is not very well defined. “Do I drive or do I cab?” The statement should really be worded as “My BAC is X, therefore I should Y.” Now it is no longer really a choice, all law abiding citizens follow the directive given, and those that don’t care enough do whatever they want and eventually get caught if they choose poorly too often. By increasing awareness at the individual level, citizens can now act responsibly with some contextual knowledge. Without that contextual knowledge, how can we expect everyone to make the right choice? If I ask you right now is the milk in your fridge expired? You can make an educated guess based on the last time you remember buying milk or looking at the expiry date, but without seeing that date in front of you can can’t make the right choice every time. Nobody wants to drink expired milk, so that’s why the date is included on the container. Without our BAC given to us prior to making our choice, we can never guarantee making the right choice every time. So how do we implement this notion? Well that is truly the most important question, how do we inform everyone at the individual level so that they can make an informed choice. We need a quick, simple, and cost effective way of informing people in the entertainment districts. It’s still a choice, so it should be optional, but easily available to those who want to be informed. I know that I would never step into a vehicle knowingly over the limit (even our new draconian limit). I have to imagine that others would feel the same, because who wants to voluntarily criminalize themselves? To implement this strategy some communication between law enforcement, legislators, and entertainment industry owners must begin. These three parties are those who can solve this problem in a reasonable manner.

Now that informed choice is solved, we need to solve the second half of the equation. When the answer to the choice is “I should not drive” then we need realistic alternatives. Catching a taxi from the Jasper Ave entertainment district to my home in Rutherford is absurdly expensive. A 5 to 10 minute cab ride in Edmonton, at night, with tip is approximately $20 to $25. The distance to my home is going to be around 40 minutes, and I would expect to shell out at least $60 and probably closer to $80 to get home. You want to talk about incentives to drive “impaired” this is the biggest of incentives. If someone has two beers over the course of 4 hours (what would be considered social drinking, NOT consuming to be impaired) then could EASILY be over the 0.05 limit. Do you think someone who was socially drinking would be interested in shelling out $80 to get home, not to mention another $80 to return and get the vehicle! Now I realize that a cab is not the only method of transportation, in fact I love public transit options and I think that the city made a wonderful choice when they proposed the late night transit service (too bad it keeps getting delayed). This certainly helps reduces the burden of cost but it isn’t feasible for the whole city only in concentrated entertainment districts. All this has me come to the conclusion that we require some more incentive to make the right choice. If you make the wrong choice (and you are caught making this wrong choice) then you are punished. But if you make the right choice, while you aren’t quite punished, you are still severely inconvenienced which almost feels like a punishment. I would love to see some positive incentives for those who make the right choice. We need cooperation between taxis, law enforcement, entertainment establishments, and maybe more to help subsidize the cost/burden of making the right choice. If those who are legally impaired have an incentive to make that right choice and maybe save someone’s life, then maybe providing that incentive will help solve this problem from a new angle.

Finally, I wanted to touch on the social media “problem” that is so viciously discussed these days. “Everyone who tweets a check stop is supporting drunk drivers and causing deaths!” I can’t stand it when people oversimplify the twitter issue. If you’ve ever been caught in a check stop line (I mean caught as in traffic wise) then you know that it sucks, a lot. You don’t complain because you know it’s for the good of the community but when you get home you silently complain that it took forever to get home because of the check stop. Now I know that tweeting check stop locations can be used by impaired drivers to circumvent their purpose, but let’s be truly honest here. Anyone who is dangerously impaired (not necessarily legally impaired) is probably not going to find out. This isn’t true for all cases, but in the general case the impaired driver is either not capable (not device to check for them), not motivated (doesn’t care enough to wade through all the anti check stop tweeting), not cognizant (remembering to check), or even not smart enough (to realize that there is in fact a check stop on the way home). When you consider this, really the only people who benefit from the check stop tweeting are people that probably aren’t of interest to the police anyway (or shouldn’t be because they aren’t actually impaired) thus making the check stop more efficient at finding those who are impaired. I would also like to bring up the fact that this was never a problem until the new legislation came into effect. People were more than happy with the 0.08 limit because that meant that 2 drinks over the course of your socializing period was almost certainly under the limit, and for those who were lighter weight one drink was still nothing to worry about. Now, even one drink may be too much. Two drinks is almost certainly over the limit for some. This dramatic shift in what is acceptable and what is not has clearly caused an outrage amongst those who enjoy socializing with a beer or glass of wine. The outrage has spawned a need determined by a few people to help keep the others informed. And I know that most people think that tweeting check stops is just as bad as driving impaired yourself, but I believe that it is a social mechanism to counter what many feel is an invalid restriction imposed on us. I know that in my own case two beers will almost certainly put me over the legal 0.05 limit. I used to enjoy going to the sports bar to watch hockey. I no longer engage in this activity because it is simply not worth the risk. It may sound stupid but I am what would be considered a light weight, my body weight hovers around 140 lbs. My body is very capable of processing two beers, and while by BAC might read 0.05 or 0.06, my impairment is very likely similar to someone else’s 0.03 or 0.04. BAC does not necessary imply impairment (though it is a very good indicator, there are variances). So while I am quite certainly not impaired, a road side test will probably disagree. I simply cannot afford to take such risks and therefore I no longer engage in social drinking without prior dedication of a ride home. The end result is that I far less frequent the sports bars to watch sports and socialize.

So to summarize I want to go over what I have suggested in this (rather long) post. I am suggesting that the new laws may in fact be causing more harm than good, in the form of too many resources wasted on those who are not truly impaired (or dangerously impaired at least). I am suggesting that we need to offer those who make the choices contextual information (what their current BAC is at) so that they can make the informed choice, and most likely the responsible choice. I am suggesting that we need to offer positive incentives to those who make the right choice, help make being responsible something people don’t have to think twice about. And finally, I am suggesting we stop caring so much about tweeting check stops because it simply isn’t informing as many dangerously impaired drivers as you think it might be. Remember dangerously impaired drivers are the people who are causing the majority (if not all) deaths. These are the people who making roads dangerous. These are the people that we don’t want on our roads. Let’s focus more energy on removing these people (either through law enforcement or the incentives I have suggested) and less energy on criminalizing law abiding citizens and clogging up our legal system. I want to make our streets just as safe as all of you Bill 26 proponents do, but we have to focus and target the bigger problems, and we just took a giant step in the wrong direction.

In my case i was working on a query that inner joined three tables together, then grouped by one of the columns in the joined tables. Now LINQ can do this no problem with Join/Join/GroupBy. The difficulty lies in how you project your grouped columns. By default LINQ will just include the whole collection of grouped columns per group row. While this works great in memory, the SQL bridge butchers your call. The reason is that SQL (SQLite at least) can’t do what you asked so the translation is to group by, then do a select all for each group row. As you can imagine, the computational power required grows exponentially with the data size. This is quite clearly very bad.

When working in pure SQL, we can only include columns that are in the group key and columns with an aggregation function applied to them. The aggregation functions are not super obvious on how to use them, so this is what i will be simplifying in this post. Usually what you want is the Sum, Count, First Row, Last Row, etc… from your grouped rows. The main problem is that you can’t just call the LINQ aggregate functions normally, because it doesn’t make sense in the context of your group by projection. I’ll start off with some sample code and move on from there explaining as i go.

First we join the tables together, and project the join into an anonymous type with both values
var q1 = Table1.Join(Table2, x => x.t2key, x => x.key, (t1, t2) => new { t1, t2 })

Now we can group by (say by t1) so that we end up with t1, and an enumerable of t2′s.
var q2 = q1.GroupBy(x => x.t1.key, x => x.t2, (k, x) => new { k.Name, Timestamp = x.Max(y => y.Timestamp), Value = x.Max(y => y.Value) })
so the first lambda tells us what to group on (our parent key), the second lambda describes how to project the grouped data (we will just project the whole t2 table), and the third lambda describes how to project the result set. The third lambda is where things get interesting, we can include members of the key as is (k.Name), but for members of the grouped data, we must apply the aggregate functions or risk a horribly inefficient query. In the above example, i am using the Max aggregate function, which (in SQLite land at least, but others as well im sure) will select the last item in the group as determined by the order by clause (which i didn’t include). Because i didn’t include an order by then its just the last item in the grouped data however the grouped data was built. The order by must appear before the group by in order for it to affect the aggregation functions, so above i would do something like q1 = q1.OrderBy(x => x.t2.Timestamp) in order for the Max function to return the most recent value in the grouped data. If you specify an order by after the group by, it will order the projected group results, so you could do something like q2 = q2.OrderBy(x => x.Value) in order to show the values in ascending order, without affecting the group by aggregation. This is executed by a wrapper query, that uses the projected grouped data as input, so you execute a second query, but that’s it (and this one is generally quite fast)

So the important bits to take a way from this post is that any aggregated columns you want to project must be individually included in your group by result projection, and if you include any enumerations in your projection then they will be converted into subqueries. While my example may not be all that complicated, it is certainly more complicated than simple a select/join/where/order type of LINQ query, which are far more common. By understanding the group by projection core concepts, it should be relatively easy to construct much more complicated (AND efficient) LINQ queries. And remember, when in doubt play around in LINQPad, that program is the best for testing out LINQ queries.

start : [a0, a1, a2], [b0, b1, b2], [c0, c1, c2] –> transpose –> [a0, b0, c0], [a1, b1, c1], [a2, b2, c2]

Now the Zip function in .net4 can do this very easily, but only for TWO enumerables, not any number. Its basic function is to interleave two enumerables and project the result. I wanted to do something similar but without the silly two enumerable limitation. It’s very easy to extend Zip to operate on > 2 enumerables statically, you just need to add more and more params to the extension method, but i wanted to have true dynamic interleaving functionality. So i wrote two extension methods (really just one, and then a simplification for the standard projection) that would do this. One consequence to note is that this will be slower than the built-in Zip, quite obviously because we’re dealing with more enumerables, but also because we can’t run the same type of optimizations that Zip does (this is due to the dynamic nature of this function). So here is some code to look at:

public static IEnumerable<TResult> ZipMany<TItem, TResult>(
    this IEnumerable<IEnumerable<TItem>> source,
    Func<IEnumerable<TItem>, TResult> func)
{
    var iters = source.Select(x => x.GetEnumerator()).ToArray();
    while (iters.All(x => x.MoveNext()))
    {
        yield return func(iters.Select(x => x.Current));
    }
}

public static IEnumerable<List<TItem>> ZipMany<TItem>(
    this IEnumerable<IEnumerable<TItem>> source)
{
    return ZipMany(source, x => x.ToList());
}

So the idea is we build an array of enumerators for each of the input source lists. We have to call ToArray to invoke the execution of the projection, otherwise some strange and undesirable stuff happens. Then we just iterate each enumerator at the same pace and project the index aligned projection of the results. It’s actually pretty simple code for what it is really doing, but it works quite well and i thought i would share it. The second method is just a helper that simplifies the first by removing the need to project the results, this way you can project the results into any custom type if you want, but the default is to simply project them into a list (which is how i can imaging myself and most others wanting the results returned).

I am curious if anyone can point out any improvements or optimizations on this code. Mostly just so i can learn from them myself. Other than that, i am quite happy with how this turned out and it works wonderfully with the application that i wanted to use it with.

This same post is available at the msdn forums if you want to follow the comments there as well: http://social.msdn.microsoft.com/Forums/eu/linqprojectgeneral/thread/40cc2410-adad-4da6-80cd-1736140e885e

The most important thing to note is that you only use the attached property to enable (or disable) a scoped region to share size info within. This is extremely important to understand because scope is not inherited by children if you override it. For example, if you were to create a grid within a grid and put the attached property on both grid nodes, the second grid would override the scope of the first, and you would NOT get your shared sizing. You only ever want to put the attached property ONCE for the ENTIRE scope of shared sizing.

With that out of the way, all you need to do now is give your row or column definitions a unique identifier on the SharedSizeGroup property and then all rows or columns that share the same unique identifier will also share the same hight or width respectively. You should also note that this only works for explicit or Auto sized rows and columns. If you specify a star on a shared item, it will default it to Auto.

When you are creating your DP’s, you have the option of specifying a default (initial) value. The problem with this value is that it is created and stored statically. So if you are creating a DP for, say, a collection, and you initialize it statically in the DP definition then your collection reference now exists statically. So regardless of whether or not you create ten instances of your DO, they will all contain the same initial value because they will all point to the same static reference.

So the conclusion to this quick lesson is that you should never initialize your DP’s with reference types, always perform this step at instantiation to guarantee unique DP values per object instance (unless of course you want to share the reference). As for value types it doesn’t matter nearly as much because the value is copied anyways.

The solution as you may have guessed is to use dynamic types, which allow you to build the type definition at run time and return it.  Since there is no static compilation type checking, it doesn’t care that you can’t define the return type of your method or property.  This isn’t something very common, or even recommended in most situations, but it can come in handy in a pinch.  Here is some totally useless, but good sample code explanation.

private bool flagValue = false;
private bool isFlagValueSet = false;

private dynamic Flag
{
    get
    {
        return new { Value = flagValue, IsValueSet = isFlagValueSet };
    }
}

public bool Test()
{
    return Flag.IsValueSet ? Flag.Value : false;
}

All you gotta do is ensure that you reference the Microsoft.CSharp.dll to get access to dynamic types.  You won’t get any intellisense on the flag variable, but that’s because the type information is computed at runtime only.

The problem here is that we need to bind the DP of the view’s context to multiple sources, something which a standard Binding does not allow.  MultiBinding allows multiple sources, but it would be impossible to know which source was actually “made active” most recently, so we could never return the right source accurately (unless we gave context to the sources themselves, which would be poor design).

The solution to this problem is rather simple, we just need to manage that multi-source aspect of the binding manually in the location where the binding is made or where the DP’s live (this could be the same place if you are doing MVVM).  First create a read only DP that will act as your view driving DP, it can be initialized to null.  Now create a standard event handler function to handle the property changed event for the driving DP on each source.  Hook up the DP value changed events:

private void ViewContext_PropertyChanged(object sender, EventArgs e)
{
    SetValue(ViewContextPropertyKey, (sender as IViewContextProvider).ViewContext);
}

DependencyPropertyDescriptor.FromProperty(Source1ViewModel.ViewContextProperty, typeof(Source1ViewModel))
    .AddValueChanged(m_Source1ViewModel, ViewContext_PropertyChanged);

In the event handler, we simply update your RO DP and that’s it!

If the scenario seems a little obscure, think of this situation.  You want to write a file explorer type of view, the explorer will obviously display files and folders in some sort of list or grid.  On the left hand side, you have multiple panels that determine the context of the file explorer.  One panel is your local system, another panel is a local search, another panel is an FTP site, etc…  All these left side panels can drive your single view through this RO DP pattern.