Carnation Anapa Winery, part 1, day 10: Specific gravity

Attempt #2. I’m measuring Specific Gravity to understand for how long more keep the must in the buckets.

  • Petite Sirah: 1.14

Then hydrometer broke, again. Need to buy another model, apparently.

Posted in Winemaking | Leave a comment

Carnation Anapa Winery, part 1, day 8: Specific gravity

So far looks good. I’m measuring Specific Gravity to understand for how long more keep the must in the buckets… But hydrometer broke before I even could start. Reordering another one.

Posted in Winemaking | Leave a comment

Carnation Anapa Winery, part 1, day 4: adding yeast

Seemingly nothing is happening within the bucket of Petite Sirah. Decided to add cultured yeast:

  • 60ml of boiled water at 105f

  • pack of EC-1118

  • stir, wait 5 minutes, stir again

  • pout into the must

Evening update: good news! Seemingly the reaction has started. So I decided to add yeast to the rest of the buckets:

  • Another pack of EC-1118 into Grenache
  • Bourgovin RC-212 into Mourvède

Note: I haven’t used sulfites to kill wild yeast.

Posted in Winemaking | Leave a comment

Carnation Anapa Winery, part 1, day 3: Mourvèdre

The third and final bucket is finished now.

  • I forgot to weigh in raw grapes

  • My weight: 78.75, my weight with bucket: 88.40, i.e. 9.65 kg of grape juice

  • Room temperature: 22.4c at 22.14.

Up next: shop on Amazon for a better masher. Wait, punch down, rinse, repeat

Posted in Winemaking | Leave a comment

Carnation Anapa Winery, part 1, day 2: Grenach

Baby steps. Today I destemmed and crushed the bucket of Grinache:

  • My weigh: 78.80, my weigh with bucket: 90.65, i.e. 11.85 kg of raw grapes
  • My weight: 78.25, my weigh with bucket 89.95, i.e. 10.7 kg of grape juice
  • I’ve lost 0.55 just but staying on foot and processing the vines
  • Room temperature: 19.4c at 23:12.

Additional equipment used:

  • Potato masher from Fred Meyer. Two different. Both sucks, will return. Need something will smaller holes and a comfortable handle.

Up next: finish processing the buckets.

Posted in Winemaking | Leave a comment

Carnation Anapa Winery, part 1, day 1: Petite Sirah

Today I destemmed and crushed the bucket of Petite Sirah.

  • My weight: 78.95, my weight with container: 89.35, i.e. 10.4 kg of raw grapes.
  • My weigh: 78.00, my weight with bucket: 87.10, i.e. 9.1 kg of grape juice.

Equipment used. To support local I buy brewing supplies at Mt Si Homebrew Supply in Snoqualmie.

  • 6-gallon food grade bucket (primary fermenter)
  • Star San 4 oz (for bucket sanitization)
  • Plastic containers (for unprocessed grapevines, waste)
  • Hands (to destem)
  • Kitchen nylon turner (to crush). Need a better tool though. Like a potato masher.

Up next: I’m going to punch down it every 12 hours.

Posted in Winemaking | Leave a comment

Carnation Anapa Winery, part 1, day 1: the journey begins

Hi there! My name is Alex. I write emails and in C# at Microsoft at day, I like various liberal staff on Twitter at night. I’m a diabetic on high fat/low carbs all day around. I’m a wine enthusiast. And now I’m also a home wine maker. And here I’m going to keep notes of my journey.

Today I drove with my son to Carthage Vineyard/Knight Hill Winery located in Zillah, WA and picked-up three 6-gallon buckets of three different varieties of grapevines: Grenache, Petite Sirah, Mourvèdre. I’m going to try to make famous red blend GSM, which actually is made of Sirah. So I’m going to call mine GPS instead.

Why Carnation Anapa? I live now in Carnation, WA. My great-great-grandfather Maxim Alexandrovich Boyko-Baba lived in Anapa, Krasnodar Krai, Russia. Somewhere around 1923-24 he has planted a vineyard. Less than 3 years later, shortly before the first harvest, someone wrote a donos. Shortly thereafter he was dekulakizated. In the memory of his life and efforts and to restore the family tradition I call this project Carnation Anapa.

Posted in Winemaking | Leave a comment

HeartbeatActorServiceType is invalid and cannot be registered. Only ServiceTypes specified in the ServiceManifest can register.

If you try to register an actor within a Service Fabric service like this:

ActorRuntime.RegisterActorAsync<HeartbeatActor>((serviceContext, agentType) => new AgentService(serviceContext, agentType))
            .GetAwaiter()
            .GetResult();

but getting the following exception:

System.Fabric.FabricException: ‘Invalid Service Type’
Inner Exception: COMException: Exception from HRESULT: 0x80071C21

then in Event Log (Applications and Services Logs -> Microsoft-Service-Fabric -> Admin) you’ll see an entry like this:

StartRegister: HeartbeatActorServiceType is invalid and cannot be registered. Only ServiceTypes specified in the ServiceManifest can register.

This happens because by default service name is inferred from actor name, e.g. HeartbeatActor would produce HeartbeatActorServiceType. And your service is called differently, AgentService in my case. Hence the error.

