I started 2019 with my annual review of 2018, the second year in a row doing so. While I was down on myself for missing objectives before I did it upon reviewing the data I was pretty content. The same will not be said for my review of 2019, but let’s dissect that further with a health review of 2019.

Necessity is the mother of invention. I’m working on a project where it seems that storing and manipulating documents is the way to go instead of the relational database route. Maybe it’s too much time having worked with Mongo but it just feels naturally to me. The go-to embedded database is of course SQLite so I start up with that and some of the new document processing capabilities that it has. Then it occurred to me to ask if there is a NoSQL Document database equivalent to it. Sure enough LiteDB is one and it is built natively for .NET. After using it a bit it was clear I needed to inspect and manipulate the data stored in it not just in my app but on the side. While the website shows literally half a dozen ways to do it literally all of them are stuck to running only on Windows. After a few days of suffering through a Windows VM with that being the only reason I decided to take some of my newfound skills with Avalonia and build a client that can run on Linux, Mac, and Windows too. This begat LiteDB Portal .

I’m working on prototyping some new desktop and mobile applications. One of the things I want them to be able to do is the “infinite scroll” workflow that you see in social media timelines like on Twitter, Diaspora, and etc. It’s essentially when you almost get to the bottom of your timeline it automatically loads it with more informaiton. As usual my go-to framework for doing the desktop is Avalonia . I’m using a basic ListBox so my first thought was to simply look for scroll events and scroll percentages (or some metric like that). It turns out that’s not directly and easily exposed. The solution was to manually wire up similar event handlers using similar properties that are exposed in more raw terms. Below is a break down on how I did it. You can find the solution to this in this Gitlab Repository .

(I want to thank the Egram for writing their Avalonia-based Telegram client with an open source license and publishing it here . The way they handled more complex scrolling behavior interception led me to this solution). Thanks to MakcStudio for cluing me into the existence of this project and their source code.

** Note this is a second version with a cleaner implementation of capturing the events using GetObservable. **

NOTE: This article is from 2019 and Avalonia has been under active development and improvement since that time. Please consult newer tutorials and documentation for how to use this against current releases of Avalonia.

I am embarking on making some libraries that have a chance to get large and that I wanted to be independent from the applications that will utilize them. It’s really all about easy and scalable dependency management. In Java we usually do this with Maven or Gradle . Under .NET we have NuGet . Of course there are command differences across the three but the idea is the same: just say which packages your code depends on and we will do the rest for you. They have another neat feature where if you write our own library you can easily bring that into your other project’s dependencies too. For public projects you want to circulate you can push them to the same repositories you download the other dozens (or hundreds) of libraries you use. For local development you can use them too. I thought it’d be as simple as mvn install or gradlew install in NuGet. Would that it were so simple . The long story short is that if I were developing on Windows it’d be slightly more cumbersome but not that difficult. For Linux, and I believe for Mac, however there is a lot more setup that needs to happen. Worse, the documentation for doing local repositories is a bit hidden and there are things you have to do in a few places. I’ve decided to document them all here.

Avalonia is on the verge of releasing their 0.9 update (it’s up to it’s fourth preview). The .NET Core system released 3.0 was released last month. I’ve been working on non-Avalonia related projects for the past several months but when last I left all my tutorials and projects they were running on Avalonia 0.8 and .NET Core 2.1. I’m looking forward to the near term release as well as having some upcoming projects that I think could be suited for Avalonia. In preparation I went updated all of my tutorial code repositories in a side-branch waiting for the day 0.9 hits prime time. Through that process I learned about some of the small and not so small (but all good I think) changes people may encounter migrating versions.

(As I side note, this is why it is a good idea to always be forward migrating code as libraries and runtimes jump versions. It’s easier to tweak from one release to another rather than two, three, or more.)

For a very long time I’ve been considering contributing to open source financially not just with code contributions. The model I was originally working on was one where I’d “buy” the free-as-in-beer open source software that I was using regularly. Looking at my software stack it’s almost all projects which don’t necessarily have huge corporate backing. Yes I use GitHub but that’s essentially Microsoft at this point. Yes I use Java but that foundation has huge corporate sponsors. Yes I use Linux which has lots of sponsors for some pieces but the projects I use are the smaller off to the side ones. So how did my “buy the software” model work? It turns out that plan sucks.

Between the months of July and August I had a month of travel. Part of that was a three week trip to southern Europe and another week at my first astrodynamics conference in a very long time (the AIAA/AAS Astrodynamics Specialists Conferenec ). Because of that I actually forgot to post some of the things that I had been up to for the first half of July, before my trip. I’m therefore combining my open source contributions update to cover both months in one post. One of the biggest shifts you’ll see is my focus for the time being. While I spent much of May and June focusing on Avalonia or development using it my focus in the past couple months, and for the time being, is shifting to a project called B612 Foundation which is a non-profit organization looking to make strides in improving our ability to track near-Earth asteroids and give us enough warning time to mitigate a potential impact if one is predicted to occur. The work I’m doing on their open source astrodynamics engine and related tools is the perfect merger of my interests and technical capabilites: software engineering and aerospace engineering.

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.