The innovative programming ideas thread

[svdsinner]

Often we see ideas in programming that have the potential to surprise and delight our end-users. This is the thread to share ideas that made you go "Wow, this is worth sharing!"

• Cool UX ideas
• Ways to make our lives easier
• Improvements to work flow
• Helpful libraries you just discovered
• Cool programming tools

I'll kick this off with a cool UX idea:
When entering addresses, make the City box an autocomplete dropdown that populates based on any one of several geographical data sources. Less typing for users, less misspelled cities. Allow non-listed entries, of course. (Probably should update the geographical data occasionally) You will be loved by anybody who enters lots of addresses.

 

[Apteris]

Debuggers that let you go back in time. As in, you press Alt+F8 or whatever, and program execution goes back one step, program counter, program state, and all.

It's not a new idea at all, and there are a few implementations, but still far too few to my liking. I'd really like to have one at my fingertips for my day-to-day work.

 

[Ardax]

Debuggers that let you go back in time.

I thought IntelliTrace let you do this in Visual Studio? Needs the Enterprise Edition, of course.

When entering addresses, make the City box an autocomplete dropdown

What I've seen recently in a lot of places is typing in your first address line will give you an autocomplete dropdown that just fills in the rest of the address. It's... really nice. As long as 1Password or something else don't throw another fucking pop up on top of it.

 

[rain shadow]

What I've seen recently in a lot of places is typing in your first address line will give you an autocomplete dropdown that just fills in the rest of the address. It's... really nice.

I had access to some of the backend data for this kind of thing a little while ago. What happens a lot of the time is that the user just takes the first autocomplete that looks remotely close. If the street is walnut or main or second it's hopeless. The second level is some UI's will autocomplete an address including the apartment number, then the user might take whatever starts with the same digit, rather than typing more or scrolling further in the autocomplete list. It was really bad, IOW an unconcerned user would get about a 2% error rate, which is fine if you're just going to send them brochures, but if you are sending them products they ordered that's terrible.

I now lean toward having the user type in the whole address line, and another line for city/state/zip and only then go look for matches. It can still be interactive and on the same page. If the backend data indicates an apartment number is needed but not present, you can highlight the address line and put the cursor at the end where the unit number usually goes. And don't provide any completion/corrections unless the user input narrows it down to few enough addresses that they all fit in the pop-up. They will not scroll.

We didn't do this, but one place was thinking about physically mailing postcards with six-digit verification codes to customers before shipping any products to the address they entered.

 

[Lt_Storm]

I had access to some of the backend data for this kind of thing a little while ago. What happens a lot of the time is that the user just takes the first autocomplete that looks remotely close. If the street is walnut or main or second it's hopeless. The second level is some UI's will autocomplete an address including the apartment number, then the user might take whatever starts with the same digit, rather than typing more or scrolling further in the autocomplete list. It was really bad, IOW an unconcerned user would get about a 2% error rate, which is fine if you're just going to send them brochures, but if you are sending them products they ordered that's terrible.

This sounds like the kind of thing that might be fixed by showing the location of the address on a map.

 

[Ardax]

What happens a lot of the time is that the user just takes the first autocomplete that looks remotely close. If the street is walnut or main or second it's hopeless.

My house number + street name is unpopular enough that it's not an issue -- that didn't even click for me. I can see how that would be exceedingly problematic.

 

[ShuggyCoUk]

In the UK cities the postcodes are normally small enough that your name and that would get it to you (the postie often knows their route, or asks on the street for someone). Also the pandemic resulted in lots of "street level groups" being created so just putting it in one door results in it eventually making it because people are generally pretty nice and helpful.

Many UK centric sites try to get you to type the postcode first and then it's always going to be pretty on point.

ZIP codes in the US are, I understand waaaay larger in many cases so not as amenable to this.

 

[ShuggyCoUk]

I wish there had been some intermediary (goverment run is fine) where you get a (shortish) personal code for things and you update the central intermediary with where that should target.

It wouldn't be a means to hide (any one registered to the system gets to do the lookup to area to calculate shipping etc) it just lets you do redirects simply and not have to worry about updating various places that need your address when moving.

 

[LID919]

I wish there had been some intermediary (goverment run is fine) where you get a (shortish) personal code for things and you update the central intermediary with where that should target.

It wouldn't be a means to hide (any one registered to the system gets to do the lookup to area to calculate shipping etc) it just lets you do redirects simply and not have to worry about updating various places that need your address when moving.

