So I tried to use
Oracle.ManagedDataAccess on a .Net Core 3.0 project. But when trying to do queries, it failed with this error message:
Cannot print exception string because Exception.ToString() failed.
I enjoy working with the MVVM pattern which underpins Xamarin Forms, WPF, UWP and other XAML based application frameworks. Testability is one of the pattern’s strengths, and after reading about Spotify’s Microservices Testing Honeycomb I’ve come to reevaluate my earlier client testing strategies.
Read their article for details on testing microservices, but I argue that this approach is valuable also on the client-side. Luckily, the interaction points in XAML based apps using MVVM are well defined. The interaction points are the
events and their effect on application state.
Testing commands is trivial, they’re only public methods after all, but what about properties and their INotifyPropertyChanged events? We want to make it easy to verify that the UI does what it should, using as few tests as reasonable in doing so.
GitHub actions still have a couple of limitations when it comes to Docker:
- Docker is not available on macOS virtual hosts
- Docker is set to Windows-containers on Windows virtual hosts
Thus, a complete recreation of the previous build which built and tested on all three OSes is infeasible using Docker. But it works in Ubuntu and Windows and this post is how you do it.
Consider the following Dockerfile, perhaps the simplest in existence, which echoes back the argument given to it:
FROM mcr.microsoft.com/dotnet/core/runtime:3.0-alpine ENTRYPOINT ["echo"]
And this small script,
test.sh, which builds the container, runs it with the argument 42 and verifies that the output is the same as the input.
#!/usr/bin/env bash docker build -t hjerpbakk/example . ARGUMENT="42" RESULT=$(docker run --rm -it hjerpbakk/example "$ARGUMENT") if [ "$RESULT" = "$ARGUMENT" ]; then echo "container ran successfully"; exit; fi echo "container failed. Expected:" echo "$ARGUMENT" echo "but got:" echo "$RESULT" exit 1;
Surprisingly, 42 is not equal to 42. What is going on here?
GitHub has finally learned from GitLab and added GitHub Actions to their repertoire. It’s in beta now, but this means that we can use only GitHub for everything from code hosting, project management, CI and finally CD. All in one place. An alluring thought, but how mature is it?
I recently started a new project using ASP.Net Core 3.0 and decided to take GitHub Actions out for a spin.
I needed to benchmark a couple of CLI solutions today and found the wonderful tool hyperfine. It times arbitrary shell commands over multiple runs, giving you the mean execution time and other statistical variables. As command timings can vary significantly between runs, this is a live saver if you want to compare different commands with regards to run-time.
- Statistical analysis across multiple runs.
- Support for arbitrary shell commands.
- Constant feedback about the benchmark progress and current estimates.
- Warmup runs can be executed before the actual benchmark.
- Cache-clearing commands can be set up before each timing run.
- Statistical outlier detection to detect interference from other programs and caching effects.
- Export results to various formats: CSV, JSON, Markdown, AsciiDoc.
- Parameterized benchmarks (e.g. vary the number of threads).
I previously wrote about how you can create a list of all your tags, sorted by the number of posts using Jekyll. Güngör Budak had a much better idea; create a tag cloud sorted by post count. Since this solution doesn’t require plugins, it too is compatible with GitHub Pages.
My tags now look like this, and for the first time, I’m happy with my archives page.
Over the years, I’ve amassed quite a few posts on this blog, but I’ve never been pleased with my Archives page. I’m still not completely satisfied, but it’s now improved by showing the tags and the number of posts in them, in addition to a chronological ordering.
I achieved this using only a Liquid template. It doesn’t use any plugins and is compatible with GitHub Pages.
Some of my regular readers might get déjà vu; this is the return of ERROR bad Request-Line.
Taking screenshots of your app on every device and localization quickly becomes time-consuming. With 2 languages, 6 different iPhones and 10 screenshots, you are faced with 120 screenshots per release. If we increase the number of languages to 10 and add iPad support, this number explodes to 10 (languages) x 11 (devices) x 10 (screenshots) = 1 100 screenshots!
Xnapshot enables you to use C#, together with Xamarin.UITest, to automatically take the screenshots for you. Just derive from the abstract Screenshots class, implement one simple method per screenshot and use your time productively while your computer takes the screenshots.