As I tweeted about over the weekend, I’m going to be starting a month of deep diving into Rust for the month of May. I’m not trying to be a complete convert. I have work to do after all. However I really want to explore this new lower level language as opposed to my day to day work in managed and interpreted languages. I’m going to try to spend an hour or so each day working through tutorials and maybe trying to build my first real application with it. I’m starting with the Rust website seems to have some great resources like a language guide book and tutorials. I’ll go on from there. Today however was just getting the system setup and working through my first hello world tutorials. So far it’s been a mostly positive experience.

I was having a moment of weakness in my quest to permanently get off Facebook. The last two weeks I’ve missed some major things that were happening to some friends and family. Yes, I ultimately learned about it but I learned about it because my spouse is still on Facebook and he made a point of letting me know. At the same time I was still feeling constricted in my ability to discuss things with friends. I had been texting friends through various systems: LinkedIn, SMS, Matrix, iMessage, Twitter DMs, etc. and it occurred to me that all of this would have been in one singular place (Facebook Messenger) before now. So what was the point? Why not, I rationalized, rejoin and figure out how to leverage manual cross posting or some other mechanism to help extract friends from Facebook? Then it struck me, the next book up on my reading list was Steven Levy’s Facebook: The Inside Story . As I wrote on social media perhaps that book would push me one way or the other. Boy did it ever! The book is a great exploration of the entire history of Facebook right up to the present day. While I had mixed emotions earlier in the book as the story of Facebook went on so too did my revulsion to the idea of every going back.

I’m becoming more and more energized by the climate debate every year. At the same time I don’t do anything practical about it at any point either. Do I reduce my consumption habits? No. Do I adjust my diet to make it more carbon friendly? As a side effect of eating more whole food plant based I do but it’s not the direct target. Do I do some kind of offsetting? No. So as much as I lament our global lack of action on climate change I fall into the same boat as everyone else. Just like everything in life I suppose I want it to be something automatic. I didn’t actively stop using CFCs to help fix the ozone layer but I did do it because the government banned CFCs. Hypothetically the same sorts of environmental policies could be underway for the past 20 years to help mitigate climate change. None of that has happened. So what can I do to do proactively address this problem? Actually the real question is what am I going to do to mitigate that? I’m going to take the same quantification and tracking approach that I use for everything else in my life.

I’m pretty stoked about what I was able to do in 2019 towards open source software. I’ve always contributed here and there but I took the momentum of contributions I did in the second half of 2018, in that case to the Diaspora project, and just kept on trucking. I spent a total of 653 hours on open source projects in 2019. A lot of that was new code generation but there is of course more to development than just writing code. There were lots of meeting times, some hackathons, documentation generation, tech support etc too. Some of these were projects I started as well as contributing to established projects. The five projects I contributed to the most fall into a relatively broad range of software (from highest to lowest number of hours contributed):

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.)