Decoding feedback - 4/5 stars

I recently saw this software review being shared on Twitter.

THIS APP HAS EVERYTHING I COULD WANT but it does more than I need. 4/5 stars

The implication was that if it does everything that they want the reviewer should have given it 5 stars.

This sat in my mind for a while and the response I was building became too long for Twitter so I'm posting it here.

Part of the job of a developer and any business owner is to understand what customers (or users) want. Often you have to try and work this out for yourself. If you're fortunate they'll tell you what they think or what they think they want. The trick of being a good business owner, or product manager, or customer relations person, or developer working from a spec is being able to take what is said and working out what is meant.

Reviews are great feedback. Let's see what the person who left the above review might be telling us. With no more context, we have to guess at some of it but let's what they might be saying as an exercise in trying to understand the user and identify ways of improving a product.

• This app does all they want. It's important to recognize that we're in a positive place and we want to make it even better. Don't start by being defensive and critical of what is mostly positive feedback. This is a learning opportunity.
• But they don't think it's perfect. The opportunity for improvement.
• Doing more than they need may be a problem. The challenge here is finding out why this is the case.
• Maybe there are so many features, options, and pieces of functionality it's hard to get to the ones they want.
• Maybe the features they want are at the bottom of or hidden in, a long list that the person has to search through each time.
• Maybe the terms the app uses aren't the ones the person uses and so they are forced to remember (or figure out--through trial and error) the translations each time they use the app.
• Maybe it's hard to do the things that they want, even though they are possible.
• Maybe they have to navigate through multiple pages/sections/menus to get to the functionality they want.
• Maybe the app has ways around the issue they're encountering but they don't know how and so it's just an education issue.

So, what could be done about this?

• If possible, seek clarification.
• Consolidate this feedback with what others are saying.
• Address the concerns once it's known what they are.
  My guess is that the ability to mark options as favorites or maintain a recently used list will help but it's worth exploring the possible other issues highlighted above to see if they're issues too.

HT

The specified ITextSnapshot doesn't belong to the correct TextBuffer - a solution

I'm assuming you're reading this because you encountered this error message in a Visual Studio log and didn't know what to do about it.

"The specified ITextSnapshot doesn't belong to the correct TextBuffer."

You may even have found a number of other blog and forum posts looking for answers but finding none.
I've been there myself.

This is a record of how I fixed this issue. This applies to how I addressed it in an extension I'm writing. If you're just using VS and not writing an extension yourself this is unlikely to be useful or interesting. If you are investigating this because of an extension you're writing, please note that you might be having this issue because of another issue to me.

Disclaimer over, I noticed this error occurring when a config file was deleted from the project.

The call stack in the log wasn't immediately helpful either.

System.ArgumentException: The specified ITextSnapshot doesn't belong to the correct TextBuffer.
   at Microsoft.VisualStudio.Text.SnapshotSpan.TranslateTo(ITextSnapshot targetSnapshot, SpanTrackingMode spanTrackingMode)
   at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.<GetTagsForBuffer>d__47.MoveNext()
   at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.<InternalGetTags>d__51.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at Microsoft.VisualStudio.Text.AdornmentLibrary.Squiggles.Implementation.SquiggleVisualManager.GetNormalizedSquiggleSpanCollections(ITextViewLine line)
   at Microsoft.VisualStudio.Text.AdornmentLibrary.Squiggles.Implementation.SquiggleVisualManager.UpdateVisualsOn(IEnumerable`1 lines, Boolean removeOldSquiggles)
   at Microsoft.VisualStudio.Text.AdornmentLibrary.Squiggles.Implementation.SquiggleVisualManager.UpdateSquigglesOnInvalidatedSpans()
   at Microsoft.VisualStudio.Text.AdornmentLibrary.Squiggles.Implementation.SquiggleVisualManager.OnLayoutChanged(Object sender, TextViewLayoutChangedEventArgs e)
   at Microsoft.VisualStudio.Text.Utilities.GuardedOperations.RaiseEvent[TArgs](Object sender, EventHandler`1 eventHandlers, TArgs args)

However, on reflection, it did provide a hint.
The mention of `GetTagsForBuffer` made me look at what I was doing with tagging.

In my `ITagger<T>` implementation I was using a cache of created tags to avoid needing to recreate them unnecessarily. However, it seems that changing the project that an open file is in causes a new TextBuffer to be created.
The consequence of this is that my cached tags now refer to a Snapshot with a different TextBuffer and that causes VS to have (but log) an exception.

My solution is that in the GetTags method, I check that the TextBuffer of the NormalizedSnapshotSpanCollection matches the TextBuffer of the SnapShot of the cached tags.
I only return the tags if they do match and if they don't I invalidate the cache for that file.

Hopefully, this helps save someone else some time trying to debug a similar issue.

Uno talk notes (links)

Today I gave a talk about Uno in London.

Here are the links I mentioned (all in one handy place 😀)

Main website - https://platform.uno/
GitHub - https://github.com/unoplatform

All the latest details - https://platform.uno/announcing-uno-platform-2-0/

