Carnation Anapa Winery, vol 2, day 17: Cabernet Sauvignon (cont’d)

My weight: 78.00 kg

Bucket #5:

  • 24.15 kg

Yeast: 1 pack of Lalvin Bourgovin RC 212

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 16: Cabernet Sauvignon

I decided to do not delay and start processing the recently picked grapes today. So first weight it in.

Some precalculations:

  • My weight: 79.40 kg
  • With empty container: 80.85 kg
  • Empty container: 1.45 kg

Bucket #4:

  • 23.00 kg

Yeast: 1 pack of Lalvin Bourgovin RC 212.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 16: Racking

Past weekend I did few things. First, I racked two of my 5-gallon carboys, removed a lot of dead yeast from their bottoms. I’ve read on internet that these bottom wastes may give wine the yeast smell, exactly what I ended up with last year, so I decided to do not take risk and dumped it with some bottom juice as well. So instead of having 1 extra gallon of juice now I had -1 gallon of juice, means of the carboys didn’t have enough juice to fill it up.

Then I drove to Zillah, WA again and picked about 6 buckets of Cabernet Sauvignon from same Chapman Vineyard. I will weight all what I’ve got tomorrow and start processing right away.

I got 2 gallons of Syrah juice, again from same Chapman Vineyard, but professionally fermented at Knight Hill Winery in industrial half-ton bin. I filled up one of my 5-gallon carboys with it. The result was fascinating: it started bubbling up very actively and continues to do it till now, about 24 hours later.

I racked another carboy again, added the rest of this very active juice to it, got 1 gallon of leftovers for the future needs.

Up next: wait for bubbling up to slow down, measure specific gravity, maybe rack again.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 9: Specific gravity, secondary fermentation

One week has passed and I’m measuring specific gravity again to see if it’s time to rack the buckets and proceed to secondary fermentation:

  • Bucket #1: 0.994
  • Bucket #2: 0.995
  • Bucket #3: 0.995

Per the information on the internet it’s definitely time for secondary fermentation, so that’s what I will do now.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 3: adding yeast

By about 11 PM of the next day I finished processing the grapes. I got at least 15 gallons of must: 2 almost full buckets and 1 little less.

This time I purchased at Mt. Si Homebrew Supply in Snoqualmie the yeast Clos Wine Yeast DYW45 that smells pretty good and is claimed to be “amazing for Syrah, Petite Syrah, Grenache, Tempranillo, and Carignane” (Cambridge comma is mine) by Cellar Science, batch #51362 (whatever it means).

I added about 5g into first two buckets and little less than that (almost the rest of the second pack) to the third bucket.

Up next: specific gravity in bucket #3. Which was 1.100, surprisingly or not the same as in the other two.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 2: Specific gravity

By the end of the first day of processing the grapes I’ve got two 6-gallon buckets almost full of juice. However, unlikely the prior year when I forgot to do that, now I’m going to measure the specific gravity at the start. Also to label the buckets.

  • Bucket #1: 1.100
  • Bucket #2: 1.100 (or little more)

I decided to not kill the wild yeast, same as past year. But I’ll definitely kill the rest of the yeast at the end of the fermentation.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 2: weighing

Some precalculations:

  • My weight: 79.75 kg
  • With empty bucket: 80.90 kg
  • Empty bucket: 1.15 kg

Bucket #1:

  • With bucket: 92.55 kg
  • Grapes: 11.65 kg

Bucket #2:

  • With bucket: 95.05
  • Grapes: 14.15 kg

Bucket #3:

  • With bucket: 94.65 kg
  • Grapes: 13.75 kg

Bucket #4:

  • With bucket: 90.85
  • Grapes: 10.4 kg

Bucket #5:

  • With bucket: 91.00 kg
  • Grapes: 10.55 kg

Bucket #6:

  • With bucker: 89.35 kg
  • Grapes: 8.9 kg

Total: 69.4 kg (or 153 lb even).

I’m going to start processing the grapes now. Will likely take a few days.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery, vol 2, day 1: Syrah

Today I opened the next chapter in my home winemaking experiments. I drove to Zillah, WA and picked about 6 buckets of Syrah/Shiraz from Chapman Vineyard.

My wife’s maiden name is Shiran, so it’s a funny coincidence. Will see how I can thread this fact into the upcoming wine.

I’ll start processing the grapes tomorrow in the morning.

Posted in Winemaking | Tagged | Leave a comment

Carnation Anapa Winery: industrial crushing and destemming

Over the passed weekend I, my family, and my parents stayed at Knight Hill Winery in Zillah, WA and got a chance to participate in two incredible activities:

First, on Saturday, we’ve picked a row of Roussanne at Carthage Vineyard. It took for 4 of us (me, my dad, my wife, and the owner) about 3.5 hours and produced one full bucket and a little more in another bucket, totalling more than 1400 lbs.

Then, on Sunday, we’ve crushed it using real industrial-grade production line: tipped the buckets over using a forklift, dumped the grapes over a conveyor line, that dropped them into a industrial crusher and destemmer, then pumped over the juice into a 250-gallon tank.

Posted in Winemaking | Tagged | Leave a comment

How I started using MediatR and then how I stopped

Introduction

Today I own the Service Fabric infrastructure piece in my team, to run applications and services written by otherw. But before I wrote a Service Fabric application to deploy other Service Fabric applications, it’s called accordingly – Deployment Service. It’s up and running in public and two national cloud environments, works perfectly fine (except huge backlog that that was put on hold and then effectively cut, of course). Initially it consisted of three “classic” layers:

  • Controller (ASP.NET Core)
  • Service (business logic)
  • Repository (CosmosDB)