I was thinking about how such a system would be architected. Simple HTTP get request, company uses an API key to authenticate and it costs some minimal amount per request. A request could be for one or more addresses, so companies can optimize costs to themselves by batching their requests, also reducing load on the system.

I stopped for a moment, concerned that this could allow anyone with a valid API key to get the address of anyone whose code they know. That risks large scale data brokers just scraping huge amounts of addresses to build up address histories and then associating those histories with a unique person as soon as either the person's key or any one address leaks. If the addresses include the recipient name, then it's even easier. Data brokers could just hit the API with batches of random codes and steal address information.

It wouldn't be the only way such entities steal PII to sell, but being a new system and if it is run by "the government" it'll be under a lot of scrutiny. "Government sells your address to scammers" would be the exact kind of headline that could kill the project, and be political poison for whatever politician set it up.

It would also risk providing a tool for anyone looking to harass or otherwise abuse a target if they can figure out the target's code. Imagine the likes of 4chan getting someone's code. SWATTing on demand. Easy access to mail death threats. Or in the worst case scenario straight up showing up at someone's home.

Stalker exes. Creepy fans showing up at streamers doors. And more.

At the bare minimum such a system would need to be strictly opt-in, with a trivial ability to delete your information from it at a later point. But even that might not be enough to mitigate the risks that come with this kind of unified attack vector.

And all this doesn't even get into what happens if the database is hacked.

 

[ShuggyCoUk]

Back on track (sorry).

I saw Dev Drives linked from a LinqPad update. I wouldn't have been able to use this in my previous employment so would have largely ignore it anyway. Anyone used this?

Dev Drive is a new form of storage volume available to improve performance for key developer workloads.

Dev Drive builds on ReFS technology to employ targeted file system optimizations and provide more control over storage volume settings and security, including trust designation, antivirus configuration, and administrative control over what filters are attached.

 

[ShuggyCoUk]

I was thinking about how such a system would be architected. Simple HTTP get request, company uses an API key to authenticate and it costs some minimal amount per request. A request could be for one or more addresses, so companies can optimize costs to themselves by batching their requests, also reducing load on the system.

I stopped for a moment, concerned that this could allow anyone with a valid API key to get the address of anyone whose code they know. That risks large scale data brokers just scraping huge amounts of addresses to build up address histories and then associating those histories with a unique person as soon as either the person's key or any one address leaks. If the addresses include the recipient name, then it's even easier. Data brokers could just hit the API with batches of random codes and steal address information.

It wouldn't be the only way such entities steal PII to sell, but being a new system and if it is run by "the government" it'll be under a lot of scrutiny. "Government sells your address to scammers" would be the exact kind of headline that could kill the project, and be political poison for whatever politician set it up.

It would also risk providing a tool for anyone looking to harass or otherwise abuse a target if they can figure out the target's code. Imagine the likes of 4chan getting someone's code. SWATTing on demand. Easy access to mail death threats. Or in the worst case scenario straight up showing up at someone's home.

Stalker exes. Creepy fans showing up at streamers doors. And more.

At the bare minimum such a system would need to be strictly opt-in, with a trivial ability to delete your information from it at a later point. But even that might not be enough to mitigate the risks that come with this kind of unified attack vector.

And all this doesn't even get into what happens if the database is hacked.

Entirely opt in. And the only info it would need is code -> address (not name). It likely needs the history to deal with accidents internally, but the hack you mention means that would be something to age out.

The other option is the system is not public in anyway, you send a package/letter etc and only the actual last mile companies such the royal mail/USPS/UPS etc ever get the address. Still a hacking target though I know.

Royal Mail redirect's work pretty well IME though so

 

[LID919]

Entirely opt in. And the only info it would need is code -> address (not name). It likely needs the history to deal with accidents internally, but the hack you mention means that would be something to age out.

The other option is the system is not public in anyway, you send a package/letter etc and only the actual last mile companies such the royal mail/USPS/UPS etc ever get the address. Still a hacking target though I know.

Royal Mail redirect's work pretty well IME though so

Option 2 makes calculating shipping costs impossible. And it wouldn't be enough to just return "distance" on sending a request because distance isn't the only thing that goes into delivery pricing. It would need to do something like "return the prices for all the different carriers to bring a package to that location". Which could get pretty odd.

It also prevents anyone from creating a competing delivery service if you enshrine only the post office and a tiny number of existing services as "official" to the exclusion of any new ones.

