At Mozilla I recently rewrote the crash reporter (a cross-platform native GUI application) in Rust, using no external GUI libraries! This involved quite a lot of architecting and there were many hurdles to overcome. I've written a Mozilla Hacks blog post detailing the work. Check it out!
Lately I've been programming with Rust quite a bit. In my opinion, the language
shows careful, thoughtful design in almost every decision point of its
development. The syntax, semantics, standard library, and tooling are all truly
top-notch (and a welcome change from my C++ work). I've also used Rust deeply
enough to encounter the edges which aren't so smooth. Async code (using the Rust
Future trait) can especially present difficult cases at times, like when
dealing with more complicated lifetimes and when you want to be able to take
parameterized futures (i.e. future generators) as arguments.
I've been developing with C++ very extensively for the past year or so. Most of this development has been on heavily optimized codepaths, using modern C++17 practices. After creating a few developer interfaces, I realized that I was taking a similar general approach to interface architecture.
Web development has become a fast-moving, ever changing landscape of frameworks, technologies, and best practices. Approaching a new web development project can often be daunting, as rapid advancements quickly polarize various communities and everyone's advice can be conflicting. Which frontend framework is best (for varying definitions of "best")? Which server package can support the performance constraints of your project? Which build tools, bundling tools, and source languages should you use? I've gathered many opinions and preferences about these questions myself, but decided to take a step back to evaluate what benefits these complex systems provide.
A while back I was struck with the idea to make a low-power, solar-driven e-ink display with WiFi connectivity, so that I could hang it in a window and have information periodically update on it. In particular, an immediately useful function it could perform was showing the weather forecast (forecast accuracy aside). It turns out that these displays, while very easy to acquire due to the popularity of Amazon Kindles, are a bit tricky to drive. In particular, there aren't any publicly-available documents that detail how they work with enough information to get exactly what you want on the screen.
In C#, interfaces can only specify public properties and functions. However, especially when making libraries to be used by other projects, it is often beneficial to have internal interfaces (specifying functions that should also be marked internal, rather than public). Below is an outline of how to get this sort of desired visibility for internal interfaces, as well as convenient syntax for using internal interface methods.
The WIX framework is excellent for building installers and deploying software
for Windows, however there's some functionality that is left to be desired,
especially when it comes to deploying projects and ensuring that everything that
project needs is bundled. The WIX heat tool can do some helpful
things for your deployment, but if you don't want all your projects to build
into a single directory, and then use that directory when invoking heat, you
need something a bit smarter.
Anyone who has programmed using the WPF framework for a while eventually runs
into its limitations. In my opinion, the framework is great overall; it offers
many advantages over WinForms, and for little extra overhead. However, the
limitation of {x:Type} to only reference classes that are direct descendants
of a namespace was bothering me, so I made a markup extension to overcome the
issue.
The Intel Integrated Performance Primitives (IPP) libraries are excellent optimized libraries for Intel architectures that can really boost the speed of complex operations. Intel supplies them for Windows, Linux, and Mac OSX, and they also include optimizations specific to each Intel processor architecture. However, you should be cautious when using them in a Cygwin environment; they will work just fine, but the "default" usage won't work as expected.
I needed a VPN client in NixOS (the operating system I've installed and have been using on my work machine) that would work with my company's VPN. Unfortunately, neither openfortivpn nor strongswan worked, but I was told by some coworkers that libreswan was working well. The libreswan package didn't yet exist in the main NixOS nixpkgs repository, so I took it upon myself to add it in! Along the way I also learned about the nix expression language and the community behind both nix and NixOS.