Dead Nintendo Switch?

“I'm sure this is irrelevant chatter but a few days ago I turned on my Nintendo Switch for the first time in months but the battery had drained, so I went to charge it but noticed after 20 minutes it still wouldn't turn on, I tried using another plug and putting it in the dock, it still wasn't working, I knew from early YouTube videos that some people had this problem and sold their console on eBay as "faulty, not accepting charge" when the console was first on the market, not wishing to sell my console I proceeded to calmly take it appart in an attempt to disconnect the battery and plug it in again in order to wake it up, however I'd forgotten how to remove the battery and wasn't sure the tools I had were best for the job, looking at the connector though made me realise if use 2 electrical screwdrivers, I could short the pins, simulating a temporary disconnect, I allowed the battery to spark for a split second and reassembled the unit. Hey presto, the Nintendo Switch is back in full working order, end of story. Good day to you all.”

James Barnes

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: VSBuild@1
  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 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: FileTransform@1
  displayName: Transform Release.Config
  inputs:
    folderPath: '$(System.DefaultWorkingDirectory)/Ui/'
    enableXmlTransform: true
    xmlTransformationRules: -transform **/*.Release.config -xml **/*.config

- task: PowerShell@2
  displayName: "Confirm web.config transform"
  inputs:
    targetType: 'inline'
    script: 'cat $env:System_DefaultWorkingDirectory/Ui/web.config'
    errorActionPreference: 'continue'

- task: FileTransform@1
  displayName: Variable substitution *.config
  inputs:
    folderPath: '$(System.DefaultWorkingDirectory)/Ui/'
    fileType: 'xml'
    targetFiles: '**/*.config'

- task: VSBuild@1
  ...etc..

Reference

Showing Software Architectures in 2+1 Views with UML

  • How can I show & explain an application or service architecture?
  • How can I draw “correct” (and what does that mean?) UML diagrams?

Let me show you how I document smallish software systems with, typically, no more than four UML diagrams. We'll cover the questions, what is worth diagramming? and what can I do with these diagrams anyway? and we'll cover enough UML to be useful.

I will use the example of developing a “lead generation” website, which should be simple enough to not get bogged down, but complex enough to answer some of the but how do I …? questions that more complex systems raise.

Why Diagrams?

Use diagrams as starting point to discuss, describe and explain your system. A diagram can give an instant overview of some aspect of the system. It can show important relationships on a single sheet of paper. It can raise important questions and show design decisions.

Why UML?

The UML is a visual modelling language. It has a vocabulary and grammar for diagramming software such that the diagram is a precise statement. So it can be used to show and explain software architecture.

The UML is the only diagramming standard left standing (with, perhaps, one exception that we'll see later). You may be tempted to compete in this uncrowded field of standards for software diagrams. I comment only that the UML contains several decades of work by several thoughtful people and if you can produce a usable standard that is simpler, quicker to learn, and not unhelpfully imprecise, then I shall be impressed.

You may also be tempted — as many, many of your colleagues have been — to just do without a standard. I hope these few examples will persuade you that learning a standard is less work than you fear and more useful than you expect.

Why 2+1 views?

The UML tells you how to diagram once you've decided what to diagram. “2+1” is a minimal decision about what to diagram. It suggests a couple of diagrams for the logical view of your software and one for the physical view (we'll explain what those words mean, too). That's the 2. But it starts with the 1, which is the context.

The System Context: Shown with a UML Use Case Diagram

Always start with context. Always start with simple.

The context diagram should make sense to your non-technical customer and can be so simple you wouldn't even give it a second glance. It shows:

  • Who and what will use the system
  • What the system will do
  • Who and what the system will rely on

In the UML, anyone or anything who uses the system, or is relied on by the system to do its thing, is an Actor. What the system will do is a UseCase. A UseCase is a instance of the system being used to do something. It is shown on a diagram just by its name, which is a single descriptive phrase, in an ellipse.

  • Anything inside the box is what the system does.
  • Anything outside the box is the context of the system.

How to Use a Context / Use Case Diagram?

Use the diagram to discuss scope, expectations and dependencies with the system's customers and with the development team who will build it. Its simplicity and brevity should also clarify what is not (or not yet) expected of the system. Like user stories, the brevity calls for conversation to clarify. Complex Use Cases call for detailed careful business analysis too, but that is done with words, not pictures.

For your developers, this diagram is the high level overview of what they're delivering — everything inside the box — and what the system will need for it to work — everything outside the box.

I really like having a “hand drawn” look when first showing diagrams, because it says “work in progress” and invites participation. A precisely drawn diagram risks the impression of being a final decision.

I try to draw diagrams to be read from top left to bottom right. So I put “active” Actors—the users—on the left, and “dependency” actors on the right. That's not a part of UML, but it's part of how I will talk through the diagram.

Here's the same diagram later on on the project. In phase two, we're giving visitors SMS feedback, and adding a whole new bit of functionality to read events from the customer service team and integrate then with web analytics.

Use Case diagram with several use cases, 2 user actors and 5 machine actors.