Additionally, it doesn't stop some software dev at UPS from stalking his ex with the system while "running tests".

 

[ShuggyCoUk]

Yeah, you're right, without exposing entirely it's not remotely viable (not that the full one necessarily would be!)

 

[Ardax]

I saw Dev Drives linked from a LinqPad update.

I've done it on my personal laptop, but haven't really put it through it's paces yet.

It's "just" a vhdx for an ReFS volume on a mount point. Nothing exactly earth shattering about the tech. I already kept my code excluded from Defender, so I'm not sure what else I'll see improvement wise.

 

[Aleamapper]

Debuggers that let you go back in time. As in, you press Alt+F8 or whatever, and program execution goes back one step, program counter, program state, and all.

It's not a new idea at all, and there are a few implementations, but still far too few to my liking. I'd really like to have one at my fingertips for my day-to-day work.

i was writing a programming game (think zachtronics without the polish, or most of the game) a few months ago and wrote a time-travelling debugger for it, you could also create snapshots and run state forward from them with multiple values and compare end states. I was quite chuffed until I saw this debugger for c64 development...

View: https://youtu.be/GWh_kzr55Oo?list=PLq4NVS62WsPDgnYyb3hUHZpWodSF4z5bo&t=5590

...that shows PC/disassembly and machine state for every raster line, plus a bunch of other views of memory and crazy stuff. Makes me want to try c64 demoscene dev just so i can use it!

 

[svdsinner]

When designing database table foreign keys, sometimes it can make things far more usable to Foreign key to the meaningful unique value rather than to the "Id" column of the foreign table. Example:
Table CarColors:

Id     Color
1      Red
2      Blue
3      White
4      Tan

Instead of table Car looking like this:

Id     Make    Model    ColorId
1      Ford    Focus    1
2      Honda   Civic    2
3      Hundai  Santa Fe 4
4      BMW     320i     1
5      Chevy   Blazer   3
6      GMC     Jimmy    3
7      Buick   Regal    5

Make it look like this:

Id     Make    Model    Color
1      Ford    Focus    Red
2      Honda   Civic    Blue
3      Hundai  Santa Fe Tan
4      BMW     320i     Red
5      Chevy   Blazer   White
6      GMC     Jimmy    White
7      Buick   Regal    Tan

Pro-tip: If you do this, make the foreign keys ON UPDATE CASCADE in case you ever need to fix a spelling error.

This can save a HUGE amount of joins and make ad-hoc queries so much faster. We started this a year ago and never want to go back.
(As with all database design tips, YMMV)

 

[Ardax]

When designing database table foreign keys, sometimes it can make things far more usable to Foreign key to the meaningful unique value rather than to the "Id" column of the foreign table

Ooh, are we bringing back the "natural key" vs "surrogate key" argument again? and ON UPDATE CASCADE.

popcorn.gif

I won't deny that it might have its moments, but they're pretty rare.

 

[rain shadow]

My experience is you get a lot of key collisions because people don't always assign unique names, and even if they do, someone will find a way to misspell it and then you get a duplicate record.

My preference is to just go ahead and do a join to see the natural key, or if you want to make it easy on the semi-techies, make a view that does the join for you.

 

[ShuggyCoUk]

If it’s a natural key then it is, by definition unique so it’s fine bar typos.

If not you used the wrong thing as a key and deserve what you get.

Collation matters though, and can bite you badly.

 

[rain shadow]

If it’s a natural key then it is, by definition unique so it’s fine bar typos.

I think I agree with that, but in my experience many natural keys are only unique because someone artificially put a unique constraint on a column. Some real-life data (names, social security numbers, driver's license numbers) aren't actually unique. You end up requiring a composite key to contextualize them (country, state, birthday, etc) to make them unique at scale when corresponding with real-world uniqueness.

So for relationships that tend towards a natural but composite key, svdsinner's idea becomes a little more cumbersome.

 

[Ardax]

If it’s a natural key then it is, by definition unique so it’s fine bar typos.

If not you used the wrong thing as a key and deserve what you get.

Collation matters though, and can bite you badly.

Collation and case-sensitivity, depending on your needs.

But I think that a lot of times people think something is a natural key and it turns out not to be as the system matures or the data model evolves.

There's also the challenges of, say, synchronizing an enum and a deployed table.

None of them are insurmountable, they're just yet more things that go into the choice.