Tuesday, October 15, 2019

Reconfigure the ElasticSearch Windows Service

If you are running ElasticSearch on a Windows Cluster you probably are using a Windows Service to run it in the background and make it start automatically at boot time.

This Windows Service feature is available out-of-the-box if you use the .zip package.

Some settings of ElasticSearch are managed as command-line arguments(e.g. the min and max memory usage). To manipulate these settings when using the Windows Service, you have to go through the ElasticSearch Windows Service Manager.

  • To open the manager, go the ElasticSearch installation folder. (e.g. c:\elasticsearch-7.4.0\)
  • Browse to the bin folder (where you should find a elasticsearch-service.bat file)
  • Run the following command:
    • elasticsearch-service.bat manager

This will open a GUI where you can manage multiple ElasticSearch settings:

Remark: Most changes will require a restart of the service.

Monday, October 14, 2019

ASP.NET Core gRPC–Unary RPC vs Streams

When creating your gRPC implementation you have to be aware about the difference between Unary RPC and Streams.

Unary RPC

This is the simplest type of RPC, where the client sends a single request and gets back a single response. This is the simplest approach and similar to what we know when using WCF.

Streams

With streaming we have to make a difference between server streaming, client streaming and bidirectional streaming.

A server-streaming RPC is most similar to the Unary RPC, the only difference is that the server sends back a stream of responses instead of a single response after getting the client’s request message. After sending back all its responses, the server’s status details (status code and optional status message) and optional trailing metadata are sent back to complete on the server side. The client completes once it has all the server’s responses.

A client-streaming RPC turns things around, the client sends a stream of requests to the server instead of a single request. The server sends back a single response, typically but not necessarily after it has received all the client’s requests, along with its status details and optional trailing metadata.
In a bidirectional streaming RPC, the call is initiated by the client calling the method and the server receiving the client metadata, method name, and deadline. The server can choose to send back its initial metadata or wait for the client to start sending requests. What happens next depends on the application, as the client and server can read and write in any order - the streams operate completely independently.

It is important that you are aware of the difference as it can greatly impact the performance characteristics of your application. Working with streams can help you reduce the memory footprint of your application as you don’t have to buffer the whole response in memory before returning it to the client. Another advantage is that the client can start processing before all data is returned from the server(or the other way around).

More information: https://grpc.io/docs/guides/concepts/

Friday, October 11, 2019

Why you should not fear rebase…

Last week our junior developers shared their experiences and lessons learned during a ‘dev case’. One thing they al mentioned is that doing a ‘rebase’ in GIT is, according to their opinion, a bad idea. Although rebasing is a powerful tool, and you have to apply it carefully, there is no reason to avoid it all cost.

Some things to keep in mind before you rebase:

  1. Never rebase commits that have been pushed to a remote origin and shared with others.
  2. Use rebase to catch up with the commits on another branch as you work with a local feature branch.
  3. You can't update a published branch with a push after you've rebased the local branch. You'll need to force push the branch to rewrite the history of the remote branch to match the local history. Never force push branches in use by others.

As a general rule it would only use rebase on local changes that haven't been shared with others. Once you’ve shared your changes, switch to merge instead.

  • To use rebase, go to Team Explorer –> Branches.
  • Select Rebase instead of Merge.
  • Specify the target branch and click Rebase.

Thursday, October 10, 2019

ASP.NET Core 3.0 - ConfigureContainer magic

Last week I blogged about the changes I had to make to let Autofac work with ASP.NET Core 3.0. Inside my Startup.cs file I had to use the .ConfigureContainer() method:

But where is this method coming from? Let’s dig into the ASP.NET Core source code to find out…

The source of all magic is the StartupLoader class: https://github.com/aspnet/Hosting/blob/rel/1.1.0/src/Microsoft.AspNetCore.Hosting/Internal/StartupLoader.cs.

This class uses reflection to find the following 3 methods in the Startup.cs file:

  • a Configure() method
  • a ConfigureServices() method
  • a ConfigureContainer() method

If you want environment-specific setup you can put the environment name after the Configure part, like ConfigureDevelopment, ConfigureDevelopmentServices, and ConfigureDevelopmentContainer. If a method isn’t present with a name matching the environment it’ll fall back to the default.

If a ConfigureContainer() method is found, the IServiceProviderFactory<TContainerBuilder> CreateBuilder method is invoked and the created builder is passed as a parameter to the ConfigureContainer()

Wednesday, October 9, 2019

Visual Studio 2019–Code Cleanup

Did you notice the small broom icon at the bottom of your code editor window in Visual Studio?

This is the  Code Cleanup button. It allows you to apply code styles from an EditorConfig file or from the Code Style options page. (The .editorconfig takes precedence).

To configure the exact Code Cleanup actions, you can click the expander arrow next to the code cleanup broom icon and then choose Configure Code Cleanup.

Configure Code Cleanup in Visual Studio 2019

After you've configured code cleanup, you can either click on the broom icon or press Ctrl+K, Ctrl+E to run code cleanup.

Tuesday, October 8, 2019

Visual Studio–Generate an EditorConfig file

I talked about the .editorconfig file a long time ago as a way to standardize code style conventions in your team. These conventions allow Visual Studio to offer automatic style and format fixes to clean up your document.

But did you know that in Visual Studio 2019, you can generate an .editorconfig file dynamically based on the style and formatting found in your existing codebase?

  • Go to Tools –> Options –> IntelliCode.
  • Change the EditorConfig inference setting to Enabled.
  • Right click on you solution in the Solution Explorer and choose Add –> New EditorConfig (IntelliCode)

Add IntelliCode-generated EditorConfig file in Visual Studio

After you add the file in this way, IntelliCode automatically populates it with code style conventions it infers from your codebase.

Friday, October 4, 2019

Azure DevOps - Publish code as wiki–Advanced features

One of the features I really like in Azure DevOps is to publish your code as a wiki. This allows you to choose a Git repository, branch and folder that contain Markdown files. The markdown files are then published as pages inside the wiki.

Unfortunately when we take a look at the table of contents(TOC) we see all the markdown files listed in alphabetical order. Every subfolder is also shown as a wiki page even when it doesn’t contain any markdown files.

This is probably not what we want. Let’s improve the TOC…

Change the page order

To change the order of the files in the TOC, you can add a .order file to the repository.

Each .order file defines the sequence of pages contained within a folder. The root .order file specifies the sequence of pages defined at the root level. And for each folder, a .order file defines the sequence of sub-pages added to a parent page.

Inside the .order file you can specify each file name without the .md extension. An example:

README
page-2
page-3

By default, the first file that appears at the root within alphabetical order is set as the wiki home page.

Promote folder to page

Another annoying thing is that every subfolder is shown as a TOC item in the wiki although no page exists. It would be logical to have a wiki page for every folder. Therefore we need to create a markdown file with the same name as the folder as a sibling to the folder (meaning both the folder and the md file of the same name should lie next to each other). See the screenshot below:

Promote a folder to a page