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.
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.
I recently read a “Coding Question” thread, and a developer was asking what we all thought about this article. I wanted to hold on to my replies, so I’m posting it here for posterity 🙂
Auri:
Only a Sith deals in absolutes. There are use cases for everything, with exceptions.
Auri:
Seriously, though, I’d write tests to ensure the states that you want work as expected.
Auri:
Exceptions are a necessary construct. If something doesn’t go as planned, we need a way to handle it. In his article, he’s against blindly swallowing exceptions. That’s generally sound advice. Ask yourself: “Is this an expected exception? If so, do I have a specific exception handler for it, or am I just using the generic catch-all? Have other exceptions occurred? If so, is this one expected? Didn’t I read about C# support for exception switch statements? Did I just shiver?”
Have you been wondering how to access the Azure Multi-Factor Authentication Settings in the Azure Classic Portal without first having to create an Azure account? I figured this out a few days ago, having an Office 365 tenant, and wanting to use the EMS and Azure Active Directory Premium features. Following Microsoft’s instructions, it said to go to the Azure Classic Portal. The problem is, Office 365 doesn’t include an Azure subscription, it just includes Azure Active Directory, which you manage through the “modern” Azure portal. Unfortunately, the Trusted IPs and MFA capabilities are managed through the Azure Classic Portal, which you can’t directly access without an Azure subscription.
So, here’s what you do:
Type the following command from an admin command prompt:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SynTP\Parameters\Debug /v DumpKernel /d 00000000 /t REG_DWORD /f
I’ve been having this problem with Visual Studio. Alt-Shift-L is a common shortcut for finding the location of a file in your solution. However, on a Lenovo laptop, pressing that key combo also stores debug log info for the touchpad driver. Pretty annoying, totally useless, and no UI element to turn it off.
Found this helpful article:
A note: Don’t call Lenovo support. My gosh, they transferred me 3 times, each time to the wrong department. Thank heavens for the Internet.
From their forums:Â https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/How-to-disable-touchpad-diagnostics-hotkey-alt-shift-l/td-p/2176730
Auri's Blog 