Back in June on a lark, or maybe it was some nostalgia kick induced by an article I read somewhere, I wanted to see if SETI@Home. This was a system designed by UC Berkley around 2000 to turn spare CPU cycles on otherwise idle computers into a massive distributed computing infrastructure. It turns out that not only does it still exist but in the nearly 20 years I hadn’t been paying attention it turned into a giant ecosystem of so-called “Volunteer Computing” (VC) called Berkeley Open Infrastructure for Network Computing (BOINC).

It’s been awhile since I’ve done development around Diaspora regularly, or anything associated with the API. When I saw the announcement of the work being done with the API at their Hackathon back in April I was pretty stoked. It looks like it will be on track for the 0.8.0.0 release which hopefully will be in the near future. I was especially excited to see that there is a possibility of someone putting it up on a live-test server to work with. To get ready for that I wanted to make sure that my two code bases, the “test harness” and the “Comment Reflector” that used it to create comments for a blog as described in this blog post, worked as soon as a server went live with the code.

I follow a lot of open source developer blogs, including some from project-based blog aggregators like Debian, Ubuntu, and some .NET developers. One of the things they do that I like is that they provide a monthly summary of the open source contributions. In some cases I’m pretty sure it’s part of accountability for getting some funding to work on the project. In other cases I think it’s just a little historical tracking on their part. Some people make lots of changes and others just have one small package they incremented slightly. As I (hopefully) continue to ramp up my open source software contributions I want to begin that process as well. Some of these are relatively inconsequential things. Many of them are documentation-driven. All of them however I hope will help open source projects or users of open source projects in at least some infinitesimal way. Worst case I’m just publically documenting my own experiences to make for easy reference for myself as well as potentially othersThis will be the first such summary articles.

As I get ready to do a tutorial on a live simulator rendering using nothing but Avalonia it looked like using the standard event handlers in .NET and ReactiveUI that are the underpinning of Avalonia data flow would be the easiest way. There is a great example of this too with Nikita Tsukanov’s Avalonia BattleCity Game Demo which I was going to crib off. The first thing that came to mind though was what exactly is the throughput and overhead of .NET’s event handling system. Coming from Microsoft and with it being the core of many patterns not just the UI, but the UI is where we most often prominently see it, I was curious if it would break with large number of objects or handles. I didn’t expect it to be a slouch but exactly how far can it be pushed? This has most certainly done by others and probably even more thoroughly but this is new to me and I found it instructive. This is a write up of my exploration of this and the results.

Tree Views are a standard control for looking at hierarchal data in a user interface. Avalonia has a TreeView Control as well. In this tutorial we are going to go over creating a TreeView control for a league roster system. This is based on a similar tutorial written for WPF by Mike Hillberg that you can find here except that we are skipping the manual list aspects of it. As an FYI, I’m doing my work in JetBrain’s Rider IDE so screenshots and instructions will be from there but this obviously works with any editor. You can find the final solution for this blog post in this Gitlab Repository.