Try it out (Sample apps)
Android app - https://play.google.com/store/apps/details?id=com.nventive.uno.ui.demo
iOS app - https://itunes.apple.com/app/uno-gallery/id1380984680
Windows app - https://www.microsoft.com/store/apps/9NTT97F69ZHZ
In browser - https://playground.platform.uno/

Other browser-based demos
In browser DB - https://sqliteefcore-wasm.platform.uno/
SkiaSharp - https://skiasharp-wasm.platform.uno/
Community Toolkit - http://windowstoolkit-wasm.platform.uno/
Lottie (animations) - https://lottie.platform.uno/


Ask for help - https://gitter.im/uno-platform

Rapid XAML in the future

This

Before

has become this

After

Yes, ownership of the repository has transferred to me.

Background

A little under two years ago, I was thinking about how more can be done to help developers building software. I was contributing to Windows Template Studio, which is a great way to get started in creating an app but wondered what could be done after that. I saw that there was a big gap in the tooling for developers working with XAML, and I had several ideas about ways this could be improved.

Skip forward a couple of months, and I had a proof of concept that I showed to some people in Redmond.
I received a positive response.
They asked what I wanted to do with it, and the conclusion we came to was to make it an "official" Microsoft open source project. And so, open-sourcing processes were followed (Yes, Microsoft has such things), a repository was created, and I began working away in my "free" time.

Fast forward to earlier this year.

I reached the point where it became realistic, practical, and necessary to start getting the functionality out to people who could use it.
In a case of bad timing, the primary advocate for the project within Microsoft left for another job.
The person who took over responsibility for the project within Microsoft then faced several months of me asking them questions. Questions like:

• When can we get this in the marketplace?
• What do you need from me to help this progress?
• What progress is happening?
• What can I do to help this progress?
• Etc...

To try and encourage things along and provide a way for people to see what I'd been working on, I released a preview via my own publishing account.
I did a small amount of extra work in response to feedback from the preview, but the uncertainty of the project meant progress on the project slowed.

Eventually, I got an answer. This wasn't going to be something Microsoft would publish.

Not totally dejected (or surprised--given how long things had taken), I asked about my continuing the project away from Microsoft. Primarily, this meant transferring the ownership of the repository to me. As there were only minor contributions from other people and I had no plans on changing the licensing, this was agreed to, in principle, subject to approval from legal.

Cue several months of me repeatedly asking, first, "Have you asked legal yet?" and then "Have you heard from legal? Can you follow up with them?"

Until.

Yesterday I received an email that the legal department had no objections and so I made the transfer.


I've definitely learned a lot from this process.


What's next?

• Time for me to get to work.
  While work had stalled concerning development, I've been keeping track of more and more ideas for what could be done to help developers and features to be added to the product. More details to follow...

• Get a "proper" version released.
  I'm also going to revisit how it's packaged, so developers need only install the bits they want.

• It will remain free and open source! An original goal was to gain experience in managing such a project, and that's still possible. While the direct Microsoft association would undoubtedly have helped, I still believe this can be a valuable tool for developers working with XAML. While Microsft continues to focus their effort on improving tooling within the visual designer, that leaves a lot of opportunities to offer tools to help within the editor.
  And, free because of not being a name that can sell the tool, I'd instead gain experience and knowledge from having a lot of people use it rather than make a small amount of money from a few users. Having spent the last 7-8 years doing work under NDA, it's getting harder to find work without any portfolio. Hopefully, this will start to show what I'm technically capable of and my knowledge of what developers want and need. This may aid in securing future consulting/contract work. I'm also hopeful the lessons and experience here may allow me to create other, paid, tools in the future.
  In a moment of what's hopefully excellent timing, I've also been approved for the GitHub sponsors program, so you can financially support this project too.

• A new website - probably.

• Merch/SWAG - eventually?

exciting times!

How not to build code when only docs are changed (AppVeyor)

Having documentation and code in separate repositories makes sense for many projects but not for all.

When you make changes to code you want the CI process to build the code to make sure everything is ok with it. Then, once someone (or rather something) other than you have verified it's ok, it can be merged/committed.

That's all good but sometimes it can be very time-consuming.

When making a small change you can easily get frustrated if you haven't changed anything related to code.

I only fixed a typo on the readme. Why is it doing a full build?

In scenarios like this, you shouldn't be building all the code.

There are lots of reasons not to build the code but the most important is that it prevents quick, simple things from being quick and simple. The consequence of this is that if something should be quick and simple isn't people are less likely to do it (again).

I'm less likely to submit a fix for an issue in your docs if it takes hours. And yes, I count the time all the actions on the PR will take.

Fortunately, it's really simple to avoid this issue. Just configure your server to not build the code when only docs have been changed.

For my projects (built on AppVeyor) I use the following configuration to avoid building code when the only things that have changed are images (kept in the 'art directory'), anything related to docs, and/or any markdown files.

Here's the relevant snippet from my `appveyor.yml` file.

skip_commits:
  files:
    - art/*
    - docs/*
    - '**/*.md'

I'm sure there's a similar way to do this with whatever build system/server/CI/CD process you use too.

None of those things are related to the code and so there's no need to rebuild the code to look for any accidental breaking changes or failing tests.

The next thing I'd like to do with my current process is to add additional checks for documentation and validate those checks only when the affected docs are changed. But that's a task for another day...