Being Grateful Is Good For You

Being grateful—for what others do, for good fortune, for what you have—is good for you. It makes you happier, helps you sleep better, and boosts your immune system. Being grateful is a good way to live and when you thank someone else for what they have done for you, I believe it fosters relationships, builds community, and encourages others to do the same.

I learned about the concepts behind journaling gratitude at my first KalamazooX when Elizabeth Naramore1 discussed her own gratitude journal. Around the same time, a Facebook friend started recording five things a day for which they were grateful. Looking back, this was the period when I started to acknowledge that I had unaddressed problems with depression, anxiety, and self-worth. Being grateful seemed like an easy place to start, so I gave it a try.

At different times, I recorded my gratitude using Facebook, Twitter, a physical journal, and my blog. Eventually, it started feeling stale or false; I was being thankful for inanimate or generic things like coffee, friends, or sunshine. Don't get me wrong, these are all fantastic things, but stating gratitude for coffee felt like my goal had become writing about gratitude than actually feeling grateful.

"…people are not so keen on just handing out personal information like their home address without at least knowing why."

Sometime before a visit to Boston, I had read about a man who set out to send one "thank you" note a day for a year. The idea of writing to people and thanking them directly was appealing. While in Boston, we visited the Isabella Stewart Gardner Museum, and there I bought a box of postcards that I thought would suit this purpose. It took another two years and a move to Texas before I actually got started.

It has now been three weeks since I started; I have sent 20 cards, and have another four ready to go this week. Writing them is cathartic for me and I get a little excited to mail each one. I keep a list of the people I intend to write to and make sure to keep track of those to whom I have already written. Each day, I send one card, write one or two more, and send a message or two over the Internet to get addresses. However, it turns out that some people are not so keen on just handing out personal information like their home address without at least knowing why. This seemed odd to me at first and I felt untrusted. In addition, I felt a deep reluctance to explain why. It seemed I felt the value of this project was lost if the postcard was not a surprise. Of course, that is ridiculous; not only do people have every right to know why I would want their address, but if the surprise of receiving the card itself were the value, what would be the point of writing anything on the card?

So, I write this blog entry, in part, to provide an explanation for people when they ask why I need their address. That said, I also write it as encouragement to others who might be considering the start of their own gratitude project. Being grateful is powerful on its own, yet the responses I have received to messages I have sent have been wonderful, humbling, and kind. People are amazing, so tell them; the more you thank others for their impact on your life, the more you will be surprised by your impact on theirs.


  1. IIRC 

OzCode: Reveal With Reveal

In my last post, I revealed that I am a magician; an OzCode magician1. I also revealed the new LINQ support currently in EAP. Since that was two reveals in one, I thought that I would look at another OzCode feature today coincidentally called Reveal.

I remember this specific feature as "favourites for properties" although I am reliably informed by the OzCode team, their website, and their documentation that it is in fact called "Reveal"2. Reveal was the feature that first lured me into regular use of OzCode and if it is the only feature you use, you will still wonder how you really survived without it.

When debugging, we can spend lots of time drilling down into objects to find the value of various properties and sub-properties. This can get especially tiresome when we're looking at a few similar objects since we repeat the same steps. Although pinning certain values is helpful, it does not really solve the initial issue of drilling down to find the thing to pin.

With Reveal, we can make life much simpler by elevating the details of an object to its summary; like an on-the-fly custom ToString implementation. Not only does this help with looking at one item, but it really helps with collections of similar items. For example3:

Animated GIF showing how to use Reveal in OzCode
Animated GIF showing how to use Reveal in OzCode

Any properties that are "revealed" carry across to the rest of the debug session and beyond; once you have revealed some properties, they stay revealed until you decide you do not want them to be anymore, even across debug sessions.

Animated GIF showing how the revealed properties remain revealed
Animated GIF showing how the revealed properties remain revealed

You can even see (and change) your revealed properties directly within the LINQ analysis window.

Animated GIF of using Reveal inside the new LINQ analysis feature of OzCode
Animated GIF of using Reveal inside the new LINQ analysis feature of OzCode

