Month: March 2017

Developing my first HoloLens app

Wow. Unity is awesome. No. Unity is freaking awesome.

Seriously. As someone who has had to write her own physics engine three times (1. Space Invaders – my senior project in college, 2. Kinect app – my masters project, and 3. WebTop – Laser and Reflection and Refraction modules – my first developer job in college), I wish I had taken the time to learn Unity sooner.

To learn Unity (shameless plug alert: github is working on a plugin for Unity), I was curious what the experience would be like if I took the most-starred open source repositories graph from and made it into a holographic app.

most-starred open source repositories graph

Here’s what my first take of the above octoverse graph as a holographic app.

and here’s the holo-octoverse repo.

Here’s my suggested order of training (as of this writing on Feb 24, 2017)

  1. Get comfortable in unity before you do anything – TBH, I’d pay for a course that does nothing but teach me how to navigate around a scene in the unity scene. I got motion sickness on several occasions trying to navigate around the scene. True story.
  2. Start with the hololens 100-level trainings offered at the Microsoft HoloLens Academy –
  3. Get comfortable using the Emulator. The sooner you realize that the dot on the screen is NOT the gaze cursor, the more hours you’ll get back on your life.
  4. Take the pluralsight HoloLens course – it’s similar to the hololens 100 level courses, but with a bit of a different twist, so you’ll learn new things and help retain the info you just learned from the 100 levels.
  5. (Optional) – at this point I knew enough to build my app, so I didn’t continue with the 210 levels, except to grab bits and pieces of things I needed.

Hidden gotchas

  • My absolute biggest struggle was deciding when should a script apply to the entire node collection (i.e. the parent GameObject of all my nodes) or to an individual node. I was going around in circles (no pun intended, as this is a 3D connected graph). Finally, I started splitting scripts out individually (who knows if that is correct) and also I’d rather do more manual work in unity (i.e. wiring up public GameObjects to a script) rather than trying to figure out how to do all that at runtime. I’m confident there’s a better way, but it is a start…
  • Renaming a script in unity – renaming the script in unity will rename the filename (and will update the components using that script for you), but you’ll need to rename the class in Visual Studio (remember, ctrl+dot is your friend). A few times I had to restart unity because of errors.
  • Clearing warnings and errors:
    • If you have any compile errors, you’ll won’t know in Visual Studio. You’ll find out in Unity, at the bottom in the status bar where you won’t know to look at the beginning. You’ll double-click the status bar to see more about the error.
    • Once you think you’ve fixed your error, you’ll need to clear this output window. Otherwise, next time you update your script from VS and switch back into Unity, you’ll might be confused why your error still persists.
  • Always hit the play button in unity to verify there are no script errors. You can catch some null pointer exceptions this way.
  • Using the emulator
    • Sometimes your holograms will appear besides you, or behind you. Or your holograms appear in the bathroom, making people really confused by your tweets.
    • The emulator should come with a “I Accept” button that says the little dot is NOT the gaze for the tap gesture. (Have I mentioned lost hours). I lost a lot of time debugging why my tap recognizer wasn’t firing because I had the wrong cursor over the object.
    • You don’t have to close the emulator each time
    • If you’re just making an update in Visual Studio (e.g. in the multiple project solution), you can just redeploy to the emulator or hololens. You don’t have to rebuild in Unity.
  • For Visual Studio I keep the single-project solution opened to edit my scripts, but I close the solution produced by the unity build every time I’m done with that debugging session. YMMV
  • And honestly, the emulator is great. I used the actual device for sizing, e.g. how large should my object be? How far apart should they be spaced? But take note. if you’re goal is to use in a large space, you’ll need to test in that large space, versus doing your development in a small room.
  • For clipping planes, Microsoft recommends no nearer than 0.5m. Maybe it’s because I’m 5’1 and have practically no arm distance reach (I did karate for 20 years, trust me on this), but I found the near setting that worked best for me was at 0.35. But then again, perhaps holograms need to be placed farther away.
  • Where you develop your app versus where you film your app matters, as I mentioned previously. I was developing my app in a small room, so I had to have the nodes close to me; otherwise, they’d appear within the sofa. However, when you run the app in a large room, it makes you wonder why you didn’t space out the graph more.
  • When you go for a final build, make sure you choose Master instead of Debug or Release in VS. You also will want to delete the previous Release or Debug app on the device before you deploy your Master build.

