Jason’s a great guy and Old 55 has a fantastic product. Learn more about their distillery, process, and more in the interviews:
Part I:
Part II:
I’m having a lot of fun sharing this with you. Part 2 is out, and I must say my editing skills are getting better 🙂 In this video, Steve discusses single barrel vs. blending. Spoiler alert: Blending isn’t bad.
I’ve also created a Facebook page for Bourbon Bartender… Yes, finally. Check it out.
Looking forward to your feedback – and I hope you enjoy.
Happy Holidays!
-Auri
I’ve been wanting to do this for a while… Talk with master distillers and others in the industry and see what their job is like. Most YouTube channels, blogs, and so forth celebrate the drinking aspect of bourbon, whiskey, and other spirits. What about the industry? What’s it like to be the part of the team that makes all this great stuff? And thus, my new Meet the Masters series was born. It’s part of my Bourbon Bartender channel, where I try to educate others on all things bourbon and whiskey.
In my first installment, I had the grand opportunity to interview Steve Nally, Bardstown Bourbon’s master distiller. Steve’s a great guy. Funny, a storyteller, and wise in the ways of distillation and whiskeycraft. I drove down to Louisville the night before, imbibed a bit, then headed to Bardstown. Much to my surprise, they have EV charging stations! The distillery is going through a multi-million dollar expansion, enabled after the investment by Pritzker.
Steve and I had lunch, then a great interview. It’s fascinating how similar our two occupations are – he’s crafting whiskey, and I’m crafting software. There’s so much process and quality control, and at the same time creativity and a focus on teamwork.
After the interview, I stayed the night at the Old Talbott Inn and closed the bar with a few new found friends. The next day, I headed home, eager to figure out how to edit video with two camera angles.
Enjoy the video!
I recently enjoyed a “fireside chat” at the Indy .NET Consortium, a meetup I run for local .NET developers.
I’ve had some good conversations with interns and others recently who have struggled with or had insights into this transition. My experience as a young developer was a bit different, because I didn’t take the traditional path of high school -> college -> workforce. Mine was high school -> college -> co-op -> left-school to work and create career -> go back to school -> leave school to work again -> work for startup -> work for consulting firm -> start a business -> shut down business and go back to workforce.
Our October 5 meetup talked about how the traditional path can be a bit jarring. The way I explained it to my employees was “In school, you can get an A, B, C, D, or F. And that’s OK. You learn from it. But in the workforce, you either get an A or an F. You can have as many Fs as you want, as long as you end up with an A. Sometimes, within reason, I’ll accept an A- or B+, but it’s rare. We’re paid to deliver, not pass lessons.”
You can watch the entire discussion below:
I’m often asked what bourbon or whiskey to buy as a gift. So, I added a Bourbon Bartender video explaining how to tackle that topic. Enjoy!
I recently ran into an issue with Amazon’s “Login with Alexa” – aka LWA – SDK in our Android app. Before releasing to Google Play, I fully tested the app. Logging in with Alexa worked flawlessly, and I was able to register my Amazon Alexa device.
Everything was looking good in the app, so I uploaded it to Google Play and released it to Production. A few hours later, the app was approved, and available for download to Android apps around the world. w00t!
A week or so later, a partner was testing the app and said “Hey, Amazon login doesn’t work!” Considering I had tested this 7 ways to Sunday, I found that hard to believe. But still, I had to test it.
Sure enough, I downloaded the app from Google Play, went to login with Alexa, and received an error: “Cannot connect to Amazon Alexa.”
WHAT?!?! It worked with the exact same APK I had uploaded. What the heck changed? Certainly, Google doesn’t change the code upon uploading, do they? How could they? Conspiracy theories aside, my team started looking into it.
When we’d logcat the PROD version, we’d see these telling entries:
2021-07-08 10:01:58.966 17695-6047/? I/com.amazon.identity.auth.device.api.authorization.AuthorizationManager: com.our.appname calling authorize
2021-07-08 10:01:58.972 17695-6047/? W/com.amazon.identity.auth.device.appid.APIKeyDecoder: Failed to decode: Decoding failed: certificate fingerprint can't be verified! pkg=com.our.appname
2021-07-08 10:01:58.972 17695-6047/? W/com.amazon.identity.auth.device.appid.APIKeyDecoder: Unable to decode APIKey for pkg=com.our.appname
It turns out, our signing process was the culprit. Our production LWA API key was generated in the Amazon developer portal using our original keystore’s thumbprint and SHA-256 hash. However, we use Google’s managed key service, which maintains the app signing key in Google Play. This is important, just in case you ever lose your keystore. Old timer Android devs know this nightmare…
So how do we fix this? How do we use a different LWA API key when releasing to Google Play, yet still enable our beta testers to use our sideloaded Dev builds? We definitely don’t want to lose our CI/CD pipeline to a manual process!!
Android build variants to the rescue.
The LWA API key is generally stored under assets/api_key.txt. However, that one was only the debug key. We needed one for both our debug and release build configurations. Luckily, you can simply add build folders for this and Android’s build system will take care of the rest! You don’t need to work with Gradle source sets!
To fix this, under the src/ folder, we added two new folders:
These are in addition to the typical:
As long as “replacement” entries exist in the build configuration-specific folders, the Android compiler will choose those assets over those under main/.
There’s more information about how to do this via the Android Studio UI here. Just keep in mind the UI approach is a slow process. Sometimes menu options you’re expecting don’t appear until gradle has finished doing its job.
Alright, to solve this problem, we need a new LWA API key based on our Google Play signing key. Thankfully, Google makes this easy to obtain.
We retrieved our Google Play thumbprint and hash from the Google Play Developer Console and going to <AppName> > Setup > App Integrity, and found our MD5 certificate fingerprint and SHA-256 certificate fingerprint:

