Customise Macos XQuartz : xinitrc doesn’t work

If you installed XQuartz and are, for instance, irritated by the small white xterm window you get, you might try customising it in the usual way by editting an .xinitrc file. If only.

Instead, try this:

defaults read org.macosforge.xquartz.X11

to see all the settings; or to permanently change the startup xterm window, something like:

defaults write org.macosforge.xquartz.X11 app_to_run \
 "/opt/X11/bin/xterm -fa Monaco -fs 12 -fg green -bg black -sb -sl 1000"

Or, if you have installed a better bash with homebrew, then e.g. :

defaults write org.macosforge.xquartz.X11 app_to_run \
  "/opt/X11/bin/xterm -fa Monaco -fs 12 -fg green -bg black -sb -sl 1000 -ls /usr/local/bin/bash"

Before setting the default you can check your syntax is correct simply by running your command in a terminal window.

To set the default for a new xterm window from the XQuartz Application menu, the menu itself lets you edit the command.

In short, read the FAQ : https://www.xquartz.org/FAQs.html.

Dev Azure Pipeline Web Config Transform

The web.config transform appears at first glance to be somewhat orphaned in Azure DevOps. If you are deploying to a WebApp then the pipeline wizard will probably have given you this snippet for your Build step:

- task: [email protected]
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'

To run config transforms you can add the additional parameter /p:TransformConfigFile=true to your msbuildArgs.

The replacement, of course, is the independent FileTransform task (which can also work within zip files). But once your site is packaged the Web.Release.Config is left behind; so you have to run the FileTransform task before, not after, the build step. (Similarly the WebAppDeployment task can’t transform a Web.Release.config that isn’t inside the package).

Slightly magically, the default parameter for the FileTransform is which is exactly what you typically want for web.Release.config transforms:

#xmlTransformationRules: '-transform **\*.Release.config -xml **\*.config-transform **\*.$(Release.EnvironmentName).config -xml **\*.config' # Optional

FileTransform can also do variable substitution, and you can have multiple FileTransform steps in your pipeline. I also like to see some diagnostic feedback so I include script step to show the xml transform result. But I put it before variable substitution, because the variables often include secrets:

- task: [email protected]
displayName: Transform Release.Config
inputs:
folderPath: '$(System.DefaultWorkingDirectory)/Ui/'
enableXmlTransform: true
xmlTransformationRules: -transform **/*.Release.config -xml **/*.config

- task: [email protected]
displayName: "Confirm web.config transform"
inputs:
targetType: 'inline'
script: 'cat $env:System_DefaultWorkingDirectory/Ui/web.config'
errorActionPreference: 'continue'

- task: [email protected]
displayName: Variable substitution *.config
inputs:
folderPath: '$(System.DefaultWorkingDirectory)/Ui/'
fileType: 'xml'
targetFiles: '**/*.config'

- task: [email protected]
...etc..

Reference

Should a method name describe what it does or what it intends?

Bob Martin raises a good example in InformIT: Robert C. Martin’s Clean Code Tip of the Week #1: An Accidental Doppelgänger in Ruby > Duplication of two functions that do the same thing but mean different things by it.

I recently stumbled into a slightly different take on the question of should a function say what it does or what it intends?

When a  function implements business process Alpha that today consists of steps A and B (but tomorrow  may change) should you call the function DoBusinessProcessAlpha or call it DoStepsAandB?

One answer would be, if the function is in a public package which exposes business functionality then the name should probably show that it does BusinessProcessAlpha. But if it is a private, not exposed, function then the reader is probably looking for the detail, that it does StepsAandB.

The question is more awkward if Steps A and B are themselves business process functions. That is, if you asked your customer, they would understand what steps A and B mean.

I suppose in that case you could always call it DoAlphaAsStepsAandB().

ConEmu in your Visual Studio External Tools List

Add ConEmu to your VisualStudio Menu -> Tools -> External:

Visual Studio Menu -> Tools -> External
VisualStudio Menu -> Tools -> External

By copying the line from ConEmu’s shell integration to get:

Command: C:\Program Files\ConEmu\ConEmu64.exe
Arguments: "{PowerShell} -cur_console:n"
Initial Directory: $(ProjectDir)

ConEmu in the Visual Studio ExternalTools menu
ConEmu in your Visual Studio ExternalTools menu