Miscellaneous Helpful Links

  1. How to change the color of the cube we’re looking at?
    • See the Pluralsight training mentioned above.
  2. How to plot the x,y,z points on a Sphere – aka “how has my Math degree failed me today?”
  3. How to send the gesture command? At first I thought each object could register, but doesn’t seem to be the case
  4. How to use the Tapped event to generate new objects – at first I thought I’d be creating objects at runtime to display the Text overall, but decided not to go this route after all in the spirit of “get something working that you can demo”
  5. How to display 3D text
  6. How to have the text face you when you walk around
  7. How to find a child object

How to stage multiple changes within same file using Visual Studio – 069

Why would you want to stage multiple commits of the same file? Actually, I have no idea. This is why I’m writing this series so I can ask you all questions 🙂 Maybe there is no good reason to stage, just like making your bed every morning. Biggest waste of time EVER. You’re just going to mess it up less than half a day later… but I digress…

TBH I originally wrote today’s tip convinced I had found a bug in Team Explorer. I wanted to see what the workflow was like in Visual Studio when staging multiple commits for the same file. However, I confused myself by pressing the Commit Staged button, thinking it was the equivalent of git add <filename> (it’s not). In Team Explorer, doing Context MenuStage is the equivalent of git add <filename>, as you’ll see below…

To explain, let’s start with the command line for the expected behavior, then we’ll rinse and repeat using Team Explorer.

Multiple Stages using Same File using Command Line

First, I’ve written my code to be in a “baseline” state, e.g.

only Console.WriteLine("Hello World") showing

Next, I’ll add a new line

added Console.WriteLine(MyStrings.message);

and via the command line, I’ll run git add Program.cs (or git add . since it is the only file modified) to add it to staging.

Running a git status confirms it’s staged to be committed.

changeds to be committed: modified Program.cs

Don’t git commit yet! Let’s stage another changes to the same file.

Back in Visual Studio, let’s add a Console.ReadLine() to make sure the console window doesn’t go away…

added Console.Read();

Now let’s run git add Program.cs again. Running git status confirms it’s still staged to be added.

Now let’s commit by running git commit -m “two changes added”

git log shows two commit histories as expected

Now let’s rinse and repeat using Team Explorer…

Multiple Stages using Same File using Team Explorer

First, let’s get back to our baseline of just having Hello World. And I’ll hit Commit All to commit those changes.

back to baseline commit in TE

Next, let’s make that first line change of Console.WriteLine(MyStrings.message); but this time instead of hitting Commit All, you want to right click and hit “Stage”

clicking stage in TE

Now you’ll see the change has been staged in TE.

Staged Changes (1) in TE 

Now let’s add our Console.ReadLine() line…

Console.ReadLine() added

and stage that commit…

Staging a change to an already staged commit in TE

and now under Staged Changes (1), you can right click and hit Compare with Unmodified to see that the 2 new lines have been added to the staging area.

diff between the baseline commit and the 2 changes staged

Clicking Commit Staging in Team Explorer will now add these two new lines to the log.

Commit Staged