What if you have lots of use cases? Don't put more on one diagram than you can usefully discuss in a single session. Pick out the main use cases & those that show the main external dependencies (which probably means, the ones that pose the highest risk to your project). Optionally, have a second diagram for all use cases, but only if you have an audience for it.

UML Definitions

There are 3 things you need to know for this diagram:

Actor, UseCase, and Subject aka System Boundary

Here are their definitions, which I've abbreviated from the UML 2.5 spec, section 18 Use Cases.

UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.

A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems.

NOTE. An Actor does not necessarily represent a specific physical entity but instead a particular role of some entity that is relevant to the specification of its associated UseCases. Thus, a single physical instance may play the role of several different Actors and, conversely, a given Actor may be played by multiple different instances.

NOTE. The term “role” is used informally here and does not imply any technical definition of that term found elsewhere in this specification.

A UseCase is shown as an ellipse, either containing the name of the UseCase or with the name of the UseCase placed below the ellipse. An optional stereotype keyword may be placed above the name.

A subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name in the top-left corner, with the UseCase ellipses visually located inside this rectangle.

An Actor is represented by a “stick man” icon with the name of the Actor in the vicinity (usually above or below) the icon. An Actor may also be shown as a Classifier rectangle with the keyword «actor»

Other icons that convey the kind of Actor may also be used to denote an Actor, such as using a separate icon for non- human Actors.


The spec: https://www.omg.org/spec/UML

I have used 3 more UML features to add explanations:

  • A Comment is “a textual annotation that can be attached to a set of Elements”. A Comment is shown as a rectangle with the upper right corner bent (this is also known as a “note symbol”). The rectangle contains the body of the Comment. The connection to each annotatedElement is shown by a separate dashed line. The dashed line connecting the note symbol to the annotatedElement(s) may be suppressed if it is clear from the context, or not important in this diagram.
  • A Dependency “implies that the semantics of the clients are not complete without the suppliers”. A Dependency is shown as a dashed arrow between two model Elements. The model Element at the tail of the arrow (the client) depends on the model Element at the arrowhead (the supplier) .
  • InformationFlows “describe circulation of information through a system in a general manner. They do not specify the nature of the information, mechanisms by which it is conveyed, sequences of exchange or any control conditions”. An InformationFlow is represented using the same notation as Dependency , with the keyword «flow» adorning its dashed line.

A Hard Problem of Grammar: A formal logic analogue to Nagel’s bat

The hard problem of consciousness, and variations on it, revolves around the difficulty of explaining mental phenomena—I see and smell a rose; I think about my work; I feel pleased by good news—in materialist or physicalist terms.

The presumptive barrier that prevents neurophysiological research answering this question, is that objective observations which can be made by a researcher — such as, electrical current moves through these neurons; a biochemical cascade releases such and such a hormone — appear to be about completely different things than the subjective experiences of a conscious experiencer.

This objective/subjective gap has also been called a first person / third person gap: how can third person sentences such as “that neuron spiked” possibly relate to a first person sentence such as, “I see red.”

Expressed this way, the problem can be studied with formal languages. This appears to make it provably insoluble. It's a hard problem of grammar: there is no sound deduction from a set of 3rd person sentences to a 1st person sentence in any formal logic.

  • If subjective experience could be explained in objective terms, then that explanation—if it is a rational one—must be expressible in formal language.

(This claim may not be obvious. It's like claiming that some form of the Church-Turing thesis applies not only to mathematics and logic, but to rational discourse more widely, including empirical research.  I'm suggesting that any argument which is genuinely rational, can be expressed in a formal language. If some part of the argument can't be formalised then I think we will discover, on inspection, that it's because the argument isn't rational. Either it will be a non-sequitor, or it will be an appeal to emotion, or an ad hominem attack, or somesuch).

  • If so, the formal version of that explanation would have to, at some point, define the word ‘I’ in ‘3rd person’ terms, that is, without relying on any first person noun or verb or other part of grammar.

(This is essentially an assertion that some form of the Craig interpolation theorem can be proven for any formal grammar suitable for rational discourse. The Craig interpolation theorem says (more-or-less), that given a set of sentences only about apples, you cannot validly deduce from them a sentence about oranges. I suggest that any formal language that does not satisfy this constraint is not a language we can use for rational discourse. It may still be fine for poetry; but not for being rational).

  • I assert that any such attempted definition will, on inspection, turn out to be invalid.  That is, when we look at any such purported definition, we'll be able to see that it doesn't quite work and hence that the explanation which it supports will also fail. I do of course look forward to being proven wrong, but there aren't any attempts on the table so far.

I think any attempt to define 1st & 2nd  person words – I, you, me, we  – in 3rd person terms fails. Any definition using only 3rd person terms can only succeed in defining 3rd person 'things'.

The thought is somewhat similar to Chalmer's “Structure and functions” argument: anything you can define with structure and function will itself be structure and function. I think the grammatical argument is stronger, surprisingly (one doesn't expect arguing about grammar to prove anything!), because 1st and 2nd person speech and relationships is, and always has been, a core part of the reality of human experience.

Intuitively, throughout the modern era, people have always felt that a reductionist materialist account of humanity surely misses something. The grammar of every human language (at least, every one that I know of) embodies that fact.