I’m using Simple Injector as the Dependency Injection container of my choice with active usage of the Decorator pattern.

Having an interface like this for one of the “services” that plays the central role in the application:

public interface IDeploymentService
{
    Task<DeploymentPayload> GetOrCreateDeployment(StartDeploymentRequest request);

    Task<DeploymentPayload> GetDeployment(Guid deploymentId);

    Task CancelDeployment(Guid deploymentId);
}

I ended up with the following hierarchy of classes that implement and/or “decorate” it:

  • IDeploymentServices
  • DeploymentService
  • MultiTenantDeploymentServiceDecorator
  • LoggingDeploymentServiceDecorator

DeploymentService was implemented in a way that its methods called each other and it was working fine. Sooner or later almost every application receives a feature request which often leads to a lot of rethinking and restructuring, it’s called multi-tenancy. I implemented it relatively easily by introducing just yet another decorator, conventionally called MultiTenantDeploymentServiceDecorator.

Now, when a call reaches the bottom of the stack, i.e.:

  1. IDeploymentService.GetOrCreateDeployment(request);
  2. LoggingDeploymentServiceDecorator.GetOrCreateDeployment(request);
  3. MultiTenantDeploymentServiceDecorator.GetOrCreateDeployment(request);
  4. DeploymentService.GetOrCreateDeployment(request);

at DeploymentService then calls to other methods will be to DeploymentService itself as well. What bypasses the multi-tenancy decorator and brakes the functionality:

public sealed class DecoratorService : IDeploymentService
{
    public async Task<DeploymentPayload> GetOrCreateDeployment(StartDeploymentRequest request)
    {
        // this call
        var deployment = await GetDeployment(request.DeploymentId); 
    }

    public async Task<DeploymentPayload> GetDeployment(Guid deploymentId)
    {
        // will jump here 
    }
}

public sealed class MultiTenantDeploymentServiceDecorator : IDeploymentService
{
    public async Task<DeploymentPayload> GetDeployment(Guid deploymentId)
    {
        //  and not here
    }
}

This issue forced me to drop current architecture and redo it in the right way: Command Query Responsibility Segregation (CQRS).

Handlers, commands and queries

After refactoring each service’s method into its own class accepting (handling) its own type of command or query, I ended up with the following classes:

public sealed class StartDeploymentHandler : IRequestHandler<StartDeploymentCommand,  DeploymentPayload>
{
}

public sealed class GetDeploymentHandler : IRequestHandler<GetDeploymentQuery,  DeploymentPayload>
{
}

public sealed class CancelDeploymentHandler : IRequestHandler<CancelDeploymentCommand>
{
}

With single logging decorator (neat!):

public sealed class LoggingHandler<T, TResult> : IRequestHandler<T,  TResult>
{
}

And multi-tenancy decorator wherever it’s applicable:

public sealed class MultiTenantGetDeploymentHandler : IRequestHandler<GetDeploymentQuery,  DeploymentPayload>
{
}

MediatR

Instead of reinventing the wheel, I’m using the interfaces from small, slick and well-designed, open source library called MediatR which implements the Mediator pattern.

So now my ASP.NET Core controller looks like this:

[ApiController]
public sealed class DeploymentController : ControllerBase
{
    private readonly IMediator _mediator;

    public DeploymentController(IMediator mediator) =>  
        _mediator = mediator;

    [HttpPut]
    public async Task<IActionResult> StartDeployment(StartDeploymentRequest request, CancellationToken cancellationToken)
    {
        var command = new StartDeploymentCommand(request);
        var deployment = _mediator.Send(command, cancellationToken);
    }
}

Here’s how its unit test looks like now:

[TestClass]
public class DeploymentControllerTest
{
    [TestMethod]
    public async Task StartDeployment_Should_Return_StatusCode_Accepted_And_State_Queued_When_Deployment_Is_Accepted_And_Queued()
    {
        // Arrange
        var deploymentId = Guid.NewGuid();
        var request = new StartDeploymentRequest
        {
            DeploymentId = deploymentId
        };
        var deploymentPayload = new DeploymentPayload
        {
            DeploymentId = deploymentId
        };

        var mediator = new Mock<IMediator>();
        mediator.Setup(m => m.Send(It.Is<GetDeploymentQuery>(q => q.DeploymentId == request.DeploymentId)))
                .ReturnsAsync((DeploymentPayload)null);
        mediator.Setup(m => m.Send(It.Is<CreateDeploymentCommand>(c => c.Request == request)))
                .ReturnsAsync(deploymentPayload);

        var controller = new DeploymentController(mediator.Object);

        // Act
        var result = await controller.StartDeployment(request, CancellationToken.None);

        // Assert
    }
}

And it illustrates perfectly the issue with Mediator in general and MediatR in particular: the code that uses it violates, or stops following, even if with good intentions, the SOLID principles. Namely, it’s not possible anymore to tell what are the dependencies of DeploymentController as it stops telling that explicitly. At least not in the design time. I personally find it now an anti-pattern due to the very same reasons to why Service Locator/Inversion of Control is.

Back to injecting handlers

So instead DeploymentController’s constructor now looks like this:

[ApiController]
public sealed class DeploymentController : ControllerBase
{
    public DeploymentController(
        IRequestHandler<StartDeploymentRequest, DeploymentPayload> startDeploymentHandler,
        IRequestHandler<GetDeploymentQuery, DeploymentPayload> getDeploymentHandler,
        IRequestHandler<CancelDeploymentCommand> cancelDeploymentHandler)
    {
    }
}
Posted in Programming | Tagged , | Leave a comment