And now checking the history (Status Bar – Click Master (or whatever branch) then View History shows the two commits (baseline and the two new lines).

history in Team Explorer showing last two commits

How to stage changes in Visual Studio in separate files – 068

One of the reasons Git is pretty awesome is its ability to stage changes. I only recently discovered why it is so awesome to stage changes just a couple of months ago. But then again, I was using Ctrl+C, Ctrl+V as my VCS until 2 years ago.

I get ahead of myself all the time and I’ll make several updates at once and then my commit is no longer scope to one functional unit of change. For example, in my Hello World example, let’s say I wanted to make the following changes:

  1. Add a ReadLine() so I have to press Enter to dismiss the console window
  2. Add a new class that contains the actual “Hello World” string to be used – just trivial example to demonstrate making changes to a separate file.

And at this point I realize, “oh no! I forgot to commit part 1.” So now my commits become larger than I want.

What you can do is stage the commit for Part 1, e.g. in Team Explorer – Changes select the file you want to stage, and right-click and click Stage

Stage in Team Explorer

Now you’ll see two sections in Team Explorer. Your staged changes and your working directory.

Staged Changes in Team Explorer

Now you’ll see that the Commit All button has changed to a Commit Staged button.

Commit Staged button

To confirm what is happening, open the command prompt, and run git status. You’ll see that you’ve essentially did a git add Program.cs but via Team Explorer.

git status via command prompt confirming Program.cs staged

Finish the commit by clicking the Commit Staged button.

Now finish part 2 by committing the newly added strings class (and changes to the corresponding .csproj file)

Committing the newly added Strings.cs class via Team Explorer

And now if you view the log in Visual Studio – from status bar(!!) click the up arrow,

View History command from status bar

You’ll see the history with the last two commits

Local History shown in Visual Studio

and the command line will confirm, using git log

command line showing git log of the last few commits

Now you’ll see that what would have been originally one big commit is now two separate commits thanks to staging.

How to make quick edits in the diff view in Visual Studio – 067

I always assumed that if you’re diff’ing the working directory against the last commit (i.e. Compare with Unmodified), both sides of the diff would be read-only. Turns out, only the last commit (left-hand side) is read-only.

For example, suppose you’ve made some quick edits in Program.cs (see yesterday’s tip), and you’ve opened the diff in the Editor by right-clicking and clicking Compare with Unmodified, you can still make edits on the right-hand side.

Added a new line of code on right-hand side

In this example, I’ve added a Console.ReadLine(), as anyone who has ever created a throwaway console app knows why. (I thought at one point in VS 20 year history if you switched from debug to release, the console app persisted until you closed it, but it looks like that’s no longer the case)

As soon as you hit save, you can confirm via the command line that Visual Studio is being honest that you can edit changes on this right-hand side.

git diff confirming changes to right-hand side

How to use the GitHub tool window to make changes to a Pull Request from a contributor in Visual Studio – 066

We recently launched support for what we call “Maintainer Workflows.” You’ve got an open source project and you’re receiving pull requests. Suppose you want the contributor to make some changes. You can leave comments in the Pull Request asking them to make whatever adjustments, e.g. adding a Console.Read(); in a Console Application project. But what if they don’t respond in a timely manner or never respond at all? Now within Visual Studio you can pull down those changes, review them, make modifications, commit and push back up to GitHub, all within the GitHub tool window!

(P.S. the Pull Request contributor needs to create the Pull Request by keeping the “allow edits from maintainers” checkbox checked by default. see more at bottom of post).

Continuing from yesterday’s tip, let’s say you’ve reviewed the diff for the PR but you want to make one addition.

1. You can click on the Checkout to <pr/pr-title> link button to checkout the branch.

Checkout to pr/2-added-a-message being clicked in GitHub tool window

Clicking on the checkout… link indicates whether the checkout was successful. If not, it’ll tell you to go to Team Explorer – Changes to see what you have uncommited or unstashed.

Local branch up to date message shown

If you want to verify what state you are in, you can go to Team Explorer – Branches to confirm you’ve checked out a PR branch. Hovering over gives you additional information. You can also view in the VS status bar.

Team Explorer - Branches showing the pr branch checked out

2. Open the solution (if not already opened from Team Explorer – Home – Solutions) and then open the file you wish to modify.

In this example, I want to add a Console.Read() under the Console.WriteLine() that came from the Pull Request.

Console.Read() added to the PR by repo maintainer

Don’t forget to save and test your changes! // This is a note for myself 🙂

3. Go to Team Explorer – Changes and make your commit(s) to the branch

Team Explorer - Changes showing the commit for the Read()

4. Push your changes back up to GitHub from the Team Explorer – Sync page

Team Explorer - Sync - Push changes

And you should see a success message.

Successfully pushed to drofaras/patch-1

(We’ll cover more about Syncs in VS in a few weeks.)

If you go to to review the Pull Request, you’ll see that there’s been a new commit.

pull request page showing the new commit


Let’s take a minute to review what’s going on here. Remember a Pull Request is the start of a conversation. The actual code for the Pull Request sits on a branch that can be updated at anytime, hence why I say a pull request is the “start” of a conversation. In the past, this branch would be updatable by the person who created it. Now because of the new feature upstream repository contributors to collaborate on a forked branch, the user saraford-tips was able to make changes directly to the branch associated with the Pull Request from user drofaras.

When user drofaras created the pull request, she (or I) kept the checkbox checked to allow edits from maintainers.

allow edits by maintainers

Got Feedback?

I strongly recommend using one of the existing channels for feedback. Of course, I’ll help anyone who leaves comments. It’s just that if you use one of the existing channels, your feedback and questions go to the entire team; whereas this blog is my nights and weekends project, so it’ll take me a while to respond, but I will respond. Just don’t ask me how small my queue of tips has become! O_O

How to review changes in a pull request without switching branches in Visual Studio – 065

I’m disrupting your regularly scheduled tip series to talk about the awesome work the Editor Tools team has been doing at GitHub. I’m too impatient to wait for the series to catch up!

We have a GitHub Extension for Visual Studio that’s available in Visual Studio Gallery / Marketplace which is also an open source project at You can go to Tools – Extensions and Updates and under Online search for GitHub to install.

Once installed, you can open the GitHub tool window from View – Other Windows – GitHub

In the interest of time, I’m going to assume you are 1. connected to GitHub (either by signing in via Team Explorer or the GitHub tool window) and 2. in Team Explorer, you’re connected to a GitHub repo, as shown below

Team Explorer - Connect showing connected to SimpleConsoleApp repo

How to review changes in a pull request without switching branches

1. Go to Team Explorer –  Home – Pull Requests

Team Explorer - Home - Pull Requests button being clicked

Clicking Pull Requests will take you to the GitHub tool window, showing all of your open pull requests for your currently connected repo.

Note by default the GitHub tool window shows Open pull requests. You can filter to see closed and all pull requests.

GitHub tool window showing an open pull request 

2. Click on the title of the pull request (e.g. added a message) to view the details.

GitHub - Pull Request Details View

Ignore my funky font sizes. I’m making it to 40 without computer glasses. That one summer 10 years ago was an exception.

Lots of stuff going on here. We see

  • User drofaras wants to submit her (yes, my alias spelled backwards) branch patch-1 (the default name GitHub supplies to branches created via the website) into master.
  • A”checkout” link button, but the goal of this blog post is to review changes without switching branches. (stay tuned for tomorrow)
  • The details about the pull request and the option to view it on GitHub.
  • Lastly, there’s Changes (1) because only one file has been changed.

3. Double-Click on Program.cs to view the file diff

VS showing the diff between the two files

And that’s how you can do a diff between two files without switching branches within Visual Studio using the GitHub extension.

To show we’re still on the same branch as before (e.g. master), go to Team Explorer – Home – Branches to verify.

Team Explorer - Branches showing master as current branch

Got Feedback?

I strongly recommend using one of the existing channels for feedback. Of course, I’ll help anyone who leaves comments. It’s just that if you use one of the existing channels, your feedback and questions go to the entire team; whereas this blog is my nights and weekends project, so it’ll take me a while to respond, but I will respond. Just don’t ask me how small my queue of tips has become! O_O

How to view changes to your working directory in Visual Studio (and via command line) – 064

Yep this might seem trivial, but two things: 1. I discovered something new (see tomorrow’s tip) and 2. I’m playing with formatting of VS vs CLI

How to in Visual Studio

In Visual Studio, if you want to compare your current changes (i.e. changes in your working directory) to those in your last commit (where HEAD is at), you can right click on the file in Solution Explorer, in the Editor, in Team Explorer, aka practically anywhere, and select  Compare with Unmodified…

Compare with Unmodified

This command will open a diff of the file at HEAD and the file in the working directory,

Program.cs;HEAD vs. Program.cs

where you can see the changes in the diff side-by-side, where the Console.WriteLine was added.

Diff showing Console.WriteLine() message being added

How to via Command Line

Here’s how to do the same via the command line. Open the command prompt and navigate to your solution.

PSA: If you don’t have the Productivity Power Tools installed, go get them! Then you can right-click Program.cs and select “open in command prompt.”

To compare changes from your working directory (i.e. what you haven’t staged or committed yet) to your last commit (where that HEAD pointer thingy is at), run the following command

git diff

and now you’ll see the equivalent diff in the command line interface

command line showing "git diff"