Windows: change default sound source with 1 click

Glenn — Wed, 04 Nov 2020 23:06:09 +0000

I found myself switching between my monitor speakers and my headphones frequently and having to click 3-4 times through the taskbar every time I wanted to change started to get annoying.

I figured it could be useful to others so here it is.

Default Audio Switcher

Purpose:

Created for switching default sound source between my monitor speakers and headphones with 1 click.

Prerequisites:

Windows OS
Download and copy NirCmd to your windows directory
Download my defaultaudioswitcher repo

Setup Switch Sound Source:

Find the names of your sound sources for your PC via command prompt

nircmd showsounddevices

Pick the two you want to switch between
Edit the SwitchSoundSource+.bat file with the names of your sound sources

SET defaultSoundSource="exampleSource1"
SET soundSource0="exampleSource1"
SET soundSource1="exampleSource2"

Save the SwitchSoundSource+.bat
Run (double click) SwitchSoundSource.vbs

Optional:

Create shortcut to the .vbs file and set icon location to ico file in this folder (or your own custom icon)
Set hotkey via shortcut properties

I just have my shortcut set up on my Nexus Dock

@author Glenn Chon

How do all of you handle user sign up flows?

Glenn — Sat, 26 Sep 2020 20:38:08 +0000

I've seen:

⚫ Sign up form (email and password) ➡ Verification email ➡ User logs in

⚫ Sign up with email ➡ Verification email to account setup page (details and password) ➡ User is logged in

What benefits do you see in your method?

Architecture planning of an on top filter over multiple public search APIs?

Glenn — Tue, 14 Apr 2020 20:10:04 +0000

I'm in the beginning stages of creating a service that gives users more filtering options on top of multiple public APIs.

I think I've gathered the basic pros and cons of setting something like this up with different stacks and wanted to see if I was missing anything big or I have anything wrong. (Or if you have any other recommendations)

Option 1:
Normal front end + back end for auth and config saves to DB.

Front end > User requests search > User search configs > Request from individual APIs > Filter > Display
Back end > handles user auth and config saves

Pros:

Simple to set up.
Public API end point requests come from client so there’s less cost for my server.
No chance of being blacklisted for too many API calls from 1 IP address.

Cons:

All filtering done on client side, code will be accessible to anyone who wants to copy.
UX speed dependent on client machine/connection – Must wait for multiple API requests from different sources and then filter.
Speed dependent on 3rd party API servers and whether they’re available at time of request.

Indifferent:

Will still need to implement an auth server and save user settings.

Option 2:
Normal front end + REST back end API + auth and config saves to DB.

Front end > User saves configs > User requests search
Back end > Use user search configs > Calls 3rd party APIs > Results formatted and filtered in server > Return to front end > Display results

Pros:

Simple to set up.
Don’t have to worry about bogging down client UX.
Hides filtering from anyone who wants to just copy the code and business model.

Cons:

Increase in cost due to many api requests from my server.
Risk of being blacklisted if there are a high number of users.

Option 3:
Normal front end + REST back end API + Redis cache + auth and config saves to DB.

Front end > User saves configs > User requests search
Back end > Use user search configs > check if end-points are in DB or end-point results are in Redis cache

If false, Calls 3rd party APIs > Format results > Results saved Redis cache > Filter results > Return to front end
If true, get results from Redis cache > Filter results based on user configs > Return to front end ________________________________________

Pros:

Less requests done from my server than option 2.
Less risk of being blacklisted.
Requests are only called when needed or the cache result has timed out.
If there are a lot of users with the same base API search requests, this will have a constant number of requests within a specified cache timeout time-frame.

Cons:

Same speed as 2 if users request search after a cache item has timed out.
Increase in setup complexity.

Option 4:
Normal front end + REST back end API + Redis cache + auto rolling API calls+ auth and config saves to DB.
Same as Option 3 but instead of getting results on demand when Redis cache item times out, the server automatically gets the results for each unique api endpoint upon timeout. (aka 4 times a day it’ll make all unique api calls and cache results)

Pros:

Same as 3
Constant number of 3rd party API calls, x:1 relation in number of calls and Unique API. X being how many times I want my server to auto get results.
Decreases costs substantially as user numbers get high. Scales effectively.

Cons:

Not as cost effective as 3 in the beginning as it may be making calls unnecessarily with small user numbers ( could halve the number of calls at first to 2 instead of 4 times a day) and change that as users increase.

Option 5:
Front end with GraphQL + Apollo GraphQL backend + Redis cache + auto rolling API calls + auth and config saves to DB

Setup same as Option 4 but basically implement it as a GraphQL API

Pros:

Reduces number of calls between client and my server for relational calls
Decreases costs on my end when implemented for large number of users.
Would be fun to learn and useful in the future for other projects

Cons:

Time to learn setting up GraphQL
Not really worth it if I don’t have a large number of users accessing relational data

DEV Community: Glenn

Windows: change default sound source with 1 click

Default Audio Switcher

Purpose:

Prerequisites:

Setup Switch Sound Source:

Optional:

How do all of you handle user sign up flows?

Architecture planning of an on top filter over multiple public search APIs?