To change the behavior, apply [ActorServiceAttribute] to the actor:

[ActorService(Name = nameof(AgentService))]
[StatePersistence(StatePersistence.None)]
class HeartbeatActor : Actor, IHeartbeatActor
{
}

That’s it, folks!

Posted in Programming | Tagged | Leave a comment

Service Fabric and Dependency Injection, part 3: Unit testing

This is a series of blog posts:

Unit testing of the final construct we’ve got in previous two parts would be challenging due to a number of reasons:

  • Both StatelessServiceContext and StatefulServiceContext are sealed, what means you cannot instantiate them directly, ContainerConfig(new StatefulServiceContext()) simply won’t compile, neither you can easily inherit one or another, e.g. class MockedStatelessServiceContext : StatelessServiceContext.
  • Both StatelessService and StatefulService require the exact type of their respective context type, i.e. public StatelessService(StatelessServiceContext context), what means you cannot mock their base class so Mock.Of() won’t satisfy service’s ctor and it will fail in runtime (or in test time if you have appropriate test, and you should!).

Would be a bleak picture which would bury the whole idea. But ServiceFabric.Mocks to the rescue! Thank to it we can easily mock both contexts:

[TestClass]
public class ContainerConfigTest
{
    [TestMethod]
    public void Verify_MyStatefulService_Container_Should_Not_Throw_Exception()
    {
        // Arrange
        var container = ContainerConfig.CreateContainer(MockStatefulServiceContextFactory.Default);

        // Act
        // Assert
        container.Verify(VerificationOption.VerifyAndDiagnose);
    }

    [TestMethod]
    public void Verify_MyStatelessService_Container_Should_Not_Throw_Exception()
    {
        // Arrange
        var container = ContainerConfig.CreateContainer(MockStatelessServiceContextFactory.Default);

        // Act
        // Assert
        container.Verify(VerificationOption.VerifyAndDiagnose);
    }
}

That’s it! Now both of your stateless and statefull services themselves and all their dependencies are recursively instantiated and controlled by the container, plus their registrations are tested.

Posted in Programming | Tagged , | Leave a comment

Service Fabric and Dependency Injection, part 2: Stateless Service

This is a series of blog posts:

Update: this approach is incorrect, unfortunately. It actually creates two containers: one to instantiate the service and another to instantiate the Startup object. So it is even less elegant than initially I thought it is.

Last time we instantiated a stateful service from a DI container, it was elegant and relatively easy. What I can’t say about instantiating a stateless service that hosts a web server. The problem is that it needs a reference to the same container in 3 different places: Program.cs, MyStatelessService.cs, Startup.cs.

First the near identical code between stateless and statefull services:

ServiceRuntime.RegisterServiceAsync(nameof(MyStatelessService) + "Type", context => CreateService(context))
              .GetAwaiter()
              .GetResult();

private static StatelessServiceBase CreateService(StatelessServiceContext context)
{
    var container = ContainerConfig.CreateContainer(context);
    return container.GetInstance();
}

Now where the differences start. Let’s start from refactoring the Startup class. From the template it comes as a so-called conventional startup, in other words follows the Convention over Configuration principle. Now it inherits StartupBase and accepts Container in its constructor:

internal sealed class Startup : StartupBase
{
    private readonly Container _container;

    public Startup(Container container)
    {
        _container = container;
    }
}

Then inject IStartup into service’s ctor alongside its other dependencies (if any):

internal sealed class MyStatelessService : StatelessService
{
    private readonly IStartup _startup;

    public MyStatelessService (StatelessServiceContext context, IStartup startup, ...)
       : base(context)
    {
        _startup = startup;
    }

    protected override IEnumerable CreateServiceInstanceListeners()
    {
        yield return new ServiceInstanceListener(serviceContext =>
            new HttpSysCommunicationListener(serviceContext, nameof(MyStatelessService) + "Endpoint", (url, listener) =>
            {
                var builder = new WebHostBuilder();
                return builder.UseHttpSys()
                              .ConfigureServices(services => services.AddSingleton(serviceContext)
                                                                     .AddSingleton(_startup))
                              .UseContentRoot(Directory.GetCurrentDirectory())
                              .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                              .UseUrls(url)
                              .Build();
            }));
    }
}

The CreateServiceInstanceListeners() method differs from the template just slightly. Instead of UseStartup() now we use AddSingleton(_startup). What means the Startup class should be registered in the container by its interface:

container.RegisterInstance(context);
container.RegisterInstance(context);
container.RegisterSingleton();
container.RegisterSingleton();

The only thing left is to configure the ASP.NET Core infrastructure pipeline to use the container, for more details see the documentation:

public override void ConfigureServices(IServiceCollection services)
{
   services.AddSingleton(new SimpleInjectorControllerActivator(container));
   services.AddSingleton(new SimpleInjectorViewComponentActivator(container));

   services.EnableSimpleInjectorCrossWiring(container);
   services.UseSimpleInjectorAspNetRequestScoping(container);
}

public override void Configure(IApplicationBuilder app)
{
    container.AutoCrossWireAspNetComponents(app);
}

That’s it! Now your statefull service itself and all its dependencies are recursively instantiated and controlled by the container.

Posted in Programming | Tagged , | Leave a comment