Finally, revealed properties propagate up the object hierarchy allowing you to surface values from deeper in your object tree. This can really be a huge time saver, especially since the revealed properties are remembered across sessions. No more hovering over multiple things to find what you're looking for and no more writing custom ToString overrides, debug visualizers, or other workarounds.

Hopefully, this overview of Reveal in OzCode has demonstrated not only why I love it so much, but also how valuable it can be. I genuinely believe OzCode to be an essential tool in any .NET developer's kit, but since you may mistake me for some corporate shill, you should not take my word for it; try OzCode out for yourself with a free trial (or take part in the EAP). Stop performing workarounds and start performing magic.


  1. Read as Sean Connery as James Bond 

  2. and apparently it doesn't matter how often I tell them they are wrong 

  3. To demonstrate, I am using the handy demo app from OzCode, which you can find on GitHub 

I Am an OzCode Magician and I Have a New LINQ Trick

It has probably not gone unnoticed by those whoocm_logo know me that I really like the OzCode extension to Visual Studio. Now, I have an awesome glass brick with my name etched in it as proof1. I am happy to announce that I was recently invited to be a part of the OzCode Magician Program; an award in recognition of my genuine enthusiasm and support for OzCode over the last couple of years.

linqBug

What I really like about this is that I get to occasionally preview a new feature or two. Of course, sometimes I will be sworn to secrecy on what those features are, but thankfully, the current feature I have been allowed to play with is no secret at all. It was showcased in OzCode's recent webinar and recently made publicly available as an EAP2, so you can try it too. To whet your appetite, here is a sneak preview of the new magical LINQ debugging support.

numericIndicators

In this latest update to OzCode, we get some really nice visualizations of our LINQ queries, enabling us to see the queries step-by-step. No more refactoring code just to see what that Where will do.

quickDatatip

The new LINQ debugging allows a user to step into a specific part of the query chain on a specific iteration and see exactly what the outcome is, and it can show you how inputs map to outputs on many of the most common LINQ operations.

detailsQueryToolWindow

At the time of writing, the EAP only supports fluent syntax LINQ but I am assured that query syntax support is on its way. So, go register for the EAP now and give it a try for yourself. It's magical!


  1. also weighty enough to be a prop in an episode of CSI 

  2. Early Access Preview 

Merging multiple accounts on UserEcho

UserEcho is a service employed by the likes of OzCode and SublimeText for collecting and managing customer issues and suggestions; often regarding software features and bugs. It enables users and developers to discuss bugs and ideas, and respond to frequently asked questions.

OzCode UserEcho landing page
OzCode UserEcho landing page

Recently, I signed into the OzCode UserEcho site using my Google credentials. UserEcho supports the OpenID identity system, providing a wide range of ways to authenticate. Upon logging in, I was immediately confused; where was the issue I had raised a week or two earlier? I was certain it should be there but it was not. After a little thought, I realised I may have logged in with the wrong credentials, inadvertently creating a new account. I logged out and then, using my GitHub account to authenticate instead of Google, tried logging back in. Voila! My issue appeared.

For some, this would probably be the end of it, but it bugged me that I now had two accounts. You may think this is no big deal and you are right, but it was bothering me1.

Settings dropdown on UserEcho
Settings dropdown on UserEcho

Using the dropdown captioned with my name at the top-right of the UserEcho site, I chose User Profile. At the bottom of the subsequent page, I found a table of OpenID logins that the account used but no way to edit it. How could I merge my accounts or add new OpenID identities?

OpenID table on UserEcho user profile screen
OpenID table on UserEcho user profile screen

After searching around the UserEcho site a bit and trying a few Google searches2, I was almost ready to contact UserEcho for some help (or just give up), but then I had an idea. If UserEcho was like most sites these days, it probably keyed accounts using a primary email address for the user. So, I checked the two UserEcho accounts I knew I had and confirmed they had different email addresses.

User details section of a UserEcho profile
User details section of a UserEcho profile

I edited the email address for one of the two accounts to match the other, triggering UserEcho to send a verification email3, so I followed the instructions and verified the email address change.

