While working on the post “Microsoft Orleans — Reporting Dashboard”, I ran into an issue where code generation seemingly stopped “generating”.
Orleans is an easy to use actor framework, but how can you monitor your deployment? Luckily, there’s something simple to use — Orleans Dashboard!
Note this is not an Orleans post, not exactly — it’s just something I wanted to enhance on my Orleans Project, prior to moving on to demonstrating even more Orleans features!
We’ve explored Orleans for distributing application logic across a cluster. Next, we’ll be looking at grain reuse and grain state…
Have you ever had a LOT of projects in a solution, many of which use the same NuGet packages? Managing package versions could be a nightmare!
I’ve been a developer my whole life, professionally about 10 years. In those 10 years, I feel I’ve always been able to “get the job done”, but things really started to click for me, once I embraced the abstraction.
Previously I got docker working with nginx and let’s encrypt; this resulted in an “A” from ssllabs.com. Let’s see about getting that to an “A+”.
I’ve used letsencrypt in the past for free certs, but I have not successfully utilized it since moving over to docker/kestrel/nginx. That all changed today, and I had a hell of a time figuring out what I’m doing to get it working.
So, I’m losing faith in my google skills, there didn’t seem to be a one stop shop that I could find to give information on setting up a .net core console application with a
IServiceProvider and utilizing
IOptions… so that brings us here.
I’m close to wrapping up my initial pass through the solar projection feature of the website. One of the final touches is the ability for visitors to run their own projections.
I needed a way to quickly distinguish between “good” and “bad” years, that led me to NgClass. So let’s continue on with Angular basics - NgClass.
Last post, we added some basic pipe information to the solar projection page. I noticed that due to the way my array worked, the data in the table shows the first year as “year 0”…
Last post we worked on data binding, this post I want to expand on that. Right now we have no formatting, so I’d like to add currency formatting, and/or thousands separatorsto the bound data.
I’m not really a front end guy, but I want to try to learn at a minimum the basics. I wanted to expand on the post my first NuGet package, by putting a visualization to the projection.
I published my first NuGet package (https://www.nuget.org/packages/Kritner.SolarProjection/)! Kristen and I recently were considering (and have since financed) a 17,000 kw/year solar array, on the back of our house
Unit testing continued - dealing with changing requirements.
We’ve been doing a lot more concentration on unit testing at work lately, and a question has come up. What value do automated unit tests provide?
In the previous post, we had setup our basic WCF project to play around with for unit testing. So let’s get to testing!
In the previous post I started exploring unit testing, specifically with moq and for WCF services.
We had a new team lead start recently, he seems to have had a fair amount of experience in areas I’m only vaguely familiar with, mostly through reading. One of the first things being pushed for is a concentration on unit testing. While I did begin implementing some tests into our codebase a few months ago (around 250 so far), I feel that there’s still a long way to go. Luckily Chris is here to help impart knowledge to us, hooray!
The simplest way I can think of to explain a build server is to imagine hiring a brand new developer for each code check in, giving them explicit instructions to accomplish the build, and letting them go. Maybe that requires a bit of explanation - the idea of a build server is to provide a reproducible set of instructions/steps to accomplish building your application from start to finish without requiring additional input from the developer checking in the code.