Then we moseyed on over to the Login with Alexa Console, chose Kindle/Android Settings for our security profile, and added a second key:


Once we had the new API key – which you can retrieve by clicking Show – we added a new api_key.txt file under src/release/assets and inserted the new key there.
We then moved the non-Production API key from src/main/assets/api_key.txt to src/debug/assets. It no longer needed to be located under src/main/assets because we only want the configs for debug and release. If you have other build configs, you may need to create additional folders.
This enabled our CI/CD pipeline to continue to distribute DEV builds that work, and to also generate PROD builds we could successfully distribute via Google Play.
I hope this helps anyone else having the same issue!
A friend with a hearing aid was having issues after upgrading to a new Android phone. He could pair the device with his phone, but couldn’t make or receive phone calls. What the heck – he used the app, and nothing worked like before! I worked on it for about an hour, and finally figured it out… What a terrible experience for him, so I hope this helps others. It boils down to the hearing aid requiring two different Bluetooth connections to make things work. This is very common with headphones, actually.
For those interested in the root of the issue: You have to set up the Bluetooth Classic connection before the Bluetooth Low Energy – a.k.a. BLE – connection. If you set them up in the opposite order, the hearing aids stop advertising Bluetooth Classic and you’re stuck with being frustrated. It’s probably a firmware issue Phonak needs to address. Unfortunately, that requires taking the device to a service center – not an optimal solution for those needing hearing aids.
This article assumes you already have the Phonak app installed on the new phone.
Step 1 – Unpair the Hearing Aids From The Previous Device
Make sure your hearing aids are no longer paired to the old device. In the Phonak app, choose Forget Device. I’m not sure of the actual verbiage, as I’m writing this without having the app handy. Then, under Bluetooth Settings in Android, tap the widget wheel next to all the Phonak entries, and choose Forget Device or Unpair Device.
Step 2 – Factory Reset the Hearing Aids
Make sure the hearing aids are off. You can do this by holding the power button on each bud until the light turns red and letting go. Once they’re off, count 5 seconds. Now, on each bud, hold the power button until the orange light turns on and then off – don’t let go until it turns OFF. Then, power down the ear bud again.
Step 3 – Power On the Hearing Aids
Now that they’re reset, power them on again. You can do this by holding the power button until the green light flashes, then letting go.
Step 4 – Pair Bluetooth Classic
Do *not* launch the app first. Go to Bluetooth settings on your phone, then Scan for devices, and choose the Phonak device that has a headphone icon next to it. You’ll see a couple icon types – but you need the one entry that has the headphone icon. This indicates the “Bluetooth Classic” connection, if you’re interested in such technical details. Accept the pairing request prompts that will show up after you tap to pair. If prompted to make/receive phone calls with the device, confirm you want to do so.
Step 5 – Pair Bluetooth LE
Now that you’ve paired Bluetooth Classic, launch the Phonak app and run through its setup process.
Step 6 – Done!
You should be good to go. I hope this helps those of you frustrated by such a crazy experience.
So I recently ran into an issue where Microsoft AppCenter wouldn’t build my Android APK… It would find the source, build successfully, then fail to find the resulting APK.
If you’re running into this issue, try the following:
This is based on @johnclarete’s idea, which I had to modify due to it relying on Flutter’s config.
Find the android { part of the file and paste in the buildTypes part:
android {
compileSdkVersion 30
buildTypes {
appcenter {
applicationVariants.all { variant ->
variant.outputs.all {
def currentFile = new File(outputFileName)
def filename = currentFile.getName()
outputFileName = "../../../../../Application/Application/build/outputs/apk/${filename}"
}
}
}
}

That worked for me. I hope this helps others.
My friend Mark and I recently installed a VR pulley system. It’s a much less expensive alternative to Wireless VR solutions, none of which exist for Windows Mixed Reality, which is my headset type.
You can watch the video below:
Special thanks to Thrill for his three-axis pulley suggestion.
A friend reached out today and asked “Hey, I need my splash screen to be themed based on whether Dark Mode is selected on the Android device.” I had never done that before, so I was curious how it should be done.
Dark Mode is new to Android 10, a.k.a. Android Q. Not as tasty, but hey, gotta ship something. It has a range of benefits, such as lower energy consumption, looking cool, and frustrating developers without budget for theme-aware apps.
It turns out, after some sleuthing, it’s relatively straightforward.
First, this article assumes you’re following the “splash screen as a theme” approach, which you can learn more about here. The example is for Xamarin.Forms, but the same approach applies to regular Android development.
Basically, you have a “splashscreen” style, and you set it as your app’s theme in the Android manifest. Then, you “swap” to the real theme in MainActivity. For example, what I use in an app, located in resources/values/styles.xml:
<!-- Splash screen style --> <style name="splashscreen" parent="Theme.AppCompat.DayNight"> <item name="android:windowBackground">@drawable/splash</item> <item name="android:windowNoTitle">true</item> <item name="android:windowIsTranslucent">false</item> <item name="android:windowIsFloating">false</item> <item name="android:backgroundDimEnabled">true</item> </style>
Note my drawable. I want a different drawable for my dark vs. light (normal) theme. Here’s what is different:
In this example, I haven’t yet added the other folder variations, but you get the point.
The theme swap code in MainActivity is as follows:
protected override void OnCreate(Bundle savedInstanceState)
{ TabLayoutResource = Resource.Layout.Tabbar; ToolbarResource = Resource.Layout.Toolbar; // Swap back to the normal app theme. We used Splash so we didn't have to create a special activity. // Cute hack, and better approach. // Idea from URL: https://xamarinhelp.com/creating-splash-screen-xamarin-forms/ Window.RequestFeature(WindowFeatures.ActionBar); SetTheme(Resource.Style.MainTheme);
That’s all there is to it. If Dark mode is enabled, the splash.png from the -night folder will be used, otherwise the normal image will takes its rightful place.
If you have any questions, please hit me up in the comments.
Special thanks to this StackOverflow article for the –night hint.
More info on Android Dark Theme can be found here.