UserEcho table of accounts with the same email
UserEcho table of accounts with the same email

Then I returned to the User Profile screen in OzCode's UserEcho. At the bottom, below the OpenID table, I was now presented with a message saying that there were other accounts with the same email address, including a Merge button. I clicked that button and immediately, the table showed both the Google and GitHub logins.

OpenID table in UserEcho showing GitHub and Google IDs
OpenID table in UserEcho showing GitHub and Google IDs

So, there you go. If you have multiple accounts for a UserEcho product site, make sure the email addresses match and that you have verified the email address on each account, then view one and click Merge. Job done.


  1. In writing this blog and generating the screenshots, I discovered I actually had three accounts! 

  2. and maybe one Bing 

  3. just making sure you're still you 

Prerelease packages with branches, Appveyor, and MyGet

We use a workflow where Appveyor is setup for CI and then it automatically pushes newly built nuget packages to a MyGet feed for consumption. Perhaps in a future post, I will go over how to set all this up, but for now, let's assume you already have this working; you push changes to a branch in your GitHub repo, which then gets built and tested on Appveyor, before being pushed to MyGet. Everything is nice and smooth.

Unfortunately, the magic ended there. Since there is no differentiation between pushing prerelease changes and release changes, I found that I would either have to limit what branches built in on Appveyor or spend a lot of time curating MyGet to remove intermediate builds I did not want used. I knew that MyGet supported prerelease packages but no matter what I tried, I could not get Appveyor to build them. Unsurprisingly, I found this frustrating. Then I stumbled on this particular answer on StackOverflow:

However, there were some issues I had with this.

  1. It seemed wrong that I had to use an after_build or on_success step to explicitly build my nuget package
  2. I didn't want every build to be prerelease
  3. It didn't work

The first point smelled enough that I wanted to see if I could not have to do that, and that second point seemed really important.

So, I delved a little deeper and discovered that the nuspec file, which has a handy $version$ substitution for the version takes that information from the value of the AssemblyInformationalVersion attribute, which I did not have declared in my AssemblyInfo.cs. Since it was not in there, the Appveyor step declared to patch it did not do anything. This was easy to fix, so I edited my AssemblyInfo.cs to include the attribute and tried again. This time the version updated as I wanted, even without the after_build or on_success shenanigans.

However, it still was not quite right since now, every build being performed was marked as prerelease. While this is a potential workflow, where the appveyor.yml is updated when finally reaching release, what I wanted was for releases to occur when I tagged a branch. For that, I looked at tweaking how the Appveyor build version updated and what environment variables Appveyor defined that I could leverage.

It turns out that Appveyor defines APPVEYOR_REPO_TAG, which is set to true if the build was started by a tag being pushed. It also defines APPVEYOR_REPO_BRANCH containing the name of the branch being built. Armed with these two variables, I updated my appveyor.yml to have two init scripts.

The first script creates a new environment variable. If the APPVEYOR_REPO_TAG is set to true, the new variable gets set to the value of APPVEYOR_BUILD_VERSION; if not, it is set to APPVEYOR_BUILD_VERSION-APPVEYOR_REPO_BRANCH. So, for example, if the build was going to be version 2.4.0, it was not a tag, and the branch was master, then the new variable would be set to 2.4.0-master; however, if it was a tag, it would just be 2.4.0.

The second script calls the Update-AppveyorBuild cmdlet provided by Appveyor, passing the value of the new environment variable as the -Version parameter value.

These two init scripts, plus the AssemblyInformationalVersion attribute in the AssemblyInfo.cs (and corresponding assembly_information_version field under the assembly_info section of the appveyor.yml) were all I needed. Now, whenever I push to a branch, I get a new prerelease nuget package that I can use in my development coding, and whenever I create a new tag, I get a release package instead. Not only does this reduce my need to manually manage my nuget packages on MyGet, but it also means I can take advantage of the different retention policy settings between prerelease and release packages.

All in all, I find this workflow much nicer than what I had before. Hopefully some of you do too. Examples of the appveyor.yml file and associated AssemblyInfo.cs change can be seen in the following Gist.